Q про iSCSI

Коллеги, с приближающимся!

И простой вопрос.
1. Хочу разместить ресурс с образами виртуальных машин на iSCSI-таргете.
2. Запускаться эти виртуальные машиы будут на различных узлах.
Вопрос. Можно ли иметь один на все эти образы iSCI таргет и монтировать его как девайс на разных хостах или на каждую такую виртуалку следует иметь выделенный таргет? То есть можно ли на один таргет вешать несколько инициаторов с разных хостов?

Ну и в догонку - у меня в серверах, скорее всего, простые сетевые платы без аппаратной поддержки iSCSI (не знаю как проверить его наличие). Интернет говорит, что при этом возможна очень сильная загрузка CPU на инициаторе. Это действительно так? Или больше пугалка?

"Cruiser78" написал:

можно ли на один таргет вешать несколько инициаторов с разных хостов?

да
таргет это сервис, инициаторы - клиенты

"Cruiser78" написал:

Или больше пугалка?

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


самое важное тут не подключения, а разделение доступа. если держать несколько имиджей на одном таргете, очень важно сделать так что только один хост сможет иметс доступ на запись в каждый имидж. именно для этого и существуют кластерные ФС

Cruiser78 написал:

Интернет говорит, что при этом возможна очень сильная загрузка CPU на инициаторе. Это действительно так? Или больше пугалка?

Тестировал подобное шаблоном sql от iometer. Иопсов было на ~15% больше чем при nfs и в тоже время LA держался около 0,2 в то время, как при nfs было около 0,9. Как будет у тебя, покажет тест.

Macumazan написал:

[quote=Cruiser78]Интернет говорит, что при этом возможна очень сильная загрузка CPU на инициаторе. Это действительно так? Или больше пугалка?

Тестировал подобное шаблоном sql от iometer. Иопсов было на ~15% больше чем при nfs и в тоже время LA держался около 0,2 в то время, как при nfs было около 0,9. Как будет у тебя, покажет тест.[/quote]

Ну, у меня выбор - использовать под хранение образов виртуалок (предпочитаю файлы-образы, а не разделы дисков) или привычную мне glusterfs. И при этом "размазать" эти образы по трем хостам, на которых эти виртуалки жить будут. Или создать на DRBD iSCSI-таргет, и раздать его под хранение файлов-образов. Не знаю, что выбрать, непонятно, где найдешь, где потеряешь. Сеть - гигабитная, на ней сейчас большой DRBD-раздел синхронизируется со скоростью под 100 мегабайт/с, по сути - скорость дискового канала.
Ну а то, что одна машина будет юзать только свой персональный образ и другая на него никак не кинется - так то само-собой. :)

"Cruiser78" написал:

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

то есть миграция или хотя бы высокая доступность не нужны?

dyasny написал:

то есть миграция или хотя бы высокая доступность не нужны?

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

"Cruiser78" написал:

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

простой пример:
хост А, на нем бежит ВМ, хост Б видит те же таргеты, но все нормально, потому что ВМ на нем не бежит и в таргеты с него не пишет. Все это в удаленном ДЦ, без физического доступа.
На хосте А отказывает сетевушка. С удаленной т.з. он ушел в даун, так как не пингуется. Мы спокойно запускаем ВМ на хосте Б, и получаем ВМ на обоих хостах, пишущих в один и тот же диск. В лучшем случае, ВМ не будет работать (remount / r/o - стандартная практика в линуксе), в худшем - информация к которой одновременно обратятся две ВМ с разных хостов окажется безнадежно убитой.

именно поэтому в кластерах, где имеет место доступ из белее одного хоста к общему хранилищу, обязателен механизм SBA