Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 











Freely subscribe to our NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Unsubscribe

Diskeeper Corporation: Why zero fragmentation matters on storage area network

January 2011 by Diskeeper Europe

A SAN affords the administration the ability to make remote disks appear to be local. It does not matter what protocol they use to connect: ISCSI, Fibre Channel, etc.

SAN storage units are referred to as LUNs. Originally the term LUN (Logical Unit Number) only meant the SCSI disk address on an array for a particular disk, but it is now commonly used to represent the physical disk array when it is implemented in a SAN as a logical volume(s).

Storage virtualization involves the creation of a usually very large, logical pool of data. Via software, that pool appears to be physically located all on one server. In actuality, that data may be located across hundreds of physical disks spread across dozens of servers. This is the concept implemented by Storage Area Networks.

This technology abstracts “logical storage” (the file system —what the operating system sees and uses) from physical storage devices and combines it into one large grouping on top of which a virtual storage container is created.
SAN file systems such as VMFS from VMware or EMC Celerra are known as shared-disk file systems and are the backbone of storage virtualization. An operating system defragmenter only recognizes the “local” disk file systems that it natively supports. Vendors of proprietary file systems typically include specialized technologies to optimize performance. These file systems are the foundation for storage virtualization.

Storage virtualization uses metadata to properly channel I/O. Software on a storage virtualization device (such as a SAN Switch) will translate logical disk locations to physical disk ones.

For example, a storage virtualization device gets a request for a logical location of LUN #1, LBA32. It then performs a metadata lookup for that address and finds it actually maps to LUN#4, LBA16. The device then redirects the request to the actual physical location of the data. Once it retrieves the data, it passes it back to the originator without the originating requestor ever knowing that the request was completed from a different location than what it knew.

The fact that there is not a one-to-one mapping of file system clusters to LBAs (due to LUN virtualization) is not an issue. Logical file system level fragmentation causes the operating system to generate additional I/O requests to the virtualization software. Using metadata, the SAN then redirects I/O from the logical disk to its physical location.

The local disk file system does not know of and cannot control the physical distribution or location in a virtualized storage environment and, as a result of fragmentation, NTFS has to make multiple requests regardless of the physical or virtualized storage environment.

In SAN file systems, block size (the smallest addressable virtual unit) is a configurable metric and varies based on the software used. VMware VMFS, for example, supports 1 MB to 8 MB blocks.

Logical Cluster Numbers (LCNs) are a file system construct used to map a file on a volume to LBAs. Disk controllers take those logical blocks and make the appropriate translation to a physical location. Disk controllers do not, no matter how “smart” they are, independently map fragmented file I/O into consecutive
or linear block requests. They cannot “pool” incoming block-based data back into a file.

SANs can offer extremely efficient and high-performing data storage, but it is not the job of a SAN system to address file system level fragmentation. Proprietary technologies employed by one vendor can be more efficient at retrieving data blocks than another. Architectures can vary as well. No matter how efficient data retrieval can be, and how much physical disk limitations can be mitigated, the overhead on the operating system is impacted by fragmentation and beyond the scope of SAN technology. Local disk file defragmentation is still necessary.

In cases where multiple operating systems (multi-headed) connect to common shared disks, as in a SAN, I/O throttling techniques will not function appropriately. The case being that an application using I/O throttling may detect that a shared disk array is not busy, but a secondary server also using that same array may be processing a very disk-intensive operation. In that event disk contention may occur.

Only Diskeeper 2010 provides file system drivers that prevent most fragmentation at the source (the file system) with a file write. This is an excellent solution in a SAN environment as it lowers the added overhead spent in after-the-fact removal of fragmentation.

Proprietary technologies such as InvisiTasking® technology, which eliminates defragmentation overhead on direct attached storage, will provide more effective resource-sensitivity for storage networks through granularity of its actions. With the possibility of overhead conflict in more I/O-demanding SANs, it is still recommended to undertake a proper evaluation of the environment to determine if defragmentation time frames are better suited to off-peak production hours.


See previous articles

    

See next articles












Your podcast Here

New, you can have your Podcast here. Contact us for more information ask:
Marc Brami
Phone: +33 1 40 92 05 55
Mail: ipsimp@free.fr

All new podcasts