On-Premise Deployment

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
  • Apache 2.4

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:

1. Development
2. QA
3. 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
Web Services Database Data Storage Interface	Apache memcached MariaDB File System	4 CPU cores 32G Memory 500G Storage

DEDICATED
Service Name	Services	Hardware
Web Services	Apache Nginx node.js memcached	4 CPU cores 8G Memory 100G Storage
Database	MariaDB	See On-Premise MariaDB Database
Data Storage	File System	4 CPU cores 8G Memory 500G 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

1. 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. 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

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

1. 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.
2. Deploy the VM within your Virtualized Environment
3. 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	SOC2 type II certified Data Center Dedicated Services Highly Available Multi-Region Redundancy Tuned for best performance 99.95% uptime SLA Tuned IDS and IPS Auto applied security patches 24/7 Monitoring of infrastructure Backup and rotations Optional data-at-rest encryption	Provisioning of hardware purchase of domain name and SSL certificates Configuration of load balancers Configuration of Linux CentOS 7, Apache, MariaDB, MIEFS, failover, logging, monitoring and other software to support the application. Self configured IDS and IPS Support Contract VPN Connectivity Access to servers
Deployment	Easy deployment - 8 to 24 hours, and your Enterprise Health system is up and running ready for production	Long deployment cycle Requires provisioning of hardware Software installation and configuration
IT Operations	Dedicated Operations team specializing in SaaS and experts in full stack deployment Continuous capacity planning, we scale as you grow	Infrastructure may not support EH requirements May require additional resources to support Enterprise Health system Capacity planning may require the provisioning of additional costly hardware or reconfiguration
Software Deployment	We plan and deploy hotfixes and upgrades seamlessly	Requires patch files to be sent Depending on deployed infrastructure, software updates may require extended downtime to implement.

Managed Services

EH offers managed services for the following: * [Application Managed Service Summary](on-premise-deployment/application-managed-service-summary.md) * [Database Managed Services](https://drive.google.com/open?id=1YX-G0aO0wZ13vsiHUtroPGSzE3q6yjKeLdzgX3fvMrs)