Machine Creation Services & Azure -Understanding the configuration/disks and costs involved!

During recent work with the cost calculator covered in this article Deep dive into Citrix Cost Calculator for Azure i wanted to understand all possible azure costs incurred (of which the below appears not to be included).

The following article will cover the MCS (Machine Creation Services) provisioning impact to the number of disks/size & cost depending on selection made during the machine catalog provisioning process.

Initial Image Creation

Step 1: I deployed a new [smalldisk] Windows Server 2016 data centre VM

Step 2: Choose virtual machine type D2S_V2.

Step 3: Logging into OS, you get two disk listed Local Disk & Temporary Storage

• C (Local Disk) Drive is the allocated Azure storage for Operating System (i deployed a smaller disk as per above choice)
• OS Drive is storage in Storage Account this is chargeable
  • Standard – charged per utilisation of disk (15.7GB used), charge will increase if disk is more utilised so needs to be taken into account from costing point of view
  • Premium – charged for all 30GB
• D (Temporary Storage) is the storage allocated/list in VM type – this is non-persistent storage (see image below

• D Drive/Temporary storage is included in the compute cost, there is no additional cost per GB needs to be factored into any costs for this.

Step 4: Review the Azure portal VM/Disk to the LABCTXIMAGE it confirms that OS disk is listed

Step 5: I installed VDA Agent 7.15 & appropriate software or the image in preparation for image to be used as the Master Image needed in the next section. VM was then Shutdown.

Deploying Image (using MCSIO Write Cache)

Step 1:  Launching Citrix Studio> Machine Catalog >Create new Machine Catalog.  Click Next at introduction

Step 2:  Choose Server OS (as we deployed Server 2016 before for labctximage), Click Next

Step 3:  Select Deploy using Citrix Machine Creation Services, choose WILKYTIT RGROUP (which is an existing Azure Resource Group setup already), Click Next

Step 4:  Choose the labctximage… created in previous section, Click Next

Step 5: Click Close to confirm VM is not running.

Step 6: At storage and license type, i have chosen “Standard Storage” and No to “Hybrid Use Benefits” , Click Next

Step 7: I have chosen “Standard_D2s_v3“, Click Next

Step 8: At write back cache, the following options are available and needs to be considered.

• Memory allocated to cache (MB)
  • Defaults to suitable memory but can be adjusted. Ensure your azure VM is adequately sized to include this memory overhead. Minimum is 256MB. Once this cache in memory has been exceeded it will then write to disk cache.
• Disk cache size (GB)
  • Defaults to size of OS which is 127GB even though we have chosen a small disk (maybe something in config of smaller disk that still refers to 127GB). Considered how much machine write cache would be generated for image and need need some level of adjustment before going into production and committing the storage.

Step 9: A warning about the disk cache lower than the default 127GB appear (setting to 128GB will prevent the warning, Click Yes to continue

Step 10: At Network Interface cards, Select “0”(this is specific to my setup). Click Next

Step 11: At Active Directory computer accounts, Select “Create new Active Directory accounts“, Choose OU Location and account naming scheme. Click Next

Step 12: Enter Name machine catalog & description & Click Finish

 

The new azure VM provisioned by MCS will be created. During this process 3 disks will be created with temporary names until provisioning process is complete.(See below)

After logging into new VM, you’ll not see anymore additional disks that was previously seen on the LABCTXIMAGE VM.

Reviewing Device management you’ll see unallocated disk (of the size created in Step 8) and it will ask to be initialised

 

**IT IS IMPORTANT YOU DO NOT INITIALISE THE DISK AND IGNORE THIS MESSAGE**

The rest of the disk can be seen after ignoring the initialise disk size.

• Disk 0 – OS
• Disk 1 – Temporary Storage
• Disk 2 -Identity Disk
• Disk 3 – Writeback Cache

In Azure Portal > Virtual Machine > Settings > Disks you’ll see the disk allocated here.

Writeback Cache cannot be placed in the temporary storage that Azure VM creats which would seem a great idea due to it being non-persistent much like the write cache itself.

This appears to be limitation citrix has placed on write back cache where it needs to create the disk. This could possibly be a future enhancement but there could also be a good reason for it being this way (i have discussed with citrix and requested further feedback on this matter).

Deploying Image (using MCS without write back cache)

Repeating the same steps in previous section with the exception of Step 8, which should be altered to the below:-

The new azure VM provisioned by MCS will be created. During this process 2 disks will be created with temporary names until provisioning process is complete (see bellow)

After logging into new VM, you’ll not see anymore additional disks that was previously seen on the LABCTXIMAGE VM.

Reviewing Device management you’ll see 3 disk listed.

• Disk 0 – OS
• Disk 1 – Temporary Storage
• Disk 2 – Identity Disk

In Azure Portal > Virtual Machine > Settings > Disks you’ll see the disk allocated here.

Cost Impact

Deploying using MCS Storage Optimisation (MCSIO) will have an impact to storage accounts sizing/limits and costs associated with VM’s provisioned in this method. The following is the chargeable disk assigned to the VM for this configuration:

• OS Disk Utilisation/Size- 127GB 
• Identity Disk – 16MB
• Write Back Cache – 127GB

Using standard storage and assume 60% usage of OS & 20GB Write back cache the below costing calculation is used:-

76.2 (60%) + 20 MB (identity Disk)+ 20GB (example write back cache size)

£0.046954467 * 72.6GB = £3.4088943042 + £0.046954467 * 20MB = £ 0.00093908934 + £0.046954467 * 20GB = £0.93908934

Total cost per month  = £4.34892273354

NOTE: Storage Access has to be included in the above per month cost. Identity disk charging for Premium needs to be validated as there is no smaller disk that 128GB

If Premium storage is used then the price increases as all allocated storage is charged as showing in the costing calculation below:-

P10 – 128GB = £17.78 + £0.002778125 + P10 – 128GB =£17.78

Total cost per month  = £35.562778125

NOTE: There is no storage access charge for Premium storage.Identity disk charging for Premium needs to be validated as there is no smaller disk that 128GB

Deploying using MCS Traditional (Pre-version 7.9 release) will have an impact to storage accounts sizing and costs associated with VM’s provisioned in this method. The following is the chargeable disk assigned to the VM for this configuration:

The following is the chargeable disk assigned to the VM for this configuration:

• OS Disk Utilisation/Size- 127GB
• Identity Disk – 16MB

Using standard storage and assume 60% usage of OS

£0.046954467 * 72.6GB = £3.4088943042 + £0.046954467 * 20MB = £ 0.00093908934

Total cost per month  = £3.40983339354

NOTE: Storage Access has to be included in the above per month cost. Identity disk charging for Premium needs to be validated as there is no smaller disk that 128GB

If Premium storage is used then the price increases as all allocated storage is charged as showing in the costing calculation below:-

P10 – 128GB = £17.78 + £0.002778125

Total cost per month  = £17.782778125

NOTE: There is no storage access charge for Premium storage.Identity disk charging for Premium needs to be validated as there is no smaller disk that 128GB

Conclusion

With the Performance enhancement given by MCSIO around IOPS reductions the cost appears to be the major factor in any decision. Here are a few things to consider when deciding on using Traditional MCS vs MCSIO

• Will provisioning using MCSIO help meet number of users to be achieved per VM (task, knowledge worker & heavy user etc)
• Will the cost for provisioning the additional write back cache reduce the overall VM’s needed to meet the user volumes and be cost neutral (or near it)

If any of the above are NO, then using traditional MCS provisioning will be your best and most cost effective way to proceed.

Other references/information is available on MCS Storage optimisation.

Introducing MCS Storage Optimization