Azure voor Google Cloud Professionals

Dit artikel helpt Google Cloud-experts de basisbeginselen van Microsoft Azure accounts, platform en services te begrijpen. Ook worden de belangrijkste overeenkomsten en verschillen tussen de Google Cloud- en Azure-platformen bestrijkt. (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 in de tijd gebouwd, zodat elk ervan belangrijke implementatie- en ontwerpverschillen heeft.

Overzicht van Azure voor Google Cloud

Net als Google Cloud is Microsoft Azure gebaseerd op een kernset van compute-, 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 oplossingen met hoge beschikbaar maken 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: Dit zijn containers die u helpen om de toegang, het beleid en de naleving voor meerdere abonnementen te beheren. Alle abonnementen in een beheergroep nemen automatisch de voorwaarden over die op de beheergroep zijn toegepast.
• Abonnementen: In een abonnement zijn gebruikersaccounts en de resources die met deze gebruikersaccounts zijn gemaakt, logisch gekoppeld. 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.
• Bronnen: 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 GCP-project is conceptueel vergelijkbaar met het Azure-abonnement, wat betreft facturering, quota en limieten. Vanuit functioneel oogpunt lijkt een GCP-project echter meer op een resourcegroep in Azure. Het is een logische eenheid waar cloudbronnen in worden geïmplementeerd.

Houd er rekening mee dat er, in tegenstelling tot in GCP, geen maximum aantal Azure-abonnementen is. Elk Azure-abonnement is gekoppeld aan één azure ad Azure Active Directory-tenant (een account, in GCP-termen). Een Azure AD-tenant kan een onbeperkt aantal abonnementen bevatten, terwijl GCP een standaardlimiet heeft van 30 projecten per account.

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 een fijnerf toegangsbeheer tot Azure-resources kunt u op rollen gebaseerd toegangsbeheer vanAzure (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 Azure AD).

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 op basis van een van de volgende 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 Azure-services programmatisch kunnen beheren en gebruiken.

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 situaties 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.

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 Oplossingen bouwen voor hoge beschikbaarheid met behulp van Beschikbaarheidszones voor meer Beschikbaarheidszones.

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 Vergelijking van Google Cloud-naar-Azure-services voor een overzicht van de manier waarop services tussen platforms worden weergegeven.

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-oplossingsarchitecturen
• Azure-referentiearchitecturen