Назад | Перейти на главную страницу

Виртуализация сервера базы данных Microsoft SQL

Моя компания хочет виртуализировать наш сервер Microsoft SQL. Я прочитал по другому вопросу, что базы данных на виртуальных машинах страдают от узкого места ввода-вывода, что не очень хорошо для нас. Но мне было интересно, если мы используем Microsoft HyperV, Microsoft Server и Microsoft SQL, оптимизировала ли Microsoft их для работы так же хорошо, как на физической машине?

Спасибо

что Microsoft оптимизировала их для работы на уровне физической машины?

Да, у MS - довольно близко.

Основная проблема в том, что это имеет смысл только в небольших установках. В тот момент, когда вашему виртуальному SQL-серверу потребуется собственная машина с тщательно продуманной установкой диска - любой, кроме небольшого экземпляра SQL с небольшим объемом - больше нечего будет размещать на этом сервере.

Я запускаю SQL-сервер на платформе виртуализации. Из 20 дисков на этой машине 12 выделены для SQL-сервера (для журналов и данных, включая tempdb - ОС загружается с VHD). Следующее обновление доведет его до предела - даже сейчас это самая толстая виртуальная машина с 16 ГБ оперативной памяти из моих доступных 64 ГБ. Как только мне нужно будет обновить это .... какой в ​​этом смысл?

С текущей технологией вы ограничены 4 виртуальными ядрами - 16 в Hyper-V 3 (появится в следующем году). Это не так уж и много для аналитики баз данных. Если вы выполняете обработку типа OLAP, визуализация с помощью Hyper-V может просто не масштабироваться в достаточной степени.

Таким образом, основная проблема заключается не в том, что MS не может приблизиться к сопоставимому оборудованию, а в том, что серверы SQL могут стать настолько большими, что сопоставимое оборудование в любом случае означает 1 сервер SQL на одном уровне оборудования, плюс вы не можете масштабировать виртуальную машину так же хорошо, как оборудование. , к сожалению.

Современные гипервизоры могут обеспечивать почти такую ​​же производительность, что и базовое физическое оборудование, при условии, что производительность сохраняется физически и вы не помещаете слишком много виртуальных машин на одно и то же оборудование; Итак, виртуализация как таковой не сильно повлияет на производительность, если у вас достаточно ЦП / ОЗУ и вы убедитесь, что диски данных этой виртуальной машины не используются совместно с другими виртуальными машинами.

Для небольшой / средней нагрузки этого почти всегда достаточно; но для больших рабочих нагрузок вы бы действительно хотите, чтобы SQL Server работал на физическом оборудовании, по двум основным причинам:

  1. Виртуализированное оборудование может масштабироваться только до определенного уровня, у вас не может быть более 4 виртуальных процессоров с Hyper-V и 8 с ESXi.
  2. Если вы собираетесь назначить все физические ресурсы узла виртуализации одной виртуальной машине, вы также можете запустить ее непосредственно на физическом оборудовании и удалить эти (небольшие) накладные расходы на виртуализацию.

Краткий ответ: никакая виртуальная машина, независимо от стека, не может сравниться с производительностью ввода-вывода физического сервера.

Длинный ответ: это действительно зависит от нагрузки. Если в вашей компании 80 пользователей и ваш SQL-сервер обслуживает бухгалтерское приложение, экземпляр SharePoint и какое-то другое случайное бизнес-приложение, я сомневаюсь, что вы заметите значительное снижение производительности.

Если этот SQL-сервер обслуживает тысячи пользователей или имеет какое-то интенсивное приложение, выполняющее тысячи запросов и вычислений в секунду, вы увидите значительное снижение производительности.

Я не вижу причин, по которым вы не должны виртуализировать базы данных. Даже если один SQL-сервер займет целый гипервизор ...

Да, виртуализация всегда сопровождается некоторой потерей производительности. Однако с каждым выпуском эта потеря становится все меньше и меньше, и я считаю, что сегодня это мало по сравнению со всеми другими преимуществами, которые вы получите от виртуализации серверов. Подумайте о высокой доступности и аварийном восстановлении, возможности временно добавить ресурсы общедоступного облака в вашу инфраструктуру при внезапном повышении спроса, простом развертывании новых серверов.

Кроме того, я также вижу, что все упоминают ограничения vCPU. Два комментария: общее практическое правило; не добавляйте в виртуальную машину больше виртуальных ЦП, если на определенном хосте / гипервизоре доступны ядра. Итак, если у вашего хоста 8 ядер, вам понадобится 8 виртуальных ЦП. Второй комментарий: vSphere 5 Enterprise Plus поддерживает до 32 виртуальных ЦП на виртуальную машину.

Все, что я когда-либо испытывал в отношении виртуализации, значительно снижает производительность, особенно при вводе-выводе. Я бы никогда не запустил тяжелую БД на виртуальной машине.