воскресенье, 15 марта 2009 г.

Кто хочет и сомневается использовать ли SQL под ESX

Интересный документ - Best Practices for SQL Server.

Даются ссылки на сопутствующие доки.

Автор: Михаил на воскресенье, марта 15, 2009
Ярлыки: ,

17 комментариев:

  1. Анонимныйвоскресенье, 15 марта, 2009

    Общие мысли на этот счет:
    1. Какой смысл? Любая субд (DB2, Oracle, MS SQL, etc) сегодня поддерживает инстансы и позволяет консолидировать базы на физике, позволяют менять аффинити на каждый инстанс.. по сути таже виртуализация, только без лишних гипервизоров.
    2. Не берусь судить насколько правилен тест, но тут - http://virtualizationreview.com/features/article.aspx?editorialsid=2641 делают вывод о том, что толстые нагрузки типа SQL на ESX дают много накладных расходов...

    Дмитрий

    ОтветитьУдалить
  2. Михаилвоскресенье, 15 марта, 2009

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

    ОтветитьУдалить
  3. Анонимныйпонедельник, 16 марта, 2009

    У меня SQL2005 x64 запущен под Vmware server 2.0 и держит базу данных для SAP, порядка 160Gb. Всё не просто бегает, а ЛЕТАЕТ.
    Старый физический сервер DL380G4 подтормаживал, временами даже очень сильно. Новое железо - мощная десктопная материнка и такой же процессор.
    Так что:
    1. Виртуализировать SQL вполне можно, надо только знать кунг-фу.
    2. Кажется мне, что по ссылке гонево в области утверждения, что "Server проигрывает ESX`у". На дефолтных настройках - да, с применением кунг-фу - ещё посмотрим.

    ОтветитьУдалить
  4. Михаилпонедельник, 16 марта, 2009

    Кунг-фу ESX потенциально сильнее кунг-фу VMware Server.

    ОтветитьУдалить
  5. Anton Zhbankovпонедельник, 16 марта, 2009

    По пункту 2. На опыте проверено, что vSMP на Server сильно хуже vSMP на ESX.

    ОтветитьУдалить
  6. Анонимныйпонедельник, 16 марта, 2009

    к комментарию номер 1
    по поводу теста http://virtualizationreview.com/features/article.aspx?editorialsid=2641

    судя по тесту ESX сливает по процам и памяти просто чудовищно, с чего бы это?
    интересно, а было ли отключено sched.mem.pshare.enable = "FALSE"
    шары и резервация на память, проц ...

    да и сам BurnInTest не вызывает доверия - гонял на нем тесты - все время разные результаты получал, миллион туда, пара тройка туда ))

    ОтветитьУдалить
  7. Анонимныйпонедельник, 16 марта, 2009

    > По пункту 2. На опыте проверено, что vSMP на Server сильно хуже vSMP на ESX.

    Тут всё сложнее. Очень похоже что Server`у не очень то и надо vSMP. У меня на 4х-ядерном проце крутятся две однопроцесорные VM, в момент высокой нагрузки CPU одной из виртаулок htop показывает загрузку всех 4х ядер вместо загрузки одного.

    Свободного ESX-совместимого железа нет, сравнить производительность не могу. Но хотелось бы.

    ОтветитьУдалить
  8. Михаилпонедельник, 16 марта, 2009

    То, что пара однопроцессорынх ВМ может загрузить больше 4х ядер - противоречит теории.
    Может, на сервер что то еше крутится?

    ОтветитьУдалить
  9. Anton Zhbankovпонедельник, 16 марта, 2009

    vSMP - это вообще-то многопроцессорная ВМ. Server'у vSMP действительно не нужен.

    ОтветитьУдалить
  10. Михаилпонедельник, 16 марта, 2009

    как не нужен - двухпроцессорные ВМ он делать то умеет.

    ОтветитьУдалить
  11. Анонимныйпонедельник, 16 марта, 2009

    > То, что пара однопроцессорынх ВМ может загрузить больше 4х ядер - противоречит теории.

    Да, знаю. Но тем не менее, только что ещё раз посмотрел - когда пользователи активно работают htop показывает загрузку всех 4х ядер, неравномерную, но загрузку. Т.е. одно ядро всегда загружено меньше остальных 3х, но его загрузка подскакивает вместе с остальными. Выглядит примерно так - в спокойном состоянии 14х14х7х4 (%), начали колотить данные - 70х70х40х25. Кроме вмвари на этом хосте больше ничего жручего нет.

    ОтветитьУдалить
  12. Anton Zhbankovпонедельник, 16 марта, 2009

    >как не нужен - двухпроцессорные ВМ он делать то умеет.

    В общем, мы об одном и том же.

    ОтветитьУдалить
  13. Анонимныйпонедельник, 16 марта, 2009

    В комментарии 3 3apa3a-b-ta3e упоминал о производительности Server в противовес ESX ... толи 3apa3a-b-ta3e недосписал, толи еще чего но в тесте участвует Citrix Xenserver но никак не VMWARE Server

    Может кто либо прокомментировать разницу в производительности? По первому тест XenServer просто вреди планеты всей.

    ОтветитьУдалить
  14. Анонимныйпонедельник, 16 марта, 2009

    23apa3a-b-ta3e
    у вас с дисковой все в порядке?
    70х70х40х25 - два ядра на виртуальную машину, нагрузка на два других ядра похоже на обслуживание запросов хоста (как правило дисковые операции если происходит много много IO и дисковая не успевает)

    В наличии 6 серверов с VMWARE Server 2 (регион, проще в обслуживании для местной техподдержки и нет возни с пробросом портов USB) - везде нагрузка на ядра хоста соответствует ожиданиям.
    Сейчас специально нагрузил VM с 2vCPU тестом производительности 7-zip, на хосте загружено 2 ядра.

    ОтветитьУдалить
  15. Анонимныйвторник, 17 марта, 2009

    zubastiy, в статье - "Item 5: Use VMware's ESX Server". Там про server.

    С дисками всё в порядке, там адаптек 3405 и 4 SAS-винта в RAID10, здесь затыков быть не должно.

    Странно, что запросы хоста довольно высокие, не? Хотя этож SAP, там всё может быть.

    ОтветитьУдалить
  16. Анонимныйпонедельник, 20 апреля, 2009

    В комментарии 3 3apa3a-b-ta3e упоминал про "кунг-фу".

    А вообще, кто-нибудь может поделиться про установку (как связать 2 и более физических сервера для корректной работы SQL & Terminal Server`s)... Как правильно создать разделы для размещения файлов БД Сикула более 100 ГБ.

    Спасибо за ранее...

    ОтветитьУдалить
  17. Михаилпонедельник, 20 апреля, 2009

    В комментариях не очень удобно, я думаю, задавать такой вопрос - их мало кто читает.
    Попробуйте, может, на форуме
    http://communities.vmware.com/community/vmug/emea/russia?view=discussions

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

Примечание. Отправлять комментарии могут только участники этого блога.

Подписаться на: Комментарии к сообщению (Atom)