Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Azure Container Registry is een beheerde containerregisterservice die wordt gebruikt voor het opslaan en beheren van uw persoonlijke Docker-containerinstallatiekopieën en gerelateerde artefacten voor uw containerimplementaties.
Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.
In dit artikel wordt beschreven hoe u Container Registry bestand maakt tegen verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone en regiostoringen. Ook wordt beschreven hoe u back-ups kunt gebruiken om te herstellen van andere soorten problemen en belangrijke informatiepunten uitlicht over de Service Level Agreement (SLA) van de Container Registry.
Aanbevelingen voor productie-implementatie voor betrouwbaarheid
Voor productieworkloads raden we u aan de volgende acties uit te voeren:
Gebruik de Premium-laag van Container Registry, die de meest uitgebreide betrouwbaarheidsfuncties biedt. De Premium-laag biedt ook hogere prestatielimieten, verbeterde beveiligingsfuncties en geavanceerde mogelijkheden die essentieel zijn voor productiecontainerworkloads. Zie Container Registry-servicelagen voor meer informatie over servicelagen en functies.
Richt uw Container Registry in een regio in die ondersteuning biedt voor beschikbaarheidszones.
Voor scenario's met meerdere regio's configureert u geo-replicatie om uw register over meerdere regio's te verdelen op basis van uw specifieke geografische en nalevingsvereisten.
Overzicht van betrouwbaarheidsarchitectuur
Container Registry is gebouwd op een gedistribueerde Azure-infrastructuur om hoge beschikbaarheid en duurzaamheid van gegevens te bieden. De service bestaat uit verschillende belangrijke onderdelen die samenwerken om betrouwbaarheid te garanderen. In het volgende diagram ziet u de basisservicearchitectuur.
Het besturingsvlak is een gecentraliseerd beheeronderdeel in de basisregio voor registerconfiguratie, verificatieconfiguratie en replicatiebeleid.
Het gegevensvlak is een gedistribueerde service die push- en pull-bewerkingen voor containerinstallatiekopieën verwerkt in regio's en beschikbaarheidszones.
De opslaglaag is een oplossing voor inhoudsadressen van Azure Storage die containerinstallatiekopieën en artefacten persistent maakt. Het omvat automatische ontdubbeling, versleuteling-at-rest en ingebouwde replicatie.
Microsoft is verantwoordelijk voor het beheren van de onderliggende Container Registry-infrastructuur, waaronder de volgende typen onderhoud:
Beheervlakonderhoud voor registerbeheer
Onderhoud van gegevensvlak voor bewerkingen van containerinstallatiekopieën in regio's en beschikbaarheidszones
Als klant bent u verantwoordelijk voor de volgende acties:
Tolerantie op toepassingsniveau: Implementeer de juiste logica voor opnieuw proberen en failover-verwerking in uw containertoepassingen en indelingsplatforms.
Configuratie van zonetolerantie: Zorg ervoor dat uw containerregister is geïmplementeerd in een regio die beschikbaarheidszones ondersteunt.
Configuratie van geo-replicatie: Kies de juiste regio's voor geo-replicatie op basis van uw geografische distributie, naleving en prestatievereisten.
Container Registry ondersteunt ook taken, waarmee u uw container-builds en onderhoudsbewerkingen kunt automatiseren. Taken worden uitgevoerd op door Microsoft beheerde rekeninfrastructuur en ondersteunen handmatige, gebeurtenisgebaseerde of geplande triggers. Zie Builds en onderhoud van containerinstallatiekopieën automatiseren met behulp van Container Registry-taken voor meer informatie.
Note
Container Registry ondersteunt verbonden registers, die on-premises of externe replica's zijn die worden gesynchroniseerd met uw containerregister in de cloud. Wanneer u verbonden registers gebruikt, bent u verantwoordelijk voor het configureren van deze registers om te voldoen aan uw betrouwbaarheidsvereisten. Verbonden registers vallen buiten het bereik van dit artikel.
Tolerantie voor tijdelijke fouten
Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.
Alle in de cloud gehoste toepassingen moeten de richtlijnen voor tijdelijke foutafhandeling van Azure volgen wanneer ze communiceren met eventuele in de cloud gehoste API's, databases en andere onderdelen. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.
Container Registry verwerkt tijdelijke fouten intern via verschillende mechanismen. De service implementeert automatische logica voor opnieuw proberen voor registerbewerkingen en onderhoudt verbindingspooling voor efficiënt resourcegebruik. Container Registry-bewerkingen zijn ontworpen om idempotent te zijn, waardoor veilige pogingen van push- en pull-bewerkingen mogelijk zijn. Taken verwerken automatisch tijdelijke fouten wanneer ze veel soorten bewerkingen uitvoeren.
Voor clienttoepassingen die gebruikmaken van Container Registry, implementeert u het juiste beleid voor opnieuw proberen met exponentieel uitstel bij het uitvoeren van registerbewerkingen. Gebruik de officiële Docker-client- of Container Registry SDK's, waaronder ingebouwde mechanismen voor opnieuw proberen voor veelvoorkomende tijdelijke fouten.
Tolerantie voor fouten in beschikbaarheidszones
Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.
Zoneredundantie beschermt uw containerregister tegen fouten in één zone door registergegevens en -bewerkingen te distribueren over meerdere beschikbaarheidszones binnen de regio. Pull- en pushbewerkingen voor container images blijven functioneren tijdens uitval van zones, met automatische failover naar gezonde zones.
Zoneredundantie is standaard ingeschakeld voor alle registers in regio's die beschikbaarheidszones ondersteunen, waardoor uw resources automatisch en zonder extra kosten toleranter worden. Deze uitbreiding is van toepassing op alle servicelagen, waaronder Basic en Standard, en is toegepast op zowel nieuwe als bestaande registers.
Belangrijk
De Azure-portal en andere hulpprogramma's weerspiegelen mogelijk nog niet de update van zoneredundantie.
De zoneRedundancy eigenschap in de configuratie van uw register kan nog steeds worden weergegeven als false, maar zoneredundantie is actief voor alle registers in ondersteunde regio's.
We werken de portal- en API-oppervlakken actief bij om dit standaardgedrag transparanter weer te geven. Alle eerder ingeschakelde functies blijven werken zoals verwacht.
Considerations
- Regioondersteuning: Zone-redundante registers kunnen worden geïmplementeerd in elke regio die beschikbaarheidszones ondersteunt. Als uw register zich in een regio bevindt die geen ondersteuning biedt voor beschikbaarheidzones, moet u een nieuw register maken in een regio die beschikbaarheidzones ondersteunt. Vervolgens moet u uw containerinstallatiekopieën migreren door een overdrachtspijplijn te maken of door containerinstallatiekopieën te importeren.
Considerations
Taken: Container Registry-taken ondersteunen momenteel geen beschikbaarheidszones. Zoneredundantie is van toepassing op de registerservice zelf, maar niet op taken of hun bewerkingen.
Geo-replicatie: Als uw register gebruikmaakt van geo-replicatie, worden replica's die zijn gemaakt in regio's met beschikbaarheidszones, automatisch zone-redundant gemaakt.
Cost
Zoneredundantie is zonder extra kosten opgenomen in containerregisters.
Ondersteuning voor beschikbaarheidszones configureren
Maak een zone-redundant register. Wanneer u een register maakt in een ondersteunde regio, wordt het automatisch zone-redundant. Zie Een zone-redundant register maken in Container Registry voor meer informatie over het maken van een nieuw register.
Schakel zoneredundantie in voor een bestaand register. Registers die zich in regio's met beschikbaarheidszones bevinden, zijn automatisch zone-redundant. U hoeft zoneredundantie niet in te schakelen.
Zoneredundantie uitschakelen. Zoneredundantie kan niet worden uitgeschakeld.
Gedrag wanneer alle zones in orde zijn
In deze sectie wordt beschreven wat u kunt verwachten wanneer Container Registry-resources zijn geconfigureerd voor zoneredundantie en alle beschikbaarheidszones operationeel zijn.
Verkeersroutering tussen zones: Container Registry maakt gebruik van interne routeringsfunctionaliteit om gegevensvlakbewerkingen automatisch te distribueren naar alle beschikbaarheidszones binnen een regio. De registerservice stuurt aanvragen automatisch door naar zones die in orde zijn zonder dat externe load balancers nodig zijn.
Gegevensreplicatie tussen zones: Registergegevens, waaronder containerinstallatiekopieën, manifesten en metagegevens, worden asynchroon gerepliceerd in meerdere beschikbaarheidszones. Wijzigingen worden snel gerepliceerd tussen zones om de duurzaamheid van hoge beschikbaarheid en gegevens te behouden. Replicatie is asynchroon, maar wordt doorgaans binnen enkele minuten voltooid en alle zones blijven beschikbaar voor lees- en schrijfbewerkingen tijdens de replicatie.
Gedrag tijdens een zonefout
In deze sectie wordt beschreven wat u kunt verwachten wanneer Container Registry-resources zijn geconfigureerd voor zoneredundantie en er een storing in de beschikbaarheidszone is.
Wanneer een zone niet beschikbaar is, verwerkt Container Registry het failoverproces automatisch met minimale gevolgen voor registerbewerkingen.
Detectie en reactie: Het Container Registry-platform detecteert automatisch fouten in een beschikbaarheidszone en initieert een reactie. De service routeert automatisch verkeer naar de resterende gezonde zones. Er is geen handmatige tussenkomst vereist om een zonefailover te starten.
Meldingen: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.
U kunt ook metrische gegevens over de beschikbaarheid van registers bewaken in Azure Monitor.
Actieve aanvragen: Wanneer een beschikbaarheidszone niet beschikbaar is, worden alle aanvragen die worden uitgevoerd die zijn verbonden met resources in de defecte beschikbaarheidszone beëindigd. Ze moeten opnieuw worden geprobeerd.
Verwachte gegevensverlies: Recente schrijfbewerkingen in de foutieve zone worden mogelijk niet gerepliceerd naar andere regio's, wat betekent dat ze mogelijk verloren gaan totdat de zone wordt hersteld. Het gegevensverlies is doorgaans minder dan 15 minuten, maar dat is niet gegarandeerd.
Verwachte downtime: Er kan een kleine hoeveelheid downtime optreden tijdens automatische failover, omdat verkeer wordt omgeleid naar gezonde zones. Deze downtime duurt doorgaans een paar seconden voor de meeste registerbewerkingen. We raden u aan de aanbevolen procedures voor het afhandelen van tijdelijke fouten te volgen om het effect van zonefailover op uw toepassingen te minimaliseren.
Verkeer omleiden: Het platform routeert automatisch verkeer naar gezonde zones zonder dat u configuratiewijzigingen hoeft aan te brengen.
Zoneherstel
Wanneer de betrokken beschikbaarheidszone wordt hersteld, distribueert Container Registry automatisch bewerkingen over alle beschikbare zones, inclusief de herstelde zone. De service herverdeelt verkeer en gegevens zonder dat er handmatige tussenkomst of onderbreking van de dienst nodig is.
Testen op zonefouten
Het Container Registry-platform beheert verkeersroutering, failover en failback voor zone-redundante registers. Omdat deze functie volledig wordt beheerd, hoeft u geen processen voor fouten in de beschikbaarheidszone te initiëren of valideren.
Tolerantie voor storingen in de hele regio
Container Registry biedt systeemeigen ondersteuning voor meerdere regio's via geo-replicatie wanneer uw register gebruikmaakt van de Premium-laag. Geo-replicatie maakt registerreplica's in meerdere regio's van uw keuze. De regio waarmee u de registerresource implementeert, wordt de basisregio genoemd.
Geo-replicatie maakt tolerantie mogelijk voor regionale storingen. Als uw register geo-gerepliceerd is en er een regionale storing optreedt, blijven de registergegevens beschikbaar vanuit de andere regio's die u hebt geselecteerd. Als u geo-replicatie niet inschakelt, zijn uw gegevens mogelijk niet meer beschikbaar tijdens een storing in de regio.
U kunt geo-replicatie ook gebruiken om lokale toegang te krijgen tot containerinstallatiekopieën binnen die regio's en om de latentie voor wereldwijd gedistribueerde toepassingen te verminderen.
Wanneer u Container Registry implementeert en geo-replicatie inschakelt, gebruikt Microsoft Azure Traffic Manager om aanvragen van gegevensvlakken tussen uw replica's te distribueren en automatisch een failover tussen replica's uit te voeren als een regionale replica niet beschikbaar is.
Geo-replicatie van Container Registry is niet afhankelijk van gekoppelde Azure-regio's. U kunt elke combinatie van Azure-regio's voor replicatie selecteren op basis van uw specifieke geografische, prestatie- en nalevingsvereisten. Elk geo-gerepliceerd register fungeert als een registereindpunt. Het ondersteunt de meeste registerbewerkingen, waaronder pushes van installatiekopieën, pulls en beheertaken.
In deze sectie wordt informatie over geo-replicatie samengevat, omdat deze betrekking heeft op betrouwbaarheid. Zie Geo-replicatie in Container Registry voor meer informatie.
Ondersteuning voor regio
Geo-replicatie is beschikbaar in alle Azure-regio's waar de Premium-laag wordt ondersteund. U kunt repliceren naar elke combinatie van regio's, ongeacht of Azure deze regio's paren.
Requirements
U moet de Premium-laag gebruiken om geo-replicatie in te schakelen.
Considerations
Zone-redundante replica's: Elke replica die u in een regio met beschikbaarheidszones maakt, is automatisch zone-redundant.
Besturingsvlak: Het besturingsvlak draait in de thuisregio. Als de thuisregio niet beschikbaar is, zijn bewerkingen van het besturingsvlak niet beschikbaar en kunt u de configuratie van het register mogelijk niet wijzigen.
Taken: Container Registry-taken ondersteunen momenteel geen geo-replica's. Taken worden altijd uitgevoerd in de basisregio. Als de thuisregio niet beschikbaar is, wordt de taak niet uitgevoerd.
Cost
Elke geografisch gerepliceerde regio wordt afzonderlijk gefactureerd volgens de prijs van de Premium-laag voor de respectieve regio. Kosten voor uitgaand verkeer zijn ook van toepassing op gegevensoverdracht tussen regio's tijdens de initiële replicatie en doorlopende synchronisatie.
Ondersteuning voor meerdere regio's configureren
Geo-replicatie kan worden geconfigureerd tijdens het maken van het register of toegevoegd aan bestaande Premium-registers. Geo-replicatie kan worden geconfigureerd via Azure Portal, de Azure CLI, Azure PowerShell of Azure Resource Manager-sjablonen.
Maak een geo-gerepliceerd register. Configureer geo-replicatie na het maken van het register door extra regio's op te geven.
Schakel geo-replicatie in voor een bestaand register. Als u mogelijkheden voor geo-replicatie wilt inschakelen, moet u bestaande Basic- of Standard-laagregisters upgraden naar de Premium-laag. U kunt de replicatieregio's op elk gewenst moment wijzigen. Zie Geo-replicatie configureren voor meer informatie.
Schakel geo-replicatie uit. Verwijder afzonderlijke regionale replica's via de Azure-portal of opdrachtregelhulpprogramma's. Het register van de basisregio kan niet worden verwijderd.
Gedrag wanneer alle regio's in orde zijn
In deze sectie wordt beschreven wat u kunt verwachten wanneer een register is geconfigureerd voor geo-replicatie en alle regio's operationeel zijn.
Verkeersroutering tussen regio's: Container Registry werkt in een actief-actief-configuratie waarbij elk regionaal eindpunt alle bewerkingen van het gegevensvlak onafhankelijk kan verwerken, inclusief lees- en schrijfbewerkingen. Gegevensvlakbewerkingen, zoals push- en pull-bewerkingen voor containers, worden automatisch gerouteerd met Traffic Manager met criteria op basis van prestaties om het optimale regionale eindpunt voor prestaties te bepalen.
Gegevensreplicatie tussen regio's: Geo-replicatie synchroniseert automatisch containerinstallatiekopieën en artefacten in alle geconfigureerde regio's met behulp van asynchrone replicatie met uiteindelijke consistentie. De service maakt gebruik van inhoudsadressenbare opslag om alleen de unieke afbeeldingslagen efficiënt te repliceren. Deze benadering minimaliseert het bandbreedtegebruik en de replicatietijd. Lees- en schrijfbewerkingen werken in alle geografisch gerepliceerde regio's. Wijzigingen die in elke regio zijn aangebracht, worden gerepliceerd naar alle andere regio's.
De replicatie wordt doorgaans binnen enkele minuten na wijzigingen voltooid. Er is echter geen garantie voor tijdsinstellingen voor gegevensreplicatie. Het kan langer duren voordat grote containerinstallatiekopieën of updates met een hoge frequentie in alle regio's worden gerepliceerd.
Gedrag tijdens een regiofout
In deze sectie wordt beschreven wat u kunt verwachten wanneer een register is geconfigureerd voor geo-replicatie en er een storing optreedt in de primaire regio.
Wanneer een regio niet beschikbaar is, kunnen containerbewerkingen alternatieve regionale eindpunten blijven gebruiken.
Detectie en reactie: Container Registry bewaakt de status van elke regionale replica en is verantwoordelijk voor het omleiden van verkeer naar een andere regio.
Meldingen: Microsoft informeert u niet automatisch wanneer een regio niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele regiofouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.
U kunt ook metrische gegevens over de beschikbaarheid van het register bewaken voor elk regionaal eindpunt in Azure Monitor.
Actieve aanvragen: Actieve aanvragen die momenteel in vlucht naar een niet-beschikbare regio zijn, mislukken en moeten opnieuw worden geprobeerd, zodat ze kunnen worden omgeleid naar een gezonde regio.
Verwachte gegevensverlies: Recente schrijfbewerkingen in de defecte regio worden mogelijk niet gerepliceerd naar andere regio's. Deze fout betekent dat ze mogelijk verloren gaan totdat de regio wordt hersteld. Normaal gesproken is het gegevensverlies naar verwachting minder dan 15 minuten, maar dat is niet gegarandeerd.
Verwachte downtime: Voor bewerkingen in het gegevensvlak wordt een kleine hoeveelheid downtime verwacht voor bewerkingen in het gegevensvlak terwijl de failover is voltooid, wat doorgaans 1 tot 2 minuten duurt.
Als de thuisregio niet beschikbaar is, zijn besturingsvlakbewerkingen niet beschikbaar totdat de regio is hersteld.
Verkeer omleiden: Wanneer een regio niet beschikbaar is, worden containerbewerkingen automatisch doorgestuurd naar een andere replica in een gezonde regio. Clients hoeven het eindpunt waarin ze communiceren met het register niet te wijzigen. Microsoft verwerkt automatisch routering, failover en failback.
Regio herstel
Wanneer een regio wordt hersteld, worden gegevensvlakbewerkingen automatisch hervat voor dat regionale eindpunt via Traffic Manager-routering. De service synchroniseert eventuele wijzigingen die optreden tijdens de storing met behulp van asynchrone replicatie met uiteindelijke consistentie.
Test voor regiofouten
U kunt de fout van een van de regio's die aan uw register zijn gekoppeld niet simuleren, maar u kunt de mogelijkheid van uw toepassing testen om een failover uit te schakelen tussen regio's. U kunt regionale failover simuleren door geo-replica's tijdelijk uit te schakelen, waardoor ze worden verwijderd uit Traffic Manager-routering. Vervolgens kunt u controleren of containerbewerkingen een failover naar alternatieve regio's hebben uitgevoerd zonder dat er sprake is van een regionale storing. Zie Routering naar replicatie tijdelijk uitschakelen voor meer informatie.
Wanneer u de replica opnieuw inschakelt, hervat Traffic Manager het routeren van verkeer naar de replica die opnieuw is ingeschakeld. Metagegevens en afbeeldingen worden ook gesynchroniseerd met uiteindelijke consistentie met de replica die opnieuw is ingeschakeld om gegevensconsistentie in alle regio's te garanderen.
Backups en herstel
Container Registry ondersteunt het exporteren van containerinstallatiekopieën en artefacten van uw register naar externe opslag of alternatieve registers. Gebruik de import- en exportmogelijkheden van Container Registry of standaard Docker-opdrachten om kopieën van kritieke containerinstallatiekopieën te maken voor scenario's voor herstel na noodgevallen.
Voor de meeste oplossingen hoeft u niet uitsluitend te vertrouwen op back-ups. Gebruik in plaats daarvan de andere mogelijkheden die in deze handleiding worden beschreven om uw tolerantievereisten te ondersteunen. Back-ups beschermen echter tegen enkele risico's die andere benaderingen niet opleveren. Zie Wat zijn redundantie, replicatie en back-up? voor meer informatie.
Diensteniveauovereenkomst
De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.