BES DR Failover using VMWare ESX
 

With the significant delay in Argon and it's native failover capabilities, I am looking at other options for BES failover.

We are currently evaluating migrating BES to VM's on VMWare's ESX Server platform, with the idea of implementing some sort of offsite VM replication solution, so that in a DR situation the VM can be brought up offsite.

Has anybody else looked into this option as an additional / replacement DR strategy over what is planned for 5.0?

For what it's worth, I've been running BES 4.1 for Exchange with less than 100 users on ESX for several months without issue. In fact I have been very happy with the performance, but as said, this is a small site.

I think DarthBerry was looking to do exactly this.

Me, I think there's too much disk activity for BES Domino to run it in a shared VMware environment especially with your number of users. Unless you can get dedicated servers.

Our current BES is running 4.1.4 MR4 for Exchange in a Win 2003 R2 SP2 VM on a 3 server ESX 3.5 Cluster. We have 186 users and the SQL database is on another VM running SQL 2005 with 4 vCPU's.

The VM's are hosted on an IBM ds4800 fiber channel SAN. The VM cluster also hosts about 45 other VM's ranging from data, print, dc's, sql.

No performance problems to date and I'm very satisfied.

Our original BES ran on a standalone box using MSDE. We migrated over to VM around the 150 user mark.

Well that certainly is a concern, and I was planning on benchmarking to see just how far we can go with this. Even if on a dedicated host, the guest vm would still be portable and hardware agnostic.

Thanks PhanMan for the info. What is your current plan for BES DR in this environment?

ESX BES admin
 

I have 370 users on an 2k3 ESX VM. Two vprocs and 3 gig on memory. Would not recommend over 300 uses on MSDE DB. Tsupport has told me that they have clients that use SQL servers and BES servers with ~1500-2000 users with no ESX issues. We Vmotion our BES server between datacenters withour issue. Snapshots make upgrade rollback plans a breeze! just make sure you keep your vmotion'ed BES server close to mail servers where user's mail is. Oh and cluster your SQL database. We never go down but for upgrades and that takes ~10 mins with reboots. Testing neverfail to see how that host failover works and if we can upgrade w/o any short outage.

We have begun our BES migration to VMware ESX with three servers completely on VMs. No issues with these. I had a good discussion with RIM's VMware/Virtualization Project Manager a couple weeks ago and they're certainly excited about virtualization and moving forward with their support of it.

Our current servers running on VMs each have right at 500 users. These run on a single vProc and 1.5GB RAM. We're planning on dropping the RAM to 1.25GB, as it's not being fully utilized (from the VM reports on active memory usage).

Hi - Off topic but I know Web Desktop Manager can be used in VM but any feedback on the Monitor Service?

Our Server group is putting all requests for servers in VM now and won't purchase hardware unless we have written explination why it won't work.

Is there a recommended number of users to stay under when running on VMs or is it purely dependent on the H/W?

Currently we're running about 1300-1500 per physical server and load is pretty minimal.

He X14, we are running the last 2 years Domino BES 4.x on ESX no Problems at all. Once in a while the CPU jumps up to 100% but no problems at all with disk.
Had three BES Servers with about 500 useres each; the SQL Server for BES; a Test SAP R3 System, and two productive Oracle Servers on our VM Box

@jibi & @boma0021:

Those numbers are encouraging b/c I like to keep my servers at 500-800 max, thanks for the info.

Now how about DR, what is your strategy for this in a VM environment? Are you looking forward to the upcoming Continuous Availability option within ESX or employing a third party product?

Or like me depending upon the "sourceless move" option as a poor man's DR? :)

Still looking at that scenario. I might not have the hardware available for a full DR server.

For our DR, we have used a combination of a few methods during our migration to a fully virtual environment.

We originally migrated off a standalone BES to a VM. 1 CPU, 2GB memory (not that it needed it), and about 100 users.

We used the freebie vmdk backup to back up the VM nightly.

For nearly live replication once we had another ESX box up at the DR site, we used vReplicator.

And now that we have a prod SAN/ dr SAN, we use EMC Recovery Point to replicate the SAN LUN that contains the VM.

I think any of these options is better than using non-VM recovery solutions such as backing up the database, restoring the database, log shipping, "standby" servers etc. Of course, all of this differes slightly I guess if you use a centralized database server (which I recommend you do), but is pretty much the same.

Right now, just our BESmgmt db is backed up every night onto tape. We are currently in the planning phase for a remote DR site as well and deciding if we want to replicate the entire SAN lun's or at the vm level (or a combination of the two)

Depends on your total user base. If you have a BES or messaging server or SQL server that's virtualized, then there should be little concern behind virtualizing the monitoring service. Just keep in mind that the traffic distribution algorithms will need to accommodate for the SNMP requests.

Jibi - is that in users on the BES or users for the Monitoring service? I know your a big boxtone guy .. can you put that in VM?

SQL is a dedicate server (hardware based)

Recommended capacity depends on the number of messaging servers you have. In the Exchange world of MAPI, the server performance starts to exponentially degrade as you add users on different mailbox servers to it. RIM recommends optimal performance with a 1:1 ratio of BES to Exchange. In one region, we have more than 40 Exchange servers in our current mail infrastructure across 8 BES servers. Prior to my arrival is when they topped out at 500 users and then built a new BES and populated it and so on and so forth. When I started looking at this and redesigning our infrastructure for a 5:1 ratio (taking into account the default 5 mailbox agents from BES), we had just begun work on consolidating our Exchange environment with SAN storage. In a couple months, we'll be down to 6 Exchange servers, thus being able to reduce our BES environment by a couple servers and increasing the number of users that are managed by each one. Should be interesting.

Anyhow, users-per-server is not a great way of determining your BES limitations. It's based on system performance, messaging infrastructure, and finding a balance of BES-to-MSG ratio (if more than 1:1, that is). From there, it's just monitoring your system to see when/if you have a degrading of service for your users.

One more thing to remember is that following a reboot, service restart, etc., the time it takes to recover and be 100% functional (post-rescans) is directly dependent on the number of users you have on a server and the messaging infrastructure.

BoxTone cannot be virtualized (well, I won't say can't but we won't). It runs on Oracle and JBOSS.

Users being monitored would be what I'm talking about though. Most of the time, I would imagine this would directly coincide with the number of users in a BES environment.

Thanks everyone for the valuable feedback. Just signed up for a VMWare lunch session on DR in "VMWare Infrastructure 3" so will be able to consolidate all this info and make an intelligent decision. Rare, but it happens sometimes! :)