Share via


SharePoint-Intranetfarm in Azure, Phase 3: Konfigurieren der SQL Server-Infrastruktur

 

**Gilt für:**SharePoint Server 2016

**Letztes Änderungsdatum des Themas:**2017-09-20

Zusammenfassung: In diesem Artikel erfahren Sie, wie Sie die SQL Server-Infrastruktur konfigurieren, die eine SharePoint Server 2016-Farm mit hoher Verfügbarkeit in Microsoft Azure hosten soll.

In dieser Phase der Bereitstellung einer nur im Intranet verfügbaren SharePoint Server 2016-Farm in den Azure-Infrastrukturdiensten erstellen und konfigurieren Sie die beiden virtuellen SQL Server-Computer und den Computer, der als Clustermehrheitsknoten fungiert. Anschließend fassen Sie diese Computer in einem Windows Server-Cluster zusammen.

Sie müssen diese Phase abschließen, bevor Sie mit SharePoint-Intranetfarm in Azure, Phase 4: Konfigurieren von SharePoint-Servern fortfahren können. Eine Übersicht über alle Phasen finden Sie unter Bereitstellen von SQL Server AlwaysOn-Verfügbarkeitsgruppen für SharePoint Server 2016 in Azure.

Hinweis

In dieser Anleitung verwenden Sie ein SQL Server-Image aus der Azure-Image-Galerie, und es fallen laufende Kosten für die Verwendung der SQL Server-Lizenz an. Es ist auch möglich, virtuelle Computer in Azure zu erstellen und Ihre eigenen SQL Server-Lizenzen zu installieren. Sie benötigen jedoch Software Assurance und Lizenzmobilität, um eigene SQL Server-Lizenzen in einem virtuellen Computer verwenden zu können. Das gilt auch für virtuelle Computer in Azure.

Erstellen der Azure-VMs für den SQL Server-Cluster

Es werden zwei virtuelle SQL Server-Computer implementiert. Einer enthält das primäre Datenbankreplikat einer Verfügbarkeitsgruppe. Der zweite enthält das sekundäre Sicherungsreplikat. Die Sicherung gewährleistet hohe Verfügbarkeit. Ein weiterer virtueller Computer wird als Clustermehrheitsknoten implementiert.

Verwenden Sie die nachfolgend aufgeführten PowerShell-Befehlsblöcke, um die Komponenten in Azure zu erstellen. Geben Sie dabei die Werte für die Variablen an, und entfernen Sie die „<“- und die „>“-Zeichen. Diese PowerShell-Befehlsblöcke verwenden Werte aus den folgenden Tabellen:

  • Tabelle R (für die Ressourcengruppen)

  • Tabelle V (für die Einstellungen des virtuellen Netzwerks)

  • Tabelle S (für das Subnetz)

  • Tabelle I (für die statischen IP-Adressen)

  • Tabelle M (für die virtuellen Computer)

  • Tabelle A (für die Verfügbarkeitsgruppen)

Tabelle M haben Sie in SharePoint-Intranetfarm in Azure, Phase 2: Konfigurieren von Domänencontrollern ausgefüllt, die Tabellen R, V, S, I und A in SharePoint-Intranetfarm in Azure, Phase 1: Konfigurieren von Azure.

Hinweis

In den folgenden Befehlssätzen wird die aktuelle Version von Azure PowerShell verwendet. Informationen dazu finden Sie unter Get started with Azure PowerShell cmdlets.

Zuerst erstellen Sie in Azure einen internen Load Balancer für die beiden SQL Server-VMs. Sobald Sie alle Werte korrekt festgelegt haben, führen Sie den resultierenden Block über die Azure PowerShell-Eingabeaufforderung oder in PowerShell Integrated Script Environment (ISE) auf Ihrem lokalen Computer aus.

Tipp

Eine Textdatei, die alle in diesem Artikel beschriebenen PowerShell-Befehle enthält, und eine Microsoft Excel-Konfigurationsarbeitsmappe, die basierend auf Ihren benutzerdefinierten Einstellungen ausführbereite PowerShell-Befehlsblöcke generiert, finden Sie im SharePoint Server 2016 High Availability Farm in Azure Deployment Kit.

# Set up key variables
$locName="<Azure location of your SharePoint farm>"
$vnetName="<Table V - Item 1 - Value column>"
$subnetName="<Table S - Item 2 - Subnet name column>"
$privIP="<Table I - Item 4 - Value column>"
$rgName="<Table R - Item 5 - Resource group name column>"

$vnet=Get-AzureRMVirtualNetwork -Name $vnetName -ResourceGroupName $rgName
$subnet=Get-AzureRmVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name $subnetName

$frontendIP=New-AzureRMLoadBalancerFrontendIpConfig -Name "SQLServers-LBFE" -PrivateIPAddress $privIP -Subnet $subnet
$beAddressPool=New-AzureRMLoadBalancerBackendAddressPoolConfig -Name "SQLServers-LBBE"

$healthProbe=New-AzureRMLoadBalancerProbeConfig -Name WebServersProbe -Protocol "TCP" -Port 59999 -IntervalInSeconds 5 -ProbeCount 2
$lbrule=New-AzureRMLoadBalancerRuleConfig -Name "SQLTraffic" -FrontendIpConfiguration $frontendIP -BackendAddressPool $beAddressPool -Probe $healthProbe -Protocol "TCP" -FrontendPort 1433 -BackendPort 1433 -EnableFloatingIP
New-AzureRMLoadBalancer -ResourceGroupName $rgName -Name "SQLServers" -Location $locName -LoadBalancingRule $lbrule -BackendAddressPool $beAddressPool -Probe $healthProbe -FrontendIpConfiguration $frontendIP

Nun fügen Sie der internen DNS-Infrastruktur Ihrer Organisation einen DNS-Adresseintrag hinzu, der den vollqualifizierten Domänennamen des SQL-Clusters (z. B. „sqlcluster.corp.contoso.com“) auflöst und in die dem internen Load Balancer zugewiesene IP-Adresse übersetzt (Wert aus Tabelle I, Element 4).

Im nächsten Schritt erstellen Sie die virtuellen Computer des SQL Server-Clusters.

Hinweis

Für die SQL Server-VMs werden SQL Server 2016-Images verwendet, die sich nicht zusammen mit Workflow Manager verwenden lassen. Wenn Sie Workflow Manager benötigen, müssen Sie SQL Server 2014 verwenden. Festlegen können Sie das, indem Sie die Variable $sqlSKU in dem folgenden Azure PowerShell-Befehlsblock auf SQL2014SP2-WS2012R2 setzen.

Sobald Sie alle Werte korrekt festgelegt haben, führen Sie den resultierenden Block über die Azure PowerShell-Eingabeaufforderung oder in PowerShell ISE auf Ihrem lokalen Computer aus.

# Set up variables common to all three virtual machines
$locName="<Azure location of your SharePoint farm>"
$vnetName="<Table V - Item 1 - Value column>"
$subnetName="<Table S - Item 2 - Subnet name column>"
$avName="<Table A - Item 2 - Availability set name column>"
$rgNameTier="<Table R - Item 2 - Resource group name column>"
$rgNameInfra="<Table R - Item 5 - Resource group name column>"
$sqlSKU="SQL2016-WS2016"

$rgName=$rgNameInfra
$vnet=Get-AzureRMVirtualNetwork -Name $vnetName -ResourceGroupName $rgName
$subnet=Get-AzureRmVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name $subnetName
$backendSubnet=Get-AzureRMVirtualNetworkSubnetConfig -Name $subnetName -VirtualNetwork $vnet
$webLB=Get-AzureRMLoadBalancer -ResourceGroupName $rgName -Name "SQLServers"

$rgName=$rgNameTier
$avSet=Get-AzureRMAvailabilitySet -Name $avName -ResourceGroupName $rgName

# Create the first SQL Server virtual machine
$vmName="<Table M - Item 3 - Virtual machine name column>"
$vmSize="<Table M - Item 3 - Minimum size column>"
$staticIP="<Table I - Item 5 - Value column>"
$diskStorageType="<Table M - Item 3 - Storage type column>"

$nic=New-AzureRMNetworkInterface -Name ($vmName +"-NIC") -ResourceGroupName $rgName -Location $locName -Subnet $backendSubnet -LoadBalancerBackendAddressPool $webLB.BackendAddressPools[0] -PrivateIpAddress $staticIP
$vm=New-AzureRMVMConfig -VMName $vmName -VMSize $vmSize -AvailabilitySetId $avset.Id
$vm=Set-AzureRmVMOSDisk -VM $vm -Name ($vmName +"-OS") -DiskSizeInGB 128 -CreateOption FromImage -StorageAccountType $diskStorageType
$diskSize=1000
$diskConfig=New-AzureRmDiskConfig -AccountType $diskStorageType -Location $locName -CreateOption Empty -DiskSizeGB $diskSize
$dataDisk1=New-AzureRmDisk -DiskName ($vmName + "-SQLData") -Disk $diskConfig -ResourceGroupName $rgName
$vm=Add-AzureRmVMDataDisk -VM $vm -Name ($vmName + "-SQLData") -CreateOption Attach -ManagedDiskId $dataDisk1.Id -Lun 1
$diskSize=1000
$diskConfig=New-AzureRmDiskConfig -AccountType $diskStorageType -Location $locName -CreateOption Empty -DiskSizeGB $diskSize
$dataDisk1=New-AzureRmDisk -DiskName ($vmName + "-SQLLogs") -Disk $diskConfig -ResourceGroupName $rgName
$vm=Add-AzureRmVMDataDisk -VM $vm -Name ($vmName + "-SQLLogs") -CreateOption Attach -ManagedDiskId $dataDisk1.Id -Lun 2
$diskSize=1000
$diskConfig=New-AzureRmDiskConfig -AccountType $diskStorageType -Location $locName -CreateOption Empty -DiskSizeGB $diskSize
$dataDisk1=New-AzureRmDisk -DiskName ($vmName + "-SQLTemp") -Disk $diskConfig -ResourceGroupName $rgName
$vm=Add-AzureRmVMDataDisk -VM $vm -Name ($vmName + "-SQLTemp") -CreateOption Attach -ManagedDiskId $dataDisk1.Id -Lun 3
$cred=Get-Credential -Message "Type the name and password of the local administrator account for the first SQL Server computer." 
$vm=Set-AzureRMVMOperatingSystem -VM $vm -Windows -ComputerName $vmName -Credential $cred -ProvisionVMAgent -EnableAutoUpdate
$vm=Set-AzureRMVMSourceImage -VM $vm -PublisherName MicrosoftSQLServer -Offer $sqlSKU -Skus Enterprise -Version "latest"
$vm=Add-AzureRMVMNetworkInterface -VM $vm -Id $nic.Id
New-AzureRMVM -ResourceGroupName $rgName -Location $locName -VM $vm

# Create the second SQL Server virtual machine
$vmName="<Table M - Item 4 - Virtual machine name column>"
$vmSize="<Table M - Item 4 - Minimum size column>"
$staticIP="<Table I - Item 6 - Value column>"
$diskStorageType="<Table M - Item 4 - Storage type column>"

$nic=New-AzureRMNetworkInterface -Name ($vmName +"-NIC") -ResourceGroupName $rgName -Location $locName  -Subnet $backendSubnet -LoadBalancerBackendAddressPool $webLB.BackendAddressPools[0] -PrivateIpAddress $staticIP
$vm=New-AzureRMVMConfig -VMName $vmName -VMSize $vmSize -AvailabilitySetId $avset.Id
$vm=Set-AzureRmVMOSDisk -VM $vm -Name ($vmName +"-OS") -DiskSizeInGB 128 -CreateOption FromImage -StorageAccountType $diskStorageType
$diskSize=1000
$diskConfig=New-AzureRmDiskConfig -AccountType $diskStorageType -Location $locName -CreateOption Empty -DiskSizeGB $diskSize
$dataDisk1=New-AzureRmDisk -DiskName ($vmName + "-SQLData") -Disk $diskConfig -ResourceGroupName $rgName
$vm=Add-AzureRmVMDataDisk -VM $vm -Name ($vmName + "-SQLData") -CreateOption Attach -ManagedDiskId $dataDisk1.Id -Lun 1
$diskSize=1000
$diskConfig=New-AzureRmDiskConfig -AccountType $diskStorageType -Location $locName -CreateOption Empty -DiskSizeGB $diskSize
$dataDisk1=New-AzureRmDisk -DiskName ($vmName + "-SQLLogs") -Disk $diskConfig -ResourceGroupName $rgName
$vm=Add-AzureRmVMDataDisk -VM $vm -Name ($vmName + "-SQLLogs") -CreateOption Attach -ManagedDiskId $dataDisk1.Id -Lun 2
$diskSize=1000
$diskConfig=New-AzureRmDiskConfig -AccountType $diskStorageType -Location $locName -CreateOption Empty -DiskSizeGB $diskSize
$dataDisk1=New-AzureRmDisk -DiskName ($vmName + "-SQLTemp") -Disk $diskConfig -ResourceGroupName $rgName
$vm=Add-AzureRmVMDataDisk -VM $vm -Name ($vmName + "-SQLTemp") -CreateOption Attach -ManagedDiskId $dataDisk1.Id -Lun 3
$cred=Get-Credential -Message "Type the name and password of the local administrator account for the second SQL Server computer." 
$vm=Set-AzureRMVMOperatingSystem -VM $vm -Windows -ComputerName $vmName -Credential $cred -ProvisionVMAgent -EnableAutoUpdate
$vm=Set-AzureRMVMSourceImage -VM $vm -PublisherName MicrosoftSQLServer -Offer $sqlSKU -Skus Enterprise -Version "latest"
$vm=Add-AzureRMVMNetworkInterface -VM $vm -Id $nic.Id
New-AzureRMVM -ResourceGroupName $rgName -Location $locName -VM $vm

# Create the cluster majority node server
#  Note that this virtual machine is not needed if you are using a cloud witness.
$vmName="<Table M - Item 5 - Virtual machine name column>"
$vmSize="<Table M - Item 5 - Minimum size column>"
$staticIP="<Table I - Item 7 - Value column>"
$diskStorageType="<Table M - Item 5 - Storage type column>"

$nic=New-AzureRMNetworkInterface -Name ($vmName +"-NIC") -ResourceGroupName $rgName -Location $locName -Subnet $subnet -PrivateIpAddress $staticIP
$vm=New-AzureRMVMConfig -VMName $vmName -VMSize $vmSize -AvailabilitySetId $avset.Id
$vm=Set-AzureRmVMOSDisk -VM $vm -Name ($vmName +"-OS") -DiskSizeInGB 128 -CreateOption FromImage -StorageAccountType $diskStorageType
$cred=Get-Credential -Message "Type the name and password of the local administrator account for the cluster majority node server." 
$vm=Set-AzureRMVMOperatingSystem -VM $vm -Windows -ComputerName $vmName -Credential $cred -ProvisionVMAgent -EnableAutoUpdate
$vm=Set-AzureRMVMSourceImage -VM $vm -PublisherName MicrosoftWindowsServer -Offer WindowsServer -Skus 2016-Datacenter -Version "latest"
$vm=Add-AzureRMVMNetworkInterface -VM $vm -Id $nic.Id
New-AzureRMVM -ResourceGroupName $rgName -Location $locName -VM $vm

Hinweis

Da diese virtuellen Computer für eine Intranetanwendung gedacht sind, wird ihnen weder eine öffentliche IP-Adresse noch eine DNS-Domänennamenbezeichnung zugewiesen. Sie sind also nicht über das Internet erreichbar. Das bedeutet allerdings, dass Sie auch nicht über das Azure-Portal auf sie zugreifen können. Wenn Sie die Eigenschaften eines der virtuellen Computer aufrufen, ist die Option zum Verbinden nicht verfügbar. Verwenden Sie eine Remotedesktopverbindung oder ein anderes Remotedesktoptool, um eine Verbindung über die private IP-Adresse des betreffenden virtuellen Computers oder seinen Intranet-DNS-Namen herzustellen.

Konfigurieren der SQL Server-Computer

Erstellen Sie mithilfe eines Remotedesktopclients Ihrer Wahl eine Remotedesktopverbindung für jede SQL Server-VM. Verwenden Sie den Intranet-DNS-Namen oder den Computernamen des jeweiligen Servers und die Anmeldeinformationen des lokalen Administratorkontos.

Führen Sie für jede der SQL Server-VMs die folgenden Befehle über die Windows PowerShell-Eingabeaufforderung aus, um jeweils einen Domänenbeitritt zur gewünschten Windows Server AD-Domäne einzurichten.

$domName="<Windows Server AD domain name to join, such as corp.contoso.com>"
Add-Computer -DomainName $domName
Restart-Computer

Beachten Sie: Nach der Ausführung des Befehls Add-Computer müssen Sie die Anmeldeinformationen des Domänenkontos eingeben.

Stellen Sie nach dem VM-Neustart erneut eine Verbindung mit den VMs her. Verwenden Sie dazu das lokale Administratorkonto.

Im nächsten Schritt müssen Sie zusätzliche Datenträger hinzufügen. Führen Sie auf jedem SQL Server-Computer die folgenden Befehle über eine Windows PowerShell-Eingabeaufforderung aus:

$newDisks=Get-Disk | Where Partitionstyle -eq "RAW"
ForEach ($d in $newDisks) {
$diskNum=$d.Number - 1
Get-Disk $d.Number | Initialize-Disk -PartitionStyle GPT -PassThru | New-Partition -AssignDriveLetter -UseMaximumSize | Format-Volume -FileSystem NTFS -NewFileSystemLabel "DataDisk$diskNum"
}
md f:\Data
md g:\Log
md h:\Backup

Im nächsten Schritt führen Sie auf jedem SQL Server-Computer mithilfe des Befehls ping einen Ping an die Namen und IP-Adressen von Ressourcen innerhalb des Netzwerks Ihrer Organisation durch. So können Sie testen, ob alle SQL Server-Computer eine Verbindung zu Standorten im Netzwerk Ihrer Organisation herstellen können. Gleichzeitig stellen Sie damit sicher, dass die DNS-Namensauflösung korrekt funktioniert (d. h., dass die einzelnen virtuellen Computern jeweils korrekt mit den DNS-Servern im virtuellen Netzwerk konfiguriert sind) und dass Pakete sowohl an das standortübergreifende Netzwerk als auch aus ihm gesendet werden können.

Führen Sie den folgenden PowerShell-Befehlsblock zweimal aus (einmal für jeden SQL-Server), damit die SQL-Server die zusätzlichen Datenträger für neue Datenbanken sowie für Konten und Berechtigungen verwenden:

$domain = "<your Windows Server AD domain name, such as CORP for corp.contoso.com>"
$spFarmDBAcctName=$domain +"\sp_farm_db"
$spFarmInstallAcctName=$domain +"\sp_install"
Import-Module -Name 'SQLPS' -DisableNameChecking
$svr = new-object('Microsoft.SqlServer.Management.Smo.Server')localhost
$svr.properties["DefaultFile"].Value="f:\data"
$svr.properties["DefaultLog"].Value="g:\log"
$svr.properties["BackupDirectory"].Value = "H:\Backup"
$svr.alter()
$login = New-Object('Microsoft.SqlServer.Management.Smo.Login') -ArgumentList $svr, $spFarmDBAcctName
$login.LoginType = "WindowsUser"
$Login.Create()
$login.AddToRole("sysadmin")
$login.Alter()
$login = New-Object('Microsoft.SqlServer.Management.Smo.Login') -ArgumentList $svr, $spFarmInstallAcctName
$login.LoginType = "WindowsUser"
$Login.Create()
$login.AddToRole("securityadmin")
$login.AddToRole("dbcreator")
$login.Alter()
$maxdop=$svr.Configuration.Properties| where displayname -Match 'degree'
$maxdop.ConfigValue = 1
$svr.Alter()

Melden Sie sich von jedem virtuellen SQL Server-Computer ab, und stellen Sie dann über das sp_install-Konto eine Verbindung dazu her.

Öffnen Sie auf jedem virtuellen SQL Server-Computer eine Windows PowerShell-Eingabeaufforderung auf Administratorebene, und führen Sie den folgenden PowerShell-Befehlsblock aus, um Remotedesktopverbindungen unter Verwendung des sp_farm_db-Kontos zuzulassen:

$domain = "<your Windows Server AD domain name, such as CORP for corp.contoso.com>"
$server="<name of the server>"
$user = "sp_farm_db"
$group = "Remote Desktop Users"
$de = [ADSI]"WinNT://$server/$group,group" 
$de.psbase.Invoke("Add",([ADSI]"WinNT://$domain/$user").path)

SQL Server benötigt einen Port, den Clients für den Zugriff auf den Datenbankserver verwenden. Daneben benötigt die Anwendung Ports für die Verbindung zu SQL Server Management Studio sowie zur Verwaltung der Hochverfügbarkeitsgruppe. Zusätzlich ist ein weiterer nicht genutzter Port erforderlich, über den der Verfügbarkeitsgruppenlistener Load Balancer-Tests durchführt.

Führen Sie im nächsten Schritt den folgenden Befehl zweimal (einmal für jeden SQL-Server) über eine Windows PowerShell-Eingabeaufforderung aus, um eine Firewallregel hinzuzufügen, die diese Typen von eingehendem Datenverkehr auf dem SQL-Server zulässt:

New-NetFirewallRule -DisplayName "SQL Server ports 1433, 1434, and 5022, and 59999" -Direction Inbound -Protocol TCP -LocalPort 1433,1434,5022,59999 -Action Allow 

Melden Sie sich von allen SQL Server-VMs als lokaler Administrator ab.

Weitere Informationen zur Optimierung der SQL Server-Leistung in Azure finden Sie unter Bewährte Methoden zur Leistung für SQL Server auf virtuellen Azure-Computern.

Konfigurieren des als Clustermehrheitsknoten fungierenden Servers

Erstellen Sie mithilfe eines Remotedesktopclients Ihrer Wahl eine Remotedesktopverbindung zu dem Server, der als Clustermehrheitsknoten fungiert. Verwenden Sie den Intranet-DNS-Namen oder den Computernamen des Servers und die Anmeldeinformationen des lokalen Administratorkontos.

Hinweis

Dies ist nicht erforderlich, wenn Sie einen Cloudzeugen verwenden.

Richten Sie für den als Clustermehrheitsknoten fungierenden Server mithilfe der folgenden Befehle über die Windows PowerShell-Eingabeaufforderung einen Domänenbeitritt zur gewünschten Windows Server AD-Domäne ein.

$domName="<Windows Server AD domain name to join, such as corp.contoso.com>"
Add-Computer -DomainName $domName
Restart-Computer

Beachten Sie: Nach der Ausführung des Befehls Add-Computer müssen Sie die Anmeldeinformationen des Domänenkontos eingeben.

Erstellen des Windows Server-Clusters

SQL Server AlwaysOn-Verfügbarkeitsgruppen basieren auf der Windows Server-Funktion WSFC (Windows Server Failover Cluster). Über sie können mehrere Computer als Gruppe an einem Cluster teilnehmen. Wenn ein Computer ausfällt, kann sofort ein anderer Computer übernehmen. Im ersten Schritt müssen Sie daher Failoverclustering auf allen am Cluster teilnehmenden Computern aktivieren. Das sind:

  • Der primäre SQL-Server

  • Der sekundäre SQL-Server

  • Der Clustermehrheitsknoten (falls erforderlich)

Für den Failovercluster werden mindestens drei VMs benötigt. Zwei VMs hosten SQL Server. Die zweite SQL Server-VM ist ein synchrones sekundäres Replikat und verhindert Datenverlust, sollte die primäre VM ausfallen. Auf der dritten VM muss SQL Server nicht gehostet werden. Der Clustermehrheitsknoten stellt ein Quorum im WSFC bereit. Da der WSFC-Cluster seine Integrität auf Basis des Quorums überwacht, muss immer eine Mehrheit der Computer online sein, damit der WSFC-Cluster online ist. Besteht ein Cluster aus nur zwei Computern und ein Computer fällt aus, kann es keine Mehrheit mehr geben. Weitere Informationen finden Sie unter WSFC-Quorummodi und Abstimmungskonfiguration (SQL Server). Alternativ zu einem als Clustermehrheitsknoten fungierenden virtuellen Computer können Sie auch einen Cloudzeugen verwenden.

Führen Sie auf beiden SQL Server-Computern und dem Clustermehrheitsknoten den folgenden Befehl mit Administratorrechten über eine Windows PowerShell-Eingabeaufforderung aus.

Install-WindowsFeature Failover-Clustering -IncludeManagementTools

Da das DHCP-Verhalten in Azure aktuell nicht RFC-konform ist, kann die Erstellung eines WSFC-Clusters fehlschlagen. Details hierzu finden Sie im Abschnitt „WSFC-Clusterverhalten in Azure-Netzwerken“ des Artikels Hohe Verfügbarkeit und Notfallwiederherstellung für SQL Server auf virtuellen Azure-Computern. Es gibt jedoch eine Problemumgehung. Gehen Sie wie folgt vor, um den Cluster zu erstellen.

  1. Stellen Sie mit den Anmeldeinformationen des Kontos „sp_install“ eine Verbindung zur primären SQL Server-VM her.

  2. Klicken Sie auf Start, geben Sie Failover ein, und klicken Sie auf Failovercluster-Manager.

  3. Klicken Sie im linken Bereich mit der rechten Maustaste auf Failovercluster-Manager und dann auf Cluster erstellen.

  4. Klicken Sie auf der Seite Vorbereitung auf Weiter.

  5. Geben Sie auf der Seite Server auswählen den Namen der primären SQL Server-VM ein, und klicken Sie auf Hinzufügen. Klicken Sie dann auf Weiter.

  6. Klicken Sie auf der Seite Überprüfungswarnung auf No, I do not require support from Microsoft for this cluster, and therefore do not want to run the validation tests. When I click Next, continue creating the cluster. Klicken Sie dann auf Weiter.

  7. Geben Sie auf der Seite Zugriffspunkt für die Clusterverwaltung in das Textfeld Clustername den Namen für den Cluster ein, und klicken Sie auf Weiter.

  8. Klicken Sie auf der Seite Bestätigung auf Weiter, um die Clustererstellung zu starten.

  9. Klicken Sie auf der Seite Zusammenfassung auf Fertig stellen.

  10. Klicken Sie im linken Bereich auf den neuen Cluster. Öffnen Sie im Inhaltsbereich im Abschnitt Hauptressourcen des Clusters den Namen des Serverclusters. Für die Ressource IP-Adresse wird der Status Fehlgeschlagen angezeigt. Die Ressource „IP-Adresse“ kann nicht online geschaltet werden, weil dem Cluster dieselbe IP-Adresse zugewiesen ist wie dem Computer selbst. Das Ergebnis ist ein Adressduplikat.

  11. Klicken Sie mit der rechten Maustaste auf die fehlgeschlagene Ressource IP-Adresse. Klicken Sie dann auf Eigenschaften.

  12. Klicken Sie im Dialogfeld IP Address Properties auf Statische IP-Adresse.

  13. Geben Sie eine nicht verwendete IP-Adresse aus dem Subnetzadressraum ein, in dem sich der SQL-Server befindet, und klicken Sie auf OK.

  14. Klicken Sie mit der rechten Maustaste auf die fehlgeschlagene Ressource IP-Adresse. Klicken Sie dann auf Online schalten. Warten Sie, bis beide Ressourcen online sind. Sobald die Ressource „Clustername“ online ist, aktualisiert sie den Domänencontroller mit einem neuen Active Directory (AD)-Computerkonto. Dieses AD-Konto wird später zur Ausführung des Clusterdiensts „Verfügbarkeitsgruppe“ verwendet.

  15. Da das AD-Konto nun erstellt ist, können Sie den Clusternamen offline schalten. Klicken Sie unter Hauptressourcen des Clusters mit der rechten Maustaste auf den Clusternamen und dann auf Take offline.

  16. Klicken Sie zum Entfernen der Cluster-IP-Adresse mit der rechten Maustaste auf IP-Adresse. Klicken Sie dann auf Entfernen und anschließend auf Ja, wenn Sie dazu aufgefordert werden. Die Clusterressource kann nicht mehr online geschaltet werden, da sie von der Ressource „IP-Adresse“ abhängt. Die ordnungsgemäße Funktion einer Verfügbarkeitsgruppe hängt jedoch weder vom Clusternamen noch von der IP-Adresse ab. Daher kann der Clustername offline bleiben.

  17. Klicken Sie im linken Bereich mit der rechten Maustaste auf den Clusternamen und anschließend auf Knoten hinzufügen, um dem Cluster die übrigen Knoten hinzuzufügen.

  18. Klicken Sie auf der Seite Vorbereitung auf Weiter.

  19. Geben Sie auf der Seite Server auswählen den Namen ein, und klicken Sie auf Hinzufügen, um dem Cluster den sekundären SQL-Server und den Clustermehrheitsknoten hinzuzufügen. Der Mehrheitsknoten wird nicht benötigt, wenn Sie einen Cloudzeugen verwenden.

  20. Klicken Sie auf Weiter, nachdem Sie die Computer hinzugefügt haben. Falls ein Computer nicht hinzugefügt werden kann und die Fehlermeldung „the Remote Registry is not running“ angezeigt wird, gehen Sie wie folgt vor: Melden Sie sich bei dem Computer an, öffnen Sie das Snap-In „Dienste“ (services.msc), und aktivieren Sie die Remoteregistrierung. Weitere Informationen finden Sie unter Mit dem Remoteregistrierungsdienst kann keine Verbindung hergestellt werden.

  21. Klicken Sie auf der Seite Überprüfungswarnung auf No, I do not require support from Microsoft for this cluster, and therefore do not want to run the validation tests. When I click Next, continue creating the cluster. Klicken Sie dann auf Weiter.

  22. Klicken Sie auf der Seite Bestätigung auf Weiter.

  23. Klicken Sie auf der Seite Zusammenfassung auf Fertig stellen.

  24. Klicken Sie im linken Bereich auf Knoten. Es sollten alle drei Computer aufgeführt werden.

Falls Sie einen Cloudzeugen verwenden: Lesen Sie den Artikel Bereitstellen eines Cloudzeugen für einen Failovercluster.

Aktivieren von AlwaysOn-Verfügbarkeitsgruppen

Im nächsten Schritt aktivieren Sie AlwaysOn-Verfügbarkeitsgruppen über den SQL Server-Konfigurations-Manager. Beachten Sie: Verfügbarkeitsgruppen in SQL Server sind nicht dasselbe wie Azure-Verfügbarkeitsgruppen. Eine Verfügbarkeitsgruppe enthält Datenbanken, die hoch verfügbar und wiederherstellbar sind. Eine Azure-Verfügbarkeitsgruppe weist virtuelle Computer verschiedenen Fehlerdomänen zu. Weitere Informationen zu Fehlerdomänen finden Sie unter Verwalten der Verfügbarkeit virtueller Computer.

Gehen Sie wie folgt vor, um AlwaysOn-Verfügbarkeitsgruppen auf SQL Server zu aktivieren:

  1. Verbinden Sie sich über das Konto „sp_install“ mit dem primären SQL-Server. Sie können auch ein anderes Konto verwenden, das die Serverrolle „SysAdmin“ auf dem SQL-Server hat.

  2. Klicken Sie auf Start, geben Sie SQL Server-Konfiguration ein, und klicken Sie auf SQL Server-Konfigurations-Manager.

  3. Klicken Sie im linken Bereich auf SQL Server-Dienste.

  4. Doppelklicken Sie im Inhaltsbereich auf SQL Server (MSSQLSERVER).

  5. Klicken Sie unter SQL Server (MSSQLSERVER) Properties auf die Registerkarte Hohe Verfügbarkeit mit AlwaysOn, und wählen Sie AlwaysOn-Verfügbarkeitsgruppen aktivieren aus. Klicken Sie auf Apply und anschließend auf OK, wenn Sie dazu aufgefordert werden. Schließen Sie das Eigenschaftenfenster noch nicht.

  6. Klicken Sie auf die Registerkarte Anmelden, und vergewissern Sie sich, dass das Optionsfeld This Account ausgewählt ist. Geben Sie dann „<Ihre Domäne>\sqlservice“ in das Feld Kontoname ein. Geben Sie in das Feld Kennwort und in das Feld Kennwort bestätigen jeweils das Kennwort für das Konto „sqlservice“ ein, und klicken Sie auf OK.

  7. Klicken Sie im Meldungsfenster auf Ja, um den SQL Server-Dienst neu zu starten.

  8. Stellen Sie eine Verbindung zum sekundären SQL-Server her, und wiederholen Sie alle Schritte.

Wenn Sie diese Phase erfolgreich abgeschlossen haben, sieht Ihre Konfiguration wie folgt aus. Für die Computernamen werden hier Platzhalter verwendet.

Phase 3: Die SQL Server-Infrastruktur für Ihre SharePoint Server 2016-Farm mit hoher Verfügbarkeit

Phase 3 of the SharePoint Server 2016 highly-available farm in Azure with SQL Server infrastructure

Nächster Schritt

Gehen Sie weiter zu SharePoint-Intranetfarm in Azure, Phase 4: Konfigurieren von SharePoint-Servern, um mit der Konfiguration dieser Workload fortzufahren.

See also

Installieren und Konfigurieren von SharePoint Server 2016

Bereitstellen von SQL Server AlwaysOn-Verfügbarkeitsgruppen für SharePoint Server 2016 in Azure
SharePoint Server 2016 in Microsoft Azure
Entwerfen einer SharePoint Server 2016-Farm in Azure