Хорошая вводная статья, ждем продолжения и подробностей. Как мне кажется, BigData — это довольно специализированная область, где необходима быстрая постоянная обработка большого объема данных «здесь и сейчас». Но иногда стоит вопрос вопрос простого хранения данных. Так что традиционные СХД все равно останутся, но в этой области их потеснят безусловно, ну они и не создавались для BigData.
Также есть ряд практических и общих вопросов/нюансов по тексту:
1) Как решается вопрос резервирования данных на уровне ноды?
«стартовать с определенного количества ресурсов (в нашем случае — 3 узла / нода / сервера)»
2) Три ноды — это уже с учетом fault tolerance? Если да, то получается 2 рабочие ноды и одна «запасная», так? Если нет, то сколько еще нужно standby нод для реальной минимальной конфигурации?
«после отказа жесткого диска на 4TB, восстановление целостности»
+
«Сколько времени будет перестраиваться большой массив (скажем на сотни терабайт) и RAID 6»
4) На мой взгляд не очень корректное сравнение.
Либо первое и Сколько будет перестраиваться диск на 4TB в RAID6?
или
Либо второе и Сколько будет перестраиваться RAIN на сотни терабайт?
«Современные процессоры Intel умеют очень многое, причем очень быстро.»
5) Почему же тогда для вычисления тех же самых биткойнов люди делали специальные процессоры или использовали FPGA?
Обычный процессор умеет многое и быстро, если грамотно написан софт. Но все же спец.железка, заточенная под определенную функцию будет быстрее.
да, SLA 100% реален
6) Звучит как будто вы создали вечный двигатель :) Вы гарантируете, что железо собрано на заводе без технолгических отклонений? Что софт написан без единой ошибки?
Эффектно, но, думаю, до полного автомата еще очень далеко. Тест наверняка синтетический, все полностью выверено на заранее известной трассе.
Ведь в обычной жизни машина не будет конусы объезжать «змейкой». Захотелось самому расставить препятствия на трассе и посмотреть что она будет с ними делать :)
Иногда техподдержка советует просто вытащить старый диск и вставить новый. Но если вы общаетесь с ТП по этому вопросу, то наверняка вы им присылали логи системы и они провели проверку такой возможности вручную, заместо wizard. Так что, это возможно, но бывают случаи когда так делать ни в коем случае нельзя.
Active-active прежде всего нужен, чтобы доступ к LUN'у был одновременным по двум путям через оба Storage Processor'а. При нормальной работе, это увеличивает производительность. В случае недоступности одного из путей или сбоя SP, это позволяет не тратить драгоценные миллисекунды на trespass LUN'а с одного SP на другой.
Выровнять нагрузку между двумя SP в старом случае можно было путем распределения лунов между процессорами по степени активности IO к этим лунам, там есть такой параметр как SP Owner. Думаю, вы знаете про него.
Сбойный диск явно отображался в интерфейсе плюс на нем горел оранжевый диод. Но, ТП опять же сказала, как заменять диск: использовать wizard (не пол раза не какой-то сторонний скрипт, а именно wizard в java интерфейсе). Только когда это не удалось специалист ТП сказал, что тогда надо просто вытащить диск. После извлечения диска таки автоматически подцепился другой из hot spare и пошел rebuild (тоже, кстати неочевидное поведение). Вставленный новый диск ушел в hot spare.
Если VNX видит, что на диск много ошибок, он заранее начинает копирование данных с него на Hot spare. Если что-то не успеет скопировать и диск выйдет из строя, то восстановит из parity. В итоге hot spare полностью замещает неисправный диск.
После того как неисправный заменен, данные автоматически начинают копироваться в фоне с Hot spare на новый диск.
По окончании этого процесса ребилда, hot spare остается hot spare, а новый диск занимает место старого.
Мне кажется, что-то здесь напутано, т.к. вставленный новый диск не мог уйти в hot spare. (если он только не был hot spare до замены :) )
3. Здесь вы немножко не правы. Wizard рекомендуется использовать, потому что он проводит ряд внутренних проверок системы, если все успешно, то разрешает замену.
3. К сожалению, да. В силу сложности и специфики двух системы, просто так переключить полки со старой головы на новую, сохранив данные, не получится, потому что информация о разбиении и использовании дисков на полках хранится в голове СХД. Точнее данные на полках то останутся, но новая голова не будет знать что они там есть.
Чтобы перенести данные со старой системы на новую потребуется миграция. Можно использовать хранилище «посредник». Можно обойтись и без него, мигрируя напрямую.
Active-active работает на классических LUN'ах только. Опять же, потому что классические луны используются в основном под приложения, которым требуется более высокий performance.
На одной и той же системе, производительность thin LUN будет всегда немного ниже, чем classic LUN, из-за внутренних процессов на обслуживание thinLUN. Можно было бы искуственно «замедлить» обычные луны, чтобы производительность сравнялась :) Но ведь это незачем делать.
Дедупликация используется чтобы «увеличить» полезную емкость системы, например, если система используется как долговременное хранилище данных, как библиотека.
Если нужна производительность, то лучше использовать старые добрые классические луны.
Тут важно не путать назначение. Ведь почти все как на домашнем ноутбуке: критически важную ко времени отклика ОС лучше ставить на SSD, а библиотеку фотографий лучше хранить на более емком HDD.
Обычно электрикам в опечатанную стойку лазить вообще не следует. Если работы затрагивают СХД, то, как правило, на площадке присутствует кто-нибудь ответственный за СХД и он проводит выключение/включение, при этом все администраторы и пользователи уведомляются заранее. Это если хранилка критически важна для бизнес процессов в компании. Если на площадке внезапно выключилось всё питание, то тут система сама аккуратно погасится, сохранив кэш — для этого как раз и нужны батареи — удаленное выключение тут не панацея.
Просто я, честно, не представляю ситуации, когда потребуется отключать СХД удаленно, если только когда она не критически важная и ехать на удаленную площадку не охото :)
1. Были использованы новые процы и новая архитектура самой головы. Весь софт переписан заново, только Unisphere оболочка выглядит как у старой серии.
2. Нет, т.к. новый софт написан под новую архитектуру.
3. Полки обновлять смысла нет, они такие же как и в предыдущей серии VNX.
4. Гранулярность блочной дедупликации 8КБ.
Корпус МС служит для защиты от механических повреждений кристалла, а также для защиты от химически активных веществ, которые содержаться как в жидкостях, так и газах, в т.ч. и в воздухе. Поэтому не факт, что после распила МС будет стойко переживать все внешние воздействия.
Статья, интересна только для поделок на коленке «для себя» и для ответа на вопрос «надо попробовать, вдруг получится?». Делать таким методом боевые проекты, и уж тем более проекты от которых зависит жизнь и здоровье людей не следует.
Компания ChipWorks производит реверс-инженеринг микросхем. Вот она этих микросхем перепилила кучу :)
Раньше за денежку можно было заказать реверс-инженеринг любого чипа, как сейчас — не знаю.
Также есть ряд практических и общих вопросов/нюансов по тексту:
1) Как решается вопрос резервирования данных на уровне ноды?
2) Три ноды — это уже с учетом fault tolerance? Если да, то получается 2 рабочие ноды и одна «запасная», так? Если нет, то сколько еще нужно standby нод для реальной минимальной конфигурации?
3) Какова максимальная конфигурация вашего кластера (количество нод, суммарная емкость дисков и суммарная полезная емкость)? Какова максимальная полезная емкость одной вашей ноды?
+
4) На мой взгляд не очень корректное сравнение.
Либо первое и Сколько будет перестраиваться диск на 4TB в RAID6?
или
Либо второе и Сколько будет перестраиваться RAIN на сотни терабайт?
5) Почему же тогда для вычисления тех же самых биткойнов люди делали специальные процессоры или использовали FPGA?
Обычный процессор умеет многое и быстро, если грамотно написан софт. Но все же спец.железка, заточенная под определенную функцию будет быстрее.
6) Звучит как будто вы создали вечный двигатель :) Вы гарантируете, что железо собрано на заводе без технолгических отклонений? Что софт написан без единой ошибки?
Ведь в обычной жизни машина не будет конусы объезжать «змейкой». Захотелось самому расставить препятствия на трассе и посмотреть что она будет с ними делать :)
Я говорю, что для каждого применения можно и нужно использовать подобающий инструмент. Не стоит забивать гвоздь кувалдой, а сваи молотком.
Я ответил выше, что AA работает только на классических лунах. То есть pool LUNs не поддерживаются. Это есть в документации на системы.
Или вопрос был в чем-то другом?
Выровнять нагрузку между двумя SP в старом случае можно было путем распределения лунов между процессорами по степени активности IO к этим лунам, там есть такой параметр как SP Owner. Думаю, вы знаете про него.
Если VNX видит, что на диск много ошибок, он заранее начинает копирование данных с него на Hot spare. Если что-то не успеет скопировать и диск выйдет из строя, то восстановит из parity. В итоге hot spare полностью замещает неисправный диск.
После того как неисправный заменен, данные автоматически начинают копироваться в фоне с Hot spare на новый диск.
По окончании этого процесса ребилда, hot spare остается hot spare, а новый диск занимает место старого.
Мне кажется, что-то здесь напутано, т.к. вставленный новый диск не мог уйти в hot spare. (если он только не был hot spare до замены :) )
Чтобы перенести данные со старой системы на новую потребуется миграция. Можно использовать хранилище «посредник». Можно обойтись и без него, мигрируя напрямую.
Дедупликация используется чтобы «увеличить» полезную емкость системы, например, если система используется как долговременное хранилище данных, как библиотека.
Если нужна производительность, то лучше использовать старые добрые классические луны.
Тут важно не путать назначение. Ведь почти все как на домашнем ноутбуке: критически важную ко времени отклика ОС лучше ставить на SSD, а библиотеку фотографий лучше хранить на более емком HDD.
Просто я, честно, не представляю ситуации, когда потребуется отключать СХД удаленно, если только когда она не критически важная и ехать на удаленную площадку не охото :)
2. Нет, т.к. новый софт написан под новую архитектуру.
3. Полки обновлять смысла нет, они такие же как и в предыдущей серии VNX.
4. Гранулярность блочной дедупликации 8КБ.
Поэтому ждем статью «Как распаять на плате бескорпусную интегральную схему с помощью паяльника и клея „Момент“ ;)
Статья, интересна только для поделок на коленке «для себя» и для ответа на вопрос «надо попробовать, вдруг получится?». Делать таким методом боевые проекты, и уж тем более проекты от которых зависит жизнь и здоровье людей не следует.
Раньше за денежку можно было заказать реверс-инженеринг любого чипа, как сейчас — не знаю.