Delen via

Wat is Azure Resource Manager?

  • Artikel

Azure Resource Manager is de implementatie- en beheerservice voor Azure. Het biedt een beheerlaag waarmee u resources in uw Azure-account kunt maken, bijwerken en verwijderen. U gebruikt beheerfuncties zoals toegangsbeheer, vergrendelingen en tags om uw resources na de implementatie te beveiligen en te ordenen.

In de volgende video worden de basisconcepten van Resource Manager behandeld:

Consistente beheerlaag

Wanneer u een aanvraag verzendt via een van de Azure-API's, hulpprogramma's of SDK's, ontvangt Resource Manager de aanvraag. De aanvraag wordt geverifieerd en geautoriseerd voordat deze naar de juiste Azure-service wordt doorgestuurd. Omdat alle aanvragen worden verwerkt via dezelfde API, ziet u consistente resultaten en mogelijkheden in de verschillende hulpprogramma's.

In het volgende diagram ziet u de rol die Resource Manager speelt tijdens Azure-aanvragen:

Diagram met de rol van Resource Manager tijdens Azure-aanvragen.

Alle mogelijkheden die in Azure Portal beschikbaar zijn, zijn ook beschikbaar via PowerShell, de Azure CLI, REST API's en client-SDK's. Wanneer API's nieuwe functionaliteit introduceren, weerspiegelt dit binnen 180 dagen na de eerste release in de portal.

Belangrijk

Resource Manager stopt het ondersteunen van protocollen ouder dan TLS 1.2 op 1 maart 2025. Zie Migreren naar TLS 1.2 voor Azure Resource Manager voor meer informatie.

Terminologie

Als u geen ervaring hebt met Resource Manager, bent u mogelijk niet bekend met de volgende termen:

  • resource : een beheerbaar item dat beschikbaar is via Azure. Voorbeelden van resources zijn virtuele machines, opslagaccounts, web-apps, databases en virtuele netwerken. Resourcegroepen, abonnementen, beheergroepen en tags zijn ook resources.

  • resourcegroep - een container met gerelateerde resources voor een Azure-oplossing. De resourcegroep bevat die resources die u als groep wilt beheren. U bepaalt welke resources deel uitmaken van een resourcegroep op basis van wat voor uw organisatie het meest zinvol is. Zie Wat is een resourcegroep?

  • resourceprovider - een service die zorgt voor Azure-resources. Een veelgebruikte resourceprovider is bijvoorbeeld Microsoft.Compute, die de virtuele machine levert. Microsoft.Storage is een andere veel voorkomende resourceprovider. Zie Azure-resourceproviders en -typen.

  • Declaratieve syntaxis: syntaxis waarmee u kunt aangeven: 'Dit is wat ik wil maken', zonder dat u de reeks programmeeropdrachten hoeft te schrijven om deze te maken. ARM-sjablonen en Bicep-bestanden zijn voorbeelden van declaratieve syntaxis. In deze bestanden definieert u de eigenschappen voor de infrastructuur die in Azure moet worden geïmplementeerd.

  • ARM-sjabloon : een JSON-bestand (JavaScript Object Notation) dat een of meer resources definieert die moeten worden geïmplementeerd in een resourcegroep, abonnement, beheergroep of tenant. Gebruik de sjabloon om de resources consistent en herhaaldelijk te implementeren. Zie Wat zijn ARM-sjablonen? voor een overzicht van het implementeren van sjablonen.

  • Bicep-bestand: een bestand voor het declaratief implementeren van Azure-resources. Bicep is een taal die is ontworpen om de beste ontwerpervaring te bieden voor oplossingen voor infrastructuur als code in Azure. Zie Wat is Bicep? voor meer informatie over Bicep.

  • extensieresource : een resource die wordt toegevoegd aan de mogelijkheden van een andere resource. Een roltoewijzing is bijvoorbeeld een extensieresource. U past een roltoewijzing toe op een andere resource om toegang op te geven. Zie Extensiebronnen.

Zie basisconcepten van Azure voor meer definities van Azure-terminologie.

De voordelen van Resource Manager

Met Resource Manager kunt u het volgende doen:

  • Uw infrastructuur beheren via declaratieve sjablonen in plaats van scripts.

  • Alle resources voor uw oplossing implementeren, beheren en bewaken als groep, in plaats van deze resources afzonderlijk te verwerken.

  • Uw oplossing gedurende de ontwikkelingscyclus herhaaldelijk implementeren en erop vertrouwen dat de resources consistent worden geïmplementeerd.

  • De afhankelijkheden tussen resources zo definiëren dat deze in de juiste volgorde worden geïmplementeerd.

  • Toegangsbeheer toepassen op alle services omdat op rollen gebaseerde toegangscontrole van Azure (Azure RBAC) is geïntegreerd in het beheerplatform.Toegangsbeheer toepassen op alle services omdat op rollen gebaseerd toegangsbeheer (RBAC) is geïntegreerd in het beheerplatform.

  • Tags toepassen op de resources om alle resources in uw abonnement op een logische manier te organiseren.

  • Maak de facturering van uw organisatie duidelijker door kosten voor een groep resources met dezelfde tag weer te geven.

Bereik

Azure biedt vier beheerniveaus: beheergroepen, abonnementen, resourcegroepen en resources. In het volgende diagram worden deze lagen gevisualiseerd:

Diagram dat de vier bereikniveaus in Azure illustreert: beheergroepen, abonnementen, resourcegroepen en resources.

U past beheerinstellingen toe op elk van deze bereikniveaus. Het niveau dat u selecteert, bepaalt hoe breed de instelling wordt toegepast. Lagere niveaus nemen instellingen over van hogere niveaus. Als u een beleid bijvoorbeeld toepast op het abonnement, wordt het beleid toegepast op alle resourcegroepen en resources in het abonnement. Wanneer u een beleid toepast op de resourcegroep, wordt dit beleid toegepast op de resourcegroep en alle bijbehorende resources. Een andere resourcegroep beschikt echter niet over die beleidstoewijzing.

Zie Wat is Microsoft Entra ID? Voor meer informatie over het beheren van identiteiten en toegang in Azure.

U kunt sjablonen implementeren op tenants, beheergroepen, abonnementen of resourcegroepen.

Wat is een resourcegroep?

Een resourcegroep is een container die u gebruikt voor het beheren van gerelateerde resources voor een Azure-oplossing. Met behulp van een resourcegroep kunt u wijzigingen coördineren tussen resources die zijn gerelateerd. U kunt bijvoorbeeld een update implementeren in de resourcegroep en erop vertrouwen dat de resources worden bijgewerkt in een gecoördineerde bewerking. Als u klaar bent met de oplossing, kunt u de resourcegroep verwijderen en weten dat alle resources worden verwijderd.

Er zijn enkele belangrijke overwegingen bij het definiëren van uw resourcegroep:

  • Alle resources in uw resourcegroep moeten dezelfde levenscyclus delen. U implementeert ze samen, werkt ze samen bij en verwijdert ze samen. Een server is bijvoorbeeld één resource. Als deze moet bestaan in een andere implementatiecyclus, moet deze zich in een andere resourcegroep bevinden.

  • Elke resource kan maar in één resourcegroep voorkomen.

  • U kunt een resource op elk gewenst moment toevoegen aan of verwijderen uit een resourcegroep.

  • U kunt een resource van de ene naar de andere resourcegroep verplaatsen. Zie Azure-resources verplaatsen naar een nieuwe resourcegroep of een nieuw abonnement voor meer informatie.

  • De resources in een resourcegroep kunnen zich in verschillende regio's bevinden dan de resourcegroep, maar we raden u aan dezelfde locatie te gebruiken. Zie welke locatie moet ik gebruiken voor mijn resourcegroep?

  • Een resourcegroep kan worden gebruikt voor het bepalen van de mate van toegangsbeheer voor beheertaken. U kunt Azure-beleid, -rollen of -resourcevergrendelingen gebruiken om een resourcegroep te beheren.

  • U kunt tags toepassen op een resourcegroep. De resources in de resourcegroep nemen deze tags niet over.

  • Een resource kan verbinding maken met resources in andere resourcegroepen. Dit scenario is gebruikelijk wanneer de twee resources gerelateerd zijn, maar niet dezelfde levenscyclus hebben. U kunt bijvoorbeeld een web-app hebben die verbinding maakt met een database in een andere resourcegroep.

  • Wanneer u een resourcegroep verwijdert, worden ook alle resources in de resourcegroep verwijderd. Zie Azure Resource Manager-resourcegroep en resourceverwijdering voor informatie over hoe Resource Manager deze verwijderingen organiseert.

  • U kunt maximaal 800 exemplaren van een resourcetype implementeren in elke resourcegroep. Sommige resourcetypen worden uitgesloten van de limiet van 800 exemplaren. Zie resourcegroeplimieten voor meer informatie.

  • Sommige resources kunnen buiten een resourcegroep bestaan. Deze resources worden geïmplementeerd in het abonnement, de beheergroep of de tenant. In deze bereiken worden alleen specifieke resourcetypen ondersteund.

  • Als u een resourcegroep wilt maken, gebruikt u Azure Portal, PowerShell, de Azure CLI of een ARM-sjabloon.

Welke locatie moet ik gebruiken voor mijn resourcegroep?

Wanneer u een resourcegroep maakt, moet u een locatie voor die resourcegroep opgeven.

U vraagt zich misschien af waarom een resourcegroep een locatie nodig heeft en waarom de locatie van de resourcegroep van belang is als resources locaties buiten een resourcegroep kunnen hebben.

In de resourcegroep worden metagegevens over resources opgeslagen. Wanneer u een locatie voor de resourcegroep opgeeft, geeft u ook op waar die metagegevens worden opgeslagen. Om nalevingsredenen moet u er mogelijk voor zorgen dat uw gegevens in een bepaalde regio worden opgeslagen.

Door alle besturingsvlakbewerkingen te routeren via de locatie van de resourcegroep, kan de resourcegroep in een consistente status blijven. Wanneer u een locatie voor een resourcegroep selecteert, is het raadzaam dat u een locatie selecteert dicht bij de locatie waar uw besturingsbewerkingen vandaan komen. Normaal gesproken is deze locatie de locatie die het dichtst bij u in de buurt is. Deze routeringsvereiste is alleen van toepassing op besturingsvlakbewerkingen voor de resourcegroep. Dit heeft geen invloed op aanvragen die naar uw toepassingen worden verzonden.

Als de regio van een resourcegroep tijdelijk niet beschikbaar is, kunt u mogelijk geen resources in de resourcegroep bijwerken omdat de metagegevens niet beschikbaar zijn. De resources in andere regio's werken nog steeds zoals verwacht, maar u kunt ze mogelijk niet bijwerken. Deze voorwaarde kan ook van toepassing zijn op globale resources, zoals Azure DNS, Azure Privé-DNS zones, Azure Traffic Manager en Azure Front Door. Zie de naslaglijst van de Azure Resource Graph-tabel en het resourcetype om de resources en metagegevens weer te geven die Door Resource Manager worden beheerd.

Wanneer de regio van een resourcegroep niet beschikbaar is, kan Resource Manager de metagegevens van uw resource niet bijwerken en uw schrijfaanroepen blokkeren. Als u de impact van regionale storingen wilt verminderen, is het raadzaam om uw resources en resourcegroep in dezelfde regio te vinden. Dit vermindert de kans dat een regio niet beschikbaar is omdat uw resources en metagegevens zich in één regio bevinden in plaats van meerdere regio's.

Zie de controlelijst voor tolerantie voor specifieke Azure-services voor meer informatie over het bouwen van betrouwbare toepassingen.

Tolerantie van Resource Manager

Resource Manager is ontworpen voor tolerantie en continue beschikbaarheid. Bewerkingen van Resource Manager en besturingsvlak (aanvragen verzonden naar management.azure.com) in de REST API:

  • Verdelen over regio's. Resource Manager heeft een afzonderlijk exemplaar in elke Azure-regio, wat betekent dat als een Resource Manager-exemplaar in één regio uitvalt, dit geen invloed heeft op de beschikbaarheid van de service in een andere regio; hetzelfde geldt voor andere Azure-services. Hoewel Resource Manager wordt verdeeld over regio's, zijn sommige services regionaal. Dit onderscheid betekent dat, terwijl de eerste verwerking van de besturingsvlakbewerking tolerant is, de aanvraag mogelijk vatbaar is voor regionale storingen wanneer deze naar de service wordt doorgestuurd.

  • Distribueer over beschikbaarheidszones (en regio's) op locaties met meerdere beschikbaarheidszones. Deze distributie zorgt ervoor dat wanneer een regio een of meer zones verliest, Resource Manager een failover naar een andere zone of regio kan uitvoeren. Het biedt nog steeds de mogelijkheid van het besturingsvlak voor de resources.

  • Niet afhankelijk van één logisch datacenter.

  • Worden niet uitgepakt voor onderhoudsactiviteiten.

Deze tolerantie is van toepassing op services die aanvragen ontvangen via Resource Manager. Azure Key Vault is één service die profiteert van deze consistentie.

Gelijktijdige bewerkingen oplossen

Gelijktijdige resource-updates kunnen onverwachte resultaten veroorzaken. Wanneer twee of meer bewerkingen tegelijkertijd dezelfde resource proberen bij te werken, detecteert Resource Manager het conflict, kan slechts één bewerking worden voltooid, worden de andere bewerkingen geblokkeerd en wordt een fout geretourneerd. Deze resolutie zorgt ervoor dat uw updates overtuigend en betrouwbaar zijn; u weet de status van uw resources en voorkomt inconsistentie of gegevensverlies.

Als u bijvoorbeeld twee aanvragen (A en B) hebt die proberen om dezelfde resource tegelijkertijd bij te werken en aanvraag A is voltooid voordat aanvraag B, dan slaagt de aanvraag A en mislukt de aanvraag B. Aanvraag B retourneert de 409-fout. Nadat u deze foutcode hebt opgehaald, kunt u de bijgewerkte status van de resource ophalen en bepalen of u aanvraag B opnieuw wilt verzenden.

Volgende stappen