Ein Scrub ist die Integritätsprüfung von ZFS — jeder Block im Pool wird gelesen und seine Checksumme verifiziert. Beschädigte Blöcke werden automatisch aus der Redundanz repariert (Mirror oder RAID-Z). Ohne Redundanz erkennt ZFS den Fehler immerhin, kann ihn aber nicht korrigieren.
Empfehlung: Einmal pro Woche oder mindestens einmal im Monat. Auf Produktivsystemen am besten per Cronjob.
Scrub starten
zpool scrub backup
Fortschritt prüfen
zpool status backup
pool: backup
state: ONLINE
scan: scrub in progress since Sun May 27 11:11:00 2012
4.20G scanned out of 74.5G at 102M/s, 0h11m to go
0 repaired, 5.64% done
Scrub abbrechen
Braucht man die I/O-Leistung gerade für etwas anderes:
zpool scrub -s backup
Im Status sieht man dann den Unterschied — stopped statt completed:
# Abgebrochen
scan: scrub stopped after 0h7m with 0 errors on Sun May 27 11:18:52 2012
# Normal beendet
scan: scrub completed after 0h7m with 0 errors on Sun May 26 10:52:13 2012
Ein abgebrochener Scrub setzt beim nächsten Start nicht dort fort, sondern beginnt von vorne.
Scrub per Cronjob
# Jeden Sonntag um 02:00 alle Pools scrubben
0 2 * * 0 /sbin/zpool scrub backup
Unter FreeBSD läuft der Scrub standardmäßig über periodic daily — dort muss man nichts extra einrichten. Unter Linux gibt es je nach Distribution einen systemd-Timer (zfs-scrub-weekly.timer) oder man legt den Cronjob selbst an.
Warum vergessen nur immer alle die DNS Informationen zu ihrem neuen Jabber-Server zu setzten? Ich bin heute sicher zum 12 mal nach einem Problem gefragt worden welches damit zusammen hing. Die Info fehlt aber auch in _fast_ jedem Howto. Kopieren denn wirklich alle nur noch Zeile für Zeile? Als Wikipedia mal einen Tag ausgesetzt hat, konnten tausende keine Hausaufgaben abgeben. Irgendwie habe ich dass Gefühl, wenn Google mal einen Tag aussetzten würde könnten tausende „Admins“ nichts installieren oder Probleme lösen ;-P
Also um es noch mal in Google zu werfen:
Damit die Kommunikation zwischen den Jabber-Server sauber läuft müssen die nötigen DNS Records vorhanden sein. Für meinen Bind schaut es so aus wie im folgenden Beispiel:
_jabber._tcp.jabber.kernel-error.de. IN SRV 0 0 5269 jabber.kernel-error.de.
_xmpp-server._tcp.jabber.kernel-error.de. IN SRV 0 0 5269 jabber.kernel-error.de.
_xmpp-client._tcp.jabber.kernel-error.de. IN SRV 0 0 5222 jabber.kernel-error.de.
Testen lässt sich dieses am Ende natürlich mit dig:
Veraltet: OpenIndiana und Solaris werden kaum noch als Desktop eingesetzt. Unter Linux gibt es zahlreiche RSS-Reader (Thunderbird, Liferea, Newsboat).
Ich habe gerade meinen lieblings RSS-Feed Reader Liferea auf der Solariskiste kompiliert. Ich finde es gibt einfach keinen besseren! Spannenderweise konnte ich auch keinen „fertigen“ finden. Na bis auf Thunderbird…. Aber Thunderbird? So gefällt es mir besser *hüpf*.
Mein Creative ZEN Mozaic lässt sich nur per MTP mit Daten befüllen. Unter Windows kein Problem, unter Linux bringen die meisten Distributionen FUSE-Treiber mit. Solaris und OpenIndiana bringen von Haus aus nichts mit. Die Lösung: gMTP.
gMTP installieren
Das Paket gibt es direkt auf der gMTP-Downloadseite. Auspacken und installieren:
Veraltet: OpenIndiana und Solaris werden kaum noch als Desktop eingesetzt. USB-Kameras und Scanner funktionieren unter Linux mit SANE/XSane problemlos.
Man man man… Jetzt habe ich mich doch tatsächlich 1 Stunde lang in etwas sehr sinnlosem verrannt. *kopfschüttel*
Da will ich mal eben ein Bild mittels xsane von einem USB-Scanner einlesen. Da findet xsane auf dem Solaris 11 System den Scanner nicht. Genau so verhält es sich mit einer USB Digitalkamera….. Ich habe ja überall nachgeschaut, nur wohl ohne Verstand!
Die Lösung war natürlich recht simpel. Einfach mal das Paket: libusbugen installieren. *Narf*
Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. Die hier beschriebene Nagios-Überwachung bezieht sich auf XenServer 6.x/7.x. Wer heute Virtualisierung überwachen will, sollte sich Proxmox VE oder XCP-ng anschauen.
Das folgende habe ich auf den Citrix XenServer in Version 5.6SP2 bis 6.2.0 anwenden können. Im Grunde geht es darum auf dem „freien“ Citrix XenServer nrpe (Nagios Remote Plugin Executor) zu installieren um diesen mit Nagios auf einfache Weise überwachen zu können. Natürlich bietet der Cirtix XenServer ebenfalls die Möglichkeit ihn per SNMP zu überwachen und diese Version zu zu bevorzugen…. Für das eine oder andere Script ist die Ausführung per nrpe denn noch einfacher und schneller umzusetzen, als per snmp. Denn noch bitte beachten… Diese Version ist zwar absolut funktionsfähig und fast gefahrlos für das System, denn noch ist es „hereingefummelt“ und muss nach Versionsupgrade wieder (passend für die jeweilige Version) eingespielt werden. Die eigentliche Nagiosanbindung soll hier nicht Thema sein. Beispiele dazu kann man gerne bei mir erfragen.
So dann wollen wir mal:
Ich habe eine -schlechte- Angewohnheit. Ich erstelle immer gerne im Root das Verzeichnis 001 um dort meine Daten „herum zu würfeln“.
$ mkdir /001
$ cd /001
Im Grunde basiert der Citrix XenServer auf Redhat Linux/Fedora… Also können wir für diesen Fall auch die (Extra Packages for Enterprise Linux) epel nutzen.
So und schon sollten wir die zusätzlichen Pakete nutzen können. In diesen findet sich sinnigerweise auch direkt nrpe, was wir gleich installieren:
$ yum install --enablerepo=epel nrpe
$ chkconfig nrpe on
Das chkconfig nrpe on sorgt dafür dass der Service direkt beim Start des Systems mitgestartet wird. Wichtig ist nun noch die passenden Löcher in die Firewall des XenServers zu schießen. Sonst läuft zwar der Dienst, wir bekommen von außen aber keine Verbindung. Hier muss nur in der folgenden Datei eine Zeile ergänzt werden:
$ nano -w /etc/sysconfig/iptables
…..
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5666 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
….
Damit wären wir schon feritg. Natürlich sollte man nun noch die Nagios Plugins installieren, Programme und Temperaturen von Festplatten oder IPMI auszulesen.
Für IPMI (Intelligent Platform Management Interface) müssen ggf. noch die nötigen Kernelmodule geladen werden:
$ modprobe ipmi_devintf
$ modprobe ipmi_si
Konfigurieren lässt sich nrpe nun wie bekannt über:
$ nano -w /etc/nagios/nrpe.cfg
Die Konfiguration von nrpe und Nagios ist aber unabhängig von der Installation auf dem XenServer.
Ich habe gerade den Hinweis bekommen, dass es helfen könnte wenn ich hier erwähne dass man sich die Nagios Plugins noch zusätzlich installieren muss. Dieses Stimmt natürlich. Ich habe mir mit der Zeit einen Satz recht weit „angepasste“ Nagios Plugins zusammengestellt. Diese schiebe ich mir oft (unter Berücksichtigung der Abhängigkeiten) einfach passend hin und her kopiere. Vielleicht ein Grund warum ich das -vergessen- habe zu erwähnen.
Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. XenServer 8 hat ein anderes Lizenzmodell, Software-RAID wird dort anders gehandhabt. Alternativen: Proxmox VE oder XCP-ng.
Wer die Freie Version des Citrix XenServers einsetzt hat in den meisten Fällen seine virtuellen Maschinen im Local Storage liegen. Natürlich hat ein Hardwareraid für diesen Speicherplatz Vorteile, aber er hat auch Nachteile. Wie man hier dem XenServer nun einen Local Storage auf der Basis eine Softwarraids unterschieben kann, darum geht es hier!
Alle nötigen Schritte lassen sich direkt auf der Konsole des XenServers ausführen und ist vollständig mit Boardmitteln realisierbar. Die Konfiguration überlebt auch jegliche Updates/Upgrades von der Citrix XenServer Version 5.6 bis 6.1.0.
Wir gehen nun mal davon aus, eine 60GB SSD als Systemplatte für den eigentlichen Citrix XenServer zu haben und ein Softwareraid Level 5 aus drei Festplatten bauen zu wollen. Damit hätten wir folgende Konfiguration:
/dev/sda => Systemplatte
/dev/sdb => Erste Festplatte RAID
/dev/sdc => Zweite Festplatte RAID
/dev/sdd => Dritte Festplatte RAID
Die für das Softwareraid vorgesehenen Festplatten sollten natürlich keine Daten enthalten und keine Informationen im MBR (Master Boot Record) haben. Diesen löschen wir also zur Sicherheit mit:
Nun heißt es warten bis das Resilvering durchgelaufen ist. Wie weit es fortgeschritten ist lässt sich so beobachten:
$ watch –n 1 'cat /proc/mdstat'
Natürlich können wir jetzt schon auf das neue Softwareraid Laufwerk zugreifen. Ein Reboot sollte man aber erst nach dem ersten korrekten Resilvering durchführen.
Damit nun der Citrix XenServer Kenntnis von diesem neuen Speicherplatz erzählt, müssen wir es ihm noch „schmackhaft“ machen! Zuerst legen wir auf diesem neuen Laufwerk nun eine Partition vom Type 8E (Linux LVM) an:
$ fdisk /dev/md0
N => neue Partition
T => Type setzten => 8E
W => neue Partitionstabelle auf Platte schreiben
Q => fdisk beenden
Wunderbar. Dann schieben wir es mal dem XenServer unter:
Fertig…. Nun kann man schon im XenCenter den neuen lokalen Speicher RAID-5 finden und nutzen.
Es ist auch möglich dem Citrix XenServer einen lokalen Storage auf dieser Basis unter zu schiebe, der größer ist als 2TB. Dieses geht leider nicht mehr ganz mit Boardmitteln, da fdisk einfach die nötige Struktur nicht mehr anlegen kann. Der eingesetzte Kernel kann es aber sehr wohl ansprechen und verwalten. Hierzu schreibe ich sich später noch mal was..
* U-P-D-A-T-E *
Zusammen mit gdisk lassen sich nun auch GPT Partitionen anlegen.
COMSTAR (Common Multiprotocol SCSI Target) ist das Framework in Solaris/OpenIndiana, das iSCSI, FC und FCoE unter einem Dach vereint. Es ersetzt den alten iSCSI Target Daemon aus Solaris 10. Hier die Einrichtung eines iSCSI-Targets auf Basis eines ZFS-Volumes für einen Windows-Initiator.
ZFS-Volume anlegen
Zuerst einen eigenen Pool und darin ein ZFS-Volume mit fester Größe erstellen — das Volume wird später die LUN:
zpool create iscsi-target-pool c4t2d0
zfs create -V 10g iscsi-target-pool/iscsi_10gb-lun01
zfs list iscsi-target-pool/iscsi_10gb-lun01
NAME USED AVAIL REFER MOUNTPOINT
iscsi-target-pool/iscsi_10gb-lun01 10,3G 19,6G 16K -
Die feste Größe (-V 10g) ist wichtig — sonst würde die Poolgröße das Target begrenzen, und bei mehreren Targets im selben Pool wird es unübersichtlich.
COMSTAR-Dienste starten
Das SCSI Target Mode Framework (STMF) aktivieren:
svcadm enable stmf
svcs stmf
STATE STIME FMRI
online 13:02:50 svc:/system/stmf:default
stmfadm list-state
Operational Status: online
Config Status : initialized
Das iSCSI-Target-Paket installieren und den Dienst starten:
sbdadm create-lu /dev/zvol/rdsk/iscsi-target-pool/iscsi_10gb-lun01
Created the following LU:
GUID DATA SIZE SOURCE
-------------------------------- ------------- ----------------
600144f051c247000000523ed0050001 10737418240 /dev/zvol/rdsk/iscsi-target-pool/iscsi_10gb-lun01
Prüfen ob die LUN online ist:
stmfadm list-lu -v
LU Name : 600144F051C247000000523ED0050001
Operational Status : Online
Provider Name : sbd
Alias : /dev/zvol/rdsk/iscsi-target-pool/iscsi_10gb-lun01
Data File : /dev/zvol/rdsk/iscsi-target-pool/iscsi_10gb-lun01
Size : 10737418240
Block Size : 512
Damit der Initiator die LUN sehen kann, einen View erstellen:
stmfadm add-view 600144F051C247000000523ED0050001
stmfadm list-view -l 600144F051C247000000523ED0050001
View Entry: 0
Host group : All
Target group : All
LUN : 0
iSCSI-Target anlegen
Zwischenstand:
STMF und iSCSI-Target-Dienst laufen
10 GB ZFS-Volume als LUN angelegt
View erstellt, damit Initiatoren die LUN sehen
Fehlt noch das Target selbst:
itadm create-target
Target iqn.2010-09.org.openindiana:02:6c3939bf-f5e5-4f28-a8d0-d0f0bbb2e1c4 successfully created
itadm list-target -v
TARGET NAME STATE SESSIONS
iqn.2010-09.org.openindiana:02:6c3939bf-f5e5-4f28-a8d0-d0f0bbb2e1c4 online 0
alias: -
auth: none (defaults)
targetchapuser: -
targetchapsecret: unset
tpg-tags: default
Zum Schluss sicherstellen, dass das Target im Discovery auftaucht:
devfsadm -i iscsi
Windows-Initiator verbinden
Auf der Windows-Seite den eingebauten Microsoft iSCSI-Initiator öffnen (ab Windows 7 vorinstalliert):
Portal über die IP-Adresse des OpenIndiana-Hosts ermitteln lassen
Das Ziel suchen und verbinden
Die neue Festplatte in der Datenträgerverwaltung initialisieren und ein Volume erstellen
Hinweis: Dieser Artikel beschreibt SMB-Freigaben mit dem eingebauten SMB-Server von Solaris/OpenIndiana. Unter FreeBSD und Linux nutzt man stattdessen Samba — dort wird sharesmb nicht unterstützt.
SMB-Server einrichten
Die SMB Server Kernel-Komponenten installieren:
pkg install SUNWsmbskr
Damit lokale Benutzer sich per Benutzername und Passwort authentifizieren können, das PAM-Modul in /etc/pam.conf eintragen:
other password required pam_smb_passwd.so.1 nowarn
smbadm join -w WORKGROUP
After joining WORKGROUP the smb service will be restarted automatically.
Would you like to continue? [no]: yes
Successfully joined WORKGROUP
ZFS-Freigabe erstellen
Ein neues ZFS-Dataset anlegen und direkt per SMB freigeben — ein einziges Property reicht:
zfs create rpool/daten-freigabe
zfs set sharesmb=on rpool/daten-freigabe
zfs get sharesmb rpool/daten-freigabe
NAME PROPERTY VALUE SOURCE
rpool/daten-freigabe sharesmb on local
Das war es. Das Dataset ist jetzt als SMB-Share im Netzwerk sichtbar. Kein Samba, keine smb.conf — der Kernel-SMB-Server von Solaris arbeitet direkt mit ZFS zusammen. Alle ZFS-Features (Snapshots, Compression, Quotas) gelten für die Freigabe genauso wie für jedes andere Dataset.
Zugriff
Von einem Windows-Client aus die Freigabe über \\hostname\daten-freigabe erreichen. Die Authentifizierung läuft über die lokalen Unix-Benutzer — das PAM-Modul synchronisiert die Passwörter automatisch.
ZFS bringt NFS-Freigaben als eingebaute Funktion mit — kein separater NFS-Server nötig, ein einziges Property reicht. Das funktioniert unter Solaris, OpenIndiana und teilweise auch unter FreeBSD.
NFS-Freigabe erstellen
Dataset anlegen und per NFS freigeben:
zfs create rpool/daten
zfs set sharenfs=on rpool/daten
zfs get sharenfs rpool/daten
NAME PROPERTY VALUE SOURCE
rpool/daten sharenfs on local
Das war es. Das Dataset ist jetzt per NFS im Netzwerk verfügbar — für alle Clients, ohne Einschränkung.
NFS-Optionen
Statt on lassen sich die üblichen NFS-Optionen direkt im Property angeben — zum Beispiel Zugriff nur für ein bestimmtes Subnetz:
# Nur Lesen/Schreiben für ein Subnetz
zfs set sharenfs="rw=@192.168.1.0/24" rpool/daten
# Nur Lesen für alle, Schreiben für ein Subnetz
zfs set sharenfs="ro,rw=@10.0.0.0/8" rpool/daten
# Freigabe prüfen
share -F nfs
Auf dem Client mounten:
mount -t nfs server:/rpool/daten /mnt/daten
Portabilität
Ein netter Nebeneffekt: ZFS-Properties wandern mit dem Pool. Exportiert man den Pool und importiert ihn auf einem anderen System, ist die NFS-Freigabe sofort wieder aktiv:
# Pool exportieren (z.B. vor dem Umstecken einer USB-Platte)
zpool export nfs-share
# Auf einem anderen System importieren — Share ist sofort da
zpool import nfs-share