Um IaaS-Dienste (Virtual Data Center) bereitzustellen, haben wir Wir verwenden einen kommerziellen Orchestrator (FCO). Diese Lösung verfügt über eine ziemlich einzigartige Architektur, die sie von Openstack und CloudStack unterscheidet, die der breiten Öffentlichkeit bekannt sind.
KVM, VmWare, Xen, Virtuozzo6/7 sowie Container aus demselben Virtuozzo werden als Rechenknoten-Hypervisoren unterstützt. Zu den unterstützten Speicheroptionen gehören lokaler, NFS-, Ceph- und Virtuozzo-Speicher.
FCO unterstützt die Erstellung und Verwaltung mehrerer Cluster über eine einzige Schnittstelle. Das heißt, Sie können einen Virtuozzo-Cluster und einen KVM + Ceph-Cluster verwalten, indem Sie per Mausklick zwischen ihnen wechseln.
Im Kern handelt es sich bei FCO um eine umfassende Lösung für Cloud-Anbieter, die neben der Orchestrierung auch die Abrechnung umfasst, mit allen Einstellungen, Zahlungs-Plugins, Rechnungen, Benachrichtigungen, Resellern, Tarifen usw. Der Abrechnungsteil ist jedoch nicht in der Lage, alle russischen Nuancen abzudecken, weshalb wir auf die Verwendung zugunsten einer anderen Lösung verzichtet haben.
Ich bin sehr zufrieden mit dem flexiblen System zur Rechteverteilung auf alle Cloud-Ressourcen: Bilder, Festplatten, Produkte, Server, Firewalls – all dies kann zwischen Benutzern und sogar zwischen Benutzern verschiedener Clients „geteilt“ und mit Rechten versehen werden. Jeder Kunde kann mehrere unabhängige Rechenzentren in seiner Cloud erstellen und diese über ein einziges Bedienfeld verwalten.
Architektonisch besteht FCO aus mehreren Teilen, von denen jeder über einen eigenen unabhängigen Code und einige über eine eigene Datenbank verfügt.
Skyline – Admin- und Benutzeroberfläche
Jade – Geschäftslogik, Abrechnung, Aufgabenverwaltung
Tigerlilie – Servicekoordinator, verwaltet und koordiniert den Informationsaustausch zwischen Geschäftslogik und Clustern.
XVPManager – Verwaltung von Clusterelementen: Knoten, Speicher, Netzwerk und virtuelle Maschinen.
XVPAgent – ein auf Knoten installierter Agent zur Interaktion mit XVPManager
Wir planen, eine detaillierte Geschichte über die Architektur jeder Komponente in eine Artikelserie aufzunehmen, sofern das Thema natürlich Interesse weckt.
Der Hauptvorteil von FCO ergibt sich aus seiner „Box“-Beschaffenheit. Einfachheit und Minimalismus stehen Ihnen zur Verfügung. Für den Kontrollknoten ist eine virtuelle Maschine unter Ubuntu vorgesehen, in der alle notwendigen Pakete installiert werden. Alle Einstellungen werden in Form eines Variablenwerts in Konfigurationsdateien abgelegt:
# cat /etc/extility/config/vars
…
export LIMIT_MAX_LIST_ADMIN_DEFAULT="30000"
export LIMIT_MAX_LIST_USER_DEFAULT="200"
export LOGDIR="/var/log/extility"
export LOG_FILE="misc.log"
export LOG_FILE_LOG4JHOSTBILLMODULE="hostbillmodule.log"
export LOG_FILE_LOG4JJADE="jade.log"
export LOG_FILE_LOG4JTL="tigerlily.log"
export LOG_FILE_LOG4JXVP="xvpmanager.log"
export LOG_FILE_VARS="misc.log"
…
Die gesamte Konfiguration wird zunächst in Vorlagen bearbeitet, anschließend wird der Generator gestartet
#build-config, das eine Vars-Datei generiert und die Dienste anweist, die Konfiguration erneut zu lesen. Die Benutzeroberfläche ist schön und lässt sich leicht mit einem Branding versehen.
Wie Sie sehen, besteht die Oberfläche aus Widgets, die vom Benutzer gesteuert werden können. Er kann ganz einfach Widgets zur Seite hinzufügen/entfernen und so das Dashboard erstellen, das er benötigt.
Trotz seiner geschlossenen Natur ist FCO ein hochgradig anpassbares System. Es verfügt über eine Vielzahl von Einstellungen und Einstiegspunkten zur Änderung des Arbeitsablaufs:
- Benutzerdefinierte Plugins werden unterstützt. Sie können beispielsweise Ihre eigene Abrechnungsmethode oder Ihre eigene externe Ressource schreiben, um sie dem Benutzer zur Verfügung zu stellen
- Benutzerdefinierte Auslöser für bestimmte Ereignisse werden unterstützt, beispielsweise das Hinzufügen der ersten virtuellen Maschine zu einem Client, wenn dieser erstellt wird
- Benutzerdefinierte Widgets in der Benutzeroberfläche werden unterstützt, beispielsweise das direkte Einbetten eines YouTube-Videos in die Benutzeroberfläche.
Alle Anpassungen sind in FDL geschrieben, das auf Lua basiert. Wenn Sie Lua kennen, wird es mit FDL keine Probleme geben.
Hier ist ein Beispiel für einen der einfachsten Trigger, die wir verwenden. Dieser Auslöser ermöglicht es Benutzern nicht, ihre eigenen Bilder mit anderen Clients zu teilen. Wir tun dies, um zu verhindern, dass ein Benutzer ein schädliches Bild für andere Benutzer erstellt.
function register()
return {"pre_user_api_publish"}
end
function pre_user_api_publish(p)
if(p==nil) then
return{
ref = "cancelPublishImage",
name = "Cancel publishing",
description = "Cancel all user’s images publishing",
triggerType = "PRE_USER_API_CALL",
triggerOptions = {"publishResource", "publishImage"},
api = "TRIGGER",
version = 1,
}
end
-- Turn publishing off
return {exitState = "CANCEL"}
end
Die Registerfunktion wird vom FCO-Kernel aufgerufen. Es wird der Name der aufzurufenden Funktion zurückgegeben. Der Parameter „p“ dieser Funktion speichert den Aufrufkontext und ist beim ersten Aufruf leer (null). Dadurch können wir unseren Auslöser registrieren. In „triggerType“ geben wir an, dass der Trigger VOR dem Veröffentlichungsvorgang aufgerufen wird und nur Benutzer betrifft. Selbstverständlich erlauben wir Systemadministratoren, alles zu veröffentlichen. In triggerOptions beschreiben wir die Vorgänge, für die der Trigger ausgelöst wird.
Und die Hauptsache ist return {exitState = „CANCEL“}, weshalb der Trigger entwickelt wurde. Es wird ein Fehler zurückgegeben, wenn der Benutzer versucht, sein Bild in der Systemsteuerung freizugeben.
In der FCO-Architektur wird jedes Objekt (Festplatte, Server, Image, Netzwerk, Netzwerkadapter usw.) als Ressourcenentität dargestellt, die über gemeinsame Parameter verfügt:
- Ressourcen-UUID
- Ressourcenname
- Ressourcentyp
- UUID des Ressourceneigentümers
- Ressourcenstatus (aktiv, inaktiv)
- Ressourcenmetadaten
- Ressourcenschlüssel
- UUID des Produkts, das Eigentümer der Ressource ist
- Ressource VDC
Dies ist sehr praktisch, wenn mit einer API gearbeitet wird, wenn alle Ressourcen nach dem gleichen Prinzip arbeiten. Produkte werden vom Anbieter konfiguriert und vom Kunden bestellt. Da unsere Abrechnung nebenbei erfolgt, kann der Kunde jedes Produkt aus dem Panel frei bestellen. Die Berechnung erfolgt später in der Abrechnung. Das Produkt kann eine IP-Adresse pro Stunde, ein zusätzliches GB an Festplatte pro Stunde oder einfach nur ein Server sein.
Mit Schlüsseln können bestimmte Ressourcen markiert werden, um die Logik der Arbeit mit ihnen zu ändern. Beispielsweise können wir drei physische Knoten mit dem Gewichtungsschlüssel markieren und einige Clients mit demselben Schlüssel markieren und so diese Knoten diesen Clients persönlich zuweisen. Wir verwenden diesen Mechanismus für VIP-Clients, die keine Nachbarn neben ihren VMs mögen. Die Funktionalität selbst kann viel umfassender genutzt werden.
Beim Lizenzmodell wird für jeden Prozessorkern eines physischen Knotens bezahlt. Die Kosten werden auch von der Anzahl der Clustertypen beeinflusst. Wenn Sie beispielsweise KVM und VMware gemeinsam nutzen möchten, erhöhen sich die Lizenzkosten.
FCO ist ein vollwertiges Produkt mit sehr umfangreichen Funktionen. Daher planen wir, mehrere Artikel gleichzeitig mit einer detaillierten Beschreibung der Funktionsweise des Netzwerkteils vorzubereiten.
Da wir bereits mehrere Jahre mit diesem Orchestrator zusammengearbeitet haben, können wir ihn als sehr geeignet bezeichnen. Leider ist das Produkt nicht ohne Mängel:
- Wir mussten die Datenbank optimieren, da die Abfragen mit zunehmender Datenmenge langsamer wurden.
- Nach einem Unfall funktionierte der Wiederherstellungsmechanismus aufgrund eines Fehlers nicht und wir mussten die Autos unglücklicher Kunden mithilfe unserer eigenen Skripte wiederherstellen.
- Der Mechanismus zur Erkennung der Nichtverfügbarkeit eines Knotens ist fest im Code verankert und kann nicht angepasst werden. Das heißt, wir können keine eigenen Richtlinien erstellen, um die Nichtverfügbarkeit eines Knotens zu bestimmen.
- Die Protokollierung ist nicht immer detailliert. Manchmal, wenn Sie auf eine sehr niedrige Ebene vordringen müssen, um ein bestimmtes Problem zu verstehen, verfügen Sie für einige Komponenten nicht über genügend Quellcode, um zu verstehen, warum.
TOTAL: Generell sind die Eindrücke vom Produkt gut. Wir stehen in ständigem Kontakt mit den Orchestrator-Entwicklern. Die Jungs sind zu einer konstruktiven Zusammenarbeit geneigt.
Trotz seiner Einfachheit verfügt FCO über eine breite Funktionalität. In zukünftigen Artikeln planen wir, uns eingehender mit den folgenden Themen zu befassen:
- Networking bei FCO
- Bereitstellung von Live-Recovery und FQP-Protokoll
- Schreiben Sie Ihre eigenen Plugins und Widgets
- Anbindung zusätzlicher Dienste wie Load Balancer und Acronis
- Sicherung
- einheitlicher Mechanismus zum Konfigurieren und Konfigurieren von Knoten
- Verarbeitung von Metadaten virtueller Maschinen
ZY Schreiben Sie in die Kommentare, wenn Sie an anderen Aspekten interessiert sind. Bleiben Sie dran!
Source: habr.com