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

^[1]

В предыдущих сериях: «Джет» перешел на новую сеть на базе небезызвестного вендора. Как происходил процесс аудита систем, сбора «хотелок» и укрощения «заповедника мутантов» читайте в первой части ^[2].

В этот раз я расскажу о процессе миграции пользователей (более 1600 человек) со старой сети на новую. Всех заинтересовавшихся приглашаю под кат.

Итак, существующая сеть компании по состоянию на прошлое лето:

• простейшая топология «collapsed backbone» — ядро сети (оно же уровень распределения) образовано двумя коммутаторами сетевого уровня, объединёнными в VSS-кластер;
• уровень доступа представлен коммутаторами и стеками коммутаторов канального уровня, установленными в кроссовых, а иногда и непосредственно в коридорах и даже в рабочих помещениях;
• часть коммутаторов доступа включена в цепочку, т. е. коммутатор включен в другой коммутатор, а последний — уже в ядро;
• отказоустойчивость подключения коммутаторов доступа к ядру обеспечивается в основном посредством LACP, иногда — никак не обеспечивается;
• разграничение доступа — посредством VLAN, маршрутизация VLAN — на ядре;
• используются коммутаторы доступа трёх производителей и четырёх поколений, подключение пользователей осуществляется на скорости от 100 Мбит/с до 1 Гбит/с;
• некоторые пользователи всё ещё применяют аналоговые телефоны, некоторые — IP-телефоны, подключенные через PoE-инжекторы, у меньшинства — IP-телефоны, получающие питание по PoE от коммутаторов доступа.

Задача:

• привести сеть в приличный вид;
• не нарушить в ходе модернизации работу сотрудников;
• исправить максимально возможное количество проблем, накопившихся за предыдущие 15 лет эксплуатации.

Прежняя жизнь

Ранее система эксплуатации и расширения сети в офисе была следующей: предположим, что нам необходимо организовать рабочие места для новых сотрудников. В бизнес-центре арендовались дополнительные площади, делался ремонт, прокладывалась СКС, после чего развертывались компьютерная и телефонная сеть.

На одно рабочее место приходилось, в зависимости от потребностей подразделения, от 2 до 4 розеток RJ-45. Одна из розеток назначалась телефонной (получала зеленую маркировку), остальные (от одной до трёх) назначались компьютерными (получали синюю маркировку).

Розетки на типовом рабочем месте

Каждая компьютерная розетка еще на этапе строительства сети соединялась с отдельным портом коммутатора доступа, каждая телефонная розетка — с аналоговым портом телефонной станции (в старых помещениях) или с портом коммутатора доступа, предварительно настроенным для передачи данных VoIP (в новых помещениях).

Такая схема была удобной для службы эксплуатации. Пользователи переезжали в новое помещение, подключали компьютер в любую свободную компьютерную розетку, телефон — в любую свободную телефонную розетку.

После этого сотрудники службы технической поддержки, ориентируясь на MAC-адреса подключенного оборудования, прописывали на портах коммутаторов доступа необходимые VLAN-ы и другие параметры.

Но у подхода был свой недостаток — он был неэкономичным, до половины портов оставались неиспользованными. Такой резерв полезен, если с течением времени в помещении организуются дополнительные рабочие места, но резерв в 50% нам до конца не удалось использовать ни разу.

Подготовка к миграции

На первом этапе мы решили заменить все коммутаторы доступа. В качестве стандартной была выбрана модель семейства Huawei S5720 ^[3], конкретно S5720-52X-PWR-SI-AC. Ее характеристики:

• подключается к магистрали на скорости 10 Гбит/с;
• объединяется в стек по обычным интерфейсам 10G;
• допускает подключение ко всем пользовательским портам на скорости 1 Гбит/с;
• предоставляет на всех пользовательских портах питание по PoE.

Таким образом, к любому порту допускается подключение компьютера, IP-телефона, компьютера через IP-телефон, точки беспроводного доступа, камеры видеонаблюдения и других устройств.
Нам пришлось выяснить, какие розетки в помещениях реально используются и что к ним подключено. У нас были:

• данные старых и не очень старых проектов прокладки СКС;
• «не совсем актуальные» кабельные журналы по всем помещениям компании;
• таблицы MAC-адресов на существующих коммутаторах доступа, которые мы получили с помощью встроенных средств сетевого оборудования;
• таблицы соответствия MAC-адресов телефонных аппаратов и внутренних номеров абонентов — с телефонной станции.

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

• помещение;
• маркировка порта на рабочем месте;
• маркировка розетки на коммутационной панели в кроссовой;
• имя (hostname) старого коммутатора (стека);
• номер порта на старом коммутаторе;
• VLAN ID;
• MAC-адрес подключенного устройства (или несколько);
• тип подключенного устройства (определялся по MAC-адресу);
• имя (hostname) нового коммутатора (стека);
• номер порта на новом коммутаторе.

Результаты работы скрипта

По такой таблице сразу было видно, что именно подключено к конкретному порту — компьютер, телефон, компьютер через телефон (если MAC-адресов два), или же нечто более сложное.
На основе таблиц инженеры-проектировщики разрабатывали новые кабельные журналы, а инженеры внедрения предварительно настраивали новые коммутаторы, которые при очередном этапе миграции устанавливались в кроссовые взамен старых.

Фрагмент нового кроссового журнала

Настройки порта доступа

Таким образом, работы сводились к следующему:

• отключить старые коммутаторы доступа, удалить патч-корды;
• установить новые коммутаторы доступа, подключить питание;
• выполнить коммутации по кроссовому журналу;
• обойти рабочие помещения, убедиться, что телефоны и компьютеры работают нормально.

Выглядит просто, но…

Первый этап — замена коммутаторов доступа: три месяца работы без выходных

С середины 2018 года мы три месяца каждые выходные заменяли коммутаторы доступа и делали перекоммутацию рабочих мест по нашим таблицам миграций (всего около 3500 портов).
Первая миграция заняла у нас больше 12 часов, мы успели за это время заменить один стек доступа из пяти коммутаторов и перекоммутировать примерно 200 портов, подключенных к нему.
Больше всего времени занимала… подготовка патч-кордов. Каждый патч-корд нужно было освободить от упаковки и наклеить с двух сторон бирки с номером. Только после этого патч-корд можно было использовать для коммутации.

При следующих миграциях мы оптимизировали процесс, и готовили патч-корды заранее. Поэтому последняя миграция заняла те же 12 часов, и мы успели за это время заменить пять стеков доступа, от 3 до 5 коммутаторов в каждом, и перекоммутировать более 1000 портов.

Что мы получили в итоге?

Во-первых, актуализированный кроссовый журнал, которым мы поделились со службой эксплуатации. Служба разработала собственное веб-приложение для поддержки актуального состояния коммутации — с ним теперь всегда можно ознакомиться с на внутреннем ресурсе.

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

В-третьих, мы выключили все неиспользуемые порты активного оборудования и настроили функцию port security. Параллельно мы сформулировали, согласовали и утвердили регламент о подключениях, теперь никаких подключений «мимо кассы».

Таким образом, мы:

• привели в порядок и задокументировали все подключения оборудования офиса;
• избавились от старых коммутаторов, PoE-инжекторов, аналоговых телефонов;
• снизили энергопотребление оборудования (по отдельным кроссовым и рабочим помещениям — до 30%);
• повысили удобство работы пользователей и сохранили разумно-достаточный резерв портов активного оборудования (ценой некоторого увеличения загруженности специалистов технической поддержки, особенно при переездах сотрудников в новые помещения).

Миграция в разгаре — переключение на новую магистраль

После завершения первого этапа у нас нормализовалась ситуация с пользовательскими подключениями, но с магистралью ничего не поменялось. Как было сказано выше, до модернизации она была устроена достаточно просто. Имелось около 100 VLAN, которые маршрутизировались на центральном коммутаторе, вернее, на двух коммутаторах, объединённых в кластер по технологии VSS.

Параллельно с первым этапом миграции мы строили и тестировали новую магистраль в соответствии с принципами, изложенными в первой статье ^[2]:

• установили коммутаторы ядра Huawei CE8850;
• установили коммутаторы распределения Huawei CE6870;
• проложили дополнительные ВОЛС;
• выполнили все соединения;
• настроили протоколы маршрутизации overlay и underlay (но пока не завершился первый этап, коммутаторы простаивали и грели воздух).

Далее начался следующий этап миграции. Не очень длительный, но самый сложный.

Для начала мы разработали и согласовали новый план IP-адресации, учитывающий наши текущие и перспективные потребности. В новом плане выделили отдельные диапазоны под все запланированные L3VPN-ы — для обычных пользователей и пользователей технического центра, для систем телефонии, видеоконференцсвязи, камер видеонаблюдения, демонстрационных стендов разных типов и других нужд.

Затем мы подключили всю старую сеть к одной паре коммутаторов распределения на правах единого стека доступа. После этого мы приступили к переключению стеков на новую магистраль с изменением номеров VLAN-ов и, соответственно, с изменением IP-адресов подключаемых пользователей на новые диапазоны.

Мы планировали работы так, чтобы за один раз переключить достаточно большую группу коммутаторов доступа. Работали или ночью, или в выходные, в зависимости от специфики работы переключаемых подразделений.

Перед началом работ мы заранее выполняли следующие операции:

1. настраивали корпоративный DHCP-сервер так, чтобы он выдавал для переключаемых пользователей IP-адреса из нового диапазона;
2. настраивали порты на коммутаторах распределения, в которые планировалось включать коммутаторы доступа при миграции;
3. с помощью ещё одного специально разработанного скрипта готовили измененные конфигурации для переключаемых коммутаторов.

Работали в следующем порядке:

1. переключали коммутаторы доступа со старой магистрали на новую;
2. убеждались, что коммутаторы доступны по управляющему интерфейсу;
3. заливали на переключенные коммутаторы заранее подготовленную конфигурацию для изменения номеров VLAN-ов.

Перед выполнением перечисленных работ VLAN, содержащий управляющие интерфейсы всех коммутаторов доступа, был «растянут» между старой и новой магистралью, поэтому шаг 2 обычно занимал минимум времени. В самом простом случае пользовательские рабочие станции (а также телефоны, принтеры и другие устройства) сразу получали от DHCP-сервера IP-адреса из нового диапазона и продолжали работать без изменений.

Куда же без проблем?

На этом пути нам встретилось несколько трудностей.
Во-первых, у многих пользователей переставали работать принтеры. На рабочих станциях некоторых пользователей доступ к принтерам был настроен по конкретному IP-адресу. После переключения принтеров на новый диапазон они получили и новые адреса, а пользователи потеряли к ним доступ. Для решения проблемы на следующий день после миграции мы на половину рабочего дня выделяли одного специалиста поддержки, чтобы он обошел пользователей, которые подверглись миграции, и перенастроил принтеры на использование не IP-адресов, а DNS-имен.

При миграции самой первой группы пользователей нам пришлось решить некоторые проблемы с корректной настройкой межсетевых экранов, чтобы они пускали переехавших пользователей на необходимые корпоративные ресурсы. И при всех последующих миграциях мы уже заранее знали, что необходимо настраивать.

В последнюю очередь мы перемещали сервисный центр, а именно сотрудников дежурной смены. Дежурная смена должна работать непрерывно и круглосуточно, всегда иметь доступ к ресурсам, нужным для работы, и к информационным системам заказчиков. Для этих людей мы организовали временные рабочие места в заранее согласованное время и в отдельных помещениях. Один сотрудник дежурной смены переходил в это помещение, убеждался, что он может получить доступ ко всем нужным системам. После чего в это помещение переходили остальные.

Затем мы проводили миграцию соответствующего подразделения, приглашали одного из сотрудников дежурной смены вернуться на своё место обратно и проверить доступность всех необходимых ресурсов. Оперативно устраняли проблемы, если таковые обнаруживались. Проблем было мало. После этого дежурная смена снова перебиралась из «временного убежища» к обычному режиму работы на своих рабочих местах со всем набором нужных им информационных систем.

В какой-то момент мы обнаружили, что в старой сети не осталось ни одного пользовательского рабочего места! И открыли шампанское. Далее мы приступили к миграции серверного сегмента. К нему применили уже другую схему, поскольку сервер обычно нельзя останавливать даже на 15 минут. Об этом я отдельно расскажу в следующей статье.

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

Автор: Максим Клочков

Источник ^[4]