Здравствуйте
Задача: внедрение 1С 8.3.10.2667 первоначально на 400 пользователей (с дальнейшим расширением до 1000+ "не в скором времени").

Базы
2 по 500Gb (max) (SQL)

Аппаратная часть (Для старта 400-600 пользователей), дальнейшее расширение - добавление новых серверов в кластер

Под 1С сервер
HP Proliant DL360p Gen8, 2 процессора Intel Xeon E5-2670v2, 96GB DRAM, P420i/1GB FBWC / HDD: 2*SAS RAID1 (Система) - 2*SSD RAID1 (Temp, cache сервера)
HP Proliant DL360p Gen8, 2 процессора Intel Xeon E5-2670v2, 96GB DRAM, P420i/1GB FBWC / HDD: 2*SAS RAID1 (Система) - 2*SSD RAID1 (Temp, cache сервера)

Под терминалы
HP Proliant DL380 G7, 2 процессора Intel Xeon X5670 2.93GHz, 48GB DRAM, 1GB FBWC / HDD 2*SAS RAID1 (Система) - 2*SSD RAID1 (Temp, cache пользователей)
HP Proliant DL380 G7, 2 процессора Intel Xeon X5670 2.93GHz, 48GB DRAM, 1GB FBWC / HDD 2*SAS RAID1 (Система) - 2*SSD RAID1 (Temp, cache пользователей)
HP Proliant DL380 G7, 2 процессора Intel Xeon X5670 2.93GHz, 48GB DRAM, 1GB FBWC / HDD 2*SAS RAID1 (Система) - 2*SSD RAID1 (Temp, cache пользователей)

База №1 (Там же обработки) (РАБОЧАЯ)
HP Proliant DL380 G8, 2 процессора Intel E5-2620, 64GB DRAM / HDD 2*SAS RAID1 (Система) - 4*SAS RAID10 - 2*SSD 500Gb RAID1 (База) - SSD 32Gb (Temp)

База №2 (Там же обработки) (самостоятельная база, используется рабочей в основном для чтения)
HP Proliant DL180 G6, 2 процессора Intel X5670, 64GB DRAM / HDD 2*SAS RAID1 (Система) - 4*SAS RAID10 - 2*SSD 500Gb RAID1 (База) - SSD 32Gb (Temp)

Сеть
Соединение 2Gb агрегацией портов

Очень надеюсь что ни чего не забыл.

Будет ли достаточно данной конфигурации под старт 400-600 пользователей, а может и перебор, например в SSD на каждый сервер, может будет достаточно SAS RAID10? Готов выслушать конструктивную критику и любые предложения.
Есть ли какие-то подводные камни у данной платформы?

Описанное выше это всё для внедрения на базе терминалов, такой вариант использовать не самый лучший выбор??


Как понимаю целесообразней использовать тонкий клиент и публикацию в IIS

Сам к 1С имею косвенное отношение и в тонкости работы увы не посвящен.

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

Ниочем.

Что за конфа, что за работа?
Если на УФ то терминалы противопоказаны. Если самописка на обычных формах то лучше платформа 8.2

http://catalog.mista.ru/public/378766/
http://catalog.mista.ru/public/835719/

Платформа самописка.
Управленческий учет.

обязательно почитаю статьи.

Да всё на УФ, можно подробней почему терминалы противопоказаны.

Извиняюсь, но сам к 1С имею косвенное отношение, но запуститься на 8.2 отдел разработчиков не сможет.

Сейчас вопрос решается от необходимости терминальных серверов или всё таки тонкие клиенты

(4)Ходят упорные слухи что в терминале очень сильно тормозит отрисовка управляемых форм.

А по сабжу, без специалистов не взлетит. Нужны специалисты, в том числе которые смогут мониторить узкие места. Миста тут нечем не поможет. Нужно привлекать 1С, нужно привлекать поддержкой ЦКТП от 1С.

описание железа ниочем, ибо если почитаешь по ссылки у них изначально было 1000 пользователей, серваки в сотки и все висело. После оптимизации сейчас 3000 человек. И чем тут поможет выбор железа?

Вон по ссылки они год проводили нагрузочное тестирование при смене платформы с 8.2 на 8.3, чтобы определить потребность железа. А вы хотите что бы вам по фотографии диагноз поставили?

(0) Про сервер баз данных непонятно.
1. Памяти маловато.
2. У HP сейчас есть большие SSD, ИМХО лучше заменить "4*SAS RAID10 - 2*SSD 500Gb RAID1 (База) - SSD 32Gb (Temp)" на зеркало из больших SSD.

Обратитесь к специалистам http://www.gilev.ru/podbor/

(0) Про сервера SQL:
Памяти хотя бы в полразмера базы, т.е. 256гб.
Для базы в 500Гб нужен SSD на 1000Гб.
Под тембдб выделить отдельный SSD гигов на 240 минимум.
Систему - тоже на SSD.
Про SAS RAID10 - забыть! Всё, эпоха закончилась. Только для бэкапов.

Спасибо за советы, на SSD будет заменено.
Но всё же посоветуйте, как лучше доставлять до клиента, RDP или всё же тонкий клиент, группа разработчиков сразу отказалась от Web на IIS (аргументируют только то что глючить будет).

(10) ну так правильно агрументируют, что IIS на практике глючней, чем Apach

Расчет параметров серверного оборудования
https://its.1c.ru/db/metod8dev#content:5810:hdoc

(10) по поводу лучше будет RDP или нет - нужно тестить конкретные условия, т.к. 400 человек не на 40 кв метрах сидят, а на значительно большем количестве этаже, комнат, зданий, преходов и т.п. - это не на сервер смотреть нужно, а на способность всей ЛВС в целом

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

Нужно прежде всего четко понимать, что критично у сервера 1С:
- количество ядер + количество потоков = один Процесс прекрасно подхватывает свободное ядро либо свободный поток, но когда свободных ядер нет, то куча юзеров будут просто выталкивать друг друга и понижать выданное на каждого процессорное время.
- количество оперативы = каждый сеанс гарантированно должен получать достаточный объем памяти без ее свопа, когда операционка начнет бешеное число раз переключать потоки в количестве 400 штук, например.

(0) для УФ нужен мощный и быстрый кластер 1С
зачем для УФ TS ?

Я бы на место сервера 1с взял бы i9-7980xe.
Ибо на сервере 1с не должно быть больше 1процессора.

Кстати да, 1С сервер не поддерживает NUMA, поэтому вроде как бессмысленно пихать несколько процессоров. Если нужно распараллелить нагрузку, лучше несколько серверов и разносить сервисы с помощью ТНФ. Фоновые задания точно лучше вынести на отдельный сервер.

Но чтобы точно ответить, нужно делать нагрузочное тестирование

(0) Подумайте про вариант SQL + Сервер 1С на одном физическом. Чем меньше железок, тем меньше головной боли админам. И связь 1С с SQL быстрее будет отрабатывать через shared memory.
За числом ядер не гонитесь, главное - частота.

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

(20) Наоборот: уйдут задержи сети, а впихнуть побольше памяти - несложно. Другое дело, что можно пойти по пути (16) - купить для сервера 1с более "настольный" процессор, но с более высокой частотой.

(17) думаю, что неверно ты интерпретировал вот это разъяснение

---
На многопроцессорных системах на одном сервере должно работать больше одного процесса rphost
Следует иметь в виду, что поддержка NUMA в кластере серверов "1С:Предприятия" полноценно пока не реализована.

Сервер 1С не управляет распределением ресурсов по NUMA узлам, полностью полагаясь в этом на операционную систему, что не всегда даёт оптимальный результат.

Поэтому при работе на многопроцессорных системах (все современные многопроцессорные системы Intel и AMD имеют NUMA архитектуру), в зависимости от характера нагрузки, может наблюдаться неравномерная загрузка процессоров/ядер. В некоторых случаях может оказаться загружена только какая-то часть доступных ядер CPU, при этом другая часть будет простаивать. В таких случаях рекомендуется использовать лимит числа соединений на рабочий процесс, установленный из расчета:

ЧислоСоединенийНаПроцесс = РасчетноеМаксимальноеКоличествоСоединений/КоличествоNUMAНод.

При этом все равно возможна ситуация при которой будет перегружена только какая-то часть CPU (это можно можно увидеть в диспетчере задач 100% длительная 100% нагрузка на некоторые CPU при том, что остальные свободны). В таком случае лимит соединений на процесс следует уменьшать из расчета:

ЧислоСоединенийНаПроцесс = РасчетноеМаксимальноеКоличествоСоединений/(КоличествоNUMAНод * Коэффициент),

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

(21) Но только не для 400 пользаков

(22) в чем я неверно интерпретировал?

(21) какие задержки сети, если в норм системе их нет?

(23) Почему? Чем больше пользователей - тем больше запросов, и больше влияние сетевых задержек. Все тесты, что нашел, показывают бОльшую скорость при использовании shared memory, что логично.

Такие медленные ядра - это ж надругательство над пользователями натуральное.
Можно кстати чем-то объяснить, что на терминальный сервер предполагается ставить самый быстрый процессор, а на сервер БД самый медленный? (Ну кроме некомпетентности подборщика)
А на фига вам RAID1 под терминальными профилями? Там что-то ценное предполагается хранить помимо 1Сного кеша?
RAID то хотя бы софтверный? Или на самом деле будете RAID-контроллеры ставить в 2018 году?

(27) чем в 2018 году софтверный РЭЙД лучше железки в сервере?

(28) -1 точка отказа

(16) Плюсую за данный вариант. Сам собрал "сервер" на базе i7 8700k + SSD, еще и разогнал его. Он там так полетел, что от скорости офигели все, в том числе и я.

+(30) До этого был крутой сервер на базе Xeon, модель не помню, 32 ядра, 2 процессора. Еле шевелилось все. 50 пользователей УТ 11.

(27) На одном заводе купили серверы с недостаточной скоростью ядер, примерно как в (0) и запустили ERP. Теперь несмотря на вбуханные большие деньги - пользователи воют на скорость работы.

Я вообще во франче работаю - повсеместно у клиентов стоят процы на серверах наподобие Xeon 2.1 Ghz и все там плачут от такого быстродействия. Зато админы рапортуют "посмотрите, 32 ядра и все не загружены, это ваше 1С тормозное УГ".

(24) Смотрим на формулу

ЧислоСоединенийНаПроцесс = РасчетноеМаксимальноеКоличествоСоединений/КоличествоNUMAНод.

Из топика, что Максимальное количество соединений желают видеть 400+

Характеристика процессора
Количество ядер 10
Количество потоков 20
Базовая тактовая частота процессора 2,50 GHz
Максимальная тактовая частота с технологией Turbo Boost 3,30 GHz

На двух процессоров получим 40 потоков, которые примитивно можем полагать равными КоличествоNUMAНод

Ставим ЧислоСоединенийНаПроцесс  = 400/40 = 10

Хотя частота не самая шустрая, не нужно представлять себе, что при количестве 400 соединений один или два rphost обеспечат адекватную производительность всем этим соединениям на высокой частоте. Это все-таки не 10 юзеров и даже не 40

(33) не уметь в многоядерные и мнопроцессорные системы это таки грех 1с-ки. но зная этот грех все равно покупать 100500 ядерный 478 процессорный мегасерверище с 2.1 ггц это не грех 1с-ки.

(16) >>Ибо на сервере 1с не должно быть больше 1процессора.

Это с какого перепугу?

(35) Понятное дело, что это особенность 1С, но админ ведь должен перед таким ответственным приобретением собрать информацию, что надо приобретать применительно к продукту, который этот сервер будет обслуживать. А никто не парится, у всех позиция "я лучше других знаю, какое железо надо". В итоге имеем массовые проблемы быстродействия по причине железа. Хотя и сам код 1С не идеален, спору нет. Но всего лишь подобрав железо, можно в несколько раз ускорить быстродействие. В моем случае по тесту Гилева получилось вообще в 5.5 раз. Было 10, стало 55-58.

(37) Да, админов с низкой квалификацией не меньше, чем 1С-ников.

(0) по своему опыту скажу - для 400-600 юзеров при базе до 100гб  конфигурация почти норм :)

Заранее продумай как будет работать печать - это тот еще геморрой, особенно если юзера базы находятся в 100500 городах с пингами от 2 до 200

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

На sql-сервер памяти побольше ставь, мы сейчас к 256 подошли :( За 4 года с 64гб уехали постепенно.
И sql-бы сразу в отказоустойчивый кластер загнать - нас спасало пару раз.

(39) О, значит у нас грамотный админ был... Именно так все с самого начала и сделал. Уже 3 года полет нормальный, и еще года на 3 хватит...

(36) может про кластер еще не знают?

(0) Ставь в 1с-сервант самый злой по частоте проц.

И я бы не делал 2 сервера 1с под 2 базы, лучше 1 но лютый.

2 SQL-серванта плюсую.

Ну и SSD куда только можно, SSD нынче рулят.

(41) Ну в случае (0) я согласен, в принципе (базы то две). Один проц, но самый-самый.


У меня 2х12 ядер хорошо работают, но баз 150.

(40) дык, не теряйте с ним контакта :)

Кстати говоря, SSD обязательно нужен PCI-E (NVMe). У них скорость отклика сильно меньше, чем у SATA.

(45) Жду не дождусь, когда одобрят сервер на Intel Optane SSD))) Вот там будет жесть, в хорошем смысле)))

(46) А чего медлят? Это самое быстрое, что есть. Правда, если в проц упрется, то не сильно ощутите.

(0)  Кстати, я бы на вашем месте запихнул в sql парочку Intel Optane SSD)))

(46) В проц упретесь. Проверено.

(47) Жду когда нагребут еще штук 50 баз и начнут жаловаться что "1с что-то как-то не как раньше")))

Дорого, а админ пока себе серванты обновляет, не моя очередь тратить деньги))

(49) SQL не будет успевать строить планы запросов?)))

(51) Даже на обычном SSD уже в проц всё упирается.

(49) (52) Пока на подходе упирание в чтение/запись когда закрывают месяц штуках в 40 БП одновременно)

Или проценты считают по 500 договорам за пол года.

(53) Сколько IOPS диски выдают и какая очередь?

(52) Учту при выборе процессора, спасибо)

(53) а если разгрести эти задачи на фоновые и разрешить им стартовать не больше 10-20 одновременно?

(54) Иопсы не считал. Очередь 0.5 - 0.9 под большой нагрузкой. А так 0.05.

(0) выкинуть терминалы, работать через тонких клиентов

+(39) к (0) забыл упомянуть - если кластеризацией займетесь, то очень желательно прикупить хороший СХД, соединенный с контроллерами на sql-серверах - при выходе из строя сервера - сохранность данных выше, для кластеров удобнее, да и масштабировать можно прямо на-лету.
У меня - шуршат sas'ы на 25тб, схд - IBM System Storage DS3524

(56) Ну когда 8 бухов запускают в конце месяца расчет (который им нужен вот прям сейчас) это не сильно поможет.

А мне им объяснять, вот подождите, пусть оно считается, ваша очередь следующая?)))

У нас философия такая, что пользователи должны работать в максимально комфортных условиях)

Для них, любимых, никаких денег не жалко)))

(53) Эти 40 БП - на sql? У нас одна база, просто молотят накладные в ней по 15 тыс в день. SSD в raid-10, никакой очереди нет.

(59) Да, именно так и сделано, только железо не IBM а HP :))
Только вот все это не очень бюджетно, мягко говоря...

Ставьте Эльбрусы

(62) но оно того стоит :)

(61) Эти 60 БП и, 60 ЗП, и еще до кучи разного)

И у меня не SSD, у меня SAS 15-тысячники в R10.

И 15 тыс. накладных в одной базе это не закрытие месяца в 40)))

(64) Для программистов да, думать об ограничении по железу не надо, и все усилия по оптимизации направить на код. Для пользователей да, нет тормозов из-за проблем с железом. А вот для бизнеса в целом - не факт, что это наилучшее вложение денег...

Идите в softpoint.ru и платите дорого за решение проблемы.

Или ходите по форумам, создавайте проблемы и решайте их за большие деньги.

(65) вы о фреше еще не думали?

(0) sas убрать, только SSD, Raid 10, вместо 1.
Все зависит от программистов, если управленка, думаю программисты норм - взлетит вполне. База 500 гб, это средняя база, и имеет значение не общий размер, а отдельные таблицы и что в них.

делать не терминал, а через веб.
По дисковому пространству смотри, без учета бекапов, нужно где-то 5-8 тб минимум

Все упирается в программистов и базистов.

Сервер SQL 1
Замена:
CPU
E5-2620 2.1 GHz/6-core -> E5-2690 v2 3.0 GHz/10-core
RAM
64GB -> 256 GB
HDD
HDD 2*SSD RAID1 (Система) - 2*SAS RAID1 (Система) - 4*SSD 1000Gb RAID10 (База) - SSD 240Gb (Temp)

Итог
HP Proliant DL380 G8, 2 процессора Intel E5-2690 v2 3 GHz/10-core, 256GB DRAM / HDD 2*SAS RAID1 (Система) - 4*SSD 1000Gb RAID10 (База) - SSD 240Gb (Temp)

Сервер SQL 2
Замена:
Полная замена сервера на аналогичный "Сервер SQL 1"
HP Proliant DL380 G8, 2 процессора Intel E5-2690 v2 3 GHz/10-core, 256GB DRAM / HDD 2*SAS RAID1 (Система) - 4*SSD 1000Gb RAID10 (База) - SSD 240Gb (Temp)

Под 1С сервер
Не всё так однозначно

Вариантов пока несколько

1. Использовать имеющиеся в данный момент (с поднятием частотами до 3,1)
HP Proliant DL380 G7, 2 процессора Intel Xeon X5670 2.93GHz -> 3,1GHz, 48GB DRAM, 1GB FBWC / HDD 2*SAS RAID1 (Система) - 2*SSD RAID1 (Temp, cache сервера)
HP Proliant DL380 G7, 2 процессора Intel Xeon X5670 2.93GHz -> 3,1GHz, 48GB DRAM, 1GB FBWC / HDD 2*SAS RAID1 (Система) - 2*SSD RAID1 (Temp, cache сервера)
HP Proliant DL380 G7, 2 процессора Intel Xeon X5670 2.93GHz -> 3,1GHz, 48GB DRAM, 1GB FBWC / HDD 2*SAS RAID1 (Система) - 2*SSD RAID1 (Temp, cache сервера)

2. Поставить аналогичные серверам SQL
HP Proliant DL380 G8, 2 процессора Intel E5-2690 v2 3 GHz -> 3.3 GHz /10-core, 96GB DRAM / HDD 2*SAS RAID1 (Система) - 2*SSD RAID1 (Temp, cache сервера)
HP Proliant DL380 G8, 2 процессора Intel E5-2690 v2 3 GHz -> 3.3 GHz /10-core, 96GB DRAM / HDD 2*SAS RAID1 (Система) - 2*SSD RAID1 (Temp, cache сервера)
Тут еще стоит тогда вопрос в выборе процессора, в связи с советами по увеличению GHz
Варианты:
Intel E5-2690 v2 3 GHz -> 3.3 GHz / 10-core
Intel E5-2667 v2 3,3 GHz -> 3.6 GHz / 8-core
Что из этого будет лучше

3. Переход совсем на другие платформы HP Gen9 или HP Gen10 или аналогичные
Вариант не особо принимается руководством (

----------------------------------------
Работа клиента в программе
По всем советам, терминальный доступ пока не рассматриваем.
В итоге разработчике упорно не хотят использовать Web ни на IIS ни на Apache, аргументируя только тем что глючит подвисает да и вообще работает ни так как надо. В данный момент на Web 1С не работает дальше стартовой формы.

Извиняюсь за мою некомпетентность в данном и за потраченное на решения вопроса время

С уважением

"Переход совсем на другие платформы HP Gen9 или HP Gen10 или аналогичные
Вариант не особо принимается руководством ("
Почему кстати? С таким количеством железа нужно разговаривать с вендером, пусть предлагают лучшие варианты.

В целях экономии, HP Proliant DL380 G7 есть в наличии 3 штук уже, HP Proliant DL380 G8 пару тоже найдётся только надо апгрейдить.

(72) Имхо, в реальности у вас все в принципе хорошо по железу. Придирки, которые тут в ветке озвучили на практике трудно исполнимы в таких масштабах.

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

Обратите внимание на возможности виртуализации (выше об этом в постах упоминали), т.к. это может дать существенные плюсы, но при тупой настройки даст и минусы.

Сама по себе сбалансированная система может пойти в разнос довольно быстро - например, сейчас сбалансировали на 400 активных соединений, а поднимите до 555 (условно) и все просядет конкретно, причем, очевидными рецептами восстановить сбалансированность будет не так-то просто.

Ну и самое главное - даже если железо дает хорошие возможности, нужно суметь ими воспользоваться в настройках и программной реализации всех идей. Собственно, пример реакции специалистов на web-подключения к базам должен прекрасно это иллюстрировать.

(72) И в заключение - для корректной и стабильной работы тучи уникальных, хоть и унифицированных по железу, пользаков вам все равно придется вернуться или остановиться или просто сделать его как один из основных - вариант с использованием терминальной фермы... хотят ли об этом холиварить или нет - никуда вы от этого не денетесь.

плюсану за нормальную СХД.
из моего опыта именно дисковая система дает максимум проблем, причем мириться с ними не получается, поскольку производительность падает на порядок и более, в отличие от процессора когда может снизиться в 2-3 раза (с этим можно жить).

(4) "Платформа самописка"

Так вот кто, оказывается "платформу" пишет! ;)

(75) При наличии вполне приличного железа обосновать приобретение очень дорогого нового будет проблематично...

(4) грамотная самописка на 500 пользователей обязана быстро работать на обычном десктопном компе.

(68) Зачем? Производительность пока устраивает, потом докинем оптэйнов и забудем еще лет на 3-5)

Ну и это, у нас же не ларек с шаурмой, кто в трезвом уме будет выкидывать серьезные вещи неизвестно куда?)

Не аутсортинг, если что.

(77) если СХД есть то ее параметры не озвучены.
если ее нет, то возражение о "наличии" снимается.
судя по тому что "базу" предполагается положить на 2 ССД рейд1 больше похоже что СХД отсутствует.

(70) если тонкого клиента, и вэб не хотят, то может всё же терминалки рассмотрите, в варианте "Remote Application"? Но, как я выше писал, продумайте как будете печатать, единственная проблема с которой по своему (и не только) опыту часто сталкиваемся на remoteapp по rdp - это печать :( Т.е часто (минимум раз в неделю) у части юзеров (особенно с высокими пингами из дальних регионов) начинаются паузы по 5-10-15 минут от момента нажатия кнопки печати, до выхода на печать.