The selection of OS and hypervisor has a significant impact on the overall design and also affects server hardware selection. Ensure that the storage hardware is supported by the selected operating system and hypervisor combination and that the networking hardware selection and topology will work with the chosen operating system
and hypervisor combination. For example, if the design uses Link Aggregation Control Protocol (LACP), the OS and hypervisor are both required to support it.
Some areas that could be impacted by the selection of OS and hypervisor include:
Cost: Selection of a commercially supported hypervisor, such as Microsoft Hyper-V, will result in a different cost model rather than selected a community-supported open source hypervisor like Kinstance or Xen. Similarly, choosing Ubuntu over Red Hat (or vice versa) will have an impact on cost due to support contracts. Conversely, business or application requirements might dictate a specific or commercially supported hypervisor.
Supportability: Whichever hypervisor is chosen, the staff needs to have appropriate training and knowledge to support the selected OS and hypervisor combination. If they do not training will need to be provided, which could have a cost impact on the design.
Another aspect to consider would be the support for the OS-hypervisor. The support of a commercial product such as Redhat, Suse, or Windows, is the responsibility of the OS vendor. If an Open Source platform is chosen, the support comes from in-house resources.
Either decision has a cost that will have an impact on the design.
Management tools: The management tools used for Ubuntu and Kinstance differ from the management tools for VMware vSphere. Although both OS and hypervisor combinations are supported by OpenStack, there will naturally be very different impacts to the rest of the design as a result of the selection of one combination versus the other.
Scale and performance: Make sure that selected OS and hypervisor combination meet the appropriate scale and performance requirements needed for this general purpose OpenStack cloud. The chosen architecture will need to meet the targeted instance-host ratios with the selected OS-hypervisor combination.
Security: Make sure that the design can accommodate the regular periodic installation of application security patches while maintaining the required workloads. The frequency of security patches for the proposed OS-hypervisor combination will have an impact on performance and the patch installation process could affect maintenance windows.
Supported features: Determine what features of OpenStack are required. This will often determine the selection of the OS-hypervisor combination. Certain features are only available with specific OSs or hypervisors. For example, if certain features are not available, the design might need to be modified to meet the user requirements.
Interoperability: Consideration should be given to the ability of the selected OS-hypervisor combination to interoperate or co-exist with other OS-OS-hypervisors ,or other software solutions in the overall design, if that is a requirement. Operational and troubleshooting tools for one OS-hypervisor combination may differ from the tools used for another OS-hypervisor combination. As a result, the design will need to address if the two sets of tools need to interoperate.
OpenStack Components
The selection of OpenStack components has a significant direct impact on the overall
design. While there are certain components that will always be present, (Nova and Glance, for example) there are other services that may not need to be present. As an example, a certain design may not require OpenStack Heat. Omitting Heat would not typically have a significant impact on the overall design however, if the architecture uses a replacement for OpenStack Swift for its storage component, this could potentially have significant impacts on the rest of the design.
A storage-focused design might require the ability to use Heat to launch instances with Cinder volumes to perform storage-intensive processing.
For a storage-focused OpenStack design architecture, the following components would typically be used:
Keystone Horizon
Nova (including the use of multiple hypervisor drivers) Swift (or another object storage solution)
Cinder Glance
Neutron or nova-network
The exclusion of certain OpenStack components may limit or constrain the functionality of other components. If a design opts to include Heat but exclude Ceilometer, then the design will not be able to take advantage of Heat's auto scaling functionality (which relies on
information from Ceilometer). Due to the fact that you can use Heat to spin up a large number of instances to perform the compute-intensive processing, including Heat in a compute-focused architecture design is strongly recommended.
Supplemental Software
While OpenStack is a fairly complete collection of software projects for building a platform for cloud services, there are additional pieces of software that might need to be added to any given OpenStack design.
Networking Software
OpenStack Neutron provides a wide variety of networking services for instances. There are many additional networking software packages that may be useful to manage the
OpenStack components themselves. Some examples include HAProxy, keepalived, and various routing daemons (like Quagga). Some of these software packages, HAProxy in
particular, are described in more detail in the OpenStack HA Guide (refer to Chapter 8 of the
OpenStack High Availability Guide). For a general purpose OpenStack cloud, it is reasonably likely that the OpenStack infrastructure components will need to be highly available, and therefore networking software packages like HAProxy will need to be included.
Management Software
This includes software for providing clustering, logging, monitoring, and alerting. The factors for determining which software packages in this category should be selected is outside the scope of this design guide. This design guide focuses specifically on how the selected
supplemental software solution impacts or affects the overall OpenStack cloud design.
Clustering Software, such as Corosync or Pacemaker, is determined primarily by the
availability design requirements. Therefore, the impact of including (or not including) these software packages is determined by the availability of the cloud infrastructure and the complexity of supporting the configuration after it is deployed. The OpenStack High Availability Guide provides more details on the installation and configuration of Corosync and Pacemaker, should these packages need to be included in the design.
Requirements for logging, monitoring, and alerting are determined by operational
considerations. Each of these sub-categories includes a number of various options. For example, in the logging sub-category one might consider Logstash, Splunk, instanceware Log Insight, or some other log aggregation-consolidation tool. Logs should be stored in a centralized location to make it easier to perform analytics against the data. Log data analytics engines can also provide automation and issue notification, by providing a mechanism to both alert and automatically attempt to remediate some of the more commonly known issues.
If any of these software packages are needed, then the design must account for the additional resource consumption (CPU, RAM, storage, and network bandwidth for a log aggregation solution, for example). Some other potential design impacts include:
OS - Hypervisor combination: Ensure that the selected logging, monitoring, or alerting tools support the proposed OS-hypervisor combination.
Network hardware: The network hardware selection needs to be supported by the logging, monitoring, and alerting software.
Database Software
Virtually all of the OpenStack components require access to back-end database services to store state and configuration information. Choose an appropriate back-end database which will satisfy the availability and fault tolerance requirements of the OpenStack services.
MySQL is generally considered to be the de facto database for OpenStack, however, other compatible databases are also known to work. Note, however, that Ceilometer uses
MongoDB.
The solution selected to provide high availability for the database will change based on the selected database. If MySQL is selected, then a number of options are available. For active-active clustering a replication technology such as Galera can be used. For active-active-passive some form of shared storage must be used. Each of these potential solutions has an impact on the design:
Solutions that employ Galera/MariaDB will require at least three MySQL nodes.
MongoDB will have its own design considerations, with regards to making the database highly available.
OpenStack design, generally, does not include shared storage but for a high availability design some components might require it depending on the specific implementation.
Prescriptive Examples
Storage-focused architectures are highly dependant on the specific use case. Three specific example use cases are discussed in this section: an object store with a RESTful
interface, compute analytics with parallel file systems, and a high performance database.