Azure Deployment Experience - Series 2 (NTFS vs ReFS) - Beware of failures in ReFS

After provisioning the Disks for VM, we normally tend to 'Allocate' space and create Logical Drives inside the VM.

ReFS seem to be a good bet in terms of being the latest and having the feature of auto-correcting in case of any failures. NTFS has been there for quite some years and ReFS is touted as next best technology for file storage & access.

It so happened that, one of the ReFS drives in one of our VMs got corrupted somehow and we could not recover the contents. Ten days effort of deploying an application for a demo, went for a complete mess. In NTFS, there is a mechanism to run CHKDSK and possibly recover the bad sectors. But in ReFS, running it is of no impact, as the system internally tries to do it by itself.

Finally, we had to recreate everything and from this incident onward, I started choosing NTFS for all drives that I create.

There is a way we could have possibly recovered the data had we taken a backup of either the content or the drive itself to a Storage Account. But being (a) new to Azure, (b) not knowing internals of how technology works, (c) when you are the sole person doing everything, (d) demo set up in a short time and (e) especially when we do these in small / start-up work places, these kind of processes may not be practically executed. 

So, if you choose ReFS, go ahead, but make sure you backup the contents as per the changes made. Else, choose NTFS. In either case, taking backup is a good practice. NTFS has ChkDsk way of possible recovery while ReFS does not seem to be proved (as in our case).

Azure Deployment Experience - Series 1 (VMs with MS-SQL)

There are a lot of videos and tutorials on Azure VMs with SQL and its deployment. I am not going to get into any of the existing content. 

The content is more about the high-level practical approaches if we were to go for Azure VMs which has to support Microsoft SQL. This is based on my current experience in deploying our solutions in Azure.

• First, if there is an Enterprise Agreement, there shall be a Pricing Sheet that will help you to know how much a VM would cost; remember that the cost will vary according to the configuration of VM along with the Edition of SQL.
• If you want a 'Test' or 'Development' server, create a minimal VM (say 2 core, 3.5 GB RAM or 4 Core,7GB RAM) and download SQL Express. SQL Express 2012 can support up to 10 GB Database size and you can have multiple databases and Express 2012 can support up to 4 Cores. 
• If not Production server, but require a server for replicating the Production, go for SQL Web Edition which costs much less compared to Standard / Enterprise.
• For Production, SQL Standard is recommended and a better choice as it will be required to configure Backups, Maintenance Jobs.
• Go for Enterprise, if we really require Always-On, Inline Memory Processing, Partition kind of features. The cost of Enterprise is nearly 4 times that of Standard.

I have not experimented with Azure SQL DB, as its a shared chunk from a bigger SQL but its not a dedicated SQL Instance except for the assured DTUs.

Importantly, create the VMs using the new portal and as part of ARM, so that all latest features of new portal are available to work with. It is not possible to migrate a VM from Classic to ARM at this point of time, without a down time.