Я собираюсь разделить наш сервер базы данных и сервер приложений и оцениваю предложения от Rackspace и Azure, в частности, вокруг сервера базы данных. Мы являемся веб-приложением Saas, и для нас важны производительность и способность к будущему росту.
Rackspace сказал мне, что для производительности важно иметь машину, выделенную для SQL-сервера, и, что более важно, не существует уровня виртуализации между ОС и жестким диском. т.е. Другое название - конфигурация «голый металл».
Евангелист Azure сказал, что у них нет проблем с запуском SQL Server на виртуальной машине, которая является единственным клиентом физической машины, и что они точно настроили эту конфигурацию, чтобы получить гораздо более высокую пропускную способность (в 3-4 раза), чем Rackspace могла бы достичь за счет их виртуализации. слой (видимо, VMWare).
Azure намного дешевле и, похоже, имеет лучшую долгосрочную историю с точки зрения простого масштабирования базы данных. Собираюсь ли я добиться желаемого прироста производительности с помощью уровня виртуализации? Кто говорит правду? Есть ли какие-либо статистические данные или технические документы, по которым я могу изучить или сравнить дальше.
Что ж, SQL работает ужасно медленно на моем компьютере Compaq 1993 года (с 33 МГц и 4 МБ ОЗУ), но очень хорошо на гостевой виртуальной машине ESX с 8 виртуальными ЦП, 64 ГБ ОЗУ и подключенным FC SAN для своего диска.
Итак, это зависит от характеристик ваших машин.
При прочих равных условиях сервер базы данных на голом железе будет превосходить виртуализированный сервер, но в какой конкретной степени он действительно зависит от множества конфигураций и шаблонов использования - от машины, ОС и самого SQL-сервера (и вы не упоминаете ни одного того, что). Единственный реальный способ получить точный ответ - это провести тесты, которые, похоже, потратят много денег, чтобы сказать, что вы уже знаете - виртуализированная производительность в некоторой степени хуже, при этом основным определяющим фактором является дисковый ввод / вывод. О. (Отсюда и пропускная способность в 3-4 раза - дисковый ввод-вывод может быть в 3-4 раза медленнее через уровень виртуализации, чем через напрямую подключенные диски.)
Насколько велико это различие, зависит от того, какой «прирост производительности» конкретно, вам нужно выйти из сервера базы данных. Вы не говорите, так что можно только догадываться, что вам действительно нужно. Без надежных показателей производительности для анализа невозможно сказать так или иначе. И какой бы путь вы ни выбрали, вам действительно понадобятся эти показатели, если вы хотите построить их с самого начала.
Что касается масштабируемости, в наши дни вы можете получить довольно хорошую масштабируемость для SQL-сервера из голого металлического корпуса, что, возможно, стоит принять во внимание ... Бьюсь об заклад, вы можете получить много операций ввода-вывода, обслуживающих базу данных. из один из них, и если вы правильно определите базовую модель сервера, у вас не должно возникнуть проблем с добавлением дополнительных процессоров или оперативной памяти или традиционных дисков / подключенного хранилища.
На самом деле, похоже, что гораздо больше исследований с вашей стороны - это порядок, по крайней мере, в том, что касается ваших требований (и денежных ограничений), прежде чем вы остановитесь на каком-либо решении.