Search Engine: Elastic

Article ID: 131593, created on Oct 10, 2017, last review on Oct 11, 2017

  • Applies to:
  • Operations Automation

The instruction below is aimed to clarify in details the process of transitioning of OA UI cluster based on CloudLinux web nodes to the UI cluster based on pure CentOS7 web nodes.

Problem statement

The original OA UI cluster is based on CloudLinux web nodes as a part of WebHosting Linux (formerly NG Shared Hosting) infrastructure. However, reseller's brands - virtual servers that host brands settings (static pages, CSS files, and so on) - are deployed as regular Apache Virtual Hosts.

They do not need the powerful WebHosting Linux infrastructure as they contain only static HTML and CSS files. There are no scripts running in context of a reseller's brand and there are no any other activities that need to be artificially limited as it is done for WebHosting Linux web spaces where an owner of a web space can run computationally heavy scripts in its context.

Another aspect is that since branding Virtual Hosts are being configuring traditionally (that is, by means of httpd.conf), there is no necessity to resolve a domain name of a brand web space dynamically as it is done in WebHosting Linux when web spaces are created and deleted on a regular basis, and they need to be highly available just after their creation and without the Apache service restarting.

All that aspects have lead us to the conclusion that UI cluster can be served by regular CentOS/RHEL web nodes without WebHosting Linux components like Redis, SuExec, Fast CGI and so on.

Thus, starting from OA 7.2 we implemented the UI cluster solution where web nodes are just regular CentOS7/RHEL7 machines without Redis and other superfluous WebHosting Linux components.

Unfortunately, that UI cluster can be deployed only from scratch - there is no possibility to transform the UI cluster based on WebHosting Linux to the UI cluster based on CentOS7\RHEL7 during the regular OA upgrade procedure. This is mostly related to the high complexity of changing the type of the operating system - no reasonable ability to substitute CloudLinux with CentOS guarantying high safety and consistency.

Solution

Regardless the fact that there is no upgrade procedure that would migrate from WebHosting Linux UI cluster automatically, we provide the solution that allow a provider to do it manually. We have implemented the Python script that safely removes the superfluous WebHosting Linux components from web nodes of the WebHosting Linux UI cluster. However, this does not change the type of web nodes operation system - they continue running on CloudLinux OS.

At the end of its work, the script marks a given cluster as UI cluster. Starting from that moment a provider can add new Centos7/RHEL7 web nodes to that cluster. Note that the UI cluster allows the provider to add only Centos7/RHEL7 machines as web nodes - there will be no ability to add CloudLinux nodes to that cluster anymore. Only removing of CloudLinux web nodes is permitted for such cluster.

As a result, a provider receive the ability to consistently substitute CloudLinux web nodes in the UI cluster with web nodes running on Centos7/RHEL7. We recommend do it consistently one by one:

  1. Prepare one new UI server with pure installed CentOS7/RHEL7 operating system Please do not forget to install the epel-release repo as it is required by the UI cluster deployment guide. More information about EPEL are available at the bottom of the “Deploying Odin Automation UI with Branding on Linux > Deploying UI on Linux Cluster > Hardware and Software Requirements > UI Server” section.

  2. Add new UI node to the UI cluster and wait until the end of deployment (check that corresponding tasks are finished).

  3. In the corresponding administration panel, mark the new UI node as UI cluster director. This will release director duties from the original Cloud Linux machine.

  4. Choose a CloudLinux UI server as a victim and remove it from the cluster. Wait until the undeployment is fulfilled (check that corresponding tasks are finished).

  5. Prepare one more new UI server with pure installed CentOS7 operating system. Alternatively, you can use the old machine that was released from the cluster on the step #4. In this case, you should just reinstall an operation system there.

  6. Repeat the steps #2, #4, and #5 until all CloudLinux nodes are dislodged from the UI cluster. Once the last CloudLinux web node is dislodged from the cluster, a provider starts to manage a full value UI cluster as if it was installed from scratch. Note that such a way does not change IP addresses of brands’ domains. They stay immutable and therefore a reseller will not note the web nodes substitution – a brand web site will continue running on its original IP address.

How to run the script

Note: The script operates as an arbiter - it must be executed on OA management node!

The provided archive contains two files:

  1. MutateUICluster.py - the Python script to run
  2. no-redis-httpd.conf - new Apache config that must be placed onto a CloudLinux web node

They both needs to be extracted to the same directory.

Below is the usage of the script:

Usage: MutateUICluster.py [options] 

Options:
  -h, --help     show this help message and exit
  -v, --verbose  if specified, will cause detailed trace output to log
  -F, --fix      erases superfluous components from Web nodes of given NG UI cluster and reconfigures Apache service accordingly

Firstly, we recommend to run the script to check only, that is without the -F (--fix) option. It will check cluster nodes availability and some other conditions. For example:

python ./MutateUICluster.py 5

where `5` is the id of UI cluster.

In order to erase superfluous components from web nodes run the script with -F (--fix). For example:

python ./MutateUICluster.py -F 5 -v

where the -v (--verbose) option prints more abundant trace output.

5356b422f65bdad1c3e9edca5d74a1ae caea8340e2d186a540518d08602aa065 e12cea1d47a3125d335d68e6d4e15e07

Email subscription for changes to this article
Save as PDF