Назад | Перейти на главную страницу

iSCSI как серверная часть хранилища KVM: передовой опыт в отношении целей и LUN для каждой виртуальной машины

Я использую пул iSCSI в качестве серверной части хранилища для нескольких виртуальных машин, и мне было интересно, как другие люди используют цели и LUN в этом случае использования.

Я начал с одной цели под названием iqn.2016-06.iscsihost:kvmguests с одним LUN на каждую виртуальную машину. Однако в результате получаются не совсем идеальные имена для целевого хранилища, связанного с виртуальной машиной (см. этот вопрос), поэтому мне было интересно, следует ли мне переключаться на одну цель для каждой виртуальной машины (с потенциально парой LUN на цель, например, для отдельных дисков ОС и т. д.). Это будет иметь побочный эффект в виде очень аккуратных имен, которые невозможно так легко перепутать на стороне KVM (например, iqn.2016-06.iscsihost:webserver01, iqn.2016-06.iscsihost:database07, и т.д.) . Я не уверен, какие последствия это будет иметь, поэтому любые указатели приветствуются.

Итак, вопрос: что здесь лучше всего? Одна цель с одним (или несколькими) LUN на виртуальную машину или одна цель на виртуальную машину?

Обновить: Подумав об этом, нужно добавить каждую цель iSCSI в качестве пула хранения к каждому хосту KVM. Это просто очень неудобно, так как приходилось бы менять конфигурацию каждого хоста KVM каждый раз, когда добавлялась новая виртуальная машина ... Или мне что-то не хватает. Как это делается в реальном мире?

Я не могу говорить о KVM, но мы используем iSCSI для подключения нашего кластера VMWare VSphere с 4 хостами ESXi к нашей системе хранения данных Dell Compellent, и мы просто создаем хранилища данных на прибл. 4-5 виртуальных машин, в настоящее время около 2 ТБ на LUN. Вы не хотите, чтобы на одном подключении iSCSI было слишком много виртуальных машин, но вам также не нужны огромные административные издержки, связанные с несколькими LUN на каждую виртуальную машину, особенно если ваша среда превышает 4-5 виртуальных машин. «Лучшая» настройка зависит от вашей среды, возможностей вашего хранилища (несколько контроллеров, балансировка нагрузки и т. Д.) И вашего решения виртуализации.

Первоначально проект Libvirt спроектировал хранилище iSCSI для существования в пулах на хосте KVM. Как вы заметили, нет особого смысла делать это с iSCSI, особенно если вы хотите переместить виртуальную машину. Я считаю, что именно поэтому в проекте QEMU реализован собственный «встроенный iSCSI» драйвер с libiscsi библиотека. Таким образом, виртуальная машина сама сможет подключиться к цели iSCSI для своего хранилища. Если процесс QEMU подключается к цели самостоятельно, то он не зависит от хоста и может быть легко перенесен на другие хосты, при этом хост ничего не знает об инфраструктуре хранения iSCSI.

Это легко сделать с сырым QEMU, например:

-device virtio-scsi-pci,id=scsi0 \
-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,drive=disk0 \
-drive id=disk0,file=iscsi://server.example.com/iqn.2000-01.com.example:server:target/0,if=none,cache=none,format=raw,media=disk,discard=unmap

Документацию по QEMU можно найти здесь:

https://www.qemu.org/docs/master/qemu-doc.html#Device-URL-Syntax

Мне удалось заставить абстракцию Libvirt работать следующим образом:

<domain type='qemu'>
  <!-- snip -->
  <devices>
    <!-- snip -->
    <controller type='scsi' index='0' model='virtio-scsi'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
    </controller>
    <disk type='network' device='lun'>
      <driver name='qemu' cache='none' discard='unmap'/>
      <source protocol='iscsi' name='iqn.2000-01.com.example:server:target/0'>
        <host name='server.example.com' port='3260'/>
      </source>
      <target dev='sda' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <!-- snip -->
  </devices>
</domain>