Healthcare on VMware Cloud

Executive Summary

Over the past few years, it has been made clear that hospitals are critical ecosystems that support their local communities. Unfortunately, during this time it has also made them targets for ransomware and strained their already burdened IT staff. The ability to seamlessly migrate life-critical workloads to the cloud has become paramount. With operational risks such as ransomware and limited IT staff, cloud is not only appealing but is becoming a necessity for hospital IT environments. While some stakeholders may have doubts about the cloud and its capabilities, the reality is that many government entities provide their communities with cloud-based services that are deemed as life-critical. With that in mind, cloud adoption can be tiered in a systematic approach, by leveraging the existing application model and migrating secondary or tertiary workloads. Migrating healthcare workloads to VMware Cloud™ on AWS can address these issues.

Audience

This reference architecture is intended for customers, IT architects, consultants, and administrators involved in the early phases of planning, design, and deployment of Electronic Health Record (EHR) solutions using VMware Cloud on AWS. It is assumed that the reader is familiar with the concepts and operations of VMware vSphere and Epic.

VMware Cloud on AWS

VMware Cloud on AWS brings VMware’s enterprise class Software-Defined Data Center software to the AWS Cloud, and enables customers to run production applications across VMware vSphere®-based environments, with optimized access to AWS services. Jointly engineered by VMware and AWS, this on-demand service enables IT teams to seamlessly extend, migrate, and manage their cloud-based resources with familiar VMware tools – without the hassles of learning new skills or utilizing new tools. VMware Cloud on AWS integrates VMware’s flagship compute, storage, and network virtualization products (VMware vSphere, VMware vSAN™ and VMware NSX®) along with VMware vCenter® management as well as robust disaster protection, and optimizes it to run on dedicated, elastic, Amazon EC2 bare-metal infrastructure that is fully integrated as part of the AWS Cloud. This service is delivered and supported by VMware and its partner community. With the same architecture and operational experience on-premises and in the cloud, IT teams can now quickly derive instant business value from the use of the AWS and VMware hybrid cloud experience. VMware Cloud on AWS enables enterprise IT and operations teams to innovate, transform, and add value to the business while continuing to leverage their VMware expertise. With VMware Cloud on AWS, you can quickly and confidently migrate applications currently deployed in on-premises and co-located data centers usually without refactoring. In addition, applications deployed in VMware Cloud on AWS become much easier to modernize with high-speed low-latency access to native cloud services from AWS.

Why VMware Cloud on AWS

Cost-effective

Reduce upfront investment costs with no application refactoring or re-architecting needed.

Scalable

Rapidly increase or decrease capacity on-demand to adapt to changing business needs across global regions with automatic scaling and load balancing.

Fast

Spin up an entire VMware SDDC in under two hours and scale host capacity in a few minutes, and leverage bi-directional, live application mobility between on-premises and the public cloud.

Simple & Consistent

Reduce operational complexity with a familiar and proven VMware environment and a single console to manage both on-premises and in the public cloud.

Secure

Leverage established on-premises enterprise security, governance and operational policies, and extend that with AWS cloud scale and security.

Automated VM Migration

Migrate large amounts of healthcare workloads with VMware HCX®. An application mobility platform that simplifies application migration, rebalances workloads and optimizes disaster recovery across data centers and clouds. HCX enables high-performance, large-scale app mobility across VMware vSphere and non-vSphere cloud and on-premises environments to accelerate data center modernization and cloud transformation.

Solution Configuration

The purpose of this paper is to introduce the capabilities and functionality of VMware Cloud on AWS and layering in well-known applications. The focus is on Epic ancillary services in this initial architecture.

Solution Architecture

The Shared Services Virtual Private Cloud (VPC) contains Active Directory Domain Controllers, Management Servers, File Servers, and Multipurpose SQL Servers. Customers should deploy a landing zone with AWS Control Tower to establish AWS multi-account management, security, and governance. The Shared Services SDDC contains System Pulse and Kuiper servers.

VMware Cloud on AWS – Epic Ancillary Services Reference Architecture

Figure 1: Ancillary and Shared Services on VMware Cloud AWS Architecture

This reference architecture provides a general guide to start deploying standard hybrid Epic ancillary services on VMware Cloud on AWS that can be accessed by on-prem end-users.

All networking information depicted here are generic examples and can be customized as per organization’s need.

Ancillary and Shared Services
1	On-prem connectivity IPsec VPN (preferably route-based) or Amazon Direct Connect between on-prem datacenter and VMC on AWS. - Policy-based VPN: Subnets must be declared on both sides during the setup. One tunnel is created per subnet. It is recommended to use large subnets. - Route-based VPN: Subnets are automatically advertised through BGP. BGP configuration is mandatory, no static route can be configured on VMC side.
2	Firewall rules for vCenter access - If on-prem connectivity is configured, allow infrastructure on-prem subnets to access vCenter and ESXi (allowing remote console, vMotion, and possibly hybrid linked mode). - Otherwise, access can be allowed from the public Internet, but it is highly recommended to limit it to a few trusted public IPs (not detailed here)
3	On-prem firewall - Access from on-prem subnets to VMC Management segment (or at least vCenter and ESXi). - Access from VMC vCenter to on-prem infrastructure services (Active Directory, DNS, Content Library)
4	Routed network segments - One infrastructure segment with privileged access to management component (vCenter, NSX) - One or multiple workload segments where all the applications VMs are deployed.
5	Firewall rules for network segments - Allow connectivity between infra and management - Allow connectivity between infra and on-prem infrastructure subnet - Allow connectivity between workload segment, AWS VPC subnets and on-prem application subnets
6	Infrastructure VMs Deploying infrastructure VMs inside VMC is recommended to provide reliability and performance to application workloads. Usual infrastructure components are (but not limited): - Active Directory (RODC might be considered) - DNS Server - Backup Server
7	DNS Configuration - VMC Compute Gateway should use on-prem DNS servers (applications can resolve enterprise domain) - vCenter alias to resolve using its private IP (allowing access from on-prem through its alias)
8	VPC connectivity This allows creating hybrid applications leveraging Amazon Native Services (EC2 & RDS Instances, S3 Buckets, EFS) and traditional virtual machines: - Allow access from/to VPC subnets and workload segments in the compute gateway and through security groups.

For No. 4 Ancillary component, see the below VM table:

VM	BI Rest
VM	BCA
VM	BCA Web
VM	Care Everywhere
VM	Reverse Proxy
VM	Web Blob
VM	Non-Prod BI Rest
VM	Interconnect
VM	Print
VM	IVR
VM	System Pulse
VM	Web Servers

VMware Cloud Hardware

VMware Cloud offers two instance types; i3.metal and i3en.metal. As with any new hardware deployment with Epic, it is recommended to refer to the most recent Hardware Configuration Guide for sizing.

	i3.metal	i3en.metal
Cores/host	36	48
Memory/host (GiB)	512	768
Storage	NVMe (~10.7 TiB raw storage capacity)	NVMe (~45.8 TiB raw storage capacity)

vSAN Storage in VMware Cloud on AWS

VMware Cloud on AWS provides two vSAN datastores in each SDDC cluster: WorkloadDatastore, managed by the Cloud Administrator; and vsanDatastore, managed by VMware.

These datastores are logical entities that share a common capacity pool. Each datastore reports the total available free space in the cluster as its capacity. Capacity consumed in either datastore updates the free value for both.

vsanDatastore

This datastore provides storage for the management VMs in your SDDC, such as vCenter Server, NSX controllers, and so on.

The management and troubleshooting of the vSAN storage in your SDDC are handled by VMware. For this reason, you cannot edit the vSAN cluster settings or monitor the vSAN cluster. You also do not have permission to browse this datastore, upload files to it, or delete files from it.

WorkloadDatastore

This datastore provides storage for your workload VMs, templates, ISO images, and any other files you choose to upload to your SDDC. You have full permission to browse this datastore, create folders, upload files, delete files, and perform all other operations needed to consume this storage.

The datastores in your SDDC are assigned the default VM storage policy by default. You can define additional storage policies and assign them to either datastore. For more information on vSAN storage policies, see Using vSAN Policies.

VMware Cloud Managed Storage Policies

When you create a cluster in your SDDC, VMware Cloud on AWS creates a managed storage policy profile that is applied by default to VMs that you create in the cluster. This storage policy profile is named "VMC Workload Storage Policy - cluster name". The policy settings ensure that the cluster meets the requirements outlined in the Service Level Agreement for VMware Cloud on AWS (the SLA). When you migrate a VM to a different cluster in the same SDDC, you must also change the VM storage policy. See Assign Storage Policies to Virtual Machines for more details.

Managed storage policy settings are based on the cluster configuration:

Single host SDDCs are not covered by the SLA. They use a No data redundancy policy.
Single-AZ clusters use thin provisioning and set a failure tolerance value based on cluster size and the host instance type:
- Clusters containing 2 to 5 hosts use 1 failure - RAID-1 (Mirroring).
- Clusters containing 6 or more hosts use 2 failures - RAID-6 (Erasure Coding).
- Stretched clusters with four hosts or fewer use No data redundancy and have Site Disaster Tolerance set to Dual Site Mirroring.
- Stretched clusters with six or more hosts use 1 failure - RAID-1 (Mirroring), but also have Site Disaster Tolerance set to Dual Site Mirroring.

Because the managed storage policy varies based on cluster size, adding or removing hosts will trigger a storage policy reconfiguration if it changes the size of the cluster so that it requires a different policy. For example, if you add an additional host to a cluster containing five hosts, the storage policy for that cluster is reconfigured from using 1 failure - RAID-1 (Mirroring) to 2 failures - RAID-6 (Erasure Coding). The reverse happens if the extra host is removed, and the number of hosts is reduced from six to five.

Refer to both the Epic Hardware Configuration Guide and the Best Practices for Epic on VMware vSAN for recommended storage policy settings.

Additional References

About the Author

Christian Rauber, Staff Mission-Critical Workloads Solution Architect in Cloud Infrastructure Business Group in VMware authored this paper with contributions from the following member:

Tom Twyman, Senior Staff VMware Cloud Solution Architect