Сьогодні розповім про те, як з'явилася та реалізувалася ідея створення нової внутрішньої мережі для нашої компанії. Позиція керівництва – для себе потрібно зробити такий же повноцінний проект, як для клієнта. Якщо зробимо добре для себе – зможемо запросити замовника та показати, наскільки добре влаштовано та працює те, що ми йому пропонуємо. Тому до опрацювання концепту нової мережі для московського офісу ми підійшли досить ґрунтовно, використавши повний виробничий цикл: аналіз потреб відділів → вибір технічного рішення → проектування → реалізація → тестування. Отже, починаємо.
Вибір технічного рішення: заповідник мутантів
Порядок роботи над складною автоматизованою системою поки що найкраще описаний у ГОСТ 34.601-90 «Автоматизовані системи. Стадії створення», тож ми працювали по ньому. І вже на стадіях формування вимог та розробки концепції ми зіткнулися з першими труднощами. Організаціям різного профілю - банкам, страховим компаніям, розробникам софту тощо - під їх завдання та стандарти потрібні певні типи мереж, специфіка яких зрозуміла і стандартизована. Проте з нами таке не прокотить.
Чому?
"Інфосистеми Джет" - велика багатопрофільна ІТ-компанія. При цьому відділ внутрішньої підтримки у нас невеликий (але гордий), він забезпечує працездатність базових сервісів та систем. Компанія містить у собі безліч підрозділів, що виконують різні функції: це й кілька найпотужніших аутсорс-команд, і власні розробники бізнес-систем, і інформбезпека, і архітектори обчислювальних комплексів — загалом, хто тільки не. Відповідно, завдання, системи та політики безпеки у них також різні. Що очікувано створило складності у процесі аналізу потреб та їх стандартизації.
Ось, наприклад, відділ розробки: його співробітники пишуть та тестують код для великої кількості замовників. Часто виникає необхідність оперативно організувати тестові середовища, і скажемо відверто, не завжди для кожного проекту вдається сформувати вимоги, запросити ресурси та побудувати окреме тестове середовище відповідно до всіх внутрішніх регламентів. Це породжує курйозні ситуації: одного разу ваш покірний слуга заглянув у кімнату розробників і виявив під столом справний Hadoop-кластер з 20 десктопів, який незрозумілим чином був підключений до спільної мережі. Думаю, не варто уточнювати, що ІТ-відділ компанії не знав про його існування. Це, як і багато інших, стали винуватцями того, що в ході розробки проекту у нас народився термін «заповідник мутантів», що описує стан багатостраждальної інфраструктури офісу.
Або ще приклад. Періодично всередині якогось підрозділу заводиться тестовий стенд. Так було з Jira та Confluence, які обмежено використовувалися Центром програмної розробки у деяких проектах. Через деякий час про ці корисні ресурси дізналися в інших підрозділах, оцінили, і наприкінці 2018 року Jira та Confluence перейшли зі статусу «локальна іграшка програмістів» у статус «ресурси компанії». Тепер за цими системами має бути закріплений власник, мають бути визначені SLA, політики доступу/ІБ, політика резервного копіювання, моніторингу, правила маршрутизації заявок на усунення проблем, загалом мають бути присутніми всі атрибути повноцінної інформаційної системи.
Кожен наш підрозділ це ще й інкубатор, який вирощує власні продукти. Деякі з них гинуть на стадії розробки, якісь ми використовуємо в період роботи над проектами, інші ж приживаються і стають рішеннями, що тиражуються, які ми починаємо застосовувати самі і продавати клієнтам. Для кожної подібної системи бажано мати власне мережеве середовище, де воно буде розвиватися, не заважаючи іншим системам, і в якийсь момент зможе бути інтегрованою в інфраструктуру компанії.
Крім розробки, ми маємо дуже великий з більш як 500 співробітниками, сформованими в команди під кожного замовника. Вони займаються обслуговуванням мереж та інших систем, віддаленим моніторингом, врегулюванням заявок тощо. Тобто інфраструктура СЦ — це, по суті, інфраструктура замовника, з яким вони зараз працюють. Особливість роботи з цією ділянкою мережі полягає в тому, що їхні робочі станції для нашої компанії є частково зовнішніми, а частково внутрішніми. Тому для СЦ ми реалізували наступний підхід — компанія надає відповідному підрозділу мережеві та інші ресурси, розглядаючи робочі станції цих підрозділів як зовнішні підключення (за аналогією до філій та віддалених користувачів).
Проектування магістралі: ми оператор (сюрприз)
Після оцінки всіх підводних каменів ми зрозуміли, що ми отримуємо мережу телекомунікаційного оператора в рамках одного офісу, і почали діяти відповідним чином.
Створили опорну мережу, за допомогою якої будь-якому внутрішньому, а в перспективі та зовнішньому споживачеві надається потрібний сервіс: L2 VPN, L3 VPN або звичайна маршрутизація L3. Одним підрозділам потрібен безпечний доступ в інтернет, іншим — чистий доступ без міжмережевих екранів, але при цьому захист наших корпоративних ресурсів і опорної мережі від їх трафіку.
З кожним підрозділом ми неформально уклали SLA. Відповідно до нього всі інциденти, що виникають, повинні усуватися за певний, заздалегідь узгоджений проміжок часу. Вимоги до своєї мережі у компанії виявилися жорсткими. Максимальний час реагування на інцидент при збоях телефонного зв'язку та електронної пошти становив 5 хвилин. Час відновлення працездатності мережі при типових відмови - не більше хвилини.
Оскільки у нас мережа операторського класу, до неї можна підключатися лише у суворій відповідності до правил. Обслуговуючі підрозділи встановлюють політики та надають послуги. Їм навіть не потрібна інформація про підключення конкретних серверів, віртуальних машин та робочих станцій. Але при цьому потрібні механізми захисту, тому що жодне підключення не повинно виводити мережу з ладу. При випадковому створенні петлі інші користувачі не повинні помічати цього, тобто необхідна адекватна реакція мережі. Будь-який оператор зв'язку постійно вирішує подібні, здавалося б, складні завдання всередині своєї опорної мережі. Він надає сервіс безлічі клієнтів з різними потребами та трафіком. При цьому різні абоненти не повинні зазнавати незручностей від трафіку інших.
Ми вирішили це завдання так: побудували опорну L3-мережа з повним резервуванням, з використанням протоколу IS-IS. Поверх опорної збудували накладену мережу на основі технології /, з використанням протоколу маршрутизації . Для прискорення збіжності протоколів маршрутизації застосували BFD.
структура мережі
На випробуваннях така схема показала себе чудово - при відключенні будь-якого каналу або комутатора час збіжності не більше 0.1-0.2 с, втрачається мінімум пакетів (часто - жодного), TCP-сесії не рвуться, телефонні розмови не перериваються.
Рівень Underlay - маршрутизація
Рівень Overlay - маршрутизація
Як комутатори розподілу використовувалися комутатори Huawei CE6870 з ліцензіями VXLAN. Цей пристрій має оптимальне поєднання ціна/якість, що дозволяє підключати абонентів на швидкості 10 Гбіт/с, та підключатися до магістралі на швидкостях 40–100 Гбіт/с, залежно від використовуваних трансіверів.
Комутатори Huawei CE6870
Як комутатори ядра використовувалися комутатори Huawei CE8850. Із завдання — швидко та надійно передавати трафік. До них не підключаються жодні пристрої, крім комутаторів розподілу, вони нічого не знають про VXLAN, тому була обрана модель з 32 портами 40/100 Гбіт/с, з базовою ліцензією, що забезпечує L3-маршрутизацію та підтримку протоколів IS-IS та MP-BGP .
Найнижчий - комутатор ядра Huawei CE8850
На етапі проектування всередині команди вибухнула дискусія про технології, за допомогою яких можна реалізувати стійкість до відмови до вузлів опорної мережі. Наш московський офіс розміщується в трьох будинках, у нас 7 кросових приміщень, у кожному з яких було встановлено два комутатори розподілу Huawei CE6870 (ще в декількох кросових приміщеннях встановлювалися лише комутатори доступу). Під час розробки концепції мережі було розглянуто два варіанти резервування:
- Об'єднання комутаторів розподілу у відмовостійкий стек у кожному кросовому приміщенні. Плюси: простота та зручність налаштування. Мінуси: вища ймовірність виходу з ладу всього стека при прояві помилок вбудованого програмного забезпечення мережевих пристроїв («відплив пам'яті» і подібні).
- Застосувати технології M-LAG та Anycast gateway для підключення пристроїв до комутаторів розподілу.
Зрештою зупинилися на другому варіанті. Він дещо складніший у налаштуванні, але показав на практиці свою працездатність та високу надійність.
Розглянемо спочатку підключення кінцевих пристроїв до комутаторів розподілу:
Кросова
Комутатор доступу, сервер або будь-який інший пристрій, що вимагає стійкості до відмови, включається в два комутатора розподілу. Технологія M-LAG забезпечує резервування на канальному рівні. Передбачається, що два комутатора розподілу виглядають для устаткування, що підключається, як один пристрій. Резервування та балансування навантаження здійснюються за протоколом LACP.
Технологія Anycast Gateway забезпечує резервування на мережному рівні. На кожному з комутаторів розподілу налаштовано досить велику кількість VRF (кожен VRF призначений для своїх цілей — окремо для «звичайних» користувачів, окремо — для телефонії, окремо — для різних тестових середовищ та середовищ розробки тощо), і в кожному VRF налаштовано декілька VLAN. У нашій мережі комутатори розподілу є стандартними шлюзами для всіх пристроїв, підключених до них. IP-адреси, що відповідають інтерфейсам VLAN, однакові для обох комутаторів розподілу. Маршрутизація трафіку провадиться через найближчий комутатор.
Тепер розглянемо підключення комутаторів розподілу до ядра:
Відмовостійкість забезпечується на мережному рівні, за протоколом IS-IS. Зверніть увагу – між комутаторами передбачена окрема лінія зв'язку L3, на швидкості 100G. Фізично ця лінія зв'язку є кабелем Direct Access, його можна побачити праворуч на фотографії комутаторів Huawei CE6870.
Альтернативою було б організувати "чесну" повнозв'язну топологію "подвійна зірка", але, як було сказано вище, у нас 7 кросових приміщень у трьох будинках. Відповідно, якби ми вибрали топологію «подвійна зірка», то нам би знадобилося рівно вдвічі більше «дальнобійних» трансіверів 40G. Економія тут дуже суттєва.
Потрібно сказати кілька слів про те, як спільно працюють технології VXLAN та Anycast gateway. VXLAN, якщо не вдаватися до деталей, це тунель для транспортування кадрів Ethernet всередині пакетів UDP. Як цільова (destination) IP-адреса VXLAN-тунелю використовуються loopback-інтерфейси комутаторів розподілу. У кожній кросовій встановлено два комутатори з однаковими адресами loopback-інтерфейсів, відповідно пакет може прийти на будь-який з них, і з нього може бути вилучений кадр Ethernet.
Якщо комутатор знає про цільову MAC-адресу вилученого кадру, кадр буде коректно доставлений за призначенням. За те, щоб обидва комутатори розподілу, встановлені в одній кросовій, мали актуальну інформацію про всі MAC-адреси, що «прилітають» з комутаторів доступу, відповідає механізм M-LAG, що передбачає синхронізацію таблиць MAC-адрес (а також ARP-таблиць) на обох комутаторів M-LAG-пари.
Балансування трафіку досягається завдяки наявності в underlay-мережі кількох маршрутів на loopback-інтерфейси комутаторів розподілу.
Замість висновку
Як вже було сказано вище, на випробуваннях і в роботі мережа показала високу надійність (час відновлення при типових відмови не більше сотень мілісекунд) і хорошу продуктивність - кожна кросова пов'язана з ядром двома каналами по 40 Гбіт/с. Комутатори доступу в нашій мережі об'єднуються в стеки і підключаються до комутаторів розподілу LACP/M-LAG двома каналами по 10 Гбіт/с. У стеку зазвичай 5 комутаторів по 48 портів у кожному, до розподілу в кожній кросової підключаються до 10 стеків доступу. Таким чином, магістраль забезпечує близько 30 Мбіт/с на користувача навіть за максимального теоретичного завантаження, що на момент написання статті достатньо для всіх наших практичних застосувань.
Мережа дозволяє без проблем організувати пару будь-яких довільних підключених пристроїв як по L2, так і по L3, забезпечуючи повну ізоляцію трафіку (що подобається службі інформаційної безпеки) і доменів відмов (що подобається службі експлуатації).
У наступній частині розповімо, як ми проводили міграцію на нову мережу. Stay tuned!
Максим Клочков
Старший консультант групи мережевого аудиту та комплексних проектів
Центру мережевих рішень
«Інфосистеми Джет»
Джерело: habr.com