среда, 26 декабря 2012 г.

Сравнение катастрофоустойчивых решений

На портале ict-online.ru опубликовали мою статью о сравнении ПО для построения катастрофоустойчивых решений от различных производителей. Для сравнения были выбраны следующие решения:
  • Microsoft Hyper-V Replica;
  • VMware vCenter Site Recovery Manager;
  • VMware vSphere Replication;
  • Veeam Backup & Replication.

Сравнение возможностей в виде таблицы:

Замечания и дополнения приветствуются.

Смена названия блога

Уважаемые читатели, если вы еще не заметили, то хочу сообщить, что я поменял основной адрес блога на blog.vmpress.org.

P.S. всех с наступающим!

понедельник, 12 ноября 2012 г.

Настройка Data ONTAP Edge (Часть II)

Продолжение статьи о настройке виртуального хранилища NetApp Data ONTAP Edge. Сегодня о том, как настроить синхронную репликацию между двумя хранилищами. Первая часть статьи тут.


Настройка DNS

Для корректной работы репликации важно правильно настроить службу разрешения имен на хранилищах и добавить все необходимые A-записи, которые позволяли бы разрешать имена как самих хранилищ, так и дополнительных сетевых интерфейсов. Это важно в случае, если в при настройке вы пользуетесь не конкретными IP адресами, а алиасами, вроде ontap02, ontap01-e0a и т.п.

Настройка исходного хранилища

 Все указанные ниже настройки выполняются на исходном хранилище (ontap01).

На исходном хранилище включите репликацию, используя команду:
options snapmirror.enable on
Укажите, какие хосты являются целевыми для репликации, и на какие IP адреса могут реплицироваться данные:
options snapmirror.access host=<HOST_IP1>,< HOST_IP2>[,...,< HOST_IPN>]
Например, чтобы разрешить репликацию на хранилище ontap02, который имеет два IP адреса (192.168.1.252 и 192.168.2.252), введите:
options snapmirror.access host=192.168.1.252,192.168.2.252
Просмотреть все опции, связанные с репликацией можно с помощью команды:
options snapmirror

Настройка целевого хранилища

Все указанные ниже настройки выполняются на целевом хранилище (ontap02).

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

При развертывании задайте другое имя (ontap02) и другой IP адрес (192.168.1.252).

После завершения, зайдите в консоль ВМ и с помощью команды setup задайте IP адрес на интерфейсе e0b (192.168.2.252). Остальные настройки можете задать по аналогии с ontap01. Не забудьте перезагрузиться (reboot).

Добавьте лицензии с помощью license add.

Создайте новый том, который будет использоваться для хранения реплицированных данных с основного хранилища, а также группу инициаторов, в которой будет находиться резервный сервер виртуализации на втором сайте (esx02). Также запустите службу iSCSI.
vol create vol1 -s none aggr0 10g
snap sched vol1 0 0 0
snap reserve vol1 0
iscsi start
igroup create -i -t vmware VMWARE_SERVERS iqn.2012-10.local.test:esx02
Учтите, что для корректной работы репликации, том на целевом хранилище должен быть такого же размера или больше, чем том на исходном хранилище. Проверить размер тома можно с помощью команды:
vol size <имя_тома>
Включите репликацию на целевом хранилище:
options.snapmirror.enable on 
Теперь вам потребуется отредактировать файл snapmirror.conf (vol/vol0/etc/snapmirror.conf), содержащий информацию о настройках репликации. В данном файле описывается перечень реплицируемых томов, тип репликции (синхронная, асинхронная), расписание репликации (для асинхронной репликации), максимальная скорость репликации, использование сжатия, интерфейсы, по которым передаются данные и многое другое.

Формат конфигурации выглядит следующим образом:
source destination arguments schedule
, где source - исходная пара хранилище:том, например (ontap01:vol1);
destination- целевая пара  пара хранилище:том, например (ontap02:vol1);
arguments - дополнительные аргументы, такие как ограничение максимальной скорости передачи данных, использование сжатия и т.п. Если дополнительные аргументы не указывается, то ставится прочерк "-".
schedule- расписание репликации (для асинхронной репликации), либо параметр "sync" (для синхронной репликации).

Например, для синхронной репликации vol1 с хранилища ontap01 на хранилище ontap02, конфигурация будет выглядеть следующим образом:
ontap01:vol1 ontap02:vol1 - sync
Однако, по умолчанию, передача данных будет выполняться по IP адресам, которые хранилища получили, разрешив имена ontap01 и ontap02, т.е. 192.168.1.251 и 192.168.1.252. Для использования второй пары IP адресов (192.168.2.251 и 192.168.2.252) требуется добавить в файл строку следующего формата.
name = mode(source_ip_addr1, dest_ip_addr1)(source_ip_addr2, dest_ip_addr2)
где, name - имя исходного хранилища, например ontap01;
mode - режим использования пар IP адресов: failover (использование одной пары в качестве основной, а второй в качестве резервной), или multi (использование обоих пар одновременно с балансировкой нагрузки);
source_ip_addrN - IP адрес интерфейса исходного хранилища;
dest_ip_addrN - IP адрес интерфейса целевого хранилища.

Например:
ontap01=failover(192.168.2.251, 192.168.2.252)(192.168.1.251, 192.168.1.252)
задает конфигурацию, при которой пара IP адресов из 192.168.2.0 подсети будет использоваться для передачи данных репликации, а пара IP адресов из 192.168.1.0 подсети будет использоваться как резервная на случай сбоя первой пары.

Таким образом, файл конфигурации snapmirror.conf будет выглядеть следующим образом:
ontap01=failover(192.168.2.251, 192.168.2.252)(192.168.1.251, 192.168.1.252)
ontap01:vol1 ontap02:vol1 - sync
Как отредактировать файл snapmirror.conf? Есть несколько вариантов.

Во-первых, подключить корневой том (vol0) по протоколу NFS, как было описано в предыдущей статье, и использовать текстовый редактор, поддерживающий переносы в стиле *nix, например, Notepad++.

Во-вторых, с помощью команды wrfile.
wrfile <путь_к_файлу>
Например,
wrfile /vol/vol0/etc/snapmirror.conf
Команда позволит вам отредактировать указанный файл прямо из консоли. После окончания редактирования файла нажмите CTRL + c. Учтите, что команда полностью перезаписывает файл.

Если вам требуется добавить строку в существующий файл, используйте команду:
wrfile -a <путь_к_файлу> <добавляемая_строка> 
Прочитать данные из существующего файла можно с помощью команды:
rdfile /vol/vol0/etc/snapmirror.conf

Запуск и проверка репликации

После завершения настроек запустите репликацию с целевого хранилища. Перед запуском репликации запретите доступ к тому, используя команду:
vol restrict <имя_тома>
Например:
vol restrict vol1 
Запуск репликации осуществляется командой:
 snapmirror initialize -S <source> <destination> 
, где: <source> - исходная пара хранилище:том, например (ontap01:vol1);
<destination>- целевая пара  пара хранилище:том, например (ontap02:vol1)

Для запуска репликации тома vol1 с хранилища ontap01 на хранилище ontap02 выполните:
snapmirror initialize -S ontap01:vol1 ontap02:vol1
Для проверки работы репликации используйте команду:
snapmirror status
Сразу после запуска репликации начнется передача данных с исходного тома на целевой.

После того, как все данные будут переданы, репликация на короткое время перейдет в состояние idle, а затем in-sync, означающее, что синхронная репликация работает.

 Тестирование с остановкой репликации/плановый перенос

Данный вариант может применяться для проверки корректности настроек репликации и тестового восстановления инфраструктуры в резервном сайте.

Для начала скопируйте на LUN в основном сайте какую-либо тестовую ВМ или файлы, после чего остановите репликацию, введя команду на целевом хранилище:
snapmirror quiesce <имя_тома>
Например:
snapmirror quiesce vol1
Разорвите пару:
snapmirror break <destination>
<destination> - целевая пара  пара хранилище:том.

Например:
snapmirror break ontap02:vol1
После разрыва пары реплицированный LUN на целевом хранилище станет доступен для чтения/записи.

Презентуйте реплицированный LUN серверу ESXi во втором сайте:
lun map /vol/vol1/lun0 VMWARE_SERVERS 0
На сервере ESXi подключитесь к целевому хранилищу и выполните сканирование для обнаружения новых томов.

ESXi автоматически не монтирует реплицированные datastore'ы. Поэтому требуется смонтировать хранилище вручную. Для этого выберите Configuration -> Storage -> Add Storage. Из списка дисков выберите реплицированный LUN. Для монтирования с сохранением файловой системы и всех данных выберите один из двух вариантов: Keep the existing signature или Assign a new signature.

Для реплицированного хранилища будет сгенерировано новое имя.

Теперь вы можете зайти на реплицированный Datastore, зарегистрировать и запустить ВМ для проверки.

После завершения тестирования для возобновления репликации разрегистрируйте тестовую ВМ, отключите реплицированный том и выполните ресинхронизацию на целевом хранилище с помощью команды:
snapmirror resync <имя_тома>
Например:
snapmirror resync vol1
На вопрос системы, хотите ли вы начать репликацию с последнего снапшота, введите: yes.

Через некоторое время все изменения будут синхронизированы и пара перейдет в состояние in-sync.

Схожим образом можно осуществить запланированный перенос инфраструктуры ВМ из основного сайте в резервный. Алгоритм переноса выглядит следующим образом:
  1. Выключите все ВМ на реплицируемом хранилище в основном сайте.
  2. Разрегистрируйте все ВМ и отмонтируйте хранилище.
  3. Дождитесь, пока завершится репликация (в случае использования асинхронной репликации).
  4. Остановите репликацию (snapmirror quiesce) и разорвите пару (snapmirror break) из консоли на целевом хранилище.
  5. Презентуйте реплицированный LUN  серверу виртуализации в резервном сайте, используя команду lun map (если это не было сделано ранее).
  6. Подключите и выполните обнаружение новый LUN на сервере ESXi (если это не было сделано ранее).
  7. Смонтируйте хранилище, назначив им новый идентификатор.
  8. Переименуйте хранилище, вернув ему старое именя.
  9. Зарегистрируйте и запустите все ВМ с реплицированного хранилища.
  10. Если вы не планируете больше выполнять репликацию с основного хранилища на резервное, отключите пару, используя команду:
    snapmirror release <имя тома> <destination>, например: snapmirror release vol1 ontap02:vol1
  11. Также удалите или закомментируйте  конфигурацию из файла snapmirror.conf.
Примечание: Если вы используете данный вариант для тестирования, то учтите, что он имеет один существенный недостаток - на время теста данные  с основного хранилища не реплицируются на резервное, поэтому если в этот момент произойдет сбой, есть риск потери определенного объема данных.

Тестирование без остановки репликации

В качестве альтернативного варианта тестирования репликации существует возможность создания на основе реплицированного тома flexclone том, доступный на чтение/запись, с последующим монтированием LUN'а с этого тома и проверкой работы репликации.

Создать flexclone том на целевом хранилище можно следующей командой:
vol clone create <vol-name> [-s none | file | volume] [-f] -b <parent_flexvol> [<parent_snapshot>]
, где  <vol-name> - имя для нового тома;
[-s none | file | volume]- резервирование пространства под создаваемый том;
-b <parent_flexvol>- имя тома, из которого будет создан клон;
[<parent_snapshot>]- снапшот тома, из которого будет создан клон.

Например:
vol clone create vol2 -s none -b vol1 ontap02(2147483976)_vol1.308
создаст flexclone том с именем vol2 из снапшота реплицированного тома vol1.

Посмотреть список доступный снапшотов для тома можно с помощью команды:
snap list
После создания flexclone тома, LUN на нем будет в состоянии offline.

Для того, чтобы иметь возможность смонтировать LUN, переведите его в режим online, выполнив команду:
lun online <путь_к_lun>
 Например:
lun online /vol/vol2/lun0
После этого, вы сможете смонтировать LUN с помощью команды lun map.

После проверки репликации, отключите flexclone том, используя команду:
vol offline <имя_тома>
Например:
vol offline vol2
А затем удалите flexclone том, используя команду:
vol destroy <имя_тома>
Например:
vol destroy vol2

Аварийно переключение на резервное хранилище

Итак, предположим, что настал тот неприятный момент, когда первый сайт лежит в руинах и основное хранилище приказало долго жить. Какие шаги следует предпринять для восстановления инфраструктуры во втором сайте?

План такой:
  1. Смиритесь с потерей, поплачьте, если это поможет.
  2. Остановите репликацию (snapmirror quiesce) и разорвите пару (snapmirror break)  из консоли на целевом хранилище. 
  3. Презентуйте реплицированный LUN серверу виртуализации в резервном сайте, используя команду lun map (если это не было сделано ранее).
  4. Подключите и выполните обнаружение нового LUN'а на сервере ESXi (если это не было сделано ранее).
  5. Смонтируйте хранилище, назначив ему новый идентификатор.
  6. Переименуйте хранилище, вернув ему старое имя.
  7. Зарегистрируйте и запустите все ВМ с реплицированного хранилища.
  8. Если хранилище на первом сайте полностью отказало, и вы не планируете больше выполнять репликацию с основного хранилища на резервное, отключите пару, используя команду:
    snapmirror release <имя тома> <destination>, например: snapmirror release vol1 ontap02:vol1
  9. Также удалите или закомментируйте конфигурацию из файла snapmirror.conf.

Настройка возможности репликации в обратном направлении

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

Репликация в обратную сторону настраивается аналогичным образом.

На хранилище в резервном сайте (ontap02) добавьте IP адреса хранилища основного сайта:
options snapmirror.access host=192.168.1.251,192.168.2.251
На хранилище в основном сайте (ontap01) отредактируйте файл snapmirror.conf:
ontap02=failover(192.168.2.252, 192.168.2.251)(192.168.1.252, 192.168.1.251)
ontap02:vol1 ontap01:vol1 - sync
На хранилище в основном сайте выполните команды:
vol restrict vol1 
snapmirror initialize -S ontap02:vol1 ontap01:vol1
Проверьте статус репликации командой snapmirror status.

Заключение

Механизм репликации в Data ONTAP является крайне гибким и функциональным. Он позволяет реплицировать данные как в синхронном, так и в асинхронном режиме, ограничивать полосу пропускания, использовать несколько интерфейсов для репликации, тестировать план восстановления без необходимости остановки репликации, перенастраивать репликацию в обратную сторону и многое другое.

Однако, далеко не всегда работа из командной строки является приемлемым вариантом. В больших инфраструктурах, насчитывающих сотни виртуальных машин, а также при необходимости уменьшения времени простоя, для автоматизации операции восстановления ВМ на резервном сайте может пригодиться такой продукт, как VMware Site Recovery Manager. VMware SRM позволяет заранее настроить процедуры тестирования, переноса или восстановления ВМ в резервном сайте, избавив администратора от необходимости работы с консолью, ограничившись лишь несколькими щелчками мыши в интерфейсе vSphere Client. Более подробно о SRM вы можете прочитать тут.

вторник, 23 октября 2012 г.

Настройка NetApp Data ONTAP Edge (Часть I)

Наконец-то выдалось свободное время и я смог покрутить NetApp Data ONTAP Edge - хранилище на базе ОС Data ONTAP версии 8.1.1, работающее внутри ВМ VMware vSphere и обладающее многими возможностями своих взрослых коллег - NetApp FAS и V-Series.

Введение

Data ONTAP Edge может стать неплохим решением для небольших организаций или филиалов крупных компаний, где нет возможности установить выделенную аппаратную систему хранения, но требуется доступ к данным по различным протоколам (iSCSI, NFS, SMB),  а также могут пригодиться всевозможные технологии защиты данных (репликация, снапшоты, клоны).

Однако, если вы планируете использовать Data ONTAP Edge в качестве чего-то большего, то учтите, что Data ONTAP Edge имеет ограничение на максимальный размер хранилища - 5 ТБ (триальная версия имеет ограничение в 2 ТБ). Кроме того, в Data ONTAP Edge отсутствует функционал вроде RAID-DP, SyncMirror, HA Pair, MetroCluster, Cluster Mode и презентации LUN'ов по Fibre Channel или FCoE.

Важным отличием Data ONTAP Edge от ONTAP Simulator является то, что Data ONTAP Edge не эмулирует дисковую подсистему хранилища NetApp FAS, позволяя создавать агрегаты только с RAID уровня 0 (никаких RAID4 и RAID-DP). В этом плане хранилище Data ONTAP Edge ближе к виртуализатору NetApp V-Series, которому презентованы внешние LUN'ы для хранения на них данных, хотя в случае с Data ONTAP Edge презентация выполняется не по Fibre Channel, а через виртуальный SAS адаптер.

Загрузить триальную версию можно с сайта: http://www.netapp.com/data-ontap-edge-eval

После прохождения регистрации становится доступен для загрузки .ova файл с ВМ Data ONTAP Edge, а также OnCommand System Manager под Windows и Linux.  Начиная с версии 8.1, OnCommand System Manager является заменой штатному FilerView и позволяет управлять несколькими хранилищами NetApp из Web-интерфейса.

Пару слов о OnCommand System Manager. Я немного поработал с ним и одно могу сказать точно - он гораздо красивее и приятнее, нежели FilerView.

Однако, в текущей версии 2.0.2 есть несколько недостатков, например, из Web-интерфейса нельзя настраивать сетевые адаптеры и DNS серверы.

Пример развертывания

В качестве варианта использования Data ONTAP Edge я хочу привести пример развертывания двух хранилищ в двух сайтах, работающих в режиме active-passive с репликацией данных с основного сайта на резервный.

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

Хосты ESXi подключаются по протоколу iSCSI каждый к своему хранилищу. Каждое хранилище Data ONTAP Edge использует два виртуальных сетевых интерфейса: первый для управления хранилищем и доступа по iSCSI, второй - для репликации данных между хранилищами.

Для упрощения конфигурации я буду использовать одинаковые подсети для первого и второго сайта: 192.168.1.0/24 -для управления и iSCSI, 192.168.2.0/24 - для репликации, а также одну единственную группу портов VM Network на виртуальном коммутаторе ESXi.
Общая схема приведена на рисунке:


Установка и настойка Data Ontap Edge

Процедура установка для Data ONTAP Edge проходит также как и для других virtual appliances. Из интерфейса VMware vSphere выполните импорт .OVF файла (File -> Deploy OVF Template).

В процессе установки примите лицензионное соглашение, задайте имя ВМ и ее расположение. По умолчанию, ВМ создается в thick формате, однако в тестовых целях ничто не мешает использовать тонкие (thin) диски. Укажите сеть для подключения интерфейсов ВМ. ВМ создается с 4-мя виртуальными адаптерами: e0a, e0b, e0c и e0d, все они подключаются к одной и той же сети, которую вы выберите, однако ничто не мешает изменить привязку сетевых адаптеров в свойствах ВМ после завершения работы мастера.

На вкладке Properties задайте имя хоста, IP адрес для интерфейса e0a, маршрутизатор по умолчанию, пароль для учетной записи root и размер диска в ГБ (минимальный размер диска - 50 ГБ, максимальный - 2 ТБ, диска размером 100 ГБ будет достаточно для тестовых целей). На этом диске система создаст корневой агрегат (root aggregate) на все доступное дисковое пространство  и корневой том (root volume) размером 30 ГБ.

После завершения работы мастера запустите ВМ. Дождитесь завершения загрузки и появления приглашения входа в систему.

Вы можете настраивать систему с помощью консоли vSphere Client, однако более удобным вариантом является управление через SSH. Просто подключитесь по IP адресу, который вы задали в процессе развертывания, используя учетную запись root и пароль, заданный в мастере настройки.

Для дальнейшей работы вам потребуется настроить дополнительные параметры: IP адрес оставшихся сетевых интерфейсов, адрес DNS сервера, часовой пояс и т.п. Сделать это можно как с помощью интерактивной команды setup, так и отдельным командами.

 Ниже приведен пример настройки через setup:
setup
Are you sure you want to continue? [yes] <Нажмите Enter>
Please enter the new hostname [ontap01]: <Нажмите Enter или введите новое имя>
Do you want to enable IPv6? [n]: <Нажмите Enter>
Do you want to configure interface groups? [n]: <Нажмите Enter>
Please enter the IP address for Network Interface e0a [192.168.1.251]: <Нажмите Enter или введите новый IP адрес>
Please enter the netmask for Network Interface e0a [255.255.255.0]: <Нажмите Enter>
Please enter media type for e0a [auto]: <Нажмите Enter>
Please enter flow control for e0a [full]: <Нажмите Enter>
Do you want e0a to support jumbo frames? [n]: <Нажмите Enter>
Please enter the IP address for Network Interface e0b []: <Введите новый IP адрес, например: 192.168.2.251>
Please enter the netmask for Network Interface e0b [255.255.255.0]: <Нажмите Enter>
Please enter media type for e0b [auto]: <Нажмите Enter>
Please enter flow control for e0b [full]: <Нажмите Enter>
Do you want e0b to support jumbo frames? [n]: <Нажмите Enter>
Please enter the IP address for Network Interface e0c []: <Нажмите Enter>
Please enter the IP address for Network Interface e0d []: <Нажмите Enter>
Would you like to continue setup through the web interface? [n]: <Нажмите Enter>
Please enter ther name or IP address of the IPv4 default gateway [192.168.1.1]: <Нажмите Enterили введите новый IP адрес>
Please enter the name or IP address of the administration host: <Нажмите Enterили введите имя или IP адрес рабочей станции, с которой вы планируете управлять хранилищем>
Please enter timezone [GMT]: <Нажмите Enter или введите имя временной зоны, в которой располагается хранилище, например: Europe/Moscow или Etc/GMT-4 для Москвы>
Where is the filer located? []: <Нажмите Enter или введите описание местоположения хранилища, например, Test lab>
Enter the root directory for HTTP files [/vol/vol0/home/http]: <Нажмите Enter>
Do you want to run DNS resolver? [n]:  <Введите y или yes>
Please enter DNS domain name []: <Введите имя домена, например: test.local>
Please enter the IP address for first nameserver []: <Введите IP адрес DNS сервера для разрешения имен>
Do you want another nameserver? [n]: <Нажмите Enter>
Do you want to run NIS client? [n]: <Нажмите Enter>
Do you want to configure the Shelf Alternate Control Path Management interface for SAS shelves [n]: <Нажмите Enter>

После завершения работы мастера перезагрузите хранилище, выполнив команду:
reboot
После перезагрузки проверьте, что параметры корректно применились, используя команду:
ifconfig -a


Настройка времени и даты

Для проверки корректности настроек времени и временной зоны используйте команды:
date
timezone 

При необходимости измените время, используя команду date со следующими параметрами:
date [[[[CC]yy]mm]dd]hh]mm[.ss]]
, где CC - первые две цифры года;
yy - последние две цифры года;
mm - порядковый номер месяца (от 01 до 12);
dd - порядковый номер дня месяца (от 01 до 31);
hh - час (от 01 до 24);
mm - минута (от 00 до 59);
ss - секунда (от 00 до 59).

Например, для установки даты 21 октября 2012 года и времени 22 часа, 16 минут, 30 секунд, введите:
date 201210212216.30
Для установки временной зоны используйте команду timezone со следующими параметрами:
timezone [timezone]
, где timezone - название временной зоны, например: Europe/Moscow, Etc/GMT+1, CET, UTC и пр.

Полный список временных зон расположен в корневом томе, в каталоге "/vol/vol0/etc/zoneinfo".

Добавление лицензий

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

Посмотреть список лицензий можно с помощью команды:
license

Лицензии представляют собой ключи длиной 7 символов. Активируются лицензии с помощью команды:
license add [ключ]
При необходимости, можно активировать несколько лицензий за раз, разделяя ключи пробелами.

Подключение корневого тома по NFS

Data ONTAP имеет много общего с ОС семейства *nix, многие настройки могут выполняться путем изменения конфигурационных файлов, расположенных в каталоге /etc на корневом томе (/vol/vol0). Встроенный механизм чтения и редактирования файлов в виде команд rdfile и wrfile не очень удобен для частого изменения файлов. Поэтому гораздо более удобным вариантом будет монтирование корневого тома по протоколу NFS и использование привычных инструментов администратора (под Windows рекомендую использовать текстовый редактор Notepad++ или любой другой, воспринимающий переносы строк в стиле *nix).

Посмотреть все NFS экспорты на хранилище можно с помощью команды:
exportfs

Обратите внимание, что, по умолчанию,   доступ к корневому тому на чтение и запись с правами root имеет только административная станция - компьютер, чей IP адрес вы задали в процессе настройки с помощью команды setup.

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

Сначала удалите некорректно настроенный экспорт:
exportfs -z <имя_экспорта>
Например:
exportfs -z /vol/vol0
Затем добавьте экспорт с нужными параметрами с помощью команды:
exportfs -p <параметры> <имя_экспорта>
Например:
exportfs -p sec=sys,ro,rw=192.168.1.2:192.168.1.7,root=192.168.1.2:192.168.1.7,nosuid /vol/vol0

В качестве значений для параметров rw= и root= вы можете указать одиночный IP адрес или DNS имя хоста, например, 192.168.1.2 или host.test.local, IP подсеть, например, 192.168.1.0/24, несколько адресов или DNS имен, разделенных ":", например, 192.168.1.2:192.168.1.3:192.168.1.10:bob.test.local  и т.п.

Для подключения NFS шары к компьютеру с Windows Vista или Windows 7 выполните следующие действия.

Установите клиент NFS (Services for NFS -> Client for NFS) из панели добавления/отключения компонентов Windows (Control Panel -> Programs and Features -> Turn Windows features on or off).

По умолчанию клиент Windows подключается к любой NFS шаре в гостевом режиме (Uid=-2 и Gid=-2) и вы можете только просматривать файлы. Поэтому если у вас не развернута служба каталога Active Directory или служба User Name Mapping, то вам потребуется отредактировать реестр. Откройте regedit, найдите ключ HKLM\SOFTWARE\Microsoft\ClientForNFS\CurrentVersion\Default. Создайте два параметра типа DWORD с именами AnonymousUid и AnonymousGid и установите значение обоих параметров в 0.

Перезапустите службу клиент NFS, выполнив в консоли CMD:
nfsadmin client stop
nfsadmin client start 
Теперь вы можете подключить NFS шару:
mount <полный путь к NFS шаре> <буква диска>
Например:
mount \\192.168.1.251\vol\vol0 Z:

После этого вы сможете просматривать и редактировать любые файлы на корневом томе хранилища.

Создание томов на хранилище

После завершения первоначальных настроек приступим к созданию дополнительных томов для размещения LUN'ов, которые будут презентоваться хостам виртуализации.

При развертывании ВМ, система создает один агрегат (aggr0) на все доступное дисковое пространство и корневой том (vol0) размером 30 ГБ.

Посмотреть информацию о доступных агрегатах можно с помощью команды:
aggr status
Увидеть занятое и свободное место на агрегатах можно с помощью команды:
aggr show_space

Создайте новый том:
vol create <vol-name> [-s none | file | volume] <hosting-aggr-name> <size>[k|m|g|t]
, где:  <vol-name> - название нового тома;
[-s none | file | volume] - опция резервирования дискового пространства под том (например при -s none создается тонкий том);
<hosting-aggr-name>- имя агрегата, на котором создается том;
<size>- размер тома в КБ, МБ, ГБ или ТБ.

Например, команда:
vol create vol1 -s none aggr0 10g
создаст тонкий том размером 10 ГБ с именем vol1 на агрегате aggr0.

Посмотреть доступные тома можно с помощью команды:
vol status
Посмотреть место, занимаемое томами можно с помощью команды:
df
Для всех томов по умолчанию настраивается создание снапшотов по расписанию, а также резервируется 5% дискового пространства. В тестовой среде можно отключить эти настройки, чтобы сэкономить немного дискового пространства, используя команды:
snap sched vol1 0
snap reserve vol1 0
, где vol1 - имя тома.

Создание и презентация LUN

Для начала включите протокол iscsi на хранилище с помощью команды:
iscsi start
Для презентации LUN'ов хранилище Data ONTAP использует т.н. группы инициаторов (Initiator Group), содержащие IQN адреса клиентов (для iSCSI) или WWN (для FC).

Создайте новую группу инициаторов:
igroup create -i -t <ostype> <initiator_group> [<node> ... ]
, где -i - тип группы (для iSCSI);
-t <ostype> - тип ОС на клиентах (windows, linux, vmware и т.п.);
<initiator_group> - имя группы инициаторов;
[<node> ... ] - IQN имена клиентов, разделенных пробелом. 

Например:
igroup create -i -t vmware VMWARE_SERVERS iqn.2012-10.local.test:esx01
создает группу инициаторов VMWARE_SERVERS и добавит туда одно IQN имя  iqn.2001-01.com.vmware:esxa

При необходимости добавления дополнительных IQN имен вы можете использовать команду:
igroup add <initiator_group> [<node> ... ]
Посмотреть доступные группы инициаторов вы можете с помощью команды:
igroup show
Для создания LUN используйте команду:
lun create -s <size> -t <ostype> [ -o noreserve ] <lun_path>
, где: -s <size> - размер LUN'а в КБ, МБ, ГБ, ТБ;
-t <ostype> - тип ОС на клиентах (windows, linux, vmware и т.п.);
[ -o noreserve ]- опция резервирования дискового пространства под LUN (например при -o noreserve создается тонкий том);
<lun_path>- полный путь к создаваемому LUN.

Например:
lun create -s 5g -t vmware -o noreserve /vol/vol1/lun1
Для просмотра созданных LUN'ов используйте:
lun show
Презентовать созданный LUN можно с помощью команды
lun map <lun_path> <initiator_group> [ <lun_id> ]
, где  <lun_path> - полный путь к созданному LUN;
<initiator_group> - имя группы инициаторов;
[ <lun_id> ]- номер LUN'а, под которым он будет презентован клиентам.

Например:
lun map /vol/vol1/lun1 VMWARE_SERVERS 0
Презентует /vol/vol1/lun1 под LUN ID 0 группе инициаторов VMWARE_SERVERS.

Посмотреть на презентованные LUN'ы можно с помощью команды:
lun show -m

Посмотреть и изменить IQN имя iSCSI инициатора на хосте ESXi можно из консоли vSphere Client (Home -> Host and Clusters -> Host -> Configuration -> Storage Adapter -> iSCSI Adapter -> Properties -> General -> Configure... -> iSCSI Name).

Для подключения тома к серверу ESXi откройте свойства iSCSI адаптера, перейдите на вкладку Dynamic Discovery и с помощью кнопки Add... добавьте IP адрес хранилища (например: 192.168.1.251), затем нажмите OK. ESXi предложит произвести поиск новых устройств, согласитесь. Через пару секунд новый LUN появится в списке доступных устройств.

Увеличение дискового пространства хранилища и агрегата

Если места, указанного при начальном развертывании хранилища, недостаточно, то вы можете добавить в ВМ дополнительные диски и создать на них новые агрегаты, либо добавить эти диски в существующий агрегат. Для второго варианта выполните следующие действия.

После добавления диска и загрузки ВМ потребуется назначить владельца для данного диска с помощью команды:
disk assign <disk_name>
, где <disk_name>- имя неназначенного диска.

Например:
disk assign 0a.1
Определить имя неназначенного диска можно с помощью команды:
disk show -n
Добавить диск в существующий агрегат можно с помощью команды:
aggr add <aggr-name> -d <disk-name>
, где <aggr-name> - имя агрегата;
-d <disk-name> - имя добавляемого диска.

Например:
aggr add aggr0 -d 0a.1
Дождитесь, пока хранилище закончит добавление диска в агрегат. Проверить статус операции можно с помощью команды:
aggr status

Добавление места на томе

Если у вас заканчивается место на томе, вы можете расширить том за счет свободного места агрегата, используя команду:
vol size <vol-name> +<size>[k|m|g|t]
, где <vol-name>- имя тома;
+<size>[k|m|g|t]- размер дискового пространства в КБ,МБ,ГБ,ТБ, которое требуется добавить к тому.

Например:
vol size vol0 +10g
добавит 10 ГБ к тому vol0.

Добавление места на LUN'е

 Если у вас заканчивается место на LUN'e, вы можете расширить LUN за счет свободного места тома, используя команду:
lun resize <lun_path> +<size>
, где <lun_path>- путь к LUN'у;
+<size>- размер размер дискового пространства в КБ,МБ,ГБ,ТБ, которое требуется добавить к LUN'у.

Например:
lun resize /vol/vol0/lun1 +5g
увеличит lun1 на 5 ГБ.

Заключение

На сегодня все, во второй части описана настройка второго хранилища и репликация между двумя хранилищами.

воскресенье, 14 октября 2012 г.

VMworld 2012. День 4

Заключительная часть рассказа о конференции VMworld 2012 Europe. Предыдущие части: раз, два, три.

Четвертый день начался с доклада об организации катастрофоустойчивых решений: растянутые кластеры или VMware SRM, как и когда выбирать одно, другое или все вместе. Выступающие, Chad Sakac (тот самый, в представлении не нуждается) и Joel Kaufman (тим-лидер NetApp), озвучили ряд очень важных тезисов, о которых ни в коем случае не следует забывать. Например, при организации растянутого кластера следует помнить, что обоими сайтами управляет один vCenter, поэтому требуется обеспечить его надежность и доступность, что требуется организация общего адресного пространства, что в кластере СХД должна решаться проблема split-brain, что желательно, чтобы хосты обращались к локальному хранилищу, а не удаленному, что расстояния между ЦОД могут быть слишком большими для синхронной репликации данных.

Что же касается исходного вопроса: что лучше внедрять - растянутый кластер или VMware SRM, то ответ выступающих был - лучше и то, и другое. Так надежнее. :-)

В конце выступающие привели информацию о количестве внедрений растянутых метро кластеров у EMC и NetApp. У EMC около 500 внедрений на VPLEX, у NetApp:

Что тут сказать - любят в Германии NetApp. :-)

Следующий доклад был посвящен обзору VCE Vblock Systems. Ведущий - Trey Layton (VCE, вице-президент).

Vblock - это такая здоровская штука, которая получается путем объединения серверов и сетевого оборудования Cisco, систем хранения данных EMC и ПО VMware. Все это вместе, запихивается в одну стойку (или не одну), конфигурируется на заводе, привозится Заказчику, буквально за пару дней подключается к текущей инфраструктуре и сдается "под ключ".

За два года продаж, из стартапа, созданного усилиями трех гигантов, VCE превратилась к компанию с капитализацией 3 млрд. $.

Vblock представлен двумя продуктами - Vblock System 700 - решение для крупных заказчиков, а также Vblock System 300 - для малого и среднего бизнеса.

Сильной стороной Vblock является возможность интеграции Vblock с большим количеством продуктов и решений трех вендоров, что позволяет управлять всеми компонентами современной ИТ-инфраструктуры.

В ближайшем будущем VCE планирует обновить и расширить линейку продуктов, в частности добавить Vblock для филиалов, во многом схожий с Flexpod Express, о котором я писал ранее.

На оставшиеся доклады я забил, пойдя на выставку.

В этом году компания Symantec решила сэкономить и заменила живых девушек голографическими. Очень правильное решение - зарплату платить не надо, работать может целый день без перерыва на обед, общительная, если что-то не понял - повторит.

Я пообщался с представителем компании и поинтересовался - в чем, по его мнению заключается преимущество Symantec Backup Exec над Veeam Backup при резервном копировании виртуальных сред.

Если отбросить маркетинг, то преимущества Backup Exec над Veeam B&R:
  • Дедупликация бекапов работает не в пределах одного задания, а на всем диске с данными.
  • Возможность сохранять бекапы на ленту.
  • Возможность бекапить физические серверы, после чего восстанавливать их в виде виртуальных машин.
  • Есть агенты для Oracle DB, Microsoft Sharepoint, которые можно установить внутри ВМ для консистентного бекапа и гранулярного восстановления прямо из консоли Backup Exec.
Но чтобы быть максимально объективным, я пошел на стенд Veeam спросить об их конкурентных преимуществах на Backup Exec. Получилось как-то так:
  • Поддержка forever incremental (synthetic) резервного копирования виртуальных машин для уменьшения времени резервного копирования.
  • Возможность создавать консистентные бекапы приложений внутри ВМ без необходимости установки в гостевой ОС агента резервного копирования.
  • Поддержка репликации ВМ по расписанию внутри или за пределами сайта.
  • Возможность запускать ВМ прямо с хранилища резервных копий для уменьшения времени восстановления.
  • Возможность автоматизированный проверки резервной копии ВМ.
  • Перенос ВМ с одного хранилища на другое с минимальным простоем, даже при отсутствии поддержки Storage vMotion.
Так что не все так однозначно, особенно с учетом появления в vSphere 5.1 новой СРК vSphere Data Protection.

Компания QNAP стремится освоить новый для себя рынок Entry систем хранения, предлагая решения схожие по функционалу с, например, HP StorageWorks P2000i, но по меньшей цене. К плюсам хранилищ можно отнести возможность установки собственных дисков из списка поддерживаемых, поддержка различных протоколов доступа к данным: iSCSI, NFS, SMB, FTP, WebDAV. В старших моделях хранилищ QNAP используются процессоры Xeon, а также есть слоты расширения для установки 1 и 10 Гбит адаптеров, так что по заверениям представителя компании проблем с производительностью быть не должно.

С другой стороны, отсутствие поддержки дисков с SAS интерфейсом, ограниченные возможности по расширению (не более 12 дисков в старшей модели), а также только один контроллер на систему хранения не позволяют им в полной мере конкурировать с СХД HP или IBM. Посмотрим, что из этого получится.

Следующим на очереди стал стенд другого производителя систем хранения - Nimble Storage. Архитектура СХД Nimble Storage строится на использовании flash дисков для кэширования операций чтения с хранилища, что позволяет добиться существенного прироста IOPS по сравнению с другими решениями на рынке. Клиенты подключаются к хранилищу через 1 или 10 Гбит/с порты, используя протокол iSCSI.

СХД имеет двухконтроллерную конфигурацию, работающих в режиме active-standby. На выбор доступно несколько моделей, отличающихся производительностью, максимальным объемом хранилища, количеством поддерживаемых дисков, и, главное, ценой.

Приятным моментом является то, что все функции хранилища, такие как: тонкие диски, снапшоты (в том числе и VSS консистентные снапшоты), клоны, репликация, сжатие данных, поддержка VMware SRM и т.д. не требуют приобретения дополнительных лицензий и доступны "из коробки".


На выставке также присутствовала компания Neverfail, чье ПО для обеспечения высокой доступности сервера vCenter VMware продает под именем vCenter Heartbeat. Сложно переоценить, насколько важным может быть сервер vCenter в современной виртуальной инфраструктуре. Но в защите нуждается не только он сам, но также сервер SQL, на котором размещены базы vCenter. На сегодняшний день лишь vCenter Heartbeat является полностью поддерживаемым продуктом для организации такого типа защиты.

На стенде Red Hat раздавали прикольные красные шапки, а также рассказывали о том, что не VMware единым жива индустрия виртуализации.

Так что, если по какой-то причине вы не любите коммерческие гипервизоры с закрытым исходным кодом, но все же хотите использовать решение, поддерживаемое серьезной компанией, то вам стоит посмотреть в сторону Red Hat Enterprise Virtualization (или Oracle VM).

На стенде компании Xsigo Systems красовались директоры с поддержкой  Infiniband с пропускной способностью до 56 Гбит/с на порт. Директоры позволяют организовать конвергированную, отказоустойчивую, высокопроизводительную инфраструктуру, имеют модульную архитектуру, позволяющую устанавливать дополнительные Ethernet или FC-модули для подключения к LAN и SAN коммутаторам уровня ядра. Крутые железки для крутых задач.

Вот, пожалуй и все, что я хотел рассказать о выставке VMworld.

Кстати, я совсем забыл описать одну из важнейших составляющих любой конференции, а именно - организацию питания. Не то, чтобы я был в полном восторге от еды на VMworld, но все было вполне съедобно.

Основная проблема, на мой взгляд - это однообразие меню, все 4-ре дня (за исключением главной вечеринки в среду) есть приходилось одно и то же. Если на первый день бутерброды, сандвичи, кексы шли на ура, то в последний день на них уже не хотелось смотреть. Еще я заметил, что IT'шники не особо жалуют салаты, предпочитая менее "здоровую" еду; просто картинки для сравнения:


А вот с напитками было гораздо лучше - во многих местах стояли холодильники из которых можно было в любое время взять газировку, сок или простую воду в любых количествах (если она там была, конечно), но обновляли их довольно быстро. Отдельно располагались столики с чаем/кофе.

Про главную вечеринку конференции в среду тоже хочется сказать несколько слов. Сделана она была в ретро стиле 8-битных компьютерных и консольных игр. Огромный зал, в котором днем проходила пленарная конференция, к вечеру был украшен замысловатыми геометрическими фигурами в духе Tetris, а на экранах выводились изображения странных кубических персонажей. Из развлечений были доступны автоматы с пакманом и тетрисом, пинбол, биллиард, настольный футбол, даже небольшую трассу для велокартинга соорудили, в общем, скучать не приходилось. Особое умиление вызвали тележки по "продаже" хотдогов, к которым, несмотря на обилие другой еды, выстроились весьма немаленькие очереди.




Итак, конференция закончилась. Не все доклады были выслушаны, не все лабораторные были сделаны, не все стенды были посещены, не все оппоненты убеждены в крутости VMware, ну да уж чего там. Впереди еще целый год, богатый на новые решения и технологии, которые сделают нашу IT'шную жизнь проще. А пока, до новой встречи, до следующей конференции VMworld 2013!

четверг, 11 октября 2012 г.

VMworld 2012, день 3

Закончился третий день конференции VMworld 2012, проходящей в Барселоне. Что интересного было уведено и услышано сегодня можете прочитать ниже. С обзорами предыдущих дней можете ознакомиться по ссылкам (раз и два).
День начался с пленарного доклада под заголовком "Empowering the Workforce of Tomorrow, That's Here Today", начавшегося в 9 часов. В этот раз барабанщиков на разогреве не было, зато сам доклад был не в пример интереснее и живее. 

Ведущий, Steeve Herrod, рассказал о том, как может преобразиться рабочее окружение пользователя в недалеком будущем. С помощью связки ПО Mirage и View Manager возможно будет централизованно создавать, управлять, распространять образы клиентских ОС (в частности выполнять обновление ОС на новые версии в фоновом режиме), а также предоставлять удаленный доступ для любых любых клиентских устройств (рабочих станций, ноутбуков, планшетов и мобильных телефонов).

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

Между делом анонсировали VMware Horizon Suite (наконец-то!). VMware Horizon представляет собой платформу для организации единой точки входа для пользователей, которым требуется доступ ко всевозможным приложениям (развернутым в частных или публичных облаках), виртуальным рабочим станциям и своим данным с любого устройства.

Кроме того Horizon позволит для мобильных устройств на платформе Android и iOS разделить приложения между двумя средами: личной и рабочей, с возможностью применения к рабочей среде ряда ограничений в целях усиления безопасности, таких как: требования аутентификации при запуске приложения, запрет на копирования данных из рабочей среды в личную, шифрование данных относящихся к рабочей среде.

Далее были краткие выступления бриллиантовых партнеров, которые анонсировали свои новые решения, расширяющие функциональность платформы VMware vSphere. По результатам голосования, по мнению аудитории наиболее полезным оказался доклад Chack Sakac, который рассказал о грядущей поддержке технологии VVols в линейке СХД EMC. Реализация VVols позволит обеспечить гарантированную, консистентную, синхронную  репликацию отдельных ВМ на расстояния, которые на сегодняшний день поддерживаются только при использовании асинхронной репликации.

Мне лично больше понравился доклад HP, рассказавшем о возможностях HP Matrix Infrastructure Orchestator автоматического создания виртуального ЦОД, и Cisco, рассказавшем о новой технологии LISP. Не знаю почему, но я долгое время не мог оторвать глаз от столь замечательной майки.

После завершения основной сессии я побывал на секретном собрании секретной компании секрет секрет секрет, подписал NDA, поэтому пропустил часть ранее запланированных сессий. А две оставшиеся, на которые я рассчитывал, были очень скучные, поэтому не буду о них писать. Поэтому перейду сразу к выставке.

На стенде компании VCE я помучал вопросами представителей компании о Vblock - аналоге FlexPod, в котором вместо СХД от NetApp, используется СХД EMC, а также опционально доступно ПО для централизованного управления вычислительной инфраструктурой.

В частности выяснилось, что на текущий момент не поддерживается подключение СХД напрямую к Fabric Interconnect ни по FC, ни по FCoE. Однако этот недостаток планируют исправить в Q1 2013 года, путем выпуска новых прошивок на оборудование.

На стенде Teradici (создателя протокола PCoIP, который лицензируется VMware для View) были представлены тонкие клиенты, реализующие аппаратную поддержку PCoIP от всех известных производителей (на любой вкус и цвет).

Вдобавок на стенде показывали работу Teradici APEX 2800 Server Offload Card, позволяющей снизить нагрузку на CPU и ускорить кодирование/декодирование видеопотока протокола PCoIP, и тем самым увеличить показатель консолидации виртуальных рабочих станций на одном сервере виртуализации вплоть до 2-х раз по сравнению с сервером, где такой карты нет.

Я второй раз заглянул к мастеру каллиграфии на стенд Hitachi.

Надо будет попросить его нарисовать красивое хокку о виртуализации.

На стенде демонстрировался ввиртуализатор СХД - Hitachi VSP. Вкратце, системы виртуализации СХД предназначены для объединения ресурсов нескольких отдельных систем хранения в единое хранилище, что позволяет централизованно управлять и предоставлять дисковые ресурсы клиентам. Виртуализор может повысить производительность доступа к данным за счет кэширования операций чтения и записи, а также использовать такие возможности, как thin provisiong, создание снапшотов, клонирование, зеркалирование, репликация даных и пр. независимо от того, поддерживают ли данные функции нижележащие СХД, или нет.

Hitachi VSP во многом схоже с такими продуктами, как EMC VPLEX или NetApp V-series, и также поддерживает возможность организации "растянутого" метро кластера. По словам представителей Hitachi в данный момент VSP проходит "аттестацию" в VMware, поэтому вполне возможно, что в ближайшее будущее список официально поддерживаемых VMware решений пополнит Hitachi VSP.

На стенде компании Cisco я узнал о новом для себя продукте - Cisco UCS-E Series, который, на самом деле, имеет мало общего с обычным UCS, но даже сам по себе достаточно интересен. Серверы UCS-E представляют собой блейды, которые устанавливаются внутрь модульного роутера Cisco ISR G2. Да, тут нет никакой ошибки, шасси роутера выступает корзиной для блейд-серверов. По мнению представителя Cisco, с которым я общался, такое решение в виде одной единственной коробки будет идеально для небольших филиалов, где из-за нехватки места нет возможности ставить отдельные железки - роутеры, коммутаторы, брандмауэры, серверы, и в этом есть смысл. Сами серверы бывают двух форм-факторов - половинной ширины и полной ширины, в каждый сервер может быть установлено по одному процессору Intel Xeon E3 или E5, до 16 или до 48 ГБ оперативной памяти, два или три жестких диска 2.5" - зависит от модели. Каждый сервер имеет два 1 GbE сетевых интерфейса, которые по внутренней шине коммутируются с внутренними портами роутера. Несмотря на присутствие в названии аббревиатуры UCS, на текущий момент UCS-E не может управляться через UCS Manager, что, в принципе, не является серьезным недостатком, если вспомнить, что это решение для филиалов.

На сегодня - все. Заключительная часть обзора по ссылке.