There are other challenges and issues facing storage customers when it comes to integrating multiple SANs, but Lam says it all boils down to three little words: compatibility, compatibility, and compatibility. He believes that the biggest reason for this is that even though there are standards out there such as CIM, some vendors either choose not to follow the standards at all or they follow them in ways that suit their individual proprietary methods.
“When customers try to integrate multiple SANs, they run into many difficulties because some vendors have requirements that conflict when islands of SANs are integrated, such as the switch settings to the storage, or when there’s an HBA from a host that is supposed to access storage from both SANs, and one vendor requires the timing or loop count/loop down time be a certain value, while the other vendor requires a completely different setting. The question the customer then faces is: ‘Which value do I choose?’” says Lam. “And, the answer is,” he continues, “it doesn’t matter, because whichever setting the customer chooses will violate the other vendor’s recommended setting.”
Lam points out that one of the ways to get around this dilemma is to have middleware (such as a storage appliance) in the fabric. “From the host’s point of view, the customer only has one storage platform to deal with — the storage appliance platform.” And, he adds, because the appliance is in the data path and can translate the differences between storage devices and can access different vendor’s storage, the host does not have to be specific to any storage vendor’s recommendations or specifications.
Other industry experts believe that storage customers must carefully investigate the ability to have storage subsystems from different vendors share the same SAN, especially if the storage expects to gain access to the same host. “What’s most important to the customer is to prove that the end-to-end solution will work in a real environment,” says Ross. “This means not only qualifying storage and a switch, but also including HBAs, switch vendor interoperability, software, SAN extensions such as DWDM and FC over SONET, and support for multiple storage vendors at the same time.”
Fabric Instability Another Major Challenge
Ross adds that fabric stability is another challenge facing storage customers. He believes that the FC SAN’s mechanism of logging in and out of a network provides a graceful way to add and remove devices in the SAN. “Zoning is a mechanism for controlling access among devices in a SAN, and when a customer tries to deploy a large SAN, the above changes generate a “State Change Notification” to all the other participants in the SAN.” The problem is that the larger the SAN gets, the more this type of traffic gets generated, potentially hindering performance.
Another issue, according to Ross, is that if a mistake is made in a very large SAN, such as a zoning change, this mistake could potentially take down the entire SAN. “New mechanisms that allow for building large domain count SANs that minimize the propagation of overhead traffic are beginning to be delivered,” says Ross. “These new features create virtual SANs or sub-nets to isolate portions of SANs from one another.”
Page 3: Complexity Among the Switches