Super HA dla HTTP?

[Kszysiu 136]

Cześć

W sumie kiedyś już o tym chciałem napisać, ale albo się nie kliknęło "dodaj nowy temat" albo w sumie nie wiem jak to się stało że temat się nie pojawił...

Zastanawiam się jakie są drogi do uzyskania (w ogóle się da) 100% uptime dla usług WWW... Chodzi mi o rozwiązanie oparte na wielu serwerach w różnych serwerowniach.

Chciałbym pominąć kwestię tego "co z tyłu" (chodzi mi o synchronizację danych itp, bo każdy ma na to swój sposób).

Chodzi mi o to jak "pokazać to światu".

Powiedzmy że mam link pliki.pl/nagie_fotki_kszysia.zip i czy da się zbudować takie środowisko, aby plik pod tym linkiem był zawsze dostępny.

Pierwsze co przychodzi na myśl to Round rubin DNS - no ale to ma taką wadę, że jeśli padnie jeden z serwerów to zawsze jakaś część klientów się nie dobije do moich fotek (w ogóle ktoś by próbował? ).. Niby można zrobić takich serwerów np. 10 i jak padnie jeden to niedostępność dla 10% osób to nie dużo - ale my nie chcemy zostawiać tych 10% z niczym

Domyślam się, że można oprócz tego skorzystać z niskiego TTL (np 60 sec) dla domeny i ewentualnie usuwać rekord A dla niedziałającego serwera... Ale coś mi się obiło o uszy, że niektóre serwery DNS ignorują niską wartość TTL.

Jest jeszcze coś co się nazywa DNS anycast - ale niezbyt cokolwiek wiem o tej technologii...

 

Ktoś ma jakieś pomysły?

Jako, że jest to dział "luźne rozmowy o hostingu" więc chciałbym aby temat tak został potraktowany - czysta dyskusja.

Kszysiu

[Pan Kot 1535]

Zacznę od fajnego cytatu.

 

If you mean that 100% of the time, 100% of people who are connected to some part of the Internet can issue a TCP request to your server and get a response, the answer (today) is "No"--there are enough points of failure and latency issues across the globe that will prevent this from happening.

 

 

I drugi cytacik:

load balancing does not imply redundancy, it's quite the opposite in fact. The more servers you have, the more likely you'll have a failure at a given instant. That's why redundancy IS mandatory when doing load balancing, but unfortunately there are a lot of solutions which only provide load balancing without performing any health check, resulting in a less reliable service.

 

 

Jeśli podchodzisz do sprawy poważnie to potrzebujesz zrobić coś na kształt tego

 

DNSy nie są "zaufane". TTL powinien, ale niekoniecznie musi być respektowany. Nie masz żadnej fizycznej gwarancji tego, że serwer DNS który odpytuje twój user respektuje TTL, dodatkowo również w przypadku RR nie masz żadnego failure-detection, a 10% szansa na fail przy 9 działających serwerach na 10 jest niedopuszczalna (nie kalkuluje się).

 

Oczywiście to nie jedyne rozwiązanie (keepalived) zapewniające "prawie" 100% uptime, jest też np. UCARP czy hearthbeat. Również niekoniecznie trzeba korzystać z HAProxy, jest chociażby również nginx, tyle że HAProxy akurat pod tym względem jest lepszy (proxy TCP) niż nginx (proxy HTTP).

 

Być może ktoś bardziej doświadczony akurat w tym temacie powie coś więcej albo mnie poprawi, nigdy nie potrzebowałem aż tak wysokiego SLA dla swoich usług.

Edytowano Kwiecień 4, 2015 przez Archi (zobacz historię edycji)

[Kszysiu 136]

Zacznę od fajnego cytatu.

 

No tak, to jest zrozumiałe - i tak znajdzie się taki któremu nie będzie działać i to może być w 100% niezależne od mojego "HA"

 

Ogólnie nie chodziło mi o "100% uptime" - bardziej chodziło mi o "dużo dziewiątek" - logiczne, ze nie jestem w stanie w razie "padu" jednej ze stron przełączyć tego w ciągu sekundy, tak żeby działało idealnie, ale chodzi o zmniejszenie tego czasu do minimum.

Jeśli ktoś ściągnie "moje fotki" do połowy i mu przerwie i będzie musiał zacząć jeszcze raz - trudno. Ważne, że może od razu ponowić próbę

 

 

 

Jeśli podchodzisz do sprawy poważnie to potrzebujesz zrobić coś na kształt tego

 

To jest chyba nie do końca to o czym myślałem - nie wiem jak miałbym to zrobić na poziomie dwóch niezależnych DC, niezależnych AS.

 

 

 

 

DNSy nie są "zaufane". TTL powinien, ale niekoniecznie musi być respektowany. Nie masz żadnej fizycznej gwarancji tego, że serwer DNS który odpytuje twój user respektuje TTL, dodatkowo również w przypadku RR nie masz żadnego failure-detection, a 10% szansa na fail przy 9 działających serwerach na 10 jest niedopuszczalna (nie kalkuluje się).

 

To był przykład na który wpadłem szybko, przykład jak widać nie idealny bo przecież i tak ktoś nie będzie miał dostępu do treści.

 

 

 

Być może ktoś bardziej doświadczony akurat w tym temacie powie coś więcej albo mnie poprawi, nigdy nie potrzebowałem aż tak wysokiego SLA dla swoich usług.

Jak już wcześniej wspomniałem temat jest właśnie bardziej edukacyjny

 

Jak to jest np. z cloudflare - co jak pada im jeden serwer? jak szybko strona zaczyna odpowiadać na innym? ktoś miał okazję być królikiem doświadczalnym?

Np. jeśli takie cloudflare miałoby jeszcze możliwość loadballancingu (a nie wiem czy ma?) - w sensie, dodajesz 2 źródła i jak nie może odczytać strony, to nie wczytuje cache tylko stronę z drugiego źródła. No i tu już teoretycznie osiąga się HA na poziomie serwerów hostujących treść - ale jak rozrzucić ruch po tej warstwie "z przodu"?

Edytowano Kwiecień 4, 2015 przez Kszysiu (zobacz historię edycji)

[Misiek08 285]

W takich pytaniach trzeba zawsze dopisać na jaki maksymalny czas niedostępności się zgadzasz. Czas sumaryczny i czas np. przy padzie serwera lub DC.

 

Zmontowałem raz doświadczalnie taki zestaw i teoretycznie maksymalny czas niedostępności wahał się w granicach 0-25s. Było to doświadczalne ustawienie, więc na VPSach, ale użyłem do tego CloudFlare, ich API i 5 serwerów VPS. 3 jako lustrzane sprawdzacze dostępności, 2 jako serwery strony. Każdy z 3 odpytywał aktualny główny serwer pod adresem testowym i jeśli coś było nie tak, to każdy z tych 3 podawał innym kandydata na nowy aktywny serwer. Z tych 3 jeden był główny i punktował kandydatów i temu z największym wynikiem przekazywał ruch zmieniając DNS w CF za pomocą API. Serwerów sprawdzających można kupoć ile się chce, zamiast 2 VPSów pod treść - dedyki lub grupy dedyków wielu centrach danych i wszystko działa.

 

Tutaj do 10s da się spokojnie zejść, ale to tylko HTTP(S), bo WebSockety już padną.

 

CF ma i anycast i loadbalancing i failover, bo inaczej nie osiągnęli by swojej dostępności.

[Kszysiu 136]

Każdy z 3 odpytywał aktualny główny serwer pod adresem testowym i jeśli coś było nie tak, to każdy z tych 3 podawał innym kandydata na nowy aktywny serwer. Z tych 3 jeden był główny i punktował kandydatów i temu z największym wynikiem przekazywał ruch zmieniając DNS w CF za pomocą API.

 

Znów wracamy do DNS czyli:

 

 

DNSy nie są "zaufane". TTL powinien, ale niekoniecznie musi być respektowany. Nie masz żadnej fizycznej gwarancji tego, że serwer DNS który odpytuje twój user respektuje TTL

Chyba, że czegoś nie zrozumiałem w twojej wypowiedzi Misiek.

 

 

Ale twoje efekty:

 

 

Tutaj do 10s da się spokojnie zejść, ale to tylko HTTP(S), bo WebSockety już padną.

 

To już super Zastanawiam się, czy z tego da się wyeliminować cloud flare

Edytowano Kwiecień 4, 2015 przez Kszysiu (zobacz historię edycji)

[Pan Kot 1535]

W takich pytaniach trzeba zawsze dopisać na jaki maksymalny czas niedostępności się zgadzasz. Czas sumaryczny i czas np. przy padzie serwera lub DC.

 

Zmontowałem raz doświadczalnie taki zestaw i teoretycznie maksymalny czas niedostępności wahał się w granicach 0-25s. Było to doświadczalne ustawienie, więc na VPSach, ale użyłem do tego CloudFlare, ich API i 5 serwerów VPS. 3 jako lustrzane sprawdzacze dostępności, 2 jako serwery strony. Każdy z 3 odpytywał aktualny główny serwer pod adresem testowym i jeśli coś było nie tak, to każdy z tych 3 podawał innym kandydata na nowy aktywny serwer. Z tych 3 jeden był główny i punktował kandydatów i temu z największym wynikiem przekazywał ruch zmieniając DNS w CF za pomocą API. Serwerów sprawdzających można kupoć ile się chce, zamiast 2 VPSów pod treść - dedyki lub grupy dedyków wielu centrach danych i wszystko działa.

 

Tutaj do 10s da się spokojnie zejść, ale to tylko HTTP(S), bo WebSockety już padną.

 

CF ma i anycast i loadbalancing i failover, bo inaczej nie osiągnęli by swojej dostępności.

 

Łatwiej zrobić RR wokół tych dwóch serwerów, dołożyć dwa sprawdzacze, i jeśli obydwa zwrócą fail to wyłączają z obiegu rekord A/AAAA dla tego serwera, który nie działa.

 

Tyle, że to wciąż są DNSy, a na poziomie DNSów nie można mówić o gwarancji, a raczej o "czymś co powinno w teorii działać". W praktyce mamy tyle różnych rozwiązań, zarówno po stronie providerów, klientów, jak i ich ustawień i przeglądarek, że respektowanie TTL nie może być w żaden sposób wymuszane.

[Misiek08 285]

@Archi no właśnie RR to DNS, DNS to TTL i dalej bez pomysłu.

 

Kszysiu - DNS to jedno, ale CF wykorzystać jako proxy, czyli DNSy wskazują na serwery CF, a te podają treść z zadanych serwerów. Mam do tego stare skrypty, bo chciałem takie HA jako tanią usługę wystawić, ale nie wiem czy by był ktoś chętny.

[Kszysiu 136]

Misiek, to jest dobre rozwiązanie...


Ale znów wracamy do punktu wyjścia - tyle, że w tym przypadku problemem nie jest nasz serwer z tyłu, a te proxy z przodu, które może paść dokładnie tak samo jak nasze serwery z treścią

Co wtedy?
CF niby jest fajne - ale dochodzimy do momentu...

Jak sobie zrobić CF samemu? Jak oni się "obunkrowali" że możemy liczyć, że zawsze będą działać.

[Misiek08 285]

Własne /24, rozgłaszanie ich w kilku DC i zaprzestanie rozgłaszania jeżeli za danym routerem już nic nie działa. Trasy się odświeżą i ruch pójdzie gdzie indziej.

[Pan Kot 1535]

IP failover po prostu.

[Misiek08 285]

IP Failover to jedno DC zazwyczaj, czyli nadal lokalizacja jest słabym punktem. OVH dawno już nie zniknęło z sieci, ale jak autor pyta o teorię to IP FO to moim zdaniem mało.

[Kszysiu 136]

Dokładnie Archi - chodziło mi o wyjście "poza DC".

Ogólnie szukając szybko o failover IP albo o Anycast DNS, to pierwsze strony wyników w góglu to i tak gotowa usługa - o ile failover IP zdaje się być "proste" to nie mogę rozkminić co daje Anycast DNS, bo (chyba) rozumiem sens działania, ale nie rozumiem co to miałoby dać i w jaki sposób:P

Rozgłaszanie IP w dwóch DC jest dobrym rozwiązaniem...

Pytanie: Tak można? O ile techniczne myślę, że bez problemu to jak... "prawnie" - jakieś RIPE czy ktoś się nie czepia? (nie znam tych instytucji, ale kojarzę, że to oni się ajpikami i numerami AS zajmują).

ps (offtop). Misiek - dopiero teraz zauważyłem, gdzie twój podpis z cytatem? Czy pomyliłem osoby? xD

[Misiek08 285]

@Kszysiu: Gdzieś tam było info o maksymalnej długości sygnatury, a chciałem wstawić info o usługach, więc zmuszony byłem usunąć.

 

Temat:

 

Rozgłaszanie Anycast to puszczanie IP z wielu DC i routery same znajdują najkrótszą trasę, więc w teorii wystarczy rozgłosić w 2 miejscach na 2 kontynentach i mamy już naprawdę nieźle zabezpieczone, tylko w przypadku przełączenia się na drugi kontynent wzrasta opóźnienie i ruch na danym punkcie dwukrotnie.

 

Ogólnie Anycast to piękna sprawa, tylko trzeba mieć swój AS, blok IP i znaleźć firmy, które go dla nas rozgłoszą LUB trzeba postawić własne routery z BGP, znaleźć peerów itd.

[Kszysiu 136]

 

 

Rozgłaszanie Anycast to puszczanie IP z wielu DC i routery same znajdują najkrótszą trasę, więc w teorii wystarczy rozgłosić w 2 miejscach na 2 kontynentach i mamy już naprawdę nieźle zabezpieczone, tylko w przypadku przełączenia się na drugi kontynent wzrasta opóźnienie i ruch na danym punkcie dwukrotnie.

Jak ogólnie działa Anycast to "ja rozumie", co to robi też rozumie, ale nie rozumie usługi Anycast DNS...

https://www.ovh.pl/domeny/dns-anycast/

Co to by mi miało w ogóle dać? Że DNS odpowie w stanach szybciej i moja strona otworzy się 100ms szybciej? Bo na prawdę nie widzę innej opcji

[Misiek08 285]

To nie ogarnąłem. Anycast DNS to w sumie marketing bardziej, bo w teorii chodzi tylko o to pierwsze zapytanie i te 70ms szybciej za pierwszym razem. DNSy i tak każdy trzyma w dwóch niezależnych lokalizacjach(taaa, najczęściej ten sam IP dla NSów i tyle - sam tak mam dla prywatnej domeny), więc dostępne są, tylko szybkość mniejsza.