This is going to be an ongoing piece designed to assist new builders in in realizing the value of designing their domain ecosystem in advance. And to help showcase the interaction of the individual domain ecosystem elements and their impact on cloud infrastructure architecture.

A downloadable print version will be made available once this project is complete.

PLACEHOLDER

• Post install architecture
  • Service architecture
  • On-ramp
  • Tagging as a tool
  • Examples
  • Check-list

For details specifically on accounts and domains, please refer to the following document:

Assessing Scope (Draft 1)

The very first thing that should be done, even before installing the first piece of hardware, is to consider the end purpose of the build. I have included this in my post-install paper, because of its absolute importance. Without a clear understanding of your goals, designing a successful cloud becomes increasingly impossible. There are many features of the infrastructure that can not easily be altered after a certain point, mainly the network, but also the domain ecosystem.

Architecting Your Cloud

To begin discussing how, or even why, to build a cloud, we need to take an inventory of our goals. Lets review the list below.

• When my cloud is finished, what will I do with it?
• How many users will use my cloud?
• Is my cloud an enterprise cloud, or a personal cloud?
• Do I have a significant hardware budget, or am I just seeking a development platform?
• Will I offer public cloud services to many people, or host dedicated systems for specific clients... or both?
• Do I have any previous experience with cloud computing?
• Do I really want cloud? or just virtualization?
• Do I anticipate having a user heavy collaborative cloud, or a system heavy service cloud?
• Do I have both an infrastructure plan, and a business model, drawn out?
• Do my customers require special security considerations?
• Will I offer different security levels?

There are many more questions to be asked when building the foundation for investing in a cloud computing solution, however these are a good cross section of concerns.

Designing Domain Ecosystems (Draft 2)

Zones, Pods, Clusters, Hosts and Guests/Instances

While this can all vary based on your own design and structure, a zone can be abstracted to represent a single physical location (datacenter, city, etc). A pod is the equivalent of a rack, which would house one or multiple clusters of systems. And finally, a cluster is grouping of physical hosts which will run either bare metal or virtualized guests/instances. During VM/instance creation a user has the option to choose which zone to deploy in from a list of zones the users domain is associated with. Certain resources are shared amongst a zone, a pod, and a cluster. For examples, secondary storage is shared amongst the entire zone, whereas primary storage is shared amongst a cluster. (more descriptions need to be added here about what resources belong to zones, pods, and clusters and how they are shared)

Domains

Domains are, more or less, the equivalent of an organizational unit for those familiar with LDAP. Domains (generally) don't own resources**, but they can impose resource limits upon all accounts held within them. Domains can house projects and accounts, but domains don't really own any instances, volumes, or other resources on their own. A domain is basically a logical container for other things which can own resources such as instances, volumes, networks, snapshots, templates, etc. Domains must be unique to their parent (ROOT/dom1, ROOT/dom2, etc), however they can be duplicative if they are a child of another domain. For example, ROOT/dom1/sub1 and ROOT/dom2/sub1 are acceptable even though "sub1" is not unique to the zone, it is unique to the parent domain (dom1 and dom2, in this case).

The ROOT domain is somewhat special because all domains are a child of this parent domain. An admin account of the ROOT domain has the ability to manipulate (via the API) other resources belonging to all child domains (e.g. ALL domains) because all domains are a child of ROOT. So admin accounts of the ROOT domain have global admin privileges across your CloudStack cloud.

**In some cases with basic and advanced networking a domain can own a virtual router. When creating a network it is possible to request via the API that the network be owned by the domain and not an account. The advantage to this is that multiple accounts within a single domain can share the same virtual router to help conserve system resources (number of VLANs as well as the compute resources required for multiple virtual routers). The best example of a virtual router which is owned by a single domain but shared by multiple accounts is the virtual router in basic networking mode. In basic networking, a single virtual router is shared by all accounts within that zone.

Domain/Zone relationship

The basic and core relationship in Apache CloudStack infrastructure architecture is the many to many relationship of domains to zones. Domains are logical container, as well as a security and resource boundary. The purpose of domains is not only to house user structures, but also determine which resources those users may be assigned and impose limits on resource utilization. A single domain may have access to multiple zones by way of inheritance, or a zone may be locked to a particular domain in order to establish a private cloud. There is one core domain referred to above as the ROOT domain. It should be noted that this domain should never be used in zone assignments unless you are positive you want a public only cloud zone (basic networking). Which is to say, a zone which is accessible to ALL sub-domains. Even private clouds will see this public cloud as an option when deploying guest instances through their account. This is fine if done by design and you have a billing system in place to track the used resources by account across multiple zones. However in Best Practice, one should skip the ROOT Domain, and deploy to the next level sub-domain. At this point you can allow access to the zone publicly to customers by nesting them further down that tree, or exclude customers from using those resources by starting a new lateral domain tree.

Accounts

At the time of writing, CloudStack doesn't currently support RBAC, so permissions exist at two levels – Admin and User. Account names must be unique to a domain, but not unique to all domains (e.g. joe@foo.tld and joe@bar.tld are acceptable because although "joe" is not unique foo.tld and bar.tld are separate domains).

Admin Account

An admin account has domain admin privileges. It is still constrained to domain limitations set by the ROOT admin on that domain (# of instances permitted, # of volumes, etc) but it has more privileges. For example, a domain admin can create additional accounts within a domain or generate API keys for users. It can also create sub-domains within its own domain and report on their resource utilization. For a full list of differences please consult the CloudStack API Guide.

User Account

A user account has privileges to create and manage resources (instances, volumes, snapshots, etc) but very little administrative privileges. At this time, user accounts cannot generate API keys or additional users within their account, they can only view them. For a full list of commands available to users, please consult the CloudStack API Guide.

Usernames, Passwords, and API Keys

Usernames, passwords, and API keys belong to an account. This is the username & password you would log into the Web UI with (and if you generated an API key, the API key you would use for making API calls). Usernames must be unique to the domain they belong to (e.g. two users within the domain foo.tld cannot have the same username – you can't have two joe@foo.tld users), but they can be duplicative between multiple domains (e.g. joe@foo.tld and joe@bar.tld). Users do not own any resources, they are simply used as a means to manipulate and access resources owned by the account they are a part of. Users cannot have separate permissions between them, they inherit the permissions of the account they belong to.

Accounts and Resources

Accounts own resources. This is extremely important! Accounts own resources If you delete an account all resources associated with it (instances, volumes, snapshots, etc) will be removed as well. Usage is also tracked at an account level. So for billing or chargeback purposes, if the usage module is enabled, reporting is available for resources used at an account level.

Account/Domain relationship

Accounts can be confusing in simple deployments, as they add an unneeded level of complexity without clear purpose. Domains may contain multiple accounts in order to isolate structural boundaries in an organization. However it is quite common that a domain or sub-domain is used too as the boundary between multiple tenants, and individual tenants have dedicated administration teams whom can all exist within a single account. The value of accounts exists in shared management environments where multiple teams or departments require access to shared resources, and distinction and quotas need to be maintained. A good example would be reseller billing.

In a basic deployment it's easy to confuse accounts and users, or often end up with a single user in each account.

User/Account relationships

Users are the base organizational unit and come in two flavors, User, and Admin. The User is enabled to operate resources within an account as defined by the account admin. The Admin has full access to provision the resources assigned by the hosting agent (Root Admin). When creating a multi-user IaaS provision for a customer it is important to sit down beforehand and sketch out the customers organizational structure by assessing its departmental hierarchy as it relates to the cloud services user model. Determine if the the user groups can be accounted for in two levels, or do they require two+ levels. This will allow you to determine if sub-domains will be required. In most cases, multiple accounts can be created for site or geographical administration/user groups.

Projects

Projects are similar to accounts but unique in one special aspect. Projects can share control of resources amongst multiple accounts. The resources themselves (instances, volumes, snapshots, etc) are owned by the project and are allowed to be manipulated by multiple accounts within the same domain. For example, if there was a joint project being worked on by multiple departments within an organization a project could be created and could invite other accounts (departments in the organization) to take part in the project. With a project, one account must be delegated as the project administrator. A project admin has the ability to invite and revoke access to other accounts within the domain with regard to access on that project. A project admin only has control of the project and has no other authority over other accounts (e.g. it cannot impose account-level restrictions such as limits on the number of instances, volumes, snapshots, etc permitted), only over which accounts can access the project. While there can only be one project admin, it can be moved between accounts without affecting anything because all resources created by the project are owned by the project and not the individual accounts that are participating in it.

Projects In Relation To Organizational Structure

Projects are account level collaboration, meaning, to restrict account users from accessing a project, you must move those users to another account. The user of projects can affect the organizational design when factoring in collaboration needs between a customers departments so it is important to understand their role and uses.

Practical user models (Appendix)

This image is for illustrative purposes only as it clearly violates my best practice recommendation of not populating the root domain.

Large Scale Organization

In this model, the ROOT Domain is restricted to the primary service provider. The companies ACME 1-4 all have resources in a zone called Public Cloud which allows sub-domain access. This is a domain for shared multi-tenant infrastructure, and all the public cloud companies have sub-domains under it. ACME 4 also has a private zone they purchase or potentially own that is tied to the ACME 4 Private domain. This domain can access resources from its private zone AND the public zone tied to the Public Cloud domain. However, members and sub-domains of the Public Cloud domain can NOT access resources from ACME 4's Private dedicated zone. ATC is a company which purchases all of their infrastructure from the primary service provider and has several organizational units which depend on it. Developers and IT share a project pool but still have discrete resources from their ATC domain accounts. Engineering is a separate branch of the company and requires complete user isolation from the main branch even though they all share common resources in their private cloud zone. This is why Engineering uses host, storage, and network tags to ensure their sensitive machine run on dedicated hardware, and isolated storage.