похоже процесс пошел, будем переходить на ЗУП с ЗИК.
посоветуйте примерно какие требования должны быть к серверу для расчета з/п на 4500 человек?
активных пользователей в базе на данный момент около 60, возможно цифра изменится при переходе.
больших доработок базового функционала не планируется, думаю оценивать можно от типовой ЗУП.
также предлагается вариант ведения всего предприятия в одной базе а не по филиалам, соответственно цифры надо будет умножить на 8-10 - чем это чревато?

от 128Гб оперативки и по возможности Raid60 с хотсвопами, пара процов помощнее, это если не ориентироваться на цены.

60 пользователей? Круто...
Я бы рассмотрел вариант с 2мя серваками.

+(0), (1)
у нас ЦОД, админы обычно запрашивают для сервера только ОЗУ, объем диска количество процессоров. что там на уровне корзин винтов я откровенно говоря не совсем в курсе.

Так пусть админ бы и спросил?

А зачем два железных-то сервера? Железный один, на нем три виртуалки - скуль, 1с и терминал

(3) Т.е. они могут и потом добавить "ОЗУ, объем диска количество процессоров"?

Для сервера-нефайлопомойки ориентироваться только на ОБЪЕМ дисков.. мдя.

(6) я так понимаю если требования будут выше некого порога, будет речь о существенной модернизации ЦОД, а это время и деньги.
озвученные 128 Г оперативы уже не радуют, на данный момент под сервер ЗИК выделен скуль с 4Г озу и 4 процессорами и 2 терминала таких же.

(7) у них там есть "быстрая" корзина и "медленная" ) соответственно по ним и делят)

Вообще, при количестве пользователей в реальном онлайн от 30-40 действительно требуется качественно другой состав железа, наши сервера по 40Гб на двух терминалах вполне справляются со своими задачами, но кроме них еще и сервера скуль и 1с отдельно со своими 64Гб какжды к примеру. А файловая подсистема зависит только от контроллера Raid большей частью. А камни, камни по умолчанию должны все это "прокачивать"

(10) спасибо. можно узнать сколько у вас человек рассчитывается и сколько по времени идет расчет и насколько это влияет на работу других пользователей?
в 7ке у нас это проблемный момент, когда начисляется и рассчитывается зарплата.

(5)
> Железный один, на нем три виртуалки - скуль, 1с и терминал

ты фееричный фантазер.

(12) Поясни?

(5) > Железный один, на нем три виртуалки - скуль, 1с и терминал

Если упадет, то все сразу, прекрасно. 60 человек будут курить.
SQL на виртуалке при такой нагрузке, молодец.

(13)
> Поясни

в (14) кратко пояснил. При желании можно развернуто, но это платная услуга.

(14) мы пробовали переносить базу на отдельный физический скуль, 14 гигов озу 8 процессоров. реальная скорость работы упала вдвое против виртуалки которая на ЦОД.

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

(16)
> реальная скорость работы упала вдвое

Вроде или упала? Тонкой настройкой серверов никто не занимался у вас. Виртуалка скорости не добавляет по сравнению с физическим сервером при равном железе.

(11) расчет на 13000 человек, точное время не скажу, обычно разбросано по подразделениям

(18) я не говорил про равное железо, ЦОД видимо хороший, при нагрузке админы говорили выделялось до 10 Ггц процессорного времени ему.

(17)
> Причем каждый час. Плюс резерв из винтов для хотсвопа и не только. Перечислить еще?

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

(19) хотя бы грубо оценить можно? у нас просто в рабочее время расчет вообще нереально запускать делается в ночь и монопольно, при этом порядка 4 часов считается.

(20)
>  я не говорил про равное железо, ЦОД видимо хороший

ну о чем тогда спор? Воспроизведите условия ЦОДа у себя и все будет красиво.

(23) мне это не нужно. да и спор я тоже не понимаю о чем. мне нужно оценить нагрузку на существующий ЦОД которую даст ЗУП.
на 4,500 человек и на 40 тысяч грубо говоря.
при 50 и соответственно 500 пользователях.
но судя по комментариям я понял что всех в одну базу сливать не стоит, лучше построить распределенку.

(21) да я как бы согласен, но в реале работаем и так, второй стоит рядом и ни разу еще не использовался.

(25) и сколько у вас пользователей в базе на ваших 13 000 сотрудников?

(24)
> я понял что всех в одну базу сливать не стоит, лучше построить распределенку.

это и к базам и к серверам относится.
Все яйца в одну корзину складывать никода полезно не было.

(22) Вообще, Мизантроп прав конечно, это даже не спор, я просто рассказывал, как обстоит в реале у нас. Фактически

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

(0) А вообще, не стоит так расстраиваться.
128 Гб. ОЗУ на первый год, наверное не пригодится.
База новая, пока не большого размера.
Через год подрастет, добавите.

Запрашивайте где-то из такого расчета:
- терминал  24 Гб.
- сервер 1С 24 Гб.
- сервер SQL 24 Гб.
И диски из быстрой корзины.

(1) А почему Raid60?

(29) спасибо за наиболее близкий пример к сути вопроса.
если найдется еще пара человек с примерами из жизни на сравнимых объемах - будет просто замечательно.

(30)
> А почему Raid60?

потому что массива круче не придумать :-)

(32) Гм. Круче, это циферка побольше?

(33) да, именно так. На мисте уже было несколько случаев, когда народ ставил себе какие-то массивы, радовался, рекомендовал, а потом массив рушился, человек не знал что с ним делать, как перестраивать и т.д.
Я уже как-то писал о том что надо проводить тренировки по работе с массивами, сознательно создавать сложные ситуации и решать их и т.д.

Как вариант - собрать HA/DRS кластер на вмвари из бюджетных серверов от Supermicro, но с хорошим стораджем от NetApp. Получается забавная и довольно шустрая зверушка (я состряпал такое из зоопарка из пяти разношерстных серверов, подогнав их по объему памяти).

Суммарно обошлось все где-то в 35 килоенотов (не считая лицензий), при этом загнал в это облако ВСЮ инфраструктуру, кроме файрвола, само собой. Получилось зело удобно, красиво и довольно шустро. При этом из нового железа докуплен был только сторадж за 15к и SAN-свитч за штуку, все остальное уже имелось в наличии в стойке.

в (10) на указанных серверах какие процессоры и что с дисковой системой? или там о виртуалках речь?

+(35) Кстати, еще и стабильность. Даже без отзеркаливания, в "чистом" режиме HA, падение даже трех железок одновременно ведет к простою ровно на время загрузки ОС. С отзеркаливанием - вообще миллисекунды.

(37) Хорошая штука. Если разнести хосты в разные помещения, будет еще и пожароустойчивый кластер.

(38) Ага, это вообще без проблем. Главное, чтобы задержки не превышали пару миллисекунд и пропускной способности интерконнекта между стойками хватало для поддержки Fault Tolerance (то, что я "отзеркаливанием" обозвал). А без FT вообще проблем никаких и требования к каналу относительно невысокие.

(37) Вариант и правда интересный. Надо нашим админам подкинуть идейку. а по (36) Терминалки - виртуалки, скуль и 1с тоже виртуальные, но на другом железе насколько знаю.

(40) Имейте в виду, лицензии на vSphere с поддержкой HA и DRS довольно-таки недешевы. Но оно реально того стоит.

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

Кстати, насчет скуля на виртуалке. Единственный приемлемый вариант избежать притормаживания дисковой подсистемы - опять же использовать внешний сторадж через iSCSI. Все прекрасно летает, особенно если не пожадничать и поставить 10Гб карту на хост.

+(43) Соврал, не единственный. Можно еще поплясать с бубном вокруг гипервизора, запихав в него оптимизированные драйвера контроллера. Но это на отдельных моделях, и о надежности таких дров информации нет.

(44) Ну вот наши и думают сейчас насчет гипервизора, как раз приходят пара серверов, будем посмотреть, как говорится

(0) 4500 сотрудников в одной организации или нескольких?

(0) [для расчета з/п на 4500 человек]
не является нагрузкой
будет работать на любом "среднем" железе

(47) быстро сказка сказывается,да не скоро дело делается
Привет.

(46) в нашем филиале.
(47) точно? в 7ке с этим объемом проблемы у нас. то есть позволит запустить расчет не в монопольном режиме и ожидать его выполнения примерно в течение скольки часов?

(49)дык уточни по железу в головной организации

(50) что именно уточнить не совсем понял?
ЗУП пока не внедрен нигде у нас, все на ЗИК живут, переходить будут соответственно все, уточнять пока не у кого.

(51) Ты сам в филиале работаешь или в головной организации?

(52) филиал.
к (43) узнал у админов что у нас стоит DS4300 подключение по FC а не по iSCSI, я так понимаю это быстрее.
или речь о том чтобы выделить отдельный массив именно для виртуалки? тогда поясните поподробнее как это сделать.

(53) iSCSI - это всего лишь протокол. Среда может быть какой угодно - хоть Ethernet, хоть FC. В частности, 10 Гбит Ethernet ничуть не медленнее FC.

(48) здоров
(49) зарплата в 8-ке считается по подразделениям, в не монопольном режиме и занимает расчет на 1000 голов минут 10

(54) это стандартным функионалом, без "доработок напильником"?
цифра просто сильно отличается от 3 дней расчета на 13 000 человек указанных в (29), хотя там и не машиночасы конечно.

(53) Нет, отдельный массив не нужен, если стоит высокопроизводительный сторадж, способный обслуживать всю эту кухню без задержек ввода-вывода дисковой подсистемы. У меня была дисковая полка с SASами 15к на всю эту кухню, никаких задержек не замечалось, скорость работы скуля практически ничем не отличалась от таковой на обычном RAID10 из SASов на "чистом" железе, без виртуализации.

(56) Да, без всяких доработок напильником, по iSCSI средствами ОС (винда, ага) цепляется LUN на сторадже... и все :)

(56) [цифра просто сильно отличается от 3 дней расчета на 13 000 человек указанных в (29),]
ни о чем

по варианту ведения всех в одной базе что то можете сказать?
грубо говоря это 40 000 человек и порядка 400-500 пользователей.

(56) Чота три дня - дюже много, имхо.

Помнится, я одной бухше показал волшебную кнопочку - запуск обработки "Расчет регламентированной зарплаты". Она так радовалась, так радовалась... и все равно "рассчитывала" з/п те же два дня, хотя сам расчет занимал меньше пяти минут :)

(60) 400-500 пользователей ЗУП? Что-то очень огого.

(62) 10 филиалов, я грубо умножаю тех кто в ЗИК работает сейчас. там и отиз и расчетчики и экономисты плановики.

(63) Если филиалы - имеет смысл разнести базы и слинковать по РИБ, имхо. Чтобы экономисты-плановики, работающие в основном на чтение данных, работали с ЦБ отдельно.

в данный момент подключений в ЗИК 70. то есть я еще и занижаю несколько результат простого умножения.

(65) Реально работают не более половины. Меняют данные и того меньше.

(0) зик удачно считал 3000 сотрудников
в файловом варианте в момент, на sql тормозил

(66) я не спорю, так и есть наверняка, я бы даже оценил примерно в 30% реально интенсивно работающих и формирующих отчеты.

(65) Если брать простой бюджетный вариант, то достаточно 2 серверов начального уровня. И 3 дня - это конечно же не машиночасы, а общая сумма времени по расчету ЗП. Для использования в филиале - РИБ и канал связи с головным офисом.   На первых порах все будет просто "летать". Затем, через годик примерно уже поймешь, где узкие места, что нужно улучшить и стоит ли менять инфраструктуру.

Стесняюсь спросить, а что делают 60 человек с зарплатой 4500 в вашей базе? Получается 75 сотрудников на одного расчетчика? Я максимум что встречал для таких объемов это 20 черовек, но это и менеджеры по персоналу и кадровики и расчетчики.

(70) руками пересчитывают за 1с-кой

(70) я уже писал что это не только расчетчики но и отиз и плановики экономисты и все подряд.
непосредственно расчетчиц 10.

Кстати, в отличие от ЗиК 77, ЗУПу терминал не особо нужен.

http://3nity.ru/viewforum.php?f=40&start=0

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

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

+ все работают в терминальном режиме

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

(78) Record Level Security. Разграничение доступа на уровне записей. Прожорливая штука, факт.

судя по ссылкам в гугле это разграничение доступа на уровне записей справочников? тогда наверняка захотят это, раз платформа позволяет.

(80) Не только справочников.

(80) если они это самое RLS продавят, то потом вони будет, что ЗУП еще тормознутей чем ЗиК. И существенно поправить эти тормоза каким-то железом вряд ли удастся - они все равно останутся. Хорошая альтернатива этому самому RLS - разделить базу на РИБ по подразделениям. Тем более, что наличие 10 расчетчиков все-равно потребует создания каждому из них, условно говоря, отдельных рабочих наборов данных. Вот и пусть каждый расчетчик сидит в своем рабочем наборе монопольно. А плановики и остальные юзеры сидят в центральной без деления на подразделения.

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

(83) Ну про РИБ в филиалах - это самый логичный вариант (если филиалы не из полутора сотрудников состоят, конечно).

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

кстати, я сильно промахнулся с общим числом сотрудников, и видимо пользоватаелей. итого сотрудников порядка 20 000, у нас просто большой филиал.

(85) Я филиалы обычно считаю в качестве подразеделений, только с признаком "обособленное". План обмена для обосболенных подразделений в ЗУП КОРП есть точно. Насчет обычной ЗУП - не уверен, не помню.

60 пользователей в ЗУПе ? Что они там делают у вас?

(88) Настоящий бюрократ сумеет обеспечить работой себя и своего товарища (с) народное

(88) https://ru.wikipedia.org/wiki/Закон_Паркинсона
>> Закон тысячи [править]
Учреждение, в котором работают более тысячи сотрудников, становится «административно самодостаточным». Этот специальный термин означает, что оно создает так много внутренней работы, что больше не нуждается в контактах с внешним миром.

(88) Ну а что, расчетчики плюс кадровики плюс еще табельщицы какие-нибудь

"60 пользователей в ЗУПе ? Что они там делают у вас?"

у нас заведено вообще 150. разные функции у всех.

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

+93 таковы принципы расчета зарплаты и налогообложения, иначе нельзя.

(93) разве не будет целой считаться база филиала, к которой с помощью РИБ будут привязаны несколько баз для ввода первичных документов? документов других филиалов у нас не видно на данный момент в ЗИК, да и не нужны они нам.

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

(96) не со всеми, не надо преувеличивать. какое-то странное у тебя виденье расчета налога в ЗУП.

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

да, и дробление, скажем так, масштабирование путем создания новых и новых планов обмена и узлов РИБ можно делать постепенно, накапливая статистику от степени блокировок центральной базы при запуске монопольно-ориентированных процедур и обработок/отчетов