Non Georedundant blobs best practice


  • Hi, I have been setting up several new VMs and hitting them with SQLIO. According to my tests, it is absolutely the case that EVERY data drive should be implemented as a minimum stripe of 3 blobs. In my tests with 64KB allocation units and 64 KB reads and writes:

    single blob: Write IO 240 Read IO 426

    3X stripe: Write IO 1413 Read IO 1501

    Really, my thinking about this is that Azure ought to come with a big warning: IO will suck unless you stripe. Instead I had to tease this out of a variety of blogs, docs and experimentation. Did I say that strongly enough? The IO _sucks_ when the 7 year old Dell Poweredge in my hosting center can beat it.

    So this will just be standard practice at this office. To the extent you can have the extra blobs (A3 size and above) use 'em. 

    Following best practice to implement this, I created a new storage container that is not georedundant.  Now I have read that you don't want to mix geo redundant and non blobs on the same machine. Does this include the OS drive? In which case should I be moving these over to the non-geo storage container. Really, if so, the practical implication is that NONE of my blobs should have ever been made in a georedundant container. I haven't seen that big warning yet either.

    What do you folks think?

    Friday, August 08, 2014 12:24 AM

All replies

  • I wanted to create a stripe of 6 100GB disks to have one fast 600GB data disk. Not so much space really! I already had 3 disks. Really 2, as one is consisting of two blobs. I found that I could not do this without going A6 to A7 in size. I do not need the memory, I do not need the CPU. The only thing I need is the ability to create more than 8 blobs. This ws going to cost something like $500 extra per month. I find that a bit in the extreme.
    Friday, August 08, 2014 12:57 AM
  • I don't know the answer. But I would like to know, as it has implications for our storage containers.

    OS disk not in the same container as data disks, and mismatch on the redundancy setting.

    Would appreciate Microsoft views... I guess I can open a case.

    Tuesday, August 12, 2014 10:50 PM