{"id":14291,"url":"\/distributions\/14291\/click?bit=1&hash=257d5375fbb462be671b713a7a4184bd5d4f9c6ce46e0d204104db0e88eadadd","hash":"257d5375fbb462be671b713a7a4184bd5d4f9c6ce46e0d204104db0e88eadadd","title":"\u0420\u0435\u043a\u043b\u0430\u043c\u0430 \u043d\u0430 Ozon \u0434\u043b\u044f \u0442\u0435\u0445, \u043a\u0442\u043e \u043d\u0438\u0447\u0435\u0433\u043e \u0442\u0430\u043c \u043d\u0435 \u043f\u0440\u043e\u0434\u0430\u0451\u0442","buttonText":"","imageUuid":""}

Распутать сеть

Как заменить всю сетевую инфраструктуру крупного предприятия в нынешних условиях, не прерывая его работы?

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

Запутанное дело

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

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

Работы по проекту были разделены на два основных направления: апгрейд серверного парка и модернизация сетевого оборудования. Мы отвечали за вторую часть. Основное требование со стороны заказчика – минимизация простоев производства во время выполнения работ. Где-то простои не допускались вовсе.

Наш проект по замене оборудования, линий коммуникаций и настройке готового решения в чем-то напоминал операцию на открытом сердце: объект работал в режиме 24х7х365, без каких-либо плановых простоев.

Постепенно и аккуратно

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

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

С началом работ мы прежде всего определили зоны, активность в которых никак не влияет на критические участки предприятия (цеха, погрузочно-разгрузочный блок, склады и т. д.). Что касается работ, потенциально затрагивающих непрерывность производства, то с заказчиком было согласовано допустимое время простоя для каждого узла сети: от 1 до 15 минут.

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

Все работы были разделены на шесть этапов:

1) Аудит текущего состояния сети. Включает в себя подготовку и планирование работ, оценку готовности команд на стороне клиента и подрядчика, выполняющего монтаж.

2) Выбор формата проведения работ с глубоким анализом и детальным планированием. На этом проекте мы выбрали формат чек-листа с точным указанием порядка и последовательности действий.

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

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

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

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

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

К делу

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

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

Например, типичная «борода» выглядела так:

Или так:

Или даже так:

Каждая такая задача требовала описания процесса, буквально «Берем провод Х из порта 1 старого оборудования, втыкаем его в порт 18 нового оборудования».

Это только звучит просто, на самом же деле, когда у вас 48 полностью забитых портов и нет опции простоя критических узлов, единственный выход – работать по блокам. Чем больше можно вытащить проводов из старого оборудования за один раз, тем быстрее можно их «причесать» и переключить на новое сетевое «железо».

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

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

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

Согласитесь, приятно посмотреть. А также гораздо легче осуществлять поддержку сети после наведения порядка на этом уровне.

Аналитическая пауза

По завершении второго этапа последовала аналитическая пауза: разбирали ошибки и оценивали общую динамику реализации проекта.

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

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

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

Вызовы и ошибки

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

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

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

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

Технические итоги

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

В старой сети многие коммутаторы подсоединялись к ядру по одной трассе, одним плечом (аплинком). Если он рвался, коммутатор становился недоступен. А если через один аплинк подключалось несколько коммутаторов, то авария выводила из строя целый отдел или производственную линию на предприятии.

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

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

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

Схема сети

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

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

0
20 комментариев
Написать комментарий...
Павел Житнюк

"В теории и на бумаге все это выглядело логично, последовательно и выполнимо. На практике же проект оказался крайне непростым из-за сложных условий." - вот это просто в граните высечено:-) про любой крупный ИТ проект можно так сказать. Гладко было на бумаге, да забыли про овраги. Молодцы!

Ответить
Развернуть ветку
Дмитрий Ветров

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

Ответить
Развернуть ветку
Linxdatacenter
Автор

Целью проекта была замена старого оборудования находящегося в EOL статусе. Основной эффект - снижение риска выхода из строя оборудования, который бы привёл к простою конвейера и т.п.

Ответить
Развернуть ветку
Life Expert

Если все зарезервировано, то никакого простоя бы и не было )

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Zuko Yuppi

АХАХАХААХА
ХАХАХХАХАХХА
АХАХАХАХАААА
(заплакал)

Ответить
Развернуть ветку
AlexSam

Так дома, такого обычно и не бывает (исключение если хозяин неряха). А вот на предприятиях - легко. Особенно из-за текучки админов и неумных указаний начальства.

Ответить
Развернуть ветку
Timur Aristov

так даже если хозяйки и не неряха тоже может быть такое )

Ответить
Развернуть ветку
Ольга Мельниченко

Интересная статья!
Возник такой вопрос: была ли у заказчика централизованная система мониторинга сетевого оборудования? Как он управляет сетью сейчас?

Ответить
Развернуть ветку
Linxdatacenter
Автор

Система мониторинга самописная. Сейчас используют технологии SD-WAN от производителя оборудования.
Благодарю за интерес!

Ответить
Развернуть ветку
Денис Бойцов

А эта история была еще до великого исхода вендоров или уже после? Как вообще сейчас с доступностью сетевого оборудования дела обстоят?

Ответить
Развернуть ветку
Linxdatacenter
Автор

Она была в процессе)
То есть первый завод сделали до, а часть последующих после.
Сейчас с доступностью непросто.

Ответить
Развернуть ветку
Оксана Гришина

Хм... «Выяснилось, что основной трафик передавался корректно, а управляющий трафик не достигал узла через новое ядро". Удалось ли выяснить причину этой ошибки? Можно ли было ее избежать при еще более тщательном планировании?

Ответить
Развернуть ветку
Linxdatacenter
Автор

Основная причина ошибки - человеческий фактор. Снизить риск человеческого фактора возможно при более детальном описании конфигурации и с помощью дополнительного контроля.

Ответить
Развернуть ветку
Life Expert

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

Ответить
Развернуть ветку
Linxdatacenter
Автор
Ответить
Развернуть ветку
Виктория Фоменко

Есть ли усредненный показатель допустимых простоев на таких проектах?

Ответить
Развернуть ветку
Linxdatacenter
Автор

Не уверен. Всё зависит от бизнес требований у заказчика.

Ответить
Развернуть ветку
Айгуль Ширяева

Молодцы, что ещё сказать :))

Ответить
Развернуть ветку
Tetoti Tutoto

В 15 минут не верю, столько по времени только свитч включатся может. Еще судя по фото новое оборудование размещать рядом со старым было некуда, значит нужно было демонтировать старое, потом монтировать новое.

Ответить
Развернуть ветку
Linxdatacenter
Автор

Новое и старое оборудование работало одновременно. Новый коммутатор монтировался рядом со старым, подключался, поднимался 1 аплинком (2ой в старом коммутаторе). Тогда получается даунтайм только на переключение кабеля.
То есть время требуется, чтобы выпутать один линк ;)

Ответить
Развернуть ветку
17 комментариев
Раскрывать всегда