# Epic InterSystems Iris Architecture
## Introduction
InterSystems Iris is the database platform used by the Epic application. It provides a robust, scalable foundation for healthcare data management with comprehensive support for high availability, disaster recovery, and enterprise-scale deployments.
### Core Components
The InterSystems Iris architecture consists of several key components:
- **Data Server**: The access point for persistently stored data
- **Application Server**: Manages database queries and makes data requests to the data server
- **Symmetric Multiprocessor (SMP) Architecture**: Sufficient for most Epic software environments
- **Enterprise Caché Protocol (ECP)**: Enables distributed models for large deployments
### Key Advantages
The updated Iris database provides significant benefits:
- **Increased Scale**: Enables larger organizations with multiple Epic instances to consolidate into one larger instance
- **Platform Flexibility**: Licensing holiday allowing customers to move between AIX and Red Hat Enterprise Linux (RHEL) without paying for a new platform license
## Epic Environment Overview
The complete Epic ecosystem includes multiple interconnected components working together to provide comprehensive healthcare data management.
```mermaid
graph TB
subgraph "Client Layer"
HS[Hyperspace<br/>Client Access]
end
subgraph "Primary Site"
PROD[("Production DB<br/>Read/Write")]
APP[Application<br/>Servers]
REPORT[("Report Mirror<br/>Read-Only")]
CLARITY[("Clarity DB<br/>Oracle/SQL Server")]
WEBLOB[WebBLOB Server<br/>SMB Storage]
end
subgraph "Secondary Site"
DR[("DR Mirror<br/>Read-Only")]
SUPPORT[("Support Mirror<br/>Read-Only")]
end
subgraph "Development"
TEST[("Test/Dev/Staging<br/>Environments")]
end
subgraph "Storage Infrastructure"
STORAGE[Storage Cluster<br/>SAN/NAS Storage]
SNAP[Storage Replication]
end
HS --> APP
APP --> PROD
PROD -.Mirror Sync.-> REPORT
REPORT -.Daily Extract.-> CLARITY
PROD -.Async Mirror.-> DR
PROD -.Mirror.-> SUPPORT
PROD --> STORAGE
REPORT --> STORAGE
DR --> STORAGE
WEBLOB --> SNAP
TEST --> STORAGE
classDef production fill:#ff6b6b,stroke:#c92a2a,stroke-width:3px,color:#fff
classDef report fill:#4dabf7,stroke:#1971c2,stroke-width:2px,color:#fff
classDef dr fill:#ff922b,stroke:#d9480f,stroke-width:2px,color:#fff
classDef support fill:#51cf66,stroke:#2f9e44,stroke-width:2px,color:#fff
classDef clarity fill:#ffd43b,stroke:#fab005,stroke-width:2px,color:#000
classDef weblob fill:#cc5de8,stroke:#9c36b5,stroke-width:2px,color:#fff
classDef test fill:#e9ecef,stroke:#868e96,stroke-width:1px,color:#000
classDef storage fill:#343a40,stroke:#212529,stroke-width:2px,color:#fff
class PROD production
class REPORT report
class DR dr
class SUPPORT support
class CLARITY clarity
class WEBLOB weblob
class TEST test
class STORAGE,SNAP storage
```
## InterSystems Iris Database Architecture
### Symmetric Multiprocessor (SMP) Architecture
For most Epic software environments, the SMP architecture in a single database server suffices to service Epic applications' database requests. In large deployments, a distributed model can be supported using InterSystems' Enterprise Caché Protocol (ECP).
```mermaid
graph LR
subgraph "Standard SMP Architecture"
direction LR
APP1[Application<br/>Server]
DATA1[Data<br/>Server]
STOR1[(All-Flash<br/>Storage)]
APP1 -->|Query| DATA1
DATA1 -->|I/O| STOR1
end
subgraph "Distributed ECP Architecture"
direction LR
DATA2[Data<br/>Server]
STOR2[(Shared<br/>Storage)]
APP2A[Application<br/>Server A]
APP2B[Application<br/>Server B]
APP2C[Application<br/>Server C]
APP2A -->|ECP| DATA2
APP2B -->|ECP| DATA2
APP2C -->|ECP| DATA2
DATA2 -->|I/O| STOR2
end
subgraph "High Availability Cluster"
direction LR
PRIMARY[Primary<br/>Data Server<br/>Active]
STANDBY[Standby<br/>Data Server<br/>Passive]
SHARED[(Shared<br/>Storage)]
PRIMARY -.Failover.-> STANDBY
PRIMARY --> SHARED
STANDBY -.-> SHARED
end
classDef appserver fill:#74c0fc,stroke:#1971c2,stroke-width:2px,color:#000
classDef dataserver fill:#ff6b6b,stroke:#c92a2a,stroke-width:2px,color:#fff
classDef storage fill:#343a40,stroke:#212529,stroke-width:2px,color:#fff
classDef standby fill:#ffd43b,stroke:#fab005,stroke-width:2px,color:#000
class APP1,APP2A,APP2B,APP2C appserver
class DATA1,DATA2,PRIMARY dataserver
class STOR1,STOR2,SHARED storage
class STANDBY standby
```
### Failover and High Availability
The use of failover-enabled clustered hardware enables a standby data server to access the same storage as the primary data server. This configuration allows the standby data server to take over processing responsibilities during a hardware failure, ensuring continuous operation.
### Replication Technologies
InterSystems provides comprehensive technologies to satisfy data replication, disaster recovery, and high-availability (HA) requirements:
- **InterSystems Replication**: Replicates an Iris database synchronously or asynchronously from a primary data server to one or more secondary data servers
- **Storage Replication**: Replicates WebBLOB storage for backup and disaster recovery purposes
## Database Server Types
In Epic software environments, a single patient-centric database is deployed with multiple mirror configurations to support different operational needs.
### Mirror Replication Flow
```mermaid
graph TB
subgraph "Primary Site"
PROD[("Production Database<br/>Read/Write<br/>High Performance<br/>All-Flash Storage")]
FAILOVER[Failover Server<br/>Standby]
REPORT[("Report Mirror<br/>Read-Only<br/>Reporting Workload")]
end
subgraph "Disaster Recovery Site"
DR[("DR Mirror<br/>Read-Only → SRW<br/>Geographic Separation")]
end
subgraph "Optional"
SUPPORT[("Support Mirror<br/>Read-Only → Read/Write<br/>Business Continuity")]
end
PROD -.Shared Storage.-> FAILOVER
PROD -->|Epic Mirror<br/>Synchronous| REPORT
PROD -->|Epic Mirror<br/>Asynchronous| DR
PROD -->|Epic Mirror| SUPPORT
FAILOVER -.Automatic<br/>Failover.-> PROD
classDef production fill:#ff6b6b,stroke:#c92a2a,stroke-width:3px,color:#fff
classDef failover fill:#ffd43b,stroke:#fab005,stroke-width:2px,color:#000
classDef report fill:#4dabf7,stroke:#1971c2,stroke-width:2px,color:#fff
classDef dr fill:#ff922b,stroke:#d9480f,stroke-width:2px,color:#fff
classDef support fill:#51cf66,stroke:#2f9e44,stroke-width:2px,color:#fff
class PROD production
class FAILOVER failover
class REPORT report
class DR dr
class SUPPORT support
```
### Production Database Server
In Epic's hardware requirements, the physical server hosting the primary read/write Iris data server is called the production database server. Key characteristics:
- **Storage Requirements**: High performance all-flash storage for files belonging to the primary database instance
- **High Availability**: Epic supports the use of a failover database server with access to the same files
- **Replication**: Uses Epic Mirror to replicate to read-only Report, disaster recovery, and support read-only copies
- **Business Continuity**: Each type of database server can be switched to read/write mode for business continuity reasons
### Report Mirror Database Server
A reporting mirror database server provides read-only access to production data. Key characteristics:
- **Configuration**: Hosts an Iris data server configured as a backup mirror of the production Iris data server
- **Storage Capacity**: Same requirements as the production database server
- **Performance Profile**: Write performance matches production, but read workload characteristics are different and sized accordingly
- **Purpose**: Dedicated reporting queries without impacting production performance
### Support Read-Only Mirror Database Server
This database server is optional and provides additional read-only access to production data:
- **Purpose**: Provides a copy of production in read-only mode for support activities
- **Flexibility**: Can be switched to read/write mode for business continuity reasons
- **Deployment**: Not always included in standard configurations
### Disaster Recovery Mirror Database Server
To meet business continuity and disaster recovery objectives, a DR mirror database server is commonly deployed:
- **Geographic Separation**: Deployed at a site geographically separate from production and/or reporting mirror database servers
- **Configuration**: Hosts an Iris data server configured as a backup mirror of the production Iris data server
- **Business Continuity**: Can be configured to act as a mirror read/write instance (SRW) if the production site becomes unavailable
- **Storage Requirements**: Same file storage requirements as production database server, sized from a performance perspective for business continuity
### Test, Development, and Staging Environments
Healthcare organizations often deploy additional environments for testing and development:
- **Purpose**: Development, testing, and staging environments for application updates and testing
- **Storage**: Additional Iris data servers requiring storage, which can be accommodated by the same storage system
- **Requirements**: Epic has specific requirements and constraints for providing additional storage from a shared storage system
## Additional Epic Components
Beyond the Iris ODB data servers, Epic software environments include several other critical components.
### Clarity Database
- **Platform**: Oracle or Microsoft SQL Server database server
- **Purpose**: Backend for Epic's Clarity business-reporting tools
- **Data Source**: Reports on data extracted daily from the reporting Iris database
### WebBLOB Server
- **Protocol**: SMB (Server Message Block)
- **Storage**: Stores large binary objects such as images and documents
- **Replication**: Storage replication used for backup and disaster recovery
### Multipurpose Components
- **Multipurpose Database Server**: Supports various ancillary database needs
- **Multipurpose Virtual Machines**: Provide flexible compute resources for various Epic functions
### Hyperspace
- **Purpose**: Client access layer for Epic applications
- **Function**: Provides the user interface for clinicians and staff to access Epic systems
### Consolidated Storage Strategy
The storage requirements of all these multiple workloads, pools, NAS and SAN protocols can be consolidated and hosted by a single storage cluster. This consolidation enables healthcare organizations to have a single data management strategy for all Epic and non-Epic workloads.
## Storage Architecture
### File Types and I/O Patterns
Each Epic database server performs I/O on three primary types of files:
```mermaid
graph TB
subgraph "Epic Database Server"
SERVER[Iris Data Server]
end
subgraph "Storage System"
subgraph "Database Files"
DB1[Primary Database<br/>100% Random I/O<br/>Most Demanding]
DB2[Mirror Databases<br/>Less Demanding<br/>Fewer Read Requests]
end
subgraph "Journal Files"
JOURNAL[Transaction Logs<br/>Sequential I/O<br/>Write-Intensive]
end
subgraph "Application Files"
APPFILES[Application Code<br/>Configuration<br/>Static Content]
end
end
SERVER -->|Random Read/Write| DB1
SERVER -->|Random Read| DB2
SERVER -->|Sequential Write| JOURNAL
SERVER -->|Read Access| APPFILES
classDef database fill:#ff6b6b,stroke:#c92a2a,stroke-width:2px,color:#fff
classDef mirror fill:#4dabf7,stroke:#1971c2,stroke-width:2px,color:#fff
classDef journal fill:#51cf66,stroke:#2f9e44,stroke-width:2px,color:#fff
classDef app fill:#ffd43b,stroke:#fab005,stroke-width:2px,color:#000
class DB1 database
class DB2 mirror
class JOURNAL journal
class APPFILES app
```
### Workload Characteristics
The workload of an individual database server depends on its role in the Epic software environment:
- **Production Database Files**: Typically incur the most demanding workload, consisting of 100% random I/O requests
- **Mirror Databases**: Workload is typically less demanding with fewer read requests
- **Journal Files**: Workloads are mainly sequential, providing predictable performance patterns
### Performance Benchmarking
Epic maintains a workload model for storage performance benchmarking and customer workload analysis. For more information about the Epic workload model, benchmark results, and guidance on correctly sizing storage for Epic environments, consult Epic's documentation and sizing tools.
## High Availability and Disaster Recovery
```mermaid
graph TB
subgraph "Primary Site"
direction TB
PROD_PRIMARY[("Production Database<br/>Read/Write<br/>Primary")]
PROD_FAILOVER[("Failover Server<br/>Standby")]
REPORT_PRIMARY[("Report Mirror<br/>Read-Only")]
WEBLOB_PRIMARY[WebBLOB Storage<br/>Primary]
STORAGE_PRIMARY[(Primary Storage)]
PROD_PRIMARY -.Cluster.-> PROD_FAILOVER
PROD_PRIMARY --> STORAGE_PRIMARY
PROD_FAILOVER -.-> STORAGE_PRIMARY
REPORT_PRIMARY --> STORAGE_PRIMARY
WEBLOB_PRIMARY --> STORAGE_PRIMARY
end
subgraph "DR Site - Geographic Separation"
direction TB
DR_MIRROR[("DR Mirror<br/>Read-Only → SRW<br/>Backup")]
WEBLOB_DR[WebBLOB Storage<br/>DR Copy]
STORAGE_DR[(DR Storage)]
DR_MIRROR --> STORAGE_DR
WEBLOB_DR --> STORAGE_DR
end
PROD_PRIMARY ==>|Epic Mirror<br/>Async Replication| DR_MIRROR
WEBLOB_PRIMARY ==>|Storage Replication| WEBLOB_DR
STORAGE_PRIMARY -.Backup/DR.-> STORAGE_DR
subgraph "Failure Scenarios"
SCENARIO1["Hardware Failure:<br/>Automatic failover to standby<br/>within Primary Site"]
SCENARIO2["Site Failure:<br/>Manual activation of DR site<br/>DR Mirror → SRW mode"]
end
classDef primary fill:#ff6b6b,stroke:#c92a2a,stroke-width:3px,color:#fff
classDef standby fill:#ffd43b,stroke:#fab005,stroke-width:2px,color:#000
classDef dr fill:#ff922b,stroke:#d9480f,stroke-width:3px,color:#fff
classDef storage fill:#343a40,stroke:#212529,stroke-width:2px,color:#fff
classDef scenario fill:#e9ecef,stroke:#868e96,stroke-width:1px,color:#000
class PROD_PRIMARY,REPORT_PRIMARY primary
class PROD_FAILOVER standby
class DR_MIRROR dr
class STORAGE_PRIMARY,STORAGE_DR storage
class SCENARIO1,SCENARIO2 scenario
```
### Hardware Failure Protection
Failover-enabled clustered hardware provides automatic recovery:
- **Standby Server**: Accesses the same storage as the primary data server
- **Automatic Failover**: Standby server takes over processing responsibilities during hardware failure
- **Minimal Downtime**: Quick recovery maintains service continuity
### Site Failure Protection
Geographic separation and mirror replication provide disaster recovery:
- **Asynchronous Replication**: Data replicated to geographically separate DR site
- **Manual Activation**: DR mirror can be promoted to read/write mode (SRW)
- **WebBLOB Replication**: Storage replication ensures document and image availability
- **Business Continuity**: Full system recovery at DR site if primary site unavailable
## Deployment Planning and Sizing
### Hardware Configuration Guide
Epic provides each customer with a customized hardware configuration guide containing:
- **I/O Projections**: Expected input/output operations based on customer's projected workload
- **Storage Capacity Requirements**: Total storage needs for all database instances
- **Environment Coverage**: Requirements for development, testing, staging, and production environments
- **Ancillary Workloads**: Additional workloads that may be consolidated on the storage system
Customers can use this hardware configuration guide to communicate total storage requirements. The guide contains all the data needed to properly size an Epic deployment.
### Database Storage Layout Guide
During the deployment phase, Epic provides a Database Storage Layout Guide with more granular details:
- **LUN-Level Details**: Specific logical unit number configurations
- **Advanced Storage Design**: Detailed layout recommendations for optimal performance
- **General Recommendations**: Storage best practices for optimal results
- **Storage Optimization**: Use this guide to determine the best storage layout for your infrastructure
Sign in with Wallet
Connect another wallet