[babylonrocker]

Hi all ... like title , i must support from vio different kind of storage , like ds8000 ibm and emc2 storage .
what kind of product i must install for support an hibryd situation ?

powerpath or sddpcm ?

[cdelgadop]

Hi

Does your Organization have lots of money ?? Buy a Storage Volume Controller (IBM SVC) and virtualize all your Storage boxes throught the SVC so your VIOS only sees FC 2145 Type disks no matter whether they are IBM or EMC2.


No. Don't worry. I won't neither do that. Just install SDD and Powerpath. You will see both type of disks and create your mappings to disks on each storage box.

Hope this helps

[babylonrocker]

mmh , i knew that only one of them can be installed at same time , or not?

[cdelgadop]

Hmmm

Nope. You can have installed multiple drivers for different disks in a system. Some configurations maybe needed. I once had a p690 with hitachi and emc2 disks at the same time for migration purposes. An one p570 with disks in a IBM Shark system and EMC powerpath devices for migration purposes also.

Hope this helps

[duke900ssd]

I think IBM would say you can install both BUT you cannot mix the devices on the same adapter, so connect the DS to one, or two adapters and the emc to another one or two adapters if you want IBM to "support" the configuration.

If you have IBM support, raise a PMR and ask them.

If you don't have IBM support then try it and see, like cd3lgad0p, I have mixed devices on the same adapter for migration purposes only.

[Administrator]

Originally Posted by cdelgadop

Hi

Does your Organization have lots of money ?? Buy a Storage Volume Controller (IBM SVC) and virtualize all your Storage boxes throught the SVC so your VIOS only sees FC 2145 Type disks no matter whether they are IBM or EMC2.


No. Don't worry. I won't neither do that. Just install SDD and Powerpath. You will see both type of disks and create your mappings to disks on each storage box.

Hope this helps

SVC is less than the cost of licensing PowerPath. AFter normal discounts, you can deploy a 2-node SVC for about $60K - and that includes professional services to get it up and running.

That doesn't even factor in the performance gains.

[duke900ssd]

SVC is a small system solution.
It only supports a small number of connections (I/O bottleneck) and introduces a PC (OMG!) between your enterprise servers and SAN.
Who would / could possibly consider such a solution in an enterprise class infrastructure?

[Administrator]

Originally Posted by duke900ssd

SVC is a small system solution.
It only supports a small number of connections (I/O bottleneck) and introduces a PC (OMG!) between your enterprise servers and SAN.
Who would / could possibly consider such a solution in an enterprise class infrastructure?

It sounds like you don't know too much about SVC. Small number of connections? No, not at all. A full SVC will support non-cached 960,000 IOs per second. Hardly a small number of connections, huh?

Each node is an IBM xSeries server - not nearly he same as a PC - running a specialized Linux kernel. Node are deployed in highly available node pairs called an IO group. In the even of the failure of one node, the other node in the IO group takes over all I/Os. If you loose a IO group, the IO is equally divided among all IO groups.

Each node has its own dedicated (and required) UPS.

Keep in mind that the SVC functions as an in-band controller. You don't cable anything directly to the SVC. Traffic is routed through the SVC via SAN zoning and makes your switch zoning much simpler to manage.

SVC introduces no IO latency. To the contrary, the additional layer of caching that SVC introduces typically improves IO.

Please have a better idea what your speaking about before giving bad information. There is an automaker in Michigan - can't mention which but there aren't too many to choose from, running an SVC with a IBM provided code modification. Their SVC is 40 nodes and they get 4.4 million IOs per second with 7 petabytes of managed heterogenius storage.

You were implying something about performance, scalability and reliability?

[duke900ssd]

"It sounds like you don't know too much about SVC. Small number of connections? No, not at all. A full SVC will support non-cached 960,000 IOs per second. Hardly a small number of connections, huh?"

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.

"Each node is an IBM xSeries server - not nearly he same as a PC - running a specialized Linux kernel. Node are deployed in highly available node pairs called an IO group. In the even of the failure of one node, the other node in the IO group takes over all I/Os. If you loose a IO group, the IO is equally divided among all IO groups."

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

"Each node has its own dedicated (and required) UPS."

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.

"Keep in mind that the SVC functions as an in-band controller. You don't cable anything directly to the SVC. Traffic is routed through the SVC via SAN zoning and makes your switch zoning much simpler to manage."

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

"SVC introduces no IO latency. To the contrary, the additional layer of caching that SVC introduces typically improves IO."

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?

"Please have a better idea what your speaking about before giving bad information."

Nuff said matey.

[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.