[Administrator]

Originally Posted by duke900ssd

So this little PC has more I/O bandwidth between its four fibre adapters than half a dozen, or more, pSeries sytems have amongst their multiple adapters? Yeah, right.

The SVC isn't performing the IOs any more that your SAN switch performs the IOs. You can't seem to get passed the fact that it is a controller, not a proxy server.

Originally Posted by duke900ssd

Said it your self, xSeries = x86 = PC, OMG! it runs linux too, so it's a linux PC.

The pSeries and DS8000 HMCs also run Linux on a xSeries server. You depend on them for dynamic reallocation of CPUs for workgroups and uncapped LPARs. HACMP reallocated resources after failover using the HCM and Partition Load Manager uses the HCM to dynamically reallocate CPU and memory.

Originally Posted by duke900ssd

Which is probably so small it only allows a controlled shutdown. Why is this required? I suspect because the poor little linux PC would dump the cache when the power went if it didn't have some warning and whould trash your data with no way to recover it. And, hey, we all love adding reliable things like a UPS or two as the only means to stand a chance of keeping our data safe.

Does someone really have to explain this to you? It is a controller. Would you purchase a storage device that disn't have cache battery backup? I would hope not. Any cached controller, whether it is a controller on a storage device, or an in-band virtualization controller such as IBM SVC or HDS TagmaStore Universal Storage Platform, has to be able to complete the IOs in cache, even in the even of a power failure.

You're railing against IBM for proper design in the appliance.

Originally Posted by duke900ssd

Great if you can't zone your SAN properly, I suppose, otherwise it is just a major point of failure.

Mean time between failure data has already shown that the SAN director is more likely to experience a failure than the SAN Volume Controller, so it definitely isn't a major point of failure.

Originally Posted by duke900ssd

So your data I/O request goes from your server, to the SAN, then to the SVC, which thinks about it for a finite amount of time, then back to the SAN, then on to the storage, the I/O request is released back to the SAN, which passes it back to the SVC, which thinks about it for another finite amount of time, then it passes the data back to the SAN and on to the requesting system. How does this happen without any I/O latency? Magic?

It seems like "SAN" is the magic to you. Do you ever consider what processing the switches/directors perform? What about the latency of ISL'ing switches and directors? By your narrow thinking, a Core/Edge fabric design would be a bad thing, huh?

SVC is part of the SAN, it isn't a separate element. The processing that it performs in routing SAN packets is more than offset by the added layer of cache it provides.

Originally Posted by duke900ssd

Nuff said matey.

I agree. Your lack of understanding has been adequately exposed. Ultimately, you bring a flawed understanding with no practical experience to the table.

On the otherhand, I have years of experience managing SVC clusters with petabytes of storage under management. I have real-world data on reliability, ease of management and application performance.

If you're afraid of storage virtualization, if you don't embrace the technology now, 3 years from now you'll be left behind. You'll be the technological equivalent of a CICS admin.