Topic
  • 3 replies
  • Latest Post - ‏2009-01-08T20:27:54Z by ricky1
BruceMFB
BruceMFB
1 Post

Pinned topic RAM data in database - how to set up a Disaster Recover Instance

‏2009-01-07T22:22:31Z |
I have couple of questions regarding the RAM data in database and on local file system that is the single file system for a clustered server environment using WAS ND and a Oracle database.

1.To setup DR for RAM, we plan to have a cron job which runs every 5 minutes and copies the persist and local folders
from primary machine to the secondry DR machine. Now the question is: Assuming most of the data is stored in Database. If not, can the RAM instance on the DR side operate with local files not being upto date to get it into a running and consistent state. As it may loose 5 minutes worth of local store data.
Is the 5 minutes syncing time ok ?
Are there any other complication we need to be aware of ?

2.How does RAM behave if we have issues with the database failing in a clustered server environment, such as it is failing and switching over. Does it automatically reconnect or does it need a restart ?

3. Would this be a recommended approach for setting up a disaster recovery instance for RAM:
On the DR system that is configured with the same level of OS and WAS ND instance.
A. Restore the RAM Oracle database.
B. Restore the 2 file systems (Persist and Local) in the same relative file structure as on the failed system. (i.e. /opt/RAM/...)
C. . Restore the WAS ND configuration (presuming that the DR site already has WAS ND, and RAM installed)
D. Configure the DR installation to use the RAM Oracle file system using the RAM Server Set-up Utility. The utility will validate the database has been configured correctly.
E. Configure the LDAP server access to point to the right LDAP server using the RAM Server Set-up Utility. Test the connection with the RAM Server Set-up utility. Make sure the sys admin user id is validated by the RAM Server Setuo utility..
F. Configure the DNS servers / Http servers to route to the new host and add any server re-directs in the Http server configuration file..
G. Start-up RAM in the DR environment.
Updated on 2009-01-08T20:27:54Z at 2009-01-08T20:27:54Z by ricky1
  • ricky1
    ricky1
    84 Posts

    Re: RAM data in database - how to set up a Disaster Recover Instance

    ‏2009-01-08T15:19:03Z  
    Hi,

    A lot of these questions haven't been pursued, but I'll take a shot:

    1.To setup DR for RAM, we plan to have a cron job which runs every 5 minutes and copies the persist and local folders
    from primary machine to the secondry DR machine. Now the question is: Assuming most of the data is stored in Database. If not, can the RAM instance on the DR side operate with local files not being upto date to get it into a running and consistent state. As it may loose 5 minutes worth of local store data.
    Is the 5 minutes syncing time ok ?
    Are there any other complication we need to be aware of ?

    >> You don't actually need to copy the local data. All local data can be reconstructed if needed. However, there is an advantage if you have a large index. Depending on the number of assets you have it may take several hours to recreate the index if it is lost. But there may be a problem with copying the index in that it is actually composed of a set files, and if you try to copy them some may be locked due to be accessed or you may copy some that then go t subsequently changed and you would have an inconsistent copy of the index.

    >> Is your CRON job smart enough to do incremental backup? The persist area can become huge but it won't be changing that often, so you don't want to do a complete copy every five minutes.

    >> What is maintained in the database is references to the paths of files in the persist area. It is best if the database backup and persist area are copied at the same time with RAM being down. Such as in the middle of the night. Then you would not have any inconsistencies. We haven't explored how to do an online backup of database and persist area.

    2.How does RAM behave if we have issues with the database failing in a clustered server environment, such as it is failing and switching over. Does it automatically reconnect or does it need a restart ?

    >> We just use standard database connections. Each application server maintains a connection pool to the database, so if an application server goes down the other servers have their own connections. As for clustered database, we don't know anything about Oracle's capabilities in that area. We've only tested non-clustered Oracle.

    3. Would this be a recommended approach for setting up a disaster recovery instance for RAM:
    On the DR system that is configured with the same level of OS and WAS ND instance.
    A. Restore the RAM Oracle da...

    >> You should also back up the Websphere profile when you install RAM so that you restore it to look identical to what it was. That should handle setting up correctly your WAS configuration. But if you don't then it is basically what you said.
    >> But an important point to remember is if you did change the DNS path you need to change the server paths inside the RAM setup utility too to point to the new paths.
  • SystemAdmin
    SystemAdmin
    217 Posts

    Re: RAM data in database - how to set up a Disaster Recover Instance

    ‏2009-01-08T20:00:01Z  
    • ricky1
    • ‏2009-01-08T15:19:03Z
    Hi,

    A lot of these questions haven't been pursued, but I'll take a shot:

    1.To setup DR for RAM, we plan to have a cron job which runs every 5 minutes and copies the persist and local folders
    from primary machine to the secondry DR machine. Now the question is: Assuming most of the data is stored in Database. If not, can the RAM instance on the DR side operate with local files not being upto date to get it into a running and consistent state. As it may loose 5 minutes worth of local store data.
    Is the 5 minutes syncing time ok ?
    Are there any other complication we need to be aware of ?

    >> You don't actually need to copy the local data. All local data can be reconstructed if needed. However, there is an advantage if you have a large index. Depending on the number of assets you have it may take several hours to recreate the index if it is lost. But there may be a problem with copying the index in that it is actually composed of a set files, and if you try to copy them some may be locked due to be accessed or you may copy some that then go t subsequently changed and you would have an inconsistent copy of the index.

    >> Is your CRON job smart enough to do incremental backup? The persist area can become huge but it won't be changing that often, so you don't want to do a complete copy every five minutes.

    >> What is maintained in the database is references to the paths of files in the persist area. It is best if the database backup and persist area are copied at the same time with RAM being down. Such as in the middle of the night. Then you would not have any inconsistencies. We haven't explored how to do an online backup of database and persist area.

    2.How does RAM behave if we have issues with the database failing in a clustered server environment, such as it is failing and switching over. Does it automatically reconnect or does it need a restart ?

    >> We just use standard database connections. Each application server maintains a connection pool to the database, so if an application server goes down the other servers have their own connections. As for clustered database, we don't know anything about Oracle's capabilities in that area. We've only tested non-clustered Oracle.

    3. Would this be a recommended approach for setting up a disaster recovery instance for RAM:
    On the DR system that is configured with the same level of OS and WAS ND instance.
    A. Restore the RAM Oracle da...

    >> You should also back up the Websphere profile when you install RAM so that you restore it to look identical to what it was. That should handle setting up correctly your WAS configuration. But if you don't then it is basically what you said.
    >> But an important point to remember is if you did change the DNS path you need to change the server paths inside the RAM setup utility too to point to the new paths.
    Hi Ricky1,

    Thanks for clarifying on the DR topic.

    A question though, as regard to your answer 1, para 3.

    What if in place of cron job, we make DR RAM instance share the file system with Primary RAM via NFS. This way the persist is always same for both.

    With above scenario, it raises further questions as to does RAM allow 2 of instances share same database at same time ? or one needs to keep only one active and other in standby(shutdown) mode until DR occurs ?

    Appreciate your response.

    Sanjeev Nagpal
  • ricky1
    ricky1
    84 Posts

    Re: RAM data in database - how to set up a Disaster Recover Instance

    ‏2009-01-08T20:27:54Z  
    Hi Ricky1,

    Thanks for clarifying on the DR topic.

    A question though, as regard to your answer 1, para 3.

    What if in place of cron job, we make DR RAM instance share the file system with Primary RAM via NFS. This way the persist is always same for both.

    With above scenario, it raises further questions as to does RAM allow 2 of instances share same database at same time ? or one needs to keep only one active and other in standby(shutdown) mode until DR occurs ?

    Appreciate your response.

    Sanjeev Nagpal
    I'm not quite sure what are you trying to say, but you can't share the same persist area with two different RAM databases. And you can't have two different RAM servers running using the same database and persist area unless they are in a cluster and the servers are part of the same cluster.

    When in a cluster the persist area must be a shared drive. All nodes in the cluster must see the same persist area. All nodes in the cluster will use the same database instance. Because you have to have JMS setup in a cluster with RAM we can know about the other servers in the cluster and the servers can notify each other of important changes they need to be aware of.

    From what I understand a DR instance is supposed to be entire copy of the original installation because it would need to be running since the original instance was destroyed. So it must be started from backups and not live data.

    Rich