Włączanie replikacji w wielu regionach w zarządzanym module HSM platformy Azure

Replikacja w wielu regionach umożliwia rozszerzenie zarządzanej puli modułów HSM z jednego regionu platformy Azure (nazywanego podstawowym) do innego regionu platformy Azure (nazywanego pomocniczym). Po skonfigurowaniu oba regiony są aktywne, mogą obsługiwać żądania i, za pomocą replikacji automatycznej, współużytkować ten sam materiał, role i uprawnienia klucza. Najbliższy dostępny region aplikacji odbiera i spełnia żądanie, maksymalizując w ten sposób przepływność i opóźnienie odczytu. Podczas gdy awarie regionalne są rzadkie, replikacja w wielu regionach zwiększa dostępność kluczy kryptograficznych o znaczeniu krytycznym, jeśli jeden region stanie się niedostępny. Aby uzyskać więcej informacji na temat umowy SLA, odwiedź stronę Sla for Azure Key Vault Managed HSM (Umowa SLA dla zarządzanego modułu HSM usługi Azure Key Vault).

Architektura

Diagram architektury zarządzanej replikacji wieloregionowej modułu HSM.

Po włączeniu replikacji z wieloma regionami w zarządzanym module HSM druga zarządzana pula modułów HSM z trzema partycjami HSM o zrównoważonym obciążeniu jest tworzona w regionie pomocniczym. Gdy żądania są wysyłane do globalnego punktu końcowego <hsm-name>.managedhsm.azure.netDNS usługi Traffic Manager, najbliższy dostępny region odbiera i spełnia żądanie. Chociaż każdy region indywidualnie utrzymuje regionalną wysoką dostępność ze względu na dystrybucję modułów HSM w całym regionie, menedżer ruchu zapewnia, że nawet jeśli wszystkie partycje zarządzanego modułu HSM w jednym regionie są niedostępne z powodu awarii, żądania mogą być nadal obsługiwane przez pomocniczą zarządzaną pulę modułów HSM.

Opóźnienie replikacji

Każda operacja zapisu w zarządzanym module HSM, taka jak tworzenie lub aktualizowanie klucza, tworzenie lub aktualizowanie definicji roli albo tworzenie lub aktualizowanie przypisania roli, może potrwać do 6 minut, zanim oba regiony zostaną w pełni zreplikowane. W tym oknie nie ma gwarancji, że zapisany materiał został zreplikowany między regionami. W związku z tym najlepiej odczekać sześć minut między utworzeniem lub zaktualizowaniem klucza i użyciem klucza, aby upewnić się, że materiał klucza został w pełni zreplikowany między regionami. Dotyczy to również przypisań ról i definicji ról.

Zachowanie trybu failover

Tryb failover występuje, gdy jeden z regionów w zarządzanym module HSM w wielu regionach staje się niedostępny z powodu awarii, a drugi region zaczyna obsługiwać wszystkie żądania. Awaria może być ograniczona tylko do puli modułów HSM, całej zarządzanej usługi HSM lub całego regionu świadczenia usługi Azure. Podczas pracy w trybie failover można zauważyć zmianę zachowania w zależności od regionu, którego dotyczy problem.

Region, którego dotyczy problem Dozwolone odczyty Dozwolone zapisy
Podrzędny Tak Tak
Podstawowe Tak Być może

Jeśli region pomocniczy stanie się niedostępny, operacje odczytu (pobierz klucz, klucze listy, wszystkie operacje kryptograficzne, przypisania ról listy) są dostępne, jeśli region podstawowy jest aktywny. Dostępne są również operacje zapisu (tworzenie i aktualizowanie kluczy, tworzenie i aktualizowanie przypisań ról, tworzenie i aktualizowanie definicji ról).

Jeśli region podstawowy jest niedostępny, operacje odczytu są dostępne, ale operacje zapisu mogą nie być zależne od zakresu awarii.

Czas przejścia w tryb failover

Pod maską rozpoznawanie nazw DNS obsługuje przekierowywanie żądań do regionu podstawowego lub pomocniczego.

Jeśli oba regiony są aktywne, usługa Traffic Manager rozpoznaje żądania przychodzące do lokalizacji, która ma najbliższą bliskość geograficzną lub najmniejsze opóźnienie sieci do źródła żądania. Rekordy DNS są konfigurowane przy użyciu domyślnego czasu wygaśnięcia 5 sekund.

Jeśli region zgłasza stan złej kondycji usługi Traffic Manager, przyszłe żądania są rozpoznawane w innym regionie, jeśli jest dostępny. Klienci buforujący wyszukiwania DNS mogą mieć dłuższy czas pracy w trybie failover. Jednak po wygaśnięciu pamięci podręcznej po stronie klienta przyszłe żądania powinny być kierowane do dostępnego regionu.

Obsługa regionów platformy Azure

Następujące regiony są obsługiwane jako regiony podstawowe (regiony, w których można replikować zarządzaną pulę modułów HSM)

  • Wschodnie stany USA
  • Wschodnie stany USA 2
  • Północne stany USA
  • Europa Zachodnia
  • Zachodnie stany USA
  • Kanada Wschodnia
  • Katar Środkowy
  • Azja Wschodnia
  • Azja Południowa
  • Południowe Zjednoczone Królestwo
  • Środkowe stany USA
  • Japonia Wschodnia
  • Szwajcaria Północna
  • Brazylia Południowa
  • Australia Środkowa
  • Indie Środkowe
  • Zachodnie stany USA 3
  • Kanada Środkowa
  • Australia Wschodnia
  • Indie południowe
  • Szwecja Środkowa
  • Północna Republika Południowej Afryki
  • Korea Środkowa
  • Europa Północna
  • Francja Środkowa
  • Japonia Zachodnia
  • Południowo-środkowe stany USA
  • Polska Środkowa
  • Szwajcaria Zachodnia
  • Australia Południowa
  • Indie Zachodnie
  • Środkowe Zjednoczone Emiraty Arabskie
  • Północne Zjednoczone Emiraty Arabskie
  • Zachodnie stany USA 2
  • Zachodnio-środkowe stany USA

Uwaga

Środkowe stany USA, Wschodnie stany USA, Południowo-środkowe stany USA, Zachodnie stany USA 2, Szwajcaria Północna, Europa Zachodnia, Indie Środkowe, Kanada Środkowa, Kanada Wschodnia, Japonia Zachodnia, Katar Środkowy, Środkowe i Zachodnie stany USA nie mogą być obecnie rozszerzone jako region pomocniczy. Inne regiony mogą być niedostępne dla rozszerzenia z powodu ograniczeń pojemności w regionie.

Rozliczenia

Replikacja w wielu regionach do regionu pomocniczego wiąże się z dodatkowymi rozliczeniami (x2), ponieważ nowa pula modułów HSM jest zużywana w regionie pomocniczym. Aby uzyskać więcej informacji, zobacz Cennik zarządzanego modułu HSM platformy Azure.

Zachowanie usuwania nietrwałego

Funkcja usuwania nietrwałego zarządzanego modułu HSM umożliwia odzyskiwanie usuniętych modułów HSM i kluczy, jednak w scenariuszu z włączoną replikacją w wielu regionach istnieją subtelne różnice, w których pomocniczy moduł HSM musi zostać usunięty przed wykonaniem usuwania nietrwałego w podstawowym module HSM. Ponadto po usunięciu pomocniczego jest natychmiast przeczyszczany i nie przechodzi w stan usuwania nietrwałego, który zatrzymuje wszystkie rozliczenia dla pomocniczej. Zawsze można rozszerzyć na nowy region jako pomocniczy z podstawowego, jeśli jest to konieczne.

Funkcja usługi Azure Private Link umożliwia dostęp do zarządzanego modułu HSM za pośrednictwem prywatnego punktu końcowego w sieci wirtualnej. Prywatny punkt końcowy można skonfigurować w zarządzanym module HSM w regionie podstawowym tak samo, jak w przypadku braku korzystania z funkcji replikacji w wielu regionach. W przypadku zarządzanego modułu HSM w regionie pomocniczym zaleca się utworzenie innego prywatnego punktu końcowego po replikacji zarządzanego modułu HSM w regionie podstawowym do zarządzanego modułu HSM w regionie pomocniczym. Spowoduje to przekierowanie żądań klientów do zarządzanego modułu HSM znajdującego się najbliżej lokalizacji klienta.

Poniżej przedstawiono przykładowe scenariusze: Zarządzany moduł HSM w regionie podstawowym (Południowe Zjednoczone Królestwo) i inny zarządzany moduł HSM w regionie pomocniczym (Zachodnio-środkowe stany USA).

  • Gdy oba zarządzane moduły HSM w regionach podstawowych i pomocniczych są uruchomione z włączonym prywatnym punktem końcowym, żądania klientów są przekierowywane do zarządzanego modułu HSM znajdującego się najbliżej lokalizacji klienta. Żądania klientów przechodzą do prywatnego punktu końcowego najbliższego regionu, a następnie kierowane do zarządzanego modułu HSM tego samego regionu przez menedżera ruchu.

    Diagram przedstawiający pierwszy zarządzany scenariusz z wieloma regionami modułu HSM.

  • Jeśli jeden z zarządzanych modułów HSM (Południowe Zjednoczone Królestwo, na przykład) w scenariuszu replikowanym w wielu regionach jest niedostępny z włączonymi prywatnymi punktami końcowymi, żądania klientów są przekierowywane do dostępnego zarządzanego modułu HSM (Zachodnio-środkowe stany USA). Żądania klientów z południowej Wielkiej Brytanii trafią najpierw do prywatnego punktu końcowego południowego Zjednoczonego Królestwa, a następnie kierowane do zachodnio-środkowego zarządzanego modułu HSM przez menedżera ruchu.

    Diagram ilustrujący drugi scenariusz z wieloma regionami zarządzanego modułu HSM.

  • Zarządzane moduły HSM w regionach podstawowych i pomocniczych, ale tylko jeden prywatny punkt końcowy skonfigurowany w podstawowym lub pomocniczym. Aby klient z innej sieci wirtualnej (VNET1) łączył się z zarządzanym modułem HSM za pośrednictwem prywatnego punktu końcowego w innej sieci wirtualnej (VNET2), wymaga komunikacji równorzędnej sieci wirtualnych między dwiema sieciami wirtualnymi. Możesz dodać link sieci wirtualnej dla prywatnej strefy DNS utworzonej podczas tworzenia prywatnego punktu końcowego.

    Diagram przedstawiający trzeci zarządzany scenariusz z wieloma regionami modułu HSM.

Na poniższym diagramie prywatny punkt końcowy jest tworzony tylko w regionie Południowej Wielkiej Brytanii, podczas gdy istnieją dwa zarządzane moduły HSM uruchomione po jednym w Południowej Wielkiej Brytanii, a drugi w regionie Zachodnio-środkowe stany USA. Żądania od obu klientów przechodzą do zarządzanego przez południowe Zjednoczone Królestwo modułu HSM, ponieważ żądania są kierowane przez prywatny punkt końcowy, a w tym przypadku prywatna lokalizacja punktu końcowego znajduje się na południu Wielkiej Brytanii.

Diagram przedstawiający czwarty zarządzany scenariusz z wieloma regionami modułu HSM.

Na poniższym diagramie prywatny punkt końcowy jest tworzony tylko w regionie Południowej Wielkiej Brytanii, dostępny jest tylko zarządzany moduł HSM w regionie Zachodnio-środkowe stany USA, a zarządzany moduł HSM na południu Wielkiej Brytanii jest niedostępny. W takim przypadku żądania zostaną przekierowane do zarządzanego przez moduł HSM zachodnio-środkowego regionu USA za pośrednictwem prywatnego punktu końcowego w Południowej Wielkiej Brytanii, ponieważ menedżer ruchu wykryje, że moduł HSM zarządzany przez Południowe Zjednoczone Królestwo jest niedostępny.

Diagram ilustrujący piąty scenariusz z wieloma regionami zarządzanego modułu HSM.

Polecenia interfejsu wiersza polecenia platformy Azure

Jeśli tworzysz nową pulę zarządzanych modułów HSM, a następnie rozszerzasz ją na pomocniczą, zapoznaj się z tymi instrukcjami przed rozszerzeniem. Jeśli rozszerzenie już istniejącej puli zarządzanego modułu HSM, użyj poniższych instrukcji, aby utworzyć pomocniczy moduł HSM w innym regionie.

Uwaga

Te polecenia wymagają interfejsu wiersza polecenia platformy Azure w wersji 2.48.1 lub nowszej. Aby zainstalować najnowszą wersję, zobacz Jak zainstalować interfejs wiersza polecenia platformy Azure.

Dodawanie pomocniczego modułu HSM w innym regionie

Aby rozszerzyć zarządzaną pulę modułów HSM do innego regionu, uruchom następujące polecenie, które spowoduje automatyczne utworzenie drugiego modułu HSM.

az keyvault region add --hsm-name "ContosoMHSM" --region "australiaeast"

Uwaga

"ContosoMHSM" w tym przykładzie jest podstawową nazwą puli HSM; "australiaeast" to region pomocniczy, w którym ją rozszerzasz.

Usuwanie pomocniczego modułu HSM w innym regionie

Po usunięciu pomocniczego modułu HSM partycje HSM w innym regionie zostaną przeczyszczone. Wszystkie moduły pomocnicze muszą zostać usunięte, zanim podstawowy zarządzany moduł HSM może zostać usunięty nietrwale lub przeczyszczone. Za pomocą tego polecenia można usunąć tylko pomocnicze pliki pomocnicze. Podstawowe można usunąć tylko za pomocą poleceń usuwania nietrwałego i przeczyszczania

az keyvault region remove --hsm-name ContosoMHSM --region australiaeast

Wyświetlanie listy wszystkich regionów

az keyvault region list --hsm-name ContosoMHSM

Następne kroki