Transcription
Architecting an N-Tier ApplicationInfrastructure in Microsoft AzureAuthored By: Thomas Mitchellthomasmitchell.net
ContentsAbout the Author . 3Introduction . 3Business Requirements . 3Planning the Architecture . 4Production Environment Considerations. 4Proposed Architecture (Production) . 5Backup Environment Considerations . 8Proposed Architecture (Backup) . 8Azure Active Directory . 11Putting it All Together . 12Completed Solution . 13Conclusion . 142
About the AuthorMy name is Tom Mitchell. I am a 20 year veteran of the ITindustry and throughout the course of such a long an interestingcareer, I have built a rather in-depth skill base. My skillset spansover a dozen different IT disciplines but my specialties include: Microsoft ExchangeMicrosoft Office 365Microsoft Active DirectoryMicrosoft AzureI have designed and architected the smallest solutions and someglobal solutions. I have deployed and implemented said solutionsas well as supported them. My expert-level knowledge of theseand other disciplines such as virtualization and storage allow meto meticulously design and efficiently implement/troubleshootall kinds of IT solutions and infrastructures.In addition to the coveted MCSE: Cloud Platform and Infrastructure certification, I also carry severalother industry certifications, including multiple Microsoft MCSA certifications.My superior ability to see things from a strategic perspective allows me to architect solutions thatclosely align with business needs. By avoiding “tunnel vision” that focuses on “now” when designingsolutions, I can ensure that my solutions stand the test of time and grow with the business.IntroductionOver the summer, an associate of mine approached me and asked if I could answer some MicrosoftAzure questions for another associate of his. I obliged. After a few calls, I was asked to architect anddeploy a rather large application infrastructure in Microsoft Azure. This infrastructure was needed tosupport a new, web-based application that the customer wanted to deploy.The purpose of this document is to provide a detailed look at how I architected a solution, providing you(the reader) with a fantastic use case for Microsoft Azure.Business RequirementsOnce engaged by the customer, I began collecting information that I needed to formulate a proposedarchitecture. I asked questions about platform preferences, required availability, security, etc. Initialdiscussions also included conversations about identity management and network connectivity.Production SiteAfter several architecture calls, the customer provided me with a spreadsheet that contained serverinformation. In production, the application’s web front end would be hosted on two virtual machines.The application itself would run on two separate virtual machines and a single logical SQL VM would3
back-end the application. Additional, centralized storage also needed to be made available to anyvirtual machines that were deployed.Backup SiteIn addition to the production environment, a backup site was also required. The customer requestedthat a single web VM reside in the backup site, along with a single application VM and a second SQLserver, which would host a replicated copy of the production database.Identity ManagementDuring discussions, the customer indicate that the application should be “standalone”, meaning accessand identity management needed to be separate from the on-prem Active Directory. In addition, accessneeded to be centrally managed.High AvailabilityBecause the planned application was being made available to the public, the underlying architectureneeded to be highly available and provide multiple levels of redundancy. Not only did the applicationneed to be regionally redundant – it also had to be locally redundant.Security ConsiderationsSince the application would be internet-facing, security was of utmost concern to the customer.Regardless of what the final architecture looked like, it was imperative that the attack footprint of theenvironment be minimized. It was crucial to the customer that only the necessary services be exposedto the internet.Planning the ArchitectureWith the business requirements in hand, I got to work on the design of a solution that would account forall business requirements. I launched my trusty Visio Pro and started drawing.Production Environment ConsiderationsPer the customer’s requirements, the production site needed to be locally redundant at the front-endtier and at the application tier and regionally redundant in the SQL tier. Easy enough. This wouldrequire two VMs in the web tier (customer did not want to use web apps), two VMs in the applicationtier, and a logical SQL virtual machine in the SQL tier.RedundancyTo get local redundancy, I was going to need a public-facing load balancer for the front-end VMs, aprivate load balancer for the application VMs, and a private load balancer for the SQL virtual machine.Yes, although I was only going to be deploying a single SQL VM in the production site, I wanted toprovide the ability to easily add a second one later on. By leveraging a load balancer at the outset forthe SQL tier, adding a second SQL VM later wouldn’t be nearly as onerous.In addition to load balancers, I was also going to need a few availability sets to ensure I always had oneVM available in both the app and web tiers. I also was going to want to deploy one for the SQL tier as4
well – even though I was only deploying a single SQL virtual machine. I planned on this because it’sIMMENSELY easier to initially deploy a VM into an availability set than it is to go back and do it over ifyou decide to add an availability set after the fact.SecurityAs I worked through the architecture plan for the production site, I had to think about the securityrequirements as well. Because the business requirements called for a locked down environment, I hadto devise a way to limit traffic to and from each VM in the proposed solution.While the front-end servers needed to have HTTP(s) open to the world, all public traffic to them neededto be blocked. The app servers would never be accessed publicly so traffic to/from those VMs neededto be limited only to the front-end servers and the SQL server. The SQL server would only ever talk tothe application VMS so it, too, needed to be locked down.Proposed Architecture (Production)After all considering all options, I put the proposed architecture on paper. The production site consistedof a single virtual network, which, in turn, consisted of three subnets: Web, App, and SQL. Each subnetwould be protected by a separate network security group. The NSG for the web subnet would allowHTTP traffic inbound from “ANY” and block all other inbound traffic from outside. The app subnet NSGwould allow only inbound traffic originating from the web subnet or the SQL subnet. Protecting the SQLsubnet required a network security group that blocked all inbound traffic except for SQL trafficoriginating from the application subnet. The graphic below depicts what the production site’s virtualnetwork looked like as drawn in Visio.5
As you saw in the previous graphic, I planned to deploy a vNet in the East US region. The vNet would bea /16 network, which would provide plenty of room for growth. Three /24 subnets would be carved out– once for each tier (web, app, SQL). A separate network security group would be configured for eachsubnet and configured to allow only the required traffic to those subnets.Architecting the production network in this fashion provided maximum network security while alsoallowing for flexibility if ultimately required.With the network architecture drawn out, I moved onto the redundancy piece of production.Because the business requirements called for local redundancy of the web and app virtual machines inthe production site, I added an availability set in both the web tier and app tier. Inside each availabilityset, I added two virtual machines (WEB1/WEB2 & APP1/APP2). I front-ended the web VMs with a publicload balancer. The app VMs were front-ended with a private load balancer. Each configuration lookedsomething like this:6
By utilizing a load balancer in each tier, the application could sustain a single web server failure AND asingle app server failure and continue to function in the production environment, negating the need fora failover to the backup site (yet to be architected).A separate availability set in both the web tier and app tier would ensure that at least one app serverand one web server was always up, even when Microsoft performed maintenance or if there was a faultsomewhere. This architecture ensures a 99.5% availability SLA on the web and application pieces.To save on costs, the customer requested only a single SQL server in production. The productiondatabase would then be replicated to the backup SQL server in the backup site. However, just because Ihad only one SQL server to work with, it didn’t mean I couldn’t PLAN for local redundancy later on. So,as I did with the app and web tiers, I added an availability set to the SQL tier in my Visio diagram, placeda single SQL virtual machine in it, and front-ended the single SQL virtual machine with an internal loadbalancer. By doing so, I was allowing future redundancy without the need to redesign things.When all was said and done, my Visio diagram for the production site looked like this:By architecting production as depicted above, I was able to address both the security requirements andlocal redundancy requirements while also providing flexibility for future growth. As designed, theproduction site could withstand a simultaneous outage of one web server and one app server and stillcontinue functioning. With the network security groups configured, traffic to each tier was limited to7
only what was necessary: HTTP(s) to web, internal traffic from web and SQL to the app tier, and app tiertraffic only to SQL.With the production side of the architecture dawn up, I moved onto the backup site to architect anacceptable solution there as well.Backup Environment ConsiderationsPer the customer’s requirements, the backup site did not need to be locally redundant in any tier. As amatter of fact, the customer requested only a single web server, a single app server and a single SQLserver in the backup site. Because local redundancy/HA was not required in the backup site, it was notnecessary to build out load balancers, availability sets, etc. Or was it?RedundancyAs an architect, it is my job to steer the customer toward a stable solution when I can. Although thebusiness requirements did not call for high availability nor local redundancy in the backup site, Iexplained to the customer that there were zero additional costs associated with availability sets and thecosts associated with additional load balancers would be minimal. I explained that if they ever wantedto implement redundancy down the road in the backup site, it would be much more work to build it outafter the fact.Based on my recommendations, the customer opted to architect the backup site with futureredundancy as an option.Although redundancy wasn’t required at this point, I was going to need the same type of architecturethat I designed for production: a few availability sets and some load balancers would fit the bill.SecurityThe security requirements for the backup site were identical to those of production. I had to architect asolution in the backup site that limited traffic to and from each VM in the proposed solution.Proposed Architecture (Backup)Since I had already architected a similar design for production, drawing it up for the backup site wassignificantly easier. I basically took what I did for production and copied it over to the backup site inVisio, simply removing a web VM and an app VM. Since the production site was going to be deployed tothe East US region, the backup site would be deployed to the West US region. This would meet thebusiness requirements of regional redundancy.The backup site architecture looked something like this when I was done drawing it up:8
At this point, I had the both the production site and the backup site drawn up in Visio. Each wasdesigned with local redundancy in mind but there was still no regional redundancy. I had to design a9
solution that allowed external users to access the app via the production site and only hit the backupsite if the production site was down. Hmm Enter Traffic Manager.Since I now had two separate sites designed, I had to find a way to connect them to the outside world.Microsoft offers Traffic Manager as the solution.To tie everything together, I added a Traffic Manager Profile to my Visio and added the production siteas one endpoint and the backup site as the second endpoint. The public load balancers in each of theweb tiers served as the actual endpoints. By configuring the Traffic Manager in priority mode, I couldensure that all external traffic is directed to the production site unless that site went down. TrafficManager could then automatically send traffic to the backup site.My Visio diagram looked like this after the addition of the Traffic Manager profile:10
As you can see from the image above, the solution was coming together quite nicely on paper. Asarchitected, the proposed solution provided regional redundancy via the Traffic Manager profile. Localredundancy was afforded in both the production and backup sites via load balancers. High availabilitywas achieved through the deployment of availability sets in each tier within each region. Securityconcerns were allayed through the use of network security groups for each subnet.However, there was still work to be done. If you look closely at the architecture diagram, there is noconnectivity between the East and West virtual networks. Remember, these networks are in differentregions. As such, they need to be connected via a VPN or peering to allow communication betweenthem. Since, at a minimum, the SQL servers are going to need to talk to each other to allow replicationof the database, the two networks are going to need to be connected.Additionally, the diagram depicts no Azure Active Directory. Azure AD was the agreed-upon identitymanagement solution for this environment. As such, it still needs to be architected out and added tothe architecture diagram.Azure Active DirectoryBecause the customer wanted all VMs to be joined to a standalone directory, I opted for Azure ActiveDirectory with Domain Services activated. This type of solution would allow all VMs to be joined to acentral Active Directory. Users could then also be centrally managed without the need for a third-partysolution. If desired, the machines could even be managed with Group Policy.So, I added Azure AD to my Visio.At the time of this project, which was just a few months ago, Azure’s Domain Services were stillmanaged in the Classic Portal and subnet choices for activating Domains Services were limited. As such,when this solution was architected, I opted to put Azure AD Domain services in its own virtual network:11
To make Domain Services available to the production VMs, I opted to peer the Domain Services vNetwith the production vNet.Putting it All TogetherWith the production site connected to the Domain Services vNet via Peering, I had to design a solutionto allow the production and backup networks (which would be in different regions) to talk to each other.To connect the two virtual networks, I opted for a route-based VPN connection between the two. Thiswould require not only a virtual network gateway on each network but also a gateway subnet on each aswell.So, off to Visio, I went.I added a VPN gateway to each virtual network on my architecture diagram, along with a VPNconnection. With that, my proposed architecture addressed the connectivity issue between theproduction and backup sites.12
Completed SolutionAfter a couple days, my proposed solution was complete. I had architected a production site in the Eastregion and a backup site in the West region. Each site would live on its own virtual network. The virtualnetworks in East and West would each be broken down into three subnets: Web, App, and SQL.Network Security Groups for each subnet would control traffic among the subnets, allowing only whattraffic was required.Access to the eventual application would be provide via a Traffic Manager profile and that access to theapplication would be forced to the production site by Traffic Manager unless the production site wasdown. In the event of an outage of the production site, Traffic Manager would automatically routetraffic to the backup site.Load balancers and availability sets in each site would provide high availability and local redundancy forthe front-end and application VMs. The SQL backend database would be replicated from production tobackup, per the customer’s request, over the VPN that was called out in the architecture diagram.Azure Active Directory would be deployed and all VMs joined to the domain, allowing for centralizeduser management.The final solution looked something like this:13
ConclusionA few days after I architected this solution on paper, I presented it to the client for approval. Afterdiscussing the solution, it was approved. A few weeks later, I deployed the solution as architected.During deployment, additional features were added, including a few ETL boxes, a data warehouse, aRedis Cache, and even some additional VMs.When all was said and done, the complete solution looked like this:Although some aspects could have been architected differently (ie. web apps instead of VMs, SQL as aservice instead of VMs, etc), certain requirements and requests from the customer dictated that thesolution be architected with virtual machines.This was a complex and challenging project – but enjoyable all the same. This particular project servesas a great use-case for Microsoft Azure and how all of the different offerings can be used together toarchitect a large-scale infrastructure with very little to no up-front expenditures.If you need assistance with an Azure project, visit me at ThomasMitchell.net. I provide affordableconsulting services and specialize in Microsoft Azure, Active Directory, Microsoft Exchange, and Office365, among others. I’ve even authored a best-selling course on Migrating to Office 365.Thanks for reading and I hope you find this document useful.14
deploy a rather large application infrastructure in Microsoft Azure. This infrastructure was needed to support a new, web-based application that the customer wanted to deploy. The purpose of this document is to provide a detailed look at how I architected a solution, providing you (the reader) with a
