1 Setting Up Multi Node (High Availability Architecture)

This topic describes about the multi node setup (High Availability Architecture).

Configuration Server Related Changes

The below changes are to be made to the PROPERTIES table specified by the configuration server.

For the Discovery Server:

PLATO Discovery Service must have an entry for its entire peer PLATO Discovery Services configured by eureka.client.serviceUrl.defaultZone. It contains a comma-separated list of all Peer PLATO Discovery Services.

Additionally, to enable the peer awareness mode for PLATO Discovery Service, we should set the eureka.client.register-with-eureka to true.

Table 1-1 Application Parameters - Discovery Server

ID	APPLICATION	PROFILE	LABEL	KEY	VALUE
1	plato-discovery- service	jdbc	jdbc	eureka.client.serviceUrl.defaultZon	http://<IP of the server where the first instance of PLATO Discovery Service is running>:<PORT where the first instance of PLATO Discovery Service is running>/plato- discovery-service/eureka http://<IP of the server where the second instance of PLATO Discovery Service is running>:<PORT where the second instance of PLATO Discovery Service is running>/plato- discovery-service/eureka
2	plato-discovery- service	jdbc	jdbc	eureka.client.register-with-eureka	true
3	plato-discovery- service	jdbc	jdbc	server.port	<< PORT Number where the PLATO Discovery Service is running >>

For the Individual Services:

Each service must have an entry for all PLATO Discovery Services configured by eureka.client.serviceUrl.defaultZone. It contains a comma-separated list of all PLATO Discovery Services.

Table 1-2 Application Parameters - Individual Services

ID	APPLICATION	PROFILE	LABEL	KEY	VALUE
1	<<service-name>>	jdbc	jdbc	eureka.client.serviceUrl.defaultZone	http://<IP of the server where the first instance of PLATO Discovery Service is running>:<PORT where the first instance of PLATO Discovery Service is running>/plato- discovery- service/eureka http://<IP of the server where the second instance of PLATO Discovery Service is running>:<PORT where the second instance of PLATO Discovery Service is running>/ plato-discovery-service/eureka

Plato UI Configuration Server Related Changes

For each product registered in PRODUCT_SERVICES_ENV_LEDGER, the user must change the URL to indicate the PLATO API gateway service.

Table 1-3 Load Balancer - URL

ID	PRODUCT_NAME	URL
1	<<PRODUCT NAME>>	<< HTTP URL OF THE LOAD BALANCER >>

setDomainEnv.sh Related Changes

For all the Micro Services

Individual microservices should now access the PLATO Config Service through the Load Balancer URI. That is, the property is configured on server runtime through the property plato.services.config.uri.

The plato.services.config.uri must point to the URI of the load balancer. The format of the same would be as follows:

-Dplato.services.config.uri=http://<< IP OF THE LOAD BALANCER >>:
<< PORT OF THE LOAD BALANCER >>

For the UI APPSHELL

UI APPShell should now access the API Gateway Router Service through the Load balancer URI. That is, the property is configured in the server runtime . For example, Dapigateway.url.

The apigateway.url must point to the host and port of the load balancer. The format of the same would be as follows:

-Dapigateway.url=http://<< IP OF THE LOAD BALANCER >>:<< PORT OF THE LOAD BALANCER >>

To install the services of Oracle Banking Microservices Architecture in more than two nodes, it is not possible to maintain the value of the eureka URL in the properties table due to the size restriction. In such cases, remove the following key from the properties table and add in the setuseroverrides.sh file.

-Deureka.client.serviceUrl.defaultZone

Requirement of Load Balancers

Load balancers are required for the PLATO API GATEWAY Service, PLATO Configuration Service, and PLATO UI APP SHELL.

PLATO API Gateway Router Service

PLATO API Gateway Router Service acts as a single point of entry for UI and External Systems to access the underlying services. This service will route requests to respective services via PLATO API GATEWAY Service. In a multi node deployment where multiple PLATO API Gateway Router Services are deployed, we would need a single URI for accessing the multi node deployments of the PLATO API Gateway Router Services. This Load Balancer would help us to achieve that functionality.

PLATO Configuration Service

All domain services access the PLATO Configuration Service to retrieve their configurations. In a multi-node deployment where multiple PLATO Configuration Services are deployed, the user need a single URI to access multiple-node deployments of PLATO Configuration Services. This Load Balancer helps us to achieve that functionality.

PLATO UI APP SHELL

PLATO UI App Shell acts as a single user interface entry point for users. In multi-node deployment, where multiple instances of PLATO UI APP SHELL are deployed, users need a single URI to access the multi-node extensions of the PLATO UI APP SHELL. The Load Balancer setup helps to achieve this.

In addition to the App Shell, the UI of the application is serviced by additional UI Component Server applications. These are also for SMS, CMC, MOC, and related product domain. All of these UI component server applications must be deployed in the same managed server, where the PLATO UI APP SHELL war is deployed.

If the deployment is in a cluster with more than one managed server for UI applications, all the UI applications must be deployed in the clustered managed servers, and an appropriate load balancer setup must be done for all the UI applications.