Hallo zusammen. Dieser Artikel richtet sich an diejenigen, die zwischen verschiedenen Virtualisierungsplattformen schwanken, besonders nach dem Lesen des Artikels in der Reihe „Proxmox installiert und alles läuft super, 6 Jahre Uptime ohne Unterbrechung“. Doch nach der Installation einer bestimmten Box-Lösung stellt sich die Frage, wie man hier und da Anpassungen vornehmen kann, damit das Monitoring verständlicher wird, und wie man hier kontrollieren kann, ob Backups ordnungsgemäß durchgeführt werden. Und dann kommt der Zeitpunkt, an dem man erkennt, dass man etwas Funktionaleres möchte, oder dass man möchte, dass alles in seinem System klar und übersichtlich ist, anstatt in einem schwarzen Kasten zu arbeiten, oder dass man gerne mehr nutzen möchte als nur einen Hypervisor und eine Menge virtueller Maschinen. In diesem Artikel werden einige Überlegungen und praktischen Erfahrungen mit der Plattform OpenNebula geteilt — ich habe diese gewählt, da sie nicht ressourcenintensiv ist und die Architektur recht einfach ist.
Wie viele Cloud-Anbieter, die auf KVM basieren, machen eine externe Anbindung zur Verwaltung von Maschinen. Es ist offensichtlich, dass große Hosting-Unternehmen ihre eigenen Anbindungen für Cloud-Infrastrukturen entwickeln, wie zum Beispiel YANDEX. Einige nutzen OpenStack und erstellen darauf basierende Anbindungen — SELECTEL, MAIL.RU. Wenn Sie jedoch eigene Hardware und ein kleines Team von Spezialisten haben, wählen die meisten in der Regel etwas Fertiges — VMWARE, HYPER-V, es gibt kostenlose und kostenpflichtige Lizenzen, aber jetzt nicht darüber. Sprechen wir über Enthusiasten — das sind die, die nicht zögern, innovative Lösungen anzubieten und auszuprobieren, obwohl das Unternehmen offensichtlich signalisiert hat: "Wer wird das nach dir warten?", "Wird das etwa in die Produktion gehen? Das ist beängstigend." Aber man kann diese Lösungen zunächst im Testumfeld anwenden, und wenn es allen gefällt, kann man die Frage nach der Weiterentwicklung und dem Einsatz in ernsthafteren Umgebungen aufwerfen.
Hier ist auch der Link zur Präsentation von einem aktiven Teilnehmer an der Entwicklung dieser Plattform.
In diesem Artikel könnte es etwas geben, das für einen erfahrenen Fachmann überflüssig und bereits klar ist. In einigen Fällen werde ich nicht alles beschreiben, da solche Befehle und Erklärungen im Internet vorhanden sind. Hier teile ich nur meine Erfahrung mit dieser Plattform. Ich hoffe, dass aktive Teilnehmer in den Kommentaren ergänzen, was verbessert werden kann und wo ich Fehler gemacht habe. Alle Aktivitäten fanden unter den Bedingungen eines Heimstandes statt, der aus drei PCs mit unterschiedlichen Spezifikationen bestand. Außerdem habe ich absichtlich nicht angegeben, wie diese Software funktioniert und wie man sie installiert. Es geht nur um meine Erfahrungen in der Administration und die Probleme, auf die ich gestoßen bin. Vielleicht ist das für jemanden hilfreich bei der Auswahl.
So, fangen wir an. Mir als Systemadministrator sind folgende Punkte wichtig, ohne die ich diese Lösung kaum verwenden werde.
1. Wiederholbarkeit der Installation
Es gibt viele Anleitungen zur Installation von OpenNebula, hier sollte es keine Probleme geben. Von Version zu Version kommen neue Funktionen hinzu, die beim Versionswechsel nicht immer funktionieren.
2. Überwachung
Wir werden die Node, KVM und OpenNebula überwachen. Zum Glück gibt es bereits eine Lösung. Für das Monitoring von Linux-Hosts gibt es zahlreiche Optionen, wie Zabbix oder Node Exporter — je nach Vorliebe. Momentan bestimme ich, dass die Überwachung systemrelevanter Metriken (Temperatur, wo sie messbar ist, und die Konsistenz des Speicher-Arrays) über Zabbix erfolgt, während die Anwendungsüberwachung über einen Exporter für Prometheus abgewickelt wird. Zum Beispiel kann für die KVM-Überwachung ein Projekt verwendet werden. und wir setzen den Start über systemd auf, was gut funktioniert und KVM-Metriken anzeigt. Es gibt auch ein fertiges Dashboard. .
Zum Beispiel, hier ist meine Datei:
/etc/systemd/system/libvirtd_exporter.service
[Unit]
Description=Node Exporter
[Service]
User=node_exporter
ExecStart=/usr/sbin/prometheus-libvirt-exporter --web.listen-address=":9101"
[Install]
WantedBy=multi-user.targetUnd so haben wir einen Exporter, wir benötigen einen zweiten zur Überwachung von OpenNebula, ich habe den folgenden verwendet.
Dies kann zu einem normalen hinzugefügt werden, um das System zu überwachen.
In der Datei des Node Exporters ändern wir den Start wie folgt:
ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collectorWir erstellen das Verzeichnis mkdir -p /var/lib/opennebula_exporter
Das oben dargestellte Bash-Skript überprüfen wir zunächst über die Konsole. Wenn es das Erwartete anzeigt (bei Fehlern installieren wir xmlstarlet), kopieren wir es nach /usr/local/bin/opennebula_exporter.sh.
Fügen Sie einen Cron-Job für jede Minute hinzu:
*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)Die Metriken erscheinen jetzt, sie können mit Prometheus abgerufen werden, um Grafiken zu erstellen und Alarme einzurichten. In Grafana kann man beispielsweise ein einfaches Dashboard erstellen.
(Hier habe ich eine Overcommitierung für CPU und RAM vorgenommen.)
Für diejenigen, die Zabbix lieben und verwenden, gibt es
Das Monitoring ist jetzt vollständig, das Wichtigste ist vorhanden. Natürlich kann man zusätzlich die integrierten Monitoring-Tools der virtuellen Maschinen verwenden, um Daten in die Abrechnung zu übertragen; hier hat jeder seine eigene Perspektive, und ich habe bisher noch nicht intensiv damit begonnen.
Beim Logging bin ich bisher nicht wirklich weitergekommen. Der einfachste Weg wäre, den td-agent hinzuzufügen, um das Verzeichnis /var/lib/one mit regulären Ausdrücken zu parsen. Beispielsweise passt die Datei sunstone.log unter den regexp nginx und andere Dateien, die die Historie der Zugriffe auf die Plattform zeigen – was ist der Vorteil dabei? Nun, wir können die Anzahl der "Error, error" eindeutig nachverfolgen und schneller erkennen, wo und auf welcher Ebene ein Problem besteht.
3. Backups
Es gibt auch kostenpflichtige, verbesserte Projekte – beispielsweise sep :OpenNebula_Backup. Hier müssen wir verstehen, dass es nicht darum geht, einfach ein Maschinenbild zu sichern, denn unsere virtuellen Maschinen sollten mit voller Integration arbeiten (im selben Kontext die Datei, in der Netzwerkeinstellungen, der Name der VM und benutzerdefinierte Einstellungen für Ihre Anwendungen beschrieben sind). Daher legen wir fest, was und wie wir sichern werden. In einigen Fällen ist es besser, Kopien von dem zu machen, was sich in der VM selbst befindet. Möglicherweise müssen wir sogar nur eine Festplatte dieser Maschine sichern.
Zum Beispiel haben wir festgelegt, dass alle Maschinen mit persistenten Images gestartet werden, daher haben wir gelesen
Das bedeutet, dass wir zuerst mit unserer VM ein Image exportieren können:
onevm disk-saveas 74 3 prom.qcow2
Image-ID: 77
Lassen Sie uns schauen, unter welchem Namen es gespeichert wurde
oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
Und dann kopieren wir es an den gewünschten Ort. Natürlich ist das nicht die beste Methode. Ich wollte nur zeigen, dass man mit den Tools von OpenNebula solche Lösungen aufbauen kann.Ich habe auch im Internet gefunden und es gibt noch , aber hier nur für qcow2-Speicher.
Wie wir alle wissen, kommt irgendwann der Moment, an dem man inkrementelle Backups möchte, das ist komplizierter und möglicherweise wird das Management Geld für eine kostenpflichtige Lösung bereitstellen, oder man geht einen anderen Weg und versteht, dass wir hier nur Ressourcen verbrauchen und das Backup auf Anwenderebene machen und die Anzahl neuer Nodes und VMs erhöhen — hier sage ich, dass man die Cloud rein für den Betrieb von Anwendungsclustern nutzen sollte und die Datenbank auf einer anderen Plattform betreiben oder eine fertige von einem Anbieter nehmen sollte, wenn dies möglich ist.
4. Benutzerfreundlichkeit
In diesem Abschnitt werde ich die Probleme beschreiben, mit denen ich konfrontiert war. Zum Beispiel, bei Images gibt es das persistent-Format: Wenn dieses Image an die VM angebunden wird, werden alle Daten in dieses Image geschrieben. Bei non-persistent wird das Image auf den Speicher kopiert und die Daten werden in das geschrieben, was vom ursprünglichen Image kopiert wurde – so funktionieren die Vorlagen. Ich habe mir oft selbst Probleme bereitet, indem ich vergessen habe, persistent anzugeben, wodurch 200 GB des Images kopiert wurden. Das Problem ist, dass dieses Verfahren in der Regel nicht abgebrochen werden kann, man muss zur Node gehen und den aktuellen „cp“-Prozess stoppen.
Ein wichtiger Nachteil ist, dass man die Aktionen nicht einfach über die GUI abbrechen kann. Genau genommen, man wird sie abbrechen und sieht, dass nichts passiert, und startet sie erneut, aber faktisch gibt es dann bereits zwei „cp“-Prozesse, die das Image kopieren.
Und hier wird deutlich, warum OpenNebula jeder neuen Instanz eine neue ID zuweist. Wenn man zum Beispiel in Proxmox eine VM mit der ID 101 erstellt, sie löscht und dann erneut erstellt, hat sie wieder die ID 101. Das wird es in OpenNebula nicht geben; jede neue Instanz wird mit einer neuen ID erstellt, und darin liegt eine gewisse Logik – zum Beispiel zur Bereinigung alter Daten oder gescheiterter Installationen.
Das Gleiche gilt für den Speicher, diese Plattform ist vor allem auf zentrale Speicherung ausgerichtet. Es gibt Add-ons, um lokale Speicherung zu nutzen, aber darum geht es hier nicht. Ich denke, dass in Zukunft jemand einen Artikel darüber schreiben wird, wie es gelungen ist, lokale Speicherung auf Knoten zu nutzen und erfolgreich in der Produktion einzusetzen.
5. Maximale Einfachheit
Natürlich versteht man hier mit der Zeit immer weniger Leute.
In den Bedingungen meines Standes — 3 Knoten mit NFS-Speicher — funktioniert alles einwandfrei. Aber wenn man Experimente zur Stromabschaltung durchführt, beispielsweise beim Starten eines Snapshots und der Abschaltung der Stromversorgung der Knoten, bleiben uns die Einstellungen in der Datenbank erhalten, dass es einen Snapshot gibt, in Wirklichkeit existiert er jedoch nicht (wir verstehen ja alle, dass ursprünglich in der SQL-Datenbank über diese Aktion geschrieben wurde, aber der Vorgang ist gescheitert). Der Vorteil ist, dass bei der Erstellung eines Snapshots eine separate Datei gebildet wird und es einen "Elternteil" gibt, sodass wir im Falle von Problemen, selbst wenn es über die GUI nicht funktioniert, die QCOW2-Datei abrufen und separat wiederherstellen können.
Leider ist es in Netzwerken nicht so einfach. Zumindest einfacher als in OpenStack. Ich habe nur VLAN (802.1Q) verwendet, das funktioniert ziemlich gut. Wenn Sie jedoch Änderungen an den Einstellungen des Template-Netzwerks vornehmen, gelten diese Änderungen nicht für bereits laufende Maschinen, d. h. Sie müssen die Netzwerkkarte entfernen und wieder hinzufügen, damit die neuen Einstellungen wirksam werden.
Wenn man es mit OpenStack vergleichen möchte, kann man sagen, dass es in OpenNebula keine klare Definition dafür gibt, welche Technologien für die Speicherung von Daten, Netzwerk- und Ressourcenmanagement verwendet werden sollen – jeder Administrator entscheidet selbst, was für ihn am besten ist.
6. Zusätzliche Plugins und Installationen
Wie wir verstehen, kann die Cloud-Plattform nicht nur KVM, sondern auch VMware ESXi verwalten. Leider hatte ich keinen Pool mit vCenter, wenn es jemand versucht hat, schreiben Sie bitte.
Bei anderen Cloud-Anbietern wurde erklärt
AWS, AZURE.
Ich habe auch versucht, VMware Cloud von Selectel zu integrieren, aber es hat nicht geklappt – ich habe aufgegeben, da es viele Faktoren gibt und es keinen Sinn macht, den technischen Support des Hosting-Anbieters zu kontaktieren.
Außerdem gibt es in der neuen Version Firecracker — das ist der Start von MicroVMs, eine Art KVM-Hülle über Docker, die noch mehr Vielseitigkeit, Sicherheit und Leistungssteigerung bietet, da keine Ressourcen für die Emulation von Hardware verschwendet werden müssen. Ich sehe nur Vorteile im Vergleich zu Docker, da es keine zusätzlichen Prozesse benötigt und keine Sockets belegt, wenn diese Emulation verwendet wird. Man kann es durchaus als Lastenausgleich verwenden (aber darüber sollte ich wahrscheinlich einen separaten Artikel schreiben, da ich noch nicht alle Tests vollständig durchgeführt habe).
7. Positive Erfahrungen und Debugging von Fehlern
Ich wollte meine Beobachtungen zur Arbeit teilen, einen Teil habe ich oben beschrieben, und ich möchte mehr schreiben. Tatsächlich bin ich wahrscheinlich nicht der Einzige, der zuerst denkt, dass dies nicht das richtige System ist und dass hier alles provisorisch ist — wie funktioniert man überhaupt damit? Doch dann kommt das Verständnis, dass alles durchaus logisch ist. Natürlich kann man es nicht allen recht machen, und einige Punkte erfordern Verbesserungen.
Beispielsweise eine einfache Operation, um ein Disk-Image von einem Datenspeicher auf einen anderen zu kopieren. In meinem Fall gibt es 2 Knoten mit NFS, ich sende das Image – die Kopie erfolgt über das Frontend von OpenNebula, obwohl wir es gewohnt sind, dass Daten direkt zwischen Hosts kopiert werden – wie bei VMware oder Hyper-V. Hier ist das anders. Hier gibt es einen anderen Ansatz und eine andere Ideologie, und in der Version 5.12 wurde der Button „migrate to datastore“ entfernt – nur die Maschine wird verschoben, nicht der Datenspeicher, da ein zentrales Speichersystem vorausgesetzt wird.
Weiterhin ein beliebter Fehler mit verschiedenen Ursachen: „Error deploying virtual machine: Could not create domain from /var/lib/one//datastores/103/10/deployment.5“. Nachfolgend wird eine Liste von Punkten präsentiert, die Sie überprüfen sollten.
- Rechte auf das Image für den Benutzer oneadmin;
- Rechte für den Benutzer oneadmin zum Starten von libvirtd;
- Ist der Datenspeicher korrekt montiert? Gehe und überprüfe den Pfad am Knoten selbst, möglicherweise ist etwas abgestürzt;
- Falsch konfigurierte Netzwerke. Genauer gesagt steht in den Netzwerkeinstellungen des Frontends, dass br0 als Hauptschnittstelle für VLAN verwendet wird, während am Knoten bridge0 konfiguriert ist – es muss übereinstimmen.
Das System-Datenspeicher speichert Metadaten für Ihre VM. Wenn Sie die VM mit einem persistenten Image starten, muss die VM auf die ursprünglich erstellte Konfiguration im Speicher zugreifen, in dem Sie die VM erstellt haben — das ist sehr wichtig. Daher müssen Sie beim Verschieben der VM auf einen anderen Datenspeicher alles sorgfältig überprüfen.
8. Dokumentation, Community. Weitere Entwicklung
Und alles andere, gute Dokumentation, eine Community und vor allem, dass das Projekt weiterhin lebt.
Hier ist alles insgesamt recht gut dokumentiert, und selbst über die offizielle Quelle wird es kein Problem sein, zu instalieren und Antworten auf Fragen zu finden.
Eine aktive Community. Sie veröffentlicht viele fertige Lösungen, die Sie in Ihren Installationen verwenden können.
Aktuell hat sich mit Version 5.12 einige Richtlinien im Unternehmen geändert. Es wird interessant sein zu erfahren, wie sich das Projekt entwickeln wird. Zu Beginn habe ich absichtlich einige Anbieter genannt, die ihre eigenen Lösungen und das, was die Industrie anbietet, verwenden. Eine klare Antwort darauf, was Sie verwenden sollten, gibt es natürlich nicht. Aber für kleine Organisationen kann die Unterstützung ihrer kleinen privaten Cloud weniger kosten, als es scheint. Wichtig ist nur, genau zu wissen, dass Sie das wirklich benötigen.
Zusammenfassend lässt sich sagen, dass es unabhängig davon, welches Cloud-System Sie gewählt haben, nicht sinnvoll ist, sich auf ein Produkt zu beschränken. Wenn Sie Zeit haben, sollten Sie sich auch anderen, offenen Lösungen zuwenden.
Es gibt einen guten Chat. der aktiv hilft und nicht dazu auffordert, Lösungen für Probleme bei Google zu suchen. Treten Sie bei.
Quelle: habr.com
