{"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\/novosti-interneta\/flexiant-cloud-orchestrator-s-chem-ego-edyat","title":{"rendered":"Flexiant Cloud Orchestrator: Was Sie dar\u00fcber wissen sollten","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Flexiant
\n
\nUm den IaaS-Dienst (Virtuelles Rechenzentrum) anzubieten, nutzen wir Rusonyx<\/a><\/noindex> einen kommerziellen Orchestrator Flexiant Cloud Orchestrator<\/a><\/noindex> (FCO). Dieses L\u00f6sung verf\u00fcgt \u00fcber eine einzigartige Architektur, die sie von den weithin 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. Unterst\u00fctzte Speichersysteme umfassen lokales Storage, NFS, Ceph und Virtuozzo Storage.<\/p>\n

FCO erm\u00f6glicht die Erstellung mehrerer Cluster und deren Verwaltung \u00fcber eine einzige Oberfl\u00e4che. Das bedeutet, dass Sie zwischen einem Virtuozzo-Cluster und einem KVM + Ceph-Cluster mit einem Mausklick wechseln k\u00f6nnen.<\/p>\n

Im Wesentlichen ist FCO eine umfassende L\u00f6sung f\u00fcr Cloud-Anbieter, die neben der Orchestrierung auch Abrechnung miteinander verbindet, einschlie\u00dflich 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\u00f6sung nicht zu verwenden.<\/p>\n

Das flexible System zur Verteilung von Rechten auf alle Cloud-Ressourcen wie Images, Festplatten, Produkte, Server und Firewalls ist sehr erfreulich \u2013 alles kann zwischen Benutzern und sogar zwischen Benutzern verschiedener Kunden \u201egeteilt\u201c und Rechte vergeben werden. Jeder Kunde kann in seiner Cloud mehrere unabh\u00e4ngige Rechenzentren erstellen und diese aus einem einheitlichen Dashboard verwalten.<\/p>\n

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

Skyline<\/b> \u2013 Admin- und Benutzeroberfl\u00e4che
\nJade<\/b> \u2013 Gesch\u00e4ftslogik, Abrechnung, Taskmanagement
\nTigerlily<\/b> \u2013 Servicekoordinator, der den Austausch von Informationen zwischen Gesch\u00e4ftslogik und Clustern verwaltet und koordiniert.
\nXVPManager<\/b> \u2013 Verwaltung der Clusterkomponenten: Knoten, Speicher, Netzwerk 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 Components planen wir in einer Serie von Artikeln zu ver\u00f6ffentlichen, sofern das Thema auf Interesse st\u00f6\u00dft.<\/p>\n

Der Hauptvorteil von FCO liegt in seiner \"Kastenform\". Ihnen steht Einfachheit und Minimalismus zur Verf\u00fcgung. F\u00fcr 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\u00fcssel-Wert-Paaren ausgef\u00fchrt:<\/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 Vorlagen bearbeitet und anschlie\u00dfend 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 Steuerung dem Benutzer zur Verf\u00fcgung steht. Er kann Widgets einfach von der Seite hinzuf\u00fcgen oder entfernen und so sein gew\u00fcnschtes Dashboard gestalten.<\/p>\n
Trotz ihrer Geschlossenheit ist FCO ein \u00e4u\u00dferst anpassbares System. Es gibt eine enorme Anzahl von Einstellungen und Zugangspunkten zur Ver\u00e4nderung des Workflows:<\/p>\n
    \n
  1. Es werden benutzerdefinierte Plugins unterst\u00fctzt, beispielsweise k\u00f6nnen Sie Ihre eigene Abrechnungsmethode oder eine externe Ressource zur Bereitstellung an den Benutzer schreiben.<\/li>\n
  2. Benutzerdefinierte Trigger f\u00fcr bestimmte Ereignisse werden unterst\u00fctzt, zum Beispiel das Hinzuf\u00fcgen der ersten virtuellen Maschine f\u00fcr einen Kunden bei dessen Erstellung.<\/li>\n
  3. Benutzerdefinierte Widgets in der Benutzeroberfl\u00e4che werden unterst\u00fctzt, beispielsweise um ein Video von YouTube direkt in die Benutzeroberfl\u00e4che einzubetten.<\/li>\n<\/ol>\n
    \nAlle Anpassungen werden in der FDL-Sprache geschrieben, die auf Lua basiert. Wenn Sie Lua kennen, werden Sie mit FDL keine Probleme haben.<\/p>\n
    Hier ist ein Beispiel f\u00fcr 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\u00e4dliches Abbild f\u00fcr andere Benutzer erstellt.<\/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 soll. Der Parameter \u201ep\u201c dieser Funktion speichert den Kontext des Aufrufs und ist beim ersten Aufruf leer (nil). Dies erm\u00f6glicht uns, unseren Trigger zu registrieren. Im triggerType geben wir an, dass der Trigger VOR der Ver\u00f6ffentlichung ausgef\u00fchrt wird und nur f\u00fcr Benutzer gilt. Administratoren des Systems erlauben wir selbstverst\u00e4ndlich, alles zu ver\u00f6ffentlichen. In triggerOptions spezifizieren wir die Operationen, f\u00fcr die der Trigger aktiviert wird.<\/p>\n
    Und das Wichtigste \u2013 return {exitState = \"CANCEL\"}, wof\u00fcr der Trigger entwickelt wurde. Er gibt einen Misserfolg zur\u00fcck, wenn der Benutzer versucht, sein Abbild im Control Panel zu teilen.<\/p>\n
    In der FCO-Architektur wird jedes Objekt (Festplatte, Server, Image, Netzwerk, Netzwerkadapter usw.) als Ressourceneinheit dargestellt, die gemeinsame Parameter hat:<\/p>\n