пʼятниця, 18 червня 2010 р.

SAN storage - изменение размера диска (RHEL5)



Достаточно частая задача - увеличить размер диска, выделенного на SAN
Как правило ко мне с такой задачкой регулярно обращаются 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). Следовательно, если начало раздела попадает в ту же точку, где раздел начинался, потери данных не будет.

8 коментарів:

  1. >Однако, для больших дисков (а для баз данных 100-200 гигабайт это вполне заурядный размер) это занимает массу времени.
    то что вы предложили - одни команды, записи + fsck займут сравнимо времени. уж лучше и правда скопировать (при скорости 100мб/сек это 100-200 сек) потери времени практически идентичны если не меньше (ведь новый раздел готовится при ещё работающей базе, это уже на копирование остановка идёт) + оригинальный раздел не удаляется что всегда позволит быстро востановить систему в случае каких либо затруднений с новым.

    ВідповістиВидалити
  2. ошибся конечно не 100-200 сек, больше , но и в таких серверах субд, как правило, рейды стоят на значит более быстрые скорости чем 100мбайт/сек

    ВідповістиВидалити
  3. А зачем удалять и потом добавлять устройства?! На vmware виртуалках у меня всегда срабатывает
    # echo 1 > /sys/block/sda/device/rescan

    ну и устройство так же не должно при этом использоваться.

    ВідповістиВидалити
  4. А что делать если на SAN я использую том размером больше 2 ТБ ?
    fdisk тогда не поможет.
    да и parted тоже
    у меня случилась такая ситуация
    только на SAN был один раздел который был выделен для LVM
    в итоге после шаманств пришлось создать новый раздел на SAN и добавить его в lvm
    как сделать по другому так и не придумал.

    ВідповістиВидалити
  5. > оригинальный раздел не удаляется что всегда позволит быстро востановить систему в случае каких либо затруднений с новым.

    1) место SAN storage очень дорогое и дефицитное. Это не дешевый NAS
    2) для быстрого восстановления есть механизм снапшотов (снапклонов), работающий намного (на порядки) быстрее

    > уж лучше и правда скопировать (при скорости 100мб/сек это 100-200 сек) потери

    При условии, что база 10-20 Гб - соглашусь. Если база 300-400 гб (местами до 600-700) - могу поспорить. К тому же не забываем, что производительность стораджа зависит от его нагруженности. К примеру, мой сторадж в прайм-тайм находится на пике своих возможностей (из экономии забит винтами не полностью, там всего штук 30 в одном массиве и штук 50 в другом ). Нагружать сторадж в таких условиях - недопустимо. Я лучше потеряю лишних 5-10 минут.

    > ошибся конечно не 100-200 сек, больше , но и в таких серверах субд, как правило, рейды стоят на значит более быстрые скорости чем 100мбайт/сек
    Рейды-то быстрые. Но реальная производительность где-то такая же. Потому как к массиву обращается не один бокс, а десятка два.

    ВідповістиВидалити
  6. > А зачем удалять и потом добавлять устройства?! На vmware виртуалках у меня всегда срабатывает
    > # echo 1 > /sys/block/sda/device/rescan

    Это в виртуалках - там все ok. А вот при работе с multipath (два и более FC адаптеров, множество путей к SAN) фокус не проходит. У меня по крайней мере не получилось

    ВідповістиВидалити
  7. > А что делать если на SAN я использую том размером больше 2 ТБ ?

    В parted заявлена поддержка таких разделов и должно все получиться. Но, ВАЖНО - ядро должно поддерживать EFI/GPT. В RedHat поддержка есть. Остальные дистрибутивы - увы, я не в курсе.

    ВідповістиВидалити