upgrade VSX to R80.10 and replace the hardware

[Dawei_Ye]

Hi guys,

We have got a plan to upgrade our VSX Gateways to R80.10 from R77.20.

and also we are going to replace two old 13500 running VSX Cluster to two 15600 appliances.

There are two virtual systems running VSLS on this VSX Cluster.

I know the 'vsx_util reconfigure' could use to replace the hardware ,but 15600 didn't support R77.20.

Have you guys any experience on this workaround?

Thanks.

[Kaspars_Zibarts]

You can do both - HW and SW upgrade the same time. It would be very similar to steps I described here R77.30 VSX appliance upgrade to R80.10 

In nutshell

• install R80.10 on new boxes 
• preconfigure both with GAIA settings (interfaces, users, DNS, routing for VS0, backups, licenses etc)
• switch management cable on standby to the new box
• upgrade VSX object version in management to R80.10 using vsx_util
• do vsx_util reconfigure on the new box
• update any CoreXL / SecureXL params like affinity
• plug in remaining cables
• cutover (I don't think you will be able to use connectivity upgrade due to different HW versions)
• repeat vsx_util reconfigure on the new box, connect mgmt cable
• update any CoreXL / SecureXL params like affinity
• plug in remaing cables
• failover back to verify other box

We normally use lab to preconfigure and prebuild VSX boxes fully so during upgrade we only swap cables  but not many have that luxury

[Kaspars_Zibarts]

if you  are willing to wait I can post detailed instructions within couple of weeks as we will do exactly the same

[Dawei_Ye]

Hi Kaspars,

Sorry for late reply,and I am hangning on other things these days.

Thanks for your sharing.I will try the workaround on my lab,too.

Expecting your detailed instructions.

[Christopher_Ri1]

Would love to see these instructions as well.  Running into something similar soon as well.

[Kaspars_Zibarts]

On hold for couple of weeks, summer holidays  but sure enough they are coming

[cosmos]

@Kaspars_Zibarts I know this is old, did you end up posting detailed instructions? I have a customer with a similar requirement - upgrade from R77 to R80 on new hardware with minimal downtime (FCU if possible). We also need a fast rollback plan that doesn't involve restoring from snapshots (ideally).

My initial thoughts are we have 2 options:

1. Join the existing cluster
   1. As above, I'm hoping we can use cphacu but it doesn't sound promising due to different HW
   2. Will this even work if the interface names are different on the new hardware (vsx_util change_interface applies to the VS as a whole, not an instance on a member)?
   3. Rollback without snapshots could be a challenge if we have already upgraded the VSX object (see vsx_util downgrade caveats)
2. Build a new cluster
   1. Replicate each VS on the new cluster (ports will either be shutdown or VLANs not allowed to avoid a form of split brain)
   2. Move cables (shutdown switchports / remove VLANs to old cluster, no shut switchports / add VLANs to new cluster
   3. Migrating one VS at a time is not really an option due to the heavy use of virtual routers & switches

The customer has roughly 75 VS across 2 clusters on the same MDS, option 2 sounds like it will have a better rollback path due to the independent clusters but requires all 75 virtual systems to be replicated on the new cluster (150 until the migration is complete, I think I will be getting very friendly with the VSX Provisioning Tool).

We have our SE looking for FCU-type options, fingers crossed.

cc @PhoneBoy ?

[Kaspars_Zibarts]

Hi @cosmos ! You are absolutely correct - VSX provisioning tool is a must.. 🙂 Let me check how much I can copy paste here - we recently moved our VSX from 41k chassis (R76SP) to 26k appliances R80.30 without a single incident raised 🙂 approx 20 VSes. Had exactly the same requirements - fast rollback on gateways and Mgmt. Let me check!

[Andrew_Theron]

@Kaspars_Zibarts @cosmos @PhoneBoy

I also have a client looking to do something similar. The documentation around such an engagement is also slim to none.

Am very keen to see how you would go about solving this one.

Thanks fellas!

[_Val_]

"Something" is the key word here. Depending on what you are doing (just replacing HW or also changing VSX config), there are two completely different approaches possible.

What is your specific case?

[G_W_Albrecht]

Many long years filled with VSX experience will surely help when performing these actions 8)

[Kaspars_Zibarts]

Hehe @Andrew_Theron don't forget that CP needs to sell professional services 🙂 but as Val said - every VSX deployment is rather different so approach of upgrade really depends on environment. It's hard to write a book for every single scenario. Therefore you can either start playing yourself in lab environment with scarps of info that are available here and build your own approach or you engage CP PS. 

I'm totally snowed under with work and won't have time to reply any time soon I'm afraid 😞 

[CheckPointerXL]

Hey,which scenario did you apply?