🥇История на едно прехвърляне

В нашата агрегация на локалната мрежа имаше шест партиди комутатори 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 са разположени сървъри на един клиент C1, 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 секунди при очаквано поведение на оборудването).

В дадения пример на клиента C1 или клиента С2 Трябва да предупредим за работата с прекъсване на връзката най-малко три пъти — първия път за извършване на работа по един POD, в който е разположен един от сървърите, втори път — за втория, и трети път — при превключване на оборудването за DCI услуги.

Превключване на агрегирани комуникационни канали

Защо говоря за очакваното поведение на оборудването и как агрегирани канали могат да се превключват с минимално прекъсване на връзката. Нека си представим следната картина:

От страната на линка — комутатори за дистрибуция на POD — D1 и D2, те образуват между себе си MLAG двойка (стек, VCS фабрика, vPC двойка), от другата страна два линка — Линк 1 и Линк 2 — включени в MLAG двойката на старите комутатори за агрегация И. От страната на комутаторите D е образуван агрегираният интерфейс с име Порт-канал A, а от страната на комутаторите за агрегация И — агрегирания интерфейс с име Порт-канал D.

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

работят;
включени в една двойка устройства на отдалечената страна.

При обмен на пакети в пакета се предава стойността system-id, която обозначава устройството, към което тези линкове са свързани. За 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 — Минимизиране на прекъсването
Изключете от комутатор A2 линк 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 A-N на интерфейсите Po A и Po DN, така че трафикът започва да се предава по линка. Линк 2. Прекъсването в този случай е, на практика, до 2 секунди.

А сега спокойно прехвърляме Link 1 в комутатор N1, възстановявайки капацитета и нивото на резервиране на интерфейсите. Po A и Po DN. Тъй като при свързването на този линк не се променя текущата стойност на system-id от нито една страна, не настъпва прекъсване.

Допълнителни линкове

Но превключването може да се извърши без присъствието на инженер в момента на превключване. За това ще трябва предварително да прокараме допълнителни линкове между комутаторите за дистрибуция D и новите комутатори за агрегиране. N.

Прокарваме нови линкове между комутаторите за агрегиране N и комутаторите за дистрибуция на всички POD. Това изисква поръчка и прокарване на допълнителни патч-кабели, и инсталиране на допълнителни трансивери както в N, така и в D. Можем да го направим, тъй като в комутаторите D на всеки POD има свободни портове (или ги освобождаваме предварително). В крайна сметка всеки POD е физически свързан с два линка към старите комутатори A и към новите комутатори 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 сегментът отива от клиентските сървъри само до L3VPN маршрутизаторите на Selectel. На маршрутизаторите се терминира клиентската мрежа.

Всеки клиентски сървър, например, 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.

юнит 1006 {
    описание C2;
    vlan-id 1006;
    фамилия inet {       
        адрес 10.0.0.252/24 {
            vrрp-група 1 {
                приоритет 200;
                виртуален-адрес 10.100.0.254;
                преемственост {
                    време-задържане 120;
                }
                приемай-данни;
            }
        }
    }
}

Сървър 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