10-04-2007, 09:57 AM
Join Date: Sep 2005
Location: Congested Islet of "Foreign Talents" (> 45% of workforce) - Singapore.
Post Thanks: 6
Thanked 9 Times in 9 Posts
| | Advantages in time of DR - BESes sharing same BESMgmt
Please Login to Remove!
Just wanna share the useful information after talking to an experienced BES admin the other day.
If you have many BESes in your organisation (in my case Domino servers), try grouping them logically by geographical location as you would group them for your mail servers when planning and deploying them. Why? Because RIM recommends that BES should be as close to its users mail servers as possible.
Next, prepare the number of SQL servers that will serve the same number of groups. Install your BESes in a group and designate a BESMgmt database so as to form a BlackBerry Domain.
BES_US_01, BES_US_02, BES_US_03 <=> BESMgmt (SQL_US_Server)
BES_HK_01, BES_HK_02, BES_HK_03 <=> BESMgmt (SQL_HK_Server)
Now, if in the event that BES_US_01 is totally toasted and cannot be started. What would you do? You will be glad that you have bind all the US BES servers under the BESMgmt (SQL_US_Server). Why? You can use the "move user" function to move all your users from BES_US_01 to either BES_US_02 or BES_US_03.
This is a good and clean DR strategy. But there is a catch. Apart from the obvious extra SPR IDs that you require, the user move is called a sourceless move as the source BES Domino is offline. What you need to do before the move is to temporary turn the destination BES offline, after moving the user, copy their state databases over to the destination. Finally, restart the BES. It will initialize those moved users as if they are already on it before.
I think this is quite a good DR strategy although it is a little manual but pretty straight forward.
Just sharing. If others have experienced a DR situation and your solution is better, do share.
Native but 4th class citizen of a nation governed by idiots who import congestions & contention.