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

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

Через несколько ночей это повторилось.

Мы просмотрели оба набора журналов. Единственная вещь, которая сильно выделялась, это был DHCP. В то время, как по умолчанию OpenStack устанавливает выделение DHCP на одну минуту, оно, в нашем случае, равнялось двум минутам. Это означало,что каждый экземпляр связывается с контроллером облака (сервером DHCP) для обновления своего фиксированного IP. По некой причине этот экземпляр не может обновить свой IP. Мы скоррелировали журналы экземпляра с журналами в контроллере облака и собрались вместе на обсуждение:

Имея на руках эту информацию, мы были уверены, что проблема должна быть связана с DHCP. Мы предположили, что по некой причине экземпляр не может получить новый IP адрес, а не имея IP, он отключает себя от сети.

Быстрый поиск в Google выводит следующее: DHCP lease errors in VLAN mode (ошибки выделения DHCP в режиме VLAN, https://lists.launchpad.net/openstack/msg11696.html), что еще больше укрепляет нашу теорию DHCP.

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

Мы решили иметь запущенный tcpdump на данном экземпляре и попробовать поймать проблему снова. Естественно, мы ее получили.

Вывод результатов tcpdump выглядел очень, очень странно. Короче говоря, это выглядело так, как будто сетевое взаимодействие прекращалось перед тем, как экземпляр пытался обновить свой IP. Поскольку при выделении на одну минуту существует очень много болтовни, очень трудно подтвердить эту гипотезу, однако, даже при разнице только в одну миллисекунду между пакетами, если один пакет приходит первым, он возникает первым, и если это пакет сообщает о сетевой проблеме, то это произойдет до DHCP.

Кроме того, данный экземпляр в обсуждаемом вопросе был ответственен за очень, очень большой объем работы резервного копирования каждую ночь. Вместе с тем, "Проблема" (как мы теперь начали ее называть) не произошла во время выполнения резервного копирования, хотя это время было достаточно близко (в пределах нескольких часов) и мы не могли игнорировать это.

Шли дни, и мы сталкивались с Проблемой снова и снова. Мы увидели, что dhclient не выполняется после возникновения Проблемы. Теперь мы вернулись, чтобы обдумать ее вопросы,связанные с DHCP. Выполнение перезапуска /etc/init.d/networking возвращает все назад и приводит в рабочее состояние.

Был ли у вас день, когда вы вдруг получает результаты Google поиска, которые вы ожидали найти? Ну, это то, что произошло. Я искал информацию о dhclient, а также о том, почему он умирает, когда не может возобновить ее выделение, и все: внезапно я нашел кучу OpenStack и dnsmasq обсуждений, которые были идентичны наблюдаемой нами проблеме!

Problem with Heavy Network IO and Dnsmasq (Проблема с нагруженным сетевым вводом/выводом и Dnsmasq, http://www.gossamer-threads.com/lists/openstack/operators/18197)

instances losing IP address while running, due to No DHCPOFFER (экземпляры теряют IP адрес во время работы вследствие No DHCPOFFER http://www.gossamer-threads.com/lists/openstack/dev/14696)

В самом деле, Google.

Вот это сообщение было ключом ко всему: KVM images lose connectivity with bridged network (образы KVM теряют связь с соединенными через мост сетями https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/997978)

Было забавно читать этот отчет. Присутствовало много людей, которые испытывали какую-то странную проблему в сети, но они не могли ее четко описать таким образом.

Итак, это было ошибкой qemu/kvm.

Одновременно с находкой четкого отчета о проблеме, наш коллега смог успешно воспроизвести Проблему! Как? Он воспользовался iperf выжимания тонны пропускной способности из экземпляра. В пределах 30 минут экземпляр просто пропал в сети.

Вооружившись исправленным qemu и способом воспроизведения ошибки, мы начали изучать смогли ли мы разрешить Проблему. После 48 часов прямого забивания экземпляра нагрузкой с высокой пропускной способностью мы были уверены в себе. Остальное история. Вы можете найти сообщение об ошибке для "joe", чтобы найти мои комментарии и фактические испытания.