Server Raid Level Adjustment

Server Raid Level Adjustment

1. Adjust the background

The system disk is two 600G HDD operating systems through Raid1, and the server has 4 600G HDD disks in total. In order to ensure the redundancy of the disks, raid1 needs to be configured, so that the available space is 1.2T, and 2 disks are wasted.

Recently, due to insufficient system resources, in line with the principle of reducing costs and increasing the maximum scientific availability of resources, it is necessary to adjust the disk raid level, from two groups of Raid 1 to one group of Raid 5 with 1 redundant disk. (All servers are planned for long-term renewal, that is, the damaged disk will be replaced in time within one week)

Raid level adjustment requirements

PS: As a premise, there is no bottleneck in the normal use of disk io. Difficulties, system disk refresh and logical volume PV size adjustment. Note that there is loss of io during raid reconstruction, and it is recommended to do it after the business underestimation period or business migration.

2. Adjustment steps

2.1 Prepare resources:

Migrate another group of RAID services in advance to release resources;

2.2 Perform basic RAID migration:

raid level adjustment step 1
Raid level adjustment step 2

2.3 Waiting for RAID rebuild

raid rebuild

Reconstruction is a long process. 600G data needs to be rebuilt for about 12 hours. During the rebuilding process, io will appear slow. Of course, there are situations where data loss and reconstruction fail, so it is recommended to make all preparations.

2.4 Refresh system hard disk identification

raid rebuild completed

From the out-of-band management of the system, it can be seen that the raid resources have been rebuilt, the sector has RAID1==>RAID5, and the capacity has changed from 600G ===>1675G.

The first problem arises: how to refresh it?

Use partproble to make the system kernel reload the partition situation, but failed.

Use the restart method, the system is reloaded, and it is effective.

But restarting Dafa is too cumbersome, and the server still has marginal business.

Use command: “echo 1 > /sys/block/sda/device/rescan”

rescan

2.5 GPT partition size modification

The system recognizes that sda is 1.7T, but the system disk adopts the GPT hard disk format, and the data distribution adopts the partition + LVM method, that is, the logical volume is not recognized.

**Second problem: PV refresh.**

For this reason, I have tried to modify the partition size in rescue mode, and various command refreshes are invalid. Have considered system reinstallation.

Use the parted command to modify the partition size

[root@bj-test-kvm-db-2-18 ~]# echo 1 > /sys/block/sda/device/rescan
[root@bj-test-kvm-db-2-18 ~]# df
Filesystem                           1K-blocks       Used  Available Use% Mounted on
devtmpfs                             263874956          0  263874956   0% /dev
tmpfs                                263886916          4  263886912   1% /dev/shm
tmpfs                                263886916    1283240  262603676   1% /run
tmpfs                                263886916          0  263886916   0% /sys/fs/cgroup
/dev/mapper/centos-root              104806400    3879200  100927200   4% /
/dev/sda2                               508580     172484     336096  34% /boot
/dev/sda1                               204580      11484     193096   6% /boot/efi
/dev/mapper/vg_hdd_db02-lv_data2    4685043712 3221956368 1463087344  69% /data2
/dev/mapper/vg_ssd_db01-lv_datassd   780410564  305965012  474445552  40% /data_ssd
/dev/mapper/centos-lv_data           469205152  407205156   61999996  87% /data
/dev/mapper/vg_ssdr002-lv_datassd_2  780410564  778790216    1620348 100% /data_ssd2
tmpfs                                 52777384          0   52777384   0% /run/user/0
[root@bj-test-kvm-db-2-18 ~]# lsblk
NAME                      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                         8:0    0   1.7T  0 disk 
├─sda1                      8:1    0   200M  0 part /boot/efi
├─sda2                      8:2    0   500M  0 part /boot
└─sda3                      8:3    0 557.7G  0 part 
  ├─centos-root           253:0    0   100G  0 lvm  /
  ├─centos-swap           253:1    0    10G  0 lvm  [SWAP]
  └─centos-lv_data        253:3    0 447.7G  0 lvm  /data
sdb                         8:16   0 744.6G  0 disk 
└─vg_ssd_db01-lv_datassd  253:4    0 744.6G  0 lvm  /data_ssd
sdd                         8:48   0   4.4T  0 disk 
└─vg_hdd_db02-lv_data2    253:2    0   4.4T  0 lvm  /data2
sde                         8:64   0 744.6G  0 disk 
└─vg_ssdr002-lv_datassd_2 253:6    0 744.6G  0 lvm  /data_ssd2
[root@bj-test-kvm-db-2-18 ~]# vgs
  VG          #PV #LV #SN Attr   VSize    VFree
  centos        1   3   0 wz--n- <557.69g    0 
  vg_hdd_db02   1   1   0 wz--n-   <4.37t    0 
  vg_ssd_db01   1   1   0 wz--n-  744.62g    0 
  vg_ssdr002    1   1   0 wz--n-  744.62g    0 
[root@bj-test-kvm-db-2-18 ~]# fdisk -l /dev/sda

Disk /dev/sda: 1798.7 GB, 1798651772928 bytes, 3512991744 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1  1170997247   585498623+  ee  GPT
[root@bj-test-kvm-db-2-18 ~]# parted /dev/sda
GNU Parted 3.1
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p                                                                
Error: The backup GPT table is not at the end of the disk, as it should be.  This might mean that another operating system believes the disk is smaller.  Fix, by moving the backup to the end (and removing the
old backup)?
Fix/Ignore/Cancel? fix                                                    
Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 2341994496 blocks) or continue with the current setting? 
Fix/Ignore? Fix                                                           
Model: DELL PERC H730P Mini (scsi)
Disk /dev/sda: 1799GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size   File system  Name                  Flags
 1      1049kB  211MB  210MB  fat16        EFI System Partition  boot
 2      211MB   735MB  524MB  xfs
 3      735MB   600GB  599GB                                     lvm

(parted) res                                                              
rescue      resize      resizepart  
(parted) resizepart 3
End?  [600GB]? 100%
(parted) p                                                                
Model: DELL PERC H730P Mini (scsi)
Disk /dev/sda: 1799GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name                  Flags
 1      1049kB  211MB   210MB   fat16        EFI System Partition  boot
 2      211MB   735MB   524MB   xfs
 3      735MB   1799GB  1798GB                                     lvm

partd partition operation

2.6 Refresh PV size

The size of /dev/sda3 has been refreshed, but the pv size and the remaining size of vg are still unchanged.

Use the command: "pvresize /dev/sda3"

lvm expansion

3. Summary of adjustments

  1. Perform any raid-related operations to migrate the business, and make preparations for data loss that will not affect the business
  2. System disk capacity adjustment is a big problem, and in most cases, the system needs to be restarted.
  3. Steps for this operation:
    • dell raid migration, rebuild
    • System Disk Capacity Refresh
    • System gpt partition capacity refresh
    • pv data refresh

There are risks in the operation, and the operation needs to be cautious. The principle of backup first

Guess you like

Origin blog.csdn.net/weixin_43423965/article/details/128558598