# Secondary Server High Availability Model - PostgreSQL - Build 8310 and Below ## Secondary Server Model using PostgreSQL Database > **Caution** > > - The PostgreSQL High Availability model using Rubyrep for database replication in earlier setups has reached its [end-of-life](https://www.manageengine.com/privileged-access-management/eol-rubyrep.html) and is no longer maintained. Continuing to rely on Rubyrep may expose your environment to security risks and upgrade issues. > - It is mandatory to use the new High Availability model based on PostgreSQL’s native streaming replication for builds 8400 and above. For more details, refer to this [new PostgreSQL High Availability](https://www.manageengine.com/privileged-access-management/help/high-availability-postgresql.html) document. > - Procedure applies to builds 8310 and below. PAM360's secondary server model provides a foundational approach to tackle downtime and ensure continual access to privileged accounts. By deploying a PAM360 instance on a secondary server, organizations establish a solution that facilitates smooth transitions in the event of service interruptions on the primary server. > **Additional Detail** > > The High Availability configuration using the secondary server model is exclusively compatible with the PostgreSQL database bundled with the PAM360 product. Initially, a PAM360 instance is installed on a server and connected to a primary database, serving as the primary PAM360 server. Subsequently, another instance is established on a separate server, linked to a new secondary database, serving as the secondary server. In the event of the primary server's inactivity, operations are seamlessly transferred to the secondary server. Once the primary server resumes operation, database synchronization occurs using the merge replication methodology, restoring it as the primary server. 1. [How Does the Secondary Server Model Works?](https://www.manageengine.com/privileged-access-management/help/high-availability-pgsql.html#How_Does_the_Secondary_Server_Model_Work) 2. [Secondary Server Architecture in PAM360](https://www.manageengine.com/privileged-access-management/help/high-availability-pgsql.html#Secondary_Server_Architecture) 3. [Network Scenarios for Secondary Server](https://www.manageengine.com/privileged-access-management/help/high-availability-pgsql.html#Secondary_Servers_Network_Scenarios) 4. [Setting up High Availability in the Server Running with PostgreSQL](https://www.manageengine.com/privileged-access-management/help/high-availability-pgsql.html#Setting_up_Secondary_Server_Model_with_PostgreSQL) 5. [Monitoring Secondary Server Model](https://www.manageengine.com/privileged-access-management/help/high-availability-pgsql.html#Monitoring_Secondary_Server_Model) ## 1. How Does the Secondary Server Model Work? In PAM360, the secondary server model ensures redundancy of both servers and database instances. Key characteristics of the model include: - **Primary and Secondary Instances**: The primary instance handles read/write access for all users. The secondary instance remains synchronized with the primary instance. - **Data Synchronization**: Data between the primary and secondary databases is continuously synchronized via server replication over a secure, encrypted channel. - **Failover**: When the primary server becomes unavailable, the secondary server automatically provides read/write access to users (except for password reset functionality) until the primary server is back online. Once the primary server is restored, any changes made to the secondary database during the downtime are automatically synchronized with the primary database. ## 2. Secondary Server Architecture in PAM360 The architecture consists of redundant PAM360 servers - one primary server and one secondary server. The secondary server is kept in synchronization with the primary server through server replication. ![high-availability-pgsql](https://cdn.manageengine.com/sites/meweb/images/privileged-access-management/help/high-availability-pgsql.webp) ## 3. Network Scenarios for Secondary Servers The secondary server architecture in PAM360 supports two network scenarios: | Scenario 1 | | |---|---| | **Primary and Secondary Servers on the Same Network** | In this scenario, both the primary and secondary servers are hosted within the same network. If the primary server fails, the secondary server assumes read/write responsibility, except for password resets. | | **Example** | Both servers are deployed in the same location. If the primary server goes down, users can still retrieve passwords and perform relevant operations from the secondary server within the same network. Once the primary server becomes active, the data in both the servers' database will be synchronized. | | Scenario 2 | | |---|---| | **Primary and Secondary Servers on Different Networks** | In this scenario, the primary and secondary servers are hosted in different geographical locations, connected via a WAN link. If the WAN link fails, the secondary server can continue to serve users in its network by providing read/write access (except password resets). | | **Example** | If the primary server is located in location A and the secondary server in location B, and the WAN link between them fails, both servers will operate independently. Users in location B will access the secondary server until the link is restored, after which both servers' database will synchronize. | ### 3.1 Audit Trail Management In both scenarios, audit trails are recorded as usual. If users access the secondary server during a primary server failure, actions such as password retrieval, login, and logout will be logged on the secondary server. Once network connectivity is restored, the audit data between the primary and secondary servers is synchronized. > **Caution** > > Make sure that the ports **3456** (database port) and **8282** (web server port) are open between the primary and the secondary application servers. ## 4. Setting up the Secondary Server Model for PAM360 with PostgreSQL Database To establish High Availability for a server running PostgreSQL in PAM360, follow these essential steps: 1. Use your existing PAM360 installation as the primary server. 2. Install a new instance of PAM360 on a separate machine to act as the secondary server. During installation, select **Configure this server as High Availability Secondary server**. Upon completing the installation, do not start the PAM360 service. 3. Ensure both the primary and secondary servers, as well as the PostgreSQL process for PAM360, are not running. 4. Open the command prompt and navigate to the `/bin` folder and execute the following appropriate command depending on your operating system: **Windows:** ```bat HASetup.bat ``` **Linux:** ```bash sh HASetup.sh ``` Replace `` and `` with the fully qualified domain names of the primary and secondary servers. For example: ```bat HASetup.bat primary-server.zohocorpin.com secondary-server.zohocorpin.com ``` ```bash sh HASetup.sh primary-server.zohocorpin.com secondary-server.zohocorpin.com ``` 5. Running the script will generate a replication package named **HAPack.zip** in the `/replication` folder. This package contains the database package required for the secondary server. 6. Start the PAM360 primary server once the replication package has been created. 7. Copy **HAPack.zip** and place it on the machine where the PAM360 secondary server is installed. 8. Move **HAPack.zip** into the `` on the secondary server and unzip it. Ensure you extract files directly under `` to overwrite the existing data files properly. 9. Upon extracting **HAPack.zip** on the secondary server, navigate to the `conf` folder, and open the **manage_key.conf** file and specify the full path to **pam360_key.key** ([encryption master key](https://www.manageengine.com/privileged-access-management/help/get-started.html#Managing_PAM360_Encryption_Key)). > **Additional Detail** > > PAM360 requires the **pam360_key.key** file to be accessible with its full path when it starts up every time. After a successful start-up, it does not need the key anymore so the device with the key file can be taken offline. > **Caution** > > From PAM360 build 8000 onwards, it is mandatory to retain the **pam360_key.key** file in the file path specified in the **manage_key.conf** file for a seamless operation. PAM360 continuously accesses this file to ensure uninterrupted operation. If the **pam360_key.key** file is not available in the specified path, the service may not startup or certain features such as database backup will not function. The secondary server configuration for HA is now complete. Start the PAM360 secondary server followed by the primary server to activate the HA setup. > **Caution** > > By default, PAM360 uses a self-signed SSL certificate. If you have replaced this with a certificate from an internal CA (other than well-known CAs like [Verisign](http://verisign.com), [Thawte](http://www.thawte.com), [RapidSSL](http://www.rapidssl.com), etc) on the secondary server, follow these extra steps to add the certificate to the primary server’s certificate store: > > i. Stop the primary server if it is running. > ii. Copy the secondary server's SSL certificate and paste it in the `/bin` folder. > iii. From the `/bin` folder, open the command prompt and execute the following command: > > ```bat > importCert.bat > ``` > > Replace `` with the path of the secondary server’s certificate. For example: > > ```bat > importCert.bat D:\Builds\PAM\7200\bin\ha-server.crt > ``` > > This command adds the server certificate to the PAM360 certificate store. > iv. Restart the primary server to apply the SSL certificate configuration. Your HA configuration for PAM360 with PostgreSQL is now fully set up and secured. ## 5. Monitoring Secondary Server Model PAM360 supports monitoring the high availability of your servers to anticipate failures, thereby avoiding costly downtimes. Refer to [this help document](https://www.manageengine.com/privileged-access-management/help/monitor_high_availability.html) to learn more about monitoring HA in detail.