<   Previous Post  Introducing the IBM...
Next UK (EU) SVC...  Next Post:   >

Comments (72)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

31 mitchellm3 commented Permalink

Barry, <div>&nbsp;</div> With the move to start using thin provisioned volumes with VMware, we are liking the ability of the storage to "Zero Detect" the zero blocks and save space. However, at this time in the GUI we only have the ability to view how much the volume is committed and how much space is actually being used. It will then warn when a certain percentage of the volume is actually used. <div>&nbsp;</div> Are there any plans on doing this at the MDisk group? That is the important information because we need to know how much of the mdisk group is committed/over committed, how much actually exists and then how much is actually being used.

32 RudiChristensen commented Permalink

Hi Barry. <div>&nbsp;</div> I have a question following mitchellm3's question. <div>&nbsp;</div> It's about zero detection on Hitachi VSP systems, compared to SVC compression. <div>&nbsp;</div> How does these two technologies compare. Is compression the same or almost the same as zero detection on the HDS VSP. Do you save the same amount of space or is one better than the other. I know that zero detection is client controlled, which we - in our situation don't like - and compression is done on the svc with no interaction from our part. <div>&nbsp;</div> Any view on this is very much appreciated. <div>&nbsp;</div> Thx <div>&nbsp;</div> /Rudi

33 VipinKumarG commented Permalink

Hi Barry, <div>&nbsp;</div> Understand vdisk movement to new/another IO group in SVC requires recreation of flash and Remote relations if any in 6.3 version. Is this still applies to 6.4 version also where the online migration is supported? <div>&nbsp;</div> Vipin <br />

34 orbist commented Permalink

Al, <div>&nbsp;</div> The UPS in SVC is limited to 515W - based on US regulations, anything with more power than that needs an EPO, which defeats the purpose of the UPS.... So we can only power one node from one UPS. <div>&nbsp;</div> In V7000, we can run both nodes off one good battery, so a single battery failure doesn't take down a node. <div>&nbsp;</div> Chances are that if one input power fails, so will the other, and your disks will be gone, your SAN and hosts... so input failure isn't a concern. The UPS itself shouldn't fail either, unless its 10 years old or smoething, so unlikely to lose a node because of a UPS failure. <div>&nbsp;</div> As for roadmap items, I can't discuss un-announced features, functions or products on here. For a roadmap discussion, speak to your IBM BP or account team.

35 orbist commented Permalink

mitchellm3 and Rudi... <div>&nbsp;</div> 1. If you goto the "Volumes by Pool" section of the GUI, in the top right corner you get a view of the by pool status, alloacted, free, over allocated, and used capacity. You can also set warning events / emails on a per pool basis so you get warned when you get to that level. <div>&nbsp;</div> 2. Rudi, all SVC based (Storwize family etc) products support zero detect too. So if you write zeros in a block to a thin provisioned (or compressed) volume, we won't physically write them to disk, however if you read back those block(s) you will get zeros back. Compression is a very different beast, it compressed data based on a rolling window of compression history. It will write less data to disk (*assuming data is compressable) and will do this to any data - zeros or not.

36 orbist commented Permalink

Vipin, <div>&nbsp;</div> In 6.4.0+ the NDVM (non-distruptive volume move) function does not need any cloning or replicating of volumes. The ownership of the existing volume is logically moved from one IO Group to another. The same volume is used, and no copying of data is needed. Its just which nodes in the cluster that physically cache / service I/O for that volume that is changed. <div>&nbsp;</div> This needs the multi-pathing software to support the addition of new paths (via the new IO groups nodes) and the removal of the old paths (old IO groups nodes) to work - so is available on certain well behaving OS multipathing software at this time... see the support matrix on ibm.com for full details, and have a read of the infocenter documentation about how to use the function / what is needed.

37 Mark.C.Egan commented Permalink

We are adding a TMS unit behind our SVC to use in 2 ways. 1 - provide high performance storage and 2 - use with existing MDGs for EasyTIER. <br /> We are finding that when a SDD MDISK is presented and used with EasyTIER, if that MDISK goes offline and the MDG has LUNs using the SDD space, the MDG goes offline. I was under the impression that the EasyTIER function was suppose to automatic promote/demote storage in and out and if the SDD was not available, the LUNs that used that space continued on at the reduced performance of the real HDD. we are running at the 6.4 code level. <div>&nbsp;</div> Is this a risk of running EasyTIER or is this something that will be addressed in future releases.?

38 FHX7_Thao_Pham commented Permalink

Barry, <div>&nbsp;</div> I'm not too concerned about the UPS failing but the battery itself taking the node offline when it fails. Just recently while working with a colleague on a SVC install, we discovered that the partner node had a single failed battery within its UPS (brand new 2145 &amp; UPS) which negated the node's ability to power on which impacted us from a project rollout prospective. <div>&nbsp;</div> While it took a couple of days before we could get a replacement battery in, we had to wonder if the SVC's firmware can detect if the battery is close to expiring (similar to the DS4K and DS5K) or give the user notification on pending battery expiration. <div>&nbsp;</div> <div>&nbsp;</div> <div>&nbsp;</div>

39 scott.fuhrman commented Permalink

Mark, <div>&nbsp;</div> This is exactly why we would like to see either mdisk mirroring, or have Easy Tier mirror promoted extents to SSD rather than move them. The current implementation only moves the extent, which as you see, creates a big single point of failure. <div>&nbsp;</div> I have submitted a RFE to implement mdisk mirroring, you can see it at the following URL and vote for it. IBM needs to act on this if they really want Easy Tier to be a viable solution in the enterprise. <div>&nbsp;</div> http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&amp;CR_ID=27579 <div>&nbsp;</div> Thanks, <div>&nbsp;</div> Scott <div>&nbsp;</div> <div>&nbsp;</div>

40 TMasteen commented Permalink

Thank you for the opportunity to ask questions. <div>&nbsp;</div> With SVC GM one of the rules is: <br /> Global Mirror is not supported for cache-disabled Volumes participating in a Global Mirror <br /> relationship. <br /> Does this still apply? If so, can you please explain the reason and\or the result if it is in place? <div>&nbsp;</div> Thanks.

41 orbist commented Permalink

Mark, <div>&nbsp;</div> EasyTier physically migrates extents to the SSD mdisks in the pool. This is just like any other "striped" mdisk in a pool, whereby the data is spread over multiple mdisks. I'm assuming you are using one of the newer TMS boxes that have internal RAID-5 across the flash cards? I would expect that an SSD array is as reliable or more than normal HDD arrays. So there is no more risk than normal. <br />

42 orbist commented Permalink

Thao, <div>&nbsp;</div> The serial cable between the node and the UPS allows us to poll the battery and if its reaching end of life we will log errors. If it gets so bad, we will shut down the node. It sounds like you just had an unfortunate DOA - if there isn't enough power in the battery (UPS) then we will wait for it to charge before we power up the node. The design of all RAM being NVRAM is key to the way the SVC code was written, so we have to have enough power in whatever battery is being used to successfully shutdown gracefully at least once to avoid potential data loss.

43 orbist commented Permalink

Scott, <div>&nbsp;</div> The extent move is only an SPoF if you don't have RAID protection on the SSD device. The assumption of SVC is that any mdisk presented to it is RAIDed or somehow fault tolerant of one or more of its internal devices failing.

44 orbist commented Permalink

Tmasteen, <div>&nbsp;</div> GM volumes live and die by the latency, both at the primary and in particular the secondary. <br /> When using cache, at both sides, locally the write goes into cache and the I/O completes to the host. Asynchronously the write is mirrored to the remote site and again is written into cache there. This reduces the latency as much as possible. If you did not do this, especially at the secondary, then you'd have to wait for synchronous destage at the secondary site before the async GM write is completed back to the primary site. This is likely (due to the very short RPO target in SVC GM) to mean that we'd end up overrunning the GM buffering at the primary and take down the link giving the dreaded 1920 errors.

45 scott.fuhrman commented Permalink

Hi Barry, <div>&nbsp;</div> I agree with you in principal that "the extent move is only an SPoF if you don't have RAID protection on the SSD device". <div>&nbsp;</div> However in the real world bugs exist and bad, unexpected things can happen... reference code release notes from any storage vendor (IBM included) over the years. There are plenty of data unavailability bugs (and occasional data loss bugs) that have been fixed, and as long as humans write microcode this will not change. <div>&nbsp;</div> My point is that Easy Tier, in many implementations, can put a lot of eggs in one basket. Every pool may depend on just one or a few backend SSD controllers. Because it is so critical, I am advocating a belt and suspenders approach to Easy Tier'd extents. Storage subsystem data unavailability events are indeed rare, but they can and do happen. We need ways to limit the risk. Thanks! <div>&nbsp;</div> Scott <br />