Kio postvivas VIP-failover de prokurilo?
Apartigu la restaŭron de la prokurila enirejo disde la postvivo de establitaj CONNECT-tuneloj kaj la elira adreso al la retejo.
Flosanta adreso tenas la prokurilan agordon stabila: klientoj daŭre uzas la saman gastigantnomon aŭ IP post kiam la aktiva maŝino fiaskas. Tio estas utila havebleco. Tamen elŝuto jam komencita povas tamen halti.
Konsideru HTTPS-peton jam ene de CONNECT. La aktiva prokurilo posedas la klientan TCP-ligon kaj alian ligon al la retejo. Ĝi ankaŭ posedas la aplikaĵstato, kiu kunigas tiujn fluojn.
Movi adreson al rezerva maŝino mem ne movas nek la TCP-regblokon nek tiun plusendostaton. La nova posedanto povas akcepti novajn ligojn sen povi daŭrigi bajtan fluon establitajn de la malnova posedanto.
| Atendo | Ĉu ordinara adresfailover provizas tion? |
|---|---|
| Konservi unu agorditan enirejon | Tio estas la celita avantaĝo |
| Daŭrigi establitajn CONNECT-fluon | Bezus plian kunstaton konservantan mekanismon |
| Konservi la saman eliran publikan IP | Dependas de elira enkursigado kaj NAT |
| Repeti interrompitan aplikaĵoperacion sekure | Dependas de la operacio kaj de la kliento |
VRRP difinas elekton kaj adresposedon. Ĝi ne estas replika protokolo por la prokurila procezo. Disfaldo uzanta alian altdisponeblan programaron bezonas la saman distingon, krom se ĝi eksplicite provizas pli.
Rigardu, kion la sanokontrolo vere observas. Maŝino povas respondi anoncojn dum ĝia prokurila servo, DNS aŭ supra vojo fiaskis. Inverse, tro sentemaj kontroloj povas kaŭzi senbezonajn ŝaltadojn.
Ankaŭ klienta restariĝo gravas. Nova retumila peto povas facile religiĝi; alŝuto kun konsumita korpo aŭ ne-idempotenta API-operacio eble postulas aplikaĵ-specifan traktadon. Ne promesu nevideblan failover nur ĉar nova peto sukcesas tra la rezervo.