OpenStack Deployment Options
OpenStack can be deployed in various ways depending on your requirements, expertise, and infrastructure. This guide covers popular deployment methods, from quick testing environments to production-grade installations.
Deployment Methods Comparison
| Method | Complexity | Production Ready | Best For |
|---|---|---|---|
| DevStack | Low | No | Development, testing, learning |
| PackStack | Low-Medium | POC only | Quick demos, proof of concept |
| MicroStack | Low | Limited | Edge deployments, small installations |
| Kolla-Ansible | Medium | Yes | Production deployments, containerized |
| TripleO | High | Yes | Large-scale, Red Hat ecosystem |
| Juju Charms | Medium | Yes | Ubuntu/Canonical ecosystem |
| OpenStack-Ansible | Medium-High | Yes | Flexible production deployments |
| Manual Installation | Very High | Yes | Custom requirements, learning internals |
Quick Start: DevStack
DevStack - Development Environment
DevStack deploys a complete OpenStack environment on a single machine using shell scripts. Perfect for developers and testing, but NOT suitable for production.
Requirements
- Fresh Ubuntu 20.04/22.04 or CentOS/RHEL installation
- Minimum 4 GB RAM (8 GB recommended)
- 10 GB+ free disk space
- Non-root user with sudo privileges
Installation Steps
git clone https://opendev.org/openstack/devstack
cd devstack
cat > local.conf << EOF
[[local|localrc]]
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=\$ADMIN_PASSWORD
RABBIT_PASSWORD=\$ADMIN_PASSWORD
SERVICE_PASSWORD=\$ADMIN_PASSWORD
# Enable services
enable_service placement-api
enable_service placement-client
# Disable unnecessary services for faster deployment
disable_service tempest
disable_service horizon
EOF
./stack.sh
Installation takes 15-45 minutes depending on internet speed. Once complete, access Horizon at http://<your-ip>/dashboard
with username admin and the password you set.
Production Deployment: Kolla-Ansible
Kolla-Ansible - Containerized Production Deployment
Kolla-Ansible deploys OpenStack services in Docker containers using Ansible playbooks. Offers excellent upgrade path and production-grade deployments with high availability support.
Architecture Requirements
| Node Type | Minimum Count | Recommended Specs | Purpose |
|---|---|---|---|
| Control Nodes | 3 (for HA) | 8 CPU, 16 GB RAM, 100 GB disk | API services, database, message queue |
| Compute Nodes | 2+ | 16+ CPU, 64+ GB RAM, 500 GB disk | Run VM instances |
| Network Nodes | 2 (for HA) | 4 CPU, 8 GB RAM, 50 GB disk | Neutron L3, DHCP, metadata agents |
| Storage Nodes | 3+ (for Ceph) | 4 CPU, 16 GB RAM, multiple disks | Ceph OSD, block storage |
| Deployment Node | 1 | 4 CPU, 8 GB RAM, 50 GB disk | Run Ansible playbooks |
Network Planning
Critical: Plan Your Networks First
OpenStack requires multiple isolated networks. Plan these before installation:
- Management Network: Internal OpenStack service communication (e.g., 192.168.1.0/24)
- Tenant Network: VM-to-VM communication, usually VXLAN/GRE overlay (e.g., 10.0.0.0/8)
- External Network: Public internet access and floating IPs (public IP range)
- Storage Network: Backend storage traffic for Ceph/NFS (e.g., 172.16.0.0/24)
- API Network: User-facing API endpoints (often same as management or external)
Kolla-Ansible Quick Start
sudo apt install python3-dev python3-pip git -y
pip3 install ansible kolla-ansible
sudo mkdir -p /etc/kolla && sudo chown $USER:$USER /etc/kolla
cp -r /usr/local/share/kolla-ansible/etc_examples/kolla/* /etc/kolla/
cp /usr/local/share/kolla-ansible/ansible/inventory/multinode /etc/kolla/inventory
# Key settings in /etc/kolla/globals.yml
kolla_base_distro: "ubuntu"
kolla_install_type: "source"
openstack_release: "zed"
kolla_internal_vip_address: "192.168.1.100"
network_interface: "eth0"
neutron_external_interface: "eth1"
enable_cinder: "yes"
enable_heat: "yes"
kolla-genpwd
kolla-ansible -i /etc/kolla/inventory bootstrap-servers
kolla-ansible -i /etc/kolla/inventory prechecks
kolla-ansible -i /etc/kolla/inventory deploy
kolla-ansible -i /etc/kolla/inventory post-deploy
Commercial Distributions
Red Hat OpenStack Platform
Based on: TripleO deployment tool
Best for: Enterprise deployments requiring commercial support
Features:
- Validated hardware compatibility
- 24/7 enterprise support
- Long-term maintenance (10+ years)
- Integration with Red Hat ecosystem (Ceph, Ansible)
Ubuntu OpenStack (Charmed OpenStack)
Based on: Juju Charms
Best for: Organizations using Ubuntu ecosystem
Features:
- Model-driven deployment
- Easy scaling and updates
- Ubuntu Advantage support
- MAAS for bare metal provisioning
SUSE OpenStack Cloud
Based on: Crowbar/Chef or Kolla
Best for: SUSE Linux Enterprise environments
Features:
- Enterprise support and SLAs
- Integration with SUSE ecosystem
- Automated deployment and lifecycle management
Mirantis OpenStack
Based on: Fuel deployment tool
Best for: Private cloud at scale
Features:
- GUI-based deployment
- Reference architectures
- Professional services
- Kubernetes integration
Deployment Best Practices
Pre-Deployment Planning
Critical Planning Steps
- Requirements Gathering: Capacity planning, workload analysis, compliance requirements
- Hardware Selection: Choose validated hardware, plan for growth (3-5 years)
- Network Design: Plan IP addressing, VLANs, bandwidth requirements
- Storage Architecture: Decide on Ceph, NFS, commercial SAN based on IOPS/capacity needs
- High Availability Strategy: Define RTO/RPO, design HA architecture
- Security Planning: Network segmentation, encryption, compliance (PCI, HIPAA)
- Monitoring Strategy: Select tools (Prometheus, Nagios), define SLAs
- Backup/DR Plan: Backup strategy for control plane and instances
Hardware Recommendations
Controller Nodes
- CPU: 8+ cores (Intel Xeon or AMD EPYC)
- RAM: 16-32 GB minimum, 64 GB for large deployments
- Storage: Dual SSDs in RAID 1 for OS, separate volumes for database
- Network: Dual 10 GbE NICs minimum, bonded for redundancy
Compute Nodes
- CPU: Maximum cores you can afford (20-64 cores common)
- RAM: 128-512 GB (ratio: 4:1 or 8:1 RAM to core)
- Storage: Local SSD for ephemeral storage, network storage for persistent
- Network: Dual 10/25 GbE for tenant traffic, separate management network
Storage Nodes (Ceph)
- CPU: 1-2 cores per OSD (disk), 8-16 cores typical
- RAM: 1-2 GB per TB of storage (16-64 GB common)
- Storage: 8-12 OSDs per server, mix SSD (journals) and HDD (data)
- Network: Dual 10/25 GbE dedicated storage network
Post-Deployment Tasks
Essential Post-Deployment Steps
- Create Initial Resources: Networks, subnets, routers, security groups
- Upload Images: Common OS images (Ubuntu, CentOS, Windows)
- Define Flavors: Instance types matching your workloads
- Configure Quotas: Set reasonable limits per project
- Setup Projects/Users: Organizational structure, RBAC
- Implement Monitoring: Deploy monitoring stack, configure alerts
- Backup Configuration: Database dumps, config files, playbooks
- Document Everything: Architecture diagrams, runbooks, escalation procedures
- Testing: Create test instances, verify HA failover, performance testing
- User Training: Train administrators and end users
Operational Considerations
- Upgrades: Plan for regular upgrades (every 6-12 months), test in staging first
- Capacity Management: Monitor resource usage, plan expansion before hitting limits
- Performance Tuning: Database optimization, network tuning, hypervisor configuration
- Security Hardening: Regular patching, security scanning, audit logging
- Disaster Recovery: Regular DR drills, documented procedures, offsite backups
- Cost Management: Chargeback/showback implementation, resource optimization
Common Pitfalls to Avoid
Avoid These Mistakes
- Inadequate Planning: Skipping network design leads to painful migrations later
- Underestimating Complexity: OpenStack requires significant expertise to operate
- Single Controller: Never run production with single controller—no HA
- Mixing Workloads: Don't run controllers on compute nodes or storage on controllers
- Ignoring Documentation: Official docs are comprehensive—read them
- No Testing Environment: Always have staging/dev environment for testing
- Poor Monitoring: You can't manage what you don't measure
- Skipping Backups: Database corruption happens—have backups and test restores
- DIY When Unnecessary: Consider commercial distributions if you lack expertise
Successful OpenStack deployment requires careful planning, adequate resources, and ongoing operational investment. Start small, learn, document everything, and scale as your expertise grows.