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,

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,

Volumes die zum Beispiel für Oracle DB’s als RAW Files benutzt werden sollen, sollten ja bereits dem richtigen User und der richtigen Gruppe gehören. Man erreicht das mit dem VxVM mit folgendem Befehl:

vxedit -g <group> set user=<user> set group=<group> <volume>

Kleines Beispiel:

vxedit -g alldg set user=oracle set group=dba sysaux2

Mein Artikel in der Rubrik Tipps und Tricks über den Veritas Volume Manager (VxVM) habe ich auch erweitert.

Viele Grüße

Michael Zimmer

Haben wir mehrere Controler im System die die selbe Platte im SAN sehen können, benutzt VxVM per Default Multipathing im Balanced Mode.

Multipathing wird bei VxVM mit dem Befehl vxdmpadm administriert.

• list controller

vxdmpadm listctlr all

• list enclosures

vxdmpadm listenclosure all

• display Path

vxdmpadm getsubpaths ctlr=emc0

vxdmpadm getsubpaths dmpnodename=<enclosure>

• summing up

vxdmpadm getdmpnode enclosure=<enclosure>

• list I/O policy

vxdmpadm getattr enclosure <enclosure> iopolicy

• statistics

vxdmpadm iostat start

vxdmpadm iostart stop

vxdmpadm iostat show all

vxdmpadm iostat show all interval=5 count=10

vxdmpadm iostat show ctlr=<controler> | enclosure=<enclsure>

• performance

vxtrace -o dev,disk -g <diskgroup>

Hallo,

hier findet man zukünftig zu verschiedenen Themen Sammlungen von Befehlen mit kurzen Erklärungen zu verschiedenen Produkten. Aktuell habe ich angefangen meine gesammelten Zettel für die Veritas Produkte von Symantec zu dokumentieren. Aber es soll natürlich noch mehr werden.

Viele Grüße

Michael

Folgende Gegebenheiten:

Dicke Solaris Kiste als Veritas Cluster aufgesetzt, mit gesharten Volumes und obendrauf ein Oracle RAC. Speicherplatz liegt im SAN verteilt auf zwei Standorten. Das bedeutet die Platten werden “hostbased gemirrort”. Aber natürlich so, das je ein Spiegel je Standort (enclosure) existiert. VxVm kann das eigentlich automatisch. So sieht beispielsweise eine Erweiterung eines Veritas Filesystems aus:

• Bei gesharten Disks bitte nur auf dem Master arbeiten:

#vxdctl -c mode

mode: enabled: cluster active – MASTER

master: hugo1

• Filesystem erweitern:

#vxresize -F <fs-type> -g <diskgroup> <volume> <size> mirror=enclr

#vxresize -F vxfs -g hugolinedg myvol +2g mirror=enclr

erweitert das Veritas-Filesystem myvol in der Diskgroup hugolinedg um 2 GB, und zwar so, dass beide Spiegel auf die Standorte verteilt sind. Funktioniert mit UFS genau so. Aber nur vxfs kann man im laufenden Betrieb auch verkleinern. Beim erweitern wird das Volume in ein Layerd-Volume umgewandelt.

Sollte das Volume vor der Erweiterung nicht fehlerfrei über beide Standorte gespiegelt sein, so ergibt die Erweiterung natürlich auch nix anständiges. Heraus kommt ein Volume mit einem einzigen Plex der nur Subvolumes enthält. Diese Subvolumes sind nur ihrerseits Volumes mit einzelnen Plexen und Subdisks. Liegen die Subdisks nun auf nur einem Standort und wir haben vielleicht auch nicht mehr genug Platz frei um das ganze Volume nocheinmal einwandfrei zu spiegeln, sieht es schlecht aus. vxassist mag dann natürlich nicht mehr sauber ein Enclosure abhängen, wenn wir einen Spiegel removen. Übrig bleibt dann ein Volume mit nur einem Spiegel, aber mit Subdisks auf beiden Enclosures und kein Platzt mehr auf dem freien Enclosure um einen kompletten Spiegel neu aufzubauen.

Veritas sei Dank, kann man in dieser Situation natürlich noch alles von Hand gerade ziehen. Das bedeutet, wir legen uns eine neue Subdisk auf dem richtigen Enclosure von Hand an und moven dann die Subdisk auf dem falschen Enclosure auf die neue Subdisk:

• freien Platz fest stellen:

#vxdg -g <diskgroup> free

• Subdisk anlegen:

#vxmake -g <diskgroup> sd <subdisk-name> disk=<diskname> len=<länge> offset=<offset des freien Bereichs>

• Subdisk verschieben

#vxsd -g <diskgroup> -o rm mv  <oldsd> <newsd>

-o rm sorgt in diesem Fall dafür, das die alte Subdisk gelöscht wird. Eventuell ist noch ein “-f” nötig, weil es sich um ein Subvolume handelt.

Nun haben wir wieder einen sauberen Spiegel auf nur einem Standort und können diesen einfach wieder spiegeln und mit einem Log versehen:

#vxassist -g <diskgroup> <volume> mirror=enclr

#vxassist -g <diskgroup> addlog <volume>

Möglich ist aber auch folgendes:

• Subdisk anlegen (s.o.)
  
• Plex anlegen und mit Subdisk versehen

#vxmake -g <diskgroup> plex <plex-name> sd=<subdisk-name>

• Plex an Volume attachen, dh Spiegel aufbauen

#vxplex -g <diskgroup> att <volume> <plex-name>

Als hervorragende Einführung in Veritas Volume Manager und Veritas Cluster kann ich folgendes deutschsprachiges Buch empfehlen:

Veritas Storage Foundation: High End-Computing für UNIX Design und Implementation von Hochverfügbarkeitslösungen mit VxVM und VCS  von Volker Herminghaus und  Albrecht Scriba. Erschienen im Springer Verlag Berlin. ISBN 978-3540346104.

Ausserdem sind auch die Original Dokumentationen von Symantec, die man dort nach entsprechend komplizierter Suche und in immer wieder neuen Anordnungen auf der Webseite runterladen kann, zu empfehlen. (Link spare ich mir, weil er sich zu oft geändert hat)