четверг, 26 февраля 2015 г.

VMware Virual Volumes (VVols)

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

Наверняка, за прошедшее с момента первого упоминания время, все не по одному разу слышали что VVols это хорошо, удобно и круто. Но почему?

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

Можно конечно все функции управления "загнать" в vCenter с помощью плагинов, тогда управлять всем оборудованием можно будет из "одного окна". Это вполне удобно, когда у нас небольшая (и сравнительно простая инфраструктура), но как только появляется несколько систем хранения, знаний специалиста по VMware может оказаться недостаточно и, хотя настроить все можно из одной консоли, но занимаются этим снова разные сотрудники.

Помимо того, чтобы упростить развертывание (и обслуживание) виртуальных машин, стоит еще и задача не вносить в гипервизор излишний функционал, который утяжеляет и усложняет работу. Часть функционала дисковых систем можно благодаря VAAI (vStorage APIs for Array Integration). В частности, поддержка Clone Blocks/Full Copy/XCOPY примитива позволяет копировать данные на уровне СХД, не передавая их гипервизору и обратно на массив. Несмотря на все плюсы, VAAI не дает существенных преимуществ как в момент непосредственного развертывания виртуальных машин, так и не слишком помогает в управлении жизненным циклом системы в разрезе конкретных виртуальных машин.

Что сейчас происходит при создании виртуальной машины? Администратор выбирает подходящий datastore - не только исходя из свободного объема, но и в зависимости от того, какая нагрузка будет на виртуальной машине, насколько уже сейчас нагружен тот или иной datastore, а также он должен принимать во внимание поддерживаемый функционал системы хранения. Если датастор еще не создан, то мы обращаемся к администраторам СХД, которые создают LUN, настраивают доступ к хостам. Не исключено, что придется также вносить изменения в сеть хранения (зонирование). После развертывания виртуальной машины, нам нужно следить за производительностью дисковой системы. Можно настраивать QoS на разных уровнях и, скорее всего, также потребуется привлечь администратора СХД.

Можно было бы предположить экстремальное решение - создать достаточно большое число LUNов и распределить по ним виртуальные машины. Ведь чем больше будет число созданных LUN, тем большую гибкость мы получаем! Идеальная ситуация - создать по одному LUN для каждой виртуальной машины, тогда мы можем очень гибко управлять ими. С другой стороны, повышается overprovisioning и управлять системой с большим числом разделов - это настоящий ад для администратора! Да и ESXi имеет ограничение на число подключаемых LUN, что тоже требуется учитывать при планировании системы.

Таким образом, требовалось создать такое решение, которое бы позволило:
  • снять нагрузку с администраторов СХД (создал раздел из SSD дисков, раздел из SAS дисков и раздел из NL SAS дисков - и дальше пусть специалисты по виртуализации сами с ними разбираются)
  • обеспечить максимальную гибкость для управления каждой из виртуальных машин
  • автоматизировать большинство операциq
  • не перегружать гипервизор (ESXi) и систему управления (vCenter) аппаратно-зависимыми модулями
  • получить унифицированное решение, которое не "привязано" к конкретным системам хранения

Виртуальные разделы (Virtual Volumes, VVols) и были предложены в качестве такого решения. По сути своей, VVol это еще один уровень абстракции, который отделяет систему хранения данных от гипервизора. Давайте в этом разрезе и посмотрим на основные компоненты решения.

Прежде всего, сам виртуальный раздел Virtual Volume (VVol) - это своего рода контейнер, в котором хранится информация, необходимая виртуальной машине - это может быть конфигурация, swap или непосредственно данные, которые мы привыкли обычно видеть в vmdk файле. Любой элемент виртуальной машины, который ранее требовал создания файла в vmfs (или nfs), теперь является отдельным виртуальным томом. Каждая виртуальная машина включает несколько VVols, количество которых меняется, в зависимости от состояния машины (наличия снимков и т.п.):
  • 1 VVol для конфигурации виртуальной машины (метаданные - .vmx файл, дескрипторы виртуальных дисков, логи и т.п.)
  • 1 VVol для каждого виртуального диска (.vmdk)
  • 1 VVol для swap (если используется)
  • 1 VVol для снапшота каждого диска + 1 VVol для снимка памяти

VVols_1

VVol это только некий виртуальный контейнер - это не LUN (по крайней мере, он им не обязан быть) и не точка монтирования NFS - реализация VVol на уровне системы хранения остается в руках производителя СХД. Для гипервизора же это просто абстрактный объект с данными, с которыми можно работать по SCSI протоколу, как и с любыми другими данными, находящимися в vmdk файле.

Первое, что нам нужно - научиться создавать и управлять виртуальными томами. Управлять созданием и размещением VVols должен не каждый отдельный хост ESXi, а сервер управления vCenter Server, поэтому слой управления (control plane) логично отделить от канала передачи данных (data plane). Кроме того, система управления виртуальными томами может быть реализована каждым производителем систем хранения по-своему, т.е. она должна быть "вне" vCenter Server. Этот программный компонент, обеспечивающий управление виртуальными томами, носит название VASA Provider. В его задачи входит в том числе предоставление информации о топологии и текущем состоянии СХД, а также о поддерживаемых возможностях системы хранения. Посредством vSphere APIs for Storage Awareness (VASA) данные передаются в vCenter Server и хосты ESXi. VASA Provider может быть реализован как “внутри" системы хранения (HP 3Par), так и в виде отдельной виртуальной машины (NetApp FAS). 
VVol_2

Следующей задачей является обеспечение доступа гипервизора (ESXi) к данным, которые находятся внутри VVol. С одной стороны, есть изначально реализованный механизм DataStore, с которым все привыкли работать. С другой стороны, у нас есть множество VVols, которые можно сгруппировать по используемым возможностям системы хранения. Например, одни тома могут быть созданы на дисках SAS и для них настроена аппаратная репликация, другие тома созданы на дисках SSD и для них репликация не используется. Логично объединить такие VVol в группы (Storage Containers) -  это еще один важный термин в новой системе. По своим параметрам Storage Container очень напоминает уже привычный LUN или раздел NFS - там хранятся данные наших виртуальных машин.  Однако, Storage Container отличается тем, что он не является жестко ограниченным ресурсом (как LUN), а представляет собой пулл “грязного” (raw) дискового пространства, на котором можно создать нужные VVols. VASA Provider сообщает всю необходимую информацию серверу vCenter и хостам ESXi. Хост ESXi не может получить доступ к Storage Container через SCSI команды или NFS RPC - вся информация передается только через VASA провайдер. Когда мы хотим создать VVol для виртуальной машины, мы должны сначала подключить новый DataStore, для которого vCenter "предложит" нам (если мы конечно все правильно настроили) предварительно созданный Storage Container. За создание Storage Container отвечает администратор системы хранения, скорее всего, он их создаст несколько (зачем - чуть позже). Всю остальную работу по распределению ресурсов уже берет на себя vCenter и аднимистратор виртуальной инфраструктуры.
VVol_3

Как же хост может получить доступ к данным в VVol? Чтобы реализация в гипервизоре не зависела от реализации VVol в системе хранения, нужен универсальный механизм реализации канала передачи данных. Protocol Endpoint (PE) является своего рода proxy для перенаправления операций ввода-вывода от гипервизора на конкретный VVol. PE это либо специальный LUN (если VVol находится на СХД, подключенной через блочный протокол), либо точка монтирование NFS (если VVol находится на NFS системе хранения). Один PE может служить прокси для множества виртуальных томов.
VVol_4

Обратите внимание, что уже это существенно упрощает администрирование - нам достаточно подключить только один LUN на сервер ESXi, чтобы получить возможность управлять множеством VVols. Protocol Endpoint поддерживает multipath для блочных протоколов, но для NFS поддержки multipath пока нет (как нет и поддержки NFS v4.1). Для NFS отказоустойчивость можно реализовать за счет увеличения числа PE для данного Storage Container. Хотя PE может отвечать только за одну систему хранения, но на одной СХД мы можем создать столько PE, сколько нам необходимо, при этом подразумевается, что каждый PE обеспечивает доступ ко всем Storage Container на данной системе хранения, хотя это и не является обязательным требованием.

Так как количество используемых Protocol Endpoint существенно меньше, чем количество подключаемых LUN (до перехода к использованию VVol), технически мы можем подключить к нашей инфраструктуре заметно больше дисковых ресурсов, что может быть актуально в свете повышения максимального количества хостов в кластере vSphere 6.

Все перечисленные компоненты (VVol, Storage Container, VASA Provider, Protocol Endpoint) обеспечивают управление виртуальными томами и доступ к данным на них. С их помощью мы можем упростить задачу распределения пространства на СХД для виртуальной инфраструктуры.

Какие еще плюсы мы можем получить от нового уровня абстракции? Благодаря VASA Provider, мы знаем о поддерживаемых возможностях системы хранения данных для VVols, размещенных на тех или иных Storage Containers, а значит мы можем использовать эту информацию при размещении новых VVols. Создавая Storage Container, администратор системы хранения фактически определяет Storage Capability - те возможности СХД , о которых VASA Provider сообщает серверу vCenter. Они могут включать в себя такие параметры как: уровень RAID, поддержку thin provisioning, тип используемых дисков, поддержку zero detect, аппаратную поддержку снапшотов и т.д. Все эти атрибуты затем могут быть использованы администратором виртуальной инфраструктуры для определения политик - Storage Policies. При создании виртуальных машин, администратор выбирает, какую политику применить для размещения дисковых ресурсов. В ходе жизненного цикла виртуальной машины также учитываются назначенные политики. Все это и составляет систему управления виртуальными машинами на базе политик (Storage Policy Based Management, SPBM). 
VVol_5

Итак, как выглядит процесс "запуска" системы для использования VVols:
  • настраиваем VASA Provider (либо интегрирован в СХД, либо отдельная виртуальная машина)
  • администратор СХД выделяет ресурсы (Storage Containers) на системе хранения
  • ищем существующие Protocol EndPoint (создаются вместе с Storage Container или VASA Provider делает это автоматически для нас)
  • создаем новые DataStore для созданных Storage Containers
  • настраиваем политики (Storage Policies)
  • создаем новую вирутальную машину

Конечно, VVol на начальном этапе развития не лишены определенных недостатков. Пока еще:
  • нет поддержки NFS v4.1
  • нет поддержки Storage DRS
  • нет поддержки Site Recovery Manager (SRM)
Суммируем плюсы от испльзования VVols:
  • Единая терминология, независимо от способа подключения СХД
  • Возможность делегировать СХД  выполнение многих операций над дисками виртуальной машины
  • Возможность предоставлять сервисы СХД на уровне отдельной виртуальной машины
  • Управление ресурсами на основе политик
  • Легкость администрирования
Все это, безусловно, начинает играть роль, когда у нас появляется достаточно сложная инфраструктура. Начинать "играть" в VVols, имея одну систему хранения с одним типом дисков и 3-4 сервера, на мой взгляд, можно только для самообразования. Практической пользы вы, уверен, на такой конфигурации не увидите.


Ключевые термины и сокращения:
  • Virtual Volume (VVol) - виртуальный раздел/том
  • VASA Provider - реализация слоя управления для VVol
  • vSphere APIs for Storage Awareness (VASA) - программный интерфейс для унификации взаимодействия с СХД
  • Storage Container - контейнер, в котором создаются VVols
  • Protocol Endpoint (PE) - прокси для доступа к самим данным
  • Storage Capability - поддерживаемые возможности СХД, которые можно использовать в создаваемых политиках
  • Storage Policies - политики, назначаемые виртуальным машинам, на основе которых происходит выбор подходящих дисковых ресурсов
  • Storage Policy Based Management (SPBM) - управление ресурсами хранения на основе политик
Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

четверг, 19 февраля 2015 г.

IBM потратит ярд на системы хранения

В IBM заявили, что готовы в ближайшие 5 лет вложить миллиард $ на разработку Software Defined Storage нового поколения. Инвестиции будут направлены на R&D в области облачных и объектных систем хранения, а также интеграцию с открытыми технологиями (OpenStack).

Если уже представители IBM заявляют, что "traditional storage is inefficient in today’s world", наверное действительно пришла пора перемен. Пока, уж не знаю зачем, решили переименовать все (почти все) системы хранения. Конечно, теперь все поймут, какая IBM супер-современная компания! :)

Встречайте - IBM Spectrum. На сегодняшний день это единственное изменение, которое случилось с IBM System Storage по случаю смены парадигмы.

Хотя, я все-таки немного сгустил краски - в IBM решили наконец превратить XIV в программную платформу. Если бы этот шаг был сделан через год после выпуска Gen3, вот это был бы настоящий взрыв! А сейчас этим уже почти никого не удивишь, тем не менее, вот он - Spectrum Accelerate.

Остальные "новинки":
Spectrum Virtualize = San Volume Controller (SVC)
Spectrum Scale = General Parallel File System (GPFS)
Spectrum Archive = Linear Tape File System (LTFS)
Spectrum Control = Storage Insights
Spectrum Protect = Tivoli Storage Manager

Нового названия не нашлось для старичка DS8000, хотя он самый что ни на есть Software Defined Storage еще с незапамятных времен. Также почему-то в стороне остались All Flash массивы (Flash System).

За программной реализацией XIV, на мой взгляд, есть реальная сила, но будет ли этого достаточно, чтобы вытянуть весь Spectrum на новый уровень - большой вопрос.
Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

Varonis DatAnswers - корпоративная система поиска по неструктурированным данным

Не знаю как вы, но я за собой многократно замечал, если мне нужен какой-то документ (и я понимаю, что он мне понадобится еще несколько раз в ближайшие дни), я просто кладу его на рабочий стол или в какую-то папку, которую я год назад создал, специально для “очень нужного документа”, и сам себе пообещал удалить через недельку, не позднее. Только сейчас в этой папке 200 (и хорошо, если 200, а не 1000) разных файлов и понять что есть что уже почти не реально.

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

Почему так происходит? Чаще всего из-за того, что найти нужный документ, расположенный где-то на одном из файловых серверов (или в корпоративном портале), используя только стандартный механизм поиска и какие-то ключевые слова, довольно сложно - либо получаешь на выходе нерелевантный результат из сотни документов, в которых “на ощупь” пытаешься найти нужный, либо не получаешь вообще ничего. А если совсем не повезет, то можно случайно найти и “чужие” файлы, доступа к которым вообще не должно быть. Все это не способствует повышению продуктивности сотрудников - если человек вынужден потратить 30 минут на поиск документа (а таких сотрудников в компании 100), несложно посчитать какая часть заработного фонда вылетает “в трубу”.

Если для небольших компаний задача управления неструктурированными данными может решаться “наколенным” способом, то для крупных корпораций с сотнями пользователей и несколькими (а иногда и десятками) файловыми серверами требуется искать более продвинутые решения. Уже несколько лет для ряда заказчиков таким продвинутым решением является система Varonis DatAdvantage (в составе комплекса Data Governance Suite). Этот программный комплекс не только позволяет быстро увидеть права доступа в разрезе пользователь-ресурс (и наоборот), но система аналитики позволяет выйти далеко за рамки простой утилиты контроля доступа к файлам. [Неожиданно для себя, заметил, что упомянул DatAdvantage единожды и то только по случаю выхода очередного апдейта - постараюсь исправиться в ближайшее время.] Подсистема сбора статистических данных (IDU Analytics) собирает полную статистику доступа пользователей к файлам - кто и когда открывал файл, кто записывал, кто пытался получить доступ, но не получил и т.д. На основе накопленных данных можно построить своего рода “рекомендательную систему”. Такие системы часто используются в интернет-магазинах или соц-сетях - вам рекомендуются те товары (или публикации), которые заинтересовали других людей, чье поведение было схоже с вашим. Однако, в Varonis DatAdvantage, накопленная статистика активности используется не для того, чтобы что-то предложить пользователю, а чтобы помочь классифицировать пользователей и показать, правильно ли настроены группы доступа. Также система позволяет выявить неправомерные попытки получить доступ к данным.

В конце прошлого года Varonis объявил о доступности (т.е. его уже можно попробовать в пилоте или приобрести) нового компонента своей системы - системы поиска DatAnswers. Это корпоративная система поиска файлов на файловых серверах и портале Sharepoint. Поскольку ядро системы (IDU) уже собирает и анализирует как статистику доступа к файлам, так и их содержимое, разработчикам оставалось только добавить индекс и, уже на его основе, построить поисковую систему.

Благодаря тому, что содержимое файлов не единственный источник данных для поисковой системы, DatAnswers имеет ряд уникальных преимуществ перед другими корпоративными поисковыми системами:

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

Эффективное индексирование
Так как система сбора статистики всегда “знает” какие файлы были добавлены, а какие изменялись, полного переиндексирования не требуется никогда. Не нужно даже проверять метки о последнем времени модификации файла - информация о том, какие файлы нужно индексировать, берется непосредственно из данных IDU Analytics. Такой подход позволяет существенно снизить нагрузку от процесса индексирования на всю инфраструктуру заказчика и не зависеть от корректности временных меток на файлах и каталогах.

Уже сейчас DatAnswers предоставляет следующие возможности:
  • находить “похожие” документы - здесь на помощь снова приходит статистика доступа
  • искать файлы на серверах Windows, NAS устройствах и SharePoint портале
  • позволяет пользователю сразу перейти в родительский каталог, где был найден документ
  • использовать для фильтрации результатов рекомендации DatAdvantage
  • с использованием IDU Classsification Framework из результатов поиска можно исключать определенные данные, такие как номера кредитных карт, зарплатных ведомости и другие финансовые данные
  • исключать из результатов поиска файлы, попадающие под всевозможные регулирующие законы (правда пока это актуально скорее для западных компаний)
Кроме того, API DatAnswers позволяет интегрировать систему поиска в свои приложения, что может быть востребовано для крупных компаний, которым организационно нет смысла добавлять еще одну программную оболочку, а гораздо удобнее интегрировать поиск в свою ИС.

И, на всякий случай, еще раз хочу отметить, что комплекс программных решений Varonis ориентирован, в первую очередь, на крупные компании с большим количеством сотрудников и большим объемом неструктурированных данных (т.е. на те случаи, когда "ручное" администрирование начинает приносить больше вреда, чем пользы и требует слишком больших людских ресурсов). По этой же причине всем проектам по внедрению предшествует пилотная эксплуатация, в ходе которой можно оценить преимущества решения и те плюсы, которые оно предоставляет. За пилотом можно смело обращаться к партнеру Varonis в России.

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

понедельник, 16 февраля 2015 г.

HP: еще одна реализация EVO:RAIL отгружается заказчикам


Раз уж я начал писать про EVO:RAIL, не могу пройти мимо - на прошлой неделе HP объявил о начале отгрузок своей, анонсированной ещё осенью 2014 года, гиперконвергентной системы - HP ConvergedSystem 200–HC EVO:RAIL.

HP Converged System 200-HC EVO:RAIL front

"Железный" состав довольно стандартный - 4 вычислительных узла, каждый содержит:
  • 2 процессора Intel® E5-2620 v2 six-core
  • 192 GB памяти
  • 1 диск SAS 300 GB 10k для загрузки ESXi
  • 3 дика SAS 1.2 TB 10k (для построения VSAN)
  • 1 диск 400 GB MLC SSD (кэш для VSAN)
  • 2 порта 10GbE (под медь или SFP+)
  • 1 порт IPMI под удалённое управление
HP Converged System 200-HC EVO:RAIL back

В некоторой перспективе (второй квартал 2015) заказчикам обещают поддержку HP OneView для централизованного управления инфраструктурой, но пока её нет.

Признаться честно, сверх сухих цифр, сказать мне про данную систему практически нечего: никаких экстраординарных возможностей, никакого дополнительного функционала. Со всех точек зрения - говорим ли мы о железной начинке или о программной части, это только следование "reference" дизайну от VMware. Найти хотя бы какие-то отличия от, например, Supermicro EVO:RAIL я не смог, как не старался. Да, конечно, локальная поддержка в России от "большого" бренда - это серьезный плюс HP. Уверен, однако, что многие из локальных сборщиков/партнеров Supermicro готовы предложить схожие условия по поддержке за сравнимые, если не за меньшие деньги.

Похоже, что для HP это скорее политическое, чем техническое решение - "Да, мы тоже умеем EVO:RAIL и нашим заказчикам не стоит смотреть на других вендоров." С другой стороны, у HP есть система 200-HC StoreVirtual, которую им, скорее всего, продавать заказчикам гораздо интереснее, чем EVO.

Кто же будет покупателем данного решения? Наверное те заказчики, у которых HP является корпоративным стандартом и для которых EVO подходит (а это всё-таки довольно нишевое решение). 

Ждём GA от других вендоров (NetApp уже скоро).
Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

четверг, 5 февраля 2015 г.

Еще один игрок среди реализаций EVO:RAIL

На днях EMC анонсировала свой EVO:RAIL appliance - VSPEX BLUE, присоединившись, тем самым, к не слишком многочисленной компании, в которой готовых отгружать решение еще меньше.


VSPEX BLUE


Для крупных игроков на рынке довольно сложно продвигать свою реализацию EVO:RAIL. Им нужно заработать, а в случае с EVO, мы имеем жесткие лимиты по дизайну системы, определенный софт и, собственно, практически всё. Поэтому основная задача - показать ценность своего решения, чтобы клиенту не казалось, что цена идет только за брэнд EMC, когда он сравнивает VSPEX BLUE с практически точно такой же (по железным характеристикам) системой от Supermicro (например).

В EMC это прекрасно понимали и на разработку решения потратили довольно много времени и приложили максимум усилий, чтобы потенциальный клиент понимал, что не зря тратит свой бюджет. 
VSPEX BLUE front

VSPEX BLUE back
Что касается аппаратной части, то здесь всё довольно стандартно - можно выбрать между двумя моделями - 128ГБ памяти на узел, либо 192ГБ. Других отличий нет -  2 процессора Intel Xeon E5-2620 V2, 3*1.2TB SAS, 400GB SSD, 2*10G ethernet. Всё, что потребуется клиенту для запуска - стойка, коммутатор (10Гбит), электропитание и ноутбук для настройки. EMC обещает, что за 15 минут можно вполне уложиться с первоначальной инициализацией системы и уже приступать к созданию виртуальных машин. Настройка, по большей части, происходит автоматизировано и от администратора требуется минимум участия.

Так что отличия решения от конкурентов это конечно не железо, а программные “фишки”. 

Первая отличительная особенность, которая сразу бросается в глаза - существенно расширенная система управления (Blue Manager). Она позволяет администратору “видеть”, что происходит с железом на более низком уровне, чем стандартный vCenter. В нее встроены ссылки на дополнительный, предназначенный для VSPEX BLUE, софт от EMC (о нем чуть ниже). Присутствует и доступ к ресурсам технической поддержки, все сервисы, как это теперь модно, "в одном окне".

Раз речь зашла о поддержке, то мы помним, что ранее VSPEX был лишь референсным дизайном для партнёров и именно они должны были обеспечивать первый уровень поддержки. Напротив, VSPEX BLUE это система, которая поддерживается EMC “от и до”. Более того, система ESRS (EMC Secure Remote Services) сама периодически отправляет информацию о состоянии оборудования в службу поддержки (если конечно есть доступ в интернет), поэтому, если не очень внимательно относиться в средствам мониторинга,  вы сможете получить сигнал от службы поддержки ещё даже до того, как узнаете о потенциальных проблемах. Проактивный удалённый мониторинг всегда является большим плюсом для заказчика,так как позволяет отчасти переложить ответственность на плечи вендора. Поддержка уровня Premium, помимо времени реагирования 24*7*4 на критичные проблемы,  включает в себя еще и установку апдейтов на систему, так что про обслуживание можно практически забыть и заниматься только развертыванием нужных сервисов (и управлением ими).

Защита от сбоя в рамках кластера это прекрасно, но для компаний, использующих более одной площадки для размещения своей ИТ-инфраструктуры, довольно часто бывает востребован такой функционал как репликация данных для обеспечения отказоустойчивости. Поэтому в поставку уже включены лицензии на RecoverPoint for Virtual Machines - по 15 лицензий на каждый из физических серверов, т.е. каждый appliance поддерживает репликацию до 60 виртуальных машин. Это полностью программное решение по репликации и не требует никакого дополнительного оборудования. Но даже если у вас нет удаленной площадки, никто не мешает использовать локальные реплики для быстрого восстановления в случае сбоя (это совсем не то, что снапшоты внутри VMware). Мы можем сами указать требования по RPO для наших виртуальных машин и обеспечить уровень доступности сервисов, соответствующий бизнес-задачам.

Ещё одной особенностью системы является система резервного копирования VDPA (а не только VDP, входящая в состав лицензии на Enterprise Plus) с коннектором для Data Domain. Ведь нельзя же делать резервную копию данных на сам VSPEX BLUE. :) Вся необходимая программная часть уже включена в поставку  VSPEX BLUE (конечно, кроме самого Data Domain). Поддержка дедупликация и высокой скорости disk-to-disk резервного копирования позволяют оптимизировать схему бэкапа и минимизировать его влияние на продуктивную среду. Одна из "младших" систем Data Domain станет отличным дополнением к проекту по внедрению.

Меня всегда настораживал ограниченный объем дискового пространства, который характерен для систем EVO:RAIL -  в случае с EMC это по 3 диска 1.2TB SAS плюс 400GB SSD для VSAN Cache на каждый узел. Это даёт примерно 12ТБ на систему, но ведь полезная емкость будет ещё минимум в 2 раза меньше. Конечно, 6ТБ это не так мало, но, по современным меркам, совсем не так уж и много. Поэтому ещё одна “фишка” системы нацелена как раз на тех, кому нужен объем, но нет желания ставить свою собственную дополнительную дисковую систему (либо из-за невысоких требований к производительности, либо из-за того, что обращение к данным не такое уж и частое). Каждый покупатель VSPEX Blue получает возможность подключить до 10ТБ данных из “облака” (Amazon, Google и др.) к EMC Cloud Array VE. Поддерживается до 1ТБ локального кэша, который обеспечивает высокую производительность при работе с “облачными” данными. В облаке можно размещать как данные, так и непосредственно образы виртуальных машин (работающих!).

И, да, для тех кому мало одной системы - можно поставить до 4х VSPEX BLUE в один кластер (16 физических хостов). 

Получилась довольно интересная система, тем более, что на таком массовом рынке серверов EMC никогда не играла. Посмотрим, насколько быстро получится "отхватить" долю. Весьма успешный и совсем недавний пример Cisco подтверждает, что можно и с места высоко прыгнуть.
Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!