C4 model for IT infrastructure: practical application

The C4 Model in IT Infrastructure: How to Structure Design from Context to Components

The C4 model, originally created for documenting software architecture, has proven its effectiveness in designing complex IT infrastructures. Its four-level approach allows systematically describing the system from a macroscopic context to detailed components, minimizing risks in implementing virtualization projects, migrations, or building fault-tolerant clusters. In this article, we'll break down adapting the C4 methodology for engineering tasks using the example of creating an oVirt-based cluster.

Why C4 Works for Infrastructure Projects

Traditional approaches to HLD (High Level Design) often lose the connection between business requirements and technical implementation. The C4 model solves this through sequential decomposition:

• Level 1 (Context) focuses on the system's interaction with users and external services
• Level 2 (Containers) describes physical and logical infrastructure components
• Level 3 (Components) details interactions between modules
• Level 4 (Code) is specific to software development, but in infrastructure, it's replaced with low-level connection diagrams

Key advantage for engineers—no need to create a single "monstrous" diagram. Instead, a hierarchy of views is formed, where each level addresses specific tasks:

• For managers—confirmation of alignment with business goals
• For architects—verification of system integrity
• For implementers—clear boundaries of responsibility

In infrastructure projects, the transition from Level 1 to Level 2 is especially critical. For example, when designing a virtualization cluster, at the context level all integration points are documented: AD/LDAP, monitoring systems, SIEM, and migration sources (VMware, Hyper-V). This allows identifying dependencies early, which often cause project failures.

Adapting C4 for Infrastructure Solutions

Level 1: System Context

At this stage, interactions between are documented:

• User roles (administrators, operations, service owners)
• External systems (DNS, NTP, storage systems, backup)
• Source systems (for migration from VMware/Hyper-V)

Important not just to list components, but to describe the type of interaction:

• One-way (platform → DNS for name resolution)
• Two-way (integration with monitoring system via active queries and alerts)
• Synchronous/asynchronous (data replication between data centers)

For infrastructure projects, it's critical to specify the physical location of elements. For example, with two data centers featuring synchronous data replication between them, explicitly note:

• Geographic distance between sites
• Data transfer protocols (iSCSI, NFS)
• SLA for replication time

This prevents situations where implementation reveals that network latency makes synchronous replication impossible.

Level 2: Containers

Here, the C4 model is adapted for engineering tasks. Instead of microservices, describe:

• Physical servers and their roles (virtualization hosts, cluster managers)
• Network zones (management, storage, VM network)
• Storage systems and connection protocols (iSCSI, Fibre Channel)
• Fault tolerance systems (replication, clustering)

Example structuring for an oVirt cluster:

• Container "DC-1"

- 4 virtualization hosts

- Storage with iSCSI connection

- 2 cluster manager servers

- Network segments: management (VLAN 10), storage (VLAN 20), VM traffic (VLAN 30)

• Container "DC-2"

- Similar structure

- Synchronous data replication between storage systems

• Integration Services

- AD/LDAP for authentication

- Monitoring system (Zabbix/Prometheus)

- SIEM (log transmission via syslog)

Special attention to boundary conditions:

• Maximum number of VMs per host
• Network interface throughput
• Latency requirements for replication

These parameters directly impact hardware selection and network topology, so they must be defined at the HLD level.

Practical Implementation: Case of a Fault-Tolerant Cluster

Step 1: Creating the Context Diagram

Based on project requirements, create a diagram including:

• Three user groups with descriptions of their interactions
• All integration points (AD, DNS, monitoring)
• Migration sources (VMware, Hyper-V)
• Backup systems

A critical mistake at this stage—ignoring interaction protocols. For example, if the monitoring system requires SNMPv3 but the project assumes only SNMPv2, it will lead to rework at the LLD stage.

Step 2: Detailing Containers

For each data center, form the structure:

DC-1
├── Virtualization Hosts (4 units)
│   ├── Role: Compute Node
│   ├── CPU: 2x Xeon Silver 4314
│   └── RAM: 512GB
├── Storage
│   ├── Type: iSCSI Target
│   └── Replication: synchronous to DC-2
└── Network
    ├── Management: 10Gbe, VLAN 10
    ├── Storage: 25Gbe, VLAN 20
    └── VM Traffic: 10Gbe, VLAN 30

Special attention to network zoning. Incorrect traffic separation (e.g., combining storage and VM traffic in one VLAN) creates bottlenecks under load.

Step 3: Developing Components

At this level, engineering issues are addressed:

• Bonding configuration for network interfaces
• Clustering parameters (quorum, fencing)
• Storage replication settings
• VM distribution policies across hosts

Example of a critical decision: choice between active-active and active-passive configuration for cluster managers. At the HLD level, the principle is fixed; at LLD, implementation details are worked out.

Key Points

• Context determines project success: 70% of migration problems arise from incomplete accounting of external dependencies during design
• Physical topology is critical: network delays between data centers can make synchronous replication impossible even with sufficient bandwidth
• Integrations require early testing: compatibility with existing monitoring and SIEM systems must be verified before implementation begins
• Document protocols: not just "integration with AD", but specific attributes and authentication methods
• Boundary conditions are mandatory: maximum storage load, number of simultaneous VMs, latency requirements

— Editorial Team