Перенос root volume

Вы уже знаете, что каждая система хранения NetApp, вернее даже каждый ее контроллер, обязательно имеет на подключенных к нему дисках специальный, обычно самый первый, том, так называемый root volume или vol0. На этом томе хранится содержимое настроек и установок внутренней OS Data ONTAP (для знакомых с миром UNIX OS скажу проще – /etc), а также много всего прочего, включая директорию документации и веб-интерфейса, прошивки дисков, конфиг-файлы репликации и прочее жизненно необходимое. Такая схема позволяет легко и просто менять контроллер системы хранения, ведь если все индивидуальные настройки системы находятся на дисковых полках, вместе с данными, а в контроллере только ядро, то подключенный на замену новый (даже другого типа) контроллер загрузится, обнаружит и подключит /etc с дисков, и загрузится в той конфигурации и с теми самыми настройками, которыми обладал старый контроллер.

Том root vol, обычно vol0, создается при начальной установке системы и очень часто уже никогда не меняется. Но что делать, если нам понадобилось изменить положение root vol, создать новый, на других дисках, например? Каким образом правильно перенести root vol на новый том?

Допустим, мы мигрируем с 7.x на 8.0.1, и хотим использовать 64-bit aggregate only. Так как в настоящий момент нет средства преобразовать 32-bit, 7.x-style aggregate в новый, 64-bit, нам придется создать на пустых дисках новый 64-bit aggregate, затем перенести в него root vol и другое содержимое старого aggregate, затем убить старый aggregate и добавить его диски в новый.

Или, например, наша старая система когда-то создала свой root vol на старых дисках FC 144GB, а теперь мы используем SAS 600GB, и хотим вывести старые полки из эксплуатации, перенеся их содержимое на новые, в том числе и root vol.

Но как вы догадываетесь, root vol это немного особенный том, недостаточно его просто скопировать, надо чтобы его опознало ядро Data ONTAP как “свое”.

Посмотрим на имеющуюся картину:

filer> vol status
Volume State Status Options
vol1 online raid_dp create_ucode=on
vol0 online raid4 root, create_ucode=on

Как вы видите, том vol0 имеет специальный атрибут – root.

Начнем с того, что на нужном aggregate создадим том, который будет в будущем нашим новым root vol.

> vol create <new_root_volname> <aggrname> <size>

Размер тома (size) следует выбрать согласно рекомендациям для используемого типа контроллера (он зависит от используемого в контроллере объема памяти, потому что на нем должно быть место для сброса core dump, “если что-то пошло не так” и дальнейшей диагностики проблем системы, кроме того определенный объем занимают файлы самой OS).

Рекомендованные значения размеров тома:
Для 7.3.х:
FAS2020 – 10GB, FAS2050 – 12GB, FAS2040, FAS3140 – 16GB, FAS3160 – 23GB, FAS3170, FAS6040 – 37GB, FAS6080 – 69GB.

Для 8.х.х:
FAS2040, 3040, 3140 – 160GB,  остальные – 250GB.

Напомню, что размер тома вы можете увеличить и после его создания, но не более, чем на 95% от объема его содержащего aggregate. Проверить доступную емкость aggregate можно командой df -A

Скопируем содержимое старого тома в новый том, например используя ndmpcopy.

Убедимся что ndmp daemon включен или включим его, если он выключен.

> ndmpd on

Скопируем содержимое тома в новый том. В отличие от копирования “через хост”, эта операция осуществляется внутренними средствами системы хранения и не нагружает канал передачи данных.

> ndmpcopy /etc /vol/new_root_vol/etc

Ndmpcopy: Starting copy [ 2 ] …
Ndmpcopy: filer: Notify: Connection established
Ndmpcopy: filer: Notify: Connection established
Ndmpcopy: filer: Connect: Authentication successful
Ndmpcopy: filer: Connect: Authentication successful
Ndmpcopy: filer: Log: DUMP: creating "/vol/vol0/../snapshot_for_backup.4" snapshot.
Ndmpcopy: filer: Log: DUMP: Using subtree dump
Ndmpcopy: filer: Log: DUMP: Date of this level 0 dump: Mon Mar 7 10:18:18 2005.
Ndmpcopy: filer: Log: DUMP: Date of last level 0 dump: the epoch.
Ndmpcopy: filer: Log: DUMP: Dumping /etc to NDMP connection
Ndmpcopy: filer: Log: DUMP: mapping (Pass I)[regular files]
Ndmpcopy: filer: Log: DUMP: mapping (Pass II)[directories]
Ndmpcopy: filer: Log: DUMP: estimated 365193 KB.
Ndmpcopy: filer: Log: DUMP: dumping (Pass III) [directories]
Ndmpcopy: filer: Log: RESTORE: Mon Mar 7 10:18:25 2005: Begin level 0 restore
Ndmpcopy: filer: Log: RESTORE: Mon Mar 7 10:18:25 2005: Reading directories from the backup
Ndmpcopy: filer: Log: DUMP: dumping (Pass IV) [regular files]
Ndmpcopy: filer: Log: RESTORE: Mon Mar 7 10:18:28 2005: Creating files and directories.
Ndmpcopy: filer: Log: RESTORE: Mon Mar 7 10:18:32 2005: Writing data to files.
Ndmpcopy: filer: Log: DUMP: dumping (Pass V) [ACLs]
Ndmpcopy: filer: Log: RESTORE: Mon Mar 7 10:19:06 2005: Restoring NT ACLs.
Ndmpcopy: filer: Log: RESTORE: RESTORE IS DONE
Ndmpcopy: filer: Notify: restore successful
Ndmpcopy: filer: Log: DUMP: 365298 KB
Ndmpcopy: filer: Log: DUMP: DUMP IS DONE
Ndmpcopy: filer: Log: DUMP: Deleting "/vol/vol0/../snapshot_for_backup.4" snapshot.
Ndmpcopy: filer: Notify: dump successful
Ndmpcopy: Transfer successful [ 49 seconds ]
Ndmpcopy: Done

Укажем для OS, что созданный том и есть наш новый root vol

> vol options new_root_vol root

Mon Mar 7 10:21:24 PST [filer: fmmbx_instanceWorke:info]: Disk 8a.37 removed from primary mailbox set
Mon Mar 7 10:21:24 PST [filer: fmmbx_instanceWorke:info]: Disk 8a.36 removed from primary mailbox set
Mon Mar 7 10:21:24 PST [filer: fmmbx_instanceWorke:info]: Disk 8a.35 is a primary mailbox disk
volume new_vol_root will become root volume at the next boot.

При необходимости переименуем новый том понятным именем

> vol rename new_root_vol rootvol

Если вы использовали NAS-шары на старом томe (например для доступа к содержимому /etc и корня root vol, автоматически при инсталляции создаются шары etc$ и c$), они будут автоматически переставлены на новые места. Проверьте это, и, при необходимости, поправьте.

> cifs shares

> exportfs

Проверьте новые настройки томов

filer> vol status
Volume State Status Options
vol1 online raid_dp create_ucode=on
vol0 online raid4 create_ucode=on
rootvol online raid4 root, raidsize=4, create_ucode=on

Как вы видите, созданный вами том rootvol теперь является root.

Перезагрузитесь (в кластерной системе вместо перезагрузки можно сделать кластерный takeover/giveback), и убедитесь, что все хорошо.

> reboot

Готово, вы перенесли root volume на новое место.

UPD: Как правильно заметили в комментариях, я забыл еще одну операцию. Дело в том, что после переноса root vol перестает работать доступ по https в FilerView и System Manager. Поэтому необходимо перегенерировать SSL-сертификаты из командной строки:


filer> options ssl.enable off
filer> secureadmin setup ssl
filer> options ssl.enable on

15 комментариев

  1. Киселев Сергей:

    Буквально вчера у Заказчика вточь-вточь делал такую процедуру, почему то после этого отвалился https доступ :( http работает …
    До этого всё работало.
    По поводу размера root для 64-bit агрегата: для 3210 - 151GB, для 3240 - 205GB. Это есть в TR3838.

  2. Альберт Салман:

    Перед данной операцией настояльно рекомендуется выключить всякие идущие процессы: snapvault, snapmirror и т.д. что меняет содержимое root volume.
    Конкретно я столкнулся что если не выключить snapvault пока будет идти перенос данных на новый root том содержимое реестра snapvault может измениться (по завершении трансферов скажем) и в итоге после перезагрузки с нового тома эти relationship буду неработоспособны, хорошо что заранее поинтересовался на NOW и погонял тесты. Ксатати жуткий минус статей что они однобокие, вот эта же операция переноса по разному описывается в разных статьях и в них друг на друга ссылок вообще не было.
    Кстати выключение идущих трансферов тоже может забавно отразиться и приходится всякими обходными путями оживлять relationship, например пришлось вручную запускать апдейт соседнего чтобы другой на тот же том вылечился после очисти\обновления softlock.

  3. Альберт Салман:

    HTTPS доступ бывает отваливается, есть статья на NOW как лечить, поищите.

  4. Киселев Сергей:

    Спасибо Альберт … уже искал - как вариант решения, это перегенерировать SSL ключ, будем пробывать.

  5. BSD dump/restore, какая всё ж таки прелесть…

  6. Дмитрий:

    Надо еще httpd.rootdir поменять

  7. Дмитрий:

    Зачем? Это весьма опциональное действие, и то, только если вы зачем-то используете протокол HTTP с корнем на root-vol, что вообще довольно сомнительная затея.

  8. Алексей:

    Спасибо за статью. У меня вопрос: имеется 200GB root volume, с 1% занятого пространства. Могу ли я использовать свободное место для хранения данных? Чревато ли это какими-либо неприятными последствиями?

  9. Алексей:

    Да, конечно сможете. Это не является “наилучшей практикой”, но повсеместно пространство на root volume используется для хранения каких-нибудь, обычно второстепенных и некритичных для работы компании данных.
    Главное оставить там достаточно места, в размере не менее рекомендованного, указанного выше. Иногда дополнительное место (сверх занятого в настоящий момент, но менее приведенных выше цифр рекомендаций, указанные там размеры посчитаны уже с учетом этого требования) может понадобиться, например, для сброса core dump, или подобных же задач.

  10. Алексей:

    Спасибо за быстрый ответ, romx!
    Я планирую хранить важные данные: лун, который я подцеплю к ESX для продакшн контента.

    Помимо этого мой root volume хранится на root agregate вместе с остальными volume. Имеет ли смысл в данной ситуации создавать отдельный root volume размером в ~10GB?
    К сожалению, исходя из официального мануала, не могу понять реальные риски такого распределения ресурсов.

  11. Алексей:

    По большому счету специально использовать пространство root volume имеет смысл только в случае, если пространство там образовано за счет того, что вы создали для root volume отдельный aggregate. В этом случае у вас получается размер неиспользуемого пространства равный емкости этого выделенного aggregate, на котором расположен root volume.

    Но при сравнительно небольшом количестве дисков бывает выгоднее не выделять под root vol отдельный aggregate, а создать его на общем aggregate, вместе с томами данных. В этом случае вам совершенно все равно сколько там на нем места. Уменьшите его до рекомендованных выше величин, а все остальное пространство aggregate можете задействовать под volume с данными и LUN.
    Теоретически можно даже сделать этот том без space reservation и с volume autogrow, и тогда он будет занимать только реально занятое в нем данными место. Но это, как я знаю, все же не рекомендуется.

  12. bbk:

    2 Альберт Салман
    >Перед данной операцией настояльно рекомендуется выключить всякие идущие процессы: snapvault, snapmirror и т.д. что меняет содержимое root volume.

    Здесь речь идёт о хранении информации на root разделе (что и так не является бестпрактисом) или всё-же желательно их останавливать на всём контроллере (независимо от того, что snapvault/snapmirror процессы юзают “не рут” разделы)?

  13. bbk:

    После переноса раздела почему-то SystemManager не хочет конектиться к контроллеру. Сертификаты перегенирировал, по SSH пускает. Кто подскажет в чём загвоздка?

  14. bbk:
    Лучше такие вопросы задавать в известном форуме на community.netapp.com, по крайней мере там ваши сообщения прочтет не только лишь я один :)

  15. bbk:

    Мне помогло:
    secureadmin disable ssl
    secureadmin setup -f ssl
    secureadmin enable ssl

Оставить комментарий

20/0.146

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.