Windows Azure: General Availability of SQL Server Always On Support and Notification Hubs, AutoScale Improvements + More

This morning we released some major updates to Windows Azure.  These new capabilities include:

• SQL Server AlwaysOn Support: General Availability support with Windows Azure Virtual Machines (enables both high availability and disaster recovery)
• Notification Hubs: General Availability Release of Windows Azure Notification Hubs (broadcast push for Windows 8, Windows Phone, iOS and Android)
• AutoScale: Schedule-based AutoScale rules and richer logging support
• Virtual Machines: Load Balancer Configuration and Management
• Management Services: New Portal Extension for Operation logs + Alerts

All of these improvements are now available to use immediately (note: AutoScale is still in preview – everything else is general availability).  Below are more details about them.

SQL Server AlwaysOn Support with Windows Azure Virtual Machines

I’m excited to announce the general availability release of SQL Server AlwaysOn Availability Groups support within Windows Azure.  We have updated our official documentation to support Availability Group Listeners for SQL Server 2012 (and higher) on Windows Server 2012.

SQL Server AlwaysOn Availability Group support, which was introduced with SQL Server 2012, is Microsoft’s premier solution for enabling high availability and disaster recovery with SQL Server.  SQL Server AlwaysOn Availability Groups support multi-database failover, multiple replicas (5 in SQL Server 2012, 9 in SQL Server 2014), readable secondary replicas (which can be used to offload reporting and BI applications), configurable failover policies, backups on secondary replicas, and easy monitoring. 

Today, we are excited to announce that we support the complete SQL Server AlwaysOn Availability Groups technology stack with Windows Azure Virtual Machines - including enabling support for SQL Server Availability Group Listeners.  We are really excited to be the first cloud provider to support the full range of scenarios enabled with SQL Server AlwaysOn Availability Groups – we think they are going to enable a ton of new scenarios for customers.

High Availability of SQL Servers running in Virtual Machines

You can now use SQL Server AlwaysOn within Windows Azure Virtual Machines to achieve high availability and global business continuity.  As part of this support you can now deploy one or more readable database secondaries – which not only improves availability of your SQL Servers but also improves efficiency by allowing you to offload BI reporting tasks and backups to the secondary machines.

Today’s Windows Azure release includes changes to better support SQL Server AlwaysOn functionality with our Windows Azure Network Load Balancers.  With today’s update you can now connect to your SQL Server deployment with a single client connection string using the Availability Group Listener endpoint.  This will automatically route database connections to the primary replica node – and our network load balancer will automatically update to route requests to a secondary replica node in the event of an automatic or manual failover scenario:

This new SQL Server Availability Group Listener support enables you to easily deploy SQL Databases in Windows Azure Virtual Machines in a high-availability configuration, and take full advantage of the full SQL Server feature-set.  It can also be used to ensure no downtime during upgrade operations or when patching the virtual machines.

Disaster Recovery of an on-premises SQL Server using Windows Azure

In addition to enabling high availability solutions within Windows Azure, the new SQL Server AlwaysOn support can also be used to enable on-premise SQL Server solutions to be expanded to have one or more secondary replicas running in the cloud using Windows Azure Virtual Machines.  This allows companies to enable high-availability disaster recovery scenarios – where in the event of a local datacenter being down (for example: due to a hurricane or natural disaster, or simply a network HW failure on-premises) they can failover and continue operations using Virtual Machines that have been deployed in the cloud using Windows Azure.

The diagram above shows a scenario where an on-premises SQL Server AlwaysOn Availability Group has been defined with a 2 database replicas - a primary and secondary replica (S1).  One more secondary replica (S2) has then been configured to run in the cloud within a Windows Azure Virtual Machine.  This secondary replica (S2) will continuously synchronize transactions from the on-premises primary replica.  In the event of a disaster on-premises, the company can failover to the replica in the cloud and continue operations without business impact. 

In addition to enabling disaster recovery, the secondary replica(s) can also be used to offload reporting applications and backups. This is valuable for companies that require maintaining backups outside of the data center for compliance reasons, and enables customers to leverage the replicas for compute scenarios even in non-disaster scenarios. 

Learn more about SQL Server AlwaysOn support in Windows Azure

You can learn more about how to enable SQL Server AlwaysOn Support in Windows Azure by reading the High Availability and Disaster Recovery for SQL Server in Windows Azure Virtual Machines documentation.  Also review this TechEd 2013 presentation: SQL Server High Availability and Disaster Recovery on Windows Azure VMs.  We are really excited to be the first cloud provider to enable the full range of scenarios enabled with SQL Server AlwaysOn Availability Groups – we think they are going to enable a ton of new scenarios for customers.

Windows Azure Notification Hubs

I’m excited today to announce the general availability release of Windows Azure Notification Hubs.  Notification Hubs enable you to instantly send personalized, cross-platform, broadcast push notifications to millions of Windows 8, Windows Phone 8, iOS, and Android mobile devices. 

I first blogged about Notification Hubs starting with the initial preview of Notification Hubs in January.  Since the initial preview, we have added many new features (including adding support for Android and Windows Phone devices in addition to Windows 8 and iOS ones) and validated that the system is ready for any amount of scale that your next app requires.

You can use Notification Hubs from both Windows Azure Mobile Services or any other custom Mobile Backend you have already built (including non-Azure hosted ones) – which makes it really easy to start taking advantage of from any existing app.

Notification Hubs: Personalized cross platform broadcast push at scale

Push notifications are a vital component of mobile applications.  They’re the most powerful customer engagement mechanism available to mobile app developers.  Sending a single push notification message to one mobile user is relatively straight forward (and is already easy to-do with Windows Azure Mobile Services today).  But sending simultaneous push notifications in a low-latency way to millions of mobile users, and handling real world requirements such as localization, multiple platform devices, and user personalization is much harder.

Windows Azure Notification Hubs provide you with an extremely scalable push notification infrastructure that helps you efficiently route cross-platform, personalized push notification messages to millions of users:

• Cross-platform. With a single API call using Notification Hubs, your app’s backend can send push notifications to your users running on Windows Store, Windows Phone 8, iOS, or Android devices.

• Highly personalized. Notification Hubs' built-in templating functionality allows you to let the client chose the shape, format and locale of the notifications it wants to see, while keep your backend code platform independent and really clean.

• Device token management. Notification Hubs relieves your backend from the need to store and manage channel URIs and device tokens used by Platform Notification Services (WNS, MPNS, Apple PNS, or Google Cloud Messaging Service). We securely handle the PNS feedback, device token expiry, etc. for you.

• Efficient tag-based multicast and pub/sub routing. Clients can specify one or more tags when registering with a Notification Hub thereby expressing user interest in notifications for a set of topics (favorite sport/teams, geo location, stock symbol, logical user ID, etc.). These tags do not need to be pre-provisioned or disposed, and provide a very easy way for apps to send targeted notifications to millions of users/devices with a single API call, without you having to implement your own per-user notification routing infrastructure.

• Extreme scale. Notification Hubs are optimized to enable push notification broadcast to thousands or millions of devices with low latency. Your server back-end can fire one message into a Notification Hub, and thousands/millions of push notifications can automatically be delivered to your users, without you having to re-architect or shard your application.

• Usable from any backend. Notification Hubs can be easily integrated into any back-end server app using .NET or Node.js SDK, or easy-to-use REST APIs. It works seamlessly with apps built with Windows Azure Mobile Services. It can also be used by server apps hosted within IaaS Virtual Machines (either Windows or Linux), Cloud Services or Web-Sites.

Bing News: Using Windows Azure Notification Hubs to Deliver Breaking News to Millions of Devices

A number of big apps started using Windows Azure Notification Hubs even before today’s General Availability Release.  One of them is the Bing News app included on all Windows 8 and Windows Phone 8 devices.

The Bing News app needs the ability to notify their users of breaking news in an instant. This can be a daunting task for a few reasons:

• Extreme scale: Every Windows 8 user has the News app installed, and the Bing backend needs to deliver hundreds of millions of breaking news notifications to them every month

• Topic-based multicast: Broadcasting push notifications to different markets, based on interests of individual users, requires efficient pub sub routing and topic-based multicast logic

• Cross-platform delivery: Notification formats and semantics vary between mobile platforms, and tracking channels/tokens across them all can be complicated

Windows Azure Notification Hubs turned out to be a perfect fit for Bing News, and with the most recent update of the Bing News app they now use Notification Hubs to deliver push notifications to millions of Windows and Windows Phone devices every day.

The Bing News app on the client obtains the appropriate ChannelURIs from the Windows Notification Service (WNS) and the Microsoft Push Notification Service (MPNS), for the Windows 8 and Windows versions respectively, and then registers them with a Windows Azure Notification Hub . When a breaking news alert for a particular market has to be delivered, the Bing News app uses the Notification Hubs to instantly broadcast appropriate messages to all the individual devices.  With a single REST call to the Notification Hub they can automatically filter the customers interested in the topic area (e.g. sports update) and instantly deliver the message to millions of customers:

Windows Azure handles all of the complex pub/sub filtering logic for them, and efficiently handles deliver of the messages in a low-latency way.

Create your first Notification Hubs Today

Notification Hubs support a free tier of usage that allows you to send 100,000 operations every month to 500 registered devices at no cost – which makes it really easy to get started. 

To create a new Notification Hub simply choose  New->App Services->Service Bus->Notification Hub within the Windows Azure Management Portal:

Creating a new Notification Hub takes less than a minute, and once created you can drill into it to see a dashboard view of activity with it.  Among other things, the dashboard allows you to see how many devices have been registered with it, how many messages have been pushed to it, how many messages have been successfully delivered via it, and how many have failed:

Once your hub is created, click the “Configure” tab to enter your app credentials for the various push notifications services (Windows Store/Phone, iOS, and Android) that your Notification Hub will coordinate with:

And with that your notification hub is ready to go!

Registering Devices and Sending out Broadcast Notifications

Now that a Notification Hub is created, we’ll want to register device apps with it.  Doing this is really easy – we have device SDKs for Windows 8, Windows Phone 8, Android, and iOS. 

Below is the code you would write within a C# Windows 8 client app to register a user’s interest in broadcast notifications sent to the “myTag” or “myOtherTags” tags/topics:

await hub.RegisterNativeAsync(channel.Uri, new string[] { "myTag", "myOtherTag" });

Once a device is registered, it will automatically receive a push notification message when your app backend sends a message to topics/tags it is registered with.   You can use Notification Hubs from a Windows Azure Mobile Service, a custom .NET back-end app, or any other app back-end with our Node.js SDK or REST API.  The below code illustrates how to send a message to the Notification Hub from a custom .NET backend using the .NET SDK:

var toast = @"<toast><visual><binding template=""ToastText01""><text id=""1"">Hello everybody!</text></binding></visual></toast>";

await hub.SendWindowsNativeNotificationAsync(toast);

A single call like the one above from your app backend will now securely deliver the message to any number of devices registered with your Notification Hub.  The Notification Hub will handle all of the details of the delivery irrespective of how many users you are sending it to (even if there are 10s of millions of them). 

Scaling and Monitoring your Notification Hub

Once you’ve built your app, you can easily scale it to millions of users directly from the Windows Azure management portal.  Just click the “scale” tab in your Notification Hub within the management portal to configure the number of devices and messages you want to support:

In addition to scaling capacity, you can also monitor and track nearly 50 different metrics about your notifications and their delivery to your customers:

Learn More about Notification Hubs

Learn more about Notification Hubs using the Notification Hubs service page, where you will find video tutorials, in-depth scenario guidance, and link to SDK references.

We are happy to continue offering Notification Hubs at no charge to all Windows Azure subscribers through September 30, 2013.  We will begin billing for Notification Hubs consumption in the Basic and Standard tiers on October 1, 2013.  A Free Tier will continue to also be available and supports 100,000 notifications with 500 registered devices each month at no cost.

AutoScale: Scheduled AutoScale Rules and Richer Logging

This summer we introduced new AutoScale support to Windows Azure that enables you to automatically scale Web Sites, Cloud Services, Mobile Services and Virtual Machines.  AutoScale enables you to configure Windows Azure to automatically scale your application dynamically on your behalf (without any manual intervention required) so that you can achieve the ideal performance and cost balance. Once configured, AutoScale will regularly adjust the number of instances running in response to the load in your application.

Today, we are introducing even more AutoScale features – including the ability to proactively adjust your Cloud Service instance count using time scheduled rules.

Schedule AutoScale Rules

If you click on the Scale tab of a Cloud Service, you’ll see that we’ve now added support for you to configure/control different scaling rules based on schedule rules.

By default, you’ll edit scale settings for No scheduled times – this means that your scale settings will always be the same regardless of the time/day. You can scale manually by selecting None in the Scale by Metric section – this will give you the traditional Instance Count slider that you are familiar with:

Or you can AutoScale dynamically by reacting to CPU activity or Queue Depth.  The below screen-shot demonstrates configuring an auto-scale rule based on the CPU of the WebTier role and indicates to scale between 1 and 3 instances – depending on the aggregate CPU:

With today’s release, we also now allow you to setup different scale settings for different times of the day.  You can enable this by clicking the “Set up Schedule Times” button above.  This brings up a new dialog:

With today’s release we now offer the ability to define two different recurring schedules: Day and Night. The first schedule, Day Time, runs from the start of the day to the end of the day (which I’ve defined above as being between 8am and 8pm). The second schedule, Night Time, runs from the end of one day to the start of the next day. Both use the options in Time to define start and end of a day, and the time zone. This schedule respects daylight savings time, if it is applicable to that timezone. In the future we will add other types of time based schedules as well.

Once you’ve setup a day/night schedule, you can return to the Scale page and see that the schedule dropdown now has the two schedules you created populated within it:

You can now select each schedule from the list and edit scaling rules specific to it within it. For example, you can select the Day Time Schedule and set Instance Count on a Cloud Service role to 5, and then select Night Time and set Instance Count to 3.  This will ensure that Windows Azure scales up your service to 5 instances during the day, and then cycles them down to 3 instances overnight.

You can also combine Scheduled Autoscale rules and the Metric Based AutoScale rules together.  Select the CPU or Queue toggle and you can configure AutoScale rules that apply differently during the day or night. For example, you could set the Instance Range from 5 to 10 during the day, and 3 to 6 at night based on CPU activity.

Today’s release only supports Scheduled AutoScale rules on Cloud Services – but you’ll see us enable these with all types of compute resources (including Web Sites, Mobile Services + VMs) shortly.

AutoScale History

It’s now easy to know and log exactly what AutoScale has done for your service: there are four new AutoScale history features with today’s release to help with this.

First, we have added two new operations to Windows Azure’s Operation Log capability: AutoscaleAction and PutAutoscaleSetting. We now record each time that AutoScale takes a scale up or scale down action, and include the new and previous instance counts in the details. In addition, we record each time anyone changes autoscale settings – you can use this to see who on your team changed autoscale options and when.  These are both now exposed in the Operation Logs tab of the new Management Services node within the Windows Azure Management Portal:

For Cloud Services, we are also adding a historical graph that shows of the number of instances over the past 7 days. This way, you can see trends in AutoScale over the span of a week:

Third, if AutoScale ever fails for more than 2 hours at a time, we will automatically notify the Service Administrator and Co-Admin of the subscription via email:

Fourth, if you are the Account Administrator for your subscription, we will now show you billing information about Autoscale in your account’s currency:

If AutoScale is on, it will show you the difference between your current instance count, and the maximum instance count – and how much you are saving by using it.

If AutoScale is off, we will show you how much we predict you could save if you were to turn on AutoScale.  Put another way - we are updating your bill to include suggestions on how you can pay us less in the future (please don’t tell my boss about this… <g>)

Virtual Machines: Support for Configuring Load Balancer Probes

Every Virtual Machine, Cloud Service, Web Site and Mobile Service you deploy in Windows Azure comes with built-in load balancer support that you can use to both scale out your app and enable high availability.  This load balancer support is built-into Windows Azure and included at no extra charge (most other cloud providers make you pay extra for it).

Today’s update of Windows Azure includes some nice new features that make it even easier to configure and manage load balancing support for Virtual Machines – and includes support for customizing the network probe logic that our load balancers use to determine whether your Virtual Machines are healthy and should be kept in the load balancer rotation.

Understanding Load Balancer Probes

Load-balancing network traffic across multiple Virtual Machine instances is important, both to enable scale-out of your traffic across multiple VMs, as well as to enable high availability of your app’s front-end or back-end virtual machines (as discussed in the SQL Server AlwaysOn section earlier). A network probe is how the Windows Azure load balancer detects failure of one or more of your virtual machine instances - whether due to software or hardware failure.  If the network probe detects there is an issue with a specific virtual machine instance it will automatically failover traffic to your healthy virtual machine instances, and prevent customers thinking your application is down.

The default configuration for a network probe from the Windows Azure load balancer is simply using TCP on the same port your application is load-balancing.  As shown in the below example, each Virtual Machine in a load-balanced set is receiving TCP traffic on port 80 from the public internet (likely a website or web service). With a simple TCP probe, the load-balancer sends an ongoing message, every 15 seconds by default, on that same port to each Virtual Machine, checking for health. Because the Virtual Machine is running a website, if the Virtual Machine and web service is healthy, it will automatically reply back to the TCP probe with a simple ACK to the load balancer. While this ACK continues, the load-balancer will continue to send traffic, knowing the website is responsive. 

In any situation where the website is unhealthy, the load balancer will not receive a response from the website.  When this happens the load balancer will stop sending traffic to the virtual machine that is having problems, and instead direct traffic to the other two instances, as shown for Virtual Machine 2 below. This simple high availability option will work without having to write any special code inside the VM to respond to the network probes and can protect you from failure due to the application, the virtual machine, or the underlying hardware (note: if Windows Azure detects a hardware failure we’ll automatically migrate your Virtual Machine instance to a new server).

Windows Azure allows you to configure both the time interval for sending each network probe (15 seconds is the default) and the number of probe attempts that must fail before the load balancer takes the instance offline (the default is 2). Thus, with the defaults, after 30 seconds of receiving no response from a web service, the load balancer will consider it unresponsive and stop sending traffic to it until a healthy response is received later (15 seconds per probe * 2 probes).

You can also now configure custom HTTP probes – which is a more advanced option. With HTTP probes, you can configure the load balancer’s network probe request to be sent to a separate network port than the one you are load-balancing (and this port does not have to be open to the Internet – the recommendation is for it to be a private port that only the load balancer can access). This will require your service or application to be listening on this separate port and respond to the probe request, based upon the health of the application. With HTTP probes, the load balancer will continue to send traffic to your Virtual Machine if it receives an HTTP 200 OK response from the network probe request. Similar to the above TCP intervals, with the defaults, when a Virtual Machine does not respond with an HTTP 200 OK after 30 seconds (2 x 15 second probes), the load balancer will automatically take the machine out of traffic rotation until hearing a 200 OK back on the next probe. This advanced option does require the creation of code to listen and respond on a separate port, but gives you a lot more control over traffic being delivered to your service:

Configuring Load Balancer Probe Settings

Before today’s release, configuring custom network probe settings used to require you to use PowerShell, our Cross Platform CLI tools, or write code against our REST Management API.  With today’s Windows Azure release we’ve added support to configure these settings using the Windows Azure Management Portal as well. 

You can configure load-balanced sets for new or existing endpoints on your virtual machines.  You can do this by adding or editing an endpoint on a Virtual Machine.  To do this with an existing Virtual Machine, select the VM within the portal and navigate to the Endpoints tab within it.  Then add or edit the endpoint you want to open to external callers:

The Edit Endpoint dialog allows you to view or change a port that is open to the Internet (and existed before today’s release): 

Selecting the “Create Load-Balanced Set” or “Reconfigure the Load-Balanced Set” checkbox within the dialog above will now allow you to proceed to another page within the wizard that surfaces the load balanced set and network probe properties:

Using the screen above you can now change the network probe settings to be either TCP or HTTP based, configure which internal port you wish to probe on (if you want your network probe to be private and different than the port you use to serve public traffic), configure the probe interval (default is every 15 seconds), as well as configure the number of times the network probe is allowed to fail before the machine is automatically removed from network rotation (default is 2 failures).

Identifying Network Probe Problems

In addition to allowing you to create/edit the network probe settings, today’s Windows Azure Management Portal release also now surfaces cases where network probes are misconfigured or having problems.  For example, if during the Virtual Machine Preview you created a VM and configured a load-balanced sets prior to probes being a required configuration item, we will show an error icon that indicates missing probe configuration under the load-balanced set name column to indicate that the load-balanced set is not configured correctly:

Operation Logs and Alerts Now in “Management Services” section of Portal

Previously “Alerts” and “Operation Logs” tabs were under the “Settings” extension in the Windows Azure Management Portal.  With today’s update, we are moving these cross cutting management and monitoring functionality to a new extension in the Windows Azure Portal named “Management Services”. The goal is to increase discoverability of common management services as well as to provide better categorization of functionality that cuts across all Windows Azure services. We will continue to enrich and add to such cross cutting functionality in Windows Azure over the next few releases.

Note that this change will not affect existing alert rules that were previously configured, only the location where they show up in the portal is different.

Additions to Operation Logs

Prior to today, you could find operation history for Cloud Services and Storage operations. With this release, we are adding additional operation history data for the following additional areas:

• Disk operations – add and delete Virtual Machine Disks
• Autoscale: Autoscale settings changes, autoscale actions
• Alerts
• SQL Backup configuration changes

We’ll add to this list in later updates this year to include all other services/operations as well.

Summary

Today’s release includes a bunch of great features that enable you to build even better cloud solutions.  If you don’t already have a Windows Azure account, you can sign-up for a free trial and start using all of the above features today.  Then visit the Windows Azure Developer Center to learn more about how to build apps with it.

Hope this helps,

Scott

P.S. In addition to blogging, I am also now using Twitter for quick updates and to share links. Follow me at: twitter.com/scottgu