Tuesday, January 19, 2021

Azure recovery Services Vault overview and how to create one

In this blog post I would talk about Azure Recovery Services vault; this is the central component for backup or DR planning in Azure or even for on-prem if you are planning to use Azure Site recovery (ASR) for DR or Azure Backup.

A Recovery Services vault is a storage entity in Azure that houses data it stores the backups and recovery points created over time. The Recovery Services vault also contains the backup policies that are associated with the protected virtual machines. You can use Recovery Services vaults to hold backup data for various Azure services such as IaaS VMs (Linux or Windows) and Azure SQL databases. Recovery Services vaults support System Center DPM, Windows Server, Azure Backup Server, and more. Recovery Services vaults make it easy to organize your backup data, while minimizing management overhead.

We can have up-to 500 vaults in a subscription and 1000 Azure VMs can be backed up in a single vault with the frequency of once a day. Here you need to keep one thing in mind that this Vault should be in the same region as your VMs (for backup only).

 Recovery Services vaults are based on the Azure Resource Manager model of Azure, which provides features such as:

  • Enhanced capabilities to help secure backup data: Enhanced security features for backup that allow for data recovery even if production and backup servers are compromised
  • Central monitoring for your hybrid IT environment: With Recovery Services vaults, you can monitor not only your Azure IaaS VMs but also your on-premises asset backups (if configured) from a central portal.
  • Azure role-based access control (Azure RBAC): Recovery Services vaults are compatible with Azure RBAC, which restricts backup and restore access to the defined set of user roles. 
  • Soft Delete: With soft delete, even if a malicious actor deletes a backup (or backup data is accidentally deleted), the backup data is retained for 14 additional days, allowing the recovery of that backup item with no data loss. The additional 14 days of retention for backup data in the "soft delete" state don't incur any cost to you.
  • Cross Region Restore: Cross Region Restore (CRR) allows you to restore Azure VMs in a secondary region, which is an Azure paired region. If Azure declares a disaster in the primary region, the data replicated in the secondary region is available to restore in the secondary region to mitigate real downtime disaster in the primary region for their environment.

Storage settings in the Recovery Services vault: Within Recovery Services Vault Azure Backup automatically handles storage for the vault how as per our availability requirement we can choose the storage redundancy as one of the following, local, geo or zonal redundancy. As of now zonal is not available in all regions.

  • Locally redundant storage (LRS) copies your data synchronously three times within a single physical location in the primary region. LRS is the least expensive replication option but is not recommended for applications requiring high availability.
  • Zone-redundant storage (ZRS) copies your data synchronously across three Azure availability zones in the primary region. For applications requiring high availability, Microsoft recommends using ZRS in the primary region, and also replicating to a secondary region.
  • Geo-redundant storage (GRS) copies your data synchronously three times within a single physical location in the primary region using LRS. It then copies your data asynchronously to a single physical location in the secondary region.

Encryption settings in the Recovery Services vault: By default, all your data is encrypted using platform-managed keys. You don't need to take any explicit action from your end to enable this encryption. It applies to all workloads being backed up to your Recovery Services vault.

You can choose to encrypt your data using encryption keys owned and managed by you.

Azure Site Recovery: Site Recovery contributes to your business continuity and disaster recovery (BCDR) strategy, by orchestrating and automating replication of Azure VMs between regions, on-premises virtual machines and physical servers to Azure, and on-premises machines to a secondary datacenter.

This Recovery service vault blade would become the central point to configure enable and initiate the VM failover and fail back.

Note: You can also use the VM blade to configure replication for an individual VM however here you can create recovery plan to orchestrate the failover of multiple VMs part of a single application environment.

When you enable replication for a VM to set up disaster recovery, the Site Recovery Mobility service extension installs on the VM and registers it with Azure Site Recovery. During replication, VM disk writes are sent to a cache storage account in the source region. Data is sent from there to the target region, and recovery points are generated from the data. When you fail over a VM during disaster recovery, a recovery point is used to restore the VM in the target region.


coming soon...

Related Reads:

Azure Recovery Service Vault Overview

Backup Support Matrix

Azure Site recovery Documentation, Azure to Azure or On-prem to Azure Scenario (AWS or any other Cloud to Azure would also fall in this category).

Also read the Backup and Site recovery FAQs.

That's it for today....Thanks :)

Monday, January 18, 2021

Azure Resource Hierarchy and how to manage them effectively

In this blog post, we would discuss about the Azure resource hierarchy and how you can organize and manage them effectively from the point of Security, management, and tracking the cost.

As we know that one needs to have an active Azure Subscription to create any resource in Azure account and once you have that then need to create a Resource Groups (RG) and then can create all other resources by putting them in RGs.

Now think from the perspective of an Org having multiple subscriptions, that is where you need a Scope above subscription to efficiently manage them and that is where can use Azure Management Groups. Here we can manage Access Policies & Compliance for these subscriptions as a single entity and whatever access, policy, or compliance you would configure would get inherited top-down.

How the four management-scope levels relate to each other

·        Management groups: These groups are containers that help you manage access, policy, and compliance for multiple subscriptions. All subscriptions in a management group automatically inherit the conditions applied to the management group.

·        Subscriptions: A subscription logically associates user accounts and the resources that were created by those user accounts. Each subscription has limits or quotas on the amount of resources you can create and use. Organizations can use subscriptions to manage costs and the resources that are created by users, teams, or projects.

·        Resource groups: A a resource group is a logical container into which Azure resources like web apps, databases and storage accounts are deployed and managed.

·        Resources: Resources are instances of services that you create, like virtual machines, storage, or SQL databases.

Note: All Subscriptions within a single MG must the same AAD Tenant.

This was a simple example of Management group hierarchy; you can create multiple Management Groups under Root Management Group for Azure Actively Directory. The creation of other Management groups could be part of your resource’s management planning to achieve one of the following,

·        Group your subscriptions: Easily manage your Azure subscriptions by grouping them together and taking actions in bulk

·        Mirror your organization’s structure: Create a hierarchy of Azure management groups tailored to your organization to efficiently manage your subscriptions and resources

·        Apply policies or access control to any service Use full platform integration to apply governance conditions such as policies, access controls, or full-fledged blueprints to any Azure service

Each Directory is given a single top-level management group called the “Root Management group”. This Root management group is built into the hierarchy to have all subscriptions part of that directory fold into it. This is used to assign the global policies and Azure role assignment at the directory level. To mange access at this scope the Azure AD Global administrator need to elevate themselves to have User Access Administrator role of this root group initially. Once you have the permission then can assign any Azure role to other directory users or Groups to manage the access, compliance and related aspects.

A management group tree can support up to six levels of depth however this limit doesn’t include root or subscription level. Keep in mind that each MG or subscription can have only one parent, and all these are within a single hierarchy in each directory.

Related Demo: How-to Create and manage Azure Management Groups and related hierarchy.

Related reads:

Azure Management Groups And Hierarchy

Azure management groups

That’s It….Thanks 😊

Sunday, April 19, 2020

vSphere 7 Lab - Nested deployment of VCSA 7 on VMware Workstation

In this post, I would talk about the changes noticed during the nested vSphere 7 Lab deployment and when tried to initially access the vCenter using WebClient.

For direct nested deployment where you are deploying the VCSA directly on VMware Workstation 13.x or later, its a three-step process but before we go into that, extract the VCSA7 iso file and locate the vcsa folder, there you will find the VCSA appliance OVA file.
  • Right-click on vcsa open virtualization archive (ova) file and select open with VMware workstation or double click on this ova file => in subsequent screens follow the screen instruction and then provide the required IP, DNS, Gateway, FQDN etc and deploy the actual appliance
  • Once the appliance is successfully deployed, set up its root password by accessing it through workstation console
  • Now go to https://vcsa_fqdn_or_ip:5480, login with root and complete the rest of the configuration and deployment, vCenter PSC setup, create administrator password etc.
However, when I tried the same with VCSA 7 on the latest version on VMware Workstation 15.5.2, I was able to deploy and configure the appliance but was unable to access the vSphere WebClient.
I was able to access the vCenter Server Appliance Management Interface (VAMI) and complete the rest of the configuration however when tried to access the vSphere WebClient it simply failed.

Checked the status of the related services. found no issue however now I recall there was some error occurred during the VCSA appliance configuration however and there was no successfully completed message.

Then I thought to go with the standard lab deployment procedure, where we deploy VCSA on one of the already deployed ESXi hosts (double nested).

Once the deployment completed then I was able to access the vCenter Server Appliance Management Interface (VAMI) by going to https://vcsa_fqdn_or_ip:5480 and VCSA by going to https://vcsa_fqdn_or_ip:443 or just https://vcsa_fqdn_or_ip however, noticed that we no longer have flash-based WebClient client available (remember this url, https://fqdn_or_ip:9443/vsphere-client/). 

Now it is just HTML5 based WebClient.
As you can see, unlike vCenter 6.x there is no Flex-based vSphere WebClient option available.

One can access the vCenter Server by using the following url, https://vcsa_fqdn_or_ip/ui/

One more thing which I noticed that VMware Workstation 15.5.2 doesn't have ESXi 7 listed in supported OS list however I didn't see any issue when deployed it by selecting ESXi6.7. Hopefully, this would be available with the next update of the workstation.

Update: Tried to re-deploy the VCSA 7 appliance directly on VMware Workstation again and this time during post configuration deployment it got stuck at 70% with a page refresh error message however I waited for around 20 more minutes before hitting the browser refresh button which brought me to vCenter Server Appliance Management Interface (VAMI). Checked about the status of services and configuration and then tried to access it again using the https://vcsa_fqdn_or_ip and voila getting started page opened with an option to launch vSphere Client (HTML5) like shown in the first screenshot.

That's it for now...Thanks :)

Wednesday, April 15, 2020

AWS Glue Vs. Azure Data Factory : Similarities and Differences.

In today’s world emergence of PaaS services have made end user life easy in building, maintaining and managing infrastructure however selecting the one suitable for need is a tough and challenging task. We often tend to select hybrid cloud solution for our customers thus providing them the cost efficient solutions with cutting edge technologies.
The fundamental building block of any company is DATA  , without which no organization can think of survival. But to store and analyze this Data is the traditional approach of warehouse is not fit well because of many reasons. It could be increasing cost or infrastructure or over head of management ,but it does not fit well today.
The other alternative we have is Cloud , be it AWS / Azure /Google or any other. Each of these cloud offer different solutions to problems that we have. But fundamental Question remain same , which cloud to use and why.
Take Data analytics itself , For Running ETL jobs both AWS and Azure offer some solutions , but as architect we need to deeply understand the similarity and differences between two , before suggesting that to customer.
I am here highlighting the some fundamentals similarities and differences between two technologies  hoping that it might help the individuals who need to make solutions for customers .
Similar Features for two services 
AWS Glue
Data Factory 
Fully Managed, Server-less ETL engines
Data ingestion as both structured as well as unstructured data.
Auto generation of code
Underlying technology stack: Spark
Trigger type can be manual as well as automatic
Enable you to focus on building business logic and data transformation
Perform data cleaning, transformation and aggregation
Connects to data warehouses. Data lakes?
Yes, Support data to and from Redshift
Yes : Support  in and out from SQL DW
Transparent Pricing
Support SLAs
Ability for customers to add new data sources
Developers can write custom Scala or Python code and import custom libraries and Jar files into Glue ETL jobs to access data sources not natively supported by AWS Glue.

Differences between these two services
AWS Glue
Data Factory 
Main Focus of service
ETL, data catalog
Database replication
Full table; incremental via change data capture through AWS Database Migration Service (DMS)
Full table; incremental via custom SELECT query
SaaS sources
About 20, with several more in preview
Compliance, governance, and security certifications
Data sharing
Yes, within AWS
Vendor lock-in
AWS Glue is strongly tied to the AWS platform. Usage is billed monthly.
Month to month
Developer tools
Only python and Scala options are available.
REST API, .Net and Python SDKs, PowerShell CLI

Thanks for Reading .Your Suggestions and feedback's are welcome.

Friday, February 28, 2020

VMware vExpert 2020 Award Announced

I am very honored to be named a VMware vExpert again, this is my sixth time…..Congratulations to all those who made in the vExpert 2020 list.

VMware vExpert directory is available here.. https://vexpert.vmware.com/directory

And my vExpert profile can be found here.

Thank you VMware... :)