Как правило ко мне с такой задачкой регулярно обращаются DBA, когда их база в очередной раз норовит заполнить выделенное пространство :)
Разумеется, никто не мешает поступить максимально просто - выделисть новый виртуальный диск на SAN, подключить его скопировать данные на новое место. Однако, для больших дисков (а для баз данных 100-200 гигабайт это вполне заурядный размер) это занимает массу времени. А если нужно проделать операцию для 2х-5ти серверов?
Гораздо быстрее будет увеличить виртуальный диск средствами SAN, а потом изменить размер FS средствами OS.
Делается это очень просто. Рассмотрим случай для RHEL 5
Пусть мы подключены к SAN через два оптических HBA адаптера и используем multipath для обеспечения надежности:
Процедура следующая:
- размонтируем FS. Если FS не размонтируется (device is busy) - можно воспользоваться командой fuser, чтобы определить, кто занял FS
# fuser -muv /dev/multipath/vdisk - увеличиваем через консоль управления стораджем размер виртуального диска (как это сделать - должно быть описано в мануале к SAN)
- делаем рескан SAN разделов. Процедура описана здесь
- не торопимся монтировать диск после предыдущего шага! нужно еще увеличить FS.
если виртуальный диск не разбивался на разделы (partitions), то все просто, с помощью resize2fs "растягиваем" диск:# fsck -f /dev/mapper/vdisk
# resize2fs /dev/mapper/vdisk
# fsck -f /dev/mapper/vdisk
Операция проверки диска (fsck) может оказаться весьма длительной! Все зависит от размера раздела.- если виртуальный диск таки был разбит на части, то задача несколько усложняется. К сожалению, удобной утилитой parted обычно воспользоваться не получается, т.к. работа с ext3 в ней не поддерживается. Приходится прибегать к другому способу - через fdisk
- запускаем fdisk
- на всякий случай просматриваем partition table и выписываем номера Start и End (по ним всегда можно восстановить раздел "как было")
- удаляем существующий раздел (на SAN обычно создается только один раздел, так что неопределенностей быть не должно. В противном случае задача становится совсем нетривиальной, скопировать данные на новый раздел получится, пожалуй, быстрее)
- создаем раздел заново, на все доступное пространство
- выходим из fdisk с сохранением.
- при выходе из fdisk таблица разделов должна перечитаться автоматически. Иногда этого не происходит (о чем выводится соответствующее сообщение), тогда даем команду :# partprobe /dev/mapper/u01
- дальше "растягиваем" диск, как было описано выше, только устройство уже будет именоваться как /dev/mapper/vdiskp1
Фокус с удалением раздела fdisk срабатывает по той причине, что fdisk не меняет данные на диске - он меняет только таблицу разделов (partition table). Следовательно, если начало раздела попадает в ту же точку, где раздел начинался, потери данных не будет.
>Однако, для больших дисков (а для баз данных 100-200 гигабайт это вполне заурядный размер) это занимает массу времени.
ВідповістиВидалитито что вы предложили - одни команды, записи + fsck займут сравнимо времени. уж лучше и правда скопировать (при скорости 100мб/сек это 100-200 сек) потери времени практически идентичны если не меньше (ведь новый раздел готовится при ещё работающей базе, это уже на копирование остановка идёт) + оригинальный раздел не удаляется что всегда позволит быстро востановить систему в случае каких либо затруднений с новым.
ошибся конечно не 100-200 сек, больше , но и в таких серверах субд, как правило, рейды стоят на значит более быстрые скорости чем 100мбайт/сек
ВідповістиВидалитиА зачем удалять и потом добавлять устройства?! На vmware виртуалках у меня всегда срабатывает
ВідповістиВидалити# echo 1 > /sys/block/sda/device/rescan
ну и устройство так же не должно при этом использоваться.
А что делать если на SAN я использую том размером больше 2 ТБ ?
ВідповістиВидалитиfdisk тогда не поможет.
да и parted тоже
у меня случилась такая ситуация
только на SAN был один раздел который был выделен для LVM
в итоге после шаманств пришлось создать новый раздел на SAN и добавить его в lvm
как сделать по другому так и не придумал.
> оригинальный раздел не удаляется что всегда позволит быстро востановить систему в случае каких либо затруднений с новым.
ВідповістиВидалити1) место SAN storage очень дорогое и дефицитное. Это не дешевый NAS
2) для быстрого восстановления есть механизм снапшотов (снапклонов), работающий намного (на порядки) быстрее
> уж лучше и правда скопировать (при скорости 100мб/сек это 100-200 сек) потери
При условии, что база 10-20 Гб - соглашусь. Если база 300-400 гб (местами до 600-700) - могу поспорить. К тому же не забываем, что производительность стораджа зависит от его нагруженности. К примеру, мой сторадж в прайм-тайм находится на пике своих возможностей (из экономии забит винтами не полностью, там всего штук 30 в одном массиве и штук 50 в другом ). Нагружать сторадж в таких условиях - недопустимо. Я лучше потеряю лишних 5-10 минут.
> ошибся конечно не 100-200 сек, больше , но и в таких серверах субд, как правило, рейды стоят на значит более быстрые скорости чем 100мбайт/сек
Рейды-то быстрые. Но реальная производительность где-то такая же. Потому как к массиву обращается не один бокс, а десятка два.
> А зачем удалять и потом добавлять устройства?! На vmware виртуалках у меня всегда срабатывает
ВідповістиВидалити> # echo 1 > /sys/block/sda/device/rescan
Это в виртуалках - там все ok. А вот при работе с multipath (два и более FC адаптеров, множество путей к SAN) фокус не проходит. У меня по крайней мере не получилось
> А что делать если на SAN я использую том размером больше 2 ТБ ?
ВідповістиВидалитиВ parted заявлена поддержка таких разделов и должно все получиться. Но, ВАЖНО - ядро должно поддерживать EFI/GPT. В RedHat поддержка есть. Остальные дистрибутивы - увы, я не в курсе.
Спасибо!
ВідповістиВидалити