Интеграция файловой системы IBM GPFS с продуктами IBM Storwize V7000 Unified Global Mirror и IBM FlashCopy на операционной системе AIX

Решение для аварийного восстановления AIX-систем с помощью репликации файловой системы GPFS

Автор представляет руководство по использованию расширенных возможностей копирования данных, доступных в унифицированной системе хранения IBM® Storwize V7000®, для создания решения для восстановления системы после сбоя (disaster recovery - DR) для кластеров IBM General Parallel File System (IBM GPFS™), развёрнутых на операционной системе IBM AIX®. В статье подробно описана концепция интеграции модульной системы хранения с возможностью репликации с файловой системой GPFS.

Рожерио де Риззио, программист-консультант, IBM

фото Рожерио де РиззиоРожерио де Риззио (Rogerio de Rizzio) работает программистом-консультантом в группе Core Engineering team for IBM Smart Analytics Systems в IBM Brazil Software Lab. Рожерио окончил университет Сан-Паулу (Universidade de São Paulo) со степенью бакалавра физических наук, а затем получил степень магистра в области сетевых технологий и MBA в области информационных технологий. Он обладает 15-летним опытом работы с платформами Linux и UNIX, СУБД, системами хранения данных, а проектирования высоконадежных систем и процессов восстановления после сбоев. Связаться с Рожерио можно по адресу rrizzio@br.ibm.com



19.06.2013

Обзор решения

Мы рассмотрим типичный GPFS-кластер, в котором пара узлов является резервными менеджерами для файловой системы, а все остальные серверы в кластере монтируют эту файловую систему как клиенты. На рисунке 1 представлены только GPFS-менеджеры для основного и дополнительного кластеров. Данные, которые должны реплицироваться со всех серверов в основном GPFS-кластере, хранятся в общей файловой GPFS-системе, смонтированной в каталоге /repvol на каждом сервере. Серверы server03 и server04 – это GPFS-менеджеры для файловой системы, но также они выступают в роли NSD-серверов (network shared disk – сетевой общий диск) для используемого общего диска. Общий диск построен на "тонком" виртуальном диске (zero percent thin provisioned virtual disk), размещённом в унифицированной системе хранения Storwize V7000.

Примечание: Виртуальные диски могут быть "толстыми" (thick) или "тонкими" (thin). В случае с "толстыми" дисками их размер задаётся при создании и остаётся постоянным. Размер "тонкого" диска зависит от фактического объёма хранящихся на нём данных и может меняться со временем, что помогает сэкономить физическое дисковое пространство.

Чтобы обеспечить симметрию между основным и вспомогательным кластерами, в системе Storwize V7000 Unified были созданы два "тонких" виртуальных диска по 200 ГБ для каждого кластера. На главном кластере один из дисков не используется, а второй диск представлен серверам server03 и server04 через сетевое хранилище данных, поверх которого построена файловая система GPFS - /repvol. Этот диск реплицируется в дополнительный кластер с помощью асинхронной репликации - глобального зеркалирования (Global Mirror – одна из возможностей системы Storwize V7000 Unified). Парный виртуальный диск для второго кластера недоступен для серверов server05 и server06. Вместо этого он используется в качестве источника для инкрементного образа, созданного с помощью IBM Tivoli® Storage FlashCopy® Manager, который периодически обновляется и смонтирован в каталогах /repvol на этих серверах. Этот образ создается на втором "тонком" виртуальном диске объёмом 200 ГБ. Когда каталог /repvol монтируется в дополнительном кластере, данные, содержащиеся на нём, могут использоваться всеми серверами, находящимися в данном кластере. Физическое соединение между основным и дополнительными кластерами построено путем конфигурирования е-портов (e_ports) в коммутаторах SAN и их соединения с помощью высокоскоростного канала, например DWDM канала (dense wavelength division multiplexing – соединение со спектральным уплотнением каналов) или "тёмного" волокна (dark fiber).

Рисунок 1. Изображение конфигурации кластеров, используемой в статьеРисунок 1. Изображение конфигурации кластеров, используемой в статье

Имена систем, используемых в процедуре

Чтобы облегчить понимание следующих процедур, мы введём для систем специальные имена вместо общих названий:

Имя основной системы Storwize V7000: V7000_7
Имена виртуальных дисков основной системы Storwize V7000: mdisk1_vdiskP1, mdisk1_vdiskP2
Имена основных хостов, на которых развёрнуты базовые модули: server03 server04

Имя вспомогательной системы Storwize V7000: V7000_6
Имена виртуальных дисков вспомогательной системы Storwize V700: mdisk1_vdiskS1, mdisk1_vdiskS2
Имена вспомогательных хостов, на которых развёрнуты базовые модули: server05 server06

В описании процедур обращайте внимание на приглашения командной строки, которые показывают, где необходимо выполнить ту или иную команду.

Создание фундаментальных компонентов

В этом разделе мы создадим необходимые компоненты (виртуальные диски для системы хранения Storwize V7000 на основном и резервном сайтах), назначим их соответствующим серверам, создадим один GPFS NSD-сервер и файловую систему, которая будет реплицироваться.

Согласно документации по Stormwize V7000, управляемый диск (MDisk – managed disk) - это логическая сущность, представляющая физическое устройство хранения, например массив, напрямую подключенных дисков, сконфигурированных в RAID-формате, или номера логических устройств (LUN) из другой системы хранения, доступной через SAN (storage area network –сеть хранения данных). Чтобы использовать возможности хранения, предоставляемые управляемым диском, он должен быть вставлен в пул хранилищ (MDisk group – группа управляемых дисков). Основной особенностью конкретного пула хранилищ является то, что он делит все принадлежащие ему управляемые диски на фрагменты одинакового размера. Размер фрагментов может быть 16, 32, 64, 128, 256, 512, 1024, 2048, 4096 или 8192 МБ. Унифицированная система хранения Storwize V7000 может управлять 2^22 (4194304) разделами. Таким образом, при размере фрагмента в 16 МБ система может управлять объёмом данных до 64 ТБ = 16 МБ * 4194304.

Эти фрагменты из пула хранилищ группируются в тома, также называемые виртуальными дисками (VDisk). Система Storwize V7000 привязывает виртуальные диски к хостам (серверам). При этом хосты никогда не "видят" сами управляемые диски и реальные устройства хранения.

Предположим, что мы уже определили группу управляемых дисков (пул хранилищ), обозначенную идентификатором 1, и обладаем достаточным количеством свободных фрагментов, чтобы создать виртуальные диски требуемого размера.

Сначала создадим виртуальные диски и привяжем их к хостам на основном кластере:

IBM_2076:V7000_7:superuser> mkvdisk -mdiskgrp 1 -iogrp 0 -size 200
-unit gb -rsize 0% -autoexpand -name mdisk1_vdiskP1
                                  
IBM_2076:V7000_7:superuser> mkvdisk -mdiskgrp 1 -iogrp 0 -size 200
-unit gb -rsize 0% -autoexpand -name mdisk1_vdiskP2
                                     
IBM_2076:V7000_7:superuser> mkvdiskhostmap -force -host server03
mdisk1_vdiskP2
                
IBM_2076:V7000_7:superuser> mkvdiskhostmap -force -host server04
mdisk1_vdiskP2

Созданные диски будут иметь размер в 200 ГБ, но фактически ни один фрагмент не будет выделен в момент создания, как показывается аргументом -rsize 0%. Фрагменты будут выделяться по требованию, но хосты будут видеть эти тома так, как если бы они сразу имели полный объём. Это особенность "тонких" виртуальных дисков.

Поскольку мы планируем создать GPFS NSD-сервер, используя mdisk1_vdiskP2, этот виртуальный диск должен быть одновременно доступен для server03 и server04. За соблюдение этого требования отвечает опция –force в команде mkvdiskhostmap.

Когда привязка внутри системы Storwize V7000 будет выполнена, ОС AIX на серверах должна будет повторить сканирование, чтобы определить новый диск:

server03# cfgmgr -s                
server04# cfgmgr -s

Чтобы определить, какой hdisk OC AIX соответствует привязанному виртуальному диску, сначала потребуется получить список уникальных идентификаторов виртуальных дисков:

IBM_2076:V7000_7:superuser>lsvdisk disk1_vdiskP2
vdisk_UID 60050768028282292800000000000003

Затем мы можем использовать простой сценарий, показанный ниже, чтобы найти указанный vdisk_UID (идентификатор виртуального диска) среди дисков, идентифицированных операционной системой AIX:

*********************

#!/bin/ksh
 
USAGE="usage :
get_hdisk_ids.ksh <first hdisk number> <last hdisk
number>"
 if (($# != 2))
 then
 print "$USAGE"
 exit 1
 fi
                
 i=$1
 last=$2
               
 while ((i <= last))
 do
 print -n "hdisk$i"
 /usr/sbin/lsattr -El hdisk$i -a unique_id | awk '{print $2}'
 ((i += 1))
 done
*********************
                
server03# ./get_hdisk_ids.ksh 2 125 |grep
60050768028282292800000000000003
hdisk101 33213 60050768028282292800000000000003 04214503IBMfcp

Так, на сервере server03 виртуальный диск mdisk1_vdiskP2 будет распознан как hdisk101, на server04 этот же диск будет идентифицироваться как hdisk103.

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

IBM_2076:V7000_6:superuser>mkvdisk -mdiskgrp 1 -iogrp 0 -size 200
-unit gb -rsize 0% -autoexpand -name mdisk1_vdiskS1

IBM_2076:V7000_6:superuser>mkvdisk -mdiskgrp 1 -iogrp 0 -size 200
-unit gb -rsize 0% -autoexpand -name mdisk1_vdiskS2

IBM_2076:V7000_6:superuser> mkvdiskhostmap -force -host server05
mdisk1_vdiskS2

IBM_2076:V7000_6:superuser> mkvdiskhostmap -force -host server06
mdisk1_vdiskS2
server05# cfgmgr -s
server06# cfgmgr -s

На сервере server05 виртуальный диск mdisk1_vdiskS2 будет опознан как hdisk142, а на сервере server06 – как hdisk158.

Далее, с помощью файла DescFile, содержащего необходимые описания, мы создадим GPFS NSD-диск и файловую систему на главном кластере, как показано ниже:

server03# cat DescFile
hdisk101:server03,server04::dataAndMetadata::nsd_repvol:
 
server03# mmcrnsd -F DescFile                
 
server03# cp DescFile DescFileFS
server03# cat DescFileFS
# hdisk101:server03,server04::dataAndMetadata::nsd_repvol:
nsd_repvol:server03:server04:dataAndMetadata:4011::system
 
server03# mmcrfs /repvol repvolfs -F DescFileFS -B 64k
 
server03# mmmount repvolfs -N "server03,server04"

К данному моменту мы имеем созданную GPFS-систему, смонтированную в каталоге /repvol.

Первичная установка связи между основным и вспомогательным кластерами

Серверы в дополнительном кластере (server05, server06) должны быть доступны через IP-протокол серверам server03, server04, находящимся в основном кластере.

  1. Убедимся, что каталог /repvol смонтирован на обоих основных серверах:
    server03# mmlsnsd
    File system Disk name NSD servers
    ------------------------------------------ repvolfs nsd_repvol server03,server04 server03# mmlsmount repvolfs -L File system repvolfs is mounted on 2 nodes: 172.23.1.15 server04 172.23.1.14 server03

    Передадим информацию, относящуюся к файловой системе GPFS repvolfs, на серверы, расположенные на втором кластере


  2. server03# mmfsctl repvolfs syncFSconfig -n targetNodesFile
    server03# cat targetNodesFile
    server05
    server06

    Модули системы хранения Storwize V7000 на основном и вспомогательных кластерах должны иметь доступ друг к другу через расширенное SAN-устройство.
    IBM_2076:V7000_6:superuser>lspartnershipcandidate
    id configured name
    00000200A0208A2C no V7000_7             
                    
    IBM_2076:V7000_7:superuser>lspartnershipcandidate
    id configured name
    00000200A0A08A4A no V7000_6
                    
    IBM_2076:V7000_6:superuser>mkpartnership -bandwidth 2000 V7000_7
    
    IBM_2076:V7000_6:superuser>lspartnership
    id name location partnership bandwidth
    00000200A0A08A4A V7000_6 local
    00000200A0208A2C V7000_7 remote fully_configured 2000
                    
    IBM_2076:V7000_7:superuser>mkpartnership -bandwidth 2000 V7000_6
                    
    IBM_2076:V7000_7:superuser>lspartnership
    id name location partnership bandwidth
    00000200A0208A2C  V7000_7 local
    00000200A0A08A4A V7000_6 remote   fully_configured 2000
  3. Настроим GM-репликацию (global mirror – глобальное зеркалирование) между виртуальными дисками основного кластера и виртуальными дисками вспомогательного кластера:
    IBM_2076:V7000_7:superuser>mkrcrelationship -master mdisk1_vdiskP2 -aux 
    mdisk1_vdiskS1 -cluster V7000_6 -global
    IBM_2076:V7000_7:superuser>startrcrelationship rcrel1
  4. Создадим на вспомогательной системе хранения Storwize V7000 инкрементный FlashCopy-образ.
    IBM_2076:V7000_6:superuser> mkfcmap -source mdisk1_vdiskS1 -target
    mdisk1_vdiskS2 -copyrate 0 -cleanrate 0
  5. На основном кластере завершим и приостановим операции ввода/вывода в файловой системе /repvol:
    server03# mmfsctl repvolfs suspend
  6. На дополнительном кластере проверим, что репликация находится в состоянии постоянной синхронизации (consistent_synchronized):
    IBM_2076:V7000_6:superuser>lsrcrelationship
    id name
    master_cluster_id master_cluster_name master_vdisk_id
    master_vdisk_name aux_cluster_id aux_cluster_name aux_vdisk_id
    aux_vdisk_name primary consistency_group_id consistency_group_name
    state bg_copy_priority progress copy_type cycling_mode
    5  rcrel1 00000200A0A08A4A  V7000_7 5
    mdisk1_vdiskP2     00000200A0208A2C   V7000_6 5 mdisk1_vdiskS1 
    master  consistent_synchronized       
    50 global none
  7. Запустим FlashCopy-образ на вспомогательном кластере:
    IBM_2076:V7000_6:superuser> startfcmap -prep fcmap1
    IBM_2076:V7000_6:superuser>lsfcmap

    Состояние должно смениться на copying (копирование). Прогресс копирования должен оставаться нулевым для инкрементных FlashCopy-образов.
  8. Возобновим ввод/вывод в файловую систему /repvol на основном кластере:
    server03# mmfsctl repvolfs resume
  9. Обновим информацию о GPFS NSD-диске на дополнительном кластере:
    server05# mmchnsd "nsd_repvol:server05,server06"
    server05# mmmount repvolfs -o ro -N "server05,server06"

    К этому моменту во вспомогательном кластере уже можно получить доступ к данным в файловой системе /repvol.

Периодическое обновление данных на кластере

Когда оба кластера будут запущены, реплицируемые данные, используемые вторым кластером, можно обновить с помощью следующих действий

  1. Размонтировать каталог /repvol на дополнительном кластере:
    server05# mmumount repvolfs -N "server05,server06"
  2. Завершить и приостановить операции ввода/вывода в файловую систему /repvol на основном сайте:
      server03# mmfsctl repvolfs suspend

    Убедиться, что репликация на вспомогательном кластере находится в состоянии consistent_synchronized:
    IBM_2076:V7000_6:superuser>lsrcrelationship
    id name
    master_cluster_id master_cluster_name master_vdisk_id master_vdisk_name aux_cluster_id aux_cluster_name aux_vdisk_id aux_vdisk_name primary consistency_group_id consistency_group_name state bg_copy_priority progress copy_type cycling_mode 5 rcrel1 00000200A0A08A4A V7000_7 5 mdisk1_vdiskP2 00000200A0208A2C V7000_6 5 mdisk1_vdiskS1 master consistent_synchronized 50 global none
  3. Обновить инкрементный FlashCopy-образ на дополнительном кластере:
    IBM_2076:V7000_6:superuser>stopfcmap fcmap1
    IBM_2076:V7000_6:superuser>startfcmap -prep fcmap1
  4. Теперь можно возобновить ввод/вывод в файловую систему /repvol на основном кластере:
    server03# mmfsctl repvolfs resume
  5. Смонтировать /repvol на вспомогательном кластере:
    server05# mmmount repvolfs -o ro -N "server05,server06"

Доступ к данным со второго кластера при отключении основного кластера

Если основный кластер был отключен, следует размонтировать файловую систему /repvol на вспомогательном кластере:

server05# mmumount repvolfs -N "server05,server06"

Даже если репликация на вспомогательном сайте находилась в состоянии consistent_synchronized, это не означает, что целостность файлов на реплицируемом диске по-прежнему соблюдается. Когда основной кластер отключается (если это не намеренное отключение), некоторые файлы, которые записывались в файловую систему repvol, могут оказаться повреждёнными. С учётом того, что репликация данных происходит на физическом уровне (на уровне виртуальных дисков), то физическое содержимое (секторы) виртуальных дисков на основном и вспомогательных кластеров может совпадать, но логическое содержимое (файлы) может быть различно. Поэтому их целостность необходимо проверить перед использованием.

Обновим инкрементный FlashCopy-образ на вспомогательном кластере:

IBM_2076:V7000_6:superuser>stopfcmap fcmap1
IBM_2076:V7000_6:superuser>startfcmap -prep fcmap1

И смонтируем там же файловую систему /repvol:

server05# mmmount repvolfs -o ro -N "server05,server06"

Теперь перед использованием файлов, хранящихся в /repvol, следует проверить их целостность с помощью специфических инструментов для конкретных приложений. Например, если вы осуществляете репликацию архивных журналов с транзакциями базы данных, используйте инструменты из пакета СУБД для проверки целостности этих журналов.

Версии продуктов

При написании данной статьи были использованы следующие версии продуктов IBM:

  • AIX 7.1
  • GPFS 3.4.0.9
  • Storwize V7000 Unified storage – code_level 6.3.0.0

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=AIX и UNIX
ArticleID=934645
ArticleTitle=Интеграция файловой системы IBM GPFS с продуктами IBM Storwize V7000 Unified Global Mirror и IBM FlashCopy на операционной системе AIX
publish-date=06192013