Unix ist ein Multiuser- und Multitasking-Betriebssystem. Insbesondere SVR4 (auch Solaris) implementiert über den Scheduler automatisch eine Zuteilung der CPU-Ressourcen in der Weise, dass einerseits Anwendungen mit maximaler Geschwindigkeit ablaufen können und dass andererseits beim gleichzeitigen Ablauf von Anwendungen die CPU sinnvoll aufgeteilt wird. Prozesse, die über Gebühr CPU-Zeit beanspruchen, werden benachteiligt. Andere Prozesse, die weniger CPU beanspruchen oder die mit dem Anwender interagieren, werden bevorzugt. Ohne weiteres Zutun ist so ein ausgewogenes Antwortzeitverhalten die Regel.
Eine Ausnahme bilden Client-Server-Anwendungen (auch Datenbanken), die sich mit langlaufenden und ressourcenhungrigen Serverprozessen auf eine "monokulturelle" Nutzung des Unix-Servers beschränken. Da diese Prozesse aus Sicht des Betriebssystems standardisiert behandelt werden, sind die Anwendungen dann selbst für einen sinnvollen Umgang mit den bereitgestellten Ressourcen verantwortlich (sowohl intern als auch untereinander), nehmen diese Verantwortung jedoch i. d. R. nicht oder nur unzureichend wahr. Daraus kann die Situation entstehen, dass eine starke Beanspruchung von Ressourcen (CPU, Memory, aber auch IO-Bandbreite) durch eine Anwendung übermäßige Performancenachteile für andere Anwendungen nach sich zieht.
Mangels eigener Mechanismen kann also für einige Applikationen eine weitere Steuerungsmöglichkeit über das Betriebssystem sinnvoll sein. Insbesondere Solaris 10 bietet gute Möglichkeiten, die tatsächliche Ressourcennutzung über geeignete Modelle zu beeinflussen:
Abhängig von den jeweiligen Möglichkeiten sind diese Mechanismen auf Projekte, Tasks, Prozesse oder Zonen anwendbar.
Zonen erlauben es Anwendungen, bei gemeinsamer Nutzung ein und derselben Betriebssysteminstanz (logisch) isoliert voneinander abzulaufen. Daraus ergibt sich automatisch ein Sharing von Systemressourcen. Dieses kann über das Resourcemanagement von Solaris 10 gesteuert werden und zwar insbesondere für CPU-Anteile und Hauptspeicherverbrauch.
Zonen stellen sich aus Sicht der Applikation wie ein eigenes Betriebssystem dar. Damit lassen sich auch Applikationen, die (unsinnigerweise) von einer Exklusivnutzung des Systems ausgehen, gemeinsam ausführen (jede in einer eigenen Zone). Zonen sind insofern ein mächtiges Werkzeug. Der Preis dafür ist eine erhebliche Zunahme der Komplexität in der Systemverwaltung, da jede Zone u. a. eigene Netzwerkadressen, Benutzer, Gruppen, Passwörter, Startprozeduren, Dateisysteme, Softwarepakete usw. hat. Da auch die Beziehungen zur globalen Zone und untereinander definiert werden müssen, übertrifft die Komplexität die einzelner Rechner. Zu beachten ist insbesondere die spätere Systempflege über Patches, Updates usw.
Eine sauber implementierte und in mehreren Instanzen ablauffähige Applikation erscheint damit aus Sicht des Systemmanagements als die überlegene, weil wesentlich weniger aufwendige, Variante. Das vor allem deshalb, weil das Resourcemanagement von Solaris 10 nicht nur für Zonen, sondern (wesentlich schlanker) auch für Projekte und Tasks (ähnlich Prozessgruppen) genutzt werden kann.
Da jedoch eine Vielzahl von Applikationen existieren, die diesen Anforderungen nicht genügen (leider sind es oft insbesondere die Marktführer), bieten Zonen eine brauchbare Möglichkeit, die vorhandene Hardware für mehrere solcher Applikationen zu nutzen. Daneben ist es vor allem die Isolierung der Zonen, die dieses Konzept unter dem Aspekt der Systemsicherheit attraktiv macht (Webservices ...).
Die Application Control Option des OSL Storage Clusters bindet Zonen wie gewöhnliche Applikationen in ihr Bedienkonzept ein. Sowohl das Aufsetzen von Zonen als auch Start, Stopp und Failover auf andere Rechner lassen sich über das Menüsystem bzw. CLI durchführen. Da auch das Handling der SC-Volumes, der Dateisysteme und Netzwerkadressen integriert ist, vereinfacht sich die Handhabung der Zonen deutlich. Wichtig dabei: bei Ausfall eines Rechners können Zonen problemlos auf ein geeignetes Zielsystem migrieren.
Bereits heute lassen sich Zonen (wie andere Applikationen auch) bestimmte Ressourcen (RIP, MEM) zuordnen, die dann bei der Verteilung der Applikationen im Cluster berücksichtigt werden (ressourcenbasiertes Selbstmanagement). In der zweiten Aprilhälfte 2006 wird dies dahingehend erweitert, dass die Ressourcennutzung aktiv gesteuert wird. Mit dem Start einer Zone wird die Aufteilung der CPU-Ressourcen so geändert, daß jeder Zone mindestens die über RIP definierte CPU-Leistung zur Verfügung steht. Über den Standardmechanismus hinaus werden automatisch die für das jeweilige System notwendigen Anpassungen vorgenommen. Egal, auf was für einem System die Anwendung läuft (4 oder 16 CPU), wird so z. B. für eine Anwendung, der 8 RIP* zugeordnet worden sind, sichergestellt, dass diese mdst. 8 RIP Rechenleistung erhält, bei nicht ausgelastetem System auch mehr.
Alle erforderlichen Änderungen am System werden automatisch beim Start der Zone über OSL Storage Cluster vorgenommen, so daß also nicht nur eine hohe Verfügbarkeit, sondern auch ein einfaches Handling erreicht wird (und das über Rechnergrenzen hinweg).
*RIP - Relative Integer-Performance
Die relative Integer-Performance wird von OSL Storage Cluster in einem eigenen Pseudo-Benchmark ermittelt und ermöglicht so eine Vergleichbarkeit unterschiedlicher CPU in Clustern mit unterschiedlichen CPU-Typen. 5 RIP entsprechen etwa der Integer-Performance eines Intel Pentium mit 500 MHz Taktung.