Of late there appears to be some confusion around how to migrate an existing ISAM software installation to the ISAM appliance. I think that a large part of this confusion stems from the fact that the migration appears to be scary - when in reality it shouldn't be. The good news is that IBM is in the process of putting together a program to address this confusion, and hopes to provide this program to all customers sometime in 2014. In the meantime I want to provide a high level view of how to migrate an existing ISAM environment to the appliance.
A typical ISAM for Web environment contains 3 major components:
The migration of each component is slightly different and will be covered below.
User Registry Migration
The user-registry migration is perhaps the simplest of any of the components - i.e. you shouldn't migrate your user registry. In a migrated environment the user registry should continue to run on existing hardware and should continue to operate as it does today. The only exception to this is an environment which currently depends on Active Directory for the user registry. The appliance only supports Active Directory to house the user meta-data and not the ISAM meta-data (i.e. secAuthority=Default suffix). So, if you are currently using Active Directory as your user registry an additional step is required to migrate the 'secAuthority=Default' suffix from Active Directory to a supported user registry. The product documentation contains further information on this.
Policy Server Migration
The migration of the policy server to an appliance is relatively trivial. The appliance now provides a perl script which can be executed on the server which is currently running the policy server. The perl script, isam_migrate.pl, is available from the downloads section of the appliance, accessible from the "Manage System Settings -> File Downloads" panel.
This perl script, when executed on the machine which is running the policy server, will produce a zip bundle which contains all of the configuration information for the policy server, along with the policy database. This zip bundle can then be imported into the appliance as a part of the 'ISAM Runtime Component' configuration:
Once the zip bundle has been imported into the appliance it will be running an instance of the policy server. The policy server will be configured to listen on the management interfaces of your appliance. Your existing policy server should now be stopped, and your existing WebSEAL instances can now be configured to start using the migrated policy server. This can be done by editing the WebSEAL configuration file, and changing the master-host configuration entry, within the [manager] stanza, to point to the first management interface of the appliance which is running the policy server.
The migration of your policy server should now be complete.
Policy Server HA
In version 188.8.131.52 of the appliance we also added the runtime configuration to the clustering capability of the appliance. This now provides us with high-availability of the policy server itself, via a warm standby system.
The primary master of the cluster will always be running the policy server. Each 'node' within the cluster will contain an up-to-date copy of the runtime configuration along with a copy of the policy database. In the event that the primary master dies, the administrator is then able to promote one of the existing nodes to the role of primary master. As a part of this promotion process:
The policy server is started on the new primary master;
The runtime configuration of all nodes within the cluster will be automatically updated to start using the new policy server;
Please note that the promotion of the node is a manual process. It is up to the administrator to determine when a new policy server is required in the environment. Some customers have requested that we provide automatic fail-over, but this complicates the implementation tremendously, and as such we have started with a manual failover solution. In the future we might investigate the potential of making the fail-over automated.
In order to configure the environment for a HA policy server, you first need to configure your environment into a cluster. This is done via the 'Manage System Settings -> Cluster Configuration' panel. At a minimum you will need a primary master (which will execute your policy server), and then each WebSEAL appliance should be registered as a node (i.e. each WebSEAL appliance should be joined to the cluster).
To set up your primary master, you need to change the 'primary master' field on the 'General' tab to be the first management interface of your appliance:
Once this change has been deployed the 'Export signature file', on the 'Overview' tab, will allow you to export a signature file for the cluster.
This signature file can then be imported into a different appliance when you need that appliance to join the cluster. It is worth mentioning that the import process could take a minute or two to complete, and so it is important to be a little bit patient when setting up your cluster.
The final step in setting up HA for the policy server is to then enable the replication of the ISAM runtime configuration information to the rest of this cluster. This is done on the 'Runtime Component' panel on the primary master:
WebSEAL Instance Migration
Support for the migration of a WebSEAL instance to the appliance has been around since the first release of the appliance in 2012. The concept is very similar to the migration of the policy server. A perl script, wga_migrate.pl, is available from the downloads section of the appliance, accessible from the "Manage System Settings -> File Downloads" panel. This perl script should be executed against the desired WebSEAL instance on the WebSEAL machine. It will produce a zip bundle which contains the configuration information for the WebSEAL instance, including among other things:
SSO key files;
SSL certificate key files;
XML configuration files (e.g. HTTP transformation rule files);
an abstract of the WebSEAL configuration file.
This zip bundle can then be imported into an existing WebSEAL instance running on the appliance, using the 'Reverse Proxy' management panel.
It is critical to note that the instance which you are importing the zip bundle into must have the same instance name as the originating WebSEAL instance.
When migrating to the appliance you should also perform a re-evaluation of the WebSEAL instances in your existing environment. It is best to minimise the number of instances present in your environment, and in recent releases a lot of development time and effort has been spent to enhance WebSEAL so that customers can reduce the number of instances that are required (e.g. check out the SNI certificate support, and the ability to specify WebSEAL configuration on a per-junction basis).