Monday, September 29, 2014

Deploying Web Site Clouds for Windows Azure Pack

On this blog, you have mainly found (useful?) information around Hyper-V, VMM and Azure Pack when it comes to the private cloud area.
However, Azure Pack gives us a lot more than “just” the VM Cloud Resource Provider, that is the holy grail of Infrastructure as a Service offering in your private cloud.

I have attempted to cover the broader aspect of Azure Pack on this blog, like walking through the different portals, APIs and much more, especially related to the backend VM Cloud services.

Recently, I wrote about “Deploying Service Bus for Windows Azure Pack” - http://kristiannese.blogspot.no/2014/09/deploying-service-bus-for-windows-azure.html that shows the consistency related to PaaS between Microsoft Azure in the public cloud, and Azure Pack in the private cloud.

This blog post – which is focusing on the Web Site Cloud does also falls under the PaaS umbrella in Azure Pack.

Without going into the repeating story around “one consistent platform” and all of that, I assume you know this already, but as an introduction to Web Site Clouds in WAP, we can say the following:

The Web Site Clouds enables an on-premises, high-density, multi-tenant web hosting service for service providers and enterprise IT. The web sites provides an experience similar to Microsoft Azure Web Sites. It is scalable, shared, and secure web hosting platform that supports both template web applications and a broad range of programming languages like ASP.NET, PHP and Node.js.
In addition to a web site service, it includes a self-service management portal (tenant portal), uses both SQL and MySQL database servers, integrates with popular source control systems, and offers a customizable web application gallery of popular open source web applications.

Web Site Cloud

The Web Site Cloud consists of at least 6 server roles.

·         Controller – Provisions and manage the other web site roles. This is the first role you install and run the Web Site Cloud setup on
·         Management Server – This server exposes a REST endpoint that handles management traffic to the WAP Web Site Management API, and you connect the service management portal to this endpoint
·         Front End – Accepts web requests from clients, routes requests to web workers, and return web worker worker responses to clients. Front End servers are responsible for load balancing and SSL termination
·         Web Worker – These are web servers that process client web requests. Web workers are either shared or reserved to provide differentiated levels of service to customers. Reserved workers are categorized into small, medium and large sizes.
·         File Server – Provides file services for hosting web site content. The file server houses all of the application files for every web site that runds on the web site cloud.
·         Publisher – Provides content publishing to the web site farm for FTP clients, Visual Studio and WebMatrix through the Web Deploy and FTP protocols

And as everything else, a SQL server is required for the runtime database.
The roles are separated from, and in addition to, the servers that form the (express or distributed) installation of the service management API (Portals and APIs).



Before you start to install the Web Site Cloud, you must deploy and prepare some VM’s.

Obviously everyone is using VMM today, so here’s a short script that will go ahead and create 6 VMs to be used for the Web Site Cloud in your private cloud infrastructure:

$VMNames =@(1..5)
$Template = Get-SCVMTemplate -VMMServer vmm01 -ID "1ee6ba94-b5fc-49f1-8364-a3d1b2da3f40" | where {$_.Name -eq "GEN2 Template"}
Foreach ($VM in $VMNames)
{
$VM = "webroleblog"+$VM


New-SCVirtualMachine -Name $vm -VMTemplate $template -VMHost "hv03" -Path "c:\clusterstorage\csv01" -HighlyAvailable $true -RunAsynchronously

}



Once this is done, you can start by logging into the controller VM where you will install the Web Site Cloud to deploy and configure the other core roles for this resource provider.

Note: Although it is not a requirement I have found officially, I have experienced some issues if .NET 3.5 is not enabled within the OS’s before we start on this process. Through the Web Site Cloud installer, we will download, install and enable many web server features on each guest through an agent. This one seems to fail randomly if .NET 3.5 is left out)

On the controller, download and install Web Platform Installer version 5.0

Once this is done, start Web Platform installer and search for Web Site.
Add “Windows Azure Pack: Websites V2 Update 3” and install it on your server.



Post the installation, you will be prompted by the well-known configuration page of Azure Pack that let you connect to the SQL server, create the database, file server settings and a lot more.

The following screen shots will give you an understanding of what needs to be configured.





After the setup, we logon to our admin portal to add and configure the rest of the Web Site Cloud resource provider.

Click on Web Site Cloud and connect to your newly created environment.
Select a display name, connect to the management server (https://nameofmanagementVM), and type the credentials you specified during the setup that has access to the REST endpoint.



After the web site cloud is added, you can drill into the configuration and click on ‘Roles’.
This is where you will add the additional and required web site roles you need in order to deliver web sites to your customers.



We have already the following in place:

-          Controller
-          Management
-          File server

What we need to add now, is:

-          Publisher
-          Front End
-          Worker

You simply type the DNS or the IP address of the specific server(s) you want to add, and then Azure Pack will deploy and configure these roles for you, through the controller.

Note: The Web Site Cloud has a default domain that you specify during the setup. In our example, we are using paas.systemcenter365.com  - which mean that every website that gets deployed, will have a suffix of website.paas.systemcenter365.com
In order for this to work, you must also create some host records for the following roles:

·         Web Deploy DNS: publish.paas.systemcenter365.com
·         FTP Deploy DNS: ftp.paas.systemcenter365.com
·         Front End: *.paas.systemcenter365.com

Also note that you are able to perform lifecycle management of your web site roles directly from the management portal:



Once the web site cloud is configured with the default settings, you can go ahead and add the web site cloud to an existing Hosting Plan.

You can configure the Web Site offering by clicking on the service within the plan, and edit the existing values. We will leave this alone for now, and head over to the tenant portal to see the interaction.



Now we have the Web Sites available in the tenant portal, since this tenant is subscribing to a hosting plan that contains this offering.
If we click on new, we can choose between quick create, custom create and from gallery.



Once the web site is deployed (regardless of the options listed), we can perform several operations post the deployment from the tenant portal.



From a developer perspective, it is very interesting to see that you can download the publish profile, so that you can leverage TFS to deploy your applications. This is a solid value add-on, in addition to the already exposed tenant public API (for more info, see:  http://kristiannese.blogspot.no/2014/06/azure-pack-working-with-tenant-public.html )

What I like the most about the web site cloud is the grade of integration with the other PaaS offerings in Azure Pack, just as you would find in Microsoft Azure.
Depending on the solution and application you create, you can link with SQL, MySQL and Service Bus which is basically everything you need in order to fulfill the PaaS solution you are working on.

Hopefully this gave you an overview of the Web Site Cloud in WAP.


Wednesday, September 24, 2014

Providing Disaster Recovery for Windows Azure Pack tenants

Providing Disaster Recovery for Windows Azure Pack tenants

In today’s datacenters where service providers are using Hyper-V, System Center and Windows Azure Pack, we will find a wide diversity of technologies and many moving parts that together will deliver one or more advanced sophisticated solutions.

To deliver cloud computing at scale, the most important thing is an understanding of the solutions as well as the preferred design to meet these goals.

In a nutshell, the holy grail of disaster recovery for tenants is something like this:

“A failover should occur with a minimum or none interaction from the tenants”

This one is hard to achieve to be honest, and the underlying design of the management stamp and the rest of the topology need to be designed in order for this to work.

Let us just look at some of the dependencies when a service provider is offering a complete IaaS solution to their tenants, leveraging the VM Cloud Resource Provider in Azure Pack.

·         VMM Management Stamp
o   The management stamp is the backend, the fabric controller of your VM Clouds in WAP
o   VMM manages the scale-units as well as the clouds abstracted in to WAP.
o   Networking is also a critical part of VMM once NVGRE is implemented. Since VMM act as a network controller in this context, we have in essence a boundary for the managed virtual machines
o   Virtualization Gateways is also managed by the stamp, within the single boundary
* Hyper-V Replica, managed through ASR and VMM
·         SPF
o   Service Provider Foundation exposes the IaaS capabilities in VMM to Azure Pack, and is the endpoint used by the VM Cloud Resource Provider in WAP
·         Active Directory
o   A service provider datacenter may contain several domain controllers and forests to manage their solutions, and hence a critical part of the offerings
o   ADFS for federation using multiple services can be considered as a key component
·         SQL
o   Almost everything in the Cloud OS stack on-premises has a dependency and requirement of SQL servers and databases
·         Windows Azure Pack
o   The API’s, the portals and the extensions are all there to deliver the solutions to the tenants, providing Azure similar services based on the service providers own fabric resources, such as IaaS and PaaS.
§  VM Cloud Resource Provider
·         Remote Console
·         VMM library with VM templates and VM Roles
·         Tenants
·         VMs
·         VM Roles
·         Virtual Networks
·         Usage
o   Other resource providers, such as Automation with SMA, Web Site Clouds, SQL Clouds and more, are all part of the solution too
·         Scale-units
o   Compute
o   Storage
o   Networking

In order to solve this, and address many of the challenges that you will be facing, it is really important to be aware of the structure of these components, how they scale, how they can survive and what it takes to bring them back online again.

We have been working on some designs that may fit the majority of the organizations out there, each and one of them with pros and cons.

Within the next weeks, I will publish our findings and this will give you a better understanding of what is possible and what may be the best solution to ensure business continuity for both the service provider and the tenants.

Wednesday, September 10, 2014

How Azure Pack is using Service Provider Foundation

How Azure Pack is using Service Provider Foundation

A while ago, I wrote several posts about the different APIs in Azure Pack.
As you may be aware of, Azure Pack consists of what we often refer to as “Service Management API”.
The API is similar to the one we will (not literally) find in Microsoft Azure, where the portal interacts with the APIs, that again aggregate all the wide diversity of resource providers available for us to consume.

A short summary

The Azure Pack Management Portal offers a familiar, self-service interface that every subscriber (tenant) uses to provision and manage services such as the web site offerings and the virtual machine with its virtual network capabilities.
We have portals for the admin (service provider) and the tenants.

Underlying the Management Portal is an OData Rest application programming interface (API) known as the Service Management API.
This API provides access to the underlying services and enables automation and replacement of the existing management portal.

Some of my API posts:



API summary:

Administrator API
REST APIs that are only available to Service Management for administrators. Default this Admin API is using port 30004, so the URI requests should reflect that.

Tenant API
REST APIs that are available for both administrators and tenants. Default the tenant API is using port 30005.

Public tenant API
Public REST APIs that support end-user subscription management for services presented by the service management API. Default the port is set to 30006.

Let us get back on track

When we are working with the VM Cloud Resource Provider in WAP, we are touching many many APIs on our journey, and one of the important ones (well, all of them are important for this to work) is the Service Provider Foundation (SPF).

SPF is provided with System Center 2012 R2 – Orchestrator (no, you don’t have to install Orchestrator, but the SPF setup is located in the Orchestrator setup/media).
SPF exposes an extensible OData web service that interacts with VMM. This enables service providers to design and implement multi-tenant self-service portals that integrate IaaS capabilities available in System Center 2012 R2 and Windows Server 2012 R2 – Hyper-V.

SPF contains several web services that has two locations to set credentials. On the server that has the SPF installed we use the application domain pool in IIS and the respective group in Computer Management. These groups (SPF_Admin, SPF_VMM, SPF_Usage and SPF_Provider) must contain a local credential (not a domain credential) that is also member of the Administrators group on the SPF server.

The SPF_VMM user must be added as an administrator to VMM in order to invoke actions from the WAP portal.

The Service Provider Foundation Web Services:


The admin web service is used to create and manage tenants, user roles, servers (like Remote Console), stamps (VMM), and other administrative objects.


The VMM web service invokes the VMM server to perform requested operations.
Examples of operations could be:

-          Creating virtual machines
-          Creating virtual networks
-          Creating user role definitions
-          Create cloud services and other fabric

Communication is bidirectional, so that actions triggered by a portal that’s using SPF (like WAP) as well as actions happening directly in VMM will be reflected on both sides.

An example:

You do something in VMM that affect one or more tenants, like adding a new VM to the tenant’s subscription. This will pop up in the tenant portal of WAP.

Another example is when a tenant makes changes to a virtual network in the portal, the jobs are triggered in VMM, aggregated by SPF and shows immediately.

Usage Web Service

SPF has also a Usage Web Service that can only be used by WAP, and uses data from Operations Manager’s data warehouse, which is integrated with VMM in order to collect information of the virtual machine metrics. You must use the spfcmdlets to register SCOM with SPF.

Provider Web Service

Resource providers for delivering infrastructure as a service (IaaS) uses this web service that provides a Microsoft ASP.NET web API. This one uses also the VMM and Admin web services but is not an Open Data (OData) service.


Registering SPF endpoint with Windows Azure Pack

As an administrator, you log on to the management portal and register the Service Provider Foundation endpoint. This will register a connection between the Service Management API and SPF.
Since SPF provides a programmatic interface to the stamps (VMM management servers), it enables service providers and enterprises to design and implement multi-tenant self-service portals that leverage IaaS capabilities provided by System Center and Windows Server.



After you have registered the SPF endpoint with the Service Management API:

·         All stamps that you have created directly in SPF will be listed in the management portal for administrators

·         All clouds created within the VMM stamp(s) will appear in the management portal for administrators

·         You can register stamps directly using the management portal for administrators

·         You can remove/change the association between stamp and service provider foundation


Tuesday, September 9, 2014

Deploying Service Bus for Windows Azure Pack

Many organizations worldwide has implemented many Azure Pack solutions over the last months.
Especially the VM Cloud has been a highly appreciated resource provider in this solution, but we are also seeing more and more adoption of the PaaS offerings, such as Web Site Clouds and SQL Server Clouds.

Recently, I’ve been implementing the Service Bus Cloud too, which is very relevant for the other PaaS I just mentioned.

Eh, Service Bus? What’s that?

My first meeting with Service Bus was back in 2008 when Windows Azure was new.
In a nutshell, Service Bus provides messaging capabilities that enables you to build, test and run loosely-coupled message-driven applications.
This was something we first saw in Azure, where the developers could take advantage of this scalable service.

Later, we got Service Bus for Windows Server which provides similar capabilities as the ones we find in Azure (one consistent platform), which gives flexibility in developing and deploying applications. It is built on the same architecture as the Service Bus cloud service and provides scale and resiliency capabilities.

What about Azure Pack in this context?

Again, we will return to the Cloud OS vision with the one consistent platform. A developer can now easily develop, test and tune their applications using Azure Pack on-premise. In this case, perhaps they do not have a 24/7 environment where the IT organizations are watching things closely, or do not provide the required support outside of business hours.
Now, the developer and its organization can turn to a service provider who offers the same Azure technologies delivered through Windows Azure Pack. In this case, the service provider will be responsible for the entire Azure Pack environment where these services are living and provide support and ensure business continuity.
Therefore, as a result of having the same platform, this customer can easily deploy the same applications to the service provider cloud using the same experience as on-premises, once they move to production.
The next step is of course to leverage the hyper-scale cloud of Microsoft Azure, which again, has the same capabilities as delivered through Azure Pack.

To summarize, we have a very flexible deployment options now using the Cloud OS where each tenant are able to take advantage of the most appropriate cloud option for their applications.

Great, now I understand a bit more, but what kind of features do we have for Service Bus using Azure Pack?

As stated earlier, the Service Bus on-premise supports the same brokered messaging feature set as Microsoft Azure Service Bus. Service Bus queues offer reliable message storage and retrieval with a choice of protocols and APIs.

First of all, we have the Service Bus Queues which provide load leveling by allowing the message receiver to process messages at its own pace. Service Bus provide load balancing by having multiple competing receivers that accept messages from the same queue.

Next, we have Service Bus Topics which provide rich publish-subscribe capabilities that enable multiple, concurrent subscribers to independently retrieve filtered or unfiltered views of the published message stream.
.
Deployment of Service Bus for Windows Azure Pack

You should at least start with a new virtual machine running Windows Server 2012 R2.
Next, download and install Web Platform Installer so that you can get your hands on the “Windows Azure Pack: Service Bus 1.1” component. Yes, this one is also provided in the same way as every extension, site and API for the Azure Pack.



After the installation, you will find the “Service Bus Configuration” located under Apps.
This will prompt you with a wizard that need some inputs so that you can configure the service bus service.



The options you have is to either create a new farm using the default settings, custom settings, or add to an existing farm.
In this case we will create a new farm using the default settings.



The Service Bus requires a SQL in the backend, and we will use an already existing SQL Cluster to ensure HA for our services. Specify name, username and password and test the connection before you proceed.
Service Bus also requires a service account. Once created in AD, assign the name and the password.



Under Certificate Generation Key, you must specify this and re-enter it in the box below. Please keep a record of this key for future use as you have to provide it every time you add a computer to this farm.
The configuration cmdlets use this key for generating certificates.

The option for “Enable firewall rules on this computer” should be enabled so that the configuration wizard creates required firewall rules. Only uncheck this box if Service Bus clients (applications) will run on the same server as Service Bus.

The last section of the configuration page is where you will enable the Service Bus to be managed by the Service Management API in Azure Pack.
Set the usernames and passwords which are used to secure API calls between the portal and the Service Bus farm.



In the end, you will get a summary that shows your configuration and click finish to proceed.

Adding the Service Bus Cloud to Windows Azure Pack

Logon to the admin portal as an administrator and navigate to the Service Bus Cloud.




Click on “Connect to an existing Service Bus cloud” to register with the endpoint.
Fill in the required information that connects you to the API. Once completed, you will have you new Service Bus Cloud added to WAP.




In order to expose the capabilities to your tenants, you need to present this offering through a Hosting Plan. Either create a new Plan meeting your requirements, or simply add to an existing Hosting Plan to extend your service offerings. In our case, we are adding the Service Bus cloud to an existing Plan.



Heading over to the tenant portal, we can see that the Service Bus offering is made available and that I have already created my first Namespace.
Next, I can go ahead and work with queues, topics and use this as part of my applications.




Happy developing!




Monday, September 1, 2014

Presenting at TechEd Barcelona 2014 - Windows Azure Pack

Hi everyone.
I just want to inform you that I will be presenting at TechEd in Barcelona in October.
This is truly an honor and I am really looking forward to meet my friends from all around the globe.

I have one session that is titled “Planning and Designing Management Stamps for Windows Azure Pack”.



This session will indeed focus on the underlying stamp that we turn into a resource provider for the VM Cloud in Azure Pack.
Throughout the entire session, I will share best practices, things you would like to know and also things you should already know.
This is where you will get the inside tips on how to design and build a management stamp to serve cloud computing with WAP, designed to scale and be fault tolerant.
In essence, I will be explaining and demonstrating my bread and butter and what I have done the last 12 months.

I really hope to see you there and if you have any questions upfront and would like to have answered during the session, please let me know.