Tamkovich.com: Телеком/VoIP блог » RAID

Как безболезненно увеличить дисковое пространство в Linux или удивительная система LVM

MeteoZond — Tue, 27 Sep 2011 08:03:55 +0000

Появилась задача увеличить объем дискового пространства на хостинговом сервере. Т.к. в качестве панели управления используется ISPmanager, монтирование нового раздела в отдельную папку проблемы бы не решило. По совету коллег решил призвать в помощь LVM (Logical volume manager).

Управление логическими томами (Logical Volume Management — LVM) существует в Linux, начиная с версий ядра 2.4v1 и 2.6.9v2.
Что же такое LVM, Logical volume manager, Управление логическими томами или менеджер логических томов?
LVM – это дополнительный уровень абстракции между привычными логическими/физическими дисками и файловой системой. Эта система позволяет нам объединять несколько физических дисков, разделов на физическом диске, рейд массивов в логический том на котором мы создаем файловую систему. Также у нас появляются возможности быстрых бекапов, перемещения файловой системы с, например, двух HDD по 40гб на один 80гб без выключения компьютера/сервера, увеличения/уменьшения размеров логического тома на ходу (тут надо оговориться про то что файловая система должна поддерживать данные функции).
В общем это удивительная система которая добавляет гибкости и удобства в работу с накопителями данных.

Итак, имеем сервер IBM x3560, два диска уже установлены и работают в зеркале, операционная система CentOS 5.5. Выключаем сервер, устанавливаем еще два диска, объединяем их в рейд 1. Загружаем операционную систему и видим что появился новый неразмеченный раздел /dev/sdb.

До добавления второго рейд массива картина была следующая:
Зеркало видно как /dev/sda, /dev/mapper/VolGroup01-LogVol00 это /
/dev/sda1 это /boot

Небольшая ремарка, необходимо чтобы boot раздел был вне логического тома, иначе загрузиться не получится. Смотрим что нам покажет pvdisplay:

[root@vh ~]# pvdisplay
  --- Physical volume ---
  PV Name               /dev/sda2
  VG Name               VolGroup01
  PV Size               136.51 GB / not usable 8.33 MB
  Allocatable           yes (but full)
  PE Size (KByte)       32768
  Total PE              4368
  Free PE               0
  Allocated PE          4368
  PV UUID               4tSPMO-UJzY-d21j-Mlvi-FfoK-1puC-bERapz

Тут надо сказать что у LVM есть три уровня:

PV это physical volume, так сказать физический уровень (целые диски или разделы)
VG это volume group, на этом уровне объединяем PV в группу
LV это logical volume, логический уровень, объединение VG в единый раздел на котором можно создавать файловую систему.

Видим у нас есть VG по имени VolGroup01 которая находится на PV /dev/sda2

lvdisplay нам говорит следующее:

[root@vh ~]# lvdisplay
  --- Logical volume ---
  LV Name                /dev/VolGroup01/LogVol00
  VG Name                VolGroup01

LV который нам необходимо будет расширить называется /dev/VolGroup01/LogVol00

Далее наши действия:

Инициализируем новый физический диск командой: pvcreate /dev/sdb
Добавляем новый физический диск к нашей существующей VG VolGroup1: vgextend VolGroup01 /dev/sdb
Расширяем наш LV по имени /dev/VolGroup01/LogVol00 на количество общего пространства содержащегося в /dev/sbd: lvextend /dev/VolGroup01/LogVol00 /dev/sdb

Теперь осталось изменить размер файловой системы: resize2fs -p /dev/VolGroup01/LogVol00 Всё, в моем случае я увеличил объем доступного дискового пространства в два раза.

[root@vh ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup01-LogVol00
                      259G   85G  161G  35% /
/dev/sda1              99M   19M   75M  21% /boot
tmpfs                 2.0G     0  2.0G   0% /dev/shm

[root@vh ~]# pvdisplay
  --- Physical volume ---
  PV Name               /dev/sda2
  VG Name               VolGroup01
  PV Size               136.51 GB / not usable 8.33 MB
  Allocatable           yes (but full)
  PE Size (KByte)       32768
  Total PE              4368
  Free PE               0
  Allocated PE          4368
  PV UUID               4tSPMO-UJzY-d21j-Mlvi-FfoK-1puC-bERapz

  --- Physical volume ---
  PV Name               /dev/sdb
  VG Name               VolGroup01
  PV Size               136.61 GB / not usable 17.00 MB
  Allocatable           yes (but full)
  PE Size (KByte)       32768
  Total PE              4371
  Free PE               0
  Allocated PE          4371
  PV UUID               YMX3a0-deJr-VrCL-5zrO-z65K-RJ62-vSrCHJ

[root@vh ~]# vgdisplay
  --- Volume group ---
  VG Name               VolGroup01
  System ID
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  5
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               2
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               273.09 GB
  PE Size               32.00 MB
  Total PE              8739
  Alloc PE / Size       8739 / 273.09 GB
  Free  PE / Size       0 / 0
  VG UUID               CGsscq-7UDT-3qUB-82DW-IzeK-3Ab9-iTG6Pq

[root@vh ~]# lvdisplay
  --- Logical volume ---
  LV Name                /dev/VolGroup01/LogVol00
  VG Name                VolGroup01
  LV UUID                P6aTcD-KMw6-jFUF-Cpio-C3CW-tMh2-DwLmD4
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                267.28 GB
  Current LE             8553
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

  --- Logical volume ---
  LV Name                /dev/VolGroup01/LogVol01
  VG Name                VolGroup01
  LV UUID                vd0uP2-DkST-L4ob-EAZT-N4jP-Jw1h-EUBh0l
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                5.81 GB
  Current LE             186
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:1

/dev/VolGroup01/LogVol01 в нашем случае это swap.

Также рекомендую к прочтению следующие статьи:

Производительность IBM ServeRAID-8k в различных конфигурациях

Сергей Тамкович — Tue, 01 Dec 2009 12:07:55 +0000

Около двух лет назад, я приобрёл отличный сервер IBM x3650. Сервер был предназначен для хранения биллинговой БД. Я очень люблю сервера IBM. Они делают отличное, качественное железо. Каждый элемент сервера продуман и выверен. Здесь и салазки, которые крепятся в стойку без винтов, и кулеры, работа которых мониторится, и удобные крепления жестких дисков. О конструктивных достоинствах серверов IBM можно рассказывать очень долго.

Для биллинга, одну из ключевых ролей играет дисковая подсистема. Она должна быть быстрой и надёжной. Купленный мной сервер, был оснащён контроллером IBM ServeRAID 8k и 8ю жесткими дисками IBM-ESXS MBB2073RC 10000 RPM 16MB Cache SAS 2.5″ 70G, 3.0 G/s. Под брендом ServeRAID 8k IBM продаёт контроллер известной компании Adaptec. Данный контроллер поддерживает большое число режимов и ещё больше опций к каждому из них. Для того, что бы количественно оценить быстродействие каждого из режимов, я воспользовался пакетом bonnie++. Не смотря на то, что с момента тестирования прошло около двух лет, надеюсь, что полученные мною данные до сих пор актуальны для многих. Кроме непосредственно производительности различных режимов, полученные данные позволяют понять, как различные режимы соотносятся друг к другу.

Методика тестирования.

Мною были протестированы следующие режимы raid0, raid1, raid1e, raid5, raid6 и raid10. Т.к. Я не вижу смысла в выделение отдельного жесткого диска под систему, на мой взгляд, можно ограничиться разделом на общем RAID массиве. По этому все жёсткие диски были объединены в 1 массив. Для тестирования использовалась «чистая» ОС CentOS 5.2. Рабочий объём тестирования — 16 гигабайт. Для уменьшения влияния погрешностей, каждый тест был повторён 20 раз, результаты усреднены.

Интерпретация результатов.

Протестировать быстродействие контроллера в различных режимах для посимвольных чтения и записи, а так же последовательного создания файлов и их удаления — не получилось. Дело в том, что эти операции упёрлись в быстродействие процессора. Выглядит это примерно вот так:

Как мы видим из графика, скорость чтения не зависит от режима raid контроллера и примерно одинакова. Это объясняется тем, что узким местом при посимвольном чтении является процессор. Нагрузка на процессор, так же одинакова и высока.

Свою силу контроллер показывает на операциях блочного чтения и записи. RAID1 и RAID0 – две противоположности. RAID1 это зеркало из 8 жёстких дисках, его производительность сводится к производительности отдельного жёсткого диска с быстрым кешем перед ним. RAID0 это страйп из 8 дисков, и его производительность, грубо, в 8 раз больше производительности RAID1. Удивительно выглядит большая скорость записи в RAID0, вероятно это объясняется большими кешами жёстких дисков и RAID контроллера, а так же «чистой» системой. Из других интересных моментов, хочу отметить провал RAID6 по скорости записи. Это объясняется сложным математическим аппаратом данного режима – при записи контроллеру необходимо произвести большое количество вычислений.

Скорость поиска лишь подтверждает тройку лидеров. В целом, режимы RAID5, RAID10 и RAID1e выглядят наиболее подходящими для промышленного использования. Там где надёжность желательна, но не критична, ей можно пожертвовать в пользу объёма и быстродействия, выбрав RAID5. Если же вы работаете с данными, потерять которые нельзя (например Биллинг) – ваш выбор RAID10.

Недостатки данного обзора

К сожалению, во время испытаний, я забыл провести один несложный, но очень важный тест: тест на скорость восстановления жесткого диска в случае сбоя. Интуитивно, я предполагаю, что максимальную скорость восстановления обеспечат RAID1 и RAID10, а минимальную RAID5 и RAID6. Однако очень интересно было бы узнать во сколько раз отличаются эти времена.