Around the Storage Block Blog
Find out about all things data storage from Around the Storage Block at HP Communities.

HP Tech Day: HP 3PAR and file-based portfolio

During our HP Tech Day late last week, we had someone take notes of the sessions.  These notes provide a summary of what was discussed.  Also in this post is videos of the sessions described.

 

HP 3PAR Overview

Jim "JR" Richardson

 

The 3PAR customer presentation focuses on three words: Multi-tenant, Efficient, Autonomic. These perfectly describe what HP 3PAR does in your converged storage. But sometimes the meaning of those words get lost so JR talked about their meaning. 

 

Multitenant has been the goal for a long time, but has been expensive and hard to change and siloed inside the sheet metal. So open systems exploded because less expensive and easier. We saw SANs come together to try to pull them all in. We saw virtualized storage.  But you need is a ground-up approach to a platform that can handle lots of apps without worrying about what the front end asks, you just deliver it.

 

This is the perfect fit for orgs with diverse workloads to handle large and small blocks without major surgery on the infrastructure. One of the key technologies is an ASIC. If you have lots of small random ops you should strike that across resources. Bigger assets, you need a bigger pipe. ASIC gives you big bandwidth, low latency, big pipe to strike the data across all the controllers without a penalty and sends data where it needs to go in the cluster. It does RAID-5, 6 XOR (exclusive OR) calculations. We built in provisioning into ASIC; CPUs can think about where the data goes.

 

3PAR can grab “chunklets” -- small amounts of data until it’s striped across as many disks as it needs; every other controller does the same across however many disks. Does it in less than 10 seconds. From the core up, the way 3PAR does things is agnostic to thin or not thin. It’s mixed workload – multitenancy.

 

Efficient: 3PAR didn’t invent thin provisioning, but it did revolutionize storage industry. Now every major vendor has some thin provisioning, though sometimes it’s bolted on. 3PAR is much more efficient than, say, Hitachi or EMC, at 16KB allocation. You don’t have any predefined pools; you have a policy of how storage should be consumed. No pre-allocation, so you don’t need to think too much about management.

 

Autonomic:  If you climb some stairs, automatically your heart rate goes up. You don’t have to think about it, it just adjusts – it’s autonomic! Same way, the array has a bunch of smarts built into it that removes the smarts of the user! (laughter). Takes out the drudge work; performance, stripe settings are automatically set to give you the best performance. Can also monitor what’s going on; the busy bits will go to fast storage, less actives goes to slow.

 

The 3PAR architecture is not cache-centric. The thinking is geared to not having a large cache. Rarely hits limits on CPUs.

 

 

You can learn more about HP 3PAR at www.hp.com/go/3PAR

 

File-based portfolio overview

 

Jim Hankins, product manager

 

There are two families of products:

  •  X1000 (single server appliance-based NAS), X3000 (gateway products in front of a SAN to give file access to block-based arrays), X5000 (2-server device, clustered together for HA and built in storage).  All of these are based on Microsoft Windows Storage Server 2008 R2
  • Plus the X9000, a scale-out product based on IBRIX

 

Mark Thomas, architect introduces the IBRIX X9000; 3 products in the portfolio:

  • X9320: two nodes, comes with storage
  • X9720: up to 1.3PB max, based on BladeSystem C7000
  • X9300 Storage Gateway (front end to a network array)

 

IBRIX software is a single namespace that allows you to tier: Fast storage, slow storage; policy-based storage lets you decide where storage should reside during it's lifecycle.

 

Scale-out storage environment: across the product line you can continue to grow and grow the classifications of storage you need and still provide a single file system segmented across the storage.

 

Transparent Data Tiering

  • User defined tiers with no limits
  • Policy based file movement
  • No stubs or symbolic links needed
  • Performed in the background

Enterprise Data Services:

  • Continuous Remote Replication: fully replicates to another node
  • Automatic Storage Balancing: dynamically spread workload across storage tiers within the cluster
  • Snapshots: a versioning mechanism, gives view of present and past states
  • Stats tools: historical graphs
  • Retention policy: data-based retention mechanism; provides control over when files can be deleted
  • WORM: write once, read many - file immutability for retained files
  • Data Validation: checksum signature associated with retained files with periodic data verification
  • Data Evacuation: transparent migration off re-purposed or decommissioned platforms
  • Policy Based Tiering: set preferred tier where newly created files will be stored as well as set policies for tiering job to move files; policies based on file attributes.
  • High Availability: active / active storage architecture
  • Single Name Space: up to 16PB

Robert Thompson  Architect

X5000 G2 Network Storage System: Converged Storage optimized for file serving

 

  • The industry's first two node Windows failover cluster in a box, based on ProLiant blade servers with shared storage in a single chassis.
  • Primary use case is CIFS in a Windows environment; also does NFS, iSCIS - basically anything you can do with Windows.
  • Advanced storage management features includes file dedup, file classification, quotas and storage reporting
  • Drawer holds up to 16 hot swap 6 Gbps 3.5” dual port SAS drives
  • Storage expansion Max capacity 128TB using 2TB drive, maximum drive count 116 (16LFF + 100 SFF drives)

Connectivity

  • 2-10 GbE SFP+ ports per blade included at no additional cost
  • 5-1GbE ports per blade
  • Redundant fans and power supplies

 

 

To learn more about the file based portfolio go to www.hp.com/go/NAS

Comments
nate(anon) | ‎02-16-2012 05:45 PM

3PAR touted that 16kB allocation forever it seems like. While technically true at a volume level it allocates at 16kB increments in the grand scheme of things larger allocations aren't a big deal, I mean take HDS which is 42MB I think, say you have 100 volumes, that's just 4.2GB of space. Your array with 100 volumes may have 10TB of space on it, so that 4.2GB of overhead is really a rouding error.

 

3PAR has another level of allocation from the common provisioning groups which are sort of like storage pools without reservations. thin proviisoned volumes draw data from the CPGs. CPGs allocate in chunks of typically 32GB of I remember right (actual numbers can vary depending somewhat on the platform and number of nodes). So the 3PAR platform can be very efficient if you have a small number of CPGs, but the efficiency drops when your CPG count goes up.

 

Not that 32GB is that big of a deal either for a storage pool. You can, if you want have a single storage pool for the entire array. I have several, I use CPGs for organizational purposes, as well as their default performance/availability control (RAID level, data radial placement etc). My company's tiny F200 array (32 disks) is not yet in production, don't have a lot of data written to it at this point looks like 2.2TB of raw data consumed by CPGs at this point. I have a little shell script which counts the micro raid arrays and there are 3,206 RAID arrays on the system now.

 

Now where 3PAR's efficiency shines as far as disk savings go really is in the high utilization rates (made possible in large part due to chunklets and sub disk RAID which is made possible entirely becuase of the ASIC design - Intel CPUs couldn't manage 10s of thousands of RAID arrays otherwise IBM XIV would be able to run RAID 5), which give 1000x more bang for the buck than the 16kB allocation could ever dream of.

 

Uhammer(anon) | ‎02-17-2012 06:44 PM

Good summary nate.  Warning, I work for HP so this is a little biased. OK, in truth I came over from the 3PAR acquisition so I'm a lot biased.

 

There is a little difference though.  When HP talks about a 16KB allocation size vs. other allocation size it is to compare what the minimum amount of capacity consumed on a write is.  With 3PAR it is 16KB.  When you do something like format a UFS (ext2 and 3 also work this way) there is metadata sprinkled throughout the filesystem.  With the 3PAR this will only take up 16KB of space.  If you have a larger allocation then this metadata will consume a lot more physical storage.  As an example if you have create a volume of any size and export it to a Linux host and put a new filesystem on that volume you will chew up 1%ish of the capacity.  I have seen the results on other arrays and it is significantly higher because they are chewing up such large blocks on initial small writes.  Granted as the filesystem fills up the actual consumed gets closer to actually allocated but isn't the point of Thin Provisioning to make allocated as small as possible even if the space isn't consumed.

 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the community guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
25+ years experience around HP Storage. The go-to guy for news and views on all things storage..


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation