Čau Habr!
V tomto článku bychom chtěli hovořit o automatizaci síťové infrastruktury. Bude představeno pracovní schéma sítě, která funguje v jedné malé, ale velmi hrdé společnosti. Všechny zápasy se skutečným síťovým vybavením jsou náhodné. Podíváme se na případ, který se v této síti stal a který mohl vést k dlouhodobému odstavení podniku a vážným finančním ztrátám. Řešení tohoto případu velmi dobře zapadá do konceptu „Automatizace síťové infrastruktury“. Pomocí automatizačních nástrojů si ukážeme, jak lze efektivně vyřešit složité problémy v krátkém čase a zamyslíme se nad tím, proč by se tyto problémy měly řešit právě takto a ne jinak (přes konzoli).
Odmítnutí odpovědnosti
Naše hlavní nástroje pro automatizaci jsou Ansible (jako automatizační nástroj) a Git (jako úložiště pro Ansible playbooky). Dovoluji si rovnou učinit výhradu, že se nejedná o úvodní článek, kde se bavíme o logice Ansible nebo Gitu, a vysvětlíme si základní věci (např. co jsou roletaskimoduly, inventární soubory, proměnné v Ansible nebo co se stane, když zadáte příkazy git push nebo git commit). Tento příběh není o tom, jak můžete cvičit Ansible a konfigurovat NTP nebo SMTP na vašem zařízení. Toto je příběh o tom, jak můžete rychle a nejlépe vyřešit problém se sítí bez chyb. Je také vhodné dobře rozumět tomu, jak síť funguje, zejména co je zásobník protokolů TCP/IP, OSPF, BGP. Ze závorek také vyjmeme volbu Ansible a Git. Pokud si přesto potřebujete vybrat konkrétní řešení, vřele doporučujeme přečíst si 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 problému
Představme si situaci: 3 hodiny ráno tvrdě spíte a sníte. Telefonát. Technický ředitel volá:
- Ano?
— ###, ####, #####, cluster firewallu spadl a nestoupá!!!
Protíráte si oči, snažíte se pochopit, co se děje, a představujete si, jak by se to vůbec mohlo stát. V telefonu slyšíte, jak se řediteli trhají vlasy na hlavě, a žádá, aby zavolal zpět, protože mu volá generál na druhé lince.
O půl hodiny později jste posbírali první úvodní poznámky ze služební směny, vzbudili jste všechny, kteří se probudit mohli. Ve výsledku technický ředitel nelhal, vše je tak, jak je, hlavní shluk firewallů padl a žádné základní pohyby těla ho nepřivádějí k rozumu. Všechny služby, které společnost nabízí, nefungují.
Vyberte si problém podle svého gusta, každý si bude pamatovat něco jiného. Například po noční aktualizaci bez velkého zatížení vše fungovalo dobře a všichni šli spát šťastní. Provoz začal proudit a vyrovnávací paměti rozhraní začaly přetékat kvůli chybě v ovladači síťové karty.
Jackie Chan umí dobře popsat situaci.
Děkuji, Jackie.
Není to moc příjemná situace, že?
Nechme na chvíli náš síťový brácho s jeho smutnými myšlenkami.
Pojďme diskutovat o tom, jak se budou události vyvíjet dál.
Doporučujeme následující pořadí prezentace materiálu
- Podívejme se na schéma sítě a uvidíme, jak to funguje;
- Popíšeme si, jak přenášíme nastavení z jednoho routeru do druhého pomocí Ansible;
- Pojďme se bavit o automatizaci IT infrastruktury jako celku.
Schéma a popis sítě
systém
Podívejme se na logické schéma naší organizace. Konkrétní výrobce zařízení nebudeme jmenovat, pro účely tohoto článku je to jedno (Pozorný čtenář uhodne, jaké zařízení se používá). To je jen jedna z dobrých výhod práce s Ansible; při nastavování nás obecně nezajímá, o jaký druh zařízení se jedná. Jen pro pochopení, jedná se o vybavení od známých výrobců, jako jsou Cisco, Juniper, Check Point, Fortinet, Palo Alto...můžete nahradit vlastní variantou.
Máme dva hlavní úkoly pro přesun dopravy:
- Zajistit zveřejňování našich služeb, které jsou předmětem podnikání společnosti;
- Zajišťujeme komunikaci s pobočkami, vzdáleným datovým centrem a organizacemi třetích stran (partnery a klienty) a také přístup poboček k internetu prostřednictvím centrály.
Začněme základními prvky:
- Dva hraniční routery (BRD-01, BRD-02);
- Firewall CLUSTER (FW-CLUSTER);
- Core switch (L3-CORE);
- Router, který se stane záchranou (jak problém vyřešíme, přeneseme nastavení sítě z FW-CLUSTER do NOUZOVÉHO) (EMERGENCY);
- Switche pro správu síťové infrastruktury (L2-MGMT);
- Virtuální stroj s Git a Ansible (VM-AUTOMATION);
- Notebook, na kterém se provádí testování a vývoj playbooků pro Ansible (Laptop-Automation).
Síť je nakonfigurována pomocí dynamického směrovacího protokolu OSPF s následujícími oblastmi:
- Oblast 0 – oblast, která zahrnuje směrovače odpovědné za přesun provozu v zóně EXCHANGE;
- Oblast 1 – oblast, která zahrnuje routery odpovědné za provoz služeb společnosti;
- Oblast 2 – oblast, která zahrnuje směrovače odpovědné za směrování provozu správy;
- Oblast N – oblasti pobočkových sítí.
Na hraničních routerech je vytvořen virtuální router (VRF-INTERNET), na kterém je nainstalován eBGP full view s odpovídajícím přiřazeným AS. iBGP se konfiguruje mezi VRF. Společnost má fond bílých adres, které jsou zveřejněny na těchto VRF-INTERNET. Některé bílé adresy jsou směrovány přímo na FW-CLUSTER (adresy, na kterých fungují služby společnosti), některé jsou směrovány přes zónu EXCHANGE (interní firemní služby vyžadující externí IP adresy a externí NAT adresy pro kanceláře). Dále provoz směřuje do virtuálních směrovačů vytvořených na L3-CORE s bílou a šedou adresou (bezpečnostní zóny).
Síť pro správu používá vyhrazené přepínače a představuje fyzicky vyhrazenou síť. Síť správy je také rozdělena na bezpečnostní zóny.
NOUZOVÝ router fyzicky a logicky duplikuje FW-CLUSTER. Všechna rozhraní na něm jsou zakázána kromě těch, která se dívají do sítě pro správu.
Automatizace a její popis
Zjistili jsme, jak síť funguje. Nyní se podíváme krok za krokem na to, co uděláme pro přesun provozu z FW-CLUSTER do EMERGENCY:
- Deaktivujeme rozhraní na základním přepínači (L3-CORE), která jej připojují k FW-CLUSTER;
- Deaktivujeme rozhraní na přepínači jádra L2-MGMT, která jej připojují k FW-CLUSTER;
- Nakonfigurujeme NOUZOVÝ router (ve výchozím nastavení jsou na něm všechna rozhraní deaktivována, kromě těch, která jsou spojena s L2-MGMT):
- Povolujeme rozhraní v NOUZI;
- Nakonfigurujeme externí IP adresu (pro NAT), která byla na FW-Clusteru;
- Vygenerujeme požadavky gARP tak, že adresy poppy v tabulkách L3-CORE arp se změní z FW-Cluster na EMERGENCY;
- Výchozí trasu registrujeme jako statickou do BRD-01, BRD-02;
- Vytvořte pravidla NAT;
- Zvyšte na NOUZOVOU OSPF oblast 1;
- Zvyšte na NOUZOVOU OSPF oblast 2;
- Změníme cenu tras v Oblasti 1 na 10;
- Změníme cenu výchozí trasy v Oblasti 1 na 10;
- Změníme IP adresy spojené s L2-MGMT (na ty, které byly na FW-CLUSTER);
- Generujeme požadavky gARP tak, že adresy maku v tabulkách arp L2-MGMT se změní z FW-CLUSTER na EMERGENCY.
Opět se vracíme k původní formulaci problému. Tři hodiny ráno, obrovský stres, chyba v jakékoli fázi může vést k novým problémům. Jste připraveni zadávat příkazy přes CLI? Ano? Dobře, běž si alespoň opláchnout obličej, vypít kávu a sebrat sílu vůle.
Bruci, prosím pomozte chlapům.
Pokračujeme ve zdokonalování naší automatizace.
Níže je schéma toho, jak tato příručka funguje v podmínkách Ansible. Toto schéma odráží to, co jsme popsali výše, je to jen konkrétní implementace v Ansible.
V této fázi jsme si uvědomili, co je třeba udělat, vyvinuli jsme příručku, provedli testování a nyní jsme připraveni ji spustit.
Další malá lyrická odbočka. Lehkost příběhu by vás neměla zmást. Proces psaní playbooků nebyl tak jednoduchý a rychlý, jak by se mohlo zdát. Testování zabralo poměrně hodně času, vznikl virtuální stánek, řešení bylo mnohokrát testováno, bylo provedeno cca 100 testů.
Spustíme... Je tu pocit, že se vše děje velmi pomalu, někde je chyba, něco nakonec nebude fungovat. Pocit, že skáčete s padákem, ale padák se nechce hned otevřít...to je normální.
Dále si přečteme výsledek provedených operací Ansible playbooku (IP adresy byly nahrazeny pro účely utajení):
[xxx@emergency ansible]$ ansible-playbook -i /etc/ansible/inventories/prod_inventory.ini /etc/ansible/playbooks/emergency_on.yml
PLAY [------->Emergency on VCF] ********************************************************
TASK [vcf_junos_emergency_on : Disable PROD interfaces to FW-CLUSTER] *********************
changed: [vcf]
PLAY [------->Emergency on MGMT-CORE] ************************************************
TASK [mgmt_junos_emergency_on : Disable MGMT interfaces to FW-CLUSTER] ******************
changed: [m9-03-sw-03-mgmt-core]
PLAY [------->Emergency on] ****************************************************
TASK [mk_routeros_emergency_on : Enable EXT-INTERNET interface] **************************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Generate gARP for EXT-INTERNET interface] ****************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Enable static default route to EXT-INTERNET] ****************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Change NAT rule to EXT-INTERNET interface] ****************
changed: [m9-04-r-04] => (item=12)
changed: [m9-04-r-04] => (item=14)
changed: [m9-04-r-04] => (item=15)
changed: [m9-04-r-04] => (item=16)
changed: [m9-04-r-04] => (item=17)
TASK [mk_routeros_emergency_on : Enable OSPF Area 1 PROD] ******************************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Enable OSPF Area 2 MGMT] *****************************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Change OSPF Area 1 interfaces costs to 10] *****************
changed: [m9-04-r-04] => (item=VLAN-1001)
changed: [m9-04-r-04] => (item=VLAN-1002)
changed: [m9-04-r-04] => (item=VLAN-1003)
changed: [m9-04-r-04] => (item=VLAN-1004)
changed: [m9-04-r-04] => (item=VLAN-1005)
changed: [m9-04-r-04] => (item=VLAN-1006)
changed: [m9-04-r-04] => (item=VLAN-1007)
changed: [m9-04-r-04] => (item=VLAN-1008)
changed: [m9-04-r-04] => (item=VLAN-1009)
changed: [m9-04-r-04] => (item=VLAN-1010)
changed: [m9-04-r-04] => (item=VLAN-1011)
changed: [m9-04-r-04] => (item=VLAN-1012)
changed: [m9-04-r-04] => (item=VLAN-1013)
changed: [m9-04-r-04] => (item=VLAN-1100)
TASK [mk_routeros_emergency_on : Change OSPF area1 default cost for to 10] ******************
changed: [m9-04-r-04]
TASK [mk_routeros_emergency_on : Change MGMT interfaces ip addresses] ********************
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})
TASK [mk_routeros_emergency_on : Generate gARPs for MGMT interfaces] *********************
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})
PLAY RECAP ************************************************************************Hotovo!
Ve skutečnosti to není úplně připravené, nezapomeňte na konvergenci dynamických směrovacích protokolů a načítání velkého množství cest do FIB. To nemůžeme nijak ovlivnit. Počkáme. Vyšlo to. Nyní je to připraveno.
A ve vesnici Vilabajo (která nechce automatizovat nastavení sítě) pokračují v mytí nádobí. Bruce (nutno uznat, že už jiný, ale neméně cool) se snaží pochopit, o kolik více manuálních překonfigurování výbavy dojde.
Rád bych se také zastavil u jednoho důležitého bodu. Jak můžeme všechno získat zpět? Po nějaké době přivedeme náš FW-CLUSTER zpět k životu. Toto je hlavní zařízení, nikoli záloha, na něm musí běžet síť.
Cítíte, jak networkeři začínají vyhořet? Technický ředitel si vyslechne tisíc argumentů, proč by se to nemělo dělat, proč to lze udělat později. Bohužel takto funguje síť z hromady záplat, kousků a zbytků svého někdejšího luxusu. Ukázalo se, že je to patchworková deka. Naším úkolem obecně, ne v této konkrétní situaci, ale obecně v zásadě, jako IT specialistů, je přivést práci sítě ke krásnému anglickému slovu „konzistence“, je velmi mnohostranné, lze jej přeložit jako: soudržnost , konzistence, logika, koherence, systematičnost, srovnatelnost, koherence. Je to všechno o něm. Pouze v tomto stavu je síť ovladatelná, jasně rozumíme tomu, co a jak funguje, jasně chápeme, co je potřeba změnit, v případě potřeby jasně víme, kde hledat, pokud nastanou problémy. A pouze v takové síti můžete provádět triky, jako jsou ty, které jsme právě popsali.
Vlastně byl připraven další playbook, který vrátil nastavení do původního stavu. Logika jeho fungování je stejná (je důležité si uvědomit, že pořadí úkolů je velmi důležité), abychom nenatahovali už tak dost dlouhý článek, rozhodli jsme se nezveřejňovat výpis provedení playbooku. Po provedení takových cvičení se budete v budoucnu cítit mnohem klidnější a jistější, navíc se okamžitě odhalí jakékoli berle, které jste tam naskládali.
Kdokoli nám může napsat a obdržet zdroje veškerého napsaného kódu spolu se všemi příručními knihami. Kontakty v profilu.
Závěry
Podle našeho názoru ještě nevykrystalizovaly procesy, které lze automatizovat. Na základě toho, s čím jsme se setkali a o čem diskutují naši západní kolegové, jsou zatím viditelná následující témata:
- Poskytování zařízení;
- Sběr dat;
- Hlášení;
- Odstraňování problémů;
- Soulad.
V případě zájmu můžeme pokračovat v diskusi na jedno z daných témat.
Rád bych také mluvil trochu o automatizaci. Co by to mělo být v našem chápání:
- Systém musí žít bez člověka a přitom být člověkem vylepšován. Systém by neměl záviset na lidech;
- Obsluha musí být odborná. Neexistuje žádná třída specialistů, kteří provádějí rutinní úkoly. Existují odborníci, kteří celou rutinu zautomatizovali a řeší pouze složité problémy;
- Rutinní standardní úkoly se provádějí automaticky „stisknutím tlačítka“, nedochází k plýtvání zdroji. Výsledek takových úkolů je vždy předvídatelný a srozumitelný.
A k čemu by tyto body měly vést:
- Transparentnost IT infrastruktury (méně rizik provozu, modernizace, implementace. Méně prostojů ročně);
- Schopnost plánovat zdroje IT (systém plánování kapacit - můžete vidět, kolik je spotřebováno, můžete vidět, kolik zdrojů je vyžadováno v jednom systému, a ne pomocí dopisů a návštěv na nejvyšších odděleních);
- Možnost snížení počtu IT pracovníků.
Autoři článku: Alexander Chelovekov (CCIE RS, CCIE SP) a Pavel Kirillov. Máme zájem diskutovat a navrhovat řešení na téma automatizace IT infrastruktury.
Zdroj: www.habr.com