25. 03. 2024
APM, NetEye, Visual Synthetic Monitoring
Introduction
Every few years (3-5) once your Hardware Guaranty expires, it’s time again to migrate your productive NetEye Server from the old Hardware to the new. This is a procedure that has to be done regularly, but unfortunately no “How To” documentation can be found for it. So today I’ll try to explain in a short blog post how I normally do this, and maybe this will help other people who have to do the same thing.
To-Do List
- Install the right NetEye Server version (ISO ONLY no) on the new hardware (Version >= Productive NetEye)
- If necessary, update/upgrade the productive NetEye Server to the one installed on the new hardware
- Add/update volume groups on the new hardware if more than one disk present
- Create any needed “local” filesystems (not DRBD), mount them, and fix all of the LV/Filesystem sizes
- Follow the NetEye Product Installation instructions until you’re able to download/update RPMS over DNF on the NEW Hardware
- Fix Unix users and groups (different depending whether the hardware is for a cluster or a single instance)
- Compare and adjust the installed RPM’s of the OLD and NEW Hardware
- Run a first synchronization of all “local” data from OLD to NEW
- Stop all services on the OLD NetEye Server and swap the NetEye Server IP from OLD to NEW and vice-versa
- Run a final synchronization of all changed “local” data from OLD to NEW
- On a cluster, create/sync the DRBD filesystem
- On a cluster, start the cluster software
- Start NetEye Services, or on a cluster, test them
Install the Right NetEye Server Version (ISO ONLY no) on the New Hardware (Version >= Productive NetEye)
First of all you have to decide which version of NetEye you want to migrate from the OLD to the NEW hardware. It might be that the customer has a very old version of NetEye, or they’re at the other end of the scale and they’re really up-to-date. As an example, let me tell you about my decision the last time I had to migrate hardware.
My customer’s productive NetEye Server was at version 4.26, but the last installable supported version was 4.39, while the latest available version was 4.46. So I decided to install 4.39 on the new hardware, since any earlier version was no longer officially supported for new installations.
I also wanted to do some upgrades on the OLD server, and after that some upgrades on the NEW server so that I could also be certain that any updates/upgrades would continue to work on the new server, and I wouldn’t forget to migrate some files which would then give me errors on future upgrades/updates.
Update/Upgrade the Productive NetEye Server to the One Installed on the New Hardware if Necessary
As you saw in the previous step, one doesn’t always have the same version on OLD and NEW Hardware, but on the NEW Hardware there could be the same or a newer version than on the productive system.
If the version is the same as on the OLD Server, you’ll have to update the NetEye Version so that all security and/or bug-fix versions of the RPM’s are installed for that version. If the version is lower, then you’ll have to update that version first and then upgrade the productive server until it’s the same version as the one you decided to install on the new hardware.
This is important since if the product data is synchronized, then that data will be correct for the version installed, and should there be any different versions installed, the program data might be incompatible, for example in databases with a changed layout.
Add/Update VG of New Hardware if More than One Disk Present
It might be the case that the new hardware has more disks than the old server does. For example, hardware is delivered with a system disk and data disks. A system disk is typically RAID1 and data disks might be RAID5. Since the installation in the previous step is done on the system disk, you’ll now have to decide what to do with the data disk. I’ll just give you some examples, but in the end you’ll have to decide what’s best for you.
- The data disk has same hardware and RAID-Level as the system disk: In this case I would prefer to just add the data disk to the already-present vg00 Volume Group
- The data disk has a different RAID level than the system disk: In this case I would create a second Volume Group, call it vg01 or vgdata, with that disk so I would know exactly how the Volume Group then behaves
Create Any Needed “Local” Filesystems (not DRBD), Mount Them, and Fix All of the LV/Filesystem Sizes
Now’s the time to create all missing “local” filesystems you need for the migration, for instance /neteye/local/mariadb or /neteye/local/elasticsearch. Also, you will most probably have to resize the already existing filesystems because they’re too small after a standard installation.
If you have only one volume group then it’s easy: you just increase the existing filesystems (look at the LV sizes on the OLD server) by using lvresise -L<new-greater-size> /dev/vg00/lv<whatever> -r, which will resize the Logical Volume and Filesystem (-r), and then create the new Logical Volumes with lvcreate and mkfs.xfs on the only vg00 volume.
If in the previous step you decided on 2 Volume Groups, then make the new “Product” Logical Volumes on the newly added Volume Group (vg01 or vgdata).
Follow the NetEye Product Installation Instructions Until You’re Able to Download/Update RPMS over DNF on NEW Hardware and Add Repos
You have to follow the NetEye Installation Guide after the RAW ISO Installation until the point where you can launch neteye node register. If that went well, then try dnf update to see if you can access all NetEye and/or RedHat repositories.
After that you can download/access the RedHat and NetEye repositories. You need to take a look at what repositories are configured on the OLD Server, and install/configure them on the new one. First of all, launch the command dnf --enablerepo=neteye* repolist on the old server. Then do the same on the new server using the command subscription-manager repos --enable <repository-name-from-list> and add all missing RedHat repositories on the New Server.
Also add repositories from the OLD Server as EPEL and/or Hardware Repositories (e.g., DELL) that you added there manually. You’ll also probably need to add some RPM’s from these additional repositories later on when synchronizing RPM’s.
On new NetEye versions you’ll also have to pay attention to the RedHad Stream you are subscribed to, for example in newer versions they use 10.11 for MariaDB and 6 for Redis, and in addition some special ones for NGinx. You can check these by using the command dnf module list and comparing the versions which are on the OLD and the NEW servers.
End of Part 1
See you next time to finish of our to-do list from above.
These Solutions are Engineered by Humans
Did you find this article interesting? Does it match your skill set? Our customers often present us with problems that need customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth IT Italy.
Juergen Vigna
NetEye Solution Architect at Würth IT Italy
I have over 20 years of experience in the IT branch. After first experiences in the field of software development for public transport companies, I finally decided to join the young and growing team of Würth Phoenix (now Würth IT Italy). Initially, I was responsible for the internal Linux/Unix infrastructure and the management of CVS software. Afterwards, my main challenge was to establish the meanwhile well-known IT System Management Solution WÜRTHPHOENIX NetEye. As a Product Manager I started building NetEye from scratch, analyzing existing open source models, extending and finally joining them into one single powerful solution. After that, my job turned into a passion: Constant developments, customer installations and support became a matter of personal. Today I use my knowledge as a NetEye Senior Consultant as well as NetEye Solution Architect at Würth Phoenix.
Author
Latest posts by Juergen Vigna
22. 05. 2025
NetEye, Unified Monitoring
Automatic Integration of NagVis Map into Icinga Web 2/NetEye Monitoring