System Center 2012 R2 Explained: Creating Private Clouds and Deploying Services with System Center 2012 R2 Virtual Machine Manager

아티클
04/19/2013

There are two abstractions, Private Cloud and Service, in VMM directly relevant to an application deployment. Here VMM considers a service as an instance of an application which may consists of a set of VMs to form the application architecture. While a Private Cloud is a container in VMM for deploying services. To better understand the deployment process and associated settings in VMM, these two abstractions are crucial.

Private Cloud and Service

Specific in VMM, these two abstractions are complementary and coupled. A private cloud is a home of a service. A service only lives in a private cloud. While a private cloud may not yet have a service deployed, the existence of a service denotes a target private cloud is in place.

Private Cloud as Defined in System Center 2012 R2

It is a logical container for deploying services. This container is configured with a set of constraints (on resource consumption and access control) which a deployed service is automatically imposed upon. A private cloud by itself has not much meaning, it is just an artifact with a set of variables and parameters. Only when a private cloud is hosting a service, the cloud becomes functional, enforcing, and significant. In the context of VMM, one should distinguish a private cloud itself from a service running in a private cloud. And they are not to be used interchangeably.

Service as Defined in System Center 2012 R2

A service is an application instance which may consist of a set of VMs (representing an application architecture)collectively delivering a business function. This set of VMs can be identified, operated, and managed as one logical entity. In my view, this abstraction is critical for Microsoft private cloud implementations.”

Since VMM can deploy a set of VMs forming the application architecture as one logical entity, the processes, tasks, operations, and interdependencies of configuring a target and possibly distributed runtime environment (i.e. platform) and the subsequent installation process of an intended application possibly spreading among multiple VMs can then be serialized, as needed, and orchestrated. The ability to manage an entire set of VMs as one entity makes transitioning from IaaS, to PaaS, and then SaaS possible. In other words, a service deployment to a private cloud in VMM can start with first creating a set of VMs representing the application architecture (IaaS) followed by configuring the runtime (PaaS), and finish with installing and substantiating an intended application instance (SaaS). This service-based deployment is essentially an SaaS offering which is the ultimate goal of cloud computing and what a cloud service consumer wants and expects.

With the understanding of a private cloud, a service, and their relationship in mind, the strategy is to delegate authority to a private cloud, i.e. the container, which will then automatically apply to those services deployed to the cloud.

Create/Configure Private Cloud (Container)

In VMs and Services workspace of VMM admin console, create a private cloud (container) as shown on the left and set the constraints and access control as intended. The defense-in-depth strategy on security, resource consumption, manageability in general is very obviously integrated into VMM everywhere. A constraint can be set in a cloud, a service, a template, a user role, etc. i.e. various logical layers, based on needs.

Delegating Authority

The security tools for delegating authority including RunAs account and user roles profiles in the Settings workspace of VMM Admin Console.

RunAs Account

There are scenarios that an authorized user or service may need an elevated right. Rather than giving out the credentials of a privileged account, a VMM admin can create a RunAs account with the privileged account’s credentials and offered the RunAs account instead. A RunAs account is similar to a symbolic name linked to a protected account to eliminate the needs to share out the credentials of the protected account. The following is a sample.

Role-Based Security

A user role profile in VMM security model is in essence a set of policies on who can do/consume what, when, and how much. A user with an assigned user role will be subjected to the policies upon bring authenticated by VMM. This model enables a VMM admin to map a business or functional role with a set of security policies. The logical steps to create a user role include:

First Plan Your Delegation of Authority

This is basically to identify the functional requirements of a business role relevant to access control and constraints on a target cloud. And notice the considerations here are from a service provider’s view point, while the customers/consumers are those who own/develop/deploy/manage an examined service deployed to a target cloud.
Translate the Delegation of Authority into Role-Based Security Model

There are four user role profiles as shown below left presented in VMM Settings workspace when creating a user role. Map the business functions of a role into an intended user role profile. Considering a typical service deployment, for example, there are business functional roles as shown below right.

Architecture Owner defines the solution architecture/infrastructure and needs the access to all including running instances and everything above and below fabric relevant to a service, hence this role is with a delegated administrator user role profile.

Service Owner owns a deployment and cares about keeping a service up and running to fulfill an SLA, and not so much about what is technically happening under the hood. A tenant administrator user role profile fits well.

Application Admin supports the service by performing basic support and maintenance routines, and escalates issues to Service Owner as needed. A self-service user role profile with proper scope of actions will work.

Here is a set of sample settings of a user role.

Notice that in VMM the delegation of authority can be scoped only at a private cloud level which then implicitly applies to a service deployed to the cloud.

Deploy Services into Private Cloud or Host Group

In VMM 2012 R2, a service or a VM is to be deployed with a service template or a VM template, respectively. A template is a cookie cutter with definitions, processes, configurations, and operations of deploying a resource. Deployment based on a template can provide consistency and predictability on runtime independent configurations like hardware settings, added server roles and features, application installation procedures, upgrade domains, scalability, etc.

The above left shows a service template is to be configured for deployment first with the service template designer and the above right depict the user experience on specifying a destination for the deployment.

Verify Delegation of Authority with App Controller and VMM Admin Console

Upon successful deploying a service, a VMM admin can log in App Controller as shown below left or VMM Admin Console as shown below right with an intended user role and verify the delegation of authority. In this case, a VMM admin will need to assign herself with the intended role, and in the log-in process there will be then an opportunity to specify an intended user role.

다음을 통해 공유