Comments on: Who let the cow in? http://blog.nigelpoulton.com/who-let-the-cow-in/#utm_source=feed&utm_medium=feed&utm_campaign=feed with nigel poulton Tue, 20 Dec 2011 19:37:54 +0000 http://wordpress.org/?v=2.8.6 hourly 1 By: Nigel (mackem) http://blog.nigelpoulton.com/who-let-the-cow-in/comment-page-1/#comment-236 Nigel (mackem) Fri, 13 Jul 2007 09:38:06 +0000 http://blogs.rupturedmonkey.com/?p=104#comment-236 <p class="MsoNormal"><span>Billy,</span></p> <p class="MsoNormal"><span>I think the main point about suitability for enterprise customers was the fact that the snapshot is reliant on the primary volume. <span> </span>If the primary volume fails then so do all snapshots. <span> </span>And the Hitachi boxes allow for up to 64 snaps per primary volume (although that is a marketing number) people often have between 10 and 20 or so. <span> </span>Whereas a full block level copy, like a snapclone on the EVA, is totally independent. <span> </span>This is more suited to the reliability requirements of enterprise systems.</span></p> <p class="MsoNormal"><span>Im also not a big fan of using snapshots for backups unless a lot of data has been updated to the snapshot.<span>  </span>Otherwise you are still placing a heavy read load on your primary volume.</span></p> Billy,

I think the main point about suitability for enterprise customers was the fact that the snapshot is reliant on the primary volume.  If the primary volume fails then so do all snapshots.  And the Hitachi boxes allow for up to 64 snaps per primary volume (although that is a marketing number) people often have between 10 and 20 or so.  Whereas a full block level copy, like a snapclone on the EVA, is totally independent.  This is more suited to the reliability requirements of enterprise systems.

Im also not a big fan of using snapshots for backups unless a lot of data has been updated to the snapshot.  Otherwise you are still placing a heavy read load on your primary volume.

]]> By: billy bathgates http://blog.nigelpoulton.com/who-let-the-cow-in/comment-page-1/#comment-235 billy bathgates Wed, 11 Jul 2007 20:48:00 +0000 http://blogs.rupturedmonkey.com/?p=104#comment-235 <p>Not sure why CoW would be seen as intrinsically non-suitable for the enterprise. Shouldn't a CoW volume be just as reliable as the parent volume, assuming they share the same raid-level  (most of my experience is with EVA snapshots, which are CoW, but can have less redundancy than the parent volume if desired) ?</p> <p>Nigel, it's only the high-end DS (8300 I think is the model) which has the p570 aix-based controllers.  I don't think the baby-shark (ds6800) is engenio based, that's the ds4xxx series.</p> Not sure why CoW would be seen as intrinsically non-suitable for the enterprise. Shouldn't a CoW volume be just as reliable as the parent volume, assuming they share the same raid-level  (most of my experience is with EVA snapshots, which are CoW, but can have less redundancy than the parent volume if desired) ?

Nigel, it's only the high-end DS (8300 I think is the model) which has the p570 aix-based controllers.  I don't think the baby-shark (ds6800) is engenio based, that's the ds4xxx series.

]]> By: Nigel (mackem) http://blog.nigelpoulton.com/who-let-the-cow-in/comment-page-1/#comment-234 Nigel (mackem) Fri, 06 Jul 2007 10:20:23 +0000 http://blogs.rupturedmonkey.com/?p=104#comment-234 Anil,<br /><br />I did see an article on The Register re the IBM bricks.  My gut feeling on that is that its a good thing (as long as enough cash is there to fund it going forward) as Im not a fan of IBM storage.  They dont seem to put the effort in - the DSrange being a pair of AIX servers and some disk shelves and much of the rest of the range being rebadged Enginio and NetApp......<br /><br />Nigel Anil,

I did see an article on The Register re the IBM bricks.  My gut feeling on that is that its a good thing (as long as enough cash is there to fund it going forward) as Im not a fan of IBM storage.  They dont seem to put the effort in – the DSrange being a pair of AIX servers and some disk shelves and much of the rest of the range being rebadged Enginio and NetApp……

Nigel

]]> By: Anil Gupta http://blog.nigelpoulton.com/who-let-the-cow-in/comment-page-1/#comment-233 Anil Gupta Fri, 06 Jul 2007 03:15:32 +0000 http://blogs.rupturedmonkey.com/?p=104#comment-233 <p>Nigel,</p> <p>I don't think there is a debate between enterprise or midrange any longer. More and more data is being stored on midrange class and more and more performance is being extracted from enterprise class. Also, the trend you are seeing with smaller "enterprise class" being selected for larger "midrange class" may have to do more with requirement of the performance vs. storing data.</p> <p>IMO, the debate has moved on to scale-up vs. scale-out in storage. With my interest in 3PAR, Isilon, Amazon S3 and Google storage, you know where my bias lies. ;-) Did you hear about IBM bricks will be productize using a separate company?</p> <p>As for availability there is no magic bullet or one solution for all, all options whether snapshot vs. split-mirror or fast cows vs fast and slow cows have their own pros and cons.</p> <p>Anil</p> Nigel,

I don't think there is a debate between enterprise or midrange any longer. More and more data is being stored on midrange class and more and more performance is being extracted from enterprise class. Also, the trend you are seeing with smaller "enterprise class" being selected for larger "midrange class" may have to do more with requirement of the performance vs. storing data.

IMO, the debate has moved on to scale-up vs. scale-out in storage. With my interest in 3PAR, Isilon, Amazon S3 and Google storage, you know where my bias lies. ;-) Did you hear about IBM bricks will be productize using a separate company?

As for availability there is no magic bullet or one solution for all, all options whether snapshot vs. split-mirror or fast cows vs fast and slow cows have their own pros and cons.

Anil

]]> By: Nigel (mackem) http://blog.nigelpoulton.com/who-let-the-cow-in/comment-page-1/#comment-232 Nigel (mackem) Wed, 04 Jul 2007 14:17:26 +0000 http://blogs.rupturedmonkey.com/?p=104#comment-232 Ive also shared the same hesitance over the availability, or should I say lack of availability, of the snapshots if the primary/source volume fails.  Although on enterprise kit the chances of the primary volume failing due to the storage subsystem is unlikely, I certainly would not like to have to tell a customer that they had also lost all of their snapshots!!  That said, though Im starting to warm to it for certain purposes.<br /><br />As for the ACoFW that Barry mentions on the DMX (let me rush to the patent office to copyright that catchy acronym) I’m not actually sure how the USP handles these writes.  I would image they are also handled asynchronously although hand on heart I can’t say for certain – so much for me being a world authority on CoW ;-)<br /><br />And on the point of serverless backup.  That’s another one that I have never seen done.  I know Snig was looking into this a while ago but I never asked if he got it going? Ive also shared the same hesitance over the availability, or should I say lack of availability, of the snapshots if the primary/source volume fails.  Although on enterprise kit the chances of the primary volume failing due to the storage subsystem is unlikely, I certainly would not like to have to tell a customer that they had also lost all of their snapshots!!  That said, though Im starting to warm to it for certain purposes.

As for the ACoFW that Barry mentions on the DMX (let me rush to the patent office to copyright that catchy acronym) I’m not actually sure how the USP handles these writes.  I would image they are also handled asynchronously although hand on heart I can’t say for certain – so much for me being a world authority on CoW ;-)

And on the point of serverless backup.  That’s another one that I have never seen done.  I know Snig was looking into this a while ago but I never asked if he got it going?

]]> By: the storage anarchist http://blog.nigelpoulton.com/who-let-the-cow-in/comment-page-1/#comment-231 the storage anarchist Wed, 04 Jul 2007 02:46:24 +0000 http://blogs.rupturedmonkey.com/?p=104#comment-231 With the latest code release, DMX minimizes the write performance impact of the Copy on Write overhead by scheduling the copy to occur asynchronously to the write that initiates the copy - an approach that leverages the large global cache architecture and that wouldn't work as well with most mid-tier platforms. (a technique called ACoFW - Asynchronous Copy on First Write...)   Read performance isn't really impacted all that much with CoW Snaps, especially if the pre-fetch algorithms are appropriately tuned (as we've done for DMX). For sequential reads, it doesn't really matter where the "next" track is actually stored - the trick is to get the read queued to the drive before the read comes from the host. And random I/O is virtually unaffected - another feature of the DMX pre-fetch algorithms.   BTW - The real limitation of CoW replicas isn't so much performance. Instead, you have to balance the capacity savings you get for multiple replicas against the availability risks of having multiple LUNs dependent upon the same physical devices for all the data that has NOT changed...a double-drive failure in the primary RAID 5 group(s)  could not only cost you your primary logical device, but ALL of your recovery points as well. RAID 6 is a reasonable insurance policy against that risk.   Note that both wide-striped Thin Provisioning and DeDup technologies create similar "hyper-dependencies" of a large number of logical devices - here too one must balance the risks of a dual drive failure within a single RAID group...if it should ever happen, you've lost a portion of virtually every single logical device in your system. For CoW Snapshots, the high probability risk of data loss might be acceptable; the risks may not be justifiable if you're talking about the primary copy of your LUNs in a thin provisioned deployment.. With the latest code release, DMX minimizes the write performance impact of the Copy on Write overhead by scheduling the copy to occur asynchronously to the write that initiates the copy – an approach that leverages the large global cache architecture and that wouldn’t work as well with most mid-tier platforms. (a technique called ACoFW – Asynchronous Copy on First Write…)
 
Read performance isn’t really impacted all that much with CoW Snaps, especially if the pre-fetch algorithms are appropriately tuned (as we’ve done for DMX). For sequential reads, it doesn’t really matter where the "next" track is actually stored – the trick is to get the read queued to the drive before the read comes from the host. And random I/O is virtually unaffected – another feature of the DMX pre-fetch algorithms.
 
BTW – The real limitation of CoW replicas isn’t so much performance. Instead, you have to balance the capacity savings you get for multiple replicas against the availability risks of having multiple LUNs dependent upon the same physical devices for all the data that has NOT changed…a double-drive failure in the primary RAID 5 group(s)  could not only cost you your primary logical device, but ALL of your recovery points as well. RAID 6 is a reasonable insurance policy against that risk.
 
Note that both wide-striped Thin Provisioning and DeDup technologies create similar "hyper-dependencies" of a large number of logical devices – here too one must balance the risks of a dual drive failure within a single RAID group…if it should ever happen, you’ve lost a portion of virtually every single logical device in your system. For CoW Snapshots, the high probability risk of data loss might be acceptable; the risks may not be justifiable if you’re talking about the primary copy of your LUNs in a thin provisioned deployment..

]]> By: Chris M Evans http://blog.nigelpoulton.com/who-let-the-cow-in/comment-page-1/#comment-230 Chris M Evans Tue, 03 Jul 2007 23:00:45 +0000 http://blogs.rupturedmonkey.com/?p=104#comment-230 For both the EMC and HDS versions I'd like to see an idea of the performance degredation from using the technology.  Clearly for writes the penalty is on saving the "about to be changed" block and for reads the risk is that the COW and original are both required to be read and potentially with different profiles.  Up to now I've never recommended COW due to the uncertainty on performance.  For both the EMC and HDS versions I’d like to see an idea of the performance degredation from using the technology.  Clearly for writes the penalty is on saving the "about to be changed" block and for reads the risk is that the COW and original are both required to be read and potentially with different profiles.  Up to now I’ve never recommended COW due to the uncertainty on performance. 

]]> By: the storage anarchist http://blog.nigelpoulton.com/who-let-the-cow-in/comment-page-1/#comment-229 the storage anarchist Tue, 03 Jul 2007 22:48:21 +0000 http://blogs.rupturedmonkey.com/?p=104#comment-229 FWIW - Symmetrix DMX has supported so-called CoW replicas (we call them space-saving Snapshots) with TimeFinder/Snap since 2004 (Enginuity 5670+). Snaps can be configured via Solutions Enabler, CLI, both the ControlCenter Symmetrix Manager and Symmetrix Management Console GUIs, and even SMI-S (I think).   A significant percentage of our enterprise customers use these for a variety of applications, from backup/recovery points to test & dev against "live" data. FWIW – Symmetrix DMX has supported so-called CoW replicas (we call them space-saving Snapshots) with TimeFinder/Snap since 2004 (Enginuity 5670+). Snaps can be configured via Solutions Enabler, CLI, both the ControlCenter Symmetrix Manager and Symmetrix Management Console GUIs, and even SMI-S (I think).
 
A significant percentage of our enterprise customers use these for a variety of applications, from backup/recovery points to test & dev against "live" data.

]]> By: stephen2615 http://blog.nigelpoulton.com/who-let-the-cow-in/comment-page-1/#comment-228 stephen2615 Tue, 03 Jul 2007 22:25:51 +0000 http://blogs.rupturedmonkey.com/?p=104#comment-228 Nigel,   Interestingly enough, I have used COW for a very large database on a USP 1100 just because it was so large.  SI was used for a consistent daily backup because it took so long to backup to tape but COW was used to offer smaller time window "snapshots".  Mind you I never actually used it to do any sort of recovery but it was there and made management feel all warm and fuzzy.   I must admit the training on it was less than extensive.   The student guide on COW was not too bad but we had no lab doco.  It was given as an after thought at the end of the last day because I asked for it.  I had to write down some steps in the back of my notebook.  Let me give what I was given.   Identify LDEV's for pool disk   Create pool   Identify  PVOL for COW   Create V-VOL (max 64 for each P-VOL)   Use SI Interface - > Select P-VOL and assign V-VOL as secondary volume   Manage from SN or CCI.   Perhaps COW normally falls in the same category as Serverless Backup which is too complex to get to work..  It surely would be a wonderful thing if it did work.   Stephen     Nigel,
 
Interestingly enough, I have used COW for a very large database on a USP 1100 just because it was so large.  SI was used for a consistent daily backup because it took so long to backup to tape but COW was used to offer smaller time window "snapshots".  Mind you I never actually used it to do any sort of recovery but it was there and made management feel all warm and fuzzy.
 
I must admit the training on it was less than extensive.   The student guide on COW was not too bad but we had no lab doco.  It was given as an after thought at the end of the last day because I asked for it.  I had to write down some steps in the back of my notebook.  Let me give what I was given.
 
Identify LDEV’s for pool disk
 
Create pool
 
Identify  PVOL for COW
 
Create V-VOL (max 64 for each P-VOL)
 
Use SI Interface – > Select P-VOL and assign V-VOL as secondary volume
 
Manage from SN or CCI.
 
Perhaps COW normally falls in the same category as Serverless Backup which is too complex to get to work..  It surely would be a wonderful thing if it did work.
 
Stephen
 
 

]]>