Логическое рассуждение в сетевых проблемах

Классический случай 1

Многим специалистам по программному обеспечению не хватает глубоких знаний логики TCP/IP, что часто приводит к неправильной идентификации проблем как загадочных. Некоторые отпугиваются сложностью литературы по сетям TCP/IP, в то время как другие вводятся в заблуждение запутанными деталями в Wireshark. Например, администратор баз данных, столкнувшийся с проблемами производительности, может неправильно истолковать данные захвата пакетов в Wireshark, ошибочно заключив, что причиной являются повторные передачи TCP.

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

При анализе сетевых пакетов информация о временных метках критически важна для точного логического вывода. Разница во времени в диапазоне микросекунд между двумя дублирующими пакетами указывает либо на повторную передачу по таймауту, либо на захват дублирующего пакета. В типичной локальной сети со временем обратного пути (RTT) около 100 микросекунд, где TCP повторные передачи требуют как минимум одного RTT, повторная передача, происходящая всего в 1/100 части RTT, скорее всего указывает на захват дублирующего пакета, а не на фактическую повторную передачу по таймауту.

Классический случай 2

Еще один классический случай иллюстрирует важность логического вывода в анализе проблем сети.

Однажды один бизнес-разработчик вспомнил, что запланированный скрипт, использующий промежуточное программное обеспечение базы данных MySQL, не сработал в ранние утренние часы без какого-либо ответа. Услышав о проблеме, я проверил журналы ошибок промежуточного программного обеспечения базы данных MySQL, но не нашел ценной информации. Поэтому я попросил разработчиков воспроизвести проблему, зная, что проблема становится проще решаемой, как только ее удается воспроизвести.

Разработчики пытались несколько раз воспроизвести проблему, но безуспешно. Тем не менее, они сделали новое открытие: они обнаружили, что выполнение тех же SQL-запросов днем приводило к другим временам ответа по сравнению с ранним утром. Они подозревали, что когда ответ от SQL был медленным, промежуточное программное обеспечение базы данных MySQL блокировало сеанс и не возвращало результаты клиенту.

Основываясь на этом понимании, команду по работе с базами данных попросили изменить SQL-запрос скрипта для имитации медленного ответа SQL. В результате промежуточное программное обеспечение базы данных MySQL возвращало результаты без возникновения проблемы зависания, замеченной в ранние утренние часы.

Некоторое время не удавалось выявить коренную причину, и разработчики обнаружили функциональную проблему с промежуточным программным обеспечением базы данных MySQL. Поэтому разработчики и операционные специалисты по базам данных стали более убеждены в том, что промежуточное программное обеспечение базы данных MySQL задерживает ответы. На самом деле эти проблемы не были связаны с временами ответов промежуточного программного обеспечения базы данных MySQL.

Из событий первого дня проблема действительно возникла. Все участники пытались выявить причину, делая различные догадки, но истинная причина оставалась неясной.

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

Как разработчик, ответственный за прослойку базы данных MySQL, такие загадочные проблемы не могут быть легкомысленно проигнорированы. Их нельзя игнорировать, так как это может повлиять на последующее использование прослойки базы данных MySQL, и есть также давление со стороны руководства на оперативное решение проблемы. Наконец, было решено внедрить решение анализа захвата пакетов низкой стоимости: во время выполнения сценария рано утром на сервере будут выполняться захваты пакетов для анализа того, что происходило в это время. Цель заключалась в том, чтобы определить, не отправила ли прослойка базы данных MySQL ответ вовсе или отправила ответ, который сценарий клиента не получил. Как только можно было подтвердить, что прослойка базы данных MySQL действительно отправила ответ, проблему не пришлось бы приписывать разработчикам прослойки базы данных MySQL.

На третий день разработчики сообщили, что проблема ранним утром не повторилась, и анализ захвата пакетов подтвердил, что проблема не возникла. После тщательного рассмотрения, казалось маловероятным, что проблема была исключительно в промежуточном ПО базы данных MySQL: частые проявления ранним утром и редкие проявления в течение дня вызывали недоумение. Единственным выходом было дождаться повторения проблемы и проанализировать её на основе захватов пакетов.

На четвертый день проблема снова не проявилась.

Однако на пятый день проблема наконец появилась снова, что дало надежду на её разрешение.

Файлов захвата пакетов много. Сначала попросите разработчиков предоставить временную метку, когда возникла проблема, затем просмотрите обширные данные захвата пакетов, чтобы определить SQL-запрос, который вызвал проблему. Конечный результат следующий:

Из содержания захвата пакетов выше (захвачено с сервера) видно, что SQL-запрос был отправлен в 3 часа ночи. Промежуточное ПО базы данных MySQL затратило 630 секунд (03:10:30.899249-03:00:00.353157), чтобы вернуть SQL-ответ клиенту, что подтверждает, что промежуточное ПО базы данных MySQL действительно ответило на SQL-запрос. Однако всего через 238 микросекунд позже (03:10:30.899487-03:10:30.899249) TCP-слой сервера получил пакет сброса, что было подозрительно быстро. Важно отметить, что этот пакет сброса нельзя сразу считать от клиента.

Во-первых, необходимо подтвердить, кто отправил пакет сброса — либо это сделал клиент, либо промежуточное устройство по пути. Поскольку захват пакетов был выполнен только со стороны сервера, информация о ситуации с пакетами клиента недоступна. Анализируя файлы захвата пакетов со стороны сервера и применяя логическое мышление, цель состоит в том, чтобы выявить коренную причину проблемы.

Если предположить, что клиент отправил сброс, это будет означать, что уровень TCP клиента больше не распознает состояние TCP этого соединения — переход от установленного состояния к несуществующему. Это изменение состояния TCP уведомит клиентское приложение о проблеме с соединением, что приведет к немедленной ошибке в клиентском скрипте. Однако на самом деле клиентский скрипт все еще ждет ответа. Таким образом, предположение о том, что клиент отправил сброс, не является верным — клиент не отправил сброс. Соединение клиента все еще активно, но со стороны сервера соответствующее соединение было завершено сбросом.

Кто же отправил сброс? Основной подозреваемый — облачная среда Amazon. На основе этого анализа захвата пакетов операции DBA обратились в службу поддержки клиентов Amazon и получили следующую информацию:

Ответ службы поддержки соответствует результатам анализа, указывая на то, что ELB Amazon (Elastic Load Balancer, аналог LVS) принудительно завершил TCP-сессию. Согласно их обратной связи, если ответ превышает порог в 350 секунд (как наблюдалось в захвате пакетов как 630 секунд), устройство ELB Amazon отправляет сброс отвечающей стороне (в данном случае серверу). Клиентские скрипты, развернутые разработчиками, не получили сброс и ошибочно предположили, что соединение с сервером все еще активно. Официальные рекомендации для таких проблем включают использование механизмов TCP keepalive для смягчения этих проблем.

Получив официальный ответ, проблема была полностью решена.

Этот конкретный случай иллюстрирует, как онлайн-проблемы могут быть крайне сложными, требуя захвата критической информации — в данном случае данных захвата пакетов — для понимания ситуации, как это произошло. Через логическое рассуждение и применение редукции до нелепости была выявлена корневая причина.