Forum Discussion

rafaelbn_176840's avatar
rafaelbn_176840
Icon for Altocumulus rankAltocumulus
Nov 23, 2017
Solved

Viprion. 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

application delivery
LTM
TMOS
vcmp
viprion
  • Yann_Desmarest_'s avatar
    Yann_Desmarest_
    Apr 27, 2018

    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

     

8 Replies

Sort By
  • Yann_Desmarest's avatar
    Yann_Desmarest
    Icon for Cirrus rankCirrus
    Apr 27, 2018

    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's avatar
      rafaelbn
      Icon for Cirrostratus rankCirrostratus
      Apr 27, 2018

      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's avatar
      Yann_Desmarest
      Icon for Cirrus rankCirrus
      Apr 27, 2018

      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's avatar
      rafaelbn
      Icon for Cirrostratus rankCirrostratus
      Apr 27, 2018

      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_'s avatar
    Yann_Desmarest_
    Icon for Nacreous rankNacreous
    Apr 27, 2018

    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's avatar
      rafaelbn
      Icon for Cirrostratus rankCirrostratus
      Apr 27, 2018

      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_'s avatar
      Yann_Desmarest_
      Icon for Nacreous rankNacreous
      Apr 27, 2018

      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's avatar
      rafaelbn
      Icon for Cirrostratus rankCirrostratus
      Apr 27, 2018

      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.