Useful(less) notes

СХД начального уровня от Lenovo - S2200 и S3200

noreply@blogger.com (Andrew Ivanov) — Wed, 24 Jun 2015 06:38:00 +0000

Компания Lenovo недавно представила две новые дисковые системы S2200 и S3200. Рассчитаны они, прежде всего, на малый бизнес. Конкуренция на этом рынке довольно активная - среди наиболее активных игроков HP с системами MSA, Dell с MD3, NetApp E2700 и FAS2500, EMC VNXe, IBM V3700 и целый ряд B-брендов.

Если посмотреть на характеристики объявленных новинок, то мы увидим классическую архитектуру двухконтроллерного массива, который масштабируется вертикально (за счет добавления дисковых полок). Для S2200 максимальное количество дисков составляет 96 (контроллерный модуль и 3 полки по 24 диска), для S3200 максимум можно подключить 192 диска (контроллерный модуль и 7 полок по 24 диска). Если использовать полки с дисками 3.5" (по 12 дисков на полку), то максимальное число дисков будет 48 и 96, соответственно.

Технические подробности, сравнение систем друг с другом, а также с аналогом от HP - в полной версии статьи по ссылке.

Новый лидер от HP - 3PAR 20000

noreply@blogger.com (Andrew Ivanov) — Wed, 24 Jun 2015 06:33:00 +0000

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

На прошедшей конференции HP Discover была объявлена новая high-end система HP 3PAR 20000 (модель 20800 поддерживает и ssd, и обычные диски, а модель 20850 - только ssd). По сравнению с 3PAR 10000, изменений довольно много (в ознаменование этого и номер модели поменялся в 2 раза), система стала не только заметно производительнее, а также избавилась от рудиментарного fibre channel в качестве интерконнекта между контроллерами и дисковыми полками. С учетом того, что "десятитысячник" уже давно просился на покой, я даже немного удивлен, что этот анонс произошел сейчас, а не в прошлом году.

Некоторые подробности про две новые системы по ссылке.

OnCommand Shift туда и обратно

noreply@blogger.com (Andrew Ivanov) — Mon, 18 May 2015 08:00:00 +0000

В инфраструктуре из нескольких серверов задача миграции виртуальных машин между гипервизорами если и возникает, то редко и разово. А вот если счет серверов идет на десятки, то вероятность параллельного использования двух гипервизоров весьма высока - кто-то это делает для экономии на лицензиях, кто-то чтобы не класть все яйца в одну корзину. И миграция виртуальных машин между Hyper-V и VMware может оказаться непростой задачей.

Уже некоторое время существует решение для ускоренной миграции из VMware в Hyper-V, разработанное с участием NetApp - MAT4Shift. Основная сложность в миграции - необходимость конвертировать диск с данными, а это требует существенных затрат времени (и ресурсов СХД). Если использовать только MAT (Microsoft Automation Toolkit), миграция 1ТБ диска может занять несколько часов. MAT4Shift за счет использования технологии FlexClone в СХД (да-да, конечно требуется не только утилита, но и СХД NetApp FAS) позволяет радикально сократить время миграции. Скорость возрастает, так как фактически не происходит конвертации данных, изменяются только заголовки и метаданные, после этого VMDK “превращается” в VHDX диск. Утилита также удаляет vmware tools и вносит необходимые изменения в настройки сетевых интерфейсов и VLAN. Время миграции виртуальной машины из VMware в Hyper-V сокращается от нескольких часов до всего нескольких минут.

Несмотря на достигнутые результаты, хочется еще, как минимум, конвертировать VM и из Hyper-V в VMware. Чтобы закрыть вопрос миграции в гетерогенной виртуальной среде, NetApp выпустил отдельный продукт - NetApp OnCommand Shift. Именно благодаря ему можно без лишних затрат времени и при минимальном участии администраторов производить миграции VM из VMware в Hyper-V и наоборот.

Как же осуществляется миграция?

ПО собирает данные о настройках виртуальной машины, которые необходимо будет воспроизвести после миграции.
Создается клон виртуальной машины (технология FlexClone в СХД NetApp FAS). Независимо от размера диска VM, процесс клонирования происходит практически мгновенно.
Происходит автоматизированное удаление утилит (VMware tools или Hyper-V Integration tools).
Дальше некоторое время требуется для настоящей магии - замены метаданных и заголовков в снимке диска (VMDK/VHDX). Сами данные не изменяются, а так как объем метаданных сравнительно небольшой, время конвертации диска мало зависит от размера исходных данных.
Если необходимо, устанавливается новый набор утилит.
Переносятся настройки, сохраненные на первом этапе. После миграции будут сохранены все сетевые настройки, подключения к VLAN и названия сетевых подключений.

Если нужно перенести не одну, а сразу несколько VM, автоматизировать процесс поможет модуль OnCommand Shift PowerShell.

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

Поддерживаемые гипервизоры: VMware ESXi 5.0 и выше, Microsoft Windows Server 2008R2 Hyper-V и выше. На NetApp должна быть установлена Clustered Data ONTAP 8.2 и выше, также потребуется создать виртуальную машину (требования самые скромные), в которой и будет выполняться OnCommand Shift.

Да, все это бесплатно, но работает только для владельцев СХД NetApp - остальным придется либо тратить на миграцию больше времени, либо искать альтернативы (про которые я, впрочем, пока не слышал).

HP StoreOnce VSA - теперь и бесплатно!

noreply@blogger.com (Andrew Ivanov) — Fri, 24 Apr 2015 05:00:00 +0000

Как получить бесплатную систему дедубликации для хранения резервных копий совершенно бесплатно? Сейчас — запросто! HP раздает всем желающим лицензии на 1ТБ StoreOnce VSA абсолютно бесплатно, то есть даром! Выпущены версии для всех наиболее распространенных гипервизоров: VMware, Hyper-V и KVM.

Уже довольно давно (я и про это упоминал здесь) можно получить в совершенно бесплатное использование лицензию на 1ТБ дискового пространства HP StoreVirtual VSA. Это отличный старт для экспериментов, для пилотных инсталляций, когда еще нет больших требований к объему дисков. Бесплатный 1ТБ StoreVirtual VSA вполне может даже стать неплохой основой своего рода «микро-конвергентного» решения для филиала, где стоит задача минимизировать простой при сбоях, но нет возможности строить серьезное решение. Теперь программную систему хранения данных можно дополнить программной системой хранения резервных копий.

Минимальные требования для установки: 2 x vCPU (2.2GHz), 16GB vRAM. Ничего запредельного.

Поддерживаются все популярные программы резервного копирования. Детальный список можно найти здесь: www.hp.com/go/ebs Думаю, что при некотором желании можно запустить и что-то типа бесплатной Bacula — StoreOnce можно настроить как VTL, NFS, CIFS или Catalist target.

Обратите внимание, что никто не запрещает использовать бесплатную лицензию в продуктивной среде — это плюс. Важно помнить, что никакой технической поддержки ждать не стоит — она предназначается для владельцев коммерческих лицензий. Еще одно, последнее ограничение бесплатной версии — нельзя расширить объем свыше 1ТБ, но можно без проблем «проапгрейдить» систему до коммерческой лицензии и получить 4ТБ, 10ТБ или даже 50ТБ. Апгрейд проходит совершенно прозрачно для уже сохраненных данных — они продолжают быть доступны для восстановления при аварии. А если и этого мало, то пора переходить на аппаратную реализацию, где объемы могут достигать сотни ТБ, а скорости десятков ТБ в час.

Важно заметить, что 1ТБ это «честный» объем — после дедубликации, а так как система предназначена для хранения бэкапов, то фактический полезный объем, при степени дедубликации 1:20, составит уже 20ТБ.

Остальной функционал полной версии доступен и для бесплатных пользователей. Среди интересных возможностей — шифрование данные и поддержка репликации (можно например установить в филиале, если на центральной площадке уже используется StoreOnce).

Но, как это часто бывает, бесплатный сыр встречается редко. Ровно через три года карета Золушки, как в сказке, превратится в самую обычную тыкву! Бесплатная лицензия выдается сроком на 3 года и, когда лицензия заканчивается, все резервные копии продолжают оставаться доступными — можно реплицировать их на другую систему, можно восстанавливать данные, но записать новые уже нельзя. По окончании срока действия лицензии, StoreOnce VSA перейдет в режим «только для чтения». Спасти вас может коммерческая лицензия — после покупки и активации, продолжайте полноценное использование продукта. Впрочем, если 3 года система проработала успешно в продуктиве, то пора и полноценную лицензию покупать. А наиболее экономные пользователи найдут способ получить свежую бесплатную лицензию (если они еще будут раздаваться) и реплицировать данные из старой бесплатной VSA на новую. Для наших админов нет нерешаемых задач! Но нужно быть готовыми к такому развитию событий.

Скачать образ виртуальной машины (и зарегистрировать лицензию) можно здесь: www.hp.com/go/FreeBackup

Еще раз про vVol - теперь для владельцев NetApp

noreply@blogger.com (Andrew Ivanov) — Wed, 15 Apr 2015 05:00:00 +0000

Про vVol я уже писал здесь. На прошлой неделе стали доступны для загрузки Virtual Storage Console 6.0 и VASA Provider 6.0 for Clustered Data ONTAP. Это два необходимых компонента для начала работы с virtual volumes в vSphere 6.0 и Data ONTAP.

Virtual Storage Console крайне полезный плагин vCenter, который пригодится любому владельцу СХД NetApp, независимо от планов на использование vSphere 6 или virtual volumes. Я буду очень удивлен, если кто-то из администраторов еще не использует его — решение подавляющего большинства задач управления системой хранения упрощается в разы.

VASA Provider это отдельная виртуальная машина (на базе Linux), которая и реализует двустороннее взаимодействие между vCenter Server и системой хранения.

Конечно нужно помнить, что виртуальную машину с VASA Provider нельзя размещать на vVol — сервер ESXi не сможет начать работать с vVol до тех пор, пока не будет запущен VASA Provider. Это в равной степени относится и к vCenter — для него тоже нужно использовать только обычный датастор.

Кроме того, бакап и еще раз бэкап! Потеря как базы данных, так и самого VASA Provider может запросто прикончить вашу сверхсовременную и технологичную инфраструктуру. Новые технологии несут нам не только счастье и радость, но и лишние заботы! Хотя для сложной инфраструктуры польза от использования vVol конечно есть — администратор получает очень гибкий инструмент для автоматизированного управления как на уровне отдельной виртуальной машины, так и на уровне групп.

Да, на текущий момент в матрице совместимости vSphere нет поддержки vVols в Data ONTAP 8.3 - пока только 8.2.3.

Мне лично больше нравится реализация VASA Provider в HP 3Par — он работает не в отдельной виртуальной машине, а “внутри” системы хранения. Такой вариант мне кажется более удобным для пользователя, хотя до первой проблемы однозначно не скажешь! :)

Пора прорубать окна в контейнерах!

noreply@blogger.com (Andrew Ivanov) — Fri, 10 Apr 2015 05:00:00 +0000

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

Многие наверное еще осенью слышали обещание Microsoft о грядущей поддержке Docker в новой версии Windows. И вот, пришла пора узнать подробности — вчера в Microsoft было сразу два анонса, имеющих непосредственное отношение к контейнерам.

Во-первых, это контейнеры Hyper-V. Благодаря интеграции с Docker, код, работающий в рамках одного контейнера, изолирован от процессов в операционной системы и процессов в других контейнеров. Hyper-V контейнеры можно будет развертывать как обычный Windows Server контейнер, так и в виде виртуальной машины Hyper-V — довольно интересная опция, которая может стать аргументом для принятия технологии корпоративным сектором. Управление обоими видами контейнеров осуществляется через Docker.

Во-вторых, объявлено о еще одной редакции Windows Server. Это минифицированная операционная система с говорящим за себя названием Nano Server. В результате масштабного рефакторинга существенно сокращен размер ядра, а сама система поддерживает удаленную установку и управление. Nano Server оптимизирован для облачных вычислений и DevOps разработки. Наконец-то нам обещают меньше патчей и апдейтов, а также быструю перезагрузку. Редакция Nano Server будет доступна уже в следующем релизе Windows Server, поэтому ждать остается не так уж и долго.

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

уменьшение размера VHD-файла на 93%
потребуется на 92% меньше патчей — (возможно речь идет о потенциальном количестве, за счет сокращения числа устанавливаемых сервисов)
снижение числа перезагрузок на 80%

Чтобы все это достичь пришлось избавиться от GUI, отказаться от поддержки 32 битных приложений, MSI и от целого ряда других, стандартных для Server Core, компонентов. В том числе, нет поддержи локальной авторизации и RDP — все управление осуществляется только удаленно через PowerShell и WMI. Для обеспечения удобства управления нас ждут изменения в PowerShell — будут поддерживаться, например, передача файлов и удаленная отладка. Кроме того, планируется представить новые web-утилиты как замену локальных инструментов управления.

Так как Nano Server это именно переработанная версия Windows Server, то полная совместимость с API (в рамках оставшихся в Nano Server компонентов) упростит разработку нового ПО. Visual Studio будет полностью поддерживаться, так что экосистема не должна оказаться пустой.

Например, в Chef плотно занимаются интеграцией с Nano Server, заявляя о том, что новая платформа (Nano Server плюс автоматизация от Chef) станет отличным решением для разработки в стиле DevOps.

Само собой, Nano Server будет и отличной базой для развертывания на нем контейнеров Windows Server и Hyper-V контейнеров. В мире Linux аналог уже доступен — Red Hat Enterprise Linux Atomic Host.

Уже в конце апреля, на конференции Build 2015, можно будет увидеть контейнеры Windows «живьем».

Источник:

http://blogs.technet.com/b/server-cloud/archive/2015/04/08/microsoft-announces-new-container-technologies-for-the-next-generation-cloud.aspx

SCSI Decoder

noreply@blogger.com (Andrew Ivanov) — Thu, 02 Apr 2015 09:00:00 +0000

Нашел в почте письмо от RedHat про полезную утилиту - SCSI Decoder.

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

Справа увидим список найденных ошибок, а после нажатия "DECODE" получим не только детальное описание ошибки, но и ссылку на возможное решение проблемы. В данном примере это будет:

SCSI error: return code = 0x08000002 - Illegal Request
* We are getting errors only for first LUN coming from Storage * This LUN is the command device coming from Hitachi Array * Error snippet from messages file: ~~~ kernel: sd 5:0:0:0: SCSI error: r
https://access.redhat.com/solutions/369363

Вот и все! С высокой вероятностью мы получим решение проблемы в пару кликов. И не забываем, что ошибки SCSI это не только SCSI диски (которые поди найди сейчас), но и например СХД, подключенные по FC.

Для доступа к декодеру потребуется логин на Red Hat Customer Portal, но никакие подписки и прочие затратные мероприятия от вас не требуются.

С интересом потратил часть вчерашнего вечера на поиск в почте писем с вопросами про ошибки и скармливание этих ошибок в декодер - когда-то можно было много времени сэкономить на этом!

Data Ontap 8.3 GA - новости и изменения

noreply@blogger.com (Andrew Ivanov) — Fri, 27 Mar 2015 09:00:00 +0000

Я совсем недавно уже писал про одно из нововведений в cDOT 8.3 - поддержку MetroCluster, но считаю нужным упомянуть и другие возможности, которые пользователи получат в новой версии. Список изменений весьма обширен - более 40 из 90 страниц отведены перечислению именно новых возможностей.

Что первым бросается в глаза? Конечно система управления - теперь System Manager интегрирован в Data ONTAP! Больше не нужно устанавливать на компьютер приложение, мучаться с версиями Java - достаточно открыть браузер, набрать адрес и после этого мы получаем полноценную систему управления (на HTML5). Уверен, это это придется по душе очень многим админам!

Еще одна приятная возможность для администратора - можно сильно упростить жизнь за счет использования 'network subnet'. Вместо того, чтобы назначать каждому логическому интерфейсу (LIF) конкретный адрес, администратор назначает пул адресов для широковещательного домена (broadcast domain). А уже при создании LIF, ему присваивается адрес из пула. Такой подход может быть крайне удобен в больших и часто меняющихся инфраструктурах.

Использование IP Spaces для изоляции SVM - еще одна возможность для построения развитой инфраструктуры. IP Spaces позволяют получать доступ к кластеру из несвязанных подсетей - даже если клиенты имеют одинаковые адреса:

В данном случае, клиенты в IPSpace A физически отделены от клиентов IPSpace B, но работают с одним кластером. Эта возможность актуальна для компаний, которые предоставляют системы NetApp в аренду "по кусочкам".

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

В больших конфигурациях, можно получить слишком большое количество путей от хоста до LUN - это является проблемой управления, но может влиять и на производительность. Для того, чтобы поддержать число путей в рамках разумных границ, теперь используется технология Selective LUN Mapping (SLM) - хост видит только нужные пути до системы, а лишние спрятаны (но могут быть включены при необходимости. Коллеги писали об этом совсем недавно (есть примеры команд).

Автоматизация процесса обновления ПО. Еще одна "крутая фишка". В самых разных ситуациях я сталкивался с тем, что система работает, на ней наблюдаются какие-то проблемы (не критичные, но малоприятные). Спрашиваешь, а почему не обновить на новый микрокод - там же есть исправление как раз вашей проблемы? "Мы бы с удовольствием, но для нас очень проблематично выделить время на обновление и столкнуться с угрозой остановки сервиса. Кроме того, это очень сложная процедура." И это длится год за годом! Теперь такая проблема больше не должна волновать - администратору достаточно всего трех команд, чтобы запустить процесс обновления:


cluster image package get
cluster image validate
cluster image update

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


cluster image show-update-progress

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

Обновлять систему стало легко, но так ли просто обновить несколько кластеров сразу на нескольких площадках, объединенных в единую инфраструктуру? Далеко не факт. Но если мы используем репликацию (Snap Mirror), то для ее нормального функционирования нужно было поддерживать одинаковые версии и всегда обновлять сначала "получателя" данных. В случае, если репликация идет в обе стороны, приходится останавливать SnapMirror на время апгрейда. Теперь у нас есть version-flexible SnapMirror, благодаря которому можно спокойно обновлять любой из узлов без остановки репликации. Еще одна задача администрирования решена! Для поддержки распределенной отказоустойчивый инфраструктуры это очень важное нововведение.

Раз уж затронули SnapMirror, то теперь при передаче данных используется компрессия, что позволяет снижать нагрузку на сеть и каналы связи. Не могу сдержаться - FalconStor NSS умел так делать еще лет 10 тому назад! :) В любом случае, это еще один плюс в копилку.

У заказчиков, использующих SnapVault появлиась возможность восстанавливать данные на уровне отдельных файлов (технология On-Demand Data Management). Данные доступны пользователю сразу и он может с ними работать, пока происходит копирование на основную систему.

Перейдем к производительности и эффективности хранения.

Больше не записываем нули на диски! Для томов с включенной дедупликацией, в онлайне находятся блоки из одних нулей и они не записываются на диски (Inline zero write detection and elimination). В VMware, например, мы создаем eager zeroed диски, чтобы обеспечить неизменный уровень производительности, но из-за архитектуры WAFL, нам нет нужды записывать нули на диски. Кроме того, существуют и другие специфические задачи, когда за счет исключения нулевых блоков, мы получаем заметный прирост производительности.

Еще одно направление оптимизации - All-Flash Optimized personality. Для All-Flash систем мы отказываемся от всех алгоритмов по оптимизации работы с обычными дисками, так как все это бесполезно для SSD дисков. Как следствие, производительность системы возрастает, а там, где борьба идет за микросекунду, любая оптимизация может быть критичной. AFF personality доступна только для FAS80xx и не позволяет использовать обычные диски - только SSD.

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

Следить за производительностью стало удобнее - собирать статистику можно уже не на уровне агрегата, а на уровне отдельного тома (qos statistics volume show).

Что касается эффективности, то самая большая проблема в младших системах (с небольшим числом дисков) это объяснить заказчику, куда делось все то дисковое пространство, за которое он заплатил. Для каждого контроллера отдельные диски выделим под root (рекомендуется RAID-DP) плюс еще пара дисков в резерв (spare). И вот, в самой младшей системе от 12 дисков осталось 2 под данные.

Да, конечно, можно немного "поколдовать" и улучшить ситуацию (здесь RAID4, там один spare диск) - в результате, что-то подходящее можно собрать. Но, во-первых, это нужно делать руками (и игнорировать предупреждения системы), а, во-вторых, даже в этом случае, мы получаем не слишком-то большой объем. Поэтому систему из 12 дисков сложно использовать как active-active, так как на одном из контроллеров будет всегда слишком мало дисков. Наконец-то, в Data ONTAP 8.3 появилось решение - Advanced Disk Partitioning (ADP). После метрокластера, мне кажется, это вторая по значимости новость - можно на одних и тех же физических дисках размещать два агрегата - для root и для данных. Причем, для root мы можем собрать RAID-DP и два spare "блока", а для данных один резервный блок. Теперь конфигураций с 12ю дисками можно уже пользоваться "из коробки" - полезного пространства стало гораздо больше.

И даже для системы с 12 дисками можно использовать active-active режим работы (полезная емкость конечно ниже, но мы можем делить нагрузку между контроллерами):

ADP очень хорошо работает и для AFF конфигураций - стоимость SSD дисков довольно высока и "выбрасывать" их на создание рутового агрегата довольно расточительно. Благодаря ADP, AFF система будет показывать лучшую экономику, при сравнении с конкурентами, чем ранее.

И третьим плюсом от ADP является оптимизация нагрузки на SSD диски в FashPool - на одних и тех же дисках можно создать агрегаты для каждого из контроллеров. Широкий страйпинг позволит обеспечить лучшую производительность системы.

Advanced Disk Partitioning можно использовать на младших системах (22хх) для совмещения root и data агрегатов на одних дисках, всех AFF конфигурациях и для всех систем в FlashPool.

В версии 8.3 также существенно увеличен максимальный объем FlashPool - рост в 4 раза:

FAS8080 EX	144 TiB
FAS8060	72 TiB
FAS8040	48 TiB
FAS8020	24 TiB
FAS25xx	16 TiB

Я кратко описал только часть тех новых возможностей, которые стали доступны после выхода версии 8.3 Data ONTAP. Кто-то конечно мог уже попробовать и оценить многие из перечисленных возможностей, обновившись еще на 8.3 RC1 версию, но сейчас, когда GA уже здесь, можно планировать апгрейд и тем, кто не решался использовать ранние версии. Безусловно, очень важно внимательно изучить документацию перед апгрейдом - всегда есть нюансы.

Почитать на тему:

Clustered Data ONTAP 8.3 Release Notes
Clustered Data ONTAP 8.3 Network Management Guide
Clustered Data ONTAP 8.3 SAN Administration Guide
Clustered Data ONTAP 8.3 Physical Storage Management Guide

Data ONTAP 8.3 и MetroCluster

noreply@blogger.com (Andrew Ivanov) — Wed, 25 Mar 2015 05:00:00 +0000

На прошлой неделе объявлено о GA версии 8.3 Clustered Data ONTAP - внутри довольно много нововведений. Больше “совместимой” 7-mode версии нет - только clustered вариант. Но одним из ключевых изменений я вижу вот это:

"Starting with Data ONTAP 8.3, MetroCluster configurations are supported in clustered Data ONTAP."

Начиная с Data ONTAP 8.3 в clustered Data ONTAP поддерживаются конфигурации MetroCluster.

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

Как только мы начинаем говорить про отказоустойчивость, сразу появляются два важных параметра:

RPO, Recovery Point Objective - максимально допустимая потеря данных при сбое
RTO, Recovery Time Objective - максимально допустимое время восстановления сервис СХД (обеспечение доступности данных для приложений)

Отказоустойчивость в системах с MetroCluster в Data ONTAP 8.3 базируется на двух столпах:

NDO (NonDisruptive Operation) при большинстве локальных сбоев внутри датацентра (отдельные компоненты, узел кластера, сбои сети и т.п.). Кроме того, обеспечивается непрерывность обслуживания и во время проведения планового обслуживания системы.
Непосредственно MetroCluster повышает доступность за счет наличия второго датацентра и зеркалирования данных на удаленную систему

Между узлами кластера обеспечивается автоматическое переключение в рамках одного датацентра и ручное переключение нагрузки при полном сбое в основном ЦОДе. При этом, заказчик получает нулевой RPO (данные не теряются) и RTO порядка 120 секунд для запланированных переключений между площадками и порядка несколько минут для “аварийных” переключений (администратору достаточно выполнить только одну команду).

Функционирование MetroCluster “прозрачно” для ОС и прикладных приложений, поэтому нет необходимости во внесении существенных изменений в имеющуюся инфраструктуру. Переход на резервную площадку не требует переподключения хостов к SAN или NFS ресурсам, так как все пути до СХД остаются неизменными. Только для SMB клиентам понадобится подключиться заново (в силу ограничений протокола).

MetroCluster интегрирован непосредственно в Data ONTAP и не требует никаких дополнительных лицензий - нужно только правильно спланировать архитектуру системы.

Больше нет разделения на Fabric MetroCluster (FMC) и strech MetroCluster (SMC) - есть только один MetroCluster, который может быть использован на расстояниях до 200км.

Как уже наверное стало понятно из вышесказанного, в новой версии мы больше не “растягиваем” одну пару контроллеров между площадками, а размещаем на каждой площадке по HA-паре. Несомненный плюс такого подхода - снимается одно из главных возражений против использования метрокластера, которое регулярно приходилось слышать. А что будет, если у нас выйдет из строя один контроллер? Раньше нас ждал переезд на вторую площадку (как правило, в ручном режиме) и, безусловно, такие мероприятия доставляют мало удовольствия. В то же время, исследования показывают, что незапланированные проблемы, приводящие к выходу из строя целой площадки составляют всего около 1% от всех возможных нештатных ситуаций. Чаще всего вообще причина остановки - плановое обслуживание. Прозрачное переключение между узлами в HA-паре позволяет практически полностью избавиться от такого рода проблем - теперь плановые работы можно проводить именно “по плану”.

Что же нужно, чтобы “построить” MetroCluser?

Для связи между площадками используются FC линки, которых желательно иметь не менее четырех.
Также потребуется установить на каждой площадке по 2 FC коммутатора
Все контроллеры должны иметь доступ к дискам на всех площадках, поэтому дисковые полки нельзя подключить через SAS напрямую, а нужно использовать FC-SAS гейты (ATTO 6500N).
Желательно на каждой площадке установить не менее 4 дисковых полок (минимум 2). Когда каждая полка содержит диски только одного пула, администрировать систему заметно проще - не нужно вручную назначать диски контроллерам, а значит и запутаться вероятность ниже.
По FC-VI карте в каждый контроллер
Все правильно подключить и настроить :)

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

Как видим, получается не такую уж и маленькую система. При этом, совсем младшие модели будут иметь много ограничений по доступным портам - часть слотов расширения займут FC-VI карты.

После того как все настроено, данные будут зеркалироваться между площадками. Операции чтения по-умолчанию происходят с “локальных” для контроллера дисков. Контроллер A1 будет всегда читать данные с дисков в "A1 Plex0". Однако, для некоторых типов нагрузки, с точки зрения производительности, может быть выгоднее включить чередование операций чтения с разных площадок (это можно настроить). А вот операции записи будут подтверждаться только после того, как второй контроллер в паре и парный контроллер на второй площадке отрапортуют о получении данных (в NVRAM).

Помимо данных, зеркалируется и содержимое NVRAM контроллеров. Поэтому каждый контроллер использует для “своих” нужд только четверть от общего объема NVRAM и реплицирует данные на два других контроллера (локального и удаленного партнера). В нормальном режиме функционирования в NVRAM каждого контроллера, помимо "своих" данных, есть еще и данные двух других контроллеров (в NVRAM контроллера A1 - данные из NVRAM контроллеров A2 и B1). Еще четверть резервируется на случай выхода из строя одного из контроллеров после сбоя на площадке, т.е. на случай, когда у нас останется в живых только один контроллер из четырех. И даже в этом случае система будет продолжать работать!

Конечно, думая о внедрении MetroCluster, мы должны помнить и об ограничениях:

Нельзя защитить только часть данных - в MetroCluster должны дублироваться абсолютно все данные. На двух площадках всегда должно быть одинаковое количество дисковых ресурсов и нельзя создать агрегат без зеркалирования. Конечно можно на одной площадке использовать 60% доступных локальных дисковых ресурсов, а на второй 40%. Такая схема будет поддерживаться, но зеркалировать нужно все.
Не поддерживаются Infinite Volumes.
Не поддерживается Advanced Disk Partitioning.
Не поддерживается NSE (NetApp Storage Encryption). Если требуется шифрование, можно использовать виртуализацию СХД и подключить сторонние системы, которые такой режим поддерживают.
Действуют ограничения на количество SSD дисков в стеке полок (не более 48). Кроме того, рекомендуется не смешивать в одной полке SSD и обычные диски.
Ограничение конкретной модели FAS на число дисков распространяется не на HA-пару, а на 4 контроллера (т.е. на две площадки), так что на каждой площадке может быть не более 50% от возможного числа дисков.
Рекомендуется “ручное” переключение между площадками в случае сбоя
Восстановление всегда "ручная” операция, требующая вмешательства администратора СХД

Еще несколько слов про переключение между площадками. Рекомендация делать переключения вручную неслучайна - вероятность выхода целой площадки из строя весьма мала, но последствия могут быть самыми разными, поэтому важно понимать что мы делаем и зачем. Кроме того, может быть ситуация, когда обе площадки живы, а вот канал связи между ними потерян - в таком случае, никакие переключения делать не стоит. Обычно в таких случаях используется третья площадка, которая “следит” за происходящим. В случае с MetroCluster есть т.н. tiebreaker software, который и выполняет эту роль. Да, с его помощью можно полностью автоматизировать переключение на резервную площадку при сбое, но, поверьте, это не самая лучшая идея. Поэтому лучше использовать этот софт только как средство дополнительного мониторинга.

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

Почитать по теме:

Data ONTAP 8.3 Release Notes

NetApp MetroCluster Product Documentation

TR-3982: Introduction to Clustered Data ONTAP

Microsoft - Software Defined Datacenter легко!

noreply@blogger.com (Andrew Ivanov) — Fri, 20 Mar 2015 05:00:00 +0000

В то время как партнеры VMware уже поставляют системы EVO:RAIL, которые могут быть полностью развернуты для использования всего за 15 минут, Microsoft выпускает электронную книгу "Microsoft System Center Deploying Hyper-V with Software-Defined Storage & Networking".

Всего 236 страниц и вы сможете легко:

выбрать железо
спланировать архитектуру
развернуть кластер
настроить сеть
настроить дисковые ресурсы

Вот, теперь можно и начать разворачивать виртуальные машины!

В 15 минут конечно не уложились и попутно настроили десяток серверов, но зато "бесплатный" гипервизор и вся инфраструктура на базе Microsoft. Это конечно все сарказм и шутки - документ на самом деле интересный и полезный. Стоит прочитать или хотя бы помнить, что он существует.

Если VMware предлагает EVO:RAIL с тем, чтобы пользователи могли сами развернуть всю инфраструктуру максимально быстро при минимальных знаниях, то Microsoft, по всей видимости, дает возможность партнерам заработать на сервисе и продавать заказчикам услуги по развертыванию. Это конечно имеет смысл, но вот вопрос что выберет партнер - развернуть за 15 минут VMware и оставшееся время потратить на обучение сотрудников заказчика, либо потратить день на развертывание Hyper-V?

Очередное пополнение среди конвергентных решений: Huawei + DataCore

noreply@blogger.com (Andrew Ivanov) — Wed, 18 Mar 2015 05:00:00 +0000

Huawei и DataCore объявили о партнерстве в области Software Defined Storage и hyperconverged систем.

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

Конвергентная система состоит из серверов Huawei FusionServer RH с предустановленным программным обеспечением DataCore SANsymphony и поддерживает различные гипервизоры (Hyper-V и VMware). Максимальная конфигурация включает 64 узла в кластере, а минимально необходимо только 2 узла, чтобы обеспечить отказоустойчивость. Решение не ограничивается простым кластером - за счет синхронной репликации на расстояниях до 100м обеспечивается катастрофоустойчивость в распределенном кластере. При правильной организации, полный сбой на одной из площадок не приведет к остановке всей инфраструктуры. Кроме того, поддерживается и асинхронная репликация - все это позволяет строить полноценные катастрофоустойчивые решения.

DataCore Random Write Accelerator позволяет существенно ускорить операции записи за счет использования быстрых SSD дисков, а многоуровневое хранение (multi-tiering) повысит не только скорость работы, но и эффективность использования дискового пространства.

Отличительной особенностью данного решения является то, что заказчик не ограничен в использовании лишь встроенных дисковых ресурсов (и DAS полок). SANsymphony это, по сути своей, еще и виртуализоватор СХД, поэтому в систему можно подключать как имеющиеся, так и новые системы хранения. Не секрет, что в SDS довольно низкая утилизация дискового пространства - в силу изолированности узлов требуется, как минимум, две копии данных плюс дополнительные резервы на снапшоты и пр. Использование внешних СХД может увеличить утилизацию дискового пространства, при этом, управление ресурсами будет по-прежнему сосредоточено в одном месте.

Сотрудничество Huawei и DataCore уже имеет некоторую историю - вот один интересный документ с тестом DataCore на оборудовании Huawei "Oracle OLTP Performance Acceleration Using Huawei OceanStor Dorado and DataCore SANsymphony-V Storage Virtualization Gateway”.

Единственное, что меня всегда немного “напрягало” в SANsymphony это то, что он работает в Windows среде, но, с другой стороны, StarWind тоже работает и ничего :)

Учитывая, что сейчас Huawei может предложить практически любое оборудование, начиная от серверов и СХД, заканчивая инженерными системами в ЦОД, данное решение позволяет получить законченную конвергентную систему от одного вендора, которая отлично масштабируется и сможет закрыть практически все требования. А уж если вспомнить про текущую политическую ситуацию, такое решение от азиатского вендора может оказаться весьма и весьма интересным как для "станционных" компаний, так и для тех, кто опасается возможных ограничений.

Полезные ссылки для подготовки любой презентации

noreply@blogger.com (Andrew Ivanov) — Fri, 13 Mar 2015 14:00:00 +0000

С удовольствием сходил на конференцию "Бизнес и ИТ. Вокруг ЦОД. Вокруг Облака. Вокруг IP” - это одно из немногих мероприятий, с которого не хотелось уйти с середины. Дмитрий Мацкевич - молодец! :)

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

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

Когда готовите презентацию, отодвиньтесь на пару метров от экрана и сдвиньтесь вбок. Хорошо, если у вас монитор с не очень большим углом обзора - вот примерно так 50% аудитории и будут видеть ваши слайды. Удобно, все понятно на слайде? Если нет - переделать срочно!

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

Никогда не используйте 50 оттенков серого на слайде - проектор передаст из низ 2 (или 1), а остальные будут либо черными, либо белыми. Хуже могут быть только желтый, розовый и голубой цвета - они вообще должны быть под запретом. Думайте про используемые сочетания цветов.

А вот обещанный “must read":

Seth Godin: 10 советов, как готовить презентацию
http://blog.ted.com/10-tips-for-better-slide-decks/

"No more than six words on a slide. EVER. There is no presentation so complex that this rule needs to be broken."

Garr Reynolds: The Naked Presenter / Обнаженный оратор
http://amzn.com/0321704452
https://www.ozon.ru/context/detail/id/28289241/
Chuck Hollis:
http://chucksblog.emc.com/chucks_blog/2010/06/from-presenting-to-engaging.html

"went from 40 slides, to 20 slides, to 10 slides, to just a few as conversation starters... And then I took the biggest step of all -- no slides."

http://chucksblog.emc.com/chucks_blog/2013/06/how-i-give-a-really-good-customer-presentation.html
Просто для души почитать:
http://presentationzen.blogs.com

Sandisk выходит на новые рынки

noreply@blogger.com (Andrew Ivanov) — Wed, 11 Mar 2015 05:00:00 +0000

Компания Sandisk, которая всем хорошо известена как производитель флешек и SSD дисков, на днях представила свои новые продукты, предназначенные на этот раз вовсе не для домашнего использования. Новинками являются внешние системы хранения InfiniFlash IF100, IF500 и IF700.

И первое, то бросается в глаза, это конечно прекрасный дизайн передней панели системы InfiniFlash IF100:

Разве может быть что-то круче? Разве что только новый IBM z13.

IF100 это не только самостоятельный продукт, но и исходный блок для систем IF500 и IF700. Фактически IF100 это просто JBOF (Just a Bunch Of Flash) - никакого интеллекта, только мощь, только объем. Всего в 3U размещается половина петабайта (512ТБ или 256ТБ - на выбор)! Помимо фантастической плотности, неоспоримым преимуществом является потребляемая мощность - меньше 0.5кВт. Вот уж точно отличная возможность экономить на счетах за электричество! Система InfiniFlash построена на 64 картах с Flash памятью проприетарного формата, каждая карта имеет объем 8ТБ и является энергонезависимой (выключения питания не страшны).

Система имеет 8 независимых SAS портов для подключения серверов. Традиционно для внешних систем, зарезервированы основные компоненты, такие как вентиляторы и блоки питания. Все основные компоненты могут быть заменены без отключения системы (горячая замена). Однако, что касается самой flash памяти, то никаких средств резервирования нет - только горячая замена отдельных модулей. Пользователь должен сам заботиться о том, чтобы в случае сбоя одной карты или всего JBOF, данные не пропали.

Так как IF100 предназначен прежде всего для Hadoop, такое “пренебрежение” отказоустойчивостью оправдано, но есть и одно "но". Производитель декларирует стоимость порядка 1$ за ГБ. Но, если мы будем защищать данные стандартными средствами, нам потребуется 3 копии, а это уже будет 3$ за ГБ. Звучит конечно не так страшно, но давайте вспомним, что у нас каждая система имеет объем 512ТБ, а это уже 1.5 миллиона $. Как говорил крот в небезызвестном мультфильме, “а в год получается не так уж и мало”.

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

Давайте посмотрим на производительность. Декларируется величина не ниже 780.000 IOPs (данных о времени отклика не приводится - только “меньше 1мс"), хотя в некоторых материалах я видел и другие цифры - до 1 миллиона IOPs (возможно такие значения достигаются в каких-то "хитрых" тестах). С одной стороны, это довольно хороший результат, но, с другой стороны, если мы опять учтем объем системы, то величина совсем не такая уж и фантастическая - меньше 2IOPs на ГБ. Для обычного SSD можно получить в разы и десятки раз более высокие показатели. При этом, номинальный трансфер составляет 7ГБ/сек и это тоже далеко не чудеса производительности - на рынке есть системы, которые показывают результаты лучше.

Если к JBOF IF100 добавить интеллекта, то получится уже IF500 - внутри нее работает InfiniFlash Operating System (OS), которая позволяет строить горизонтально расширяемую систему. IF500 уже полноценная СХД, которая обеспечивает унифицированный доступ (блочный, файловый, объектный - все на базе Ceph), а кроме того включает традиционные “enterprise” возможности - мгновенные снимки, репликацию и thin provisioning. В комплект IF500, помимо JBOF IF100, входит и пара серверов, на которых выполняется InfiniFlash OS.

Также анонсирована система IF700, которая нацелена скорее на классические бизнес-приложения и включает SanDisk ION Accelerator, для создания высокопроизводительной системы с блочным доступом (от 128ТБ до 512ТБ). Защита данных, как и в IF100, вновь отдается на откуп прикладному приложению.

Что ж, очень интересное начало! Big data рынок растущий и новые решения будут востребованы. Некоторый скепсис вызывает производительность - здесь я вижу только одну причину странных величин производительности в расчете на объем: в первом поколении систем старались сделать работающую систему с минимально достаточными для узкой задачи параметрами (hadoop). А когда (и если) получится преодолеть системные ограничения новой платформы, начать более активно выводить InfiniFlash и на другие рынки. Пока мне действительно сложно представить новое детище Sandisk где-то вне big data.

HP приобретает Aruba Networks

noreply@blogger.com (Andrew Ivanov) — Fri, 06 Mar 2015 14:00:00 +0000

HP объявили о приобретении Aruba Networks - компании, которая хорошо известна на рынке беспроводных сетей. Сумма сделки порядка 2.7 млрд$ - довольно внушительная сумма, если учитывать результативность прошлых попыток занять твердые позиции на этом рынке. А такие попытки у HP уже были - в 2008 году была приобретена Colubris (кто-то еще помнит про них?). Потом, вместе с приобретением 3Com, была еще одна попытка, но и она не имела серьезного успеха. Да, какие-то wireless продукты есть у HP в линейке и поставляются заказчикам, но в корпоративном секторе о какой-то их значимой доли говорить явно нельзя.

Процесс покупки должен завершиться во второй половине этого года. Интересный вопрос предстоящей сделки - наличие у Aruba Networks множества OEM-соглашений. Технологии Aruba сейчас продают Alcatel-Lucent, Brocade, Dell, Juniper - что предпримут они и что будет предпринимать HP в этом отношении? И конечно, Dell в этом списке интригует больше всего - не будут же они перепродавать продукцию прямого (и самого главного) конкурента, только чтобы сохранить доступ к продуктовой линейке Aruba. Узнаем ли мы о еще одном приобретении, на этот раз Dell-ом, другой сетевой компании или Dell только выберет нового поставщика? Ответ, я думаю, будет уже в этом году.

Я позволю себе короткую цитату из пресс-релиза HP:

At the same time, the industry is about to go through the next major wave of wireless protocol roll-out with 802.11ac, ushering in another significant change in wireless performance. Over the next 3-5 years, we believe this wave will drive a massive network refresh not just to our customers’ wireless access points, but to their campus switches as well.

В то же время, индустрию вот-вот подхватит волна внедрения протокола 802.11ac в беспроводные сети, что приведет к очередному скачку производительности. Мы считаем, что в течение ближайших 3-5 лет это станет причиной не только массовой замены беспроводных точек доступа, но и коммутаторов во всем кампус. (перевод мой)

Все это безусловно верно и текущая ситуация создает очень неплохую перспективу на ближайшие годы. Но хочется надеяться, что весь накопленный в Aruba потенциал R&D не похоронят в ближайшие год-два, а, напротив, получится его эффективно использовать для развития всего сетевого направления. А это, в свою очередь, даст возможность серьезно конкурировать с Cisco на ее поле.

IBM FlashSystem - что за RAID внутри?

noreply@blogger.com (Andrew Ivanov) — Fri, 06 Mar 2015 05:00:00 +0000

Раз я упомянул анонс новых систем IBM FlashSystem 900 и V9000, то наверное стоит немного уделить внимания уникальной “фишке” этих систем - реализации отказоустойчивости.

В FlashSystem используется RAID5 для защиты от сбоя всего модуля MicroLatency, но это далеко не единственная технология, обеспечивающая отказоустойчивость:

RAID5 защищает систему от сбоя модуля. В зависимости от числа модулей, конфигурация массива вальируется от 2D+1P+1HS, до 10D+1P+1HS. В системе всегда только один RAID массив для модулей, поэтому объем всех модулей должен быть одинаковым
RAID5 внутри каждого модуля защищает от сбоя отдельного чипа
Variable Stripe RAID внутри каждого модуля защищает от частичного сбоя чипов NAND
ECC на уровне чипа защищают от битовых и блочных ошибок

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

Совместное использование двух уровней RAID ("внутри” отдельных модулей и между всеми модулями) и носит фирменное название 2D RAID (two-dimensional RAID).

Благодаря такой многоуровневой защите можно минимизировать возникновение ошибок, приводящих к необходимости менять целый модуль MicroLatency. Кроме того, сохраняется возможность использовать RAID5 (а не RAID6) и не сталкиваться с повышенными рисками множественных ошибок (хотя объем самих модулей может достигать 5.7ТБ).

Технология RAID “внутри” модуля MicroLatency была запатентована еще компанией TMS (где и родились предшественники нынешних FlashSystem - тогда они назывались RamSAN) и носит название Variable Stripe RAID (VSR). Она позволяет не просто обеспечить отказоустойчивость при большинстве частичных сбоев внутри модуля, но и позволяет большой срок службы модуля, а это, в свою очередь, снижает стоимость, так как не нужно закладывать дополнительные расходы на “лишние" замены в гарантийный срок.

Каждый MicroLatency модуль имеет внутри несколько чипов Flash и 4 FPGA контроллера, которые и реализуют VSR. Каждый из этих контроллеров, в свою очередь, “отвечает” не более чем за 20 чипов. Но RAID внутри модуля построен не на уровне чипов, а на уровне слоя (plane) в отдельных чипах (по 16 слоев в каждом чипе). Все это позволяет спокойно пережить сбой до 256 блоков перед тем как весь слой будет считаться сбойным. Чтобы модуль все-таки вышел из строя необходимо, как минимум:

признать сбойными 64 слоя
сбой 4 чипов в модуле целиком

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

Отличительной особенностью VSR является:

RAID защищает не отдельный чип, а только слой чипа. Это позволяет гораздо эффективнее использовать модули, не производя лишних замен и перестроений массивов;
страйп не фиксирован в размере - в зависимости от состояния слоев, он может быть не в стандартной конфигурации 9D+1P, а 8D+1P, 7D+1P или 6D+1P.

Именно вариативный размер страйпа позволяет максимизировать объем полезного пространства в модуле, не “отбраковывая” рабочие части остальных чипов. Давайте посмотрим как это работает. В случае, когда мы используем обычный RAID-массив (пусть даже и на уровне слоя микросхемы), сбой в любом из слоев приведет к тому, что нам будет нужно исключить все такие же (еще рабочие!) слои остальных чипов, чтобы сохранить архитектуру массива:

При использовании Variable Stripe RAID, нам достаточно перестроить страйп на меньшем количестве элементов:

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

Кроме того, VSR работает “внутри” каждого модуля, не требуя для восстановления "перекачки" данных к центральному процессору или FPGA, отвечающему за RAID на уровне системы. А это, в свою очередь, позволяет избежать деградации производительности при перестроении массивов, что для All Flash систем, где мы ожидаем получить гарантированный уровень производительности, очень важно.

И вот только в том случае, когда исчерпаны все “внутренние” ресурсы MicroLatency модуля по обеспечению отказоустойчивости, система использует RAID5 между модулями и задействует spare модуль для перестроения массива.

Что почитать:

IBM Redbooks про FlashSystem

Патент TMS на технологию VSR - здесь все очень подробно про VSR

Вышла LeftHand OS 12

noreply@blogger.com (Andrew Ivanov) — Wed, 04 Mar 2015 05:00:00 +0000

Вышла версия 12 LeftHand OS для систем HP StoreVirtual.

Изменений не очень много, но есть и интересные:

Space Reclamation - теперь системы StoreVirtual поддерживают T10 UNMAP, что позволяет возвращать неиспользуемое дисковое пространство обратно в пул. Поддерживается как в VMware, так и в Windows.
HP StoreVirtual Multipathing Extension Module (MEM) - этот модуль оптимизирует доступ к данным по разным путям в vSphere 5.x (является аналогом StoreVirtual DSM для Microsoft MPIO). MEM, кроме того, оптимизирует трафик и в мультисайтовых конфигурациях.
Новый REST API - поддержка основных функций (выделение дискового пространства, создание и модификация пулов) через web based API.
Увеличена производительность репликации, а также скорость загрузки системы.

Новость не касается владельцев конвергентных систем HP 200-HC StoreVirtual - пока версия 12 для них не сертифицирована.

Стоит напомнить, что сейчас любой обладатель сервера на базе процессора Intel Xeon E5v3 имеет вполне легальную и бесплатную возможность использовать HP StoreVirtual VSA с объемом дискового хранилища 1ТБ. Лицензию можно зарегистрировать здесь. В комплекте нет только поддержки Adaptive Optimization (автоматическая миграция "горячих" данных на более быстрые диски). Да, cервер может быть любой! Совсем не обязательно быть покупателем техники HP.

StoreVirtual VSA (в бесплатном варианте или в виде demo-лицензии) замечательно подходит для ознакомления с продуктом - можно посмотреть все возможности, протестировать свое ПО. И, если все тесты увенчались успехом, можно смело переезжать на "железную" реализацию, а можно и остаться на VSA, если производительности хватает.

IBM FlashSystem 900 и V9000

noreply@blogger.com (Andrew Ivanov) — Tue, 03 Mar 2015 05:00:00 +0000

Совсем недавно были анонсированы новые системы хранения All Flash Array от IBM - FlashSystem 900 и V9000. Странно, но, как я уже писал, линейка FlashSystem не попала в “программу переименования за миллиард”, хотя интегрированная система FlashSystem V9000 вот уж точно должна была бы стать частью портфеля Spectrum.

В основе архитектуры IBM FlashSystem лежит идея о минимизации задержек на всем пути от внешнего интерфейса до чипа flash-памяти, на котором непосредственно и хранятся данные. Именно это позволяет получить очень хорошие результаты по производительности. Важно отметить, что когда мы говорим о производительности AllFlash систем, оценивать нужно не количество IOPs - их набрать не так уж и сложно, а в первую очередь о как можно низкой задержке (latency). Хорошим результатом можно считать результат меньше 1мс, но борьба уже идет за 500мкс и ниже.

В то время как многие другие производители активно используют стандартные процессоры в “ядре” своих СХД, IBM для FlashSystem продолжает выдерживать “железный” подход ("hardware only datapath”), когда вместо программного кода (пусть даже на разновидности real time OS) активно используются FPGA и кастомизированные компоненты.

Примечательно, что в системе используются не стандартные SSD диски, а специальные модули (MicroLatency Modules), это позволяет избежать “лишних” интерфейсов, а следовательно и лишних задержек. В 900й серии использование таких модулей позволяет обеспечить латентность 90мкс на запись и 155мкс на чтение. При этом объем одного такого модуля может достигать 5.7ТБ В прошлой серии (840) использовались eMLC (enterprise multi-level cell) чипы, в новой же системе перешли на использование более дешевых, но усовершенствованных MLC чипов от Micron (IBM Enhanced MLC). Смешно, но здесь машина IBM по созданию акронимов нашла на камень - не так уж просто будет объяснить клиентам чем eMLC отличается от E-MLC, поэтому наверное решили “Enhanced” в названии оставить без сокращений. :)

Хотя FlashSystem 900 и имеет фиксированную конфигурацию (только один модуль), но обладает необходимыми возможностями, для того, чтобы использовать систему для tier-1 приложений:

обновление микрокода без остановки (не требуется даже снижать нагрузку)
возможность заменить на ходу любой из компонентов системы
избыточность всех компонентов
шифрование данных (AES-XTS 256) без потери производительности

Полезная емкость системы варьируется в зависимости от объема и количества используемых MicroLatency модулей. Минимальный полезный объем - 2.4ТБ, а максимальный - 57ТБ. Важно помнить, что смешивать модули разного объема в одной системе нельзя, поэтому стоит аккуратнее просчитывать необходимые перспективы расширения.

Для подключения СХД к серверам можно использовать различные интерфейсы:

Fibre Channel (FC) - 8*16Gbit или 16*8Gbit
Fibre Channel over Ethernet (FCoE) - 16*10Gbit
iSCSI - 16*10Gbit
Infiniband - 8*40Gbit (QDR)

Все интерфейсные карты в системе должны быть одинаковыми и “смешивать” протоколы в рамках одной системы нельзя.

Декларируется, что FlashSystem 900 может обеспечить до 1.1 миллиона случайных операций чтения 4КБ блоков и до 10ГБ/сек поток на чтение данных. Для операций записи (100% random) - 600.000 IOPs и 4.5ГБ/сек.

Результатом гонки за минимизацией задержек стало полное отсутствие таких привычных для систем энтерпрайз-класса "фишек" как мгновенные снимки, репликация, компрессия, thin provisioning. Если какие-то из этих возможностей действительно необходимы, то у заказчика есть два пути: подключить FlashSystem 900 к своей системе виртуализации СХД (это может быть например SVC или V7000), либо приобрести уже интегрированную систему FlashSystem V9000.

По сути это своего рода гибрид из IBM SVC и FlashSystem 900, но это именно гибрид, а не просто две системы объединенные общей фронтальной заглушкой, как могло бы показаться с первого взгляда. Если мы подключаем FlashSystem к SVC, то мы должны управлять двумя системами, в то время как для V9000 мы имеем единую систему управления.

Во-первых V9000 позволяет расширяться как “вертикально” - добавив до 4х storage enclosures (до 57ТБ каждый), так и “горизонтально” - доведя количество контроллеров V9000 с двух до восьми (4 системы V9000 в кластере). Такое расширение позволит получить до 456ТБ полезного пространства исключительно на Flash. А если учесть возможности RealTime Compression, то мы получим уже 2.2ПБ полезной емкости. И это всего в 34U - достаточно одного(!) серверного шкафа, чтобы вместить весь этот ураган производительности и обеспечить такой объем. Но и это еще не все - можно использовать V9000 и как обычный виртуализатор СХД - все-таки это и SVC тоже, а значит можно к нему подключить имеющиеся системы и использовать на них такие возможности как thin provisioning, снапшоты и многие другие.

Кроме того, поддерживается репликация между V9000 и системами SVC, V7000 - можно строить катастрофоустойчивые решения на базе AllFlash системы IBM. По понятным причинам (полку с Flash модулями нельзя поделить между площадками) не поддерживается конфигурация распределенного кластера (streched cluster).

Конечно, программная “прослойка” между FlashSystem и серверами не обходится даром, поэтому мы вынуждены заплатить латентностью, но плата эта не так уж велика - мы все равно получаем 200мкс на чтение, а это действительно очень мало. Кроме того, за счет использования "горизонтального” масштабирования мы можем получить до 2.5 миллионов IOPs и поток до 19.2ГБ/сек (блоками по 128КБ). А за счет поддержки QoS в V9000 можно гарантировать приложениям требуемый уровень производительности дисковой системы.

Таким образом, FlashSystem 900 нацелена на тех заказчиков, которым нужна экстремально высокая производительность и они готовы пожертвовать программным функционалом систем enterprise-уровня (но хотят сохранить enterprise уровень отказоустойчивости и управляемости). Интегрированная система FlashSystem V9000 ориентирована на заказчиков, которым требуется не только производительность, но и возможность расширить систему, получить богатый программный функционал и возможность защитить данные с помощью репликации. Кроме того, V9000 может быть интересна тем, кто еще не имеет enterprise СХД в своем ЦОД, рассматривает возможности консолидации своих дисковых систем за счет виртуализации.

С нетерпением жду результатов SPC - IBM любит эти тесты. Как раз недавно неожиданно отметились HDS со своей системой VSP G1000, показав отличный результат в 2М IOPs при цене 1$ за IOPs. Вот только чтобы достигнуть цену в 1$ за IOPs пришлось дать почти 60% скидку на железо, зато теперь в лидерах рейтинга.

VMware Virual Volumes (VVols)

noreply@blogger.com (Andrew Ivanov) — Thu, 26 Feb 2015 05:00:00 +0000

Разбираясь в старых бумагах, нашел свой черновик с записями про 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 для снимка памяти

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).

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

Обратите внимание, что уже это существенно упрощает администрирование - нам достаточно подключить только один 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).

Итак, как выглядит процесс "запуска" системы для использования 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) - управление ресурсами хранения на основе политик

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

noreply@blogger.com (Andrew Ivanov) — Thu, 19 Feb 2015 16:00:00 +0000

В 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 на новый уровень - большой вопрос.

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

noreply@blogger.com (Andrew Ivanov) — Thu, 19 Feb 2015 05:00:00 +0000

Не знаю как вы, но я за собой многократно замечал, если мне нужен какой-то документ (и я понимаю, что он мне понадобится еще несколько раз в ближайшие дни), я просто кладу его на рабочий стол или в какую-то папку, которую я год назад создал, специально для “очень нужного документа”, и сам себе пообещал удалить через недельку, не позднее. Только сейчас в этой папке 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 в России.

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

noreply@blogger.com (Andrew Ivanov) — Mon, 16 Feb 2015 05:00:00 +0000

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

"Железный" состав довольно стандартный - 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 под удалённое управление

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

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

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

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

Ждём GA от других вендоров (NetApp уже скоро).

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

noreply@blogger.com (Andrew Ivanov) — Thu, 05 Feb 2015 19:54:00 +0000

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

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

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

Что касается аппаратной части, то здесь всё довольно стандартно - можно выбрать между двумя моделями - 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 подтверждает, что можно и с места высоко прыгнуть.

Sanbolic переходит под крыло Citrix

noreply@blogger.com (Andrew Ivanov) — Wed, 21 Jan 2015 06:25:00 +0000

Новость, которую я, признаться, ждал уже лет десять. 12 января Citrix объявил о приобретении компании Sanbolic (сумма сделки не называется).

Поначалу я думал, что покупателем окажется Microsoft, но после выхода 2008R2 (и тем более 2012) стало понятно, что никакого интереса уже не будет. Citrix выглядит вполне логично - подавляющее число внедрений, которые я видел и про которые слышал, это именно Citrix XenDesktop и XenApp. Были попытки занять другие рынки, но без фантастического успеха. Разве что, в свое время, решение было интересно для обработки видео (когда СХД были медленные, а каналы до серверов тесные).

С интересом жду, как дальше будет развиваться платформа ориентированная исключительно на windows-платформу. На что они будут нацелены, с кем из вендоров будут и дальше работать в плане интегрированной SDS платформы - месяцев через 6 будет понятно.

Ссылки в тему:
Как обеспечить высокую доступность XenDesktop?
Копирование файлов на CSV диск
Общий доступ к дискам (Sanbolic Melio FS и другие)
beta версия Sanbolic MelioFS 2009 R1
Сказка перед выходными

NetApp FAS8080 EX - новый флагман

noreply@blogger.com (Andrew Ivanov) — Fri, 20 Jun 2014 04:16:00 +0000

NetApp анонсировал свой новый флагман в линейке FAS8000 - FAS8080EX.

FAS8080 EX

До недавнего времени был “старичок” FAS6290, который почти ни в чем не уступал FAS8060 (а по некоторым параметрам и превосходил ее). Сейчас, после анонса, все встало на свои места. Решение разумное - время жизни (и цикл продаж) топовых систем заметно больше, чем для обычных рабочих лошадок. Поэтому “убивать” линейку 6290 не было никакого смыла. За прошедшее с момента анонса серии 8000 NetApp успел дождаться и обкатать новый чипсет (в FAS8080 EX используется 2.8GHz Ivy Bridge вместо Sady Bridge), линейка получила распространение (и не обрушила доверие клиентов) и уже сейчас вполне готова для новых инсталляций “большим дядькам”, которые ждут не только 100500 иопсов.

Что же мы получаем в новой системе? Не так уж и мало:

20 ядер на контроллер
128ГБ памяти на контроллер
16ГБ NVRAM на контроллер
уже привычный для 8000 богатый набор портов из коробки
12 слотов PCI-E Gen3 для расширения (на контроллер)

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

Контроллер FAS8080 EX (без IOXM)

Итак, FAS8080 EX с двумя контроллерами “из коробки” дает нам

8 портов 10GbE
8 универсальных портов UTA2 (можно настроить как 10GbE, либо как 16Gb FC - либо как комбинацию из 4*10GbE и 4*FC портов)
8 портов GbE (кто-то еще использует в таких системах? :) Шутка - конечно GbE все еще очень актуален
8 портов SAS для подключения полок расширения

И все это богатство можно расширять и расширять (напомню - 24 слота для дальнейшего расширения в двухконтроллерной системе).

Пока всё ещё нет 12G SAS для подключения полок расширения (но и самих полок тоже нет).

Напомню, что для линейки FAS8000 уже нет привычного разделения систем на “файлер” FAS и “виртуализатор” V-Series - поэтому нельзя заказать V8080EX, зато есть программная опция FlexArray Virtualization Software, которая избавляет нас от лишних продуктовых линеек и сложностей выбора при заказе. Сколько раз мне приходилось обсуждать с заказчиками чем отличается FAS от V-Series и что именно стоит заказывать! Сейчас вопрос выбора не стоит и обсуждать можно более важные вопросы.

То немногое, что не изменилось в FAS8080 EX по сравнению с FAS6290 это максимальный объем системы - 1440 дисков (5760ТБ), а также максимально поддерживаемое число SSD дисков — 240 (объемом от 100ГБ до 1.6ТБ каждый). FlashCache на контроллерную пару может достигать 16ТБ, а FlashPool — 36ТБ.

Традиционная пара портов интерконнекта между контроллерами может стать узким местов для производительности системы, поэтому в FAS8000 появилась возможность использовать 4 порта при использовании коммутируемого соединения. В FAS8080EX пошли еще дальше и разрешили подключать до 6 портов для Cluster Interconnect (конечно в этом случае потребуется дополнительная плата расширения). Рекомендованным режимом, как и для FAS8040/8060, является подключение 4х портов (2 по-прежнему поддерживаются, а 6 может потребоваться в экстремальных конфигурациях).

В поддержке кластерных конфигураций ничего не изменилось - максимум 24 ноды для NAS и 8 нод для SAN конфигураций.

Система поставляется с Data ONTAP® 8.2.1 RC2 и уже ждет заказчиков :)

Быть экспертом!

noreply@blogger.com (Andrew Ivanov) — Fri, 11 Apr 2014 04:58:00 +0000