RHCS – Cluster from Scratch | Part 02

Okay after long time back, anyway I’m here and let’s get started with clustering 😀 We are going to implement two (2) node Active/Passive cluster for provide continues web service to the end users. I’n my scenario I’m  using two virtual servers as a cluster nodes and network attach storage (NAS) as a shared storage for both servers. also there are three (3) virtual networks for public network, private network(cluster heartbeat network) and for the storage network. here all of this virtual servers, network and storage are deployed on a CentOS 6 environment using KVM based hypervisor. anyway all virtual resources work as a actual physical resources.


above figure show the initial architecture for our high availability web service deployment, In each virtual server has three (3) network interface cards (NIC) for connect to the public, private and storage networks. In addition to the servers, network attached storage has two(2) ip address. we use both this address to configure multi-path for provide efficient and reliable storage infrastructure to our cluster deployment. here the configuration details of servers and storage.

Server 01
2.6 GHZ 2 vCPU’s with 1 GB RAM
Hostname : web1.hasitha.org
NIC 01 : (Public Network)
NIC 02 : (Private Network)
NIC 03 : (Storage Network)

Server 02
2.6 GHZ 2 vCPU’s with 1 GB RAM
Hostname : web2.hasitha.org
NIC 01 : (Public Network)
NIC 02 : (Private Network)
NIC 03 : (Storage Network)

Network Attach Storage (NAS)
NIC 01 : (Storage Network)
NIC 02 : (Storage Network)
LUN 01 : 10GB (iqn.2013-08-10.storage.hasitha.org:web)

Now we are ready to go and next part is all about configuring servers, wait till the next then, see ya soon.

RHCS – Cluster from scratch | Part 01

In my previous post, I’ve just touch Red Hat High Availability Add-on for Red Hat Enterprise Linux and it’s eliminate single point of failures, so in case if the active cluster member on which a high availability service group is running become inoperative, the high availability service will start up again(fail over) in another cluster node without interruption.

Okay let’s get started with high availability clustering! but first of all, let’s understand some basic concepts. if you need clear and fully understand about all of these things, I highly recommend to read Red Hat Enterprise Linux 6 Cluster Administration Guide. It’s the best resources for RHEL6 HA clustering. and also you can use CentOS or Oracle Linux as alternatives to follow this article series without Using Red Hat Enterprise Linux.

Cluster Node
Cluster node is a server that is configured to be a cluster member. Normally shared storage (SAN,NAS) is available to all cluster members.

Cluster Resources
Cluster resources is the things you going to keep high available and all of these resources need to available for all cluster nodes. all or some of these resources can be associated with an application you plan to keep highly available.

Cluster Service Group
A collection of related cluster resources that defines actions to be taken during a fail-over operation of the access point of resilient resources. These resilient resources include applications, data, and devices.

Fencing is the method that cuts off access to a cluster resource (shared storage, etc.) from a node in your cluster if it loses contact with the rest of the nodes in the cluster.

There are some more things related to clustering including this basic components and we can learn most of them when we deploying our high availability web service. So wait till the next post 😉

RHCS – Cluster from scratch

According to the Red Hat, Red Hat Cluster Suite (RHCS) High Availability Add-On provides on-demand failover to make applications highly available. It delivers continuous availability of services by eliminating single points of failure. And clustering is a group of computers (called node or members) to work together as a team to provide continued service when system components fail.

Assume that we are running a critical database service on a standalone server, if a software or hardware component failed on that database server, administrative intervention is required and database service will be unavailable until the crashed server is fixed, but with clustering that database service get automatically restarted on another available node in the cluster without administrator invention and database service will be continuously available to the end-users. cluster can deploy as a active/active (one active node and one standby node) or active/passive (both nodes are active) to suite our clustering needs.

In this series of “RHCS – Cluster from scratch” articles, I’m planning to deeply explain how to deploy high availability web service as a active/passive cluster using Red Hat High Availability Add-On on a Red Hat Enterprise Linux 6.