centralized management, configuration management

robertrenner · ‎06-03-2008

Hi Folks,

i just want to know how you are managing your configurations in a clustered environement. since there is no official possibility to restore a configuration from a previously saved config xml in a cluster, it is very interesting to know how you guys make it possible to "go back" :)

in my situation i have to prove that i always have the ability to restore the configuration of the complete system, otherwise any of my change requests will be set to "disapprove" :cry:

many thanks for your feedback in advance,
rob

Rayman_Jr · ‎06-03-2008

The roll back will not be an easy task in clustered environment.

One option I can see is to break the cluster and save the configs for roll back.

I had to do that once prior a big change. The procedure were basically the following:

1. Remove appliances from cluster one by one (remove completly, not only disconnect)
2. Save the configuration of each box
3. Add appliances back into cluster
4. back to step 1.

Then you will have a configuration of individual box which can then be used in disaster recovery. Unfortunately you have to rebuild your cluster if you want to roll back.

Another drawback was that when removing appliances from cluster the SSL certificates are also lost. So, you have to reinstall those if you are using TLS.

I'm more than interested to hear better ideas :shock:

robertrenner · ‎06-09-2008

seems that not to much guys does have a clustered environent ... or change management :roll:

@jariih: thats the way i have to go[...]. but just to be honest, it think for a upper class email security appliance like an ironport i think this is a bit 'measly' :-), isn't it ?

joe_ironport · ‎06-09-2008

If you read through the Centralized Management section of the admin guide it talks about rolling out changes in a clustered environment and the ability to stage changes. That might help you.

You're not allowed to restore the config of an individual machine in the cluster for security reasons. The host keys would also change if you have a different appliance and then the appliances in the cluster won't talk to each other.

Joe

steven_geerts · ‎06-13-2008

Hi,

What you possibly can do is disconnect one machine from the cluster and perform the change on that disconnected machine. If everything works as expected you can join the cluster again and your changes are replicated over your other cluster members. If thing go wrong you can remove your disconnected machine from the cluster, reset the machines configuration and add it to the cluster again. This is a quite drastic way of performing a rollback, but I think you will meet the requirements of your change management department.
There is one thing to be careful with: when your cluster is not fully connected you can modify settings on your disconnected machine(s) and on one of your other (connected) cluster members. When the cluster gets reconnected again you need to select what changes you want to keep..... While typing this I think that might be another way of rolling back.... if you need to rollback just make a harmless change on the cluster (changing a user to guest and back to operator or admin or so) and than, at cluster reconnect select the harmless change as the one you like to keep.... (BEWARE: THIS IS JUST GUESSING, please test carefully before you start to trust on this as a rollback scenario)
It might be worth to try...

Regards Steven

wmchurch_ironport · ‎06-15-2008

There are a couple of ways you can do this.

1. You can create a new cluster group and make your changes to that cluster group. If you need to back the changes out, simply move the ESAs back into the parent group or your "gold" cluster group. I don't think a lot of people realize the power of cluster groups.

2. A low tech approach can also be accomplished with your systems documentation. I don't know of many changes one would make to an IronPort that can be backed out by documenting your changes and then referring back to your document to back them out.

I make it a point to keep a log of the changes I make to any system, we use a wiki internally to document our changes. It would be nice to backup and restore at the cluster group level and this should be "simple"

3. You can make a backup of the entire cluster at any time (System Administration | Configuration File) that can be used to restore the entire cluster (all groups) in the case of DR. The configuration file is plain text XML and is very easy to read and understand. You can use diff tools (like windiff or notepad++) to compare previous versions and find your changes.

In the event you have to revert back to a previous configuration you can simply reverse your changes in the GUI or, remove all ESAs from the cluster, upload the config to one of them and recreate the cluster from that ESA. I wouldn't do this, but in a DR situation you'd have to.