{"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\/da\/blog\/news\/flexiant-cloud-orchestrator-s-chem-ego-edyat","title":{"rendered":"Flexiant Cloud Orchestrator: hvad er det?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Flexiant
\n
\nFor at levere IaaS-tjenesten (Virtuelt datacenter) bruger vi Rusonyx<\/a><\/noindex> en kommerciel orkestrator Flexiant Cloud Orchestrator<\/a><\/noindex> (FCO). Denne l\u00f8sning har en temmelig unik arkitektur, hvilket adskiller den fra de bredt kendte Openstack og CloudStack.<\/a><\/noindex> <\/p>\n

Som hypervisorer underst\u00f8ttes KVM, VmWare, Xen, Virtuozzo6\/7, samt containere fra samme Virtuozzo. De underst\u00f8ttede lagringssystemer inkluderer \u2013 lokal, NFS, Ceph og Virtuozzo Storage.<\/p>\n

FCO underst\u00f8tter oprettelse af flere klynger og styring af dem fra en enkelt interface. Det vil sige, at man kan administrere en Virtuozzo-klynge og en KVM + Ceph-klynge ved at skifte mellem dem med et musetryk.<\/p>\n

I sin essens er FCO en omfattende l\u00f8sning til cloud-udbydere, der udover orkestrering ogs\u00e5 inkluderer fakturering med alle indstillinger, betalingsplugins, fakturaer, meddelelser, forhandlere, takster osv. Dog kan faktureringsdelen ikke d\u00e6kke alle de russiske nuancer, hvorfor vi har fravalgt at bruge den til fordel for en anden l\u00f8sning.<\/p>\n

Det gl\u00e6der os, at der er et fleksibelt system til fordeling af rettigheder til alle ressourcer i cloud'en: billeder, diske, produkter, servere, firewalls \u2013 alt dette kan \"dele\" og give rettigheder mellem brugere, og endda mellem brugere fra forskellige kunder. Hver kunde kan oprette flere uafh\u00e6ngige datacentre i deres cloud og administrere dem fra et enkelt kontrolpanel.<\/p>\n

\"Flexiant
\n
\nArkitektonisk best\u00e5r FCO af flere dele, hver med sin egen uafh\u00e6ngige kode og nogle ogs\u00e5 med deres egen database.<\/p>\n

Skyline<\/b> \u2013 administrativt og brugerinterface
\nJade<\/b> \u2013 forretningslogik, fakturering, opgaveh\u00e5ndtering
\nTigerlily<\/b> \u2013 servicekoordinator, der styrer og koordinerer informationsudvekslingen mellem forretningslogikken og klyngerne.
\nXVPManager<\/b> \u2013 styring af klyngeelementer: noder, lagring, netv\u00e6rk og virtuelle maskiner.
\nXVPAgent <\/b>\u2013 agent, der installeres p\u00e5 noder for at interagere med XVPManager<\/p>\n

\"Flexiant
\n
\nVi planl\u00e6gger at placere en detaljeret fort\u00e6lling om arkitekturen af hver komponent i en serie artikler, hvis emnet selvf\u00f8lgelig v\u00e6kker interesse.<\/p>\n

Hovedfordelen ved FCO kommer fra dets \"boksl\u00f8sning\". Du f\u00e5r enkelhed og minimalisme. Der tildeles en virtuel maskine med Ubuntu til kontrolnoden, hvor alle n\u00f8dvendige pakker installeres. Alle indstillinger gemmes i konfigurationsfiler som variabel-v\u00e6rdi:<\/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
Hele konfigurationen rettes oprindeligt i skabelonerne, hvorefter generatoren aktiveres.
\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
\nSom det ses, best\u00e5r gr\u00e6nsefladen af widgets, som brugeren har adgang til at styre. Han kan nemt tilf\u00f8je\/fjerne widgets fra siden, og derved danne det dashboard, han \u00f8nsker.<\/p>\n
P\u00e5 trods af sin lukkethed er FCO en meget tilpasselig system. Den har et enormt antal indstillinger og adgangspunkter til at \u00e6ndre workflowet:<\/p>\n
    \n
  1. Tilpassede plugins underst\u00f8ttes, for eksempel kan du skrive din egen betalingsmetode eller et eget eksternt ressourcer til at give brugeren.<\/li>\n
  2. Tilpassede triggere underst\u00f8ttes ved bestemte h\u00e6ndelser, for eksempel tilf\u00f8jelse af den f\u00f8rste virtuelle maskine til kunden ved oprettelsen.<\/li>\n
  3. Tilpassede widgets underst\u00f8ttes i gr\u00e6nsefladen, for eksempel at integrere videoer fra YouTube direkte i brugerens interface.<\/li>\n<\/ol>\n
    \nAl tilpasning skrives i FDL-sproget, som er baseret p\u00e5 Lua. Hvis du kender Lua, vil der ikke v\u00e6re problemer med FDL.<\/p>\n
    Her er et eksempel p\u00e5 en af de simpleste triggere, som vi bruger. Denne trigger forhindrer brugere i at dele deres egne billeder med andre kunder. Vi g\u00f8r dette for at forhindre, at \u00e9n bruger kan skabe skadelig billeder til andre brugere.<\/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
    Funktionen register vil blive kaldt af FCO-kernen. Den vil returnere navnet p\u00e5 den funktion, der skal kaldes. Parameteren \u201cp\u201d i denne funktion indeholder konteksten for kaldet, og ved det f\u00f8rste kald vil den v\u00e6re tom (nil). Dette giver os mulighed for at registrere vores trigger. I triggerType angiver vi, at triggere aktiveres F\u00d8R offentligg\u00f8relsen og kun g\u00e6lder for brugerne. Systemadministratorer har selvf\u00f8lgelig tilladelse til at offentligg\u00f8re alt. I triggerOptions detaljerer vi de operationer, som triggeren skal reagere p\u00e5.<\/p>\n
    Og vigtigst af alt \u2013 return {exitState = \u201cCANCEL\u201d}, som triggeren er designet til. Den vil returnere fejl, n\u00e5r brugeren fors\u00f8ger at dele sit billede i kontrolpanelet.<\/p>\n
    I FCO-arkitektur er ethvert objekt (disk, server, billede, netv\u00e6rk, netv\u00e6rksadapter osv.) repr\u00e6senteret som en enhed kaldet Resource, som har f\u00e6lles parametre:<\/p>\n