Certain use cases may benefit from exposure to additional devices on the compute node.
Examples might include:
High performance computing jobs that benefit from the availability of graphics processing units (GPUs) for general-purpose computing.
Cryptographic routines that benefit from the availability of hardware random number generators to avoid entropy starvation.
Database management systems that benefit from the availability of SSDs for ephemeral storage to maximize read/write time when it is required.
Host aggregates are used to group hosts that share similar characteristics, which can include hardware similarities. The addition of specialized hardware to a cloud deployment is likely to add to the cost of each node, so careful consideration must be given to whether all compute nodes, or just a subset which is targetable using flavors, need the additional customization to support the desired workloads.
Utilization
Infrastructure-as-a-Service offerings, including OpenStack, use flavors to provide
standardized views of virtual machine resource requirements that simplify the problem of scheduling instances while making the best use of the available physical resources.
In order to facilitate packing of virtual machines onto physical hosts, the default selection of
flavors are constructed so that the second largest flavor is half the size of the largest flavor in every dimension. It has half the vCPUs, half the vRAM, and half the ephemeral disk space.
The next largest flavor is half that size again. As a result, packing a server for general purpose computing might look conceptually something like Figure X:
On the other hand, a CPU optimized packed server might look like the following figure:
These default flavors are well suited to typical load outs for commodity server hardware. To maximize utilization, however, it may be necessary to customize the flavors or create new ones, to better align instance sizes to the available hardware.
Workload characteristics may also influence hardware choices and flavor configuration, particularly where they present different ratios of CPU versus RAM versus HDD
requirements.
For more information on Flavors refer to: http://docs.openstack.org/openstack-ops/content/flavors.html
Performance
The infrastructure of a cloud should not be shared, so that it is possible for the workloads to consume as many resources as are made available, and accommodations should be made to provide large scale workloads.
The duration of batch processing differs depending on individual workloads that are
launched. Time limits range from seconds, minutes to hours, and as a result it is considered difficult to predict when resources will be used, for how long, and even which resources will be used.
Security
The security considerations needed for this scenario are similar to those of the other scenarios discussed in this book.
A security domain comprises of users, applications, servers or networks that share common trust requirements and expectations within a system. Typically they have the same
authentication and authorization requirements and users.
These security domains are:
1. Public 2. Guest
3. Management 4. Data
These security domains can be mapped individually to the installation, or they can also be combined. For example, some deployment topologies combine both guest and data
domains onto one physical network, whereas in other cases these networks are physically separated. In each case, the cloud operator should be aware of the appropriate security concerns. Security domains should be mapped out against specific OpenStack deployment topology. The domains and their trust requirements depend upon whether the cloud
instance is public, private, or hybrid.
The public security domain is an entirely untrusted area of the cloud infrastructure. It can refer to the Internet as a whole or simply to networks over which the user has no
authority. This domain should always be considered untrusted.
Typically used for compute instance-to-instance traffic, the guest security domain handles compute data generated by instances on the cloud; not services that support the operation of the cloud, for example API calls. Public cloud providers and private cloud providers who do not have stringent controls on instance use or who allow unrestricted internet access to instances should consider this domain to be untrusted. Private cloud providers may want to
consider this network as internal and therefore trusted only if they have controls in place to assert that they trust instances and all their tenants.
The management security domain is where services interact. Sometimes referred to as the
"control plane", the networks in this domain transport confidential data such as
configuration parameters, usernames, and passwords. In most deployments this domain is considered trusted.
The data security domain is concerned primarily with information pertaining to the storage services within OpenStack. Much of the data that crosses this network has high integrity and confidentiality requirements and depending on the type of deployment there may also be strong availability requirements. The trust level of this network is heavily dependent on deployment decisions and as such we do not assign this any default level of trust.
When deploying OpenStack in an enterprise as a private cloud it is assumed to be behind a firewall and within the trusted network alongside existing systems. Users of the cloud are typically employees or trusted individuals that are bound by the security requirements set forth by the company. This tends to push most of the security domains towards a more trusted model. However, when deploying OpenStack in a public-facing role, no assumptions can be made and the attack vectors significantly increase. For example, the API
endpoints and the software behind it will be vulnerable to potentially hostile entities
wanting to gain unauthorized access or prevent access to services. This can result in loss of reputation and must be protected against through auditing and appropriate filtering.
Consideration must be taken when managing the users of the system, whether it is
the operation of public or private clouds. The identity service allows for LDAP to be part of the authentication process, and includes such systems as an OpenStack deployment that may ease user management if integrated into existing systems.
It is strongly recommended that the API services are placed behind hardware that performs SSL termination. API services transmit usernames, passwords, and generated
tokens between client machines and API endpoints and therefore must be secured.
More information on OpenStack Security can be found at http://docs.openstack.org/security-guide/
OpenStack Components
Due to the nature of the workloads that will be used in this scenario, a number
of components will be highly beneficial in a Compute-focused cloud. This includes the
typical OpenStack components:
OpenStack Compute (Nova)
OpenStack Image Service (Glance) OpenStack Identity Service (Keystone)
Also consider several specialized components:
OpenStack Orchestration Engine (Heat)
It is safe to assume that, given the nature of the applications involved in this scenario, these will be heavily automated deployments. Making use of Heat will be highly
beneficial in this case. Deploying a batch of instances and running an automated set of tests can be scripted, however it makes sense to use the OpenStack Orchestration Engine (Heat) to handle all these actions.
OpenStack Telemetry (Ceilometer)
OpenStack Telemetry and the alarms it generates are required to support autoscaling of instances using OpenStack Orchestration. Users that are not using OpenStack
Orchestration do not need to deploy OpenStack Telemetry and may choose to use other external solutions to fulfill their metering and monitoring requirements.
See also: http://docs.openstack.org/openstack-ops/content/logging_monitoring.html
OpenStack Block Storage (Cinder)
Due to the burstable nature of the workloads and the applications and instances that will be used for batch processing, this cloud will utilize mainly memory or CPU, so the need for add-on storage to each instance is not a likely requirement. This does not mean the OpenStack Block Storage service (Cinder) will not be used in the
infrastructure, but typically it will not be used as a central component.
Networking
When choosing a networking platform, ensure that it either works with all desired hypervisor and container technologies and their OpenStack drivers, or includes an implementation of an ML2 mechanism driver. Networking platforms that provide ML2 mechanisms drivers can be mixed.
Operational Considerations
Operationally, there are a number of considerations that affect the design of compute-focused OpenStack clouds. Some examples might include enforcing strict API availability requirements, understanding and dealing with failure scenarios, or managing host
maintenance schedules.