FlexClone — цифровая овечка Долли

    image

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


    Практический пример того, где и как можно применить клоны.
    Допустим, в нашей компании используется большая база данных, в которой сосредоточен весь наш бизнес, например база ERP-системы. Разумеется бизнес живет и растет, вместе с ростом нашей компании, группа разработки пишет новую функциональность для базы, проектирует новые рабочие места, пишет в базе какую-то новую бизнес-логику. И все это им надо тестировать и проверять на данных. Причем чем более объемные и реальные данные будут у них — тем эффективнее и точнее будет их тестирование.
    В идеале им нужно тестироваться на реальных данных, на реальной базе вашей компании. Однако кто ж в здравом уме пустит на «боевую» базу тестировать что-то?
    Вот если бы можно было создать точную копию базы, в ее текущем состоянии, специально для тестирования!

    Но для создания полного, независимого клона, нам понадобится объем хранения как минимум равный емкости основной базы. Да еще и быстродействие такой базы должно бы быть, в идеале, равное «боевой», то есть не подойдет копировать их на «кучу USB-дисков». Я уж не говорю о том, что по условиям внедрения, например, такой ERP-системы, как SAP, в развернутой инфраструктуре просто обязательно должны быть подразделения разработки и QA (Quality Assurance, валидации и проверки), а зачастую еще нужна и база для проведения тренингов и обучения новых пользователей, и у каждой обязательно должна быть своя копия текущей базы, на которой проходит разработка и контроль приложений, а также обучение персонала.

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

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

    Сделать клон можно тремя путями. Во-первых, просто скопировать данные в свободное место, и поддерживать его актуальность вручную. Это очевидно, и не интересно. Это скорее копия, а не клон. Такой вариант занимает огромное пространство дорогого места хранения и много времени на свое создание.
    Второй вариант — так называемые Copy-on-Write (COW) копии. В них записи, которые, допустим, тестируемое приложение хочет занести в свою «копию» вызывают копирование исходных данных в специальное зарезервированное пространство, при этом сохранятся как исходный набор данных, так и их изменения. Проблемы тут те же самые, что и у COW-снэпшотов, это почти втрое снижает производительность работы такого хранилища. И это тоже неинтересно.

    А третий вариант реализовал NetApp.
    Как вы уже знаете, лежащая в основе всех систем хранения NetApp структура размещения блоков данных под названием WAFL, устроена таким образом, что изменения блоков в ней делаются не внутрь фактически изменяемых блоков, а в свободное пространство тома, куда затем переставляются указатели текущего состояния данных.
    Такая схема позволяет легко и изящно решить проблему с изменяемыми блоками в клоне. Клон всегда остается неизменной виртуальной «копией» данных (а значит мы можем не занимать им место на диске, а просто ссылаясь из него на блоки исходных данных), а все изменения блоков, которые мы делаем над экземплярами клонов накапливаются отдельно.
    Следовательно, место на диске такие клоны занимают только в объеме внесенных в клоны изменений.

    image

    Если ваши программисты в отделе разработки наизменяли в своих виртуальных копиях клонов базы, размером 6TB, пару терабайт данных — то их клон займет на диске из свободного места ровно эти 2TB, и только.

    image

    На скриншоте вы видите, как на практике выглядит такой клон. На диске находится три файла, каждый, с точки зрения Экплорера размером 10GB, однако занятое на диске место всеми тремя — всего 10GB.

    image

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

    Кстати сказать, таких клонов может быть до 255 на каждом томе (не на систему в целом — на каждый том!), и вы можете не ограничивать себя количеством клонов. Если у ваших разработчиков есть несколько вариантов, и они хотели бы выбрать один из них — просто дайте им по клону на каждый вариант, пусть экспериментируют и выберут, сравнив все желаемые варианты разом.

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

    На картинке в заголовке статьи — клоны два контроллера новой серии FAS3200.
    NetApp
    32,34
    Компания
    Поделиться публикацией

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

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

      +1
      А чем хуже копия файла + дедупликация?
        0
        Главное, например тем, что при копировании плюс дедупликации вам придется сначала потратить время (подчас немалое) и место на копирование, посчитайте сколько будет копироваться пара терабайт, а ведь это еще и нагружает работающую систему вводом-выводом.
        А потом, после того, как, допустим ночью, отработает постпроцесс дедупликации, вы получите назад высвобожденное место.
        То есть на момент копирования вам все равно нужно будет иметь место для размещения копии.
        Клонирование же происходит мгновенно (ну, почти, секунды, на формирование метаданных клона) и места при этом не занимается (ну кроме нескольких сотен килобайт на метаданные клона).

        Ну то есть да, в основе тот же механизм shared disk block use, что и при дедупликации и снэпшотах, это просто еще один способ его использовать.
          0
          А, ну да, еще «хуже» тем, что, в отличие от дедупликации, лицензия на FlexClone за деньги, и довольно существенные, то есть нацелена, скажем так, на «верхний» сегмент рынка.
          Это, к слову, вообще первая «платная» фишка систем NetApp, из всего, что я рассказал до сих пор. Все остальное включено в покупаемую систему, по сути, бесплатно для клиента.
          0
          Фраза «до 255» на том очень правильна, число не гарантировано, там делается ссылка на каждый блок в отдельности, а значит для каждого блока будет индивидуальное число максимально возможных ссылок 255 минус «количество уже существующих ссылок». Например если том хорошо дедуплицирован то число может значительно снизиться.
            0
            А это чем-то подтверждается? Потому что в документации об этом ни слова. От снятых снэпшотов, например, количство доступных клонов точно не зависит.
              0
              Извиняюсь, промахнулся, написал ниже.
              0
              Именно поэтому и «до». Используется тот же механизм, что и в дедупликации, только «с другой стороны». То есть дедупликация это «постпроцесс», а клонирование — «препроцесс». Но фактически внутренний принцип тот же.

              Впрочем возможно в будущем, если это будет ограничивать пользователей, это может быть изменено в сторону увеличения. Пока же клонирование и дедупликация редко совмещаются функционально на одном томе, просто незачем, а на разных это не ограничивается.
              0
              Можно посмотреть в TR3742 на NOW (переведенный документ есть на Netwell.ru, пункт 5.9).

              Снапшоты не создают дополнительные ссылки на физические блоки, они залочивают ссылки на физические блоки в таблицах inode. А вот этих ссылок может быть много на один и тот же блок.

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

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