HP StoreVirtual — платформа для катастрофоустойчивых решений для среднего и крупного бизнеса

13 октябрь, 2015 - 10:42Вячеслав Носулич

По данным исследований Gartner, программно-определяемые системы хранения (Software-Defined Storage, SDS) попадают в топ-тренды ИТ-рынка последние пару лет. Чаще всего используют программные СХД или полностью строят на них свою инфраструктуру малый и средний бизнес, а также сервис-провайдеры. При этом на рынке существует много разработок таких систем хранения с разной функциональностью и возможностями масштабирования, но особое внимание заслуживает одна из первых SDS — HP StoreVirtual VSA (Virtual Storage Appliance), ранее известная как LeftHand. Система выполнена в виде виртуальной машины VSA для гипервизоров Hyper-V и ESXi. Она интересна не только тем, что за многие годы разработки ее давно уже можно рекомендовать для корпоративного сегмента, а также и тем, что StoreVirtual доступна еще и в варианте аппаратного исполнения. В продуктовых средах заказчиков насчитывается уже более 12 тыс. виртуальных СХД HP StoreVirtual VSA.

Еще одной сильной стороной данной СХД является возможность обеспечить катастрофоустойчивость «из коробки» без дополнительных затрат. Именно на этом (катастрофоустойчивости) и сосредоточено внимание этой статьи.

Модельный ряд НР StoreVirtual включает в себя как аппаратно-программные решения 4000 серии, так и полностью программные VSA-продукты (рис. 1).

Рис. 1. Модельный ряд StoreVirtual

Технология HP StoreVirtual

HP StoreVirtual 4000 — это конвергентная система хранения данных, которая за счет уникальной технологии кластеризации может решать задачи небольшого бизнеса с малыми объемами данных и масштабироваться до системы корпоративного уровня с повышенными требованиями к производительности и сохранности данных. Основное применение этих систем — это виртуализированные среды и территориально разнесенные инфраструктуры, где необходимо обеспечить репликацию данных между несколькими площадками одновременно на малых и больших территориях по Ethernet-каналам связи и интерфейсу iSCSI.

Если рассматривать системы, подобные StoreVirtual, то мы увидим, что каждый узел — это собственная СХД и взаимодействие с себе подобными системами происходит с помощью технологий синхронной репликации, для настройки которой нужно рассматривать каждый узел как независимую систему хранения. А StoreVirtual — это изначально кластерная система хранения данных, и каждый узел — это пул ресурсов, который расширяет емкость и производительность кластера и отказоустойчивость системы в целом.

Взаимодействие узлов StoreVirtual в кластере происходит по технологии Network RAID — сетевой RAID. Если мы объединяем, например, несколько узлов в кластер и в нем создаем виртуальный диск (LUN) с сетевым RAID 10, то каждый блок данных на этом диске будет зеркалироваться между двумя узлами. Если в кластере два узла и все виртуальные диски объединены в RAID 10, то это, можно сказать, синхронная репликация между двумя узлами. Отметим, что этот пример является всего лишь частным случаем технологии кластеризации StoreVirtual, так как ее возможности гораздо шире.

Для серверов кластер хранения — это единый пул ресурсов. Каждый LUN они видят по одному Virtual IP и обращаются к нему, как к единой системе хранения, одновременно взаимодействуя со всеми узлами кластера. При этом размещение узлов StoreVirtual на разных площадках никак не сказывается на работе серверов.

Один кластер рекомендуется разносить не более чем между тремя площадками (рис. 2). Система StoreVirtual позволяет разнести узлы кластера и между четырьмя площадками с сохранением одной копии данных на каждой площадке (Network RAID10+2), но для этого нужно обеспечить повышенные требования к каналам связи между площадками. Поскольку такое решение нужно очень редко, то в рекомендациях «Best Practice» оно не указано, но при этом возможно и реализуемо.

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

В одном кластере можно организовывать разные уровни сетевого RAID для каждого виртуального диска (LUN):

• Network RAID 10 (2—Way Mirror) строится как минимум на двух StoreVirtual в кластере, каждый блок данных храниться на двух узлах (рис. 3);

Рис. 3. Размещение блоков данных внутри кластера StoreVirtual из четырех узлов, если для логического диска выбран Network RAID 10

• Network RAID 10+1 (3—Way Mirror) — строится как минимум на трех StoreVirtual в кластере, каждый блок данных храниться на трех узлах (рис. 4);

Рис. 4. Размещение блоков данных внутри кластера StoreVirtual из четырех узлов, если для логического диска выбран Network RAID 10+1

• Network RAID 10+2 (4—Way Mirror) — стоится как минимум на четырех StoreVirtual в кластере, каждый блок данных храниться на четырех узлах (рис. 5);

Рис. 5. Размещение блоков данных внутри кластера StoreVirtual из четырех узлов, если для логического диска выбран Network RAID 10+2

• Network RAID 5 (Single Parity) — строится как минимум на трех StoreVirtual в кластере, если, например, у нас три узла, то один блок данных пишется на один узел, второй блок данных — на второй узел и четность этих данных — на третий узел и так далее со смещением на один узел (рис. 6);

Рис. 6. Размещение блоков данных внутри кластера StoreVirtual из четырех узлов, если для логического диска выбран Network RAID 5

• Network RAID 6 (Dual Parity) — строится как минимум на пяти StoreVirtual в кластере, работает, как Network RAID 5, но при этом записывается две четности для повышенной отказоустойчивости (рис. 7);

Рис. 7. Размещение блоков данных внутри кластера StoreVirtual из шести узлов, если для логического диска выбран Network RAID 6

• Network RAID 0 — стоится как минимум на одном StoreVirtual в кластере, каждый блок данных храниться на одном узле, отказоустойчивость между узлами не обеспечивается.

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

Чтобы избежать потери синхронизации площадок в случае нарушения связи между площадками, так называемого «split-brain», существует StoreVirtual Failover Manager. Это виртуальная машина, которая размещается на отдельной или логически отделенной площадке и следит за тем, какая площадка должна работать, а какая должна остановится автоматически при потере канала.

Требования к сети для построения одного кластера, разнесенного между площадками, следующие:

• рекомендуемая пропускная способность для одного узла — 50 МБ/с, но также нужно учитывать, что узлы с 25-ю дисками и более или с дисками SSD требуют большую пропускную способность в зависимости от нагрузки и приложений;

• латентность — до 2 мс; система может работать и с большей латентностью, если приложения не требовательные, но при больших задержках в канале рекомендуется строить два кластера или более и переходить на асинхронную репликацию между кластерами;

• рекомендуется использовать одну подсеть. Если же это невыполнимо, тогда можно использовать разные подсети на разных площадках. Но на одной площадке нужно использовать одну подсеть.

Если расстояние между площадками большое или канал связи не удовлетворяет требованиям, то на основной и резервной площадках строится отдельный кластер StoreVirtual (рис. 8).

Рис. 8. Схема подключения узлов StoreVirtual на основной и резервной площадках, которые разнесены на большое расстояние

Между кластерами, а точнее, между виртуальными дисками в каждом кластере, настраивается асинхронная репликация по принципу Remote Snap. При этом нужно учитывать, что RPO и RTO увеличиваются в зависимости от частоты снапшотов (рис. 9).

Рис. 9. Схема асинхронной репликации с распределенным на большое расстояние логическим диском с помощью Remote Snap между кластерами StoreVirtual на разных площадках для обеспечения катастрофоустойчивости

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

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

Выводы

Требования бизнеса к защищенности данных растут с каждым днем, и хотя функциональность СХД расширяется от поколения к поколению, только проверенные и действительно используемые функции остаются и развиваются далее. Одна из самых важных — репликация. Сложно сейчас представить хранение критических для бизнеса высокодоступных данных без использования репликации. Как мы разобрались, существует два основных вида репликации — это синхронная и асинхронная.

Синхронная репликация требует качественные каналы связи между площадками, обычно разнесенных на небольшие расстояния, задержек не более ~2-5 мс и достаточно высокой полосы пропускания (в зависимости от производительности). При синхронной репликации RPO близко к 0, а RTO существенно уменьшается. Если синхронную репликацию совмещать с функциями высокой доступности на уровне приложений (HA-кластеры для виртуализации, устойчивость к сбоям и др.), то RTO также можно приблизить к 0.

При асинхронной репликации требования к каналам не такие жесткие, как при синхронной репликации. Благодаря этому асинхронная репликация, в первую очередь, используется при катастрофоустойчивых решениях, когда необходимо разнести инфраструктуру между городами, странами и даже континентами. Чаще всего используется технология асинхронной репликации с помощью снапшотов, а точнее, когда передаются только измененные данные (дельта) между мгновенными снимками. RPO в таком случае зависит от частоты снапшотов и времени на их передачу. Частоту снапшотов подбирают таким образом, чтобы в промежутках между снимками каналы и инфраструктура позволяли передать дельту на удаленную площадку. Максимальное RPO в таком случае равняется времени между снапшотами + время, которое уходит на передачу дельты. Например, если частота снимков составляет 15 минут и данные (дельта) между снимками передаются на удаленную площадку за промежуток времени до 15 минут, то RPO будет в пределах 0

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