Історія одного перемикання

У нас в агрегації локальної мережі було шість пар комутаторів Arista DCS-7050CX3-32S та одна пара комутаторів Brocade VDX 6940-36Q. Не те, щоб нас сильно напружували комутатори Brocade у цій мережі, вони працюють і виконують свої функції, але ми готували повну автоматизацію деяких дій, а цих можливостей ми на цих комутаторах не мали. А ще хотілося перейти з 40GE інтерфейсів на можливість використання 100GE щоб зробити запас на наступні 2-3 роки. Так ми вирішили міняти Brocade на Arista.

Ці комутатори є комутаторами агрегації локальної мережі кожного дата-центру. До них підключаються безпосередньо комутатори дистрибуції (другий рівень агрегації), які вже збирають у собі комутатори Top-of-Rack локальної мережі у стійках із серверами.

Кожен сервер включений в один або два комутатори доступу. Комутатори доступу підключені до пари комутаторів дистрибуції (два комутатори дистриб'юції та два фізичні лінки від комутатора доступу до різних комутаторів дистрибуції використовуються для резервування).

Кожен сервер може бути використаний своїм клієнтом, тому клієнту виділяється окремий VLAN. Цей VLAN потім прописується на інший сервер цього клієнта в будь-якій стійці. Дата-центр складається з кількох таких рядів (POD'ів), для кожного ряду стійок є свої комутатори дистрибуції. Потім ці комутатори дистриб'юції підключаються до комутаторів агрегації.

Клієнти можуть замовити сервер у будь-якому ряду, заздалегідь передбачити, що сервер буде виділений або встановлений у якийсь конкретний ряд у якусь конкретну стійку, не можна, тому на комутаторах агрегації є близько 2500 VLAN у кожному дата-центрі.

Устаткування для DCI (Data-Center Interconnect) підключається до комутаторів агрегації. Воно може призначатися як для L2-зв'язності (пара комутаторів, що утворює VXLAN-тунель в інший дата-центр), так і для L3-зв'язності (два MPLS-маршрутизатори).

Як я вже писав, для уніфікації процесів автоматизації конфігурації послуг на обладнанні в одному дата-центрі потрібно було замінити центральні комутатори агрегації. Ми встановили нові комутатори поруч із існуючими, об'єднали їх у MLAG пару та почали готуватися до робіт. Їх одразу поєднали з існуючими комутаторами агрегації, так що у них став загальний L2-домен по всіх клієнтських VLAN.

Деталі схеми

Для конкретики назвемо старі комутатори агрегації А1 и А2, нові - N1 и N2. Уявимо, що в POD 1 и POD 4 розміщені сервери одного клієнта С1, VLAN клієнта позначений синім кольором. Цей клієнт використовує послугу L2-зв'язку з іншим дата-центром, тому його VLAN подано на пару комутаторів VXLAN.

клієнт С2 розміщує сервери в POD 2 и POD 3, VLAN клієнта позначаємо темно-зеленим кольором. Цей клієнт також використовує послугу зв'язків з іншим дата-центром, але L3, тому його VLAN подано на пару L3VPN маршрутизаторів.

Клієнтські VLAN нам потрібні для розуміння, на яких етапах робіт із заміни що відбувається, де з'являється перерва зв'язку, і яка може бути його тривалість. Протокол STP в цій схемі не використовується, так як ширина дерева для нього в такому випадку виходить великою, і збіжність протоколу зростає в геометричній прогресії кількості пристроїв і лінків між ними.

Усі пристрої, з'єднані подвійними лінками, утворюють стек, MLAG-пару або VCS-Ethernet-фабрику. Для пари маршрутизаторів L3VPN подібні технології не використовуються, так як немає необхідності резервування L2, достатньо того, щоб у них була L2 зв'язність один з одним через комутатори агрегації.

Варіанти реалізації

При аналізі варіантів подальших подій ми зрозуміли, що є кілька способів проведення цих робіт. Від глобальної перерви по всій локальній мережі, до невеликих буквально 1-2 секундних перерв у частинах мережі.

Мережа, стояти! Комутатори, замінюйтесь!

Найпростіший спосіб - це, звичайно, оголосити глобальну перерву зв'язку по всіх POD і по всіх послугах DCI і переключити всі лінки з комутаторів А у комутатори N.

Крім перерви, час якої ми не можемо гарантовано передбачити (так, ми знаємо кількість лінків, але не знаємо, скільки разів щось піде не так — від заламаного патч-корду чи пошкодженого конектора до несправності порту чи трансівера), ми ще не можемо заздалегідь передбачити, чи вистачить довжини патч-кордів, DAC, AOC, підключених у старі комутатори А, щоб дотягнути їх до, хоч і поряд, але все одно трохи осторонь, нових комутаторів N, і чи запрацюють ті ж самі трансівери /DAC/AOC з комутаторів Brocade у комутаторах Arista.

І все це в умовах жорсткого пресингу з боку клієнтів і техпідтримки («Наташ, вставай! Наташ, там все не працює! Наташ, ми вже написали в техпідтримку, чесно-чесно! Наташ, там уже все впустили! Наташ, а скільки ще не буде працювати? Наташ, а коли запрацює?!»). Навіть незважаючи на заздалегідь оголошену перерву та зроблене сповіщення щодо клієнтів, наплив звернень у такий час гарантовано.

Стій, 1-2-3-4!

А якщо не оголошувати глобальну перерву, а оголосити серію маленьких перерв зв'язку з POD та послуг DCI. У першу перерву переключити на комутатори N лише POD 1, у другій - через пару днів - POD 2, потім ще за пару днів POD 3, Далі POD 4…[N]потім VXLAN-комутатори і потім L3VPN-маршрутизатори.

За такої організації робіт із перемикання ми зменшуємо складність одноразових робіт і збільшуємо собі час на вирішення проблем, якщо щось раптом пішло не так. Зв'язок POD 1 після перемикання з іншими POD і DCI не втрачається. Але самі роботи затягуються надовго, на час цих робіт у дата-центрі потрібно виділення інженера на фізичне виконання перемикань, і під час робіт (а такі роботи виконуються, як правило, вночі, з 2 до 5 ранку) потрібна наявність онлайн мережевого інженера досить високою кваліфікації. Проте ми отримуємо короткі перерви зв'язку, як правило, роботи можуть проводитися в інтервалі півгодини з перервою до 2 хвилин (на практиці, часто 20-30 секунд при очікуваній поведінці обладнання).

У наведеному прикладі клієнта С1 або клієнта С2 доведеться попереджати про роботи з перервою зв'язку щонайменше три рази - вперше для проведення робіт по одному POD, в якому знаходиться один його сервер, вдруге - по другому, і втретє - при перемиканні обладнання для DCI послуг.

Перемикання агрегованих каналів зв'язку

Чому ми говоримо про очікувану поведінку обладнання, і як з мінімізуванням перерви зв'язку можуть перемикатися агреговані канали. Представимо таку картину:

З одного боку лінка - комутатори дистрибуції POD - D1 и D2, вони утворюють між собою MLAG-пару (стек, VCS-фабрику, vPC-пару), з іншого боку два лінки - Посилання 1 и Посилання 2 - включені в MLAG-пару старих комутаторів агрегації А. На боці комутаторів D сформовано агрегований інтерфейс з назвою Port-channel Aна боці комутаторів агрегації А - агрегований інтерфейс з назвою Port-channel D.

Агреговані інтерфейси у своїй роботі використовують LACP, тобто комутатори з двох сторін регулярно обмінюються LACPDU-пакетами по обидва лінки, щоб переконатися, що лінки:

• робітники;
• включені в одну пару пристроїв на віддаленому боці.

При обміні пакетами у пакеті передається значення системний ідентифікатор, що означає пристрій, куди ці лінки включені. Для MLAG-пари (стека, фабрики тощо) значення system-id для пристроїв, що утворюють агрегований інтерфейс, однаково. Комутатор D1 відправляє в Посилання 1 значення system-id D, та комутатор D2 відправляє в Посилання 2 значення system-id D.

комутатори А1 и А2 аналізують LACPDU-пакети, отримані по одному інтерфейсу Po D, і перевіряють збіг system-id в них. Якщо отриманий по якомусь лінку system-id раптом відрізнятиметься від поточного робочого значення, цей лінк виводиться зі складу агрегованого інтерфейсу до виправлення ситуації. Зараз у нас на боці комутаторів D поточне значення system-id від LACP-партнера A, а на боці комутаторів А - поточне значення system-id від LACP-партнера - D.

При необхідності перемикання агрегованого інтерфейсу ми можемо надійти двома різними способами:

Спосіб 1 - Простий
Вимкнути обидва лінки з комутаторів A. При цьому агрегований канал не працює.

Включити обидва лінки по черзі в комутатори N, тоді знову відбудеться узгодження параметрів роботи LACP, формування інтерфейсу Po D на комутаторах N та передача на лінках значення system-id N.

Спосіб 2 - Мінімізація перерви
Вимкнути з комутатора А2 лінк Link 2. При цьому трафік між А и D продовжить передаватися просто одним із лінків, який залишиться у складі агрегованого інтерфейсу.

Підключити Link 2 до комутатора N2. На комутаторі N вже налаштовано агрегований інтерфейс Po DN, та комутатор N2 почне передавати до LACPDU system-id N. На цьому етапі ми вже можемо перевірити, що комутатор N2 коректно працює з трансівером, що використовується для Посилання 2, що порт підключення перейшов у стан Up, і що з передачі LACPDU немає помилок на порту підключення.

Але той факт, що комутатор D2 для агрегованого інтерфейсу Po A з боку Link 2 отримує значення system-id N, відмінне від поточного робочого значення system-id A, не дозволяє комутаторам D ввести Посилання 2 до складу агрегованого інтерфейсу Po A. Комутатор N не може ввести Посилання 2 у роботу, оскільки він не отримує підтвердження про працездатність від LACP-партнера комутатора D2. Трафік у результаті по Посилання 2 не передається.

А тепер ми вимикаємо Link 1 із комутатора A1, тим самим позбавляючи комутатори А и D працюючого агрегованого інтерфейсу. Таким чином, на стороні комутатора D пропадає поточне робоче значення system-id для інтерфейсу Po A.

Це дозволяє комутаторам D и N домовитись про обмін system-id АН на інтерфейсах Po A и Po DN, так що трафік починає передаватися по лінку Посилання 2. Перерва у разі становить, практично, до 2 секунд.

А тепер ми спокійно перемикаємо Link 1 до комутатора N1, відновлюючи ємність та рівень резервування інтерфейсів Po A и Po DN. Так як при підключенні цього лінка не змінюється поточне значення system-id з одного боку, перерви не відбувається.

Додаткові лінки

Але перемикання можна здійснити без присутності інженера на момент перемикання. Для цього нам потрібно заздалегідь прокласти додаткові лінки між комутаторами дистрибуції D та новими комутаторами агрегації N.

Ми прокладаємо нові лінки між комутаторами агрегації N та комутаторами дистриб'юції всіх POD. Це вимагає замовлення та прокладання додаткових патч-кордів, та встановлення додаткових трансіверів як у N, Так і в D. Ми можемо це зробити, тому що у нас у комутаторах D кожного POD є вільні порти (чи їх попередньо звільняємо). У результаті кожен POD фізично підключений двома лінками до старих комутаторів А і нових комутаторів N.

На комутаторі D сформовано два агреговані інтерфейси Po A з лінками Посилання 1 и Посилання 2, І Po N - З лінками Link N1 и Link N2. На цьому етапі ми перевіряємо правильність підключення інтерфейсів та лінків, рівні оптичних сигналів на обох кінцях лінків (за допомогою DDM-інформації з комутаторів), можемо навіть перевірити працездатність лінка під навантаженням або помоніторити стан оптичних сигналів та температури трансіверів протягом кількох днів.

Трафік, як і раніше, передається через інтерфейс. Po A, а інтерфейс Po N стоїть без трафіку. Налаштування на інтерфейсах приблизно такі:

Interface Port-channel A
Switchport mode trunk
Switchport allowed vlan C1, C2

Interface Port-channel N
Switchport mode trunk
Switchport allowed vlan none

Комутатори D, як правило, підтримують сесійну зміну конфігурації, використовуються такі моделі комутаторів, які мають цей функціонал. Отже, зміну налаштувань інтерфейсів Po A і Po N ми можемо зробити в один прийом:

Configure session
Interface Port-channel A
Switchport allowed vlan none
Interface Port-channel N
Switchport allowed vlan C1, C2
Commit

Тоді зміна конфігурації відбудеться досить швидко, і перерва становитиме, на практиці, не більше 5 секунд.

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

Що ще важливо за такого способу перемикань — усі нові лінки вже заздалегідь поставлені на моніторинг. Помилки, включення лінків в агрегат, завантаження лінків - вся необхідна інформація вже в системі моніторингу, і це вже на картах.

D-Day

POD

Ми обрали найболючіший для клієнтів і найменш схильний до варіантів «щось пішло не так» шлях перемикань з додатковими лінками. Так ми за пару ночей переключили всі POD на нові комутатори агрегації.

Але залишилося переключити обладнання, яке забезпечує послуги DCI.

L2

У разі обладнання, що забезпечує L2-зв'язок, ми не змогли провести аналогічні роботи з додатковими лінками. Причин цього як мінімум дві:

• Відсутність вільних портів потрібної швидкості на VXLAN комутаторах.
• Відсутність функціоналу сесійної зміни конфігурації на VXLAN комутаторах.

Перемикання лінків «по одному» з перервою лише на час узгодження нової пари system-id ми не стали робити, оскільки 100% впевненості в тому, що процедура пройде коректно, у нас не було, а тест у лабораторії показав, що у випадку, якщо "щось йде не так", ми все одно отримуємо перерву зв'язку, і що найстрашніше - не тільки для клієнтів, що мають L2-зв'язок з іншими дата-центрами, а й взагалі для всіх клієнтів дата-центру.

Ми заздалегідь провели агітаційну роботу з переходу з L2 каналів, тому кількість клієнтів, які стосуються роботи на VXLAN-комутаторах, була вже в кілька разів меншою, ніж рік тому. У результаті ми зважилися на перерву зв'язку за послугою L2-зв'язку за умови, що ми зберігаємо нормальну роботу послуг локальної мережі в одному дата-центрі. До того ж, SLA на цю послугу передбачає можливість проведення планових робіт з перервою.

L3

Чому ми рекомендували всім перейти на використання L3VPN під час організації послуг DCI? Однією з причин є можливість проведення робіт на одному з маршрутизаторів, які надають цю послугу, просто зі зниженням рівня резервування до N+0, без перерви зв'язку.

Розглянемо схему надання послуги уважніше. У цій послугі сегмент L2 йде від клієнтських серверів тільки до маршрутизаторів Selectel L3VPN. На маршрутизаторах термінується клієнтська мережа.

Кожен сервер клієнта, наприклад, S2 и S3 у наведеній схемі мають свої приватні IP-адреси. 10.0.0.2/24 у сервера S2 и 10.0.0.3/24 у сервера S3. Адреси 10.0.0.252/24 и 10.0.0.253/24 призначені з боку Selectel на маршрутизатори L3VPN-1 и L3VPN-2відповідно. IP-адреса 10.0.0.254/24 є VRRP VIP адресою на маршрутизаторах Selectel.

Докладніше про послугу L3VPN можна прочитати у нашому блозі.

До моменту перемикання все виглядало приблизно як на схемі:

Два маршрутизатори L3VPN-1 и L3VPN-2 були підключені до старого комутатора агрегації А. Майстром для VRRP VIP адреси 10.0.0.254 є маршрутизатор L3VPN-1. У нього виставлено пріоритет на цю адресу вище, ніж у маршрутизатора L3VPN-2.

unit 1006 {
    description C2;
    vlan-id 1006;
    family inet {       
        address 10.0.0.252/24 {
            vrrp-group 1 {
                priority 200;
                virtual-address 10.100.0.254;
                preempt {
                    hold-time 120;
                }
                accept-data;
            }
        }
    }
}

Сервер S2 для зв'язку з серверами інших локаціях використовує шлюз 10.0.0.254. Таким чином, відключення від мережі маршрутизатора L3VPN-2 (природно, при попередньому його вимкненні з домену MPLS) не впливає на зв'язність серверів клієнта. У цей час просто знижується рівень резервування схеми.

Після цього ми можемо спокійно перепідключати маршрутизатор L3VPN-2 до пари комутаторів N. Прокласти лінки, поміняти трансівери. Логічні інтерфейси маршрутизатора, від яких залежить робота клієнтських послуг, досі підтвердження, що це функціонує як слід, є вимкненими.

Після перевірок лінків, трансіверів, рівнів сигналів, рівнів помилок на інтерфейсах маршрутизатор включається в роботу, але вже підключений до нової пари комутаторів.

Далі ми знижуємо VRRP-пріоритет у маршрутизатора L3VPN-1 і VIP адреса 10.0.0.254 переміщується на маршрутизатор L3VPN-2. Ці роботи також провадяться без перерви зв'язку.

Перенесення VIP адреси 10.0.0.254 на маршрутизатор L3VPN-2 дозволяє вимкнути маршрутизатор L3VPN-1 без перерви зв'язку для клієнта та підключити його вже до нової пари комутаторів агрегації N.

Повертати VRRP VIP на маршрутизатор L3VPN-1 чи ні — це вже інше питання, та й якщо повертати, це робиться без перерви зв'язку.

Разом

Після всіх цих дій ми дійсно замінили комутатори агрегації в одному з наших дата-центрів, мінімізувавши при цьому перерви для наших клієнтів.

Далі залишається лише демонтаж. Демонтаж старих комутаторів, демонтаж старих лінків між комутаторами А та D, демонтаж трансіверів від цих лінків, виправлення моніторингу, виправлення схем мережі у документації та моніторингу.

Комутатори, трансівери, патч-корди, AOC, DAC, що залишилися після перемикань, ми можемо використовувати в інших проектах або інших подібних перемиканнях.

«Наташа, ми все переключили!»

Джерело: habr.com