VM Volumes live anpassen mittels blkdeviotune

This entry is part 2 of 2 in the series Cloud Management

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.

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Cloud Management – Teil 1: blkdeviotune/migrate-setmaxdowntime

This entry is part 1 of 2 in the series Cloud Management

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

Enrico Labedzki

Autor: Enrico Labedzki

Enrico ist beruflich ganz schön rumgekommen – IT hat ihn aber immer beschäftigt. Nach einem Ausflug in die Selbstständigkeit im Bereich Webentwicklung und Network Solutions, wurde es dann Zeit Nägel mit Köpfen zu machen und endlich den Weg als Softwareentwickler und Systemintegrator einzuschlagen. In seiner Freizeit widmet sich der passionierte Bastler der Elektrotechnik und Animatronik. Bei Netways bereichert er mit seinem vielseitigen Know-How das Managed Service-Team.

Monthly Snap June: Icinga2, Training, Foreman, GitLab, Icinga director, OpenNebula

Martin presented in June our new book about Icinga 2 written by our very own Lennart Betz and Thomas Widhalm.

Julia announced the official Foreman training material and Michael recommended the new DEV-Trainings: Git and Jenkins.weekly snap

Tim explained how to use OpenNebula ACLs and Foreman in Part 1 and Part 2 while Florian showed us how to animate vector graphics with CSS.

Julia gave us a nice update of our new training facility – the „Kesselhaus“.

Dirk announced that the Foreman Project will be 7 years at the 21st of July – so safe the date and visit us at the German Foreman birthday event that will take place in our event room „Kesselhaus“.

Enrico shared some tips and tricks about how to work with GitLab web hooks and Thomas Gelf showed us the new and shiny Icinga director 1.10.

Vanessa Muschweck

Autor: Vanessa Muschweck

Vanessa ist unser Head of Finance und somit mit ihrem Team für das Geld, Controlling und Personalverwaltung zuständig. Außerhalb des Büros ist sie sportlich unterwegs und widmet sich neben Tennis hauptsächlich dem professionellem Yoga. Hier macht sie gerade die offizielle Trainer-Ausbildung und kann dann die älter werdende Belegschaft bei NETWAYS ertüchtigen.

OpenNebula ACLs und Foreman Teil 2 von 2

Dies ist die Fortsetzung von OpenNebula ACLs und Foreman Teil 1 von 2

Vorab eine kurze Zusammenfassung:
Wir haben in OpenNebula einen User angelegt, der durch ACL-Einträge auf bestimmte Ressourcen beschränkt wurde und bereits in der Lage ist, VMs in OpenNebula anzulegen. Über die bestehende Integration von Foreman und OpenNebula soll dieser User nun durch Foreman virtuelle Maschinen anlegen. Dazu müssen jedoch in Foreman noch einige Voraussetzungen erfüllt werden, wie im folgenden Artikel dargestellt werden soll.

(Wir verwenden hier Foreman in der Version 1.11.2 in einer gepatchten Version.)

Als ersten Schritt legen wir auch in Foreman einen Benutzer an:
Bildschirmfoto 2016-06-08 um 14.20.39

Damit dieser User auf OpenNebula zugreifen kann, muss ein neuer Eintrag in den “Compute resources” mit den Credentials des vorher angelegten OpenNebula-Benutzers angelegt werden:

Screen Shot 2016-06-22 at 10.05.49

(Um zu verdeutlichen, dass es sich hierbei nicht um den Foreman-User handelt, habe ich den User-Namen leicht verdreht)

Für den Zugriff auf die Ressourcen, braucht der User eine Rolle. Diese wird eingerichtet und beschränkt:

Bildschirmfoto 2016-06-08 um 14.33.04

Die Einschränkungen erreicht man über das Setzen von ACL, in Foreman “Filtern”. In unserem Fall kommen hier viele Einträge zusammen, da wir den User auf einige wenige Ressourcen beschränken wollen.

Bildschirmfoto 2016-06-08 um 14.33.15

Bildschirmfoto 2016-06-08 um 14.33.26

Dieser Blogpost dient nur als schnelle Übersicht. Wer tiefer in diese Materie einsteigen möchte, klickt hier.

Nachdem die Filter gesetzt wurden, muss dem User natürlich auch diese Rolle zugewiesen werden:Bildschirmfoto 2016-06-08 um 14.34.32

Hier unbedingt den Haken bei “Administrator” entfernen! Ein Nutzer mit dieser Eigenschaft wird in Foreman durch keinen Filter eingeschränkt.

Fazit:

Wir haben nun zwei User, einen in OpenNebula, einen in Foreman. Beide sind durch ACL/”Filter” in ihren Aktionen beschränkt und können somit nur in einem fest zugewiesenen Bereich agieren.Durch die feine Granulierung der Einschränkungen können Benutzer für unterschiedlichste Szenarien angelegt werden, ohne dass andere Benutzer betroffen sind.

Wer sich durch diesen Anriss motiviert fühlt, mehr über dieses Thema zu erfahren: Tiefer ins Detail gehen die Kollegen Christian Stein und Dirk Götz in einem Webinar am 26.07.

 

 

Tim Albert

Autor: Tim Albert

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere um Infrastrukturthemen kümmert. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr - als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit einsatzbereit. Ansonsten kocht er sehr gerne – alles außer Hase!

OpenNebula ACLs und Foreman Teil 1 von 2

Wer nicht, wie von Kay dargestellt, die OpenNebula API nutzen möchte, sondern per Foreman in OpenNebula Virtuelle Maschinen erstellen will, hat einige Klippen zu umschiffen.

Dieser Post soll einen kurzen Einblick in unser Vorgehen, hier bei Netways bieten. Aufgrund der verwendeten Software schwankt die hier verwendete Sprache zwischen Deutsch und Englisch, ich versuche aber, mit Screenshots den Ablauf darzulegen. Falls dennoch Unklarheiten auftreten, freue ich mich über ein kleinen Kommentar. Da wir bereits über eine bestehende Integration zwischen Foreman und ONE verfügen, deren Einrichtung den Rahmen sprengen würde, wird diese als gegeben angenommen. Folgendes Ziel: Es wird ein generischer Nutzer angelegt, der mit möglichst wenigen Berechtigungen dennoch funktional arbeiten soll.

Im zweiten Teil werde ich darlegen, welche Schritte in Foreman nötig sind.

OpenNebula: Nutzer, Group, ACL (das Erstellen von VDC, Templates und VLAN entfällt bei unserem eingeschränktem User)

Beginnen wir an der Basis, in OpenNebula

ONE User anlegen

Da der User sich “lokal” gegen ONE authentifiziert, ist die Methode “Core”

Bildschirmfoto 2016-06-07 um 09.36.57

Zugehörige Gruppe anlegen

Die Views beeinflussen nur das Webinterface (Sunstone), Admin bei einem eingeschränkten Account einfach auslassen, bei den Permissions muss mindestens ein Wert gesetzt werden.

Der mit dem geringsten Impact ist hier “VMs anlegen”

Bildschirmfoto 2016-06-07 um 09.39.20

ACLs anlegen, hier auf folgendes achten:

  • ob der User oder die Gruppe betroffen ist
  • in welcher Zone die Regel greift
  • für jede Ressource eine eigene ACL erstellen
  • die verwendeten IDs sind selbstverständlich systemspezifisch

Bildschirmfoto 2016-06-07 um 09.43.37

 

Achtung bei den VLANs und den Templates. Hier nicht Name des Netzwerks und seine ID durcheinander bringen.

Bildschirmfoto 2016-06-07 um 09.46.02

Bildschirmfoto 2016-06-07 um 09.53.39

Bildschirmfoto 2016-06-07 um 09.44.20

Bildschirmfoto 2016-06-07 um 09.47.27

Bildschirmfoto 2016-06-07 um 09.44.48

 

In Summe sollte das Endergebnis so aussehen:

Bildschirmfoto 2016-06-07 um 09.54.15

Man sieht, dass Resource IDs nur in der Zone “OpenNebula” gelten und ACL 495 die ACL 491 bedingt

Dieser User kann nun bereits VMs im VLAN 0815 mit dem Template 0815 in OpenNebula erstellen, ein erstes Teilziel ist also erreicht.

Im nächsten Teil kommen wir zu Foreman:

User anlegen

Role anlegen

Compute Resources anlegen

Verknüpfung untereinander und mit ONE herstellen und Erstellen der ersten VM

Edit 1: Manche Screenshots wurden nicht angezeigt, Danke an @gethash (15:00, 08.06.16)

 

Tim Albert

Autor: Tim Albert

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere um Infrastrukturthemen kümmert. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr - als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit einsatzbereit. Ansonsten kocht er sehr gerne – alles außer Hase!

Monthly Snap May: Docker, Graphite, Opennebula and Beijing

May started with Simons blog post on monitoring custom applications. 

Blerim gave us an insight into Graphite – the history of a data point. Kai, one of our trainees explained what he learned at NETWAYS.
weekly snap

Tobias explained Debugging with Docker and Michael told us something about Docker on OSX.

Kay explained on how to get started with the Opennebula API.

Finally, Christoph told us about his Consulting journey to Beijing.

Vanessa Muschweck

Autor: Vanessa Muschweck

Vanessa ist unser Head of Finance und somit mit ihrem Team für das Geld, Controlling und Personalverwaltung zuständig. Außerhalb des Büros ist sie sportlich unterwegs und widmet sich neben Tennis hauptsächlich dem professionellem Yoga. Hier macht sie gerade die offizielle Trainer-Ausbildung und kann dann die älter werdende Belegschaft bei NETWAYS ertüchtigen.