Share via


Entwerfen einer SharePoint Server 2016-Farm in Azure

 

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

**Letztes Änderungsdatum des Themas:**2017-10-19

Zusammenfassung: Dieser Artikel beschreibt Schritt für Schritt den Entwurfsprozess zur Konfiguration von Microsoft Azure-Infrastrukturdiensten als Host für SharePoint Server 2016-Farmen.

Der Artikel gibt einen Überblick über die Unterstützung von SharePoint Server 2016-Farmen in den Azure-Infrastrukturdiensten. Darüber hinaus enthält er einen Schritt-für-Schritt-Prozess sowie Empfehlungen und Best Practices für den Entwurf der Azure-Umgebung, inklusive Netzwerk-, Speicher- und Computeressourcen.

SharePoint Server 2016-Farmen in den Azure-Infrastrukturdiensten

Die Ausführung von SharePoint Server 2016-Farmen in einer Infrastructure-as-a-Service-Umgebung (IaaS-Umgebung) hat folgende Vorteile:

  • Kapazität nach Bedarf und die Möglichkeit zur zentralen Hochskalierung von virtuellen Computern (Elastizität)

  • Teilweises Outsourcing

  • Zusätzliche Standorte bei minimaler Investition

  • Kosteneinsparungen

In den folgenden Szenarien sollten SharePoint-Farmen in einer IaaS-Umgebung ausgeführt werden:

  • Farmen für Entwicklung/Tests, Pilotprojekte oder Machbarkeitsstudien

  • Hybride Infrastrukturen

  • Notfallwiederherstellung

  • Produktionsfarm

Unterstützung für SharePoint Server 2016 in Azure

Microsoft unterstützt die folgenden SharePoint Server 2016-Bereitstellungsszenarien mit virtuellen Computern (VMs) in Azure IaaS:

  • Farmen, die nicht produktiv genutzt werden (z. B. Farmen für Entwicklungs-/Testumgebungen oder Machbarkeitsstudien)

  • Notfallwiederherstellungsziel mit Protokollversand, SQL Server AlwaysOn-Verfügbarkeitsgruppen oder Azure Site Recovery

  • Produktionsfarmen mit Azure Storage Premium für Server, denen die Suchrolle zugewiesen ist

Produktionsfarmen mit SharePoint 2013 werden ebenfalls unterstützt. Der Mainstream-Support für SharePoint 2010 wurde mittlerweile eingestellt. Die Version kann jedoch in Azure-VMs installiert werden, um Migrationsszenarien zu testen und zu validieren.

Wie auch bei anderen Microsoft-Workloads läuft die Lizenzierung über Software Assurance mit Lizenzmobilität. Weitere Informationen finden Sie unter Licensing Microsoft server products for use in virtual environments und License Mobility through Software Assurance.

Entwurfsprozess für SharePoint Server 2016-Farmen in Azure

Die Azure-Infrastrukturdienste sind eine Umgebung, die sich von lokalen Rechenzentren unterscheidet und zusätzliche Planung erfordert. Der folgende Entwurfsprozess führt Sie Schritt für Schritt durch die Ermittlung Ihres Bedarfs im Hinblick auf die folgenden Azure-Infrastrukturelementen:

  1. Ressourcengruppen

  2. Konnektivität

  3. Speicher

  4. Identität

  5. Sicherheit

  6. Virtuelle Computer

In jedem Schritt finden Sie Best Practices und Empfehlungen spezifisch für SharePoint Server 2016-Farmen.

Nachdem Sie den Entwurfsprozess durchgearbeitet haben, wissen Sie, welche Komponenten der Azure-Infrastrukturdienste Sie für Ihre SharePoint Server 2016-Farm benötigen.

Tipp

Der vorgestellte Prozess basiert auf dem Artikel Design Azure infrastructure services to host a multi-tier LOB application.

Schritt 1: Ressourcengruppen

Ressourcengruppen sind Container für mehrere Azure-Elemente, die gemeinsam verwaltet werden können. Beispielsweise können Sie Zugriffssteuerungslisten erstellen, die festlegen, dass nur bestimmte Benutzerkonten die Elemente in einer Ressourcengruppe ändern dürfen.

Sie können alle Ressourcen für Ihre SharePoint Server 2016-Farm in ein und derselben Ressourcengruppe platzieren. In Produktionsbereitstellungen raten wir davon allerdings dringend ab. Stattdessen empfehlen wir die Verwendung unterschiedlicher Ressourcengruppen für:

  • Infrastruktur- und Netzwerkkomponenten

    Beispiel: Verwenden Sie eine Ressourcengruppe namens „Networking_RG“, die das virtuelle Netzwerk (VNet), Netzwerksicherheitsgruppen und Load Balancer enthält.

  • Die einzelnen Rollen in der SharePoint-Farm

    Beispiel: Verwenden Sie separate Ressourcengruppen für die Rollen „Front-End“, „Suche“, „Anwendung“, „Verteilter Cache“, „Daten“ und „Kombiniert“ einer typischen SharePoint Server 2016-Farm. Platzieren Sie in jeder separaten Ressourcengruppe die zu der betreffenden Rolle gehörenden Verfügbarkeitsgruppen, Netzwerkschnittstellen und virtuellen Computer.

Füllen Sie vor der Erstellung Ihrer Ressourcengruppen die folgende Tabelle aus. Sie können so viele Zeilen verwenden wie nötig.

Ressourcengruppenname Azure-Standort (Region)

Schritt 2: Konnektivität

Unter den Aspekt Konnektivität fallen:

  • Der Intranet- und Internetzugriff auf die Server in Ihrer SharePoint Server 2016-Farm, sowohl zu Verwaltungszwecken als auch durch die Farmressourcen

  • Der Zugriff der Farmserver aufeinander, auf das Intranet und auf das Internet

Zu den Konnektivitätselementen zählen virtuelle Netzwerke (VNets), die Subnetze innerhalb von VNets, das Domain Name System (DNS) für die Namensregistrierung und Namensauflösung, die Datenverkehrsverteilung und die Adressierung für virtuelle Computer.

VNets

Ein Azure-VNet ist der erforderliche Container für virtuelle Computer in den Azure-Infrastrukturdiensten. Es gibt zwei Typen von VNets:

  • Rein cloudbasiert

    Dieser Typ VNet hat keine Verbindung zu einem lokalen Netzwerk. Verwenden Sie VNets dieses Typs, wenn Sie eine ans Internet angebundene SharePoint-Farm bereitstellen, die eine eigenständige Windows Server Active Directory (AD)-Gesamtstruktur verwendet.

  • Standortübergreifend

    Dieser Typ VNet ist mit einem lokalen Netzwerk verbunden. Einem solchen VNet muss ein eindeutiger Adressraum aus Ihrem Intranet zugewiesen werden. Verwenden Sie VNets dieses Typs, wenn Sie eine intranetbasierte SharePoint-Farm bereitstellen, die eine lokale Windows Server AD-Gesamtstruktur verwendet.

Zwar ist es möglich, die VMs einer Serverrolle einer SharePoint-Farm in verschiedenen VNets zu platzieren. Wir raten jedoch dringend davon ab, da Netzwerkdatenverkehr zwischen den VMs dann über eine VNet-zu-VNet-Verbindung oder eine VNet-Peering-Verbindung übertragen werden müsste. Wir empfehlen, alle Server einer Farm in einem einzigen VNet zu platzieren.

Wenn Sie das VNet erstellen, müssen Sie ihm einen Adressraum zuweisen; er kann aus einem oder mehreren CIDR (Classless Inter-Domain Routing)-Blöcken bestehen, auch bekannt als Netzwerkpräfixe. Das ist ähnlich der Zuweisung eines Adressraums an ein neues Rechenzentrum, das mehrere Subnetze und IT-Workloads enthalten wird. Die Auswahl des Adressraums hängt vom Typ des VNets ab:

  • Rein cloudbasiert

    Diesem Typ kann jeder Adressraum aus dem privaten IPv4-Adressraum (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) zugewiesen werden, solange es keine Überlappungen mit den Adressräumen anderer verbundener VNets gibt.

  • Standortübergreifend

    Dieser Typ benötigt einen eindeutigen, nicht überlappenden Adressraum aus Ihrem Intranetadressraum. Dabei kann es sich um einen öffentlichen oder um einen privaten Adressraum handeln.

Füllen Sie die folgende Tabelle für Ihr VNet aus.

VNet-Name VNet-Typ Ressourcengruppenname Adressraum

Platzieren Sie das VNet in der Ressourcengruppe für Infrastruktur- und Netzwerkkomponenten.

Beachten Sie: Sie können ein bereits vorhandenes VNet verwenden, das IT-Workloads in virtuellen Computern in Azure hostet, oder Sie können ein neues VNet erstellen.

Subnetze

Genauso wie die Subnetze in einem Rechenzentrum sind die Subnetze eines Azure-VNets logische Teilbereiche des IPv4-Adressraums, die Netzwerkknoten und deren Datenverkehr gruppieren oder voneinander trennen. Azure unterstützt drei Typen von Subnetzen:

  • VM-Host (erforderlich)

    Dieser Typ Subnetz hostet eine IT-Workload. Ein Beispiel wären alle Server einer SharePoint Server 2016-Farm, die den Dienst „Verteilter Cache“ ausführen.

  • Gateway

    Dieser Typ Subnetz hostet Azure-Gateways für standortübergreifende VPN-Verbindungen oder VNet-zu-VNet-VPN-Verbindungen. Dieses Subnetz muss den Namen „GatewaySubnet“ haben.

  • Verwaltung (empfohlen)

    Dieser Typ Subnetz hostet zwei oder mehr VMs, die Remotedesktopverbindungen zu den Servern im VNet bereitstellen und Funktionen zur Netzwerkverwaltung unterstützen.

Genau wie in lokalen Rechenzentren empfehlen wir auch in Azure die Verwendung eines separaten Subnetzes des Typs „VM-Host“ für jede Gruppe von VMs, die dieselbe Serverrolle für die Farm bereitstellen. Wenn Sie getrennte Subnetze implementieren, können Sie mithilfe von Azure-Netzwerksicherheitsgruppen festlegen, welcher eingehende und welcher ausgehende Datenverkehr erlaubt ist, und Subnetze voneinander isolieren.

Der Adressraum für jedes Subnetz muss Teil des als einzelner CIDR-Block (Netzwerkpräfix) verschriftlichen VNet-Adressraums sein. Wählen Sie den Adressraum so groß, dass die geplante Zahl von Servern mit identischer Serverrolle darin Platz hat.

Anzahl Server Länge des Netzwerkpräfixes

1-3

/29

4-11

/28

12-27

/27

18-59

/26

Wir empfehlen, für das Subnetz „GatewaySubnet“ die Netzwerkpräfixlänge „/27“ zu verwenden und ein Präfix aus dem letzten Teil des VNet-Adressraums zuzuweisen. Weitere Informationen finden Sie unter Calculating the gateway subnet address space for Azure virtual networks.

Füllen Sie vor der Erstellung der Subnetze Ihres VNet die folgende Tabelle aus. Sie können so viele Zeilen verwenden wie nötig.

Subnetzname Adressraum

GatewaySubnet (sofern erforderlich)

DNS

Allen VMs in einem Azure-VNet wird standardmäßig eine Gruppe von DNS-Servern zugewiesen, die die Namensregistrierung und Namensauflösung übernehmen. Sie können diese Einstellung außer Kraft setzen, indem Sie einzelnen VM-Netzwerkschnittstellen DNS-Server zuweisen.

Weisen Sie für eine SharePoint Server 2016-Farm in Azure, die Azure Active Directory (AD)-Domänendienste verwendet, die IP-Adressen des Diensts als die DNS-Server zu.

In einer Azure-basierten SharePoint Server 2016-Farm mit einer Gruppe von Windows Server AD-Domänencontrollern, die auch als DNS-Server fungieren, weisen Sie die IP-Adressen der Domänencontroller als die DNS-Server zu. Bei einem übergreifenden VNet benötigen Sie zwei Sätze von DNS-Servern:

  • zum Einen eine Gruppe von DNS-Servern in Ihrem lokalen Netzwerk, die Ihre Domänencontroller-VMs verwenden, wenn sie der Domäne beitreten und auf Domänencontroller hochgestuft werden.

  • Sobald die VMs zu DNS-Servern geworden sind, setzen Sie die DNS-Server auf die IP-Adressen der Domänencontroller zurück.

Füllen Sie die folgende Tabelle für die DNS-Server-IP-Adressen aus, die Ihrem VNet zugewiesen werden sollen. Sie können so viele Zeilen verwenden wie nötig.

IP-Adressen des DNS-Servers

Datenverkehrsverteilung

In einer typischen SharePoint-Farm werden Load Balancer verwendet, um den Datenverkehr auf Server zu verteilen, denen dieselbe Rolle zugewiesen ist. Die Azure-Infrastrukturdienste umfassen einen integrierten Load Balancer, der auf folgende Weise verwendet werden kann:

  • Mit Internetanbindung: Der Load Balancer wird mit einer öffentlichen IP-Adresse verwendet, um eingehenden Internetdatenverkehr auf die VM-Mitglieder einer Gruppe mit Lastenausgleich zu verteilen.

  • Intern: Der Load Balancer wird mit einer IP-Adresse aus einem Subnetz des VNet verwendet, um eingehenden Internetdatenverkehr auf die VM-Mitglieder einer Gruppe mit Lastenausgleich zu verteilen.

Hier unsere Empfehlungen für Azure-Load Balancer in einer Azure-basierten SharePoint Server 2016-Farm:

  • Verwenden Sie für die Front-End-Server den Azure-Load Balancer oder eine Load Balancer-Netzwerkappliance. Kann über das Internet auf die SharePoint-Farm zugegriffen werden: Verwenden Sie einen Load Balancer mit Internetanbindung.

  • Verwenden Sie einen internen Azure-Load Balancer oder eine Load Balancer-Netzwerkappliance für die Gruppe von Servern, auf denen Anwendungen ausgeführt werden, sowie für den SQL Server-Cluster (über die Listener-IP-Adresse).

  • Erstellen Sie die Azure-Load Balancer oder die Load Balancer-Netzwerkappliances in der Ressourcengruppe für Infrastruktur- und Netzwerkkomponenten.

  • Verlängern Sie mit dem Azure PowerShell-Befehl Set-AzureLoadBalancedEndpoint –IdleTimeoutInMinutes 15 das Verbindungstimeout bei Leerlauf, um lang andauernde Verbindungen von SharePoint-Clients zu unterstützen.

  • Zum Testen der VM-Integrität können Sie entweder eine HTTP-GET-Nachricht oder eine ICMP-Echo-Request-Nachricht (ping) absetzen. Ausnahme: Arbeitet die Load Balancer-Netzwerkappliance auf Layer 4, müssen Sie eine HTTP-GET-Nachricht verwenden.

Füllen Sie vor der Erstellung der Azure-Load Balancer die folgende Tabelle aus. Sie können so viele Zeilen verwenden wie nötig.

Load Balancer-Name Zweck Typ (Internet oder intern)

Statische Adressen

Sie können VM-Netzwerkschnittstellen statische IP-Adressen aus dem verfügbaren Subnetzadressraum zuweisen. Wenn Sie einen internen Azure-Load Balancer verwenden, um den Datenverkehr auf Server mit identischer Rolle zu verteilen, sollten Sie dem Load Balancer eine statische IP-Adresse aus dem Subnetz zuweisen, das die Mitglieder der Gruppe mit Lastenausgleich enthält.

Microsoft empfiehlt, in Azure-basierten SharePoint Server 2016-Farmen jedem Server eine statische IP-Adresse zuzuweisen, auf dem SQL Server oder SharePoint Server 2016 ausgeführt wird.

Füllen Sie die folgende Tabelle für die statischen IP-Adressen aus. Sie können so viele Zeilen verwenden wie nötig.

VM-Name oder Load Balancer-Name Statische IP-Adresse

Öffentliche IP-Adressen

Eine öffentliche IP-Adresse ermöglicht Internetzugriff auf einen Load Balancer oder eine VM. Um die Angriffsfläche für Hacker zu verkleinern, empfiehlt Microsoft, öffentliche IP-Adressen ausschließlich für Folgendes zu verwenden:

  • Jumpbox-VMs in einem rein cloudbasierten Netzwerk:

    Eine Jumpbox-VM ist die VM, über die Sie Remotedesktopverbindungen zur Remoteverwaltung der übrigen VMs im VNet initiieren. Es ist nicht nötig, jeder VM eine öffentliche IP-Adresse zuzuweisen.

  • Load Balancer mit Internetanbindung in Farmen, auf die extern zugegriffen wird:

    Die öffentliche IP-Adresse ermöglicht den Zugriff für die Front-End-Server der Farm.

Füllen Sie die folgende Tabelle für die öffentlichen IP-Adressen aus. Sie können so viele Zeilen verwenden wie nötig.

VM-Name oder Load Balancer-Name

Azure weist öffentliche IP-Adressen zu dem Zeitpunkt zu, an dem sie für eine VM oder einen Load Balancer angefordert werden.

Schritt 3: Speicher

Speicherressourcen für VMs in Azure sind verwaltete Datenträger. Hierunter fallen auch die Datenträger, die von den einzelnen VMs verwendet werden.

Azure unterstützt die Speichertypen Storage Standard und Storage Premium. Damit Ihre Konfiguration unterstützt wird, müssen Sie Storage Premium-Speicher für alle SharePoint Server 2016-Server verwenden, die die Suchrolle hosten. Microsoft empfiehlt die Verwendung von Storage Premium-Speicher für alle VMs mit SQL Server oder SharePoint Server 2016. Für die anderen VMs in der Farm können Sie Storage Standard-Speicher verwenden, beispielsweise für Domänencontroller und die VMs im Verwaltungssubnetz.

Schritt 4: Identität

SharePoint Server 2016 setzt die Mitgliedschaft in einer Windows Server AD-Domäne voraus. Deshalb benötigt eine SharePoint Server 2016-Farm in Azure Zugriff auf eine Windows Server AD-Domäne, entweder mit virtuellen Computern, die als Domänencontroller fungieren, oder mit Azure Active Directory (AD)-Domänenendiensten.

Bei Verwendung von virtuellen Computern, die als Domänencontroller fungieren, gilt Folgendes:

  • Erstellen Sie für ausschließlich internetbasierte Farmen in einem rein cloudbasierten VNet eine eigenständige Windows Server AD-Gesamtstruktur mit mindestens zwei VMs für Verfügbarkeit.

  • Für eine Intranetfarm in einem standortübergreifenden VNet können Sie lokale Domänencontroller verwenden. Microsoft empfiehlt jedoch die Verwendung von mindestens zwei Replikatdomänencontrollern für die lokale Windows Server AD-Gesamtstruktur in dem VNet, das die SharePoint-Farm enthält.

Schritt 5: Sicherheit

Verwenden Sie die folgenden Azure-Elemente, um die Sicherheit der Server in der SharePoint-Farm zu gewährleisten:

  • Verwenden Sie für rein cloudbasierte VNets eine Jumpbox-VM für Remotedesktopverbindungen, und weisen Sie dieser Jumpbox-VM die einzige öffentliche IP-Adresse zu. Jumpbox-VMs sind für standortübergreifende VNets optional, da die VMs der SharePoint-Farm direkt aus dem Intranet erreichbar sind.

  • Verwenden Sie subnetzbasierte Netzwerksicherheitsgruppen zur Isolierung von Subnetzen. Netzwerksicherheitsgruppen und die zugehörigen Regeln definieren, welcher Datenverkehr das Subnetz passieren darf. Platzieren Sie die Netzwerksicherheitsgruppen in der Ressourcengruppe für Infrastruktur- und Netzwerkkomponenten.

Füllen Sie vor der Erstellung der Netzwerksicherheitsgruppen die folgende Tabelle aus. Sie können so viele Zeilen verwenden wie nötig.

Name der Netzwerksicherheitsgruppe Subnetzname Regeln

Schritt 6: Virtuelle Computer

Führen Sie für die virtuellen Computer der SharePoint-Farm die folgenden Schritte durch:

  • Erstellen Sie eine Verfügbarkeitsgruppe für jede Gruppe von VMs mit identischer Rolle, und platzieren Sie jeweils alle VMs mit identischer Serverrolle in der entsprechenden Gruppe.

  • Erstellen Sie die Verfügbarkeitsgruppe in der Ressourcengruppe für die jeweilige Serverrolle.

  • Verwenden Sie mindestens zwei VMs für jede Serverrolle.

  • Wenn Sie SQL Server AlwaysOn-Verfügbarkeitsgruppen verwenden und nur zwei SQL-Server einsetzen möchten, müssen Sie auch einen Minderheitsknotenserver für den Cluster implementieren.

  • Platzieren Sie die Netzwerkschnittstellen und die VMs in der Ressourcengruppe für die jeweilige Serverrolle.

Hier die empfohlenen Mindestgrößen für die VMs:

  • Windows Server AD-Domänencontroller: Standard_D2

  • SQL-Server: Standard_DS4

  • Minderheitsknotenserver: Standard_D2

  • SharePoint-Server: Standard_DS4

Adressen für Netzwerkschnittstellen:

  • Verwenden Sie statische private IP-Adressen für alle Schnittstellen von VMs, die als Domänencontroller fungieren oder SharePoint Server 2016 bzw. SQL Server ausführen.

  • Verwenden Sie nur für die Jumpbox-VM eine öffentliche IP-Adresse.

  • Verwenden Sie eine öffentliche IP-Adresse für den über das Internet erreichbaren Load Balancer der Front-End-Server, wenn die Farm über das Internet erreichbar ist.

Jede Azure-VM enthält einen Betriebssystemdatenträger. Sie können bei der Erstellung der VM und auch später zusätzliche Datenträger hinzufügen. In der folgenden Tabelle finden Sie eine Übersicht über die Mindestanzahl von zusätzlichen Datenträgern für die VMs in einer SharePoint-Farm.

Servertyp Zusätzliche Datenträger

Windows Server AD-Domänencontroller

Ein zusätzlicher Datenträger mit 40 GB zum Speichern von Windows Server AD-Informationen

SQL-Server

Drei zusätzliche Datenträger mit je 1 TB für Daten, Protokolle und temporäre Daten

Anwendungs- oder Suchserver

Ein zusätzlicher Datenträger mit 100 GB für Protokolle, ein zusätzlicher Datenträger mit 200 GB für den Suchindex

Front-End-Server oder Hostserver für den verteilten Cache

Ein zusätzlicher Datenträger mit 100 GB für Protokolle

Füllen Sie vor der Erstellung der Verfügbarkeitsgruppen die folgende Tabelle aus. Sie können so viele Zeilen verwenden wie nötig.

Name der Verfügbarkeitsgruppe Rolle in der SharePoint-Farm Ressourcengruppe

Füllen Sie vor der Erstellung der VM-Netzwerkschnittstellen die folgende Tabelle aus. Sie können so viele Zeilen verwenden wie nötig.

Name der Netzwerkschnittstelle Ressourcengruppe Subnetzname Statische IP-Adresse Load Balancer-Instanz (sofern erforderlich)

Füllen Sie vor der Erstellung der VMs die folgende Tabelle aus. Sie können so viele Zeilen verwenden wie nötig.

VM-Name Zweck Größe Verfügbarkeitssatz Ressourcengruppe Name der Netzwerkschnittstelle

Nächste Schritte

Wenn Sie eine Azure-basierte SharePoint Server 2016-Intranetfarm für eine Machbarkeitsstudie oder als Entwicklungs-/Testumgebung erstellen möchten, lesen Sie Entwicklungs-/Testumgebung von Intranet SharePoint Server 2016 in Azure.

Wenn Sie eine für den Produktionseinsatz geeignete Azure-basierte SharePoint Server 2016-Farm mit hoher Verfügbarkeit bereitstellen möchten, lesen Sie Bereitstellen von SQL Server AlwaysOn-Verfügbarkeitsgruppen für SharePoint Server 2016 in Azure.

See also

SharePoint 2013 und SharePoint 2016
Installieren und Konfigurieren von SharePoint Server 2016

SharePoint Server 2016 in Microsoft Azure