Дилемма, т.к. с кластерами SQL не знаком, прошу подсказать имеющим опыт.
Есть сервер двухпроцововый по 4 ядра на камне (т.е. имеем 8 ядер), но его стало нехватать (проца и ОП), думаю, что лучше докупить? такой же и сделать кластер SQL или заменить на четырехпроцовый с большей ОП?

От кластера какие плюсы?
1. Лучше отказоустойчивость (один сломался, второй работает)

Но есть вопросы, база данных при кластере где хранится?

Добавьте коллеги свое мнение.

Спасибо.

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

(1) Надеюсь на ответы

(2) http://v8.1c.ru/overview/Term_000000126.htm#1

У нас работает отказоустойчивый кластер SQL (два сервера).
Дорого это..

(4) В чем именно дороговизна?

почитал http://www.osp.ru/win2000/2010/01/13001641/
так и не понял,  с чего кластер СКЛ должен увеличить производительность

вы его потом накуривать будите?

В том что у тебя всегда включены два нехилых сервера, а работает (ну в смысле выполняет потребности организации) всегда только один из них.

(6) кластер только из двух SQL серверов никак не увеличивает производительность. Это только отказоустойчивость.

(9) так и я об этом, хотел собственно узнать, что автор курил

>>Но есть вопросы, база данных при кластере где хранится?
Естественно база хранится на внешнем дисковом хранилище.

(0) Озвучь объем базы и конфу (речь же про 1С идет?)...

(0) лучше кластер 1с-серверов сделай... Увеличит скорость...

(13) Кластер 1С уменьшит нагрузку на SQL-сервер?

(13)да фиг знает.. имхо узкое место обычно всегда сервер БД, а как MSSQL кластеризовать с распределением нагрузки..
тут я не копенгаген, до такого не доходило как-то :)

(0) возможно стоит разделить сервер БД и сервер 1С если это еще не сделано.

(15) Ну, распределённые вьюшки и т.п...
Но на 1с это поднимать... С мягким знаком получится...

(16)
Чтобы приложение работало в кластере MS SQL  оно должно быть специально спроектировано. Если упрощенно,  приложение должно уметь хранить свои данные в разных серверах. Примером такого приложения является MS Project  Server. В утешение можно сказать, что во многих случаях переделка под кластер достаточно проста, но можно встретить и серьезные проблемы (см. ниже).
Следствие из предыдущего пункта. Создание кластера MS SQL  не является чисто административным усилием, т.е. недостаточно просто положить базу в кластер.
http://www.microsoftproject.ru/articles.phtml?aid=47

(0) Что еще крутится на SQL-сервере?

Балансировка нагрузки

Для начала опровергнем одно распространенное заблуждение. Кластеризация MSCS используется для повышения уровня доступности, а не для балансировки нагрузки. Кроме того, сервер SQL Server не имеет встроенной возможности автоматической балансировки нагрузки. Балансировать нагрузку необходимо посредством физического проектирования приложения. Что это значит?

С ростом размеров таблицы следует ожидать ухудшения быстродействия, в частности, при сканировании таблицы. Когда количество строк достигает миллионов и миллиардов, обычным решением до сих пор являлось использование секционированных представлений. Эти секционированные представления состоят из таблиц с одинаковыми схемами, объединенных с помощью инструкций UNION ALL. Кроме того, для различения таблиц-компонентов устанавливаются проверочные ограничения (инструкция CHECK), что предотвращает дупликацию данных в секционированном представлении. Если столбец, используемый в проверочном ограничении, является частью первичного ключа, то представление является обновляемым.

Если таблицы-компоненты расположены на отдельных файловых группах, то для повышения быстродействия дисковой подсистемы можно распределить файлы этих файловых групп по разным физическим дискам. Можно даже размещать таблицы в разных базах данных. Однако размещение всех данных в одной базе данных позволяет использовать возможности секционирования таблиц, предоставляемые сервером SQL Server 2005. Реализовать такое секционирование значительно проще.

Но допустим, что уже испробованы все возможности секционирования таблиц или создания (локальных) секционированных представлений, а быстродействие все равно не на высоте. Если вы пользуетесь сервером SQL Server 2000 или SQL Server 2005, можно воспользоваться распределенными секционированными представлениями. Основное их отличие заключается в том, что таблицы-компоненты могут располагаться на разных экземплярах сервера SQL Server, и эти экземпляры могут быть установлены на кластере с конфигурацией «N+1». В чем же смысл такого решения? Если таблица-компонент в секционированном представлении становится недоступной, недоступным становится и всё представление. Если же сделать эти таблицы-компоненты частью кластера, это предоставит стабильность, необходимую для обеспечения быстродействия и балансировки нагрузки.
http://www.oszone.ru/4566/SQL_Server

(18) у нас работет сервер 1С в этом отказоустойчивом кластере.
Как думаешь, оно (сервер 1С) специально спроектировано? :)
Начиная еще с 8.1. Нет там ничо хитрого. Это общие слова от MS.

(21) вообще то, да...
кластеризация серверов 1С в 8.1 и 8.2 разные вещи

http://www.gilev.ru/1c/app/#k81

(21)+ Тем не менее надо признать, что доля истины в них есть. Но она не раскрыта в (18). Все зависит от задач.

(24) так вот и надо понять, что можно распараллелить на кластере скл, мне пока это как то не очень понятно

(22) неее, я не про родную 1С кластеризацию. Это так сказать совсем другое. Собственно она у нас не используется кластер 1С состоит из одного сервера, MSSQL сервер там же. Нам хватает. Главное в типовые конфы много народу не пускать. :)

(26) ты уже определить о чем ты говоришь,
есть кластеризация 1С,
есть кластеризация СКЛ...
ты собственно о чем?

я о кластеризации MS.

(28) и как у вас нагрузка балансируется на СКЛ ?

(29)нет этого, я же говорю, только отказоустойчивость. Имхо распределение нагрузки в MSSQL это вообще задача практически не решаемая (ну или псевдорешаемая), а тем более под базой 1С это вообще проблема, т.к. структурой базы в 1С на таком уровне управлять невозможно.

У нас сделано только вот что. Если по какой то причине рабочий сервак накроется медным тазом (скажем сдохнет память, блок питания, мамка, да что угодно), то автоматически начнет работать другой сервер. При этом на него перейдут все боевые процессы: MSSQL, сервер 1С, IIS (для веб-сервисов).

(30) так по той то ссылке написано про нагрузку

(31) оно не противоречит (18)

клястер как бы немного надежнее (усреднено), но слабее одного (тут тоже обстоятельства могут перевешивать)

(31) Каким решением это реализовано?

Вцелом я понял - для увеличения пр-ти лучше приобрести более мощный сервер

(35)этим и реализовано, кластеризация серверов от MS, которую поддерживает MS Windows Server 2003 R2 Enterprize Edition с помощью специальной службы "Служба кластеров".
Там все компоненты: MSSQL, сервер 1С, и IIS надо устанавливать несколько хитрее, но вообщем-то ничего сложного нет.

(35)сказано в (28)

(31) Данные где лежат? На внешнем хранилище? Что будет, если внешнее хранилище упадет?

+38 SQL какой?

(38) в этом случае конечно же будет будет полный отказ всего кластера. А по-другому никак. Внешнее дисковое хранилище может быть только одно. Это то общее что и объединяет эти два сервера. База данных ведь может быть только в одном экземпляре всегда.

(31) эти риски страхуются другими спец. средствами: резервное копирование, зеркалирование MSSQL и т.п. Мне достаточно резервного копирования с бекапом лога каждые 15 мин. Кстати бекап естественно на другой хост в сети.

(41)->(38)

(39) 2000 EE
т.к. там еще 77 хостится, база SQL, но каталог ее базы тоже на внешнем хранилище.

(40) Зераклирование не пробовали, сильно интересно подтормаживать будет?

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

Естественно TCP/IP сокет рвется, естественно приложения требующие постоянного подключения (к которым относится 1С) падают. Между 1С 77 и 8 разница только в том что 8ка грамотно предлагает пререзапуск приложения.

А вот клиентские приложения не требующие постоянного подключения могут и вообще ни чего не заметить. Именно на таких приложениях и любят демонстрировать возможности своей кластеризации серверов майкрософтовцы. И именно эта особенность по большей части и имеется в виду в их заумной фразе "приложение должно быть специально спроектировано".
Т.к. в кластерную группу можно засунуть любую службу на общих основаниях, службе кластеров пофиг. Просто для некоторых служб типа MSSQL там есть спец. средства.

(44)Нет, не пробовали, на кой оно леший. Есть кластер, есть бекапы.

(0)Кластер в первую очередь увеличивает отказоустойчивость.

На счет приложений не требующих постоянного соединения. Тут MS просто рассчитывают на пулинг соединений к MSSQL на хосте клиента. Т.е. приложение как бы коннектится каждый раз когда ему нужно сделать запрос, что вобщем-то так-то не эффективно с точки зрения оптимизации ресурсов и быстродействия. А на самом деле OLEDB провайдер или ODBC драйвер соединения кладет в пул и придерживает, не закрывает сразу, ну и соответственно может выдать соединение из пула быстро, а клиент думает что он зацепился заново.
Так что MSовцы вобщем-то тут правы.

в общем на до параллельного программирования как до китая раком

(40) Если упадет внешнее хранилище, как восстанавливать кластер?

(50)Вероятно пересбором кластерных групп на новое внешнее хранилище. Там ведь еще у каждого сервера есть свой жесткий диск. Собственно это диск С. Он в каждом серваке, а не во внешнем хранилище.
Собственно на нем все и установлено (программные файлы, просто надо следить за тем чтобы они были одинаковые).
При отказе внешнего хранилища оба сервера останутся работоспособными.
Понятно что внешнее хранилище это весьма узкое место. Но там дофига дисков, с автозаменой (оно само может сдиагностировать отказ диска и вставить вместо него специальный винт который стоит в резерве). Неплохой рейд-контроллер. Собрано несколько рейд-массивов.

(50) а с чего ему падать?

(51) есть варианты сборки, когда ОС стартует с внешного хранилища

(52) не ну упасть может любая железяка конечно. И надо сказать что чаще всего случается что падают винты относительно других конструктивных частей серверов.
Главное не подогревать серверную. У нас там блин даже сигнализация на кондиционер зацеплена. Если что охрана бдит.

(53)ну, может и можно, но зачем..?
Дело в том что для диска С (где лежат программные файлы) особая скорость не нужна. А место в хранилище дорогое так-то, совмещать задачи которые щас у меня решает диск С с каким-то из массивов в хранилище тоже не желательно..
Так что имхо такой вариант предпочтительнее.

(55) дешевизна...
лезвия будут проще и дешевле
так что такие варианты блэйд-серверов есть...
раз есть, значит покупают

(56) дак вроде тока на два винта все удещевляется-то вроде..

(57) тепловыделение, электричество...
я же грю, раз делают, то значит, что покупают

верю-верю
Вы бы лучше про лицензирование спросили, там не все шоколадно с сервером 1С. Ключик-то переставлять надо.

(59) если сервер 1С на отдельной машине то ничего переставлять не надо, либо можно купить вторую лицензию на сервер и развернуть еще и кластер серверов 1С

А вот MS например явно пишет что на MSSQL нужна всего одна лицензия, не смотря на то что стоит два экземпляра.

(61) зато кластер 1С, может распределять нагрузку

Да что ему там распределять, у него нагрузки-то хрен да маленько, вся основная нагрузка на сервере БД.
Если его выделять на отдельную машину, ее тоже кластеризовать для отказоустойчивости? будет та же проблема с ключом - да нафиг, не стоит это таких затрат.

(63) усе зависит от задач, если тебе не надо, то надо другим
тем более ты 8.2 еще не видел

(64) я на на ней работаю с 13.202

(62) тады должен знать, что идет тенденция к повышению требований к серверу 1С

ЗЫ. сейчас из за организационных моментов, сервер 1С оказался на одной машине с SQL...
мля это жесть!
уже 5 часов накатываю обновление на копию базы (помещение в хранилище обновление конфы + обновление БД + запуск обработок обновления)

хоть спать уходи

Сервер 1С - на мощной пользовательской машинке с большой оперативкой + 1 в запасе (штатно его используют разработчики).
Сервера SQL - в кластер.

Да проще еще лицензию на сервер 1С купить.

(66) офигеть, чо так долго-то?

(68) Если это на мой пост, то не соглашусь:
1. сервера 1С и SQL нужно разносить;
2. для надежности лучше кластер SQL-серверов.

(69) 1С и SQL оба память любят. Поэтому на одной железке не уживаются.

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

(69) а вот так

(71) При наличии подменного (как в 67) сервера 1С поднять систему при падении сервера 1С можно быстро.
Если упадет единственный SQL (пусть бэкап и есть) - это надолго. Согласны?

(73) не критично, да и вероятность падения очень низкая

(74) Если встанет транспортный терминал, сорвется отправка десятка фур товара оптовикам - это не критично? Я завидую Вашим нервам :)

(0)
вся крупная розничная торговля запада использует trade house
эти чудики поделки от 1С + еще и кластер гыыыыы

Жесть парень совета попросил а DmitrO и Дарлок развели демагогию, обменяться и контактами и общайтесь между собой.

Мое предложение такое, пока есть более мощные компы, по нормальной цене, то можно брать их. Ведь кластеры начали создавать не просто потомучто это кому-то нравилось, а потомучто уже круче серверов не было, вот и приходилось из 2,4... и.т.д делать 1 "большой" комп.
Сервер 1с тоже легко перенести на другой комп.

(77) Есть версия, что плюс кластера еще и в отказоустойчивости. Об этом толкуем.

(75) у нас нет такого, поэтому нервы у меня в порядке :)

(74) согласен с тем, что время перенаправления на другой сервер 1С не большое, но кластер быстрее и автоматически. И единственное препятствие - система защиты.

(77)
рано или поздно все русское сообщество торгашей выкинет нах.. 1с и поставит нормальную товароучетку trade house
1с для бухии
товаро учет - изврат

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

(80) выноси сервер 1С на отдельную машину и не будет у тебя такой проблемы...
а насчет времени восстановления так это обычное требование к ИС, которую нужно выявлять...
для кого то 3 суток восстанавлить ничего страшного, а кому то и 15 минут смерти подобно

(82) о чем и речь... у меня и падение на сутки не проблема

(78) Ну для отказоустойчивости можно для начала поставить RAID, это дешевле второго сервака.

(85) кхм... системы без рэйда вообще не обсуждается, мы тут не ларьки обсуждаем

(85) для отказо устойчивости бэкап
рэйд для скорости...

(86) Автор про райд не писал, не факт что у него он есть

(87) А бэкап тогда каждые 10 минут надо делать?

(89)
отказ из за сбоя работы жесткого диска - дело довольно редкое

а вот могут быть и другие причины

у нас например распред база на trade house :)
если что то дохнет - восстанавливаем с центральной мааааксимум без бэкапа 20 мин - если филиал удален и скорость канала низкая.....

+(90)
центральная - 5 мин всю
из бэкапа + филиалы синхронизируют сами

+(90)
за 6 лет один раз сдох диск в филиале

всем нашим смаркетам привет :)

(92) за 3 года, 4 диска IBM-их по гарантии сменили

Эффективные кластеры(по крайней мере распределенные) с балансировкой нагрузки или даже с реалтайм синхронизацией данных это миф:)

(95)вот мне тоже так кажется.

(89)
как вариант - заведи распределенную базу где нить в уголке и синхронизируй каждые 10 мин :)

+(97) хотя честно как она в 1С работает - не помню, может и нельзя центральную восстановить из клиентской