Today we are very excited to announce the release of V-locity 4 VM Accelerator. With this latest release, V-locity increases VM and application performance by up to 50% and does so without any additional storage hardware.

Let’s face it - in today’s world of virtual environments, we generate a tremendous amount of data and it’s only the beginning. In fact, findings included in a recent study by IDC titled “Extracting Value from Chaos” predict that in the next ten years we will create 50 times more information and 75 times more files.

The impact of this data explosion on server virtualization can often lead to I/O bottlenecks. This is because a physical server running multiple virtual machines (VMs) must often carry out far more I/O operations than one server running a single workload, and typical virtualization environments emulate I/O devices that run less efficiently than native I/O devices.

In essence, virtualization acts like a funnel, combining and mixing many disparate I/O streams, sending out to the disk what becomes a very random I/O pattern. To make matters worse, the more VMs are added, the more the issue is compounded as more I/O is "randomized." All of this has a very negative affect on storage performance, and renders time-honored techniques such as read-ahead buffers and caching algorithms far less effective than in conventional physical environments.

Storage I/O is the most critical issue in a virtualized environment, and can cause organizations to spend a great deal on storage, purchasing more and more disk spindles, but often using only a fraction of their capacity because of performance issues. The outcome is that, due to issues relating to performance bottlenecks in the storage infrastructure, some applications are deemed unable to be virtualized; however, a properly tuned storage environment might have accommodated those applications. So what’s the alternative? The answer is V-locity 4 VM Accelerator. 

V-locity 4 VM Accelerator provides:

·         Increased application performance up to 50%

·         Up to 50% faster access to frequently accessed files

·         Faster I/O performance without the cost of additional storage hardware

·         Increased VM density per physical server up to 50%

·         Extended hardware lifespan by eliminating unnecessary I/Os

·         Automatic and real-time operation for true “Set It and Forget It®” management 

What makes V-locity 4 so effective is its powerful toolkit of proactive technologies, including IntelliWrite,® V-Aware,® CogniSAN,® InvisiTasking® and the new IntelliMemory® RAM caching technology.

New! IntelliMemory™ Caching Technology
IntelliMemory intelligent caching technology boosts active data, improving I/O response time up to 50% or more while also eliminating unnecessary I/O operations from getting into the network or storage.

Improved! IntelliWrite® Technology
IntelliWrite automatically prevents the operating system from breaking files into pieces and writing those pieces in a performance penalized manner. This proactive approach improves performance up to 50% or more while preventing any negative impact to snapshots replication, data deduplication or thin provisioning growth. As this proactive approach happens at the server level, the network and shared storage simply has less I/O operations to transfer and process.

New! Performance Benefit Analyzer
The Performance Benefits Analyzer helps document the performance benefits of V-locity. The benefit analyzer looks at your current system performance, then compares these results to those after using V-locity to provide a detailed report showing specific improvements and benefits to your system.

V-Aware® Technology
V-Aware detects external resource usage from other virtual machines on the virtual platform and eliminates resource contention that might slow performance.

CogniSAN® Technology
CogniSAN detects external resource usage within a shared storage system, such as a SAN, and allows for transparent optimization by not competing for resources utilized by other VMs over the same storage infrastructure. And it does this without intruding in any way into SAN-layer operations.

InvisiTasking® Technology
InvisiTaksing allows all the V-locity 4 "background" operations within the VM to run with zero resource impact on current production.

Set It and Forget It®
Automatic and real-time operation.

For more details and a FREE trial, visit www.condusiv.com/products/v-locity or call a sales representative at 1-800-829-6468.

IntelliWrite technology has been around for about two years now, optimizing literally millions of systems worldwide. It seamlessly integrates with Windows, delivering optimized writes upon initial I/O (no need for additional, after-the-fact file movement). What does that translate to? Actual fragmentation prevention.

Interestingly, we do occasionally get asked how it bears up against modern storage technologies:

“Don’t the latest SANs optimize themselves?”

“Do I really need this on my VMs? They aren’t physical hard drives, you realize…”

Or even…

“I don’t need to defragment my SAN-hosted VMs.”

Now, there are some factors which must be considered when you’re looking at optimizing I/O in your infrastructure:

• I/O from Windows is just abstracted Reads and Writes from a higher layer, even directly over a bare metal disk.
• Due to the way current Windows file systems are structured, I/O can be greatly constrained by file fragmentation—no matter what storage lies underneath it.
• Fragmentation in Windows means more I/O requests from Windows—even if files are stored perfectly contiguously at the SAN level, Windows still has to send X amount of requests because of the fragmentation that it sees within its top level.
• File fragmentation is not the same as block-level (read: SAN-level) fragmentation. Many SAN utilities resolve issues of block-level fragmentation admirably; these do not address file fragmentation.
• Finally, and as noted above, IntelliWrite prevents fragmentation in real time by improving Windows “Best Fit” file write logic. This means solving file fragmentation issues with no additional writes which could create issues with SAN de-dup or various copy-on-write data redundancy measures.

We performed testing with a customer recently in order to validate the benefits of IntelliWrite over cutting-edge storage. This customer’s SAN array is less than a year old, and while we don’t want to go into specifics in order to avoid seeming partial, it’s from one of today’s leading SAN vendors.

Testing involved apples to apples comparison on a production VM hosted over the SAN. A non-random workload was generated 3 times, recording Windows-level file fragmentation, several PerfMon metrics, and time to complete the workload. The test was then repeated 3 times, now with IntelliWrite enabled on the same VM’s test volume.

Here were the results:

Diskeeper Corporation recently delivered a live webinar hosted by Ziff Davis Enterprise. The principle topics covered were:

• Measuring performance loss in Windows over SAN
• Identifying client-side performance bottlenecks in private clouds
• Expanding performance awareness to the client level
• The greatest and often-overlooked performance issue in a virtual ecosystem

The webinar was co-hosted by:

• Stephen Deming, Microsoft Partner Solution Advisor
• Damian Giannunzio, Diskeeper Corporation Field Sales & Application Engineer

Don't miss out on this critical data! If you missed the webinar, you can view the recorded version online here.

Here are some additional, relevant resources:

White Paper: Diskeeper 2011: Improving the Performance of SAN Storage

White Paper: Increasing Efficiency in the IT Environment

White Paper: Inside Diskeeper 2011 with IntelliWrite

White Paper: Running Diskeeper and V-locity on SAN Devices 

In today’s well connected world of electronics and instant communications I received a text from a friend asking if I had seen the recent PC World magazine (February, 2012).  He said it had some tidbit of information concerning one of my favorite subjects; system performance, defragmentation, and SSDs.  I located a copy here at the office and found the article. As I read the first line I realized the debate on the virtues of defragmentation especially on SSDs will be one that goes on indefinitely as no one really talks about the issue with supporting hard facts and numbers.  Most articles are rehashing ideas and opinions long since debunked.  They continue to surface because very few truly understand the intricacies of the Windows NTFS file system and that of the storage media, whether it is rotating magnetic hard disks or electronic solid state disks.

So let’s set the record straight… Fragmentation is exponentially more of a problem with today’s data explosion. Defragmenting once a week will still cause the user to experience slowdowns from the degradation effects and doesn’t address the issue when files are initially being written.  And yes, never do a traditional defrag on SSDs.

NTFS file and free space fragmentation happens far more frequently than you might guess.  It has the potential to happen as soon as you install the operating system.  It can happen when you install applications or system updates, access the internet, download and save photos, create e-mail, office documents, etc…  It is a normal occurrence and behavior of the computer system, but does have a negative effect on over all application and system performance.  As fragmentation happens the computer system and underlying storage is performing more work than necessary.  Each I/O request takes a measurable amount of time.  Even in SSD environments there is no such thing as an “instant” I/O request.  Any time an application requests to read or write data and that request is split into additional I/O requests it causes more work to be done.   This extra work causes a delay right at that very moment in time.  Whoever thought that defragmenting once a month or weekly was good enough, simply didn’t understand fragmentation.

Disk drives have gotten faster over the years, but so have CPUs.  In fact, the gap between the difference in speed between hard disks and CPU has actually widened.  This means that applications can get plenty of CPU cycles, but they are still starving to get the data from the storage.  What’s more, the amount of data that is being stored has increased dramatically.  Just think of all those digital photos taken and shared over the holidays.  Each photo use to be approximately 1MB in size, now they are exceeding 15MB per photo and some go way beyond that.  Video editing and rendering and storage of digital movies have also become quite popular and as a result applications are manipulating hundreds of Gigabytes of data.  With typical disk cluster sizes of 4k, a 15MB size file could potentially be fragmented into nearly 4,000 extents.  This means an extra 4,000 disk I/O requests are required to read or write the file.  No matter what type of storage, it will simply take longer to complete the operation.

Suppose I chose to do some editing of my family videos on Tuesday evening.  Even the built-in defragmentation tool in Windows 7 doesn’t do me much good because it isn’t schedule to run until Wednesday morning at 1:00am.  This also means that quite a bit of fragmentation has built up since the previous week when it last ran.  Maybe I’ll manually run it, but that can take quite a while and I’ve wasted time that I would have rather spent on my project.  Unfortunately, the Windows built-in defragmentation utility doesn’t prevent fragmentation so even after running it manually; I still will wind up with fragmentation and slow access speed of my newly created files. 

I’ve often thought about why Wednesday at 1:00am was chosen as the time to schedule defragmentation.  Why isn’t it scheduled all the time?   It is because there could be system resource conflicts that either interfere with getting the task done or the defragmentation process has difficulty throttling back under a variety of conditions.  Regardless, this wait a week to clean up fragmentation doesn’t really help me when I need it most.

As pointed out in the article, the built-in defragmenter does not have the technology advancement to properly deal with fragmentation and SSDs. The physical placement of data on an SSD doesn’t really matter like it does on regular magnetic HDDs.  With an SSD there is no rotational latency or seek time to contend with.  Many experts assume that fragmentation is no longer a problem, but the application data access speed isn’t just defined in those terms.  Each and every I/O request performed takes a measurable amount of time.  SSD’s are fast, but they are not instantaneous.  Windows NTFS file system does not behave any differently because the underlying storage is an SSD vs. HDD and therefore fragmentation still occurs.  Reducing the unnecessary I/O’s by preventing and eradicating the fragmentation reduces the number of I/O requests and as a result speeds up application data response time and improve the overall lifespan of the SSD.  In essence, this makes for more sequential I/O operations which is generally faster and outperforms random writes.

In addition, SSD’s require that old data be erased before new data is written over it, rather than just writing over the old information as with HDDs.  This doubles the wear and tear and can cause major issues with the speed performance and lifespan of the SSD.  Most SSD manufactures have very sophisticated wear-leveling technologies to help with this. The principle issue is write speed degradation due to free space fragmentation.  Small free spaces scattered across the SSD causes the NTFS file system to write a file in fragmented pieces to those small available free spaces.  This has the effect of causing more random I/O traffic that is slower than sequential operations.

I think I have clearly made my point….  The built-in defragmenter in Windows 7 is not a solution for neither the consumer/home user, nor the enterprise business user.  Data access speeds are far more critical in the business world where time is money.  In the enterprise environment there are generally many more files that are used by higher number of users that are accessing data across shared type of storage such as SAN.  Even virtual platforms benefit from the same points covered.  This opens the door and is the reason why robust solutions such as Diskeeper exist.  More data about Diskeeper and the superior technology it offers can be found at http://www.diskeeper.com.

Overview 

The intensified demand for IT network efficiency and lower operating costs has been driving the phenomenal growth of virtualization in the past decade, with no signs of slowing. At present, many corporations run more virtualized servers than physical servers.

While virtualization provides opportunity for consolidation and better hardware utilization, it’s critically important to recognize and never exceed hardware capacities.  

The importance of ensuring sufficient CPU and memory are well understood, with many processes and management tools available to help plan and properly provision VMs for these critical resources. I/O traffic, network and disk, are more complicated to account for in virtual environments as they tend to be more unpredictable.

In order to better accommodate disk I/O, most virtualization platforms will implement a Storage Area Network (SAN) which can offer greater data throughput, and a dynamic environment to address fluctuations in I/O demands.

While a storage infrastructure can be built out to meet expected demands, there are uncontrollable behaviors that will still impede performance. 

File Fragmentation

As files are written to a general purpose local disk file systems, such as Windows NTFS, a natural byproduct is file fragmentation. File fragmentation is a state in which the data stream of a file is stored in non-contiguous clusters in the file system. Fragmentation occurs on logical volume, and by device drivers is translated to logical blocks, and eventually to physical sectors residing on a storage device. It can be demonstrated as pieces of a file located in a non-contiguous manner. The effect of this file fragmentation is increased I/O overhead, leading to slower system performance for the operating system.

In the case of virtual platforms, a guest operating systems is stored as a file (i.e. set of files) on the virtual platforms file system as a “virtual disk”. A virtual disk is essentially a container file, housing all the files that constitute the OS and user data of a VM.  A virtual disk files can fragment just as any other file can resulting in what amounts to a “logically” fragmented virtual hard disk, which still has typical file fragmentation contained within it. The picture represented to the right would appear as “VirtualServer1.vmdk, 30GB in size, in 4 pieces”.  

This situation equates to hierarchical fragmentation or more simply fragmentation-within-fragmentation. Given the relatively static nature and large size of virtual disks, and large allocation unit size of VMFS (typically 1MB), fragmentation of these files is unlikely to cause performance issues in most cases. The focus and solution to fragmentation should be directed at the guest operating system.

Fragmentation within a Windows VM will cause Windows to generate additional unnecessary I/O. This added I/O traffic can be discovered using Windows Performance Monitor, where it is one of the principal causes for Split I/O.  

Fragmentation prevention and defragmentation technologies exist to eliminate unnecessary I/O overhead, and improve system performance. Fragmentation prevention solves fragmentation at the source, by actively causing files to be written contiguously via advanced files system drivers. Defragmentation is the action in which file fragments are re-aligned within the file system, into a single extent, so that only the minimal amount of disk I/Os are required to access the file, thereby increasing access speed.  

Partition Alignment 

Depending on your storage protocol and virtual disk type, misaligned partitions can cause additional unnecessary I/O[1]. In the example below in which the ESX and SAN volumes are not properly aligned, a Word file spanning four NTFS clusters causes additional unnecessary I/O in both VMFS and the SAN LUN.  

Similarities between Partition Alignment and Fragmentation 

Much like misaligned partitions can cause additional I/O at multiple layers, so does fragmentation. While partitions can be properly aligned once and never require further corrective action, fragmentation will continue to occur, and needs to be regularly addressed.

In the example below, which assume proper partition alignment, a file in eight fragments in the guest OS, causes additional I/Os to be generated at the virtualization platform layer[2] and at the LUN.   

Defragmentation in the guest operating system (of this file), eliminates excess I/O when accessing the file as Windows only generates one I/O. This reduction in I/O traffic translates to the host file system and SAN LUN, ensuring efficiencies at each layer.   

Best Practices 

Defragmentation of Windows file systems is a VMware recommended performance solution. The VMware Knowledge Base article 1004004[3] states “Defragmenting a disk is required to address problems encountered with an operating system as a result of file system fragmentation. Fragmentation problems result in slow operating system performance.” In order to validate the Vmware statement, tests were performed.

Test Environment

Configuration

Test Environment Configuration Host OS: ESX Server 4.1 with VMFS (1MB blocks)

Guest OS: Windows Server 2008r2 x64 (3GB RAM, 1 vCPU)

Benchmarking Software: Iometer (http://www.iometer.org/)

Fragmentation Program: FragmentFile.exe (used to fragment a specified file)

Defragmentation Software: V-locity® 3.0 (http://www.diskeeper.com/business/v-locity/)

 

Storage: 10GB test volume in a 40GB virtual disk. VMFS Datastore of 410GB. HP Smart Array P400 controller. RAID 5 (4x 136GB SCSI at 10K RPM) Stripe size of 64KB with a 64KB offset (properly aligned).

Load Generation 

The industry standard benchmarking tool Iometer was used to generate I/O load for these experiments.  

Iometer configuration options used as variables in these experiments:

• Transfer request sizes: 1KB, 4KB, 8KB, 16KB, 32KB, 64KB, 72KB, and 128KB

• Percent random or sequential distribution: for each transfer request size, 0 percent and 100 percent random accesses were selected

• Percent read or write distribution: for each transfer request size, 0 percent and 100 percent read accesses were selected 

Iometer parameters that were held constant for all tests:

• Size of volume: 10GB

• Size of Iometer test file (iobw.tst): 8,131,204 KB (~7.75GB)

• Number of outstanding I/O operations: 16

• Runtime: 4 minutes

• Ramp-up time: 60 seconds

• Number of workers to spawn automatically: 1 

The following is excerpted from a VMware white paper[4], and helps to explain why the Iometer parameters were used. 

Servers typically run a mix of workloads consisting of different access patterns and I/O data sizes.

Within a workload there may be several data transfer sizes and more than one access pattern.There are a few applications in which access is either purely sequential or purely random. For example, database logs are written sequentially. Reading this data back during database recovery is done by means of a sequential read operation. Typically, online transaction processing (OLTP) database access is predominantly random in nature. 

The size of the data transfer depends on the application and is often a range rather than a single value. For Microsoft Exchange, the I/O size is generally small (from 4KB to 16KB), Microsoft SQL Server database random read and write accesses are 8KB, Oracle accesses are typically 8KB, and Lotus Domino uses 4KB. On the Windows platform, the I/O transfer size of an application can be determined using Perfmon.

In summary, I/O characteristics of a workload are defined in terms of the ratio of read operations to write operations, the ratio of sequential accesses to random accesses, and the data transfer size. Often, a range of data transfer sizes may be specified instead of a single value.  

Create Fragmentation 

The FragmentFile.exe tool was used to fragment the Iometer test file (iobw.tst) into 568,572 fragments, a mid-range amount of fragmentation for a production server. The statistics collected from an analysis of the volume (shown below) were performed with V-locity.

Test Procedure 

The primary objective was to characterize the performance of fragmented versus defragmented virtual machines for a range of data sizes across a variety of access patterns. The data sizes selected were 1KB, 4KB, 8KB, 16KB, 32KB, 64KB, 72KB, and 128KB. The access patterns were restricted to a combination of 100 percent read or write and 100 percent random or sequential. Each of these four workloads was tested for eight data sizes, for a total of 32 data points per workload.

In order to isolate the impact of fragmentation only the test VM was powered on and active for the duration of the tests.

For the initial run, Iometer created a non-fragmented file, and performance data was collected. Then FragmentFile.exe tool was used to fragment the Iometer test file, the VM rebooted, and the test procedure re-run. This resulted in data sets for both non-fragmented and fragmented scenarios. The results are graphed below.  

Performance Results  

As the graphs show, all workloads show an increase in throughput when the volume [file] is defragmented (i.e. not fragmented).  It also becomes clear that as the I/O read/write size increases, the fragmentation-induced I/O latency increases dramatically.  The greatest improvements of a contiguous file are found with file reads; both random and sequential. 

Random Reads  

Random Writes 

Sequential Reads

Sequential Writes

Conclusion

Fragmentation demonstratively impedes performance of Windows guest operating systems.  While the tests depicted were executed on a singular VM, the issue becomes exponentially worse in a multi-VM environment wherein each VM suffers from file fragmentation.  As server virtualization establishes a symbiotic relationship, it is important to remember that generating disk I/O in one virtual machine affects I/O requests from other virtual systems.  Therefore latencies in one VM will artificially inflate latency in co-located virtual machines (VMs that share a common platform).  

Fragmentation artificially inflates the amount of disk I/O requests which, on a virtual machine platform, compounds the disk bottleneck even more so than on conventional systems.

Eliminating fragmentation in VMs, and the corresponding unnecessary disk I/O traffic, is vital to platform-wide performance and enhances the ability to host more VMs on a shared infrastructure.

Coming Soon: V-locity 3.0 (virtual platform optimizer)  has some fantastic new features in it we're sure you’ll like, including:

+Full Support for ESXi Server (in addition to existing support for ESX and Hyper-V)

+Reduced installation effort for ESX Servers (no installation on Host)

+New CogniSAN technology (for storage area networks)

+New V-Aware technology (for any virtualization platform)

+Automatic zeroing of free space (for thin/dynamic virtual disks)

+Added support for virtualization platforms such as XenServer, RHEV, Oracle VM and more

We are just a few short weeks from releasing it, and could use your help. If your interested in catching a “sneak peak” (our final release candidate build), and are interested and able to install, evaluate and then comment (fill out a 10 minute online survey) on this software, simply fill-out a Non-Disclosure Agreement (NDA) located here.

Okay, so you've bought, installed, connected, configured, and then tuned/optimized your new storage virtualization solution, but somehow there are still latencies with apps (e.g. SQL).

You've run the Storage Area Network (SAN) vendor utilities that:

• did not see any contention on the disks in the RAID group(s). 
• noted that the average I/O to physical disks did not exceed a reasonable number of I/O's per second on each volume in the meta device.
• checked the utilization of the port that the Host Bus Adaptor (HBA) is zoned to and did not see any performance issues.
• noted the switch port that the HBA is connected to is not saturated or reporting any errors.

And basically surmised "at this time we do not see any issue on the array or with the SAN in reference to this server."

However....

When running PerfMon within Windows, it continues to uncover latencies in the 100ms+ range. What the hayel!

This is when it's important to consider what those SAN optimization and reporting tools are providing. SANs can optimize storage from HBA-to-spindle. Above the HBA other factors cause latencies outside the scope or control of the SAN, and ultimately it is the App/User Experience that needs to be addressed.

So, it's time to look further up the storage stack.

Here is a great chart (borrowed from VMware here):

The chart helps simplify that SAN and even VM based latency monitoring and storage optimization do not account for latencies that may exist in the Guest Operating System (GOS). They are only aware of, and able to optimize I/O from the point they receive the traffic to the physical storage.

Monitoring performance in Windows does not go away simply because you've left direct attached storage (DAS) and physical servers to go virtual. There are numerous causes for poor performance on the GOS side, from poorly written apps, to incorrect configurations, to bad partitioning strategies, file system fragmentation and more. Pretty much all the issues that could cause poor Windows I/O performance on physical servers with DAS, still exist.

It's important to continue to use GOS based solutions to determine application latency such as PerfMon, which can support counters for popular apps (like SQL).

To evaluate if file fragmentation is a potential cause, track these metrics with Perfmon. Fragmentation will show up in the logical disk statistics referred to in the document. You can also use a freeware solution from Diskeeper Corporation; called Disk Performance Analyzer for Networks (DPAN) to collect file fragmentation statistics from any Windows system (physical or virtual) on your LAN/WAN.  You can download DPAN here.

Sample DPAN Report:

Overview:

As high performing storage solutions based on block protocols (e.g. iSCSI, FC), SANs excel at optimizing block access. SANs work at a storage layer underneath the operating systems file system; usually NTFS when discussing Microsoft Windows®. That dictates that a SAN is unaware of “file” fragmentation and unable to solve this issue.

With file fragmentation causing the host operating system to generate additional unnecessary disk I/Os (more overhead on CPU and RAM) performance suffers. In most cases the randomness of I/O requests, due to fragmentation and concurrent data requests, the blocks that make up the file will be physically scattered in uneven stripes across a SAN LUN/aggregate. This causes even greater degradation in performance.

Fortunately there are simple solutions to NTFS file system fragmentation; fragmentation prevention and defragmentation. Both approaches solve file fragmentation at the source, the local disk file system.

IntelliWrite® “The only way to prevent fragmentation before it happens™”

IntelliWrite is an advanced file system driver that leverages and improves upon modern Windows’ file system “Best Fit” file write design in order to write a file in a non-fragmented state on the initial write. Intelligently writing contiguous files to the disk provides four principal benefits above and beyond defragmentation, including:

• Prevents most fragmentation before it happens
• Better file write performance
• An energy friendly approach to improving performance, as defragmentation is not required for files handled by IntelliWrite
• 100% compatibility with copy-on-write technologies used in advanced storage management solutions (e.g. snapshots)

While eliminating fragmentation improves performance. it is important to properly configure and account for advanced SAN features.

With the increasing popularity of SANs, we've included instructions in the Diskeeper installation to ensure users properly configure Diskeeper:

We suggest reading this full document before executing any of the recommended configurations. These instructions apply to V-locity (used on VMs as well).

Best Practices:

Highlights:

Implementing Diskeeper on a SAN is simple and straightforward. There are two principal concepts to ensuring proper configuration and optimal results:

• Ensure IntelliWrite is enabled for all volumes.
• Find a time to schedule Automatic Defragmentation (more details below)

If you are implementing any of the following SAN based technologies such as Thin Provisioning, Replication, Snapshots, Continuous Data Protection (CDP) or Deduplication, it is recommended to follow these guidelines.

Defragmentation can cause unwanted side effects when any of the above referenced technologies are employed. These side effects include:

This is why it is important to enable the fragmentation prevention (IntelliWrite) and change the Automatic Defragmentation to occur during non-production periods to address the pre-existing fragmentation:

During Installation, disable Automatic Defragmentation;

Upon installation ensure IntelliWrite is enabled on all volumes (default). IntelliWrite was specifically designed to be 100% compatible with all advanced SAN features, and should be enabled on all SAN LUNs. IntelliWrite configuration is enabled or disabled per volume, and can be used in conjunction with Automatic Defragmentation, or exclusively.

Once installed, enable Automatic Defragmentation for any volumes that are not mapped to a SAN LUN. This may include the System Partition (e.g. C:\).

If you are not using any advanced SAN features, it is recommended to enable Automatic Defragmentation for all days/times. However, note that pre-existing fragmentation will require significant effort from Diskeeper to clean up. This effort will generate disk I/O activity within the SAN.

Therefore, if existing fragmentation is significant, initially schedule Diskeeper to run during off-peak hours. As Diskeeper has robust scheduling capability, this is easily configured.

The above example disables defragmentation Monday through Friday. It also disables defragmentation Saturdays and Sundays except between 7pm until 3:30am the following morning. This would afford 17 hours of defragmentation availability per week. Immediately following these scheduled defragmentation periods is when SAN maintenance for advanced features should be addressed (e.g. thin reclamation, deduplication).

Should accommodating SAN maintenance be difficult (e.g. limited maintenance windows)using a weekly optimization process, very granular scheduling is also available with Diskeeper. Note, maintenance windows are not required in order to implement and benefit from IntelliWrite.

If you are implementing the above mentioned advanced technologies and your SAN provides hot block optimization / data tiering, it is also recommended to disable I-FAAST® (Intelligent File Access Acceleration Sequencing technology). I-FAAST sequences hot “files” (not blocks) in a Windows volume, after determining hardware performance characteristics. The sequencing process creates additional movement of data for those advanced SAN features, and is therefore generally recommended to disable when similar SAN solutions are in place.

Note, I-FAAST requires Automatic Defragmentation be enabled. Also note that I-FAAST is disabled by default in Diskeeper 2011 in certain cases. Also note that I-FAAST generates additional disk I/Os and will therefore cause an increase in the aforementioned Automatic Defragmentation side effects.

Once pre-existing fragmentation has been removed, increase the periods in which Diskeeper actively optimizes the Windows file systems. With real-time defragmentation and InvisiTasking® technology, Diskeeper immediately cleans up fragmentation (that is not prevented by IntelliWrite). This minimal ongoing optimization generates only invisible, negligible I/O activity.

New features in Diskeeper 2011 to improve SAN performance:

Diskeeper 2011 introduces SAN specific solutions. These default solutions automate many of the configurations required for SAN-attached servers.

Diskeeper 2011’s new Instant Defrag™ technology dramatically minimizes I/O activity, and exponentially speeds up defragmentation. The Instant Defrag engine is provided fragmentation information, in real-time, by the IntelliWrite file system filter driver (those fragments that it does not prevent). Without the traditional need to run a time and resource intensive whole-volume fragmentation analysis, Instant Defrag can address the recently fragmented files as they occur. This dynamic approach prevents a buildup of fragmentation, which could incur additional I/O overhead to solve at a later date/time.

Diskeeper 2011’s new Efficiency Mode (default) maximizes performance, while minimizing disk I/O activity. By focusing on efficiency and performance and not on presenting a “pretty disk” visual display, Diskeeper 2011 minimizes negative side effects (e.g. reduce snapshot storage requirements or thin LUN growth, etc..) while maximizing performance benefits. It is a SAN-optimized defrag mode and our recommended solution for SAN-attached Windows volumes.

By default, Efficiency Mode also disables proprietary file placement features such as I-FAAST.

Also, by default, Diskeeper 2010/2011 moves data to lower NTFS clusters, and hence generally “forward” on SAN LUNs.

• Ensure IntelliWrite is enabled for all volumes.
• Automatic Defragmentation should be enabled at all times for all direct attached storage volumes.
• Use Efficiency Mode of Diskeeper 2011.
• Schedule Automatic Defragmentation on SAN LUNs, based on use of advanced SAN features.
• Run SAN processes such as space reclamation and/or deduplication on recently defragmented LUNs using advanced SAN features.

Want this in PDF form. Get it here: Best Practices for using Diskeeper on Storage Area Networks.pdf (3.00 mb)

Diskeeper Corporation, Innovators in Performance and Reliability Technologies, announced that its Diskeeper 2010 performance software has received the Certificate of Networthiness (CoN) from the U.S. Army Network Enterprise Technology Command. The Certificate of Networthiness signifies that Diskeeper performance software is configured to the current Army Golden Master baseline and complies with all U.S. Army and Department of Defense (DoD) standards for security, compatibility and sustainability. A CoN is required for all enterprise software products deployed in the Army Enterprise Infrastructure Network and used by the U.S. Army, all National Guard, Army Reserve and DoD organizations that use the Army Enterprise Infrastructure.

"Spokane Regional Health District uses CommVault Simpana backup/archiving/disaster recovery software installed on a dedicated server with 37TB of SAS attached storage.

We perform daily full and incremental backups of all our servers. The data backup is disk-to-disk-to-tape and is deduplicated as it is saved on the SAS storage. The deduplication process can create a very large number of file fragments, sometimes over 1,540,000 fragments on a 2TB disk array. With Diskeeper EnterpriseServer automatic defrag running the response time of the arrays is approaching 0.02 second delay due to fragmentation. This has reduced our backup time by approximately 25 percent for any D2D2T job. 

SRHD also uses Microsoft Hyper-V and currently has 31 virtualized servers running on an Intel Modular Server. There are 72TB of storage available to the Modular Server via SAS connections featuring dual path IO. All of the data on the SAS arrays is maintained in RAID 60 logical disk drives. Since setting up V-locity, which has built-in support for VHD (virtual hard disks), with automatic defragmentation, our VHDs very seldom show any fragmentation. 

The solutions also have the intelligence to monitor disk IO and the defragmentation will pause to prevent IO latency affecting performance. They are set and forget applications which perform a very well without impact on our server response times."

-Larry Smith, Spokane Regional Health District

We have been running Diskeeper 2010 EnterpriseServer for two months on an HP EVA SAN 4000 and 4400, with 4 1TB volumes each.  

Diskeeper removed over 45 million fragments in the last two months on a specific volume that had only 15% free space, and IntelliWrite prevented 24,000 fragments. I believe that will be even better as soon as we can extend this volume to two TB. 

We see a big improvement on the backup time which came down from 48 hours to 32 now, and it’s still going down. 

I believe Diskeeper worth the price and I never had any trouble with software from Diskeeper Corporation, so that alone narrowed the field of choices. 

Jean-François Poirier
Technicien Telecommunication
Spectra Premium Industries Inc.

Later this month (Thursday, May 27, 2010 at 12:00pm Eastern / 9:00am Pacific), IT Analyst David Chernicoff and I will co-host a webinar covering the benefits and caveats of defragmenting SAN attached servers.

Here is the abstract: 

As storage technologies have become more advanced there is a tendency for storage administrators to believe that the hardware is handling all of their data maintenance needs, keeping their files optimized in the best possible way for top performance and availability. The reality is that hardware solutions alone aren't the most efficient way to keep your critical data stored in an optimal fashion. With this webinar we will give you the information you need to understand how your data is actually being handled and what you can do to improve the performance and optimization of your Windows Server storage.

You can register here: www.windowsitpro.com/go/seminars/diskeeper/windows_san 

We also have two webinars planned for June on the topic of virtualization. One jointly with Redmond Mag, and the other with Microsoft. I'll post registration links on this blog when they are available. Lastly, we'll have a reprise of the SSD webinar we did with Microsoft sometime in July - this time we'll host and Microsoft will be our guest.

If you live in on the west coast (USA), you may have seen an ad campaign about happy cows coming from California. Given we're a CA-based software company we concur.

OK wait a minute. Why are we talking about cows? What does this have to do with defrag? Maybe you're thinking "Michael's talking bovine, he's had a few too many".

Well maybe yes, but... I do have a point.  

Copy on Write refers to a low level technology that looks at block data changes and then takes a particular action. Every time there is a write, a copy on write technology would seek to make a copy of just the changes - not the entire new file. That action may be part of inline data dedupe, may be a snapshot, etc. The basic point is that copy on write is used to isolate changes to data at a granular level rather than at a file level.

The consideration is that most copy on write technologies are unable to distinguish between changes to data or movement of pieces of data, due to a defragmentation job. In other words, if you run a defrag, copy on write may think there are actual data changes to files, and then take action to make block-change copies, run a dedupe, etc...

Holy copy on write you say!

So, it is possible that a defrag, any kind of defrag, causes a copy on write based technology to go into hyperactive mode. That may mean a CDP (continuous data protection)/snapshot program may be triggered in to keeping/taking far more copies that it needs to. It is basically fooled into thinking that a defrag represents actual changes to data, and that they need to process those changes. Now this is a false processing but, because most copy on write solutions function underneath the file system layer, they simply cannot differentiate that actions that take place at the file system are not changes to data, but rather data-movement-for-optimization reasons.

So, if we're talking about a copy on write solution that takes snapshots, we could see an increase in the amount of copies that a snapshot solution would have to take. That would make for a fairly fat copy on write (a lot of extra data storage demands created by not understanding defrag).

Copy on write based solutions that work at the file system level (NTFS), have the possibility to recognize changes due to defrag and differentiate them from changes due to new actual data to a file. One such copy on write solution is Microsft's VSS (Volume Shadow Copy Service). However, as noted, most copy on write technologies operate at storage layers that are abstracted from the local disk file system - they operate at levels underneath the file system. Again, that means defrag jobs in the file system will not be recognized by these solutions, and a defrag job of any kind, will cause unnecessary copies.

In comes IntelliWrite. Now, it makes sense to think that IntelliWrite was invented as a faster and, perhaps cooler, solution to fragmentation. But, the truth is that solving fragmentation at the source (when it is created) is vital to ensure compatibility with many of the copy on write solutions that may be implemented at virtualization host or SAN layer (i.e. underneath and hence, unaware of the file system).

So, in a nutshell, IntelliWrite was very much designed to ensure that defrag offered full compatibility with modern storage technologies. That, we feel, makes for happy copy on writes.

Storage Area Networks (SANs) are becoming increasingly more common. A few years ago "SAN" was an acronym that rarely made it out of the lexicon of IT Storage Admins at 1000s+ employee multinationals. In more recent years the SAN IHV/ISVs have greatly simplified and reduced the installation, maintenance, technical effort, and acquisition costs. It's increasingly more common to see SANs in medium sized businesses. Many SAN providers have even offered targeted "mid-range" solutions often for those mid-sized organizations. EMC is one such vendor that targets just such a solution with their Clariion product line.

Microsoft has also been at the forefront of advancements in data storage centralization. Technologies like Storport (introduced in Windows Server 2003), iSCSI software initiator, multipath I/O storage stack, and more.

A great deal of innovative software from Microsoft and SAN vendors make the whole system work.

An important point to be aware of is where in the whole computer system, the SAN "plugs" in. A SAN is, in essence, a replacement for a single disk. In the Windows I/O storage stack a SAN solution replaces the disk driver (disk.sys), with its own drivers. Eventually data must reside on a physical storage device of some kind, so any request to read or write data will have to go through this disk driver, or SAN replacement thereof. However, before the I/O request gets to this lower level it goes through a local disk file system. When talking about Windows in a SAN, that local disk file system is pretty much always going to be NTFS. Fragmentation as Windows sees it and cares (same for Diskeeper), is at NTFS. So, if files are fragmented as NTFS sees it, the local disk file system has to send a great deal more I/O traffic into the SAN, causing the SAN to do more work that it should.

We have a very thorough white paper that covers defragmenting SAN. It also includes Best Practices for Diskeeper. Check it out here.

Even SAN vendors recommend defragmenting Windows. EMC includes a paragraph about the need for their Clariion family of products in a white paper here. In it (pg. 5) it says:

The interesting part is they also note the SAN file system solutions they offer are NOT designed to handle NTFS fragmentation, and that they recommend to defragment that "local disk" file system. When we here at Diskeeper talk about the need to defrag SAN attached systems, were talking about doing what we always have done - defragging NTFS in Windows (from Windows). That is an important point as SANs also use a file system to organize data. Diskeeper, nor Windows defrag addresses this. "If" defrag of some kind is needed in this SAN file system it is handled by the SAN vendor - you can check with their support staff on that subject. Defragmenting NTFS and defrag of SAN file systems are two completely different subjects and should not be confused.

Even more reading:

Ziff Davis Enterprise (from the same parent company of eWeek) just released a paper on defragmenting SANs, including benefits and covering some considerations as well. You can read that here.

In summary, even with the tremendous amount of technology that has gone into SANs over the past decade, defragmenting SANs is still just as vital as defragmenting DAS (direct attached storage).