Управление блочным устройством
Материал из Xgu.ru
Внутри операционной системы управление устройствами делается через вызовы ioctl: для кросс-платформенного управления виртуализованными блочными устройствами неизбежна трансляция этих команд в некое стандартное подмножество, осуществляемая инициатором SCSI.
Однако тех команд недостаточно для управления сложными SCSI-адресуемыми устройствами, такими как дисковые массивы, оптические и ленточные библиотеки: для таких целей использовались дополнительные команды SCSI-протокола (in band, внутри полосы пропускания).
И этих стандартизированных SCSI-команд также оказалось недостаточно для управления проприетарным функционалом массивов, особенно их конфигурацией (особенно в сложившихся условиях, когда в интересах вендоров и продавцов "железа" искусственно раздута рыночная ценность фиксированных конфигураций): такие задачи решаются внешними средствами out-of-band SCSI-трафика тунеллируемого в протоколах SAN, или даже вовсе out-of-band протоколов SAN.
Помаленьку стандартизированы протоколы SES и I2C...
Итак, с точки зрения разработчика поле непаханное. С точки зрения использования, картина складывается удручающая: на сей момент безопасны только статические конфигурации, тщательно продуманные на этапе интеграции. Рутинные операции с конфигурацией SAN рискованы, из-за человеческого фактора.
Динамическая инфраструктура виртуализованных блочных устройств на практике пока невозможна, исключительно из-за отсутствия доступных средств управления SAN как единым целым (не отдельных её узлов, и не отдельных проприетарных реализаций). Нет даже удовлетворительных средств просмотра конфигурации SAN, не говоря о таких необходимых вещах, как ролевой доступ к функционалу, опасному для аптайма инфраструктуры или для самих данных.
В Windows есть Storage Manager for SAN, требующий отдельно проприетарного драйвера VDS Hardware Provider от каждого вендора сторадж-подсистемы... Сейчас создаются ещё более навороченные и закрытые архитектурные решения уровня датацентра.
