SharePoint Server: Patchschritte ohne Ausfallzeiten
GILT FÜR:
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
Patchen ohne Ausfallzeiten (ZDP) ist in SharePoint Server 2016, SharePoint Server 2019 und SharePoint Server Subscription Edition verfügbar. Ermöglichen Sie Benutzern, dokumente weiter zu arbeiten, zu speichern und zu durchsuchen, während Sie Ihre SharePoint Server-Farm patchen.
Das Patchen ohne Ausfallzeiten ist eine Methode zum Patchen und Upgraden, die in SharePoint in Microsoft 365 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).
Ihre ZDP-Erfahrung könnte durch die Verwendung von MinRole in SharePoint Server verbessert werden, aber MinRole ist keine Voraussetzung.
Die Farm muss hohe Verfügbarkeit unterstützen, damit die Vorteile von ZDP optimal genutzt werden können. Eine hochverfügbare SharePoint Server-Farm ist eine Voraussetzung für ZDP.
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.
Wichtig
Auch wenn alle Server in Ihrer SharePoint Server-Farm für die Verwendung der Rolle "Benutzerdefiniert" konfiguriert wurden, können Sie eine hochverfügbare Farm weiterhin manuell konfigurieren. Es gibt Artikel , die Ihnen helfen, hochverfügbare Farmen zu erstellen, und die Prinzipien der Fehlertoleranz (mit redundanter Hardware) und Hochverfügbarkeit (mit Systemen und Software zur Unterstützung von Failover und Fortsetzung der Betriebszeit) sind identisch. Beachten Sie, dass Sie in komplexeren hochverfügbaren oder benutzerdefinierten Farmen besonders darauf achten sollten, die Suchserver auf eine Weise zu patchen, die Hochverfügbarkeit unterstützt, z. B. jeweils ein Indexreplikat zu patchen und Indexreplikate von derselben Partition niemals gleichzeitig zu patchen oder zu aktualisieren.
Der ZDP-Prozess
In diesem Beispiel wird ZDP für ein SharePoint Server-Farmsetup 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.
Hinweis
Allgemeine Informationen zu Softwareupdates für SharePoint Server finden Sie hier. Beachten Sie, dass der Artikel mit der Dokumentation zu Berechtigungseinstellungen für SharePoint Server verknüpft ist. Lesen Sie die folgenden Artikel nach Bedarf, und bedenken Sie, dass zu einem Teil des Patchens Datenbankaktualisierungen gehören. Wenn Sie die SQL Server-Berechtigungen für die SharePoint-Konten nach der Installation geändert haben, müssen Sie diese Artikel lesen.
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.
Wichtig
Durch die parallele Ausführung wird sichergestellt, dass alle Web-Front-Ends in der Farm denselben statischen Inhalt während des Upgrades verarbeiten, auch wenn statische Dateien in einem bestimmten WFE aktualisiert oder ersetzt werden. Parallel ist in PSCONFIG integriert, muss jedoch aktiviert werden. Durch dieses Feature wird sichergestellt, dass Benutzer beim Durchsuchen von SharePoint und beim Arbeiten mit ihren Dateien die gleiche Umgebung auf Websites sehen, auch wenn Dateisystemdateien geändert und aktualisiert werden.
Um die parallele Funktionalität zu aktivieren, führen Sie das folgende PowerShell-Skript einmal aus, indem Sie die URL für eine der Inhaltswebanwendungen verwenden:
$webapp = Get-SPWebApplication <webappURL>
$webapp.WebService.EnableSideBySide = $true
$webapp.WebService.update()
Ab KB3178672 (Update vom März 2017) für SharePoint Server 2016 und höher kopiert PSCONFIG automatisch alle .js, .css und .htm Dateien innerhalb des 16-HIVE\TEMPLATE\LAYOUTS Ordners in den 16-HIVE\TEMPLATE\LAYOUTS\<NEW BUILD NUMBER> Ordner, die erforderlich sind, um zu den neuen Benutzeroberflächendateien wechseln und den parallelen Prozess abschließen zu können, wie weiter unten in diesem Thema in Phase 2 – PSCONFIG-Upgrade (4) beschrieben.
Phase 1 - Patch installieren
Die erste Phase besteht im Abrufen der Binärdateien des Patches auf den Servern und im Installieren.
Take the first WFE (SPWeb01) out of the load balancer and patch it with the 'STS' and 'WSS' packages.
Reboot the server when patching is done.
Return the server to rotation in the load balancer.
Take the second WFE (SPWeb02) out of the load balancer and patch it with the 'STS' and 'WSS' packages.
Reboot the server when patching is done.
Leave this server out of the load balancer until the entire upgrade is complete.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.
For each of SPApp, SPDCH, and SPSRCH in column 1, patch with 'STS' and 'WSS' packages.
Reboot them when they're done. (The work sent by SPWeb01 will fall on servers in column 2).
Now you repeat the 'patch and reboot' for column 2. For each of SPApp02, SPDCH02, and SPSRCH02 in column 2, patch with 'STS' and 'WSS' packages.
Reboot them when they're done. (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-Farm sind die Patches installiert, und alle wurden neu gestartet. Es ist nun an der Zeit, das Upgrade von Build zu Build auszuführen.
Hinweis
[!HINWEIS] Während des ZDP-Vorgangs können Sie Upgrade-SPContentdatabase ausführen, um die Gesamtdauer der Ausführung von PSCONFIG zu reduzieren. Berücksichtigen Sie dies, wenn Sie eine hohe Anzahl von Datenbanken haben oder große Datenbanken auswählen.
Kehren Sie zu der WFE zurück, die sich außerhalb der Rotation mit Lastenausgleich befindet (SPWeb02), öffnen Sie die SharePoint-Verwaltungsshell, und führen Sie den folgenden PSCONFIG-Befehl aus:
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -installNehmen Sie dieses WFE (SpWeb02) nach Abschluss des Befehls wieder in den Lastenausgleich auf. Der Server ist nun vollständig gepatcht und aktualisiert.
Tipp
[!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 dies unter:
C:\programme\common files\Microsoft shared\web server extensions\16\logs. (Der Laufwerkbuchstabe kann bei Ihnen anders lauten.)
Wenn PSCONFIG ui-Dateien aus irgendeinem Grund nicht erfolgreich kopiert hat, führen Sie diesen Befehl aus, um sie manuell zu kopieren Copy-SidebySideFiles!
Remove SPWeb01 from the load-balancer. > Öffnen Sie die SharePoint-Verwaltungsshell, und führen Sie denselben PSCONFIG-Befehl aus:
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -installNehmen 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.
Führen Sie für alle verbleibenden Server in Spalte 1 (SPApp01, SPDCH01, SPSRCH01) denselben PSCONFIG-Befehl in der SharePoint-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
Führen Sie für alle verbleibenden Server in Spalte 2 (SPApp02, SPDCH02, SPSRCH02) denselben PSCONFIG-Befehl in der SharePoint-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 -installWichtig
Nachdem alle Server PSCONFIG erfolgreich durchlaufen haben, denken Sie daran, den folgenden SharePoint-Verwaltungsshell-Befehl auszuführen, um zu den neuen Benutzeroberflächendateien zu wechseln und den parallelen Prozess abzuschließen:
$webapp = Get-SPWebApplication <webappURL>$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, SharePoint Server 2019 und SharePoint Server Subscription Edition. 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 ganze Whitepapers und Artikel dazu online, z. B. diese Dokumentation. Um das Konzept zumindest für diesen Artikel zu vereinfachen, stellen Sie fest, dass ZDP (und auch MinRole) aus SharePoint in Microsoft 365 stammen. In SharePoint in Microsoft 365 verfügen virtualisierte Server über integrierte Redundanzen, sodass sich zwei servergleiche Server aus derselben SharePoint-Farm nicht auf demselben Host oder Rack befinden. Dadurch wird SharePoint 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 erstellen, unabhängig davon, wo sie sich befindet (vollständig mit Racknamen/-nummern und Servernamen, in denen jede SharePoint Server-Rolle zu finden ist). 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.