Dario Ristic

Open-source cloud infrastructure is the future—but it isn't accessible. AWS dominates the public cloud market, VMware dominates the private cloud space, and small-to-medium businesses are caught in between. They need cloud capabilities but can't afford expensive VMware licenses or commit to the public cloud's vendor lock-in.

My solution? Pack a complete, production-ready OpenStack infrastructure into a 2U Twin Supermicro server with full redundancy. CloudEx delivers an open-source cloud platform that brings enterprise-grade capabilities to SMB and enterprise markets.

This isn't just about installing software. This is about designing a resilient, scalable, maintainable cloud infrastructure with complete high availability that fits in a standard rack and runs reliably for customers who can't afford a full data center.

The Vision: Cloud in a Box with Full Redundancy

The goal is audacious: deliver a complete OpenStack-based cloud platform that includes compute, storage, networking, and management—all in a 2U Twin server configuration with full redundancy. Not a proof-of-concept. Not a demo. A production-ready high-availability system that businesses can deploy and rely on.

Why 2U? Standard rack unit size means it fits in any server room or data center without special accommodation. It must be as simple as rack, power, connect, and provision virtual machines.

Why OpenStack? OpenStack is relatively new but gaining momentum. It represents the freedom to avoid vendor lock-in. Unlike VMware's proprietary ecosystem, OpenStack means customers aren't trapped. If they want to migrate later, they can. The APIs are standard. The components are open source.

Most importantly, it's free software on free hardware. No per-CPU licensing costs. No VM licensing fees. The economics make sense for SMBs who need cloud capabilities but can't justify the expense of traditional virtualization platforms.

The Hardware Challenge: Twin Servers with Full Redundancy

Let me be clear: packing enterprise cloud infrastructure with full redundancy into a 2U footprint is hard. Really hard. A typical OpenStack deployment spans multiple nodes—controller nodes, compute nodes, storage nodes, network nodes. I'm consolidating all of this into a twin server configuration while maintaining complete high availability.

The 2U Twin Supermicro server enclosure I'm using is purpose-built for this kind of work. Twin architecture means two independent server nodes in a single 2U chassis. This gives me:

Server Architecture

Two Independent Nodes: Each server node is a complete system with its own CPUs, memory, storage, and network. Each node can operate independently, but together they provide high availability.

CPU: Dual Intel Xeon processors per node, multiple cores. This isn't about brute force—it's about parallelization and redundancy. Different OpenStack components can run simultaneously without contention, and if one node fails, the other takes over.

Memory: Maximized RAM capacity per node. OpenStack components are memory-hungry. Nova (compute), Cinder (storage), Neutron (networking), Horizon (dashboard)—all running in redundant clusters needed significant memory across both nodes.

Storage: Each node had a mix of SSDs and spinning disks. SSDs for the OpenStack services and databases (fast boot times, quick database operations). Spinning disks for the actual virtual machine storage. Critical data replicated between nodes for redundancy.

Network: Multiple network interfaces per node. OpenStack requires separate networks—management network, data network, storage network, replication network. The hardware had enough interfaces to handle this segmentation properly on both nodes.

RAID Controller: Hardware RAID with battery-backed write cache on each node. This isn't a development server—it's production infrastructure. Data integrity mattered. If a server crashed during a write, cached data in battery-backed memory survived. Additionally, data replicated to the peer node for complete redundancy.

Shared Storage: In addition to local storage on each node, a shared storage controller connected both nodes to common storage pools. This allowed for live migration of VMs between nodes and ensured data availability even if one node was down.

The hardware selection mattered every bit as much as the software architecture. This system had to be reliable with zero single points of failure, not just performant.

The Software Architecture: OpenStack Integration

Choosing the right OpenStack components is crucial. I can't include everything—the server has resource constraints. I need the essentials and nothing more.

Core Components

Nova (Compute): The hypervisor layer. KVM as the underlying virtualization technology for several reasons:

Cinder (Block Storage): Persistent storage for VMs. This ran as LVM (Logical Volume Manager) on the local disks. Each provisioned VM got a logical volume that could be snapshotted, extended, or migrated.

Neutron (Networking): Open vSwitch (OVS) handled virtual networking. Every VM got its own virtual network interface. Neutron created isolated networks, managed security groups, and handled floating IPs for external connectivity.

Horizon (Dashboard): Web-based UI for management. Customers needed to provision VMs without becoming OpenStack experts. Horizon provided that interface.

Keystone (Identity): Authentication and authorization. Who can access what resources.

Glance (Image Service): Repository for VM templates. Pre-installed OS images that customers could clone to provision new VMs quickly.

What I Didn't Include

Swift (Object Storage): Too resource-intensive for a single-node deployment. Real object storage needs distributed systems. I focused on block storage (Cinder) instead.

Heat (Orchestration): Nice-to-have, not essential. For SMB deployments, simple VM provisioning was enough. Complex orchestration added complexity without clear benefit.

Ceilometer (Telemetry): Monitoring was handled by simpler, lighter-weight tools. OpenStack's built-in telemetry consumed resources I couldn't spare.

The philosophy was minimal viable cloud. Include what made it a cloud platform. Omit what didn't directly contribute to provisioning VMs reliably.

Network Design: Software-Defined Everything

OpenStack's networking layer is complex. Neutron combines multiple technologies: Open vSwitch for switching, namespaces for isolation, iptables for security groups, DHCP for IP assignment. All of this had to run efficiently on a single host.

Virtual Network Architecture:

Each VM got its own L2 segment. Open vSwitch created virtual switches. Linux namespaces provided network isolation—customer A's network traffic couldn't touch customer B's network, even though both ran on the same physical server.

Security groups enforced firewall rules. Each VM had ingress and egress rules that controlled what traffic was allowed. These rules enforced at the virtual interface level, so even if a VM was compromised, it couldn't access unauthorized resources.

The Management Network:

Separate network interfaces for management versus data. The management network carried OpenStack API traffic, database replication (even single-node, best practices apply), and administrative access. This segmentation kept the control plane separate from the data plane.

In a single-node deployment, this segmentation might seem unnecessary. But it preserved the architecture's integrity. When customers wanted to scale out to multi-node, the network design carried forward without redesign.

Storage Strategy: Maximizing Capacity and Performance

Storage was the trickiest part. OpenStack block storage (Cinder) needed to provide persistent volumes for VMs across both twin nodes with full redundancy. Every provisioned VM consumed disk. Customers needed to be able to provision multiple VMs that could run on either node.

Shared Storage Architecture: Instead of local storage per node, I deployed shared storage accessible by both nodes. This meant any VM could run on either node, and VMs could migrate between nodes without storage reconfiguration. The shared storage controller connected both nodes to common storage pools.

Thin Provisioning: Cinder logical volumes were thin-provisioned by default. Allocating 100GB to a VM didn't consume 100GB immediately. It consumed only what the VM actually wrote. This let customers over-subscribe storage, provisioning 2TB worth of disks when only 500GB was physically present. Production monitoring prevented actual disk exhaustion.

Snapshot Strategy: LVM snapshots provided backup capability. Before customer changes, snapshots captured the volume state. If something went wrong, rollback was instant. These snapshots lived in shared storage, accessible from either node, not requiring external backup systems.

Storage Backend: LVM backend for Cinder because:

The alternative would have been Ceph (distributed storage), but Ceph needs multiple nodes to function properly. Shared LVM storage provided the redundancy we needed while maintaining simplicity.

Resource Management: Distributing Load Across Twin Nodes

Even though this was a twin-server system, customers needed to run multiple VMs across both nodes. Multiple tenants sharing the hardware required resource isolation and load balancing.

Workload Distribution: OpenStack distributed VM workload across both nodes automatically. VMs could run on either node based on resource availability. If one node ran low on capacity, new VMs launched on the other node.

CPU Pinning: Critical VMs could get dedicated CPU cores. Less critical VMs shared CPU time. The hypervisor scheduler allocated CPU fairly across both nodes.

Memory Overcommit: With KVM, memory could be over-committed across both nodes. Allocate 8GB to each of multiple VMs across 64GB total RAM (32GB per node). KVM used balloon drivers in VMs to dynamically reclaim memory when hosts were under pressure. This let customers provision more VMs than physical memory would normally allow, as long as VMs didn't all peak simultaneously across both nodes.

Disk I/O Limits: Multiple VMs share the shared storage subsystem. Without limits, one VM doing heavy I/O could starve others. Cgroup-based disk I/O limits ensured fair sharing of disk bandwidth, and load balancing distributed I/O load across both nodes.

Network Bandwidth: Each virtual interface had rate limiting. A single VM couldn't monopolize the physical network connections. Network traffic distributed across both nodes.

Live Migration: If one node needed maintenance or failed, VMs could live-migrate to the other node without downtime. This dynamic load balancing maximized resource utilization while maintaining availability.

Resource management meant customers could safely run multiple tenants across both nodes without one tenant's workload affecting another's, while maintaining true high availability.

Deployment and Operations: Making It Work in Production

This wasn't a development project—it needed to work reliably for actual customers. Operational concerns dominated the design.

Fast Deployment

The entire system installed as a single ISO image. Boot from USB, follow a guided installation process, and the system was ready for use. No manual OpenStack configuration. All components installed, configured, and wired together automatically.

The installation process:

  1. Boot from CloudEx ISO
  2. Answer a few prompts (hostname, IP address, root password)
  3. Installation completes
  4. Access Horizon dashboard
  5. Start provisioning VMs

This simplicity mattered. Customers weren't OpenStack experts. They were businesses that needed cloud infrastructure.

Monitoring and Maintenance

Built-in monitoring tracked:

Alerts triggered when thresholds were exceeded. Customers could see their infrastructure health from the dashboard.

Backup Strategy

Automated snapshot rotation. Periodic snapshots of all volumes. Old snapshots deleted as newer ones created. If a VM failed, restore from snapshot. No external backup systems required.

Snapshots were fast—seconds, not minutes. LVM snapshots are copy-on-write, so creating a snapshot was just metadata operations. Restoring a snapshot was equally fast.

Challenges and Solutions

Packing OpenStack into a twin-server configuration with full redundancy encountered real engineering challenges.

Challenge 1: Memory Constraints

Early versions ran out of memory under load. All OpenStack services consume RAM. When multiple VMs ran simultaneously, the host system ran low on memory.

Solution: Aggressive memory tuning for OpenStack services. Reduced service worker counts. Disabled non-essential features. Swapped to disk used only for unallocated memory, never for active VM memory. Configured log rotation to prevent log files from consuming space.

Every MB of memory mattered. I profiled each service, measured actual memory usage, and tuned aggressively.

Challenge 2: Database Performance

PostgreSQL databases for Keystone, Nova, Glance competed for disk I/O. Under load, database operations became slow, impacting VM provisioning.

Solution: Moved all databases to SSD. Database performance is I/O bound. SSDs eliminated I/O bottlenecks. PostgreSQL configuration tuned for SSD workloads. Write-ahead log tuning optimized for SSD characteristics.

This simple change—moving databases to faster storage—dramatically improved responsiveness.

Challenge 3: Network Complexity

Managing Neutron's network topology was complex. Virtual switches, namespaces, iptables rules—this complexity made debugging difficult when something went wrong.

Solution: Automated network provisioning through Neutron's API. Customers never touched networking configuration manually. The UI created networks, routers, subnets automatically. Behind the scenes, Open vSwitch, namespaces, and iptables configured automatically.

Abstraction hid complexity. Customers created a network in Horizon, and OpenStack handled the implementation details.

Challenge 4: Achieving True High Availability

Initial designs had single points of failure. One server failure meant complete outage. Customers needed better reliability.

Solution: Twin server architecture with full redundancy. OpenStack services ran in active-active clusters across both nodes:

Critical innovation: VMs ran on either node via shared storage, so virtual machines continued running even if one physical server failed entirely. Failover was automatic—if Node A failed, Node B detected it and continued serving all VMs.

This wasn't just redundancy—it was true high availability. One node could fail completely, and the system continued operating without manual intervention.

The important part was managing expectations. CloudEx wasn't AWS with multiple data centers, but it provided enterprise-grade high availability in a compact 2U form factor that fit in any server room.

Lessons Learned

Simplicity Over Features

The temptation was to include more OpenStack components. Heat for orchestration would have been nice. Ceilometer for metrics would have been useful. Sahara for Hadoop would have addressed specific use cases.

I resisted. Every additional component consumed resources. Every additional component created potential failure points. Every additional component required documentation, support, and maintenance.

CloudEx succeeded by doing less, not more. It did the core cloud job—provision persistent virtual machines—really well. That focus mattered.

Open Source Economics

The success of CloudEx hinged on open-source economics. No licensing fees meant the total cost of ownership was just hardware plus support. For customers coming from VMware environments, this cost difference was dramatic.

But open source wasn't free—it required expertise. My job was packaging that expertise into a system customers could operate without becoming OpenStack experts.

Hardware Matters

Software-defined infrastructure doesn't eliminate hardware dependencies. Disk speed, memory capacity, CPU cores, network interfaces—all of these constrained what the software could do.

Choosing hardware carefully mattered. The Supermicro 2U Twin server wasn't just commodity hardware—it was specifically selected for this use case. Twin-server redundancy, RAID controllers with battery backup on each node, multiple network interfaces per node, and sufficient slots for both SSDs and spinning disks on both nodes.

Good hardware made good software possible.

Abstraction is Value

Customers didn't care about Keystone authentication tokens or Neutron L2 agents or Nova compute drivers. They cared about provisioning VMs.

The value proposition was abstraction. Hide the complexity of OpenStack behind a simple interface. Hide the complexity of KVM, Open vSwitch, LVM behind OpenStack. Hide the complexity of the underlying hardware behind software layers.

Each layer of abstraction made the system simpler to use. The engineering challenge was maintaining that simplicity while the underlying technology remained complex.

The Market Impact

CloudEx addressed a real market need: affordable cloud infrastructure for SMBs who couldn't justify AWS's monthly costs or VMware's licensing fees.

For Small Businesses: They got cloud capabilities without monthly commitments or vendor lock-in. Deploy CloudEx in their office server room, provision VMs internally, control their own data.

For Enterprise: They got a private cloud option that didn't require massive investment. Departments could deploy their own cloud infrastructure without IT approval processes. Compliance, regulatory, security requirements could be met without sending data to public cloud.

For Service Providers: They got a white-label cloud platform. Deploy CloudEx hardware for multiple customers, provision VMs per customer, maintain one infrastructure investment.

The market wasn't just "who needs a twin-server cloud." It was "who needs cloud capabilities without the full infrastructure, ongoing costs, or vendor lock-in of traditional cloud."

Future Improvements

Looking ahead, there are several things I'm considering:

Ceph Instead of LVM: Ceph could provide better distributed storage across the twin nodes. This would improve scalability if customers want to expand to additional storage nodes later.

Dockerized Services: Docker is still maturing. Running OpenStack services in containers could simplify deployment and updates.

Better Monitoring: While live migration between twin nodes is working well, monitoring and alerting could be more sophisticated. Prometheus-based monitoring would provide better insights into cluster health and performance across both nodes.

These are areas for potential enhancement. The current design choices make sense with available technology, but there's always room for improvement.

The Open Source Philosophy

CloudEx embodies the open-source philosophy: freedom to use, modify, and distribute. No vendor lock-in. No licensing fees. No artificial limitations.

This isn't just about cost savings—it's about control. Customers control their infrastructure. They can see the source code. They can modify it if needed. They aren't dependent on a vendor's roadmap.

The openness extends to the platform itself. Underlying technologies are open source: Linux, KVM, OpenStack, Open vSwitch, LVM. Even the hardware choice avoids proprietary extensions where possible.

This open approach differentiates CloudEx from proprietary virtualization platforms. It isn't cheaper—it's freer. And for many customers, that freedom matters more than cost.

Conclusion: Cloud Computing Democratized

CloudEx proves that enterprise cloud infrastructure doesn't require data center scale. A twin-server configuration in 2U can deliver real cloud capabilities with full high availability to customers who need them.

The project demonstrates that thoughtful architecture and careful resource management can compress a full cloud stack into a manageable form factor. That open source doesn't have to mean amateur—it can mean production-grade infrastructure.

Most importantly, it shows that cloud computing can be accessible. Not just for big corporations with data center budgets, but for small businesses, departments, service providers who need cloud capabilities without cloud complexity.

The principles remain relevant: simplicity over complexity, resource efficiency, redundancy, open standards, abstraction that hides complexity while exposing value.

CloudEx is my attempt to democratize cloud computing—to bring enterprise-grade infrastructure to customers who can't access it otherwise. This is what open source cloud should be: practical, accessible, enterprise-grade.

Sometimes the most ambitious projects aren't the ones that span continents or use bleeding-edge technology. Sometimes they're the ones that take complex systems and make them accessible. That's CloudEx: cloud computing with full high availability, simplified, in a twin-server configuration.