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. En förståelse av dessa överväganden hjälper dig när du arbetar med oem-maskinvaruleverantören när de distribuerar Azure Stack Hub till ditt datacenter.
Obs
Azure Stack Hub-integrerade system kan bara köpas från auktoriserade maskinvaruleverantörer.
För att distribuera Azure Stack Hub måste du tillhandahålla planeringsinformation till din lösningsleverantör innan distributionen börjar för att hjälpa processen att gå snabbt och smidigt. Den information som krävs omfattar 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 routrar, växlar och brandväggar för att förbereda anslutningen till de nya Azure Stack Hub-lösningsväxlarna. Se till att ha ämnesexperten redo för att hjälpa dig med din planering.
Överväganden för 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 i 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 Azure Stack Hub-kapacitetsplaneraren hjälper dig att fatta välgrundade beslut om planeringskapacitet på två sätt. Det första är genom att välja ett maskinvaruerbjudande och försöka anpassa en kombination av resurser. Den andra är genom att definiera den arbetsbelastning som Azure Stack Hub är avsedd att köra för att visa tillgängliga maskinvaru-SKU:er som kan stödja den. Slutligen är kalkylbladet avsett som en guide för 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 representationer eller garantier, uttryckliga eller underförstådda, med avseende på den information som tillhandahålls i kalkylbladet.
Hanteringsöverväganden
Azure Stack Hub är ett förseglat system där infrastrukturen är låst både ur ett behörighets- och nätverksperspektiv. Listor över nätverksåtkomstkontroll (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 åtgärder 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:et). Det finns ingen åtkomst till systemet via andra hanteringsverktyg som Hyper-V Manager eller Failover Cluster Manager. För att skydda systemet kan programvara från tredje part (till exempel agenter) inte 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 systemdistribution. 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, konton som de använder eller om de kan ansluta till en Active Directory-domän och så vidare. De här sakerna ä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 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 åtkomstkontroll (RBAC) i Azure Stack Hub. När åtkomsten 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 distributionkan 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, vilket sedan faktureras via Azure Commerce.
- Endast kapacitetsbaserad licensiering stöds om du distribuerar frånkopplad från internet.
Mer information om licensieringsmodellerna finns i Microsoft Azure Stack Hub-paketering och prissättning.
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 följande 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.comhttps://adminportal.east.cloud.fabrikam.com
Viktig
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.
| Namn | Beskrivning |
|---|---|
| Regionnamn | 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 Azure Stack Hub hanterar. 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 (som -, #och så vidare) tillåts. |
| Externt domännamn | Namnet på zonen i Domain Name System (DNS) för slutpunkter med externa virtuella IP-adresser (VIP). Används i FQDN (Fullt Kvalificerat Domännamn) för dessa offentliga VIP:er. |
| 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 ange SSL-certifikat (Secure Sockets Layer) för offentliga slutpunkter. På hög nivå har certifikat följande krav:
- 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 offentlig nyckelinfrastruktur i Azure Stack Hub.
Viktig
Den angivna PKI-certifikatinformationen bör användas som allmän vägledning. Innan du skaffar PKI-certifikat för Azure Stack Hub ska 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 lösa en URL stöder vissa endast IP-adresser. Om du använder alternativet för frånkopplad distribution måste du ange en tidsserver i företagets nätverk som du är säker på att du kan nå från infrastrukturnätverket i Azure Stack Hub.
Viktig
Om tidsservern inte är en Windows-baserad NTP-server måste du lägga till ,0x8 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 (virtuellt privat nätverk) via 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). Det kan inte användas för att kommunicera med den virtuella datorn utifrån.
Alternativ för hybridanslutning
För hybridanslutningar är det viktigt att tänka på 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 klientorganisationer: En Azure Stack Hub-distribution där varje klientprenumerationstrafik 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 i 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 som använder internetrouterbara offentliga IP-adresser för det offentliga VIP-intervallet. Distributionen kan fortfarande ligga 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-, nackdelar och användningsfall.
| Scenarie | Anslutningsmetod | Fördelar | Nackdelar | Bra för |
|---|---|---|---|---|
| Azure Stack Hub för enskild klientorganisation, intranätsdistribution | 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 användare ä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 hyresgästens VNet till destinationen ä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 klienter. |
| Azure Stack Hub för enskild användare, internetinstallation | 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 hyresgästens virtuella nätverk till slutmå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 tjänsteleverantören vill erbjuda ett moln med flera hyresgäster, där hyresgästerna 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 provisionerad ExpressRoute-krets genom en anslutningsleverantör.
I följande diagram visas 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 klientorganisationer.
Extern övervakning
Om du vill få en enda vy över alla aviseringar från din Azure Stack Hub-distribution och dina enheter, och för att integrera aviseringar i befintliga IT Service Management-arbetsflöden för biljetthantering, kan du integrera Azure Stack Hub med övervakningslösningar för externa datacenter.
Maskinvarulivscykelvärden, som ingår i Azure Stack Hub-lösningen, är en dator utanför Azure Stack Hub som kör hanteringsverktyg tillhandahållna av OEM-leverantörer för maskinvara. Du kan använda dessa verktyg eller andra lösningar som integreras direkt 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 |
Azure Stack Hub Management Pack för Operations Manager Nagios-plugin REST-baserade API-anrop |
| Fysiska servrar (BMC via IPMI) | OEM-maskinvara – Hanteringspaket för Operations Manager-leverantörer OEM-maskinvarulösning som tillhandahålls av leverantören Plugin-program för maskinvaruleverantören Nagios. Övervakningslösning som stöds av OEM-partner (ingår) |
| Nätverksenheter (SNMP) | Identifiering av operations manager-nätverksenheter OEM-maskinvarulösning som tillhandahålls av leverantören Nagios switch plug-in |
| Hälsokontroll av hyresgästers prenumerationer | System Center-hanteringspaket 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 för 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-delning 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 maskinvarulivscykelns värd. 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 säkerhetskopieringen av infrastrukturen för att återställa distributionsdata, till exempel:
- Distributionsindata och identifierare
- Tjänstkonton
- CA-rotcertifikat
- Federerade resurser (i frånkopplade utplaceringsmiljöer)
- 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 går förlorade, komprometteras eller låses. Du förlorar åtkomsten till den privilegierade slutpunkten och andra resurser.
Vi rekommenderar starkt att du skapa ytterligare CloudAdmin-kontonfö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 haveriskydd 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 säkerhetskopierings- och återställningslösning i samma datacenter eller externt i ett moln.
För att 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-, operativsystemstillstå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 ett haveri inträffar kan du använda Azure Site Recovery eller produkter från tredje part som stöds. Appar som stöder intern replikering, till exempel Microsoft SQL Server, kan också replikera data till en annan plats där appen körs.
Lära sig mer
- Information om användningsfall, inköp, partner och OEM-maskinvaruleverantörer finns på produktsidan Azure Stack Hub.
- Information om översikten och geo-tillgängligheten för integrerade Azure Stack Hub-system finns i faktabladet: Azure Stack Hub: Ett tillägg av Azure.