planning high-availability and disaster recovery

mibusedmibused Member Posts: 3
Hi all,
we currently have a low/mid-sized Navision 4 SP1 deployment, about 200 users and a number of companies.
The system is up and running on a single robust server machine, a xeon dual core with 4gigs and raid5 on scsi drives, windows 2003SP1, NAS and DB (SQL2000), all in one box. At night a batch file syncs NAS with a remote instance of Project Server.

Right now we do nightly db backups on a daily basis, but that means, in case of a major hardware/software failure, i could have 200 users doing nothing while i call support and wait 4 hours for the initial diagnoses of the failures, which is fairly acceptable as this could even mean a 2 days of forced vacations for everyone and losing all the data edited within the last 24 hours.

Our solutions partner doesn't seem to know how to go HA, i was told a very few deployments have ever been done with clustering with odd results, and i suppose, from the answer i received, none was runned by them.

Here are a bunch of questions for you the Experts:

- We have ESX in place in a san environment, that could help i suppose, but still will be a virtual machine the best way to move?
- Can two Navision instances stay up together without licenses troubles?
- Is the SQL cluster the right option or would you prefer replication or log shipping?

OS and SQL licenses are not a big deal, we already own a couple of unused SQL2005EE and WS2003EE licenses.

thanks

Comments

  • nunomaianunomaia Member Posts: 1,153
    In partnersource there is a document called "Microsoft Business Solutions-Navision 4.0 on MS Cluster Server" I think you should ask it to your current solution partner.

    I guess there isn’t any problem to use Navision license in a standby server if you use only one server at the time, so you can't get around about user license limit.

    SQL cluster probably it the best choice, log shipping could bring problems if users selected the 2 servers and the same time.
    Nuno Maia

    Freelance Dynamics AX
    Blog : http://axnmaia.wordpress.com/
  • fufikkfufikk Member Posts: 104
    It's also a good idea to read about SQL Server and maintaining high availibility - I believe its the hardware and proper SQL config to be succesfull...
  • mibusedmibused Member Posts: 3
    nunomaia wrote:
    In partnersource there is a document called "Microsoft Business Solutions-Navision 4.0 on MS Cluster Server" I think you should ask it to your current solution partner.

    [...]

    SQL cluster probably it the best choice, log shipping could bring problems if users selected the 2 servers and the same time.

    from what i've read (i could find that document somewhere on the net, thanks for the file name), they have successfully tested an active/passive environment with sql data on a shared array/drive which is, correct me if i'm wrong, a big point of failure.

    what i was looking for is a realtime/scheduled replica of the db, for instance two machines with their internal/san dedicated storage where each of them owns an updated copy of the DB, e.g. like RAID1, read from one unit but write to both.


    fufikk:

    That's a good point, but i suppose i could find many ways more suitable than clustering for high availability and maybe none of them would be ok for Navision


    thanks
  • clustering only protects against physical server failure - it does not protect against data damage or loss and it still leaves the disk subsystem as a single point of failure.
    Most DBA's use log shipping for DR, it's simple to set up and maintain and it allows for lots of variations in scope, it doesn't give real time protection though - about 5 mins data loss is the least you can reasonably expect.
    You need to differentiate between availaibility of a system and protection of data.
    I don't know if you can use SQL replication with Navision - not looked at that yet. SQL 2005 also allows database mirroring which if between clustered servers gives high availability - it won't protect against malicious data loss though unless you maintain transaction logs and backups.
Sign In or Register to comment.