There have been plenty of blog posts about using Windows Azure Pack for Infrastructure as a Service, but not many about using the websites feature. I’ve been working with the websites functionality since Windows Azure Services for Windows Server, and thought I’d give an overview of how this feature works. In this blog I assume you’ve already set up the tenant & administrative portals and the associated bits and pieces that go along with that. Part 1 (this one) will give an overview of the websites feature and its components, and some of the things you need to consider for deployment. In part 2 we’ll have a look at the deployment process.
Windows Azure Pack websites feature lets you run high density, scalable modern websites with an experience that is similar to Windows Azure websites. It supports .NET, PHP & Node.js, and provides integration with a number of source control systems. In addition, through the tenant portal you can also provision databases with MS SQL or MySQL to use with your websites.
The WAP websites feature is made up of several components:
- The websites controller which provisions and manages all the other roles in the websites infrastructure. The controller is the first role that is provisioned
- The management server (sometimes known as the REST server) provides a REST interface to the websites feature that the WAP portal can consume. The configuration process of the websites controller also configures the management server.
- Web Workers are servers that actually process the web requests, and can be either shared or reserved. Shared workers as the name implies share their resources across multiple tenants and websites, while reserved workers are dedicated to a tenant. For redundancy you should have multiple workers.
- Front end servers, which take web requests from clients and route them to the correct worker servers. The front end servers use a modified version of Application Request Routing to provide this functionality. There should be at least two front end servers for redundancy, and you will need to load balance them in some way (Windows NLB seems to work just fine, but you may have a hardware device you can use).
- File servers provide the content store for all the web site content & certificates.
- The Publisher allows tenants to deploy their content to their websites via FTP, Visual Studio and WebMatrix.
- The websites runtime database provides a configuration store for the websites feature, and runs on MS SQL server. The runtime database needs to be contactable by all the servers in the websites infrastructure. SQL mixed mode authentication must be used. If you use a named instance, be sure to start the SQL browser and open UDP port 1434 (and create a program exclusion for the SQL instance process)
Of these components, only the front end servers & the publisher are exposed to the Internet. All other components are purely internal. For the front end servers, you will expose only the load balanced IP address.
When I talk about the Websites feature, I like to break it down into the management components (controller, management server, publisher, runtime DB) and the delivery components (front ends, workers, file servers).
One of the key things you’ll need to do before you deploy the websites feature is choose a DNS name for your hosted websites. By default, each website you create gets a unique DNS name in the format <website name>.<your custom domain name>. For example, websites created in Windows Azure get a name <something>.azurewebsites.net. You could use something like websites.yourdomain.com, or register a custom domain, there are no special requirements placed on this. You do need to consider how easy it will be for someone to type in those URL’s, so don’t choose something too complex or with too many layers.
Tenants can also map other domain names to your websites once they are provisioned (assuming your plan allows this), but they will always have your custom domain name as well.
You’ll then need to set up DNS records in this domain that will allow tenants to publish content, and users to access content. The DNS records you’ll require are detailed here.
When deploying the websites feature if you are using NAT to present the public facing components, you’ll also need to set up an internal DNS that has the same records as the external facing records, but referring to the internal IP addresses. If you don’t do this, you’ll find things like deploying new websites from the gallery will fail.
You’ll also need to consider certificates. You’ll need to provide a default certificate for the websites feature which is used if an SSL session is requested and there is no corresponding SSL certificate loaded, and also for git publishing. This certificate needs to be a wildcard certificate which includes the names *.<your custom DNS suffix> & *.scm.<your custom DNS suffix>. You’ll also need to provide a certificate for the publisher – you can reuse the default certificate if you want to, or you can provision a new certificate with the publish.<your custom DNS suffix> name explicitly in it.
The other thing you’ll need to think about is redundancy. As noted above, you should build redundancy in to your front end servers by load balancing and provision multiple worker servers. You should also plan for redundancy with your content store (the file server). You could go as far as a file server cluster, or try something simpler like using DFS to replicate the content. Another alternative to consider is using a NAS or a SAN that exposes a Windows SMB file share.