Obecnie mamy klasyczną aplikację n-tier: DB / web service / front-end. Ma inne komponenty, ale jest to podstawowy układ.

Chcemy poprawić dostępność aplikacji z 3 głównych powodów:

1. Nasz host czasami doświadcza awarii (tak jak wszyscy), i chcemy zminimalizować wpływ na naszych klientów, więc na przykład włączyliby centrum danych B, jeśli centrum danych A nie działa.
2. Gdy aktualizujemy wersję, zamykamy witrynę w celu konserwacji i zwykle zajmuje to kilka godzin (skrypty migracji itp.). Chcielibyśmy, aby użytkownicy mieli bardziej płynne przejście z jak najmniejszym czasem przestoju (używają serwera B podczas aktualizacji serwera A).
3. Opcjonalnie, nasi klienci są zlokalizowani na całym świecie i chcemy, aby mieli jak najlepsze wrażenia pomimo ich potencjalnie złych kontaktów (każdy, kto pracował z indyjskimi programistami, powinien wiedzieć, co mam na myśli). Idealnie byłoby, gdybyśmy mogli podłączyć serwer do ich biura (lub skorzystać z centrum danych w pobliżu ich miasta), i to bez problemu zintegrowałoby się z naszą architekturą.

Nie potrzebujemy zdalnie 99% dostępności, nawet 95%. To aplikacja do zarządzania dokumentami. Nikogo to nie obchodzi. Ponieważ jednak migracje mogą zająć trochę czasu, a na całym świecie są klienci, czasami uniemożliwiamy klientowi pracę przez większość dnia.

Jeśli chodzi o część SQL, mimo że nie ma „odpowiednich” baz danych, wiemy o możliwościach SQL : replikacja, tworzenie kopii lustrzanych itp. Po stronie bazy danych dość łatwo jest znaleźć na to zasoby. Co jest trudniejsze, to wszystko inne: przechowywanie sesji, kodu itp. Jeśli mój serwer internetowy ulegnie awarii, skąd mój interfejs użytkownika wie, że musi się przełączyć? Jak trwają moje sesje na serwerach?

Niestety, nikt z nas nie ma doświadczenia w tej dziedzinie i nawet nie wiemy, od czego zacząć. Czy istnieją na to najlepsze praktyki? Wzorce projektowe? Biblioteki (które powinny być darmowe, ponieważ nie mamy pieniędzy)?

Używamy ASP.Net i SQL Server, z usługą WCF pośrodku. Mamy wiele usług Windows, ale nie są one krytyczne dla misji i zakładam, że metody radzenia sobie z witryną będą miały zastosowanie do tych usług.

Rozumiem, że większość platform chmurowych zapewnia wbudowany system do tego, ale hosting w chmurze jest nie do przyjęcia ze względu na naszego sysadmina, który chce zarządzać wszystkim sam, a nie polegać na nikim.

Musisz wyjaśnić, jakiego rodzaju wysokiej dostępności szukasz. Są wysoce dostępne aplikacje, które uruchamiam, które muszą działać w 95% przypadków. Są inne, które muszą działać na poziomie 99%. Mogę wymyślić scenariusze życia lub śmierci, które wymagają 100% czasu sprawności. Tylko te trzy mają drastycznie różne podejścia i koszty.

Zgadywanie w oparciu o twoje potrzeby i SLA czasu pracy 95-99%:

• W przypadku większości zmian migracja bazy danych powinna być możliwa w czasie rzeczywistym. Ćwicz ewolucyjne projektowanie baz danych . W przypadku zmian, które wymagają bardziej inwazyjnego zachowania, masz kilka opcji. Jednym z nich jest przestój. Jeśli to możliwe, uruchomienie usługi w trybie tylko do odczytu może działać. Aby uzyskać pełną funkcjonalność, od jakiegoś czasu chciałem wypróbować ScaleArc. Wygląda jak naprawdę sprytne narzędzie do skalowania i odporności w świecie SQL Server.
• Umieszczenie serwerów w witrynach klientów jest receptą na niemożliwą do opanowania katastrofę, chyba że masz światowej klasy strategie wdrażania (których, na podstawie opisu migracji, jeszcze nie masz). Nie wypychaj usług chmurowych z wyprzedzeniem, ponieważ masz problemy z wydajnością. Rozwiązuj problemy z wydajnością od czasu do czasu, nie będziesz musiał radzić sobie z kosztowniejszymi na drodze.
• Twój serwer stanu powinien być pewnego rodzaju bazą danych. Postępuj zgodnie z ich wytycznymi dotyczącymi HA. Możesz do tego użyć programu SQL Server, ponieważ już go masz.
• Mówiąc o bazach danych, replikacja nie włącza HA. W rzeczywistości replikacja SQL spowoduje bóle głowy na każdym kroku (mówiąc z doświadczenia z wieloma scenariuszami replikacji węzłów). Kopia lustrzana może działać, ale ostatnio pamiętam, że klastrowanie SQL zajmuje od 1 do 5 minut, aby przełączyć się na nowy serwer. Słyszałem dobre rzeczy o AlwaysOn, ale nadal jestem podejrzliwy, biorąc pod uwagę osiągnięcia Microsoft. Coś takiego jak ScaleArc może tu być bardziej pomocne.
• Twój serwer internetowy powinien być bezstanowy. Zakręć trzy lub cztery i umieść je za modułem równoważenia obciążenia. To rozwiązuje Twoje problemy z bezczynnością. Jak wspominał wcześniej Frederik, w ten sposób można również przeprowadzać wdrożenia cykliczne.
• Twoja usługa internetowa powinna być prawdopodobnie bezpaństwowa. Jeśli nie, sprawdź, czy możesz rozbić go na bezstanowe i stanowe części. Umieszczenie wielu jego instancji za tym samym modułem równoważenia obciążenia ponownie rozwiązuje problemy związane z czasem pracy i umożliwia bardziej zainteresowane scenariusze wdrażania (np. Wdrożenia niebieskie / zielone).

W przeciwieństwie do Frederika, nie będę nazywał waszej chmury paranoją nieuzasadnioną. To zależy od wymagań dotyczących czasu pracy. Można sobie wyobrazić, że usługa musiałaby działać w wielu centrach danych obsługiwanych przez różnych dostawców w różnych krajach ze względu na nadmiarowość. Biorąc jednak pod uwagę twój obecny stan, zgodzę się, że AWS, Azure lub podobne są prawdopodobnie bezpiecznymi zakładami dla Twojej firmy.

Uzyskiwanie poziomu HA na poziomie sieci i aplikacji:

1. Najlepiej jest rozdzielić dowolny stan, w tym stan sesji, na systemy stanów współużytkowanych, takie jak baza danych lub serwer stanów sesji w pamięci. W zależności od projektu aplikacji może to powodować problemy z wydajnością z powodu dodatkowego opóźnienia w uzyskiwaniu dużej ilości stanu.

2. Każda witryna sieci Web i warstwa aplikacji powinny mieć przed sobą niezależny moduł równoważenia obciążenia. NGINX załatwi sprawę, ale IIS też może to zrobić (ARR).

3. Jeśli pojedyncza baza danych nie jest w stanie obsłużyć obciążenia, skorzystaj z partycjonowania stanu sesji (lub dzielenia lub spójnego mieszania), aby skierować określone żądanie do konkretnego pola bazy danych.

Jeśli faktoryzacja stanu jest zbyt trudna, możesz przejść z powinowactwem serwera do równoważenia obciążenia (tzn. Użytkownicy są konsekwentnie kierowani do tego samego urządzenia, często na podstawie plików cookie). Nie jest tak wysoce dostępny jak bezstanowe podejście do robota okrągłego, ponieważ wyłączenie skrzynki wpłynie na wszystkich użytkowników i stan na tym polu, ale pokonuje całkowite wyłączenie (zależne od przypadku użycia).

Po stronie aktualizacji:

1. Zaprojektuj skrypty bazy danych w taki sposób, aby można było przeprowadzać aktualizacje bazy danych podczas działania systemu, innymi słowy zachowując zgodność wsteczną. Wzorzec, który działa dobrze, to „rozwiń, a następnie skurcz” -> dokonuj tylko addytywnych, zgodnych wstecz zmian, ale usuwaj zależności od pól (itp.), Których chcesz się pozbyć; następnie zaktualizuj wszystkich klientów bazy danych do najnowszej wersji; następnie wykonaj kolejną aktualizację db, aby pozbyć się starych pól (itp.) w bazie danych. Może to być powolny proces, jeśli masz dużą bazę danych i musisz uważać, aby nie obniżyć wydajności systemu.

2. Uaktualnianie warstwy aplikacji: ponieważ nie korzystasz ze środowiska chmurowego, zalecamy postępowanie według kanaryjskiego schematu wdrażania: wykonaj aktualizację stopniową swoich skrzynek internetowych i warstwy środkowej. Jeśli wdrożenie nie powiedzie się, wyjmij skrzynkę z modułu równoważenia obciążenia, tak jak gdyby to się nie powiodło.

Słowo ostrzeżenia: ewolucja systemu, który nie został zaprojektowany dla HA, może być długim i kosztownym procesem. Po drodze będziesz musiał dokonać kompromisu (koszt vs. wysiłek, aby osiągnąć określony poziom dostępności)

Twoja paranoja w chmurze jest nieuzasadniona - dostawcy tacy jak AWS w połączeniu z dobrymi praktykami z twojej strony mogą kontrolować / ograniczać większość ryzyka - zajrzyj na ich stronę zgodności, aby dowiedzieć się, jakie przepisy są zgodne z: https: // aws .amazon.com / compliance /

TL; DR: Zbuduj redundantne, modułowe; test dostępności; uważnie monitoruj.

Po uświadomieniu sobie, że próba wyciśnięcia jakiegokolwiek wyjaśnienia może potrwać bardzo długo, więc zapiszę wszystkie obserwacje, które poczyniłem.

Kwestionowanie przesłanki

System chmurowy to panaceum

Nawet jeśli chcesz w pełni korzystać z chmury, z najlepszym dostawcą chmury, nadal będziesz musiał zaprojektować swoją aplikację pod kątem odporności. AWS może zastąpić maszynę wirtualną, ale aplikacja powinna być w stanie zrestartować się, jeśli pozostanie w trakcie obliczeń.

Nie chcemy używać systemu w chmurze z powodu x / y / z

Jeśli nie jesteś bardzo dużą organizacją, lepiej korzystać z systemów chmurowych. Top 3 systemy chmurowe (AWS, MSFT, Google) zatrudniają tysiące inżynierów, którzy zapewniają obiecane umowy SLA i łatwy w obsłudze pulpit nawigacyjny. To naprawdę dobra okazja, aby użyć ich zamiast wydać ani grosza na to w domu.

Problemy w określaniu zakresu i projektowaniu

Zdefiniowanie, określenie ilościowe, a następnie ciągły pomiar dostępności usługi jest większym wyzwaniem niż pisanie rozwiązania problemów z dostępnością.

Zdefiniowanie i zmierzenie „dostępności” jest trudniejsze niż oczekiwano

Wielu interesariuszy ma odmienne zdanie na temat dostępności, a to, co może się zdarzyć, to definicja preferowana przez osobę z najwyższą pensją przewyższa inną definicję. Jest to czasami poprawna definicja, ale często ekosystem nie opiera się na pomiarze tego samego, ponieważ ta idealna definicja jest bardzo trudna do zmierzenia, nie mówiąc już o monitorowaniu w czasie rzeczywistym. Jeśli masz definicję dostępności, której nie można monitorować w czasie rzeczywistym, znajdziesz swój własny projekt podobny do siebie z niesamowitymi podobieństwami. Trzymaj się czegoś, co ma sens i czegoś, co można łatwo monitorować.

Ludzie nie doceniają złożoności zawsze dostępnego systemu.

Aby zająć się słoniem w pokoju, powiem tak: „Żaden system wielu komputerów nie jest w 100% dostępny, może w przyszłości, ale nie przy obecnej technologii”. Tutaj przez obecną technologię mam na myśli naszą niemożność wysyłania sygnałów szybciej niż prędkość światła i tym podobne. Wszyscy inżynierowie comp-sci, którzy są godni swojej wiedzy, znają ograniczenia przetwarzania rozproszonego , a większość z nich nie wspomina o tym na spotkaniach, obawiając się, że będą wyglądać jak nooby. Aby zrekompensować wszystkim, którzy nie wspominają o ograniczeniach przetwarzania rozproszonego , powiem, że jest to skomplikowane, ale nie zawsze ufają komputerom .

Ludzie przeceniają swoje możliwości inżyniera

Niestety dostępność należy do kategorii, w której nie wiesz, czego chcesz, ale wiesz, czego nie chcesz. Jest to nieco trudniejsze, jeśli chodzi o kategorię „Poznaj potrzeby”, taką jak interfejs użytkownika. Wymaga odrobiny doświadczenia i dużo czytania, aby uczyć się na doświadczeniach innych i jeszcze więcej.

Budowanie dostępnego systemu od podstaw

Upewnij się, że będziesz ewangelizował dla każdego zespołu architektury i projektantów o właściwym priorytecie dostępności jako wymaganiu systemowym.

Atrybuty systemu zwiększające dostępność

Wykazano, że następujące cechy systemu przyczyniły się do dostępności systemu:

Nadmiar

Oto niektóre przykłady tego, że nigdy nie ma tylko jednej maszyny wirtualnej za VIP-em ani nigdy nie przechowuje tylko jednej kopii danych. Są to pytania, które dobry IAAS ułatwi ci do rozwiązania, ale nadal będziesz musiał podjąć te decyzje.

Modułowość

Modułowy REST jest lepszy niż monolityczny SOA. Jeszcze modułowy microservice jest rzeczywiście bardziej dostępne niż zwykłe HATEOS REST . Rozumowanie można znaleźć w dyskusji dotyczącej wydajności w następnej sekcji. Jeśli wykonujesz przetwarzanie wsadowe, lepiej jest przetwarzanie wsadowe w rozsądnej partii 10s w porównaniu do przetwarzania partii 1 000 000.

Odporność

"I am always angry"
                    - Hulk

Odporny system jest zawsze gotowy do przywrócenia. Ta odporność dotyczy instancji takich jak potwierdzanie ACK zapisu tylko po zapisaniu na dysku RAID i ewentualnie w co najmniej dwóch centrach danych. Innym najnowszym trendem jest stosowanie bezkonfliktowych struktur danych , w których struktura danych przyjmuje odpowiedzialność za rozwiązywanie konfliktów, gdy są prezentowane w dwóch różnych wersjach. System nie może być odporny na później, należy go przewidzieć i wbudować. Awaria jest gwarantowana przez długi czas, dlatego zawsze powinniśmy być przygotowani z planem powrotu do zdrowia.

Szlak dziennika

Jest to technicznie podtyp Odporności, ale bardzo wyjątkowy, ponieważ posiada wszystkie możliwości. Pomimo dołożenia wszelkich starań możemy nie być w stanie przewidzieć wzorca niedostępności. Jeśli to możliwe, zachowaj wystarczającą liczbę rejestrów działań systemu, aby móc odtwarzać zdarzenia systemowe. Pozwoli to, przy wielkich kosztach ręcznych, na wyjście z nieprzewidzianych sytuacji.

Atrybuty dostępności

Niewyczerpująca lista atrybutów „dostępność” na początku umysłu: Dla celów dyskusji załóżmy, że pytanie, które zadaje użytkownik, brzmi: „Ile przedmiotów mam w koszyku?”.

Poprawność

Czy musisz udzielić możliwie najdokładniejszej odpowiedzi, czy też możesz popełniać błędy? Tylko w celach informacyjnych, kiedy wypłacasz pieniądze z bankomatu, nie ma gwarancji, że są poprawne. Jeśli bank stwierdzi, że popełnił błąd, być może cofniesz transakcje. Jeśli twój system generuje liczby pierwsze, zgaduję, że możesz chcieć przez cały czas właściwych odpowiedzi.

Wydajność

Pomiń ten punkt, jeśli zawsze odpowiedziałeś poprawnie na poprzednie pytanie tematyczne. Czasami odpowiedź na pytania nie musi być precyzyjna, np. Ilu przyjaciół mam teraz na Facebooku? Oczekuje się jednak, że odpowiedź będzie cały czas na boisku +/- 1. Kiedy osiągasz oczekiwany wynik, wydajność wynosi 100.

Konsystencja

Twoja odpowiedź może być poprawna w pewnym momencie, ale zanim światło opuści ekran i wejdzie do siatkówki obserwatora, wszystko może się zmienić. Czy to sprawia, że ​​twoja odpowiedź jest zła? Nie, to tylko powoduje, że jest to niespójne. Większość aplikacji jest ostatecznie spójna, ale sztuczka polega na określeniu, jaki rodzaj modelu spójności ma zapewnić twoja aplikacja. Przez przypadek twoja aplikacja może działać na jednym komputerze, możesz pominąć tę cudowną lekturę na temat twierdzenia CAP .

Koszt

Wiele zależy od tego, jaki łączny wpływ efektów krótkoterminowych (utrata dochodów) i efektów długoterminowych (zła reputacja, utrzymanie klientów). W zależności od rodzaju klienta (płatny / bezpłatny, powtarzalny / niepowtarzalny, w niewoli) i dostępności zasobów należy wprowadzić różne poziomy gwarancji dostępności.

W kierunku poprawy dostępności istniejącego systemu

Zarządzanie operacyjne poszczególnymi maszynami i siecią jest tak złożone, że zakładam, że pozostawiłeś ją dostawcy usług w chmurze lub jesteś już wystarczająco ekspertem, aby wiedzieć, co robisz. Dotknę innych tematów w miarę dostępności. Dla długoterminowej strategii Zdefiniuj-Zmierz-Analizuj-Kontrola to niebiańskie połączenie, coś, co sam widziałem.

1. Zdefiniuj „dostępność” dla swoich interesariuszy
2. Jak zmierzysz to, co zdefiniowałeś
3. Analiza przyczyn źródłowych w celu zidentyfikowania wąskich gardeł
4. Zadania dotyczące ulepszeń
5. Ciągłe monitorowanie ( kontrola ) systemu

Przyczyny niedostępności

Ponieważ zgodziliśmy się, że zarządzanie operacyjne, które obejmie zarządzanie infrastrukturą fizyczną, powinno być wykonywane przez profesjonalistów, w związku z kompletnością dotknę innych przyczyn niedostępności. Dostępność IMO powinna również obejmować brak oczekiwanego zachowania, co oznacza, że ​​jeśli użytkownikowi nie zostanie przedstawione oczekiwane doświadczenie, coś jest niedostępne. Mając na uwadze tę szeroką definicję, następujące czynniki mogą spowodować niedostępność: - Błędy w kodzie - Przypadki bezpieczeństwa - Problemy z wydajnością