В предыдущих двух частях (, ) мы рассмотрели принципы, на основе которых построена новая пользовательская фабрика, и рассказали про миграцию всех рабочих мест. Теперь пришла пора поговорить о серверной фабрике.
Раньше никакой отдельной серверной инфраструктуры у нас не было: серверные коммутаторы были подключены к тому же ядру, что и пользовательские коммутаторы распределения. Разграничение доступа осуществлялось с помощью виртуальных сетей (VLAN), маршрутизация VLAN производилась в одной точке — на ядре (по принципу ).
Старая сетевая инфраструктура
Одновременно с новой сетью офиса мы решили построить новую серверную, и для нее — отдельную новую фабрику. Она получилась небольшая (три серверных шкафа), но с соблюдением всех канонов: отдельное ядро на коммутаторах CE8850, полносвязная (spine-leaf) топология, top of the rack (ToR)-коммутаторы CE6870, отдельная пара коммутаторов для сопряжения с остальной сетью (border leaves). Короче, полный фарш.
Сеть новой серверной фабрики
Мы решили отказаться от серверной СКС в пользу подключения серверов непосредственно в ToR-коммутаторы. Почему? У нас уже есть две серверные, которые построены с применением серверной СКС, и мы поняли, что это:
- неудобно в эксплуатации (много перекоммутаций, нужно аккуратно обновлять кабельный журнал);
- накладно с точки зрения места, занимаемого коммутационными панелями;
- является препятствием при необходимости увеличить скорость подключения серверов (например, перейти с подключений 1 Гбит/с по меди на 10 Гбит/с по оптике).
При переходе на новую серверную фабрику мы постарались уйти от подключения серверов на скорости 1 Гбит/с и ограничились 10-гигабитными интерфейсами. Виртуализировали почти все старые серверы, которые так не умеют, а остальные через гигабитные трансиверы подключили в 10-гигабитные порты. Мы посчитали и решили, что это будет дешевле, чем ставить для них отдельные гигабитные коммутаторы.
Коммутаторы ToR
Также в нашей новой серверной мы установили отдельные коммутаторы out-of-band management (OOM) на 24 порта, по одному на стойку. Эта идея оказалась очень хорошей, вот только портов оказалось маловато, в следующий раз установим коммутаторы OOM на 48 портов.
В сеть OOM у нас подключаются интерфейсы удалённого управления серверами типа iLO, или iBMC по терминологии Huawei. Если сервер потерял основное соединение с сетью, то достучаться до него можно будет по такому интерфейсу. Также в коммутаторы OOM подключаются управляющие интерфейсы коммутаторов ToR, датчики температуры, управляющие интерфейсы ИБП и другие подобные устройства. Сеть OOM доступна через отдельный интерфейс межсетевых экранов.
Подключение сети OOM
Сопряжение серверной и пользовательской сетей
В пользовательской фабрике для разных целей используются отдельные VRF — для подключения рабочих мест пользователей, систем видеонаблюдения, мультимедийных систем в переговорных, для организации стендов и демозон, и т. п.
В серверной фабрике создан другой набор VRF:
- Для подключения обычных серверов, на которых развернуты корпоративные сервисы.
- Отдельный VRF, в рамках которого развёртываются серверы с доступом из интернета.
- Отдельный VRF для серверов баз данных, к которым обращаться только другие серверы (например, серверы приложений).
- Отдельный VRF под нашу почтовую систему (MS Exchange + Skype for Business).
Таким образом, у нас есть набор VRF со стороны пользовательской фабрики и набор VRF со стороны серверной фабрики. Оба набора заведены на кластеры корпоративных межсетевых экранов (МЭ). МЭ подключены к пограничным коммутаторам (border leaves) как серверной фабрики, так и пользовательской фабрики.
Сопряжение фабрик через МЭ — физика
Сопряжение фабрик через МЭ — логика
Как проходила миграция
В ходе миграции мы соединили новую и старую серверные фабрики на канальном уровне, через временные транки. Для миграции серверов, расположенных в определенном VLAN, мы создавали отдельный bridge-домен, в который включали VLAN старой серверной фабрики и VXLAN новой серверной фабрики.
Конфигурация выглядит примерно так, ключевыми являются две последние строки:
bridge-domain 22
vxlan vni 600022
evpn
route-distinguisher 10.xxx.xxx.xxx:60022
vpn-target 6xxxx:60022 export-extcommunity
vpn-target 6xxxx:60022 import-extcommunity
interface Eth-Trunk1
mode lacp-static
dfs-group 1 m-lag 1
interface Eth-Trunk1.1022 mode l2
encapsulation dot1q vid 22
bridge-domain 22
Миграция виртуальных машин
Затем с помощью VMware vMotion мигрировали виртуальные машины в этом VLAN со старых гипервизоров (версии 5.5) на новые (версии 6.5). Попутно виртуализировали аппаратные серверы.
Когда попытаетесь повторитьЗаранее настройте MTU и проверьте прохождение больших пакетов «end to end».
В старой серверной сети мы пользовались виртуальным МЭ VMware vShield. Поскольку компания VMware больше не поддерживает этот инструмент, то одновременно с миграцией на новую виртуальную ферму мы перешли с vShield на аппаратные межсетевые экраны.
После того, как в конкретном VLAN в старой сети не оставалось ни одного сервера, мы переключали маршрутизацию. Раньше она осуществлялась на старом ядре, построенном по технологии Collapsed Backbone, а в новой серверной фабрике мы использовали технологию Anycast Gateway.
Переключение маршрутизации
После переключения маршрутизации для определенного VLAN он отключался от bridge-домена и исключался из транка между старой и новой сетью, т. е. полностью переходил в новую серверную фабрику. Таким образом мы мигрировали около 20 VLAN.
Так мы создали новую сеть, новую серверную и новую ферму виртуализации. В одной из следующих статей мы расскажем о том, что сделали с Wi-Fi.
Максим Клочков
Старший консультант группы сетевого аудита и комплексных проектов
Центра сетевых решений
«Инфосистемы Джет»
Источник: habr.com