Chapter 4 Service provider cloud

The third cloud type in the Cloud OS vision is the service provider cloud. These are clouds hosted by a provider other than Microsoft or the end customer. As discussed previously, service provider clouds are ideal for use cases that either Windows Azure can’t support or where Windows Azure isn’t available. Service provider clouds are also ideal for use cases that are too expensive for hosting on-premises or where on-premises staff is not trained or capable of managing the particular solution (consider a hosted enterprise resource planning instance such as SAP).

Cloud OS Network

The Cloud OS vision depends on a robust service provider ecosystem running the Microsoft platform to enable the common virtualization, identity, data, management, and development capabilities as the private cloud and Windows Azure. To achieve this goal of a robust ecosystem, Microsoft established the Cloud OS Network.

The Cloud OS Network is a worldwide consortium of cloud service providers who have embraced the Cloud OS vision. These organizations offer solutions based on the Microsoft Cloud Platform designed to meet customer business needs. Members of this network combine Microsoft technology with their hosting and geographic expertise to provide flexibility and choice for hybrid infrastructure solutions. A current list of the Cloud OS Network partners can be found at: http://www.microsoft.com/en-us/server-cloud/cloud-os-network.aspx#fbid=tKWR1hKoghK.

Members of the Cloud OS Network have built hosting solutions using the same products and architectures as described in Chapter 2, “Private cloud.” The same Infrastructure as a Service (IaaS) Product Line Architecture referenced in those chapters and used in private cloud deployments is utilized in the service provider deployments by the Cloud OS Network partners. This provides not just commonality of product utilization, but also commonality of architectures and solutions.

Many of the Cloud OS Network partners are utilizing the Microsoft software-defined storage, network, and compute architectures described in this book because many of those capabilities were specifically engineered to support service provider needs.

By choosing Cloud OS Network partners, you can extend your datacenter fabric and fabric management to service providers in addition to Windows Azure and achieve the Cloud OS vision of a unified virtualization, identity, data, management, and development platform across the entire hybrid infrastructure.

Extending the datacenter fabric to a service provider

Many of the same concepts from extending the datacenter fabric to Windows Azure also apply to extending the fabric to service providers. In some cases, there are different features or capabilities utilized and those are what we will cover in this chapter.

Extending the datacenter network to service providers

Similar to extending the datacenter network to Windows Azure, extending to service providers also entails using VPN capability, however, in this case the combination of VPN and Hyper-V Network Virtualization can be utilized. Cloud OS Network partners that enable Hyper-V Network Virtualization capability do so through a combination of Hyper-V, Virtual Machine Manager (VMM), and Windows Azure Pack capabilities. The end result is that you can extend your datacenter network and bring your own IP address spaces to the service provider datacenter. As described in the section titled “Software-defined networking” in Chapter 2, Hyper-V Network Virtualization allows the service provider to run multiple isolated tenant networks side by side allowing each tenant to bring their own IP address ranges.

If the service provider utilizes Service Provider Foundation and Windows Azure Pack (each described later in this chapter) they can expose a similar network configuration and VPN connectivity self-service interface as Windows Azure, again providing a common experience across the three cloud types even though the underlying implementation is different.

Establishing network connectivity to the service provider cloud opens a variety of application and management scenarios. Similar to the Windows Azure scenarios, establishing network connectivity enables you to either deploy Microsoft System Center2012 for fabric management in the private cloud datacenter and managing both private cloud and service provider hosted resources or alternatively, placing the System Center implementation at the service provider and managing on-premises resources from that implementation. When network connectivity is established between clouds using VPN and network virtualization, nearly all System Center management scenarios become possible-the most important being the ability to deploy agents into the running virtual machines for management and monitoring.

Extending datacenter storage to service providers

The combination of VPN and network connectivity to service providers enable several storage scenarios, such as hosting file servers and storage at the provider, replicating storage between the private cloud and the service provider using technologies such as Distributed File System (DFS) in Windows.

Similarly to Windows Azure, service providers are also able to leverage economies of scale and offer raw capacity such as storage at prices that may be less than what enterprises are able to achieve on-premises. Additionally, since most service providers are not creating global scale services like Windows Azure where mass standardization is required, they often have the flexibility to fill niches and needs that may not be able to be profitably delivered by Windows Azure. Examples might be hosting particular types of regulated data, or hosting data in specific regions where Windows Azure does not maintain a datacenter. For these and many other possible reasons, extending storage to the service provider cloud is valuable option.

Many of the Windows features and capabilities, such as DFS, DFS-R, and File Services, are well known as they have been part of Windows Server for many years and therefore they will not be covered in detail here. We simply want to emphasize that many of the architectures you might have used between your on-premises datacenters can also be used when a service provider running the Cloud OS and allowing network connectivity is selected.

Extending datacenter compute to service providers

Extending the datacenter compute infrastructure to service providers is the same as extending to Windows Azure. Cloud OS Network partners enable Hyper-V based hosting of virtual machines. Cloud OS Network partners also have the option of using Windows Azure Pack as the self-service user interface to their hosted solutions and providing the same user interface being utilized by Windows Azure and their customer’s private cloud infrastructures.

An additional capability service providers can provide, which is potentially highly valuable to customers and not currently provided by Windows Azure, is being a replication target for Hyper-V Replica. Windows Server 2012 R2 enhances Hyper-V Replica to support three replicas of a virtual machine: the primary or source virtual machine, a secondary replica, and a tertiary replica. For source virtual machines in a private cloud, the secondary replica could be hosted either on-premises or at a service provider as can the tertiary replica. This enables two interesting scenarios. The first is a customer maintaining both the primary replica in the private cloud and the secondary in a second datacenter in their private cloud with the tertiary being hosted at a service provider. The second scenario is where the customer maintains the primary virtual machine with both the secondary and tertiary replicas being hosted by a service provider. This can relieve an organization from the expense of maintaining a backup or disaster recovery datacenter while opening up opportunities for service providers to bring significant value to their customers.

The third cloud type in the Cloud OS, the service provider cloud, enables a number of scenarios for extending the hybrid cloud fabric to the Microsoft Cloud OS Network partners. With the fabric extended to service providers, fabric management must also be extended to encompass the provider hosted resources.

Extending datacenter fabric management to a service provider

The final step in building the Cloud OS hybrid infrastructure is extending fabric management to encompass the resources hosted at Cloud OS Network service providers. This section will be brief because nearly all of the approaches that were utilized for managing Windows Azure hosted resources also apply to managing service provider hosted resources. Two enabling technologies, Service Provider Foundation (SPF) and Windows Azure Pack (WAP) provide API and UI commonality respectively between private cloud, Windows Azure, and service provider cloud.

Service Provider Foundation

Service Provider Foundation is provided with System Center 2012 R2 Orchestrator. Service Provider Foundation exposes an extensible OData web service that interacts with System Center 2012 R2 VMM. This enables service providers and hosters to design and implement multi-tenant self-service portals that integrate with the IaaS capabilities available in a Windows Server 2012 R2 and System Center 2012 R2 cloud environment.

In many cases, service providers want to enable a robust self-service capability for their customers, typically in the form of a self-service portal providing secure access for the customer to provision and manage resources in the service providers shared infrastructure. Creating such a portal requires a robust set of web services and APIs for the portal to use and interact with the infrastructure. For the Microsoft platform, this function is provided by SPF.

Figure 4-1, adapted from Microsoft TechNet diagram ( http://technet.microsoft.com/en-us/ library/jj642897.aspx ), illustrates the high-level architecture enabled by SPF

The tenant represents a service provider’s customer, and the tenant has assets on the service provider’s infrastructure. Each tenant has their own administrators, applications, scripts, and other tools. The service provider could be an enterprise IT organization providing services to business units or it could be a commercial service provider or hoster.

The service provider provides tenants an environment, which can include virtual machines or other resources. The service provider in this case is assumed to have an existing self-service portal, which all tenants can use (later we’ll discuss the Windows Azure Pack portal provided by Microsoft). On the back end, the service provider has a set of resources (compute, storage, network), which is called the fabric. The service provider allocates those resources into discrete groups according to the service provider’s needs in terms of performance, isolation, etc. Each of these groups is known as a stamp. The service provider assigns the tenant’s access to stamps in whatever manner is appropriate. The tenant’s resources may be provisioned across several stamps, according to the service provider’s policies and business model. SPFmakes it possible for the service provider to present an aggregated view to the tenant of all their resources regardless of which stamp they are hosted on. SPF also enables a set of application programming interfaces (APIs) tenants can utilize to manage their resources.

A stamp in Service Provider Foundation is a logical scale unit of compute, storage, and network designed for scalability that provides pre-determined amount of capacity. An example of a stamp is the single rack architecture described in previous chapters where a balanced mix of compute, storage, and network capacity is designed to support a specified number of virtual machines. As tenant demand increases, the service provider deploys additional stamps to meet demand. As described previously, these stamps can be deployed from bare-metal by VMM.

Figure 4-2, also adapted from Microsoft TechNet ( http://technet.microsoft.com/en-us/ library/jj642897.aspx ) provides a view of how both the service provider’s custom portal and System Center 2012 R2 App Controller can serve as the front end to the service provider’s hosted IaaS stamps.

Service Provider Foundation uses a SQL Server database to aggregate the tenant resources, which are managed with Windows PowerShell scripts and Orchestrator runbooks. The service provider can distribute tenant resources among management stamps depending on their own policies while to the tenant their resources are aggregated and appear to be hosted on a single infrastructure.

Another key service provided by SPF is usage metering. SPF provides usage metering that enables service providers to:

• Obtain metrics for tenant usage consumption for virtual machines, CPU, memory, network, and disk.

• Determine capacity utilization

• Bill tenants for their usage according to their plans.

Usage metering is a critical requirement for service providers as it enables them to monitor and track various metrics that they use to bill their customers for services provided.

The Usage Service captures the tenant-specific resource allocation and consumption information in a uniform manner across the hosted services (VMs, web sites, etc.). The Usage Service treats all services uniformly and collects information across these services and stores them for a limited period of time in a SQL Server database. The information is designed to be used by billing or financial systems for chargeback and monetization of the provided services. The information captured consists of actions performed with billing impact on the self-service tenant portals or at the Service Management API layer, meaning regardless of whether a tenant performs an action through the portal, PowerShell, or API, the Usage Metering service will capture those actions

The Usage Metering service does not provide a billing system but is designed to enable third-party billing systems by capturing the required data and making that data available via a REST API.

Windows Azure Pack

Windows Azure Pack (WAP) has been described previously as providing an Azure-consistent self-service user interface for private and service provider clouds. Windows Azure Pack is a collection of Windows Azure technologies, available to Microsoft customers at no additional cost, for installation into private cloud or service provider data centers. It runs on top of Windows Server 2012 R2 and System Center 2012 R2

Windows Azure Pack includes the following capabilities as documented on Microsoft TechNet (http://technet.microsoft.com/en-us/library/dn296435.aspx):

• Management portal for tenants A customizable self-service portal for provisioning, monitoring, and managing services such as Web Site Clouds, Virtual Machine Clouds, and Service Bus Clouds.

• Management portal for administrators A portal for administrators to configure and manage resource clouds, user accounts, and tenant offers, quotas, and pricing.

• Service management API A REST API that helps enable a range of integration scenarios including custom portal and billing systems.

• Web Site Clouds A service that helps provide a high-density, scalable shared web hosting platform for ASP.NET, PHP, and Node.js web applications. The Web Site Clouds service includes a customizable web application gallery of open source web applications and integration with source control systems for custom-developed web sites and applications.

• Virtual Machine Clouds A service that provides IaaS capabilities for Windows and Linux virtual machines. The Virtual Machine Clouds service includes a VM template gallery, scaling options, and virtual networking capabilities.

• Service Bus Clouds A service that provides reliable messaging services between distributed applications. The Service Bus Clouds service includes queued and topic-based publish/subscribe capabilities

• SQL and MySQL Services that provide database instances. These databases can be used in conjunction with the Web Sites service.

• Automation The capability to automate and integrate additional custom services into the services framework, including a runbook editor and execution environment.

Windows Azure Pack also provides APIs and builds on the SPF APIs. In addition to virtual machines, Windows Azure Pack also enables web sites, databases, and service bus services similar to Windows Azure but hosted in the private cloud or service provider cloud. Figure 4-3 illustrates the architecture that a service provider would deploy

The references to third-party modules indicate the extensibility model enabled by both SPF and the Windows Azure Pack for the advantage of Microsoft’s large partner ecosystem. Multiple partners have created extensions for connecting to billing systems, providing hosted services beyond those provided by WAP natively, and many other scenarios.

Windows Azure Pack enables significant new capabilities to Windows and System Center. Given its pedigree from Windows Azure and its target use cases with large enterprises and service providers, Windows Azure Pack is delivered through a highly available set of web services and capabilities requiring a relatively complex architecture.

Windows Azure Pack is comprised of several required and optional components. Each component can be deployed in physical or virtual machines and each can be deployed as scale-out, load-balanced tiers. This section provides the suggested machine topologies for these components

There are four defined patterns for Windows Azure Pack deployment:

• Express Deployment (single server)

• Basic Distributed Deployment

• Minimal Distributed Deployment

• Scaled Distributed Deployment

The latter two deployment patterns are recommended for production environments. The Minimal Distributed Deployment, illustrated in Figure 4-4, is appropriate for enterprise or small service provider deployments.

For large enterprises or service providers requiring higher scale, the Windows Azure Pack Scaled Distributed Deployment pattern can be utilized. This pattern further separates the layers of the Windows Azure Pack architecture into their own sets of load-balanced servers (or virtual machines). Figure 4-5 illustrates this deployment pattern.

For both enterprises and service providers utilizing Windows Azure Pack, our reference architecture for IaaS referred to in previous sections considers WAP to be a part of fabric management, meaning it is deployed (using either of the two patterns illustrated above) on the fabric management cluster as virtual machines. In our reference architecture, WAP also utilizes the fabric management SQL Server guest cluster that the rest of the System Center components utilize and the WAP database requirements are illustrated alongside those of System Center.

System Center 2012 R2

As with extending fabric management to Windows Azure, System Center 2012 R2 can also be utilized to manage resources hosted at service providers. Many of the same deployment options apply such as using an on-premises deployment of System Center to manage service provider hosted resources over a VPN connection to the provider or deploying System Center itself at the service provider to manage all of your resources hosted there. Given the similarity in approach, those options won’t be repeated here.

Utilizing System Center 2012 R2 - App Controller, and enterprise can connect App Controller to any service provider cloud that exposes SPF endpoints to them. What this means is that from within App Controller, it can be configured to provision virtual machines to connected service provider clouds in addition to VMM-based private clouds and Windows Azure.

Hyper-V Replica

As discussed previously, Hyper-V Replica provides asynchronous replication of Hyper-V virtual machines between two (or three) hosting servers. It is simple to configure and does not require either shared storage or any particular storage hardware. Replication works over any ordinary IP-based network, and the replicated data can be encrypted during transmission. Hyper-V Replica works with standalone servers, failover clusters, or a mixture of both. The servers can be physically colocated or widely separated geographically. The physical servers do not need to be in the same domain, or even joined to any domain at all.

When replication is enabled, changes in the primary virtual machines are transmitted over the network periodically to the Hyper-V Replica virtual machines. The exact frequency varies depending on how long a replication cycle takes to finish (depending in turn on the network throughput, among other things), but generally, replication data is sent to the Hyper-V Replica server every 5 minutes in Windows Server 2012. In Windows Server 2012 R2, you can configure the replication frequency, so that the changes are sent every 30 seconds, every 5 minutes, or every 15 minutes.

A primary scenario that service providers can enable (which is currently not supported in Windows Azure) is the Hyper-V Replica hosting possibility that was described earlier in this chapter in the section titled “Extending datacenter compute to service providers.” This scenario is where the service provider serves as a replication target for the secondary or tertiary replicas of on-premises virtual machines to achieve a disaster recovery capability without the expense of a second or third datacenter being incurred by the customer.

The typical scenario for Hyper-V Replica is replicating virtual machines from your primary datacenter to a secondary datacenter. With Windows Server 2012 R2, the ability to replicate to a third or tertiary datacenter was introduced. Figure 4-6 illustrates this capability from a private cloud perspective.

With the addition of a service provider cloud and assuming the service provider enables the capability, the service provider could host either the secondary or the secondary and tertiary replicas. Figure 4-7 illustrates both design options

The above scenario can be highly valuable both for enterprises and service providers because maintaining secondary or disaster recovery datacenters is a significant cost for enterprises that can be reduced by leveraging a service provider. For service providers, this is a net new service they can offer to customers. This is another example of the new approaches to IT challenges enabled by the Cloud OS.

Conclusion

In this book we’ve described the vision of the Cloud OS and detailed the architectures and capabilities of the Windows Server 2012 R2 and System Center 2012 R2 private and service provider clouds as well as the Windows Azure public cloud. The combination of the three, as illustrated in Figure 4-8, comprises the Cloud OS hybrid infrastructure. System Center delivers the integrated cloud platform management suite required to utilize all three cloud types as a single platform.

The hybrid infrastructure enables an IT organization to provide a robust cloud service catalog consisting of infrastructure and platform capabilities such as virtual machines, web sites, and storage. The cloud service catalog might have multiple items of the same type (such as virtual machines), each with different cost, performance, SLA, and other characteristics depending on the cloud type they are hosted in. This enables IT consumers to choose the cloud service and cloud type or location which is most optimal for their use case. The Microsoft Cloud OS hybrid infrastructure provides a common virtualization, identity, data, management, and development platform across all three cloud types while delivering a common user interface and experience for both administrators and consumers.