Ahoj, Habr!
V tomto článku bychom rádi probrali automatizaci síťové infrastruktury. Budeme prezentovat pracovní schéma sítě, která funguje v jedné malé, ale velmi hrdé společnosti. Všechna shodování s reálným síťovým zařízením jsou náhodná. Podíváme se na případ, který se v této síti odehrál a mohl vést k zastavení podnikání na delší dobu a vážným finančním ztrátám. Řešení tohoto případu se velmi dobře zapadá do konceptu "Automatizace síťové infrastruktury". Pomocí automatizačních nástrojů ukážeme, jak efektivně řešit složité úkoly v krátkých lhůtách, a zamyslíme se nad tím, proč je výhodnější tyto úkoly řešit právě takto, a ne jinak (přes konzoli).
Poznámka
Hlavními nástroji pro automatizaci jsou pro nás Ansible (jako prostředek automatizace) a Git (jako úložiště playbooků Ansible). Hned je třeba poznamenat, že se nejedná o úvodní článek, kde mluvíme o logice fungování Ansible nebo Gitu, a vysvětlujeme základní věci (například, co jsou rolí, moduly, inventářové soubory nebo proměnné v Ansible, nebo co se stane při zadání příkazů git push nebo git commit). Tento příběh není o tom, jak se procvičovat v Ansible, nastavit na zařízení NTP nebo SMTP. Je to příběh o tom, jak rychle a ideálně bez chyb řešit síťový problém. Také je žádoucí mít dobré představy o tom, jak síť funguje, zejména co je to zásobník protokolů TCP/IP, OSPF, BGP. Výběr Ansible a Gitu také ponecháme stranou. Pokud pro vás stále stojí otázka konkrétního řešení, velmi doporučujeme přečíst knihu "Network Programmability and Automation. Skills for the Next-Generation Network Engineer" od Jasona Edelmana, Scotta S. Lowea a Matta Oswalta.
Teď k věci.
Formulace úkolu
Představme si situaci: 3 hodiny ráno, pevně spíte a sníte. Telefonní hovor. Volá technický ředitel:
— Ano?
— ###, ####, #####, cluster firewallů spadl a nezvedá se!!!
Utíráte si oči, snažíte se pochopit, co se děje, a představit si, jak se něco takového vůbec mohlo stát. Na druhém konci je slyšet, jak řediteli padají vlasy, a prosí, aby zavolal zpět, protože na druhé lince mu volá generální ředitel.
Po půlhodině jste shromáždili první informace od službu konající směny, probudili jste všechny, koho bylo možné probudit. Ve výsledku technický ředitel nelhal, všechno je tak, jak má být, hlavní cluster firewallů spadl a žádné základní kroky mu nepomáhají. Všechny služby, které společnost nabízí, nefungují.
Vyberte si problém podle svého vkusu, každý si vzpomene na něco jiného. Například po noční aktualizaci, kdy nebylo velké zatížení, všechno fungovalo dobře a všichni spokojení šli spát. Přišel provoz a začaly se přetěžovat vyrovnávací paměti rozhraní kvůli chybě v ovladači síťové karty.
Situaci dobře může popsat Jackie Chan.
Děkuji, Jackie.
Není to příliš příjemná situace, že?
Na chvíli necháme našeho síťového kamaráda s jeho smutnými myšlenkami.
Prodiskutujeme, jak se události budou vyvíjet dál.
Nabízíme následující pořadí prezentace materiálu.
- Podíváme se na schéma sítě a podrobně probereme, jak funguje;
- Popíšeme, jak přenášíme nastavení z jednoho routeru na druhý pomocí Ansible;
- Povíme si o automatizaci IT infrastruktury obecně.
Schéma sítě a jeho popis.
Schéma
Podíváme se na logické schéma naší organizace. Nebudeme názvy konkrétních výrobců vybavení, v rámci článku to nemá význam. (Pozorný čtenář si sám domyslí, jaké zařízení se používá). To je právě jedna z výhod práce s Ansible, při nastavování nám vlastně nezáleží na tom, jaké to je vybavení. Jen abychom si ujasnili, toto vybavení pochází od známých dodavatelů, jako jsou Cisco, Juniper, Check Point, Fortinet, Palo Alto … můžete použít svou verzi.
Máme dvě hlavní úkoly ohledně přesunu provozu:
- Zajistit publikaci našich služeb, které představují podnikání společnosti;
- Zajistit spojení s pobočkami, vzdáleným datovým centrem a externími organizacemi (partnery a klienty), a také přístup poboček na internet prostřednictvím centrály.
Začneme základními prvky:
- Dva hraniční směrovače (BRD-01, BRD-02);
- Cluster firewallů (FW-CLUSTER);
- Jádrový přepínač (L3-CORE);
- Router, který se stane záchranným kruhem (během řešení problému přeneseme síťová nastavení z FW-CLUSTER na EMERGENCY) (EMERGENCY);
- Přepínače pro správu síťové infrastruktury (L2-MGMT);
- Virtuální stroj s Gitem a Ansible (VM-AUTOMATION);
- Notebook, na kterém se testují a vyvíjejí playbooky pro Ansible (Laptop-Automation).
V síti je nastaven dynamický směrovací protokol OSPF s následujícími oblastmi:
- Oblast 0 – oblast, do které patří směrovače odpovědné za přenos provozu v oblasti EXCHANGE;
- Oblast 1 – oblast, do které patří směrovače odpovědné za fungování služeb společnosti;
- Oblast 2 – oblast, do které patří směrovače odpovědné za směrování management-provozu;
- Oblast N – oblasti pobočkových sítí.
Na hraničních směrovačích bylo vytvořeno po jednom virtuálním směrovači (VRF-INTERNET), na kterém je spuštěn eBGP full view se přiřazeným AS. Mezi VRF bylo nastaveno iBGP. Společnost má fond veřejných adres, které jsou publikovány na těchto VRF-INTERNET. Část veřejných adres je směrována přímo na FW-CLUSTER (adresy, na kterých běží služby společnosti), část je směrována přes oblast EXCHANGE (interní služby společnosti vyžadující externí IP adresy a externí adresy NAT pro kanceláře). Následně provoz míří na virtuální směrovače vytvořené na L3-CORE s veřejnými a šedými adresami (bezpečnostní zóny).
V Management-síti jsou používány vyhrazené switche a představují fyzicky oddělenou síť. Management síť je také rozdělena na bezpečnostní zóny.
Směrovač EMERGENCY fyzicky a logicky duplikuje FW-CLUSTER. Na něm jsou vypnuty všechny rozhraní kromě těch, které směřují do management-sítě.
Automatizace a její popis
Pochopili jsme, jak funguje síť. Nyní si podrobně projdeme, co budeme dělat, abychom přesměrovali provoz z FW-CLUSTER na EMERGENCY:
- Odpojujeme rozhraní na jádrovém switche (L3-CORE), která ho spojují s FW-CLUSTER;
- Odpojujeme rozhraní na jádrovém switche L2-MGMT, která ho spojují s FW-CLUSTER;
- Konfigurujeme směrovač EMERGENCY (ve výchozím nastavení jsou na něm vypnuta všechna rozhraní kromě těch, která jsou spojena s L2-MGMT):
- Zapínáme rozhraní na EMERGENCY;
- Nastavujeme externí IP adresu (pro NAT), která byla na FW-Cluster;
- Generujeme gARP dotazy, aby se v ARP tabulkách L3-CORE změnily MAC adresy z FW-Cluster na EMERGENCY;
- Zapisujeme výchozí trasu staticky do BRD-01, BRD-02;
- Vytváříme pravidla NAT;
- Aktivujeme na EMERGENCY OSPF Oblast 1;
- Aktivujeme na EMERGENCY OSPF Oblast 2;
- Změňujeme cenu tras v Oblasti 1 na 10;
- Změňujeme cenu výchozí trasy v Oblasti 1 na 10;
- Změňte IP adresy, spojené s L2-MGMT (na ty, které byly na FW-CLUSTER);
- Generujeme gARP dotazy, aby se v arp tabulkách L2-MGMT změnily MAC adresy z FW-CLUSTER na EMERGENCY.
Opět se vracíme k původnímu zadání. Tři hodiny ráno, obrovský stres, chyba na jakémkoli kroku může vést k novým problémům. Jste připraveni spouštět příkazy přes CLI? Ano? Dobře, jděte si aspoň opláchnout obličej, vypijte kávu a vzbuďte v sobě vůli.
Bruce, pomoz prosím klukům.
A my pokračujeme v rozvoji naší automatizace.
Níže je uveden diagram práce playbooku v terminologii Ansible. Tento diagram odráží to, co jsme popsali výše, ale už s konkrétní implementací v Ansible.
V této fázi jsme si uvědomili, co je potřeba udělat, vypracovali jsme playbook, provedli jsme testování, nyní jsme připraveni ho spustit.
Ještě jedno malé literární odbočení. Lehkost vyprávění by vás neměla zaslepit. Proces psaní playbooků nebyl tak jednoduchý a rychlý, jak by se mohlo zdát. Testování zabralo poměrně hodně času, byl vytvořen virtuální stand, řešení bylo několikrát testováno, provedli jsme asi 100 testů.
Spouštíme… Mám pocit, že všechno se děje velmi pomalu, někde je chyba, něco nakonec nebude fungovat. Je to jako skok s padákem, ale padák se okamžitě nechce otevřít… to je normální.
Dále čteme výsledek provedených operací playbooku Ansible (IP adresy byly z důvodů ochrany identity změněny):
[xxx@emergency ansible]$ ansible-playbook -i /etc/ansible/inventories/prod_inventory.ini /etc/ansible/playbooks/emergency_on.yml
PLAY [------->Nouzový stav na VCF] ********************************************************
TASK [vcf_junos_emergency_on : Deaktivovat PROD rozhraní na FW-CLUSTER] *********************
změněno: [vcf]
PLAY [------->Nouzový stav na MGMT-CORE] ************************************************
TASK [mgmt_junos_emergency_on : Deaktivovat MGMT rozhraní na FW-CLUSTER] ******************
změněno: [m9-03-sw-03-mgmt-core]
PLAY [------->Nouzový stav na] ****************************************************
TASK [mk_routeros_emergency_on : Aktivovat EXT-INTERNET rozhraní] **************************
změněno: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Generovat gARP pro EXT-INTERNET rozhraní] ****************
změněno: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Aktivovat statickou výchozí trasu na EXT-INTERNET] ****************
změněno: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Změnit NAT pravidlo na EXT-INTERNET rozhraní] ****************
změněno: [m9-04-r-04] => (item=12)
změněno: [m9-04-r-04] => (item=14)
změněno: [m9-04-r-04] => (item=15)
změněno: [m9-04-r-04] => (item=16)
změněno: [m9-04-r-04] => (item=17)
TASK [mk_routeros_emergency_on : Aktivovat OSPF Oblast 1 PROD] ******************************
změněno: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Aktivovat OSPF Oblast 2 MGMT] *****************************
změněno: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Změnit náklady OSPF Oblast 1 rozhraní na 10] *****************
změněno: [m9-04-r-04] => (item=VLAN-1001)
změněno: [m9-04-r-04] => (item=VLAN-1002)
změněno: [m9-04-r-04] => (item=VLAN-1003)
změněno: [m9-04-r-04] => (item=VLAN-1004)
změněno: [m9-04-r-04] => (item=VLAN-1005)
změněno: [m9-04-r-04] => (item=VLAN-1006)
změněno: [m9-04-r-04] => (item=VLAN-1007)
změněno: [m9-04-r-04] => (item=VLAN-1008)
změněno: [m9-04-r-04] => (item=VLAN-1009)
změněno: [m9-04-r-04] => (item=VLAN-1010)
změněno: [m9-04-r-04] => (item=VLAN-1011)
změněno: [m9-04-r-04] => (item=VLAN-1012)
změněno: [m9-04-r-04] => (item=VLAN-1013)
změněno: [m9-04-r-04] => (item=VLAN-1100)
TASK [mk_routeros_emergency_on : Změnit výchozí náklady OSPF Oblast 1 na 10] ******************
změněno: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Změnit IP adresy rozhraní MGMT] ********************
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})
TASK [mk_routeros_emergency_on : Generovat gARPy pro MGMT rozhraní] *********************
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
změněno: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})
PLAY REKAP ************************************************************************Hotovo!
Ve skutečnosti to není úplně hotové, nezapomínejme na konvergenci dynamických směrovacích protokolů a na zatížení velkého množství tras v FIB. Na to nemáme žádný vliv. Čekáme. Sešlo se to. Teď je to hotové.
A ve vesnici Vilabaggio (která nechce automatizovat nastavení sítě) stále myjí nádobí. Bruce (sice už jiný, ale ne méně skvělý) se snaží pochopit, kolik zařízení ještě bude muset ručně přenastavit.
Chtěl bych se ještě zastavit u jednoho důležitého bodu. Jak všechno vrátíme zpět? Po nějaké době vrátíme náš FW-CLUSTER zpět do života. Je to hlavní zařízení, nikoli záložní, na kterém by měla fungovat síť.
Cítíte, jak se síťovým specialistům začíná pálit? Technický ředitel uslyší tisíc argumentů, proč to dělat nemáme, proč to můžeme udělat později. Bohužel se práce sítě skládá z mnoha záplat, kusů, zbytků bývalé slávy. Vzniká z toho patchworková deka. Naším úkolem, ne jen v této konkrétní situaci, ale obecně jako IT specialistů - je uvést práci sítě do krásného anglického slova „consistency“, které je velmi mnohoznačné, můžeme ho přeložit jako: konzistence, nekontradikčnost, logičnost, soulad, systematičnost, srovnatelnost, provázanost. To vše o tom je. Pouze v tomto stavu je síť říditelná, jasně chápeme, co a jak funguje, jasně si uvědomujeme, co je třeba změnit, pokud je to nutné, víme přesně, kam se podívat, v případě problémů. A pouze v takové síti lze provádět triky, podobné těm, které jsme právě popsali.
Byl připraven ještě jeden playbook, který vracel nastavení do původního stavu. Logika jeho činnosti je stejná (je důležité pamatovat, že pořadí úkolů je velmi důležité), abychom neprodloužili již tak dost dlouhý článek, neuspořádali jsme výpis provedení playbooku. Po takových cvičeních se budete cítit mnohem klidněji a sebevědoměji do budoucna, navíc jakékoli zbytečnosti, které tam budete mít, se okamžitě projeví.
Všichni zájemci nám mohou napsat a získat zdrojové kódy veškerého napsaného kódu, spolu se všemi playbooky. Kontakty najdete v profilu.
Závěry
Podle našeho názoru procesy, které lze automatizovat, se ještě plně nevykrystalizovaly. Na základě toho, čemu jsme čelili, a toho, co diskutují naši západní kolegové, se zatím objevují následující témata:
- Zavádění zařízení;
- Sběr dat;
- Reportování;
- Odstraňování problémů;
- Soulad.
Pokud máte zájem, můžeme pokračovat v diskusi k jednomu z uvedených témat.
Rádi bychom také trochu rozproudili diskusi o automatizaci. Jaká by měla být podle našeho chápání:
- Systém by měl fungovat bez zásahu člověka a zároveň se zlepšovat pomocí člověka. Systém by neměl být závislý na lidech;
- Provoz by měl být odborný. Chybí kategorie odborníků, kteří vykonávají rutinní úkoly. Existují odborníci, kteří veškerou rutinu automatizovali a řeší pouze složité úkoly;
- Rutinní standardizované úkoly se vykonávají automaticky "stiskem tlačítka", takže se neztrácejí zdroje. Výsledek těchto úkolů je vždy předvídatelný a jasný.
A k čemu by tyto body měly vést:
- Průhlednost IT infrastruktury (menší rizika provozu, modernizace, zavádění. Menší výpadky ročně);
- Možnost plánovat IT zdroje (systém plánování kapacity - je vidět, kolik se spotřebovává, vidí se, kolik zdrojů je potřeba v jednom systému, a ne podle e-mailů a obíhání šéfů oddělení);
- Možnost snížit počet IT personálu na údržbu.
Autoři článku: Alexander Čeljakov (CCIE RS, CCIE SP) a Pavel Kirillov. Rádi diskusi a nabízíme řešení na téma automatizace IT infrastruktury.
Zdroj: habr.com
