Using pool move to relocate a pool from one piece of storage to an alternative storage location on the same server. In a cluster it take the concept to a whole new level – really it makes SAN changes a doddle!
The next stop is to be able to move a pool from Server 1 to Server2 and make all of the changes to the eDir rights etc Not login scripts but the ability to bring up a new server and then just move the data from old host to new would resolve so many upgrade issues.
OES2015 – 2018 without the OS hassle?
As a first phase I wonder if this could be incorporated as part of the Miggui tool set?
by: Tim H. | over a year ago | NSS
Comments
very useful
Yes Very usfull and helpful for Server hardware updates
also very nice would be nss32 to nss64 pool migration.
"Pool move", "miggui", "nssmu", "NLVM", and "iManager" are tools that currently provide most of this functionality. In a virtual environment, additional tools are available to duplicate a virtual disk and/or attach it to a new server. I would leave it to the developers to decide whether the better approach is to enhance these existing tools or implement these enhancements in a different way.
The need to migrate data between servers is not an issue when upgrading an existing server however this is not always possible in a virtual environment. For example, VMware does not support upgrading a virtual machine from one major release to another as described in "VMware support for guest operating system upgrade (2018695)". This requirement alone ensures frequent data migrations between servers.
While "pool move" describes a process, it does not adequately describe what needs to be accomplished and while we can accomplish what we need with the available tools it can be a lengthy and possible error prone process which needs to be simplified.
In addition to the capabilities provided by existing tools, we need to be able to:
1. Seamlessly migrate NSS pools between servers in the same tree with options to increase the pool size and specify the devices to be used as can currently be done with a "pool move" at the same time providing the ability to fall back to the existing server should the migration be unsuccessful.
2. In addition to #1, when migrating data between servers in different trees, we need a way to automate the creation of eDirectory users based on NSS trustee data.
Generic solutions, like muggui, can be used in a wide variety of situations but "across the wire" solutions can be very slow. With the ability to attach an existing virtual disk to a new server, migrations can be accomplished for the most part on a single server reducing the migration time significantly.