Oracle IRM, the official blog

This article is way, way over due. I've had a few requests to describe how the Oracle IRM server can be setup in a high availability environment as described in my blog article here. It is possible to have a setup where more than one IRM server is in production and if one fails requests to the service are served from another IRM server, like the diagram below.

Note that running the Oracle IRM server in fail over mode in this manner is supported but load balancing is not. The IRM server has not been designed nor tested in a load balanced mode simply because the performance of the system is so good you don't need to load balance systems together. Fail over to protect against network and operating system failure is however key for any highly available service.

I must also state the very obvious. Rehearse this setup on test systems BEFORE doing anything with a live production system and when you do install and configure the live server you MUST backup your IRM database.

This article requires you have the following;

• A fully working Oracle IRM server
  
• Access to the Oracle IRM database server and schema
  
• A second server with network access to the database server and a valid database ODBC client installed
  
• A network device to monitor and direct the traffic between the two servers
  

If these are in place you can now install the same version of the IRM server on the second server.

Setting up a second or more Oracle IRM servers for failover

The Oracle IRM server installation process involves the following main activities.

• Deploy binaries to local file system, by default in;
  • C:\Program Files\Oracle\Information Rights Management
• Write some registry keys
• Write out a configuration file called server.properties in the properties folder
• Build a schema in the database the installer has been pointed at
• Create a superuser account

In a highly available fail over environment you configure the server to talk to a single database instance which represents a cluster of nodes. I have however seen customers setup two IRM servers, each with their own database and have a mechanism like log shipping ensure that the standby server database is up to date for when a fail over happens. However my own experiences with log shipping and other methods find that the effort, time and risks involved are such that you might as well configure both database servers in a clustered mode. So in this article i'm going to prepare my IRM server against a common clustered instance of the database.

Before we get into the installation, it is worth understanding the server startup procedure.

• Read in the server.properties in the properties folder.
  
• Connect to the database using the connection string sealedmedia.server.persistence.database.odbc.connectionstring.encrypted from the file. Note this is obviously encrypted because it contains the username and password to the database.
  
• Load the plugins as specified in the setting sealedmedia.server.plugins in the properties file.
  
• Read the configuration for the server in from the table [prefix]config where [prefix] is the string from the setting sealedmedia.server.persistence.namespace in the file.
  
• Open and start logging to both the audit and log files as specified by the file stored settings;
  • sealedmedia.server.logging.destination
    
  • sealedmedia.server.logging.destination
  
  
• Open and start logging to the web log file determined by the database stored config setting sealedmedia.server.web.logging.path
  
• Start listening on the ports and IP addresses as specified in the sealedmedia.server.internal.port and sealedmedia.server.internal.bind as well as the .external. equivalents
  

Forcing configuration settings to the local IRM server installation

The above highlights some configuration information comes from the local properties file and some is gained after the server connects to the database. This presents a problem because there are some settings that reside in the database that might be specific to the local installation, such as logging directories. No worries, because there is a mechanism to have the server get settings from the local properties file and ignore the database. Open the server.properties and look for the line;

sealedmedia.server.persistence.localsettings=

This lists all the other properties which should be read from the local file and not from the database, by default these are;

sealedmedia.server.logging.destination
sealedmedia.server.audit.destination
sealedmedia.server.plugins
sealedmedia.server.component.config.encryption.activated
sealedmedia.server.nt.servicename
sealedmedia.server.external.port
sealedmedia.server.external.bind
sealedmedia.server.internal.port
sealedmedia.server.internal.bind
sealedmedia.server.plugins.port
sealedmedia.server.plugins.bind

There is a slight oddity here in that one more log setting resides in the database which should ideally be a localised one. If you install both IRM servers in exactly the same location, it doesn't matter, but if they change you'll need to add this setting to the sealedmedia.server.persistence.localsettings line;

sealedmedia.server.persistence.localsettings=sealedmedia.server.logging.destination, sealedmedia.server.audit.destination,sealedmedia.server.plugins,sealedmedia.server. component.config.encryption.activated,sealedmedia.server.nt.servicename,sealedmedia. server.external.port,sealedmedia.server.external.bind,sealedmedia.server.internal.port, sealedmedia.server.internal.bind,sealedmedia.server.plugins.port,sealedmedia.server. plugins.bind,sealedmedia.server.web.logging.path

Then create a new line like the one below in the properties file. Note that in the properties file you need to escape all the backslashes so that the line below would have C:\\Program Files\\Oracle\\Infor... and so on.

sealedmedia.web.logging.path=C:\Program Files\Oracle\Information Rights Management\IRMServer\bin\..\log

Another aspect we need to consider is that of caching. It is advisable that all the caches on all the servers are disabled. The modern servers typically used to deploy IRM mean that switching off the caches doesn't really impact performance and only increases slightly the emphasis on the importance of reliable and fast database connection. Switching off the caching means that as you fail from one server to the next you are assured that serviced requests hit data in the database and that stale information is not delivered from the cache or written lazily to the database. Because we want to disable this on both servers we don't need to localize the settings, we can make the change to the values in the database. It doesn't matter when you do it, pre or post install, but here's how to disable all the caching.

Disabling the Oracle IRM server cache

Changes to the settings that reside in the database is done using the smconfig.exe tool that resides in the IRMServer\bin directory. There are three environment variables that are worth setting so you can just run smconfig without passing in the connection details each time. So start a command prompt on your existing IRM server installation and run the following, obviously changing in your own URL, ACCOUNT and PASSWORD;

T:\Oracle\IRMServer\bin>set ORACLE_IRM_SERVER_URL=seal://localhost:2001 T:\Oracle\IRMServer\bin>set ORACLE_IRM_SERVER_ACCOUNT=superuser T:\Oracle\IRMServer\bin>set ORACLE_IRM_SERVER_PASSWORD=p455word T:\Oracle\IRMServer\bin>smconfig -server ping

Important to note here is that this tool uses a port you may not be familiar with, 2001. This is the API port and is what the configuration tools for IRM use. By default this is enabled but you may have switched it off. You can re-enable this by connecting to the server using the Management Console as the superuser and under settings there is an API traffic applet where you can set the port and what addresses the server will listen on. If this is all working then the above ping command should return;

Oracle IRM Server configuration tool. Copyright (c) 1996, 2008, Oracle. All rights reserved.

Connecting to [IRM Server]

seal://localhost:2001 is alive.

Excellent, now lets change the caching settings;

smconfig -setconfig sealedmedia.server.component.account.cache -value no
smconfig -setconfig sealedmedia.server.component.security.cache -value no
smconfig -setconfig sealedmedia.server.component.publisher.cache -value no
smconfig -setconfig sealedmedia.server.component.group.cache -value no

You can check all the settings in the config by running;

smconfig -show config

Installing the Oracle IRM server

Finally time to install the second server, start the installer hit next and ensure you select custom for the setup type.


Then choose your installation directory. Remember that if this is different from your first server you'll need to ensure your web logging root is configured for this local instance.


Setup the ODBC connection to the clustered database using the same account credentials to connect.


This is now the key area of the installation. The second field MUST be changed to be different from the first server otherwise you are going to drop and recreate all the tables for the production system!


The server name might want to reflect the failover server and it doesn't matter what the superusers details are because we will delete this data after install.


Network settings are important, make sure these reflect the public hostname you have for the service and that it is listening on the correct local address. This address will be what the fail over network device will redirect traffic to.




It is typical to have the service start as the local system account.


Logging again is configured locally, you might want to consider having the server write to a shared drive where both servers store logs in a common area. Note if you do this, you may need to change the previous service account details so that the server runs under a user that has permissions to write to the shared folder.



Finally you are ready to go. Before hitting install make sure you've done a backup of the database.

Nearly there! Now lets configure the environment so that the server points to the right data and not the fresh schema it has just created.

• First of all stop the Oracle IRM server service
  
• Open the server.properties and change the setting sealedmedia.server.persistence.namespace to reflect the correct namespace which by default is irm
  
• If you need to, edit the sealedmedia.server.persistence.localsettings and add sealedmedia.server.web.logging.path details as explained previously in this article.
  

Now you can start the second IRM server to test it can connect. Use the Management Console on the local machine to connect to the local instance and just browse a few users to check. You can leave the IRM server running and connected as long as no traffic is directed to it. There is no support for a system which has two IRM servers talking to the database at the same time and could potentially result in corrupted data. The network device needs to be configured to monitor the primary server and when this isn't available, direct the requests onto the secondary. Testing from outside the local network you can determine which server is responding to the requests by using the following URL in any web browser.

http://irm.domain.com:80/ping

This will return;

[IRM Server,SECONDARY_SERVER,5.4 release 5 build 10,19 Jun 2009 19:24:11 UTC]

Where SECONDARY_SERVER is the netbios hostname of the Windows server that the IRM server is running on. This can be a useful URL for any monitoring tool to determine what service is currently active.

As a post clean up activity you may now wish to delete the tables that were created, there are also a few stored procedures, functions and packages depending on the database type you are using. You can drop the ones with any prefix which matches your secondary installation.