Solaris 10 Container Leitfaden - Funktionalitätsstand bis Solaris 10 10/09 und OpenSolaris 2009.06 -
Detlef Drewanz, Ulrich Gräf, u.v.a.
Sun Microsystems GmbH Stand 30.11.2009
Funktionsweisen
Anwendungsfälle
Best Practices
Kochbücher Version 3.1-de Solaris 10 Container Leitfaden - 3.1 Stand: 30.11.2009
Inhaltsverzeichnis Disclaimer...... VII Versionierung...... VII 1. Einführung...... 1 2. Allgemein...... 2 2.1. Solaris Container und Solaris Zonen...... 2 2.1.1. Überblick...... 2 2.1.2. Zonen und die Installation von Software...... 4 2.1.3. Zonen und Sicherheit...... 4 2.1.4. Zonen und Privilegien...... 4 2.1.5. Zonen und Ressource Management...... 5 2.1.5.1. CPU Ressourcen...... 5 2.1.5.2. Kontrolle von Memory Ressourcen...... 6 2.1.5.3. Kontrolle von Netzwerk Ressourcen (IPQoS = IP Quality of Services)...... 6 2.1.6. User Interfaces für Zonen...... 7 2.1.7. Zonen und Hochverfügbarkeit...... 7 2.1.8. Branded Zones (Linux und Solaris 8/Solaris 9 Kompatibilität)...... 7 2.1.9. Solaris Container Cluster (aka „zone cluster“)...... 8 2.2. Virtualisierungstechnologien im Vergleich...... 9 2.2.1. Domains/physikalische Partitionen...... 10 2.2.2. Logische Partitionen...... 11 2.2.3. Container (Solaris Zonen) in einem OS...... 12 2.2.4. Konsolidierung in einem Rechner...... 13 2.2.5. Zusammenfassung zu den Virtualisierungstechnologien...... 14 3. Anwendungsfälle...... 16 3.1. Grid Computing mit Isolation...... 16 3.2. Kleine Webserver...... 17 3.3. Multi-Netzwerk Konsolidierung...... 18 3.4. Multi-Netzwerk Monitoring...... 19 3.5. Multi-Netzwerk Backup...... 20 3.6. Konsolidierung Entwicklung/Test/Integration/Produktion...... 21 3.7. Konsolidierung von Testsystemen...... 22 3.8. Schulungssysteme...... 23 3.9. Server Konsolidierung...... 24 3.10. Vertraulichkeit von Daten und Prozessen...... 25 3.11. Testsysteme für Entwickler...... 26 3.12. Solaris 8 und Solaris 9 Container für die Entwicklung...... 27 3.13. Solaris 8 und Solaris 9 Container als Revisionssysteme...... 28 3.14. Hosting für verschiedene Firmen auf einem Rechner...... 29 3.15. SAP Portale in Solaris Containern...... 30 3.16. Upgrade- und Patchmanagement in einer virtuellen Betriebsumgebung...... 31 3.17. „Flying Zones“ - Service-orientierte Solaris Server Infrastruktur...... 32 3.18. Solaris Container Cluster (aka „zone cluster“)...... 33 4. Best Practices...... 34 4.1. Konzepte...... 34 4.1.1. Sparse-root Zonen...... 34 4.1.2. Whole-root Zonen...... 34 4.1.3. Vergleich Sparse-root Zone und Whole-root Zone...... 35 4.1.4. Software in Zonen...... 35
II Version 3.1-de Solaris 10 Container Leitfaden - 3.1 Stand: 30.11.2009
4.1.5. Softwareinstallationen in Solaris und Zonen...... 36 4.1.5.1. Softwareinstallation durch die globale Zone - Nutzung in allen Zonen...... 36 4.1.5.2. Softwareinstallation durch die globale Zone - Nutzung in einer lokalen Zone...... 36 4.1.5.3. Softwareinstallation durch die globale Zone - Nutzung in der globalen Zone...... 37 4.1.5.4. Installation durch die lokale Zone - Nutzung in der lokalen Zone...... 37 4.1.6. Storage-Konzepte...... 38 4.1.6.1. Storage für das root-Filesystem der lokalen Zonen...... 38 4.1.6.2. Storage für Daten...... 38 4.1.6.3. Storage für Programme/Applikationen...... 38 4.1.6.4. Rootplatten Layout...... 39 4.1.6.5. ZFS in einer Zone...... 39 4.1.6.6. Möglichkeiten zur Benutzung von ZFS in lokalen Zonen...... 40 4.1.6.7. NFS und lokale Zonen...... 40 4.1.6.8. Volume-Manager in lokalen Zonen...... 40 4.1.7. Netzwerk-Konzepte...... 41 4.1.7.1. Einführung Netzwerke und Zonen...... 41 4.1.7.2. Verwaltung der Netzwerk-Adressen für Zonen...... 41 4.1.7.3. Shared IP-Instanz und das Routing zwischen Zonen...... 41 4.1.7.4. Exclusive IP-Instanz...... 42 4.1.7.5. Firewalls zwischen Zonen (IP Filter)...... 42 4.1.7.6. Zonen und Limitierungen im Netzwerk...... 43 4.1.8. Zusätzliche Geräte (devices) in Zonen...... 44 4.1.8.1. Konfiguration von Geräten (Devices)...... 44 4.1.8.2. Statische Konfiguration von Geräten...... 44 4.1.8.3. Dynamische Konfiguration von Geräten...... 44 4.1.9. Separate Namensdienste in Zonen...... 45 4.1.9.1. hosts-Datenbank...... 45 4.1.9.2. User-Datenbank (passwd, shadow, user_attr)...... 45 4.1.9.3. Services...... 45 4.1.9.4. Projekte...... 45 4.2. Paradigmen...... 46 4.2.1. Delegation von Admin Rechten an die Applikations-Abteilung...... 46 4.2.2. Applikationen nur in lokalen Zonen...... 46 4.2.3. Eine Applikation pro Zone...... 47 4.2.4. Container im Cluster...... 47 4.2.5. Solaris Container Cluster...... 49 4.3. Konfiguration und Administration...... 50 4.3.1. Manuelle Konfiguration von Zonen mit zonecfg...... 50 4.3.2. Manuelle Installation von Zonen mit zoneadm...... 50 4.3.3. Manuelle De-Installation von Zonen mit zoneadm...... 50 4.3.4. Manuelles Entfernen einer konfigurierten Zone mit zonecfg...... 50 4.3.5. Duplizieren einer installierten Zone...... 50 4.3.6. Standardisiertes Erzeugen von Zonen...... 50 4.3.7. Automatische Konfiguration von Zonen per Script...... 51 4.3.8. Automatisiertes Provisionieren der Services...... 51 4.3.9. Installation und Administration einer Branded Zone...... 51 4.4. Lifecycle Management...... 52 4.4.1. Patchen eines Systems mit lokalen Zonen...... 52 4.4.2. Patchen mit Live Upgrade...... 53 4.4.3. Patchen mit Upgrade Server...... 53 4.4.4. Patchen mit zoneadm attach -u...... 53 4.4.5. Bewegen von Zonen zwischen Architekturen (sun4u / sun4v)...... 53
III Version 3.1-de Solaris 10 Container Leitfaden - 3.1 Stand: 30.11.2009
4.4.6. Neuinstallation und Service Provisionieren statt Patchen...... 54 4.4.7. Backup und Recovery von Zonen...... 54 4.4.8. Backup von Zonen mit ZFS...... 55 4.4.9. Migration (Umzug) einer Zone zu einem anderen System...... 55 4.4.10. Bewegen einer Zone innerhalb eines Systems...... 55 4.5. Management und Monitoring...... 55 4.5.1. Verwendung von Bootargumenten in Zonen...... 55 4.5.2. Konsolidierung von Log-Informationen von Zonen...... 56 4.5.3. Überwachung der Zonen-Auslastung...... 56 4.5.4. Extended Accounting mit Zonen...... 56 4.5.5. Auditing der Operationen in der Zone...... 56 4.5.6. DTrace von Prozessen in einer Zone...... 57 4.6. Ressource Management...... 58 4.6.1. Arten von Ressource Management...... 58 4.6.2. CPU Ressourcen...... 58 4.6.2.1. Kappung von CPU-Zeit für eine Zone...... 58 4.6.2.2. Allgemeine Ressource Pools...... 58 4.6.2.3. Fair Share Scheduler (FSS)...... 59 4.6.2.4. Fair Share Scheduler in einer Zone...... 59 4.6.2.5. Dynamische Ressource Pools...... 59 4.6.2.6. Light-Weight Processes (LWP)...... 59 4.6.3. Limitierung der Memory Ressourcen...... 60 4.6.3.1. Abschätzung des Speicherbedarfs für globale und lokale Zonen...... 60 4.6.3.2. Limitierung des Virtuellen Speicher...... 60 4.6.3.3. Limitieren des physikalischen Speicherbedarfs einer Zone...... 60 4.6.3.4. Limitieren von Locked Memory...... 61 4.6.4. Netzwerk Limitierung (IPQoS)...... 61 4.6.5. IPC Limits (Semaphore, Shared Memory, Message Queues)...... 61 4.6.6. Privilegien und Ressource Management...... 61 4.7. Solaris Container Navigator...... 62 5. Kochbücher...... 65 5.1. Installation und Konfiguration...... 65 5.1.1. Konfigurationsdateien...... 65 5.1.2. Besondere Kommandos für Zonen...... 66 5.1.3. Rootplattenlayout...... 68 5.1.4. Konfiguration einer Sparse-root Zone: Erforderliche Aktionen...... 69 5.1.5. Konfiguration einer Whole-root Zone: Erforderliche Aktionen...... 70 5.1.6. Installation einer Zone...... 71 5.1.7. Initialisierung von Zonen mit sysidcfg...... 71 5.1.8. Deinstallation einer Zone...... 72 5.1.9. Konfiguration und Installation einer Linux branded Zone mit CentOS...... 72 5.1.10. Konfiguration und Installation eines Solaris 8/Solaris9 Containers...... 73 5.1.11. Optionale Einstellungen...... 73 5.1.11.1. Automatisches Starten von Zonen...... 73 5.1.11.2. Privilegien-Set einer Zone verändern...... 73 5.1.12. Storage in einer Zone...... 74 5.1.12.1. Benutzung eines Raw-Device in einer lokalen Zone...... 74 5.1.12.2. Die globale Zone stellt der lokalen Zone ein Filesystem per lofs bereit...... 74 5.1.12.3. Die globale Zone mountet ein Filesystem beim Booten der lokalen Zone...... 75 5.1.12.4. Die lokale Zone mountet ein UFS-Filesystem von einem Device...... 75 5.1.12.5. User Level NFS-Server in einer lokalen Zone...... 76
IV Version 3.1-de Solaris 10 Container Leitfaden - 3.1 Stand: 30.11.2009
5.1.12.6. Ein DVD Laufwerk in der lokalen Zone benutzen...... 76 5.1.12.7. Dynamisches Konfigurieren von Geräten (Devices)...... 76 5.1.12.8. Mehrere Zonen teilen sich ein Filesystem...... 78 5.1.12.9. ZFS in einer Zone...... 78 5.1.12.10. User-Attribute für ZFS in einer Zone...... 78 5.1.13. Konfiguration einer Zone durch Kommando-Datei oder Template...... 79 5.1.14. Automatische Schnell-Installation von Zonen...... 79 5.1.15. Beschleunigtes automatisches Erstellen von Zonen auf einem ZFS-Dateisystem...... 80 5.1.16. Härten von Zonen...... 80 5.2. Netzwerk...... 81 5.2.1. Netzwerkkonfiguration für Shared IP-Instanzen ändern...... 81 5.2.2. Default Router für Shared-IP Instanz setzen...... 81 5.2.3. Netzwerkinterfaces für Exklusive-IP Instanzen...... 81 5.2.4. Netzwerkkonfiguration von Shared-IP Instanz auf Exklusive-IP Instanz ändern...... 82 5.2.5. IP Filter zwischen Shared-IP Zonen auf einem System...... 82 5.2.6. IP Filter zwischen Exclusive-IP Zonen auf einem System...... 83 5.2.7. Zonen, Netzwerke und Routing...... 83 5.2.7.1. Globale und lokale Zone mit gemeinsamem Netzwerk...... 83 5.2.7.2. Zonen in getrennten Netzwerksegmenten unter Nutzung der Shared-IP Instanz...... 84 5.2.7.3. Zonen in getrennten Netzwerksegmenten unter Nutzung der exklusiven IP-Instanzen...... 85 5.2.7.4. Zonen in getrennten Netzwerken unter Nutzung der Shared IP-Instanz...... 86 5.2.7.5. Zonen in getrennten Netzwerken unter Nutzung von exklusiven IP-Instanzen...... 87 5.2.7.6. Zonen mit Verbindung in unabhängige Kunden-Netzwerke unter Nutzung der shared IP-Instanz...... 88 5.2.7.7. Zonen mit Verbindung in unabhängige Kunden-Netzwerke unter Nutzung von exklusiven IP-Instanzen....90 5.2.7.8. Verbindung von Zonen über externe Router unter Nutzung der shared IP-Instanz...... 91 5.2.7.9. Verbindung von Zonen über einen externen Load-Balancer unter Nutzung von exklusiven IP-Instanzen...93 5.3. Lifecycle Management...... 95 5.3.1. Boot einer Zone...... 95 5.3.2. Bootargumente in Zonen...... 95 5.3.3. Softwareinstallation per mount...... 96 5.3.4. Software Installation mit Provisioning System...... 97 5.3.5. Migration einer Zone zwischen Systemen...... 97 5.3.6. Bewegen einer Zone in einem System...... 98 5.3.7. Duplizieren von Zonen mit zoneadm clone...... 99 5.3.8. Duplizieren von Zonen mit zoneadm detach/attach und zfs clone...... 101 5.3.9. Bewegen einer Zone zwischen einem sun4u und einem sun4v System...... 102 5.3.10. Herunterfahren einer Zone...... 104 5.3.11. Die Benutzung von Live Upgrade zum Patchen eines Systems mit lokalen Zonen...... 104 5.4. Management und Monitoring...... 106 5.4.1. DTrace in einer lokalen Zone...... 106 5.4.2. Accounting über eine Zone...... 106 5.4.3. Audit einer Zone...... 106 5.5. Ressource Management...... 107 5.5.1. Begrenzung von /tmp-Größe in einer Zone...... 107 5.5.2. Limitieren des CPU Verbrauchs einer Zone (CPU-Capping)...... 107 5.5.3. Ressource Pools mit Prozessor Sets...... 107 5.5.4. Fair Share Scheduler...... 108 5.5.5. Statisches CPU Ressource Management zwischen Zonen...... 108 5.5.6. Dynamisches CPU Ressource Management zwischen Zonen...... 108 5.5.7. Statisches CPU Ressource Management in einer Zone...... 108 5.5.8. Dynamisches CPU Ressource Management in einer Zone...... 109
V Version 3.1-de Solaris 10 Container Leitfaden - 3.1 Stand: 30.11.2009
5.5.9. Dynamische Ressource Pools für Zonen...... 109 5.5.10. Physikalischen Hauptspeicherverbrauch eines Projektes begrenzen...... 110 5.5.11. Anwendung von Memory Ressource Management für Zonen...... 110 Anhang...... 112 A. Solaris Container in OpenSolaris...... 112 A.1. OpenSolaris allgemein...... 112 A.2. ipkg-Branded Zones...... 112 A.3. Kochbuch: Konfiguration einer ipkg-Zone...... 113 A.4. Kochbuch: Installation einer ipkg-Zone...... 113 B. Literatur...... 114
VI Version 3.1-de Solaris 10 Container Leitfaden - 3.1 Disclaimer Stand: 30.11.2009
Disclaimer
Die Sun Microsystems GmbH übernimmt keine Gewähr für die Vollständigkeit und die Fehlerfreiheit der in diesem Dokument enthaltenen Informationen und Beispiele. Versionierung
Version Inhalt Wer 3.1 30.11.2009 Detlef Drewanz Abstimmung mit dem Inhalt des „Solaris Container Guide 3.1“ Ulrich Gräf Inhaltsverzeichnis in HTML für einfacheres Navigieren im Dokument Korrektur „Patchen von Systemen mit lokalen Zone“ Korrektur „Patchen mit zoneadm attach -u“ Korrektur Solaris Container Navigator 3.0 19.06.2009 Detlef Drewanz, Allgemeine Korrekturen Uwe Furchheim, Ergänzungen im Allgemeinen Teil, Ressource Management Ulrich Gräf, Ergänzungen Patch Management von Zonen Franz Haberhauer, Formatierung: URLs und Querverweisen zur besseren Lesbarkeit Joachim Knoke, Formatierung: Nummerierung repariert Hartmut Streppel, Thomas Wagner,
Einfügung: Möglichkeiten zur Benutzung von ZFS in lokalen Zonen Heiko Stein 3.0 Draft 1 10.06.2009 Mehr Querverweise im Dokument Dirk Augustin, Allgemeine Korrekturen Detlef Drewanz, Einfügung: Solaris Container Navigator Ulrich Gräf, Einarbeitung Funktionalitäten Solaris 10 5/08 + 10/08 + 5/09 Hartmut Streppel Einfügung: Firewall zwischen Zonen Überarbeitung: Zonen und ZFS Überarbeitung: Storage Konzepte Überarbeitung: Netzwerk Konzepte Einfügung: Dynamisches Konfigurieren von Geräten in Zonen Überarbeitung: Ressource Management Ergänzung: Patchen von Zonen Überarbeitung: Zonen und Hochverfügbarkeit Einfügung: Solaris Container Cluster Einfügung: Solaris Container in OpenSolaris Einfügung: Upgrade- und Patchmanagement in einer virtuellen Betriebsumgebung 2.1 13.02.2008 Einarbeitung von Korrekturen (tagged vlanID) Detlef Drewanz, Ulrich Gräf 2.0 21.01.2008 Einarbeitung von Kommentaren zu 2.0-Draftv27 Detlef Drewanz, Ulrich Gräf Einfügung: Konsolidierung von Log-Informationen Einfügung: Kochbüchern für Ressource Management 2.0-Draftv27 11.01.2008 Einarbeitung von Kommentaren zu 2.0-Draftv22 Detlef Drewanz, Ulrich Gräf Einarbeitung Live Upgrade und Zonen Einfügung von einigen Querverweisen
Beschleunigtes automatisches Installieren von Zonen auf einem ZFS- Bernd Finger, Ulrich Gräf Dateisystem 2.0-Draftv22 20.12.2007 Einarbeitung Ressource Management Detlef Drewanz, Ulrich Gräf Einarbeitung von Solaris 10 08/07 Einarbeitung von Solaris 10 11/06 Einarbeitung von Kommentaren Gesamte Überarbeitung des Leitfaden
Einarbeitung „SAP Portale in Containern“ Dirk Augustin Einarbeitung „Flying Zones“ Oliver Schlicker Überarbeitung „Zonen und Hochverfügbarkeit“ Detlef Ulherr, Thorsten Früauf 1.3 07.11.2006 Zeichnungen 1 - 6 als Image Detlef Drewanz 1.2 06.11.2006 Verallgemeinerung Virtualisierung Detlef Drewanz, Ulrich Gräf Weitere Netzwerkbeispiele
VII Version 3.1-de Solaris 10 Container Leitfaden - 3.1 Disclaimer Stand: 30.11.2009
Version Inhalt Wer 1.1 27.10.2006 Versionierungstabelle umgestellt Detlef Drewanz (das Neueste nach oben) Literaturangabe ergänzt Hardening von Zonen ergänzt
1.0 24.10.2006 Feedback eingearbeitet, Korrekturen Detlef Drewanz Anwendungsfälle und Netzwerk
Zonen im Cluster hinzugefügt Thorsten Früauf/Detlef Ulherr
Komplette Überarbeitung verschiedener Kapitel Ulrich Gräf Draft 2.2 1. Netzbeispiel, Korrekturen 31. 07. 2006 Ulrich Gräf Draft 2.0 2. Draft veröffentlicht – 28.07.2006 Detlef Drewanz, Ulrich Gräf Draft 1.0 1. Draft (intern) - 28.06.2006 Detlef Drewanz, Ulrich Gräf
VIII Version 3.1-de Solaris 10 Container Leitfaden - 3.1 1. Einführung Stand: 30.11.2009 1. Einführung
[dd/ug] Dieser Leitfaden ist über Solaris Container, wie sie funktionieren und wie man sie benutzt. Obwohl der Leitfaden ursprünglich in deutsch entwickelt wurde, bieten wir ab Version 3.1 erstmals eine englische Version [25] an. Mit der Verfügbarkeit von Solaris 10 am 31. Januar 2005 ist durch Sun Microsystems ein Betriebssystem mit bahnbrechenden Neuerungen bereitgestellt worden. Eine dieser Neuerungen sind die Solaris Container, die unter anderem zur Konsolidierung und Virtualisierung von OS- Umgebungen, für die Isolation von Anwendungen und zum Ressource Management eingesetzt werden können. Solaris Container tragen erheblich zur fortschrittlichen Umgestaltung von IT- Prozessen und -Umgebungen, sowie zu Kosteneinsparungen im IT-Betrieb bei. Die Nutzung dieser neuen Möglichkeiten erfordert Know-How, Entscheidungshilfen und Beispiele, die wir in diesem Leitfaden zusammengefasst haben. Er richtet sich an Entscheidungsträger, RZ-Leiter, IT-Fachgruppen und IT-Administratoren. Das Dokument gliedert sich in die Kapitel Einführung, Allgemeiner Teil, Anwendungsfälle, Best Practices, Kochbücher und eine Literaturauflistung. Der kurzen Einführung folgt ein allgemeiner Teil mit der Darstellung heutiger RZ-typischer Anforderungen in Bezug auf Virtualisierung und Konsolidierung, sowie der Darstellung und dem Vergleich der Solaris Container Technologie. Im Anschluss daran werden in verschiedenen Anwendungsfällen die Einsatzmöglichkeiten für Solaris Container diskutiert. Deren konzeptionelle Umsetzung wird anhand von Best Practices dargestellt. Konkrete Beispiele zeigen im Kapitel Kochbücher die Kommandos zur Realisierung der Best Practices. Alle Kochbücher wurden durch die Autoren selbst erprobt und verifiziert. Der Anhang zeigt die Besonderheiten von Solaris Container mit OpenSolaris. Dieser Leitfaden ist als Referenz-Dokument gedacht. Es ist zwar möglich, aber nicht zwingend notwendig, den Leitfaden von vorne nach hinten zu lesen. Ein RZ-Leiter wird beispielsweise den Überblick über die Solaris Container-Technologie erwerben wollen oder sich die Anwendungsfälle ansehen. Ein IT-Architekt sieht sich die Best Practices an, um Lösungen zu bauen, währenddessen ein System-Administrator die Kommandos in den Kochbüchern ausprobiert, um Praxis zu gewinnen. Daher bietet das Dokument für jeden etwas. Vielen Dank an alle diejenigen, die durch Bemerkungen, Beispiele und Zusätze zu diesem Dokument beigetragen haben. Ein besonderer Dank geht an die Kollegen (alphabetisch): Dirk Augustin[da], Bernd Finger[bf], Constantin Gonzalez, Uwe Furchheim, Thorsten Früauf[tf], Franz Haberhauer, Claudia Hildebrandt, Kristan Klett, Joachim Knoke, Matthias Pfützner, Roland Rambau, Oliver Schlicker[os], Franz Stadler, Heiko Stein[hes], Hartmut Streppel[hs], Detlef Ulherr[du], Thomas Wagner und Holger Weihe.
Für Rückmeldungen und Anregungen stehen die Autoren gerne zur Verfügung.
Berlin und Langen im November 2009 Detlef Drewanz ([email protected]), Ulrich Gräf ([email protected])
1 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 2. Allgemein Stand: 30.11.2009 2. Allgemein
2.1. Solaris Container und Solaris Zonen 2.1.1. Überblick [ug] Solaris Zonen ist die Bezeichnung für eine virtualisierte Ausführungsumgebung - eine Virtualisierung auf Betriebssystem-Ebene (im Gegensatz zur HW-Virtualisierung). Solaris Container sind Solaris Zonen mit Ressource Management. Der Begriff wird häufig (auch in diesem Leitfaden) als Synonym mit Solaris Zonen benutzt. Das Ressource Management wurde bereits mit Solaris 9 eingeführt und erlaubt eine Begrenzung von CPU-, Hauptspeicher- und Netzwerk-Ressourcen. Solaris Zonen sind eine Virtualisierung auf der Schnittstelle zwischen dem Betriebssystem und der Applikation. • Es gibt eine globale Zone, die den Kernel und alle Treiber enthält, sowie alle Geräte, Filesysteme und nicht-globalen Zonen kennt. • Zusätzlich können lokale Zonen (non-global) als virtuelle Ausführungsumgebungen definiert werden. • Alle lokalen Zonen nutzen den Betriebssystemkern der globalen Zone und sind damit Teil einer einzigen Betriebssystem-Installation - im Unterschied zur HW-Virtualisierung, wo mehrere Betriebssysteme auf einer virtualisierten Hardware gestartet werden. • Alle gemeinsam genutzten (shared) Objekte (Programme, Bibliotheken, der Kernel) werden nur einmal geladen; daher ist im Unterschied zur HW-Virtualisierung der Mehrverbrauch bezüglich Hauptspeicher sehr gering. • Bezüglich Filesystem ist eine lokale Zone von der globalen Zone getrennt. D. h. sie benutzt ein Unterverzeichnis der globalen Zone als root-Verzeichnis (wie bei chroot-Umgebungen). • Eine Zone kann eine oder mehrere eigene Netzwerk-Adressen und -Interfaces haben. • Physikalische Geräte sind in den lokalen Zonen nicht sichtbar (Standard), können jedoch optional konfiguriert werden. • Lokale Zonen haben eigene Umgebungs-Einstellungen, z.B. für den Nameservice. • Die lokalen Zonen sind bezüglich Prozessen untereinander und gegen die globale Zone abgetrennt, d.h. eine lokale Zone kann die Prozesse einer anderen Zone nicht sehen. • Die Abtrennung erstreckt sich auch auf den gemeinsam genutzten Hauptspeicher (Shared Memory) und logische oder physikalische Netzwerk-Interfaces. • Der Zugriff auf eine andere lokale Zone auf dem selben Rechner ist daher nur über das Netzwerk möglich. • Die globale Zone kann zur Steuerung und Überwachung (Accounting) alle Prozesse der lokalen Zonen sehen.
App
Lokale Lokale Lokale Zone Zone Zone
Globale Zone OS
Server
Zeichnung 1: [dd] Schematische Darstellung von Zonen
2 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 2. Allgemein Stand: 30.11.2009 Eine lokale Zone ist also eine separiert nutzbare Solaris-Umgebung, welche von den anderen Zonen getrennt ist. Gleichzeitig werden viele Ressourcen der Hardware und des Betriebssystems gemeinsam mit anderen lokalen Zonen genutzt, wodurch der Mehraufwand zur Laufzeit gering ist. Lokale Zonen führen dieselbe Solaris-Version wie die globale Zone aus. Alternativ können in sogenannten Branded Zones auch virtuelle Ausführungsumgebungen für ältere Solaris-Versionen (SPARC: Solaris 8 und 9) oder andere Betriebssysteme (x86: Linux) installiert werden. Hierbei wird - im Gegensatz zur einer Emulation - die Original-Umgebung auf dem Solaris 10 Kern der globalen Zone ausgeführt. Weitere Details sind in der folgenden Tabelle zusammengefasst: Funktionalität Bemerkung System Die Einstellungen in /etc/system gelten für den Kernel, der von allen Zonen Einstellungen: genutzt wird. Jedoch können die wichtigsten Einstellungen früherer Solaris Versionen (Shared Memory, Semaphoren und Message Queues) seit Solaris 10 durch den Solaris Ressource Manager im laufenden Betrieb verändert werden. Shared Kernel: Der Kernel wird von der globalen Zone und den lokalen Zonen gemeinsam genutzt. Der durch das OS initiierte Mehraufwand fällt nur einmal an. Die Kosten für eine lokale Zone sind daher, gemessen an Hauptspeicher-Bedarf, CPU- Leistung und Plattenplatz gering. Shared In Unix werden alle Objekte wie Programme, Dateien und shared Libraries nur Objekte: einmal als shared Memory Segment geladen, wodurch insgesamt die Performance verbessert wird. Dies erstreckt sich bei Solaris 10 auch über die Zonen; d.h. egal wie häufig z.B. ein Programm oder eine shared Library in Zonen benutzt wird: sie belegt im Hauptspeicher nur einmal Platz. (Dieses Sharing ist bei virtuellen Maschinen nicht möglich.) Shared Weitere Teile des Dateibaumes (Filesysteme oder Verzeichnisse) können von der Plattenplatz: globalen Zone aus einer oder mehreren lokalen Zonen zugeordnet werden. Separation: Der Zugriff auf die Ressourcen der globalen Zone oder anderer lokalen Zonen, soweit nicht explizit so konfiguriert (Geräte, Speicher), wird verhindert. Softwarefehler werden durch Fehlerisolation auf die jeweilige lokale Zone begrenzt. Physikalische Die Administration von physikalischen Geräten erfolgt von der globalen Zone aus. Geräte: Die lokalen Zonen haben auf die Zuteilung dieser Geräte keinen Zugriff. Zugeordnete In der Standardkonfiguration einer lokalen Zone sind keine physikalischen Geräte Geräte: enthalten. Geräte (z.B. Platten, Volumes, DVD-Laufwerke, ...) können durch Konfiguration einer oder mehreren lokalen Zonen zugeordnet werden. So lassen sich auch gesonderte Treiber nutzen. Netzwerk: Zonen haben eigene IP-Adressen auf einem oder mehreren virtuellen oder physikalischen Interfaces. Die Netzwerkkommunikation zwischen Zonen erfolgt nach Möglichkeit über die gemeinsam genutzten Netzwerk-Schichten oder bei der Nutzung von exklusive IP-Instanzen über externe Netzwerkverbindungen. Prozess: Jede lokale Zone sieht nur ihre eigenen Prozesse. Die globale Zone sieht alle Prozesse der lokalen Zonen. Namens- Lokale Zonen verfügen über eine unabhängige Namensumgebung mit Hostnamen, umgebung: Netzwerkdiensten, Nutzern, Rollen und Prozessumgebungen. Eine Zone kann zur Nutzung der Namens-Datenbank aus lokalen Dateien konfiguriert sein, eine andere auf dem gleichen Rechner kann z.B. LDAP oder NIS nutzen. Filesystem: Der sichtbare Teil des Filesystems der lokalen Zone kann auf einen oder mehrere Teilbäume der globalen Zone eingeschränkt werden. Die Dateien in der lokalen Zone können auf Basis von Verzeichnissen shared mit der globalen Zone oder in Kopie konfiguriert werden. Patches: Für Solaris Packages, die in der lokalen Zone als Kopie installiert sind, können auch dort separat Patches installiert werden. Der Patchlevel der Systempatches sollte gleich gehalten werden, da alle Zonen eines Systems den selben Kernel benutzen. Root Eine lokale Zone hat einen individuellen root-Account (Zone-Administrator). Daher Delegation: kann die Administration von Anwendungen und Diensten in einer lokalen Zone vollständig an andere Personen delegiert werden - inklusive root-Anteil. Die Betriebssicherheit in der globalen Zone oder der anderen lokalen Zonen wird dadurch nicht beeinflusst. root der globalen Zone hat generellen Zugang zu allen lokalen Zonen.
Tabelle 1: [ug] Eigenschaften von Solaris 10 Zonen
3 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 2. Allgemein Stand: 30.11.2009
2.1.2. Zonen und die Installation von Software [dd] Es gibt zwei Arten, Software in Zonen bereitzustellen: 1. Software wird im pkg-Format bereitgestellt. Wird diese Software mit pkgadd in der globalen Zone installiert, so steht diese auch anderen lokalen Zonen zur Verfügung. Dadurch wird die Installation und Pflege von Software erheblich vereinfacht, da - auch wenn viele Zonen installiert sind - die Pflege der Software zentral von der globalen Zone aus vorgenommen werden kann. 2. Software kann exklusiv für eine lokale oder für die globale Zone installiert werden, um z.B. in einer Zone unabhängig von anderen Zonen Änderungen an der Software vornehmen zu können. Dieses kann durch die Installation mit speziellen Optionen von pkgadd oder durch spezielle Softwareinstallationsformen, z.B. als tar-Archiv erreicht werden. In jedem Falle werden jedoch der Kernel und die Treiber von Solaris von allen Zonen gemeinsam genutzt, können aber nur in der globalen Zone direkt installiert und modifiziert werden. 2.1.3. Zonen und Sicherheit [dd] Durch die Bereitstellung eigener root-Verzeichnisse für jede Zone, können durch die lokalen Namensumgebungen in den Zonen eigene Festlegungen zu den Sicherheitseinstellungen getroffen werden (RBAC - Role Based Access Control, passwd-Datenbank). Weiterhin steht in jeder Zone eine eigene Nutzerdatenbank mit eigenen Benutzerkonten zur Verfügung. Dadurch wird es möglich, getrennte Nutzerumgebungen für jede Zone aufzubauen, sowie für jede Zone eigene Administrator- Anmeldungen einzuführen. Solaris 10 5/08 ist wie bereits frühere Solaris-Versionen nach Common Criteria EAL4+ zertifiziert. Diese Zertifizierung wurde durch die Canadian CCS durchgeführt. Canadian CCS ist Mitglied der Gruppe der Zertifizierungsstellen von westlichen Staaten, bei der auch das BSI (Bundesamt für Sicherheit in der Informationstechnik) Mitglied ist. Diese Zertifizierung wird auch vom BSI anerkannt. Bestandteil der Zertifizierung sind Einbruchssicherheit, Separation und - neu in Solaris 10 - die Abgrenzung der Zonen. Details dazu sind nachlesbar unter: http://www.sun.com/software/security/securitycert/ Solaris Trusted Extensions erlauben es Anwendern, die spezifischen Gesetzen oder Datenschutzanforderungen unterliegen, Labeling Features zu nutzen, die bisher nur in hochspezialisierten Betriebssystemen und Appliances enthalten waren. Zur Realisierung von Labeled Security werden sogenannte Compartments verwendet. Diese Compartments werden bei den Solaris Trusted Extensions durch Solaris Zonen realisiert. 2.1.4. Zonen und Privilegien [dd] Lokale Zonen verfügen über weniger mögliche Prozess-Privilegien als die globale Zone, wodurch die Ausführung einiger Kommandos innerhalb einer lokalen Zone nicht möglich ist. Zu den Einschränkungen gehören u.a.: • Konfiguration von Swap-space und Prozessorsets • Veränderung des Prozess Schedulers und des Shared Memory • Anlegen von Device Files • Laden und Entladen von Kernel Modulen • Bei gemeinsam genutzten IP-Instanzen: – Zugriff auf die physikalische Netzwerkschnittstelle – Setzen von IP-Adressen Seit Solaris 10 11/06 können lokalen Zonen bei der Zonenkonfiguration erweiterte Prozess-Privilegien zugeordnet werden, die erweiterte Zugriffsmöglichkeiten der lokalen Zonen ermöglichen (aber nicht alle). Die möglichen Kombinationen und benutzbaren Privilegien in Zonen sind hier dargestellt: http://docs.sun.com/app/docs/doc/817-1592/6mhahuotq?a=view
4 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 2. Allgemein Stand: 30.11.2009
2.1.5. Zonen und Ressource Management [ug] In Solaris 9 wurde das Ressource Management auf der Basis von Projekten, Tasks und Ressource Pools eingeführt. In Solaris 10 kann das Ressource Management auch auf Zonen angewendet werden. Kontrollierbar sind die folgenden Ressourcen: • CPU Anteile (Prozessor-Sets, CPU-Capping und Fair-Share-Scheduler) • Speicher-Verbrauch (Realer Speicher, Virtueller Speicher, Shared Segmente) • Kontrolle des Netzwerk-Verkehrs (IPQoS = IP Quality of Service) • Zonen-spezifische Einstellungen für Shared Memory, Semaphore, Swap (System V IPC Ressource Controls ) 2.1.5.1. CPU Ressourcen [ug] Mit Zonen sind 3 Stufen des Ressource Management möglich: • Partitionierung der CPUs in Prozessor-Sets, die Ressource Pools zugeordnet werden können. Ressource-Pools werden lokalen Zonen zugeordnet und bestimmen die nutzbare CPU Menge. • Einsatz des Fair-Share-Scheduler (FSS) in einem Ressource-Pool, der von einer oder mehreren lokalen Zonen benutzt wird. Dieser erlaubt die feingranulare Zuteilung von CPU-Ressourcen zu Zonen in einem definierten Verhältnis, sobald Zonen um CPU-Zuteilungen konkurrieren. Dies ist der Fall, wenn die Systemauslastung bei 100% ist. So stellt der FSS die Antwortzeit von Zonen sicher. • Einsatz des FSS in einer lokalen Zone. Dies erlaubt die feingranulare Zuteilung von CPU-Ressourcen zu Projekten (Gruppen von Prozessen) in einem definierten Verhältnis, wenn Projekte um CPU-Zuteilungen konkurrieren, die Auslastung der für diese Zone verfügbaren CPU-Zeit also bei 100% liegt. So stellt der FSS die Antwortzeit von Prozessen sicher. Prozessor-Sets in einem Ressource-Pool Einer lokalen Zone lässt sich genau wie einem Projekt ein Ressource Pool zuordnen, in dem alle Prozesse der Zone ablaufen (zonecfg: set pool=). Man kann CPUs einem Ressource Pool zuordnen. Dann laufen die Prozesse der Zonen nur auf den dem Ressource-Pool zugeordneten CPUs ab. Einem Ressource-Pool können auch mehrere Zonen (oder auch Projekte) zugeordnet sein, die sich die CPU-Ressourcen des Ressource Pools teilen. Der häufigste Fall ist, je Zone einen eigenen Ressource-Pool mit CPUs zu erzeugen. Dann kann als Vereinfachung die Anzahl der CPUs für eine Zone in der Zonenkonfiguration angegeben werden (zonecfg: add dedicated-cpu). Beim Start einer Zone wird automatisch ein temporärer Ressource-Pool erzeugt, der die konfigurierte Zahl von CPUs enthält. Beim Shutdown der Zone werden Ressource-Pool und CPUs wieder freigegeben (Seit Solaris 10 8/07). Fair-Share-Scheduler in einem Ressource-Pool In dem Fall, dass mehrere Zonen in einem Ressource Pool miteinander laufen, lässt sich mit dem Fair Share Scheduler (FSS) die Zuordnung von CPU-Ressourcen innerhalb eines Ressource Pools steuern . Dazu kann man jeder Zone bzw. jedem Projekt einen Anteil (share) zuordnen. Die Einstellungen der Zonen und der Projekte in einem Ressource Pool werden dazu herangezogen, die Kontrolle der CPU-Ressourcen dann vorzunehmen, wenn die Applikationen der lokalen Zonen bzw. die Projekte um die CPU Zeiten konkurrieren: • Ist die Auslastung des Prozessor-Sets unter 100%, dann wird keine Steuerung vorgenommen, da noch freie CPU Leistung zur Verfügung steht. • Liegt die Auslastung bei 100%, dann wird der Fair-Share-Scheduler aktiv, indem die Priorität der beteiligten Prozesse so verändert wird, dass die zugeteilte CPU-Leistung einer Zone oder eines Projektes dem definierten Anteil entspricht. • Der definierte Anteil berechnet sich aus dem Share-Wert einer aktiven Zone (oder eines Projektes) dividiert durch die Summe der Shares aller aktiven Zonen/Projekte. Die Zuordnung ist dynamisch im laufenden Betrieb veränderbar. CPU-Ressource Kontrolle in einer Zone In einer lokalen Zone ist es zusätzlich möglich, Projekte und Ressource-Pools zu definieren und die Zuordnung von CPU-Ressourcen mittels FSS auf die in der Zone laufenden Projekte anzuwenden (siehe voriger Absatz).
5 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 2. Allgemein Stand: 30.11.2009
CPU-Capping Der maximale CPU-Verbrauch von Zonen kann eingestellt werden (cpu-caps). Diese Einstellung ist ein absolutes Limit bezüglich der verbrauchten CPU-Leistung und kann auf 1/100 CPUs genau eingestellt werden (ab Solaris 10 5/08). Mit dieser Konfigurationsmöglichkeit kann man die Zuordnung erheblich feiner einstellen, als mit Prozessor-Sets (1/100 CPU statt 1 CPU). Weiterhin bietet CPU-Capping eine weitere Kontrollmöglichkeit, wenn mehrere Zonen in einem Ressourcenpool laufen (mit oder ohne FSS), um von Anfang an alle Nutzer auf die später zur Verfügung stehende Leistung zu limitieren. 2.1.5.2. Kontrolle von Memory Ressourcen [ug] In Solaris 10 (auch in einem Update von Solaris 9) ist der Hauptspeicher-Verbrauch auf der Ebene von Zonen, Projekten und Prozessen begrenzbar. Dies wird mit dem sogenannten Ressource- Capping-Daemon (rcapd) realisiert. Für die entsprechenden Objekte wird ein Limit für den Realspeicherverbrauch definiert. Steigt der Verbrauch eines der Projekte über das definierte Limit an, veranlasst der rcapd das Auslagern von wenig genutzten Hauptspeicher-Seiten von Prozessen. Als Messgröße wird die Summe des Platzverbrauches der Prozesse herangezogen. So wird der definierte Hauptspeicher-Bedarf eingehalten. Die Leistung der Prozesse in dem entsprechenden Objekt sinkt, da sie gegebenenfalls Seiten wieder einlagern müssen, wenn die Speicherbereiche wieder benutzt werden. Eine ständige Auslagerung von Hauptspeicherseiten ist ein Indiz für eine zu geringe Menge an verfügbarem Hauptspeicher oder zu knappen Einstellungen oder die Anwendung benötigt mehr als die eingestellte Menge Als Vereinfachung sind seit Solaris 10 8/07 Memory Limits für jede Zone einstellbar. Man kann die Menge des genutzten realen Speichers (physical), den virtuellen Speicher (swap) und von locked Segmenten (nicht auslagerungsfähige Hauptspeicherseiten, Shared-Memory Segmente) begrenzen. Die Einstellungen für virtuellen und locked Speicher sind harte Limits, d.h. wenn der entsprechende Wert erreicht wird, können die Applikationen keinen weiteren Speicher anfordern. Das Limit für den realen Speicher wird hingegen von dem rcapd überwacht, der bei Überschreitung Hauptspeicherseiten sukzessive auslagert.
2.1.5.3. Kontrolle von Netzwerk Ressourcen (IPQoS = IP Quality of Services) [ug] In Solaris 10 (auch Solaris 9) ist es möglich, den Netzwerk-Verkehr zu klassifizieren und die Datenrate der Klassen zu kontrollieren. Ein Beispiel ist die Bevorzugung des Netzwerk-Verkehrs eines Webservers vor dem Netzwerk Backup. Wenn der Netzwerk-Backup läuft, soll der Dienst am Kunden darunter nicht leiden. Die Konfiguration erfolgt mit Regeln in einer Datei, die mit dem Kommando ipqosconf aktiviert wird. Die Regeln bestehen aus einem Teil, mit dem der Netzwerkverkehr klassifiziert wird und aus Aktionen, mit denen die Datenrate / Burstrate gesteuert werden kann. Die Klassifizierung kann nach einigen oder allen der folgenden Parametern erfolgen: • Adresse des Senders oder Empfängers • Port-Nummer des Empfängers • Datenverkehr Typ (UDP,TCP) • User-ID des lokalen Prozesses • Projekt des lokalen Prozesses (/etc/project) • TOS Feld des IP-Verkehrs (Veränderung Priorität in einer laufenden Verbindung)
6 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 2. Allgemein Stand: 30.11.2009
2.1.6. User Interfaces für Zonen [dd] Für die Arbeit mit Zonen und Containern stehen verschiedene Werkzeuge zur Verfügung. Solaris liefert selbst eine Reihe von Command Line Interface (CLI)-Tools wie zoneadm, zonecfg und zlogin mit denen auf der Kommandozeile oder in Scripten die Konfiguration und Installation von Zonen vorgenommen werden kann. Als Grafisches User Interface (GUI) steht der Solaris Container Manager (http://www.sun.com/software/products/container_mgr/) zur Verfügung. Dabei handelt es sich um ein separates Produkt, das zusammen mit dem Sun Management Center (SunMC) betrieben wird. Der Container Manager gestattet durch sein Nutzerinterface eine einfache und schnelle Neuerzeugung, Umkonfiguration oder Migration von Zonen und eine effektive Benutzung des Ressource Managements. Webmin stellt mit dem Zonenmodule ein Browser User Interface (BUI) zur Installation und dem Management von Zonen zur Verfügung. Das Module kann unter http://www.webmin.com/standard.html als zones.wbm.gz heruntergeladen werden. 2.1.7. Zonen und Hochverfügbarkeit [tf/du/hs] Ein einzelnes System hat bei allen vorhandenen RAS-Fähigkeiten nur die Verfügbarkeit eines Rechners und reduziert sich mit der Anzahl der Komponenten einer Maschine (MTBF) Ist diese Verfügbarkeit nicht ausreichend, so kann man mit dem HA Solaris Container Agenten sogenannte Failover Zonen implementieren und so Zonen zwischen Cluster Knoten schwenken (ab Sun Cluster 3.1 08/05). Damit erhöht sich die Verfügbarkeit des Gesamtsystems erheblich. Zusätzlich wird hier aus einem Container ein flexibler Container. Das heißt, es ist völlig unerheblich auf welchem der am Cluster beteiligten Rechner der Container abläuft. Ein Verschieben des Containers ist manuell durch administrative Aktionen oder automatisch bei Ausfall eines Rechners möglich. Alternativ ist mit dem HA Solaris Container Agenten auch möglich, lokale Zonen mitsamt ihren Services zu starten und zu stoppen. D.h. Es existieren identische Zonen auf mehreren Rechnern, mit identischen Services, die keinen(!) shared Storage haben. Da jetzt kein Failover einer Zone möglich ist, da der Zonenrootpfad nicht geschwenkt werden kann, ist konfigurierbar, dass die eine Zone gestoppt und anschließend die identische auf einem anderen System gestartet wird. Eine weitere Möglichkeit bieten Container Cluster (seit Sun Cluster 3.2 1/09). In der globalen Zone ist ein Sun Cluster installiert, in dem virtuelle Cluster konfiguriert werden können. Die virtuellen Cluster bestehen aus virtuellen Rechner-Knoten, die lokale Zonen sind. Die Administration kann dem Betreiber der Zonen übertragen werden. (siehe 2.1.9 Solaris Container Cluster (aka „zone cluster“) ). 2.1.8. Branded Zones (Linux und Solaris 8/Solaris 9 Kompatibilität) [dd/ug] Mit Branded Zones ist es möglich, in einer Zone eine andere OS-Umgebung laufen zu lassen als in der globalen Zone installiert ist (BrandZ, seit Solaris 10 8/07) Branded Zones erweitern die Zonen-Konfiguration wie folgt: • Ein Brand ist ein Zonenattribut. • Jeder Brand enthält Mechanismen zur Installation einer Branded Zone. • Jeder Brand kann seine eigenen Pre-/Post-Boot Verfahren benutzen. Zur Laufzeit werden die Systemaufrufe abgefangen und entweder an das Solaris weitergeleitet oder emuliert. Die Emulation erfolgt durch Module in Bibliotheken, die im Brand mit enthalten sind. Diese Konstruktion hat den Vorteil, dass ohne Änderung des Solaris Kernels leicht weitere Brands eingeführt werden können. Zur Zeit gibt es die folgenden Brands: • native: Brand für Zonen mit dem Solaris aus der Globalen Zone • lx: Solaris Container for Linux Applications (abgekürzt: SCLA) Hiermit können unter Solaris auf x86-Systemen unmodifizierte 32-Bit Linux-Programme benutzt werden. Dazu muss in der Zone eine 32-Bit Linux-Distribution installiert werden, die einen Linux 2.4 Kernel benutzen kann. In der Zone können dann die benötigten Linux- Programme benutzt und/oder installiert werden. Die Linux-Distribution und Lizenz ist selbst nicht in Solaris enthalten und muss in jeder Zone installiert werden Neuinstallation oder Kopie einer bestehenden Installation). Die folgenden Linux Distributionen funktionieren: – CentOS 3.5 – 3.8, RedHat Linux 3.5 - 3.8 (zertifiziert) – Debian (unsupported, Anleitung siehe Blog von Nils Nieuwejaar http://blogs.sun.com/nilsn/entry/installing_a_debian_zone_with)
7 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 2. Allgemein Stand: 30.11.2009 • solaris8/Solaris9: Solaris 8 bzw. Solaris 9 Container Damit ist es möglich, eine Solaris 8 oder Solaris 9 Umgebung in einer Zone zu betreiben (nur SPARC). Solche Container können mit den HA Solaris Container Agenten hochverfügbar gemacht werden. Zonen dieses Typs können nicht als virtuelle Knoten verwendet werden. • solaris 10: Solaris 10 Branded Zones sind für OpenSolaris in der Planung (Siehe http://opensolaris.org/os/project/s10brand/)
2.1.9. Solaris Container Cluster (aka „zone cluster“) [hs] Im Herbst 2008 wurden im Rahmen des Open HA Cluster Projekts zone clusters angekündigt. Diese steht seit Sun Cluster 3.2 1/09 auch im kommerziellen Produkt als Solaris Container Cluster zur Verfügung. Ein Solaris Container Cluster ist die Weiterentwicklung der Solaris Zonen-Technologie hin zu einem virtuellen Cluster, auch „zone cluster” genannt. Die Installation und Konfiguration eines Container Clusters ist im Sun Cluster Installation Guide [http://docs.sun.com/app/docs/doc/820-4677/ggzen?a=view] beschrieben. Der Open HA Cluster stellt eine vollständige, virtuelle Clusterumgebung zur Verfügung. Als Elemente werden Zonen als virtualisierte Solaris-Instanzen verwendet. Der Administrator einer solchen Umgebung sieht und bemerkt fast keinen Unterschied zum globalen Cluster, das hier virtualisiert wird. Zwei wesentliche Gründe haben die Entwicklung der virtuellen Cluster-Technologie vorangetrieben: • der Wunsch nach einer Abrundung der Container-Technologie • die Kundenanforderung, Oracle RAC (Real Application Cluster) innerhalb einer Container- Umgebung betreiben zu können.
Solaris Container, abgesichert durch Sun Cluster, bieten eine hervorragende Möglichkeit, Anwen- dungen sicher und hochverfügbar in Solaris Containern zu betreiben. Für solche Implementierungen stehen zwei Möglichkeiten, Flying Container und Flying Services, zur Verfügung. Eine saubere Trennung bei der Systemadministration ermöglicht die Delegation der Container- Administration an die Anwendungsbetreiber, die ihre Applikation innerhalb eines Containers installieren, konfigurieren und betreiben. Für den Anwendungsbetreiber war es allerdings unbefriedigend, zwar Administratorrechte in seinen Containern zu haben, andererseits aber nur sehr eingeschränkt mit den zu seiner Zone gehörenden Cluster-Ressourcen umgehen zu können. In der Cluster Implementierung vor Sun Cluster 3.2 1/09 bestand das Cluster hauptsächlich aus den in der globalen Zone installierten, konfigurierten und auch laufenden Komponenten. Nur eine sehr kleine Zahl von Clusterkomponenten war tatsächlich innerhalb eines Containers aktiv; und auch diese ermöglichte nur sehr eingeschränkte administrative Eingriffe. Die virtuellen Cluster geben dem Zonen-Administrator nun das Gefühl, eine fast vollständige Kontrolle über seinen Cluster zu haben. Einschränkungen beziehen sich auf Dienste, die weiterhin nur einmal im Cluster vorhanden sind, wie z.B. Quorum Devices oder auch Heartbeats. Anwendern von Oracle RAC war es unverständlich, dass dieses Produkt nicht einfach innerhalb eines Containers installiert und betrieben werden konnte. Allerdings muss man wissen, dass das Oracle CRS, die sogenannte Oracle Clusterware - eine Betriebssystem-neutrale Clusterschicht - Rechte benötigt, die das ursprüngliche Sicherheitskonzept der Solaris Container nicht in eine non-global Zone delegierte. Seit Solaris 10 5/08 ist es allerdings möglich, auch innerhalb einer Zone Netzwerkschnittstellen so zu verwalten, dass Oracle CRS dort betrieben werden kann. Das Ziel, eine Clusterumgebung zur Verfügung zu stellen, die keinerlei Anpassungen der Anwendungen notwendig macht, wurde erreicht. Auch Oracle RAC kann so wie in einer normalen Solaris-Instanz installiert und konfiguriert werden. Die Zertifizierung von Oracle RAC in einem Solaris Container Cluster ist derzeit (Juni 2009) noch nicht abgeschlossen. Allerdings bietet Sun Microsystems für eine solche Konstruktion Support an. Eine Installation von Oracle RAC mit CRS in einem Solaris Container ist auch ohne ein Zonencluster möglich, allerdings ebenfalls noch nicht zertifiziert. Der Nachteil einer solchen Konfiguration ist, dass ausschließlich exclusive-IP Konfigurationen verwendet werden können, welche die Anzahl der notwendigen Netzwerkschnittstellen unnötig erhöht.
8 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 2. Allgemein Stand: 30.11.2009 2.2. Virtualisierungstechnologien im Vergleich [ug] Die herkömmlichen RZ Technologien umfassen • Applikationen auf separaten Rechnern Hierzu gehören auch mehrstufige Architekturen mit Firewall, Loadbalancing, Web- und Applikations-Server und Datenbanken. • Applikationen auf einem Rechnerverbund Darunter fallen verteilte Applikationen und Job-Systeme. • Viele Applikationen auf einem großen Rechner
Die Separierung von Applikationen auf Rechnern vereinfacht die Installation der Applikationen, erhöht jedoch die Verwaltungskosten, da die Betriebssysteme mehrfach installiert und separat gepflegt werden müssen. Weiterhin sind die Rechner in der Regel schlecht ausgelastet (< 30 %). Verteilte Applikationen sind Applikationen die auf mehreren Rechnern gleichzeitig laufen und via Netzwerk (TCP/IP, Infiniband, Myrinet, ...) kommunizieren (MPP Rechner, MPI-Software, ...). Bei Job-Systemen wird in der Vorbereitung die Berechnung in abgeschlossene Teilberechnungen mit Abhängigkeiten zerlegt und von einem Job-Scheduler auf mehreren Rechnern ausgeführt, der auch den Transport der Daten übernimmt (Grid Verbund). Beide Varianten erfordern eine hohe Netzwerkleistung und angepasste Applikationen und machen nur in Bereichen Sinn, in denen die Applikationen bereits angepasst sind. Die Anpassung ist ein größerer Schritt und nur selten für heute verfügbare Standard-Applikationen durchgeführt. In Zukunft kann diese Technologie daher mit der Anpassung der Applikationen interessanter werden. Viele Applikationen in einem Rechner einzusetzen ist die Art und Weise, in der heute Mainframes und größere Unix Systeme betrieben werden. Die Vorteile liegen in der besseren Auslastung der Systeme (mehrere Applikationen) und geringeren Zahl von zu wartenden Betriebssystem-Installationen. Daher ist gerade diese Variante für die Konsolidierung im Rechenzentrum interessant. Die Herausforderungen bestehen darin, für die Applikationen eine Umgebung zu schaffen, in der die Applikationen zwar unabhängig ablaufen können (Separation), aber doch Ressourcen miteinander teilen (Sharing), um Kosten zu sparen. Die im einzelnen interessanten Bereiche sind: • Separation. Wie weit sind die Environments der Applikationen getrennt? • Applikation. Wie fügt sich die Applikation in das Environment ein? • Auswirkungen auf die SW-Maintenance • Auswirkungen auf die HW-Maintenance • Delegation: Können Administrations-Tätigkeiten an das Environment delegiert werden? • Skalierung der Environments? • Overhead der Virtualisierungstechnologie? • Kann man unterschiedliche OS-Versionen in den Environments benutzen? Dazu wurden verschiedene Techniken zur Virtualisierung entwickelt, die im folgenden vorgestellt werden.
Vergleiche dazu auch: http://en.wikipedia.org/wiki/Virtualization
9 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 2. Allgemein Stand: 30.11.2009
2.2.1. Domains/physikalische Partitionen [ug] Ein Rechner kann durch Konfiguration in Teil-Rechner (Domain, Partition) zerlegt werden. Die Domains sind fast vollständig physikalisch getrennt, da die elektrischen Verbindungen abgeschaltet werden. Gemeinsam benutzte Teile sind entweder sehr ausfallsicher (Gehäuse) oder redundant aufgebaut (Service-Prozessor, Netzteile). Vorteile: • Separation: Die Applikationen sind gut voneinander separiert, ein gegenseitiger Einfluss über das OS oder ausgefallene gemeinsame Hardware ist nicht möglich. • Applikation: Alle Applikationen sind lauffähig, sofern sie nur im Basis-Betriebssystem lauffähig sind. • Skalierbarkeit: Die Leistung einer Virtualisierungsinstanz (hier eine Domain) lässt sich bei einigen Implementierungen im laufenden Betrieb ändern (Dynamic Reconfiguration), indem HW- Ressourcen zwischen Domains verschoben werden. • HW-Maintenance: Bei Ausfall einer Komponente kann bei entsprechender Auslegung der Domain die Applikation trotzdem betrieben werden. Reparaturen sind durch Dynamic Reconfiguration im laufenden Betrieb möglich (bei redundanter Auslegung). Nur um Total- Ausfälle abzufangen, muss noch ein Cluster eingerichtet werden (Stromversorgung, Brand des Gehäuses, Ausfall des RZ, Software-Fehler). • OS-Versionen: Unterschiedliche Betriebssysteme/Versionen sind möglich. Nachteile: • OS-Maintenance: Jede Maschine muss separat administriert werden. OS-Installation, Patches und die Umsetzung Firmen-interner Standards müssen für jede Maschine separat erfolgen. • Delegation: Die für die Applikation / den Service zuständige Abteilung braucht für einen Teil der Ablaufsteuerung root-Rechte oder muss mit dem Rechner-Betrieb bezüglich Änderungen kommunizieren. Das kann die Sicherheit beeinträchtigen oder aufwändig werden/länger dauern. • Overhead: Jede Maschine hat den Overhead eines eigenen Betriebssystems. Sun bietet Domains in den High-End Servern SunFire E20K, E25K , den Midrange Servern SunFire E2900, E4900, E6900 und den Sun SPARC Enterprise M4000, M5000, M8000 und M9000 an.
App 1 App 2 App 3 App
OS
Server
Zeichnung 2: [dd] Domains/Physikalische Domains
Diese Virtualisierungstechnik wird von einigen Herstellern zur Verfügung gestellt (Sun Dynamic System Domains, Fujitsu Partitions, HP nPars). HW-Support und (wenig) OS-Support sind notwendig.
10 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 2. Allgemein Stand: 30.11.2009
2.2.2. Logische Partitionen [ug] Auf der Hardware eines Rechners läuft ein minimales Betriebssystem, der Hypervisor, der die Schnittstelle zwischen Hardware und OS des Rechners virtualisiert. Auf den entstehenden sogenannten virtuellen Maschinen lässt sich jeweils ein eigenes Betriebssystem (Gast- Betriebssystem) installieren. Bei einigen Implementierungen läuft der Hypervisor auch als normales Applikationsprogramm, was jedoch erhöhten Overhead bedeutet. In der Regel werden durch Emulation aus den realen Devices virtuelle Devices erzeugt; reale und virtuelle Devices werden den logischen Partitionen durch Konfiguration zugeteilt. Vorteile: • Applikation: Alle Applikationen des Gast-Betriebssystem sind lauffähig. • Skalierbarkeit: Die Leistung einer logischen Partition lässt sich teilweise im laufenden Betrieb ändern, wenn das OS und der Hypervisor es zulassen. • Separation: Die Applikationen sind voneinander separiert, ein direkter gegenseitiger Einfluss über das OS ist nicht möglich. • OS-Versionen: Unterschiedliche Betriebssysteme/Versionen sind möglich. Nachteile: • HW-Maintenance: Bei Ausfall einer gemeinsam genutzten Komponente sind ggf. viele oder alle logischen Partitionen betroffen. Es wird jedoch versucht, durch vorbeugende Analyse Anzeichen eines zukünftigen Ausfalls zu erkennen, um vorab die Fehler auszugrenzen. • Separation: Die Applikationen können sich über gemeinsam genutzte Hardware gegenseitig beeinflussen. Ein Beispiel ist hier das virtuelle Netzwerk, da der Hypervisor einen Switch emulieren muss. Auch die virtuellen Platten, die zusammen auf einer realen Platte liegen und sich dort gegenseitig den Schreib-/Lese-Kopf „wegziehen“, sind ein Beispiel für dieses Verhalten. Um das zu vermeiden, kann man reale Netzwerk-Interfaces und/oder dedizierte Platten verwenden, was den Aufwand zur Nutzung von logischen Partitionen allerdings erhöht. • OS-Maintenance: Jede Partition muss separat administriert werden. OS-Installation, Patches und die Umsetzung Firmen-interner Standards müssen für jede Partition separat erfolgen. • Delegation: Wenn die für die Applikation / den Service zuständige Abteilung root-Rechte benötigt, dann sind alle Aspekte des Betriebssystems in der logischen Partition administrierbar. Das kann die Sicherheit beeinträchtigen. • Overhead: Jede logische Partition hat den Overhead eines eigenen Betriebssystems, insbesondere wird der Hauptspeicherbedarf der einzelnen Systeme beibehalten.
App 1 App 2 App 3 App
OS
Server
Zeichnung 3: [dd] Logische Partitionen
Zu logischer Partitionierung gehören das IBM VM-Betriebssystem, IBM LPARs auf z/OS und AIX, HP vPars, sowie VMware und XEN. Sun bietet Logical Domains an (SPARC: seit Solaris 10 11/06) sowie Sun xVM VirtualBox (x86- und x64-Architekturen. Der Sun xVM-Server befindet sich in Zusammenarbeit mit der XEN-Community für x64-Architekturen in der Entwicklung. Der Virtualisierungsteil (xVM-Hypervisor) kann seit OpenSolaris 2009.06 bereits evaluiert werden.
11 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 2. Allgemein Stand: 30.11.2009
2.2.3. Container (Solaris Zonen) in einem OS [ug] In einer Betriebssystem-Installation werden voneinander unabhängige Ausführungsumgebungen für Anwendungen und Dienste geschaffen. Der Kernel wird mandantenfähig: er ist nur einmal da, erscheint aber jeder Zone als wäre er exklusiv zugeordnet. Die Separation wird implementiert, indem der Zugriff auf Ressourcen eingeschränkt wird, wie z.B. die Sichtbarkeit der Prozesse (modifiziertes procfs), Nutzbarkeit der Devices (modifiziertes devfs), die Sichtbarkeit des Dateibaumes (wie bei chroot). Vorteile: • Applikation: Alle Applikationen sind lauffähig, sofern sie keine eigenen Treiber benutzen oder sonst systemnahe Features nutzen. Eigene Treiber sind jedoch über Installation in der globalen Zone nutzbar. • Skalierbarkeit: Die Leistung eines Containers ist konfigurierbar (mit Ressource Management, Prozessorsets und CPU-Caps). • Separation: Die Applikationen sind voneinander separiert, ein direkter gegenseitiger Einfluss über das OS ist nicht möglich. • OS-Maintenance: Nur an zentraler Stelle (in der globalen Zone) muss die OS-Installation, Patches und Umsetzung Firmen-interner Standards erfolgen. • Delegation: Die für die Applikation / den Service zuständige Abteilung braucht für einen Teil der Ablaufsteuerung root-Rechte. Sie kann hier die root-Rechte in der Zone erhalten, ohne die anderen lokalen Zonen oder die globale Zone beeinträchtigen zu können. Die Zuweisung von Ressourcen ist allein der globalen Zone vorbehalten. • Overhead: Alle Prozesse lokaler Zonen sind aus Sicht der globalen Zone nur normale Applikationsprozesse. Der OS-Overhead (Memory Management, Scheduling, Kernel) und der Speicherbedarf für shared Objekte (Dateien, Programme, Libraries) entsteht nur einmal. Jede Zone hat zusätzlich nur eine kleine Zahl von Systemprozessen. Daher sind hunderte von Zonen auf einem 1-Prozessor-System möglich.
Nachteile: • HW-Maintenance: Bei Ausfall einer gemeinsam genutzten Komponente sind ggf. viele oder alle Zonen betroffen. Mit FMA (Fault Management Architecture) erkennt Solaris 10 Anzeichen eines zukünftigen Ausfalls und kann die betroffenen Komponenten (CPU, Memory, Bus-Systeme) im laufenden Betrieb deaktivieren bzw. benutzt stattdessen alternativ vorhandene Komponenten. Durch Einsatz von Cluster Software (Sun Cluster) kann die Verfügbarkeit der Applikation in der Zone verbessert werden (Solaris Container Cluster/ Solaris Container). • Separation: Die Applikationen können sich über gemeinsam genutzte Hardware gegenseitig beeinflussen. Der Einfluss kann bei Solaris mit Ressource Management und Netzwerk- Bandbreitenkontrolle minimiert werden. • OS-Versionen: Unterschiedliche Betriebssysteme/Versionen sind nur mit Branded Zones möglich. Hierbei wird in einer Zone eine virtuelle Ablaufumgebung für ein anderes Betriebssystem erzeugt, der Kern der globalen Zone wird aber von den Branded Zones mitbenutzt.
App 1 App 2 App 3 App
BrandZ OS
Server
Zeichnung 4: [dd] Container (Solaris Zonen) in einem OS Implementierungen sind im freien BSD Betriebssystem die Jails, in Solaris die Zonen und im Linux das vserver Projekt. HW Voraussetzungen sind nicht erforderlich.
12 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 2. Allgemein Stand: 30.11.2009
2.2.4. Konsolidierung in einem Rechner [ug] Die Applikationen werden auf einem Rechner installiert und unter unterschiedlichen UserIDs benutzt. Das ist die Konsolidierung, die von Haus aus in den modernen Betriebssystemen möglich ist. Vorteile: • Applikation: Alle Applikationen sind lauffähig, sofern sie nur im Basis-Betriebssystem lauffähig sind und keine eigenen OS-Treiber nutzen. Einschränkungen gibt es allerdings dann, wenn unterschiedliche Versionen der Applikationen mit definiertem Install-Verzeichnis gebraucht werden oder zwei Instanzen die gleiche UserID brauchen (z.B. Oracle Instanzen) bzw. die Konfigurations-Dateien an den selben Stellen im Filesystem liegen. • Skalierbarkeit: Die Leistung einer Anwendung lässt sich online ändern. • OS-Maintenance: Nur für ein OS muss die OS-Installation, Patches und Umsetzung Firmen- interner Standards erfolgen. Das heißt mit dem Administrations-Aufwand für eine Maschine kann man viele Applikationen betreiben. • Overhead: Der Overhead ist gering, da nur die Applikationsprozesse pro Applikation laufen müssen. Nachteile: • HW-Maintenance: Bei Ausfall einer gemeinsam genutzten Komponente sind ggf. viele oder alle Applikationen betroffen. • OS-Maintenance: Die Administration wird kompliziert, sobald Applikationen auf unterschiedliche Versionen einer Software basieren (z.B. Versionen für Oracle, Weblogic, Java, ...). Ohne genaue Dokumentation und Change-Management wird ein solches System schwer beherrschbar. Ein Fehler in der Dokumentation wird nicht sofort bemerkt, kann sich jedoch beim Upgrade (HW oder OS) später fatal auswirken. • Separation: Die Applikationen können sich über gemeinsam genutzte Hardware und das OS gegenseitig beeinflussen. Der Einfluss kann bei Solaris mit Ressource Management und Netzwerk-Bandbreitenkontrolle reduziert werden. • Delegation: Die für die Applikation / den Service zuständige Abteilung braucht für einen Teil der Ablaufsteuerung root-Rechte oder muss mit dem Rechner-Betrieb bezüglich Änderungen kommunizieren. Das kann daher die Sicherheit beeinträchtigen oder aufwändiger werden/länger dauern. • OS-Versionen: Unterschiedliche Betriebssysteme/Versionen sind nicht möglich.
App1 App 2 App 3 App
OS
Server
Zeichnung 5: [dd] Konsolidierung in einem Rechner
Diese Konsolidierung wird von vielen modernen Betriebssystemen ermöglicht die es erlauben, mehrere Software-Pakete zu installieren, ggf. auch die gleiche Software in unterschiedlichen Versionsständen.
13 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 2. Allgemein Stand: 30.11.2009
2.2.5. Zusammenfassung zu den Virtualisierungstechnologien [ug] Die diskutierten Virtualisierungstechnologien lassen sich in der folgenden Tabelle -im Vergleich zur Installation auf einem separaten Rechner- zusammenfassen.
Domains/ Logische Container Konsolidierung Separate Physikalische Partitionen (Solaris Zonen) in einem Rechner Partitionen in einem OS Rechner Separation + O + (Software) + (Software) - - (Hardware) - (Hardware) Applikation + + + + - SW-Maintenance - - - + O HW-Maintenance + + O O O Delegation - - - + - Skalierbarkeit O + O + + Overhead - - - + + OS-Versionen je eine mehrere mehrere eine eine Tabelle 2: [ug] Zusammenfassung zu den Virtualisierungstechnologien
Legende zur Bedeutung der Symbole: • + gut • O ist weder gut noch schlecht • - bedeutet: hat Nachteile
Die Separation ist bei einem eigenständigen Rechner natürlich am Besten, bei physikalischen Partitionen gibt es das gemeinsam genutzte Gehäuse (Netzteil, Brand), obwohl die Rechner unabhängig sind, währenddessen Lpars, LDom und Container nur in der OS-Umgebung separiert sind. Konsolidierung in einem Betriebssystem offenbart jeder Applikation das Sichtbare der anderen Applikationen. In den anderen Fällen sind die Applikationen separiert. SW-Maintenance kann erst mit Zonen und Konsolidierung in einem Rechner gemeinsam durchgeführt werden. Die anderen Technologien erfordern mehrfache Maintenance. HW-Maintenance auf der Maschine einer Applikation ist nur bei Domains oder separaten Rechnern ohne Beeinträchtigung anderer Applikationen machbar, es sei denn, man nutzt bewegliche Lpars/LDom oder setzt Cluster Technologien oder Flying Zones ein. Die Delegation von Teilen der Administrations-Aufgaben ist nur bei Containern vordefiniert. Alle anderen Technologien erfordern genaue Definition der Aufgaben und dedizierte Zuordnung von Rollen. Das ist kostenintensiv und aufwändig. Die Skalierbarkeit ist bei separaten Rechnern und Lpars auf die Basis der Hardware limitiert (definierte feste Bus-Leistung), währenddessen Domains durch weitere Hardware in der Leistung angepasst werden können (Crossbar). Container und Konsolidierungen laufen ohne Anpassung auf größeren Rechnern. Weitere Anteile können durch Verschiebung von weiteren Containern auf diesen Rechner genutzt werden. Der Overhead ist bei separaten Rechnern, physikalischer und logischer Partitionierung höher, da je Applikation ein Betriebssystem mit CPU und Memory-Anforderungen läuft. Container und Konsolidierung auf einem Rechner teilen sich ein Betriebssystem und sind daher erheblich sparsamer im Verbrauch von Ressourcen. Der Effekt ist umso deutlicher, je geringer der Ressourcen-Bedarf einer Applikation ist. Die OS-Version jeder Betriebssystem-Installation muss separat gepflegt werden. Das bedeutet Aufwand. Daher sind bei separaten Rechnern sowie physikalischer und logischer Virtualisierung höhere Aufwände zu betreiben, als bei Containern oder Konsolidierung auf einem Rechner. Die multiplen OS-Versionen bedeuten aber auch die Möglichkeit, separate Stände des OS zu nutzen, sofern die Applikationen es erfordern. Daher ist hier keine Wertung vorgenommen, da die Wertung vom Einsatzzweck im Rechenzentrum abhängt. Man kann den Aufwand mehrerer OS-Instanzen verringern, indem Management-Software wie z.B. das Sun xVM OpsCenter eingesetzt wird, was selber wieder Investitionen erfordert.
14 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 2. Allgemein Stand: 30.11.2009
Physikalische Logische OS Ressource Virtualisierung Virtualisierung Virtualisierung Management (Domains/ (Logische (Container (Konsolidierung in Physikalische Partitionen) - Solaris Zonen - einem Rechner) Partitionen) in einem OS)
App
OS
HW
HW-Fehler Containment
Eigenes OS / separater Speicher OS und Speicher Sharing
Isolation des OS-Environments Sharing des OS- Environments
Zeichnung 6: [dd] Vergleich von Virtualisierungstechnologien
15 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 3. Anwendungsfälle Stand: 30.11.2009 3. Anwendungsfälle
Das folgende Kapitel diskutiert verschiedene Anwendungsfälle für Solaris Container und bewertet diese. 3.1. Grid Computing mit Isolation Anforderung [ug] Im Unternehmen besteht Bedarf eine gewisse Menge Rechenarbeit im Hintergrund unter Nutzung der freien Zyklen der bestehenden Rechner durchzuführen. Dafür ist Grid Software wie Sun N1 Grid Engine geeignet. Jedoch soll den Prozessen die dann im Grid laufen, die Sicht auf die anderen Prozesse des Systems versperrt werden. Lösung [ug] Auf den Rechnern mit freier Kapazität wird Sun Gridware in jeweils einer Zone installiert: • Sparse-root Zones werden benutzt ( 4.1.1 Sparse-root Zonen ). • Software und Daten werden per NFS in der globalen Zone installiert. • Sun Grid wird in der lokalen Zone installiert. • Automatische Erzeugung der Zone ( 5.1.14 Automatische Schnell-Installation von Zonen ) • Software-Installation per lofi von der globalen Zone ( 5.3.3. Softwareinstallation per mount ) Bewertung [ug] Dieser Anwendungsfall hat die folgenden Eigenschaften: • Die Rechner können zu den definierten Zeiten die freien Kapazitäten nutzen. • Die Daten der anderen Applikationen bleiben vor Einsicht geschützt. Dadurch erhöht sich oft die Bereitschaft der Applikations-Zuständigen, die Rechner dafür zur Verfügung zu stellen. • Die Applikations-Abteilung kann die freien Kapazitäten den Grid-Nutzern „verkaufen“. Über alles werden Rechner-Kapazitäten eingespart.
Grid Netzwerk
Grid Grid Knoten App 1 App 2 Knoten App 3 App 4 1 2 Grid Knoten 3 Grid Knoten 4 Globale Zone Globale Zone System 1 System 2
Zeichnung 7: [dd] Anwendungsfall Grid Computing mit Isolation
16 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 3. Anwendungsfälle Stand: 30.11.2009 3.2. Kleine Webserver Anforderung [ug] Eine der folgenden Situationen besteht: • Ein Internet Service Provider (ISP) möchte ohne große Kosten die Möglichkeit haben, Webserver automatisch aufzusetzen. Der ISP will auf Basis dieser Technologie ein günstiges Angebot für Webserver mit root-Zugang erstellen. • Ein Rechenzentrum einer größeren Firma hat aus vielen Abteilungen Anforderungen für interne Webserver zum Informationsaustausch zwischen den Abteilungen. Das Interesse der Kunden ist, möglichst einfach ohne viele Regularien und Absprachen, Web- Content abzulegen (wenig Aufwand). Daher strebt die Fachabteilung einen Webserver an, auf dem sonst niemand sonst arbeitet. Das Interesse des Rechenzentrums ist, die Administrationskosten niedrig zu halten. Daher soll es möglichst kein eigener Rechner sein, zumal auch der Datenverkehr wahrscheinlich klein sein wird und keinen eigenen Rechner rechtfertigt. Lösung [ug] Die Webserver werden durch automatisch installierte Zonen realisiert. Im einzelnen werden die folgenden Details verwendet: • Sparse-root Zones, das heißt die Zonen erben möglichst alles von der globalen Zone (4.1.1 Sparse-root Zonen). • Das Softwareverzeichnis des Webservers, z.B. /opt/webserver wird nicht vererbt (inherit-pkg-dir), um verschiedene Web-Server Versionen zu ermöglichen. • Automatische Erzeugung einer Zone per Script • Automatische Systemkonfiguration in der Zone mit sysidcfg • Automatische IP-Adressenverwaltung • Option: Automatische Schnell-Installation einer Zone • Option: Applikations-Administrator mit root-Zugang • Option: Software-Installation per mount Bewertung [ug] Dieser Anwendungsfall hat die folgenden Eigenschaften. • Die Betriebsabteilung hat geringe Aufwände bei der Erzeugung der Zonen. • Da die erwartete Last sehr klein ist, ist der Konsolidierungseffekt sehr groß, da nur die aktiven Prozesse in der Zone Ressourcen brauchen. • Die Nutzer der automatisch erzeugten Web-Server in den Zonen haben die Freiheit, diverse verschiedene Versionen zu nutzen, ohne sich umgewöhnen zu müssen. Das heißt, ihre Kosten sind gering und es entsteht kaum Schulungsbedarf. • Die Webserver können mit den Standardports und den voreingestellten IP-Adressen der Container arbeiten - es sind keine besonderen Konfigurationen nötig, wie sonst, wenn mehrere Webserver auf einem System betrieben werden sollen.
Webserver Webserver Webserver 1 2 3
Globale Zone System 1
Zeichnung 8: [dd] Anwendungsfall kleine Webserver
17 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 3. Anwendungsfälle Stand: 30.11.2009 3.3. Multi-Netzwerk Konsolidierung Anforderung [dd] Die folgende Situation besteht: • Eine Firma verfügt über mehrere unterschiedliche Netzwerke, die entweder in mehreren Stufen durch Firewalls oder durch Router getrennt sind. In den einzelnen Netzwerken laufen Anwendungen. Man möchte sehr einfach Anwendungen aus verschiedenen Netzwerken oder Security-Bereichen gemeinsam auf einem physikalischen System benutzen, da die Anwendungen nicht jeweils ein komplettes System auslasten. Lösung [dd] Die einzelnen Anwendungen werden jeweils in eine Zone installiert. Zonen werden nach bestimmten Kriterien (Redundanz, ähnliche Anwendung, Lastverhalten, ...) zusammen auf physikalische Server gruppiert. Das Routing zwischen den Zonen ist ausgeschaltet, um die Netzwerke zu trennen. Im einzelnen werden die folgenden Details verwendet: • Erzeugung von Zonen • Zonen als Laufzeitumgebung für je eine Anwendung • Das Routing der globalen Zone auf den Interfaces ist ausgeschaltet, damit Zonen sich nicht gegenseitig erreichen können. D.h. die Zonen erreichen jeweils nur Adressen in ihrem Netzwerk • IP Instanzen benutzen Bewertung [dd] Dieser Anwendungsfall hat die folgenden Eigenschaften. • Die Netzwerkstruktur vereinfacht sich durch die Einsparung von Routen und Routern. • Die Anzahl benötigter Systeme verringert sich. • Anwendungen können nach neuen Gesichtspunkten geordnet werden, z.B. alle Web-Server auf einen physikalischen Server bzw. für Webserver werden z.B. T2000 benutzt, für Proxy Server werden T1000 benutzt, für alle Datenbanken UltraSPARC IV+ Systeme, etc. • Die globale Zone kann als zentrale Administrationsinstanz aller Zonen eines Systems benutzt werden. Über die globalen Zonen kann ein separates Administrationsnetz gelegt werden. • Die Administration der Anwendungen liegt innerhalb der Zone bei den Anwendungsadministratoren. Werden gleiche Anwendungen auf Systemen zusammen gruppiert, kann ein Anwendungsadministrator aus der globalen Zone heraus alle Anwendungen in den Zonen einfacher administrieren oder durch die Nutzung von Sparse-root Zones die Administration vereinfachen. Gateway/Router/ FireWall
Netzwerk C Netzwerk A Netzwerk B
App A1 App A2 App B App A1' App A3 App B' App C App C App C
Globale Zone Globale Zone Globale Zone System 1 System 2 System 3
Zeichnung 9: [dd] Anwendungsfall: Multi-Netzwerk Konsolidierung
18 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 3. Anwendungsfälle Stand: 30.11.2009 3.4. Multi-Netzwerk Monitoring Anforderung [dd] Die folgende Situation besteht: • Eine Firma verfügt über mehrere unterschiedliche Netzwerke, die entweder in mehreren Stufen durch Firewalls oder durch Router getrennt sind. In den einzelnen Netzwerken sind verschiedene Rechner installiert. Die Administration soll vereinfacht werden und man möchte von einer zentralen Stelle aus direkt in alle Netzwerke „hineinschauen“ und administrieren können, ohne die Netzwerke mit Routing verbinden zu müssen. Lösung [dd] Es wird ein zentraler Monitoring- und Administrator-Server installiert. Auf diesem Server werden mehrere Zonen erzeugt, die in jedes Netzwerk eine Netzwerkverbindung haben. Aus den Zonen erfolgt das Monitoring oder die Administration der Rechner der einzelnen Netzwerke. Im Einzelnen werden die folgenden Details verwendet: • Sparse-root Zones, das heißt die Zonen erben möglichst alles von der globalen Zone • Alle Zonen verwenden die selben Monitoring- und Administrationstools • Monitoring-Daten werden in zwischen Zonen gemeinsam genutzte Filesysteme abgelegt • Die Daten können aus einer lokalen Zone oder aus der globalen Zone heraus zentral ausgewertet werden. • Von einer zentralen Stelle aus (die globale Zone) können zentrale Konfigurationsdateien über die Zonen an alle Systeme in den Netzwerken direkt verteilt werden. Umständliche Wege über Router oder Firewalls entfallen. • Das Routing zwischen den Zonen muss abgeschaltet sein. • Option: IP Instanzen benutzen Bewertung [dd] Dieser Anwendungsfall hat die folgenden Eigenschaften. • Die Betriebsabteilung hat geringe Aufwände bei der Erzeugung der Zonen. • Der Administrationsaufwand sinkt für Systeme in den Netzwerken, da keine mehrfachen Logins über Router oder Firewalls hinweg ausgeführt werden müssen. • Es kann ein Single-Point-of-Administration geschaffen werden. • Entlastung der Router und Firewalls von Netzlast und zusätzlichen Konfigurationen. • Nutzung einheitlicher Überwachungswerkzeuge. • Nutzung einheitlicher Konfigurationen wird vereinfacht.
Netzwerk C Netzwerk D Netzwerk B Netzwerk E
Monitor Monitor Monirot Monitor Monitor Monirot Netzwerk A A B C D E F Netzwerk F
Globale Zone System 1
Zeichnung 10: [dd] Anwendungsfall Multi-Netzwerk Monitoring
19 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 3. Anwendungsfälle Stand: 30.11.2009 3.5. Multi-Netzwerk Backup Anforderung [dd] Die folgende Situation besteht: • Eine Firma verfügt über mehrere unterschiedliche Netzwerke, die entweder in mehreren Stufen durch Firewalls oder durch Router getrennt sind. In den einzelnen Netzwerken sind verschiedene Rechner installiert. Das Backup soll vereinfacht werden, indem von einer Stelle aus das direkte Backup der Systeme in den einzelnen Netzwerken durchgeführt werden kann, ohne die Netzwerke mit Routing verbinden zu müssen Lösung [dd] Es wird ein Server mit Backup-Serversoftware installiert. Auf diesem Server werden mehrere Zonen erzeugt, die in jedes Netzwerk eine Netzwerkverbindung haben. In den Zonen werden Backup- Clients gestartet, die mit dem Backup-Server in der globalen Zone über das interne Netzwerk kommunizieren oder als Backup-Server direkt auf ein verfügbares Backup-Gerät schreiben. Im Einzelnen werden die folgenden Details verwendet: • Sparse-root Zones, das heißt die Zonen erben möglichst alles von der globalen Zone. • Die Backup-Client oder -Server Software ist für jede Zone separat installiert. • Bereitstellung eines Gerätes aus der globalen Zone an eine lokale Zone. • Netzwerksetup zur Verbindung von der globalen mit der lokalen Zone Bewertung [dd] Dieser Anwendungsfall hat die folgenden Eigenschaften. • Die Betriebsabteilung hat geringe Aufwände bei der Erzeugung der Zonen. • Backup und Restore kann zentral von einer Stelle aus organisiert und durchgeführt werden. • Durch direktes Backup können höhere Backup-Geschwindigkeiten erreicht werden. Router oder Firewalls werden nicht durch Backup-Daten belastet. • U.u. Einsparung von Lizenzkosten für Backup-Software. • Sharing von Backup-Hardware zwischen Abteilungen und Netzwerken.
Bisher hat sich leider gezeigt, dass die Softwarehersteller Backup-Server Software noch nicht für die Benutzung in Zonen freigegeben haben. So ist also dieser Anwendungsfall nur bedingt einsetzbar. Backup-Clients sind vereinzelt bereits zur Benutzung in Zonen freigegeben.
Netzwerk B
Backup Backup Backup Netzwerk A Client Client Client Netzwerk C A B C
Globale Zone System 1
Zeichnung 11: [dd] Anwendungsfall Multi-Netzwerk Backup
20 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 3. Anwendungsfälle Stand: 30.11.2009 3.6. Konsolidierung Entwicklung/Test/Integration/Produktion Anforderung [ug] Zu einer Applikation, die in Produktion ist, existieren in der Regel noch weitere Systeme, die die gleiche Applikation tragen: • Entwicklungssysteme • Testsysteme • Integrationssysteme ggf. mit Simulation der Applikationsumgebung • Disaster-Recovery-Systeme Lösung [ug] Die verschiedenen Systeme können auf einem Rechner in Zonen realisiert werden. Die Details: • Sparse-root Zones, das heißt die Zonen erben möglichst alles von der globalen Zone. • Option: Ressource Pools mit eigenem Prozessor-Set für die Produktion • Option: Applikations-Administrator mit root-Zugang • Option: Software-Installation per mount • Option: OS Release Upgrade per Flash-Image Bewertung [ug] Dieser Anwendungsfall hat die folgenden Eigenschaften: • Es sind weniger Rechner insgesamt zu betreiben. Daher können Einsparungen bei Platz, Stromverbrauch und Klimatisierung erzielt werden. • Die Anwendungen können auf genau dem Environment getestet werden, auf dem sie auch später ablaufen sollen. • Ein Umstieg auf eine neue Software-Version in der Produktion ist einfach durch Umleiten der Last auf die Zone mit der neuen Version möglich. Eine Installation nach Test ist nicht erforderlich.
Entwick- Test Produktion Integration lung
Globale Zone System
Zeichnung 12: [dd] Anwendungsfall Konsolidierung Entwicklung/Test/Integration/Produktion
21 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 3. Anwendungsfälle Stand: 30.11.2009 3.7. Konsolidierung von Testsystemen Anforderung [ug] Für Tests von Software und Applikationen existieren im RZ-Environment viele Test-Systeme die immer nur bei Tests benutzt werden. Größtenteils werden sie nur für qualitative Tests benutzt, wobei die Systeme nicht wie bei Lasttests belastet werden. Ein Neu-Installieren der Testsysteme je nach benötigtem Test kommt allerdings nicht in Frage, weil man ohne Wartezeit auf das Environment gehen können will, genau so wie es in der Produktion läuft. Die Testsysteme sind daher sehr schlecht ausgelastet. Lösung [ug] Die Testsysteme werden durch Zonen auf einem größeren Server realisiert. Die Details: • Sparse-root Zones / Whole-root Zones, je nach Bedarf. • Filesystem Entscheidungen analog zum Produktionssystem • Option: Ressource Management mit Prozessor Sets für parallel ablaufende Tests • Option: Automatische Erzeugung der Zone • Option: Software-Installation per mount • Option: Move der Zone zwischen Rechnern • Option: Automatische Schnell-Installation einer Zone Bewertung [ug] Dieser Anwendungsfall hat die folgenden Eigenschaften: • Die Betriebsabteilung benötigt viel weniger Rechner, die als Testsysteme dienen. Es müssen viel weniger Installationen durchgeführt werden. • Teure Systeme für Lasttests müssen nur einmal und nicht für jede Applikation angeschafft werden. Lasttests auf den mittels Zonen gemeinsam genutzten Maschinen müssen jedoch abgesprochen werden (Betrieb). • Die Anwender haben die Testinstallation immer im Zugriff, jedenfalls qualitativ; gegebenenfalls nicht mit der vollen Performance.
Test Test Test Test Test A B C D E
Globale Zone System
Zeichnung 13: [dd] Anwendungsfall Konsolidierung von Testsystemen
22 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 3. Anwendungsfälle Stand: 30.11.2009 3.8. Schulungssysteme Anforderung [ug] In Schulungs-Abteilungen müssen die Rechner häufig wieder neu aufgesetzt werden, die den Schulungsteilnehmern (auch Schüler/Studenten) zur Verfügung stehen. Lösung [ug] Die Schulungssysteme werden durch automatisch installierte Zonen realisiert: • Sparse-root Zones, das heißt die Zonen erben möglichst alles von der globalen Zone. • Automatische Erzeugung einer Zone per Script • Automatische Systemkonfiguration in der Zone mit sysidcfg • Automatische IP-Adressenverwaltung • Option: /opt ist nicht vererbt (inherit-pkg-dir), für die Schulung von Installationen • Option: Automatische Schnell-Installation einer Zone • Option: Applikations-Administrator mit root-Zugang • Option: Installation gemeinsamer Software per mount Bewertung [ug] Dieser Anwendungsfall hat die folgenden Eigenschaften: • Der Betrieb der Schulungsrechner ist extrem einfach, da die Zonen für die Schulung einfach für den nächsten Kurs neu erzeugt werden können. • Die Schulungsteilnehmer sind in der Zone selbst root, womit sie alle wesentlichen Administrationsfunktionen ohne Gefahr für das Gesamtsystem ausüben können. Die Neuinstallation des Rechners entfällt somit. • Der Schulungsleiter hat von der globalen Zone aus Einblick in die Arbeit der Schulungsteilnehmer. • Die Kosten für das Schulungssystem sinken daher drastisch.
Student Student Student Student Student Student A B C D E F
Globale Zone System
Zeichnung 14: [dd] Anwendungsfall Schulungssysteme
23 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 3. Anwendungsfälle Stand: 30.11.2009 3.9. Server Konsolidierung Anforderung [ug] Im Rechenzentrum werden mehrere Applikationen betrieben, deren Auslastung zu gering ist (oft weit unter 50%). Die Rechner selber benötigen in der Regel Strom, Kühlung und Platz. Lösung [ug] Mehrere Anwendungen werden in Zonen auf einem Rechner konsolidiert. Die Details: • Dies kann in der Regel mit Sparse-root Zones erfolgen. • Genau eine Applikation pro Zone installieren. • Option: Software-Installation durch shared Directory • Option: Automatische Software Installation • Option: Ressource Management mit Ressource Pools • Option: Ressource Management mit Fair Share Scheduler • Option: Netzwerk Ressource Management mit IPQoS • Option: Hochverfügbarkeit durch Cluster • Option: Software-Installation per Provisioning Bewertung [ug] Dieser Anwendungsfall hat die folgenden Eigenschaften: • Die Betriebsabteilung hat geringere Kosten, da weniger Platz, Energie und Kühlung benötigt werden. • Die Anwendungsabteilung hat eine Kapselung der Applikation und genau definierte Schnittstellen. Die Verfügbarkeit der Applikation steigt.
App App App App App A B C D E
Ressource Pool 1 Ressource Pool 2
CPU1 CPU2 CPU3 CPU4 Globale Zone System CPU5
Zeichnung 15: [dd] Anwendungsfall Server Konsolidierung
24 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 3. Anwendungsfälle Stand: 30.11.2009 3.10. Vertraulichkeit von Daten und Prozessen Anforderung [ug] Im Rechenzentrum laufen Applikationen auf verschiedenen Rechnern, weil • Bestimmte Abteilungen sicher sein wollen, dass die Daten und Prozesse nicht von anderen Abteilungen gesehen werden. • Services für verschiedene Kunden sollen konsolidiert werden. Die Kunden wünschen Vertraulichkeit der Daten und der Prozesse (die ggf. Rückschluss auf Geschäftsprozesse erlauben). Lösung [ug] Die Applikationen der Kunden werden in verschiedenen Zonen installiert: • Applikationen werden nur in lokalen Zonen installiert • Die Filesysteme/Devices mit den Daten der jeweiligen Kunden werden nur in den entsprechenden Zonen zur Verfügung gestellt. Damit ist die Vertraulichkeit der Daten auch ohne strenge Disziplin bei den Dateizugriffsrechten gewährleistet. • Option: Software-Installation in der Zone in ein nur dort vorhandenes lokales Filesystem oder ein nicht gemeinsam genutztes /opt . Bewertung [ug] Dieser Anwendungsfall hat die folgenden Eigenschaften: • Die Betriebsabteilung hat eine bessere Auslastung der Systeme. • Die Anwender / Kunden behalten die Vertraulichkeit. • Die Basis-Kosten sind geringer, wodurch der Service bei höherer Marge günstiger angeboten werden kann.
App App App App App A B C D E
Globale Zone System
Zeichnung 16: [dd] Anwendungsfall Vertraulichkeit von Daten und Prozessen
25 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 3. Anwendungsfälle Stand: 30.11.2009 3.11. Testsysteme für Entwickler Anforderung [ug] Entwickler brauchen zum Ausprobieren ihrer Applikation Testsysteme. Häufig ist auch das Zusammenspiel von mehreren Rechnern zu testen. Die Ressourcen für die Installation der Testsysteme sind in der Regel limitiert. Da die Entwickler die meiste Zeit entwickeln, haben die Testsysteme eine geringe Auslastung. • Eine gemeinsames Benutzen der Testsysteme ist möglich, jedoch erhöht es die Dauer, bis der Test durchgeführt ist, da die Systeme neu installiert bzw. wiederhergestellt werden müssen. • Es ist nicht auszuschließen, dass es Zeitkonflikte gibt, wenn die Developer gleichzeitig auf die Systeme zugreifen wollen. • Backup/Restore bzw. Installation sind in der Regel in der Betriebsabteilung lokalisiert. Die herkömmliche Nutzung der Testsysteme erzeugt hier einigen Aufwand. Lösung [ug] Die Testsysteme der Developer werden mittels mittelgroßer Rechner und Zonen realisiert.. Die Details: • Sparse-root Zones / Whole-root Zones je nach Bedarf. • Daten liegen lokal • Automatische Erzeugung der Zone • Automatische Systemkonfiguration in der Zone mit sysidcfg • Automatische IP-Adressenverwaltung • Der Developer wird Applikations-Administrator mit root-Zugang • Zu testende Software wird lokal installiert. • Option: Software-Installation (teilweise) per mount Bewertung [ug] Dieser Anwendungsfall hat die folgenden Eigenschaften: • Die Betriebsabteilung hat viel weniger Testsysteme zu betreiben, jedes neue Testsystem braucht daher nur Plattenplatz und keinen eigenen Rechner mehr. • Das Erstellen der Testsysteme kann voll automatisiert werden, der Aufwand für die Betriebsabteilung ist daher viel geringer. • Die Developer können mehrere Testsysteme gleichzeitig bestehen lassen; nur die gerade gebrauchten müssen hochgefahren werden. Vergleich von Funktionalitäten in den Versionen ist ohne viel Aufwand möglich. • Um einen Test durchzuführen ist keine Wartezeit (f. Restore) oder Koordination (mit anderen Tests auf der Maschine) notwendig.
Ent- Entwickler Entwickler Entwickler Entwickler wickler A B C D E
Globale Zone System
Zeichnung 17: [dd] Anwendungsfall Developer Testsysteme
26 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 3. Anwendungsfälle Stand: 30.11.2009 3.12. Solaris 8 und Solaris 9 Container für die Entwicklung Anforderung [ug] Es sind noch Systeme unter Solaris 8 oder Solaris 9 mit selbst entwickelter Software im Unternehmen in Betrieb und für diese Systeme muss es möglich sein, noch Entwicklung oder Fehlerbehebung von Software zu betreiben. • Betrieb von alten Systemen unter Solaris 8 oder Solaris 9 noch notwendig • Selten benutzte Entwicklungssysteme sind relativ teuer (laufende Wartung) • Migration der Entwicklung auf aktuelle Systeme garantiert nicht die Lauffähigkeit der entwickelten Software auf den Alt-Systemen.
Lösung [ug] Auf einem aktuellen System unter Solaris 10 werden Solaris 8 bzw. Solaris 9 Zonen mit installierter Entwicklungsumgebung für das entsprechende Betriebssystem eingerichtet. Die Details: • Branded Zones, d.h. in der Zone ist eine Umgebung eines älteren Solaris aktiv • Installation eines archivierten Altsystems • CPU Ressource Management auf Basis des Solaris Fair Share Scheduler • Memory Ressource Management
Bewertung [ug] Dieser Anwendungsfall hat die folgenden Eigenschaften: • Die Anwendungen werden mit der ursprünglichen Version betrieben und weiterentwickelt. Es ist keine kostenintensive Migration der Anwendung auf eine neue Version notwendig. • Die ursprüngliche Entwicklungssoftware kann weiter benutzt werden; es gibt keine Kompatibilitätsprobleme. • Es kann aktuelle Hardware mit Solaris 10 als Basis benutzt werden. • Die Environment-Kosten wie Strom und Kühlung sind geringer, die Leistung ist höher als bei einem alten Rechner. • Die weiterentwickelte Software kann sowohl auf einem System unter Solaris 8 oder Solaris 9 als auch in einem System in einer entsprechenden Branded Zone installiert und betrieben werden.
27 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 3. Anwendungsfälle Stand: 30.11.2009 3.13. Solaris 8 und Solaris 9 Container als Revisionssysteme Anforderung [ug] Aus rechtlichen Gründen oder wegen Anforderung der Revision ist es notwendig, bestimmte Systeme unter Solaris 8 oder Solaris 9 über Jahre hinweg verfügbar zu haben. • Betrieb von alten Systemen unter Solaris 8 oder Solaris 9 wird teuer (Wartung). • Alte Hardware, teilweise außerhalb der Wartung. • Migration auf aktuellere Systeme ist teuer. • Migration auf aktuelles Betriebssystem/aktuelle Hardware erfordert neue Software-Version.
Lösung [ug] Die Altsysteme werden in Solaris 8 bzw. Solaris 9 Containern auf einem aktuellen Solaris 10 System betrieben. Die Details: • Branded Zones, d.h. in der Zone ist eine Umgebung eines älteren Solaris aktiv (Kochbuch) • Installation eines archivierten Altsystems • CPU Ressource Management auf Basis des Solaris Fair Share Scheduler • Memory Ressource Management • Applikations-Administrator / Zugang für Alt-System Administrator mit root-Zugang
28 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 3. Anwendungsfälle Stand: 30.11.2009 3.14. Hosting für verschiedene Firmen auf einem Rechner Anforderung [ug] Ein Application Service Provider betreibt Systeme für verschiedene Firmen. Die Systeme sind nicht ausgelastet. Lösung [ug] Die Applikationen werden in Zonen auf einem Rechner konsolidiert. Die Details: • Getrennte Filesysteme für jede Zone • Option: Integration der Server in die Firmennetze per NAT • Option: Software-Installation per mount Bewertung [ug] Dieser Anwendungsfall hat die folgenden Eigenschaften: • Der Application Service Provider spart RZ-Platz, Energie und Kühlung. Er kann daher seine Dienstleistung günstiger anbieten. • Der Kunde des ASP kann die Dienstleistung günstiger einkaufen.
Firmen-Netz C
Firmen-Netz Firmen-Netz B D
Firmen-Netz Public Firmen-Netz A Netzwerk E
NAT-
Firma Firma Firma Firma Firma A B C D E
Globale Zone System
Zeichnung 18: [dd] Anwendungsfall Hosting für verschiedene Firmen auf einem Rechner
29 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 3. Anwendungsfälle Stand: 30.11.2009 3.15. SAP Portale in Solaris Containern Anforderung [da] Der Betrieb von SAP Systemumgebungen wird stetig komplexer. Daraus ergeben sich: • Applikationsspezifische Anforderungen • Standardisierungsvorgaben • Einfache Kommandos und Scripte zur Basis-Administration • Automatisierungsmöglichkeit betriebsrelevanter Prozesse • Anforderungen zur Kostenreduzierung • Einfache Konsolidierungsmöglichkeiten durch Solaris Container • Softwarelizenzen (Virtualisierungstools, Volume Manager, Snapshot Technologien, ...) • Optimierung der Systemauslastung • Hochverfügbarkeitsanforderungen • Flexibilität durch verschiebbare Container • Erhöhte Datensicherheit • „Komplexe“ Kundenanforderungen • Klonen von SAP-Systemen ohne Downtime • Neue SAP Installationsumgebungen in Minuten • Minimieren / Optimieren von Upgrade-Zeiten • Versionierung von SAP Systemen Lösung [da] Betrachtet man aktuelle SAP Systemlandschaften, so stellt man fest, dass 70-80% der Systeme nicht produktive Systeme sind. Diese erfordern jedoch den größten Pflege- und Administrationsauf- wand und verursachen somit die meisten Kosten. Daher wurde für diese Systeme eine „Easy-Start“ Lösung erarbeitet, die in „Sun Solaris und SAP“ beschrieben wird: http://de.sun.com/servicessolutions/virtualization/ressourcen.jsp • Alle SAP Applikationen werden in Solaris 10 Containern auf Shared Storage betrieben • Whole-root Zones bieten dem SAP Betrieb die benötigte Flexibilität und Sicherheit • ZFS als Basis für die Containerimplementierung, zur Downtime-Minimierung für SAP Systeme • Ein Toolset, bestehend aus verschiedenen Scripten, ermöglicht den schnellen und einfachen Aufbau einer Virtualisierungslösung mit Solaris Containern und ZFS für SAP Systeme. Bewertung [da] Dieser Anwendungsfall hat die folgenden Eigenschaften. • Schnelle Einführung der Container und ZFS Technologie • Die Betriebsabteilung hat geringe Aufwände bei der Erzeugung der Zonen. • Großer Konsolidierungseffekt • Hohe Flexibilität
Zeichnung 19: [da] Anwendungsfall SAP-Portale in Solaris Containern
30 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 3. Anwendungsfälle Stand: 30.11.2009 3.16. Upgrade- und Patchmanagement in einer virtuellen Betriebsumgebung Anforderung [da] Die Virtualisierung mittels Solaris Containern ermöglicht die Loslösung der Anwendung von der Hardware. Eine Anwendung kann so sehr einfach auf verschiedenen Servern betrieben werden. Der Rechenzentrumsbetrieb muss die Verfügbarkeit dieser Anwendungen durch geeignete Maßnahmen sicherstellen. Dies beinhaltet die Anforderungen an geplante Downtimes, aber auch die Anforderung zur Absicherung gegen ungeplante Downtimes. Geplante Downtimes sind für die Wartung jeder IT- Infrastruktur notwendig. Die weitaus meisten geplanten Downtimes werden für die Aktualisierung (Patchen) der Systeme benötigt. Lösungen, die nur den Schwerpunkt auf den Schwenk einer Anwendung von einer Maschine auf eine andere legen, gehen daher am eigentlichen Problem völlig vorbei. Viel wichtiger ist ein einfaches und automatisiertes Release Management für das gesamte Betriebssystem. Die Downtimes für das Aktualisieren der Applikation und die des Betriebssystems (OS) in einer virtualisierten Umgebung können daher unabhängig voneinander betrachtet werden. Lösung [da] Durch den Einsatz von Live Upgrade und Update-on-Attach in Verbindung mit ZFS ergeben sich für den Rechenzentrumsbetrieb die benötigten Voraussetzungen für ein effizientes Release Management. Das Einspielen eines Kernel-Patches für ein Betriebssystem bedeutet nicht mehr zwangsläufig auch eine Downtime der Applikation. Die Betriebssystem-Aktualisierung mittels Live Upgrade kann im laufenden Betrieb erfolgen. Die Aktivierung erfolgt zu einem späteren, planbaren Zeitpunkt, der in vielen Rechenzentren in den Service Level passt. Solaris Live Upgrade ist das optimale Verfahren, um einen Upgrade für ein solches „virtualisiertes“ System durchzuführen oder Patches einzuspielen. Das Verfahren zeichnet sich insbesondere durch den Einsatz von ZFS dadurch aus, dass die Länge des benötigten Wartungsfensters 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 Zeichnung 20: [da] Live Upgrade Anwendungen mit verschiedenen Wartungsfenstern zusammen auf einem System betrieben werden, kann ein Live Upgrade nicht durchgeführt werden. 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 der gleichen Betriebssystemversion verschoben werden. Dies Zeichnung 21: [da] Update-on-Attach geschieht geplant in dem jeweils verfügbaren Zeitfenster der Anwendung. Das Konzept wurde in einem WhitePaper u.a. unter folgendem Link veröffentlicht: http://wikis.sun.com/display/SAPonSun/Links+(to+SAP+and+or+Solaris+topics ) Bewertung [da] Dieser Anwendungsfall hat u.a. die folgenden Eigenschaften • Minimale Downtime erforderlich durch Live Upgrade & ZFS • Hohe Flexibilität und „Planbarkeit“ durch Update-on-Attach • Hohe Sicherheit durch „Rollback“ Möglichkeiten • Einfache Administration bzw. einfacher Betrieb • Technologien sind lizenzkostenfrei in Solaris 10 verfügbar
31 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 3. Anwendungsfälle Stand: 30.11.2009 3.17. „Flying Zones“ - Service-orientierte Solaris Server Infrastruktur Anforderung [os] Eine hochverfügbare Virtualisierungsplattform zum Betrieb geschäftskritischer Anwendungen sollte folgenden Anforderungen genügen: • Aufbrechen der starren Abhängigkeit von Services und Hardware • Applikationsorientierte und Workload optimierte Ressourcenauslastung • keine physische Trennung der Produktions und Integrationsumgebungen • Katastrophenfall-Funktionalität Lösung [os] Die geschäftskritischen Anwendungen werden in Solaris 10 Zonen sowohl auf SPARC als auch auf X64-Systemen betrieben. Katastrophenfall-Funktionalität und das standortübergreifende Verschieben von Zonen erfolgt innerhalb eines Grid Cluster mit Hilfe des Sun Cluster 3.1. Die Details: • Sparse-root Zones, d.h. die Zonen erben möglichst alles von der globalen Zone. • Manuelles Verschieben von Zonen • Automatisches Failover der Zonen mit SC 3.1, Container Überwachung mit SC 3.1 oder optional Überwachung auf Ebene der Anwendungen durch Spezialwerkzeuge • CPU Ressource Management auf Basis des Solaris Fair Share Scheduler • Memory Ressource Management • Applikations-Administrator mit root-Zugang • Vermessung des Workloads und der Ressourcenanforderungen auf einem dedizierten Staging Server des Grid Clusters (Zeichnung) Bewertung [os] Dieser Anwendungsfall hat die folgenden Eigenschaften: • Bis zu 24 Grid Cluster (mit bis zu 8 Knoten) basierend auf SPARC oder Sun X64-Systemen. Mit bis zu 8 Zonen pro Solaris Instanz werden durchschnittliche CPU-Auslastungen von bis zu 60 % erreicht. • Konsolidierungsfaktor von aktuell durchschnittlich 5, d.h. es werden signifikante Einsparungen bei Platz, Stromverbrauch und Klimatisierung erzielt. • Deutliche Effizienzsteigerungen im Betrieb durch Einsatz einer standardisierten Umgebung (nur 1 OS-Typ, nur 2 Kernel- und CPU-Architekturen) • Staging Server als Teil des Grid Clusters ermöglicht das genaue Vermessen der Ressourcenanforderungen und eine detaillierte Kapazitätsplanung für das Grid Cluster. • Produktions- und Integrationsumgebungen werden gemischt und standortübergreifend betrieben. Im Katastrophenfall werden Integrationsumgebungen heruntergefahren und Produktionsumgebungen auf den Knoten des verbliebenen RZ gestartet.
Produk- Integra- Produk- Integra- Produk- Integra- Produk- Integra- Produk- Integra- Produk- Integra- Produk- Integra- tion tion tion tion tion tion tion tion tion tion tion tion tion tion RZ1 Globale Zone Globale Zone Globale Zone System System System
Staging Server Produk- Integra- Produk- Integra- Produk- Integra- Produk- Integra- Produk- Integra- Produk- Integra- tion tion tion tion tion tion tion tion tion tion tion tion RZ2 Globale Zone Globale Zone System System
Zeichnung 22: [os] Anwendungsfall „Flying Zones“ - Service Orientierte Solaris Server Infrastruktur
32 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 3. Anwendungsfälle Stand: 30.11.2009 3.18. Solaris Container Cluster (aka „zone cluster“) Anforderung [hs] • In einer virtualisierten Umgebung auf der Basis von Solaris Containern soll dem Administrator auch die Verwaltung „seiner“ Clusterumgebung übergeben werden • Die Verwendung von „capped“ Containern zur Minimierung von (Oracle) Lizenzkosten soll auf Oracle RAC (Real Application Cluster) Umgebungen ausgeweitet werden (Zertifizierung durch Oracle ist heute (Juni 2009) noch nicht abgeschlossen. Lösung [hs] Durch die Implementierung von Solaris Container Clustern werden virtuelle Cluster implementiert, bei denen Container die virtuellen Knoten des Clusters bilden. Der Administrator der globalen Sun Cluster Umgebung erschafft das virtuelle Cluster und weist ihm die notwendigen Ressourcen zu; so wie der globale Administrator die Ressourcen einzelnen Containern zuweist. Dazu gehören: • Hauptspeicher • CPUs • Dateisysteme • Netzwerkadressen Dem Administrator der lokalen Zonen, die die virtuellen Knoten des Container Clusters bilden, stehen nun alle administrativen Rechte zur Verfügung, hochverfügbare Dienste mit der Hilfe von Sun Cluster zu verwalten. Dazu gehören: • das Anlegen von Ressourcegruppen • das Anlegen von Ressourcen • das Starten und Stoppen von Ressourcegruppen und Ressourcen
Bewertung [hs] Dieser Anwendungsfall hat die folgenden Eigenschaften: • Durchgehende Virtualisierung bis auf die Clusterebene • Delegation der Administration auch des (virtuellen) Clusters an den Container-Administrator • Reduzierung von Lizenzkosten durch den Einsatz von „capped“ Containern auch im Oracle RAC Umfeld (Status der Zertifizierung bei Oracle noch „pending“)
33 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009 4. Best Practices
Das folgende Kapitel beschreibt Konzeptionen zur Umsetzung von Architekturen mit Solaris Containern. 4.1. Konzepte 4.1.1. Sparse-root Zonen [dd] Sparse-root Zonen werden Zonen genannt, an die die folgenden Verzeichnisse von der globalen Zone aus als inherit-pkg-dir "vererbt" werden: – /lib – /platform – /sbin – /usr • Von der OS- und Anwendungssoftware werden die Softwarepakete nur einmal zentral in der globalen Zone installiert und in allen lokalen Zonen als inherit-pkg-dir zur Verfügung gestellt. Ein inherit-pkg-dir ist ein readonly Loopback-Mount aus der globalen Zone an die lokale Zone. Die Packages erscheinen in der lokalen Zone durch entsprechende Einträge in der pkg-Datenbank installiert. • Die Softwarepflege (Update, Patching) von vererbten Packages erfolgt einfach zentral aus der globalen Zone heraus für alle installierten Zonen. • Durch die Vererbung werden Sparse-root Zonen erheblich schneller installiert und gepatched. • /opt wird nicht als inherit-pkg-dir eingerichtet. • Plattenplatz wird für inherit-pkg-dir nur einmal in der globalen Zone auf der Festplatte belegt und mehrfach in den Sparse-root Zonen benutzt. So wird durch eine Sparse-root Zone nur ein minimaler Plattenplatz benötigt, der je nach Architektur und Umfang der Softwareinstallation ca. 70 MB (x86/x64) oder 100MB (SPARC) beträgt. • Programme und Bibliotheken werden genau wie shared Memory nur einmal in den Hauptspeicher geladen. Da Sparse-root Zonen die gleichen Programme und Bibliotheken mit anderen Zonen teilen, wird der Platz im Hauptspeicher nur einmal belegt, unabhängig davon, wie häufig es aufgerufen worden ist und wie viele Zonen es benutzen. Das führt bei häufiger Benutzung der gleichen Software in unterschiedlichen Zonen zu einer Einsparung in benötigtem Hauptspeicher. • Sparse-root Zonen sind nicht dafür geeignet, unterschiedliche Softwarestände in den Zonen zu betreiben, wenn sich diese Software in einem inherit-pkg-dir befindet. Hierfür sind entweder Whole-root Zonen Konfigurationen zu verwenden oder die Software darf nicht in einem inherit-pkg-dir installiert werden. • Benötigen Installationsroutinen von Software Schreibrechte in einem inherit-pkg-dir der lokalen Zone, sollte eine Whole-root Zonenkonfiguration gewählt werden.
4.1.2. Whole-root Zonen [dd] Whole-root Zonen besitzen keine inherit-pkg-dir, d.h. bei der Erzeugung der Zone werden die Packages der globalen Zone in die lokale Zone kopiert. Ausgenommen hiervon sind Packages, die ausschließlich für die Benutzung in der globalen Zone vorgesehen sind (z.B. der Kernel und die Treiber) oder Packages, die mit pkgadd -G installiert wurden. • Whole-root Zonen haben eine nahezu vollständige Unabhängigkeit von der globalen Zone, da die Packages in Kopie vorliegen und separat modifiziert und gepatched werden können. • Der benötigte Platz für eine Whole-root Zone umfasst ca. den Bedarf einer kompletten Solaris Installation. • Die Erzeugung und das Patchen einer Whole-root Zone erfordert mehr Zeit. • Whole-root Zonen teilen sich bis auf den Kernel keine Programme und Bibliotheken untereinander oder mit der globalen Zone. Deshalb werden sie nochmals in den Hauptspeicher geladen, unabhängig davon, ob eine andere Zone eine eigene Kopie des gleichen Programms bereits in den Hauptspeicher geladen hat. Das führt zu einem erhöhten Bedarf an benötigten Hauptspeicher-Ressourcen durch Whole-root Zonen.
34 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009
4.1.3. Vergleich Sparse-root Zone und Whole-root Zone [dd] Aus den vorangegangenen Betrachtungen ergibt sich ein Vergleich von Sparse-root Zonen zu Whole-root Zonen. In den überwiegenden Fällen werden Sparse-root Zonen eingesetzt.
Sparse-root Zone Whole-root Zone Benötigter Plattenplatz 70 - 100 MB 2600 - 3600 MB Schnelle Erzeugung von Zonen + - Schnelles Patchen pro Zone + - Zentrale Softwareinstallation und Pflege + + Effektive Hauptspeichernutzung + - Unabhängige Installation, Modifikation und Patch von - + Betriebssystem-Teilen in der Zone Schreibmöglichkeit in Systemverzeichnissen - + Tabelle 3: [dd] Vergleich Sparse-root Zone und Whole-root Zone
Globale Sparse-root Whole-root Zone / / / /var /var /var /usr --> lofs inherit-pkg-dir /usr /lib --> lofs inherit-pkg-dir / /sbin --> lofs inherit-pkg-dir /sbinlib /platform --> lofs inherit-pkg-dir /platform ~ 3.6 GB ~100 MB ~3.6 GB Zeichnung 23: [dd] Schematischer Vergleich Sparse-root Zone und Whole-root Zone
4.1.4. Software in Zonen [dd] Für Anwender und Betreiber stellt sich die Frage, ob ihre Software in einer lokalen Zone läuft und von dem Softwarehersteller dafür auch zertifiziert ist. Anwendungen können nach http://developers.sun.com/solaris/articles/zone_app_qualif.html zur Nutzung in lokalen Zonen qualifiziert werden. Grundsätzlich gilt, dass Anwendungen, die mit normalen Benutzerprivilegien auskommen, auch in einer lokalen Zone laufen. Solche Software, die besondere Privilegien erfordert oder unter root-Rechten laufen muss, sollte gesondert betrachtet werden. Als kritisch sind hier vor allem der direkte Zugriff auf Geräte, Gerätetreiber, eigene Kernel-Module, ISM oder der direkte Zugriff auf das Netzwerk und Netzwerkmodule anzusehen. Details dazu sind unter „Bringing your application Into the Zone“ http://developers.sun.com/solaris/articles/application_in_zone.html nachzulesen. Wenn die Software grundsätzlich in einer lokalen Zone lauffähig ist, ist weiterhin der Installations- und Konfigurationsmechanismus der Anwendung zu betrachten. So muss darauf geachtet werden, dass während der Installation in lokalen Zonen keine Schreiboperationen in inherit-pkg-dir notwendig sind, z.B. bei einer Installation nach /usr oder /usr/local, wenn bei einer sparse-root Zone / usr ein inherit-pkg-dir ist.
35 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009
4.1.5. Softwareinstallationen in Solaris und Zonen [dd] Die Frage der Art und Weise der Softwareinstallation in Zonen bestimmt im hohen Maße die Verzeichnisstruktur der Zonen. Vor der Erzeugung der Zonen sollte diese Frage ausgiebig auch vor dem geplanten Einsatzzweck der Zone diskutiert werden. Generell sind die folgenden Formen der Softwareinstallation in Solaris möglich: • Softwareinstallation aus einem Archiv - im Folgenden als non-pkg-Software bezeichnet – Die Software wird per Installationsskript aus einem Archiv oder einem Verzeichnis durch Kopieren installiert. – Es sind keine Informationen über die installierte Software in der pkg-Datenbank enthalten. – Die Softwareverwaltung muss durch Werkzeuge der Software selbst oder durch einfache Solaris Programme wie cp, mv, rm, ... erfolgen. • Softwareinstallation als Package mit pkgadd - im Folgenden als pkg-Software bezeichnet – Die Software wird im pkg-Format verteilt und mit pkgadd installiert. – Die pkg-Informationen sind in der pkg-Datenbank unter /var/sadm/install vorhanden. – Zur pkg-Verwaltung wie Update, Patch, Remove und Zoneninstallation wird die pkg- Datenbank verwendet. Weiterhin muss entschieden werden, ob Software bei der Installation in alle Zonen (globale und lokale) oder nur eine bestimmte installiert werden soll und wer die Software installieren darf (die globale Zone oder die lokale Zone). Die folgenden Abschnitte beschreiben unterschiedliche Szenarien der Softwareinstallation im Zusammenhang mit der Nutzbarkeit der Software. 4.1.5.1. Softwareinstallation durch die globale Zone - Nutzung in allen Zonen • non-pkg-Software – Software A wird durch die globale Zone z.B. in /software/A installiert. – /software/A wird als Verzeichnis allen lokalen Zonen readonly zur Verfügung gestellt (z.B. zonecfg: add fs). – /software/A/cfg ist ein Softlink nach z.B. /opt/A/cfg und enthält die zonenabhängige Konfiguration. – /software/A/data ist ein Softlink nach z.B. /opt/A/data und enthält die zonenabhängigen Daten. – Die Software ist in allen Zonen nutzbar. – Nur die Konfiguration und die Daten der Software können von den Zonen modifiziert werden. • pkg-Software – Software P wird durch die globale Zone mit pkgadd in die globale und alle lokalen Zonen installiert. – In allen Zonen wird ein Eintrag in die pkg-Datenbank vorgenommen. – Wenn die zu installierende Datei sich nicht in einem inherit-pkg-dir befindet, wird die Datei in das entsprechende Verzeichnis kopiert. – Durch entsprechende Softlinks können die Konfigurations- und Datenbereiche von Software P in für die lokalen Zonen schreibbare Bereiche gelegt werden (siehe non-pkg- Software). – Die Software ist in allen Zonen nutzbar. – Nur die Konfiguration und die Daten der Software können von den Zonen modifiziert werden. 4.1.5.2. Softwareinstallation durch die globale Zone - Nutzung in einer lokalen Zone • non-pkg-Software – Software A wird durch die globale Zone z.B. in /zone-z/software/A installiert – /zone-z/software/A wird als Verzeichnis der lokalen Zone z schreibbar zur Verfügung gestellt (z.B. zonecfg: add fs) – Die Konfiguration und die Daten der Software A können von Zone z modifiziert werden, da der Bereich ausschließlich dieser Zone schreibbar zur Verfügung steht. • pkg-Software – Dieser Fall ist mit pkg-Software nicht zu empfehlen. In diesem Falle sollte die Software besser direkt in der lokalen Zone installiert werden (Installation durch die lokale Zone - Nutzung in der lokalen Zone).
36 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009 4.1.5.3. Softwareinstallation durch die globale Zone - Nutzung in der globalen Zone • non-pkg-Software – Software A wird durch die globale Zone z.B. in /software/A installiert – /software/A steht als Verzeichnis der globalen Zone schreibbar zur Verfügung. – Die Konfiguration und die Daten der Software A können durch die globale Zone modifiziert werden, da der Bereich ausschließlich dieser Zone schreibbar zur Verfügung steht. • pkg-Software – Software P wird in die globale Zone mit pkgadd -G installiert. – In der globalen Zone wird ein Eintrag in die pkg-Datenbank vorgenommen. – Die Software ist nur in der globalen Zone nutzbar. – Die Konfiguration und die Daten der Software sind von der globalen Zone aus modifizierbar.
4.1.5.4. Installation durch die lokale Zone - Nutzung in der lokalen Zone • non-pkg-Software – /software/A steht als Verzeichnis der Zone schreibbar zur Verfügung. – Software A wird durch die Zone z.B. in /opt/software/A installiert. – Die Konfiguration und die Daten der Software A können durch die Zone modifiziert werden, da der Bereich ausschließlich dieser Zone schreibbar zur Verfügung steht. • pkg-Software – Software P wird durch die Zone mit pkgadd -G installiert. – Das Installations- und Konfigurationsverzeichnis des Packages muss der Zone schreibbar zur Verfügung stehen. Ist dieses nicht der Fall, z.B. mit /usr/local wenn /usr bei einer sparse-root Zone ein inherit-pkg-dir ist), kann z.B. in der globalen Zone ein Softlink /usr/local --> ../../opt/local gesetzt werden. Dieser zeigt in der lokalen Zone mit /opt/local in einen schreibbaren Bereich. – Für die Zone wird ein Eintrag in die pkg-Datenbank vorgenommen. – Die Software ist nur in dieser Zone nutzbar. – Die Konfiguration und die Daten der Software sind von der Zone aus modifizierbar.
37 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009
4.1.6. Storage-Konzepte 4.1.6.1. Storage für das root-Filesystem der lokalen Zonen [ug] Normalerweise reicht es aus, wenn mehrere Zonen sich ein Filesystem teilen. Wenn der Einfluss von den Zonen auf das Filesystem entkoppelt werden soll wird empfohlen, jeder Zone ein eigenes Filesystem zu geben. Mit dem neuen ZFS Filesystem von Solaris 10 ist das mit geringem Aufwand möglich (ab Solaris 10 6/06). Seit Solaris 10 10/08 kann ZFS als zoneroot verwendet werden. Vor Solaris 10 10/08 kann eine Zone zwar auf ZFS betrieben werden, ein Upgrade ist aber nicht supportet; daher ist mit Zonen auf ZFS Solaris 10 10/08 dringend zu empfehlen. Mit der Verfügbarkeit von iSCSI in Solaris 10 8/07 als Client Initiator und als Target Emulator, kann auch diese Technologie als Speichertechnologie für root-Filesysteme von Zonen verwendet werden. Durch die flexible Nutzung von iSCSI-Volumes an verschiedenen Systemen mit Netzwerkzugang, erhöht sich dadurch die Beweglichkeit von Zonen z.B. im Zusammenhang mit zoneadm detach / zoneadm attach. Für ein System, auf dem eine hohe Zahl an Zonen installiert werden soll, ist zu empfehlen, dass ein Storage-Subsystem mit Cache für die root-Filesysteme eingesetzt wird. Jede OS-Instanz und damit auch jede Zone schreiben in unregelmäßigen Abständen Messages, Log-Einträge, utmp-Einträge usw. auf das root-Filesystem. Die Applikationen nutzen ggf. ebenfalls das root-Filesystem für Logs. Bei vielen Instanzen kann dies zu einem Engpass auf dem Filesystem führen (bei ZFS weniger kritisch). 4.1.6.2. Storage für Daten [ug] Die Planung für den Datenspeicher (Files, Datenbanken) erfolgt in gleicher Weise wie für dedizierte Rechner. Die Speichergeräte werden an den Rechner, der die Zonen enthält, angeschlossen. Die Filesysteme werden in der globalen Zone direkt gemountet und an die Zonen per loopback-mount übergeben (zonecfg:add fs). Dann können die Filesysteme auch von anderen Zonen zum Datenaustausch genutzt werden, sofern konfiguriert. Alternativ ist es möglich, Filesysteme (zonecfg:add fs) direkt beim Booten der Zone durch den zoneadmd(1M) mounten zu lassen und diese so einzelnen Zonen exklusiv zur Verfügung zu stellen. Da in diesem Fall innerhalb der Zone kein Zugriff auf das raw- und das block-Device möglich ist, erfolgt der Mount eines solchen Filesystems während des Bootens der Zone mit zoneadm -z
38 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009
4.1.6.4. Rootplatten Layout [dd] Je nach Verfügbarkeitsanforderungen werden die root-Platten innerhalb eines Systems über interne Platten gespiegelt oder über unterschiedliche Controller und externe Storage Devices bereitgestellt. Die gesamte OS-Installation wird heute bereits in vielen Fällen in / installiert, d.h. ohne weitere Unterteilung in /usr oder /opt. Lediglich /var ist als separates Filesystem einzurichten, um ein Überlaufen von / durch z.B. große log-Files zu vermeiden. Weiterhin ist zusätzlicher Platz für ein später geplantes Live Upgrade des Systems vorzusehen. Wenn die Anzahl benötigter Slices pro Platte erschöpft ist, kann /var/crash in /var mit hineinverlagert werden oder die Benutzung von Softpartitionen in Erwägung gezogen werden. Oft wird /usr/local als schreibbares Verzeichnis in einer lokalen Zone benötigt. Wenn z.B. eine Sparse-root Zone benutzt wird und /usr ein inherit-pkg-dir ist, kann in /usr/local in einer lokalen Zone nicht geschrieben werden. Empfehlenswert ist in solchen Fällen, in der globalen Zone einen Softlink z.B. /usr/local -> ../../opt/local anzulegen. Da /opt normalerweise für jede Zone separat ist, besteht hier für jede Zone Schreibrecht. Wichtig ist, relative Links zu benutzen, damit auch ein Zugriff aus der globalen Zone auf z.B. /zones/zone-z/root/usr/local im richtigen Verzeichnis ankommt. Die Software der Companion DVD installiert sich nach /opt/sfw. Wenn diese zentral installiert werden soll, wäre /opt/sfw zusätzlich als inherit-pkg-dir festzulegen. StarOffice installiert sich beispielsweise nach /opt/staroffice. Die Größen der Filesysteme variieren je nach Art und Umfang der Installationen. Ein konkretes Rootplattenlayout ist hier dargestellt ( 5.1.3 Rootplattenlayout ). 4.1.6.5. ZFS in einer Zone [ug] Mit Solaris 10 6/06 ist erstmals das neue Filesystem ZFS verfügbar. Da ZFS nicht auf einem special device basiert, das gemountet wird, ist ein Mechanismus im zonecfg-Kommando implementiert, mit dem man ein ZFS Filesystem an eine Zone weitergeben kann. Dies geht mit dem zonecfg-Unterkommando add dataset . Das ZFS Filesystem ist dann in der Zone sichtbar und kann dort verwendet und (limitiert) administriert werden. Bei ZFS können Attribute eines Filesystems gesetzt werden, die sofort aktiv werden. Hier sind die Attribute quota (maximal belegbarer Plattenplatz) und reservation (garantierter Plattenplatz) für das Filesystem interessant. Wenn ein Filesystem mit add dataset einer Zone übergeben ist, dann kann der Administrator der globalen Zone die Attribute quota und reservation setzen. Der Administrator der lokalen Zone kann diese Parameter nicht verändern, um keinen Zugriff auf Ressourcen anderer Zonen zu nehmen. ZFS erlaubt es, Filesysteme hierarchisch zu unterteilen. Dies gilt auch für die einer Zone weitergegebenen ZFS Filesysteme, die vom Administrator der Zone weiter unterteilt werden können. Sind die Attribute quota und reservation für das übergebene Filesystem gesetzt, gilt die Limitierung auch in der Zone weiter. Somit sind die in der Zone nutzbaren Ressourcen beschränkt. Seit Solaris 10 5/08 gibt es für ZFS Filesysteme benutzerdefinierbare Attribute. Gerade im Falle von an Zonen weitergegebenen ZFS Filesystemen sind diese gut dafür nutzbar, die Verwendung der ZFS Filesysteme zu dokumentieren ( 5.1.12.10 User-Attribute für ZFS in einer Zone ).
39 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009
4.1.6.6. Möglichkeiten zur Benutzung von ZFS in lokalen Zonen [hes] Je nach Art und Weise der Konfiguration von ZFS in Zonen ergeben sich unterschiedliche Benutzungsmöglichkeiten von ZFS in Zonen. ZFS-Operation in Zuordnung eines Zuordnung eines Zuordnung eines Zuordnung einer lokalen Zone einzelnen ZFS in ZFS-Datasets zu ZFS-Volumens des ZFS via einer Zone - einer Zone/ zu eines Zone lofs legacy Mount Erzeugung des ZFS in der lokalen Zone umount nein ja ja nein destroy nein ja nein nein snapshot erstellen nein ja nein nein zfs set nein ja nein nein mount des ZFS in nein nein nein ja globaler Zone sichtbar Tabelle 4: [hes] Möglichkeiten zur Benutzung von ZFS in lokalen Zonen
4.1.6.7. NFS und lokale Zonen [ug] Der Einsatz von Zonen verändert bezüglich NFS nichts in der globalen Zone. Eine lokale Zone kann Filesysteme von NFS Servern mounten. Die folgenden Einschränkungen sind zu beachten: • Eine lokale Zone kann nicht als Solaris NFS Server eingesetzt werden, also keine Filesysteme selber freigeben, da der NFS-Service im Kernel abläuft und noch nicht in einer lokalen Zone ablaufen kann. • Mit einem Userland-NFS Server (z.B. Sourceforge.net: unfs3, nicht Bestandteil von Solaris) ist es möglich, eine Zone als NFS-Server einzusetzen. • Eine lokale Zone sollte ein Filesystem nicht von seiner globalen Zone mounten. Das scheint zwar möglich zu sein, weil der mount möglich ist, es kann aber zu Datenverlusten kommen (Bug 5065254)
4.1.6.8. Volume-Manager in lokalen Zonen [ug] Eine häufige Frage ist es, wie man einen Volume-Manager in einer lokalen Zone nutzt. Das ist leider nicht möglich. Ein Volume-Manager wie der Solaris Volume Manager (SVM) oder der Veritas Volume Manager (VxVM) braucht zum Einen Treiber, die in einer lokalen Zone nicht extra geladen werden können. Zum Anderen erzeugt ein Volume-Manager Device Nodes in /dev, mit denen auf die erzeugten Volumes zugegriffen wird. Die Berechtigung zum Erzeugen solcher Device Nodes existiert aber innerhalb einer lokalen Zone nicht, da dies ein Sicherheitsloch darstellen würde. Wenn nämlich eine Zone einen beliebigen Device Node erzeugen kann, dann könnte man als Administrator einer Zone den Device Node einer Platte erzeugen, die der Zone nicht zugewiesen ist und auf die Daten lesend oder schreibend zugreifen. Daher ist durch Einschränkung der Privilegien einer Zone das Erzeugen von Device Nodes innerhalb einer lokalen Zone unterbunden. Ein Volume Manager braucht diese Funktion des Kernels aber und kann daher innerhalb einer lokalen Zone nicht funktionieren.
40 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009
4.1.7. Netzwerk-Konzepte 4.1.7.1. Einführung Netzwerke und Zonen [dd] Eine Netzwerk-Adresse ist bei der Konfiguration einer Zone nicht zwingend vorgeschrieben. Dienste in einer Zone sind von außerhalb aber nur über das Netzwerk zu erreichen, deshalb ist in der Regel mindestens eine Netzwerk-Adresse pro Zone notwendig (konfigurierbar mit zonecfg). Die Netzwerk-Adresse einer Zone kann als virtuelles Interface auf ein beliebiges physikalisches Interface (Shared IP-Instanz) oder direkt auf ein, der Zone exklusiv zugeordnetes, physikalisches Interface (Exclusive IP-Instanz) gelegt werden. Die unterschiedlichen Typen der IP-Instanzen werden in ( 4.1.7.4 Exclusive IP-Instanz ) erläutert. Routen für die Netzwerke der lokalen Zonen lassen sich bei shared IP-Instanzen in der Zonenkonfiguration eintragen. Beim Booten der Zone wird so sichergestellt, dass der entsprechende Routing-Eintrag in der globalen Zone existiert. Der IP-Stack der globalen Zone enthält und verwaltet alle Routen der Shared IP-Instanz. Exclusive IP-Instanzen verwalten ihre eigenen Routing-Tabellen und sind genau einer Zone zugeordnet.
4.1.7.2. Verwaltung der Netzwerk-Adressen für Zonen [ug] DHCP ist für die Adressen von Zonen mit shared IP-Instanzen nicht möglich, da DHCP auf der HW-Adresse des Netzwerk-Interfaces basiert. Zonen nutzen eine virtuelle Adresse auf einem shared Netzwerk-Interface: sie haben daher die gleiche MAC-Adresse wie das Interface in der globalen Zone. Die Verwaltung der Netzwerk-Adressen für Zonen muss daher auf andere Weise erfolgen. Es sind prinzipiell die folgenden Arten der Verwaltung möglich: • Manuelles Führen einer Liste. Bei der Zonen-Konfiguration muss daher die IP-Adresse in der Liste markiert werden. • Vor-Definieren der IP-Adressen mit dem Zonen-Namen im Name-Service. Bei der Zonen-Konfiguration kann ein Script daher die IP-Adresse der Zone automatisch ermitteln, wenn der IP-Name aus dem Zonen-Namen berechnet werden kann (Kochbuch). • Wenn auf einem System viele Zonen eingerichtet werden sollen, dann ist es empfehlenswert einen ganzen Bereich vorab für das System zu allozieren, bei dem die Netzwerk-Adresse gleich dem vorgesehenen Zonennamen ist. Damit ist eine eindeutige Zuordnung gewährleistet. • Andere Integration in die IP-Namensvergabe des Ziel-Environments. Hier ist eine Integration in die organisatorischen Prozesse der IP-Vergabe des Unternehmens gemeint.
4.1.7.3. Shared IP-Instanz und das Routing zwischen Zonen [dd] Jede Zone verfügt über mindestens eine eigene IP-Adresse und eigene TCP- und UDP- Portnummern. Anwendungen, die in Zonen benutzt werden, binden sich auf die in der Zone sichtbaren IP-Adressen und nutzen diese auch als Absenderadressen. Dadurch wird eine logische Netzwerktrennung zwischen den Zonen realisiert. Wenn Zonen sich durch entsprechende Adressvergabe in unterschiedlichen logischen Subnetzen befinden und eine Kommunikation der Zone mit anderen Netzen notwendig ist, müssen für jede Zone eigene Routen existieren. Diese werden durch Zonenkonfiguration in der globalen Zone gesetzt, da die Routingtabelle sich im TCP/IP-Stack befindet, der zwischen allen Zonen shared wird (Shared IP-Instanz). Ist so eine Route für eine Zone gesetzt, findet eine Inter-Zonen-Kommunikation (lokale Zone zu lokale Zone) direkt über die gemeinsam genutzte IP-Instanz statt. Wenn diese Inter- Zonen-Kommunikation unterbunden werden soll, müssen sogenannte reject-routes eingesetzt werden, die jegliche Kommunikation zwischen zwei IP-Adressen einer IP-Instanz unterbinden. Alternativ kann die Kommunikation zwischen Shared-IP Zonen durch die folgende Konfiguration unterbunden werden: ndd -set /dev/ip ip_restrict_interzone_loopback 1
Diese Konfiguration kann auch in /etc/system gesetzt werden. Ist eine gezielte Kommunikation zwischen zwei lokalen Zonen notwendig, die aber z.B. über einen externen Router, Load Balancer oder Firewall geführt werden soll, müssen NAT-fähige Router eingesetzt werden. Entsprechende Setups werden im Abschnitt 5 . Kochbücher diskutiert.
41 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009
4.1.7.4. Exclusive IP-Instanz [dd] Mit exclusive-IP Instanzen wird eine fast vollständige Trennung des Netzwerkstacks zwischen Zonen erreicht (ab Solaris 10 8/07). Eine Zone mit einer exklusiven IP-Instanz hat ihre eigene Kopie von Variablen und Tabellen, die vom TCP/IP-Stack benutzt werden. Diese Zone hat im Ergebnis eine eigene IP-Routingtabelle, ARP- Tabelle, IPsec-Policies, IP-Filter Regeln oder ndd-Einstellungen. Innerhalb der Zone ist in exklusiven IP-Instanzen die Benutzung von ifconfig(1M) plumb, snoop(1M), dhcp(5) oder ipfilter(5) möglich. Für die Nutzung einer exklusive IP-Instanz wird von der globalen Zone einer Zone ein separates physikalisches oder tagged VLAN-Netzwerkinterface zugewiesen (zonecfg: set ip-type). Tagged VLAN-Interfaces erhalten eigene Namen, die wie folgt gebildet werden: Interface = Interfacename
Instance #0 Instance #1 Global Zone Zone A Global Zone Zone “bar” Zone “foo” shared IP shared IP exclusive IP apps apps apps apps apps
tcp udp tcp udp tcp udp tcp udp tcp udp 129.146.89.2 129.146.89.3 129.146.89.2 129.146.89.3 10.0.0.1 IP/ARP/IPsec IP/ARP/IPsec IP/ARP/IPsec
ce0 bge1000 ce0 bge1000 Zeichnung 24: [dd] Gegenüberstellung Shared-IP Instanz (links) und Exclusive IP-Instanz (rechts)
4.1.7.5. Firewalls zwischen Zonen (IP Filter) [dd] Firewalls können beim Einsatz von Zonen zur Paketfilterung oder für NAT eingesetzt werden. So lässt sich z.B. der Datenverkehr zwischen bestimmten Zonen komplett unterbinden bzw. für einen Netzwerkport limitieren. Soll die Firewall auf dem System selbst zusammen mit den Zonen zum Einsatz kommen, können generell zwei Varianten unterschieden werden: • Für Shared-IP Zonen: Die Firewall muss mit ihren Regeln in der globalen Zone konfiguriert, gestartet und administriert werden. • Für Exclusive-IP Zonen: Die Firewall muss mit ihren Regeln in der jeweiligen lokalen Zone konfiguriert , gestartet und administriert werden. IP Filter ist in Solaris 10 und OpenSolaris enthalten und wurde so erweitert, dass es auch als Firewall zwischen Shared-IP Zonen eines Systems eingesetzt werden kann. (Kochbuch: 5.2.5 IP Filter zwischen Shared-IP Zonen auf einem System ) (Kochbuch: 5.2.6 IP Filter zwischen Exclusive-IP Zonen auf einem System )
42 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009
4.1.7.6. Zonen und Limitierungen im Netzwerk [dd] Zonen haben im Zusammenhang mit Netzwerkkonfigurationen verschiedene Limitierungen. Die folgende Tabelle zeigt die Unterschiede aufgeteilt nach Zonen- und IP-Instanz Typ. Einige Funktionalitäten können in Zonen selbst konfiguriert und benutzt werden (+), wirken sich lediglich auf die Funktionsweise von Zonen aus oder können von Diensten in einer Zone benutzt werden. Funktionalität Globale Zone Lokale Zone mit Lokale Zone mit shared exclusive IP-Instanz IP-Instanz DHCP-Client + + - DHCP-Server + + - ifconfig(1M) + + - IPfilter + + Auswirkung auf Zone (Filter) IPMP + + Nutzbar in Zone (Redundanz) IPQoS + Auswirkung auf Zone (Bandbreite) Auswirkung auf Zone (Bandbreite) IPsec + + Nutzbar in Zone (Kommunikation) Multicast + + - ndd-Parameter + + - NFS-Server + - - RAW-Netzwerkzugriff + + - Routing Daemon + + - Routing Einstellungen + + Auswirkung auf Zone (Routing) snoop(1M) + + - Solaris Network Cache and + - - Accelerator (NCA) Tabelle 5: Zonen und Limitierungen im Netzwerk
43 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009
4.1.8. Zusätzliche Geräte (devices) in Zonen 4.1.8.1. Konfiguration von Geräten (Devices) [ug] Eine Zone benutzt prinzipiell zunächst keine physikalischen Devices. Um Netzwerk-Interfaces exklusiv in einer Zone zu benutzen muss die Zone als exclusive-IP Zone konfiguriert werden (Fehler: Referenz nicht gefunden Fehler: Referenz nicht gefunden ). Disks oder Volumes können mit zonecfg in eine Zone eingebracht werden ( 5.1.12.6 Ein DVD Laufwerk in der lokalen Zone benutzen). Um eine so veränderte Konfiguration zu aktivieren muss die Zone neu gestartet werden. Devices können auch dynamisch mit mknod in eine Zone gebracht werden, ohne dass die Zone heruntergefahren werden muss ( 5.1.12.7 Dynamisches Konfigurieren von Geräten (Devices)). Das Entfernen von Geräten erfolgt durch Entfernen mit zonecfg bzw. bei dynamisch hinzugefügten Devices mit Löschen des Device-Nodes. Prinzipiell können auch andere Geräte wie zum Beispiel serielle Interfaces an lokale Zonen weitergegeben werden. Die Aufgabe des Administrators der globalen Zone bzw. des Verantwortlichen für die Konfiguration der lokalen Zonen ist es, die Verwendung der Devices zu koordinieren und eine Doppelvergabe bzw. doppelte Nutzung aus globaler Zone und lokaler Zone zu vermeiden. 4.1.8.2. Statische Konfiguration von Geräten [ug] Geräte für eine Zone werden bei der Zonenkonfiguration mit zonecfg mit der Anweisung add device definiert. Solaris erzeugt dann das Gerät mittels eines sogenannten Device-Nodes im Filesystem /dev der Zone. Das /dev-Verzeichnis der Zone befindet sich im zonepath der Zone im Unterverzeichnis dev. Das Löschen der Geräte erfolgt durch Löschen in der Konfiguration. Das Device ist dann beim nächsten Reboot der Zone aus deren /dev Verzeichnis entfernt. Hier ist einer der Unterschiede zwischen der globalen Zone und der lokalen Zonen, da bei der lokalen Zone der Device-Node direkt im /dev-Verzeichnis liegt. In der globalen Zone ist in /dev nur ein symbolischer Link zu einem Device-Eintrag in /devices. In /devices. liegen alle vom System erkannten Geräte mit ihren Device-Nodes. Eine Zone ist nicht in der Lage, selbst in ihrem /dev Device-Nodes zu erzeugen, da das Kommando mknod(1M) und der Systemcall mknod(2) in einer lokalen Zone durch Privilegien verboten sind. Weiterhin kann eine Zone selber Filesysteme nur mit der Option nodevices mounten, wodurch die Geräte-Einträge in diesem Filesystem nicht benutzbar sind. Die Sicherheit der Zonen bezüglich Geräten beruht genau auf diesen Maßnahmen, weil eine Zone keinen Zugriff auf Geräte erlangen kann, die nicht für sie konfiguriert sind. 4.1.8.3. Dynamische Konfiguration von Geräten [ug] Ein Reboot der lokalen Zone ist manchmal nicht erwünscht, obwohl man neue Geräte hinzufügen muss, um zum Beispiel einer Datenbank neuen Platz zu beschaffen. Dann kann man der Zone dynamisch neue Geräte hinzufügen, indem man den Vorgang der statischen Gerätekonfiguration nachahmt. Zunächst wird in der globalen Zone mit ls -lL
44 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009
4.1.9. Separate Namensdienste in Zonen [ug] Namensdienste umfassen unter anderem die hosts-Datenbank und die UserIDs (passwd, shadow) und werden mit der Datei /etc/nsswitch.conf konfiguriert, die in der lokalen Zone unabhängig von der globalen Zone existiert. Die Namensdienste sind daher in lokalen Zonen unabhängig von den globalen Zonen definiert. Die wichtigsten Aspekte dazu werden in diesem Abschnitt behandelt. Wenn man der Empfehlung von anderer Stelle in dem Dokument folgt, dass man in der globalen Zone keine Applikationen laufen lässt, dann muss auch die globale Zone nicht in NIS oder LDAP eingefügt werden. Dies limitiert weiter den Zugang von außen und vermindert die Abhängigkeit der globalen Zone von anderen Rechner (Namensdienste Server). 4.1.9.1. hosts-Datenbank [ug] Die Rechner, die mittels Namen ansprechbar sein sollen müssen hier eingetragen werden. Es findet keine automatische Kopie der /etc/hosts von der globalen Zone statt, wenn die Zone installiert wird (ganz im Sinne, dass in der lokalen Zone eine eigene OS Umgebung existiert). Die bessere Alternative ist natürlich, dass man einen Namensdienst wie NIS, DNS oder LDAP verwendet. Bei einer automatischen Installation kann das über eine sysidcfg-Datei eingestellt werden. 4.1.9.2. User-Datenbank (passwd, shadow, user_attr) [ug] Die Benutzer-Einstellungen in den lokalen Zonen können wie bei einem separaten Rechner durch einen Namensdienst ergänzt werden. Zu beachten ist, dass in unterschiedlichen Zonen die User- namen ungleich sein können, insbesondere werden bei der Überwachung aus der globalen Zone (mit ps) die in der globalen Zone konfigurierten Namen angezeigt Eine Kopie der Dateien von der globalen Zone wird nicht empfohlen, ein Namensdienst wie NIS oder LDAP ist besser geeignet. 4.1.9.3. Services [ug] Die /etc/services oder der entsprechende Namensdienst muss ebenfalls an die in der Zone laufenden Applikationen angepasst werden. 4.1.9.4. Projekte [ug] Um in einer lokalen Zone Ressource-Management mit Fair-Share-Scheduler oder Extended Accounting lokal zu betreiben, muss die entsprechende Namensdienst Datenbank in /etc/project oder der entsprechende Namensdienst in der Zone angepasst werden.
45 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009 4.2. Paradigmen Paradigmen sind Design Regeln zum Aufbau von Zonen. Je nach Anwendung muss entschieden werden, welche davon zur Anwendung kommen sollen. 4.2.1. Delegation von Admin Rechten an die Applikations-Abteilung [ug] Die Administration bezüglich einer Applikation kann an die für die Applikation zuständige Abteilung delegiert werden. Durch die Zonen-Isolation kann der root-Administrator nur Ressourcen beeinflussen, die der Zone zugeordnet sind. Dies gilt auch für andere definierte privilegierte User in der Zone (siehe Process Privileges, ppriv). • Ist eine Zone einer shared IP-Instanz zugeordnet, kann das Netzwerk nur in der globalen Zone konfiguriert werden. • Wenn einer Zone eine exclusive IP-Instanz zugewiesen wurde, kann der Administrator dieser Zone die Netzwerkkonfiguration der Zone selbstständig vornehmen. • Filesysteme können von der globalen Zone festgelegt sein (zonecfg add fs) • Die Administration der Filesysteme kann dem Administrator der lokalen Zone übergeben werden (zonecfg add device). 4.2.2. Applikationen nur in lokalen Zonen [ug] Wenn lokale Zonen für Applikationen genutzt werden, empfiehlt es sich, die globale Zone nicht auch für Applikationen zu nutzen. • Nur dann ist es möglich, dass die Administration der Hardware des Rechners rein bei den Plattform-Administratoren der globalen Zone bleibt. • Plattform-Administratoren sind die Administratoren, die die globale Zone administrieren. Sie haben den Zugriff auf die Hardware (Gehäuse, Netzkabel, Festplatten) und führen die Solaris Installation in der globalen Zone durch. Das Patching des Kernels und der Reboot des Gesamtsystems obliegt ebenfalls dem Plattform-Administrator. • Es ist nicht notwendig, dem Applikations-Admin Zugang zu der globalen Zone zu geben. • Sofern der Applikations-Admin root-Zugang braucht, kann er das root-Passwort der lokalen Zone seiner Applikation erhalten. Er muss dann allerdings in Absprache mit dem Betrieb die Verantwortung für die Verfügbarkeit der Applikation übernehmen. • Anforderungen für Plattenplatz erfolgen über die Plattform-Administration, die nach Freigabe durch die Storage-Administration (sofern separat) die Ressourcen der entsprechenden lokalen Zone zuordnen kann. • Bei der Netzwerkkonfiguration ist nach shared oder exclusive IP-Instanz zu unterscheiden. Im Gegensatz zu der shared IP-Instanz kann der Administrator einer Zone mit exclusive IP-Instanz die Netzwerkadministration selbst übernehmen. In der globalen Zone werden nur noch systemnahe Applikationen installiert, die zum Management, der Überwachung oder zu Backup-/Restore-Zwecken notwendig sind. Zur Erhöhung der Verfügbarkeit kann auch Cluster-Software eingesetzt werden. Vorteile: • Die Zuständigkeiten für System, Storage und Applikation können klar getrennt werden. • Der root-User Zugriff auf dem Basis-System ist auf die System-Administration eingeschränkt. Die Stabilität ist dadurch besser.
Nachteile: • Einige Applikationen sind noch nicht explizit für die Nutzung in Zonen freigegeben. In der Regel funktionieren die Applikationen in den Zonen, jedoch sind sie nur noch nicht vom Hersteller der Applikation zertifiziert worden.
46 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009
4.2.3. Eine Applikation pro Zone [ug] Ein weiteres Paradigma ist, immer nur eine Applikation pro Zone zu installieren. Der Overhead einer Zone ist sehr gering; im Prinzip werden nur die Applikationsprozesse vom Rest des Systems separiert, indem sie mit der ID der Zone markiert werden. Das wird durch die Zonen- Technologie realisiert. Die Gewinne durch diese Entscheidung sind sehr hoch: • Der Administrator der Applikation kann das Passwort für root in der lokalen Zone erhalten, ohne dass er den Betrieb des gesamten Rechners bei einem Fehler gefährden kann. • Gerade bei Konsolidierung von vielen Applikationen wird die Anzahl der Benutzer mit root- Rechten reduziert. • Wenn man die Applikation automatisch installieren möchte, ist dies viel einfacher, weil man ja sicher weiß, dass keine andere Applikation da ist und das System verändert hat. • Abhängigkeiten/Störungen zwischen Applikationen im Filesystem und/oder Konfigurations- Dateien entfallen vollständig, wodurch der Betrieb sicherer wird. 4.2.4. Container im Cluster [tf/du] Container können im Cluster als virtuelle Knoten oder als Ressourcen betrachtet und konfigu- riert werden. Mit Hilfe von Containern als virtuellen Knoten können seit Sun Cluster 3.2 1/09 virtuelle Cluster, sog. Solaris Container Cluster implementiert werden. Nähere Informationen bietet das nächste Kapitel. Im Cluster ist der Betrieb als Blackbox Container oder in ausgeformten Ressource Topologien möglich. In einem Blackbox Container werden die betriebenen Applikationen nur im Container konfiguriert. Der Cluster kennt sie nicht, sie werden innerhalb des Containers nur von Solaris kontrolliert. Dies führt zu besonders einfachen Cluster Konfigurationen. Bei einer ausgeformten Ressource Topologie wird jede Applikation unter Cluster Kontrolle betrieben. Jede Applikation wird damit als eine Ressource in den Cluster integriert und von ihm in der richtigen Reihenfolge gestartet und überwacht. Für ausgeformte Ressource Topologien in Containern stehen ab Sun Cluster 3.2 der HA Container Agent oder Container als „virtuelle Knoten“ zur Verfügung. Bei einem Container als virtuellem Knoten schwenkt man Applikationen gebündelt in Ressourcegruppen zwischen Containern. Mehrere Ressourcegruppen können in einem Container laufen und unabhängig von einander schwenken. Beide Konzepte, HA Container und Container als virtueller Knoten, haben jeweils ihre eigenen Stärken. Hilfreiche Kriterien zur Wahl des richtigen Konzepts für den jeweiligen Anwendungsfall sind im „Sun Cluster Concepts Guide for Solaris OS“ zu finden: http://docs.sun.com/app/docs/doc/819-2969/gcbkf?a=view Man kann in der Cluster Topologie Applikationen im Container unter Cluster Kontrolle bringen. Betreibt man Container als virtuelle Knoten, werden für die Applikationskontrolle Standard oder selbst geschriebene Agenten benutzt. Betreibt man Container unter Kontrolle des HA Container Agenten, können ausgewählte Standard Agenten oder die Shellscript- oder SMF-Komponente des Sun Cluster Container Agenten verwendet werden. Bei Verwendung des HA Container Agenten sind Mischformen zwischen Blackbox und ausgeformter Ressource Topologie jederzeit zulässig. Bei Containern als virtueller Knoten ist eine ausgeformte Ressourcetopologie erforderlich. Cluster können in aktiv-passiv Konfiguration oder in aktiv-aktiv Konfiguration betrieben werden. Aktiv–passiv bedeutet, ein Knoten bedient die konfigurierten Container oder Applikationen und der zweite Knoten wartet auf den Ausfall des ersten. Aktiv–aktiv bedeutet, dass jeder Knoten Container oder Applikationen bedient. Reicht die Leistung jedes Knoten nicht für alle Container oder Applikationen aus, so ist bei Ausfall eines Knotens eine geringere Performance zu akzeptieren. Ist die Anforderung, Hochverfügbarkeit in einem Rechenzentrum oder Hochverfügbarkeit zwischen zwei Rechenzentren zu erreichen, so genügt Sun Cluster um Container oder Applikationen geplant und im Notfall zwischen den Rechnern zu verschieben. Die maximale Entfernung zwischen zwei Cluster Knoten war bei Sun Cluster früher auf 400 km begrenzt und setzte den Einsatz zertifizierter DWDMs (Dense Wave Division Multiplexer) voraus. Heute gilt der Nachweis einer maximalen Latenz von 15 ms (one-way) und eine maximale Bit Error Rate (BER) von 10-10 als ausreichend. Sind diese Anforderungen eingehalten, bedeutet das leider noch nicht, dass auch die Performance- Anforderungen der Anwendung eingehalten werden. D.h. genügt die Latenz der involvierten Spiegelungs- bzw. Replikationstechnik nicht den Performance Anforderungen, so ist hier Sun Cluster Geographic Edition einsetzbar. Sun Cluster Geographic Edition setzt laufende Cluster in mehreren Rechenzentren voraus. Der verwandte Storage wird über geeignete Techniken vom Rechenzentrum A in das Rechenzentrum B
47 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009 repliziert. Zur Zeit sind Sun StorEdge Availability Suite (AVS) als hostbasierte Replikation, Hitachi Truecopy und EMC SRDF als Controller-basierte Replikation und mit Sun Cluster 3.2 1/09 Oracle DataGuard als anwendungsbasierte Replikation integriert. Sun Cluster Geographic Edition ermöglicht es, die Container / Services vom Rechenzentrum A in das Rechenzentrum B zu verschieben. Fällt ein Rechenzentrum aus, so schlägt Sun Cluster Geographic Edition einen Rechenzentrum-Schwenk vor. Nach Bestätigung durch einen Administrator wird dieser dann auch durchgeführt. Mit den hier beschriebenen Software Produkten lassen sich die Anforderungen von Visualisierung und Flexibilisierung von Containern bis hin zu Desaster Recovery Konzepten voll abdecken. Admin. Client Primary Site Backup Site
Optional Router Heartbeat DWDM Network
SE SE SE Network Network DWDM DWDM Network FC FC FC Switch-8 Switch-8 Unlimited Distance Switch-8 Separation
9990 9990 9990 Zeichnung 25: [tf/du] Typische Konfiguration: Sun Cluster Geographic Edition
Sun Cluster Geographic Active Edition Passive Sun Sun Cluster Cluster Container-protection-group Container-rg Container-rg Container Container Agent Applic. Agent Applic.
Container Container Agent Agent
HAStorage Logical HAStorage Logical Plus Host Plus Host
Zeichnung 26: [tf/du] Ressourcegruppen und Protectiongroup Topologie Die hier dargestellte Hardware Architektur besteht aus einem zwei Knoten Cluster aus SF6900 Servern im primären Rechenzentrum und einem Ein-Knoten Cluster in dem für Desaster Recovery vorgesehenen Ausweichrechenzentrum. Die verwendeten Storage Systeme sind Sun StorageTek 9990 Systeme und die Datenreplikation erfolgt mittels Truecopy. Die Steuerung erfolgt über Sun Cluster Geographic Edition. Sollte keine Desaster Recovery gewünscht werden, so kann man jedes Rechenzentrum auch für sich betreiben. In der hier dargestellten Ressourcegruppen-Topologie verwaltet der aktive Cluster einen Container. Der passive Cluster wird für Disaster Recovery Zwecke benutzt. Die Cluster bilden eine Partnerschaft und verwalten die Ressourcegruppe in einer sogenannte Protectiongroup. 48 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009 4.2.5. Solaris Container Cluster [hs] Eine der wesentlichen Eigenschaften von Containern ist die Möglichkeit, die administrativen Aufgaben an den Verwalter bzw. Benutzer eines oder mehrerer Container zu delegieren. Wird die Hochverfügbarkeit eines Containers durch den Einsatz des HA Solaris Container Agenten sichergestellt, so ist dies für den Administration des betroffenen Containers nicht sichtbar – was in der Regel auch so gewünscht ist. Soll jedoch auch die Container bezogene Verwaltung von Cluster Ressourcen ebenfalls an den Container Administrator delegiert werden, kann ein Container Cluster eingesetzt werden. Ein Container Cluster besteht aus mehreren Containern, je einer pro Solaris Instanz, die zu einem virtuellen Cluster zusammengefasst werden. Die für den Betrieb der Container und des Container Clusters notwendigen Ressourcen werden durch den Administrator der globalen Zone zur Verfügung gestellt. Die Verwendung dieser Ressourcen, u.a. das Anlegen von Ressourcegruppen und ihrer Ressourcen, obliegt aber dem Administrator des Container Clusters. Die Verwaltung der Ressourcen innerhalb eines Container Clusters verhält sich so wie die Verwaltung in der globalen Zone. Ausnahmen sind Quorum und Cluster Interconnect, die ausschließlich in der globalen Zone administriert werden. Damit kann sich der Verwalter des Container Clusters auf die hochverfügbaren Dienste und ihre Integration ins Cluster konzentrieren. Die wesentlichen Aufgaben bei der Verwaltung von Container Clustern bestehen in der Identifikation und Zuweisung der notwendigen Ressourcen von der globalen Zone in die lokalen Zonen, die einen Container Cluster bilden. Dazu gehören: • IP Adressen; (Container Cluster können nur mit ip-type shared arbeiten) • CPUs • Hauptspeicher • Dateisysteme, bzw. raw devices Eine nachvollziehbare, systematische Namensgebung für Ressourcen ist eine große Hilfe für eine fehlerfreie Administration komplexer Container Cluster Umgebungen.
49 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009 4.3. Konfiguration und Administration 4.3.1. Manuelle Konfiguration von Zonen mit zonecfg [ug] Zur Konfiguration einer Zone gibt es das Kommando zonecfg, siehe Beispiel im Kochbuch. Die Konfiguration beschreibt lediglich das Verzeichnis (zonecfg: zonepath) in dem die Dateien für die Zone abgelegt werden sollen und wie System-Verzeichnisse von der globalen Zone übernommen werden sollen (Kopieren/Loopback-Mount). Als Option kommen noch Netzwerk- Adressen, Filesysteme, Devices... hinzu. Jede einmal konfigurierte Zone lässt sich auch als Template für weitere Zonen verwenden. Durch dieses Klonen von Konfigurationen kann die Erstellung von Zonen gleichartiger Konfigurationen erheblich vereinfacht werden. Von einer Konfiguration von Zonen durch das Editieren der XML-Dateien unter /etc/zones wird abgeraten, da dieses Verfahren sehr fehleranfällig ist und daher nicht unterstützt wird. 4.3.2. Manuelle Installation von Zonen mit zoneadm [ug] Nachdem eine Zone konfiguriert ist, besteht der nächste Schritt in der Installation mit zoneadm -z
50 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009 In der Regel werden einige Richtlinien lokal festgelegt, zum Beispiel: • Welche Filesysteme von der globalen Zone geerbt werden sollen (inherit-pkg-dir). • Filesysteme mit Software, die jede Zone nutzen können soll. • shared Verzeichnisse von der globalen Zone. • Ob die Zone bei Reboot des Rechners automatisch gestartet werden soll. • Der Ressource Pool und andere Ressource Einstellungen für die Zone.
Diese Standard-Einstellungen lassen sich als Templates ablegen und wieder benutzen. Man muss jedoch immer noch die IP-Adresse und das Zone-Directory mit zonecfg konfigurieren, sowie beim ersten Booten der Zone den Rechnernamen (/etc/nodename), die Zeitzone und den Name- Service konfigurieren. Für eine automatisierte Erzeugung von Zonen kann das N1 Service Provisioning System (N1SPS) benutzt werden. 4.3.7. Automatische Konfiguration von Zonen per Script [dd] Zonen können automatisch per Script erzeugt und konfiguriert werden. Die Erzeugung von Zonen folgt vorher festgelegten Policies. Dazu sind die folgenden Schritte im Script auszuführen: • Das zonecfg-Kommando wird von einem Script aufgerufen, das die IP-Adresse, Zone- Directory, Filesysteme, Ressource-Pool nach Policies setzt (Kochbuch), zum Beispiel nach: • IP-Adresse ist die Adresse des IP-Namens von z-
51 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009 4.4. Lifecycle Management 4.4.1. Patchen eines Systems mit lokalen Zonen [dd/ug] Bei einem Solaris System mit nativen Zonen hat man prinzipiell in den lokalen Zonen den gleichen Patch-Stand wie in der globalen Zone. Dies ist unabhängig davon, ob die lokale Zone eine sparse-root Zone oder eine whole-root Zone ist. Daher werden Patches auf einem solchen System in der globalen Zone und damit automatisch in alle lokalen Zonen installiert. • Entgegen den Verfahren von vor Solaris 10 10/08, werden Zonen zum Patchen nicht mehr gebootet. • Der Patchvorgang erfordert, dass die zu patchenden Zonen im Zustand „installed“. • Die konfigurierten Filesysteme (per zonecfg und /etc/vfstab der lokalen Zone) müssen durch die globale Zone gemountet werden können. • Zum Patchen werden die konfigurierten Filesysteme einer Zone gemountet, der Patch eingespielt und die Filesysteme wieder unmountet. Dieser Vorgang läuft für jeden Patch separat ab. Beim Einspielen eines Patch-Clusters wird dieses Verfahren nacheinander für alle Patches und Zonen durchgeführt. Daher kann das Patchen bei vielen einzuspielenden Patches (z.B. Patchcluster) und vielen vorhandenen Zonen mehrere Stunden oder Tage in Anspruch nehmen. Es gibt verschiedene Überlegungen, wie der Zeitaufwand zum Patchen von vielen Zonen und damit die Ausfallzeit von Zonen reduziert werden kann: 1. Die Patch-Utilities sind so optimiert worden, dass ein zeitparalleles Patchen von vielen lokalen Zonen möglich ist. Diese Utilities sind im Juni 2009 durch die Patches 119254-66 (SPARC) und 119255-66 (x86) bereitgestellt worden. (siehe auch http://blogs.sun.com/patch/entry/zones_parallel_patching_feature_now) Diese Funktionalität ist in Solaris 10 10/09 integriert worden.
Der Zeitgewinn durch die Benutzung dieser neuen Utilities ist enorm. Jeff Victor hat in seinem Blog dazu einige Untersuchungen unternommen. http://blogs.sun.com/JeffV/entry/patching_zones_goes_zoomUtilities Zur Benutzung des Mechanismus ist unbedingt das Readme.txt des Patches zu beachten, denn die Anzahl der parallel zu patchenden Zonen muss zunächst konfiguriert werden. (siehe /etc/patch/pdo.conf) Daraus geht hervor, dass die Anzahl der parallel patchbaren Zonen von der Anzahl der im System verfügbaren CPU abhängt. (max. Anzahl parallel patchbarer Zonen = Anzahl CPU * 1,5) Ältere Tools zum zeitparallelen Patchen von Zonen sollten nicht mehr benutzt werden. 2. Um das aktuell laufende System nicht durch Patch-Verfahren zu beeinflussen, ist auch ein separater Patch-Server anwendbar. Die aktuellen Zonen werden hierbei dupliziert und die Kopien der Zonen werden per zoneadm detach / zoneadm attach auf einen Patch-Server bewegt. Auf diesem Server werden danach die Patches eingespielt. Danach werden die Zonen auf einen Server bewegt, der in der globalen Zone bereits die aktuellen Patches enthält. Bemerkungen: • Generell wird angestrebt, dass lokale Zonen die gleichen Patchstände des Betriebssystems wie die globale Zone enthalten. Für Systembibliotheken ist dieses zwingend notwendig. • Lediglich für die benutzte Anwendungssoftware kann in Erwägung gezogen werden, in Zonen unterschiedliche Patch-Stände zu benutzen. • Sollen Patches nur in einer bestimmten Zone installiert werden, z.B. bei Whole-root Zonen zum Testen von Patches, können Patches mit patchadd -G in eine Zone installiert werden. Die folgende URL enthält weiterführende Informationen und Empfehlungen rund um das Thema Patching: http://www.sun.com/bigadmin/hubs/documentation/howto/patch.jsp Weiterführende Informationen zum Thema Patching sind hier (http://blogs.sun.com/patch/) und hier (http://www.sun.com/bigadmin/features/articles/patch_management.jsp) erhältlich.
52 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009
4.4.2. Patchen mit Live Upgrade [ug/dd] Ab Solaris 10 8/07 kann Live Upgrade zum Patchen auch auf Zonen angewendet werden, wenn der zonepath auf ZFS liegt. (Siehe auch Kochbuch: 5.3.11 Die Benutzung von Live Upgrade zum Patchen eines Systems mit lokalen Zonen )). Dazu wird mit lucreate(1M) eine Kopie des aktiven Solaris Boot-Environments mit all seinen installierten lokalen Zonen erzeugt, um danach in diese Kopie mit luupgrade -t die Patches einzuspielen. Ein luactivate(1M) aktiviert das Boot-Environment, das nach dem nächsten Reboot aktiv ist. Durch die Nutzung von Live Upgrade kann die Ausfallzeit von Services während des Patchens drastisch reduziert werden, da das Patchen parallel zum laufenden aktiven System abläuft. Lediglich zur Aktivierung des aktualisierten Boot- Environments durch ein Reboot ist eine Ausfallzeit notwendig. Es ist zu beachten, das Live Upgrade eine I/O-Last erzeugt, die von dem Server- und Plattensystem während der Laufzeit von lucreate und luupgrade zusätzlich bereitgestellt werden muss. 4.4.3. Patchen mit Upgrade Server [ug] Bei dieser Variante wird eine Zone von dem Produktions-Rechner auf einen sogenannten Upgrade-Server transportiert (zoneadm detach und zoneadm attach), der den gleichen Stand wie der Produktions-Server hat. Auf diesem Upgrade-Server wird dann ein Upgrade oder die Installation von Patches durchgeführt. Dann hat die Zone den neuen Patch-Stand. Varianten: • Der Upgrade-Server kann dann als neuer Produktions-Rechner dienen. • Man kann auch einen Cluster (Sun Cluster) so upgraden, indem man in die Zonen auf einem Upgrade-Server die Patches einspielt, dann in den einen Clusterknoten die Patches einspielt und dann die Zonen dorthin bewegt. Dann kann der erste Clusterknoten auf den neuen Stand gebracht werden. • Sollen die Zonen weiterlaufen, wird nur eine Kopie der Zone bewegt und die Applikation während des Upgrade nicht gestartet. Damit ist die Zeit des Upgrades, die von der Zahl der Patches und der Zahl der Zonen abhängt, nicht mehr so wichtig, weil die Produktion in der Zeitdauer des Upgrade weiterläuft. 4.4.4. Patchen mit zoneadm attach -u [ug/dd] Mit Solaris 10 10/08 ist das Kommando zoneadm attach -u verfügbar, mit dem eine Zone beim zoneadm attach auf den Stand des neuen Zielsystems gebracht werden kann. Dieses ist jedoch nicht als neue Möglichkeit für das Upgrade von Zonen anzusehen. Voraussetzung für zoneadm attach -u ist, dass die Patch-Historie relativ identisch ist und das Zielsystem kein Paket mit einem älterem Stand hat, weil der downgrade eines Paketes nicht möglich ist. Das gilt auch für einen alten Patch-Stand. Ein zoneadm attach -u ist daher nicht zwischen beliebigen Systemen anwendbar. Die Systeme sollten dafür entsprechend administriert werden, wie zum Beispiel im Cluster. Für so installierte Patches gibt es innerhalb der Zone keine backout- Möglichkeit. zoneadm attach -u betrachtet beim Patchen von Paketen nur solche, für die die Option SUNW_PKG_ALLZONES=true gesetzt ist. Das betrifft alle OS-Level Pakete, aber üblicherweise nicht die von Applikationen. Wenn zoneadm attach -u zum Patchen von Zonen verwendet werden soll, muss beachtet werden, dass also unter Umständen Applikationspatches gar nicht oder nicht komplett betrachtet werden. Diese Patches sollten dann zur Wahrung der Konsistenz der Patch- und Paket-Datenbank nachinstalliert werden. Mit diesen Kenntnissen kann zoneadm attach -u jedoch nach ausreichenden Tests und dem Wissen um die Funktionsweise trotzdem wertvolle Einsatzzwecke beim Patchen erfüllen. Das ist dann der Fall, wenn ein zeitkritisches Patchen notwendig ist, da diese Methode schneller ist, als das parallele Patchen von Zonen mit patchadd. Dieses Verfahren zum Patchen sollte nur mit der entsprechenden Umsicht benutzt werden. 4.4.5. Bewegen von Zonen zwischen Architekturen (sun4u / sun4v) [ug] Mit zoneadm attach -u ist es möglich, Zonen zwischen den beiden aktuellen SPARC Hardware-Architekturen hin und her zu bewegen. Voraussetzung dafür ist ebenso, dass die gleichen Pakete installiert sind und die Patch-Historie identisch ist.
53 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009
4.4.6. Neuinstallation und Service Provisionieren statt Patchen [dd] Zum Einspielen von System-Patches, werden die Zonen in den Single-User Mode gebracht und so die Services in den Zonen beendet. Dieser Service-Ausfall kann je nach Art der Installation der Patches, der Anzahl der Zonen und der Anzahl der zu installierenden Patches unterschiedlich lang sein. Um diesen Zeitraum zu verkürzen und eine Vorhersagbarkeit der Service-Ausfallzeit zu erreichen, kann der Weg der Neuinstallation anstatt individuellem Patchen gewählt werden. Zonen können in fast beliebiger Zahl schnell erzeugt werden. Diese Zonen-Installationen sind erheblich schneller als die Neuinstallation eines Rechner oder das individuelle Patchen von Zonen. Daher sollte vor Patch- oder Upgrade-Planungen generell erwogen werden, Neuinstallationen der Zonen anstelle von Patch oder Upgrade vorzunehmen. Neu erzeugte Zonen haben schließlich nach der Erzeugung automatisch den aktuellen Software- oder Patchstand der globalen Zone. Danach werden die Anwendungsdaten und ggf. die Anwendung von der existierenden Zone in die neue Zone bewegt. Für diesen Zeitraum ist ein Service-Ausfall einzukalkulieren. Voraussetzung für dieses Verfahren ist, dass die Applikation, die Konfiguration und die Daten zwischen Zonen bewegt werden können. Folgende Dinge sind hierbei zu beachten: • Binärprogramme werden mit der Standardprozedur zur Zonenerzeugung in Zonen installiert. • Konfigurationen und Daten der Services werden in separaten Verzeichnissen oder Filesystemen der Zone gespeichert. • Sonstige Modifikationen an den Zonen werden protokolliert oder sind automatisch ermittelbar und extrahierbar (z.B. mit bart(1m)) • Für den „Umzug“ einer Zone, wird der Service „umgezogen“. Das passiert durch das Kopieren der Konfiguration und der Daten des Services (ggf. durch Verschieben des Filesystems) sowie der Anpassung der erzeugten Zone für die Anforderung des Services. Das kann durch das Extrahieren, Transport und Auspacken der Modifikation von der Originalzone zur neuen Zone erfolgen. 4.4.7. Backup und Recovery von Zonen [dd] Zonen können mit Backuptools aus der globalen Zone gesichert werden. Die Sicherung kann die Anwendungsdaten der Zone mit enthalten oder diese separat sichern. Für die Sicherung von Zonen sind die folgenden Dinge notwendig: • Sicherung der Zonekonfiguration mit zonecfg -z
54 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009 4.4.8. Backup von Zonen mit ZFS [ug] Mit Solaris 10 10/08 sind Zonen auf ZFS offiziell supportet. Damit kann der Backup von Zonen erheblich vereinfacht werden. Zonen werden auf ZFS eingerichtet und der Backup einer Zone kann mittels Snapshot des ZFS Filesystems realisiert werden. Dazu fährt man die zu sichernde Zone herunter, erzeugt einen Snapshot des Filesystems (mit zfs snapshot
55 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009
4.5.2. Konsolidierung von Log-Informationen von Zonen [dd] Der Einsatz von Zonen als Laufzeitumgebung für Dienste führt zu einer Erhöhung der Anzahl der Betriebsystemumgebungen, die zu einer Architektur gehören. Aus Gründen der Kapselung oder Modularisierung von Anwendungen ist dies zwar beabsichtigt, kann aber zu einem anderen Problem führen. Da jede Betriebssystemumgebung und die Anwendungen ihre eigenen log-Dateien führen, liegen diese nun ebenfalls in größerer Anzahl vor. Dadurch ist eine gesamtheitliche Auswertung von log- Dateien für die gesamte Architektur nur mit erhöhtem Aufwand möglich. Log-Informationen können per NFS, per Datei-Synchronisation oder mit anwendungsspezifischen Mitteln konsolidiert werden. 1. Zur Zusammenfassung von log-Informationen per NFS kann wie folgt vorgegangen werden: 1. Die log-Dateien werden durch die Anwendungen in den lokalen Zonen direkt in das lokale Filesystem geschrieben (ggf. Rotation von log-Dateien beachten oder organisieren). 2. Die relevanten log-Dateien aller lokalen Zonen eines Systems werden in der globalen Zone zentral gesammelt. Die Sammlung kann auf ein NFS-Verzeichnis erfolgen, das nur in der globalen Zone gemountet ist. Der transparente Durchgriff auf die Daten einer Zone ist durch das Zonenkonzept möglich (z.B. Zugriff auf /
4.5.3. Überwachung der Zonen-Auslastung [ug] Mit dem Kommando prstat (seit Solaris 8) sieht man die Prozesse mit der höchsten Auslastung ähnlich dem von auch anderen Plattformen bekannten Kommando top. Mit Solaris 10 hat das Kommando prstat eine Option -Z erhalten, mit der man summarisch die Auslastung für jede Zone (auch die globale Zone) mit anzeigen kann. Dadurch ist der Status der Zonen leicht überwachbar. 4.5.4. Extended Accounting mit Zonen [ug] Mit Solaris 9 wurde das Extended Accounting eingeführt. Im Gegensatz zu dem traditionellen Unix Accounting - das es nach wie vor gibt - kann man bei Extended Accounting die Datenfelder, die protokolliert werden sollen, aus einer Obermenge auswählen. Mit Solaris 10 steht als weiteres optionales Datenfeld auch der Name der Zone zur Verfügung. Daher kann man in der globalen Zone das Extended Accounting so konfigurieren, dass mit jedem Accounting Datensatz auch der Zonen-Name mitgeschrieben wird. Die Daten (z.B. verbrauchte CPU- Zeit) lassen sich daher nach Zonen getrennt summieren und einer Kapazitätsplanung oder Abrechnung zuführen. 4.5.5. Auditing der Operationen in der Zone [dd] Audit kann zur Überwachung von Systemaktivitäten eingesetzt werden. Das System-Audit erfolgt in der globalen Zone. Audit kann auch zur Überwachung der Aktivitäten einer lokalen Zone konfiguriert werden oder durch den Administrator einer Zone zur Überwachung der Nutzerprozesse einer Zone. Audit in lokalen Zonen kann zwar die Aktivitäten vom Kernel nicht überwachen, aber User-Aktivitäten innerhalb der Zonen.
56 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009
4.5.6. DTrace von Prozessen in einer Zone [dd/ug] DTrace kann zur Untersuchung von Prozessen in Zonen verwendet werden. Dazu können DTrace Scripte um die Variable zonename erweitert werden, um z.B. nur Systemcalls einer Zone zu tracen.
global# dtrace -n 'syscall:::/zonename==”sparse”/ {@[probefunc]=count()}' oder den I/O von Zonen zu messen. global# dtrace -n io:::start'{@[zonename] = count()}'
Ab Solaris 10 11/06 ist DTrace auch auf Prozesse innerhalb der eigenen lokalen Zone anwendbar. Dazu müssen die Privilegien dtrace_proc und dtrace_user einer Zone zugewiesen werden (zonecfg:set limitpriv=default,dtrace_proc,dtrace_user). Ausgeschlossen bleibt das Tracen des Kernels und der Prozesse der globalen Zone. DTrace innerhalb einer Zone ist vor allem für solche Anwendungsfälle von Interesse, in denen eine Zone zur Softwareentwicklung benutzt wird oder die Administration einer Zone delegiert wurde. In diesem Fall kann der Zonen-Administrator selbstständige Analysen vornehmen.
57 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009 4.6. Ressource Management 4.6.1. Arten von Ressource Management [dd] Insgesamt werden 3 Arten des Ressource Managements unterschieden: • Faire Ressourcen: Hier werden alle Ressourcen fair bzw. nach Regeln zwischen allen Anforderern verteilt. Beispiel: Fair Share Scheduler für CPU-Ressourcen • Gekappte Ressourcen: Die Ressourcen sind von allen Anforderern sichtbar. Es wird ein oberes Limit einer Ressource festgelegt, der Kappungs-Wert. Nicht genutzte Ressourcen können von anderen mit genutzt werden. Beispiel: CPU-Kappung • Exklusive Ressourcen: Die Ressourcen sind exklusiv einem Anforderer zugewiesen und sind nur von ihm nutzbar. Nicht genutzte Ressourceanteile stehen anderen nicht zur Verfügung. Beispiel: Ressource Pools mit Prozessor Sets 4.6.2. CPU Ressourcen [ug] CPU Ressourcen lassen sich in Solaris 10 auf verschiedenen Ebenen limitieren: • Kappung von CPU-Zeit für eine Zone • Ressource Pools mit Prozessorset (nur globale Zone) • Fair-Share Scheduler zwischen Zonen in einem Ressource Pool (nur globale Zone) • Fair Share Scheduler zwischen Projekten in einer Zone
4.6.2.1. Kappung von CPU-Zeit für eine Zone [dd] Hierzu wird in der Zonenkonfiguration ein CPU-Kappungswert für eine Zone zugewiesen. Hierbei können Anteile einer CPU angegeben werden, z.B. 0,5 CPU oder 1,7 CPU. Die benutzbare CPU-Zeit einer Zone wird an diesem Wert gekappt. So ist eine fein granulierte CPU-Zuteilung auf verschiedene Zonen möglich, auch wenn weniger als ganze CPU einer Zone zugeteilt werden soll. Zusätzlich darf die Zone so auch nicht mehr CPU-Ressourcen verbrauchen, obwohl mehr CPU-Zeit zur Verfügung stehen würde (z.B. in Zeiten der Unterbelastung des Gesamtsystems). CPU-Caps sind dort anzuwenden, wo fein granulierte CPU-Zuteilungen notwendig sind und ein oberes Limit eingehalten werden muss. Die Einstellung mit CPU-Caps ist auf 1/100 CPUs genau. (Kochbuch: 5.5.2 Limitieren des CPU Verbrauchs einer Zone (CPU-Capping) ) 4.6.2.2. Allgemeine Ressource Pools [ug] Hierzu werden in der globalen Zone sogenannte Ressource Pools definiert, denen jeweils ein Prozessor-Sets zugeordnet werden kann (siehe Kommandos poolcfg und pooladm). • Ein Prozessor-Set enthält eine Ober- und Unter-Grenze für die Zahl der Prozessoren. Dies kann für eine dynamische Zuteilung von Prozessoren mit dem poold genutzt werden. • Diese Definitionen sind statisch (überstehen einen Reboot) eine dynamische Veränderung ist jedoch auch möglich. • Eine dynamische Änderung ist mit dem Kommando prctl möglich. • Eine Zone (oder auch ein Projekt) kann einem solchen Ressource Pool zugeordnet werden. Das geht mit zonecfg: set pool=
58 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009
4.6.2.3. Fair Share Scheduler (FSS) [ug] Wenn mehrere Zonen in einem Ressource Pool laufen, kann man einstellen, wie die CPU-Zeit zwischen diesen Zonen verteilt wird. Diese Konfiguration ist aktiv, wenn die Auslastung des Prozessor-Sets gegen 100% geht (Volllast). Dann werden die Prioritäten der Prozesse durch den FSS nach den eingestellten Shares ausgerichtet. Solange jedoch die Ausnutzung der CPU-Leistung unter 100% ist, greift der FSS nicht ein. • Zur Konfiguration muss in dem Ressource Pool der Fair Share Scheduler aktiviert werden. • In der Zone muss mit zonecfg: add rctl der Wert von zone.cpu-shares gesetzt werden. • Ab Solaris 10 8/07 lässt sich die Anzahl der Shares einfacher mit zonecfg: set cpu-shares=
59 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009
4.6.3. Limitierung der Memory Ressourcen [ug] Der Speicherverbrauch von Zonen wird fast exakt ermittelt (seit Solaris 10 8/07). Das erfolgt folgendermaßen: Zunächst wird die Menge aller Speichersegmente aller Prozesse der Zone ermittelt. Shared Segmente kommen in der Menge nur einmal vor. Dann wird der Speicherverbrauch der Segmente aufaddiert. Diese Berechnung erfasst fast korrekt den Speicherbedarf der Zone. Der Speicherverbrauch der Zone lässt sich mit prstat -Z anzeigen, wobei SWAP den verbrauchten virtuellen Speicher bezeichnet und RSS den verbrauchten physikalischen Hauptspeicher. Diese Berechnung funktioniert auch für Projekte (zum Beispiel in Zonen) mit prstat -J . Sobald ein Limit konfiguriert ist, lässt sich der Status der Zonen mit rcapstat anzeigen. Die Ungenauigkeit besteht darin, dass zum Beispiel das Segment der /usr/lib/libc.so Bibliothek von der globalen Zone und von allen Zonen, die den /usr/lib Baum erben, benutzt wird. Es wird bei der Speicherberechnung jeder beteiligten Zone voll angerechnet, ist aber in der Realität nur einmal da. Die Zone braucht also diesen Platz, benutzt ihn aber shared mit anderen und dürfte daher nur einen Teil davon angerechnet bekommen. Das betrifft aber nur shared Bibliotheken und Programm-Code. Die wesentlichen Speicher-Anteile sind jedoch die Datenbereiche von laufenden Programmen und shared Segmenten (z.B. von Datenbanken), die nicht über eine Zone hinausgehen. (Kochbuch: 5.5.11 Anwendung von Memory Ressource Management für Zonen ) 4.6.3.1. Abschätzung des Speicherbedarfs für globale und lokale Zonen [ug] Die globale Zone entspricht den folgenden Randbedingungen eines Solaris Betriebssystems: • Solaris benötigt ca. 512 MB - 1 GB Hauptspeicher je nach aktivierten Diensten • Weiterhin wird 1/32 des realen Hauptspeichers für die free-Liste freigehalten (minfree- Einstellung), der Platz dient auch als Platten-Cache. • Wenn viel traditionelles I/O mit großen Dateien stattfindet (read() und write() anstelle von mmap()), benötigt man noch 12% (ca. 1/8) des Hauptspeichers für den entsprechenden Puffer (segmap Einstellung). Die globale Zone ohne Applikationen eines 32 GB Systems benötigt daher ca. 2 GB, bei traditionellem IO sind es 6 GB Speicher. Den Verbrauch einer lokalen Zone kann man mit prstat -Z verifizieren. Er liegt ohne Applikationen bei ca. 5 - 10 MB je nach eingeschalteten Diensten. 4.6.3.2. Limitierung des Virtuellen Speicher [ug] (Ab S10 8/07) Der gesamte virtuelle Speicher wird durch den Kernel verwaltet. Welche Menge davon alle Prozesse einer Zone verbrauchen dürfen, kann limitiert werden. Dazu wird in der Zonenkonfiguration mit zonecfg: add capped-memory der Wert swap auf eine bestimmte Menge gesetzt. Diese Einstellung kann vom Administrator der Zone nicht mehr verändert werden. Sobald in der Zone diese Menge Speicher erreicht ist, können Applikationen in der Zone keinen neuen Speicher mehr anfordern. Die Menge des virtuellen Speichers ist damit hart limitiert (capping). Das ist die Einstellung, mit der man die Größe einer Zone limitieren kann. Diese Konfiguration sollte vor der Limitierung des phys. Hauptspeichers angewendet werden. 4.6.3.3. Limitieren des physikalischen Speicherbedarfs einer Zone [ug] Der von allen Prozessen einer Zone verbrauchte physikalische Speicher kann limitiert werden, indem in der Zonenkonfiguration mit zonecfg: add capped-memory der Wert physical auf eine bestimmte Menge gesetzt wird. Diese Einstellung kann vom Administrator in der Zone nicht mehr verändert werden (Seit S10 8/07). Das Verhalten der Prozesse in der Zone bleibt zunächst gleich. Wenn eine virtuelle Speicherseite lange nicht benutzt wurde, wird sie auf den swap-Space (Disk) ausgelagert. Wird eine ausgelagerte Speicherseite benutzt, wird sie über den Paging-Mechanismus des Solaris eingelagert und benutzt eine physikalische Speicherseite. Sobald eine Zone mit physikalischer Speicherlimitierung bootet, wird der Ressource-Capping-Daemon (rcapd) in der globalen Zone automatisch konfiguriert und gestartet. Sofern der rcapd feststellt, dass eine Zone mehr als die konfigurierte Menge physikalischen Hauptspeichers benutzt, lagert er aktiv Hauptspeicherseiten aus, bis das Limit eingehalten wird, die Arbeit der Zone wird behindert und die Performance der Zone wird schlechter. Mit dieser Einstellung kann man die Auswirkung auf andere Zonen limitieren, wenn insgesamt eine Fehlkonfiguration vorliegt (z.B. Datenbank zu groß eingestellt) Zur Limitierung der Größe einer Zone sollte man die Einstellung des virtuellen Speichers verwenden.
60 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009 4.6.3.4. Limitieren von Locked Memory [ug] Realtime-Programme und Datenbanken können Speicherseiten im Hauptspeicher festschreiben. Die Programme brauchen dazu das Privileg (proc_lock_memory), dass für die Zone konfiguriert sein muss. Datenbanken benutzen teilweise das Memory-Locking für shared Segmente, um die Performance zu optimieren (ISM – intimate shared memory). Heute wird jedoch auch häufig schon DISM (Dynamic ISM, z.B. bei Oracle) benutzt, das nur den Speicher festschreibt, wenn es gerade möglich ist. Die Menge an locked-Memory in einer Zone lässt sich für eine Zone konfigurieren, indem mit zonecfg: add capped-memory der Wert locked auf eine bestimmte Menge gesetzt wird. Diese Einstellung kann vom Administrator in der Zone nicht mehr verändert werden. Locked Memory verbessert die Performance von Anwendungen. Es ist aber auch von Nachteil, weil es direkt von der Menge des verfügbaren Hauptspeichers abgezogen wird. Es steht nicht mehr für andere Prozesse zur Verfügung, selbst wenn der Prozess nicht aktiv ist, der den Speicher festgeschrieben hat. Ob ein Prozess locked Memory braucht, kann man aus der Dokumentation entnehmen, oder mit dem Kommando pmap -x
Damit kann sichergestellt werden, dass in der Zone die entsprechende Einstellungen nicht überschritten werden können. 4.6.6. Privilegien und Ressource Management [ug] In Solaris 10 werden privilegierte Systemaufrufe feingranularer geprüft. Berechtigungen zur Nutzung dieser Aufrufe sind konfigurierbar. Diese Technik ist aus Trusted Solaris übernommen worden. Zum Beispiel kann man die Berechtigung, ein Filesystem zu mounten, an einen User weitergeben. Das kann mit Role Based Access Control konfiguriert werden (RBAC). Eine andere Anwendung davon sind die Zonen, bei denen ein root-Prozess in der lokalen Zone nicht alle Privilegien eines root-Prozesses in der globalen Zone hat; im Prinzip fehlt die Berechtigung, die Prozesse außerhalb der Zone zu sehen und auf alle Hardware zuzugreifen. Mit Solaris 10 11/06 wurde es möglich, in der Zonenkonfiguration mit zonecfg: set limitpriv=... zusätzliche Rechte für die Zone freizuschalten. Diese Rechte sind u.a. DTrace, lock memory oder Netzwerk Raw Zugriff. Eine genaue Aufstellung der Privilegien in Zonen und ihre Zuordnung findet sich unter: http://docs.sun.com/app/docs/doc/817-1592/6mhahuou9?a=view
61 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009 4.7. Solaris Container Navigator [dd] Der nachfolgende Abschnitt navigiert durch die Betrachtungen, die im Vorfeld des Einsatzes von Solaris Containern notwendig sind. Diese umfassen sowohl die Prüfung der Kompatibilität von Anwendungen mit Solaris Containern, als auch die Auswahl von unterschiedlichen Konfigurationsmöglichkeiten und die Überlegungen zur Installation von Containern. Dieser Navigator beruht sowohl auf Best Practices, als auch auf Erfahrungen und erhebt keinen Anspruch auf Vollständigkeit. Hinweise und Ergänzungen sind jederzeit willkommen.
Planung eines Solaris Containers
A: Prüfung der Lauffähigkeit der Anwendung in einem Container
B: Festlegung der Konfiguration eines Containers
Ende: Planung eines Solaris Containers Zeichnung 27: [dd] Planung eines Solaris Containers
A: Prüfung der Lauffähigkeit der Anwendung in einem Container
A-1: Sind Erfahrungen bekannt n (Hersteller, Literatur, Internet, Referenzen,...) ? j
A-2: Ggf. Angaben des Herstellers zum kommerziellen A-3: Selbst-Qualifikation Softwaresupport in Solaris Containern auswerten. einer Anwendung in einem Container
A-4: n Ergebnis positiv ? j A-Stop: Anwendung in Solaris Container nicht nutzbar A-Ende: Prüfung der Lauffähigkeit der Anwendung in einem Container Zeichnung 28: [dd] Prüfung der Lauffähigkeit der Anwendung in einem Container
62 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009
A-3: Selbst-Qualifikation einer Anwendung in einem Container
A-3-1: Ggf. zusätzliche Details beachten in: „Qualification Best Practices for Application Support in Non-Global Zones“ http://developers.sun.com/solaris/articles/zone_app_qualif.html
A-3-2: j A-3-3: n Benutzung des Solaris Application Scanners Problem gefunden ? ?
n j A-3-5: Weitere Prüfung, da aufgetretenen Probleme durch besondere Konfigurationen des Containers behoben werden könnten.
A-3-6: Ist eine der Anforderungen j durch die Anwendung gegeben ? - Erzeugen und Entfernen von Geräten - Direkter Zugriff auf Kernelmodule - Laden und Entladen von Treibern
n
A-3-10: Weitere priviligierte j Operationen während der Laufzeit notwendig (suid root, o.ä.) ?
n A-3-11: n Erforderliche Privilegien per zonecfg:limitpriv konfigurierbar ? j
A-3-12: zonecfg:limitpriv ermitteln
A-3-7: Ergebnis der A-3-13: Ergebnis der Qualifikation negativ Qualifikation positiv (Anwendung nicht für (Anwendung ist für Solaris Container geeignet) Solaris Container geeignet)
A-3-4: Ergebnis der Qualifikation positiv (Anwendung ist für Solaris Container geeignet)
A-3: Selbst-Qualifikation einer Anwendung in einem Container
Zeichnung 29: [dd] Selbst-Qualifikation einer Anwendung in einem Container
63 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 4. Best Practices Stand: 30.11.2009
B:Festlegung der Konfiguration eines Containers
B-2: B-1: j j Solaris8 oder Plattform = SPARC Solaris9 Container ? ? n n
B-4: zonecfg:brand=native B-3: zonecfg:brand=solaris8|solaris9
B-5: Container-Konzept festlegen sparse-root oder whole-root
B-6: Filesystem-Layout festlegen
B-7: Weitere zonecfg:inherit-pkg-dir festlegen
B-8: Zugriff auf weitere Filesysteme der globalen Zone betrachten ggf. zonecfg:add fs mit Attributen festlegen
B-9: Direkter Zugriff auf Raw-Devices der globalen Zone betrachten ggf. zonecfg:set match festlegen
B-10: CPU- und Prozeß-Ressourcemanagement auswählen - Fair-Share Scheduler - Ressource Pool (Dynamischer oder Statischer Ressource Pool) - CPU-Capping - LWP-Begrenzung
B-11: Memory-Ressourcelimitierungen festlegen - Virtueller Speicher und Physikalischer Speicher - Shared Memory
B-12: IPC-Limitierungen festlegen - Message-Queue - Semaphore - Shared Memory
B-13: Ist eine der Anforderungen für das Netzwerk des Containers gegeben ? - Eigenes Netzwerk mit eigener konfigurierbarer j Routingtabelle - Sonstiger Raw-Zugriff auf das Netzwerkinterface - Eigene NDD-Parameter in dem Container setzbar - Netzwerkmonitoring (snoop) im Container - DHCP-Server oder DHCP-Client - IP-Filter in dem Container n
B-15: zonecfg:ip-type=shared B-14: zonecfg:ip-type=exclusive Netzwerkinterface der globalen Separates Netzwerkinterface Zone wird mit Container geteilt oder tagged-vlan Interface benötigt
B-Ende:Festlegung der Konfiguration eines Containers Zeichnung 30: [dd] Festlegung der Konfiguration eines Containers
64 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 5. Kochbücher
Das Kapitel Kochbücher stellt die Realisierung der konzeptionellen Best Practices an konkreten Beispielen dar. 5.1. Installation und Konfiguration 5.1.1. Konfigurationsdateien [dd] Datei: /etc/zones/index Listet alle konfigurierten Zonen eines Systems auf, inkl. Zonenstatus und Rootverzeichnis. # DO NOT EDIT: this file is automatically generated by zoneadm(1M) # and zonecfg(1M). Any manual changes will be lost. # global:installed:/ sparse:installed:/zones/sparse:ae343d81-3439-cd4d-ff52-f110feeff8d2 whole:configured:/zones/whole
Datei: /etc/zones/
Datei: /etc/zones/SUNWblank.xml legt die Standardvorgabe fest, wie blank-Zones (Kommando zoneadm create -b) erzeugt werden
Datei: /etc/zones/SUNWdefault.xml legt die Standardvorgabe fest, wie default Zonen (sparse-root) erzeugt werden (nicht verändern)
65 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.1.2. Besondere Kommandos für Zonen [dd/ug] Die Erzeugung und Nutzung von Zonen in Solaris 10 erfolgt durch die folgenden Kommandos:
Kommando Beschreibung zoneadm(1M) Administration von Zonen (Installation/Uninstallation, Boot/Reboot/Halt, List) zonecfg(1M) Konfiguration der Zone zlogin(1) Zonenlogin von der globalen Zone aus -C Verbindung mit der Console der Zone zonename(1) Ausgabe des Namens der aktuellen Zone Tabelle 6: [dd/ug] Kommandos für Zonen
Mit den folgenden Kommandos sind administrative Aktionen bezüglich Zonen möglich: Kommando Beschreibung dladm(1M) Administration von Data Links ifconfig(1M) zone
66 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 Mit den folgenden Kommandos lassen sich Informationen abhängig von den Zonen anzeigen: Kommando Beschreibung df(1M) -Z zeigt Mounts der Zonen an ifconfig(1M) zone
67 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.1.3. Rootplattenlayout [dd] Die nachfolgende Tabelle stellt beispielhaft ein Rootplattenlayout eines Systems mit einer lokalen Zone dar. Die Annahmen über die Größe der Filesysteme stellen Erfahrungswerte und Beispiele dar und können je nach Umfang der Softwareinstallation und lokalen Erfordernissen variieren. Pfad Größe des Bemerkung Filesystem s (Beispiel) / 8 GB /opt für die globale Zone kann hier mit enthalten sein swap 2 GB je nach Hauptspeichergröße, Anforderung und Erfahrung In das Swap-Device ist auch das Dump-Device konfiguriert. /var 6 GB je nach Anforderung und Erfahrung /var/crash 4 GB kann u.U. auch innerhalb von /var liegen Größe je nach Hauptspeichergröße und Erfahrung ABE (/) 8 GB Alternatives Boot-Environment (ABE) für / ABE (/var) 6 GB ABE für /var /var/crash und swap können zwischen beiden BE shared werden metadb 100MB SVM Metadatenbank, wenn der Solaris Volume Manager eingesetzt wird
/zones 2 GB root-Filesystem aller Zonen, wenn mehrere Zonen sich ein Filesystem teilen /zones/zone1 1 GB root-Filesystem exklusive für Zone1 /zones/root 1 GB root-Filesystem für mehrere Zonen, wenn mehrere Zonen sich ein Filesystem teilen und /var der lokalen Zone separat sein soll. Weitere Aufteilung z.B. in /zones/root/zone2, /zones/root/zone3,etc. /zones/var 1GB /var-Filesystem für mehrere Zonen, wenn mehrere Zonen sich ein Filesystem teilen sollen, aber /var separiert wird und getrennt überwacht wird. Weitere Aufteilung z.B. in /zones/ var/zone2, /zones/var/zone3, etc.
/anwendung1 1 GB enthält die Anwendung, die innerhalb der Zone laufen soll /anwendung1 wird z.B. in der Zone an /opt/anwendung1 gemountet, ist vom rootfs der Zone separiert und kann also unabhängig von der Zone verschoben werden. Tabelle 9: [dd] Rootplatten-Layout
Seit Solaris 10 10/08 kann ein Rootfilesystem und der zonepath auch auf ZFS angelegt werden. Dadurch können für die einzelnen Filesysteme ZFS-Filesysteme benutzt werden, und die Notwendigkeit der Bereitstellung einer großen Anzahlen von Slices und Volumes entfällt. Es ist jedoch zu beachten, dass alle Filesysteme, die sich in einem zpool befinden, nur gemeinsam auf ein anderes System bewegt/migriert/verschoben werden können. Ist also geplant, einzelne Zonen per zoneadm detach ... attach auf andere Systeme zu migrieren, sollte man diesen Zonen eigene zpools zuordnen oder die Filesysteme per zfs send ... receive verschieben.
68 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.1.4. Konfiguration einer Sparse-root Zone: Erforderliche Aktionen [dd] Aus Sparse-root Zonen können nur durch eine Neuinstallation Whole-root Zonen erzeugt werden. Also ist vor Beginn der Konfiguration auszuwählen, welche Art von Zone erzeugt werden soll. Entscheidungshilfen dazu sind bereits in diesem Dokument diskutiert worden. Die folgenden Angaben sind für die Konfiguration erforderlich: • Festlegung eines Zonennamens • Festlegung des root-Verzeichnisses der Zone • Zuordnung eines Interfaces • Zuordnung einer IP-Adresse • In diesem Beispiel wird /opt/sfw als inherit-pkg-dir festgelegt, da Software aus der Companion DVD sich hier installiert und so, einmal in der globalen Zone installiert, von allen lokalen Zonen genutzt werden kann. Diese Festlegung muss vor der Erzeugung der Zone getroffen werden und kann nachträglich nur durch eine Neuinstallation der Zone verändert werden. • Das Verzeichnis /opt wird kopiert und bleibt für die lokale Zone schreibbar. Nach der Konfiguration muss die Zone vor der ersten Benutzung installiert und initialisiert werden (siehe 5.1.6 Installation einer Zone ).
global# zonecfg -z zone1 zone1: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:zone1> create zonecfg:zone1> set zonepath=/zones/zone1 zonecfg:zone1> add inherit-pkg-dir zonecfg:zone1:inherit-pkg-dir> set dir=/opt/sfw zonecfg:zone1:inherit-pkg-dir> end zonecfg:zone1> add net zonecfg:zone1:net> set physical=bge0 zonecfg:zone1:net> set address=192.168.1.1/24 zonecfg:zone1:net> end zonecfg:zone1> verify zonecfg:zone1> commit zonecfg:zone1> info zonename: zone1 zonepath: /zones/zone1 brand: native autoboot: false bootargs: pool: limitprivs: scheduling-class: ip-type: shared inherit-pkg-dir: dir: /lib inherit-pkg-dir: dir: /platform inherit-pkg-dir: dir: /sbin inherit-pkg-dir: dir: /usr inherit-pkg-dir: dir: /opt/sfw net: address: 192.168.1.1/24 physical: bge0 zonecfg:zone1> exit global#
69 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.1.5. Konfiguration einer Whole-root Zone: Erforderliche Aktionen [dd] Whole-root Zonen enthalten keine inherit-pkg-dir und werden mit zonecfg create aus der Vorgabedatei /etc/zone/SUNWdefault.xml erzeugt. Im Anschluss daran werden mit remove inherit-pkg-dir alle inherit-pkg-dir entfernt. Von der Benutzung von zonecfg create -b wird abgeraten, da so eine Zone mit der Vorgabe aus /etc/zones/SUNWblank.xml erzeugt wird, die nicht unbedingt einer whole-root Zone entsprechen muss. Die folgenden Angaben sind für die Konfiguration einer whole-root Zone erforderlich: • Festlegung eines Zonennamens • Festlegung des root-Verzeichnisses der Zone • Zuordnung eines Interfaces • Zuordnung einer IP-Adresse Nach der Konfiguration muss die Zone vor der ersten Benutzung installiert und initialisiert werden (siehe 5.1.6 Installation einer Zone ).
global# zonecfg -z whole whole: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:whole> create zonecfg:whole> set zonepath=/zones/whole zonecfg:whole> remove inherit-pkg-dir dir=/sbin zonecfg:whole> remove inherit-pkg-dir dir=/usr zonecfg:whole> remove inherit-pkg-dir dir=/platform zonecfg:whole> remove inherit-pkg-dir dir=/lib zonecfg:whole> add net zonecfg:whole:net> set physical=bge0 zonecfg:whole:net> set address=192.168.1.1/24 zonecfg:whole:net> end zonecfg:whole> verify zonecfg:whole> commit zonecfg:whole> info zonename: whole zonepath: /zones/whole brand: native autoboot: false bootargs: pool: limitpriv: scheduling-class: ip-type: shared net: address: 192.168.1.1/24 physical: bge0 zonecfg:whole> exit global#
70 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.1.6. Installation einer Zone [dd] Vor der ersten Benutzung einer Zone, muss diese nach Ihrer Konfiguration installiert werden. Die Installationszeit variiert je nachdem, ob eine Sparse-root oder Whole-root Zone installiert wird. Weiterhin bestimmt die Menge der in der globalen Zone installierten Software, die benutzte Plattentechnologie (SATA, IDE, SCSI, FC) und ob ein Schreibcache in dem benutzten Plattensubsystem vorhanden ist, die Zeit zur Installation einer Zone. Diese Zeit kann für eine Sparse- root Zone zwischen 3 und 20 Minuten variieren.
global# zoneadm -z zone1 install Preparing to install zone
Nach der Installation einer Zone ist nach dem ersten Boot der Zone ein zlogin -C
71 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.1.8. Deinstallation einer Zone [dd] Installierte Zonen werden durch zoneadm -z
global# zonecfg -z centos centos: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:centos> create -t SUNWlx zonecfg:centos> set zonepath=/zones/centos zonecfg:centos> add net zonecfg:centos:net> set physical=bge0 zonecfg:centos:net> set address=192.168.1.100 zonecfg:centos:net> end zonecfg:centos> add attr zonecfg:centos:attr> set name=audio zonecfg:centos:attr> set type=boolean zonecfg:centos:attr> set value=true zonecfg:centos:attr> end zonecfg:centos> verify zonecfg:centos> commit zonecfg:centos> exit global# zoneadm -z centos install -v -d /dist/brandz/images A ZFS file system has been created for this zone. Verbose output mode enabled. Installing zone "centos" at root "/zones/centos" Attempting ISO-based install from directory: "/dist/brandz/images" Checking possible ISO "/dist/brandz/images/CentOS-3.8-i386-bin1of3.iso"... added as lofi device "/dev/lofi/1" Attempting mount of device "/dev/lofi/1" on directory "/tmp/lxiso"... succeeded. Attempting to read "/tmp/lxiso/.discinfo"... Unmounting device "/dev/lofi/1"... succeeded......
Completing installation; this may take a few minutes. Setting up the initial lx brand environment. System configuration modifications complete. Installation of CentOS 3.8 to zone 'centos' completed Mon Aug 6 16:42:55 CEST 2007.
Installation of zone 'centos' completed successfully.
Details saved to log file: "/zones/centos/root/var/log/centos.install.1594.log" global#
72 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.1.10. Konfiguration und Installation eines Solaris 8/Solaris9 Containers [ug] Solaris 8 Container und Solaris 9 Container lassen sich durch 4 einfache Schritte erzeugen. 1. Planung, wie sich die Datenbereiche und Netzwerk-Interfaces des Quellsystems unter Solaris 8 (oder Solaris 9) in Solaris 10 repräsentieren lassen. 2. Dann wird das Solaris 8 System archiviert. Dazu lässt sich das mitgelieferte P2V Tool nutzen, aber auch jedes andere Archivierungstool wie tar oder cpio. 3. Nun wird die Zone als Solaris 8 Container (bzw. Solaris 9 Container) konfiguriert. 4. Das archivierte System wird mit zoneadm install installiert. 5. Die Daten werden auf die neue Speicher-Architektur transportiert. 6. Das System ist fertig zum Test.
5.1.11. Optionale Einstellungen [dd] Nach der Konfiguration der Zone können Änderungen der Konfiguration vorgenommen werden. Einige Beispiele werden in den folgenden Abschnitten anhand von der sparse-root Zone zone1 aufgeführt. Änderungen an der Zonenkonfiguration werden mit einem Neustart der Zone aktiviert. 5.1.11.1. Automatisches Starten von Zonen [dd] Zonen können so konfiguriert werden, das sie direkt nach dem Booten des Systems gestartet werden. In der Ursprungskonfiguration müssen Zonen nachträglich durch den Administrator gestartet werden.
global# zonecfg -z zone1 zonecfg:zone1> set autoboot=true zonecfg:zone1> commit zonecfg:zone1> exit global#
5.1.11.2. Privilegien-Set einer Zone verändern [dd] Das Privilegienset einer lokalen Zone kann um bestimmte Privilegien erweitert werden. So sind z.B. zur Nutzung von DTrace auf lokale Prozesse der eigenen Zone zusätzlich die Privilegien dtrace_proc und dtrace_user in einer Zone notwendig (Siehe 4.5.6 DTrace von Prozessen in einer Zone ). global# ppriv -l zone | wc -l global# 68
zone1# ppriv -l zone | wc -l zone1# 34
global# zonecfg -z zone1 zonecfg:zone1> set limitpriv=default,dtrace_proc,dtrace_user zonecfg:zone1> commit zonecfg:zone1> exit
zone1# ppriv -l zone | wc -l zone1# 36
73 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.1.12. Storage in einer Zone [dd] Storage kann in lokalen Zonen unterschiedlich benutzt werden. Die Art und Weise der Benutzung kann auf die folgenden Arten klassifiziert werden: • Device oder NFS • Raw-Device in der lokalen Zone direkt benutzen • Mount • Die globale Zone stellt der lokalen Zone ein Filesystem per lofs bereit • Die globale Zone mountet ein Filesystem beim Booten der lokalen Zone • Die Zone mountet ein Filesystem von einem Raw-Device • Zugriff • read/write • readonly • Filesystem gemeinsam durch mehrere Zonen schreibbar benutzen 5.1.12.1. Benutzung eines Raw-Device in einer lokalen Zone [dd] Wird ein direkter Zugriff auf ein Raw-Device durch die lokale Zone benötigt, muss das Gerät durch die entsprechende Zonenkonfiguration freigeschaltet werden. Nach einem Neustart der Zone steht der Geräteeintrag aus Sicht der lokalen Zone unter /dev zur Verfügung.
global# zonecfg -z zone1 zonecfg:zone1> add device zonecfg:zone1:device> set match=/dev/rdsk/c1d0s0 zonecfg:zone1:device> end zonecfg:zone1> info device device: match: /dev/rdsk/c1d0s0 zonecfg:zone1> commit zonecfg:zone1> exit
5.1.12.2. Die globale Zone stellt der lokalen Zone ein Filesystem per lofs bereit [dd] /export/globalhome der globalen Zone soll in der lokalen Zone schreibbar als /export/home gemountet werden. Da /export/globalhome in der globalen Zone bereits verfügbar ist, kann das Zufügen des Filesystems als loopback-Filesystem erfolgen. Wird das Loopback-Filesystem schreibbar gemountet, können sowohl die globale Zone als auch die Zone1 auf dem Filesystem schreiben.
global# zonecfg -z zone1 zonecfg:zone1> add fs zonecfg:zone1:fs> set special=/export/globalhome zonecfg:zone1:fs> set dir=/export/home zonecfg:zone1:fs> set type=lofs zonecfg:zone1:fs> add options rw zonecfg:zone1:fs> info fs: dir: /export/home special: /export/globalhome raw not specified type: lofs options: [rw] zonecfg:zone1:fs> end zonecfg:zone1>
74 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.1.12.3. Die globale Zone mountet ein Filesystem beim Booten der lokalen Zone [dd] Filesysteme können durch die globale Zone nicht nur als Loopback-Filesystem einer lokalen Zone bereitgestellt werden. Das folgende Beispiel zeigt das Mounten eines Filesystems als UFS direkt beim Booten der Zone. Das Filesystem wird durch die globale Zone in /zones/
global# zoneadm -z zone1 reboot global# df -kZ /dev/dsk/c1d0s0 Filesystem kbytes used avail capacity Mounted on /dev/dsk/c1d0s0 7064379 3794979 3198757 55% /zones/zone1/root/mnt
5.1.12.4. Die lokale Zone mountet ein UFS-Filesystem von einem Device [dd] Auch die lokale Zone selbst kann Filesysteme mounten. Dazu muss das entsprechende Block- und Raw-Device für die Zone freigegeben werden. Nach einem Neustart der Zone stehen die Geräte der Zone zur Verfügung. zonecfg:zone1> add device zonecfg:zone1:device> set match=/dev/dsk/c1d0s0 zonecfg:zone1:device> end zonecfg:zone1> add device zonecfg:zone1:device> set match=/dev/rdsk/c1d0s0 zonecfg:zone1:device> end zonecfg:zone1> info device device: match: /dev/dsk/c1d0s0 device: match: /dev/rdsk/c1d0s0 zonecfg:zone1> commit zonecfg:zone1> exit
Nach der Installation und dem Boot der Zone kann der Mount innerhalb der Zone ausgeführt werden.
zone1# ls /dev/dsk c1d0s0 zone1# mount /dev/dsk/c1d0s0 /mnt zone1# df -k /dev/dsk/c1d0s0 Filesystem kbytes used avail capacity Mounted on /dev/dsk/c1d0s0 7064379 3794979 3198757 55% /mnt global# df -kZ /zones/zone1/root/dev/dsk/c1d0s0 Filesystem kbytes used avail capacity Mounted on /zones/zone1/root/dev/dsk/c1d0s0 7064379 3794979 3198757 55% /zones/zone1/root/mnt
75 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.1.12.5. User Level NFS-Server in einer lokalen Zone [ug] Das system-eigene NFS in dem Solaris-Kernel kann zur Zeit nicht als Server innerhalb einer lokalen Zone benutzt werden.
Stattdessen kann man den unfs3d - einen OpenSource NFS Server – nutzen (unfs3 Projekt bei SourceForge), der vollständig im Userland läuft und daher dieser Limitierung nicht unterliegt. Dazu muss man die RPC Konfiguration ändern und statt dem Solaris NFS Dämon den unfs3d aufrufen. 5.1.12.6. Ein DVD Laufwerk in der lokalen Zone benutzen [dd] Wird der Zugriff auf ein DVD-Laufwerk in einer lokalen Zone benötigt, ist das DVD-Laufwerk für die Zone aus der globalen Zone heraus in der Zonenkonfiguration freizugeben. Zusätzlich muss noch verhindert werden, dass der Volume Daemon der globalen Zone die DVD automatisch mountet, wenn sie in das Laufwerk gelegt wird. Dazu muss der smf-Service svc:/system/filesystem/volfs in der globalen Zone abgeschaltet werden. Dieser Service steht lokalen Zonen nicht zur Verfügung. Deshalb müssen DVDs in lokalen Zonen per Kommandozeile gemountet werden. Nach einem Neustart der Zone steht das Gerät der Zone zur Verfügung. Die ist durch den Eintrag in /dev/dsk überprüfbar. Weiterhin ist aus der globalen Zone heraus sichtbar, das sich nun in /zones/zone1/dev/dsk ein Geräteeintrag befindet. zonecfg:zone1> add device zonecfg:zone1:device> set match=/dev/dsk/c2t0d0s2 zonecfg:zone1:device> end zonecfg:zone1> commit zonecfg:zone1> exit
global# svcadm disable volfs
. . . . reboot der Zone . . . .
zone1# ls /dev/dsk c2t0d0s2 zone1# mount -F hsfs /dev/dsk/c2t0d0s2 /mnt zone1# df -k /dev/dsk/c2t0d0s2 Filesystem kbytes used avail capacity Mounted on /dev/dsk/c2t0d0s2 2643440 2643440 0 100% /mnt
global# df -kZ /zones/zone1/root/dev/dsk/c2t0d0s2 /Filesystem kbytes used avail capacity Mounted on /zones/zone1/root/dev/dsk/c2t0d0s2 2643440 2643440 0 100% /zones/zone1/root/mnt
Alternativ kann die DVD als Loopback-Filesystem in eine oder mehrere Zonen gemountet werden. In dem Fall muss sie durch die globale Zone gemountet werden und kann erst wieder ausgeworfen werden, wenn alle Loopback-Mounts der Zonen aufgehoben sind. 5.1.12.7. Dynamisches Konfigurieren von Geräten (Devices) [ug] Devices lassen sich statisch (dauerhaft) per zonecfg in eine Zone einbringen. Allerdings ist zur Aktivierung ein Reboot der Zone notwendig: global# zonecfg -z test zonecfg:test> add device zonecfg:test:device> set match=/dev/dsk/c1t1d0s1 zonecfg:test:device> end zonecfg:test> verify zonecfg:test> commit zonecfg:test> exit
76 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 Zur dynamischen Konfiguration muss man major und minor Nummer des Devices ermitteln, dazu kann man das ls Kommando in der globalen Zone nutzen. Die Option -L ist hier wichtig, weil sie symbolische Links bis zum eigentlichen Eintrag in /devices verfolgt: global# cd /dev global# ls -lL /dev/rdsk/c1t1d0s1 crw-r----- 1 root sys 118, 1 Dec 5 19:33 rdsk/c1t1d0s1 global#
Mit diesen Informationen kann man dann im /dev Verzeichnis der lokalen Zone mit dem Kommando mknod einen entsprechenden Eintrag vornehmen. Dabei sind der Typ des Devices (hier c = character device) und die Major sowie die minor Device-Nummer anzugeben (hier 118 und 1 aus der ls -lL Ausgabe). Danach sollte man noch die entsprechenden Zugriffsrechte mit chmod setzen. global# cd ...zonepath.../dev global# mknod rdsk/c1t1d0s1 c 118 1
global# ls -lL rdsk/c1t1d0s1 crw-r--r-- 1 root root 118, 1 Jan 29 16:06
global# chmod o-r rdsk/c1t1d0s1 global# ls -lL rdsk/c1t1d0s1 crw-r----- 1 root root 118, 1 Jan 29 16:06 rdsk/c1t1d0s1
Nun ist das Device innerhalb der Zone sofort sichtbar und sofort nutzbar. test# ls -l /dev/rdsk/c* crw-r--r-- 1 root root 118, 1 Jan 29 16:06/dev/rdsk/c1t1d0s1 bash-3.00 ls -l /dev/rdsk/c* total 0 crw-r----- 1 root root 118, 1 Jan 29 16:06 c1t1d0s1
test# reboot
Für eine dauerhafte Verwendung und zur Dokumentation sollte das Device auf jeden Fall auch noch in der Zonenkonfiguration eingetragen werden. global# zonecfg -z test zonecfg:test> add device zonecfg:test:device> set match=/dev/rdsk/c1t1d0s1 zonecfg:test:device> end zonecfg:test> verify zonecfg:test> commit zonecfg:test> exit global#
Wenn dann das Device aus der Zonenkonfiguration gelöscht wird, dann ist es nach dem nächsten Reboot auch aus dem /dev-Verzeichnis der lokalen Zone entfernt. Diese Vorgehensweise ist dem manuellen Entfernen aus dem /dev-Verzeichnis vorzuziehen. global# zonecfg -z test zonecfg:test> remove device match=/dev/rdsk/c1t1d0s1 zonecfg:test> verify zonecfg:test> commit zonecfg:test> exit global#
77 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.1.12.8. Mehrere Zonen teilen sich ein Filesystem [dd] Durch das Zonenmodell ist es sehr einfach möglich, das sich mehrere Zonen ein Filesystem schreibbar teilen. Das wird dann möglich, wenn die globale Zone ein Filesystem mountet und dasselbe Filesystem als read/write-Loopback-Filesystem mehreren Zonen zur Verfügung stellt (Kochbuch 5.1.12.2 Die globale Zone stellt der lokalen Zone ein Filesystem per lofs bereit ). Aus Sicht von Solaris handelt es sich hier um gleichberechtigte Schreiboperationen in einem lokalen Filesystem. Die Anwendungen müssen das ggf. benötigte File-Locking selbst realisieren. Diese Vorgehensweise entspricht dem Zugriff auf ein NFS-Filesystem von mehreren Clients aus. Hier entspricht die globale Zone dem NFS-Server und die lokalen Zonen den NFS Clients. 5.1.12.9. ZFS in einer Zone [ug] Ein ZFS Filesystem kann man einer Zone übergeben, so dass der Administrator der Zone das Filesystem weiterverwenden kann. • Mit add dataset des zonecfg-Kommando kann das ZFS der Zone übergeben werden. • In der Zone kann der Administrator weitere ZFS Filesysteme mit zfs create von dem Filesystem ableiten. • Das in der globalen Zone gesetzte Attribut quota kann in der Zone nicht verändert oder überschritten werden. • Der Administrator der Zone kann jedoch den Mountpunkt innerhalb der Zone festlegen.
# zpool create -m none tank # zfs create tank/zone1 # zfs set quota=1g tank/zone1 # zfs set mountpoint=/mnt tank/zone1 # # zonecfg -z zone1 zonecfg:zone1> add dataset zonecfg:zone1:device> set name=tank/zone1 zonecfg:zone1:device> end zonecfg:zone1> commit zonecfg:zone1> exit
. . . reboot der Zone zone1 . . .
. . . login in die Zone zone1 . . .
zone1# zfs list NAME USED AVAIL REFER MOUNTPOINT tank 30.2M 10G 18K none tank/zone1 16.3M 983M 16.3M /mnt
5.1.12.10. User-Attribute für ZFS in einer Zone [ug] Mit ZFS ist es möglich, bei jedem Filesystem zusätzliche beliebige Attribute zu verwalten, die zusammen mit dem Filesystem gespeichert werden (Solaris 10 5/08). Die Bedingung ist, dass diese zugefügten Attribute ein „:“ im Namen enthalten. Diese sogenannten User-Attribute können sowohl manuell eingesehen als auch in Scripten verwendet werden. Der Vorteil ist die Speicherung innerhalb des Filesystems, so dass die Dokumentation beim Filesystem verbleibt, auch wenn es von einem anderen Rechner benutzt wird. # zfs set admin:application="DB Webportal" tank/db234_01 # zfs set admin:importance="critical" tank/db234_01 # zfs set admin:costcenter="47110815" tank/db234_01 # zfs set admin:application="App-Server Webportal" tank/web234_01 # zfs set admin:costcenter="47110815" tank/web234_01 # zfs get all tank/web234_01 | fgrep admin: tank/web234_01 admin:application App-Server Webportal local tank/web234_01 admin:costcenter 47110815 local # # zfs get -H -o value admin:costcenter tank/db234_01 47110815
78 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 5.1.13. Konfiguration einer Zone durch Kommando-Datei oder Template [dd] Gleichartige Zonen können durch die Nutzung von Kommando-Dateien für zonecfg oder durch die Nutzung von Templates konfiguriert werden. So ist eine schnelle und fehlerfreie Konfiguration vieler Zonen möglich. • Nutzung von zonecfg-Kommando-Datei Es wird eine Kommando-Datei für die automatische Konfiguration der Zone erstellt. 1. zonecfg Kommando-Datei erstellen - mit zonecfg -z
5.1.14. Automatische Schnell-Installation von Zonen [ug] Die Installation von Zonen dauert abhängig von der Geschwindigkeit des Filesystems (Platten) und der zu kopierenden Software der Zone wenige bis einige Minuten. Dies kann erheblich verkürzt werden, wenn viele Zonen erzeugt werden sollen, die bezüglich der Konfiguration identisch sind (wesentlich sind hier die inherit-pkg-dir Einstellungen). Vorbereitung: 1. zonecfg einer Template Zone mit der gewünschten Konfiguration, die später nicht benutzt werden darf (zum Beispiel mit dem Namen template1). Hierbei muss zonepath gesetzt werden, die Konfiguration der Netzwerk-Adresse sollte fehlen, weil die Zone ja nur als Template dient und nicht in Betrieb gehen soll. 2. Installieren der Zone template1 mit zoneadm. 3. Sichern des Inhaltes der Zone template1 in einer tar-Datei template1.tar . (Anmerkung: cp -r ist nicht geeignet um Zonen zu kopieren!)
Erzeugen von duplizierten Zonen: 1. Konfiguration mit zonecfg unter Nutzung der Template Funktion (create -t template1). (Die inherit-pkg-dir Einstellungen dürfen nicht verändert werden!) 2. Ändern von zonepath mit zonecfg (kann per Skript geschehen) 3. Eintragen von Netzwerkadresse(n) mit zonecfg. 4. Auspacken von template1.tar unterhalb zonepath der neuen Zone. 5.
Da die Template Zone nicht direkt startbar ist, ist zum Einspielen der Patches die folgende Vorgehensweise notwendig: 1. Konfigurieren der Zone template1 (manuell oder mit sysidcfg-Datei) 2. Einspielen der Patches (am besten sind alle konfigurierten Zonen hochgefahren) 3. De-Konfigurieren der Zone template1 mit dem Kommando zlogin template1 sys-unconfig 4. Neu Erzeugen der Zonen-Inhaltsdatei template1.tar . Alternativ kann statt manueller Kopie das Kommando zoneadm -z template1 clone benutzt werden.
79 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.1.15. Beschleunigtes automatisches Erstellen von Zonen auf einem ZFS-Dateisystem [bf/ug] Falls eine Zone auf einem ZFS-Dateisystem konfiguriert ist, kann diese durch die Verwendung von ZFS-Snapshots sehr schnell dupliziert werden. Dieses Verfahren wird im Folgenden anhand eines Beispiel-Skripts beschrieben. Das Skript steht unter http://blogs.sun.com/blogfinger/entry/how_to_create_a_lot zum Herunterladen bereit. In ersten Teil des Scripts sind die wichtigsten Parameter für die Zonen zu definieren. Dazu gehören zum Beispiel: • Anzahl der zu erzeugenden Zonen • Netzwerk-Adressbereich • Name des Netzwerk Interfaces • Netzmaske • Gateway • Basis-Zonenname (wird mit Nummer zum Zonennamen ergänzt) • Verzeichnis für die Zonen (wird mit Zonenname ergänzt) • Der Name der Zone, die als Basis für das Klonen verwendet wird. • Informationen für die sysidcfg - Datei • Startzustand für die Zone nach der Installation
Wenn diese Einstellungen vorgenommen sind, kann das Script die Zonen automatisch erzeugen und in den konfigurierten Zustand starten. Mehr Details zu dem Script sind in dem Blog-Eintrag verfügbar. 5.1.16. Härten von Zonen [dd] Zum Härten von Solaris wird grundsätzlich das Solaris Security Toolkit empfohlen. Die kompletten Abläufe und Mechanismen sind hier abgelegt: http://www.sun.com/products-n- solutions/hardware/docs/Software/enterprise_computing/systems_management/sst/index.html
Innerhalb des Toolkits werden die Besonderheiten beschrieben, die zur Härtung von Sparse root oder Whole root Zonen notwendig sind. Details dazu sind hier zu finden: http://www.sun.com/products-n-solutions/hardware/docs/html/819-1503-10/introduction.html#pgfId- 1001177 Mit Solaris 10 11/06 wurde das Feature „Secure by Default“ für Netzwerkdienste eingeführt, mit dem durch den Aufruf von netservices limited alle Netzwerkdienste bis auf sshd abgeschaltet werden bzw. so umkonfiguriert werden, dass sie nur auf Anfragen vom localhost reagieren. Dadurch ist mit einfachen Mitteln eine erhebliche Absicherung von Zonen in Netzwerken möglich.
80 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 5.2. Netzwerk 5.2.1. Netzwerkkonfiguration für Shared IP-Instanzen ändern [dd] Für eine bereits konfigurierte Zone mit einer shared IP-Instanz kann die Veränderung des physikalischen Interfaces oder der Netzwerkadresse notwendig sein.
global# zonecfg -z zone1 zonecfg:zone1> info net net: address: 192.168.1.1/24 physical: bge1 zonecfg:zone1> select net physical=bge1 zonecfg:zone1:net> set physical=bge0 zonecfg:zone1:net> set address=192.168.2.1/24 zonecfg:zone1:net> info net: address: 192.168.2.1/24 physical: bge0 zonecfg:zone1:net> end zonecfg:zone1> commit zonecfg:zone1> exit global#
5.2.2. Default Router für Shared-IP Instanz setzen [dd] In der Zonenkonfiguration kann der Defaultrouter für eine Zone mit einer Shared-IP Instanz festgelegt werden. Die Nutzung dieser Konfigurationsoption stellt beim Booten einer Zone sicher, das eine bestimmte Netzwerkroute in der globalen Zone verfügbar ist (seit Solaris 10 11/08) global# zonecfg -z keetonga zonecfg:keetonga> select net physical=e1000g0 zonecfg:keetonga:net> set defrouter=1.2.3.1 zonecfg:keetonga:net> info net: address: 1.2.3.4/24 physical: e1000g0 defrouter: 1.2.3.1 zonecfg:keetonga:net> end
5.2.3. Netzwerkinterfaces für Exklusive-IP Instanzen [dd] Für die Nutzung von exklusiven IP-Instanzen sind GLDv3-fähige Netzwerkinterfaces oder tagged VLAN-Interfaces notwendig, die im folgenden insgesamt als GLDv3-Interfaces bezeichnet werden. Zu diesen Treibern zählen: bge, ce, e1000g, eri, hme, ixgb, nge, nxge, rge, xge. Weitere Details zu unterstützen Adaptern finden sich unter: http://opensolaris.org/os/project/crossbow/faq/#ip_instances Die Adapter eines Systems können mit dladm show-link angezeigt werden.
Jeder exklusiven IP-Instanz ist ein physikalisches Interface oder ein tagged VLAN-Interface zuzuweisen. Deshalb ergibt sich aus der Anzahl der benötigten Zonen mit einer exklusiven IP-Instanz die benötigte Anzahl von Interfaces. Werden tagged VLAN-Interfaces benutzt, ergibt die maximale Anzahl von Zonen innerhalb eines VLAN die Anzahl der benötigten physikalischen Interfaces. Der Grund ist die Erzeugungsregel für tagged VLAN-Interfaces: Interface = Interfacename
81 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.2.4. Netzwerkkonfiguration von Shared-IP Instanz auf Exklusive-IP Instanz ändern [dd] Bereits konfigurierte Zonen werden bis Solaris 10 11/06 mit shared IP-Instanzen betrieben. Mit der Einführung von Solaris 10 8/07 besteht die Möglichkeit, Zonen mit einer exklusiven IP-Instanz zu betreiben. Dazu muss die Zonenkonfiguration angepasst werden und der Zone ein physikalisches Interface oder ein tagged VLAN-Interface zugewiesen werden. In diesem Beispiel wird ein VLAN mit der VLAN-ID 1 auf dem Interface bge0 der Zone zugewiesen. Der Device-Eintrag wird durch die globale Zone beim Starten der Zone automatisch erzeugt. Die IP-Adresse wird dem Interface durch die Zone selbst zugewiesen. global# zonecfg -z zone1 zonecfg:zone1> info net net: address: 192.168.2.1/24 physical: bge0 zonecfg:zone1> info ip-type ip-type: shared zonecfg:zone1> set ip-type=exclusive zonecfg:zone1> verify net: address cannot be specified for an exclusive IP type zone1: Invalid argument zonecfg:zone1> remove net physical=bge0 zonecfg:zone1> add net zonecfg:zone1:net> set physical=bge1000 zonecfg:zone1:net> end zonecfg:zone1> info net net: address not specified physical: bge1000 zonecfg:zone1> verify zonecfg:zone1> commit zonecfg:zone1> exit
5.2.5. IP Filter zwischen Shared-IP Zonen auf einem System [dd] IP Filter kann zur Filterung von Netzwerkpaketen zwischen shared-IP Zonen benutzt werden. Hierzu wird IP Filter zwar in der globalen Zonen konfiguriert und gestartet, filtert aber mit den entsprechenden Regeln den Datenverkehr zwischen Zonen. Zu beachten ist hier, das Datenverkehr zwischen Shared-IP Zonen den TCP/IP-Stack des Systems nicht verlässt. Damit dieser Datenverkehr von IP Filter mit betrachtet wird, muss in die IP Filter- Konfiguration die Zeile set intercept_loopback true; mit aufgenommen werden. Das nachfolgende Beispiel filtert den gesamten Datenverkehr zwischen zwei Zonen (Zone keetonga: 192.168.1.210; Zone haitoda: 192.168.1.200). global# cd /etc/ipf global# more ipf.conf set intercept_loopback true; block in from 192.168.1.210/32 to 192.168.1.200/32 block out from 192.168.1.210/32 to 192.168.1.200/32 block in from 192.168.1.200/32 to 192.168.1.210/32 block out from 192.168.1.200/32 to 192.168.1.210/32 global# svcadm enable ipfilter
Das nachfolgende Beispiel zeigt, wie ssh-Verbindungen von Zone keetonga zur Zone haitoda gefiltert werden, nachdem eine vorhandene IP Filter Konfiguration verändert und neu geladen wurde. global # more ipf.conf set intercept_loopback true; block in proto tcp from 192.168.1.210/32 to 192.168.1.200/32 port = ssh
global # ipf -F a -f /etc/ipf/ipf.conf
82 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 5.2.6. IP Filter zwischen Exclusive-IP Zonen auf einem System [dd] Zur Verwendung von IP Filter in Exclusive-IP Zonen sind die üblichen Konfigurationsregeln für IP Filter zu befolgen. Das ist möglich, da bei Exclusive-IP Instanzen der Zone der physikalische Netzwerkport zugewiesen wurde. Nach der Konfiguration von IP Filter pro Zone, wird in jeder Zone IP Filter aktiviert und arbeitet in jeder IP-Instanz unabhängig. Das Kommando dazu lautet: svcadm enable ipfilter 5.2.7. Zonen, Netzwerke und Routing [dd/ug] Die folgende Abschnitte beschreiben Szenarien im Umfeld Zonen, Netzwerke und Routing. Folgende Einschränkungen existieren: • In den angeschlossenen Netzen darf die gleiche IP-Adresse nicht doppelt vergeben sein. Kann dies auf Grund von organisatorischen Gegebenheiten nicht verhindert werden, muss eine Abtrennung mit NAT-Routern (Szenario 3) benutzt werden. • Routing zwischen den Adressen der Zonen mit shared-IP erfolgt im System. Externes Routing kann nur mittels NAT Routern erzwungen werden. Routing zwischen Zonen kann unterbunden werden durch: ndd -set /dev/ip restrict_interzone_loopback 1 • Die vorgenommene Netzwerkseparierung wird im Solaris auf logischer TCP/IP-Ebene realisiert. Für viele Einsatzfälle ist das ausreichend. • Ist eine Trennungen auf physikalischer Netzwerkebene notwendig, kann dieses durch separate Systeme, Solaris Domains oder - seit Solaris 10 8/07 - durch exklusive IP-Instanzen realisiert werden.
5.2.7.1. Globale und lokale Zone mit gemeinsamem Netzwerk [dd/ug] Zwei lokale Zonen zone1 und zone2 befinden sich im gleichen Netzwerksegment wie die globale Zone. • Jede lokale Zone kann auf dem gleichen Netzwerk-Interface wie die globale Zone eingerichtet werden. • Das Routing, das für die globale Zone einrichtet ist, gilt auch für die lokalen Zonen. Alle Zonen (globale und lokale) können miteinander kommunizieren.
Realisierung: • Die Zonen werden mit dem Netzwerk-Interface der globalen Zone eingerichtet; ist dies bge0, dann wird mit zonecfg: add net die Einstellung set physical=bge0 vorgenommen. • Jede lokale Zone muss eine Adresse aus dem Netzwerk der globalen Zone erhalten.
192.168.1.0 Netzwerk
bge0:1 - 192.168.1.201 bge0:2 - 192.168.1.202 Zone 1 Zone 2
bge0 - 192.168.1.1 Globale Zone
Zeichnung 31: [dd] Globale und lokale Zone mit gemeinsamem Netzwerk
83 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.2.7.2. Zonen in getrennten Netzwerksegmenten unter Nutzung der Shared-IP Instanz [dd/ug] Zwei lokale Zonen zone1 und zone2 befinden sich in logisch getrennten Netzwerksegmenten und stellen für diese Netzwerksegmente Dienste zur Verfügung. • Jede lokale Zone soll ein eigenes physikalisches Interface in dem Netzwerksegment haben. • An dem Netzwerksegment ist kein weiteres Netzwerk angeschlossen. • Routing wird nicht eingesetzt. • Eine Kommunikation zwischen den lokalen Zonen soll nicht stattfinden. • Eine Kommunikation zwischen der globalen Zone und den lokalen Zonen ist nicht vorgesehen.
Realisierung: • Das für die lokale Zone vorgesehene Netzwerk-Interface (z.B. bge1) darf in der globalen Zone nicht anderweitig benutzt sein. • Zur Vorbereitung für lokale Zonen muss das Interface geplumbt werden (aber nicht aktiviert): ifconfig bge1 plumb down Damit erhält das Interface die Adresse 0.0.0.0, die aber nicht aktiv ist. • Routing-Einträge werden nicht vorgenommen. • Option: Wenn eine Kommunikation zwischen der globalen und der lokalen Zone möglich sein soll, ist in der globalen Zone das Interface mit einer Adresse zu konfigurieren, die sich im Netzwerk der lokalen Zone befindet.
192.168.201.0 192.168.202.0 Netzwerk Netzwerk
bge1:1 - 192.168.201.1 bge2:2 - 192.168.202.1 Zone 1 Zone 2
bge0 - 192.168.1.1 bge1 - 0.0.0.0 bge2 - 0.0.0.0 Globale Zone
192.168.1.0 Netzwerk Zeichnung 32: [dd] Zonen in getrennten Netzwerksegmenten unter Nutzung der shared IP-Instanz
84 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.2.7.3. Zonen in getrennten Netzwerksegmenten unter Nutzung der exklusiven IP-Instanzen [dd/ug] Zwei lokale Zonen zone1 und zone2 befinden sich in logisch getrennten Netzwerksegmenten und stellen für diese Netzwerksegmente Dienste zur Verfügung. • Jede lokale Zone soll ein eigenes physikalisches Interface in dem Netzwerksegment haben. • An dem Netzwerksegment ist kein weiteres Netzwerk angeschlossen. • Routing wird nicht eingesetzt. • Eine Kommunikation zwischen den lokalen Zonen soll nicht stattfinden. • Eine Kommunikation zwischen der globalen Zone und den lokalen Zonen ist nicht vorgesehen.
Realisierung: • Für jede Zone wird ein eigenes GLDV3-Interface (z.B. bge1 und bge2) vorgesehen. Diese Interfaces dürfen in der globalen Zone nicht anderweitig benutzt werden. zone1-zonecfg: add net physical=bge1 zone2-zonecfg: add net physical=bge2 • Die Zonenkonfiguration wird für zone1 und zone2 auf die Benutzung von exklusiven IP- Instanzen umgestellt. zonecfg: set ip-type=exclusive • In den Zonen werden über die üblichen Wege die IP-Adressen festgelegt. Zone 1: /etc/hostname.bge1 Zone 2: /etc/hostname.bge2 • Routing-Einträge werden in den Zonen nicht vorgenommen. • Option: Wenn eine Kommunikation zwischen der globalen und der lokalen Zone möglich sein soll, ist in der globalen Zone ein Interface zu konfigurieren, das sich in dem logischen Netzwerk der lokalen Zone befindet. • Durch die exklusiven IP-Instanzen findet eine Kommunikation zwischen den Zonen bzw. zwischen den Zonen und der globalen Zone nur statt, wenn entsprechende Routingeinträge in den Zonen existieren und eine physikalische Netzwerkverbindung zwischen den Interfaces der Zonen existiert.
192.168.201.0 192.168.202.0 Netzwerk Netzwerk
bge1 - 192.168.201.1 bge2 - 192.168.202.1 ip-type: exclusive ip-type: exclusive Zone 1 Zone 2
bge0 - 192.168.1.1 ip-type: shared Globale Zone
192.168.1.0 Netzwerk Zeichnung 33: [dd] Zonen in getrennten Netzwerksegmenten unter Nutzung der exklusiven IP-Instanzen
85 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.2.7.4. Zonen in getrennten Netzwerken unter Nutzung der Shared IP-Instanz [dd/ug] Zwei lokale Zonen zone1 und zone2 befinden sich in logisch getrennten Netzwerken und stellen Dienste für andere Netze zur Verfügung. – Jede lokale Zone soll ein eigenes physikalisches Interface in dem Netzwerk haben. – An dem Netzwerksegment sind weitere Netzwerke angeschlossen. – Routing wird eingesetzt. – Eine Kommunikation zwischen den lokalen Zonen soll nicht stattfinden. – Eine Kommunikation zwischen der globalen Zone und den lokalen Zonen ist nicht vorgesehen. Realisierung: • Das für die lokale Zone vorgesehene Netzwerk-Interface (z.B. bge1) darf in der globalen Zone nicht anderweitig benutzt sein. • Zur Vorbereitung für lokale Zonen muss das Interface geplumbt werden (aber nicht aktiviert): ifconfig bge1 plumb down Damit erhält das Interface die Adresse 0.0.0.0, die aber nicht aktiv ist. • Die Netzwerk-Konfiguration der Zonen wird hochgefahren, in dem man die Zonen auf den Zustand ready setzt. zoneadm -z zone1 ready zoneadm -z zone2 ready Die in der Konfiguration der Zonen angegebenen Adressen (zone1: 192.168.201.1 und zone2: 192.168.202.1) sind nun aktiv. • Die Routen der lokalen Zonen werden mit zonecfg:set defrouter gesetzt. set defrouter=192.168.201.2 set defrouter=192.168.202.2 • Damit keine Kommunikation zwischen den lokalen Zonen durch den shared TCP/IP-Stack stattfindet, müssen in der globalen Zone reject-routes gesetzt werden, die eine Kommunikation zwischen zwei IP-Adressen unterbinden(oder Nutzung von ipfilter). route add 192.168.201.1 192.168.202.1 -interface -reject route add 192.168.202.1 192.168.201.1 -interface -reject Alternativ kann das Interzonen-Routing wie folgt unterbunden werden: ndd -set /dev/ip ip_restrict_interzone_loopback 1 • Die Zonen können jetzt zum Betrieb gebootet werden: zoneadm -z zone1 boot zoneadm -z zone2 boot • Option: Wenn eine Kommunikation zwischen der globalen und der lokalen Zone möglich sein soll, ist in der globalen Zone ein Interface zu konfigurieren, das sich in dem logischen Netzwerk der lokalen Zone befindet.
bge1:1 - 192.168.201.1 bge2:2 - 192.168.202.1 192.168.201.0 192.168.202.0 Def-Router - 192.168.201.2 Def-Router - 192.168.202.2 Netzwerk Netzwerk Zone 1 Zone 2 bge0 - 192.168.1.1 bge1 - 0.0.0.0 bge2 - 0.0.0.0 reject route 192.168.201.1 192.168.202.1 Globale Zone
192.168.1.0 Netzwerk Zeichnung 34: [dd] Zonen in getrennten Netzwerken unter Nutzung der shared IP-Instanz
86 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.2.7.5. Zonen in getrennten Netzwerken unter Nutzung von exklusiven IP-Instanzen [dd] Zwei lokale Zonen zone1 und zone2 befinden sich in logisch getrennten Netzwerken und stellen Dienste für andere Netze zur Verfügung. – Jede lokale Zone soll ein eigenes physikalisches Interface in dem Netzwerk haben. – An dem Netzwerksegment sind weitere Netzwerke angeschlossen. – Routing wird eingesetzt. – Eine Kommunikation zwischen den lokalen Zonen soll nicht stattfinden. – Eine Kommunikation zwischen der globalen Zone und den lokalen Zonen ist nicht vorgesehen.
Realisierung: • Für jede Zone wird ein eigenes GLDV3-Interface (z.B. bge1 und bge2) vorgesehen. Diese Interfaces dürfen in der globalen Zone nicht anderweitig benutzt werden. zone1-zonecfg: add net physical=bge1 zone2-zonecfg: add net physical=bge2 • Die Zonenkonfiguration wird für zone1 und zone2 auf die Benutzung von exklusiven IP- Instanzen umgestellt. zonecfg: set ip-type=exclusive • In den Zonen werden über die üblichen Wege die IP-Adressen und der Default Router festgelegt. Zone 1: /etc/hostname.bge1 Zone 2: /etc/hostname.bge2 /etc/defaultrouter • Durch die exklusiven IP-Instanzen findet eine Kommunikation zwischen den Zonen bzw. zwischen den Zonen und der globalen Zone nur statt, wenn entsprechende Routingeinträge in den Zonen existieren und eine physikalische Netzwerkverbindung zwischen den Interfaces der Zonen existiert.
bge1 - 192.168.201.1 bge2 - 192.168.202.1 192.168.201.0 192.168.202.0 Def-Router - 192.168.201.2 Def-Router - 192.168.202.2 Netzwerk Netzwerk ip-type: exclusive ip-type: exclusive Zone 1 Zone 2
bge0 - 192.168.1.1 ip-type: shared Globale Zone
192.168.1.0 Netzwerk Zeichnung 35: [dd] Zonen in getrennten Netzwerken unter Nutzung von exklusiven IP-Instanzen
87 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.2.7.6. Zonen mit Verbindung in unabhängige Kunden-Netzwerke unter Nutzung der shared IP-Instanz [dd/ug] Zwei lokale Zonen zone1 und zone2 befinden sich in logisch getrennten Netzwerken und stellen Dienste für unterschiedliche Kunden in eigenen Netzwerken zur Verfügung. • Jede lokale Zone soll ein eigenes physikalisches Interface in dem Netzwerk haben. • An dem Netzwerksegment sind weitere Netzwerke des Kunden angeschlossen. • Eine Koordination der Adressvergabe in den Netzwerken findet nicht statt; eine Adresse könnte mehrfach vergeben sein (jeweils 1x pro Kunden-Netzwerk). Anwender nutzen intern oft private IP-Adressen (10.x.y.z, 192.168.x.y). Deshalb ist die Wahrscheinlichkeit der Nutzung derselben Adresse durch unterschiedliche Anwender sehr wahrscheinlich. • Die Zonen zone1 und zone2 sollen aus anderen Netzwerken erreichbar sein. • Die Zonen zone1 und zone2 können keine Verbindungen in andere Netzwerke initiieren. • Eine Kommunikation zwischen den lokalen Zonen soll nicht stattfinden. • Eine Kommunikation zwischen der globalen Zone und den lokalen Zonen ist nicht vorgesehen.
Realisierung: • Das für die lokale Zone vorgesehene Netzwerk-Interface (z.B. bge1) darf in der globalen Zone nicht anderweitig benutzt sein. • Zur Vorbereitung für lokale Zonen muss das Interface geplumbt werden (aber nicht aktiviert): ifconfig bge1 plumb down Damit erhält das Interface die Adresse 0.0.0.0, die aber nicht aktiv ist. • Die Netzwerk-Konfiguration der Zonen wird hochgefahren, in dem man die Zonen auf den Zustand ready setzt. zoneadm -z zone1 ready zoneadm -z zone2 ready Die in der Konfiguration der Zonen angegebenen Adressen (zone1: 192.168.201.1 und zone2: 192.168.202.1) sind nun aktiv. • Die Routen der lokalen Zonen werden mit zonecfg:set defrouter gesetzt. set defrouter=192.168.201.2 set defrouter=192.168.202.2 • Damit keine Kommunikation zwischen den lokalen Zonen durch den shared TCP/IP-Stack stattfindet, müssen in der globalen Zone reject-routes gesetzt werden, die eine Kommunikation zwischen zwei IP-Adressen unterbinden. route add 192.168.201.1 192.168.202.1 -interface -reject route add 192.168.202.1 192.168.201.1 -interface -reject Alternativ kann das Interzonen-Routing wie folgt unterbunden werden: ndd -set /dev/ip ip_restrict_interzone_loopback 1 • Die Zonen können jetzt zum Betrieb gebootet werden: zoneadm -z zone1 boot zoneadm -z zone2 boot • Der Default-Router ist ein NAT-Router, der die IP-Adresse der lokalen Zone zum Kunden hin verbirgt. Auf der Seite des Kunden ist er mit einer IP-Adresse aus dessen Netzwerk konfiguriert. Somit können keine Konflikte bei Adressen mehr auftreten. • Option: Wenn eine Kommunikation zwischen der globalen und der lokalen Zone möglich sein soll, ist in der globalen Zone ein Interface zu konfigurieren, das sich in dem logischen Netzwerk der lokalen Zone befindet.
88 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
192.168.101.0 192.168.102.0 Kunden-Netzwerk Kunden-Netzwerk A B
192.168.101.201 192.168.102.201
NAT- 192.168.201.2 192.168.202.2 NAT- Router Router bge1:1 - 192.168.201.1 bge2:2 - 192.168.202.1 Def-Router - 192.168.201.2 Def-Router - 192.168.202.2 Zone 1 Zone 2 bge0 - 192.168.1.1 bge1 - 0.0.0.0 bge2 - 0.0.0.0 reject route 192.168.201.1 192.168.202.1 Globale Zone
192.168.1.0 Netzwerk Zeichnung 36: [dd] Zonen mit Verbindung in unabhängige Kunden-Netzwerke unter Nutzung der shared IP-Instanz
89 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.2.7.7. Zonen mit Verbindung in unabhängige Kunden-Netzwerke unter Nutzung von exklusiven IP-Instanzen [dd/ug] Zwei lokale Zonen zone1 und zone2 befinden sich in logisch getrennten Netzwerken und stellen Dienste für unterschiedliche Kunden in eigenen Netzwerken zur Verfügung. • Jede lokale Zone soll ein eigenes physikalisches Interface in dem Netzwerk haben. • An dem Netzwerksegment sind weitere Netzwerke des Kunden angeschlossen. • Eine Koordination der Adressvergabe in den Netzwerken findet nicht statt; eine Adresse könnte mehrfach vergeben sein (jeweils 1x pro Kunden-Netzwerk). Das ist mit der heute üblichen Verwendung der privaten IP-Adressen einigermaßen wahrscheinlich. • Die Zonen zone1 und zone2 sollen aus anderen Netzwerken erreichbar sein. • Die Zonen zone1 und zone2 können keine Verbindungen in andere Netzwerke initiieren. • Eine Kommunikation zwischen den lokalen Zonen soll nicht stattfinden. • Eine Kommunikation zwischen der globalen Zone und den lokalen Zonen ist nicht vorgesehen.
Realisierung: • Für jede Zone wird ein eigenes GLDV3-Interface (z.B. bge1 und bge2) vorgesehen. Diese Interfaces dürfen in der globalen Zone nicht anderweitig benutzt werden. zone1-zonecfg: add net physical=bge1 zone2-zonecfg: add net physical=bge2 • Die Zonenkonfiguration wird für zone1 und zone2 auf die Benutzung von exklusiven IP- Instanzen umgestellt. zonecfg: set ip-type=exclusive • In den Zonen werden über die üblichen Wege die IP-Adressen und der Default Router festgelegt. Zone 1: /etc/hostname.bge1 Zone 2: /etc/hostname.bge2 /etc/defaultrouter • Durch die exklusiven IP-Instanzen findet eine Kommunikation zwischen den Zonen bzw. zwischen den Zonen und der globalen Zone nur statt, wenn entsprechende Routingeinträge in den Zonen existieren und eine physikalische Netzwerkverbindung zwischen den Interfaces der Zonen existiert. • Der Default-Router ist ein NAT-Router, der die IP-Adresse der lokalen Zone zum Kunden hin verbirgt. Auf der Seite des Kunden ist er mit einer IP-Adresse aus dessen Netzwerk konfiguriert. Somit können keine Konflikte bei Adressen mehr auftreten.
90 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
192.168.101.0 192.168.102.0 Kunden-Netzwerk Kunden-Netzwerk A B
192.168.101.201 192.168.102.201
NAT- 192.168.201.2 192.168.202.2 NAT- Router Router bge1 - 192.168.201.1 bge2 - 192.168.202.1 Def-Router - 192.168.201.2 Def-Router - 192.168.202.2 ip-type: exclusive ip-type: exclusive Zone 1 Zone 2
bge0 - 192.168.1.1 ip-type: shared Globale Zone
192.168.1.0 Netzwerk Zeichnung 37: [dd] Zonen mit Verbindung in unabhängige Kunden-Netzwerke unter Nutzung von exklusiven IP-Instanzen
5.2.7.8. Verbindung von Zonen über externe Router unter Nutzung der shared IP-Instanz [dd/ug] Ein Webserver in der zone1 wird aus dem Internet kontaktiert und braucht zur Erfüllung der Aufträge den Applikationsserver in der zone2. – Die zone1 soll über ein separates Netzwerk mit dem Internet verbunden sein. – Die Verbindung von zone1 nach zone2 soll über einen externen Load-Balancing Router erfolgen. Wegen der Übersichtlichkeit sind hier keine weiteren Instanzen für Web- und Applikationsserver enthalten. – Eine Kommunikation direkt zwischen den lokalen Zonen soll nicht möglich sein, wohl aber über den externen Router. – Eine Kommunikation zwischen der globalen Zone und den lokalen Zonen ist nicht vorgesehen. Realisierung: • Die für die lokalen Zonen vorgesehenen Netzwerk-Interfaces (bge1, bge2 und bge3) dürfen in der globalen Zone nicht anderweitig benutzt sein. • Zur Vorbereitung für die lokalen Zonen müssen die Interfaces geplumbt werden (aber nicht aktiviert); damit erhalten die Interfaces die Adresse 0.0.0.0: ifconfig bge1 plumb down ifconfig bge2 plumb down ifconfig bge3 plumb down • Die Netzwerk-Konfiguration der Zonen wird hochgefahren, in dem man die Zonen auf den Zustand ready setzt. zoneadm -z zone1 ready zoneadm -z zone2 ready Die in der Konfiguration der Zonen angegebenen Adressen sind nun aktiv. (zone1: 192.168.201.1,192.168.200.1 und zone2:192.168.202.1) • Für die Kommunikation der Zone zone1 mit dem Internet wird eine Default Route gesetzt. zonecfg:set defrouter=192.168.200.2 Weiterhin braucht man eine Route zur scheinbaren Adresse der zone2 hinter dem NAT- Router. route add 192.168.102.0 192.168.201.2
91 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 • Damit keine Kommunikation zwischen den lokalen Zonen durch den shared TCP/IP-Stack stattfindet, müssen in der globalen Zone reject-routes gesetzt werden, die eine Kommunikation zwischen den IP-Adressen der beiden Zonen unterbinden (oder Nutzung von ipfilter). route add 192.168.201.1 192.168.202.1 -interface -reject route add 192.168.202.1 192.168.201.1 -interface -reject route add 192.168.200.1 192.168.202.1 -interface -reject route add 192.168.202.1 192.168.200.1 -interface -reject • Die Zonen können jetzt zum Betrieb gebootet werden: zoneadm -z zone1 boot, zoneadm -z zone2 boot • Die reject-Route führt zu einer vollständigen Unterbindung der Kommunikation zwischen zone1 und zone2, die aber nach obigen Vorgaben in diesem Szenario gefordert ist. Daher muss der konfigurierte Default Router NAT unterstützen. Er muss die Adresse 192.168.102.1 in die Adresse 192.168.202.1 umsetzen. Die Kommunikation über den NAT-Router umgeht so die reject-Routen. • Option: Wenn eine Kommunikation zwischen der globalen und der lokalen Zone möglich sein soll, ist in der globalen Zone ein Interface zu konfigurieren, das sich in dem logischen Netzwerk der lokalen Zone befindet. Der Ablauf ist folgendermaßen: • Eine HTTP-Anfrage wird von außen an die Zone zone1 gestellt. • Teile der Anfrage kann sie selbst bearbeiten, ein anderer Teil muss vom Applikationsserver kommen, der über die Adresse 192.168.102.1 adressiert wird. • Diese Adresse wird über den NAT Router geroutet, der die Adresse auf der anderen Seite in die Adresse 192.168.202.1 umsetzt. • Das ist die Adresse der Zone zone2 die den Applikationsserver trägt, der die fehlenden Teile der Anfrage bearbeitet und über die bestehende Verbindung zurück liefert.
NAT: 192.168.102.1 --> 192.168.202.1 192.168.201.2 192.168.202.2
NAT- Router 192.168.200.2 192.168.201.0 192.168.202.0 Netzwerk Netzwerk
bge1:1 - 192.168.201.1 Adressierung von Zone 2 bge3:1 - 192.168.200.1 bge2:2 - 192.168.202.1 als 192.168.102.1 Def-Router - 192.168.200.2 Zone 2 Zone 1 bge0 - 192.168.1.1 bge1 - 0.0.0.0 bge2 - 0.0.0.0 bge3 - 0.0.0.0 reject route 192.168.201.1 ↔ 192.168.202.1 reject route 192.168.200.1 ↔ 192.168.202.1 Globale Zone
192.168.1.0 Netzwerk Zeichnung 38: [dd] Verbindung von Zonen über externe Router unter Nutzung der shared IP-Instanz
92 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.2.7.9. Verbindung von Zonen über einen externen Load-Balancer unter Nutzung von exklusiven IP-Instanzen [dd/ug] Ein Webserver in der zone1 wird aus dem Internet kontaktiert und braucht zur Erfüllung der Aufträge den Applikationsserver in der zone2. – Die zone1 soll über ein separates Netzwerk mit dem Internet verbunden sein. – Die Verbindung von zone1 nach zone2 soll über einen externen Load-Balancer erfolgen. Wegen der Übersichtlichkeit sind hier keine weiteren Instanzen für Web- und Applikationsserver enthalten. – Eine Kommunikation direkt zwischen den lokalen Zonen soll nicht möglich sein, wohl aber über den externen Router. – Eine Kommunikation zwischen der globalen Zone und den lokalen Zonen ist nicht vorgesehen.
Realisierung: • Für jede Zone wird ein eigenes GLDV3-Interface (z.B. bge1, bge2) vorgesehen. bge3 wird zusätzlich der Zone1 zur direkten Kommunikation mit der Zone2 zugewiesen. Diese Interfaces dürfen in der globalen Zone nicht anderweitig benutzt werden. zone1-zonecfg: add net physical=bge1 zone1-zonecfg: add net physical=bge3 zone2-zonecfg: add net physical=bge2 • Die Zonenkonfiguration wird für zone1 und zone2 auf die Benutzung von exklusiven IP- Instanzen umgestellt. zonecfg: set ip-type=exclusive • In der Zone zone1 werden über die üblichen Wege die IP-Adressen und der Default Router festgelegt. Zone2 benötigt keine Defaultroute, da als einzige Kommunikation die mit zone1 vorgesehen ist. bge3 und bge2 werden über einen Load-Balancer verbunden und entsprechend konfiguriert. Zone 1: /etc/hostname.bge1 Zone 1: /etc/hostname.bge3 /etc/defaultrouter Zone 2: /etc/hostname.bge2 • Die Kommunikation zwischen zone1 und zone2 kann zur Erhöhung der Sicherheit zusätzlich noch über eine separate Firewall geführt werden. Durch die exklusiven IP-Instanzen findet eine Kommunikation zwischen den Zonen bzw. zwischen den Zonen und der globalen Zone nur statt, wenn entsprechende Routingeinträge in den Zonen existieren und eine physikalische Netzwerkverbindung zwischen den Interfaces der Zonen existiert.
Der Ablauf ist folgendermaßen: • Eine HTTP-Anfrage wird von außen an die Zone zone1 gestellt. • Teile der Anfrage kann sie selbst bearbeiten, ein anderer Teil muss vom Applikationsserver kommen, der über die Adresse 192.168.102.1 in zone2 erreichbar ist. • Diese Adresse wird über das Interface bge3 erreicht. • Eine weitere Kaskadierung über weitere Zonen zone2.1, zone2.2, zone2.3, ... ist denkbar.
93 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
Load- Balancer 192.168.200.2
bge2 - 192.168.201.2 bge4 - 192.168.201.3 bge3 - 192.168.201.1 Adressierung von Zone 2 ip-type: exclusive ip-type: exclusive bge1 - 192.168.200.1 als 192.168.102.1 Zone 2.1 Zone 2.2 Def-Router - 192.168.200.2 ip-type: exclusive Zone 1
bge0 - 192.168.1.1 ip-type: shared Globale Zone
192.168.1.0 Netzwerk Zeichnung 39: [dd] Verbindung von Zonen über externe Load-Balancer mit exclusiven IP-Instanzen
94 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 5.3. Lifecycle Management 5.3.1. Boot einer Zone [dd] zoneadm -z
[NOTICE: Zone booting up]
SunOS Release 5.10 Version Generic_118855-15 64-bit Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Hostname: zone1
zone1 console login:
Weiterhin wird das Verzeichnis
5.3.2. Bootargumente in Zonen [dd] Die Zonenkonfiguration kann ebenso wie das Kommando zoneadm -z
[NOTICE: Zone booting up]
SunOS Release 5.10 Version Generic_137138-09 64-bit Copyright 1983-2008 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. Booting to milestone "milestone/single-user:default". Hostname: keetonga Requesting System Maintenance Mode SINGLE USER MODE
Root password for system maintenance (control-d to bypass):
95 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 Alternativ, die Verwendung in der Zonenkonfiguration, um die Bootargumente dauerhaft umzustellen: global# zonecfg -z keetonga zonecfg:keetonga> info bootargs bootargs: zonecfg:keetonga> set bootargs="-m verbose" zonecfg:keetonga> info bootargs bootargs: -m verbose zonecfg:keetonga> commit zonecfg:keetonga> exit global# zoneadm -z keetonga halt bash-3.00# zlogin -C keetonga [Connected to zone 'keetonga' console]
[NOTICE: Zone booting up]
SunOS Release 5.10 Version Generic_137138-09 64-bit Copyright 1983-2008 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. [ system/filesystem/root:default starting (root file system mount) ] [ network/loopback:default starting (loopback network interface) ] [ network/pfil:default starting (packet filter) ] [ system/installupdates:default starting (system update installer) ] [ system/boot-archive:default starting (check boot archive content) ] [ milestone/name-services:default starting (name services milestone) ]
... gelöschte Ausgaben ...
[ network/inetd:default starting (inetd) ] [ system/system-log:default starting (system log) ] [ system/console-login:default starting (Console login) ]
keetonga console login:
5.3.3. Softwareinstallation per mount [ug] Um eine Applikation in der Zone laufen zu lassen, wird außer in trivialen Fällen (Apache,Perl, ...) noch zusätzlich installierte Software gebraucht. Diese Software liegt oft nicht im pkg-Format vor. Eine Methode, diese Software zu verteilen, ist in der globalen Zone ein gemeinsames Software- Repository zu pflegen und dieses ganz oder teilweise in den Zonen sichtbar zu machen: • Global gibt es das Verzeichnis /software • Die Software ist in dem Verzeichnis /software/produkt/version/ installiert, z.B.: • /software/oracle/9i_05/ • /software/oracle/9i_06/ • /software/oracle/10g_01/ • /software/siebel/3.14/ • /software/tomcat/3.7/ • Mit zonecfg: add fs werden die notwendigen Verzeichnisse in den jeweiligen Zonen readonly sichtbar gemacht (mit lofs).
Damit ist gewährleistet, dass auch die Nutzung von Software nachvollzogen werden kann, um gegebenenfalls die Lizenzkosten zu kontrollieren. Einfacher ist es, das gesamte Verzeichnis /software in jede Zone einzubringen. Zur Überwachung der Nutzung der Software müssen dann andere Mittel benutzt werden (audit und dtrace).
96 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.3.4. Software Installation mit Provisioning System [ug] Die N1 SPS Software kann Software auch in Zonen provisionieren. Die Voraussetzungen sind: • Ein schreibbares Verzeichnis, in dem die Software installiert werden kann. Dies kann /opt sein, das aber nicht als inherit-pkg-dir konfiguriert sein darf. • Wenn die Software unter /usr oder in einem anderen System-Verzeichnis installiert werden muss, kann das entweder mit einer whole-root Zone oder mit einem in dem /usr-Baum verfügbaren schreibbaren Verzeichnis (z.B. /usr/local) implementiert werden. (erzeugt durch zonecfg:add fs) • Die Software muss in der Zone lauffähig sein. 5.3.5. Migration einer Zone zwischen Systemen [dd] Zonen können ab Solaris 10 11/06 zwischen physikalischen Systemen bewegt werden. Dafür wird zoneadm detach/attach verwendet. Für die Migration von Zonen sind die folgenden Bedingungen zu beachten: • Zonen müssen vor der Migration angehalten werden • der Patch- und Package-Stand zwischen beiden Systemen muss gleich sein
Eine lokale Zone kann wie folgt zwischen Systemen migriert werden: • Detach der Zone mit zoneadm -z
Eine installierte lokale Zone wird vor der Migration auf einem System detached. Dieser Prozess erzeugt alle Informationen die benötigt werden, um diese Zone an einem anderen System zu attachen. Diese Informationen werden in der Datei
Vor einem Attach wird die Zonenkonfiguration aus der SUNWdetached.xml-Datei erzeugt. Durch das attach wird auf dem Zielsystem geprüft, ob die lokale Zone auf das Zielsystem passt. Dazu wird überprüft ob die installierten Packages und Patches in der migrierten Zone und der globalen Zone übereinstimmen.
97 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.3.6. Bewegen einer Zone in einem System [ug] Gegeben ist hier eine Zone namens test, die auf ein anderes Verzeichnis bewegt werden soll. Zur Zeit liegt die Zone test auf /export/home/zone/test (zonepath). global# zoneadm list -vc ID NAME STATUS PATH BRAND IP 0 global running / native shared 22 test running /export/home/zone/test native shared
Die Zone muss vor dem Bewegen gestoppt werden: global# zoneadm -z test halt
Danach kann in kurzer Zeit die Zone mit zoneadm ... move bewegt werden. Die Dauer hängt davon ab, ob das Zielverzeichnis im gleichen Filesystem liegt (Implementierung mit mv) oder in einem anderen Filesystem (zonepath muss kopiert werden) -abhängig vom Inhalt (sparse-root/whole-root- Zone; Dauer einige Minuten). global# zoneadm -z test move /container/test Moving across file-systems; copying zonepath /export/home/zone/test... Cleaning up zonepath /export/home/zone/test... global#
Dabei wird die Konfiguration der Zone ebenfalls angepasst: global# zonecfg -z test info zonename: test zonepath: /container/test brand: native autoboot: false bootargs: pool: limitpriv: scheduling-class: ip-type: shared inherit-pkg-dir: dir: /lib inherit-pkg-dir: dir: /platform inherit-pkg-dir: dir: /sbin inherit-pkg-dir: dir: /usr inherit-pkg-dir: dir: /opt
global# zoneadm list -vc ID NAME STATUS PATH BRAND IP 0 global running / native shared 23 test running /container/test native shared
In diesem Beispiel wurde die Zone von einem UFS auf ein ZFS Verzeichnis bewegt. global# df -k /export/home /container Filesystem kbytes used avail capacity Mounted on /dev/dsk/c1t1d0s6 5848297 2839898 2949917 50% /export/home container 1007616 90758 916031 10% /container
98 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.3.7. Duplizieren von Zonen mit zoneadm clone [ug] Das Installieren von Zonen kann mit zoneadm ... clone beschleunigt werden. In diesem Beispiel ist eine Zone namens test schon konfiguriert und installiert.
global# zoneadm list -vc ID NAME STATUS PATH BRAND IP 0 global running / native shared - test installed /container/test native shared
Diese Zone soll nun als Basis für eine weitere Zoneninstallation dienen. Die Konfiguration der Zone test ist wie folgt: global# zonecfg -z test info zonename: test zonepath: /container/test brand: native autoboot: false bootargs: pool: limitpriv: scheduling-class: ip-type: shared inherit-pkg-dir: dir: /lib inherit-pkg-dir: dir: /platform inherit-pkg-dir: dir: /sbin inherit-pkg-dir: dir: /usr inherit-pkg-dir: dir: /opt
Um die Konfiguration zu kopieren wird sie mit zonecfg ... export ausgelesen und die neue Zone wird daraus direkt erzeugt. Lediglich den zonepath muss man noch anpassen; das geht mit der einzeiligen Variante vom zonecfg . global# zonecfg -z test export | zonecfg -z test1 test1: No such zone configured Use 'create' to begin configuring a new zone.
global# zonecfg -z test1 set zonepath=/container/test1
99 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 Nun ist die Zone test1 genauso konfiguriert wie die Zone test, hat aber einen eigenen zonepath. global# zonecfg -z test1 info zonename: test1 zonepath: /container/test1 brand: native autoboot: false bootargs: pool: limitpriv: scheduling-class: ip-type: shared inherit-pkg-dir: dir: /lib inherit-pkg-dir: dir: /platform inherit-pkg-dir: dir: /sbin inherit-pkg-dir: dir: /usr inherit-pkg-dir: dir: /opt
global# zoneadm list -vc ID NAME STATUS PATH BRAND IP 0 global running / native shared - test installed /container/test native shared - test1 configured /container/test1 native shared
Nun kann man die bisher nur konfigurierte Zone test1 installieren, indem man die Zone test dupliziert. Direkt danach ist die Zone test1 nutzbar.
global# zoneadm -z test1 clone test Cloning zonepath /container/test... grep: can't open /a/etc/dumpadm.conf global#
global# zoneadm -z test1 boot root@se-ffm-03-um-test [283] # zoneadm list -vc ID NAME STATUS PATH BRAND IP 0 global running / native shared 25 test1 running /container/test1 native shared - test installed /container/test native shared
In diesem Beispiel ist bei der Zone test kein Netzwerk konfiguriert, was natürlich für den realen Einsatz unrealistisch ist. Ist ein Netzwerk konfiguriert, dann muss es natürlich nach der Konfiguration der Zone test1 umkonfiguriert werden, da sonst beide Zonen die gleiche Netzwerkadresse haben und nicht gleichzeitig laufen können.
100 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009
5.3.8. Duplizieren von Zonen mit zoneadm detach/attach und zfs clone [ug] Zunächst wird die Zone test in ein eigenes ZFS Filesystem bewegt. Das Filesystem darf nur von root aus benutzbar sein, sonst erfolgt eine Fehlermeldung. global# zfs create container/ztest global# ls -ld /container/ztest drwxr-xr-x 2 root root 2 Feb 19 16:00 /container/ztest global# chmod og-rwx /container/ztest global# ls -ld /container/ztest drwx------2 root root 2 Feb 19 16:00 /container/ztest
Nun wird die Zone in das separate ZFS Filesystem bewegt. Die Konfiguration wird automatisch angepasst, sie muss dazu natürlich heruntergefahren sein. global# zoneadm -z test move /container/ztest Moving across file-systems; copying zonepath /container/test... Cleaning up zonepath /container/test...
Die Zone wird detached und mit zfs snapshot wird der aktuelle Zustand des Filesystems als readonly Version festgehalten. Danach kann die ursprüngliche Zone wieder in Betrieb genommen werden. global# zoneadm -z test detach global# zfs snapshot container/ztest@gold global# zoneadm -z test attach global# zoneadm -z test boot
Eine Kopie der Zone wird erzeugt, indem man mit zfs clone eine schreibbare Version des Zonen- Filesystems erstellt. global# zfs clone container/ztest@gold container/ztest2 global# zfs list NAME USED AVAIL REFER MOUNTPOINT container 181M 803M 88.7M /container container/ztest 91.8M 803M 88.7M /container/ztest container/ztest@gold 3.07M - 90.4M - container/ztest2 0 803M 90.4M /container/ztest2
Um die Zonenkopie in Betrieb zu nehmen, muss man sie konfigurieren und den Zonenpfad anpassen. Danach reicht das zoneadm attach und die Zone ist startbar. global# zonecfg -z test export | zonecfg -z test2 test2: No such zone configured Use 'create' to begin configuring a new zone. global# zonecfg -z test2 set zonepath=/container/ztest2 global# zoneadm -z test2 attach global# zoneadm -z test2 boot
In der Zone ist natürlich der Name der OS-Instanz noch der gleiche, weil die Datei /etc/nodename noch nicht geändert wurde. Weiterhin ist es sinnvoll, dass wie die hier durchgeführte Anpassung des zonepath, auch eine Anpassung der Netzwerkadressen vorgenommen wird. Weitere Zonen mit dem gleichen OS Inhalt können nun sehr schnell erzeugt werden, in dem man die Schritte zfs clone / zonecfg / zoneadm attach wiederholt. Genauso lassen sich Zonen mit zoneadm detach / attach auch auf andere Systeme bewegen. Die Voraussetzung ist, dass der gleiche Paket- und Patchstand auf dem Zielsystem vorliegt. Mit der Variante zoneadm attach -u lässt sich eine Zone auf ein System mit neuerem Stand bewegen, allerdings darf kein downgrade der Patches vorkommen. Seit Solaris 10 5/09 wird bei dem Kommando zoneadm -z zone clone automatisch das zfs clone benutzt, wenn die Zone auf einem ZFS Filesystem liegt. Damit wird das schnelle Erzeugen von Zonen noch einfacher.
101 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 5.3.9. Bewegen einer Zone zwischen einem sun4u und einem sun4v System [ug] Zur Zeit sind von Sun Microsystems zwei Architekturen mit SPARC-Prozessoren erhältlich, die beide von Solaris 10 unterstützt werden. Die sun4u-Architektur in den größeren Datacenter Rechnern mit einer höheren Einzelprozessor-Leistung und die sun4v-Architektur in den CMT-Rechnern (Chip Multi Threading) mit vielen Cores und Threads sowie Virtualisierungsunterstützung. Die Rechnerarchitekturen sind an der HW/SW-Schnittstelle leicht unterschiedlich, was sich in einer Solaris 10 Installation durch unterschiedliche Inhalte im Filesystem niederschlägt. In Rechenzentren kann es vorkommen, dass Zonen zwischen den verschiedenen Architekturen bewegt werden müssen. Zunächst wird eine Zone als Template auf dem sun4u-System tiger erzeugt, die Konfiguration sieht so aus: root@tiger [6] # zonecfg -z template-u info zonename: template-u zonepath: /zone/template-u brand: native autoboot: false bootargs: pool: limitpriv: scheduling-class: ip-type: shared inherit-pkg-dir: dir: /lib inherit-pkg-dir: dir: /platform inherit-pkg-dir: dir: /sbin inherit-pkg-dir: dir: /usr inherit-pkg-dir: dir: /opt
Die Installation: root@tiger [8] # zoneadm -z template-u install Preparing to install zone
Nun wird die Konfiguration als Datei für die Wiederbenutzung abgelegt (unter /zone): root@tiger [18] # zonecfg -z template-u export >template-u.export
Eine neue Zone gleicher Konfiguration lässt sich auf dem sun4u System tiger so erzeugen: root@tiger [19] # zonecfg -z u0 root@tiger [20] # zonecfg -z u0 set zonepath=/zone/u0 root@tiger [21] # zoneadm -z u0 clone template-u Cloning zonepath /zone/template-u... 102 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 Die Zone soll nun auf ein sun4v namens bashful System transportiert werden. Dazu wird der Inhalt und die Konfiguration gesichert: root@tiger [23] # cd /zone root@tiger [23] # tar cEvf u0.tar u0 # zone sichern root@tiger [24] # zonecfg -z u0 export >u0.export # Konfiguration Die Erzeugung der Zone erfolgt mittels der gesicherten Konfiguration: root@bashful [40] # zonecfg -z u0v Der Baum der Zone wird vom tar-Archiv installiert: root@bashful [41] # cd /zone root@bashful [42] # tar xEf /net/tiger/zone/u0.tar Und im letzten Schritt erfolgt die Anpassung an die HW-Architektur: root@bashful [43] # zoneadm -z u0v attach -u /zone/u0 zoneadm: zone 'u0v': The zone was not properly detached. Attempting to attach anyway. WARNING: package operation in progress on the following packages: SUNWcsr SUNWcslr SUNWmlibk SUNWmlibl TSBWvplr FJSVs8brandr FJSVhea SUNWxwplt SUNWxorg-cfg SUNWxwinc SUNWxorg-xkb SUNWxorg-server SUNWxorg-client-docs SUNWxorg-doc SUNWxorg-devel-docs SUNWxwpmn SUNWapchu SUNWapchd SUNWtcatu SUNWapch2u SUNWapch2d SUNWcsl SUNWcsu SUNWdtrc SUNWPython SUNWwbdev SUNWdtcor SUNWdtbas SUNWnamdt SUNWupdatemgru SUNWdtdte SUNWdttsu SUNWodtts SUNWdtdst SUNWdtma SUNWhea SUNWcry SUNWfirefox-devel SUNWfmd SUNWgnome-panel-devel SUNWiiimu SUNWlxsl SUNWlxml SUNWprd SUNWj5rt SUNWj5rt:none SUNWj5rtx SUNWj5dmo SUNWj5dmx SUNWj5dev SUNWj5man SUNWbzip SUNWesu SUNWmdu SUNWfirefox SUNWnfssu SUNWzfsu SUNWkrbu SUNWgnome-libs SUNWipfu SUNWkdcu SUNWnisu SUNWdpl SUNWpsu SUNWmdb SUNWpr SUNWpprou SUNWppro- plugin-sunos-base SUNWpcu SUNWsmcmd SUNWlvma SUNWsshcu SUNWmcos SUNWgnome-desktop-prefs SUNWxwice SUNWxwfnt SUNWxwopt SUNWxwacx SUNWxim SUNWxi18n FJSVxwpsr SUNWplow SUNWtltkm TSBWvplu SUNWppm SUNWdclnt SUNWwbmc SUNWlvmg SUNWwbapi SUNWwbcou SUNWmgapp SUNWtlsu SUNWsfwhea SUNWopenssl-include SUNWimagick SUNWsmbau SUNWgnome-img- editor SUNWgcmn SUNWxwrtl SUNWPython-share SUNWsfman SUNWgnome-panel- share SUNWgnome-desktop-prefs-share SUNWbind SUNWgnome-themes-share SUNWgnome-img-viewer-share SUNWgnome-display-mgr-share SUNWgnome-img- editor-share SUNWgnome-libs-share SUNWjss SUNWgnome-file-mgr-share SUNWgnome-session-share SUNWxvnc SUNWmctag SUNWmcon SUNWucbt SUNWxcu6 Getting the list of files to remove Removing 5 files Remove 53 of 53 packages Installing 12 files Add 21 of 21 packages Updating editable files The file within the zone contains a log of the zone update. Die Anpassung wird durch die letzten Zeilen angezeigt. Bei diesem Test waren ursprünglich noch zwei Pakete mehr auf dem Rechner tiger installiert, die erst entfernt werden mussten (Kommando pkgrm), damit das zoneadm attach -u funktioniert hat. Wichtig ist hier also möglichst die Gleichheit von Paket- und Patchstand, bzw. das das Zielsystem einen Upgrade darstellt und kein Downgrade in irgendeinem Paket. 103 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 5.3.10. Herunterfahren einer Zone [dd] Zonen können aus der lokalen Zone selbst oder aus der globalen Zone heraus heruntergefahren werden. Je nachdem welche Variante benutzt wird, werden dabei laufende Services noch beendet oder einfach gestoppt. • zoneadm -z zone halt wird in der globalen Zone aufgerufen, hält eine Zone an und stoppt alle Prozesse der Zone sofort. • zlogin Shared Filesysteme und swap werden nicht automatisch kopiert. Falls notwendig, kann die Kopie per Parameter von lucreate konfiguriert werden. Weiterhin wird hier für das aktuelle BE der Name s10-807 und für das zu erzeugende BE der Name s10-807+1 vergeben. Durch lucreate wird der Inhalt von /non-shared/zone1 nach /non-shared/zone1 von BE s10-807+1 kopiert. Da sich zone2 in einem shared Filesystem befindet, wird die Zone innerhalb dieses Filesystems nach /shared/zone2- s10-807+1 kopiert. So wird sichergestellt, das jedes BE den richtigen zonepath aus dem shared Filesystem benutzt. Deshalb muss sichergestellt werden, dass genügend Platz in dem shared Filesystem vorhanden ist. Nun kann das inaktive BE s10-807+1 inklusive seiner Zonen gepatched werden, während die Produktion auf dem aktiven BE weiter läuft. Die Patches werden wie folgt eingespielt: luupgrade -t -n s10-807+1 -s Bemerkung: Wer anstelle des Patchens ein Live Upgrade des BE auf ein neueres Solaris durchführen will, wird hierfür das folgende Kommando benutzen: luupgrade -u -n s10-807+1 -s Für x86/x64-Systeme ist ein weiterer Schritt zur Aktualisierung des Boot-Archivs notwendig, da mit dem Einspielen der Patches auch Treiber oder Systemdateien modifiziert worden sein könnten. Dazu wird zunächst das neue BE gemountet. lumount s10-807+1 104 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 Das BE ist nun z.B. unter /.alt.s10-807+1 verfügbar. Anschließend wird das Boot-Archive dieses BE aktualisiert und das BE wieder unmountet. bootadm update-archive -R /.alt.s10-807+1 luumount s10-807+1 Abschließend kann nun das neue BE aktiviert werden. Danach muss das Gesamtsystem neu gestartet werden. Dabei ist es wichtig, das Live Upgrade beim Abschalten des aktuellen BE noch eine letzte Synchronisation durchführen kann, daher muss unbedingt das Kommando init 6 verwendet werden (keinesfalls Reboot). luactivate s10-807+1 init 6 Wenn das neue BE das erste Mal startet, werden die globale Zone, sowie die „alten“ und die „neuen“ Zonen lt. /etc/lu/synclist synchronisiert. Dazu muss Live Upgrade beim ersten Start des neuen BE Zugriff auf die „alten“ und die „neuen“ Zonen haben, d.h. es muss sichergestellt werden, das auch die shared Filesysteme in dem neuen BE automatisch beim Booten gemountet werden. Dieses ist für die ordnungsgemäße Beendigung von Live Upgrade erforderlich. Nun ist das Patchen der Zonen durch Live Upgrade abgeschlossen und alle Zonen können in Betrieb genommen werden. 105 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 5.4. Management und Monitoring 5.4.1. DTrace in einer lokalen Zone [dd] Seit Solaris 10 11/06 ist die Benutzung von DTrace innerhalb von lokalen Zonen auf Prozesse der Zone möglich. Dazu ist die Erweiterung des Privilegiensets der lokalen Zone um die Privilegien dtrace_proc und dtrace_user notwendig. Ohne diese Privilegien sind keine DTrace Probes in der Zone verfügbar. DTrace Probes sind nicht in der Zone verfügbar. zone1# dtrace -l | tail +2 zone1# DTrace Privilegien der Zonenkonfiguration hinzufügen. global# zonecfg -z zone1 zonecfg:zone1> set limitpriv=default,dtrace_proc,dtrace_user zonecfg:zone1> commit zonecfg:zone1> exit Beispielsweise kann der pid-Provider benutzt werden, um einen Prozess in der eigenen Zone zu tracen. dtrace -n 'pid Je nachdem ob die Kontrolle über die Audit-Konfiguration und der vollständige Zugriff auf die Audit- Daten erforderlich ist, wird die Entscheidung für eine der beiden Konfigurationsmöglichkeiten ausfallen. 106 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 5.5. Ressource Management 5.5.1. Begrenzung von /tmp-Größe in einer Zone [dd] /tmp wird in vielen Fällen als tmpfs in swap benutzt. Das führt dazu, dass der swap-Bereich durch /tmp in jeder Zone von allen Zonen shared benutzt wird. Die /tmp-Bereiche sind zwar nur für jede Zone selbst sichtbar, aber es werden globale Ressourcen benutzt. Zur Begrenzung des Platz- Verbrauches sollte /tmp in der /etc/vfstab der Zonen mit der size-Option gemountet werden. swap - /tmp tmpfs - yes size=250m Diese Begrenzung kann durch den root-Administrator der Zone verändert werden. Jedoch wird dieser Bereich dem virtuellen Speicher der Zone angerechnet und ist daher auch durch die Einstellung des mit zonecfg:add capped-memory: set swap= limitiert. 5.5.2. Limitieren des CPU Verbrauchs einer Zone (CPU-Capping) [dd] Seit Solaris 10 5/08 ist das Kappen von CPU-Zeit für eine Zone möglich. Als Kappungswerte können CPU-Anteile angegeben werden. So steht z.B. der Wert 1.5 für eine ganze CPU und eine halbe. Bei der Syntax ist zu beachten, dass je nach locale-Einstellung der Session des Administrators hier set ncpus=1.5 (locale=C) oder set ncpus=1,5 angegeben werden muss. Die Einstellung ist auf 1/100 CPUs genau. zonecfg:keetonga> add capped-cpu zonecfg:keetonga:capped-cpu> set ncpus=1.5 zonecfg:keetonga:capped-cpu> end zonecfg:keetonga> info capped-cpu: [ncpus: 1.50] rctl: name: zone.cpu-cap value: (priv=privileged,limit=150,action=deny) Diese Einstellung ist ein hartes Limit, das heisst die eingestellte CPU-Leistung kann nicht überschritten werden. 5.5.3. Ressource Pools mit Prozessor Sets [ug] In Solaris (ab Solaris 9) lassen sich die CPUs auf Ressource Pools aufteilen. Solaris Zonen kann man diesen Ressource-Pools zuordnen und damit lässt sich auf einfache Weise eine Entkopplung der CPU-Ressourcen durchführen: • Mit den Kommandos poolcfg und pooladm wird das Ressource-Management eingeschaltet und der zusätzliche Ressource-Pool erzeugt. • Mit dem Kommando poolcfg wird das Prozessor-Set (pset) erzeugt und dem Ressource- Pool zugeordnet. • Mit dem Kommando zonecfg kann man das Attribut pool der Zone ändern und dort den neuen Ressource-Pool eintragen. Dies ist dann die Einstellung, die nach Reboot des Systems ohne weitere Maßnahmen gilt. • Mit dem Kommando poolbind kann die Zuordnung der Zonen zu Ressource-Pools dynamisch verändert werden. Dies hat aber keine Auswirkung auf die mit zonecfg vorgenommene Default-Einstellung. Die Prozesse einer Zone, die einem Ressource Pool zugeordnet sind, laufen dann nur auf den Prozessoren ab, die zum Prozessorset des Ressource-Pools gehören. Sind mehrere Zonen einem Ressource-Pool zugeordnet, kann das Verhältnis der verbrauchten CPU- Zeit mit dem Fair-Share Scheduler eingestellt werden. Diese Einstellung ist ein hartes Limit und kann nicht überschritten werden. 107 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 5.5.4. Fair Share Scheduler [ug] Das Verhältnis des CPU-Verbrauchs zwischen Zonen oder Projekten lässt sich einstellen. Dazu wird der sogenannte Fair Share Scheduler benutzt. Dabei werden CPU-Shares zugeteilt: • Für Zonen geht das mit add rctl und dem Attribut zone.cpu-shares im zonecfg- Kommando. • Bei Projekten wird dies in der project-Database (/etc/project, oder NIS oder LDAP) und dem Attribute project.cpu-shares eingestellt (globale und/oder lokale Zone). • Die Zonen/Projekte müssen dem gleichen Ressource-Pool zugeordnet werden. • In dem Ressource-Pool muss der Fair Share Scheduler eingeschaltet werden. • In der globalen Zone kann man den Ressource-Pool auch auf eine Untermenge der Prozessoren im System limitieren. Das Betriebssystem sorgt dann für Fairness, wenn die CPUs des Ressource Pool ausgelastet werden. Dazu werden die zugeteilten Shares der Projekte und Zonen mit aktiven Prozessen dazu benutzt, den Sollwert für den CPU-Verbrauch zu berechnen. Der Sollwert des CPU-Verbrauchs ermittelt sich aus: (shares der Zone) * (Anzahl der CPUs) / (Summe der shares der aktiven Zonen) Wenn der CPU-Verbrauch gegen 100% geht und der Anteil der verbrauchten CPU-Zeit größer ist als der Sollwert, dann steuert der Fair Share Scheduler durch Verringerung der Priorität dagegen. Weiterhin: • Im laufenden Betrieb (dynamisch) können die Einstellungen für die CPU-Shares mit dem Kommando prctl umgestellt werden. • Die Zugehörigkeit zu Ressource-Pools kann mit dem Kommando poolbind jederzeit umgestellt werden. Ist der CPU-Verbrauch merklich kleiner als 100%, kontrolliert der Fair Share Scheduler den CPU- Verbrauch nicht. Das heißt, eine Zone in dem Ressource-Pool kann mehr verbrauchen, als ihr eigentlich zusteht. Ist das nicht gewünscht, dann ist eine zusätzliche Limitierung mit Prozessor Sets oder cpu-capping empfehlenswert. 5.5.5. Statisches CPU Ressource Management zwischen Zonen [ug] Statisches Ressource-Management zwischen Zonen bestimmt, wie im Normalfall nach einem Bootvorgang die Ressourcen zwischen Zonen verteilt werden sollen: • Zum Erstellen eines Ressourcenpools werden die Kommandos poolcfg und pooladm benutzt. • Die Zugehörigkeit einer Zone zu einem Ressourcenpool kann bei zonecfg mit dem Attribut pool eingestellt werden. • Die Einstellungen für Fairness zwischen den Zonen werden mit add rctl im zonecfg eingestellt. Empfohlen wird die Einstellung von zone.cpu-shares (Anteil CPU) und zone.max-lwps (maximale Anzahl Threads). 5.5.6. Dynamisches CPU Ressource Management zwischen Zonen [ug] Hiermit sind die Kommandos gemeint, mit denen man im laufenden Betrieb die Ressource- Kontrolle umstellen kann, um auf eine temporäre Lastsituation zu reagieren. Dazu werden die Kommandos prctl und poolbind verwendet. Gegebenenfalls können mit poolcfg und pooladm neue Ressourcenpools temporär erstellt werden. 5.5.7. Statisches CPU Ressource Management in einer Zone [ug] Das Verhältnis des CPU-Verbrauchs von Applikationen in einer Zone lässt sich ebenfalls einstellen. Dazu werden innerhalb der Zone Ressourcenpools definiert und der Fair Share Scheduler eingesetzt. Eine Zuordnung von CPUs zu den Ressource-Pools ist in der Zone nicht möglich. • Die Zuordnung von Applikationen zu Projekten erfolgt mit Konfiguration in den Dateien /etc/ project und der /etc/user_attr . • In der /etc/project ist definierbar, in welchem Ressource-Pools ein Projekt laufen soll. • Zum Erstellen eines Ressource-Pools in der Zone werden die Kommandos poolcfg und pooladm benutzt, Prozessoren können allerdings nicht zugewiesen werden. • In dem Ressource Pool muss der Fair Share Scheduler (FSS) eingeschaltet werden. 108 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 5.5.8. Dynamisches CPU Ressource Management in einer Zone [ug] Hiermit sind die Kommandos gemeint, mit denen man im laufenden Betrieb in der Zone die Ressource-Kontrolle umstellen kann, um auf eine temporäre Lastsituation zu reagieren. Dazu werden die Kommandos prctl und poolbind verwendet. Gegebenenfalls können mit poolcfg und pooladm neue Ressourcenpools temporär erstellt werden. 5.5.9. Dynamische Ressource Pools für Zonen [dd] Wie in 4.6.2.5 Dynamische Ressource Pools bereits beschrieben, lassen sich seit Solaris 10 8/07 Dynamische Ressource Pools sehr einfach für Zonen verwenden. Dabei wird in der Zonenkonfiguration die Menge der benötigten CPUs festgelegt. Wird die entsprechende Zone gestartet, wird aus den angeforderten und verfügbaren CPU ein temporärer Ressource Pool erzeugt und dieser der gestarteten Zone zugeordnet. Dieser Ressource Pool besteht für die Laufzeit der Zone und wird nach Abschaltung der Zone ebenfalls vernichtet. Die Angabe der CPU kann durch eine feste Anzahl von CPU (z.B. set ncpu=10) erfolgen. In diesem Fall muss der Zone diese Anzahl zum Start zur Verfügung gestellt werden und bleibt ihr auch für die Laufzeit zugeordnet. Wird ein CPU-Bereich (z.B. set ncpus=10-14) angegeben, muss die Mindestanzahl der CPU beim Start der Zone verfügbar sein. Während der Laufzeit der Zone weist der poold der Zone CPUs dynamisch je nach Anforderung durch die Zone und die Verfügbarkeit von CPU im System zu. (Damit der poold läuft, muss der Service /system/pool/dynamic aktiviert sein.) Wenn mehrere Ressource Pools um verfügbare CPU konkurrieren, wird anhand der Importance entschieden, welcher Ressource Pool bevorzugt bedient wird. global # svcs dynamic STATE STIME FMRI online Jan_19 svc:/system/pools/dynamic:default global # zonecfg -z zone1 zonecfg:zone1> add dedicated-cpu zonecfg:zone1:dedicated-cpu> help zonecfg:zone1:dedicated-cpu> set ncpus=10-14 zonecfg:zone1:dedicated-cpu> set importance=30 zonecfg:zone1:dedicated-cpu> end zonecfg:zone1> commit zonecfg:zone1> exit Nach dem Starten der Zone kann mit poolstat der Status der verfügbaren Ressource Pools angezeigt werden. global # poolstat 5 pset id pool size used load 0 pool_default 32 0.02 0.04 < Wenn während der Laufzeit einer Zone ohne automatischen Einfluss des poold einer Zone weitere CPUs zugewiesen werden sollen, muss dies mit dem Kommando poolcfg erfolgen. Die Veränderung der CPU-Anzahl muss aber innerhalb des festgelegten CPU-Bereiches bleiben. • Erhöhung der Anzahl von CPU in einem Ressource Pool poolcfg -dc 'transfer 3 from pset pset_default to SUNWtmp_zone1' • Reduzierung der Anzahl von CPU in einem Ressource Pool poolcfg -dc 'transfer 2 from pset SUNWtmp_zone1 to pset_default' 109 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 Die Einstellung des Ressource Pools mit zonecfg ist statisch und wird nur beim Starten der Zone, also bei der Erzeugung des Ressource Pools ausgewertet. Eine Veränderung des CPU-Bereiches zur Laufzeit der Zone kann mit poolcfg erfolgen. poolcfg -dc 'modify pset SUNWtmp_zone1 (uint pset.min=15;uint pset.max=20)' 5.5.10. Physikalischen Hauptspeicherverbrauch eines Projektes begrenzen [dd] Zur Begrenzung des physikalischen Hauptspeicherverbrauches eines Projekte kann der Ressource Capping Daemon rcapd(1M) verwendet werden. Wenn die resident set size (RSS) eines Projektes die Capping-Vorgabe (rcap.max-rss in Bytes) überschreitet, reduziert der rcapd die RSS und lagert benutzte Speicherseiten auf das Paging-Device aus. rcapd wird durch rcapadm(1M) konfiguriert und mit rcapstat(1) überwacht. Der rcapd kann in Zonen im Zusammenhang mit Projekten eingesetzt werden und den physikalischen Hauptspeicherverbrauch eines Projektes innerhalb einer Zone begrenzen. Es ist auf jeden Fall zu empfehlen, zunächst den virtuellen Speicher (swap) zu limitieren und dann den phys. Speicher zu begrenzen, da dieses Limit ein hartes Limit ist und bei einer Fehlkonfiguration (20 GB Cache für die Datenbank statt 2 GB) schneller bemerkt wird. Eine alleinige Limitierung des physikalischen Speicherverbrauchs würde sich in einem solchen Fall extrem auf die Performance dieser Zone auswirken und eventuell auch andere Zonen beeinträchtigen. 5.5.11. Anwendung von Memory Ressource Management für Zonen [dd] Nach 4.6.3 Limitierung der Memory Ressourcen kann seit Solaris 10 8/07 der virtuelle, physikalische und locked Hauptspeicher einer Zone begrenzt werden. Die Konfiguration dazu erfolgt in der Zonenkonfiguration. global # zonecfg -z zone1 zonecfg:zone1> add capped-memory zonecfg:zone1:capped-memory> set physical=50m zonecfg:zone1:capped-memory> set swap=200m zonecfg:zone1:capped-memory> set locked=20m zonecfg:zone1:capped-memory> end zonecfg:zone1> commit zonecfg:zone1> exit Die Konfiguration von capping-Parametern für eine Zone und der Neustart einer Zone führt zum automatischen Start des rcapd - Daemon in der globalen Zone, der das Ressource Management vornimmt. Die Arbeit des rcapd kann mit rcapstat -z beobachtet werden. global # rcapstat -z id zone nproc vm rss cap at avgat pg avgpg 21 zone1 29 42M 57M 50M 12M 0K 8584K 0K 21 zone1 29 42M 57M 50M 6752K 0K 6712K 0K 21 zone1 - 26M 29M 50M 0K 0K 0K 0K 21 zone1 - 26M 29M 50M 0K 0K 0K 0K id zone nproc vm rss cap at avgat pg avgpg 21 zone1 - 18M 22M 50M 0K 0K 0K 0K 21 zone1 - 17M 18M 50M 0K 0K 0K 0K id zone nproc vm rss cap at avgat pg avgpg 22 zone1 29 42M 57M 50M 12M 0K 8672K 0K 22 zone1 29 42M 57M 50M 10M 0K 7776K 0K 22 zone1 - 42M 43M 50M 0K 0K 0K 0K Die Einstellungen des Memory Capping mit zonecfg sind statisch. Sind Veränderungen der Einstellungen zur Laufzeit der Zone notwendig, so ist dies mit dem Kommando rcapadm durchzuführen. rcapadm -z zone1 -m 40m 110 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 Einstellungen für swap (= virtueller Speicher), locked-memory und andere Ressource Controls einer Zone können zur Laufzeit mit prctl -i zone Die Veränderung dieser Einstellungen zur Laufzeit erfolgt mit dem Kommando prctl. global # prctl -r -t privileged -n zone.max-swap -v 180m -e deny -i zone zone1 global # prctl -n zone.max-swap -i zone zone1 zone: 22: zone1 NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT zone.max-swap privileged 180MB - deny - system 16.0EB max deny - 111 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 Anhang A. Solaris Container in OpenSolaris A.1. OpenSolaris allgemein [dd] In 2005 wurde von Sun Microsystems OpenSolaris als OpenSource Projekt gestartet, um die Entwicklergemeinschaft rund um Solaris zu fördern und weiterzuentwickeln (http://www.opensolaris.org/os/) . Im Mai 2008 wurde das erste OpenSolaris Betriebssystem fertig gestellt (http://www.opensolaris.com/). Die erste Distribution OpenSolaris 2008.05 richtete sich vor allem im x86-Markt an einzelne Desktop- und Server-Benutzer, Web 2.0-Entwickler und HPC-Kunden. Mit den Versionen OpenSolaris 2008.11 und OpenSolaris 2009.06 sind weitere Distributionen erschienen, die sich an der Weiterentwicklung des Solaris Kernels und der vielfältigen Solaris Technologien orientieren. OpenSolaris 2009.06 steht seit Juni 2009 nicht nur für x86-Systeme, sondern auch für SPARC- Systeme zur Verfügung (http://www.opensolaris.com/learn/features/whats-new/200906/). Das OpenSolaris Betriebssystem zeichnet sich neben der Integration einer Vielzahl von OpenSolaris Projekten durch viele konzeptionelle Neuerungen gegenüber der Solaris 10 Distribution aus. Dazu zählen u.a.: • Distribution auf einer Live CD • Sehr einfache grafische Installation • Einführung eines Internet basierten Package Management Systems (Image Packaging System - IPS) (http://www.opensolaris.org/os/project/pkg/) • Neuer Packagemanager zur Installation von IPS-Packages • Neuer Updatemechanismus zum einfachen Upgrade des Betriebssystems • Automatisierte Installation durch die Nutzung des Automatic Installer (AI) (http://www.opensolaris.org/os/project/caiman/auto_install/) A.2. ipkg-Branded Zones Das neue Packaging System führte zur Einführung eines neuen Zone Brands, der IPS-basierte Zonen enthält. Von der Funktionalität und der Benutzung sind OpenSolaris Zonen, zu den Solaris 10 Zonen vergleichbar. Auch die Ressourcemanager-Funktionalitäten von OpenSolaris sind zu denen von Solaris 10 zumindest identisch und teilweise gegenüber diesen erweitert. Folgende Unterschiede bestehen zwischen dem ipkg-Brand und dem native-Brand: • ipkg-Zonen sind sehr klein (ca. 200 MB) und enthalten in ihrer Grundinstallation nur die notwendigsten Packages. Dadurch ist die Installation einer Zone sehr schnell. Weitere Packages können einfach hinzugefügt werden. • ipkg-Zonen sind zur Zeit immer whole-root Zonen. Das zonecfg-Feature inherit-pkg-dir ist auf SVR4-Packages ausgerichtet und kann auf IPS-Packages nicht angewendet werden. Die Möglichkeiten von sparse-root Zonen mit OpenSolaris werden zur Zeit (Juni 2009) diskutiert. • Zur Installation einer Zone, benötigt das System Zugang zum einem Internet-basierten Package Repository, das normalerweise durch die globale Zone vorgegeben wird. Während der Installation kann aber auch ein alternatives Repository angegeben werden (z.B. zoneadm -z keetonga install -a ipkg=http://pkg.opensolaris.com:80) das die Packages enthält aus denen die Zone erzeugt werden soll. Da zur Kommunikation das http- Protokoll verwendet wird, ist keine direkte Verbindung zum Internet notwendig. Es genügt eine Verbindung über einen http-Proxy. • ipkg-Zonen sind von dem Packaging-System der globalen Zone unabhängig Diese Unterschiede stellen den aktuellen Stand (Juni 2009) dar. Die Funktionalitäten von OpenSolaris befinden sich weiterhin in einem sehr dynamischen Entwicklungsprozess. Der Umfang dieser Aufzählung wird sich mit fortschreitender Entwicklung noch verändern. 112 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 A.3. Kochbuch: Konfiguration einer ipkg-Zone Die Konfiguration der Zone erfolgt wie gewohnt mit zonecfg(1M). root@cantaloup:~# zonecfg -z keetonga keetonga: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:keetonga> create zonecfg:keetonga> set zonepath=/zones/keetonga zonecfg:keetonga> add net zonecfg:keetonga:net> set physical=e1000g0 zonecfg:keetonga:net> set address=192.168.1.21/24 zonecfg:keetonga:net> end zonecfg:keetonga> info zonename: keetonga zonepath: /zones/keetonga brand: ipkg autoboot: false bootargs: pool: limitpriv: scheduling-class: ip-type: shared hostid: net: address: 192.168.1.21/24 physical: e1000g0 defrouter not specified zonecfg:keetonga> verify zonecfg:keetonga> commit zonecfg:keetonga> exit zoneadm list zeigt den ipkg-Brand an. root@cantaloup:~# zoneadm list -cv ID NAME STATUS PATH BRAND IP 0 global running / native shared - keetonga configured /zones/keetonga ipkg shared A.4. Kochbuch: Installation einer ipkg-Zone root@cantaloup:~# zoneadm -z keetonga install A ZFS file system has been created for this zone. Publisher: Using opensolaris.org (http://pkg.opensolaris.org/release/). Image: Preparing at /zones/keetonga/root. Cache: Using /var/pkg/download. Sanity Check: Looking for 'entire' incorporation. Installing: Core System (output follows) DOWNLOAD PKGS FILES XFER (MB) Completed 20/20 3021/3021 42.55/42.55 PHASE ACTIONS Install Phase 5747/5747 Installing: Additional Packages (output follows) DOWNLOAD PKGS FILES XFER (MB) Completed 37/37 5598/5598 32.52/32.52 PHASE ACTIONS Install Phase 7332/7332 Note: Man pages can be obtained by installing SUNWman Postinstall: Copying SMF seed repository ... done. Postinstall: Applying workarounds. Done: Installation completed in 648,952 seconds. Next Steps: Boot the zone, then log into the zone console (zlogin -C) to complete the configuration process root@cantaloup:~# 113 Version 3.1-de Solaris 10 Container Leitfaden - 3.1 5. Kochbücher Stand: 30.11.2009 B. Literatur [1] Jeff Victor,"Solaris Containers Technology Architecture Guide", Sun Blueprint, Mai 2006, http://www.sun.com/blueprints/0506/819-6186.html [2] Jeff Victor, "Zones and Containers FAQ", OpenSolaris FAQ, http://opensolaris.org/os/community/zones/faq/ [3] Sun Microsystems Inc., "Solaris Containers Learning Center", http://www.sun.com/software/solaris/containers_learning_center.jsp [4] Joost Pronk van Hoogeveen,"Working with Solaris Containers and the Solaris Service Manager", Sun Blueprint, Mai 2006, http://www.sun.com/blueprints/0506/819-4328.html [5] Menno Lageman, "Solaris Containers --What They Are and How to Use Them", Sun Blueprint,Mai 2005, http://www.sun.com/blueprints/0505/819-2679.pdf [6] Sun Microsystems Inc., "System Administration Guide: Solaris Containers-Resource Management and Solaris Zones", Solaris 10 Manual, 2006, http://docs.sun.com/app/docs/doc/817-1592 [7] OpenSolaris Project: „Crossbow: Network Virtualization and Resource Control“ http://opensolaris.org/os/project/crossbow/ [8] Websphere Application Server im Container http://www.sun.com/software/whitepapers/solaris10/websphere6_sol10.pdf und http://blogs.sun.com/roller/page/sunabl?entry=websphere_deployment_on_solaris_10 [9] Statement von IBM, dass Websphere MQ nur in globalen Zonen und whole root lokalen Zonen unterstützt wird http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg21233258 [10] Solaris Containern bei der Apache Software Foundation http://www.tbray.org/ongoing/When/200x/2006/03/06/Apache-Server [11] Oracle im Container http://www.sun.com/blueprints/0505/819-2679.pdf pp. 22-33 und Oracle Metalink https://metalink.oracle.com (Note: 317257.1) [12] Sun Cluster Data Service for Solaris Containers Guide http://docs.sun.com/app/docs/doc/819-2664 [13] Webserver/ftpd und Backup/Restore in einer Zone http://www.sun.com/blueprints/0506/819-6186.pdf pg. 8 und pp. 10-13 [14] Qualification Best Practices for Application Support in Non-Global Zones http://developers.sun.com/solaris/articles/zone_app_qualif.html [15] "Bringing Your Application Into the Zone". http://developers.sun.com/solaris/articles/application_in_zone.html [16] Sreekanth Setty, "Deploying Sun Java Enterprise System on the Sun Fire T2000 Server using Solaris Containers“, Sun Blueprint, August 2006, http://www.sun.com/blueprints/0806/819-7663.pdf [17] http://en.wikipedia.org/wiki/Virtualization [18] Zonenspezifische Einstellungen in späteren Solaris Updates: http://www.opensolaris.org/os/community/arc/caselog/2006/496/spec-txt [19] Grafische Überwachung des Zonen-Auslastung http://www.asyd.net/home/projects/zonestats [20] Jeff Savit,"Energy Efficiency Strategies: Sun Server Virtualization Technology", Sun Blueprint, August 2007, http://www.sun.com/blueprints/0807/820-3023.html [21] Harry J. Foxwell, Menno Lageman, Joost Pronk van Hoogeveen, Isaac Rozenfeld, Sreekanth Setty and Jeff Victor, „The Sun BluePrints Guide to Solaris Containers: Virtualization in the Solaris Operating System“, Sun Blueprint, October 2006, http://www.sun.com/blueprints/1006/820-0001.html [22] Sybase: Best Practices for Running ASE 15.0 in Solaris Containers http://www.sybase.com/detail?id=1041285 http://wikis.sun.com/display/SolarisContainers/Sybase [23] Solaris Container Cluster in Sun Cluster Installation Guide http:// docs.sun.com/app/docs/doc/820-4677 [24] System Administration Guide: Virtualization Using the Solaris Operating System http://docs.sun.com/app/docs/doc/819-2450?l=en&q=Virtualization [25] Solaris Container Guide - http://mediacast.sun.com/users/Detlef..Drewanz/media/solaris-container-guide.pdf/details 114