Implementace změn v živých sítích

Transkript

1 Tieto Corporation Public Implementace změn v živých sítích aneb jak síť změnit a nic nerozbít Petr Grygarek, Martin Oleš

2 Obsah prezentace Síťová praxe a změny v sítích Proč měnit, co měnit, jak měnit, kdy měnit a kdy neměnit Příklady implementace změn Příklad 1: Upgrade IOS síťového prvku Cisco VSS 1440 Příklad 2: Rekonstrukce a převzetí zastaralého lokálního datacentra 2 Tieto Corporation

3 Síťová praxe a změny v sítích Na zelené louce se síť staví spíše výjimečně Naproti tomu změny v existujících prostředích za plného nebo místně či časově dočasně omezeného se dějí velmi často Při změně nesmíme rozbít ani omezit nic, co nebylo v plánu Dobře naplánovat a implementovat změnu může být výrazně těžší než postavit novou síť Ve zcela nové síti není provoz a uživatelé, takže není co pokazit ;-) Nicméně i každá nová síť má návaznost na starou část 3 Tieto Corporation

4 Proč něco měnit Změny jsou standardní součástí provozní praxe a zákazník za ně také platí vždy jsou spojeny s jistým rizikem ne všechna rizika lze vždy předem podchytit na sdíleném prostředí jiní zákazníci ve stejnou chvíli platí za to, že vše normálně funguje Reakce na požadavky a aktuální potřeby zákazníka Optimalizace na straně provozovatele sítě (úspora nákladů) Obnova zastaralých systémů Přechod na nové technologie 4 Tieto Corporation

5 Co se obvykle mění? Od připojení jediného serveru přes upgrade síťového prvku až po změnu infrastruktury datacentra Obnova síťových prvků s končící životností Také upgrade na novou verzi firmware Optimalizace (a.k.a. úklid) I pečlivě navržená a systematicky udržovaná síť se časem změní v chaos (i administrátoři jsou jenom lidé ) Úklid v takovéto síti je předpokladem úspěchu dalšího rozvoje Rozšíření počet přípojných míst, kapacity linek či zařízení, Redukce i odchody zákazníků jsou běžná realita Změna architektury s ohledem na nové provozované služby či technologie 5 Tieto Corporation

6 Jak měnit (1)? Hlavně tak, aby se nepokazilo něco, co má fungovat ;-) Předpokladem úspěchu je dobrý plán pečlivě promyslet nejen kroky postupu, ale i potenciální rizika jednotlivých kroků a možné reakce na případné problémy Vhodné telefonní číslo na vhodného člověka je vždy k nezaplacení ;-) včetně veškeré logistiky a detailní znalosti prostředí během servisního okna není čas nic hledat! Změny se zpravidla realizují jako posloupnost menších kroků, kdy se v případě neočekávané situace dokážeme vždy v rozumném čase vrátit o krok zpět Nebo o 2 kroky dopředu či úkrok stranou, abychom vše opět zprovoznili a měli čas rozmyslet, co dál Vždy musí být dost času i na případný rollback Po každé změně nebo jejim kroku je nutné vše podstatné otestovat Pokud nechcete při zaslouženém návratu po dobře vykonané práci troubleshootovat v letištní hale 5 min před uzavřením přepážky k 6 vašemu letu domů Tieto Corporation

7 Jak měnit (2)? Rozsáhlejší změny prováděné v součinnosti několika lidí rozesetých po světě je nutné dobře koordinovat aspoň koordinátor by měl vždy vědět, co se právě děje ne vždy je reálné, aby každý pracovník znal detaily celého rozsahu změny měníme aplikační prostředí, nejen síť samotnou část kroků prováděna serverovými správci, správci loadbalancerů či jiných platforem Při jakémkoli zásahu do živé sítě se vyplatí postupovat uvážlivě Síť je složitý mechanismus, o provozu v ní ani použitých technologiích nevíte vše, takže trocha respektu nikdy neuškodí neexperimentovat s neznámými částmi (technologie, část sítě apod.) Nepodceňovat význam neznámých zařízení a spojů přepínač se 3 živými porty může být důležitý fa0/1: Váš CEO, fa0/2: dánská královna, fa0/3: uplink trunk ;-) Přes půl roku neaktivní vytáčenou linku může pouze vždy na Silvestra o půlnoci téct zásadní firemní uzávěrka do auditorské firmy 7 Tieto Corporation

8 Jak měnit (3) Časově nejnáročnější částí změny je její detailní příprava Často i několik měsíců Během servisního okna není čas na velké přemýšlení V případě vzdáleného datacentra je nutné přípravu i provedení změny zvlášť dobře rozdělit na části s nutnou fyzickou přítomností a části realizovatelné vzdáleně Dopad na cestovní náklady i váš čas strávený na cestách 8 Tieto Corporation

9 Kdy měnit? V době s očekávaným sníženým provozem Jistě, 3:00 a.m. - ale kterého lokálního času ;-)? Podle servisních oken dlouhodobě nebo operativně dohodnutých se zákazníkem Což je těžké zvláště v systémech sdílených více zákazníky Ihned, pokud je výpadek kritický Nehrozí, že ad-hoc opravou situace pro jednoho zákazníka rozbiju komunikaci 20 dalším? 9 Tieto Corporation

10 A kdy raději neměnit? Pokud rizika spojené se změnou nevyváží předpokládaný efekt Rizika pro měněného zákazníka, ostatní zákazníky, síťovou infrastrukturu jako takovou Co když sdílený síťový prvek běžící10 let po vypnutí už nenaběhne? Funguje to - nesahej na to (nebo se pak nediv) Neopravuj to pokud to není rozbitý Pokud už to nestojí za to (zbytečná práce) V dohledu je komplexnější rekonstrukce, zákazník odchází apod Což se ovšem ne vždy ví 10 Tieto Corporation

11 Co nerozbít? Je žádoucí vědět, co může být ovlivněno a co výpadek může stát Co se nesmí (za žádnou cenu) rozbít Identifikace kličových systémů Co se může rozbít, na jak dlouho a kdo o tom musí předem vědět Často příprava náhradních uživatelských řešení na dobu výpadku Např. přesměrování příchozích hovorů pracovníků call centra na mobilní telefony během rekonstrukce VoIP řešení 11 Tieto Corporation

12 Přece se nemůže nic stát I drobná změna v síti nebo dokonce na připojeních zařízeních může mít fatální důsledky. Pár příkladů z praxe: Duální připojení serveru s instalovaným bridging software Připojení PC s dobře vydařeným virem útočícím na control plane síťové infrastruktury Připojení malého přepínače s polovičatou podporou Spanning Tree Připojení na konzoli CatOS routeru běžícího 15 let způsobí jeho hardwarový pád Bug v IOSu po zadání příkazu show log reloaduje box Přidání VLAN do trunku s neúmyslným odstraněním všech ostatních 12 ; Tieto Corporation

13 Jak to dělat správně aneb Change Management Process ITIL Incident Management Change Management také definice standardizovaných změn Problem Management Change ticket popis změny, důvod změny, ovlivněné systémy a zákazníci/služby, způsob ovlivnění a plánovaná servisní okna, analýza rizik a jak jim předejít detailní postup (příprava, provedení), změny HW/SW/konfigurace účastníci + kontakty a jim přiřazené akce, komunikace během změny včetně třetích stran, např. ISP nebo vzdálené body tunelů testovací plán, plán a podmínky pro rollback technický peer review, schválení managementem a zákazníkem schválení před provedením změny a akceptace jejich výsledků 13 Tieto Corporation

14 Tieto Corporation Public Pár příkladů aneb jak jsme měnili a [ne]rozbili

15 Tieto Corporation Public Příklad 1 Upgrade IOS síťového prvku Cisco VSS 1440

16 Co je Cisco VSS Pár fyzických Cisco 6500 chovajících se jako jeden celek Společný management i control plane Zařízení připojována pomocí portchannelu vedoucího do obou členů VSS páru Jednoduchá logická topologie, STP neblokuje žádný port, méně síťových prvků k managementu, odolnost proti výpadku fyzického prvku člena páru 16 Tieto Corporation

17 L2 topologie jedné z produkčních sítí distribuovaného DC 17 Tieto Corporation

18 Fyzická topologie uzlu DC 18 Tieto Corporation

19 L3 topologie produkční sítě 19 Tieto Corporation

20 Příprava (1) Sdílené prostředí využití servisního okna Vyhledání nebo kvalifikovaný odhad, kteří zákazníci budou výpadkem ovlivněni Vytvoření plánu IOS upgrade Čím detailnější, tím lépe Vytvoření komunikačního plánu (adresáře) techniků, testerů, techniků zákazníka, managerů Většinou jeden centrální koordinátor Ověření s Cisco vhodnosti verze IOS (bugs, HW compatibility, features), revize vytvořeného plánu (hlavně z technického pohledu) 20 Tieto Corporation

21 Příprava (2) Schválení plánu a času výpadku managementem Alokace Cisco TAC engineera Alokace Database specialisty Alokace Windows/Linux/Unix/AIX/VMWare/Exchange specialistů Aktualizace komunikačního plánu Záloha stávajícího IOS Záloha konfigurace Oznámení výpadku dohledovému centru Oznámení výpadku zákazníkům Obvykle začátek 23:00, oznámena série krátkých výpadků 21 Tieto Corporation

22 Vlastní akce (1) 30 minut před plánovaným výpadkem otevření všech dohodnutých komunikačních kanálů Navázání Cisco TAC telekonference Navázání telekonference mezi koordinátorem a všemi zúčastněnými techniky Nahrání nového IOS dle plánu Přítomnost technika přímo u daného VSS Oznámení výpadku dohledovému centru Dohledové systémy budou hlásit výpadky (nedostupnost serverů) Reload aktivního člena VSS Pasívní sledování provozu, v ideálním případě žádný výpadek Sledování a ukládání výpisu z obou konzolí SW Komunikace s technikem přítomným u VSS (svítí/nesvítí) 22 Tieto Corporation

23 Vlastní akce (2) Ukončení bootu člena VSS Ověření funkčnosti, začlenění do VSS Houston, we've had a problem Line karty člena VSS s novým IOS nejsou vidět Provoz jde skrz druhého člena VSS se starou verzi IOS Aktivní komunikace s Cisco TAC engineerem Dle TAC se jedná o normální jev kvůli rozdílu verze IOS mezi členy VSS Při reload zbývajícího člena VSS, dojde k aktivaci line karet Rozhodnuto o reloadu druhého člena VSS 23 Tieto Corporation

24 Vlastní akce (3) Člen VSS s novým IOS začal aktivovat line karty Síťový provoz přerušen jeden člen bootuje, druhý teprve aktivuje karty Karty jsou aktivovány, člen VSS s novým IOS obsluhuje síťový provoz Druhý člen dokončil boot a začlenil se do VSS Ověření stavu VSS jeví se normálně, síťový provoz je viditelný Houston, we've had a problem again V logu jde vidět masivní flapping všech Ethernet rozhraní na kartě ve slotu 1 Porty jsou nahoře, ale flap kvůli UDLD a SpanningTree 24 Tieto Corporation

25 Vlastní akce (4) Aktivní komunikace s Cisco TAC engineerem Ověření chyby hardware line karty ve slotu 1 TAC doporučuje vytažení karty a znovu usazení Technik v datacentru vyjme line kartu a po minutě opět vrátí do slotu Ověření stavu line karty Test hardware ukončen, karta je v pořádku Ethernet porty nahoře UDLD a SpanningTree vypadají korektně Intenzívní ověření celkového stavu VSS Hromada příkazů uvedených v plánu Porovnání výstupu s předpokládaným výstupem (dle pečlivosti přípravy), je 2:00 ráno, intelektuální kapacita omezena 25 Tieto Corporation

26 Vlastní akce (5) Oznámení ukončení prací všem dalším zúčastněným členům Koordinátor kontaktuje všechny dle komunikačního plánu Database technik začal ověřovat stav databazí, opravil split brain shutdown Windows/Linux/AIX technici potvrdili funkčnost Dohledové centrum potvrzuje, že už žádné nové poplachy nechodí 3:00 ráno všichni členové potvrdili, že systémy fungují jak mají Ukončení aktivní části upgradu IOS a telekonferencí Bezvědomí 26 Tieto Corporation

27 Afterparty Během pracovního dne monitoring VSS CPU, logy, ohlášené problémy které mohou mít souvislost Nový bug v IOS CSCuf36123, všichni členové network týmu musí být s ním seznámeni VSS rebootuje při vytváření nových VLAN conf t vlan 1234 name CUSTOMER-A vlan 1235 ssh: connection lost 27 Tieto Corporation

28 Tieto Corporation Public Příklad 2 Rekonstrukce a převzetí zastaralého lokálního datacentra (síťová část)

29 Definice cílů Eliminace zastaralých a fyzicky rozměrných síťových prvků Omezení spotřeby energie, úspora místa, podpora výrobce Obnovení systematické struktury sítě Symetrizace a obnovení plné redundance Rozdělení do fyzicky oddělených oblastí hostitelského datacentra (místností) Stanovení pravidel jednotné implementace budoucích zákazníků orientace na tradiční 3-vrstvé aplikace Architektura přístupové vrstvy: tradiční L2, s Top-of-Rack SW všechny VLAN všude Nalezení, potvrzení a odstranění nepoužívaných částí sítě včetně připojených serverů a VPN tunelů Úklid FW pravidel Aktualizace implementace monitorovacích nástrojů 29 Tieto Corporation

30 Omezení Minimální prostředky na nákup nových zařízení ale jsou k dispozici SW použitelné jako ALS a DLS znovupoužití části stávajících zařízení Jediné výpadkové servisní okno (cca 4h) Omezený počet propojů mezi místnostmi DC Změna adresního plánu s ovlivněním serverů všech zákazníků nereálná Z toho plyne potřeba převzetí stávající L3 segmentace Případné systematické přečíslování VLAN nutno koordinovat se správci VMWare ESX a dalších zákaznických serverů připojených přes trunk 30 Tieto Corporation

31 Původní stav 31 Tieto Corporation

32 Analýza současného stavu (1) Získání přístupů na síťové prvky, fyzicky do datacentra Získání kontaktů na spolupracující skupiny serverové a aplikační týmy, zákaznická IT Získání stávající (nekompletní a zastaralé) dokumentace Analýza a dokumentace aktuálního síťové topologie a konfigurace Zjištění: Multitenant architektura ešena pomocí VRF, VLAN a FW kontextů Z největší části vzdáleně fyzické propojení síťových prvků, analýza a dokumentace L2 topologie (VLAN) a L3 topologie včetně směrování (sousedské vazby, redistribuce) Na místě následně dohledání propojů k neznámým zařízením Fyzická prohlídka rozvaděčů zjištění aktuálního fyzického rozmístění prvků a dostupného prostoru seznámení se stávající kabeláží, včetně externích linek 32 Tieto Corporation

33 Analýza současného stavu (2) Analýza aktuální utilizace síťových prvků a linek Identifikace (a potvrzení) již nevyužívaných zařízení a spojů Aktualizace dokumentace (reálný aktuální stav) Na základě ní je navržen plán změny Zákaz provádění dalších drobných změn během plánování Nebo alespoň nutnost informování designera nové architektury, který připravuje změnový plán 33 Tieto Corporation

34 Naplánování nové architektury Analýza a dokumentace požadavků současná omezení a potřeby, výhled potřeb do budoucnosti, co se naopak nepředpokládá Popis a zdůvodnění volby architektury, popis způsobu rozšiřování sítě High-level a Low-level design L1 (porty), L2 (VLANs + STP) a L3 (routing) design Naplánování počtu zařízení naškálování s ohledem na počet serverů/externích linek, které je nutné připojit S rozumnou rezervou realisticky zohledňující předpokládaný růst v dohledné době Zohledněn plánovaný převod fyzických serverů na VM Popis předpokládaného způsobu implementace zákazníků (implementační šablona) doporučené schema FW zón, systematické číslování VLAN, plán využívání privátních IP adres, 34 Tieto Corporation

35 Nová vrstvená architektura Logická topologie 35 Tieto Corporation

36 Nová vrstvená architektura Fyzická topologie 36 Tieto Corporation

37 Naplánování postupu změny - základní filosofie (1) Vybudování základu nového switching bloku a jeho propojení s core prvky - bezvýpadkově zahoření a otestování postupný přenos serverů v dohodnutých výpadkových oknech Po skupinách aplikační vzájemně provázaných serverů Koordinace s aplikačními a serverovými týmy Před přenosem nutno aplikace a OS korektně vypnout, po skončení opět nastartovat a otestovat Fyzická návaznost také na SAN síť Odstranění nepoužívaných částí sítě - bezvýpadkově Získání síťových prvků pro rozšíření nového switching bloku a zařízení v rolích WAN edge a VPN koncentrátorů a uvolnění místa v rozvaděčích Hlavní servisní okno ohlášený celkový výpadek Přepojení a rekonfigurace core i recyklovaných zařízení Symetrizace rozdělení redundantních zařízení do 2 místností Přepojení linek k ISP a do WAN zákazníků 37 Tieto Corporation

38 Naplánování postupu změny - základní filosofie (2) Po ukončení základní fáze rekonstrukce Převod existujících zákazníků do jednotné implementační šablony Po jednotlivých zákaznících, v koordinaci se zákazníkem U některých zákazníků nebude reálné, zůstanou ve stávajícím stavu Odstranění neaktuálních VPN tunelů Optimalizace existujících FW pravidel, návrh konsolidace nejlépe automatizovaně 38 Tieto Corporation

39 Přípravné práce Plán nového rozmístění prvků v rozvaděčích Zahoření nových prvků (s instalací aktuálního OS) Oštítkování všech síťových zařízení podle nového jmenného schematu Plán nové kabeláže objednávka propojů mezi místnostmi a k externím linkám, označení, ověření Detailní nákres topologie Seznam spojů port-port typ SFP, délka a typ patch kabelu, vedení kabelu (pozice na patchpanelech) - odškrtávací seznam Určení počtu a objednávka SFP modulů a TP i FO patch kabelů Příprava kompletních konfigurací pro nově instalovaná i recyklovaná zařízení předkonfigurování nových (zahořených) zařízení 39 Tieto Corporation

40 Přípravné práce (2) Uschování aktuálních konfigurací a stavových informací směrovacích vazeb, CDP vazeb, směrovacích tabulek, mohou se hodit pro případ rollbacku a troubleshootingu 40 Tieto Corporation

41 Detailní naplánování akcí v servisním okně Upřesnění posloupností akcí jednotlivých členů týmu i koordinační body v datacentru je všude daleko a hluk Logistika přesunů síťových prvků mezi částmi DC ne všechno unese jeden člověk v ruce Ujasnění uložení materiálu kabely, SFP, montážní materiál, nářadí, 41 Tieto Corporation

42 Akce v servisním okně Demontáž starých a montáž nových síťových prvků Nahrání předpřipravených konfigurací do recyklovaných prvků Zakabelování Kontrola stavu portů a LLDP/CDP sousedství, STP, vazeb směrovacích protokolů, obsahu směrovacích tabulek, Kontrola konektivity koncových systémů (dle testovacího plánu) Troubleshooting a v kritickém případě rollback 42 Tieto Corporation

43 Den poté Aktualizace monitoringu Kosmetické úpravy, které nebyly prioritní v servisním okně Organizace a estetická úprava kabeláže, oštítkování Popisky v konfiguraci, Finalizace dokumentace podle skutečného stavu během změny Být k dispozici na telefonu a připraven reagovat vždycky se na něco zapomene ;-) 43 Tieto Corporation

44 Tieto Corporation Public Děkujeme za pozornost Q & A

45 Tieto Corporation Public