100% czasu działania aplikacji internetowej

Otrzymaliśmy dziś interesujący „wymóg” od klienta.

Chcą 100% czasu pracy bez wyłączania awaryjnego w aplikacji internetowej. Z punktu widzenia naszej aplikacji internetowej nie stanowi to problemu. Został zaprojektowany, aby móc skalować na wiele serwerów baz danych itp.

Jednak z powodu problemu z siecią po prostu nie mogę zrozumieć, jak to zrobić.

Krótko mówiąc, aplikacja będzie działać na serwerach w sieci klienta. Jest dostępny zarówno dla osób wewnętrznych, jak i zewnętrznych. Chcą, abyśmy utrzymywali kopię systemu poza witryną, która w przypadku poważnej awarii w ich obiektach natychmiast przejmie i przejmie kontrolę.

Teraz wiemy, że absolutnie nie ma możliwości rozwiązania tego problemu dla ludzi wewnętrznych (gołębi pocztowych?), Ale chcą, aby użytkownicy zewnętrzni nawet tego nie zauważyli.

Szczerze mówiąc, nie mam najmniejszego pojęcia, jak to możliwe. Wygląda na to, że jeśli utracą łączność z Internetem, będziemy musieli dokonać zmiany DNS, aby przekazywać ruch do urządzeń zewnętrznych ... Co oczywiście wymaga czasu.

Pomysły?

AKTUALIZACJA

Dzisiaj rozmawiałem z klientem, który wyjaśnił sprawę.

Utknęli przy wartości 100%, mówiąc, że aplikacja powinna pozostać aktywna nawet w przypadku powodzi. Jednak wymóg ten pojawia się tylko wtedy, gdy go hostujemy. Powiedzieli, że poradzą sobie z czasem przestoju, jeśli aplikacja będzie działać całkowicie na swoich serwerach. Możesz odgadnąć moją odpowiedź.

Oto przydatna tabela Wikipedii w poszukiwaniu dziewiątek:

Co ciekawe, tylko 3 z 20 najlepszych stron internetowych były w stanie osiągnąć mityczną liczbę 5 dziewiątek lub 99,999% czasu sprawności w 2007 roku. Były to Yahoo, AOL i Comcast. W pierwszych 4 miesiącach 2008 r. Niektóre z najpopularniejszych sieci społecznościowych nawet się do tego nie zbliżały.

Z wykresu powinno być oczywiste, jak absurdalne jest dążenie do 100% czasu pracy ...

Poproś, aby zdefiniowali 100% i jak będą mierzone W jakim okresie. Prawdopodobnie oznaczają one prawie 100%, jak mogą sobie pozwolić. Podaj koszty.

Opracować. Przez lata rozmawiałem z klientami o rzekomo absurdalnych wymaganiach. We wszystkich przypadkach używali po prostu nieprecyzyjnego języka.

Dość często przedstawiają elementy w sposób, który wydaje się bezwzględny - na przykład 100%, ale w rzeczywistości przy głębszych badaniach są wystarczająco rozsądne, aby przeprowadzić analizy kosztów i korzyści, które są wymagane, gdy są przedstawiane z kosztorysowaniem danych ograniczających ryzyko. Pytanie o to, jak zmierzą dostępność, jest kluczowym pytaniem. Jeśli nie wiedzą o tym, jesteś w stanie zasugerować im, że należy to najpierw zdefiniować.

Poprosiłbym klienta, aby określił, co by się stało pod względem wpływu / kosztów biznesowych, gdyby witryna uległa awarii w następujących okolicznościach:

• W najbardziej ruchliwych godzinach x godzin
• W ich najmniej pracowitych godzinach przez x godzin

A także, jak to zmierzą.

W ten sposób możesz z nimi współpracować w celu ustalenia właściwego poziomu „100%”. Podejrzewam, że zadając tego rodzaju pytania, będą mogli lepiej określić priorytety innych wymagań. Na przykład mogą chcieć zapłacić określone poziomy SLA i naruszyć inne funkcje, aby to osiągnąć.

Twoi klienci są szaleni. 100% czasu sprawności jest niemożliwe bez względu na to, ile pieniędzy na to wydasz. Prosty i prosty - niemożliwy. Spójrz na Google, Amazon itp. Mają prawie nieskończoną ilość pieniędzy, które mogą rzucić na swoją infrastrukturę, a mimo to nadal mają przestoje. Musisz przekazać im tę wiadomość, a jeśli nadal będą nalegać, by stawiać rozsądne wymagania. Jeśli nie rozpoznają, że pewne przestoje są nieuniknione, to porzuć je.

To powiedziawszy, wydaje się, że masz mechanikę skalowania / dystrybucji samej aplikacji. Część sieciowa będzie musiała obejmować nadmiarowe łącza zwrotne do różnych dostawców usług internetowych, uzyskiwanie ASN i przydziału adresów IP, a także uzyskanie głębokiego dostępu do BGP i rzeczywistego sprzętu do routingu, aby przestrzeń adresów IP mogła w razie potrzeby przemieszczać się między dostawcami usług internetowych.

Jest to, oczywiście, bardzo zwięzła odpowiedź. Nie masz doświadczenia z aplikacjami wymagającymi takiego stopnia bezawaryjności, więc naprawdę musisz zaangażować profesjonalistę, jeśli chcesz zbliżyć się do mitycznego 100% czasu sprawności.

To zdecydowanie interesujące. Nie jestem pewien, czy chciałbym się zobowiązać umownie do 100% czasu sprawności, ale gdybym musiał, sądzę, że wyglądałoby to tak:

Rozpocznij od publicznego adresu IP modułu równoważenia obciążenia całkowicie poza siecią i zbuduj co najmniej dwa z nich, aby jeden mógł przejść do drugiego. Program taki jak Heatbeart może pomóc w automatycznym przełączaniu awaryjnym tych programów.

Lakier jest znany przede wszystkim jako rozwiązanie buforujące, ale ma również bardzo przyzwoite równoważenie obciążenia. Być może byłby to dobry wybór do obsługi równoważenia obciążenia. Można go skonfigurować tak, aby backendy 1 do n były opcjonalnie pogrupowane w reżyserach, które będą ładowały równowagę losowo lub w trybie round-robin. Lakier może być wystarczająco inteligentny, aby sprawdzić zdrowie każdego zaplecza i upuścić niezdrowe tylne końce z pętli, dopóki nie wróci online. Zaplecze nie musi być w tej samej sieci.

Jestem trochę zakochany w elastycznych adresach IP w Amazon EC2, więc prawdopodobnie zbudowałbym moduły równoważące obciążenie w EC2 w różnych regionach lub przynajmniej w różnych strefach dostępności w tym samym regionie. To dałoby ci opcję ręcznego (boskiego zabrania) rozkręcenia nowego modułu równoważenia obciążenia, gdybyś musiał i przeniesienie istniejącego adresu IP rekordu A do nowego pola.

Lakier nie może jednak zakończyć SSL, więc jeśli jest to problem, możesz zamiast tego spojrzeć na coś takiego jak Nginx.

Możesz mieć większość swoich backendów w sieci klientów i jeden lub więcej poza ich siecią. Wierzę, ale nie jestem w 100% pewien, że możesz ustalić priorytety backendów, aby maszyny klientów otrzymały priorytet, dopóki wszystkie nie staną się niezdrowe.

Od tego bym zaczął, gdybym miał to zadanie i niewątpliwie udoskonalił je w trakcie pracy.

Jednak, jak stwierdza @ErikA, to Internet i zawsze będą części sieci, które są poza twoją kontrolą. Będziesz chciał upewnić się, że Twój związek prawny wiąże cię tylko z rzeczami, które są pod twoją kontrolą.

Nie ma problemu - nieznacznie zmienione brzmienie umowy:

... gwarantuje nieprzerwany czas pracy wynoszący 100% (w zaokrągleniu do zera po przecinku)

Jeśli Facebook i Amazon nie mogą tego zrobić, to nie możesz. To takie proste.

Aby dodać odpowiedź oconnore z Hacker News

Nie rozumiem o co chodzi. Klient chce, abyś zaplanował katastrofę i nie są one zorientowane na matematykę, więc prośba o 100% prawdopodobieństwo wydaje się rozsądna. Inżynier, podobnie jak inżynierowie, pamiętał swój pierwszy dzień prob & stat 101, nie biorąc pod uwagę, że klient może tego nie zrobić. Mówiąc to, nie myślą o nuklearnej zimie, myślą o Fredu rzucającym kawę na serwer biurowy, awarii dysku lub awarii ISP. Ponadto możesz to osiągnąć. Dzięki geograficznie odrębnym, niezależnym serwerom samokontrolującym zasadniczo nie będziesz mieć przestojów. Przy 3 serwerach działających z niezależną (1) trzema 9 niezawodnością i dobrymi trybami przełączania awaryjnego, oczekiwane przestoje są krótsze niż sekunda rocznie (2). Nawet jeśli dzieje się to naraz, nadal znajdujesz się w rozsądnej umowie SLA dla połączeń internetowych, a zatem przestoje praktycznie nie istnieją. Klient nadal musi radzić sobie ze scenariuszami dnia zagłady, ale Godzilla wykluczony, będzie miał usługę, która jest „zawsze” gotowa.

(1) Serwer w LA jest dość niezależny od serwera w Bostonie, ale tak, rozumiem, że istnieje pewne skrzyżowanie związane z wojną nuklearną, chińskimi hakerami rozbijającymi sieć energetyczną itp. Nie sądzę, aby twój klient był zdenerwowany to.

(2) Tryb failover DNS może dodać kilka sekund. Nadal znajdujesz się w scenariuszu, w którym klient musi ponawiać żądanie raz w roku, co ponownie mieści się w rozsądnej umowie SLA i zwykle nie jest traktowane tak samo jak „przestój”. W przypadku awarii, która automatycznie przekierowuje do dostępnego węzła, może to być niezauważalne.

Jesteś proszony o coś niemożliwego.

Przejrzyj inne odpowiedzi tutaj, usiądź z klientem i wyjaśnij DLACZEGO jest to niemożliwe, i oceń ich odpowiedź.

Jeśli nadal nalegają na 100% dyspozycyjności, uprzejmie poinformuj ich, że nie da się tego zrobić, i odrzuć umowę. Nigdy nie sprostasz ich wymaganiom, a jeśli umowa nie będzie do końca do niczego, będziesz ukarany karami.

Cena odpowiednio, a następnie zastrzeż w umowie, że wszelkie przestoje po SLA zostaną zwrócone według stawki, którą płacą.

Zrobił to dostawca usług internetowych w mojej ostatniej pracy. Do wyboru mieliśmy „zwykłą” linię DSL z 99,9% czasu dostępności za 40 USD / mc lub połączone trio T1 z 99,99% czasu dostępności za 1100 USD / mc. Często dochodziło do przestojów trwających ponad 10 godzin miesięcznie, co spowodowało, że ich czas przestoju był znacznie niższy niż 40 USD / mc DSL, ale zwrócono nam tylko około 15 USD, ponieważ na tym kończy się stawka za godzinę * godzin. Wystąpili jak bandyci z umowy.

Jeśli wystawisz rachunki w wysokości 450 000 USD miesięcznie za 100% dyspozycyjności i osiągniesz tylko 99,999%, będziesz musiał zwrócić im kwotę 324 USD. Jestem gotów założyć się, że koszty infrastruktury sięgną 99,999% w okolicach 45 000 $ miesięcznie, zakładając w pełni rozproszone colo, łącza wysyłające na wielu poziomach 1, sprzęt fantazyjny itp.

Jeśli profesjonaliści zastanawiają się, czy dostępność na poziomie 99,999 procent jest kiedykolwiek praktyczną lub ekonomicznie opłacalną możliwością , dostępność na poziomie 99,9999% jest jeszcze mniej możliwa lub praktyczna. Nie mówiąc już o 100%.

Przez dłuższy czas nie osiągniesz celu 100% dostępności. Możesz uniknąć tego przez tydzień lub rok, ale wtedy coś się stanie i będziesz pociągnięty do odpowiedzialności. Wypadek może wahać się od uszkodzonej reputacji (obiecywałeś, że nie dostarczyłeś) po bankructwo od kar umownych.

Istnieją dwa rodzaje osób, które wymagają 100% czasu pracy:

1. Ludzie bez absolutnej wiedzy o komputerach, systemach komputerowych lub Internecie. *
2. Ci, którzy celowo robią z siebie dupę, albo testując twoją zdolność do odmowy (Google „test soku pomarańczowego”), albo próbują uzyskać jakąś umowę SLA w celu uniknięcia wypłaty później.

Moja rada, która wielokrotnie cierpiała na oba rodzaje klientów, nie powinna brać tego klienta. Niech doprowadzą kogoś innego do szaleństwa.

* Ta sama osoba może nie odczuwać zażenowania, pytając o podróż szybszą niż światło, Perpetual Motion, Cold Fusion itp.

Komunikowałbym się z klientem, aby ustalić z nim, co dokładnie oznacza 100% czasu sprawności. Możliwe, że tak naprawdę nie widzą różnicy między 99% dyspozycyjnością a 100% dyspozycyjnością. Dla większości osób (tj. Nie administratorów serwera) te dwie liczby są takie same.

100% czasu sprawności?

Oto czego potrzebujesz:

Wiele (i redundantnych) serwerów DNS, wskazujących na wiele witryn na całym świecie, z odpowiednimi umowami SLA z każdym dostawcą usług internetowych.

Upewnij się, że serwery DNS są poprawnie skonfigurowane, a TTL jest rozpoznawany skutecznie.

To jest łatwe. Umowa SLA Amazon EC2 wyraźnie stwierdza:

„Roczny odsetek przestojów” oblicza się, odejmując od 100% odsetek 5-minutowych okresów w roku serwisowym, w którym Amazon EC2 był w stanie „Region niedostępny”.

http://aws.amazon.com/ec2-sla/

Wystarczy zdefiniować „czas pracy”, aby był relatywny do całego pakietu usług, który faktycznie można utrzymać w 100% przez cały czas i nie powinno być problemów.

Warto również zauważyć, że celem umowy SLA jest określenie, jakie są twoje obowiązki i co się stanie, jeśli nie będziesz w stanie ich spełnić. Nie ma znaczenia, czy klient prosi o 3 lub 5 dziewiątek lub milion dziewiątek - pytanie brzmi, co otrzymają, kiedy / jeśli nie możesz dostarczyć. Oczywistą odpowiedzią jest zapewnienie elementu zamówienia zapewniającego 100% nieprzerwany czas pracy przy 5-krotności ceny, którą chcesz naliczyć, a następnie otrzymają 4x zwrot pieniędzy, jeśli nie uda Ci się osiągnąć tego celu. Możesz strzelić gola!

Zmiany DNS wymagają czasu tylko, jeśli są skonfigurowane tak, aby wymagały czasu. Możesz ustawić TTL na rekord na jedną sekundę - Twoim jedynym problemem będzie zapewnienie terminowej odpowiedzi na zapytania DNS oraz że serwery DNS będą w stanie poradzić sobie z tym poziomem zapytań.

Dokładnie tak działa GTM w F5 Big IP - DNS TTL jest domyślnie ustawiony na 30 sekund, a jeśli jeden członek klastra musi przejąć, DNS jest aktualizowany, a nowy adres IP jest przejmowany prawie natychmiast. Maksymalnie 30 sekund przerwy, ale taki jest przypadek na krawędzi, średnia wynosiłaby 15 sekund.

Wiesz, że to niemożliwe.

Bez wątpienia klient koncentruje się na widzeniu „100%”, więc najlepsze, co możesz zrobić, to obiecać 100%, z wyjątkiem [wszystkich uzasadnionych przyczyn, które nie są Twoją winą].

Chociaż wątpię, czy 100% jest możliwe, możesz rozważyć użycie platformy Azure (lub czegoś o podobnej umowie SLA). Co się dzieje:

Twoje serwery to maszyny wirtualne. Jeśli kiedykolwiek wystąpi problem sprzętowy na jednym serwerze, maszyna wirtualna zostanie przeniesiona na nową maszynę. Moduł równoważący obciążenie dba o przekierowanie, aby klient nie widział żadnych przestojów (chociaż nie jestem pewien, jak wpłynie to na stan sesji).

To powiedziawszy, nawet przy tym przełączeniu awaryjnym różnica między 99,999 a 100 graniczy z obłędem.

Musisz mieć pełną kontrolę nad następującymi czynnikami.
- Czynniki ludzkie, zarówno wewnętrzne, jak i zewnętrzne, zarówno złośliwość, jak i impotencja. Przykładem tego jest ktoś pchający coś do kodu produkcyjnego, który powoduje awarię serwera. Co gorsza, co z sabotażem?
- Problemy biznesowe. Co się stanie, jeśli Twój dostawca przestanie działać lub zapomni zapłacić rachunki za prąd lub po prostu zdecyduje się przestać wspierać infrastrukturę bez wystarczającego ostrzeżenia?
- Natura. Co jeśli niepowiązane tornada jednocześnie uderzą w wystarczającą liczbę centrów danych, aby pokonać pojemność tworzenia kopii zapasowych?
- Całkowicie wolne od błędów środowisko. Czy jesteś pewien, że nie istnieje przypadek krawędziowy z jakąkolwiek kontrolą systemu zewnętrznego lub systemu podstawowego, która się nie ujawniła, ale nadal mogłaby to zrobić w przyszłości?
- Nawet jeśli masz pełną kontrolę nad powyższymi czynnikami, czy jesteś pewien, że oprogramowanie / osoba monitorująca to nie przedstawi fałszywych negatywów podczas sprawdzania, czy twój system działa?

Szczerze mówiąc, 100% jest całkowicie szalone bez co najmniej wahania pod względem ataku hakerskiego. Najlepiej jest zrobić to, co robią Google i Amazon, ponieważ masz rozproszone geograficznie rozwiązanie hostingowe, w którym witryna i baza danych są replikowane na wielu serwerach w wielu lokalizacjach geograficznych. Zagwarantuje to wszystko w przypadku poważnej katastrofy, takiej jak przecięcie sieci internetowej do regionu (co zdarza się od czasu do czasu) lub coś niemal apokaliptycznego.

Umieściłbym klauzulę na takie przypadki (DDOS, przecięcie szkieletu Internetu, apokaliptyczny atak terrorystyczny lub wielka wojna itp.).

Oprócz tego zajrzyj do usług w chmurze Amazon S3 lub Rackspace. Zasadniczo konfiguracja chmury zapewnia nie tylko nadmiarowość w każdej lokalizacji, ale także skalowalność i rozkład geograficzny ruchu, a także możliwość przekierowywania wokół uszkodzonych obszarów geograficznych. Chociaż rozumiem, że dystrybucja geograficzna kosztuje więcej pieniędzy.

Chciałem tylko dodać kolejny głos do imprezy „ można (teoretycznie) zrobić”).

Nie podjąłbym się umowy, która by to sprecyzowała, bez względu na to, ile mi zapłacili, ale jako problem badawczy ma kilka interesujących rozwiązań. Nie jestem wystarczająco zaznajomiony z siecią, aby nakreślić etapy, ale wyobrażam sobie kombinację konfiguracji związanych z siecią + przełączanie awaryjne okablowania elektrycznego / sprzętowego + przełączanie awaryjne oprogramowania, być może w jakiejś konfiguracji lub innej pracy, by to zrobić.

Prawie zawsze istnieje jeden punkt awarii gdzieś w dowolnej konfiguracji, ale jeśli pracujesz wystarczająco ciężko, możesz przesunąć ten punkt awarii w coś, co można naprawić „na żywo” (tzn. Root dns spada, ale wartości są nadal buforowane wszędzie indziej, więc masz czas, aby to naprawić).

Znów nie mówię, że jest to wykonalne. Po prostu nie podobało mi się, że żadna odpowiedź nie odnosiła się do faktu, że nie jest to „wyjście” - to po prostu nie jest to coś, czego naprawdę chcą, jeśli się nad tym zastanowią.

Przemyśl swoją metodologię pomiaru dostępności, a następnie współpracuj z klientem, aby ustalić znaczące cele .

Jeśli prowadzisz dużą witrynę internetową, czas działania nie jest w ogóle przydatny. Jeśli porzucisz zapytania na 10 minut, kiedy Twoi klienci najbardziej ich potrzebują (szczyt ruchu), może to być bardziej szkodliwe dla firmy niż godzinna przerwa o 3 rano w niedzielę.

Czasami duże firmy internetowe mierzą dostępność lub niezawodność, korzystając z następujących wskaźników:

1. procent zapytań, na które odpowiedziano pomyślnie, bez błędu po stronie serwera (HTTP 500).
2. procent zapytań, na które odpowiedziano poniżej określonego docelowego opóźnienia .
3. odrzucone zapytania powinny się liczyć z Twoimi statystykami (patrz poniżej).

Dostępność nie powinna być mierzona za pomocą przykładowych sond, które mogą zgłaszać podmioty zewnętrzne, takie jak pingdom i pingability. Nie polegaj wyłącznie na tym. Jeśli chcesz to zrobić poprawnie, każde pojedyncze zapytanie powinno się liczyć . Zmierz swoją dostępność, patrząc na rzeczywisty, postrzegany sukces.

Najbardziej efektywnym sposobem jest zebranie dzienników lub statystyk z modułu równoważenia obciążenia i obliczenie dostępności na podstawie powyższych wskaźników.

Procent odrzuconych zapytań powinien również liczyć się do twoich statystyk. Może być rozliczany w tym samym segmencie co błędy po stronie serwera. Jeśli występują problemy z siecią lub inną infrastrukturą, taką jak DNS lub moduły równoważenia obciążenia, możesz użyć prostej matematyki, aby oszacować liczbę utraconych zapytań . Jeśli spodziewałeś się zapytań X dla tego dnia tygodnia, ale dostałeś X-1000, prawdopodobnie zrzuciłeś 1000 zapytań. Wyświetlaj ruch w postaci wykresów z zapytaniami na minutę (lub sekundę). Jeśli pojawią się luki, odrzucasz zapytania. Użyj podstawowej geometrii, aby zmierzyć obszar tych luk, co daje całkowitą liczbę odrzuconych zapytań.

Omów tę metodologię ze swoim klientem i wyjaśnij jego zalety. Ustaw linię bazową , mierząc ich bieżącą dostępność. Stanie się dla nich jasne, że 100% jest niemożliwym celem.

Następnie możesz podpisać umowę na podstawie ulepszeń na poziomie podstawowym. Powiedzmy, że jeśli obecnie osiągają 95% dostępności, możesz obiecać dziesięciokrotnie poprawić sytuację , osiągając 98,5%.

Uwaga: ten sposób pomiaru dostępności ma wady. Po pierwsze, samodzielne zbieranie dzienników, przetwarzanie i generowanie raportów może nie być trywialne, chyba że użyjesz do tego istniejących narzędzi. Po drugie, błędy aplikacji mogą zaszkodzić twojej dostępności. Jeśli aplikacja jest niskiej jakości, będzie wyświetlać więcej błędów. Rozwiązaniem tego jest rozważenie tylko 500 utworzonych przez moduł równoważenia obciążenia zamiast tych pochodzących z aplikacji.

W ten sposób sprawy mogą się nieco skomplikować, ale to tylko jeden krok poza pomiarem czasu bezawaryjnej pracy serwera .

Chociaż niektórzy zauważyli tutaj, że 100% jest szalony lub niemożliwy , jakoś nie trafili w sedno. Argumentowali, że powodem tego jest fakt, że nawet najlepsze firmy / usługi nie są w stanie tego osiągnąć.

Cóż, jest o wiele prostsze. Jest to matematycznie niemożliwe .

Wszystko ma prawdopodobieństwo. Może wystąpić jednoczesne trzęsienie ziemi we wszystkich lokalizacjach, w których przechowujesz swoje serwery, niszcząc je wszystkie. Prawdopodobnie jest to absurdalnie małe prawdopodobieństwo, ale nie jest równe 0. Wszyscy dostawcy Internetu mogliby spotkać się z jednoczesnym atakiem terrorystycznym / cyber. Znowu mało prawdopodobne, ale też nie zerowe. Cokolwiek podasz, możesz otrzymać niezerowy scenariusz prawdopodobieństwa, który obniża całą usługę. Ponieważ twój czas dostępności nie może być równy 100%.

Wybierz książkę o kontroli jakości produkcji za pomocą próbkowania statystycznego. Ogólna dyskusja w tej książce, na którą każdy menedżer byłby narażony podczas ogólnego kursu statystyki w college'u, dyktuje koszty przejścia od 1 usprawiedliwienia na tysiąc, do 1 na dziesięć tysięcy do 1 na milion do 1 na miliard rośnie wykładniczo. Zasadniczo zdolność do osiągnięcia 100% czasu sprawności kosztowałaby prawie nieograniczoną ilość funduszy, podobnie jak ilość paliwa potrzebna do popchnięcia obiektu do prędkości światła.

Z perspektywy inżynierii wydajności odrzuciłbym wymaganie zarówno jako niesprawdzalne, jak i nierozsądne, aby wyrażenie to było bardziej pragnieniem niż prawdziwym wymogiem. Dzięki zależnościom aplikacji, które istnieją poza aplikacjami sieciowymi, rozpoznawaniem nazw, routingiem, defektami wynikającymi z podstawowych komponentów architektonicznych lub narzędzi programistycznych, praktycznie niemożliwe staje się zapewnienie 100% dostępności bez przestojów.

Nie sądzę, że klient faktycznie prosi o 100% czasu pracy, a nawet 99,999% czasu pracy. Jeśli spojrzysz na to, co oni opisują, mówią o tym, gdzie powinni przerwać, jeśli meteor usunie swoje centrum danych na miejscu.

Jeśli wymaganiem jest, aby ludzie z zewnątrz nawet tego nie zauważyli, jak drastyczne to musi być? Czy zaakceptowanie prośby Ajax i ponowne wyświetlenie pokrętła przez 30 sekund użytkownikowi końcowemu jest dopuszczalne?

To są rzeczy, na których zależy klientowi. Gdyby klient myślał o precyzyjnych umowach SLA, wiedziałby wystarczająco dużo, aby wyrazić to jako 99,99 lub 99,999.

moje 2 centy. Byłem odpowiedzialny za bardzo popularną stronę internetową dla firmy z wróżbą-5, która zajmowałaby się reklamą super bowl. Musiałem poradzić sobie z ogromnymi skokami ruchu, a sposobem, w jaki to rozwiązałem, było skorzystanie z usługi takiej jak Akamai. Nie pracuję dla Akamai, ale uważam, że ich obsługa jest bardzo dobra. Posiadają własny, inteligentniejszy system DNS, który wie, że dany węzeł / host jest albo obciążony, albo nie działa i może odpowiednio kierować ruchem.

Ciekawą rzeczą w ich usługach było to, że tak naprawdę nie musiałem robić nic bardzo skomplikowanego, aby replikować zawartość na serwerach we własnym centrum danych do ich centrum danych. Ponadto wiem, że dzięki współpracy z nimi bardzo intensywnie korzystali z serwerów Apache HTTP.

Chociaż nie ma 100% czasu sprawności, możesz rozważyć takie opcje rozpraszania treści na całym świecie. Jak rozumiałem, Akamai miał również możliwość lokalizowania ruchu, co oznacza, że ​​gdybym był w Michigan, dostałem zawartość z serwera Michigan / Chicago, a jeśli byłem w Kalifornii, podobno dostałem zawartość z serwera z siedzibą w Kalifornii.

Zamiast zewnętrznego przełączania awaryjnego po prostu uruchom aplikację z dwóch lokalizacji jednocześnie, wewnętrzną i zewnętrzną. I zsynchronizuj dwie bazy danych ... Wtedy jeśli wewnętrzne ulegnie awarii, wewnętrzni ludzie nadal będą mogli pracować, a zewnętrzni ludzie będą nadal mogli korzystać z aplikacji. Gdy wewnętrzny wróci do trybu online, zsynchronizuj zmiany. Możesz mieć dwa wpisy DNS dla jednej nazwy domeny lub nawet router sieciowy z okrągłym robinem.

W przypadku witryn hostowanych zewnętrznie najbliżej 100% czasu działania to hosting Twojej witryny w Google App Engine i korzystanie z magazynu danych o wysokiej replikacji (HRD) , który automatycznie replikuje dane w co najmniej trzech centrach danych w czasie rzeczywistym. Podobnie serwery frontonu App Engine są automatycznie skalowane / replikowane.

Jednak nawet przy wszystkich zasobach Google i najbardziej zaawansowanej platformie na świecie gwarancja dostępności usługi App Engine SLA wynosi tylko „99,95% czasu w dowolnym miesiącu kalendarzowym”.

Prosty i bezpośredni: Anycast

http://en.wikipedia.org/wiki/Anycast

Tego właśnie używa CloudFlare, Google i każdej innej dużej firmy, aby wykonywać zbędne, niewielkie opóźnienia, międzykontynentalne przełączanie awaryjne / równoważenie.

Pamiętaj również, że nie można mieć 100% czasu bezczynności, a koszty przejścia z 99,999% do 99,9999% są DUŻO większe.