Статическая разбивка дисков уходит в прошлое, на смену ей давно пришли различные менеджеры томов и их гибриды с файловыми системами. В AIX и HP-UX даже нужны достаточно серьезные костыли, чтобы не использовать менеджер томов. Дистрибутивы Linux также сейчас по умолчанию делают разбивку средствами LVM, что говорит о достаточной стабильности этого механизма для использования в корпоративной среде.
Но на рынке довольно давно присутствует продукт компании Symantec (купившей Veritas), который называется Veritas Storage Foundation (в последней версии Storage Foundation High Availability). Он включает в себя довольно много средств управления дисковым пространством: начиная от настройки Multipath, заканчивая собственной крайне гибкой файловой системой, и доступен под все современные серверные ОС.
На практике инженеры чаще всего сталкиваются с продуктами Veritas, когда приходят на новую работу, логинятся на какой-то сервер, там оказывается Veritas, и они на все помещение кричат “WTF??”. Я впервые встретился с ним на HP-UX, знакомство было весьма натянутым, приходилось долго разбираться.
В этой статье я дам некоторое базовое понимание что такое Veritas Volume Manager (VxVM) и как он работает.
Преимущества для сервиса перед статикой, некоторые и перед LVM:
— Утилизация пространства. Разделы можно расширять и уменьшать без остановки сервиса, выделение места под новые сервисы так же проходит без влияния на сервис. Поддерживается Thin Provisioning.
— Дедубликация и компрессия. В ряде задач помогает экономить место.
— Управление путями. Пакет содержит средство управления путями к устройству (multipath), которое позволяет довольно гибко настроить политики балансировки, доступности и т.д.
— Тиринг (tiering). Оптимизация размещения данных в зависимости от их классификации
— Миграция данных. Полезно, когда нужно перебросить диски на другую систему с любой ОС. Всего одна команда на источнике и одна на приемнике, и группа вместе с данными доступна на другом сервере. Само собой, диски должны быть презентованы на оба сервера.
Основной недостаток — сравнительная сложность администрирования и платность как дополнительного продукта (только с HP-UX он поставляется в дистрибутиве, можно выбирать между LVM и VxVM). Если в том же LVM администратор работает только с тремя компонентами менеджера, то в Veritas добавлено еще два. Для базовых задач эти компоненты и не нужны, но без понимания как они работают будет невозможно добиться максимальной производительности, гибкости, а так же справиться с внештатными ситуациями.
Установка не вызывает вопросов, установочный скрипт делает все, что нужно. После установки может потребоваться вызвать “vxinstall” для инициализации сервисов и их запуска.
В качестве входных параметров есть несколько чистых дисков, из которых, в конечном итоге, нужно получить файловые системы. В терминологии Veritas это “Physical disks”:
Из вывода команды видим, что системе доступно 5 дисков, но они не инициализированы для работы с VxVM. На “sda” у меня стоит система, поэтому его трогать не буду.
Для добавления устройства в VxVM нужно записать на него служебную область при помощи команды “vxdisksetup” c ключом “-i” (Initialize the private region):
Важно отметить, что Veritas не запрашивает у пользователя имена файлов устройств, используются записи из поля “DEVICE”.
Теперь имеем другой вывод команды “vxdisk list”:
Тип “cdsdisk” используется по умолчанию для разделов с данными, и не поддерживает загрузку. Если возникнет желание грузиться с диска, инкапсулированного VxVM, нужно будет инициализировать диск как “sliced”.
Теперь на основе двух инициализированных дисков создадим группу dg_first, присвоив устройствам имена дисков:
Последняя команда показала более детальную информацию о группе. Довольно важное поле LENGTH указывает на длину в секторах. Неудобно, да… Сектор в данном случае 512 байт, получаем 2Гб на диск. Когда в группе много дисков, приходится прибегать к помощи подручных средств, и получается что-то типа:
Сразу предупрежу, что таких приколов в Veritas хватает, но со временем вырабатывается привычка и все воспринимается как так и надо.
Теперь создадим том vol1 в группе dg_first размером 2Гб, на который можно будет записать файловую систему, чтобы ее можно было уже смонтировать:
В принципе, описанный процесс аналогичен процессу создания раздела в LVM, описанные выше два слоя создались автоматически: plex и subdisk. Их будет видно в выводе команды vxprint:
Вывод комманды можно трактовать так: дисковая группа dg_first состоит из одного плекса vol1-01, который, в свою очередь, состоит из двух сабдисков disk1-01 и disk2-01 (PLOFFS — plex association offset). Добавим еще один том размером 1Гб и посмотрим, где он расположится:
Второй том получил свой плекс, который содержит один сабдиск, и этот сабдиск поместился на второй диск (первый сабдиск занял немного второго диска, очевидно в связи с наличием служебных областей). Графически это представляется так:
Детальную информации о расположении плексов и сабдисков дает команда vxprint с соответствующими ключами:
В процессе эксплуатации можно оперировать плексами и сабдисками: создавать, удалять, ассоциировать друг с другом и т.д. Это вносит некоторую сложность и, возможно, путаницу, но добавляет гибкость в размещении данных.
Теперь можно создать файловую систему на существующих томах vol1 и vol2. Я уже упоминал, что пакет содержит собственную очень гибкую и производительную файловую систему Veritas File System (vxfs). Создадим ее на томах и смонтируем:
Обратите внимание на путь к файлу блочного устройства: постоянный путь к файлам устройств VxVM “/dev/vx”, далее dsk (блочные устройства) или rdsk (символьные устройства), имя группы и имена томов. Все логично. Проверим размеры файловых систем:
Все отлично. Но у нас есть еще 2 диска: sdd и sde, можно попробовать их добавить и расширить существующие файловые системы в 2 раза:
Добавились только диски. Изменяем размер томов вместе с файловыми системами:
Расширились тома и файловая система. Обратите внимание как распределились сабдиски.
Допустим, теперь у нас есть задача отдать sdb, который содержит данные на смонтированной файловой системе. Попытка его отключить ничего не даст, т.к. там есть сабдиск, да и некуда было бы смигрировать все данные:
На диске disk4 занято всего 1Гб, поэтому сначала заберем гигабайт с файловой системы, затем освободим disk1 (на котором лежит сабдиск disk1-01, принадлежащий плексу vol1-01 тома vol1) и выведем его из VxVM:
Видим, что к vol1 добавились сабдиски disk3-02 и disk4-02, т.е. система использовала все свободное пространство диска disk3, затем заняла необходимое количество места на диске disk4.
Для первой статьи достаточно. Думаю, в общих чертах понятно, как работает данный продукт. Команды и ключи детально не описывал, чтобы еще больше не раздувать статью, рекоммендую погуглить “vxvm cheat sheet”, выбрать табличку и распечатать ее.
Если будет заинтересованность, в следующих статьях я рассмотрю такие темы, как миграция лунов, оптимизация пространства, файловая система vxfs и другие.
Но на рынке довольно давно присутствует продукт компании Symantec (купившей Veritas), который называется Veritas Storage Foundation (в последней версии Storage Foundation High Availability). Он включает в себя довольно много средств управления дисковым пространством: начиная от настройки Multipath, заканчивая собственной крайне гибкой файловой системой, и доступен под все современные серверные ОС.
На практике инженеры чаще всего сталкиваются с продуктами Veritas, когда приходят на новую работу, логинятся на какой-то сервер, там оказывается Veritas, и они на все помещение кричат “WTF??”. Я впервые встретился с ним на HP-UX, знакомство было весьма натянутым, приходилось долго разбираться.
В этой статье я дам некоторое базовое понимание что такое Veritas Volume Manager (VxVM) и как он работает.
Преимущества для сервиса перед статикой, некоторые и перед LVM:
— Утилизация пространства. Разделы можно расширять и уменьшать без остановки сервиса, выделение места под новые сервисы так же проходит без влияния на сервис. Поддерживается Thin Provisioning.
— Дедубликация и компрессия. В ряде задач помогает экономить место.
— Управление путями. Пакет содержит средство управления путями к устройству (multipath), которое позволяет довольно гибко настроить политики балансировки, доступности и т.д.
— Тиринг (tiering). Оптимизация размещения данных в зависимости от их классификации
— Миграция данных. Полезно, когда нужно перебросить диски на другую систему с любой ОС. Всего одна команда на источнике и одна на приемнике, и группа вместе с данными доступна на другом сервере. Само собой, диски должны быть презентованы на оба сервера.
Основной недостаток — сравнительная сложность администрирования и платность как дополнительного продукта (только с HP-UX он поставляется в дистрибутиве, можно выбирать между LVM и VxVM). Если в том же LVM администратор работает только с тремя компонентами менеджера, то в Veritas добавлено еще два. Для базовых задач эти компоненты и не нужны, но без понимания как они работают будет невозможно добиться максимальной производительности, гибкости, а так же справиться с внештатными ситуациями.
Установка не вызывает вопросов, установочный скрипт делает все, что нужно. После установки может потребоваться вызвать “vxinstall” для инициализации сервисов и их запуска.
В качестве входных параметров есть несколько чистых дисков, из которых, в конечном итоге, нужно получить файловые системы. В терминологии Veritas это “Physical disks”:
# vxdisk list
DEVICE TYPE DISK GROUP STATUS
sda auto:none - - online invalid
sdb auto:none - - online invalid
sdc auto:none - - online invalid
sdd auto:none - - online invalid
sde auto:none - - online invalid
Из вывода команды видим, что системе доступно 5 дисков, но они не инициализированы для работы с VxVM. На “sda” у меня стоит система, поэтому его трогать не буду.
Для добавления устройства в VxVM нужно записать на него служебную область при помощи команды “vxdisksetup” c ключом “-i” (Initialize the private region):
# /opt/VRTS/bin/vxdisksetup -i sdb
# /opt/VRTS/bin/vxdisksetup -i sdc
# /opt/VRTS/bin/vxdisksetup -i sdd
# /opt/VRTS/bin/vxdisksetup -i sde
Важно отметить, что Veritas не запрашивает у пользователя имена файлов устройств, используются записи из поля “DEVICE”.
Теперь имеем другой вывод команды “vxdisk list”:
# vxdisk list
DEVICE TYPE DISK GROUP STATUS
sda auto:none - - online invalid
sdb auto:cdsdisk - - online
sdc auto:cdsdisk - - online
sdd auto:cdsdisk - - online
sde auto:cdsdisk - - online
Тип “cdsdisk” используется по умолчанию для разделов с данными, и не поддерживает загрузку. Если возникнет желание грузиться с диска, инкапсулированного VxVM, нужно будет инициализировать диск как “sliced”.
Теперь на основе двух инициализированных дисков создадим группу dg_first, присвоив устройствам имена дисков:
# vxdg init dg_first disk1=sdb disk2=sdc
# vxdisk list
DEVICE TYPE DISK GROUP STATUS
sda auto:none - - online invalid
sdb auto:cdsdisk disk1 dg_first online
sdc auto:cdsdisk disk2 dg_first online
sdd auto:cdsdisk - - online
sde auto:cdsdisk - - online
# vxprint -g dg_first
TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0 PUTIL0
dg dg_first dg_first - - - - - -
dm disk1 sdb - 4120320 - - - -
dm disk2 sdc - 4120320 - - - -
Последняя команда показала более детальную информацию о группе. Довольно важное поле LENGTH указывает на длину в секторах. Неудобно, да… Сектор в данном случае 512 байт, получаем 2Гб на диск. Когда в группе много дисков, приходится прибегать к помощи подручных средств, и получается что-то типа:
# vxprint -g dg_first|awk 'BEGIN{DGSIZE=0} {DGSIZE=DGSIZE+$5} END{print "DG size:" DGSIZE*512/1024/1024}'
DG size:4023.75
Сразу предупрежу, что таких приколов в Veritas хватает, но со временем вырабатывается привычка и все воспринимается как так и надо.
Теперь создадим том vol1 в группе dg_first размером 2Гб, на который можно будет записать файловую систему, чтобы ее можно было уже смонтировать:
# vxassist -g dg_first make vol1 2G
# vxprint -g dg_first -vt vol1
V NAME RVG/VSET/CO KSTATE STATE LENGTH READPOL PREFPLEX UTYPE
v vol1 - ENABLED ACTIVE 4194304 SELECT - fsgen
В принципе, описанный процесс аналогичен процессу создания раздела в LVM, описанные выше два слоя создались автоматически: plex и subdisk. Их будет видно в выводе команды vxprint:
# vxprint -g dg_first
TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0 PUTIL0
dg dg_first dg_first - - - - - -
dm disk1 sdb - 4120320 - - - -
dm disk2 sdc - 4120320 - - - -
v vol1 fsgen ENABLED 4194304 - ACTIVE - -
pl vol1-01 vol1 ENABLED 4194304 - ACTIVE - -
sd disk1-01 vol1-01 ENABLED 4120320 0 - - -
sd disk2-01 vol1-01 ENABLED 73984 4120320 - - -
Вывод комманды можно трактовать так: дисковая группа dg_first состоит из одного плекса vol1-01, который, в свою очередь, состоит из двух сабдисков disk1-01 и disk2-01 (PLOFFS — plex association offset). Добавим еще один том размером 1Гб и посмотрим, где он расположится:
# vxassist -g dg_first make vol2 1G
# vxprint -g dg_first
TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0 PUTIL0
dg dg_first dg_first - - - - - -
dm disk1 sdb - 4120320 - - - -
dm disk2 sdc - 4120320 - - - -
v vol1 fsgen ENABLED 4194304 - ACTIVE - -
pl vol1-01 vol1 ENABLED 4194304 - ACTIVE - -
sd disk1-01 vol1-01 ENABLED 4120320 0 - - -
sd disk2-01 vol1-01 ENABLED 73984 4120320 - - -
v vol2 fsgen ENABLED 2097152 - ACTIVE - -
pl vol2-01 vol2 ENABLED 2097152 - ACTIVE - -
sd disk2-02 vol2-01 ENABLED 2097152 0 - - -
Второй том получил свой плекс, который содержит один сабдиск, и этот сабдиск поместился на второй диск (первый сабдиск занял немного второго диска, очевидно в связи с наличием служебных областей). Графически это представляется так:
Детальную информации о расположении плексов и сабдисков дает команда vxprint с соответствующими ключами:
# vxprint -g dg_first -s -t
Disk group: dg_first
SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE MODE
SV NAME PLEX VOLNAME NVOLLAYR LENGTH [COL/]OFF AM/NM MODE
SC NAME PLEX CACHE DISKOFFS LENGTH [COL/]OFF DEVICE MODE
sd disk1-01 vol1-01 disk1 0 4120320 0 sdb ENA
sd disk2-01 vol1-01 disk2 0 73984 4120320 sdc ENA
sd disk2-02 vol2-01 disk2 73984 2097152 0 sdc ENA
В процессе эксплуатации можно оперировать плексами и сабдисками: создавать, удалять, ассоциировать друг с другом и т.д. Это вносит некоторую сложность и, возможно, путаницу, но добавляет гибкость в размещении данных.
Теперь можно создать файловую систему на существующих томах vol1 и vol2. Я уже упоминал, что пакет содержит собственную очень гибкую и производительную файловую систему Veritas File System (vxfs). Создадим ее на томах и смонтируем:
# mkfs.vxfs /dev/vx/dsk/dg_first/vol1
version 9 layout
4194304 sectors, 2097152 blocks of size 1024, log size 16384 blocks
rcq size 1024 blocks
largefiles supported
# mkfs.vxfs /dev/vx/dsk/dg_first/vol2
version 9 layout
2097152 sectors, 1048576 blocks of size 1024, log size 16384 blocks
rcq size 1024 blocks
largefiles supported
# mount.vxfs /dev/vx/dsk/dg_first/vol1 /mnt/vol1
# mount.vxfs /dev/vx/dsk/dg_first/vol2 /mnt/vol2
Обратите внимание на путь к файлу блочного устройства: постоянный путь к файлам устройств VxVM “/dev/vx”, далее dsk (блочные устройства) или rdsk (символьные устройства), имя группы и имена томов. Все логично. Проверим размеры файловых систем:
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vx/dsk/dg_first/vol1
2.0G 19M 1.9G 1% /mnt/vol1
/dev/vx/dsk/dg_first/vol2
1.0G 19M 943M 2% /mnt/vol2
Все отлично. Но у нас есть еще 2 диска: sdd и sde, можно попробовать их добавить и расширить существующие файловые системы в 2 раза:
# vxdg -g dg_first adddisk disk3=sdd disk4=sde
# vxprint -g dg_first
TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0 PUTIL0
dg dg_first dg_first - - - - - -
dm disk1 sdb - 4120320 - - - -
dm disk2 sdc - 4120320 - - - -
dm disk3 sdd - 4120320 - - - -
dm disk4 sde - 4120320 - - - -
v vol1 fsgen ENABLED 4194304 - ACTIVE - -
pl vol1-01 vol1 ENABLED 4194304 - ACTIVE - -
sd disk1-01 vol1-01 ENABLED 4120320 0 - - -
sd disk2-01 vol1-01 ENABLED 73984 4120320 - - -
v vol2 fsgen ENABLED 2097152 - ACTIVE - -
pl vol2-01 vol2 ENABLED 2097152 - ACTIVE - -
sd disk2-02 vol2-01 ENABLED 2097152 0 - - -
Добавились только диски. Изменяем размер томов вместе с файловыми системами:
# /usr/lib/vxvm/bin/vxresize -F vxfs -g dg_first vol1 4G
# /usr/lib/vxvm/bin/vxresize -F vxfs -g dg_first vol2 2G
# vxprint -g dg_first
TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0 PUTIL0
dg dg_first dg_first - - - - - -
dm disk1 sdb - 4120320 - - - -
dm disk2 sdc - 4120320 - - - -
dm disk3 sdd - 4120320 - - - -
dm disk4 sde - 4120320 - - - -
v vol1 fsgen ENABLED 8388608 - ACTIVE - -
pl vol1-01 vol1 ENABLED 8388608 - ACTIVE - -
sd disk1-01 vol1-01 ENABLED 4120320 0 - - -
sd disk2-01 vol1-01 ENABLED 73984 4120320 - - -
sd disk2-03 vol1-01 ENABLED 73984 4194304 - - -
sd disk3-01 vol1-01 ENABLED 4120320 4268288 - - -
v vol2 fsgen ENABLED 4194304 - ACTIVE - -
pl vol2-01 vol2 ENABLED 4194304 - ACTIVE - -
sd disk2-02 vol2-01 ENABLED 2097152 0 - - -
sd disk4-01 vol2-01 ENABLED 2097152 2097152 - - -
# df -h
/dev/vx/dsk/dg_first/vol1
4.0G 20M 3.8G 1% /mnt/vol1
/dev/vx/dsk/dg_first/vol2
2.0G 19M 1.9G 1% /mnt/vol2
Расширились тома и файловая система. Обратите внимание как распределились сабдиски.
Допустим, теперь у нас есть задача отдать sdb, который содержит данные на смонтированной файловой системе. Попытка его отключить ничего не даст, т.к. там есть сабдиск, да и некуда было бы смигрировать все данные:
# vxdg -g dg_first rmdisk disk1
VxVM vxdg ERROR V-5-1-552 Disk disk1 is used by one or more subdisks.
Use -k to remove device assignment.
На диске disk4 занято всего 1Гб, поэтому сначала заберем гигабайт с файловой системы, затем освободим disk1 (на котором лежит сабдиск disk1-01, принадлежащий плексу vol1-01 тома vol1) и выведем его из VxVM:
# /usr/lib/vxvm/bin/vxresize -F vxfs -g dg_first vol1 -1G
# vxprint
Disk group: dg_first
TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0 PUTIL0
dg dg_first dg_first - - - - - -
dm disk1 sdb - 4120320 - - - -
dm disk2 sdc - 4120320 - - - -
dm disk3 sdd - 4120320 - - - -
dm disk4 sde - 4120320 - - - -
v vol1 fsgen ENABLED 6291456 - ACTIVE - -
pl vol1-01 vol1 ENABLED 6291456 - ACTIVE - -
sd disk1-01 vol1-01 ENABLED 4120320 0 - - -
sd disk2-01 vol1-01 ENABLED 73984 4120320 - - -
sd disk2-03 vol1-01 ENABLED 73984 4194304 - - -
sd disk3-01 vol1-01 ENABLED 2023168 4268288 - - -
v vol2 fsgen ENABLED 4194304 - ACTIVE - -
pl vol2-01 vol2 ENABLED 4194304 - ACTIVE - -
sd disk2-02 vol2-01 ENABLED 2097152 0 - - -
sd disk4-01 vol2-01 ENABLED 2097152 2097152 - - -
# vxassist -g dg_first move vol1 '!disk1'
# vxdg -g dg_first rmdisk disk1
# vxprint -g dg_first
TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0 PUTIL0
dg dg_first dg_first - - - - - -
dm disk2 sdc - 4120320 - - - -
dm disk3 sdd - 4120320 - - - -
dm disk4 sde - 4120320 - - - -
v vol1 fsgen ENABLED 6291456 - ACTIVE - -
pl vol1-01 vol1 ENABLED 6291456 - ACTIVE - -
sd disk3-02 vol1-01 ENABLED 2097152 0 - - -
sd disk4-02 vol1-01 ENABLED 2023168 2097152 - - -
sd disk2-01 vol1-01 ENABLED 73984 4120320 - - -
sd disk2-03 vol1-01 ENABLED 73984 4194304 - - -
sd disk3-01 vol1-01 ENABLED 2023168 4268288 - - -
v vol2 fsgen ENABLED 4194304 - ACTIVE - -
pl vol2-01 vol2 ENABLED 4194304 - ACTIVE - -
sd disk2-02 vol2-01 ENABLED 2097152 0 - - -
sd disk4-01 vol2-01 ENABLED 2097152 2097152 - - -
Видим, что к vol1 добавились сабдиски disk3-02 и disk4-02, т.е. система использовала все свободное пространство диска disk3, затем заняла необходимое количество места на диске disk4.
Для первой статьи достаточно. Думаю, в общих чертах понятно, как работает данный продукт. Команды и ключи детально не описывал, чтобы еще больше не раздувать статью, рекоммендую погуглить “vxvm cheat sheet”, выбрать табличку и распечатать ее.
Если будет заинтересованность, в следующих статьях я рассмотрю такие темы, как миграция лунов, оптимизация пространства, файловая система vxfs и другие.