Fluid Data: «маленькая» победа в хранении «больших» данных — часть 2

    В предыдущей части мы начали знакомство с новой технологией Fluid Data, предназначенной для улучшения жизни тем, кто имеет дело с действительно большими данными. Также были разобраны некоторые, но не все, преимущества этого решения на примере СХД Dell Compellent. Что ж, не откладывая в долгий ящик, предлагаем продолжить знакомство.

    Сударь, защищайтесь! И бэкаптесь!


    Админы делятся на два вида: на тех, которые ещё не делают бекапы, и на тех, которые уже делают. Бородой этой шутки, наверное, можно пару раз обернуть Землю, но актуальности своей она всё равно не потеряет. Сегодня непрерывность бизнес-процесса для компании порой весьма критична, а это значит, что хорошая СХД должна предлагать решение для возможных проблем. Какие «беды» могут ждать железо? Как минимум отключение питания, человеческий фактор (ошибки пользователей), вирусы и т.п. Однако у традиционных подходов к защите и восстановлению данных с течением времени накопилось порядочно «атавизмов»: они стали требовать слишком много дискового пространства, при этом не блеща показателями надёжности и скорости работы. К примеру, генерация мгновенных снимков вполне эффективно защищает данные (конечно при условии, что время между двумя последовательными снимками достаточно мало). Однако при этом часто приходится использовать полную зеркальную копию и клоны всего тома. А ведь ещё и RAID есть, который совсем не облегчает задачу. Добавьте сюда малоэффективное выделение ёмкостей, о котором мы говорили в предыдущей статье, и получите патовую ситуацию: снимки можно делать, но большое их количество просто негде хранить. И здесь либо придётся увеличивать время между двумя последовательными точками восстановления, либо иметь возможность откатиться на небольшой период времени. Очевидно, оба подхода «не торт».

    Поэтому вполне естественным и логичным является решение, используемое в системах Dell Compellent, которое получило название Data Instant Replay. Его принцип чем-то напоминает поведение большинства онлайновых игр — на сервер стекается только информация об изменениях в игровом мире, а не видео / звук / чат / мат… В применении к бэкапам данных это означает отказ от полных зеркальных копий и последующих клонах тома в сторону записи только изменения данных с момента последнего мгновенного снимка. Такой подход неизбежно вызовет экономию дискового пространства, а в купе с Dynamic Capacity и вовсе — double damage profit.

    image


    Что ж, получив такой выгодный инструмент и минимизировав время между двумя снимками, необходимо позаботиться и об автоматизации процесса. Не тыкать же в кнопку самому каждые 15 секунд? Это, так сказать, попахивает Foxconn’ом  Тем не менее, эта тривиальная задача решается настройкой не менее тривиального встроенного планировщика, позволяющего автоматически запускать процесс «репликации».

    Остаётся лишь привести какой-нибудь пример из жизни (картинка не в счёт), доказывающий «полезность» технологии. Представьте, что поставлена задача протестировать новые приложения или сервисы, которые компания возможно планирует внедрить в будущем. Где гарантия, что в процессе теста всё пройдёт «без сучка, без задоринки»? При использовании Data Instant Replay это можно будет сделать без всякого риска потери или порчи данных.

    Админы реплицировали, реплицировали, да не выреплицировали



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

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

    Но кто сказал, что эти проблемы нельзя решить за приемлемую цену? В Dell точно не говорили. И разработали технологию «тонкой» репликации (ориг. Thin Replication) под названием Remote Instant Replay. Её идеология схожа с вышеописанным способом создания бэкапов: после первоначальной синхронизации площадок в дальнейшем по каналам связи курсируют только изменения в данных.
    Выгоды очевидны:
    • снижение расходов на оборудование;
    • снижение расходов и требований на пропускную способность каналов связи;
    • увеличение скорости восстановления информации.

    Также в преимущества обязательно стоит записать относительную «всеядность» технологии, то есть на резервных площадках можно использовать недорогие диски SAS и SATA и при этом не разоряться на полосу пропускания канала. А ещё больше повысить эффективность может встроенный в системы Dell Compellent конвертер Fibre Channel-to-iSCSI, позволяющий обойтись родной IP-сетью без преобразования протоколов.

    Счастья много не бывает



    Напоследок остановимся ещё на одной актуальной проблеме, которая рано или поздно постигает любой успешный бизнес. Речь идёт о неизбежном росте объёмов информации. Для СХД эта проблема трансформируется в требование к масштабируемости. Беда в том, что поставщики решений тоже не дураки и хотят заработать денег. Простая аналогия: производитель имеет возможность выпускать за приемлемую цену флешки на 64 Гб. Но зачем ему это делать, если в данный момент на «пике популярности» 8 Гб? Да и куда потом девать флешки на 1, 2 и 4 Гб? Очевидно, вводить потребителя в «лучшую жизнь» надо постепенно — это выгодно и производителям, и продавцам (не выгодно только самому потребителю). Поэтому сначала появятся решения на 16, затем на 32 и только потом заветные 64 Гб.

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

    В Dell, хотите верьте, хотите нет, решили отойти от этого принципа. Системы хранения Dell Compellent рассчитаны на длительный жизненный цикл. Саму платформу по мере роста «аппетитов» можно масштабировать от двух до тысячи терабайт ёмкости. При этом допускаются вариативные комбинации как серверных интерфейсов FC и iSCSI, так и используемых дисков (SSD, FC, SAS и SATA). Можно даже устанавливать в одной дисковой полке накопители SAS разной емкости и скорости вращения.

    С другой стороны, особое внимание уделено защите от сбоев. Объединенные в кластер контроллеры, каждый из которых оборудован резервированными вентиляторами и блоками питания, совместно обеспечивают оптимальную производительность системы. Тем не менее, каждый контроллер независимо от другого подключен к дисковым полкам и дискам для устранения единой точки отказа. А виртуализация портов контроллера и дублирование канала ввода / вывода между серверами и дисками устраняет необходимость в приобретении дополнительного программного обеспечения.

    Послесловие



    Не стоит мириться с «грабительскими» подходами традиционных СХД, предлагающих заказчику заведомо обречённые на устаревание и ограниченные по совместимости решения. Dell Compellent обеспечивают динамичное виртуализированное хранение, которое легко адаптируется к постоянным изменениям.
    В основные особенности можно записать:
    • оптимизирование процесса хранения данных, позволяющее эффективно распределять дисковое пространство;
    • встроенные интеллектуальные функции управления данными и возможность их автоматизации;
    • улучшенную технологию мгновенных снимков;
    • изначальное проектирование системы на долгосрочный период без привязки к фирменным технологиям и конкретным производителям.

    Что тут добавить? Хочешь делать хорошо — делай это с Dell.
    Dell Technologies
    Компания

    Похожие публикации

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

      +2
      Ребят, если вы хотите кого-то тут заинтересовать, то писать надо по делу, а не тупые слоганы вешать.

      Производительность? IOPS/Gb?
      Latency?
      Уровень избыточности?
      Цена за Гб и за IOPS?

      Пока всё написанное сильно напоминает убогую рекламу всяких «one button backup» на usb-sata дисках.
        0
        В будущем постараемся сделать статью про конкретную реализацию для проекта с цифрами на базе конкретных массивов.
        Fluid Data — это просто концепция и идея, которая воплощается в различных решениях (equallogic, Compellent, NX, DX, FS и т.п. устройствах), на базе различных аппаратных и программных платформ. Т.е. статья — про идею, которая имеет различные реализации, а не про конкретное решение.
        «Производительность? IOPS/Gb?
        Latency?
        Уровень избыточности?
        Цена за Гб и за IOPS?»
        Вопросы не несущие под собой никакого смысла без понимания характера нагрузки, объемов, требований, условий эксплуатации и многого другого.

        Производительность в «тяжелых» решениях переваливает за 100K IOPS в зависимости от нагрузки (размер блока, % кэшхита, соотношение чтение/запись, наличие мирроринга, тип RAID, и т.д.).
        Latency при 100% кэшхите — 3 милисекунды
        Цена от 10K USD до 2,5M USD за массив

        Как вы наверняка поняли, вопросы должны быть предметными, типа сколько IOPs и какая Latency будет в такой конфигурации, при таком типе нагрузки. Сколько это стоит и т.п.
        Это мы постараемся осветить позднее, на примере конкретных реализаций.
          0
          Можно уточнить про «переваливает за»? Лично мне было бы интересно посмотреть на конфиг, который в разумный ценник способен дать что-то порядка 500 IOPS/Tb при latency <2мс.
            0
            Еще раз. Latency менее 2 мс — что кэшхит, т.к. даже SSD в сетевых устройствах дает latency ~4мс.
            практически любой массив любого производителя легко будет давать вам и 10000 IOPS при Latency <2 мс, если вы будете грузить его нагрузкой со 100% кэшхитом.
            При 100% рандоме (что так же в реальности встречается совсем редко) каждый шпиндель SATA будет давать порядка 120 IOPS, SAS/FC c дисками 15К — порядка 200 IOPS со шпинделя. Т.е. какого бы класса вы массив не купили — при 100% рандоме и 10HDD SAS15K больше 2000-2200 IOPS вы с него не снимете.

            В отрасли все производители, как правило, оперируют параметром — сколько IOPS даст массив при Latency <30мс, и при таких условиях 100000 IOPS — это очень большой показатель.

            Давайте так. скачайте с сайта Dell бесплатную утилиту DPACK. Она собирает статистику о том, какой ввод-вывод на вашей СХД, какими блоками, сколько кэшхитов, соотношение чтения-записи и т.п. Все безопасно и никакие ваши данные трогаться не будут.
            Скачать можно тут:
            content.dell.com/us/en/business/d/campaigns/dpack-downloads.aspx
            Там же есть описание как инсталлировать и настраивать. Соберите отчет хотя бы за 4 часа, лучше за день и пришлите мне — mvorobyev (собака) dell.com — и мы предложим вам вариант который подойдет под вашу нагрузку с любым запасом по емкости или производительности под ваши нужды.
              0
              А можно просто исполняемый файл? Что я с этим VMware-Player-4.0.2-591240.i386.bundle делать должен?

              По моим попугаям (fio по диску с размером 2Тб, 16 потоков на чтение, 16 на запись (независимо), random 4k) для одиночной виртуалки я получаю вот такое:

              read: (groupid=0, jobs=1): err= 0: pid=25763
                read : io=1038MB, bw=16037KB/s, iops=4009, runt= 66306msec
                  slat (usec): min=3, max=816, avg= 8.91, stdev=11.64
                  clat (usec): min=37, max=287122, avg=3978.01, stdev=5858.45
                  bw (KB/s) : min= 2784, max=23536, per=100.13%, avg=16057.19, stdev=3993.55
                cpu          : usr=1.92%, sys=5.53%, ctx=144550, majf=0, minf=136
                IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
                   submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
                   complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
                   issued r/w: total=265831/0, short=0/0
                   lat (usec): 50=0.01%, 100=0.02%, 250=0.12%, 500=0.39%, 750=1.42%
                   lat (usec): 1000=5.71%
                   lat (msec): 2=38.96%, 4=28.63%, 10=14.20%, 20=9.71%, 50=0.69%
                   lat (msec): 100=0.05%, 250=0.10%, 500=0.01%
              write: (groupid=0, jobs=1): err= 0: pid=25765
                write: io=1426MB, bw=22025KB/s, iops=5506, runt= 66294msec
                  slat (usec): min=3, max=907, avg= 8.99, stdev=14.87
                  clat (usec): min=142, max=156462, avg=2892.95, stdev=3655.73
                  bw (KB/s) : min= 6352, max=29728, per=100.24%, avg=22077.33, stdev=3797.21
                cpu          : usr=2.06%, sys=6.96%, ctx=174691, majf=0, minf=125
                IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
                   submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
                   complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
                   issued r/w: total=0/365032, short=0/0
                   lat (usec): 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.14%
                   lat (msec): 2=21.66%, 4=69.79%, 10=7.56%, 20=0.57%, 50=0.16%
                   lat (msec): 100=0.03%, 250=0.08%
              


              И да, мы используем flashcache для кеширования. Разумеется, там latency будет ниже, чем у магнитных дисков.

              ЗЫ Если найдёте что-то приемлимое для запуска (linux x86/64), обращайтесь, будем смотреть и сравнивать.
                0
                ПО ссылке выше (content.dell.com/us/en/business/d/campaigns/dpack-downloads.aspx) вторая ссылка — клиент под линукс. :)
                Вот конкретная ссылка на него
                www.dell.com/support/drivers/us/en/555/DriverDetails?DriverId=5XF67
                С его статистикой и репортом проще работать, чем руками эмулировать вашу нагрузку
              0
              ЗЫ каким образом SSD может дать latency больше 4мс, если запись занимает менее 1мс, а сетевой пинг 0.1мс? Про чтение с SSD можно и не говорить, надеюсь и так понятно.
                0
                Достаточно очереди переполнить :)
        0
        .

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

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