Тома должны оставаться тонкими

    В комментариях к нашему посту об архитектуре 3Par InServ нас попросили подробнее рассказать как реализован у 3Par механизм thin reclamation. Работа по вашим заявкам — это, наверное, самая приятная часть ведения этого блога, поэтому с удовольствием рассказываем.

    Прежде всего давайте посмотрим зачем, собственно, требуется thin reclamation. 3Par, а вслед за ней и другие вендоры дисковых массивов применили в своих системах технологию thin provisioning, которая позволяет выделять приложениям емкость из виртуального пула дисковых ресурсов. При этом выделенная виртуальная емкость может быть намного больше, чем физическая, за счет чего можно существенно сэкономить на дисках при покупке массива.

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

    Например, рассмотрим такой сценарий: файловая система хоста содержит 100 Гб данных и ей выделена такая же емкость из виртуального тома на дисках массива. Если удалить группу файлов общим размером 10 Гб, то массив не сможет узнать об этом удалении и для файловой системы на нем по-прежнему будет выделено 100 Гб.

    Если затем вместо старых файлов будут записаны новые того же объема, то для них потребуется выделить дополнительно 10 Гб емкости на дисках, хотя размер самой файловой системы останется прежним — 100 Гб. В результате тонкий том (thin volume) будет постепенно разрастаться и становиться толстым (fat volume).

    Для решения этой проблемы 3Par добавила в операционную систему InServ функцию Thin Persistence (вольный перевод — поддержание томов в спортивной форме). Thin Persistence работает в реальном времени и анализирует данные перед тем, как они будут записаны в тонкий том. В данных, которые пишет хост, функция ищет блоки, состоящие из одних нулей (это служит признаком затертых данных или неиспользованной емкости), и затем возвращает эти блоки порциями по 16 Кбайт в пул свободной виртуальной емкости. Функция поиска нулей встроена в специализированную микросхему 3Par ASIC Gen3 и поэтому Thin Persistence не замедляет работу массива InServ Storage Server.

    Аналогичным способом работает и функция Thin Copy Reclamation. С той разницей, что она борется с утолщением томов, которое происходит из-за удаления мгновенных снимков (snapshot), а не файлов. При удалении мгновенного снимка выделенная ему емкость виртуального тома возвращается в виртуальный пул и может быть перераспределена между другими томами.

    Особо стоит сказать о том, что 3Par, как пионер технологии thin provisioning, первой среди производителей дисковых массивов реализовала поддержку API-интерфейсов Thin Reclamation для Veritas Storage Foundation версии 5 и выше. С помощью них работающая на хосте файловая система VxFS сама сообщает дисковому массиву (SCSI-командой WRITE SAME) об удалении файлов, поэтому массив InServ Storage Server может найти выделенную этим файлам емкость без поиска блоков нулей (подробнее об этом здесь).

    Кроме того, Oracle совместно с 3Par разработали утилиту Oracle Automatic Storage Manager (ASM) Storage Reclamation для высвобождения емкости для СУБД Oracle Database 10g и 11g на дисковых массивах InServ Storage Server (подробнее здесь).

    Надеемся, что было интересно.

    Comments 25

      +1
      Простите за дилетантские вопросы:
      Какой аппаратный интерфейс взаимодействия рассматриваемого дискового массива с клиентом? SCSI?
      Какой логический протокол используются поверх физического интерфейса?
      Если используется оригинальный логический протокол, доступна ли документация, описывающая его?

      Интересует не API, а описание пакетов, бегающих поверх физического интерфейса.
      Спасибо.

        +1
        используется FC и соответсвенно SAN ( scsi over FC) насколько я понял
          0
          Спасибо. Именно это и хотел узнать.
        0
        Можно уточнить, этот алгоритм позволяет объявить несуществующими области, в которых есть данные?

        Ведь при удалении файла он не затирается нулями, там лежат данные, изменяется только мета-информация. И если кто-то их объявляет пустыми «подсмотрев» запросы о записи информации об удалении файлов?

        Рискованное телодвижение…
          0
          в чём риск? мне кажется, что логично, что удалённые данные не занимают место…
          или вам больше нравится идея с виндовой корзиной?:)
            0
            В чём риск? Например в том, что у меня будет миррор (рейд) между таким томом и обычным. Ближайший ресинк что покажет? Правильно, «она утонула». Рейд рассыпется как карточный домик.

            Идея соблазнительная, но реально это грязный-грязный хак, потому что вы произвольно меняете содержимое чужого блочного устройства. Это рвёт все абстракции, в основе которых неизменность данных на блочном устройстве хранения.

            Я уже молчу про то, что ваша система сделает с какой-нибудь ext5, попутав чуток в атрибутах…
              0
              В чём риск? Например в том, что у меня будет миррор (рейд) между таким томом и обычным. Ближайший ресинк что покажет? Правильно, «она утонула». Рейд рассыпется как карточный домик.

              *вы путаете то что реально пишется на диски и то что видно системе (клиенту стораджа)
              вы же не пытаетесь сравнить в лоб архив(не распаковывая) и исходные файлы?

              Идея соблазнительная, но реально это грязный-грязный хак, потому что вы произвольно меняете содержимое чужого блочного устройства.

              *с этого места поподробнее… «чужого» это как? доступ к дискам идет через те же мозги. и про«грязный хак» может не стоит сразу?

              Это рвёт все абстракции, в основе которых неизменность данных на блочном устройстве хранения.

              не понял у кого где начались абстракции… вы архиваторами никогда не пользовались?

              Я уже молчу про то, что ваша система сделает с какой-нибудь ext5, попутав чуток в атрибутах…

              не понял… думаю на уровне драйверов всё уже решено…
                0
                Я записал 5Гб на хранилище и на локальный диск. Удалил файл.

                Потом сделал diff между локальным блочным устройством и разделом с хранилища. Что я увижу на месте 5Гб данных на хранилище? Те данные, которые были записаны или нули?

                Насчёт абстракций, не обращайте внимание, это сисадмиское, менеджеров по продажам это обычно не тревожит.
                  0
                  Скорее всего, вы увидите нули.
                  Или получите какую-нибудь ошибку в стиле «попытка чтения незаписанной памяти» — если такие вообще предусмотрены всякими API.
                  То, что вы не увидите чужих, или бывших своих данных — определённо.
                    0
                    То есть рейд при проверке рассыпется. Понятно. Радостная новость.
                      0
                      а где был raid? я вот не спроста спрашивал…
                        0
                        В примере выше, где я показал опасность нарушения уровней абстракции. Я делаю миррор между хранилищем и локальным диском — и рейд рассыпается, потому что хранилище себе на уме и хочет подменять данные на блочном уровне, исходя из тараканов файловой системы.
                          0
                          моно вопрос?
                          если хранилище УЖЕ ПИШЕТ RAID-ом зачем вам такой хитрый механизм организации дискового пространства?
                    0
                    Я записал 5Гб на хранилище и на локальный диск.

                    они у вас в софтовом зеркале?

                    Удалил файл.

                    тоже хорошо.

                    Потом сделал diff между локальным блочным устройством и разделом с хранилища. Что я увижу на месте 5Гб данных на хранилище?

                    ещё раз: как у вас осуществляется копирование? вручную? Тогда представьте себе две флешки. вы скопировали и туда и туда… потом на одной стёрли… что будет?

                    Те данные, которые были записаны или нули?

                    нули. кстати такие же нули вы увидите и на исходном устройстве при стирании файла(однако данные будут на месте, тут вы правы), правда до тех пор, пока система «случайно» не затрёт кусками новых файлов

                    Насчёт абстракций, не обращайте внимание, это сисадмиское, менеджеров по продажам это обычно не тревожит.

                    вы менеджеров тут в связи с чем упомянули?

                    сувж.
                    если про меня — я не менеджер и уж тем более к продажам отношения не имею :)
                      0
                      mdadm -c /dev/md0 -n 2 --level 0 /dev/netapp0 /dev/sdb
                      mkfs /dev/md0
                      mount /dev/md0 /mnt
                      (создали файлы, удалили файлы)
                      mdadm --scan /dev/md0

                      Что мы увидим в результате?
                        0
                        я не линуксоид :)
                          0
                          Я вам сначала описал это человеческим языком, потом показал как это сделаю.

                          Вам всё равно не понятно.

                          Видимо, мне следует игноировать ваши реплики, так как с весьма высокой вероятностью вы просто плохо разбираетесь в вопросе.
                            0
                            выше уже всё описано многократно. видимо Вам стоит немножко отступить от того чему Вас учили :) не на всегда, но просто представьте что бывает чуть иначе.

                            про разбирательство в вопросе — я не эксперт ни по netapp-у ни по 3par-у :) во всяком случае пока. а уж игнорировать или нет -решайте сами.
                            кстати в моём «человеческом языке» нет слова «diff»
                            и на последок: речь в статье шла про НОРМАЛЬНОЕ функционирование. а не " выцарапывание стёртых данных"
            0
            Согласен с amarao. Что-то вы недоговариваете :)

            Файловые системы не обнуляют содержимое удаленных блоков (за редкими исключениями, в основном диктуемыми всякими military-grade security решениями), они просто помечаются как неиспользуемые, и без агента на уровне OS и драйвера FS об удалении ничего не узнать.
            Единственное исключение, теоретически претендующее на «кроссплатформенность» это как раз использование SCSI-команд, но пока оно не так распространено, как должно бы.

            С «освобождением»содержащих нули блоков совсем непонятно. А если эти нули где-то внутри данных (сами данные — нули, ну вот так бывает)? А как на такое вмешательство в данные отреагирует программа?
              0
              1) см выше.
              2) думаю согласитесь, что 16кб «нулей» можно описать занчительно более лаконично… да? а про программу — так при чтении и обращении они будут (видимо) восстановлены… для простоты примера — процедура архивации и разархивации.
                0
                Кстати, я давно лоббировал поддержку TRIM в blktap в Xen'е, чтобы как раз иметь возможность возвращать разреженность назад с поддержкой гостевой ОС.
                0
                И, да, речь в данном случае должна идти не столько о WRITE SAME, сколько, как мне кажется, о TRIM, команде, которая (в теории) должна передаваться системе хранения, указывая, что блоки в аргументе больше не используются хост-сервером.
                  0
                  Вот если они реализовали TRIM так, что его будет по какой-то причине будет использовать система, то это да, это круто. А мухлёж с подменой данных — это всего лишь мухлёж.

                Only users with full accounts can post comments. Log in, please.