Planningsoverwegingen voor datacenterintegratie voor geïntegreerde Azure Stack Hub-systemen

Als u geïnteresseerd bent in een geïntegreerd Azure Stack Hub-systeem, moet u de belangrijkste planningsoverwegingen voor implementatie begrijpen en weten hoe het systeem in uw datacenter past. Dit artikel biedt een algemeen overzicht van deze overwegingen om u te helpen belangrijke beslissingen te nemen over de infrastructuur voor uw geïntegreerde Azure Stack Hub-systemen. Inzicht in deze overwegingen helpt bij het werken met uw OEM-hardwareleverancier tijdens het implementeren van Azure Stack Hub in uw datacenter.

Notitie

Geïntegreerde Azure Stack Hub-systemen kunnen alleen worden aangeschaft bij geautoriseerde hardwareleveranciers.

Als u Azure Stack Hub wilt implementeren, moet u uw oplossingsprovider planningsgegevens verstrekken voordat de implementatie wordt gestart, zodat het proces snel en soepel verloopt. De vereiste informatie varieert over netwerk-, beveiligings- en identiteitsgegevens met veel belangrijke beslissingen die mogelijk kennis vereisen van veel verschillende gebieden en besluitvormers. U hebt personen uit meerdere teams in uw organisatie nodig om ervoor te zorgen dat u alle vereiste informatie bij de hand hebt vóór de implementatie. Het kan helpen om met uw hardwareleverancier te praten tijdens het verzamelen van deze informatie, omdat deze mogelijk nuttig advies hebben.

Tijdens het onderzoeken en verzamelen van de vereiste informatie moet u mogelijk enkele configuratiewijzigingen vóór de implementatie aanbrengen in uw netwerkomgeving. Deze wijzigingen kunnen bestaan uit het reserveren van IP-adresruimten voor de Azure Stack Hub-oplossing en het configureren van uw routers, switches en firewalls om de connectiviteit met de nieuwe Azure Stack Hub-oplossingsswitches voor te bereiden. Zorg ervoor dat de expert op het gebied van het onderwerp in de rij staat om u te helpen met uw planning.

Overwegingen bij het plannen van capaciteit

Wanneer u een Azure Stack Hub-oplossing evalueert voor overname, maakt u hardwareconfiguratiekeuzen die een directe invloed hebben op de totale capaciteit van de Azure Stack Hub-oplossing. Deze omvatten de klassieke opties van CPU, geheugendichtheid, opslagconfiguratie en de algehele oplossingsschaal (bijvoorbeeld het aantal servers). In tegenstelling tot een traditionele virtualisatieoplossing is de eenvoudige berekening van deze onderdelen om bruikbare capaciteit te bepalen niet van toepassing. De eerste reden is dat Azure Stack Hub is ontworpen om de infrastructuur of beheeronderdelen binnen de oplossing zelf te hosten. De tweede reden is dat een deel van de capaciteit van de oplossing is gereserveerd ter ondersteuning van tolerantie door de software van de oplossing bij te werken op een manier die onderbreking van tenantworkloads minimaliseert.

Met de spreadsheet van azure Stack Hub-capaciteitsplanner kunt u op twee manieren weloverwogen beslissingen nemen voor het plannen van capaciteit. De eerste is door een hardwareaanbod te selecteren en te proberen een combinatie van resources aan te passen. De tweede is door de workload te definiëren die Azure Stack Hub moet uitvoeren om de beschikbare hardware-SKU's weer te geven die dit kunnen ondersteunen. Ten slotte is het spreadsheet bedoeld als hulp bij het nemen van beslissingen met betrekking tot de planning en configuratie van Azure Stack Hub.

Het werkblad is niet bedoeld als vervanging voor uw eigen onderzoek en analyse. Microsoft geeft geen verklaringen of garanties, expliciet of impliciet, met betrekking tot de informatie die in het spreadsheet wordt verstrekt.

Overwegingen ten aanzien van het beheer

Azure Stack Hub is een verzegeld systeem, waarbij de infrastructuur is vergrendeld, zowel vanuit het oogpunt van machtigingen als het netwerk. Netwerktoegangsbeheerlijsten (ACL's) worden toegepast om al het niet-geautoriseerde binnenkomende verkeer en alle onnodige communicatie tussen infrastructuuronderdelen te blokkeren. Dit systeem maakt het moeilijk voor onbevoegde gebruikers om toegang te krijgen tot het systeem.

Voor dagelijks beheer en bewerkingen is er geen onbeperkte beheerderstoegang tot de infrastructuur. Azure Stack Hub-operators moeten het systeem beheren via de beheerdersportal of via Azure Resource Manager (via PowerShell of de REST API). Er is geen toegang tot het systeem door andere beheerprogramma's, zoals Hyper-V-beheer of Failoverclusterbeheer. Ter bescherming van het systeem kan software van derden (bijvoorbeeld agents) niet worden geïnstalleerd in de onderdelen van de Azure Stack Hub-infrastructuur. Interoperabiliteit met externe beheer- en beveiligingssoftware vindt plaats via PowerShell of de REST API.

Neem contact op met Microsoft Ondersteuning wanneer u een hoger toegangsniveau nodig hebt voor het oplossen van problemen die niet worden opgelost met behulp van bemiddelingsstappen voor waarschuwingen. Via ondersteuning is er een methode om tijdelijke volledige beheerderstoegang tot het systeem te bieden voor geavanceerdere bewerkingen.

Identiteitsoverwegingen

Id-provider kiezen

U moet overwegen welke id-provider u wilt gebruiken voor de implementatie van Azure Stack Hub, Microsoft Entra id of AD FS. U kunt na de implementatie niet schakelen tussen id-providers zonder volledige herimplementatie van het systeem. Als u niet de eigenaar bent van het Microsoft Entra-account en een account gebruikt dat aan u is verstrekt door uw cloudoplossingsprovider, en als u besluit van provider te veranderen en een ander Microsoft Entra-account te gebruiken, moet u contact opnemen met uw oplossingsprovider om de oplossing voor u opnieuw te implementeren op uw kosten.

De keuze van uw id-provider is niet van invloed op virtuele tenantmachines (VM's), het identiteitssysteem, accounts die ze gebruiken of of ze lid kunnen worden van een Active Directory-domein, enzovoort. Deze dingen staan los van elkaar.

U kunt meerdere Azure Stack Hub-systemen implementeren met dezelfde Microsoft Entra tenant of Active Directory.

INTEGRATIE VAN AD FS en Graph

Als u ervoor kiest om Azure Stack Hub te implementeren met behulp van AD FS als id-provider, moet u het AD FS-exemplaar in Azure Stack Hub integreren met een bestaand AD FS-exemplaar via een federatieve vertrouwensrelatie. Met deze integratie kunnen identiteiten in een bestaand Active Directory-forest worden geverifieerd met resources in Azure Stack Hub.

U kunt de Graph-service ook integreren in Azure Stack Hub met de bestaande Active Directory. Met deze integratie kunt u Role-Based Access Control (RBAC) beheren in Azure Stack Hub. Wanneer toegang tot een resource is gedelegeerd, zoekt het Graph-onderdeel het gebruikersaccount op in het bestaande Active Directory-forest met behulp van het LDAP-protocol.

In het volgende diagram ziet u de geïntegreerde AD FS- en Graph-verkeersstroom.

Licentiemodel

U moet beslissen welk licentiemodel u wilt gebruiken. De beschikbare opties zijn afhankelijk van of u Azure Stack Hub implementeert die is verbonden met internet:

• Voor een verbonden implementatie kunt u kiezen voor betalen per gebruik of licenties op basis van capaciteit. Voor betalen per gebruik is een verbinding met Azure vereist om gebruik te rapporteren. Dit wordt vervolgens gefactureerd via Azure Commerce.
• Alleen licenties op basis van capaciteit worden ondersteund als u de verbinding met internet hebt verbroken .

Zie Pakketten en prijzen van Microsoft Azure Stack Hub voor meer informatie over de licentiemodellen.

Naamgevingsbeslissingen

U moet nadenken over hoe u uw Azure Stack Hub-naamruimte wilt plannen, met name de regionaam en de naam van het externe domein. De externe FQDN (Fully Qualified Domain Name) van uw Azure Stack Hub-implementatie voor openbare eindpunten is de combinatie van deze twee namen: <regio>.<fqdn>. Bijvoorbeeld east.cloud.fabrikam.com. In dit voorbeeld zijn de Azure Stack Hub-portals beschikbaar via de volgende URL's:

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

Belangrijk

De regionaam die u kiest voor uw Azure Stack Hub-implementatie moet uniek zijn en wordt weergegeven in de portaladressen.

De volgende tabel bevat een overzicht van deze domeinnaamgevingsbeslissingen.

Naam	Beschrijving
Regionaam	De naam van uw eerste Azure Stack Hub-regio. Deze naam wordt gebruikt als onderdeel van de FQDN voor de openbare virtuele IP-adressen (VIP's) die door Azure Stack Hub worden beheerd. Normaal gesproken is de regionaam een fysieke locatie-id, zoals een datacenterlocatie. De regionaam mag alleen bestaan uit letters en cijfers tussen 0-9. Er zijn geen speciale tekens (zoals -, #enzovoort) toegestaan.
Externe domeinnaam	De naam van de DNS-zone (Domain Name System) voor eindpunten met extern gerichte VIP's. Wordt gebruikt in de FQDN voor deze openbare VIP's.
Persoonlijke (interne) domeinnaam	De naam van het domein (en de interne DNS-zone) die zijn gemaakt in Azure Stack Hub voor infrastructuurbeheer.

Certificaatvereisten

Voor de implementatie moet u SSL-certificaten (Secure Sockets Layer) opgeven voor openbare eindpunten. Op hoog niveau hebben certificaten de volgende vereisten:

• U kunt één jokertekencertificaat gebruiken of u kunt een set toegewezen certificaten gebruiken en vervolgens alleen jokertekens gebruiken voor eindpunten zoals opslag en Key Vault.
• Certificaten kunnen worden uitgegeven door een openbare vertrouwde certificeringsinstantie (CA) of een door de klant beheerde CA.

Zie Azure Stack Hub Public Key Infrastructure-certificaatvereisten voor meer informatie over welke PKI-certificaten vereist zijn voor het implementeren van Azure Stack Hub en hoe u deze kunt verkrijgen.

Belangrijk

De opgegeven PKI-certificaatinformatie moet als algemene richtlijn worden gebruikt. Voordat u PKI-certificaten voor Azure Stack Hub aanschaft, moet u samenwerken met uw OEM-hardwarepartner. Ze bieden meer gedetailleerde richtlijnen en vereisten voor certificaten.

Tijdsynchronisatie

U moet een specifieke tijdserver kiezen die wordt gebruikt voor het synchroniseren van Azure Stack Hub. Tijdsynchronisatie is essentieel voor Azure Stack Hub en de bijbehorende infrastructuurrollen, omdat deze wordt gebruikt om Kerberos-tickets te genereren. Kerberos-tickets worden gebruikt om interne services met elkaar te verifiëren.

U moet een IP-adres opgeven voor de tijdsynchronisatieserver. Hoewel de meeste onderdelen in de infrastructuur een URL kunnen omzetten, ondersteunen sommige alleen IP-adressen. Als u de optie voor niet-verbonden implementatie gebruikt, moet u een tijdserver in uw bedrijfsnetwerk opgeven die u zeker kunt bereiken vanuit het infrastructuurnetwerk in Azure Stack Hub.

Belangrijk

Als uw tijdserver geen op Windows gebaseerde NTP-server is, moet u het einde van het IP-adres toevoegen ,0x8 . Bijvoorbeeld 10.1.1.123,0x8.

Azure Stack Hub verbinden met Azure

Voor hybride cloudscenario's moet u plannen hoe u Azure Stack Hub wilt verbinden met Azure. Er zijn twee ondersteunde methoden om virtuele netwerken in Azure Stack Hub te verbinden met virtuele netwerken in Azure:

• Site-naar-site: een VPN-verbinding (virtueel particulier netwerk) via IPsec (IKE v1 en IKE v2). Voor dit type verbinding is een VPN-apparaat of RRAS (Routing and Remote Access Service) vereist. Zie Over VPN Gateway voor meer informatie over VPN-gateways in Azure. De communicatie via deze tunnel is versleuteld en veilig. Bandbreedte wordt echter beperkt door de maximale doorvoer van de tunnel (100-200 Mbps).

• Uitgaande NAT: standaard hebben alle VM's in Azure Stack Hub connectiviteit met externe netwerken via uitgaande NAT. Aan elk virtueel netwerk dat wordt gemaakt in Azure Stack Hub, wordt een openbaar IP-adres toegewezen. Of de VM nu rechtstreeks een openbaar IP-adres krijgt toegewezen of zich achter een load balancer met een openbaar IP-adres bevindt, deze heeft uitgaande toegang via uitgaande NAT met behulp van het VIP van het virtuele netwerk. Deze methode werkt alleen voor communicatie die wordt geïnitieerd door de VM en is bestemd voor externe netwerken (internet of intranet). Deze kan niet worden gebruikt om van buiten met de virtuele machine te communiceren.

Opties voor hybride connectiviteit

Voor hybride connectiviteit is het belangrijk om te overwegen welk type implementatie u wilt aanbieden en waar deze wordt geïmplementeerd. U moet overwegen of u netwerkverkeer per tenant moet isoleren en of u een intranet- of internetimplementatie hebt.

• Azure Stack Hub met één tenant: een Azure Stack Hub-implementatie die, althans vanuit een netwerkperspectief, lijkt alsof het één tenant is. Er kunnen veel tenantabonnementen zijn, maar net als elke intranetservice gaat al het verkeer via dezelfde netwerken. Netwerkverkeer van het ene abonnement verloopt via dezelfde netwerkverbinding als een ander abonnement en hoeft niet te worden geïsoleerd via een versleutelde tunnel.

• Azure Stack Hub met meerdere tenants: een Azure Stack Hub-implementatie waarbij het verkeer van elk tenantabonnement dat is gebonden aan netwerken die zich buiten Azure Stack Hub bevinden, moet worden geïsoleerd van het netwerkverkeer van andere tenants.

• Intranetimplementatie: een Azure Stack Hub-implementatie die zich op een bedrijfsintranet bevindt, meestal op een privé-IP-adresruimte en achter een of meer firewalls. De openbare IP-adressen zijn niet echt openbaar omdat ze niet rechtstreeks via het openbare internet kunnen worden gerouteerd.

• Internetimplementatie: een Azure Stack Hub-implementatie die is verbonden met het openbare internet en gebruikmaakt van via internet routeerbare openbare IP-adressen voor het openbare VIP-bereik. De implementatie kan zich nog steeds achter een firewall bevinden, maar het openbare VIP-bereik is rechtstreeks bereikbaar vanaf het openbare internet en Azure.

De volgende tabel bevat een overzicht van de hybride connectiviteitsscenario's met de voor- en nadelen en gebruiksscenario's.

Scenario	Connectiviteitsmethode	Voordelen	Nadelen	Goed voor
Azure Stack Hub met één tenant, intranetimplementatie	Uitgaande NAT	Betere bandbreedte voor snellere overdrachten. Eenvoudig te implementeren; geen gateways vereist.	Verkeer niet versleuteld; geen isolatie of versleuteling buiten de stack.	Bedrijfsimplementaties waarbij alle tenants even vertrouwd zijn. Ondernemingen met een Azure ExpressRoute-circuit naar Azure.
Azure Stack Hub met meerdere tenants, intranetimplementatie	Site-naar-site-VPN	Verkeer van het tenant-VNet naar de bestemming is veilig.	Bandbreedte wordt beperkt door site-naar-site VPN-tunnel. Vereist een gateway in het virtuele netwerk en een VPN-apparaat in het doelnetwerk.	Bedrijfsimplementaties waarbij sommige tenantverkeer moet worden beveiligd van andere tenants.
Azure Stack Hub met één tenant, internetimplementatie	Uitgaande NAT	Betere bandbreedte voor snellere overdrachten.	Verkeer niet versleuteld; geen isolatie of versleuteling buiten de stack.	Hostingscenario's waarbij de tenant een eigen Azure Stack Hub-implementatie en een toegewezen circuit naar de Azure Stack Hub-omgeving krijgt. Bijvoorbeeld ExpressRoute en Multiprotocol Label Switching (MPLS).
Multitenant Azure Stack Hub, internetimplementatie	Site-naar-site-VPN	Verkeer van het tenant-VNet naar de bestemming is veilig.	Bandbreedte wordt beperkt door site-naar-site VPN-tunnel. Vereist een gateway in het virtuele netwerk en een VPN-apparaat in het doelnetwerk.	Hostingscenario's waarbij de provider een cloud met meerdere tenants wil aanbieden, waarbij de tenants elkaar niet vertrouwen en verkeer moet worden versleuteld.

ExpressRoute gebruiken

U kunt Azure Stack Hub verbinden met Azure via ExpressRoute voor zowel intranetscenario's met één tenant als scenario's met meerdere tenants. U hebt een ingericht ExpressRoute-circuit nodig via een connectiviteitsprovider.

In het volgende diagram ziet u ExpressRoute voor een scenario met één tenant (waarbij 'Klantverbinding' het ExpressRoute-circuit is).

In het volgende diagram ziet u ExpressRoute voor een scenario met meerdere tenants.

Externe bewaking

Als u één weergave wilt krijgen van alle waarschuwingen van uw Azure Stack Hub-implementatie en -apparaten en waarschuwingen wilt integreren in bestaande IT Service Management-werkstromen voor ticketing, kunt u Azure Stack Hub integreren met bewakingsoplossingen voor externe datacenters.

De host voor de hardwarelevenscyclus die deel uitmaakt van de Azure Stack Hub-oplossing, is een computer buiten Azure Stack Hub waarop door de OEM-leverancier geleverde beheerhulpprogramma's voor hardware worden uitgevoerd. U kunt deze hulpprogramma's of andere oplossingen gebruiken die rechtstreeks kunnen worden geïntegreerd met bestaande bewakingsoplossingen in uw datacenter.

De volgende tabel bevat een overzicht van de lijst met momenteel beschikbare opties.

Gebied	Externe bewakingsoplossing
Azure Stack Hub-software	Azure Stack Hub Management Pack voor Operations Manager Nagios-invoegtoepassing OP REST gebaseerde API-aanroepen
Fysieke servers (BMC's via IPMI)	OEM-hardware - Management pack voor Operations Manager-leveranciers Oplossing die door de leverancier van OEM-hardware wordt geleverd Nagios-invoegtoepassingen van hardwareleverancier. Bewakingsoplossing die door OEM-partners wordt ondersteund (inbegrepen)
Netwerkapparaten (SNMP)	Detectie van Operations Manager-netwerkapparaten Oplossing die door de leverancier van OEM-hardware wordt geleverd Nagios switch plug-in
Statuscontrole van tenantabonnementen	System Center Management Pack voor Windows Azure

Houd rekening met de volgende vereisten:

• De oplossing die u gebruikt, moet zonder agent zijn. U kunt geen agents van derden installeren in Azure Stack Hub-onderdelen.
• Als u System Center Operations Manager wilt gebruiken, is Operations Manager 2012 R2 of Operations Manager 2016 vereist.

Back-up en herstel na noodgevallen

Het plannen van back-up en herstel na noodgevallen omvat het plannen van zowel de onderliggende Azure Stack Hub-infrastructuur die als host fungeert voor IaaS-VM's en PaaS-services, als voor tenant-apps en -gegevens. Plan deze dingen afzonderlijk.

Onderdelen van de infrastructuur beveiligen

U kunt een back-up maken van infrastructuuronderdelen van Azure Stack Hub naar een SMB-share die u opgeeft:

• U hebt een externe SMB-bestandsshare nodig op een bestaande Windows-bestandsserver of een apparaat van derden.
• Gebruik dezelfde share voor de back-up van netwerkswitches en de host voor de hardwarelevenscyclus. Uw OEM-hardwareleverancier helpt u bij het maken van back-ups en herstel van deze onderdelen, omdat deze zich buiten Azure Stack Hub bevinden. U bent verantwoordelijk voor het uitvoeren van de back-upwerkstromen op basis van de aanbeveling van de OEM-leverancier.

Als onherstelbaar gegevensverlies optreedt, kunt u de back-up van de infrastructuur gebruiken om implementatiegegevens opnieuw te verzenden, zoals:

• Implementatie-invoer en -id's
• Serviceaccounts
• CA-basiscertificaat
• Federatieve resources (in niet-verbonden implementaties)
• Plannen, aanbiedingen, abonnementen en quota
• RBAC-beleid en roltoewijzingen
• geheimen Key Vault

Waarschuwing

Uw Azure Stack Hub-stempel is standaard geconfigureerd met slechts één CloudAdmin-account. Er zijn geen herstelopties als de accountreferenties verloren gaan, zijn aangetast of vergrendeld. U hebt geen toegang meer tot het bevoegde eindpunt en andere resources.

Het wordt ten zeerste aanbevolen om extra CloudAdmin-accounts te maken om te voorkomen dat uw zegel op eigen kosten opnieuw wordt geïmplementeerd. Zorg ervoor dat u deze referenties documenteert op basis van de richtlijnen van uw bedrijf.

Tenant-apps op IaaS-VM's beveiligen

Azure Stack Hub maakt geen back-up van tenant-apps en -gegevens. U moet back-up- en herstelbeveiliging plannen voor een doel buiten Azure Stack Hub. Tenantbeveiliging is een tenantgestuurde activiteit. Voor IaaS-VM's kunnen tenants in-gasttechnologieën gebruiken om bestandsmappen, app-gegevens en systeemstatus te beveiligen. Als onderneming of serviceprovider wilt u echter mogelijk een back-up- en hersteloplossing aanbieden in hetzelfde datacenter of extern in een cloud.

Als u een back-up wilt maken van Linux- of Windows IaaS-VM's, moet u back-upproducten gebruiken met toegang tot het gastbesturingssysteem om bestanden, mappen, status van het besturingssysteem en app-gegevens te beveiligen. U kunt Azure Backup, System Center Datacenter Protection Manager of ondersteunde producten van derden gebruiken.

Als u gegevens wilt repliceren naar een secundaire locatie en failover van toepassingen wilt organiseren als er zich een noodgeval voordoet, kunt u Azure Site Recovery of ondersteunde producten van derden gebruiken. Apps die systeemeigen replicatie ondersteunen, zoals Microsoft SQL Server, kunnen ook gegevens repliceren naar een andere locatie waar de app wordt uitgevoerd.

Lees meer

• Zie de productpagina van Azure Stack Hub voor informatie over use cases, aankopen, partners en OEM-hardwareleveranciers.
• Zie het technische document: Azure Stack Hub: een uitbreiding van Azure voor informatie over de roadmap en geo-beschikbaarheid voor geïntegreerde Azure Stack Hub-systemen.

Volgende stappen

Verbindingsmodellen voor Azure Stack Hub-implementatie