Lessons from the Field: NetScaler MPX to SDX Conversion
I was recently working with a customer on a NetScaler SDX deployment to replace their existing MPX appliances. Once piece that was in scope of this project was that the configuration be migrated from their existing production MPX's to a VPX hosted on the new SDX appliances.
Before performing this conversion process I needed to review several things within the configuration and with the customer. Doing so would help me understand exactly how the NetScaler was being utilized and how to provide this conversion with no downtime. This particular customer had identical infrastructure and capacity in both a primary and backup site and were using the NetScaler as a load balancer and ICA proxy. They were also using Global Server Load Balancing (GSLB) on a separate pair of NetScalers to perform site failover that were not being modified. This configuration allowed for all systems to be up and available while each MPX cutover was completed. This thought process will help you understand the touch points when migrating configuration from a physical MPX appliance to a VPX running on SDX.
Testing is Key, Have a Plan
A test plan is a key piece to the conversion puzzle but is something that will often get missed. We know that testing needs to be completed after the conversion process is done but you also want to make sure everything is working as expected before making any changes. This can be beneficial in two ways, the first being you know if something isn't working as expected beforehand. Any issues that come up prior to changes being made can then be addressed accordingly. The second benefit to doing a pre-move test is that you know exactly what issues can be attributed to the changes during the conversion. If there is anything that comes up after performing the move they can be fixed before the NetScaler begins servicing connections again. I have a real life example of this situation below in the 'Spot Check Your Work' section. The bottom line is that by following this methodology you can build a solid foundation while providing continuity of service without interruption. Work with the customer to come up with a documented test plan and have them designate testers for both before and after the conversion. Remember, better safe than sorry!
Sharing is Caring: VPX Resource Allocation
Remember that you're no longer providing these NetScaler services on a dedicated platform. CPU, memory, SSL Chips, and network throughput are now shared amongst virtual NetScaler’s on a hypervisor. You should first review the existing resource allocation and utilization on the MPX appliance to make sure you have a good handle on what’s being used. At this particular customer they had MPX 9500’s. As part of this process I looked at their use case and was able to determine that I needed to trim down some of the resources while also dedicating CPU cores and throughput on the new VPX. It’s also best to run network links to the SDX with the same port configuration as were run to the MPX appliances to provide similar network throughput and VLAN configuration. This will make it much easier to provide as similar a configuration as possible to what the MPX had. One last item to note is the VPX running on SDX may display network links differently than what the MPX had. For example, let’s say we have ports 1/1 and 1/4 active on the SDX. If we allocate both to our new VPX, they will show up in the VPX configuration as 1/1 and 1/2. Be wary, this may affect your new configuration!
Know your Custom Files
This is one of the most important element of the conversion process since custom files are not brought over with just the ns.conf file on the NetScaler. These files need to be backed up and then copied to the VPX after it’s provisioned to keep the NetScaler Gateway consistent along with any lines of the configuration referencing these files. These are some of the files and directories you want to watch out for:
- Copy the whole /var/nsconfig directory which may include:
- conf
- netscaler
- conf
- SSL Certificates
- Universal Access Gateway (UAG) Licenses
- Copy any GeoIP database files in /var/GeoIP
- If Web Interface on the NetScaler is being used, make sure you:
- Copy the JDK and Web Interface files to /var/
- Backup any custom default.ica or webinterface.conf files from /var/wi/tomcat/webapps/Citrix/<Site Name>/WEB-INF/.
- Please note this path may differ depending on what NetScaler firmware version you’re running.
The Bread and Butter: Conversion Process
Now that we have everything prepared and have done our initial testing, it’s time for the fun part! Make sure to review your configuration and remove any unnecessary lines like the ones added by default, network interface lines (since these are changing) and HA configuration. This will allow us to run a batch configuration smoothly to get everything configured as it was on the VPX.
- Shut down your existing MPX. Before you provision your new VPX appliances through SDX management we want to make sure our MPX is shut down so we don’t cause any IP conflicts. If you’re running an HA pair, make sure that both of them are shut down before running the batch config since both of them will hold the VIP’s and SNIP’s.
- Copy custom files to the new NetScaler. Once they are provisioned you’ll want to copy any custom files over to the new NetScaler. Also, if applicable, I like to re-create the HA pair before importing the configuration. Some lines of the configuration may reference some of these files like your SSL certificates, Web Interface files and GeoIP database files to name a few.
- Run the configuration. Now that we have all of our custom files copied over we can run our batch configuration within an SSH client like Putty from the lines that were pulled off of the MPX. I prefer to do these in sections in order to review any errors that may occur when re-importing the configuration. If you do encounter errors during the import be sure to remediate them as needed.
- Perform final tweaks. Finally, there are a few things that you’ll need to configure that aren’t part of the ns.conf or we removed beforehand. These would normally include the NTP Configuration within the code and any settings specific to the Network Interfaces like HA monitoring.
Spot Check Your Work
Once you’re completed with the configuration you always want to spot check the configuration in the GUI. This means checking things like services, vServers, AppExpert policies, etc. As I mentioned previously I found an issue when pulling some rewrite rules over in which the expression contained a ‘?’. When I ran the new rewrite rules the question mark character simply didn’t make it into the rules causing some issues with ICA connections on mobile devices. After going through the rules and comparing them to the previous configuration I was able to diagnose the issue and remedy it. Also, make sure you perform your test plan to verify all functionality is as it was on the MPX appliances. I also like to keep the appliances racked and shut down for a week or so in case anything comes up down the road.
I hope this lesson from the field was helpful and worthwhile. May the NetScaler force be with you!
.png)
