Server Scalability and
High Availability
March 2015
GO!Enterprise
Permission is granted to make and distribute verbatim copies of this documentation provided the copyright notice and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this documentation under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Disclaimer
Server Scalability and High Availability Guide Scalability and High Availability of GO!Enterprise Server installations i
Contents
Scalability and High Availability of GO!Enterprise Server
installations
1
Scalability and High Availability of
GO!Enterprise Server installations
About This Guide
The purpose of this guide is to help IT personnel to understand the performance capabilities and scalability options of GO!Enterprise Server.
Performance and capacity
The performance and capacity of GO!Enterprise is greatly dependent on the volume of data that needs to be synchronized and on the frequency of the synchronization.
When determining the system requirements for GO!Enterprise Server deployments, the following factors must be considered:
The nature of the GO!Apps that are provided to the users.
The number of active GO!Enterprise users. Active users are considered those who have recently (i.e. within a specified period) used GO!Enterprise services.
The number of devices that are concurrently connected to GO!Enterprise.
For GO!Enterprise Office solutions, active users have a greater impact on performance than concurrent devices because of the data synchronization between the office GO!Apps (e.g. emails, contacts, calendar etc.) and the back-end systems (e.g. MS Exchange Server, MS SharePoint, etc.). Thus, assuming a reasonable number of devices per user (up to 3), the performance and capacity of the deployment is essentially determined only by the number of active users.
The following cases of a typical* GO!Enterprise Office deployment have been successfully tested:
Users (active) Processor RAM HD
250 2 core 1.4GHz (or better) 4 GB (minimum) 150 GB
500 4 core 1.4GHz (or better) 8 GB (minimum) 150 GB
Server Scalability and High Availability Guide Scalability and High Availability of GO!Enterprise Server installations 2
* Assumptions:
No other system or service except GO!Enterprise Server is installed on the same host machine.
Only GO!Enterprise Office is offered through the particular server (no other GO!Apps).
Active users are those who have used GO!Enterprise services within the last 24 hours. The period during which a user is considered active is configurable via the relevant parameter. The minimum period is 24 hours.
For GO!Apps in the context of GO!Enterprise Mobilizer solution, the system specifications required for such deployment are dynamic and highly dependent on the way GO!Apps synchronize data in the background. The above mentioned cases of typical GO!Enterprise Office deployment can be
successfully used to serve GO!Apps which have performance requirements similar to the office GO!Apps, including the data intensive email service.
Scalability and High Availability
Multiple GO!Enterprise Servers can be deployed together in order to support Scalability and High Availability.
A Load Balancer providing IP Stickiness (not Session Stickiness) is used for serving multiple
GO!Enterprise Servers that are all configured to share the same SQL Server and the same File Storage. This type of setup provides for Scalability since more GO!Enterprise Servers can gradually be added as the user base grows. In case only Scalability (and not High Availability) is required, SQL Server and file storage can reside in one of the GO!Enterprise Servers.
For High Availability, clustered SQL Servers and clustered file storage would be used (note that MS SQL EXPRESS does not support clustering).
In a typical environment where an external Firewall controls public access to DMZ and an internal Firewall controls access from DMZ to the internal network infrastructure, the Load Balancer should be deployed in DMZ. The Load Balancer should have a valid certificate and should terminate SSL
requests, while port 443 in the external firewall should be open so that devices can connect to the Load Balancer through a public domain name by sending HTTPS requests.
The Load Balancer receives requests at port 443 (HTPPS), terminates the SSL requests and forwards them through port 80 (HTTP) to the GO!Enterprise Servers.
Option 1 (recommended): Multiple GO!Enterprise Servers are installed within the internal
network
Port 80 should be open at the internal Firewall providing access only between the Load Balancer (in DMZ) and the GO!Enterprise Servers.
For High Availability, multiple SQL Servers (clustered) and Clustered File Storage (e.g. SAN, MS DFS or MS CSV) should exist within the internal network so they can be accessed by the GO!Enterprise Servers.
Option 2: Multiple GO!Enterprise Servers are installed within DMZ
For High Availability, multiple SQL Servers (clustered) and Clustered File Storage (e.g. SAN, MS DFS or MS CSV) should exist within DMZ so they can be accessed by the GO!Enterprise Servers.
Alternatively, Clustered SQL Servers and Clustered Shared File Storage can exist within the internal network but in this case the proper ports must be open at the internal Firewall so that the
GO!Enterprise Servers can have access to them.
Server Scalability and High Availability Guide Scalability and High Availability of GO!Enterprise Server installations 4
Complementing the High Availability solution
The above topologies have two single points of failure. The first one is the core backend system interface (e.g. Web Service Bus) and the second is the Load Balancer.
For a complete High Availability solution:
The core backend system interface should be developed and provided in such way so that it is always available.
Two instances of Load Balancers should exist, accessed through DNS Round Robin.
Typical Hardware Requirements
Typical redundancy scenarios would need at least 2 instances of GO!Enterprise Server and: Clustered SQL Server: 2 instances
CPU Cores: 8 Memory (GB): 30
Storage (GB): 500
Clustered Shared File Storage (SAN, MS DFS or MS CSV)
Storage (GB): 300
GO!Enterprise Server health check monitoring
GO!Enterprise Server provides a health check function so that administrators can verify that the service is up and running by making an http or https request to the following URL:
http://GOES_Server_Name/Admin/f_HealthCheck.aspx
If the service is up, the response will be: HTTP 200 OK
Disaster Recovery Site
To provide for Disaster Recovery (DR), an exact copy (clone) of the production environment must be installed at another remote location.
In order for the Disaster Recovery environment to function properly, a mechanism should be
established so that clustered SQL Servers of both production and DR environments are synchronized. Alternatively, a backup & restore process can be established in order to ensure that the DR
For More Information
Visit our site www.globoplc.com to learn more about GO!Enterprise and GLOBO’s Enterprise Mobility solutions.
About GLOBO plc
As a leading provider of mobile services to the enterprise GLOBO is pioneering a new era in mobilizing business. Its revolutionary products enable businesses to become more competitive by giving staff secure access to critical applications whilst on the go using their mobile phone or a tablet PC. Founded in 1997, the company is listed on the London Stock Exchange (GBO.LN). GLOBO is widely regarded as one of the most innovative companies due to its ongoing investment in research and development.
Contact Information New York
247, West 35th Street
11th Floor Front, New York 10001
Tel.: +1 646 307 1614 London 41, Lothbury EC2R 7HG, U.K. Tel.: +44 (0) 207 378 8828 Athens 67, E. Antistaseos Street 152 31 Halandri, Greece Tel.: +30 21 21 21 7000 Email [email protected] Website www.globoplc.com
