Answers to the Quiz
Estimated reading time: 5 minutes.
Multi-Tenancy and Topology in Red Hat OpenStack
-
An OpenStack Administrator needs to support, on the same cluster, two business units that used to be independent companies, before a merger, and must continue using each their legacy enterprise authentication system and each have their own team of OpenStack Operators. How can OpenStack support this requirement?
-
Each business unit requires its own domain.
Correct: Each domain can refer to different enterprise authentication systems and manage role assignment independent of other domains. -
Each business unit requires its own projects.
Incorrect: Projects cannot refer to external authentication backends, but users from multiple domains can be granted access to a project, so this is not entirely incorrect, just not sufficient. -
Each business unit requires its own cluster.
Incorrect: OpenStack provides features that enable multiple tenant sharing on a single cluster. -
Each business unit requires its own region.
Incorrect: OpenStack provides features that enable multiple tenant sharing on a single cluster, and regions are their own clusters. -
Each business unit requires its own AZ.
Incorrect: Workloads from any project, and users from any domain, can use compute resources from any AZ. -
Each business unit requires its own host aggregate.
Incorrect: Workloads from any project, and users from any domain, can use compute resources from any host aggregate. Restricting visibility of server flavors to indirectly restrict visibility of compute nodes would be an inefficient way of meeting the requirement and more labor intensive. -
Each business unit requires its own cell. Incorrect: Workloads from any project, and users from any domain, can use compute resources from any compute cell.
-
-
An OpenStack Operator needs to configure a multi-instance workload to be resilient against physical failures of network switches and uninterrupted power supplies (UPS) which are dedicated to a server rack. The data center was designed with multiple server racks, and each rack has its dedicated network switch and UPS devices. Assuming that an Administrator already configured the proper tenancy and topology mechanism, how would the operator configure its workloads?
-
By spreading server instances over multiple domains.
Incorrect: Domains are not cluster topology mechanisms in OpenStack. -
By spreading server instances over multiple projects.
Incorrect: Domains are not cluster topology mechanisms in OpenStack. -
By spreading server instances over multiple clusters.
Incorrect: Workloads deployed on independent OpenStack clusters must be managed as independent workloads, which can be done, but not with OpenStack alone. The scenario also admits a simpler solution using OpenStack capabilities. -
By spreading server instances over multiple regions. Incorrect: It would be overkill configuring multiple OpenStack clusters, as different regions, on the same data center building, and anyway OpenStack alone cannot schedule and manage workloads spreading multiple regions.
-
By spreading server instances over multiple AZs.
Correct: Availability Zones (AZs) are the common topology mechanism for representing failure domains such as server racks in the scenario. -
By spreading server instances over multiple host aggregates.
Incorrect: Operators cannot directly match workloads to host aggregates like they can do with regions and AZs. -
By spreading server instances over multiple cells. Incorrect: Operators cannot directly match workloads to compute cells, like they can do with regions and AZs.
-
-
An OpenStack Operator has the member role in a project and found that the team of developers working on that project is very knowledgeable about OpenStack and wishes to allow the team more autonomy managing API resources for their application. Can that operator grant those developers permission to manage API resources on their project?
-
Yes
Incorrect: The member role does not enable a user to assign roles and grant permissions to other users. -
No
Correct: The operator would require the admin role on the project or its domain to assign roles and grant permissions to other users.
-
-
An OpenStack Administrator team is concerned about "noisy neighbor" issues between applications from different teams sharing an OpenStack cluster, where one team uses too much compute capacity of the cluster and makes all other teams get lower performance from their applications. They decide to set a limit to the number of server instances in each and every project. Will this solve "noisy neighbor" issues?
-
Yes
Incorrect: Setting quotas in a project is the correct approach but API resource quotas alone will not be sufficient. -
No
Correct: An API resource quota on the number of server instances is not sufficient because each server could use multiple vCPUs and, without a compute resource quota on that, a small number of server instances could use all CPU cores in all compute nodes of the cluster.
-
-
An OpenStack Administrator created two host aggregates: one for physical machines with GPUs and another for physical machines with large memory. Some machines have both GPUs and large memory, should the administrator create a third host aggregate for those machines?
-
Yes
Incorrect: Nothing prevents administrators from creating such host aggregate but it is not necessary. -
No
Correct: Compute nodes can belong to multiple host aggregates, so a physical server with both GPUs and very large memory would belong to both host aggregates simultaneously.
-