Хранилище данных vSphere для определенных типов данных: NFS или iSCSI
Я изучаю улучшение производительности в моей vSphere среде. Мы используем устройство NetApp со всем VMs, сохраненным в Хранилищах данных, которые смонтированы через NFS.
Было предложено мне, чтобы, для некоторых определенных рабочих нагрузок (как данные SQL или файловый сервер), для дисковой IO производительности могло быть лучше использовать iSCSI для данных vHD.
В моем примере загрузочный диск был бы нормальным VMDK, сохраненным в присоединенном к NFS хранилище данных. Диск D (диск, где данные SQL или данные файлового сервера находятся) был бы присоединенным к iSCSI объемом.
C: - VMDK disk container -> VMFS datastore -> NFS -> NetApp
D: - iSCSI -> NetApp
Я также обдумываю: iSCSI инициируется от vSphere уровня или непосредственно из Windows?
У кого-либо есть опыт или мысли с этим?
Прежде всего, перед , чтобы исправить с хранилищем вы должны быть на 100% уверены, что ваше узкое место действительно связано с конфигурацией диска / ввода-вывода.
В этом случае общий ресурс iSCSI может быть быстрее, чем общий ресурс NFS, но только в конкретном сценарии (небольшое случайное чтение / запись пакетов). Серверы SQL могут быть одним из этих сценариев, поэтому, если вы уверены , что ваша проблема заключается в производительности хранилища, вы можете попробовать с общим ресурсом iSCSI.
Решение, как его настроить, зависит на ваши конкретные потребности. Для максимальной производительности следует использовать полностью предварительно выделенный том RAW, напрямую подключенный к гостевой ОС. Это дает дополнительное преимущество, заключающееся в том, что гостевая конфигурация становится «самодостаточной» в том смысле, что для миграции этого гостя на другой виртуализатор (даже на основе другой технологии) не потребуется перенастраивать общий ресурс iSCSI. (или, в лучшем случае, реконфигурация будет очень ограниченной).
С другой стороны, управление подключенными гостями, блокировкамиоснованный на виртуальном диске, безусловно, более сложен, если использовать ESX для достижения той же цели, поэтому вам следует не использовать эту настройку, если она действительно не нужна.
Я предлагаю вам провести несколько тестов, сравнительный анализ каждого конфигурации перед запуском в производство.
Я не слышал, что iSCSI лучше, чем NFS для виртуальных машин SQL, однако, если вы решите создать их, я бы создал хранилище данных на уровне ESX, а не устанавливать инициатор iSCSI на виртуальную машину.
Одна вещь, о которой вам нужно быть осторожной, - это тонкое обеспечение в NetApp. То, как они блокируют устройства, отличается. Вы можете оказаться с автономным LUN, если вам случится настроить его, не готовясь к идеальному шторму неудач. Вам нужна следующая конфигурация:
- Тонкий том размером с лунку
- A одиночный тонкий лунок внутри этого тома
- Автовращение объема, настроенное на томе
Максимум, который вы хотите установить для автоматического увеличения объема будет зависеть от того, хотите ли вы делать снимки этого лунного файла. Если вы это сделаете, вам нужно оценить скорость изменения и позволить объему вырасти до достаточно большого, чтобы он мог обрабатывать самую большую дельту, которую вы ожидаете, прежде чем вы удаляете привязки.
Вы также должны быть очень осторожны с lun и igroup settings - убедитесь, что они установлены на VMWare. Кроме того, вы хотите убедиться, что VAAI включен, чтобы VMWare могла перераспределять нули.
Перво-наперво: если вы хотите повысить производительность виртуальной машины, вы должны знать, где находится узкое место. Повышение производительности хранилища не поможет вам, если в вашей среде не хватает, например, Производительность процессора.
Я не думаю, что изменение протокола хранения с NFS на iSCSI вам сильно поможет. Есть десятки других параметров, которые влияют на производительность вашего хранилища больше, чем протокол.
Если у вас действительно есть проблемы с производительностью вашего хранилища, Google для передовых методов vmware netapp ; это должно дать вам достаточно информации.
Кстати: Лично я бы не стал использовать iSCSI внутри виртуальной машины. Если вы хотите переместить виртуальную машину в другой массив хранения, вам придется сделать это как в vSphere, так и на уровне ОС. Использование VMDK значительно упрощает жизнь.