Software- OpenMediaVault und Proxmox-Tweaks
Den Fakt, dass sich innerhalb der virtuellen Maschine arbeiten lässt, als wenn es sich um eine normale baremetal Installation handeln würde wollen wir uns beim Review-Center.de NAS zu Nutze machen und OpenMediaVault in einer Gast-VM arbeiten lassen. Dazu muss man zwangsläufig auf die Option einer vollständig virtualisierten Maschine zurückgreifen, da ein LXC-Container leider nicht lauffähig zu bekommen war. Folglich bieten sich wieder zwei Installations-Optionen an: Entweder nutzt man die vorliegende ISO des OMV-Projektes oder installiert OpenMediaVault erneut über den Debian-Paketmanager. Letzteres hätte den Vorteil, dass man statt einem etwas älteren Wheezy-System direkt mit einem aktuellen Jessie und der aktuell in der Beta befindlichen OpenMediaVault Version beginnen kann.
Sollte man sich für erstere Variante entscheiden muss nur das Image von der Website des Projekts geladen werden und unter Storage auf die Proxmox-Node geladen werden. Im Anschluss erstellt man eine normale VM (hierbei am besten sowohl beim Datenträger, als auch bei der Ethernet-Schnittstelle den virtIO-Treiber wählen) und binden als Disk-Image das OMV-Image ein. Im Anschluss kann die Maschine gebootet werden und OpenMediaVault über den normalen Installer installiert werden. Siehe dazu auch den offiziellen Eintrag im OpenMediaVault-Wiki dazu, der sowohl mit Bildern, als auch mit Text die Installation beschreibt.
Möchte man hingegen mit der zweiten Variante Vorlieb nehmen, so installiert man erst ein Debian und dann wird über die gezeigte Befehlskette das OpenMediaVault-System installiert.
- echo "deb http://packages.openmediavault.org/public erasmus main" > /etc/apt/sources.list.d/openmediavault.list
apt-get update
apt-get install openmediavault-keyring postfix
apt-get update
apt-get install openmediavault
omv-initsystem
In beiden Fällen erhält man im Anschluss ein lauffähiges OMV-System, welches sich so bedienen lässt, als wäre es auf einem normalen NAS installiert wurden. Im Folgenden wollen wir noch einige Tweaks zeigen, die die Nutzung etwas komfortabler gestalten:
Tweak 1: Durchreichen der HDDs aus dem Proxmox-System zur OpenMediaVault-Maschine
Da wir in unserem NAS keine virtuellen HDDs erstellen wollten und ein bestehendes RAID-5 an die OMV-Box weitergeben wollten standen wir vor der Frage, wie man die physikalisch vorhandenen Disks inklusive der Daten an die virtuelle Maschine durchreichen können. Dazu steht im Proxmox-Wiki ein Artikel, der beschreibt wie man physikalische Disks zu einer KVM-Maschine durchreichen kann.
Dazu benötigt man im ersten Schritt die IDs der installieren HDDs. Diese lässt sich mittels des Befehls ls -l /dev/disk/by-id/ erzeugen. Konkret wird dabei beispielsweise der Part "/dev/disk/by-id/ata-ST3000DM001-1CH166_Z1F41BLC" benötigt.
Zum hinzufügen des Datenträgers darf dieser nicht durch die Proxmox-Maschine gemountet sein. Das Hinzufügen erfolgt über die Befehlskette
- qm set 592 -virtio2 /dev/disk/by-id/ata-ST3000DM001-1CH166_Z1F41BLC
update VM 592: -virtio2 /dev/disk/by-id/ata-ST3000DM001-1CH166_Z1F41BLC
Wobei die ID (in diesem Fall 592) durch die reale ID der virtuellen Maschine ersetzt werden muss. Weiterhin muss in virtio2 die 2 durch die reale Anzahl ersetzt werden. In unserem Fall mussten wir folglich die ID 100 und die vier vorhandenen 3TB-Disks wählen, wobei dabei virtio2, virtio3, virtio4 und virtio5 zum Einsatz kamen.
Nach einem Reboot der virtuellen Maschine stehen diese Datenträger nun als virtio-Device zur Verfügung. Die virtuelle Maschine kann direkt auf die vorhandenen Partitionen und Daten der HDDs zugreifen.
Tweak 2: Schlafen legen der System-HDDs, wenn diese längere Zeit nicht benutzt wurden
Weiterhin wollten wir das System etwas optimieren, so dass die Lautstärkebelastung und auch der Stromverbrauch im Dauerbetrieb auf ein Minimum reduziert wird. Dazu bietet es sich an, die HDDs in den Standby zu versetzen, wenn diese nicht gebraucht werden. Dazu liefert Debian das Tool hdparm, welches per apt-get installiert werden kann. Um zu testen, ob hdparm mit den installierten HDDs arbeiten kann bietet es sich an, vorher einige Befehle zu testen. So liefert ein sudo hdparm -C /dev/sdc beispielsweise den Status (Active oder Idle) der HDD /dev/sdc. Tauscht man in dem Befehl den Parameter -C durch ein -y dürfte die HDD hörbar in den Standby schalten. Ein erneutes Aufruf mittels -C dürfte dann "drive state is: standby" liefern.
Sofern diese Befehle auf allen vorhandenen und zu steuernden HDDs funktioniert hat, kann eine entsprechende Konfigurationsdatei für hdparm unter /etc/hdparm.conf erstellt werden. Dabei wird für jede HDD ein Block angelegt
- /dev/disk/by-uuid/4c9dca33-e3e1-4a6a-a7d4-110cdbb4cfbd {
spindown_time = 60
}
Die UUIDs der HDDs lassen sich dabei über sudo blkid ermitteln. Sollte hierbei eine HDD, wie in unserem Fall, nicht auffindbar sein, so kann man im Ordner /dev/disk/by-id/ nach der HDD suchen und den Eintrag statt über die UUID auch über die ID anlegen - beides sollte zu einem eindeutigen Ergebnis führen.
Bei der Wahl der Spindown-Time sollte man nicht zu restriktiv arbeiten, da ein häufiges Ein- und Ausschalten der HDD letztlich zu einem höheren Verschleiß der HDD führt.
- Values from 1 to 240 specify multiples of 5 seconds, yielding timeouts from 5 seconds to 20 minutes. Values from 241 to 251 specify from 1 to 11 units of 30 minutes, yielding timeouts from 30 minutes to 5.5 hours. A value of 252 signifies a timeout of 21 minutes. A value of 253 sets a vendor-defined timeout period between 8 and 12 hours, and the value 254 is reserved. 255 is interpreted as 21 minutes plus 15 seconds. Note that some older drives may have very different interpretations of these values.
Quelle: https://linuxundich.de/hardware/festplatten-automatisch-im-betrieb-in-den-standby-schalten/
Tweak 3: Lüftersteuerung des Prozessorlüfters je nach CPU-Temperatur
Grundlegend wird der Prozessorlüfter in den default-Einstellungen durch das BIOS/UEFI des Systems gesteuert. Möchte man eine manuelle Anpassung daran vornehmen, so kann dies über das Paket "fancontrol" geschehen. Nach der Installation per apt-get muss nur über den Befehl "pwmconfig" die Zugehörigkeit des Prozessorlüfters mit dem entsprechenden hwmon PWM-Kanal hergestellt werden.
Die Definition der Regeln und Zuordnung erfolgt auch über dieses, nahezu selbsterklärende, Tool. Sofern man eine Anleitung dazu benötigt, so bietet sich das Ubuntuusers-Wiki dazu an. Die Befehle lassen sich dabei ein-zu-eins auf das Proxmox-Debian-System umlegen.
Sollten einige Sensoren fehlen, so muss erst "lm-sensors" per Paketmanager installiert werden und im Anschluss über "sudo sensors-detect" das benötigte Modul geladen werden.
Tweak 4: Lüftersteuerung des Gehäuselüfters je nach HDD-Temperatur
Alternativ bietet es sich an, die Gehäuselüfter auf Basis der HDD-Temperatur zu regeln - sind die HDDs aus, so muss theoretisch kein Lüfter laufen. Dazu werden auf dem ASRock Rack-Board PWM-Lüfter nötig: Normale 3pin-Lüfter lassen sich leider an diesem Motherboard nicht regeln.
Hatten wir auf dem bestehenden NAS-System ein Script per Hand geschrieben, welches die Steuerung übernahm, so sind wird diesmal im Internet über das Python-Tool "hddfancontrol" gestolpert. Um dieses nutzen zu können muss erst Python und andere Voraussetzungen installiert werden: "apt-get install python3-pip fancontrol hddtemp hdparm" .
Nach dem dies geschehen ist kann über "pip3 install hddfancontrol" das benötigte Tool installiert werden. Eine Anleitung zur Nutzung findet man prinzipiell auf der Website des Tools unter https://pypi.python.org/pypi/hddfancontrol/. So kann das Tool unter anderem verschiedene PWM-Kanäle ansteuern, als Daemon gestartet werden oder sogar die Festplatten nach einer gewissen Zeit schlafen legen. Dies wird über die Startparameter des Tools gestartet.
Als Beispiel wird auf der Website der Befehl
- hddfancontrol -d /dev/sda /dev/sdb -p /sys/class/hwmon/hwmon1/device/pwm2 /sys/class/hwmon/hwmon1/device/pwm3 --pwm-start-value 200 200 --pwm-stop-value 75 75 --min-fan-speed-prct 10 -i 60 --spin-down-time 7200 -b -l /var/log/hddfancontrol.log
aufgeführt. Dieser startet das Tool im Daemon-Mode (-d), so dass es automatisch als Hintergrundprozess arbeitet.
Die Angabe von /dev/sda /dev/sdb stellt eine Liste der zu überwachenden Festplatten auf und kann beliebig um HDDs erweitert werden, eine Leertaste dient dabei als Separator. Hierbei kann Alternativ auch erneut über den /dev/by-id/xxx Pfad vorgegangen werden.
Der Operator -p definiert die Hwmon-PWM-Kanäle die gesteuert werden sollen. Auch hierbei handelt es sich um eine Liste - im Falle des ASRock Rack Boards würde es sich um den PWM2-Controller, also um den Pfad /sys/class/hwmon1/device/hwmon/hwmon1/pwm2. Die -pwm-start-value gibt an, mit welchem PWM-Wert (0 bis 255) der Lüfter auf dem jeweiligen Kanal gestartet werden soll. Dies kann über das Tool pwmconfig ermittelt werden. Der Wert -pwm-stop-value gibt hingegen an, ab welchem Wert der Lüfter stoppt. Wichtig ist weiterhin der Wert hinter -min-fan-speed-prct: Dieser gibt an, wie die Lüfter drehen sollen, wenn die HDD gerade nicht gekühlt werden sollen. Möchte man die Lüfter ganz abschalten, so kann man hier 0 angeben.
Ein Log der Aktivität wird in diesem Fall unter /var/log/hddfancontrol.log abgelegt und über den Parameter -l spezifiziert. Nachdem so die benötigten Parameter eingestellt wurden, kann man das Tool auch in den Autostart aufnehmen. Dazu wird auf der Proxmox-Node einfach per nano /etc/rc.local der entsprechende Befehl zum Start von hddfancontrol vor dem abschließenden "exit 0" in der Datei eingetragen. Nach einem Neustart sollte somit auch die Lüftersteuerung gestartet werden.
Tweak 5: Einsatz einer APC-USV zur Absicherung des Systems
Zur Sicherstellung der Stromversorgung am ersten Review-Center.de NAS hatten wir eine APC-USV angeschafft und diese per USB mit dem NAS verbunden. Unter OpenMediaVault stand mit dem Plugin openmediavault-nut ein Tool bereit, welches die Vorgänge der USV aktiv monitoren und aufzeichnen konnte. Bei Stromausfall konnte so das System ordnungsgemäß weiter betrieben oder ab einem gewissen Ladezustand der USV abgeschaltet werden.
Dies wollten wir auf dem Proxmox-System auch umsetzen - dafür existiert unter Debian das Package apcupsd. Dieses kann simpel per "apt-get install apcupsd apcupsd-doc" installiert werden. Möchte man weiterhin einen Webserver zur Datenausgabe nutzen, so muss zusätzlich noch das folgender Befehl ausgeführt werden "apt-get install apache2 apcupsd-cgi" .
Im Anschluss an die Installation muss in der Datei /etc/apcupsd/apcupsd.conf eine entsprechende Konfiguration vorgenommen werden. Sofern man auf eine per USB verbundene USV setzt der UPSCABLE-Wert und der UPSTYPE-Wert auf usb gesetzt werden. Die weiteren Parameter sind weitestgehend erklärt und können somit je nach Bedarf verändert werden.
In der Datei /etc/default/apcupsd muss der Wert von ISCONFIGURED von no auf yes geändert werden - zum ersten Starten des Daemon wird der Befehl "/etc/init.d/apcupsd start" verwendet. Im Anschluss müsste unter http://IP-der-Proxmoxmaschine/cgi-bin/apcupsd/multimon.cgi die entsprechende Weboberfläche mit Statistiken zur USV sichtbar werden.
Möchte man sich zusätzlich Mails bei bestimmten Aktionen zusenden lassen, so müssen im Verzeichnis /etc/apcupsd einige Scripte angepasst werden - dies wären unter anderem die Datei changeme, commfailure, commok, offbattery und onbattery. Hier muss der Wert SYSADMIN=
Tweak 6: Schlafen legen des Systems bei Nichtbenutzung und Optionen zum Aufwecken
Möchte man das Proxmox-System nutzen, um nur OpenMediaVault und Proxmox produktiv zu nutzen, nutzt die sonstigen VMs jedoch nur gelegentlich oder nur bei Bedarf, so wäre es wünschenswert, wenn das System bei Nichtbenutzung automatisch heruntergefahren wird.
In OpenMediaVault lässt sich dies einfach über das Plugin "openmediavault-autoshutdown" realisieren, welches über OMV-Extras angeboten wird und sich folglich komfortabel per Erweiterungs-Menü installieren lässt und im Anschluss in der OpenMediaVault-Web-GUI konfigurieren lässt. Ist die Konfiguration einmal vorgenommen und das Plugin aktiviert, so wird die virtuelle Maschine mit dem installieren OpenMediaVault automatisch heruntergefahren. Bei Bedarf lässt sie sich jedoch jederzeit über Proxmox starten.
Möchte man jedoch dazu übergehen auch die Proxmox-Node zu stoppen und somit die physikalische Maschine vollständig herunter zu fahren, so lässt sich dies über folgendes Script lösen, welches als Shell-Script unter /usr/bin/shutdown_check.sh gespeichert werden muss.
- # !/bin/bash
if /usr/sbin/qm list | grep -q 'running'
then
if [ -f .shutdown ]
then
echo "VM was starting up - stopping shutdown"
rm .shutdown
fi
else
if [ -f .shutdown ]
then
echo "Shutdown now"
rm .shutdown
/sbin/shutdown -h now
else
echo "Shutdown, if down on next cron run"
touch .shutdown
fi
fi
Nachdem die Datei erstellt wurde, wird sie über den Befehl "chmod +x /usr/bin/shutdown_check.sh" ausführbar gemacht. Und als Adminnutzer per "crontab -e" als regelmäßigen Cronjob aufgenommen. Nutzt man Beispielsweise im crontab den Befehl "*/5 * * * * /usr/bin/shutdown_check.sh > /var/log/shutdown_cron.log 2>&1", so wird das Script alle 5 Minuten ausgeführt. Es prüft dabei ob eine virtuelle Maschine aktiv ist, ist dies der Fall passiert nichts. Sind jedoch keine VMs aktiv, so wird eine Datei .shutdown erstellt. Bei der nächsten Ausführung in 5 Minuten wird erneut geprüft ob eine VM aktiv ist. Ist dies der Fall, so wird die Datei .shutdown gelöscht und der Zähler beginnt erneut. Sind jedoch keine VMs aktiv, so wird die .shutdown Datei gelöscht und das System per Shutdown-Befehl gestoppt. Der Check stellt somit sicher, dass man die Proxmox-Node immer starten kann und für mindestens 10 Minuten nutzen kann - wird in dieser Zeit keine VM gestartet, so fährt das System wieder herunter. Befindet sich jedoch z.B. die OpenMediaVault VM im Autostart, so wird das System erst gestoppt, wenn auch die VM nicht mehr aktiv ist, also keine Nutzung der VM mehr erfolgt.
Das oben genannte Script stellt eine sehr simple Möglichkeit dar, das Hauptsystem herunter zu fahren und könnte um weitere Checks erweitert werden z.B. ob ein SSH-Nutzer angemeldet ist.
Zum Starten des Systems kann auf Wake-On-Lan zurückgegriffen werden. Dies funktioniert jedoch nur über die physikalische MAC der Hauptmaschine und nicht über die MAC-Adresse einer virtuellen Maschine. Auch bei gestartetem Proxmox lassen sich VMs nicht per WoL starten - Abhilfe könnte jedoch dieser Beitrag im Proxmox-Forum schaffen, den wir bisher jedoch noch nicht ausprobieren konnten.
Möchte man das NAS bzw. die Proxmox-Node per WoL aus dem Internet wecken und ist in Besitz einer fritz!box aus dem Hause AVM, so lässt sich dies in der Fritz!Box-GUI einstellen. Dazu unter Heimnetz -> Heimnetzübersicht -> Reiter "Netzwerkverbindungen" -> System auswählen und auf den Stift bzw. Bearbeiten klicken und den Haken bei "Diesen Computer automatisch starten, sobald aus dem Internet darauf zugegriffen wird." setzen. Sofern eine Portfreigabe vorhanden ist, reicht es nun diese auf irgendeinem Wege von außen zu öffnen und das System müsste starten. Sollte bisher keine Portfreigabe vorhanden sein, so lässt sich hier frei ein zufälliger Port (beispielsweise 12345) erstellen. Bei Aufruf von http://web-ip-oder-externe-domain-der-fritz-box:12345 dürfte das System nun auch von außen gestartet werden können. Eine Erleichterung dabei könnte auch die Nutzung einer DNS-Dienstes oder der myFritz-Funktion der Fritzbox sein.
Tweak 7: CPU-Last verstehen und im Auge behalten
Ein weiteres wichtiges Kriterium sollte das Monitoring der Systemlast sein - einen Artikel der dieses Thema gut aufgreift ist unter http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages zu finden. Bei laufenden VMs sollte man immer die average load im Blick behalten, ist diese langfristig größer, als die Anzahl der Kerne oder Prozessoren (z.B. bei eine Dual-Core oder Dual-CPU VM größer als 2), so sollte man überlegen, der jeweiligen VM mehr Ressourcen zur Verfügung zu stellen.
Sehr praktisch diesbezüglich ist neben dem Tool top, das erweiterte Tool htop, welches per "apt-get install htop" auf Ubuntu oder Debian-Systemen installiert werden kann und sich wesentlich besser bedienen lässt, als das normale top.
Natürlich sollte man auch die Serverlast des Hauptsystems im Blick halten - bei unserem vier Kern bzw. acht Thread Intel-Prozessor dürfte der load average Wert folglich nicht langfristig über acht liegen, da der Prozessor sonst den Flaschenhals im System darstellt.
Tweak 8: Proxmox default-Datenspeicher vergrößern
Der default-Datenspeicher, unter dem Proxmox Daten wie Images, virtuelle Festplatten, Backups oder Snapshots ablegt liegt per default Einstellung auf der gleichen HDD wie bereits das Debian-System. Möchte man dies umgehen, so kann in der Datei /etc/fstab eine andere HDD unter /var/lib/vz gemountet werden. Proxmox wird zukünftig die Daten dann auf der entsprechend gemounteten HDD speichern.
In unserem Fall lautet der Eintrag in der fstab beispielsweise und verweist auf eine andere und wesentlich größere Partition:
- #Daten
UUID="09dc51c0-b88f-4736-a423-1cb6aaae6843" /var/lib/vz ext4 errors=remount-ro 0 1