Of all the non-functional requirements for productionservers, the one with arguably the most severe potential business impact isthat of high availability and disaster recovery; the standard go-to solutionis, of course, clustering. But what if your application needs a singletonservice? Or what if you depend on the JTA transaction recovery service or aparticular JMS queue to be highly available? We certainly can’t just wrap upour managed server in cotton wool and hope for the best. These days, almost all conceivable services can be deployedto a cluster but there are still certain services, like those above, which mustbe pinned to a single server instance; for these, Weblogic supports failurerecovery with service migration as opposed to failover. It should be notedthat, as of Weblogic 12.1.2, it is nowpossible to target a JMS server to a cluster, but there are still otherJMS-related services which must be pinned to a single server!
Service level migration is moving one pinned service toanother server. Controlling what services get migrated is achieved with a logicalmigratable target – in other words, a logical grouping of services all hostedon just one server – and these migratable targets can be selected to deploy toin place of a cluster or server.
Migrating a service manually is generally not going to helpwith your high availability problem – at least, not directly – but it’scertainly something to be familiar with as part of a disaster recovery plan.WLST provides the “migrate”command as part of its category of “Life Cycle” commands, or you can usethe Admin Console. Relying on these two methods of migration in the case ofa failure will result in downtime, however, so we really need a method ofconfiguring this to happen without any user interaction.
To migrate services automatically, a migration policy mustfirst be configured. Under the covers, you will have already used a migrationpolicy if you have ever migrated a service manually, because the “manual”policy is the system default. The other options are “Exactly-Once” and “Failure-Recovery”which are very similar, but have a crucial difference:
- This policy is simple: if there is at least one managed server running out of the list of candidate servers, then Weblogic guarantees that the service will be running once, and once only, on any one of the available servers. Sound good? Beware of using this policy blindly, if only one candidate server comes up, then all migratable targets with this policy will be grouped together on that single server.
- This policy is very similar, but will only start a service if its UPS (user-preferred server) is started; once the service is started, it will be migrated to any other candidate server in case of failure. This differs again from the Exactly-Once policy in that the service will only be migrated if the server is shutdown unexpectedly – if an administrator shuts down the UPS either gracefully or forcefully, then the service won’t be migrated.
The key to using Weblogic’s service migration effectively isa good understanding of your business needs for each critical service. Will thetarget grouping of an “Exactly-Once” policy really matter to you if you onlyhave one service to migrate? Do you need to isolate your service to a veryshort list of candidate servers, or perhaps you want to specify a single serverto be a primary and other servers as backups?
Service migration still isn’t ideal – Oracle themselves showedit’s not the preferred way of doing things by introducing the capability oftargeting JMS servers to a cluster – but the pain of maintaining propermigration policies is far smaller than the pain of an outage of a criticalservice!