Getting Around Blocked Ports

Regularly, I find myself in a location that blocks ports to the outside world. In many of those moments, I can’t use Remote Desktop (RDP) sessions to connect to Virtual Machines hosted on Azure. The strategy expressed in this post is one of many possible solutions that also applies to Linux and SSH sessions.

The Strategy

• Using a Load Balancer and NAT rules to map port 443 to the RDP (3389) port for a Jumpbox Virtual Machine (VM)
• Using the Jumpbox to RDP into VMs deployed to the Azure Virtual Network.
  

Geo-HA Service Fabric Cluster

One of the biggest challenges that we face when we build an Internet-scale solution, is high availability across geographic locations (Geo-HA). Why is this important? Well, there can be a few different reasons. The most common reason, is to be able to survive data center outages. Another reason, is to bring services closer to end users so that we can provide good user experiences.

Geo-HA brings challenges to the table. For example, should we use an Active-Passive or Active-Active strategy for data across regions? Keeping in mind that Active-Active is difficult to get right, we need to take time to analyze and to make the correct choices. We need to consider our Disaster recovery (DR) plan, target RPO and RTO. Azure has a whole bunch of mechanisms for replication, backup and monitoring, so how do we decide what’s the right combination?

Today’s Internet-scale services are built using microservices. Service Fabric is a next-generation middleware platform used for building enterprise-class, Tier-1 services. This microservices platform allows us to build scalable, highly available, reliable, and easy to manage solutions. It addresses the significant challenges in developing and managing stateful services. The Reliable Actors API is one of two high-level frameworks provided by Service Fabric, and it is based on the Actor pattern. This API gives us an asynchronous, single-threaded programming model that simplifies our code while still providing the advantages of scalability and reliability guarantees offered by Service Fabric.

A Service Fabric cluster is HA within its geographic region by default. Thinking about our heritage of on premise data centers, we’ve poured thousands of man-hours to deploy Disaster Recovery sites in secondary physical locations, because we know that everything is possible. Over the past few years, we’ve experienced many interesting scenarios, for example, a cut cable, or a faulty DNS entry broke the Internet. So why should we do anything differently in the cloud? We must treat each region as we treat our own data centers and think about Geo-HA.

The rest of this post is about taking high availably to the next level by deploying a Geo-HA Service Fabric cluster.

Using ARM to Deploy Global Solutions

Imagine deploying your secure load balanced solution to three datacenters, putting in place a worldwide load balancer and doing so in roughly 24 minutes. Did I mention that this deployment is predictable and repeatable?

Good, now that I’ve got your attention, it’s time to dive in!

Building on my previous post about managing compute resources on Azure I decided to modify the Azure Resource Manager(ARM) template to deploy a real-world environment to three datacenters (Yes I know, the diagrams shows two locations, but as I built the demo, I got greedy…). Using Azure Traffic Manager we are able positively affect a users experience by directing them to the closest datacenter.

Its important to note that ARM does not support nested copy operation. This means that we have to use a different strategy to deploy identical environments in multiple Azure regions. After a bit of research it became apparent that I had to use nested deployments. This technique requires us to break our template into multiple files. The parent template in this demo is the azuredeploy-multi-geo.json file. It contains the full list of parameters, a nested deployment that deploys instances of our environment to multiple Azure regions, and a Traffic Manager definition. The azuredeploy.json template file was refactored from the template used in my previous blog post. It contains networking, storage and Virtual Machine definitions.

Share this:

A little while ago, I wrote about building, using and destroying environments on Azure. At first, what I proposed may have seemed like overkill, so I took this as a challenge and built this short demo project to demonstrate why I favor destroying environments to shutting them down.

Why are Virtual Networks Important?

As a developer, I used to forget about Virtual Networks. And to be fair, I shied away from pretty much everything that can be considered as infrastructure.

Microsoft Azure is a game changer! It requires Developers and IT Pros to collaborate on projects. Let’s take a moment to set things right. Developers and IT Pros are not competing against each other in this new world. They collaborate in order to produce value for the business and customers.

As we move to a Cloud First and Mobile First world, security is more important than it ever was. On Microsoft Azure, the first step towards securing your application resources is to create a Virtual Network.

Temporarily Taking a Cloud Service Role Instances Off of the Load Balancer

By default, public endpoints are load balanced and there are times when we need to take a Role instance off the load balancer. Fortunately, the Windows Azure team has made this possible.

In order to relieve Role instance from too much stress cause by too many requests. You can throttle inbound requests by telling the load balancer that the Role is busy. This can allow the Role to stabilize and get back to normal.

Windows Azure Traffic Manager – High Performance, Availability & Resiliency

With the ability to deploy Windows Azure Cloud Services in different geographical locations, there has to be a way to bring it all together under a single URI.

The Windows Azure Traffic Manager does just that! It allows your end-user’s to interact with the cloud service instance that is closest to them! But that’s not all, it provides the ability to load balance incoming traffic across multiple hosted Windows Azure services whether they’re running in the same datacenter or across different datacenters around the world. By effectively managing traffic, you can ensure high performance, availability and resiliency for your applications.

During Preview, Windows Azure Traffic Manager is currently available at no charge.

Available Traffic Manager Profiles

• Performance – Use this method when your endpoints are deployed in different geographic locations and want to use the one with the lowest latency.
  See Performance load balancing method in Windows Azure Traffic Manager
• Round Robin – Use this method when you want to distribute traffic equally across a set of endpoints.
  See Round Robin load balancing method in Windows Azure Traffic Manager.
• Failover  – Use this method when a primary endpoint is selected to serve all the traffic but backups are required in case the primary or the backup endpoint go offline. The endpoints can be in the same data center or in different data centers. See Failover load balancing method in Windows Azure Traffic Manager.