asked
Windows Azure Virtual Machine Sizes, temporary storage, and buffer pool extensions
Here's the scenario: * We're building Powershell scripts to automatically build Azure Virtual Machine server environments. Depending on the environment being built, we set up things like the machine name and instance size. * The instance size controls the type (and size) of temporary storage attached (very temporary - the D: drive on an Azure VM is physically located close to the VM host, and if your VM is rebooted, there's no guarantee that you'll get it back). Ideal territory for the TempDB, and, with new versions of SQL, Buffer Pool Extensions. * Except that enabling BPE is only recommended if you're running on an InstanceSize from the D series, as that's where the D: drive is on SSDs rather than HDDs. So, my question is... **How do we tell, from the VM side, what InstanceSize we're running**? Or whether we've got an SSD or an HDD? This would need to be done at boot time, to enable/disable BPE as appropriate, as the InstanceSize might change. So far, the only thing that looks promising is the PhysicalClusterSize - on the D series VM I've just spun up, that's different (4096) to those on the Basic & A series machines (512). But I can't find any documentation that points to this being the standard.
Not sure if this would be a good answer, but hope it's a great comment... Based on this post -
http://pipe2text.com/?page_id=2589 - you should be able to create a task scheduler task that runs at startup, connects to your Azure subscription and pulls the InstanceSize for your host using Get-AzureVM -name "your_host_name"
Azure Forum:
http://feedback.azure.com/forums/216843-virtual-machines/suggestions/6204911-provide-virtual-machine-instance-metadata-support I've voted it up. As have quite a few others...
Yeah, was wondering about that. But was hoping to have a more direct answer (ie one that doesn't involve going back into Azure)
I haven't been managing large scale automation like this. The person to ask is Joey D'Antoni. I know he's been neck deep in it.
@Grant - thanks. I'll hunt him down when I'm near a decent twitter client (blocked here at work...)
Metadata management is always a challenge in a fully automated environment like this. I think a step in the right direction might be to look at using PowerShell DSC for Azure. I can't think of a good way to get that information without going back into Azure however, particularly the instance size. There isn't a lot of internal metadata exposed that isn't through PowerShell. One other place I might investigate, is the telemetry data folder under C:\WindowsAzure--I haven't checked it, but I suspect they may be storing metadata in those files. If it's a pattern you can write some regular PowerShell to grab it.
Thanks for the input, @Joey - I'll check it out and let you know.
C:\WindowsAzure - doesn't look helpful. (Thought I would try the easiest option first!) There's a lot of interesting logging information there, but nothing with that level of detail.
Currently thinking about a solution involving a combination of Azure Automation and the CustomScriptExtension.
21 People are following this question.
