Test přepnutí: přežije zavedený TCP proud?
Záložní výstup může přijmout každé nové spojení a přesto přerušit přenos, který už běží. Otestujte oba výsledky a případ zpětného přepnutí ponechte v plánu.
Dva výsledky se skrývají ve větě, že záloha funguje. Nový požadavek uspěje, to je obnova. Přenos, který už běží, pokračuje, to je kontinuita. To jsou různé sliby a většina návrhů přepnutí doručí první, zatímco druhý tiše vyprší. Rozhodněte, který potřebujete, dřív než vyberete mechanismus, a napište test tak, aby je dokázal rozlišit.
Dva výsledky, které vypadají jako jeden úspěch
Představte si klienta na 10.90.0.42 se spojením na 198.51.100.20:443. Primární výstup to přeloží na jednu veřejnou adresu a port, záložní výstup na jinou. Vnitřní adresa klienta se nikdy nemění, a proto lidé očekávají, že spojení přežije.
Server nevidí vnitřní adresu. Vidí přeložený koncový bod a ten je po přepnutí jiný.
Starý proud tedy vyprší, zatímco nové spojení ke stejné službě funguje okamžitě. Obě pozorování platí zároveň.
Co server vidí, když se výstup změní
TCP spojení se identifikuje svou čtveřicí, a změna zdrojové adresy nebo portu vytváří z pohledu přijímajícího hostitele jiné spojení. Pakety, které dorazí z nového zdroje po spojení, jež server nezná, se zahodí nebo se na ně odpoví resetem. Nic v adrese VPN klienta nezachová asociaci napříč touto změnou.
Přepnutí se stavem existuje právě proto, aby se tomu vyhnulo, a funguje výměnou překladu a stavu spojení mezi předávacími zařízeními. To je vlastnost dvojice, ne tunelu, a musí se navrhnout a otestovat, ne předpokládat.
Ověřte, zda dvojice stav skutečně drží, než někomu slíbíte kontinuitu. Níže uvedené příkazy ukazují aktuální stav na obou stranách.
conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10Proč stejná veřejná adresa nestačí
Zachovat jednu veřejnou adresu na obou cestách je dobrý začátek, protože server pak vidí stejný zdrojový koncový bod. Samo o sobě to ale nestačí. Předávací zařízení stále potřebuje stav překladu, stav firewallu a použitelnou zpáteční cestu, a to musí existovat na tom zařízení, které po přepnutí nese provoz.
RFC 3022 popisuje překlad adres a výměnu stavu mezi překládajícími zařízeními považuje za součást záložního návrhu. Plovoucí adresa nebo zkopírovaný profil přesouvá konfiguraci, ale nepřesouvá stav.
Proto test, který jen pinguje přes zálohu, dokazuje velmi málo. Ping nemá žádný stav spojení, který by mohl ztratit.
Rozhodněte, jak silný požadavek je
Pokud se uživatelé po výpadku mohou znovu připojit, je návrh návrhem obnovy a akceptační test je nový požadavek. Pokud musí přežít přenos souboru, návrh potřebuje synchronizaci stavu a mnohem pečlivější test. Pokud musí přežít vzdálená relace, je požadavek znovu silnější a může vyžadovat mechanismus na úrovni aplikace místo na úrovni sítě.
Napište požadavek jako větu s měřitelným výsledkem, například nahrávání se dokončí bez restartu nebo operátor se znovu připojí do minuty. Pak vyberte nejlevnější mechanismus, který jej splňuje, a to je často návrh obnovy.
Výslovně řekněte, co se stane, když se primární vrátí, protože automatické přepnutí zpět může přerušit spojení, které se právě zotavilo na záloze. Ten případ patří do testovacího plánu, ne do poznámky pod čarou.
Zkontrolujte starý proud a nový požadavek
Spusťte neškodný dlouhý přenos přes primární, pak samostatný nový požadavek na stejnou službu. Zaznamenejte kontext aplikace, pozorovanou výstupní adresu a čas. Přerušte primární schváleným způsobem a dál sledujte původní přenos, zatímco posíláte nový požadavek přes zálohu.
Uveďte tři hodnoty: zda starý proud pokračoval, resetoval se nebo vypršel; kdy nová operace poprvé fungovala; a zda zpětné přepnutí něco přerušilo. Tyto tři řádky jsou akceptační záznam.
ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20Pokud pracovní zátěž zapisuje data, neopakujte nejistou operaci po vypršení naslepo. Zápis mohl dorazit dřív, než se odpověď ztratila. Zeptejte se aplikace na výsledek, nebo opakujte jen tam, kde je operace idempotentní. Pak napište akceptační tvrzení ve třech částech: nové operace se obnovují podle politiky výstupu, stávající proudy mají dokumentované chování při přerušení a aplikace bezpečně pokračuje. To tvrzení je testovatelné a je poctivé ohledně toho, co návrh neslibuje.