This is multipart project overview. The brief here was to create a high level design for a virtual datacentre in Azure for a company looking to move the contents of a datacentre and few other sites with On-premise server infrastructure to the cloud.
Part One gives a quick run down of the scoping and an overview of the design.
All code and documentation is available at https://github.com/jmattmacd/AzureVirtualDatacentre
Part One – Overview and Scoping
Part Two – General Azure Resources
Part Three – Network Resources
Part Four – Server Infrastructure Resources
The design is based heavily on Microsoft’s own reference designs with some modifications. Probably most usefully when I wrote the design I included the scripts to create it in prototype/test so I am reproducing it here.
The scripts and functional elements are an important part of the design but I have also included included the HEAVILY redacted design document which goes through considerations for the design – Cloud vs On Prem, MS vs other providers, Site Recovery Options, Connectivity Options, etc in the script package above on the off chance it is of any interest.
Naming and Addressing
Throughout I have specified naming using a JMM_ prefix and IP addressing specifying ranges in 10.$IP.0.0/16 $IP can just be changed to prevent overlap with existent infrastructure.
The project was delivered over several phases and looks to deliver a dynamically expandable structure which has no definitive “completion” so the scope of this project is fixed to providing the structure and a fully documented mechanism for continuous growth and change.
The solution will create a virtual data centre and associated basic infrastructure complete with necessary resources for core services (Authentication, DNS, DHCP). Initially Data, Compute and Migration Networks will be defined and built with processes, scripts and conventions designed for adding further resources
In scope for this phase of the project are:
- Outline of connectivity into Azure from current network
- Delivery of a functional infrastructure network and extension of AD into azure site.
- Delivery of a functional migration network
- Delivery of a functional DMZ network
- Delivery of functional 3-tier network for future applications and services and for existing resources to be rebuilt or redeployed into.
- Overview of monitoring recommendations and interoperability with current tools (ServiceNow, etc)
- Overview of conventions, processes and methodology for extending with further resources (Virtual networks, Subnets, Servers
The project will not deliver the following which will need to be examined at a later date:
- Detailing connectivity. The connectivity option on this project is a simple VPN endpoint. The definition of the Local (On Prem) side of this will be decided in conjunction with the existing network owner. This design presents a simplified model which can be easy modified to work with whatever technology and configuration they require.
- Detail of Network Virtual Appliances. These have been included in the design but not specified or detailed.
- Full network monitoring and proactive capabilities. This will be dependent on tooling; outline recommendations are included
- Disaster Recovery planning and configuration. As the services that are going into azure are not currently known Disaster recovery and planning for them is out of scope of this solution. However this has been considered as far as possible and some recommendations provided.
Target Architecture
A picture paints a thousand words…
But Ill also include the thousand words…
The architecture is based around multiple subnets (‘tiers’) in an Azure virtual network connected to the existing network via a site to site IPSec VPN.
The solution is designed around a 3-tier paradigm with all applications broken into their Web (User), Business (App) and Data (Storage and SQL) components and separated into the subnets to provide security, control and isolation. Applications are then accessed via the DMZ network controlled by Azure network security groups and other firewall/network virtual appliance solutions.
As the current application stack is not compatible with that goal a “Migration” tier has been designed which has no restrictions on access – anything on the virtual or on-premise networks can access it exactly as if it was an On-Premise site LAN segment.. This can act as a single tiered subnet where application/data/user servers can all coexist as per the current on-site network design until adoption of a more structured and secured approach.
An infrastructure tier has been specified which will hold infrastructure services – Active Directory, DNS, etc. The extension of AD into this virtual site and deployment of a single domain controller is delivered in this design. DNS and LDAP lookups can then be allowed to the infrastructure network from the other tiers as required to support lookups and authentication for applications and services within them.
A management tier has been specified along with a single Non-Member server. This will have access to all other tiers and can be used as a hop box so RDP does not need to be opened across the VPN to every tier. The dynamic nature of the Azure cloud also means it can be immediately given and extern IP address and used as an emergency method of access should there be a failure in the VPN link(s).
The DMZ Tier (Inside) is addressable by any other tier or the On-Prem network. Outbound security from that tier is then controlled by network virtual appliance to by designed and controlled by the network security team. The NVAs will be deployed with one interface on this DMZ tier and one on the DMZ network from which outbound connections can be set up. Detail of individual components follows. The majority of the infrastructure is to be deployed as code, code snippets are included on these posts and in the associated downloadable archive.
