Проблемы с потерянными пакетами по каналам jgroups на EC2

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

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

При просмотре журнала трассировки 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 для поиска других кандидатов в члены кластера. Это не проблема с подключением.

Любые идеи, почему некоторые пакеты не доходят до места назначения?


java amazon-ec2 udp jgroups infinispan
person Gray    schedule 07.01.2014    source источник

Ответы (2)


arrow_upward
5
arrow_downward

Любые идеи, почему некоторые пакеты не доходят до места назначения?

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

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

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

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

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

От: Amazon Web Services

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

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

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

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

person Gray    schedule 07.01.2014
comment
Ура! Большое спасибо за ваше сообщение. Мы исследовали аналогичную проблему в течение нескольких дней, не предвидя никакого решения. До твоего поста, который попал прямо в точку. - person blacelle; 24.04.2014

arrow_upward
1
arrow_downward

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

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

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

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

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

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

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

person blacelle    schedule 24.04.2014