NetScaler 11.1 to 12 Migration Review

I recently had the opportunity to upgrade Citrix Netscaler from v11.1 to v12 for a client. It was a relatively simple load-balancer on a stick architecture with high availability (HA) active/passive pair, so seems super easy, right? It was…mostly. I had two bumps along the way, so I wanted to put this out there. Oh yeah, this is also an appliance pair, but I’m withholding the model. Here are the Citrix recommendations for the process below.

I’m a new kid on the networking block, so I wanted to do this via the web GUI. This couldn’t be much simpler. After logging in on a NetScaler, click Configuration on the bar, which would put you in System. Herein lies the System Upgrade button; however, we’re not ready for that. This is an HA pair and we want to control our fail-overs.

Prep for Upgrading the Secondary Device

So you should just be able to upgrade your secondary device, right? Yes. The primary will see the secondary down and just keep on trucking…assuming you don’t run into a bug. Well, my boss will light me up if I trip over a bug and take down production, so let’s control this process.

First, we log into our primary box, navigate into System/High Availability, select the primary load-balancer, and click edit. This is also a good time to save any changes to the running-config, which will be noted as a orange dot on a blue file (seen in the top right of the snippet below. Mine’s grayed since there are no pending changes).

HA_Primary_1

In Configure HA Node, pull down the High Availability Status dropdown, select “Stay Primary” and hit the Okay button at the bottom of the form.

HA_Primary_1_2

In the High Availability page, the node state should now say STAYPRIMARY.

Now I log in to the secondary NetScaler and repeat this process, but this time I’m putting the secondary box into “STAYSECONDARY.” If you have HA Synchronization and HA Propagation checked checked as I do in the screenshot above, you can technically configure the secondary into stay secondary from the primary, but I don’t. I don’t like to wait for the config to propagate and I need to verify on the secondary that it’s correct anyways.

Once Primary is in stay primary and secondary is in stay secondary, it’s time to upgrade.

Upgrade Secondary Device

From the GUI on the secondary node, open the main System page and click System Upgrade.

System.PNG

Seen below, the GUI allows you to select the build from either your local machine or the appliance. Last time I updated one of these, the local file upload did not work, and would just spin after the upload  I tried it anyway, which failed miserably on IE, Chrome, and FireFox. I opened FileZilla client and transferred the build file to /var/nsinstall. Now I can select the file from appliance in the Select Firmware drop-down. Put a check-mark in Reboot after successful installation and click upgrade. A black progress box will pop up. In my experience, it’s not terribly trustworthy. Both of the ones I upgraded took almost exactly seven minutes each from clicking upgrade to logging back into the GUI. Go get some food and hit the bathroom. Maybe not in that order.

SystemUpgrade

Once the GUI comes back up, it should look slick indicating a successful upgrade. Need more proof? I do, but I somehow can’t find the build in the GUI since version 11, which Citrix swears is at the top of the screen. I SSH into the box and run > show version. It should reply with something like NetScaler NS12.0: Build redacted.nc, Date: Sep 22 2017, 09:11:54. I verify the back-end applications are functioning and your active users are happy. We’ve won half the battle. Now its time to break the network.

Prep for Upgrading the Primary Device

This shouldn’t break the network, but any sessions will need to renegotiate. If you’ve been following along and haven’t told your change board (shame on you), go tell someone because it’s fail-over time.

Log into the primary and secondary nodes, go back into System/High Availability, and set them both to ENABLED, changing the primary first. Let it bake for five minutes. Now since we don’t want to send commands from v12 to v11 (because that would be begging to hit a bug), from the v11 unupgraded primary node put a check in the primary’s checkbox, click the Action drop-down, and select Force Failover. There may be a pop-up or there may not. I don’t remember and this screenshot is in production so I’m not really gonna do it.Fail_Over_1

Confirm on the upgraded node that it’s now showing primary and the v11 is showing secondary. If that’s fine, go back into System/High Availability on both nodes and set the v12 node to STAYPRIMARY and v11 node to STAYSECONDARY. Verify this change and we’re ready to upgrade the remaining device.

Upgrading the Remaining v11 Device

I’m not going to rewrite this part, so in short: transfer the build file to the v11 node, upgrade it, and make sure it upgraded successfully. Now go back into System/High Availability on both devices and put them both back into ENABLED. I like to force one more fail-over to make sure both devices both handle traffic well. That’s it. As for the other bump I mentioned, it was my fault and I don’t want to talk about it. Hope this guide can help some of y’all out.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s