LINUX.ORG.RU
решено ФорумAdmin

Нарезка iSCSI+LVM под виртуалки

 , ,


2

2

Есть у меня iSCSI сторадж, там нарезаны тома, подключены к серверам, разбиты в LVM и скормлены виртуалкам.
Хочу нарезать тома помельче, что бы без промежуточного LVM на хостовой машине - напрямую отдавать небольшие тома виртуалкам.

В плюсе - удобство управления и миграции.
Как минус - я не знаю, как правильно их скормить kvm'у к примеру:

<disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/dev/disk/by-uuid/f06ba262-4331-47ca-87d3-e6d056a7631d'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>
или как-то иначе.

Насколько «иделогоически верен» тот и другой вариант?

Спасибо за внимание.

★★★★

что бы без промежуточного LVM на хостовой машине

Так и надо. Со стороджа для каждой виртуалки свой том (lun). В виртуалку так и заноси как в твоем примере.

sdio ★★★★★
()
Ответ на: комментарий от sdio

так не надо, количество LUNов ограничено, а LV можно нарезать сотнями тысяч. LUN-ы надо выделять по мере надобности, и в зависимости от потребностей VM, какие-то с десятого рейда, какие-то с пятого (например). А тупо резать очень много томов - можно очень быстро потеряться в них, или упереться в ограничения SAN или device-mapper.

dyasny ★★★★★
()

идеологически, отдавать VM отдельный LUN нужно если на нем строится кластер (и то не обязательно, libvirt позволяет шарить диски между виртуалками), при обычных нагрузках, нет ничего плохого в большом томе, порезанном на LV для разных машин.

доступ к ним лучше всего отдавать в форме /dev/mapper/WWID, так же как и к LV самое верное отдавать через /dev/mapper/VG-LV

dyasny ★★★★★
()
Ответ на: комментарий от sdio

читаем спеки данной модели СХД

в софтовых таргетах ограничений может и не оказаться (в LIO например их нет), но управлять такой кучей тоже может стать накладно. Проще отдавать LUN сгруппированным по релевантным признакам виртуалкам или даже их дискам, и нарезать LUN уже при помощи LVM под сами диски.

Кластеризация, а точнее одновременный доступ тогда тоже намного проще - все хосты видят все LUNы, но только тот хост где бежит VM перед запуском прогоняет lvchange -ay по нужным LV, a когда VM опускается или мигрирует отключает себе доступ. Тогда никаких кластерных FS не нужно, и масштабируется такой кластер до тысяч хостов и дальше.

dyasny ★★★★★
()
Ответ на: комментарий от dyasny

такой вариант мне не нравится. перенесено управление с схд на сервер, ну будешь путаться в сотнях lv. и надо менять дефолтные настройки, добавляя запуск lvchange и обработку ошибок если lv busy по каким-то причинам

sdio ★★★★★
()
Ответ на: комментарий от sdio

перенесено управление с схд на сервер

почему это проблема? все равно надо подключаться

ну будешь путаться в сотнях lv

не буду, ведь у меня получится несколько LUNов с набором LV на каждом, эдакая иерархия и группирование, чего просто на СХД сделать сложнее (разве что по таргетам их распихать, но и это не совсем комильфо)

и надо менять дефолтные настройки, добавляя запуск lvchange и обработку ошибок если lv busy по каким-то причинам

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

oVirt как раз так и делает (хотя там есть возможность создавать прямые подключения к LUNам как к дискам для VM), и за счет такого подхода может строить огромные кластеры, тогда как vmware и ms до сих пор торчат на уровне 32 хостов и не более, плюс идиотские проблемы с persistent reservations

dyasny ★★★★★
()
Ответ на: комментарий от dyasny

почему это проблема?

Это не проблема. Это ты выдал за преимущество перенос управления томами с СХД на сервер

но управлять такой кучей тоже может стать накладно. Проще отдавать LUN сгруппированным по релевантным признакам виртуалкам или даже их дискам, и нарезать LUN уже при помощи LVM под сами диски."

вместо кластерной ФС

Откуда взялась кластерная ФС?

У меня схема простая:

СХД --> LUN1 --> server1 --> kvm_virtual_machine1 (online)
    --> LUN2 --> server1 --> kvm_virtual_machine2 (online)
    .....
    --> LUN1 --> server2 --> kvm_virtual_machine1 (standby)
    --> LUN2 --> server2 --> kvm_virtual_machine2 (standby)

Миграция происходит в живую одной командой (virsh migrate)

Ты предлагаешь так:

СХД --> LUN1 --> server1 --> VG1 --> LV1 --> kvm_virtual_machine1 (online)
                                 --> LV2 --> kvm_virtual_machine2 (online)
    .....
    --> LUN1 --> server2 --> VG1 --> LV1 --> kvm_virtual_machine1 (standby)
                                 --> LV2 --> kvm_virtual_machine2 (standby)


Как мигрирует в твоем случае машина с одного сервера на другой?

sdio ★★★★★
()
Последнее исправление: sdio (всего исправлений: 1)
Ответ на: комментарий от sdio

что означает «standby»? машина висит в паузе? или статус тома в multipath?

миграция осуществляется очень просто - нa destination делается lvchange, virsh migrate, lvchange на source. никаких standby нигде, все хосты видят все релевантные LUN-ы, но попортить данные не могут, так как LVM не пускает.

на стороне СХД я делаю несколько больших LUN, под разные задачи (по типам дисков и уровням raid, некоторые с репликацией, некоторые без и т.д.), и на них раскладываю диски VM. LUN под диски ОС один, с дедупликацией, LUN под диски SQL другой - быстрый raid10 на 15к SAS или SSD. LUN под темплейты машин третий, с большими SATA дисками. Короче все удобно и сгруппировано по задачам, масштабируется ad libitum и легко разобраться, при создании новых VM, какие диски от нее куда класть. Можно похожее делать на СХД на уровне raid-group, нарезав группу на LUN-ы, но тогда теряется контроль. У меня пользователь (или админ-джуниор) может спокойно сам создать себе виртуалку, с дисками расположенными там где они должны быть, не трогая меня и не имея доступ к СХД, в пределах своей квоты на LUN-ах.

dyasny ★★★★★
()
Ответ на: комментарий от sdio

количество LUNов ограничено

Кстати, не только кол-во lun конечно. Есть такое понятие, как размер очереди на фронт-энд порт, так вот он тоже ограничен. У мидренжа это 512 обычно, а если виртуалок, например, 250 или более, то производительность может оказаться в такой опе, что мало не покажется.

EvgGad_303 ★★★★★
()
Ответ на: комментарий от EvgGad_303

OK, принято. Не думаю что это случай ТС'а, но все же.

Кстати, если речь идет о iSCSI, то на один гигабит все-равно много не посадишь, т.е. придется раскидывать по разным сетевухам либо башлять за 10G, но это не только сетевуха, но и вся инфраструктура.

sdio ★★★★★
()
Последнее исправление: sdio (всего исправлений: 1)
Ответ на: комментарий от dyasny

У меня пользователь (или админ-джуниор) может спокойно сам создать себе виртуалку, с дисками расположенными там где они должны быть, не трогая меня и не имея доступ к СХД, в пределах своей квоты на LUN-ах.

Согласен.

sdio ★★★★★
()
Ответ на: комментарий от Yustas

что за сторедж такой - всего два портала, да еще и актив/пассив? гиговые entry level, работающие в режиме RDAC, и те идут с как минимум 8-ю порталами, а 10g я меньше 4-ех порталов не видел, даже в том самом entry level, типа всяких ребрендов LSI. Даже их можно вроде как включить в режим a/a

dyasny ★★★★★
()
Ответ на: комментарий от dyasny

«Портал» там поднят один.
И, соответственно, один линк на него в standby.
По уму, можно сделать несколько порталов и линков, да.

Yustas ★★★★
() автор топика
Ответ на: комментарий от Yustas

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

dyasny ★★★★★
()
Ответ на: комментарий от dyasny

Я так понимаю, по порталам должна быть нагрузка раскидана примерно равным образом?
Или там ещё каие-то критерии что бы группировать LUN'ы?

Yustas ★★★★
() автор топика
Ответ на: комментарий от Yustas

я обычно цепляю все таргеты ко всем порталам, и все инициаторы ко всем порталам, дальше разбирается multipath

dyasny ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.