если порядка 100 мелких баз 1с77 и 8, в которых работают порядка 100 пользователей.
причем одни группы работаю в одних базах, другие в других и они не пересекаются.

думаю как их максимально эффективно распределить по серверам.
можно взять 1 мощный сервер с 2 процами по 8\16 ядер.
можно взять 2 сервера по 1 процу по 8\16 ядер
или даже 4 сервера по 1 проц с 4\8 ядер

с одной стороны 1 мощный сервер вроде как некоторая экономия на железе.
хотя на самом деле не совсем так, т.к. например планка 16гб оперативки стоит дороже чем 2 по 8 или 4 по 4) и 2 проца 4/8 часто можно найти дешевле чем 1 8\16 ит т.д.
и экономия на электроэнергии.

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

собирать это все думаю на 2011 или 2011v3 платформах как самых дешевых по соотношению цена\тактовые частоты.  из тех соображений, что в случае чего можно эти компы поставить кому-то как офисные или распродать.

буду рад конструктивным советам, возможно здесь люди, решавшие подобные задачи

(0) я за два идентичных сервера, с предустановленным одинаковым ПО
в штатном режиме сиквел и rphost разделены, в аварийном слиты

плюсую (1)

у нас так и есть : два одинаковых сервера с одинаковым ПО.
Только немного пожадничали на 1С ключ серверный - он только 1. Т.е. для пользователей можем дать один 1С, не два.
В текущем штатном режиме на одном 1С и на другом СУБД. Если возникают форс-мажор или плановые какие-то работы, то перебрасываем все на какой-то из двух.

Если бы было 1с ключей на сервер без ограничений, то поставили бы 2+2 т.е. (1С-СУБД)х2

Но просто даже если не возникает проблемы с количеством железа и софта, то по резервированию электропитания проблема все равно возникнет и поставит ограничение на количество серваков в одной серверной.

Я тоже согласен, что 2 сервера вроде как лучше чем 1.

А 4 лучше чем 2?

Вопросы ПО можно не брать во внимание

(4) Ну вот у нас желание поставить 4 одинаковых и мощных обломалось возможностями по электропитанию.

(4) Бери 16, че жаться. Главное, чтобы было 2 в степени. Это важно, тру-программисты любят такие числа.

(6) мощный в твоём понимании какую конфигурацию имеет?

Интрига..

(7) 16 мне пока нечем будет занять. Но в будущем вполне возможно)

(8) из твоих вариантов вот этот - 2 сервера по 1 процу по 8\16 ядер.
Памяти в них 32 или 64 вполне будет достаточно. На одном 1С и на другом СУБД.

з.ы. 2-ух процессорные именно в наших условиях (примерно на 100 пользователей) избыточно.

(0) 100 пентиумов первых уже предлагали?

(11) скажем так, пользователей чем больше можно будет впихнуть, тем лучше.
у меня сейчас несколько серверов с характеристиками 4(8)*4Ггц + 32Гб тащат примерно по 50 активных пользователей. это при том что на каждом используется схема линух в качестве хоста + виртуалка и на виртуалку я отдаю их этих 32гиг только 16-20.

я вообще думал взять 2х процессорную китайскую мамку на 2011v3 сокете, воткнуть в нее e5-2678v3 (12(24)*2,5), второй сокет будет про запас пусть мало ли. Если не мучать мамку разгонами процов, то думаю работать будет не сильно хуже чем серверные брендовые мамки, а сгорит если, то не проблема купить новую.
А если брендовую серверную мамку под 2011v3 брать, то это скорее всего будет б\у, во-вторых существено дороже, то есть под 2011\2011v3 вроде как некитайские мамки и нет особого смысла брать.
под задачи 1с для обеспечения комфортной работы максимального количества пользователей вроде как важнее количество ядер, то есть 12 ядер по 2,5 скорее всего будут лучше тащить чем 4 по 4, а стоят существенно поменьше, плюс если второй проц добавить и памяти нарастить до 128 гиг, то вообще неубиваемый тазик должен получиться.
а рядом можно поставить еще такой же сервачек с одним процом.

просто не совсем понимаю как сравнить производительность системы 8*2,5 vs 4*4 под нагрузкой. У меня несколько серваков на 2011 сокете, но они не особо нагруженные, тест Гилева что ли погонять на них, хотя он вроде как одно ядро только тестирует.

посмотрел статистику из теста Гилева - в sql варианте [email protected] показывает 32-37, а 2678v3 выдает 25-32, то есть разница 32/25=1,28, примерно как и соотношение частот 3,4/2,5=1,36, но так как у 2678v3 ядер больше в 3 раза, то он в вроде итоге в 2,2 раза производителей. Хотя на практике не все так просто.

(13) "на практике не все так просто" -золотые слова

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

// Хотя на практике не все так просто.

Скорей всего, что рассматривается некая платформа 1С, которая не актуальная на сегодня.
Потому что раскидать разных пользователей на множество ядер можно только указывая для 1С флаг в настройках "1-база на 1-рпхост"
Если этим флагом не пользоваться, но на 1С создается 3-4 рпхост, а вся толпа из остального множества ядер простаивает без нагрузки.
А поэтому, если говорить о виртуальном железе, но на таких настройках ставить более 4-ех ядер в каждую машину нет особого резона.
Но зато машин можно создать множество на хорошем/толстом хосте :-)

Чтоб советовать что-то более конкретное нужно тестирование, именно, что не только в железе, но на конкретном наборе ПО

Как замечено в 1с8 чем больше частота процессора тем лучше.
При обычной работе пользователей это будет не так заметно,
а вот при перепроведении документов за период тут прирост в скорости
проца будет сильно влиять на время проведения.

Вот результаты с тестов Гилева:
SQL  - Intel(R) Xeon(R) CPU E5-2678 v3 @ 2.50GHz - 32,89 попугя
Файл - Intel(R) Xeon(R) CPU E5-2678 v3 @ 2.50GHz - 65,79 попугя

SQL  - Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz - 42,02 попугя
Файл - Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz - 73,53 попугя

Т.е. на E5-1650 v3 документы перепроведутся на 15-25 % быстрей

Если же взять Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz с турбобустом до 4.70 GHz
то будет еще лучше.

SQL  - Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz - 50,51 попугя
Файл - Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz - 96,15 попугя


Я бы если выбирал начал считать с пары, тройки серверов на десктопных i7-9700, потом смотрел по деньгам
Один сервер я бы точно не ставил, потому что без запасного сервера это как без рейда, страшновато.

(17) тоже смотрел на i7-9700\9700K
да, классный проц, но i7-9700 стоит баксов 300-350, плюс мамка к нему баксов 100-150 (односокетная, двухсокетные 1151 а двухсокетныеот 600). Т.е. итого баксов 400-600
при этом ядер 8/8
то есть по сравнению с 2678 в 1,5 раза больше попугаев вроде как, но в 2678 людей-то воткнуть можно больше к 3 раза, а комплект из 2678 + мамка обойдется в 200 баксов.
то есть этот прирост скорости в 1,5 достигается удорожанием попугая на ядро в 4 раза.
2678 - 30 попугаев, 24 ядра - 200 дол, 1 ядро стоит 200/24=8,3дол, стоимость 1 попугая = 8,3/30= 0,27
9700 - 50 попугаев, 8 ядра - 400 дол, 1 ядро стоит 400/8=50дол, стоимость 1 попугая = 50/50= 1
память я считал, что одинаково стоит, и можно не учитывать

(18) Ну я вижу что Вы и сами все понимаете. Так что если пользователям не критична разница во времени перепроведния базы, может у них (документооборот небольшой) то и вопроса не возникает что брать. На мой взгляд пару серверов на 2678v3 закроют и потребности по 1с и остальные. Поставить например esxi на оба сервера, настроить виртуалки, и бэкап виртуалок на разные сервера чтоб в случае сбоя можно было быстро поднять на другом сервере и можно ставить и почтовый сервер и доменный и остальное.

(16) сейчас у меня используется 8.3.9 и 8.3.16, галка "1-база на 1-рпхост" нигде не стоит, да ее в 8.3.9 вроде как и нет,так что действительно создается3-4 рпхоста.
но самые активные\нагруженные базы они как раз таки файловые, это базы инет магазинов, и там основная деятельность пользователей - они судят в 1с заказах, которые им прилетели с сайта, плюс у них открыты хромы с кучей закладок, вайберы\телеги, то есть все такое не особо скоросте зависимое, но его просто дохрена.
есть у меня на i9-9900к сервачек, конечно на нем все летает, но там и юзеров 10 штук всего, если туда 50 человек воткнуть, да они все каждый по хрому запустят + 1с, то я хз даже что будет в итоге.

если "1-база на 1-рпхост", то оно на каждую базу будет создавать минимум 1рп хост, а максимум больше 1? или это на 1 базу будет всегда только 1 рпхост выделенный?

(19) есть еще интересный вариант взять например E5-1650 + двухсокетную мамку x79 и разогнать это все немного до 4ггц. и будет сравнимо с i7-6700 по скорости. а по цене все те же 200 баксов. но опять же, ядер меньше + разгон повышает риск что чтото отвалится.
нашел сервак чужой не особо нагруженый с e5606, у него как раз 2,13 частота, попробую туда тестовую копию какой-нибуть из нагруженых баз поставить и запустить юзеров, чтобы сказали насколько им комфортно будет. если будет норм, то можно смело брать 2678, т.к. он немного быстрее чем e5606. если скажут что плохо, тогда надо дальше что-то думать будет видимо.

(20) // или это на 1 базу будет всегда только 1 рпхост выделенный?

Да. Но это в скл-варианте работы с базами и это сейчас доступно без версии корп-платформы, если версия платформы достаточно низкая.

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

Только при запуске файловой базы в многопользовательском режиме есть нюансы, но Вас этими нюансами не удивишь, скорей всего

(22) Только при запуске файловой базы в многопользовательском режиме есть нюансы, но Вас этими нюансами не удивишь, скорей всего
-- имеете в виду, что чем больше пользователей в файловой базе, тем больше блокировок и снижение общей производительности? или про "падения" файловых баз?

(23) ну самое болезненная ошибка понижающая производительность файловых баз - это подключение к базе через "расшаренную папку".
Только как раз доступ к папкам баз в терминал-сессиях настраивают таким образом, чтобы любой сеанс имел только локальный доступ к каталогу базы изнутри терминала, а больше никаких иных сеансов у базы не было. Тогда тормозов не будет. Но это самый частый режим использования для той же самой УТ 10, которая так работает даже быстрей, чем клиент-серверная по сети. Еще для баз на 7.7 это было очень сильно распространено. Ну судя по всему, именно так это используете.

(24) да, юзеры все в разных сетях сидят, поэтому тут без вариантов, только rdp и только локально все. да и в одной сети файловые 8ки так и не научились нормально работать через шары(

(25) Для этого есть управляемые формы + апач.

(25) это не реально. Технологически недоступно. Файловые шары находятся под виндой в протоколе SMB или SAMBA или как там его правильно нужно называть.
Его режим никоим образом не дорабатывают, а если что и меняют , то максимум всех изменений за все более 30 лет его существования - усиление безопасности.

(26) апач кстати больше любит ядра или частоту проца?)

(28) Ему пофигу, он просто транслятор, потери на нем минимальны. При файловых базах данных он запустит в своем пространстве 1с и будет туда-оттуда транслировать данные.

насчет разницы между 2011 и 2011v3 тоже не совсем понятно в свете моих задач
технически разница получается в 6 сата3 у 2011v3 против 2 у 2011
и память у 2011v3 может работать на частоте 2133мгц против 1866мгц у 2011
но зато 2011 я на мсете нашел по такой же цене как в Китае, а вот 2011v3 на месте несколько дороже, так что скорее всего лучше заказывать.
техническая разница я подозреваю минимальная, что собственно и отображается в минимальной разнице в цене.

Вы серьезно собираетесь на китайском металлоломе ака Хуанан и тпх делать сервер?! Или это очередная штука юмора?
Если по однопоточной производительности жестких требований нет, рассмотрите Ryzen 2700 (8/16), например. Они дешевые и платы под них дешевые. Из магазина. 70 попугаев файловых нарисовать должны...

(31) 2700 Ryzen у меня нет под рукой.
но вот 2600 Райзен запустил тест Гилева
http://joxi.ru/LmGlXDKTlRY7X2
27 очков файловая. Я провда хз насчет этого сервака, он какой-то странный

а вот тесты на всяком металломе старом
http://joxi.ru/J2bnMloTV4wP92

http://joxi.ru/bmoGZVeIyMXDKm

Что не так с Хуананами кстати, они думаете сгорят что ли сразу? да вроде не горят

(32) У Вас Ryzen 2600 задушен чем-то (параметры питания, роль Hyper-V и т.д. - причин много может быть). Ибо 50 попугаев показывает древний Зион Х5460 на обычной 775-й мамке с ДДР2 памятью, которому место уже на свалке.
Хуанан - это не материнская плата, это макет материнской платы, место которому в мусорном баке либо рядом с ним, если последний переполнен. От этого говна даже школотроны плюются, когда насмотревшись блогеров, собрали себе  хлам-ПК с алиэкспресс.

(0) в 100 базах 100 пользователей? По 1 в ИБ? Базы файловые или как?

(33) да, к тому райзену у меня вопросы, на сервак не мой, это дела их админа.
есть такое насчет Хуананов, но лично Вы собирали на них что-то. были какие-то проблемы и если да, то какие?
я нашел серверные мамки б\у 2х сокетные от Асус, думал их может взять.

(34) имеется в виду активных юзеров одновременных, всего их наверно 200-300, но одновременно больше 100 я не замечал

(33) потестил райзен 5 2600. да, ты прав, неплохие результаты.
правда с коллегами пообщался, которые собирали на райзенах сервера (не под 1с) - говорят замечали зависания иногда и т.д.