{"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\/en\/blog\/news\/flexiant-cloud-orchestrator-s-chem-ego-edyat","title":{"rendered":"Flexiant Cloud Orchestrator: what is it used for","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Flexiant
\n
\nTo provide IaaS (Virtual Data Center) services, we use Rusonyx<\/a><\/noindex> the commercial orchestrator Flexiant Cloud Orchestrator<\/a><\/noindex> (FCO). This solution has a sufficiently unique architecture that distinguishes it from the well-known Openstack and CloudStack.<\/a><\/noindex> <\/p>\n

As for hypervisors, the compute nodes support KVM, VmWare, Xen, Virtuozzo 6\/7, as well as containers from the same Virtuozzo. Supported storage includes local, NFS, Ceph, and Virtuozzo Storage.<\/p>\n

FCO supports the creation of multiple clusters and managing them from a single interface. In other words, one can manage a Virtuozzo cluster and a KVM + Ceph cluster by switching between them with a click.<\/p>\n

Essentially, FCO is a comprehensive solution for cloud providers that, apart from orchestration, also includes billing, with all setups, payment plugins, invoices, notifications, resellers, rates, and so on. However, the billing component cannot cover all the nuances of the Russian market, which is why we abandoned its use in favor of another solution.<\/p>\n

The flexible system for distributing rights over all cloud resources is very pleasing: images, disks, products, servers, firewalls \u2013 all of these can be 'shared' and rights can be granted among users, even between users of different clients. Each client can create several independent data centers in their cloud and manage them from a single control panel.<\/p>\n

\"Flexiant
\n
\nArchitecturally, FCO consists of several parts, each with its independent code, and some even have their own database.<\/p>\n

Skyline<\/b> \u2013 admin and user interface
\nJade<\/b> \u2013 business logic, billing, task management
\nTigerlily<\/b> \u2013 service coordinator that manages and coordinates the exchange of information between business logic and clusters.
\nXVPManager<\/b> \u2013 management of cluster elements: nodes, storage, network, and virtual machines.
\nXVPAgent <\/b>\u2013 an agent installed on nodes for interaction with XVPManager<\/p>\n

\"Flexiant
\n
\nWe plan to include a detailed discussion of the architecture of each component in a series of articles, if, of course, the topic creates interest.<\/p>\n

The main advantage of FCO stems from its \"box-like\" nature. You have the benefit of simplicity and minimalism. A single virtual machine running Ubuntu is allocated for the management node, where all necessary packages are installed. All settings are moved to configuration files in the form of variable-value pairs:<\/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
All configuration is initially modified in templates, and then the generator is launched.
\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
\nAs you can see, the interface consists of widgets, which the user can manage easily. They can effortlessly add\/remove widgets from the page, thereby creating their desired dashboard.<\/p>\n
Despite its closed nature, FCO is a highly customizable system. It offers a vast number of settings and entry points for modifying the workflow:<\/p>\n
    \n
  1. Custom plugins are supported; for example, you can write your own billing method or an external resource for user provision.<\/li>\n
  2. Custom triggers for specific events are supported, such as adding the first virtual machine for a client upon their creation.<\/li>\n
  3. Custom widgets in the interface are supported, such as embedding YouTube videos directly into the user interface.<\/li>\n<\/ol>\n
    \nAll customization is written in FDL, a language based on Lua. If you know Lua, you will have no issues with FDL.<\/p>\n
    Here\u2019s an example of one of the simplest triggers we use. This trigger prevents users from sharing their own images with other clients. We do this to ensure that one user cannot create a harmful image for others.<\/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
    The register function will be called by the FCO core. It will return the name of the function that needs to be invoked. The parameter \u201cp\u201d of this function holds the context of the call, which will be empty (nil) on the first invocation. This allows us to register our trigger. In triggerType, we indicate that the trigger is called BEFORE the publishing operation and applies only to users. Naturally, we allow system administrators to publish everything. In triggerOptions, we detail the operations for which the trigger will activate.<\/p>\n
    And most importantly \u2013 return {exitState = \u201cCANCEL\u201d}, which is exactly what the trigger was designed for. It will return failure when a user tries to share their image in the control panel.<\/p>\n
    In FCO architecture, any object (disk, server, image, network, network adapter, etc.) is represented as a Resource entity, which has common parameters:<\/p>\n