Dnes vám poviem, ako sa zrodila a zrealizovala myšlienka vytvorenia novej internej siete pre našu spoločnosť. Pozícia manažmentu je taká, že musíte urobiť rovnaký plnohodnotný projekt pre seba ako pre klienta. Ak to robíme dobre pre seba, vieme zákazníka pozvať a ukázať, ako dobre funguje a funguje to, čo mu ponúkame. Preto sme k vývoju konceptu novej siete pre moskovskú kanceláriu pristúpili veľmi dôkladne, s využitím celého výrobného cyklu: analýza potrieb rezortu → výber technického riešenia → návrh → implementácia → testovanie. Tak začnime.
Výber technického riešenia: Mutant Sanctuary
Postup práce na komplexnom automatizovanom systéme je v súčasnosti najlepšie opísaný v GOST 34.601-90 „Automatizované systémy. Etapy stvorenia“, tak sme pracovali podľa toho. A už vo fázach tvorby požiadaviek a vývoja koncepcie sme narazili na prvé ťažkosti. Organizácie rôznych profilov – banky, poisťovne, vývojári softvéru a pod. – pre svoje úlohy a štandardy potrebujú určité typy sietí, ktorých špecifiká sú jasné a štandardizované. U nás to však nepôjde.
Prečo?
Jet Infosystems je veľká diverzifikovaná IT spoločnosť. Zároveň je naše oddelenie internej podpory malé (ale hrdé), zabezpečuje funkčnosť základných služieb a systémov. Spoločnosť obsahuje mnoho divízií, ktoré vykonávajú rôzne funkcie: ide o niekoľko výkonných outsourcingových tímov a interných vývojárov podnikových systémov a informačnej bezpečnosti a architektov výpočtových systémov – vo všeobecnosti, nech je to ktokoľvek. V súlade s tým sa líšia aj ich úlohy, systémy a bezpečnostné politiky. Čo podľa očakávania spôsobilo ťažkosti v procese analýzy potrieb a štandardizácie.
Tu je napríklad vývojové oddelenie: jeho zamestnanci píšu a testujú kódy pre veľký počet zákazníkov. Často je potrebné rýchlo zorganizovať testovacie prostredia a úprimne povedané, nie vždy je možné formulovať požiadavky pre každý projekt, požadovať zdroje a vybudovať samostatné testovacie prostredie v súlade so všetkými internými predpismi. Z toho vznikajú kuriózne situácie: jedného dňa sa váš skromný sluha pozrel do miestnosti vývojárov a našiel pod stolom správne fungujúci klaster Hadoop s 20 počítačmi, ktorý bol nevysvetliteľne pripojený k spoločnej sieti. Nemyslím si, že stojí za to objasniť, že IT oddelenie spoločnosti nevedelo o jej existencii. Táto okolnosť, podobne ako mnohé iné, bola zodpovedná za to, že počas vývoja projektu sa zrodil termín „mutant rezerva“, popisujúci stav dlhodobo trpiacej kancelárskej infraštruktúry.
Alebo tu je ďalší príklad. V rámci oddelenia sa pravidelne zriaďuje skúšobná stolica. To bol prípad Jira a Confluence, ktoré v obmedzenej miere využívalo Software Development Center v niektorých projektoch. Po určitom čase sa o týchto užitočných zdrojoch dozvedeli aj ďalšie oddelenia, vyhodnotili ich a koncom roka 2018 sa Jira a Confluence posunuli zo statusu „hračky lokálnych programátorov“ do stavu „firemných zdrojov“. Teraz musí byť k týmto systémom priradený vlastník, musia byť definované SLA, politiky zabezpečenia prístupu/informácií, politiky zálohovania, monitoringu, pravidiel pre smerovanie požiadaviek na opravu problémov – vo všeobecnosti musia byť prítomné všetky atribúty plnohodnotného informačného systému .
Každá naša divízia je zároveň inkubátorom, ktorý pestuje vlastné produkty. Niektoré z nich odumierajú vo fáze vývoja, niektoré používame pri práci na projektoch, zatiaľ čo iné sa udomácňujú a stávajú sa replikovanými riešeniami, ktoré sami začíname používať a predávať klientom. Pre každý takýto systém je žiadúce mať vlastné sieťové prostredie, kde sa bude vyvíjať bez zásahov do iných systémov a v určitom momente ho možno integrovať do podnikovej infraštruktúry.
Okrem vývoja máme veľmi veľké s viac ako 500 zamestnancami, formovanými do tímov pre každého zákazníka. Podieľajú sa na údržbe sietí a iných systémov, diaľkovom monitorovaní, riešení reklamácií a pod. To znamená, že infraštruktúra SC je v skutočnosti infraštruktúra zákazníka, s ktorým v súčasnosti pracujú. Zvláštnosťou práce s touto časťou siete je, že ich pracovné stanice pre našu spoločnosť sú čiastočne externé a čiastočne interné. Preto sme pre SC implementovali nasledujúci prístup - spoločnosť poskytuje príslušnému oddeleniu sieťové a iné zdroje, pričom pracovné stanice týchto oddelení považuje za externé spojenia (analogicky s pobočkami a vzdialenými používateľmi).
Dizajn diaľnice: my sme prevádzkovateľ (prekvapenie)
Po zhodnotení všetkých úskalí sme si uvedomili, že v rámci jednej kancelárie získavame sieť telekomunikačného operátora a podľa toho sme začali konať.
Vytvorili sme jadrovú sieť, pomocou ktorej je každému internému a v budúcnosti aj externému spotrebiteľovi poskytovaná požadovaná služba: L2 VPN, L3 VPN alebo bežné L3 smerovanie. Niektoré oddelenia potrebujú bezpečný prístup na internet, zatiaľ čo iné potrebujú čistý prístup bez brán firewall, ale zároveň ochranu našich podnikových zdrojov a základnej siete pred ich prevádzkou.
S každou divíziou sme neformálne „uzatvorili SLA“. V súlade s ním musia byť všetky vzniknuté incidenty odstránené v určitej, vopred dohodnutej lehote. Požiadavky spoločnosti na svoju sieť sa ukázali ako prísne. Maximálna doba odozvy na incident v prípade zlyhania telefónu a emailu bola 5 minút. Čas na obnovenie funkčnosti siete počas typických porúch nie je dlhší ako minúta.
Keďže máme sieť na úrovni operátora, môžete sa k nej pripojiť iba v prísnom súlade s pravidlami. Servisné jednotky stanovujú politiky a poskytujú služby. Nepotrebujú ani informácie o pripojeniach konkrétnych serverov, virtuálnych strojov a pracovných staníc. Zároveň sú však potrebné ochranné mechanizmy, pretože ani jedno pripojenie by nemalo zakázať sieť. Ak sa náhodne vytvorí slučka, ostatní používatelia by si to nemali všimnúť, to znamená, že je potrebná adekvátna odpoveď zo siete. Každý telekomunikačný operátor neustále rieši podobné zdanlivo zložité problémy v rámci svojej základnej siete. Poskytuje služby mnohým klientom s rôznymi potrebami a návštevnosťou. Rôzni predplatitelia by zároveň nemali pociťovať nepríjemnosti z prevádzky iných.
Doma sme tento problém vyriešili nasledovne: vybudovali sme chrbticovú L3 sieť s plnou redundanciou, pomocou protokolu IS-IS. Nad jadrom bola postavená prekryvná sieť založená na technológii /pomocou smerovacieho protokolu . Na urýchlenie konvergencie smerovacích protokolov bola použitá technológia BFD.
Štruktúra siete
V testoch sa táto schéma ukázala ako vynikajúca - keď je odpojený akýkoľvek kanál alebo prepínač, čas konvergencie nie je dlhší ako 0.1 - 0.2 s, stratí sa minimum paketov (často žiadne), TCP relácie nie sú prerušené, telefonické rozhovory nie sú prerušené.
Podkladová vrstva - Smerovanie
Prekryvná vrstva – Smerovanie
Ako distribučné prepínače boli použité prepínače Huawei CE6870 s licenciami VXLAN. Toto zariadenie má optimálny pomer cena/kvalita, čo vám umožňuje pripojiť účastníkov rýchlosťou 10 Gbit/s a pripojiť sa k chrbtici rýchlosťou 40–100 Gbit/s v závislosti od použitých transceiverov.
Prepínače Huawei CE6870
Ako jadrové prepínače boli použité prepínače Huawei CE8850. Cieľom je prenášať premávku rýchlo a spoľahlivo. Nie sú k nim pripojené žiadne zariadenia okrem distribučných prepínačov, nevedia nič o VXLAN, preto bol zvolený model s 32 portami 40/100 Gbps so základnou licenciou, ktorá poskytuje L3 smerovanie a podporu pre IS-IS a MP-BGP. protokoly .
Spodný je prepínač jadra Huawei CE8850
Vo fáze návrhu sa v rámci tímu rozprúdila diskusia o technológiách, ktoré by sa dali použiť na implementáciu pripojenia odolného voči chybám k uzlom základnej siete. Naša moskovská kancelária sa nachádza v troch budovách, máme 7 distribučných miestností, v každej z nich boli nainštalované dva distribučné spínače Huawei CE6870 (do niekoľkých distribučných miestností boli inštalované iba prístupové spínače). Pri vývoji koncepcie siete sa zvažovali dve možnosti redundancie:
- Konsolidácia rozvodných prepínačov do stohu odolného voči poruchám v každej prepojovacej miestnosti. Výhody: jednoduchosť a jednoduchosť nastavenia. Nevýhody: pri výskyte chýb vo firmvéri sieťových zariadení je vyššia pravdepodobnosť zlyhania celého zásobníka („úniky pamäte“ a podobne).
- Aplikujte technológie M-LAG a Anycast gateway na pripojenie zariadení k distribučným prepínačom.
Nakoniec sme sa rozhodli pre druhú možnosť. Je o niečo náročnejší na konfiguráciu, ale v praxi preukázal svoj výkon a vysokú spoľahlivosť.
Najprv zvážime pripojenie koncových zariadení k distribučným prepínačom:
Kríž
Prístupový prepínač, server alebo akékoľvek iné zariadenie, ktoré vyžaduje pripojenie odolné voči chybám, je súčasťou dvoch distribučných prepínačov. Technológia M-LAG poskytuje redundanciu na úrovni dátového spojenia. Predpokladá sa, že dva distribučné spínače sa javia pripojenému zariadeniu ako jedno zariadenie. Redundancia a vyvažovanie záťaže sa vykonáva pomocou protokolu LACP.
Technológia brány Anycast poskytuje redundanciu na úrovni siete. Na každom z distribučných prepínačov je nakonfigurovaný pomerne veľký počet VRF (každý VRF je určený pre svoje vlastné účely - samostatne pre „bežných“ používateľov, samostatne pre telefonovanie, samostatne pre rôzne testovacie a vývojové prostredia atď.) a v každom VRF má nakonfigurovaných niekoľko VLAN. V našej sieti sú distribučné prepínače predvolenými bránami pre všetky zariadenia, ktoré sú k nim pripojené. IP adresy zodpovedajúce VLAN rozhraniam sú rovnaké pre oba distribučné prepínače. Doprava je smerovaná cez najbližšiu výhybku.
Teraz sa pozrime na pripojenie distribučných prepínačov k jadru:
Odolnosť voči poruchám je zabezpečená na úrovni siete pomocou protokolu IS-IS. Upozorňujeme, že medzi prepínačmi je k dispozícii samostatná komunikačná linka L3 s rýchlosťou 100G. Fyzicky je táto komunikačná linka káblom s priamym prístupom, možno ho vidieť vpravo na fotografii prepínačov Huawei CE6870.
Alternatívou by bolo zorganizovať „čestnú“ plne prepojenú topológiu dvojitej hviezdy, ale ako už bolo spomenuté vyššie, máme 7 vzájomne prepojených miestností v troch budovách. Ak by sme teda zvolili topológiu „dvojitej hviezdy“, potrebovali by sme presne dvakrát toľko vysielačov a prijímačov „dlhého dosahu“ 40G. Úspory sú tu veľmi výrazné.
Je potrebné povedať niekoľko slov o tom, ako technológie VXLAN a brány Anycast spolupracujú. VXLAN, bez toho, aby sme zachádzali do detailov, je tunel na prenos ethernetových rámcov vo vnútri paketov UDP. Slučkové rozhrania distribučných prepínačov sa používajú ako cieľová IP adresa tunela VXLAN. Každý crossover má dva prepínače s rovnakými adresami spätného rozhrania, takže paket môže doraziť na ktorýkoľvek z nich a možno z neho extrahovať ethernetový rámec.
Ak prepínač vie o cieľovej MAC adrese načítaného rámca, rám bude správne doručený na miesto určenia. Aby sa zabezpečilo, že oba distribučné prepínače nainštalované v rovnakom prepojení majú aktuálne informácie o všetkých MAC adresách „prichádzajúcich“ z prístupových prepínačov, je mechanizmus M-LAG zodpovedný za synchronizáciu tabuliek MAC adries (ako aj ARP tabuľky) na oboch spínačoch M-LAG párov.
Vyvažovanie prevádzky je dosiahnuté vďaka prítomnosti niekoľkých trás v základnej sieti k rozhraniam spätnej slučky distribučných prepínačov.
namiesto záveru
Ako už bolo spomenuté vyššie, počas testovania a prevádzky sieť vykazovala vysokú spoľahlivosť (doba obnovy pri typických poruchách nie je dlhšia ako stovky milisekúnd) a dobrý výkon – každé cross-connect je spojené s jadrom dvoma 40 Gbit/s kanálmi. Prístupové prepínače v našej sieti sú naskladané a pripojené k distribučným prepínačom cez LACP/M-LAG s dvomi 10 Gbit/s kanálmi. Stoh zvyčajne obsahuje 5 prepínačov so 48 portami a až 10 prístupových stohov je pripojených k distribúcii v každom prepojení. Chrbtica teda poskytuje okolo 30 Mbit/s na používateľa aj pri maximálnej teoretickej záťaži, čo v čase písania článku postačuje na všetky naše praktické aplikácie.
Sieť vám umožňuje bezproblémovo organizovať párovanie ľubovoľných pripojených zariadení cez L2 aj L3, čím poskytuje úplnú izoláciu prevádzky (čo má rada informačná bezpečnostná služba) a poruchových domén (čo má rád operačný tím).
V ďalšej časti vám povieme, ako sme migrovali na novú sieť. Zostaňte naladení!
Maxim Klochkov
Senior konzultant skupiny sieťového auditu a komplexných projektov
Centrum sieťových riešení
"Informačné systémy prúdových lietadiel"
Zdroj: hab.com