How-to: rolling upgrade WebLogic 11g to 12c

How-to: rolling upgrade WebLogic 11g to 12c

Published on: Category: Java & Web

A lot of companies are currently working on upgrading Weblogic 11g to 12c. In this blog you can read how the upgrade can be done like a rolling upgrade. With the presented plan you can perform a rolling upgrade with nearly no downtime at all.

For a customer in The Netherlands, Qualogy was asked to help in an upgrade of the WebLogic 11g platform to 12c. There was requested to do this like a rolling upgrade. However, Oracle only supports rolling upgrades for individual patches, patch bundles, and patch set updates. It turns out that a rolling upgrade can be done with only minor adjustments to the upgrade plan.

A common approach is building a new environment next to the current one. The traffic will then be switched gradually from the current environment to the new one. This is a solid, but also resource intensive approach, as it requires additional machines. Using the rolling upgrade we can keep using the same machines and thus annul the cost and hassle of (temporary) extra machines.

The environment

In our case the WebLogic environment is located behind two Apache servers. The Apache servers will loadbalance the http(s) traffic between the Managed Servers. In turn, the traffic for the Apache servers is loadbalanced by a hardware loadbalancer.

The WebLogic environment (simplified)

How-to

A rolling upgrade means we will do the upgrade one node at a time. To minimize downtime the traffic will be diverted to the other node, until the node has been successfully upgraded. It is necessary to block the internal WebLogic communication between the 12c environment and the 11g environment. If this is not done, issues can arise when deploying to clusters.

Also the following error can appear in your logfiles:
java.lang.NullPointerException
at weblogic.cluster.messaging.internal.GroupManagerImpl.mapServerNameToGroupNo(GroupManagerImpl.java:182)

This can be prevented by using iptables rules as shown below. These rules can later be removed by replacing the -A with -D.

Added iptables rules
  1. iptables –A INPUT –s <admin-ip> -j REJECT –reject-with-icmp-port-unreachable
  2. iptables –A OUTPUT –m state --state NEW –d <admin-ip> -j DROP
  3.  
  4. iptables –A INPUT –s <node1-ip> -j REJECT –reject-with-icmp-port-unreachable
  5. iptables –A OUTPUT –m state --state NEW –d <node1-ip> -j DROP
The iptables rules illustrated

The plan

The upgrade itself can be done in multiple ways. Oracle also provides the WebLogic Upgrade Wizard. It is best to read this Oracle documentation to see which steps are relevant for your environment.

The outline of an upgrade from WebLogic 11g to 12c is displayed below:

  1. Configure http2 to only send the traffic to the Managed Server on Node2, including a graceful restart of http2.
  2. Redirect all traffic from the loadbalancer to http2. Alternative: shutdown http1.
  3. Shutdown the Managed Server running on node1.
  4. Shutdown the Admin Server.
  5. Add the iptables rules on node2 to block all communication between node2 and the other servers in the domain.
  6. Upgrade the Admin Server to 12c.
  7. Start the Admin Server.
  8. Upgrade the Managed Server on node1 to 12c. (incl. Node Manager)
  9. Start the Managed Server on node1.
  10. Perform a regression test on node1.
  11. Configure http1 to only send the traffic to the Managed Server on node1, including a graceful restart of http1.
  12. Redirect all traffic from the loadbalancer to http1. Alternative: shutdown http2.
  13. Shutdown the Managed Server running on node2.
  14. Remove the previously added iptables rules.
  15. Upgrade the Managed Server on node2 to 12c. (incl. Node Manager)
  16. Start the Managed Server on node2.
  17. Perform a regression test on node2.
  18. Configure http1 and http2 to send the traffic to the Managed Servers running on node1 and node2, including graceful restarts.
  19. Configure the loadbalancer to direct the traffic to both http1 and http2.

I want to thank Thijs Kaper for his part in solving the issues and performing the upgrade.

Maarten Droogendijk
About the author Maarten Droogendijk

More posts by Maarten Droogendijk
Comments (2)
  1. om 10:10

    You wrote:

    "It is necessary to block the internal WebLogic communication between the 12c environment and the 11g environment. If this is not done, issues can arise when deploying to clusters."

    Does that not only apply to a cluster communication with unicast and not multicast? Since multicast should use backward compatibility .

    source quote:
    "Note: When creating a new cluster, it is recommended that you use unicast for messaging within a cluster. For backward compatibility with previous versions, WebLogic Server you must use multicast for communications between clusters."

    source site:
    https://docs.oracle.com/cd/E11035_01/wls100/cluster/features.html

  2. om 12:12

    Please share the detailed steps.

Reply