8 мифов о дедупликации

    Пришло время рассмотреть все мифы и узнать где правда в вопросах дедупликации для массивов данных.



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

    Не важно, являетесь ли вы администратором системы хранения уровня tier-1, архивного хранилища или all-flash гибридных систем хранения, вам будет интересно пройтись по мифам и легендам дедупликации, чтобы избежать досадных ошибок при проектировании или работе с вашими системами хранения.

    Коэффициент сокращения данных: чудес не бывает


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

    Дедупликация — это автоматический процесс, существующий на многих массивах известных производителей, но потенциальный коэффициент, который вы можете получить, отличается у массивов разного типа. В результате, например, если вам будет нужен массив на 100ТБ, а вы будете считать коэффициент 10:1, то и приобретете хранилище под 10ТБ, или, скажем, если вы будете оценивать коэффициент как 2:1, следовательно, приобретете хранилище на 50ТБ – в итоге, эти совершенно разные подходы, приводят к совершенно разной стоимости покупки! Вы должны на практике понять какой коэффициент вы можете получить на ваших продуктивных данных, прежде чем сделать выбор в пользу определенной модели с определенным объемом.

    Строя конфигурации массивов данных под различные задачи оперативного хранения и резервного хранения, часто приходится сталкиваться со сложностями в правильном определении коэффициента дедупликации. Если вам интересны тонкости архитектурного дизайна массивов под дедупликацию, эта дискуссия для вас.

    Как минимум, понимание на базовом уровне 8 мифов, приведенных далее, позволит вам осознанно понять дедупликацию и оценить ее коэффициент для ваших данных.

    Миф1. Больший коэффициент дедупликации дает больше преимуществ для хранения данных


    Верно ли утверждение, что если один вендор предлагает коэффициент дедупликации 50:1 это в пять раз лучше альтернативного предложения 10:1? Нужно проверять и сравнивать совокупную стоимость влдения! Дедупликация позволяет сократить требования к ресурсам, но какова потенциальная экономия объема? 10:1 позволяет уменьшить размер хранимых данных (reduction ratio) на 90%, в то время как коэффициент в 50:1 увеличивает этот показатель на 8% и дает 98% reduction ratio (см. график ниже). Но это только 8% разницы…

    В целом, чем выше коэффициент дедупликации, тем меньше преимуществ по уменьшению объема данных, согласно закону убывающей доходности. Объяснение смысла закона убывающей доходности может быть таким: дополнительно применяемые затраты одного фактора (например, коэффициента дедупликации) сочетаются с неизменным количеством другого фактора (например, объема данных). Следовательно, новые дополнительные затраты на текущем объеме дают всё меньшую экономию ресурсов.

    К примеру, у вас есть офис, в котором работают клерки. Со временем, если увеличивать количество клерков, не увеличивая размер помещения, они будут мешаться под ногами друг у друга и возможно затраты будут превышать доходы.


    Рис. 1 Рост коэффициента дедупликации и сокращение объемов хранения

    Миф2. Есть четкое определение термина «дедупликация»


    Дедупликация позволяет сократить объем хранимых данных, удаляя повторяющиеся последовательности данных из пула. Дедупликация может быть на файловом уровне, блочном уровне или на уровне приложения или контента. Большая часть продуктов сочетают дедупликацию с компрессией, чтобы еще сильнее сократить объем хранимых данных. В то время, как некоторые производители не разделяют эти термины, некоторые разделяют их и вводят такие термины, как «уплотнение» (compaction), что, по сути, является просто другим названием «дедупликации плюс сжатие». К сожалению, не существует единственного определения дедупликации. В обывательском уровне вам будет важно, как вы сможете сэкономить на дисковых ресурсах вашей системы хранения и резервного копирования, применяя дедупликацию. Ниже мы раскроем эту тему.

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

    Для систем хранения оперативных данных в массиве 3PAR разработан целый комплекс утилит и механизмов, позволяющий сократить объем данных на продуктивном массиве.
    Этот комплекс носит название HPE 3PAR Thin Technologies и состоит из нескольких механизмов:

    • Thin Provisioning – наиболее эффективно реализованная в системах хранения 3PAR, т.к. применяется виртуализация дискового пространства и массив используют свою внутреннюю карту хранимых блоков, при высвобождении ресурсов массиву не нужно проводить ревизию (garbage collection), высвободившиеся блоки сразу готовы к дальнейшему использованию… Позволяет выделять логическому тому ровно столько объема, сколько он требует, но на массиве занять всего лишь столько, сколько на этот том физически записано.

    • Thin Conversion — технология, позволяющая переводить в реальном времени тома со старых массивов данных HPE (3PAR, EVA), EMC, Hitachi и других производителей в «тонкие тома» (которые используют Thin Provisioning) на массиве 3PAR с сокращением объема тома на целевом устройстве.

    • Thin Persistence и Thin Copy Reclamation — технология, позволяющая массиву 3PAR на очень низком гранулярном уровне понимать работу всех популярных файловых систем и гипервизоров и в случае удаления файлов (освобождения физического объема) переводить соответствующие блоки в пул свободных ресурсов.

    • Thin Deduplication — технология позволяющая использовать дедупликацию на продуктивном массиве в реальном времени, без существенной просадки производительности.

    Все три технологии доступны бесплатно и без ограничений по времени или объему для любой системы хранения 3PAR, в том числе, установленных у наших заказчиков, подробнее об этих технологиях.


    Рис. 2 Технологии Thin в массивах 3PAR

    Миф3. Коэффициенты дедупликации на основном массиве такие же, как и на массиве с резервными копиями.


    Разработчики систем хранения данных используют различные алгоритмы дедупликации. Некоторые из них требуют больших ресурсов CPU и сложнее, чем остальные, следовательно, не должен удивлять тот факт, что коэффициент дедупликации варьируется достаточно сильно.

    Однако, самый большой фактор, влияющий на то, какой коэффициент дедупликации вы получите — как много у вас повторяющихся данных. По этой причине системы резервного копирования, содержащие несколько копий одних и тех же данных (дневные, недельные, месячные, квартальные, годичные) имеют такой высокий коэффициент дедупликации. В то время как оперативные системы хранения имеют практически уникальный набор данных, что практически всегда дает невысокий коэффициент дедупликации. В случае, если вы храните несколько копий оперативных данных на продуктивном массиве (например, в виде клонов) — это увеличивает коэффициент дедупликации, т.к. применяются механизмы сокращения места хранения.

    Поэтому для оперативных массивов хранения данных иметь коэффициент 5:1 также замечательно, как иметь коэффициент 30:1 или 40:1 для систем резервного копирования, поскольку коэффициент этот зависит от того, сколько копий продуктивных данных хранится на таких массивах.

    Если рассматривать продукты компании HPE, то в массивах для оперативного хранения HPE 3PAR поиск повторяющихся последовательностей (например, при инициализации виртуальных машин или создании снэпшотов) проходит «на лету» на специальной микросхеме ASIC, установленной в каждом контроллере массива. Этот подход позволяет разгрузить центральные процессоры массива для других, более важных, задач и дает возможность включить дедупликацию для всех типов данных, не боясь, что массив «просядет» под нагрузкой. Подробнее про дедупликацию на массиве 3PAR можно прочитать.


    Рис.3 Дедупликация в массивах 3PAR выполняется на выделенной микросхеме ASIC

    В портфеле HPE также есть аппаратные комплексы для резервного копирования данных с онлайн дедупликацией на уровне блоков переменной длины — HPE StoreOnce. Варианты систем охватывают полный спектр заказчиков от начального до корпоративного уровня:


    Рис. 4 Портфель систем резервного копирования HPE StoreOnce

    Про преимущества систем резервного копирования StoreOnce можно почитать в других статьях.
    Для заказчиков может быть интересно, что связка HPE 3PAR и StoreOnce позволяет упростить и ускорить процесс переноса данных с продуктивного массива на систему резервного копирования без использования ПО резервного копирования или выделенного сервера бэкапа. Такая связка получила название HPE StoreOnce RMC и подробнее о ней также можно почитать в нашей статье.

    Миф4. Все данные одинаковы


    Здесь не должно быть никаких сомнений- все данные разные. Даже данные одного и того же приложения в различных условиях будут иметь разные коэффициенты дедупликации на одном и том же массиве. Коэффициент дедупликации для конкретных данных зависит от разных факторов:

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

    • Степень изменяемости данных — чем выше объем дневных изменений данных на блочном или файловом уровне, тем ниже коэффициент дедупликации. Это особенно актуально для систем резервного копирования.

    • Срок хранения — чем больше копий данных вы имеете, тем выше коэффициент дедупликации.

    • Политика резервного копирования — политика создания дневных полных копий, в противовес политике с инкрементными или дифференциальными бэкапами, даст больший коэффициент дедупликации (см. исследование ниже).

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


    Рис. 5 Оценка коэффициента дедупликации в зависимости от типов данных и политики резервного копирования

    Миф5. Группировка несвязных типов данных повышает уровень дедупликации


    В теории, вы можете смешивать совершенно разные типы данных в общем пуле хранения для дедупликации. Может возникнуть ощущение, что вы имеете очень большой набор уникальных данных и, следовательно, вероятность нахождения в этом пуле уже записанных ранее блоков или объектов будет велика. На практике же этот подход не работает между несвязанными типами данных, например, между БД и Exchange, поскольку форматы данных разные, даже если хранится один и тот же набор данных. Такой, все время растущий пул, становится более сложным и требует больше времени для поиска повторяющихся последовательностей. Лучшей практикой является разделение пулов по типу данных.

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


    Рис.6 Зависимость коэффициента дедупликации от количества виртуальных машин в пуле и размеров блока данных.

    Миф6. Ваше первое резервное копирование покажет вам ожидаемый коэффициент дедупликации.


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

    График ниже показывает очень типичную кривую коэффициента дедупликации. Приложение, в этом графике — БД SAP HANA, но большинство приложений показывает схожую кривую. Ваше первое резервное копирование показывает определенную дедупликацию, но большая экономия достигается благодаря сжатию данных. Как только вы начинаете держать в пуле больше копий данных — коэффициент дедупликации пула начинает расти (голубая линия). Коэффициент индивидуального бэкапа взмывает вверх уже после создания второй копии (орнжевая линия), т.к. на блочном уровне первый и второй бэкап очень похожи.


    Рис. 7 График роста коэффициента дедупликации при увеличении количества резервных копий (подробнее в документе).

    Миф7. Вы не можете увеличить уровень дедупликации


    Наивно рассуждать, что нет возможности искусственно увеличить уровень дедупликации. Другой вопрос — зачем? Если показать маркетинговые цифры — это одно, если необходимо создать эффективную схему резервного копирования — это другое. Если цель — иметь синтетический наивысший коэффициент дедупликации, то необходимо просто хранить больше как можно больше копий одних и тех же данных. Конечно, это увеличит объем хранимых данных, но ваш коэффициент дедупликации взмоет до небес.

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

    Миф8. Нет возможности заранее спрогнозировать коэффициент дедупликации


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

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

    Но наиболее точный прогноз по коэффициенту дедупликации получается в ходе проведения испытаний на реальных данных.


    Рис. 8 Изменение коэффициента дедупликации и объема занимаемых данных в зависимости от политики резервного копирования на данных конкретного заказчика

    У компании HPE есть набор утилит и сайзеров, позволяющий спрогнозировать (с неким допущением) тот объем систем хранения, который необходим заказчикам.

    1. Для оперативного хранилища данных есть бесплатная программа оценки текущей утилизации массива и оценки экономии места, в случае перехода на 3PAR.

    2. Для оценки утилизации ресурсов на оперативном массиве и построения прогноза по росту объема данных на уже установленных системах, при условии разрешения отправки массивом информации о его состоянии в службу технической поддержки HPE: www.storefrontremote.com

    3. Аналогичная программа по оценке утилизации систем резервного копирования.

    Также есть возможность оценить предполагаемый объем, который мы получим после включения на системе 3PAR дедупликации в режиме симулятора, для этого необходимо на 3PAR запустить команду оценки, выполняемую в онлайн режиме, прозрачно для хоста:

    checkvv -dedup_dryrun {Имена виртуальных томов}

    И получить предварительную оценку:



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

    Следует отметить, что современный рост объемов SSD и снижения стоимости хранения на 1ГБ на flash накопителях (а стоимость уже соответствует $1.5 за ГБ) отодвигают вопросы, связанные с эффективностью дедупликации на второй план для оперативного хранилища, но становятся все более актуальными для систем резервного копирования.

    К слову, есть альтернативное видение будущего (без дедупликации): Викибон считает, что устранение копий одних и тех же данных эффективнее, чем рост коэффициенотв дедупликации и компрессии (см. по ссылке в середине отчета), но такой подход требует кардинального внедрения целого комплекса технических мер, изменения всей инфраструктуры, правил одновременной работы приложений (процессинг, аналитика) с данными так, чтобы они не снижали производительность (при внедрении хороших средств работы с SLA) и надежность.

    И, самое главное, если все это внедрить во всей экосистеме — и разработчикам ПО, и вендорам, и CIO, то через несколько лет экономия от этого будет больше, чем от дедупликации.

    Какая школа мысли победит – покажет время.

    Использованы материалы
    Hewlett Packard Enterprise
    101,37
    Компания
    Поделиться публикацией

    Комментарии 23

      –1
      [Сжатие] 10:1 позволяет уменьшить размер хранимых данных (reduction ratio) на 90%, в то время как коэффициент в 50:1 увеличивает этот показатель на 8% и дает 98% reduction ratio (см. график ниже). Но это только 8% разницы…

      Вот бы вам зарплату платили по таким формулам!
      Курс рубля к доллару 60:1 дает reduction rate 98.3%, но мы вам пересчитали зарплату по курсу 6000 рублей за доллар, который увеличивает reduction rate до 99.98%.
      Обратите внимание, это даже больше на целых 1.68%!
      Вот держите ваши 30 долларов.

        0
        Про зарплату — спасибо)
        Ссылка на разъяснение percent increase and decrease: http://www.mathgoodies.com/lessons/percent/change.html
        Math is fun)
          0

          Вроде бы с пропорциями у меня всегда все ОК было. Посмотрел вашу ссылку и понял, что в этом мире пока ничего не изменилось. Имеем 100Tb исходных данных. При коэффициенте дедупликации 10:1 получаем соотношение 10/1=100/X, т.е X=100*1:10=10Tb хранимых данных. Берем коэффициент дедупликации 50:1 и получаем соотношение 50/1=100/X, т.е. X=100*1/50=2Tb хранимых данных. Итого ровно в 5 раз меньше требуется пространства для данных на оборудовании "второго" вендора по сравнению с "первым". А дальше вся ваша "магия" чисел сводится к тому, что мы будем считать за 100%.


          Клиент платит за реальный дисковый объем. Т.е. нужно купить или 10Tb дискового пространства одного вендора, или 2Tb другого вендора (допустим при примерно равной стоимости "за Tb"). Считаем экономию денег заказчика, ваш percent decrease = (10 — 2) / 10 = 0,8 = 80%. Т.е. взяв оборудование "второго" вендора с коэфициентом дедупликации 50:1 мы "внезапно" получаем снижение в 5 раз требований к реальному дисковому пространству и экономию денежных средств заказчика на 80%.


          Ваше утверждение о 8% так же легко подтвердить математически, приняв за 100% размер исходных данных, которые нужно хранить, те. те же 100Tb. Для 10:1 получаем percent decrease = (100 — 10) / 100 = 0.9 = 90%. Для 50:1 получаем decrease = (100 — 2) / 100 = 0.98 = 98%.


          Вот только смахивает это больше "статистику", которая известно в каком месте стоит по шкале лжи :). Ну и отношение вызывает соответствующее к тем организациям, которые пытаются при ее помощи облопошить "простых и доверчивых".

        0
        Как с сохранностью данных? Если пострадает несколько килобайт, а то и мегабайты обычных данных, вред будет зачастую не самым большим, пострадают только поврежденные участки нескольких файлов. А что будет с данными подвергшимися дедупликации?
          0
          Нужно проверять хэш суммы записанных данных и того, что было передано.
          В 3PAR, например, осуществляется постоянная проверка целостности данных по нескольким направлениям (persistent checksum):
          • CRC/parity checks on all internal CPU and serial buses
          • Control cache ECC checks
          • Data cache ECC checks
          • PCIe I2C bus CRC/parity checks
          • HPE 3PAR ASIC connection CRC/parity checks
          • Protocol (Fibre Channel/iSCSI/FCoE) CRC checks at the frame level (hardware accelerated via the HPE 3PAR ASICs)
          • Disk devices CRC checks at the block level, occurring once the data has landed and throughout the lifecycle of the data once it’s stored to disk
          Подробнее https://www.hpe.com/h20195/v2/getpdf.aspx/4aa3-3516enw.pdf
            0
            Данные повредились, скажем скачок по питанию + последующее выключение ИБП (редко, но бывают в жизни подобные случаи и ИБП не всегда помогает) они как-то восстанавливаются или только резервная копия?
              0
              Если приложение подтвердило транзакцию, а массив не успел записать (что в практически невозможно) или записал с ошибкой в силу помех в канале передачи (это уже вполне реально), то в этом случае восстанавливаться из резервной копии. Но приложение всегда ждет пока массив на «том конце» сообщит ок, после этого приложение подтверждает запись.
                0
                Опять же, в силу того, что есть помехи в канале передачи данных — спасает механизм persistent checksum — массив 3PAR не подтвердит запись, если отправленные хостом данные будут отличаться от пришедших на контроллеры массива.
                  0
                  Я беру хуже ситуацию. Описывалась когда-то, всплеск напряжения ИБП пропустили, БП справились, но ИБП тут же вырубились, на диске возникла ошибка, уже на записанном месте к примеру. Какие есть механизмы восстановления такой информации? Не во время записи, а из-за вины внешних фаткоров.
                    0
                    К примеру, у конкурентов довольно давно используется так называемая NVRAM, которая энергозависима и питается от обычного мини аккумулятора. Черене nvram проходит вся запись на диски. В случае отключения питания все данные на дисках валидны, потом при включение питания остатки скидываются на диск и все данные консистентны.
                      0
                      Это опять контроль во время записи. Начнем с другого края. На винчестере появилась серия бедов (не нужно писать про самоконтроль, все равно бывает), в бедах и данные нужные для дедупликации. Какие механизмы восстановления имеются?
                        0
                        Рэйд же.
                          0
                          Вот с рейда (самый простой рейд зеркалом), 20 минут назад это было.
                          Запись 2 из 3: Логические кластеры [0x4857bc, 0x4857c0) принадлежат как файлу…
                          Запись 3 из 3: Неиспользуемые метаданные файла, помеченные как используемые… обнаружено непредвиденное повреждение…

                          И таких записей с десяток за два дня образовалось по неведомой причине. Поэтому и интересует есть ли механизмы восстановления при повреждении данных необходимых для дедупликации данных? Или при использовании дедупликации с данными можно попрощаться в такой ситуации?
                          Сейчас пытаюсь понять что вызывает такие проблемы.
                        0
                        Привет!
                        По-моему, вы смешиваете два сценария — ошибку записи в результате помех в канале и нарушение целостности данных из-за исчезновения питания (что-то дестейджилось на диск, что-то — нет). Защиту кэш-памяти сейчас обеспечивают все производители, не только конкуренты :)
              0
              В разделе «У компании HPE есть набор утилит и сайзеров» первая и третья ссылка битые.
                0
                Спасибо, поправили
                +1

                Хранилище с полезной ёмкостью в 50TiB обходится нам, допустим, в 150 000$.
                Без дедупликации мы сможем 50TiB своих данных. При коэффициенте дедупликации 10:1 мы сможем хранить 500TiB данных. И нам это по-прежнему будет стоить 150К$. При коэффициенте дедупликации 50:1 мы уже будем хранить 2500TiB данных
                В первом случае мы тратим 3000$ за TiB, во втором 300$, а в третьем всего 60$.
                Так к чему говорить про разницу в reduction ratio в 8%? Клиент считает свои деньги и в третьем случае получит возможность хранить в 5 раз больше данных.


                Дедупликация, компрессия, уплотнение. HPE поддерживает что-то кроме дедупликации?
                Кто из вендоров уплотнением называет дедупликацию+компрессию?
                Есть данные для которых хорошо работает дедупликация — виртуальные среды, есть данные для которых лучше сработает компрессия — OLTP DB. И большинство извстных мне вендоров эти понятия разделяют.


                Рис 6. Зависимость коэффициента дедупликации от количества виртуальных машин в пуле и размеров блока данных.
                Немного бесполезный и вводящий в заблуждение график. Судя по тому, что заметный рост коэффициента дедупликации заметен при размере блока 16К и кратных ему, речь идёт про HP 3Par. При этом другие вендоры, использующие другую гранулярность при дедупликации могут получить другие результаты.
                  0
                  Вы правы в том, что всегда нужно считать совокупную стоимость владения, а не только стоимость за ГБ, приведенные примеры показывают, что дедупликация позволяет сэкономить на хранилище, а ниже в статье описываются причины, к этому приводящие.

                  Из практики многих внедрений OLTP DB как раз-таки лучше сжимают сами DB, включенная компрессия на хранилище не дает дополнительных преимуществ, а иногда даже вредит производительности самой БД. Здесь нужно сравнивать на практике.

                    0

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

                  0
                  Коэффициенты дедупликации на основном массиве такие же, как и на массиве с резервными копиями.

                  Если не ошибаюсь, у IBM вся линейка Spectrum Storage использует один движок для компрессии.
                    0
                    Много интересного, но про ряд подводных камней не расскали.
                    Например, про скорость дедупликации.
                    Тестовый стенд DL380p G8 12 ядер 3.5ГГц, 64ГБ, 6 SSD RAID 10, 10GbE с единственной виртуальной машиной, на которой развернута всего 1 база SQL на 1 терабайт.
                    Бэкапим с помощью Symantec Backup Exec 15 на
                    StoreOnce VSA 4 ядра 3ГГц, 16ГБ, 2 SSD RAID 0 (только для теста), 10 GbE.
                    Производительность SSD сервера 4ГБ/с
                    Производительность SSD VSA 1ГБ/с
                    Никакой нагрузки кроме теста бэкапа нет.
                    Надо забэкапить только базу SQL.
                    Как вы думаете, какая будет скорость бэкапа?
                    Упрется в сеть 10 гигабит?
                    Увы нет, скорость бэкапа составила 200-300 килобайт в секунду. База на 1 терабайт будет дедуплицироваться…
                    Ваши предположения?
                    1 час?
                    За ночь?
                    Точно за выходные управится?
                    Я вас сильно удивлю. Бэкап на дедуплицированное хранилище займет около 2 месяцев! У меня вначале вообще показывало один год. Естественно я не стал ожидать.
                    Специфика продукта такова, что дедупликация — однопотоковый процесс (странно в 2016-м году). Что чтобы иметь заявленные скорости, нужно разбивать бэкап на множество одновременных заданий, чтобы загрузить все ядра. Т.е. если вы бэкапите кучу виртуалок и раньше у вас было одно задание, которое их по очереди делает, то сейчас нужно создавать задание на каждую и желательно в нем еще кучу подзаданий (отдельно система, отдельно SQL, отдельно папку 1 в шаре 1, отдельно папку 2 в шаре 1 и т.д. Но вы же знаете как влияет лень и сложности на человека…
                    Выход? Есть.
                    Нужно бэкапить на отдельное хранилище без дедупликации и уже с него не спеша переносить данные на дедуплицированное хранилище.
                    Минусы? Тоже есть.
                    Нужно иметь (и платить) сразу за оба хранилища.
                    Может быть дедупликация не выгодна с финансовой точки зрения?
                    StoreOnce 3540 на 24TB стоит в РФ около 15 000$ (миллион рублей).
                    За такие деньги можно купить
                    — двухсокетную платформу 4U на 36 дисков
                    — процессор 8 ядер
                    — 128 гиг оперативки
                    — 12 дисков по 10 терабайт
                    — сетевушку 10GbE
                    — лицензию на гипервизор и ОС Windows для SBE

                    В итоге за эти же деньги мы имеем гарантию на железо, гарантию записать 100 терабайт бэкапов в RAID 5 в группах от 3 до 6 дисков. Ну и самое главное — база бэкапится за 1-3 часа и реально упирается в сеть 1GbE (поэтому использую 10GbE). Система легко масштабируется еще в 2 раза.
                    Более того, можно использовать дедупликацию самого Symantec и получить как минимум не хуже результаты.

                    Далее самое интересное. Допустим мы все-таки забэкапили. И тут вам надо поднять эту базу.
                    С дедуплицированного хранилища восстановить 1 терабайт займет недели. С моего решения — менее часа.

                    ОК, скажете вы, мне не нужна скорость, хочу дешево хранить и не пользоваться бэкапами
                    Пожалуйста. Тот же SBE умеет складывать в облако и там еще дедуплицировать.
                    Например, хранение в Google Storage Nearline 100 терабайт стоит около 1000 долларов в месяц. Т.е. только железо, без развертывания, аренды стойки, питания, охлажнения, обслуживания стоит как 15 месяцев использования облака сразу на 100 терабайт, что не бывает.

                    Все идет к облаку. Но все-таки есть применение для StoreOnce. Например, вы купили Veeam, а там дедупликация только в пределах одного задания и места бэкапы занимают очень много. Вот тут вам и поможет StoreOnce.

                    Интересно будет сравнить дедупликацию StoreOnce vs Windows Server 2016. Жду статью.

                    Буду рад помочь с консультацией по бэкапу, дедупликации, облачному хранению, серверам HP.
                      0

                      Подскажите почему Raid5, а не Raid6? Прикидывали сколько времени займет ребилд одного вышедшего из строя диска, заполненного хотя бы на 50-70%? На моей памяти 1Tb диски могли ребилдится по 12 часов и более. За это время вероятность потерять второй диск в том же Raid сильно возрастает. Учитывая то, что партия скорее всего у дисков одна и нагрузка на оставшиеся в живых диски высокая в процессе ребилда.


                      Ну и с облаками в нашей стране, особенно в регионах, основная проблема это ширина канала. А отсюда и скорость бэкапа/восстановления этих данных. Это даже если не брать в расчет стоимость (де-факто абонентскую плату).

                        0
                        Я не только считал, но и делал. Проводил расширение емкости путём последовательной замены дисков с 2 ТБ на 4TB, и 4 ТБ на 8 ТБ.
                        Под нагрузкой ребилд 1 ТБ занимает от суток до недели. Без нагрузки — сутки.
                        Замена 10 дисков 4TB в одной группе в фоновом режиме заняло почти квартал.
                        RAID 6 использовал в системе с большим количеством дисков в группе. Минус — низкая скорость записи из высокого пенальти. Если скорость бэкапа не является критичной, то да -RAID6.
                        Делал много раз так, ибо эксплуатирую множество таких систем.
                        У меня стоят такие решения в 5 регионах РФ от Краснодара до Хант. Проблем с Инетом нет. Даже больше. Для юр. лиц он там дешевле чем в Москве. В Астрахани вообще чуть ли не домашний тариф.
                        Заливаю в неделю 1 терабайт в облако без особых проблем.
                        Плюс решения — не хранить важные бэкапы на одном сайте (ЦОДе) с данными.
                        У одного клиента в был потоп и затопило серверную. Бэкап дублировался в облако. Пришлось поднимать ещё раз SBE (целый квест с ключами шифрования, базой данных с набором резервного копирования). А дальше подняли в арендованном ЦОДе на IaaS самое важное. Сервера на 100 000$ на свалку. Хотя потом что-то со страховкой вернули обратно.

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое