ADC, ADN, Failover IPs, HA ako to riesia velke firmy?

[Manorak]

Zdravim,
povedzme, ze mam svoje API na api.mojafirma.com pristupne pre klientov. Ako zabezpecim, aby bola tato adresa stale dostupna z pohladu frontend serverov?

Aktualny hostname api.mojafirma.com smeruje na failover IP, ktoru mam z datoveho centra v Hetzneri (www.hetzner.de) a 2x frontend servery, ktore funguju v rezime active/pasive. Teda vsetok traffic ide cez jeden frontend a v pripade jeho vypadku mi keepalived spusti request na Hetzner API, ktore do minuty (tolko trva kym sa zmena rozdistribuje po ich sieti) a traffic zacne tiect cez druhy frontend server. Problem je ta minuta, ktoru to trva, lebo ja potrebujem mat pre klientov moje api.mojafirma.com dostupne stale. Tiez v buducnosti by som chcel mat moznost load balancovat medzi tymi dvomi pripadne viacerymi (scale out) frontend servermi. Viem, ze si na to mozem kupit hardware load balancer respektive Application Delivery Controller (ADC), ale co ak mi odide toto zariadenie? To si mam kupit 2x ADC a nejako to prepojit alebo co mi odporucate? Ako to riesia velke firmy ako Google, Facebook atd?

Za kazdu radu, clanok, technologiu na ktoru ma odkazete vopred vdaka.

[Reklama]

[odpovedateľ]

Skús pohľadať niečo ako Corosync, Pacemaker a Floating IPs

[Miroslav Šilhavý]

Vámi popsaná rizika nejde eliminovat, pouze mitigovat. Aplikace musí být připravena na X sekund trvající flap a na spolupráci s mechanismy, který ho zajišťují. Jednotlivými kroky pak můžete a) umenšovat riziko, že k výpadku dojde, b) zkracovat dobu, za kterou dojde k recovery. Někdy jsou kroky dokonce i protichůdné - např. balancování / failover přes DNS vyžaduje snižování TTL. Ale snižování TTL zase zvyšuje tlak na autoritativní DNS a rizika spojená s výpadkem DNS samotného. Unverzální řešení není, můžete pouze podle zkušenosti rizika přelévat tam, kde je považujete za nejnižší.

[_Tomáš_]

pokud máš klienty pod kontrolou, můžeš udělat api1., api2., api3... endpointy a klient si je bude postupně zkoušet dokud si s ním někdo nebude povídat. Dá se to zajistit běžnými prostředky na běžných hostinzích a je možné i vybírat nejbližší server aniž bych musel řešit BGP.

Pak je otázka co to api dělá a jak nejlépe vyřešit CAP problém.

[EHP]

Hetzner neznam, ale v google cloudu bych vytvoril instance group z nekolika api serveru a pred ne dal googli loadbalancer. Kdyz se nastavi dobre healthcheck tak jednotliva spojeni pri vypadku spadnou, ale jako celek to bude dostupne stale.

[Reklama]

[Trupik]

Hetzner neznam, ale v google cloudu bych vytvoril instance group z nekolika api serveru a pred ne dal googli loadbalancer. Kdyz se nastavi dobre healthcheck tak jednotliva spojeni pri vypadku spadnou, ale jako celek to bude dostupne stale.

jj, v googli je to v bezpečí, ten nikdy nevypadne... https://www.lupa.cz/aktuality/uzijte-si-klidny-vecer-google-nejede-a-zadna-z-jeho-sluzeb-take-ne/

[drunkez]

Nuz u nas je to presne tak...ha loadbalancery , ha reverzne proxy, plavajuce ipky...failovery su max jednotky sekund....na backende to iste...block storidze su continous access vsetky....naska active\active.....vsetko je to drahe jak svin a tlaci to na vykon celej infra..ale inak sa neda....vypadky su minimalizovane na max

[David]

Já používám loadbalancer v Azure, který si zkouší dostupnost služby v pravidelném intervalu a podle toho požadavky posílá střídavě na jeden a na druhý server.

[Manorak]

Nuz u nas je to presne tak...ha loadbalancery , ha reverzne proxy, plavajuce ipky...failovery su max jednotky sekund....na backende to iste...block storidze su continous access vsetky....naska active\active.....vsetko je to drahe jak svin a tlaci to na vykon celej infra..ale inak sa neda....vypadky su minimalizovane na max

Vdaka ze odpoved. Takze ak by som to chcel riesit tak ako u vas tak api.mojafirma.com by smerovala na nejaku floating IP, ktora je na nejakom loadbalanceri, spravne? Predpokladam, ze HA loadbalancer znamena, ze ak ten loadbalancer vyhori tak tam mate dalsi co jeho funkcionalitu zastupi, teda active/pasive? Alebo ako mate respektive ako je podla teba najlepsi sposob ako technicky zvladnut prave tuto cast?

[Manorak]

Vámi popsaná rizika nejde eliminovat, pouze mitigovat. Aplikace musí být připravena na X sekund trvající flap a na spolupráci s mechanismy, který ho zajišťují. Jednotlivými kroky pak můžete a) umenšovat riziko, že k výpadku dojde, b) zkracovat dobu, za kterou dojde k recovery. Někdy jsou kroky dokonce i protichůdné - např. balancování / failover přes DNS vyžaduje snižování TTL. Ale snižování TTL zase zvyšuje tlak na autoritativní DNS a rizika spojená s výpadkem DNS samotného. Unverzální řešení není, můžete pouze podle zkušenosti rizika přelévat tam, kde je považujete za nejnižší.

Vdaka za odpoved. Prave kvoli tomu co popisujete to cez DNS riesit nechcem/nemozem, ale rozumiem ako priklad je to dobre. Prajem prijemny den.

[Manorak]

pokud máš klienty pod kontrolou, můžeš udělat api1., api2., api3... endpointy a klient si je bude postupně zkoušet dokud si s ním někdo nebude povídat. Dá se to zajistit běžnými prostředky na běžných hostinzích a je možné i vybírat nejbližší server aniž bych musel řešit BGP.

Pak je otázka co to api dělá a jak nejlépe vyřešit CAP problém.

Dakujem za odpoved. Nie je to uplne idealne riesenie, ale v ramci nejakeho zalozneho planu by mohlo byt nejake backup-api. Nerozumiem ale ako sa da "beznymi prostriedkami" vyberat najblizsie server bez toho aby som musel riesit BGP? Ma ta technologia nejaky nazov, ktory si mozem vygooglit?

[j]

... vyberat najblizsie server ...

Zacit muzes u sluvka latence - vyberes ten, kterej ji ma nejnizsi. V sitovani se totiz neresi vzdalenost v km, ale v ms.

A jak uz bylo receno, pokud chces resit bezvypadkovy provoz, tak to jednak musi umet tvoje aplikace, druhak na to musi byt pripravena cela infrastruktura (10 serveru v cmoudu je ti naprd, kdyz ti padne internet) a neni to vubec levny. Navic to sebou nese sousty problemu ktery souvisej s vecma, ktery se ti pri beznym provozu nedejou - vznik vsemoznych smycek, oscilace ...

Naprosto nejhorsi o co se muzes pokouset, je zajistit HA pro aplikaci, ktera to neumi. Protoze ac ti bude kazdej jeden dodavatel letacku s vysmatejma rodinkama tvrdit, ze jejich reseni je pro aplikaci transparentni, pravda to neni naprosto nikdy.

[MP]

pokud máš klienty pod kontrolou, můžeš udělat api1., api2., api3... endpointy a klient si je bude postupně zkoušet dokud si s ním někdo nebude povídat. Dá se to zajistit běžnými prostředky na běžných hostinzích a je možné i vybírat nejbližší server aniž bych musel řešit BGP.

Pak je otázka co to api dělá a jak nejlépe vyřešit CAP problém.

Dakujem za odpoved. Nie je to uplne idealne riesenie, ale v ramci nejakeho zalozneho planu by mohlo byt nejake backup-api. Nerozumiem ale ako sa da "beznymi prostriedkami" vyberat najblizsie server bez toho aby som musel riesit BGP? Ma ta technologia nejaky nazov, ktory si mozem vygooglit?

Napr. anycast