Self-service deployment of Microsoft workloads on Cloud Platform System (and other systems with Windows Azure Pack) – Part 3

Article
04/17/2015

Jeff Goldner is back with another installment of our CPS workload deployment series. Jeff is a Principal Program Manager in Microsoft’s Cloud Solutions Group. Come get workload deployment details first hand at Ignite, Session BRK3469.

Jeff Goldner from Microsoft’s Cloud Solutions, back for part three of the workload story for CPS. In this episode, we are going to do something much bigger. We’ll take what we learned from the single tier deployments (Active Directory, SQL Server, Exchange Server) and expand to deploy three tiers to get a fully running and highly-available SharePoint farm. As before, we are going to leverage the Service Management API (SMA) and Desired State Configuration (DSC) to automate the installation of the Windows Server 2012 R2 instances, a SQL Server AlwaysOn cluster, and a SharePoint 2013 SP1 Farm with two tiers, AND a load balancer!

Note: the other workloads got small updates to fix bugs so make sure you update your existing plans if you used the previous VM Roles.

Brought to you by the CPS team, with a lot of help from the Microsoft Enterprise Cloud Group’s Customer Acceleration Team (the Building Clouds guys). And remember, CPS is not a pre-requisite, because you can use these items with some adjustment if you have already deployed the Windows Azure Pack (WAP). As with the first two releases, we are making these available through the VMM content feed.

Previous blogs in this series:

Part 1 - SQL Server 2014 and Active Directory. Read this to get the pointer to the WebPI feed!

Part 2 - Exchange 2013 SP1

One SharePoint Option

There are many ways to deploy SharePoint, so we have to start somewhere. The target for this sample deployment is going to be a scalable solution that can support about 1,000 users with about 1TB of data. We aren’t going to get fancy; each tier of our installation is symmetric with one small exception for the Central Administration site. Each server in a tier will be hosting the same SharePoint services, and we aren’t deploying separate search or office application servers.

It’s scalable because each tier uses VM Roles which allow scaling to five instances. If you find that you need to separate services on different servers and/or need a dedicated Search machine, you can do that by scaling out and then using the SharePoint configuration tools (e.g., PowerShell) to add the new machines into your existing farm.

What the deployment does

We’ve talked about using a subscription to a plan to trigger a set of VM roles, thereby overcoming the issue with VM Roles not supporting multi-tier deployments. (See the resources at the end, particularly the videofrom TechEd Europe 2014.)

Here’s what our SharePoint installation is going to look like after we finish the deployment:

Figure 1 Dedicated SharePoint plan

Subscribing to the Dedicated SharePoint plan will result in the following activities:

1. A VM network is created using our software defined networking capability

2. A new AD domain is set up with two DCs, including DNS (and the VM network is configured for that)

3. A SQL Server 2014 AlwaysOn cluster will be created to host the SharePoint configuration and content databases

4. SharePoint 2013 SP1 Web and Application tiers will be created with two servers each

5. The load balancer will get configured against the Web-tier HTTPS access points (except for the part that can’t be automated today)

Note that step 5 requires a fabric administrator to configure the load balancing pool, so technically this is not a 100% self-service workload. Over time we hope to automate that part.

What’s left is the actual farm configuration. While we investigate the best way to leverage DSC to automate this process in the future, we are going to use some PowerShell scripts to take this to the production stage; they are included in the zip file you download from WebPI. That will distribute the services across the tiers and get you to a running farm. Or you can use your own formula for this, if you already have one. Or you can use the SharePoint configuration wizard, but make sure you read the readme file that comes with the Gallery item first. Start with creating the service accounts listed in the readme file.

If you want to add more servers to the farm, you can scale out the VM Roles using the Windows Azure Pack Tenant Portal, and then follow this article to complete the work. Using the VM role will take you most of the way through, so pick up at “Add the new SharePoint server to the farm”.

Validation

We run our validation tests against multiple instances of this deployment on an actual CPS rack. For SharePoint, we use a workload that represents about 12% active users out of the 1,000 that we scaled for, which is on the high side. And that we did that a bunch of times on the same rack. The goal is to be able to test the equivalent of 16 tenants of 1,000 users each, running a mixed workload, while keeping to application latency limits.

Samples

The usual reminder: these are examples for you (the service provider/enterprise private cloud admin) to customize to best suit your customers’ needs. To modify them will require an understanding of how WAP works, how the multiple scripting engines process scripts, and how to edit the automation artifacts. An understanding of PowerShell is also going to be a prerequisite. See the Building Clouds blog and the rest of the resources at the end of this post.

What now?

I am thinking that we have provided you enough artifacts to get started (don’t worry, we have more coming), but I know there are some limitations in what we have distributed so far. Mainly because we assume that you will have different environments for each of the plans we are distributing as samples. Next time, I’ll make some suggestions as to how to consolidate those into a per-tenant AD/Exchange/SharePoint all-inclusive environment. With that combination, we would not really want multiple file share witness servers. In fact the file share witness doesn’t need its own server at all. Let me know your thoughts on where you want us to go next. And come say hi when you get to Ignite!