Как рассчитать необходимое количество ядер SQL серверу? #794712

Нужна отказоустойчивая система. в Enterprise SQL версии есть очень удобный механизм AlwaysON,Enterprise лицензируеться только Core, 2 ядра стоят 700к руб. соответственно возник вопрос, существует ли метода расчета потребности в ядах SQL сервера? хотя бы примерно? на резервый конечно по минималке взяли бы на 2 ядра, на основной надо думать

Ядер много не бывает

это понятно, но цены на них кусаются.... например если каждое последующее ядро будет давать выигрыш в скорости на 5% то от него можно отказаться ибо 5% не стоят 350т руб.

0. В связке с 1С на долю MS SQL приходится относительно небольшое количество отказов. Шансов что неопытный администратор ошибочными действиями положит кластер больше чем шансов что MS SQL ляжет сам или в результате отказов железа. 1. Если нужна только отказоустойчивость и режим активный узел/пассивный узел устраивает, то не обязательно брать Enterprise, Standard поддерживает. Косвенно на то что вам дростаточно Standard слово "резервный" указывает. 2. Лицензируется не меньше 4 ядер на сервер. И вроде бы не меньше 4 ядер на сокет, то есть если физический сервер и сокетов два то не меньше восьми, но тут я уже не уверен.

Каждое лишнее ядро никакого выигрыша по скорости не даст, это факт. Оно даст выигрыш по производительности - большее количество юзеров смогут работать.

если я правильно понимаю отличия между стандартом и ентерпрайзе только в том что в ентерпрайзе можно пассивную базу для чтения юзать? не подскажите где про это желательно по шагово почитать можно и как это называется? везде встречаю только примеры с AlwaysON

Нет. Как я понимаю, Standard поддерживает единственный режим когда работает один узел кластера, при отказе первого узла включается второй, хранилище у них общее. У Enterprise  много разных хитрых вариантов. Но я не понимаю как всё это великолепие использовать в связке с типовыми конфигурациями 1С на практике. Возможно как-то можно.

хотим без общего хранилища, с 1с как понял два варианта, или руками сервак прописывать вслучае падения, или через промежуточного слушателя который прописываеться в кластер 1с в качестве SQL сервера который вслучае падения SQl сервака будет переправлять запросы на резервный

Postgres Pro не рассматриваете? там есть очень интересная технология On-line backup (архивирование WAL)