• What systems are configured for replication
• What data is being replicated
• What are the primary and second volumes
• The direction in which the data is being replicated between systems
• Whether the replication is synchronous or asynchronous
• How the replication is configured - 1:1, 1:N, N:1 or SyncLD

• VMs competing for the same resources. In cloud computing environments, competition for system resources can limit scalability and performance. While this resource contention is rarely an issue in smaller environments, large ESX or vSphere servers that may host tens if not hundreds of VMs may run up against these system scalability limits.
  

In these situations what is known as the SCSI reservation bit locks a LUN when, for example, VMDK clones are made. This precludes large environments from putting large numbers of VMDKs on a single large LUN. The reason is that other VMDKS on that LUN are negatively impacted waiting for a SCSI reservation to complete while a clone is made of that VMDK file.

• Expediting the creation of VMware initiated VMDK clones. VMware also has the ability to create its own clones. However when it does so, it adds extra overhead to ESX or vSphere underlying physical server's CPU, memory and network resources since the clone has to traverse the storage array, the host and then go back out to the storage array again.

• Host overhead associated with zeroing out previously allocated space. vSphere includes the ability to zero out blocks of data when storage is allocated to a VM. By first zeroing out these blocks of data, it prevents the new VM from accidentally accessing any of the data that may have been stored on that disk by a deleted VM that previously had access to it. However the new problem that results is that the newly created VM has to generate excessive amounts of write I/O and overhead on the physical host and network in order to zero out newly allocated blocks.

• First, if they are already using or want to use larger size LUNs and place multiple VMDKs on a single LUN, they can now do so and still make clones of individual VMDK files without negatively impacting other VMDKs also located on that LUN.
• Second, 3PAR's implementation of the ATS command was done within the ASIC of its InServ storage servers to expedite processing of this command. While the performance benefits that this provides in small environments may be too negligible to notice, it is service providers with large virtualized infrastructures that need to quickly create large numbers of clones that are most apt to benefit from this feature.

• The software is there and it works. Few companies buy any version Microsoft software until Microsoft releases its first patch. The same analogy applies here. The sub-volume optimization software available from many storage vendors is, in many instances, in its first release with few if any customers using it in production or willing to act as a reference.
• Managing SSDs is the same as managing cache.  SSDs are being positioned as a second tier of cache but this approach is not as simple as it sounds. Cache is often used as an initial target for writes before the writes are de-staged to disk. The advantage that cache has over SSDs is that the write performance of cache is substantially better than SSDs so it is not a simple swap and replace.
• Vendors can provide a SSD/SATA system configuration that matches your requirements. Storage vendors are still largely guessing as to what is the right mix of SSD and SATA for your environment. While 95:5, 90:10, 85:15 and even 80:20 ratios of SATA to SSD are often used, without any information as to how a specific set of applications perform, it is difficult if not impossible for storage vendors to provide a SSD/SATA ratio that is optimal for your environment.
• SSDs work great in all situations.  SSDs work great for reads but are less than optimal for writes. While a single SSD will outperform a single HDD in all circumstances, in write-intensive environments or environments with large databases (over 1 TB) that have large amounts of random access reads, it is difficult to predict where the next read will come from. So if the system cannot predict the next block or blocks of data that are needed to be read and then places that data on the SSD before the read occurs, SSD still might not be the right solution for your environment.
• The movement of data between tiers will occur seamlessly. Moving one block of data from one tier to another is easy; automatically and dynamically moving hundreds, thousands or millions of blocks of data in real time so it is on the right tier of storage and then updating the index that tracks where the data is located is very complex and needs to be carefully orchestrated such that it does not interrupt application processing. At this time few if any vendors are even attempting this sophisticated level of sub-volume optimization.
• The right data will be on the right tier at the right time. Probably the biggest presumption that storage vendors hope users make is this: that sub-volume optimization software will place the right data on the right tier of storage just before or as the application needs it. However that is a BIG assumption. If sub-volume optimization only occurs on a scheduled basis or according to pre-set policies (as is the primary way it is implemented now), it presumes that the schedule is correct or that the person who set up the policies understands the behavior of the application well enough to predict when it will need data.

• The number of eDiscovery opinions almost doubled in 2009 over 2008
• Almost half of the eDiscovery opinions concerned sanctions, and sanctions were awarded in 70% of those cases, including 10 cases with terminating sanctions and five cases sanctioning counsel
• eDiscovery law is becoming more widespread and largely uniform, especially in federal jurisdictions
• Courts in every circuit issued e-discovery opinions in 2009.
• Courts are continuing to provide greater clarity on eDiscovery requirements, including the duty to preserve and the consequences of failing to do so.
• Courts increasingly are urging litigants to engage in cooperative and transparent discovery.
• Governmental entities are being held to the same eDiscovery requirements as private litigants.

• VMware pioneered the concept of a virtual machine (VM) running directly on a CPU.  Before VMware, server virtual operating systems treated VMs as applications which resulted in poor performance and even virtual machine crashes because the operating system on the VMs would try to directly access the underlying hardware. VMware solved this problem by implementing a technique call Binary Translations that intercepted these hardware calls before they could crash the VM. While complex, it made VMware stable and resulted in significant performance gains for VMs.

• Xen represents the second generation of server virtualization operating systems as it introduced the concept of paravirtualization. Using paravirtualization the virtualized operating system is modified in such a way that it is now aware that it is virtualized, can make direct calls into the hypervisor and cooperate with it for improved scheduling and I/O. The downside with this approach is that it requires operating system providers to make modifications to their operating system so it is "virtualization aware".

• Hardware assisted virtualization became available in 2005. This virtualized CPUs in x86 environments so that different levels of access to the CPU were available. This change enables the CPU to operate in either host or guest mode so the hypervisor can grant processes on guest VMs direct but controlled access to the CPU so they do not accidentally crash the entire physical server. This technique again expedites processing but again requires very complicated formulas to implement.

• First, use externally attached storage systems such as the 3PAR InServ Storage Servers that supports thin provisioning. In this way, when the VM is created, the VM only uses as much 3PAR storage as the OS and application actually need for written data.
• Second, only use thin provisioning storage systems that automate the recapture of capacity. In the case of 3PAR's storage servers, 3PAR provides a thin persistence option. This feature detects when an operating system or application "zeros out" blocks of data that are no longer needed so the underlying storage system can automatically detect and recapture these blocks of unutilized storage capacity.
• Third, if using VMware vSphere, users should take advantage of its eager zeroed thick format. This format has three benefits.

(1) Performance. Every new write in vSphere zeros the block before writing data.  With the zeros written at VM creation, ongoing I/O is faster.  
(2) Security.  If perchance any storage capacity was previously assigned to another VM and still had data on it, this feature zeros out those blocks so no data is accidently compromised.
(3) Efficiency.  The eager zeroed thick format can be run on a regular basis to zero out stranded capacity from deleted VMs and VMDKs.  With the appropriate storage equipped with capacity reclamation features such as 3PAR and Thin Persistence, the net effect is inline zero detection and instant storage capacity reclamation.

"The unit of data written in the 3PAR system is a "Chunklet," which is only 256MB long. 3PAR leverages these chunklets, which are held in a common storage pool, as a key component of its virtualization approach. In addition to chunklets, 3PAR has always had an additional construct in place called 'regions' that manage groups of chunklets and all the metadata (e.g., RAID type) associated with them.

3PAR has taken advantage of this structure to add more metadata to the region to track frequency of access, block size, access patterns, etc...all useful data to decide what should go into SSD. Ideal candidates to place on SSD are random, hot, mostly read data.

The secret sauce is the 3PAR software that chooses which blocks to place onto SSD. <Emphasis is mine.> The nice thing about the 3PAR implementation is that all its virtualization tables are already in place and utilized. The system simply points these references at another location (i.e. the flash)."

• Large LUNs can now be created on the 3PAR InServ Storage Server and assigned to the host(s) since any hot block of data within that LUN can be moved to the appropriate tier of storage.
• Overhead on the InServ Storage Server is also minimized since it does not need to move 10, 20, 100 or 500 GB LUNs but only 128 MB blocks of data within those LUNs.
• LUN management is simplified since storage administrators do not need to worry about making trade-offs between ease of storage management and their ability to easily manage the performance of the application.
• Manual performance management work to determine when and where to move a block of data can now be done by the system, or "autonomically" in 3PAR terminology.  Threshold alerts are captured and handled on-demand (or on a schedule chosen by the user) for small amounts of application data.  

• Automates and simplifies the use of advanced features on storage arrays. Creating snapshots and clones of virtual machines on storage arrays is becoming a priority for more users as they are needed to protect and recover existing virtual machines (VMs) as well as create new VMs. This new integration between Citrix and 3PAR enables Citrix administrators to centrally create and manage these snapshot and cloning features found on 3PAR systems using the Citrix Essentials virtualization management console.
• More quickly discover and map out their virtual infrastructure. To troubleshoot I/O performance problems on virtual environments means administrators need "At a glance" abilities to first determine how a VM is configured and what resources it is using. Citrix Essentials with its new integration with 3PAR gives administrators this ability. It can quickly discover virtual environments down to the storage level and then map what storage is assigned to individual VMs.
• Quickly implement new VMs or manage service levels of existing VMs. By centralizing management of key 3PAR features under the Citrix Essentials console, a single server or storage administrator can quickly create a new VM and automatically assign the appropriate tier of storage to the VM. Further, if performance starts to spike with an application on an existing VM, based on policies set by the same administrator, the 3PAR InServ Storage Server dynamically moves the data to a higher performing tier of storage.
• Increased VM density on physical servers. The additional insight, information and flexibility that Citrix Essentials provides into their virtual environment combined with the wide-striping and I/O performance of the 3PAR InServ means more VMs can be deployed on existing physical resources. This is possible because wide striping provides lower read latencies when virtual servers page to disk, a frequent performance bottleneck. 
  

By reducing latencies, a given physical server can handle more VMs.  In addition, by having the performance information at their fingertips that Citrix Essentials and 3PAR provides, administrators can be even more aggressive in how many VMs they deploy without exposing their organization to any new risks.

• Reduced capacity requirements for virtualized data centers. By purchasing and consuming storage only as data is written, the ballooning impact of storage purchases to support server virtualization can be cut in half.  In fact, 3PAR will provide a guarantee in writing to support a 50% capacity reduction when converting fully allocated legacy storage to 3PAR thin storage for XenServer deployments.

• Block based interfaces. While some private storage cloud offerings offer iSCSI as a block based interface, this protocol is generally viewed as insufficient for performance intensive applications. So any cloud based offering that is to be used by a data center will need to support protocols such as Fibre Channel (FC) or FC over Ethernet (FCoE) to satisfy its performance demands.
• Multiple tiers of storage. First generation cloud storage offerings primarily use SATA drives to store data because they are high capacity and low cost. The downside is that these drives are relatively low performing. While data center managers certainly desire to store some of their inactive production data on this tier of storage, they also have a percentage of their application data that requires higher performing FC, SAS and even new SSD. So whatever cloud storage solution they deploy has to support all of these tiers of storage capacity.
• Dynamic placement of application data on the appropriate tier of disk at the right time. Just having multiple tiers of storage capacity is not enough. There must be intelligence added into the storage system that automatically places data on the appropriate tier of storage according to the application's needs. This placement needs to be policy driven, done automatically and adjust dynamically to changing application requirements.
• Simplified storage provisioning in block-based environments. This is one of largest hurdles that this emerging data center cloud storage tier has to overcome. The need for this feature is driven by server virtualization where a single physical server may host multiple virtual machines each with its own unique identifier. When this host is connected to a storage cloud, performing tasks such as zoning on FC switches and directors and applying LUN masking to each LUN become numerous and complex. While it can be done manually, it becomes very time consuming and risky as it introduces the potential for human error. To avoid this, the data center tier must provide a means to simplify and automate this very cumbersome and time consuming process.
• Risk-averse. This may sound like an oxymoron in the data center world - how can you implement a cloud storage solution and minimize risk while doing so? However that is exactly what is required in order for these managers to feel comfortable adopting a data center cloud storage solution.

• Identifying and moving the most active application data from current HDDs to the SSD.
• Moving this data back off of the SSD to the HDDs as the data becomes inactive.
• Scaling the SSD solution up as requirements change.
• Automating this data movement so it occurs without human intervention
• Providing overrides and policies so that some data movement is subject to human control.

• Chunklets are little, virtual pieces of physical disk.
• Regions are a narrow stripe of capacity across many chunklets and are assigned to logical disks that are used to create volumes.
• Wide striping takes advantage of these underlying "chunklets" and "regions" by spreading them across multiple disk drives in the 3PAR storage server to improve overall application performance even when lower performing disk drives are used.
• Dynamic optimization then moves regions associated with an entire volume to an appropriate tier of disk based upon their applications' access patterns and usage.

• Availability of SSD to all application data on 3PAR volumes. Because all 3PAR volumes are made up of regions, as soon as SSDs are placed in a 3PAR system and the adaptive optimization is turned on, all 3PAR volumes can be associated with the Adaptive Optimization profile and have access to the SSD drives.

• Selective allocation. Just because SSDs are installed on the InServ Storage Server and adaptive optimization is turned on does not mean a volume gets unfettered access to the SSDs. Administrators can set up policies that control when and how much application data on a volume can reside on the SSD and they can even prohibit certain volumes from storing any data on the SSDs at all.

• Controlled data movement. Using SSDs as a cache sounds appealing until one considers all of the data movement that needs to occur between these different tiers of disk and the overhead that this can introduce on the storage system.

To minimize this, adaptive optimization supports the creation of profiles that consist of specific tiers which have policies associated with them. These policies control when data movement occurs  between tiers for specific volumes such that if a region of data that normally experiences minimal activity suddenly gets busy, that region does not immediately get placed on SSD. Rather it stays on SATA or FC for a defined period of time until it passes a certain threshold.

Conversely, if an extremely active region that resides on SSD goes abnormally dormant for a period of time, 3PAR does not automatically migrate that data to SATA disk. Instead it again leaves the data there until it crosses a specified threshold before it vacates it from the SSD disk.

3PAR has also introduced a feature called QoS Gradients which allows an administrator to bias volumes toward performance or cost resources, depending upon the application service level objectives. A performance gradient would be used for an application with a high SLA or a cyclical application that demands rapid response to a spike in activity. In contrast a cost gradient would be used where cost is the primary objective and an application with have a SATA-stickiness associated with it.  

• Reduced total cost of ownership. Of course, maybe the message that will resonate most with end-users is that adaptive optimization actually lowers storage costs.

Using adaptive optimization, 3PAR can recognize the most active regions of data within volumes and move them to SSD while placing inactive regions of data on lower cost SATA disk. This flexibility gives organizations new found flexibility to start to consider SSD-FC-SATA storage system configurations that look something like 5% SSD, 15% FC and 80% SATA even for their production application workloads.

This combination should serve to minimize the amount of SSD needed, decrease the number of FC drives needed, and increase the usage of SATA drives that will ultimately serve to drive down storage costs by 20% or more.

• Storage capacity is only allocated and consumed (to VMFS and the VMDK) when data is actually written by the application on the VM to the attached storage system.
• Storage capacity does not need to be over-provisioned
• Storage management can remain a function of the storage team for those enterprise organizations that have this separation of duties. However because of 3PAR's integration with VMware's vCenter, organizations can also monitor, manage and report on storage through this management console.

• One provider's guarantee is only applicable when its storage system is used in conjunction with a server virtualization operating system from Citrix, Microsoft and VMware. Further, when one reads this provider's Technical Guide associated with its guarantee, it goes on to specifically EXCLUDE large database and Exchange deployments from this guarantee.  In addition, professional services are a required part of the guarantee program.
• Another storage provider promises new customers a 40% reduction in storage capacity versus their current configuration.  This guarantee is notable in that it makes this promise to customers even if they are already using thinly provisioned volumes. The catch with this guarantee is that it is only measured at the time when their storage system is installed and data is migrated to it.
• The third one guarantees a minimum 80% utilization rate when their storage system is used with no performance degradation. Again, a notable guarantee but one of its caveats is that the customer must notify the storage provider if the customer makes any changes to the environment that may affect the storage system. My own experience tells me that this guarantee is not practical to enforce since often the individuals responsible for the storage are the last ones to hear about changes to applications using the storage system.

• First, 3PAR customers will see at least a 50% capacity savings when converting from existing "fat" volumes on traditional storage arrays to thin volumes on any 3PAR InServ Storage Server. What is important to note is that 3PAR places very few conditions around its guarantee as 3PAR extends this guarantee to all types of application servers whether or not they are virtualized.  No professional services are required, and 3PAR is willing to stand behind its program with a contract versus simply a marketing statement.
• Second, 3PAR makes it possible for this capacity savings not to be a one-time event. One of the reasons thinly provisioned volumes get "fat" over time is because storage capacity that is used and then freed up by the application is never reclaimed by the storage system. 3PAR helps to eliminate that problem with its Thin Engine^TM technology that dedupes "zeros" associated with deleted data on a volume. In this way, organizations will continue to realize capacity savings over time, not just when data migrations are performed.
• Third, there is no need to call 3PAR every time changes are made to the environment to ensure compliance. While 3PAR's Thin Engine^TM technology automates the recapture of freed space, its Thin Built In^TM technology distributes the application data across all available drives in its system. This technique ensures optimal performance for each application without requiring a professional services engagement every time a change to the system is made.

• Increases in the amount of time and effort required to manage the environment
• The inability to definitively associate storage resources with specific virtual machines (VMs)
• The creation of complex, error-prone manual processes that try to do these virtual-to-physical mappings