У меня есть сервер CentOS 7, который в настоящее время получает хранилище через подключенный многопутевой сеанс iSCSI. Многопутевое устройство, представляющее это блочное хранилище в /dev/mapper монтируется в папку в /mnt/x
Выполняется серверное приложение, которое можно настроить с использованием только одного пути к папке для использования в качестве хранилища, в настоящее время указывающего на /mnt/x
Моя проблема в том, что это приложение использует огромный объем памяти. В настоящее время iSCSI LUN составляет 50 ТБ, и нам необходимо расширять его каждые несколько месяцев.
Мне интересно, есть ли способ представить несколько небольших iSCSI LUN через многопутевый доступ к этому серверу и каким-то образом объединить хранилище, чтобы они отображались как одна точка монтирования /mnt/x?
Я знаю, что есть такие решения, как mhddfs но все они, похоже, работают с локально подключенным хранилищем, и, кроме того, я недостаточно играю, чтобы опробовать их с таким объемом данных. Фактическое решение, которое они представляют, отлично подойдет для моего случая, поскольку оно может хранить файлы, создаваемые приложением, на нескольких LUN, что позволяет избежать ситуации, когда при отключении одного LUN вся точка монтирования перестанет отвечать, как это может быть в случае с LVM.
Я хочу попытаться избежать одного огромного LUN, я реально могу увидеть этот подход на 100 ТБ в ближайшие месяц или два, поэтому я хочу посмотреть, смогу ли я спланировать заранее.
Поскольку вы используете CentOS, вы можете рассмотреть возможность использования GlusterFS. Теперь он поддерживается RedHat и может быть легко настроен. Посетите их веб-сайт для получения дополнительной информации.
Я не могу придумать единого решения, из которого можно было бы случайно удалить LUN, которое обеспечивает конкатенацию блочных устройств в стиле JBOD, как вам нужно. LVM - это моя первая мысль, но если вы потеряете любую из этих многочисленных точек отказа, ваша VG будет в ухудшенном состоянии, и у вас, вероятно, возникнут проблемы с данными.
В этом случае вы можете рассмотреть совершенно другой подход. Прямо сейчас вы вручную расширяете тома, чтобы удовлетворить потребности предположительно нескольких конечных точек. Почему бы не предоставить этим конечным точкам большие тома с тонким выделением ресурсов и не переместить проблему управления в центральное место, удобное для управления хранилищем?
Правда, вам придется не отставать от добавления хранилища к цели iSCSI, но это обычно более изящно, чем конечные точки, и может быть выполнено, когда на ваших томах действительно мало места. Я говорю все это обнадеживающим тоном, потому что я не знаю, нужно ли использовать какой-то ужасный продукт SAN за всем этим, который не будет делать простых вещей, таких как расширение объемов в Интернете.
Имея это в виду, мне любопытно, какой продукт вы на самом деле используете для своей SAN, поскольку это была бы важная информация для определения того, как вы могли бы эффективно справиться с этой проблемой.