VSC 4.0 - Optimization and Migration - No optimized datastore

[pedro_rocha]

Hello,

We are starting to use the optimization and migration funcionality in VSC 4.0. After provisioning one datastore via VSC, I moved one VM to this new datastore and started to scan it.

The scan has ended and the VM was put on the actually aligned group. Ok, very nice.

On the scan manager, where I have the list of datastores, that new datastore with the actually aligned VM is listed as NO optimized. Why is that (no optimized)? How does it work?

DOT is 8.0.2P6, VSC 4.0, ESXi 5.0

Regards,

Pedro Rocha.

[sharmas]

Hi Pedro,

Optimized datastores are the ones created with an offset to align the IO to the misaligned VMs inside it. So it is normal if you have a datastore marked 'No' under optimized that has been created by you through Create Datastore functionality.

After you detect misaligned VM and decide to migrate it using Optimization and MIgration, it will create a new datastore (mark it optimized) with appropriate offset to ensure the IO is aligned. If it finds an existing datastore with the appropriate offset it will move the VM to this datastore instead of creating a new one.

Remember, you should not move aligned VMs to Optimized datastores as it results in the IO becoming unaligned.

Hope this helps.

Regards

Satinder

[pedro_rocha]

Hi,

This is a bit confusing. When I provision a datastore through vsc, is it ok that the resulting datastore is one of those not optimized?

Moreover I thought that datastores created within vsc would always be aligned, is it true?

Regards,

Pedro Rocha.

Enviado pelo meu aparelho BlackBerry® da Vivo

[borkp]

Hi Pedro,

     It's not so much that the datastore is "aligned", but it's more accurate to say that the guests are aligned with the datastore.  Typically there are 2 options:

1. Create a datastore in a LUN that is offset to correct guest misalignment

     or

2. Create a standard datastore (with no offset) and correct guest misalignment.

So the real question is - are the guests aligned, or no?  If guest parition alignements agree with 4k alignments, then a typical datastore will be just fine.  for many Windows 2003/Linux guests, the default alignment is 63 sector/32,256k offsets (unless administrators have taken special precautions to deal with those guest with regards to alignment). 

For Win2k8, guests come pre-aligned to suppuort standard datastoers (not optimized).  What are you dealign with?

Regards,

Pihl

[pedro_rocha]

Hello,

I thought that there was 2 levels of alignment. On the datastore level,

between VMFS and storage (which I read once is automatic when creating LUNs

on NetApp specifying the vmware type). And on the guest level between guest

file systems and datastores. Is that incorrect?

On the environment I am dealing with, all the VMs appeared in the

Functionally Aligned group within the optimization tab on VSC. But I have

no optimized datastore. I am trying to understand in which situations those

optimized datastores would appear.

Best wishes and thank you for all the information,

Pedro Rocha.

On Tue, Jun 26, 2012 at 1:35 AM, borkp <

[borkp]

Actually, you are correct.  The VMFS file system should align with block 0, similar to Linux and Windows_2008 LUNs.  In addition to aligning VMFS datastore with NetApp, the guests have to be aligned also.  As you can imagine, if a guest is not aligned, but it IS in an aligned datastore, I/O will still be misaligned. 

I'm not sure with the VSC piece though.  Sorry abou that.  But you are correct with VMFS and guest alignment.  Do you know if the guests are aligned?  What O/S are they?

Regards,

Phil

[pedro_rocha]

Hi Phil,

Yes the guests are aligned, they are windows 2008. I just don't understand

why my datastore is NO optimized.

Best wishes,

Pedro.

On Tue, Jun 26, 2012 at 1:18 PM, borkp <

[WillFulmer]

Based on Nick Howell's (NetApp) post on another blog which details this perfectly

http://theithollow.com/2012/04/10/netapp-vsc4-optimization-and-migration/

<QUOTE>

Essentially what we’re doing is lying to vSphere, and creating what we like to call a “shim” datastore that is intentionally offset. This way, you just svMotion any misaligned VM’s into this datastore, and the misaligned I/O all of a sudden becomes an aligned I/O stream. Pretty slick if you think about it.

This is to be considered a short-term solution for a much longer “Actually aligned” strategy. Let me be perfectly clear about that. Your VM’s are still misaligned! We’re just aligning the I/O stream under the covers in an online fashion, in order to ease the performance pains of VM’s being misaligned.

Please, still schedule some time to align your VM’s offline with MBRalign, and then move them out of these Functionally Aligned datastores.

</QUOTE>

[justin_smith]

I have roughly 900 VMDK's that are misaligned.

Of the 900, I'd say 600 of them are offset by 32KB (which is misaligned) and another 100 are offset by16964640KB and a handful of 12289725KB. Dont ask my HOW we got so many, or why certain ones are off set differently

My question is this:

If I create an optimized LUN, I didnt think VSC gave me the option to specify the offset, in which case, it wont work on 200-300 of my VMDK's. If I create a NEW satastore within VSC does the NetApp offset it based on the offset of the VMDK?

If thats the case, I would have to have multiple datastores that are offset differently....

[keitha]

Go into the Optimization and Migration section of the VSC. In here it will detect those offsets and then guide you through building LUNs with the correct offset (then even VMotion the VMs into the LUN for you)

Keith

[justin_smith]

Right, but Im still concerned on the different offsets of each VMDK.... if one VMDK is offset by 32KB, and one by 64KB per say, will moving both the VMDK's to the SAME "optimized" datastore fix BOTH VMDK's? Or will I need 2 separate LUNS for the different offset values?

[MRJORDANG]

My understanding is that each datastore is offset specific.  That is, you will need a datastore for VM's with a 32K offset and another datastore for those with a 64K offset.

[borkp]

This is what the VSC can do:

At your direction, it will scan all guests.  For guests that have a detectable MBR (basic partitions, boot partitions, etc), VSC will inventory and note the starting offset of each disk.  For guests with all common offsets (63 sector / 32,256kb), (0k / 64k / 1M) it will indicate that those guests can be grouped.  VSC will walk you through provisioning a datastore.  Note - you must have a volume created first to host the new datastore LUN.  For guests that either cannot be detected (Windows guests with dynamic disks, linux disks managed by the LVM) or guests that need special need special attention (a guest with 2 VMDKs with different offsets), it will flag those separately as well for you to take a further look.

To answer your question, once a datastore is provisioned (either with a 0 offset, 63 secotr compensator (-P 3584), only guests with that same common offset should be put in those datastores.  Once you do that, you will have "functional alignment", which means that I/O will be aligned to NetApp's 4k block boundaries.

For performance, "funcationally aligned" guests and aligned, when placed in proper datastores, should be equal.  For flexability, it is probably a good idea to correct guest alignment and move it to a vmware type datastore.

[justin_smith]

Maybe Im missing something, but VSC doesnt list out the offsets of the actual VM's/VMDK's. There are Misaligned > Online Migration > Group 1, 2, etc... but nothing that tells me the offset. With that being said, how am I supposed to figure out the offset for the VMDK's?

I also noticed it has some datastores under Actually aligned, and Offline Alignment... can you explain a little more what the actual DS's being there means?

[keitha]

Hey Justin...Almost there... We divided a 4K block in 8 512 byte "buckets" so Group 1 VMs are offset by 512 bytes, Group 2 offset by 1024 bytes... ect...

So if you use VSC to build a LUN for the Group1 VMs then it will offset a LUN by 512 Byes and moves all the group 1 VMs into it.

If a VM is a a group them it has a single VMDK and can be moved into an Optimized Datastore via VMotion, no downtime. If however it has multiple VMDKs with different offsets or a VMDK with multiple partitions with different offsets then Optimized LUNS will not help you and you have to do an offline alignment using VMware Convertor, MBRAlign or something similar...

Keith

[justin_smith]

Making sense now, is there anything documented that states what groups are for what offsets?

Also, if the VM has multiple VMDK's and more than one are offset by ANY number, then they will have to manually be aligned with VMConverter or MBRAlign, etc? And cant take advantage of the VSC?

[keitha]

Yes to an extent;

     1. If you have multiple VMDKs and they are all offset by the same amount then VSC will migrate the VM for you

     2. If you have multiple VMDKs with different offsets then you can manually move the VMDKs into the correct datastores created by VSC

     3. If you have any VMDKs with Multiple PARTITIONS within a single VMDK that have different offset then you cannot use Optimized LUNs and have to align the VMDK offline with another tool (recommend VMware Convertor)

[justin_smith]

Good info to know.

If I expand the folders (Aligned > Actually Aligned) I see actual datastores under here.... what is the purpose of this? I can drill into that DS and see the VM's on it... but why are they there?

[keitha]

Two reasons actually. First it's just good to know which VMs are aligned properly and as such can move around without any concern for what datastore they go in (except of course for one of the Optimized datastores which would be bad)

Second, this is a very cool and less known feature of VSC. You can select all those VMs and move them somewhere. For example say you were new to NetApp and wanted to move from your old storage to your shiny new NetApp. You could select the VMs in here en mass and migrate them to a different datastore. Say, Non NetApp to NetApp. The VSC would then move those VMs using storage VMotion 4 at a time to the target datstore and you can go have a beer/coffee/water and watch them move... Pretty cool eh?

[justin_smith]

Can you tell me what Offset 1, 2, 4, 5, 6, 7 are and the differences?

[keitha]

OK, imagine you divide a single 4K block into 8 512 Byte buckets. Bucket 0 starts at the start of the 4K block, Bucket 1 starts 512 bytes in bucket 2 starts 1024 bytes in.... and so on.

Now a misaligned VMDK means that it's NTFS/EXT file system has a funny offset such that it's 4K blocks don't align with the NetApps 4K block right. Say for example there was 512 bytes infront of the first NTFS block on a guest Windows VM. That would mean that when the guest VM wrote to a NTFS block it would really write starting 512 bytes in on the NetApp block (and 512 bytes on the next block over). Thus the VM would have a 512 byte offset and be considered an Offset of 1.

Most windows 2003 VMs have an offset of 7 by default. That means they are 7/8th of a block off (7X512 bytes off).

VSC creates a LUN that is Bumped over just the right amount to make sure the guest file system lines up correctly. As you can see though you need a LUN for each offset.

How many offsets do you have?