Hello Everyone,
This post is to explain about WAP Architectures from 2 different scenarios: STANDALONE DEPLOYMENT & HIGH AVAILABILITY DEPLOYMENT.
NOTE:
ARCHITECTURE SHOWN IN THIS POST IS NOT RELATED TO ANY CUSTOMER... THESE ARE SIMPLE DESIGN CREATED BY ME TO MAKE YOU UNDERSTAND ABOUT DEPLOYMENT.
THIS ARCHITECTURE WILL DIFFER FOR EVERY REQUIREMENTS BASED ON RESPECTIVE ENVIRONMENTS. TO GIVE YOU BETTER UNDERSTANDING, I HAVE CREATED A VERY SIMPLE ARCHITECTURES FOR BOTH SCENARIOS.
To see Microsoft Windows Azure Pack (PRIVATE CLOUD - WAP) - INTRODUCTION - Part 1, Click Here!
To see Microsoft Windows Azure Pack (PRIVATE CLOUD - WAP) - Components & Deployment Types- Part 2, Click Here!
To see Microsoft Windows Azure Pack (PRIVATE CLOUD - WAP) - Complete Setup Deployment Requirement - Part 3, Click Here!
Let's start understanding both deployment types in details below...😉
Consider "n-1" where N = 4. So All 4 servers will be part of cluster and all CSV volumes are shared on all physical nodes but 1 Node will be always empty (No VM should be deployed on that server) because when any node out of other 3 nodes goes down, then all VMs can be fail-over (or Live Migrate) to complete available empty physical server to utilise resources. This "n-1" will be called as 1 Failover. Similarly, if You are using "n-2", then You can go for min 2 Failover.
Now, You may get confused here with above calculation because if You are deploying VMs on all nodes then You may think that even though Clustering is configured still You can not live migrate VMs.
So, Understand the concept that clustering is a concept of combining physical resources in such a way that if 1 nodes goes down then VM which was using resources of that node can use the next available physical nodes resources. By resources I mean to say Memory & CPU.
If Your VMs are assigned with Static Memory with Higher size and When any node goes down but next available node doesn't have required resource available then Your VM will still migrate on next available node but will go in saved-critical state.
That's why for best practices I have explained concept for n-1, n-2 or so on based on Your environment requirement. ***APPLICABLE FOR PRODUCTION ENVIRONMENT (NOT MANDATORY BUT RECOMMENDED).
All is a game of capacity planning & utilization reports. You must use best practices calculations in such cases for better performance & resource optimization.
This layer is nothing but using Your Tenant VMs via Internet access. You will be given Tenant portal access from where You can provision VMs to Cloud Infra Servers and check their status, report and take console from that portal itself. Cloud is nothing but using Your servers over Internet (Web access).
This layer includes same VMs which are deployed on Cloud Infra Servers where Cloud Infra Servers is known as Back-end Infrastructure and Cloud Layer is front-end portal for Tenants.
TO LEARN ABOUT GUEST CLUSTERING CONFIGURATION, CLICK HERE!!!
This is all about basics of both architecture deployment types. These both are very basic methods to just explain & clear Your understanding on WAP. 😊😊
For detailed sizing calculation & prerequisites for both deployment, I will explain in next post with examples.
This post is to explain about WAP Architectures from 2 different scenarios: STANDALONE DEPLOYMENT & HIGH AVAILABILITY DEPLOYMENT.
NOTE:
ARCHITECTURE SHOWN IN THIS POST IS NOT RELATED TO ANY CUSTOMER... THESE ARE SIMPLE DESIGN CREATED BY ME TO MAKE YOU UNDERSTAND ABOUT DEPLOYMENT.
THIS ARCHITECTURE WILL DIFFER FOR EVERY REQUIREMENTS BASED ON RESPECTIVE ENVIRONMENTS. TO GIVE YOU BETTER UNDERSTANDING, I HAVE CREATED A VERY SIMPLE ARCHITECTURES FOR BOTH SCENARIOS.
To see Microsoft Windows Azure Pack (PRIVATE CLOUD - WAP) - INTRODUCTION - Part 1, Click Here!
To see Microsoft Windows Azure Pack (PRIVATE CLOUD - WAP) - Components & Deployment Types- Part 2, Click Here!
To see Microsoft Windows Azure Pack (PRIVATE CLOUD - WAP) - Complete Setup Deployment Requirement - Part 3, Click Here!
Let's start understanding both deployment types in details below...😉
STANDALONE DEPLOYMENT ARCHITECTURE:
Below is the simple architecture for STANDALONE DEPLOYMENT:
Mostly, STANDALONE DEPLOYMENT is used for POC/Staging/Dev Testing environment purposes only. So, You can use minimal resources for the complete deployment which may have differ architectures.
Above architecture includes below key sections:
ACTIVE DIRECTORY:
All Management Servers (Explained in Management Layer section below) & Cloud Infra Servers (Explained in Cloud Infra Servers Layer section below) must be joined to active directory.
Active Directory will also be used for creating accounts which will be used for deploying complete setup. All setup VMs will be part of Active directory.
MANAGEMENT LAYER:
This section includes Physical Management Servers & Virtual Management VMs which are created on those physical management servers (where complete setup will be installed).
As shown in above architecture diagram, I have shown only 1 Physical Server with 1 additional disk where all Virtual Hard Disks will be placed for all Management VMs. Disk size will be based on capacity planning for complete setup deployment where You have to calculate complete required size (will explain sizing details during prerequisites for each components in upcoming posts).
You can also use Physical 'N' numbers of Management Servers as per Your environment requirements.
MANAGEMENT VMs on PHYSICAL MANAGEMENT LAYER:
This section is basically consider as standalone deployment if You are deploying each component on 1-1 VMs respectively with their Database as shown below:
In this case, if any of VM or individual service goes down, Your complete setup will be down. There will be no Failover of services on VMs without High Availability.
This is why STANDALONE DEPLOYMENT is not recommended for Production Environment but You can use it on Your own risks.
CLOUD INFRA SERVER LAYER:
This section will includes those servers which will have Cloud VMs on their hyper-v and CSV or Local disks.
As shown in diagram below, I have shown clustered server with CSV (Clustered Shared Volume) volume where all Tenant's VMs will be placed:
It is not mandatory to have Clustered Servers. You can also use standalone physical servers with local additional disks but in that case, if physical server goes down then all VMs will be goes down & Your tenants can not access them.
If using clustered infra then if any server goes down then VMs can float (Live Migrate) to other available servers.
NOTE: Always keep in mind that Clustered should be created with concept like n-1, n-2 or n-3 and so on based on environment requirements - availability & usages of resources.
EX: Consider "n-1" where N = 4. So All 4 servers will be part of cluster and all CSV volumes are shared on all physical nodes but 1 Node will be always empty (No VM should be deployed on that server) because when any node out of other 3 nodes goes down, then all VMs can be fail-over (or Live Migrate) to complete available empty physical server to utilise resources. This "n-1" will be called as 1 Failover. Similarly, if You are using "n-2", then You can go for min 2 Failover.
Now, You may get confused here with above calculation because if You are deploying VMs on all nodes then You may think that even though Clustering is configured still You can not live migrate VMs.
So, Understand the concept that clustering is a concept of combining physical resources in such a way that if 1 nodes goes down then VM which was using resources of that node can use the next available physical nodes resources. By resources I mean to say Memory & CPU.
If Your VMs are assigned with Static Memory with Higher size and When any node goes down but next available node doesn't have required resource available then Your VM will still migrate on next available node but will go in saved-critical state.
That's why for best practices I have explained concept for n-1, n-2 or so on based on Your environment requirement. ***APPLICABLE FOR PRODUCTION ENVIRONMENT (NOT MANDATORY BUT RECOMMENDED).
All is a game of capacity planning & utilization reports. You must use best practices calculations in such cases for better performance & resource optimization.
CLOUD LAYER:
This layer is nothing but using Your Tenant VMs via Internet access. You will be given Tenant portal access from where You can provision VMs to Cloud Infra Servers and check their status, report and take console from that portal itself. Cloud is nothing but using Your servers over Internet (Web access).
This layer includes same VMs which are deployed on Cloud Infra Servers where Cloud Infra Servers is known as Back-end Infrastructure and Cloud Layer is front-end portal for Tenants.
OVERALL CYCLE SUMMARY FOR STANDALONE DEPLOYMENT:
Each section individually is explained in details above. Summary of above deployment is each Management Servers (both physical & virtuals) will be joined to Active Directory. Cloud Infra Servers will be added to SCVMM. All cloud resources (network, storage. compute, subscriptions) are managed by SCVMM. Tenants will be provided access to only required resources. SPF will play as intermediate role between SCVMM & WAP which will be responsible to handle all request/responses in both directions.
HIGH-AVAILABILITY (HA) DEPLOYMENT ARCHITECTURE:
In this architecture, all physical & virtual management layer will be in HA mode i.e. in physical & guest clustering configuration mode. Required min 2 or more Physical Servers for Management Physical Servers & Min 2 or more Virtual Servers for each components will be required for WAP Setup.
Architecture will be like shown below: (Simple architecture shown, will differ for each different requirement & environment based on capacity & utilisation plannings):
All layers are same as explained above. Only difference comes with configuring everything in High-Availability mode.
For virtual management layer, Each components will have min 2 VMs or max You can take as per Your wish with resources availability (as per my suggestion, 4 VMs will be enough but resource utilisation will be more so consider resource planning as well while planning for deployment).
SCVMM will be configured for Guest Clustering while other 2 components (SPF & WAP) will be configured with NLB (Network Load Balancer) as shown in above diagram. Each component Database will be configured on separate DB VMs which will be configured with Guest Clustering SQL Always-on Mode.
TO LEARN ABOUT GUEST CLUSTERING CONFIGURATION, CLICK HERE!!!
Other components like SCOM, SCCM don't support guest clustering concept. Instead of that, In SCOM, You can have more Management Servers in environment while in SCCM, You can deploy CAS environment with multiple Primary & Secondary sites.
Rest all concept is already explained above.
For detailed sizing calculation & prerequisites for both deployment, I will explain in next post with examples.
Share Your feedback or any query!!!
Happy Reading!!!
If You like my post then follow my updates:
Join my Facebook group for updates on trending technologies/technical references/issues etc: