[Snyder81]

I have read that clustering BES 4.0 is possible, but I can't find any in-depth technical information specific to BES. Has anyone done this? Is each BES service considered a cluster resource or just the SRP service? Details would be greatly appreciated.

Thanks!

[jibi]

version?

[Snyder81]

BES 4.0 for Exchange w/ SP1 and hotfixes 1, 2, & 3.

[corey@12mile]

There is no clustering ability with BES at this point. Closest thing right now is single database with multiple bes servers, but it's still explicit assignment of users to individual servers. There is the possibility for failover creation, but you have to ensure that 2 servers with the same srp are never live together, or else you are in for a world of hurt.

cd.

[Snyder81]

Originally Posted by corey@12mile

There is no clustering ability with BES at this point. Closest thing right now is single database with multiple bes servers, but it's still explicit assignment of users to individual servers. There is the possibility for failover creation, but you have to ensure that 2 servers with the same srp are never live together, or else you are in for a world of hurt.

cd.

So if clustering is not possible, explain this...

I'm just wondering if anyone has any experience setting this up.

https://www.eaccessinc.com/Support/B..._Clustered.htm

You can either click on a question to take you directly to the answer or scroll through to read all of them. 1. What is clustering?
2. How is logging done during a failover? (i.e., if the first node crashes, does it record anything to the BlackBerry Enterprise Server log to let me know this? If so what?)
3. How do I initiate failback if I've fixed the problem with node 1 and want the system to return to the original state?
4. What requirements are there for the clustered server solution?
5. How does this benefit my organization?
6. Does one license cover both nodes of a clustered system?
7. Can a clustered server support more users then a regular BlackBerry Enterprise Server?


1. What is clustering?

Clustering allows the use of automatic failover from one server to another server that has been specifically designed for this task. Back to top

2. How is logging done during a failover? (i.e., if the first node crashes, does it record anything to the BlackBerry Enterprise Server log to let me know this? If so what?)

In the event of primary node fail over, initiated (for example, due to loss of power on the primary node) provided the BlackBerry Enterprise Server service is in stand-by mode on the secondary node, failover is automatic. The logging for the secondary node will show the failover taking place at that time, and the secondary node takes over typical logging (BlackBerry Infrastructure pings, mail redirection, etc). When the problem on the primary node is addressed, and you want it to resume processing, you must initiate failback. Back to top

3. How do I initiate failback if I've fixed the problem with node 1 and want the system to return to the original state?

Once the primary node is operational, to allow it to resume processing, bring it back online:

From the Start button, select Programs > Administrative Tools > Cluster Administrator to open the Cluster Administrator window.
In the tree view, select BlackBerry Enterprise Server Group and right-click.
From the menu, select Bring Online.
There is a slight delay while all users are started. This delay does not occur with failover, because the secondary node has started everything but the SRP connection. Back to top

4. What requirements are there for the clustered server solution?

The BlackBerry Enterprise Server for a clustered environment requires the following hardware and software components:
Hardware: PC with an Intel® Pentium® processor or compatible (233 MHz or higher, 128 MB RAM, 1 GB hard drive), and cluster server nodes compatible with Microsoft's cluster service specifications
Software: BlackBerry Enterprise Server works in Microsoft Exchange 5.5 or higher environments.

There should be two cluster server nodes with the following software: Windows NT 4.0 Server Enterprise Edition
Microsoft Exchange Administrator 5.5 (with Microsoft Exchange Service Pack 4 installed), with access to the Microsoft Exchange server


WARNING: If you install Microsoft Exchange Administrator on a new cluster server, on each node, you must run it and connect to a Microsoft Exchange server in the same site in which you will be installing the BlackBerry Enterprise Server.

WARNING: You MUST install the BlackBerry Enterprise Server on both the primary and secondary node. Once the install is complete on both nodes, you MUST start the primary node (using Cluster Administrator) BEFORE starting the secondary node. Otherwise, both nodes will attempt SRP connections, resulting in authentication errors.

Microsoft Outlook should not be installed on the BlackBerry Enterprise Server machine. This is an unsupported configuration.
Microsoft Exchange Administrator's MAPI and CDO subsystems are required for a BlackBerry Enterprise Server 2.1 environment
Before installing BlackBerry Enterprise Server, you must install the CDO.dll hotfix for Microsoft Product Support Services Knowledge Base article Q289606. You can download the hotfix and obtain information on the Knowledge Base article from:
http://www.microsoft.com/Downloads/R...eleaseID=29085
Note: The corporate firewall must be able to resolve Internet addresses using DNS.

Firewall Configuration: The BlackBerry Enterprise Server initiates connections to the wireless network in an outbound direction. To support BlackBerry in an environment with a firewall in place, you must configure the firewall to allow the computers running the BlackBerry Enterprise Server within the company to initiate TCP/IP connections to an outside server listening on port 3101. If you use a proxying firewall, the proxy must be transparent.

Note:
A transparent proxy does NOT modify requests or responses through the proxy during proxy authentication and identification, whereas a non-transparent proxy (where the client specifies the hostname and port number of the proxy) IS used to modify requests or responses through the proxy. If you have a non-transparent proxy, the BlackBerry Enterprise Server can be configured to access an internal proxy address, which is then translated externally to the SRP Host on port 3101. Back to top


5. How does this benefit my organization?

The advantage to clustered servers is the ability to continue the BlackBerry Enterprise Server even in the event of hardware failure. This allows for 7 days a week, 24-hour continual service without interruption. Back to top

6. Does one license cover both nodes of a clustered system?

Yes. Back to top

7. Can a clustered server support more users then a regular BlackBerry Enterprise Server?

No, the clustered server operates in the same fashion in that only one node is functional at a time. The advantage to clustered servers is the automatic fail over abilities allowing for uninterrupted administration of the service even in the event of hardware failure. Back to top.

[Zharin]

Interesting read.

[corey@12mile]

The article is somewhat old... bes 2.1. Clustering today is more of a load balancing architecture as oppsed to what they are showing as a redundant architecture in the article. What I mentioned in my post about failover is what they are talking about in that article... I can write some vbscript to monitor serverA from serverB and as soon as it stops responding start the services on serverB to pick up. I can then fire things into the event log, shoot some smtp to BWC, whatever I want.

Clustering per se is having X number of servers work together as a single entity on the network, which can't be done with bes... you can't take 5 servers with 4000 (800 users per server) users and if 1 server fails the other 4 pickup the slack, it just isn't going to happen.

The number are all hypothetical to show my point. When you setup the user in BES, it is that instance and SRP that the relay uses to communicate with the handheld. That SRP and only that SRP will work for the user without having to generate new encryption keys and re-sync.

cd.

[Sohail]

Clustering is possible on BES but not node failover. We have clustered sql db, but lack of failover force us to keep the BES server standalone with one hotspare.

[Snyder81]

I think it's simply a matter of having two identical Windows server boxes and setting up the BlackBerry services as a cluster resource. Has anyone done this yet?

Then again, maybe I'm missing the point. Here's what I think the configuration would look like:

One active server
One passive server
Both servers identically configured with same SRP and pointing at same SQL DB, but only the Active node has the BlackBerry services running.
All the BlackBerry services are listed as cluster resources and if Active node fails then all the BlackBerry services are shut down on Active Node and shortly after all the BlackBerry services are enabled on the Passive Node. Essentially the service just had a short outage while the failed Active server stopped the BlackBerry services and the Passive node started the services.

Does this make any sense? What am I missing?

Cory, I agree with your definition of clustering, but it's not necessarily requiring multiple machines to simultaneously share the responsibility. It can be setup with one active and one passive node for failover.

[dev]

In order to have a true BES cluster, the BES services have to be cluster aware..in particular the Blackberry controller service. If this service is cluster aware then it will be able to "start" the services on the passive node when it senses a failure on the active node. Only RIm developers can alter the code wrt that component.

[x14]

I ran across an article saying that the FCC using EMC/Legato FullTime AutoStart and FullTime RepliStor to cluster their BES. An outside consulting company set it up for them. I'm currently looking into this.

[Snyder81]

Originally Posted by dev

In order to have a true BES cluster, the BES services have to be cluster aware..in particular the Blackberry controller service. If this service is cluster aware then it will be able to "start" the services on the passive node when it senses a failure on the active node. Only RIm developers can alter the code wrt that component.

So can Windows 2003 Enterprise Cluster Administrator not be setup to monitor the BlackBerry services? In Exchange(it is cluster aware), the services are set to manual on all servers and the Cluster Administrator fails over the service when the primary node dies. Why can't this be done for BES 4.0? Do the services really need to be cluster aware?

-Scott

[amukhey]

There is no TRUE BES cluster involved but like it was said above. 2 Servers identical on your DR Site. Have the same # of servers at the DR site and the HQ site. Its pretty simple and we have done it fr BES 2.2 for Domino.

It would be different for 4.0...It may also involve SQL Replication.

[johnnyBB]

Originally Posted by x14

I ran across an article saying that the FCC using EMC/Legato FullTime AutoStart and FullTime RepliStor to cluster their BES. An outside consulting company set it up for them. I'm currently looking into this.

Have you found anymore info on this clustering method? Or do you have a link to the article?

[johnnyBB]

Originally Posted by x14

I ran across an article saying that the FCC using EMC/Legato FullTime AutoStart and FullTime RepliStor to cluster their BES. An outside consulting company set it up for them. I'm currently looking into this.

Have you found anymore info on this clustering method? Or do you have a link to the article?

[Turboman93]

If you're looking for BES HA/DR solution check out Neverfail. They offer a BES solution with their product and they do support BES 4.0.

http://www.neverfailgroup.com