Как мы спроектировали и реализовали новую сеть на Huawei в московском офисе, часть 3: серверная фабрика

В предыдущих двух частях (раз, два) мы рассмотрели принципы, на основе которых построена новая пользовательская фабрика, и рассказали про миграцию всех рабочих мест. Теперь пришла пора поговорить о серверной фабрике.

Раньше никакой отдельной серверной инфраструктуры у нас не было: серверные коммутаторы были подключены к тому же ядру, что и пользовательские коммутаторы распределения. Разграничение доступа осуществлялось с помощью виртуальных сетей (VLAN), маршрутизация VLAN производилась в одной точке — на ядре (по принципу Collapsed Backbone).

Старая сетевая инфраструктура

Одновременно с новой сетью офиса мы решили построить новую серверную, и для нее — отдельную новую фабрику. Она получилась небольшая (три серверных шкафа), но с соблюдением всех канонов: отдельное ядро на коммутаторах 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