Test Post

Published: August 2, 2013
Version: 1.0

[toc]

For the latest information, see the Hybrid IT Infrastructure Solution for Enterprise IT article set. To provide feedback on this article, leave a comment at the bottom of this article or send e-mail to SolutionsFeedback@Microsoft.com.  To easily save, edit, or print your own copy of this article, please read How to Save, Edit, and Print TechNet Wiki Articles. When the contents of this article are updated, the version is incremented and changes are entered into the change log. The online version is the current version. This article discusses technologies listed in the Technologies Discussed section of this article.

1.0 Introduction

This article is one of several articles that are included in an integrated article set called the Hybrid IT Infrastructure Solution for Enterprise IT. If you haven’t already, before reading this article, please read the Introduction article within this article set, as it provides an overview of the article set as a whole, introduces the domain and audience that it is written for, and defines the articles contained within it.
This article details which specific products, technologies, and configuration options were selected, out of the hundreds of individualy available options, to meet the unique requirements for the example organization defined in the Scenario Definition article. This article also details the rationale for why specific design decisions were made. For organizations that have similar requirements and constraints as the example organization, the lab-tested design and rationale in this article can help decrease both the implementation time and risk of implementing a custom hybrid IT infrastructure solution. This article is most helpful to those responsible for designing a hybrid IT infrastructure or implementing solutions within enterprise IT organizations, since it details an example design, and the rationale for the design.
If instead of, or in addition to, only understanding one example hybrid IT infrastructure design, and the rationale for the design options selected for it, you’d like to understand all of the relevant individual design configuration options for hybrid IT infrastructure solutions so that you can determine which options are most appropriate for your own, unique requirements, then it’s recommended that you read the Hybrid IT Infrastructure Design Considerations Guide for Enterprise IT article. While the Hybrid IT Infrastructure Design Considerations for Enterprise IT article details all available Microsoft product and technology design options and considerations for hybrid IT infrastructure solutions, it does not provide any example designs or recommendations for specific requirements. Many people will find it helpful to read both the Design article (this article you're reading now) for the RI article set targeted to an organization similar to their own, as well as the Design Considerations article for the hybrid IT infrastructure problem domain. Others will only find it necessary to read one article or the other. Though the two articles are related, there are nodependencies between them.

2.0  Conceptual Design

With a clear understanding of its consumer and environmental requirements, Contoso started its solution design. Before selecting products and technologies to implement its solution with however, it started with a conceptual design. The conceptual design provides Contoso a vendor-agnostic architectural foundation that helps it ultimately select the best products and technologies to implement its conceptual design. The sections that follow detail the different aspects of Contoso’s conceptual design.

2.1 Reference Model

The first design artifact Contoso decided to create for its hybrid IT infrastructure was a vendor-agnostic reference model. They wanted the reference model to serve as a common definition of the capabilities and functions their hybrid IT infrastructure would provide. Though from Microsoft, Contoso already uses the vendor-agnostic Microsoft Cloud Services Foundation Reference Model (CSFRM) as a foundation for its IT environment as a whole, so it first defined where in that model this new service fits best The figure below illustrates the Microsoft CSFRM and where Contoso’s hybrid IT infrastructure fits into it. Note the technical capabilities that have the yellow border. Those are the areas that are covered in Contoso's hybrid IT infrastructure design and are discussed in detail in this article.

Note: Further explanation of the Microsoft CSFRM is not included in this article. If you’re interested in understanding it further however, you’re encouraged to read the Microsoft Cloud Services Foundation Reference Model (CSFRM) article, which is part of the Microsoft Cloud Services Foundation Reference Architecture (CSFRA) article set.

As a result of this positioning of its hybrid IT infrastructure within the broader Microsoft CSFRM, the service inherits all of the existing relationships represented in the CSFRM. In addition to positioning the hybrid IT infrastructure within the Microsoft CSFRM, Contoso then defined a reference model for a hybrid IT infrastructure itself.

2.2  Principles

Contoso defined some principles for its service to serve as a set of guidelines for designing their service. Just as they utilize the Microsoft CSFRM as their foundational reference model, they also use the principles defined in the Microsoft CSFRA Principles, Concepts, and Patterns article as a foundational set of principles in their environment. The principles that Contoso defined are a combination of applied relevant principles from the Microsoft CSFRA, as well as unique principles for a hybrid IT infrastructure in their environment.

Hybrid IT infrastructure principles include:

• Achieve business value through measured continuous improvement. The productive use of technology to deliver business value should be measured by a process of continual improvement. This is true for any type of cloud solution. In a hybrid IT infrastructure, you want to be confident that the public cloud infrastructure service provider is continually working to improve the service, and the provider should be able to provide evidence of those improvements over time.

• Perception of infinite capacity. From the consumer’s perspective, a cloud service should provide capacity on demand that is limited only by the amount of capacity the consumer is willing to pay for. In a hybrid IT infrastructure, you need to provide the consumers of your hybrid cloud services with the resources they need, when they need them, and there should be no perception by the consumer that there is some hard-coded limitation on what they can acquire or purchase. The same should be true of the cloud infrastructure service provider.

• Perception of continuous service availability. From the consumer’s perspective, a cloud service should be available on demand from anywhere and at any time. In a hybrid IT infrastructure, the consumers of your service should never experience any downtime, regardless of inevitable transient failure states that might occur to components of the hybrid IT infrastructure. Components should be able to fail without impacting your service as a whole.

• Take a service provider’s approach. The provider of a cloud should think and behave as if he is running a service provider business rather than an IT department within an enterprise. In a hybrid IT infrastructure, you should seek to establish well defined boundaries between the IT organization running the hybrid cloud infrastructure and the consumers of that infrastructure. In practice, that means that you provide a service offering that contains a defined service catalog. Consumers of the service will select options from the service catalog only, and are not empowered to ask for custom infrastructure to support a particular application or service. In addition, as a service provider, you will provide SLAs around the service that you provide, but have no responsibility for any services that run on the hybrid IT infrastructure, unless that is part of your explicit service offering. From the perspective of the public cloud infrastructure service provider, by definition that will always take a service provider's approach, as this is their core competency.

• Optimize resource usage. The cloud should automatically make highly efficient use of infrastructure resources. In a hybrid IT infrastructure, you can optimize resource usage by taking advantage of the efficiencies that the public cloud infrastructure service provider exposes to you. Make sure to acquire what you need, and then release the resources back into the provider’s cloud when you no longer need them. The same applies to your private cloud infrastructure if you are connecting a private cloud to a service provider’s cloud.

• Take a holistic approach to availability design. The availability design for a cloud solution should involve all layers of the stack, employ resilience wherever possible, and remove redundancy that is unnecessary. In a hybrid IT infrastructure, you must be confident that the public cloud infrastructure service provider has an availability design that isn’t dependent on redundancy, but instead relies on resiliency. However, this requires that the applications that you move to the cloud infrastructure service provider are stateless applications. If your hybrid IT infrastructure requires support for stateful applications in the service provider’s cloud, then your cloud infrastructure service provider will need to enable support for stateful applications as part of its service offering. A similar approach should be applied if you run an on-premises private cloud infrastructure.

• Minimize human involvement. The day-to-day operations of a cloud should require minimal human involvement. In a hybrid IT environment, your interface with the cloud infrastructure service provider should be through some type of online portal, where you can acquire and release resources either on demand or through a policy based, automated process. In addition, all reporting and logging information should also be available in a self-service manner so that you will not need to talk to a human operator. On the on-premises side of the hybrid cloud infrastructure, you need to define the level of human involvement you want to enable, because enterprise IT works a bit differently than what is done in a pure public cloud service provider scenario. The difference between enterprise IT and a public cloud infrastructure service provider is based on their different missions: enterprise IT exists to serve the profitability of the business units it supports, while the public cloud infrastructure service provider's main objective is to serve its own profitability goals.

• Drive predictability. A cloud must provide a predictable environment, as the consumer expects consistency in the quality and functionality of the services they consume. In a hybrid IT infrastructure, you must have assurances that the public cloud infrastructure service provider can provide a level of predictability that enables you to support the SLAs you establish with the consumers of your cloud infrastructure. If you run a private cloud on premises, you need to also provide the same level of predictability, so that the infrastructure as a whole provides predictable levels of service to the consumers of the hybrid IT infrastructure.

• Incentivize desired behavior. IT will be more successful in meeting business objectives if the services it offers are defined in a way that incentivizes desired behavior from the service consumer. Your public cloud infrastructure service provider incentivizes you to use only the resources that you need by providing a tiered pricing structure that is based on your level of consumption. Service providers can also make controls available so that you can define when some components of the service should be retired, and those components (network, storage and compute resources) can be returned to the shared pool of resources. In the same way, you can incentivize the users of the hybrid cloud infrastructure to use only what they require by enabling chargeback or showback and making it easy for them to release unneeded capacity back into the shared pool.

• Create a seamless user experience. Consumers of an IT service should not encounter anything that disrupts their use of the service as a result of crossing a service provider boundary. In a hybrid IT infrastructure, consumers of your cloud services should not be confronted with different interfaces that might expose to them the location of the infrastructure services that they are consuming. It is a key tenet of cloud computing that the underlying infrastructure is abstracted from the consumer and that the consumer only needs to know that the service is provided. When designing your service catalog and self-service portal, try to avoid exposing the location of the services. Instead, only provide options that relate to how a service is provisioned. For example, if the consumer of the hybrid IT infrastructure has a choice to indicate that they will be deploying a Low Business (LBI) solution, then those components that are tagged as LBI can be hosted in the public cloud infrastructure provider’s network.

2.3  Concepts

Contoso defined some concepts for its service. These concepts are abstractions or strategies that support the principles that they defined. They are guided by, and directly support, one or more of their principles. Just as they utilized the principles within the Microsoft CSFRA as a foundation for defining their own principles, they used the concepts within the Microsoft CSFRA as a foundation for defining their concepts.

Contoso used the following concepts to support the principles driving their hybrid IT infrastructure:

• Predictability. Traditionally, IT has often provided unpredictable levels of service quality. This lack of predictability hinders the business from fully realizing the strategic benefit that IT could provide. As public cloud offerings emerge, businesses may choose to utilize public offerings over internal IT in order to achieve greater predictability. Enterprise IT must provide a predictable service on par with public offerings in order to remain a viable option for businesses to choose.

• Favor resiliency over redundancy. In order to achieve the perception of continuous availability, a holistic approach must be taken in the way availability is achieved. Traditionally, availability has been the primary measure of the success of IT service delivery and is defined through service level targets that measure the percentage of uptime. However, defining the service delivery success solely through availability targets creates the false perception of “the more nines the better” and does not account for how much availability the consumers actually need.

• Homogenization of physical hardware. Homogenization of the physical hardware is a key concept for driving predictability. The underlying infrastructure must provide a consistent experience to the hosted workloads in order to achieve predictability. This consistency is attained through the homogenization of the underlying servers, network, and storage.

• Pool compute resources. Leveraging a shared pool of compute resources is key to cloud computing. This Resource Pool is a collection of shared resources composed of compute, storage, and network that create the fabric that hosts virtualized workloads. Subsets of these resources are allocated to the customers as needed and conversely, returned to the pool when they are not needed. Ideally, the Resource Pool should be homogeneous. However, as previously mentioned, the realities of a customer’s current infrastructure may not facilitate a fully homogenized pool.

• Virtualized infrastructure. Virtualization is the abstraction of hardware components into logical entities. Although virtualization occurs differently in each infrastructure component (server, network, and storage), the benefits are generally the same including lesser or no downtime during resource management tasks, enhanced portability, simplified management of resources, and the ability to share resources. Virtualization is the catalyst to the other concepts, such as Elastic Infrastructure, Partitioning of Shared Resources, and Pooling Compute Resources. The virtualization of infrastructure components needs to be seamlessly integrated to provide a fluid infrastructure that is capable of growing and shrinking, on demand, and provides global or partitioned resource pools of each component.

• Fabric management. Fabric is the term applied to the collection of compute, network, and storage resources. Fabric Management is a level of abstraction above virtualization; in the same way that virtualization abstracts physical hardware, Fabric Management abstracts service from specific hypervisors and network switches. Fabric Management can be thought of as an orchestration engine, which is responsible for managing the life cycle of a consumer’s workload. In a cloud, Fabric Management responds to service requests, Systems Management events and Service Management policies.

• Elastic infrastructure. The concept of an elastic infrastructure enables the perception of infinite capacity. An elastic infrastructure allows resources to be allocated on demand and more importantly, returned to the Resource Pool when no longer needed. The ability to scale down when capacity is no longer needed is often overlooked or undervalued, resulting in server sprawl and lack of optimization of resource usage. It is important to use consumption-based pricing to incent consumers to be responsible in their resource usage. Automated or customer request based triggers determine when compute resources are allocated or reclaimed.

• Partitioning of shared resources. Sharing resources to optimize usage is a key principle; however, it is also important to understand when these shared resources need to be partitioned. While a fully shared infrastructure may provide the greatest optimization of cost and agility, there may be regulatory requirements, business drivers, or issues of multi-tenancy that require various levels of resource partitioning. Partitioning strategies can occur at many layers, such as physical isolation or network partitioning. Much like redundancy, the lower in the stack this isolation occurs, the more expensive it is.

• Resource decay. Treating infrastructure resources as a single Resource Pool allows the infrastructure to experience small hardware failures without significant impact on the overall capacity. Traditionally, hardware is serviced using an incident model, where the hardware is fixed or replaced as soon as there is a failure. By leveraging the concept of a Resource Pool, hardware can be serviced using a maintenance model. A percentage of the Resource Pool can fail because of “decay” before services are impacted and an incident occurs. Failed resources are replaced on a regular maintenance schedule or when the Resource Pool reaches a certain threshold of decay instead of a server-by-server replacement.

• Service classification. Service classification is an important concept for driving predictability and incenting consumer behavior. Each service class will be defined in the provider’s service catalog, describing service levels for availability, resiliency, reliability, performance, and cost. Each service must meet pre-defined requirements for its class. These eligibility requirements reflect the differences in cost when resiliency is handled by the application versus when resiliency is provided by the infrastructure.

• Cost transparency. Cost transparency is a fundamental concept for taking a service provider’s approach to delivering infrastructure. In a traditional data center, it may not be possible to determine what percentage of a shared resource, such as infrastructure, is consumed by a particular service. This makes benchmarking services against the market an impossible task. By defining the cost of infrastructure through service classification and consumption modeling, a more accurate picture of the true cost of utilizing shared resources can be gained. This allows the business to make fair comparisons of internal services to market offerings and enables informed investment decisions.

• Consumption based pricing. This is the concept of paying for what you use as opposed to a fixed cost irrespective of the amount consumed. In a traditional pricing model, the consumer’s cost is based on flat costs derived from the capital cost of hardware and software and expenses to operate the service. In this model, services may be over or underpriced based on actual usage. In a consumption-based pricing model, the consumer’s cost reflects their usage more accurately.

• Security and identity. fill this in.

• Multitenancy. Multitenancy refers to the ability of the infrastructure to be logically subdivided and provisioned to different organizations or organizational units. The traditional example is a hosting company that provides servers to multiple customer organizations. Increasingly, this is also a model being utilized by a centralized IT organization that provides services to multiple business units within a single organization, treating each as a customer or tenant.

2.4 Patterns

Contoso regularly uses design patterns when implementing new services into their environment because they provide proven, common solutions to common problems. They determined that the patterns listed below were applicable to their solution and chose to utilize them in their design.

• Resource pooling. The Resource Pool pattern divides resources into partitions for management purposes. Its boundaries are driven by Service Management, Capacity Management, or Systems Management tools. Resource pools exist for either storage (Storage Resource Pool) or compute and network (Compute Resource Pool). This de-coupling of resources reflects that storage is consumed at one rate while compute and network are collectively consumed at another rate.

• Physical fault domain. It is important to understand how a fault impacts the Resource Pool, and therefore the resiliency of the VMs. A datacenter is resilient to small outages such as single server failure or local direct-attached storage (DAS) failure. Larger faults have a direct impact on the datacenter’s capacity so it becomes important to understand the impact of a non-server hardware component’s failure on the size of the available Resource Pool.

• Upgrade domain. The upgrade domain pattern applies to all three categories of datacenter resources; network, compute, and storage. Although the VM creates an abstraction from the physical server, it doesn’t obviate the requirement of an occasional update or upgrade of the physical server. The Upgrade Domain pattern can be used to accommodate this without disrupting service delivery by dividing the Resource Pool into small groups called Upgrade Domains. All servers in an Upgrade Domain are maintained simultaneously, and each group is targeted in turn. This allows workloads to be migrated away from the Upgrade Domain during maintenance and migrated back after completion.

• Reserve capacity. The advantage of a homogenized Resource Pool-based approach is that all VMs will run the same way on any server in the pool.  This means that during a fault, any VM can be relocated to any physical host as long as there is capacity available for that VM.  Determining how much capacity needs to be reserved is an important part of designing a private cloud.  The Reserve Capacity pattern combines the concept of resource decay with the Fault Domain and Upgrade Domain patterns to determine the amount of Reserve Capacity a Resource Pool should maintain.

• Scale unit. At some point, the amount of capacity used will begin to get close to the total available capacity (where available capacity is equal to the total capacity minus the Reserve Capacity) and new capacity will need to be added to the datacenter. Ideally, the architect will want to increase the size of the Resource Pool to accommodate the capacity in standardized increments, with known environmental requirements (such as space, power, and cooling), known procurement lead time, and standardized engineering (like racking, cabling, and configuration). Further, this additional capacity needs to be a balance between accommodating the growth, while not leaving too much of the capacity unutilized. To do this, the architect will want to leverage the Scale Unit pattern.

• Capacity plan. The Capacity Plan pattern utilizes the infrastructure patterns described above along with the business demand to ensure the perception of infinite capacity can be met. The capacity plan pattern cannot be built by IT alone but must be built and regularly reviewed and revised in conjunction with the business.

• Health model. To ensure resiliency, a datacenter must be able to automatically detect if a hardware component is operating at a diminished capacity or has failed. This requires an understanding of all of the hardware components that work together to deliver a service, and the interrelationships between these components. The Health Model pattern is the understanding of these interrelationships that enables a management layer to determine which VMs are impacted by a hardware component failure, facilitating the datacenter management system to determine if an automated response action is needed to prevent an outage, or to quickly restore a failed VM onto another system.

• Service class. Service Class patterns are useful in describing how different applications interact with the cloud platform infrastructure. While each environment may present unique criteria for their service class definitions, in general there are three Service Class patterns that describe most application behaviors and dependencies.

• Cost model.  Cost Model patterns are a reflection of the cost of providing services in the cloud and the desired consumer behavior the provider wishes to encourage. These patterns should account for the deployment, operations, and maintenance costs for delivering each service class, as well as the capacity plan requirements for peak usage and future growth. Cost model patterns must also define the units of consumption. The units of consumption will likely incorporate some measurement of the compute, storage, and network provided to each workload by Service Class. This can then be used as part of a consumption-based charge model. Organizations that do not use a charge back model to pay for IT services should still use units of consumption as part of notional charging. (Notional charging is where consumers are made aware of the cost of providing the services they consumed without actually billing them.)

3.0 Physical Design

Contoso evaluated multiple available products, technologies, and services to determine which would best help them meet their requirements and the conceptual design they created for their hybrid IT infrastructure.
The table below lists the products and technologies that Contoso chose to implement various entities from the reference model it defined.

Reference model entity

Product/technology/external service

Network (support and services)

• Azure Virtual Networks (AVN)
• Windows Server 2012 DNS services

Authentication (support and services)

• Active Directory Domain Services (AD DS)
• Windows Azure Active Directory (WAAD)

Directory (support and services)

• Active Directory Domain Services (AD DS)
• Windows Azure Active Directory (WAAD)

Compute (support and services)

• Azure Infrastructure Services Virtual Machines (AIS VMs)

Storage (support and services)

• Azure Infrastructure Services blob storage

Network infrastructure

• On premises VPN gateway
• Existing on-premises network infrastructure
• Windows Azure Virtual Networks

Compute infrastructure

• Existing on-premises compute infrastructure—could be traditional data center, virtualized datacenter, or private cloud
• Windows Azure Virtual Machines

Storage infrastructure

• Existing on-premises storage infrastructure
• Azure Infrastructure Services storage infrastructure

After selecting the products, technologies, and services to implement the hybrid IT infrastructure, Contoso continued the design of its solution. The sections that follow outline the design decisions that Contoso made after evaluating hundreds of available options. The decisions are aligned into groupings that align to the CSFRM as much as possible, but also attempt to follow a top-down design approach, although every design process is iterative. Contoso iterated through design decisions they made in many of the sections that follow, as well as went back and forth with their consumers and their requirements, before finalizing both their requirements and their design. The final requirements are detailed in the Scenario Definition article within this article set. The final design is detailed in the sections that follow.

3.1 Overview

As outlined in the Scenario Guide, Contoso is a multi-national manufacturing company that has it's headquarters in the Southwest United States. The company has begun its journey into cloud computing and has completed the first phase of it's private cloud infrastructure project, which was based on the information they learned from the Cloud Infrastructure Solution for Enterprise ITguidance set. Contoso was about to start building out the fabric management components of their private cloud infrastructure as part of phase 2 of that project when they became aware of the existence of Azure Infrastructure Services (AIS). Contoso's leadership team had read Microsoft's Economics of the Cloud Whitepaper and confirmed the conclusions drawn in that paper. For this reason, they directed Contoso IT to delay completing phase 2 of the private cloud infrastructure project and create a design and pilot implementation of a hybrid IT project.

Contoso IT decided that they would start a hybrid IT infrastructure project that would help them answer critical design issues around hybrid IT. Prior to the project they had little insight into what the primary design issues are for a hybrid IT infrastructure. Fortunately, they found the Hybrid IT Infrastructure Considerations Guide for Enterprise IT. This guide provided them with a comprehensive list of questions that they need to answer in order to create a hybrid IT infrastructure that would meet their requirements. You can find Contoso's requirements for their hybrid IT infrastructure in the Scenario Definition article.

Similar to their private cloud project, Contoso IT has decided that they will break the project into two phases. The first phase will focus on the physical design and implementation and the second phase will include the bulk of the management and support components, as defined in the Cloud Services Foundation Reference Architecture. This Design Guide focuses on phase one with a focus on the hybrid IT infrastructure's physical design.

After reading the Hybrid IT Infrastructure Considerations Guide for Enterprise ITContoso had the information they needed to make the key design decisions that would enable them to create their initial implementation for a hybrid IT infrastructure. The figure below is a diagram of the physical design for Contoso's hybrid IT infrastructure solution.

Figure X: Contoso's Hybrid IT Infrastructure [ContosoArch.png]

Contoso IT will deploy an application to the hybrid IT infrastructure to test the viability of the initial design. The is a simple two-tier application that they currently have running on-premises. The application includes a front-end web tier and a back-end database tier. Contoso has classified the application as a low business impact (LBI) application. They chose an LBI application because they wanted to start with a low risk asset as they learn more about designing, planning, implementing and managing a hybrid IT infrastructure. In subsequent phases of the project, they will integrated more robust management and automation elements to the hybrid IT infrastructure design.

Contoso has decided to use Microsoft Azure Infrastructure Services as their public cloud infrastructure services provider. The sections that follow detail every design decision made by Contoso IT for their hybrid IT infrastructure, as well as the rationale for why each design decision was made.

3.2 Service Account Acquisition and Billing Considerations for Public Cloud Infrastructure Design Decisions

Contoso has several payment plan options from which they can choose from when using Azure Infrastructure services. They decided to begin their hybrid IT infrastructure project with a "pay as you go" plan. After they determine what the cost model will be, Contoso will move to a the "pay monthly for six months" plan and once they move into full production they will finalize on the "pay monthly for twelve months" plan. They made these decisions based on wanting to begin the project slowly and decided a conservative approach would work best early on. As they gain more experience, they will move to payment plans that increase their financial level of commitment to the public cloud infrastructure service provider.

Contoso needs to decide if they will use one or more subscriptions and how many billing accounts they want to manage. To simplify billing management, they have decided to use a single billing account.  The billing account will be assigned to the Director of Contoso IT. They have also decided that the single billing account will pay for multiple subscriptions. These decisions was made based on issues related to granularity of access, organization of resources, and project billing, all of which are simplified by using a single billing account with multiple subscriptions. Contoso IT plans on starting with a single subscription and plan on adding a development subscription in the future.

DESIGN DECISIONS:
-Begin  with a "pay as you go" payment plan
-Use a single billing account managed by the Directory of Contoso IT
-Establish separate subscriptions that are based on project
-Begin with a single subscription

3.3 Network

Contoso currently has a well designed network infrastructure that is managed by its networking team and they have determined that for the most part, they will have to make very few changes to their underlying networking infrastructure and support model. However, there are a few decisions that they have to made regarding connectivity to resources hosted on the public cloud infrastructure service provider's network. These include:

• Network connectivity between on-premises and off-premises resources
• Inbound connectivity to the public cloud infrastructure service network
• Load balancing of inbound connection to virtual machines in the public infrastructure service network
• Name resolution for the public infrastructure service network

The remainder of this section will discuss design decisions Contoso made in each of these areas.

3.3.1 Network Connectivity Between On-Premises and Off-Premises Resources

Contoso needs to connect the corporate network to resources in the Azure Virtual Network (AVN). They have decided to use a site-to-site VPN connection to connect the networks. The reason for this is that Contoso needs full bidirectional connectivity and enterprise level name resolution for resources connecting both to and from the AVN.

DESIGN DECSIONS:
-Contoso will establish a site-to-site VPN between the corporate network and the Windows Azure Virtual Network

3.3.2 Inbound Connectivity to the Public Cloud Infrastructure Service Network Design Decisions

Contoso needs to decide the best approach for inbound access to public cloud infrastructure service hosted resources in the AVN. They examined their options and decided that all inbound access for client systems would be done over the Internet. This includes systems that are connecting from both on and off premises. This will simplify the DNS configuration so that a split DNS is not required.

Inbound access to resources hosted in the AVN for management systems will not be done over the Internet. Because management access requires access to the operating system themselves, Contoso has decided that all management activity must be source from management workstations and services within the corporate network. Management workstations and services must be physically located on the corporate network, or they must be connected to the corporate network over VPN or DirectAccess.  This decision is driven by Contoso's security team who requires that all management access must be done from authorized systems located on the corporate network.

DESIGN DECISIONS:
-All client access to resources located on the Azure Virtual Network is done over the Internet
-All management access to resources located on the Azure Virtual Network is done from the corporate network

3.3.3 Load Balancing of Inbound Connections to Virtual Machines in a Public Infrastructure Service Network Design Decisions

Contoso IT requires high availability for services running on the AVN. In order to provide high availability and load balancing for front-end web systems, they have decided to use the AVN's built-in load balancing feature. This decision was made based on the fact that all inbound connections from client systems will be done over the Internet and not through the corporate network. Windows Network Load Balancing was considered, but since it's not supported in AVNs, that option was removed from consideration.

DESIGN DECISIONS:
-The AVN's built-in load balancer will be used to enable high availability and load balancing for front-end web servers

3.3.4 Name Resolution for the Public Infrastructure Service Network Design Decisions

Contoso IT needs name resolution support for client systems that will be accessing resources on the Azure Virtual Network. Since the decision was made that all client access to cloud based resources would be done over the Internet, they decided that they will use name resolution services that are external to both the AVN and the corporate network. DNS entries for resources on the Azure Virtual Network that are accessible over the Internet will be maintained on a public DNS server. Client systems located both on and off premises will use the public DNS entries to access the services located on the AVN.

Contoso IT also requires name resolution support for management systems so that they can access AVN hosted resources. Since they have decided to only allow management access to resources on the AVN through the corporate network, the decision was made to enter the actual virtual machine names into the corporate DNS database. This decision is also supported by the fact that some or most of the resources hosted on the AVN will be domain members, and thus will be able to take advantage of Active Directory secure Dynamic DNS.

DESIGN DECISIONS:
-Public DNS records will be created to allow client Internet access to Azure Virtual Network hosted resources
-Private DNS records will be created to allow management access to Azure Virtual Network hosted resources

3.4 Storage

The Contoso intranet currently has a mature storage infrastructure that includes iSCSI SAN and Windows Server 2012 Storage Spaces. They do not plan on making significant the intranet storage infrastructure, but will consider available options. They need to consider their storage options for resources hosted in AIS. Design decisions around storage for the hybrid IT infrastructure include:

• Storage tiering
• IaaS database
• PaaS database and storage
• Integration with on-premises storage resources

The remainder of this section discusses Contoso's design decisions made in each of these areas.

3.4.1 Storage Tiering Design Decisions

Contoso would like to take advantage of storage tiering, but this option is not currently available on Azure Infrastructure Services. Therefore, the services that they place in Azure Infrastructure Services will be those that do not require a storage tiering option. They plan on moving services that require storage tiering to Azure Infrastructure Services when this option becomes available.

DESIGN DECISIONS:
-Contoso will not move applications that require storage tiering during the early phase of their hybrid IT infrastructure

3.4.2 IaaS Database Design Decisions

Contoso will be deploying applications on AIS that require database services on the back-end. These applications currently are supported by on-premises databases. They have weighed the option of putting these databases onto the AVNs together with the front-end and middle tiers of applications. They have decided that they will make this decision on a case-by-case basis, driven by security and regulatory compliance and data governance considerations. During the first phase if their hybrid IT infrastructure project, they will not place any databases into an AVN.

DESIGN DECISIONS:
-Contoso will not put back-end databases into any AVN during phase 1 of their hybrid IT infrastructure project

3.4.3 PaaS Database and Storage Design Decisions

Contoso is aware that Windows Azure includes a PaaS database offering, which is called Windows Azure SQL database. At this time Contoso is primarily interested in migrating their current applications to AIS and does not want to incur any development expense that might be required to port applications into a PaaS platform. However, they understand that they may benefit from using Windows Azure SQL database for applications that are designed on the Windows Azure PaaS infrastructure and plans development pilot projects for this option in the future.

DESIGN DECISIONS:
-Contoso will not use a PaaS database at this time

3.4.4 Cloud Infrastructure Services Integration with On-Premises Storage

While in the first phase of the hybrid IT infrastructure project there are no plans for updating the current on-premises storage infrastructure, Contoso is aware that Windows Azure storage is able to integrate with with on-premises storage resources. They have looked at some information about Microsoft's StorSimple solution and consider it promising enough that they are considering a pilot project that will use StorSimple to integrate on-premises with cloud hosted storage on Windows Azure

DESIGN DECISIONS:
-Contoso will not integrate on-premises storage with cloud infrastructure storage in this phase of the project

3.5 Compute

Contoso needs to make Compute design decisions that center on the virtual machines that will be hosted on premises and in the AIS cloud. Contoso needs to take into account issues related to the virtual machine offering made available by the public cloud service provider.

Contoso will need to make decisions centered around the following issues when designing the hybrid IT infrastructure’s compute components:

• Operating system and service images
• On-premises physical and virtual server images and disks
• Virtual disk formats and types
• Virtual machine customization
• Virtual machine access
• Virtual machine service availability
• Virtual machine service scalability

The remainder of this section will discuss design decisions Contoso made in each of these areas.

3.5.1 Operating System and Service Images Design Decisions

Contoso plans to begin by moving a low business impact (LBI) application to AIS during the first phase of their hybrid IT infrastructure project. This application is currently running on Contoso's cloud infrastructure that they built based on what they learned from  the Cloud Infrastructure Solution for Enterprise IT reference implementation. The LBI application is currently running on virtual machines. This is a custom line of business application that was developed by Contoso's in-house developers. Contoso need to decide if they want to move the exiting virtual machines to AIS or create new virtual machines on a AVN and then install the applications on those new virtual machines.

Contoso has decided to create new virtual machines on a AVN and then install the front-end web tier component of their LBI applications on the AVN. They made this decision for three primary reasons: 1. the current virtual machines are using VHDX files and AIS does not currently support VHDX and they want to avoid having to convert the VHDX files to VHD files, and 2. the front-end web tier component is simple to install and configure, and 3. they won't have to wait for the virtual machine files to upload into the AVN.

In the future, Contoso will consider porting existing virtual machine files into AIS if it is determined that the overhead is lower than creating new virtual machines to support the applications. 

When deploying the virtual machines, Contoso will place the virtual machines in an Azure datacenter that is closest to the back-end database tier. They made this decisions based on their understanding that network performance will be best if they located the AIS hosted virtual machines as close as possible to the on-premises datacenter.

For similar performance reasons, Contoso will place all the virtual machines into the save affinity group, as this will put all members of the web tier into the same datacenter.

DESIGN DECISIONS:
-Contoso will create new virtual machines to support the front-end and middle tiers on the AVN
-All virtual machines hosted in AIS will be made members of the same affinity group
-All virtual machines will be placed in an Azure datacenter closest to the on-premises network 

3.5.2 On-Premises Physical and Virtual Server Images and Disks Design Decisions

Contoso has some organizational standards for server operating systems that host services on their network. They use sysprepped disk images that contain the settings that have been approved by operations and security.  This helps them save time and reduce the risk of configuration errors when deploying new operating systems to virtual machines. However, during the first phase of their hybrid IT infrastructure project, they have decided to create new virtual machines on the AVN to support their LBI applications based on the rationale discussed in section 3.5.1.

Therefore, they will not begin the project by using the "gold" images that are currently deployed on the intranet. New virtual machines deployed on the AVN will be manually configured to comply with corporate standards. In the future they will consider porting their "gold" images to Azure storage and use them as the base for new virtual machines created in AIS.

The application's web tier is currently hosted in Contoso's DMZ segment since these machines accept inbound connections from the Internet. Security configuration for these virtual machines is managed by the Group Policy settings for the DMZ OU. They will continue to apply security settings to the virtual machines via Group Policy. Therefore will put the web tier virtual machines hosted in AIS into their DMZ OU in Active Directory.

DESIGN DECISIONS:
-In the first phase of the hybrid IT infrastructure project, Contoso will not use corporate "gold" images in AIS
-Contoso will place the web tier virtual machines hosted in AIS into their DMZ OU.

3.5.3 Virtual Disk Formats and Types Design Decisions

Contoso's current cloud infrastructure uses only VHDX files. They are aware that currently AIS support only the VHD format. They are aware that they can perform disk conversion, but they prefer to wait until AIS supports the VHDX format so that they do not need to incur the overhead of converting virtual disk files.

Contoso will use Microsoft's recommendation to put the operating system on operating system disks and application data on data disks. Also per Microsoft's recommendation, they will not put data on caching disks.

DESIGN DECISIONS:
-Contoso will create new virtual machines on AIS and use the native VHD disk format supported by the service
-They will use the Microsoft recommended disk types

3.5.4 Virtual Machine Customization Design Decisions

Contoso's virtual machines are configured with a number of different virtual hardware designs, based on the particular service being supported by the virtual machine or the preferences of the operator who set up the virtual machine. They realize that AIS requires users to pick from a number of pre-defined virtual hardware configurations and that the level of customization available on the on-premises cloud infrastructure is not available in AIS. Contoso will review the virtual hardware configuration for virtual machines running on-premises and map these existing configurations to those available on AIS. When Contoso moves on-premises services to AIS, they will use the mapping table to determine what the size of compute instance they will use to host the service on AIS.

DESIGN DECISIONS:
-Contoso will map current virtual machine hardware configuration to those available in AIS
-New virtual machines created on AIS will be configured based on the hardware mapping
-The front-end web tier virtual machines will be deployed with the "small" virtual machine offering

3.5.5 Virtual Machine Access Design Decisions

Contoso will need a way to access virtual machines on AVNs for management purposes. They have decided to use the Remote Desktop Protocol (RDP) and Remote PowerShell to access Windows operating systems as this is what they use to manage virtual machines on a per server level on the intranet. For Linux based virtual machines that they plan to deploy in the future, they will use the Secure Shell Protocol (SSH) for remote management. 

AIS automatically creates a port forwarding rule that enables remote RDP and SSH access from the Internet to virtual machines created on an AVN. Contoso security has dedicated that they want to reduce the attack surface for virtual machines on AVNs by preventing Internet access to the operating systems over RDP and SSH. For this reason Contoso has decided that it will disable the default port forward rule created by AIS.

DESIGN DECISIONS:
-RDP will be used to perform per server management access to Windows virtual machines on AIS Virtual Networks
-The default RDP port forwarding rules will be removed 

3.5.6 Virtual Machine and Service Availability Design Decisions

Contoso currently uses a hardware load balancer to increase the service availability for their multi-tier applications, typically for the front-end web servers. They would like to continue to use load balancing technology when moving these applications to AIS. For this reason, they will utilize the built-in load balancing feature included in AIS.

In addition to using load balancing to help insure service availability, Contoso wants to make sure that all components are available when the public cloud infrastructure virtualization hosts are being serviced or updated. To solve this problem, Contoso has decided that all virtual machines participating in the same service will belong to the same availability set.

DESIGN DECISIONS:
-Contoso will use the AIS built-in load balancing feature for inbound connections to the service
-All machines participating in the same service will be assigned to the same availability set

3.5.7 Virtual Machine Service Scalability

The application that Contoso will put into AIS currently has two on-premises front-end servers. Contoso IT has noticed that there are times when application performance is degraded due to the front-end servers being overwhelmed with connection traffic. They had considered adding  two more front-end servers on-premises to improve application performance, but since they are moving the front-end web tier to AIS, they will take advantage of the Azure auto-scaling feature. They will create 4 front-end web servers and configure auto-scaling so that they can acquire resources they need on demand. They will configure virtual machine auto-scaling so that service processor utilization sites between 60-80%, they will scale up 1 instance at a time, scale up wait time will be 10 minutes after previous action, scale down by 1 instance at a time, and scale down 10 minutes after last action.

Contoso will put all the front-end web tier servers into the same Cloud Service. The reason for this decision is that auto-scaling virtual machines can only be done within the same service and is configured within the service.

DESIGN DECISIONS:
-Contoso IT will configure the front-end web tier of the application to auto-scale to up to 4 servers
-Auto-scaling parameters will be set using those discussed above
-All servers in the web tier will be placed into the same cloud service

3.6 Management and Support

Contoso needs to make several important design decisions centered around management and support. The major areas where these decisions need to be made in their hybrid IT infrastructure design are:

• Consumer and provider portals
• Usage and billing
• Service Reporting
• Infrastructure service provider authentication and authorization
• Application authentication and authorization
• Backup services and disaster recovery

The following section discuss the decisions made by Contoso and the rationale behind those decisions.

3.6.1 Consumer and Provider Portal Design Decisions

At this time Contoso runs a private cloud infrastructure but has not yet completed its full, but planned, infrastructure as a service offering. Because of this, they do not provide a consumer-facing portal to their users. They plan to do so when they have completed their on-premises private cloud offering. Until then, they will take resource requests via their IT Web web site where business units can make requests for resources in the private cloud infrastructure.

Contoso will need access to AIS in order to provision and configure virtual machines. While they have several options, they have decided to begin their hybrid IT project by using the Azure Portal to manage their AIS environment. Contoso is aware that they have other options, such as PowerShell management and System Center App Controller, but decided that during the first phase of the project, they wanted to keep things as simple as possible. In the next phase of their project, they will seek to create a seamless management experience by using using App Controller or a similar solution. In addition, prior to the next phase of the hybrid IT project, Contoso will gain experience with PowerShell management of their AIS resources.

DESIGN DECISIONS:
-Contoso will not provide a consumer portal to its customers during the first phase of the hybrid IT infrastructure project
-They will use the Azure Portal for the first phase of the project

3.6.2 Usage and Billing Design Decisions

As mentioned in section 3.2, Contoso will begin with a conservative approach in terms of resource acquisition in AIS and then systematically grow their financial investment in AIS as they gain more experience with the service. In order to both simplify and clarify usage reporting, Contoso will use a single billing account that will be responsible for multiple subscriptions. This will give them visibility into usage costs for different services offerings that use the hybrid IT infrastructure.

During the initial phase of the project, Contoso IT will use showback to report the costs to the business group responsible for the application. As they deploy more applications into the hybrid IT infrastructure, they will continue to use showback with multiple business groups. Over time, they will engage in discussions with the financial leadership at Contoso to determine if chargeback is appropriate for some or all of the business groups that use the hybrid IT infrastructure.

DESIGN DECISIONS:
-Contoso will use a single billing account
-Multiple subscriptions will be used with one subscriptions per service offering 
-Showback will be used instead of chargeback during the initial phase of the project

3.6.3 Service Reporting Design Decisions

Contoso needs reports on service availability for the public cloud infrastructure service side. Contoso will want to provide an SLA to consumers of the hybrid cloud service and reports need to provide information about uptime for each component of the service as well as the service as a whole. They currently have a monitoring and reporting system that they use on-premises and plan to integrate that system with the Windows Azure system if they find that it is possible in the next phase of the project. During the first phase of the hybrid IT project, Contoso will take advantage of the no-cost System Center Advisor software as a service offering from Microsoft to provide service configuration monitoring and reporting that will supplement the reporting capabilities included with AIS. Contoso will also considering wider adoption of System Center Advisor after they gain more experience with the product during the first phase. In addition, they will use the service dashboard to determine the health of the AIS services in the region where the virtual machines are located.

DESIGN DECISIONS:
-Contoso will use the AIS built-in service reports
-They will use System Center Advisor to monitor service components hosted on AIS
-They will use the service dashboard to monitor the health of the overall AIS services in their location

3.6.4 Public Cloud Infrastructure Service Provider Authentication and Authorization

When working with a public cloud infrastructure service provider’s system, Contoso needs to decide what authentication and authorization/access control options they will adopt. Design decisions they need to make in this area include those in the following areas:

• Authentication
• Authorization
• Account management

NOTE:
This section (3.6.4) addresses only authentication, authorization and account management issues for access to the Azure service. This section does not cover authentication, authorization and account management issues related to access to the application itself and the front-end web servers located in AIS that host the web tier of the application. The next section (3.6.5) will discussion authentication, authorization and account management issues related to accessing the application.

The following sections will discuss the design decisions Contoso made in these areas and the rationale for those decisions.

3.6.4.1 Authentication  Design Decisions

Contoso needs to authenticate to the provider’s system to gain access to system resources. They considered their options and decided that the most efficient and secure way to provide account access to the Azure Portal and AIS hosted resources is to integrate their Active Directory accounts with Azure. This enables enterprise level account management since it integrates their on-premises account provisioning and de-provisioning systems with Azure authentication systems. They decided that they would synchronize their on-premises authentication system (Active Directory) with Azure by taking advantage of Windows Azure Active Directory. After synchronizing  local accounts with Windows Azure Active Directory , Contoso will allow only accounts in their Active Directory administrative access to AIS hosted resources. This will allow accounts that are deleted or disabled on-premises to no longer be able to access Azure services after they are deleted.

Contoso realizes that synchronizing accounts will provide them with "same sign-on" (meaning that they can use corporate credentials to sign onto the Azure service), it does not provide them with "single sign-on". They will investigate single sign-on capabilities using ADFS to federate their corporate accounts with Windows Azure Active Directory and include those capabilities in the next phase of the project. For the first phase, only a handful of administrators will be using the Azure services, and therefore it was decided that the learning curve required to set up the supporting infrastructure to support single-on for a small number of administrators during the first phase didn't provide a good return on investment.

DESIGN DECISIONS:
-Contoso will synchronize their on premises Active Directory with Windows Azure Active Directory using DirSync
-Only Active Directory accounts will be allowed administrative access to AIS hosted resources for management

3.6.4.2 Authorization and Access Control Design Decisions

In Contoso's hybrid IT infrastructure, they need to decide what authorization capabilities they will enforce for access to resources contained on premises and in the public cloud. At this time Contoso does not have a self-service portal and therefore requests for resources involve mostly manual processes based on requests made in a web form. A full self-service portal will be implemented when Contoso completes it's private cloud IaaS implementation and automation will be built into the resource requisitioning process, which will integrate both on-premises and off-premises components.

Contoso has reviewed its options for acquiring resources for the public cloud components of the hybrid IT infrastructure and has decided that during the first phase of the project that they would just extend their current on-premises approach to requests for AIS resources. They will accept requests for infrastructure resources from the web form consumers will use to ask for resources, and then Contoso IT will decide which components will be located on-premises and off-premises, based on business impact of the service. Therefore, only specific members of the Contoso IT group will be given administrative access to AIS at the first phase of project. Later, these members of the IT group will train the rest of the group on how to manage AIS resources.

DESIGN DECISIONS:
-Contoso will extend its resource request approach to public cloud components of the hybrid IT infrastructure
-A subset of the Contoso IT organization will be trained on managing AIS resources
-The subset of the Contoso IT organization will train the rest of the IT group in the next phase of the project

3.6.4.3 Account Management Design Decisions

Contoso needs an account management system to insure that only valid accounts of authorized users will have access to the hybrid IT infrastructure. They currently have a mature account management system that is integrated with on-premises human resources systems. They need to extend the efficiencies they have with their on-premises system to access to AIS hosted resources. As discussed in section 3.6.4.1, they will accomplish this goal by integrating their on-premises Active Directory system with Azure so that local accounts are required for management access.

Role based access control is important to Contoso security and they have implemented this at many levels of their on-premises network. They would like to have similar capabilities for the public components of the hybrid IT infrastructure. Based on current capabilities, they have decided to assign the head of Contoso IT the Service Administrator role, and a subset of Contoso IT members Co-Administrator roles. They did this based on the fact that the Director of Contoso IT makes decisions on who has administrative access and therefore should have the same responsibility for assign this access to the AIS hosted resources.

Contoso is aware that Co-Administrators are allowed to add other Co-Administrators. Therefore, they have put a process in place where the Service Administrator is responsible for reviewing the Co-Administrator list on a daily basis to confirm that only authorized users are listed as Co-Administrators. If the Service Administrator is not available due to vacation, sick leave, or any other reason, the Service Administrator's manager will be tasked with this check. The reason for this is that it is possible that a Co-Administrator might add an account that user might use if that user leaves the company, which could lead to untoward effects.

DESIGN DECISIONS:
-On-premises account management will be extended to off-premises access via federation
-The Director of Contoso IT will be assigned the Service Administrator role
-The Director of Contoso IT will assign Co-Administrator access to a subset of the IT organization
-Contoso IT will put a process in place to check on the list of Co-Administrators

3.6.5 Application Authentication and Authorization Design Decisions

Contoso needs to make design decisions around application authentication and authorization. While there are a number of authentication and authorization options available for the applications that Contoso will run in AIS, in the majority of cases for Contoso those applications will be dependent on Active Directory. For this reason, Contoso needs to make design decisions for applications that run some or all of their components in AIS  network.

Design decisions for application authentication authorization resolve around the following issues:

• Active Directory domain controller on an AVN
• Domain controllers on an AVN
• Domain Controller Locator 
• Domain, forest and global catalog
• Active Directory name resolution and Geo-location
• Active Directory Federation Services

NOTE:
This section (3.6.5) addresses authentication, authorization and account management issues related to access to the application that has it's front-end web tier hosted in AIS. This section does not address issues related to authentication, authorization and account management for access to the Azure services themselves. These issues are discussed in section 3.6.4

The following sections will discuss the design decisions Contoso made in these areas and the rationale for those decisions.

3.6.5.1 Active Directory Domain Controllers in the Public Cloud Infrastructure Provider's Network Design Decisions

Contoso IT needs to decide if they are going to put any domain controllers in a AVN to support applications that require Active Directory for authentication. In addition, they need to decide what type of domain controller to place. Contoso has decided that they will put two domain controllers on the AVN to support user authentication for access to hybrid applications. This will allow users to authenticate even if the site to site VPN connection to the on-premises domain controllers.

New domain controllers will be created on the AVN. Contoso is aware that AIS support VM-Generation ID which would enable them to create domain controllers on-premises and move them to an AVN.

Given that the decision is made to put domain controllers on the AVN, Contoso needs to decide which disk types to use in AIS virtual machines to support the domain controller role. Contoso has decided to adopt Microsoft's recommendations that the operating system is put on an OS disk and all Active Directory-related files on a Data Disk. This recommendation is based on the fact that OS disks enable write caching by default and Data Disks disable write caching by default, which is a core Active Directory assumption for disk behavior.

DESIGN DECISIONS:
-Contoso will put two domain controllers on each AVN to support user authentication to applications
-These domain controllers belong to the same domain and forest as the on-premises production domain
-New domain controllers will be created on the AVN network
-Domain controllers will use the disk type recommendations provided by Microsoft

3.6.5.2 Read-Only Domain Controller Design Decisions

Contoso has decided that they will not use read-only domain controllers. The reason they made this decision is that they know that not all applications are compatible with read-only domain controllers. They do not want to incur the overhead of testing each application to determine if they are compatible with read-only domain controllers. This helps Contoso avoid the need to deploy both read-only and read-write domain controllers.

DESIGN DECISIONS:
-Contoso will not deploy read-only domain controllers

3.6.5.3 Domain Controller Locator Design Considerations

Contoso want to make sure that they minimize the impact of egress traffic due to replication traffic. In order to achieve this goal, they have decided to configure a subnet and site for each each AVN they create in AIS. After creating sites, they will configure site links with costs to insure that on-premises domain controllers see that AVN located domain controllers see these sites as very high cost. They will limit replication from AVN located domain controllers to weekdays only and will create a replication policy that will enforce this. Finally, Contoso has decided to enable compression for Active Directory replication.

DESIGN DECISIONS:
-Contoso will create a subnet and site for each AVN
-High cost site links will be set for links to domain controllers location on an AVN
-Replication policies will be created that limit outbound replication to weekdays only
-Compression will be enabled for Active Directory Replications

3.6.5.4 Domain, Forest and Global Catalog Design Decisions

Contoso had several options for what type of domain and forest configuration to use for domain controllers and resources located on an AVN. They decided that the Azure security model was strong enough to enable them to put full read-write domain controllers that are members of the corporate on-premises domain and forest on the AVNs. They decided to deploy domain controllers that are part of the same domain and forest as the on-premises network because this will be easier to manage and deploy and will enable the greatest level of application compatibility.

The decision was also made to make the domain controllers located on AVNs to be global catalog servers. The reason for this is that Contoso wanted to support Universal Groups, enable log on for their multiple-domain forest and enable them to take advantage of universal group membership caching.

DESIGN DECISIONS:
-All domain controllers on the AVN will be configured as global catalog servers
-All domain controllers on the AVN will be read/write domain controllers
-All domain controllers on the AVN will be members of the on-premises network forest and domain

3.6.5.5 Active Directory Name Resolution and Geo-Distribution Design Decisions

Contoso needs to decide how to handle name resolution for resources located on AVNs and resources located on-premises. While Contoso is aware that AIS provides some native DNS capabilities, they are not robust enough to support Active Directory's DNS requirements. For this reason, Contoso will configure the domain controllers on AVNs to also be Active Directory integrated DNS servers.

DESIGN DECISIONS:
-All domain controllers located on AVNs will be configured as AD-integrated DNS servers

3.6.5.6 Active Directory Federation Services (ADFS) Design Decisions

While Contoso will not be using federated access to applications hosted in AIS, they have decided that they will want to use on-premises Active Directory accounts for log on to AIS services. In order to accomplish this, they will need to federate their on-premises Active Directory infrastructure with Azure Active Directory. Contoso plans to investigate application federation when they move forward in the future to use Azure PaaS services. In addition,  they plan on enabling single sign-on to Azure services by federating their on-premises directory with Azure Active Directory.

DESIGN DECISIONS:
-Contoso will not use ADFS for application federation during this phase of the project
-They will not use ADFS for federating with Azure Active Directory to enable single sign-on

3.6.6 Backup Service and Disaster Recovery

In order to make sure that the company is able to recover from untoward events, they will need to make design decisions around:

• Active Directory domain controller on an AVN
• Domain controllers on an AVN

The following sections will discuss the design decisions Contoso made in these areas and the rationale for those decisions.

3.6.6.1 Backup Services Design Decisions

Contoso currently has a well established backup system in place for on-premises virtual machines and application data attached to those virtual machines. They have decided that they will continue to use that system for on-premises resources. However, they will not use the same system to back up virtual machines and application data for resources running on AIS because they do not want to incur the egress traffic costs. In addition, the front-end web tier hosts stateless services that are simple to restore, therefore there is little to gain by backing up the operating systems and there is no data to back up.  In the next phase of the project, Contoso will consider using Windows Azure Backup Services. By using Windows Azure Backup Services they will be able to backup systems on AIS without incurring additional costs from standing up more virtual machines in the AVN to perform backup services.

DESIGN DECISIONS:
-Contoso will not backup the stateless machines that run the front-end web tier

3.6.6.2 Disaster Recovery

Contoso currently has a disaster recovery plan that is based on failing over to a second on-premises data center. During this phase of the hybrid IT project, they do not plan on making changes to their current plan. The do plan on investigating cloud based disaster recovery options in the future.

3.6.6.3 Operating System Update Design Decisions

Contoso needs to decide how they will update the Windows operating systems that host the front-end web services. They can use the public Windows Update system or Windows Server Update Services. They have a WSUS implementation on-premises and have update policies in place for DMZ systems on-premises. They have decided that they want to continue to use those policies when moving the front-end web tier into an AVN. Therefore, they will update the front-end web tier using their on-premises system. This will not impact traffic related costs because this will be inbound traffic into the AVN. However, the bandwidth available over the site to site VPN connection and therefore updates from the front-end web tier will be scheduled for off-hours.

DESIGN DECISIONS:
-Contoso will use their on-premises WSUS system to update the front-end web tier virtual machines
-They will set update policies so that updates take place during off-hours

4.0 Summary

After identifying the requirements and constraints in your environment and then evaluating each of the design considerations that are detailed within this document, you can create a hybrid IT infrastructure design that best meets your unique needs. Then, you can implement it in a test environment, test it, and deploy it into production.

To complement this document, Microsoft has created reference implementation (RI) guidance sets for hybrid IT infrastructure solutions that are designed for specific audiences. Each RI guidance set includes the following documents:

• Scenario Definition: For a particular domain, different audiences generally have different requirements and constraints. This document describes a fictitious example organization that is implementing a hybrid IT infrastructure solution. It provides answers to the questions in the Envisioning The Hybrid IT Solution section of this document—answers that relate to the fictitious organization. Many organizations within this audience type will find that they have requirements and constraints similar to those of the fictitious organization. This document is most helpful to people responsible for designing hybrid IT infrastructure solutions at organizations similar to those that are defined by the RI’s audience type.  

• Design: This document details which specific products, technologies, and configuration options were selected, out of the hundreds of individual available options, to meet the unique requirements for the example organization that is defined in the Scenario Definition document. This document also explains the rationale for why specific design decisions were made. For organizations that have requirements and constraints similar to the example organization, the lab-tested design and rationale in this document can help decrease both the implementation time and the risk of implementing a custom hybrid IT solution. This document is most helpful to those responsible for designing a hybrid IT infrastructure or implementing solutions within enterprise IT organizations, because it details an example design, and the rationale for the design.

Note:
The Design document within a Reference Implementation (RI) guidance set uses one combination of the almost infinite number of combinations of design and configuration options that are presented in this hybrid IT infrastructure Design Considerations document. The specific design options from this hybrid IT infrastructure Design Considerations document that are chosen in an RI Design document are based on the unique requirements from the Scenario Definition document in the RI guidance set. As a result, many people who read this hybrid IT infrastructure Design Considerations document will find it helpful to also read the RI guidance set for this domain that is targeted at an audience type similar to their own. The RI guidance set shows which design options from this document were chosen for the example organization, and helps the reader to better understand why those options were chosen. Other people will decide that reading an RI guidance set is unnecessary for them, and that this hybrid IT infrastructure Design Considerations document provides all the information they need to create their own custom design.

Although the Design document in an RI guidance set is related to this hybrid IT infrastructure Design Considerations document, there are no dependencies between the documents.

• Implementation: This document provides a step-by-step approach to implementing the design in your environment. While this document lists implementation steps to install and configure the solution, the steps are written at a level that assumes you already have some familiarity with the technologies that are used in the design that is detailed in the Design document. In cases where new technologies are used, more detailed implementation steps are included in the document. To review lower-level implementation steps than those that are provided in this document, you’re encouraged to read the information found at the hyperlinks that are included throughout this document. This document is most helpful to those responsible for implementing hybrid IT infrastructure solutions within types of organizations that are identified by the audience type for the RI.  

• Operations: This document details recommended operational tasks for the design that is detailed in the Design document. This document is most helpful to those responsible for the day-to-day operations, such as support, administration, and monitoring of a hybrid IT infrastructure solution when it’s live in production.

5.0 Technologies Discussed in this article

Windows Server 2012 DNS services
Active Directory Domain Services
Windows Azure Active Directory
Windows Azure Virtual Machines
Windows Azure Cloud Services
Windows Azure Storage
Windows Azure Storage Services
Windows Azure Recovery Service
Windows Azure Virtual Network  

6.0 Authors and Reviewers

Authors:
Thomas W. Shinder - Microsoft
Reviewers:
Jim Dial - Microsoft
Yuri Diogenes - Microsoft
John Dawson - Microsoft
Cheryl McGuire - Microsoft
Kathy Davies - Microsoft
John Morello - Microsoft
Jamal Malik - Microsoft

This article is maintained by the Microsoft DDEC Solutions Team

6.0 Change Log

Version

Date

Change Description

1.0

7/1/2013

Initial posting and editing complete.

4.0 Summary

This article detailed a lab-tested design that met the requirements, constraints, and principles of a fictitious organization described in the Scenario Definition [Edit the hyperlink to point to the correct URL] article of this article set. If you haven’t read that article, and are interested in understanding the requirements and constraints that drove the design detailed in this article, then you’re encouraged to read it. If you’re interested in implementing this design in whole or part, you’re encouraged to read the Implementation [Edit the hyperlink to point to the correct URL] article in this article set, which details the steps required to implement this design.

5.0 Technologies Discussed

This section lists the official names of the technologies discussed in the article.

• Technology 1
• Technology 2

6.0 Authors and Reviewers

This section is optional and may be removed if necessary.

Authors

• Name - Company
• Name - Company

Contributors

• Name - Company
• Name - Company

Reviewers

• Name - Company
• Name - Company

7.0 Change Log

For the first version, simply fill in the publishing date cell of this table.

Version
Date published
Change description

1.0
Initial posting and editing complete.