Reverzní proxy - jaké používáte checky?

[czechsys]

Ahoj,

resim tu moznou zmenu zpusobu kontroly funkcniho weboveho backendu. Pokud nekdo zna zajimavy blog/clanek ohledne komplexnejsiho reseni, sem s tim. Momentalne pouzivam http check proti konkretni url. Z hediska risk managementu to neni uplne optimalni (ve smyslu rozdil mezi pingem, dostupnosti portu X, dostupnosti url, a hloubeji), tak padl dotaz tohoto typu:

Je mozne nastavit, aby v pripade, ze check backendu bude ve stavu FAIL a toto se stane na vice backendech, aby alespon jeden backend zustal pripojeny na proxy bez ohledu na to, zda je check OK ci FAIL? Tzn, aby proxy nevyradila veskere backendy z dane skupiny.

Umi to pripadne nejaky balancer? U haproxy jsem zatim na takovou moznost nenarazil.

Diky.

[Reklama]

[schrapnel]

Na čo chceš posielať traffic z vonku na FAIL backend?
Fuknčne som to riešil s vývojármi tak, že mi vytvorili na app endpoint. Napr. web.app.cz/check ktorý vracal HTTP 200 ak všetky interné checky prebehli OK. Ak nastal nejaký problém na backende, tak sa vrátil nejaký špecfický non200 kód (spravidla http 500 family).
V haproxi si vieš nastaviť aby špecifické IP (napr. RFC1918) smerovalo na backend bez balancovania a tým obchádzalo checky.

[Filip Jirsák]

Je mozne nastavit, aby v pripade, ze check backendu bude ve stavu FAIL a toto se stane na vice backendech, aby alespon jeden backend zustal pripojeny na proxy bez ohledu na to, zda je check OK ci FAIL? Tzn, aby proxy nevyradila veskere backendy z dane skupiny.

Vy rovnou navrhujete řešení. Lepší by bylo napsat, jaký problém řešíte. Možná je dobré řešení úplně jiné než to, co navrhujete. Např. nginx má pro servery příznak backup, kterým můžete označit záložní servery, které se použijí v případě, kdy není žádný z primárních serverů dostupný. Což se používá pro servírování ochuzených stránek nebo lepších chybových stránek v případě, kdy celý backend selže. Možná je to řešení vašeho problému.

[czechsys]

Je mozne nastavit, aby v pripade, ze check backendu bude ve stavu FAIL a toto se stane na vice backendech, aby alespon jeden backend zustal pripojeny na proxy bez ohledu na to, zda je check OK ci FAIL? Tzn, aby proxy nevyradila veskere backendy z dane skupiny.

Vy rovnou navrhujete řešení. Lepší by bylo napsat, jaký problém řešíte. Možná je dobré řešení úplně jiné než to, co navrhujete. Např. nginx má pro servery příznak backup, kterým můžete označit záložní servery, které se použijí v případě, kdy není žádný z primárních serverů dostupný. Což se používá pro servírování ochuzených stránek nebo lepších chybových stránek v případě, kdy celý backend selže. Možná je to řešení vašeho problému.

Problem je snad jasny ne? Jednoducha demonstrace pomoci pingu:
1] kazdy backend v danem poolu je kontrolovan pingem
2] z nejakeho duvodu prestane ping fungovat (napr. nedomyslena uprava na FW)
3] kontroly na proxy selzou pro vsechny backendy -> odpojeni vsech backendu

Ale pritom aplikace je funkcni.

Backup parametr mi nepripada jako rozumne reseni takoveho problemu.

[czechsys]

Na čo chceš posielať traffic z vonku na FAIL backend?
Fuknčne som to riešil s vývojármi tak, že mi vytvorili na app endpoint. Napr. web.app.cz/check ktorý vracal HTTP 200 ak všetky interné checky prebehli OK. Ak nastal nejaký problém na backende, tak sa vrátil nejaký špecfický non200 kód (spravidla http 500 family).
V haproxi si vieš nastaviť aby špecifické IP (napr. RFC1918) smerovalo na backend bez balancovania a tým obchádzalo checky.

Eliminace problemu s chybovym checkem. Lepsi posilat traffic na FAIL backend v pripade, ze vsechny jsou ve stavu FAIL, nez neposilat nic.

[Reklama]

[schrapnel]

Tu si dovolím tvrdiť, že máte veľmi zlý prístup. Ak je niečo FAIL, tak je to FAIL. Neexistuje "napoly fail alebo akože fail". Ošetrite si checky tak aby reprezentovali realitu. Na čo budem posielať zákazníka na Internal Server Error?

[Filip Jirsák]

Problem je snad jasny ne? Jednoducha demonstrace pomoci pingu:
1] kazdy backend v danem poolu je kontrolovan pingem
2] z nejakeho duvodu prestane ping fungovat (napr. nedomyslena uprava na FW)
3] kontroly na proxy selzou pro vsechny backendy -> odpojeni vsech backendu

Ale pritom aplikace je funkcni.

Backup parametr mi nepripada jako rozumne reseni takoveho problemu.

Problém
Teď už je problém jasný. Rozumné řešení je oprava kontroly nebo backendu tak, aby kontrola neselhávala, když je backend funkční. Pokud z nějakého důvodu nechcete/nemůžete použít rozumné řešení, je podle mne backup přesně to, co hledáte – jeden nebo více backendů zduplikujete v konfiguraci jako backup, a když všechny primární servery budou označené jako nefunkční, začne nginx posílat požadavky na backup (což budou shodou okolností ty samé backend servery). Řešení je to sice zvláštní, ale nevidím důvod, proč by nemělo fungovat (v rámci limitů toho, že nechcete rozumné řešení).

Jinak v případě (falešného) výpadku všech primárních backendů směrovat veškerý provoz na jediný backend mi nepřipadá jako dobrý nápad. Pokud tam ten load balancer nemáte jen tak pro legraci, ten jediný backend zátěž neustojí a odpadne nebo bude odpovídat velmi pomalu (čímž se teda konečně srovná stav hlášený kontrolou se skutečným stavem).

[Ondrej Nemecek]

Vidím to také tak, že problém je v kontrole, která selže i pokud backend funguje. Musíte odlišit a specifikovat funkčnost jednotlivých komponent a výpadky jednotlivých komponent řešit adekvátním způsobem (pro jednotlivé vrstvy se bude lišit) - a to tak, aby infrastruktura jako celek fungovala.

Co přesně je ta kontrola pingem? Myslíte ICMP ping nebo aplikační ping ve smysli heartbeat nebo - ?

[czechsys]

Tu si dovolím tvrdiť, že máte veľmi zlý prístup. Ak je niečo FAIL, tak je to FAIL. Neexistuje "napoly fail alebo akože fail". Ošetrite si checky tak aby reprezentovali realitu. Na čo budem posielať zákazníka na Internal Server Error?

Jenze FAIL je na strane checku, ne na strane backendu. Takze by zakaznik videl aplikaci, ne Internal Server Error.

[czechsys]

Problem je snad jasny ne? Jednoducha demonstrace pomoci pingu:
1] kazdy backend v danem poolu je kontrolovan pingem
2] z nejakeho duvodu prestane ping fungovat (napr. nedomyslena uprava na FW)
3] kontroly na proxy selzou pro vsechny backendy -> odpojeni vsech backendu

Ale pritom aplikace je funkcni.

Backup parametr mi nepripada jako rozumne reseni takoveho problemu.

Problém
Teď už je problém jasný. Rozumné řešení je oprava kontroly nebo backendu tak, aby kontrola neselhávala, když je backend funkční. Pokud z nějakého důvodu nechcete/nemůžete použít rozumné řešení, je podle mne backup přesně to, co hledáte – jeden nebo více backendů zduplikujete v konfiguraci jako backup, a když všechny primární servery budou označené jako nefunkční, začne nginx posílat požadavky na backup (což budou shodou okolností ty samé backend servery). Řešení je to sice zvláštní, ale nevidím důvod, proč by nemělo fungovat (v rámci limitů toho, že nechcete rozumné řešení).

Jinak v případě (falešného) výpadku všech primárních backendů směrovat veškerý provoz na jediný backend mi nepřipadá jako dobrý nápad. Pokud tam ten load balancer nemáte jen tak pro legraci, ten jediný backend zátěž neustojí a odpadne nebo bude odpovídat velmi pomalu (čímž se teda konečně srovná stav hlášený kontrolou se skutečným stavem).

Problem parametru backup je ten, ze (napr. v pripade haproxy) ten backend "backup" je monitorovany (a tim se propaguje to monitoringu, fw apod). Ale jako jo, provozni naklady jsou proti nakladum na vypadek defacto nulove.

[czechsys]

Vidím to také tak, že problém je v kontrole, která selže i pokud backend funguje. Musíte odlišit a specifikovat funkčnost jednotlivých komponent a výpadky jednotlivých komponent řešit adekvátním způsobem (pro jednotlivé vrstvy se bude lišit) - a to tak, aby infrastruktura jako celek fungovala.

Co přesně je ta kontrola pingem? Myslíte ICMP ping nebo aplikační ping ve smysli heartbeat nebo - ?

Haproxy umi definovat jeden check pro pool. Takze pokud ten check selze (at uz je na cilove strane pouze nejaka status stranka, ci komplexni skript na vyhodnoceni stavu), tak pak staci dany soubor zmenit/odstranit a veskere backendy toho poolu leti dolu.

Z toho duvodu zvazujeme, zda nezkusit cestu pres monitorovani primo HTTP statusu z dotazu, ale trochu se obavam, ze odpojovani backendu tam bude castejsi (a z toho vznikl dotaz, zda lze zajistit, aby aspon jeden backend byl vzdy pripojen).

[Filip Jirsák]

Problem parametru backup je ten, ze (napr. v pripade haproxy) ten backend "backup" je monitorovany (a tim se propaguje to monitoringu, fw apod). Ale jako jo, provozni naklady jsou proti nakladum na vypadek defacto nulove.

Nerozumím, v čem je problém. Když všechny servery vypadnou z primáru, budete je mít stejně v monitoringu – proč vadí, když tam budou ještě jednou v backupu?

Z toho duvodu zvazujeme, zda nezkusit cestu pres monitorovani primo HTTP statusu z dotazu, ale trochu se obavam, ze odpojovani backendu tam bude castejsi (a z toho vznikl dotaz, zda lze zajistit, aby aspon jeden backend byl vzdy pripojen).

Backend by měl mít skript, který ověří to, co je pro aplikaci životně nutné (např. že se dokáže připojit do databáze a provést tam triviální dotaz) a podle toho vracet stavový kód. Na ten stavový kód by se pak měla chytat reverzní proxy. Pak není důvod, proč by backend vypadával z poolu, i když je v pořádku.