The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Раздел полезных советов: Опыт восстановления работы zones в ..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Раздел полезных советов: Опыт восстановления работы zones в ..."  +/
Сообщение от auto_tips on 03-Сен-11, 14:15 
После скоропостижной гибели жесткого диска с лежащими на нем зонами, наступило время восстановить их из бекапа и запустить. Казалось, тривиальная процедура, отрепетированная на тестовых системах (но не тех, где лежали зоны – это важно) отняла много времени и поставила несколько вопросов, ответы на которые еще придется поискать.

Восстанавливаем зону из бекапа:

   # zfs send -R backup/zone/develop@rep201108250419 | zfs receive -F vol01/ zone/develop@rep201108250419

Стартуем зону и наблюдаем странное:

   # zoneadm -z develop boot

   zone 'develop': ERROR: no active dataset.
   zone 'develop':
   zoneadm: zone 'develop': call to zoneadmd failed

Ошибка явно говорит о том, что у нас что-то не в порядке со свойствами датасета.

++ Начинаем осмотр датасета

Чтобы было с чем сравнивать, я создал и запустил тестовую зону, свойства ее файловых систем и брал за эталон.

Тестовая зона создается примерно так:

    # zonecfg -z testzone

    testzone: No such zone configured
    Use’create’ to begin configuring a new zone.
    zonecfg:testzone>create
    zonecfg:testzone>set zonepath=/vol01/zone/testzone
    zonecfg:testzone>set autoboot=false
    zonecfg:testzone>add net
    zonecfg:testzone:net>set physical=e1000g4
    zonecfg:testzone:net>set address=192.168.0.24/24
    zonecfg:testzone:net>end
    zonecfg:testzone>verify
    zonecfg:testzone>commit
    zonecfg:testzone>exit

    # zoneadm -z testzone install
    ...

    # zoneadm -z testzone boot

При инсталляции в OpenSolaris/Solaris 11 создаются три датасета (по адресу zonepath):

    # zfs list | grep vol01/zone/testzone

    NAME
    vol01/zone/testzone
    vol01/zone/testzone/ROOT
    vol01/zone/testzone/ROOT/zbe

++ Лечение

    Смотрим полный список свойств датасетов исправной и сломанной зон и сравниваем их:
    
   # zfs get all vol01/zone/testzone

    (сдесь должен быть очень большой вывод, который я пропустил и самое интересное из которого можно увидеть ниже)

    # zfs get all vol01/zone/testzone/ROOT
    ...
    # zfs get all vol01/zone/testzone/ROOT/zbe
    ...
    # zfs get all vol01/zone/develop
    ...
    # zfs get all vol01/zone/develop/ROOT
    ...
    # zfs get all vol01/zone/develop/ROOT/zbe

    ...

Наблюдаем основную разницу в данных свойствах датасета:

   # zfs get zoned,canmount,mountpoint,org.opensolaris.libbe:parentbe,org.opensolaris.libbe:active vol01/zone/testzone/ROOT/zbe

    NAME    PROPERTY    VALUE    SOURCE

    vol01/zone/testzone/ROOT/zbe  zoned on inherited from vol01/zone/testzone/ROOT
    vol01/zone/testzone/ROOT/zbe  canmount noauto  local
    vol01/zone/testzone/ROOT/zbe  mountpoint legacy inherited from vol01/zone/testzone/ROOT
    vol01/zone/testzone/ROOT/zbe  org.opensolaris.libbe:parentbe  2aadf62d-9560-e14b-c36a-f9136fbce6e9  local
    vol01/zone/testzone/ROOT/zbe  org.opensolaris.libbe:active on  local

   # zfs get zoned,canmount,mountpoint,org.opensolaris.libbe:parentbe,org.opensolaris.libbe:active vol01/zone/develop/ROOT/zbe

    NAME    PROPERTY    VALUE    SOURCE

    vol01/zone/develop/ROOT/zbe  zoned off default
    vol01/zone/develop/ROOT/zbe  canmount on default
    vol01/zone/develop/ROOT/zbe  mountpoint /vol01/zone/develop/ROOT/zbe  default
    vol01/zone/develop/ROOT/zbe  org.opensolaris.libbe:parentbe - -
    vol01/zone/develop/ROOT/zbe  org.opensolaris.libbe:active - -


Исправляем, чтобы было нормально:

    # zfs set zoned=on vol01/zone/develop/ROOT/zbe
    # zfs set canmount=noauto vol01/zone/develop/ROOT/zbe
    # zfs set mountpoint=legacy vol01/zone/develop/ROOT/zbe
    # zfs set org.opensolaris.libbe:parentbe=2aadf62d-9860-e14b-c36a-f9106fbce6e9 vol01/zone/develop/ROOT/zbe
    # zfs set org.opensolaris.libbe:active=on vol01/zone/develop/ROOT/zbe

Аналогично, правим vol01/zone/develop/ROOT после сравнения с работающей зоной:

   # zfs get zoned,canmount,mountpoint,org.opensolaris.libbe:parentbe,org.opensolaris.libbe:active vol01/zone/testzone/ROOT

    NAME    PROPERTY    VALUE    SOURCE
    vol01/zone/testzone/ROOT  zoned on local
    vol01/zone/testzone/ROOT  canmount on default
    vol01/zone/testzone/ROOT  mountpoint legacy local
    vol01/zone/testzone/ROOT  org.opensolaris.libbe:parentbe - -
    vol01/zone/testzone/ROOT  org.opensolaris.libbe:active  - -

   # zfs get zoned,canmount,mountpoint,org.opensolaris.libbe:parentbe,org.opensolaris.libbe:active vol01/zone/develop/ROOT

    NAME    PROPERTY    VALUE    SOURCE
    vol01/zone/develop/ROOT  zoned off default
    vol01/zone/develop/ROOT  canmount on default
    vol01/zone/develop/ROOT  mountpoint  /vol01/zone/develop/ROOT     default
    vol01/zone/develop/ROOT  org.opensolaris.libbe:parentbe - -
    vol01/zone/develop/ROOT  org.opensolaris.libbe:active - -

   # zfs set zoned=on vol01/zone/develop/ROOT
   # zfs set canmount=on vol01/zone/develop/ROOT

После этого у нас все хорошо: свойства датасетов практически идентичны.

    # zlogin -C develop

    [Connected to zone 'develop' console]
    [NOTICE: Zone booting up]
    SunOS Release 5.11 Version snv_134 64-bit
    Copyright 1983-2010 Sun Microsystems, Inc.  All rights reserved.
    Use is subject to license terms.
    Hostname: develop
    Reading ZFS config: done.
    Mounting ZFS filesystems: (5/5)

    develop console login: mike
    Password:
    Last login: Mon Aug 2 06:41:54 from nostalgia
    Sun Microsystems Inc.   SunOS 5.11      snv_134 February 2010
    (mike@develop)$ su
    Password:
    Aug 27 15:04:13 develop su: ‘su root’ succeeded for mike on /dev/console
    (root@develop)# svcs -xv
    (root@develop)#

++ Вместо послесловия

Если у зоны были смонтированы  из глобальной зоны файловые системы через lofs, будет такой казус - зона загрузиться, но локальные файловые системы не будут смонтированы, сервис filesystem/local:default перейдет в состояние maintenance с ошибкой 262 в логах:  
   /usr/bin/zfs mount -a failed: cannot mount local filesystem.

Проблему можно решить экспортировав и затем импортировав зону

   # zoneadm -z webapp detach
   # zoneadm -z webapp attach

После этого все будет работать нормально.


URL: http://blog.wadmin.ru/2011/08/solaris-zones-troubleshut/
Обсуждается: http://www.opennet.me/tips/info/2620.shtml

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "ZFS головного мозга"  +/
Сообщение от XPEH email on 03-Сен-11, 14:15 
> Казалось, тривиальная процедура, отрепетированная на тестовых системах (но не тех, где лежали зоны - это важно) отняла много времени

и поделом

> поставила несколько вопросов, ответы на которые

еще придется поискать

И главный из них: нахрена в этой задаче вообще ZFS, a не проверенные и безотказные gtar или rsync ?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "ZFS головного мозга"  +/
Сообщение от GribNik on 03-Сен-11, 19:42 
> И главный из них: нахрена в этой задаче вообще ZFS, a не
> проверенные и безотказные gtar или rsync ?

В какой, простите, задаче?

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "ZFS головного мозга"  +/
Сообщение от Ващенаглухо (ok) on 05-Сен-11, 09:21 
что за gtar или rsync ? нет таких команд в солярисе.
Чел юзает снапшоты и правильно делает, а то что не знал некоторых особенностей ну и что теперь знает.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

6. "ZFS головного мозга"  +/
Сообщение от GribNik on 05-Сен-11, 17:49 
> что за gtar или rsync ? нет таких команд в солярисе.

Есть rsync точно (возможно не идет в базовой поставке с дистром, но в оф. репозиториях точно должна быть), я его юзаю когда есть задача синхронизации на файловом уровне, причем файлы могут быть на разных ФС. Но бывают задачи исключительно под ZFS, если фантазировать, то навскидку: через iscsi на zfs раздается volume размером 300 Гб, на котором лежит диск для виртуалки, на диске файлы БД размером 250 Гб. Как обеспечить резервное копирование БД с каждые 10 минут, и сократить окно бекапа до 5 минут? В ZFS это решается на раз снапшотами, так как инкрементный снапшот забекапит ИЗМЕНЕННЫЕ блоки виртуального диска only. И не будет переписывать каждый раз 300 Гб виртуального диска при обном изменившемся блоке. Кстати, буду очень признателен если кто-нибудь скажет, чем реализовать такое по-блочное копирование под CentOS?
    

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

5. "Опыт восстановления работы zones в Solaris 11 Express/OpenSo..."  +/
Сообщение от Аноним (??) on 05-Сен-11, 15:20 
ХРЕН,

дело в следующем. Зоны в Солярисе в принципе заточены под ZFS. Там даже аналог телепортации есть - но только если зона на датасете ZFS. Смекаешь?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру