null

Восстановление томов на массивах 6000 и 2000 серии.

Shit happens ©

    Иногда случается случается так,очень редко но все же, что заботливо созданные тома на массивах внезапно исчезают.
В данном случае речь идет о массивах Sun StorageTek 6000 и 2000 серий. Происходит это по разным причинам. В самых первых версиях массивов в эта  проблема была вызвана недочетом микрокода, но массив со столь древней прошивкой найти довольно трудно. Потому главной причиной является "человеческий фактор", промах мышью, неверно набранная команда, некорректное выключение/переключение массивов и т.д.
    В случае если на пропавших томах полезных данных не было, то можно слегка погрустить, пересоздать тома и работать дальше. А если тома содержали полезные данные, да еще не имеющие резервной копии, ситуация становиться интересней.Как правило при потере томов теряются только метаданные, отвечающие за размещение данных по физическим дискам массива, а сами пользовательские данные остаются на своих местах. Таким образом, есть шанс восстановить данные. Если просто пересоздать тома на прежнем месте, то при инициализации новых томов все данные будут безвозвратно утеряны, но для вышеуказанных массивов существует специальная процедура восстановления.
    Ранее подобная процедура была довольна не тривиальна, требовала непосредственно подключения к массиву при помощи serial кабеля,  доступа в VxWorks(операционная система реального времени, под управлением которой работают массивы)  и изменения в ней ряда служебных параметров. Ныне, благодаря неустанному труду программистов, появилась возможность восстанавливать  тома при помощи штатных средств StorageTek Common Array Manager Software, в дальнейшем CAM. Данную полезную функцию CAM приобрел начиная с версии 6.5.
    Для того чтобы успешно провести вышеуказанную процедуру необходимо

  • СAM версии 6.5 и выше
  • Managment host - машину, на которую можно установить CAM. CAM существует под SPARC - Solaris, x86 Solaris,Linux,Windows.
  • Массив Sun StorageTek 6000 или 2000 серий.
  • Надежное сетевое соединение между массивом и Managment host.
  • Исчезнувший том.
  • Информация о  прежней конфигурации тома, без этого пункта можно смело отправляться на поиски резервной копии данных.


Данный функционал выполняется только в cli при помощи полезной утилиты  service, в Solaris она находиться в  

/opt/SUNWsefms/bin/service

а точнее её подкоманды recover.    Суть её работы в том, что она создает тома, но при этом не инициализирует их.
В общем виде команда выглядит следующим образом
/opt/SUNWsefms/bin/service -d <deviceid> -c recover label=<vol name> manager=<a|b> vdiskID=<vdisk idx> [drives=<tXdiskY,tXdiskY...>] raidLevel=<0|1|3|5> capacity=<bytes> segmentSize=<bytes> offset=<blocks> readAhead=<0|1>

параметры имеют следующий смысл

  • -d <deviceid>     -    имя массива, необходимо для успешного выполнения любой подкоманды service.
  • -c <commnand>     -    собственно сама подкоманда, в данном случае recover.
  • label=<vol name> -    имя воссоздаваемого тома, не обязательно чтобы оно в точности совпадало с прежним именем  тома, это просто имя которое будет носить воссозданный том.
  • manager=<a|b> -     предпочтительный контроллер для воссозданного тома,  опять таки не обязательно чтобы совпадал с прежним контроллером воссоздаваемого тома.
  • vdiskID=<vdisk idx> -    номер vdisk на котором существовал том. В случае если исчез только том, а vdisk, на котором он располагался, остался, то необходимо указать номер того vdisk на котором существовал том. В случае если vdisk исчез вместе с томом,  то 0 и указать следующий параметр.
  • drives=<tXdiskY,tXdiskY...> -    физические диски на которых располагался том и его vdisk. Он указан в квадратных(как штаны Губки Боба) скобках, то есть необязательный. Если vdisk на котором производится восстановление тома существует, диски указывать не нужно. Если vdisk тоже необходимо восстановить, то указывать диски, на которых располагался vdisk, необходимо причем именно в том порядке в котором они работали в пропавшем vdisk.
  • raidLevel=<0|1|3|5> -    уровень RAID воссоздаваемого тома, должен в точности соответствовать прежнему.
  • capacity=<bytes> -    ёмкость в байтах, мультипликаторы не поддерживаются,должна в точности соответствовать прежней.
  • segmentSize=<bytes> -    размер сегмента RAID в байтах, мультипликаторы не поддерживаются,должен в точности соответствовать прежнему.
  • offset=<blocks> -    смещение тома относительно начала vdisk в блоках,должна в точности соответствовать прежней.
  • readAhead=<0|1> -    будет ли включено упреждающее чтение для воссозданного тома, 0 - выключено , 1 - включено. Совпадение с прежним значением не обязательно.


    Зная какую информацию о исчезнувшем томе необходимо сообщить утилите service для его восстановления , встает вопрос, где эту информацию можно обнаружить. Путей несколько. В фале storadeArrayProfile.txt архива supportdata, который рекомендуется собирать после инсталляции оборудования и время от времени в процессе эксплуатации. Эту же информацию можно получить при при помощи подкоманды print утилиты service

/opt/SUNWsefms/bin/service -d <deviceid> -c print -t profile

<deviceid> или имя массива необходимо знать, но на всякий случай оно отображается в первой строчке про-файла.

bash-3.00# ./service -d  ST6140 -c print -t profile
Executing the print command on ST6140
PROFILE FOR STORAGE ARRAY: ST6140


    Для получения остальной  информации необходимо переместиться к разделу Virtual Disks (Volume Groups) про-файла.  

 

Virtual Disks (Volume Groups) --------------
Number of volume groups: 2

   VolumeGroup 2
      Raid Level: RAID 1
      Online: true
      Tray loss protection: false

      Associated volumes and capacities:
         r1_16_d2 Capacity: 67 GB (71940702208 bytes) Offset (blocks): 0
         Free Extent Capacity: 887,196 MB (930292736 bytes) Offset (blocks): 140509184

      Associated drives (in piece order):
         Tray.85.Drive.03 index: 0
         Tray.85.Drive.04 index: 1

     Здесь можно увидеть, что том  r1_16_d2 находится на VolumeGroup 2 или vdisk 2 (параметр vdiskID), сконфигурирован как RAID уровня 1 (параметр raidLevel), имеет емкость в байтах 71940702208 bytes (параметр capacity), vdisk создан на двух физических дисках Tray.85.Drive.3 и Tray.85.Drive.04 индекс указывает на порядок следования дисков в vdisk(параметр drives). Отдельно следует отметить параметр Offset, логично было бы предположить, что блоки, которые нужно указывать в "service  recover", совпадают с теми, которые указаны в про-фале массива. Ан нет, они различаются, но , к счастью, ровно в 512 раз. Если Offset=0, то большого значения это не имеет, но если он от 0 отличен, то Offset, указанный в про-фале массива, необходимо умножить на 512 и полученное значение использовать в команде "service  recover".  Из параметров которые должны в соответствовать прежнему тому при его воссоздании остался только segmentSize, для того чтобы узнать его значение необходимо переместится к параметрам самого тома

DETAILS
   Volume name: r1_16_d2
     <...>
      Segment size: 16 KB


    Здесь размер сегмента указан в килобайтах, для получения значения в байтах нужно умножить его на 1024, 16х1024=16384. Теперь вся необходимая для восстановления тома информация есть в наличии.

Небольшой пример восстановления тома, для массива ST6140 и сервера под управление Solaris
Создание и mapping тома atlantida, которому предстоит исчезнуть

    ./sscs create -a ST6140 -p Sun_ZFS -s 999MB  -v 1 volume atlantida
    ./sscs map -a ST6140 volume atlantida

   
здесь и далее./sscs означает /opt/SUNWsesscs/cli/bin/sscs(при использовании Solaris)  
Далее, создание файловой системы и монтирование тома в Solaris

    newfs /dev/rdsk/c3t600A0B800026AAB80000129A4BA1A267d0s0
    mount /dev/dsk/c3t600A0B800026AAB80000129A4BA1A267d0s0 /mnt


Копирование архива с CAM на том, тестирование архива, вычисление cksum. Понадобиться в дальнейшем для проверки действительно ли цел файл.

    cp /var/tmp/host_sw_solaris_6.5.0.10.tar.gz /mnt
    cd /mnt
    ls -l
    total 940992
    -r--r--r--   1 root     root     481531725 марта 18 15:08 host_sw_solaris_6.5.0.10.tar.gz
   &nbsprwx------   2 root     root        8192 марта 18 15:00 lost+found
    gzip -vt host_sw_solaris_6.5.0.10.tar.gz
    host_sw_solaris_6.5.0.10.tar.gz:         OK
    cksum host_sw_solaris_6.5.0.10.tar.gz
    202628879       481531725       host_sw_solaris_6.5.0.10.tar.gz


Отмонтирование тома.

    umount /mnt


Теперь необходимо сохранить про-файл массива с информацией необходимой для восстановления  тома  atlantida.

   /opt/SUNWsefms/bin/service -d  ST6140 -c print -t profile > /var/tmp/atl_profile


Теперь можно удалить том, для того чтобы исчез и vdisk, на котором том располагался, удалим все тома, находящиеся на vdisk 1

./sscs list -a ST6140 vdisk 1
<...>
  Associated Volumes:   
    Volume:             atlantida
    Volume:             patch

./sscs delete  -a ST6140 volume atlantida,patch


Тома пропали, можно смело переходить к их восстановлению. Информация о прежней конфигурации сохранена в файле /var/tmp/atl_profile
Конфигурация тома atlantida следующая

VolumeGroup 1
      Raid Level: RAID 5
      Online: true
      Tray loss protection: false

      Associated volumes and capacities:
         patch Capacity: 1,149 GB (1234173952 bytes) Offset (blocks): 0
         atlantida Capacity: 999 MB (1047527424 bytes) Offset (blocks): 803584
         Free Extent Capacity: 201,474 GB (216331152384 bytes) Offset (blocks): 1485568

      Associated drives (in piece order):
         Tray.85.Drive.01 index: 0
         Tray.85.Drive.03 index: 1
         Tray.85.Drive.04 index: 2
         Tray.85.Drive.02 index: 3
<...>

  Volume name: atlantida
<...>
      Segment size: 128 KB

 
Соответственно параметры для команды "service  recover" следующие vdiskID=0(так как vdisk тоже исчез), raidLevel=5, capacity=1047527424, offset=803584х512=411435008, drives=t85d01,t85d03,t85d04,t85d02, segmentSize=128x1024=131072

Таким образом команда для восстановления будет выглядеть следующим образом

/opt/SUNWsefms/bin/service -d ST6140 -c recover label=antlantida-1 manager=a vdiskID=0 drives=t85d01,t85d03,t85d04,t85d02 raidLevel=5 capacity=1047527424 segmentSize=131072 offset=411435008 readAhead=1
Executing the recover command on ST6140
Completion Status: Success


И том успешно восстановлен

    ./sscs list -a ST6140 volume
    Volume:antlantida-1   Type: Standard  Pool: -  Profile: -


Подходящий пул и про-файл тома необходимо будет задать позже.
Можно его смонтировать, необходимо обратить внимание на то , что wwn тома изменился,  и проверить целостность файлов

    mount /dev/dsk/c3t600A0B800026AB5000000E004BA1B32Cd0s0 /mnt
    gzip -tv /mnt/host_sw_solaris_6.5.0.10.tar.gz
    /mnt/host_sw_solaris_6.5.0.10.tar.gz:    OK
    cksum /mnt/host_sw_solaris_6.5.0.10.tar.gz
    202628879       481531725       /mnt/host_sw_solaris_6.5.0.10.tar.gz


Процедура прошла успешно, данные восстановлены.

 

 

Назад

 

Профессиональные навыки:

  •  За более чем 10 лет преподавательской деятельности стал обладателем навыка простого и понятного изложения учебного материала с использованием минимильного набора вспомогательных средств;
  •  Разработка и внедрение образовательных программ по различным ИКТ-направлениям;
  •  Многолетний опыт работы в технической поддержке позволил приобрести навыки поиска причин возникновения проблем в системах различной степени сложности;
  •  Проектирование, внедрение, обслуживание и оптимизаци производительности  ИКТ решений на базе аппаратных и программных продуктов таких производителей как Sun / Oracle, IBM, HP, Dell, Supermicro, Brocade, Veritas, Symantec, Intel, Huawei, Commvault, VMware и дргих;
  • Администрирование операционных систем на базе Linux (Arch, Debian, OEL, Fedora/RHEL, CentOS, Suse/SLES) и Unix - Solaris, HP-UX, AIX ;
  •  Построение решений по виртуализации на базе VMware vSphere, Huawei Fusion Sphere, Xen project, KVM, Oracle VM for Sparc, Oracle VM for x86, Oracle VirtualBox, Qemu;

Квалификация:

  • Диплом магистра техники и техногогий Санкт Петербургского Университета Информационных Технологий Механики и Оптики;
  • Oracle Certified Professional, Oracle Solaris 11 System Administrator
  • Oracle Certified Associate, Oracle Solaris 11 System Administrator
  • HCNA/HCNP Routing&Switching
  • HCNA/HCNP Storage
  • HCIE Storage (первый вне Китая)
  • HCNA/HCNP Data Center Facility
  • HCNA Cloud
  • HCNA Security
  • HCNA Unified Communication
  • IBM Certified Specialist - Storwize Family Technical Solutions
  • IBM Certified Technical Sales Specialist - Power Systems with POWER8 Scale-out
  • Sun Certified Field Engineer

Преподавательские сертификаты:

  • Oracle Certified Instructor
  • HCIE Storage Instructor
  • HCNP Routing&Switching Instructor
  • HCNP DCF Instructor
  • HCNA Cloud Instructor

 

Ничего не найдено. n is 0