RSS 

How To: Upgrade a HA Pair (Part 2 of 3)

In this AskSupport How To video you will learn how to Upgrade a HA Pair (Part 2 of 3)

Tags: technical support netscaler how to
Views: 890
Rating: 5

Transcript : Now, so I’m going to drop into, actually I’m going to put this one… I read from left to right, so I have the primary on the left. I’m going to drop into the shell. Install. Okay. So there’s my install files there on the primary. I go into the shell of the secondary. Oops. 9.1. There we are. Okay. So there we have our build and our md5 hash file there, as well. Okay. So, what do we do next? We have to fast load it onto both appliances. The first thing we’re going to do is upgrade the secondary box. That’s right. We get the secondary box running the new version. So I’m checking here. Node ID: 0 is the south node. This means that, whenever we do Sho Node, Node 0 is the box that you are issuing the command from. So I know that it’s in an up state and it’s secondary. Right? So, let’s do this one first. It’s two commands, and that’s all. The first command is simply to extract the install files. The second command is to install it. And that’s it. It’s quite simple. So tar when it’s xvzf and the build file. Right? We don’t extract the doc bundle. Okay? This documentation bundle we leave as is. The install file will extract that for us and automatically deploy those PDF files to the correct location. So we type dot-slash. I’m just making sure I’m running this installns file here. Right? Just in case there is an installns script somewhere else in the path on the system. I want to make sure I’m running the correct one. Right? So I type: ./installns. We’re on the secondary box. And off it goes. So, here is an issue that you may come across, especially if you upgrade your boxes regularly. The flash card has run out of space. So it’s quite simple. It’s perfectly okay to say why to this. Okay. Normally we don’t like to let scripts do things for us, but this is quite safe. I’m going to let it archive the old releases. It’s going to pull some old builds off the flash card. It doesn’t delete them, it’s going to move them to the hard disk. So they’re still available to us. If we want to put them back on at a later point, that’s no problem. So it’s archiving those older releases. It may take some time to copy those off the flash card. While that’s running, I’m just going to step briefly back to the gooey, and we click on Documentation here. This is the location of all of our PDFs. Right? So here we can get Quick Start guides, the Hardware Installation and Setup Guide, the NetScaler Migration Guide--which is excellent in terms of describing the steps required to upgrade and downgrade—the Admin Guide, so on and so forth. Traffic Management. It’s all here, okay, loaded on the appliance. We don’t have to go anywhere else to get the documentation for the product. It’s all there. So…so this is completed. There we are. It’s…I’m going to close down my WinSCP. In the meantime, guess I’ll point this out. I am pinging here the VIP IP address of one of the load balance Vservers. So this is an IP, for example, it could be serving production traffic. I’m just running a ping on this. Just to make sure, for example, that we don’t have any outages. Just something I do just to demonstrate how we’re going to failover between the two later on. We shouldn’t…we should still, obviously, have production traffic flowing through our appliances. That’s the whole idea of a high availability pair. We can upgrade and reboot an appliance without losing any production traffic. So this is completed. I have the option to reboot now. I’m going to choose yes. So we are upgrading here from 9.0 to 9.1. I choose Y. It’s going to take a while for the box to come back up. Here we have an alert on our primary box, just saying, whoops, this node has now gone down. And that’s fine because we’re rebooting it. In the meantime, let’s prepare this system here, the primary, for an upgrade. So type the same command again: tar xvzf. And it’s just extracting that tar ball. We have to have the same builds in a HA pair. Not just only the same version, 9.1, but 98.5. That’s critical. So one of the things we do when we’re upgrading the HA pair, we will, once this is finished restarting, we can take a look at the config. Okay. We make sure that the config looks okay, that there’s nothing strange about it, that it isn’t empty. And…and, in that manner, we then verify that it isn’t missing anything. Because what’s going to happen next is, once this box comes back online, we’re going to install, we’re going to upgrade the primary box. And then when we restart the primary, this secondary box here, the one in blue, is going to take over production traffic. That’s the whole idea. If I do a sho node again, we see here that the secondary is in the unknown state. That’s because it’s not currently online yet. It’s still starting up. So it’s now coming online shortly. So, here we go. And we can see here, the box is online. We get ping replies. And we have on the console HA Version Mismatch. That’s correct, because we now have 9.1 running here, 98.5. And we have 9.0 running here. Right? Type: sho node. We can see that this is primary. The secondary is here. It’s in up status. Synchronization state is auto disabled. Propagation is auto disabled. It’s no point propagating 9.0 commands to a 9.1 box. Okay? They may have changed. And a few other things here which are unknown. Basically it’s a version mismatch at the moment. Now, if we go here to sho IP, we see the IP addresses. Sho IP. Okay? This all looks…it’s all in parity. Sho lb vserver. So in either event, there, that it’s up. Sho lb vserver. We see two vservers there. Test-gslb. Test-gslb. That’s down. That’s fine. It’s supposed to be down. And test-caching. Right? It says down. And test-caching here, which says state: up. Okay. The reason why it says state down is because, when the versions are the same, same major versions and same build numbers, we’ll actually propagate the service state to the secondary box. But at the moment, because they’re not the same, it’ll say state: down. We’re just making sure that the Vserver is actually there, the IP is there. This is the IP that we’re running our ping on. Okay? So once this Vserver goes…so once we failover, the ping reply should probably be coming from the secondary box.