How to minimize outage time when converting from a standalone to a clustered RSA Identity Governance and Lifecycle deployment
3 years ago
Originally Published: 2018-03-02
Article Number
000054823
Applies To
RSA Product Set: Identity Governance and Lifecycle
RSA Version/Condition: 7.0.1, 7.0.2
 
Issue
RSA documents a method for converting a Wildfly deployment "in place" from standalone to clustered.  See: RSA particularly refers you to the "Supported Configurations" section of both above documents.

To simplify fallback plans, you may consider setting up a new clustered environment, rather than converting the existing standalone deployment "in place". A method for doing so is, at a high level:
  1. Build a new standalone environment.
  2. Put the old standalone environment into maintenance mode, to stop all activities on it.
  3. Export the old standalone's database
  4. Shutdown the old standalone environment as it will only be needed as a fallback option should the clustering attempt fail 
  5. Import the old standalone database into the new standalone environment
  6. Convert the new standalone environment to clustered, as described in the above published RSA documentation for your version
  7. If the clustering fails, you can fallback to the standalone environment. Meanwhile, keep the clustered environment "as is" for troubleshooting. 
    • At the end of each of the above Configure Wildfly Clustering documents is a "Troubleshooting" section. If you are having difficulty converting to a clustered architecture, see if that section helps. Of course, contact RSA Support if you need assistance.
This method requires an outage while the export, import and clustering is done (steps 2 to 6).  Clustering (step 6) may be time-consuming and as it involves many tasks, may be prone to error.

 
Resolution
RSA will support importing the database from your standalone deployment to the new cluster deployment.  This allows for a procedure that still requires outage time during import and export, but as the clustering step can be done while production is running, the clustering portion of the outage is eliminated.  It also minimizes risk as the clustered deployment can be prepared earlier and tested, whilst the fallback procedure is still quick and simple:
  1. Build a new standalone environment.
  2. Convert the new standalone environment to clustered, as described in the documents in the Issue section above, and confirm it is generally operative with an "empty" database.
  3. Put the old standalone environment into maintenance mode, to stop all activities on it.
  4. Export the old standalone's database
  5. Import the old standalone database into the new clustered environment: Follow the instructions in the Database Setup and Management Guide for your version, chapter 3, section "Importing AVUSER Schema/Data for a Customer-Supplied Database Restoration/Load". Make sure you do the "Validate Compatibility of the Database Import" steps.  The Guides are:
  6.  After importing, the following environment information will need to be adjusted.  To fix that:
    1. Delete * from T_SERVER_NODES and the new nodes will register themselves.
    2. Create new AFX and remote agent server certificates as required. Ensure AFX and remote agents are configured to communicate with the new cluster.
  7. When all is working in the clustered environment, shutdown the old standalone environment.
  8. If the clustering fails, you can fallback to the standalone environment. Meanwhile, keep the clustered environment "as is" for troubleshooting. 
Notes
Information about clustering in Weblogic and Websphere environments is in the Installation Guide for your version.  Refer section "Clustered Application Server and Oracle RAC Implementation Environments" within the Weblogic and Websphere chapters.

Related Articles

Trending Articles

Don't see what you're looking for?