<   Previous Post  Happy 5th Birthday
Survived my first...  Next Post:   >

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

1 localhost commented Permalink

One of the key benefits for me is the ability to do risk-free code upgrades on the underlying controllers. The ease of migration with SVC means that I can just move all the data off, do the code upgrade, then put the data back afterwards. A secondary benefit of doing it this way is that the data gets relaid out nicely. Of course, you have to have the free space available.....<div>&nbsp;</div> I have done many many software upgrades to SVC, and a hardware upgrade....I won't claim zero issues, but I will say that the issues I have come across have been fixed quickly!

2 localhost commented Permalink

We actually have an older two-node SVC cluster consisting of 4F2's. We've upgraded the code on this little cluster many times with out issue.<div>&nbsp;</div> However, for us the claim of no interruption of access or service was tested one evening when one of the nodes dropped dead. Even though we had tested the SVC's capabilities extensively during our acceptance testing, there is nothing like a real-world failure to really get to the heart of the matter.<div>&nbsp;</div> In short, not a single one of our users had any idea that anything was wrong. Two hours later we were back to normal after reloading the failed node from the remaining cluster member(a VERY cool feature).

3 localhost commented Permalink

Good article, this was probably the leading reason why we could not consider another vendor's virtualization. They failed to realize that one day the virtualizer itself would need to be upgraded/replaced/refreshed. <div>&nbsp;</div> With EMC, the upgrade was a lengthy process that had to be done by EMC. They told us it would take several days. I've seen lengthy "EMC only" upgrades in the past, and that means they are complex and don't always go well. It was not a straight-forward, well-documented upgrade.<div>&nbsp;</div> With HDS, they have no way to replace the virtualizer, although they say they are working on it. Their solution is to put a new virtualizer in front of the old and get off of it that way. Problem with this is that you take a disruption just like a traditional storage frame migration. Isn't that what virtualization was supposed to solve? C'mon, hitachi...