Lun Misalignment
I am interested writing something about misalignment even
though its old concept, but understanding misalignment will give a clear idea about basic
storage architecture and iop's operations.
Now a days most of the traditional infrastructure was migrated
to virtualized platform which seems more flexible but misalignment triggered
when we convert old platform with new, let me continue briefly :)
What is Misalignment:
By default, many guest OSs, including most versions of
Windows, attempt to align the first sector on a full track boundary. The
installer/setup routine requests the cylinder/Head/Sector (CHS) information
that describes the disk from the BIOS (PC firmware that manages disk I/O at a
low level), or, in the case of many VMs, an emulated BIOS. The issue is that
the CHS data hasn't actually corresponded to anything physical, even in
physical machines, since the late 1980s. At larger LUN sizes, usually 8GB or
more, the sectors per track (S number) is always reported as 63, so the
partitioning routine sets a starting offset of 63 sectors in an attempt to
start the partition on a track boundary.
While this may be correct for a single physical disk drive,
it does not line up with any storage vendor's logical block size. A block is
the smallest unit of data that can be used to store an object on a storage
device. In order to make sure of optimal storage capacity and performance, data
should reside in the blocks. Physical disk blocks always have 512
(usable/visible) bytes, but for efficiency and scalability reasons, storage
devices use a logical block size that is some number of physical blocks,
usually a power of 2. For example, NetApp Unified Storage Architecture arrays
have a logical block size of 4K, that is, 8 disk blocks. EMC Symmetrix storage
arrays have a logical block size of 64KB.
Let’s see an example here
so if an operating system is using 4KB (LBS) block size then how many physical blocks?
8 physical blocks required to place a single logical block(i.e:4KB).
Write operations can consume no less than a single 4KB block
and can consume many 4KB blocks depending on the size of the write operation.
Ideally, the guest/child OS should align its file system(s) such that writes
are aligned to the storage device's logical blocks. The problem of unaligned
LUN I/O occurs when the partitioning scheme used by the host OS
doesn't match the block boundaries inside the LUN.
If the guest file system is not aligned, it might become necessary to read or write twice as many blocks of storage than the guest actually requested because any guest file system block actually occupies at least two partial storage blocks.
By default, many guest operating systems, including Windows 2000, Windows 2003, and various Linux distributions, start the first primary partition at sector (logical block) 63. The reasons for this are historically tied to disk geometry. This behavior leads to misaligned file systems because the partition does not begin at a sector that is a multiple of 8.
Note that Windows Server 2008 and Windows Vista® default at 1,048,576, which is divisible by 4,096, and do not require any adjustments. Also, RHEL 6 does not require any adjustments because it aligns its partitions properly by default.
Impact of misalignment:
Figure blow an example of a LUN with and without file system alignment. In the first instance, the LUN with aligned file systems uses four 4KB blocks on the LUN to store four 4KB blocks of data generated by a host. In the second scenario, where there is misalignment, the NetApp storage controller must use five blocks to store the same 16KB of data. This is an inefficient use of space, and performance suffers when the storage array must process five blocks to read or write what should be only four blocks of data. This results in inefficient I/O, because the storage array is doing more work than is actually requested.
File system misalignment is a known issue in virtual environments and can cause VM performance issues. Please follow the below links which will help you to fix the misalignment.
The Challenge with Re-Aligning:
Strictly downtime required..!! Also performing alignment on the disk/partition which is holding data should be taken proper consideration to revert back if something went wrong because i still remember when we performing alignment on a windows VM server the disk-geometry got corrupted, although we reverted back by the recent backup which was taken before alignment process.
Best Practices:
"Alignment is mean to be the disk/partition alignment not the data alignment" so it's better to take proper action while creating the fresh partition and need to be corrected on that time only.
In vmware environment "vmware converter" is the best tool to perform the alignment where physical servers can be aligned by P2V and virtual machines can be aligned by V2V.
Creating a template with proper alignment partitions and deploying the vm's would be the best idea and this should be followed by whoever does the deployment which will highly reduces unknown performance issues later when the virtual machines grows.
Comments
Post a Comment