Vernünftiger Patch-Zeitplan für Windows 2003-Cluster

Wir haben einen Cluster von 75 Win2k3-Knoten in einem grobkörnigen Rechencluster. Der Cluster befindet sich hinter einem Berg von Firewalls und befindet sich in einem eigenen VLAN. Jobs aller Größen und Typen werden im Cluster ausgeführt, und alle ausgeführten ausführbaren Dateien werden nach Maß erstellt.

(ed: zusätzliche Hinweise zu unseren ausführbaren Dateien) Die Jobs dauern zwischen 30 Sekunden und 7 Tagen und können eine ausführbare Datei oder 2000 Unterjobs (von kurzer Dauer) enthalten. Offensichtlich versuchen wir, die Situation zu vermeiden, in der unsere IT einen Neustart während eines 7-tägigen Produktionsauftrags plant.

Wir haben eine Planungssoftware, die alle normalen Aufgaben für einen grobkörnigen Cluster übernimmt, und wir können steuern, welche Maschinen für die Übermittlung aktiv sind usw. Wenn WSUS in irgendeiner Weise skriptfähig wäre (oder der Client die Verfügbarkeit für das Herunterfahren angeben könnte), könnten wir koordinieren die beiden Systeme und helfen aus.

Derzeit ist der Patch-Zeitplan der Sonntag nach dem Super-Dienstag, unabhängig davon, was auf dem Cluster ausgeführt wird. Wir müssen jedes Mal eine Ausnahme beantragen, wenn wir das Patchen einer Maschine für einen lang laufenden Produktionsauftrag verzögern möchten. Während unsere Gruppe für die Maschinen verantwortlich ist, haben wir im Grunde wenig Kontrolle über den Patch-Zeitplan der IT.

1. Ist das monatliche Patchen mit dem Zeitplan von MS für einen Windows-Produktionscluster sinnvoll?
2. Gibt es in WSUS Software-Hooks, bei denen wir sagen könnten: "Bitte starten Sie noch nicht neu"?

1.Ist das monatliche Patchen mit dem Zeitplan von MS für einen Windows-Produktionscluster sinnvoll?

Ja, jedoch sollte ein Cluster keine mit einem Patch verbundenen Ausfallzeiten haben, da die Jobs auf einen anderen Knoten übertragen werden sollten. Ich würde NICHT den gesamten Cluster gleichzeitig patchen (das wäre verrückt).

2. Gibt es in WSUS Software-Hooks, bei denen wir sagen könnten: "Bitte starten Sie noch nicht neu"?

Es gibt keine Möglichkeit für Endbenutzer, ein WSUS-Update oder einen Neustart zu stoppen, aber es scheint mir, dass Sie ein echtes Kommunikationsproblem zwischen Ihrer Gruppe und der IT-Gruppe haben. Sie sollten jedoch in der Lage sein, jeweils 1 Knoten zu verlieren, ohne die Produktion zu beeinträchtigen.

Durch die Verwendung von Config Mgr zum Verwalten der Bereitstellung von Updates können Sie den Neustart der Server stoppen. Daher werden Updates angewendet (die jedoch möglicherweise erst nach einem Neustart wirksam werden), und die IT-Abteilung verfügt über Berichte, in denen die Server angezeigt werden, für die ein Neustart aussteht. Sie können Ihnen diese Liste leicht geben, und ich gehe davon aus, dass Sie die Neustarts bestimmter Knoten ohne zu große Unterbrechungen problemlos von Hand planen können. Die IT kann leicht eine ausfallsichere Bereitstellung (mit erzwungenen Neustarts) und eine lange Frist haben, so dass dies letztendlich die Aktualisierungen und Neustarts erzwingt, falls Sie Ihre Seite nicht im Griff haben!

Für die Standard-Update-Bereitstellungen möchten die IT (und Sie) wahrscheinlich sehr kurze Fristen für eine vollständig stille Bereitstellung (nicht neu startende Bereitstellung) sowie eine etwas längere Bereitstellungsfrist, die nicht stumm ist, sodass Sie benachrichtigt werden, wenn Sie sich beim Server anmelden. Keine dieser Bereitstellungen sollte den Neustart erzwingen.

Möglicherweise tritt immer noch die Situation auf, dass etwas fehlschlägt, wenn eine Bibliothek oder eine andere Codekomponente aktualisiert wurde, während sie nicht verwendet wird, und dann verwendet wird, bevor der Neustart den Rest der Aktualisierungen wirksam werden lässt.

Dies ist ein effizienter Weg, um das zu erreichen, was Sie und die IT wollen, und jeder von Ihnen hat einen gewissen Überblick darüber, was vor sich geht. Die Meldung, welche Server sich gemäß den Bereitstellungen in welchem ​​Status befinden, ist auch für Sie beide sehr nützlich.

Klingt so, als würden Sie von Ihrer IT-Abteilung eine Menge "Talk to the Hand" -Haltung erhalten. Sie müssen sich hinsetzen (oder sie mit Bier bestechen?), Um Ihre Situation zu erklären und zu prüfen, ob sie beispielsweise einen nachgeschalteten WSUS-Server mit manuellen Patch-Genehmigungen erstellen können.

Die Einstellungen für WSUS werden alle durch Gruppenrichtlinien festgelegt. Diese werden im Active Directory auf Domänen- oder Organisationseinheitsebene festgelegt. Wenn sich die Server in der Unternehmensdomäne ohne separate Organisationseinheit befinden, erhalten sie das, was alle anderen erhalten, was nicht angemessen klingt.

Wenn Sie das Problem mit Ihrer IT-Abteilung nicht lösen können, entfernen Sie die Computer aus der Domäne.