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

• оптимизация использования емкости более производительных дисковых массивов; так данные, для которых более не требуется очень высокая скорость обработки, должны быть перемещены из all-flash массива в массив с жесткими дисками, для того чтобы освободить дорогую емкость на SSD накопителях под другие задачи;
  
  
• повышение эффективности использования дисковых и вычислительных ресурсов массивов: если на одном массиве вам не хватает каких-то ресурсов (емкости или производительности), а на другом массиве (расположенном рядом или в соседнем корпусе) такие ресурсы имеются в избытке, то перемещение части данных с одного массива на другой позволит решить эту проблему и при этом не нужно тратить деньги на апгрейд массивов; т.е., здесь речь идет фактически о балансировке нагрузки между несколькими массивами;
  
  
• выведение устаревшего массива из эксплуатации и перемещение данных с этого массива на новый массив.

И здесь конечно важна не столько сама возможность перемещения данных, сколько простота этого процесса, возможность перемещать данные в любом направлении, возможность перемещать данные без остановки бизнес-процессов (т.е., прозрачно для серверов и приложений). Также немаловажно чтобы все это можно было реализовать без дополнительных затрат на специальное аппаратное или программное обеспечение.

HPE 3PAR Storage Federation как раз и позволяет реализовать все изложенное выше. HPE 3PAR Storage Federation позволяет объединить несколько массивов HPE 3PAR StoreServ в единую логическую систему с целью повышения утилизации дисковых ресурсов всей системы и балансировки нагрузки между различными компонентами системы. Перенос данных выполняется одним кликом мышки. Кроме того, другие массивы (т.е., массивы не относящиеся к семейству HPE 3PAR StoreServ) также могут быть включены в общую систему, но с одним исключением: перенос данных в этом случае будет возможен только в одном направлении – в массив StoreServ из массива не-StoreServ.

Далее я постараюсь кратко описать, как работает федерация дисковых массивов и что требуется для её настройки.

Топология

В федерацию сегодня можно объединить до 4 массивов HPЕ 3PAR StoreServ, это могут быть различные модели, как современные, так и предыдущих поколений, скажем, 7400, 8450 и 20800. Федерация позволяет перемещать данные между любой парой массивов в обоих направлениях, для этого на массивах должен стоять микрокод не ниже 3.2.2 MU1. К массивам, включенным в федерацию (далее такие массивы будут именоваться «федеративными»), можно также подключить и другие массивы, с которых нужно делать одностороннюю миграцию (такие массивы называются «источники миграции» migration sources). Односторонняя миграция поддерживается как с массивов HPЕ 3PAR StoreServ, так и с других массивов HPE: EVA/P6000 и P9500 / XP10000 / XP12000 / XP20000 / XP24000, а также и с массивов третьих производителей: EMC CX4 / VNX / vMAX, HDS USP / USP-V / USP-VM / VSP, IBM XiV. Таких источников миграции может быть до 6, но суммарное кол-во массивов, федеративных и источников миграции не может превышать 8. Ниже приведены 2 варианта возможных конфигураций. Стрелочками на этих рисунках показаны возможные направления миграции данных.


Рис.1. два федеративных массива и 6 источников миграции


Рис.2. четыре федеративных массива и 4 источника миграции

Далее в этом блоге я буду говорить только о федеративных массивах. О миграции данных на массивы HPЕ 3PAR StoreServ с других массивов я расскажу в последующих публикациях.

Порты и зоны

На федеративном массиве нужно выделить 2 порта FC, через которые на этот массив будет выполняться миграция данных, такие порты называются peer. Порты, через которые будет выполняться миграция на другой/другие массивы называются host портами.  Host порты могут быть как выделенными, так и не выделенными. Peer и host порты федеративных массивов нужно объединить в зоны и в данном случае можно использовать упрощенную схему зонирования, в которой на все порты можно использовать только 2 зоны (см. рис. 3 ниже): в каждую зону объединяется по одному peer порту и по одному host порту от каждого массива.


Рис. 3. Схема зонирование для дисковых массивов, объединенных в федерацию.

Варианты миграции

Поддерживаются 3 варианта миграции:

• Онлайн миграция возможна если серверная ОС и ПО multipath поддерживают добавление путей доступа к томам в онлайне. При онлайн миграции сервер (серверы) не теряет доступ к своим томам и обработка массивом запросов ввода/вывода от сервера не прерывается.

Для онлайн миграции возможны два варианта:

— миграция на уровне сервера – в этом случае все тома, экспортированные определенному серверу (или группе серверов) будут мигрированы одновременно.

— миграция на уровне тома (группы томов) – в этом случае толко часть томов, экспортированных определенному серверу (или группе серверов) будут мигрированы одновременно. При этом остальные тома сервера будут продолжать обслуживаться массивом. Именно этот вариант миграции позволяет перераспределять нагрузку ввода/вывода между несколькими массивами, сервер может одновременно обращаться ко всем своим томам: к томам, которые уже смигрированы на другой массив, к томам, которые находятся в процессе миграции, и к томам, которые не должны быть смигрированы.

• Миграция с минимальным временем простоя (Minimally Disruptive Migration). Если вариант с онлайн миграцией не возможен, тогда можно выполнить миграцию с минимальным временем простоя. Время простоя определяется временными затратами, необходимыми для переконфигурирования сервера – чтобы он видел target-массив вместо source-массива. Во время миграции серверу будут доступны все его данные. Этот вариант миграции возможен только на уровне сервера (см. выше).
  
  
• Оффлайн миграция. Этот вариант миграции используется если нужно мигрировать не-презентованные тома.

Возможность того или другого варанта миграции зависит от операционной системы сервера (серверов), данные которого нужно будет перемещать. Онлайн миграция возможна, например, для следующих ОС: Windows Server 2008/2012, RedHat Enterprise 5/6/7, SuSE Enterprise 10/11/12, VmWARE 5.x/6.0.

Процесс миграции

Начальная настройка Storage Federation сводится к нескольким простым шагам, которые выполняются из графической управляющей консоли SSMC (StoreServ Management Console):

• выбираем массивы, которые хотим объединить в федерацию;
• назначаем peer и host порты на этих массивах и включаем их в зоны (зоны на коммутаторах нужно будет создать предварительно)

Миграция на уровне тома (группы томов) и миграция на уровне хоста (когда мигрируются все тома, презентованные хосту) реализованы немного по-разному. Дело в том, что при миграции на уровне тома массив-источник должен продолжать обслуживание всех прочих томов данного хоста, которые не мигрируются. Для миграции на уровне тома требуется, чтобы хост поддерживал SCSI-протокол ALUA multipathing.

Процесс миграции на уровне тома выглядит следующим образом:

• Выбирается группа томов, которые нужно мигрировать. При этом каждый том-сточник автоматически экспортируется (презентуется) таргет-массиву и далее таргет-массив автоматически экспортирует эти тома хосту. Тома-копии (на таргет-массиве) будут иметь ровно те-же WWN, что и соответствующие тома-источники.
  
  
• В итоге хост увидит новые пути доступа для каждого тома и запросит статус (посредством Report Target Port Group (RTPG) SCSI command) этих новых путей у массива. В результате хост будет видеть каждый том по двум группам путей (Target Port Groups): первая группа – через порты массива-источника и вторая группа – через порты таргет-массива. При этом первая группа будет находится в режиме active optimized, а вторая группа – в режиме standby.
  
  
• Далее стартует процесс миграции, при этом сначала изменяется режим TPG: первая группа путей переходит в режим standby, а вторая – в режим active optimized (см. рис. 4). После этого все запросы ввода/вывода пойдут уже на таргет массив. Запускается копирование данных из тома-источника в том-копию, копирование, естественно, выполняется напрямую между двумя массивами без участия хостов.
  
  
• В процессе миграции запись новых данных выполняется в том-копию, при этом новые данные также копируются таргет-массивом в исходный том (на тот случай, если вдруг что-то пойдет не так, чтобы данные не были потеряны). При этом чтение будет выполняться локально (т.е., из тома-копии) – если запрашиваемые блоки уже были смигрироанны. Если же запрашиваемые блоки еще не были смигрироанны, то они будут смигрированны «вне очереди». Естественно ожидать некоторого снижения производительности в процессе миграции.
  
  
• После завершения миграции тома (группы томов) – он будет окончательно находиться на таргет-массиве. Том-источник может быть автоматически удален после успешного завершения миграции или оставлен на массиве-источнике – в зависимости от выбранных настроек миграции. Если настройки таковы, что том-источник автоматически не удаляется – никакого зеркалирования томов после завершения миграции выполняться уже не будет. В процессе миграции и после завершения миграции тома на массиве-источнике, которые не участвовали в миграции, доступны хосту без каких-либо ограничений/изменений.

Рис. 4. Состояние путей доступа к мигрируемому тому (Vol-B) во время миграции данных.

В заключение хочу добавить, что федерацию можно использовать также и в том случае, если используются катастрофоустойчивые решения и решения высокой  доступности. Т.е., можно мигрировать тома, с которыми работает серверный кластер. Можно мигрировать тома, которые участвуют в репликации между массивами HPE StoreServ (в этом случае тома с одного массива из репликационной пары мигрируют на третий массив – с сохранением репликации для этих томов; мигрировать можно или тома-source, или тома-target). Да, и еще нужно добавить, что при миграции поддерживаются консистентные группы (consistency group): если приложение работает с несколькими томами, то такие тома следует мигрировать как консистентную группу томов. Консистентная группа означает, что зеркалирование томов между таргет-массивом и исходным массивов будет продолжаться до тех пор, пока все тома из консистентной группы не будут смигрированы на таргет-массив.

Лицензии

Лицензия для Storage Federation называется вовсе не Storage Federation… а Peer Motion. Лицензировать нужно все массивы, включенные в федерацию – если вам требуется возможность двунаправленной миграция. Если же нужна только однонаправленная миграция, тогда можно лицензировать только таргет-массивы.

Так что, если вы администратор нескольких массивов HPE StoreServ – можете сразу воспользоваться преимуществами Storage Federation, не откладывая в долгий ящик. Говоря — воспользоваться сразу – я имею в виду возможность использовать триальные (trial) лицензии для оценки возможностей Storage Federation.

Объединяйте массивы в федерацию, оно того стоит!