Czy usługa Round-Robin DNS jest „wystarczająco dobra” do równoważenia zawartości statycznej?

Mamy zestaw wspólnych, statycznych treści, które udostępniamy między naszymi stronami internetowymi pod adresem http://sstatic.net . Niestety, ta zawartość nie jest obecnie w ogóle zrównoważona pod względem obciążenia - jest obsługiwana z jednego serwera. Jeśli na tym serwerze występują problemy, wszystkie witryny, które na nim polegają, są skutecznie niedostępne, ponieważ współużytkowane zasoby są niezbędnymi współdzielonymi bibliotekami i obrazami javascript.

Szukamy sposobów równoważenia obciążenia statycznej zawartości na tym serwerze, aby uniknąć zależności od pojedynczego serwera.

Zdaję sobie sprawę, że DNS typu round-robin jest w najlepszym razie rozwiązaniem niskiej jakości (niektórzy mogliby nawet powiedzieć getto ), ale nie mogę się zastanawiać - czy DNS typu round-robin jest wystarczająco dobrym rozwiązaniem do podstawowego równoważenia obciążenia statycznej zawartości ?

Trwa dyskusja na ten temat w tagach [dns] [równoważenie obciążenia] , a ja przeczytałem kilka świetnych postów na ten temat.

Zdaję sobie sprawę z typowych wad równoważenia obciążenia DNS poprzez wiele rekordów A w trybie round-robin:

• zwykle nie ma uderzeń serca ani wykrywania awarii z rekordami DNS, więc jeśli dany serwer w rotacji spadnie, jego rekord A musi zostać ręcznie usunięty z wpisów DNS
• czas do życia (TTL) musi być koniecznie ustawiony dość nisko, aby w ogóle działał, ponieważ wpisy DNS są buforowane agresywnie w Internecie
• komputery klienckie są odpowiedzialne za sprawdzenie, czy istnieje wiele rekordów A i wybranie właściwego

Ale czy okrągły DNS robin jest wystarczająco dobry na początek, lepszy niż nic, „podczas gdy badamy i wdrażamy lepsze alternatywy” formy równoważenia obciążenia dla naszej zawartości statycznej? A może okrągły runda DNS jest w ogóle bezwartościowy ?

Jeff, nie zgadzam się, równoważenie obciążenia nie oznacza redundancji, wręcz przeciwnie. Im więcej masz serwerów, tym większe prawdopodobieństwo wystąpienia awarii w danym momencie. Dlatego nadmiarowość JEST obowiązkowa podczas równoważenia obciążenia, ale niestety istnieje wiele rozwiązań, które zapewniają równoważenie obciążenia tylko bez przeprowadzania kontroli stanu, co skutkuje mniej niezawodną obsługą.

Roundrobin DNS doskonale nadaje się do zwiększania pojemności, rozkładając obciążenie na wiele punktów (potencjalnie rozmieszczonych geograficznie). Ale nie zapewnia przełączania awaryjnego. Musisz najpierw opisać rodzaj awarii, którą próbujesz skasować. Awaria serwera musi zostać naprawiona lokalnie przy użyciu standardowego mechanizmu przejmowania adresów IP (VRRP, CARP, ...). Awaria przełącznika jest chroniona przez elastyczne łącza na serwerze do dwóch przełączników. Awaria łącza WAN może zostać pokryta przez konfigurację wielu łączy między tobą a twoim dostawcą, za pomocą protokołu routingu lub rozwiązania warstwy 2 (np. PPP z wieloma łączami). Awaria witryny powinna być pokrywana przez BGP: twoje adresy IP są replikowane na wielu stronach i ogłaszasz je w sieci tylko tam, gdzie są one dostępne.

Z twojego pytania wydaje się, że potrzebujesz jedynie rozwiązania awaryjnego serwera, które jest najłatwiejszym rozwiązaniem, ponieważ nie wymaga żadnego sprzętu ani umowy z żadnym dostawcą usług internetowych. Musisz tylko skonfigurować odpowiednie oprogramowanie na swoim serwerze i jest to zdecydowanie najtańsze i najbardziej niezawodne rozwiązanie.

Zapytałeś „co jeśli maszyna haproxy zawiedzie?”. To jest to samo. Wszyscy, których znam, którzy używają haproxy do równoważenia obciążenia i wysokiej dostępności, mają dwie maszyny i działają na nich ucarp, keepalived lub bicie serca, aby mieć pewność, że jedna z nich jest zawsze dostępna.

Mam nadzieję, że to pomoże!

Równoważenie obciążenia to getto, ale mniej lub bardziej skuteczne. Jeśli miałeś jeden serwer, który spadał z obciążenia i chciałeś go rozłożyć na wiele serwerów, może to być dobry powód, aby to zrobić, przynajmniej tymczasowo.

Istnieje wiele uzasadnionych zarzutów dotyczących rundy robin DNS jako „równoważenia obciążenia” i nie zalecałbym robienia tego inaczej niż jako krótkoterminowe wspomaganie pasma.

Mówisz jednak, że twoją podstawową motywacją jest unikanie zależności od jednego serwera. Bez zautomatyzowanego sposobu usuwania martwych serwerów z obrotu, nie jest to bardzo cenne jako sposób zapobiegania przestojom. (Dzięki zautomatyzowanemu sposobowi wycofywania serwerów z rotacji i krótkiemu czasowi TTL staje się trybem awaryjnym getta. Ręcznie, to nawet nie to.)

Jeśli jeden z dwóch okrągłych serwerów ulegnie awarii, 50% klientów dostanie awarię. Jest to lepsze niż 100% awarii w przypadku tylko jednego serwera, ale prawie każde inne rozwiązanie, które wykonało prawdziwe przełączanie awaryjne, byłoby lepsze.

Jeśli prawdopodobieństwo awarii jednego serwera wynosi N, w przypadku dwóch serwerów prawdopodobieństwo wynosi 2N. Bez automatycznego, szybkiego przełączania awaryjnego ten schemat zwiększa prawdopodobieństwo wystąpienia awarii u niektórych użytkowników.

Jeśli planujesz ręcznie wyłączyć martwy serwer z obrotu, jesteś ograniczony szybkością, z jaką możesz to zrobić oraz DNS TTL. Co jeśli serwer umrze o 4 rano? Najlepszą częścią trybu failover jest zasypianie w nocy. Używasz już HAProxy , więc powinieneś się z nim zapoznać. Zdecydowanie sugeruję użycie go, ponieważ HAProxy jest przeznaczony do dokładnie takiej sytuacji.

Round robin DNS nie jest tym, co ludzie myślą. Jako autor oprogramowania serwera DNS ( BIND ) otrzymujemy użytkowników, którzy zastanawiają się, dlaczego ich okrągły robin przestaje działać zgodnie z planem. Nie rozumieją, że nawet przy TTL wynoszącym 0 sekund będzie trochę buforowania, ponieważ niektóre pamięci podręczne zapewniają minimalny czas (często 30-300 sekund) bez względu na wszystko.

Ponadto, podczas gdy twoje serwery AUTH mogą wykonywać round robin, nie ma gwarancji, że te, na których Ci zależy - pamięci podręczne, z którymi rozmawiają użytkownicy - będą. Krótko mówiąc, okrągły robin nie gwarantuje żadnego zamówienia z punktu widzenia klienta, tylko to, co serwery auth zapewniają w pamięci podręcznej.

Jeśli chcesz prawdziwego przełączenia awaryjnego, DNS to tylko jeden krok. Wymienienie więcej niż jednego adresu IP dla dwóch różnych klastrów nie jest złym pomysłem, ale użyłbym tam innej technologii (takiej jak prosta anycast), aby przeprowadzić równoważenie obciążenia. Osobiście gardzę sprzętem do równoważenia obciążenia, który psuje się z DNS, ponieważ zwykle robi to źle. I nie zapominaj, że nadchodzi DNSSEC, więc jeśli wybierzesz coś w tym obszarze, zapytaj swojego dostawcę, co się stanie po podpisaniu strefy.

Powiedziałem to już kilka razy i powiem to jeszcze raz - jeśli problemem jest odporność, to sztuczki DNS nie są odpowiedzią .

Najlepsze systemy HA pozwolą Twoim klientom nadal używać dokładnie tego samego adresu IP dla każdego żądania. Jest to jedyny sposób, aby klienci nawet nie zauważyli awarii.

Zatem podstawową zasadą jest to, że prawdziwa odporność wymaga sztuczek na poziomie routingu IP . Użyj urządzenia równoważącego obciążenie lub OSPF „równomierny koszt wielu ścieżek”, a nawet VRRP.

Z drugiej strony DNS to technologia adresowania . Istnieje wyłącznie w celu mapowania z jednej przestrzeni nazw na drugą. Nie został zaprojektowany w celu umożliwienia bardzo krótkoterminowych dynamicznych zmian w tym odwzorowaniu, a zatem, gdy spróbujesz wprowadzić takie zmiany, wielu klientów albo ich nie zauważy, albo w najlepszym razie zajmie to dużo czasu.

Powiedziałbym również, że ponieważ ładowanie nie stanowi dla ciebie problemu, równie dobrze możesz mieć inny serwer gotowy do działania jako gorący tryb gotowości. Jeśli używasz głupiego okrężnego robota, musisz proaktywnie zmieniać rekordy DNS, gdy coś się zepsuje, więc równie dobrze możesz proaktywnie włączyć gorący serwer rezerwowy do działania i nie zmieniać DNS.

Przeczytałem wszystkie odpowiedzi i jedną rzeczą, której nie widziałem, jest to, że większość nowoczesnych przeglądarek internetowych wypróbuje jeden z alternatywnych adresów IP, jeśli serwer nie odpowiada. Jeśli dobrze pamiętam, Chrome spróbuje nawet wielu adresów IP i będzie kontynuował pracę z serwerem, który odpowie pierwszy. Więc moim zdaniem DNS Round Robin Równoważenie obciążenia jest zawsze lepsze niż nic.

BTW: Widzę DNS Round Robin bardziej jako proste rozwiązanie dystrybucji obciążenia.

Spóźniłem się na ten wątek, więc moja odpowiedź prawdopodobnie po prostu unosi się sama na dole, zaniedbana, powąchana.

Po pierwsze, właściwą odpowiedzią na pytanie nie jest odpowiedź na pytanie, ale powiedzenie:

1. „Prawdopodobnie chcesz zamiast tego wyrównać obciążenie systemu Windows .” LUB
2. „Czuć się z duchem czasu, umieść swoją statyczną zawartość na czymś takim jak Cloud Files lub S3 i niech CDN dubluje ją na całym świecie”.

NLB jest dojrzały, dobrze dostosowany do zadania i dość łatwy w konfiguracji. Rozwiązania chmurowe mają swoje zalety i wady, które są poza zakresem tego pytania.

Pytanie

czy usługa Round Robin DNS jest wystarczająco dobra na początek, lepsza niż nic, „podczas gdy badamy i wdrażamy lepsze alternatywy” formy równoważenia obciążenia dla naszej zawartości statycznej?

Pomiędzy, powiedzmy, 2 lub 3 statycznymi serwerami WWW? Tak, jest to lepsze niż nic, ponieważ istnieją dostawcy DNS, którzy zintegrują DNS Round Robin z kontrolami kondycji serwera i tymczasowo usuną martwe serwery z rekordów DNS. W ten sposób otrzymujesz przyzwoity rozkład obciążenia i pewną wysoką dostępność; a konfiguracja zajmuje mniej niż 5 minut.

Obowiązują jednak zastrzeżenia przedstawione przez innych w tym wątku:

• Obecne przeglądarki Microsoft buforują dane DNS przez 30 minut , więc patrzysz na ponad 30 minutowy czas przełączania awaryjnego podzbioru użytkowników, w zależności od ich początkowego stanu pamięci podręcznej DNS.
• To, co użytkownicy widzą podczas przełączania awaryjnego, może być ... dziwne (nie używasz uwierzytelniania do treści statycznych i na pewno nie tworzysz uwierzytelniania, ale link pokazuje coś, na co należy uważać).

Inne rozwiązania

HAProxy jest fantastyczny, ale ponieważ przepełnienie stosu jest w stosie technologii Microsoft, być może użycie narzędzi równoważenia obciążenia i wysokiej dostępności firmy Microsoft będzie miało mniejszy narzut administracyjny. Równoważenie obciążenia sieciowego rozwiązuje jedną część problemu, a Microsoft faktycznie ma teraz odwrotne proxy / równoważenie obciążenia L7 HTTP .

Nigdy sam nie korzystałem z ARR, ale biorąc pod uwagę, że jest on w drugim wydaniu głównym i pochodzi od Microsoftu, zakładam, że został wystarczająco przetestowany. Dokumenty są łatwe do zrozumienia , oto jeden z nich, jak widzą rozkład zawartości statycznej i dynamicznej w węzłach internetowych, a tutaj jest, jak używać ARR z NLB, aby osiągnąć zarówno rozkład obciążenia, jak i wysoką dostępność.

To niezwykłe, jak wielu współpracowników przyczynia się do dezinformacji o DNS Round Robin jako mechanizmie rozłożenia obciążenia i odporności. Zwykle działa, ale musisz zrozumieć, jak to działa, i uniknąć błędów spowodowanych całą tą dezinformacją.

1) TTL dla rekordów DNS używanych dla Round Robin powinien być krótki - ale NIE ZEROWANY. Utrzymywanie TTL na poziomie zerowym jest głównym sposobem zapewnienia odporności.

2) DNS RR rozprzestrzenia się, ale nie równoważy obciążenia, rozkłada go, ponieważ w dużej bazie klientów mają tendencję do samodzielnego wysyłania zapytań do serwera DNS, w wyniku czego uzyskują różne wpisy DNS pierwszego wyboru. Te różne pierwsze opcje oznaczają, że klienci są obsługiwani przez różne serwery, a obciążenie jest rozłożone. Ale wszystko zależy od tego, które urządzenie wykonuje zapytanie DNS i od tego, jak długo utrzymuje wynik. Typowym przykładem jest to, że wszyscy klienci za korporacyjnym serwerem proxy (który wykonuje dla nich zapytanie DNS) ostatecznie będą atakować pojedynczy serwer. Obciążenie rozkłada się - ale nie jest równomiernie zrównoważone.

3) DNS RR zapewnia odporność, o ile oprogramowanie klienckie odpowiednio go implementuje (a zarówno TTL, jak i zakres uwagi użytkowników nie są zbyt krótkie). Wynika to z faktu, że okrągły robin DNS zapewnia uporządkowaną listę adresów IP serwerów, a oprogramowanie klienckie powinno próbować kontaktować się z każdym z nich po kolei, aż znajdzie serwer, który zaakceptuje połączenie.

Jeśli więc serwer pierwszego wyboru jest wyłączony, połączenie klienta TCP / IP przekroczy limit czasu i pod warunkiem, że nie upłynął ani czas TTL, ani okres uwagi, oprogramowanie klienta podejmuje kolejną próbę połączenia z drugim wpisem na liście - i tak dalej, aż do momentu TTL wygasa lub trafia na koniec listy (albo użytkownik poddaje się z niesmakiem).

Długa lista uszkodzonych serwerów (twoja wina) i duże limity ponownych prób połączenia TCP / IP (błędna konfiguracja klienta) mogą powodować długi czas, zanim klient faktycznie znajdzie działający serwer. Zbyt krótki TTL oznacza, że ​​nigdy nie uda mu się dotrzeć do końca listy, zamiast tego wydaje nowe zapytanie DNS i dostaje nową listę (mam nadzieję, że w innej kolejności).

Czasami klient ma pecha, a nowa lista wciąż zaczyna się od uszkodzonych serwerów. Aby dać systemowi najlepszą szansę na zapewnienie odporności klienta, należy upewnić się, że czas TTL jest dłuższy niż typowy okres uwagi, a klient powinien dostać się na dół listy.

Gdy klient znajdzie działający serwer, powinien go zapamiętać, a kiedy musi nawiązać następne połączenie, nie powinien powtarzać wyszukiwania (chyba że upłynął czas TTL). Dłuższe TTL zmniejsza częstotliwość, z jaką użytkownicy doświadczają opóźnienia, podczas gdy klient szuka działającego serwera - co zapewnia lepsze wrażenia.

4) DNS TTL wchodzi w grę, gdy chcesz ręcznie zmienić rekordy DNS (np. Aby usunąć zepsuty serwer na dłuższą metę), to krótki TTL pozwala na szybkie rozpowszechnienie się tej zmiany (kiedy już to zrobisz), więc zastanów się nad równowagą między tym, jak długo potrwa, zanim dowiesz się o problemie, i dokonaj ręcznej zmiany - oraz faktem, że normalni klienci będą musieli przeprowadzić nowe wyszukiwanie działającego serwera dopiero po wygaśnięciu TTL.

Okrągły robin DNS ma dwie wyjątkowe funkcje, które sprawiają, że jest bardzo opłacalny w wielu różnych scenariuszach - po pierwsze jest bezpłatny, a po drugie jest prawie tak rozproszony geograficznie jak baza klientów.

Nie wprowadza nowej „jednostki awarii”, którą robią wszystkie inne „sprytne” systemy. Nie ma żadnych dodanych komponentów, które mogłyby wystąpić wspólna i jednoczesna awaria w całym obciążeniu połączonych elementów.

„Sprytne” systemy są świetne i wprowadzają wspaniałe mechanizmy koordynowania i zapewniania płynnego mechanizmu równoważenia i przełączania awaryjnego, ale ostatecznie tymi samymi metodami, które wykorzystują do zapewnienia płynnego działania, są pięta achillesowa - dodatkowa skomplikowana rzecz, która może się nie udać, a kiedy to zrobi, zapewni bezproblemowe działanie systemu awarii w całym systemie.

Tak, TAK, okrągły robin DNS jest zdecydowanie „wystarczająco dobry”, aby zrobić pierwszy krok poza pojedynczy serwer hostujący wszystkie treści statyczne w jednym miejscu.

Systemy Windows Vista i Windows 7 wdrażają obsługę klienta round robin inaczej, ponieważ dokonały backportu wyboru adresu IPv6 na IPv4. ( RFC 3484 )

Jeśli więc masz znaczną liczbę użytkowników systemów Vista, Windows 7 i Windows 2008, w rozwiązaniu do równoważenia obciążenia ersatz prawdopodobnie znajdziesz zachowanie niezgodne z planowanym sposobem myślenia.

Zawsze korzystałem z usługi Round-Robin DNS z długim czasem TTL jako funkcji równoważenia obciążenia. Działa naprawdę dobrze dla usług HTTP / HTTPS z przeglądarkami .

Naprawdę stresuję się w przypadku przeglądarek, ponieważ większość przeglądarek implementuje coś w rodzaju „ponów próbę na innym adresie IP”, ale nie wiem, jak inne biblioteki lub oprogramowanie poradziłyby sobie z rozwiązaniem z wieloma adresami IP.

Gdy przeglądarka nie otrzyma odpowiedzi z jednego serwera, automatycznie zadzwoni do następnego adresu IP, a następnie pozostanie przy nim (dopóki nie zostanie wyłączony ... a następnie spróbuje użyć innego).

W 2007 roku wykonałem następujący test:

• dodaj iframe na mojej stronie internetowej, wskazując jeden wpis Round-Robin, na przykład http://roundrobin.test:10080/ping.php
• strona była obsługiwana przez 3 gniazda PHP, nasłuchujące na 3 różnych adresach IP, wszystkie na porcie 10080 (nie było mnie stać na testowanie na porcie 80, ponieważ działała na nim moja strona internetowa)
• jedno gniazdo (powiedzmy A ) było tam, aby sprawdzić, czy przeglądarka może połączyć się z portem 10080 (ponieważ wiele firm dopuszcza tylko standardowe porty)
• pozostałe dwa gniazda (powiedzmy B i C ) można włączyć lub wyłączyć w locie.

Pozwoliłem mu działać przez godzinę, miałem dużo danych. Wyniki były takie, że dla 99,5% trafień w gnieździe A miałem trafienie w gnieździe B lub C (oczywiście nie wyłączyłem obu z nich jednocześnie). Przeglądarki to: iPhone, Chrome, Opera, MSIE 6/7/8, BlackBerry, Firefox 3 / 3.5 ... Więc nawet niezbyt zgodne przeglądarki dobrze sobie z tym radziły!

Do dziś nigdy go nie testowałem, ale może kiedyś skonfiguruję nowy test lub opublikuję kod na github, aby inni mogli go przetestować.

Ważna uwaga: nawet jeśli działa przez większość czasu, nie usuwa faktu, że niektóre żądania zakończą się niepowodzeniem. Używam go również do żądań POST, ponieważ moja aplikacja zwróci komunikat o błędzie, jeśli nie będzie działać, dzięki czemu użytkownik może ponownie wysłać dane, a najprawdopodobniej w tym przypadku przeglądarka użyje innego adresu IP i będzie działać zapisywanie . A w przypadku treści statycznych działa naprawdę świetnie.

Więc jeśli pracujesz z przeglądarkami, używaj Round-Robin DNS, zarówno dla zawartości statycznej, jak i dynamicznej, w większości będzie dobrze. Serwery mogą również spaść w trakcie transakcji, a nawet przy użyciu najlepszego modułu równoważenia obciążenia nie poradzisz sobie z taką sprawą. W przypadku treści dynamicznych musisz zsynchronizować sesje / bazę danych / pliki, w przeciwnym razie nie będziesz w stanie sobie z tym poradzić (ale jest to również prawdą w przypadku rzeczywistego równoważenia obciążenia).

Uwaga dodatkowa: możesz przetestować zachowanie na własnym adresie IP za pomocą iptables. Na przykład przed regułą zapory dla ruchu HTTP dodaj:

iptables -A INPUT -p tcp --dport 80 --source 12.34.56.78 -j REJECT

(gdzie 12.34.56.78oczywiście jest twoje IP)

Nie używaj DROP, ponieważ spowoduje to odfiltrowanie portu , a przeglądarka będzie czekać na przekroczenie limitu czasu. Teraz możesz włączyć lub wyłączyć jeden serwer lub drugi. Najbardziej oczywistym testem jest wyłączenie serwera A, załadowanie strony, a następnie włączenie serwera A i wyłączenie serwera B. Gdy załadujesz stronę ponownie, zobaczysz trochę oczekiwania z przeglądarki, a następnie załaduje się z serwera Znowu. W Chrome możesz potwierdzić adres IP serwera, patrząc na żądanie w panelu sieci. W Generalzakładce Headerszobaczysz fałszywy nagłówek o nazwie Remote Address:. To jest adres IP, z którego otrzymałeś odpowiedź.

Jeśli więc chcesz przejść w tryb konserwacji na jednym serwerze, po prostu wyłącz ruch HTTP / HTTPS za pomocą jednej iptables REJECTreguły, wszystkie żądania trafią do innych serwerów (z jednym krótkim oczekiwaniem, prawie niezauważalnym dla użytkowników).

Nie sądzę, aby było to wystarczająco dobre rozwiązanie, ponieważ załóżmy, że masz teraz dwa serwery i zaokrąglasz robota za pomocą DNS do adresu IP każdego serwera. Gdy jeden serwer ulegnie awarii, serwery DNS nie będą wiedziały, że uległy awarii i będą nadal obsługiwać ten adres IP w ramach procesu RR. Wówczas 50% odbiorców otrzyma uszkodzoną witrynę, w której brakuje javascript lub obrazów.

Być może łatwiej jest wskazać wspólny adres IP obsługiwany przez Windows NLB reprezentujący dwa serwery z tyłu. Chyba, że ​​gdzieś to przeczytałem, chyba że korzystasz z serwera Linux dla treści statycznych?

Round-robin równoważenie obciążenia działa tylko wtedy, gdy masz kontrolę nad strefą DNS, dzięki czemu możesz zmienić listę serwerów i przesłać ją do kontrolerów strefy w odpowiednim czasie.

Jak wspomniano w jednej z pozostałych odpowiedzi, ukrytym złem rundy robin jest buforowanie DNS, które może się zdarzyć w dowolnym miejscu między serwerami a klientem, co całkowicie neguje niewielką zaletę tego rozwiązania. Nawet przy ustawieniu TTL DNS na bardzo niską wartość masz niewielką kontrolę nad tym, jak długo pamięć podręczna DNS usługodawcy internetowego, a nawet klienta, utrzyma nieaktywny adres IP.

Z pewnością jest to poprawa w stosunku do SPOF, ale tylko marginalna. Chciałbym rzucić okiem na to, kto kiedykolwiek hostuje twój serwer i zobaczyć, co mają do zaoferowania, wielu ma jakąś podstawową usługę równoważenia obciążenia, którą mogą zapewnić.

Równie dobrze możesz mieć pojedynczy serwer ze zduplikowaną zawartością statyczną w S3 i przełączyć się na S3 CNAME, gdy podstawowa ulegnie awarii. Skończysz z tym samym opóźnieniem, ale bez kosztów wielu serwerów.

To naprawdę zależy od tego, o czym mówisz i od ilu serwerów się obracasz. Kiedyś miałem witrynę, która działała na kilku serwerach, i używałem do tego okrągłego robina DNS z powodu głównie mojej nowicjuszki w tym czasie, i to naprawdę nie był duży problem. To nie był duży problem, ponieważ się nie zawiesił. To był naprawdę głupi, nieskomplikowany system, więc trzymał się i miał dość stały poziom ruchu. Gdyby zepsuł się z ruchu, to w ciągu dnia i czymś, czym mógłbym się łatwo zająć. Powiedziałbym, że twoja statyczna treść kwalifikuje się jako wystarczająco prosta, aby sama nie powodować awarii.

Poza awarią sprzętu itp., Jak stabilny był twój serwer? Jak „spiczasty” jest ruch z tych treści? Zakładając, że jest to Apache lub coś w tym rodzaju i względnie mały ruch uliczny, nie będzie to miało wielkiego załamania, i powiedziałbym, że round-robin jest wystarczająco dobry.

Jestem pewien, że zagłosuję, ponieważ nie głosię rozwiązania w 100% HA, ale nie o to prosiliście. Wszystko sprowadza się do tego, co chcesz zaakceptować jako rozwiązanie, a nie wysiłku.

Jeśli używasz RR DNS do równoważenia obciążenia, byłoby dobrze, ale tak nie jest. Używasz go, aby włączyć nadmiarowy serwer, w którym to przypadku nie jest w porządku.

Jak powiedział poprzedni post, potrzebujesz czegoś, aby wykryć bicie serca i przestać go uderzać, dopóki nie wróci.

Dobra wiadomość jest taka, że ​​bicie serca jest dostępne naprawdę tanio, albo w przełącznikach, albo w systemie Windows.

Nie wiem o innych systemach operacyjnych, ale zakładam, że też tam są.

Sugeruję, aby przypisać dodatkowy adres IP do każdego z serwerów (oprócz statycznego adresu IP, którego używasz, powiedzmy, ssh) i przenieść go do puli DNS. Następnie używasz oprogramowania do przełączania adresów IP na wypadek awarii serwera. Heartbeat lub CARP mogą to zrobić, na przykład, ale istnieją inne rozwiązania.

Ma to tę zaletę, że dla klientów Twojej usługi nic nie musi się zmieniać w konfiguracji i nie musisz się martwić o buforowanie DNS lub TTL, ale nadal możesz skorzystać z „równoważenia obciążenia” w systemie round-robin DNS .

Prawdopodobnie wykona to zadanie, szczególnie jeśli możesz mieć wiele adresów IP na swoich statycznych skrzynkach. mieć jeden adres IP „podaj treść statyczną” i jeden adres IP „zarządzaj maszyną”. Jeśli następnie pole się opuści, możesz użyć istniejącego rozwiązania HA lub ręcznej interwencji, aby podnieść adres IP z uszkodzonej maszyny na jednym z pozostałych „elementów klastra” lub na zupełnie nowej maszynie (w zależności od tego, jak szybko by to było aby to uruchomić).

Jednak takie rozwiązanie będzie miało niewielkie problemy. Równoważenie obciążenia nie będzie blisko ideału, a jeśli polegasz na ręcznej interwencji, możesz mieć przerwy dla niektórych odwiedzających.

Sprzętowy moduł równoważenia obciążenia prawdopodobnie lepiej poradzi sobie zarówno z dzieleniem obciążenia, jak i zapewnianiem „czasu sprawności klastra”, niż robi to okrągły DNS. Z drugiej strony, to jest jeden (lub dwa, ponieważ idealnie masz LB w klastrze HA) elementy sprzętu, które będą wymagać zakupu, zasilania i chłodzenia oraz (ewentualnie) trochę czasu na zapoznanie się (jeśli jeszcze tego nie zrobiłeś) mają dedykowane moduły równoważące obciążenie).

Aby zwięźle odpowiedzieć na pytanie (czy okrągły robin DNS jest wystarczająco dobry na początek, lepszy niż nic, „podczas gdy badamy i wdrażamy lepsze alternatywy” formy równoważenia obciążenia dla naszej zawartości statycznej?), Powiedziałbym, że jest lepszy niż nic, ale zdecydowanie powinieneś nadal badać inne formy równoważenia obciążenia.

Podczas badań równoważenia obciążenia systemu Windows kilka lat temu widziałem dokument, w którym stwierdzono, że farma internetowa Microsoftu została skonfigurowana jako wiele grup równoważenia obciążenia, między którymi znajduje się okrągły DNS. Ponieważ w każdej przestrzeni nazw może znajdować się wiele serwerów DNS, a ponieważ funkcja równoważenia obciążenia firmy Microsoft jest samonaprawiająca się, zapewnia to zarówno redundancję, jak i równoważenie obciążenia.

Wada: potrzebujesz co najmniej 4 serwerów (2 serwery x 2 grupy).

Odpowiadając na komentarz Jeffa dotyczący odpowiedzi Schofa, czy istnieje sposób na round-robin DNS między serwerami HAProxy?

Ma bardzo marginalne zastosowanie, wystarczające, abyś mógł sobie z tym poradzić, gdy wprowadzasz prawdziwe rozwiązanie. Jak mówisz, wartości TTL muszą być dość niskie. Ma to jednak dodatkową zaletę polegającą na wyciągnięciu problematycznej maszyny z DNS, gdy występują problemy. Powiedzmy, że SvrA, SvrB i SvrC rozdają swoje treści, a SvrA spada. Wyciągasz go z DNS i po krótkim okresie czasu zdefiniowanym przez niski TTL, resolwery wykryją inny serwer (SvrB lub SvrC), który działa. Ponownie włączasz SvrA do trybu online i ponownie włączasz go do DNS. Krótki przestój dla niektórych ludzi, żaden dla innych. Nie świetne, ale wykonalne. Im więcej statycznych serwerów umieścisz w miksie, tym mniejsze jest prawdopodobieństwo, że większość grup użytkowników zostanie wyłączona.

Z pewnością nie uzyskasz prawdziwie zbalansowanej dystrybucji, którą zapewni prawdziwe rozwiązanie równoważenia obciążenia ze względu na topologię Internetu. Nadal obserwowałbym obciążenie wszystkich zaangażowanych serwerów.