Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

Перенос SQL сервера из файлопомойки в физический сервер.

Перенос SQL сервера из файлопомойки в физический сервер.
Я
   studiodlx
 
18.06.20 - 11:39
4. Перенести 1С-сервер на виртуалку50% (2)
3. Перенести SQL Server на виртуалку25% (1)
5. Перенести по-другому25% (1)
1. Перенести SQL Server на хост-систему0% (0)
2. Перенести 1С-сервер на хост-систему0% (0)
6. Ничего не переносить0% (0)
Всего мнений: 4

Добрый день форуму. Я системный администратор с нулевым опытом работы с 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. Имеет ли такой вариант право на существование? Какое распределение ресурсов сервера в процентном выражении между виртуалками должно быть?

Тапками не кидайте, свою компетенцию я указал. Если исходных данных недостаточно, могу дополнить. Буду благодарен за любые ответы, советы и прочую полезную информацию.
   H A D G E H O G s
 
1 - 18.06.20 - 11:55
Вы все сделали не так.
   H A D G E H O G s
 
2 - 18.06.20 - 11:58
Но в вашем случае - перенести SQL, сервер 1С на новый сервер.
Никаких виртуалок.
Терминалку оставить на старом сервере.

SQL настроить по рекомендациям 1С
   H A D G E H O G s
 
3 - 18.06.20 - 11:59
3. Читал что базы, журналы, temp базы и temp журналы желательно разносить по разным физическим дискам. В нашем случае массив только один. Приемлемо ли это?

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

Самое главное mdop=1. Это 90% успеха.
   H A D G E H O G s
 
4 - 18.06.20 - 12:00
4. Лично у меня чешутся руки запилить на отдельных виртуальных машинах 1С+SQL и RDP

Отпили их, чтобы не чесались.
   H A D G E H O G s
 
5 - 18.06.20 - 12:02
2. Имеет ли смысл переносить только SQL? Будет ли прирост в производительности?
Нет. У вас производительность упирается в сервер 1С, в ядро проца. Это если у вас нет косяков в данных типа динамического обновления, итогов с начала тысячелетия, depotfiles, каких нибудь планов запросов с crossjoin.
Вы и сервер новый херово купили.
   ДенисЧ
 
6 - 18.06.20 - 12:07
За желание крутить скл и сервер 1с на виртуалках нужно гнать админа с работы с волчьим билетом. С записью в трудовую.
Чтобы его потом никто не подпускал к серверам ближе километра...
   Волшебник
 
Модератор
7 - 18.06.20 - 12:14
Имеет смысл перенести только SQL-сервер. Это очень правильно!
   Галахад
 
8 - 18.06.20 - 12:23
(7) Чем же правильно? Процессор-то на новом пошустрее, и на нем службе 1С будет комфортнее.
   yurikmellon2
 
9 - 18.06.20 - 12:34
(3) а можно чуть поподробней про mdop=1. Почему нельзя включать параллелизм? Вроде как с ним запросы быстрее выполняются
   ssh2006
 
10 - 18.06.20 - 12:51
(9) если кривых запросов нет то с параллелизмом работает быстрее. Чем и пользуюсь.

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

"основная причина - исключить сценарий, при которой один длительный запрос с неэффективным планом выполнения создаст за счет параллелизма нагрузку на CPU, не позволяющую другим транзакциям выполняться с обычной для системы скоростью."
https://its.1c.ru/db/metod8dev#content:5945:hdoc
   timurhv
 
11 - 18.06.20 - 13:21
(9) 2 консультанта запустили перерасчеты в ЗУП, в итоге 800 человек больше не могли работать.
   Волшебник
 
Модератор
12 - 18.06.20 - 13:24
(8) на новом ядер больше

2x Xeon E5-2620 v2 - 12 ядер
2x Xeon Gold 6144 - 16 ядер
   Галахад
 
13 - 18.06.20 - 13:26
(12) Вопрос, почему " только SQL-сервер", а не вместе с сервером 1С.
   Волшебник
 
Модератор
14 - 18.06.20 - 13:27
(13) Лучше вместе, но можно и по отдельности. Чем больше удастся забрать с сервера терминалов, тем лучше.
   Мистикан
 
15 - 18.06.20 - 13:27
(3) это только в случае если SQL тормозит на паралельности
   mistеr
 
16 - 18.06.20 - 13:30
А что так все против виртуалок для 1С сервера и скуля? Есть проблемы?
   Мистикан
 
17 - 18.06.20 - 13:31
(6) Смотря как к вопросу подойти. Можно и вполне качественно сделать
(12) Если утилизация проца 80+%, если замеры показывают что SQL ждет на проце. Тогда да
   Мистикан
 
18 - 18.06.20 - 13:32
(16) обычно просто у тех кто делает руки не из того места. Есть проблемы с виртуальными дисками, но это лечится.
   Мистикан
 
19 - 18.06.20 - 13:34
(16) мы месяца 3 бодались. в итоге -7% производительности в сравнении с физическим сервером.
   H A D G E H O G s
 
20 - 18.06.20 - 13:37
А зачем параллелизм в OLTP ? Ну, иногда он нужен, например при переносе данных и реструктуризации, но в рабочей базе - нет. Как правило, возникают кривые планы запросов и ожидания на синхронизации.
   Волшебник
 
Модератор
21 - 18.06.20 - 13:38
(16) Только так и надо делать
   H A D G E H O G s
 
22 - 18.06.20 - 13:40
(16) Да, есть проблемы.
На виртуалках возникают проблемы с сеансовыми данными.
Я подозреваю, что из за динамического распределения памяти, когда память виртуалки подходит к концу "динамически" выделенного куска, сервер 1С начинает скидывать сеансовые данные из памяти на диск.
Но доказать не могу.
   mistеr
 
23 - 18.06.20 - 13:41
(20) Для отчетов на плохо спроектированых метаданных :)
   Волшебник
 
Модератор
24 - 18.06.20 - 13:41
(22) В гипервизоре можно поставить буфер побольше, например, 50% вместо 20%.
   mistеr
 
25 - 18.06.20 - 13:44
(22) Если известно, в какие файлы скидываются сеансовые данные, можно промониторить.
   H A D G E H O G s
 
26 - 18.06.20 - 13:44
(24) Я предпочитаю жить спокойно без вот этого всего и сокращаю количество проблемных мест.
   mistеr
 
27 - 18.06.20 - 13:47
(26) А фиксированное выделение памяти не решает проблему?
   H A D G E H O G s
 
28 - 18.06.20 - 13:54
(27) Я не готов ответить на этот вопрос. Я просто пишу то, с чем сталкивался.
Те сервера, которые рекомендовал я - физические, мы за них отвечаем и администрируем.
Те сервера, которые развернуты вопреки рекомендациям - в зоне ответственности админов заказчиков и по ним я могу сказать только о наблюдаемых проблемах. Как они там админятся - я не в курсе.
   H A D G E H O G s
 
29 - 18.06.20 - 14:01
(23) Отчеты могут и подождать. Колесико крутится, рабочий день мутится.
   yurikmellon2
 
30 - 18.06.20 - 14:20
(10) понятно, спасибо за информацию
 
 Рекламное место пустует
   Волшебник
 
Модератор
31 - 18.06.20 - 14:22
(28) Рекомендации разные бывают...
   studiodlx
 
32 - 18.06.20 - 15:14
(1) Я не сделал ещё ровным счётом ничего
   H A D G E H O G s
 
33 - 18.06.20 - 15:20
(32) Ну значит - хотели сделать
   s-n-a-y
 
34 - 18.06.20 - 16:05
(0) не забудьте еще на новом сервере поставить план электропитания на Высокий (это есть в рекомендациях по настройке 1с), ибо в отличии от домашних пк на серверах динамический разгон ужасно инертный, можете проверить в диспетчере
   pessimist
 
35 - 18.06.20 - 17:22
(6) Минус 10-15 попугаев по тесту Гилёва. Но удобнее. Если важна скорость то сервер один и физический если простота восстановления в случае отказа то виртуальный или два виртуальных.
   rphosts
 
36 - 18.06.20 - 17:25
(2) >Никаких виртуалок.

а как-же насчёт получить много секса и никакого удовольствия?
   X Leshiy
 
37 - 18.06.20 - 17:42
(0)
Переносить 1С + SQL на новый сервант.
Без виртуалок.
ОСь на рэйд, базы, tempdb, журналы на SSD, разделить по вкусу.
   X Leshiy
 
38 - 18.06.20 - 17:43
(0)
Старый сервант перестряхнуть, пропылесосить и застеклить заново под RDP, файлопомойку и прочее.
   pessimist
 
39 - 18.06.20 - 17:49
(0)
1. У вас быстрая дисковая система. Можно на одном массиве. Делить на разделы как удобнее.
В общем случае, сама ОС не требует быстрого диска и нормально стартует с механики. Но временные файлы ОС и 1С по умолчанию на системном диске. Это можно изменить, но само оно не изменится.

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

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

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

Замечание по железу:
На новом сервере меньше памяти. Это действительно так? Докупать возможно, свободные слоты есть?
Серверов всего два или есть ещё?
   studiodlx
 
41 - 18.06.20 - 19:20
(40) Да, ОЗУ меньше. В подборе железа не участвовал, думаю, урезали по причине "ну только под SQL же".
   Asmody
 
42 - 18.06.20 - 19:31
(22) не должно быть никакого [динамического распределения памяти]. На виртуалках под 1С и БД память прибивается гвоздями (впрочем, как и все остальное). И выделенный сетевой интерфейс, прокинутый в виртуалку.
"Вот тогда дети и не станут пропадать!"
   studiodlx
 
43 - 18.06.20 - 20:32
Я вижу, что мнения разделились. Виртуальное или физическое? За много лет единственный минус Hyper-V, обсуждение которого я видел на форумах, это динамическая память. Проблема решаемая. Так всё же, чем ещё виртуальная машина "медленнее" физической?
   studiodlx
 
44 - 18.06.20 - 21:21
(5) Что именно по Вашему мнению мы сделали "херово"?
   Ёпрст
 
45 - 18.06.20 - 22:57
(0) Та не парься, сделай, как знаешь.
А вот когда это всё будет работать медленнее, чем было, вот тога и будешь бегать с вопросами
   studiodlx
 
46 - 18.06.20 - 23:15
(45) Я не знаю, потому и спрашиваю. На основные мои вопросы я ответ получил, но вот на вопрос о том, почему мне руки отпилить нужно и больше не подпускать к серверам за то, что я хочу это реализовать на виртуальных машинах, никто не отвечает. Динамическая память? Знаю. Выставляю рамки. Ещё какие минусы?
   Ёпрст
 
47 - 18.06.20 - 23:24
(46) у нас облако на гипервизоре, работает как-то..не жалуемся
   Turku
 
48 - 19.06.20 - 00:44
(43) Про HYPER-V забыть для 1С!!! Если уж так хотите виртуализацию, то используйте WMWare, например. Но лучше на физическом железе!
Новый сервер тоже жесть жестокая. Слили миллион.
А можно было просто на Алике купить пару 2667v2 по 8к и получить прирост на старом сервере...
   rphosts
 
49 - 19.06.20 - 07:52
(48) разницы между гипером и вм особой нет, на обох при грамотной настройке в лучшем случае минус 10% производительности как палата за виртуализацию.
   Asmody
 
50 - 19.06.20 - 09:49
(48) И как вы "пару 2667v2 по 8к" с Алика предлагаете через бухгалтерию провести?
   H A D G E H O G s
 
51 - 19.06.20 - 09:55
   Изучаю1С8
 
52 - 19.06.20 - 11:13
(6) "За желание крутить скл и сервер 1с на виртуалках нужно гнать админа с работы с волчьим билетом"

Эта парадигма уже устарела.
   Волшебник
 
Модератор
53 - 19.06.20 - 11:18
(52) Скоро будут гнать из профессии за разворот серверов на хост-системе
   Изучаю1С8
 
54 - 19.06.20 - 11:23
(53) Именно так и будет.
   ДенисЧ
 
55 - 19.06.20 - 11:28
(52) Пока это будет в моей власти на подчинённых мне серверах...
   Paint_NET
 
56 - 19.06.20 - 11:33
Размещение ключевых сервисов на физ. сервере - огромный минус к отказоустойчивости при наличии нормального HA кластера, да и без него развернуть бэкап образа виртуалки на любом другом свободном сервере куда менее геморройно, нежели всю ОС с нуля подымать.
Мифы про адские тормоза 1С на виртуалке в наше время не актуальны.
   Волшебник
 
Модератор
57 - 19.06.20 - 11:35
(56) Истину глаголешь.
   ДенисЧ
 
58 - 19.06.20 - 11:37
(56) Бэкап физсервера и разворот его на другом - копеечная операция.
Ну, в общем, я своё ИМХО озвучил. А вы можете хоть вприсядку - заодно и напляшетесь.
   H A D G E H O G s
 
59 - 19.06.20 - 11:39
(56) Вы можете развлекать себя игрушками сколько угодно, но когда запускали 1200+ пользователей онлайн 24/7, на виртуалки смотрели, как манул на журналиста.
   Волшебник
 
Модератор
60 - 19.06.20 - 11:42
(58) Давайте голосовать

4. Перенести 1С-сервер на виртуалку
 
 Рекламное место пустует
   Paint_NET
 
61 - 19.06.20 - 11:42
(58) Не копеечная. У другого физ. сервера может быть другое железо, поэтому просто образ уже отстроенной ОС с приложениями перекинуть не всегда возможно.
И про кластер я не зря упомянул. При его наличии время восстановления сокращается до времени загрузки ОС, а если кластер ещё и Fault Tolerance - до пары миллисекунд.
(59) Отказоустойчивость вот этого всего на физ. сервере считалась хоть как-то? 24/7, ага...
   Paint_NET
 
62 - 19.06.20 - 11:43
1С+SQL на виртуалку. RDP оставить там, где была.

5. Перенести по-другому
   Простенький вопросик
 
63 - 19.06.20 - 13:23
Лично мое мнение, что 1с надо держать вместе с скл на одном сервере, собранном на десктопном железе с максимальной производительностью в однопоточных приложениях, ну и ссд диск нужного размера производительный и память 32гб. Мое мнение, что 1с и скл должны быть ломаными, но с отдельно лежащими лицензиями, разумеется. Ломаные работают быстрее и не теряются лицензии время от времени или после обновлений. Юридически это вроде бы нарушение, но по факту никого не привлекали при фактическом наличии купленной лицензии.
   Paint_NET
 
64 - 19.06.20 - 13:28
(63) С ломаными платформами старше 8.3.15 ты получишь только геморрой.
   Paint_NET
 
65 - 19.06.20 - 13:29
+(64) Тьху, не старше, свежее, конечно же.
   Ёпрст
 
66 - 19.06.20 - 13:30
(64) брехня
   Paint_NET
 
67 - 19.06.20 - 13:32
(66) Нет.
   ДенисЧ
 
68 - 19.06.20 - 13:33
(63) "Ломаные работают быстрее"
Бряхня (с)
   Простенький вопросик
 
69 - 19.06.20 - 13:35
(64)
Гемор как раз был с лицензиями после обновления на 8.3.15. Целый день предприятие не работало ))). Поставили ломаный и с тех пор проблем с падением лицензией нет. Даже после обновлений.
   pessimist
 
70 - 19.06.20 - 19:53
(68) Ломаные стартуют быстрее. Проверка лицензии занимает время. Вероятно из-за этого возникла популярная точка зрения что они работают быстрее.
Но время запуска не важно для службы которая стартует раз в сутки или реже.
   H A D G E H O G s
 
71 - 19.06.20 - 20:21
Вот с лицензиями - это как раз тот редкий случай, когда нужно подождать, чем потом шить варежки.
   Ёпрст
 
72 - 19.06.20 - 20:40
(67) если ты чего-то не знаешь, то лучше погуглить
   Cthulhu
 
73 - 19.06.20 - 21:38
(62): это не 5, это - 3 + 4

3. Перенести SQL Server на виртуалку
   Cthulhu
 
74 - 19.06.20 - 21:38
(73)+:

4. Перенести 1С-сервер на виртуалку
   Paint_NET
 
75 - 22.06.20 - 05:31
(72) Вот и погугли. Ставили какую-то из 16 на пробу, в тестовой среде всё работало, в продакшне на <20 юзерах тоже, как только 150 пользователей ломанулось - ошибка целостности. Все рекомендации с известного сайта были перепробованы.
   Paint_NET
 
76 - 22.06.20 - 05:32
+(75) Сервер 64 бита, да. 32 проблем не доставлял, но он нам не нужен.
   Провинциальный 1сник
 
77 - 22.06.20 - 06:50
(6) Иногда виртуалка дает быстродействие выше, чем реальное железо. С 1с такое возможно. Например, если реальное железо это 2003 сервер(x64, конечно же), а виртуалка - 2008. Дело в том, что начиная с 8.3.11 рантайм 1с очень не любит старые ОС, и нереально тупит при выделении памяти из системной кучи. И с лишним слоем эмуляции получается _быстрее_, в некоторых случаях - на порядки, если этот слой представлен более новой ОС.
   Ёпрст
 
78 - 22.06.20 - 07:05
(75) плохо гуглил..работает там всё, от количества юзеров и версии платформы, никак не зависит
   Paint_NET
 
79 - 22.06.20 - 07:11
(78) Можешь инструкцию скинуть? pdpmwjqo@supere.ml
Неделю и так и эдак, потом забили. Лицензии у нас есть, если что. Нужно для миграции продакшена по хитрому плану.
   studiodlx
 
80 - 23.07.20 - 15:07
Нежданно-негаданно изменились вводные данные. Оказывается, пользователи работают на толстых клиентах, т.к. это УПП. Имеет ли смысл в таком случае переносить 1С сервер на новое железо или его лучше оставить на месте, где запускаются толстые клиенты?


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.