Für den IaaS-Service (Virtuelles Rechenzentrum) bieten wir in eine kommerzielle Orchestrierungslösung (FCO) an. Diese Lösung zeichnet sich durch eine ziemlich einzigartige Architektur aus, die sie von den allgemein bekannten Openstack und CloudStack unterscheidet.
Als Hypervisoren für die Compute-Knoten werden KVM, VmWare, Xen, Virtuozzo6/7 sowie Container von Virtuozzo unterstützt. Zu den unterstützten Speicherarten zählen – lokal, NFS, Ceph und Virtuozzo Storage.
FCO unterstützt die Erstellung mehrerer Cluster und deren Verwaltung über eine einzige Schnittstelle. Das heißt, man kann zwischen einem Virtuozzo-Cluster und einem KVM + Ceph-Cluster mit einem Mausklick wechseln.
Grundsätzlich ist FCO eine umfassende Lösung für Cloud-Anbieter, die neben der Orchestrierung auch Abrechnungsfunktionen mit allen Einstellungen, Zahlungs-Plugins, Rechnungen, Benachrichtigungen, Wiederverkäufern, Tarifen und so weiter umfasst. Die Abrechnungsfunktion ist jedoch nicht in der Lage, alle russischen Besonderheiten abzudecken, weshalb wir uns entschieden haben, sie zugunsten einer anderen Lösung nicht zu verwenden.
Besonders erfreulich ist das flexible System zur Verteilung von Rechten auf alle Ressourcen der Cloud: Images, Festplatten, Produkte, Server, Firewalls – all das kann 'geteilt' und zwischen Benutzern sowie sogar zwischen Benutzern unterschiedlicher Kunden verwaltet werden. Jeder Kunde kann in seiner Cloud mehrere unabhängige Rechenzentren erstellen und diese über ein einheitliches Dashboard verwalten.
Architektonisch besteht FCO aus mehreren Teilen, von denen jeder seinen eigenen unabhängigen Code hat, einige sogar ihre eigene Datenbank.
Skyline – Admin- und Benutzeroberfläche
Jade – Geschäftslogik, Abrechnung, Aufgabenmanagement
Tigerlily – Dienstkoordinator, der den Austausch von Informationen zwischen Geschäftslogik und Clustern verwaltet und koordiniert.
XVPManager – Verwaltung der Cluster-Elemente: Knoten, Speicher, Netzwerke und virtuelle Maschinen.
XVPAgent – Agent, der auf Knoten installiert wird, um mit XVPManager zu interagieren
Einen detaillierten Bericht über die Architektur jedes einzelnen Komponentens planen wir in einem Artikelzyklus zu präsentieren, falls das Thema natürlich Interesse weckt.
Der Hauptvorteil von FCO resultiert aus seiner "Kastenform". Für Sie stehen Einfachheit und Minimalismus zur Verfügung. Für die Steuerungseinheit wird eine virtuelle Maschine unter Ubuntu bereitgestellt, in die alle notwendigen Pakete installiert werden. Alle Einstellungen werden in Konfigurationsdateien im Format variable-Wert ausgelagert:
# 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 den Vorlagen bearbeitet, anschließend wird der Generator gestartet.
#build-config который сформирует файл vars и даст команду сервисам перечитать конфиг. Пользовательский интерфейс приятный и может быть легко забрендирован.
Wie zu sehen ist, besteht die Benutzeroberfläche aus Widgets, deren Verwaltung für den Benutzer zugänglich ist. Er kann Widgets ganz einfach von der Seite hinzufügen oder entfernen und damit sein gewünschtes Dashboard erstellen.
Trotz ihrer Geschlossenheit ist FCO ein sehr anpassbares System. Es verfügt über eine enorme Anzahl von Einstellungen und Einstiegspunkten zur Änderung des Workflows:
- Es werden benutzerdefinierte Plugins unterstützt, zum Beispiel können Sie Ihre eigene Abrechnungsmethode oder eine eigene externe Ressource zur Bereitstellung für den Benutzer schreiben.
- Es werden benutzerdefinierte Trigger für bestimmte Ereignisse unterstützt, zum Beispiel das Hinzufügen der ersten virtuellen Maschine zu einem Kunden bei dessen Erstellung.
- Es werden benutzerdefinierte Widgets in der Benutzeroberfläche unterstützt, zum Beispiel ein Video von YouTube direkt in die Benutzeroberfläche integrieren.
Alle Anpassungen werden in der FDL-Sprache geschrieben, die auf Lua basiert. Wenn Sie Lua kennen, wird es keine Probleme mit FDL geben.
Hier ist ein Beispiel für einen der einfachsten Trigger, die wir verwenden. Dieser Trigger erlaubt es den Benutzern nicht, ihre eigenen Images mit anderen Kunden zu teilen. Wir tun dies, damit ein Benutzer kein schädliches Image für andere Benutzer erstellen kann.
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 muss. Der Parameter "p" dieser Funktion speichert den Kontext des Aufrufs, und bei der ersten Ausführung wird er leer (nil) sein. Dies ermöglicht es uns, unseren Trigger zu registrieren. In triggerType zeigen wir an, dass der Trigger VOR der Veröffentlichung der Operation aufgerufen wird und nur für Benutzer gilt. Systemadministratoren erlauben wir selbstverständlich, alles zu veröffentlichen. In triggerOptions detaillieren wir die Operationen, für die der Trigger aktiv wird.
Und das Wichtigste – return {exitState = "CANCEL"}, wofür der Trigger entwickelt wurde. Er wird einen Misserfolg zurückgeben, wenn der Benutzer versucht, sein Image im Dashboard zu teilen.
In der Architektur von FCO wird jedes Objekt (Disk, Server, Image, Netzwerk, Netzwerkadapter usw.) als Entität Resource dargestellt, die über gemeinsame Parameter verfügt:
- UUID der Ressource
- Name der Ressource
- Typ der Ressource
- UUID des Eigentümers der Ressource
- Status der Ressource (aktiv, inaktiv)
- Metadaten der Ressource
- Schlüssel der Ressource
- UUID des Produkts, zu dem die Ressource gehört
- VDC der Ressource
Dies ist sehr praktisch bei der Arbeit mit der API, da mit allen Ressourcen nach demselben Prinzip gearbeitet wird. Produkte werden vom Anbieter konfiguriert, und die Bestellung erfolgt durch den Kunden. Da sich unsere Abrechnung separat befindet, kann der Kunde jederzeit kostenlos ein beliebiges Produkt über das Panel bestellen. Es wird später in der Abrechnung berücksichtigt. Ein Produkt kann eine IP-Adresse pro Stunde, zusätzliches GB Speicher pro Stunde oder einfach ein Server sein.
Mit Schlüsseln können bestimmte Ressourcen gekennzeichnet werden, um die Logik der Arbeit mit ihnen zu ändern. Zum Beispiel können wir drei physische Knoten mit dem Schlüssel Weight kennzeichnen und einige Kunden mit demselben Schlüssel markieren, wodurch diese Knoten bestimmten Kunden zugewiesen werden. Dieser Mechanismus wird für VIP-Kunden verwendet, die keine Nachbarn neben ihren VMs mögen. Die Funktionalität kann jedoch viel breiter angewendet werden.
Das Lizenzmodell sieht eine Bezahlung für jeden Prozessor-Kern des physischen Knotens vor. Auch die Kosten hängen von der Anzahl der Cluster-Typen ab. Wenn beispielsweise KVM und VMware zusammen verwendet werden sollen, steigen die Lizenzkosten.
FCO ist ein vollwertiges Produkt mit einer sehr umfangreichen Funktionalität, weshalb wir planen, mehrere Artikel zur detaillierten Beschreibung der Netzwerkfunktionen vorzubereiten.
Nach mehreren Jahren der Arbeit mit diesem Orchestrator können wir ihn als sehr wertvoll einstufen. Leider weist das Produkt einige Mängel auf:
- Wir mussten die Datenbank optimieren, da die Abfragen bei steigendem Datenvolumen zu stagnieren begannen;
- Nach einem Vorfall hat der Recovery-Mechanismus aufgrund eines Fehlers nicht funktioniert, und wir mussten die Maschinen der unglücklichen Kunden mit unserem eigenen Satz von Skripten wiederherstellen;
- Der Mechanismus zur Erkennung der Nichterreichbarkeit eines Knotens ist im Code verankert und kann nicht angepasst werden. Das bedeutet, dass wir keine eigenen Richtlinien zur Bestimmung der Nichterreichbarkeit eines Knotens erstellen können.
- Das Logging ist nicht immer detailliert. Manchmal, wenn man auf eine sehr niedrige Ebene gehen muss, um ein bestimmtes Problem zu verstehen, 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 verfügt FCO über eine breite Funktionalität. In zukünftigen Artikeln planen wir, uns mit folgenden Themen näher zu beschäftigen:
- Organisation des Netzwerks in FCO
- Sicherung der Live-Wiederherstellung und des FQP-Protokolls
- Schreiben eigener Plugins und Widgets
- Anbindung zusätzlicher Dienste wie Load Balancer und Acronis
- Backup
- Einheitlicher Mechanismus zur Konfiguration und Einstellung von Knoten
- Verarbeitung von Metadaten virtueller Maschinen
P.S. Schreibt in die Kommentare, wenn euch auch andere Aspekte interessieren. Bleibt dran!
Quelle: habr.com
