Converting Tool - ClusterXL to ElasticXL

[HeikoAnkenbrand]

I’ve opened a new article on this topic.

In the near future, there is supposed to be a tool that allows converting a ClusterXL into an ElasticXL cluster.

This is discussed in the following article: 
Replacing 5800 HA ClusterXL with 9200s. Should I convert to ElasticXL?

What information is available about this tool and when will it be released?

@matanbe_chkpcp
Can you already provide any further information about this tool?
This would be very relevant for planning with our customers.

[the_rock]

Sounds, to ne anyway, based on what @matanbe_chkpcp had said, since its in final testing, should be available sooner rather than later, but lets see : - )

Andy

[HeikoAnkenbrand]

My questions are basically the following:

1. A ClusterXL normally has a different cabling setup than an ElasticXL cluster (e.g., SYNC, MAGG1, …).
   How can the tool help with converting this?

2. How will the licenses be handled? They are different for ClusterXL and ElasticXL.

3. Will there be a possibility to convert a VSX cluster into an ElasticXL + VSNext cluster?

[the_rock]

Im positive Matan will be able to answer all those questions. Very good point about cabling and licensing though.

Andy

[Adeesha]

Hi,

1. As far as I know the cabling is similar between ClusterXL and ElasticXL so that should not be a problem.
   If you have a specific case or concern, please share.
2. This is still under investigation, but if the license is not sufficient after the conversion, a new one can always be configured and the process will not be harmed.
3. Yes, using the tool you will be able to convert from the following platforms:
   ClusterXL to ElasticXL
   VSX ClusterXL to VSNext ElasticXL
   VSX maestro to VSNext Maestro

[_Val_]

The tool is still in development. Before it is ready, I would not speculate about the details. 

[Perry_McGrew]

I created the original post on 5800 ClusterXL to 9200 ElasticXL.  @matanbe_chkpcp mentioned the tool they are developing to assist in converting a GW cluster to ElasticXL.  Several CP techs seem to highly recommend ElasticXL.  I never got a response to my PM on the tool - so I presume its still not ready.  I even reached out to our CP account team who do not know much -- only the rumors. 

We are 24x7x365 not-for-profit eldercare with 19 sites; so any "significant" outages are to be avoided.   The reading I have done on ElasticXL seems to indicate I would need some sort of outage to setup the 9200's in ElasticXL to replace the 5800 ClusterXL.  We use all 8 of the 5800 Interfaces - we need to maintain all the IPs / VIPs assigned to the 5800 Interfaces which would seem to preclude me from pre-configuring them in SmartConsole. 

Unfortunately I don't have a lab environment to be able to investigate / dry run an ElasticXL setup.  I was wondering if anyone here has gone through the process of replacing a ClusterXL with ElasticXL?  

Since our 5800's are EoL, I need to get the 9200's installed.  I will just set the 9200's up in ClusterXL on its fresh R82, import the JHF 41 currently applied to the 5800's.   I can replace the Passive member, push policy, then fail active 5800 member over to the new, passive 9200 - making it the Active GW and repeat.  Basically a minimal outage.   Then wait for this Conversion Tool to appear.  

[_Val_]

@Perry_McGrew As mentioned above, the conversion tool is still in work. This is not a trivial matter if you expect a one-click conversion experience. Especially considering you need to revert to a fresh install before configuring the ElasticXL cluster. Even with the tool ready, there will be a short interruption because the old and new clusters cannot sync.

However, it is possible to come up with a scenario of a relatively similar procedure, like one you described for replacing the appliances.

In your case, you can set up the new ElasticXL cluster, isolated from the production networks before switch-over, push policy on it, and then swap production networks to re-route the traffic through the new cluster. 

[Perry_McGrew]

I expect conversion would entail some sort of outage.  Even the typical hardware Swap using the Passive ClusterXL member seems to cause an outage to the remote P2P VPNs.  If the conversion tool requires a significant outage, I won't be able to move to ElasticXL.  As for the "fresh install", I would hope that since the 9200's will come up on R82, then apply the current JHF, it will count as a "fresh install" vs the many upgrades the 5800's went through. 

I realize I can setup the 9200 ElasticXL "off net" at my desk.  This is how I prepped all the 3920's I had to deploy at the remote sites to replace the 3200's.  Once I got to the site I had to reset SIC on the Mgt server and then push policy to the 3920's.  I don't see how I can initialize SIC and push policy to the Isolated 9200's since I need to maintain the interface IP / VIPs.  

[_Val_]

@Perry_McGrew Just to make sure we all unerstand the process.

1. ElasticXL requires all cluster members to be in a fresh install state. SMO must go through the first-time wizard process to get ElasticXL option enabled. Other members remain un-initialized state and automatically join the cluster when you claim them.

2. To set up a cluster, you only need SMO to be communicating on Sync and MGMT networks. You still can connect production interfaces to isolated networks/vlans, but you don't need them to be communicating to the actual priduction domains

3. The way I see it, you set up a new cluster and only use DMI MGMT connection to your Security Management Server to set up an SMO object and establish SIC. When done, you need to push policy. Once it is there, you can swap the cluster. 

That is how I would plan the procedure. Let me know if it makes sense

[Perry_McGrew]

I was speaking with CIO and he would like to pursue ElasticXL install.   I got to dive deeper into the setup docs as there are terms I am not that familiar with.  Off the top, I am still not clear on how to set this all up on "isolated networks" and maintain the IP/VIPs. 

[Bob_Zimmerman]

One of the cool things about ElasticXL is that it doesn't really have VIPs. Instead, each member actually has the same address on each of the various interfaces. The only unique addresses are on the sync bond, and they're managed automatically (though they are in the 192.0.2 documentation block, which is incorrect and should be fixed).

He's saying you could stage an ElasticXL cluster ahead of time without connecting it to the real network. You can even push policy if you build it with an additional staging interface and establish SIC with your real management. Then when it's time to deploy, you pull cables from the old members, plug them into the new members, edit the ElasticXL gateway object to remove the staging address, and push policy again.

It's complicated, but can get you to a new cluster with under a minute of hard downtime. Takes a lot of practice to do that quickly, but if minimal downtime is important, any major change should be practiced at least a few times. I run most of my big changes in a lab 10-15 times before trying them for real.

[the_rock]

I really believe that tool, whenever is available publicly, will be super popular.

Andy