Skip to main content
FlexPod

MEDITECH Workload Overview

Contributors
PDFs

This section describes the types of compute and storage workloads that you might find in MEDITECH environments.

MEDITECH and backup workloads

When you size NetApp storage systems for MEDITECH environments, you must consider both the MEDITECH production workload and the backup workload.

MEDITECH Host

A MEDITECH host is a database server. This host is also referred to as a MEDITECH file server (for the EXPANSE, 6.x or C/S 5.x platform) or a MAGIC machine (for the MAGIC platform). This document uses the term MEDITECH host to refer to a MEDITECH file server and a MAGIC machine.

The following sections describe the I/O characteristics and performance requirements of these two workloads.

MEDITECH workload

In a MEDITECH environment, multiple servers that run MEDITECH software perform various tasks as an integrated system known as the MEDITECH system. For more information about the MEDITECH system, see the MEDITECH documentation:

  • For production MEDITECH environments, consult the appropriate MEDITECH documentation to determine the number of MEDITECH hosts and the storage capacity that must be included as part of sizing the NetApp storage system.

  • For new MEDITECH environments, consult the hardware configuration proposal document. For existing MEDITECH environments, consult the hardware evaluation task document. The hardware evaluation task is associated with a MEDITECH ticket. Customers can request either of these documents from MEDITECH.

You can scale the MEDITECH system to provide increased capacity and performance by adding hosts. Each host requires storage capacity for its database and application files. The storage available to each MEDITECH host must also support the I/O generated by the host. In a MEDITECH environment, a LUN is available for each host to support that host’s database and application storage requirements. The type of MEDITECH category and the type of platform that you deploy determines the workload characteristics of each MEDITECH host and, therefore, of the system as a whole.

MEDITECH Categories

MEDITECH associates the deployment size with a category number ranging from 1 to 6. Category 1 represents the smallest MEDITECH deployments; category 6 represents the largest. Examples of the MEDITECH application specification associated with each category include metrics such as:

  • Number of hospital beds

  • Inpatients per year

  • Outpatients per year

  • Emergency room visits per year

  • Exams per year

  • Inpatient prescriptions per day

  • Outpatient prescriptions per day

For more information about MEDITECH categories, see the MEDITECH category reference sheet. You can obtain this sheet from MEDITECH through the customer or through the MEDITECH system installer.

MEDITECH Platforms

MEDITECH has four platforms:

  • EXPANSE

  • MEDITECH 6.x

  • Client/Server 5.x (C/S 5.x)

  • MAGIC

For the MEDITECH EXPANSE, 6.x and C/S 5.x platforms, the I/O characteristics of each host are defined as 100% random with a request size of 4,000. For the MEDITECH MAGIC platform, each host’s I/O characteristics are defined as 100% random with a request size of either 8,000 or 16,000. According to MEDITECH, the request size for a typical MAGIC production deployment is either 8,000 or 16,000.

The ratio of reads and writes varies depending on the platform that is deployed. MEDITECH estimates the average mix of read and write and then expresses them as percentages. MEDITECH also estimates the average sustained IOPS value required for each MEDITECH host on a particular MEDITECH platform. The table below summarizes the platform-specific I/O characteristics that are provided by MEDITECH.

MEDITECH Category MEDITECH Platform Average Random Read % Average Random Write % Average Sustained IOPS per MEDITECH Host

1

EXPANSE, 6.x

20

80

750

2-6

EXPANSE

20

80

750

6.x

20

80

750

C/S 5.x

40

60

600

MAGIC

90

10

400

In a MEDITECH system, the average IOPS level of each host must equal the IOPS values defined in the above table. To determine the correct storage sizing based on each platform, the IOPS values specified in the above table are used as part of the sizing methodology described in the Technical Specifications for Small, Medium and Large Architectures section.

MEDITECH requires the average random write latency to stay below 1ms for each host. However, temporary increases of write latency up to 2ms during backup and reallocation jobs are considered acceptable. MEDITECH also requires the average random read latency to stay below 7ms for category 1 hosts and below 5ms for category 2 hosts. These latency requirements apply to every host regardless of which MEDITECH platform is being used.

The table below summarizes the I/O characteristics that you must consider when you size NetApp storage for MEDITECH workloads.

Parameter MEDITECH Category EXPANSE MEDITECH 6.x C/S 5.x MAGIC

Request size

1-6

4K

4K

4K

8K or 16K

Random/sequential

100% random

100% random

100% random

100% random

Average sustained IOPS

1

750

750

N/A

N/A

2-6

750

750

600

400

Read/write ratio

1-6

20% read, 80% write

20% read, 80% write

40% read, 60% write

90% read, 10% write

Write latency

<1ms

<1ms

<1ms

<1ms

Temporary peak write latency

1-6

<2ms

<2ms

<2ms

<2ms

Read latency

1

<7ms

<7ms

N/A

N/A

2-6

<5ms

<5ms

<5ms

<5ms
Note MEDITECH hosts in categories 3 through 6 have the same I/O characteristics as category 2. For MEDITECH categories 2 through 6, the number of hosts that are deployed in each category differs.

The NetApp storage system should be sized to satisfy the performance requirements described in previous sections. In addition to the MEDITECH production workload, the NetApp storage system must be able to maintain these MEDITECH performance targets during backup operations, as described in the following section.

Backup Workload Description

MEDITECH certified backup software backs up the LUN used by each MEDITECH host in a MEDITECH system. For the backups to be in an application-consistent state, the backup software quiesces the MEDITECH system and suspends I/O requests to disk. While the system is in a quiesced state, the backup software issues a command to the NetApp storage system to create a NetApp Snapshot copy of the volumes that contain the LUNs. The backup software later unquiesces the MEDITECH system, which enables production I/O requests to continue to the database. The software creates a NetApp FlexClone volume based on the Snapshot copy. This volume is used by the backup source while production I/O requests continue on the parent volumes that host the LUNs.

The workload that is generated by the backup software comes from the sequential reading of the LUNs that reside in the FlexClone volumes. The workload is defined as a 100% sequential read workload with a request size of 64,000. For the MEDITECH production workload, the performance criterion is to maintain the required IOPS and the associated read/write latency levels. For the backup workload, however, the attention is shifted to the overall data throughput (MBps) that is generated during the backup operation. MEDITECH LUN backups are required to be completed in an eight-hour backup window, but NetApp recommends that the backup of all MEDITECH LUNs be completed in six hours or less. Aiming to complete the backup in less than six hours mitigates for events such as an unplanned increase in the MEDITECH workload, NetApp ONTAP background operations, or data growth over time. Any of these events might incur extra backup time. Regardless of the amount of application data stored, the backup software performs a full block-level backup of the entire LUN for each MEDITECH host.

Calculate the sequential read throughput that is required to complete the backup within this window as a function of the other factors involved:

  • The desired backup duration

  • The number of LUNs

  • The size of each LUN to be backed up

For example, in a 50-host MEDITECH environment in which each host’s LUN size is 200GB, the total LUN capacity to backup is 10TB.

To back up 10TB of data in eight hours, the following throughput is required:

  • = (10 x 10^6)MB (8 x 3,600)s

  • = 347.2MBps

However, to account for unplanned events, a conservative backup window of 5.5 hours is selected to provide headroom beyond the six hours that is recommended.

To back up 10TB of data in eight hours, the following throughput is required:

  • = (10 x 10^6)MB (5.5 x 3,600)s

  • = 500MBps

At the throughput rate of 500MBps, the backup can complete within a 5.5-hour time frame, comfortably within the 8-hour backup requirement.

The table below summarizes the I/O characteristics of the backup workload to use when you size the storage system.

Parameter All Platforms

Request size

64K

Random/sequential

100% sequential

Read/write ratio

100% read

Average throughput

Depends on the number of MEDITECH hosts and the size of each LUN: Backup must complete within 8 hours.

Required backup duration

8 hours

Cisco UCS Reference Architecture for MEDITECH

The architecture for MEDITECH on FlexPod is based on guidance from MEDITECH, Cisco, and NetApp and on partner experience in working with MEDITECH customers of all sizes. The architecture is adaptable and applies best practices for MEDITECH, depending on the customer’s data center strategy: whether that is small or large, centralized, distributed, or multitenant.

When deploying MEDITECH, Cisco has designed Cisco UCS reference architectures that align directly with MEDITECH’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.