BEs 5.0.2 inplace upgrade of sql express to sql server 2005
i have been testing bes 5.0.1 (recently upgrade to 5.0.2) and am now happy with the way it works (single exchange 2007 server)
i am in the process of setting up a new DR solution in a new Datacentre and wanted to install a bes 5.0.2 HA server in the new DR datacentre.
i did a bit of reading up on the BES 5.0 HA failover and understand i need a sql server database rather than the sql express 2005 database i currently have on the bes 5.0 server (sql express was installed as part of the installation)
i can just scrap the existing bes 5.0.1 server and rebuid from scratch and install the SQL server 2004/8 on the box and then do the installation and setup mirroring to a sql express 2005/8 server on the bes 5.0 HA server.
is it possible to do an inplace upgrade of sql 2005 express to sql 2005 standard while keeping the bes databases intact and working. i currently only have 1 user on the bes server (me) so a bit of downtime is not an issue.
it might just be easier to start from scratch as it is on a virtualised server and can rebuild in less than 1 or 2 hours but if in place is possible that might be easier?
is there anything else i should be taking into account, i am also planning on installing exchange 2010 once some 3rd party plugins become compatible and will be installing an exchange 2010 server in the DR datacenter so if there is anything i can do now with the bes 5.0 HA setup that will make it easier to incorporate with exchange 2010 please let me know
for one user, nuke it and install fresh SQL server
My 2 cents worth suggestions...
Start from scratch better. I have tried to do a in-place upgrade and apparently it installed another SQL instance instead. This is because BES 5.0 installed local SQL Express as a named instance named "BLACKBERRY" and when I ran the installer for SQL 2005 server, it created the default instance and effectively you have 2 SQL instances:-
1 x SQL Expresss 2005 with BLACKBERRY instance
1 x SQL 2005 Server with default instance
You may have better luck figuring ways to really do an in-place upgrade over the existing one.
Also, please do not go with this configuration (same as many of my customers - just to save cost but not troubles later on which may be more expensive). It just doesn't make sense and defeats the purpose of building a true High Availability solution.
(A) NO NO Configurations (n)
(1) Computer A
- BES 5.0 Primary + SQL Principal Server
(2) Computer B
- BES 5.0 Standby + SQL Mirror Server
Just for laugh: We call this "cheapskate" configurations :razz:
Serious Now: This is not a truly distributed configurations and it is not scalable at all. There will be system resources contention and your BES server's performance will be affected. Also if Computer A has a hardware failure, your SQL server will be also down and you will be stuck with a broken state Computer B. You won't be able to manually promote the BES Standby server via BAS (go try out and you will know). I'm no SQL wizard, but I wonder how easy it will be to promote SQL Mirror Server as Principal server in this situation. That will be a question for the SQL Administrators here.
(B) Better Configurations (y)
This is more scalable. Computer can be easily managed by plugging and replacing as and when required and will not disturb the other computers. In short, the disruption is minimal when one of them is offline.
(1) Computer A - BES Core services (primary BES)
(2) Computer B - BES Core services (standby BES)
(3) Computer C - BAS services
(4) Computer D - MDS-IS service (Optional)
(5) Computer E - BES Monitoring services (Optional)
(6) Computer F - SQL 2005 SP3 Principal Server
(7) Computer G - SQL 2005 SP3 Mirror Server
RIM did a very bad job by not giving out this specific best-practice information when BES 5.0 first released and there are many customers already built their "mashed" configurations.
I would advised to go configuration (B), anyway nowadays computers are VM images and can be easily built effortlessly.
thanks for the plan B, that is a very good description, i should have pointed out i only have 19 users and with a bit of luck we will grow to 30 users so don't think system resources will be a problem with running everything on 1 server but i take your point onboard about not being able to promote computer b, that is a good point and i will have a think about that and how it can be resolved.
I am a Lotus Domino Administrator but, am tasked with supporting BES on Domino. We have worked our way up to almost 600 users (started with only 36) and now are need of splitting our user base to 2 BES Servers in 2 Datacenters. After reading your note, it has forced me to evaluate a different scenario for our resolve.
Currently, we have 1 BES 5.0 Server. Originally, we had the plan to create a New Primary BES 5.0.2 in our Houston Datacenter with a Standby in our Atlanta Datacenter and then a Primary BES 5.0.2 in our Atlanta Datacenter with a Standby in our Houston Datacenter. We will be installing all of these on VMs.
So, now, my question is what should our scenario be? We have Mail Servers in Atlanta and Mail Servers in Houston (user base about 1/2 and 1/2). How would you suggest we plan our build-out for Failover / Disaster Recovery? Obviously, our original plan was not a good one and we do not want to have to work in reactive mode should we have failures. Will mirroring be a part of this?
Any suggestions / guidance you may have would be greatly appreciated.
i know it is better to spread it out over more than 2 servers but for 25 users this is way over the top. also given that most of our users now also have ipads and iphones with mobile email, the blackberry is becoming less of a critical item.
for 600 users I don't know if this will work and also given that you have your users spread out over 2 sites, as long as the connection between the 2 sites is less than what rim recommend (can't remember what it is) i would build 1 data site as your primary site and have all your users on that bes setup and use your 2nd site as a failover. whether you go for my "cheapskate" solution or for the more ellaborate setup. if you do go for the cheapskate solution please bare in mind you need a 3rd SQL witness server in a 3rd site, it is no good placing this in the same site as your primary or mirror sql database as you need 2 out of 3 up and running and connected for sql to work.
there are manual commands you can run on the sql server to break the mirror in an emergency and run it as a single instance again.
|All times are GMT -5. The time now is 12:55 AM.|
Powered by vBulletin® Version 3.6.12
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.