In-Depth

Real-Life Azure, Part 1: Setting Up the Environment

In this first installment on moving to a hybrid cloud, our fictional company decides on the cloud provider and creates the infrastructure.

Click here for Part 2

Public cloud brings a plethora of choices to IT departments; and often, too many options lead to indecisiveness. Looking at technology features is one thing, but really understanding how and why it would benefit your business is another. In this first of a three-part series, I'll take a fictional company on its journey from an on-premises IT infrastructure to a hybrid cloud environment, with instructions for each leg of the journey, along with links to further information. Let's get started.

Just Another Big Business
Just Another Big Business (JABB) Systems International is a 2,400-employee business with global offices.

JABB manufactures security equipment, such as surveillance systems, alarms, bulletproof glass and cars, safes and related technologies. Its IT team of 15 is responsible for the day-to-day running of its datacenters, as well as improving the business through innovative use of technology.

It has two datacenters: New York and Los Angeles, which is in a co-location facility. The environment is mostly Windows Server virtual machines (VMs), with about 60 percent running on a VMware cluster, another 30 percent running on a newer Hyper-V cluster, and the rest running on older, physical servers. There are quite a few Linux servers, as well as two main, in-house-developed line-of-business (LOB) applications. The IT team currently finds itself in a challenging situation, with aging hardware in both datacenters and a shrinking budget.

Decision Points
Mike, the CIO, calls a meeting with the entire IT team to look at how to improve the IT situation for JABB in the next 12 to 24 months. The very first mention of public cloud and comparisons between Microsoft Azure and Amazon Web Services (and Google) trigger a heated debate about the pros and cons of each, and why certain technology features should be the deciding factor.

Ultimately, technology features don't determine the choice of cloud provider; typically, if one platform introduces a new feature, the others pick it up fairly quickly. The choice of a public/hybrid cloud provider is a long-term strategy, and Mike believes that Microsoft offers the strongest solution for a gradual migration from JABB's current platforms to a hybrid/mostly public cloud-based infrastructure.

Subscriptions
Before the company's Azure journey starts, they decide to sort out their subscription strategy. The developers have an MSDN subscription and receive a monthly credit for dev and test; but for production, JABB settles on a single Azure subscription.

The next issue concerns the selection of an Azure interface. There are two separate management GUIs (apart from Windows PowerShell and API access): the current management console and the new portal. The newer portal has a customizable UI that displays all resources for a service in a single place, whereas the current console manages each resource as a separate object. The new portal is built on resource groups, but not all services are available in the new portal yet. This situation is likely to persist for some time. Because there are links in each console to its counterpart when necessary, the team needs to be prepared to use both UIs depending on the task at hand.

To allocate different administrator access to different services, JABB uses the new Azure portal because it's the only one where real role-based access control (RBAC) is possible. If a particular service it uses needs to be separated from the others from a spending point of view, the decision will be made then to have a separate subscription for it.

JABB has also found that administrative delegation is best managed with an account stored in Azure Active Directory (see Figure 1), because ordinary Live/Microsoft accounts don't work well with the RBAC model.

[Click on image for larger view.] Figure 1. Select your domain name and hosting region when creating your Azure Active Directory.
Putting AD in the Cloud
Identity is a huge issue in the cloud world. JABB knows that even in this early stage, when only internal staff needs authentication, it's vital to get this right. JABB is confident its AD structure (running on a mix of Windows Server 2012 and 2012 R2) is healthy, even though it's about 10 years old. This is mostly due to a Microsoft Risk and Health Assessment Program for Active Directory (ADRAP) service from Premier Support it undertook last year. The assessment cleaned out a lot of debris that had collected; in addition, it helped modernize JABB's AD infrastructure.

Jane, head of development, understands the benefits and risks of linking AD to Azure Active Directory (AAD), and knows that the recommended solution today is Azure AD Sync. The new solution is Azure AD Connect (currently in preview, and expected to be released in June or July 2015), which will become the single tool for all directory synchronization scenarios. The main feature JABB needs at the moment is Organizational Unit (OU) filtering, so that only IT staff accounts are synchronized to AAD. Both of these tools support this filtering.

Backup Considerations
The first workload to consider is backup. JABB uses a combination of System Center Data Protection Manager (DPM) and custom scripts for some Linux servers for this. Off-site storage of the backups is partly done through replication between the datacenters, and partly through tape backups stored with a security firm.

Using DPM on-premises disk backup for short-term backup (and fast restores), then uploading data to an Azure storage account is a good way to ensure compliance.

Setting up cloud-based backup in DPM is easy; prerequisites and step-by-step instructions are available.

A Virtual Branch Office
While some of the IT staff have been experimenting with running workloads in Azure, there hasn't been an overall plan. This is something Mike wants to address first, as IT sees it as essentially the same process used when the company opens a new branch office.

Similar to how a new office operates, networking and storage infrastructure need to be established first. It's helpful to view systems hosted in IaaS as an extension of the internal network to a new location, just like a new branch office extends the systems to a new site (apart from the lack of end users in this "branch office").

JABB starts off by defining a virtual network in Azure that doesn't have any overlapping subnets with any of its current internal IPv4 networks. This is crucial for cross-premises networking. This virtual network has a single subnet  -- it picks 172.16.28.0/18 -- although it can be subdivided into smaller subnets if needed.

[Click on image for larger view.] Figure 2. Define your virtual network IP address space, along with any subnets into which you need to divide it.

Here's the process for creating the virtual network: In the Azure portal, click NEW, select Networking and click Virtual Network. Give the network a name, specify the Address space and a subnet, the subscription and the Azure region (see Figure 2).

To ensure all production Azure VMs are stored logically, JABB also creates a storage account, with locally redundant storage (the default is geo-replicated storage, which is slightly more expensive and not very useful for VM workloads), shown in Figure 3. A single standard storage account holds up to 500TB and can deliver up to 20,000 "entities or messages per second," and because each virtual disk supports up to 500 IOPS (in the Standard tier), the maximum number of virtual disks that should be housed in a single storage account is 40 (20,000/500 = 40).

As this virtual branch office grows, there's the possibility that more storage accounts will have to be added for performance reasons, or that some VMs will need to be stored on Premium Storage.

[Click on image for larger view.] Figure 3. Pick "Locally Redundant" when creating your storage account of IaaS workloads.
Azure Hybrid Networking
The final piece of linking a new branch office to the rest of the business is the WAN link. JABB will start with configuring a VPN device with a Site to Site link (S2S). The development team will also set up a Point to Site link (P2S). The latter is suitable for single devices to connect to the machines in the Azure virtual network securely from any location with an Internet connection. The S2S connection is a permanent IPSec connection with dynamic routing. While you can create a gateway in Azure with static routing, this is less than ideal, as it only allows a single VPN link.

Setting up the WAN link, step by step: Once you've created a Virtual Network, the next step is to go into the Azure portal, click browse and click on the name of the network (see Figure 4). On the VPN connections tile, fill in the required information to create an S2S (and P2S) connection. You have to define your local networks (making sure you include all subnets in your internal network), as well as the public IP address of your VPN device. Azure maintains a list of VPN devices that are tested to work along with templates or configuration instructions.

[Click on image for larger view.] Figure 4. Start setting up your Site to Site connection with a Normal gateway and Dynamic routing.
As JABB looks to expand its Azure branch office utilization, it will be looking at linking several branch offices to the virtual network for redundancy, as well as possibly expanding with other virtual networks in other Azure regions around the world. Detailed instructions for doing this are beyond the scope of this article, but essentially you start by downloading the network configuration file created in the earlier steps, then manually adding further on-premises VPN devices, as well as any additional Azure virtual networks needed. You then upload this file, which Azure will parse to ensure validity. This will be the new configuration for all your cross-premises hybrid networking links.

If JABB sees that the VPN links aren't keeping up with its needs, the answer is ExpressRoute. This can either take the form of MPLS WAN links provided through a telecommunication company with speeds from 10Mbps to 1Gbps, or Ethernet connectivity through an exchange provider with speeds from 200Mbps to 10Gbps.

Next Steps
So far I've taken JABB Systems on its first steps toward a hybrid cloud world. It has sorted out subscriptions, management interfaces, identity and backup. Next came storage and networking for a virtual branch office. In the next article I'll take a look at creating infrastructure VMs such as domain controllers, DNS and file services in Azure, followed by LOB application servers and using Remote App to ensure maximum reach for their business applications.

Resources

Featured

Subscribe on YouTube