Serviceguard
cancel
Showing results for 
Search instead for 
Did you mean: 

Isolate primary node network in MC Services Guard

 
SOLVED
Go to solution
Jason Chia
Occasional Contributor

Isolate primary node network in MC Services Guard

Hi,

Currently Server A & B are configured in a clustering environment whereby server A is the primary node with 3 network cards(1 is activate,1 is standby and 1 is the heartbeat).

Sometime I would need to isolate this server A from our existing network to a hub for third party to logon. However once I unplug the network cable for the activate NIC. the cluster will detected that NIC defeated and switch to the standby NIC.

How can I able to unplug the active NIC without allow it to switch to the standby NIC.
And will the package halt/switch to the adoptive node if it detected both NIC cables unpluged and pluged it to the hub while the adoptive node (Server B) is still in our existing network.

Would appreciate anyone can advises me on that. Thanks.

Regards,
Jason
4 REPLIES 4
melvyn burnard
Honored Contributor

Re: Isolate primary node network in MC Services Guard

Well to be honest, what you are trying ot do is not the smartest thing to do to a cluster.
And yes, if you idsconnect all hte cables to move it to hte hub, hte package will swicth, UNLESS you prevent it by doing cmmodpkg -d pkgname. Then you would have to restart it afterawards.
I do believe, however, that you should look for a smarter way to have your 3rd party gain access, say via modem, or via plugging them in ot the exisiting netwrk.
My house is the bank's, my money the wife's, But my opinions belong to me, not HP!
Bill Hassell
Honored Contributor

Re: Isolate primary node network in MC Services Guard

I would strongly agree with Melvin that this defeats not only the purpose of a clustered environment but may expose an unprotected system to an unsecure network. There are many solutions that will eliminate this NIC swap including SSH, VPN, or changing the systems to a more secure envionment.


Bill Hassell, sysadmin
Jason Chia
Occasional Contributor

Re: Isolate primary node network in MC Services Guard

Hi,

Thanks for your replies.

But due to our company policy, we got to isolate that server from our existing network to a hub for 3rd party vendor to access temporary (abt a few hours).

If I able to move both server A & B activate NICs to the hub, will that solved the problem. Which means that 3rd party vendor would be able to access to the hub and the cluster will still working.

Please advises. Thanks.
Highlighted
Stephen Doud
Honored Contributor
Solution

Re: Isolate primary node network in MC Services Guard

Hello Jason,

Melyvn and Bill have valid points that if ignored may cause you grief in the future. However, since you are constrained to operate in this manner, I'll give you some information that may help you.

ServiceGuard is "wired" to fail network traffic over to a "standby" NIC when available and indicated in the cluster binary file. To prevent ServiceGuard from rerouting traffic from a disconnected primary NIC to a standby NIC, disconnect the standby NIC first. (Watch the syslog.log to see that SG detects the stby NIC's outage before disconnecting the primary NIC.)

However, when both primary and standby LANs fail to transmit due to such manipulation, ServiceGuard determines that the SUBNET has failed and halts the package, moving it to the adoptive node if the SUBNET is active there.

To prevent package failover, disconnect the SUBNET lans on that node first. This however won't prevent ServiceGuard from halting the package on the normal primary node.

To prevent a package halt in the event of a SUBNET outage, configure the package to NOT watch the SUBNET.
That is, edit the package configuration file, commenting out the SUBNET reference, and with the package down, perform a 'cmapplyconf' on the configuration file. ServiceGuard will from that point on not see a relationship between that SUBNET and the package, so it won't halt or move the package if the SUBNET goes down.

As you can see, this is a complicated process and not one we recommend because it is so "hands-on" and potentially error prone.

-s.