Bereitstellen getrennter Vorgänge für Azure Local und den Verwaltungscluster

In diesem Artikel wird erläutert, wie sie getrennte Vorgänge für Azure Local in Ihrem Rechenzentrum bereitstellen. Dieser Schritt ist wichtig, um Azure Local ohne ausgehende Netzwerkverbindung bereitzustellen und auszuführen. Nachdem Sie den Verwaltungscluster (Steuerungsebene) bereitgestellt haben, stellen Sie Ihre erste Azure Local Instanz bereit.

Wichtige Überlegungen

Berücksichtigen Sie bei der Bereitstellung getrennter Vorgänge und beim Erstellen Ihrer Verwaltungsinstanz die folgenden wichtigen Punkte:

  • Die Netzwerkkonfiguration und die Namen, die Sie im Portal eingeben, sollten mit Ihrem Setup und den zuvor erstellten Switches konsistent sein.
  • Virtuelle Bereitstellungen werden nicht unterstützt. Sie müssen über physische Computer verfügen.
  • Wenn Sie ein VLAN auf der Steuerebenen-Appliance benötigen, müssen Sie sicherstellen, dass Sie es mit dem Befehl Set-VMNetworkAdapterIsolation -ManagementOS einrichten.
  • Sie benötigen mindestens drei Computer, um getrennte Vorgänge zu unterstützen. Sie können bis zu 16 Computer für die Verwaltungsinstanz verwenden.
  • Die Bereitstellung des Azure Local Clusters kann mehrere Stunden dauern.
  • Die lokale Steuerungsebene kann während Knotenneustarts und -updates Ausfallzeiten erleben.
  • Während der Erstellung des Clusters erstellt der Prozess ein dünn bereitgestelltes 2-TB-Infrastrukturvolume für getrennte Vorgänge. Ändern oder löschen Sie die während des Bereitstellungsprozesses erstellten Infrastrukturbereiche nicht.
  • Wenn Sie die Azure Local-Instanz erstellen, verschiebt der Prozess die vm-Appliance für getrennte Vorgänge in den Clusterspeicher und konvertiert sie in einen gruppierten virtuellen Computer.

Voraussetzungen

Anforderungen Einzelheiten
Gerätetechnik Planen und Verstehen der Hardware
Identität Planen und Verstehen der Identität
Vernetzung Planen und Verstehen des Netzwerks
Public-Key-Infrastruktur Planen und Verstehen der Public Key-Infrastruktur (PKI)
Azure Local-Knoten vorbereiten Azure Local für den Offline-Betrieb vorbereiten
Abrufen getrennter Vorgänge Erwerben Sie abgekoppelte Vorgänge bei Azure Local

Weitere Informationen finden Sie unter Überblick über getrennte Azure Local Vorgänge.

Informationen zu bekannten Problemen mit getrennten Vorgängen für Azure Local finden Sie unter Bekannte Probleme bei getrennten Vorgängen.

Prüfliste für die Bereitstellung getrennter Vorgänge

Bevor Sie Azure Local mit getrennten Vorgängen bereitstellen, benötigen Sie Folgendes:

Reihenfolge des Einsatzes

Stellen Sie Azure Local mit getrennten Betriebsmodi ohne Netzwerkverbindung auf nicht-premium Hardware-Lagerhaltungseinheiten (SKUs) bereit. Weitere Informationen finden Sie unter Azure Local Catalog.

Sie stellen Azure Local mit getrennten Vorgängen in mehreren Schritten bereit und konfigurieren diese. ** Die folgende Abbildung zeigt die gesamte Reise, einschließlich nach der Bereitstellung.

Screenshot des Bereitstellungsablaufs für getrennte Vorgänge in Azure Local.

Hier ist eine kurze Übersicht über die Tools und Prozesse, die Sie während der Bereitstellung verwenden. Sie benötigen Zugriff auf Azure Local Knoten (Betriebssystem oder Host) für die ersten Phasen der Bereitstellung.

  1. Verwenden Sie die vorhandenen Tools und Prozesse, um das Betriebssystem zu installieren und zu konfigurieren. Sie benötigen lokalen Administratorzugriff auf alle Azure Local Knoten.
  2. Führen Sie PowerShell und das Operations-Modul auf dem ersten Computer aus (sortiert nach Knotennamen wie seed node). Sie müssen über lokalen Administratorzugriff verfügen.
  3. Verwenden Sie das lokale Azure-Portal, Azure PowerShell oder Azure CLI. Sie benötigen keinen physischen Knotenzugriff, aber Sie benötigen Azure Role-Based Access Control (RBAC) mit der Rolle Owner.
  4. Verwenden Sie das lokale Azure-Portal, Azure PowerShell oder Azure CLI. Sie benötigen keinen physischen Knotenzugriff, aber Sie benötigen Azure RBAC mit der Rolle Operator.

Bereitstellen getrennter Vorgänge (Steuerebene)

Getrennte Vorgänge müssen auf dem ersten Rechner (Seed-Knoten) bereitgestellt werden. Stellen Sie sicher, dass Sie die folgenden Schritte für jeden Knoten in Ihrem Verwaltungscluster ausführen. Weitere Informationen finden Sie unter Prepare Azure Local Machines.

Führen Sie die folgenden Schritte aus, um den ersten Computer für die Appliance für getrennte Vorgänge vorzubereiten:

  1. Ändern Sie den Pfad, um den richtigen Speicherort auszuwählen. Wenn Sie einen Datenträger initialisiert haben oder einen anderen Pfad als C verwenden: ändern Sie die $applianceConfigBasePath.

    Ein Beispiel:

    $applianceConfigBasePath = 'C:\AzureLocalDisconnectedOperations'

  2. Kopieren Sie die Installationsdateien für abgetrennte Vorgänge (Appliance ZIP, VHDX und Manifest) auf den ersten Computer. Speichern Sie diese Dateien im Basisordner, den Sie zuvor erstellt haben.

    Copy-Item \\fileserver\share\azurelocalfiles\* $applianceConfigBasePath

  3. Stellen Sie sicher, dass Sie über diese Dateien in Ihrem Basisordner verfügen, indem Sie den folgenden Befehl verwenden:

    • AzureLocal.DisconnectedOperations.zip
    • AzureLocal.DisconnectedOperations.manifest
    • ArcA_LocalData_A.vhdx
    • ArcA_SharedData_A.vhdx
    • OSAndDocker_A.vhdx
    • ArcA_SharedData_ACSTable_A.vhdx
    • ArcA_SharedData_ACSBlob_A.vhdx
    • ThirdPartyNotices.txt
    Get-ChildItem $applianceConfigBasePath

  4. Extrahieren Sie die ZIP-Datei im selben Ordner:

    Expand-Archive "$($applianceConfigBasePath)\AzureLocal.DisconnectedOperations.zip" -DestinationPath $applianceConfigBasePath

  5. Stellen Sie sicher, dass Sie über diese Dateien verfügen, indem Sie den folgenden Befehl verwenden:

    • OperationsModule (PowerShell-Modul für die Installation)
    • AzureLocal.DisconnectedOperations.manifest
    • AzureLocal.DisconnectedOperations.zip
    • manifest.xml
    • IRVM.zip
    • ArcA_LocalData_A.vhdx
    • ArcA_SharedData_A.vhdx
    • ArcA_SharedData_ACSBlob_A.vhdx
    • ArcA_SharedData_ACSTable_A.vhdx
    • OSAndDocker_A.vhdx
    • Storage.json
    Get-ChildItem $applianceConfigBasePath

    Hinweis

    Entfernen Sie an diesem Punkt die AzureLocal.DisconnectedOperations.zip Datei, um Speicherplatz zu sparen.

  6. Kopieren Sie das Stammverzeichnis der Zertifikate. Speichern Sie diese Dateien im Basisordner, den Sie zuvor erstellt haben.

    $certsPath = "$($applianceConfigBasePath)\certs"  
Copy-Item \\fileserver\share\azurelocalcerts $certspath -recurse

  7. Überprüfen Sie die Zertifikate, den öffentlichen Schlüssel und den Verwaltungsendpunkt. Sie sollten über zwei Ordner verfügen: ManagementEndpointsCerts und IngressEndpointsCerts mindestens 24 Zertifikate.

    Get-ChildItem $certsPath 
Get-ChildItem $certsPath -recurse -filter *.pfx

  8. Importieren Sie das Operations-Modul. Führen Sie den Befehl als Administrator mithilfe von PowerShell aus. Ändern Sie den Pfad so, dass er ihrer Ordnerstruktur entspricht.

    Import-Module "$applianceConfigBasePath\OperationsModule\Azure.Local.DisconnectedOperations.psd1" -Force    

$mgmntCertFolderPath = "$certspath\ManagementEndpointsCerts"  
$ingressCertFolderPath = "$certspath\IngressEndpointsCerts"

Initialisieren der Parameter

Füllen Sie die erforderlichen Parameter basierend auf Ihrer Bereitstellungsplanung aus. Ändern Sie die Beispiele so, dass sie Ihrer Konfiguration entsprechen.

  1. Füllen Sie das Verwaltungsnetzwerkkonfigurationsobjekt auf.

    $CertPassword = "retracted"|ConvertTo-Securestring -AsPlainText -Force  
$ManagementIngressIpAddress = "192.168.50.100"  
$ManagementNICPrefixLength = 24  
$mgmtNetworkConfigParams = @{  
    ManagementIpAddress = $ManagementIngressIpAddress  
    ManagementIpv4PrefixLength = $ManagementNICPrefixLength  
    TlsCertificatePath = "$mgmntCertFolderPath\ManagementEndpointSsl.pfx"  
    TlsCertificatePassword = $CertPassword  
    ClientCertificatePath = "$mgmntCertFolderPath\ManagementEndpointClientAuth.pfx"  
    ClientCertificatePassword = $CertPassword  
}  
$managementNetworkConfiguration = New-ApplianceManagementNetworkConfiguration @mgmtNetworkConfigParams

    Hinweis

    Das Kennwort für die Zertifikate muss im sicheren Zeichenfolgenformat vorliegen. Zertifikate, die sich auf den Verwaltungsendpunkt beziehen, finden Sie unter PKI für getrennte Vorgänge.

  2. Füllen Sie das Ingress-Netzwerkkonfigurationsobjekt auf.

    $azureLocalDns = "192.168.200.150"  
$NodeGw = "192.168.200.1"  
$IngressIpAddress = "192.168.200.115"  
$NICPrefixLength= 24  
$ingressNetworkConfigurationParams = @{  
    DnsServer = $azureLocalDns  
    IngressNetworkGateway = $NodeGw  
    IngressIpAddress = $IngressIpAddress  
    IngressNetworkPrefixLength = $NICPrefixLength  
    ExternalDomainSuffix = "autonomous.cloud.private"
}  
$ingressNetworkConfiguration = New-ApplianceIngressNetworkConfiguration @ingressNetworkConfigurationParams

    Details zur Netzwerkkonfiguration finden Sie unter "Netzwerk für getrennte Vorgänge".

  3. Füllen Sie das Identitätskonfigurationsobjekt auf.

    $oidcCertChain = Get-CertificateChainFromEndpoint -requestUri 'https://adfs.azurestack.local/adfs'        
# Omitted this step if you don't have LDAPS.

$ldapsCertChain = Get-CertificateChainFromEndpoint -requestUri 'https://dc01.azurestack.local'

# LDAPS default port (Non secure default = 3268)
$ldapPort = 3269
$ldapPassword = 'RETRACTED'|ConvertTo-SecureString -AsPlainText -Force

# Populate params with LDAPS enabled.
$identityParams = @{  
    Authority = "https://adfs.azurestack.local/adfs"  
    ClientId = "<ClientId>"  
    RootOperatorUserPrincipalName = "operator@azurestack.local"  
    LdapServer = "adfs.azurestack.local"  
    LdapPort = $ldapPort 
    LdapCredential = New-Object PSCredential -ArgumentList @("ldap", $ldapPassword)  
    SyncGroupIdentifier = "<SynGroupIdentifier>"     
    OidcCertChainInfo = $oidcCertChain
    LdapsCertChainInfo = $ldapsCertChain             
}  
$identityConfiguration = New-ApplianceExternalIdentityConfiguration @identityParams

    Hinweis

    • LdapsCertChainInfo und OidcCertChain kann für Debugging- oder Demozwecke vollständig weggelassen werden. Informationen zum Abrufen von LdapsCertChainInfo und OidcCertChainInfo finden Sie unter PKI für getrennte Vorgänge.

    Es gibt ein Problem damit, dass das Get-CertificateChainFromEndpoint nicht wie vorgesehen exportiert wird. Führen Sie die Schritte in Bekannte Probleme für getrennte Vorgänge in der Azure Local-Umgebung aus, um dieses Problem zu beheben.

    Weitere Informationen finden Sie unter Identität für getrennte Operationen.

  4. Füllen Sie das Konfigurationsobjekt für externe Zertifikate auf.

    $ingressCertPassword = "retracted"|ConvertTo-Securestring -AsPlainText -Force  
$certsParams = @{  
    certificatesFolder = $ingressCertFolderPath  
    certificatePassword = $ingressCertPassword  
}  
$CertificatesConfiguration = New-ApplianceCertificatesConfiguration @certsParams

    Weitere Informationen finden Sie unter PKI für getrennte Vorgänge.

Installieren und Konfigurieren der Appliance

Verwenden Sie den folgenden Befehl, um die Appliance auf dem ersten Computer zu installieren und zu konfigurieren. Zeigen Sie den AzureLocalInstallationFile auf einen Pfad, der die IRVM01.zip enthält.

$networkIntentName = 'ManagementComputeStorage' 
$azureLocalInstallationFile = "$($applianceConfigBasePath)"  
$applianceManifestJsonPath = Join-Path $applianceConfigBasePath AzureLocal.DisconnectedOperations.manifest.json

$installAzureLocalParams = @{  
    Path = $azureLocalInstallationFile  
    IngressNetworkConfiguration = $ingressNetworkConfiguration  
    ManagementNetworkConfiguration = $managementNetworkConfiguration  
    IngressSwitchName = "ConvergedSwitch($networkIntentName)"  
    ManagementSwitchName = "ConvergedSwitch($networkIntentName)"  
    ApplianceManifestFile = $applianceManifestJsonPath  
    IdentityConfiguration = $identityConfiguration  
    CertificatesConfiguration = $CertificatesConfiguration      
}  

Install-Appliance @installAzureLocalParams -disconnectMachineDeploy -Verbose  

# Note: If you're deploying the appliance with limited connectivity, you can omit the flag -disconnectMachineDeploy.

Hinweis

Installieren Sie die Appliance auf dem ersten Computer, um sicherzustellen, dass Azure Local ordnungsgemäß bereitgestellt wird. Das Setup dauert einige Stunden und muss erfolgreich abgeschlossen werden, bevor Sie fortfahren. Sobald dies abgeschlossen ist, haben Sie eine lokale Kontrollebene, die in Ihrem Rechenzentrum läuft.

Wenn die Installation aufgrund falscher Netzwerk-, Identitäts- oder Observability-Einstellungen fehlschlägt, aktualisieren Sie das Konfigurationsobjekt, und führen Sie den Install-appliance Befehl erneut aus.

Sie können auch den Schalter -clean angeben, um die Installation von Anfang an zu starten. Mit diesem Switch werden alle vorhandenen Installationszustände zurückgesetzt und von Anfang an gestartet.

Konfigurieren der Observierbarkeit für Diagnose und Support

Es wird empfohlen, die Observierbarkeit so zu konfigurieren, dass vom System generierte Protokolle für Ihre erste Bereitstellung abgerufen werden. Dies gilt nicht, wenn Sie planen, luftlückend auszuführen, da vom System generierte Protokolle und Diagnosen Konnektivität erfordern.

Die erforderlichen Azure Ressourcen:

  • Eine in Azure verwendete Ressourcengruppe für die Appliance.
  • Ein Dienstprinzipalname (Service Principal Name, SPN) mit Mitwirkendenrechten für die Ressourcengruppe.

Führen Sie die folgenden Schritte aus, um die Beobachtbarkeit zu konfigurieren:

  1. Erstellen Sie auf einem Computer mit Azure CLI (oder mithilfe des Azure Cloud Shell im Azure Portal) das SPN. Führen Sie folgendes Skript aus:

    $resourcegroup = 'azure-disconnectedoperations'
$appname = 'azlocalobsapp'
az login
$g = (az group create -n $resourcegroup -l eastus)|ConvertFrom-Json
az ad sp create-for-rbac -n $appname --role Owner --scopes $g.id

# Get the Subscription ID
$j = (az account list | ConvertFrom-Json) | Where-object {$_.IsDefault}

# SubscriptionID:
$j.id

    Hier ist eine Beispielausgabe:

    {
  "appId": "<AppId>",
  "displayName": "azlocalobsapp",
  "password": "<RETRACTED>",
  "tenant": "<RETRACTED>"
}
<subscriptionID>

  2. Legen Sie die Observability-Konfiguration fest. Ändern, um ihren Umgebungsdetails zu entsprechen:

    $observabilityConfiguration = New-ApplianceObservabilityConfiguration -ResourceGroupName "azure-disconnectedoperations" `
  -TenantId "<TenantID>" `
  -Location "<Location>" `
  -SubscriptionId "<SubscriptionId>" `
  -ServicePrincipalId "<AppId>" `
  -ServicePrincipalSecret ("<Password>" | ConvertTo-SecureString -AsPlainText -Force)

Set-ApplianceObservabilityConfiguration -ObservabilityConfiguration $observabilityConfiguration

  3. Überprüfen Sie, ob die Beobachtbarkeit konfiguriert wurde:

    Get-ApplianceObservabilityConfiguration

Hinzufügen der Azure Local umgebung getrennter Vorgänge zu den Knoten

Damit die Knoten Ihre private Cloudumgebung verstehen können, müssen Sie die lokale Umgebung hinzufügen. Dies ist erforderlich, um die Azure Local-Knoten später an die Steuerebene anzubinden.

Führen Sie auf jedem Knoten folgendes aus PowerShell aus:

  1. Add-AzLocalEnvironment -CloudFQDN "autonomous.cloud.private"

Hinweis

Dies ist standardmäßig auf die integrierten DirectoryTenantId und Endpunkte festgelegt. Für weitere Informationen verwenden Sie Get-Help Add-AzLocalEnvironment

Verwenden Sie für Umgebungen vor 2603 den folgenden Legacyansatz Add-AzEnvironment .

# Legacy approach from prior to 2603 adding a private cloud environment
$applianceCloudName = "azure.local"
$applianceFQDN = "autonomous.cloud.private"

$AdminManagementEndPointUri = "https://armmanagement.$($applianceFQDN)/"
$DirectoryTenantId = "98b8267d-e97f-426e-8b3f-7956511fd63f"

#Retrieve disconnected operations endpoints

$armMetadataEndpoint = $AdminManagementEndPointUri.ToString().TrimEnd('/') + "/metadata/endpoints?api-version=2015-01-01"

$endpoints = Invoke-RestMethod -Method Get -Uri $armMetadataEndpoint -ErrorAction Stop

$azEnvironment = Add-AzEnvironment `
-Name $applianceCloudName `
-ActiveDirectoryEndpoint ($endpoints.authentication.loginEndpoint.TrimEnd('/') + "/") `
-ActiveDirectoryServiceEndpointResourceId $endpoints.authentication.audiences[0] `
-ResourceManagerEndpoint $AdminManagementEndPointUri.ToString() `
-GalleryEndpoint $endpoints.galleryEndpoint `
-MicrosoftGraphEndpointResourceId $endpoints.graphEndpoint `
-MicrosoftGraphUrl $endpoints.graphEndpoint `
-AdTenant $DirectoryTenantId `
-GraphEndpoint $endpoints.graphEndpoint `
-GraphAudience $endpoints.graphEndpoint `
-EnableAdfsAuthentication:($endpoints.authentication.loginEndpoint.TrimEnd("/").EndsWith("/adfs",[System.StringComparison]::OrdinalIgnoreCase)) 


# Verify that you can connect to the ARM endpoint (example showing device authentication)
Connect-AzAccount -EnvironmentName $applianceCloudName -UseDeviceAuthentication

Abonnementplatzierung für den dedizierten Verwaltungscluster

Wir erfordern die Bereitstellung eines vollständig dedizierten Verwaltungsclusters. Die empfohlene Vorgehensweise besteht darin, Ihren Verwaltungscluster im Betreiberabonnement zu platzieren. Auf diese Weise können Sie die Steuerungsebene von Workloads einschränken und isolieren, und Sie können die Erstellung von Workloads auf demselben Cluster wie andere Mandanten einschränken.

Die Trennung der Kontrollebene von den Arbeitslasten bietet eine klare Trennung der Verantwortlichkeiten.

Stellen Sie sicher, dass Sie den Zugriff auf das Betreiberabonnement nur auf erforderliche Mitarbeiter beschränken.

Registrieren der erforderlichen Ressourcenanbieter

Stellen Sie sicher, dass Sie die erforderlichen Ressourcenanbieter vor der Bereitstellung registrieren.

Nachfolgend finden Sie ein Beispiel zum Automatisieren der Registrierung von Ressourcenanbietern aus Azure PowerShell.

Hinweis

Führen Sie dieses Skript auf einem Clientcomputer aus, nicht auf den Azure Local Knoten. Wenn Sie sie auf einem Azure Local Knoten ausführen, überprüfen Sie die Az.Resources-Version, um Bereitstellungskonflikte zu vermeiden.

$applianceCloudName = "azure.local"
$subscriptionName = "Operator subscription"

<# Use this block only when running this script from an Azure Local node. Check whether Az.Resources 8.1.1 is installed and install it if needed (2603).
$requiredModule = "Az.Resources"
$requiredVersion = "8.1.1"
$installedModule = Get-InstalledModule -Name $requiredModule -ErrorAction SilentlyContinue

# If operating air-gaped, you need to download and copy this module manually
if (-not $installedModule -or $installedModule.Version -lt $requiredVersion) {
     Write-Host "Installing $requiredModule version $requiredVersion..."
     Install-Module -Name $requiredModule -RequiredVersion $requiredVersion -Force
     Write-Information "Make sure Az.Resources is the correct version if you are running this script on an Azure Local node rather than a client"
}#>

# Register resource providers
# Connect to the ARM endpointusing device authentication
Connect-AzAccount -EnvironmentName $applianceCloudName -UseDeviceAuthentication
Write-Host "Selecting a different subscription than the operator subscription.."
$subscription = Get-AzSubscription -SubscriptionName $subscriptionName

# Set the context to that subscription
Set-AzContext -SubscriptionId $subscription.Id

Register-AzResourceProvider -ProviderNamespace  "Microsoft.EdgeArtifact"
Register-AzResourceProvider -ProviderNamespace "Microsoft.HybridCompute" 
Register-AzResourceProvider -ProviderNamespace "Microsoft.GuestConfiguration" 
Register-AzResourceProvider -ProviderNamespace "Microsoft.HybridConnectivity" 
Register-AzResourceProvider -ProviderNamespace "Microsoft.AzureStackHCI" 
Register-AzResourceProvider -ProviderNamespace "Microsoft.Kubernetes" 
Register-AzResourceProvider -ProviderNamespace "Microsoft.KubernetesConfiguration" 
Register-AzResourceProvider -ProviderNamespace "Microsoft.ExtendedLocation" 
Register-AzResourceProvider -ProviderNamespace "Microsoft.ResourceConnector" 
Register-AzResourceProvider -ProviderNamespace "Microsoft.HybridContainerService"

# Not required on disconnected operations
# Register-AzResourceProvider -ProviderNamespace "Microsoft.Attestation"
# Register-AzResourceProvider -ProviderNamespace "Microsoft.Storage"
# Register-AzResourceProvider -ProviderNamespace "Microsoft.Insights"

# Required for automating Key Vault creation, not for Azure Local.
Register-AzResourceProvider -ProviderNamespace "Microsoft.KeyVault"

Warten Sie, bis alle Ressourcenanbieter im Status Registriert sind.

Führen Sie den folgenden Befehl aus, um alle Ressourcenanbieter und deren Status auflisten zu können.

Get-AzResourceProvider | Format-Table

Hinweis

Um ressourcenanbieterstatus im lokalen Portal zu registrieren oder anzuzeigen, wechseln Sie zu Ihrem Abonnement, erweitern Sie "Einstellungen", und wählen Sie "Ressourcenanbieter" aus.

Bereitstellen von Azure Local zum Bilden des Verwaltungsclusters

Sie haben jetzt eine Kontrollebene bereitgestellt und konfiguriert, eine Abonnement- und Ressourcengruppe, die für Ihre Azure Local Bereitstellung erstellt wurde, und (optional) ein SPN, der für die Bereitstellungsautomatisierung verwendet werden soll.

Überprüfen Sie die Bereitstellung, bevor Sie lokale Azure Ressourcen erstellen.

  1. Melden Sie sich mit dem Stammoperator an, den Sie während der Bereitstellung definiert haben, oder verwenden Sie ein Abonnementbesitzerkonto.
  2. Öffnen Sie von einem Client mit Netzwerkzugriff auf Ihre Ingress-IP Ihren Browser, und wechseln Sie zu https://portal.<FQDN>. Ersetzen Sie <FQDN> durch Ihren Domänennamen.
    • Sie werden an Ihren Identitätsanbieter umgeleitet, um sich anzumelden.
  3. Melden Sie sich bei Ihrem Identitätsanbieter mit den Anmeldeinformationen an, die Sie während der Bereitstellung konfiguriert haben.
    • Sie sollten sehen, dass das Azure-Portal in Ihrem Netzwerk ausgeführt wird.
  4. Überprüfen Sie, ob ein Abonnement für Ihre Azure Local-Infrastruktur (z. B. Betreiberabonnement) vorhanden ist.
  5. Überprüfen Sie, ob erforderliche Ressourcenanbieter im Abonnement registriert sind.
  6. Überprüfen Sie, ob eine Ressourcengruppe für Ihre Azure Local-Infrastruktur vorhanden ist (z. B. azurelocal-disconnected-operations).

Hinweis

Der Verwaltungscluster unterstützt keine Bereitstellungen ohne Active Directory.

Initialisieren Sie jeden Azure Local-Knoten

Führen Sie dieses PowerShell-Skript aus, um jeden Knoten zu initialisieren. Ändern Sie die Variablen, die erforderlich sind, um ihren Umgebungsdetails zu entsprechen:

Hinweis

Wenn Ihre Computer mit einem OEM-Image vorinstalliert sind, führen Sie die Schritte unter Behandeln vorinstallierter OEM-Images in getrennten Vorgängen aus.

$resourcegroup = 'azurelocal-management-cluster' 
$applianceCloudName = "azure.local"
$applianceConfigBasePath = "C:\AzureLocalDisconnectedOperations\"
$applianceFQDN = "autonomous.cloud.private"
 $subscriptionName = "Operator subscription"

Connect-AzAccount -EnvironmentName $applianceCloudName -UseDeviceAuthentication
Write-Host "Ensuring you are using operator subscription for the management cluster.."
$subscription = Get-AzSubscription -SubscriptionName $subscriptionName

# Set the context to that subscription
Set-AzContext -SubscriptionId $subscription.Id

$armTokenResponse = Get-AzAccessToken -ResourceUrl "https://armmanagement.$($applianceFQDN)"

# $ArmAccessToken = $armTokenResponse.Token
# Convert token to string for use in initialization
# Workaround needed for Az.Accounts 5.0.4
$ArmAccessToken = [System.Net.NetworkCredential]::new("", $armTokenResponse.Token).Password

# Bootstrap each node
Invoke-AzStackHciArcInitialization -SubscriptionID $subscription.Id -TenantID $subscription.TenantId -ResourceGroup $resourceGroup -Cloud $applianceCloudName -Region "Autonomous" -CloudFqdn $applianceFQDN -ArmAccessToken $ArmAccessToken -TargetSolutionVersion '12.2604.1003.1005'
# If bootstrap fails or timesouts after 45:00:00 - see known-issues with CRL.

Hinweis

Stellen Sie sicher, dass Sie die Initialisierung auf dem ersten Computer ausführen, bevor Sie zu anderen Knoten wechseln.

Knoten werden im lokalen Portal kurz nach dem Ausführen der Schritte angezeigt, und die Erweiterungen werden einige Minuten nach der Installation auf den Knoten angezeigt.

Sie können auch die Konfigurator-App verwenden, um jeden Knoten zu initialisieren. Stellen Sie sicher, dass der Parameter TargetSolutionVersion auf die richtige Lösungsversion festgelegt ist, die für die Bereitstellung verwendet wird, z. B. 12.2604.1003.1005.

Vorinstallierte OEM-Images in Offlinevorgängen verwalten

Voraussetzungen

Aktualisieren des Bootstrap-Diensts

  1. Kopieren und extrahieren Sie die BootstrapBundle.zip Datei. Dieses Bundle umfasst:

    • Update-BootstrapService.ps1. Signiertes Updateskript.

    • Microsoft.Azure. Edge.Bootstrap.Setup.Official.release.10.3342.1.3008.nupkg. Bootstrap NuGet-Paket.

  2. Kopieren Sie beide Dateien in jeden Azure Local Knoten. Kopieren Sie sie beispielsweise in "C:\packages".

  3. Führen Sie auf jedem Knoten das Bootstrap-Updateskript aus, und überprüfen Sie, ob der Bootstrap-Dienst erfolgreich aktualisiert wurde.

    # Run the bootstrap update script on the node
C:\packages\Update-BootstrapService.ps1 -NugetPath "C:\packages\Microsoft.Azure.Edge.Bootstrap.Setup.Official.release.10.3342.1.3008.nupkg"

    Screenshot des Bootstrap-Dienstupdates.

  4. Stellen Sie sicher, dass das Bootstrap-Dienstupdate erfolgreich abgeschlossen ist.

Initialisieren von Azure Arc

  1. Kopieren Sie Platform.zip in das Verzeichnis "C:\zerodayupdate" auf jedem Knoten.

  2. Führen Sie auf jedem Knoten den Invoke-AzStackHciArcInitialization Befehl aus:

    # Initialize Azure Arc with ALDO-specific parameters
  Invoke-AzStackHciArcInitialization
  -TenantId $Tenant
   -SubscriptionID $Subscription
   -ResourceGroup $RG
   -Region $Region
 # cloud must be set to `Azure.local` for disconnected operations
  -Cloud "Azure.local" 
  -TargetSolutionVersion "<SolutionVersionToDeploy>" 
 #LocalPlatformPackagePath - The local path to the `Platform.zip` file you copied
  -LocalPlatformPackagePath "C:\zerodayupdate\Platform.zip"

    Von Bedeutung

    Legen Sie den Parameter Cloud auf Azure.local fest. Jeder andere Wert bewirkt, dass der Knoten die Registrierung mit der öffentlichen Azure Cloud versucht, was in einer getrennten Umgebung fehlschlägt. Stellen Sie sicher, dass die TargetSolutionVersion ihrer nicht verbundenen Betriebsanwendungsversion entspricht. Nicht übereinstimmende Versionen verursachen Bereitstellungsfehler.

    Screenshot, der die Arc-Initialisierung zeigt.

  3. Warten Sie, bis die Initialisierung abgeschlossen ist. Dieser Vorgang kann bis zu 30 bis 60 Minuten dauern.

  4. Führen Sie den folgenden Befehl auf dem Seedknoten aus, und warten Sie, bis die Appliance fehlerfrei ist:

    Get-ApplianceHealthState

  5. Führen Sie Invoke-AzStackHciArcInitialization auf jedem Knoten erneut aus.

Vorerstellung des Azure Key Vault

Erstellen Sie die Azure Key Vault, bevor Sie Azure Local bereitstellen, um lange Bereitstellungsverzögerungen zu vermeiden, die durch ein bekanntes Problem verursacht werden.

Ein Codebeispiel finden Sie unter "Bekannte Probleme".

Nachdem Sie die Key Vault erstellt haben, warten Sie 5 Minuten, bevor Sie mit dem nächsten Bereitstellungsschritt des Portals fortfahren.

Bereitstellen des Verwaltungsclusters (erste Azure Local Instanz)

Mit der bereitgestellten und konfigurierten Steuerebene können Sie den Management-Cluster abschließen, indem Sie Azure Local mithilfe der lokalen Steuerebene bereitstellen.

Führen Sie die folgenden Schritte aus, um eine Azure Local Instanz (Cluster) zu erstellen:

  1. Greifen Sie über einen Browser Ihrer Wahl auf das lokale Portal zu.
  2. Navigiere zu portal.FQDN. Beispiel: https://portal.autonomous.cloud.private.
  3. Wählen Sie Ihre Knoten aus, und führen Sie die bereitstellungsschritte aus, die in Deploy Azure Local using the Azure portal beschrieben sind.

Hinweis

Wenn Sie Azure Key Vault während der Bereitstellung erstellen, warten Sie ca. 5 Minuten, bis RBAC-Berechtigungen wirksam werden.

Wenn ein Überprüfungsfehler angezeigt wird, ist es ein bekanntes Problem. Berechtigungen werden möglicherweise immer noch weitergegeben. Warten Sie ein bisschen, aktualisieren Sie Ihren Browser, und stellen Sie den Cluster erneut bereit.

Aufgaben nach der Bereitstellung getrennter Vorgänge

Führen Sie die folgenden Aufgaben nach der Bereitstellung von Azure Local mit getrennten Vorgängen aus:

  1. Sichern Sie die BitLocker-Schlüssel (überspringen Sie diesen Schritt nicht). Während der Bereitstellung wird die Appliance verschlüsselt. Ohne die Wiederherstellungsschlüssel für die Volumes können Sie die Appliance nicht wiederherstellen und zurücksetzen. Weitere Informationen finden Sie unter Sicherheitskontrollen mit getrennten Operationen auf Azure Local verstehen.
  2. Weisen Sie zusätzliche Operatoren zu. Sie können einen oder mehrere Operatoren zuweisen, indem Sie zu Operatorabonnements navigieren. Weisen Sie die Rolle "Mitwirkender " auf Abonnementebene zu.
  3. Exportieren Sie die Zertifikate des Host-Guardian-Diensts, und sichern Sie den Ordner, in den Sie sie exportieren, auf einer externen Freigabe oder einem Laufwerk.
  4. Registrieren des Verwaltungsclusters
  5. Sperren Sie den Verwaltungscluster. Verhindern Sie, dass Operatoren Arbeitslasten auf dem Verwaltungscluster bereitstellen. Beschränken Sie den Operatorzugriff auf eine ausgewählte Gruppe und erzwingen Sie diese Einschränkung mithilfe von Azure Policy, um Arbeitslasten auf der Clusterressource zu blockieren.
  6. Bereinigen von Datenträgern. Wenn Während des Bootstrap-Prozesses Datenträger verwendet wurden, stellen Sie sicher, dass sie entfernt werden.

Hinweis

Überspringen Sie diese Schritte nicht. Betrachten Sie dies als Prüfliste für den Abschluss der Bereitstellung. Diese Schritte sind wichtig, um im Falle von Katastrophen wiederherstellen zu können, Support zu erhalten und konform zu bleiben.

Bereitstellen von Workloadclustern

Führen Sie zum Bereitstellen von Standardmäßigen Azure Local Instanzen als Workloadcluster die gleichen Schritte aus, die für den Verwaltungscluster verwendet werden.

Bereitstellen eines Rack-bewussten Clusters

Ab der Version 2604 können Sie einen rackfähigen Azure Local-Cluster im getrennten Betrieb von Azure Local bereitstellen.

Für die Bereitstellung eines rackbewussten Clusters für den getrennten Betrieb in Azure Local ist ein Dateifreigabe-Zeuge erforderlich. Die Dateifreigabe muss eine lokale Dateifreigabe sein und auf einem Windows Server gehostet werden, der derselben Active Directory-Gesamtstruktur wie der Cluster angehört.

Bevor Sie die Bereitstellung starten, erfüllen Sie die folgenden Voraussetzungen:

Verwenden Sie zum Bereitstellen eines rackbewussten Clusters die folgende ARM-Vorlage: create-cluster-rac-enabled-disconnected. 

Ein Beispiel, das das Format verschiedener Eingaben wie ArcNodeResourceID zeigt, finden Sie in der JSON-Parameterdatei azuredeploy.parameters.json. Eine detaillierte Beschreibung der parameter, die in diesen Dateien definiert sind, finden Sie in der Referenz zu ARM-Vorlagenparametern. 

Von Bedeutung

  • Stellen Sie sicher, dass alle Parameter in der JSON-Datei ausgefüllt sind.
  • Ersetzen Sie alle Platzhalterwerte wie [""] durch tatsächliche Daten. Diese Platzhalter geben an, dass der Parameter eine Arraystruktur erwartet.  
  • Wenn erforderliche Werte fehlen oder falsch formatiert sind, schlägt die Überprüfung fehl.

Beispiel für eine rackbewusste Clusterkonfiguration

Im folgenden Beispiel wird ein Rack-aware-Cluster mit vier Knoten und je zwei Knoten pro Rack bereitgestellt:

  • Knoten1 und Knoten2 befinden sich physisch im selben Rack (Zone1). 

  • node3 und node4 befinden sich in einem anderen Rack (Zone2).  

Konfigurieren Sie neben allen Standardbereitstellungsparametern die folgenden Parameter für die Rack-Aware-Bereitstellung.

Ressourcen-IDs von Arc-Knoten

"arcNodeResourceIds": {
"value": [
"/subscriptions/<SubscriptionID>/resourceGroups/<ResourceGroupName>/providers/Microsoft.HybridCompute/machines/node1",
"/subscriptions/<SubscriptionID>/resourceGroups/<ResourceGroupName>/providers/Microsoft.HybridCompute/machines/node2",
"/subscriptions/<SubscriptionID>/resourceGroups/<ResourceGroupName>/providers/Microsoft.HybridCompute/machines/node3",
"/subscriptions/<SubscriptionID>/resourceGroups/<ResourceGroupName>/providers/Microsoft.HybridCompute/machines/node4"
]
}

Clustermuster und lokale Verfügbarkeitszonen

Legen Sie clusterPattern auf RackAware fest und definieren Sie für jedes Rack eine lokale Verfügbarkeitszone. Weisen Sie Zonen basierend auf ihrer physischen Rackposition Knoten zu. In diesem Beispiel befinden sich Knoten1 und Knoten2 in Zone1, während sich Knoten3 und Knoten4 in Zone2 befinden.

"clusterPattern": {
"value": "RackAware"
},
"localAvailabilityZones": {
    "value": [
    {
        "localAvailabilityZoneName": "Zone1",
        "nodes": ["node1","node2"]  
    },
    {
        "localAvailabilityZoneName": "Zone2",
        "nodes": ["node3","node4"]
    }
    ]
}

Dateifreigabenzeuge

Ein rackfähiger Cluster in Azure Local erfordert für den Betrieb mit getrennter Verbindung einen Dateifreigabezeugen. Legen Sie witnessType auf FileShare fest, und geben Sie den UNC-Pfad zur Dateifreigabe an.

"witnessType": {
    "value": "FileShare"
},
"witnessPath": {
    "value": "witness_share_path"
}

Netzwerkabsichtskonfiguration

Bei Rack-fähigen Clustern muss die Absicht des Speichernetzwerks eine dedizierte Absicht sein, die vom Verwaltungs- und Computedatenverkehr getrennt ist. Definieren Sie zwei Netzwerkziele:

  • ManagementCompute – behandelt die Verwaltung und den Computedatenverkehr auf gemeinsam genutzten Adaptern.
  • Speicher – verarbeitet Speicherdatenverkehr auf dedizierten Adaptern.

Konfigurieren Sie die Speicher-VLAN-IDs für jeden Speicheradapter. Die standardmäßigen VLAN-IDs (711 und 712) können für Ihre Umgebung angepasst werden.

"networkingType": {
    "value": "switchedMultiserverDeployment"
},
"networkingPattern": {
    "value" : "convergedManagementCompute"
},
"intentList" : {
    "value": [
        {
            "name": "ManagementCompute",
            "trafficType": [
                "Management",
                "Compute"
            ],
            "adapter": [
                "ethernet",
                "ethernet 2"
            ],
            "overridevirtualswitchConfiguration": false,
            "virtualswitchConfigurationoverrides": {
                "enableIov": "",
                "loadBalancingAlgorithm": ""
            },
            "overrideQosPolicy": false,
            "qosPolicyoverrides": {
                "priorityvalue8021Action_SMB": "",
                "priorityvalues8021Action_Cluster": "",
                "bandwidthPercentage_SMB": ""
            },
            "overrideAdapterProperty": false,
            "adapterPropertyoverrides": {
                "jumboPacket": "",
                "networkDirect": "",
                "networkDirectTechnology": ""
            }
        },
        {
            "name": "Storage",
            "trafficType": [
                    "Storage"
            ],
            "adapter": [
                "ethernet 3",
                "ethernet 4"
            ],
            "overridevirtualswitchConfiguration": false,
            "virtualswitchConfigurationoverrides": {
                "enableIov": "",
                "loadBalancingAlgorithm": ""
            },
            "overrideQosPolicy": false,
            "qosPolicyoverrides": {
                "priorityvalue8021Action_SMB": "",
                "priorityvalues8021Action_Cluster": "",
                "bandwidthPercentage_SMB": ""
            },
            "overrideAdapterProperty": false,
            "adapterPropertyoverrides": {
                "jumboPacket": "",
                "networkDirect": "",
                "networkDirectTechnology": ""
            }
      }
    ]
},
"storageNetworkList": {
    "value": [
        {
            "name": "Storage1Network",
            "networkAdapterName": "ethernet 3",
            "vlanId": "711"
        },
        {
            "name": "Storage2Network",
            "networkAdapterName": "ethernet 4",
            "vlanId": "712"
        }
    ]
}

Anhang

Sperrung des Verwaltungsclusters

$operatorSubscriptionId = 'a1b2c3d4-e5f6-7890-abcd-ef1234567890'
$resourceGroup = 'azurelocal-management-cluster'
$managementClusterLocationName = 'managementcluster-location'
$customLocationId = "/subscriptions/$($operatorSubscriptionId)/resourceGroups/$($resourceGroup)/providers/Microsoft.ExtendedLocation/customLocations/$($managementClusterLocationName)"
Import-Module "$applianceConfigBasePath\OperationsModule\AzureLocal.Orchestration.psm1" 
Set-ManagementClusterLock `
        -Enabled $true `
        -SubscriptionId $operatorSubscriptionId `
        -MgmtClusterCustomLocationId $customLocationId

Bereinigen von Datenträgern, die für Bootstrap verwendet werden

# ===============================
# Remove CSV and Return Space to Pool
# ===============================

$CsvName="Cluster Virtual Disk (InfraLocal_1)"
$VirtualDiskName ="InfraLocal_1"

Write-Host "Starting CSV removal process..." -ForegroundColor Cyan

# --- Validate CSV exists ---
$csv = Get-ClusterSharedVolume -Name $CsvName -ErrorAction Stop
Write-Host "Found CSV: $($csv.Name)"

# --- Remove CSV ---
$csv = remove-ClusterSharedVolume -Name $CsvName -ErrorAction Stop
Write-Host "Removed CSV: $($csv.Name)"

# --- Take Cluster Resources offline ---
Write-Host "Taking CSV resource offline..." -ForegroundColor Yellow
Stop-ClusterResource -Name $csv.name -Wait 120

# --- Remove Cluster Resources offline ---
Write-Host "Taking CSV resource offline..." -ForegroundColor Yellow
remove-ClusterResource -Name $csv.name

# --- Remove virtual disk and return space to pool ---
Write-Host "Remoing virtual disk..." -ForegroundColor Yellow
remove-virtualdisk -FriendlyName $VirtualDiskName

Problembehandlung und Neukonfiguration mithilfe des Verwaltungsendpunkts

Um den Verwaltungsendpunkt für die Problembehandlung und Neukonfiguration zu verwenden, benötigen Sie die während der Bereitstellung verwendete Verwaltungs-IP-Adresse sowie das Clientzertifikat und das Zum Sichern des Endpunkts verwendete Kennwort.

Importieren Sie von einem Client mit Netzwerkzugriff auf den Verwaltungsendpunkt das OperationsModule-Element , und legen Sie den Kontext fest (ändern Sie das Skript entsprechend Ihrer Konfiguration):

Import-Module "$applianceConfigBasePath\OperationsModule\Azure.Local.DisconnectedOperations.psd1" -Force

$password = ConvertTo-SecureString 'RETRACTED' -AsPlainText -Force  
$context = Set-DisconnectedOperationsClientContext -ManagementEndpointClientCertificatePath "${env:localappdata}\AzureLocalOpModuleDev\certs\ManagementEndpoint\ManagementEndpointClientAuth.pfx" -ManagementEndpointClientCertificatePassword $password -ManagementEndpointIpAddress "169.254.53.25"

Nach dem Festlegen des Kontexts können Sie alle vom Operations-Modul bereitgestellten Verwaltungs-Cmdlets verwenden, z. B. das Zurücksetzen der Identitätskonfiguration, das Überprüfen des Integritätszustands und vieles mehr.

Verwenden Sie die PowerShell Get-Command -Module OperationsModule, um eine vollständige Liste der bereitgestellten Cmdlets zu erhalten. Verwenden Sie den Get-Help <cmdletname> Befehl, um Details zu den einzelnen Cmdlets abzurufen.

Problembehandlung bei Bereitstellungen

System nicht konfiguriert

Nach der Installation der Appliance wird dieser Bildschirm möglicherweise eine Weile angezeigt. Lassen Sie die Konfiguration für 2 bis 3 Stunden ausgeführt werden. Nachdem Sie die 2 bis 3 Stunden gewartet haben, wird der Bildschirm ausgeblendet, und das normale Azure Portal wird angezeigt. Wenn der Bildschirm nicht mehr angezeigt wird und Sie nicht auf das lokale Azure Portal zugreifen können, beheben Sie das Problem.

Screenshot der Seite, die anzeigt, dass das System nicht konfiguriert ist.

  • Um Protokolle aus dem OperationsModule auf dem ersten Computer zu suchen, wechseln Sie zu C:\ProgramData\Microsoft\AzureLocalDisconnectedOperations\Logs.

  • Verwenden Sie das Cmdlet "VerwaltungsendpunktGet-ApplianceHealthState", um den Gesundheitszustand Ihrer Appliance anzuzeigen. Wenn dieser Bildschirm angezeigt wird und das Cmdlet keine Fehler meldet, und alle Dienste melden 100, öffnen Sie ein Supportticket aus dem Azure-Portal.

Install-Appliance schlägt fehl

Aktualisieren Sie die Appliance-Konfiguration, und führen Sie die Installation nach einem Fehler erneut aus.

Beispiel:

  • Wenn die IP-Adresse bereits verwendet wird, ändern Sie das Konfigurationsobjekt.

    Hier ist ein Beispiel zum Ändern der eingehenden IP-Adresse

    # Set a new IP address
$ingressNetworkConfiguration.IngressIpAddress = '192.168.0.115'

  • Wenn während der Installation install-appliance ein Fehler auftritt, aktualisieren Sie $installAzureLocalParams und führen Install-appliance erneut aus, wie in "Installieren und Konfigurieren der Appliance" beschrieben.

  • Wenn die Appliance-Bereitstellung erfolgreich war und Sie die Netzwerkkonfiguration aktualisieren möchten, finden Sie unter Get-Help Set-Appliance Informationen zu den Einstellungen, die Sie nach der Bereitstellung aktualisieren können.

Nächste Schritte

Dieses Feature ist nur in Azure Local 2602 oder höher verfügbar.

  • Last updated on