Clarity

  • 1.  How do you guys handle an off-site Disaster Recovery plan?

    Posted Jul 18, 2011 05:19 AM
    I am working on setting up an off-site copy for disaster recovery.

    Our Clarity (v 12.0.5) using SQL Server and Actuate 9 is rather simple, consisting of one production app server (Windows Server) and a separate database box (SQL Server).

    Our company has a computer center in a different city which makes it perfect for establishing a Disaster Recovery copy.

    The database replication is already taken care of by the DBA support team. My question here entirely relates to the app server for Clarity. For the sake of transparency I will comment here that being afraid of making a mess we actually copied our local Development server to the remote location as a proof of concept. We would like to run DEV remotely from the Disaster Recovery location for a few days to see how things behave, before we do this in Production.

    We cloned the local copy this weekend (after turning Clarity services off for the clone). Now I have a copy that we can transfer and install in a prepared VM in the remote location.

    Before we proceed to the next step (setup and use) I'd like to get some best practices advice from people that have already done this.

    We understand we should never have both boxes on in the same Domain (LAN) at the same time, as both talk to the same database which will make a mess. Avoiding data corruption is obviously highest in our priorities.

    The new remote app server now has a copy of the local server. It has not been made part of the domain and turned on yet until we understand the ramifications.

    The remote machine (virtual) has a separate IP Address, machine name and subnet, being in another city, but the copy it received is a clone of the local box so internally Clarity will think it has the same name and IP Address as the local box. How do we resolve this? What kind of issues will I find? I can turn NSA on and adjust everything I need there before we use it. For this test we plan to use the remote box with the local database as the database replication is not at issue in this test).

    Any insight appreciated.

    Alex


  • 2.  RE: How do you guys handle an off-site Disaster Recovery plan?
    Best Answer

    Posted Jul 18, 2011 06:02 AM
    My understanding is that with SQL server it does not matter for Clarity or MS SQL functionality if the IP is different. It is a question of getting to the login of the app server.
    Ideally you would want the the user to be able to go to the same URL which means that there has to be a name server which ties the IP to the name.
    Alternatively you would use the IP as the URl and in order to keep that the same you would have to over come the issues you pointed out.
    If you manage to have two servers with the same name and IP up at the same time you get error messages about that.

    If your NSA configuration is the same your copied server starts communicating with the database as soon as the services are up even with no user logged in.
    So you are right in saying not to have them up at any point at the same time. When you change, you should have a method for securing the that the prod server is really down before you turn on the copy and any time while you have the copy running.

    Don't recall if there is anything required for Actuate. BTH aren't you supposed to have Actuate 9 with Clarity 12?

    You have a similar situation when you have VMWare virtual machines for testing: Usually you start with one, make a copy for upgrade or variation of the content. Eventually you have a small number.
    With SQL server you can have more than one up at the same time. You get the error about the server name, but the DHCP server usually takes care of the different IPS' if you use DHCP.
    You can also access simultaneously running VM's having the same name if you use IP as the URL.

    Martti K.


  • 3.  RE: How do you guys handle an off-site Disaster Recovery plan?

    Posted Jul 18, 2011 10:15 AM
    It is Actuate 9 (corrected it).

    I forgot to mention the DNS issue. Yes of course we will change the DNS to point to the new server so it should be transparent for users.

    The question gears more towards what else is kept internally that the DNS will not resolve (IP, file in the cloned copy still mentioning the local server name as it has no knowledge it is now in a different server).

    The plan for any switch (e.g. disaster) is to make sure the local machine is physically off so we guarantee they are never both on on the same domain. That's also why I turned off all Clarity services (niku stop all) before we made the clone.

    So you see no other conflicts once the DNS is repointed? I will be testing thoroughly (exercising the system) once we turn the remote one on (it is now a copy of DEV for testing). I will find out how Actuate reacts to it.

    My main concern is avoiding conflicts and database corruption.

    Thanks,

    Alex


  • 4.  RE: How do you guys handle an off-site Disaster Recovery plan?

    Posted Jul 18, 2011 08:23 AM
    Those were thew things that came into my mind, not having actually done that.
    Though I do have VM's from 7.02 up. Another difference with them is that the databse is usually on the same VM so the possibility to mess with the database is smaller.

    Martti K.


  • 5.  RE: How do you guys handle an off-site Disaster Recovery plan?

    Posted Aug 02, 2011 08:26 AM
    Continuing with this issue, we created an image of our test app server as a proof-of-concept, and used it to create a virtual app server (12.0.5) in our remote location. We turned off the test/dev app server - as we cannot/should not have both instances on at the same time, talking to the same database. We repointed the internal DNS (http:\\claritytest) to this new VM and started the services.

    NSA works fine, and has - of course - all the pointers to the old box (as it is an image). We repointed every instance to the new logical app server name.

    Actruate 9 services refuse to start. They give an error. Upon inspection we see they are also hard-coded to the old app server (the one now turned off). How do I repoint that to eliminate Actuate 9 dependency on he turned off server?


  • 6.  RE: How do you guys handle an off-site Disaster Recovery plan?

    Posted Aug 02, 2011 05:24 AM
    After some fix pack installs Actuate just did not want to start. It was less pain to reinstall than to get to bottom why it would not.

    Martti K.