On-Premise Deployment
Covered by this topic
Change Log
VERSION | DATE | AUTHOR | CHANGE |
1.0 | 06/20/2017 | DWJ | Initial Version |
1.1 | 09/05/2017 | DWJ | Changed RHEL/CentOS 6 to 7 |
1.2 | 09/05/2017 | DWJ | Remove Render Server - this is now done by the application |
1.3 | 09/06/2017 | DWJ | Changed MariaDB 5.5 to MariaDB 10.2.8 |
Objective
This document outlines the minimum recommended hardware configuration for deployment of Enterprise Health either on dedicated hardware or within a virtualized environment.
Confidentiality
All information supplied in this document by Enterprise Health is to be considered company confidential. This document (whether in electronic or print format) should only be distributed to the minimum number of individuals possible, and is subject to the restrictions imposed by the executed Non-Disclosure Agreement (NDA) and or contract agreement.
Assumptions
The following critical infrastructure items are assumed to be reliable, redundant and well managed by the hosting organization when considering self-hosting.
- Power
- Cooling
- Networking
- Security, physical and cyber
This document also assumes the hosting organization has the technical resources to maintain and support the services that will be deployed within the self-hosting environment.
Prerequisites
During the installation and configuration period, all instances must have access to the internet for package management and installation. If this install is not an OVA install, then EH engineers must have root level access to the instance during installation and configuration. This elevated security is only during the installation and configuration period.
Services
Enterprise Health deploys its applications using Enterprise-level open source software. Minimally required services in the hosting environment are as follows:
- Linux, Red Hat® Enterprise Linux 7 or CentOS 7
- Web Services
Enterprise Health System * Local File System * MariaDB 10.2.8 or higher * memcached 1.4.4 or higher
State Diagram of Services
Environments
Typical standalone deployments include three environments to support a Deployment Life Cycle (DLC) for application patches, upgrades and configuration changes:
- Development
- QA
- Production
Multi-tenant
Enterprise Health has the ability to run multiple, logically isolated instances of the Enterprise Health System on a single server or cluster. A URL for each instance (aka handle) uniquely identifies each instance and provides direct and secure access. This type of deployment is useful for Development and QA environments.
Infrastructure
The Enterprise Health application requires an x86_64 architecture and can be deployed on bare metal hardware or within a virtualized shared or dedicated environment. The balance of this document will focus on deployment within a virtualized environment and includes minimal hardware requirements.
Deployment Methodologies
There are three typical deployment footprints:
- All-in-one
- Dedicated DB
- High Availability / Horizontal Scalability
All-in-one
All the required services run within a single server. This approach is best utilized in small (~50 concurrent users) deployments or for sandbox development use-cases. The “all-in-one” strategy for production is best when a virtualized environment is available for scaling and redundancy underneath the Enterprise Health System. A VM image that contains all necessary services for the Enterprise Health System to operate can be provided. This approach can also be used for Development and QA lifecycles. The All-in-one footprint enables quick and easy deployment and can serve as a stepping stone to larger deployments with dedicated services.
Dedicated DB
The Dedicated DB is the first useful step to scaling up to handle more load. The database I/O patterns tend to compete with other I/O so it is useful to split the database to another server with dedicated resources.
High Availability / Horizontal Scalability
The High Availability (HA) and Horizontal Scalability (HS) environment distributes low-level services across multiple systems to provide redundancy and high availability. The Enterprise Health System is optimized to distribute the components across multiple servers and automatically failover to balanced redundant hardware. Managing a cluster requires expert skills in load balancing, routing, networking and monitoring.
Minimum Hardware Requirement
Hardware requirements vary greatly based on a variety of factors including the number of concurrent users, user activities and data storage requirements. For example, disk requirements will be greater when converting volumes of paper charts to digital images. We typically work with our clients to review current usage requirements and forecast anticipated growth in order to ensure Development, QA and Production environments are provisioned correctly. Minimum requirements are as follows:
ALL-IN-ONE | ||
Service Name | Services | Hardware |
|
|
|
DEDICATED | ||
Service Name | Services | Hardware |
Web Services |
|
|
Database |
| |
Data Storage |
|
|
File Servers
- 3 x (1 as primary, 2 as replication partners)
- 1 x Quad-core Intel E5 series or better CPUs
- 64G RAM
- 5T of storage (RAID6 based array)
- OS: RHEL / CentOS 7.x
Web Servers
- 2 x Quad-core Intel E5 series or better CPUs:
- 12G RAM minimum
- 500G RAID1
- OS: RHEL / CentOS 7.x
Fax Server
- If using our Dialogic based FAX server, the fax and interface box can be one in the same:
- One server provides fax functionality, interfaces, and runs a virtual machine for the print functions:
- 2 x Quad-core Intel E5 series or better CPUs
- 64G RAM
- 4 x 600G 15K SAS drives in a RAID10 volume
- 1 x Dialogic DIVAServer E1 306-304 PCIe fax card for currently developed MIE faxing solution
- OS: RHEL / CentOS 7.x
- VM: Windows 7 32bit, running latest copy of Microsoft Word (for print conversions)
- 2 x Quad-core Intel E5 series or better CPUs
- One server provides fax functionality, interfaces, and runs a virtual machine for the print functions:
- If using a separate FAX server, the following specs are for a separate interface server and separate print server:
- Print server:
- 1 x Quad-core Intel E5 series or better CPUs
- 2G RAM minimum
- 20G RAID1
- OS: Windows 7 32bit, running Word 2013
- 1 x Quad-core Intel E5 series or better CPUs
- Print server:
Batch Server
- 1 x Quad-core Intel E5 series or better CPUs
- 4G RAM minimum
- 60G RAID1
- OS: RHEL / CentOS 7.x
Supportive Servers and Services
The following servers and services are not covered in detail in this document, but are typically included as part of a on-premise environment.
- Fax Server
- Dedicated bare metal hardware
- Dialogic DIVA 306-304 PCIe T1/PRI FAX card
- Interface
- EDI
- sFTP/FTPs
- Socket based
Deployment Guide
Below are the requirements, technical details and steps on how to install, configure and access the Enterprise Health system as an All-in-one VM.
Getting Started
The All-in-One EH VM deployment is designed to be quick and easy allow for Enterprise Health environments to be launch within just a few hours.
Downloading All-in-One **_
EH _** VM- Using the link provided by your deployment specials, download the EH All-in-One VM Box Image. If you do not have a link contact your deployment specialist and one will provided to you.
- Deploy the VM within your Virtualized Environment
- Assign IPv4 address to VM Network and System
- Hostname
- DNS
- VPN to MIE
- Firewall rules
- tcp/443 (HTTPS) to MIE and Application Users
- tcp/22 (SSH) to MIE
- tcp/389 and tcp/636 LDAP to MIE
- tcp/10050 and tcp/10051 - Zabbix
- tcp/1514 OSSec
- tcp/514 and udp/514 - syslog
- tcp/4505 and tcp/4506 - Salt
- Mail Services
- Allow mail to be sent from instance
- Monitoring of systems
- Audit Logging
- Backup
Web Services Configuring
- Purchase SSL certificate for selected domain name
- Configure Apache 2.2.15 with SSL certificates
On-Premise Golive Checklist
Successful Go-Live of an On-Premise Enterprise Health System requires planning, coordination and orchestration throughout the many facets of the customer’s organization, including divisions and departments to bring everything pieces together. These include, but are not limited to, data migration, IT operations, staff training, support and notification to stakeholders. This document is to help you prepare and plan for such a monumental task.
Checklist
This checklist is to help the customer plan and give insight to what is needed for a successful go-live and is by no means is comprehensive.
- Determine Enterprise Health endpoint example: (https://ehs.mycompany.com)
- Purchase SSL certificates for domain (ehs.mycompany.com)
- Server / Application Configuration:
install and configuration of services
Install and configuration of EH
Logging
Monitoring
Backup configuration
Outbound email Configuration to EH support
- Production functionality testing
- Access to Application
- View / uploading data
- Failover testing (if applicable)
Hosted vs On-Premise
SERVICE | HOSTED | CUSTOMER ON-PREMISE | |
Infrastructure |
|
|
Deployment |
|
|
IT Operations |
|
|
Software Deployment |
|
|
Managed Services
EH offers managed services for the following:Enterprise Health Documentation
Last Updated:
Last Build:
Mon, 14 Oct 2024 18:40:59 UTC
WikiGDrive Version: 2aacb51f060d0354a678419290943a99bd16aad1