У нас есть модуль iSCSI SAN, подключенный к кластеру серверов ESX. Все серверы управляются экземпляром vCenter. Экземпляр vCenter управляет десятком виртуальных машин Windows Server.
Большинство виртуальных машин имеют более одного тома. Эти тома отображаются в настройках виртуальной машины в vCenter. Диск C в Windows отображается как жесткий диск 1 в vCenter. Диск D отображается как жесткий диск 2 и так далее. Другими словами, SAN скрывается от серверов.
Однако один сервер настроен иначе. Его диск C управляется vCenter, но его второй том напрямую подключен к SAN через инициатор iSCSI Windows. Когда я спросил администратора сервера, почему он настроил его таким образом, он спросил: «Зачем вам нужен посредник для обработки ваших томов?» Я попытался объяснить, что функции vCenter HA и Snapshot не охватят второй том, но его это не убедило.
Я тоже по-прежнему не убежден. Хотя это кажется как и все тома виртуальной машины должны обрабатываться vCenter, я могу ошибаться. Вы настроили свои виртуальные машины аналогичным образом? Что-то, где загрузочный диск представлен виртуальной машине vCenter, но все остальные тома напрямую подключены к SAN?
Да.
Иногда люди делают это. Причины могут включать:
vSphere не сможет делать снимки и многое делать с этими томами с прямым подключением. Я не сторонник этого без крайней необходимости. Это вызывает путаницу и усложняет проектирование сети, аварийное восстановление и редко хорошо документируется.
Я работал в среде, где конкретный клиент делал это на каждый одна из их 900 виртуальных машин. Ужасная смесь CIFS, iSCSI, NFS, представленная из нескольких массивов SAN непосредственно на виртуальные машины вместо VMDK.
В настоящее время у нас есть файловый сервер, настроенный аналогичным образом. Загрузочный диск и некоторые другие - через VMWare, а диск с данными - через прямое соединение iSCSI. Ранее он был настроен таким образом, чтобы преодолеть ограничение на 2 ТБ жестких дисков в VMWare. И да, функции моментального снимка vCenter и высокой доступности не будут применяться к этому тому, поскольку он предоставляется непосредственно на сервер. Это сработало для нас, поскольку этот «диск» покрыт снимками в SAN.
Что касается комментария посредника, сделанного администратором, я должен сказать, что нет проблем с производительностью и нет причин не использовать возможности моментальных снимков и высокой доступности. Эта статья в частности, показывает, что накладные расходы гипервизора на хранилище минимальны. При отправке в централизованное хранилище узким местом будет не гипервизор, а среда, соединяющая хосты с вашим хранилищем (оптоволокно, Ethernet и т. Д.), А за этим - сами диски и контроллеры. Единственный раз, когда я мог видеть, что гипервизор становится узким местом, - это если вы перегружаете хост виртуально выделенными ресурсами, превышающими его физически, и все виртуальные машины обращаются к ним одновременно. Если вы абсолютно уверены, что гипервизор вызовет проблемы с производительностью, вы можете использовать прямое сопоставление устройств. Если вы потратите некоторое время на их поиск, то уже было проведено несколько тематических исследований по производительности хранилища и VMWare.
Лично у меня не было проблем с использованием VMWare для управления хранилищем, особенно с версия 5.5 и новые ограничения на хранение. Надеюсь это поможет.