И снова здравствуйте. Постоянные читатели знают, что большинство здешних заметок рождается из реальных задач или болей, которые вылезают в процессе работы. Этот раз – не исключение, поговорим об идеологии архитектуры виртуальной среды. У меня ESXi, поэтому речь будет именно про него.
Для начала – о том, как делать НЕ надо. Точнее о проблемах, которые появляются при несистемном построении системы. Я прям даже не знаю, из откуда начать…
1) Есть хост ESX, у которого 4 гигабитных порта на борту. Поскольку на нем живут виртуалки, которые в прыжке могут потреблять довольно большой поток трафика, на хосте завели 4 виртуальных свитча и виртуалки как-то между ними распределили. Разумеется, всё это воткнуто разными линками в один свитч. Вроде бы всё работает, но виртуальная среда – живая и виртуалки время от времени меняются, но за распределением их по разным свитчам никто не следит. В результате бывают лаги в сети, когда толпа виртуалок выжирает один гигабитный канал, а остальные практически простаивают.
2) Кто-то скажет, что можно же к виртуальному свитчу добавить несколько аплинков. Оно всё, конечно, так, но второй (третий и далее) аплинк не заработает, пока первые не сдохнут. И обратно, кстати, переключение не работает. Так что не получится, к примеру, добавить карточку 10G и поставить её первым аплинком, а просто гигабит – вторым. Сервер после сбоя и восстановления линка на 10G просто не переключится обратно.
3) 4) Есть еще пара ESX’ов и там тоже по 4 гигабитных порта. На одном хосте когда-то была заведена изолированная сеть чисто для общения виртуалок между собой. Вот только этот vSwitch был мало того, что зачем-то подключен к физическому порту, но оттуда на второй хост был прокинут провод тоже в отдельный порт. И всё бы ничего, но ресурсы не резиновые и понадобилась ещё одна виртуалка с доступом в эту самую внутреннюю сеть. Что сделали? Правильно – прицепили специальный vSwitch на втором хосте к тому самому порту и подняли виртуалку на втором хосте. Вот только теперь мы жестко привязаны к конкретным хостам и не можем сделать ни шага в сторону.
4) 5) Есть тестовая среда, она маленькая и арендует уголок на одном из ESX’ов наряду с боевыми виртулаками. Для тестовой среды выделен отдельный vSwitch с отдельным физическим портом, отдельная адресация, даже какие-то ACL’ы в туда прописаны. НО! Всё это воткнуто всё в тот же свитч с локалкой, а на роутере просто заведен отдельный адрес на интерфейсе с локальной сетью. Как следствие – изоляция даже не на бумаге, чисто в умах. Плюс, роутер почему-то не очень хорошо отрабатывает маршрутизацию между двумя адресами на одном интерфейсе – временами чего-то отваливается или теряется.
5) А ведь есть еще вопросы изоляции сетей. И таких сетей на хосте может потенциально быть больше, чем физических портов. Пример? Пусть будет тестовая среда с доступом в свою сеть, прод с доступом к локалке и интерфейс управления ESX’ом. Сетей надо три, а физических карточек две…
6) Есть vCenter, но на каждом хосте ESX свои виртуальные коммутаторы. Как следствие, миграция виртуалок между хостами требует не забыть правильно расставить подключение виртуальных сетевых карт.
Решение, на самом деле простое и закрывает все перечисленные вопросы разом – единые vSwitch на весь vCenter + LACP + VLAN. Настройка всего этого добра, конечно же, будет не в три клика мыши, но и некультурно сложным не является.