TODO
- same ip / different ip
- data disk size is different
- data disk
- check different number of agents / nodes
- rollback
- verify system working
This procedure is intended for users wants to migrate from one DPOD installation to another for the following scenarios :
- Migration from DPOD Appliance mode installation version v1.0.0 with CentOS 6.7 to CentOS 7.2 introduced at version v1.0.2+.
- Migration from DPOD on a virtual server to physical server (for example : when load increased and requires a physical server based installation).
- Migration from DPOD Appliance to Non-Appliance mode (RHEL) to better comply with their organization technical / security requirements and standards.
New procedure and tools were introduced to support customers with migration of an existing DPOD Store data to a new DPOD installation in each of the scenarios above.
Pre Requisites
- Both systems (current and new) must be with the same DPOD version, 1.0.6.0 and above.
- Only the Appliances installation (provided as ISO file) is supported for this migration procedure. SHACHAR
Collect Needed Artifacts from Source System
Application Files and Internal DB
Invoke the backup command
app_backup.sh INFO : backup finished successfully. for more information see log file /installs/system-backup/full-backup-2017-09-11_17-17-59/full-backup-2017-09-11_17-17-59.log
The output backup directory will be the location of the backup log as printed in the backup status message (in the current example /installs/system-backup/full-backup-2017-09-11_17-17-59 ).
Copy the backup directory to a temporary location outside the current DPOD system.
Services Files
DPOD's services files are located in directory /etc/init.d
The services files will not be migrated to the new system because they are not compatible with the new OS version.
If the user altered manually one of the services files it is the user responsibility to migrate these changes to the new services files.
User Custom Artifacts
example for custom artifacts can be custom key stores used for DPOD SSL client authentication.
Creating New System
Install new System
Install new DPOD installation using version 1.0.2.0 ISO file and apply needed updates (fix) in order for the the current system and the new system to have the same DPOD version.
Disable Log Targets
Since DPOD will not be available during the migration process we recommend to disable the monitored device's log targets as describe in "Disable / Enable DPOD's Log Targets".
Move The Data Disk - Optional
The current transactions data is store in the BigData store located on the OS mount point /data (the configuration data is kept in the internal DB which was recovered in previous steps).
It is not mandatory to migrate the current transaction data to the new system.
Not migrating the transaction data means loosing current transaction data !
For migrating the current transactions data to the new system please follow the procedure
Exporting The Data LVM Configuration (Volume Group)
The /data mount point is mapped to the LVM volume group vg_data .
- Stop the application services using the Main Admin Menu CLI (option 2 → "stop all" )
un-mount the /data mount point
umount /data
Mark the volume group as non active
vgchange -an vg_data output : 0 logical volume(s) in volume group "vg_data" now active
Export the volume group
vgexport vg_data output : Volume group "vg_data" successfully exported
Comment /data mount point in OS FS table
Comment the following line in /etc/fstab#/dev/mapper/vg_data-lv_data /data ext4 defaults 1 2
- TODO - not needed if reinstalling the same server
Disconnect the Data Disk and Connect to New System
Stop The System
shutdown the server (virtual / physical ) using the command
shutdown -h 0
Virtual Environment
Copy the Virtual Data Disk From Current VM
- Edit the current virtual machine settings
- Locate the data disk (hard drive number 3 )
- It is recommended to copy the data disk vmdk file the new system directory (we recommend NOT to move the vmdk file but copy it, in order to keep fallback option if an issue will be raised during migration).
Edit the New System OS FS table
Change the /data mount point in OS FS table
From : /dev/mapper/vg_data-lv_data /data xfs defaults 0 0 To : /dev/mapper/vg_data_old-lv_data /data xfs defaults 0 0
Rename /data LVM volume Group
Rename the data volume group vg_data in the new system to avoid volume group collision when connecting the data disk from the old system
vgrename vg_data vg_data_old output : Volume group "vg_data" successfully renamed to "vg_data_old"
Connect the Virtual Disk to New VM
- Shut down the new system
shutdown -h 0
- Configure the virtual disk to the new system by adding new hard drive and choosing existing
- Start the new VM
Configure New Disk
- Make sure the new exported volume group (LVM vg) and physical volume (LVM pv) are recognized by the OS
pvscan output : PV /dev/sdb3 VG vg_app lvm2 [7.08 GiB / 80.00 MiB free] PV /dev/sdb1 VG vg_logs lvm2 [11.08 GiB / 84.00 MiB free] PV /dev/sdb5 VG vg_apptmp lvm2 [4.10 GiB / 100.00 MiB free] PV /dev/sdb6 VG vg_shared lvm2 [596.00 MiB / 84.00 MiB free] PV /dev/sdd1 is in exported VG vg_data [101.97 GiB / 0 free] PV /dev/sda2 VG vg_root lvm2 [10.19 GiB / 196.00 MiB free] PV /dev/sdb2 VG vg_inst lvm2 [7.08 GiB / 80.00 MiB free] PV /dev/sdc1 VG vg_data_old lvm2 [100.00 GiB / 20.00 MiB free] Total: 8 [242.07 GiB] / in use: 8 [242.07 GiB] / in no VG: 0 [0 ]
vgscan output : Reading all physical volumes. This may take a while... Found volume group "vg_data_old" using metadata type lvm2 Found volume group "vg_inst" using metadata type lvm2 Found volume group "vg_root" using metadata type lvm2 Found exported volume group "vg_data" using metadata type lvm2 Found volume group "vg_shared" using metadata type lvm2 Found volume group "vg_apptmp" using metadata type lvm2 Found volume group "vg_logs" using metadata type lvm2 Found volume group "vg_app" using metadata type lvm2
Import the data volume group from the new disk added to VM
vgimport vg_data output : Volume group "vg_data" successfully imported
- Activate the imported data volume group
vgimport vg_data output : 1 logical volume(s) in volume group "vg_data" now active
Verify the data volume group status
vgdisplay vg_data output : --- Volume group --- VG Name vg_data System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 1 Open LV 0 Max PV 0 Cur PV 1 Act PV 1 VG Size 101.97 GiB PE Size 32.00 MiB Total PE 3263 Alloc PE / Size 3263 / 101.97 GiB Free PE / Size 0 / 0 VG UUID 4vIe7h-qqLR-6qEa-aRID-dU8w-U5E2-gV7FoJ
Add the new mount point to OS FS table
- Configure the /data mount point to OS FS table by adding the following line
/dev/mapper/vg_data-lv_data /data ext4 defaults 1 2
Comment the following line
#/dev/mapper/vg_data_old-lv_data /data xfs defaults 0 0
Restart the system
reboot
Make sure the /data mount point is mounted using vg_data volume group
df -h output : Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_root-lv_root 4.0G 1.6G 2.5G 39% / devtmpfs 7.9G 0 7.9G 0% /dev tmpfs 7.9G 56K 7.9G 1% /dev/shm tmpfs 7.9G 9.1M 7.9G 1% /run tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup /dev/sda1 2.0G 101M 1.8G 6% /boot /dev/mapper/vg_data-lv_data 101G 81M 96G 1% /data /dev/mapper/vg_root-lv_var 4.0G 109M 3.9G 3% /var /dev/mapper/vg_logs-lv_logs 11G 44M 11G 1% /logs /dev/mapper/vg_shared-lv_shared 509M 26M 483M 6% /shared /dev/mapper/vg_root-lv_tmp 2.0G 726M 1.3G 36% /tmp /dev/mapper/vg_inst-lv_inst 7.0G 2.8G 4.3G 40% /installs /dev/mapper/vg_app-lv_app 7.0G 1.4G 5.7G 20% /app /dev/mapper/vg_apptmp-lv_apptmp 4.0G 33M 4.0G 1% /app/tmp tmpfs 1.6G 0 1.6G 0% /run/user/0
- Start the application services using the Main Admin Menu CLI (option 1 → "start all" )
Verify The Application Is Working Properly
TODO
Remove the Old data volume group
Mark the volume group as non active
vgchange -an vg_data_old output : 0 logical volume(s) in volume group "vg_data_old" now active
Export the volume group
vgexport vg_data_old output : Volume group "vg_data_old" successfully exported
- Shut down the new system
shutdown -h 0
- Remove the unused virtual disk from VM (should be the 3rd virtual hard drive )
- Start the VM
Verify The Application Is Working Properly
TODO
Create Staging Directory
Create staging directory on the new system
mkdir -p /installs/system-backup/system-migration
Restore Internal DB
Copy the backup directory from the source system to the staging directory.
Invoke the restore command for the internal DB, where :
-t : the restore type (db)
-d : the restore source backup directory. in the example /installs/system-backup/system-migration/full-backup-2017-09-13_22-38-56
-f : the source backup file in the backup directory. in the example full-backup-2017-09-13_22-38-56.tar.gz
app_restore.sh -t db -d /installs/system-backup/system-migration/full-backup-2017-09-13_22-38-56 -f full-backup-2017-09-13_22-38-56.tar.gz stopping application ... application stopped successfully. starting restore process ... restoring internal DB ..... system restore was successful for more information see log file /installs/system-backup/db-restore-2017-09-17_15-04-19.log
Restore Application Files
Copy the backup directory from the source system to the staging directory (not needed if copied during internal DB restore)
Invoke the restore command for the application, where :
-t : the restore type (app)
-d : the restore source backup directory. in the example /installs/system-backup/system-migration/full-backup-2017-09-13_22-38-56
-f : the source backup file in the backup directory. in the example full-backup-2017-09-13_22-38-56.tar.gz
app_restore.sh -t app -d /installs/system-backup/system-migration/full-backup-2017-09-13_22-38-56 -f full-backup-2017-09-13_22-38-56.tar.gz stopping application ... application stopped successfully. starting restore process ... restoring system files ... making sure files to restore exist in backup file files to restore exist in backup file system restore was successful for more information see log file /installs/system-backup/app-restore-2017-09-17_15-04-19.log
Change Agent's IP Address
If the new DPOD system has different IP address the current one user must change the "Agent IP" in the nodes management screen :
- Startthe application services using the Main Admin Menu CLI (option 1 → "start all" )
- In the web console navigate to system → nodes and edit the IP address of the agents in your data node raw.
- Re-configure syslog for the default domain on each monitored device (the Setup Syslog for device on the Device Management section)
- Restart the keepalive service using the Main Admin Menu CLI
TODO - recalculate retention conf
TOTO - external poratl changed hosts montier-es
Verify The Application Is Working Properly
TODO
TODO - Shachar Greenberg please write here the procedure