... {section:border=false}{column}Der Betrieb von Applikationen wie z.B. SAP in einer virtualisierten Systemumgebung erfordert neue Methoden zur Pflege betriebsystemnaher Software. Solaris 10 Technologien wie Container, ZFS, Live Upgrade und Upgrade-on-Attach ermöglichen ein optimales Konzept zum hardware-unabhängigen Betrieb von Server-Ressourcen. Eine derart flexibilisierte Landschaft ist aber nur dann kostengünstig und sicher betreibbar, wenn neben der Virtualisierung auch die erforderliche Aktualisierung sichergestellt ist. Hier unterscheidet sich Solaris 10 positiv von allen anderen Lösungen im Markt.
Das [Sun White Paper zu diesem Thema |http://wikis.sun.com/download/attachments/65087706/WhitePaper_SunUpgradeAndPatch-SO9V2.11F-g.pdf] beschreibt erforderliche Upgrade- und Patch-Prozesse und geht in einem eigenen Kapitel auf die Besonderheiten von hochverfügbaren Sun Cluster Umgebungen ein.
h5.Die zwei Verfahren / Technologien !
Solaris Live Upgrade ist das optimales Verfahren, um einen Upgrade für ein solches Systems durchzuführen oder Patches einzuspielen. Das Verfahren zeichnet sich besonders dadurch aus, dass die Länge des benötigten Wartungsfenster, und damit die Downtime der Anwendungen auf dem System, minimal ist.
Dies bedeutet auch immer, dass alle auf dem System installierten Anwendungen gleichzeitig betroffen sind. Wenn mehrere Anwendungen mit verschiedenen Wartungsfenstern zusammen auf einem System betrieben werden, kann ein Live Upgrade nicht durchgeführt werden. {column}{column}!wp_upgrade_patchen.jpg!{column}{section}
Mit der neuen Update-on-Attach Technologie für lokale Zonen steht daher ein weiterer Mechanismus in Solaris zur Verfügung, mit dem diese Aufgabenstellung gelöst werden kann. Er ermöglicht es dem Betrieb, einen Update eines Solaris Containers inklusive der Anwendung geplant und innerhalb des für die Anwendung in den Service Level Agreements (SLAs) definierten Wartungszeitraums durchzuführen. Dabei geschieht der eigentliche Update durch einfaches Verschieben des Containers auf ein anderes System mit einer neueren Betriebssystemversion.
Durch verschiebbare Container ist es auch möglich, eine Anwendung vor einem Live Upgrade „zu schützen". Kann der Betrieb kein gemeinsames Wartungsfenster für die Anwendungen auf einem System finden, so können Einzelne, diese Anwendungen beinhaltende Container, auf andere Systeme mit dergleichen Betriebssystemversion verschoben werden. Dies geschieht geplant in dem jeweils verfügbaren Zeitfenster der Anwendung.
h5.Wichtige Anmerkungen |
| Bei der Planung für den Einsatz von Live-Upgrade sollte auch berücksichtigt werden, dass diese Applikationen möglichst in einem eigenen Filesystem installiert werden. Insbesondere Datenbanken, Datendateien und Schnittstellen sind hierbei unbedingt näher zu betrachten. Werden sie z.B. im root-Filesystem der globalen oder einer lokalen Zone installiert und wird beispielsweise der Reboot eines Systems mit Datenbank erst 60 Minuten nach einem Live Upgrade "lucreate" durchgeführt, so ist der "Stand" der Datenbank nach einem Umschalten auf die neue Bootumgebung, immer noch der vor 60 Minuten. Alle Daten, die in diesen 60 Minuten in die Datenbank geschrieben wurden, sind nicht mehr vorhanden. Daher sollte, falls die Applikation im root-Filesystem installiert wurde,
vor einem Upgrade die Applikation gestoppt und
der Befehl "luactivate" und der Reboot des Systems möglichst direkt nach dem Update des Systems erfolgen. Ist dies nicht möglich, so sollte über den Einsatz von Update-on-Attach nachgedacht werden. |