Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Isolate guest for vCMP but I need remain the sync between cluster members

I have 3 chassis each with a blade. Two of the three chassis are in the main data center and the other is in the alternate data center.

4 guest were created in each chassis which are clustered in threes, each housed in a chassis.

The customer wants for any reason the guest that is in the chassis roll take alternate data center active within the cluster but if you receive synchronizations sent from the guest that are in the main data center.

I took a look and found an option that worked in a cluster in version 12 but to make the same settings on my client infrastructure no longer worked.

The idea is to modify the "Minimum Number Of Blades Up Device Is Considered Before Available" parameter within the chassis guest in the alternate data center. By modifying this parameter to greater than 1 (4), this guest would enter a state of "failsafe-foult" where virtual server services are disabled but connectivity exists and can receive synchronizations.

When did the change in the guest, its status will not change to failsafe-foult but remains in the standby state.

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

The system should still report that it's in standby, but if you look at "tmsh show sys ha-status" if you have it set to require more blades than it has it should report a failure. Generally the system's actual status will be:

  • Active - taking traffic
  • Standby - not taking traffic, but otherwise functional (can connect to self-IPs, for instance)
  • Offline - generally manually forced to an offline state, or configuration load failed
  • Inactive - Not yet fully up

If you are in failsafe, I would expect the box to remain in standby, but show the failure in ha-status.

0
Comments on this Answer
Comment made 19-Apr-2016 by gcallejas 2
I understand everything you say but my client wants the BigIP that is in the alternate data center never assume the roll of active but at the same time that syncs with the other two machines. while in standby mode, the active BigIP could change at any time and that is exactly what my client does not want.
0
Comment made 19-Apr-2016 by Chris Grant
If the BigIP is in a failsafe condition it will never go active. Be aware that they will need to bring it up manually if they have to go to the alternate data center, and that the networks will need to be compatible, as the BigIP will sync network objects that are intended for the active data center. You may wish to discuss your specific requirements with Professional Services to ensure that the BigIP will do exactly what you wish in a datacenter failover.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Hi Gabriel,

The settings that you should have in production is as follows:

Image Text

Here is the tmsh output:

Before the change user@(vcmp1)(cfg-sync In Sync)(/S1-green-P:Active)(/Common)(tmos)# list sys cluster sys cluster default { address 172.20.10.5/24 members { 1 { } 2 { } 3 { } 4 { } } min-up-members 1 min-up-members-enabled yes }

After the change user@(vcmp1)(cfg-sync In Sync)(/S1-yellow-P:FailsafeFault)(/Common)(tmos)# list sys cluster sys cluster default { address 172.20.10.5/24 members { 1 { } 2 { } 3 { } 4 { } } min-up-members 3 min-up-members-enabled yes }

0
Comments on this Answer
Comment made 19-Apr-2016 by gcallejas 2
when I put the command tosh show /sys ha-status this is the response: admin@(test3)(cfg-sync In Sync)(/S1-green-P:ForcedOffline)(/Common)(tmos)# show / sys ha-status --------------------------------------------------------------------------- Sys::HA Status Slot Feature Key Action Fail --------------------------------------------------------------------------- 1 cluster-mbr-disabled clusterd go-offline-downlinks no 1 cluster-time-sync clusterd reboot no 1 config-not-recvd sod go-offline no 1 crypto-failsafe cn-crypto-0 none no 1 crypto-failsafe cn-crypto-1 none no 1 daemon-heartbeat bigd restart no 1 daemon-heartbeat cbrd restart no 1 daemon-heartbeat clusterd go-offline-downlinks-restart no 1 daemon-heartbeat mcpd restart-all no 1 daemon-heartbeat scriptd restart no 1 daemon-heartbeat snmpd restart no 1 daemon-heartbeat sod restart-all no 1 daemon-heartbeat tmm go-offline-downlinks-restart no 1 daemon-heartbeat tmm1 go-offline-downlinks-restart no 1 daemon-heartbeat tmrouted restart no 1 daemon-heartbeat vxland restart no 1 daemon-heartbeat wccpd restart no 1 forced-offline sod none yes 1 hypervisor-offline chmand go-offline no 1 license-invalid mcpd go-offline-downlinks no 1 min-up-cluster-mbr clusterd failover yes 1 mpi-failsafe tmm go-offline-downlinks no 1 nic-failsafe tmm reboot no 1 nic-failsafe tmm1 reboot no 1 overdog-ctrl watchdog none no 1 proc-run bigd go-offline-downlinks no 1 proc-run clusterd go-offline-downlinks no 1 proc-run mcpd go-offline-downlinks no 1 proc-run named go-offline-downlinks no 1 proc-run tmm go-offline-downlinks no 1 proc-run tmrouted failover no 1 ready-for-world tmm none no 1 ready-for-world tmm1 none no 1 reboot-request sod reboot no 1 software-update lind reboot no 1 tmm-detect-fail tmm failover no 1 wait-primary-sod sod none no this means that this BigIP never be in active mode ?? thanks for your help!!!
0