Jump to content

Update-Verhalten Windows Server 2016 (extrem langsam, monatlich zwei KUs))


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

vor einer Stunde schrieb Horstenberg:
vor 1 Stunde schrieb Sunny61:

Wir haben ein GPO das die Updates um 3 Uhr in der Nacht installiert. Die Server werden tagsüber in eine Gruppe auf dem WSUS verschoben, für die die Updates zur Installation freigegeben sind. In 99% der Fälle funktioniert das Installieren der Updates auch auf W2016 damit problemlos. Wenn ihr Hyper-V Hosts im Cluster habt funktioniert die Vorgehensweise mit der Installation in der Nacht AFAIK ebenfalls.

Wir haben zwei Hyper-V-Hosts, die sind sozusagen das Rückgrat der gesamten IT. Die würde ich nur ungern unbeaufsichtigt nachts updaten und neustarten.

Was spricht gegen die Erstellung eines Clusters? Dann das ganze per PS-Script. Wartungsmodus einschalten, Maschinen werden verschoben, anschließend die WUA_SearchDownloadInstall.vbs passend aufrufen, schon wird automatisch gedownloadet, installiert und gebootet. Am nächsten Tag dann den zweiten Node aktualisieren.

 

Und wenn die beiden Hosts wirklich das Rückgrat sind, solltest Du dir in Sachen Ausfallsicherheit etwas überlegen. Sind die Hosts mit den vorhandenen VMs denn ausgelastet oder kann 1 Host alle VMs hosten?

 

Nett wie bei solch einfachen Fragen zu WU dann solche Konfigurationen zu Tage kommen.

bearbeitet von Sunny61
Link zu diesem Kommentar
vor 1 Minute schrieb Sunny61:

Was spricht gegen die Erstellung eines Clusters? Dann das ganze per PS-Script. Wartungsmodus einschalten, Maschinen werden verschoben, anschließend die WUA_SearchDownloadInstall.vbs passend aufrufen, schon wird automatisch gedownloadet, installiert und gebootet. Am nächsten Tag dann den zweiten Node aktualisieren.

 

Und wenn die beiden Hosts wirklich das Rückgrat sind, solltest Du dir in Sachen Ausfallsicherheit etwas überlegen. Sind die Hosts mit den vorhandenen VMs denn ausgelastet oder kann 1 Host alle VMs hosten?

 

Nett wie bei solch einfachen Fragen zu WU dann solche Konfigurationen zu Tage kommen.

 

Die beiden physischen Hosts sind hardwaretechnisch fast identisch. Ausfallsicherheit besteht durch Hyper-V-Replication, mit der die wichtigsten Server-VMs jeweils auf den anderen Host repliziert werden. Wenn ein physischer Host ausfällt, müssten ein paar VMs "ausgeschaltet" werden, die zentralen Dingen laufen dann aber dann auf dem verbleibenden Host weiter (DC, AD, Printserver, Exchange, Fileserver). Klappt bislang alles so ganz gut, immerhin seit ca. 6 Jahren ohne größere Probleme. Ist mehr so Hochverfügbarkeit und Clustern für Arme, angesichts der geringen Größe des Netzwerks aber akzeptabel. 

 

Link zu diesem Kommentar
vor 6 Minuten schrieb Dukel:

Auch bei Hyper-V Replica kann man die Maschinen verschieben. Bei der manuellen Tätigkeit gibt es keinen Datenverlust.

Das ist übrigends keine Hochvefügbarkeit, das ist eine DR Lösung!

 

Stimmt, das ist keine Hochverfügbarkeit. Es ist aber eine gute Fallback-Option, mit der ich seit Jahren gute Erfahrungen mache. 

vor 4 Minuten schrieb Nobbyaushb:

OT on - nicht für alles ist Replica zulässig! AD nein, Exchange nein, SQL unter bestimmten Voraussetzungen - OT off

Stimmt. Da man für die Replikation ohnehin doppelte Lizenzen braucht, habe ich auf jedem Host einen DC (mit AD und DNS), die ohnehin aufeinander replizieren. Zum Exchange habe ich backups und eine separate Maschine mit Mailstore. (Stimmt, ist jetzt aber echt OT).

 

Übrigens: Für Exchange ist Hyper-V-Replication nicht "unzulässig", es ist "nicht supportet". Das heißt nicht, dass es nicht funktioniert (und technisch müsste es es funktionieren, jedenfalls, seit Production-Checkpoints repliziert werden, das habe ich aber noch nicht probiert. Windows-Server-Backup sichert den Exchange auch nicht anders, und das funktioniert nun nachweislich gut.). 

bearbeitet von Horstenberg
Link zu diesem Kommentar
vor 20 Minuten schrieb Horstenberg:

Wenn ein physischer Host ausfällt, müssten ein paar VMs "ausgeschaltet" werden,

Klingt jetzt aber doch so, als wäre ein dritter Host angesagt.

Meistens fallen halt die Dinge, die ausgeschaltet bleiben können / unwichtig sind, genau dann aus, wenn sie ganz ganz dringend benötigt werden. ;)

Link zu diesem Kommentar
vor 43 Minuten schrieb testperson:

Klingt jetzt aber doch so, als wäre ein dritter Host angesagt.

Meistens fallen halt die Dinge, die ausgeschaltet bleiben können / unwichtig sind, genau dann aus, wenn sie ganz ganz dringend benötigt werden. ;)

In den meisten Fällen dürftest Du damit Recht haben. Das Ausfallen eines physischen Hosts wäre bei uns dadurch zu kompensieren, dass im Wesentlichen nur die VMs, die für den Remotezugriff "zuständig" sind, ausgeschaltet bleiben. Das ist bei uns nicht systemkritisch und hat nur für wenige User Folgen. Das könnten wir tatsächlich verschmerzen. 

Link zu diesem Kommentar
vor 1 Stunde schrieb Horstenberg:

Übrigens: Für Exchange ist Hyper-V-Replication nicht "unzulässig", es ist "nicht supportet". Das heißt nicht, dass es nicht funktioniert (und technisch müsste es es funktionieren, jedenfalls, seit Production-Checkpoints repliziert werden, das habe ich aber noch nicht probiert. Windows-Server-Backup sichert den Exchange auch nicht anders, und das funktioniert nun nachweislich gut.). 

 

Hallo,

 

deine Aussage ist technisch nicht richtig, deshalb auch nicht deine Schlussfolgerung. Ich zitiere von Microsoft: https://docs.microsoft.com/de-de/exchange/plan-and-deploy/virtualization?view=exchserver-2019

Zitat

Some hypervisors include features for taking snapshots of virtual machines. Virtual machine snapshots capture the state of a virtual machine while it's running. This feature enables you to take multiple snapshots of a virtual machine and then revert the virtual machine to any of the previous states by applying a snapshot to the virtual machine. However, virtual machine snapshots aren't application aware, and using them can have unintended and unexpected consequences for a server application that maintains state data, such as Exchange. As a result, making virtual machine snapshots of an Exchange guest virtual machine isn't supported.

 

Snapshots (Checkpoints) sind nicht "Application Aware". Die Windows Server Sicherung aber schon. Das ist ein großer unterschied :achtung:Daraus resultiert die Möglichkeit eines Datenverlustes und das erklärt auch warum Microsoft das nicht unterstützt. ;-)

 

bearbeitet von MurdocX
Link zu diesem Kommentar
vor 21 Stunden schrieb MurdocX:

 

Hallo,

 

deine Aussage ist technisch nicht richtig, deshalb auch nicht deine Schlussfolgerung. Ich zitiere von Microsoft: https://docs.microsoft.com/de-de/exchange/plan-and-deploy/virtualization?view=exchserver-2019

 

Snapshots (Checkpoints) sind nicht "Application Aware". Die Windows Server Sicherung aber schon. Das ist ein großer unterschied :achtung:Daraus resultiert die Möglichkeit eines Datenverlustes und das erklärt auch warum Microsoft das nicht unterstützt. ;-)

 

ok und Danke für die Info. In irgendeinem Blog hatte ich mal gelesen, dass das mit der Replikation von Exchange in Hyper-V klappen kann, seit es Production-Checkpoints gibt. Zur Nachahmung war es aber sowieso nicht empfohlen. 

Link zu diesem Kommentar

Moin,

 

als "unzulässig" könnte Microsoft es nur bezeichnen, wenn es gegen Lizenzbestimmungen verstößt. "Nicht supported" bedeutet: wenn "sowas" gemacht wird, leistet der Hersteller keine Unterstützung dafür - typischerweise weder für Probleme, die direkt aus "sowas" entstehen (hier etwa: die Replikation funktioniert nicht), meist aber ausgedehnt auf jede Art von Problem, auch wenn sie nur sehr indirekt mit "sowas" zu tun hat (Beispiel: der Mailversand klappt nicht).

 

Wenn man Lust hat, "sowas" dann selbst zu supporten, hält einen Microsoft nicht davon ab. Nur kann man dann eben nicht bei Microsoft anrufen, wenn was klemmt (um vorzubeugen: doch, kann man schon, die werden aber sehr bald das Gespräch beenden). Da ein solcher Zustand für die meisten Unternehmen indiskutabel ist, kommt "nicht supported" schon nah an "unzulässig" heran.

 

Gruß, Nils

 

Link zu diesem Kommentar
vor 8 Stunden schrieb NilsK:

Moin,

 

als "unzulässig" könnte Microsoft es nur bezeichnen, wenn es gegen Lizenzbestimmungen verstößt. "Nicht supported" bedeutet: wenn "sowas" gemacht wird, leistet der Hersteller keine Unterstützung dafür - typischerweise weder für Probleme, die direkt aus "sowas" entstehen (hier etwa: die Replikation funktioniert nicht), meist aber ausgedehnt auf jede Art von Problem, auch wenn sie nur sehr indirekt mit "sowas" zu tun hat (Beispiel: der Mailversand klappt nicht).

 

Wenn man Lust hat, "sowas" dann selbst zu supporten, hält einen Microsoft nicht davon ab. Nur kann man dann eben nicht bei Microsoft anrufen, wenn was klemmt (um vorzubeugen: doch, kann man schon, die werden aber sehr bald das Gespräch beenden). Da ein solcher Zustand für die meisten Unternehmen indiskutabel ist, kommt "nicht supported" schon nah an "unzulässig" heran.

 

Gruß, Nils

 

Eine Lösung wie die Hyper-V-Replication von Exchange wird Microsoft wohl schon deshalb nicht supporten, weil es für Microsoft total uninteressant ist. Interessant ist das nur für kleinere Umgebungen, die Microsoft ohnehin in die Cloud schieben möchte. Größere Umgebungen sollen das über DAG lösen, was ja sicherlich auch besser ist als Hyper-V-Replication. Jede kleinere Umgebung, die alles On-Premises lösen will, muss gucken, zu welchen Kompromissen man bereit ist. Da kann es manchmal erwägenswert sein, auch einen Weg zu gehen, bei dem es keinen Support von MS gibt.

 

Übrigens an alle ein herzliches Dankeschön für die Beiträge hier! Die Hyper-V-Server habe ich jetzt auf Windows Server 2019 umgestellt, da die Lizenzen ohnehin da waren. Ich hatte etwas Bedenken, WS 2019 auf recht betagter Hardware zu installieren (sechs Jahre alt). Gefühlt war die Installation von WS 2019 aber sehr unproblematisch und problemloser als die vieler anderer früherer WS-Versionen. Und die Updates laufen plötzlich ziemlich schnell. 

Link zu diesem Kommentar
vor 33 Minuten schrieb Horstenberg:

Jede kleinere Umgebung, die alles On-Premises lösen will, muss gucken, zu welchen Kompromissen man bereit ist. Da kann es manchmal erwägenswert sein, auch einen Weg zu gehen, bei dem es keinen Support von MS gibt.

An der Stelle würde ich eher auf ein schnelles und getestest (Disaster) Recovery bzw. Backup Konzept setzen. Was nützt dir das Replica, wenn es nicht sauber läuft bzw. das evtl. Problem erst Tage, Wochen, Monate oder gar Jahre später auftritt?

 

vor 37 Minuten schrieb Horstenberg:

Ich hatte etwas Bedenken, WS 2019 auf recht betagter Hardware zu installieren (sechs Jahre alt).

An der Stelle könnte man natürlich fragen, ob die betagte Hardware für Windows Server 2019 freigegeben ist. ;)

Link zu diesem Kommentar
vor 16 Stunden schrieb Horstenberg:

Ich hatte etwas Bedenken, WS 2019 auf recht betagter Hardware zu installieren (sechs Jahre alt).

Keiner unsrere Server wird jemals so alt werden, da keiner der Hersteller so lange Teile für Hardware liefert - bzw. nur unter bestimmten Voraussetzungen, aber geht zu weit OT

 

Ich bin bei Jan - ihr solltet dringend eurer Backup-Konzept überarbeiten, bzw. anders ansetzten, aber auch das geht alles zu weit OT

 

Wenn das jetzt für dich erledigt ist - OK

 

Bezüglich Exchange (das ist ja meine Spielwiese...) habe ich im DR Fall den Server nach 1 h wieder ON, vorausgesetzt, die Datenbanken sind im Zugriff / im Backup

 

Aber wie oben geschrieben - viel Erfolg :-)

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...