Method for realizing migration and high-reliability guarantee of LVM storage data of virtual machine
A method using DRBD, NFS, and Keepalived creates a high-availability storage cluster to address single-point failure issues in LVM-based virtual machine storage, ensuring data redundancy and continuous operations.
Patent Information
- Application Number
- CN202510105567.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-01-23
- Publication Date
- 2025-05-23
AI Technical Summary
Current LVM-based virtual machine storage solutions lack robustness, leading to potential data loss and business disruption due to single-point failures, even with data synchronization across physical servers.
Implement a method involving DRBD, NFS, and Keepalived to create a high-availability storage cluster by distributing virtual machine data across multiple backup nodes, ensuring data redundancy and automatic failover, using DRBD for real-time synchronization and Keepalived for seamless access via VIP addresses.
Ensures data reliability and continuous business operations by maintaining data consistency and availability across nodes, reducing downtime and enhancing system resilience against hardware or software failures.
Smart Images

Figure CN120029718A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of data migration, in particular to a method for realizing virtual machine LVM storage data migration and high reliability guarantee. Background Art
[0002] LVM is the abbreviation of Logical Volume Manager, which is generally translated into Chinese as "Logical Volume Management". It is a mechanism for managing disk partitions under Linux. LVM is a logical layer built between disk partitions and file systems. System administrators can use LVM to dynamically adjust the size of partitions without repartitioning the disks. If a new hard disk is added to the system, the new hard disk space can be directly expanded to the original disk partition through LVM.
[0003] Installing a file system through LVM does not ensure that the file system will not have problems. Once a problem occurs, it may be impossible to recover. Although the snapshot function provided by LVM provides some possible help, it cannot completely avoid problems in some cases (for example, systems involving large amounts of data may have to store thousands of records since the last snapshot).
[0004] One solution to this problem is to use LVM mirroring, which is a complete copy of a logical volume that is updated in real time. When a mirrored logical volume is created, LVM will synchronize the original logical volume to the mirrored copy. Once the synchronization is complete, LVM will perform two writes for each file system (once to the primary logical volume and once to the mirrored logical volume), which reduces write performance but improves system reliability.
[0005] Currently, desktop cloud vendors often use LVM block devices natively supported by the Linux operating system as virtual machine disks, but the data is only stored on a single physical server. If the physical server is shut down or a single point failure occurs, the desktop virtual machine will become unusable due to disk damage, resulting in business interruption or even data loss.
[0006] The usual solution is to add an additional disk on the same physical server, and synchronize the data disk to another lvm disk volume group on the server using lvm volume group synchronization. This achieves real-time synchronization and backup of data, and meets high availability in the event of disk failure. However, if the physical server fails, the data is still unavailable, and the single point of failure is not eliminated. Summary of the invention
[0007] In view of the needs and deficiencies of current technology development, the present invention provides a method for implementing virtual machine LVM storage data migration and high reliability guarantee.
[0008] The present invention provides a method for implementing virtual machine LVM storage data migration and high reliability guarantee, and the technical solution adopted to solve the above technical problems is as follows:
[0009] A method for implementing virtual machine LVM storage data migration and high reliability guarantee includes the following steps:
[0010] S1. In the physical server cluster where the virtual machine is located, select the backup node according to the storage capacity and hardware model, and divide the servers in the physical server cluster into multiple active and standby server groups to ensure that the total disk capacity of the backup server is greater than the actual data usage of the currently used virtual machine;
[0011] S2. Perform logical processing on the backup hard disk of the backup node, install and configure the drbd9 software on all nodes in the cluster, initialize the backup hard disk of the backup node and mount it to the specified directory;
[0012] S3. Install nfsserver and keepalived services on the primary node and backup node in the primary and backup server groups, configure them accordingly, and set the VIP address for NFS data directory and virtual machine disk access;
[0013] S4. Promote the drbd0 device (distributed replication block device) of the backup node to the primary node to migrate the virtual machine data, then clean up the primary node disk and perform reverse data synchronization;
[0014] S5. Repeat steps S1-S4 in multiple active and standby server groups to migrate all virtual machine data and ensure high data reliability through DRBD and keepalived.
[0015] Optionally, the step S1 specifically includes the following operations:
[0016] S1.1. Traverse each node in the physical server cluster where the virtual machine is located, check the storage capacity information of each node, select the node with half of the storage capacity in idle state, and use it as the backup node;
[0017] S1.2. After completing the backup node selection, classify all servers in the physical server cluster according to the hardware model, and classify servers with the same or similar hardware models into one category;
[0018] S1.3. In each type of server, further screening is performed based on the total disk storage capacity, and two servers with similar total disk storage capacity and similar configuration are selected to form a primary and secondary server group;
[0019] S1.4. Repeat the above operations until the servers in the physical server cluster are divided into multiple active and standby server groups.
[0020] Further optionally, the step S2 specifically includes the following operations:
[0021] S2.1. Collect the backup hard disks of the selected backup nodes, and form the backup hard disks into Linux cache disks or divide them into logical volume devices using LVM volume groups;
[0022] S2.2. Install the drbd9 software on all nodes in the cluster. The software is used to achieve real-time data synchronization and high availability. After the installation is complete, manage the bare device in the system as / dev / drbd0.
[0023] S2.3. Perform drbd metadata initialization on the backup disk of the backup node and clear the original data on the backup disk. After the initialization is completed, mount the backup disk to the / var / lib / nfs directory of the backup node so that the disk can be correctly identified and accessed by the system, providing data storage support for subsequent NFS services.
[0024] Further optionally, the step S3 specifically includes the following operations:
[0025] S3.1. Install the nfsserver service on the primary node and backup node in the primary and backup server groups. After the installation is complete, configure / var / lib / nfs as the nfs data directory.
[0026] S3.2. Install the keepalived service on the primary node and backup node in the primary and backup server groups respectively. After the installation is complete, configure a new VIP as the subsequent virtual machine disk access address.
[0027] Optionally, step S3.1 is performed by executing the command echo' / var / lib / nfs
[0028] *(rw,async,no_root_squash,no_all_squash)'>> / etc / exports to configure
[0029] / var / lib / nfs is the nfs data directory. This command sets the sharing permissions for the / var / lib / nfs directory, allowing all nodes to access the directory in read, write, and asynchronous modes. It does not restrict the permissions of the root user and all users, ensuring the flexibility and convenience of data sharing.
[0030] Further optionally, the step S4 specifically includes the following operations:
[0031] S4.1. First, upgrade the role of the backup node's drbd0 device to the primary, so that it has the ability to accept data reading and writing, and then start the virtual machine data migration operation;
[0032] S4.2, after all virtual machine data on the master node has been successfully migrated to the backup nfs disk, clean up the master node disk;
[0033] Further optionally, step S4.1 is executed to perform the virtual machine data migration operation using any of the following methods:
[0034] a) Replace the lvm backend of the virtual disk of the openstack virtual machine with the new nfs backend, and switch the storage location of the virtual machine disk by modifying the relevant configuration files and parameters, so as to migrate the data of the virtual machine disk from the primary node to the nfs disk of the backup node;
[0035] b) Use the libvirt tool to manually execute the virshblockjob command to migrate the virtual machine disk data from the primary node to the NFS disk of the backup node;
[0036] During the entire migration process, the operating status of the virtual machine is monitored in real time to ensure normal use of the virtual machine.
[0037] Optionally, step S4.2 is performed to clean up the primary node disk. The specific operations are as follows:
[0038] Clear and format the disk storing virtual machine data on the master node, delete the lvm logical volumes and volume groups related to the virtual machines on the master node, and free up disk space;
[0039] Reconfigure DRBD on the disk storing virtual machine data of the primary node so that it can synchronize data with the backup node; after the configuration is completed, start the DRBD data synchronization function to synchronize the data stored on the NFS disk back to the disk storing virtual machine data of the primary node, so that the data of the primary and backup nodes are consistent again, preparing for possible subsequent primary-backup switching.
[0040] Further optionally, step S5 is performed, after all active and standby server groups complete data migration, nfs uses the vip address configured by keepalived to access, and the data is synchronized in real time through drbd in the active and standby server groups;
[0041] When the primary node fails, the keepalived VIP of the backup node automatically takes effect and continues to provide data access services for the virtual machine, ensuring high data reliability and business continuity.
[0042] Compared with the prior art, the method of the present invention for realizing virtual machine LVM storage data migration and high reliability guarantee has the following beneficial effects:
[0043] 1. The steps of the present invention are clear. From environment preparation, disk and software configuration, service installation and configuration, to data migration and multi-group promotion, each step has a clear operation process. This structured design makes the system easy to understand and maintain. When a problem occurs, the operation and maintenance personnel can quickly locate the fault point and repair it according to the specific steps. In the configuration process, such as the creation of configuration files in the field of data migration technology, DRBD in the field of data migration technology, the permission configuration of NFS services in the field of data migration technology, and the parameter configuration of keepalived in the field of data migration technology, there are clear standards and examples, which makes it more convenient to perform repeated configurations on multiple active and standby server groups, and also facilitates unified management and maintenance of system configuration parameters, reducing problems caused by inconsistent configurations.
[0044] 2. The present invention utilizes DRBD master-slave cluster technology to transform LVM block device data into a highly available NFS cluster, thus realizing a cross-node storage cluster without significantly increasing hardware costs;
[0045] 3. The present invention realizes data backup storage by selecting a backup node and ensuring that its disk capacity can accommodate the amount of data actually used by the virtual machine; in the data migration process, the virtual machine data is migrated from the primary node to the NFS disk of the backup node, and at the same time, the primary and backup nodes synchronize data in real time through DRBD in the field of data migration technology. In this way, even if the primary node fails (such as hardware damage, software crash, etc.), the data of the backup node is still available, effectively avoiding the risk of data loss; the data consistency between the primary and backup nodes is ensured by DRBD software in the field of data migration technology. During normal operation, the data update operation can be copied from the primary node to the backup node in real time. This synchronization mechanism ensures that the backup data is always up to date, further enhancing the security and integrity of the data;
[0046] 4. The present invention uses the keepalived service to configure a VIP (virtual IP) address for virtual machine disk access. When the primary node fails, the keepalived service of the backup node will automatically take effect, allowing the virtual machine to continue accessing data through the backup node. The entire process is almost seamless for users, greatly reducing the service interruption time caused by server failures and ensuring service continuity and high availability.
[0047] 5. The present invention divides the physical server cluster into multiple active and standby server groups. This distributed architecture increases the redundancy of the entire system. Even if a certain active and standby server group has a problem, other groups can still work normally, thereby improving the ability of the entire system to cope with failures and ensuring high availability of services;
[0048] 6. The present invention provides a variety of virtual machine data migration methods, such as replacing the virtual machine virtual disk backend in the OpenStack environment, or using the libvirt tool to manually execute the migration command. These methods can be flexibly selected according to the actual environment and needs to ensure that data can be smoothly migrated from LVM storage to NFS disk, and the virtual machine status can be monitored in real time during the migration process through monitoring tools to ensure the normal use of the virtual machine, effectively reducing the impact of data migration on the business;
[0049] 7. After the migration is completed, the present invention cleans and reconfigures the master node disk, freeing up the disk space originally used to store virtual machine data, while making full use of the storage resources of the backup node, so that the storage resources are more reasonably allocated and utilized, thereby improving the storage efficiency of the entire cluster. BRIEF DESCRIPTION OF THE DRAWINGS
[0050] Attached Figure 1 It is a flow chart of the method of embodiment 1 of the present invention. DETAILED DESCRIPTION
[0051] In order to make the technical solution, the technical problem solved and the technical effect of the present invention more clearly understood, the technical solution of the present invention is clearly and completely described below in conjunction with specific embodiments.
[0052] Embodiment 1:
[0053] Combined with Figure 1This embodiment proposes a method for implementing virtual machine LVM storage data migration and high reliability guarantee, which includes the following steps:
[0054] S1. In the physical server cluster where the virtual machine is located, select the backup node based on the storage capacity and hardware model, and divide the servers in the physical server cluster into multiple active and standby server groups to ensure that the total disk capacity of the backup server is greater than the actual data usage of the current virtual machine.
[0055] This step specifically includes the following operations:
[0056] S1.1. Traverse each node in the physical server cluster where the virtual machine is located, check the storage capacity information of each node, select the node with half of the storage capacity in idle state, and use it as the backup node;
[0057] S1.2. After completing the backup node selection, all servers in the physical server cluster are classified according to the hardware model, and servers with the same or similar hardware models are grouped together; similar hardware models here include similar CPU models, memory capacity and type, network interface bandwidth, etc.;
[0058] S1.3. In each type of server, further screening is performed based on the total disk storage capacity, and two servers with similar total disk storage capacity and similar configuration are selected to form a primary and secondary server group;
[0059] S1.4. Repeat the above operations until the servers in the physical server cluster are divided into multiple active and standby server groups.
[0060] S2. Perform logical processing on the backup hard disk of the backup node, install and configure the drbd9 software on all nodes of the cluster, initialize the backup hard disk of the backup node and mount it to the specified directory.
[0061] This step specifically includes the following operations:
[0062] S2.1. Collect the backup hard disks of the selected backup nodes, and form the backup hard disks into Linux cache disks or divide them into logical volume devices using LVM volume groups;
[0063] S2.2. Install drbd9 software on all nodes in the cluster. The software is used to achieve real-time data synchronization and high availability. After the installation is complete, manage the bare device in the system as / dev / drbd0. Create the drbd0.res file in the / etc / drbd.d / directory with reference to the sample configuration file (such as the configuration of k1676 as the primary node and k1677 as the backup node), and configure the drbd0 device of the primary and backup nodes in detail, including the device path (such as device / dev / drbd0), disk path (such as disk / dev / bcache0), metadata disk settings (meta-diskinternal), and communication addresses (such as address6.6.6.76:7789 and address6.6.6.77:7789) and other key parameters to ensure that data synchronization and communication can be carried out normally between the primary and backup nodes. The specific code is as follows:
[0064]
[0065] It should be added that: ① A bare device refers to a physical storage device or a logical storage device that is not formatted by a file system and is directly managed and used by an operating system. For example, a new hard disk is a bare device before it is partitioned, formatted, and mounted with a file system. In this embodiment, these bare devices are the basic physical resources for storing virtual machine data. ② It is an important configuration step to manage bare devices as / dev / drbd0; after installing the DRBD9 software, the bare devices in the system are incorporated into the management system of DRBD9 through the configuration and management functions of the software, and are abstracted as a device named / dev / drbd0. The / dev / drbd0 device plays a core role in the entire data synchronization and storage architecture. It corresponds to each other between the primary and backup nodes. The / dev / drbd0 device of the primary node and the / dev / drbd0 device of the backup node will communicate and synchronize data through the DRBD9 software. When data is written to the / dev / drbd0 device of the primary node, the DRBD9 software will copy the data to the / dev / drbd0 device of the backup node according to the configuration, thereby realizing data synchronization between the two nodes.
[0066] S2.3. Perform drbd metadata initialization on the backup disk of the backup node and clear the original data on the backup disk. After the initialization is completed, mount the backup disk to the / var / lib / nfs directory of the backup node so that the disk can be correctly identified and accessed by the system, providing data storage support for subsequent NFS services.
[0067] S3. Install nfsserver and keepalived services on the primary node and backup node in the primary and backup server groups respectively, configure them accordingly, and set the VIP address for NFS data directory and virtual machine disk access.
[0068] This step specifically includes the following operations:
[0069] S3.1. Install the nfsserver service on the master node and backup node in the master-slave server group. After the installation is complete, configure / var / lib / nfs as the nfs data directory. This step is specifically performed by executing the command echo' / var / lib / nfs*(rw,async,no_root_squash,no_all_squash)'>> / etc / exports to configure / var / lib / nfs as the nfs data directory. This command sets the sharing permissions of the / var / lib / nfs directory, allowing all nodes to access the directory in read-write and asynchronous mode, and does not limit the permissions of the root user and all users, to ensure the flexibility and convenience of data sharing;
[0070] S3.2. Install the keepalived service on the primary node and backup node in the primary and backup server groups respectively. After the installation is complete, configure a new VIP as the subsequent virtual machine disk access address. In this step, you need to set the relevant parameters of vrrp_instance in the keepalived.conf file, such as setting state to MASTER (master node) or BACKUP (backup node), specifying interface as bond_mgmt (network interface name, filled in according to the actual network configuration), virtual_router_id to 151 (virtual router identifier, customized and unique in the same network), priority to 150 (priority, the master node has a higher priority than the backup node), advert_int to 1 (advertisement interval, in seconds), authentication to set auth_type to PASS (password authentication type), auth_pass to atmeHez99bdjTi0 (authentication password, which needs to be kept properly), and configure the track_script part, adding monitoring scripts such as chk_eth, chk_split_brain, and chk_drbd to monitor the network and drbd status in real time to ensure the stability and high availability of the system.
[0071] Taking the master node k1676 and the backup node k1677 as an example, the specific code is as follows:
[0072]
[0073] S4. Promote the drbd0 device (distributed replication block device) of the backup node to the primary node to migrate the virtual machine data, then clean up the primary node disk and perform reverse data synchronization.
[0074] This step specifically includes the following operations:
[0075] S4.1. First, upgrade the role of the backup node's drbd0 device to the primary so that it has the ability to read and write data, and then start the virtual machine data migration operation. This step specifically uses any of the following methods to perform the virtual machine data migration operation: a) Replace the lvm backend of the openstack virtual machine's virtual disk with a new nfs backend, and switch the virtual machine disk storage location by modifying relevant configuration files and parameters, thereby migrating the virtual machine disk data from the primary node to the nfs disk of the backup node; b) Use the libvirt tool to manually execute the virshblockjob command to migrate the virtual machine disk data from the primary node to the nfs disk of the backup node; It should be added that: During the entire migration process, monitor the running status of the virtual machine in real time to ensure the normal use of the virtual machine;
[0076] S4.2. After waiting for all virtual machine data on the primary node to be successfully migrated to the backup nfs disk, clean up the primary node disk. The specific cleaning operations are as follows: empty and format the disk storing virtual machine data on the primary node, delete the lvm logical volumes and volume groups related to the virtual machines on the primary node, and free up disk space; reconfigure drbd on the disk storing virtual machine data on the primary node so that it can synchronize data with the backup node; after the configuration is completed, start the drbd data synchronization function to synchronize the data stored on the nfs disk back to the disk storing virtual machine data on the primary node, so that the data of the primary and backup nodes are consistent again, and prepare for possible subsequent primary and backup switching.
[0077] S5. Repeat steps S1-S4 in multiple active and standby server groups to migrate all virtual machine data and ensure high data reliability through DRBD and keepalived.
[0078] After all active and standby server groups complete data migration, nfs uses the vip address configured by keepalived to access, and data is synchronized in real time through drbd within the active and standby server groups. When the active node fails, the keepalived vip of the backup node automatically takes effect and continues to provide data access services for the virtual machine, ensuring high data reliability and business continuity.
[0079] It is necessary to add that: ① The server's operating system meets the installation and operation requirements of drbd9, nfsserver, keepalived and other software, such as a common Linux operating system (such as CentOS, Ubuntu, etc.) and a suitable version. ② The network environment must have a certain bandwidth (such as not less than 1000M network bandwidth) and stability to ensure efficient data transmission and synchronization. ③ The existing virtual machine environment must support related data migration operations, such as the openstack virtual machine must have the corresponding configuration modification permissions and interfaces, and the libvirt tool must be able to access and operate the virtual machine disk normally.
[0080] In summary, the method for implementing virtual machine LVM storage data migration and high reliability guarantee of the present invention can realize a cross-node storage cluster without significantly increasing the hardware cost;
[0081] The above specific examples are used to explain the principles and implementation methods of the present invention in detail. These examples are only used to help understand the core technical content of the present invention. Based on the above specific embodiments of the present invention, any improvements and modifications made to the present invention by technicians in this technical field without departing from the principles of the present invention should fall within the scope of patent protection of the present invention.
Claims
1. A method for implementing virtual machine LVM storage data migration and high reliability guarantee, characterized in that: It includes the following steps: S1. In the physical server cluster where the virtual machine is located, select the backup node according to the storage capacity and hardware model, and divide the servers in the physical server cluster into multiple active and standby server groups to ensure that the total disk capacity of the backup server is greater than the actual data usage of the currently used virtual machine; S2. Perform logical processing on the backup hard disk of the backup node, install and configure the drbd9 software on all nodes in the cluster, initialize the backup hard disk of the backup node and mount it to the specified directory; S3. Install nfsserver and keepalived services on the primary node and backup node in the primary and backup server groups, configure them accordingly, and set the VIP address for NFS data directory and virtual machine disk access; S4. Promote the drbd0 device of the backup node to the primary node to migrate the virtual machine data, then clean up the primary node disk and perform reverse data synchronization; S5. Repeat steps S1-S4 in multiple active and standby server groups to migrate all virtual machine data and ensure high data reliability through drbd and keepalived.
2. A method for implementing virtual machine LVM storage data migration and high reliability guarantee according to claim 1, characterized in that: The step S1 specifically includes the following operations: S1.
1. Traverse each node in the physical server cluster where the virtual machine is located, check the storage capacity information of each node, select the node with half of the storage capacity in idle state, and use it as the backup node; S1.
2. After completing the backup node selection, classify all servers in the physical server cluster according to the hardware model, and group servers with the same or similar hardware models into one category; S1.
3. In each type of server, further screening is performed based on the total disk storage capacity, and two servers with similar total disk storage capacity and similar configuration are selected to form a primary and secondary server group; S1.
4. Repeat the above operations until the servers in the physical server cluster are divided into multiple active and standby server groups.
3. A method for implementing virtual machine LVM storage data migration and high reliability guarantee according to claim 2, characterized in that: The step S2 specifically includes the following operations: S2.
1. Collect the backup hard disks of the selected backup nodes, and form the backup hard disks into Linux cache disks or divide them into logical volume devices using LVM volume groups; S2.
2. Install the drbd9 software on all nodes in the cluster. The software is used to achieve real-time data synchronization and high availability. After the installation is complete, manage the bare device in the system as / dev / drbd0. S2.
3. Perform drbd metadata initialization on the backup disk of the backup node and clear the original data on the backup disk; After initialization is complete, the backup disk is mounted to the / var / lib / nfs directory of the backup node so that the disk can be correctly identified and accessed by the system, providing data storage support for subsequent NFS services.
4. A method for implementing virtual machine LVM storage data migration and high reliability guarantee according to claim 3, characterized in that: The step S3 specifically includes the following operations: S3.
1. Install the nfsserver service on the primary node and backup node in the primary and backup server groups. After the installation is complete, configure / var / lib / nfs as the nfs data directory. S3.
2. Install the keepalived service on the primary node and backup node in the primary and backup server groups respectively. After the installation is complete, configure a new VIP as the subsequent virtual machine disk access address.
5. A method for implementing virtual machine LVM storage data migration and high reliability guarantee according to claim 4, characterized in that: Execute step S3.1 and configure / var / lib / nfs as the nfs data directory by executing the command echo' / var / lib / nfs*(rw,async,no_root_squash,no_all_squash)'>> / etc / exports. This command sets the sharing permissions of the / var / lib / nfs directory, allowing all nodes to access the directory in read-write and asynchronous modes, and does not restrict the permissions of the root user and all users to ensure the flexibility and convenience of data sharing.
6. A method for implementing virtual machine LVM storage data migration and high reliability guarantee according to claim 4, characterized in that: The step S4 specifically includes the following operations: S4.
1. First, upgrade the role of the backup node's drbd0 device to the primary, so that it has the ability to accept data reading and writing, and then start the virtual machine data migration operation; S4.
2. After all virtual machine data on the master node has been successfully migrated to the backup nfs disk, clean up the master node disk.
7. A method for implementing virtual machine LVM storage data migration and high reliability guarantee according to claim 6, characterized in that: Execute step S4.1 and use any of the following methods to migrate virtual machine data: a) Replace the lvm backend of the virtual disk of the openstack virtual machine with the new nfs backend, and switch the storage location of the virtual machine disk by modifying the relevant configuration files and parameters, so as to migrate the data of the virtual machine disk from the primary node to the nfs disk of the backup node; b) Use the libvirt tool to manually execute the virshblockjob command to migrate the virtual machine disk data from the primary node to the NFS disk of the backup node; During the entire migration process, the operating status of the virtual machine is monitored in real time to ensure normal use of the virtual machine.
8. A method for implementing virtual machine LVM storage data migration and high reliability guarantee according to claim 7, characterized in that: Execute step S4.2 to clean up the master node disk. The specific operations are as follows: Clear and format the disk storing virtual machine data on the master node, delete the lvm logical volume and volume group related to the virtual machine on the master node, and release disk space; Reconfigure DRBD on the disk storing virtual machine data on the primary node so that it can synchronize data with the backup node; After the configuration is complete, start the drbd data synchronization function to synchronize the data stored on the nfs disk back to the disk storing the virtual machine data of the primary node, so that the data of the primary and standby nodes are consistent again, preparing for the subsequent possible primary and standby switching.
9. A method for implementing virtual machine LVM storage data migration and high reliability guarantee according to claim 8, characterized in that: Execute step S5. After all active and standby server groups complete data migration, nfs uses the vip address configured by keepalived to access the data. The data is synchronized in real time through drbd in the active and standby server groups. When the primary node fails, the keepalived VIP of the backup node automatically takes effect and continues to provide data access services for the virtual machine, ensuring high data reliability and business continuity.