Cloud Orchestration with OpenStack
Cloud Orchestration with OpenStack
This domain tests operating OpenStack as the VIM for NFV and cloud workloads. Know the core services, the Neutron networking model, and how Juniper Contrail or vMX/vSRX integrate.
Core rules
- Keystone authenticates and authorizes; Nova schedules VMs; Glance stores images; Cinder provides block volumes; Swift provides object storage; Neutron provides networks, subnets, ports, routers, and security groups; Heat orchestrates stacks; Placement tracks resource inventories.
- Neutron has tenant networks, self-service and often VXLAN or Geneve, and provider networks mapped to physical VLANs. ML2 drivers and agents implement the data plane; Contrail can replace the Neutron plugin and provide EVPN/VXLAN.
- Security groups are stateful L2/L3 filters at the port; floating IPs provide external reachability through NAT.
- For NFV, use SR-IOV or DPDK ports, flavor extra specs, and host aggregates to pin workloads.
Worked example
A tenant creates private network 192.168.10.0/24, boots a VM with a Neutron port, and needs SSH from outside. Create the tenant network and subnet, attach the port to the VM, add a security group rule for TCP/22, then associate a floating IP from the external provider network to the port. Reasoning: the router connects the tenant subnet to the external network; without it, the floating IP has no path. The security group must allow SSH before the floating IP is usable.
Traps
- Confusing provider and tenant networks. Provider networks map to physical VLANs and are usually admin-created.
- Forgetting that security groups apply at the port, not the subnet.
- Assuming Heat and Nova are the same layer. Heat orchestrates API calls; Nova places instances.