-=Kernel-Error=-

Datenhaufen zu IT und Elektronik.

Kategorie: ZFS Filesystem (Seite 3 von 3)

ZFS NFS

22. März 2012 / / Keine Kommentare

NFS Freigaben erstellen

Mal eben schnell einen NFS Share anlegen ist mit ZFS überhaupt kein Problem. Ich greife mir mal schnell meinen 8GB USB-Stick und stopfe ihn in den Rechner. Dann lege ich schnell einen ZFS Pool auf diesem an:

$ zpool create nfs-share c3t0d0p0
$ zpool list
NAME        SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
nfs-share  7,44G    91K  7,44G     0%  1.00x  ONLINE  -
platte2     149G  37,5G   111G    25%  1.05x  ONLINE  -
rpool       464G  46,6G   417G    10%  1.00x  ONLINE

Zur besseren Übersicht lege ich hier nun ein weiteres Volume an und gebe das direkt per NFS „frei“:

$ zfs create nfs-share/freigabe01
$ zfs set sharenfs=on nfs-share/freigabe01
$ zfs get sharenfs nfs-share/freigabe01
NAME                  PROPERTY  VALUE     SOURCE
nfs-share/freigabe01  sharenfs  on        local

Einmal kontrollieren welche Exports es nun gibt:

$ zfs get sharenfs nfs-share/freigabe01
NAME                  PROPERTY  VALUE     SOURCE
nfs-share/freigabe01  sharenfs  on        local

Wunderbar…. Nun könnte man diesen Share schon mounten und nutzen. Ist nicht sonderlich schwer, oder? Natürlich kann man die gängigen NFS Optionen auf einen solchen Share anwenden, alle eine Sache der Optionen 😛 Ganz lustig ist nun folgendes…. Mache ich nun ein:

$ zpool export nfs-share

Ziehe dann den USB-Stick raus und gehe zu einem anderen Rechner. Dann kann ich diesen dort ja mit:

$ zpool import nfs-share

Wieder einbinden. Alle ZFS-Einstellungen bleiben ja erhalten. Somit auch der share. Ich habe damit also einen Tragbaren NFS share. Stopfe ich diesen in einen Rechner und importiere den ZFS Pool dann habe ich auch sofort wieder meinen nutzbaren NFS Share 😀 An so einem Punkt wird einem schnell klar welche Möglichkeiten einem ZFS damit bietet diese Konfigurationen mitwandern zu lassen. Mir fällt jetzt zwar gerade kein genaues Einsatzfeld für einen Tragbaren NFS Share auf einem USB-Stick ein, denn noch schön zu wissen das es geht 😛

Openindiana Gnome Nautilus ZFS Snapshot Time-Slider
Openindiana Gnome Nautilus ZFS Snapshot Time-Slider

ZFS Snapshots

22. März 2012 / / Keine Kommentare

ZFS Snapshots

Eine wirklich geile Funktion von ZFS sind Snapshots. Macht man einen Snapshot friert ZFS den aktuellen Stand des Dateisystems einfach ein. ZFS schreibt so oder so jede Änderung an eine neue Stelle (copy on write). Die Blöcke werden bei einem Snapshot einfach nicht mehr zum überschreiben freigegeben. Somit ist es für ZFS einfacher einen Snapshot zu machen als eine Datei zu speichern. Einen snapshot kann man natürlich einfach wiederherstellen, auf diesen Zugreifen (um sich mal schnell eine versehentlich gelöschte Datei aus diesem heraus zu kopieren), ihn wiederherstellen oder aus ihm einen beschreibbaren Clone erstellen. Wenn gewünscht kann man einen Snapshot oder nur die Veränderung zwischen zwei Snapshots per SSH auf einen anderen Rechner schieben. Dabei werden natürlich alle Einstellungen der Dateisysteme (NFS Shares, SMB Shares, ISCSI Targets, Quotas usw. usw…) übernommen. Man kann also für 0€ seinen Store auf eine andere Maschine Spiegeln. Als Sicherung oder für den failover!

Ich habe mir für meinen Test nun erstmal einen neuen ZFS Pool mit dem Namen wurstpelle angelegt. In diesem habe ich schnell das ZFS Volume bernd angelegt und diesem eine Quota von 10GB sowie eine Reservierung von 3GB verpasst:

$ zpool create wurstpelle c3d0p0
$ zfs create wurstpelle/bernd
$ zfs set quota=10G wurstpelle/bernd
$ zfs set reservation=3G wurstpelle/bernd
$ zfs list
NAME                     USED  AVAIL  REFER  MOUNTPOINT
...
wurstpelle              3,00G  70,3G    32K  /wurstpelle
wurstpelle/bernd          31K  10,0G    31K  /wurstpelle/bernd

In diesem erstelle ich nun schnell 1GB Testdateien (10 Stück je 100MB):

$ dd if=/dev/zero of=/wurstpelle/bernd/image01.img bs=10240 count=10240
10240+0 records in
10240+0 records out
$ ls -lh
total 204833
-rw-r--r--   1 root     root        100M Okt 31 15:21 image01.img

$ cp image01.img image02.img
$ cp image01.img image03.img
$ cp image01.img image04.img
$ cp image01.img image05.img
$ cp image01.img image06.img
$ cp image01.img image07.img
$ cp image01.img image08.img
$ cp image01.img image09.img
$ cp image01.img image10.img
$ ls -lh
total 1993042
-rw-r--r--   1 root     root        100M Okt 31 15:21 image01.img
-rw-r--r--   1 root     root        100M Okt 31 15:21 image02.img
-rw-r--r--   1 root     root        100M Okt 31 15:21 image03.img
-rw-r--r--   1 root     root        100M Okt 31 15:22 image04.img
-rw-r--r--   1 root     root        100M Okt 31 15:22 image05.img
-rw-r--r--   1 root     root        100M Okt 31 15:22 image06.img
-rw-r--r--   1 root     root        100M Okt 31 15:22 image07.img
-rw-r--r--   1 root     root        100M Okt 31 15:22 image08.img
-rw-r--r--   1 root     root        100M Okt 31 15:22 image09.img
-rw-r--r--   1 root     root        100M Okt 31 15:22 image10.img

Mal schauen wie voll der Pool nun ist:

$ zfs list wurstpelle/bernd
NAME               USED  AVAIL  REFER  MOUNTPOINT
wurstpelle/bernd  1000M  9,02G  1000M  /wurstpelle/bernd

Nun erstelle ich vom Dateisystem bernd mal einen Snapshot:

$ zfs snapshot wurstpelle/bernd@Test-snapshot>

Diesem Snapshot muss ich natürlich einen Namen geben, das passiert ab dem @. Mein Snapshot heißt also nun Test-snapshot. Ab diesem Moment gibt es unter /wurstpelle/bernd einen Ordner mit dem Namen „.zfs“ diese ist per default nicht sichtbar. Selbst mit einem ls -lisa nicht:

$ ls -lisa
total 2048352
4    3 drwxr-xr-x   2 root     root          12 Okt 31 15:22 .
4    3 drwxr-xr-x   3 root     root           3 Okt 31 15:17 ..
8 204833 -rw-r--r--   1 root     root     104857600 Okt 31 15:21 image01.img
9 204833 -rw-r--r--   1 root     root     104857600 Okt 31 15:21 image02.img
10 204833 -rw-r--r--   1 root     root     104857600 Okt 31 15:21 image03.img
11 204833 -rw-r--r--   1 root     root     104857600 Okt 31 15:22 image04.img
12 204849 -rw-r--r--   1 root     root     104857600 Okt 31 15:22 image05.img
13 204833 -rw-r--r--   1 root     root     104857600 Okt 31 15:22 image06.img
14 204833 -rw-r--r--   1 root     root     104857600 Okt 31 15:22 image07.img
15 204833 -rw-r--r--   1 root     root     104857600 Okt 31 15:22 image08.img
16 204833 -rw-r--r--   1 root     root     104857600 Okt 31 15:22 image09.img
17 204833 -rw-r--r--   1 root     root     104857600 Okt 31 15:22 image10.img

Ich kann aber mit einem cd einfach in diesen Ordner wechseln. In diesem gibt es einen Ordner snapshot und hier liegt mein Test-snapshot:

$ cd .zfs
cd snapshot/
$ ls -lh
total 3
drwxr-xr-x   2 root     root          12 Okt 31 15:22 Test-snapshot

Cool, hm? Wechsel ich nun in den Snapshot schaut alles aus wie mein Dateisystem zum Zeitpunkt des Snapshots. Ich kann Dateien öffnen, sie herauskopieren, ich könnte den Snapshot sogar als Backup wegsichern!

Snapshot/Backup/wegsichern?!?!? Joar… Wie wäre es mit einem Einzeiler auf der Bash um ein komplettes Dateisystemabbild auf einen anderen Rechner zu schieben? Kein Problem!

Auf dem Quellsystem ist nicht viel zu beachten. Es muss halt einen Snapshot geben, welchen man herüber schieben will. Den zu erstellen ist ja kein Problem 😛 Auf dem Zielsystem ist genau so wenig zu beachten. der SSH-Loginuser muss halt das Recht haben ein neues ZFS-Volume anzulegen.

Ich teste ja mit Openindiana, für einen Test erlaube ich dann mal auf der Openindianakiste den root Login per ssh:

### enable root ssh login ###
$ rolemod -K type=normal root

$ cat /etc/ssh/sshd_config |grep PermitRootLogin
PermitRootLogin yes

Nun lege ich noch schnell einen ZFS Pool an in welchem ich die Daten gerne liegen hätte:

$ zpool create backup c2d1p0
$ zpool list backup
NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
backup  74,5G   132K  74,5G     0%  1.00x  ONLINE  -

Schon kann es los gehen. Mit folgendem Befehl stoße ich nun also auf meinem Quellsystem die „Kopie“ an:

$ zfs send wurstpelle/bernd@Test-snapshot | ssh root@xxxx:xxxx:8001:0:2e0:4cff:feee:8adb zfs recv backup/daten-ziel@Test-snapshot>
Password:

Fertig? Joar, nun schaue ich mal ob alles angekommen ist:

$ zpool list backup
NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
backup  74,5G  1001M  73,5G     1%  1.00x  ONLINE  -

$ ls -l /backup/
total 2
drwxr-xr-x 2 root root 12 2011-10-31 15:22 daten-ziel

$ ls -lh /backup/daten-ziel/
total 1001M
-rw-r--r-- 1 root root 100M 2011-10-31 15:21 image01.img
-rw-r--r-- 1 root root 100M 2011-10-31 15:21 image02.img
-rw-r--r-- 1 root root 100M 2011-10-31 15:21 image03.img
-rw-r--r-- 1 root root 100M 2011-10-31 15:22 image04.img
-rw-r--r-- 1 root root 100M 2011-10-31 15:22 image05.img
-rw-r--r-- 1 root root 100M 2011-10-31 15:22 image06.img
-rw-r--r-- 1 root root 100M 2011-10-31 15:22 image07.img
-rw-r--r-- 1 root root 100M 2011-10-31 15:22 image08.img
-rw-r--r-- 1 root root 100M 2011-10-31 15:22 image09.img
-rw-r--r-- 1 root root 100M 2011-10-31 15:22 image10.img

Alles da, alles gut. Nun könnte ich alle 10 Minuten einen Snapshot machen und jeweils den Unterschied der Snapshots auf mein Backupsystem schieben. Damit hätte ich eine genaue Kopie meines Livesystems mit maximal 15 Minuten unterschied. Auf dem Backupsystem könnte ich natürlich genau so Snapshots machen und den Backupstand zusätzlich sicher. Krass oder?

Für den Gnome Dateimanager Nautilus unter Opensolaris basierenden Systemen  gibt es ein ganz nettes Plugin. Den Time Slider… Hier gibt es einen Dienst der alle paar Minuten einen Snapshot vom Sytem macht. Diese werden dann aufgehoben (Stündlich, täglich, wöchentlich, monatlich, jährlich….) Wir die Platte zu voll werden immer die ältesten Snapshots automatisch gelöscht. Durch das Nautilus Plugin kann man dann ganz bequem per GUI durch die Snapshots sliden. Ich habe da mal zwei Screenshots gemacht:

Aber da geht noch mehr… Ich sag nur Solaris boot environment 😀

Macht man ein Update seines Systems, macht der Updater einen Snapshot des root Pools, erstellt davon einen Clone und trägt diesen selbstständig im Grub ein. Dann macht er alle Updates in diesen neuen Pool. Es werden also nicht alle möglichen Dienste während des Updates neu gestartet oder sonstiges Zeugs…. Ist das Update abgeschlossen startet man seine Kiste einfach neu und Bootet in diesen neuen Clone (boot environment). Ein Update ist also in der Zeit eines Reboots erledigt. Ist bei dem Update etwas schief gelaufen, kann man einfach in alte System booten und alles ist wie vor dem Update. Kein Stress mehr, kein Bangen, keine Ausfälle während der Updates.

// Ich kann mich da an Updates auf Linux Servern erinnern, bei denen etwas mit dem Netzwerk oder SSH-Server schief gelaufen ist und man dann zum Server fahren musste (pre IPMI) oder an Windows Server die zwar ihre Updates installieren aber erst nach dem zweiten Reboot wieder (darf man stabil sagen?) stabil laufen. Über die boot environments muss man darüber nicht mehr nachdenken, zumindest bei Solaris und öhm BSD 😛 //

Dabei muss es sich nicht immer um ein Systemupdate handeln. Hin und wieder fummelt man ja gerne in einigen Konfigurationen herum. Warum macht man nicht einfach vor Experimenten ein neues Boot Environment von Hand? Kostet nichts und ist mit einem Befehl erledigt. Verfriemelt man sich, bootet man einfach lächelnd den alten Stand und fertig!

Alles läuft im Grunde über den Befehl beadm….

Was gibt es bisher:

$ beadm list
BE                  Active Mountpoint Space Policy Created
Sebastians-Notebook -      -          36,1M static 2011-10-25 10:49
openindiana         NR     /          11,6G static 2011-09-28 19:06
openindiana-1       -      -          37,3M static 2011-10-27 20:04

Ein neues anlegen:

$ beadm create NAME

Löschen mit destroy… Ach, einfach mal selbst schauen, ist sehr einfach!

ZFS RAID

22. März 2012 / / Keine Kommentare

ZFS RAID

ZFS unterstützt natürlich „RAID“ ein einfacher Mirror ist genau so möglich wie eine Art Raid5 (raidz genannt) oder eine Art Raid6 (raidz2 genannt). Natürlich sind spare Platte kein Problem und Striping ist überhaupt kein Problem.

Ich habe ja bereits einen Pool mit dem Namen backup. Wenn ich aus diesem nun lieber einen Mirror über zwei Platten machen möchte geht das so:

$ zpool attach backup c2d1p0 c3d0p0
Make sure to wait until resilver is done before rebooting.

Wichtig ist hier die richtige Reihenfolge der Platten. Denn man Packt ja der Platte c2d1p0 im Pool backup die Platte c3d0p0 als Spiegel hinzu. Vertauscht man die Platten im Befehlt spiegelt ZFS die leere Platte auf die Datenplatte. Auch ein schöner Mirror, sogar genau wie angegeben aber so leer 😛

Mal angenommen alles wurde richtig angegeben, dann beginnt ZFS nun den Pool zu resilvern. Da es bei ZFS keine Trennung mehr zwischen RAID / Volumemanager bzw. Dateisystem gibt, weiss ZFS genau wo Daten liegen und spiegelt nur diese. Sind nur ein paar GB belegt ist der sync das resilvering schnell durch. Andere Systeme würden hier nun stumpf Block für Block herüber schieben. Egal ob in diesem nun Daten liegen oder nicht. Woher soll dieses auch wissen was das Dateisystem macht? Daher kann es je nach Plattengröße sehr lange dauern.
// Schon mal versucht sechs 3TB Platten eines RAID6 per Linux mdadm nach einem Plattentausch im Betrieb zu resilvern? 10 Stunden sind da nichts, selbst wenn nur 1TB belegt ist… //

Zurück zum backup Pool. Um sich den Status des Pools anzuschauen gebe ich folgendes ein:

$ zpool status backup
pool: backup
state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Mon Oct 31 13:18:13 2011
444M scanned out of 4,04G at 18,5M/s, 0h3m to go
440M resilvered, 10,72% done
config:

NAME        STATE     READ WRITE CKSUM
rpool       ONLINE       0     0     0
mirror-0  ONLINE       0     0     0
c2d1p0  ONLINE       0     0     0
c3d0p0  ONLINE       0     0     0  (resilvering)

errors: No known data errors

Ja das Testsystem ist LANGSAM 😉 ich habe alte Hardware genommen (sehr alte Hardware). Denn noch sieht man das ZFS nur die eigentlichen Daten resilverd. Hier also knapp 4,04GB. Würde es die ganzen 80GB resilvern hätte ich eine längere Kaffeepause! Nach getaner Arbeit schaut es nun so aus:

$ zpool status backup
pool: backup
state: ONLINE
scan: resilvered 4,04G in 0h5m with 0 errors on Mon Oct 31 13:33:00 2011
config:

NAME        STATE     READ WRITE CKSUM
rpool       ONLINE       0     0     0
mirror-0  ONLINE       0     0     0
c2d1p0  ONLINE       0     0     0
c3d0p0  ONLINE       0     0     0

errors: No known data errors

Ein 80GB Mirror in 5 Minuten resilvern und das auf kack Hardware… Schöne Zeit, oder?

Will ich direkt einen Pool als Mirror anlegen geht dieses natürlich mit:

$ zpool create backup mirror c2d1p0 c3d0p0
Make sure to wait until resilver is done before rebooting.

Sind meine Datenplatten gespiegelt ist dieses gut gegen Datenverlust. Fällt eine Systemplatte aus kommen die User denn noch nicht an ihre Daten. Daher macht es Sinn einen root pool zu mirrorn. Das ist nun etwas aufwändiger, vor allem da man ja grub nicht vergessen darf. Denn was bringt einem ein gespiegelter Root Pool, wenn man den ohne Bootmanager nicht booten kann? Ich habe da nun folgendes gemacht…

So schaut der rpool meines Testsystems aus:

$ zpool status rpool
pool: rpool
state: ONLINE
scan: none requested
config:

NAME        STATE     READ WRITE CKSUM
rpool       ONLINE       0     0     0
c2d0s0    ONLINE       0     0     0

errors: No known data errors

Diesen möchte ich nun auf die Platte c2d1s0 spiegeln. Dafür lege ich auf dieser zuerst ein Lable an:

$ format c2d1s0
selecting c2d1s0
NO Alt slice
No defect list found
[disk formatted, no defect list found]
 FORMAT MENU: disk       - select a disk type       - select (define) a disk type partition  - select (define) a partition table Total disk size is 9729 cylinders Cylinder size is 16065 (512 byte) blocks Cylinders Partition   Status    Type          Start   End   Length    % =========   ======    ============  =====   ===   ======   === 1       Active    Solaris2          1  9728    9728    100 SELECT ONE OF THE FOLLOWING: 1. Create a partition 2. Specify the active partition 3. Delete a partition 4. Change between Solaris and Solaris2 Partition IDs 5. Edit/View extended partitions 6. Exit (update disk configuration and exit) 7. Cancel (exit without updating disk configuration) Enter Selection: 6 format> quit

Nun die Partitionseinstellungen der s2 von der Hauptplatte auf die zweite Platte übernehmen:

$ prtvtoc /dev/rdsk/c2d0s2 | fmthard -s - /dev/rdsk/c2d1s2
fmthard:  New volume table of contents now in place.

Dann die zweite Platte dem Pool als mirror hinzuzwingen:

$ zpool attach -f rpool c2d0s0 c2d1s0
Make sure to wait until resilver is done before rebooting.

Damit sollte der rootpool gespiegelt sein. Nun fehlt noch der Bootmanager grub auf der zweiten Platte.

$ installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c2d1s0
stage2 written to partition 0, 275 sectors starting at 50 (abs 16115)
stage1 written to partition 0 sector 0 (abs 16065)

Fertig….

Jetzt reiße ich einfach mal die eigentliche Hauptplatte aus dem Testsystem und starte die Kiste neu. Nach ordentlichem Boot (muuaaahhhhrrrr) schaue ich mal den Status des Pools an:

$ zpool status
pool: rpool
state: DEGRADED
status: One or more devices could not be used because the label is missing or
invalid.  Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-4J
scan: scrub in progress since Mon Oct 31 13:47:29 2011
17,8M scanned out of 4,06G at 261K/s, 4h30m to go
0 repaired, 0,43% done
config:

NAME        STATE     READ WRITE CKSUM
rpool       DEGRADED     0     0     0
mirror-0  DEGRADED     0     0     0
c2d0s0  FAULTED      0     0     0  corrupted data
c2d1s0  ONLINE       0     0     0

errors: No known data errors

Passt und funktioniert also wie gewünscht. Weiter gehts!

ZFS compression

22. März 2012 / / Keine Kommentare

ZFS compression und deduplication

Bei Kompression auf Dateisystemebene denken viele direkt an die Implementierung von Microsoft. Mit dem gleichen Gedanken kommt oft ein *UAARRGGGSSS*. Microsoft Kisten mit eingeschalteter Komprimierung sind alles nur nicht mehr performant, es lässt sich kaum Software auf so einer Platte betreiben und man hat schneller Dateisystemfehler als man meep sagen kann. Niemand will das wirklich einschalten! Bei ZFS ist das etwas anders. Natürlich benötigt das komprimieren Systemressourcen und Datenrettungen werden um einiges Aufwändiger…. Bei heutigen CPUs merkt man kaum etwas davon, dass die CPU nun noch den Stream zur Platte komprimieren muss. Diese Funktion bringen viele CPUs schon in Hardware mit. Die CPU ist hier selten das langsamste Gliet in der Kette. Da ist viel eher die Festplatte der Flaschenhals. Mit einer neueren CPU wird es mit eingeschalteter Komprimierung eher schneller als langsamer. Warum? Na, wenn weniger Daten von der Platte gelesen bzw. weniger Daten auf die Platte geschrieben werden müssen, bringt einem das nicht nur mehr Platz auf dem Datenträger sondern zusätzlich noch weniger IOs 😀 Kompression ist also gut, sofern man nicht gerade eine alte Celeron CPU verbaut hat. Zusätzlich werden nicht beim aktivieren stumpf alle Daten komprimiert. Nein, bei aktivierter Komprimierung werden nur die Daten komprimiert abgelegt, welche in diesem Moment geschrieben werden. Schaltet man die Komprimierung wieder ab werden die neuen Daten wieder unkomprimiert gespeichert.Natürlich kann weiterhin aus jedem Zustand auf alle Daten zugegriffen werden. Will man also mal eben viele Daten ablegen / zwischenspeichern könnte man nur dafür kurz die Komprimierung aktivieren.

Dedublication also dedublizierung ist noch so ein extrem cooles Spielzeug. Ist dieses aktiviert werden einmal gespeicherte Blöcke nicht noch einmal auf der Platte gespeichert. Es wird nur hinterlegt wo man die Daten findet. Hat man also auf dem Store virtuelle Maschinen liegen hat man schnell einige gleiche Blöcke. Das kann richtig Platz sparen. Ist der Store als Fileserver oder ähnliches in einem Unternehmen kann man ebenso Platz sparen. Arbeiten viele User an bzw. mit den gleichen Dingen, taucht ein und das gleiche Dokument an den verschiedensten Stellen auf. Egal ob man nun einen Sharepoint-Server oder ähnliches einsetzt oder das ganze nur an einem Ort liegen soll.User sind halt User. Versionierung in der Entwicklung… Hier wird oft mal eine Kopie des alten Baumes angelegt um eine neue Version zu starten.
// Da gibt es bei einem Kunden meines Arbeitgebers einen Administrator. Dieser betreut eine nicht ganz unwichtige Software. Vor jedem Update das er einspielt legt er immer eine Kopie des Programmordners an, jeweils 2 GB… Diese Kopien liegen dann gerne mal noch 2 – 3 weitere Updates herum. Selbst wenn bei einem solchen Update nur 4 – 5 ini Einträge und zwei 500kb exe Dateien getauscht werden. Mit aktivierter dedubplication verbraucht eine solche Kopie nicht mehr 2GB sondern nur noch die Menge der Änderungen 10 MB…. Also soll dieser beratungsresistente Admin seine Kopien machen! 😀 //

Als kleinen Test habe ich Openindiana auf zwei baugleichen Rechnern mit gleichen Einstellungen installiert. Einmal habe ich vor der Installation compression und deduplication aktiviert einmal nicht.

Sobald die Openindianainstallation den zfs Pool (default rpool) angelegt hat führte ich in einer Konsole der LiveDVD folgendes aus:

$ sudo -s
$ zfs set compression=on rpool && zfs set dedup=on rpool

Dann lies ich die Installation ganz normal durchlaufen und habe die Kiste nach der Installation neu gestartet. Direkt nach der Anmeldung des frischen Systems habe ich mir angeschaut was an Daten auf der Platte gelandet ist. Ach ja, die Installation mit compression und deduplication (deduplication konnte hier ja noch nicht richtig ausgespielt werden, belegt nur schon mal Platz im RAM :-P) hat ca. 30 Sekunden länger gedauert….

Als erstes lasse ich mir mal den Komprimierungsgrat ausgeben:

$ zfs get compressratio rpool
NAME   PROPERTY       VALUE  SOURCE
rpool  compressratio  1.52x  -

1.52…. Da müsste ich ja fast die Hälfte an Platz gespart haben! Mal schauen was die deduplication gemacht hat:

$ zpool get dedupratio rpool
NAME   PROPERTY    VALUE  SOURCE
rpool  dedupratio  1.01x  -

Wie zu erwarten nicht _SO_ viel. Es gibt bei der Installation halt kaum doppelte Daten. Denn noch  ist es ein ganz guter Test, denn mit aktivierter deduplication laufen die ganzen Routinen schon mal mit und man sieht wie schnell oder langsam es ist! Schauen wir mal was nun wirklich auf der Platte an Platz verbraucht wurde:

$ zpool list
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
rpool    74G  2,59G  71,4G     3%  1.01x  ONLINE  -

2,59GB für die Grundinstallation mit aktivierter compression und deduplication. Mal schauen was ohne diese beiden Funktionen auf der Platte landet:

$ zpool list
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
rpool    74G  3,93G  70,1G     5%  1.00x  ONLINE  -

Joar das kann sich sehen lassen, oder? Mit entsprechend viel RAM holt man bei eingeschalteter deduplication natürlich eher mehr als weniger Leistung aus deinem Store. Denn jeder Block der nicht geschrieben werden muss lässt der Platte Luft einen anderen Block zu schreiben 😀

Noch etwas zu ZFS compression. Man sollte natürlich darüber nachdenken für welches Volume man die Komprimieren nun einschaltet und für welches nicht. Denn ein Volume auf welchem bereits komprimierte Daten wie Videos, Bilder oder ähnliches abgelegt werden, da wird zfs compression nichts bringen. Es macht es maximal langsamer! Bei Logfiles sieht es natürlich anders aus.
Jetzt lassen sich die Optionen der Komprimierung aber noch etwas genauer anpassen. Mit einem einfachen: zfs set compression=on zfs Datenset greifen die standard Einstellungen. Zur Komprimierung wird gzip verwendet und zwar mit dem compression level 6. Möchte man nun einen höheren Komprimierungslevel haben, zum Beispiel das Maximum 9. Setzt man es wie folgt:

$ zfs set compression=gzip-9 home/kernel/textdokumente
$ zfs get compression home/kernel/textdokumente
NAME PROPERTY VALUE SOURCE
home/kernel/textdokumente compression gzip-9 local

Ebenso lässt sich auf einen anderen Algorithmus wechseln:

$ zfs set compression=zle home/kernel/textdokumente
$ zfs get compression home/kernel/textdokumente
NAME PROPERTY VALUE SOURCE
home/kernel/textdokumente compression zle local

Umso stärker die Komprimierung umso mehr CPU Zeit geht für die Berechnung drauf. Ob es jetzt beim default level 6 bleibt oder man auf 9 wechselt, dieses hat in meiner Praxis kaum einen Unterschied gemacht. Als Algorithmus zle zu nutzen macht die Sache etwas schneller, verschlechtert den Komprimierungsgrad aber deutlich. Dieses kann ich mit einem gzip-1 fast ebenfalls erreichen! Was man sich vielleicht noch einmal genauer anschauen sollte ist lzjb oder LZ4….

Es bleibt daher, wie so oft, zu bewerten was wohl in der aktuellen Situation das Beste ist!

….und noch was zu ZFS Deduplication!
Hier bitte ebenfalls darüber nachdenken ob und für welches Volume es sinnvoll ist. Deduplication sorgt zwar für Platz und Ruhe auf den Platten. Verbrennt dafür RAM und CPU Zeit!
Im Standard sorgt folgendes:

$ zfs set dedup=on home/kernel/vorlagen
$ zfs get dedup home/kernel/vorlagen
NAME PROPERTY VALUE SOURCE
home/kernel/vorlagen dedup on local

..dafür dass bei jedem zu schreibenden Block eine sha256 Checksumme erstellt wird und wenn die gleich ist mit einem bereits geschriebenen Block wird er nicht geschrieben, sondern es gibt nur eine Art Verweiß auf den bereits geschriebenen. Dieses bedeutet nun aber dass es bei einem von 2\^-256 Blöcken zu einer gleichen Checksumme kommen kann auch wenn die Daten unterschiedlich sind. Wer hier eine höhere Sicherheit haben möchte kann mit einem:

$ zfs set dedup=sha256,verify home/kernel/vorlagen
$ zfs get dedup home/kernel/vorlagen
NAME PROPERTY VALUE SOURCE
home/kernel/vorlagen dedup sha256,verify local

..dafür sorgen, dass bei einer gleichen Checksumme ein Byte-für-Byte Vergleich der Daten gemacht wird. Damit kommt man dann auch diesem Fall auf die Schliche! Ebenso lassen sich hier wieder andere Algorithmen als sha256 einsetzten. fletcher2 oder fletcher4… Gefühlt bringt hier flechter4 zusammen mit verify etwas mehr Performance. Ich bleibe derzeit denn noch lieber bei sha256!

B.t.w.: fletcher4 habe ich unter BSD und Linux Implementierungen schon ein paar mal vermisst. Ob ich hier nur auf eine „alte“ ZFS Version reingefallen bin?

ZFS Pool

22. März 2012 / / Keine Kommentare

Erstellen eines ZFS Pools und Dateisystem

Das erstellen eines neuen Pools ist schnell und sehr einfach erledigt. Im Grunde muss man sich zur Administration von ZFS zwei Befehle merken. zpool wenn etwas mit dem Pool passieren soll und zfs wenn etwas mit dem Volume „Dateisystem“ passieren soll.

Folgender Befehl legt nun den neuen Pool backup an, c2d1p0 ist dabei das verwendete Device, sprich Festplatte. Man könnte hier auch ein File angeben!

$ zpool create backup c2d1p0

ZFS denkt sich bei dem c2d1p0 schon das wir eine Festplatte meinen und ergänzt selbständig /dev/rdsk… ZFS denkt sich zudem das wir wohl Daten im Pool speichern wollen und legt im Pool direkt ein gleichnamiges Volume an. Um dort Daten speichern zu können muss es natürlich gemountet werden. Dieses ist ZFS klar und deswegen hängt es alles gleich unter dem root „/“ ein. Selbstverständlich lassen sich alle diese Dinge (und viele mehr) per Option beim anlegen steuern.

Nun schauen wir uns mal an was ZFS gemacht hat:

$ zpool list backup
NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
backup  74,5G   132K  74,5G     0%  1.00x  ONLINE  -

Schaut gut aus, wir könnten jetzt sofort Daten dort speichern…. Mal angenommen der Pool backup wäre nun auf einer USB-Wechselfestplatte oder einem USB-Stick. Dann könnte man diesen „aushängen“ mit:

$ zpool export backup

An jedem anderen System ließe er sich wieder einbinden mit:

$ zpool import backup

Dieses funktioniert natürlich mit jedem anderen Pool genau so!

cifs01

Solaris CIFS-Server mit ZFS: SMB-Freigaben einfach einrichten​

20. März 2012 / / Keine Kommentare

Der OpenSolaris fork Openindiana und SMB CIFS Share mit ZFS

Man hat bei Solaris über CIFS die Möglichkeit die Berechtigungsstruckturen von Microsoft Windows Systemen zusetzten. Ich meine damit, man macht eine Freigabe und kann dann die Datei- und Ordnerberechtigungen auf dieser Freigabe mit seinem Windows Client genau so bearbeiten und setzten, als wenn diese auf einem anderen Windows System liegen. Man hat sogar die Möglichkeit sein Solaris System ins Active Directory seiners ADS zu buchen und dieses zur Rechtevergabe zu nutzen! Ja, ich finde es auch geil 🙂

Hier möchte ich nun einmal in einem kleinen Beispiel beschreiben wie man einen einfachen Share für diesen Zweck aufbaut und wie man die Berechtigungen setzt.

Als Ausgangssystem nehme ich ein OpenIndiana in der Version oi_151a2 und mit lokalen Benutzeraccounts. Wenn ich Zeit finde mache ich noch ein Update mit Active Directory Integration…

Damit ich bei meinen „Spielchen“ Mist bauen darf, erstelle ich mir vor solchen Arbeiten immer ein neues Boot Environment:

$ beadm create vor-cifs-test
Created successfully

Jetzt kann schon mal nicht mehr viel schief gehen!

Wir brauchen natürlich noch den kernelbasierten Teil des CIFS Server für Solaris, dieser installiert sich wie folgt fast von alleine:

$ pkg install storage-server
               Zu installierende Pakete:    19
           Startumgebung erstellen:  Nein
               Neu zu startende Dienste:     1
DOWNLOAD                                PAKETE     DATEIEN ÜBERTRAGUNG (MB)
Completed                                19/19     750/750    47.9/47.9

PHASE                                       AKTIONEN
Installationsphase                         1498/1498

PHASE                                       ELEMENTE
Paketstatus-Aktualisierungsphase               19/19
Abbildstatus-Aktualisierungsphase                2/2

Jetzt sind nun nicht nur die Grundlagen für den CIFS Samba Server gelegt sondern auch für alle anderen denkbaren Storage Ideen 🙂

So dann werfen wir mal die Riemen auf den Samba Server:

$ svcadm enable -r smb/server
$ svcadm start network/smb/server:default

Kurze Kontrolle ob alles läuft:

$ svcs |grep smb
online         14:32:45 svc:/network/smb/client:default
online         14:32:46 svc:/network/shares/group:smb
online         14:33:03 svc:/network/smb/server:default

Perfekt, weiter gehts! Damit unsere Windosen die Kiste schneller und einfach finden buchen wir sie noch in eine Workgroup:

$ smbadm join -w KERNEL-TEST
After joining KERNEL-TEST the smb service will be restarted automatically.
Would you like to continue? [no]: yes
Successfully joined KERNEL-TEST

Samba-Server reboot tut nun gut:

$ svcadm restart network/smb/server:default

Damit normale Systembenutzer auch smb Kennwörter bekommen muss pam_smb_passwd aktiviert werden. Dazu muss folgendes in der Datei /etc/pam.conf ergänzt werden:

other password required pam_smb_passwd.so.1 nowarn
# echo "other password required pam_smb_passwd.so.1 nowarn" >> /etc/pam.conf

Setzt man nun seinem Benutzer ein neues Kennwort, bekommt er zusätzlich auch sein smb Kennwort.

$ passwd benutzername

Ich habe bereits einen einfachen Datenpool, daher richte ich auf diesem nur noch ein weiteres ZFS Filesystem ein, welches ich später freigeben möchte.

Microsoft unterscheidet normalerweise nicht zwischen Groß- und Kleinschreibung auf Dateisystemebene. Dieses beachte ich natürlich beim Anlegen vom neuen ZFS Filesystem. Sollte man später das gleiche Filesystem noch per NFS freigeben wollen, sollte man das „non-blocking mandatory locking“ aktivieren. Dieses beachte ich natürlich auch direkt beim erstellen des Filesystems. Dieses schaut nun also so aus:

$ zfs create -o casesensitivity=mixed -o nbmand=on fileserver/daten

Jetzt kann ich dieses Filesystem schon freigeben, dieses möchte ich unter dem Namen „DatenShare“ tun. Eine kurze Beschreibung der Freigabe darf natürlich nicht fehlen:

$ zfs set "sharesmb=name=DatenShare,description=Der Testdaten Share" fileserver/daten

Dann legen wir einen Testbenutzer an und vergeben ein Kennwort:

$ useradd -g cifsshare -s /bin/false -c TestUser -m test
$ passwd test
New Password:
Re-enter new Password:
passwd: password successfully changed for test

Nun sorgen wir mit folgendem Befehl dafür das unser neues ZFS Filesystem diesem Benutzer gehört:

$ chown -R test:cifsshare /fileserver/daten

Damit am Ende alle Berechtigungen vererbt werden benötigen wir folgendes:

$ zfs set aclinherit=passthrough fileserver/daten
$ zfs set aclmode=passthrough fileserver/daten

Jetzt wird es spannend! Mit folgendem Befehl (diese geht über mehrere Zeilen) vergeben alle Rechte für: Alle Benutzer, Alle Gruppen, Jeden

Zur Verdeutlichung und als Test sicher erst mal gut.

/usr/bin/chmod A=\
owner@:rwxpdDaARWcCos:fd-----:allow,\
group@:rwxpdDaARWcCos:fd-----:allow,\
everyone@:rwxpdDaARWcCos:fd-----:allow \
/fileserver/daten

Hier sollte man darauf achten, wirklich das Solaris chown zu nutzen. Denn das GNU chown versteht die Optionen nicht.

$ which chown
/usr/bin/chown

Jetzt können wir mal testen auf den Share zuzugreifen und Rechte zu setzen (Windows booten….. *schnarch*)!

 

cifs01
cifs02
cifs03

 

cifs04
cifs05
cifs06

 

 

 

Damit es mit dem Vererben der Berechtigungen deutlicher wird erstelle ich noch einen zweiten Share:

$ chown -R test:cifsshare /fileserver/daten
$ zfs create -o casesensitivity=mixed -o nbmand=on fileserver/daten2
$ zfs set "sharesmb=name=DatenShare2,description=Der Testdaten Share 2" fileserver/daten2
$ chown -R test:cifsshare /fileserver/daten2
/usr/bin/chmod A=\
owner@:rwxpdDaARWcCos:fd-----:allow,\
group@:rwxpdDaARWcCos:fd-----:allow,\
everyone@:rwxpdDaARWcCos:fd-----:allow \
/fileserver/daten2

Die erweiterten ACLs lassen sich natürlich ebenfalls auf Systemebene anzeigen, hier muss man auch das Solaris ls nutzen:

$ cd /fileserver/daten
$ ls -V
total 4373
-rwxrwxrwx+  1 test     cifsshare  345088 Nov 20  2010 cmd.exe
                 owner@:rwxpdDaARWcCos:------I:allow
                 group@:rwxpdDaARWcCos:------I:allow
              everyone@:rwxpdDaARWcCos:------I:allow
drwxrwxrwx+  2 test     cifsshare      12 Mär 22 17:39 de-DE
                 owner@:rwxpdDaARWcCos:fd----I:allow
                 group@:rwxpdDaARWcCos:fd----I:allow
              everyone@:rwxpdDaARWcCos:fd----I:allow
drwxrwxrwx+  5 test     cifsshare       5 Mär 22 17:39 diagnostics
                 owner@:rwxpdDaARWcCos:fd----I:allow
                 group@:rwxpdDaARWcCos:fd----I:allow
              everyone@:rwxpdDaARWcCos:fd----I:allow
drwxrwxrwx+  2 test     cifsshare       2 Mär 22 17:38 TestOrdner
                 owner@:rwxpdDaARWcCos:fd----I:allow
                 group@:rwxpdDaARWcCos:fd----I:allow
              everyone@:rwxpdDaARWcCos:fd----I:allow
-rwxrwxrwx+  1 test     cifsshare 1733554 Mär 22 16:37 winrar-x64-411d.exe
                 owner@:rwxpdDaARWcCos:------I:allow
                 group@:rwxpdDaARWcCos:------I:allow
              everyone@:rwxpdDaARWcCos:------I:allow

Es lassen sich nun also die Berechtigungen vom Windows Client aus setzten.

Solaris Boot Environment
Solaris Boot Environment

Solaris Boot Environment

15. Februar 2012 / / Keine Kommentare

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..

Solaris Boot Environment

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?“

Solaris ZFS

13. Oktober 2011 / / Keine Kommentare

Der OpenSolaris fork Openindiana und ZFS, das beste Filesystem wo gibt von ganze Welt.

Das ZFS derzeit das geilste Filesystem überhaupt ist, muss ich ja keinem mehr sagen. Aber ich möchte 😀 Boar ist das GEIL!

Zurück zum Thema und damit zu ein paar technischen Eckdaten

Wortlänge 128 Bit (wer noch die letzten Zahlen in Sachen IPv6 im Kopf hat, der hat eine Ahnung von 128Bit Zahlen :D)
Volumemanager Integriert (im groben weiss das Dateisystem was die Platten machen und umgekehrt)
Ausfallsicherheit RAID 1, RAID-Z1 (1 Parity-Bit, ~RAID 5), RAID-Z2 (2 Parity-Bits, ~RAID 6) und RAID-Z3 (3 Parity-Bits) integriert
maximale Größe des Dateisystems 16 exbi Byte (= 16 × 260 Byte)
maximale Größe jedes Pools 3 × 1023 pebi Byte (ca. 2 × 1038 Byte)
maximale Anzahl an Dateien in einem Verzeichnis 248
maximale Anzahl an Geräten im Pool 264
maximale Anzahl an Dateisystemen im Pool 264
maximale Anzahl an Pools im System 264

Wenn man nun mal von den irren Maximalwerten absieht, was genau ist denn jetzt so neu? Tja, grob betrachtet kaum etwas… Snapshots gibt es schon, vergrößerbare Dateisysteme auch, Verschlüsselung gibt es schon lange, Raid ist ebenso ein alter Hut, Snapshots sind alles andere als neu usw. usw.. Das aber alles zusammen kombiniert wird, das ist hier das Neue 😀

Die Kombi? Japp… Als kleines Beispiel: Normalerweise ist es bei einem Raidverbund so, dass sich der Raidcontroller bzw. ein paar Softwarestücke (beim Softwareraid) um die Platten kümmen. Der eigentliche Raidverbund hat keine Ahnung Ob Daten auf den Platten liegen. Nicht einmal ob es überhaupt ein Dateisystem oder gar eine Partitionstabelle gibt ist ihm bewusst. Soll jetzt z.B.: alle Platte durchgesync (resilvered) werden, muss das Byte für Byte passieren, egal wieviel von den Platten nun wirklich belegt ist. Ob nun 2TB oder halt nur 1kb auf dem Raidverbund liegt. Das Resilvering dauert die gleiche Zeit (ewig). Das wäre beim ZFS anders, denn ZFS weiss genau welche Daten wo liegen. Somit müssen nur die Teile mit Daten syncronisiert werden.

ZFS unterstützt einfaches Striping, einen Mirror, Raid5 (raidz), Raid6(raidz2) und natürlich Spares. In Sachen Datensicherheit ist das aber noch lange nicht alles…. ZFS verbessert selbst die Datensicherheit bei einzelnen Festplatten. Dafür gibt es Ditto Blöcke…. Wird dieses aktiviert, werden für jeden logischen Block bis zu drei physische Blöcke auf der Platte verteilt. Das verschwendet zwar echt Platz auf der Platte, erhöht dafür die Chance selbst bei einer def. Platte Daten rekonstruieren zu können extrem.

Macht ein Festplattenkontroller nicht was er soll oder ein Kabel hat einen def. kann es zu extrem dummen Fehlern kommen oder gar zu Silent Data Corruption (leisem/unbemerktem Datenverlusst). Das bedeutet: Die eigentlichen Daten auf der Festplatte werden stellenweise unbrauchbar. Das merkt man aber erst wenn man versucht auf diese Daten zuzugreifen. Selbst ein Dateisystemscan kann fehlerfrei durchlaufen, denn noch sind die Daten im Eimer. ZFS bietet hier nicht nur die einfache Möglichkeit von Blöcken Checksummen zu bilden, nein es integriert Hash Trees. So können Checksummen in einer Baumstrucktur erstellt werden und es können z.B. sogar versehentlich überschriebene Blöcke erkannt werden. Diese Probleme löst ZFS dann, wenn möglich schon automatisch. Sind Daten gespiegelt kann so direkt festgestellt werden, auf welcher Platte def. Daten liegen. Das ZFS unter anderem dieses kann gilt es als selbstheilendes Dateisystem.

Nach offizieller Aussage soll man ein ZFS Dateisystem nicht kaputt bekommen (es sei denn man schlägt mit dem Hammer drauf :-P). Dateisysteme wie NTFS, ext3, xfs usw…. benutzten journaling um zu erledigende Aufgaben bzw. Aufgaben die noch anstehen zu protokollieren. ZFS arbeitet da eher wie moderne Datenbanksysteme. Es nutzt das ZFS Intent Log… Dort wird genau aufgeführt was ZFS nun gerade vor hat und im Falle eine Stromausfalles oder ähnlich kann ZFS dort ganz genau nachvollziehen was passieren sollte. Für alle Fälle gibt es natürlich die Möglichkeit sein Dateisystem zu überprüfen. Dieses nennt sich unter ZFS scrubbing (total lustiger aber auch passender Begriff, oder?).

Ganz cool ist die Möglichkeit immer und zu jedem Moment Snapshots vom aktuellen Dateisystem anzufertigen. Somit lässt sich immer der aktuelle Zustand einfrieren. Da es zusammen mit Copy on Write läuft, werden im groben die aktuellen Daten einfach so gelassen wie sie sind und erst bei einer Veränderung wird diese einfach an eine andere Stelle geschrieben. Es passiert also nicht das Daten doppelt und dreifach durch einen Snapshot im Pool liegen 🙂

Ich kann nun wenn ich Bock habe einfach auf einen der Snapshots zurück springen, ich kann Snapshots von Hand oder auch per Cronjob erstellen… Von mir aus alle 10 oder 15 Minuten 😀 Ich kann einen Clone aus einem Snapshot erstellen, welcher dann wieder veränderbar ist. Ich kann auch per SSH einen Snapshot auf eine andere Maschine irgendwo auf der Erde schieben und somit meinen ZFS Pool sichern/synconisieren… Dort könnte ich vorher zusätzlich noch einen Snapshot erstellen usw. usw. usw…..

Dieses ist nun nur ein Bruchteil von dem was mit ZFS möglich ist, man sieht jetzt schon schnell was mit ZFS alles möglich ist!

opensolaris solaris openindiana
Openindiana

Openindiana

25. September 2011 / / Keine Kommentare

Der OpenSolaris fork Openindiana

Openindiana ist ein fork von OpenSolaris. OpenSolaris ist wiederum die von SUN unter der CDDL freigegebene Version ihres Betriebssystems Solaris. Seit meiner Ausbildung hänge ich immer irgendwie mit einem Bein im Solaristopf. Ich komme einfach nicht von diesem OS weg. Was wohl daran liegt das ich es auch nicht möchte. Denn es ist ein sehr schönes OS 🙂 Zusätzlich ist der default Unterbau seit längerem schon das Dateisystem ZFS.

opensolaris solaris openindiana

ZFS ist nun schon ein paar Jahre alt, denn noch habe ich bisher noch kein Dateisystem gefunden welches im wirklich das Wasser reichen kann. Hier und da in Detailvergleichen, keine Frage aber

alles in allem „no way“ 🙂 Bei seiner Einführung hat SUN etwas von unkaputtbar erzählt. Titanic lässt grüßen? Auf keinen Fall… Ich habe es noch nicht geschafft ein ZFS zu zerlegen. Egal wie oft der Strom ausfällt oder der Rechner einen Reset bekommt. Ohne Hammer bzw. echten Hardwaredef. läuft das System einfach weiter.

Wie auch immer…. Vor ein paar Tagen ist nun die Entwicklerversion oi_151a erschienen. Die Version 148 war schon viel versprechend. Diese Version lief auch immer im Dualboot neben meinem Gentoo. Da sie denn noch viel Schleifarbeit an vielen Stellen braucht hatte sie eher ein passives leben 🙁

Dieses hat sich jetzt nach einem kurzen Test geändert. Gentoo verschwindet in eine Virtualbox VM auf dem Solarissystem und dann geht es los.

Ich liste in laufe der Zeit mal in einem Untermenü auf was mir so aufgefallen ist bzw. was anderen vielleicht weiterhelfen könnte.

OpenIndiana der fork von OpenSolaris und Solaris? Ja und nein, denn Sun hat sein Verspechen, die OpenSolaris-Entwicklung für die Gemeinschaft zu öffnen, nicht eingehalten hat und da Oracle nach der Übernahme von Sun zunehmend Teilprojekte einstellte, haben Mitglieder der OpenSolaris-Entwickler-Gemeinschaft am 3. August 2010 die Gründung des Projektes Illumos zur Entwicklung eines wirklich freien Open-Source-Solaris bekanntgegeben. OpenIndiana hat nun diese Basis 🙂

Ich hatte auf einer meiner Maschinen ein kleines Problem mit der LiveCD. Diese bliebt beim booten einfach hängen und dieses ohne erkennbaren Grund. Zumindest konnte ich auf den Konsolen nichts erkennen und einen Logfile gibt es so ja erstmal nicht :-/ Bei einem Linux Live System würde man ja nun erstmal Kernel Optionen wie: noacpi / noapic / acpi=off oder so ein Geschlönz probieren, aber hier????

Ich habe im Zusammenhang mit der OpenIndiana LiveDVD ein paar Bugs und Probleme im Zusammenhang mit USB gelesen. Hier scheint das System noch etwas „anfällig“ zu sein 🙁 Wie auch immer nach einigen Tests viel mit nichts besseres mehr ein als einfach den USB-Kontroller im BIOS zu deaktivieren. Nur um das USB-System auszuschließen versteht sich… Tja, was soll ich sagen? USB im BIOS ausschalten und LiveDVD (der OpenIndiana Live USB-Stick ist dann natürlich nutzlos) einlegen. Schon versagen ordnungsgemäß USB-Tastatur und USB-Maus ihren Dienst, OpenIndiana Bootet aber sauber hoch. Spannenderweise erkennt das gebootete System den USB-Kontroller wieder und somit auch Maus, Tastatur oder sonstige USB-Sticks. Dieses Verhalten führte zwar bei mir zu etwas Stirnrunzeln, bringt mir denn noch ein funktionierendes System.

Oracle Solaris 11

Oracle hat Solaris 11 herausgegeben. Im direkten Vergleich zu OpenIndiana gibt es dann doch einige Unterschiede. Vor allem hinsichtlich Zonen, Netzwerk, den erweiterten Möglichkeiten der höheren ZFS Version und noch vieles mehr….

Einiges hier wird sich daher etwas mischen. Auf was es sich jeweils bezieht werde ich jeweils aufführen.

Neuere Beiträge »

© 2025 -=Kernel-Error=-

Theme von Anders Norén — Hoch ↑