Archive for the ‘Storage’ Category

Storage Efficiency – Compression

March 4, 2013 2 comments

Storage Compression is one of those efficiency feature that isn’t talked about much. There are lots of ways in which you can implement compression like File System compression, storage array based compression, backup data compression etc. Storage Compression coupled with thin provisioning in CLARiiON/VNX Systems provide thin provisioned pools the much needed Space Reclamation capability that allows white space to be reclaimed. Remember one of the down side of implementing thin Provisioning for Server Virtualization environment was the thin space reclamation and Storage compression exactly brings that capability for the EMC CLARiiON/VNX arrays.

Data written on LUNs are compressed based on meeting set thresholds/parameters. Generally runs as background task. When host reads compressed data, compressed data is decompressed in the Memory and made available to the host. A LUN when enabled for Compression becomes thin provisioned as well. Freed thin-LUN block space is made available for allocation at a storage pool level. Compression is best suited for data luns that contains whitespaces or recurring patterns.

In EMC Arrays, when we enable compression on a LUN, Complete LUN processing is carried out after which data is processed in fixed 64KB increments encoding any recurring strings within data currently being processed and then moves on to next 64 KB increment. If the resulting savings is less than 8 KB, the data would be written in uncompressed format. If the System can free up to 1 GB of 8 KB blocks on a LUN, the space would be returned back to the Storage Pool as free space.  NetApp uses 32K compression groups for scanning.

Most data stored on disk today has at least some redundancy and is easily compacted and lot of space can be reclaimed. Based on my experience at the least 10& of space can be reclaimed but based on data type the value can even go higher.

I have talked of EMC array compression as I have worked on them and pretty much felt the ease of use and its benefits but should pretty much the same with all other supported Storage arrays. Please go through the Vendor documentation for in-depth details and start compressing your data now!


Storage Efficiency – Storage Tiering

February 28, 2013 1 comment

In a traditional Storage allocation model, Storage Requirement for most environments are typically satisfied by allocating the Storage based on the Capacity requirement rather than Performance because of either not knowing the Performance requirement of the application/environment during its initial deployment phase or due to lack of understanding of the importance of RAID and associated Disk penalties.

Consider this, if there is a requirement to host 500 VMs of 18 IOPS each and 100 GB Capacity, We are looking at a Storage requirement of 6 TB (5 *100 GB + 25% Buffer Overhead) & 9000 IOPS. Considering a Read:Write ratio of 70:30 in RAID 5, we are looking at IOPS Requirement of 17100 which can be satisfied by 95 numbers of 15K drives. Consider RAID 5 configuration with 4+1 Drives for these 95 drives to satisfy the IOPS Requirement, We would be left with roughly 38 TB of Usable Space. But our capacity requirement was only 6 TB. How do we satisfy the IOPS and still right size for Capacity or how do we size for Capacity and still match the IOPS Requirement? Are we not spending additional $$$ to accommodate Performance requirements when most of the virtual workloads would not be active all the time?

Storage Tiering is recommended when you want maximum Efficiency at lower cost. Simply put, automating data migration/placement within different tiers of storage according to workload. If we consider the same example referred above, instead of placing in 95 numbers of 600 GB drives, Can we look at an alternate approach of using multiple drive types in a Single Storage Pool like 5 numbers of SSDs along with 27 numbers of 900 GB 10K SAS plus 16 numbers of 2 TB  NL-SAS. SSD & SAS Drives would serve the performance requirements whereas the NL-SAS would serve the capacity requirement at lower cost. Active data set within the pool would be automatically migrated to SSD/SAS drives whenever they get active and inactive data would get into the NL-SAS drives. There are a lot of advantages in this model since you can keep expanding your Storage Pool with additional drives as and when required online. Data placement would be handled automatically by the Storage Array and with Powerful SSD based Cache that are available these days, Storage Tiering is the way to move forward for high-capacity environments.

For VMware Environments, you have an additional choice of enabling and making use of SDRS in cases where Storage Array doesn’t have the capability or licenses for Storage Tiering. This can also do a limited level of automatic placement of VMs between datastore and in case where datastore are from different tires of Storage Systems, this can also be used as a Virtual Storage Tiering.

Benefits of Storage Tiering

  • Maximize Storage Efficiency at Lower Cost
  • Simplified administration
  • Decrease Drive Counts on the Array
  • Cost Reduction
  • Improve performance with wide striping on larger Storage Pools

Remember to understand your Storage array capabilities and understand its limitations before you implement.

Storage Efficiency – Thin Provisioning

February 26, 2013 5 comments

Traditionally, we allocate storage required for an environment upfront which is also referred as thick provisioning or fat provisioning. For Example, when there is a request for a 100 GB Virtual disk space, we go ahead with creation & allocation of 100 GB space. But have you analyzed how long would it take for that 100 GB Space to be consumed?

  • If this is the case for a Single VM, Imagine the space that is being allocated to multiple virtual servers in the environment and how much space goes underutilized? In cases where they are optimally utilized, how long before they get consumed completely? Can we use the space for that time being for some other use cases or for provisioning more VMs?
  • Another use case is optimizing the free space in datastore. Depending on environment there is a certain amount of buffer space that is reserved in every datastore. For Example, if we consider 20% as buffer space, in a 2 TB datastore we would be left with 400 GB free space per datastore. If you environment has 25 datastore of 2 TB each, you would be approximately leaving 10 TB (400 GB * 25) of unused space. Can we optimize this 10 TB space?

Thin Provisioning help increase storage utilization by enabling dynamic allocation and intelligent provisioning of physical storage capacity. Thin Provisioning is an On-Demand allocation model where storage is allocated based on request from server rather than allocating everything upfront.

Thin Provisioning can be implemented in a Virtualized environment in either of the two ways or combination of both.

  1. Thin Provisioning at Hypervisor layer
  2. Thin Provisioning at Storage Array

Thin Provisioning at Hypervisor layer would mean that you present a thick LUN from Storage array or create datastore from your local HDDs and then do thin provisioning of virtual hard disk on the datastore. This would help you provision more VMs per datastore since space saved is at datastore level. You can look at Hypervisor based thin provisioning when you use local attached HDDs or your storage array doesn’t support the feature.

Thin Provisioning at Storage array can be implemented when your storage array supports the feature and you have appropriate license for it if need be. Typically you create a Storage pool and present Thin LUN back to your Hypervisor and you create VMs that are thick provisioned (Lazy Zeroed). Thin LUN presented from the Storage array would grow only when the data in the provisioned virtual HDDs grows. One would typically create multiple Thin luns from Storage Pool and present back to hypervisor for allocation. Advantage of doing thin provisioning at Storage array is that space saved an either be used back for the same hypervisor/cluster or for a different use case.

Whatever be the option you choose, it is imperative that you monitor any thin provisioned environment carefully for growth and do proper capacity planning. Also please be mindful of impact on the disk performance of the workload. Would not recommend thin provisioning if your workload is a critical disk intensive workload. There are lot of non-critical workloads that can be deployed on Thin Provisioned LUNs saving your Organization lots and lots of space which in return would mean lots of $$$ Savings !!

Storage Efficiency & Virtualization

February 25, 2013 Leave a comment

Virtualization – To unleash the full benefits and capabilities of any Hypervisor in the Industry today,One of the key requirement is Storage. Storage plays a critical role in Virtualization and while lot of focus is on Big Data , We must not over-look the benefits & challenges of storage for Virtualization. While Storage is considered de-facto in many environments , there are still environments that do not use storage for their entire virtualization layout more so because of cost per GB than being ruled out of technical reasons.

Also in environments where there is wide-spread adoption of Storage for Virtualization , there are a lot of opportunities for increasing the efficiency of the Storage that is being used. VM Sprawls and Private Cloud set-up leads to large number of VMs being consumes in Organizations and while Hypervisor techniques can help handle the over-subscribed compute and memory, Storage Efficiency features at the array level would help you optimally use the back-end storage.

There are 4 critical opportunities available for Storage Efficiency. In a Series of posts , I will share my thoughts as an administrator on these key features , their benefits and pit-falls to watch out for.


Based on the Storage Vendor , the Storage efficiency features supported may vary along with the implementation methodology. But the opportunities for increasing the efficiency in back-end Storage used for Server Virtualization is immense and would recommend you all to try out ( In case you haven’t tried yet). Please do refer your Vendor’s documentation and understand the features supported and its implementation methodology. With Every technology, there is also going to be some pitfalls and please be sure to watch out for them and set-up mechanisms to avoid them.

FAST Cache Configuration Best Practice

July 27, 2011 13 comments

EMC’s FAST Cache has been one of the most talked about technology in recent times due to the much needed Caching capabilities that it brings to EMC CLARiiON series of arrays. In a nut shell , FAST Cache is a collection of Enterprise Flash Drives that sits between Storage System’s DRAM Cache and Disks. FAST Cache holds a large percentage of the most frequently used data in high performance FLASH drive. While the response time of DRAM Cache is in nanoseconds , response time of FAST Cache is in terms on milliseconds. In my previous posts , I had explained on the Performance benefits that one could derive from FAST Cache on various work loads like VDI , Database etc..

We had an interesting discussion recently on the Configuration Best Practice for disks that constitute FAST Cache. Remember FAST Cache is a collection of Enterprise Flash Drives or SSD configured in RAID to provide Read & Write Caching capabilities. Scanning through EMC KB , Came across an Primus (ID: emc251589) on the Configuration Best Practice for FAST Cache and thought of sharing the same with the larger audience so that it could be useful when you configure the same in your environment. The Primus is being constantly updated and would recommend you to look out for updated information by logging on to powerlink.

Best Practice :

  • The order that the drives are added into FAST Cache is important, because that will dictate which drives are Primary and which are Secondary. The first drive added is the first Primary, the next drive added is its Secondary, the third drive is the Primary for the second mirror and so on.
  • For highest availability, ensure that the Primary and Secondary for each RAID 1 pair are on different buses (i.e. not just different enclosures on the same bus).
  • The FAST Cache drives can sustain very heavy workloads, but if they are all on the same bus, they could completely saturate this bus with I/O. This would especially be an issue if the drives were all on bus 0, because this is used to access the vault drives. Spread the FAST Cache drives over as many buses as possible.
  • Avoid using the Vault drive DAE, if possible, for the FAST Cache (DAE 0_0) on a VNX, because this would then use a different SAS lane than the vault drives. It is acceptable to use bus 0 for some, but preferably not all, of the FAST Cache drives (unless the CLARiiON only has a single backend bus).
  • As these drives are individual RAID 1 groups, the Primary drive in each pair will be more heavily accessed than its Secondary mirror, because read I/O operations only need to access one of these drives.
  • It is easiest to be certain of the order in which these drives are bound by using the following CLI command to bind the FAST Cache                                                                                                                                                   Naviseccli cache -fast -create -disks disksList -mode rw -rtype r1
  • The FAST Cache driver has to track every I/O in order to calculate whether a block needs to be promoted to FAST Cache. That adds to the SP CPU utilization. Disabling FAST Cache, for LUNs unlikely to need it, will reduce this overhead.
  • After a few hours, FAST cache will be using nearly all of the available drive capacity of its flash drives. For every new block that is added into FAST cache, another must be removed and these will be the blocks that are the oldest in terms of the most recent access. If there is not much FAST cache capacity (in comparison to LUN capacity), blocks that are frequently accessed at certain times of day will have been removed by the time they are accessed again the next day. Restricting the use of FAST cache to the LUNs, or Pools, which need it the most, can increase the probability of a frequently accessed block still being in FAST cache the next time it is needed.

Here are some general rules of thumb for using FAST Cache:

  • Do not enable FAST Cache on all reserved / private LUNs, apart from metaLUN components.
  • Do not enable FAST Cache on MirrorView/S Secondary mirror LUNs or on Pools which contain these LUNs.
  • Do think about the type of data on a LUN and consider if FAST Cache is needed. For example log files are generally written and read sequentially across the whole LUN. Therefore these would not be good candidates for FAST Cache. Avoiding using FAST Cache on unsuitable LUNs reduces the overhead of tracking I/O for promotion to FAST Cache.
  • Do not put all FAST Cache drives on a single bus (apart from on CLARiiONs with only one backend bus per SP, such as the CX4-120).
  • Do locate the Primary and Secondary mirrors for each RAID 1 pair of FAST Cache drives on different buses, to improve Availability. The order the drives are added into FAST Cache is the order in which they are bound, with the first drive being the first Primary; the second drive being the first Secondary; the third drive being the next Primary and so on.

NOTE / DISCLAIMER : Please do check with EMC Technical / Support Team before making any changes to FAST Cache configuration in your environment. These are general best practice shared by EMC and might vary depending on your environment.

Categories: Storage Tags: ,

CLARiiON Storage Replication with Recover Point

July 26, 2011 3 comments

One of the main aspects of any Disaster Recovery strategy has to be Storage Replication considering all critical applications & data are generally hosted on a highly available SAN Infrastructure. With growing influence of Virtualization on Data Center , Number of  Servers that are virtualized has been increasing and will continue to grow and replicating these VM’s is also critical. VMware provides SRM ( Site Recovery Manager ) as a DR solution for VMware VM’s in conjunction with Array Replication Technologies.Integration of Storage Replication technology with Products like VMware SRM which provides Disaster Recovery solutions for Virtual Machine’s would go a long way in automating the DR process.

Replication can be local or remote and also can be synchronous or Asynchronous.  Based on various tests that we carried out for both local and remote replication ,  Recover Point seems to be a better solution and in this post I would try and share my thoughts on the same.

There are 3 EMC Replication technologies that can be utilized for replication of data that is available on a CLARiiON array and they are :

  • Snap View
  • Mirror View
  • Recover Point
Below snapshot from EMC RecoverPoint/SE Applied technology white paper shows the differences between various Storage Replication technologies of EMC :
There are two editions of Recover Point –
  • RecoverPoint/SE – CLARiiON Specific
  • Recover Point  – Can be used across heterogeneous Storage
Below snapshot shows the differences  between Recover Point & RecoverPoint/SE from EMC RecoverPoint/SE Applied technology white paper
Why is Recover point a better Storage Replication Technology ?
  • Support for federated database / federated OS / federated Storage Systems. RPA can be used across all LUNs from different Storage vendors like EMC , HP , IBM etc. ..
  • Quick & Guaranteed Recovery even in case of a rolling disaster to a point in time copy from the journal
  • Huge bandwidth savings as a result of de-dupe and compression.
  • Application aware solution with agents available for Exchange / SQL / Hyper-V and VMware SRM ( Automatic Failover and failback)
  • Supports and recognizes Thin provisioning. Thick LUN can be resynced to a thin LUN in the remote site.
  • Recover Point can do Synchronous Replication locally and at the same time do a Asynchronous replication with the remote storage system.
  • Enable Read / Write Access to the Remote Replica Volume w/o requiring Clone or Snapshot ( Mirror View requires Clone/Snap of Remote LUN to be presented to host for verification). Changes upto 40GB or 20% of journal Size is permitted.
  • Usage of Write splitters at CLARiiON end and Host End . Duplicates any incoming writes and send it across to RPA appliance for immediate journaling. With splitters we can replicate LUNS of upto 32 TB and w/o splitters maximum supported LUN size is 2 TB.
  • Independent Recovery ( In spite of doing a simultaneous local replication and remote Asynchronous replication )
  • Replicates small aperture of snaps frequently and this would help us in reducing data lag
  • RPA Supports almost all existing CLARiiON Arrays whereas Mirror View would require iSCSI ports on CLARiiON array.
  • With EMC Cluster Enabler for RPA , we can have geographically dispersed MS cluster that is supported
VMware SRM & Recover point Integration means Administrators can run mock DR drills tests right from SRM console without the need to change settings in Recovery Point console and that’s Cool !
Categories: Storage Tags: , ,

Support for PST in Network Drives

July 26, 2011 1 comment

One of the main challenges on VDI has always been around use of Outlook PST’s.Although PST’s are meant to be used as archiving or backup solutions , Smaller mail box size in large Organizations meant that People use PST all the time. I would not like to get into a discussion if one should use PST or not. As a VDI administrator ,  I might be against the use of PST’s but then decision varies from Organization to Organization and we have to live with it. PST’s are generally stored on Home drives ( Data Drive) that are presented to a User in a VDI session. Predominantly , Home Drives are carved out of NAS or on a more generic term “Network Drives”.  Until now , PST’s accessed over Network was not a supported Microsoft Configuration  which meant that you cannot log a case with Microsoft for any issues pertaining to use of PST’s on Network Drives.

Starting with Outlook 2010 , Microsoft has termed that “Network access of PST and OST as a Supported configuration” under specific conditions namely,

  • A high bandwidth/low latency network connection is used.
  • There is single client access per file (one Outlook client per .pst).
  • Windows Server 2008 R2 Remote Desktop Session Host (RDSH) and Virtual Desktop Infrastructure (VDI) are used.
This is a welcome change from a VDI Administrator perspective. There are always advantages and disadvantages of using PST on VDI and you would be the best person to judge if it’s suitable to your environment. Sometimes you don’t have a choice !
More details on Support for PST in Network Drives can be found in this Microsoft KB and would recommend reading the Planning Consideration White paper that can be found here.