Azure Governance – Tunecom

Virtual Datacenter Concept | 2 of 10 | Governance

admin.yannickd — Wed, 29 Jan 2020 08:20:00 +0000

This blogpost is part of a series of Azure Virtual Datacenter Concept blog posts.

Today let’s focus on probably the most important pillar of the Azure Governance scaffold: Azure Governance.
We will talk about Azure Policies and auditing, resource tagging, managing subscriptions, locking down resources and role based access controls.

What’s it all about? Policies on Azure? And more!

As stated before, this is probably the most important pillar, so what is it exactly?
Azure Governance allows you to define the rules of play to all your subscriptions within your Azure AD tenant. As with typical on-premises scenario’s, you would deploy group policies within your Windows Server Active Directory estate in order to meet your corporate requirements and standards. And most of all to make sure you’re gaining a certain amount of control over your infrastructure.

So, comparable with group policies you say? Not exactly, with Azure Policies we can do so much more and on different levels.

Before we start deploying policies, we need some kind of hierarchy to which we can apply our policies. And as with traditional group policies, we needed organizational units to group our resources into logical containers.

Management Groups

A management group is a logical container that can have policies, blueprints and role based access controls applied. Subscriptions can be added to a management group, so they can inherit the settings that are being applied to a management group. Below example provided by Microsoft, shows you how you can organize management groups, subscriptions and resource groups per Business Unit, Geo-location and environment type.

When on-boarding your first subscription into your tenant, it will be added to your root management group.

Best practice is to create a management group attached to the root management group and start from there. As with group policies, you usually start with a new OU and apply policies on that level. You never start with changing the default domain policies.

The following powershell demonstrates how to create a very simple management group hierarchy.

Powershell script

###########
#
# Let us define our variables here
#
###########

$ParentGroupname = "Contoso_Management_Group"
$ITManagementGroupname = "IT_OPS_Management_Group"
$PRDManagementGroupname = "Production_Environment_Management_Group"
$DEVManagementGroupname = "Development_Environment_Management_Group"

###########
#
# Create the parent management group which is located just below the root management group
#
###########

$ParentGroup = New-AzManagementGroup -GroupName $ParentGroupname -DisplayName $ParentGroupname
$parentobject = Get-AzManagementGroup -GroupName $ParentGroupname
$ParentID = $ParentGroup.ParentId

###########
#
# Create the IT Operations management group as a member of the parent group
#
###########

$ITGroup = New-AzManagementGroup -GroupName $ITManagementGroupname -DisplayName $ITManagementGroupname -ParentObject $parentobject
$ITGroupObject = Get-AzManagementGroup -GroupName $ITManagementGroupname

###########
#
# Create the Production and Development management groups as a member of the IT Operations management group
#
###########

$PRDGroup = New-AzManagementGroup -GroupName $PRDManagementGroupname -DisplayName $PRDManagementGroupname -ParentObject $ITGroupObject
$DEVGroup = New-AzManagementGroup -GroupName $DEVManagementGroupname -DisplayName $DEVManagementGroupname -ParentObject $ITGroupObject


###########
#
# Move our subscriptions to the correct management group
#
###########

$PRDsubscription = Get-AzSubscription | where {$_.Name -eq "Azure IT Ops Prd"}
$DEVsubscription = Get-AzSubscription | where {$_.Name -eq "Azure IT OPS Dev"}


New-AzManagementGroupSubscription -GroupName $PRDGroup.Name -SubscriptionId $PRDsubscription.SubscriptionId
New-AzManagementGroupSubscription -GroupName $DEVGroup.Name -SubscriptionId $DEVsubscription.SubscriptionId

###########
#
# End of script
#
###########

Subscriptions

In the previous example, we’ve added our production and development subscription to a management group. By adding our subscriptions to a management group, we can start defining our rules of play at 2 levels.

Top level: Management Group
Sub level: Subscription

A subscription is a billing and management boundary to deploy your resources in and manage them via the right set of role based access controls.

Your subscription(s) are linked to your Azure AD tenant and can be made available to your Administrators by delegating permissions on a per subscriptions basis.

Our previous example provisioned a Production and Development subscription. With RBAC we can assign our developers the Contributor role to the Development subscription, so they can deploy and manage their resources. That same developer can only be granted a Read-Only role, to make sure no changes are being made on our production platform. If we really want to utilize the power of Azure we will deploy the roles on management group level, so every subscription in the PRD and DEV managemen group is inheriting the right set of roles and permissions.

RBAC (Role Based Access Controls)

And yes, Role Based Access Control is exactly what is states. We are giving access to a set of resources based on the specific role a security principal has. A security principal can be one of the following.

Now how does this work in Azure? RBAC is applied at 2 levels.

Azure Active Directory
Azure Subscriptions or Management Groups

As an example, you can have a global administrator within your Azure Active Directory tenant. That global administrator will have the ability to perform everything within your Azure AD tenant. However, that same global administrator, doesn’t necessarily have the same amount of power within your Azure Subscriptions. Your Azure Subscriptions or Management Groups are using their own built-in roles. If you want your global administrator to have all the keys to the kingdom, you’ll have to grant him Subscription Owner rights within your Azure Subscription.

Below is an overview of the Global Administrator permissions.

Below is an overview of the Azure Owner permissions.

As an administrator, I would love to have the keys to the kingdom, for demo purposes, the below powershell script gives you an idea on how to assign the required roles to a user.

Best practice is to assign roles to a security principal based on the least privilege principle.

Powershell script (credits to Steve König for the password generator included in this script )

###########
#
# Connect to your Azure AD Tenant
#
###########

$MyAzureADTenant = Connect-AzureAD
$tenantname = $MyAzureADTenant.TenantDomain

###########
#
# Define our new admin user
#
###########

$DisplayName = "MyAdmin"
$MailNickName = "MyAdmin"
$CompanyName = "MyCompany"
$UPN = $MailNickName + "@" + $tenantname

###########
#
# Generate a new complex password
#
###########

function Get-RandomCharacters($length, $characters) {
    $random = 1..$length | ForEach-Object { Get-Random -Maximum $characters.length }
    $private:ofs=""
    return [String]$characters[$random]
}
 
function Scramble-String([string]$inputString){     
    $characterArray = $inputString.ToCharArray()   
    $scrambledStringArray = $characterArray | Get-Random -Count $characterArray.Length     
    $outputString = -join $scrambledStringArray
    return $outputString 
}
 
$password = Get-RandomCharacters -length 5 -characters 'abcdefghiklmnoprstuvwxyz'
$password += Get-RandomCharacters -length 1 -characters 'ABCDEFGHKLMNOPRSTUVWXYZ'
$password += Get-RandomCharacters -length 1 -characters '1234567890'
$password += Get-RandomCharacters -length 1 -characters '!"§$%&/()=?}][{@#*+'
 
 
$password = Scramble-String $password

###########
#
# Store the password in a password profile
#
###########


$PasswordProfile = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile
$PasswordProfile.Password = $Password

###########
#
# Create my new admin user
#
###########


New-AzureADUser -DisplayName $DisplayName -CompanyName $CompanyName -UserPrincipalName $UPN -AccountEnabled $true -PasswordProfile $PasswordProfile -MailNickName $MailNickName
$User = Get-AzureADUser -ObjectId $UPN

###########
#
# Assign the Azure AD Global Administrator Role
#
###########

$GlobalAdminRole = Get-AzureADDirectoryRole | Where-Object {$_.displayname -eq 'Company Administrator'}
Add-AzureADDirectoryRoleMember -ObjectId $GlobalAdminRole.ObjectId -RefObjectId $User.ObjectId

###########
#
# !!! Login with an account that has subcription owner permissions in order to add a new security principal to the role
# Grant permissions to my Azure Subscription within my Parent Management Group
#
###########

$MyAzureSubscriptionAccount = Login-AzAccount
$MyAzureSubscription = Get-azsubscription
New-AzRoleAssignment -SignInName $UPN -RoleDefinitionName "Owner" -Scope "/providers/Microsoft.Management/managementGroups/$($ParentGroupname)"


###########
#
# End of script
#
###########

Time for a small recap

Taking the above into account, we’ve made our environment ready with the following structure.

Management Groups
Subscriptions linked to our management groups
Subscription Owner assigned with RBAC at Management Group level

Let’s continue, Resource Locks

Now that we have our management structure up and running, let’s see how we can make use of Azure Policy to start locking down our environment.

Locking down… sounds like a plan, so let’s look at Resource Locks.
Now what is a resource lock and how is it applied.

There are 2 types of resource locks:

DoNotDelete – this will prevent deletion of your resources
ReadOnly – this will prevent changes or updates to your resources

Where can this be applied?

Subscription Level : Applies to all resource groups and resources
Resource Group: Applied to all resources in that specific resource group
Resource: Applied to a specific resource

When can this be applied?

You can apply a lock during the creation of the specific subscription, resource groups or resource. A lock can be applied via powershell or through the portal on existing resources. Or you can leverage Azure Policy to apply locks at scale.

Let us walk through the steps in order to make sure that a Delete lock is being applied to all of our resources.

Azure Policy

For the sake of this blogpost series, I won’t dig too deep into Azure Policies and how the policy structure is being assembled. My colleague @ThomasVanLaere has made a detailed blog-post on Azure Policy, make sure to check that one out as well.

We will make use of a predefined Azure Policy and let’s alter this one to meet our needs. What are our needs?

Audit Subscriptions / Resource groups that don’t have a Delete Lock applied
Remediate Subscriptions / Recource Groups so that a delete lock is applied

Below Policy Definition is exactly what we need to Audit and deploy is a resource lock is not available on our resource groups.

{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Resources/subscriptions/resourceGroups"
        },
   "then": {
      "effect": "deployIfNotExists",
      "details": {
            "type": "Microsoft.Authorization/locks",
            "existenceCondition": {
               "field": "Microsoft.Authorization/locks/level",
               "equals": "CanNotDelete"
         },
         "roleDefinitionIds": [
            "/providers/Microsoft.Authorization/roleDefinitions/0000-0000-0000-0000-0000000"
],
      "deployment": {
         "properties": {
            "mode": "incremental",
            "template": {
               "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json",
               "contentVersion": "1.0.0.0",
               "parameters": {
                  "location": {
                     "type": "string"
                  }
               },
               "resources": [
                  {
                     "type": "Microsoft.Authorization/locks",
                     "apiVersion": "2017-04-01",
                     "name": "ResourceLock",
                     "properties": {
                       "level": "CanNotDelete",
                       "notes": "Prevent accidental deletion of resource groups"
                     }
                  }
               ]
            }
         }
      }
   }
}
}

Now let’s apply this via Azure Policy. Create a new policy definition

Select a scope, since we are going to remediate a setting, we are forced to select a subscription. As of writing, management groups don’t support remediation tasks yet. Enter your details and create a new category if you like.

Now paste in the previous code

And here we go, we have our custom policy definition ready to be assigned.

Now navigate to policy assignments and select assign policy

Select your policy, enter a description and click next.

We have no parameters that need to be defined, so let’s continue.

Next up, yes we would like to remediate our policy. And this requires a managed identity in order to modify our settings. When applying a remediation task via the Azure Portal, the managed identity will receive the required permissions that are required to perform it’s remediating tasks.

Final step, review and create!

Now let’s wait for the assignment to kick in and review our compliance state.

It can take up to 30 minutes before your policy is evaluated. Once the policy is evaluated you see a compliance or non-compliance report.

In this case.. all our resource groups are compliant.

Ready for TAGS

Now that we’ve seen our first policy at work, it’s time to take a look at resource tags. And how we can benefit from applying a right set of tags to our environment. The below list represents a series of tags that we commonly use in our Azure environments.

Description	Tag Name	Values/Format
Cost Center	CostCenter	IT , HR, Finance, Sales, Marketing
Environment	Environment	PRD, ACC, TST, DEV, HUB
Owner	Owner	owner@company.com
Application	App	Public Website, Sales App, ..
Importance	Importance	Critical, high, medium, low

Tags are most used in the following 2 scenario’s:

Cost Management (Providing the ability to chargeback to a specific costcenter or owner)
Resource navigation and automation (automating start/stop schedules by defining out of hours within tags)

Before you start applying tags, make sure to go through the supported tag mechanisms. In our next blogpost we’ll talk about resource groups and as with resource locks we’ll have a look at how we can use Azure Policy to apply tags at scale.

Summary

This blogpost sort of includes the high level steps to start of with managing your subscriptions with management groups. Applying RBAC at scale and locking down your environment with Azure Policy.

What’s next?

The following aspects of the virtual datacenter concept will be highlighted in the following upcoming posts:

Virtual Datacenter Concept – 3 of 10 – Resource Groups
Virtual Datacenter Concept – 4 of 10 – Virtual Networking
Virtual Datacenter Concept – 5 of 10 – Cloud Storage
Virtual Datacenter Concept – 6 of 10 – Identity Options
Virtual Datacenter Concept – 7 of 10 – Log Analytics
Virtual Datacenter Concept – 8 of 10 – Security
Virtual Datacenter Concept – 9 of 10 – Business Continuity
Virtual Datacenter Concept – 10 of 10 – Automation

Missed a part or want to review a previous section? Be sure to check out my previous posts:

Virtual Datacenter Concept – Introduction
Virtual Datacenter Concept – 1 of 10- Naming Conventions
Virtual Datacenter Concept – 2 of 10 – Governance

The post Virtual Datacenter Concept | 2 of 10 | Governance appeared first on Tunecom.

Virtual Datacenter Concept | 1 of 10 | Naming Conventions

admin.yannickd — Tue, 07 Jan 2020 20:47:00 +0000

This blogpost is part of a series of Azure Virtual Datacenter Concept blog posts.

Let’s talk about one of the key pilars from the Azure Governance scaffold: naming conventions

Understanding which resource, what is does and where it is located

Naming standards and conventions have been around for decades.
They are commonly used to identify objects and are used in most industries.

Let’s take car manufacturer BMW as an example, their cars are named with certain key characteristics in mind.

BMW 118D Hatch
Brand = BMW
Motorization = 1800 CC
Fuel Type = Diesel
Bodywork = Hatch (5 doors)

Pretty simple example on how a well defined naming standard can immediately give you the necessary info about a certain object. In essence, that’s why naming conventions are used.

Azure Naming conventions

As with regular industry naming conventions, standardizing the way you define your Azure Resources is crucial.

Microsoft has a predefined set of “policies” that need to be met with regards to naming your resources, the following docs article gives you an overview on how naming standards can be applied.

Below you can find a couple of commonly used resources that need to be uniquely identified globally across Microsoft Azure.

! We will need some kind of generalization to keep our resources unique

Entity	Scope
API management	Global
Key vault	Global
Function app	Global
Web app	Global
Storage account name (data)	Global
Storage account name (disks)	Global
Data Lake Storage	Global
Container registry	Global
Service Bus namespace	Global
Event Hubs namespace	Global
Log Analytics Workspace	Global

Taking the above information into account, we’ve generated a set of scripts that allow you to easily define a naming policy.

Input variables

To start building our naming conventions we first need a couple of input variables that are unique to our setup.

#####################################################################################
#
# This script provides you with an overview of all naming conventions that are being used in the Virtual Datacenter Concept
# Version: 0.1
# Author: Yannick Dils
#
#####################################################################################

#####################################################################################
#
# Below is a set of variables that is being used in order to populate the naming conventions
#
#####################################################################################


# Variable abbreviation for the resource group that will be used for central shared services
$RG_PurposeHUB = "hub" 

# Variable abbreviation for the resource group that will be used for production workloads
$RG_PurposePRD = "prd"

# Variable abbreviation for the resource group that will be used for acceptance workloads
$RG_PurposeACC = "acc"

# Variable abbreviation for the resource group that will be used for test workloads
$RG_PurposeTST = "tst"

# Variable abbreviation for the resource group that will be used for development workloads
$RG_PurposeDEV = "dev"

# Variable abbreviation for the customer / environment
$Cus = ""

# Variable abbreviation for the resource location
$Location = "weu"

# Variable which provides the desired resource location
$FullLocation = "WestEurope"

# Variable abbreviation for the resource owner
$owner = "YD"

# Variable abbreviation for the environment tier
# 1 : HUB + PRD
# 2 : HUB + PRD + ACC
# 3 : HUB + PRD + ACC + TST
# 4 : HUB + PRD + ACC + TST + DEV
$EnvironmentTier = "4"

# Variable required for resource generalization
$Guid = [guid]::NewGuid()
$MyGUID = $Guid.Guid.Remove(8)

#####################################################################################
#####################################################################################

Resource Groups

Resource group naming conventions are provided as per below. A resource group should be able to clearly define the customer or project, the type of environment and the purpose of the resources that are being created in the resource group.

Customer or project (3 letter abbreviation)	–	Tier (3 letter abbreviation of the Tier, HUB; PRD, TST, ACC, DEV)		Purpose (Resource Group Purpose Abbreviation)	–	Resource Purpose
	–	hub	–	identity	–	rg

Powershell script

$HUBRGID = $Cus + '-' + $RG_PurposeHUB + '-' + 'identity' + '-rg'

Networking

Networking related naming conventions are provided as per below. In order to be able to perform smart discovery over your networking resources, Virtual Networks (VLANs), Subnets, Network Security Groups are named according to the endpoints and services that are located in the specified network topology.

Virtual Networks

Customer or project (3 letter abbreviation)	–	Tier (3 letter abbreviation of the Tier, PRD, TST, ACC, DEV)	–	Location (3 letter abbreviation of the location)	–	Resource Purpose
	–	hub	–	weu	–	vn

Powershell script

$virtualnetworkHUBname = $Cus + '-' + $RG_PurposeHUB + '-' + $Location + '-vn'

Subnets

Customer or project (3 letter abbreviation)	–	Tier (3 letter abbreviation of the Tier, PRD, TST, ACC, DEV)	–	Subnet purpose	–	Resource Purpose
	–	hub	–	identity	–	sn

Powershell script

$hubsubnetname1identity = $Cus + '-' + $RG_PurposeHUB + '-' + 'identity' + '-sn'

Network Security Groups

Customer or project (3 letter abbreviation)	–	Tier (3 letter abbreviation of the Tier, PRD, TST, ACC, DEV)	–	Subnet purpose	–	Resource Purpose
	–	hub	–	identity	–	nsg

Powershell script

$hubnsgid = $Cus + '-' + $RG_PurposeHUB + '-' + 'identity' + '-' +'nsg'

Public IP addresses

Public IP usage	–	Public IP abbreviation
resourcename	–	pip

Powershell script

$vmpip = $VirtMachName + '-pip'

Load Balancing

Azure provides several cloud native load balancing solutions, as with other Azure Resources, they require a logical naming convention.

Internal Load Balancer

Internal Load Balancer	–	Purpose
ilb	–	adfs
ilb	–	sql

Powershell script

$adfsintlb = 'ilb-' + 'adfs'

External Load Balancer

External Load Balancer	–	Purpose
elb	–	adfswap
elb	–	rdgw

Powershell script

$adfsextlb = 'elb-' + 'adfswap'

General Compute Resources

Compute resources contain virtual machines, availability sets, storage and everything related to the infrastructure you need to run your apps.

Storage Accounts

Storage Account	Redundancy level	Customer Abbreviation	Location	Tier	Purpose
st	lrs		weu	prd	logs

Powershell script

$SA_Logs = 'stlrs' + $Cus + $location  + $RG_PurposeHUB + 'logs'

Availability Sets

Customer Abbreviation	–	Tier	–	Purpose	–	Resource Purpose
	–	hub	–	sql	–	as

Powershell script

#$hubavsql = $Cus + '-' + $RG_PurposeHUB + '-' +  'sql' + '-' + 'as'

Virtual Machines

Customer Abbreviation	Location	Optional Tier	Purpose	##
	weu	prd	sql	01

Powershell script

$VMShortName = "sql01"
$VirtMachName = $Cus.ToLower() + $location.ToLower() + $RG_PurposePRD + $VMShortName

Virtual Machine Disks

Virtual Machine Name	–	Disk drive letter
	–	c
	–	e

Powershell script

$OSDiskName = $VirtMachName + '-c'

Summary

In this blogpost, we’ve provided some guidance with regards to naming conventions and standards. The powershell “script” provided can be used for your convenience. In the upcoming series of posts we will be re-using these variables in order to build our Virtual Datacenter Concept topology.

Checkout our previous blogpost to recap on the Virtual Datacenter Concept.

What’s next?

The following aspects of the virtual datacenter concept will be highlighted in the following upcoming posts:

Virtual Datacenter Concept – 2 of 10 – Governance
Virtual Datacenter Concept – 3 of 10 – Resource Groups
Virtual Datacenter Concept – 4 of 10 – Virtual Networking
Virtual Datacenter Concept – 5 of 10 – Cloud Storage
Virtual Datacenter Concept – 6 of 10 – Identity Options
Virtual Datacenter Concept – 7 of 10 – Log Analytics
Virtual Datacenter Concept – 8 of 10 – Security
Virtual Datacenter Concept – 9 of 10 – Business Continuity
Virtual Datacenter Concept – 10 of 10 – Automation

The post Virtual Datacenter Concept | 1 of 10 | Naming Conventions appeared first on Tunecom.

Virtual Datacenter Concept | Introduction

admin.yannickd — Tue, 31 Dec 2019 09:18:32 +0000

This blogpost is part of a series of Azure Virtual Datacenter Concept blog posts.

The following series of posts is a direct reference to the Virtual Datacenter Concept provided by Microsoft as part of the Cloud Adoption Framework.

My intention is to provide you with a holistic overview, lessons learned and best practices over the last couple of years during the design and implementation phase of the Azure Virtual Datacenter.

What is the Azure Virtual Datacenter Concept (VDC)?

VDC is a series of guidelines that can be interpreted in various ways, the main goal of the VDC is to be able to deploy and manage your Azure resources in a secure and proper fashion.

When looking at AzOps and AzSec we are striving to build an operational and security model that fits the customers needs and wishes, which can still provide the promised scalability, flexibility and cloud optimization benefits. AzOps and AzSec should play a supporting role in the application landscape

Taking into account the perspective of DevOps and DevSecOps the VDC should facilitate the application development team to perform CI/CD in a way that the entire IT infrastructure which is oriented around your Line-of-business applications closes the gap between the operations and deployment lifecycle.

Why should the Virtual Datacenter Concept matter to you?

Planning Cloud Adoption is key, we’ve often seen Cloud environments that have been setup with no clear vision of the future application and IT landscape, which ended up in consuming a lot of credits that could’ve been spent more wisely.

On your road to onboarding IaaS, PaaS and SaaS the Virtual Datacenter Concept is your hitchhikers guide to the galaxy. It’s often seen as a way to easily lift and shift your servers, when looking at the VDC from a broader perspective, it can be a good fit to start transitioning to PaaS and SaaS.

How does this all translate into practice?

Below infographic shows a typical scenario where a DTAP (Development, Test, Acceptance, Production) environment has been setup and during deployment, key components have gone missing.

In order to fix the above situation, we’ve got a couple of options, either deploy additional equipment on Azure or consolidate and optimize to make the best use of all Azure Resources.

Below IaaS overview shows how we can consolidate the central shared services and make use of unique Azure techniques like vnet peering to tie everything together in a secure way.

Extending your services to Azure

In the above example we’ve seen a full blow DTAP environment located on Azure infrastructure. However Cloud Adoption isn’t about moving virtual machines to the Cloud. When moving to the cloud our goal is to provide our end-customers with tools and applications that are always on and can meet the necessary capacity demands.

As a start we would primordially get started with the Virtual Datacenter Basic setup. This allows you to extend your on-premises workloads to Azure with a minimum amount of resources.

The basic setup consists of :

Hybrid cloud identity which can be setup in various ways that suits your business needs.
Virtual Private network connectivity based on Azure Virtual Network gateway
Resource Governance
Backup and business continuity additions

What’s next?

Hope you liked the introduction, and sort of know where we are working towards in this blogpost series.

The following aspects of the virtual datacenter concept will be highlighted in the following upcoming posts:

Virtual Datacenter Concept – 1 of 10- Naming Conventions
Virtual Datacenter Concept – 2 of 10 – Governance
Virtual Datacenter Concept – 3 of 10 – Resource Groups
Virtual Datacenter Concept – 4 of 10 – Virtual Networking
Virtual Datacenter Concept – 5 of 10 – Cloud Storage
Virtual Datacenter Concept – 6 of 10 – Identity Options
Virtual Datacenter Concept – 7 of 10 – Log Analytics
Virtual Datacenter Concept – 8 of 10 – Security
Virtual Datacenter Concept – 9 of 10 – Business Continuity
Virtual Datacenter Concept – 10 of 10 – Automation

The post Virtual Datacenter Concept | Introduction appeared first on Tunecom.