Schritte zum Patchen ohne Ausfallzeiten (Zero Down Time Patching) in SharePoint Server 2016

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

**Letztes Änderungsdatum des Themas:**2016-10-21

Patchen ohne Ausfallzeiten (Zero Down Time Patching) ist in SharePoint Server 2016 verfügbar. Benutzer können weiterhin an Dokumenten arbeiten, diese speichern oder suchen, während Sie Ihre SharePoint Server 2016-Farm patchen.

Zero Downtime Patching ist eine Methode des Patchens und Upgradens, die in SharePoint Online entwickelt wurde. Damit können Administratoren den Dienst patchen, während Benutzer gleichzeitig ihre Abonnements weiter nutzen können. In anderen Worten: Diese getestete Methode wurde entwickelt, um das Patchen zu ermöglichen, während Benutzer in der SharePoint Server-Farm aktiv an ihren Dateien arbeiten, Durchforstungen mit der Suche ausführen und Ergebnisse rendern. Das ist, worum es sich beim Patchen ohne Ausfallzeiten handelt.

Es gibt ein paar Dinge, die Sie beim Zero Downtime Patching (ZDP) beachten müssen (diese werden später in diesem Artikel erläutert).

• Sie können das Arbeiten mit ZDP durch Verwendung von MinRole in SharePoint Server 2016 weiter verbessern, MinRole ist jedoch keine Anforderung.

  Inwiefern kann MinRole helfen?

• Die Farm muss hohe Verfügbarkeit unterstützen, damit die Vorteile von ZDP optimal genutzt werden können. Eine hoch verfügbare SharePoint Server 2016-Farm ist eine Anforderung für ZDP.

  Warum ist eine hohe Verfügbarkeit erforderlich?

Sie müssen bedenken, dass das Ziel des ZDP die Betriebszeit für Ihre Benutzer ist. In diesem Artikel werden daher alle Entscheidungen im Zusammenhang mit dem Patchen und Neustarten Ihrer Farm im Hinblick darauf getroffen.

Der ZDP-Prozess

In diesem Beispiel wird ZDP für eine SharePoint Server 2016-Farmeinrichtung mit MinRole verwendet. Die Beispielumgebung sieht wie folgt aus:

Diese Struktur kann folgendermaßen aufgegliedert werden: Zwei Web-Front-Ends (WFEs) (SPWeb01 und 02) sind mit einem Lastenausgleich verbunden, zu diesem Zeitpunkt handelt es sich bei beiden um fielding-Anforderungen. Es gibt zwei Anwendungsserver (SPApp01 und 02), zwei Server mit verteiltem Cache (SPDCH01 und 02) und zwei Suchserver (SPSRCH01 und 02). Hinter dieser Struktur, jedoch nicht direkt im ZDP-Prozess enthalten, befindet sich ein SQL Server-Cluster (z. B. SQL Server Always-On).

Ideologisch können Sie in diesem Diagramm eine Linie durch die Mitte der Farm ziehen, von oben nach unten. Auf einer Seite der Linie befinden sich alle Server, die auf „01“ (Spalte 1) enden, und die redundanten Server in „02“ befinden sich auf der anderen Seite (Spalte 2). Wir verwenden diese duale Konstruktion, damit die Farm während des Patchens für Benutzer betriebsbereit bleibt.

In den meisten Fällen ist es so, dass Sie alle Aktionen auf der einen Seite der Linie (für die 01-Server) genau so für 02 wiederholen. Von all den Schritten, die an dem verhältnismäßig einfachen ZDP-Prozess aus zwei Phasen beteiligt sind, sind die Schritte mit den WFEs (SPWeb01 and 02) die komplexesten. Lassen Sie uns damit beginnen.

Vergewissern Sie sich, dass Sie Ihre WFEs neu gestartet und getestet haben, bevor Sie diese aus dem Lastenausgleich nehmen, um Situationen zu vermeiden, in denen das WFE, das zuerst gepatcht werden soll, aus der Rotation genommen wird und andere WFEs die resultierende Last nicht verarbeiten. Alle Server in der Farm sollten vor dem Patchen gerade neu gestartet worden sein. Überlegen Sie auch, ob Sie die Suchdurchforstungen und Profilimporte während des Upgrade- oder Patchfensters anhalten.

Phase 1 - Patch installieren

Die erste Phase besteht im Abrufen der Binärdateien des Patches auf den Servern und im Installieren.

1. 

   Nehmen Sie das erste WFE (SPWeb01) aus dem Lastenausgleich, und patchen Sie es mit den Paketen „STS“ und „WSS“. Starten Sie den Server neu, wenn das Patchen abgeschlossen ist. Nehmen Sie den Server wieder in die Rotation im Lastenausgleich auf.

2. 

   Nehmen Sie das zweite WFE (SPWeb02) aus dem Lastenausgleich, und patchen Sie es mit den Paketen „STS“ und „WSS“. Starten Sie den Server neu, wenn das Patchen abgeschlossen ist. Belassen Sie diesen Server außerhalb des Lastenausgleichs, bis das gesamte Upgrade abgeschlossen ist.

   Hinweis

   Wenn Sie das Upgrade nicht in einem Wartungsfenster ausführen und in der Farm eine hohe Arbeitslast vorhanden ist, können Sie dieses WFE wieder in den Netzwerklastenausgleich aufnehmen, bis Sie bereit sind, PSCONFIG auszuführen.

3. 

   Führen Sie den Patch für SPApp, SPDCH und SPSRCH in Spalte 1 mit den Paketen „STS“ und „WSS“ durch. Führen Sie nach Abschluss einen Neustart aus. (Bei der von SPWeb01 gesendeten Arbeit tritt auf Servern in Spalte 2 ein Fehler auf).

4. 

   Wiederholen Sie jetzt das Patchen und den Neustart für Spalte 2. Führen Sie den Patch für SPApp02, SPDCH02 und SPSRCH02 in Spalte 2 mit den Paketen „STS“ und „WSS“ durch. Führen Sie nach Abschluss einen Neustart aus. (Wie Sie sehen können, tritt nun bei der von SPWeb01 gesendeten Arbeit ein Fehler auf Servern in Spalte 1 auf.)

Phase 2: Upgrade von PSCONFIG

Auf jedem Knoten in der SharePoint Server 2016-Farm wurden die Patches installiert und alle wurden neu gestartet. Es ist nun an der Zeit, das Upgrade von Build zu Build auszuführen.

1. 

   Kehren Sie zu dem WFE außerhalb der Lastenausgleichsrotation (SPWeb02) zurück, öffnen Sie SharePoint 2016-Verwaltungsshell, und führen Sie den folgenden PSCONFIG-Befehl aus:

   PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secrureresources -cmd services -install
   

   Nehmen Sie dieses WFE (SpWeb02) nach Abschluss des Befehls wieder in den Lastenausgleich auf. Der Server ist nun vollständig gepatcht und aktualisiert.

   Tipp

   Durch den letzten Schritt im PSCONFIG-Prozess wird sichergestellt, dass Updates der Benutzeroberfläche aus dem Ordner „/layouts“ in einen versionsspezifischen Ordner kopiert werden. Dies ist Teil des parallelen Benutzeroberflächenupdates, mit dem Benutzer, die Ihre Farm durchsuchen, eine einheitliche Benutzeroberfläche angezeigt bekommen, bis das Upgrade abgeschlossen ist und Sie bereit sind, auf die neue Benutzeroberfläche umzusteigen.
   Um sicherzustellen, dass die parallele Kopie erfolgreich war, überprüfen Sie die zugehörige Protokolldatei. Standardmäßig befindet sich diese unter C:\Programme\Gemeinsame Dateien\Microsoft Shared\web server extensions\16\logs. (Der Laufwerkbuchstabe kann bei Ihnen anders lauten.)
   Wenn die Benutzeroberflächendateien aus irgendeinem Grund von PSCONFIG nicht erfolgreich kopiert wurden, führen Sie den folgenden Befehl aus, um sie manuell zu kopieren Copy-SidebySideFiles!

2. 

   Entfernen Sie SPWeb01 aus dem Lastenausgleich. Öffnen Sie SharePoint 2016-Verwaltungsshell, und führen Sie den gleichen PSCONFIG-Befehl aus:

   PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
   

   Nehmen Sie dieses WFE (SPWeb01) wieder in den Lastenausgleich auf. Dieses ist nun ebenfalls vollständig gepatcht und aktualisiert.

   Beide WFEs sind gepatcht und aktualisiert. Fahren Sie mit den Rest der Farm fort, stellen Sie aber sicher, dass die erforderlichen Microsoft PowerShell-Befehle immer nur auf einem Server und nicht parallel ausgeführt werden. Dies bedeutet, dass Sie für die gesamte Spalte 1 die Befehle Server für Server ausführen. Dann führen Sie die Befehle Server für Server für Server in Spalte 2 ohne Überlappung aus. Das Endziel ist, dass Sie die Betriebszeit aufrechterhalten. Das Ausführen der PSCONFIG-Befehle nacheinander ist die sicherste und am besten prognostizierbare Methode zum Abschließen des ZDP-Prozesses, deshalb werden wir so vorgehen.

3. 

   Führen Sie für alle verbleibenden Server in Spalte 1 (SPApp01, SPDCH01, SPSRCH01), den gleichen PSCONFIG-Befehl in SharePoint 2016-Verwaltungsshell aus. Tun Sie dies auf jedem Server einzeln, bis alle Server in Spalte 1 aktualisiert sind.

   Wichtig

   Denken Sie daran, den verteilten Cache ordnungsgemäß zu entfernen, bevor Sie PSCONFIG ausführen, und nach Abschluss den verteilten Cache wieder dem Server hinzuzufügen.

   PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
   

4. 

   Führen Sie für alle verbleibenden Server in Spalte 2 (SPApp02, SPDCH02, SPSRCH02), den gleichen PSCONFIG-Befehl in SharePoint 2016-Verwaltungsshell aus. Tun Sie dies auf jedem Server einzeln, bis alle Server in Spalte 2 aktualisiert sind.

   Wichtig

   Denken Sie daran, den verteilten Cache ordnungsgemäß zu entfernen, bevor Sie PSCONFIG ausführen, und nach Abschluss den verteilten Cache wieder dem Server hinzuzufügen.

   PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
   

   Wichtig

   Nachdem PSCONFIG für alle Server erfolgreich ausgeführt wurde, müssen Sie den folgenden SharePoint 2016-Verwaltungsshell-Befehl ausführen, um zu den neuen Benutzeroberflächendateien zu wechseln und den parallelen Prozess abzuschließen.
   $webapp.WebService.SideBySideToken = <current build number in quotes, ex: "16.0.4338.1000">
$webapp.WebService.update()

Jetzt sind Sie fertig, und die Farm wurde erfolgreich während der Verwendung und ohne Ausfallzeiten aktualisiert.

Inwiefern kann MinRole helfen?

Wenn es um ZDP geht, sollte auch das Konzept von MinRole behandelt werden. MinRole ist eine Option in der Installation von SharePoint Server 2016. Es unterteilt die Konfiguration einer Farm in Rollen wie „Front-End“ (WFE), „Anwendungsserver“ (App), „Verteilter Cache“ (DCache), „Suche“ oder „Benutzerdefiniert“ (für benutzerdefinierten Code oder Drittanbieterprodukte). Diese Konfiguration liefert Ihnen im Durchschnitt vier Server – zwei WFEs, zwei App-Server, zwei DCache-Server und zwei Suchserver.

Standardmäßig werden WFEs für niedrige Latenz und die App-Server für hohen Durchsatz optimiert. Analog dazu arbeiten die Suchserver effizienter, wenn die Suchkomponenten gebündelt werden, damit Aufrufe das Feld, aus dem sie stammen, nicht verlassen müssen. Einer der größten Vorteile von MinRole besteht darin, dass die Fehlertoleranz integriert ist.

Warum ist eine hohe Verfügbarkeit erforderlich?

Hohe Verfügbarkeit ist ein wichtiges Thema in SharePoint. Es gibt online ganze Whitepaper und Artikel zu diesem Thema, z. B. diese Dokumentation über TechNet. Um das Konzept zumindest in diesem Artikel zu vereinfachen, bedenken Sie, dass ZDP (und auch MinRole) aus SharePoint Online (SPO) stammen. In SPO weisen virtualisierte Server integrierte Redundanzen auf, sodass zwei Server mit derselben Rolle aus der gleichen SharePoint-Farm nicht auf dem gleichen Host oder Rack vorhanden sein können. Deshalb ist SPO fehlertoleranter. Sie können die gleiche Situation nachstellen, indem Sie zwei Server jeder SharePoint-Serverrolle auf separaten Hosts auf unterschiedlichen Racks in Ihrem eigenen Rechenzentrum mit einem gemeinsam genutzten Router oder gemeinsamer Verkabelung zwischen Racks platzieren, um die Kommunikation schneller zu gestalten. Sie können auch einfach zwei physische Server für jede SharePoint-Serverrolle in einer Testumgebung einrichten (wählen Sie dabei separate Stromversorgungen für jede Hälfte Ihrer Farm und stellen Sie sicher, dass das Routing zwischen den Serversätzen schnell ist und, wenn möglich, größeren Netzwerkdatenverkehr für eine niedrigere Latenz umgeht).

Die Ziele sind hier Hochverfügbarkeit und Fehlertoleranz. Oberste Priorität ist daher das Trennen der Rollen über Racks oder Server hinweg, wodurch sichergestellt wird, dass Sie zwei Elemente von jeder Rolle haben, das Bereitstellen eines schnellen Netzwerkdatenverkehrs zwischen diesen beiden Ebenen und das Sicherstellen, dass Ihre Einrichtung über Systeme verfügt, um Datenbankserver automatisch zu überwachen und ein Failover dafür auszuführen. Im Hinblick auf das manuelle Installieren von Diensten in SharePoint (wie bei der Auswahl der Rolle „Benutzerdefiniert“) ist es wichtig, dass die Dienste Redundanzen innerhalb der Farm aufweisen. Der verteilte Cache ist beispielsweise geclustert, Ihre Farm hat mehrere WFEs, Sie richten Anwendungs- und Suchserver paarweise ein. Auf diese Weise kann in dem Fall, dass auf einem Server ein schwerwiegendes Problem auftritt, der andere die Benutzerlast verarbeiten.

In den hier verwendeten Beispielen habe ich physische Server verwendet, um die Konzepte besser verständlich zu machen. Wenn es an der Zeit ist, ZDP zu planen, sollten Sie Ihre eigene Umgebung aufzeichnen (mit Racknamen/Nummern und Servernamen, wo die einzelnen SharePoint-Serverrollen zu finden sind). Dies ist eine der schnellsten Methoden zum Isolieren von Verstößen gegen die Ziele der Rollenredundanz und Fehlertoleranz, die sich in Ihr Setup eingeschlichen haben könnten, unabhängig von der Größe des Setups.

Verwandte Themen

Videodemonstration über das Patchen ohne Ausfallzeiten (Zero Down Time Patching) in SharePoint Server 2016