Мы наблюдали непоследовательные сетевые сбои при попытке настроить Infinispan на EC2 (большие инстансы) через Jgroups 3.1.0-FINAL, работающую на 64-битном Linux AMI Amazon. Пустой кеш запускается нормально и, кажется, некоторое время работает, однако, как только кеш заполнен, новый сервер, который синхронизируется, приводит к блокировке кеша.

Мы решили откатить собственный кеш, но наблюдаем примерно такое же поведение. Во время синхронизации происходит обмен 10-ю мегабайтами, но они не переполняются. Существует обмен данными -> подтверждение на уровне приложения, но похоже, что некоторые сообщения никогда не доходят до удаленного.

При просмотре журнала трассировки UNICAST я вижу следующее:

# my application starts a cache refresh operation 
01:02:12.003 [Incoming-1,mprewCache,i-f6a9d986] DEBUG c.m.e.q.c.l.DistributedMapManager - i-f6a9d986: from i-d2e29fa2: search:REFRESH 
01:02:12.003 [Incoming-1,mprewCache,i-f6a9d986] INFO  c.m.e.q.c.l.DistributedMapRequest - starting REFRESH from i-d2e29fa2 for map search, map-size 62373 
01:02:12.003 [Incoming-1,mprewCache,i-f6a9d986] DEBUG c.m.e.q.c.l.DistributedMapManager - i-f6a9d986: to i-d2e29fa2: search:PUT_MANY, 50 keyValues 
# transmits a block of 50 values to the remote but this never seems to get there 
01:02:12.004 [Incoming-1,mprewCache,i-f6a9d986] TRACE o.j.p.UNICAST - i-f6a9d986 --> DATA(i-d2e29fa2: #11, conn_id=10) 
# acks another window 
01:02:12.004 [Incoming-1,mprewCache,i-f6a9d986] TRACE o.j.p.UNICAST - i-f6a9d986 --> ACK(i-d2e29fa2: #4) 
# these XMITs happen for over and over until 01:30:40 
01:02:12.208 [Timer-2,mprewCache,i-f6a9d986] TRACE o.j.p.UNICAST - i-f6a9d986 --> XMIT(i-d2e29fa2: #6) 
01:02:12.209 [Timer-2,mprewCache,i-f6a9d986] TRACE o.j.p.UNICAST - i-f6a9d986 --> XMIT(i-d2e29fa2: #7) 
01:02:12.209 [Timer-2,mprewCache,i-f6a9d986] TRACE o.j.p.UNICAST - i-f6a9d986 --> XMIT(i-d2e29fa2: #8) 
...

Вот наш стек Jgroups. Мы заменяем протокол PING во время выполнения нашей собственной версией EC2_PING, которая использует вызовы AWS для поиска других кандидатов в члены кластера. Это не проблема с подключением.

Есть идеи, почему некоторые пакеты не достигают места назначения?

5
Gray 8 Янв 2014 в 01:38

2 ответа

Лучший ответ

Есть идеи, почему некоторые пакеты не достигают места назначения?

Это была интересная проблема, которую нужно было отследить. Похоже, что это влияет на одни экземпляры EC2 намного больше, чем на другие. Проблема заключается в том, что большие пакеты отправляются между экземплярами EC2 через UDP.

Код синхронизации кеша отправлял на удаленный сервер большое сообщение размером ~ 300 КБ, которое фрагментировалось (с использованием FRAG2) на 4 пакета по 60 КБ (размер по умолчанию) и 1 пакет размером 43 КБ, которые отправлялись на удаленный ящик. Из-за некоторых сетевых ограничений удаленный ящик получает только последнее (5-е) сообщение размером 43 КБ. 60k сообщений просто никогда не приходят. Кажется, это происходит только между определенными парами хостов - другие пары могут нормально взаимодействовать с большими размерами пакетов. То, что это не универсально, - вот почему мне потребовалось так много времени, чтобы изолировать причину проблемы.

Сначала я подумал, что это проблема с размером окна приемника UDP, и попытался отрегулировать ее (sysctl -w net.core.rmem_max=10240000), но это не помогло. Просмотр tcpdump показал, что 60k пакетов просто не поступали на удаленный хост. Только пакетов 43к было.

Решение заключалось в том, чтобы уменьшить размер фрагмента до 16k (32k, возможно, было хорошо, но мы были консервативны). Существует некоторое внутреннее ограничение AWS на размеры пакетов, поскольку они перемещаются по виртуальной сети Amazon, которая фильтрует большие пакеты UDP, превышающие, возможно, 50 КБ. Размер фрагмента Jgroups по умолчанию (60k) соответствует большому IMO и, вероятно, должен быть уменьшен до 32k или что-то в этом роде.

Мы отправили запрос по этому поводу в Amazon, и они признали проблему, но в целом ответили, что им было трудно ее исправить. Мы изменили размеры фрагментов и работали, поэтому заявка была закрыта. Цитата из билета:

От: Amazon Web Services

Это обновление для случая XXXXXXXXX. В настоящее время мы ограничены размером пакетов 32 КБ и ниже на Amazon EC2 и можем подтвердить проблемы, с которыми вы сталкиваетесь для пакетов большего размера. Мы ищем решение этого ограничения. Сообщите нам, можете ли вы сохранить размер пакетов ниже этого уровня, или если это серьезная проблема, мешающая вам работать.

Мы активно изучаем возможности увеличения размера пакета, а также другие улучшения платформы и приносим извинения за неудобства.

Еще пара комментариев по поводу EC2. Во-первых, мы видим, что TTL> 8, необходимого для хостов в той же зоне доступности. Если вы используете многоадресную рассылку, убедитесь, что ваш TTL установлен на 128 или что-то в этом роде. Сначала мы думали, что это проблема, но в конечном итоге это не так.

Надеюсь, это поможет другим.

5
Community 20 Июн 2020 в 09:12

Не добавляя никаких элементов к ответу, я хотел бы добавить альтернативный способ обнаружения той же проблемы.

Я не специалист по tcpdump, тогда я проанализировал проблему с отладкой и логированием.

В нашем случае сообщение было разделено на несколько меньших пакетов (с учетом параметра frag_size FRAG2). Некоторые из них (не обязательно последний) не передавались случайным образом: обычно пакеты с 1 по 19 передавались правильно, 21 передавалось, а 20 отсутствовало.

За этим последовало большое количество циклов обмена между двумя экземплярами:

У клиента будет отсутствовать пакет №20, он снова подтверждает №19 и запрашивает 20; сервер отправит # 20, который запрошен явно, и # 21, который не был подтвержден

Клиент, у которого отсутствует # 20, получит # 21 (но не # 20), повторно подтвердит # 19, повторно спросит # 20 и так далее в течение времени от 1 секунды до 50 секунд.

В конце клиент, у которого отсутствует # 20, обычно завершает работу (даже если # 20 никогда не получал), ничего не говоря.

1
Community 20 Июн 2020 в 09:12