У Xenserver 6.2 есть ограничение на максимальный размер подключаемого блочного устройства — 2 Тб. А как поступить если у меня хранилище на 100 Тб. Не подключать же 50 блочных устройств?
Не блочное. Но автор пока не объяснил, зачем ему именно «блочность», а в реальной жизни задач, для которых нужно только блочный доступ к секторам диска и никак иначе — не так много.
Так дофига это, 100 TB, если это не домашнюю коллекцию фильмов хранить. Емкость-емкостью, но вам же это читать и писать придется.
Впрочем, если вы про MD3, тогда возможно и потянет. Но все равно, учитывайте, что если речь идет не про архивное хранение, то… 100TB дисками-то поди SATA на 4TB?
А что мешает подключать хранилище к гостю, а не к хосту? Пусть гость знает, что это iscsi или nfs. Хосту вообще будет неведомо, для него это будет сетевой трафик.
Ну вот судя по всему так и придется делать, потому как иными способами достичь 50 Тб на виртуальную машину не получается. + немного нужно будет поиграться с multipath на гостевой машине.
Вы главное не забывайте, что «поддерживает» неравно «работает». Оно может работать так, что вы сами этого не захотите.
Чем вы будете эти 100TB защищать от дисковых сбоев? RAID-6? Какой длиной группы? С какими дисками, какой емкости?
Мне кажется, что вопрос «как подключить» в данном случае не настолько важен, как то, что вы будете с ними делать и как. Если вы найдете для себя ответ на этот вопрос, то может и подключать уже ничего будет не надо. Так что правильно поставленный вопрос — половина ответа. :)
Впрочем, ответ уже явно выходит за рамки заданного автором вопроса.
track, я с Вами полностью согласен. Работа с разделами таких размеров не всегда тривиальная задача. Одному из наших подразделений необходим FTP сервер/CIFS для хранения «сырого» видеоматериала. 50 Тб они выберут немного более чем за год. Загрузка/выгрузка видео будет производиться через специализированное ПО (видео менеджер). На вопрос о том, нормально ли он пережует раздел такого размера был получен ответ — нормально. А как по другому отдать столько места под хранение? Диски по 3Тб, RAID-6, группа — 20 дисков.
Что касается multipath на гостевой машине, то у хранилища два контроллера и без multipath я смогу работать только с одним контроллером и при выходе его из строя получим недоступность всего сервиса.
Спасибо, это важное дополнение, про характер и способ доступа, потому что по дефолту предполагается (мной по крайней мере), что это будет рандом мелкими блоками, как обычно и работает большая ферма виртуализации, на таком workload такой сторадж загнется сразу же, а в вашем случае, скорее всего, будет нормально, по крайней мере сам сторадж такую задачу потянет.
Интересно, а сам видеоменеджер не умеет работать с пространством, разбитым на множественные разделы?
Но, откровенно говоря, все проблемы вы начали с того, что взяли неправильный инструмент. Завинчивать гвоздь отверткой и забивать шуруп кружкой — неудобно :)
На самом деле вам нужен под эту задачу NAS, а не iSCSI storage. При стоимости решения на 100TB я бы на вашем месте пересмотрел бы выбор стораджа, если это возможно. Сейчас вы с большими потерями и неизбежным оверхедом просто делаете из него это же самый NAS, вместо того, чтобы пойти и взять уже готовый.
Все верно, но… Этого не было указано ранее, хранилище приобретается не только под эту задачу. Хранилище забито емкими и относительно медленными дисками для медиа хранилища, быстрыми SAS для виртуализации, и др.
Ну и NAS наверное не дал бы такой гибкости. Например, возьмем Win Server 2008, подключим к нему блочное устройство. На нем будет внутренний сервис FTP+CIFS. С помощью AD можно будет очень гибко реализовать политики доступа.
Ну почему вы так думаете? В современных NAS есть все это, и работает ничуть не хуже, чем в Windows.
Просто вы идете к цели кружным путем. Вам нужен файловые пртоколы на много дисков. Но вместо прямого пути — NAS, вы берете отдельно блочный сторадж, а потом превращаете его в NAS внешним сервером. По мне так прямой путь имеет меньше оверхеда, как в производительности, так и в деньгах.
Да я не сомневался, я хорошо помню ваш след на этом ресурсе, спор по поводу мегабайтов и этих ублюдских мебибайтов, по поводу софтраидов RAID6 в линуксе и так далее ;)
Я же не зря зря попросил «нормальную поддержку SMB2». Неужели кто-то сделал? С другой стороны, шесть лет уже прошло, могли уже и сделать…
Если говорить о задаче в целом, то необходимо получить виртуальную машину (Linux) с дисков 50 Тб. Первый вариант решения: подключение LUN'а такого раздела к Xenserver, а потом отдача его виртуальной машине. Но есть описанные выше ограничения. Второй вариант: создание вирутальной машины с небольшим диском и подключение LUN'а непосредственно к ней, минуя Xenserver.
RDM, Raw Device Mapping, это вообще не сильно рекомендуемое любым вендором гипервизоров решение. Надо смотреть на ограничения в XenServer для такого варианта.
А вариант сделать столько сколько надо LUN-ов, а потом в каком-нибудь LVM в VM, раз у вас все равно Linux, слепить из них что надо, хоть простым concatenate — не подходит?
Такого ограничения нет в XenServer. Я подключал луны и по 20 Тб как по iSCSI так и по фибре. Ограничение в 2 Тб имеет место быть в отношении проброса vdisk'а внутрь VM, и то, через консоль руками, это обходится.
