Failover-testi: selviääkö muodostettu TCP-virta?

Kaksi tulosta piilee lauseessa, että vara toimii. Uusi pyyntö onnistuu, se on palautuminen. Jo käynnissä oleva siirto jatkuu, se on jatkuvuus. Ne ovat eri lupauksia, ja useimmat failover-ratkaisut tuottavat ensimmäisen, kun taas toinen päättyy hiljaa aikakatkaisuun. Päätä, kumman tarvitset, ennen kuin valitset mekanismin, ja kirjoita testi niin, että se pystyy erottamaan ne.

Kaksi tulosta, jotka näyttävät yhdeltä onnistumiselta

Kuvittele asiakas osoitteessa 10.90.0.42, jolla on yhteys osoitteeseen 198.51.100.20:443. Ensisijainen lähtö muuntaa sen yhdeksi julkiseksi osoitteeksi ja portiksi, ja varalähtö toiseksi. Asiakkaan sisäinen osoite ei koskaan muutu, ja siksi ihmiset odottavat yhteyden säilyvän.

Palvelin ei näe sisäistä osoitetta. Se näkee muunnetun päätepisteen, ja tämä päätepiste on vaihdon jälkeen erilainen.

Niin vanha virta päättyy aikakatkaisuun, kun taas uusi yhteys samaan palveluun toimii heti. Molemmat havainnot pitävät yhtä aikaa paikkansa.

Mitä palvelin näkee, kun lähtö vaihtuu

TCP-yhteys tunnistetaan nelikollaan, ja lähdeosoitteen tai -portin muutos luo vastaanottavan isännän kannalta toisen yhteyden. Paketit, jotka saapuvat uudesta lähteestä yhteydellä, jota palvelin ei tunne, hylätään tai niihin vastataan nollauksella. Mikään VPN-asiakkaan osoitteessa ei säilytä liitosta tämän muutoksen yli.

Tilallinen failover on olemassa juuri tämän välttämiseksi, ja se toimii vaihtamalla muunnos- ja yhteystilaa välityslaitteiden välillä. Se on parin ominaisuus, ei tunnelin, ja se on suunniteltava ja testattava eikä oletettava.

Tarkista, pitääkö pari todella tilaa, ennen kuin lupaat kenellekään jatkuvuutta. Alla olevat komennot näyttävät nykyisen tilan molemmilla puolilla.

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

Miksi sama julkinen osoite ei riitä

Yhden julkisen osoitteen pitäminen molemmilla poluilla on hyvä alku, koska silloin palvelin näkee saman lähdepäätepisteen. Sellaisenaan se ei kuitenkaan riitä. Välityslaite tarvitsee edelleen muunnostilan, palomuurin tilan ja käyttökelpoisen paluupolun, ja näiden on oltava siinä laitteessa, joka kantaa liikennettä vaihdon jälkeen.

RFC 3022 kuvaa osoitemuunnoksen ja käsittelee tilanvaihtoa muunnosta tekevien laitteiden välillä osana varasuunnitelmaa. Kelluva osoite tai kopioitu profiili siirtää kokoonpanon siirtämättä tilaa.

Siksi testi, joka vain pingaa varayhteyden kautta, todistaa hyvin vähän. Pingillä ei ole yhteyden tilaa, jonka voisi menettää.

Päätä, kuinka vahva vaatimus on

Jos käyttäjät voivat yhdistää uudelleen vian jälkeen, ratkaisu on palautumisratkaisu ja hyväksymistesti on uusi pyyntö. Jos tiedostonsiirron on selvittävä, ratkaisu tarvitsee tilan synkronoinnin ja paljon huolellisemman testin. Jos etäistunnon on selvittävä, vaatimus on taas vahvempi ja voi tarvita sovellustason mekanismin verkkotason sijaan.

Kirjoita vaatimus lauseena, jolla on mitattava tulos, esimerkiksi lataus valmistuu ilman uudelleenkäynnistystä tai operaattori yhdistää uudelleen minuutissa. Valitse sitten halvin mekanismi, joka täyttää sen, ja usein se on palautumisratkaisu.

Sano selvästi, mitä tapahtuu, kun ensisijainen palaa, koska automaattinen paluu voi katkaista yhteyden, joka oli juuri palautunut varalle. Tämä tapaus kuuluu testisuunnitelmaan, ei alaviitteeseen.

Tarkista vanha virta ja uusi pyyntö

Käynnistä vaaraton pitkäkestoinen siirto ensisijaisen kautta ja sitten erillinen uusi pyyntö samaan palveluun. Kirjaa sovelluksen konteksti, havaittu lähtöosoite ja aika. Katkaise ensisijainen hyväksytyllä tavalla ja seuraa alkuperäistä siirtoa samalla, kun lähetät uuden pyynnön varan kautta.

Raportoi kolme arvoa: jatkuiko vanha virta, nollautuiko se vai päättyikö aikakatkaisuun; milloin uusi toiminto toimi ensimmäisen kerran; ja keskeyttikö paluu jotain. Ne kolme riviä ovat hyväksymiskirjaus.

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

Jos työkuorma kirjoittaa dataa, älä toista epävarmaa toimintoa sokkona aikakatkaisun jälkeen. Kirjoitus on voinut saapua ennen kuin vastaus katosi. Kysy sovellukselta tulos tai yritä uudelleen vain siellä, missä toiminto on idempotentti. Kirjoita sitten hyväksymislause kolmessa osassa: uudet toiminnot palautuvat lähtöpolitiikan mukaisesti, olemassa olevilla virroilla on dokumentoitu keskeytymiskäyttäytyminen ja sovellus jatkuu turvallisesti. Tämä lause on testattava, ja se on rehellinen siitä, mitä ratkaisu ei lupaa.