Проблема динамического выделения дискового пространства виртуальных машин

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

    Суть проблемы: Системы виртуализации с высокой степенью виртуализации (я это говорю, чтобы отмести в сторону openvz) предоставляют место виртуальным машинам в форме виртуального диска. Или, точнее, виртуального блочного устройства. Иногда эмулируется скази (VMWare Server, Virtual PC), иногда «неопределённое блочное устройство», иногда прямым текстом «виртуальный диск» (Xen для PV-машин). Важным является то, что это устройство полностью повторяет свойства блочного устройства — набор секторов, которые можно читать и писать.

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

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



    Во-первых, нужно сказать, что большинство файловых систем умеет увеличиваться «на ходу». XFS, raiserfs, ext3-4… Некоторые файловые системы могут уменьшаться (ext3, raiser… xfs не умеет). Windows тут выглядит полным ауткастером, так как не поддерживает изменение размера файловой системы NTFS, особенно, на системных дисках. Сторонние утилиты умеют это делать, но не на ходу…

    Но даже белая и пушистая ext3 не умеет это делать в штатном режиме. Нужно руками говорить «отресайзить», причём процесс рейсайза (особенно, вниз) занимает огромные ресурсы. По моим личным впечатлениям, на обычных SATA-дисках ресайз с 5.5Тб до 4.5Тб файловой системы с 4Тб занятого пространства занимает около 10-12 часов. Увеличение отрабатывает быстрее, за единицы минут. Но — всё равно с потерей производительности, большой нагрузкой и непозволительно долго.

    Да и сам подход неверен. Если мы хотим динамически изменять размер используемого пространства, то нам нужен механизм, который бы добровольно освобождал неиспользуемое пространство, в штатном режиме работы ФС, и запрашивал новое при необходимости.

    Существующие решения


    Насколько я понимаю, таких файловых систем для блочных устройств пока нет. Единственным выходом ялвяется использование file-based network access, иными словами, использование NFS/SMB для юникс и SMB для windows.

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

    Что на самом деле нужно


    Файловая система должна быть минимально возможного размера. Если у нас занято 2Гб, то размер файловой системы 2Гб + служебные данные. Если мы решили создать файл в 100Тб размером, то файловая система запрашивает у блочного устройства нижележащего уровня 25 миллиардов блоков по 4кб и размещает файл. Когда файл сотрут, файловая система отдаст эти 25 миллиардов обратно.

    На ум приходит «LVM», но LVM не поддерживает в настоящий момент запросов от файловой системы, да и к вырезанию дыр из середины FS не готов совершенно…

    Вопросы



    Вопрос 1: существуют ли файловые системы в которых есть подобное решение?
    Вопрос 2: как должен выглядеть интерфейс файловой системы и блочных устройств?
    Вопрос 3: Можно ли представить себе замену блочных устройств на такой тип виртуальных устройств, который бы с одной стороны позволял создавать и использовать файловые системы, с другой стороны был бы более приспособлен к динамическому изменению размера?
    Вопрос 4: как такое устройство будет примерно выглядеть?
    Поделиться публикацией

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

      0
      zfs
      На мой взгляд идеальная фс, жаль только под линей+fuse дико тормозит.
        0
        zfs способна координироваться с нижележащим блочным устройством? Как? Как выглядит процесс освобождения блоков?
          0
          что вы подразумеваете под этой витиеватой фразой?
            0
            Каким образом zfs даёт знать блочному устройству, что указанный блок можно убрать? И как это будет обрабатываться блочным устройством?

            Речь именно про блочные устройства, про то, каким образом они могут взаимодействовать с файловой системой в вопросах «добавить/удалить место».

            Если не понятно: вопрос о том, как с помощью файловой системы уменьшать размер VDI на диске.
              0
              ну смотрите, идеология ZFS:
              1) Делаем «пул» из блочных устройств по типу LVM-а
              2) Поверх пула делаем «разделы», только делаются они по типу папок (никаих фоматов, фдисков и прочего — делается все моментально).
              — Ты можешь сделать один раздел на весь пул.
              — Можешь два и ограничить их размером в половину пула каждый.
              — А можешь три, и без ограничений, и они будут занимать именно столько места, сколько данных на них есть.
              Там нет нужны уменьшать\увеличивать размер раздела, можно поставить принудительно ограничение на размер конкретного раздела, чтобы он не занимал более определенного объема.
              Увеличение размера пула — без проблем, уменьшение — без проблем. Но естественно, если у тебя раздел 5тб, да еще и raidz, процесс может занять неделю, но это ИМХО, проблема «универсальности» ЦП и медленная работа ЖД.
                +1
                Смотрю. И всё ещё не понимаю, каким образом, удаляя файл на 1Тб на одной виртуальной машине, я освобождаю 1Тб для остальных виртуальных машин.
                  0
                  пул занимает все возможное дисковое пространство(и легко расширяем если понадобится), а для каждой виртуалки можно выделять разделы на пуле — у них обьем будет равен занятому месту данными. Записали в раздел еще данных — он увеличился за счет свободного места из пула, удалили данные — раздел уменьшился и отдал пустое пространство в пул где его может использовать раздел любой другой виртуалки. Както так)
                    0
                    Раздел уменьшился? Как он понял, что нужно уменьшаться? Через какое API это делается?
                      0
                      это не через апи делается) это делает сама фс — она так устроена. Все физически доступное место является пулом, а все разделы внутри него занимают места ровно столько сколько в них данных. Данных добавили раздел увеличился за счет свободного места в пуле, данные удалили — свободное место опять отдается в пул на пользование другим разделам.
                        0
                        Ага. Уже интересно. Теперь вопрос: как обеспечить сосуществование двух и более VM на одном блочном устройстве?
                          +1
                          вот тут уже точно не скажу, надо пробовать на практике. если с обычными фс там все просто — при форматировании появляется новое вирт блочное устройство, то тут я не уверен ведут ли разделы себя также. Хотя мне кажется это уже проблема системы виртуализации, а не фс — выдать каждой VM определенный раздел. А квоты(макс обьем раздела до которого позволено разростатся) можно уже и средствами фс ставить.
                            –1
                            Можно попробовать расшарить раздел (ну т.е. файловую систему zfs) через iscsi. И вообще по хорошему вы пытаетесь изобрести велосипед — уже давно оформилось разделение между серверами и стораджами. Советую вам посмотреть на последние достичения в области storage и подключения по iscsi через гигабит или FB.

              0
              RAID-Z на этом построен.

              Ну, и для reiser4 (он, кстати, reiser, а не raiser) можно сделать плагин.

              Reiserfs умеет динамическое увеличение без остановки.
                0
                Они все умеют динамическое увеличение. Вопрос в том, сколько ресурсов при этом потребляют. И насколько это штатный режим?
                  0
                  Reiserfs вполне стабилен при увеличении раздела.
                    +1
                    Что значит стабилен? Я спрашиваю про штатность (т.е. автоматичность) операции.

                    Я пишу на раздел в 2Гб файл в 4Гб. Блочное устройство (допустим) предоставляет места на 10Гб. Оно само раздвинется? Если нет, это строго то, о чём я написал в начале.
              0
              недавно проскакивала новость что уже написали модуль ядра для zfs, скоро про fuse можно будет забыть
                0
                ZFS + Solaris. Доступны любые представимые действия с файловой системой.

                Линукс же в настоящее время работает с ZFS только через костыли.
                  +1
                  Да не подходит ZFS. ZFS отлично (в этой части) эмулируется с помощью LVM + обычная FS, но это явно не автоматическое on-demand выделение и освобождение места. Кроме того, совершенно не ясно, как именно ZFS может пережить изменение диска (1шт) с 10Гб до 5Гб.
                    0
                    >>>изменение диска (1шт) с 10Гб до 5Гб
                    Легко. Добавляем в пул диск в 5 гигов, удаляем 10 гиговый, это при условии что не используется RAIDZ\Stripe и данных в пуле меньше 5 гигов.
                      0
                      И это будет штатным режимом работы zfs? Не верю. С большой вероятностью этот манёвр вызовет просто взрыв дисковых операций.
                        +1
                        Конечно вызовет. Вы меняете один физический диск на дугой физический диск. Как минимум данные нужно перенести.
                        Вот если разделу в пуле размер менять — это никаких проблем, но тут идеология разделов немного другая, почитайте выше.
                      0
                      zfs autoexpand — почему нет?
                  +1
                  Мне очень интересна эта тема. Если пропущу путный ответ — пожалуйста, напиши в хабрапочту.

                  Мы думали, думали… и так и не нашли «дешевого» в плане разработки и внедрения решения (Xen). С CIFS/SMB все хорошо. С блочными устройствами — плохо. как минимум — прийдется его отмонтировать и ресайзнуть неким управляющим скриптом, потом примонтировать в гостевой OS.
                    0
                    Ну, отмонтировать не обязательно. Если том лежит на NFS, то его можно изменять в размере динамически. Но файловой системе всё равно приходится ресайзить, и это явно не прозрачная операция, которая может быть инициализирована самой файловой системой…
                    +3
                    Есть виртуальная инфраструктура VMware ESX 3.5 + vSphere. Регулярно меняю размер системных разделов на работающих виртуальных серверах 2003, 2008 и 2008 R2. Для расширения системного диска внутри виртуалки с 2003 виндой требуется утилита от Dell под названием ExtPart. Увеличение размера происходит прямо в онлайне, без остановки виртуальной машины. В винде же 2008 и старше увеличение размера осуществляется штатными средствами, через оснастку «управление дисками», в 2 клика, опять же без остановки.

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

                    Как говорится, enlarge and enjoy :)
                      0
                      Да и с уменьшением (shrink) на лету системных разделов под NTFS в Windows Server 2008 и выше стандартными утилитами проблем никаких нет.

                      Файловая система должна быть минимально возможного размера. Если у нас занято 2Гб, то размер файловой системы 2Гб + служебные данные.

                      А это уже, на мой взгляд, должно быть проблемой совсем не файловой системы, а СХД, и, кстати, у многих вендоров Thin Provisioning реализован и вполне успешно работает.
                        0
                        вы это делаете руками или из скриптов. Я же говорю про ситуацию, когда у вас кто-то начинает писать файл в 1Тб на системный диск в 2Гб размером… И успешно записывает, потому что файловая система запросила 1Тб у блочного устройства, блочное устройство увеличилось в размере, файловая система увеличилась в размере…

                        После того, как файл стёрли, всё прошло обратно. Без каких-то ручных телодвижений.
                          0
                          Изначально вопрос звучал так:
                          Большинство систем виртуализации позволяет изменять размер дисков. Многие системы позволяют это делать на ходу, в онлайне.

                          Вопрос звучит так: а может ли гостевая ОС воспользоваться этим местом свободно? Этот вопрос выходит за рамки виртуализации и является общим вопросом: есть ли у нас файловые системы, которые способны динамически изменяться в размере в штатном режиме?
                          Если приходится писать терабайтные файлы на системный раздел, значит, инфраструктура спроектирована отвратительно. Под подобные задачи нужен отдельный сторедж, специально рассчитанный на работу с громадными объемами данных. Облако хранения, или High-End хранилище с собственной логикой.
                            0
                            А если мы уже про облако говорим? И «системный раздел» лишь условность, оно всё лежит на сетевом сторе?
                              0
                              Если мы уже говорим про облако, то у нас нет задачи менять системный раздел. Логика у нас живет в ПЗУ, либо в специально отведенной флешке (или на отдельном диске/массиве).

                              Из сравнительно простого, что приходилось щупать руками — сторедж с ZFS. Имеется, к примеру, 10 терабайтных дисков в одном ZFS пуле. Внутри этого пула создаются разделы — сколько угодно — которые шарятся любым способом — NFS, CIFS, iSCSI, FC. Если не ограничивать размер раздела, он может занять всё свободное на пуле место, все 10 условных терабайт. Файлы удаляются — место освобождается, и всё это в автоматическом режиме без участия админа. Можно добавлять/удалять физические диски (hot-spare, разумеется), при этом размер пула соответственно изменяется.

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

                              P.S. Как-то мы лихо уехали от виртуалок в облака…
                                +1
                                Тыг, повторю ещё раз: облака — это метод учёта ресурсов. В частности, для виртуалки. И чтобы виртуалка стала облачной, ей нужно дать места «жри сколько хочешь, заплатишь за сожранное».
                                  0
                                  Ну так и не надо здесь локальных файловых систем, пусть виртуалка по NFS/CIFS до стореджа доступается. Папка /docs или сетевой диск. А сторедж on-demand сам разрулит, кому сколько выделить. Зачем усложнять локальную файловую систему, если уже есть решения, заточенные под гибкое хранение?
                                    +1
                                    Ага. Теперь следующий вопрос: как бы это совместить с необходимостью грузить систему?

                                    Я уже думал о «бездисковой виртуальной машине», которая бы с NFS грузилась бы, но как-то это очень громоздко выглядит…
                                      0
                                      Давайте более конкретно, что в итоге нужно получить? Не хочется городить сферическую виртуалку со сферическим хранилищем в вакууме.
                                      0
                                      Здесь есть проблема с безопасностью доступа. Пока мы имеет storage network и опосредованный доступ через платформу виртуализации, нет опасности прослышивания трафика.
                                      Как только подключим сторадж прямо в виртуалку, например Microsoft iSCSI Initiator, скажем «до свидания» безопасности.
                                        +1
                                        Ну, для этого и существует nfsv4 с керберосом. А там уже на выбор krb5, krb5i, krb5p.

                                        Алсо, слушать трафик на виртуалке никто не даст, виртуальный интерфейс воткнут в виртуальный коммутатор, который прекрасно заметит хулиганство со стороны VM. (а в принципе, его можно вообще запретить как класс).
                                          0
                                          Виртуальный коммутатор воткнут в физический коммутатор.
                                            0
                                            И? Трафик-то фильтруется на вируальном коммутаторе. Не пройдя его дорваться до вышестоящих коммутаторов не получится. А фильтр «не флудить маками» на самом деле очень легко пишется (по-крайней мерере в Open vSwitch, который в Xen Cloud Platform идёт).
                                              0
                                              iSCSI трафик уходит с виртуального коммутатора на физический и так до iSCSI target. Вот как только он ушел в физическую сеть, его можно слушать, поскольку он ушел не в выделенный сегмент для iSCSI а через general purpose.
                                                0
                                                Простите, КТО будет слушать трафик в сети между хостом/iscsi target? Гостевые VM? Я написал выше.
                                                  0
                                                  Тот, кто подключен к тому же физическому коммутатору.
                                                    0
                                                    К фическому коммутатору подключен шлюз, хосты виртуализации, сторедж, виртуальные коммутаторы внутри хост.
                                                      0
                                                      В случае использования Software iSCSI из гостевой ОС идет чистый нешифрованный трафик:
                                                      гостевая ОС -> виртуальный коммутатор -> физический коммутатор ->… -> физический коммутатор -> iSCSI Target

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

                                                      Если же iSCSI используется (на примере VMware) для создания VMFS датастора, то по всем рекомендациями и руководствам iSCSI сеть ввиду ее незащищенности должна быть отделена физически или как минимум в отдельный VLAN. Трафик iSCSI не встречается с general purpose трафиком, к которому имеет доступ кто угодно и может подключиться откуда угодно.
                                                        0
                                                        Как именно можно в такой ситуации прослушать трафик? Встать в разрыв между каким-то из элементов в этой цепочке?
                                  0
                                  Системный раздел не условность, если речь идет о винде.
                                  1) если по какой-то причине надо переустановить ОС, то можно не беспокоиться о сохранности данных — он будут лежать не на системном разделе
                                  2) виртуальный диск с ОС может лежать на low-end storage, ведь по сути надо только заугрзиться. А данные на сверхможном дорогом массиве
                                    0
                                    Я не могу сказать про винды, но debian занимает примерно 200-400Мб в серверной установке, тут нет нужды париться на разделение системного диска и данных.
                            +1
                            > Windows тут выглядит полным ауткастером, так как не поддерживает изменение размера файловой системы NTFS, особенно, на системных дисках.

                            либо «не поддерживает» (вообще не поддерживает), либо «особенно, на системных дисках» (поддерживает, но есть известные проблемы)

                            и вообще пи… дёжь и провокация: ещё в 2k были реализованы динамические диски и тома

                            А разве высокая степерь виртуализации не подразумевает максимальное абстрагирование от аппаратной части. Я к тому, что при таких задачах (облако) наверное надо не блочные устройства эмулировать, а по максимуму использовать файловый доступ (NFS/SMB).
                              0
                              NFS/SMB — бесконечно медленно, по сравнению со скоростью операций с блочными устройствами.
                                +1
                                Насчёт SMB не скажу, но в сравнении NFS/iSCSI я не заметил существенных различий.
                                  0
                                  iSCSI — тоже далеко не предел мечтаний. TCP/IP все же сильно тупит всю передачу, особенно при большой нагрузке множеством потоков.

                                  Если у вас действительно серьезные задачи с серьезной нагрузкой, то никаких SMB/NFS/iSCSI. Fibre Channel, Infiniband и иже с ними.
                                    0
                                    Ну, насколько я понимаю, при 10G сожрать полосу так, чтобы поплохело TCP, несколько проблемно…
                                      0
                                      При 10G да. Просто я встречал множество сисадминов, которые страшно удивлялись, чего это у них все тупит по двум агрегированным гигабитным портам )
                                0
                                Динамические тома-то она поддерживает. А изменение размера системного диска? Не затруднит ткнуть в команду в 2003/2008 для этого?
                                  –1
                                  Аналогичным образом из консоли можно сделать Diskpart'ом.
                                    0
                                    Интересно. Я с виндами распрощался ещё на уровне 2003, 2008 плотно не смотрел. Будет под руками тестовый образец, проверю. Возможно, они этот вопрос допилили…
                                      0
                                      ...Windows тут выглядит полным ауткастером...
                                      … с виндами распрощался ещё на уровне 2003...
                                      Так распрощались или всё-таки ауткастером?
                                        –1
                                        По состоянию на 2003R2 — ауткастером. Возможно, догнали.
                                      0
                                      Только для 2008
                                    +1
                                    Ну, этот вариант я тоже прорабатываю. Проблема в том, что в отличие от блочного устройства, на NFS очень сложно учитывать число дисковых операций.
                                    +2
                                    Btrfs начиная с 2.6.35 не будет иметь статус экспериментальной ФС.
                                    Про увеличение/уменьшение здесь: btrfs.wiki.kernel.org/index.php/Btrfsctl
                                    Но только вручную.
                                      0
                                      В списке фич btrfs есть еще:
                                      Block discard support (reclaims space on some virtualization setups or improves wear leveling on SSDs by notifying the underlying device that storage is no longer in use)
                                        0
                                        Да. В зеновскую рассылку я уже написал, ждём ответа.
                                      +1
                                      Проблема далеко не новая, и для нее уже давно есть решение.
                                      Thin Provisioning
                                        0
                                        А, в комментарии выше уже упомянули, не заметил.
                                          0
                                          Спасибо. Прочитал. Издалека выглядит как то, что нужно, но совсем не ясно, с помощью чего это делать.
                                            0
                                            С помощью СХД, делается просто — под данные, которые должны занимать только столько места, сколько реально занято выделяется отдельный лун нужного размера, который фактически занимает на хранилище столько места, сколько на нём записано данных.
                                              0
                                              Мне бы в более техничных терминах. Кто-то создаёт файл большого размера (в локальной FS, для драматизма, допустим, что прямо в '/'). Этот запрос: (вот тут бы мне вписать нужное)…
                                                0
                                                Разбирался с этой штукой года полтора назад, поэтому возможно что-то забыл, пусть комментаторы меня поправят.

                                                Выглядит это так — есть у вас некая СХД (EMC, Hitachi, NetApp, Infortrend — у них у всех это есть). Есть у вас, некая рейд-группа на имеющихся дисках, пусть полезный объем будет 15 Тб. вы берете, и с помощью Thin Provisioning создаете 30 лунов по 1 Тб (условно) и мапите их к вашим виртуальным серверам или вообще куда угодно. Соответственно ваши сервера видят свои блочные устройства по 1 Тб и вообще понятия не имеют, что там на массиве при этом творится. Вся головная боль по распределению и хранению данных ложится на СХД. Если при этом в процессе работы у вас начинает заканчиваться место — вы докупаете еще диски и дисковые полки, расширяете рейд-группу и т.д.

                                                Вся прелесть такого подхода раскрывается в связке с дедупликацией, когда при наличии множества одинаковых виртуалок, реально на СХД занято очень-очень мало места.

                                                Вот как-то так.
                                                  +1
                                                  >Вся прелесть такого подхода раскрывается в связке с дедупликацией

                                                  В случае интенсивной работы виртуалок с дисковой системой, когда кладутся и удаляются большие файлы, необходимо предусмотреть регулярное обнуление свободного пространства, чтобы онво дедуплицировалось и диски на СХД освободились для новых данных.
                                                    +1
                                                    Вот-вот, я про это и говорю: должна быть поддержка команды TRIM на уровне виртуального блочного устройства… Сейчас в рассылку зена напишу.
                                          0
                                          wafl?
                                            0
                                            Опять же не ясно, каким образом место от удалённых файлов будет возвращаться в общий пул.
                                              +1
                                              Регулярное обнуление дискового пространства?
                                                0
                                                ну хранить не виртуальный образ, а напрямую использовать через nfs/smb
                                              0
                                              Veritas File System + Veritas Volume Manager.
                                                0
                                                Изменение размера образа диска по состоянию файловой системы виртуальной машины — прерогатива гипервизора. В качестве виртуального диска выделяется определенный файл, но менять его размер гостевая система не сможет, только гипервизор. То есть подобную функциональность стоит требовать от системы виртуализации, а не от файловой системы.
                                                Думаю, можно создать 10 Тб сжатых нулей и использовать гипервизором в качестве диска, а в гостевой системе удалять данные с заполнением нулями.
                                                  +1
                                                  Вопрос: почему гость не может попросить этого у гипервизора? (да, у гостя есть лимиты, но...)

                                                  Кстати, идея! Ведь есть команда TRIM, которую можно отлично эмулировать (со стороны гипервизора).

                                                  Пожалуй, над этой идеей стоит подумать…
                                                  0
                                                  По-моему автор немного смешал 2 понятия: из ОС у нас может быть доступ на уровне ФС и на уровне блочного устройства.

                                                  Блочное устройство позволяет гораздо больше, например довесить к некоторым типам ФС модули вроде квот, либо вообще сменить ФС, или совсем уж без ФС работать (tar на раздел к примеру или свап), а на ФС — теоретической возможности unerase пока еще неперезаписанных данных. Эти дополнительные возможности САМИ ПО СЕБЕ исключают возможность создания метаинформации о занятости/незанятости определенного места на блочном устройстве.

                                                  Однако чаще всего в типовых виртуалках (VPS/VDS) эти возможности не очень-то и нужны, и вполне достаточно было бы NFS/SMB-like (только с более упрощенным интерфейсом на хост-систему, чтобы не было оверхеда на сетевой стек) файловой системы с чуть более расширенными возможностями, вроде опять же, соответствующих ОС системе прав доступа, квот на иерархию (к примеру чтобы /var не занял все место, что сейчас реализуется размером раздела отчасти)… В принципе что-то вроде этого и реализовано в OpenVZ например, но это конечно же сугубо частное решение в плане ОСозависимости ;)

                                                  В общем, для решения проблемы ИМХО надо думать в сторону отказа от излишней промежуточной эмуляции блочного устройства.
                                                    0
                                                    так а nfs поддерживает упомянутые операции?
                                                      0
                                                      Да, только несколько в иной форме. NFS предполагается «общей» для разных VM: как только один гость удаляет файл, место сразу же доступно для других гостей для записи.
                                                        0
                                                        ну так её же можно реализовать через «паравиртуальный сетевой интерфейс»,
                                                        (paravirtualized network adapter), чтобы избавиться от расходов на лишнюю виртуализацию.
                                                        и будет всем счастие, наверно.
                                                          0
                                                          да, есть такое решение. Проблема только в учёте дисковых операций…
                                                            0
                                                            а какие проблемы с учётом операций?
                                                              0
                                                              Для блочного устройства мы (как гипервизор и особы к нему приближённые) можем точно знать, сколько было iops'ов и сколько байт было передано. В случае в NFS мы не можем знать, сколько IOPS'ов вызвала та или иная операция (точнее, мы не сможем выделить долю клиента в дисковых операциях NFS-сервера).
                                                                0
                                                                вот этот момент мне непонятен.

                                                                разве nfs-серверу не доступна информация какой клиент какие операции совершает?
                                                                разве это проблематично прикрутить?
                                                                  0
                                                                  nfs-сервер не знает, сколько он иопсов делает. Это знает внешний аккаунтинг. А внешний аккаунтинг не знает, какой из запросов NFS кому принадлежит.
                                                              0
                                                              вроде бы в NFSv4 есть учёт операций и даже квоты.
                                                                0
                                                                Квоты — да. А вот учёт операций, если покажете ссылку, буду очень благодарен.
                                                            0
                                                            а хотя какой нафик виртуальный сетевой интерфейс.
                                                            я ч-то-то туплю.
                                                            оно же через rpc работает. а их можно завернуть хоть через локальные сокеты, хоть через чёрталысого, специально адаптированного.

                                                            непонятно только, насколько существенны получатся расходы на rpc.
                                                              0
                                                              Ну, тут изобретать-то особо нечего: виртуальный сетевой адаптер, разворачивающийся в отдельный вилан. Вопрос только в одном: как это считать…
                                                                0
                                                                виртуальный сетевой адаптер съест заметную долю ресурсов на реализацию аппаратной части.
                                                                наверняка реализацию nfs можно существенно оптимизировать, если сделать другой транспортный уровень (не заморачиваясь физическим, канальным, сетевым).
                                                                  0
                                                                  М… Если мы про xen, то нет. Там паравиртуализация всего железа, накладные расходы стремятся к нулю (только на сетевой стек).
                                                          0
                                                            0
                                                            Выглядит как lvm-over-iscsi, динамического пула, с автоматическим выделением и освобождением места между виртуалками не вижу…
                                                            +1
                                                            А можно спросить, какую практическую задачу вы хотите решить? Если я правильно понял по комментариям, все это про облачные хостинги. Тогда какие нужные преимущества для клиентов (или с точки зрения себестоимости?) такой online-resize даст? Может быть, есть другие способы этого добиться. Или не добиваться.
                                                              0
                                                              Ну, очевидное: если вы положили файл на 1Тб на 2 часа (временный дамп) то платить за него за месяц — глупо.
                                                                +1
                                                                А nfs/cifs не подходит, потому что непонятно, как iops клиентов считать? Смотрели вокруг CONFIG_TASK_IO_ACCOUNTING и CONFIG_TASK_IO_THROTTLE? Не чистые iops, конечно, но и клиентам продать это будет сложнее (или невозможно), чем bandwidth до шары.
                                                                  0
                                                                  Ещё не смотрел. За кейворды спасибо.
                                                              0
                                                              >Сторонние утилиты умеют это делать, но не на ходу…

                                                              Dell ExtPart (36кБ, бесплатная) умеет увеличивать размер системного раздела «на ходу»
                                                                0
                                                                Вы неправильно понимаете «на ходу». На ходу — это не когда админ сказал «дайте мне ещё», а когда файловая система обнаружила, что на запрос нет свободного места и попросила ещё.
                                                                0
                                                                Кстати, а AFS разве этого не умеет?
                                                                  0
                                                                  за исключением системного раздела в винде можно и увеличивать и уменьшать разделы
                                                                  вполне очевидно что это долго — ведь надо все файлы с освобождаемого места убрать
                                                                  почему вы удивляетесь?
                                                                  а на линуксе обычно сотни миллионов файлов, вот и 12 часов вам…
                                                                    0
                                                                    Трэд не читал но скажу. Полностью правильное решение должно включать в себя и файловую систему в госте — туда должен прокидываться не блок-девайс а блок-аллокатор. Такого похоже ещё нет.

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

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