RE: Informix Hardware setup help

Michael, We use HDR here in a critical production environment. HDR is easy to set up and maintain, and is very bullet-proof. Yes, HDR can be run across slightly different hardware platforms, but they should be similar. We run ours on HP K-class boxes; different model numbers, but in the same "class". The really important things that must match are: -- OS version (try to keep patch levels in sync, also) -- IDS version -- disk layout <== this is the critical one!!! Chunk names & sizes must be identical on both boxes -- DR... values in the two ONCONFIG files need to match, or you could run into problems. Also, I highly recommend that you *NOT* do synchronous updates to the secondary; stay with asynch. Synchronous will cause the primary to wait until the change has been applied on the secondary, before the transaction completes on the primary. As far as keeping the two servers in sync data-wise, this is really no problem, even with asynch updates, as long as the network connection between the two boxes is stable. We have server pairs that are hundreds of miles apart (disaster plan), and the update delay is only a few seconds *at the most*. With your two servers right next to each other, you should have no problem at all. Finally, if you are running IDS 7.x, I recommend that you stay with *manual* failover (DRAUTO=0). Automatic failover can lead to update conflicts if you have any network "glitches". As a matter of fact, this is the *only* failover method with version 9.2x, i.e., DRAUTO is always set to 0 (cannot be changed). Speaking of network "glitches", HDR is very good at automatically recovering by itself after most network interruptions. You really ought to read the two chapters in the Admin Guide on Data Replication (ER has its own manual, HDR is covered very well in these two chapters in the Admin Guide). HTH, Paul Mosser -----Original Message----- From: Michael Hoffman [mailto:mrh@panix.com] Sent: Tuesday, January 02, 2001 11:46 AM To: informix-list@iiug.org Subject: Re: Informix Hardware setup help Thanks for the in depth responses, Obnoxio (hey, any chance there is a real name behind this mask? My boss laughed when I told him I was getting advice from "Obnoxio the Clown". His full response besides the laughter was "You mean that's not your pseudonym?"). I keep reading that HDR is extremely picky about the setup of the 2 servers, specifically the disk configuration, the OS, and event he model type. All must be identical. Now, I'm know relatively little about hardware, so this question may be meaningless, but aren't the E4500 and E6500 2 different machines? How does HDR handle that? Oh, and we're not a website... yet. I'm not able to give out many details, but we're in the financial area. We'll be providing up-to-the-millisecond data to the users and taking orders based on such data. Lastly, considering the urgency to keep the data flowing as quickly as possible, how much delay does Synchronous HDR put on the system? The 2 boxes will, most probably unless we learn about some negatives, linked with a very reliable Veritas cluster. They will be in close proximity to each other as well. Network transmission time should be quite minimal. I understand that the Secondary server doesn't rebuild the indexes as it adds rows, instead it requests a full copy from the Primary server. Most of our DB updates will be in the form of Inserts (not Updates), so the indexes are constantly being modified. Will this cause HDR to kill our system performance as it constantly requests, and waits for, the new indexes to be passed to the Secondary server? Thanks, Michael Hoffman In <3a4cc8e4.780432@News.CIS.DFN.DE> article, Obnoxio The Clown mentioned that: : In the year of Our Lord 29 Dec 2000 16:56:22 GMT, Michael Hoffman : <mrh@panix.com> broke a vow of silence to utter: :>Thanks for the explanations, and thank you Art for confirming I still have a :>grip on reality. :> :>Since we are basically locked into using the ECM data storage system, it would :>seem that HDR and EDR will not be effective. All servers will be linking to :>the ECM (we have many different systems running and users can log into any of :>the available servers. All data and programs must be accessible by every :>server). :> :>Obnoxio mentioned that a Sun cluster was possible, but seemed to suggest not :>the best option. We looked at Sun's clustering application and, from what I've :>been told, quickly ran away and picked Veritas's clustering solution instead. : Well, AFAIK it won't give you the ability to share data. Have you looked at XPS? :>What we are most concerned about is one login server crashing. The users will :>need to be able to log in again, and will automatically be routed to one of the :>other running servers, and MUST have access to all the data immediately. : A "Sun cluster" will allow this, XPS won't. Nothing I've seen in your post would : preclude HDR -- why not use that? Set up the second box as a read server and off : you go. And if you need to failover, it's relatively painless. To be honest, I : haven't seen much that a Sun cluster can do that HDR can't busk for a lot less : money and effort. :-) :>Someone, through email, suggested setting up instances of Informix on each :>server, but instead of creating the tables, to use synonyms instead. Will this :>work effectively? Does the use of synonyms slow down processing times? : I don't think it'll slow things down much, I've already been to this party too. : However, tracking down performance problems is "fun" and God help you if you get : versions seriously out of sync. Also, we moved from this to HDR, and were much : happier with performance and resilience. :>Finally, and this was just a brainstorm: what would happen if I created :>instances on each additional server and loaded the exact same dbschema, but :>instead of pointing to the ECM, I pointed to some raw slices. I wouldn't load :>any data to these tables. If the main server crashed, wouldn't I be able to :>start one of these other instances and just repoint (via the symbolic links) :>the engine to the ECM storage? Since all of the system tables will be on the :>ECM system also, shouldn't the newly started instance forget it's original :>setup and use the ECM data just fine? (Ok, now I think I may have totally lost :>my mind :-)) : It would probably work, if I understand you correctly, but I doubt it's : supported. : Are all your systems available on all servers?