Network-as-a-Service для крупного предприятия: нестандартный кейс

8b8d30e7f246c1b2638c2f659904928c.png


Как обновить сетевое оборудование на крупном предприятии без остановки производства? О масштабном проекте в режиме «операции на открытом сердце» рассказывает менеджер по управлению проектами Linxdatacenter Олег Федоров. 
В последние несколько лет мы отмечаем повышенный спрос заказчиков на услуги, связанные с сетевым компонентом ИТ-инфраструктуры. Потребность в связности ИТ-систем, сервисов, приложений, задачи мониторинга и операционного управления бизнесом практически в любой сфере вынуждают сегодня компании уделять сетям повышенное внимание.  

Диапазон запросов — от обеспечения отказоустойчивости сети до создания и управления клиентской автономной системой с приобретением блока IP-адресов, настройкой протоколов маршрутизации и управлением трафиком согласно политикам организаций.

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

Данный тренд по времени совпал с периодом развития и усложнения собственной сетевой инфраструктуры Linxdatacenter. Мы расширили географию своего присутствия в Европе за счет подключения к удаленным площадкам, что в свою очередь потребовало и совершенствования инфраструктуры сети. 

Компания запустила новый сервис для клиентов, Network-as-a-Service: решение всех сетевых задач клиентов мы берем на себя, позволяя им сосредоточиться на основном бизнесе.

Летом 2020 года завершился первый большой проект в этом направлении, о котором хотелось бы рассказать. 

На старте 

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

Последняя модернизация оборудования на предприятии проходила около 10 лет назад. Новое руководство предприятия решило улучшить связность, начав с обновления инфраструктуры на самом базовом, физическом уровне. 

Проект был разделен на две части: апгрейд серверного парка и сетевого оборудования. Мы отвечали за вторую часть. 

Базовые требования к работам включали в себя минимизирование простоев производственных линий предприятия во время выполнения работ (а на некоторых участках и полное исключение простоев). Любая остановка — прямые денежные потери клиента, чего не должно было произойти ни при каких обстоятельствах. В связи с режимом работы объекта 24×7х365, а также с учетом полного отсутствия периодов плановых простоев в практике предприятия, перед нами была поставлена задача, по сути, выполнить операцию на открытом сердце. Это и стало главной отличительной чертой проекта.

Поехали

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

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

Необходимо не только заменить узлы и провода в сети, но и правильно сконфигурировать все компоненты для корректной работы решения в целом. Именно конфигурации и проверялись таким образом: начиная работы в удалении от ядра, мы как бы давали себе «право на ошибку», не подвергая риску критически важные для работы предприятия участки. 

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

Работы были разделены на несколько этапов.

Этап 1 — Аудит. Подготовка и согласование подхода к планированию работ и оценка готовности команд: клиента, подрядчика, выполняющего монтаж, и нашей команды.

Этап 2 — Разработка формата для проведения работ, с глубоким детальным анализом и планированием. Выбрали формат чек-листа с точным указанием порядка и последовательности действий, вплоть до последовательности переключения патч-кордов по портам.

Этап 3 — Проведение работ в шкафах, не влияющих на производство. Оценка и корректировка времени простоя для последующих этапов работ.

Этап 4 — Проведение работ в шкафах, напрямую влияющих на производство. Оценка и корректировка времени простоя для финального этапа работ.

Этап 5 — Проведение работ в серверной по переключению оставшегося оборудования. Запуск на маршрутизации на новом ядре.

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

Прическа бороды проводов

Проект оказался непростым еще и из-за сложных исходных условий. 

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

Выглядело это примерно так:

467ae023d558d405a7d84a21e240104b.jpg


так:

0795fd09d46a83bcd4c557dfbfbd2658.jpg


или так:  

f8ead77e03ebc8f658facb690ea3f3da.jpg


Во-вторых, для каждой подобной задачи необходимо было подготовить файл с описанием процесса. «Берем провод Х из порта 1 старого оборудования, втыкаем его в порт 18 нового оборудования». Звучит просто, но когда у тебя в исходных данных 48 полностью забитых портов, а также отсутствует опция простоя (мы помним про 24×7х365), единственный выход — работать по блокам. Чем больше можно вытащить проводов из старого оборудования за один раз, тем быстрее можно их причесать и вставить в новое сетевое «железо», избежав сбоев и простоев в работе сети. 

Поэтому на подготовительном этапе мы провели разбивку сети по блокам — каждый из них относился к определенному VLAN. Каждый порт (или их подмножество) на старом оборудовании — это какой-то из VLAN в новой топологии сети. Мы сгруппировали их так: в первых портах коммутатора разместились пользовательские сети, в середине — производственные сети, а в последних — точки доступа и аплинки. 

Такой подход позволил за один прием вытаскивать и причесывать из старого оборудования не 1 провод, а 10–15. Это в несколько раз ускорило рабочий процесс.  

Кстати, вот как выглядят провода в шкафах после причесывания:  

1c196776d8452800e92bfd7ec848400c.jpg


или, например, так:  

e8198a1814790a10d298a8b7f36675bf.jpg


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

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

Однако предварительное планирование и разбивка проекта на блоки позволили уложиться в запланированное время простоя на всех участках, а в большинстве случаев и вовсе обойтись без него. 

Вызов времени — проект под COVID-ом 

Без дополнительных сложностей, тем не менее, не обошлось. Конечно, в качестве одного из препятствий выступил коронавирус. 

Работы осложнились тем, что началась пандемия, и невозможно было присутствовать во время проведения работ на площадке клиента всем специалистам, задействованным в процессе. На площадку были допущены только сотрудники монтажной организации, а контроль осуществлялся через комнату в Zoom — в ней находились сетевой инженер со стороны Linxdatacenter, я как руководитель проекта,  сетевой инженер со стороны клиента, ответственный за производство работ, и команда, выполняющая монтажные работы.

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

Хотя дистанционный формат работы и казался непривычным в начале проекта, мы довольно быстро приспособились к новым условиям и вышли на финальный этап работ. 

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

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

А в результате

Технические итоги проекта 

Прежде всего, было создано новое ядро новой сети предприятия, для чего мы построили физические/логические кольца. Сделано это таким образом, чтобы у каждого коммутатора в сети появилось «второе плечо». В старой сети многие коммутаторы подсоединялись к ядру по одной трассе, одним плечом (аплинком). Если он рвался, коммутатор становился полностью недоступен. А если через один аплинк подключалось несколько коммутаторов, то авария выводила из строя целый отдел или производственную линию на предприятии. 

В новой сети даже довольно серьезной сетевой инцидент ни при каком сценарии не сможет «положить» всю сеть или значимый ее участок. 

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

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

Схема сети

0c8237f3d32f850456e83f0ad038491a.jpg


Самый главный итог в техническом отношении: достаточно масштабные инфраструктурные работы были проведены быстро, не создавая никаких помех в работе предприятия и практически незаметно для его персонала. 

Бизнес-итоги проекта

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

Успех проекта позволяет говорить о том, что наша инициатива по развитию сетевого направления в рамках портфеля сервисов Linxdatacenter — верный выбор вектора развития компании. Ответственный подход к управлению проектами, грамотная стратегия, четкое планирование позволили нам выполнить работу на должном уровне. 

Подтверждение качества работы — запрос от клиента на продолжение оказания услуг по модернизации сети на его остальных площадках в России.

© Habrahabr.ru