Home 
ORDIX News 3/2004
ORDIX News 3/2004
ORDIX News 3/2004
Das IT-Magazin der ORDIX AG mit Fachbeiträgen zu Datenbanken, Unix und Java/XML.
FlexFrame wurde von Fujitsu Siemens Computers in Zusammenarbeit mit SAP und Network Appliance entwickelt. Es adressiert neue SAP-Einführungen, in denen die oben genannten Anforderungen realisiert werden sollen.
Das System besteht aus 2 Control Nodes (Steuerungsrechner), einem Network Appliance Filer, auf dem sämtliche Daten liegen und beliebig vielen Application Nodes, auf denen die einzelnen SAP-Instanzen gestartet werden.
Die Application Nodes beziehen ihre Daten inklusive des eigenen Kernels und des Betriebssystems aus dem Netz. Die IP-Adresse und Lage des Kernels liefern DHCP bzw. TFTP Server, die hochverfügbar auf den Control Nodes laufen. Filesysteme werden mittels NFS direkt vom NetApp Filer gemounted.
Der Application Node ist somit in der Lage, das zentral liegende Betriebssystem zu Booten.
Mittels spezieller Agenten werden auf den Application Nodes die notwendigen SAP-Instanzen gestartet und überwacht. Sollte ein Application Node ausfallen, so wird die fehlende Instanz auf einem anderen System aktiviert. Da die Daten für alle Nodes erreichbar auf einem Filer liegen, ist dies problemlos möglich.
Sämtliche Systeme basieren auf Suse Linux (SLES 8). Die Hochverfügbarkeit der Control Nodes wird durch Primecluster erreicht. Durch myAMC.FA werden die einzelnen Applikationen überwacht. Hinzu kommt die SAP/R3 Software und eine geeignete Datenbank, beispielsweise Oracle.
Für höhere Leistung der Application Nodes (z. B. für die Datenbank-Instanz) sollen Application Nodes in naher Zukunft auch unter Solaris betrieben werden können. Dies ermöglicht den Einsatz der Primepower Systeme.
Die Application Server, auf denen die SAP-Instanzen laufen, werden über ein Public LAN von den SAPGUIs der Anwender erreicht.
Für die Kommunikation der SAP-Instanzen untereinander ist ein separates Netz vorgesehen, welches nicht von außen erreichbar sein muss. Da in einer FlexFrame Lösung die Application Server alle Daten auf einem Filer liegen haben, wird zusätzlich noch ein Storage-Netzwerk benötigt (siehe Abbildung 1).
Das Storage- und Servernetz kann für Testumgebungen bzw. für Installationen, die wenig Datendurchsatz benötigen, zusammengelegt werden.
Jeder Rechner hat im Server-, im Storage- und im Public-LAN feste IP-Adressen. Diese werden unter anderem dafür genutzt, den Kernel zu laden und die Filesysteme zu mounten (siehe Abbildung 2). Alle Anforderungen auf Betriebssystemebene werden über diese statischen Adressen abgewickelt.
Abb. 2: Statische und virtuelle IP-Adressen.
Die SAP-Instanzen wiederum sind so installiert, dass jede ihre eigenen IP-Adressen und ihren eigenen Nodenamen besitzt. Damit jede SAP-Instanz prinzipiell auf jedem Application Node gestartet werden kann, wird vor dem tatsächlichen Start einer SAP-Instanz in dessen Umgebung der Nodename umgestellt und die entsprechende IP-Adresse auf dem Ziel-Application-Node konfiguriert. Diese virtuellen IP-Adressen werden von den SAP-Instanzen und von den Clients (SAPGUIs) verwendet.
Eine bestimmte SAP-Instanz ist immer über dieselbe IP-Adresse zu erreichen, egal, auf welchem physikalischen Rechner sie gerade läuft.
Auch auf den Control Nodes befinden sich neben den physikalischen zusätzlich noch virtuelle IP-Adressen, um ebenfalls die angebotenen Dienste hochverfügbar zu halten. Für die Verfügbarkeit dieser Dienste (TFTP-Server, DHCP-Server ...) wird die Hochverfügbarkeitssoftware RMS eingesetzt.
Im BIOS des Application Servers wird PXE-Boot als Bootmedium eingestellt. PXE steht für Preboot Execution Environment und entspricht einem Bootloader. PXE lädt den Kernel und eine für Linux typische initrd (initial RAM-Disk). Netzwerktreiber werden geladen und die IP-Adresse konfiguriert. Das Root-Filesystem wird read-only über NFS gemounted.
Der weitere Bootvorgang bietet keine Besonderheiten: /sbin/init wird aufgerufen; /var wird über NFS gemounted; das Master-Resource-Control Skript (/etc/init.d/rc 5), welches wiederum die RC-Skripte des entsprechenden Runlevels startet, wird ausgeführt. Abbildung 3 veranschaulicht den Gesamtvorgang noch einmal.
Abb. 3: Bootvorgang Application Node.
Die Verwendung von PXE bietet eine hohe Flexibilität. Die Lage des Root-Filesystems (NFS-Server mit Verzeichnis) und weitere Systemeigenschaften werden unter PXE konfiguriert und dem Kernel mittels Parameter mitgeteilt.
Zu erwähnen sei noch, dass alle Application Nodes ein gemeinsames Root-Filesystem nutzen. Dieses ist folglich nur Read-Only gemounted. Die /var-Filesysteme sind jedoch für jeden Application Node separat. Dateien, die vom System geschrieben werden müssen oder für jeden Application Node unterschiedlich sind, finden sich im /var-Filesystem und werden durch Symbolic Links auch im Root-Zweig zugreifbar gemacht.
Durch den beschriebenen Bootvorgang sind alle Application Nodes in der Lage, mit dem zentral verwalteten Betriebssystem zu booten. Ziel ist, darüber hinaus die unterschiedlichen SAP-Instanzen auf den Systemen zu verteilen. Dazu läuft auf jedem Application Node ein eigens für FlexFrame entwickelter Agent namens "myAMC Application Agent". Auf dem Control Node läuft (wiederum hochverfügbar) der "myAMC Control Agent". Alle myAMC-Agenten nutzen dasselbe NFS-Filesystem.
Über regelmäßige Statuseinträge der Application Agents kennt der Control Agent den Zustand der Application Agents und der zugehörigen Applikation.
Stellt der Application Agent fest, dass seine Applikation nicht mehr läuft, so kann er sie neu starten. Gelingt ihm das nicht, wird er sie an einen anderen Application Node abgeben.
Ist der Application Node komplett ausgefallen, bleiben die Statusmeldungen auf dem NFS-Filesystem aus. Der Control Node reagiert, indem er die fehlende Applikation auf einem anderen Application Node starten lässt.
Markus Schreier (info@ordix.de).