Dneska to nebude moc o mně a o těch projektových věcech, ale bude to skutečně spíše o té technice tak, jak jsme slíbili. Minule jsem se vyjádřil dost, měl jsem dost prostoru, tak dneska to nechám spíš kolegovi.

Z té projektové části je akorát potřeba říci, že ty věci, o kterých se budeme bavit, částečně vycházeli z původní koncepce a z technologického stacku, jak jsme si ten projekt naplánovali. S nějakými historickými znalostmi a zkušenostmi jsme naplánovali řešení, které bylo postavené na jedné technologii a pak vlastně na radu výrobce jsme zvolili novější a modernější technologii.

Schválně neříkám ty zkratky, protože se přiznám, že si s nimi nejsem úplně jistý, tak to radši nechám na kolegovi, abych tu neřekl něco špatně a dám mu radši rovnou slovo, a když, tak do toho někde vstoupím a doplním věci s ohledem na dopad na projekt, kdy to mělo vliv na čísla, termíny apod.

Na dnešek tady budeme mít hlubší témata ohledně podvozku a síťařiny. První téma bude SAN (Storage Area Network) a budeme řešit, jak jsme to kompletně zapojili, jak to používáme, jaké prvky a porty máme, o jakých rychlostech.

Naše storage jako takové mají dvě síťovky a ta má každá dva porty 100 Gbps. Vše je nakonfigurováno tak, aby to bylo ve vysoké dostupnosti, neboli v případě, že nám nějaký port selže, modul by byl vadný nebo se něco stane s optikou popřípadě byl problém s celým switchem nebo síťovou kartou, tak máme k dispozici druhou síťovku, port nebo switch, který je 24/7 schopen převzít plnou zátěž celého serveru a zákazník vůbec nepozná, že bychom my, jako provozovatel, měli nějaký problém na síti nebo na nějaké části naší infrastruktury.

K tomu jsme zvolili 100 Gbps linky s tím, že je máme ke storage jako takovým a naše výpočetní servery jsou připojeny 4×25 Gbps linkami, což je pro nás v tuto chvíli dostatečné. Kompletně jsme oddělili datovou část od storagové části, tak v případě, že nějaký server potřebuje hodně přistupovat k nějakému disku, tak to neovlivní jakkoli propustnost do internetu ani v rámci jednotlivých virtuálních serverů, které mohou ležet na jiných fyzických strojích.

Proč jsme nezvolili EFC a jdeme touto cestou?

Je to jedna technologie, takže nepotřebujeme mít jiné moduly, síťovky, máme jen dva switche a máme jedno kompletní řešení, nechci říct od jednoho výrobce, ale co se týče síťařiny, tak máme jednoho vendora, kterého jsme si zvolili a díky tomu, v případě, že budeme mít nějaký problém na síti, na modulu, na optice, na čemkoli, tak můžu vzít jakýkoli jiný optický modul, který máme, a jen udělám cvak cvak a jedeme dál. Nemusí řešit, jaký zrovna máme typ modulu, jaký máme kabel, co tam vlastně je a odkud kam je co zapojené. Kvůli tomu jsme zvolili toto řešení.

To je tedy ta storage část a network jako takový. Díky tomu, že tam máme 100 Gbps linky, tak jsme řešili, abychom měli co nejvyšší možnou propustnost a abychom co nejméně zatěžovali CPU s RAM protože víme, že čím více datové propustnosti nám teče přes síťovky, tak nějaký prostředek je musí obsluhovat, což je procesor. Čím více paketů obsluhuje a čím větší je datová propustnost přes jednotlivé porty, tak je i vyšší zátěž. Díky tomu jsme začali navyšovat MTU.

Navýšili jsme je ze základních 1500 B na 9100 B a nějaké drobné. To je nejvyšší možná hodnota switchů, které máme použité. S tím začalo naše peklo, jelikož se to jmenuje co se po…kazilo, tak samozřejmě jsme začali hned zjišťovat, že ne všechno, co by mělo krásně fungovat, funguje.

Servery krásně fungovaly na 9000 B, ale pouze v rámci switche. Takže v rámci switche bylo všechno v pořádku, ale v případě, kdy jsme dělali trhací testy a polovinu sítě jsme odpojili a jedna část serverů běžela přes jeden switch a  jedna část přes druhý switch přes technologii, kterou budu zmiňovat následně, tak jsme nebyli schopni vymáčknout MTU vyšší jak 8000 a stále jsme řešili co a proč, až jsme to řešili s výrobcem a různě v knowledge base, co a jak jsme kde zapomněli nakonfigurovat, jelikož základní řešení bylo, že pojedeme všechno 1500 B a nebudeme to řešit. Ale abychom co nejvíce odlehčili serverům, tak jsme začali navyšovat a začali jsme pomalu, ale jistě konfigurovat switche. A kde jsme si mysleli, že všechny jednotlivé části jsou potřeba, až jsme na to strávili asi dva dny v přepočtu, kdy jsme od rána do večera jednom hledali, kde se nám ztrácí MTU a kde chybí a dochází k tomu, že 9000 B nám neproteče mezi switchema, ale jen v rámci jednoho switche.

To jsme zjistili, že je díky vxlan, čímž se dostávám k další technologii. První technologie, jako taková, jelikož jsme zvyklí, tak jsme si mysleli, že tyto dva switche postavíme jakožto Virtual Chassis Fabric, neboli tyto dva fyzické switche propojíme do jednoho virtuálního a budeme ho konfigurovat tak, jak jsme zvyklí. Máme dva fyzické boxy a já se přes jednu IP adresu připojím na nějaký management a oba dva boxy mi udělají jeden virtuální a já budu mít všechno z pohodlí jednoho terminálu, budu vše konfigurovat z jedné řádky a nebudu muset skákat zleva, zprava.

To se nestalo. Díky doporučení od výrobce, jelikož chceme mít co nejvyšší dostupnost, nejlépe 100 % uptime, tak nám doporučil technologii EVPN, abychom si vlastně z těchto boxů postavili EVPN VXLAN Fabric, abych do budoucna mohli škálovat a nebyli omezení vendor lock-inem, model lock-inem, protože v případě Virtual Chassis Fabric – bude to určitě u jiných výrobců – propojit můžete pouze buď stejné modely, které tuto technologii podporují, a ne všechny modely ji podporují, popřípadě hodně podobné modelové řady. Například když mám modelovou řadu 3300, tak třeba 4400 řadu nedokážu mezi sebou propojit do VCF, protože to prostě nepodporuje. Možná by to šlo propojit, ale v rámci technologií by to bylo hodně náročné pro toho výrobce. Díky tomu se začala implementovat EVPN s tím, že v tomto případě se všechny tyto problémy odstraní, takže když teď máme dva switche, tak můžeme nakoupit jakýkoli jiný switch, který tuto technologii podporuje, a můžeme dále škálovat. Nejsme omezení konkrétním modelovým typem, ale můžeme nakoupit libovolný modelový typ a ve finále i od jakéhokoli jiného vendora a můžeme jít dál a nejsme omezení.

Celou technologii se takto snažíme držet, abychom byli co nejméně omezovaní.

Co se týče virtual chassis, EVPN a těch MTU, tak jelikož je to EVPN VXLAN Fabric, tak VXLAN si jako taková bere na vlastní režii 50 B, což jsme se začátku úplně nevěděli, protože je to pro nás nová technologie. My jsme všude na začátku nastavili MTU 9016. Jelikož jsme měli jeden server na straně A a jeden na straně B, mělo nám to proskočit přes tu VXLAN. Protože tam byla, v datovém rámci nám chybělo 50 B, což jsme zjistili následně až v dokumentaci, když jsme hledali v knowledge base a s pomocí od výrobce, a navýšili jsme MTU na switchích na maximální možný, což je u nich asi 9206 B. Tento problém vymizel, takže můžeme mít 50 B na režiji VXLAN a následně i pro VLAN a pořád máme možnost využít 9000 B čistě pro přenos dat mezi switchema a z jednoho serveru na druhý switch.

Ještě bych se vrátil k rozpletům z minula. Ti, kteří jste tu byli posledně, tak jsme řešili rozplety a otočené síťové karty na Intel computech, a jelikož máme EVPN Fabric, už nemáme Virtual Chassis Fabric, tak v konečném důsledku by se AE s LACPI chovalo stejně, jenom bychom na to asi přišli o trochu dřív.

V EVPN Fabric nemáme jeden virtuální switch, ale máme dva fyzické, takže když budu potřebovat něco konfigurovat, musím jít do jednoho switche, potom do druhého switche. Na jednu stranu je to super, na druhou stranu, co udělám na jednom, musím jít i na druhý a udělat 1:1 konfiguraci.

Na jedne stranu je to dobré, protože je to oddělené, na tu konfigurační část je to zdlouhavější, protože musím dělat věci dvakrát. Ale v rámci bezpečnosti a provozuschopnosti to má daleko více výhod.

Jaké?

V případě, že mám Virtual Chassis Fabric a EVPN, tak když to vezmu na náš Virtual Chassis Fabric, kde máme switch, tak když jsme dělali trhací testy, jelikož jsme měli switch v divnostavu, tak jsem začal rebootovat všechny switche mezi sebou, aby nedošlo k výpadku ostatních switchů. Všechno mělo krásně vypadat tak, že já přijdu do VCF, dám reboot jednoho membra a nic se nestane. Jenom lidi, kanceláře  počítače, které jsou na tom konkrétním switchi, který se restartuje, tak budu mít výpadek.

Udělal jsem to 6x a toto chassis se mi rozpadlo pokaždé takovým způsobem a do takového stavu, že se potom celé stejně muselo restartovat, protože nebyly správně zapojené všechny porty, což se zjistilo až následně. Došlo k tomu, že v tomto chassis máme 6 switchů – jeden má permanentní roli master, druhý je neustále v roli back-up. Když se cokoli stane s masterem – například ho manuálně zrestartuju nebo by mu vypadlo napájení nebo se stalo cokoli jiného na úrovni systému nebo hardwaru – a dělá ten virtuální switch, tak back-up část převezme veškerou jeho provozní schopnost.

Bohužel, to není ihned a je to většinou 1 minuty. Máme otestováno, že to je 20 – 40 sekund. Takový výpadek pod cloudovou částí je pro nás kritický, protože nevidíte, co se děje a musíte to řešit ihned. Nechceme, aby zákazníci trpěli nějakým 20 sekundovým výpadkem, protože se něco někde stalo.

EVPN toto všechno řeší, protože každý switch je stand-alone a v případě, že se stane něco s jedním switchem ,tak EVPN na druhé části je non-stop v aktivní roli. Kdykoli na ni cokoli přijde, tak ona to zpracuje. Není to tak, že ona ten provoz přehodí na druhou část, ale provoz, který jde na A nebo B switch, tak se zpracuje tím konkrétním switchem a buď se pošle zpátky na nějaký server nebo se pošle do internetu. To je tedy vše k virtual chassis a EVPN. To je důvod, proč jsme zvolili EVPN VXLAN Fabric a nikoli Virtual Chassis Fabric.

Takže tam není ta prodleva, než se rozhodne, že se master přepíná na slave?

Přesně. A než převezme kompletně všechny činnosti, než naleje veškerou konfiguraci, která byla na masteru, do těch line card switchů. Switche se musí v tu chvíli naučit všechny MAC adresy a začít fungovat. K tomu následně mířím, co se týče upgradu.

Musíme řešit bezpečnostní záplaty a nové features do budoucna. (Asi by to bylo dobře). Co se týče upgradů, v rámci Virtual Chassis konkrétní verze podporují tzv. non-stop upgrade s tím, že toto chassis by se mělo dokázat rozdělit na dvě poloviny. Ta jedna je v upgradu, druhá normálně funguje. Pak ta původní část přehodí komunikaci na nově upgradovanou část a sama se upgraduje na aktuální verzi. Celé virtual chassis se pak složí do jednoho.

Bohužel ne všechny verze tuto funkci podporují. Je to funkcionalita, kterou někteří výrobci tlačili a už je to pár let zpátky. To v případě EVPN nehrozí, protože když se nyní rozhodnu, že půjdu upgradovat jeden switch, tak jen povypínám porty, které nechci, aby byly ovlivněné. Když budu upgradovat, tak po zapnutí switche nechci, aby přebíral plnou provozuschopnost. Může tam být chyba v konfiguraci, například mezi majoritními verzemi, může tam být nějaká změna, už jsme si tím v minulosti prošli, kdy se nám změnily názvy portů, to se může stát. Když někdo nečte changelog – je to dobré číst je – když se na tohle nemyslí, tak se může stát úplně cokoli.

Takže je důležité to zkontrolovat. Samozřejmě – než switch opět pošlu nazpátek do produkce, tak je nutné si všechno ověřit, a ve chvíli, kdy uznám za vhodné, že je v pořádku a schopný provozu, tak ho nazpátek připojím do EVPN a budu mít opět dva switche v aktivní režii a budeme mít load balancing.

To je k technologiím jako takovým vše.

On někdo čte change logy?

Teď je vidět, že to je třeba. A musím říct, že u ná už technici začali dokonce občas číst i manuály. Až tak hluboko jsme klesli a daleko se dostali. Ono to prostě začíná být potřeba. Ty změny jsou zásadní a to, co zmiňoval Vašek, byl docela velký point v technologii, protože když se mezi jednotlivými verzemi operačního systému změní pojmenování portů, které používáme, tak když to nevíte dopředu, tak se z toho zblázníte. 

Najednou vám tam začnou skákat věci, se kterými nepočítáte, a navíc když to děláte na úrovni vysoké dostupnosti technologií, tak se vám to změní jen na půlce a na té druhé ne. N+které věci tedy nemůže najít, najednou tam nejsou, jmenuje se to jinak, takže se z toho blbne. 

Tohle je přesně důvod, proč ty change logy číst a dívat se na to, co se tam mění. Nehledě na to, že vám ty change logy také řeknou, jestli nejsou ovliněné některé technologie, které používáte, nějakým potenciálním bugem. Ty operáky se nenasazují ve chvíli kdy vyjdou, to dělá jenom sebevrah. 

Nasazuje se to s nějakým odstupem a s nějakou znalostí, co v té verzi funguje a nefunguje a jaké technologie jsou ovlivněné. Takže to prostě nejde střílet tak, že včera vyšla nová verze, tak to tam jdeme nalít.

Toto dělejte pouze v laboratorních podmínkách, kde si můžete dovolit výpadek a testování těchto jednotlivých nových vydání, protože v případě, že se vám tohle stane na produkci, když může být nějaký bug takový, že vám to klidně způsobí kernel panic na switchi – co s tím budete na dálku dělat, když s tím switchem nedokážete v tu chvíli nic udělat. Opravdu ty change logy raději čtěte.

První věc je přečíst change log, druhá věc je vyzkoušet to v labu, mít ty prostředky, nebýt punkáč a nestřílet to do produkce rovnou, což se často také děje, takže to samozřejmě má nějaké nároky na to, že to vybavení musíte mít k dispozici. Mít nějaký ten lab, kde se to dá vyzkoušet. Není to levné, stojí to peníze, ale je to potřeba, protože pokud máte potom zajistit provoz s nějakou odpovídající kvalitou, tak to je prostě třeba udělat.

A i stejně, když si to projdete, otestujete a vyzkoušíte v labu, tak stejně nemáte jistotu, že v té produkci nenastane nějaký problém. Ale uděláte maximum pro to, abyste tomu předešli.

Minule jsme ještě slíbili jedno téma, a to je migrace. My se tady sice bavíme o tom, že jsme stavěli nový cloud a tohle se po…kailo, tak se pojďme podívat také na jednu věc, která se po…vedla.

Migrace se nepokazila, migrace se povedla. Já už jsem to tu částečně říkal minule. Ne, že by byla bez problémů, ty problémy byly způsobené spíše vnějšími okolnostmi, než technickými věcmi. Jak jsem zmiňoval posledně, z plánovaných termínů a časů, které jsme na to měli, z různých vnějších důvodů se čas hodně zkrátil a byli jsme tlačeni to dělat ve zrychleném režimu, což samozřejmě zvedlo tlak na techniky s těmi maratony, co jsem tu minula zmiňoval, že mě pár dní nezdravili, ale ono se to povedlo, stihlo se to, udělalo se to. Částečně díky tomu, že ty technologie byli dobře připravené, částečně díky tomu, že máme dobrý tým a jsou ochotní nasadit víc než je nutné, takže za to je vždycky rád pochválím a poděkuju jim za to.

A nikomu je nedám! Jsou moji! Kdyby mmi je chtěl náhodou někdo přetahovat.

Reálně nenastal žádný problém kromě toho časového presu, který tam byl. To, co samozřejmě se naplánovalo, tak tam žádná migrace být neměla. Ten projekt jako takový s žádnou migrací na začátku nepočítal, protože, jak jsme zmiňovali minule, stavěli jsme to jako rozšíření původních kapacit.

V průběhu času se ten set-up změnil, změnilo se určení a ve finále jsme skončili s úplně samostatným provozním celkem, takže ve finále to byla kompletní migrace z jednoho cloudu/poskytovatele/datového centra/serverů do úplně jiného – technologicky odděleného, konfiguračně nepropojeného.

V tom nám pomohli ty technologie, které Vašek zmiňoval, protože jsme byli schopní si tam postavil nějaké síťové propojení napříč datovými centry a lokalitami, protože se to přesouvali mezi dvěma datovými centry mezi různými městy. Tohle vše nám pomohlo, že jsme byli schopní vzít zákazníky z provozu, kde byli, a z cloudu, kde byli, a přesunout je do toho našeho cloudu.

Takže z jejich pohledu to vlastně byla odstávka těch jednotlivých serverů jen na dobu reálného přenesení dat z jednoho cloudového prostředí do druhého. Byli jsme pouze limitovaní rychlostí sítí, kterou jsme byli schopní mezi  těmi datovými centry získat, ale jinak všechno ostatní pro ně zůstalo funkčně stejné.

V podstatě se jim změnilo prostředí akorát s tím, že začali používat novou platformu, nové technické řešení od nás, ale provozně zůstal ten systém úplně stejný, takže to bylo bohužel s odstávkou, ale na druhou stranu naši zákazníci nám v tomhle vyšli vstříc, takže jsme to připravili tak, aby to časově co nejméně omezilo jejich provoz a ty migrace proběhly velmi rychle.

Stejně tak, jako jsme schopní rychle adaptovat zákazníky a přenést je k nám, tak tímhle způsobem jsme schopní je i relativně snadno od nás vystřelit ven. Ono to k tomu patří, protože někdy je ta migrace potřeba. Zákazník se ptá, jakým způsobem se od nás dostane, jakým způsobem, když už k nám jednou vstoupí, tak dostane ta data od nás. Tím, že máme technologický výpočetní část oddělenou od datové, tak konfigurace virtuálek je separátní a nemá vliv na data, která jsou uložena ve storage. Záleží jen na tom, jakým způsobem si je chcem odnést. Jsou to v podstatě image v QCOW2 a jestli si je přetáhne po síti nebo přenese na storage, na kterou to nalejeme, nebo se propojí VPN, a tak se to pošle, my s tou migrací nemáme technicky žádný problém. Tenhle formát není problém převést na jiný. Tak, jako zákazníky migrujeme z VMware nebo Hyper V, prostě se převádí formát disků, tak stejným způsobem se data dokážou převést zpátky a funguje to kdekoli jinde.

Tohle byla v podstatě jediná technická komplikace, že jsme museli zajistit propojení s původním poskytovatelem co se týče síťařiny. Tyhle nové technologie nám k tomu daly nástroj, daly nám tu možnost, takže ta migrace probíhala tak, že se ta data přenášela, takže ta odstávka byla na tu dobu, než přetekly data z jednoho prostředí do druhého. Zákazníci ve finále to akceptovali a neměli s tím problém, naplánovalo se to tak, aby je to minimálně ovlivnilo, takže to většinou probíhalo v noci nebo o víkendu.

Prostě si řekli, jak oni můžou mít tu danou odstávku, a my jsme se pokusili co nejvíce přizpůsobit.

Kvůli tomu toho kluci moc nenaspali – jelikož to bylo vesměs v noci a o víkendech – ale nemáme jedinou stížnost od zákazníka, že by ta migrace proběhla s nějakým problémem.

Tím pádem si myslím, že to sem vlastně nepatří.

Ale je dobře, že jsme tím mohli zakončit.

My se určitě rádi pochlubíme.

Poklepat se po rameni, to vám jde.

Takhle s odstupem času už jo. Když to doběhlo a bylo to čerstvé, tak se mnou několik dní kluci nemluvili.

My nechtěli mluvit vůbec s nikým protože kdokoli k nám přišel, tak to bylo honem, honem, včera samozřejmě bylo pozdě. Ale holt když je takový větší projekt, tak to k tomu patří, jinak by to nebyl projekt.

Ale zvládli to dobře. A říkám, nepatří to sem, protože se to ne po…kazilo, ale po…vedlo.

Tak my to vystříhávat nebudeme, když už jsme se tu o tom tak hezky pobavili, ale je potřeba po všech těch patáliích si říct, že výsledek stojí za to.

Jsme s tím spokojení. Technologicky jsme se posunuli, zlepšili, máme to víc pod kontrolou, je to naše řešení. Přešli jsme z něčeho, co jsme měli pronajaté a hostované, neměli jsme to plně pod kontrolou. Teď je to naše vlastní řešení, na našem vlastním železe, otevírá nám to spoustu nových možností v tom, co můžeme dělat. Je to určitě krok, který jsme si dlouho rozmýšleli, dělali jsme ho v době, která nebyla vůbec příznivá – blbějc jsme si to naplánovat nemohli. Ale udělali jsme ho a dneska jsme za to rádi a myslíme si, že s tím pohledem zpětně to byl správný krok a že nás to někam posouvá. A rozhodně to nehodnotíme negativně, ale myslíme si, že nám to otevírá cestu k dalšímu rozvoji a možnostem, co vlastně v cloudu dělat, zákazníkům nabídnout. Klukům to do ruky dává nové hračky a nové věci, které si můžou zkoušet i jiným způsobem. I viz třeba upgrady a správa zařízení.

To, čím jsme vlastně byli závislí na někom jiném, dneska máme plně pod kontrolou. Můžeme si to naplánovat, můžou si to klucí otestovat, mají tu laboratoř, aby jsme všechno mohli dělat profesionálně a nešli jsme do toho bezhlavě, ale abychom udělali maximum pro to, abychom při těchto změnách a činnostech, které se dělat musejí, tak aby byl dopad na zákazníky co nejmenší, optimálně, aby o tom vůbec nevěděli – v laboratoři mají veškeré vybavení, které reálně provozujeme.

Což se skoro povedlo. Nějaká odstávka se vždycky udělat musí.

Ty upgrady se naplánovat musí, my o tom zákazníky informujeme, ale teď, jak je ten systém postavený, tak vlastně by o tom měli vědět jenom z těch emailů.

A jenom vy byste o tom měli vědět.

Přesně, my, kteří tam budeme sedět, když náhodou se něco stane, a co s tím budeme dělat.

A toto by se právě díky laboratoři nemělo stát, samozřejmě. Ale známe, jak to je v reálném světě.

Viz i ta otázka s change logama.

Přesně. Pár dní dopředu načíst change logy, z upgradovat, vyzkoušet konfigurace a pak do produkce.

Přemýšlím, čím to shrnout za tu projektovou část. Jak jsem říkal na začátku, nevešli jsme se do času, v podstatě jsme se vešli do rozpočtu, i s těmi strašnými změnami a problémy, které kolem toho byly. To je vlastně pozitivní. To, že jsme se nevešli do času, ve finále v podstatě z toho provozního hlediska až tolik nevadilo. Ten tlak samozřejmě byl větší na kluky, protože některé věci, které měli naplánované na rozumnější čas a termíny, aby si u toho měli možnost trochu odpočinout a nebýt v práci téměř nonstop a pořád vzhůru, tak to úplně neklaplo.

Ale nicméně ty porjekty vždycky takové jsou. Není projekt, kde se povede všechno, je potřeba počítat s tím, že se něco nepovede a pak už záleží jenom na tom, jak se s tím člověk vypořádá.

Myslím, že všechny ty věci, které nás potkaly, vedly spíše k tomu, že se ten projekt se zlepšil, že je to technické řešení lepší, provoz je pro nás rozumnější a pro nás přívětivější, lepší, máme ho víc pod kontrolou, voc ho máme v ruce. Máme vpodstatě svoje řešení, takže z tohohle pohledu, když pomineme, že ten projekt byl delší, než bylo plánované, tak pro nás to vlastně mělo jen pozitiva. I když to někdy byla hororová díla.