Comments 48
А внедрять дедупликацию в MSA\EVA\XP они не собираются?
Это технически очень непросто сделать.
Вернее делать-то может и можно, но результат вам не понравится. Скорость упадет весьма значительно.
Вернее делать-то может и можно, но результат вам не понравится. Скорость упадет весьма значительно.
А вот вопрос — зачем в дисковых массивах дедупликация? Жабу радовать? В ущер производительности?
Единственно, где это хоть как то может быть оправдано — при удаленной репликации и паршивом канале :)
Единственно, где это хоть как то может быть оправдано — при удаленной репликации и паршивом канале :)
Если у вас очень много одинаковых вм (как у меня), то это существенно улучшит и производительность(файлы вм будут в кэше), и занимаемое место на СХД.
В случае наличия ущеба производительности — безусловно так.
Но не всякая дедупликация ведет к падению производительности.
Что касается задач для дедупликации на primary, то классическая — виртуализация.
Представьте себе сервер ESX (ну или подставь любой любимый гипервизор), а на нем 20 одинаковых VM под Windows(RHEL/SLES) (все, конечно же идентичные по сервиспакам и патчам, как это и бывает).
Каждый «диск С:» такой VM занимает свои 2GB, при том, что содержимое их отличается на полпроцента.
Впрочем, для HP и данного треа это оффтопик.
Но не всякая дедупликация ведет к падению производительности.
Что касается задач для дедупликации на primary, то классическая — виртуализация.
Представьте себе сервер ESX (ну или подставь любой любимый гипервизор), а на нем 20 одинаковых VM под Windows(RHEL/SLES) (все, конечно же идентичные по сервиспакам и патчам, как это и бывает).
Каждый «диск С:» такой VM занимает свои 2GB, при том, что содержимое их отличается на полпроцента.
Впрочем, для HP и данного треа это оффтопик.
а разве всякие виртуоззо не делают так?
да, согласен, это совершенно другой уровень виртуализации, но тем не менее. если у вас 20 одинаковых машин, возможно стоит посмотреть в сторону таких решений?
да, согласен, это совершенно другой уровень виртуализации, но тем не менее. если у вас 20 одинаковых машин, возможно стоит посмотреть в сторону таких решений?
RHEL\SLES да в принципе любой Linux\BSD позволят сделать общий и единый /usr для всех гостей\хостов на уровне ОС
Хорошо, тогда чуть более сложный вариант: половина из этих 20 полностью идентичны, а вторая половина — нет, некоторые файлы не совпадают (допустим нужны какие-то определенные версии), причем разные и с разными, в этих /usr.
Что делать?
А дедупликация снова разберется, притом сама.
Что делать?
А дедупликация снова разберется, притом сама.
Вот как раз для такой задачи та же Virtuozzo и гораздо удобнее благодаря vzfs, так как экономит не только место, но и ОЗУ.
Как это работает(в сильно упрощенном виде): на NadswareNode ставится темплейт, после установки этого темплейта в любой контейнер на HardwareNode, файлы в контейнере представляют из себя аналог символических ссылок в UNIX/POSIX. Если какой-то файл меняется, то «символическая ссылка» vzfs «разрывается» и файл создается в «приватной» области контейнера.
Так как ядро на все контейнеры одно, то, фактически, мы получаем одно приложение, запущенное в, например, 80 экземплярах, и которое занимает в ОЗУ пусть и не в 80 раз меньше места (так как данные приложений отличаются), но все же, может быть, и в 60:
например, облачный хостинг по запуску каких-нибудь прожордивых до оперативки и написанных на Java приложений может получить очень хорошую экономию по занятому ОЗУ и занятой памяти.
Кроме этих плюсов, у Virtuozzo так же есть плюс в меньшем объеме необходимых инвестиций в оборудование: для LiveMigration Linux-контейнеров не нужен общий сторадж, оно может осуществляться между локальными дисками серверов.
Помимо Virtuozzo интересные технологии для решения этой же задачи имеют и свободные и бесплатные контейнеры LXC (к сожалению, пока сыроватые для production использования)
Внимание, я не отрицаю плюсов СХД и гипервизоров: гипервизоры могут заменить контейнеры, а вот контейнеры гипервизоры заменить не смогут, но применять на задаче массового сервиса (а, значит, по-возможности максимально дешевого) дорогущие СХД и гипервизорную инфраструктуру, имхо, может быть оправданно только с целью хорошего такого попила $ с поставщиком железа (так же хотела бы отметить, что против и корупции и попила $, что бы на эту тему не началась дискуссия)
Как это работает(в сильно упрощенном виде): на NadswareNode ставится темплейт, после установки этого темплейта в любой контейнер на HardwareNode, файлы в контейнере представляют из себя аналог символических ссылок в UNIX/POSIX. Если какой-то файл меняется, то «символическая ссылка» vzfs «разрывается» и файл создается в «приватной» области контейнера.
Так как ядро на все контейнеры одно, то, фактически, мы получаем одно приложение, запущенное в, например, 80 экземплярах, и которое занимает в ОЗУ пусть и не в 80 раз меньше места (так как данные приложений отличаются), но все же, может быть, и в 60:
например, облачный хостинг по запуску каких-нибудь прожордивых до оперативки и написанных на Java приложений может получить очень хорошую экономию по занятому ОЗУ и занятой памяти.
Кроме этих плюсов, у Virtuozzo так же есть плюс в меньшем объеме необходимых инвестиций в оборудование: для LiveMigration Linux-контейнеров не нужен общий сторадж, оно может осуществляться между локальными дисками серверов.
Помимо Virtuozzo интересные технологии для решения этой же задачи имеют и свободные и бесплатные контейнеры LXC (к сожалению, пока сыроватые для production использования)
Внимание, я не отрицаю плюсов СХД и гипервизоров: гипервизоры могут заменить контейнеры, а вот контейнеры гипервизоры заменить не смогут, но применять на задаче массового сервиса (а, значит, по-возможности максимально дешевого) дорогущие СХД и гипервизорную инфраструктуру, имхо, может быть оправданно только с целью хорошего такого попила $ с поставщиком железа (так же хотела бы отметить, что против и корупции и попила $, что бы на эту тему не началась дискуссия)
Описание в виде 6 абзацев текста, предваренныое словами «сильно упрощенно», по-моему, очень показателен ;D
При чем здесь вообще OЗУ? В топике речь про диски идет.
По моему вы рассказываете про что-то свое, не относящееся к данной теме.
По моему вы рассказываете про что-то свое, не относящееся к данной теме.
Не понимаю, зачем _этот_ человек вообще ко мне обращается, хотя знает, что он в игноре.
В любой теме, где бы я не появилась, он не упускает случая поиздеваться. На мой взгляд, это сексизм. В связи с хроническим неадекватом он в тотальном игноре.
Данный топик написан исключительно для хабраюзеров, но не для romx.
В любой теме, где бы я не появилась, он не упускает случая поиздеваться. На мой взгляд, это сексизм. В связи с хроническим неадекватом он в тотальном игноре.
Данный топик написан исключительно для хабраюзеров, но не для romx.
Извиняюсь, показалось, что второй пост написан так же romx. Речь именно о дедубликации.
Мне кажется, что пример массовых и однотипных сервисов, который бы потребовал СХД с дедубликацией, неудачен.
Кроме того, мысль о Virtuozzo в этой теме была высказана в первый раз совсем не мной.
Я лишь ответила на Ваш топик, о том, что есть более лучшее, и эффективное решение для именно этой, конкретной задачи (массовый сервис однотипных виртуалок)
Мне кажется, что пример массовых и однотипных сервисов, который бы потребовал СХД с дедубликацией, неудачен.
Кроме того, мысль о Virtuozzo в этой теме была высказана в первый раз совсем не мной.
Я лишь ответила на Ваш топик, о том, что есть более лучшее, и эффективное решение для именно этой, конкретной задачи (массовый сервис однотипных виртуалок)
Поясню мысль еще раз, возможно, Вы ее не поняли, так как написала немного невнятно.
За некоторую невнятность извиняюсь.
В Virtuozzo Containers есть возможность, с помощью Application templates, иметь в границах физического сервера, массовые приложения, проинсталлированные в одном экземпляре(это экономит место, как и дедубликация), при этом изменяя только те файлы приложения, которые можно изменить, без ущерба для экономии места.
Как бонус, Вы получаете так же существенную экономию ОЗУ, и возможность вообще не использовать СХД(которая обычно практически must have, если у Вас сервисы виртуализированы, конечно, прямого отношения именно к дедубликации это не имеет, но имеет к Вашему примеру однотипных виртуалок), что для Вашего примера (массового сервиса какого-нибудь application) может быть достаточно Важно, так как любой массовый сервис ориентируется на снижение цены за счет массовости(что бы сервис был именно массовым).
За некоторую невнятность извиняюсь.
В Virtuozzo Containers есть возможность, с помощью Application templates, иметь в границах физического сервера, массовые приложения, проинсталлированные в одном экземпляре(это экономит место, как и дедубликация), при этом изменяя только те файлы приложения, которые можно изменить, без ущерба для экономии места.
Как бонус, Вы получаете так же существенную экономию ОЗУ, и возможность вообще не использовать СХД(которая обычно практически must have, если у Вас сервисы виртуализированы, конечно, прямого отношения именно к дедубликации это не имеет, но имеет к Вашему примеру однотипных виртуалок), что для Вашего примера (массового сервиса какого-нибудь application) может быть достаточно Важно, так как любой массовый сервис ориентируется на снижение цены за счет массовости(что бы сервис был именно массовым).
все хорошо, но виртуозо — это очень нишевое решение, и только для linux систем.
дедупликация на уровне фс позволяет работать с любыми гипервизорами и любыми виртуалками.
плюс данное решение нацелено на первый уровень баккапа, а вовсе не как общее хранилище.
дедупликация на уровне фс позволяет работать с любыми гипервизорами и любыми виртуалками.
плюс данное решение нацелено на первый уровень баккапа, а вовсе не как общее хранилище.
>все хорошо, но виртуозо — это очень нишевое решение, и только для linux
>систем.
На самом деле, доступно и для Windows
А что касается нишевости: массовые и однотипные сервисы и есть нечто весьма нишевое, вот именно в этой области PVC и более удобен, чем дедубликация. Это и есть ниша PVC, под которую он «заточен».
>дедупликация на уровне фс позволяет работать с любыми гипервизорами и >любыми виртуалками.
Я лишь ответила на пример про массовые сервисы: имхо, использование для массовых сервисов виртуализации (а не контейнеров, не только виртуозы) вообще достаточно большой оверсел и оверхед, гипервизорная виртуализация в данном случае, не очень правильный выбор (имхо).
В разнородном же корпоративном окружении гипервизоры, конечно (имхо) гораздо более удобны и предпочтительны.
>плюс данное решение нацелено на первый уровень баккапа, а вовсе не как >общее хранилище.
Бэкап EZtemplat'а тоже весит гораздо меньше, чем контейнер с суммой места всех установленных в него Application'ов.
>систем.
На самом деле, доступно и для Windows
А что касается нишевости: массовые и однотипные сервисы и есть нечто весьма нишевое, вот именно в этой области PVC и более удобен, чем дедубликация. Это и есть ниша PVC, под которую он «заточен».
>дедупликация на уровне фс позволяет работать с любыми гипервизорами и >любыми виртуалками.
Я лишь ответила на пример про массовые сервисы: имхо, использование для массовых сервисов виртуализации (а не контейнеров, не только виртуозы) вообще достаточно большой оверсел и оверхед, гипервизорная виртуализация в данном случае, не очень правильный выбор (имхо).
В разнородном же корпоративном окружении гипервизоры, конечно (имхо) гораздо более удобны и предпочтительны.
>плюс данное решение нацелено на первый уровень баккапа, а вовсе не как >общее хранилище.
Бэкап EZtemplat'а тоже весит гораздо меньше, чем контейнер с суммой места всех установленных в него Application'ов.
«Бэкап EZtemplat'а тоже весит гораздо меньше,»
Просьба читать как
«Бэкап контейнера с установленными в него темплейтами тоже весит гораздо меньше,»
Просьба читать как
«Бэкап контейнера с установленными в него темплейтами тоже весит гораздо меньше,»
Массовые однотипные сервера — это вовсе не нишево. В каждой мелкой-средней конторе есть десяток виндовых серверов, если мы переводим их в виртуалки — куча места уходит по почти идентичный системный раздел.
Дедупликация в памяти есть уже у многих гипервизоров, а вот дедупликация диска — задача тяжелая и ее нет. За то покупка хранилища с дедупликацией сразу решает этот вопрос независимо от того, что хранится. Правда, на сколько я знаю такое есть только в топовых моделях, ибо ресурсоемко.
Не разделяю оптимизма на счет контейнеров. все же полная виртуализация проще и понятнее с т.з. администраторов и начальников на местах. примеров внедрения (успешных, помогающих экономить железо и упростить администрирование) у меня много. а вот с контейнерами рисковали связываться в основном только хостеры, т.е. там где очень ограниченное число осей и сервисов.
Ну да, я и пишу с т.з. «обычной» фирмы.
Дедупликация в памяти есть уже у многих гипервизоров, а вот дедупликация диска — задача тяжелая и ее нет. За то покупка хранилища с дедупликацией сразу решает этот вопрос независимо от того, что хранится. Правда, на сколько я знаю такое есть только в топовых моделях, ибо ресурсоемко.
Не разделяю оптимизма на счет контейнеров. все же полная виртуализация проще и понятнее с т.з. администраторов и начальников на местах. примеров внедрения (успешных, помогающих экономить железо и упростить администрирование) у меня много. а вот с контейнерами рисковали связываться в основном только хостеры, т.е. там где очень ограниченное число осей и сервисов.
Ну да, я и пишу с т.з. «обычной» фирмы.
>массовые однотипные сервера — это вовсе не нишево. В каждой >мелкой-средней конторе есть десяток виндовых серверов
Под «массовыми» сервисами (не серверами) я имела ввиду под сотню однотипных аппликэйшенов на физический сервер, а физических серверов хотя бы пол-десятка.
>а вот с контейнерами рисковали связываться в основном только >хостеры
Да я с Вами и не спорю, на самом деле, только не только хостеры в обычном понимании, этим как раз часто оправданно продавать VPS на гипервизорах(хотя и контейнерные, как дешевый, быстрый и эффективный вариант, конечно, рулят), если есть SAN инфраструктура, а если и хостинг, то Application'ов.
В общем, имхо, мы спорили о разном :)
Под «массовыми» сервисами (не серверами) я имела ввиду под сотню однотипных аппликэйшенов на физический сервер, а физических серверов хотя бы пол-десятка.
>а вот с контейнерами рисковали связываться в основном только >хостеры
Да я с Вами и не спорю, на самом деле, только не только хостеры в обычном понимании, этим как раз часто оправданно продавать VPS на гипервизорах(хотя и контейнерные, как дешевый, быстрый и эффективный вариант, конечно, рулят), если есть SAN инфраструктура, а если и хостинг, то Application'ов.
В общем, имхо, мы спорили о разном :)
На primary storage без потерь производительности это умеет делать пока только NetApp.
EMC Symmetrix тоже умеют
Где прочитать?
ненене. Ключевые слова «на primary» и «без потерь производительности». А послать на маркетинговую презентацию на офсайте это не то.
Было бы интересно именно про Symmetrix.
Потому что с дедупликацией есть Data Domain (и кажется Avamar еще), но это бэкапные устройства.
Есть еще компрессия, которая почему-то называется у EMC «дедупликацией» у Celerra, это NAS.
Но вот насчет Symmetrix что-то не могу найти.
Потому что с дедупликацией есть Data Domain (и кажется Avamar еще), но это бэкапные устройства.
Есть еще компрессия, которая почему-то называется у EMC «дедупликацией» у Celerra, это NAS.
Но вот насчет Symmetrix что-то не могу найти.
С учетом того, что у Нетапа нет хайэнда как класс… удачи.
Есть. FAS6000 — это у NetApp highend.
Или что вы называете highend?
Или что вы называете highend?
думаю попозже и начнут со старших моделей… в MSA пока маловато ресурсов для этого… да и не для архивирования её делали.
Прочитал, интересно. Интересно, где заканчиваются ученые и начинаются инженеры?
Спасибо за очередной маркетинг.
обьясните плиз, каким образом ваше решение дедубликации защищается от случая потери блока, на который по индексу ссылаются куча лунов?
обьясните плиз, каким образом ваше решение дедубликации защищается от случая потери блока, на который по индексу ссылаются куча лунов?
UFO just landed and posted this here
хранилища hp всегда растягивают 1 raid на все имеющиеся диски или возможны ситуации с 2-я и более raid?
мой вопрос был про случай, когда мы теряем полностью по какой-то причине первый raid, то если была дедубликация 2-го на первый успешно сдохнет и 2-ой.
мой вопрос был про случай, когда мы теряем полностью по какой-то причине первый raid, то если была дедубликация 2-го на первый успешно сдохнет и 2-ой.
UFO just landed and posted this here
со спасением понятно — дело то совсем в другом. при использовании это вроде бы очень вкусной опции получается можем получить проблемы там, где они совсем никак не ожидались. и казалось бы мелкий алярм с тестовой виртуалкой обернется большим геммороем с боевой БД
Нет, это не так. Так делает массив EVA да и то растягивает на все диски, которые пользователь определяет как группу. Если группы две, то на каждой будут свои raid.
Если мы (в смысле Вы) часто теряете полностью raid1, что то надо менять в консерватории. Ленточки магнитные тоже никто не отменял :)
Если мы (в смысле Вы) часто теряете полностью raid1, что то надо менять в консерватории. Ленточки магнитные тоже никто не отменял :)
А это разве не эквивалентно incremental backup, который на магнитной ленте тоже используется?
ложь? глупость?
>> Кроме того, в ленточных библиотеках используются сменные носители, поэтому полностью заполненный ленточный картридж можно извлечь из библиотеки и отправить в хранилище, а вместо него вставить чистый картридж. Емкость дисковых массивов таким способом масштабировать нельзя…
вообще то ничто совершенно не мешает извлечь диск и вставить новый, только что это определит выбор алгоритма, по которому будет производиться резервное копирование, да и RAID в данном случае не подходит, нужны совсем другие способы избыточного хранения.
>> Кроме того, в ленточных библиотеках используются сменные носители, поэтому полностью заполненный ленточный картридж можно извлечь из библиотеки и отправить в хранилище, а вместо него вставить чистый картридж. Емкость дисковых массивов таким способом масштабировать нельзя…
вообще то ничто совершенно не мешает извлечь диск и вставить новый, только что это определит выбор алгоритма, по которому будет производиться резервное копирование, да и RAID в данном случае не подходит, нужны совсем другие способы избыточного хранения.
Я, все таки предложил в технической дискуссии не приклеивать ярлыки.
Никто Вам не мешает носиться с дисками, извлеченными из массива :) за одним маленьким НО: если это массив начального уровня. Из массива EVA и XP кустарными средствами без потери данных извлечь диск просто не удастся. Ленточные накопители существовали одновременно с перфоркартами, существуют сейчас (хотя их много раз пытались похоронить). Из очевидных плюсов ленты: очень высокая скорость записи (когда привод разогнался и пишет непрерывно) и очень низкая стоимость (при больших объемах и если учитывать еще и стоимость владения). Из минусов — медленность извлечения одиночного файла из конца ленты (но эта задача решается тандемом Виртуальная и Физическая ленточные библиотеки, ну или бэкап-ту-диск).
Единственное, пожалуй соглашусь, что термин «масштабирование» в данном случае неуместен
Знаете ли Вы какие методы используются для надежного хранения записи на ленте (имеется в виду, естественно, Ultrium). Очень советую познакомиться.
И последнее: общепризнанной методикой защиты данных в мире НА НАСТОЯЩИЙ МОМЕНТ является резервное копирование на ленты. Для корпоративных Заказчиков, разумеется.
Никто Вам не мешает носиться с дисками, извлеченными из массива :) за одним маленьким НО: если это массив начального уровня. Из массива EVA и XP кустарными средствами без потери данных извлечь диск просто не удастся. Ленточные накопители существовали одновременно с перфоркартами, существуют сейчас (хотя их много раз пытались похоронить). Из очевидных плюсов ленты: очень высокая скорость записи (когда привод разогнался и пишет непрерывно) и очень низкая стоимость (при больших объемах и если учитывать еще и стоимость владения). Из минусов — медленность извлечения одиночного файла из конца ленты (но эта задача решается тандемом Виртуальная и Физическая ленточные библиотеки, ну или бэкап-ту-диск).
Единственное, пожалуй соглашусь, что термин «масштабирование» в данном случае неуместен
Знаете ли Вы какие методы используются для надежного хранения записи на ленте (имеется в виду, естественно, Ultrium). Очень советую познакомиться.
И последнее: общепризнанной методикой защиты данных в мире НА НАСТОЯЩИЙ МОМЕНТ является резервное копирование на ленты. Для корпоративных Заказчиков, разумеется.
Sign up to leave a comment.
Ученые HP Labs совершенствуют дедупликацию