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

Public

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

© Tieto Corporation

aneb jak síť změnit a nic nerozbít

Petr Grygarek, Martin Oleš

Public

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


2013-11-05

Public

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


2013-11-05

Public

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


2013-11-05

Public

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


2013-11-05

Public

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

6

• 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 vašemu letu domů © Tieto Corporation 2013-11-05

Public

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


2013-11-05

Public

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


2013-11-05

Public

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


2013-11-05

Public

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


2013-11-05

Public

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


2013-11-05

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

;


2013-11-05

Public

“Přece se nemůže nic stát…”

• 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


2013-11-05

Public

Jak to dělat „správně“ aneb Change Management Process

Public

Pár příkladů


aneb jak jsme měnili a [ne]rozbili

Public

Příklad 1


Upgrade IOS síťového prvku Cisco VSS 1440

Public

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


2013-11-05

17


2013-11-05

Public

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

Public

Fyzická topologie uzlu DC

18


2013-11-05

19


2013-11-05

Public

L3 topologie produkční sítě

Public

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


2013-11-05

Public

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


2013-11-05

Public

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


2013-11-05

Public

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


2013-11-05

Public

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


2013-11-05

Public

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


2013-11-05

Public

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


2013-11-05

Public

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


2013-11-05

Public

Příklad 2 Rekonstrukce a převzetí zastaralého lokálního datacentra


(síťová část)

Public

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


2013-11-05

Public

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


2013-11-05

Public

Původní stav

31


2013-11-05

• 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


2013-11-05

Public

Analýza současného stavu (1)

Public

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


2013-11-05

• 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


2013-11-05

Public

Naplánování nové architektury

Public

Nová vrstvená architektura Logická topologie

35


2013-11-05

Public

Nová vrstvená architektura Fyzická topologie

36


2013-11-05

- 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


2013-11-05

Public

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


2013-11-05

Public

Naplánování postupu změny

Public

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


2013-11-05

Public

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


2013-11-05

• 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


2013-11-05

Public

Detailní naplánování akcí v servisním okně

Public

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


2013-11-05

Public

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


2013-11-05


Děkujeme za pozornost

Q&A

Public


Public

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

Recommend Documents