Azure Resource Manager vergeleken met klassieke implementatie: implementatiemodellen en de status van uw resources begrijpen
Notitie
De informatie in dit artikel wordt alleen gebruikt wanneer u een migratie van de klassieke implementatie naar de Azure Resource Manager-implementatie uitvoert.
In dit artikel vindt u informatie over Azure Resource Manager en het klassieke implementatiemodel. Het implementatiemodel van Resource Manager en het klassieke implementatiemodel zijn twee verschillende manieren voor het implementeren en beheren van uw Azure-oplossingen. U gebruikt de modellen via twee verschillende API-sets, en de geïmplementeerde resources kunnen sterk afwijken. De twee modellen zijn niet compatibel met elkaar. In dit artikel worden deze verschillen beschreven.
Om de implementatie en het beheer van resources te vereenvoudigen, raden we u aan Resource Manager te gebruiken voor alle nieuwe resources. Implementeer indien mogelijk bestaande resources opnieuw via Resource Manager. Als u Cloud Services hebt gebruikt, kunt u uw oplossing migreren naar Cloud Services (uitgebreide ondersteuning).
Als u geen toegang hebt tot Resource Manager, kunt u eerst de terminologie bekijken die is gedefinieerd in het overzicht van Azure Resource Manager.
Geschiedenis van de implementatiemodellen
In Azure was in eerste instantie alleen het klassieke implementatiemodel beschikbaar. In dit model waren alle resources zelfstandig en er was geen enkele manier om gerelateerde resources te groeperen. In plaats daarvan moest u handmatig bijhouden welke resources in uw oplossing of toepassing werden gebruikt en niet vergeten om de resources op een gecoördineerde manier te beheren. Als u een oplossing wilde implementeren, moest u elke resource afzonderlijk maken via de portal of een script schrijven waarmee alle bronnen in de juiste volgorde werden geïmplementeerd. Als u een oplossing wilde verwijderen, moest u elke resource afzonderlijk verwijderen. U kunt het toegangsbeheerbeleid voor gerelateerde resources niet eenvoudig toepassen en bijwerken. Ten slotte kunt u geen tags toepassen op resources om ze te labelen met termen waarmee u uw resources kunt bewaken en facturering kunt beheren.
In 2014 werd Azure Resource Manager geïntroduceerd, en daarmee het concept van resourcegroepen. Een resourcegroep is een container voor resources die een gemeenschappelijke levenscyclus delen. Het implementatiemodel van Resource Manager biedt diverse voordelen:
- U kunt alle services voor uw oplossing als een groep implementeren, beheren en bewaken, in plaats van deze services afzonderlijk te verwerken.
- U kunt de oplossing herhaaldelijk implementeren gedurende de levenscyclus en erop vertrouwen dat uw resources op een consistente manier worden geïmplementeerd.
- U kunt toegangsbeheer toepassen op alle resources in de resourcegroep. Deze beleidsregels worden automatisch toegepast wanneer nieuwe resources worden toegevoegd aan de resourcegroep.
- U kunt tags toepassen op de resources om alle resources in uw abonnement op een logische manier te organiseren.
- U kunt JSON (JavaScript Object Notation) gebruiken voor het definiëren van de infrastructuur voor uw oplossing. Het JSON-bestand is in feite de Resource Manager-sjabloon.
- U kunt de afhankelijkheden tussen resources zo definiëren dat deze in de juiste volgorde worden geïmplementeerd.
Toen Resource Manager werd geïntroduceerd, werden alle resources met terugwerkende kracht toegevoegd aan standaardresourcegroepen. Als u nu een resource maakt via een klassieke implementatie, wordt de resource automatisch gemaakt in een standaardresourcegroep voor die service, ook al hebt u tijdens de implementatie geen resourcegroep opgegeven. Alleen bestaande binnen een resourcegroep betekent echter niet dat de resource is geconverteerd naar het Resource Manager-model.
Ondersteuning voor de modellen begrijpen
Er zijn drie mogelijke scenario's:
- Cloud Services (klassiek) biedt geen ondersteuning voor het Resource Manager-implementatiemodel. Cloud Services (uitgebreide ondersteuning) ondersteunt het Resource Manager-implementatiemodel.
- Virtuele machines, opslagaccounts en virtuele netwerken ondersteunen zowel het implementatiemodel van Resource Manager als het klassieke implementatiemodel.
- Alle andere Azure-services ondersteunen Resource Manager.
Als de resource is gemaakt via de klassieke implementatie, geldt voor virtuele machines, opslagaccounts en virtuele netwerken dat u alleen klassieke bewerkingen kunt uitvoeren op de resource. Als de virtuele machine, het opslagaccount of het virtuele netwerk is gemaakt via Resource Manager, moet u alleen Resource Manager-bewerkingen gebruiken. Dit verschil kan problemen geven wanneer uw abonnement een combinatie van resources bevat die zijn gemaakt via Resource Manager en de klassieke implementatie. Deze combinatie van resources kan onverwachte resultaten opleveren omdat de resources geen ondersteuning bieden voor dezelfde bewerkingen.
In sommige gevallen kunt u met een opdracht van Resource Manager gegevens ophalen van een resource die via de klassieke implementatie is gemaakt of een beheertaak uitvoeren zoals het verplaatsen van een klassieke resource naar een andere resourcegroep. Maar deze gevallen mogen niet de indruk geven dat het type Resource Manager-bewerkingen ondersteunt. Stel dat u een resourcegroep hebt met daarin een virtuele machine die is gemaakt met het klassieke implementatiemodel. Als u de volgende PowerShell-opdracht van Resource Manager uitvoert:
Get-AzResource -ResourceGroupName ExampleGroup -ResourceType Microsoft.ClassicCompute/virtualMachines
wordt deze virtuele machine geretourneerd:
Name : ExampleClassicVM
ResourceId : /subscriptions/{guid}/resourceGroups/ExampleGroup/providers/Microsoft.ClassicCompute/virtualMachines/ExampleClassicVM
ResourceName : ExampleClassicVM
ResourceType : Microsoft.ClassicCompute/virtualMachines
ResourceGroupName : ExampleGroup
Location : westus
SubscriptionId : {guid}
Met de cmdlet Get-AzVM van Resource Manager worden echter alleen virtuele machines geretourneerd die zijn geïmplementeerd via Resource Manager. Met de volgende opdracht wordt de virtuele machine die is gemaakt via de klassieke implementatie niet geretourneerd.
Get-AzVM -ResourceGroupName ExampleGroup
Tags worden alleen ondersteund door resources die via Resource Manager zijn gemaakt. U kunt geen tags toepassen op klassieke resources.
Wijzigingen voor reken-, netwerk- en opslagresources
In het volgende diagram ziet u de reken-, netwerk- en opslagresources die zijn geïmplementeerd via Resource Manager.
SRP: Opslagresourceprovider, CRP: Rekenresourceprovider, NRP: Netwerkresourceprovider
Zie Een Virtuele Windows-VM uitvoeren in Azure voor een bijgewerkt diagram van een virtuele-machineoplossing die gebruikmaakt van beheerde schijven.
Dit zijn de verschillende relaties tussen de resources:
- Alle resources bestaan binnen een resourcegroep.
- De virtuele machine is afhankelijk van een specifiek opslagaccount dat is gedefinieerd in de Storage-resourceprovider (SRP) voor het opslaan van schijven in blob-opslag (vereist).
- De virtuele machine verwijst naar een specifieke netwerkinterfacekaart die is gedefinieerd in de netwerkresourceprovider (vereist) en een beschikbaarheidsset die is gedefinieerd in de compute-resourceprovider (optioneel).
- De netwerkinterfacekaart verwijst naar het IP-adres van de virtuele machine (vereist), het subnet van het virtuele netwerk voor de virtuele machine (vereist) en naar een netwerkbeveiligingsgroep (optioneel).
- Het subnet binnen een virtueel netwerk verwijst naar een netwerkbeveiligingsgroep (optioneel).
- Het load balancer-exemplaar verwijst naar de back-endpool met IP-adressen die de netwerkinterfacekaart van een virtuele machine (optioneel) bevatten en verwijst naar een openbare of persoonlijke IP-adres van een load balancer (optioneel).
Dit zijn de onderdelen en hun relaties voor een klassieke implementatie:
De klassieke oplossing voor het hosten van een virtuele machine omvat:
- Cloud Services (klassiek) fungeert als een container voor het hosten van virtuele machines (compute). Azure biedt automatisch virtuele machines met een netwerkinterfacekaart en een IP-adres. Bovendien bevat de cloudservice een instantie van een externe load balancer, een openbaar IP-adres en standaardeindpunten om verkeer van Extern bureaublad en extern PowerShell-verkeer toe te staan voor virtuele Windows-machines en SSH-verkeer (Secure Shell) voor virtuele Linux-machines.
- Een vereist opslagaccount waarin de virtuele harde schijven voor een virtuele machine worden opgeslagen, waaronder het besturingssysteem, tijdelijke en extra gegevensschijven (opslag).
- Een optioneel virtueel netwerk dat fungeert als een extra container, waarin u een subnetstructuur kunt maken en het subnet kunt kiezen waarop de virtuele machine zich bevindt (netwerk).
In de volgende tabel wordt beschreven wat er is veranderd aan de interactie tussen de resourceproviders voor Compute, Network en Storage:
Artikel | Klassiek | Resourcebeheer |
---|---|---|
Cloudservice voor virtuele machines | Cloudservice was een container voor de opslag van de virtuele machines waarvoor de beschikbaarheid van het platform en taakverdeling vereist was. | Cloudservice is niet langer een object dat is vereist voor het maken van een virtuele machine met het nieuwe model. |
Virtuele netwerken | Een virtueel netwerk is optioneel voor de virtuele machine. Als dit is opgenomen, kan het virtuele netwerk niet worden geïmplementeerd met Resource Manager. | Voor de virtuele machine is een virtueel netwerk vereist dat is geïmplementeerd met Resource Manager. |
Storage Accounts | De virtuele machine vereist een opslagaccount waarin de virtuele harde schijven voor het besturingssysteem, tijdelijke en extra gegevensschijven worden opgeslagen. | De virtuele machine vereist een opslagaccount voor het opslaan van de schijven in de blob-opslag. |
Beschikbaarheidssets | U hebt de beschikbaarheid voor het platform aangegeven door hetzelfde AvailabilitySetName te configureren op de virtuele machines. Het maximumaantal foutdomeinen was 2. |
Een beschikbaarheidsset is een resource die beschikbaar wordt gesteld door Microsoft.Compute Provider. Virtuele machines die uiterst beschikbaar moeten zijn, worden opgenomen in de beschikbaarheidsset. Het maximumaantal foutdomeinen is nu 3. |
Affiniteitsgroepen | Voor het maken van virtuele netwerken waren affiniteitsgroepen vereist. Met de introductie van regionale virtuele netwerken is die vereiste echter verwijderd. | Ter vereenvoudiging bestaat het concept Affiniteitsgroepen niet in de API's die worden weergegeven via Azure Resource Manager. |
Taakverdeling | Bij het maken van een cloudservice wordt een impliciete load balancer voor de geïmplementeerde virtuele machines aangemaakt. | De load balancer is een resource die beschikbaar wordt gesteld door de Microsoft.Compute-provider. De primaire netwerkinterface van de virtuele machines waarvoor de taken moeten worden verdeeld moet verwijzen naar de load balancer. Load balancers kunnen intern of extern zijn. Een instantie van de load balancer verwijst naar de back-endpool van IP-adressen met daarin de NIC van een virtuele machine (optioneel) en het openbare of particuliere IP-adres (optioneel) van een load balancer. |
Virtueel IP-adres | Cloud Services krijgt een standaard-VIP (virtueel IP-adres) toegewezen wanneer een VM wordt toegevoegd aan een cloudservice. Het virtuele IP-adres is het adres dat is gekoppeld aan de impliciete load balancer. | Het openbare IP-adres is een resource die beschikbaar wordt gesteld door de Microsoft.Compute-provider. Een openbaar IP-adres kan statisch (gereserveerd) of dynamisch zijn. Dynamische openbare IP-adressen kunnen worden toegewezen aan een load balancer. Openbare IP-adressen kunnen worden beveiligd met beveiligingsgroepen. |
Gereserveerd IP-adres | U kunt een IP-adres in Azure reserveren en dit koppelen aan een cloudservice om ervoor te zorgen dat het IP-adres is vergrendeld. | Een openbaar IP-adres kan in de statische modus worden gemaakt en biedt dezelfde mogelijkheden als een gereserveerd IP-adres. |
Openbaar IP-adres (PIP) per VM | Openbare IP-adressen kunnen ook rechtstreeks aan een VM worden gekoppeld. | Het openbare IP-adres is een resource die beschikbaar wordt gesteld door de Microsoft.Compute-provider. Een openbaar IP-adres kan statisch (gereserveerd) of dynamisch zijn. |
Eindpunten | Invoereindpunten moesten eerder op een virtuele machine worden geconfigureerd voor open connectiviteit voor bepaalde poorten. Een van de algemene modi voor het maken van verbinding met virtuele machines wordt gerealiseerd door het instellen van invoereindpunten. | Inkomende NAT-regels kunnen op load balancers worden geconfigureerd om eindpunten in te schakelen op bepaalde poorten voor verbinding met de VM's. |
DNS-naam | Een cloudservice krijgt een impliciete wereldwijd unieke DNS-naam. Voorbeeld: mycoffeeshop.cloudapp.net . |
DNS-namen zijn optionele parameters die u kunt opgeven voor een openbare IP-adresresource. De FQDN heeft de volgende notatie: <domainlabel>.<region>.cloudapp.azure.com . |
Netwerkinterfaces | De primaire en secundaire netwerkinterface en de eigenschappen ervan worden gedefinieerd als netwerkconfiguratie van een virtuele machine. | De netwerkinterface is een resource die beschikbaar wordt gesteld door Microsoft.Network Provider. De levenscyclus van de netwerkinterface is niet gekoppeld aan een virtuele machine. Het verwijst naar het IP-adres van de virtuele machine (vereist), het subnet van het virtuele netwerk voor de virtuele machine (vereist) en naar een netwerkbeveiligingsgroep (optioneel). |
Zie Verschillende implementatiemodellen gebruiken om vanuit de portal verbinding te maken met virtuele netwerken om te lezen hoe u met behulp van verschillende implementatiemodellen verbinding kunt maken met virtuele netwerken.
Migreren van klassiek naar Resource Manager
Als u uw resources van klassieke implementatie naar Resource Manager-implementatie wilt migreren, raadpleegt u:
- Technische details over door platforms ondersteunde migratie van klassiek naar Azure Resource Manager
- Platformondersteunde migratie van IaaS-resources van het klassieke implementatiemodel naar Azure Resource Manager
- IaaS-resources migreren van klassiek naar Azure Resource Manager met behulp van Azure PowerShell
- IaaS-resources migreren van klassiek naar Azure Resource Manager met behulp van Azure CLI
Veelgestelde vragen
Kan ik een virtuele machine maken met Resource Manager voor implementatie in een virtueel netwerk dat is gemaakt met behulp van het klassieke implementatiemodel?
Deze configuratie wordt niet ondersteund. U kunt Resource Manager niet gebruiken om een virtuele machine te implementeren in een virtueel netwerk dat u hebt gemaakt met behulp van de klassieke implementatie.
Kan ik een virtuele machine maken met Resource Manager op basis van een gebruikersinstallatiekopieën die ik heb gemaakt met het klassieke implementatiemodel?
Deze configuratie wordt niet ondersteund. U kunt de virtuele hardeschijfbestanden echter kopiëren vanuit een opslagaccount dat u hebt gemaakt met het klassieke implementatiemodel en deze toevoegen aan een nieuw account dat is gemaakt via Resource Manager.
Wat zijn de gevolgen voor het quotum voor mijn abonnement?
De quota voor de virtuele machines, virtuele netwerken en opslagaccounts die zijn gemaakt met behulp van Azure Resource Manager zijn gescheiden van andere quota. Elk abonnement krijgt quota voor het maken van de resources met behulp van de nieuwe API's. Zie Servicelimieten voor Azure-abonnementen voor meer informatie over quota.
Kan ik mijn geautomatiseerde scripts voor het inrichten van virtuele machines, virtuele netwerken en opslagaccounts via de API's van Azure Resource Manager blijven gebruiken?
Alle automatisering en scripts die u hebt gemaakt, blijven werken voor de bestaande virtuele machines en virtuele netwerken die zijn gemaakt in de Azure Service Management-modus. U moet de scripts echter bijwerken om het nieuwe schema te gebruiken voor het maken van dezelfde resources via de Resource Manager-modus.
Waar vind ik voorbeelden van Azure Resource Manager-sjablonen?
Er is een uitgebreide set starterssjablonen beschikbaar in Azure Resource Manager-quickstartsjablonen.
Volgende stappen
- Resources implementeren met Resource Manager-sjablonen en Azure PowerShell voor informatie over de opdrachten voor het implementeren van een sjabloon.