Forum Discussion
Replacing Two HA Platforms with HA VEs
- Nov 15, 2022
Hi speachey ,
I like such these changes.
> Both of options are good ideas for migration , and you covered them well.I want to add some points below :
- After Activating the new licenses on both of New "VEs"
- Take the Master Key from of old F5 4200 appliance , it is enough one appliance as this Key is shared between them as long they are in HA Cluster or single device group.
For retrieving or getting this key issue the below Command on bash shell :
#f5mku -K , Note "K" is a uppercase letter.
Copy it’s output and save it in safe place.
before migration you must re-keying the master key on F5 Virtual edition " VEs" by issuing the below command on bash as well :
#f5mku -r "Key_output_from_the_old_appliance" , Note "r" is a lowercase letter.
> Without Re-Keying the master Key on "VEs" , your migration fails from the first step. - import "UCS" file , or transfer it to " /var/local/ucs " directory.
- Make sure that , the new VEs license is identical with Old device license in Features , I mean for instance if you have on your old devices " ASM , IP intelligence , GTM " you need to request a new license with the new "VEs" contains " ASM , IP intelligence , GTM " which are the same modules or Features.
- it is very very good to power both of VEs on the same version like old devices.
- when loading the ucs on VEs , correct you will use platform-migrate option but you must use the below command on tmsh prompt :
(tmos)# load sys ucs "File_Name" no-license platform-migrate.
> Why " no-licnse option" because F5 licenses is related to Appliances’ serial numbers and other parameters , and of course the license which exists on UCS is related to old appliances and is tied with its serial " mean old devices serials " .
So that you must exclude old license during loading ucs , at the same time you already configured the new license in " step number 1 " - After That , Revise your network design and Flow , and select your new interfaces which you are going to use , and assign again the Vlans to your interfaces " From Network >> Vlan >> (assign your needed interface to your vlan) " this part is depending on your design.
- I assume you will load UCSs on both of VEs
- After finishing " Vlans , Trunks , routes " , you will need to check the HA between both of VEs.
> I recommend that :
- Break up the HA between both of VEs , and remove each other from their device group.
- Re-build HA between both of VEs from scratch.
- Generate a new Certificate for both of them , before building device trust , check the below snap shot :
- Do not forget this step , the trust idea is exchanging certificates between both of appliances and you should not use an old certificate " old certificate will be transferred from old appliance via ucs on the new VEs " so you need to Re-new or re-generate new one.
> Follow this KB to build your HA correctly :
https://support.f5.com/csp/article/K42161405 - After Finishing HA , you will be about step on migration and you can test your services offline before changing the path of traffic from old appliances to new VEs.
- After making sure that all is fine , Take your maintenance window and change traffic Path to VEs to serve your application.
- Do you know , I do not recommend working with VEs over real Appliances , I think you will buy a new 2 physical appliances in the future , as a hardware based is more stable , speedy and efficient than Virtual edition.
- I prefer to choose " load ucs options ".
- I do not think disabling interfaces will add anything.
- you can use forced offline option , it is a very good idea.
- Automatic or manual Sync is not a problem in migration , start with manual sync , after guaranteeing that everything is stable , you can switch to Automatic sync.
I know you have covered most of my points , so I hope the above procedures help you if there are any missing point with you in migration plan.
GoodLuck in your Migration , you will enjoy by taking this Action.
Regards
I've gone with option 2 in the past and it's been successful.
Some additional tips:
- Ensure connectivity on all VLANs (ping self ips between devices). Reason because L2 config might not be correct.
- I don't think it's in the list, but forcing the old passive node to offline and disabling interface is a good way to get a fast rollback.
- Disable the old nodes interfaces before turning the new VM on.
- Run the VM as active at least 1-2 days to ensure that it works as expected before migrating the other device.
I don't think you need to worry as long as you follow your game plan. You've seem to have thought this through properly. Thumbs up!
Thanks Patrik! Good ideas to ping/verify L2 and run one VE as Active for a few days before replacing the other platform. I'm replacing two similar HA platform pairs in different DCs with VEs and I will start with the DC that is not as high profile and test thoroughly. I suggested shutting the platforms down instead of forcing them offline because I plan to use the same mgmt config as the platforms they are replacing. I'll probably actually leave the platforms up and shut all of their interfaces at the nexus switches (mgmt, HA, trunk) so I could bring platforms back up quickly, if needed.
Just curious...have you noticed any performance issues switching from platform to VE? I don't think our load requirements are that high so it looks like VE should work fine ( 1K virtual servers, max of about 50K active connections, 150M throughput[bits], 250 APM Access Session/sec)
- Nov 16, 2022
"I'll probably actually leave the platforms up and shut all of their interfaces at the nexus switches (mgmt, HA, trunk) so I could bring platforms back up quickly, if needed." - exactly my point. 🙂
As for performance, you should be ok. I have had to back out of a VE migration once because of performance but this was a high intensive sports book betting application. Have you read the docs about VMWare specific settings (if you're using VMware)?
https://clouddocs.f5.com/cloud/public/v1/vmware/vmware_users.html
Migrating the master key is not a bad idea by Mohamed below (if you're not using the ucs path). IIRC it's used to encrypt sensitive stuff in the config such as TLS key passphrases.
- speacheyNov 16, 2022Cirrus
Thanks again. I believe the f5-recommended sizing for our VE builds was used but I'll review the guide with our VMWare team
- Nov 16, 2022
There are some other options in the article rather than sizing such as LRO/GRO. Read the whole thing and you'll see. 🙂
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com