Storage Federation Или Все Корпоративные Системы Хранения Данных Объединяются В Федерацию.



Storage Federation или все корпоративные системы хранения данных объединяются в федерацию.
</p><p>

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

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

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

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

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

прозрачно серверам и приложениям).

Немаловажно и то, что все это можно реализовать без дополнительных затрат на специальное оборудование или программное обеспечение.

HPE 3PAR Storage Federation позволяет реализовать все вышеперечисленное.

HPE 3PAR Storage Federation позволяет объединить несколько массивов HPE 3PAR StoreServ в единую логическую систему, чтобы улучшить использование дисковых ресурсов во всей системе и сбалансировать нагрузку между различными компонентами системы.

Передача данных осуществляется одним щелчком мыши.

Кроме того, в общую систему могут быть включены и другие массивы (т. е.

массивы, не относящиеся к семейству HPE 3PAR StoreServ), но с одним исключением: передача данных в этом случае будет возможна только в одном направлении — к массиву StoreServ из массив не StoreServ. Далее я попытаюсь кратко описать, как работает объединение дисковых массивов и что необходимо для его настройки.



Топология

Сегодня в федерацию можно объединить до 4 массивов HPE 3PAR StoreServ; это могут быть разные модели, как современные, так и предыдущих поколений, скажем, 7400, 8450 и 20800. Федерация позволяет перемещать данные между любой парой массивов в обе стороны, для этого на массивах должен быть микрокод не ниже 3.2.2. МУ1. К массивам, входящим в федерацию (далее такие массивы будут называться «федеративными»), вы также можете подключить другие массивы, с которых нужно сделать одностороннюю миграцию (такие массивы называются «источниками миграции»).

Поддерживается односторонняя миграция как с массивов HPE 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 варианта возможных конфигураций.

Стрелки на этих рисунках показывают возможные направления миграции данных.



Storage Federation или все корпоративные системы хранения данных объединяются в федерацию.
</p><p>

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

Storage Federation или все корпоративные системы хранения данных объединяются в федерацию.
</p><p>

Рис.

2. четыре федеративных массива и 4 источника миграции В оставшейся части этого блога я буду говорить только об объединенных массивах.

О миграции данных на массивы HPE 3PAR StoreServ с других массивов я расскажу в последующих публикациях.



Порты и зоны

На объединенном массиве необходимо выделить 2 FC-порта, через которые будет осуществляться миграция данных в этот массив; такие порты называются вглядеться .

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

Хост-порты могут быть выделенными или невыделенными.

Одноранговые и хост-порты объединенных массивов необходимо объединять в зоны, и в этом случае можно использовать упрощенную схему зонирования, при которой для всех портов можно использовать только 2 зоны (см.

рис.

3 ниже): один одноранговый порт и один хост-порт из каждого массива.



Storage Federation или все корпоративные системы хранения данных объединяются в федерацию.
</p><p>

Рис.

3. Схема зонирования объединенных дисковых массивов.



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

Поддерживаются 3 варианта миграции: Онлайн-миграция возможна, если ОС сервера и программное обеспечение многопутевого доступа поддерживают добавление путей доступа к томам в режиме онлайн.

Во время онлайн-миграции сервер(ы) не теряют доступ к своим томам и обработка массивом запросов ввода-вывода от сервера не прерывается.

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

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

При этом остальные тома серверов продолжат обслуживаться массивом.

Именно этот вариант миграции позволяет перераспределить нагрузку ввода-вывода между несколькими массивами; сервер может одновременно получить доступ ко всем своим томам: к томам, которые уже были перенесены в другой массив, к томам, которые находятся в процессе миграции, и к томам, которые не следует мигрировать.

Миграция с минимальным временем простоя (Minimally Disruptive Migration).

Если онлайн-миграция невозможна, вы можете выполнить миграцию с минимальным временем простоя.

Время простоя определяется временем, необходимым для перенастройки сервера, чтобы он видел целевой массив вместо исходного.

Во время миграции сервер будет иметь доступ ко всем своим данным.

Этот вариант миграции возможен только на уровне сервера (см.

выше).

Оффлайн миграция.

Этот вариант миграции используется, если вам нужно перенести непредставленные тома.

Возможность того или иного варианта миграции зависит от операционной системы сервера(ов), данные которого необходимо будет переместить.

Онлайн-миграция возможна, например, для следующих ОС: 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): выбираем массивы, которые хотим объединить в федерацию; назначьте одноранговые и хост-порты на этих массивах и включите их в зоны (сначала необходимо создать зоны на коммутаторах) Миграция на уровне тома (группы томов) и миграция на уровне хоста (где переносятся все тома, представленные хосту) реализованы несколько по-разному.

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

В этом случае каждый исходный том автоматически экспортируется (представляется) в целевой массив, а затем целевой массив автоматически экспортирует эти тома на хост. Копируемые тома (в целевом массиве) будут иметь точно такой же WWN, что и соответствующие исходные тома.

В конце концов хост увидит новые пути доступа для каждого тома и запросит статус (через команду SCSI Report Target Port Group (RTPG)) этих новых путей из массива.

В результате хост будет видеть каждый том по двум группам путей (Target Port Groups): первая группа — через порты исходного массива и вторая группа — через порты целевого массива.

При этом первая группа будет находиться в активном оптимизированном режиме, а вторая группа – в режиме ожидания.

Далее запускается процесс миграции, при этом сначала меняется режим TPG: первая группа путей переходит в режим ожидания, а вторая – в активный оптимизированный режим (см.

рис.

4).

После этого все запросы ввода-вывода будут поступать в целевой массив.

Начнется копирование данных из исходного тома в копируемый том; копирование, естественно, происходит напрямую между двумя массивами без участия хостов.

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

В этом случае чтение будет производиться локально (т.е.

с копии тома) — если запрошенные блоки уже были перенесены.

Если запрошенные блоки еще не были перенесены, то они будут перенесены «вне очереди».

Естественно ожидать некоторого снижения производительности в процессе миграции.

После завершения миграции тома (группы томов) он наконец будет расположен в целевом массиве.

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

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

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



Storage Federation или все корпоративные системы хранения данных объединяются в федерацию.
</p><p>

Рис.

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

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

То есть вы можете мигрировать тома, с которыми работает кластер серверов.

Вы можете мигрировать тома, которые участвуют в репликации между массивами HPE StoreServ (в этом случае тома из одного массива из пары репликации мигрируют в третий массив — с сохранением репликации для этих томов; вы можете мигрировать как исходные тома, так и целевые тома).

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

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



Лицензии

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

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

Итак, если вы являетесь администратором нескольких массивов HPE StoreServ, вы можете сразу же воспользоваться преимуществами Storage Federation, не откладывая это на потом.

Когда я говорю «воспользуйтесь сразу», я имею в виду возможность использовать пробные лицензии для оценки возможностей Storage Federation. Объедините массивы в федерацию, оно того стоит! Теги: #система хранения #hpe #3PAR Storage Federation

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.