Не хватает производительности SQL Server 2000, хотим попробовать поставить его на кластер.
Вырастет ли его производительность и не придется ли переписывать софт под это дело?
Противоречивые сведения...
Чтобы такое почитать, посоветуйте плиз...

судя по посталеной задаче вам обязательно поможет, ставте не сомневаясь !

Здравствуйте, Аноним, Вы писали:

А>судя по посталеной задаче вам обязательно поможет, ставте не сомневаясь !

где б починать? =(

кто-нидь вообще пишет для sql server'a на кластере?

Доброго времени суток, BillyBoy!

А>>судя по посталеной задаче вам обязательно поможет, ставте не сомневаясь !

BB>где б починать? =(

BB>кто-нидь вообще пишет для sql server'a на кластере?

Эээээ ....
Что значит писать?

У нас как не стало хваталь сервака — то прикупили 2 помощнее, поставили в кластер и поехали... В сети он виден как один, и подключаемся поэтому к одному инстансу сервере SQL, а фактически это 2 системника. Автоматом переключается с одной ноды на другую. Производительность заметно высше, да и надёжнее... если одна нода выпадает по каким-либо причинам, то вторая вытянет пока не произойдёт замена/ремонт/ещё_что-то_там_такое. А ещё если что-то с винтами с базой на одном случается — то всегда есть гарячая копия

А читать надо наверное только о тома как правильно поставить Виндовоз на кластер и SQL Server + все необходимые приблуды для вашего конкретного случая...

Фактически бояться нечего, упасть производительность точно не упадёт!

Есть один момент: желехо на нодах должно быть идентичным!

S>Эээээ ....
S>Что значит писать?

S>У нас как не стало хваталь сервака — то прикупили 2 помощнее, поставили в кластер и поехали... В сети он виден как один, и подключаемся поэтому к одному инстансу сервере SQL, а фактически это 2 системника. Автоматом переключается с одной ноды на другую. Производительность заметно высше, да и надёжнее... если одна нода выпадает по каким-либо причинам, то вторая вытянет пока не произойдёт замена/ремонт/ещё_что-то_там_такое. А ещё если что-то с винтами с базой на одном случается — то всегда есть гарячая копия

S>А читать надо наверное только о тома как правильно поставить Виндовоз на кластер и SQL Server + все необходимые приблуды для вашего конкретного случая...

S>Фактически бояться нечего, упасть производительность точно не упадёт!

S>Есть один момент: желехо на нодах должно быть идентичным!

Спасибо за ответ!
НО, например здесь написано, что производительность НЕ вырастет в кластере:
http://www.whatcar.ru/text/176626.html
а именно фраза "Прежде чем создать кластер, нужно понять, что кластеризация в Windows используется только для целей высокой отказоустойчивости. Она не повышает производительности SQL Server, поскольку в каждый момент времени работает только один сервер — связанные серверы не обрабатывают запросы вместе."


и еще где-то читал, что софт надо будет немного переписывать под кластер...

Доброго времени суток, BillyBoy!

BB>Спасибо за ответ!
BB>НО, например здесь написано, что производительность НЕ вырастет в кластере:
BB>http://www.whatcar.ru/text/176626.html
BB>а именно фраза "Прежде чем создать кластер, нужно понять, что кластеризация в Windows используется только для целей высокой отказоустойчивости. Она не повышает производительности SQL Server, поскольку в каждый момент времени работает только один сервер — связанные серверы не обрабатывают запросы вместе."
BB>

Возможно я выразился неправильно, но юзерам стало легче.... А их порядка 50, которые неслабыми выбрками озадачивают жизнь серваку, + 4 сервера занимаются только тем что данные заливают в базу по мере поступления.
У нас была такая фигня что периодически система была загружена на 100%. Причину админы не раскрывали, могу предположить из-за диференцированных бекапов или ещё чего-то... А сейчас после переключения на свежую ноду как я понимаю память оперативная в основном свободная, и это даёт серваку где разгуляться...

BB>и еще где-то читал, что софт надо будет немного переписывать под кластер...

Софт однозначно не переписывали, ему то 100% пофигу скольсо физически системников, инстанс SQL Server-а то один, название то одно... я ж писал что и в сети кластер киден как один комп...

Здравствуйте, soljen, Вы писали:

S>Доброго времени суток, BillyBoy!

S>Возможно я выразился неправильно, но юзерам стало легче.... А их порядка 50, которые неслабыми выбрками озадачивают жизнь серваку, + 4 сервера занимаются только тем что данные заливают в базу по мере поступления.
S>У нас была такая фигня что периодически система была загружена на 100%. Причину админы не раскрывали, могу предположить из-за диференцированных бекапов или ещё чего-то... А сейчас после переключения на свежую ноду как я понимаю память оперативная в основном свободная, и это даёт серваку где разгуляться...

BB>>и еще где-то читал, что софт надо будет немного переписывать под кластер...

S>Софт однозначно не переписывали, ему то 100% пофигу скольсо физически системников, инстанс SQL Server-а то один, название то одно... я ж писал что и в сети кластер киден как один комп...

жаль...
а как же быть, если НАДО увеличить производительность системы?
переходить на Оракл

BB>а как же быть, если НАДО увеличить производительность системы?
BB>переходить на Оракл

Без понимания причин торможения на MSSQL — врядли поможет.

Здравствуйте, Igor Trofimov, Вы писали:

BB>>а как же быть, если НАДО увеличить производительность системы?
BB>>переходить на Оракл

iT>Без понимания причин торможения на MSSQL — врядли поможет.

огромная база, куча обращений... 120 человек одновременно работают, куча сложных запросов...
база историческая, ничего не удаляется из нее...
а база данных будет еще раз в пять больше... кол-во обращений в 5 раз должно вырасти...

Здравствуйте, BillyBoy, Вы писали:

BB>Вырастет ли его производительность и не придется ли переписывать софт под это дело?
Сходу не скажешь, смотря на какой кластер и что за приложение.

BB>Противоречивые сведения...
Неудивительно. Кластеры-то разные бывают. Есть те которые для производительности, а есть те, которые для отказоустойчивости, а есть которые и то и то. Соответственно под это все нужно и разное железо и софт по другому настраивать и отчасти переписывать или не переписывать.

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, BillyBoy, Вы писали:

BB>>Вырастет ли его производительность и не придется ли переписывать софт под это дело?
IB>Сходу не скажешь, смотря на какой кластер и что за приложение.

BB>>Противоречивые сведения...
IB>Неудивительно. Кластеры-то разные бывают. Есть те которые для производительности, а есть те, которые для отказоустойчивости, а есть которые и то и то. Соответственно под это все нужно и разное железо и софт по другому настраивать и отчасти переписывать или не переписывать.

ммм... судя по тому, что нарыл в тырнете, sql server 2000 для повышения производительности масштабироваться не может =(

или я не прав?

Здравствуйте, BillyBoy, Вы писали:

BB>ммм... судя по тому, что нарыл в тырнете, sql server 2000 для повышения производительности масштабироваться не может =(
Значит где-то не там рыл... И что такое "масштабироваться для порвышения производительности"?

BB>или я не прав?
Нет, не прав.

Если нужен именно кластер, то для MSSQL реализовано два варианта совместной работы нескольких машин — один из вариантов называют failover кластер, другой — кластер на основе distributed partitioned views (DPV).
Количество узлов, на которых может работать failover кластер определяется операционной системой. Узлы, естественно, не просто обеспечивают hot standby, а могут нести полезную нагрузку. При этом кластер можно сконфигурировать так, что все будут подстраховывать всех. Например, на одном узле может стоять SQL Server, на другом Exchange, на третьем IIS. При падении любого из них, оставшиеся возьмут на себя дополнительную нагрузку в соответствии с приоритетами и порядком, который задаётся администратором кластера. Это кластерное решение для обеспечения отказоустойчивости.

DPV конфигурации уже никак не связан с поддержкой кластеров в OS и могут разворачиваться на любом количестве не обязательно одинаковых машин. По сути — это чистое распараллеливание нагрузки, которое, правда, эффективно работает только для определённого (хотя и довольно широкого) класса OLTP задач типа TPC-C.

Оба решения можно скомбинировать и, скажем, сделать высокопроизводительный кластер, узлы которого одновременно являются частью scale-out решения с DPV. В результате получается отказоустойчивая масштабируемая конфигурация.

Однако, если масштабирование с DPV для задачи не подойдет, то выгоднее купить один большой сервер с большим количеством памяти и правильным дисковым массивом и развернуть базу на нем — это будет эффективнее чем кластер. СУБД в принципе тот класс задач, где кластер, как способ масштабирования, подходит в довольно ограниченом количестве случаев.

Здравствуйте, IB!

Спасибо за исчерпывающий ответ !
Все ясно и по делу.
Похоже надо копать в сторону DPV...

Здравствуйте, BillyBoy, Вы писали:

BB>Не хватает производительности SQL Server 2000, хотим попробовать поставить его на кластер.
BB>Вырастет ли его производительность и не придется ли переписывать софт под это дело?
BB>Противоречивые сведения...
BB>Чтобы такое почитать, посоветуйте плиз...

Напиши письмо в Microsoft
Они тебе подробно ответят

BB>огромная база, куча обращений... 120 человек одновременно работают, куча сложных запросов...
BB>база историческая, ничего не удаляется из нее...
BB>а база данных будет еще раз в пять больше... кол-во обращений в 5 раз должно вырасти...

Вы понимаете, что "волшебства Oracle" не существует?

В первую очередь производительность определяется архитектурой системы (включая архитектуру СУБД и структуру данных).
Если у вас нет сильного смешения OLTP и OLAP запросов, то различия в архитектурах самих MSSQL и Oracle можно считать незначительными и все существенные вопросы по производительности следует относить к архитектуре вашей системы и структурам данных. Ну, и потом уже, к железу, конечно.

То что вы описали выше, еще никоим образом не свидетельствует ни о масштабах задачи, ни о причинах торможения вашей реализации на MSSQL.

Производительность на active-active кластере (если его умеет MSSQL) может и упасть (как и на Oracle RAC).
Потому что бесплатного "волшебства кластера" тоже нету. Зависит от задачи и от реализации.

Доброго времени суток, BillyBoy!

BB>а как же быть, если НАДО увеличить производительность системы?
BB>переходить на Оракл

Согласен с Igor Trofimov!

Может стоит пересмотреть архитектуру базы, или может стоить нарастить железо... Кстати, что у вас под капотом?

Здравствуйте, soljen, Вы писали:

S>Доброго времени суток, BillyBoy!

S>Может стоит пересмотреть архитектуру базы, или может стоить нарастить железо... Кстати, что у вас под капотом?

архитектуру однозначно надо пересматривать и есть куда оптимизировать...
под капотом пока что 4-х процессорный Xeon и скази райд...

Povysheniya proizvoditel'nosti mozhno dobit'sya pri raznesenii baz (esli ih konechno neskol'ko) po nodes na active-active cluster.
Esli sil'no ispol'zuemaya baza odna, to togda cluster pomozhet tol'ko dlya podstrahovki.

Доброго времени суток, BillyBoy!

BB>архитектуру однозначно надо пересматривать и есть куда оптимизировать...
BB>под капотом пока что 4-х процессорный Xeon и скази райд...

Что за рейд?
Сколько весит база?