none
Конфигурация для SQL 2012 на Hyper-v FC RRS feed

  • Вопрос

  • Добрый день.

    Подскажи оптимальную конфигурацию дисковой подсистемы (по производительности) для виртуального сервера SQL 2012.

    Вводные данные: Два физических сервера HP (два процессора по 48 ядер, 128Гб памяти, два жесстких диска в RAID10 под ОС супервизорам), СХД Dell (два контролера связанные по FC 16G, в каждом контроллере 4 FC подключенные к SAN свичу) все оборудование продублировано везде для откзоустойчивости. На СХД 20 дискова SAS 1.2Tb в RAID10. Сделан один большой Volum под виртуальные машины и один для кворума кластера.

    -Планирую создавать виртуальные машины на этмо большом волюме, для не требовательных сервисов типа AD,DNS,Print Server и прочего, создавать один фиксированый VHDX диск, а для Exchange 2013, SQL 2012 и File Server сервером создавать дополнительные отдельные фиксированные VHDx диски под базы данных и логи.

    -Второй вариант: на СХД создать несколько волюмов, один где будут располагаться диски с ОС для виртуальных серверов, второй vol для базы данных Exchaange2013 и презентованный непосредственно в виртуальную машину и далее разбитый на диски согласно количеству почтовых баз (одна база один диск), Для SQL сервера также создать отдельные vol на СХД под базы данных и презентованные напрямую виртуальному серверу, также и для Файлового сервера.

    Какой вариант будет предпочтительнее и производительнее т.к. количество пользователей около 500 под почту, а у SQL буду базы 1С (200-300 активных пользователей).

    Или есть другие еще варианты, подскажите буду признателен.

    Спасибо.

    23 декабря 2019 г. 11:52

Ответы

  • В целом бы добавил, что лучше сделать LUN мЕньшего размера и затем его увеличивать по мере необходимости, чем сразу резервировать кучу блоков, которые не будут использоваться. 

    Ни в коем случае не использовать тонкие LUN и диски.

    Для оптимизации SQL, чанги лучше вначале почитать практики от вендора - тут

    • Помечено в качестве ответа NK-addc 24 декабря 2019 г. 9:47
    24 декабря 2019 г. 8:05
  • Пожалуйста.

    LUN

    VHDX

    • Помечено в качестве ответа NK-addc 24 декабря 2019 г. 9:47
    24 декабря 2019 г. 9:00

Все ответы

  • Приветствую.

    Под sql базы как рекомендация использовать ssd (оптимизированные для них), вынести системные базы на  отдельные ssd диски, логи вынести на отдельный ssd диск. 

    По презентации дисков, можно презентовать хосту и пробросить в vm, но Емнип но это не совсем правильно. Проще презентовать диски непосредственно vm


    Я не волшебник, только учусь. MCTS, CCNA. Если Вам помог чей-либо ответ, пожалуйста, не забывайте нажать на кнопку "Отметить как ответ" или проголосовать за "полезное сообщение". Disclaimer: Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции работодателя. Вся информация предоставляется как есть, без каких-либо на то гарантий. Блог IT Инженера, Яндекс Дзен, YouTube, GitHub.

    24 декабря 2019 г. 4:19
    Модератор
  • 1. Под виртуальные машины (AD, DNS, PRINT) сделал бы несколько LUN (это то что вы называете Volume). Они будут более производительны с точки зрения СХД и рациональнее с точки зрения бэкапов (например используя Veeam).

    2. RDM-диски (презентация LUN непосредственно в ВМ) не нужно. Их нужно использовать только в тех случаях, где вендор СХД об этом прямо говорит, например при создании Windows Failover Cluster.

    3. Для SQL на 300 активных пользователей ваши диски скорее всего не потянут - нужны будут SSD. А учитывая, что у вас на этом же Tier ещё будет жить и почта, то есть риск, что вы просто упрётесь либо в IOPS на Dell, либо в пропускную способность дисков.

    4. Перед внедрением лучше сделать нагрузочное тестирование по дискам (у чанги есть отдельный инструмент для этой задачи).

    5. Для SQL есть отдельные практики:

    • размер кластера под БД  = 64 кбайта (default = 4 кбайта)
    • отдельная доменная УЗ для служб Database Engine, Reporting Services, SQL Server Agent
    • отдельные диски под DB, TempDB, Logs (DB + TempDB)
    • ограничить размер выделяемой ОЗУ (через Management Studio)
    • Размер логов (около 20% от размера БД)
    • Для сервисной УЗ задать в secpol.msc "Lock pages in memory", "Perform maintenance tasks"

    24 декабря 2019 г. 5:45
  • 1. Под виртуальные машины (AD, DNS, PRINT) сделал бы несколько LUN (это то что вы называете Volume). Они будут более производительны с точки зрения СХД и рациональнее с точки зрения бэкапов (например используя Veeam).

    - Я предполагал что будет один лун но все виртуальных серверов особо не нагружаемые СХД, где будет храниться только системный диск С, всего будет около 20-24 виртуальных серверов. Т.к разбивка на несколько лунов, ведет к ограничению размера самого луна, лучше один лун с нужным количеством свободного места для резерва, чем несколько но с ограниченным. Бекапы делаются на ленты через Symstnec Backup Ex, с ним проблем нету

    2. RDM-диски (презентация LUN непосредственно в ВМ) не нужно. Их нужно использовать только в тех случаях, где вендор СХД об этом прямо говорит, например при создании Windows Failover Cluster.

    - Тут я имел ввиду (не много не так выразился), что будут отдельный лун на схд со своим raid10 подключенные к тому же самому кластеру виртуализации (два физических сервера) и далее на них создаются VHDX диски для баз данных SQL, затем еще отдельный лун для логов и отдельный лун для баз данных exchange.

    3. Для SQL на 300 активных пользователей ваши диски скорее всего не потянут - нужны будут SSD. А учитывая, что у вас на этом же Tier ещё будет жить и почта, то есть риск, что вы просто упрётесь либо в IOPS на Dell, либо в пропускную способность дисков.

    - Тут да согласен, что нежно высокоскоростные диск, но точно не ssd живут они не очень долго. Для каждого луна, где будут храниться базы данных, будут куплены отдельные диски SAS.базы данных и логи для SQL - Lun1 на RAID10 из 10 дисков SAS 600Gb 15000.

    база данных и логов Exchange -  Lun2 на RAID10 из 10 дисков SAS 600Gb 15000

    файловый сервер и sccm - Lun3 на RAID10 из 10 дисков SAS 600Gb 15000

    5. Для SQL есть отдельные практики:

    Про это я знаю, только вот один вопрос, насколько целесообразно ставить модель восстановления full вместо simple? Сейчас как раз стоит фул, вот думаю лучше же для производительности модель восстановления простая?

    24 декабря 2019 г. 6:32
  • 1. "SSD живут не очень долго"

         да ладно, с чего вы это взяли?

    2. Модель восстановления SQL диктуется требованиями бизнеса по RPO и RTO. Если требований никаких нет (а так бывает), то берите Simple и делайте бэкап почаще (каждые пару часов). 

    3. Не забудьте настроить функционал снапшотов на СХД. Это бывает очень полезно. 

    24 декабря 2019 г. 6:54
  • SSD или SAS вообще не суть т.к. тут просто уже вопрос решен, что это SAS.

    А по моим тезисам постом выше, в целом правильная концепция? 

    24 декабря 2019 г. 7:29
  • В целом бы добавил, что лучше сделать LUN мЕньшего размера и затем его увеличивать по мере необходимости, чем сразу резервировать кучу блоков, которые не будут использоваться. 

    Ни в коем случае не использовать тонкие LUN и диски.

    Для оптимизации SQL, чанги лучше вначале почитать практики от вендора - тут

    • Помечено в качестве ответа NK-addc 24 декабря 2019 г. 9:47
    24 декабря 2019 г. 8:05
  • Про луны меньшего размера согласен.

    А, что значит тонкие LUN и диски?


    • Изменено NK-addc 24 декабря 2019 г. 8:54
    24 декабря 2019 г. 8:18
  • Пожалуйста.

    LUN

    VHDX

    • Помечено в качестве ответа NK-addc 24 декабря 2019 г. 9:47
    24 декабря 2019 г. 9:00
  • 1. "SSD живут не очень долго"

    А подскажите какие лучше SSD диски брать, на будущее?

    Спасибо.

    30 декабря 2019 г. 9:51