|
Hi, Mike, thanks for your reply. Yes, this installation is using Vision Solutions, which appears to be one of the better utilities for data replication. From a switchover/failover standpoint, they seem to be covered. That's all well and good. But if we can avoid a NEED to switchover by exploiting a redundancy option that currently exists within the room, then we have done a good thing. So the crossover connection to the pair of F20s made sense to me, to avoid a single point of failure. However, if the failure of one of these redundant pieces of ... ummm ... hardware causes both systems to go down, then we've increased the risk rather than reducing it. (I hope I'm saying that clearly enough.) I agree that they should maintain their data redundancy operation in addition to all the other things they can do to enhance reliability through redundancy and other available means. Good to hear from you, Mike, and I look forward to your (and others') further remarks. Dennis ________________________________ From: midrange-l-bounces@xxxxxxxxxxxx on behalf of mshaw2456@xxxxxxxxxxx Sent: Wed 08-Sep-04 7:52 PM To: Midrange Systems Technical Discussion Subject: Re: Redundancy: Multiple 890s and multiple Shark F20 Dennis, Long time no keyboard! :-) There are some pretty stringent requirements for mirroring on the iSeries as I recall. Mirrored pairs is what falls out of feeble mind at the moment. Most folks have chosen a HA solution to do this. There are many providers in the iSeries arena. The ones that come to mind is Lakeview Technologies and Vision Solutions. <hth> Regards, Mike Shaw -------------- Original message -------------- > Hello, Midrangers: > > I am reviewing an iSeries implementation at a bank in South America. In > this process, I have found an interesting anomaly I had never heard of.... > and I hope that one of you good people can clarify for me. > > Overview: Two 890 systems, each connected to its own Shark F20 Storage > device. (In other words, 2 890's and 2 F20's). Each of these systems is > configured with BUS level mirroring. Most of the redundancy issues seem to > have been addressed, except one. It made sense (to me ) to recommend that > the iSeries systems have connections to BOTH F20 (with one copy of the > mirror on each F20). So we'd have this sort of configuration (sorry for the > poor graphics..... > |---------------| > | | > | 890 | > | | > | | > |---------------| > | \ > | \ > | -------\ > | \ > |---------------| |---------------| > | SysA Mirror 1 | | SysA Mirror 2 | > | | | | > | | | F20 | > | F20 | | | > | | | | > | SysB Mirror 2 | | SysB Mirror 1 | > |---------------| |---------------| > \ | > \ | > \----------\ | > \ | > |---------------| > | | > | 890 | > | | > | | > |---------------| > > When I presented this concept, it was shot down. The Client indicated that > they > had been through this scenario with IBM; they were told that in this > configuration, if one of the F20 Shark units fails, it will bring both iSeries > systems down. > > This surprises me greatly... which is why I'm here. Can any of you confirm or > deny that: > If a Shark F20 fails while connected to an iSeries, the iSeries will also > fail > (even if the redundant Shark is still running) > Above being true, an EMC solution or other storage solution cannot resolve > this point > > It seems unthinkable in this age that such an obvious single point of failure > cannot be resolved. I'd love to hear your thoughts. > > Regards, > -- > Dennis Lovelady > -- > "Television is a device that permits people who haven't anything to do to > watch people who can't do anything." > - Fred Allen > > > This message is for the designated recipient only and may contain privileged, > proprietary, or otherwise private information. If you have received it in > error, please notify the sender immediately and delete the original. Any other > use of the email by you is prohibited. > > -- > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > or email: MIDRANGE-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. > -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.