Azure för Google Cloud-proffs

Den här artikeln hjälper Google Cloud-experter att förstå grunderna i Microsoft Azure konton, tjänster och resurser. Den omfattar även viktiga likheter och skillnader mellan Google Cloud- och Azure-plattformarna.

Anmärkning

Google Cloud kallades tidigare Google Cloud Platform (GCP).

I den här artikeln lär du dig:

• Hur konton och resurser organiseras i Azure.
• Hur tillgängliga lösningar är strukturerade i Azure.
• Hur de stora Azure-tjänsterna skiljer sig från Google Cloud-tjänster.

Azure och Google Cloud har skapat sina funktioner oberoende över tid, så de har betydande implementerings- och designskillnader.

Likheter mellan Azure och Google Cloud

Precis som Google Cloud bygger Microsoft Azure på en grundläggande uppsättning beräknings-, lagrings-, databas- och nätverkstjänster. I många fall erbjuder båda plattformarna jämförbara funktioner och har stöd för lösningar med hög tillgänglighet på Linux- eller Windows-värdar. Om du är van vid utveckling med Linux och programvara med öppen källkod kan båda plattformarna utföra jobbet.

Även om plattformarna har liknande funktioner ordnas ofta de resurser som tillhandahåller dessa funktioner på olika sätt. Direkt service-till-tjänst-mappningar är inte alltid tydliga och vissa tjänster är bara tillgängliga på en plattform.

Hantera konton och prenumerationer

Azure tillhandahåller en hierarki med hanteringsgrupper, prenumerationer och resursgrupper som hjälper dig att hantera resurser effektivt. Den här hierarkin liknar mapparna och projektstrukturen för resurser i Google Cloud. Följande diagram visar hierarkin för hanteringsomfånget i Azure:

Träddiagrammet visar Azure hanteringshierarki på fyra nivåer. Högst upp ligger en enda hanteringsgrupp med namnet Corporate IT. Direkt under företags-IT förgrenar sig tre underliggande hanteringsgrupper horisontellt från vänster till höger: produktion, utveckling och QA. Förbindelselinjer anger att policyer och åtkomstkontroller som definierats på företagets centrala IT-nivå ärvs av alla tre. Under produktionshanteringsgruppen ordnas tre prenumerationer från vänster till höger: verksamhetskritiska, skyddade data och annan produktion. Under gruppen för utvecklingshantering finns en enda prenumeration med etiketten icke-produktion. Under QA-hanteringsgruppen finns en enda prenumeration med namnet staging. På den nedre nivån innehåller resursgrupper programresurser.

• Hanteringsgrupper: Dessa grupper är containrar som hjälper dig att hantera åtkomst, principer och efterlevnad för flera prenumerationer. Alla prenumerationer i en hanteringsgrupp ärver automatiskt de villkor som tillämpas för hanteringsgruppen.

• Prenumerationer: En prenumeration associerar logiskt användarkonton och de resurser som dessa användarkonton skapar. Varje prenumeration har gränser eller kvoter för hur många resurser du kan skapa och använda. Organisationer kan använda prenumerationer för att hantera kostnader och de resurser som användare, team eller projekt skapar.

  Du kan skapa ett obegränsat antal Azure prenumerationer. Varje prenumeration länkar till en enda Microsoft Entra klientorganisation (ett konto i Google Cloud-termer). En klientorganisation kan innehålla ett obegränsat antal prenumerationer, medan Google Cloud har en mjuk standardgräns som varierar per konto och kan ökas genom en begäran.

  Ett Google Cloud-projekt liknar konceptuellt Azure-prenumerationen när det gäller fakturering, kvoter och gränser. I funktion liknar dock ett Google Cloud-projekt mer en Azure resursgrupp – en logisk container som molnresurser distribueras till.

• Resursgrupper: En resursgrupp är en logisk container där du distribuerar och hanterar Azure resurser som webbappar, databaser och lagringskonton.

• Resurser: Resurser är instanser av tjänster som du skapar, till exempel virtuella datorer , lagring eller SQL-databaser.

Azure erbjuder flera köpalternativ som passar organisationer av olika storlekar och behov. Mer information finns i prisöversikten.

Du hanterar åtkomst till Azure resurser via Azure rollbaserad åtkomstkontroll (Azure RBAC), som innehåller mer än 100 inbyggda roller. Du kan även skapa egna anpassade roller.

Varje prenumeration har också en kontoadministratör som representerar prenumerationsägaren och kontot som debiteras för de resurser som används i prenumerationen. Du kan bara ändra kontoadministratören genom att överföra ägarskapet för prenumerationen.

Under prenumerationsnivån kan du tilldela användarroller och enskilda behörigheter till specifika resurser. I Azure är alla användarkonton associerade med antingen ett Microsoft-konto eller organisationskonto (ett konto som hanteras via Microsoft Entra-ID).

Prenumerationer har standardkvoter och begränsningar för tjänster. En lista med de här gränserna finns i Azure-prenumerationer och gränser, kvoter och begränsningar för tjänster. Du kan öka vissa av dessa gränser genom att skicka in en supportbegäran i hanteringsportalen.

Mer information om hur du hanterar konton och prenumerationer finns i följande resurser:

• Lägg till eller ändra Azure-prenumerationsadministratörer
• Ladda ned eller visa din Azure-faktura

Resurshantering

I Azure är en resurs alla beräkningsinstanser, lagringsobjekt, nätverksenheter eller andra entiteter som du kan skapa eller konfigurera på plattformen.

Du kan distribuera och hantera Azure resurser med hjälp av Azure Resource Manager.

Resursgrupper

Azure tillhandahåller även resursgrupper som organiserar resurser som virtuella datorer, lagringsenheter och virtuella nätverksenheter. Du associerar alltid en Azure resurs med en resursgrupp. Du kan flytta en resurs från en resursgrupp till en annan, men den kan bara finnas i en resursgrupp i taget. Mer information finns i Flytta Azure-resurser till en ny resursgrupp eller prenumeration. Azure Resource Manager använder resursgrupper som grundläggande gruppering.

Du kan också ordna resurser med hjälp av taggar. Taggar är nyckel/värde-par som du kan använda för att gruppera resurser i prenumerationen oavsett resursgruppsmedlemskap.

Hanteringsgränssnitt

Det finns flera sätt att hantera dina resurser i Azure:

• Azure portal: I Azure-portalen finns ett fullständigt webbaserat hanteringsgränssnitt för Azure resurser.
• REST API: rest-API:et Azure Resource Manager ger programmatisk åtkomst till de flesta funktioner som är tillgängliga i Azure-portalen.
• Kommandorad: I Azure CLI finns ett kommandoradsgränssnitt som kan skapa och hantera Azure resurser. Azure CLI är tillgängligt för Windows, Linux och macOS.
• PowerShell: Du kan använda Azure moduler för PowerShell för att köra automatiserade hanteringsuppgifter med hjälp av ett skript. PowerShell är tillgängligt för Windows, Linux och macOS.
• Mallar: Azure Resource Manager mallar tillhandahåller mallbaserade resurshanteringsfunktioner. Dessa mallar skrivs vanligtvis i Bicep eller Terraform.
• Azure-SDK:er: SDK:erna är en samling bibliotek som du kan använda för att programmatiskt hantera och interagera med Azure tjänster.

I alla dessa gränssnitt är resursgruppen central för att skapa, distribuera och hantera Azure resurser.

Dessutom finns många icke-Microsoft hanteringsverktyg, som HashiCorps Terraform och Spinnaker, tillgängliga på Azure.

Regioner och tillgänglighetszoner

Molnfel varierar kraftigt i omfattning och allvarlighetsgrad. Lokaliserade maskinvarufel eller konfigurationsproblem kan påverka enskilda resurser eller grupper av resurser i en arbetsbelastning. Det är mindre vanligt med fel som stör ett helt datacenter, till exempel strömavbrott i ett datacenter. I sällsynta fall kan en hel region bli otillgänglig.

En av huvudmetoderna för att göra ett program flexibelt är via redundans. Du måste dock planera för den här redundansen när du utformar programmet. Redundansnivån du behöver beror på dina affärskrav. Alla program behöver inte redundans i flera regioner för att skydda mot ett regionalt strömavbrott. Det kan ofta vara nödvändigt att kompromissa mellan större redundans och tillförlitlighet jämfört med högre kostnad och komplexitet.

I Google Cloud har en region två eller flera tillgänglighetszoner. En tillgänglighetszon motsvarar ett fysiskt isolerat datacenter i den geografiska regionen. Azure har många funktioner för att tillhandahålla programredundans på alla nivåer av potentiella fel, inklusive tillgänglighetszoner och parerade regioner.

I följande tabell sammanfattas varje alternativ.

	Tillgänglighetszon	Länkad region
Omfång för fel	Datacenter	Region
Routning av förfrågningar	zonöverskridande Azure Load Balancer	Azure Traffic Manager
Nätverksfördröjning	Låg	Mellan till hög
Virtuella nätverk	Virtuellt nätverk	Peering mellan virtuella nätverk i olika regioner

Tillgänglighetszoner

Precis som Google Cloud kan Azure regioner ha tillgänglighetszoner som är fysiskt separata zoner i en Azure region. Varje tillgänglighetszon har en distinkt energikälla, ett nätverk och en kylning. Att distribuera virtuella datorer mellan tillgänglighetszoner hjälper till att skydda ett program mot datacenteromfattande fel.

Diagram som visar en zonredundant distribution av virtuella datorer i en enda Azure region. En stor yttre rektangel märkt region innehåller hela layouten. I regionen staplas tre vågräta rektangulära zoner lodrätt uppifrån och ned, märkt zon 1, zon 2 och zon 3. Varje zon innehåller en virtuell dator. En lodrät streckad rektangel överlagrar de virtuella datorerna i alla tre zonerna. Den här streckade rektangeln representerar ett enda undernät som sträcker sig över alla tre tillgänglighetszonerna samtidigt. Etikettundernätet visas längst ned i den streckade rektangeln. Layouten visar att distribution av virtuella datorer i varje zon, anslutna via ett delat undernät, ger redundans vid ett fel i en zon.

Mer information om tillgänglighetszoner och regioner finns i Arkitekturstrategier för användning av tillgänglighetszoner och regioner.

Länkade regioner

För att skydda ett program mot ett regionalt avbrott distribuerar du programmet i flera regioner och använder Azure Traffic Manager för att distribuera Internettrafik till olika regioner. Varje Azure region parkopplas med en annan region. Tillsammans bildar dessa regioner ett regionpar. Med undantag för Södra Brasilien finns regionpar inom samma geografi för att uppfylla krav på datalagring för beskattnings- och brottsbekämpningsjurisdiktion.

Till skillnad från tillgänglighetszoner, som är fysiskt separata datacenter men kan finnas i relativt närliggande geografiska områden, avgränsas vanligtvis kopplade regioner med minst 500 miles. Den här utformningen ser till att även större katastrofer endast påverkar en av regionerna i paret. Du kan ställa in närliggande par för att synkronisera databas- och lagringstjänstdata. De är konfigurerade så att plattformsuppdateringar distribueras till endast en region i paret i taget.

Azure geo-redundant lagring säkerhetskopieras automatiskt till rätt parat område. För alla andra resurser måste du distribuera en fullständig kopia av din lösning i varje region för att uppnå fullständig redundans.

Diagram som visar den kapslade inneslutningshierarkin för Azure regionpar. Den yttersta rektangeln representerar ett geografiskt område. Inuti geografin finns ett regionpar. I regionparet sitter två regioner sida vid sida. Inom varje region finns ett datacenter. Kapslingen av formerna illustrerar inneslutningsrelationerna: datacenter finns fysiskt i regioner, två regioner bildar tillsammans ett regionpar och ett regionpar tillhör ett enda geografiskt område.

Tillförlitlighetsguider per tjänst

Information om tillförlitlighetsrekommendationer för varje Azure tjänst finns i Tillförlitlighetsguider per tjänst.

Mer information finns i följande resurser:

• Hög tillgänglighet för Azure-program
• Arkitekturstrategier för katastrofåterställning

Tjänster

Information om hur Google Cloud-tjänster mappas till deras Azure motsvarigheter finns i Jämförelse mellan Google Cloud och Azure tjänster.

Alla Azure-produkter och -tjänster är inte tillgängliga i alla regioner. Mer information finns i Produkter efter region. Du hittar drifttidsgarantier och kreditprinciper för stilleståndstid för varje Azure produkt eller tjänst i dokumentet serviceavtal för online služby.

Nästa steg

Kom igång med Azure

Relaterat innehåll

• Azure referensarkitekturer