Overwegingen voor de planning van 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 de implementatie begrijpen en hoe het systeem in uw datacenter past. Dit artikel bevat een algemeen overzicht van deze overwegingen om u te helpen belangrijke infrastructuurbeslissingen te nemen voor uw geïntegreerde Azure Stack Hub-systemen. Een goed begrip van 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 planningsgegevens aan uw oplossingsprovider verstrekken voordat de implementatie begint om het proces snel en soepel te laten verlopen. De vereiste informatie varieert over netwerken, beveiliging en identiteitsinformatie met veel belangrijke beslissingen die mogelijk kennis van veel verschillende gebieden en besluitvormers vereisen. U hebt personen van meerdere teams in uw organisatie nodig om ervoor te zorgen dat u alle vereiste informatie gereed hebt voordat u gaat implementeren. Het kan helpen om met uw hardwareleverancier te praten tijdens het verzamelen van deze informatie, omdat ze 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 vakexpert klaarstaat om u te helpen met uw planning.
Overwegingen voor capaciteitsplanning
Wanneer u een Azure Stack Hub-oplossing evalueert voor aanschaf, maakt u hardwareconfiguratiekeuzen die direct van invloed zijn op de totale capaciteit van de Azure Stack Hub-oplossing. Deze omvatten de klassieke keuzes van CPU, geheugendichtheid, opslagconfiguratie en algehele oplossingsschaal (bijvoorbeeld het aantal servers). In tegenstelling tot een traditionele virtualisatieoplossing is de eenvoudige rekenkundige berekening van deze onderdelen om te bepalen of bruikbare capaciteit niet van toepassing is. 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 wordt gereserveerd ter ondersteuning van tolerantie door de software van de oplossing bij te werken op een manier die de onderbreking van tenantworkloads minimaliseert.
De spreadsheet Azure Stack Hub-capaciteitsplanner helpt u op twee manieren weloverwogen beslissingen te nemen voor het plannen van capaciteit. De eerste is door een hardwareaanbieding te selecteren en een combinatie van resources aan te passen. De tweede stap is door de workload te definiëren die Azure Stack Hub moet uitvoeren om de beschikbare hardware-SKU's weer te geven die deze kunnen ondersteunen. Ten slotte is het spreadsheet bedoeld als richtlijn voor het nemen van beslissingen met betrekking tot het plannen en configureren van Azure Stack Hub.
Het spreadsheet is niet bedoeld als vervanging voor uw eigen onderzoek en analyse. Microsoft geeft geen verklaringen of garanties, uitdrukkelijk of impliciet, met betrekking tot de informatie die in het spreadsheet wordt verstrekt.
Overwegingen voor beheer
Azure Stack Hub is een verzegeld systeem, waarbij de infrastructuur is vergrendeld vanuit het perspectief van machtigingen en netwerken. 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 beheerhulpprogramma's, zoals Hyper-V Manager of Failoverclusterbeheer. Ter bescherming van het systeem kunnen 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 zijn opgelost via stappen voor het oplossen van 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 rekening houden met de id-provider die u wilt gebruiken voor de implementatie van Azure Stack Hub, ofwel Microsoft Entra ID of AD FS. U kunt na de implementatie geen andere id-providers overschakelen zonder volledige herimplementatie van het systeem. Als u niet de eigenaar bent van het Microsoft Entra-account en een account gebruikt dat u door uw Cloud Solution Provider hebt verstrekt, en als u besluit om van provider te wisselen en een ander Microsoft Entra-account te gebruiken, moet u contact opnemen met uw oplossingsprovider om de oplossing voor u opnieuw te implementeren tegen uw kosten.
De keuze van uw id-provider heeft geen 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 zijn gescheiden.
U kunt meerdere Azure Stack Hub-systemen implementeren met dezelfde Microsoft Entra-tenant of Active Directory.
AD FS- en Graph-integratie
Als u ervoor kiest om Azure Stack Hub te implementeren met 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 RBAC (Access Control) beheren in Azure Stack Hub. Wanneer toegang tot een resource is gedelegeerd, zoekt het Graph-onderdeel het gebruikersaccount in het bestaande Active Directory-forest op met behulp van het LDAP-protocol.
In het volgende diagram ziet u de geïntegreerde AD FS- en Grafiekverkeersstroom.
Licentiemodel
U moet bepalen welk licentiemodel u wilt gebruiken. De beschikbare opties zijn afhankelijk van het feit of u Azure Stack Hub implementeert die is verbonden met internet:
- Voor een verbonden implementatiekunt u betalen per gebruik of licenties op basis van capaciteit kiezen. Betalen per gebruik vereist een verbinding met Azure om gebruik te rapporteren. Deze worden vervolgens gefactureerd via Azure Commerce.
- Alleen licenties op basis van capaciteit worden ondersteund als u niet-verbonden van internet implementeren.
Zie Microsoft Azure Stack Hub-pakketten en prijzenvoor 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 externe domeinnaam. 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 op de volgende URL's:
https://portal.east.cloud.fabrikam.comhttps://adminportal.east.cloud.fabrikam.com
Belangrijk
De regio-naam die u kiest voor uw Azure Stack Hub implementatie moet uniek zijn en zal worden weergegeven in de portal-adressen.
De volgende tabel bevat een overzicht van deze beslissingen voor domeinnaamgeving.
| Naam | Beschrijving |
|---|---|
| Regio naam | 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 naam van de regio een fysieke locatie-identificator, zoals een datacenterlocatie. De regio-naam mag alleen uit letters en de cijfers 0 tot 9 bestaan. Er zijn geen speciale tekens (zoals -, #enzovoort) toegestaan. |
| Externe domeinnaam | De naam van de DNS-zone (Domain Name System) voor eindpunten met externe 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 in Azure Stack Hub is gemaakt voor infrastructuurbeheer. |
Certificaatvereisten
Voor implementatie moet u SSL-certificaten (Secure Sockets Layer) opgeven voor openbare eindpunten. Certificaten hebben op hoog niveau 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 voor meer informatie over welke PKI-certificaten vereist zijn om Azure Stack Hub te implementeren en hoe u deze kunt verkrijgen, certificaatvereisten voor openbare sleutelinfrastructuur van Azure Stack Hub.
Belangrijk
De verstrekte PKI-certificaatgegevens moeten worden gebruikt als algemene richtlijnen. Voordat u PKI-certificaten voor Azure Stack Hub verkrijgt, moet u contact opnemen met uw OEM-hardwarepartner. Ze bieden gedetailleerdere certificaatrichtlijnen en -vereisten.
Tijdsynchronisatie
U moet een specifieke tijdserver kiezen die wordt gebruikt om Azure Stack Hub te synchroniseren. 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 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 opgeven in uw bedrijfsnetwerk die u zeker weet te bereiken via het infrastructuurnetwerk in Azure Stack Hub.
Belangrijk
Als uw tijdserver geen op Windows gebaseerde NTP-server is, moet u ,0x8 het einde van het IP-adres toevoegen. 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 Routing and Remote Access Service (RRAS) vereist. Zie Over VPN Gatewayvoor meer informatie over VPN-gateways in Azure. De communicatie via deze tunnel is versleuteld en beveiligd. 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 verbinding met externe netwerken via uitgaande NAT. Elk virtueel netwerk dat in Azure Stack Hub wordt gemaakt, krijgt een openbaar IP-adres toegewezen. Of het de virtuele machine nu rechtstreeks een openbaar IP-adres is toegewezen of zich achter een load balancer bevindt met een openbaar IP-adres, zijn er uitgaande toegangsmogelijkheden via NAT met behulp van de VIP van het virtuele netwerk. Deze methode werkt alleen voor communicatie die wordt geïnitieerd door de VIRTUELE machine en bestemd is voor externe netwerken (internet of intranet). Het 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 bieden 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 er vanuit het oogpunt van netwerken naar kijkt, alsof het één tenant is. Er kunnen veel tenantabonnementen zijn, maar net als elke intranetservice, wordt al het verkeer via dezelfde netwerken verzonden. 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 voor 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 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 internetrouteerbare openbare IP-adressen gebruikt voor het openbare VIP-bereik. De implementatie kan nog steeds achter een firewall zitten, 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; er zijn 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 tenant-verkeer moet worden beveiligd voor 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 krijgt voor de Azure Stack Hub-omgeving. Bijvoorbeeld ExpressRoute en Multiprotocol Label Switching (MPLS). |
| Azure Stack Hub met meerdere tenants, 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 intranet met één tenant als scenario's met meerdere tenants. U hebt een ingericht ExpressRoute-circuit nodig dat via een connectiviteitsprovider loopt.
In het volgende diagram ziet u ExpressRoute voor een scenario met één tenant (waarbij de verbinding van de klant 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 om waarschuwingen te integreren in bestaande IT Service Management-werkstromen voor ticketing, kunt u Azure Stack Hub integreren met bewakingsoplossingen voor externe datacenters.
Opgenomen in de Azure Stack Hub-oplossing, is de host voor de levenscyclus van hardware een computer buiten Azure Stack Hub waarop OEM-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 API-aanroepen op basis van REST |
| Fysieke servers (BMC's via IPMI) | OEM-hardware - Beheerpakket voor leveranciers van Operations Manager Door de OEM-hardwareleverancier geleverde oplossing Nagios-invoegtoepassingen van hardwareleverancier. Bewakingsoplossing die door OEM-partners wordt ondersteund (inbegrepen) |
| Netwerkapparaten (SNMP) | Detectie van Operations Manager-netwerkapparaten Door OEM-hardwareleverancier geleverde oplossing Nagios switch plug-in |
| Gezondheidsmonitoring van tenantabonnement | System Center-beheerpakket voor Windows Azure |
Let op 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, en voor tenant-apps en -gegevens. Plan deze dingen afzonderlijk.
Infrastructuuronderdelen beveiligen
U kunt een back-up maken van Azure Stack Hub infrastructuuronderdelen 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 richtlijnen te bieden voor het maken van back-ups en het herstellen van deze onderdelen, omdat deze extern zijn voor Azure Stack Hub. 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
- Gefedereerde bronnen (in losgekoppelde implementaties)
- Plannen, aanbiedingen, abonnementen en quota
- RBAC-beleid en roltoewijzingen
- Key Vault-geheimen
Waarschuwing
Standaard is uw Azure Stack Hub-stempel geconfigureerd met slechts één CloudAdmin-account. Er zijn geen herstelopties als de accountreferenties verloren gaan, gecompromitteerd of vergrendeld zijn. U hebt geen toegang meer tot het bevoegde eindpunt en andere resources.
Het wordt ten zeerste aanbevolen dat u extra CloudAdmin-accountste maken, om te voorkomen dat uw stempel op eigen kosten opnieuw wordt geïmplementeerd. Zorg ervoor dat u deze referenties documenteert op basis van de richtlijnen van uw bedrijf.
Tenant-apps beveiligen op IaaS-VM's
Azure Stack Hub maakt geen back-ups van tenant-apps en -gegevens. U moet back-up- en herstelbeveiliging plannen naar 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 bestand-, map-, besturingssysteemstatus 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.
Meer informatie
- Zie de Azure Stack Hub productpagina voor informatie over use cases, aankoop, partners en OEM-hardwareleveranciers.
- Zie het witboek: Azure Stack Hub: Een uitbreiding van Azurevoor meer informatie over de roadmap en geobeschikbaarheid voor geïntegreerde Azure Stack Hub-systemen.