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

[Don_Paterson]

Interistingly your scenario is covered in the new CCSE R82 training course. 

The HA ClusterXL cluster object needs to be removed from the configuration (rules, automatic NAT, VPN, and policy targets), and then I would delete the cluster object. 

Before changing any configuration and deleting the cluster object, I would carefully document the Where Used details of the cluster object. 

Then the ElasticXL object is added (which is just the single Gateway object) and placed wherever old cluster object was in the configuration. Meaning that the new SMO object (ElasticXL Gateway/object (single gateway object)) is put in wherever the ClusterXL object was before. 

With planning and testing, that can probably all be done with API commands, or mostly anyway.

That's how I did it in the lab. 

Doing it all manually is not such a big task in a smaller environment, but it does effect the management server configuration because of deleting the old cluster object and adding the new Gateway. 

I'd plan to do a snapshot of the management server for backup and DR but also consider a cloned management server to work on and take forward, but that depends on your management setup. 

With a cloned management server you have a known good backup.  

A Gaia snapshot is arguably just as good. 

For allowing uninterrupted flows through the new ElasticXL Gateway after it is plugged in, turning off stateful inspection temporarily comes to mind but that will only keep open connections alive and not help with network (L2) convergence or VPN connections that will need to be reestablish with the new Gateway. 

Here is a good video on ElasticXL 

https://youtu.be/Ctx9Su0y-e0?si=3smbuh6ACQawSu3f 

[Daniel_Hainich]

if you open the "where used" details, there is an "replace" button. so you can easily replace the old cluster object in rules and other objects. i tried this in the new r82-ccse course and it was working fine. 

[Don_Paterson]

That's good advise, and a great exercise to optimise the lab and prod. 

My aproach is to clean up and remove any records of the old object before introducing the new. Its just the way I like to do it, especially for a Gateway/Cluster, and probably because I'm old school and got experience in older, less dynamic, versions. 

I've also done it where a dummy host or Gateway object is placed in rules as a place holder. Again, old school and before the Replace feature. 

Whichever way is planned the testing should be thorough, including rollback and DR. Thats just the best practice. 

[_Val_]

On one of my sessions in Austria the last week, I was describing just that, without even reading the course 🙂 Management backup/snapshot is one of the ways to move forward while having an actionable regression option in case of failure.

[Don_Paterson]

Nice.

Another interesting part of the R82 CCSE labs is that we do a migrate_server export and then import to a new SMS VM.

That's more of a practical exercise to migrate to a stronger management platform (that's the scenario for the lab), so not really to have a backup of the SMS before replacing ClusterXL with ElasticXL, but it then actually offers the cloned server as a backup/rollback option in case anything goes wrong on the management side during the replacement. 🙂

[the_rock]

Done few of those before, thats really good "exercise".

Andy

[the_rock]

Nice video, Don. Btw, almost called you Steve, since I just responded to him haha

Andy

[Don_Paterson]

😄

It is a great video from the US team. 

For VSNext the TME series is also very good. 

https://youtu.be/bdrtNEN-Bw8?si=HFUz5pmcRoqdMLhF

[the_rock]

Saw that one before, yes.

[the_rock]

On a different topic, ever figured out thats whatsapp issue? : - )

[_Val_]

You only need one production IP address per clustered interface, nothing else. Play with it in the lab, see the demos, ask your partner to get you access to the ElasticXL lab if you can. It is a new way to build a cluster.