Failover-teszt: túléli egy létrejött TCP-folyam?

Két eredmény rejtőzik abban a mondatban, hogy a tartalék működik. Egy új kérés sikerül, ez a helyreállás. Egy már futó átvitel folytatódik, ez a folytonosság. Ezek különböző ígéretek, és a legtöbb failover-terv az elsőt teljesíti, miközben a második csendben lejár. Döntse el, melyikre van szüksége, mielőtt mechanizmust választ, és úgy írja meg a tesztet, hogy meg tudja különböztetni őket.

Két eredmény, amely egyetlen sikernek látszik

Képzeljen el egy klienst a 10.90.0.42 címen, amely a 198.51.100.20:443 címhez kapcsolódik. Az elsődleges kijárat ezt egy nyilvános címre és portra fordítja, a tartalék kijárat pedig egy másikra. A kliens belső címe soha nem változik, ezért az emberek azt várják, hogy a kapcsolat túléli.

A kiszolgáló nem lát belső címet. A lefordított végpontot látja, és ez a végpont a váltás után más.

Így a régi folyam lejár, miközben az ugyanahhoz a szolgáltatáshoz indított új kapcsolat azonnal működik. Mindkét megfigyelés egyszerre igaz.

Mit lát a kiszolgáló, amikor a kijárat megváltozik

Egy TCP-kapcsolatot a négyese azonosít, és a forráscím vagy -port megváltoztatása a fogadó gazdagép szempontjából más kapcsolatot hoz létre. Azok a csomagok, amelyek új forrásból érkeznek egy olyan kapcsolaton, amelyet a kiszolgáló nem ismer, eldobódnak, vagy visszaállítással válaszolnak rájuk. A VPN-kliens címében semmi nem őrzi meg a társítást e változás során.

Az állapotot átadó failover pontosan ennek elkerülésére létezik, és a továbbító eszközök között cseréli ki a fordítási és kapcsolati állapotot. Ez a pár tulajdonsága, nem az alagúté, és meg kell tervezni és tesztelni kell, nem feltételezni.

Ellenőrizze, hogy a pár valóban tart-e állapotot, mielőtt bárkinek folytonosságot ígér. Az alábbi parancsok a jelenlegi állapotot mutatják mindkét oldalon.

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 10

Miért nem elég ugyanaz a nyilvános cím

Egy nyilvános cím megtartása mindkét útvonalon jó kezdet, mert akkor a kiszolgáló ugyanazt a forrásvégpontot látja. Önmagában azonban nem elég. A továbbító eszköznek továbbra is kell a fordítási állapot, a tűzfal állapota és egy használható visszaút, és ezeknek azon az eszközön kell létezniük, amely a váltás után a forgalmat viszi.

Az RFC 3022 leírja a címfordítást, és a fordító eszközök közötti állapotcserét a tartalék terv részének tekinti. A lebegő cím vagy a másolt profil a konfigurációt mozgatja, az állapotot nem.

Ezért a csak a tartalékon át pingelő teszt nagyon keveset bizonyít. A pingnek nincs elveszíthető kapcsolati állapota.

Döntse el, milyen erős a követelmény

Ha a felhasználók hiba után újra tudnak kapcsolódni, a terv helyreállítási terv, és az átvételi teszt egy új kérés. Ha egy fájlátvitelnek túl kell élnie, a tervnek állapotszinkronizálásra és sokkal körültekintőbb tesztre van szüksége. Ha egy távoli munkamenetnek túl kell élnie, a követelmény még erősebb, és lehet, hogy alkalmazásszintű mechanizmusra van szükség hálózati helyett.

Írja le a követelményt mérhető eredményű mondatként, például hogy a feltöltés újraindítás nélkül befejeződik, vagy hogy az üzemeltető egy percen belül újra kapcsolódik. Ezután válassza a legolcsóbb mechanizmust, amely kielégíti, és ez gyakran a helyreállítási terv.

Mondja ki egyértelműen, mi történik, amikor az elsődleges visszatér, mert az automatikus visszaváltás megszakíthat egy kapcsolatot, amely éppen helyreállt a tartalékon. Ez az eset a teszttervbe tartozik, nem lábjegyzetbe.

Ellenőrizze a régi folyamot és az új kérést

Indítson ártalmatlan, hosszú átvitelt az elsődlegesen át, majd egy külön új kérést ugyanahhoz a szolgáltatáshoz. Jegyezze fel az alkalmazáskörnyezetet, a megfigyelt kimeneti címet és az időt. Szakítsa meg az elsődlegest jóváhagyott módon, és figyelje tovább az eredeti átvitelt, miközben az új kérést a tartalékon át küldi.

Adjon meg három értéket: folytatódott-e a régi folyam, visszaállt-e vagy lejárt; mikor működött először az új művelet; és megszakított-e valamit a visszaváltás. Az a három sor az átvételi jegyzőkönyv.

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 20

Ha a munkaterhelés adatot ír, ne ismételje meg vakon egy bizonytalan műveletet időtúllépés után. Lehet, hogy az írás megérkezett, mielőtt a válasz elveszett. Kérdezze meg az alkalmazástól az eredményt, vagy csak ott próbálkozzon újra, ahol a művelet idempotens. Ezután írja meg az átvételi nyilatkozatot három részben: az új műveletek a kimeneti szabályzat szerint állnak helyre, a meglévő folyamoknak dokumentált megszakítási viselkedésük van, és az alkalmazás biztonságosan folytatódik. Ez a nyilatkozat tesztelhető, és őszinte arról, amit a terv nem ígér.