Bankir.Ru
9 декабря, пятница 16:38

Объявление

Свернуть
Пока нет объявлений.

Действительно ли есть проблемы у Mssql с Scsi Raid массивами ?

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Действительно ли есть проблемы у Mssql с Scsi Raid массивами ?

    Недавно к нам с диаса приезжали - демонстрировали воркфлу и сообщили оЧень интересную новость - что они наткнулись на проблему (subj) и вообще советуют mssql (для WF) ставить на IDE диски...
    если кто встречался с подобными проблемами - то опишите их и методлы борьбы с ними, т.к. ставить mssql на IDE не считаю разумным.

  • #2
    хи-хи-хи.
    Ну только у воркфлоу наверно проблемы в MS SQL со скази-раид массивами.
    "А мужики-то не знают!?!?'.

    Ну а дословно что за проблемы?
    С уважением, Максаев Андрей.

    Комментарий


    • #3
      Бред, но уже широко распространённый.
      Известны два источника: "презентаторы" из Диа и разработчики некоего софта из Питера. Почему-то и те, и другие избрали площадкой для развешивания лапши Красноярск...

      Комментарий


      • #4
        Бред сивого дельфина. Работаю на ВФ Pro уже 2 года, ессно на SCSII RAID -- серверах -- никаких проблем нет. Системщики Диасофта обозвали эту информацию полной чушью. Уж не знаю, чем думал "презентатор", но точно не мозгами.
        Serg Voronov

        Комментарий


        • #5
          вот и я думаю что таких проблем вроде не было ....
          а предложение поставить mssql на IDE диски я лично сам слышал - причем от главного презентатора....
          до сих пор удивляемся

          Комментарий


          • #6
            Наверное - это в запале презентации, конечно откровенная чушь.

            Но вопрос - о том, какие и сколько нужно RAID под MS SQL сам по себе очень интересен. Если Вы считаете - что достаточно поставить один канал , разметить все одним большим томом и радоваться - то это неправильный ответ :-)) Регулярно на www.sql.ru подымаются вопросы под оптимальную разметку RAID для SQL серверов (и не только MS, но и Orcale, Sybase) . Рубятся серьезные специ - как всегда по "краям", но понятие - что каналов и дисков должно быть много - уже пришло. Как минимум другой канал нужен под файлы логов, затем нужно поделить базы на "медленно изменяемые" и "быстроизменяемые". Потом подумать - как сделать hot-spair устройства и ... получается самая скромная конфигурация в 36 дисков и 4 (!) RAID контроллера.
            Это по-научному, но в жизни - действительно - хотите хорошей производительности - подумайте что в SQL серверах производительность СИЛЬНО зависит от дисков и конфигурации контроллер(ов).

            Комментарий


            • #7
              А еще сильнее производительность SQL зависит от "кривизны" ручек разработчиков,
              За что и приходится платить пользователям как деньгами, так и нервами и здоровьем.
              С уважением, Максаев Андрей.

              Комментарий


              • #8
                А еще сильнее производительность SQL зависит от "кривизны" ручек разработчиков

                Не менее сильно производительность SQL зависит от "кривизны" ручек пользователей...

                Комментарий


                • #9
                  Ладно уж, поделюсь сокровенным. Вот идеальная настройка системы под документооборот 20-30 тыс документов в день (База ~ 50Gb). Система будет урчать от удовольтвия на такой раскладке - что и доказали экспериментально:

                  ===========
                  Контроллер RAID
                  ============
                  4-х канальный UW160 SCSI-PCI, обеспечивающий режим горячей замены и совместимый с материнской платой сервера.Хорошо себя зарекомендовали следующие модели контроллеров: Adaptec 3400S, Adaptec 3410, Adaptec 5400, Mylex eXtreme RAID 2000, Mylex eXtreme RAID 3000, Compaq Smart Array 5302, Compaq Smart Array 5304 и аналогичные. Если это допускается производителем и конструкцией сервера – можно использовать 2 2-х канальных контроллера, например 2*Mylex AcelleRAID 352 и аналогичные

                  =============
                  Разбивка дисков
                  =============

                  1-й канал – RAID1 (2*8GB). Для файлов Операционной системы, служб SQL, page file. (block size 4kb) ;

                  2-й канал – RAID1 (2*8GB). Для файлов transaction log (block size 8 kb) ;
                  3-й канал – RAID5 (5*18GB). Для файлов данных (block size 64 kb, RAID stripe set 64 Kb) ;
                  4-й канал – RAID1 (2*18GB). Для файлов tempdb (block size 8 kb);
                  ==========
                  Особенности файловой системы
                  ==========
                  Обратить внимание, что stripe set RAID для устройств баз данных должен быть 64Kb (по умолчанию 4Kb) и размер unit NTFS также 64Kb (по умолчанию 4Kb). Размер приращения для баз данных должен быть не менее 1Gb, чтобы предотвратить их излишнюю фрагментацию, т.к. при размере блока > 4Kb стандартные средства дефрагментации не работают.

                  Удачи !

                  Комментарий


                  • #10
                    2 bantik
                    Сергей, а эта Бхагават-Гита с системщиками согласована ? И почему ничего подобного нет в Технических требованиях?
                    Serg Voronov

                    Комментарий


                    • #11
                      bantik

                      Способ разнесения массивов по каналам вызывает удивление. И это очень мягко говоря.
                      Касательно Mylex 352: использовать контроллеры без BBU для критических приложений небезопасно, а BBU к ним в природе существуют, но на рынке что-то не очень представлены.
                      Насчёт размера страйпа и кластера - соответствует неофициальным рекомендациям MS для такого рода баз.

                      Комментарий


                      • #12
                        >Касательно Mylex 352: использовать контроллеры без BBU для критических приложений небезопасно, а BBU к ним в природе существуют, но на рынке что-то не очень представлены.

                        В 352-х BBU дается опционально. При поставке его как brand - он есть. Но если не заказали при покупке - дозаказать практически нереально.. А что вы хотели - начальный уровень и есть начальный уровень. В eXtreme RAID модуль BBU есть.

                        Насчет "супер надежности" и BBU - не забывайте элементарную вещь - серьезные сервера без UPS не ставятся. Что толку хранить 64 Mb кэш, если записать его на диск - доли секунды. Это время UPS элементарно протянет. Может быть - если нет hot-spair, если резервный диск убит или вдруг "взорвался" блок питания (и нет второго) - BBU поможет. Но это же надо так компьютер не любить :-))) (неплохие обзоры RAID можно найти на www.array.ru )

                        >Способ разнесения массивов по каналам вызывает удивление. И это очень мягко говоря.

                        Сделано это как раз для поддержки больших баз. Современные сервера на XEON MP могуть дать обмен до 3,2 Gb/s по шине - зачем же ее подсаживать на SCSI контроллере. (Для примера - Sun SunFARE может дать до 43,2 Gb/s - и в этом основной "конек" хранения баз на Solaris/Unix - а не в софте)
                        Возможно на каналах можно и сэкономить - но тогда придется обязательно играться адресами SCSI устройств (transaction log нужно ставить на "0" адрес)

                        Удачи !

                        Комментарий


                        • #13
                          bantik

                          > серьезные сервера без UPS не ставятся

                          Никакие серверы без UPS не ставятся. RAID-контроллер с включённым WB без BBU (да ещё с включённым кешом на запись на дисках) - тоже несерьёзно. Равно как и WT на серьёзном сервере БД

                          > если нет hot-spair, если резервный диск убит или вдруг "взорвался" блок питания (и нет второго) - BBU поможет.

                          При чём тут hot-spair?
                          Отказ по питанию вполне возможен, особенно в случае, если все БП висят на одном канале UPS, на дисковых полках БП зачастую вовсе не резервируются.
                          Ещё BBU может помочь при отказе канала или процессора контроллера.

                          > Современные сервера на XEON MP могуть дать обмен до 3,2 Gb/s по шине - зачем же ее подсаживать на SCSI контроллере.

                          Удивляет не само разнесение по каналам, а способ - по массиву на канал. Эффективнее распределять по каналам диски каждого массива.

                          Комментарий


                          • #14
                            2Vtb

                            Предлагаю с дискуссией завязать - а то модератор погонит. Можно долго общаться на тему Если контролер не сделан специально для СУБД (кэш с батарейкой и еще что-то), то на логическом драйве, где будет размещен журнал транзакций, должен быть настроен кэш обязательно в режиме "WRITE THRU". Хотя гораздо более производителен режим "WRITE BACK", для журнала транзакций его применять нельзя. Можно сделать так: файлы базы размещены на логическом драйве с кэшем "WRITE BACK", а файлы журнала - на логическом драйве с кэшем "WRITE THRU". Если же контролер специальный для СУБД, то можно все настроить "WRITE BACK>

                            http://www.sql.ru/articles/mssql/010...trollers.shtml

                            Но не нужно подменять специализированные форумы. Добро пожаловать на www.sql.ru !

                            Удачи !

                            Комментарий


                            • #15
                              :
                              Последний раз редактировалось VTB; 14.02.2003, 15:54.

                              Комментарий

                              Пользователи, просматривающие эту тему

                              Свернуть

                              Присутствует 1. Участников: 0, гостей: 1.

                              Обработка...
                              X