Managen der Lastverteilung in BW-Systemen bei Wartungsmaßnahmen

Die BW-Systeme, die ich bei meinen bisherigen Kunden kennengelernt habe, waren häufig auf mehrere Applikationsserver verteilt, welche wiederum auch auf verschiedenen Hosts verteilt waren. So kann sichergestellt werden, dass das System bei der Wartung einzelner Hosts weiterlaufen konnte und die wichtigsten Jobs, wie bspw. Monatsabschlüsse, trotz Wartungsmaßnahmen weiterlaufen konnten.

Aber auch bei dieser Lösung reicht es nicht, dass die Applikationsserver nur heruntergefahren werden, sie müssen auch sauber aus der Lastverteilung genommen werden, damit weitere anstehende Jobs nicht auf die heruntergefahrenen Applikationsserver verteilt werden und dadurch möglicherweise abbrechen. Was alles von technischer Seite zu beachten ist, habe ich Ihnen hier einmal aufgelistet:

Lastverteilungsgruppen der Hintergrundverarbeitung:

Für Jobs, welche durch Hintergrundverarbeitung auf die Batch-Workprozesse der einzelnen Applikationsserver aufgeteilt werden, werden sogenannte Servergruppen genutzt. Diese können in der SM61 unter dem Button “Job-Servergruppen” verwaltet werden:

Hier gibt es bei eingerichteter Lastverteilung eine Gruppe namens SAP_DEFAULT_BTC, welche alle Applikationsserver aufführt, auf welche die Jobs verteilt werden.

Soll nun ein Applikationsserver abgeschaltet werden, ist es sinnvoll, diesen vorher aus dieser Servergruppe (und eventuellen weiteren) herauszunehmen, damit keine neuen Jobs mehr zugeordnet werden.

Entfernen des Applikationsservers aus den Logon-Gruppen:

Um zu verhindern, dass Anwender, oder auch automatische Abfragen, nicht mehr durch eine Anmeldung über Logon-Gruppen auf den herauszunehmenden Applikationsserver geleitet werden, muss dieser Server auch aus den Logon-Gruppen entfernt werden.

Hierzu wird die Transaktion SMLG aufgerufen, in der die Logon-Gruppen verwaltet werden. Auch hier gilt es, die Einträge für den betroffenen Applikationsserver herauszunehmen, sodass keine Zuordnung mehr stattfinden kann.

Allerdings ist Vorsicht geboten, falls es Logon-Gruppen gibt, wo es keine Alternativ-Server gibt. Sobald hier der letzte Applikationsserver herausgenommen wird, schlägt jeder Logon-Versuch über die Logon-Gruppe fehl.

RFC-Server-Gruppen-Pflege:

Nun haben wir die weitere Verteilung über Hintergrundprozesse und über Logon-Gruppen eingeschränkt, allerdings gibt es noch die RFC-Server-Gruppen, welche noch beachtet werden müssen. Die Konfiguration hierfür können wir in der Transaktion RZ12 vornehmen.

Auch hier gilt es, den Applikationsserver zu entfernen, sodass nun auch keine Verteilung mehr über RFC-Gruppen mehr stattfindet.

Herunterfahren per Soft-Shutdown:

Sobald wir diese Konfigurationen vorgenommen haben, kann der Applikationsserver heruntergefahren werden. Hierfür empfehle ich den Soft-shutdown über die Transaktion SM51. Durch den Soft-Shutdown können die aktuell noch laufenden Hintergrundprozesse und Jobs noch in Ruhe beendet werden, es starten aber durch unsere Vorkonfigurationen keine weiteren mehr auf dem Server. Sobald kein Job mehr läuft, fährt sich der Applikationsserver herunter und die Wartungsarbeiten können durchgeführt werden.

E-Book SAP Basis

Mehr als 100 ausgewählte SAP Basis Fachartikel von rz10.de seit 2011! Auf über 900 Seiten Tipps, Tricks und Tutorials mit Screenshots aus echten SAP-Systemen.

Jetzt anfordern

E-Book SAP Basis

×

Es ist empfehlenswert, vor jeder dieser Änderungen eine Dokumentation darüber anzufertigen, wie der Stand vorher war. Nach der jeweiligen Wartung kann der Applikationsserver ganz normal mit dem Befehl “startsap r3” auf der Konsole des Applikationsservers neugestartet werden. Nach erfolgreichem Neustart kann dann anhand der Dokumentation der Server wieder normal in die Lastverteilung mit aufgenommen werden und das System kann wieder mit vollen Ressourcen arbeiten.

Hat Ihnen diese Anleitung geholfen oder haben Sie eine andere Vorgehensweise in solchen Situationen?

Schreiben Sie mir gerne von Ihren Erfahrungen!