Forum Discussion

DarioGB_339840's avatar
DarioGB_339840
Icon for Altostratus rankAltostratus
Apr 10, 2019

Splitting one device into several vCMP Guests

Hello,

I'm opening this case to interchange opinions regarding how to migrate one device with many objects (around several thousand nodes and several hundred VS) into smaller entities. I mean several vCMP Guests with smaller bunch of nodes and VS.

Taking into account that the 'big' device is under production, I would like to find a way to migrate this without taking too much risks.

My first approach is to prepare a custom configuration (with only the small set of VS/nodes of each new device) and migrate everything during a maintenance window using a command like '

load sys config
'

  • PROS - It's not necessary to planning a strategy for migration.
  • CONS - too much risky. I could forget to include something important in the config file.

My second approach is to disable Client VLAN access and migrate each VS and node gradually, but I have cases when Nodes and Clients share the same VLAN, so there is no way to create a new (replicated) VS with the same configuration in the same VLAN without interfering the production enviroment.

  • PROS - permits to migrate the configuration gradually.
  • CONS - not all the topologies permits client access isolation.

My third approach is to take advantage of config-sync device groups, trying to separate each group of VS in different device-groups, to synchronise part of the configuration of the 'big' device to the new members of the cluster (the new instances of vCMP Guests).

REF - https://support.f5.com/csp/article/K15496

  • PROS - Less risk and fast.
  • CONS - Requires to have already split the configuration in several Config-Sync groups, which it's not the case...

I would like to know your ideas and also if you have done something similar in the past. how was your impressions?

KR, Dario.

application delivery
BIG-IP
TMOS

2 Replies

Sort By
  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Apr 11, 2019

    Hi DarioGB,

    I would prefer your first approach by using the 

    load sys config merge from-terminal
    option to apply related objects one after another. The 
    merge
    option will make sure that all depending objects are already included.

    Depending on you core network infrastructure it may be also possible to run your old and new setups in parallel, so that you can test the new environment before moving production traffic (e.g. via Route changes, via DNS changes, via 1:1 NATs infront of LTM). I migrated and restructured once a LTM setup for a customer and we decided to test the new setup with the traffic comming from internal employees for several weeks, before moving the external traffic. It has worked like a charm...

    Cheers, Kai

  • Andy_McGrath's avatar
    Andy_McGrath
    Icon for Cumulonimbus rankCumulonimbus
    Apr 11, 2019

    Highly recommend you look at the use the BIGdiff tool to assist with checking the status of Virtual Servers and Pools etc during migration.

    This will allow you to quickly check the status of services between the old and new devices during migration.

    The way I have migrated before is import the configuration in using the 

    load sys config merge
    command, either from a file or from the terminal, but having the Interfaces disabled then once ready disabled the interfaces on the old F5, enabled the interfaces on the new F5 (you may want to clear your connected switches MAC/forwarding tables).

    If you have new Self IP addressing on the F5 and separate VLANs between the client and server side you can bring up the server side interfaces/VLANs so all your monitors work and can check the status of your pools and virtual servers (using BIGdiff) before you perform the cut over.

    ARTICLE: BIGdiff - A Little Help For Software Upgrades