Приветствую, и сперва немного лирики. Я иногда завидую коллегам, работающим удалённо — ведь это прекрасно иметь возможность работать из любого конца подключённого к Internet мира, каникулы в любое время, ответственность за проекты и дедлайны, а не нахождение в офисе с 8 до 17. Моя позиция и рабочие обязанности практически исключают возможность долгого отсутствия в датацентре. Однако — периодически случаются интересные кейсы, подобные описанному ниже — и я понимаю, что существует мало позиций, где есть такой простор для творческого выражения внутреннего troubleshooter'а.
Небольшой дисклеймер — на момент написания статьи кейс полностью не решен, но учитывая скорость ответа вендоров, полное решение может занять еще месяцы, а поделиться своими находками хочется уже сейчас. Надеюсь, уважаемые читатели, вы простите мне эту поспешность. Но довольно воды — что там с кейсом?
Сначала вводная: есть фирма (где я работаю сетевым инженером), которая хостит клиентские решения в приватном облаке VMWare. Большинство новых решений подключаются к VXLAN-сегментам, которые управляются NSX-V — не буду оценивать сколько времени мне подарило это решение, кратко говоря — много. Удалось даже обучить коллег настройке NSX ESG и небольшие клиентские решения разворачиваются без моего участия. Важное замечание — control plane у нас с unicast-репликацией. Гипервизоры подключены избыточно двумя интерфейсами к разным физическим коммутаторам Juniper QFX5100 (собранным в Virtual Chassis) и политикой тиминга route based on originating virtual port — это для полноты картины.
Клиентские решения очень разнородные: от Windows IIS, где все компоненты web-сервера установлены на одной машине до вполне больших — например load-balanced Apache веб-фронты + LB MariaDB в Galera + сервера-шары, синхронизированные с помощью GlusterFS. Практически каждый сервер надо мониторить отдельно, а публичные адреса есть не у всех компонентов — если вы сталкивались с этой задачей и имеете более изящное решение, буду рад совету.
Моё решение мониторинга состоит в «подключении» фаервола (Fortigate) к каждой внутренней клиентской сети (+SNAT и, конечно, жёсткие ограничения по типу разрешённого трафика) и наблюдение за внутренними адресами — таким образом достигается некая унификация и упрощение мониторинга. Сам мониторинг происходит из кластера серверов PRTG. Схема мониторинга примерно такая:
Пока мы оперировали только с VLAN всё было вполне обычно и предсказуемо работало, как часы. После внедрения NSX-V и VXLAN столкнулись с вопросом — а можно ли продолжать мониторинг по-старому? На момент этого вопроса самым «быстрым» решением было развернуть NSX ESG и подключить VXLAN trunk-интерфейс в VTEP сеть. Быстрым в кавычках — так как использовать GUI для настройки клиентских сетей, SNAT и правил фаервола может и унифицирует управление в едином интерфейсе vSphere, но по моему мнению довольно громоздкое и кроме всего прочего ограничивает набор инструментов для траблшутинга. Те, кто использовал NSX ESG как замену «настоящему» фаерволу, думаю, согласятся. Хотя, наверное, такое решение было бы более стабильным — ведь всё происходит в рамках одного вендора.
Еще одно решение — использовать NSX DLR в режиме бриджа между VLAN и VXLAN. Тут я думаю всё понятно — банально теряется выгода от применения VXLAN — ведь в этом случае всё-равно приходится тянуть VLAN к мониторинг-инсталляции. Кстати, в процессе отработки этого решения я столкнулся с проблемой, когда DLR-бридж не отсылал пакеты виртуалке с которой он находился на одном хосте. Знаю, знаю — в книгах и гайдах по NSX-V прямо сказано, что для NSX Edge должен быть выделен отдельный кластер, но это в книгах… Так или иначе, после пары месяцев с саппортом проблему мы не решили. В принципе логику действа я понял — модуль ядра гипервизора, ответственный за инкапсуляцию VXLAN не задействовался, если DLR и наблюдаемый сервер находились на одном хосте, так как трафик не покидает хост и по логике должен быть подключен к VXLAN сегменту — инкапсуляция не нужна. С саппортом мы остановились на виртуальном интерфейсе vdrPort, который логически объединяет аплинки и он же осуществляет бриджевание/инкапсуляцию — вот там было замечено несоответствие во входящем трафике, которое я взял на отработку в текущем кейсе. Но как было сказано, до конца я этот кейс не довёл, так как был переброшен на другой проект да и ветвь изначально тупиковая и желания её развивать особо не было. Если не ошибаюсь, проблема наблюдалась в версиях NSX и 6.1.4 и 6.2.
И тут — бинго! Fortinet аннонсирует нативную поддержку VXLAN. И не просто point-to-point или VXLAN-over-IPSec, не софтварный бриджинг VLAN-VXLAN — всё это начали внедрять еще с версии 5.4 (и представлено у других вендоров), а настоящую поддержку unicast control plane. При внедрении решения я столкнулся с еще одной проблемой — проверяемые сервера периодически то «пропадали» то появлялись в мониторинге, хотя сама виртуалка была жива. Причиной как оказалось было то, что я забыл разрешить Ping на VXLAN-интерфейсе. В процессе ребалансировки кластеров, виртуалки перемещались, а Ping'ом завершался vMotion, чтобы обозначить новый ESXI хост, на который переместилась машина. Глупость моя, но эта проблема еще раз подорвала доверие к саппорту производителся — в этом случае Fortinet. Я уж не говорю, что каждый кейс, связанный с VXLAN начинается с вопроса «а где у вас в настройках софтсвич VLAN-VXLAN?» В этот раз мне посоветовали изменить MTU — это для Ping'а, который 32 байта. Потом «поиграйся» с tcp-send-mss и tcp-receive-mss в полиси — для VXLAN, который инкапсулируется в UDP. Фуф, простите — накипело. В общем эту проблему решил своими силами.
Успешно откатав тестовый трафик, решено было внедрять это решение. И в продакшене выяснилось, что после дня-двух постепенно отваливаются вообще всё, что мониторится через VXLAN. Деактивация/активация интерфейса помогала, но только на время. Памятуя о неторопливости саппорта производителся, я занялся траблшутингом со своей стороны — в конце концов моя компания, моя сеть — моя ответственность.
Под спойлером ход траблшутинга. Кто устал от букв и бахвальства — пропускайте и переходите к постанализу.
fortigate (root) #diag sys vxlan fdb list vxlan-LS
mac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=у.у.у.47 port=4789 vni=5008 ifindex=7
fortigate (root) #get sys arp | grep у.у.у.47
у.у.у.47 0 00:50:56:65:f6:2c dmz
pktcap-uw --uplink vmnic1 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap
pktcap-uw --uplink vmnic4 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap
fortigate (root) #get sys arp | grep у.у.у.47
у.у.у.47 0 00:50:56:65:f6:2c dmz
fortigate (root) #get sys arp | grep у.у.у.42
у.у.у.42 0 00:50:56:6a:78:86 dmz
К сожалению, не доступен сервер mySQL