← Všechny kurzyZpět do simulátoru →

Odolnost a škálování sítě

Sítě, které přežijí poruchu a unesou nápor: jediný bod selhání (SPOF) a vysoká dostupnost (N-1), HA pár firewallů (active/standby vs active/active, failover, stavová synchronizace, split-brain), load balancing (scale-out, VIP, algoritmy, sticky sessions, health check), mapa redundance (STP, HSRP/VRRP, EtherChannel/LAG, multi-WAN) a návrh odolné sítě podle analýzy rizik.

Tohle je textový náhled lekcí pro čtení. Plná verze – interaktivní simulátor s animacemi, úlohami a kvízy – běží v aplikaci.

▶ Spustit interaktivní verzi

Lekce 1: Proč odolnost: SPOF a N-1

Jeden bod selhání (SPOF)

NETFW-AFW-BLBWEB-1WEB-2normální provoz: NET → FW → LB → server

V předchozích kurzech jsi stavěl sítě, které fungují. Teď je naučíme přežít, když se něco pokazí – protože ono se to jednou pokazí vždycky. Napájení vypadne, kabel někdo zakopne, zařízení odejde po letech provozu. Klíčový pojem zní SPOF (single point of failure – jediný bod selhání): prvek, jehož výpadek shodí celou síť, protože žádná náhradní cesta neexistuje. Podívej se na scénu jako na cestu paketu od uživatelů z internetu (NET) až k webovému serveru: NET → firewall → load balancer → server. Kdyby v té řadě byl každý prvek jen jednou, je to řetěz samých SPOF – stačí, aby praskl jeden článek, a celá služba je nedostupná. Proto na scéně vidíš prvky zdvojené: dva firewally (FW-A, FW-B), dva webové servery (WEB-1, WEB-2) a mezi nimi load balancer. To není plýtvání – to je pojistka. Zbytek kurzu je o jediné otázce: kde v síti je SPOF a jak ho odstranit, aniž bys z jednoduché sítě udělal nezvladatelnou obludu.

Krok za krokem

  1. Provoz teče od uživatelů z internetu přes firewall a load balancer až k webovému serveru. Zatím jde všechno.
  2. Kdyby byl firewall v síti jen jednou, jeho výpadek by odřízl úplně všechno. To je SPOF: jediný bod selhání.
  3. Proto jsou prvky zdvojené: když vypadne FW-A, provoz jde přes FW-B; když WEB-1, obslouží WEB-2. SPOF zmizel.
  4. Zdvojení jednoho prvku ale může odhalit další SPOF: co když je jediný load balancer? Hledání SPOF je práce na celý kurz.

Vysoká dostupnost a N-1

NETFW-AFW-BLBWEB-1WEB-2N prvků: vše běží

Když odstraníš SPOF, získáš vysokou dostupnost (HA – high availability): schopnost sítě běžet dál, i když se něco porouchá. Inženýři pro to mají krátké pravidlo N-1: síť musí ustát výpadek jednoho libovolného prvku a přitom dál obsloužit provoz. Máš dva firewally? Jeden smí spadnout (N-1) a druhý to utáhne. Máš tři servery, kde zátěž zvládnou dva? Taky N-1. Nejde o to mít všeho dvakrát „pro pocit", ale vědomě spočítat, kolik prvků smí naráz vypadnout, aniž služba padne. Jak dobrá dostupnost je „dost"? Měří se v procentech času, kdy služba běží. Slýchaná meta „pět devítek" (99,999 %) znamená jen pár minut výpadku za celý rok – a je nesmírně drahá. Dvě čísla, která tě u toho budou strašit: MTBF (mean time between failures – jak dlouho prvek průměrně vydrží bez poruchy) a RTO (recovery time objective – jak rychle se musíš vzpamatovat, když už porucha nastane). Zapamatuj si smysl, ne vzorce: N-1 říká, kolik toho smí naráz selhat; RTO říká, jak rychle se z toho síť sama vzpamatuje.

Krok za krokem

  1. Vysoká dostupnost = síť běží dál i při poruše. Pravidlo N-1: musí ustát výpadek jednoho libovolného prvku.
  2. FW-A vypadl – druhý firewall provoz převezme a služba jede dál. To je N-1 v praxi.
  3. MTBF říká, jak dlouho prvek průměrně vydrží bez poruchy – ale žádné číslo neznamená „nikdy nespadne".
  4. A RTO říká, jak rychle se síť po poruše vzpamatuje. „Pět devítek" (99,999 %) = pár minut výpadku za rok – a je to drahé.

Najdi SPOF: audit a test odolnosti

NETFW-AFW-BLBWEB-1WEB-2jednoduchá řada: klient → FW → server

Teorii SPOF a N-1 si teď osaháš přímo v simulátoru – a hezky ti k tomu poslouží dva nástroje. První je kontrola topologie: projde tvou síť a upozorní na slabá místa, včetně prvků a linek, které jsou jediné svého druhu na kritické cestě. Druhý je test odolnosti (kontrola N-1): simulátor postupně „vypne" každý prvek zvlášť a zkusí, jestli se provoz od zdroje k cíli i tak dostane. Prvek, po jehož vypnutí spojení spadne, je tvůj SPOF – přesně ten, který audit ukázal. Vyzkoušej to: postav jednoduchou řadu (klient → jeden firewall → server), spusť test odolnosti a uvidíš, že vypnutí firewallu spojení přeruší. Pak přidej druhý firewall jako HA pár (jak přesně, ukáže lekce 2), test spusť znovu – a výpadek jednoho firewallu už služba přežije. Tenhle cyklus „najdi SPOF → zdvoj ho → ověř testem" je jádro celého návrhu odolné sítě. Nauč se u toho jedné disciplíně: neškálovat naslepo. Nejdřív zjisti, kde tě to nejvíc bolí (audit), teprve pak přidávej – a po každém zásahu si ověř, že SPOF opravdu zmizel a žádný nový nevznikl.

Krok za krokem

  1. Postav v simulátoru jednoduchou řadu a spusť nad ní kontrolu topologie – ta kritická slabá místa vypíše.
  2. Test odolnosti vypne firewall a zkusí spojení znovu – spadne. Tenhle prvek je SPOF.
  3. Přidej druhý firewall jako HA pár (lekce 2). Teď existuje náhradní cesta přes FW-B.
  4. Cyklus návrhu: najdi SPOF → zdvoj ho → ověř testem. A po každém zásahu zkontroluj, že nevznikl nový.

▶ Otevřít v simulátoru

Lekce 2: Vysoká dostupnost: HA pár

Active/standby vs active/active

NETFW-AFW-BLBWEB-1WEB-2active/standby: FW-A obsluhuje

Nejčastější způsob, jak odstranit SPOF u firewallu nebo routeru, je HA pár: dvě stejná zařízení, která se domluví, že spolu tvoří jeden logický celek a jedno zaskočí za druhé. Existují dva režimy. Active/standby (aktivní/záložní): jedno zařízení (FW-A) veškerý provoz obsluhuje, druhé (FW-B) tiše čeká jako záloha a průběžně kontroluje, že aktivní žije. Když aktivní spadne, záložní se probudí a převezme jeho roli. Výhoda: jednoduché, předvídatelné, žádné hádky o to, kdo co dělá. Nevýhoda: záložní zařízení většinu času nic nedělá – platíš dva kusy, využíváš jeden. Active/active (aktivní/aktivní): obě zařízení obsluhují provoz současně a rozdělují si zátěž; když jedno spadne, druhé nabere i jeho díl. Výhoda: využiješ oba kusy a máš víc výkonu. Nevýhoda: složitější – musí se řešit, aby obě viděla stejný stav spojení, a při výpadku musí to zbývající utáhnout plnou zátěž (takže ani „aktivní/aktivní" pár nesmíš zatížit na 100 %, jinak po výpadku druhý přetíží). V simulátoru najdeš u firewallu i L3 prvku sekci HA s volbou režimu: aktivní/aktivní, nebo aktivní/záložní. Jak přesně proběhne to „převzetí", ukáže další modul.

Krok za krokem

  1. Active/standby: FW-A obsluhuje veškerý provoz. FW-B tiše čeká jako záloha.
  2. Daň za jednoduchost: záložní FW-B většinu času jen čeká – platíš dva kusy, využíváš jeden.
  3. Active/active: obě zařízení obsluhují současně a dělí si zátěž. Využiješ oba kusy a máš víc výkonu.
  4. Pozor: i active/active pár nesmíš zatížit na 100 %. Po výpadku musí druhý utáhnout plnou zátěž. V simulátoru: sekce HA + režim.

Jak proběhne failover

NETFW-AFW-BLBWEB-1WEB-2heartbeat: FW-B slyší tep FW-A

Jak přesně proběhne to „převzetí"? Říká se mu failover a má tři fáze. 1) Detekce. Zařízení v HA páru si mezi sebou posílají krátké zprávy „žiju" (heartbeat) po vyhrazené lince. Dokud FW-B slyší tep FW-A, nic nedělá. Když tep na pár okamžiků umlkne, FW-B usoudí, že aktivní spadl. 2) Převzetí. Záložní zařízení se prohlásí za nové aktivní a převezme identitu, na kterou zbytek sítě posílá provoz – hlavně sdílenou virtuální IP a MAC adresu brány (tenhle trik znáš z kurzu 10 jako HSRP/VRRP: klienti mluví se stále stejnou adresou brány, i když se pod ní vymění fyzické zařízení). 3) Přesměrování. Okolní prvky se dozvědí, že adresa teď patří jinému zařízení, a provoz začne téct přes něj. Klíčové číslo je, jak dlouho to celé trvá – doba failoveru. Dobře nastavený pár to zvládne za sekundy či zlomky sekundy: uživatel zaznamená nanejvýš krátké zaškobrtnutí, existující stažení možná musí navázat, ale služba jako celek jede dál. V simulátoru si to vyzkoušíš přímo: postav HA pár firewallů a v kontextovém menu aktivního zvol „Simulovat výpadek (HA)". Uvidíš, jak roli převezme standby a jak provoz najde novou cestu – přesně to, co jsi v lekci 1 ověřoval testem odolnosti.

Krok za krokem

  1. Detekce: firewally si po vyhrazené lince posílají „žiju" (heartbeat). Dokud FW-B slyší tep, nedělá nic.
  2. FW-A spadne, tep umlkne. FW-B po pár okamžicích usoudí, že aktivní zařízení už nežije.
  3. Převzetí: FW-B se prohlásí za aktivní a převezme virtuální IP/MAC brány – klienti adresu nemění (jako HSRP/VRRP).
  4. Přesměrování: provoz teče přes FW-B, celé to trvá sekundy. V simulátoru: v menu aktivního zvol „Simulovat výpadek (HA)".

Stavová synchronizace a split-brain

NETFW-AFW-BLBWEB-1WEB-2FW-A kopíruje tabulku spojení do FW-B

Failover z minulého modulu má jednu zradu, kterou stojí za to domyslet. Firewall je stavový (vzpomeň na kurz 5): pamatuje si tabulku otevřených spojení, aby k nim pouštěl odpovědi. Když aktivní FW-A spadne a roli převezme FW-B, co se stane s tisíci právě probíhajícími spojeními? Pokud o nich FW-B nic neví, bude je považovat za „nezvané" a zahodí – uživatelům spadnou hovory, přenosy, přihlášení, i když samotná síť „jede". Řešením je stavová synchronizace: aktivní zařízení průběžně kopíruje tabulku spojení do zálohy, takže FW-B v okamžiku převzetí ví o všech spojeních a plynule v nich pokračuje. Failover je pak pro uživatele skoro neviditelný. Druhá zrada se jmenuje split-brain („rozdvojený mozek"): co když nespadl aktivní firewall, ale jen linka mezi nimi, po které jde heartbeat? FW-A žije dál a obsluhuje – ale FW-B tep neslyší, usoudí, že FW-A umřel, a taky se prohlásí za aktivní. Najednou jsou dva aktivní, oba si nárokují stejnou virtuální IP, a v síti nastane zmatek. Řešení je nad rámec začátečnického kurzu (druhá nezávislá heartbeat linka, „hlasování" o tom, kdo smí být aktivní) – tobě stačí vědět, že split-brain existuje, a chápat, proč se HA nesmí stavět na jediné propojovací lince.

Krok za krokem

  1. Firewall je stavový: pamatuje si otevřená spojení. Aktivní je průběžně kopíruje do zálohy – stavová synchronizace.
  2. Díky synchronizaci ví FW-B o všech spojeních a plynule v nich pokračuje – failover je pro uživatele skoro neviditelný.
  3. Zrada: co když spadne jen linka heartbeatu, ne firewall? FW-A žije, ale FW-B ho neslyší.
  4. Split-brain: oba se prohlásí za aktivní a nárokují stejnou virtuální IP. Proto HA nikdy nestav na jediné lince.

▶ Otevřít v simulátoru

Lekce 3: Load balancing

Scale-up vs scale-out a VIP

NETFW-AFW-BLBWEB-1WEB-2scale-up: jeden server, víc síly (strop) ⚠

HA pár řeší dostupnost – aby služba přežila výpadek. Ale co když služba nestíhá, protože jí přibylo uživatelů? Máš dvě cesty. Scale-up (škálování nahoru): vezmeš stávající server a dáš mu víc síly – rychlejší procesor, víc paměti. Jednoduché, ale naráží na strop: nejsilnější stroj má konečnou kapacitu, je drahý a je z něj zase jeden veliký SPOF. Scale-out (škálování do šířky): místo jednoho velkého serveru dáš víc menších a rozdělíš mezi ně zátěž. Tenhle přístup má dvě kouzla najednou: zvládne skoro libovolný nárůst (přidáš další server) a je rovnou odolný – když jeden server odejde, ostatní běží dál. Právě proto vidíš na scéně dva webové servery. Jak ale klienti poznají, na který z nich se připojit? Nesmějí to řešit – od toho je load balancer (rozdělovač zátěže). Klienti mluví s jedinou adresou, které se říká VIP (virtual IP – virtuální IP služby). Load balancer za tou VIP sedí, každé příchozí spojení přidělí některému serveru z fondu (poolu) a odpověď pošle zpět. Uživatel netuší, kolik serverů za VIP stojí, jestli je jich pět nebo padesát – vidí jednu službu. Jak přesně LB vybírá server a jak pozná, že je některý mrtvý, ukážou další dva moduly.

Krok za krokem

  1. Scale-up: dej jednomu serveru víc síly. Jednoduché, ale má strop – a je z něj zase jeden velký SPOF.
  2. Scale-out: dej víc menších serverů a rozděl mezi ně zátěž. Roste skoro libovolně a je rovnou odolný.
  3. Klient mluví s jedinou adresou – VIP. Netuší, kolik serverů za ní stojí; vidí jednu službu.
  4. Za VIP sedí load balancer: každé spojení přidělí některému serveru z fondu (poolu) a odpověď pošle zpět.

Algoritmy rozdělování

NETFW-AFW-BLBWEB-1WEB-2round-robin: střídá WEB-1 a WEB-2

Podle čeho load balancer vybere, na který server pošle nové spojení? Má několik algoritmů a stojí za to jim rozumět, protože každý se hodí jinam. Round-robin (dokola): spojení rozdává popořadě – první na WEB-1, druhé na WEB-2, třetí zase WEB-1… Spravedlivé a jednoduché, ideální, když jsou servery stejně silné a požadavky zhruba stejně náročné. Least-connections (nejméně spojení): nové spojení pošle tam, kde je právě nejmíň otevřených spojení. Lepší, když jsou požadavky různě dlouhé – server zaseknutý na pár těžkých přenosech nedostane další, dokud se neuvolní. Weighted (vážené): serverům přiřadíš váhy podle výkonu; silnější stroj dostane víc spojení než slabší. Hodí se, když máš nestejně silné servery. Source-IP (podle adresy klienta): stejný klient chodí pořád na stejný server. Proč by to někdo chtěl? Kvůli sticky sessions („přilepeným" relacím): některé aplikace si stav přihlášení nebo obsah košíku drží lokálně na tom serveru, kde jsi začal. Kdyby tě LB příště poslal jinam, přišel bys o košík. Source-IP (nebo cookie) tě proto přilepí ke „tvému" serveru. Poznámka na okraj: přilepení je berlička – čistší je, když si servery drží stav ve sdíleném úložišti mimo sebe (společná databáze nebo cache), takže je jedno, na který padneš. V simulátoru u load balanceru najdeš právě tyhle algoritmy: rr, leastconn, weighted, srcip.

Krok za krokem

  1. Round-robin: spojení rozdává popořadě – WEB-1, WEB-2, WEB-1… Ideální, když jsou servery stejně silné.
  2. Least-connections: nové spojení jde tam, kde je právě nejmíň otevřených. Lepší při různě dlouhých požadavcích.
  3. Weighted: serverům přiřadíš váhy podle výkonu – silnější stroj dostane víc spojení. Pro nestejně silné servery.
  4. Source-IP: stejný klient chodí pořád na týž server – sticky session, protože tam aplikace drží stav (košík, přihlášení).

Health check a mrtvý backend

NETFW-AFW-BLBWEB-1WEB-2LB se ptá: „žiješ?" (health check)

Load balancer, který slepě rozděluje zátěž, má skrytou past: co když jeden server ze fondu spadne? Kdyby o tom LB nevěděl, dál by na něj poctivě posílal každé N-té spojení – a každý takový uživatel by narazil na mrtvý server a dostal chybu. Rozdělování zátěže by tak paradoxně zhoršilo dostupnost. Proto každý pořádný load balancer dělá health check (kontrolu zdraví): pravidelně se každého serveru ve fondu ptá, jestli žije – od prostého „ozveš se na síti?" až po chytřejší „vrať mi testovací stránku a zkontroluju, že odpověď dává smysl". Server, který přestane odpovídat, LB vyřadí z fondu a přestane na něj posílat provoz. Uživatelé to nepoznají – spojení plynule tečou na zbývající zdravé servery. A až se server zase zotaví a začne odpovídat, LB ho vrátí zpět. Všimni si, jak se ti tady spojily obě půlky kurzu: load balancer neškáluje jen do šířky (víc výkonu), ale díky health checku dělá i odolnost – sám odstraní SPOF „mrtvý backend". V simulátoru si postav VIP na load balanceru s fondem dvou serverů, pošli přes VIP provoz a sleduj, jak se rozdělí. Pak jeden backend „vypni" a přesvědč se, že provoz teče dál jen na ten zdravý. To je scale-out a odolnost v jednom obrázku.

Krok za krokem

  1. Load balancer se každého serveru ve fondu pravidelně ptá, jestli žije – to je health check.
  2. WEB-1 spadne a přestane odpovídat. Slepý LB by na něj dál posílal každé N-té spojení – samé chyby.
  3. Health check WEB-1 vyřadí z fondu; provoz plynule teče jen na zdravý WEB-2. Uživatelé nic nepoznají.
  4. Až WEB-1 zase odpovídá, LB ho vrátí do fondu. Load balancer tak škáluje do šířky i odstraňuje SPOF „mrtvý backend".

▶ Otevřít v simulátoru

Lekce 4: Mapa redundance

Redundance L2 a brány

NETFW-AFW-BLBWEB-1WEB-2záložní L2 linka = smyčka ⚠

Máš za sebou dvě velké techniky odolnosti – HA pár a load balancing. Teď je čas poskládat mapu: v síti je totiž víc míst, kde hrozí SPOF, a na každé se hodí jiný nástroj. Většinu jsi už potkal v dřívějších kurzech, tady je spojíme na jedno místo. Začni odspodu. Vrstva L2 – smyčky: když mezi switche natáhneš záložní kabel, získáš redundanci, ale i nebezpečnou smyčku, ve které rámce krouží donekonečna (broadcast storm). Řešením je STP (Spanning Tree Protocol, kurz 6): záložní linku drží zablokovanou, a když hlavní spadne, smyčku bezpečně otevře. Redundance bez bouře. Vrstva brány (default gateway): počítače mají nastavenou jednu bránu ven – a kdyby ten router spadl, celá podsíť oněmí, i kdyby jinudy cesta byla. Řešením je HSRP/VRRP (kurz 10): dva routery sdílejí jednu virtuální IP brány; klienti ji nemění, a když aktivní router odejde, druhý ji převezme – přesně ten samý trik jako HA pár firewallu z lekce 2, jen na úrovni brány. Vidíš vzorec, který se táhne celým kurzem: jedna sdílená identita, dvě zařízení, tiché převzetí. V dalším modulu přidáme redundanci kapacity a připojení k internetu.

Krok za krokem

  1. Odspodu: záložní kabel mezi switche dá redundanci, ale i nebezpečnou smyčku (broadcast storm).
  2. STP záložní linku drží zablokovanou a otevře ji, až hlavní spadne – redundance bez bouře (kurz 6).
  3. Vrstva brány: kdyby spadl jediný výchozí router, celá podsíť oněmí, i kdyby jinudy cesta byla.
  4. HSRP/VRRP: dva routery sdílejí jednu virtuální IP brány; druhý ji převezme při výpadku – stejný trik jako HA pár (kurz 10).

Redundance kapacity a WAN

NETFW-AFW-BLBWEB-1WEB-2EtherChannel: víc kabelů jako jeden

Pokračujeme v mapě redundance o dvě patra výš. Kapacita linky: co když jedna linka mezi switchi nestačí přenést provoz – nebo chceš, aby výpadek jednoho kabelu nikoho neomezil? Můžeš svázat víc fyzických linek do jedné logické. Tomu se říká EtherChannel (nebo obecně LAG – link aggregation, kurz 6): čtyři kabely se tváří jako jeden tlustý, sečte se jejich rychlost a zároveň to přežije výpadek kterékoli z nich – ostatní jedou dál, jen s menší kapacitou. Dvě mouchy jednou ranou: víc propustnosti i odolnost. Připojení k internetu (WAN): nejcennější SPOF ze všech – když ti spadne jediná linka k poskytovateli, žádná vnitřní redundance ti nepomůže, ven se nedostaneš. Řešením je multi-WAN: mít dvě připojení od dvou poskytovatelů (ideálně i různou technologií – optika a mobilní síť). Za normálu můžeš oběma i rozdělovat provoz; když jedna spadne, failover přesměruje všechno na druhou (tady se ti vrací floating static cesta z kurzu 4 a 10 – záložní cesta s horší metrikou, která se aktivuje, až hlavní zmizí). Zapamatuj si logiku: EtherChannel řeší kapacitu i výpadek uvnitř, multi-WAN řeší výpadek cesty ven. V dalším modulu celou mapu shrneme do jediné tabulky „kde se co použije".

Krok za krokem

  1. EtherChannel/LAG: sváže víc fyzických linek do jedné logické – sečte rychlost a přežije výpadek kterékoli (kurz 6).
  2. Nejcennější SPOF: jediná linka k poskytovateli. Spadne – a žádná vnitřní redundance tě ven nedostane.
  3. Multi-WAN: dvě připojení od dvou poskytovatelů, ideálně různou technologií (optika + mobil).
  4. Když jedna WAN spadne, failover přesměruje vše na druhou – vrací se floating static cesta z kurzů 4 a 10.

Celá mapa: kde se co použije

NETFW-AFW-BLBWEB-1WEB-2každá vrstva má svůj nástroj

Poskládejme mapu redundance na jedno místo – tohle je modul, ke kterému se budeš vracet. Pro každou vrstvu sítě existuje svůj nástroj a klíč je používat ten správný, ne všude cpát to samé. L2 (linky mezi switchi): STP/RSTP proti smyčkám (drží zálohu blokovanou), EtherChannel/LAG pro kapacitu i odolnost (sváže linky). Brána (první skok ven): HSRP/VRRP – dva routery, jedna virtuální IP. Firewall a L3 prvky: HA pár (active/standby nebo active/active) se stavovou synchronizací. Servery a aplikace: load balancer s VIP, poolem a health checkem – škáluje do šířky a sám vyřadí mrtvý backend. Cesta do internetu: multi-WAN se dvěma poskytovateli a failoverem. Vidíš, že napříč vším se opakují dva vzory. První: sdílená identita + tiché převzetí (virtuální IP u HSRP, HA páru i multi-WAN failoveru). Druhý: rozděl zátěž mezi víc kusů (load balancer, EtherChannel, active/active). Odolnost tedy není jedna kouzelná krabička – je to disciplína hledat SPOF vrstvu po vrstvě a na každou nasadit její osvědčený nástroj. A pozor na poslední, nejčastěji opomíjenou vrstvu, kterou žádný protokol nevyřeší: napájení a fyzika. Dva zdroje, dva přívody proudu, záložní baterie (UPS), servery ve dvou různých místnostech či budovách. Nejchytřejší HA pár je k ničemu, když oba kusy visí na jedné zásuvce.

Krok za krokem

  1. Mapa redundance: L2 → STP/LAG, brána → HSRP/VRRP, firewall → HA pár, servery → load balancer, internet → multi-WAN.
  2. Vzor 1: sdílená identita + tiché převzetí – virtuální IP u HSRP, HA páru i multi-WAN failoveru.
  3. Vzor 2: rozděl zátěž mezi víc kusů – load balancer, EtherChannel, active/active pár.
  4. Nejčastěji opomíjená vrstva: napájení a fyzika – dva zdroje, UPS, dvě místnosti. HA pár na jedné zásuvce je k ničemu.

▶ Otevřít v simulátoru

Lekce 5: Návrh odolné sítě

Vrstvi redundanci

NETFW-AFW-BLBWEB-1WEB-2krásný HA pár…

Poslední lekce je o návrhu: jak z jednotlivých nástrojů poskládat síť, která opravdu drží. První a nejdůležitější pravidlo zní: žádná jedna redundance nestačí sama. Můžeš mít nejkrásnější HA pár firewallů – ale když za ním visí jediný server, spadne služba i tak. Můžeš mít deset serverů za load balancerem – ale když je load balancer sám jeden, právě jsi z něj udělal nový SPOF. Odolnost se proto navrhuje ve vrstvách a řetěz je tak silný, jak silný je jeho nejslabší článek. Projdi cestu paketu od začátku do konce a na každém skoku se ptej „a co když tenhle kus umře?": internet (→ multi-WAN), brána (→ HSRP), firewall (→ HA pár), rozdělovač i servery (→ load balancer s poolem, a klidně dva LB v HA – sdílejí virtuální IP stejným trikem jako HSRP nebo HA pár firewallu z lekce 4), a pod tím vším switche a linky (→ STP, LAG) a napájení (→ dva zdroje, UPS). Teprve když má náhradu každý článek řetězu, máš skutečně odolnou síť – a přesně to ti po každém zásahu poví test odolnosti z lekce 1: projede N-1 přes celou topologii a ukáže, jestli ještě někde nezůstal osamělý prvek, jehož výpadek všechno položí. Návrh odolnosti tak není jednorázový akt, ale smyčka: postav vrstvu, otestuj N-1, najdi nejslabší článek, posil ho, testuj znovu.

Krok za krokem

  1. Můžeš mít nejkrásnější HA pár firewallů – dvě zařízení, tiché převzetí, stavová synchronizace.
  2. …ale když za ním visí jediný server, služba spadne stejně. Žádná jedna redundance nestačí sama.
  3. Odolnost se navrhuje ve vrstvách: na každém skoku se ptej „co když tenhle kus umře?". Řetěz je tak silný jak nejslabší článek.
  4. Návrh je smyčka: postav vrstvu, otestuj N-1, najdi nejslabší článek, posil ho, testuj znovu.

Náklady vs přínos

NETFW-AFW-BLBWEB-1WEB-2všeho dvakrát = dvojí cena a složitost

Když je odolnost tak skvělá, proč nezdvojit úplně všechno vždycky? Protože redundance něco stojí – a slepé „všeho dvakrát" je stejná chyba jako žádná redundance, jen dražší. Každý zdvojený prvek znamená dvojnásobný nákup, víc místa, víc spotřeby, a hlavně víc složitosti: víc konfigurace, víc věcí, které se můžou rozbít nebo špatně nastavit. A pozor – složitost sama je riziko: špatně nakonfigurovaný HA pár umí shodit síť způsobem, který by jediné zařízení nikdy nedokázalo (vzpomeň na split-brain). Jak se tedy rozhodnout, kde redundanci chceš a kde je to overkill? Stejným nástrojem jako v OT kurzu: analýzou rizik. Polož si dvě otázky. Jak často to spadne (pravděpodobnost) a co se stane, když to spadne (dopad)? Vysoký dopad → redundance se vyplatí skoro vždy: firemní e-shop, který při hodinovém výpadku přijde o statisíce, chce HA pár, load balancer i multi-WAN. Nízký dopad → stačí prostá záloha nebo vůbec nic: domácí síť přežije, když router jednou za rok na pět minut spadne – kupovat druhý je overkill. A klíčová myšlenka, na kterou se často zapomíná: než sáhneš po drahé redundanci v reálném čase, zvaž levnější zálohy a rychlou obnovu. U mnoha služeb je přijatelné pár minut výpadku a rychlé nahození ze zálohy – a to je zlomek ceny plné HA. Odolnost není soutěž „kdo má víc devítek", ale uvážená volba, kolik té ceny za jakou jistotu jsi ochoten zaplatit.

Krok za krokem

  1. Redundance něco stojí: dvojí nákup, víc místa a spotřeby a hlavně víc složitosti. Slepé „všeho dvakrát" je dražší chyba.
  2. A pozor: složitost je riziko. Špatně nastavený HA pár umí shodit síť hůř než jediné zařízení.
  3. Rozhoduje analýza rizik (pravděpodobnost × dopad). E-shop, kde hodina výpadku stojí statisíce, chce HA i multi-WAN.
  4. Nízký dopad → overkill. Než sáhneš po drahé HA, zvaž levné zálohy a rychlou obnovu – pár minut výpadku často stačí.

Shrnutí: odolnost pohromadě

NETFW-AFW-BLBWEB-1WEB-2najdi SPOF, miř na N-1 (lekce 1)

Kurz končí – poskládejme odolnost a škálování do jednoho obrazu. Najdi slabinu: SPOF je prvek, jehož výpadek shodí celou síť; cíl je N-1 (ustát výpadek jednoho libovolného kusu) a nástroje jsou kontrola topologie a test odolnosti (lekce 1). Zajisti dostupnost: HA pár zdvojí firewall či router – active/standby nebo active/active, s tichým failoverem a stavovou synchronizací, aby převzetí nezahodilo spojení; pozor na split-brain (lekce 2). Škáluj do šířky: load balancer schová fond serverů za jednu VIP, rozděluje zátěž (round-robin, least-conn, weighted, sticky) a health checkem sám vyřadí mrtvý backend – scale-out a odolnost v jednom (lekce 3). Použij správný nástroj na správnou vrstvu: STP a LAG na L2, HSRP/VRRP na bránu, HA pár na firewall, load balancer na servery, multi-WAN na internet – a nezapomeň na napájení (lekce 4). Navrhuj s mírou: žádná redundance nestačí sama, řetěz je tak silný jak nejslabší článek, a kolik té ceny zaplatíš, rozhoduje analýza rizik (lekce 5). Všimni si společné nitky: skoro nic z toho nebyla nová magie – virtuální IP, floating static, STP, stavový firewall znáš z dřívějších kurzů. Odolnost je z velké části způsob myšlení: u každého prvku se ptát „a co když tohle umře?" – a mít připravenou odpověď dřív, než se to stane.

Krok za krokem

  1. Najdi slabinu: SPOF shodí celou síť; cíl je N-1. Nástroje: kontrola topologie a test odolnosti.
  2. Zajisti dostupnost: HA pár zdvojí firewall/router s failoverem a stavovou synchronizací – pozor na split-brain.
  3. Škáluj do šířky: load balancer schová pool za VIP, rozdělí zátěž a health checkem vyřadí mrtvý backend.
  4. Správný nástroj na vrstvu (STP, HSRP, HA, LB, multi-WAN) a návrh s mírou podle analýzy rizik. Gratuluju – teď to zkus v simulátoru!

▶ Otevřít v simulátoru