about NetApp

Вы уже знаете, что каждая система хранения 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