Seite wählen

NETWAYS Blog

VM Volumes live anpassen mittels blkdeviotune

Wir bei NETWAYS setzen für das erstellen von VMs bestimmte Templates ein. In diesen Templates sind alle möglichen Konfigurationen hinterlegt. Unter anderem auch für die VM Volumes. Doch nicht immer passen diese Konfigurationen und so sind einzelne Anpassungen an der laufenden VM nötig. Mittels „blkdeviotune“ ist man als Admin in der Lage, live die Volume-Daten der VMs zu bearbeiten.
Hierzu begibt man sich mittels „virsh“ in das dazugehörige Terminal.
root@virt-system:~# virsh
Welcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands
'quit' to quit
virsh # list
Id Name State
----------------------------------------------------
01 one-1000 running
02 one-1001 running
03 one-1002 running
04 one-1003 running

In diesem Terminal hat man verschiedene Parameter die man anpassen kann. Welche verfügbar sind, kann man wie folgt anzeigen lassen. Hierbei wird die ID aus obigen Kommando benötigt:
virsh # blkdeviotune 02 vda
total_bytes_sec: 62914560
read_bytes_sec : 0
write_bytes_sec: 0
total_iops_sec : 500
read_iops_sec : 0
write_iops_sec : 0

Folglich ist hier die Möglichkeit gegeben, oben genannte Parameter anzupassen. Ob man hier nun die Limitierungen der IOPs und die „Bytes per second“ bezüglich „read“ und „write“ unterscheidet, oder ob man einen totalen Wert angibt, bleibt jedem Admin selbst überlassen. In diesem Beispiel hat die VM mit der OpenNebula ID „one-1001“ Limitierungen auf die Parameter „total_bytes_sec“ und „total_iops_sec„. Die anderen Werte sind hier unlimitiert, jedoch werden sie durch den übergeordneten Parameter beschränkt. Wenn man die Werte nun entsprechend seiner Wünsche anpassen möchte, ist es wie im folgenden Beispiel wichtig, alle Werte mit anzugeben, auch wenn sie nicht verändert werden sollen. Als Beispiel wird hier nun der Parameter „total_bytes_sec“ auf 0 zurück gesetzt und einzelne Limitierungen für die Werte „read_bytes_sec“ und „write_bytes_sec“ gesetzt. Ebenso werden die maximal zulässigen IOPs erhöht.
virsh # blkdeviotune 02 vda 0 31457280 31457280 1000 0 0
virsh # blkdeviotune 02 vda
total_bytes_sec: 0
read_bytes_sec : 31457280
write_bytes_sec: 31457280
total_iops_sec : 1000
read_iops_sec : 0
write_iops_sec : 0

Derartige Änderungen können live geschehen und benötigen keine weiteren Aktionen innerhalb der VMs. Wir bei NETWAYS reagieren so zum Beispiel auf temporäre Mehrauslastungen einzelner VMs.

Cloud Management – Teil 1: blkdeviotune/migrate-setmaxdowntime


Viele von euch haben bestimmt schon einmal von OpenNebula oder OpenStack gehört, beiden Plattformen verwenden standardmäßig libvirtd als Hypervisor, da jedoch die darunter liegende Hardware mit unter stark beansprucht werden wird, vor allem im Cloud Bereich, wo mehrerer KVM Instanzen auf einem Virt Host um CPU/Speicher/IO Resourcen konkurrieren, ist es gelegentlich notwendig die einen oder andere Instanz zu bändigen bzw. in die Schranken zu weisen.
Unsere Cloud läuft derzeit noch mit OpenNebula, wir selbst sind sehr zufrieden mit dem Stack, da sich dieser leicht Verwalten lässt und sich auch gut mit unserem Ceph als Backend verträgt, natürlich verwenden wir in unserem Cloud Stack noch andere Tools, diese sind aber nicht Gegenstand dieses Artikels, mehr dazu in späteren Teilen der Serie.
Libvirtd kann mit CLI Tools wie virsh gesteuert werden, auch besteht die Möglichkeit libvirtd über die entsprechende libvirt C API oder durch seine ScriptLanguage Bindings für ruby/python/perl/javascript/etc… anzusprechen bzw. anzusteuern zu können.
So beispielsweise unterstützt man OpenNebula wenn die Migration einer KVM Instanz von Virt Host A zu Virt Host B aufgrund von Last auf der Instanz selbst partout nicht klappen will…

root@virt1: ~ $ virsh migrate-setmaxdowntime --downtime 1800 one-8366
error: Requested operation is not valid: domain is not being migrated (dieser Fehler kommt nur wenn sich die Instanz nich im Status Migrate befindet, ist hier also nur exemplarisch mit abgebildet)

…oder wenn die Instanz AMOK läuft und somit andere Instanzen zu stark beeinträchtigt…

root@virt1: ~ $ virsh blkdeviotune one-8366 vda --live
total_bytes_sec: 62914560
read_bytes_sec : 0
write_bytes_sec: 0
total_iops_sec : 400
read_iops_sec  : 0
write_iops_sec : 0

…dann limitieren wir diese einfach ein bisschen…

root@virt1: ~ $ virsh blkdeviotune one-8366 vda --live 62914560 0 0 200 0 0

…und vergewissern uns nochmal ob unsere neuen IOPs Limits übernommen wurden…

root@virt1: ~ $ virsh blkdeviotune one-8366 vda --live
total_bytes_sec: 62914560
read_bytes_sec : 0
write_bytes_sec: 0
total_iops_sec : 200
read_iops_sec  : 0
write_iops_sec : 0

…ich denke, damit sollte klar sein worauf wir hier abzielen möchten.
In folgenden Teilen dieser Serie werden wir euch noch mehr Tips & Tricks mit auf den Weg geben, die helfen sollen eure Cloud zu bändigen bzw. aufkommende Probleme anzugehen, also bleibt gespannt. 😉

"Willkommen auf der dunklen Seite der Macht, Alexander …"

Nein, ich meine nicht die antagonistische Fraktion aus einer sehr populären Filmreihe (deren Name nicht genannt werden muss), sondern die Apple-Fraktion bei NETWAYS.
Letzten Monat habe ich nämlich meine Ausbildung zum Fachinformatiker für Anwendungsentwicklung abgeschlossen und wurde in die Development-Abteilung übernommen.
Neuer Status – neues Gehalt, neue Aufgaben … und neues Arbeitsgerät. Ich habe mich bewusst für ein MacBook Pro entschieden, weil auf dieser Plattform sehr vieles viel besser und einfacher funktioniert und ich nicht bei jeder Kleinigkeit erst den Linux-Kernel patchen und neu kompilieren, SELinux abschalten oder die IPTables-Regeln anpassen muss. 😉
Wer weiß wann ich mit dem nächsten Kunden von Angesicht zu Angesicht zu tun haben werde – diesbzgl. will ich keine Risiken eingehen.
Abstriche muss ich keine machen – schließlich bietet MacOS X alles, was das Entwickler-Herz begehrt. Außer vielleicht …

Container

Auf Linux haben sie sich breit gemacht wie ein Türsteher: Docker, LXC, LXD und wie sie alle heißen. Auch BSD macht mit seinen Jails keine Kompromisse in Sachen Virtualisierung und Sicherheit.
Umso mehr wundert es mich, dass das BSD-basierende MacOS X dieses Feature nicht übernommen hat. Aber es wäre kein *nix-System, wenn man das nicht mit ein wenig Geschick nachrüsten könnte …

Dann eben so …

Auf meinem alten Arbeitsgerät habe ich Ubuntu 16.04 verwendet. Diese GNU/Linux-Distribution enthält von Haus aus LXD in den Paketquellen, womit ich in einer leichtgewichtigen und sicher isolierten Umgebung mal schnell was ausprobieren konnte.
Dieses Werkzeug kann ich mit einer Virtuellen Maschine problemlos weiterhin verwenden – nicht nur in der VM selbst, sondern auch vom Mac-Host aus. Genau dafür braucht man das o. g. „wenig Geschick“ …

LXD Server einrichten

Man logge sich in die VM ein und erlange Administratorrechte. Dann installiert man LXD und richtet diesen darauf hin ein:

$ sudo -i
(...)
# apt install lxd
(...)
# lxd init
Name of the storage backend to use (dir or zfs) [default=dir]:
Would you like LXD to be available over the network (yes/no) [default=no]? yes
Address to bind LXD to (not including port) [default=all]:
Port to bind LXD to [default=8443]:
Trust password for new clients:
Again: 
Do you want to configure the LXD bridge (yes/no) [default=yes]?

Fast alle Abfragen des Installations-Assistenten können bedenkenlos mit der Eingabetaste bestätigt werden. Die von mir hervorgehobene Frage allerdings muss mit „yes“ beantwortet werden – ansonsten fällt die Nutzung vom Host aus ins Wasser. Außerdem muss ein einigermaßen sicheres Passwort gewählt werden.
Der Frage nach der „LXD bridge“ folgt ein weiterer, „pseudo-grafischer“ Installations-Assistent. Dessen Fragen kann man ausnahmslos mit der Eingabetaste bestätigen.
Des weiteren wird später die IP der VM benötigt:

# ifconfig
enp0s5    Link encap:Ethernet  HWaddr 00:1c:42:8b:e9:ba
          inet addr:10.211.55.19  Bcast:10.211.55.255  Mask:255.255.255.0
          inet6 addr: fdb2:2c26:f4e4:0:880a:a527:1a6:1130/64 Scope:Global
          inet6 addr: fdb2:2c26:f4e4:0:fc54:870c:56af:cba0/64 Scope:Global
          inet6 addr: fe80::fbc7:ab4d:d29f:e227/64 Scope:Link
(...)
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
(...)
lxdbr0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00
          inet addr:10.83.127.1  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fdb3:61e3:ffb6:f62f::1/64 Scope:Global
          inet6 addr: fe80::4024:c9ff:fe4a:691b/64 Scope:Link
(...)

LXD Client einrichten

Da die Entwickler von LXD sich bemüht haben, nicht von Linux-spezifischen Funktionalitäten Gebrauch zu machen, funktioniert der LXD Client auch auf MacOS. Den muss man nur noch vom LXD Server in Kenntnis setzen.
Sobald das getan ist, kann auch schon der erste Container in Betrieb genommen werden.

$ brew install lxc
(...)
$ lxc remote add u1604vm 10.211.55.19
Certificate fingerprint: a761f551dffdf47d9145da2aa16b4f6be242d960ce1697994c969e495b0724fd
ok (y/n)? y
Admin password for u1604vm:
Client certificate stored at server:  u1604vm
$ lxc launch ubuntu:16.04 u1604vm:test1
Creating test1
Starting test1ge: rootfs: 100% (37.78MB/s)
$ lxc exec u1604vm:test1 -- bash
root@test1:~# man perlfunc

Fazit

Es muss nicht immer Docker sein.
Gerade wenn das Testsystem sich möglichst so verhalten soll wie eine VM oder eine Physische Maschine ist LXD auf jeden Fall einen Blick Wert – auch auf dem Mac.

Alexander Klimov
Alexander Klimov
Senior Developer

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 bei uns friedliche Wege.

Foreman räumt auf

Foreman Logo
Dank Virtualisierung und automatischer Provisionierung sind schnell und einfach Entwicklungs- und Testsysteme zur Verfügung gestellt und jeder bestellt fleißig neue Systeme, aber wie viele melden sich dann wirklich zurück wenn ein System nicht mehr gebraucht wird? Aus meiner Erfahrung heraus möchte ich behaupten die wenigsten tun dies. So kommt es, dass Ressourcen reserviert sind und brach liegen oder schlimmer noch tatsächlich belegt aber nicht mehr wirklich genutzt werden. Manuelle Aufräumaktionen treffen dann entweder zu wenig oder zu viele Systeme und kosten zu viel Zeit und Nerven. Wie schön wäre es wenn man die Kollegen erziehen könnte? Da es mit den Kollegen wohl nicht klappen wird, erziehen wir stattdessen unsere Umgebung und zwar mit dem Plugin „Expire Hosts“ für Foreman.
Die Installation übernimmt wie mittlerweile bei fast allen Plugins der Foreman Installer und danach können wir auch direkt konfigurieren wie Systeme zukünftig von diesem Plugin behandelt werden sollen.
Foreman Expire Hosts Settings
Wie man sieht kann man drei Zeiten einstellen und zwar wann die erste und zweite Benachrichtigung relativ zum Ablaufdatum erfolgen soll und nach wie viel Tagen es nach Ablauf gelöscht werden soll nachdem das System am Ablaufdatum heruntergefahren wurde. Außerdem kann eingestellt werden, ob der Besitzer des Systems oder nur der Administrator das Ablaufdatum nachträglich ändern darf und ob die Angabe eine Pflicht ist. Wer dies als Administrator will kann sich auch auf die Liste der zusätzlichen Email-Empfänger setzen, da sonst nur der Besitzer benachrichtigt wird.
Wenn die allgemeinen Einstellungen nun passen erhält jeder Host ein Eingabefeld zur Einstellung seines Ablaufdatums unter den zusätzlichen Informationen.
Foreman Expire Hosts Host
Zusätzlich zur Email-Benachrichtigung zeigt Foreman auch noch im Webinterface den Status an und warnt auch hier vor dem Ablauf.

Foreman Expire Hosts OkForeman Expire Hosts Warning

Zwar ist das Plugin primär für virtuelle Maschinen gedacht, funktioniert aber auch bei physikalischen Systemen. Wenn Foreman das Powermanagement für diese steuern kann, fährt es diese auch herunter. Wenn nicht weiß der Administrator zumindest, dass das System zum Herunterfahren und Löschen freigegeben ist.
Ich denke mal für dieses Plugin finden so einige Administratoren einen sinnvollen Anwendungsfall, weshalb ich es auch neben vielen weiteren Plugins in die Foreman-Schulung aufgenommen habe.

Dirk Götz
Dirk Götz
Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Icinga2 & LSW

Ich musste feststellen das man mit dem Linux Subsystem for Windows auch Icinga2 + Icingaweb2 auch zum laufen bringen kann auf einem Windows.
Also hier mein kleiner Erfahrungsbericht:
Es galt erstmal heraus zufinden welches Ubuntu in dem Subsystem verwendet wird.
Dazu verwenden wir folgendes Kommando:

# lsb_release -a

selection_019
Nun installieren wir erstmal Updates:
# sudo -i && apt-get update
gefolgt von eurem PW und dann dem Update:
selection_020
Als nächstes installieren wir das Icinga2 Repo fuer die anstehende installation von Icinga2.
# add-apt-repository ppa:formorer/icinga && apt-get update
selection_022
Nun legen wir mit der Datenbank los:

# apt-get install mariadb-server mariadb-client -y

Es muss hiernach das Passwort für den MySQL Root Benutzer angelegt werden.
# /etc/init.d/mysql start
# mysql_secure_installation

Login zu Mariadb:
# mysql -p
Anlegen der Icinga-IDO Datenbank:
selection_027
# create database icinga;
Festlegen des IDO Benutzers:
# grant all on icinga.* to 'icinga'@'localhost' identified by 'icinga';
# apt-get install nagios-plugins-all -y

Damit haben wir die Plugin-Checks installiert aber es fehlt uns noch der Webserver :
Dem widmen wir uns nun :
# apt-get install apache2
gefolgt von der simplen installation von icinga2;
# apt-get install icinga2
selection_031
Wir starten nun erstmal den Icinga2 Service:
# /etc/init.d/icinga2 start
Nun brauchen wir natuerlich auch den Rest 🙂
# apt-get install icingaweb2 icingacli icinga2-ido-mysql
Nach dem die Installation durchgelaufen ist editieren wir erstmal die IDO Konfig Datei:
selection_034
# vi /etc/icinga2/features-enabled/ido-mysql.conf
und kommentieren alle wichtigen eintraege ein und ändern Sie ggf. ab.
Wir müssen auch noch die die php.ini editieren:
# vi /etc/php5/apache2/php.ini
Wir suchen darin nach date.timzezone und tragen hier eine Sinnvolle Zeitzone ein.

apt-get install php5-gd php5-imagick

gefolgt von :
# /etc/init.d/httpd restart
Auch ein enablen der Commandpipe ist notwendig:
# icinga2 feature enable command
Fuer das Webfrontend benoetigen wir einen setup token
# icingacli setup token create
Der Webserver läuft schon , wir oeffen im Edge die folgende adresse
und benutzen den angeforderten Token.
Wir fuellen das Setup Sinnvoll aus 🙂
Ausserdem muss ggf. die iptables firewall eingetragen werden:
# iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
selection_054
Und erhalten zum Schluß ein laufendes Icinga2 welches im LSW installiert ist.
Ich hoffe ihr hattet bischen Spaß beim dem nachvollziehen oder nachbauen.
Ich freue mich über Feedback jeglicher Art.
Gruß
David

David Okon
David Okon
Senior Systems Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.