Azure voor Google Cloud Professionals

Dit artikel helpt Google Cloud-experts inzicht te hebben in de basisbeginselen van Microsoft Azure-accounts, -platformen en -services. Het behandelt ook belangrijke overeenkomsten en verschillen tussen de Google Cloud- en Azure-platforms. (Houd er rekening mee dat Google Cloud eerder Google Cloud Platform (GCP) werd genoemd.)

U leert het volgende:

• Hoe accounts en resources in Azure zijn geordend.
• Hoe de beschikbare oplossingen in Azure zijn gestructureerd.
• Hoe de belangrijkste Azure-services verschillen van Google Cloud-services.

Azure en Google Cloud hebben hun mogelijkheden onafhankelijk van elkaar gebouwd, zodat elk ervan belangrijke verschillen in implementatie en ontwerp heeft.

Overzicht van Azure voor Google Cloud

Net als Google Cloud is Microsoft Azure gebouwd rond een kernset reken-, opslag-, database- en netwerkservices. Ook ten aanzien van de producten en services die ze bieden, zijn beide platforms in grote lijnen vergelijkbaar. Met Zowel Google Cloud als Azure kunt u maximaal beschikbare oplossingen bouwen op basis van Linux- of Windows-hosts. Als u gewend bent aan ontwikkelen met behulp van Linux- en OSS-technologie, zijn beide platforms geschikt.

Hoewel beide platforms vergelijkbare functionaliteit hebben, zijn de resources die deze functionaliteit bieden, vaak anders ingedeeld. De exacte een-op-een-relaties tussen de services die nodig zijn voor het bouwen van een oplossing, zijn niet altijd duidelijk. In andere gevallen wordt een bepaalde service op het ene platform wel aangeboden, maar op het andere niet.

Accounts en abonnementen beheren

Azure heeft een hiërarchie van beheergroepen, abonnementen en resourcegroepen om resources effectief te beheren. Dit is vergelijkbaar met de mappen- en projecthiërarchie voor resources in Google Cloud.

Niveaus van beheer in Azure

• Beheergroepen: Deze groepen zijn containers waarmee u toegang, beleid en naleving voor meerdere abonnementen kunt beheren. Alle abonnementen in een beheergroep nemen automatisch de voorwaarden over die op de beheergroep zijn toegepast.
• Abonnementen: Een abonnement koppelt gebruikersaccounts en de resources die zijn gemaakt door die gebruikersaccounts logisch. Voor elk abonnement zijn er beperkingen of quota voor de hoeveelheid resources die u kunt maken en gebruiken. Organisaties kunnen abonnementen gebruiken voor het beheren van kosten en de resources die zijn gemaakt door gebruikers, teams of projecten.
• Resourcegroepen: Een resourcegroep is een logische container waarin Azure-resources zoals web-apps, databases en opslagaccounts worden geïmplementeerd en beheerd.
• Resources: Resources zijn exemplaren van services die u maakt, zoals virtuele machines, opslag of SQL-databases.

Azure-services kunnen binnen verschillende prijscategorieën worden aangeschaft, afhankelijk van de grootte en behoeften van uw organisatie. Raadpleeg de pagina met het prijsoverzicht voor meer informatie.

Azure-abonnementen bundelen een aantal resources met een toegewezen eigenaar die verantwoordelijk is voor de facturering en het machtigingsbeheer.

Een Google Cloud-project is conceptueel vergelijkbaar met het Azure-abonnement, wat betreft facturering, quota en limieten. Vanuit functioneel oogpunt lijkt een Google Cloud-project echter meer op een resourcegroep in Azure. Het is een logische eenheid waarnaar cloudresources worden geïmplementeerd.

Houd er rekening mee dat er in tegenstelling tot google cloud geen maximum aantal Azure-abonnementen is. Elk Azure-abonnement is gekoppeld aan één Microsoft Entra-tenant (een account in Google Cloud-voorwaarden). Een Microsoft Entra-tenant kan een onbeperkt aantal abonnementen bevatten, terwijl Google Cloud een standaardlimiet van 30 projecten per account heeft.

Aan abonnementen worden drie soorten beheerdersaccounts toegewezen:

• Accountbeheerder. De eigenaar van het abonnement en het account waarbij de resources die in het abonnement worden gebruikt, in rekening worden gebracht. De accountbeheerder kan alleen worden gewijzigd door het eigendom van het abonnement over te dragen.
• Servicebeheerder. Dit type account heeft rechten om in het abonnement resources te maken en te beheren, maar is niet verantwoordelijk voor de facturering. De rollen 'accountbeheerder' en 'servicebeheerder' worden standaard aan hetzelfde account toegewezen. De accountbeheerder kan een andere gebruiker toewijzen aan het servicebeheerdersaccount voor het beheren van de technische en operationele aspecten van een abonnement. Er is slechts een servicebeheerder toegewezen per abonnement.
• Medebeheerder. Aan een abonnement kunnen meerdere medebeheerdersaccounts zijn toegewezen. Medebeheerders kunnen de servicebeheerder niet wijzigen, maar hebben verder volledige beheersmogelijkheden over de resources en gebruikers van het abonnement.

Voor gedetailleerd toegangsbeheer voor Azure-resources kunt u op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) gebruiken, dat meer dan 70 ingebouwde rollen bevat. U kunt ook uw eigen aangepaste rollen maken.

Onder het abonnementsniveau kunnen ook gebruikersrollen en individuele machtigingen aan afzonderlijke resources worden toegewezen. In Azure zijn alle gebruikersaccounts gekoppeld aan een Microsoft-account of organisatieaccount (een account dat wordt beheerd via Microsoft Entra-id).

Abonnementen hebben standaard servicequota en limieten. Raadpleeg Azure subscription and service limits, quotas, and constraints (Limieten van Azure-abonnementen en -services, quota en beperkingen) voor een volledige lijst van deze limieten. Genoemde limieten kunnen tot het maximum worden verhoogd door in de beheerportal een ondersteuningsverzoek in te dienen.

Zie ook

• Azure-beheerdersrollen toevoegen of wijzigen
• Uw Azure-factuur en de dagelijkse gebruiksgegevens downloaden

Resourcebeheer

Het begrip 'resource' in Azure verwijst naar een rekenproces, opslagobject, netwerkapparaat of andere entiteit dat/die binnen het platform kan worden gemaakt of geconfigureerd.

Azure-resources worden via een van twee modellen geïmplementeerd en beheerd: Azure Resource Manager of het oudere klassieke Azure-implementatiemodel. Nieuwe resources worden altijd met het Resource Manager-model gemaakt.

Resourcegroepen

Azure beschikt ook nog over een entiteit genaamd 'resourcegroepen', waarin resources zoals virtuele machines, opslag en virtuele netwerkapparaten worden georganiseerd. Een Azure-resource is altijd gekoppeld aan één resourcegroep. Een resource die in één resourcegroep is gemaakt, kan wel naar een andere groep worden verplaatst, maar kan zich nooit in twee resourcegroepen tegelijk bevinden. Zie Azure-resources verplaatsen tussen resourcegroepen, abonnementen of regio's voor meer informatie. Resourcegroepen vormen de fundamentele wijze van groepering die in Azure Resource Manager wordt gebruikt.

Resources kunnen ook met behulp van tags worden ingedeeld. Tags zijn sleutel-waardeparen waarmee u resources kunt groeperen in uw abonnement, ongeacht het lidmaatschap van de resourcegroep.

Beheerinterfaces

Azure biedt verschillende manieren om uw resources te beheren:

• Webinterface. Azure Portal biedt een volledige webgebaseerde beheerinterface voor Azure-resources.
• REST API. De REST API van Azure Resource Manager biedt programmatisch toegang tot de meeste van de beschikbare functies in Azure Portal.
• Opdrachtregel. De Azure CLI biedt een opdrachtregelinterface waarmee Azure-resources kunnen worden gemaakt en beheerd. De Azure CLI is beschikbaar voor Windows, Linux en macOS.
• PowerShell. Met de Azure-modules voor PowerShell kunt u geautomatiseerde beheertaken met een script uitvoeren. PowerShell is beschikbaar voor Windows, Linux en macOS.
• Sjablonen. Azure Resource Manager-sjablonen bieden resourcebeheermogelijkheden die zijn gebaseerd op JSON-sjablonen.
• SDK. De SDK's zijn een verzameling bibliotheken waarmee gebruikers programmatisch kunnen beheren en communiceren met Azure-services.

In elk van deze interfaces is de resourcegroep de basis voor hoe Azure-resources worden gemaakt, geïmplementeerd of gewijzigd.

Bovendien zijn veel beheerhulpprogramma's van derden, zoals Terraform van Hashicorp en Netflix Spinnaker, ook beschikbaar in Azure.

Zie ook

• Richtlijnen voor Azure-resourcegroepen

Regio’s en beschikbaarheidszones

De impact van een storing kan van geval tot geval variëren. Sommige hardwarestoringen, zoals een defecte schijf, treffen mogelijk slechts één enkele hostcomputer. Maar een storing in een netwerkswitch kan gevolgen hebben voor een heel serverrek. Zeldzamer zijn storingen die een heel datacenter platleggen, zoals wanneer zich een stroomstoring in een datacenter voordoet. In zeldzame gevallen kan een hele regio niet meer beschikbaar zijn.

Een van de belangrijkste manieren om ervoor te zorgen dat een toepassing tolerant is, is via redundantie. U moet deze redundantie echter plannen wanneer u de toepassing ontwerpt. Bovendien is het redundantieniveau dat u nodig hebt, afhankelijk van uw zakelijke behoeften. Niet elke toepassing heeft redundantie voor meerdere regio's nodig ter bescherming tegen regionale uitval. In het algemeen is het zo dat naarmate de redundantie en de betrouwbaarheid groter zijn, de kosten en de complexiteit toenemen.

In Google Cloud heeft een regio twee of meer Beschikbaarheidszones. Een beschikbaarheidszone komt overeen met een fysiek geïsoleerd datacenter in de betreffende geografische regio. Azure heeft op elk niveau van een mogelijke fout een groot aantal functies voor toepassingsreduntatie, waaronder beschikbaarheidssets, beschikbaarheidszones en gekoppelde regio's.

De volgende tabel geeft een overzicht van elke optie.

	Beschikbaarheidsset	Beschikbaarheidszone	Gekoppelde regio
Bereik van fout	rack	Datacenter	Regio
Aanvraagroutering	Load Balancer	Zoneoverschrijdende Load Balancer	Traffic Manager
Netwerklatentie	Zeer laag	Beperkt	Middelhoog tot hoog
Virtuele netwerken	VNet	VNet	Regio-overschrijdende VNet-peering

Beschikbaarheidssets

Ter bescherming tegen lokaal optredende hardwarestoringen, zoals een schijf- of netwerkswitchstoring, raden we u aan twee of meer virtuele machines in een beschikbaarheidsset te implementeren. Een beschikbaarheidsset bestaat uit twee of meer foutdomeinen die een gemeenschappelijke voedingsbron en netwerkswitch delen. VM's in een beschikbaarheidsset bevinden zich verspreid over de foutdomeinen, wat betekent dat als een hardwarestoring het ene foutdomein treft, het netwerkverkeer nog steeds kan worden omgeleid naar de VM's in de andere foutdomeinen. Zie Manage the availability of Windows virtual machines in Azure (De beschikbaarheid van virtuele Windows-machines in Azure beheren) voor meer informatie over beschikbaarheidssets.

Wanneer de VM-exemplaren aan beschikbaarheidssets worden toegevoegd, worden ze ook aan een updatedomein toegewezen. Een updatedomein is een groep virtuele machines die zijn ingesteld voor gelijktijdige onderhoudsgebeurtenissen. Het distribueren van virtuele machines over meerdere updatedomeinen zorgt ervoor dat geplande update- en patchgebeurtenissen altijd alleen invloed hebben op een subset van virtuele machines.

Beschikbaarheidssets moeten worden ingedeeld op basis van de rol van de instantie in uw toepassing om ervoor te zorgen dat er in elke rol altijd één instantie operationeel is. Maak in een webtoepassing met drie lagen bijvoorbeeld afzonderlijke beschikbaarheidssets voor de frontend-, toepassings- en gegevenslagen.

Beschikbaarheidssets

Beschikbaarheidszones

Net als Google Cloud kunnen Azure-regio's beschikbaarheidszones hebben. Een beschikbaarheidszone is een fysiek afgescheiden zone binnen een Azure-regio. Elke beschikbaarheidszone heeft een afzonderlijke voedingsbron en koeling, en een afzonderlijk netwerk. Door machines in verschillende beschikbaarheidszones te implementeren, is het gemakkelijker om een toepassing te beveiligen tegen storingen die een heel datacenter treffen.

Zoneredundante VM-implementatie in Azure

Zie Aanbevelingen voor meer informatie over het gebruik van beschikbaarheidszones en regio's.

Gekoppelde regio's

U kunt een toepassing beschermen tegen regionale uitval door de toepassing in meerdere regio's te implementeren met behulp van Azure Traffic Manager, zodat internetverkeer over de verschillende regio's wordt gedistribueerd. Elke Azure-regio is gekoppeld aan een andere regio. Samen vormen deze een regionaal paar. Met uitzondering van Brazilië - zuid bevinden de regionale paren zich binnen hetzelfde geografische gebied. Zo kan worden voldaan aan de vereisten op het gebied van belastingwetgeving en wetshandhaving die in de desbetreffende jurisdicties worden gesteld.

In tegenstelling tot beschikbaarheidszones (fysiek gescheiden datacenters die zich echter in relatief dicht bij elkaar gelegen geografische gebieden kunnen bevinden) bevinden gekoppelde regio's zich doorgaans op ten minste 480 kilometer van elkaar. Dit ontwerp zorgt ervoor dat noodgevallen op grote schaal alleen van invloed zijn op één van de regio's in het paar. Aangrenzende paren kunnen worden ingesteld om database- en opslagservicegegevens te synchroniseren, en worden zo geconfigureerd dat platformupdates in slechts één regio tegelijk worden geïmplementeerd.

Er wordt automatisch een back-up gemaakt van de geografisch redundante opslag naar de juiste gekoppelde regio. Voor alle overige resources betekent het maken van een volledig redundante oplossing met behulp van gekoppelde regio's dat er in beide regio's een integrale kopie van uw oplossing wordt gemaakt.

Regioparen in Azure

Zie ook

• Regio's voor virtuele machines in Azure
• Beschikbaarheidsopties voor virtuele machines in Azure
• Hoge beschikbaarheid voor Azure-toepassingen
• Herstel na fouten en noodgevallen voor Azure-toepassingen
• Gepland onderhoud voor virtuele Linux-machines in Azure

Services

Zie Google Cloud naar Azure-services vergelijken voor een overzicht van hoe services worden toegewezen tussen platforms.

Niet alle Azure-producten en -services zijn in alle regio's beschikbaar. Raadpleeg de pagina Producten per regio voor meer informatie. Op de pagina Service Level Agreements vindt u de gegarandeerde bedrijfstijd en ons vergoedingsbeleid in geval van downtime voor alle Azure-producten en -services.

Volgende stappen

• Aan de slag met Azure
• Azure-referentiearchitecturen