Plan the rolling upgrade procedure

You must plan the steps of the rolling upgrade procedure to install a fix pack to IBM MobileFirst Platform Foundation without downtime.

You must review, adapt, and test this upgrade procedure for your production environment. Other components that interact with IBM MobileFirst Platform Foundation in your production environment might require extra steps or changes to that procedure.

The goal of this procedure is to switch HTTP-based traffic from a previous installation of Worklight Server to an upgraded installation of MobileFirst Server. This is done without losing any data in the former Worklight databases, and without visible impact for users of applications that have an active session while this procedure is applied.

If other protocols than HTTP are used by some components of your application to interact with the MobileFirst Server, then you must include in the upgrade plan a way to route that traffic during a rolling upgrade procedure.

For example, if we use a pull mechanism for push notifications, you must review the risk of double notification or lost notification in a rolling upgrade procedure. See Possible MobileFirst push notification architectures.

You must review, with the development team, the code of all your adapters to identify extra steps that might be required for a rolling upgrade procedure. This is the case especially if these adapters require external resources, or use other communication protocols than HTTP, such as JMS or WebSphere MQ.

During the rolling upgrade, you must also stop management operations, such as uploading a new application or a new adapter to the console. If a new version of a MobileFirst application or adapter is uploaded to the MobileFirst Server during the upgrade procedure, some servers on the clusters might not be notified of this change and might continue to operate with the old artifact. If a new MobileFirst application is uploaded to the MobileFirst Server and the runtimes do not all have the same version, it might trigger arbitrary direct update sessions for the users of MobileFirst apps, depending on the server to which they were routed. Identify all MobileFirst administration users that have a privilege to upgrade an application. Their role is defined as worklightadmin or worklightdeployer. Then notify them of the beginning and the end of the rolling upgrade. During that period, they must not upload any adapter or application.

This procedure requires to temporarily duplicate the environment. You might find it convenient to apply this procedure at a period of low traffic, so we can use existing hardware resources for the servers of the new environment. You must double the number of instances of WebSphere Application Server during the rolling upgrade, and the hardware must have enough memory to run these servers without paging. The CPU requirements must not increase significantly during that procedure because the use on the servers that are being brought online would ramp up as new sessions get routed to the new version of the application. The CPU use on the servers that run the old version of the application must ramp down as existing sessions end.

Parent topic: Rolling upgrade procedure to apply a fix pack to MPF v6.3.0