В нашата агрегация на локалната мрежа имаше шест двойки превключватели 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, свързани с остарели комутатори A, ще бъде достатъчна, за да ги доведем до новите комутатори 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-пара), а от другата страна два линка — Link 1 и Link 2 — са включени в MLAG-парата на старите комутатори за агрегиране А. От страната на комутаторите D е формирован агрегирани интерфейс с име Port-channel A, от страната на комутаторите за агрегиране А — агрегирани интерфейс с име Port-channel D.
Агрегираните интерфейси в работата си използват LACP, тоест, комутаторите от двете страни редовно обменят LACPDU-пакети по двата линка, за да се уверят, че линковете:
- работят;
- свързани са в една двойка устройства отдалечена страна.
При обмена на пакети в пакета се предава стойността system-id, обозначаваща устройството, към което тези линкове са свързани. За MLAG-парата (стеки, фабрики и т.н.) стойността на system-id за устройствата, образуващи агрегирания интерфейс, е еднаква. Комутаторът D1 изпраща в Link 1 стойността system-id D, а комутаторът D2 изпраща в Link 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 работи коректно с трансивъра, използван за Link 2, че портът за свързване е преминал в състояние Up, и че при предаване на LACPDU не възникват грешки на порта за свързване.
Но фактът, че комутаторът D2 за агрегрирания интерфейс Po A от страна на Link 2 получава стойност system-id N, различна от текущата работеща стойност system-id A, не позволява на комутаторите D да въведат Link 2 в състава на агрегрирания интерфейс Po A. Комутаторът N не може да въведе Link 2 в експлоатация, тъй като не получава потвърждение за работоспособността от LACP-партньора на комутатора D2. В крайна сметка, трафикът по Link 2 не се предава.
А сега изключваме Link 1 от комутатора A1, като по този начин лишаваме комутаторите А и D от работещ агрегриран интерфейс. По този начин, от страната на комутатора D изчезва текущата работеща стойност system-id за интерфейса Po A.
Това позволява на комутаторите D и N да се договорят за обмен на system-id A-N на интерфейсите Po A и Po DN, така че трафикът започва да се предава по линка Link 2. Прекъсването в този случай е, в практика, до 2 секунди.
А сега спокойно прехвърляме Link 1 към комутатор N1, възстановявайки капацитета и нивото на резервиране на интерфейсите. Po A и Po DN. Тъй като при свързването на този линк не се променя текущата стойност system-id от нито една страна, не възниква прекъсване.
Допълнителни линкове
Но прехвърлянето може да се извърши без присъствието на инженер в момента на прехвърлянето. За това ни е нужно предварително да прокараме допълнителни линкове между комутаторите за дистрибуция D и новите комутатори за агрегация N.
Ние прокарваме нови линкове между комутаторите за агрегация N и комутаторите за дистрибуция на всички POD. Това изисква поръчка и прокарване на допълнителни патч-кабели и инсталиране на допълнителни трансивъри както в N, така и в D. Можем да го направим, тъй като в комутаторите D на всеки POD имаме свободни портове (или предварително ги освобождаваме). В крайна сметка всеки POD е физически свързан с две връзки към старите комутатори А и към новите комутатори N.
На комутатора D са формирани два агрегирани интерфейса — Po A с връзките Link 1 и Link 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.
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 е вече друг въпрос, и ако решим да го върнем, това ще стане без прекъсване на връзката.
Общо
След всички тези действия наистина заменихме комутаторите за агрегация в един от нашите дата-центрове, като минимизирахме прекъсванията за нашите клиенти.
След това остава само демонтаж. Демонтаж на старите комутатори, демонтаж на старите връзки между комутаторите A и D, демонтаж на трансиверите от тези връзки, корекция на мониторинга, корекция на схемата на мрежата в документацията и мониторинга.
Комутаторите, трансиверите, патч-кордовете, AOC, DAC, останали след превключванията, можем да използваме в други проекти или при други подобни превключвания.
«Наташ, всичко сме превключили!»
Източник: habr.com
