Hallo!

Neulich habe ich ein Projektangebot bekommen. Man suchte einen erfahrenen Solaris Administrator mit mindestens 10 Jahre Erfahrung mit Solaris 10, ZFS und Zonen. Lustig fand ich dabei, das Solaris 10 erst 2005 erschienen ist.

Nun hat John Fowler, der “Executive Vice President, Systems” von Oracle Solaris 11 für 2011 angekündigt. Wenn man sich kostenlos registriert, kann man den Vortrag und die zugehörige Präsentation anschauen und downloaden. Ankündigungen hat es ja im Hause Oracle nach der SUN Übernahme einige gegeben. Nicht alle werden wohl schnell erfüllt werden. Aber in diesem Fall glaube ich dran.

Solaris 11 braucht Oracle nicht flott aus dem Hut zu zaubern, die Grundlage dafür wurde bereits gelegt und ist in Form von OpenSolaris auch schon seit Ende 2008 verfügbar. Die kontinuierliche Weiterentwicklung konnte man auch im Developer Zweig bis zum 134 Build am eigenen System mitverfolgen.

Es erwarten uns Administratoren reichlich neue Features aber auch eine sehr gravierende Änderung des Paket Formats. Das neue IPS löst das alte Verfahren mit Paketen und Patches ab. Meines Erachtens ein sinnvoller Schritt. Der Download von 1,3 GB großen Recommended Patch Clustern und ein ständig anwachsendes Verzeichnis unter /var/sadm finde ich nicht mehr Zeitgemäß. Es bedeutet aber auch neue Verfahren für die Installation der Maschinen. Alte Install-Server müssen überarbeitet werden. Das will bei Rechenzentren mit vielen Servern gut bedacht und geplant werden. Hinzu kommen dann Kopien der Repository Server für Solaris 11. Nicht zuletzt müssen selbst gebaute Pakete überarbeitet werden. Dabei fällt mir vor allem auf, das es die beliebten Skripte preinstall, postinstall, preremove und postremove nicht mehr gibt. Falls Oracle das nicht noch überarbeitet, gilt es hier das Fehlen dieser Skripts mit eigenen Installationsroutinen oder SMF Services zu umschiffen. Mir fehlt an dieser Stelle die alte Eleganz.

Da wartet also reichlich Arbeit auf uns. Auf geht’s … Wenn mir dann 2012 ein Projektgesuch ins Postfach flattert die einen erfahrenen Solaris 11 Admin mit mindestens 10 Jahren Erfahrung suchen, hab ich zumindest zwei bis drei Jährchen OpenSolaris Vorsprung vor der Realität

Viele Grüße

Michael

Hallo Sysadmins,

schon wieder VxVM – irgendwie suchen sich alle Problemchen dieser Art den Weg zu mir .

Folgende Situation:

Volume durch Erweiterung in Subvolumes aufgespalten, jeweils ein Spiegel (über zwei unterschiedliche Lokationen) und zwei DLR Logs. Ja, es scheint ein DLR würde auch reichen, aber falls es die Seite des Spiegels wo genau das eine Log liegt “erwischt”, will das Volume jetzt ohne DLR auch nicht anlaufen …

Nun ist ein Plex im Status ENABLED STALE:

v  wppwlprdvolN -            ENABLED  ACTIVE   1711276032 SELECT  -        fsgen
pl wppwlprdvolN-06 wppwlprdvolN ENABLED ACTIVE 1711276032 CONCAT  -        RW
sv wppwlprdvolN-S03 wppwlprdvolN-06 wppwlprdvolN-L03 1 1321205760 0 4/4    ENA
sv wppwlprdvolN-S04 wppwlprdvolN-06 wppwlprdvolN-L04 1 48234496 1321205760 4/4 ENA
sv wppwlprdvolN-S07 wppwlprdvolN-06 wppwlprdvolN-L07 1 1056 1369440256 4/4 ENA
sv wppwlprdvolN-S08 wppwlprdvolN-06 wppwlprdvolN-L08 1 31456224 1369441312 4/4 ENA
sv wppwlprdvolN-S09 wppwlprdvolN-06 wppwlprdvolN-L09 1 195035136 1400897536 4/4 ENA
sv wppwlprdvolN-S12 wppwlprdvolN-06 wppwlprdvolN-L12 1 115343360 1595932672 4/4 ENA

v  wppwlprdvolN-L03 -        ENABLED  ACTIVE   1321205760 SELECT  -        fsgen
pl wppwlprdvolN-P01 wppwlprdvolN-L03 ENABLED ACTIVE LOGONLY CONCAT -       RW
sd h_WPPWLPRDDG_1-02 wppwlprdvolN-P01 h_WPPWLPRDDG_1 1879055584 2112 LOG HAU_EMC4661_0b63 ENA
pl wppwlprdvolN-P07 wppwlprdvolN-L03 ENABLED ACTIVE LOGONLY CONCAT -       RW
sd c_WPPWLPRDDG_1-02 wppwlprdvolN-P07 c_WPPWLPRDDG_1 1663042064 2112 LOG ENK_EMC4888_0b63 ENA
pl wppwlprdvolN-P19 wppwlprdvolN-L03 ENABLED ACTIVE 1321205760 CONCAT -    RW
sd h_WPPWLPRDDG_1-24 wppwlprdvolN-P19 h_WPPWLPRDDG_1 341835776 1321205760 0 HAU_EMC4661_0b63 ENA
pl wppwlprdvolN-P20 wppwlprdvolN-L03 ENABLED STALE 1321205760 CONCAT -      WO
sd c_WPPWLPRDDG_1-25 wppwlprdvolN-P20 c_WPPWLPRDDG_1 341835776 1321205760 0 ENK_EMC4888_0b63 ENA

Die zugehörige Subdisk ist OK. Ein vxrecover bringt in diesem Fall nichts. Laut Troubleshooting Guide, wird beim Neustart des Volumes ein Resync angestoßen. Aber wer gibt schon einen Haufen Geld aus, damit die Anwendung permanent läuft und braucht dann eine Downtime für das Spiegeln eines Volumes …..

Eine mögliche Lösung sieht so aus:

Den betroffenen Plex disassoziieren und anschließend neu attachen.

vxplex -g <group> -v <volume> dis <plex>

vxplex -g <group> att <volume> <plex>

Also in diesem Fall:

vxplex -g WPPWLPRDDG -v wppwlprdvolN-L03 dis wppwlprdvolN-P20

vxplex -g WPPWLPRDDG att wppwlprdvolN-L03 dis wppwlprdvolN-P20

Damit wird nur dieser eine Plex des Subvolumes neu gespiegelt. Der Rest des Volumes braucht nicht angefasst zu werden. Und natürlich braucht man auch keine Downtime.

Ach so …, die DLR taugen nicht wirklich was – DCO wäre deutlich besser und sinnvoller….

Viele Grüße

Michael

Hallo Admins,

seit VxVM Version 3.2 gibt es das Feature FastResync für Volumes. In Verbindung mit einem DCO Log werden wenn die Spiegel nach einem Ausfall einer Hälfte wieder synchronisieren nur die geänderten Blocks bearbeitet. Falls der Spiegel nur teilweise betroffen ist, kann das erheblich schneller erfolgen als ein vollständiges spiegeln.  Weil es ein kostenpflichtiges Feature war, muss man es gesondert einschalten. Beim neu anlegen eines Volumes mit Logs ist es also nicht eingeschaltet. Es sei den man nutzt vxsnap prepare. Wird ein Volume für Snapshots eingerichtet, kann man damit die nötigen DCO Logs automatisch anlegen, und auch FastResync wird eingeschaltet.

Abfragen ob FastResync eingeschaltet ist:

vxprint -g <group> -F%fastresync <volume>

Persistent oder nur im Memory:

vxprint -g <group> -F%hasdcolog volume

Alle Volumes mit Persistent FastResync auflisten:

vxprint -g <group> -F “%name” -e “v_fastresync=on && v_hasdcolog”

Einschalten von FastResync (ausschalten analog mit off):

vxvol -g <group> set fastresync=on <volume>

Neue DCO Logs und FastResync einschalten:

vxsnap -g <group> prepare <volume>

Dieser Befehl fällt allerdings auf die Nase, wenn FastResync schon eingeschaltet war. Kann man dann vorher einfach ausschalten (s.o.).
Viele Grüße

Michael

Hallo Sysadmins,

was ist der Unterschied zwischen “Offline” und “Offline Prop” bzw. hares -offline … und hares -offprop?

Da hat mich neulich der Kollege Sitaro erwischt. Ich konnte die Frage nicht auf Anhieb beantworten. Dabei ist es eigentlich ganz einfach:

hares -offline … oder in der GUI auf die entsprechende Resource klicken und dann “Offline” auswählen nimmt nur die entsprechende Rescource offline.

hares -offprop … oder in der GUI “Offline Prop” bedeutet Offline propagate für die Resource UND alle ihre “children”.

Also alles was in der Hierarchie in der GUI unterhalb der Resouce gelistet ist, wird mit offline genommen. Ist ja ein bisschen komisch bei VCS: Die Eltern sind von ihren Kindern abhängig!

Viele Grüße

Michael

Hallo Sysadmins,

ab Veritas Cluster 5.0 MP3 gibt es eine Service Gruppe Namens VCShmg. Komischerweise ist sie immer offline und es gibt nichts zu konfigurieren daran.  Die darin einzige Rescource VCShm ist allerdings online auf allen Systemen im Cluster.

Das Ding ist mir erst gar nicht aufgefallen, weil ich es nur mit Clustern zu tun hatte die von Version 4.1 upgegradet waren. Dort taucht dann diese Gruppe nicht auf.

Auch sieht man die Gruppe mit hastatus -sum nicht …

Also: Was’n'das?

Der Cluster überwacht die Auslastung von CPU und Swap Space auf der Maschine mit Hilfe eines Daemons Namens HostMonitor. Dieser Daemon ist neu seit Version 5.0 MP3. Auch bei den System die durch Upgrade auf diesen Stand gebracht worden sind, läuft er im Hintergrund.

Bei neu aufgesetzten Clustern wird nun eine extra Service Group für den HostMonitor angelegt. Um zu dokumentieren, das man den Status der Gruppe nicht konfigurieren kann, wird sie immer als Offline angezeigt.

Wie schon gesagt, nur in der GUI.  Weder die Resource noch die Gruppe taucht in der main.cf auf! Bei hastatus werden die Resourcen pro Maschine gelistet, aber bei hastatus -sum bleibt die Gruppe unerwähnt.

Und wozu ist das nun gut?

Nun …..

Es soll ja “Spezialisten” geben, die geclusterte Maschinen bei 95% CPU Auslastung betreiben. Kommt dann mal ein bisschen mehr Last auf die Maschine, kommt es zu einer System Panic, weil GAB glaubt das wäre sinnvoll …

Ich vermute mal, das Symantec die Nase voll von solchen “Spezialisten” und ihren Service Calls hatte. Der HostMonitor protokolliert die Auslastung von CPU und Swap in der VCS Engine und im Syslog der Maschine. Und somit ist die Ursache der Panic schnell gefunden.

Fragt sich, warum die Leute Geld und Zeit investieren um ihre Anwendungen hochverfügbar zu gestalten, um dann kein Geld für angemessene Hardware übrig zu haben?

Viele Grüße

Michael

Hallo Sysadmins,

hier ein kleines Beispiel wie man Solaris 10 mit ZFS als Root Filesystem patchen und upgraden kann:

Wenn Zonen auf dem System sind, sollten sie installiert und gebootet sein. Überprüfen kann man das mit

zoneadm list -cv

Da wir auf dem System die Zonen mit VCS schwenken und die Root Filesysteme der Zonen mit VxFS realisiert sind, habe ich die Zonen zunächst deportiert und dann für das Update des OS auskommentiert:

zoneadm -z <zönchen> detach

in /etc/zones/index mit führendem # auskommentieren

Bei Solaris 10 5/09 gibt es einen Bug bei luactivate. Als Workaround sollte folgende Variable in der Shell exportiert sein:

export BOOT_MENU_FILE=”menu.lst”

Und los geht es:

1. lucreate -n Solaris_10_10-09
2. luupgrade -u -n Solaris_10_10-09 -s /cdrom/…
3. luupgrade -t -n Solaris_10_10-09 -s /…/10_Recommended/
4. lustatus
5. luactivate Solaris_10_10-09
6. init 6

Die dann noch fehlenden Zonen wieder einkommentieren und mit

zoneadm -z <zönchen> attach -u

auf den neusten Stand bringen.

Wenn dann alles OK gelaufen ist, kann man noch die ZFS Pools updaten:

zpool upgrade <rootpool>

und die alte BE löschen:

ludelete Solaris_old-BE

aber auch hier muss die Shell Variable wie oben beschrieben gesetzt sein.

Viele Grüße

Michael

Hallo Sysadmins,

Defragmentieren, Reorganisieren … OK: nennen wir es Optimieren.

All das geht bei VxFS natürlich online!

So um das Jahr 2000 habe ich mal für einen Automobilzulieferer zwei damals schon veraltete SUN Ultra 1 als Web Proxy Server mit squid aufgesetzt. Die hatten leider kein Kleingeld für ein VxFS übrig und UFS machte zwei Probleme: Durch die hohe Anzahl an kleinen Files musste das UFS mit einer höheren Anzahl von Inodes angelegt werden. Sonst waren die Inodes schon voll, aber eigentlich wäre noch Platz für Daten da. Tja und nach jeweils ca. 4 Wochen war das UFS Filesystem so defragmentiert, das ein “newfs” fällig war. Beides wäre damals schon mit VxFS vermeidbar gewesen.

Es gibt zwei Arten der Optimierung:

• für Verzeichnisse

fsadm -F vxfs -D <mountpoint>

zeigt einen “Directory Fragmentation Report” an:

hugo.global:/# fsadm -F vxfs -D /hirschhome

Directory Fragmentation Report
Dirs        Total      Immed    Immeds   Dirs to   Blocks to
Searched    Blocks     Dirs     to Add   Reduce    Reduce
total          9515      6622      5412       230       276         619

fsadm -F vxfs -d <mountpoint>

führt dann die Optimierung durch:

hugo.global:/# fsadm -F vxfs -d /hirschhome
hugo.global:/# fsadm -F vxfs -D /hirschhome

Directory Fragmentation Report
Dirs        Total      Immed    Immeds   Dirs to   Blocks to
Searched    Blocks     Dirs     to Add   Reduce    Reduce
total          9515      6204      5421       221       226         227

• für Extents

fsadm -F vxfs -E <mountpoint>

zeigt wieder einen Report an:

hugo.global:/# fsadm -F vxfs -E /hirschhome
Extent Fragmentation Report
Total    Average      Average     Total
Files    File Blks    # Extents   Free Blks
99773         164           1    56827427
blocks used for indirects: 1312
% Free blocks in extents smaller than 64 blks: 0.18
% Free blocks in extents smaller than  8 blks: 0.05
% blks allocated to extents 64 blks or larger: 97.00
Free Extents By Size
1:       3933            2:       4241            4:       4235
8:       2101           16:       1567           32:       1033
64:        577          128:        485          256:        386
512:        291         1024:        215         2048:        822
4096:        273         8192:        153        16384:         82
32768:         31        65536:         23       131072:         22
262144:          9       524288:          2      1048576:          2
2097152:          1      4194304:          1      8388608:          0
16777216:          0     33554432:          1     67108864:          0
134217728:          0    268435456:          0    536870912:          0
1073741824:          0   2147483648:          0

fsadm -F vxfs -e <mountpoint>

führt die Optimierung durch:

Keine Panik, das kann eine Weile dauern, weil zum Teil mehrere Durchläufe stattfinden (kann man mit -p <passes> ändern, default ist 5; mit -s wird am Ende jeden Durchlaufs eine Zusammenfassung angezeigt).

hugo.global:/# fsadm -F vxfs -e /hirschhome
hugo.global:/# fsadm -F vxfs -E /hirschhome

Extent Fragmentation Report
Total    Average      Average     Total
Files    File Blks    # Extents   Free Blks
99798         165           1    56609775
blocks used for indirects: 1120
% Free blocks in extents smaller than 64 blks: 0.06
% Free blocks in extents smaller than  8 blks: 0.01
% blks allocated to extents 64 blks or larger: 97.21
Free Extents By Size
1:        529            2:        395            4:        422
8:        604           16:        589           32:        572
64:        656          128:        600          256:        559
512:        413         1024:        270         2048:        462
4096:        300         8192:        215        16384:        127
32768:         26        65536:         21       131072:         13
262144:          7       524288:          2      1048576:          1
2097152:          2      4194304:          1      8388608:          0
16777216:          0     33554432:          1     67108864:          0
134217728:          0    268435456:          0    536870912:          0
1073741824:          0   2147483648:          0

Empfohlen wird die Optimierung vor allem für Datenbank Files. Ein guter Zeitpunkt soll vor dem Backup sein.  Dabei soll eine verifizierbare Performance Steigerung zu Tage treten. Mir fehlt leider im Augenblick eine adäquate Testumgebung um hier Daten liefern zu können ….

Eine weitere Anwendung der Optimierung ist natürlich vor dem Verkleinern eines Veritas Filesystems.

Viele Grüße

Michael

Hallo Sysadmins,

vor ein paar Tagen habe ich ein VxFS Filesystem erweitert und df -h hat mir komische Werte anschließend angezeigt.  Jedenfalls meinte das der Kunde. Das Filesystem wurde um 300GB erweitert. Vorher hatten wir 20GB frei und anschließend – nein – nicht etwa 320GB sondern etwa 318GB. Der arme Kunde fühlte sich um 2GB betrogen und fing morgens um 4.30h eine lebhafte Diskussion an.

Heute ging es meinen Kollegen ähnlich. Das VxFS Filesystem war brandneu erzeugt und es gab eine signifikante Lücke zwischen ‘size’ ‘used’ und ‘avail’. Darauf hin ging die Suche los: Bei UFS (und bei ext2 unter LINUX) werden schon mal 10% des verfügbaren Platzes im Filesystem für root reserviert. Also wo bitte kann man bei VxFS bzw. bei vxtunefs die Reservierung einstellen? Die Kollegen haben einen Call bei Symantec eröffnet – bin mal gespannt was dabei raus kommt … Ein kleiner gemeiner Test für den Support

Zur Sache Schätzen:

Da VxFS unter Solaris nie als Filesystem boot fähig ist/war – machen auch Reservierungen wie bei UFS üblich keinen Sinn. Wenn root und var Filesystem vom User fast voll geschrieben wurden (bis auf den reservierten Bereich), ist es von Vorteil, wenn für den root-User noch etwas Platz übrig ist. So kann man sich noch einloggen und für Abhilfe sorgen.  Der Default Wert für UFS liegt übrigens bei (64MBytes/volumesize)*100, liegt immer zwischen 1 und max 10% und kann natürlich schon beim Erzeugen des UFS per ‘mkfs -o free=99 …. ‘ beeinflusst werden . Ebenso mit ‘tunefs -m [0-10] % <filesystem>’ geändert werden. Für VxFS gibt es das nicht!

Woher kommt er nun – der fehlende freie Plattenplatz bei leeren VxFS Filesystemen? VxFS ist ein Extent basiertes Filesystem. Es gibt keine vorher festgelegten (beim Anlegen) Strukturen von Inodes und DataBlocks wie bei UFS. Sondern nur dynamische Strukturen. Zur Verwaltung des freien Platzes gibt es eine extent_map. Das ist ein File, was für den Nutzer und auch für den Administrator im Verborgenen liegt (außer ncheck Utility). In dieser extent_map werden alle Permutationen der möglichen Extent Längen vorgehalten. Je mehr freier Platz vorhanden ist, desto größer wird diese Tabelle. Füllt sich das Filesystem im Laufe der Zeit, werden die möglichen Permutationen weniger  und die Tabelle wird kleiner. Wenn das Filesystem schließlich zu 100% gefüllt ist, wird die Tabelle nicht mehr benötigt.

Bei VxFS ist es also möglich den gesamten  Platz des Filesystems vollständig für Daten auszunutzen. Abzüglich des kleinen Bereichs der beim neu angelegten Filesystems schon als ‘used’ ausgewiesen wird. Im Gegensatz zum UFS Filesystem (gutes altes Berkeley FFS übrigens), sind die Verwaltungsinformationen relativ klein ( bei 500GB nur ca. 191M statt UFS imerhin ca. 8GB für Verwaltung). Außerdem ist durch die dynamische Struktur sichergestellt, das sowohl kleine als auch sehr große Files gut verwaltet werden können. UFS macht bei Extremwerten keine gute Figur.  Ganz zu Schweigen von den Möglichkeiten der Online Reorganisation oder auch dem Vergrößern und Verkleinern im laufenden Betrieb.

Vielleicht schreibe ich demnächst noch was über weitere Features von VxFS: Storage Checkpoints, Reorganisation oder die Konvertierung eines UFS in VxFS (das allerdings nicht Online im gemounteten Zustand). Dran bleiben und RSS Feed abonnieren …

Wer sich selber tiefer in VxFS und VxVM einarbeiten möchte, für den habe ich noch einen Buch Tip:

“Storage Management in Data Centers” von Voker Herminghaus und Albrecht Scriba. Frisch im Springer Verlag erschienen!

Viele Grüße

Michael

Hallo Sysadmins!

Heute möchte ich mal einige in Solaris eingebaute Security Features vorstellen. Man kann bei Solaris 10 auch nur mit Bordmitteln schon einiges tun. Hier ein paar Anregungen.

• Protect OBP :

eeprom security-mode=command

Damit wird bei Änderungen im Boot Prompt ein Passwort gefordert.  Es gibt auch die Möglichkeit den Level auf “full” zu setzen. Dann aber braucht man auch beim Booten der Maschine das Passwort!

• None Executable Stack:

/etc/system Parameter: set noexec_user_stack=1

Damit werden typische Buffer Overflows, wo aus dem User Stack code ausgeführt wird, mindestens behindert. Allerdings ist hierfür ein Reboot erforderlich, damit der Parameter zieht. Für die Installationen einer Oracle DB oder von Veritas Produkten wird das eh gefordert.

• Core Dump Logging:

/usr/bin/coreadm -e log

Ist das eingestellt, wird beim Auftreten eines Coredumps, per syslog geloggt. Ansonsten weiß man ja gar nicht unbedingt ob ein Core aufgetreten ist (ok, vom syscore mal abgesehen ). Was das mit Security zu tun hat? Nun, vielleicht macht man einen Fehler beim hacken und statt das es funktioniert stürzt der betroffene Deamon ab …

• BART:

Nein nein – ich meine nicht Bart Simpson …. sondern Basic Audit Reporting Tool. Das hat eine ähnliche Funktion wie das Produkt Tripwire. Zu jedem File wird ein Eintrag in eine zu erstellendes Verzeichnis gestellt. Nach diesem initialen Lauf, kann nach jedem weiteren Lauf das jeweils neu erstellte Verzeichnis mit “bart compare” verglichen werden und dadurch ein Report erzeugt werden. Es macht übrigens keinen Sinn, wie in unten angeführten Beispiel, das Verzeichnis /root/bart.control auf der Maschine liegen zu lassen (wenigstens die MD5 Summe ziehen und vergleichen, besser verschlüsseln und noch besser beides und ab auf eine andere Maschine).

1. find <dir> | bart create -I > /root/bart.control
2. find <dir> | bart create -I > /root/bart.test
3. bart compare /root/bart.control /root/bart.test

• Signed ELF:

Die Solaris Binaries im ELF Format sind alle von Hause aus signiert. Diese Signatur kann man auch überprüfen und damit feststellen, ob das Programm im Orginal vorliegt:

elfsign verify -e <elf-bin>

• Fingerprint DB :

Noch eine Nummer besser: Mit Hilfe der MD5 Checksumme eines jeden Betriebssystem Files (es sind ja nicht alles ELF-Binaries, sondern auch Skripte) kann auf bei SUN auf der Sunsolve Seite feststellen, zu welchem Release das File gehört, wie der Pfad lauten soll, zu welchem Paket es gehört und auch wie der Patchstand ist.

Prüfsumme generieren:

digest -v -a md5 <file>

Damit dann auf http://sunsolve.sun.com/pub-cgi/fileFingerprints.pl und hier die Checksumme eingeben!

Ist doch nicht übel, oder

Viele Grüße

Michael Zimmer

Hallo,

heute gibt’s ne große Show von Oracle zur Übernahme von SUN.

Wer Spaß dran hat kann auch die Zwitscherreien online verfolgen. Hier die Twitterwal!

Viele Grüße

Michael