Comments 3
Классная полезная статья.
Хабр - торт.
Крайне познавательно, спасибо :)
Общее блочное устройство для нескольких виртуальных машин можно создать с помощью открытого ПО. Главное соблюдать правило: в виртуальные машины диск передавать как устройство virtio-blk, а не virtio-scsi. Для QEMU в качестве backend-реализации можно использовать несжатый файл qcow2 (если все виртуальные машины на одном и том же физическом хосте), iSCSI-диск, Ceph RBD или аналогичные решения.
Формат qcow2 не поддерживает конкурентный доступ на чтение/запись из нескольких виртуальных машин одновременно. Даже если вы отключите page cache, он не защищён на изменение метаданных из разных источников. Если интересно, писал об этом тут.
а в качестве сервера для экспериментального стенда выбрали линуксовый nfsd. С точки зрения архитектуры эта комбинация выглядела привлекательно: в ней серверами данных (в терминологии pNFS) становились сервисы удаленных дисков SDS и оставалось только добавить в систему MDS.
А вы не тестировали возможность использования nfs-ganesha в такой же схеме с block layout?
В QEMU диск к виртуальной машине нужно подключать не как virtio-scsi, а как virtio-blk. В противном случае Linux будет пытаться использовать Block SCSI Layout вместо Block Volume Layout.
Подскажите чем это может быть черевато, ведь virtio-scsi быстрее и поддерживает TRIM.
В pNFS все эти процессы очень похожи на обычный NFS. Но для доступа к блокам данных клиент запрашивает у MDS схему размещения файла на DS-серверах, а затем выполняет чтение или запись, коммуницируя напрямую с DS-серверами.
Архитектурно pNFS Block Volume Layout лучше всего сочетается с SDS. Роль серверов данных выполняют сами удаленные диски. Фактически добавляется только одна новая сущность — сервер MDS.
То есть правильно-ли я понимаю что при наличии shared LUN, использование pNFS с блочным лейаутом можно рассматривать как альтернативу OCFS2 и GFS2?
Интересует возможность растянуть одну общую файловую систему поверх shared LUN, которая будет работать в ReadWriteMany. Внутри неё планируется создавать QCOW2-диски для отдельных виртуальных машин, которые поддерживают снапшоты и прочее.
Спасибо за хороший комментарий!
Формат qcow2 не поддерживает конкурентный доступ на чтение/запись...
Мы для теста сделали три виртуалки на одном образе: два клиента и один MDS. Сильно не проверяли на стабильность, по пару файлов между клиентами перекинуть удалось. Динамически расширяемый образ или сжатый точно не работают. Мы использовали образ фиксированного размера со статически предвыделенным местом на диске. Возможно, это просто RAW-image был, я уточню ещё раз.
А вы не тестировали возможность использования nfs-ganesha в такой же схеме с block layout?
В Ганеше просто нет реализации block layout вообще, т.е. все открытые реализации FSAL используют другие типы layouts.
По поводу virtio-scsi vs virtio-blk: можно использовать оба варианта, просто будет разный драйвер у клиента. Это очень похожие, но все таки разные layouts. Если клиент видит iSCSI-устройство, то его ядро будет грузить драйвер Block SCSI Layout. Мы же описывали как форсировать использование именно дайвера Block Volume Layout.
Например, в решениях у Dell используется Block SCSI (по описанию, которое я находил). Прицип действия аналогичный, только немножко другой формат структурок с экстентами и энумерации дисков в протоколе.
Я бы сказал, что тут все зависит от используемого SDS или СХД, т. е. как устройства раздаются в QEMU — от того и надо плясать.
То есть правильно-ли я понимаю что при наличии shared LUN, использование pNFS с блочным лейаутом можно рассматривать как альтернативу OCFS2 и GFS2?
Да, pNFS в режиме SCSI Block Layout будет работать на общем iSCSI диске, предоставлять кластерную файловую систему. Но проблема в том, что open source сервера пока не в состоянии production ready.
Как мы производительность блочного pNFS измеряли