Maestro ускоряет любые дисковые СХД, в том числе наиболее современные. Ещё раз — это кэш на чтение, а не виртуализатор. К чему его подключить — ваш выбор. Maestro не требует изменения конфигурации СХД и не влияет на уже используемый функционал, а также прозрачно добавляется и выводится из инфраструктуры. Если у вас много задач именно чтения, логично в ряде случаев приобретать вместо дорогой flash-СХД более бюджетный вариант и ускорять его Maestro.
Коллега, противоречия тут нет. Конечно, мой уважаемый заказчик не станет «выдерать» 64 ядра из своего сервера :) Основная идея, т.к. моей целью является именно освещение новых подходов, а не погружение в дискуссии о терминах, в том, что механические диски достигли своего «потолка» по скорости вращения и, как результат, времени отклика. Во многих случаях, как вы верно заметили, бутылочное горлышко именно в СХД. Добавляя шпинделей мы увеличим пропускную способность и максимальное количество операций ввода-вывода, но я говорю о принципиально другом подходе: полный переход на флеш. Это влечет за собой лавинный эфект при проектировании системы: количество процессоров, количество лицензий, количество серверов, количество стоек в ЦОДе, количество портов в коммутаторах. И мне эти изменения действительно нравится.
Полезная емкость без учета дедупликации порядка 7Тб. Уровень избыточности N+2 с восстановлением данных вышедшего из строя диска параллельно на все «живые» диски в системе. Т.е. вместо дисков горячей замены используется зарезервированная под это емкость, либо свободная доступная емкость на дисках.
Я весьма рад, что БД занимается другими «важными делами», однако, тот факт, что если данных в кэш-памяти нет, то пока они не придут от СХД, транзакция не выполнится я думаю, вы не отрицаете? То, что процессор не загружен не означает, что ему есть чем заняться эти 5мс, которые он ждет каждый IO. Тем более, раз вы верите в увеличение загруженности процессоров, что неизменно приводит к росту производительности в пересчете на процессор. Это мы видели уже на боевом внедрении, когда утилизация мощных RISC серверов наконец-то «взлетела» при шестикратном росте производительности приложения.
Это тонкий момент связанный с работой CPU. С момента, когда процессор отправил команду на чтение или запись куска данных до момента подтверждения он входит в цикл ожидания. Для БД это параметр IO_WAIT. В некоторых случаях он может достигать 70% всего времени работы. Если СХД отвечала не 5мс, а 0.5мс, это существенно повышает реальную эффективность CPU. Получается, что либо больше транзакций/виртуалок и т.п на ядро, либо меньше ядер на тот же объем данных.
Pure Storage, Nimble Data, Whiptail (Cisco), Nimbus и др. – следим за ними, но в РФ о них пока рано говорить, если речь идет о сегменте Enterprise.
Nutanix — это уже коробка с виртуализацией, которую сложно использовать в гетерогенной облачной среде, где необходимо использовать несколько гипервизоров: KVM, VMWare, Xen. Например, для нашего «облака» эта коробка по результатам тестов просто не подошла. И если ваша задача не виртуализуется — забудьте про Nutanix. В общем, решение интересное, имеет право на жизнь, но пока очень нишевое с моей точки зрения. Плюс очень важно учитывать, что один брик EMC на практике поддерживает раз в 10 больше виртуальных машин, чем два описанных юнита — часто это важно в разрезе стоимости лицензий и решения других узких мест.
У неё нет дедупликации «на лету» — только для VDI разница может быть в несколько десятков раз. Ну и тесты надо делать одинаковые, на одном стенде, иначе разница в результатах IOPS может быть очень большой.
Нет, это цена по прайсу только коробки с фотографии до ката. Это 6 юнитов.
Как я уже говорил, в реальности, во многих случаях цена довольно ощутимо ниже благодаря различным программам EMC.
Денег стоят не столько сами диски, сколько тот факт, что если их поместить в другую систему классом ниже, такой производительности для пиковых нагрузок и надёжности добиться просто не удастся.
Каждую плату для СХД нужно разработать и протестировать, а потом протестировать их на вместе совместимость. Кроме того, СХД — это не только железо, но и софт. На его разработку и тестирование (а тестирование очень серьезное, ведь речь идет о критичных данных) тратится очень много денег и усилий.
Более того, в эту цену включена поддержка и замена запчастей в течение 3 лет.
Используются и SLC, и MLC. Конкретно в XtremIO сейчас доступны только MLC модули. SLC даёт несколько большую производительность и ресурс перезаписи при значительно меньшем объёме на кристалл — их имеет смысл использовать только в очень «экзотических» задачах со сверхинтенсивной нагрузкой на запись.
Технология MLC же позволяет многослойную запись, что несколько снижает производительность, но даёт двойной и даже иногда более выигрыш в объёме. Однако, чипы выполненные по этой технологии, способны пережить меньше операций записи.
Последние годы MLC всё ближе к SLC по сроку службы, плюс благодаря правильной работе контроллеров есть возможность делать некоторые tradeoff в сторону производительности поближе к SLC. Поэтому в общем случае используются именно MLC как более экономически оправданные, а в частных, особо тяжелых случаях (в России — единичных) используются SLC чипы.
На самом деле, во многих случаях цена заметно ниже — я уже говорил, есть ряд специальный скидочных программ от вендора. Однако если говорить в целом — железо такого класса используются для тех случаев, когда нужно убрать конкретное узкое место. То есть производители постарались максимально улучшить характеристики производительности, что, естественно, сказалось на цене.
Железка для специальных задач вроде высоконагруженных VDI сред и СУБД, куда раньше ставили Hi-End или топовый Mid-Range, которые стоят еще больших денег при меньшем эффекте.
30к — это именно именно для минимальной конфигурации.
Максимальный размер луна в пуле теперь 256 ТБ.
Почему нет встроенных портов — к сожалению не могу сказать чем руководствовались архитекторы ЕМС.
Дедупликация входит в базовый комплект лицензий, отдельно за неё платить не надо.
И последнее, в статьях я всегда стараюсь писать максимально честно, но это мое понимание и мой взгляд на тему. Ну ладно, мой и технарей Крок. Наши технари от этого массива в восторге, по блочной части подавляющее большинство хотелок и даже кое чего о чем и мечтать не могли, воплотили в жизнь. И это здорово!
Вообще, ваши проблемы не связаны с диагностикой, они связаны с саппортом, жаль что вы столкнулись с таким непониманием в вашей поддерживающей организации. Все необходимое можно было сделать гораздо проще.
Про питание. Как вам корректно заметили ниже — СХД не требует особого внимания при проведении работ по электропитанию. В исключительных случаях подразумевается плановая операция, которая включает присутствие специалиста локально на площадке, так что в общем-то проблема надумана. Скажите, у вас бывали потери данных, или длительная их недоступность из-за отсутствия такого функционала в 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.
1) Железо используется более быстрое и удобное. Плюс использование новых подходов дало возможность выжать из нового железа в разы больше.
2) К сожалению, нет. Софт слишком сильно меняет подходы к работе с железом. Не получается апгрейдить старое без потери данных.
3) Да, такая возможность есть.
4) 8 КВ.
Ой, вижу, вижу что-то не то вы с СХД делали. Отвечу по порядку.
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. Он дружелюбный, но сам выбирает друзей.
Вендор пишет 2 варианта: меньше 1 мс в общей презентации и до 0,25 в результатах синтетических тестов. Мы проверили насколько вторая ситуация чаще встречается на практике.
Да, различные технологии ускорения записи есть и конкурентов, однако если посмотреть на аналитический график в посте, то вы увидите, что почти все решения страдают значительным «обрывом» производительности. Почему так происходит? Точного ответа я не знаю, но есть некоторые соображения. Во-первых, до недавнего времени дисковые СХД hi-end и mid-range класса garbage collecting-ом вообще не занимались, за редким исключением. Во-вторых, вероятно не все алгоритмы «одинаково полезны» — может конкуренты пожадничали с резервируемым пространством. В любом случае “write cliff” в SSD системах — это проблема, которая в большинстве систем не решена.
Pure Storage, Nimble Data, Whiptail (Cisco), Nimbus и др. – следим за ними, но в РФ о них пока рано говорить, если речь идет о сегменте Enterprise.
Как я уже говорил, в реальности, во многих случаях цена довольно ощутимо ниже благодаря различным программам EMC.
Каждую плату для СХД нужно разработать и протестировать, а потом протестировать их на вместе совместимость. Кроме того, СХД — это не только железо, но и софт. На его разработку и тестирование (а тестирование очень серьезное, ведь речь идет о критичных данных) тратится очень много денег и усилий.
Более того, в эту цену включена поддержка и замена запчастей в течение 3 лет.
Технология MLC же позволяет многослойную запись, что несколько снижает производительность, но даёт двойной и даже иногда более выигрыш в объёме. Однако, чипы выполненные по этой технологии, способны пережить меньше операций записи.
Последние годы MLC всё ближе к SLC по сроку службы, плюс благодаря правильной работе контроллеров есть возможность делать некоторые tradeoff в сторону производительности поближе к SLC. Поэтому в общем случае используются именно MLC как более экономически оправданные, а в частных, особо тяжелых случаях (в России — единичных) используются SLC чипы.
Железка для специальных задач вроде высоконагруженных VDI сред и СУБД, куда раньше ставили Hi-End или топовый Mid-Range, которые стоят еще больших денег при меньшем эффекте.
Максимальный размер луна в пуле теперь 256 ТБ.
Почему нет встроенных портов — к сожалению не могу сказать чем руководствовались архитекторы ЕМС.
Дедупликация входит в базовый комплект лицензий, отдельно за неё платить не надо.
И последнее, в статьях я всегда стараюсь писать максимально честно, но это мое понимание и мой взгляд на тему. Ну ладно, мой и технарей Крок. Наши технари от этого массива в восторге, по блочной части подавляющее большинство хотелок и даже кое чего о чем и мечтать не могли, воплотили в жизнь. И это здорово!
По инструкции — лицензия не нужна, называется 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.
2) К сожалению, нет. Софт слишком сильно меняет подходы к работе с железом. Не получается апгрейдить старое без потери данных.
3) Да, такая возможность есть.
4) 8 КВ.
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. Он дружелюбный, но сам выбирает друзей.