Last reviewed: 2022-07-06 |
Please note that this Knowledge Base article has been created only for 2023.1 Please note that the information in this Knowledge Base has not undergone extensive testing or verification by our Engineering team. While this article offers valuable insights, it may not guarantee flawless solutions for your specific Identity Server environment and configuration. Please contact your Ubisecure partner and/or Ubisecure Support team to obtain more information. |
The idea is to do node by node upgrade for SSO and CID and have minimal service break during the upgrade.
For this kind of upgrade, you will need to route production traffic only to SSO node 1 and CID node 1, when you are upgrading SSO Node 2 and CID Node 2.
Once SSO Node 2 and CID Node 2 are upgraded then route production traffic to upgraded nodes. After this start upgrading SSO Node1 and CID Node1 .
Let's use letters A for Active and P for Passive to avoid confusion in our current setup.
SSO 1 = SSO A | SSO 2 = SSO P |
CID Master = CID A | CID Slave = CID P |
1) Traffic Switchover: Make sure all traffic is going only to SSO Node A And CID Node A (old master)
2) SSO Node P upgrade :
Kindly follow all the steps mentioned below :
You can refer to this page for details information but you need to consider SSO node1 in this document as SSO P for you. So perform all the steps for SSO Node 1 mentioned in this document (until step 6), on your SSO Node P. - Clustered upgrade on Windows - SSO
Once SSO P is upgraded, move to CID P (slave) upgrade.
3) CID Node P upgrade :
Follow the steps in order. Issue all commands in the Windows command prompt using the Administrator user account.
a. Stop ubiloginserver service in SSO Node P and stop wildfly sevice in CID Node P.
b. It is a good idea to take periodic backups of running installations.
You should do this regularly but for the upgrade process we advise you in this step to move the existing installation to a specific location custo
merid-old
which is used in this document.
cd "%PROGRAMFILES%\Ubisecure" move customerid customerid-old |
c. Perform on Ubisecure CustomerID P Node (slave) :
%PROGRAMFILES%\Ubisecure\customerid
must be empty before doing this step, Deployment template extraction on Windows - CustomerID%PROGRAMFILES%\Ubisecure\customerid-old\application\win32.config
.In the new installation the win32.config
file is located further down the similar path in the config
sub-folder and must first be copied to the application folder.
cd /D "%PROGRAMFILES%\Ubisecure\customerid\application" copy config\win32.config |
The values must be copied carefully from the previous installation as the configuration options may have changed. You should copy only those values that have the same keys on both old and new win32.config
files. Refer to page Setup template on Windows - CustomerID for more information about the current configuration options.
NOTE: If you have made configuration changes to any of the win32.config
parameters directly in eidm2.properties
file after previously running the setup.cmd
ensure that these changes are included in the new win32.config
file. For example, if you have changed the REST credentials in eidm2.properties
file, make sure the same values are now present in the win32.config
file.
5. Run the setup script.
cd /D "%PROGRAMFILES%\Ubisecure\customerid\application" setup.cmd |
%WILDFLY_HOME%\domain\configuration\keystore.pfx
) is registered to WildFly in the next step - master node WildFly configuration. See Database Changes.
10. Create JDBC data source to WildFly. See instructions from Two node JDBC data source creation on Windows - CustomerID
11. Create a Mail Session configuration for WildFly. See instructions from Two node mail session creation on Windows - CustomerID
12. Configure logging for CustomerID. See instructions from Two node logging configuration on Windows - CustomerID
13. Register "customerid.home" system property to WildFly. See instructions from WildFly system property registration on Windows - CustomerID
d. Perform on Ubisecure SSO Node P :
e. Perform on the CustomerID new Master Node (Node P) :
f. Perform on Ubisecure SSO Node P:
1.Restart Ubisecure SSO. See instructions from Installation related SSO restart on Windows - CustomerID.
// We are working on exact instructions to move data in ADLDS from one node to another, below are high level actions need to be taken in this part
1) SSO Node A Upgrade :
Kindly follow all the steps mentioned below :
Detailed steps are here in this document. You need to consider SSO node 2 in this document as SSO A for you. So perform all the steps for SSO Node 2 mentioned in this document on your Node A: Clustered upgrade on Windows - SSO (From Step 7 )
Once SSO node A is up and running with upgraded software, move to CID Node A upgrade.
2) CID Node A Upgrade :
Perform the next steps to upgrade CID node A which is the old master node and after upgrade, it will be a new slave node.
a. Perform on Ubisecure SSO Node A:
Note : After this step you can start Ubiloginserver service in SSO Node A to restore SSO HA setup.
b. Perform on CustomerID Node A :
%WILDFLY_HOME%\domain\configuration\keystore.pfx
) is registered to WildFly in the next step - slave node WildFly configuration. Note- If cert keys are not changing, generation of new cert on slave node can be skipped and keystore.pfx can be copied from master node to slave node.At least under slow connections the script (config-wildfly-domain-slave.cmd) may show error message "Failed to establish connection in 6044ms" when reloading configurations. If you see it in the end-of-the script it is a good idea to verify your slave node Wildfly is running properly and can access the master node. |
6. Restart Ubisecure CustomerID. See instructions from Restart on Windows - CustomerID
In case, Wildfly take a long time to stop and fails in Stopping state you need to perform step 'Fix Slave Node shutdown parameters' from Two node WildFly installation on Windows - CustomerID |
c. Perform on Ubisecure SSO Node A:
d. Finalize Upgrade :
Kindly verify customerid_diag.log file to see if both CID nodes are running and logs are getting printed for both CID nodes in logs.
Ensure to check memory allocation for tomcat and wildfly from the old environment and to apply that to any new environment: To check memory allocated to Wildfly: Goto
To check memory allocated for tomcat: Goto
|