Pytanie dotyczące konfiguracji globalnej wysokiej dostępności

Jestem właścicielem i operatorem visualwebsiteoptimizer.com /. Aplikacja zawiera fragment kodu, który moi klienci wstawiają na swoich stronach internetowych, aby śledzić określone dane. Ponieważ fragment kodu to zewnętrzny kod JavaScript (u góry kodu witryny), przed wyświetleniem witryny klienta przeglądarka użytkownika kontaktuje się z naszym serwerem aplikacji. W przypadku awarii naszego serwera aplikacji przeglądarka będzie próbowała nawiązać połączenie, zanim upłynie limit czasu (zwykle 60 sekund). Jak możesz sobie wyobrazić, nie możemy sobie pozwolić na wyłączenie naszego serwera aplikacji w żadnym scenariuszu, ponieważ wpłynie to negatywnie na doświadczenie nie tylko odwiedzających naszą stronę internetową, ale także odwiedzających naszą stronę internetową naszych klientów!

Obecnie używamy mechanizmu przełączania awaryjnego DNS z jednym serwerem kopii zapasowej zlokalizowanym w innym centrum danych (właściwie innym kontynencie). Oznacza to, że monitorujemy nasz serwer aplikacji z 3 oddzielnych lokalizacji i jak tylko wykryjemy, że jest wyłączony, zmieniamy rekord A, aby wskazywał adres IP serwera kopii zapasowej. Działa to dobrze dla większości przeglądarek (ponieważ nasze TTL wynosi 2 minuty), ale IE buforuje DNS przez 30 minut, co może być zabójcą transakcji. Zobacz najnowszy post z naszego visualwebsiteoptimizer.com/split-testing-blog/maximum-theoretical-downtime-for-a-website-30-minutes/

Jakiego rodzaju konfiguracji możemy użyć, aby zapewnić niemal natychmiastowe przełączenie awaryjne na wypadek poważnej awarii centrum danych aplikacji? Przeczytałem tutaj www.tenereillo.com/GSLBPageOfShame.htm, że posiadanie wielu rekordów A jest rozwiązaniem, ale nie stać nas jeszcze na synchronizację sesji. Inną strategią, którą badamy, są dwa rekordy A, jeden wskazujący na serwer aplikacji, a drugi na zwrotny serwer proxy (znajdujący się w innym centrum danych), który rozwiązuje problem na głównym serwerze aplikacji, jeśli jest uruchomiony, i na serwerze kopii zapasowej, jeśli działa. Czy uważasz, że ta strategia jest rozsądna?

Aby mieć pewność co do naszych priorytetów, możemy pozwolić sobie na utrzymanie własnej witryny lub aplikacji w dół, ale nie możemy pozwolić, aby strona internetowa klientów zwolniła z powodu naszego przestoju. W przypadku awarii serwerów aplikacji nie zamierzamy odpowiadać domyślną odpowiedzią aplikacji. Wystarczy pusta odpowiedź, wystarczy, że przeglądarka zakończy połączenie HTTP (i nic więcej).

Odniesienie: Przeczytałem ten wątek, który był przydatny serverfault.com/questions/69870/multiple-data-centers-and-http-traffic-dns-round-robin-is-the-only-way-to-assure

Twoja sytuacja jest dość podobna do naszej. Chcemy podzielonych centrów danych i trybu failover typu warstwa sieci.

Jeśli masz na to budżet, potrzebujesz dwóch centrów danych, wielu tranzytów IP do każdego, pary routerów brzegowych wykonujących sesje BGP u dostawców usług tranzytowych, reklamujących twoje adresy IP w globalnym Internecie.

Jest to jedyny sposób na prawdziwe przełączenie awaryjne. Gdy routery zauważą, że trasa do twoich serwerów nie jest już ważna (co możesz zrobić na wiele sposobów), wtedy przestają reklamować tę trasę, a ruch trafia do innej witryny.

Problem polega na tym, że dla pary routerów brzegowych początkowo patrzysz na dość wysoki koszt, aby skonfigurować tę konfigurację.
Następnie musisz skonfigurować sieć za tym wszystkim i możesz rozważyć połączenie Warstwy 2 między Twoimi witrynami jako łącze punkt-punkt, abyś mógł kierować ruchem przychodzącym do jednego centrum danych, bezpośrednio do drugiej w przypadku częściowej awarii witryny głównej.

Najlepsze praktyki BGP Multihomed / Multi-location i najlepszy sposób na poprawę odporności? to pytania, które zadałem na temat podobnych problemów.

Wstydliwa strona GSLB porusza kilka ważnych kwestii, dlatego osobiście nigdy nie wybrałbym GSLB do wykonania routingu BGP.

Powinieneś także spojrzeć na inne punkty awarii w swojej sieci. Upewnij się, że wszystkie serwery mają 2 karty sieciowe (podłączone do 2 oddzielnych przełączników), 2 zasilacze i że twoja usługa składa się z wielu serwerów zaplecza, takich jak pary nadmiarowe lub klastry z równoważeniem obciążenia.

Zasadniczo „równoważenie obciążenia” DNS przez wiele rekordów A jest po prostu „dzieleniem obciążenia”, ponieważ serwer DNS nie ma pojęcia, ile obciążenia jest na każdym serwerze. To jest tanie (za darmo).

Usługa GSLB ma pewne pojęcie o tym, jak obciążone są serwery i ich dostępność, a także zapewnia większą odporność na awarie, ale nadal są nękane problemami związanymi z buforowaniem i ustalaniem adresów DNS. Jest to mniej tanie, ale nieco lepsze.

Sieć routowana BGP, wsparta solidną infrastrukturą, to IMHO, jedyny sposób, aby naprawdę zagwarantować dobry czas bezawaryjnej pracy. Możesz zaoszczędzić trochę pieniędzy, używając serwerów tras zamiast routerów Cisco / Juniper / etc, ale pod koniec dnia musisz bardzo ostrożnie zarządzać tymi serwerami. Nie jest to w żadnym razie tania opcja lub coś, co należy podjąć lekko, ale jest to bardzo satysfakcjonujące rozwiązanie, które wprowadza cię do Internetu jako dostawca, a nie tylko konsument.

OK, zapytano to jakiś czas temu, ale teraz widzę to po raz pierwszy.

fragment kodu to zewnętrzny JavaScript (u góry kodu strony), przed wyświetleniem strony klienta przeglądarka użytkownika kontaktuje się z naszym serwerem aplikacji.

Powinieneś:

1. Umieść swój plik Javascript w dobrej, profesjonalnej sieci dostarczania treści, tj. Kup wysokiej jakości obsługę JavaScript (S) od osoby, która ma już taką wiedzę.
2. Zaprogramuj Javascript, aby uzyskać dobry stan rezerwowy, tzn. Jeśli serwer aplikacji nie zareaguje szybko, użytkownik końcowy zobaczy normalną, niezmodyfikowaną stronę.

Robienie czegokolwiek innego jest naprawdę nieodpowiedzialne. Zakładam, że już to masz.

Należy nie oprzeć swoją usługę routingu BGP na sztuczki, chyba że masz lub uzyskanie know-how, aby to zrobić. Złożone scenariusze routingu BGP są zdecydowanie nietrywialne do wdrożenia; nie rób tego sam, jeśli nie masz wiedzy na temat konkretnej domeny.

Twoje pytanie jest trochę zdezorientowane. Analiza tego, jak utworzyć wysoce dostępną usługę, rozpoczyna się od danych aplikacji , ponieważ taki jest Twój „stan”. Części bezpaństwowe są łatwo dostępne, części pełne nie są. Zamiast skupiać się na serwerach i DNS, spójrz na to, gdzie aplikacja utrzymuje stan . Zacznij od optymalizacji tam i ewentualnie poproś o porady dotyczące algorytmu na temat przepełnienia stosu. Czy możesz zaimplementować pojęcie transakcji i ponowić próbę inteligentnego serwera w pliku JavaScript?

W rzeczywistości to, czego chcesz, można zaktualizować, aby pomóc w dzieleniu działań testowych, jeśli połączysz przełączanie awaryjne geodns i dns.

Wysłanie grupy A na ip 1 i grupy B na ip 2, nawet jeśli były na tym samym serwerze, pozwoliłoby ci oddzielić grupy testowe. Grupa A i grupa B pochodzą z różnych regionów geograficznych. Aby być uczciwym, następnego dnia / tygodnia / miesiąca przerzucasz grupy, aby upewnić się, że dopuszczasz różnice geograficzne. Aby być rygorystycznym w swojej metodologii.

Usługa dns geodns / failover na stronie http://edgedirector.com może to zrobić

ujawnienie: jestem związany z powyższym linkiem, natknąłem się tutaj na badanie artykułu o zastosowaniu głupich sztuczek dns do testowania podzielonego.