Комментарии 7
Симпатично, перекрашивать будете?
Спасибо, подымайтесь уже «на главную» :)
Несколько реплик:
> в основании структуры лежат 256-мегабайтные сегменты, на которые разбиваются физические диски.
То есть «квант» провизионинга, то есть минимального приращения при росте равен 256MB?
Это, вообще говоря, дофига. Так, Thin provisioned VMDK в VMware имеет сегмент от мегабайта до 8MB, а NetApp — и вовсе 4KB.
> Например, согласно данным 3Par, 95% операций ввода/вывода совершаются с 3% данных, хранящихся на дисковом массиве.
Это так, но беда в том, что эти 3% все время разные, а не одни и те же 3% все время. :)
То есть, в данном случае, для обеспечения эффекта от stageing придется все время перемещать данные, что, в результате, сводит на нет большую часть эффекта.
> Второй особенностью аппаратной части массивов 3Par является использование в каждом контроллере микросхемы ASIC, которая на уровне железа реализует дополнительную полезную функциональность.
Практика жизни показывает, что несмотря на очевидные преимущества реализации функционала «в кремнии» (быстродействие), она имеет и значительные недостатки, например трудности в модернизации и добавлении функционала. Пример — недалеко ходить, HP EVA (а также BlueArc, например). Да и сам 3Par уже тоже начинает это чувствовать на себе (достаточно посмотреть отражение этого процесса в виде позиции 3Par в гартнеровских квадрантах).
Плюсы софтверности тоже очевидны. NetApp, почти полностью и абсолютно «софтверное» решение, реализовал thin provisioning, если я не ошибаюсь, на следующий год после 3Par. Что обошлось ему значительно дешевле, как я понимаю, за то же самое.
И в заключение просьба: подробнее про thin reclamation расскажите. Каким образом, что за механизмы, и так далее. Насколько я понимаю тему, нужен «агент» на стороне хост-OS и приложения?
Несколько реплик:
> в основании структуры лежат 256-мегабайтные сегменты, на которые разбиваются физические диски.
То есть «квант» провизионинга, то есть минимального приращения при росте равен 256MB?
Это, вообще говоря, дофига. Так, Thin provisioned VMDK в VMware имеет сегмент от мегабайта до 8MB, а NetApp — и вовсе 4KB.
> Например, согласно данным 3Par, 95% операций ввода/вывода совершаются с 3% данных, хранящихся на дисковом массиве.
Это так, но беда в том, что эти 3% все время разные, а не одни и те же 3% все время. :)
То есть, в данном случае, для обеспечения эффекта от stageing придется все время перемещать данные, что, в результате, сводит на нет большую часть эффекта.
> Второй особенностью аппаратной части массивов 3Par является использование в каждом контроллере микросхемы ASIC, которая на уровне железа реализует дополнительную полезную функциональность.
Практика жизни показывает, что несмотря на очевидные преимущества реализации функционала «в кремнии» (быстродействие), она имеет и значительные недостатки, например трудности в модернизации и добавлении функционала. Пример — недалеко ходить, HP EVA (а также BlueArc, например). Да и сам 3Par уже тоже начинает это чувствовать на себе (достаточно посмотреть отражение этого процесса в виде позиции 3Par в гартнеровских квадрантах).
Плюсы софтверности тоже очевидны. NetApp, почти полностью и абсолютно «софтверное» решение, реализовал thin provisioning, если я не ошибаюсь, на следующий год после 3Par. Что обошлось ему значительно дешевле, как я понимаю, за то же самое.
И в заключение просьба: подробнее про thin reclamation расскажите. Каким образом, что за механизмы, и так далее. Насколько я понимаю тему, нужен «агент» на стороне хост-OS и приложения?
Коллега track путает страйпинг и размер страницы для Thin provisioning.
>>>http://www.3par.com/SiteObjects/C7A8AB0D9F6C8D9A047B1B3692A1ADDD/tp-ds-10.0.pdf
Fine-grained vs. coarse allocation unit size
3PAR Thin Provisioning uses an allocation unit size of
just 16 KB, so you don’t have to worry about small writes
consuming megabytes or even gigabytes of capacity.
Насчет плюсов софтверности, это да. В 3Паре сочетаются плюсы хардверности в ASIC и софтверности в операционке. Базовая функция ASIC в плане ThP звучит так: не пиши на диски нули. Трудности в модернизации этого функционала минимальные :-Е
Зачем агенты нужны для thin reclamation? не понял!
>>>Это так, но беда в том, что эти 3% все время разные, а не одни и те же 3% все время. :)
Если бы они были все время совсем разные, то эта статистика не имела бы смысла. Так что это, коллега track, демагогия.
BR/VL
>>>http://www.3par.com/SiteObjects/C7A8AB0D9F6C8D9A047B1B3692A1ADDD/tp-ds-10.0.pdf
Fine-grained vs. coarse allocation unit size
3PAR Thin Provisioning uses an allocation unit size of
just 16 KB, so you don’t have to worry about small writes
consuming megabytes or even gigabytes of capacity.
Насчет плюсов софтверности, это да. В 3Паре сочетаются плюсы хардверности в ASIC и софтверности в операционке. Базовая функция ASIC в плане ThP звучит так: не пиши на диски нули. Трудности в модернизации этого функционала минимальные :-Е
Зачем агенты нужны для thin reclamation? не понял!
>>>Это так, но беда в том, что эти 3% все время разные, а не одни и те же 3% все время. :)
Если бы они были все время совсем разные, то эта статистика не имела бы смысла. Так что это, коллега track, демагогия.
BR/VL
> Коллега track путает страйпинг и размер страницы для Thin provisioning.
Это не я путаю, это так изложено выше в тексте Tigger.
> Зачем агенты нужны для thin reclamation? не понял!
Затем, что с точки зрения системы хранения нет способа отличить блок с данными но «давно не читавшийся/изменявшийся» от блока стертого, так как отличаются они только отметкой на уровне «таблицы размещения файлов» файловой системы. Для системы хранения все блоки делятся только на «потроганные» и «непотроганные» (touch).
Следовательно, сколько ни стирай данные на thin-provisioned томе, он всегда будет только расти. Именно для предотвращения этого и придумана thin reclamation. Но, повторюсь, без «агента» на уровне файловой системы узнать о том, что данный блок стерт, а не просто не изменяется, невозможно.
> Так что это, коллега track, демагогия.
Объявлять любые неудобные вопросы оппонента демагогией это очень удобный способ уйти от неудобного вопроса. :-|
Это не я путаю, это так изложено выше в тексте Tigger.
> Зачем агенты нужны для thin reclamation? не понял!
Затем, что с точки зрения системы хранения нет способа отличить блок с данными но «давно не читавшийся/изменявшийся» от блока стертого, так как отличаются они только отметкой на уровне «таблицы размещения файлов» файловой системы. Для системы хранения все блоки делятся только на «потроганные» и «непотроганные» (touch).
Следовательно, сколько ни стирай данные на thin-provisioned томе, он всегда будет только расти. Именно для предотвращения этого и придумана thin reclamation. Но, повторюсь, без «агента» на уровне файловой системы узнать о том, что данный блок стерт, а не просто не изменяется, невозможно.
> Так что это, коллега track, демагогия.
Объявлять любые неудобные вопросы оппонента демагогией это очень удобный способ уйти от неудобного вопроса. :-|
>>>Система виртуальных доменов позволяет нарезать дисковый массив на изолированные между собой на логическом уровне виртуальные частные массивы.
при этом как разделяются между доменами ресурсы контроллеров?
Выделение отдельных дисков под отдельные задачи/приложения реализуется практически на всех массивах на уровне выделения отдельных дисковых групп/пулов/агрегатов/рэйд групп. При этом встаёт вопрос QoS для контроллеров для разных задач. Как это решается?
при этом как разделяются между доменами ресурсы контроллеров?
Выделение отдельных дисков под отдельные задачи/приложения реализуется практически на всех массивах на уровне выделения отдельных дисковых групп/пулов/агрегатов/рэйд групп. При этом встаёт вопрос QoS для контроллеров для разных задач. Как это решается?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура 3Par InServ