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

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.

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.

iptables –A INPUT –s <admin-ip> -j REJECT –reject-with-icmp-port-unreachable
iptables –A OUTPUT –m state --state NEW –d <admin-ip> -j DROP
 
iptables –A INPUT –s <node1-ip> -j REJECT –reject-with-icmp-port-unreachable
iptables –A OUTPUT –m state --state NEW –d <node1-ip> -j DROP

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.

Over auteur Maarten Droogendijk

Als Oracle Fusion Middleware Consultant help ik klanten bij projectwerk en het beheer van hun Middleware-omgevingen. Ik ben dagelijks bezig met het configureren, testen en implementeren van voornamelijk technische wijzigingen. Ook zet ik monitoringoplossingen op en ondersteun ik bij het automatiseren van handmatige acties (bijvoorbeeld deployment automation). Verder besteed ik graag de dag aan het troubleshooten van incidenten en problemen in de Middleware-omgevingen.

Meer posts van Maarten Droogendijk