Part 7 of a 9-part series. Today’s post is the 2nd of two sections; to read the first half, click here.
     

As an industry we have worked on disaster recovery (DR) and high availability (HA) solutions for – well, it seems like forever.  There has been a lot of good work done in this space, but one thing that has always stood out to me has been the fact that, for any enterprise to truly establish a solid DR solution, the costs have been incredibly high.  So high, in fact, that these costs have been totally prohibitive; you could argue that building a complete DR solution is a luxury reserved for only the largest organizations.

One thing that I admired about Microsoft before joining the company – and something that I have come to appreciate even more since working here – is the relentless effort we make to simplify challenges and problems, to make the solutions approachable for all, and to deliver the solutions at an economical price. 

With Windows Server 2012 R2, with Hyper-V Replica, and with System Center 2012 R2 we have delivered a DR solution for the masses.

This DR solution is a perfect example of how the cloud changes everything. 

Because Windows Azure offers a global, highly available cloud platform with an application architecture that takes full advantage of the HA capabilities – you can build an app on Azure that will be available anytime and anywhere.  This kind of functionality is why we made the decision to build the control plane or administrative console for our DR solution on Azure. The control plane and all the meta-data required to perform a test, planned, or unplanned recovery will always be available.  This means you don’t have to make the huge investments that have been required in the past to build a highly-available platform to host your DR solution – Azure automatically provides this.

(Let me make a plug here that you should be looking to Azure for all the new application you are going to build – and we’ll start covering this specific topic in next week’s R2 post.)

With this R2 wave of products, organizations of all sizes and maturity, anywhere in the world, can now benefit from a simple and cost-effective DR solution.

There’s also another other thing that I am really proud of here: Like most organizations, we regularly benchmark ourselves against our competition.   We use a variety of metrics, like: ‘Are we easier to deploy and operate?’ and ‘Are we delivering more value and doing it a lower price?’  Measurements like these have provided a really clear answer: Our competitors are not even in the same ballpark when it comes to DR.

During the development of R2, I watched a side-by-side comparison of what was required to setup DR for 500 VMs with our solution compared to a competitive offering, and the contrast was staggering. The difference in simplicity and the total amount of time required to set everything up was dramatic.  In a DR scenario, one interesting unit of measurement is total mouse clicks. It’s easy to get carried away with counting clicks (hey, we’re engineers after all!), but, in the side-by-side comparison, the difference was 10’s of mouse clicks compared to 100’s. It is literally a difference of minutes vs. days.

You can read some additional perspectives I’ve shared on DR here.

In yesterday’s post we looked at the new hybrid networking functionality in R2 (if you haven’t seen it yet, it is a must-read), and in this post Vijay Tewari (Principal Program Manager for Windows Server & System Center) goes deep into the architecture of this DR solution, as well this solution’s deployment and operating principles.

As always in this 2012 R2 series, check out the “Next Steps” at the bottom of this post for links to a variety of engineering content with hyper-technical overviews of the concepts examined in this post.

* * *

Disaster Recovery (DR) solutions have historically been expensive and complex to deploy. They require extensive configuration, and they do not work at cloud scale. Since current solutions fall short of addressing many DR needs due to their cost and complexity, workloads in need of protection are left vulnerable, and this exposes businesses to a range of compliance and audit violations. Moreover, because so many of these solutions are built using components from multiple vendors, any attempt to provide simplicity through a single pane of management is nearly impossible.

To address this need, Microsoft embarked on a journey to resolve these issues by delivering Hyper-V Replica (HVR) as a standard feature in Windows Server 2012. From the moment it entered the market, top reviewers and customers saw value in HVR and consistently ranked it amongst ‘the Top 10 features’ of the entire release.

In the R2 release we are following up on this success by providing a cloud-integrated solution for DR. This solution builds on some key enhancements in Windows Server 2012 R2 HVR around variable replication frequency, support for near-sync, and extended replication. From a management standpoint, we provide a DR solution via Windows Azure Hyper-V Recovery Manager (HRM), that is integrated with System Center Virtual Machine Manager (VMM). HRM is currently in limited preview and will be broadly available in the near future.

Our singular focus with HRM is democratizing Disaster Recovery by making it available for everybody, everywhere. HRM builds on the world-class assets of Windows Server, System Center, and Windows Azure and it is delivered via the Windows Azure Management Portal. Coupled with Windows Azure Backup (WAB), which offers data protection or backup, HRM completes the “Recovery Services” offering in Windows Azure. To know more about WAB, read this blog.

The key scenario that we want to address is to providing a simple, easily deployed and simple to operate DR solution that provides

• Pairing of “VMM clouds” from different sites for DR.
• DR for VM’s deployed via VMM .
• An established relationship between a primary and secondary site.
• Ability for a customer to mark VM’s they want replicated.
• An in-box capability for data replication (HVR).
• An orchestration engine that facilitates creation of a DR plan which dictates the sequence of shutdown and bring up of VM’s in the event of a test, planned, or unplanned invocation of the DR plan.
• A cloud-based service which provides the orchestration and management experience for operating DR.

There are five key tenets for the DR solution:

1) Simplified deployment and operation

DR software is itself susceptible to the disasters that can hit the datacenters. We wanted to ensure that the core capability that provides DR is itself highly available, resilient and not subject to failure for the same reasons the customer’s workloads are failing. With these facts in mind, the control plane of our solution (HRM) is delivered as a cloud service we call DRaaS (Disaster Recovery as a Service). HRM has been built as a highly available service running on Windows Azure.

From an operations perspective, independent of which site you are administering, the recovery actions need to be taken only in a single place, i.e. the HRM portal. Since the metadata required for orchestration resides in the cloud, you are insured against losing the critical DR orchestration instructions even if your primary site is impacted, thereby addressing the common mistake wherein the monitoring system monitors itself.

By making the DR plans securely accessible everywhere, HRM drastically reduces the amount of lost time currently suffered by the business when initiating a disaster recovery. A customer DR plan may involve multiple sites. HRM manages multiple sites, as well as complex inter-site relationships, thereby enabling a customer to create a comprehensive DR plan. On the deployment side, HRM requires only one provider to be installed per VMM server (a single VMM server can manage 1,000 virtual hosts), thereby addressing the ever-present issue of complexity (the single most important blocker of DR deployments today).

2) Enlightened with VMM

Built on top of Virtual Machine Manager (VMM), HRM leverages existing investments that your fabric administrators have made in topology and management configurations. By leveraging your existing datacenter intelligence, HRM ensures there is no reason to worry about supporting/creating redundant configurations or managing multiple tools. Via deep VMM integration, HRM monitors environment changes in the datacenter and reacts appropriately to them.

3) Works at cloud scale for all clouds

HRM works at the logical abstractions of VMM, making it a truly cloud-scale solution. Built on cloud point design from a ground-up, the solution is elastic and can easily scale to deployments of large scale.

HRM is available 24x7 because, frankly, you don’t want to invest in a DR solution for your DR solution. The reality is that customers will have different clouds as targets – private, hosted or public clouds. The HRM solution is designed to deliver consistent experience across all clouds, while reducing the cost of re-training personnel for each new deployment/topology.

4) Application level failover

With its scripting support, HRM orchestrates the failover of applications even in scenarios where different tiers are protected by heterogeneous replication technologies.

For example, a typical app that you could protect with HRM can have a virtualized front-end paired with a backed in SQL protected via SQL AlwaysOn. Capabilities within HRM orchestration can seamlessly failover such applications with a single click.

5) Service approach with extensible architecture

The HRM solution is engineered to deliver an extensible architecture such that it can enable other scenarios in the future, as well as ensure that partners can enrich, extend, or augment those scenarios (e.g. newer storage types, additional recovery objectives, etc.). With increasing deployment complexity and with systemic disasters becoming increasingly commonplace, DR solutions must keep pace. The service approach ensures that we can get these innovations out to customers faster than ever before.

Given these benefits, you should be able to roll-out the solution and protect your first virtual machine in hours!

The following sections analyze how these tenets are delivered.

Architecture

The HRM service is hosted in Windows Azure and orchestrates between private clouds built on the Microsoft cloud stack of Windows Server and System Center. HRM supports Windows Server 2012/Windows Server 2012 R2 and System Center 2012 SP1, System Center 2012 2012 R2 VMM.

The diagram below captures the high level architecture of the service. The service itself is in Windows Azure and the provider installed on the VMM servers sends the metadata of the private clouds to the service, which then uses it to orchestrate the protection and recovery of the assets in the private cloud. This architecture ensures the DR software is protected against disasters.

Since a key goal of this DR solution is extensibility, the replication channel that sends the data is highly flexible. Today, the channel supports Hyper-V Replica.

Within this architecture, it is important to note the considerable investments made towards security:

• Application data always travels on your channel. For some customers, regulatory compliance requires that application data reside within the confines of their datacenters and, to accommodate these situations, the DR solution is designed such that application data does not goes to Windows Azure. Only metadata (like names of logical clouds, virtual machines, networks etc.) which is needed for orchestration is sent to Azure. And even then, all the traffic sent to/from Azure is encrypted. Application data is sent directly from the primary site to the secondary site.
• Standard HTTPS rules: The HRM provider installed on the VMM server talks to Azure and never the other way around thereby eliminating any custom configuration of firewalls.
• There is no exposure of Hyper-V Hosts. Instead, the architecture requires only the VMM Server to communicate with Azure. As a result, the Hyper-V hosts don’t need to be exposed to the Internet.
• Support for proxy. With the above point in mind, a logical question is whether or not, the VMM Server has to be exposed directly to the internet? The answer is no. The VMM Server can be behind a proxy for higher security and HRM will continue to work seamlessly once you choose the right option in your registration.
• Selective publishing of meta-data. If there are some clouds in VMM that you do not want to offer protection, there is support to ensure that this metadata is not sent to Azure. This is done via a single check-box opt-out.

Overview of the solution

The goal of the HRM solution is to have your workloads protected in a couple of hours. The “How To” steps for doing this are here. Let’s examine how to plan, roll out and use HRM.

Before you begin setting up HRM, you should first plan your deployment from a capacity, topology and security perspective. In the early configure phase, you should map the resources of your primary and secondary sites such that during failover the secondary site provides the resources needed for business continuity. After that, you should protect  Virtual Machines and then create orchestration units for failover. Finally you test and fail them over.

Before we look at these phases, here are a couple notes to consider

1. Two critical factors are used to measure DR solutions
   1. Recovery point object (RPO) i.e. the amount of data loss you are willing to tolerate.
   2. Recovery Time Objective (RTO) i.e. the amount of time taken to bring the workloads up again in case of a disaster.
2. For illustration, let’s look at the following example:

• VMM-NewYork managing a site in New York having a cloud Gold
• VMM-Chicago managing a site in Chicago having a cloud Gold-Recovery
• Virtual Machines from NewYork (primary site) are protected by replicating them into Chicago (secondary site).

With these things in mind, here is how to plan your HRM deployment:

Deploy

To deploy the solution, you need to download a single provider and run through a small wizard on the VMM Servers in NewYork and Chicago. The provider is downloaded from the Windows Azure portal from the Recovery Services tab.

The service can then orchestrate DR for workloads hosted by Hyper-V on the primary site. The provider, which runs in the context of VMM, communicates with HRM service. No additional agents, no software and no complex configurations are required.

Compute & Memory

To map the resources for compute and memory, you configure the “Protected Items”, which represent the logical clouds of VMMs. For example, to protect the Gold cloud in VMM-NewYork by the Gold-Recovery of VMM-Chicago, you choose values for simple configurations like replication frequency. You need to ensure that the capacity of the Gold-Recovery cloud will meet the DR requirements of virtual machines protected in the Gold cloud.

Once this is done, the system takes over and does the heavy lifting. It configures all the hosts in both the Gold and Gold-Recovery clouds with the required certificates and firewall rules - and it configures the Hyper-V Replica settings for both clusters and stand-alone hosts.

The diagram below shows the same process with hosts configured.

Note that the clouds, which are the resources for compute and memory, are shown in the tab “Protected Items” in the portal.

Network

Once you have the cloud configured for protection, the next task is network mapping. As a part of that initial VMM deployment you have already created the networks on the primary and the corresponding networks on the recovery, now you map these networks on the service.

This mapping is used in multiple ways:

1. Intelligent placement of virtual machines on the secondary site is carried out by augmenting the VMM placement logic. For example, when a replica virtual machine is created on the secondary site, it is placed on a host that has the necessary access to all the required networks.
2. During failover, the virtual machines are connected to the right networks and then booted up. This ensures business continuity in the true sense, as the workloads are not just up and running but also accessible to the clients.
3. If you are using static IPs (and this is most likely the case), the service will reserve an IP address for the virtual machine and inject the same into the virtual machine on failover. As a result, there are no manual steps required to inject the IP inside each virtual machine.

Network mapping works for the entire gamut of networks – VLANs or Hyper-V Network Virtualization. It even works for heterogeneous deployments, wherein the networks on primary and recovery sites are of different types.

The diagram below shows the tenant networks of the multi-tenanted Gold cloud as mapped to the tenant networks of the multi-tenanted Gold-Recovery cloud – the replica virtual machines are attached to the corresponding networks due to this mapping. For example, the replica virtual machine of Marketing is attached to Network Marketing Recovery since (a) the primary virtual machine is connected to Network Marketing and (b) Network Marketing in turn is mapped to Network Marketing Recovery.

Recovery Plans (RPs)

For automated recovery, there are Recovery Plans, which is the orchestration construct that supports dependency groups and custom actions. Today, organizations create documents detailing their disaster recovery steps. These documents are cumbersome to maintain and even if someone made the effort to keep these documents up-to-date, they were prone to the risk of human errors by the staff hired to execute these plans.

RPs are the manifestation of our goal of ‘simplify orchestration’. With RPs, data is presented in the recovery plan view to help customer’s compliance/audit requirements. For example, in a quick glance customers can identify the last test failover of a plan or how long ago they did a planned failover of a recovery plan.

Recovery plans work uniformly for all the 3 types of failovers, namely Test Failover, Planned Failover, and Unplanned Failover. In a recovery plan, all virtual machines in a group fail over together thereby improving RTO. Across groups, the failover is in a sequence thereby preserving dependencies - Group1 followed by Group2, and so on.

In recovery, there is a continuum based on customer needs and expertise (as illustrated in the timeline below).

• Day-1: Customer does a test failover of a Virtual Machine.
• Day-5: They graduate to creating a recovery plan for applications and define the Virtual Machines in the RP; a single click will fail the entire list together.
• Day-7: Move the virtual machines into groups of dependencies.
• Your app needs certain additional steps at various phases before, during, or after the failover of the virtual machines.
• Day-10: By this time you would have added manual actions, for example updating the DNS entry. When you failover with these manual steps, the rich RTO analysis provided by the jobs will show that certain tasks (like the manual action) are taking too long and not allowing you to meet your compliance requirements.
• Day-15: Replace some of the manual steps with scripts. You are now closer to being a Zen of DR Orchestration.

DR Drills

Organizations use DR drills, known as Test Failovers in the solution, for various purposes, such as compliance reasons, training staff around roles via simulated runs, verification of the system for patching, etc.

HRM leverages HVR and the networking support in VMM to deliver simplified DR drills. In most DR solutions, drills either impact production workloads or the protection of the workloads which makes it hard to carry out testing. HRM impacts neither, making regular testing a possibility.

To increase the quality of testing in an automated manner, and help customers focus on truly testing the app, a lot of background tasks are taken care of by the system. The DR Drill creates the required Test Virtual Machines in the right mode.

From the network perspective, the following options are available to run test failovers:

• No Networks: You will choose this when you wish to test the replication channel alone.
• Existing VM Networks: You will use this if you have created test VM Networks.
• Logical Networks: You can leverage this if you want HRM to create test VM Networks. Based on the Virtual Machines participating, the HRM service figures out the VM Networks needed, creates them, and attaches the Virtual Machines to the right VM Networks. In the case of Windows Network Virtualization, the network settings will be carried forward from the replica network to the test network.

Once you signaled that DR drills are completed, the system cleans up whatever it has created.

Planned Failovers (PFO)

In the following cases, you need planned failover. Some compliance requirements for organizations mandate the failover of workloads twice-a-year to the recovery site and then running it there for a week. A typical scenario is if the primary site requires some maintenance that prevents applications from being run on that site.

To help customers fulfill these scenarios, HRM has first-class support for planned failover through its orchestration tool, RP. As part of PFO, the Virtual Machines are shut-down, the last changes sent over to ensure zero data loss, and then virtual machines are brought up in order on the recovery site.

After a PFO you can re-protect the virtual machine via reverse replication, in which case the replication goes in the other direction – from VMM-Chicago to VMM-NewYork. Once the maintenance is completed or the compliance objectives are met, you do a PFO in a symmetric manner to get back to VMM-NewYork. Failback is single click gesture which executes planned failover in the reverse direction.

Unplanned failovers

Much like insurance, we hope a customer never needs to use this! But, in eventualities such as natural disasters, this ensures that designated applications can continue to function. In the event of unplanned failovers, HRM attempts to shut down the primary machines in case some of the virtual machines are still running when the disaster strikes. It then automates their recovery on the secondary site as per the RP.

Despite all preparations, during a disaster things can go wrong. Therefore, an unplanned failover might not succeed in the first attempt and thus require more iteration. In the solution, you can re-run the same job and it will pick up from the last task that completed successfully.

Like in PFO, failback after unplanned failover is a single click gesture to execute planed failover in the reverse direction. This brings about a symmetric behavior in these operations.

Various Topologies

Topologies evolve in an organization with growth, deployment complexities, changes in environments, etc. Unlike other solutions, HRM provides the ability to administer various different topologies in a uniform manner. Examples of this include an active-active wherein the NewYork site provides protection for Chicago and vice-versa, many sites being protected by one, complex relationships, or multiple branch offices going to a single head office. This enables capacity from secondary sites to be utilized and not reserved while not running the workloads from the primary site.

Monitoring

With DR solutions comes a strong need for a simple and scalable monitoring. HRM delivers on this by providing the right view for the right jobs. For example, when a user takes an action on the HRM portal to setup infrastructure, HRM recognizes that he would be monitoring the portal to ensure the action succeeded. Therefore a rich view is present on the portal in the “Jobs” tab to help this user monitor in-progress jobs and take action on those that are waiting for action. On the other hand, when the user is not proactively monitoring the portal and the system needs to draw attention, this is provided through integration in the Operations Manager (SCOM).

The table below captures this continuum and shows how all the required monitoring needs of the users are met.

Since all DR tasks are long-standing, workflows are created by the system. We have built a rich jobs framework that helps you monitor the jobs, query for previous jobs, and export the jobs. You can export the jobs to keep an audit book of the same, as well as track the RTO of the recovery plans to help, the jobs report task-level time granularity.

       

VMM Topolgies

First, a highly available, or HA VMM, is a recommended deployment for VMM to protect against downtime due to maintenance/patching of VMM both on the primary and secondary site. HRM works seamlessly in this case: You can failover the VMM service from one VMM server to another and the management and orchestration will fail over seamlessly.

Second, there are scenarios wherein users use one VMM to manage both the sites – primary and secondary. An example of this is when one admin is managing both the sites (and these sites happen to be close by to each other), therefore wanting to see the virtual machines of both sites in one console. HRM supports a single VMM scenario and enables pairing of clouds administered by the same VMM Server.

Note that in the event of a complete failure of the primary site, a customer has to recover the VMM server itself on the secondary site before proceeding. Once VMM is up on the secondary site, the rest of the workloads can be failed over.

* * *

Microsoft’s DR solution addresses a key gap in the disaster recovery market around simplification and scale. Delivered as a service in Azure, HRM is designed to enable protection for many workloads that are currently lacking protection, thereby improving business continuity for organizations.

A solution like this is a game-changer for organizations of any size, and it is an incredibly exciting thing for the Windows Server, System Center, and Windows Azure teams to deliver.

- Brad

NEXT STEPS:

To learn more about the topics covered in this post, check out the following articles:

• Update:  HRM is now available!       
  Follow this link to learn more about HRM and how to use it.  Also, here’s more info about its adoption.
• Recovery Services
  For more information about the services of backup and DR, see the product information page of the service.
• Implementing Enterprise-Scale Disaster Recovery with Hyper-V Replica, Windows Network Virtualization and Microsoft System Center 2012 SP1
  In this channel 9 video session from North America, you can learn more details and demos of how to leverage Hyper-V Recovery Manager to roll out a DR solution.   
• Step-by-step Guide
  Learn about setting up Hyper-V Recovery Manager in your deployment through a step-by-step guide.
• Walkthroughs on MSDN
  This technical overview covers high level architecture, various features and components of HRM.
• Windows Azure Management Portal
  Learn about the Windows Azure management portal and the various services offered under Windows Azure.
• Network Virtualization Technical Details
  Cloud-based datacenters can provide many benefits such as improved scalability and better resource utilization. To realize these potential benefits requires a technology that fundamentally addresses the issues of multi-tenant scalability in a dynamic environment. Hyper-V Network Virtualization was designed to address these issues and also improve the operational efficiency of the datacenter.

Part 9 of a 9-part series.

 

A major promise underlying all of the 2012 R2 products is really simple: Consistency.

Consistency in the user experiences, consistency for IT professionals, consistency for developers and consistency across clouds. A major part of delivering this consistency is the Windows Azure Pack (WAP). Last week we discussed how Service Bus enables connections across clouds, and in this post we’ll examine more of the PaaS capabilities built and tested in Azure data centers and now offered for Windows Server. With the WAP, Windows Server 2012 R2, and System Center IT pros can make their data center even more scalable, flexible, and secure.

Throughout the development of this R2 wave, we looked closely at what organizations needed and wanted from the cloud. A major piece of feedback was the desire to build an app once and then have that app live in any data center or cloud. For the first time this kind of functionality is now available. Whether your app is in a private, public, or hosted cloud, the developers and IT Professionals in you organization will have consistency across clouds.

One of the elements that I’m sure will be especially popular is the flexibility and portability of this PaaS. I’ve had countless customers comment that they love the idea of PaaS, but don’t want to be locked-in or restricted to only running it in specific data centers. Now, our customers and partners can build a PaaS app and run it anywhere. This is huge! Over the last two years the market has really began to grasp what PaaS has to offer, and now the benefits (auto-scale, agility, flexibility, etc.) are easily accessible and consistent across the private, hosted and public clouds Microsoft delivers.

This post will spend a lot of time talking about Web Sites for Windows Azure and how this high density web site hosting delivers a level of power, functionality, and consistency that is genuinely next-gen.

Microsoft is literally the only company offering these kinds of capabilities across clouds – and I am proud to say that we are the only ones with a sustained track record of enterprise-grade execution.

With the features added by the WAP, organizations can now take advantage of PaaS without being locked into a cloud. This is, at its core, the embodiment of Microsoft’s commitment to make consistency across clouds a workable, viable reality.

This is genuinely PaaS for the modern web.

Today’s post was written by Bradley Bartz, a Principal Program Manager from Windows Azure. For more information about the technology discussed here, or to see demos of these features in action, check out the “Next Steps” at the bottom of this post.

* * *

 

Over the past decade, we’ve seen a dramatic shift in how developers build applications. Modern applications frequently reside on the web, and this shift is driving massive demand for scalable, secure, and flexible ways to host web applications across public and private clouds.

Developer and IT Pro Experiences

Web Sites for Windows Server, included in the Windows Azure Pack, provides a Platform as a Service for modern web applications. It delivers both a powerful self-service platform for developers, while serving as a flexible hosting solution for IT professionals. Web Sites does this in a manner which is highly consistent with the Windows Azure Web Sites service. This allows developers and IT professionals to code against and manage a common set of runtimes, experiences, and capabilities – regardless of deployment to the public or private cloud.

Developers and IT pros alike have often struggled with the complexity of web farm configuration and management. By providing a turnkey solution, Web Sites provides developers with the web application services they expect while simplifying administration for the IT professional.

Flexible

Today’s web developer could often be referred to as a “polyglot programmer.” He or she develops in many languages, often selecting the language, database, and tools best suited to solving a given problem. Additionally, many developers don’t start with new applications; instead, they customize an existing application to meet their needs. In either case, Web Sites aims to provide the developer with choice, reducing time to market, and increasing efficiency.

Application Gallery

In addition to providing a best-in-class environment for creating new applications from scratch, the Web Sites service includes a gallery of applications and templates to accelerate application time to market. Popular open source web applications, including DotNetNuke, Umbraco, WordPress, Drupal, and Joomla are packaged and ready for zero-code deployment to the Web Sites cloud. Furthermore, there are a number of templates for creating new .NET, PHP, Node.js, and Python apps.

Deploying Gallery Applications

A developer can create a web site from a template in a few clicks. We will walk through an example of a developer who creates his/her blog using the WordPress application template. To access the gallery, the developer will click ‘New’ in the Consumer Portal and choose to create a new web site from the gallery.

The gallery displays a list of applications that the service provider enables for tenant use. The developer can select WordPress from this list and provide the configuration settings to deploy the application to his/her new web site.

 

In a few seconds, a web site is instantiated on a server that also hosts other tenant web sites which is provided by the shared hosting capability of the Web Sites PaaS. The developer can now monitor, configure and scale this newly created web site from the Consumer Portal.

The URL for the newly created WordPress blog is now available on the Dashboard tab. The developer can share this URL of this web site as needed or associate it with a custom domain name.

Choice of Language

Out of the box, the Web Sites service provides broad language support, including ASP.net, Classic ASP, Node.js, PHP, and Python. Furthermore, if a developer has a preference for a language not included, he or she can provide a generic FastCGI handler used for running applications in his/her web site. By providing broad language support, which has been battle-tested in Windows Azure Web Sites, the private cloud can now provide a broad menu of language options to satisfy the demands of developers.

Choice of Database

Beyond languages and frameworks alone, the Windows Azure Pack also provides SQL Server and MySQL database provisioning as an integral part of the Web Sites provisioning and management experience. Since different languages often hold a database preference, providing database choice through a consistent user interface allows developers to focus on building applications naturally. By delivering these databases as a service, developers can focus on coding rather than database administration.

Choice of Tools

Additionally, we see that developers often prefer a specific set of tools for development and deployment. For .NET developers, we provide best-in-class support for Visual Studio and WebMatrix. Specifically, Visual Studio users can easily import a Publish Settings file which allows one-click application deployment. WebMatrix users, in addition to one-click deployment, can also edit their site live; it is launched by a button in the Service Management Portal. Deep tool integration makes Web Sites a great place to efficiently host existing ASP.NET and Classic ASP web sites.

Both Visual Studio and WebMatrix utilize the Web Deploy publishing endpoint. For more traditional file upload tools, both FTP and FTP-S are supported.

To demonstrate Visual Studio integration, we’ll begin by creating a web site in the Windows Azure Pack and in Visual Studio. You’ll notice that we’ll be creating a web site the same way you would build an application for deployment to IIS or to Windows Azure Web Sites.

After creating a default page, we will download the publishing profile and configure publishing in Visual Studio.

Next, we will import the downloaded publishing profile.

Finally, we will click “Publish” to deploy our application.

In a few moments, the application build will complete and publishing will commence. After Web Deploy syncs changes between the local and remote deployment, the application will be live.

Delivering DevOps

As DevOps becomes an increasingly common phenomenon, we see developers demanding a greater degree of integration between their source control systems and hosting operations. The Web Sites runtime can host a copy of a Git source code repository, allowing rapid iterative development in the private cloud (including rollback to previous versions of the application). By using standard Git commands, a user can push changes from a local repository into the cloud with no special integration. Consequently, cloning applications across clouds becomes a simple task.

To illustrate this, watch how easy it is to create an application and set up deployment from source control in Windows Azure. In this case, we’ve deployed a basic “Hello World” application written in PHP using Git.

Next, create a web site in the Windows Azure Pack, and set up deployment from source control. From here, the Git tools can be used to clone the site from the public cloud into the private cloud. Once cloned, the application can be redeployed to the private cloud with no code changes. Note the consistency across the Azure UI and how the application behaves identically despite deployment to a private cloud.

Delivering this level of Pass functionality is the result of a large number of new and improved features that include cross platform development, zero lock-in, scalability, site mode, horizontal/vertical scaling, speed, multi-datacenter support – to name a few. We’ll use the rest of this post to examine these features and their application in detail.

Cross Platform Development

By supporting FTP, FTPS, Web Deploy, and Git protocols alongside the Service Management Portal, the Web Sites service allows developers to deploy and manage applications in the Private cloud from any client OS, including MacOS, Linux, and Windows.

Zero Lock-in

Because the Web Sites runtime can be hosted by Microsoft, enterprises, or hosting service providers, developers can confidently deploy their applications. Should a developer need to migrate his or her application to a different cloud, he or she can do so quickly and simply without code changes. For customers looking to outsource hosting of web applications, they can leverage Windows Azure or hosted offerings from other third party hosting service providers.

Scalable

Web Sites provides a high degree of scalability. By de-affinitizing web applications from a single server, apps can dynamically execute on any server in a given cluster at any point in time. This allows the Web Sites service to rapidly respond to changing operating conditions. In the event of server failure, requests are load balanced and rerouted to a healthy machine in the farm to maintain application availability. Should an application require additional resources, developers or IT pros can quickly and easily allocate additional resources to the web app to preserve SLAs.

Site Mode

The Web Sites service provides two site modes – Shared Mode and Reserved Mode. Shared Mode runs sites from multiple tenants on a single server to maximize density and minimize operational costs. Shared Mode works quite well for development or testing scenarios. Reserved Mode runs sites for a single tenant in a pool of servers to maximize performance and improve isolation. Often, Reserved Mode is used for production applications. Since switching between execution modes is delegated to the developer, he/she can quickly choose the execution mode best suited to his/her application.

Horizontal and Vertical Scaling

Application scaling strategies often follow two patterns – horizontal and vertical. The Web Sites runtime supports both; developers can run multiple instances of their applications in both Shared and Reserved Modes. In addition, inside of the Reserved site mode, developers can opt to scale vertically by choosing between three instance sizes (Small, Medium, and Large). By delivering multiple scaling options, developers and IT professionals alike can select the optimal way to host their applications.

Speed and Agility

Because the Web Sites runtime focuses on delivering a finished service (web application hosting), application provisioning and management functions are orders of magnitude faster than infrastructure-based services. Since applications exist as configuration metadata and content, creation and publishing activities complete in seconds rather than minutes – all leading to increased productivity and decreased time to market.

Multi-Datacenter Support

As end users become increasingly connected via devices, performance expectations increase. Multinational corporations expect a worldwide web application presence. With multi-cloud support, service administrators can deploy multiple Web Site clouds to different geographies. Since these clouds are consumed via the same Service Management Portal, developers can easily deploy applications around the globe with minimal time and effort.

Secure

As web applications are often internet facing, security is a critical design point. In this release, the Web Sites service has been enhanced to deliver a secure application hosting experience through robust SSL support. In addition, the feed-based update mechanism allows service administrators to keep the Web Sites cloud current with the latest updates.

SSL and HTTPS

Because the secure transport of information to and from Web Sites is critical, the service provides two varieties of SSL support:

1. Shared SSL Support
   By default, all created sites are accessible via SSL using a shared certificate. This ensures that developers can use HTTPS immediately following site creation without further interaction.
2. Custom SSL Support
   For developers using custom domain names, they can upload a custom SSL certificate for transport encryption. The runtime supports two types of SSL bindings:

• SNI SSL, which provides simplified administration and allows multiple sites using multiple certificates to reside on the same IP address. SNI SSL works out of the box without further configuration.
• IP SSL, which maximizes compatibility with older browsers. The runtime contains built-in functionality to orchestrate IP SSL configuration across the Front End server(s) and upstream load balancer(s).

Always Current

The Web Sites cloud incorporates a large number of first and third party dependencies to deliver turnkey operation. However, initial deployment is only a small portion of the overall service lifecycle. By integrating Microsoft Update with our feed-based provisioning process, Microsoft is able to deploy updates to both Microsoft and non-Microsoft software. By keeping the cloud up to date, Microsoft helps you maintain a secure and highly compatible application hosting environment.

Additional R2 Features

With the 2012 R2 release of Windows Server, System Center, and the Windows Azure Pack, we ensured that great new scenarios light up across our server operating system, management tools, and cloud runtimes. As a result, we have several new features which will provide developers exciting ways to build innovative applications:

• WebSocket Protocol Support
  As mobile devices and interactive applications become the norm, we see that new application models are emerging. While traditional web applications employ a “pull” model, where the browser pulls information from the server, we are seeing an increased need for “push” models, where the server is able to push information to a large number of clients at the same time. The WebSocket protocol, now available in the R2 release of Web Sites for Windows Server, allows developers to build rich, interactive applications using this new communication mechanism.

• 64-bit Worker Processes
  As developers build increasingly complex web applications, large memory footprints are often required. At the same time, many of the open source languages and frameworks are optimized for 32-bit processes. In this release, we allow tenants to select 32 or 64-bit worker processes to best suit their needs.

• IPv6 Support
  As the number of internet-connected devices increases, the scarcity of IPv4 addresses is becoming increasingly problematic. The R2 release of Web Sites implements IPv6 support in a transparent manner, allowing end users to easily access hosted sites via IPv4, IPv6, or IPv4 and IPv6. This support includes not only HTTP traffic, but also traffic encrypted over HTTPS.

Performance Enhancements

Developers always look for ways to improve application performance, especially if optimizations don’t require code changes. For .NET developers, the most frequent performance complaint is the first request to idle applications. We refer to this as the “cold start” problem. With the R2 release, instead of shutting down idle web sites, we page inactive sites. Paging inactive sites involves moving inactive data from memory to disk. This leads to dramatically improved performance by reducing the frequency of cold start events, since the application can quickly be paged back into memory from disk instead of requiring recompilation. We have also optimized the Web Site cloud to improve performance when application cold start is unavoidable.

Running cloud scale services is challenging, and we’ve taken the lessons learned from running Windows Azure and incorporated them into the Windows Azure Pack. First, we’ve built a wholly distributed architecture to improve security and maximize scalability. Next, we’ve simplified visibility into farm operations and server provisioning. Finally, we’ve made it easy to build plans which govern resource consumption within the Web Site cloud.

Architecture

As you can see in the architecture diagram above, the Web Sites service uses a number of roles to deliver services. Each role serves a specific purpose and these concerns are separated to ensure a high degree of security. The Web Sites roles include:

• Management Server
  This is the REST API resource provider endpoint for the Service Management API. All provisioning and management requests from the service management API flow through the Management Servers, including site provisioning, scaling, and configuration tasks.
• Controller
  As the “brain” of the Web Sites cloud, the controller manages software installation and configuration of all servers. In addition, the controller performs health checks and repair operations to maintain farm availability.
• Front End
  Running Application Request Routing, the Front Ends dynamically route application requests to various web servers in the farm based on the heath and configuration of sites in the cloud.
• Web Workers
  These servers execute customer code. Since site configuration is stored in the Runtime Database and site content is stored on the File Server, applications can run across any worker in the farm. Workers are classified in four categories (Shared, Reserved Small, Reserved Medium, or Reserved Large) based on which execution mode they support. In addition, source control operations performed via Git run on worker roles.
• Publishers
  FTP, FTPS, and WebDeploy endpoint(s) for application deployment.
• File Server (optional)
  This stores web site content and custom SSL certificates. It may be deployed by the Web Sites installer for dev/test deployments, or provided externally for production deployments.
• Runtime Database (external)
  Stores the Web Site cloud configuration as well as the configuration for tenant web sites. Centrally storing the configuration allows for dynamic provisioning and management of sites while simultaneously allowing large scale cloud deployments.

Cloud Insight

When building the Web Sites runtime and user interface, we wanted to deliver the same “single pane of glass” for service administrators. We studied the routine activities of cloud admins and realized that there were three primary groups of activities: Server provisioning, cloud health/capacity management, and cloud troubleshooting. To expedite these processes, we created simple ways to complete these tasks within the browser.

Cloud at a Glance

To start, we created a unified view of all Web Sites roles which allows service administrators to view three key elements:

• All servers participating in the Web Sites cloud
• The health of these servers
• The utilization of the various role instances

By consolidating this information into a single view, IT professionals can quickly determine if sufficient capacity is available or if service health is degraded.

 

Managed Provisioning

Should the cloud require additional capacity, the administrator can quickly add additional role instances. Web Sites fully automates deployment and configuration of the runtime onto new machines to seamlessly remediate capacity constraints. To illustrate this functionality, we’ll demonstrate how to provision an additional Small Reserved Instance to deliver additional capacity to developers using the Small Reserved Instance tier of service.

First, click the “Add Role” button, and then select the appropriate role type (Web Worker).

Next, provide the server the name of the machine to be added to the cloud. Finally, specify the worker type.

With a machine name and role type, we can now complete the provisioning and configuration process without further intervention.

Plan/Add-on Authoring

Service administrators also need to define a service catalog to govern resource consumption and employ chargeback/billing for cloud usage. To facilitate this, the Web Sites service provides a robust experience for defining base packages of services (Plans) and incremental capabilities (Add-ons). With this flexibility, administrators can author a comprehensive catalog to meet the differing SLAs of different developers.

Creating a Plan

From the service administrator dashboard, we will start by selecting New, then Plan.

Next, the service administrator must provide a name for a plan.

Then, he/she must select which services are included in the plan and determine which cloud for each service is included in the plan.

Now, the administrator can customize the quotas for each service included in the plans. We will edit the quotas for the Web Sites service.

Once this is complete, the administrator can define resource consumption limits for the plan. Typical resource types, such as CPU time, Memory, Bandwidth, and Storage are all present. In addition, specific features can also be enabled or disabled; this includes custom domain, SSL, WebSocket, 64-bit support, etc.

By customizing plans and add-ons, Web Sites gives the service administrator strict control of how service consumers can use the service. This gives tremendous control over the services provided through a service catalog and also governs usage reporting consumed by chargeback and billing solutions.

* * *

 

 

The Web Site service in the Windows Azure Pack has been built from the ground up to provide developers with a flexible, scalable, and secure platform for hosting modern applications.

As Web Sites is built from the same source code as the Windows Azure service, the Windows Azure Pack provides highly consistent experiences with the Microsoft-operated Windows Azure Web Sites service. For administrators, we have taken knowledge gained from operating our cloud to improve operational efficiency.

Give it a try. The bits and documentation can be found here.

- Brad

NEXT STEPS

• Windows Azure Pack Overview
  Learn more about the WAP, it’s benefits, and what the Microsoft Cloud OS can do for you.
• Download the trial of the Windows Azure Pack
  This includes an overview of the WAP, system requirements, and a step-by-step installation guide.
• The “Windows Azure Pack Overview” whitepaper
  Get really deep with this 25 page analysis of the Windows Azure Pack’s new features.
• “Web Sites in Windows Azure Pack” breakout session
  In this session from TechEd EMEA, you can see some of the new tenant experiences in action.  Be sure to check out the demo starting at 0:28:20 on the integrated source code control and how a developer can use standard Git commands to push an application and associated changes from a local repository into the cloud.
• Windows Azure Pack Preview Forum

Over the last few years I’ve had, in one meeting or another, countless discussions with my teams and colleagues about the size, shape, and impact of the Cloud.  If you’ve been to a Microsoft event like TechEd or MMS, you’ve heard us talk about the Cloud OS and the promises we feel the Cloud OS delivers. 

What can get lost in so much of the discussion, however, is a simple question:  What is the Cloud OS?

This calls to mind an important point made by Server & Tools President, Satya Nadella, at last year’s TechEd Conference.  He noted:

“At the most basic level, any operating system has two “jobs”: it needs to manage the underlying hardware, and it needs to provide a platform for applications. The fundamental role of an operating system has not changed, but the scale at which servers are deployed and the type of applications now available or in development are changing massively.”

This is a critical concept we focus on as we build the tools for private/public/hybrid clouds, and lead the charge to create a new cloud operating system for a new cloud-based era of business.

The Cloud OS has three key pieces that address the operating system “jobs” that Satya noted:  Windows Server 2012 (a cloud-optimized server OS that can support workloads of any size), System Center 2012 (for ops, management, and governance of the datacenter), and Windows Azure (for application development, deployment, and administration).

We deeply understand that customers do not want to feel locked in to any specific cloud, and this is why our promise of consistency across Clouds is such a critical factor for everyone to understand.  Windows Server is the foundation of what we deliver for building Private Clouds, Clouds hosted by Service Providers around the world, and it is also the foundation of Windows Azure. 

When you deploy the Microsoft Cloud OS, you have the flexibility to choose which cloud is best for your business and for the specific application.  There’s no lock-in; you make the choice about what’s best for you.  This promise makes us truly unique in the industry. 

Another thing that sets us apart is the fact that we are the only organization in the world that is taking all the knowledge gained from operating our own massive public cloud, and then packing those learnings for use in enterprise and service provider datacenters.  To further support our community, in January we released, as a free download, Windows Azure Services for Windows Server.  This download is software that we initially developed for use in Windows Azure for scenarios like high-density web hosting.  This is a great example of how we are able to prove and exhaustively test capabilities like this in Azure at a massive scale and then release it for use on Windows Server.  Our on-premises products continually get better from the innovative work we do in Azure.  I think that is pretty cool!

This is a simply amazing advancement in how we think about and execute IT Management.

Microsoft’s ability to provide the Cloud OS is the result of having genuinely battle-tested this software throughout our 16 major data centers around the globe – where we manage hundreds of petabytes and hundreds of distinct workloads.  To really grasp what a major leap forward this is, it helps to stop thinking about IT deployments in terms of the individual servers, and instead think about an OS that runs a datacenter.  This operating system is what provides the intelligence, automation, and orchestration necessary to manage workloads that are increasingly large, complex, and diverse.

As you work to modernize your own data center, keep in mind the “four promises” of the Cloud OS:

1. You can transform your datacenter by thinking above and beyond servers and nodes, and instead focus on managing datacenters and clouds in a comprehensive, scalable, and elastic environment.
2. This scalability and elasticity enables modern apps to be rapidly developed, functional across devices, and manageable in multiple environments.  This means a dynamic, new approach to application lifecycle management, app availability, and IT productivity.
3. Unlock insights on any data thanks to lower storage costs, ever-increasing volumes of available data, cloud-based processing power, and the simple and easy BI solutions currently available from Microsoft.
4. Enable your workforce to be productive anywhere on any device by empowering people-centric IT – and manage these devices and their apps from a single pane of glass.

These are big promises – and they are promises I believe Microsoft is uniquely able to deliver.  In future posts, I’ll continue to talk a lot more about these promises and how we are doing to deliver on them for you.

Over the last two “Best Practices” posts, I’ve looked at how to Plan and Build a Hybrid Cloud, and with these technical exercises complete, this post will focus on the best practices for deploying this carefully planned and built Hybrid Environment.

In this post, I’ll examine some critical items for deployment, like Service Provider Foundation and Windows Azure Pack functionalities like IaaS (Software Defined Networking, Remote Console Setup, Gallery items, VM Templates), Websites (use of Proxy Servers, offline Gallery), and Databases (Microsoft SQL Server, MySQL). I’ll also be looking at vital functions like Service Management Automation, Usage, WAP Authentication Providers, Portal Theming/Customization, and Migration.

I’ll also identify how to troubleshoot some of the most common deployment obstacles. Ready to dig in?

Service Provider Foundation

Service Provider Foundation (SPF) comes as part of System Center - Orchestrator. SPF is an extensible OData web service that interacts with Virtual Machine Manager, Operations Manager, and Orchestrator (among other things) thus enabling these products to be used in a multi-tenant environment such as a Service Provider. In the Cloud OS vision, SPF is key in the communication between Windows Azure Pack and Virtual Machine Manager – but it is also leveraged for the usage consumption pipe enabled with Operations Manager.

Also of note: There is a SPF Server entry for the Remote Console that is part of IaaS, and SPF itself supports up to five VMM stamps.

The best practices for the setup and operation of Service Provider Foundation can be complex without some insight, so I’ll begin with six key pitfalls to avoid during setup:

• SPF IIS App Pool needs to run with a Domain Account that is also a VMM Administrator.
• This Domain Account must be a member of the 4 local SPF Groups.
• The user of this account needs to register SPF in Windows Azure Pack, otherwise Service Management Automation may encounter issue when attaching Runbooks to SPF Action. A local user can be used if no Runbooks are attached to SPF Actions, however.
• This account also needs access to the SQL Server that you specify during deployment.
• Configure IIS on the SPF machine with Basic Authentication.
• Login to the SPF server once with the domain service account.

To get deeper on these particular elements, I recommend reading:

• How to install Service Provider Foundation.
• General Troubleshooting List for Windows Azure Pack.
• Configure SPF for IaaS usage and metering.
• TechEd 2013:  Multi_Tenant IaaS Clouds in Microsoft System Center and Windows Server.

Windows Azure Pack

Windows Azure Pack (WAP) for Windows Server is a collection of Windows Azure technologies that run on top of Windows Server 2012 R2 & System Center 2012 R2 and enable a consistent cloud experience across public, private and hybrid clouds.

I’ve posted many times before on the importance of consistency across your clouds, and, while I don’t want to beat on too much again, it simply cannot be overemphasized that Microsoft is the only organization in the world operating an at-scale, global Public Cloud and then taking what we learn and delivering it for you to use in your datacenter. WAP is concrete evidence of this work.

For the purposes of Deployment, I’m going to focus on three specific resources delivered by WAP: IaaS, Websites, and Databases. If you aren’t familiar with WAP (or if you don’t have it already), I recommend reading this deployment overview for WAP and Windows Server, and this overview of WAP installation and configuration.

IaaS

Windows Azure Pack is a core component of the infrastructure-as-a-service capabilities we deliver through Windows Server and System Center. Our IaaS capabilities allow you to host Windows and Linux virtual machines in a cloud architecture in your datacenters. These capabilities also include a VM Gallery, scaling options, VM access options and virtual networks.  To learn more about the specifics of Microsoft’s IaaS offering, I recommend this article.

Three important elements of the IaaS features include SDN, Remote Console, Gallery items, and VM templates.

Software-defined Networking

A major milestone in networking is the platform capability of an inbox NVGRE Gateway to bridge communication from a VM/Tenant Network to networks outside of the virtualized network. Check out these links for more information on the virtual network capabilities delivered through the platform and how they work within WAP.

• Hybrid Clouds using Hyper-V Network Virtualization:  Part 1, Part 2, Part 3.
• Web Platform Installer Feed (containing the NVGRE Gateway VMM Template).
• Also check out Microsoft’s SDN strategy.

When deploying the HA NVGRE Gateway Service Template available as a free download via the Web Platform installer, keep in mind these three things:

• A host cluster is required for placing the HA Gateway Service (PA Address).
• Don’t make the Gateway VMs highly available because if this occurs the CA Address will no longer follow PA Address.
• Don’t configure your virtual switch manually with absolute QoS mode.

Remote Console

One of the improvements to Virtual Machines is the ability to get a direct connection to the console session. There are a lot of scenarios where this is hugely important, and one in particular is addressing a situation where a tenant miss-configures the network settings and can no longer connect via Remote Desktop. Instead of going through the process of opening a support ticket, the tenant can now fix the problem independently by using the new console connect option.

This diagram outlines the components required when accessing the VM Console from an untrusted network.

You can find detailed setup, installation, and configuration instructions in this guide.

Certificate requirements seem to cause some confusion in this configuration, so let’s examine this for a moment: The certificate used to sign the token between VMM, RD Gateway Plugin and the Hyper-V Host is different from the certificate used to sign the RDP file that gets downloaded in the tenant portal and opened by the client computer. The certificate to sign the RDP file must have the FQDN of the RD Gateway as CN.

Gallery Items

Windows Azure Pack includes a VM Gallery that contains VM Roles. A VM Role technically consists of two parts:

• Resource Definition package: Forms the basis for creating a virtual machine.
• Resource Extension package: Forms the basis for installing applications on a virtual machine.

Part of this configuration of VM Roles requires you to assign specific tags to virtual hard disk images. This configuration also requires the Operating System, Family Name, and Version of the virtual hard disk to be specified. To make this process straightforward, each VM Role example comes with a deployment guide that outlines these requirements. There is also a wide range of example gallery items currently available through the Web Platform Installer, but you can also build your own Gallery Items using the VM Role Authoring Tool.

To get much deeper on this topic, check out these additional posts from the engineers who’ve built these features:

• Enabling On-Prem IaaS Solutions with WAP.
• Troubleshooting Gallery Items:  Part 1, Part 2
• Using Gallery Items in Virtual Machine Clouds.
• Overview of VM Role Authoring Tool.
• Web Platform Installer Feed (containing example Gallery Items).

Websites for Windows Azure

The website component of Windows Azure Pack provides high-density, multi-tenant web hosting services. This is a scalable, shared, and secured web hosting platform for template-based web applications and programming languages like ASP.NET, PHP, and Node.js. This is a capability we innovated in Azure, proved in Azure, and we have now delivered it for you to run in your datacenters. With this functionality you can run 5,000 web sites on a single Windows Server OS instance. To deploy this component, visit this page.

Use of Proxy Servers

Have you ever tried to create a new website based on a Gallery item but found the list empty? The cause of this is very likely that you are blocked by your proxy server. The typical troubleshooting process for this includes checking the proxy server log files and then verifying if you can reach the gallery URL in a web browser on the machine that has the Web Application Gallery component installed.

Offline Gallery

If you are working in a secure environment where you want to control which web application gallery items are available to your tenants, you may consider using an offline copy for the Gallery. This arrangement also allows you to do code reviews and approve the gallery items. For an in-depth overview of the necessary steps to do this, check out this detailed post.

File Server

Windows Azure Pack Web Sites requires a File Server. This can be a standalone File Server, File Server Cluster, or a third party NAS device. For more insights about all the requirements, check out this article.

Databases

Windows Azure Pack has the capability to support Microsoft SQL Server or MySQL Database hosting for tenants or, Database as a Service (DbaaS). These databases are often used in conjunction with Web Sites Services, and are also offered as part of the Windows Azure Pack. To learn more about installing and configuring the SQL Server and MySQL resource providers, checkout this overview.  Also note that for this database functionality you must first license and deploy instances of MySQL or SQL Server outside of WAP (in this way, WAP is used as a means to provision database services).

To provide high availability for your tenant databases you can use SQL AlwaysOn Availability Groups. SQL AlwaysOn enables you to use Azure as an extension of your datacenter for backup and disaster recover or your databases – a very cool and easy to use hybrid cloud scenario. This feature is part of SQL Server Enterprise Edition.  With SQL Server 2012 these backup/DR scenarios are available with manual scripting provided by the SQL engineering team on MSDN; with SQL Server 2014 these scenarios will be much easier with a UI that is built into SQL Server Management Studio.

You can read a lot more about this on these TechNet posts:

• Configure SQL AlwaysOn Availability Groups in Windows Azure.
• Using SQL Server 2012 AlwaysOn Availability Groups with System Center 2012 – Ops Mgr.
• Enable and Disable AlwaysOn Availability Groups.
• Setting up AlwaysOn Availability group on SQL Server 2012.

The latest version of MySQL can be obtained and installed via the Web Platform Installer. The configuration step that is specific to MySQL is to enable remote login. If you miss that important step you will not be able to register MySQL Servers in the Admin Portal.

Service Management Automation

Service Management Automation (SMA) is a new component that comes as part of System Center (available on the Orchestrator image). SMA enables you to perform automation in the cloud, and, like SPF, SMA exposes an extensible OData web service. SMA leverages Runbooks to enable automation in the Windows Azure Pack. SMA Runbooks are Windows PowerShell Workflow scripts, which can be imported and/or authored right within the Windows Azure Pack. Runbook execution can be scheduled, triggered by a WAP/SPF event, or manually initiated. With this in mind, one of the primary uses of Automation within WAP is to execute Runbooks based on other WAP actions, e.g. starting a Virtual Machine.

A couple noteworthy best practices for setting up and operating Service Management Automation are:

• Like SPF, SMA IIS App Pool needs to run with a Domain Account.
• In order to execute Runbooks that use SPF, certificates need to be issued for the SMA server and SPF server which trust each other.
• Runbooks needs to be “tagged” in order to be used for automation (e.g. to show up under VM Automation, a Runbook needs to be tagged with SPF).

For further reading on this particularly complex topic, I recommend the following links:

• Detailed overview and introduction to SMA.
• How to install the Service Management Automation Web Service.
• Calling an Orchestrator Runbook from SMA, Part 1.
• Service Management Automation:  SMA Runbook Toolkit Spotlight–SMART for Runbook Import and Export.

Usage

Tracking Cloud Usage is fundamental. Pairing System Center with Windows Azure Pack offers one of the best ways to deliver usage statistics that enable pay-as-you-go scenarios for the services in WAP. Usage in WAP leverages the following components: Virtual Machine Manager, Operations Manager, Service Provider Foundation and Service Reporting.

With these components, partners and enterprises can extract usage data from Windows Azure Pack by using an OData web service. This then offers three scenarios for usage:

• Chargeback by using CloudCruiser.
• Service Reporting using SQL.
• Building a custom billing adapter.

Some straightforward best practices for setup and operation usage are:

• Operations Manager, Virtual Machine Manger and Service Provider foundation must be in place to enable VM Clouds usage.
• The WAP Usage Service must have a User and Password set before data can be extracted.
• SPF IIS App Pool needs to have read access to Operations Manager Data Warehouse.
• Service Reporting needs access to Operations Manager Operational Database.
• CloudCruiser extension enables chargeback on top of Windows Azure Pack.

For further reading, I recommend the following links:

• IaaS Usage and Service Reporting using System Center 2012 R2 and Windows Azure Pack.
• Configuring VMM and OM for IaaS usage and metering.
• Installing & configuring Service Reporting for IaaS usage and metering.
• Troubleshooting Windows Azure Pack & Usage.

WAP Authentication Providers

Windows Azure Pack supports multi-tenant authentication by using claims-based authentication. This offers a flexible way to authenticate users logging into Windows Azure Pack by providing support for a wide range of authentication technologies like ADFS, SAML, WS and others. Once authenticated a user will be given access to (and can then consume) services within WAP based on assigned subscriptions. By default the WAP Tenant uses .Net authentication, but can easily be changed to use other authentication providers. The WAP Admin Portal uses Windows Authentication by default, but this can also be changed to use ADFS.

Authentication in WAP allows you to do the following two things:

• Provide administrative access to users from its own Active Directory.
• Provide self-service access to the Tenant Portal to users from a tenant.

Some noteworthy best practices for the setup and operation of authentications are:

• Change authentication service in WAP to use CA certificates.
• Configure ADFS to authenticate with WAP.
• Configure ADFS to authenticate with tenants ADFS or other claims-based services.
• Create users in the WAP portal.
• Have users login with their own credentials in the WAP portal and provide them access to WAP.

For further reading I recommend the following links:

• Claims-Based Identity in Windows Azure Pack.
• Federated Identities to Windows Azure Pack through AD FS - Part 1, Part 2, Part 3.
• Creating users in Windows Azure Pack.
• AD FS and the AD FS Console.

Portal Theming – Customization

Windows Azure Pack can be modified to suit partner/enterprise/service provider needs in three primary ways:

• Changing the theme.
• Building a Resource provider.
• Building your own portal.

The portal theme allows simple modification of the portal by customizing the tenant user experience to include custom logos, colors, and icons.

Two best practices to keep in mind for portal theming are:

• Take advantage of the sample theme kit provided with the Windows Azure Pack Developers Kit. This kit demonstrates areas of the tenant portal that can be customized.
• The Contoso theming kit shows images and styles consistent with the branding of an imaginary hosting company named Contoso

For more information, check out these WAP Service Management API Samples.

Migration

There are two key Migration scenarios.

• Migration from Windows Azure Services for Windows Server.
• Integration of WAP to an existing System Center deployment. This scenario targets IaaS workload only.

If you made a bet on Windows Azure Services for Windows Server when it was released earlier this year, definitely take the time to get the newer (and free!) Windows Azure Pack to start taking advantage of the new features. The detailed step by step guide can be found in the link below.

The second scenario mentioned above is all about ensuring existing Virtual Machines show up in WAP Tenant Portal as expected, owned by the appropriate tenant user role.

A couple articles worth noting on this topic:

• Migrate from Windows Azure Services for Windows Server.
• Adding an Already Running VM in VMM to a WAP Subscription.

* * * *

This topic is obviously very complex, and for ongoing information, best practices, and up-to-date knowledge, I highly recommend the Deployment track over on the Building Clouds blog.

After putting this post together I have got to admit that there is some work we need to do to simplify, simplify, simplify.

In the next post we tackle everything that comes after your hybrid environment is deployed: Operation and Management.

In the Day 1 keynote at the recent re:Invent conference, there was an interesting point made about the virtuous cycle that can occur for the cloud vendor and for customers. As I listened to the keynote, I kept thinking: “They are missing the biggest benefit for the entire industry; if the public cloud vendor has the right strategy and is thinking about how to benefit the largest population possible, then they are completely missing how this virtuous cycle can grow to benefit every organization in the world – even if they are not using the public cloud.”

Let me explain a bit more about what I mean.  (And, before I get too much farther along, I want to note that this post ties into the cool news yesterday about our work with the Open Compute Project.)

The virtuous cycle of a public cloud looks a lot like the image below.  As the usage of the public cloud grows, you need more hardware to meet demand – and for sustained growth you will need a lot of hardware. This need for hardware increases your purchasing power and you can then negotiate lower prices as you purchase in bulk. As your purchasing power grows and your costs drop, you then pass those savings on to your customers by dropping your prices. The lower prices increases demand and the virtuous cycle continues.

For customers using the public cloud, they can see the benefits of this virtuous cycle (the lower prices) – but what about organizations that are also using private and hosted clouds? How can they gain benefits from what is happening?

Organizations with multiple clouds can benefit if (and only if!) that public cloud vendor has at the core of its strategy an intention to take everything that it is learning from operating that public cloud and delivering it back for use in datacenters around world – not just in its own.

This is where Microsoft is so unique! Microsoft is the only organization in the world operating a globally available, at-scale public cloud that delivers back everything it is learning for use in datacenters of every customer (and, honestly, every competitor). Our view is the learning that we are getting from the public cloud should be delivered for all the world to benefit.

This innovation can be seen by applying these public cloud learnings in products like Windows Server, System Center, and the Windows Azure Pack – and these products are the only cloud offerings that are consistent across public, hosted and private clouds – ensuring customers avoid cloud lock in and, maximize workload mobility, and have the flexibility to choose the cloud that best meets their needs.

With this in mind, I want to show you how I think the virtuous cycle can and should look – and how it can benefit any organization in the world.

First, at the center of this virtuous cycle is incredible innovation. This means innovation in software, innovation in hardware, and innovation in processes. When you are ordering and deploying 100,000’s of new servers and xx bytes of storage every year – you have to innovate everywhere or you will literally buckle under demands and costs of procuring, deploying, operating, and retiring hardware at this scale.

Microsoft is addressing this challenge in the most direct and complete way possible: Over the last three years, Microsoft has spent more than $15B building datacenters around the world and filling them with the hardware and capacity demanded by customers of Windows Azure and other Microsoft cloud services.

We keep our public cloud costs low by managing our supply chain for this kind of capacity, and, per the cycle, we pass these savings to you. We also carefully track things like the number of days from when we place an order for hardware to the time the order appears on our docks (“order-to-dock”), and then we track the number of hours/days from “dock-to-live” where we literally have customers’ workloads being hosted on that hardware. Throughout this process we set aggressive quarterly targets and we work constantly to consistently drive those numbers down. If we didn’t have a best in class product and performance, it would be impossible to remain profitable at this kind of scale.

As you can imagine, after spending $Billions on hardware every year, we are highly incented (to put it lightly) to find ways to drive our hardware costs down. The single best way we have found to do this is to use software to do things traditionally handled by hardware. For example, in Windows Azure we are able to deliver highly available, globally available storage at incredibly low prices through software innovations like SDN – all of which is based on low-cost, direct-attached storage. This brings storage economics never before seen in the industry.

One example of this is the most common workload hosted in Azure: The “Web” workload. Whether it is Azure acting as the web tier for hybrid application, or the entire workload being hosted in Azure, the web workload is a part of just about every application. This makes it a great place for innovation. In Azure we pioneered high-density web site hosting where we can literally host 5,000+ web sites on a single Windows Server OS instance. This dramatically reduces our costs, which in turn reduces your costs.

At Microsoft, we think the public cloud’s virtuous cycle can actually get a lot bigger, a lot more functional, and a lot more powerful by integrating service providers and hosted clouds.

Not only is this expanded virtuous cycle more practical, I’m sure it also looks familiar to what is already up and running in your organization.

There are some pretty solid examples of innovation that was pioneered in Azure and then brought to the whole industry for use everywhere through Windows Server and System Center:

• For highly available, low-cost direct attached storage, in Windows Server 2012 we shipped a set of capabilities we call Storage Spaces. Storage Spaces delivers the value of a SAN on low-cost, direct-attached storage, and it has been widely recognized as one of the most innovative new capabilities in Windows Server – and it was significantly updated in Windows Server 2012 R2.
• Service Bus provides a messaging queue solution in the public cloud that can be used by developers for things like a queuing system across clouds and building loosely coupled applications. Check this post for an in-depth review of Service Bus. Service Bus also ships as a component of the Windows Azure Pack – providing value pioneered in the public cloud for use in private and hosted clouds.
• Earlier I referenced the ability to host 5,000+ web sites on a single Windows Server OS instance. This has had an obvious economic impact on of costs of Windows Azure where we host millions of web sites. We proved that capability in Windows Azure, battle-hardened it, and now it ships for customers around to world to use in their datacenters as a part of what we call the Windows Azure Pack (WAP).

This is what it looks like when the complete virtuous cycle is in effect.

Our efforts haven’t been limited to software, however. Our innovative work with hardware in our datacenters has driven down costs while at the same time increasing the capacity each core and processor can support.

Our work with hardware was highlighted yesterday when we announced that we are joining the Open Compute Project and contributing the full design of the server hardware we use in Azure. We refer to this design as the “Microsoft cloud server specification.” The Microsoft cloud server specification provides the blueprints for the datacenter servers we have designed to deliver the world’s most diverse portfolio of cloud services at global scale. These servers are optimized for Windows Server software and can efficiently manage the enormous availability, scalability and efficiency requirements of Windows Azure, our global cloud platform.

This design spec offers dramatic improvements over traditional enterprise server designs: We have seen up to 40% server cost savings, 15% power efficiency gains, and a 50% reduction in deployment and service times. We also expect this server design to contribute to our environmental sustainability efforts by reducing network cabling by 1,100 miles and metal by 10,000 tons.

This level of contribution is unprecedented in the industry, and it hasn’t gone unnoticed by the media:

• Wired: Microsoft Open Sources Its Internet Servers, Steps Into the Future
• Forbes: The Worm Has Turned - Microsoft Joins The Open Compute Project

These are just a couple examples of innovation that is happening here at Microsoft – innovations in process, hardware and software.

At Microsoft, we recognize that the majority of organizations are going to use multiple clouds and will want to take advantage of Hybrid Cloud scenarios. Every organization is going to have their own unique journey to the cloud – and organizations should make decisions about cloud partners that truly enable them with the flexibility to use multiple clouds, constant innovation, and consistency across clouds.

This is an area that we focus on every day, and you can read more about it as a part of our ongoing, in-depth series, Success with Hybrid Cloud.