Architecture in Load Balancer
The Presentation tier
Liferay Portal 6.1 supports various devices, and we won't need any special component to render content for mobile devices. Liferay Portal can even detect specific devices and respond with device-specific content. Liferay also supports creating responsive web design using its UI framework called AlloyUI.
The Networking tier
Every request will pass through Firewall. Firewall will filter unsecure requests. All valid user requests will be passed to the Hardware Load Balancer. The hardware load balancer is a hardware appliance which distributes loads between multiple web servers.
In case a of failure of any web server, the hardware load balancer diverts traffic to working web servers.
The Web tier
The Web tier includes a series of Apache Web Servers.
Each Web Server is connected with each Application Server. The Web Server acts as a Software Load Balancer for Application Servers.
The Apache Web Server connects with the Liferay Portal application server using mod_jk, mod_proxy, or mod_proxy_ajp connectors.
The Application tier
The Application tier includes one or more Liferay Portal application servers. Liferay Portal can be deployed on many different application servers.
Application servers are connected with web servers using the AJP protocol or the HTTP protocol. Servers. Each Application Server is connected with other Application Servers to replicate the session information, and cache and/ or search indexes. Each Application Server is connected to dedicated Database Servers and Active Directory Servers.
The Database Repository tier
The Liferay Portal server connects to the Database Repository tier. For production systems, it is advisable to set up multiple database instances with replication. Such a setup ensures high availability of Database Servers.
The Search Repository tier
Liferay Portal comes with an embedded Apache Lucene search engine. The Lucene search engine stores search indexes in a filesystem. Each Application Server has its own search index repository in the Search Repository tier. Search engine repositories can be synchronized by the Liferay Portal server using the Cluster Link feature.
The Media Repository tier
Liferay Portal comes with a media repository, which includes a document library, image gallery, and so on. Liferay Portal provides different options to store the media repository content. By default, Liferay stores the media repository content on a filesystem. It can be configured to store the media repository content on a database, Java Content Repository (JCR), CMIS-based repository, or Amazon S3.
To avoid issues related to concurrent access on a centralized filesystem, it is recommended to use Storage Area Network (SAN) as the centralized filesystem to store the Media Library content.
The Active Directory tier
Liferay comes with its own user repository. Liferay maintains its user repository in a database. But for production systems, it is recommended to integrate the user repository with identity management systems. The reference architecture refers using the Active Directory server. Liferay Portal connects with the Active Directory Server using the LDAP protocol.
As shown in the architecture diagram, horizontal scaling is used for both the Web tier and the Application tier.
The reference architecture divides the load of the system to multiple tiers.
All application requests will be served by the clustered Application Server tier. The Application Server connects with the Database tier which is again clustered to ensure the load is distributed.
High availability and fault tolerance
The reference architecture ensures that the most important tiers of the solutions are clustered and load balanced to ensure that the system is highly available and fault tolerant.
Web tier, Application tier, and Database tier are clustered, which means that if any nodes from these tiers go down, the system will still respond to user requests.
The reference architecture places Firewall in front of the Hardware Load Balancer, which ensures that all the security threats are filtered. The architecture supports configuring SSL-based access.
Deployment sizing approach
How many concurrent users will log in at the same time?
Login is the most resource-consuming use case Liferay Portal.
What is the number of concurrent users accessing the document management functionality including login?
We need to establish the exact number of application servers that we will need to handle a specific number of concurrent users.
Apache Web Server
1 x Intel Core 2 Duo E6405 2.13 GHz CPU, 2 MB L2 cache (2 cores in total) 4 GB memory, 1 x 146 GB 7.2k RPM IDE
Liferay Portal Application Server
2 x Intel Core 2 Quad X5677 3.46 GHz CPU, 12 MB L2 cache (8 cores and 16 threads) 16 GB memory, 2 x 146 GB 10k RPM SCSI
2 x Intel Core 2 Quad X5677 3.46 GHz CPU, 12 MB L2 cache (8 cores and 16 threads) 16 GB memory, 4 x 146 GB 15k RPM SCSI
One Liferay Portal application server can handle 6,300 concurrent login requests. So to handle 15,000 concurrent login requests, we will need three Liferay Portal application servers. Generally, the load on the web server is less than 50 percent of application servers. we can derive the number of web servers as half of the application servers. So in our case, we will need two web servers (3 application servers/ 2). For the database server as per our reference architecture, it is recommended to have a master-slave database server. This calculation is valid for similar hardware configurations as it was used in the benchmark performance test. We need to use the same hardware configuration for the application server, web server, and database servers.