суббота, 28 марта 2009 г.

Виртуализация SQL

Камрад Brent Ozar написал два поста - Why Would You Virtualize SQL Server? и Reasons Why You Shouldn’t Virtualize SQL Server:
за и против виртуализации SQL серверов.

Вкратце:

За -

Независимость от железа
, и, как следствие, простота организации высокой доступности. Конечно, сделать отказоустойчивый кластер можно и для SQL на физическом сервере, однако это дорого, и чем больше серверов надо закластеризовать тем дороже. В случае SQL в ВМ мы запросто обеспечим высокую доступность всем.

Цитата:



I especially like this option for development and QA servers. Management is rarely willing to implement expensive high-availability setups for development environments, but when the dev server goes down, the developers and project managers are kicking my door down. The PM’s scream about how there’s so many expensive developers sitting around idle waiting for the server to come back up. Virtualization avoids this problem altogether.



Простота изменения конфигурации - если не угадали с сайзингом железки под SQL, то для апгрейда конфигурации нужно время. ВМ в этом смысле намного более терпима - мы просто добавляем ресурса нужной ВМ(пусть даже отнимая этот ресурс у менее критичной виртуалки). Да и в обратную сторону - видим, что какого то ресурса у SQL ВМ лишку - отнимем и поделим, делов на две секунды.

Цитата:



I loved this approach because it let me keep old SQL Servers around as long as necessary. For example, we decommissioned an old help desk database server, but I told the help desk folks they could keep it around as long as they wanted. It hardly used any resources at all, because nobody queried it unless they had a question about an old help desk ticket that didn’t get transitioned correctly to the new system. I set the server up with one virtual CPU, 1gb of memory, and put it on cheap RAID 5 SATA. The end users loved me because I could provide the service for no cost.



Производительность ВМ не ужасна, как о ней иногда отзываются. Да, годы назад, первые версии софтов виртуализации тормозили. Но ныне все работает достаточно шустро. Одним из обоснований автор приводит наличие книги "Oracle on VMware". И книга пользуется успехом.


Цитата:



You can still get really bad performance with virtualization, just as you can get really bad performance with SQL Server on native hardware. But follow a few basic guidelines like avoiding oversubscription, properly configuring networking & storage, and using the right OS configurations, and you can get perfectly acceptable performance. Yes, you’re still going to lose a few percent of overhead - but with today’s redonkulously fast CPUs and memory, I’m more concerned about optimizing T-SQL code than I’m concerned with losing 5% of my CPU speed due to virtualization. It’s all about priorities, and that small performance loss is just one piece of the picture.



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


Теперь про против виртуализации SQL:

Сложнее получить нужную производительность СХД(иногда) - ибо HBA одного физического сервера используют несколько ВМ, потенциально сильно нагружающих дисковую.

Сложнее получить информацию о производительности - в силу того, что между ВМ и железом находится гипервизор.

Связка "железо+гипервизор+ОС+SQL" менее надежна, чем "железо+ОС+SQL" - просто в силу большей сложности. Например, вспомним августовскую ночь со вторника на среду, когда баг в ESX3.5 Update 2 не позволял включать ВМ после 12 августа.

"Виртуализация" не значит "бесплатнотизация" - лицензии для платных гипервизоров стоят денег. А функций бесплатных нам может не хватить. Выгода от виртуализации не мгновенна.

Ну и рекомендации автора:
* Virtualize only when it’s going to solve a problem, and you don’t have a better solution for that problem.
* Get good at performance monitoring before you virtualize, because it’s much tougher afterwards.
* Start by virtualizing the oldest, slowest boxes with local storage because they’ll likely see a performance gain instead of a penalty.
* Avoid virtualizing servers that have (and utilize) more than 2 HBAs.

Напомню, что основные ресурсы по виртуализации SQL я собрал тут - wiki.vm4.ru/sql

P.S.
В камментах была ссылка на The proper order of Server Virtualization in SharePoint.

4 комментария:

  1. Ну так это такое жизненное правило, чем проще - тем надёжнее, чем меньше элементов в связке - тем надежнее связка вцелом.

    ОтветитьУдалить
  2. с другой стороны, если взять отказоустойчивый кластер типа MSCS\MFC - насколько он сложнее просто одного сервера.

    а ведь надежнее ;)

    ОтветитьУдалить
  3. в случае виртуализации то же не все однозначно - от усложнения получаем и плюсы.

    ОтветитьУдалить
  4. про сложности с СХД - если шасси сервера позволяет, то воткнуть еще одну HBA-шку и выдать ее виртуалке эксклюзивно. Про MSCS/MFC - я их особо глубоко не изучал, но у низ были две маленькие засады, при выходе из тепличных условий превращающиеся в большие проблемы:
    1) Quorum Disk, который один на кластер и вроде бы никак не дублируется, т.е. при отказе LUN на котором оно лежит приводит к отказу кластера (хорошо, если при этом кластерное ядро не роняет защищаемые приложения)
    2) все узлы кластера обязаны быть в одной подсети, т.е. никакого широко-распределенного кластера мы не создадим простыми средствами. А кластер в пределах одного ЦОД может не решать поставленных задач.
    Единственная засада против виртуализации SQL - это отказ вендоров решений на его базе (например такого как SAP) поддерживать промышленную эксплуатацию. В тестлабе - пожалуйста, а в продуктиве фигу!

    ОтветитьУдалить