Опыт эксплуатации Nexenta, или 2 месяца спустя

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


    напомню, Nexenta — это такой коммерческий софт для систем хранения данных, на базе ZFS/OpenSolaris. Умеет много что, но нам надо что бы он кормил по iSCSI наши ноды виртуализции под KVM и Hyper-V/Windows 2008 HA Cluster — с дедупликацией, кэшем и всеми остальными пряниками.
    Машину собрали годную, 36 дисков по 300Gb SAS 15K, нашли 300Gb SDD Intel 710 серии (круче некуда на тот момент) и так далее.

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

    Стали мы переносить туда виртуальные машины с кластера Hyper-V/Windows 2008 R2. А надо сказать их много довольно, несколько сотен и размер у них не маленький — 20Гб в среднем. Есть по 5Гб, а есть и по 200.

    Кластер мы разделили, старый был в старом ЦОД, а новый кластер мы собрали уже в новом. Поэтому мигрировали не по локалке, а через ВЛАН на нескольких сотнях мегабит — миграция ВМ с 200Гб диском затягивалась на несколько часов.

    Все бы ничего, но первый косяк мы словили уже через неделю — по мере миграции на Нексенте кончилась память для таблицы дедупликации. Надо сказать, что в Нексенте таблица дедупликации относится к пулу дисков, а не к конкретному тому. Если память кончается, то это не значит, что умная система заранее отключит модную фичу. Умная система войдет в ступор с деградацией производительности на порядок-два. Т.е. если раньше вы гоняли тела ВМ со скоростью 80-90МБ/с через гигабиттный порт, то теперь это будет 3-4МБ/с и 200-300 IOPS на всех.

    Что получается, на каждый блок ФС в пуле Нексенте надо примерно 500 байт в памяти для таблицы дедупликации. Если у нас в системе 128Гб памяти, Нексента может хранить инфу про 256 000 000 блоков:
    максимальный размер занятого пула на 4К блоках — 1Тб, на 16К блоках — 4Тб, на 32К блоках — 8Тб и на 64К блоках — 16Тб. Запишите это красным маркером на стене! Зайдете за границу и прощай премия =)

    Если не так задали размер блока в самом начале — ничто не поможет, кроме миграции на новый том с правильным размером. Если вы выключите дедупликацию, ничего само не произойдет. Таблица дедупликации некуда не денется, в том числе и из памяти. Все что можно будет сделать, это создать еще один новый том без дедупликации и копировать туда старый. Да, если у вас переполнена таблица ДД на этот момент, то копироваться он будет примерно со скоростью 3-4Гб в минуту. В нашем случае том был примерно 4Тб размером, миграция (zfs send / zfs receive) заняла около 16 часов. Потом мы стерли том с дедупликацией, через пару часов машине полегчало настолько, что мы смогли все запустить в работу.

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

    Еще про дедупликацию на блочном уровне. Это не работает, забудьте. Держа на массиве с блоками (sic!) 4Kb сотню клиентских ВМ .vhd собранных с 3-4 шаблонов мы ожидали, что будет как в книжке про NetApp, коэффициент 8-10. Этого не вышло, dedup ratio был около 2-3. Т.е. включение базовой компрессии приводит к схожему результату – 40%. Для достижения коэффициентов 8-10 вероятно надо использовать офлайновую дедупликацию с ползучим по размеру блоком. Это как в storage pools новой Windows 2012 или ONTAP.

    Дальше больше. Выключили дедупликацию, все завелось. Тома крупные, по 7Тб каждый. Продолжаем миграцию ВМ Hyper-V со старого кластера на новый, замечаем на MRTG — скорость записи снижается. Не сразу, потихоньку. За сутки миграции со скоростью 50-60МБ/с раза в два.

    Почему? Тут всплывает второй косяк, не описанный в маркетинговых материалах сразу. Стоит ZFS пулу заполниться, как он радикально деградирует по производительности. Более 30% свободного места это не бросается в глаза (но видно на графике), с 30 до 10% все работает раза в три медленнее, а если места становится менее 10% — все работает на порядок медленнее.

    Мораль, следите за местом. Если места на пуле не станет, это будет катастрофа – придется аварийно расширять пул упираясь в диски/полки/лицензии или мигрировать данные на соседние СХД/локальные диски нод. Нексента чувствует себя в добром здравии, если у нее свободно более 30% места – планируйте это при расчетах серверов.

    Но это не самое неприятное. Самое неприятное — это когда Hyper-V теряет quorum диск или весь Cluster Shared Volumes на 4Тб кормящий три крупных ноды и не получается никакими силами хотя бы его смонтировать на одну из нод. Как достичь такого волшебного результата: поставьте на один том CSV сотню ВМ под Виндой, запустите их и начните мигрировать еще несколько ВМ на этот том. Сначала все бодро копируется, потом процесс копирования замирает, а потом у вас отваливается CSV. Да, на всем кластере. При этом таргеты будут видны, но смонтировать с них том не сможете.

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

    Это касается только Hyper-V/Windows 2008 R2 и не касается KVM. Это не касается Starwind – он ровно работает в таком режиме. Наше мнение – iSCSI Винды 2008 и Нексента между собой не совсем совместимы, массовые параллельные записи/чтения приводят к локам, таймаутам и сбоям. Никто нам ничего внятного в поддержке обеих компаний не сказал. На форумах говорят, что некоторые патчи помогают Винде в ряде случаев, что тип LUN надо менять и т.п.

    Дальше, апгрейд системы на Нексенте требует ее перезагрузки. Если нет высокодоступного кластера из СХД, готовьтесь объявлять технические работы или мигрируйте все ВМ на соседние хранилища. Имейте это ввиду, changelog между версиями Нексенты громадный.
    Дальше, дисковый пул Нексенты в идеале должен состоять из одинаковых дисков, собранных в одинаковые raid-группы. Вы не сможете в дальнейшем расширять эти группы или менять в них тип raid.

    В общем примерно такие впечатления от Nexenta через 2 месяца работы. Сейчас у нас Линуксовая виртуализация довольно ровно и быстро работает с Nexenta, Кластер Windows 2012 работает со Starwind и мы тестируем механизм и скорость Storage Pools SMB 3.0 для использования их для организации высокодоступного CSV. Да, там работает оффлайновая дедупликация и мы видим хорошие коэффициенты, но это тема другой статьи.

    Из общих соображений производительности и IO pattern. Для задач VPS не нужны SAS диски в пуле, нам бы хватило 12 SATA дисков по 1Тб. Мы планировали что все будет с дедупликацией, а вышло без. Знали бы заранее — денег бы сэкономили. Дисковый монитор там удобный, по нему сразу видно сколько операций на диск приходится. SSD в кэш должен быть серверного класса, на нем постоянная серьезная нагрузка и по чтению и по записи.

    А как у Вас эксплуатируется Нексента под нагрузкой с томами в десятки Тб? Без нагрузки у всех все красиво.
    HOSTKEY
    Company
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 38

      +1
      Это не работает, забудьте. Держа на массиве с блоками (sic!) 4Kb сотню клиентских ВМ .vhd собранных с 3-4 шаблонов мы ожидали, что будет как в книжке про NetApp, коэффициент 8-10. Этого не вышло, dedup ratio был около 2-3. Т.е. включение базовой компрессии приводит к схожему результату – 40%. Для достижения коэффициентов 8-10 вероятно надо использовать офлайновую дедупликацию с ползучим по размеру блоком. Это как в storage pools новой Windows 2012 или ONTAP.

      Хммм. А у вас партиции получившихся из шаблонов VM точно выровненные? Вроде как 2012 выравнивает правильно по умолчанию, а для 2008 и R2 надо предпринимать действия.
      В вашем случае сильно похоже на сбитое выравнивание, поэтому дедупликация не может найти идентичные блоки (все те, что должна найти).

      Кстати у NetApp тоже дедупикация с фиксированным блоком, чистый оффлайн с переменным блоком делался, но так и не вышел в свет, в связи с закрытием компанией направления VTL.

      Машину собрали годную, 36 дисков по 300Gb SAS 15K, нашли 300Gb SDD Intel 710 серии (круче некуда на тот момент) и так далее.

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

      Стоит ZFS пулу заполниться, как он радикально деградирует по производительности.

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

        Хм. А чем брэндовый сервер помог бы автору топика в его проблемах с Nexenta? Аж ничем.
          0
          Я не про брэндовый сервер, а про брэндовый сторадж с соответствующей функциональностью «из коробки».
          Впрочем, я уже посмотрелответ в более ранних постах, там называлась сумма в примерно 12 тысяч долларов.
            0
            А, простите, не так понял. Если я правильно понял этот сервер обошелся в 300К руб, сомнительно чтобы можно было найти даже БУ бренд на ебее за такие деньги, и это еще без учета доставки…
              0
              Да, цена-то хорошая, только работает… вот так… через раз ;)
                +1
                Ну почему так себе… про переполнение таблицы дедупликации и деградацию ZFS должно быть сказано в документацию на Nexenta — если это не так — то да, минус им — но вообще ничего военного.
                Апгрейд системы требует перезагрузки? Пффф… Скажите спасибо что не бекапа всех данных — это вполне обычное требование для СХД.
                В сухом остатке — только проблемы связности iSCSI в Nexenta и Windows — при том что линуксовая версия работает нормально.
                  0
                  Все это конечно хорошо, в качестве сферических рассуждений в вакууме, но на практике обычно вопрос ставится «чтобы к утру работало, не то попадос на бапки списываем с виновного, того, кто это чуда нас уговорил купить»

                  Про отсутствие проблем с Linux отчасти радует, конечно, но у меня сложилось ощущение, что HOSTKEY это преимущественно Windows-хостинговая компания.
                    0
                    Так было с прошлом году, сейчас примерно 50/50 винда и линукс. С вводом в работу солусВМ мы закрыли эту тему на 100%. А новый control center наконец позволит нам пускать внешнего клиента в коньрольную панель с выделенными ресурсами.
                      0
                      Ну почему сферических в вакууме? в статье описан реальный опыт, а документацию надо читать хоть на нексенту, хоть на нетапп, хоть на емс, хоть на что… А по поводу «попадос на бабки» — так не вопрос, похожий по характеристикам NetApp та ебее, правда с FC — 40K, пусть ISCSI будет 30К — «nobody was fired for bying IBM», бабки на стол и нет вопросов. :)
                      Хотеть дешевле — есть дешвле, но сам топчешься по своим граблям. Стоит ли оно того? Для небольших компаний — однозначно стоит имхо. крупным же легче купить готовое за пару-тройку лимонов… Peace :)
                      +1
                      Мне не нравится что в нексенте напрочь отсутствует защита от неверной настройки и аварийные отбойники. Это большой минус, можно заложить себе мину и потом не иметь возможности это исправить. Бакап-то мы держим, но не силами нексенты, а силами DPS и solusVM
                      0
                      Работает ровно, но в определенных режимах и под наблюдением. Аналогичная ISCSI полка с ssd и 36 дисками обошлась нам бы минимум в 30-40к баксов.
                      Только б/у Netapp если с ебэя взять за 10к баксов схожей емкости, но есть вероятность что он не случайно на ебее оказался…
                        0
                        Там с нетаппом есть существенная засада. Дело в том, что лицензии там non-transferrable, то есть вы теоретически получаете при покупке used — только голое железо. Которое можно, например, использовать для починки и расширения своего законно купленного. Но официально used-систему нельзя продать с «софтом».
                        Да, существуют способы это обойти так или иначе, но «буква закона» такова, к сожалению. лицензии продаются на конкретное имя (компании) и на конкретный номер purchase order.

                        А так — оказались они там на ебэе потому, что народ их активно юзает и активно апгрейдит, это очень популярный в америках сторадж.
                          0
                          Мы с Германии таскаем, но там копирастам надавали по рогам за такие ограничения как я понимаю. Так что если апгрейда не будет, то и не страшно. А запчасти там же можно брать
                            0
                            Это в Америке. В Европе легально купить б/у с софтом.
                              0
                              Купить-то можно и в Америке, но мнение NetApp по поводу того, кому были проданы лицензии это не меняет. :)
                                0
                                НургалиевЕвропейский суд разрешил, NetApp просто не может продавать в Европе non-transferrable лицензии AFAIK…
                                  0
                                  Ну если Нургалиев… Впрочм, я знаю, что все эти решения суда обычно написаны юридическим языком и обложены десятками сложно понимаемых условий, так что я бы не был столь однозначен и не радовался по одному факту того, что кто-то чего-то «разрешил». Реальность как всегда бывает сложнее схем.
                  0
                  По поводу выравнивания — я не видел там таких вариантов, мы храним ВМ в виде тонких .vhd, а линуксовые сидят в LVM по тому на машину. Подскажите где смотреть?
                    0
                    Ну я не спец по Нексенте, но уверен, что их партнеры в курсе проблемы.
                    Идея там в том, что смещение начала партиции должно укладываться в число, кратное размеру блока.
                    Допустим размер физического блока у дисков 4KB (ну или 512b, «по старому»), размер блока у ZFS тоже, допустим, 4KB.
                    А вот стандартное смещение первой партиции относительно физического начала диска у старых Windows 32762, что не делится нацело на 4096, таким образом получается, что блок 4KB у NTFS лежит началом в одном блоке ZFS, конец — во втором, и так далее. Из-за этого смещения, особенно если оно не совпадает у разных VM, получается так, что блоки ZFS, несущие один и те же файлы, из за вот этого вот смещения положенных поверх них блоков NTFS, не совпадают содержимым, когда дедупликация в них считает их хэши.
                    Заодно правильное выравнивание помогает наковырять процентов 10 производительности в ряде workloads, и уменьшить занятость памяти контроллера, не радикально, но бывает полезно.

                    Впрочем, я вот сейчас посмотрел на свежеустановленную 2008R2 SP1, она поставилась со смещением 105 906 176, что на 4096 нацело делится. Так что моежт я зря вам поклеп возвожу. Также правильно теперь ставится автоматом Server 2012.

                      0
                      Не спец в винде, но в 2008R2 SP1 уже вроде как с выравниванием все ок.
                        0
                        А, значит это результат интегрированного SP1 в моем дистрибутиве.
                • UFO just landed and posted this here
                    0
                    Да, про деградацию скорости работы zfs только ленивый не пишет в интернетах.

                    Скажите, у вас под кеш zfs один ssd или несколько?
                    Почему подключали через адаптек, а не напрямую в мать?
                    Какое стоит значение ashift?
                    Проводился ли эксперимент с физическим вытаскиванием в процессе работы дисков из стораджа? Если да, то что происходит в этом случае?
                    Расскажите какой тюнинг операционки производился?
                    Спасибо!
                      0
                      Кэш один, несколько дисков подключены через адаптек так как Нексента не видела встроенного sas контроллера на матери, пришлось поставьть hba имени адаптека. К матери ничего не подключил — все должно быть хотсвопным, а на матери таких портов нет.
                      Эксперименты мы проводили на холодную, и вытаскивали и полки подключали.
                      Тюнинга специального не делали, только один раз увеличили руками размер таблицы дд.
                      0
                      У нас Нексента от локального вендора, тоже на кучу проблем напаролись. Главная — низкая скорость «на выходе» через iSCSI.
                        0
                        А вы подробнее напишите, что за Нексента, куда таргеты цепляете, для чего используете
                          0
                          Смотрел нексенту. Был глубоко поражён тем, насколько плохо солярис отрабатывает дисковые ошибки уровня шины. (mpt2sas у них ещё хуже того, что в ванильном линуксе).
                            0
                            Ламера. Все это описано в документации и на форумах. Читать надо внимательно и продумывать сайзинг перед внедрением. С таким подходом с любым решением проблемы будут.
                              0
                              Нука, подробнее — где про отличную совместимость видны и нексенты написано на форумах? Сами что эксплуатируете? Напишите конфиг и тип задачи.
                                +1
                                Совместимость comstar таргета и инициатора в новых серверных виндах это только один пункт из ваших «шокирующих деталей». Причем пока кроме как у вас нигде больше я не встречал. Нормально работает даже с MPIO.

                                Про дедупликацию в user guide написано в каждом разделе: «Use this parameter with caution, because it utilizes RAM resources intensively.» Насколько intensively написано в интернетах чуть ли не на каждом углу. Например, в блоге у Гонзалеса:
                                constantin.glez.de/blog/2010/03/opensolaris-zfs-deduplication-everything-you-need-know
                                constantin.glez.de/blog/2011/07/zfs-dedupe-or-not-dedupe
                                Поэтому не составляет никакого труда просчитать размер ARC и/или L2ARC для дедуплицированного тома.

                                Деградация производительности CoW файловых систем при полной заполненности это нормально by design. Поэтому в том же NetApp мануале и во всех admin guides по ZFS написано о необходимости оставлять 30% свободного места. Прочтите хотя бы официальный админ гайд по ZFS от сана/оракла или серию статей на сайте нексенты.

                                Про апгрейд с ребутом вообще непонятно, вы ожидали чего-то иного при обновлении software-defined стораджа?

                                У нексенты масса нерешенных проблем, что-то вроде iSCSI hangs on heavy IO load, удаление дедуплицируемого тома и прочие. Часть из них пофиксили в 3.1.4, часть в 4й ветке. Но вы не описали ни один их них. Все эти «шокирующие детали» результат плохого знания мат.части и недостаточно глубокого анализа выбранного продукта.

                                P.S. Да и intel 710 не самый прям распрекрасный вариант. Это лучший из дешевого.
                                Сам использую nexenta как быстрый и дешевый сторадж для некритичных и тестовых данных на шасси HP DL180G6 с 25 SAS 300GB 10k rpm и 64GB RAM на кластере из 5 хостов ESXi. В продакшене связка из 2х Dell EqualLogic PS4110XV с синхронной репликацией.
                            +2
                            Имею опыт. Более нескольких лет. Хочу добавить.

                            1. Не используйте дедупликацию в продакшене. Вообще. Фича из разряда «никогда не пользоваться». Каждый раз, когда она была включена, это заканчивалось пересозданием пула. Ибо все работает несколько месяцев, потом полная деградация производительности. Даже на пуле с давно выключенной дедупликацией. На машинах с 128-192-384Гб + l2arc 400-800Гб SSD.
                            2. Не используйте Нексенту с 16-32Гб в продакшене. Только для бэкапов. Все правильно пишут насчет zfs likes RAM. Ввиду cow (что по моему мнению не совсем корректное название, copy-on-write — это как раз про стандартные блочные устройства со снапшотом, где данные именно копируются при изменении _части_ блока, что приводит к деградации производительности, здесь просто запись в новое место) запись происходит всегда последовательно, что, в свою очередь приводит к фрагментации. И нужен большой кеш на чтение. Очень большой.
                            3. Так за много лет и не определился — выключать ли prefetch. С одной стороны, трата памяти и лишние iops, с другой — попадания все же есть. Интуитивно — много памяти, маленькая нагрузка — оставлять. Большая нагрузка — выключать, ибо пользы мало. По ощущениям и статистикам — радикального изменения не наблюдается.
                            4. Касаемо виртуализации. Не знаю насчет HyperV, не пользую, для esxi — не используйте один большой lun. Все-таки iscsi reservations, будь они не ладны, сильно дегрейдят. Было древнее правило (точно не помню) 5-10-20. 5 высоконагруженных машин на лун и т.д. Уже все гораздо лучше, но общий принцип остался. То есть 200-400 вм на одном луне совсем не есть хорошо, как оказалось. Да и не проблемы это нексенты, это проблемы vmfs.
                            5. Касаемо сжатия. Есть два фактора: увеличивает производительность на чтение (меньше нужно читать), увеличивает фрагментацию (блок переменного размера). Эти два фактора взаимоподавляют друг друга. Фиг его знает, но всегда держу включенным. По ощущениям (zpool iostat) проявляется только при недостатке места. В виде увеличения iops на чтение и снижении производительности (в мб/с). Включать, естественно, zip9 не надо, нужно самый простой.
                            6. Естественно, все говорят в интернетах про raid-10, не наблюдаю такого, есть две идентичные системы по 40+ дисков, в одной raid-z1, в другой raid-10. raid-z1 иногда даже лучше по производительности, нагрузка одинаковая. Наверное, нужно подробнее разбираться почему. Было просетаплено исключительно из-за места. Ожидался дегрейд производительности. А нет его.
                            7. Про VAAI. Ранее (версии 3.0) совокупно с iSCSI приводили к падению. Так и не понял, пофиксили или нет, в высоконагруженном кластере выключено, в так себе — включено. И работает. Непонятно, хотелось бы отзывов.

                            Тут еще есть, просто всего не упомню. Общее впечатление: лучшее, что есть. Рвет по производительности (в разы) коммерческие системы, но есть проблемы, куда без них. К сожалению, они (грабли) не описаны. Например, про сервера HP: www.nexentastor.org/boards/2/topics/8941
                            Да и много чего.

                            Опыт основан на серверах HP с 16+ дисков (иногда 100) и 128Г+ памяти (иногда 384Г), esxi + iscsi (иногда nfs), Есть опыт использования HA cluster (пока не продакшн, но ведет себя достойно. можно спокойно нажать ресет, ничего не падало пока).

                            Буду рад пообщаться насчет нексенты, дома не использую, поэтому врядли смогу ответить на вопросы вроде «хватит ли 16Гб для дедцпликации». Скорее всего нет.
                              0
                              А какой обьем данных у вас дедуплицировался при проблемах?
                                0
                                Как быстро переключается HA кластер на резервную ноду? Меняли ли таймауты в гипервизоре?
                                Какая конфигурация нод? Какой плагин используете (simple или полноценный)?
                                Используете 3.1.3.5 или уже обновились на 3.1.4?
                                  0
                                  По поводу VAAI+ESXi тред здесь nexentastor.org/boards/1/topics/3273 Возможно вы пропустили?!
                                    0
                                    P41X использовать для нексенты имхо совсем не стоит. Лучше уж купить нормальный LSI HBA, а 41X продать страждущим.
                                    Как кстати raid-z1 в продакшене? Не страшно за пул? Как собирали vdev'ы по сколько физ. устройств? В любых raid производительность vdev на запись будет равна производительности 1 (одного) диска, поэтому интересно посмотреть как сильно вы делили ваши 40 устройств на vdev'ы.
                                    0
                                    > Если места на пуле не станет, это будет катастрофа – придется аварийно расширять пул

                                    Для ZFS расширение существующего пула никогда не было аварийной ситуацией. Это её свойство «расширяться», делается просто и безопасно без отмонтирования ФС в пуле.

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

                                    Это да, в идеале. Но ZFS пул позволяет собирать отдельные VDEV в различные группы RAID или использовать единичные устройства подходящей ёмкости, которые впоследствии можно дополнить до mirror VDEV. Для добавления в пул VDEV с отличной от нормальной схемы построения групп накопителей, используемых в пуле, есть опция командной строки, разрешающую данную ситуацию.

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