000012606 - How to remove standalone database server?

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000012606
Applies ToRSA Authentication Manager 7.1
Remote database
IssueHow to remove standalone database server?
Cause

RSA Authentication Manager 7.1 SP2 no longer supports standalone database servers.You must remove any standalone database server before you upgrade to SP2.

Resolution

The process to remove a standalone database server requires that your deployment have at least one replica instance installed. You must perform the following tasks to remove the standalone database from your deployment:


? Promoting a Replica Instance to a Primary Instance


? Promoting an RSA RADIUS Replica Server Perform this task if your primary instance contains the RSA RADIUS primary server.


? Reconfiguring CT-KIP After Promoting a Replica Perform this task if you are using CT-KIP in your deployment.


? Removing a Standalone Database Server


? Rebalancing Contact Lists


Promoting a Replica Instance to a Primary Instance

The following section is abridged from the Installation & Configuration Guide and the Administrator?s Guide. It follows the procedures for migrating to a new primary instance and the planned migration to a new primary instance, not the procedures for


performing a disaster recovery.


Note: When promoting a replica instance, RSA recommends promoting your RADIUS server as well. For information on promoting a RADIUS server, see "Promoting an RSA RADIUS Replica Server" section.


What Happens During Replica Instance Promotion


Promoting a replica instance changes the whole replication topology. After you promote a replica instance, the following occurs:


? The replica instance becomes the new primary instance.


? The original primary instance is automatically detached from all replica instances in the deployment. You must manually reattach each replica, one by one, to the new primary instance. For instructions, see Reattach all Replica Instances to the New Primary Instance


? All configuration data referring to the original primary instance is removed from all replica instances in the deployment.


Note: During the promotion process, you cannot perform any administrative functions, such as adding or deleting users.moving a Standalone Database Server


Step 1: Identify the Replica Instance to Be Promoted


Identify which replica instance you are promoting to be the new primary instance.


Consider these factors:


? How much hardware do you need for satisfactory load and performance?


? Which replica instance was updated most recently?


Evaluating Hardware for Load and Performance


After promotion, the new primary instance performs all administrative functions, such


as accumulating all logs from the replica instances. Consider this issue when you


review the memory and disk capacity of the machine that hosts the replica instance


being promoted. Also think about whether you want to add replica instances to reduce


the workload on the new primary instance.


Selecting the Most Current Replica Instance


If you cannot recover the primary instance, consider promoting the replica instance


that was most recently updated when the primary instance was available.


To display the status of each replica instance:


Use the Operations Console to view the replication status report. For information and


instructions, see the Operations Console Help topic "Check Replication Status."


Replica Instance


Name = New York


Primary Instance


Name = Boston1


Replica Instance


Name = Boston2


Replica Instance


Name = San Jose


Multisite Replicated Deploymentving a Standalone Database Server


Step 2: Promote the Selected Replica Instance


Note: Other replica instances in your deployment should be up and running before you begin the procedure to promote a replica instance to the primary instance. If a replica instance is not up and running, you will need to delete it and reattach it after completing the promotion procedure. After you complete this step, all replica instances are fully functional and capture all updates made locally at each instance. However, any updates made at either the replica instances or the new primary instance are not propagated because the instances are not yet connected.


Note: After promotion, the new primary instance is configured to use the same identity sources that it used as a replica instance. Consider whether you need to reconfigure the new primary instance to use different identity sources. The identity sources that the replica instance used might offer lower capacity or performance than the new primary instance needs, because replicas do not send a large number of changes to an identity source. Consider using the same identity source that the original primary instance used, which may have better capacity to handle changes.


To restore the audit log entries from the original primary database server to the


new primary database server:


1. On the original primary database server, stop the replication service.


2. Change directories to RSA_AM_HOME/utils and use the Setup Replication


utility to clean up the site. Type:


rsautil setup-replication --action cleanup-site


3. Back up the log files only.


Log on to the Operation Console on the former primary and back up the log files only. For information and instructions, see the Operations Console Help topic "Back Up Your Database."


4. Copy the backup file generated in step 3 to the new primary database server.


5. Restore the log files only.


Log on to the Operation Console on the new primary and restore the log files only.


For information and instructions, see the Operations Console Help topic "Restore Your Database from a Backup File."


6. Restart the Authentication Manager server at the machine that hosts the new primary instance.


7. Update the contact lists for the new primary.


a. In the Security Console, click Access > Authentication Agents > Authentication Manager Contact List > Automatic Rebalance.


b. Click Rebalance.


Removing a Standalone Database Server


To promote a replica instance to a primary instance in the planned promotion


scenario:


1. On the original primary instance, stop all Authentication Manager Services,


except for the internal database, the database listener, and the Operations Console.


2. On the replica instance being promoted, stop all Authentication Manager


Services, except for the internal database, the database listener, and the Operations


Console.


3. Log on to the Operations Console for the instance you want to promote.


4. Use the Operations Console to promote the replica instance. Use the Planned


method in this scenario.


For information and instructions, see the Operations Console Help topic "Promote


Replica Instances."


5. Back up the database. Log on to the Operation Console on the former primary


instance and perform the backup.


Important: Do not skip this step. You must create a new backup file before


proceeding. Do not use an old backup file.


For information and instructions, see the Operations Console Help topic "Back Up


Your Database."


6. Stop the Operations Console on the former primary instance


7. Copy the generated backup file from the directory location you specified to the


new primary instance.


8. Stop all Authentication Manager Services on the new primary instance.


9. Restart the internal database.


10. Restore the database using the Manage Backups utility.


Important: Do not skip this step. You must restore the database before


reattaching your replicas in the following section, "Step 3: Reattach all


Replica Instances to the New Primary Instance."


a. On the new primary instance, open a new command shell, and change


directories to RSA_AM_HOME/utils.


b. Type:


rsautil manage-backups -a import -f absolute path


where absolute path is the absolute path and filename of the backup file,


including the file extension. For example: C:\backup\filename.dmp.


Important: The user account designated as the owner of Authentication


Manager during installation must have read-write permission to the directory


containing the backup file.


11. On the new primary instance, start the Security Console.emoving a Standalone Database Server


12. If your deployment includes RADIUS, perform the following steps:


a. Access the RADIUS primary server, and change directories to


RSA_AM_HOME/radiusoc/utils: Type:


rsautil manage-secrets -a set


com.rsa.radius.oc.cert.cn.1 cn


where cn is the fully qualified hostname of the current machine.


Important: If the RADIUS server is standalone, on the standalone RADIUS


machine, configure cn1 as the fully qualified hostname of the Authentication


Manager primary instance. You do not need to configure cn2.


b. Type:


rsautil manage-secrets -a set


com.rsa.radius.oc.cert.cn.2 <cn>


where cn is the fully qualified hostname of the Authentication Manager


primary instance.


c. Repeat step a and step b on each RADIUS server in your deployment.


The following figure shows the sample deployment after the replica instance is


promoted.


Pag


Replica Instance Promoted


Old Primary


Instance Name =


Boston1


Replica Instance


Name = New York


Replica Instance


New Primary Name = Boston2


Instance


Name = San Jose


Removing a Standalone Database Server


Step 3: Reattach all Replica Instances to the New Primary Instance


In this step, you need to:


? Reattach all remaining replica instances to the new primary instance.


Note: A replica instance cannot perform any functions while you are


reattaching it. The remaining replica instances continue to function normally.


? Resynchronize data for all instances to ensure identical data at each instance.


This step accomplishes the following tasks:


? The new primary instance is configured to receive data from the replica instance.


? Any changes that occurred on the replica instance since it was detached are


propagated to the new primary.


? The replica instance is reinitialized with data from the new primary instance,


including the changes that the primary instance just received from the replica


instance. You can perform this data synchronization step either automatically or


manually.


? The replica instance is configured to receive data from the primary instance.


Synchronizing Data Between the Replica Instance and the Primary


Instance


When you reattach a replica instance, the replica database server must be


synchronized with the primary database server. Synchronization ensures that both


instances contain the same data. You can perform data synchronization automatically


or manually.


Automatic synchronization. This method accomplishes data synchronization by


establishing the network connection between the two instances and transferring


the data over the network. You can perform this task in one step using the Manage


Replication utility. This method automatically generates a new schema data file


containing a snapshot of data in the primary instance database server.


Manual synchronization. This method requires you to use the Manage


Replication utility to manually generate a schema data file containing a snapshot


of data in the primary instance database server. You copy this file to the tablespace


directory of the replica instance. The utility initializes the replica instance using


the schema data file located in the tablespace directory of the replica instance.


Important: Each time you synchronize manually, you must generate a replication data file. See "Reattach a Replica Instance Using Manual Synchronization" on page 7. The replication data file holds the schema object for administrative and runtime data such as tables. Do not use the same replication data file for multiple replica instances. Each new replica instance copies instance-specific data to the primary instance at the time of attachment. Using a previously used schema data file causes errors in replication. a Standalone Database Server


Reattach a Replica Instance Using Automatic Synchronization


To reattach a replica instance using automatic synchronization:


1. On the primary instance, stop all Authentication Manager services except for the database, the database listener, and the Operations Console.


2. On the replica instance that you are planning to reattach, stop all Authentication Manager services except for the database, the database listener, and the Operations Console.


3. Log on to the Operations Console on the primary instance.


4. Use the Operations Console to reattach replica instances. Select the replica that you want to attach, and select Automatic synchronization. For information and instructions, see the Operations Console Help topic "Attach Replica Instances."


5. At the end of the attach process, click Done to return to the Manage Existing Instances page.


6. Repeat this step for each replica instance. When you are finished, check the status of the attached replicas on the Manage Existing Instances page.


Reattach a Replica Instance Using Manual Synchronization


To reattach a replica instance using manual synchronization:


1. On the primary instance, stop the Security Console.


2. On the replica instance that you are planning to reattach, stop the Security


Console.


3. Log on to the Operations Console on the primary instance.


4. Use the Operations Console to reattach replica instances. Select the replica that


you want to attach, and select Manual synchronization to generate the replication data file.


For information and instructions, see the Operations Console Help topic "Attach Replica Instances."


5. At the end of the attach process, click Done to return to the Manage Existing Instances page.


6. Copy the replication data file (.dmp) to the replica instance tablespace directory in


..\RSAAM\db\oradata\.


Important: For Linux systems, make sure that the schema data file is copied as belonging to the user who installed Authentication Manager.


7. Click Complete the Manual Attach Process. Select the replica to finish the attach process.


8. At the end of the manual attach process, click Done to return to the Manage


Existing Instances page.


9. Repeat steps 2-6 for each replica instance. Standalone Database Server


4. Promoting an RSA RADIUS Replica Server


The procedure described in this section is the planned promotion of a RADIUS replica


server. In a planned promotion, the primary server is online and functioning, but you


want to promote an existing replica.


Multisite Replicated Deployment


Replica New York Attached to New Primary Boston2


Replica Instance


Name=New York


Primary Instance


Name=Boston2


Replica Instance


Name=San Jose


Multisite Replicated Deployment


All Replicas Are Reattached


Replica Instance


Name=New York


Primary Instance


Name=Boston2


Replica Instance


Name=San Jose


Important: Before promoting a replica, make sure that it is synchronized with the


primary. You can do this by forcing replication to the replica. This updates the replica


server with the latest configuration changes.


To promote a replica server when the existing primary server is available:


1. Force replication to the RADIUS replica that you are going to promote so that the


replica has all of the latest configuration changes.


2. Use the Operations Console on the Authentication Manager primary server to


promote the existing RADIUS replica server to be the RADIUS primary server.


For instructions, see the Operations Console Help topic "Promoting a RADIUS


Replica Server."


5. Reconfiguring CT-KIP After Promoting a Replica


When you configured Authentication Manager, you likely configured the following


two URLs necessary for Remote Token-Key Generation (CT-KIP):


Token-Key Generation. This is the URL to invoke the CT-KIP application that


interacts with the Authentication Manager CT-KIP server for remote key


generation.


Service Address. This is the server-side address of the CT-KIP service.


After you promote a replica instance to a primary instance, you must use the Security


Console to modify these URLs to point to the new primary instance. For instructions,


see the Security Console Help topic "Configure Your RSA Authentication Manager


6. Removing RSA Authentication Manager Servers


Remove components in this order:


1. Server nodes


2. Replica database servers


3. Primary database server


For example, if you are removing a replica instance with server nodes, first remove the


server nodes and then the replica database server. The order is important because you must remove server node information from the database server before removing the server node itself. In a replica database server removal, the reference information is removed automatically from the primary database server by the removal program. After removing a replica database server, perform the tasks described in "Rebalancing Contact Lists" g a Standalone Database Server


7. Removing a Standalone Database Server


To remove a standalone database server on Windows:


1. Verify that the Authentication Server is running.


2. Click Start > Control Panel > Add/Remove Programs.


3. On the listing for RSA Authentication Manager, click Remove.


The GUI uninstaller program is displayed on your screen.


4. When prompted, select the components that you want to remove, and click Finish.


To remove a standalone database server on Solaris or Linux:


1. Verify that the Authentication Server is running.


2. Change directories to RSA_AM_HOME/uninstall.


3. Type:


uninstall.sh


The GUI removal program is displayed on your screen.


4. When prompted, select the components that you want to remove, and click Finish.


5. The removal program runs and then prompts you to run an important script as root


user. Run this script to finish removing Authentication Manager.


6. Restart the machine.


8. Rebalancing Contact Lists


After you remove the replica database server and any server nodes from the replica


instance, rebalance the contact lists in the primary instance RSA Security Console.


This removes the references to the removed replica instances.


To automatically update your contact lists:


1. Click Access > Authentication Agents > Authentication Manager Contact


List > Automatic Rebalance.


2. Click Rebalance.


 

Notes

The current documentation can be found on RSA SecurCare Online, note that the documentation set has been revised with the release of service pack 4 updated on Nov 14th 2011.  If an RSA Authentication Manager system is running an earlier version of software you should still use this documentation set and then upgrade your system to service pack 4 where required.


RSA Authentication Manager 7.1 SP4 Release Notes


RSA Authentication Manager 7.1 Administrator?s Guide


RSA Authentication Manager 7.1 Planning Guide


RSA Authentication Manager 7.1 Performance and Scalability Guide


RSA Authentication Manager 7.1 Installation and Configuration Guide


RSA Authentication Manager 7.1 Migration Guide


RSA Authentication Manager 7.1 Help Desk Administrator?s Guide


RSA Authentication Manager 7.1 Getting Started


RSA Authentication Manager 7.1 RADIUS Reference Guide


RSA Authentication Manager 7.1 SP4 Factory Reset Release Notes


RSA Authentication Manager 7.1 SP4 Full Installation Download Verification Guide


RSA Authentication Manager 7.1 Security Best Practices Guide


Hardware Token Replacement Best Practices Guide


RSA Authentication Manager 7.1 Microsoft Active Directory Integration Guide


RSA Authentication Manager 7.1 Basic Exercises


RSA Authentication Manager 7.1 Sample Migration


Volunteer Product Accessibility Template


Web Content Accessibility Guidelines

Legacy Article IDa48991

Attachments

    Outcomes