Der OpenSolaris fork Openindiana und Boot Environment

 

Um zu zeigen wie geil sich das ZFS Dateisystem integrieren lässt muss man sich nur mal das Thema Boot Environment um OpenSolaris / Solaris 11 anschauen.

Solaris ist ein System fürs Rechenzentrum bzw. Systeme die möglichst ausfallfrei laufen sollen. Natürlich ist kein Code Fehlerfrei und daher gibt es Updates. Jeder Administrator weiß das Updates Dinge sehr deutlich verschlimmbessern können. Das gleiche gilt für neue Programmversionen. Kaum hat man das Update eingespielt funktioniert plötzlich irgendetwas nicht mehr. Dumm wenn man dieses Etwas dringend braucht…. Rollback ist in so einem Fall auch nicht immer möglich. Also Datensicherung zurückspielen? System für die Zeit offline und noch schlimmer alle Daten seit der Datensicherung ggf. weg oder mühsam von Hand durch die Gegend kopieren? Tja, manchmal ist das so. Natürlich kann man auch jedes Update erst in einem Baugleichen Testsystem probieren. Jeder Administrator weiß auch hier: „Das gibt es kaum irgendwo und eine Funktionsgarantie hat man dadurch auch nicht!“ Ja, natürlich kann man über diesen Weg einige Probleme ausschließen und es gibt einem das Gefühl von Sicherheit.

Egal ob ich jetzt ein Windows System von Microsoft oder eine beliebige Linux Distribution nehme. Starte ich ein Update, ist das System in der Zeit des Updates nicht zu 100% verfügbar. Dienste werden beendet, neugestartet… Vor allem Microsoft Systeme wollen für jeden Mist neugestartet werden. (Schalten sie den Computer nicht aus Updates werden installiert… Update 1 von x). Aus Erfahrung kann ich sagen dass der Reboot eines, vielleicht sogar etwas älteren, Microsoft Domaincontrollers schnell mal 15 – 20 Minuten dauern kann. Das zusammen mit den Updates und allem Zipp und Zapp, kann so eine Kiste schon mal 2 Stunden offline nehmen. ServicePack installation, vielleicht sogar am Exchangeserver usw..

Wie sagen die Jungs von QVC das so schön? Aber das muss mit den Boot Environments nicht mehr so sein!

Eine Boot Environment muss man sich so vorstellen wie eine komplette Kopie/Snapshot der Daten, Konfigurationsdateien und Verzeichnisse die man zum Booten und Betreiben von seinem Solaris System braucht. Alles lässt sich schnell und einfach auf der Kommandozeile mit dem Befehl: beadm bedienen.
Was bringt einem das?

Gaaaannnzzz einfach! Man kann schnell vor Änderungen an der Konfiguration, Updates oder ähnlichem eine neue Boot Environment erstellen. Dann kann man die Änderungen vornehmen und sollte es doch nicht klappen wie gewünscht kann man einfach im alten Boot Environment neustarten und schon ist alles wie vorher. Es geht aber noch besser! Man kann seine Änderungen, Updates oder Installation einfach direkt im neuen Boot Environment vornehmen. Dann wäre der Ausfall des Systems bei einem Update nur so lange wie der Reboot benötigen würde.
Der Bootloader wird automatisch angepasst und alles arbeitet im groben in Zusammenarbeit mit ZFS-Snapshots und wie gut diese sind muss ich ja nicht noch  mal sagen, oder?

Kleines Beispiel gefällig?

Natürlich braucht man mehr Rechte als ein einfacher User. Also bitte pfexec oder su….

Im Grunde lässt sich alles mit dem Befehl beadm (nicht beadmin wir wollen ja kein Windows Backup machen :-P) erledigen:

$ beadm list
BE                                     Active Mountpoint Space Policy Created
09-02-2012                             -      -          88,0K static 2012-02-09 15:30
Sebastians-Notebook                    -      -          22,3M static 2011-10-25 10:49
oi_151a2-Sebastians-geht-steil-Version NR     /          14,7G static 2012-02-14 16:18
openindiana                            -      -          26,5M static 2011-09-28 19:06
openindiana-1                          -      -          22,6M static 2011-10-27 20:04

Listet einem alle Boot Environments seines Systems auf. Diese sollten einem schon vom Grub her bekannt vorkommen, da sie einen bei jedem Start anlächeln. Mal angenommen wir wollen nun ein Update von Virtualbox machen (das steht bei mir gerade an :-P) dann erstelle ich als erstes dafür ein neues Boot Environment:

$ beadm create Nach-Virtualbox-Update
Created successfully

Mal schauen ob es angelegt wurde….

$ beadm list Nach-Virtualbox-Update
BE                     Active Mountpoint Space Policy Created
Nach-Virtualbox-Update -      -          83,0K static 2012-02-23 14:32

Wunderbar. Damit habe ich nun erstmal eine „Kopie“ meiner aktuellen Boot Umgebung. Jetzt möchte ich natürlich noch das diese beim nächsten Reboot automatisch gestartet wird. Daher muss ich sie noch aktivieren:

$ beadm activate Nach-Virtualbox-Update
Activated successfully

$ beadm list Nach-Virtualbox-Update
BE                     Active Mountpoint Space Policy Created
Nach-Virtualbox-Update R      -          14,7G static 2012-02-23 14:32

Um nun in dieser Boot Umgebung herumzufummeln mounte ich sie einfach und schnell:

$ beadm mount Nach-Virtualbox-Update /mnt
Mounted successfully on: '/mnt'

Jetzt kann man schon erahnen was alles möglich ist, richtig? 🙂

Die neuste Virtualbox Version habe ich natürlich schon heruntergeladen. Also auspacken…

$ tar xvzf VirtualBox-4.1.8-75467-SunOS.tar.gz
Decompressing 'VirtualBox-4.1.8-75467-SunOS.tar.gz' with '/usr/bin/gzcat'...
tar: blocksize = 10
x VirtualBox-4.1.8-SunOS-r75467.pkg, 248977920 bytes, 486285 tape blocks
x LICENSE, 20137 bytes, 40 tape blocks
x autoresponse, 151 bytes, 1 tape blocks
x ReadMe.txt, 1778 bytes, 4 tape blocks

Bevor ich nun die neue Version von Virtualbox installiere muss ich die alte deinstallieren. Das mache ich natürlich nicht in meinem aktuellen Boot Environment sondern nur im neuen:

$ pkgrm -R /mnt SUNWvbox

The following package is currently installed:
   SUNWvbox  Oracle VM VirtualBox
             (i386) 4.1.6,REV=2011.11.05.00.26.74727

Do you want to remove this package? [y,n,?,q]

......

..........


Removal of <SUNWvbox> was successful.

Und weg ist es 🙂 Natürlich kann ich im aktuell gestarteten System weiter mit Virtualbox Arbeiten. Es ist hier ja noch installiert! Wo wir gerade beim Installieren sind. Jetzt kann ich die aktuelle Version direkt in der neuen Startumgebung installieren:

$ pkgadd -R /mnt -d VirtualBox-4.1.8-SunOS-r75467.pkg

The following packages are available:
  1  SUNWvbox     Oracle VM VirtualBox
                  (i386) 4.1.8,REV=2011.12.19.14.10.75467

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]:

.......

............

Installation of <SUNWvbox> was successful.

So nun können wir ja schon die neue Boot Environment aushängen:

$ beadm unmount -f Nach-Virtualbox-Update
Unmounted successfully

Fertig…. So schnell und einfach kann es gehen. Wenn man jetzt neustartet:

reboot -p

Kommt das System hoch und hat sofort die neue VirtualBox Version. Geht etwas nicht, startet man einfach in der alten Startumgebung 🙂 Das mein Beispiel nun an VirtualBox hängt ist Zufall. Geht natürlich auch mit fest jedem anderen Paket!

Natürlich kann man Gleiches auch vor Änderungen an Konfigurationen machen usw. usw. usw… Macht man ein ganzes Image Update seiner xyz-Solaris Version wird meist automatisch ein neues Boot Environment erstellt und alles läuft in diesem ab. Man kann einfach vor irgendwelchen Änderungen oder Konfigurationen ein neues Boot Environment anlegen. Kostet nichts und ist mit einem Einzeiler auf der Konsole in Sekunden erledigt. Wenn man es später doch nicht braucht, wirft man es einfach wieder weg, kein Problem….

Eine Warnung habe ich natürlich noch:

Hat man sich einmal daran gewöhnt und geht an Systeme mit dem natürlichen Hintergedankten: „Wenn ich was versaue, hohle ich es einfach aus dem alten Boot Environment oder einem Snapshot wieder…“ Kann man schnell Probleme bekommen. Denn man hört Stückchen für Stückchen auf sich zu merken wie der Stand war oder macht vorher keine Sicherungskopien der Konfigurationsdateien mehr usw. usw… Ist mir alles schon passiert. 🙂 Man steht dann am Ende vor der Kiste und sagt: „Wie scheisse ist denn bitte dieses Filesystem?“