Helló, Habr!
Ebben a cikkben szeretnénk beszélni a hálózati infrastruktúra automatizálásáról. Bemutatunk egy működő hálózati sémát, amely egy kis, de nagyon büszke cégben működik. Minden egybeesés a valós hálózati berendezésekkel véletlenszerű. Megvizsgáljuk azt az esetet, amely a hálózatban történt, ami hosszú távú üzletszünethez és súlyos anyagi veszteségekhez vezetett. A megoldás nagyon jól illeszkedik az „Hálózati infrastruktúra automatizálás” koncepciójába. Az automatizálási eszközök segítségével megmutatjuk, hogyan lehet hatékonyan megoldani a bonyolult feladatokat rövid időn belül, és elgondolkodunk azon, hogy miért érdemes ezeket a feladatokat így, és nem másként (a konzolon keresztül) megoldani.
Megjegyzés
Az automatizálás fő eszközei számunkra az Ansible (mint automatizálási eszköz) és a Git (mint az Ansible playbookok tárolója). Azonnal szeretném megjegyezni, hogy ez nem egy bevezető cikk, ahol az Ansible vagy a Git működési logikájáról beszélünk, és magyarázzuk az alapvető dolgokat (például mi az a szerepkör, modulok, leltári fájlok, változók az Ansible-ben, vagy mi történik a git push vagy git commit parancsok bevitele során). Ez nem arról szól, hogy hogyan lehet gyakorolni az Ansible-t, vagy beállítani az NTP-t vagy SMTP-t a berendezéseken. Ez a történet arról szól, hogy hogyan lehet gyorsan és lehetőleg hibák nélkül megoldani egy hálózati problémát. Emellett kívánatos egy jó elképzelés a hálózat működéséről, különösen a TCP/IP protokollveremről, OSPF-ről, BGP-ről. Az Ansible és Git kiválasztását is mellőzzük. Ha Ön előtt a konkrét megoldás kiválasztása áll, akkor nagyon ajánljuk elolvasni Jason Edelman, Scott S. Lowe és Matt Oswalt „Network Programmability and Automation. Skills for the Next-Generation Network Engineer” című könyvét.
Most térjünk a lényegre.
Lépjünk át a kitűzött feladatra: írjunk egy XDP mechanizmust SYN cookie-kkal.
Képzeljünk el egy helyzetet: éjfél három óra, Ön mélyen alszik és álmokat lát. Csenget a telefon. A műszaki igazgató hív:
— Igen?
— ###, ####, #####, a tűzfal klaszter leállt és nem áll fel!!!
Ön dörzsöli a szemét, próbálja felfogni, mi történik, és elképzelni, hogyan történhetett ez meg. A telefonban hallható, ahogy a direktor haja tépkedése közben kéri, hogy hívja vissza, mert a másik vonalon a vezérigazgató hívja.
Fél óra elteltével összegyűjtötted az első információkat a váltásról, felébresztetted azokat, akiket lehetett. Ennek eredményeként a műszaki igazgató nem hazudott, valóban így van, a fő tűzfal klaszter leállt, és semmiféle alapvető lépés nem ébreszti fel. A cég által kínált összes szolgáltatás nem működik.
Válaszd ki a problémát, ami tetszik, mindenki emlékezni fog valamire. Például a reggeli frissítés után, amikor nem volt nagy terhelés, minden jól működött, és mindenki elégedetten ment aludni. Növekedett a forgalom, és a hálózati kártya meghajtójában lévő hiba miatt a felületek pufferei túlcsordultak.
A helyzetet jól le tudja írni Jackie Chan.
Köszönöm, Jackie.
Nem igazán kellemes helyzet, nem igaz?
Hagyjuk egy pillanatra a hálózati barátunkat a szomorú gondolataival.
Beszéljük meg, hogyan fognak alakulni az események a jövőben.
A következő anyagkibővítési sorrendet ajánljuk.
- Nézzük meg a hálózati ábrát és elemezzük, hogyan működik;
- Leírjuk, hogyan másoljuk át a beállításokat egyik routerről a másikra az Ansible segítségével;
- Beszéljünk az IT-infrastruktúra automatizálásáról általánosságban.
A hálózat ábrája és annak leírása
Séma
Nézzük meg a szervezetünk logikai sémaét. Nem fogunk megnevezni konkrét gyártókat, a cikk keretein belül ez nem lényeges. (A figyelmes olvasó rájön, milyen berendezéseket használnak.). Ez az Ansible használatának egyik előnye, hogy a beállításaink során lényegében mindegy, milyen berendezésről van szó. Csak a megértés érdekében, ezek ismert gyártók berendezései, mint például a Cisco, Juniper, Check Point, Fortinet, Palo Alto … bárki behelyettesítheti a saját változatát.
Két alapvető feladatunk van a forgalom áthelyezésére:
- Gondoskodnunk kell a szolgáltatásaink közzétételéről, amelyek a cég üzletét jelentik;
- Biztosítani kell a kapcsolatot a fiókokkal, a távoli adatközponttal és harmadik fél szervezetekkel (partnerekkel és ügyfelekkel), valamint a fiókok internet-hozzáférését a központi irodán keresztül.
Kezdjük az alapvető elemekkel:
- Két határrouter (BRD-01, BRD-02);
- Tűzfal klaszter (FW-CLUSTER);
- Maghálózati switch (L3-CORE);
- A router, ami megmentő kör lesz (a probléma megoldása során a hálózati beállításokat áthelyezzük az FW-CLUSTER-ből az EMERGENCY-be) (EMERGENCY);
- Switch-ek a hálózati infrastruktúra kezelésére (L2-MGMT);
- Virtuális gép Git-tel és Ansible-lal (VM-AUTOMATION);
- A laptop on which playbook testing and development for Ansible (Laptop-Automation) is performed.
The network is configured with the dynamic routing protocol OSPF with the following areas:
- Area 0 – the area that includes routers responsible for traffic movement in the EXCHANGE zone;
- Area 1 – the area that includes routers responsible for the company's service operations;
- Area 2 – the area that includes routers responsible for management traffic routing;
- Area N – branch network areas.
Virtual routers (VRF-INTERNET) have been created on the border routers, where an eBGP full view with the corresponding assigned AS is established. iBGP is configured between the VRFs. The company has a pool of public addresses that are published on these VRF-INTERNETs. Some public addresses are routed directly to the FW-CLUSTER (addresses where the company services operate), and some are routed through the EXCHANGE zone (internal company services requiring external IP addresses, and external NAT addresses for offices). The traffic is then directed to the virtual routers created on the L3-CORE with public and private addresses (security zones).
Dedicated switches are used in the Management network, representing a physically isolated network. The Management network is also divided into security zones.
The EMERGENCY router physically and logically duplicates the FW-CLUSTER. All interfaces are disabled except those that connect to the management network.
Automation and its description
We have understood how the network works. Now let's go step by step through what we will do to redirect traffic from the FW-CLUSTER to the EMERGENCY:
- Disconnect the interfaces on the core switch (L3-CORE) that connect it to the FW-CLUSTER;
- Disconnect the interfaces on the L2-MGMT core switch that connect it to the FW-CLUSTER;
- Configure the EMERGENCY router (by default, all interfaces are disabled except those connected to L2-MGMT):
- Enable the interfaces on EMERGENCY;
- Configure the external IP address (for NAT) that was on the FW-Cluster;
- Generate gARP requests to change the MAC addresses in the ARP tables from FW-Cluster to EMERGENCY on L3-CORE;
- Write a default static route to BRD-01, BRD-02;
- Create NAT rules;
- Activate OSPF Area 1 on EMERGENCY;
- Activate OSPF Area 2 on EMERGENCY;
- Change the route costs in Area 1 to 10;
- Change the default route cost in Area 1 to 10;
- Change IP-címnek, related to L2-MGMT (to those that were on FW-CLUSTER);
- GARP kéréseket generálunk, hogy az arp-táblákban az L2-MGMT MAC-címek FW-CLUSTER-ről EMERGENCY-re változzanak.
Ismét visszatérünk az eredeti problémakörhöz. Három óra van, óriási stressz, a hibák bármelyik szakaszban új problémákhoz vezethetnek. Készen állsz parancsokat beírni CLI-n? Igen? Rendben, legalább öblítsd le az arcod, igyál egy kávét és gyűjtsd össze az akaraterőd.
Bruce, kérlek, segíts a srácoknak.
De folytatjuk az automatizációnk fejlesztését.
Az alábbiakban látható a playbook működésének sémája Ansible terén. Ez a séma azt tükrözi, amit fentebb leírtunk, csak már konkrét megvalósítás Ansible-ben.
Ezen a ponton rájöttünk, mit kell tennünk, kidolgoztuk a playbook-ot, teszteltük, most már készen állunk az indítására.
Még egy kis lírai kitérő. A narráció könnyedsége ne vezessen meg. A playbook írásának folyamata nem volt egyszerű és gyors, mint ahogy talán tűnik. A tesztelés elég sok időt vett igénybe, létrehoztunk egy virtuális tesztkörnyezetet, a megoldást többször is leteszteltük, körülbelül 100 tesztet végeztünk el.
Indítunk… Az a benyomásom, hogy minden nagyon lassan történik, valahol hiba van, és valami végül nem fog működni. Olyan érzés, mint amikor ejtőernyővel ugrik az ember, de az ernyő valahogy nem akar kinyílni… ez normális.
Ezután olvassuk el az Ansible playbook végrehajtott műveleteinek eredményét (az IP-címeket a titoktartás érdekében cseréltük):
[xxx@emergency ansible]$ ansible-playbook -i /etc/ansible/inventories/prod_inventory.ini /etc/ansible/playbooks/emergency_on.yml
JÁTÉK [------->Vészhelyzet a VCF-en] ********************************************************
FELADAT [vcf_junos_emergency_on : A PROD interfészek letiltása a FW-CLUSTER-hez] *********************
változott: [vcf]
JÁTÉK [------->Vészhelyzet a MGMT-CORE-on] ************************************************
FELADAT [mgmt_junos_emergency_on : A MGMT interfészek letiltása a FW-CLUSTER-hez] ******************
változott: [m9-03-sw-03-mgmt-core]
JÁTÉK [------->Vészhelyzet] ****************************************************
FELADAT [mk_routeros_emergency_on : EXT-INTERNET interfész engedélyezése] **************************
változott: [m9-04-r-04]
FELADAT [mk_routeros_emergency_on : gARP generálása az EXT-INTERNET interfészhez] ****************
változott: [m9-04-r-04]
FELADAT [mk_routeros_emergency_on : Statikus alapértelmezett útvonal engedélyezése az EXT-INTERNET-hez] ****************
változott: [m9-04-r-04]
FELADAT [mk_routeros_emergency_on : NAT szabály módosítása az EXT-INTERNET interfészhez] ****************
változott: [m9-04-r-04] => (item=12)
változott: [m9-04-r-04] => (item=14)
változott: [m9-04-r-04] => (item=15)
változott: [m9-04-r-04] => (item=16)
változott: [m9-04-r-04] => (item=17)
FELADAT [mk_routeros_emergency_on : OSPF 1-es terület engedélyezése a PROD-hoz] ******************************
változott: [m9-04-r-04]
FELADAT [mk_routeros_emergency_on : OSPF 2-es terület engedélyezése a MGMT-hez] *****************************
változott: [m9-04-r-04]
FELADAT [mk_routeros_emergency_on : OSPF 1-es terület interfészek díjainak módosítása 10-re] *****************
változott: [m9-04-r-04] => (item=VLAN-1001)
változott: [m9-04-r-04] => (item=VLAN-1002)
változott: [m9-04-r-04] => (item=VLAN-1003)
változott: [m9-04-r-04] => (item=VLAN-1004)
változott: [m9-04-r-04] => (item=VLAN-1005)
változott: [m9-04-r-04] => (item=VLAN-1006)
változott: [m9-04-r-04] => (item=VLAN-1007)
változott: [m9-04-r-04] => (item=VLAN-1008)
változott: [m9-04-r-04] => (item=VLAN-1009)
változott: [m9-04-r-04] => (item=VLAN-1010)
változott: [m9-04-r-04] => (item=VLAN-1011)
változott: [m9-04-r-04] => (item=VLAN-1012)
változott: [m9-04-r-04] => (item=VLAN-1013)
változott: [m9-04-r-04] => (item=VLAN-1100)
FELADAT [mk_routeros_emergency_on : OSPF terület 1 alapértelmezett költség módosítása 10-re] ******************
változott: [m9-04-r-04]
FELADAT [mk_routeros_emergency_on : MGMT interfészek IP címek módosítása] ********************
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})
FELADAT [mk_routeros_emergency_on : gARP generálása a MGMT interfészekhez] *********************
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
változott: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})
JÁTÉK REKAP ************************************************************************Kész!
Tulajdonképpen még nem teljesen kész, ne felejtsük el a dinamikus útválasztó protokollok konvergenciáját és a FIB-be történő nagy számú útvonal betöltését. Erre nem tudunk hatással lenni. Várunk. Összeállt. Most már kész.
A VIlabadzso faluban (ahol nem akarják automatizálni a hálózati beállításokat) továbbra is mosogatnak. Bruce (bár már egy másik, de nem kevésbé menő) próbálja megérteni, hogy még mennyit kell manuálisan újrakonfigurálni a berendezést.
Szeretnék még egy fontos pontra kitérni. Hogyan tudjuk visszavinni mindent az eredeti állapotába? Egy idő múlva életre fogjuk kelteni a FW-CLUSTER-t. Ez a fő berendezés, nem tartalék, ezen kell működnie a hálózatnak.
Érzitek, hogy kezdik feszíteni a hálózat szakembereit? A műszaki igazgató ezer érvet fog hallani arról, hogy miért nem kell ezt megtenni, miért lehet ezt később végezni. Sajnos így alakul a hálózat működése, tele foltozással, darabokkal, a régi fényűzés maradványaival. Takaros álomképet alkot. A feladatunk, nem csak ebben a konkrét helyzetben, hanem általában IT szakemberekként — a hálózat működését a szépen angolul „consistency”-nek nevezett szóhoz kellett hoznunk; ez nagyon sokrétű, jelentheti: összhang, koherencia, logikusság, összehangoltság, rendszeresség, összehasonlíthatóság, kapcsolódás. Minden erről szól. Csak ilyen állapotban a hálózat irányítható, pontosan tudjuk, hogy mi és hogyan működik, egyértelműen érezzük, mit kell változtatni, ha szükséges, és tudjuk, hová kell nézni, ha problémák merülnek fel. Csak ilyen hálózaton lehet végrehajtani olyan trükköket, mint amiket most leírtunk.
Így is készült egy másik playbook, amely visszavitte a beállításokat az eredeti állapotába. A működési logikája ugyanaz (fontos észben tartani, hogy a feladatok sorrendje nagyon fontos); hogy ne hosszabbítsuk meg így is eléggé hosszú cikket, úgy döntöttünk, hogy nem tesszük közzé a playbook végrehajtásának listingjét. Ezeknek a gyakorlatoknak a lebonyolításával sokkal nyugodtabbnak és magabiztosabbnak érezheted magad a jövőre nézve, ráadásul bármelyik „ötlet”, amit ott létrehoztál, azonnal meg fog mutatkozni.
Mindenki, aki szeretne, írhat nekünk és megkaphatja a teljesen megírt kód forrásait, az összes playbook-al együtt. Kapcsolatok a profilban.
Következtetések
Véleményünk szerint még nem kristályosodtak ki azok a folyamatok, amelyeket automatizálni lehet. Az eddig tapasztaltak és a nyugati kollégáink által tárgyalt témák alapján a következő területek láthatók:
- Eszköz ellátás;
- Adatgyűjtés;
- Jelentés készítés;
- Hibaelhárítás;
- Megfelelőség.
Ha van érdeklődés, folytathatjuk a beszélgetést az egyik megadott témáról.
Szeretnénk még egy kicsit elmélkedni az automatizálásról. Milyennek kellene lennie a mi felfogásunk szerint:
- A rendszernek ember nélkül kell működnie, ugyanakkor az ember által kellene fejlődnie. A rendszernek nem szabad az embertől függenie;
- A működésnek szakmai szintűnek kell lennie. Hiányzik egy olyan szakemberi réteg, amely a rutinfeladatokat ellátja. Vannak szakértők, akik az összes rutinfeladatot automatizálták, és csak a komplex feladatokat oldják meg;
- A rutinszerű, standard feladatok automatikusan, "gombnyomásra" elvégzendők, nem pazarolják az erőforrásokat. Az ilyen feladatok eredménye mindig előre látható és egyértelmű.
És ezek a pontok hová vezetnek:
- Az IT-infrastruktúra átláthatósága (Kevesebb üzemeltetési, modernizálási, bevezetési kockázat. Kevesebb leállás évente);
- Lehetőség az IT-erőforrások tervezésére (Kapacitás-tervezési rendszer — látható, mennyit fogyasztunk, látható, mennyi erőforrásra van szükség egy egységes rendszerben, nem pedig levelek és osztályvezetőkhöz való látogatások alapján);
- Lehetőség a fenntartó IT-személyzet számának csökkentésére.
A cikk szerzői: Alexander Cselovekov (CCIE RS, CCIE SP) és Pavel Kirillov. Érdekel minket az IT-infrastruktúra automatizálásával kapcsolatos megoldások megvitatása és ajánlása.
Forrás: habr.com
