I want to test Linux (RHEL 6) clustering on vSphere 5. i am confused regarding for fencing, how can i select for fencing device.
so RHEL fencing is not supported by VMware, as per the article,
RHEL 5.7+, RHEL 6.2+. VMware vSphere ESX 4.1. Version 5.0 is known to not currently work due to an issue with the VMware SOAP API.
for prompt reply
EDIT: The below post is a little outdated. If you are using this method of clustering on 6.x, you can still follow the instructions below, but make sure you update the fence-agents package to the newest version or you will get weirdness with the fencing, especially in a large environment.
Here's what I did to set up and test fencing with RHEL 6.2 and VMWare vSphere 5.0 and. ESXi 5.0 U1 (also in ESX 5.5)
I will list the commands that can be used pretty much verbatim, to keep the commands looking exactly as they should I have replaced the following names:
VC server: testserver1.contoso.com
VC Fencing Account: testacct (Local account on VC server, you could use a domain account I'm assuming, but I didn't)
VC Fencing Account's Password: P@sswurd
1st node of 2 node RHEL cluster: node1.contoso.com (Named node1 in VC)
2nd node of 2 node RHEL cluster: node2.contoso.com (Named node2 in VC)
Key Tip: From what I have experienced, fencing will NOT work using the system name, you MUST use UUIDs. I spent considerable time trying to get names to work in various formats, but something seems to get lost in the translation between the fencing daemon and VMWare's SOAP interface.
After confguring your cluster and getting everything set up, you will need to configure an account on your VC for fencing. I would not use a production VC for this initial testing because if you copy over the incorrect UID, you may kill a production VM. On my test environment, my fencing account is local and named testacct.
Step 1 - Get the UUID of your two nodes
On node1.contoso.com, run the following:
fence_vmware_soap --ip testserver1.contoso.com --username testacct --password P@ssword -z --action list |grep node1
This will give you:
You will only want the UUID #, but copy the whole line off. It's very important that you do not get the wrong UUID or swap them by accident, so keep the label when you copy.
Do the same for node 2.
At this point you can actually test the fencing by running the following command on node 2 to fence node 1:
If you watch Recent Tasks in VC, you'll see testacct log in and shut down your system. If this is working (test both nodes from the opposite node), then you're ready to configure fencing in luci, if not, then check your UUID, check the service account's rights, check that names are resolvable, etc. etc. etc.
Adding Fencing in LUCI:
You will need to
1) Add a fence device that tells your cluster how to log into your VC
2) Attach a fencing method to each node and give it the UUID you used earlier to
1) Log into LUCI and select your cluster and then select the Fence Devices tab. Select Add.
Fill out the form exactly as shown:
Fence type: VMWare (SOAP Interface)
Name: fence_testserver1 (Just needs to be descriptive)
IP Address or Hostname: testserver1.contoso.com
IP Port (optional): blank
Leave the rest as they are or blank
2) Go back to Manage Clusters in LUCI and select your first node by clicking on the name. At the bottom of the screen for your node, select Add Fence Method. Give it a name, the name doesn't matter unless you are planning on using multiple methods. Submit your change. Now select Add Fence Instance that appears inside the method box and fill it out exactly as described below:
Select the fencing device you configured in step 1
VM Name: Leave blank
VM UUID: 42556584-e4fe-b2e0-4781-515afba87cf3 (The UUID copied from earlier)
Use SSL: Check it on. Fencing will not work without this checked.
Do step 2) for your second node as well. You should also check the bottom of this dialog for each node while your here and verify that all your required daemons are running before testing fencing.
You should be set. You'll have to try getting fencing to work by disconnecting your network adapter, or by adding a shared quorum disk then pulling it from a node. There are probably better ways, but I don't know how at this point.