Хабрахабр

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

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


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

Она получилась небольшая (три серверных шкафа), но с соблюдением всех канонов: отдельное ядро на коммутаторах CE8850, полносвязная (spine-leaf) топология, top of the rack (ToR)-коммутаторы CE6870, отдельная пара коммутаторов для сопряжения с остальной сетью (border leaves). Одновременно с новой сетью офиса мы решили построить новую серверную, и для нее — отдельную новую фабрику. Короче, полный фарш.


Сеть новой серверной фабрики

Почему? Мы решили отказаться от серверной СКС в пользу подключения серверов непосредственно в ToR-коммутаторы. У нас уже есть две серверные, которые построены с применением серверной СКС, и мы поняли, что это:

  • неудобно в эксплуатации (много перекоммутаций, нужно аккуратно обновлять кабельный журнал);
  • накладно с точки зрения места, занимаемого коммутационными панелями;
  • является препятствием при необходимости увеличить скорость подключения серверов (например, перейти с подключений 1 Гбит/с по меди на 10 Гбит/с по оптике).

При переходе на новую серверную фабрику мы постарались уйти от подключения серверов на скорости 1 Гбит/с и ограничились 10-гигабитными интерфейсами. Виртуализировали почти все старые серверы, которые так не умеют, а остальные через гигабитные трансиверы подключили в 10-гигабитные порты. Мы посчитали и решили, что это будет дешевле, чем ставить для них отдельные гигабитные коммутаторы.


Коммутаторы ToR

Эта идея оказалась очень хорошей, вот только портов оказалось маловато, в следующий раз установим коммутаторы OOM на 48 портов. Также в нашей новой серверной мы установили отдельные коммутаторы out-of-band management (OOM) на 24 порта, по одному на стойку.

Если сервер потерял основное соединение с сетью, то достучаться до него можно будет по такому интерфейсу. В сеть OOM у нас подключаются интерфейсы удалённого управления серверами типа iLO, или iBMC по терминологии Huawei. Сеть OOM доступна через отдельный интерфейс межсетевых экранов. Также в коммутаторы OOM подключаются управляющие интерфейсы коммутаторов ToR, датчики температуры, управляющие интерфейсы ИБП и другие подобные устройства.


Подключение сети 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


Миграция виртуальных машин

5) на новые (версии 6. Затем с помощью VMware vMotion мигрировали виртуальные машины в этом VLAN со старых гипервизоров (версии 5. Попутно виртуализировали аппаратные серверы. 5).

Когда попытаетесь повторить

Заранее настройте MTU и проверьте прохождение больших пакетов «end to end».

В старой серверной сети мы пользовались виртуальным МЭ VMware vShield. Поскольку компания VMware больше не поддерживает этот инструмент, то одновременно с миграцией на новую виртуальную ферму мы перешли с vShield на аппаратные межсетевые экраны.

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


Переключение маршрутизации

е. После переключения маршрутизации для определенного VLAN он отключался от bridge-домена и исключался из транка между старой и новой сетью, т. Таким образом мы мигрировали около 20 VLAN. полностью переходил в новую серверную фабрику.

В одной из следующих статей мы расскажем о том, что сделали с Wi-Fi. Так мы создали новую сеть, новую серверную и новую ферму виртуализации.

Максим Клочков
Старший консультант группы сетевого аудита и комплексных проектов
Центра сетевых решений
«Инфосистемы Джет»

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть