There are multiple design considerations that need to be taken into account before proceeding with an OpenStack deployment. Analysing them thoroughly and adjusting your cloud design accordingly will help you avoid costly changes at further stages of your OpenStack deployment project. Please refer to the official OpenStack documentation and MicroStack documentation for more detailed information about each of the topics covered in this section.
Cloud architecture
OpenStack supports various types of cloud architectures, including the following:
- Hyper-Converged - each node in the cluster hosts control, compute and storage functions.
- Converged - each node in the cluster hosts compute and storage functions, while dedicated nodes exist to run the OpenStack control plane.
- Fully-Disaggregated - dedicated nodes exist to host individual cloud functions: control, compute and storage.
Sunbeam fully supports all above cloud architectures. Those can be modelled through the concept of roles specified during the initial bootstrap phase on the first node in the cluster, and when joining the cluster on other nodes.
Availability Zones
Availability Zones (AZs) are an end-user visible logical abstraction for partitioning a cloud without knowing the physical infrastructure. If designed properly, AZs provide segregation into failure domains, ensuring that any application deployed across multiple AZs can survive a failure of a single zone.
Sunbeam fully supports the concept of AZs. Those can be configured through the OpenStack client post-deployment.
Regions
Regions are general divisions of an OpenStack deployment with their own API endpoints and resources (compute, network and storage), while sharing the same identity records. The purpose of regions is to facilitate deployments of OpenStack across geographically distributed regions.
At the moment, Sunbeam only supports the default region - RegionOne.
Cells
Cells are OpenStack’s internal concept that enables cloud deployments on a large scale by sharding some of its internal components, such as databases and messaging queues.
In general, Canonical recommends running many small clouds rather than one big cloud.
At the moment, Sunbeam only supports the default cell - Cell 0.
Hardware requirements
Hardware used in OpenStack deployments must meet certain criteria to qualify for full commercial support from Canonical. Even though it might be technically possible to install the cloud on a different hardware, such configurations are neither recommended nor supported. Please refer to the MicroStack documentation for exact hardware requirements for production.
Bare metal automation
OpenStack can be deployed in two different modes with Sunbeam:
- Without bare metal automation - the operator is responsible for the initial provisioning and configuration of all physical machines used in the OpenStack cluster setup.
- With bare metal automation - Sunbeam relies on MAAS to provision and configure physical machines on-demand.
The decision whether or not to use bare metal automation with MAAS must be taken at the beginning of the deployment process. There is no way to transition from one mode to the other one once the deployment is complete.
Networking
Using multiple networks is recommended for traffic segregation purposes. Sunbeam requires at least two physical networks to be present on each node in the cluster when deploying OpenStack for production:
- Control plane network - used to provide access to OpenStack service APIs.
- External network - used to provide access to instances running on OpenStack.
Storage
Sunbeam uses Ceph as its default driver for Cinder. By default, it will take all un-partitioned disks found in all nodes in the cluster with the storage role assigned.
Plugins
By default, Sunbeam instals core OpenStack services only. Additional services and other components, such as observability stack, can be installed through the concept of plugins. Please refer to the MicroStack documentation for exact information about enabling and using individual plugins.
Third-party tools
Project Sunbeam fully relies on an upstream OpenStack code. As a result, Sunbeam-deployed clouds use standard OpenStack APIs. Any third-party tool, such as cloud platform management solution, that supports OpenStack APIs should theoretically work with Sunbeam-deployed clouds out-of-the-box.
Canonical invites vendors of such solutions to participate in Canonical’s Partner Program for joint testing and validation.
Non-standard components
For any non-standard components which require access to OpenStack services on a lower level than APIs, an additional layer of integration might be required.
Canonical invites vendors of such solutions to participate in Canonical’s Partner Program for joint design, implementation, testing and validation.
Commercial services
Even though project Sunbeam was created to lower the barrier to entry for OpenStack and minimise its operations burden, some organisations might still struggle when figuring out the right design, deploying it at scale and operating it post-deployment.
In response to those challenges, Canonical provides a whole gamut of commercial services. These include:
- Consulting - design and delivery services
- Support - phone and ticket support with guaranteed SLAs
- Managed - fully-managed cloud service
- Trainings - professional training courses
