Pull to refresh

Comments 98

UFO just landed and posted this here
Чуток поработал с vnx5100, хотя и являюсь программером.

Из недостатков:
— высокая сложность настройки при отсутствии актуальной документации (LUNы использовались на серверах с CentOS 6);
— диагностика для замены диска (штатная, в общем, операция) не может производиться из тяжелого Java-applet интерфейса, но только из standalone-программы (windows-only);
— невозможность штатной замены диска (по документации) по истечении, если правильно помню, месяца с момента сбоя: wizard замены сообщает об отсутствии дисков для замены; техподдержка предложила просто вытащить диск и попробовать заменить, игнорируя wizard в интерфейсе;
— штатный интерфейс работает не со всеми версиями java (например, не работал с 1.7), т. к. считает, что это нестандартная java-машина; рекомендую при случае заглянуть в код страницы-контейнера для java-applet'а;
— невозможность удаленно выключить СХД (это вообще за гранью добра и зла), только щелкнув переключателями на SPS (standby power supply);
— абсолютно прекрасная политика предоставления софта и мануалов только через закрытый портал (видимо, чтобы не позориться);
— невозможность сменить или восстановить пароль в случае его утраты (несмотря на тот же business-email, указанный при регистрации).

Извините, накипело.

Если кому актуально — краткая инструкция, как дружить VNX с CentOS под спойлером.
manual
  1. создать storage group
  2. создать raid group
  3. создать lun
  4. поставить на сервер multipath
  5. mpathconf --enable
  6. добавить blacklist в /etc/multipath.conf
  7. сделать скан:
    for s in $(find /sys/class/scsi_host -name scan) ; do
      echo "- - -" > $s
    done
  8. поставить Unisphere (yum install ./ServerUtil-Linux-64-x86-en_US-1.2.0.1.0554-1.x86_64.rpm)
  9. /opt/Unisphere/bin/serverutilcli, сделать скан (1) — должно показать пути до EMC
  10. добавить сервер в соответствующую storage group
  11. перезагрузить сервер
  12. multipath -v3
  13. проверить в multipath -ll

Ой, вижу, вижу что-то не то вы с СХД делали. Отвечу по порядку.

1. Про сложность настройки. Из моей практики — это самый простой массив по настройке блочной части. Но, конечно, если вы не работали с СХД до этого, плюс у вас были сложности с документацией, было сложно.

2. Про диагностику. USM (как я подозреваю та самая standalone-программа) для диагностики диска не нужен! Достаточно сообщения из web-интерфейса. Логи там же.

3. Замена. Штатная замена по документации – это просто вытащить неисправный и вставить новый (так говорят на ВСЕХ инженерных курсах, то же написано в документации инженерной). Скрипты, на которые вы смотрели, сделаны для помощи в локализации нахождения сбойного диска для клиента. Они никогда не используются саппортом.

4. Про не все версии Java. Да, есть такое. Но при наличии актуальной прошивки с последними версиями джавы всегда работает. Только причем тут массив? Претензии к Java не стоит перекидывать на железку.

5. Про невозможность выключить массив удалённо. Во-первых, эта функция для защиты от идиотов всегда отключается. Потому что производителю сложно представить ситуацию, когда СХД за 30 тысяч долларов нужно выключить удалённо. Во-вторых, в новом WEB-GUI всё же есть кнопка.

6. Про портал с документацией. Да, он закрытый. Но я на rutracker дольше регистрировался. Закрытый портал — нормальная практика для вендоров.

7. Про пароль. Надо подождать, письмо у меня шло около 14 минут. Дальше — 30 секунд.

ПО инструкции — шаги 8-9 не обязательны, я бы скачал с портала HostAgent – менее напряжный и более автоматизированный вариант. И вместо шага 2 лучше создавать дисковый пул, а не RAID Group.

Финал – где здесь сложности связанные с массивом? Я вижу сложности связанные с ОС, но это же Linux. Он дружелюбный, но сам выбирает друзей.
Судя по ответам, хочешь геморрой — купи вендорский СХД. Особенно пункт 5 порадовал.
Геморрой вы в любом случае получите. С одними вендорами больше, с другими меньше.

Для некоторых задач у вас уже не будет сколько-либо значительного выбора СХД. Я лишь описал те, на которые наткнулся в случае младшей линейки VNX.
1. Про сложность настройки. Из моей практики — это самый простой массив по настройке блочной части. Но, конечно, если вы не работали с СХД до этого, плюс у вас были сложности с документацией, было сложно.
Да, я не имел опыта работы с СХД (кроме пользовательского) до этого, т. к. программист, а не администратор СХД. То, что было в документации по настройке от EMC — не соответствовало действительности либо устарело.

Про диагностику. USM (как я подозреваю та самая standalone-программа) для диагностики диска не нужен! Достаточно сообщения из web-интерфейса. Логи там же.
Для замены диска (про который в java-апплете информации было минимум: только то, что он сбойнул) ТП потребовала собрать логи и отправить. Причем было прямо сказано, что это можно сделать только с помощью отдельной программы (точного названия не помню, но, скорее всего, вы правы, и это USM). По результатам работы программы был получен архив мегабайт на несколько, после получения которого нам и выслали диск DHL'ем.

Замена. Штатная замена по документации – это просто вытащить неисправный и вставить новый (так говорят на ВСЕХ инженерных курсах, то же написано в документации инженерной). Скрипты, на которые вы смотрели, сделаны для помощи в локализации нахождения сбойного диска для клиента. Они никогда не используются саппортом.
Сбойный диск явно отображался в интерфейсе плюс на нем горел оранжевый диод. Но, ТП опять же сказала, как заменять диск: использовать wizard (не пол раза не какой-то сторонний скрипт, а именно wizard в java интерфейсе). Только когда это не удалось специалист ТП сказал, что тогда надо просто вытащить диск. После извлечения диска таки автоматически подцепился другой из hot spare и пошел rebuild (тоже, кстати неочевидное поведение). Вставленный новый диск ушел в hot spare.

Я не стану выдергивать диск из массива просто так, потому что мне это кажется правильным. Естественно, что эти действия сопровождались примерно трехдневной перепиской с ТП. Была прямая техподдержка или через какого-то интегратора — не помню. Сначала нас пинали между двумя техподдержками, т. к. не могли разобраться, кто из них обязан оказывать поддержку.

Кстати, в случае Promise VTrak была аналогичная фигня: после установки нового диска ребилд необходимо было вообще запускать руками. И только из консоли, через RS232.

Про не все версии Java. Да, есть такое. Но при наличии актуальной прошивки с последними версиями джавы всегда работает. Только причем тут массив? Претензии к Java не стоит перекидывать на железку.
Почему железка пытается определить, что если версия java-плагина выше, чем 1.7uXX, то необходимо послать пользователя, а не отдать ему java-апплет? Это не ошибка поведения браузера, не ошибка поведения java-плагина или самой JVM. Нет никакой актуальной причины требовать от пользователя более старой версии явы, которую ещё хрен найдешь, т. к. у oracle лежит более новый апдейт.

Про невозможность выключить массив удалённо. Во-первых, эта функция для защиты от идиотов всегда отключается. Потому что производителю сложно представить ситуацию, когда СХД за 30 тысяч долларов нужно выключить удалённо. Во-вторых, в новом WEB-GUI всё же есть кнопка.
Угу, сложно предположить, что в удаленном ЦОДе могут быть, например, работы, требующие остановки железа. И, что люди, проводящие эти работы, могут не иметь права лезть в опечатанную стойку. Странно, что нет защиты от идиота-администратора, который может грохнуть LUN, но есть от идиота-администратора, который решит выключить железку. Не говоря уже про OOB-management, как делается на приличном железе. К тому же, почему тогда эта функция появилась, если её нельзя было вводить для защиты от дурака?

Про портал с документацией. Да, он закрытый. Но я на rutracker дольше регистрировался. Закрытый портал — нормальная практика для вендоров.
То, что часть вендоров прячет документацию на железки — не делает это нормально практикой. Просто сложившаяся убогая модель.

Про пароль. Надо подождать, письмо у меня шло около 14 минут. Дальше — 30 секунд.
Письмо с подтверждением пришло в течении 30 минут. Потом верификация (с участием человека), как заявила ТП прошла в течении суток. Только вот инициировать восстановление пароля не смогли ни в ТП, ни через портал EMC. ТП рекомендовала скачать необходимую документацию заведя второй (sic!) аккаунт на другой бизнес-email.

ПО инструкции — шаги 8-9 не обязательны, я бы скачал с портала HostAgent – менее напряжный и более автоматизированный вариант. И вместо шага 2 лучше создавать дисковый пул, а не RAID Group.
На него случаем, ещё одна лицензия не нужна? Почему в описании настройки на RHEL нет этого варианта? Есть ли он под RHEL6 x86_64?

Насчет необязательны — без них сервер не виден в списке серверов, к которым можно подцепить LUN. Да, после того, как сделан scsi scan и есть все пути в наличии. Сервер добавить руками невозможно. Почему — я не знаю, я не индус, который писал их ПО.

Дисковый пул не создавался при наличии всего одной корзины с дисками. С чем это связано — не помню.

Финал – где здесь сложности связанные с массивом? Я вижу сложности связанные с ОС, но это же Linux. Он дружелюбный, но сам выбирает друзей.
То, что вендор не осилил нормальную техподдержку RHEL (а CentOS — бинарно-совместимый) — это проблемы вендора. Особенно, когда эта поддержка заявлена.

То, что для диагностики для отправки нового диска необходима винда — это косяк вендора. Особенно, при наличии тяжелого интерфейса.

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

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

Я всего лишь описал некоторые проблемы с которыми столкнулся и которые запомнились наиболее ярко.
После извлечения диска таки автоматически подцепился другой из hot spare и пошел rebuild (тоже, кстати неочевидное поведение).

Имхо, только лишь за это разработчиков стоит стерилизовать. Я такое один раз поймал на хайлоаде… два дня сервис был в коме.
Сбойный диск явно отображался в интерфейсе плюс на нем горел оранжевый диод. Но, ТП опять же сказала, как заменять диск: использовать wizard (не пол раза не какой-то сторонний скрипт, а именно wizard в java интерфейсе). Только когда это не удалось специалист ТП сказал, что тогда надо просто вытащить диск. После извлечения диска таки автоматически подцепился другой из hot spare и пошел rebuild (тоже, кстати неочевидное поведение). Вставленный новый диск ушел в hot spare.


Если VNX видит, что на диск много ошибок, он заранее начинает копирование данных с него на Hot spare. Если что-то не успеет скопировать и диск выйдет из строя, то восстановит из parity. В итоге hot spare полностью замещает неисправный диск.

После того как неисправный заменен, данные автоматически начинают копироваться в фоне с Hot spare на новый диск.

По окончании этого процесса ребилда, hot spare остается hot spare, а новый диск занимает место старого.

Мне кажется, что-то здесь напутано, т.к. вставленный новый диск не мог уйти в hot spare. (если он только не был hot spare до замены :) )
Кстати, в новых VNX система sparing'а работает по-другому, более гибко.
Если VNX видит, что на диск много ошибок, он заранее начинает копирование данных с него на Hot spare.
Это нигде не отображалось и диск из hot spare так и висел, как неиспользуемый "hot" spare, пока не был извлечен сбойный диск. В этот момент диск из hot spare перешел в соответствующую raid group и массив начал rebuild.

Новый диск был вставлен и отправлен в hot spare (может быть руками, этого уже точно не помню, но вакансии в hot spare уже не было).

Оригинальным hot spare был 25й диск в корзине, сбойнул диск в середине. Интерфейс отображал всё достаточно однозначно.

Может быть у них описываемое вами поведение не отображается? Это был бы номер, но что-то не верится.
Про питание. Как вам корректно заметили ниже — СХД не требует особого внимания при проведении работ по электропитанию. В исключительных случаях подразумевается плановая операция, которая включает присутствие специалиста локально на площадке, так что в общем-то проблема надумана. Скажите, у вас бывали потери данных, или длительная их недоступность из-за отсутствия такого функционала в GUI? У меня и заказчиков Крок ни разу на моей памяти. А вот обратная ситуация, когда при пропадении питания в ЦОД админы попытались выключить СХД(как я говорил, в принципе это возможно было всегда, только не из GUI) ошиблись и получили простой в 12 часов, а я получил «незабываемую» ночь с саппортом ЕМС в попытках восстановить их данные до 6 утра. Повторения, честно, не хочется. Ну и небольшое пояснение: кнопка в GUI появилась потому в новом железе батарейку спрятали в корпус и волшебного тумблера больше нет.

По инструкции — лицензия не нужна, называется Unisphere Host Agent (Linux x86) 1.3.1.1.0033, скачать можно на портале. Подключение к хостам LUNов во всех вариациях описано в документе Host Connectivity Guide for Linux, там же на портале.

Существуют минимум 4 варианта регистрации инициаторов на СХД: в ручную через navicli, в ручную через GUI, полуавтоматически с помощью ServerUtility — вы его использовали — и полностью автоматически для всех подключенных массивов VNX с помощью агента. Я по возможности предпочитаю последний вариант.

Про совместимость — у меня лично в работе есть минимум 3 проекта использования VNX c RHEL и парочка с CentOS.
А вот обратная ситуация, когда при пропадении питания в ЦОД админы попытались выключить СХД(как я говорил, в принципе это возможно было всегда, только не из GUI) ошиблись и получили простой в 12 часов, а я получил «незабываемую» ночь с саппортом ЕМС в попытках восстановить их данные до 6 утра.
Как можно ошибиться в переключении двух тумблеров (если действовать в соответствии с тем, что написано в документации, то больше ничего и не надо было)? Такие ошибки — это интересно и узнать про их причины куда более полезно, чем про то, что функционал удаленного выключения не нужен.

По инструкции — лицензия не нужна, называется Unisphere Host Agent (Linux x86) 1.3.1.1.0033, скачать можно на портале. Подключение к хостам LUNов во всех вариациях описано в документе Host Connectivity Guide for Linux, там же на портале.
Спасибо, в следующий раз, если понадобится, попробую этот вариант. Судя по форумам, вариант под x86-64 таки существует.

Существуют минимум 4 варианта регистрации инициаторов на СХД: в ручную через navicli, в ручную через GUI, полуавтоматически с помощью ServerUtility — вы его использовали — и полностью автоматически для всех подключенных массивов VNX с помощью агента. Я по возможности предпочитаю последний вариант.
Не подскажите, в каком разделе Host Connectivity Guide for Linux эти варианты описаны, то я, что-то не нашел. То без магии со сканом serverutilcli сервера почему-то не появлялись в списке доступных в java-апплет интерфейсе unisphere для ручной регистрации. Или ручное добавление запрятано где-то ещё и это не оно?

В Host Connectivity Guide for Linux (P/N 300-003-865 REV A07) наиболее близкое по поводу ручной регистрации нашел в разделе по загрузке с SAN (насколько помню, VNX5100 детектировался, как CLARiiON-семейство):
Prior to the installation on a CLARiiON LUN, the Linux host must have been manually registered on the array and assigned to a Storage Group.
Вообще, ваши проблемы не связаны с диагностикой, они связаны с саппортом, жаль что вы столкнулись с таким непониманием в вашей поддерживающей организации. Все необходимое можно было сделать гораздо проще.
3. Здесь вы немножко не правы. Wizard рекомендуется использовать, потому что он проводит ряд внутренних проверок системы, если все успешно, то разрешает замену.
Иногда техподдержка советует просто вытащить старый диск и вставить новый. Но если вы общаетесь с ТП по этому вопросу, то наверняка вы им присылали логи системы и они провели проверку такой возможности вручную, заместо wizard. Так что, это возможно, но бывают случаи когда так делать ни в коем случае нельзя.
Визард уже в любом случае не работал, т. к. прошел какой-то стандартный интервал (месяц, если правильно помню).
Да, логи посылали (писал выше). Без этого они не высылали новый диск.
UFO just landed and posted this here
— невозможность удаленно выключить СХД (это вообще за гранью добра и зла), только щелкнув переключателями на SPS (standby power supply);

как раз перед новым годом вышел апдейт — появилась заветная кнопка:
New features in 05.32.000.5.209
Power Off Button feature in Unisphere
This release introduces the Power Off Button feature. The Power Off Button supports VNX for Block, VNX for File/Unified, and VNX Gateway systems. The Power Off Button is available through the Unisphere UI.

Зачем оно? Что должно произойти, чтобы появилась необходимость выключить хранилку удаленно? Если какие-то технические действия, то это в любом случае присутствие человека, который сможет нажать кнопку.
иногда бывают случаи когда выключили свет ночью/сгорел УПС/прочее и нужно корректно выключить СХД
UFO just landed and posted this here
Почти полностью посадив аккумуляторы SPS? А зачем, если можно этого не делать?
UFO just landed and posted this here
Для того, чтоб продержать некоторое время СХД в рабочем состоянии при пропадании питания, не?
UFO just landed and posted this here
Не знаю как Кларион с Селеррой (собранные в кучу и названные VNX), а Е-серия (бывший LSI он же DS3500) при выдергивании контроллера (единственного подключенного — иначе неинтересно) успевает его погасить и скинуть кэш на внутреннюю флэшку, перезагрузится и потом уже выключиться. После втыкания и запуска консистентность данных сохраняется.
А ЕМС я не ем. Много места занимают, внешние контрол стейшены которые могут потеряться, Жесткие 4 харда под рут раздел на контроллер (хуавеи также), дедуп весьма условный, снапшоты тормозят систему.
Одно приятно у них. Есть EFD. Но про это чтото ни одного слова.
Про себя. Да. я люблю 3PAR (многоконтроллерные зверюги) и NetApp(ниодного лишнего юнита при жевучести как у танка и скорости как у самолета). Tintri (царствие им небесное ибо нефиг было такие цены заламывать). DotHill. (Хорошая зверюга, маленькая и шустрая). Нелюблю Хуавеи (ректальная схема управления в высшей мере), ЕМС (много места занимают и частенько требуют бубен при настройке), фуджики (канонические киатезы, тем у кого мало денег пойдут, но несмотря на богатый функционал, бубнение и тормоза в ассортименте.)
Хотя признаю что частенько с ФАС серией от НетАппа попадается ядреный секс с саппортом по полгода (минор баги типа горящих лампочек или вислых резервных портов управления, но надо решать, а то нефеншуйно както :) ).
UFO just landed and posted this here
UFO just landed and posted this here
Бывают случаи, когда к люди, работающие в ЦОДе, проводят работы по электрике, но не имеют права лезть в опечатанную стойку, т. к. за это им придется возмещать убытки, продавая свои почки. И если, скажем, сервера можно погасить через OOBM, то с этой СХД это почему-то сделать было невозможно до апдейта.
UFO just landed and posted this here
Обычно электрикам в опечатанную стойку лазить вообще не следует. Если работы затрагивают СХД, то, как правило, на площадке присутствует кто-нибудь ответственный за СХД и он проводит выключение/включение, при этом все администраторы и пользователи уведомляются заранее. Это если хранилка критически важна для бизнес процессов в компании. Если на площадке внезапно выключилось всё питание, то тут система сама аккуратно погасится, сохранив кэш — для этого как раз и нужны батареи — удаленное выключение тут не панацея.
Просто я, честно, не представляю ситуации, когда потребуется отключать СХД удаленно, если только когда она не критически важная и ехать на удаленную площадку не охото :)
Это далеко не всегда так, de facto. Например, СХД, принадлежащими разным подразделениям, может заниматься не общая структура, а сами подразделения. И не имеют права лезть в стойки друг друга.
Я Вам приведу реальный пример из практики. Администраор СХД и СХД находятся на разных континентах. В регионе, где находится СХД бушует ураган Сэнди. Район где находится ЦОД перекрыт, техников туда не пускают из-за потопа, сотрудников ЦОДа эвакуировали. В итоге рвутся линии электропередач и электропитание отключается на 9 часов и садит все источники резервного питания в ЦОДе, включая дизель. Далее за сутки электричество включалось-выключалось несколько раз, что приводило к false-start СХД. Итог: На двух СХД сдохли power-modules, на одной сдох DataMover и полностью пришли в негодность оба SPS, а так же сдох жёсткий диск.
В тот вечер я мечтал о кнопке удалённого выключения… Спасибо, что хоть в инструкциях были консольные команды, как правильно отключить работу datamover, чтобы он перестал обрабатывать данные, это сильно успокоило мои нервы. Да и вообще за 4 года работы с EMC у меня сложилось довольно негативное отношение к продуктам этой компании (Используем SMB и mid-line СХД), в частности из-за техподдержки и спонтанных багов в работе оборудования, исправления которых приходиться ждать по 2-3 квартала.
А удаленное управление UPS и PDU невозможно? Просто если творится фигня в цоде — глушануть физически стойку занулив питание на СХД снаружи. Ведь если выключенный БПшник терзать снаружи всякой быкой — ему плохо будет :(
На тот момент момент их не было. Вроде мелочь, а заранее не предусмотрели. После этого происшествия — появились на всём серверном оборудовании.
Какая-то хвалебная ода получилась. И везде софт софт софт.

1. Так и не понял, увеличение производительности получено благодаря аппаратному масштабированию (новые процы, больше ядер) или оптимизацией софта?
2. А владельцы старых VNX получат плюшки нового софта? Если нет, то почему?
3. А старые VNX можно как-то относительно просто обновить до новых? Хотя бы полки с дисками?
4. Размер блока при дедупликации какой?
1) Железо используется более быстрое и удобное. Плюс использование новых подходов дало возможность выжать из нового железа в разы больше.
2) К сожалению, нет. Софт слишком сильно меняет подходы к работе с железом. Не получается апгрейдить старое без потери данных.
3) Да, такая возможность есть.
4) 8 КВ.
Выглядит это так, словно не из «хорошей» системы сделали «отличную», а совсем наоборот — старая система была так плоха (архитектурно), что понадобился полный редизайн. Ну не суть.

Насколько я понял, при включении блочной дедупликации LUN автоматически становится thin. На старых VNX это приводило к значительной потери производительности. А помимо потери производительности, приводило еще и к фрагментации. Добавление поверх этого дела дедупликации так же должно повысить фрагментацию при высвобождении блоков во время постпроцессинга. В общем что там с производительностью будет — непонятно. И что с файловыми томами? Компрессия?

А актив актив полноценный? Т.е. он только на «просто» RAID или на пулы тоже? В старых VNX переключить пул было проблемой.

На одной и той же системе, производительность thin LUN будет всегда немного ниже, чем classic LUN, из-за внутренних процессов на обслуживание thinLUN. Можно было бы искуственно «замедлить» обычные луны, чтобы производительность сравнялась :) Но ведь это незачем делать.

Дедупликация используется чтобы «увеличить» полезную емкость системы, например, если система используется как долговременное хранилище данных, как библиотека.
Если нужна производительность, то лучше использовать старые добрые классические луны.

Тут важно не путать назначение. Ведь почти все как на домашнем ноутбуке: критически важную ко времени отклика ОС лучше ставить на SSD, а библиотеку фотографий лучше хранить на более емком HDD.
Ага. А почему ваши партнеры (Крок) говорят о дедупликации в применении к VDI? Это не похоже на «библиотеку».

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

Я говорю, что для каждого применения можно и нужно использовать подобающий инструмент. Не стоит забивать гвоздь кувалдой, а сваи молотком.
Вы:
Дедупликация используется чтобы «увеличить» полезную емкость системы, например, если система используется как долговременное хранилище данных, как библиотека.
Если нужна производительность, то лучше использовать старые добрые классические луны.


Крок:
Новая блочная дедупликация. Принцип старый как мир: данные бьются на блоки, одинаковые блоки хранятся один раз. Для дублирующихся блоков используются ссылки на те же блоки как в архивах. Теперь всё это очень сильно «заточено» под виртуальные среды.

Два наиболее типичных типа нагрузки максимально выигрывающих от нового механизма:
Однотипные виртуальные среды, например VDI.
Множественные применения для одного набора данных.


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

Смотрите, нам от лица интегратора показывают «игрушку» и говорят: «Смотрите какая красивая, лучше прошлогодней, в ней есть настоящий Active-Active, есть дедупликация, оптимизирован софт, бегите и хватайте. А что по факту?
1. Текущая лучше прошлогодней, потому, что по сути не имеет к ней никакого отношения в плане архитектуры (со слов рассказчиков выше). Почему не получилось развить существующую архитектуру, сохранив приемственность? Потому, что он неудачная? А на момент анонса говорили совсем иные слова. А что там с новой архитектурой?
2. В новой архитектуре есть дедупликация. При включении дедупликации LUN превращается в thin, а значит при алокации блоков они будут выделяться пачками по 8KB вместо 1GB (что медленно). Сам процесс дедупликации проходит online, а не inline, блоки по 4KB, значит во время „уборки мусора“ остануться „дырочки“ (спасибо, что мусор убирают „пачками“ из блоков, как обещается. а если не получается убрать крупным?), которые будут заполнены в последствии другими маленькими блоками. Это приведет к дополнительному падению производительности. На сколько? Или не приведет? Никто толком не отвечает.
3. Вдруг выясняется, что разрекламированный Active-Active работает только на обычных RAID группах, не на пулах. Что случилось? Почему? Объяснение отсутствует. Типа на пулах оно не нужно, потому что не нужно.
4. Думаю, что если поковырять как следует, можно найти еще несколько интересных умолчаний.

Из личного опыта:
1) полный active-actie — это к 3PAR. У остальных вяленькая эмуляция с перекосами по нагрузке на головы. Причем у трипера не просто active-active, а даже active-active-active-active что мегашоколадно.
2) не компенгаген тут я. считаю WAFL истинно правоверной системой над которой можно насдстраивать дедуп, а все остальное ересь и Ваш ответ по поводу еретичных систем меня еще раз укрепляет с моей вере :)
3) «ВНЕЗАПНО»(с) — я вообще не понимаю какого хрена разделять RAID группы и пулы. С технической точки зрения и то и то набор дисков и встроенными дисками четности (ноль и более) и дисками горячей замены (ноль и более). Из пулов сейчас у меня в любимчиках DDP с его няшной способностью при наличии свободного места перераспределять парити на выживших дисках и посему поддержиивать живвучесть системы пока в системе есть свободное место. Из минусов — жрет много под резервы и по скорости как 60-й (которым кстати по внутренней логике и является).
4) Умолчаний навалом. По хитпараду ЕСМ рекордсмен (снизу) по плотности дисков в стойке в энтерпрайз ветке и энергопотреблению. По менеджменту секс сравнимый с хуавеем, но у хуавея удовлетворение получить проще. Control Station как класс меня бесят и нервируют — внешний модуль управления кластером из 2-4-х нод это так по энтерпрайзовому (причем подключаются последовательно, то есть при выходе ноды ЦС между выжившей и контроллерами, выжившая несчитается). Блэйд модули которые посуществу тупо виндовые серваки с разогнанной с четыре раза стоимостью. Как моя милая говорист — «Жуть в тапочках». Метро у них классное — нет вопросов. Растянутость миррора хоть между полюсами. Тут был бы лидером, но даже DS3500 (и его нетапповские братья Е26хх, Е27хх, Е54хх, Е55хх) по фибре миррорятся с меньшей потерей производительности (и латенси у них тоже ниже).
Для себя я не нашел задач под которые порекоммендовал бы клиенту ставить ЕМС. Медийщикам бывает рекоммендую Исилон, но потом смотрим на цены, смеемся и переходим в конструктивное русло.
1. полный AA (full-mesh) или SAA (symmetric active-active) это не только 3PAR. У IBM были эксперименты с XIV, довольно интересная архитектура у SVC (хотя они скорее AAA, но это тема отдельного разговора) решений. Тот же EMC имеет в арсенале богатый опыт с Symmetrix, хотя это хай-енд, ну и про IBM 8xxx, HP XP и т.п. тоже можно упомянуть. На самом деле, необходимость в SAA при наличии таких вещей как ALUA возникает в среднем сегменте не так чтобы очень часто. Тем более, что на многоконтроллерных системах разумно выбирать такую мощность контроллеров, при которой СХД сохранит приемлимую скорость в случае возникновения failover (да, это двухкратное резервирование в случае двух голов, но диски все равно дороже встанут). 3PAR же как система пришел из мира телекома, где требования к стораджу довольно специфические. Так что идеальным решением для обсуждаемой ниши я бы его не назвал.

2. WAFL по своему хороша, но опять же вовсе не идеальна. Она, безусловно, дает много приятностей с точки зрения «правильных» снапшотов, но вот дедупликация на ней так же приводит к снижению производительности на запись (порядка 8-9%). Если вам нравиться WAFL — можете расширить сознание изучением стораджей с ZFS, например.

3. Потому и разделять, что с дополнительным функционалом производительность блочного доступа у EMC проседает. Это не плюс и не минус (очевидно, что чем больше логики, тем ниже производительность). Плохо то, что не все плюшки доступны для пулов. Хотя ниже человек отписал, что этот функционал будет добавлен. Т.е. железку выпустили с несколько недоделанным софтом (возможно не успевали оттестировать). Не понял, что вы имеете ввиду под DDP. Если Double Disk Parity, он же RAID DP в реализации NetApp, то он совсем не RAID60 по внутренней логике. Если же Dynamic Disk Pools, то непонятно при чем они тут вообще.

4. Да, архитектурно у EMC VNX до сих пор остаются спорные моменты, но приятно, что СХД не бросили а продолжают развивать, пусть и ценой полного редизайна. Надеюсь, когда-то мы увидим действительно unified систему без разделения на модули.
1. К сожалению все эти эксперименты показали что при АА растет латенси минимум на 2-4 мс, а то и больше. Нетаппы при файловере просадки не имеют. Если знаете энтерпрайз который при файловере сажает производительность — скажите. Такую дрянь надо знать заранее.
2. C ZFS у меня пройдены уже все этапы. От щенячьей радости, до отвращения. Кроме как размером — ничем больше не зацепить. Дедуп на WAFL роняет скорость, но не трогает латенси — лучше так чем наоборот.
По поводу систем разметки дисков (не буду их называть файловыми для более общего состояния): мне одно время очень импонировали потомки reiserfs, одним из которых как раз была Tintri с их иерархическими наборами дисков. Очень похоже на ЕМС, но без прослоек внутри. Жаль что умерло. Хорошие скорости и опсы давало.
3. Как вы заметили в СХД чем толще бутерброд протоколов и технологий — тем выше латенси. Вам оно нужно? Мне нет. Даже если их несколько — давайте их плотно саггрегируем и зашьем на нижний уровень. Собственно тем и нравятся мне динамические дисковые пулы. Разницу между Diagonal Parity и кодом Соломона-Рида знаю. Термин DDP нетаппа однозначно определяется как Dynamic Disk Pools и в отношении к Е-серии. RAID-DP (diagonal parity), RAID-4 — это FAS.
4. Меня в ЕМС пугает что кубики все те же, а из них пытаются собрать слово «счастье». Полного редизайна — никто не делал, только косметический вижу. И кстати очень нехочется ждать пока они, собрав все модули в одну коробку, научат дружить коробки друг с другом.
P.S.: У меня просто видимо аллергическая реакция начинается когда мне начинают впаривать что-то что сейчас не работает, но через пару лет и релизов:«Полетит — будьте уверенны». Причем за последние четыре года из изменений замечены только смены названия модели. ЕМС просто съел кредит доверия напару с Хьюлеттом.
1. Не совсем понял замечание. Если у нас AA (пусть и не настоящий, а через ALUA) и контроллеры (процессор) нагружены, скажем, по 80%, то при выходе из строя одного из них второй, после файловера, не сможет дать 160% производительности. Конечно, в большинстве сценариев, нагрузка упирается в бэкенд, но случаи разные бывают

3. Про DDP можно отдельную статью написать, но тут, как я уже говорил, несколько оффтопик. RAID-DP это все же двойная четность (DP — double parity), диагональная из них только одна.

4. и PS. как поклоннику NetApp, софтовой компании, вам должно быть очевидно: «полный редизайн» может затронуть только софт (или его идеологию). Появление блочной дедупликации, стремление сделать «честные» снапшоты — явно не косметика. По поводу предпочтений спорить не буду, у каждого свои. Сам я не испытываю антипатии практически ни к одному вендору (с инженерной точки зрения), с маркетинговой точки зрения — может быть. Но вы должны понимать, что не мы являемся целевой аудиторией этого маркетинга.
1. Производительность контроллера измеряется в операциях в секунду, а СХД в скорости скачивания/закачивания данных и временных задержках. Если с точки зрения ФЛОПСов вы абсолютно правы, то связь их с Gbps и latency ms — вы видимо как-то превратно понимаете.
3. Меня уже столько раз в это тыкали инструкторы из нетаппа что я с радостью ткну и Вас. У нетаппа RAID-DP — это именно diagonal parity. И да — диагональная из двух четностей только одна.
4. Судя по виду предлагаемого решения ЕМС, как разработчик, халатно пренебрегает юзабилити кейсами при тестировании, сообщает некорректные сведения о системе и тд, нехорошо себя вобщем ведет. И да. На тему несофтовой компании. ЕМС моглибы и шасси разработать под свои нужды или хотябы взять шасси у хитачи… Но учитывая количество супермикры в решениях ЕМС (КС — видел) — помолчу…
1. Если я что-то превратно понимаю, поднимите мне веки :) Еще раз, постановка задачи. Если оба контроллера в 2х контроллерной системе загружены на 80%, то как один оставшийся (вдвое меньше портов и мозгов) сможет дать 160% производительности.

3. можете дать ээ прфулинк? Я могу

The next level in the evolution of RAID data protection is RAID Double Parity, or RAID-DP (an implementation of RAID 6), available on the entire Network Appliance data storage product line.

Ранний документ
www.netapp.com/us/system/pdf-reader.aspx?m=3298.pdf&cc=us

NetApp introduced double-parity RAID, named RAID-DP, in 2003, starting with the Data ONTAP® 6.5 architecture.

И новый
communities.netapp.com/docs/DOC-12850

Вы понимаете какая штука, в обычном RAID5 четность как раз диагональная. И в RAID6 тоже. А вот в RAID-DP она смешанная, есть типичная для RAID-4 (на отдельном диске) и дополнительная (диагональная), которая считается со всех дисков RAID-4, включая диск четности.

Так что можете ткнуть инструкторов ответно.

4. Еще раз, приверженность бренду — вопрос пристрастий. Я знаю ендюзеров, которые кроме EMC ничего видеть не хотят. И аргументируют свою позицию.
1. Никак. Другой вопрос. 80% чего у вас нагружено в двух контроллерах и как вы это балансируете? насколько нагружен межконтроллерный канал? какая потеря латенси на межконтроллерной синхронизации? Перевожу на русский. Если солдат тащит со скоростью 10 км/ч и тащит 40 кг. Это значит что два солдата могут со скоростью 10 км/ч меперь 80 кг, а не со скорость 20 км/ч переть 40кг.
3. В Raid-5 страйп горизонтален как горизонт. В 6-ке тоже самое, только не XOR а соломон-рид в качестве алгоритма вычисления парити.
В RAID-DP одна парити горизонтальная (тоесть считается через весь страйп), другая диагональная (читается через количество страйпов равных количеству дисков) в техдоках называется RDP (row-diagonal parity, для длузей просто diagonal parity)
dtrace.org/blogs/ahl/2011/09/21/on-raid-6-recovery/
По ссылке статья по evenodd и rdp как внедрениям двух дисков четности (на мой взгляд кривым и страшным как смертный грех, пользуясь случаем поругаю НетАпп и Ибм :) ). Кстати за этот изврат вот уже не люблю нетапп. код соломона рида им чемто непонравился, в результате если бы не вафля — у них бы система умирала при случайной записи-перезаписи на раз-два.
www.aptiris.com/products/whitepapers/RAID_DP.pdf
Специально картинка от нетаппа. Тоже что и в статье выше но воды сильно много. Диагональный — он и в африке диагональный. Что правда не мешает бы двойной.
Вы видимо диагональной четностью называете ту которая ползает по диагонали, но считается горизонтально? А тут это которая по диагонали считается и лежит на одном диске. Так что упс.
Типичная вендорская подмена понятий :)
1. Хорошо, упростим задачу, если никак не доходит. Если bandwidth на обоих контроллерах на 80%, насколько упадет производительность после перехода на один? Детсад какой-то.
3. Я на кой вы мне это рассказываете? Я в курсе как устроены RAID-5 и RAID-DP
1. Прочитайте о чем я писал в пункте 1 изначально и удивитесь увидев слово латенси, в приложении к переключению одного LUN'а между двумя контроллерами и в случае смешанного использования. И обратите внимание на слово латенси. Слова bandwidth там нет. Основное заявление именно в этом отношении с сформулировано.
3. Еще раз. Посмотрите документ. Там красиво и со схемками. Диагонально в NetApp RAID-DP расчитывается только одна четность из двух.
1. Вы о чем-то глубоко своем поете, и, может быть в силу своей врожденной тупости, я вас не понимаю.
3. Не пойму с какое мое или свое или еще какое-то утверждение вы пытаетесь оспорить.
Хотя в общем и целом. На ЕМС мне пофигу. В общем: да — у них стало лучше. Но хвалебные оды типа данного поста коробят душу и выжигают стул. У них не лучше всех и даже не наравне со всеми, если вводить цену в уравнение лучшести.
А ведь когда то были у них и первые ЕФД(enterprise flash drive)… А сейчас какая у ЕМС уникальная фича?
Про излишне слащавую подачу материала соглашусь.
Сейчас у EMC уникальная фича — VMware :) Если серьезно отвечать — то опять же оффтопик будет.
Уникальная фича под названием vmWare была куплена ЕМС почти 10 лет назад. Учитывая что на фронте виртуализации сейчас активно наступают Microsoft & Citrix,…. Но насчет оффтопа согласен.
На всякий случай еще прокомментирую, чтобы не было разночтений:
— понятие «Диагональности» относительно RAID5,6 и RAID-DP отличается (в одном случае диагонально расположены блоки четности, в другом случае диагонально рассчитывается четность)
UFO just landed and posted this here
Выпейте новопасситу. Это не было оскорблением или издевкой. И NetApp является софтовой компанией (торгуется на бирже как софтовая компания).
2. На пулах выделение пространства происходит с гранулярностью в 1 ГБ. А потом внутрь этого 1 ГБ пишутся данные по 8КБ. Это справедливо для первых VNX.
Т.к. в новых VNX FAST VP перевели на гранулярность в 256МБ, то я предполагаю, что и предоставление пространства происходит по 256МБ (пока я упоминаний этого не видел).
Да, так и есть, размер slice 256МБ, значит и пространство в пулах будет выделяться кусками по 256МБ (для thick LUN). Что, в целом, не меняет сути вопроса, разница в выделении пространства кусочками по 8KB и 256МБ достаточно велика.
Суть как раз в том, что thick лун аллоцирует всё своё пространство сразу, а thin — по требованию, но оба механизма аллокации работают с одним размером в 1ГБ для старых / 256МБ для новых массивов. Просто в случае thick эти аллокации идут сразу друг за другом.

Т.е. если после записи очередного полного ГБ, thin LUN потребуется записать следующие 8КБ, будет выделено пространство в пуле размером 1ГБ / 256МБ, а потом туда уже будут заноситься 8КБ блоки.
Эээ, давайте так, старый VNX:
— Thick тома, место резервируется но не выделяется. Выделение происходит при записи, блоки (слайсы) по 1ГБ. Блоки при этом непрерывные (в терминах LBA).
— Thin тома не резервируются при создании. Пространство так же выделяется слайсами по 1ГБ, но эти слайсы не являются непрерывными, и фактически выделение происходит фрагментами по 8KB
— начиная с какой-то версии ПО (не помню точно) Thick тома стали выделять сразу при создании.

C новым VNX все тоже самое, только размер слайса стал 256МБ
As new writes come into a thin LUN or thick LUN, more physical space is allocated in 1GB slices. This storage-on-demand ensures that at least a 1 GB slice is available at all times. LUN metadata is also embedded within these additional 1 GB.

EMC VNX Virtual Provisioning. Applied Technology. R31

As new writes come into a thin LUN, more physical space is allocated in 1GB slices. This storage-on-demand ensures that at least a 1 GB slice is available at all times. LUN metadata is also embedded within these additional 1 GB. Data is written to thin LUN in 8KB chunks and optimally placed within 1 GB slices.

EMC VNX Virtual Provisioning. VNX5100, VNX5300, VNX5500, VNX5700, and VNX7500. Applied Technology. R32

A slice is a unit of capacity which is allocated from private RAID Groups to the pool LUN when it need additional storage. Starting with VNX Operating Environment (OE) for Block Release 33, the slice size has been reduced from 1GB to 256 MB.

EMC VNX Virtual Provisioning for the New VNX Series. VNX5200, VNX5400, VNX5600, VNX5800, VNX7600 & VNX7500.

То есть slice — минимальная неделимая величина. Так что фрагментации по 8КБ нет. Может быть только по 1ГБ / 256 МБ.
community.emc.com/docs/DOC-24278

Thick LUN:

When a Thick LUN is created, the entire space that will be used for the LUN is reserved; if there is insufficient space in the Pool, the Thick LUN will not be created. An initial allocation of 3 GiB holds metadata and user data, and as users save additional data to the LUN, 1 GiB slices will be allocated as needed. These slices contain 1 GiB of contiguous Logical Block Addresses (LBAs), so when a slice is written for the first time, it will be allocated to the Thick LUN. Since tracking happens at a granularity of 1 GiB, the amount of metadata is relatively low, and the lookups that are required to find the location of the slice in the Pool are fast. Because lookups are required, Thick LUN accesses will be slower than accesses to Traditional LUNs.

Thin LUN:

Thin LUNs also allocate 1 GiB slices when space is needed, but the granularity inside those slices is at the 8 KiB block level. Any 1 GiB slice will be allocated to only 1 Thin LUN, but the 8 KiB blocks will not necessarily be from contiguous LBAs. Oversubscription is allowed, so the total size of the Thin LUNs in a Pool can exceed the size of the available physical data space. Monitoring is required to ensure that out of space conditions do not occur. There is appreciably more overhead associated with Thin LUNs than with Thick LUNs and Traditional LUNs, and performance is substantially reduced as a result.


Итого, в случае thin блоки 8KB внутри слайса не обязательно идут подряд. Это называется фрагментация, нет?
Пространство так же выделяется слайсами по 1ГБ, но эти слайсы не являются непрерывными, и фактически выделение происходит фрагментами по 8KB


Я понял вашу цитату именно, как получение по 8КБ из private raid group, а не как получение с приватных групп по одному slice, а внутри по 8КБ.
Сам slice в рамках пула является непрерывным и занимает непрерывное место на дисках (незаписанные данные числятся нулями). Внутри его для тонких томов имеется фрагментация по 8КБ.
Поэтому получается две разные фрагментации: одна на уровне пула — когда слайсы для тонких томов берутся не по порядку, а вторая на уровне слайсов.
Active-active работает на классических LUN'ах только. Опять же, потому что классические луны используются в основном под приложения, которым требуется более высокий performance.
Вот не понял логики. Вроде AA нужен для того, чтобы равномерно загружать контроллеры. Причем тут классические луны и какие-то там приложения?
Active-active прежде всего нужен, чтобы доступ к LUN'у был одновременным по двум путям через оба Storage Processor'а. При нормальной работе, это увеличивает производительность. В случае недоступности одного из путей или сбоя SP, это позволяет не тратить драгоценные миллисекунды на trespass LUN'а с одного SP на другой.

Выровнять нагрузку между двумя SP в старом случае можно было путем распределения лунов между процессорами по степени активности IO к этим лунам, там есть такой параметр как SP Owner. Думаю, вы знаете про него.
Я надеюсь, что вы сознательно уклоняетесь от ответа на вопрос. Иначе придется предположить, что вы его не поняли.
Если правильно понимаю, то изначально вопрос был:
А актив актив полноценный? Т.е. он только на «просто» RAID или на пулы тоже?


Я ответил выше, что AA работает только на классических лунах. То есть pool LUNs не поддерживаются. Это есть в документации на системы.

Или вопрос был в чем-то другом?
Active-active работает на классических LUN'ах только. Опять же, потому что классические луны используются в основном под приложения, которым требуется более высокий performance.


Какое отношение к выравниванию нагрузки на контроллер имеет тип «диска» (классический или из пула). Почему в одном случае AA работает, а в другом нет. Почему вы говорите о «performance»? Балансировать нагрузку к 500 относительно медленным лунам менее важно чем к 5 быстрым?

Если вы даете дополнительный комментарий «от себя» к документации — будьте добры выражаться полнее.

UFO just landed and posted this here
1. Были использованы новые процы и новая архитектура самой головы. Весь софт переписан заново, только Unisphere оболочка выглядит как у старой серии.
2. Нет, т.к. новый софт написан под новую архитектуру.
3. Полки обновлять смысла нет, они такие же как и в предыдущей серии VNX.
4. Гранулярность блочной дедупликации 8КБ.
3. Имелось ввиду использование старых полок с данными под новыми головами. Такой возможности по прежнему нет, т.е. для миграции нужно хранилище «посредник» + перенастройка

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

Чтобы перенести данные со старой системы на новую потребуется миграция. Можно использовать хранилище «посредник». Можно обойтись и без него, мигрируя напрямую.
«Заплатить нужно не меньше тридцати тысяч долларов» — вы издеваетесь? За такие деньги можно получить только самую минимальную комплектацию, и то не уверен. Один SSD под фаст кэш двести гигов — в базовых ценах — девять килобаксов.
Рассказали бы лучше, избавились ли от ограничения в 16 Тб на лун? Почему вдруг в контроллере на борту нет больше FC портов, и надо брать I/O карточки? Почему перформанс стал лицензироваться потерабайтно? Сколько стоит открытие дедупликации?
Нет, я очень люблю EMC, отличная железка, по мне так лучше нетапа и сторвайза. Сам скоро беру VNX5200. Но давайте же будем до конца честными!
пусть не до конца, пусть хотя бы чуть чуть :)
А чем у Вас мотивируется нелюбовь к Нетаппу и Бизнесмашинам?
Я не троллю, но, возможно, просто мы их с разных сторон видим :)
Из нареканий на сторвайзы и других бизмашины — только тормозная техподдержка. У нетаппа тоже тормозят, но только не в критикал случаях. Если объясняешь что возможен даталосс — скребут землю когтями до базальта.
По функционалу — толковые управляшки и командная строчка у меня приступов паники не вызывали. По скоростям — за свои деньги работают отлично.
30к — это именно именно для минимальной конфигурации.

Максимальный размер луна в пуле теперь 256 ТБ.

Почему нет встроенных портов — к сожалению не могу сказать чем руководствовались архитекторы ЕМС.

Дедупликация входит в базовый комплект лицензий, отдельно за неё платить не надо.

И последнее, в статьях я всегда стараюсь писать максимально честно, но это мое понимание и мой взгляд на тему. Ну ладно, мой и технарей Крок. Наши технари от этого массива в восторге, по блочной части подавляющее большинство хотелок и даже кое чего о чем и мечтать не могли, воплотили в жизнь. И это здорово!
ЛУН на 256 ТБ по факту не востребован. Единичному устройству он не нужен. В качестве шаред вольюма для группы хостов — рано или поздно они начнут блокировками просаживать производительность ниже плинтуса.
Хотя вынужден извинится и признать, что 16 ТБ всетаки маловато.
Добавлю свои пять копеек в дискуссию. В один пост соберу всё, что хочется сказать.

Дисклаймер. Я работаю в EMC. Но здесь буду высказывать своё личное мнение, которое может не совпадать с официальной точкой зрения компании.
Конечно, я могу быть не совсем объективен. С другой стороны, можете обращаться ко мне с вопросами.

Итак.
1. Про CentOS. Данная ОС не является поддерживаемой какой-либо единой компанией, а не community, нет единого центра поддержки, с которым контактируют пользователи и с которым производители могли бы заключать соглашения на тему кросс-поддержки. Т.е. если производитель железа находит баг или же система нестандартно работает с неким конкретным железом, то производитель мог бы открыть заявку в поддержке ОС. Именно поэтому в матрице поддержки EMC CentOS практически не упоминается, а Red Hat Linux и SUSE Linux имеются. И, соответственно, вся документация рассчитана именно на этих представителей Linux-систем.

2. Документация. Да, большая часть документации находится на портале, требующем авторизации. Я не сильно силён, почему это так, но это, как минимум, исторически сложилось. Кроме документации, портал отвечает за работу с лицензиями, открытием сервисных заявок и их мониторингом и много чего ещё. Т.о. являясь клиентом EMC, вам доступ на портал полезен в том или ином виде. И, с точки зрения контроля доступа, им проще управлять. Есть документы, доступные только разработчика, или же ещё и сотрудникам, партнёрам, конечным пользователям. Хотя поиск, конечно, там далёк от гуглового. Это про закрытую часть.
Насколько я помню, в документации, как в бумажной, так и электронной, идущей с системами VNX, содержится ссылка на mydocs.emc.com/. На данном сайте достаточно легковесный и удобный в обращении помощник по созданию документации на типовые задачи по работе с массивами VNX. В том числе и инициализация, и включение/выключение и подключение серверов. Данный сайт оперативно обновляется и уже содержит информацию на основе актуальных версий прошивок.
Относительно прошивок есть нюанс. Они не предоставляются конечному пользователю потому, что обновление на данный момент считается сервисной операцией и должно выполняться сервисным инженером EMC или партнёра. Весь бесплатный host-based софт доступен для скачивания.

3. Про Windows-only. Управление системами VNX, в том числе с точки зрения сервисной, действительно наиболее удобно с управляющей станции с ОС Windows (не исключено, что во многом это связано с работой Windows на блочных контроллерах :) ), но все задачи возможно выполнить и без присутствия оной. Например, системы обладают опцией подключения к инфраструктуре компании EMC для автоматического заведения заявок и удалённого решения проблем (ESRS) и при этом сервисные инженеры подключаются к массивам без GUI Unisphere и USM.
Сбор конфигурационно-диагностической информации очень прост через USM (Unisphere Service Manager), работающего на Windows. Но, ещё со времен систем CLARiiON CX-серии (их было 4 поколения), которые являются предшественниками VNX, в интерфейсе Unisphere всегда присутствует возможность сбора и скачивания SPCollect для каждого из контроллеров блочного доступа (SPA и SPB) по-отдельности. Сейчас это называется Generate Diagnostic Information и Get Diagnostic Information.
Более того, блочный VNX может управляться по IP через CLI-интерфейс, который доступен для большинства ОС и для некоторых задач имеет даже больший функционал, чем графическая консоль. В том числе может выполнять инициализацию массива.

4. Про поддержку. Системы VNX традиционно продаются в России с так называемой комбинированной поддержкой. Т.е. первой линией поддержки выступает компания-партнёр. Как, например, КРОК. И лишь по решению партнёра (недостаток компетентности, необходимость замены компонент или же требуется привлечение команды разработчиков) открывается заявка в центре поддержки EMC. В конкретных упомянутых случаях я бы посоветовал уточнить, кто и как оказывает поддержку и всегда можно пожаловаться в EMC на низкий уровень оной, как от инженеров партнёров, так и от инженеров EMC. Эти случаи обычно весьма серьёзно разбираются. Hint: спрашивайте «Who`s your manager?» в случае каких-либо проблем.

5. Про удалённое выключение. В обсуждении привели показательный пример про ураган Сэнди, когда это действительно может понадобиться. С другой стороны это так же пример несогласованности работ по восстановлению. Моё личное мнение, что в большинстве случаев раз уж за удалённым выключением последует удалённое включение, то эти операции можно выполнить открытыми на задней панели тумблерами. А при форс-мажорах питание в ЦОД должно подаваться на потребителей по окончанию восстановительных работ полностью.
По факту в системах VNX давно существует опция удалённого выключения, просто до новой версии прошивки она не была реализована в виде отдельной кнопки интерфейса. Хотя унифицированные системы имеют в своём арсенале nas_halt. Или, например, для DataMover, контроллера файлового доступа, имеется команда server_CPU shutdown -halt.
Контроллеры блочного доступа можно выключить через CLI командами naviseccli shutdownpeersp и naviseccli shutdownsp.

6. Стоимость и лицензии. Всё очень сильно варьируется и зависит. 30 000, скорее всего, была озвучена цена price-list. В каждой конкретной сделке цена является обсуждаемой. И сейчас, всё с большим желание выйти на рынок SMB, появляются очень выгодные цены на младшие модели. Опять же для небольших конфигураций можно рассмотреть и семейство VNXe.
Бесплатный функционал, который возможно установить в любой момент, включает в себя поддержку ODX, дедупликацию, сжатие, SANCopy для миграции данных на блочном уровне, в том числе со сторонних массивов, и Virtual (Thin) Provisioning. Остальной функционал объединён в бандлы, которые лицензируется по объёму с разной стоимостью на ТБ для SSD/SAS и SATA. Есть исключения, но в общем это так. Я подробностей лицензирования по объёму не знаю, но предполагаю, что связано это с разницей в размерах таких вещей, как налог на продажу железа, налог на продажу софта, скидка на железо, скидка на ПО и т.п. Т.е. раньше стоимость ПО больше закладывалась в стоимость железа, нежели сейчас.

7. Специфики конфигурации. Такие как отсутствие встроенных портов. Скорее всего связано с маркетинговыми целями и снижением стоимости на минимальные конфигурации, а так же предоставлением возможности выбора даже базовых портов из FC/iSCSI/FCoE.

8. Ограничения. Размер максимального тома на пуле был увеличен до 256 ТБ. При этом тома, отдаваемые файловым контроллерам, не должны превышать 16 ТБ. Многие другие цифры, как количество локальных/удалённых копий на систему, тоже увеличились в связи с большей масштабируемостью систем.
Мой личный опыт подсказывает избегать томов слишком большого размера, т.к. это уменьшает гранулярность управления. Т.е. если на томе в 20 ТБ свободно 5 ТБ, то их другому хосту не отдашь, а вот если это было 10 томов по 2ТБ, то 4 ТБ запросто можно. Это с одной стороны. А с другой мы имеем лимитированную глубину очереди на каждый том, т.е. чем больше томов (в разумных пределах), да ещё в страйпе на стороне хоста, тем большую суммарную глубину очереди мы имеем.

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

10. Active-Active. Работает на данный момент только для томов на Raid Group. Для томов на пулах или при включении любых интеллектуальных функций будет работать уже стандартный ALUA. С дальнейшим развитием кода функционал Active-Active будет доступен для всех томов. Отдельно отмечу, что к служебным томам, на которых строится концепция пула, доступ осуществляется в режиме Active-Active.

11. Доступность нового функционала на старых моделях. Моё ИМХО. Фактически первая линейка VNX была эволюционным наследником CLARiiON. Все же прекрасно понимают, что разработка таких программно-аппаратных комплексов, как СХД, дело весьма затратное и продолжительное и все производители имеют карты развития на 3, а то и на 5 лет. Лично моё мнение, что пока шла разработка нового кода, первый VNX выпустили с одной стороны как наследника, чтобы не терять рынок, но и с рядом нововведений, которые успели довести до ума. У EMC стандартный цикл обновления СХД в 2 года: каждые два года либо происходит полное обновление линейки, либо заметная модернизация существующей. Как тик-так у Интела. Поэтому, возможно, было бы правильнее поменять название линейки, чтобы не было лишних надежд. Т.о. даже обновление кода до новой версии можно считать как конвертацию системы между поколениями. Это было, например, доступно в CLARiiON CX. Но общая база инсталляций показала, что этим функционалом пользовалось менее 1% всех пользователей систем, насколько я слышал. Видимо решили, что не слишком целесообразно держать группу по развитию конвертации ради 1%. Тем более, что через поколение становится более выгодным купить новую систему, чем продлевать поддержку на старую. Это дало отдельный толчок развитию механизмов миграции между массивами.

12. Про Java. Согласен. Но уже вышла новая прошивка с поддержкой Java 1.7.
Касательно CentOS. Мы, используя эту ОС, ориентируемся на руководства для RHEL 6, что, как правило, не вызывает каких-либо проблем в силу бинарной совместимости дистрибутивов.

Например, системы обладают опцией подключения к инфраструктуре компании EMC для автоматического заведения заявок и удалённого решения проблем (ESRS) и при этом сервисные инженеры подключаются к массивам без GUI Unisphere и USM.
Это не всегда возможно. СХД может быть установлена в закрытом контуре, из которого нет какого-либо доступа к внешним сетям.

Сбор конфигурационно-диагностической информации очень прост через USM (Unisphere Service Manager), работающего на Windows. Но, ещё со времен систем CLARiiON CX-серии (их было 4 поколения), которые являются предшественниками VNX, в интерфейсе Unisphere всегда присутствует возможность сбора и скачивания SPCollect для каждого из контроллеров блочного доступа (SPA и SPB) по-отдельности. Сейчас это называется Generate Diagnostic Information и Get Diagnostic Information.
В нашем случае, техподдержка заявила, что сбор необходимой диагностической информации возможен только через standalone софт. Если эта информация доступна через стандартный веб-интерфейс, то это просто недоработка инструкций, по которым работает ТП.

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

Такие ответы вызывают уважение, несмотря на указанные вами отрицательные моменты, в отличии от старательно увиливающих от ответов по существу и ведущих слащавые речи товарищей. В общем, мой вам плюс в карму, как специалисту и профессионалу.
Например, системы обладают опцией подключения к инфраструктуре компании EMC для автоматического заведения заявок и удалённого решения проблем (ESRS) и при этом сервисные инженеры подключаются к массивам без GUI Unisphere и USM.
Это не всегда возможно. СХД может быть установлена в закрытом контуре, из которого нет какого-либо доступа к внешним сетям.


Я хотел акцентировать внимание, что поддержка в таком случае работает без доступа к Unisphere и USM и при этом неплохо справляется, но, видимо, криво выразился.

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

Не стесняйтесь жаловаться сейлу и пресейлу, что работают с вами — от исправления таких недочётов все только выиграют.

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

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

Спасибо!
Не стесняйтесь жаловаться сейлу и пресейлу, что работают с вами — от исправления таких недочётов все только выиграют.
В моем случае, для того, чтобы узнать телефон техподдержки пришлось допрашивать 5-6 человек разных уровней из 3 или 4 подразделений. Толькоразборки с техподдержкой, чтобы понять кто именно должен её оказывать (EMC или интегратор), заняли три рабочих дня.

Для того, чтобы выяснить кто и через кого продал нашему подразделению эту СХД пришлось бы пообщаться с десятком или более человек в течении пары недель… Не самое лучшее времяпрепровождение для программиста =) Стандартная беда больших организаций (несколько тысяч человек).
X-Blade и файловая часть VNX — это всемирное зло.
1. Когда появится возможность создавать пользователей/группы CIFS непосредственно из GUI (Unisphere)? Заявления о том, что всем можно управлять из юнисферы неправда. Без Windows MMC не обойтись никак.
2. Когда юнисфера перестанет глючить (как web, так и локальный клиент)? На предыдущем поколении мне ни разу не удавалось включить файловую дудепликацию ввиду её подвисания при сохранении настроек. Естественно пробовал 100500 разных версий java (хотя и так стояла рекомендуемая) и разные компьютеры, версии ОС/браузеров. В итоге забил и пользуюсь CLI. Никогда не видел более медленного приложения на Java чем Unisphere. Иногда приходится ждать запуска юнисферы 3-4 минуты.
3. Когда EMC выпустит ESRS виртуальную машину для Hyper-V? Сейчас есть только для VMware. Нужен ESRS Gw на Linux (чтоб не платить за лицензию MS Windows). Самостоятельная настройка же сопряжена с выполнением действий описанных на 131-страничном мануале, что вызывает у меня душевную боль.
4. Когда поддержка перестанет посылать по любому вопросу не связанному с физической неисправностью массива в платный Professional service? Индусы молодцы конечно, но они не способны ответить ни на один вопрос связанный с настройкой массива. Им бы только диски сгоревшие диагностировать. У всех ваших конкурентов всё значительно дружелюбнее.

Вообще VNX по моему скромному мнению можно использовать для ряда задач, но его файловая часть — это что-то гестаповское.
Дисклаймер. Я работаю в EMC. Но здесь буду высказывать своё личное мнение, которое может не совпадать с официальной точкой зрения компании.
Конечно, я могу быть не совсем объективен. С другой стороны, можете обращаться ко мне с вопросами.

С опытом работы с Celerra/VNX и на стороне партнёра и на стороне EMC я сам имею ряд претензий к файловой части. Главная же претензия обычна одна — сильное отличие концепции от привычной. Но стоит осмотреться и всё становится понятно и логично. Одного у файловой части не отнять — эта штука очень надёжна и очень функциональна, за что, собственно, её и покупают.

А теперь по пунктам.

1. Возможно отсутствие запрашиваемого вами функционала обосновано отсутствием запросов на его внедрение?
Я за свою карьеру по внедрению Celerra/VNX ни разу не видел standalone файловых серверов, создаваемых на файловой части. В превалирующем большинстве компаний настройкой прав доступа и созданием пользователей/групп занимается Helpdesk и/или администраторы файловых серверов. И, в случае CIFS, это традиционно выполняется на уровне Active Directory.
У всех конечных пользователей всегда есть возможность оформить запрос на внедрение функционала через пресейлов/сейлов. В компании для этого даже есть специальная процедура.

2. Все проблемы с работой интерфейса Unisphere крайне рекомендую оформлять в виде сервисных заявок. Обычно тормоза связаны с проблемами в сети. В частности, связаны с настройками скорости подключения (всем известно, как «хорошо» в Ethernet работают автоматические настройки портов). Дополнительно могу посоветовать поставить локально на рабочей станции Unisphere Client(Windows) — тогда большая часть работы Java-апплетов будет выполняться локально.

3. Тут нужно уточнить о каком варианте/компоненте идёт речь. Есть ESRS Gateway — наиболее функциональная опция удалённого подключения. Данное ПО устанавливается и на Windows и на Linux. Поддерживается виртуализация и с помощью VMware и с помощью Hyper-V. Есть отдельный компонент Policy Manger — он действительно работает только под Windows и виртуализируется только при помощи VMware. Но он является опциональным. Или же речь идёт о ESRS IP Client, который работает только с CLARiiON/VNX и ставится на Windows?

4. Работа Customer Service нацелена на обеспечение работоспособности продуктов. Внедрениями, в том числе консультациями по настройке, занимается Professional Service. Такое разделение в рамках компании. В случае, когда вас перенаправляют в PS, есть смысле туда обратиться. Все вопросы решаются индивидуально. Очень часто, даже в особо сложных случаях, если вам и не ответят подробно, то дадут ссылки на документацию, где можно разобраться. А выполнение работ инженерами PS действительно платно, если работы не описаны в рамках конкретного договора.
1. Покупайте блочную часть, цепляйте на виндовые серваки и с них раздавайте файловый доступ. С одной стороны секс с файловой частью целиком на вас, с другой стороны — все свое и стреляет куда надо без юнисферы.
Sign up to leave a comment.