Як оновити мережеве обладнання на великому підприємстві без зупинки виробництва? Про масштабний проект у режимі «операції на відкритому серці» розповідає менеджер із управління проектами Linxdatacenter Олег Федоров.
В останні кілька років ми відзначаємо підвищений попит замовників на послуги, пов'язані із мережевим компонентом ІТ-інфраструктури. Потреба у зв'язності ІТ-систем, сервісів, додатків, завдання моніторингу та операційного управління бізнесом практично у будь-якій сфері змушують сьогодні компанії приділяти мережам підвищену увагу.
Діапазон запитів – від забезпечення відмовостійкості мережі до створення та управління клієнтською автономною системою з придбанням блоку IP-адрес, налаштуванням протоколів маршрутизації та управлінням трафіком згідно з політиками організацій.
Також зростає попит на комплексні рішення щодо побудови та обслуговування мережевої інфраструктури, в першу чергу з боку замовників, мережева інфраструктура яких створюється з нуля або морально застаріла, вимагаючи серйозної модифікації.
Цей тренд за часом збігся з періодом розвитку та ускладнення власної мережевої інфраструктури Linxdatacenter. Ми розширили географію своєї присутності в Європі за рахунок підключення до віддалених майданчиків, що потребувало і вдосконалення інфраструктури мережі.
Компанія запустила новий сервіс для клієнтів, Network-as-a-Service: вирішення всіх мережевих завдань клієнтів ми беремо на себе, дозволяючи їм зосередитись на основному бізнесі.
Влітку 2020 року завершився перший великий проект у цьому напрямі, про який хотілося б розповісти.
На старті
Великий промисловий комплекс звернувся до нас за модернізацією мережевої частини інфраструктури на одному із своїх підприємств. Потрібно було зробити заміну старого обладнання на нове, у тому числі ядра мережі.
Остання модернізація обладнання на підприємстві проходила близько 10 років тому. Нове керівництво підприємства вирішило покращити зв'язність, розпочавши з оновлення інфраструктури на базовому, фізичному рівні.
Проект було поділено на дві частини: апгрейд серверного парку та мережевого обладнання. Ми відповідали за другу частину.
Базові вимоги до робіт включали мінімізування простоїв виробничих ліній підприємства під час виконання робіт (а на деяких ділянках і повне виключення простоїв). Будь-яка зупинка – прямі грошові втрати клієнта, чого мало статися за жодних обставин. У зв'язку з режимом роботи об'єкта 24х7х365, а також з урахуванням повної відсутності періодів планових простоїв у практиці підприємства, перед нами було поставлено завдання по суті виконати операцію на відкритому серці. Це і стало головною рисою проекту.
поїхали
Роботи планувалися за принципом руху від віддалених від ядра вузлів мережі до ближчих, а також від менш виробничих ліній, що впливають на роботу, до впливають на цю роботу безпосередньо.
Наприклад, якщо брати вузол мережі у відділі продажів, то перебій зі зв'язком у результаті робіт у даному відділі не торкнеться виробництва. При цьому такий інцидент допоможе нам як підряднику перевірити правильність обраного підходу до роботи на таких вузлах і, скоригувавши дії, працювати на наступних етапах проекту.
Необхідно не тільки замінити вузли та дроти в мережі, але й правильно налаштувати всі компоненти для коректної роботи рішення в цілому. Саме конфігурації і перевірялися таким чином: починаючи роботи у віддаленні від ядра, ми ніби давали собі «право на помилку», не наражаючи на ризик критично важливі для роботи підприємства ділянки.
Ми визначили зони, що не впливають на виробничий процес, а також критичні ділянки – цехи, вантажно-розвантажувальний блок, склади і т. д. . Повністю уникнути відключення окремих вузлів мережі було неможливо, оскільки кабель повинен бути фізично переключений зі старого обладнання в нове, а в процесі перемикання необхідно також розплутати «бороду» проводів, яка сформувалася в процесі декількох років експлуатації без належного догляду (одне з наслідків аутсорсингу робіт з монтажу кабельних ліній).
Роботи були поділені на кілька етапів.
етап 1 – Аудит. Підготовка та узгодження підходу до планування робіт та оцінка готовності команд: клієнта, підрядника, що виконує монтаж, та нашої команди.
етап 2 – Розробка формату для проведення робіт з глибоким детальним аналізом та плануванням. Вибрали формат чек-листа з точним вказівкою порядку та послідовності дій, аж до послідовності перемикання патч-кордів портами.
етап 3 – Проведення робіт у шафах, які не впливають на провадження. Оцінка та коригування часу простою для наступних етапів робіт.
етап 4 – Проведення робіт у шафах, які безпосередньо впливають на виробництво. Оцінка та коригування часу простою для фінального етапу робіт.
етап 5 – Проведення робіт у серверній з перемикання обладнання, що залишилося. Запуск маршрутизації на новому ядрі.
етап 6 – Послідовне перемикання ядра системи зі старих мережевих конфігурацій на нові для плавного переходу всього комплексу системи (VLAN, маршрутизація тощо). На даному етапі ми підключили всіх користувачів і перевели всі сервіси на нове обладнання, перевірили правильність підключення, переконалися, що жодні з сервісів підприємства не зупинилися, гарантували, що у разі виникнення будь-яких проблем вони будуть пов'язані безпосередньо з ядром, що полегшувало усунення можливих неполадок та фінальне налаштування.
Зачіска бороди проводів
Проект виявився непростим ще й через складні вихідні умови.
По-перше, це величезна кількість вузлів та ділянок мережі, із заплутаною топологією та класифікацією проводів за їх призначенням. Такі «бороди» треба було діставати з шаф і ретельно «зачісувати», розбираючись, який провід звідки й куди веде.
Виглядало це приблизно так:
так:
або так:
По-друге, для кожного такого завдання необхідно було підготувати файл з описом процесу. "Беремо провід Х з порту 1 старого обладнання, встромляємо його в порт 18 нового обладнання". Звучить просто, але коли у тебе у вихідних даних 48 повністю забитих портів, а також відсутня опція простою (ми пам'ятаємо про 24х7х365), єдиний вихід працювати по блоках. Чим більше можна витягнути проводів зі старого обладнання за один раз, тим швидше можна їх зачесати і вставити в нове мережеве «залізо», уникнувши збоїв та простоїв у роботі мережі.
Тому на підготовчому етапі ми провели розбивку мережі блоками – кожен з них ставився до певного VLAN. Кожен порт (або їхнє підмножина) на старому устаткуванні – це якийсь із VLAN у новій топології мережі. Ми згрупували їх так: у перших портах комутатора розмістилися користувальницькі мережі, в середині – виробничі мережі, а в останніх – точки доступу та аплінки.
Такий підхід дозволив за один прийом витягувати та зачісувати зі старого обладнання не 1 провід, а 10-15. Це у кілька разів прискорило робочий процес.
До речі, ось як виглядають дроти у шафах після зачісування:
або, наприклад, так:
Після завершення 2-го етапу ми взяли паузу на аналіз помилок та динаміки проекту. Наприклад, одночасно вилізли дрібні недоліки через неточності в наданих нам схемах мережі (неправильний конектор на схемі - неправильний куплений патч-корд і необхідність його заміни).
Пауза була необхідна, тому що при роботі з серверним правом навіть невеликий збій у процесі був неприпустимий. Якщо поставлена мета забезпечити час простою ділянці мережі трохи більше 5 хвилин, то перевищувати його не можна. Будь-яке можливе відхилення від графіка мало погоджуватися з клієнтом.
Однак попереднє планування та розбивка проекту на блоки дозволили вкластися в запланований час простою на всіх ділянках, а в більшості випадків взагалі обійтися без нього.
Виклик часу – проект під COVID-ом
Без додаткових складнощів, однак, не обійшлося. Звичайно, як одна з перешкод виступив коронавірус.
Роботи ускладнилися тим, що почалася пандемія, і неможливо було бути присутнім під час проведення робіт на майданчику клієнта всім фахівцям, задіяним у процесі. На майданчик були допущені тільки співробітники монтажної організації, а контроль здійснювався через кімнату в Zoom - в ній знаходилися мережевий інженер з боку Linxdatacenter, я як керівник проекту, мережевий інженер з боку клієнта, відповідальний за виконання робіт, і команда, яка виконує монтажні роботи.
У ході робіт виникали невраховані проблеми, і доводилося вносити коригування на льоту. Так вдалося швидко запобігати впливу людського фактора (помилки у схемі, помилки у визначенні статусу активності інтерфейсу тощо).
Хоча дистанційний формат роботи і здавався незвичним на початку проекту, ми досить швидко пристосувалися до нових умов та вийшли на фінальний етап робіт.
Ми запустили тимчасову конфігурацію налаштувань мережі для паралельної роботи двох мережевих ядер – старого та нового – з метою здійснення плавного переходу. Однак виявилося, що не видалено один зайвий рядок з файлу конфігурації нового ядра, і переходу не відбулося. Це змусило нас витратити певний час на пошуки проблеми.
З'ясувалося, що основний трафік передавався коректно, а трафік, що управляє, не досягав вузла через нове ядро. Завдяки чіткому поділу проекту на етапи, вдалося досить швидко встановити ділянку мережі, на якій виникла скрута, виявити проблему та усунути її.
А в результаті
Технічні підсумки проекту
Насамперед було створено нове ядро нової мережі підприємства, для чого ми побудували фізичні/логічні кільця. Зроблено це таким чином, щоб у кожного комутатора в мережі з'явилося друге плече. У старій мережі багато комутаторів приєднувалися до ядра по одній трасі, одним плечем (аплінком). Якщо він рвався, комутатор ставав цілком недоступним. А якщо через один аплінк підключалося кілька комутаторів, то аварія виводила з ладу цілий відділ чи виробничу лінію на підприємстві.
У новій мережі навіть досить серйозний мережевий інцидент за жодного сценарію не зможе «покласти» всю мережу або її значну ділянку.
90% всього мережевого обладнання оновлено, виведено з експлуатації медіаконвертери (перетворювачі середовища розповсюдження сигналу), а також скасовано необхідність виділених силових ліній для запиту обладнання за рахунок підключення до PoE-комутаторів, де електроживлення здійснюється по Ethernet-проводам.
Також, промарковані всі оптичні з'єднання в серверній та шафах на місцях – на всіх ключових вузлах зв'язку. Це дозволило підготувати топологічну схему обладнання та підключень у мережі, що відображає її фактичний стан на сьогодні.
схема мережі
Найголовніший підсумок у технічному відношенні: досить масштабні інфраструктурні роботи були проведені швидко, не створюючи жодних перешкод у роботі підприємства та практично непомітно для його персоналу.
Бізнес-підсумки проекту
На мій погляд, цей проект цікавий насамперед не з технічного, а з організаційного боку. Складність полягала насамперед у плануванні та продумуванні кроків щодо реалізації проектних завдань.
Успіх проекту дозволяє говорити про те, що наша ініціатива щодо розвитку мережевого спрямування в рамках портфеля сервісів Linxdatacenter – правильний вибір вектора розвитку компанії. Відповідальний підхід до управління проектами, грамотна стратегія, чітке планування дали нам змогу виконати роботу на належному рівні.
Підтвердження якості роботи – запит від клієнта продовження надання послуг із модернізації мережі з його інших майданчиках у Росії.
Джерело: habr.com