Share via


Aktivera replikering i flera regioner på Azure Managed HSM

Med replikering i flera regioner kan du utöka en hanterad HSM-pool från en Azure-region (kallas primär) till en annan Azure-region (kallas sekundär). När de har konfigurerats är båda regionerna aktiva, kan hantera begäranden och, med automatiserad replikering, dela samma nyckelmaterial, roller och behörigheter. Den närmaste tillgängliga regionen för programmet tar emot och uppfyller begäran, vilket maximerar läsdataflödet och svarstiden. Regionala avbrott är sällsynta, men replikering i flera regioner förbättrar tillgängligheten för verksamhetskritiska kryptografiska nycklar om en region blir otillgänglig. Mer information om serviceavtal finns i SLA för Azure Key Vault Managed HSM.

Arkitektur

Arkitekturdiagram över hanterad HSM-replikering i flera regioner.

När replikering i flera regioner är aktiverad på en hanterad HSM skapas en andra hanterad HSM-pool med tre belastningsutjämnings-HSM-partitioner i den sekundära regionen. När begäranden utfärdas till den globala DNS-slutpunkten <hsm-name>.managedhsm.azure.neti Traffic Manager tar den närmaste tillgängliga regionen emot och uppfyller begäran. Varje region har regional hög tillgänglighet på grund av fördelningen av HSM:er i regionen, men trafikhanteraren ser till att även om alla partitioner av en hanterad HSM i en region inte är tillgängliga på grund av en katastrof, kan begäranden fortfarande hanteras av den sekundära hanterade HSM-poolen.

Replikeringsfördröjning

Alla skrivåtgärder till managed HSM, till exempel att skapa eller uppdatera en nyckel, skapa eller uppdatera en rolldefinition eller skapa eller uppdatera en rolltilldelning, kan ta upp till 6 minuter innan båda regionerna replikeras helt. I det här fönstret är det inte garanterat att det skrivna materialet har replikerats mellan regionerna. Därför är det bäst att vänta sex minuter mellan att skapa eller uppdatera nyckeln och använda nyckeln för att säkerställa att nyckelmaterialet har replikerats helt mellan regioner. Detsamma gäller för rolltilldelningar och rolldefinitioner.

Redundansbeteende

Redundans uppstår när en av regionerna i en hanterad HSM för flera regioner blir otillgänglig på grund av ett avbrott och den andra regionen börjar hantera alla begäranden. Avbrottet kan begränsas till din HSM-pool, hela managed HSM-tjänsten eller hela Azure-regionen. Under redundansväxlingen kan du märka en ändring i beteendet beroende på vilken region som påverkas.

Berörd region Läsningar tillåtna Skrivningar tillåtna
Sekundära Ja Ja
Primär Ja Kanske

Om den sekundära regionen blir otillgänglig är läsåtgärder (hämta nyckel, listnycklar, alla kryptoåtgärder, listrolltilldelningar) tillgängliga om den primära regionen är aktiv. Skrivåtgärder (skapa och uppdatera nycklar, skapa och uppdatera rolltilldelningar, skapa och uppdatera rolldefinitioner) är också tillgängliga.

Om den primära regionen inte är tillgänglig är läsåtgärder tillgängliga, men skrivåtgärder kanske inte är det, beroende på omfånget för avbrottet.

Tid till redundans

Under huven hanterar DNS-matchningen omdirigeringen av begäranden till antingen den primära eller sekundära regionen.

Om båda regionerna är aktiva löser Traffic Manager inkommande begäranden till den plats som har den närmaste geografiska närheten eller den lägsta nätverksfördröjningen till begärans ursprung. DNS-poster konfigureras med en standard-TTL på 5 sekunder.

Om en region rapporterar en status som inte är felfri till Traffic Manager matchas framtida begäranden till den andra regionen om det är tillgängligt. Klienter som cachelagrar DNS-sökningar kan få längre redundans. Men när alla cacheminnen på klientsidan upphör att gälla bör framtida begäranden dirigeras till den tillgängliga regionen.

Stöd för Azure-region

Följande regioner stöds som primära regioner (regioner där du kan replikera en hanterad HSM-pool från)

  • USA, Östra
  • USA, östra 2
  • USA, norra
  • Västeuropa
  • Västra USA
  • Östra Kanada
  • Qatar, centrala
  • Östasien
  • Asien, Södra
  • Södra Storbritannien
  • USA, centrala
  • Japan, östra
  • Schweiz, norra
  • Brasilien, södra
  • Australien, centrala
  • Indien, centrala
  • USA, västra 3
  • Kanada, centrala
  • Australien, östra
  • Indien, syd
  • Sverige, centrala
  • Sydafrika, norra
  • Sydkorea, centrala
  • Nordeuropa
  • Centrala Frankrike
  • Västra Japan
  • USA, södra centrala
  • Polen, centrala
  • Schweiz, västra
  • Australien SouthEast
  • Indien, västra
  • Förenade Arabemiraten, centrala
  • Förenade Arabemiraten, norra
  • USA, västra 2
  • USA, västra centrala

Kommentar

USA, centrala, USA, östra, USA, södra centrala, USA, västra 2, Schweiz, norra, Europa, västra, centrala Indien, Kanada, centrala, Kanada, östra, Japan, västra, Qatar, centrala, Polen, centrala och USA, västra centrala, kan för närvarande inte utökas som en sekundär region. Andra regioner kan vara otillgängliga för tillägg på grund av kapacitetsbegränsningar i regionen.

Fakturering

Replikering i flera regioner till sekundär region medför extra fakturering (x2), eftersom en ny HSM-pool används i den sekundära regionen. Mer information finns i Priser för Azure Managed HSM.

Beteende vid mjuk borttagning

Funktionen för mjuk borttagning av hanterad HSM tillåter återställning av borttagna HSM:er och nycklar, men i ett scenario med replikering i flera regioner finns det subtila skillnader där den sekundära HSM:en måste tas bort innan mjuk borttagning kan köras på den primära HSM:en. När en sekundär tas bort rensas den dessutom omedelbart och hamnar inte i ett tillstånd för mjuk borttagning som stoppar all fakturering för den sekundära. Du kan alltid utöka till en ny region som sekundär från den primära om det behövs.

Med funktionen Azure Private Link kan du komma åt den hanterade HSM-tjänsten via en privat slutpunkt i det virtuella nätverket. Du konfigurerar en privat slutpunkt på Managed HSM i den primära regionen precis som när du inte använder replikeringsfunktionen för flera regioner. För Managed HSM i den sekundära regionen rekommenderar vi att du skapar en annan privat slutpunkt när den hanterade HSM:en i den primära regionen replikeras till den hanterade HSM:en i den sekundära regionen. Detta omdirigerar klientbegäranden till den hanterade HSM som är närmast klientplatsen.

Några scenarier nedan med exempel: Hanterad HSM i en primär region (Storbritannien, södra) och en annan hanterad HSM i en sekundär region (USA, västra centrala).

  • När både hanterade HSM:er i de primära och sekundära regionerna är igång med den privata slutpunkten aktiverad omdirigeras klientbegäranden till den hanterade HSM som är närmast klientplatsen. Klientbegäranden går till den närmaste regionens privata slutpunkt och dirigeras sedan till samma regions hanterade HSM av trafikhanteraren.

    Diagram som illustrerar det första hanterade HSM-scenariot för flera regioner.

  • När en av de hanterade HSM:erna (uk south, som exempel) i ett replikerat scenario med flera regioner inte är tillgängligt med privata slutpunkter aktiverade, omdirigeras klientbegäranden till tillgänglig Hanterad HSM (USA, västra centrala). Klientbegäranden från Storbritannien och södra storbritannien går först till den privata slutpunkten i Storbritannien och dirigeras sedan till US west Central Managed HSM av trafikchefen.

    Diagram som illustrerar det andra hanterade HSM-scenariot för flera regioner.

  • Hanterade HSM:er i primära och sekundära regioner men bara en privat slutpunkt som konfigurerats i antingen primär eller sekundär. För att en klient från ett annat VNET (VNET1) ska kunna ansluta till en hanterad HSM via en privat slutpunkt i ett annat VNET (VNET2) krävs VNET-peering mellan de två virtuella nätverken. Du kan lägga till VNET-länk för den privata DNS-zonen som skapas när den privata slutpunkten skapas.

    Diagram som illustrerar det tredje hanterade HSM-scenariot för flera regioner.

I diagrammet nedan skapas endast privat slutpunkt i regionen Storbritannien, södra, medan det finns två hanterade HSM:er som kör en vardera i Storbritannien, södra och den andra i USA, västra centrala. Begäranden från båda klienterna går till UK South Managed HSM eftersom begäranden dirigeras via den privata slutpunkten och den privata slutpunktens plats i det här fallet är i Storbritannien, södra.

Diagram som illustrerar det fjärde hanterade HSM-scenariot för flera regioner.

I diagrammet nedan skapas endast privat slutpunkt i regionen Storbritannien, södra, endast Managed HSM i USA, västra centrala är tillgänglig och Managed HSM i Storbritannien, södra är inte tillgänglig. I det här fallet omdirigeras begäranden till US West Central Managed HSM via den privata slutpunkten i Storbritannien, södra eftersom trafikhanteraren upptäcker att UK South Managed HSM inte är tillgängligt.

Diagram som illustrerar det femte hanterade HSM-scenariot för flera regioner.

Azure CLI-kommandon

Om du skapar en ny hanterad HSM-pool och sedan utökar till en sekundär, kan du läsa de här anvisningarna innan du utökar. Om du utökar från en redan befintlig Hanterad HSM-pool använder du följande instruktioner för att skapa en sekundär HSM till en annan region.

Kommentar

Dessa kommandon kräver Azure CLI version 2.48.1 eller senare. Information om hur du installerar den senaste versionen finns i Så här installerar du Azure CLI.

Lägga till en sekundär HSM i en annan region

Om du vill utöka en hanterad HSM-pool till en annan region kör du följande kommando som automatiskt skapar en andra HSM.

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

Kommentar

"ContosoMHSM" i det här exemplet är det primära HSM-poolnamnet. "australiaeast" är den sekundära region där du utökar den.

Ta bort en sekundär HSM i en annan region

När du tar bort en sekundär HSM rensas HSM-partitionerna i den andra regionen. Alla sekundärfiler måste tas bort innan en primär hanterad HSM kan tas bort eller rensas. Endast sekundärfiler kan tas bort med det här kommandot. Den primära kan bara tas bort med hjälp av kommandona för mjuk borttagning och rensning

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

Visa en lista över alla regioner

az keyvault region list --hsm-name ContosoMHSM

Nästa steg