Des notes d’ingénierie issues de l’exploitation d’infrastructures ouvertes : pannes, décisions de conception et travail upstream qui améliorent l’infrastructure ouverte.
Learn what makes a private cloud production-ready, from high availability and storage to security, observability, recovery, capacity, and operations.
A production-ready private cloud requires more than a successful deployment or the ability to provision virtual machines and Kubernetes clusters. It needs to support critical workloads reliably under real operating conditions, including maintenance, component failures, changing demand, security events, and recovery scenarios.
That means designing and operating the environment around availability, performance, security, scalability, observability, recoverability, and maintainability.
There is no single architecture that makes every private cloud production-ready. Requirements depend on the workloads being supported and the level of risk the organization is prepared to accept. But infrastructure teams can use a common framework to determine whether an environment is ready to move beyond deployment and into production.
1. What Does “Production-Ready” Actually Mean?
Being able to launch a VM proves that a cloud works. It does not prove that the cloud can continue operating when a controller fails, storage becomes degraded, demand spikes, or an infrastructure upgrade is required.
Production readiness means the environment has been designed and validated against defined requirements for:
Availability and acceptable downtime
Compute, storage, and network performance
Security and access control
Capacity and expected growth
Monitoring and operational visibility
Backup and recovery
Maintenance, patching, and upgrades
For OpenStack environments, production architecture guidance similarly treats high availability and scalability as design considerations rather than features to add after deployment.
2. Start With Workload Requirements
Private cloud architecture should begin with workloads, not hardware specifications.
Teams first need to understand what the environment will run. Are workloads CPU-intensive, memory-heavy, storage-sensitive, latency-sensitive, highly available, or dependent on substantial east-west network traffic?
For important workloads, document requirements around:
CPU and memory
Storage capacity and performance
Network throughput and latency
Availability
Data protection
Compliance and data-location requirements
Peak demand
Expected growth
Different workloads can exhaust different infrastructure resources. A database-heavy environment may encounter storage latency before compute capacity becomes a concern. Another cloud may have abundant CPU and storage but reach network limits during workload migrations, backups, or periods of heavy application-to-application traffic.
Capacity decisions should therefore reflect measured workload characteristics rather than one overall utilization number. OpenStack's capacity-planning guidance likewise notes that scalability depends on multiple variables and that resource usage and growth should inform expansion decisions.
3. Design for High Availability
Production infrastructure should minimize unnecessary single points of failure. But adding redundant components does not automatically create a highly available environment.
A pair of redundant services can still share the same database, switch, power source, storage system, or network path. If that shared dependency fails, both services may become unavailable.
Evaluate redundancy across:
Control-plane services
Databases and messaging services
Load balancing
Compute resources
Physical and virtual networking
Storage systems
Power and infrastructure failure domains
Failure domains deserve particular attention. Multiple servers may protect against an individual server failure while remaining exposed to a rack-level network or power event.
The objective is not maximum redundancy everywhere. It is an architecture capable of meeting the availability requirements of its workloads without introducing unnecessary complexity that becomes difficult to operate.
Current OpenStack production guidance illustrates this principle by combining redundant API endpoints and back-end services rather than treating a single redundant component as sufficient for HA.
4. Storage Must Deliver More Than Capacity
“How many terabytes do we need?” is only the first storage question.
Production storage also needs to be evaluated for:
IOPS
Throughput
Read and write latency
Redundancy
Failure domains
Rebuild and recovery behavior
Performance during degraded operation
This distinction matters because a storage system can have plenty of free capacity and still become the infrastructure bottleneck.
Ceph is commonly used with OpenStack to provide distributed storage, but its design still needs to reflect workload requirements. Ceph's current hardware guidance emphasizes that performance characteristics depend on the hardware and workload rather than a universal sizing formula.
Teams should also consider what happens after failure. If a drive or storage node becomes unavailable, how much additional network and disk activity will recovery create? Can important workloads continue meeting their performance requirements while the storage layer is rebuilding?
Production storage should be sized for usable performance and recovery behavior, not simply raw capacity.
5. Networking Can Make or Break the Environment
Network architecture belongs in the initial private-cloud design, not in the troubleshooting process after performance problems appear.
Teams need to understand both:
North-south traffic: communication between workloads and external networks.
East-west traffic: communication between workloads and infrastructure components inside the cloud.
Evaluate:
Physical network redundancy
Interface and switching capacity
Expected east-west traffic
External connectivity
Network segmentation
Load-balancing requirements
Storage traffic
Management and control-plane traffic
Behavior during link or device failures
Distributed storage, VM migrations, backups, service-to-service communication, and application traffic can all produce substantial internal network demand.
The important question is not simply whether a network connection is available, but whether the network can continue meeting workload and infrastructure requirements when traffic patterns change or individual paths fail.
6. Build Security Into the Architecture
A private cloud is not inherently secure because its infrastructure is dedicated.
Security depends on architecture, configuration, access controls, software maintenance, and ongoing operational discipline.
Production planning should address:
Identity and authentication
Role-based access control
Least-privilege administration
Network segmentation and isolation
Encryption where appropriate
Credential and secret management
Platform and operating-system patching
Security updates
Centralized logging
Administrative access
Audit requirements
Security also has a lifecycle. Appropriate controls at launch can deteriorate if unused accounts remain active, permissions expand without review, certificates expire, systems remain unpatched, or configuration changes are poorly controlled.
The OpenStack Security Guide covers these concerns across identity, authorization, networking, secrets management, secure communication, monitoring, logging, and incident response. Because portions of the guide are based on older OpenStack releases, teams should use it for conceptual guidance while validating release-specific implementation details against current documentation.
7. Establish Observability Before Production
Infrastructure teams should be able to understand what is happening inside the cloud before workloads become business-critical.
Relevant visibility may include:
CPU and memory pressure
Infrastructure and service health
API availability
Storage latency, throughput, and capacity
Network performance
Hardware health
Logs and errors
Capacity trends
But collecting metrics and logs is not the same as having actionable observability.
Operators need alerts that identify conditions worth investigating, dashboards that help narrow down causes, and enough historical context to distinguish ordinary variation from a developing infrastructure problem.
For example, a short CPU spike may require no action. Sustained storage latency combined with increasing queue depth and application response times may indicate a developing bottleneck that does.
OpenStack operational guidance also distinguishes between monitoring for service problems and monitoring resource trends that inform bottleneck and upgrade decisions.
The question before production should therefore be: If something starts going wrong, will operators know quickly enough, and will the information available help them act?
8. Plan for Failure and Recovery
Production readiness assumes that components, and occasionally larger parts of the environment, will eventually fail.
Three concepts should remain distinct:
High availability aims to minimize service interruption when particular components fail.
Backups preserve recoverable copies of data or configuration.
Disaster recovery addresses how services and data will be restored following a larger disruptive event.
One does not automatically replace another.
For important workloads, organizations should define appropriate Recovery Point Objectives (RPOs) and Recovery Time Objectives (RTOs), establish backup and recovery procedures, assign responsibilities, and validate that recovery can actually be completed.
NIST's contingency-planning guidance similarly treats recovery as a structured process involving system requirements, recovery strategies, procedures, responsibilities, testing, and plan maintenance.
A backup that exists is useful. A backup that has been successfully restored under a documented procedure provides substantially stronger evidence of readiness.
9. Plan Capacity for Failure as Well as Growth
Production capacity is not simply the amount of infrastructure required when every component is healthy.
Teams should account for:
Normal utilization
Peak demand
Expected growth
Capacity needed during maintenance
Compute or storage-node failures
Storage expansion
Network growth
Hardware procurement lead times
A cloud that has sufficient resources only when every compute, storage, and network component is available may have little operational margin for maintenance or failure.
How much headroom is appropriate depends on workload requirements, architecture, failure domains, growth expectations, and how quickly additional infrastructure can be introduced. There is no universal safe utilization percentage.
Capacity planning should therefore be revisited throughout the platform lifecycle. Monitoring actual resource consumption and user growth is also central to OpenStack's published capacity-planning guidance.
10. Don't Forget Day-Two Operations
Deploying the infrastructure is day one. Operating it safely for years is day two.
A well-designed private cloud can still become a production risk if the organization cannot maintain it predictably.
Day-two responsibilities include:
OpenStack and operating-system upgrades
Security patching
Monitoring and alert maintenance
Incident response
Hardware replacement
Capacity management
Configuration management
Certificate and credential lifecycle management
Troubleshooting
Backup verification
Documentation
These responsibilities should influence architecture decisions before launch.
Equally important is ownership.
Who responds when an infrastructure alert fires? Who owns an OpenStack upgrade? Who investigates a degraded storage cluster? Who replaces failed hardware? Who validates backup recovery? Who decides when capacity needs to expand?
If those questions do not have clear answers, the environment may have a technical architecture without a complete production operating model.
This is also where organizations need to decide which expertise they want to maintain internally and which operational responsibilities may be better supported by an infrastructure partner.
11. Test Failure, Not Just Functionality
A successful provisioning test shows that infrastructure works when conditions are normal.
Production readiness also requires understanding what happens when they are not.
Depending on the architecture and workload requirements, controlled tests may include:
Compute-node failure
Storage-device or storage-node failure
Network interruption
Control-plane service failure
Capacity exhaustion
Backup restoration
Loss of an infrastructure dependency
The objective is not to run the same failure tests in every cloud. Tests should reflect the architecture and business requirements.
Instead, the goal is to validate assumptions.
Does traffic fail over as expected? Do workloads remain available where required? Are operators alerted? Does storage recover acceptably? Can teams follow the documented recovery procedure under realistic conditions?
Failure testing converts an architectural expectation into operational evidence.
12. Production-Ready Private Cloud Checklist
Production Readiness Is an Operating Model
A production-ready private cloud isn't defined by whether infrastructure has been deployed. It's defined by whether that infrastructure can reliably support, protect, recover, and scale the workloads the organization depends on.
That requires architecture, storage, networking, security, observability, capacity, recovery, and operations to work as one system.
Organizations also do not necessarily need to develop every part of that expertise internally. The decision between self-managing a cloud, augmenting an internal team with specialist support, or using a managed operating model should be part of production planning—not an afterthought once operational complexity appears.
VEXXHOST designs, deploys, and operates OpenStack-based private cloud infrastructure, with options for infrastructure hosted in a customer's environment or VEXXHOST facilities and for supported or managed operations.
If you're evaluating a new OpenStack private cloud or assessing whether an existing environment is ready for production workloads, explore VEXXHOST's private cloud offerings or talk with the team about your architecture and operational requirements.
Virtual machines, Kubernetes & Bare Metal Infrastructure
Choose from Atmosphere Cloud, Hosted, or On-Premise. Simplify your cloud operations with our intuitive dashboard. Run it yourself, tap our expert support, or opt for full remote operations. Leverage Terraform, Ansible or APIs directly powered by OpenStack & Kubernetes
