Central license open platform cluster hardware upgrade primary

[Adam276]

When upgrading hardware with central licensing on open platform, How do you deal with the upgrading the final primary system hardware during the upgrade in a way that you can fully test the secondary and still be able to have the management access the primary to remove the license on the primary after the secondary is verified working as expected?

I have seen steps where you issue a 'cpstop' command on the primary to make the upgraded secondary go active.  Wouldn't that break communications between management and the primary in a way that the management wouldn't be able to remove the license from the primary when it is time to upgrade the primary hardware?  I wouldn't want to remove the license from the primary until after the secondary is verified working so that a fail-over back to working state would be as quick as possible if secondary doesn't work.

Would clusterXL_admin down be better to use when switching to the secondary so that the primary would still be able to communicate with the management?  Or is it ok/safe to issue a cpstart on the primary after the secondary has taken over?  A note that the primary will still be on R80.10 and the secondary will be on R81.20 (in case that matters with the cpstart).

[G_W_Albrecht]

When installing on a new hardware, you automatically have the PnP license (14 days afaik) on it.  If you install config from backup this usually includes the license. Also, if you have the module/management portions of the license, you could install the module (GW) part manually (e.g. from CLI or WebGUI).

sk107042: ClusterXL upgrade methods and paths

R81.20 Installation and Upgrade Guide - Upgrade Methods

[Chris_Atkinson]

Is there some part of the license process that you're trying to avoid for some reason i.e. reactivation via UC?

1. Depends on the topology of the management interface is it clustered or private

2. Leveraging eval licenses temporarily is an option 

3. Licenses can be removed locally

[Adam276]

Chris,
The problem that I see is that the normal processes that are explained in the forums for hardware changes for as little downtime as possible involves running cpstop on the primary at some point where you make the secondary active.  If I do that, I assume management will not be able to detach the central license from the old primary hardware when it is time to upgrade the primary hardware (after an hour or two of testing).  So management at that point will think it is still attached and maybe not allow me to reattach it again to the same object when I put the new hardware in place without detaching the old central primary license through SmartUpdate.

I am not trying to bypass anything.  I am just trying to get the license on the new primary hardware during the hardware upgrade process after the secondary has been upgraded.  The secondary is easy as I can detach that before I start the upgrade while the old secondary is still in cpstart state.  I will have the primary to failover to if the secondary fails so I don't want to detach any licenses or modify the primary in any way before the secondary has proven in good working state.

The primary will be in cpstop state though so the management will still think the central license is still attached to the primary when I remove the primary and put the new primary in place.  The management needs to know that it is no longer attached to the old primary so that I can reattach it to the same object.  Is this figured out automatically somehow and will allow me to reattach it again to the same object that management thinks it has already been attached to?

Is there some mechanism for central licenses (attached to management IP) where the management will see that it has been attached in management but the gateway doesn't have it and allow it to attach it again or is there some other way to force detach the license in management so that it can then be reattached to the same object?


Albrecht,
Thanks for info but I didn't see any information about changing to new hardware and dealing with central licenses during the hardware upgrade process in those documents.

Everything I have read including on this forum has mentioned that you must use management to install central licenses on gateways (restoring from backups are an exception for like hardware). I use SmartUpdate for that.  This is going to new hardware (much newer) so the normal webui backup wouldn't work from what I have read and I am also transitioning to a new version at the same time so it the new hardware was installed from scratch with the new version.

The 14 day trial license has expired already, but even if I reinstall and it wasn't expired, that would only be temporary if the management has checked out the license already to the old hardware and thinks it is still attached when it really isn't (hardware was replaced)..

Thanks for the feedback on this.  Maybe there is some automatic stuff that happens in this scenario where management thinks a central gateway license is attached to a gateway but it isn't actually attached on the hardware itself (hardware replaced) where it detaches it automatically and allows you to reattach it or reattaches it automatically if it is checked out to the firewall object already in Management.  I am being cautious as I haven't found anything that hints at that.

For regular licenses that are not central and require management to attach them, it is much easier I would think but for central licenses, management has to check out and check in the licenses to know what they are attached to so that you can't attach a license twice.