Добрый день форуму. Я системный администратор с нулевым опытом работы с SQL базами 1С, работал только с файловыми. Пригласили админом на новую работу. Поставили задачу разгрузить ресурсы имеющегося сервера с формулировкой "тупит, иногда виснет, приходиться периодически перезагружать". Сервер достался в наследство от материнской компании. Заглянул я на сервер и ахнул. Файлопомойка, 35 в одном. Сервер 1С, SQL, сервер терминалов и много прочего ПО в одном флаконе. 80-100 пользователей, Активная база 105 Гб, плюс 3-4 редких баз по 4-10 Гб. Аккурат перед моим приходом закупили новый сервер за лям рублей.

Конфигурация текущего сервера:
Supermicro X9DR3-F
2x Xeon E5-2620 v2 2383 MHz
128 Гб DDR3

ОС, 1С и SQL стоят на каком-то древнем SAS, точно определить не смог. Базы лежат на 2x Samsung SSD 860 EVO 500GB в программном RAID. До недавнего времени и базы лежали на том же SAS.

Конфигурация нового сервера:
SuperServer 6029P-WTRT
2x Intel Xeon Gold 6144, 24.75M Cache, 3.50 GHz
96 Гб DDR4
4x SSD HGST Ultrastar SS300 HUSMM3280ASS204 800Гб, 2.5", SAS в RAID10 на Adaptec SAS RAID 8805E

Переносить полностью 1С на новый сервер начальник не хочет, могут возникнуть проблемы с лицензией или её активацией, не уточняет. Предлагает перенести на новый сервер только SQL. Я, со своим опытом советов давать не могу, поэтому прошу совета на форумах, а именно:

1. Имеет ли значение расположение ОС на отдельном M.2 или на том же RAID массиве? Продавец предлагает выделить раздел на RAID массиве.
2. Имеет ли смысл переносить только SQL? Будет ли прирост в производительности?
3. Читал что базы, журналы, temp базы и temp журналы желательно разносить по разным физическим дискам. В нашем случае массив только один. Приемлемо ли это?
4. Лично у меня чешутся руки запилить на отдельных виртуальных машинах 1С+SQL и RDP и не торопясь перенести базы с тестированием. Под RDP докупить SSD. Имеет ли такой вариант право на существование? Какое распределение ресурсов сервера в процентном выражении между виртуалками должно быть?

Тапками не кидайте, свою компетенцию я указал. Если исходных данных недостаточно, могу дополнить. Буду благодарен за любые ответы, советы и прочую полезную информацию.

Вы все сделали не так.

Но в вашем случае - перенести SQL, сервер 1С на новый сервер.
Никаких виртуалок.
Терминалку оставить на старом сервере.

SQL настроить по рекомендациям 1С

3. Читал что базы, журналы, temp базы и temp журналы желательно разносить по разным физическим дискам. В нашем случае массив только один. Приемлемо ли это?

Для SSD - покуй, ну tempdb разобьешь на несколько файлов, это есть в рекомендации 1С.

Самое главное mdop=1. Это 90% успеха.

4. Лично у меня чешутся руки запилить на отдельных виртуальных машинах 1С+SQL и RDP

Отпили их, чтобы не чесались.

2. Имеет ли смысл переносить только SQL? Будет ли прирост в производительности?
Нет. У вас производительность упирается в сервер 1С, в ядро проца. Это если у вас нет косяков в данных типа динамического обновления, итогов с начала тысячелетия, depotfiles, каких нибудь планов запросов с crossjoin.
Вы и сервер новый херово купили.

За желание крутить скл и сервер 1с на виртуалках нужно гнать админа с работы с волчьим билетом. С записью в трудовую.
Чтобы его потом никто не подпускал к серверам ближе километра...

Имеет смысл перенести только SQL-сервер. Это очень правильно!

(7) Чем же правильно? Процессор-то на новом пошустрее, и на нем службе 1С будет комфортнее.

(3) а можно чуть поподробней про mdop=1. Почему нельзя включать параллелизм? Вроде как с ним запросы быстрее выполняются

(9) если кривых запросов нет то с параллелизмом работает быстрее. Чем и пользуюсь.

А так они (1с) рекомендуют его отключать по причине:

"основная причина - исключить сценарий, при которой один длительный запрос с неэффективным планом выполнения создаст за счет параллелизма нагрузку на CPU, не позволяющую другим транзакциям выполняться с обычной для системы скоростью."
https://its.1c.ru/db/metod8dev#content:5945:hdoc

(9) 2 консультанта запустили перерасчеты в ЗУП, в итоге 800 человек больше не могли работать.

(8) на новом ядер больше

2x Xeon E5-2620 v2 - 12 ядер
2x Xeon Gold 6144 - 16 ядер

(12) Вопрос, почему " только SQL-сервер", а не вместе с сервером 1С.

(13) Лучше вместе, но можно и по отдельности. Чем больше удастся забрать с сервера терминалов, тем лучше.

(3) это только в случае если SQL тормозит на паралельности

А что так все против виртуалок для 1С сервера и скуля? Есть проблемы?

(6) Смотря как к вопросу подойти. Можно и вполне качественно сделать
(12) Если утилизация проца 80+%, если замеры показывают что SQL ждет на проце. Тогда да

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

(16) мы месяца 3 бодались. в итоге -7% производительности в сравнении с физическим сервером.

А зачем параллелизм в OLTP ? Ну, иногда он нужен, например при переносе данных и реструктуризации, но в рабочей базе - нет. Как правило, возникают кривые планы запросов и ожидания на синхронизации.

(16) Только так и надо делать

(16) Да, есть проблемы.
На виртуалках возникают проблемы с сеансовыми данными.
Я подозреваю, что из за динамического распределения памяти, когда память виртуалки подходит к концу "динамически" выделенного куска, сервер 1С начинает скидывать сеансовые данные из памяти на диск.
Но доказать не могу.

(20) Для отчетов на плохо спроектированых метаданных :)

(22) В гипервизоре можно поставить буфер побольше, например, 50% вместо 20%.

(22) Если известно, в какие файлы скидываются сеансовые данные, можно промониторить.

(24) Я предпочитаю жить спокойно без вот этого всего и сокращаю количество проблемных мест.

(26) А фиксированное выделение памяти не решает проблему?

(27) Я не готов ответить на этот вопрос. Я просто пишу то, с чем сталкивался.
Те сервера, которые рекомендовал я - физические, мы за них отвечаем и администрируем.
Те сервера, которые развернуты вопреки рекомендациям - в зоне ответственности админов заказчиков и по ним я могу сказать только о наблюдаемых проблемах. Как они там админятся - я не в курсе.

(23) Отчеты могут и подождать. Колесико крутится, рабочий день мутится.

(10) понятно, спасибо за информацию

(28) Рекомендации разные бывают...

(1) Я не сделал ещё ровным счётом ничего

(32) Ну значит - хотели сделать

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

(6) Минус 10-15 попугаев по тесту Гилёва. Но удобнее. Если важна скорость то сервер один и физический если простота восстановления в случае отказа то виртуальный или два виртуальных.

(2) >Никаких виртуалок.

а как-же насчёт получить много секса и никакого удовольствия?

(0)
Переносить 1С + SQL на новый сервант.
Без виртуалок.
ОСь на рэйд, базы, tempdb, журналы на SSD, разделить по вкусу.

(0)
Старый сервант перестряхнуть, пропылесосить и застеклить заново под RDP, файлопомойку и прочее.

(0)
1. У вас быстрая дисковая система. Можно на одном массиве. Делить на разделы как удобнее.
В общем случае, сама ОС не требует быстрого диска и нормально стартует с механики. Но временные файлы ОС и 1С по умолчанию на системном диске. Это можно изменить, но само оно не изменится.

2. С точки зрения скорости почти наверняка быстрее не станет. Но, как я понимаю ситуацию, переносить придётся в итоге всё. Нужно с чего-то начинать.

3. В вашем случае HUSMM3280ASS204 это серверный SAS SSD. С точки зрения производительности нет смысла разносить. Для механики имеет смысл разносить чтобы повысить производительность.

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

(39) Продолжение.
То что вы сейчас сделаете скорее всего потом придётся переделывать в любом случае. Это нормально.
На вашем месте я бы делал что скажет начальник попутно разбираясь как оно устроено. Софт, железо. Много зависит от того допустимо ли использовать в вашей компании софт по специальной лицензии от рутрекера.
Разберитесь отдельно в первую очередь как бэкап организован. И есть ли вообще :-)

Замечание по железу:
На новом сервере меньше памяти. Это действительно так? Докупать возможно, свободные слоты есть?
Серверов всего два или есть ещё?

(40) Да, ОЗУ меньше. В подборе железа не участвовал, думаю, урезали по причине "ну только под SQL же".

(22) не должно быть никакого [динамического распределения памяти]. На виртуалках под 1С и БД память прибивается гвоздями (впрочем, как и все остальное). И выделенный сетевой интерфейс, прокинутый в виртуалку.
"Вот тогда дети и не станут пропадать!"

Я вижу, что мнения разделились. Виртуальное или физическое? За много лет единственный минус Hyper-V, обсуждение которого я видел на форумах, это динамическая память. Проблема решаемая. Так всё же, чем ещё виртуальная машина "медленнее" физической?

(5) Что именно по Вашему мнению мы сделали "херово"?

(0) Та не парься, сделай, как знаешь.
А вот когда это всё будет работать медленнее, чем было, вот тога и будешь бегать с вопросами

(45) Я не знаю, потому и спрашиваю. На основные мои вопросы я ответ получил, но вот на вопрос о том, почему мне руки отпилить нужно и больше не подпускать к серверам за то, что я хочу это реализовать на виртуальных машинах, никто не отвечает. Динамическая память? Знаю. Выставляю рамки. Ещё какие минусы?

(46) у нас облако на гипервизоре, работает как-то..не жалуемся

(43) Про HYPER-V забыть для 1С!!! Если уж так хотите виртуализацию, то используйте WMWare, например. Но лучше на физическом железе!
Новый сервер тоже жесть жестокая. Слили миллион.
А можно было просто на Алике купить пару 2667v2 по 8к и получить прирост на старом сервере...

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

(48) И как вы "пару 2667v2 по 8к" с Алика предлагаете через бухгалтерию провести?

(50) https://youtu.be/nMzf6joIJOg

(6) "За желание крутить скл и сервер 1с на виртуалках нужно гнать админа с работы с волчьим билетом"

Эта парадигма уже устарела.

(52) Скоро будут гнать из профессии за разворот серверов на хост-системе

(53) Именно так и будет.

(52) Пока это будет в моей власти на подчинённых мне серверах...

Размещение ключевых сервисов на физ. сервере - огромный минус к отказоустойчивости при наличии нормального HA кластера, да и без него развернуть бэкап образа виртуалки на любом другом свободном сервере куда менее геморройно, нежели всю ОС с нуля подымать.
Мифы про адские тормоза 1С на виртуалке в наше время не актуальны.

(56) Истину глаголешь.

(56) Бэкап физсервера и разворот его на другом - копеечная операция.
Ну, в общем, я своё ИМХО озвучил. А вы можете хоть вприсядку - заодно и напляшетесь.

(56) Вы можете развлекать себя игрушками сколько угодно, но когда запускали 1200+ пользователей онлайн 24/7, на виртуалки смотрели, как манул на журналиста.

(58) Давайте голосовать

(58) Не копеечная. У другого физ. сервера может быть другое железо, поэтому просто образ уже отстроенной ОС с приложениями перекинуть не всегда возможно.
И про кластер я не зря упомянул. При его наличии время восстановления сокращается до времени загрузки ОС, а если кластер ещё и Fault Tolerance - до пары миллисекунд.
(59) Отказоустойчивость вот этого всего на физ. сервере считалась хоть как-то? 24/7, ага...

1С+SQL на виртуалку. RDP оставить там, где была.

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

(63) С ломаными платформами старше 8.3.15 ты получишь только геморрой.

+(64) Тьху, не старше, свежее, конечно же.

(64) брехня

(66) Нет.

(63) "Ломаные работают быстрее"
Бряхня (с)

(64)
Гемор как раз был с лицензиями после обновления на 8.3.15. Целый день предприятие не работало ))). Поставили ломаный и с тех пор проблем с падением лицензией нет. Даже после обновлений.

(68) Ломаные стартуют быстрее. Проверка лицензии занимает время. Вероятно из-за этого возникла популярная точка зрения что они работают быстрее.
Но время запуска не важно для службы которая стартует раз в сутки или реже.

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

(67) если ты чего-то не знаешь, то лучше погуглить

(62): это не 5, это - 3 + 4

(73)+:

(72) Вот и погугли. Ставили какую-то из 16 на пробу, в тестовой среде всё работало, в продакшне на <20 юзерах тоже, как только 150 пользователей ломанулось - ошибка целостности. Все рекомендации с известного сайта были перепробованы.

+(75) Сервер 64 бита, да. 32 проблем не доставлял, но он нам не нужен.

(6) Иногда виртуалка дает быстродействие выше, чем реальное железо. С 1с такое возможно. Например, если реальное железо это 2003 сервер(x64, конечно же), а виртуалка - 2008. Дело в том, что начиная с 8.3.11 рантайм 1с очень не любит старые ОС, и нереально тупит при выделении памяти из системной кучи. И с лишним слоем эмуляции получается _быстрее_, в некоторых случаях - на порядки, если этот слой представлен более новой ОС.

(75) плохо гуглил..работает там всё, от количества юзеров и версии платформы, никак не зависит

(78) Можешь инструкцию скинуть? [email protected]
Неделю и так и эдак, потом забили. Лицензии у нас есть, если что. Нужно для миграции продакшена по хитрому плану.

Нежданно-негаданно изменились вводные данные. Оказывается, пользователи работают на толстых клиентах, т.к. это УПП. Имеет ли смысл в таком случае переносить 1С сервер на новое железо или его лучше оставить на месте, где запускаются толстые клиенты?