EMC VPLEX - гибкое и масштабируемое решение Enterprise-класса, предназначенное для виртуализации инфраструктуры хранения данных.
Архитектурно, VPLEX – это от 1 до 4 контроллерных пар, объединенных в единый пул вычислительных ресурсов и обладающих логически единым пространством оперативной памяти.
Возможны три конфигурации EMC VPLEX – Local, Metro- и Geo-кластер.







Три основных функции доступны пользователям EMC VPLEX:

1. Обеспечение высокой доступности данных с нулевым временем простоя за счет зеркалирования томов между удаленными ЦОД и полностью автоматизированного процесса переключения между площадками. Полная интеграция с большим списком серверного кластерного ПО (Oracle, VMware, Microsoft, Veritas, IBM и т.д.).

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

3. Обеспечение одновременного совместного доступа к одним и тем же данным с разнесенных площадок. Полная поддержка



IBM SVC – аппаратный комплекс, который изначально создавался для виртуализации СХД в рамках одной площадки. Архитектурно SVC представляет собой контроллерную пару от системы хранения среднего уровня. SVC не создавалась для того, чтобы обеспечить катастрофоустойчивость инфраструктуры в рамках двух площадок, вместо этого, компания IBM предприняла попытку использовать решение для одной площадки, «растянув» его на две.

Для общего понимания принципов работы необходимо осознать, что IBM SVC – это фактически контроллерная пара от системы хранения среднего уровня с большим количеством единичных точек отказа для каждого контроллера (работающая в типичном для этого класса режиме ALUA).



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



В SVC существует понятие IO-группы – это как раз и есть контроллерная пара, в данном случае растянутая. Каждый том принадлежит одной конкретной группе и другая группа не может ни обрабатывать нагрузку этого тома, ни получить к нему доступ. Таким образом, на каждой площадке производительность и отказоустойчивость одного тома упирается в производительность одного контроллера класса mid-range.

Что происходит, если по каким-то причинам IO-группа недоступна? Происходит простой в работе – так как том на других IO-группах не виден. В последней версии ПО для SVC появилась возможность online перемещать тома между IO-группами, но здесь больше ограничений, чем поддерживаемых конфигураций: работает это только в Windows (может потребоваться перезагрузка хоста) и в Linux. Ни кластеры, ни VMware, ни тем более Unix не поддерживаются при этой операции.

В отличие от IBM SVC, EMC VPLEX обладает hi-end архитектурой, производится гибкая балансировка нагрузки по узлам VPLEX, все элементы задублированы, отсутствуют единые точки отказа. Тома не «привязаны» к контроллерам и даже в случае выхода всего контроллера из строя, данные будут доступны через другие контроллеры. При этом, продолжает выполняться тесная интеграция с широким набором серверного кластерного ПО и не требуется перезагрузка хостов.

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

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

Это четко подтверждает документация IBM: The connection between each site in the system associated with the SAN Volume Controller nodes must guarantee a minimum bandwidth of 4 gigabits or 2 times the peek host-write I/O workload, whichever is higher (http://www.redbooks.ibm.com/redpieces/pdfs/sg248072.pdf).



Но бывает еще хуже : если операция записи происходит на «не основной» контроллер для тома, то она проходит канал между площадками трижды: к предыдущему случаю добавляется передача данных от «не основного» контроллера «основному». Это лeгко может быть на практике, например, миграция одной из виртуальных машин на другой сервер кластера, находящийся на удаленной площадке.
С подключениями все еще интереснее. Типичная схема подключения IBM SVC в распределенном режиме (Split-site system configuration without using ISLs), выглядит примерно следующим образом.



Здесь сразу много что бросается в глаза:

 обеим нодам SVC требуется доступ к системам хранения обеих площадок, именно поэтому они подключаются не в какую-то отдельную репликационную фабрику, а напрямую в продуктивные фабрики SAN обеих площадок, нужны отдельные кабели между площадками и longwave SFP в контроллеры SVC

 в качестве кворума используется третья площадка, подключенная по SAN, на которой должен присутствовать полноценный том СХД, на который будут ориентироваться ноды SVC – совсем не экономичное решение и сложное с точки зрения обеспечения каналов

Самое интересное, что в некоторых случаях и кворумный диск не помогает. Например, поведение системы, когда обе площадки видят кворум, но при этом не видят друг друга, согласно документации IBM (http://www.redbooks.ibm.com/redpieces/pdfs/sg248072.pdf) будет определяться кто первый схватит кворум – то есть, никто не знает, что будет происходить. На все отказы идет реакция на уровне нод SVC целиком, то есть нельзя задать правила, чтобы при аварии часть томов оставалась работать на одной площадке, а часть на другой.

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



Отдельного упоминания заслуживают вопросы производительности. На каждой ноде SVC присутствует по одной карте FC c 4 портами. В распределенном режиме работы два из них фактически заняты общением со второй нодой и с ресурсами удаленной площадки. Таким образом, для работы с хостами и массивами локальной площадки остается всего лишь 2 FC порта на той же самой FC карте, по одному порту в фабрике. Данное ограничение может фатально повлиять на производительность виртуализованной среды, сократить количество подключаемых серверов и систем хранения данных.

Архитектура и производственные показатели контроллеров EMC VPLEX превосходят характеристики контроллеров IBM SVC (по количеству портов ввода-вывода, процессорным ядрам, объему кэш-памяти) и соответствуют уровню систем Hi-End класса.



Один VPLEX Metro кластер в максимальной конфигурации с 4 сдвоенными контроллерами на каждой площадке может обрабатывать до 2 240 000 IO/s или 23,2GB/s
Таким образом, можно сделать вывод, что хоть решения EMC VPLEX и IBM SVC, на первый взгляд, реализуют схожий функционал, тем не менее остаются принципиально разными решениями.
EMC VPLEX – это надежное, производительное и полнофункциональное решение для виртуализации инфраструктуры хранения, масштабируемое от малых конфигураций до проектов Enterprise-уровня. В системах EMC VPLEX реализована новая архитектура, которая вобрала в себя более чем 20-летний опыт EMC в области проектирования, внедрения и усовершенствования решений корпоративного класса для интеллектуального кэширования и защиты распределенных данных.

EMC VPLEX выбирают те Заказчики, которым важна надежность хранения данных, производительность и масштабируемость.

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

В итоге, для удобства восприятия, консолидируем наиболее значимые отличия EMC VPLEX и IBM SVC в единой таблице.