Я занимаюсь повышением производительности в своей среде vSphere. Мы используем устройство NetApp со всеми виртуальными машинами, хранящимися в хранилищах данных, которые смонтированы через NFS.
Мне было предложено использовать iSCSI для данных vHD для некоторых конкретных рабочих нагрузок (например, данных SQL или файлового сервера) для повышения производительности дискового ввода-вывода.
В моем примере загрузочным диском будет обычный 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 для достижения той же цели, поэтому вам следует не используйте эту настройку, если она действительно не нужна.
Предлагаю вам сделать несколько тестов, тестирование каждой конфигурации, перед запуском в производство.
Перво-наперво: если вы хотите повысить производительность виртуальной машины, вы должны знать, где находится узкое место. Повышение производительности хранилища не поможет вам, если в вашей среде не хватает, например, Производительность процессора.
Я не думаю, что изменение протокола хранения с NFS на iSCSI вам сильно поможет. Есть десятки других параметров, которые влияют на производительность вашего хранилища больше, чем протокол.
Если у вас действительно есть проблемы с производительностью вашего хранилища, Google для vmware netapp лучшие практики; это должно дать вам достаточно информации.
Кстати: Лично я бы не стал использовать iSCSI внутри виртуальной машины. Если вы хотите переместить виртуальную машину в другой массив хранения, вам придется сделать это как в vSphere, так и на уровне ОС. Использование VMDK значительно упрощает жизнь.
Я не слышал, что iSCSI лучше NFS для виртуальных машин SQL, однако, если вы решите создать их, я бы создал хранилище данных на уровне ESX, а не устанавливал инициатор iSCSI на виртуальную машину.
Одна вещь, о которой вам нужно быть осторожнее, - это тонкое обеспечение в NetApp. То, как они блокируют устройства, отличается. Вы можете оказаться с автономным LUN, если вам случится настроить его, не готовясь к идеальному шторму неудач. Вам нужна следующая конфигурация:
Максимум, который вы хотите установить для своего автоматического увеличения vol, будет зависеть от того, хотите ли вы делать снимки этого lun. Если вы это сделаете, вам необходимо оценить скорость изменения и позволить объему вырасти до достаточно большого, чтобы он мог обработать наибольшую ожидаемую дельту, прежде чем вы удаляете привязки.
Вы также должны быть очень осторожны с настройками lun и igroup - убедитесь, что они установлены на VMWare. Кроме того, вы хотите убедиться, что VAAI включен, чтобы VMWare могла перераспределять нули.