как расширить хранилище SAN в CentOS 7

У меня есть сервер с CentOS 7, использующий LUN для хранения данных . Недавно группа Storage расширила пространство LUN. Это результат команды multipath -ll

~ # multipath -ll                                                                                    
   mpathc (3600601606cb04000a0eb35b80750eb11) dm-5 DGC     ,VRAID           
   **size=27T** features='2 queue_if_no_path retain_attached_hw_handler' hwhandler='1 alua' wp=rw
   |-+- policy='service-time 0' prio=50 status=active
   | |- 1:0:0:2 sdl 8:176 active ready running
   | `- 4:0:0:2 sdn 8:208 active ready running
   `-+- policy='service-time 0' prio=10 status=enabled
     |- 1:0:1:2 sdm 8:192 active ready running
     `- 4:0:2:2 sdo 8:224 active ready running

. Предыдущий размер был 20 ТБ, а теперь увеличился до 27 ТБ.

Это результат команды fdisk

fdisk -l /dev/mapper/mpathc
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.
Disk /dev/mapper/mpathc: 29686.8 GB, 29686813949952 bytes, 57982058496 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 4194304 bytes
Disk label type: gpt
Disk identifier: 843A6F7E-581A-455E-822F-2CE4306394BF

#         Start          End    Size  Type            Name
1         8192  42949672926     20T  Linux filesyste 

. Вы можете видеть, что размер и количество секторов LUN увеличены. Это результат команды kpartx

kpartx -l /dev/mapper/mpathc
GPT:Primary header thinks Alt. header is not at the end of the disk.
GPT:Alternate GPT header not at the end of the disk.
GPT: Use GNU Parted to correct GPT errors.
mpathc1 : 0 42949664735 /dev/mapper/mpathc 8192

и результат команды df

df -h /dev/mapper/mpathc1
Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/mpathc1   20T   17T  4.0T  81% /Splunk-Storage/COLD

Поэтому я не могу понять, как я могу расширить пространство / dev / mapper / mpathc1 без потери данных. Я очень благодарен за любое предложение Заранее спасибо

2
задан 19 January 2021 в 09:17
2 ответа

Шаг 1 : Попробуйте повторно просканировать устройства хранения, чтобы сообщить ядру об изменении размера. Я не уверен, нужно ли это делать для всех четырех компонентов многолучевого распространения, но это не должно повредить. Вы повторно сканируете устройства хранения, записывая что-нибудь в их файл rescan :

echo > /sys/class/block/sdl/device/rescan
echo > /sys/class/block/sdm/device/rescan
echo > /sys/class/block/sdn/device/rescan
echo > /sys/class/block/sdo/device/rescan

Сканирование HBA также должно работать. SCSI HBA имеют файл сканирования ; вы записываете в него три десятичных числа: контроллер, цель и LUN для сканирования этого LUN. Или используйте подстановочный знак «-» вместо числа. Следующее выполняет сканирование всех устройств на контроллере 0 на двух HBA:

echo "0 - -" > /sys/class/scsi_host/host1/scan
echo "0 - -" > /sys/class/scsi_host/host4/scan

Шаг 2 : На этом этапе ядру известно, что размер / dev / mapper / mpathc составляет 27 ТБ. Теперь вам нужно увеличить размер раздела 1. Для изменения размера разделов можно использовать команду parted , но я считаю, что версия parted для Centos 7 не имеет такой возможности.Поэтому я бы размонтировал файловую систему, удалил раздел (страшно, я знаю), а затем снова создал раздел, на этот раз с правильным размером. Убедитесь, что его параметры верны.

umount /dev/mapper/mpathc1
parted /dev/mapper/mpathc1 rm 1 mkpart primary 0% 100% print

Вы можете сначала протестировать это на диске, который не содержит ценных данных.

Я не знаю, можно ли установить parted версию, в которой есть команда resizepart . Так будет легче сделать второй шаг.

Руководство по хранению RHEL 7 содержит аналогичную процедуру с fdisk , но предполагает использование LVM и отсутствие многопутевости. После процедуры fdisk вам, вероятно, придется использовать kpartx , чтобы сообщить ядру об изменениях на диске. Таким образом, раздельный подход кажется мне проще, а значит, безопаснее.

Шаг 3 : Увеличьте файловую систему. Сначала снова установите его. Если это XFS, вы должны смонтировать его, а затем запустить xfs_growfs .

mount /dev/mapper/mpathc1 /Splunk-Storage/COLD
xfs_growfs /Splunk-Storage/COLD

Если это ext [234], запустите resize2fs . Он может быть установлен или демонтирован.

resize2fs /dev/mapper/mpathc1
mount /dev/mapper/mpathc1 /Splunk-Storage/COLD

Готово.

2
ответ дан 24 April 2021 в 00:12

Спасибо за ваше время.
В шаге 2 я использовал resizepart, но получил следующее:
Ошибка: Резервная таблица GPT не находится в конце диска, как это должно быть. Это может означать, что другая операционная система считает, что диск меньше. Исправить, переместив резервную копию в конец (и удалив старую резервную копию)? Исправить/Игнорировать/Отменить?
Стоит ли исправлять?

Вот полный результат

~ # parted /dev/mapper/mpathc                                                                                                   
 GNU Parted 3.1
 Using /dev/mapper/mpathc
 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? I                                                      
 Warning: Not all of the space available to /dev/mapper/mpathc appears to be used, you can fix the GPT to use all of the space (an extra
 15032385536 blocks) or continue with the current setting? 
 Fix/Ignore? I                                                             
 Model: Linux device-mapper (multipath) (dm)
 Disk /dev/mapper/mpathc: 29.7TB
 Sector size (logical/physical): 512B/512B
 Partition Table: gpt
 Disk Flags: 

 Number  Start   End     Size    File system  Name  Flags
 1      4194kB  22.0TB  22.0TB  xfs

(parted) resizepart                                                       
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? C
0
ответ дан 24 April 2021 в 00:12

Теги

Похожие вопросы