none
Подготовка СХД для MS SQL Server RRS feed

  • Вопрос

  • Всем привет!

    Уже 5 лет у нас работает кластер Windows Server 2003 + MS SQL Server 2005 (для 1С УПП).
    Совсем недавно места на СХД, на которой находились БД стало нехватать. Поскольку таких СХД (Xyratex DS5402) давно уже в продаже нет и валидированных дисков для них соответственно тоже  - было решено приобрести новую СХД IBM.

    5 лет назад когда я конфигурировал Зайротекс, по совету экспертов "чем больше шпинделей в массиве - тем быстрее" объединил 10 из 12 дисков в RAID10 (2 - в хот спейре) и нарезал его на LUNы - один LUN под БД, второй - под журналы транзакций, третий - под tempdb. Как известно 1С УПП - это OLTP и OLAP в одном флаконе, поэтому тут не удастся вынести аналитику на отдельный LUN (ну или я не знаю - как).

    Сейчас начинаю конфигурировать новую СХД с теми же 12-ю дисками и при изучении матчасти наткнулся на вот это:

    http://www.emc.com/collateral/hardware/technical-documentation/h2370-microsoft-sql-svr-2005-ns-series-iscsi-bp-plan-gde-ldv.pdf

    где сказано что лучше не надо смешиват физические шпиндели для БД и журналов (Recommendation #6). В связи с этим я думаю сделать два массива:
    6 дисков, RAID10 - БД

    4 диска, RAID10 - журналы транзакций, tempdb (ессно разные LUNы).

    2 диска - горячий резерв.

    С точки зрения производительности такая конфигурация СХД будет лучше чем делать один большой массив и резать его на LUNы ?

    Или разница будет мало заметна ?


    Andy Mishechkin

    23 апреля 2012 г. 19:08

Все ответы

  • Скажу сразу - я не очень большой специалист по построению СХД.

    Рекомендации от EMC в общем очень неплохие, но предложенная вами схема подойдет скорее для OLAP варианта, когда ваша 1С будет много читать, но мало писать.

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

    То, что Вы разобъете один массив (да еще и такой маленький) на отдельные LUN, Вы скорее усугубите ситуацию - у вас не станет шире канал, не появится больше шпинделей. Но головки дисков, скорее всего будут постоянно метаться между частями диска, "обслуживающими" разные LUN. То есть какой-нибудь запрос, которому потребовалось сохранить промежуточные данные в tempdb с гарантией будет тормозить процесс изменения данных, которому нужно писать в log.

    Я бы скорее разделил на пару RAID10 и одно зеркало, (DB-LOG-tempdb) распределив их по массивам в зависимости от вашей нагрузки.


    SQL Server MVP

    26 апреля 2012 г. 14:30