Хотя название этой истории намного драматичнее действительных событий, я не думаю, или, точнее, надеюсь больше не иметь возможности использовать в заголовке вновь "Valentine's Day Massacre".
Это произошло в Валентинов день. Я получил сообщение, что один из вычислительных узлов больше не доступен в понимании этого в облаке,
$nova-manage service list
выдает для данного узла состояние XXX.
Я вошел в контроллер облака и смог выполнить и ping, и SSH к проблемному вычислительному узлу, что показалось очень странным. Обычно, если я получаю такой тип уведомления, вычислительный узел полностью блокирован и не доступен.
После нескольких минут поиска неисправностей я обнаружил следующие подробности:
-
В последнее время gользователь пытался запускать экземпляр CentOS на этом узле
-
Этот пользователь был единственным пользователем на данном узле (новый узел)
-
Нагрузка скакнула до 8 непосредственно перед получением мной данного предупреждения
-
Связанное 10гб сетевое устройство (bond0) находилось в состоянии DOWN
-
Сетевая плата 1гб все еще оставалась живой и активной
Я изучил состояние обоих сетевых адаптеров, соединенных в пару, и увидел, что ни один из них не был способен соединиться с портом коммутатора. Обнаружив, что каждый адаптер в связке подключен к отдельному коммутатору, я предположил, что вероятность отказа на каждом коммутаторе по порту в одно и то же время крайне маловероятна. Я решил, что двухпортовый 10гб сетевой адаптер скончался должен быть заменен. Я почувствовал, что мне повезло, что это был новый узел и никто еще не расположился на нем пока.
Через час я получил точно такое же сообщение, но теперь для другого узла. Хрень! Ну ладно, теперь совершенно понятно что существует какая-то проблема. Как и на первом узле, я смог войти через SSH. NIC bond0 находился в состоянии DOWN, но 1гб NIC был доступен.
И хорошая часть: тот же пользователь только что попытался создать экземпляр CentOS. Что-а?
В этом месте я оказался в полном замешательстве, так что написал нашим сетевому администратору просьбу, если это возможно, посмотреть чем он может мне помочь. Он подключился к обоим коммутаторам и сразу увидел проблему: коммутаторы обнаружили пакеты алгоритма связующего дерева (spanning tree), приходящие от двух вычислительных узлов и немедленно отключили эти порты чтобы предотвратить зацикливания алгоритма связующего дерева:
Feb 15 01:40:18 SW-1 Stp: %SPANTREE-4-BLOCK_BPDUGUARD: Received BPDU packet on Port-Channel35 with BPDU guard enabled. Disabling interface. (source mac fa:16:3e:24:e7:22) Feb 15 01:40:18 SW-1 Ebra: %ETH-4-ERRDISABLE: bpduguard error detected on Port-Channel35. Feb 15 01:40:18 SW-1 Mlag: %MLAG-4-INTF_INACTIVE_LOCAL: Local interface Port-Channel35 is link down. MLAG 35 is inactive. Feb 15 01:40:18 SW-1 Ebra: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-Channel35 (Server35), changed state to down Feb 15 01:40:19 SW-1 Stp: %SPANTREE-6-INTERFACE_DEL: Interface Port-Channel35 has been removed from instance MST0 Feb 15 01:40:19 SW-1 Ebra: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet35 (Server35), changed state to down
Он включил эти порты коммутаторов и два вычислительных узла немедленно вернулись к жизни.
К сожалению эта история пока не имеет завершения... мы все еще ищем почему образ CentOS посылал пакеты связующего дерева. Кроме того, мы тщательно исследовали как смягчить то что произошло. Это гораздо бОльшая проблема, чем можно было бы подумать. Хотя для коммутаторов крайне важно предотвращать зацикливания связующих деревьев, очень проблематично быть вынужденным отрезать целый вычилительный узел из сети при возникновении подобной ситуации. Если на вычислительном узле расположены 100 экземпляров и один из них посылает пакеты связующего дерева, получается, что этот экземпляр фактически DDOS-ит остальные 99 экземпляров.
Это продолжает оставаться горячей темой в сетевых кругах— в особенности с увеличением виртуализации и виртуальных коммутаторов.