У меня проблема с синхронизацией большого объема данных между двумя центрами обработки данных. Обе машины имеют гигабитное соединение и не полностью заняты, но самое быстрое, что я могу получить, это что-то между 6 и 10 Мбит => неприемлемо!
Вчера я сделал трассировку, которая показала огромную нагрузку на маршрутизатор LEVEL3, но проблема существует уже несколько недель, и большое время отклика исчезло (20 мс вместо 300 мс).
Как мне отследить это, чтобы найти фактический медленный узел? Думал о трассировке с большими пакетами, но будет ли это работать?
Кроме того, эта проблема может быть не связана с одним из наших серверов, поскольку скорость передачи данных на другие серверы или клиентов гораздо выше. На самом делеофис => сервербыстрее, чемсервер <=> сервер!
Любая идея приветствуется ;)
Обновлять
На самом деле мы используем rsync через ssh для копирования файлов. Поскольку шифрование имеет тенденцию иметь больше узких мест, я попробовал HTTP-запрос, но, к сожалению, он такой же медленный.
У нас есть SLA с одним из центров обработки данных. Они сказали, что уже пытались изменить маршрутизацию, потому что, по их словам, это связано с дешевой сетью, через которую проходит трафик. Это правда, что он будет маршрутизироваться через "дешевую сеть", но только наоборот. Наше направление проходит через LEVEL3, а другой путь проходит через lambdanet (который, как они сказали, не является хорошей сетью). Если я правильно понял (я сетевой посредник), они смоделировали более длинный путь, чтобы принудительно маршрутизировать через LEVEL3, и они объявили LEVEL3 в пути AS.
Я в основном хочу знать, правы ли они или просто пытаются снять с себя ответственность. Дело в том, что проблема существует в обоих направлениях (по разным маршрутам), поэтому я думаю, что это ответственность нашего хостера. И честно говоря, я не верю, что есть соединение DC2DC, которое может выдерживать только 600kb/s - 1,5 MB/s в течение нескольких недель! Вопрос в том, как определить, ГДЕ это узкое место
решение1
Если вас направляют через медленный канал в общедоступном Интернете, то, по сути, единственным вариантом для вас будет принудительно обойти его. Самый простой способ сделать это — попытаться передать файл между двумя конечными точками, одна из которых — «точка A» (источник данных), апромежуточный сайткоторый географически не совпадает с пунктом назначения, «точкой Б».
Как только вы найдете «точку C», которая является сервером, который делаетнетмаршрутизироваться через медленный интернет-маршрутизатор, с которым вы сталкиваетесь, вы можете настроить VPN между точкой A и точкой C, чтобы трафик «маршрутизировался в обход» медленного узла.
Если у вас высокая деловая ценность ($$$$$$) или влияние на интернет-провайдера, вы также можете напрямую обратиться с этим вопросом к Level 3. Однако L3 является интернет-провайдером уровня 1 и может быть не особенно восприимчив к жалобам на качество обслуживания или перегрузку сети, поскольку они мало что могут сделать по этому поводу, если не могут, не хотят или неспособны расширить свои пиринговые соглашения с нижестоящими или другими провайдерами уровня 1, которые создают конкуренцию на своем узле.
Поскольку вы сказали, что соединение «офис-сервер» быстрее, вы можете попробовать настроить VPN на «офисной» площадке с использованием компьютера средней мощности (двухъядерной серверной системы должно быть достаточно).
О, и еще!Если задержка (сквозная) между «точкой А» и «точкой Б» очень высокая (более 100 мс считается высокой в серверном мире), вам следует убедиться, чтовы не используете сетевой протокол чата. Samba (также известная как SMB или Windows File Sharing) — этоочень сильноболтливый; другие протоколы «синхронизации» также могут быть болтливыми.
Болтливые протоколы — это те, которые требуют много синхронных "туда и обратно" круговых поездок для передачи данных. Если ваш протокол слишком болтлив, то задержка сама по себе может стать узким местом для вашей передачи, независимо от того, насколько быстрой может быть связь.
Чтобы определить, действительно ли болтливость влияет на вашу пропускную способность, можно воспользоваться известнымнеразговорчивыйпротокол, например HTTP, для тестовой передачи. Итак, попробуйте обычный старый HTTP из "точки A" в "точку B" через "медленный" маршрутизатор Level3, и если задержка высокая, но пропускная способность все еще хорошая, то вызнатьчто причина медленной передачи данных в том, что ваш протокол слишком «болтливый», поэтому вам нужно сменить протокол.
Итак, позвольте мне завершить обсуждение, кратко определив и объяснивтри сетевых нарушенияи почемулюбойиз них могут быть ответственны за эту проблему:
Задержка-- Сколько времени требуется датаграмме, чтобы добраться от вашего конца до другого конца. В большинстве случаев вы не можете напрямую улучшить задержку, если только один из ваших компьютеров не перегружен настолько, что его сетевой стек, ядро или приложения генерируют значительную дополнительную задержку. Большая часть задержек в общедоступном Интернете возникает из-за маршрутизаторов Интернета, а не из-за вашего компьютера или конечной точки.
Пропускная способность-- Пропускная способность — это максимальная пропускная способность самого медленного соединения между вашим компьютером и конечной точкой. В большинстве современных сетей пропускная способность не является реальным ограничением, поскольку другие сетевые нарушения возникают и замедляют работу сети задолго до того, как пропускная способность становится реальной проблемой.
Потеря пакетов-- Потеря пакетов может увеличитьсявоспринимаетсязадержка для надежных датаграмм (таких как TCP), и часто является результатом того, что сильно насыщенные соединения вынуждены выбрасывать ваш пакет из буфера передачи или приема TCP из-за того, что буфер уже переполнен. Кроме того, потеря пакета может произойти с пакетами, «чувствительными ко времени», как в случае почти со всеми пакетами TCP, потому что если пакет приходит после крайнего срока, то он отбрасывается. Это происходит, если более крупный пакет TCP фрагментируется на несколько датаграмм IP, и протокол TCP на принимающей стороне может ждать только фиксированное количество времени, пока все фрагменты не прибудут, прежде чем решить прервать прием пакета. Таким образом, потеря пакета косвенно вытекает из проблем насыщения (которыеявляетсяпроблемы с пропускной способностью), а также из-за проблем с оборудованием или сбоев.
Исходя из фундаментальных сетевых нарушений, вы можете предпринять меры по их снижению, чтобы повысить надежность своих программ, не меняя фундаментальные нарушения, поскольку в большинстве случаев вы мало что можете сделать, чтобы их контролировать:
Первый способ смягчения — сделать ваш протокол менее болтливым (или, с точки зрения системной интеграции,использоватьсуществующий протокол, который менее болтлив, чем ваше текущее решение). Чем меньше «обходных путей» требуется для синхронизации данных между конечными точками, тем лучше для вас — точка. Некоторые протоколы могут быть спроектированы так, чтобы требовать переменной частоты синхронизации — в этом случае вам следует динамически уменьшать частоту синхронизации настолько, насколько это возможно, если вы обнаружите высокую задержку или потерю пакетов. Уменьшение болтливости помогает смягчить задержку и потерю пакетов, но не проблемы с потолком полосы пропускания.
Второе смягчение — настроить все ваши переходы (те, которые вы напрямую контролируете на административном/аппаратном уровне) на использование наилучшего доступного алгоритма Active Queue Management (AQM), который в настоящее время является Fair Queue Controlled Delay AQM. Он доступен в ядре Linux 3.5 или более поздней версии как fq_codelреализация qdisc, и то, что он делает, — это динамическиуменьшаетразмер буферов передачи и приема, чтобы уменьшить задержку, которую эти буферы неизменно производят. Это может уменьшить потерю пакетов и помочь справиться с задержкой с помощью протокола TCP, поскольку ваши фрагментированные пакеты с меньшей вероятностью истекут, если вы минимизируете время ожидания, которое пакет должен пройти, прежде чем он будет отправлен по каналу. Обратите внимание, что это смягчение имеет значение только в том случае, если узел «насыщен» (т. е. если буфер TCP пуст, оно не оказывает никакого эффекта). Узел насыщается всякий раз, когда скорость записи данных в сетевой сокет превышает скорость передачи восходящего канала. Типичная реакция стека TCP на эту ситуацию — увеличить буфер, что на самом деле имеет отрицательный эффект, поскольку увеличивает задержку, и это вызывает всевозможные проблемы — поэтому fq_codel помогает смягчить это.
Оба эти способа смягчения помогают устранить все три основных недостатка сети:безмаршрутизация вокруг неисправного узла ибеззамена оборудования или обращение к интернет-провайдеру.