В нашата локална мрежова агрегация имахме шест чифта суичове Arista DCS-7050CX3-32S и една двойка суичове Brocade VDX 6940-36Q. Не че бяхме прекалено напрегнати от превключвателите Brocade в тази мрежа, те работят и изпълняват функциите си, но ние подготвяхме пълна автоматизация на някои действия и нямахме тези възможности на тези превключватели. Също така исках да премина от 40GE интерфейси към възможност за използване на 100GE, за да направя резерв за следващите 2-3 години. Затова решихме да сменим Brocade на Arista.
Тези комутатори са комутатори за агрегиране на LAN за всеки център за данни. Разпределителните комутатори (второто ниво на агрегиране) са директно свързани към тях, които вече сглобяват локални мрежови комутатори Top-of-Rack в стелажи със сървъри.
Всеки сървър е свързан към един или два комутатора за достъп. Превключвателите за достъп са свързани към двойка разпределителни превключватели (два разпределителни превключвателя и две физически връзки от превключвателя за достъп към различни разпределителни превключватели се използват за резервиране).
Всеки сървър може да се използва от собствен клиент, така че на клиента се разпределя отделна VLAN. След това същият VLAN се регистрира на друг сървър на този клиент във всеки шкаф. Центърът за данни се състои от няколко такива реда (POD), като всеки ред стелажи има свои собствени разпределителни превключватели. След това тези разпределителни превключватели се свързват към агрегиращи превключватели.
Клиентите могат да поръчат сървър във всеки ред; невъзможно е предварително да се предвиди, че сървърът ще бъде разпределен или инсталиран в конкретен ред в конкретен шкаф, поради което има около 2500 VLAN на комутатори за агрегиране във всеки център за данни.
Оборудването за DCI (Data-Center Interconnect) е свързано към комутатори за агрегиране. Може да бъде предназначен за L2 свързаност (двойка комутатори, образуващи VXLAN тунел към друг център за данни) или за L3 свързаност (два MPLS рутера).
Както вече писах, за да се обединят процесите на автоматизиране на конфигурацията на услугите на оборудването в един център за данни, беше необходимо да се сменят превключвателите за централно агрегиране. Инсталирахме нови комутатори до съществуващите, комбинирахме ги в двойка MLAG и започнахме да се подготвяме за работа. Те бяха незабавно свързани със съществуващи комутатори за агрегиране, така че да имат общ L2 домейн във всички клиентски VLAN.
Подробности за веригата
За подробности, нека назовем старите превключватели за агрегиране A1 и A2, ново - 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 агрегиран интерфейс с името Порт-канал А, от страната на превключвателите за агрегиране А - агрегиран интерфейс с името Порт-канал D.
Агрегираните интерфейси използват LACP в работата си, т.е. комутаторите от двете страни редовно обменят LACPDU пакети и на двете връзки, за да се уверят, че връзките:
- работа;
- включени в една двойка устройства от отдалечената страна.
При обмен на пакети, пакетът носи стойността системен идентификатор, посочвайки устройството, където са включени тези връзки. За двойка MLAG (стек, фабрика и т.н.) стойността на системния идентификатор за устройствата, които формират агрегирания интерфейс, е една и съща. Превключване D1 изпраща до Link 1 значение системен идентификатор D, и превключете D2 изпраща до Link 2 значение системен идентификатор D.
Превключватели A1 и A2 анализирайте LACPDU пакети, получени през един Po D интерфейс и проверете дали системният идентификатор в тях съвпада. Ако системният идентификатор, получен чрез някаква връзка, внезапно се различава от текущата работна стойност, тогава тази връзка се премахва от агрегирания интерфейс, докато ситуацията не бъде коригирана. Сега от нашата страна на превключвателя D текуща стойност на системния идентификатор от LACP партньора - A, и от страната на превключвателя А — текуща стойност на системния идентификатор от LACP партньора — D.
Ако трябва да превключим агрегирания интерфейс, можем да го направим по два различни начина:
Метод 1 – прост
Деактивирайте и двете връзки от превключватели A. В този случай агрегираният канал не работи.
Свържете двете връзки една по една към превключвателите N, тогава работните параметри на LACP ще бъдат договорени отново и интерфейсът ще бъде формиран По Д на превключватели N и предаване на стойности по връзки системен идентификатор N.
Метод 2 - Минимизиране на прекъсването
Изключете връзка 2 от превключвател A2. В същото време трафикът между А и D ще продължи да се предава просто през една от връзките, която ще остане част от обобщения интерфейс.
Свържете връзка 2 към превключвател N2. На превключвателя N агрегираният интерфейс вече е конфигуриран Po DN, и превключете N2 ще започне предаване към LACPDU системен идентификатор N. На този етап вече можем да проверим дали превключвателят N2 работи правилно с трансивъра, използван за Link 2, че портът за връзка е влязъл в състояние Upи да не възникват грешки на порта за връзка при предаване на LACPDU.
Но фактът, че превключвателят D2 за агрегиран интерфейс По А отстрани Връзка 2 получава системен идентификатор N стойност, различна от текущата операционна системна идентификатор A стойност, не позволява превключвания D въведете Link 2 част от агрегирания интерфейс По А. Превключване N не може да влезе Link 2 в експлоатация, тъй като не получава потвърждение за работоспособност от LACP партньора на комутатора D2. Полученият трафик е Link 2 не преминавам.
И сега изключваме връзка 1 от превключвател A1, като по този начин лишава ключовете А и D работещ агрегатен интерфейс. Така че от страната на превключвателя D текущата работна стойност на system-id за интерфейса изчезва По А.
Това позволява превключвания D и N съгласете се да обмените системен идентификатор AN на интерфейси По А и Po DN, така че трафикът да започне да се предава по връзката Link 2. Паузата в този случай на практика е до 2 секунди.
И сега можем лесно да превключим Link 1 към N1, възстановяване на капацитета и нивото на излишък на интерфейса По А и Po DN. Тъй като, когато тази връзка е свързана, текущата стойност на системния идентификатор не се променя от никоя страна, няма прекъсване.
Допълнителни връзки
Но превключването може да се извърши без присъствието на инженер по време на превключването. За да направим това, ще трябва предварително да поставим допълнителни връзки между разпределителните комутатори D и нови комутатори за агрегиране N.
Полагаме нови връзки между комутаторите за агрегиране N и разпределителни превключватели за всички POD. Това изисква поръчване и полагане на допълнителни кабели за свързване и инсталиране на допълнителни трансивъри, както в N, и в D. Можем да направим това, защото в нашите ключове D Всеки POD има безплатни портове (или ние ги освобождаваме предварително). В резултат на това всеки POD е физически свързан чрез две връзки към старите превключватели A и към новите превключватели N.
На превключвателя D формирани са два агрегирани интерфейса - По А с връзки Link 1 и Link 2И По Н - с връзки Линк N1 и Линк N2. На този етап проверяваме правилната връзка на интерфейсите и връзките, нивата на оптичните сигнали в двата края на връзките (чрез DDM информация от комутаторите), можем дори да проверим производителността на връзката при натоварване или да наблюдаваме състоянията на оптични сигнали и температури на трансивъра за няколко дни.
Трафикът все още се изпраща през интерфейса По А, и интерфейса По Н не струва трафик. Настройките на интерфейсите са нещо подобно:
Interface Port-channel A
Switchport mode trunk
Switchport allowed vlan C1, C2
Interface Port-channel N
Switchport mode trunk
Switchport allowed vlan noneD превключвателите, като правило, поддържат преконфигуриране на сесията; използват се модели на превключватели, които имат тази функционалност. Така че можем да променим настройките на 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 комутатори.
Не сменихме връзките „една по една“ с прекъсване само докато съгласувахме нова двойка системен идентификатор, тъй като нямахме 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, останали след превключване в други проекти или за друго подобно превключване.
„Наташа, променихме всичко!“
Източник: www.habr.com