Planeringsöverväganden för datacenterintegrering för Azure Stack Hub-integrerade system

Om du är intresserad av ett integrerat Azure Stack Hub-system bör du förstå de viktigaste planeringsövervägandena kring distribution och hur systemet passar in i ditt datacenter. Den här artikeln innehåller en översikt över dessa överväganden på hög nivå som hjälper dig att fatta viktiga infrastrukturbeslut för dina integrerade Azure Stack Hub-system. Att förstå dessa överväganden hjälper dig när du arbetar med OEM-maskinvaruleverantören när de distribuerar Azure Stack Hub till ditt datacenter.

Anteckning

Azure Stack Hub-integrerade system kan bara köpas från auktoriserade maskinvaruleverantörer.

Om du vill distribuera Azure Stack Hub måste du tillhandahålla planeringsinformation till din lösningsleverantör innan distributionen börjar hjälpa processen att gå snabbt och smidigt. Den information som krävs sträcker sig över nätverks-, säkerhets- och identitetsinformation med många viktiga beslut som kan kräva kunskap från många olika områden och beslutsfattare. Du behöver personer från flera team i din organisation för att se till att du har all nödvändig information redo före distributionen. Det kan hjälpa dig att prata med maskinvaruleverantören när du samlar in den här informationen eftersom de kan ha användbara råd.

När du undersöker och samlar in nödvändig information kan du behöva göra vissa konfigurationsändringar före distributionen i nätverksmiljön. Dessa ändringar kan omfatta att reservera IP-adressutrymmen för Azure Stack Hub-lösningen samt konfigurera dina routrar, växlar och brandväggar för att förbereda anslutningen till de nya Azure Stack Hub-lösningsväxlarna. Se till att ämnesområdet expert uppradade för att hjälpa dig med din planering.

Överväganden vid kapacitetsplanering

När du utvärderar en Azure Stack Hub-lösning för förvärv gör du maskinvarukonfigurationsalternativ som har en direkt inverkan på den övergripande kapaciteten för Azure Stack Hub-lösningen. Dessa omfattar de klassiska alternativen cpu, minnesdensitet, lagringskonfiguration och övergripande lösningsskala (till exempel antal servrar). Till skillnad från en traditionell virtualiseringslösning gäller inte den enkla aritmetiken för dessa komponenter för att fastställa användbar kapacitet. Den första orsaken är att Azure Stack Hub är konstruerat för att vara värd för infrastrukturen eller hanteringskomponenterna i själva lösningen. Den andra orsaken är att en del av lösningens kapacitet är reserverad för återhämtning genom att uppdatera lösningens programvara på ett sätt som minimerar störningar i klientarbetsbelastningar.

Kalkylbladet för Kapacitetsplaneraren i Azure Stack Hub hjälper dig att fatta välgrundade beslut om kapacitetsplanering på två sätt. Det första är att välja ett maskinvaruerbjudande och försöka passa en kombination av resurser. Det andra är att definiera den arbetsbelastning som Azure Stack Hub är avsett att köra för att visa tillgängliga maskinvaru-SKU:er som stöder den. Slutligen är kalkylbladet avsett som en guide som hjälper dig att fatta beslut som rör planering och konfiguration av Azure Stack Hub.

Kalkylbladet är inte avsett att ersätta din egen undersökning och analys. Microsoft lämnar inga utfästen eller garantier, uttryckliga eller underförstådda, med avseende på den information som tillhandahålls i kalkylbladet.

Överväganden kring hantering

Azure Stack Hub är ett förseglat system där infrastrukturen är låst både ur ett behörighets- och nätverksperspektiv. Åtkomstkontrollistor för nätverk (ACL: er) tillämpas för att blockera all obehörig inkommande trafik och all onödig kommunikation mellan infrastrukturkomponenter. Det här systemet gör det svårt för obehöriga användare att komma åt systemet.

För daglig hantering och drift finns det ingen obegränsad administratörsåtkomst till infrastrukturen. Azure Stack Hub-operatörer måste hantera systemet via administratörsportalen eller via Azure Resource Manager (via PowerShell eller REST API). Andra hanteringsverktyg som Hyper-V Manager eller Klusterhanteraren för växling vid fel har inte åtkomst till systemet. För att skydda systemet kan inte programvara från tredje part (till exempel agenter) installeras i komponenterna i Azure Stack Hub-infrastrukturen. Samverkan med extern hantering och säkerhetsprogramvara sker via PowerShell eller REST-API:et.

Kontakta Microsoft Support när du behöver en högre åtkomstnivå för felsökning av problem som inte löses med hjälp av aviseringsmedlingssteg. Via support finns det en metod för att ge tillfällig fullständig administratörsåtkomst till systemet för mer avancerade åtgärder.

Identitetsöverväganden

Välj identitetsprovider

Du måste överväga vilken identitetsprovider du vill använda för Azure Stack Hub-distribution, antingen Microsoft Entra-ID eller AD FS. Du kan inte växla identitetsprovidrar efter distributionen utan fullständig omdistribution av systemet. Om du inte äger Microsoft Entra-kontot och använder ett konto som tillhandahålls av din molnlösningsleverantör, och om du bestämmer dig för att byta leverantör och använda ett annat Microsoft Entra konto, måste du kontakta din lösningsleverantör för att distribuera om lösningen åt dig till din kostnad.

Valet av identitetsprovider har ingen betydelse för virtuella klientdatorer (VM), identitetssystemet, kontona de använder eller om de kan ansluta till en Active Directory-domän och så vidare. Dessa saker är separata.

Du kan distribuera flera Azure Stack Hub-system med samma Microsoft Entra klientorganisation eller Active Directory.

AD FS- och Graph-integrering

Om du väljer att distribuera Azure Stack Hub med hjälp av AD FS som identitetsprovider måste du integrera AD FS-instansen på Azure Stack Hub med en befintlig AD FS-instans via ett federationsförtroende. Med den här integreringen kan identiteter i en befintlig Active Directory-skog autentiseras med resurser i Azure Stack Hub.

Du kan också integrera Graph-tjänsten i Azure Stack Hub med den befintliga Active Directory. Med den här integreringen kan du hantera Role-Based Access Control (RBAC) i Azure Stack Hub. När åtkomst till en resurs delegeras letar Graph-komponenten upp användarkontot i den befintliga Active Directory-skogen med hjälp av LDAP-protokollet.

Följande diagram visar integrerat AD FS- och Graph-trafikflöde.

Licensieringsmodell

Du måste bestämma vilken licensieringsmodell du vill använda. Vilka alternativ som är tillgängliga beror på om du distribuerar Azure Stack Hub som är ansluten till Internet:

• För en ansluten distribution kan du välja antingen betala per användning eller kapacitetsbaserad licensiering. Betala per användning kräver en anslutning till Azure för att rapportera användning, som sedan faktureras via Azure Commerce.
• Endast kapacitetsbaserad licensiering stöds om du distribuerar frånkopplad från Internet.

Mer information om licensieringsmodellerna finns i Paketering och prissättning för Microsoft Azure Stack Hub.

Namngivningsbeslut

Du måste tänka på hur du vill planera ditt Azure Stack Hub-namnområde, särskilt regionnamnet och det externa domännamnet. Det externa fullständigt kvalificerade domännamnet (FQDN) för din Azure Stack Hub-distribution för offentliga slutpunkter är kombinationen av dessa två namn: <region>.<fqdn>. Till exempel east.cloud.fabrikam.com. I det här exemplet skulle Azure Stack Hub-portalerna vara tillgängliga på följande URL:er:

• https://portal.east.cloud.fabrikam.com
• https://adminportal.east.cloud.fabrikam.com

Viktigt

Regionnamnet som du väljer för din Azure Stack Hub-distribution måste vara unikt och visas i portaladresserna.

I följande tabell sammanfattas dessa beslut om namngivning av domäner.

Name	Beskrivning
Regionsnamn	Namnet på din första Azure Stack Hub-region. Det här namnet används som en del av det fullständiga domännamnet för de offentliga virtuella IP-adresser (VIP) som Hanteras av Azure Stack Hub. Regionnamnet är vanligtvis en fysisk platsidentifierare, till exempel en datacenterplats. Regionnamnet får endast bestå av bokstäver och siffror mellan 0 och 9. Inga specialtecken (till exempel -, #och så vidare) tillåts.
Externt domännamn	Namnet på DNS-zonen (Domain Name System) för slutpunkter med externa VIP-adresser. Används i FQDN för dessa offentliga VIP-adresser.
Privat (internt) domännamn	Namnet på domänen (och den interna DNS-zonen) som skapats på Azure Stack Hub för infrastrukturhantering.

Certifikatkrav

För distribution måste du tillhandahålla SSL-certifikat (Secure Sockets Layer) för offentliga slutpunkter. Certifikat har följande krav på hög nivå:

• Du kan använda ett enskilt jokerteckencertifikat eller använda en uppsättning dedikerade certifikat och sedan använda jokertecken endast för slutpunkter som lagring och Key Vault.
• Certifikat kan utfärdas av en offentlig betrodd certifikatutfärdare (CA) eller en kundhanterad certifikatutfärdare.

Mer information om vilka PKI-certifikat som krävs för att distribuera Azure Stack Hub och hur du hämtar dem finns i Certifikatkrav för Azure Stack Hub Public Key Infrastructure.

Viktigt

Den angivna PKI-certifikatinformationen bör användas som allmän vägledning. Innan du skaffar PKI-certifikat för Azure Stack Hub bör du samarbeta med din OEM-maskinvarupartner. De ger mer detaljerad vägledning och krav för certifikat.

Tidssynkronisering

Du måste välja en specifik tidsserver som används för att synkronisera Azure Stack Hub. Tidssynkronisering är avgörande för Azure Stack Hub och dess infrastrukturroller eftersom det används för att generera Kerberos-biljetter. Kerberos-biljetter används för att autentisera interna tjänster med varandra.

Du måste ange en IP-adress för tidssynkroniseringsservern. Även om de flesta komponenterna i infrastrukturen kan matcha en URL stöder vissa endast IP-adresser. Om du använder det frånkopplade distributionsalternativet måste du ange en tidsserver i företagsnätverket som du är säker på att du kan nå från infrastrukturnätverket i Azure Stack Hub.

Viktigt

Om din tidsserver inte är en Windows-baserad NTP-server måste du lägga ,0x8 till slutet av IP-adressen. Till exempel 10.1.1.123,0x8.

Ansluta Azure Stack Hub till Azure

För hybridmolnscenarier måste du planera hur du vill ansluta Azure Stack Hub till Azure. Det finns två metoder som stöds för att ansluta virtuella nätverk i Azure Stack Hub till virtuella nätverk i Azure:

• Plats-till-plats: En vpn-anslutning (virtual private network) över IPsec (IKE v1 och IKE v2). Den här typen av anslutning kräver en VPN-enhet eller routning och fjärråtkomsttjänst (RRAS). Mer information om VPN-gatewayer i Azure finns i Om VPN Gateway. Kommunikationen över den här tunneln är krypterad och säker. Bandbredden begränsas dock av tunnelns maximala dataflöde (100–200 Mbit/s).

• Utgående NAT: Som standard har alla virtuella datorer i Azure Stack Hub anslutning till externa nätverk via utgående NAT. Varje virtuellt nätverk som skapas i Azure Stack Hub får en offentlig IP-adress tilldelad till sig. Oavsett om den virtuella datorn är direkt tilldelad en offentlig IP-adress eller ligger bakom en lastbalanserare med en offentlig IP-adress, kommer den att ha utgående åtkomst via utgående NAT med hjälp av VIP för det virtuella nätverket. Den här metoden fungerar bara för kommunikation som initieras av den virtuella datorn och som är avsedd för externa nätverk (antingen Internet eller intranät). Den kan inte användas för att kommunicera med den virtuella datorn utifrån.

Alternativ för hybridanslutning

För hybridanslutning är det viktigt att överväga vilken typ av distribution du vill erbjuda och var den ska distribueras. Du måste överväga om du behöver isolera nätverkstrafik per klientorganisation och om du ska ha en intranät- eller Internetdistribution.

• Azure Stack Hub för en klientorganisation: En Azure Stack Hub-distribution som ser ut, åtminstone ur ett nätverksperspektiv, som om det vore en klientorganisation. Det kan finnas många klientprenumerationer, men precis som alla intranättjänster färdas all trafik över samma nätverk. Nätverkstrafik från en prenumeration överförs via samma nätverksanslutning som en annan prenumeration och behöver inte isoleras via en krypterad tunnel.

• Azure Stack Hub för flera innehavare: En Azure Stack Hub-distribution där varje klientprenumerations trafik som är bunden till nätverk som är externa till Azure Stack Hub måste isoleras från andra klientorganisationers nätverkstrafik.

• Intranätdistribution: En Azure Stack Hub-distribution som finns på ett företags intranät, vanligtvis på privat IP-adressutrymme och bakom en eller flera brandväggar. De offentliga IP-adresserna är inte riktigt offentliga eftersom de inte kan dirigeras direkt via det offentliga Internet.

• Internetdistribution: En Azure Stack Hub-distribution som är ansluten till det offentliga Internet och använder internetroutningsbara offentliga IP-adresser för det offentliga VIP-intervallet. Distributionen kan fortfarande sitta bakom en brandvägg, men det offentliga VIP-intervallet kan nås direkt från det offentliga Internet och Azure.

I följande tabell sammanfattas hybridanslutningsscenarierna med för-, nackdelarna och användningsfallen.

Scenario	Anslutningsmetod	Fördelar	Nackdelar	Bra för
Azure Stack Hub för enskild klientorganisation, intranätdistribution	Utgående NAT	Bättre bandbredd för snabbare överföringar. Enkelt att implementera; inga gatewayer krävs.	Trafiken är inte krypterad. ingen isolering eller kryptering utanför stacken.	Företagsdistributioner där alla klienter är lika betrodda. Företag som har en Azure ExpressRoute-krets till Azure.
Azure Stack Hub för flera klientorganisationer, intranätdistribution	Plats-till-plats-VPN	Trafik från klientorganisationens virtuella nätverk till målet är säker.	Bandbredden begränsas av vpn-tunnel från plats till plats. Kräver en gateway i det virtuella nätverket och en VPN-enhet i målnätverket.	Företagsdistributioner där viss klienttrafik måste skyddas från andra klientorganisationer.
Azure Stack Hub för enskild klientorganisation, internetdistribution	Utgående NAT	Bättre bandbredd för snabbare överföringar.	Trafiken är inte krypterad. ingen isolering eller kryptering utanför stacken.	Värdscenarier där klientorganisationen får en egen Azure Stack Hub-distribution och en dedikerad krets till Azure Stack Hub-miljön. Till exempel ExpressRoute och MpLS (Multiprotocol Label Switching).
Azure Stack Hub för flera klientorganisationer, internetdistribution	Plats-till-plats-VPN	Trafik från klientorganisationens virtuella nätverk till målet är säker.	Bandbredden begränsas av vpn-tunnel från plats till plats. Kräver en gateway i det virtuella nätverket och en VPN-enhet i målnätverket.	Värdscenarier där providern vill erbjuda ett moln för flera innehavare, där klienterna inte litar på varandra och trafiken måste krypteras.

Använda ExpressRoute

Du kan ansluta Azure Stack Hub till Azure via ExpressRoute för både intranät för en klientorganisation och scenarier med flera klientorganisationer. Du behöver en etablerad ExpressRoute-krets via en anslutningsprovider.

Följande diagram visar ExpressRoute för ett scenario med en enda klientorganisation (där "Kundens anslutning" är ExpressRoute-kretsen).

Följande diagram visar ExpressRoute för ett scenario med flera innehavare.

Extern övervakning

Om du vill få en enda vy över alla aviseringar från din Azure Stack Hub-distribution och dina enheter och integrera aviseringar i befintliga IT Service Management-arbetsflöden för biljetthantering kan du integrera Azure Stack Hub med externa datacenterövervakningslösningar.

Maskinvarulivscykelvärden ingår i Azure Stack Hub-lösningen och är en dator utanför Azure Stack Hub som kör OEM-leverantörshanterad hanteringsverktyg för maskinvara. Du kan använda dessa verktyg eller andra lösningar som direkt integreras med befintliga övervakningslösningar i ditt datacenter.

I följande tabell sammanfattas listan över tillgängliga alternativ.

Område	Extern övervakningslösning
Azure Stack Hub-programvara	Hanteringspaket för Azure Stack Hub för Operations Manager Nagios-plugin-program REST-baserade API-anrop
Fysiska servrar (BMC:er via IPMI)	OEM-maskinvara – Hanteringspaket för Operations Manager-leverantörer OEM-maskinvarulösning som tillhandahålls av leverantören Maskinvaruleverantören Nagios plugin-program. Övervakningslösning som stöds av OEM-partner (ingår)
Nätverksenheter (SNMP)	Identifiering av nätverksenheter i Operations Manager OEM-maskinvarulösning som tillhandahålls av leverantören Nagios switch plug-in
Hälsoövervakning av klientprenumeration	System Center Management Pack för Windows Azure

Observera följande krav:

• Lösningen du använder måste vara agentlös. Du kan inte installera agenter från tredje part i Azure Stack Hub-komponenter.
• Om du vill använda System Center Operations Manager krävs Operations Manager 2012 R2 eller Operations Manager 2016.

Säkerhetskopiering och haveriberedskap

Planering för säkerhetskopiering och haveriberedskap omfattar planering av både den underliggande Azure Stack Hub-infrastrukturen som är värd för virtuella IaaS-datorer och PaaS-tjänster samt för klientappar och data. Planera för dessa saker separat.

Skydda infrastrukturkomponenter

Du kan säkerhetskopiera Azure Stack Hub-infrastrukturkomponenter till en SMB-resurs som du anger:

• Du behöver en extern SMB-filresurs på en befintlig Windows-baserad filserver eller en enhet från tredje part.
• Använd samma resurs för säkerhetskopiering av nätverksväxlar och maskinvarulivscykelvärden. Oem-maskinvaruleverantören hjälper dig att ge vägledning för säkerhetskopiering och återställning av dessa komponenter eftersom de är externa för Azure Stack Hub. Du ansvarar för att köra arbetsflöden för säkerhetskopiering baserat på OEM-leverantörens rekommendation.

Om oåterkallelig dataförlust inträffar kan du använda infrastruktursäkerhetskopian för att återställa distributionsdata, till exempel:

• Indata och identifierare för distribution
• Tjänstkonton
• CA-rotcertifikat
• Federerade resurser (i frånkopplade distributioner)
• Planer, erbjudanden, prenumerationer och kvoter
• RBAC-princip- och rolltilldelningar
• Key Vault hemligheter

Varning

Som standard konfigureras din Azure Stack Hub-stämpel med endast ett CloudAdmin-konto. Det finns inga återställningsalternativ om kontoautentiseringsuppgifterna förloras, komprometteras eller låses. Du förlorar åtkomst till den privilegierade slutpunkten och andra resurser.

Vi rekommenderar starkt att du skapar ytterligare CloudAdmin-konton för att undvika omdistribution av din stämpel på egen bekostnad. Se till att du dokumenterar dessa autentiseringsuppgifter baserat på företagets riktlinjer.

Skydda klientappar på virtuella IaaS-datorer

Azure Stack Hub säkerhetskopierar inte klientappar och data. Du måste planera för säkerhetskopiering och haveriberedskapsskydd till ett mål utanför Azure Stack Hub. Klientskydd är en klientdriven aktivitet. För virtuella IaaS-datorer kan klienter använda gästtekniker för att skydda filmappar, appdata och systemtillstånd. Men som företag eller tjänstleverantör kanske du vill erbjuda en lösning för säkerhetskopiering och återställning i samma datacenter eller externt i ett moln.

Om du vill säkerhetskopiera virtuella Linux- eller Windows IaaS-datorer måste du använda säkerhetskopieringsprodukter med åtkomst till gästoperativsystemet för att skydda fil-, mapp-, operativsystemtillstånd och appdata. Du kan använda Azure Backup, System Center Datacenter Protection Manager eller produkter från tredje part som stöds.

Om du vill replikera data till en sekundär plats och samordna programredundans om en katastrof inträffar kan du använda Azure Site Recovery eller produkter från tredje part som stöds. Dessutom kan appar som stöder intern replikering, till exempel Microsoft SQL Server, replikera data till en annan plats där appen körs.

Läs mer

• Information om användningsfall, inköp, partner och OEM-maskinvaruleverantörer finns på produktsidan för Azure Stack Hub .
• Information om översikten och geo-tillgänglighet för integrerade Azure Stack Hub-system finns i faktabladet: Azure Stack Hub: Ett tillägg till Azure.

Nästa steg

Anslutningsmodeller för Azure Stack Hub-distribution