Epic on UCS tech brief

Technical Brief
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 1 of 23
Finding Success with Epic on Cisco UCS
Hospital systems and other healthcare organizations often turn to Epic to provide
electronic medical record (EMR) functionality. However, choosing the right platform for
an Epic deployment can be difficult. Quality patient care depends upon the availability
and reliability of EMR data, yet healthcare organizations often face budget constraints
that make platform selection a challenge. Hospitals and healthcare organizations need
an infrastructure solution that delivers high availability for Epic and allows for future
growth without overspending on excess infrastructure at the outset.
Using Cisco Unified Computing System
™
(Cisco UCS
®
) to build your Epic implementation helps make your
organization more efficient and effective. Cisco UCS is built to meet today’s demands while being ready to
accommodate future technologies as they become available. Cisco UCS for Epic environments is included in Epic
Hardware Configuration Guides for customers and has been aligned with Epic infrastructure recommendations and
best practices to help ensure that your infrastructure can deliver critical patient information with maximum
availability.
The architecture recommendations we will discuss here are based on the experiences of many Cisco and Epic
customers, so the solution has been field tested and has delivered successful results. Choosing Cisco UCS
delivers an easier, faster, more reliable platform for Epic.
The Challenges of Choosing an Epic Platform
As a leading manufacturer of medical software for hospitals, physician practices, and other healthcare
organizations, Epic has focused on the development of its application solutions, but has remained vendor-impartial
when it comes to hardware. For IT departments that prefer to use vendor-certified reference architectures,
choosing the right hardware for an Epic implementation is not always easy. Epic maintains specific server and
networking performance guidelines, which Epic describes as Target Platforms. Epic provides additional information
customized for each customer in Epic Hardware Configuration Guides. While Epic Target Platforms and Hardware
Configuration Guides offer customers guidance on hardware, these are not complete data center architectures.
The objective of this technical brief is to offer customers of Epic additional background and guidance on Cisco UCS
architecture, design, and best practices for the data center running Epic.
Cisco UCS provides an efficient, effective, tightly integrated platform sized to meet the reliability and performance
demands of healthcare organizations while staying within budget constraints. Cisco UCS is included in the
customized Epic Hardware Configuration Guide that each customer receives from Epic, so healthcare
organizations can feel secure that Cisco UCS provides the foundation for a proven, supported solution for Epic.
As customers design their data centers for Epic solutions, they often identify the following goals for their data
center architecture:
● High availability of the Epic applications
● Ease of implementing Epic within the data center

● Agility and scalability to enable growth with new Epic releases or applications
● Cost-effectiveness
● Alignment with Epic guidance and Target Platforms
● Manageability, stability, and ease of support
Epic on Cisco UCS Architecture, together with best practices, will enable customers to meet all of these goals.
Cisco UCS Solves Data Center Challenges
Cisco UCS changes the way organizations do business through policy-based automation and standardization of IT
processes. The industry’s first unified data center platform, Cisco UCS combines industry-standard x86-
architecture servers, networking, and enterprise-class management into a single system. The foundation of Epic on
Cisco UCS Architecture is Cisco UCS technology with its integrated systems management, Intel
®
Xeon
®
processors, and server virtualization. These integrated technologies solve data center challenges and enable
customers to meet their goals for data center design for Epic.
Cisco UCS and Unified Fabric
A unified fabric provides the easiest, most intelligent, and efficient way to connect and manage computing in the
data center. Cisco UCS unifies LAN, SAN, and systems management into one simplified link for rack servers,
blade servers, and virtual machines. Cisco UCS is an end-to-end I/O architecture that incorporates Cisco Unified
Fabric and Cisco fabric extender (FEX) technology to connect every component in Cisco UCS with a single
network fabric and a single network layer.
Easy: Cisco UCS, with service profile-based management, eliminates many of the time-consuming, manual, and
error-prone tasks traditionally required to connect servers and virtual machines in the data center. The platform is
self-integrating, with automated and dynamic configuration of server I/O and networking components over a
common connection. Cisco UCS centralizes administration, eliminating dozens of switching and server
management points found in traditional environments while radically reducing cable management complexity.
Efficient: Cisco UCS technology combines three network layers into one: top of rack, blade chassis, and server
hypervisor switching. It also combines LAN, SAN, and server systems management networks on a single fabric.
Modular fabric extenders deliver capacity from a centralized fabric interconnect to as many as 160 servers,
replacing expensive Ethernet and Fibre Channel switches typically deployed in much smaller server increments.
Server I/O adapters (network interface cards and host bus adapters) are consolidated onto a single virtual interface
card (VIC), reducing costs and simplifying administration. Cisco UCS allows you to wire for bandwidth, not for high-
availability connectivity.
Intelligent: Cisco UCS technology creates a virtualization-aware system, providing seamless VM mobility and
advanced security capabilities for multitenant environments. I/O capacity is dynamically allocated across physical
and virtual machines in the system in accordance with quality-of-service (QoS) policies, eliminating the need for
manual administrator intervention and simplifying troubleshooting. Deterministic, low-latency switching delivers
industry-leading bare-metal and virtualized performance for traditional multitier application environments and cloud
workloads alike.

Intel Xeon Technology
The latest Intel Xeon processors take performance, energy efficiency, and compute density to new heights while
delivering best-in-class support for virtualization, cloud computing, in-memory computing, big data analytics, and
technical computing. Servers based on these processors provide the foundation for a standardized, efficient, and
agile data center that can help you drive down space, power, cooling, and management costs while providing
exceptional performance and reliability across the full range of workloads.
Servers based on the Intel Xeon processor family offer robust mission-critical capability with significant system
price and price/performance advantages versus proprietary RISC processor–based servers running proprietary
versions of the UNIX operating system.
Server Virtualization
Virtualization is not a new concept—it can be traced back to developments at IBM for mainframes in the 1960s—
but the benefits of server virtualization are just as relevant today.
The benefits of server virtualization include:
● Consolidating multiple workloads onto fewer physical servers while optimizing the utilization of processors
and memory and at the same time reducing costs for cooling and electrical power
● Cost-effective use of redundancy to enable high availability
● Mobility that enables flexibility and agility
Cisco UCS server platforms provide unique advantages that complement the implementation of server
virtualization technologies. Cisco UCS servers with Cisco UCS Manager allow the personality of a server instance
to be easily defined and easily ported to different physical hardware. Cisco UCS Manager provides the capability to
directly integrate network interfaces with the hypervisor system for dynamic network interface allocation to virtual
machines.
Epic on Cisco UCS Architecture is based on guidance from both Epic and Cisco as well as our direct customer
experiences. The architecture is adaptable and applies best practices for Epic depending on the customer’s data
center strategy, whether small or large, and whether centralized, distributed, or multitenant.

Cisco UCS Components and Systems Management
A self-integrating, self-aware system, Cisco UCS consists of a single management domain interconnected by a
unified I/O infrastructure. The system is designed as a single virtual blade chassis that incorporates and scales
across multiple blade chassis, rack servers, and infrastructure racks. The system implements a radically simplified
architecture that eliminates the multiple redundant devices that populate traditional blade server chassis and result
in layers of complexity: Ethernet switches, Fibre Channel switches, and chassis management modules (Figure 1).
Figure 1. Cisco UCS Components

Service Profiles Ensure Consistency and Support High Availability
Cisco UCS uses service profiles to help ensure that virtual host servers in the infrastructure are configured
correctly. Service profiles include critical server information about the server identity, such as LAN and SAN
addressing, I/O configurations, firmware versions, boot order, network VLAN, physical port, and QoS policies
(Figure 2). Service profiles can be created dynamically and associated with any physical server in the system
within minutes rather than hours or days. The association of service profiles with physical servers is performed as a
simple, single operation. Service profiles enable the migration of identities between servers in the environment
without requiring any physical configuration changes and facilitate rapid bare-metal provisioning of replacements
for failed servers to meet service-level agreements (SLAs).
Figure 2. Service Profiles in Cisco UCS

Cisco UCS was developed as a unified platform integrating unified fabric, unified computing, and unified
management. Cisco UCS management acts as a single point of management, allowing the system to scale without
complexity. In addition, because it has a single management and connectivity domain, Cisco UCS integrates all the
system's resources into an agile, flexible resource pool. This simplicity and agility lays the foundation for significant
productivity improvements for Epic applications and other applications in the data center (Figure 3).
Figure 3. Cisco UCS Management with Instances of Epic Caché Service Profiles

Cisco UCS Manager is embedded software resident on the fabric interconnects and, using the service profiles
described later, provides centralized management capabilities, creates a unified management domain, and serves
as the central nervous system of the platform. Cisco UCS Manager is more than an embedded device manager. It
manages the system from end to end as a single, cohesive system using an intuitive GUI, with both command-line
interface (CLI) and XML API options, speeding configuration and reconfiguration of resources so that tasks that
used to require days or hours now can be accomplished in minutes (Figure 4).
Figure 4. UCS Manager GUI Screen example
Service profiles help ensure that servers are configured consistently throughout the enterprise. When multiple
Cisco UCS management domains are in use, Cisco UCS Central Software can use global service profiles to
synchronize configuration and policy information across domains. And if maintenance needs to be performed in
one domain, the virtual guests can be migrated to another host server in a separate domain using VMWare
vMotion for live migration with no Hyperspace downtime. This helps ensure that even when a single Hyperspace
Citrix Zone is offline, your applications continue to run with high availability.

Best Practices for Epic on Cisco UCS
Cisco has aligned Cisco UCS configurations with Epic’s best practices and has helped many healthcare
organizations achieve success with Epic deployments and migrations. Here are some best practices that
healthcare organizations can employ to get the best reliability, performance, and resource utilization when using
Epic on Cisco UCS.
Customers should review their customized Epic Hardware Configuration Guide with their Cisco account team and
Cisco partners. Epic encourages customers to share the entire Epic Hardware Configuration Guide with Cisco and
Cisco partners to facilitate the discussion of data center architecture design and Cisco UCS configuration.
Consider Epic on a Single Platform
In the past, many Epic customers have built their Epic implementations on a mix of platforms using both cost-
effective Intel x86 platforms and traditional RISC platforms. As an example, customers will build their client
presentation infrastructure on the x86 platform while running Epic’s Caché database on a RISC platform. Having a
mix of platforms in the data center incurred not only additional costs for the initial procurement but, more
importantly, additional operational and support costs required to support multiple platforms.
Today, Intel Xeon processor performance has progressed to the point that for all Epic customers, an architecture
consisting of all Cisco UCS and all Intel x86 using Intel Xeon processors will easily exceed the requirements for
running Epic and other applications. Recent Intel white papers document both lab testing and real world customer
experience using the Intel Xeon E7 v2 family of processors to run the InterSystems Caché 2015.1 platform and
Epic. Please see http://www.intersystems.com/library/library-item/data-scalability-with-intersystems-cache-and-
intel-processors/ and http://www.intersystems.com/assets/xeon-e7-intersystems-cache-paper.pdf for details and to
download the white paper.
For new Epic customers, designing an all Cisco UCS and Intel Xeon data center avoids the inherent inefficiencies
of multiple platforms, multiple management tools, and multiple policies. Cisco UCS SingleConnect technology
dramatically reduces complexity and the labor required for physical management, while lowering power
consumption and cooling costs. As described in detail earlier, Cisco UCS management assists with integrating data
center policies, as well as automating policy, provisioning, and maintenance.
For existing Epic customers with a legacy installed base of RISC-based computing platforms and proprietary UNIX,
there will be two concerns with moving to all Cisco UCS data centers. The first concern is usually the cost to make
the transition and the related ROI of replacing platforms; and the second concern is adoption of change by IT staff
who are familiar with the legacy platforms but may be unfamiliar with Cisco UCS. Cisco can help with both
concerns.
Use Service Profiles for Fast Provisioning and High Availability
Cisco UCS service profiles contain a complete description of the information required to provision a server,
including configuration, identify, network, and operational policies. They provide a mechanism for rapidly
provisioning servers and their associated network and storage connections with consistency in all details of the
environment. And they can be set up in advance of the physical installation of the servers, which is extremely
useful in most organizations.
Service profiles also enable new operational policies for high availability, since a service profile can be applied to a
spare server in another rack or blade slot in the event of a server failure; or the profile can be applied to a bare-
metal replacement in the failed unit’s physical slot.

Enable Flexibility with Consistency on Blades and Processors
Data centers are likely to evolve over time as new technology becomes available and new applications are
installed. Establishing some standards for specific models of Intel Xeon processors, memory, and specific models
of Cisco UCS blades that align with Epic Target Platform standards will provide the flexibility to move virtual
machine servers quickly and easily between similar hardware platforms. The object is to avoid installing a
patchwork of different processors or different blades with different memory that match only the minimum
requirements of specific applications. Instead it will usually make long-term economic sense to slightly exceed
minimum application requirements to meet established policy on blade and processor standards and to assure
flexibility. Epic’s Hardware Configuration Guides seek to be as consistent as possible in establishing processor
requirements. The challenges with consistency most often occur when blades and processors are specified for
non-Epic applications in the data center.
Design with Dual or Multiple Domains for Flexibility and High Availability
The flexibility and availability benefits of dual or multiple Cisco UCS management domains with Epic are a key
benefit to high availability. For larger customers, deploying Cisco UCS with multiple domains will usually be a
natural outcome of the number of blades, chassis, and racks required. For smaller customers, multiple Cisco UCS
chassis and fabric interconnects can, at first, appear to be unwarranted redundancy. Customers, however, will
need to weigh the costs and benefits of some minimal redundancy against the costs and challenges of planned
maintenance and unplanned downtime of their Epic applications. For most customers, Epic is mission critical, and
some minor degree of hardware redundancy is easily justified. Cisco would urge every customer to seriously
consider designing for Epic with a minimum of dual domains, and further to assure that the Production Caché
database is in a different domain than the Caché Disaster Recovery database. Epic provides similar guidance in
the Epic Hardware Configuration Guides.
In the dual-domain diagram in Figure 5, resources are divided into two management domains, avoiding a single
point of failure by using two fabric interconnects with Cisco UCS Manager in each domain.

Figure 5. Dual Cisco UCS Management Domains
Most customers will have both a primary and a secondary data center. A best practice is to design with dual
domains, at a minimum, in the primary data center.
Use Warm Spares and N+1 Redundancy for Improved Resiliency
An easy way to improve resiliency within Epic data centers is to add a warm spare server in a Cisco UCS domain
that can quickly be put into operation simply by moving the production service profiles from the failed server to the
spare (Figure 6). We recommend that Epic customers consider implementing a warm spare for all similar Epic
services (Hyperspace, Multipurpose, small Caché, small Clarity, etc.). Since some Epic databases (large Caché
and large Clarity) may require different types of processors (E5 vs. E7), those customers may also want to
consider warm spares for large Epic databases. These spares can be put into operation for any Caché database or
large Clarity database implementation.

Figure 6. Using a warm Spare Blade
Deploy Secondary Data Centers for Business Continuance, High Availability, and Disaster Recovery
The goal of deploying multiple data centers is to meet SLAs through redundancy, scalability, and high availability.
Redundancy is the first line of defense against any failure, and a secondary or remote data center can provide
business continuance in the event of a catastrophic disaster. Epic acknowledges the value of a secondary data
center in current Epic Hardware Configuration Guides with the statement, “We prefer that this server (the Caché
Disaster Recovery server) be housed in a remote or secondary data center.”
Data center design has evolved to become a science unto itself, and the details of network connectivity, data
replication, and failover management for a secondary or remote data center are beyond the scope of this technical
brief. Cisco and Cisco Press
®
have published numerous white papers and books that cover this science in depth.
Epic has published a Business Continuity Technical Solutions Guide and Dual Data Center Considerations
document with best practices for deploying Epic in multiple data centers.
Cisco’s recommendation as a best practice for nearly every Epic customer is to have a secondary data center, and
every Epic on Cisco UCS design includes a secondary data center. Cisco also recommends either a “warm
standby” model or a “hot standby” model for disaster recovery at the secondary data center. The “hot standby”
model is often called a Hyperspace Active-Active model when workloads are shared across both data centers.
● Warm Standby: In the warm standby model, the applications at the secondary data center are usually
ready to start or are running but not in production. Resources and services can then be manually activated
when the primary data center goes out of service and after traffic is being fully processed in the new
location. A warm standby model would align with Epic guidance to place the Caché Disaster Recovery
server in a secondary data center.
● Hot Standby and Hyperspace Active-Active: In the hot standby model, the secondary data center has
some applications running actively and some traffic processing the service tasks. Data replication from the
primary data center and the remote data center is done in real time. A hot standby data center can be used
for application recovery or to relieve the primary data center from a heavy workload. Relieving data center
resources from a heavy workload is usually referred to as a Hyperspace Active-Active model.

Understanding Epic
Epic is more than just a medical records system. It is a comprehensive suite of software components and
applications that store and present medical records. While an in-depth examination of the Epic suite is beyond the
scope of this paper, there are several key components common to Epic implementations.
● Caché
®
, manufactured by InterSystems, is the database system upon which Epic’s application suite is built.
All patient data within Epic is stored in a Caché database. The majority of Epic’s customers use a single
symmetric multiprocessing (SMP) database that scales with the addition of processors and memory. For
larger organizations, Epic may recommend a tiered database architecture using InterSystems’ Enterprise
Caché Protocol (ECP) technology.
● Hyperspace
®
is the presentation component of the Epic suite. It reads and writes data from the Caché
database and presents it to the user. Most hospital or clinic staff interact with Epic through the use of the
Hyperspace application. While Hyperspace can be installed directly on client workstations, many healthcare
organizations use application virtualization or a virtual desktop infrastructure (VDI) to deliver applications to
medical providers and staff. Citrix XenDesktop, Citrix XenApp, or VMware Horizon View are commonly
implemented to deliver Hyperspace to devices in the hospital.
● Cogito Clarity is Epic’s integrated analytics and reporting suite. Cogito is used to deliver information that can
help improve patient care, analyze clinical performance, manage revenue, and measure compliance. At a
minimum, customers will usually deploy a reporting server in addition to the production database server.
Most customers will deploy additional servers for Clarity reporting and SAP Business Objects.
● Services and services servers: The application layer of Epic includes additional support servers described in
the Epic Hardware Configuration Guides, including:
◦ Print format and relay servers
◦ Interconnect, web BLOB, and communication proxy servers
◦ Web servers for applications such as MyChart
In designing a data center for Epic, no two organizations start with the same infrastructure, implement exactly the
same configurations of technology, or operate their data centers in exactly the same way. Consequently, each
organization’s design for Epic on Cisco UCS will differ, depending on its existing infrastructure and ecosystem and
its specific infrastructure requirements. There are, however, best practices that guide data center design with Epic
on Cisco UCS:
● Align with Epic guidance for Target Platform and in Epic Hardware Configuration Guides.
● Consider Epic on a single platform to use Cisco UCS, Cisco management, and Intel Xeon processors
throughout the data center.
● Consistently select Intel Xeon processors and Cisco UCS blades to enable flexibility with workloads.
● Design with dual or multiple Cisco UCS management domains for high availability and flexibility.
● Design with some level of N+1 redundancy within the data center.
● Align with Epic guidance for high availability and disaster recovery and to help align with the Epic Honor
Roll program.
● Include a secondary data center for disaster recovery to mitigate downtime risks.

● Use a Hyperspace Active-Active data center design to enable distribution of workloads across data centers
and at the same time optimize resource use.
● Cisco Nexus
®
and Cisco
®
Application Centric Infrastructure (ACI) switches and Cisco MDS multilayer
directors provide connectivity and SAN consolidation.
Alignment with Epic Guidance—Target Platforms and Epic Hardware Configuration Guides
Each Epic customer receives an Epic Hardware Configuration Guide customized to the customer’s requirements,
including a list of assumptions, metrics, and specific recommendations that assist with design and sizing of
configurations. Customers should review their customized Epic Hardware Configuration Guide with their Cisco
account team and Cisco partners. Epic encourages customers to share the entire Epic Hardware Configuration
Guide with Cisco and Cisco partners to facilitate the discussion of data center architecture design and Cisco UCS
configuration.
Sizing Cisco UCS for Epic
It’s often difficult to predict how the business and infrastructure needs will grow and change in the future, yet
healthcare organizations face budget challenges today. Organizations need to purchase the computing resources
they need without overspending on infrastructure that will go underutilized.
To assist customers with the challenges of sizing computing platforms, Epic offers guidance with customized Epic
Hardware Configuration Guides, based upon metrics gathered by Epic through an assessment of the customer’s
operations or statistics provided by the customer to Epic. Cisco designs Cisco UCS architectures for customers in
alignment with guidance from Epic in conjunction with the overall network and storage requirements of the
customer and the best practices outlined in this technical brief. Cisco UCS and data center designs allow
healthcare organizations to buy only what they need today, with the assurance that they can grow their
infrastructure with the organization’s needs. Cisco engineers using Cisco UCS reference templates for Epic work
closely with healthcare organizations to design an appropriately sized, proven solution for each Epic
implementation. Please contact your local Cisco team to discuss the latest updates.
Epic Hardware Configuration Guides will state specifications for both physical servers (usually highlighted with blue
headings) and virtual servers (usually highlighted with green headings), including virtual CPU (vCPU) and virtual
RAM (vRAM).
The Epic Hardware Configuration Guide specifications for physical servers should be followed carefully, with
special attention to the specific models of Intel Xeon processors. The most common design error is to select Intel
Xeon processors for Cisco UCS blades that are not listed in the current Epic Target Platform or Epic Hardware
Configuration Guide documentation. Epic has carefully tested its applications with the processors listed in the
Target Platform guides to assure adequate performance.
An additional best practice recommended by both Epic and Cisco is to review individual designs in a joint meeting
between Cisco and the Epic technical manager or technical coordinator responsible for the customer before
placing orders for hardware.
Epic on Cisco UCS Architecture
Cisco architecture for Epic on Cisco UCS is based both on guidance from Epic and Cisco and on Cisco partner
experience in working with Epic customers of all sizes. The architecture is adaptable and applies best practices for

Epic, depending on the customer’s data center strategy—whether small or large, and whether centralized,
distributed, or multitenant.
When it comes to deploying Epic, Cisco has designed Cisco UCS reference architectures that align directly with
Epic’s best practices. Cisco UCS delivers a tightly integrated solution for high performance, high availability,
reliability, and scalability to support physician practices and hospital systems with several thousand beds.
Epic can be deployed effectively and efficiently with Cisco UCS, and Cisco’s experience in Epic implementations
provides the basis for success, whether performing a new implementation or migrating an existing implementation
to new hardware.
Cisco helps healthcare organizations succeed with Epic by providing a reliable, highly available, converged
hardware platform in which all the components—server chassis, blades, switches, and fabric interconnects—are
manufactured by Cisco.
Key Features of Epic on Cisco UCS
● Cisco UCS hardware delivers the compute power healthcare organizations need to meet the performance
demands of Epic. B-Series blade servers use Intel Xeon processors and support large memory
configurations to handle high transaction volume in the Caché database and provide high performance for
Epic Hyperspace and virtual desktop infrastructure (VDI) deployments. C-Series rack mount servers can be
configured with large drive configurations to support hyper-converged VDI.
● Caché database support for Intel Xeon architecture means you can virtualize your entire Epic infrastructure
on Cisco UCS to gain efficiency and consolidate Epic into a single cost-effective platform.
● Epic’s production database server (Caché) runs on the industry-leading open-source Red Hat Enterprise
Linux to provide exceptional reliability and security for patient data.
● VMWare vSphere, Microsoft Hyper-V, and Citrix XenServer virtualization platforms give enterprise-class
reliability, manageability, and scalability to Epic servers.
● With Cisco hardware and management throughout the infrastructure, Epic environments experience
reduced latency and increased bandwidth compared to competing solutions.
● Support for dual or multiple management domains allows for increased uptime and provides high availability
for Epic. The recommended best practice of using a dual-domain or multidomain architecture enables
maintenance and upgrades to be performed on one domain without resulting in downtime for Epic, helping
ensure high availability for critical patient information.
● Overlay Transport Virtualization (OTV) enables faster failover, disaster recovery, and shorter recovery point
objectives (RPOs) and recovery time objectives (RTOs) by allowing Layer 2 networking to be extended to a
second data center. Contact your local Cisco team for the latest on Data Center Interconnect (DCI)
best practices.
● Cisco UCS Manager provides centralized management capabilities, creates a unified management domain,
and serves as the central nervous system of Cisco UCS. It manages the system from end to end as a
single, cohesive system using an intuitive GUI, with both CLI and XML API options, speeding configuration
and reconfiguration of resources so that tasks that used to require days or hours now can be accomplished
in minutes.
● Cisco UCS Central Software manages multiple globally distributed Cisco UCS domains with thousands of
servers from a single pane of glass. It aggregates inventory and fault information across multiple Cisco UCS
domains to facilitate service assurance for the Cisco UCS infrastructure. Unlike Cisco UCS Manager, which

is embedded in the fabric interconnects, Cisco UCS Central is a virtual machine image that can be run on a
hypervisor to provide powerful compute infrastructure management.
● Cisco UCS Director delivers programmable application containers across compute, network, and storage.
Application containers are configured to the needs of the specific application, reducing manual processes
and extending automation benefits to the entire infrastructure stack.
● Cisco UCS works with many storage vendors, including NetApp, HP, EMC, IBM, Pure, and Hitachi. For
existing Epic customers, this helps lower your migration costs by enabling you to migrate to new computing
and network infrastructure without having to purchase new storage. For new Epic customers, you can
choose a storage platform that aligns with Epic recommendations and know that Cisco UCS will work with it.
● Cisco UCS uses Cisco SingleConnect technology to provide the easiest, most intelligent, and efficient way
to connect and manage computing in the data center. SingleConnect unifies LAN, SAN, and systems
management into one simplified link for rack servers, blade servers, and virtual machines. SingleConnect is
an end-to-end I/O architecture that incorporates Cisco Unified Fabric and FEX technology to connect every
component in Cisco UCS with a single network fabric and a single network layer.
Developing Individual Designs for Epic on Cisco UCS
Developing a specific design with an Epic on Cisco UCS Architecture begins with guidance from Epic Hardware
Configuration Guides and Target Platforms lists, and then applies the best practices described in this technical
brief. Each design should be adapted to specific customer situations and requirements, usually with expert advice
from a data center product specialist from Cisco or a Cisco partner. The Cisco team that regularly works with Epic
can be contacted at Epic-inform@cisco.com and would be happy to offer advice and review developing designs.
Finally, it is a best practice for the customer, the Epic technical manager or Epic technical coordinator, the Cisco
partner, and Cisco to review and validate all features and configurations of a design before products are ordered.

A Basic Design
A basic design for Epic on Cisco UCS will be less extensive. An example of a use case requiring a basic design
might be a physician’s practice with outpatient clinics. Such an organization may have fewer users of the Epic
applications, or it may not need all components of Epic. A physician’s practice group, for example, may not have a
need for the Epic Willow Pharmacy application or for Epic Monitor for in-patient monitoring. As a result, a basic
design will require fewer virtual hosts and fewer physical servers. It likely will also have fewer SAN requirements,
and the WAN connections to the secondary data center might be handled with basic routing and TCP/IP.
Figure 7 shows a basic Epic on Cisco UCS conceptual design.
● Cisco UCS server blades with Intel Xeon processors populate a Cisco UCS B-Series Blade Server chassis.
● Processors are selected based on Epic guidance from an Epic Hardware Configuration Guide.
● Cisco UCS Manager embedded in the fabric interconnects and Cisco UCS Central Software running on a
virtual machine provide management and are used to create service profiles and service profile templates.
Cisco UCS Central manages the physical and virtual servers and service profiles across all data centers.
● The service profile table in the figure identifies the various service profiles for Epic application components
and provides a conceptual distribution of the virtual host servers for the Epic applications distributed across
two primary data center domains and a third Cisco UCS domain in a disaster recovery secondary data
center.
● Warm spare blades are installed in the primary data center for Caché servers and spare blades are installed
for Hyperspace servers. Empty slots are distributed across domains to allow additional blades to be hot-
plug added as necessary for growing compute demands or for blade replacement in the event of a blade
failure.
● A Cisco Nexus switch is the core network switch and connects the SingleConnect Cisco UCS fabric to
the SAN.
● The primary data center uses a routed TCP/IP connection to the secondary data center.
● The Epic Caché Disaster Recovery server is located in the secondary data center and, along with instances
of Hyperspace VDI and virtual application servers, is fully operational. This design aligns with Epic’s
Hyperspace Active-Active design.
● Sufficient blades are populated in the secondary data center chassis to meet disaster recovery
requirements. To lower capital costs, Epic customers can work with local Cisco Powered
™
cloud services
partners to burst into their offerings when a disaster is declared.

(Notes: This table is not exhaustive and does not show a specific service profile or virtual server for every individual Epic application, service, or
server. Also note that HYP-V references a server for Epic Hyperspace running on VDI, and is not a reference to a hypervisor.
Hardware components are shown outside of racks to visually convey the function and management of the components. In reality, all hardware
components will be placed in racks.)
Figure 7. Basic Epic on Cisco UCS Design with Service Profile Table for Epic Applications

Expanded Design for Larger Implementations
An expanded design for Epic on Cisco UCS follows the same best practices as a basic design. The primary
difference is in the scale of an expanded design, and with larger scale there will usually be a need for higher
performance in the core switching, SAN, and processor requirements for Caché databases. Larger
implementations will typically have more Hyperspace users and need more Hyperspace XenApp or other virtual
application servers. Also, with requirements for more processing power, Cisco UCS quad-socket servers with Intel
Xeon E7 processors are used for the Chronicles Caché database and the related Production, Reporting, and
Disaster Recovery Caché servers.
Figure 8 shows an expanded Epic on Cisco UCS conceptual design.
● As with the basic design, Cisco UCS blades are used for the Hyperspace virtual application servers or VDI
servers as well as the Epic services servers. The quantity of servers for Hyperspace would be expected to
increase based on the number of users.
● With the expanded design, the Cisco UCS servers with Intel Xeon processors with higher core counts
populate Cisco UCS B-Series Blade Server chassis for the Caché databases.
● As with the basic design, processors are selected based on guidance from an Epic Hardware Configuration
Guide, though it would be expected that processor core and clock speed requirements for the Caché
servers will be greater than for other Epic virtual hosts and physical servers.
● In an expanded design, Cisco UCS Central becomes an essential management tool for global management
and monitoring across all Cisco UCS domains and data centers. The service profile backup repository of
Cisco UCS Central also adds resiliency to the design. Cisco UCS Manager embedded on the fabric
interconnects remains available to manage and monitor service profiles and administer local domains, but
Cisco UCS Central likely becomes the primary management platform.
● The service profile table in the figure identifies the various service profiles for Epic application components
and provides a conceptual distribution of the virtual servers for the Epic applications distributed across two
primary data center domains and a third domain in a disaster recovery secondary data center.
● Warm spare blades are installed in the primary data center for both Caché and Hyperspace servers. Empty
slots are distributed across domains to allow additional blades to be hot-plug added as necessary for
growing compute demands or for blade replacement in the event of a blade failure.
● Cisco fabric interconnects link the Cisco UCS chassis and fabrics.
● In an expanded design, Cisco Nexus switches become the core Ethernet network, and dual Cisco Nexus
switches are used to handle capacity requirements and avoid single points of failure.
● The SAN needs in an expanded design will also grow, and Cisco MDS multilayer directors are added in an
expanded design for performance and multiprotocol storage networking.
● Overlay Transport Virtualization (OTV) is implemented in the expanded design to enable faster failover,
disaster recovery, and shorter RPOs and RTOs by allowing Layer 2 networking to be extended to a
secondary data center.
● The Epic Caché Disaster Recovery server is located in the secondary data center, as was the case with the
basic design and, along with instances of Hyperspace VDI and virtual application servers, is fully
operational. This design again aligns with the “warm standby” model described earlier.
● Sufficient blades are populated in the secondary data center chassis to support disaster recovery
requirements.

(Note: This table is not exhaustive and does not show a specific service profile or virtual server for every individual Epic application, service, or
server. Also note that HYP-V references a server for Epic Hyperspace running on VDI, and is not a reference to a hypervisor.)
Figure 8. Expanded Epic on Cisco UCS Design with Service Profile Table for Epic Applications

Hyperspace Active–Active Implementations to Optimize Investment by Delivering Hyperspace from
All Data Centers
Rather than having hardware resources sit idle—and incurring software costs that are not necessary—in a
secondary data center, Epic customers with sufficient resources in their secondary data center and WAN capacity
will often optimize their computing investment by delivering Epic Hyperspace from both the primary data center and
the secondary data center, creating a Hyperspace Active-Active design.
The Active–Active design simply takes the expanded design one step further and puts Hyperspace XenApp or
other Hyperspace virtual application servers into full operation in the secondary data center (Figure 9). Review the
Epic Dual Data Center document for best practices regarding latency over the WAN, and work with your local
Cisco team or Cisco partner to design an infrastructure providing Hyperspace from the data center with the lowest
latency to inpatient acute care facilities and to outpatient facilities.
(Note: This table is not exhaustive and does not show a specific service profile or virtual server for every individual Epic application, service, or
server. Also note that HYP-V references a server for Epic Hyperspace running on VDI, and is not a reference to a hypervisor.)
Figure 9. Expanded Epic on Cisco UCS Design: Active-Active Scenario

Storage in an Epic on Cisco UCS Architecture—Flexible Options and Integrated Solutions
Cisco UCS provides flexibility to customers when selecting a storage vendor. The platform works with many
storage vendors, including NetApp, HP, EMC, IBM, Pure, and Hitachi. For existing Epic customers, this enables
you to upgrade to a new computing and network infrastructure without having to purchase new storage. New Epic
customers can choose a storage platform that aligns with Epic recommendations and know that Cisco UCS will
work with it.
Cisco Nexus switches and MDS multilayer directors provide enterprise-class connectivity and SAN consolidation.
Cisco multiprotocol storage networking reduces business risk by providing flexibility and options—Fibre Channel
(FC), Fibre Connection (FICON), FC over Ethernet (FCoE), SCSI over IP (iSCSI), and FC over IP (FCIP).
Together, Cisco UCS with Cisco Nexus switches and MDS multilayer directors provide a compute, networking, and
SAN connectivity solution for Epic.
Many Epic customers are interested in a data center solution that fully integrates both Cisco UCS and storage into
a single solution with coordinated support. Both NetApp and VCE offer fully integrated and converged solutions for
Cisco UCS and storage, and both offer simplified support models that reduce the challenge of “who to call” when
additional support is required.
The NetApp FlexPod is an integrated computing, networking, and storage solution developed by Cisco and
NetApp. Its configurations and workloads are published as Cisco Validated Designs. NetApp has published a
FlexPod Datacenter for Epic EHR Infrastructure Technical Brief that provides details on the solution that are of
specific interest to Epic customers.
VCE Vblock
™
Systems integrate computing, network, storage, virtualization, and management components from
trusted, industry-leading vendors Cisco, EMC, and VMware to accelerate time to deployment for Epic. VCE
™
Support helps ensure quick, coordinated support as needed, with a single call to VCE. An integrated support
portfolio enhances the value of Vblock Systems, helps maintain the highest availability and enhance team
productivity, and helps ensure proactive identification and resolution of any issues .
Similar offers are available from Cisco and associated storage vendors; work with your local Cisco team or Cisco
partner to better understand our converged infrastructure offerings with IBM, Pure, Hitachi, etc.
Cisco Partners
Cisco has trained many of the Cisco Healthcare account teams and many Cisco Partners on the use of customers’
Epic Hardware Configuration Guides for designing, sizing, and configuring Cisco UCS for Epic. Cisco also has a
mailer email address, Epic-inform@cisco.com, included in Epic Hardware Configuration Guides. Customers can
contact this mailer for questions related to their Epic Hardware Configuration Guide and Cisco UCS configurations.
Extending an Epic on Cisco UCS Design with Expert Cisco Advice and Services
Many Epic customers extend their Epic on Cisco UCS designs with expert design support from Cisco engineers,
Cisco Advanced Services, or Cisco partner systems engineers and services. Extended and more complex designs
are beyond the scope of this technical brief, but it is worth noting areas where Cisco and Cisco partners have
experience developing customized Epic on Cisco UCS designs for Epic customers.
● Epic with Intersystems Enterprise Caché Protocol (ECP)
ECP is a distributed data caching architecture that manages the distribution of data and locks among a
heterogeneous network of server systems. Larger Epic customers may use ECP to address more

demanding Epic environments. Designing for an Epic with ECP environment usually will require additional
collaboration between Epic, Cisco, a Cisco partner, and the customer.
● Multiple instances of Epic or multiple data centers
Very large Epic customers sometimes implement multiple instances of Epic, and often in more than a
primary and secondary data center. The fundamental best practices described thus far still apply in these
more complex environments, but with greatly expanded scope.
● Multitenancy and cloud
A few Epic customers have developed shared data center designs (Epic Community Connect). In related
cases an Epic customer might provide Epic hosting or cloud services to another Epic customer. Cisco offers
extensive documentation on best practices for multitenant and cloud designs, and this guidance can readily
be applied to Epic implementations. Again, designing for these more complex environments will require
additional collaboration between Epic, Cisco, a Cisco partner, and the customer.
Cisco Services can assist most customers with RISC/UNIX migration services designed for customers transitioning
to Epic on Cisco UCS. These services help address concerns about unfamiliarity with Cisco UCS, and can provide
a total cost of ownership analysis or a complete transition service to migrate to an all Cisco UCS environment. See
http://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/risc-unix-
migration/at_a_glance_c45-679242.pdf for details. Whether customers decide to engage Cisco Services for RISC
Migration or pursue the work themselves, Cisco Domain Ten
®
Framework provides valuable guidance. See
http://www.cisco.com/assets/services/cloud/cisco-domain-ten/index1.html - home.
Cisco Unified Data Center: Redefine the Economics of Your Data Center Infrastructure is a Cisco white paper that
addresses ROI and details both CapEx and OpEx impacts of a Cisco Unified Data Center design. See
http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/data-center-
virtualization/whitepaper_c11-713600.html. Cisco also provides a Data Center Savings Calculator at
https://roianalyst.alinean.com/ent_04/AutoLogin.do?d=305645370045250518. Both the white paper and the
savings calculator will help customers assess their individual ROI for implementing an all Cisco UCS data center.
Although individual customer experience will vary, a rough Cisco estimate is that most Epic customers transitioning
from an AIX Caché database to a Cisco UCS solution will have a positive ROI by the time they’ve completed two
Epic major release upgrades, or roughly 36 months. This estimate includes the cost for transitioning hardware,
operating systems, and licensing from InterSystems for Caché. Again, individual customer experience will vary.

References
● Cisco UCS Overview: http://www.cisco.com/c/en/us/products/servers-unified-computing/index.html
● Cisco UCS Management: http://www.cisco.com/c/dam/en/us/solutions/collateral/servers-unified-
computing/ucs-6100-series-fabric-interconnects/at_a_glance_c45-522983.pdf
● Cisco UCS Central: http://www.cisco.com/c/en/us/products/servers-unified-computing/ucs-central-
software/index.html
● Using OTV to Extend Layer 2 Between Two Data Centers:
http://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-series-switches/white_paper_c11-
644634.html
● Enable Local and Global Infrastructure Scale with Cisco UCS Central Software:
http://www.cisco.com/c/dam/en/us/products/collateral/servers-unified-computing/ucs-central-
software/ucsc_so.pdf
● Cisco MDS 9710 Multilayer Director: http://www.cisco.com/c/en/us/products/collateral/storage-
networking/mds-9700-series-multilayer-directors/data_sheet_c78-727769.html
● Cisco Nexus 7700 Series Switches: http://www.cisco.com/c/en/us/products/collateral/switches/nexus-
7000-series-switches/data_sheet_c78-728187.html
● Epic Customer Portal: https://userweb.epic.com (for Epic customers only)
Printed in USA C17-736678-00 2/16

Epic on UCS tech brief

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Epic on UCS tech brief (20)

Epic on UCS tech brief