Server Components
Software Components
No, | Component | Details | Supported Version |
|---|---|---|---|
1 | Database | Microsoft SQL Server. | 2017, 2019 Standard or Enterprise |
2 | Elastic Search | Distributed, RESTful search and analytics engine for providing advanced search capabilities across large datasets. | V7.15.2+ |
3 | Redis | Redis is an open-source, in-memory data structure store, used as a database, cache and message broker, for high-performance data caching. | v4.0.14+ |
4 | RabbitMQ | Lightweight, open-source message broker. | V3.9.1+ |
5 | Docker | Containers-as-a-Service platform for IT that manages and secures diverse applications across disparate infrastructure, both on-premises and in the cloud. | Latest support OS version |
6 | Caddy Webserver | Caddy web server is an open-source, HTTP/2-enabled web server written in Go. | 2.0 |
7 | NFS | Network File Share is used to share persistent files such as photos, reports, and email templates between the other components. | Latest support OS version |
Note
The latest support OS version requires the latest version of the application that is currently supported by the OS being installed and used.
Virtual Machine and Operating System Components
No. | Component | Details |
|---|---|---|
1 | Virtualization System | VMWare ESXi |
2 | Database Server Operating System¹ | Microsoft Windows Server 2016, Microsoft Windows Server 2019, Red Hat Enterprise Linux (RHEL) 7.3 – 7.8, 8.0 and 8.2, Ubuntu 18.04 and 20.04 LTS |
3 | Operating System for All Other Components | Ubuntu 18.04 and 20.04 LTS, Red Hat Enterprise Linux 7.9 2 and 8.3 |
¹ Database operating system version must support the version of SQL Server being used.
² Red Hat Enterprise Linux requires the use of Docker Enterprise Edition
Note
RHEL (Red Hat Enterprise Linux) must always be installed using the minimal install option.
Physical Server Architecture
The physical server architecture will depend on the size of the overall solution and the high availability requirements of the organization.
Server Resources
Note
These are provided as rough, high-level guidelines and may need to be adjusted based on the use of the individual system.
Small, medium, and large solutions are categorized by the following metrics:
Small: <10,000 IDs (employees, contractors, etc.). Less than 2,000 readers managed in total. This is typically used only for Symmetry Guest deployments.
Medium: 10,000 – 40,000 IDs (employees, contractors, etc.). 2,000 – 7,000 readers managed in total.
Large: > 40,000 IDs (employees, contractors, etc.). > 7,000 readers managed in total. High Availability.
Component | Small | Medium | Large |
|---|---|---|---|
CPU | 12 Cores (Per Server) | 12 Cores (Per Server) | 12+ Cores (Per Server) |
RAM | 96 GB (Per Server) | 128 GB (Per Server) | 96GB – 144GB (Per Server) |
HDD | 2 TB 15K SAS Minimum (SSD Preferred) | 1.5 TB 15K SAS Minimum (SSD Preferred) | 2.3TB - 3TB 15K SAS Minimum (SSD Preferred).³ |
Network | Gigabit Ethernet | Gigabit Ethernet | Gigabit Ethernet |
OS | Operating system: Windows Server or Linux OS with VMware ESXi installed. The bare-imaged Ubuntu VMs must be built and available on the physical servers. For more details, review: https://ubuntu.com/download/server |
³ Available drive space is listed; however, it is assumed that consideration will be given to multiple drives, throughput, and redundancy.
Note
The specifications provided above are per physical server. Review the description provided above regarding the number of physical servers required for the solution.
Note
The specifications provided above are to be used as a rough guide only. Additional scoping meetings are required to specify the exact server requirements.
Best Practices
On the Docker server(s), a separate partition should be created for the /var/lib/docker mount point. This will prevent the possibility of Docker and its ability to run if this folder fills up due to the number of Docker images.
Server Configuration Examples
Note
If required, please contact AMAG Technical Support for more details regarding requirements for server configuration.
The server configurations presented below (in the following section) are an example of what the server configuration may look like in a production environment.
Small System
Physical Server 1 (Application/backend)  | Physical Server 2 (SQL Server Only) |
|---|---|
Physical Hardware: CPU: 10 Cores RAM: 64GB Storage: 2TB (SSD Drive recommended for improved performance) | Physical Hardware: CPU: 2 Cores RAM: 32GB Storage: 500GB (SSD Drive recommended for improved performance) |
VM Server 1: Runs everything except SQL CPUs: 10 cores, RAM:64 GB, Storage: 1.5 TB | VM Server 2 (SQL) CPUs: 2 Cores RAM: 32 GB Storage: 300 GB |
Medium System
Physical Server |
|---|
Physical Hardware: CPU: 14 Cores RAM: 140 GB Storage: 1.75 TB (SSD Drive recommended for improved performance) |
VM Server 1: SQL Server CPUs: 4 Cores RAM: 64 GB minimum Storage: 500 GB minimum |
VM Server 2: Elastic Search CPUs: 2 Cores RAM: 16 GB minimum Storage: 300 GB minimum |
VM Server 3: Redis CPUs: 2 Cores RAM: 12 GB minimum Storage: 200 GB minimum |
VM Server 4: Docker Node CPUs: 2 Cores RAM: 24 GB minimum Storage: 250 GB minimum |
VM Server 5: RabbitMQ CPUs: 2 Cores RAM: 12 GB minimum Storage: 250 GB minimum |
VM Server 6: NFS CPUs: 2 Cores RAM: 12 GB minimum Storage: 250 GB minimum |
Large System
Physical Server #1 | Physical Server #2 | Physical Server #3 |
|---|---|---|
Physical Hardware: CPU: 12 Cores RAM: 96 GB Storage: 2.25TB (SSD Drive recommended for improved performance) | Physical Hardware: CPU: 14 Cores RAM: 160 GB Storage: 3.25 TB (SSD Drive recommended for improved performance) | Physical Hardware: CPU: 14 Cores RAM: 112 GB Storage: 2.75 TB (SSD Drive recommended for improved performance) |
VM Server 1: Elastic Search #1 CPUs: 4 Cores RAM: 32 GB Storage: 650 GB | VM Server 1: Elastic Search #2 CPUs: 4 Cores RAM: 32 GB Storage: 650 GB | VM Server 1: Elastic Search #3 CPUs: 4 Cores RAM: 32 GB Storage: 650 GB |
VM Server 2: Redis #1 CPUs: 2 Cores RAM: 16 GB Storage: 250 GB | VM Server 2: Redis #2 CPUs: 2 Cores RAM: 16 GB Storage: 250 GB | VM Server 2: Redis #3 CPUs: 2 Cores RAM: 16 GB Storage: 250 GB |
VM Server 3: Docker Node #1 CPUs: 4 Cores RAM: 32 GB Storage: 600 GB | VM Server 3: Docker Node #2 CPUs: 4 Cores RAM: 32 GB Storage: 600 GB | VM Server 3: Docker Node #3 CPUs: 4 Cores RAM: 32 GB Storage: 600 GB |
VM Server 4: RabbitMQ #1 CPUs: 2 Cores RAM: 16 GB Storage: 750 GB | VM Server 4: RabbitMQ #2 CPUs: 2 Cores RAM: 16 GB Storage: 750 GB | VM Server 4: RabbitMQ #3 CPUs: 2 Cores RAM: 16 GB Storage: 750 GB |
| VM Server 5: SQL Server¹ CPUs: 2 Cores RAM: 64 GB Storage: 1 TB | VM Server 5: NFS² CPUs: 2 Cores RAM: 16 GB Storage: 500 GB |
¹ A SQL Instance is required for Symmetry CONNECT/GUEST. This can be hosted in a VM with the application itself or on a separate SQL Farm. Values entered here show only the recommendation of AMAG Technology.
² Symmetry CONNECT/GUEST requires access to an NFS Server to store key components such as themes, pictures, and email templates used. This can be hosted on a VM with the application or separately.
High Availability
CONNECT / GUEST Application
The Large Systems architecture is used to achieve high availability. For this, the following are required:
There needs to be more than one physical server to host CONNECT/Guest. Having a single physical server would result in a single point of failure.
Elasticsearch needs a minimum of 3 instances to provide a quorum.
RabbitMQ needs a minimum of 3 instances (Cluster).
Redis needs a minimum of 2 instances (Master/Slave). 3 instances are recommended to provide a quorum.
SQL Server
SQL Server can be clustered using Microsoft Failover Cluster Instance, which uses Windows Server Failover Clustering (WSFC) functionality to provide high availability via redundancy at the server instance level. This model relies on two servers and some form of shared storage and results in a zero data loss solution. When an issue with one node is encountered, the entire instance, including the database, jobs, etc., will move to the other node.
Figure 1: Failover cluster instance
In addition, the CONNECT/Guest database can be hosted on a customer’s existing SQL cluster if available.