11-14-2008 02:24 PM
I've been ask to put in place a High Availability solution for our BES 4.1.6 for Exchange 2007 environment. I've done a lot of reading and I see 2 possibilities, before BES 5.0 comes out:
1- Neverfail
2- Build a second BES, same BES name, same SRP, with services disabled along with a second SQL configuration database (with transactional replication). With this solution, I'm wondering if I can put the SQL 2005 database on the same machine along with my BES or if it needs to be on a dedicated SQL server windows machine?
So my main question is: I'm pretty sure Neverfail would do the job but I would like to have your thoughts about my solution #2. Is that a good setup or can it be improved? Is there maybe a better way to grant high availability with a BES 4.1.6 environment? I'd like to have a setup where the failover could be as automated as possible, which is why Neverfail starts ahead based on my current knowledge.
Thanks for your input.
Solved! Go to Solution.
11-14-2008 03:05 PM
What SLA requirements do you have to meet?
RPO? RTO?
11-14-2008 03:07 PM
It's neverfail all the way for me. Quite simply you get what you pay for!
If you want a true HA simple failover solution that you can rely on and not have to go through a series of complicated steps then Neverfail is the best.
Having personally tried both solutions I have found the knofe edge cutover method complicated the firat time I went through it. It is a free solution so depending on your budget shouldn't be dismissed but if you can get the finance for Neverfail.... Do it, You won't regret it!
11-14-2008 03:17 PM
No specific SLA yet, but I'd like to do the best possible with BES 4.1.6. What I want is a solution that can take care of the failover automatically when the active server has a problem. If that solution is not possible with 4.1.6, then I want the next best thing available, a solution that will get us as close as possible to a High Availability / DR solution described in 5.0.
For example, I'd like to be able with a single click to failover, without having to backup/restore the SQL database or move users manually from one BES to another.
I don't know what RPO and RTO means.
Thanks
11-14-2008 03:26 PM
jolefebvre wrote:No specific SLA yet, but I'd like to do the best possible with BES 4.1.6. What I want is a solution that can take care of the failover automatically when the active server has a problem. If that solution is not possible with 4.1.6, then I want the next best thing available, a solution that will get us as close as possible to a High Availability / DR solution described in 5.0.
For example, I'd like to be able with a single click to failover, without having to backup/restore the SQL database or move users manually from one BES to another.
I really want to automate (or worst case faciliate) the failover process. Something as close as possible to Neverfail I guess...I don't know what RPO and RTO means.
Thanks
Ok, first and foremost, you need to define what your requirements are ... you've kinda done that with "What I want is a solution that can take care of the failover automatically when the active server has a problem. If that solution is not possible with 4.1.6, then I want the next best thing available, a solution that will get us as close as possible to a High Availability / DR solution described in 5.0."
The only proven option out there that I have seen that will meet this requirement is from Neverfail. That said, be smart and do the integration with Conceivium’s MobileMonitor to get the most out of the solution ... also an excellent product.
But again, before you go out and spend $20k on a solution to do this, you really need to define what HA means for you.
RPO = Recovery Point Objective
RTO = Recovery Time Objective
How many users do you have? How many BES's do you have? Do you have your users classified such that CxO's get higher priority than standard users or first level management? Do you have proper HA plans in place for the entire infrastructure that BES relies on? Mail Servers, Directory Servers, DNS Servers, Network Components, Database Server, etc...
Just don't put the horse before the cart on this one.
11-17-2008 10:33 AM
Ok, so here's more details:
RTO= 1 hour
RPO= undefined
Number of users= 30
So right now I have one server, running BES 4.1.6 for Exchange 2007 SP1. I want a second BES, in another location, for HA and DR.
Is my second solution, described in my original post, becomes the best solution? Is there a better way to do it? Any other thoughts?
Thanks again for your help, really appreciated.
11-17-2008 10:38 AM
BTW, I'm currently using SQL MSDE locally on the BES, not sure what can be done with transactional replication with MSDE. Worst case, I can switch to a full SQL 2005 version if it becomes easier to manage.
11-17-2008 03:08 PM
What about using our corporate SQL Cluster and forget about SQL replication between the 2 BES?
So the idea would be:
- One active BES running the 30 users and connected to the clustered central SQL database
- One passive BES, services disabled, same SRP, same BES name, pointing to the same SQL database (cluster).
When the active BES goes down, we manually start the services on the passive BES. Nothing else to do to failover and a 5 minutes RTO.
Am I forgetting or missing something or is it easy as that?
thx
11-17-2008 09:41 PM
jolefebvre wrote:What about using our corporate SQL Cluster and forget about SQL replication between the 2 BES?
So the idea would be:
- One active BES running the 30 users and connected to the clustered central SQL database
- One passive BES, services disabled, same SRP, same BES name, pointing to the same SQL database (cluster).
When the active BES goes down, we manually start the services on the passive BES. Nothing else to do to failover and a 5 minutes RTO.
Am I forgetting or missing something or is it easy as that?
thx
Ding, exactly. But, it is a manual failover. If you have the money($3000 USD retail), I'd recommend getting a second SRP and keeping both servers live all the time ... this way if one server has a problem you can drag / drop the users from one server to the other, or if you have maintenance you can do the same.
If you don't have the money for the second SRP, stick with exactly what you laid out. Just gotta move the database ... KB03112 - How to move the BlackBerry Configuration Database to a new Microsoft SQL Server or instanc...
06-09-2009 05:03 AM