Delen via

Betrouwbaarheid in Azure Container Instances

In dit artikel wordt ondersteuning voor betrouwbaarheid in Azure Container Instances beschreven. Dit biedt een eenvoudige manier om Linux- of Windows-containers uit te voeren in Azure, zonder dat u virtuele machines (VM's) hoeft te beheren of een complexere service op een hoger niveau hoeft te gebruiken.

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 hoe deze mogelijkheden werken binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en uptime doelstellingen.

In dit artikel wordt beschreven hoe u Azure Container Instances tolerant maakt voor verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone en regiostoringen. Hierin worden enkele belangrijke inlichtingen over de Service Level Agreement (SLA) van Azure Container Instances uitgelicht.

Aanbevelingen voor productie-implementatie voor betrouwbaarheid

Als u de betrouwbaarheid van productietoepassingen wilt vergroten die zijn gebouwd op Container Instances, raden we u aan de volgende acties uit te voeren:

Overzicht van betrouwbaarheidsarchitectuur

Als u Container Instances wilt gebruiken, implementeert u een containergroep. Een containergroep bevat een of meer containers. Elke container wordt gemaakt van een containerimage, die wordt opgeslagen in een register zoals Azure Container Registry.

Alle containers in een containergroep worden samen geïmplementeerd als één logische eenheid en delen dezelfde fysieke infrastructuur.

Het volgende diagram toont de relatie tussen containergroepen, containers en image-bestanden.

Diagram met een containergroep met twee containers. Elke container maakt gebruik van een afzonderlijke image in een registry.

Container Instances biedt de volgende functies voor het beheren van containergroepen:

  • NGroups (preview) biedt een set mogelijkheden voor het beheren van meerdere gerelateerde containergroepen. Wanneer u een NGroup maakt, definieert u het aantal containergroepen dat moet worden gemaakt. Container Instances biedt mogelijkheden zoals geautomatiseerde upgrade-implementaties en het verspreiden van containergroepen in beschikbaarheidszones.

  • Stand-bypools maken een pool van vooraf ingerichte containergroepen die kunnen worden gebruikt als reactie op binnenkomend verkeer. Standbypools zijn ontworpen om het aanmaken van containergroepen te optimaliseren en zijn niet bedoeld om de robuustheid van uw systeem te vergroten.

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.

Door Microsoft geleverde SDK's verwerken meestal tijdelijke fouten. Omdat u uw eigen toepassingen op Container Instances host, moet u stappen ondernemen om de kans op tijdelijke fouten te verminderen:

  • Voer meerdere containergroepen uit voor belangrijke workloads om ervoor te zorgen dat een fout in één container of containergroep niet van invloed is op uw hele toepassing.

  • Ontwerp uw applicatiecode om bestand te zijn tegen tijdelijke fouten in services waarmee u verbinding maakt, bijvoorbeeld door gebruik te maken van opnieuw probeerbeleid met backoffstrategieën.

Zie Problemen tijdens runtime voor meer informatie over andere fouten die zich tijdens runtime kunnen voordoen en hoe u erop kunt reageren problemen tijdens de runtime van de containergroep.

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.

Container Instances ondersteunt beschikbaarheidszones op verschillende manieren, afhankelijk van hoe u uw containergroepen implementeert:

  • Handmatig gemaakte containergroepen: Een afzonderlijke containergroep is een zonegebonden resource, wat betekent dat deze kan worden geïmplementeerd in één beschikbaarheidszone die u selecteert. Alle containers binnen de groep worden uitgerold in dezelfde beschikbaarheidszone. Als deze beschikbaarheidszone een storing heeft, kunnen de containergroep en alle bijbehorende containers downtime ondervinden.

    In het volgende diagram ziet u een containergroep die handmatig is geïmplementeerd in beschikbaarheidszone 1:

    Diagram dat een containergroep toont met twee containers die in één beschikbaarheidszone zijn geplaatst.

    Opmerking

    Om ervoor te zorgen dat uw toepassing blijft worden uitgevoerd wanneer één zone in de regio een storing ondervindt, raden we u aan minimaal twee containergroepen te maken in twee verschillende beschikbaarheidszones.

    Als u geen beschikbaarheidszones opgeeft die moeten worden gebruikt voor uw containergroep, is dit niet-zonegebonden of regionaal, wat betekent dat deze mogelijk in een beschikbaarheidszone binnen de regio of binnen dezelfde zone wordt geplaatst. Als er een beschikbaarheidszone in de regio een probleem heeft, kan uw containergroep downtime ondervinden.

  • NGroups: Wanneer u een NGroup implementeert, kunt u een of meer zones opgeven waarin u deze wilt implementeren. Als u een NGroup implementeert in twee of meer zones, is dit een zone-redundante NGroup en veroorzaakt een storing in één beschikbaarheidszone alleen problemen voor de containergroepen binnen de betrokken zone.

    In het volgende diagram ziet u een NGroup die is geïmplementeerd in drie beschikbaarheidszones:

    Diagram met een NGroup met drie containergroepen, geïmplementeerd in drie beschikbaarheidszones.

    Als u geen beschikbaarheidszones opgeeft die u voor uw NGroup wilt gebruiken, is deze niet-zonegebonden en ondervindt deze mogelijk downtime als er een beschikbaarheidszone in de regio een probleem heeft.

  • Stand-bypools: Wanneer u een stand-bypool implementeert, kunt u desgewenst een of meer zones opgeven. Het platform kan containers aanvragen voor de zones die u selecteert.

    Stand-bypools zijn echter niet zone-redundant of zonebestendig omdat er geen garantie is dat containers in meerdere zones worden gemaakt. Als er een zonestoring optreedt, is het mogelijk dat alle containers in de pool in de betrokken zone worden geplaatst.

    Omdat stand-bypools niet zijn ontworpen ter ondersteuning van tolerantie voor zonefouten, beschrijft deze handleiding niet het gedetailleerde gedrag van stand-bypools met beschikbaarheidszones.

    Belangrijk

    Stand-bypools zijn niet ontworpen om zonebestendig te zijn. Ze mogen niet worden gebruikt voor workloads waarvoor tolerantie is vereist voor zonefouten.

Ondersteuning voor regio

Zonegebonden implementaties van containergroepen worden ondersteund in alle regio's met beschikbaarheidszones.

Requirements

  • Zonegebonden implementaties zijn beschikbaar voor Linux- en Windows Server 2019-containergroepen.

  • Als u een beschikbaarheidszone wilt selecteren, moet u de Standard-SKU gebruiken. Zonegebonden containergroepen zijn niet beschikbaar met de Vertrouwelijke SKU.

Overwegingen

Spot-containers bieden geen ondersteuning voor beschikbaarheidszones en zijn altijd niet-zonegebonden.

Kosten

Er zijn geen extra kosten verbonden aan het configureren van beschikbaarheidszones voor een containergroep.

Ondersteuning voor beschikbaarheidszones configureren

  • Maak containergroepen met ondersteuning voor beschikbaarheidszones. De benadering die u gebruikt om beschikbaarheidszones te configureren, is afhankelijk van hoe u containergroepen maakt.

  • Schakel ondersteuning voor beschikbaarheidszones in voor bestaande resources. De benadering die u gebruikt om beschikbaarheidszones te configureren, is afhankelijk van hoe u containergroepen maakt.

    • Handmatig gemaakte containergroepen: U kunt beschikbaarheidszones niet inschakelen voor een bestaande niet-zonegebonden containergroep. U moet de containergroep verwijderen en een zonegebonden containergroep maken.

    • NGroups: U kunt beschikbaarheidszones niet inschakelen voor een bestaande niet-zonegebonden NGroup. U moet de NGroup verwijderen en een zone-redundante NGroup maken.

    • Stand-bypools: U kunt beschikbaarheidszones niet inschakelen voor een bestaande niet-zonegebonden stand-bypool. U moet de containergroep verwijderen en een nieuwe stand-bypool maken die gebruikmaakt van meerdere beschikbaarheidszones.

  • Verplaats containergroepen tussen zones of schakel ondersteuning voor beschikbaarheidszones uit. De methode die u gebruikt om beschikbaarheidszones te wijzigen, is afhankelijk van hoe u containergroepen maakt.

    • Handmatig gemaakte containergroepen: Als u de beschikbaarheidszone van een containergroep wilt wijzigen, moet u de containergroep verwijderen en een andere containergroep maken met de nieuwe beschikbaarheidszone. Zie de volgende resources voor meer informatie over het verwijderen van de containergroep:

    • NGroups: U kunt zones toevoegen aan een NGroup, maar u kunt geen zones verwijderen.

    • Stand-bypools: U kunt zones toevoegen aan een stand-bypool, maar u kunt geen zones verwijderen.

Distributie van containergroepen

De manier waarop containergroepen worden verdeeld over beschikbaarheidszones, is afhankelijk van hoe u uw containergroepen implementeert.

  • Handmatig gemaakte containergroepen: U bent verantwoordelijk voor het distribueren van uw handmatig gemaakte containergroepen over meerdere beschikbaarheidszones.

  • NGroups: Tijdens afschalingsbewerkingen verwijdert NGroups willekeurig exemplaren, wat mogelijk geen verspreide beschikbaarheidszones behoudt. Scale-outbewerkingen proberen het evenwicht over de zones opnieuw te herstellen.

  • Stand-bypools: Een stand-bypool kan containers maken in een van de beschikbaarheidszones die u voor de pool configureert. Containers kunnen echter niet in meerdere zones worden gemaakt. Stand-bypools mogen niet worden gebruikt voor workloads waarvoor tolerantie is vereist voor zonefouten.

Capaciteitsplanning en -beheer

Als u zich wilt voorbereiden op een fout in de beschikbaarheidszone, kunt u overwegen om het aantal containergroepen dat u implementeert te overprovisioneren . Met deze aanpak kan de oplossing enige capaciteitsverlies tolereren en blijven werken zonder verslechterde prestaties. Zie Capaciteit beheren met overprovisioning voor meer informatie.

De benadering die u gebruikt voor het overprovisionen van containergroepen, is afhankelijk van de manier waarop u uw containergroepen implementeert.

  • Handmatig gemaakte containergroepen: U bent verantwoordelijk voor het plannen van de capaciteit van uw handmatig gemaakte containergroepen, inclusief het plannen van het aantal containergroepen dat in elke zone moet worden geïmplementeerd.

  • NGroup: Overweeg om de capaciteit van uw NGroup te overprovisioneren om het verlies van een zone te tolereren.

  • Standbypools: Standbypools zijn niet ontworpen om resistent te zijn tegen zonefouten. Overweeg om meerdere stand-bypools in verschillende zones te gebruiken of NGroups te gebruiken.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer Container Instances-resources zijn geconfigureerd voor ondersteuning van beschikbaarheidszones en alle beschikbaarheidszones operationeel zijn.

  • Verkeersroutering tussen zones: U bent verantwoordelijk voor het routeren van verkeer naar uw containers. U kunt bijvoorbeeld Azure Application Gateway gebruiken als gateway en load balancer voor uw containergroepen.

    Als u NGroups of stand-bypools gebruikt, bent u verantwoordelijk voor taakverdeling in elke container. U moet ook uw verkeersrouteringssysteem configureren om de status van elke containergroep te detecteren en verkeer zo nodig om te leiden naar een alternatieve groep.

  • Gegevensreplicatie tussen zones: Containers en containergroepen zijn staatloos. U kunt uw eigen bestandsshare toevoegen of verbinding maken met databases of andere opslagservices vanuit uw toepassingen. U bent verantwoordelijk voor het garanderen dat deze bestandsshares en opslagservices zonebestendig zijn. Bekijk de betrouwbaarheidshandleidingen voor elke service om te begrijpen hoe u elke onderdeelzone tolerant maakt.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer Container Instances-resources zijn geconfigureerd voor ondersteuning van beschikbaarheidszones en er een storing in de beschikbaarheidszone is.

  • Detectie en reactie: Verantwoordelijkheid voor het detecteren van zonefouten en het bijbehorende antwoord is afhankelijk van de wijze waarop u uw containergroepen implementeert.

    • Handmatig gemaakte containergroepen: U moet het verlies van een beschikbaarheidszone detecteren en een failover initiëren naar een secundaire containergroep die u in een andere beschikbaarheidszone maakt.

    • NGroups: Het Container Instances-platform is verantwoordelijk voor het detecteren van een fout in een beschikbaarheidszone en reageert.

      U bent echter verantwoordelijk voor het doorsturen van verkeer naar containers in een gezonde zone.

    • Standby-pools: Het platform van Container Instances biedt geen garantie om te reageren op verstoringen in zones voor standby-pools. Stand-bypools mogen niet worden gebruikt voor workloads waarvoor tolerantie is vereist voor zonefouten.

  • Melding: 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.

  • Actieve verzoeken: Als een zone mislukt, zullen alle containers die in die zone draaien, waarschijnlijk zullen stoppen, met inbegrip van de actieve werkzaamheden die ze afhandelen

  • Verwachte gegevensverlies: Omdat containers en containergroepen staatloos zijn, is er geen gegevensverlies verwacht bij een zonefout. U bent echter verantwoordelijk voor het garanderen dat elk onderdeel in uw workload zonebestendig is, inclusief opslagservices en databases.

  • Verwachte downtime: De downtime die u van een zonefout kunt verwachten, is afhankelijk van de wijze waarop u uw containergroepen implementeert.

    • Handmatig gemaakte containergroepen: Als zonegebonden containergroepen niet beschikbaar zijn, zijn uw containergroep en de bijbehorende containers niet beschikbaar totdat de beschikbaarheidszone wordt hersteld.

    • NGroups: Als één zone uitvalt, blijft uw toepassing beschikbaar voor NGroups, omdat de resterende containergroepen binnen de NGroups in andere zones blijven worden uitgevoerd. Er wordt geen downtime verwacht.

    • Standby-pools: Standby-pools bieden geen zone-resiliëntie. Als alle containergroepen in de stand-bypool zich in één zone bevinden, is het mogelijk dat alle containergroepen en hun containers niet meer beschikbaar zijn totdat de beschikbaarheidszone wordt hersteld.

  • Verkeer omleiden: Omdat u verantwoordelijk bent voor het routeren van verkeer naar uw containers, bent u ook verantwoordelijk voor het omleiden van verkeer als een containergroep uitvalt vanwege een storing in de beschikbaarheidszone.

Zoneherstel

Nadat de zone is hersteld, start het Azure-platform containergroepen die waren gestopt automatisch opnieuw op. De gebruiker hoeft verder niets te doen.

Testen op zonefouten

Er is geen manier om een storing in de beschikbaarheidszone te simuleren die uw containergroep bevat. U kunt echter handmatig upstream-gateways of load balancers configureren om verkeer om te leiden naar een andere containergroep in een andere beschikbaarheidszone.

Tolerantie voor storingen in de hele regio

Container Instances is een service met één regio. Als de regio niet meer beschikbaar is, zijn uw containergroepen en de bijbehorende containers ook niet beschikbaar.

Aangepaste oplossingen voor meerdere regio's voor veerkracht

U kunt eventueel afzonderlijke containergroepen in meerdere regio's implementeren. U bent verantwoordelijk voor het implementeren en configureren van de containergroepen in elke regio. U moet ook taakverdeling configureren met behulp van een service zoals Azure Traffic Manager of Azure Front Door. U bent verantwoordelijk voor gegevenssynchronisatie, failover en failback.

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.

Verwante inhoud

  • Last updated on