Oświadczenie

Zawarte tu informacje stanowią ogólne wskazówki dotyczące użytkowania naszych produktów. Służą jedynie celom informacyjnym i nie mogą być dołączane do żadnego kontraktu. Nie stanowią żadnego zobowiązania do dostarczenia jakichkolwiek materiałów, kodu lub funkcjonalności i nie należy się na nich opierać przy podejmowaniu decyzji o zakupie. Opracowanie, wydanie, terminy i ceny związane z wszelkimi opisanymi funkcjami produktów Oracle mogą ulegać zmianom i są zależne wyłącznie od decyzji Oracle Corporation.

W tym dokumencie FAQ są zawarte odpowiedzi na często zadawane pytania, w jaki sposób Oracle zapewnia odporność i stałą dostępność głównych usług infrastrukturalnych oraz platformy hostingowej. Odpowiedzi te mogą zainteresować klientów Oracle Cloud z kilku powodów:

  • Pomagają klientom zachować właściwą staranność podczas uzyskiwania dostępu do platformy hostingowej i usług Oracle.
  • W wielu odpowiedziach zostały omówione problemy i rozwiązania fundamentalne dla wszystkich systemów chmurowych, dzięki czemu klienci mogą się dowiedzieć więcej o architekturze i konstrukcji systemów, które chcą tworzyć w chmurze.

Odporność i stała dostępność usług infrastrukturalnych oraz platformy Oracle Cloud — FAQ

Czy Oracle rozróżnia klasy usług, takie jak usługi krytyczne, usługi stale dostępne i usługi z jedną lokalizacją?

Nie dokonujemy takiego rozróżnienia. Zamiast tego klasyfikujemy nasze usługi według poziomu zależności, zakresu dostępu oraz stosunku płaszczyzny danych do płaszczyzny sterującej. Kategorie te zostały zaprojektowane tak, aby zapewniały rozsądny kompromis między dostępnością, trwałością, wydajnością i wygodą użytkowania.

Poziomy zależności

Poziomy te można traktować jako warstwy w schemacie blokowym architektury. Każda warstwa może zależeć tylko od warstw znajdujących się poniżej niej.

Od dołu do góry:

  • Usługi podstawowe: Usługi te tworzą fundament Oracle Cloud Infrastructure. Należą do nich następujące usługi: Identity and Access Management (IAM), Key Management, Networking, Compute, Block Volumes, Object Storage, Telemetry oraz kilka współużytkowanych usług wewnętrznych. Są zaprojektowane tak, aby cechowały je minimalne zależności, nawet wzajemne. (Szczegółowe informacje o zależnościach są podane dalej w tym dokumencie).
  • IaaS: Ta warstwa, opierająca się na warstwie usług podstawowych, zapewnia więcej funkcji poziomu infrastrukturalnego. Do usług zawartych w tej warstwie należą: File Storage, Database oraz Container Engine for Kubernetes.
  • SaaS: Ta warstwa, bazująca warstwach niższych poziomów, udostępnia oprogramowanie w postaci usług.
Zakres dostępności

W celu zapewnienia zakładanej dostępności i trwałości usługi jest dla niej wybierany jeden z następujących zakresów dostępności:

  • Domena dostępności (lokalne): Każda domena dostępności zawiera jedną niezależną instancję usługi. Usługi takie zapewniają dużą trwałość składowanych danych poprzez użycie replikacji synchronicznej obejmującej repliki w tej samej domenie dostępności (więcej szczegółów jest dostępnych dalej w tym dokumencie, w części dotyczącej domen awaryjnych). Usługi te, w zależności od ich charakteru, tolerują wyłączenie jednej trzeciej lub większej części infrastruktury w domenie dostępności. Usługi zlokalizowane w domenie dostępności osiągają ten poziom odporności na awarie poprzez użycie w domenie dostępności dwóch typów logicznych centrów danych: grup logicznych chroniących przed awariami oraz izolujących działania. Więcej szczegółów jest dostępnych dalej w tym dokumencie, w części dotyczącej domen awaryjnych i komórek usługi. Co istotne, usługi te mogą działać w zwykły sposób, nawet jeśli dana domena dostępności nie będzie mogła się komunikować z innymi domenami dostępności. Wskutek tego usługi są odporne na utratę innych domen dostępności lub całkowitą awarię sieci WAN w regionie.
  • Wiele domen dostępności (regionalne): Każdy region z wieloma domenami dostępności zawiera jedną niezależną instancję usługi ze składnikami zlokalizowanymi w każdej z występujących w nim domen dostępności. Usługi te zapewniają dużą trwałość składowanych danych poprzez użycie replikacji synchronicznej do wielu domen dostępności znajdujących się w tym samym regionie. Ponadto usługi te tolerują wyłączenie dowolnej domeny dostępności w danym regionie lub niemożność skomunikowania się.
  • Jedna domena dostępności (regionalne): Jeśli w regionie występuje tylko jedna domena dostępności, to zauważalne cechy usługi regionalnej są identyczne z lokalną usługą opisaną wcześniej. Różnica między usługą lokalną z domeną dostępności a usługą regionalną z jedną domeną dostępności staje się widoczna dopiero wtedy, gdy do regionu z jedną usługą dostępności zostaną dodane kolejne domeny dostępności (jedna lub większa ich liczba). Gdy to nastąpi, każda usługa regionalna zostanie automatycznie rozszerzona, tak aby mogła korzystać z nowych domen dostępności, pozostając jednocześnie jedną instancją usługi. Na przykład płaszczyzna danych usługi Object Storage ulegnie rozszerzeniu, tak aby dodatkowe domeny dostępności przyczyniały się do zwiększenia trwałości istniejących danych. Natomiast w przypadku usług lokalnych z domeną dostępności, każda dodana domena dostępności uzyskuje swoją nową, własną instancję usługi lokalnej.
  • Rozdzielone na regiony: Podstawową zasadą obowiązującą w Oracle Cloud Infrastructure jest zapewnienie możliwie maksymalnej niezależności poszczególnych regionów. Określenie możliwie maksymalnej jest użyte, ponieważ regiony muszą współdzielić przynajmniej część infrastruktury, na przykład łączącą je sieć szkieletową. Dlatego nie korzystamy z mechanizmów ścisłego sprzężenia regionów (na przykład wymaganych do zapewnienia przezroczystej wysokiej dostępności czy przejmowania awaryjnego), które to mechanizmy mogłyby być przyczyną problemów dotykających kilka regionów jednocześnie. Zamiast tego udostępniamy dwa mechanizmy rozdzielania usług między regiony, stosując sprzężenie luźne:
    • Odtwarzanie awaryjne (DR): Umożliwienie naszym klientom konstruowania systemów o cechach DR stanowi fundament naszego podejścia do środowiska chmurowego i inwestycji w tę technologię. Kilka podstawowych usług już oferuje mechanizmy DR — na przykład usługa Block Volumes zapewnia tworzenie kopii zapasowych przechowywanych w różnych regionach, a usługa Object Storage umożliwia sporządzenie kopii między regionami. W planach rozwoju wszystkich naszych usług jest uwzględniana funkcja DR.
    • Subskrypcje międzyregionalne: Obecnie oferujemy subskrypcje międzyregionalne tylko dla danych IAM. Konceptualnie dane IAM mają zasięg globalny. Klienci mogą przystępować do zestawu regionów (subskrybować je), a my automatycznie będzie powielać odpowiednie dane IAM i aktualizacje w określonych regionach. W celu uniknięcia ścisłego sprzężenia replikacja jest asynchroniczna i możliwie spójna. Klienci mogą dokonywać modyfikacji danych w swoim podstawowym regionie, który sami wyznaczą. Jeśli bieżący region podstawowy stanie się niedostępny lub nieprzydatny z jakiegoś powodu, może zostać wyznaczony inny region.
Płaszczyzna sterująca a płaszczyzna danych

Płaszczyzna danych usługi to zbiór interfejsów i składników służących do przetwarzania danych, zapewniających funkcjonalność usługi przewidzianej do użycia przez aplikacje. Na przykład płaszczyzna przetwarzania danych sieci VCN (Virtual Cloud Network) zawiera system przetwarzania pakietów sieciowych, wirtualizowane routery i bramy, podczas gdy płaszczyzna usługi Block Volumes zawiera implementację protokołu iSCSI oraz replikowany, odporny na awarie system składowania danych blokowych.

Płaszczyzna sterująca usługi składa się z zestawu interfejsów API oraz składników odpowiedzialnych za następujące zadania:

  • Obsługa zleceń klientów w zakresie udostępniania, zmiany konfiguracji, skalowania w dół lub w górę bądź trwałego kończenia zasobów
  • Automatyczne stosowanie poprawek dla obszernych rozwiązań w sposób szybki i bezpieczny
  • Wykrywanie zasobów, które uległy awarii, są zdezaktualizowane lub zostały błędnie skonfigurowane
  • Wykonywanie automatycznych napraw lub przywoływanie osób-operatorów w celu udzielenia pomocy
  • Współpraca z innymi płaszczyznami sterującymi (na przykład usługi Compute, VCN i Block Storage są sprzężone podczas uruchamiania instancji)
  • Zarządzanie niewykorzystanymi zdolnościami lub pojemnością
  • Koordynacja działań w powiązaniu z czynnościami wykonywanymi przez ludzi, na przykład obejmująca dodanie nowego sprzętu lub fizyczną naprawę i konserwację
  • Zapewnianie wglądu operacyjnego i kontroli
 
 

W jaki sposób Oracle zapewnia odporność i stałą dostępność usług?

We wszystkich typach usług stosujemy ten sam zbiór zasad inżynierskich zapewniających odporność i dostępność, ponieważ podstawowe wyzwania związane z budową skalowalnych, rozproszonych systemów w pełni odpornych na awarie są identyczne bez względu na typ usługi.

Aby można było osiągnąć odporność i stałą dostępność, trzeba zrozumieć wszystkie przyczyny pogorszenia wydajności wskutek braku dostępności oraz radzić sobie z nieobsługiwanymi awariami w systemach chmurowych. Istnieje wiele takich przyczyn i dlatego grupujemy je w kategorie, zgodnie z ich podstawowym charakterem.

Tradycyjnie analiza dostępności systemów IT klasy Enterprise koncentruje się na kategorii awaria sprzętu. W przypadku systemów chmurowych awaria sprzętu jest stosunkowo mniej istotnym, dobrze znanym problemem. Obecnie bardzo łatwo jest unikać większości pojedynczych punktów awarii sprzętowej lub ograniczać ich skutki. Na przykład szafy sprzętowe mogą mieć zdublowane zasilanie i powiązane jednostki zasilające, a wiele składników można wymieniać „na żywo”. Awarie sprzętowe na dużą skalę i związane z tym straty są oczywiście możliwe — na przykład w przypadku klęsk żywiołowych. Jak wynika jedna z naszego doświadczenia i raportów innych dostawców, awaria lub utrata całego centrum danych zdarza się niezwykle rzadko, zwłaszcza w porównaniu z innymi przyczynami niedostępności. Skutkom awarii sprzętowych na dużą skalę trzeba zapobiegać (na przykład stosując mechanizmy odtwarzania awaryjnego), lecz tego typu awarie zdecydowanie nie są dominującym problemem mającym wpływ na zapewnienie dostępności.

W systemach chmurowych najczęstszymi przyczynami niedostępności są:

  1. Błędy oprogramowania
  2. Błędy konfiguracji
  3. Błędy popełniane przez operatorów (ludzi)
    Uwaga: Z doświadczeń dostawców wynika, że te trzy postaci błędów ludzkich stanowią do tej pory najczęstsze przyczyny niedostępności. Mimo że ich częstotliwość można ograniczyć — stosując odpowiednie narzędzia, automatyzację i szkolenia — lecz nie można ich jednak wyeliminować. Z tego powodu muszą stanowić przedmiot szczególnej troski podczas określania architektury, projektowania i implementowania systemu.
  4. Nieakceptowalne pogorszenia wydajności (zbyt duże opóźnienia lub ograniczenie przepustowości) z dowolnego powodu, w tym następujących:
    • „Hałaśliwi sąsiedzi” w środowisku z wieloma dzierżawcami (nieskuteczne działanie mechanizmów QoS)
    • Niezdolność skutecznego odrzucenia przeciążeń (przypadkowych lub spowodowanych działaniami szkodliwymi) z jednoczesnym zapewnieniem możliwości wykonywania właściwej pracy
    • Rozproszone przeciążenie pamięci wirtualnej, nawała komunikatów, nawała ponowień i inne kosztowne „nowoczesne” interakcje
    • Puste pamięci podręczne po wyłączeniu/włączeniu zasilania, zwłaszcza równoległym, obejmującym wiele systemów
    • Obciążenia związane ze skalowaniem systemu (na przykład podczas zmiany podziału na partycje shard)
  5. Niezdolność ograniczenia „promienia rażenia”, czyli liczby klientów (i systemów), na których miały wpływ którekolwiek z wcześniej wymienionych problemów

Wyzwania te są uniwersalne — stanowią część „praw fizyki” obowiązujących dla rozproszonych systemów o skali chmury.

W zakresie każdej z wymienionych kategorii stosujemy wypróbowane strategie inżynierskie, pozwalające stawić czoło problemowi. Do najważniejszych należą:

  • Zasady obowiązujące przy opracowywaniu architektury i projektowaniu systemu
  • Nowe koncepcje w obszarze architektury (zazwyczaj wynikające z zastosowania zasad)
  • Procedury inżynierskiego przygotowania usług
Zasady obowiązujące przy opracowywaniu architektury i projektowaniu systemu

Istnieje wiele zasad, lecz skupimy się tu na tych, które mają największy wpływ na zapewnienie odporności i dostępności.

Technologie informatyczne ukierunkowane na przywracanie

W zakresie obsługi pomyłek operatorów i błędów oprogramowania, których skutki są stosunkowo podobne, postępujemy zgodnie z zasadami Recovery-Oriented Computing1, czyli technologii informatycznych ukierunkowanych na przywracanie. Na poziomie ogólnym oznacza to, że zamiast próbować zagwarantować niewystąpienie problemu (co jest niemożliwe do sprawdzenia), koncentrujemy się na dyskretnej obsłudze problemów w sposób, który można sprawdzić. W szczególności dążymy do zminimalizowania średniego czasu przywracania (MTTR — Mean Time to Recovery), stanowiącego sumę czasu wykrycia problemu, zdiagnozowania go i zaradzenia mu.

Naszym celem jest przywrócenie poprawnego stanu tak szybko, że wykryty problem nie przysporzy kłopotów użytkownikom. W osiągnięciu tego celu są pomocne:

  • Szybkie i automatyczne wykrywanie symptomów błędów i pomyłek operatorów, realizowane poprzez wszechobecne stosowanie asercji w kodzie oraz aktywne monitorowanie i alarmowanie na wszystkich poziomach.
  • Rozdzielanie funkcjonalności na wiele osobnych, szczegółowych jednostek izolacji (wątki, procesy, połączenia, maszyny zapamiętujące stan itp.) cechujących się luźnym sprzężeniem, czyli niewspółużytkujących bezpośrednio pamięci, której zawartość może ulec uszkodzeniu.
  • W razie wykrycia symptomów błędu spowodowanego przez oprogramowanie lub pomyłki operatora, automatyczne i możliwie szybkie zrestartowanie właściwej jednostki izolacji. Restartowanie jest praktycznym sposobem przywrócenia poprawnego stanu po przypadkowej awarii, ponieważ jest podejmowana próba przywrócenia stanu dobrze sprawdzonego, nieuwzględniającego zmian.
  • Jeśli przywracanie na szczegółowym poziomie izolacji nie skutkuje (na przykład asercje są na danym poziomie uaktywniane zbyt często, przyczyniając się do cyklicznego zgłaszania awarii), następuje przejście do następnej większej jednostki (procesu, środowiska wykonawczego, hosta, logicznego centrum danych, pamięci podręcznej operatora-człowieka).
  • Tworzenie mechanizmów umożliwiających „cofnięcie” w skali systemu, obejmujące wersje wszystkich ustalonych stanów i konfiguracji, w celu szybkiego zidentyfikowania i wycofania błędnych powiązań.

Minimalizowanie skutków problemów

W zakresie postępowania z błędami i pomyłkami, których skutki mogą być szersze, konstruujemy mechanizmy minimalizujące „promień rażenia” jakichkolwiek problemów. Innymi słowy, koncentrujemy się na ograniczeniu liczby klientów, systemów i/lub zasobów, na które mogą mieć wpływ jakiekolwiek problemy, w tym stanowiące szczególne wyzwania problemy „hałaśliwych sąsiadów” w środowisku wielu dzierżawców, przyczyniające się do przeciążeń, zmniejszenia wydajności i rozproszonego przeciążenia pamięci wirtualnej. Osiągamy to, używając różnych granic izolacyjnych oraz odpowiednich praktyk w zakresie zarządzania zmianami (zob. dalsze sekcje).

Koncepcje w obszarze architektury wynikające z zasad projektowania

Istnieje wiele koncepcji, lecz skupimy się tu na tych, które przyczyniają się do zmniejszenia promienia rażenia.

Koncepcje dotyczące umiejscowienia, uwzględniane we wszystkich naszych publicznych API: regiony, domeny dostępności i domeny awaryjne

Ponieważ domeny awaryjne stanowią nowe rozwiązanie, zajmiemy się nimi bardziej szczegółowo.

Domeny awaryjne służą do ograniczenia promienia rażenia problemów, które mogą się zdarzyć, gdy system jest aktywnie zmieniany (obejmuje to na przykład wdrażanie, stosowanie poprawek, restartowanie hipernadzorcy i konserwację fizyczną).

Gwarantuje się, że w danej domenie dostępności w danej chwili są zmieniane zasoby w co najwyżej jednej domenie awaryjnej. Jeśli proces zmiany się nie powiedzie, niektóre lub wszystkie zasoby w tej domenie awaryjnej mogą być przez pewien czas niedostępne, lecz nie będzie to dotyczyć pozostałych domen awaryjnych w danej domenie dostępności. Każda domena dostępności zawiera co najmniej trzy domeny awaryjne, umożliwiając hostowanie — w obrębie jednej domeny dostępności — systemów replikacji opartych na kworum (takich jak Oracle Data Guard) z zapewnieniem wysokiej dostępności.

W rezultacie każda domena awaryjna działa w obrębie domeny dostępności jako osobne logiczne centrum danych, ograniczając oddziaływanie dominujących kategorii problemów z dostępnością (błędy oprogramowania, błędy konfiguracji, pomyłki operatorów oraz pogorszenie wydajności, mające miejsce w trakcie przeprowadzania zmian).

Domeny awaryjne chronią także przed niektórymi awariami lokalnego sprzętu. Właściwości domen awaryjnych gwarantują, że zasoby umieszczone w osobnych domenach awaryjnych nie współużytkują w danej domenie dostępności — w możliwie maksymalnym, praktycznym zakresie — żadnych potencjalnych pojedynczych punktów awarii. Na przykład zasoby znajdujące się w różnych domenach awaryjnych nie współużytkują przełączników sieciowych, stosowanych w szafach sprzętowych, ponieważ standardowo przełączniki sieciowe nie są redundantne.

Zdolność domen awaryjnych do ochrony przed problemami ze sprzętem lub z środowiskiem fizycznym pozostaje na poziomie lokalnym. Domeny awaryjne — w przeciwieństwie do domen dostępności i regionów — nie zapewniają izolacji infrastruktury na dużą skalę. W rzadkim przypadku klęski żywiołowej lub awarii infrastruktury w całej domenie dostępności zostaną tym dotknięte także i zasoby znajdujące się w domenach awaryjnych.

Nasze usługi wewnętrzne używają domen awaryjnych w taki sam sposób, w jaki powinny być używane przez klientów. Na przykład usługi Block Volumes, Object Storage i File Storage przechowują repliki danych w trzech osobnych domenach awaryjnych. Wszystkie składniki wszystkich płaszczyzn sterujących i płaszczyzn danych są hostowane w trzech domenach awaryjnych (lub — w regionie z wieloma domenami dostępności — w różnych domenach dostępności).

Komórki usługi

Komórki usługi służą do ograniczenia promienia rażenia problemów, które mogą się zdarzyć, gdy system nie jest aktywnie zmieniany. Tego typu problemy mogą występować, ponieważ obciążenie systemu chmurowego z obsługą wielu dzierżawców może się w dowolnej chwili ekstremalnie zmienić, a ponadto w dużym rozproszonym systemie mogą w dowolnej chwili wystąpić złożone awarie jego części. Może to być spowodowane subtelnymi ukrytymi błędami oprogramowania lub pojawiającymi się problemami z wydajnością.

Dodatkowo komórki usługi mogą także przyczyniać się do ograniczenia promienia rażenia w niektórych rzadkich, lecz stanowiących duże wyzwanie sytuacjach, w których następuje aktywna zmiana systemu. Klasycznym przykładem jest sytuacja, w której wdrożenie w jednej domenie awaryjnej wydaje się być pomyślne — nie są dostrzegane żadne błędy ani pogorszenie wydajności — lecz gdy zostanie zaktualizowana druga lub ostatnia domena awaryjna, nowe interakcje z systemem (w skali całej chmury, z obciążeniem produkcyjnym) wystąpią problemy z wydajnością.

Warto zwrócić uwagę, że używanie komórek usługi jest wzorcem architekturalnym, a nie koncepcją jawnie określoną w Oracle Cloud API lub SDK. Wzorzec ten może być używany dla każdego systemu z obsługą wielu dzierżawców — nie wymaga specjalnej obsługi ze strony platformy chmurowej.

Komórki usługi działają następująco:

  • Każda instancja usługi (na przykład w określonym regionie lub w określonej domenie dostępności z usługami lokalnymi) składa się z wielu osobnych wdrożeń stosu oprogramowania usługi. Każde osobne wdrożenie jest nazywane komórką. Każda komórka jest hostowana w swojej własnej infrastrukturze w stopniu, w jakim jest to praktyczne. Jako minimum, komórki nie współdzielą hostów ani maszyn wirtualnych.
  • Usługa może początkowo być uruchamiana z niewielką liczbą komórek w poszczególnych domenach lub regionach. W miarę skalowania usługi w celu zaspokojenia rosnącego popytu można dodawać więcej komórek, tak aby ograniczyć promień rażenia ewentualnych problemów. Duża, popularna usługa może mieć wiele komórek. Inaczej mówiąc, komórki zapewniają multipleksowanie „n do m” zadań przetwarzania do osobnych środowisk hostujących, zapewniających izolację zasobów. Komórki nie mają oczywistej liczebności, jaka istnieje dla domen awaryjnych. (Jak wspomniano wcześniej oczywistym wyborem liczebności domen awaryjnych jest wybór trzech domen awaryjnych na jedną domenę dostępności, tak aby było możliwe hostowanie — w obrębie jednej domeny dostępności — systemów replikacji opartych na kworum, z zapewnieniem wysokiej dostępności.)
  • Każda „naturalna jednostka” zadania przetwarzania zleconego przez klienta jest przypisywana do określonej komórki. Definicja naturalnej jednostki zależy od charakteru konkretnej usługi. Na przykład w naszej wewnętrznie używanej usłudze Workflow (opisana później) naturalną jednostką mogą być „wszystkie procesy Workflow w domenie dostępności lub regionie dla określonej płaszczyzny sterującej”.
  • Przed każdą grupą komórek występuje albo minimalistyczna warstwa routingu, albo interfejs API służący do wykrywania końcowych punktów komórek. Na przykład system Streaming/Messaging jest wyposażony w interfejs API wykrywający punkt końcowy bieżącej płaszczyzny danych dla konkretnego kanału tematycznego, a wewnętrzny magazyn metadanych ma dla każdej komórki osobny punkt końcowy. Z kolei inne usługi oparte na komórkach mają jeden punkt końcowy płaszczyzny danych i współużytkowaną warstwę routingu. Warstwa routingu stanowi potencjalne źródło powiązanej awarii wielu komórek, lecz ryzyko to jest ograniczane poprzez utrzymywanie warstwy routingu maksymalnie prostą, przewidywalną i ekonomiczną (wolną od kosztownych operacji) oraz wyposażanie jej w liczne mechanizmy zapewniające przepustowość i przydział zgodnie z wymaganiami QoS oraz w mechanizmy tłumienia.
  • Właściciele usługi mogą, jeśli trzeba, przenosić zadania przetwarzania z jednej komórki do innej. Możliwe są następujące przykładowe scenariusze:
    • Pomoc w uniknięciu problemu „hałaśliwego sąsiada” poprzez przeniesienie bardzo obciążającego zadania przetwarzania, dzięki czemu nie oddziałuje ono na innych użytkowników komórki.
    • Pomoc w przywróceniu poprawnego stanu po przeciążeniu lub spadkowi wydajności, prawdopodobnie wynikającemu z ataku DDoS (Distributed Denial of Service). Jako środek ochrony przed takimi atakami stosujemy mechanizmy przydziału i tłumienia, lecz niekiedy mogą mieć miejsce szczególne przypadki, w których konkretny sposób użytkowania (działanie API, wzorzec dostępu) jest dla usługi bardziej forsowny niż rozumiany przez system przydziału lub tłumienia. W takiej sytuacji komórki pomagają krótkotrwale łagodzić skutki takiego sposobu użytkowania.
    • Rozdzielanie krytycznych zadań przetwarzania do osobnych komórek w celu znaczącego zmniejszenia ryzyka powiązanej awarii. Na przykład — w przypadku naszej wewnętrznej usługa „Workflow” dla płaszczyzn sterujących — krytyczne płaszczyzny sterujące (takie jak Platform, Compute, Networking i Block Volumes) są przypisane do różnych komórek, dzięki czemu ryzyko wystąpienia powiązanych awarii jest o wiele mniejsze niż w sytuacji, w której komórki nie byłyby używane lub płaszczyzny te były używane w jednej komórce.
      Uwaga: Dzięki takiemu wykorzystywaniu komórek klienci, tworząc aplikacje odporne na awarie, nie muszą rozważać wewnętrznych zależności usług. Analizowanie schematu zależności jest oczywiście dobrą praktyką (więcej w dalszej części dokumentu), lecz nie jest to tak istotne, gdy mechanizm dekorelacji jest już aktywny.

W rezultacie każda komórka usługi stanowi jeszcze jeden rodzaj logicznego centrum danych — logicznego zgrupowania izolującego przed problemami z wydajnością i awariami — w obrębie jednej domeny dostępności lub regionu.

Podsumowując, komórki usługi i domeny awaryjne uzupełniają się w następujący sposób:

  • Domeny awaryjne chronią przed problemami, które mogą wystąpić, gdy system jest aktywnie zmieniany.
  • Komórki usługi ograniczają promień rażenia, gdy system doświadcza potencjalnie poważnych problemów — bez względu na to, czy jest czy nie jest aktywnie zmieniany.

Właściwości domen awaryjnych i komórek usługi łączymy w ramach jednej zunifikowanej strategii, stosowanej podczas przeprowadzania wdrożeń i wprowadzania poprawek.

Procedury inżynierskiego przygotowania usług

Ponieważ zarówno testowanie, jak i doskonałość operacyjna mają krytyczne znaczenie dla niezawodności systemów chmurowych, stosujemy wiele procedur inżynierskich. Poniżej są przedstawione niektóre z najważniejszych, w których są wykorzystywane przedstawione wcześniej koncepcje:

  • Usługi wdrażamy przyrostowo, przeprowadzając staranną weryfikację na poszczególnych etapach oraz wycofując zmiany, jeśli zdarzy się coś niespodziewanego. Proces ten ma następujący przebieg:
    • W danej domenie dostępności przeprowadzamy wdrożenie kolejno w każdej z komórek. Dla każdej komórki przeprowadzamy wdrożenie kolejno w poszczególnych domenach awaryjnych, aż zostaną one wszystkie wypełnione. Następnie przechodzimy do kolejnej komórki w tej domenie dostępności.
    • Po każdym etapie wdrożenia (po każdej domenie awaryjnej i komórce) sprawdzamy, czy skutki wprowadzonej zmiany są zgodne z oczekiwaniami — inaczej mówiąc sprawdzamy, czy nie nastąpiło pogorszenie wydajności lub nie zostały wprowadzone jakieś błędy (wewnętrzne lub zewnętrzne). Jeśli cokolwiek wydaje się być niewłaściwe lub nieoczekiwane, wycofujemy zmianę. Podkreślamy tu ogromne znaczenie przygotowania i testowania, w tym testowania zautomatyzowanego oraz procedur wycofywania obejmujących zmiany mające wpływ na trwały stan i/lub schematy.
    • W ten sposób wprowadzamy zmiany kolejno w poszczególnych domenach dostępności w każdym z regionów. Wdrożenie we wszystkich regionach w danej dziedzinie odbywa się tak, że nie jest modyfikowana równolegle żadna para regionów, które mogą być używane przez klienta jako lokalizacja podstawowa i awaryjna.
  • Regularnie sprawdzamy, czy mechanizmy obsługi błędów i inne środki zapobiegawcze działają zgodnie z oczekiwaniami oraz zapobiegają rozprzestrzenianiu się problemu. Bez takich testów często się zdarza, że mechanizmy obsługi błędów (na przykład ponawiania, algorytmy przywracania poprawnego stanu po awarii oraz algorytmy zmiany stanu systemu) same zawierają błędy, są zbyt drogie lub współdziałają w nieoczekiwany sposób, przyczyniając się do przeciążenia pamięci wirtualnej lub innych poważnych problemów z wydajnością.
  • Weryfikujemy naszą zdolność szybkiego i bezpiecznego cofnięcia się do ostatniej znanej dobrze działającej konfiguracji i oprogramowania, w tym do utrwalonego stanu i schematów, zgodnie z wcześniejszym opisem.
 
 

Czy w regionach Oracle, zawierających kilka domen dostępności, wszystkie krytyczne usługi są rozdzielone na wszystkie domeny dostępności?

Tak. W danym regionie wszystkie domeny dostępności oferują ten sam zestaw usług.

 
 

W jaki sposób Oracle i klienci Oracle unikają sytuacja, w której krytyczna usługa staje się zależna od jednego logicznego centrum danych?

W regionach z jedną domeną dostępności klienci mogą używać domen awaryjnych (grup logicznych z rozdzielonymi trybami działań w razie awarii) i za ich pomocą zapewniać sobie większość właściwości oddzielonych logicznych centrów danych. Klienci mogą także wykorzystywać, na potrzeby odtwarzania awaryjnego (DR), różne regiony.

W regionach z wieloma domenami dostępności klienci mogą w taki sam sposób używają domen awaryjnych. Klienci mogą także — w celu zapewnienia pełnej wysokiej dostępności (HA) logicznych centrów danych wyższego poziomu (domenami dostępności) — używać kombinacji usług lokalnych z domenami dostępności, funkcji przełączania awaryjnego między domenami dostępności (na przykład funkcji Data Guard dla DBaaS) oraz usług regionalnych (Object Storage, Streaming). Na koniec, klienci mogą także wykorzystywać, na potrzeby odtwarzania awaryjnego (DR), różne regiony.

We wszystkich tych przypadkach klienci mogą korzystać z koncepcji komórek usługi, pozwalających izolować nawet najbardziej poważne problemy, takie jak rozproszone przeciążenie pamięci wirtualnej.

 
 

W jaki sposób Oracle przeprowadza działania konserwacyjne, aby żadne krytyczne usługi nie stały się tymczasowo niedostępne dla klienta?

Cel ten osiągamy, korzystając z domen awaryjnych, komórek usługi i naszych procedur operacyjnych, obejmujących przyrostowe wdrażanie i weryfikację. Zostało to omówione wcześniej w tym dokumencie.

 
 

Czy usługi oparte na platformie bezserwerowej są wdrażane w różnych logicznych centrach danych w celu zapewnienia większej dostępności?

Tak. Wszystkie kategorie usług są wdrażane w różnych logicznych centrach danych — odseparowanych zgrupowań logicznych, zapewniających izolację w razie awarii i problemów z wydajnością — w celu uzyskania wysokiej odporności i stałej dostępności.

 
 

Jeśli odporność (resilience) nie jest konfiguracją domyślną, czy jest oferowane klientom wdrażanie z użyciem więcej niż jednego logicznego centrum danych (na przykład konfiguracja z wieloma domenami lub regionami)?

W regionach z jedną domeną dostępności oferujemy — jako mechanizm „logicznych centrów danych” — domeny awaryjne, omówione w tym dokumencie.

W regionach z wieloma domenami dostępności oferujemy usługi i funkcje zapewniające jeszcze większą fizyczną trwałość synchronicznie replikowanych danych (z niewygórowanym kosztem dostępności, wynikającym z odległości między domenami dostępności w regionie, i szybkością światła).

Nie oferujemy automatycznych mechanizmów wysokiej zapewniania wysokiej dostępności (HA) ani przełączania awaryjnego między regionami, ponieważ to przyczyniłoby się do ścisłego sprzężenia regionów i zwiększenia ryzyka wystąpienia tych samych problemów jednocześnie w różnych regionach. Zamiast tego włączamy różne formy replikacji między regionami oraz oferujemy ro9zrastającą się listę funkcji (takich jak asynchroniczne kopiowanie i tworzenie kopii zapasowych) ułatwiających przywracanie poprawnego stanu po awarii.

 
 

W jaki sposób Oracle pomaga klientom unikać powiązanej awarii aplikacji, wynikającej z wewnętrznych zależności między różnymi usługami infrastruktury i platformy?

Jest to pytanie trochę skomplikowane, a zatem sformułujemy je trochę inaczej:

  • Jeśli klient chce używać dwóch usług Oracle (usługi A i usługi B) i chce skonstruować aplikację odporną na awarię jednej z tych usług, to czy klient musi wiedzieć, czy usługa A jest wewnętrznie zależna od usługi B? Czy zależności wewnętrzne doprowadzają powiązaną awarię do stanu poważnego? Jeśli tak, to klient powinien znać takie wewnętrzne zależności, aby — tworząc własne mechanizmy odporności na poziomie aplikacji — móc ustalić inne sposoby użycia usług A i B albo wprowadzić dla tych dodatkowych zastosowań niepowiązaną usługę C.
  • W jaki sposób klient może się bronić przed powiązaną awarią usług Oracle?

Odpowiedź składa się z dwóch części.

Zasady dotyczące architektury

W zakresie architektury stosujemy zasady, które znacząco ograniczają powiązaną awarię i jej oddziaływanie na zależne usługi. W niektórych przypadkach technika ta zmniejsza prawdopodobieństwo wystąpienia powiązanej awarii do stopnia, który może zostać zignorowany z punktu widzenia spełnienia warunków umowy dotyczącej poziomu usług (SLA) w zakresie dostępności.

W szczególności używamy komórek usługi, omówionych wcześniej w tym dokumencie. Komórki pomagają zapobiegać temu problemowi, ponieważ jeśli wewnętrzna usługa A zostanie dotknięta problemem z jednej zależnych usług, na przykład usługi B, to problem z usługą B najprawdopodobniej ograniczy się do jednej komórki. Inne usługi wysokiego poziomu (oraz własne aplikacje klienta), które używają usługi B, będą prawdopodobnie korzystać z komórek niedotkniętych problemem. Jest to argument natury probabilistycznej, zmieniający się wraz z liczbą komórek, będący ukrytym parametrem wewnętrznym, który ulega zmianie (zwiększa się), tak że nie jest udzielana żadna gwarancja wykraczająca poza umowy SLA dotyczące indywidualnie usługi A i usługi B. W praktyce rozwiązanie to może znacząco przyczynić się do wyeliminowania powiązania awarii między usługami.

Wiele z naszych współużytkowanych usług wewnętrznych — takich jak usługi Workflow i Metadata dla płaszczyzn sterujących oraz usługi Streaming/Messaging — korzysta z komórek usługi w celu wyeliminowania powiązanych skutków wyłączeń.

Zależności

Poniższe informacje są informacjami ogólnymi, ponieważ implementacja na poziomie niskim oraz szczegóły usług mogą się zmieniać i się zmieniają. Dla kluczowych wymiarów usług obliczeniowych, składowania, sieciowych oraz identyfikacji/autoryzacji wskazujemy podanej poniżej zależności.

Dla płaszczyzn sterujących istnieją następujące wspólne zależności:

  1. Płaszczyzna danych Identity/Platform używana do identyfikacji i autoryzacji
  2. Inspekcyjna usługa śledzenia
  3. Usługi wewnętrzne, zapewniające na przykład obsługę procesów Workflow, składowanie metadanych i rejestrowanie w dziennikach
  4. Różnego typu urządzenia równoważenia obciążenia

Niektóre płaszczyzny sterujące w sposób oczywisty cechują zależności od usług. Na przykład płaszczyzna sterująca Compute jest, podczas uruchamiania instancji Bare Metal lub VM, zależna od:

  • Usługi Object Storage (w celu pobrania określonego obrazu systemu operacyjnego)
  • Płaszczyzny sterującej Block Volumes (w celu udostępnienia i dołączenia woluminu rozruchowego)
  • Płaszczyzny sterującej Networking (w celu udostępnienia i dołączenia interfejsów VNIC)

W przypadku płaszczyzn danych dla głównych usług ogólną zasadą jest projektowanie poszczególnych płaszczyzn danych, tak aby cechowały je minimalne zależności, dzięki czemu można zapewnić wysoką dostępność, szybkie diagnozy i szybkie przywracanie poprawnego stanu. Z zastosowania tej zasad wynika, że:

  • Płaszczyzna danych Networking jest samoistna
  • Płaszczyzna danych Block Volumes jest samoistna
  • Instancje obliczeniowe Bare Metal i VM są zależne od płaszczyzny danych Block Volumes (dla woluminów rozruchowych) i płaszczyzny danych Networking.
  • Płaszczyzna danych Object Storage jest zależna od płaszczyzny danych Identity/Platform w zakresie identyfikacji i autoryzacji (ze względu na oczekiwania branży). Płaszczyzna danych Object Storage nie jest zależna od Block Volumes ani File Storage.
  • Wszystkie usługi wspomagające tworzenie kopii zapasowych i odtwarzanie są — w zakresie tych funkcji — zależne od płaszczyzny danych Object Storage.

W przypadku płaszczyzn danych IaaS ogólną zasadą jest zależność wyłącznie od głównych płaszczyzn danych lub płaszczyzn niższego poziomu (w celu uniknięcia zależności cyklicznych).

  • Wielowęzłowe systemy RAC baz danych są zależne od płaszczyzny danych Networking i płaszczyzny danych Block Volumes.
  • Container Engine for Kubernetes w sposób oczywisty zależy od środowiska Kubernetes oraz jego przechodnich zależności (na przykład modułu etcd) i płaszczyzny danych Networking.
  • Całość obsługi tworzenia kopii zapasowych i odtwarzania jest zależna od płaszczyzny danych Object Storage.

1Publiczny program badawczy, realizowany przez uniwersytety Stanford i Berkeley, prowadzony przez Armando Foxa i Dave'a Pattersona

 
×
Zadzwoń do nas teraz
1-800-633-0738 (Stany Zjednoczone)

Kontakt
×
Zadzwoń do nas teraz
1-800-633-0738 (Stany Zjednoczone)


Fora dyskusyjne Oracle Cloud