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.
NETWAYS Blog
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. 😉
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:
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:
(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:
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.
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:
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
Senior Systems Engineer
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. Seit Anfang 2016 ist er bei uns tätig. Zuerst im Managed Services Team, dort kümmerte Tim sich um Infrastrukturthemen und den internen Support, um dann 2019 - zusammen mit Marius - Gründungsmitglied der ITSM Abteilung zu werden. 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...
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”
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”
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
Achtung bei den VLANs und den Templates. Hier nicht Name des Netzwerks und seine ID durcheinander bringen.
In Summe sollte das Endergebnis so aussehen:
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
Senior Systems Engineer
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. Seit Anfang 2016 ist er bei uns tätig. Zuerst im Managed Services Team, dort kümmerte Tim sich um Infrastrukturthemen und den internen Support, um dann 2019 - zusammen mit Marius - Gründungsmitglied der ITSM Abteilung zu werden. 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...
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.
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 Erk
Head of Finance & Administration
Vanessa ist unsere Leiterin des Finanzbereichs. Zusammen mit ihrem Team verantwortet sie das Controlling, den Cashflow sowie die Personalangelegenheiten in der Unternehmensgruppe. Abseits des Büros taucht sie leidenschaftlich gerne in die Welt des Yogas ein – vor allem im Bereich Frauen und Kinder. Durch zahlreiche Weiterbildungen hat sie ihr Fachwissen dazu vertieft und ist Expertin in ihrem Gebiet. Als Mutter von 2 Kindern kümmert sie sich liebevoll um ihre Tochter und ihren Sohn. In ihrer Freizeit liebt sie es, mit ihrer Familie zu reisen und neue Orte zu erkunden. Dabei genießt sie besonders die Zeit in der Natur und unternimmt...
