Niezawodność w usłudze Azure Container Registry

Usługa Azure Container Registry to zarządzana usługa rejestru kontenerów używana do przechowywania prywatnych obrazów kontenerów platformy Docker i powiązanych artefaktów dla wdrożeń kontenerów i zarządzania nimi.

W przypadku korzystania z platformy Azure niezawodność jest wspólną odpowiedzialnością. Firma Microsoft oferuje szereg możliwości wspierania odporności systemów i odzyskiwania. Odpowiadasz za zrozumienie sposobu działania tych funkcji we wszystkich usługach, których używasz, i wybierania funkcji, które są potrzebne do osiągnięcia celów biznesowych oraz wymagań dotyczących dostępności.

W tym artykule opisano, jak zapewnić odporność usługi Container Registry na różne potencjalne awarie i problemy, w tym przejściowe błędy, awarie strefy dostępności i awarie regionów. Opisano w nim również sposób używania kopii zapasowych do odzyskiwania po innych typach problemów oraz wyróżnia niektóre kluczowe informacje o umowie dotyczącej poziomu usług (SLA) usługi Container Registry.

Zalecenia dotyczące wdrażania produkcyjnego pod kątem niezawodności

W przypadku obciążeń produkcyjnych zalecamy wykonanie następujących czynności:

• Użyj warstwy Premium usługi Container Registry, która zapewnia najbardziej kompleksowe funkcje niezawodności. Warstwa Premium zapewnia również wyższe limity wydajności, ulepszone funkcje zabezpieczeń i zaawansowane funkcje, które są niezbędne dla obciążeń kontenerów produkcyjnych. Aby uzyskać więcej informacji na temat warstw usług i funkcji, zobacz Container Registry service tiers (Warstwy usług usługi Container Registry).

• Skonfiguruj usługę Container Registry w regionie obsługującym strefy dostępności.

• W przypadku scenariuszy obejmujących wiele regionów skonfiguruj replikację geograficzną, aby dystrybuować rejestr w wielu regionach na podstawie określonych wymagań geograficznych i zgodności.

Omówienie architektury niezawodności

Usługa Container Registry jest oparta na rozproszonej infrastrukturze platformy Azure w celu zapewnienia wysokiej dostępności i trwałości danych. Usługa składa się z kilku kluczowych składników, które współpracują ze sobą w celu zapewnienia niezawodności. Na poniższym diagramie przedstawiono podstawową architekturę usługi.

• Płaszczyzna sterowania jest scentralizowanym składnikiem zarządzania w regionie głównym na potrzeby konfiguracji rejestru, konfiguracji uwierzytelniania i zasad replikacji.

• Płaszczyzna danych to usługa rozproszona, która obsługuje operacje wypychania i ściągania obrazu kontenera w różnych regionach i strefach dostępności.

• Warstwa magazynu to rozwiązanie do obsługi zawartości usługi Azure Storage, które utrwala obrazy kontenerów i artefakty. Obejmuje ona automatyczną deduplikację, szyfrowanie magazynowane i wbudowaną replikację.

Firma Microsoft jest odpowiedzialna za zarządzanie podstawową infrastrukturą usługi Container Registry, która obejmuje następujące typy konserwacji:

• Konserwacja płaszczyzny sterowania na potrzeby zarządzania rejestrem

• Konserwacja płaszczyzny danych na potrzeby operacji obrazu kontenera w różnych regionach i strefach dostępności

Jako klient odpowiadasz za następujące działania:

• Odporność na poziomie aplikacji: Zaimplementuj odpowiednią logikę ponawiania prób i obsługę trybu failover w aplikacjach kontenerów i platformach aranżacji.

• Konfiguracja odporności strefy: Upewnij się, że rejestr kontenerów jest wdrożony w regionie obsługującym strefy dostępności.

• Konfiguracja replikacji geograficznej: Wybierz odpowiednie regiony replikacji geograficznej na podstawie rozkładu geograficznego, zgodności i wymagań dotyczących wydajności.

Usługa Container Registry obsługuje również zadania, które mogą pomóc zautomatyzować operacje kompilacji i konserwacji kontenera. Zadania są uruchamiane w zarządzanej przez firmę Microsoft infrastrukturze obliczeniowej i obsługują ręczne, oparte na zdarzeniach lub zaplanowane wyzwalacze. Aby uzyskać więcej informacji, zobacz Automatyzowanie kompilacji i konserwacji obrazu kontenera przy użyciu zadań usługi Container Registry.

Odporność na błędy przejściowe

Błędy przejściowe to krótkotrwałe, sporadyczne awarie w komponentach. Występują one często w środowisku rozproszonym, takich jak chmura, i są one normalną częścią operacji. Błędy przejściowe naprawiają się po krótkim czasie. Ważne jest, aby aplikacje mogły obsługiwać błędy przejściowe, zwykle ponawiając próby żądań, których dotyczy problem.

Wszystkie aplikacje hostowane w chmurze powinny postępować zgodnie ze wskazówkami dotyczącymi obsługi błędów przejściowych platformy Azure podczas komunikowania się z dowolnymi interfejsami API hostowanymi w chmurze, bazami danych i innymi składnikami. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące obsługi błędów przejściowych.

Usługa Container Registry obsługuje błędy przejściowe wewnętrznie za pośrednictwem kilku mechanizmów. Usługa implementuje automatyczną logikę ponawiania prób dla operacji rejestru i utrzymuje buforowanie połączeń w celu wydajnego użycia zasobów. Operacje usługi Container Registry zostały zaprojektowane tak, aby były idempotentne, co umożliwia bezpieczne ponawianie prób operacji wypychania i ściągania. Zadania automatycznie obsługują błędy przejściowe, gdy wykonują wiele typów operacji.

W przypadku aplikacji klienckich korzystających z usługi Container Registry należy zaimplementować odpowiednie zasady ponawiania z wycofywaniem wykładniczym podczas wykonywania operacji rejestru. Użyj oficjalnych zestawów SDK klienta platformy Docker lub usługi Container Registry, które obejmują wbudowane mechanizmy ponawiania dla typowych błędów przejściowych.

Odporność na błędy strefy dostępności

Strefy dostępności są fizycznie oddzielnymi grupami centrów danych w regionie świadczenia usługi Azure. Gdy jedna strefa ulegnie awarii, usługi mogą przejść w tryb failover do jednej z pozostałych stref.

Redundancja strefy chroni rejestr kontenerów przed awariami pojedynczej strefy, rozpraszając dane i operacje rejestru w wielu strefach dostępności w danym regionie. Operacje ściągania i wypychania obrazu kontenera nadal działają podczas przestojów strefy z automatycznym przejściem w tryb failover do stref w dobrej kondycji.

Redundancja strefy jest domyślnie włączona dla wszystkich rejestrów w regionach obsługujących strefy dostępności, co automatycznie i bez dodatkowych kosztów sprawia, że zasoby stają się bardziej odporne. To ulepszenie dotyczy wszystkich warstw usług, w tym warstwy Podstawowa i Standardowa, i zostało zastosowane zarówno do nowych, jak i istniejących rejestrów.

Considerations

• Obsługa regionów: Rejestry strefowo nadmiarowe można wdrożyć w dowolnym regionie obsługującym strefy dostępności. Jeśli rejestr znajduje się w regionie, który nie obsługuje stref dostępności, należy utworzyć nowy rejestr w regionie obsługującym strefy dostępności. Następnie należy przeprowadzić migrację obrazów kontenerów przez utworzenie potoku transferu lub zaimportowanie obrazów kontenerów.

Considerations

• Zadania: Zadania usługi Container Registry nie obsługują obecnie stref dostępności. Redundancja strefowa ma zastosowanie do samej usługi rejestru, ale nie do zadań ani operacji.

• Replikacja geograficzna: Jeśli rejestr używa replikacji geograficznej, wszystkie repliki utworzone w regionach ze strefami dostępności są automatycznie strefowo-nadmiarowe.

Cost

Redundancja strefy jest zawarta w rejestrach kontenerów bez dodatkowych kosztów.

Konfiguruj obsługę stref dostępności

• Utwórz rejestr strefowo nadmiarowy. Podczas tworzenia rejestru w obsługiwanym regionie jest on automatycznie strefowo nadmiarowy. Aby uzyskać więcej informacji na temat tworzenia nowego rejestru, zobacz Tworzenie rejestru strefowo nadmiarowego w usłudze Container Registry.

• Włącz nadmiarowość strefy w istniejącym rejestrze. Rejestry, które znajdują się w regionach ze strefami dostępności, są automatycznie strefowo nadmiarowe. Nie trzeba włączać redundancji strefowej.

• Wyłącz strefową nadmiarowość. Redundancja strefy nie może być wyłączona.

Zachowanie, gdy wszystkie strefy są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy zasoby usługi Container Registry są skonfigurowane pod kątem nadmiarowości strefy, a wszystkie strefy dostępności działają.

• Routing ruchu między strefami: Usługa Container Registry używa funkcji routingu wewnętrznego do automatycznego dystrybuowania operacji płaszczyzny danych we wszystkich strefach dostępności w regionie. Usługa rejestru automatycznie kieruje żądania do stref w dobrej kondycji bez konieczności zewnętrznych modułów równoważenia obciążenia.

• Replikacja danych między strefami: Dane rejestru, w tym obrazy kontenerów, manifesty i metadane, są asynchronicznie replikowane w wielu strefach dostępności. Zmiany są szybko replikowane w różnych strefach, aby zapewnić wysoką dostępność i trwałość danych. Replikacja jest asynchroniczna, ale zwykle kończy się w ciągu kilku minut, a wszystkie strefy pozostają dostępne dla operacji odczytu i zapisu podczas replikacji.

Zachowanie podczas awarii strefy

W tej sekcji opisano, czego można oczekiwać, gdy zasoby usługi Container Registry są skonfigurowane pod kątem nadmiarowości strefy i występuje awaria strefy dostępności.

Gdy strefa stanie się niedostępna, usługa Container Registry automatycznie obsługuje proces trybu failover z minimalnym wpływem na operacje rejestru.

• Wykrywanie i reagowanie: Platforma Container Registry automatycznie wykrywa błędy w strefie dostępności i inicjuje odpowiedź. Usługa automatycznie kieruje ruch do pozostałych stref w dobrej kondycji. Do zainicjowania trybu failover strefy nie jest wymagana interwencja ręczna.

• Powiadomienia: Firma Microsoft nie powiadamia cię automatycznie, gdy strefa nie działa. Możesz jednak użyć usługi Azure Service Health , aby zrozumieć ogólną kondycję usługi, w tym wszelkie błędy strefy, i skonfigurować alerty usługi Service Health w celu powiadamiania o problemach.

  Możesz również monitorować metryki dostępności rejestru w usłudze Azure Monitor.

• Aktywne żądania: Gdy strefa dostępności jest niedostępna, wszystkie żądania, które są połączone z zasobami w uszkodzonej strefie dostępności, zostaną zakończone. Należy je przeprowadzić ponownie.

• Oczekiwana utrata danych: Wszystkie ostatnie operacje zapisu dokonane w uszkodzonej strefie mogą nie być replikowane do innych regionów, co oznacza, że mogą zostać utracone do momentu odzyskania strefy. Utrata danych zwykle wynosi mniej niż 15 minut, ale nie jest to gwarantowane.

• Oczekiwany przestój: Podczas automatycznego przełączania w tryb failover może wystąpić niewielki przestój, ponieważ ruch jest przekierowywany do stref w dobrej kondycji. Ten przestój zwykle trwa kilka sekund w przypadku większości operacji rejestru. Zalecamy stosowanie najlepszych rozwiązań dotyczących obsługi błędów przejściowych w celu zminimalizowania wpływu trybu failover strefy na aplikacje.

• Przekierowywanie ruchu: Platforma automatycznie przekierowuje ruch do stref w dobrej kondycji bez konieczności wprowadzania jakichkolwiek zmian konfiguracji.

Odzyskiwanie strefy

Gdy strefa dostępności, której dotyczy problem, usługa Container Registry automatycznie dystrybuuje operacje we wszystkich dostępnych strefach, w tym w odzyskanej strefie. Usługa ponownie równoważy ruch i dystrybucję danych bez konieczności ręcznej interwencji ani zakłóceń w działaniu usługi.

Testowanie pod kątem niepowodzeń strefy

Platforma Container Registry zarządza routingiem ruchu, trybem failover i powrotem po awarii dla rejestrów strefowo nadmiarowych. Ponieważ ta funkcja jest w pełni zarządzana, nie trzeba inicjować ani weryfikować procesów awarii strefy dostępności.

Odporność na awarie całego regionu

Usługa Container Registry zapewnia natywną obsługę wielu regionów za pośrednictwem replikacji geograficznej, gdy rejestr korzysta z warstwy Premium. Geograficzna replikacja tworzy repliki rejestru w wielu regionach według wyboru. Region, w którym wdrażasz zasób rejestru, jest znany jako region macierzystych.

Replikacja geograficzna umożliwia odporność na awarie regionalne. Jeśli rejestr jest replikowany geograficznie i wystąpi awaria regionalna, dane rejestru będą nadal dostępne w innych wybranych regionach. Jeśli nie włączysz replikacji geograficznej, dane mogą stać się niedostępne podczas awarii regionu.

Można również użyć replikacji geograficznej, aby uzyskać dostęp lokalny do obrazów kontenerów w tych regionach i zmniejszyć opóźnienia dla aplikacji rozproszonych globalnie.

Podczas wdrażania usługi Container Registry i włączania replikacji geograficznej firma Microsoft używa usługi Azure Traffic Manager do dystrybucji żądań płaszczyzny danych między replikami i automatycznego przełączania w tryb failover między replikami, jeśli replika regionalna jest niedostępna.

Replikacja geograficzna usługi Container Registry nie opiera się na sparowanych regionach platformy Azure. Możesz wybrać dowolną kombinację regionów platformy Azure na potrzeby replikacji na podstawie określonych wymagań geograficznych, wydajności i zgodności. Każdy rejestr replikowany geograficznie działa jako punkt końcowy rejestru. Obsługuje większość operacji rejestru, w tym wypychanie obrazów, ściąganie i zadania zarządzania.

Ta sekcja zawiera podsumowanie informacji o replikacji geograficznej w odniesieniu do niezawodności. Aby uzyskać więcej informacji, zobacz Replikacja geograficzna w usłudze Container Registry.

Obsługa regionów

Replikacja geograficzna jest dostępna we wszystkich regionach świadczenia usługi Azure, w których jest obsługiwana warstwa Premium. Można replikować do dowolnej kombinacji regionów, niezależnie od tego, czy platforma Azure paruje te regiony.

Requirements

Aby włączyć replikację geograficzną, należy użyć warstwy Premium.

Considerations

• Repliki strefowo nadmiarowe: Każda replika tworzona w regionie ze strefami dostępności jest automatycznie strefowo nadmiarowa.

• Płaszczyzna sterowania: Płaszczyzna sterowania działa w regionie macierzystym. Jeśli region macierzysty jest niedostępny, operacje płaszczyzny sterowania są niedostępne i może nie być możliwe, aby zmodyfikować konfigurację rejestru.

• Zadania: Zadania usługi Container Registry nie obsługują obecnie replik geograficznych. Zadania są zawsze uruchamiane w macierzystym regionie. Jeśli region macierzystowy jest niedostępny, zadanie nie zostanie uruchomione.

Cost

Każdy region replikowany geograficznie jest rozliczany oddzielnie zgodnie z cennikiem warstwy Premium dla odpowiedniego regionu. Opłaty za ruch wychodzący dotyczą również transferu danych między regionami podczas replikacji początkowej i trwającej synchronizacji.

Konfigurowanie obsługi wielu regionów

Replikację geograficzną można skonfigurować podczas tworzenia rejestru lub dodawania do istniejących rejestrów Premium. Replikacja geograficzna można skonfigurować za pośrednictwem witryny Azure Portal, interfejsu wiersza polecenia platformy Azure, programu Azure PowerShell lub szablonów usługi Azure Resource Manager.

• Utwórz rejestr replikowany geograficznie. Skonfiguruj replikację geograficzną po utworzeniu rejestru, określając dodatkowe regiony.

• Włącz replikację geograficzną w istniejącym rejestrze. Aby włączyć możliwości replikacji geograficznej, uaktualnij istniejące rejestry warstwy Podstawowa lub Standardowa do warstwy Premium. Regiony replikacji można zmienić w dowolnym momencie. Aby uzyskać więcej informacji, zobacz Konfigurowanie replikacji geograficznej.

• Wyłącz replikację geograficzną. Usuń poszczególne repliki regionalne za pomocą witryny Azure Portal lub narzędzi wiersza polecenia. Nie można usunąć rejestru regionu macierzystego.

Zachowanie, gdy wszystkie regiony są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy rejestr jest skonfigurowany do replikacji geograficznej, a wszystkie regiony działają.

• Routing ruchu między regionami: Usługa Container Registry działa w konfiguracji aktywne-aktywne, w której każdy regionalny punkt końcowy może obsługiwać wszystkie operacje płaszczyzny danych niezależnie, w tym operacje odczytu i zapisu. Operacje płaszczyzny danych, takie jak operacje wypychania i ściągania kontenerów, są automatycznie kierowane przy użyciu usługi Traffic Manager z kryteriami opartymi na wydajności w celu określenia optymalnego regionalnego punktu końcowego pod kątem wydajności.

• Replikacja danych między regionami: Replikacja geograficzna automatycznie synchronizuje obrazy kontenerów i artefakty we wszystkich skonfigurowanych regionach przy użyciu replikacji asynchronicznej ze spójnością ostateczną. Usługa używa magazynu adresowalnego do zawartości, aby efektywnie replikować tylko unikatowe warstwy obrazów. Takie podejście minimalizuje użycie przepustowości i czas replikacji. Operacje odczytu i zapisu działają we wszystkich regionach replikowanych geograficznie. Zmiany wprowadzone w dowolnym regionie są replikowane do wszystkich innych regionów.

  Replikacja zwykle kończy się w ciągu kilku minut od zmian. Nie ma jednak żadnej gwarancji czasu replikacji danych. Replikacja dużych obrazów kontenerów lub aktualizacji o wysokiej częstotliwości we wszystkich regionach może potrwać dłużej.

Zachowanie podczas awarii regionu

W tej sekcji opisano, czego można oczekiwać, gdy rejestr jest skonfigurowany do replikacji geograficznej i występuje awaria w regionie podstawowym.

Gdy region stanie się niedostępny, operacje kontenerów mogą nadal używać alternatywnych regionalnych punktów końcowych.

• Wykrywanie i reagowanie: Usługa Container Registry monitoruje kondycję każdej repliki regionalnej i odpowiada za przekierowywanie ruchu do innego regionu.

• Powiadomienia: Firma Microsoft nie powiadamia cię automatycznie, gdy region nie działa. Możesz jednak użyć usługi Azure Service Health , aby zrozumieć ogólną kondycję usługi, w tym wszelkie awarie regionów, i skonfigurować alerty usługi Service Health w celu powiadamiania o problemach.

  Można również monitorować metryki dostępności rejestru dla każdego regionalnego punktu końcowego w usłudze Azure Monitor.

• Aktywne żądania: Wszystkie aktywne żądania aktualnie w locie do niedostępnego regionu kończą się niepowodzeniem i muszą zostać ponowione, aby można je było przekierować do regionu w dobrej kondycji.

• Oczekiwana utrata danych: Wszystkie ostatnie operacje zapisu dokonane w uszkodzonym regionie mogą nie być replikowane do innych regionów. Ta awaria oznacza, że mogą zostać utracone do czasu odzyskania regionu. Zazwyczaj utrata danych powinna być mniejsza niż 15 minut, ale nie jest to gwarantowane.

• Oczekiwany przestój: W przypadku operacji płaszczyzny danych oczekiwana jest niewielka ilość przestojów w przypadku operacji płaszczyzny danych podczas pracy w trybie failover, co zwykle trwa od 1 do 2 minut.

  Jeśli region macierzysny jest niedostępny, operacje płaszczyzny sterowania są niedostępne do czasu odzyskania regionu.

• Przekierowywanie ruchu: Gdy region stanie się niedostępny, operacje kontenerów są automatycznie przekierowywane do innej repliki w regionie dobrej kondycji. Klienci nie muszą zmieniać punktu końcowego, w którym wchodzą w interakcję z rejestrem. Firma Microsoft automatycznie obsługuje routing, tryb failover i powrót po awarii.

Odzyskiwanie regionów

Po odzyskaniu regionu operacje płaszczyzny danych są automatycznie wznawiane dla tego regionalnego punktu końcowego za pośrednictwem routingu usługi Traffic Manager. Usługa synchronizuje wszelkie zmiany występujące podczas przestoju przy użyciu replikacji asynchronicznej ze spójnością ostateczną.

Testowanie pod kątem błędów regionów

Nie można symulować awarii jednego z regionów skojarzonych z rejestrem, ale możesz przetestować możliwość przełączania aplikacji w tryb failover między regionami. Możesz symulować regionalny tryb failover, tymczasowo wyłączając repliki geograficzne, co powoduje usunięcie ich z routingu usługi Traffic Manager. Następnie możesz sprawdzić, czy operacje kontenera pomyślnie przejdą w tryb failover do alternatywnych regionów bez wystąpienia awarii regionalnej. Aby uzyskać więcej informacji, zobacz Tymczasowe wyłączanie routingu do replikacji.

Po ponownym włączeniu repliki usługa Traffic Manager wznowi kierowanie ruchu do ponownie włączonej repliki. Ponadto metadane i obrazy są synchronizowane ze spójnością ostateczną z ponownie włączoną repliką w celu zapewnienia spójności danych we wszystkich regionach.

Tworzenie kopii zapasowej i przywracanie

Usługa Container Registry obsługuje eksportowanie obrazów kontenerów i artefaktów z rejestru do magazynu zewnętrznego lub alternatywnych rejestrów. Użyj funkcji importowania i eksportowania usługi Container Registry lub standardowych poleceń platformy Docker, aby utworzyć kopie krytycznych obrazów kontenerów na potrzeby scenariuszy odzyskiwania po awarii.

W przypadku większości rozwiązań nie należy polegać wyłącznie na kopiach zapasowych. Zamiast tego skorzystaj z innych możliwości opisanych w tym przewodniku, aby spełnić wymagania dotyczące odporności. Jednak kopie zapasowe chronią przed pewnymi zagrożeniami, których nie zapewniają inne podejścia. Aby uzyskać więcej informacji, zobacz Co to jest nadmiarowość, replikacja i kopia zapasowa?.

Umowa dotycząca poziomu usług

Umowa dotycząca poziomu usług (SLA) dla usług platformy Azure opisuje oczekiwaną dostępność każdej usługi oraz warunki, które rozwiązanie musi spełnić, aby osiągnąć te oczekiwania dotyczące dostępności. Aby uzyskać więcej informacji, zobacz Umowy SLA dotyczące usług online.

Treści powiązane

• Niezawodność platformy Azure
• Warstwy usługi Container Registry
• Najlepsze rozwiązania dotyczące usługi Container Registry
• Monitorowanie rejestru kontenerów
• Cennik usługi Container Registry
• Importowanie obrazów kontenerów do rejestru kontenerów