Um den IaaS-Dienst (Virtuelles Rechenzentrum) anzubieten, nutzen wir einen kommerziellen Orchestrator (FCO). Dieses Lösung verfügt über eine einzigartige Architektur, die sie von den weithin bekannten OpenStack und CloudStack unterscheidet.
Als Hypervisoren für die Compute-Knoten werden KVM, VmWare, Xen, Virtuozzo6/7 sowie Container von Virtuozzo unterstützt. Unterstützte Speichersysteme umfassen lokales Storage, NFS, Ceph und Virtuozzo Storage.
FCO ermöglicht die Erstellung mehrerer Cluster und deren Verwaltung über eine einzige Oberfläche. Das bedeutet, dass Sie zwischen einem Virtuozzo-Cluster und einem KVM + Ceph-Cluster mit einem Mausklick wechseln können.
Im Wesentlichen ist FCO eine umfassende Lösung für Cloud-Anbieter, die neben der Orchestrierung auch Abrechnung miteinander verbindet, einschließlich aller Einstellungen, Zahlungs-Plugins, Rechnungen, Benachrichtigungen, Reseller, Tarife und mehr. Die Abrechnungsfunktion kann jedoch nicht alle spezifischen Anforderungen in Russland abdecken, weshalb wir uns entschieden haben, sie zugunsten einer anderen Lösung nicht zu verwenden.
Das flexible System zur Verteilung von Rechten auf alle Cloud-Ressourcen wie Images, Festplatten, Produkte, Server und Firewalls ist sehr erfreulich – alles kann zwischen Benutzern und sogar zwischen Benutzern verschiedener Kunden „geteilt“ und Rechte vergeben werden. Jeder Kunde kann in seiner Cloud mehrere unabhängige Rechenzentren erstellen und diese aus einem einheitlichen Dashboard verwalten.
Architektonisch besteht FCO aus mehreren Teilen, von denen jeder seinen eigenen unabhängigen Code hat und einige sogar ihre eigene Datenbank.
Skyline – Admin- und Benutzeroberfläche
Jade – Geschäftslogik, Abrechnung, Taskmanagement
Tigerlily – Servicekoordinator, der den Austausch von Informationen zwischen Geschäftslogik und Clustern verwaltet und koordiniert.
XVPManager – Verwaltung der Clusterkomponenten: Knoten, Speicher, Netzwerk und virtuelle Maschinen.
XVPAgent – Agent, der auf Knoten installiert wird, um mit XVPManager zu interagieren.
Einen detaillierten Bericht über die Architektur jedes einzelnen Components planen wir in einer Serie von Artikeln zu veröffentlichen, sofern das Thema auf Interesse stößt.
Der Hauptvorteil von FCO liegt in seiner "Kastenform". Ihnen steht Einfachheit und Minimalismus zur Verfügung. Für die Verwaltungsnode wird eine virtuelle Maschine unter Ubuntu bereitgestellt, in die alle notwendigen Pakete installiert werden. Alle Einstellungen werden in Konfigurationsdateien in der Form von Schlüssel-Wert-Paaren ausgeführt:
# 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 und anschließend der Generator gestartet.
#build-config который сформирует файл vars и даст команду сервисам перечитать конфиг. Пользовательский интерфейс приятный и может быть легко забрендирован.
Wie zu sehen ist, besteht die Benutzeroberfläche aus Widgets, deren Steuerung dem Benutzer zur Verfügung steht. Er kann Widgets einfach von der Seite hinzufügen oder entfernen und so sein gewünschtes Dashboard gestalten.
Trotz ihrer Geschlossenheit ist FCO ein äußerst anpassbares System. Es gibt eine enorme Anzahl von Einstellungen und Zugangspunkten zur Veränderung des Workflows:
- Es werden benutzerdefinierte Plugins unterstützt, beispielsweise können Sie Ihre eigene Abrechnungsmethode oder eine externe Ressource zur Bereitstellung an den Benutzer schreiben.
- Benutzerdefinierte Trigger für bestimmte Ereignisse werden unterstützt, zum Beispiel das Hinzufügen der ersten virtuellen Maschine für einen Kunden bei dessen Erstellung.
- Benutzerdefinierte Widgets in der Benutzeroberfläche werden unterstützt, beispielsweise um ein Video von YouTube direkt in die Benutzeroberfläche einzubetten.
Alle Anpassungen werden in der FDL-Sprache geschrieben, die auf Lua basiert. Wenn Sie Lua kennen, werden Sie mit FDL keine Probleme haben.
Hier ist ein Beispiel für einen der einfachsten Trigger, die wir verwenden. Dieser Trigger verhindert, dass Benutzer ihre eigenen Abbildungen mit anderen Kunden teilen. Wir tun dies, um zu verhindern, dass ein Benutzer ein schädliches Abbild 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 Funktion register wird vom FCO-Kern aufgerufen. Sie gibt den Namen der Funktion zurück, die aufgerufen werden soll. Der Parameter „p“ dieser Funktion speichert den Kontext des Aufrufs und ist beim ersten Aufruf leer (nil). Dies ermöglicht uns, unseren Trigger zu registrieren. Im triggerType geben wir an, dass der Trigger VOR der Veröffentlichung ausgeführt wird und nur für Benutzer gilt. Administratoren des Systems erlauben wir selbstverständlich, alles zu veröffentlichen. In triggerOptions spezifizieren wir die Operationen, für die der Trigger aktiviert wird.
Und das Wichtigste – return {exitState = "CANCEL"}, wofür der Trigger entwickelt wurde. Er gibt einen Misserfolg zurück, wenn der Benutzer versucht, sein Abbild im Control Panel zu teilen.
In der FCO-Architektur wird jedes Objekt (Festplatte, Server, Image, Netzwerk, Netzwerkadapter usw.) als Ressourceneinheit dargestellt, die gemeinsame Parameter hat:
- UUID der Ressource
- Name der Ressource
- Typ der Ressource
- UUID des Ressourcenbesitzers
- Status der Ressource (aktiv, inaktiv)
- Metadaten der Ressource
- Schlüssel der Ressource
- UUID des Produkts, zu dem die Ressource gehört
- VDC der Ressource
Das ist sehr praktisch bei der Arbeit mit der API, da mit allen Ressourcen nach einem einheitlichen Prinzip gearbeitet wird. Die Produkte werden vom Anbieter konfiguriert und vom Kunden bestellt. Da unser Billing getrennt ist, kann der Kunde über das Panel kostenlos beliebige Produkte bestellen. Die Abrechnung erfolgt später im Billing. Ein Produkt kann sein – eine IP-Adresse pro Stunde, zusätzlicher GB Speicher pro Stunde oder einfach ein Server.
Mit Schlüsseln können bestimmte Ressourcen markiert werden, um die Logik ihrer Bearbeitung zu ändern. Zum Beispiel können wir drei physische Nodes mit dem Schlüssel Weight markieren und bestimmten Kunden denselben Schlüssel zuweisen, wodurch diese Nodes exklusiv für diese Kunden hervorgehoben werden. Diese Mechanik verwenden wir für VIP-Kunden, die keine Nachbarn neben ihren VMs mögen. Die Funktionalität kann jedoch viel breiter angewendet werden.
Das Lizenzmodell sieht eine Bezahlung pro CPU-Kern der physischen Node vor. Auch die Anzahl der Clusterarten beeinflusst die Kosten. Wenn beispielsweise KVM und VMware zusammen genutzt werden sollen, erhöht sich der Lizenzpreis.
FCO ist ein vollwertiges Produkt mit einer sehr umfangreichen Funktionalität. Daher planen wir, mehrere Artikel mit detaillierten Beschreibungen der Funktionen des Netzwerkbereichs vorzubereiten.
Nach mehreren Jahren mit diesem Orchestrator können wir ihn als sehr brauchbar betrachten. Leider ist das Produkt nicht frei von Mängeln:
- Wir mussten die Datenbank optimieren, da die Anfragen bei wachsendem Datenvolumen anfingen, zu verzögern;
- Nach einem Vorfall funktionierte der Recovery-Mechanismus aufgrund eines Bugs nicht, und wir mussten die Systeme der betroffenen Kunden mit einer eigenen Skriptsammlung wiederherstellen;
- Der Mechanismus zur Erkennung der Nichterreichbarkeit einer Node ist im Code fest verankert und kann nicht angepasst werden. Das bedeutet, dass wir keine eigenen Richtlinien zur Bestimmung der Nichterreichbarkeit einer Node erstellen können.
- Das Protokollieren ist nicht immer ausführlich. Manchmal, wenn man auf eine sehr tiefe Ebene gehen muss, um ein bestimmtes Problem zu analysieren, fehlen die Quellcodes einiger Komponenten, um die Ursachen zu verstehen;
GESAMT: Insgesamt sind die Eindrücke vom Produkt positiv. Wir stehen in ständigem Kontakt mit den Entwicklern des Orchestrators. Die Jungs sind offen für konstruktive Zusammenarbeit.
Trotz seiner Einfachheit bietet FCO eine breite Funktionalität. In zukünftigen Artikeln planen wir, uns mit folgenden Themen intensiver zu befassen:
- Netzwerkorganisation in FCO
- Gewährleistung von Live-Wiederherstellung und FQP-Protokoll
- Erstellen eigener Plugins und Widgets
- Anschluss zusätzlicher Dienste wie Load Balancer und Acronis
- Backup
- Einheitlicher Mechanismus zur Konfiguration und Einrichtung von Nodes
- Verwaltung von Metadaten virtueller Maschinen
P.S. Schreiben Sie in die Kommentare, wenn Sie an anderen Aspekten interessiert sind. Bleiben Sie dran!
Quelle: habr.com
