Как стать автором
Обновить

Комментарии 43

На мой взгляд, основная причина — почему используют SCSI контроллеры нежели IDE в виртуальной среде — это поддержка горячего добавления и возможность делать на таких дисках общее хранилище, например, для MSCS кластера.

Использовать дифференциальные диски в production-среде не рекомендуется

Это неплохо экономит место на СХД, например, при развертывании VDI на Hyper-V.
На мой взгляд, основная причина — почему используют SCSI контроллеры нежели IDE в виртуальной среде — это поддержка горячего добавления и возможность делать на таких дисках общее хранилище, например, для MSCS кластера.
Спасибо! Вот думал, о чем я еще не написал — о горячем добавлении жестких дисков, появившемся в R2. Надо будет допилить :)

Это неплохо экономит место на СХД, например, при развертывании VDI на Hyper-V.

И вновь спасибо — если б можно было поставить не один а два плюса — я бы так и сделал :) Про VDI я даже не подумал — потому что под словом «виртуализация» я понимаю обычно виртуализацию серверов. Узковато мыслю :)
Черт, перемудрил с blockquote :(
А как организовать подобную схему на никсах?
Что именно реализовать и на каких именно никсах? Hyper-V на данный момент поддерживает кроме виндов только RHEL и SLES, в остальных ОС не будут работать компоненты интеграции, а следовательно можно использовать только legacy-устройства, что не есть гуд.
Если вам нужно виртуализировать юниксовые сервера — смотрите в сторону vmware.
именно из-за последней строчки не использую Hyper-V. У нас достаточно большой парк серверов (около 2х десятков HP DL30 G4). В основном виртуализируемся на ESXi, но есть 5 ВМок, которые работают на линуксах. И поэтому используем VMware, для того, чтобы быть «гибче», чтобы среда виртуализации не могла нам «диктовать» ОС, который нам надо использовать.
То есть 5 VM-ок на линуксах, и остальные over9000 — на виндах? Может, если уже действует MS-вская инфраструктура (AD там, всякие System Center), стоит таки перейти на Hyper-V, а 5 линуксовых виртуалок перевести на что-то совместимое (ту же сусю, или шапку, например)?
Или стоит продолжить использовать VMware :)
Винда под VMware ESX/ESXi работает ничуть не хуже, чем на Hyper-V, а на мой взгляд и лучше.

Шапочная платформа пока сыра и убога: blog.vadmin.ru/search/label/RHEV
Элементарно. iscsi монитируется в хозяина, на нём делаются логические тома, которые и становятся виртуальными блочными устройствами гостя. Можно и просто файлики на nfs положить. А можно и всю iscsi'ю в гостя прокинуть.
Традиционно, hyper-v просасывает при работе с дисками, как и все винды. Тривиального lvm-over-iscsi оно не умеет? Не умеет. Значит, динамически изменять размер VHD без особых танцев с бубном на ISCSI stor'е не получится.
Традиционно, hyper-v просасывает при работе с дисками, как и все винды.

Слишком толсто.

Значит, динамически изменять размер VHD без особых танцев с бубном на ISCSI stor'е не получится.

В Hyper-V R2 есть горячее добавление дисков. Так что в принципе можно диск отцепить, изменить размер и подцепить заново. Прямо же «на лету» менять размер дисков не может, вроде, даже ESX.
ESX/ESXi может на горячую увеличивать размер диска.
Ну я про vmkfstool знаю, просто не знал, может ли он работать «на лету». Спасибо.
Может прямо из клиента, без командной строки и vmkfstools.
Собственно, будет интересно собрать инфу на тему «что может 1 и что не может 2», чтобы потом сравнить более-менее объективно, а не как у вендоров — по типу как сравнивали айфон с булыжником :)
Ну вот потому я и говорю «просасывает», потому что в xen'е можно даже размер системного диска на ходу менять. Который, по понятным причинам, «отключить/подключить» не получится.

А «традиционно просасывает» не общий выкрик «майкрософт говно», а констатация, что в windows до сих пор не реализован нормальный LVM, а dynamic disk рядом с ним и близко не стоял.
VMware ESX легко меняет размер системного диска, потому что в общем-то наплевать, системный он или нет.
А затем в онлайне Dell ExtPart увеличивает системный раздел на весь диск.
Подробнее о подключении / отключении дисков к ВМ под Hyper-V: blog.vadmin.ru/2009/11/esx-vs-hyper-v.html

Цитата: Вы будете удивлены, узнав, что все это в лучшем случае относится к добавлению нового виртуального диска к ВМ. Однако вы не можете расширить существующий VHD и не можете его безопасно отключить через SCVMM.

Планируйте заранее

Если ваша ВМ под Hyper-V не имеет виртуального SCSI адаптера, а шаблоны и ВМ Hyper-V R1 не имеют, то вы не сможете осуществить горячее подключение нового VHD, пока не добавите адаптер. Здравствуй, простой.

SCVMM может добавить новый пустой виртуальный диск к ВМ или может скопировать существующий из библиотеки, если вы предварительно скопировали его в библиотеку. Но невозможно добавить VHD, уже существующий на вашей SAN, даже если он лежит рядом с ВМ.

Отключение?

Аптайм может иметь высшее значение, но систему явно проектировали не с целью предотвратить потерю данных. Отключение VHD через SCVMM приводит к немедленному удалению VHD файла. Ай! Спасибо Microsoft, недавний патч помогает администратору, выдавая предупреждение перед удалением и предоставляя возможность отменить операцию. Но нет варианта просто отключить VHD через SCVMM.

Получается, что если вы серьезно хотите использовать горячее подключение и отключение дисков для чего-то, то вам явно потребуется старый добрый Hyper-V Manager.
Виртуальные диски фиксированного размера
Потом уменьшить/увеличить его возможно будет?
С некоторыми ограничениями — но ЕМНИП можно.
Особенно если пользоваться сторонними утилитами, типа Paragon Virtualization Manager.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
>Во-первых, в отличие от IDE, SCSI-контроллер является полностью синтетическим устройством, и потому для своей работы требует установки компонент интеграции.

Вы таки будете смеяться, но у VMware это не так. Эмулируются стандартные BusLogic и LSILogic контроллеры, и соотв. взлетает любая гостевая ОС, в которой есть драйверы. По сути любая серверная ОС последних 10 лет. При установке VMware Tools скорость работу возрастает, но работать будет и без тулзов.
>К сожалению, FibreChannel-LUN’ы присоединить подобным образом не получится – в Hyper-V нет виртуального FC-HBA.

И снова вы таки будете смеяться, но RDM диски (Passthrough) в машинах VMware видятся как обычные SCSI, и без разницы FC они или iSCSI. И висят на том же контроллере, что и обычные vmdk. Изнутри машины просто не определить что с другой стороны — диск и диск.
Точно так же в любых системах полной виртуализации, как то qemu/kvm, VirtualBox и т.п.
Вот интересно, этот топик практически одинаково плюсовали и минусовали.
Если не затруднит тех, кто минусовал топик — объясните пожалуйста, что именно вам не понравилось.
Автор, а что вы знаете на счет этого:

"… возможность прямой работы с VHD-контейнерами и дальнешее предостовление доступа к их содержимому по iSCSI", которое, якобы, доступно только СХД на базе Windows Storage Server?
MS iSCSI Software Target в качестве LUN'ов презентует VHD.
А что, любая iSCSI-хранилка это сделать не может?
Ну под Win2008R2 теоретически — любая, потому что там можно VHD-шник смонтировать в системе как диск.
Но это ж маркетинг :)
Ничего не понял. Есть у меня хранилка с iSCSI-портом, которая отдает LU по iSCSI. И ей плевать кто там на том конце и что он делает с томом — монтирует его в хост-ОС + на этот диск кладет vhd или напрямую монтирует в Hyper-V (pass-through-диск).

В чем я не прав? Какое отношение к этому функционалу имеет сама СХД?
Ну MS iSCSI Target может презентовать VHD-шник как LUN по iSCSI. Я не вижу тут 100%-го достоинства, но это ж маркетинг — любую фигню объявят мегафичей, прорывом и революцией.
Аааааааа, то есть только если это СОФТОВЫЙ iSCSI, как раз в той самой Windows Storage Server? Или просто в любой серверной Windows?

То есть, если у нас железная СХД на базе Windows Storage Server, то она НЕ сможет презентовать vhd в виде LU? Другой вопрос — а чем отличается презентация vhd от презентации LU — это ведь просто том (и в том и в другом случае), который монтируется ВНУТРЬ гостевой ОС в Hyper-V, верно?
Железная СХД на базе Windows Storage Server — это как раз и есть сервер, на котором запущен MS iSCSI Software Target ;) Например железки типа HP All-In-One (сейчас они называются вроде бы X1000).
iSCSI Target сама презентует VHD в виде LUN'ов без монтирования их в ОС.
Чем отличается — да ничем. Просто обычный маркетинговый треп. Ну примерно как Apple, выдающей большой мобильник за прорыв и революцию ;)
А просто смонтировать LU с той же EMC, скажем, внутрь гостевой ОС для Hyper-V с помощью pass-through — возможно?
Можно и даже двумя способами:
1) Запустить iSCSI-инициатор в хостовой ОС, смонтировать LUN и подмонтировать как pass-through к виртуалке
2) Запустить инициатор в гостевой ОС и смонтировать LUN в ней.
Ага, ну это понятно.
Однако для переносимости проще LU монтировать в хост-ОС и на нее уже класть vhd — получается портабельность, куда хочешь потом vhd можно переместить.
Ну да, в принципе так и есть. А почему вы используете в продакшне именно iSCSI, а не FC? Вроде бы при ценах на EMC-шное железо можно и не экономить на адаптерах и свитчах?
Ну iSCSI все равно дешевле.
При этом pass-through подключение поддерживается только для iSCSI.
Никто не мешает смонтировать FC LUN в хостовой ОС и отдать его как Pass-through виртуалке.

iSCSI может и дешевле, но ведь скорость, задержки? Или у вас 10GbE? Вроде как 10GbE свитчи и адаптеры стоят чуть ли не дороже, чем 8Gb FC :)
Да, iSCSI 1Gb — ерунда, тут я согласен. Очень редко кто его использует, всегда ориентируются на FC.

Я нахожусь по другую сторону баррикад — в компании-интеграторе, я знаю наиболее правильные методики. Однако запросы клиентов порой граничат с безграничной фантазией (:
Ну я сам одно время в интеграторе работал. Клиенты порой люто и бешено доставляют. Например, хотят положить базы Exchange на несколько тысяч юзеров на IBM N3300 :)
Мда, FAS2020, конечно, не совсем для этого (:
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.