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

MCSIO in Azure7.png

Step 2: Choose virtual machine type D2S_V2.

MCSIO in Azure8a

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

MCSIO in Azure6.png

  • 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

MCSIO in Azure8.png

  • 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

MCSIO in Azure4

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

MCSIO in Azure9

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

MCSIO in Azure10

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

MCSIO in Azure11

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

MCSIO in Azure12

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

MCSIO in Azure13

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

MCSIO in Azure14

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

MCSIO in Azure15

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.

MCSIO in Azure16

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

MCSIO in Azure17

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

MCSIO in Azure18

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

MCSIO in Azure19

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

MCSIO in Azure20

 

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)

MCSIO in Azure3.png

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

MCSIO in Azure6.png

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

MCSIO in Azure23.png

 MCSIO in Azure24.png

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

MCSIO in Azure24.png

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

MCSIO in Azure25.png

  • 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.

MCSIO in Azure22.png

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:-

MCSIO in Azure26.png

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)

MCSIO in Azure27.png

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

MCSIO in Azure6.png

Reviewing Device management you’ll see 3 disk listed.

MCSIO in Azure28.png

  • 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.

MCSIO in Azure29.png

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

 

 

2 comments

  1. Great article! quick question…..when you are not using MCSIO why is there not a differencing disk? or is the temp disk used for that?

Leave a Reply