Хабрахабр

Как мы спроектировали и реализовали новую сеть на Huawei в московском офисе, часть 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, конкретно 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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