В чем разница в производительности между хранилищем виртуальных машин, созданным в SAN, и хранилищем, используемым непосредственно в SAN для чтения и записи данных?
Я имею в виду, что у нас есть SQL-сервер, который установлен на виртуальной машине и использует виртуальный жесткий диск.
ВМ находится в моем SAN.
Лучше ли обратиться к SQL-серверу для чтения и записи данных в SAN напрямую? У моего решения более высокая производительность?
Когда дело доходит до разницы в производительности между сервером на основе виртуальной машины по сравнению с сервером без операционной системы, становится ясно, что производительность решения с нуля должна быть лучше, поскольку оно имеет буквально меньшее количество уровней абстракции, а значит, меньшее влияние на операции ввода-вывода. Это верно для случая, когда используется простой VHD. Однако есть возможность увеличить производительность виртуальной машины с помощью хранилища iSCSI на уровне блоков. Виртуальная машина использует хранилище iSCSI, что обеспечивает более высокую производительность, поскольку ввод-вывод выполняется так же, как и непосредственно на оборудовании.
Для случая вы можете взглянуть на StarWind Virtual SAN, HPE VSA, и UnityVSA который предоставляет хранилище iSCSI. Я могу порекомендовать StarWind, поскольку он работает со скоростью хранилища DAS, однако StarWind обеспечивает более эффективное использование производительности DAS с включенным кешем DRAM и SSD.
Обычно общий массив хранения используется для функций управления, не обязательно для обеспечения производительности. Высокая доступность, общее хранилище, клоны и снимки, централизованное управление.
В частности, для приложений баз данных может быть полезно использовать клоны уровня массива через необработанные устройства для резервного копирования и тестирования.
Я не думаю, что это имеет большое значение для необработанных устройств и таких абстракций, как хранилища данных VMware. Однако вам придется запустить некоторые тесты производительности в вашей конфигурации, чтобы увидеть.
Что касается локального хранилища хоста по сравнению с общим массивом, то любой из них может работать достаточно хорошо, особенно с некоторыми из более быстрых твердотельных хранилищ.
Во-первых, моя предыстория. За последние 10 лет я управлял средой, в которой работает более 700 производственных серверов, 75 из которых являются SQL-серверами. Я прошел через итерации «голого железа», виртуальных машин с прямым хранилищем SAN и виртуальных машин с VMDK, которые находятся в SAN. Вы упомянули VMWare, поэтому в этом ответе я буду придерживаться этого технического стека.
При сравнении такого же оборудования (SSD, HDD и т. Д.) «Голый металл» всегда быстрее. Однако при виртуализации я не обнаружил заметной разницы между виртуальной машиной, которая напрямую взаимодействует с SAN для хранения, и виртуальной машиной, использующей VMDK для хранения, которые находятся в той же SAN. Добавленный уровень виртуализации в большинстве случаев не увеличивает задержку настолько, чтобы ее можно было заметить. Однако у всех разные варианты использования. Возможно, VMDK быстрее. Например, вы ищете iSCSI для SAN для хранения с прямым подключением через интерфейс Ethernet 1 ГБ, в то время как у вас есть 8 или 16 Gb Fiberchannel для вашего уровня вычислений для подключения к SAN? Если так, VMDK будет быстрее.
С учетом сказанного, переход на VMDK имеет много других преимуществ. vMotion и Storage DRS - это два. Один потенциальный недостаток зависит от размера вашего VMDK, вы не можете увеличить его размер во время работы виртуальной машины. Я считаю, что VMWare перестает позволять вам добавлять дисковое пространство на 2 ТБ. Если вы говорите о меньших VMDK, это не применимо. При этом я рекомендую виртуализировать весь стек.
Кроме того, если бы я рекомендовал технологию SAN для баз данных, я нашел бы Nimble (http://www.nimblestorage.com) быть не имеющим аналогов в отрасли. Особенно в сочетании с VMWare. Молниеносно быстрый, доступный, стабильный. Все вокруг твердое решение