{"id":32318,"date":"2019-10-31T21:46:20","date_gmt":"2019-10-31T18:46:20","guid":{"rendered":"https:\/\/prohoster.info\/blog\/flexiant-cloud-orchestrator-s-chem-ego-edyat\/"},"modified":"2019-10-31T21:46:20","modified_gmt":"2019-10-31T18:46:20","slug":"flexiant-cloud-orchestrator-s-chem-ego-edyat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/flexiant-cloud-orchestrator-s-chem-ego-edyat","title":{"rendered":"Flexiant Cloud Orchestrator: was ist das?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Flexiant
\n
\nF\u00fcr den IaaS-Service (Virtuelles Rechenzentrum) bieten wir in Rusonyx<\/a><\/noindex> eine kommerzielle Orchestrierungsl\u00f6sung Flexiant Cloud Orchestrator<\/a><\/noindex> (FCO) an. Diese L\u00f6sung zeichnet sich durch eine ziemlich einzigartige Architektur aus, die sie von den allgemein bekannten Openstack und CloudStack unterscheidet.<\/a><\/noindex> <\/p>\n

Als Hypervisoren f\u00fcr die Compute-Knoten werden KVM, VmWare, Xen, Virtuozzo6\/7 sowie Container von Virtuozzo unterst\u00fctzt. Zu den unterst\u00fctzten Speicherarten z\u00e4hlen \u2013 lokal, NFS, Ceph und Virtuozzo Storage.<\/p>\n

FCO unterst\u00fctzt die Erstellung mehrerer Cluster und deren Verwaltung \u00fcber eine einzige Schnittstelle. Das hei\u00dft, man kann zwischen einem Virtuozzo-Cluster und einem KVM + Ceph-Cluster mit einem Mausklick wechseln.<\/p>\n

Grunds\u00e4tzlich ist FCO eine umfassende L\u00f6sung f\u00fcr Cloud-Anbieter, die neben der Orchestrierung auch Abrechnungsfunktionen mit allen Einstellungen, Zahlungs-Plugins, Rechnungen, Benachrichtigungen, Wiederverk\u00e4ufern, 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\u00f6sung nicht zu verwenden.<\/p>\n

Besonders erfreulich ist das flexible System zur Verteilung von Rechten auf alle Ressourcen der Cloud: Images, Festplatten, Produkte, Server, Firewalls \u2013 all das kann 'geteilt' und zwischen Benutzern sowie sogar zwischen Benutzern unterschiedlicher Kunden verwaltet werden. Jeder Kunde kann in seiner Cloud mehrere unabh\u00e4ngige Rechenzentren erstellen und diese \u00fcber ein einheitliches Dashboard verwalten.<\/p>\n

\"Flexiant
\n
\nArchitektonisch besteht FCO aus mehreren Teilen, von denen jeder seinen eigenen unabh\u00e4ngigen Code hat, einige sogar ihre eigene Datenbank.<\/p>\n

Skyline<\/b> \u2013 Admin- und Benutzeroberfl\u00e4che
\nJade<\/b> \u2013 Gesch\u00e4ftslogik, Abrechnung, Aufgabenmanagement
\nTigerlily<\/b> \u2013 Dienstkoordinator, der den Austausch von Informationen zwischen Gesch\u00e4ftslogik und Clustern verwaltet und koordiniert.
\nXVPManager<\/b> \u2013 Verwaltung der Cluster-Elemente: Knoten, Speicher, Netzwerke und virtuelle Maschinen.
\nXVPAgent <\/b>\u2013 Agent, der auf Knoten installiert wird, um mit XVPManager zu interagieren<\/p>\n

\"Flexiant
\n
\nEinen detaillierten Bericht \u00fcber die Architektur jedes einzelnen Komponentens planen wir in einem Artikelzyklus zu pr\u00e4sentieren, falls das Thema nat\u00fcrlich Interesse weckt.<\/p>\n

Der Hauptvorteil von FCO resultiert aus seiner \"Kastenform\". F\u00fcr Sie stehen Einfachheit und Minimalismus zur Verf\u00fcgung. F\u00fcr 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:<\/p>\n

# cat \/etc\/extility\/config\/vars\n\u2026\nexport LIMIT_MAX_LIST_ADMIN_DEFAULT=\"30000\"\nexport LIMIT_MAX_LIST_USER_DEFAULT=\"200\"\nexport LOGDIR=\"\/var\/log\/extility\"\nexport LOG_FILE=\"misc.log\"\nexport LOG_FILE_LOG4JHOSTBILLMODULE=\"hostbillmodule.log\"\nexport LOG_FILE_LOG4JJADE=\"jade.log\"\nexport LOG_FILE_LOG4JTL=\"tigerlily.log\"\nexport LOG_FILE_LOG4JXVP=\"xvpmanager.log\"\nexport LOG_FILE_VARS=\"misc.log\"\n\u2026\n<\/code><\/pre>\n
Die gesamte Konfiguration wird zun\u00e4chst in den Vorlagen bearbeitet, anschlie\u00dfend wird der Generator gestartet.
\n#build-config \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0441\u0444\u043e\u0440\u043c\u0438\u0440\u0443\u0435\u0442 \u0444\u0430\u0439\u043b vars \u0438 \u0434\u0430\u0441\u0442 \u043a\u043e\u043c\u0430\u043d\u0434\u0443 \u0441\u0435\u0440\u0432\u0438\u0441\u0430\u043c \u043f\u0435\u0440\u0435\u0447\u0438\u0442\u0430\u0442\u044c \u043a\u043e\u043d\u0444\u0438\u0433. \u041f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0438\u0439 \u0438\u043d\u0442\u0435\u0440\u0444\u0435\u0439\u0441 \u043f\u0440\u0438\u044f\u0442\u043d\u044b\u0439 \u0438 \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u043b\u0435\u0433\u043a\u043e \u0437\u0430\u0431\u0440\u0435\u043d\u0434\u0438\u0440\u043e\u0432\u0430\u043d.<\/p>\n
\"Flexiant
\n
\nWie zu sehen ist, besteht die Benutzeroberfl\u00e4che aus Widgets, deren Verwaltung f\u00fcr den Benutzer zug\u00e4nglich ist. Er kann Widgets ganz einfach von der Seite hinzuf\u00fcgen oder entfernen und damit sein gew\u00fcnschtes Dashboard erstellen.<\/p>\n
Trotz ihrer Geschlossenheit ist FCO ein sehr anpassbares System. Es verf\u00fcgt \u00fcber eine enorme Anzahl von Einstellungen und Einstiegspunkten zur \u00c4nderung des Workflows:<\/p>\n
    \n
  1. Es werden benutzerdefinierte Plugins unterst\u00fctzt, zum Beispiel k\u00f6nnen Sie Ihre eigene Abrechnungsmethode oder eine eigene externe Ressource zur Bereitstellung f\u00fcr den Benutzer schreiben.<\/li>\n
  2. Es werden benutzerdefinierte Trigger f\u00fcr bestimmte Ereignisse unterst\u00fctzt, zum Beispiel das Hinzuf\u00fcgen der ersten virtuellen Maschine zu einem Kunden bei dessen Erstellung.<\/li>\n
  3. Es werden benutzerdefinierte Widgets in der Benutzeroberfl\u00e4che unterst\u00fctzt, zum Beispiel ein Video von YouTube direkt in die Benutzeroberfl\u00e4che integrieren.<\/li>\n<\/ol>\n
    \nAlle Anpassungen werden in der FDL-Sprache geschrieben, die auf Lua basiert. Wenn Sie Lua kennen, wird es keine Probleme mit FDL geben.<\/p>\n
    Hier ist ein Beispiel f\u00fcr 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\u00e4dliches Image f\u00fcr andere Benutzer erstellen kann.<\/p>\n
    function register()\n    return {\"pre_user_api_publish\"}\nend\n   \nfunction pre_user_api_publish(p)  \n    if(p==nil) then\n        return{\n            ref = \"cancelPublishImage\",\n            name = \"Cancel publishing\",\n            description = \"Cancel all user\u2019s images publishing\",\n            triggerType = \"PRE_USER_API_CALL\",\n            triggerOptions = {\"publishResource\", \"publishImage\"},\n            api = \"TRIGGER\",\n            version = 1,\n        }\n    end\n\n    -- Turn publishing off\n    return {exitState = \"CANCEL\"}\n   \nend\n<\/code><\/pre>\n
    Die Funktion register wird vom FCO-Kern aufgerufen. Sie gibt den Namen der Funktion zur\u00fcck, die aufgerufen werden muss. Der Parameter \"p\" dieser Funktion speichert den Kontext des Aufrufs, und bei der ersten Ausf\u00fchrung wird er leer (nil) sein. Dies erm\u00f6glicht es uns, unseren Trigger zu registrieren. In triggerType zeigen wir an, dass der Trigger VOR der Ver\u00f6ffentlichung der Operation aufgerufen wird und nur f\u00fcr Benutzer gilt. Systemadministratoren erlauben wir selbstverst\u00e4ndlich, alles zu ver\u00f6ffentlichen. In triggerOptions detaillieren wir die Operationen, f\u00fcr die der Trigger aktiv wird.<\/p>\n
    Und das Wichtigste \u2013 return {exitState = \"CANCEL\"}, wof\u00fcr der Trigger entwickelt wurde. Er wird einen Misserfolg zur\u00fcckgeben, wenn der Benutzer versucht, sein Image im Dashboard zu teilen.<\/p>\n
    In der Architektur von FCO wird jedes Objekt (Disk, Server, Image, Netzwerk, Netzwerkadapter usw.) als Entit\u00e4t Resource dargestellt, die \u00fcber gemeinsame Parameter verf\u00fcgt:<\/p>\n