Hello NBU world!
I've just completed two master server migrations using the NbServerMigrator tool (HP-UX > RHEL), and I was curious to see if anyone else had experience with this tool? Veritas has a pretty comprehensive document to using it, but I still encountered issues that were not documented. Aside from this guide, there is a lack of documentation related to its usage.
As NBU 8.1.1 nears its EOL, I think there will be an influx of administrators using this tool to migrate off of HP-UX and AIX servers. I've documented the issues I experienced and how they were resolved, but I wanted to receive input from any other admins who have used this tool before compiling a TechNote or forum post. I'll be posting either a TechNote or forum post with more detailed info, but I've pasted a general overview of the issues I encountered below.
Issues I encountered:
1. In both migrations, the pre-check did not flag the root/sys user/group combo being required. Once we began the migration, the transfer failed and told us to fix that.
2. The data transfer takes a LONG time. There is some area for improvement here for how I performed the migration (used default compression and other settings, which could have minimized the transfer time if tuned better). One domain had a catalog ~250GB in size, and the other was ~1 TB in size.
3. The documentation says that the -clean_up switch removes ALL temporary data, including the image data that had already been transferred. I had to perform this twice due to interrupts in the transfer, and neither time caused the tempdb directory (which contains the image information) to be removed.
4. Both migrations required quite a bit of manual intervention to get the certificates straightened out on the target servers. Once you perform the final -overwrite step, the source sends its certificates to the new master, which already has certificates configured as part of the initial NBU install. This part (after a 12+ hour migration), is quite painful, as it is one of the last steps before the migration concludes.
5. During the second migration, the terminal session between the target and source was terminated due to an ISP outage by the person helping me with the migration (we were sharing screens on his computer). This caused quite a lot of trouble with the migration (I'll detail it in my in-depth write up).
There are a few more things I observed during the process, but I was curious if anyone else had observations or experience with this tool.
I haven't had ocassion to use the tool yet but I do have a question for you on it. Specifically, what made you use this tool vs. just doing a catalog restore to the new box ? Since they were both UNIX boxes I wouldn't think there'd be any issues with it - binaries don't get restored so there shouldn't be architecture issues between the OSes, just the image files and importing the EMM exports into the new EMM database.
I've successfully used a DR catalog image before to migrate between Solaris and RHEL so I'm curious about whether HP-UX to RHEL would work as well. Yes it requires that you build yourself a new NBU Master install first to land the recovery on but it sounds like it might've been worth the hassle (and the initial build can usually happen ahead of the recovery change window).
Any info would be appreciated on why you selected the tool. Thanks !
There were a few factors behind the decision to use the tool. Initially I planned on doing a catalog restore, but the documentation recommends using the tool for larger environments. I also figured that the tool was specifically designed to address this issue, so I wanted to see how it worked. Lastly, the pandemic meant that it would be nearly impossible to have someone go on-site to handle the tapes or storage needed to send the data to the target master (an RHEL VM).
The two biggest benefits were the automation and the ability to easily roll-back. The tool can transfer the image data and most configuration files while the source master server is still active. One of the biggest issues we ran into was when the SSL connection between the two servers got disconnected. Along with corrupting a touch file, this caused the tar ball that had been transferred before the disconnect to not untar. Took quite a while to figure out what happened with those two issues.
Being able to easily roll back the migration made it an easier choice as well. There's two phases: the -data_transfer and the -overwrite. The first phase takes the longest, and essentially just sends the images to the target master. The -overwrite phase shuts down the source master, and begins building the catalog DBs on the target. We were able to take the master down for an extended period of time, so keeping it up while the migration was going wasn't a huge concern, but it was an aspect that made the tool more appealing.