🥇Automatyzacja sieci. Przypadek z życia

Cześć, Habr!

W tym artykule chcielibyśmy porozmawiać o automatyzacji infrastruktury sieciowej. Zostanie przedstawiony schemat pracy sieci, która funkcjonuje w małej, ale bardzo dumnej firmie. Wszystkie zbieżności z rzeczywistym sprzętem sieciowym są przypadkowe. Omówimy przypadek, który miał miejsce w tej sieci, który mógł doprowadzić do wstrzymania działalności na dłuższy czas i poważnych strat finansowych. Rozwiązanie tej sprawy doskonale wpisuje się w koncepcję „Automatyzacja infrastruktury sieciowej”. Z pomocą narzędzi automatyzacji pokażemy, jak skutecznie rozwiązywać skomplikowane zadania w krótkim czasie, i zastanowimy się, dlaczego bardziej obiecujące jest ich rozwiązywanie w ten sposób, a nie inaczej (poprzez konsolę).

Zrzeczenie się odpowiedzialności

Podstawowymi narzędziami do automatyzacji są dla nas Ansible (jako narzędzie automatyzacji) i Git (jako repozytorium playbooków Ansible). Od razu należy zaznaczyć, że nie jest to artykuł wprowadzający, w którym mówimy o logice działania Ansible lub Gita i wyjaśniamy podstawowe rzeczy (na przykład, czym są rolki, moduły, pliki inwentaryzacyjne i zmienne w Ansible, lub co się dzieje po wprowadzeniu poleceń git push lub git commit). To historia nie o tym, jak można ćwiczyć w Ansible, konfigurować NTP czy SMTP na sprzęcie. To opowieść o tym, jak można szybko i najlepiej bez błędów rozwiązać problem sieciowy. Również dobrze jest mieć dobre pojęcie o tym, jak działa sieć, w szczególności, czym jest stos protokołów TCP/IP, OSPF, BGP. Wybór Ansible i Gita również pominiemy. Jeśli nadal stoisz przed wyborem konkretnego rozwiązania, zdecydowanie polecamy przeczytać książkę „Network Programmability and Automation. Skills for the Next-Generation Network Engineer” autorstwa Jasona Edelmana, Scotta S. Lowe'a i Matta Oswalta.

Przejdźmy do sedna sprawy.

Sformułowanie zadania

Wyobraź sobie sytuację: 3 w nocy, twardo śpisz i śnisz. Telefon dzwoni. Dzwoni dyrektor techniczny:

— Tak?
— ###, ####, #####, klaster zapór ogniowych upadł i nie wstaje!!!
Przetrzesz oczy, próbujesz zrozumieć, co się dzieje i wyobrazić sobie, jak to mogło się zdarzyć. W słuchawce słychać, jak wypadają mu włosy z głowy, i prosi, aby oddzwonić, ponieważ dzwoni do niego dyrektor generalny na drugim linii.

Po pół godzinie zebraliście pierwsze informacje od zmiany dyżurnej, obudziliście wszystkich, których można było obudzić. W rezultacie dyrektor techniczny nie kłamał, wszystko się zgadza, podstawowy klaster zapór sieciowych upadł i żadne podstawowe działania nie przywracają go do życia. Wszystkie usługi oferowane przez firmę są niedostępne.

Wybierz problem według własnego uznania, każdy przypomni sobie coś swojego. Na przykład, po nocnej aktualizacji, przy braku dużego obciążenia wszystko działało dobrze, a wszyscy zadowoleni poszli spać. Nastąpił ruch, a buforowanie interfejsów zaczęło się przepełniać z powodu błędu w sterowniku karty sieciowej.

Sytuację dobrze opisuje Jackie Chan.

Dziękuję, Jackie.

Sytuacja nie jest przyjemna, prawda?

Na chwilę zostawmy naszego sieciowego kolegę z jego smutnymi myślami.

Omówimy, jak sytuacja będzie się rozwijać dalej.

Proponujemy następujący porządek przedstawienia materiału

Rozważmy schemat sieci i przeanalizujmy, jak działa;
Opiszemy, jak przenosimy ustawienia z jednego routera na drugi za pomocą Ansible;
Porozmawiamy o automatyzacji infrastruktury IT w ogóle.

Schemat sieci i jego opis

Schemat

Rozważmy logiczny schemat naszej organizacji. Nie będziemy nazywać konkretnych producentów sprzętu, w ramach artykułu nie ma to znaczenia. (Uważny czytelnik sam się domyśli, jaki sprzęt jest używany). To jeden z dobrych atutów pracy z Ansible, podczas konfiguracji w zasadzie nie obchodzi nas, jaki to sprzęt. Po prostu dla zrozumienia, to sprzęt znanych dostawców, takich jak Cisco, Juniper, Check Point, Fortinet, Palo Alto… możecie wstawić swój wariant.

Mamy dwa główne zadania związane z przemieszczaniem ruchu:

Zapewnić publikację naszych usług, które są biznesem firmy;
Zapewnić łączność z oddziałami, zdalnym centrum danych oraz zewnętrznymi organizacjami (partnerami i klientami), a także umożliwić oddziałom dostęp do internetu przez centralne biuro.

Zacznijmy od podstawowych elementów:

Dwa brzegowe routery (BRD-01, BRD-02);
Klaster zapór sieciowych (FW-CLUSTER);
Przełącznik rdzenia (L3-CORE);
Router, który stanie się kołem ratunkowym (w trakcie rozwiązywania problemu przeniesiemy ustawienia sieciowe z FW-CLUSTER na EMERGENCY) (EMERGENCY);
Przełączniki do zarządzania infrastrukturą sieciową (L2-MGMT);
Maszyna wirtualna z Gitem i Ansible (VM-AUTOMATION);
Laptop, na którym testuje się i rozwija playbooki dla Ansible (Laptop-Automation).

W sieci skonfigurowano dynamiczny protokół routingu OSPF z następującymi obszarami:

Obszar 0 – obszar, w którym znajdują się routery odpowiedzialne za przesyłanie ruchu w strefie EXCHANGE;
Obszar 1 – obszar, w którym znajdują się routery odpowiedzialne za działanie usług firmy;
Obszar 2 – obszar, w którym znajdują się routery odpowiedzialne za routowanie ruchu zarządzającego;
Obszar N – obszary sieci oddziałowych.

Na brzegowych routerach utworzono po jednym wirtualnym routerze (VRF-INTERNET), na których uruchomiono eBGP full view z odpowiednim przypisanym AS. Między VRF-ami skonfigurowano iBGP. Firma posiada pulę białych adresów, które są opublikowane na tych VRF-INTERNET. Część białych adresów jest routowana bezpośrednio na FW-CLUSTER (adresy, na których działają usługi firmy), część routowana jest przez strefę EXCHANGE (usługi wewnętrzne firmy wymagające zewnętrznych adresów IP oraz zewnętrzne adresy NAT dla biur). Następnie ruch trafia na wirtualne routery utworzone na L3-CORE z białymi i szarymi adresami (strefy bezpieczeństwa).

W sieci zarządzającej używane są dedykowane przełączniki i stanowią one fizycznie wydzieloną sieć. Sieć zarządzająca jest również podzielona na strefy bezpieczeństwa.
Router EMERGENCY fizycznie i logicznie duplikuje FW-CLUSTER. Na nim wyłączono wszystkie interfejsy poza tymi, które są podłączone do sieci zarządzającej.

Automatyzacja i jej opis

Zrozumieliśmy, jak działa sieć. Teraz omówimy krok po kroku, co musimy zrobić, aby przekierować ruch z FW-CLUSTER na EMERGENCY:

Wyłączamy interfejsy na przełączniku rdzenia (L3-CORE), które łączą go z FW-CLUSTER;
Wyłączamy interfejsy na przełączniku rdzenia L2-MGMT, które łączą go z FW-CLUSTER;
Konfigurujemy router EMERGENCY (domyślnie wszystkie interfejsy są wyłączone, z wyjątkiem tych, które są połączone z L2-MGMT):

Włączamy interfejsy na EMERGENCY;
Konfigurujemy zewnętrzny adres IP (dla NAT), który był na FW-Cluster;
Generujemy zapytania gARP, aby w tabelach ARP L3-CORE zmieniły się adresy MAC z FW-Cluster na EMERGENCY;
Wpisujemy domyślną trasę statyczną do BRD-01, BRD-02;
Tworzymy reguły NAT;
Uruchamiamy OSPF Area 1 na EMERGENCY;
Uruchamiamy OSPF Area 2 na EMERGENCY;
Zmniejszamy koszt tras w obszarze 1 do 10;
Zmniejszamy koszt domyślnej trasy w obszarze 1 do 10;
Zmiana adresu IP, związane z L2-MGMT (na te, które były na FW-CLUSTER);
Generujemy zapytania gARP, aby w tabelach arp L2-MGMT zmieniły się adresy MAC z FW-CLUSTER na EMERGENCY.

Wracamy znów do pierwotnego sformułowania zadania. Trzecia w nocy, ogromny stres, błąd na którymkolwiek etapie może prowadzić do nowych problemów. Czy jesteście gotowi do wprowadzania poleceń przez CLI? Tak? Dobrze, idźcie chociaż przepłukać twarz, wypijcie kawę i zbierzcie siły.
Bruce, proszę, pomóż chłopakom.

A my kontynuujemy rozwijanie naszej automatyzacji.
Poniżej przedstawiona jest schemat pracy playbooka w terminach Ansible. To schemat odzwierciedla to, co opisaliśmy trochę wyżej, po prostu już konkretna realizacja w Ansible.

Na tym etapie uświadomiliśmy sobie, co musimy zrobić, opracowaliśmy playbook, przeprowadziliśmy testy, teraz jesteśmy gotowi go uruchomić.

Jeszcze jedno małe dygresja. Łatwość opowiadania nie powinna Was wprowadzać w błąd. Proces pisania playbooków nie był ani prosty, ani szybki, jak może się wydawać. Testowanie zajęło dość dużo czasu, stworzono wirtualną platformę, rozwiązanie było wielokrotnie testowane, przeprowadzono około 100 testów.

Uruchamiamy… Jest poczucie, że wszystko dzieje się bardzo wolno, gdzieś jest błąd, coś w końcu nie zadziała. Czuję się jak podczas skoku ze spadochronem, a spadochron na początku nie chce się otworzyć… to normalne.

Następnie czytamy wyniki wykonanych operacji playbooka Ansible (adresy IP dla zachowania poufności zostały zmienione):

[xxx@emergency ansible]$ ansible-playbook -i /etc/ansible/inventories/prod_inventory.ini /etc/ansible/playbooks/emergency_on.yml 

PLAY [------->Awaria w VCF] ********************************************************

TASK [vcf_junos_emergency_on : Wyłącz interfejsy PROD do FW-CLUSTER] *********************
zmieniono: [vcf]

PLAY [------->Awaria w MGMT-CORE] ************************************************

TASK [mgmt_junos_emergency_on : Wyłącz interfejsy MGMT do FW-CLUSTER] ******************
zmieniono: [m9-03-sw-03-mgmt-core]

PLAY [------->Awaria w] ****************************************************

TASK [mk_routeros_emergency_on : Włącz interfejs EXT-INTERNET] **************************
zmieniono: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Generuj gARP dla interfejsu EXT-INTERNET] ****************
zmieniono: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Włącz statyczną trasę domyślną do EXT-INTERNET] ****************
zmieniono: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Zmień regułę NAT dla interfejsu EXT-INTERNET] ****************
zmieniono: [m9-04-r-04] => (item=12)
zmieniono: [m9-04-r-04] => (item=14)
zmieniono: [m9-04-r-04] => (item=15)
zmieniono: [m9-04-r-04] => (item=16)
zmieniono: [m9-04-r-04] => (item=17)

TASK [mk_routeros_emergency_on : Włącz OSPF Area 1 PROD] ******************************
zmieniono: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Włącz OSPF Area 2 MGMT] *****************************
zmieniono: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Zmień koszty interfejsów OSPF Area 1 na 10] *****************
zmieniono: [m9-04-r-04] => (item=VLAN-1001)
zmieniono: [m9-04-r-04] => (item=VLAN-1002)
zmieniono: [m9-04-r-04] => (item=VLAN-1003)
zmieniono: [m9-04-r-04] => (item=VLAN-1004)
zmieniono: [m9-04-r-04] => (item=VLAN-1005)
zmieniono: [m9-04-r-04] => (item=VLAN-1006)
zmieniono: [m9-04-r-04] => (item=VLAN-1007)
zmieniono: [m9-04-r-04] => (item=VLAN-1008)
zmieniono: [m9-04-r-04] => (item=VLAN-1009)
zmieniono: [m9-04-r-04] => (item=VLAN-1010)
zmieniono: [m9-04-r-04] => (item=VLAN-1011)
zmieniono: [m9-04-r-04] => (item=VLAN-1012)
zmieniono: [m9-04-r-04] => (item=VLAN-1013)
zmieniono: [m9-04-r-04] => (item=VLAN-1100)

TASK [mk_routeros_emergency_on : Zmień domyślny koszt OSPF area1 na 10] ******************
zmieniono: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Zmień adresy IP interfejsów MGMT] ********************
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})

TASK [mk_routeros_emergency_on : Generuj gARPy dla interfejsów MGMT] *********************
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
zmieniono: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})

PLAY RECAP ************************************************************************

Gotowe!

W rzeczywistości nie jest to jeszcze do końca gotowe, nie zapominamy o zbieżności dynamicznych protokołów routingu oraz obciążeniu dużej liczby tras w FIB. Na to nie mamy wpływu. Czekamy. Zbieżność osiągnięta. Teraz już jest gotowe.

A w wiosce Vilabaggio (która nie chce zautomatyzować konfiguracji sieci) nadal zmywają naczynia. Bruce (wprawdzie już inny, ale nie mniej interesujący) stara się zrozumieć, ile jeszcze trzeba ręcznie rekonfigurować sprzęt.

Chciałbym także zatrzymać się nad jednym ważnym zagadnieniem. Jak możemy wszystko przywrócić do stanu pierwotnego? Po pewnym czasie, przywrócimy do życia nasz FW-CLUSTER. To jest podstawowy sprzęt, a nie zapasowy, na nim powinna działać sieć.

Czujesz, jak zaczyna się denerwować administratorów sieci? Dyrektor techniczny usłyszy tysiąc argumentów, dlaczego tego nie należy robić, dlaczego można to zrobić później. Niestety, praca sieci składa się z wielu łatek, kawałków, pozostałości dawnej świetności. Powstaje patchwork. Naszym celem ogólnie, nie w tej konkretnej sytuacji, ale w ogóle jako specjalistów IT — jest doprowadzenie pracy sieci do pięknego angielskiego słowa „consistency”, które ma wiele znaczeń, można je przetłumaczyć jako: spójność, niesprzeczność, logiczność, synchronizacja, systematyczność, porównywalność, koherencja. To wszystko o nim. Tylko w takim stanie sieć jest zarządzalna, wyraźnie rozumiemy, co i jak działa, dokładnie wiemy, co trzeba zmienić, w razie potrzeby, i dokładnie wiemy, gdzie szukać, gdy pojawiają się problemy. Tylko w takiej sieci można wykonywać sztuczki, podobne do tych, które teraz opisujemy.

W rzeczywistości przygotowano jeszcze jeden playbook, który przywracał ustawienia do stanu początkowego. Logika jego działania jest taka sama (ważne jest, aby pamiętać, że kolejność zadań jest kluczowa), aby nie wydłużać i tak dosyć długiego artykułu, postanowiliśmy nie publikować wykonania playbooka. Po przeprowadzeniu takich ćwiczeń poczujesz się znacznie spokojniej i pewniej w przyszłości, ponadto wszelkie prowizoryczne rozwiązania, które tam zbudowałeś, od razu się ujawnią.

Wszyscy chętni mogą do nas napisać i otrzymać źródła całego napisanego kodu, razem ze wszystkimi playbookami. Kontakty w profilu.

Wnioski

Naszym zdaniem procesy, które można zautomatyzować, jeszcze nie wykrystalizowały się. Biorąc pod uwagę, z czym się spotykaliśmy oraz to, co omawiają nasi zachodni koledzy, widoczne są następujące tematy:

Zarządzanie urządzeniami;
Zbieranie danych;
Raportowanie;
Rozwiązywanie problemów;
Zgodność.

Jeśli będziemy zainteresowani, możemy kontynuować dyskusję na jeden z poruszanych tematów.

Chciałbym również nieco podyskutować na temat automatyzacji. Jak powinna wyglądać w naszym rozumieniu:

System powinien działać bez człowieka, jednocześnie będąc doskonalonym przez człowieka. System nie powinien zależeć od człowieka;
Eksploatacja powinna być wyspecjalizowana. Brakuje klasy specjalistów, którzy wykonują rutynowe zadania. Są eksperci, którzy zautomatyzowali całą rutynę i angażują się jedynie w skomplikowane zadania;
Standardowe rutynowe zadania są realizowane automatycznie «po naciśnięciu przycisku», nie angażują zasobów. Wyniki takich zadań są zawsze przewidywalne i jasne.

A do czego te punkty powinny prowadzić:

Przejrzystości infrastruktury IT (mniejsze ryzyko eksploatacji, modernizacji, wdrożeń. Mniej przestojów w roku);
Możliwości planowania zasobów IT (system planowania pojemności — widać, ile jest konsumowane, ile zasobów potrzeba w jednolitym systemie, a nie w e-mailach i wizytach u kierowników działów);
Możliwości ograniczenia liczby obsługującego personelu IT.

Autorzy artykułu: Aleksander Człowiekow (CCIE RS, CCIE SP) i Paweł Kirilow. Ciekawi nas rozmowa i proponowanie rozwiązań na temat automatyzacji infrastruktury IT.

Źródło: habr.com