Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have two Asterisk servers. One is a warm failover (ie, we have to make it work manually should the first one fail, but it gets regular configuration updates so it's always ready to be made live) and the other is the live server. They both have Digium Wildcard TE405P's in them, and the hardware and software is otherwise identical, but the last time we needed to use the failover server, things went poorly when it was plugged into the PRI line. Now, we're upgrading the failover box to Asterisk 1.6 and pressing it into service.

I really need a way of thoroughly testing (including testing under load) the TE405 hardware and configuration before we need it. I can't just set up and tear down a PRI line for testing for an hour or a day, and the expense of the line prevents us from having a complete backup. Likewise, just switching the cable from one server to the next is also highly disruptive.

share|improve this question
add comment

2 Answers

up vote 5 down vote accepted

In the past for similar testing situations, I've just made a T1 crossover cable. The TE405P is a quad-port card, so on the failover system, just connect two of the ports back-to-back with a T1 crossover, then write a quick script to have asterisk place a bunch of calls out one port, answering them on the other port.

share|improve this answer
    
Oh! I was hoping that was possible, but very badly needed more details about its implementation. Thanks! –  Ernie Oct 27 '10 at 20:26
add comment

DR testing should be a part of your regularly occurring system maintenence plans, or at the very least, you should have regularly occurring DR testing annually, semi-annually, etc. You can do basic testing using the method ErikA suggested but you'll never really know if it works unless you test it with the real PRI line, making real calls. My recommendation would be to lobby for a regularly occurring DR test, scheduled for a time that's least disruptive to the business.

DR components are like anything else (backups for instance), they're of no use unless they actually work and in order to confirm that they work you have to test them.

share|improve this answer
1  
Um, it seems you just reiterated what I just said. Especially the "thoroughly testing" part. I'd like to get to the point where we can just throw a DR test at our customers just to make sure that real DR goes smoothly, but I think that things should be thoroughly tested first. –  Ernie Oct 27 '10 at 22:14
    
Hmm... Did I? It sounded to me like you wanted to test it in a "non-live" environment, which, as an approximation of a real failure, can only get you so far. How is testing with a dummy card or circuit going to approximate the real world? What are you going to tell your clients if the real deal fails? "I'm sorry, our dummy test never had this problem". You know how I test my email server failover? I shut down my email server... See my next comment for the completion of my point... –  joeqwerty Oct 27 '10 at 22:36
    
I'm not trying to be sarcastic, what I'm saying is that you should do all of the simulated testing that you can but the only way to know if it's really going to work is to schedule a DR test and put the DR components to work, doing the job you've intended them to do, and verifying that they work in a real situation. –  joeqwerty Oct 27 '10 at 22:37
1  
In addition, you stated that the last time you had to put your failover system in service it didn't work out so well, so whatever testing you've had in place up to this point has been a failure in my opinion. You can and should follow ErikA's advice to test that things work as you expect them to but are you really going to be comfortable with it without ever having put it into use in a real scenario? That's what DR testing is about. I'm on board with your dilligence, I'm just saying that you have to drive it around the block to know if it's really going to work. –  joeqwerty Oct 27 '10 at 22:44
    
Testing a few times on a fake connection before throwing everyone to the wolves for real world testing is better than throwing everyone to the wolves first. :) I needed a fake connection to work out the biggest bugs. Especially considering the old failover box is being rotated into service as an upgrade. Modified my post to reflect this. –  Ernie Oct 27 '10 at 23:25
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.