Azure Managed Shared Disk

 Managed Share Disk in Azure

Azure shared disks is a new feature for Azure managed disks that allows you to attach a managed disk to multiple virtual machines (VMs) simultaneously. Attaching a managed disk to multiple VMs allows you to either deploy new or migrate existing clustered applications to Azure

Absence of shared disks was one of the limitation in Azure for those who wish to migrate their clustered compute resources into Azure. Ex: SQL Always on availability group with failover cluster.

The alternative option was create Azure Files and mount it into multiple virtual machines which provides a "shared file system" for the applications however it is suitable for the clustered environment.

Thanks to Azure team for bringing this new feature which will be helpful for those who wish to lift and shift the clustered environments into Azure compute.

The concept of Azure shared disk is similar to accessing storage blocks/volume via ISCSI as a LUN created in the SAN storage. SCSI PR(Persistent reservation) is an industry standard leveraged by applications running on Storage Area Network (SAN) on-premises.

Azure shared disk is now generally available in all regions however with some limitations; hopefully these limitations will be overcome in near future.

I will take you through step by step install and configure of Azure disk in brief, here we go.

Azure Shared Disk

Create a shared disk

Login to the Azure portal --> Type search in the Disks --> Click on Add Disk

Input the disk name and relevant information --> Change disk size

Only Premium SSD and Ultra SSD disks from 256 GB size supports disk sharing, choose the appropraite disk based on the requirement. Here i'm going to select 256 GB disk which is having share capacity of 2 ie, can be added into virtual machine, suitable for 2 node clusters.

I'm leaving all other settings to default.

On Advanced tab click on "Enable Shared disk" yes check box and select the number of shares, here the maximum is 2 so keeping the default value. If you have choose a shared disk with 5 shares; max shares can be opt from this window.

Validate and create the shared disk

Create 2 Virtual Machines

Create 2 virtual machines based on your flavour to test the shared disk attachment, here I've created 2 windows server 2016 VM's to build 2 node windows failover cluster.

Virtual Machine 1 - fsclusternode01

Virtual Machine 2 - fsclusternode02

Attach Shared Disk

Shared disk cannot be attached to the 2 virtual machines when it is turned on, so stop the virtual machines before attaching the shared disk.

 

Navigate to virtual machines --> Disks --> click on "attach existing disks" from under Data disks menu

Select the shared disk which we have created from the drop down menu and change the host cache to read/write, then  save .

Perform the same on the 2nd virtual machine "fsclusternode02"

Start the virtual machines one by one; note that better avoid starting both virtual machines at same time instead start it one by one.

LLogin to each virtual machine and verify that the shared disk is attached successfully, open disk management (run --> diskmgmt.msc) to verify the disk status.

Install and configure windows failover cluster on VM's

Install windows server failover cluster feature into the virtual machines.

Once the feature is ready open failover cluster manager and create a cluster without adding disks

Refer the article below if you are not familiar with WSFC.

https://docs.microsoft.com/en-us/windows-server/failover-clustering/create-failover-cluster

Go back to the disk management and initialise the shared disk and bring it online, then create a new simple volume.

Volume creation is need to be performed only on one of the virtual machine/node in the cluster.

Add the disk into failover cluster 

Open failover cluster manager on the node where the volume is created --> failover cluster name --> storage --> disks --. add disk --> select the shared disk from the list.

Now login to the 2nd virtual machine/node --> open failover cluster manager --> cluster name --> storage --> disks

You could see the shared volume is added into the cluster disks

In-order to use the disk as a shared one, convert it into cluster shared volume (CSVFS)

On failover cluster manager window --> storage --> disks --> Add to cluster shared volume from the right side menu pane

Now the attached disk is added into failover cluster and converted into cluster volume. it is ready to use.

To test the shared volume, login to the 1st virtual machine "fsclusternode01"  --> open file explorer --> navigate to C:\Windows\ClusterStorage\volume1 and create a folder and file

Now login to the another node/VM and check the same folder & file exists under  C:\Windows\ClusterStorage\volume1.

If You check the properties of shared disk from Disks --> your shared disk name --> overview

I've also tried to create snapshot of shared disk and created a new disk from it, so the shared disk in  can be administer in the same way as normal managed disk in azure with a additional feature of sharing.

Size and performance of the shared disk can be expanded but you need to stop the virtual machine before making the change.

Supported use cases of Azure shared disk

Some popular applications running on WSFC include:

• Create an FCI with Azure shared disks (SQL Server on Azure VMs)
• Scale-out File Server (SoFS) [template] (https://aka.ms/azure-shared-disk-sofs-template)
• SAP ASCS/SCS [template] (https://aka.ms/azure-shared-disk-sapacs-template)
• File Server for General Use (IW workload)
• Remote Desktop Server User Profile Disk (RDS UPD)

Linux

Azure shared disks are supported on:

• SUSE SLE for SAP and SUSE SLE HA 15 SP1 and above
• Ubuntu 18.04 and above
• RHEL developer preview on any RHEL 8 version
• Oracle Enterprise Linux

If you would like to explore more feel free to have a look into the below Microsoft documentation.

https://docs.microsoft.com/en-us/azure/virtual-machines/disks-shared

Thanks for reading and hope this helps.

Happy to help 😊 if you have any queries, feel free to put your queries into the comment box

Azure Files Identity based authentication - Azure Active Directory Domain Services

Azure Files Identity based authentication -Active Directory Domain Services (AAD DS)

Azure Active Directory Domain Services (AAD DS) is Microsoft's 'managed domain' service in Cloud.

Its is a full featured active directory domain services that support Kerberos based authentication which is similar to the AD that is available in on-premises.

Here Microsoft Azure will take care of all the management overhead of active directory domain including patching of domain controllers, replications between domain controllers and availability etc..

That means you wouldn't be using the repadmin or dcdiag commands anymore.

Coming to Azure Files it supports the integration with Azure active directory domain services if there isn't an onprem directory exist.

In this article we will briefly go through the steps to be followed for the integration of Azure Files with AAD DS identity based authentication and this article is not intended to cover the setup of AAD DS.

Steps to configure AAD DS based authentication on Azure storage is similar to ADDS which is explained in the previous blog

https://sjohnonline.blogspot.com/2021/02/azure-files-identity-based.html

Prerequisites

Select or create an Azure AD tenant.

Enable Azure AD Domain Services on the Azure AD tenant.

Domain-join an Azure VM with Azure AD DS.

Select or create an Azure file share.

Verify Azure Files connectivity by mounting Azure file shares using your storage account key.

Part one: enable AD DS authentication on your storage account

Once the AAD DS setup completed, enable AAD DS authentication in Azure storage account - storage account --> Configurations --> you would be able to enable Azure Active Directory Domain Services

Part two: assign access permissions for a share to the Azure AD identity (a user, group, or service principal) that is in sync with the target AD identity

·         Storage File Data SMB Share Reader allows read access in Azure Storage file shares over SMB.

·         Storage File Data SMB Share Contributor allows read, write, and delete access in Azure Storage file shares over SMB.

·         Storage File Data SMB Share Elevated Contributor allows read, write, delete and modify NTFS permissions in Azure Storage file shares over SMB.

Part three: configure Windows ACLs over SMB for directories and files

Administrator with full access to the share can mount the share into a domain joined computer and set necessary NTFS permissions using the following.

Configure Windows ACLs with Windows File Explorer or icals

Ex: icacls <mounted-drive-letter>: /grant <user-email>:(f)

The following permissions are included on the root directory of a file share:

·         BUILTIN\Administrators:(OI)(CI)(F)

·         BUILTIN\Users:(RX)

·         BUILTIN\Users:(OI)(CI)(IO)(GR,GE)

·         NT AUTHORITY\Authenticated Users:(OI)(CI)(M)

·         NT AUTHORITY\SYSTEM:(OI)(CI)(F)

·         NT AUTHORITY\SYSTEM:(F)

·         CREATOR OWNER:(OI)(CI)(IO)(F)

Note: Port 445 should be allowed in nsg/firewall rules

Similarly if you want to give read access to a group/users into Azure File Share assign them with the below role

• Storage File Data SMB Share Reader allows read access in Azure Storage file shares over SMB.

Administrator can then configure NTFS permissions on the Mounted Share

Part four: mount an Azure file share to a VM joined to your AD DS

https://docs.microsoft.com/en-gb/azure/storage/files/storage-files-identity-ad-ds-mount-file-share

Login as the user with at least read permission to the share












User can access the share by calling the share UNC path from run command box without entering the password.

User can also access the share by calling the share UNC path from file explorer without entering the password.

Most convenient way is to MAP the share as a drive into the file explorer as shown below.

















Note: Ultimate access to the Shares will be based on the permissions applied from Azure file share IAM and more granular control applied on the windows ACL/ NTFS Permission to the subfolders and directories.