Глава 5. Восстановление и реконструкция
Содержание
Диски заполняются. Это именно то,для чего они предназначены. Аппаратные средства отказывают по той же причине. Иногда вам нужно вынуть диски из одной машины и поместить их в другую, или заместить отказавшие жесткие диски, или предоставить вашей базе данных больше пространства. Данная глава обсуждает то, как вы можете изменять, обновлять и восстанавливать ваши пулы хранения.
Прежде чем перейти к этому, давайте обсудим как ZFS перестраивает разрушенные VDEV.
Виртуальные устройства, такие как зеркала и RAID-Z специально созданы для повторного построения утраченных данных на разрушенных дисках. Если диск в вашей паре зеркал умер, вы заменяете диск и ZFS скопирует выжившее зеркало на него. Если в вашем RAID-Z отказал VDEV, вы заменяете вышедший из строя диск и ZFS перестраивает этот диск из данных контрольных сумм. Такой вид восстановления данных является ключевой функциональностью любой реализации RAID.
Однако, ZFS понимает как файловую систему, так и лежащие в основе хранилища. Это предоставляет ZFS свободу и преимущества над обычными недостатками управления RAID.
Повторное построение диска, зеркалированного программным или аппаратным RAID требует копирования всех секторов по отдельности с хорошего диска на диск замены. Устройство RAID дожно скопировать таблицу разделов, файловую систему, все индексные дескрипторы, все ваши блоки (даже все свободное пространство) и все данные с одного на другое устройство.
Мы все сделали опечатку в /etc/rc.conf, которая не позволяет системе загружаться. Исправление
этой опечатки в системе, зеркалированной посредством UFS2 и gmirror(8) потребует загрузки в
однопользовательском режиме, исправления опечатки и перезагрузки. Это выведет один из дисков из процесса синхронизации с другим.
При перезагрузка FreeBSD заметит неточность и перенесет резервный диск на синхронизируемый копированием всех секторов по отдельности
текущего диска на резервную копию. Вероятно,вы изменили один или два сектора на этом диске, однако
gmirror(8) должна скопировать все целиком. Это может занять часы, или даже дни.
ZFS знает в точности какой объем диска используется. Когда ZFS пересобирает замененного поставщика хранения, она копирует только данные, которые действительно нужны этому поставщику. Если вы замените диск ZFS, который был заполнен данными только на треть, ZFS скопирует только эту треть данных для восстановления диска.
Исправление опечатки в rc.conf в зеркалированном ZFS диске потребует вмешательства системного
администратора,очень похожее на необходимое вмешательство в системе gmirror(8). Вы войдете в
однопользовательский режим. Вы исправите опечатку. Вы перезагрузитесь. Разница заключается в том, что ZFS в точности знает какие
блоки были изменены на диске. Если только один диск был в работе в процессе однопользовательского режима (невероятно, но такое может
случаться), оба диска будут рассогласованы. Вместо того, чтобы копировать диск целиком, ZFS обновит только те блоки, которые
необходимы для повторной синхронизации дисков. Скорее всего, система восстановит зеркало еще до того, как вы введете команду для
просмотра как она поживает.
Восстановление ZFS называется переносом актуальных данных (resilvering). Как и другие операции целостности, перенос актуальных данных имеет место только на актуальной файловой системе. Вы можете выполнить перенос актуальных данных в однопользовательском режиме, но это имеет тот же смысл как и установка программного обеспечения в однопользовательском режиме.
Перенос актуальных данных автоматически происходит при замене вами поставщика хранения. Оно также случается, когда диск временно отказывает и затем восстанавливается, например, при перезапуске контроллера или перезагрузке внешнего диска. В то время как процесс переноса актуальных данных замененного поставщика хранения может занять продолжительное время, перенос актуальных данных после короткого простоя, скорее всего, потребует всего нескольких секунд.
Если вы используете пул RAID-Z обычным образом во время выполнения переноса актуальных, перенос актуальных может значительно замедлиться. Перенос актуальных данных и очистка выполняются в порядке групп транзакций, в то время как нормальные операции чтения и записи довольно- таки случайные. Скорость переноса актуальных данных ZFS дросселируется с тем, чтобы она не влияла на нормальную функциональность системы.
Данные расширяются, занимая все свободное пространство. Вне зависимости от того, сколько дискового пространства вы выделите пулу, в конце концов, вы захотите больше. Чтобы увеличить размер пула добавьте VDEV в этот пул. Для пулов с избыточностью вы можете заменить поставщиков хранения на поставщиков с большим размером.
Когда вы расширите пул ZFS автоматически начнет записывать данные в новое пространство. По мере роста пула ZFS пытается равномерно балансировать доступное пространство между различными поставщиками. ZFS смещает запись по дискам, поэтому они могут заполниться одновременно. У пула с одним пустым VDEV и тремя почти заполненными, однако, мало выбора кроме как помещать данные на пустое VDEV. Если вы часто создаете и удаляете файлы, загруженность дисков, в конце концов, выровняется.
Все VDEV внутри пула должны быть идентичными. Если пул построен из набора зеркал, не добавляете в него RAID-Z3.
Добавляете поставщиков в VDEV при помощи команды zpool attach, а VDEV в пул
командой zpool add.
Вы не можете удалять устройства из VDEV без {избыточности} или любые VDEV из пула. Флаг -n
в zpool add производит "холостое выполнение", показывая вам результаты работы команды,
которые она бы получила, без реального изменения пула. Выполнение вашей команды zpool add
с флагом -n и изучение получающегося пула может дать вам предостережения о ваших выстрелах
себе в ногу.
Чередующиеся пулы, не имеющие никакой избыточности, могут расширяться вплоть до пределов аппаратных средств. Каждое добавляемое вами VDEV без избыточности, однако, увеличивает вероятность катастрофического отказа,в точности с тем,какэто происходит в RAID-0. Помните, что отказ одного VDEV в пуле разрушит весь пул. В пуле с чередованием каждый диск является автономным VDEV.
Вот пул с чередованием с тремя поставщиками.
# zpool status scratch ... config: NAME STATE READ WRITE CKSUM scratch ONLINE 0 0 0 gpt/zfs0 ONLINE 0 0 0 gpt/zfs1 ONLINE 0 0 0 gpt/zfs2 ONLINE 0 0 0
Воспользуйтесь командой zpool add для добавления поставщика хранения в пул с
чередованием./p>
# zpool add scratch gpt/zfs3
Теперь состояние пул покажет четырех поставщиков услуг, а вы имеете дополнительное дисковое пространство.
Вы можете добавить поставщика в зеркалированное VDEV, однако дополнительные диски не увеличат доступное пространство. Они станут дополнительными зеркалами друг друга. Чтобы добавить пространство в пул, которое использует VDEV с зеркалами, добавьте новое зеркалированное VDEV в ваш пул.
Сейчас zpool db имеет два зеркалированных VDEV.
# zpool status db ... NAME STATE READ WRITE CKSUM db ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/zfs0 ONLINE 0 0 0 gpt/zfs1 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 gpt/zfs2 ONLINE 0 0 0 gpt/zfs3 ONLINE 0 0 0
Нам нужно дополнительное пространство, поэтому мы хотим добавить третье зеркалированное VDEV. Воспользуйтесь командой
zpool add для создания нового зеркального устройства и добавьте его в пул. Здесь мы используем
gpt/zfs4 и gpt/zfs5 для создания нового устройства и
добавления его в пул.
# zpool add db mirror gpt/zfs4 gpt/zfs5
Теперь состояние пула отобразит новое зеркалированное VDEV, mirror-2, содержащее двух поставщиков хранения. По мере записи и удаления
вами данных, пул постепенно выровняет загруженность по трем VDEV. Чтобы посмотреть как пул распределяет данные по всем VDEV используйте
zpool list -v.
Вы не можете добавлять поставщиков ни к какому RAID-Z VDEV. Чтобы расширить пул на основе RAID-Z, вы должны добавить дополнительное VDEV в этот пул или заменить все участвующие в пуле диски дисками большего размера. Лучшей практикой является исполнение всех RAID-Z VDEV с применением одинакового числа дисков.
Вот пул RAID-Z, который мы хотим расширить дополнительным VDEV.
config NAME STATE READ WRITE CKSUM db ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 gpt/zfs0 ONLINE 0 0 0 gpt/zfs1 ONLINE 0 0 0 gpt/zfs2 ONLINE 0 0 0
Мы опять используем команду zpool add для создания нового VDEV и добавления его в пул.
# zpool add db raidz1 gpt/zfs3 gpt/zfs4 gpt/zfs5
Проверка состояния пула показывает, что новое VDEV, raidz1-1, содержит трех поставщиков. ZFS немедленно запускает чередование данных и по новым поставщикам.
Ели вы хотите добавить новое VDEV в пул на основе RAID-Z2 или RAID-Z3, используйте ту же команду с нужным вам типом RAID-Z и соответствующим числом поставщиков.
Помните, вы не можете добавлять поставщиков в RAID-Z VDEV - настройка RAID-Z VDEV зацементирована. Многие люди пытаются добавлять
диски в RAID-Z VDEV при помощи zpool add. Команда zpool add
добавляет новые VDEV в пул. Если вы примените -f для запроса на помещение в ваш пул на основе
RAID-Z одного нового диска командой zpool add, вы получите деформированный пул с одним
участником RAID-Z и одним участником чередования. Получившийся в результате пул не будет монтироваться и будет неисправим. Его
восстановление потребует резервного копирования данных с последующим уничтожением и повторным созданием пула.
Вы можете применять zpool attach для расширения зеркалированных и чередующихся VDEV,
однако эта команда не работает с пулами RAID-Z. Вы не можете добавлять поставщиков в RAID-Z VDEV.
Большинство настроек ZFS допускают определенное число отказов аппаратных средств. Когда лежащие в основе поставщики хранения выходят из строя, ZFS делает все возможное чтобы предупредить вас. Прислушивайтесь к ней.
Команда zpool status отображает условия аппаратура хранения в поле STATE. Вы получаете одно
поле STATE для всего вашего пула, рядом с вершиной. Далее вниз, где zpool status приводит список
всех VDEV и поставщиков хранения колонка STATE позволяет вам сузить поиск виновника.
Ошибки просачиваются вверх. Если отказывает отдельный поставщик хранения, пул вырабатывает соответствующий отказ. Большое кричащее
сообщение об ошибке в вершине zpool status является ориентиром для вас просмотреть конкретных
поставщиков для выявления лежащей в основе ошибки.
Пулы и VDEV могут иметь шесть состояний. Лежащие в основе поставщики могут иметь по крайней мере три из этих состояний.
Если пул, VDEV или поставщик в интерактивном режиме (Online), то они работают нормально.
Деградировавший (Degraded) пул утратил, по крайней мере, одного поставщика хранения. Этот поставщик либо полностью выключен, либо утрачен, либо вырабатывает ошибки намного чаще, чем это допускает ZFS. Деградировавший пул сохраняет достаточную устойчивость для продолжения работы, однако еще один отказ может закрыть его.
Если поставщик хранения имеет слишком много ошибок ввода/ вывода, ZFS предпочитает полностью выключить (перевести в состояние отказа) это устройство. Однако, в действительности ZFS пытается избегать перевода в аварийное состояние устройств, которые обеспечивают необходимую уустойчивость пула. Если последний рабочий поставщик в зеркале начинает показывать слишком много ошибок или отказывает поставщик в уже имеющем аварийного поставщика хранения RAID-Z1 VDEV, тогда ZFS помещает этого поставщика в деградировавший режим, хотя он должен был бы поместить его в аварийное состояние.
Отказавший (Faulted) поставщик хранения либо разрушен, либо вырабатывает слишком много ошибок по сравнению с допустимым ZFS значением. Отказавший поставщик хранения берется из самой последней известной хорошей копии ваших данных. Если ваше зеркало с двумя дисками утратило оба диска, или ваш RAID-Z1 потерял оба диска, ваше VDEV отказывает. Отказавшее VDEV забирает ссобой весь пул.
Недоступный (Unavail) означает, что ZFS не может открыть поставщика хранения. Возможно устройство больше не подключено, или вероятно оно было плохо импортировано (см. {Импорт} пулов далее в этой главе). В любом случае, его здесь нет, поэтому ZFS не может его использовать. Недоступное устройство может затронуть все VDEV и, следовательно, весь пул.
Недоступное устройство воздействует на состояние VDEV в зависимости от устойчивости этого VDEV. Если пул все еще имеет достаточно устойчивости для продолжения работы, пул становится деградировавшим. Если VDEV не может больше работать, оно становится отказавшим.
Недоступные устройства появляются в состоянии пула по назначенному им GUID, а не в узле устройства поставщика.
Не подключенное (Offline) устройство было намеренно выключено системным администратором. У вас нет целевых причин для выключения устройства в большом массиве.
Некоторые аппаратные средства могут обнаруживать физическое удаление диска из системы при работающей системе. Такое оборудование позволяет ZFS устанавливать состояние удаленный (Removed) при вытаскивании устройства. Когда вы повторно подключаете устройство, ZFS пытается ввести поставщика обратно в интерактивный режим.
Рассмотрим сервер с парой отключенных поставщиков хранилищ. Это не относится к системе Лукаса или Джуда, это было в системе друга Лукаса. (А теперь Лукас имеет хороший пример проблемы, он может сказать, что друг с этим zpool был ранен. Хотя, чтобы быть уверенным, что он имеет хорошие примеры, он, наверное, должен подождать пока он не закончит эту книгу. Хоть они друг Лукаса, но молокосос.) Обратите внимание на ошибки ваших поставщиков, тип VDEV, и состояние пула в целом.
# zpool status
pool: FreeNAS02
state: DEGRADED
status: One or more devices could not be opened. Sufficient replicas exist for
the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
see: http://illumos.org/msg/ZFS-8000-2Q
scan: scrub repaired 0 in 15h57m with 0 errors on Sun Feb 8 15:57:55 2015
config:
NAME STATE READ WRITE CKSUM
FreeNAS02 DEGRADED 0 0 0
raidz2-0 DEGRADED 0 0 0
15881942844… UNAVAIL 0 0 0 was /dev/gpt/zfs0
gpt/zfs1 ONLINE 0 0 0
gpt/zfs2 ONLINE 0 0 0
gpt/zfs3 ONLINE 0 0 0
gpt/zfs4 ONLINE 0 0 0
gpt/zfs5 ONLINE 0 0 0
gpt/zfs6 ONLINE 0 0 0
gpt/zfs7 ONLINE 0 0 0
gpt/zfs8 ONLINE 0 0 0
gpt/zfs9 ONLINE 0 0 0
14768135092… UNAVAIL 0 0 0 was /dev/gpt/zfs10
gpt/zfs11 ONLINE 0 0 0
gpt/zfs12 ONLINE 0 0 0
gpt/zfs13 ONLINE 0 0 0
Этот RAID-Z2 пул находится в состоянии деградации. Он утратил двух поставщиков, /dev/gpt/zfs0
и /dev/gpt/zfs10. RAID-Z2 VDEV может обрабатывать до двух отказов дисков и продолжать свою работу
несмотря на утрату дисков.
Однако, деградировавший пул имеет ограничения по самовосстановлению. Пул без избыточности не имеет информации, необходимой ZFS для
восстановления файлов. Наш пример приведенного выше пула имеет утраченными два диска в своем RAID-Z2 VDEV. Он имеет нулевую избыточность.
Если файл испытывает битовую деградацию, ZFS может ее исправить. Когда вы пытаетесь получить доступ к этому файлу, ZFS возвращает ошибку.
Избыточность на уровне набора данных (со свойством copies)
может позволить ZFS вылечить файл.
Если пул испытает отказ другого диска, тогда пул не сможет завершить копию своих данных и откажет.
Раз уж ZFS столь любезен, что предупреждает о своих проблемах, то меньшее из того что вы можете сделать, это попытаться исправить их. Процесс восстановления зависит от того, является ди диск утраченным или отказавшим.
Привод, отключенный в процессе работы отображается либо как удаленный, либо как отказавший. МОжет быть, вы вынули диск чтобы посмотреть его серийный номер. Возможно, отсоединился кабель. Это могли быть гремлины. В любом случае, вы скорее всего захотите подключить его назад.
Если аппаратура замечает, что диск удален, вместо того чтобы просто сообщить, что он пропал, оборудование также заметит и возвращение диска. ZFS попытается повторно активировать восстановленный диск.
Аппаратура, которая не оповещает операционную систему о добавлении или удалении требует вмешательства системного администратора для
восстановления службы. Воспользуйтесь командой zfs online для повторного подключения привода назад
в службу.
# zfs online gpt/zfs5
Если диск не доступен по причине его отказа, тогда вы должны заменить его, а не просто снова включить его.
Самая трудная часть замены диска часто не имеет ничего общего с ZFS: вы должны найти плохой диск. Мы рекомендуем применять физическое
местоположение диска в GPT метке диска при первичной установке диска для более простой замены впоследствии. Если вам необходимо
определить неисправный диск без подобной информации, используйте gpart list и
smartctl для получения серийного номера диска и информации о производителе, а затем
найдите шасси этого диска. Это тот же самый процесс, который обсуждался в Главе 0.,
только в обратном направлении и с дополнительным давлением незапланированных простоев. В худшем случае, вы можете найти серийный номер
всех еще работающих дисков, а методом исключения вы получите отсутствующий диск.
Теперь вы не жалеете, что не сделали эту работу заранее?
Когда вы определите отказавший диск и выполните его замены, мы можем начать использовать ZFS.
Используйте команду zpool replace для удаления привода из демпфирующего VDEV и замените в нем диск
на новый. Диск не обязательно должен быть отказавшим - это может быть совершенно рабочий диск, который вы хотите заменить, поскольку, например,
вы выполняете обслуживание дисковой полки. Вот пул RAID-Z1 с плохим диском.
NAME STATE READ WRITE CKSUM db DEGRADED 0 0 0 raidz1-0 DEGRADED 0 0 0 gpt/zfs1 ONLINE 0 0 0 gpt/zfs2 ONLINE 0 0 0 gpt/zfs3 FAULTED 0 0 0 gpt/zfs4 ONLINE 0 0 0
Журнал /var/log/messages содержит много предостережений о физическом диске, лежащем в основе
gpt/zfs3. Это диск должен быть удален из нашего несчастья. Используйте
zpool replace для удаления отказавшего поставщика из VDEV и замены его новым устройством. Задайте
имя пула, отказавшего поставщика и нового поставщика.
# zpool replace db gpt/zfs3 gpt/zfs5
Эта команда может отнять много времени в зависимости от емкости диска и его скорости, а также от объема данных на нем. Вы можете наблюдать за состояние замены проверяя состояние пула.
# zpool status db pool: db state: DEGRADED status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scan: resilver in progress since Mon Mar 16 12:04:50 2015 195M scanned out of 254M at 19.5M/s, 0h0m to go 47.3M resilvered, 76.56% done config: NAME STATE READ WRITE CKSUM db ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 gpt/zfs1 ONLINE 0 0 0 gpt/zfs2 ONLINE 0 0 0 replacing-2 ONLINE 0 0 0 gpt/zfs3 FAULTED 0 0 0 gpt/zfs5 ONLINE 0 0 0 (resilvering) gpt/zfs4 ONLINE 0 0 0
Оценки времени переноса актуальных данных (resilvering) предполагает что активность диска довольно постоянна. Старт большого дампа базы данных в середине процесса переноса актуальных данных задерживает все.
Допустим, ваш массив жестких дисков заполнился и у вас больше нет места для размещения новых жестких дисков с новым узлом устройства. Вы должны физически удалить отказавший диск, выполнить замену в его местоположении, сделать раздел и создать метку диска, а также заменить поставщика. Это лишь чуть более сложно.
Однако, этот подход имеет больше рисков. При zpool replace отказавший поставщик остается
в работающем состоянии, поскольку он может управлять до завершения переноса актуальных данных. Если вы утратите второй диск в вашем
RAID-Z1 в процессе переноса актуальных данных, есть шансчто пулу хватит целостности данных для выживания. Когда вы заменяете
отказавшего поставщика до начала перепостроения, вы теряете такоую возможность безопасности. Если ваше оборудование не предоставляет
вам достаточной для безопасной замены гибкости, ну что же, проверьте свои резервные копии и вперед.
Начните с вывода отказавшего устройство в офлайн. Данная команда попросит ZFS остановить попытки чтения и записи на данное устройство.
# zpool offline gpt/zfs3
Теперь вы можете извлечь отказавший диск из массива и установить его замену. В случае необходимости, создайте раздел
поставщика. Ели вы не уверены в разбиении, вы можете скопировать таблицу разделов существующих дисков чем-то навроде
gpart backup da0 | gpart restore da9. Используйте новую метку поставщика в
zpool replace. Если метка нового поставщика идентична метке удаленного диска, у вас нет
нужды повторять имя поставщика. В нашем случае мы заменяем gpt/zfs3 новым диском, также
имеющим метку gpt/zfs3.
# zpool replace db gpt/zfs3
Если вы помечаете ваши диски серийными номерами, как мы рекомендовали в Главе 0., у вас не будет этой проблемы.
Если состояние диска UNAVAIL, ZFS идентифицирует утраченное устройство по его GUID и откладывает предыдущее имя устроства в сторону. Zpool все еще может работать, на вам действительно необходимо заменить диск.
NAME STATE READ WRITE CKSUM db DEGRADED 0 0 0 RAID-Z1-0 DEGRADED 0 0 0 gpt/zfs1 ONLINE 0 0 0 gpt/zfs2 ONLINE 0 0 0 13792229702739533691 UNAVAIL 0 0 0 was /dev/gpt/zfs3 gpt/zfs4 ONLINE 0 0 0
Я установил новый диск, который отображается в /var/run/dmesg.boot как da5
и создал на нем раздел freebsd-zfs. Этот новый поставщик получил метку zfs3. Пул не может автоматически идентифицировать данного
поставщика как его заместителя - он знает, что предыдущим поставщиком был gpt/zfs3,
однако новому gpt/zfs3 не хватает метаданных на диске, которые идентифицируют его в
качестве тома ZFS.
Чтобы плавно влить нового поставщика в zpool, снова примените zpool replace. Используйте
GUID вместо предыдущего имени устройства.
# zpool replace db 13792229702739533691 gpt/zfs3
Проверка состояния zpool покажет, что пул перенес актуальные данные. Когда перенос актуальных данных (resilvering) завершен, пул полностью восстановлен.
Иногда бывает, что диск не отказал полностью, но вырабатывает так много ошибок, что совершенно ясно, что его смерть близка.
Когда этот диск находится в зеркалированном виртуальном устройстве, лучше может оказаться оставить отказавшего поставщика на
месте, пока вы добавляете диск на замену. Это максимизирует избыточность в процессе замены. Также требуется, чтобы ваши аппаратные
средства могли использовать три диска вместо обычных двух. Если ваша система может обрабатывать только два диска, тогда продолжайте
работать с zpool replace
В нашем случае мы имеем отдельное зеркалированное VDEV содержащее двух поставщиков, gpt/zfs0
и gpt/zfs1. Мы должны заместить умерший gpt/zfs0 на
gpt/zfs2. Вместо того, чтобы напрямую перейти к zpool replace,
начнем с присоединения диска замены к пулу. Команда zpool attach попросит данный пул
добавить другой уровень зеркалирования в данный пул. Задайте имя пула, устройство, которое необходимо зеркалировать и новое
устройство.
# zpool detach db gpt/zfs0
Теперь мы подключили поставщика к нашему пулу db. Одним из существующих поставщиков
является gpt/zfs1, а мы подключили gpt/zfs2.
Просмотрим zpool status db, и мы увидим, что пул переносит актуальные данные для синхронизации
нового поставщика с другими дисками в зеркале. Когда новый поставщик синхронизируется с нашим пулом, удалите отказавшего поставщика
из виртуального устройства.
# zpool replace db 13792229702739533691 gpt/zfs3
Отказавший диск под gpt/zfs0 больше не используется.
Также выможете воспользоваться данным методом для трансформации пула с одним диском в зеркалированное виртуальное устройство.
Диск в состоянии UNAVAIL может не быть отказавшим окончательно. Он может оказаться отключенным. Если вы подойдете к серверу и увидите,
что пошевеливание корзины диска заставляет помигивать лампочки, вы можете попросить zpool повторно активировать этот диск
{Прим. пер.: конечно, перед этим желательно убедиться в надежности контактов и соединений}.
Вы также можете повторно активировать диск с состоянием REMOVED. В любом случае воспользуйтесь командой
zpool online, именем пула, а также GUID утраченного поставщика.
# zpool online db 718035988381613979
ZFS перенесет актуальные данные (resilver) повторно активированного диска и возобновит нормальную работу.
Мы предложили использовать SSD с большим циклом перезаписей для ваших ZFS журналов преднамеренного протоколирования (кэша записи, Intent Log) и L2ARC (кэша чтения). Очень часто все обнаруживают, что высокая стойкость ("high endurance") совсемне то же самое, что и достаточно высокая стойкость ("high enough endurance") и вам может понадобиться замена этого устройства. {Прим. пер.: подливает масла в огонь и разница в стоимости между т.н. устройствами SSD с большим циклом перезаписи (eMLC) и "стандартными" (MLC) SSD, достигающая порядков. В настоящее время мы проводим последовательность тестирований, которая, как мы надеемся, даст нам более глубокое понимание необходимости (или отсутствия таковой) дополнительных затрат на eMLC- обращайтесь за дополнительной информацией!. Однако, достаточно очевидно, что при наличии четкой процедуры замены дисков кэширования, да еще и при наличии четкой тенденции снижения стоимости SSD, данная статья расходов однаиз первых в рассмотрении на сокращение!} Устройства протоколирования используют те же ключевые слова состояний, что и обычные поставщики хранения - faulted, offline и тому подобные. Вам также может понадобиться вставка устройства журнала или, что менее применимо, удаление устройства журнала.
Хотя приводимые примеры отображают устройства журналирования, устройства кэширования работают в точности так же.
Чтобы добавить устройство журнала или кэша в существующий пул, воспользуйтесь zpool add,
именем пула а также типом устройства и поставщиками. Вот пример добавления устройства журнала gpt/zlog0
в пул db.
# zpool add db log gpt/zlog0
Пул немедленно начнет использовать новое устройство журнала или кэша.
Чтобы добавить зеркалированное устройство журнала примените ключевое слово mirror и
соответствующих поставщиков. Зеркалирование ZIL (ZFS Intent Log) предоставляет избыточность для записи, помогая гарантировать,
что записанные на диск данные выдержат аппаратный сбой. В нашем случае мы добавляем устройства журнала
gpt/zlog0 и gpt/zlog1, а также просим пул
db использовать в качестве журнала зеркало.
# zpool add db log mirror gpt/zlog0 gpt/zlog1
Обычно зеркалирование устройств кэширования не является наилучшим использованием быстрого диска. ZFS очень хорошо обрабатывает выход из строя устройства кэшированя. Чередование же кэша о нескольким устройствам снижает загруженность всех устройств и, следовательно, уменьшает выхода из строя.
Когда вы удаляете устройство журнала или кэша из пула ZFS, ZFS останавливает запись новых данных в ваш журнал, очищает буфер данных в журнале и освобождает устройствою
Чтобы удалить автономное устройство журнала или кэша, примените zpool remove,
имя пула, а также имя устройства. Ранее мы добавили устройство gpt/zlog0 в
качестве устройства журнала для пула db. Давайте удалим его.
# zpool remove db gpt/zlog0
Удаление зеркалированного устройства журнала слегк более сложное. Перед удалением зеркала вы должны знать его имя. Посмотрите состояние пула.
# zpool status db ... NAME STATE READ WRITE CKSUM db ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/zfs0 ONLINE 0 0 0 gpt/zfs1 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 gpt/zfs2 ONLINE 0 0 0 gpt/zfs3 ONLINE 0 0 0 logs mirror-2 ONLINE 0 0 0 gpt/zlog0 ONLINE 0 0 0 gpt/zlog1 ONLINE 0 0 0
Устройство журналирования называется mirror-2. Удалите его, как если бы вы это делали с автономным устройством.
# zpool remove db mirror-2
Пул очищает журнал и удаляет устройства из пула.
Замените неисправное устройство журнала или кэша, даже если оно участник зеркала точно так же, как вы поступаете с
любым другим неисправным устройством. Здесь мы заменяем устройство gpt/zlog0
на gpt/zlog1.
# zpool replace db gpt/zlog0 gpt/zlog2
Устройство журнала перенесет актуальные данные и продолжит работу.
Вы можете перемещать диски файловой системы ZFS между машинами, даже между машинами работающими под различными операционными системами. У вас нет ограничений на аналогичную архитектуру, или - ZFS даже позволяет вам перемещать диски между различным конечным оборудованием! Это предлагает, например, легкий путь миграции между, скажем, Sparc OpenSolaris и FreeBSD. ZFS использует свои собственные метаданные на диске для отслеживания роли каждого поставщика в пуле, следовательно вам нет нужды отслеживать порядок дисков, узлы устройств или решать любые другие обычные проблемы дисков. Отключите ваши диски, сложите их в сумку, проедьте на другой конец города и вставьте их снова. Пиведение пула обратно в работающее состояние называется импортированием (importing).
Однако, ZFS может работать с поставщиками хранения отличными от дисков. Предположим, вы используете разделы GPT на ваших дисках, как вы рекомендовали. Вы можете затем решить переместить эти диски с вашего хоста FreeBSD в другую операционную систему или на другую аппаратную архитектуру. Если новые операционная система или оборудование не распознают разделы GPT, новый хост не сможет найти ваши пулы для их импорта!
Перед импортом пула вы все-таки должны его экспортировать.
Экспорт примерно аналогичен аккуратному размонтированию традиционной файловой системы. ZFS помечает поставщиков неактивными и завершает все отложенные транзакции. Если у вас есть журнал преднамеренного протоколирования ZFS (ZFS Intent Log, Главе 2), журнал очищается. Все записывается на поставщика, файловая система демонтируется и система будет уведомлена, что эти поставщики теперь свободны для повторного использования.
Используйте zpool export и имя пула для экспорта пула. Здесь мы экспортируем
пул db.
# zpool export db
Эта команда работает без оповещений. Выполните zpool list для проверки того, что пул
больше не в системе.
Система откажется экспортировать активную файловую систему. Отключите на наборе данных все демоны, осуществляющие запись
в этот набор данных и изменения рабочего каталога вашей оболочки. Остановите хвостовые (tailing) файлы. Вы можете
использовать fstat(1) или lsof(8)
чтобы определить процессы, использующие файловые системы этого набора данных.
Чтобы увидеть неактивные пулы присоединенные к системе, выполните zpool import.
Это не будет действительным импортом пулов, а только покажет что доступно для импорта.
# zpool import
pool: db
id: 8407636206040904802
state: ONLINE
action: The pool can be imported using its name or numeric identifier.
config:
db ONLINE
raidz1-0 ONLINE
gpt/zfs1 ONLINE
gpt/zfs2 ONLINE
gpt/zfs3 ONLINE
gpt/zfs4 ONLINE
Здесь показано, что наш пул db, также именуемый длинным цифровым идентификатором, может
быть импортирован. Вы видите внизу конфигурацию пула в точности как это было для активного пула.
Состояние ONLINE не означает что пул активен, а только то, что все поставщики готовы для использования. Поскольку ZFS информирован, пул готов к работе.
Импортируйте пул при помощи zpool import и имени пула или цифрового идентификатора.
# zpool import db
Если у вас есть множество неактивных пулов с одинаковым именем, импортируйте вместо этого пул по идентификационному номеру.
# zpool import 8407636206040904802
Вы не можете импортировать пул если уже существует пул с этим именем пока не переименуете пул.
Некоторые из нас повторно используют имена пулов на различных машинах. Когда Лукасу нужно выделить пул для баз данных
он всегда называет его db, потому что это коротко а он ленивый. Это великолепно
для стандартизации - все знают где обитают файлы баз данных. Однако это раздражает при перемещении дисков на другую машину.
Каждая машина может иметь только один пул с уникальным именем.
ZFS позволяет вам окончательно переименовать пул заданием нового имени после существующего имени пула. Вот мы импортируем
пул с именем db под именем olddb.
# zpool import db olddb
Наборы данных импортированного пула могут быть найдены в /olddb. Такое переименование
окончательное. Вы можете экспортировать пул и повторно импортировать этот пул с его новым именем навсегда.
Для временного монтирования пула в местоположении, отличном от обычной точки монтирования, применяйте флаг
-R и альтернативный путь корня.
# zpool import -R /dunno data
Это временно добавит путь /dunno ко всем наборам данных в импортируемом пуле. Экспорт
вашего пула удаляет дополнительный путь и сбрасывает свое свойство
altroot.
Используйте свойство altroot когда вы не знаете что
есть в пуле и не хотите случайно наложить его на ваши существующие наборы данных или файловые системы. Помните, файловые системы
BSD стекируются! Вы также можете применять альтернативную среду загрузки, при которой импортируемый пул может перекрывать
активную корневую файловую систему и скрывать нужные вам для управления пулом инструменты.
Вы не можете импортировать пул, если он не имеет достаточного числа участников для поддержки всех необходимых данных. Аналогично тому, что вы не можете применять RAID-Z1 если у вас нет двух дисков, точно так же вы не можете импортировать RAID-Z1 с более чем одним утраченным диском.
# zpool import
pool: db
id: 8407636206040904802
state: UNAVAIL
status: One or more devices are missing from the system.
action: The pool cannot be imported. Attach the missing
devices and try again.
see: http://illumos.org/msg/ZFS-8000-3C
config:
db UNAVAIL insufficient replicas
RAID-Z1-0 UNAVAIL insufficient replicas
gpt/zfs1 ONLINE
4300284214136283306 UNAVAIL cannot open
gpt/zfs3 ONLINE
3061272315720693424 UNAVAIL cannot open
Это RAID-Z1 с четырьмя поставщиками, однако два поставщика утрачены. Проверьте что все повторно установленные диски правильно подключены и попробуйте снова.
Импорт пулов чрезвычайно полезен при восстановлении разрушенных систем. Применяя импорт пулов, ZFS позволяет вам обойти многие ошибки и проблемы. Этот раздел проведет вас по ряду специальных случаев применения импорта.
Разрушение пула не разрушает на самом деле никакие данные. Система отмечает пул разрушенным, однако пул и все его метаданные
остаются на диске пока их не перезапишут. Для того,чтобы попросить ZFS найти разрушенный, но пригодный к импорту пул, добавьте
флаг -D.
# zpool import -D
Состояние пула будет отображено как ONLINE (DESTROYED). ONLINE означает, что пул имеет все необходимое для работы.
Используйте флаг -D с именем пула или его идентификационным номером для его воскрешения.
# zpool import -D 8407636206040904802
Если пул утратил слишком большое число поставщиков хранения, вы не можете импортировать его. Вы не можете
zpool online для отсоединенных дисков. Проверьте дисковые корзины и убедитесь, что диски,
которые вы хотите импортировать, подключены и запитаны. При следующем запуске zpool import
вновь подключенные диски будут отображены.
Если пул утратил своё устройство журнала, добавьте флаг -m для его импорта без этого
устройства. Экспортируемый пул должен иметь все на поставщиках хранения.
# zpool import -m db
При выполнении вами импорта вы можете устанавливать свойства пула с применением флага -o.
Здесь мы импортируем и переименовываем пул баз данных, а также делаем его доступным только на чтение.
# zpool import -o readonly=on db olddb
Теперь мы можем копировать файлы из старого пула без разрушения первоначальной копии наших данных.
Вы можете захотеть импортировать разрушенный пул чтобы попытаться восстановить хоть какую-то часть данных в нем. Флаг
-F просит zpool import откатить назад несколько транзакций.
Это может вернуть пул в состояние, доступное для импорта. Вы потеряете содержимое транзакций, которые вы пропустили, однако если
это сработало, в любом случае, данные транзакции, судя по всему, и вызвали проблемы.
Один интересный факт об ZFS заключается в том, что она позволяет заменять поставщиков бОльшими по размеру поставщиками. Если ваш пул хранения с избыточностью использует диски 4ТБ, вы можете заменить их на диски, скажем, моделей 10ТБ и увеличить размер вашего пула. Это потребует замены успешных поставщиков поставщиками бОлшего размера.
Пул вычисляет свой размер по наименьшему диску в каждом VDEV. Если ваше зеркало имеет диск 4ТБ и диск 10ТБ в одном VDEV, то зеркалированное VDEV будет иметь пространство 4ТБ. Не существует разумного способа зеркально отобразить 10ТБ данных на диске в 4ТБ! Однако, если вы замените ваш 4ТБ диск, вы будете способны расширить зеркало до размера наименьшего диска.
Единственный вопрос заключается в том, хотите ли вы чтобы ваши пулы автоматически расширялись,когда у них есть такая возможность,
или вы хотите активировать расширение вручную? ZFS может автоматически выполнять работу по расширению, однако для начала вам нужно
установить свойство autoexpand для каждого пула. ZFS
оставляет его значение по умолчанию off, поскольку вы никогда не можете уменьшать никакой пул. (Наличие включенным в on
autoexpand не повредит вам, однако наличие его включенным
по умолчанию может оставить вас со слишком большим пулом для всех ваших других дисков.)
# zpool set autoexpand=on db
Без установки этого свойства вы должны выполнить команду для расширения пула после замены поставщика.
Замена всех поставщиков в пуле не является сложной, но она связана с определенным занудством. Возьмем данный RAID-Z1 с тремя поставщиками.
NAME STATE READ WRITE CKSUM db ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 gpt/zfs1 ONLINE 0 0 0 gpt/zfs2 ONLINE 0 0 0 gpt/zfs3 ONLINE 0 0 0
Каждый из этих поставщиков является одним маленьким диском.
# zpool list db NAME SIZE ALLOC FREE FRAG EXPANDSZ CAP DEDUP HEALTH ALTROOT db 59.5G 1.43G 58.1G 1% - 2% 1.00x ONLINE -
Если оборудование имеет достаточно физического пространства {для размещения новых устройств}, добавьте новые диски и создайте поставщиков для замены. Если вы ограничены в физическом пространстве, выведите заменяемого поставщика в офлайн и поменяйте диски местами. Здесь мы выводим диски в офлайн и меняем их местами.
Данный пул имеет трёх поставщиков: gpt/zfs1, gpt/zfs2
и gpt/zfs3. Первым мы заменяем gpt/zfs1. Выполнение
gpart show -l показывает, что поставщик находится на диске da1.
Если вам нужно вывести ваш диск в офлайн для добавления диска на замену, начните с идентификации физического местоположения диска da1. Подготовьте заменяющий диск в соответствии с требованиями вашего оборудования, затем выведите поставщика в пуле в автономное состояние.
# zpool offline db gpt/zfs1
Это должно произойти без отображения. Проверка zpool status покажет данного поставщика в
автономном состоянии. Вы можете извлечь этот диск из вашей системы.
Вставьте диск замены либо на место размещения старого диска, либо в новый слот. В /var/run/dmesg.boot
появится новый диск. В данной системе новый диск отображается как /dev/da4.
Создайте на этом диске требуемый раздел и маркируйте его меткой. Если вы не используете серийные номера в своих метках и используете
только физическое местоположение, вы можете применить ту же метку. (Опять же, мы применяем такие короткие метки здесь, поскольку их
легче читать при обучении.)
# gpart create -s gpt da4 da4 created # gpart add –a 1m -t freebsd-zfs -l zfs1 da4
Теперь попросите пул заменить отказавший диск.
# zpool offline db gpt/zfs1
Позвольте пулу завершить перенос актуальных данных прежде чем продолжить замену других поставщиков. Замена устройств не обеспеченных избыточностью данных в процессе переноса актуальных данных (resilvering) вызовет только головную боль. Если вы используете RAID-Z2 или RAID-Z3, существует возможность одновременной замены множества дисков, но это рискованно. Дополнительный отказ диска может вызвать отказ VDEV. Без предоставляемой дополнительными поставщиками избыточности ZFS не способна к самовосстановлению. Пределы операций ввода/ вывода каждого диска, скорее всего, придушат скорость переноса актуальных данных.
После того, как ваш первый поставщик перенесет актуальные данные, замените ваш следующий меньший диск. Вы не увидите изменений в
дисковом пространстве, пока вы не замените всех поставщиков в VDEV. Чтобы гарантировать, что вы заменили всех поставщиков на бОльших,
выполните проверку zpool list.
# zpool list db NAME SIZE ALLOC FREE FRAG EXPANDSZ CAP DEDUP HEALTH ALTROOT db 59.5G 1.70G 57.8G 0% 240G 2% 1.00x ONLINE -
Отметим, что у нас теперь новый размер пространства в EXPANDSZ. Данный пул может быть увеличен.
Если вы установили пул в режим авторасширения перед началом ваших операций, он должен расшириться самостоятельно. Если нет,
расширьте каждое устройство в вашем пуле вручную при помощи zpool online -e.
# zpool online -e db gpt/zfs1 # zpool online -e db gpt/zfs2 # zpool online -e db gpt/zfs3
Полученный пул имеет теперь бОльшее пространство.
Команды FreeBSD и OpenZFS постоянно улучшают свое программное обеспечение, добавляя новую функциональность в ZFS и поддержку ZFS в FreeBSD. Некоторые из этих улучшений требуют изменений или добавлений в zpool -ах. Когда вы обновляете операционную систему хоста, хост может получить свойства, которые не поддерживаются данным существующим пулом. Перед использованием этих новых функций вы должны обновить ваши пулы хранения. Пулы продолжат работать и в случае, если вы не обновите их, однако они не получат преимуществ новой функциональности, которая требует изменений дисковых форматов.
Однако, вы можете выбрать отказ от обновлений ваших пулов когда вы обновляете свою операционную систему. Если вы обновляете систему с FreeBSD 11 на FreeBSD 12, вы можете оставить диски в формате пула для FreeBSD 11. Если вам понадобится откатить выполненное обновление, операционная система все еще будет в состоянии читать эти пулы. Обновления системы могут выполняться в различных направлениях. Обновления пула нет.
Изначально ZFS использовала номера версий для индикации того, какие версии функций пула или операционной системы поддерживаются. Номера версий начинались с 1 и увеличивались по одной при каждом улучшении ZFS, которое затрагивало дисковый формат. Когда Sun Microsystems выступала центральным координатором всего развития ZFS, имел смысл единый инкрементальный номер версий. Номер версии в OpenZFS установлен в значение 5000, а пулы используют вместо этого флаги функциональности. Мы подробно обсуждали флаги функциональности в Главе 3.
Основными двумя вопросами для флагов функциональности являются: "Какую функциональность поддерживает ваш пул в настоящее
время?" и "Какую функциональность поддерживает ваша операционная система?" Проверьте свойства вашего пула, чтобы
посмотреть что имеется на вашем диске, как обсуждалось в Главе 3. Чтобы
посмотреть все установленные флаги функциональности, поддерживаемые выпуском вашей FreeBSD, выполните
zpool upgrade -v.
# zpool upgrade -v
This system supports ZFS pool feature flags.
{Данная система поддерживает флаги функциональности пула ZFS.}
The following features are supported:
(Поддерживаются следующие функции:)
FEAT DESCRIPTION
-------------------------------------------------------------
async_destroy (read-only compatible)
Destroy filesystems asynchronously.
{Асинхронное уничтожение файловых систем.}
empty_bpobj (read-only compatible)
Snapshots use less space.
{Снимки используют меньшее пространство.}
lz4_compress
LZ4 compression algorithm support.
{Поддержка алгоритма сжатия LZ4.}
...
Свойства, отмеченные как "read-only compatible", означают, что хосты, которые не поддерживают эти флаги функциональности, могут импортировать данные пулы, но в режиме доступности только для чтения. Смотрите раздел "Экспорт и импорт дисков" ранее в данной главе по поводу обсуждения перемещения пулов между хостами.
Замечания по выпускам FreeBSD для каждой версии обозначают новую функциональность ZFS. Вам действительно нужно внимательно
читать эти замечания к выпуску перед обновлением, не так ли? Если вы каким-то образом пропустите эту часть документации,
zpool status сообщит вам, какие пулы могут использовать обновления. (Помните, что
только потому, что пул может принять некое обновление не означает, что вы должны выполнять это обновление. Если вам, вероятно,
потребуется вернуть обновление операционной системы назад, оставьте функциональность вашего пула в покое!)
# zpool status db
pool: db
state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
still be used, but some features are unavailable.
{Некоторые поддерживаемые функции не разрешены в данном пуле. Это пул
все еще может использоваться, однако некоторая функциональность недоступна.}
action: Enable all features using 'zpool upgrade'. Once this is done,
the pool may no longer be accessible by software that does not support
the features. See zpool-features(7) for details.
{Разрешите всю функциональность при помощи 'zpool upgrade'. Если вы сделаете это,
пул может больше не быть доступным для программного обеспечения, которое не поддерживает
эти функции. За подробностями обращайтесь к zpool-features(7).}
...
Вы также получите список всех новых функций, поддерживаемых обновлением. Обновите ваши пулы выполнив
zpool upgrade на этих пулах.
# zpool upgrade zroot
Обновления пула безвозвратно добавляют новые поля в существующее расположение пула. Однако, обновление не переписывает существующие данные. Даже если новая функциональность может иметь проблемы, простое наличие такого флага на диске дает очень низкую вероятность риска.
Если у вас есть планы перемещать диски на систему, работающую с более старыми версиями операционной системы, или на операционную систему, выполняющую более старую версию OpenZFS, вы можете разрешать функциональность пула более избирательно. Перемещение дисков с системы FreeBSD 11 на систему FreeBSD 10 требует аккуратной проверки функциональностей пулов. Разрешайте отделную функциональность установкой ее свойства в enabled.
# zpool set feature@large_blocks=enabled data
Данный пул теперь поддерживает функциональность large_blocks.
Загрузчик FreeBSD должен понимать ваш пул ZFS, с которого вы загружаетесь. Это означает, что он должен распознавать
функции пула. Всякий раз, когда вы обновляете пул, содержащий вашу файловую систему /boot,
вы должны обновлять и начальный загрузчик на этих дисках. Для обновления начального загрузчика используйте
gpart(8). Если вы загружаетесь с зеркала ZFS на дисках da0 и da1, вы обновите
ваши загрузчики на обоих дисках как-то наподобие:
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da1
Система может не загрузиться без этого обновления. Команда zpool upgrade напечатает
вам напоминание, но вы вольны проигнорировать его, если захотите. Если вы приведете вашу систему в незагружаемое состояние,
вы можете попытаться загрузиться с ISO с самой последней на текущий момент версией FreeBSD, или с liveCD и скопировать их
начальные загрузчики в вашу систему.
FreeBSD не поддерживает все функции ZFS. Большинство неподдерживаемых функций не работают из-за фундаментальных различий между архитектурами FreeBSD и Solaris. Люди активно разрабатывает решения, которые позволят FreeBSD поддерживает все особенности ZFS. Мы ожидаем, что некоторые из них станут поддерживаемыми после того, как эта книга будет опубликована.
На момент написания книги не работает горячее резервирование. Горячее резервирование позволяет ZFS автоматически заменять
неисправный диск с назначенным запасным диском в системе. Это зависит от предстоящей реализации
zfsd(8), которая до сих пор находится в стадии разработки.
Теперь, вы можете заполнить пул данными и восстанавливать оборудования, давайте поиграем с парой более полезными функциями ZFS, клонами и снимками.