I originally posted this in the NetBackup forum but it seems to be a VCS issue that is the root of the problem: https://www-secure.symantec.com/connect/forums/install-clustered-master-server-greyed-out
I am trying to set up a test NBU 184.108.40.206 master server cluster with VCS on Windows Server 2008 R2 but the option to "install a clustered master server" is greyed out.
I have built 2 new servers, installed SFHA / VCS 6.0.1 and configured disks / volumes / disk groups / VVR replication. The VCS installation has not been modified or customised in any way as from my understanding the NBU installation will create its own service group. I have carried out the initial configuration and added the remote cluster node. Within cluster explorer, the default ClusterService service group is all up and running, the global cluster option is enabled and the remote cluster status also shows that the other cluster is up.
Marianne has already asked me to run two commands with the following output:
'gabconfig -a' - "GAB gabconfig ERROR V-15-2-25022"
lltconfig -nvv - "LLT lltconfig ERROR V-14-2-15000 open \\.\llt failed: error number: 0x2"
I've probably just made a silly mistake somewhere but I can't figure out what piece of the puzzle I have missed - any ideas?
Solved! Go to Solution.
In single node cluster, Install A Clustered Master Server" Greyed Out, if the LLT (heart beat) has not configured. please configured LLT and try to install NBU, the Install A Clustered Master Server should visible.
NBU_13 - are you saying you KNOW NBU wizard checks for LLT, or is this something you are just suggesting Shaun tries as earlier, Marianne said:
NBU is fine with 1-node cluster. The only requirement is that had must be up and running.
So, if 1-node cluster, then hastart -onenode should do the trick.
Single node clusters normally do not use LLT and "hastart -onenode" means do not use LLT, as there is no need for LLT when there is only one node and LLT is only generally configued in one-node clusters when it is likely that a 2nd node will be added at some point in the future.
We tested in house after my collegaue remembered how we resolved it previously. We faced the issue at a client last year. At least his memory is still in working order.
Without LLT configured it will remain greyd out.
Its the NBU team being toooooo clever with their wizard :p
"clever" isn't the word I would use Riaan :) - but anyway, Shaun.
If you only have 1 network, then I don't think the VCS wizard will let you configure, but you can get round this by configuring LLT manually, so let me know if you only have one NIC,and I'll post how to configure LLT manually.
Brilliant, thanks for your help everyone. Unfortunately other things have got in the way today so I haven't had a chance to swap the virtual disks for LUNs but I will do my very best to get this done within the next couple of days around other work.
Mike - I would like to proceed with 1 NIC for this test build as that is how it has been configured in live, so if you have steps for configuring LLT manually for a single node / 1 NIC cluster that would be really helpful!
To configure LLT manually:
1. Enable llt and gab. These services are hidden and usually disabled by default so you need to enable them by editing the following registry entries by changing the "Start" key from 4 (disabled) to 2:
2. Create an llthosts.txt and llttab.txt file in \Program Files\VERITAS\comms\llt as follows:
set-node host_name_of_server set-cluster 11 link Adapter0 MAC-ADDR_with_colon_seperator - ether - - start
The cluster id set by "set-cluster" should be unique so you should check if you have any other clusters on the same network and I guess you know you can get MAC address from "ipconfig /all"
3. Create an gabtab.txt file in \Program Files\VERITAS\comms\gab as follows:
gabconfig -c -n 1
Start llt, gab and VCSComm:
net start llt net start gab net start VCSComm
Check gab is running
Then start VCS:
Hopefully NBU wizard only checks llt and gab are running and not number of heartbeats, but if it is still greyed out you can create 2 heartbeats with the same interface so add line to llttab.txt like:
link Adapter1 SAME-MAC-ADDR_with_colon_seperator - ether - -
And then restart all services.
To undo above, just do reverse, but you can leave LLT and GAB running if you want.
I have replaced the virtual disks with RDMs and tested deporting / importing with no problems. Synchronisation is also now back up and running.
Thanks for the great step-by-step instructions Mark, I'll give that a go this morning!
I have configured llt and gab manually on the first node and I am very pleased to say that - as many of you predicted - the option to install a clustered Master server is now available! I actually checked our live environment and although they are also single node clusters it turns out that the configuration for llt / gab is still in place so this was obviously carried out and not documented when it was first set up.
Thanks again for the great instructions Mark. Just a couple of points that I found when configuring it on the first node that I thought you might be interested to know:
I'll provide a further update once I have finished both nodes and attempted the installation just to ensure that everything is working.
When you say you did not need to add the 3rd line in llttab.txt- do you mean llt service starts without the line:
link Adapter0 MAC-ADDR_with_colon_seperator - ether - -
and if so, this maybe why VCSComm service does not start as this requires gab and llt service to be running and MAY require LLT to be running correctly.
Can you provide output of "lltstat -nvv" and "gabconfig -a" to check llt and gab are running correctly, although as long as NBU wizard successfully runs, I guess it doesn't matter if LLT is not working correctly as LLT is not required in a one-node cluster.
Ok, that makes sense. Yes, our live servers are configured without that line so I have left it out on our test servers as well.
Here's the output:
lltstat -nvv LLT node information: Node State Link Status Address 0 OASTES-BAK002 IDLE 1 IDLE 2 IDLE 3 IDLE 4 IDLE 5 IDLE 6 IDLE 7 IDLE 8 IDLE 9 IDLE 10 IDLE 11 IDLE 12 IDLE 13 IDLE 14 IDLE 15 IDLE 16 IDLE 17 IDLE 18 IDLE 19 IDLE 20 IDLE 21 IDLE 22 IDLE 23 IDLE 24 IDLE 25 IDLE 26 IDLE 27 IDLE 28 IDLE 29 IDLE 30 IDLE 31 IDLE gabconfig -a GAB Port Memberships ===============================================================
So the above shows gab has no membership, so then did you start VCS with "hastart -onenode", rather than just "hastart" with no flags (or did you start using "net start had" or in "Sevices" GUI)
If NBU wizard doesn't work then I would set up LLT correctly with the link line for your one NIC and then "lltstat -nvv" should show the NIC, "gabconfig -a" should show port "a" membership and you should be able to start VCS with "hastart" with no flags (after which point "gabconfig -a" will also show port "h" membership).
I have successfully installed NBU on both nodes. Thanks for the help everyone.
The only outstanding issue I now have is with the replication. If this needs to be a new post in a different section let me know!
I have run the Volume Replicator Agent Configuration wizard successfully and my initial testing of failing between nodes went perfectly. However, at some point during the testing both nodes have ended up thinking that they are the primary in the GUI and I cannot see the secondaries listed, although everything looks correct in VCS and I can still bring everything online on each side with no errors. Something clearly isn't right with it though.
I have tried deleting the RDS in the GUI and using commands to create it again, but it seems to be somewhat stuck and I can't seem to remove it or change anything now! Here's the output on what should be the primary node:
C:\>vradmin -g NBUCATDG takeover nbuRVG Error occurred on host HOST1. Error V-106-58644-541: Primary takeover is not supported in present configuratio n. C:\>vradmin -g NBUCATDG stoprep nbuRVG HOST2 Error occurred on host HOST2. Error V-106-58644-528: Cannot complete operation. RDS is incomplete, either prim ary or secondary node is missing. C:\>vradmin -g NBUCATDG delsec nbuRVG HOST2 Error occurred on host HOST1. Error V-106-58644-513: This operation cannot be performed in present state of th e configuration. Please try again. C:\>vradmin -g NBUCATDG -f delpri nbuRVG Failed to perform the operation. Error V-106-58644-698: Operation not allowed. The RVG cluster resource is alread y configured for this RVG. Use -f option to forcefully stop it. C:\>vradmin -g NBUCATDG -f delrds nbuRDS Failed to perform the operation. Error V-107-58644-917: Cannot identify the correct RDS. C:\>vradmin -l printrvg Replicated Data Set : nbuRDS Primary : Hostname : HOST1 <localhost> RvgName : nbuRVG DgName : NBUCATDG Datavol_cnt : 1 Srl : vvrlog Rlinks: Name = rlk_primary ,rlink_state = ACTIVE, synchronous = override
After switching back to what should be the secondary node (HOST2) I found that most of the above commands give a different error: "Error V-106-58644-697: Cannot perform this operation on an acting secondary RVG". However in the VEA GUI it is listed as the primary.
I have successfully installed NBU on both nodes and tested failing over between nodes. Clearly the configuration of llt / gab must have been part of the original build in our live environment but was missed from the handover and documentation - I'll be adding the missing piece of the puzzle to our documentation!
Thanks again to everyone that has helped with this - it has been a perfect example of how valuable the Connect community is!