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

В инфраструктуре из нескольких серверов задача миграции виртуальных машин между гипервизорами если и возникает, то редко и разово. А вот если счет серверов идет на десятки, то вероятность параллельного использования двух гипервизоров весьма высока - кто-то это делает для экономии на лицензиях, кто-то чтобы не класть все яйца в одну корзину. И  миграция виртуальных машин между 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 - остальным придется либо тратить на миграцию больше времени, либо искать альтернативы (про которые я, впрочем, пока не слышал).

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

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

Про 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 — он работает не в отдельной виртуальной машине, а “внутри” системы хранения. Такой вариант мне кажется более удобным для пользователя, хотя до первой проблемы однозначно не скажешь! :) 

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

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

Я совсем недавно уже писал про одно из нововведений в 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

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

Data ONTAP 8.3 и MetroCluster

На прошлой неделе объявлено о 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 

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

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

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 и уже ждет заказчиков :)

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

ASIC или процессор + софт?

Сразу две интересные заметки появились от ведущих производителей систем хранения - NetApp и  HP:

Better RAID Through Software: An In-Depth Look at the NetApp Firmware Parity Engine for E/EF-Series Systems

The 3PAR ASIC

Первая статья описывает текущую ситуацию в системах NetApp E-series (бывший LSI/Engenio). После многолетнего использования ASIC для расчета контрольных сумм, сейчас нагрузка по расчету данных для RAID перенесена в центральный процессор. С одной стороны, это конечно упрощает дизайн системы, кроме того, мы все прекрасно знаем, что производительность современных процессоров сделала огромный рывок (и продолжает "рвать" :) Поэтому многие компании спокойно используют программные решения (стоит упомянуть в первую очередь конечно различные реализации Software Defined Storage).

С другой стороны, в NetApp столкнулись с проблемой производительности (СХД может создать поток, превышающий возможности процессора). Можно говорить что это большой плюс ситем NetApp - загрузить процессор это тоже достижение! Справедливости ради нужно сказать, что в NetApp используется не совсем программное решение,  а аппаратные возможности процессоров Intel (Crystal Beach 3 DMA). Так вот, оказалось, что на больших нагрузках, процессор не может обработать весь поток, который могут обеспечить остальные компоненты СХД. Для дальнейшего повышения производительности, в новых версиях микрокода происходит автоматическое переключение на программный режим расчета контрольных сумм, что позволяет повысить интегральную производительность системы. Все управление процессом заложено в микрокод и "подкрутить" что-то своими руками не получится.

Новые возможности микрокода доступны в системах E5400/5500 и EF540/550 - остальные по-прежнему используют RoC чипы для расчета контрольных сумм.

С другой стороны баррикад, в HP продолжают восхвалять свой ASIC, использующийся в системах 3PAR. Безусловно, "заточенный" под определенные операции чип, можно снять множество головных болей с архитектора СХД. Здесь и предсказуемая производительность (в силу узкой специфичности чипа), реализация определенного функционала "в железе" (в 3PAR это, в первую очередь, thin provisioning), разгрузка центрального процессора для других задач (впрочем, это спорный аргумент - все зависит от качества кода "других задач").  

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

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

NetApp не стоит на месте–обновленный midrange FAS3220/FAS3250

Мне, с самого ее анонса, очень не нравилась модель NetApp FAS3210. Почему? Ведь это настоящий мультипротокольный MidRange, который поддерживает до 240 дисков и кучу крутых “фишек” от NetApp, скажете вы! Однако, при всех замечательных возможностях, система вышла, честно говоря, “так себе”. Основное ограничение – только два слота расширения. И это действительно проблема для тех, кто хочет получить масштабируемую систему – а зачем иначе брать midrange? Поставить FlashCache на 3210 тоже проблематично – постфактум всплыл ряд проблем, связанных с нехваткой памяти, поэтому заказывать FlashCache с определенного момента вообще стало нельзя. По этим причинам я всегда советовал либо FAS2000, либо FAS3240, который лишен указанных недостатков, и всячески отговаривал от FAS3210.

Буквально несколько дней назад ситуация радикально поменялась – были анонсированы две новые системы FAS3220 и FAS3250. Первая пришла на смену FAS3210, а вторая – на смену FAS3240. Что же изменилось?

Конечно обе системы получили более производительные контроллеры – в два раза больше процессорных ядер по сравнению с предшественниками. Кроме того, увеличился и объем памяти – он стал 24GB для FAS3220 и 40GB для FAS3250. Увеличился и объем NVRAM (3.2GB для FAS3220 и 4GB для FAS3250). Обратите внимание, что FAS3220 получил процессорную мощность, аналогичную системе FAS3240, а памяти даже на 8GB больше! FAS3250, в свою очередь, имеет в 2 раза больше ядер, чем FAS3270 (правда менее производительных) и такой же объем памяти.

Как обычно, отличается максимальное число дисков, которые можно подключить к системе – 240 (FAS3220), 720 (FAS3250) и 960 (FAS3270). С версии ONTAP 8.1.2 все СХД FAS3200 поддерживают до 240 дисков SSD.

Разумеется, теперь в младшую систему можно ставить FlashCache карты и использовать FlashPool (SSD+HDD в агрегате). Возможности FAS3220 соответствуют FAS3240 (1TB FlashCache на HA пару, либо 1.2TB SDD в FlashPool, либо 1.2TB комбинированно). FAS3250, как несложно догадаться, “догнал” FAS3270 - 2TB FlashCache на HA пару, либо 2TB SDD в FlashPool, либо 2TB комбинированно.

И, да, избавились от самого главного ограничения в FAS3210 – теперь в FAS3220 можно заказать контроллер с модулем ввода-вывода (IOXM), что дает нам до 6ти слотов на контроллер (12 слотов на систему). А это уже дает полет для фантазии в развитии системы хранения по мере роста требований к ней. А для FAS3250 вообще отказались от конфигурации без IOXM, что на мой взгляд очень правильно - правильный выбор можно и навязать! :)  С другой стороны, остается возможность заказать одноконтроллерную конфигурацию (вот зачем только?).

Также для FAS3250 сразу нужно выбрать одну из плат расширения для подключения хостов – либо 10Gbit Ethernet, либо 8Gbit FC.

“Набортные” порты никаких изменений не претерпели – как и прежде, это 4*GbE, 4*4Gbit FC, 4*6Gbit SAS на двухконтроллерный вариант.

Таким образом, две новые системы замечательно закрывают все потребности в сегменте midrange СХД. А если нужно что-то более производительное, то стоит обратить внимание либо на возможность объединения систем в кластер, либо на старшую линейку FAS6200.

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

NetApp: кэшируем в сервере

Всего пара месяцев прошла с момента официального объявления о сотрудничестве Fusion-io и NetApp с целью использования технологий Fusion-io в стеке NetApp Virtual Storage Tier.

На сегодняшний день в VST используются “родные” технологии NetApp – FlashCache и FlashPool, позволяющие эффективно повышать производительность системы посредством интеллектуального кэширования “горячих” данных на Flash-картах и SSD дисках.

И вот уже вчера NetApp анонсировал продукт Flash Accel, обеспечивающий кэширование данных на стороне сервера. Как несложно догадаться, Flash Accel это по факту PCI-e карта и соответствующий софт от Fusion-io. Кэширование на стороне сервера возможно только на чтение (что вполне логично). Доступность Flash Accel заявлена на декабрь 2012. Flash Accel является программной разработкой NetApp, позволяющей использовать в качестве кэша локальные устройства сервера (SSD или Flash PCI-e карты). В первой версии будут поддерживаться Windows Server 2003 и 2008, а также vSphere 5. Примечательно, что даже в первой версии обещают работу HA, vMotion и DRS. Формально есть привязка к системе хранения (пока только FAS, V- и N-серия), но не к кэширующему устройству (будет список официально поддерживаемых). На текущий момент NetApp будет перепродавать карты от Fusion-io. 

Но этим же пресс-релизом NetApp тонко намекает Fusion-io, что расслабляться не стоит – желающие производители аналогичных решений могут подать заявку на получение значка “NetApp Validated”. И в этом списке уже, помимо Fusion-io, отметились LSI, Micron, SanDisk, STEC и Virident.

Но пока только с Fusion-io заключен контракт, согласно которому будут перепродаваться Fusion-io ioMemory, ioTurbine и Direct Cache. 

К слову сказать, у нас уже доступен к заказу LSI Nytro XD. Это комплект из PCI-e карты с 400GB флэш-памятью (e-MLC) и специального софта, который и позволяет осуществлять кэширование данных (независимо от расположения – будь то СХД или DAS). Среди серьезных преимуществ – крайне низкие требования драйвера устройства к оперативной памяти (рассматривая в качестве альтернативы решение Fusion-io об этой особенности важно помнить). Пока еще, правда, не поддерживается работа в среде VMware, но и это тоже не за горами – работа активно ведется.

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

P.S. Спасибо Роману за уточнение!

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

EMC VNX–что день грядущий нам готовит

Я уже писал про новости в high-end системах EMC, но гораздо более интересным для меня является анонс новых возможностей систем среднего уровня – VNX. И дело не в том, что такие системы гораздо больше распространены и в разы больше продаются. Речь о тех технологических возможностях, которые в них появятся. Да, несмотря на анонс, их пока нет и ждать их стоит во втором полугодии 2012. Так что же было объявлено?

Если кто-то вникал, как именно работают пулы (pools) в VNX, то наверняка обратил внимание на “магические” числа. Это, в частности, число “5” для RAID5 и “8” для RAID-6. Дело в том, что при создании пулов, именно такой размер RAID-группы всегда старается выбрать система. Конечно, если дисков недостаточно, то пул все равно будет создан, но  в одной из RAID-групп дисков будет недостаточно (или слишком много), а это скажется на равномерность нагрузки. Подробности можно прочитать вот в этой замечательной заметке, либо в ее переводе здесь. Таким образом, для RAID5 эффективность использования дискового пространства составляет 80%, а для RAID6 – 75%. В новой версии было принято увеличить размер дисковых групп – для RAID5 он может составлять 8+1 (эффективность 88.9%), а для RAID6 даже 14+2 (эффективность 87.5%). С одной стороны, это позволит несколько повысить эффективность использования дисков. С другой стороны, планирование системы становится еще более творческим занятием. Предположим, что нам нужен пул из NL SAS дисков. Логично использовать RAID6 и, как следствие, мы вынуждены использовать 17 дисков (одна группа 14+2 и пригодится хотя бы 1 hot-spare диск). Если же нужно увеличить объем системы, то дисков нужно уже 33 (а лучше бы 34). И здесь мы сталкиваемся с тем, что уместить 34 диска в дисковые полки по 15 дисков довольно проблематично, а значит потребуется 3я полка, которую мы также не сможем заполнить. В любом случае, выбор “большой” RAID группы накладывает определенные ограничения на апгрейд системы (в плане стоимости такого апгрейда). Конечно, есть полки высокой емкости, но и там диски “ровно” не укладываются.

Такими изменениями производитель нам как бы сам намекает, что оставшееся место самое время заполнить дисками SSD, чтобы использовать все прелести FAST Cache или FAST VP. И здесь мы сталкиваемся с новым изменением – в пул можно будет включать RAID-группы разного типа, т.е. в пул с  RAID6 из NL SAS дисков можно спокойно подключить RAID5 из SSD дисков (сейчас пользователь вынужден использовать только один тип RAID внутри пула, независимо от типа дисков).

Изменения коснулись и технологии FAST VP – в новом релизе данные будут сначала попадать на SSD, а уже потом перемещаться на более медленные диски. Такой подход имеет свои плюсы и минусы, но зато позволяет получить немедленный видимый эффект от использования SSD. И становится заметно проще демонстрировать преимущества от FAST VP заказчику – достаточно немного нагрузить систему. Фактически, технология FAST VP становится более похожей на FAST Cache (хотя отличия, несомненно, остаются).

В упомянутой выше статье было много сказано про недостатки пулов в VNX, связанные с расширением дискового пространства. Похоже, что и эту проблему в EMC не обошли своим вниманнием – помимо уже описанных новшеств, нас ждет еще и автоматическая ребалансировка внутри пула. При добавлении дисковых групп в общий пул, произойдет перераспределение данных по пулу. С одной стороны, это очень хорошо – добавили диски и увеличили производительность, а не только объем. С другой стороны, перераспределение занимает время и нагружает контроллеры. А как обычно происходит? Диски добавляем, когда уже и места нет, и производительность ниже необходимой. Планируйте своевременно апгрейды! (Это правило, кстати, относится не только к EMC, но и ко всем другим системам).

Ну и самое радикальное новшество – на пулах появятся новые снапшоты! Это действительно принципиальное изменение (и я понятия не имею, почему еще все производители, которые так рекламируют thin provisioning, не начали так делать). Появляются снапшоты, работающие по технологии redirect on write. Т.е. больше нам не нужно резервировать отдельное место под мгновенные снимки и системе не нужно копировать “старые” данные в этот резервный пул. В случае redirect on write новый блок данных (после создания снимка) просто записывается в новое место, а LUN “собирается” на основе указателей. Т.е. примерно так, как это реализовано в NetApp или в IBM XIV. А это дает существенные преимущества – до 256 снимков на том, нет потери производительности из-за использования снимков, возможность делать снапшоты снапшотов, доступность снапшотов на запись. Да, да -  извечные противники в плане технологий стали еще ближе друг к другу! Если NetApp выступает своего рода первопроходцем, то EMC идет по намеченному курсу, делая нужные изменения (не факт что в нужный момент, но зато не приходится растрачиваться на рекламу новых фишек – публика уже “подогрета” рассказами NetApp).

Но гонка с NetApp на снапшотах не закончена и у VNX появляется еще один дополнительный программный продукт – AppSync. Он предназначен для защиты приложений (на старте - Exchange и VMware, потом планируются и другие). Пользователь задает уровень доступности  (SLA) для конкретного приложения и может самостоятельно восстанавливать данные в случае сбоя.

Большинство из объявленных новшеств доступны только в системах VNX, а владельцам VNXe придется подождать – из-за особенностей реализации блочных протоколов в VNXe.

Посмотрим, что готовят конкуренты в ответ!

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

Кэшировать всегда, кэшировать везде!

Уже во время анонса системы IBM XIV Gen3 было объявлено о скорой поддержке SSD внутри модулей. “Скоро” уже настало и вот теперь можно не только заказать новый XIV Gen3 с установленными SSD дисками, но и установить SSD в уже инсталлированную систему XIV Gen3 (процедура не требует остановки – только обновления микрокода). В каждый узел XIV можно установить по одному диску SSD 400GB (суммарно это даст от 2.4ТБ до 6ТБ на систему, размер немного занизили – изначально обещали диски по 500GB). Почему так мало? Потому что это пространство может быть использовано только как кэш чтения, а не для хранения самих данных, а 6ТБ кэш памяти это не так уж и мало. Кэшируются только операции чтения – для кэширования операций записи используется оперативная память узлов XIV (суммарный объем которой достигает 360GB). Чтобы обеспечить для SSD модулей долгое и безоблачное существование под высокой нагрузкой используется специальный механизм оптимизации: изначально в оперативной памяти узла формируются блоки размером по 512КБ и уже именно эти блоки последовательно и циклично записываются на SSD. Таким образом, операции записи на SSD всегда идут последовательно, а ячейки используются равномерно. Обещают неплохой прирост в производительности:

Решение, предложенное в XIV безусловно не является технологическим прорывом – всем уже вспомнился и EMC FastCache, и NetApp FlashCache. Каждое из этих решений имеет и свои плюсы, и свои минусы. От EMC FastCache заказчик получает не только кэширование при чтении, но и кэширование операций записи. Платой за это является существенное сокращение кэша в оперативной памяти SP и сравнительно небольшой объем – для “топового” VNX7500 он составляет 2.1ТБ (при использовании 100GB дисков). В случае с NetApp FlashCache кэшируется только чтение, но зато кэш является дедублицированным и может достигать 16ТБ. Кроме того, FlashCache является PCI-e платой, поэтому “дорога” от кэша до процессора (а значит и до хоста) гораздо короче, чем при использовании SSD дисков. А это, в свою очередь, потенциально позволяет получить довольно низкую латентность. С другой стороны, если мы захотим получить 16ТБ кэша, то на придется задействовать 16 слотов расширения из 24х возможных, что существенно ограничит возможности расширения (как по дискам, так и по используемым протоколам подключения хостов).

EMC тоже отметились и с шумом выкатили свое решение для кэширования VFCache (Very Fast Cache). Что это и как “привязано” к дисковой системе? По факту VFCache это обычная PCI-e плата (как и аналоги у FusionIO, LSI и пр.) 300GB (производства Micron), которая используется не как супер-быстрый диск в операционной системе, но как кэш для операций чтения.

В принципе (насколько я понял из прочитанного/найденного), никто не мешает использовать VFCache с любой дисковой системой (и без нее в т.ч.). Можно даже часть VFCache “отрезать” и использовать как жесткий диск. Среди явных минусов – пока поддерживается только одна карта в сервере, так что использование части VFCache как DAS, не может обеспечить отказоустойчивость. Кроме того, поддержка в VMware серьезно ограничивает такой функционал как vMotion (а точнее он просто не поддерживается). В данном случае решение EMC тоже уникальным не назовешь. Один из пионеров в выпуске PCI-e SSD карт – FusionIO уже некоторое время предлагает аналогичный продукт ioCache (который, кстати, vMotion как раз поддерживает). Есть надежда, что в последующих релизах VFCache будет существенным образом доработан и появится не только более тесная интеграция с VMware, но и с собственными продуктами (FAST Cache/ FAST VP).

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

Одной строкой

Обновилась камасутра библия для владельцев систем NetApp и IBM N-series – документ с говорящим за себя названием “NetApp Storage Best Practices for VMware vSphere” (TR-3749). Основные изменения коснулись возможностей vSphere 5. Скачать можно совершенно свободно, даже регистрация не требуется. Всем, кто использует VMware, документ обязательно нужно прочитать хотя бы один раз!

Для серверов IBM x3650M3 и x3550M3 анонсирован новый RAID контроллер – ServeRAID M5016. Ключевая особенность – наличие 1GB кэш памяти с защитой, но не батарейкой, а флэш-памятью с конденсаторным модулем (ну наконец-то уже!). Для активации RAID6/60 более не требуется дополнительный ключ – все работает “из коробки”.

Предвосхищая – модуль с конденсаторами на фото не показан, он “болтается” отдельно,  пристегнутый длинным кабелем к контроллеру (примерно как с использованием Remote Mount Cable на M5015).

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

Неожиданно: LSI to Sell External Storage Systems Business

Анонс, который я, признаться, не ожидал увидеть в этом году: http://www.lsi.com/news/corporate_news/2011/2011_03_09.html

LSI договорился с NetApp о продаже части бизнеса, связанного с внешними дисковыми системами, за 480млн$. Т.е. все что раньше производилось под маркой Engenio и продавалось чуть ли не десятком различных вендоров (IBM, Oracle (Sun), Dell и многими другими) полностью переходит под контроль NetApp. IBM активно сотрудничает с NetApp и здесь вероятно трагедии не будет, но интересно как  остальные вендоры поступят.

Внутренние RAID контроллеры (как LSI, так и 3Ware) остаются у LSI и с ними все без изменений (надеюсь).

Неужели NetApp’у стало мало своих Unified систем хранения и потребовался “настоящий” FC?

Что характерно, шума со сделкой (как например у HP с 3Par) фактически не было – все довольно тихо и мирно.

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

Новые файлеры IBM N series

Не прошло и квартала с момента выхода в свет систем NetApp FAS3200, как IBM представил свои новые файлеры N6200. Вчера анонсировано две новинки N6210 (аналог FAS3210) и N6240 (FAS3240). В моих словах нет никакой иронии – задержка в пару месяцев с момента выхода “оригинальной” версии является совсем незначительной и вполне объяснимой (необходимые дополнительные тестирования, сертификации и т.п.).

Итак, что же мы получили? Никаких концептуальных изменений с системами от NetApp конечно нет.

N6210 может быть заказана в двух вариантах – одноконтроллерная и двухконтроллерная. Благодаря новой компоновке, контроллерный модуль займет в стойке только 3U, что не может не радовать – для небольших инсталляций прошлые системы были чересчур громоздкими. Каждый контроллер содержит 2.3ГГц процессор с двумя ядрами, 4ГБ памяти, 2 порта FC 4Gbit (для хостов или полок расширения), 2 порта SAS 6Gbit (для подключения полок расширения), 2 порта Ethernet 1Gbit (для подключения хостов), также имеется два свободных PCIe слота для установки карт расширения. Максимально система поддерживает до 240 дисков.

N6210/N6240 с двумя контроллерами в шасси 3U

N6240 поставляется уже в трех вариантах: компактный двухконтроллерный вариант в 3U корпусме, один контроллер + модуль ввода-вывода (с 4мя PCIe слотами) в 3U корпусе, а также двухконтроллерный вариант в 6U. Последний обеспечивает максимальные для данной модели возможности расширения – 12 PCIe слотов. Каждый контроллер оснащен уже четырехядерным процессором 2.3ГГц и 8ГБ памяти, а по портам отличий от N6210 нет – 2xFC 4gbit, 2xSAS 6Gbit, 2xEthernet 1Gbit. Максимально поддерживается уже 600 дисков в системе.

N6240 с одним контроллером и модулем ввода-вывода в шасси 3U

Признаться, я довольно долго в момента анонса FAS3200 думал, почему же не смогли сделать “набортные” 8Гбит порты FC и лишь потом понял что скорее всего причина в 4Гбит бэкенде для подключения полок расширения. А если уж очень хочется подключить хосты к 8Гбит, то можно и дополнительные контроллеры поставить.

В качестве полок можно использовать любые из имеющихся на сегодняшний день: EXN1000 (FC c дисками SATA), EXN2000 (FC c дисками FC), EXN3000 (SAS с дисками SAS/SATA) и EXN4000 (FC c дисками FC). Все они рассчитаны на 3.5" диски, а полки для 2.5” дисков, которые уже доступны по каналу NetApp в IBM пока еще нет.

Существенные изменения произошли в лицензировании:

Если ранее необходимо было покупать лицензии на любой протокол, кроме iSCSI (который был бесплатным), то сейчас можно выбрать один любой “initial” протокол доступа (CIFS/NFS/iSCSI/FC), который будет включен без оплаты, а остальные уже докупать. Такой вариант будет очень удобным если требуется например создать файловое хранилище для сети с Windows машинами, либо приобретается система для VMware и (небезосновательно) предполагается ограничиться использованием NFS.

Кроме того, в базовую поставку всегда входит набор лицензий “Data ONTAP Essentials”, включающий целый набор опций: CFO (failover для кластерных конфигураций), SyncMirror, Deduplication, FlexCache, MultiStore, NearStore, HTTP, DSM for MPIO (25 лицензий), все версии OSSV, по одной лицензии на Operations Manager, Protection Manager, Provisioning Manager и Protection Manager DR. Все это уже есть и уже не нужно помнить про добавление “бесплатных” лицензий во время составления конфигурации.

Дальнейшие анонсы, я думаю, впереди – пока ничего не сказано ни про старшие FAS3270 и FS6200, ни про новые полки расширения.

Вместе с новыми системами объявлено и о скорой кончине некоторых имеющихся – в частности в конце апреля уйдут в небытие N3600 (FAS2050) и N6040 (FAS3140).

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

Autovirt – новые возможности

К уже и без того впечатляющему функционалу AutoVirt прибавление!

• 
  
  Стала поддерживаться интеграция с NetApp SnapMirror: 
  можно как импортировать существующие настройки, так и создавать новые “зеркальные” пары. Кроме того, можно обеспечить автоматизированный или ручной failover через глобальное пространство имен AutoVirt.
• 
  
  Управление NetApp SnapLock:
  - через функционал архивирования можно перемещать (на основе фильтров) файлы из любой файловой  “шары” на том с включенным SnapLock.
  - можно также импортировать настройки SnapLock и управлять опциями через GUI AutoVirt

Обе возможности должны быть интересны владельцам NetApp. Причем политики миграции данных на SnapLock том могут заметно упростить жизнь при планировании инфраструктуры. Далеко не все данные необходимо хранить неизменными, поэтому нужно каким-либо образом отправить на SnapLock том только определенные файлы и здесь серьезным подспорьем будет AutoVirt.

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

Маркетинг против технологий

Не могу не скроспостить сообщение из блога про NetApp уважаемого romx. Речь про анонсы различных технологий в системах хранения компанией NetApp и реакцию EMC на эти анонсы. Собственно картинка:

В третьей колонке – время анонса аналогичных технологий в системах EMC.

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

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

Еще про мотивацию сотрудников

Оказывается в NetApp работают веселые ребята: 

http://blogs.netapp.com/dave/2009/11/always-bet-against-your-employees.html

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

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

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

Новости – понятные и не очень.

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

Oracle не успев насладиться тесной дружбой с HP (первая версия Exadata)выпустил вторую версию Exadata, назвав ее “First Database Machine for OLTP”. Объявление громкое, про него и писали, и пытались заинтриговать. А в итоге получилась пачка обычных x86 серверов на (уже успевших набить оскомину) процессорах Intel Xeon серии 5500, объединенных в Oracle RAC. По сути, единственным новшеством стало использование в “Storage” узлах флэш-памяти для ускорения ввода-вывода. Заявляется производительность в 1млн IOPs (для full rack конфигурации с 14 Storage Servers), но результаты TPC-C обещают озвучить только к середине октября.  Апологеты спарков конечно расстроены тем, что не попали на праздник, но удивительного в этом, на мой взгляд,  нет – предложить на текущий момент нечего. Эллисон в своем выступлении в основном бился против серверов IBM, которые давно уже занимают первую строчку в тестах TPC-C. Правда, при сравнении цен почему-то забыл упомянуть о том, что на один шкаф с экзадатой нужно еще заплатить больше 600тыс$ за Oracle RAC, тогда как в случае с IBM p595 этого не требуется. RAC это конечно очень быстро, масштабируемо, удобно и все такое, но если у уже заказчика есть работающая система на одном сервере, то будет довольно сложно убедить его променять эту одну машину на 22 маленьких, за которыми нужно следить (и, не приведи господи, у них там что-то в кластере “заклинит”). На мой взгляд, сказать что Oracle выпустил что-то радикально новое нельзя – тот же IBM вместе с FusionIO уже год назад демонстрировали фантастическую производительность (правда в лабораторных условиях). Интересно другое – как отразится объявление на HP? Или это еще один шаг Элиссона к тому, чтобы больше заинтересовать HP в покупке “железной” части SUN, про возможность которой продолжают возникать и циркулировать слухи? Время покажет.

Второе, совсем тихое событие – RAIDCore (от которого, немного попользовавшись, все почему-то старались избавиться, а последний владелец Ciprico так вообще обанкротился) может быть наконец обрел покой во владениях DotHill. Объявлен продукт под названием Virtual RAID Adapter (VRA) – программное решение для создания и управления RAID без использования аппаратных контроллеров. Продукт нацелен скорее на производителей плат – чтобы у них не было головной боли с тестированием драйверов под интегрированные контроллеры (ICH и т.д.). Насколько это будет востребовано для меня совершенно не ясно: с одной стороны, функционал RAIDCore несколько выше, чем у интегрированных контроллеров, с другой стороны, зачем метаться, если для бюджетного решения и то, что есть сейчас, тоже сгодиться, а на серьезных системах используются нормальные аппаратные контроллеры. Вот если бы поддерживались обычные HBA адаптеры, то интерес может быть и был бы – например для систем видеонаблюдения, где сейчас используются обычные HBA с десятками дисков, но без всякой защиты, а наличие такого программного RAID заметно повысит отказоустойчивость без серьезного удара по цене.

Ну и третье событие, хотя и не прозвучало очень громко, но зато вполне логично и понятно – NetApp расширил линейку систем хранения начального уровня, выпустив FAS2040.

Как и остальные системы 2000й серии, FAS2040 рассчитана на использование SAS и SATA дисков (до 12ти внутри контроллерного модуля), но расширяться может не только при помощи “классических” полок с FC или SATA дисками, но и уже чуть ранее объявленными SAS полками, так как на каждом контроллере есть по одному SAS порту. С одной стороны, система “помещена” между FAS2020 и FAS2050, но практически по всем характеристикам она превосходит и ту, и другую – расширяется до 136 дисков, имеет 8ГБ памяти, 8 портов ethernet и 4 порта FC (на два контроллера). Нет только возможности устанавливать в контроллер платы расширения, которая есть у FAS2050. Помимо объявления новой системы, сделано очень интересное предложение для покупателей FAS2020 – теперь они получат NFS и CIFS совершенно бесплатно (как и iSCSI). Видимо все больше ощущается конкуренция на рынках SMB со стороны Windows Storage Server, поэтому и было принято решение отдать CIFS в младшей системе даром, но наличие NFS и iSCSI (а также возможность получить двухконтроллерную систему) делает очень привлекательным использование FAS2020 не только для хранения файлов, но и в качестве хранилища для виртуальных машин VMware.

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

EMC очень хочет отнять Data Domain у NetApp

Как оказалось, EMC очень хотят, чтобы DataDomain достался все-таки им (хотя, наверное, еще больше не хотят чтобы его получил NetApp), поэтому предложили уже 30$ за акцию, что соответствует примерно 1.8млрд$ в кэшэ. Предложение явно выгоднее, чем то, которое NetApp сделал немногим ранее (у NetApp нет столько кэша не то, чтобы переплюнуть EMC, но даже и чтобы сравнять ставки). Пока, впрочем, никто ничего внятного не сказал, но вполне возможно, что EMC получит в дополненение к своему Amavar еще и аппаратное решение по дедупликации. Ни NetApp, ни DataDomain комментарии пока никакие не дали.

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

NetApp приобретает Data Domain

"Везунчик" кризиса Data Domain (все время показывали уверенный рост и были этим несомненно горды) куплен за 1.5млрд$ компанией NetApp. Обе компании предлагали клиентам средства дедупликации, но для DataDomain это был основной хлеб и именно на это нацелены их решения. В результате сделки, NetApp сможет предложить более полные решения для оптимизации резервного копирования, а также еще немного потеснить производителей ленточных приводов, так как благодаря дедупликации, объем записываемых на ленту данных можно в разы сократить. У NetApp уже был собственный VTL, но популярность его явно оставляла желать лучшего, так что теперь его место скорее всего займут продукты от DataDomain.

Российские заказчики через какое-то время скорее всего смогут получить системы DataDomain через канал NetApp вместе с соответствующим сервисом, тогда как на данный момент, насколько мне известно, "белых" поставок нет, а сервис остается на совести поставщика.

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