Forum Discussion
rafaelbn_176840
Altocumulus
AltocumulusViprion. Multiple blades and vCMP. Mirroring options.
Hello Devs!
I read on the oficial training guide that when you use vCMP, you do the mirroring on a guest basis. That makes sense to me.
But what if you have like a c2400 with 4x2150. Does the mirror "within cluster" applies?
root@(bigip1)(cfg-sync Standalone)(/S1-green-P:Active)(/Common)(tmos) list sys db statemirror.clustermirroring
sys db statemirror.clustermirroring {
value "within"
}
To me the mirror within cluster/between cluster only makes sense when we are talking about Viprions without vCMP. Am I right?!
One more thing. If I had a c2400 chassis with 4x2150 blades with vCMP enabled. If I had only one vCMP guest with only one CPU and it was configured with the proper permissions to run on all four blades. If blade1 failed, would this vCMP guest automagically run on blade2 without any disruption? Or would the vCMP guest fail and re-start on blade2?
Thanks! Rafael
Hello rafaelbn,
If you configure Mirroring "within Cluster", it means that objects requiring mirroring (connection, persistence, apm, session tables, ...) will be synched between all blades configured for the Guest. This setting is for Mirroring only, it doesn't affect Sync and Failover features.
It means that in case of a crash of blade 1 (hardware failure), your guest will continue to run on blade 2, then blade 3, etc.
But be carreful, in case of a software failure (bug, memory leaks, ...), all blades can be affected. By experience, I recommand to run a Guest on 1 blade only and define a Sync/Failover cluster with another Guest on another Chassis.
Hope it helps
Yann
Yann_DesmarestCirrus
Hello rafaelbn,
If you configure Mirroring "within Cluster", it means that objects requiring mirroring (connection, persistence, apm, session tables, ...) will be synched between all blades configured for the Guest. This setting is for Mirroring only, it doesn't affect Sync and Failover features.
It means that in case of a crash of blade 1 (hardware failure), your guest will continue to run on blade 2, then blade 3, etc.
But be carreful, in case of a software failure (bug, memory leaks, ...), all blades can be affected. By experience, I recommand to run a Guest on 1 blade only and define a Sync/Failover cluster with another Guest on another Chassis.
Hope it helps
Yann
rafaelbnCirrostratus
Thanks Yann!
I ran into some odd configuration on a client site. They have two chassis running as CMP with two blades and HA.
Some VSs and some persistence profiles are configured with mirror but I guess it's not working properly, since sys db statemirror.clustermirroring is set to within and sys cluster default min-up-members is set to 2 and sys cluster default min-up-members-enabled is set to enabled.
So what I think would happen is if blade1 crashed on the active chassis, it would failover to the second chassis. The problem is that since clustermirroring is set to within, the standby chassis never got those session state connections and mirror information in the first place.
Do I understand this correctly?
Many thanks! Rafael
- Yann_Desmarest
You are right.
You choose "within" so mirroring and session state is synched between all blades of the Guest but not with the Standby Unit.
You should change "min-up members" option to 1 to make sure that if blade 1 fails, you switch to blade 2.
The problem is that Mirroring still doesn't works with the Standby unit. The other issue is that Guest 1 will runs on blade 2 and Guest 2 runs on blade 1 which is not supported.
You should forget multi-bladed Guests and set Mirroring option to "between cluster", you will be in a supported scenario and Mirroring will works fine.
Hope it helps
Yann
- rafaelbn
I just confirmed that vCMP guest will behave just like you described. I thought that vCMP guest were not affected by "sys db statemirror.clustermirroring". This is bad.
Yann_Desmarest_Nacreous
Hello rafaelbn,
If you configure Mirroring "within Cluster", it means that objects requiring mirroring (connection, persistence, apm, session tables, ...) will be synched between all blades configured for the Guest. This setting is for Mirroring only, it doesn't affect Sync and Failover features.
It means that in case of a crash of blade 1 (hardware failure), your guest will continue to run on blade 2, then blade 3, etc.
But be carreful, in case of a software failure (bug, memory leaks, ...), all blades can be affected. By experience, I recommand to run a Guest on 1 blade only and define a Sync/Failover cluster with another Guest on another Chassis.
Hope it helps
Yann
- rafaelbn
Thanks Yann!
I ran into some odd configuration on a client site. They have two chassis running as CMP with two blades and HA.
Some VSs and some persistence profiles are configured with mirror but I guess it's not working properly, since sys db statemirror.clustermirroring is set to within and sys cluster default min-up-members is set to 2 and sys cluster default min-up-members-enabled is set to enabled.
So what I think would happen is if blade1 crashed on the active chassis, it would failover to the second chassis. The problem is that since clustermirroring is set to within, the standby chassis never got those session state connections and mirror information in the first place.
Do I understand this correctly?
Many thanks! Rafael
- Yann_Desmarest_
You are right.
You choose "within" so mirroring and session state is synched between all blades of the Guest but not with the Standby Unit.
You should change "min-up members" option to 1 to make sure that if blade 1 fails, you switch to blade 2.
The problem is that Mirroring still doesn't works with the Standby unit. The other issue is that Guest 1 will runs on blade 2 and Guest 2 runs on blade 1 which is not supported.
You should forget multi-bladed Guests and set Mirroring option to "between cluster", you will be in a supported scenario and Mirroring will works fine.
Hope it helps
Yann
- rafaelbn
I just confirmed that vCMP guest will behave just like you described. I thought that vCMP guest were not affected by "sys db statemirror.clustermirroring". This is bad.