Floating IP & OpenStack Raksha For Disaster Recovery (HP Cloud)

Floating IP & OpenStack Raksha Can Be Used For Disaster Recovery and Obtaining Zero Downtime During Maintenance. Example is With HP Cloud as Client. OpenStack’s various features clearly pushes the clients, that is we as example to not use the less costly competitors like DigitalOcean. Floating IP & OpenStack Raksha can be ideally found in HP Cloud’s Installation. This style of usage is not possible at Rackspace.

Basics of Floating IP & OpenStack Raksha

We can add or release IP address at HP Cloud against the instances. Usually, we use one IP address against a domain (that means one instance) and add that IP address in (HP Cloud) DNS with highest possible TTL to encourage caching by AkamaiGhost servers. So, if we change the IP against the domains entry as A Name in DNS, we have to decrease the TTL from 50 years or so to a very low value. This is not desired. To add flexibility, we have a separate subnet and that public floating IP address. We will not change the IP address at (HP Cloud) DNS for an example situation where there can be downtime as described below.

OpenStack Raksha is that Snapshot feature. The image is pushed towards Akamai’s Edge Server. On demand, we can spin an instance from it.

Floating IP & OpenStack Raksha For Disaster Recovery (HP Cloud)

Take an example situation with one server configuration (MySQL or any database server is running on the same instance). As usually we never use the internal IP / subnet to connect within one instance, it is very easy example usage of floating IP & OpenStack Raksha to avoid downtime.

As a first step, we are taking a snapshot of the instance. In second step, we are spinning a new instance with identical virtual device specs – same virtual RAM is the best guide. This new instance will have new set of subnet but no public IP.

After the image build is complete, we will dissociate the floating IP from the working old instance and associate with this new instance. We will check the front end manually on browser without any saved cookies to have a perfect working clone of our main instance. We can also do a cURL to check the header response.

We will add a new floating IP to the old instance and do SSH. Now, if we do any work like shutting down the web server software or simply running update and upgrade, the chance of failure on the fronted will be zero.

After updating / completing our work, we will work follow the above steps in reverse direction. We will delete the instance and release the IP used for the rescue purpose.

If database server is different

In case if the work is with different database server and web server, then for MySQL, we need to adjust accordingly :

On the web server, we need to change the subnet, for example; in case of WordPress, in wp-config.php file. Yes, it is a bit disturbing too much work to avoid Error Connecting Database Server. my.cnf should be widely open as we have router in front. Security group of the Database server should not accept port 80 or port 443. These are about security.