Сервер терминалов + сервер 1с + sql
 

Доброго времени суток

Имеется сервак на базе intel xeon e5 2620 v3 6 ядерный 32 ггб
Роль сервера терминалов. 1с 8.3 Конфигурации БП 4 человека, ЗУП 3 человека и УТ11 15. В настоящий момент все базы работают в файловом режиме.

Вопрос по серверу SQL. Покупать под него отдельный сервер или лучше на существующем создать виртуальную машину? Если виртуальную, то как оптимальнее поделить ресурсы?

Виртуалку точно не надо.
Начните с установки на этом же сервере, и если не будет хватать, то тогда уже отдельный сервер.
Диски нужно SSD - хотя бы десктопные (просто умрут быстрее и чуток тормознее будут работать).
Если ssd никак - то нужно разделение на разные диски файлов БД и журналов, а также отдельно tempdb.
Сервер 1С уже купили? Без него SQL не нужен )
Ни SQL, ни 1C Сервер на виртуалки не пихать - только хуже будет.

Насколько я понимаю Raid ssd смысла не имеет?

raid 1 или 10 или хотя бы 5 - обязательно. И SQLу ограничьте использование памяти, а то он сожрет все, что есть.

Просто вычитывал, что поскольку ssd имеют одинаковый ресурс, то и сдохнут они одновременно

прям в один день?

RAID защищает от "незапланированного" выхода из строя одного из дисков, а не от того, что закончился ресурс.
На обычных HDD тоже вполне бывают ситуации, когда одновременно начинают сыпаться диски.

Для этого даже делают сдвижку во времени:
Ставится пара дисков (на примере RAID 1), но при этом покупается 3 шт. Один кладется на полку.
Через полгода планово один из работающих дисков меняется местами с тем, что на полке. Тем самым обеспечивается сразу и запасной диск, и защита от одновременного истечения ресурса.

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

6-alexm13 > капец, вы хоть понимаете как работает сервер БД? ограничить объем использования оперативки SQL'м - ну ну.
SSD??? вируалка - плохо, кто сказал? Для начала было бы не плохо спросить про размер БД. утилизацию процессора.
От этого нужно отталкиваться.
вот график утилизации дисковой подсистемы сервера баз данных на 40 человек. 8 сас дисков на 10к + контроллер 512mb. Ну и зачем тут SSD?
[img]https://ibb.co/3FGWGTy[/img]

[url=https://ibb.co/3FGWGTy][img]https://i.ibb.co/3FGWGTy/image.jpg[/img][/url]

1-alexm13 > не сразу прочел. Отличный совет. Поставить 1с на тот-же сервер где и БД. Это 5.
Много таких конфигураций вы обслуживаете?
что делаете когда 1с "внезапно" съедает оперативку? рестартуете сервер?

вот еще один график, на нем видно как 1с утилизирует память

[url=https://ibb.co/VWB7Mpb][img]https://i.ibb.co/VWB7Mpb/image.jpg[/img][/url]

0-Romul_78 > Самым правильным было бы произвести замеры производительности текущей конфигурации.
Если уж так необходим сервер SQL, то произвести расчет финансовой стороны.
Как вариант, можно сэкономить на железе, купить б.у. сервер с гарантией + попробовать связку PostgreSQL + 1c. по сути, вы заплатите только за железо, франч может для тестов временную лицензию дать.

[quote=wladuha;46940655]ограничить объем использования оперативки SQL'м - ну ну.[/quote]
Вообще-то это является стандартной практикой.
[url]https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/server-memory-server-configuration-options?view=sql-server-2017[/url]

[quote=wladuha;46940670]Поставить 1с на тот-же сервер где и БД. Это 5.[/quote]
Согласен. Надо делать 2 гео-кластера. Один для SQL и один для 1С с ноудами в географически отдаленных дэйта-центрах.

11-v > еще раз прочитайте внимательно статью. ни слова про стандартную практику там не сказано. Задавать параметр использования памяти SQL необходимо в тех случаях, когда ему приходится конкурировать за эти самые ресурсы. ну или если разработчик явно говорит, задайте столько то памяти. Во всех остальных, не мешайте sql работать.
На курсах, тренер говорил, что лучшей практикой будет выделить ОС 4 гб + по 1 гб на каждые 4 гб памяти. все остальное отдать серверу. В 14 sql изменен алгоритм работы sql с памятью, якобы он лучше освобождает страницы, и доп настройка нужна в случаях, указанных выше.

Про гео кластера - ага. С ноУдами)))
Внимательно изучите график утилизации 1с. Эта зараза активно использует оперативную память, а в случае нехватки падает. Лучше заранее избавиться от последствий.

13-wladuha > а тренер на курсах вам рассказывал, что нужно "раскладывать" по разным "шпинделям" файлы БД, журналы и tempdb?
А то вы хвастаетесь (непонятно правда чем там хвастаться) 8 дисков SAS - только там если по уму разложить - то придется 4 отдельных массива делать по 2 диска - под систему, под базы, под логи, под tempdb.
И по факту получится так себе конфигурация - дисков-то маловато )
Ваши графики утилизации с усреднением 30-60 секунд никому не интересны, потому как более интересно поведение дисковой подсистемы в момент проведения документа в 1С.
Память 1С использует активно - а что в этом плохого?
Разве 16 Гб это так много?
Только на ваших графиках пик приходится на вечер после 21:00 - подозреваю, что идет обслуживание баз - бэкапы, переиндексации, возможно какие-то пересчеты. Зато в рабочее время все ровно.
И опять же на графике - общая память, а не процессов 1С - еще не факт, что это 1С )))
А еще сервер 1С можно настроить, чтобы он сам мочил процессы, которые жрут слишком много памяти - но наверно об этом на курсах не рассказывают?

То что вы где-то узнали (послушали или почитали), что якобы нельзя на одном сервере держать 1С сервер и SQL - это еще не означает, что вы - истина в последней инстанции. И не только вы умеете пользоваться системами мониторинга.
Я и без вас прекрасно знаю, что 1С при работе с SQL достаточно мало "мучает" диск и достаточно много - процессор и память. Но это когда памяти достаточно для адекватного кэширования. А еще сервер 1С активно использует tmp-файлы - и если они лежат на "мертвой" дисковой системе, то это скажется на скорости 1С и очень сильно.

Но вот только рассказывать все эти нюансы новичку не имеет никакого практического смысла - он и так задает вопросы про RAID.
Очевидно, что денег ни на адекватное железо, ни на покупку 1С Сервера, и уж тем более MS SQL никто давать не собирается.
Поэтому и совет очень простой - поиграть с SSD - это гарантированно даст улучшение, по сравнению с простыми дисками. Даже обычные десктопные SSD дадут намного лучше результат по random read / write.

[quote=v;46941596]Задавать параметр использования памяти SQL необходимо в тех случаях, когда ему приходится конкурировать за эти самые ресурсы[/quote]
Так здесь как раз такой случай.

14-alexm13 > ваша проницательность так себе. В каком месте я хвастаюсь?
Вы сказали глупость, смиритесь уже. При правильной настройке сервера БД, ему SSD не нужны. Про виртуализацию тоже глупость. Виртруализация - это надежно, потеря в производительности не столь критична. Больше плюсов чем минусов.
Про шпиндели - ага. Вы знаете в каких случаях это нужно делать?

16-wladuha >
Ну если приложение только и делает, что последовательно читает и пишет таблицы - то да, разницы не будет.
Но как только дойдем до random read - то будет ой, т.к. ваши 8 дисков дадут 800 iops (и это если контроллер нормальный как у вас, а то и вовсе будет 400 всего).
Даже десктопные SSD дают в 10 раз больше с одного диска.
Не, все понятно, если БД целиком помещается в ОЗУ - то проблем тоже никаких не будет, правда если кэш "прогретый".
Про виртуализацию - вносится дополнительная задержка, тот самый latency. Однопоточные дисковые операции теряют 10-20%. В многопоточных уже не так все плохо. Но разница есть. И есть рекомендации производителей СУБД запускать их на голом железе. Даже использование внешней СХД вносит задержки. Странно, что вам о них не рассказали на курсах. И это только про дисковую подсистему. По памяти и процессору все тоже самое. Может быть не критично в целом, но оно все равно есть.
Понятно, что иногда этим можно пренебречь, особенно когда удобства превысят потери.
Виртуализация помогает тогда, когда есть куча железных ресурсов и куча сервисов/ролей которые нужно разнести.
А мудрить виртуалки 1С и SQL на одном и единственном хосте - это мудрить виртуалки ради мудрения виртуалок. Разделить ресурсы можно и штатными настройками софта. То что у вас там падает 1С - это исключительно ваша недоработка, а не проблема 1С.

Про шпиндели. Почитайте что такое журнал транзакций в MSSQL, или WAL в PostgreSQL, и зачем он нужен. Его назначение в том числе затем, чтобы фиксировать транзакции на диск по мере их поступления и при этом идет последовательная запись - что обычный HDD может обеспечить на адекватном уровне. А потом уже СУБД фоном будет это все распихивать в файлы БД по мере возможности. Но если его постоянно будут дергать чтением, да еще и рандомно, то скорость линейной записи будет никакая. Поэтому файлы с данными БД и журнал транзакции разносят на разные "шпиндели", "шпиндель" в данном случае это отдельный диск или массив. Кроме того в MS SQL еще есть tempdb, которая тоже любит потыкаться в диск. Поэтому и есть такие рекомендации - все это добро по отдельным дискам/шпинделям/массивам. Если обратите внимание, то MSSQL при создании базы всегда спрашивает куда положить файлы БД, а куда журнал - как думаете, просто так? И при установке тоже спрашивает - а куда положить tempdb?

По факту, если объем БД < 200 Гб, то пара нормальных SSD на 400-500 Гб (Intel s3710 и т.п.), и даже десктопных, когда денег жалеют и нужно делать из говна и палок, закрывают все эти проблемы и нюансы по дисковой подсистеме, включая темпы 1С-ки.
Да и стоят два SSD диска дешевле, чем 8 SAS любого объема.
Повторюсь про ограничения на размер БД.
И прекрасно 1С сервер уживается вместе с СУБД, если их нормально настроить. Хоть на windows, хоть на linux.
Проверено на эксплуатации 20+ серверов (в том числе на "изготовленных" из говна и палок по обстоятельствам), и вот числе без использования SSD )
И я даже не пытаюсь утверждать, что это конструкция самая правильная и лучшая. Каждый сам придет к нужным выводам опытным путем.

17-alexm13 > вы не слышите, или не хотите слышать.
Память сейчас стоит не дорого. это первое.
Второе, 10-20% потери. вы в своем уме?
Про виртуализацию бред.
Смею утверждать, что про шпиндели мне рассказывать ненужно.

[quote=wladuha;46940686] 0-Romul_78 &gt; Самым правильным было бы произвести замеры производительности текущей конфигурации. Если уж так необходим сервер SQL, то произвести расчет финансовой стороны. Как вариант, можно сэкономить на железе, купить б.у. сервер с гарантией + попробовать связку PostgreSQL + 1c. по сути, вы заплатите только за железо, франч может для тестов временную лицензию дать. [/quote]
Сильно не замерял, память используется на 30-40%, процессор 0-4, дисковую систему не замерял пока
Posgre ? Честно нет желания заморачиваться с Линукс. Не только MS SQL

[quote=wladuha;46943663] 14-alexm13 &gt; ваша проницательность так себе. В каком месте я хвастаюсь? Вы сказали глупость, смиритесь уже. При правильной настройке сервера БД, ему SSD не нужны. Про виртуализацию тоже глупость. Виртруализация - это надежно, потеря в производительности не столь критична. Больше плюсов чем минусов. Про шпиндели - ага. Вы знаете в каких случаях это нужно делать? [/quote]
Если бы вам предложили делать виртуализацию или насыпали денег на отдельный сервер что бы вы выбрали?

Тут главный вопрос, есть ли готовая инфраструктура для вируализации (хосты, хранилища, сеть, лицензии и, главное, люди, которые это все обслуживают)? Если да, то можно пробовать и оценивать производительность по ходу дела. Если же всю инфраструктуру надо создать сначала - то это другой вопрос.
Можно, конечно, купить сервер, поставить на него ESX или Hyper-V, а сверху накатить винду. Но это будет виртуализация ради виртуализации без особых преимуществ.

20-Romul_78 > я бы посмотрел на наличие лицензий, производительность сервера, произвел замеры. Если все, говорит о том, что рессурсов хватает, Купил бы второй б.у но с гарантией и хорошей дисковой подсистемой.
Поставил бы на обоих чистый hyper-v, настроил репликацию вм с одного сервера на другой. 1 лицензия MS Server лицензирует 2 ВМ или 1 железку.
Такая конфа как раз и отражена на графиках, настраивал людям 4 года назад. все еще работает. И она же спасла их от тотального выгорания меди и контроллеров. Один умный человек, занедорого настроил вайфай мост. Молния ударила в тарелку, тарелка подключена была в коммутатор, в него же сервера одним аплинком. У серверов выгорели сетевые карты, а у одного из них еще и контроллер RAID.
Время восстановления 15 мин, при незначительной потери производительности. Через неделю приехал такой же БУ hp dl380 g7, но с 16-ю sas 146 15к дисками. За сервер отдали что-то вроде 100к.
Когда время восстановления сервиса критична, для меня выбор очевиден.
Можно конечно накрутить отказоустойчивость и на железе, но это в 2 раза дороже.

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