Сервер 1с + Postgresql + Терминальный сервер #616467

Возник несколько идеологический вопрос какие плюсы/минусы у двух вариантов распределения 1с (клиент-серверный вариант 1с 8.2) между двумя серверами... 1 вариант: сервер БД + сервер 1с на одном сервере (Linux) и терминальный сервер на другом (Windows) 2 вариант: сервер БД на одном сервере (Linux) и сервер 1с + терминальный сервер на другом (Windows) Сервера по производительности считаем примерно одинаковыми (только под БД наверное более производительна дисковая подсистема)... У кого какие соображения?

отдельно сервер 1с, отдельно сервер скуль и всех на тонкий клиент

Есть группа людей (30-50 процентов), которым не подходит тонкий клиент. Т.е. терминальник так или иначе нужен... В вашем варианте сервер 1с под линукс или под винду?

ап

Обычно при небольшом количестве пользователей выгодно держать БД+1С на одном, отдельно терминал

ибо скорость обмена между sql и 1c сервером будет выше

если бы вы не использовали сервер терминалов, то на сколько серверов было бы - один или два?

Не вижу толку от терминала, для баз SQL :( До 50~70-ти человек хватит полностью 1с и БД на одном.

если от виндусового сервера терминалов отказаться совсем нельзя, то поставил бы сервер 1С на нем же. Версии клиента и версии сервера приложений должны совпадать. А для обновленных версий платформы обновки под виндой идут одновременно, а под линукс с задержкой. так наверное они же толстых клиентов в терминалах запускают, а не в wine-сеансах.

А ну если очень удаленно пускать, тогда да надо серв.терминалов. Но у нас то все через вайн :)

сервер терминалов желательно держать отдельно от сервера БД и сервера 1С. Опять же .

нам нужно на вырост, плюс лицензии МС (недавно слышал что CAL лицензии требуются для любого подключения к серверу, т.е. если у нас 100 лицензий на 1с, и сервер 1с на винде, то CAL лицензий нужно 100)... наверное 2. в принципе ваше мнение понятно. Спасибо большое... а если больше 70, 100 и выше (на вырост) Вайн несколько не подходит, из-за торгового оборудования (хотя на этом поприше возможно изменилось...) Спасибо... Тогда вопрос в производительности сервера БД + 1с - какие пожелания/рекомендации к нему?

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

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

+13 тороговое оборудование заставлять работать в терминальных сессиях, имхо, задачка нетривиальная - стоит ли овчинка выделки?

Для бухгалтерии обновления можем подождать... по сути клиенты у нас все под виндой, просто канал до некоторых клиентов - нестабильный, поэтому используем удаленник, в дальнейшем будем переходит на тонкий клиент. Торговое оборудование (Сканер ШК, Принтер Этикеток/Чеков) нормально работают в удаленнике... Сейчас есть 2 сервера Сервер БД - 2*Xeon 5110, 4*SAS 15K 70Gb + 2*SATA, 16Gb RAM, Centos 5, Postgresql 8 Сервер 1c - 2*Xeon 5420, 4*SATA, 16Gb RAM, Windows 2008 r2, Сервер 1c 8.2 + Терминальный сервер База УТ 10.2 сильно модифицированная, в ближайшее время планируем переход на УТ 11. Планируем брать сервер (на замену серверу 1с) и думаю как лучше организовать структуру, хочется сделать отказоустойчивость. Планировал процы с текущего сервера 1с перекинуть на сервер БД, а из сервера 1с сделать кластер для сервера БД. И получится отказоустойчивый сервер БД. Остается вопрос с отказоустойчивым сервером 1с и cal лицензиями MS.)))

В вашем случае можно на новый сервер(с как можно бОльшим объемом памяти) поставить сервер 1С и PostgreSQL 9(на CentOS 6.2), на сервер с Xeon 5110 - терминальный сервер, а сервер с Xeon 5420 сделать резервным, необязательно кластер, просто, чтобы был наготове. Если хотите на вырост, берите новый сервер на последних Xeon-ах , ну и на память не скупиться(вашему руководству). Полностью согласен с .

Спасибо. Насчет резервного, почему не кластер? И почему на резерв Xeon 5420, а не Xeon 5110? Новый планируется E5-2620 + 24-32Gb RAM. (Дисковую перекинем с текущего сервера БД). До какого количества пользователей хватит такого в режиме сервер 1с + сервер БД? (на Ваш взгляд)? Среднее количество документов 1500-2000 документов в день (рост ~20% в год)...

5420 производительнее, чем 5110(тактовая частота, кэш, количество ядер), логичнее его сделать сервером приложений и БД и когда(если) он вам понадобится, пользователи будут более благодарны. Если для вас критично время простоя, то конечно, можно постараться сделать и отказоустойчивый кластер на Centos, правда, как будут себя вести сервер приложений 1С и Postgres я не знаю. Делать Failover Cluster на Windows - дороговато, все в двойном экземпляре и, вроде бы, Enterprise или Datacenter должно быть. А сейчас сколько пользователей и как себя ведут сервера?

Ключ 1с на 100 пользователей. Реально пользователей где-то 75. В терминальнике сидят где то 45... Субъективно иногда подтормаживает. Что именно никак не могу до конца оценить. Руководство поставило условие минимизировать потенциальное время простоя до 5-10 минут. Думаю сделать кластер Postgresql (streaming replication) и 1с кластер. В случае падения основного сервера перекидываем на резервный... Отсюда и возник вопрос есть ли смысл разводить 1с и постгри по серверам. В близжайших планах переход на УТ11 и тонкий клиент (не полностью)...

+ Рост количества пользователей / документов грубо оцениваем на ~20% в год...

1. у меня вариант 1 пашет без проблем.

пора уже центос6 и постгри9 )

А можно поподробней про Ваше железо и нагрузку? Для обновления нужен выходной день. А политика компании - 2 выходных в год. И ближайший не скоро))) Думал заменить сервер 1с + терминальник, теперь вот обдумываю переиграть систему...

Посмотрите в сторону более топовых процессоров, понятно, что E5-2680 стоит в 4 раза дороже, и это сильно сдерживающий фактор. Просто сервер приложений(на мисте это иногда обсуждалось) заметно лучше работает(быстрее, по крайней мере) на процессорах с большим объемом кэша и с большей тактовой частотой. Памяти 24-32Гб, вроде, мало на 75-100 юзеров, хотя бы 64, ну и от размера баз зависит. Для полного счастья можно 2 блока питания(+ еще один мирно лежит в резерве и ждет, пока его спишут) и ИБП киловатта на 3-4 с двойным преобразованием и дополнительной батареей. Также не помешает запас дисков ну и батарейка или безбатарейный кэш на раид контроллер. Авось пронесет... Вы же  на вырост хотели, с запасом. Как-то так...

Тогда почему не E5-2643, частота вроде как выше, кеша на ядро также... По дисковой много не понятного. Сколько винтов в RAID 10 будет разумным, какие лучше подходят, может вообще SSD. Это все Вы для первого варианта привели? База сейчас под 20Gb в postgres, dt файл где-то 1-1,2Gb. На УТ11 не представляю как будет...

Там минимум 4 надо в RAID 10, винты под базу надо брать SAS, с SSD не стоит связываться лучше еще один RAID на SAS винтах. RAIDы можно и попроще RAID 1 или RAID 5. И по оптимизации postgres маны почитайте, есть такая крутая фича как tablespacing, например можно разместить таблицы на одном диске, индексы на другом, а логи на третьем. База у вас небольшая надо смотреть на ежемесячный прирост, ну и сейчас помониторить счетчики производительности (нагрузка на диск, проц, память). По личному опыту скажу что 24-32Гб для 75-100 хватит с головой, если в конфигурацию никто криворукий не влазил (а если влез то там не факт что и больше спасет =)). + память можно докупить позже. ИМХО из того что влияет на производительность главное дисковая подсистема и оптимизация СУБД.

RAID 5 вроде как плохо для БД, на записи проседать будет... (ИМХО). По оптимизации почитаю, про tablespacing не знал, но xlog итак разделен (пишу на системный SATA RAID 1). По счетчикам производительности есть какие нибудь рекомендации? Если честно никак не могу найти объективных показателей и их оценок для такого мониторинга... С оптимизацией конфигурации все плохо. Сейчас УТ10.2, измененная. Большинство изменений не оптимизированы (да и сама УТ10.2 я думаю корявая для Постгри). Ну насколько я вижу по текущей конфе, на сервере БД иногда не хватает процессора (при серьезных отчетах ядро нагружено на 100% в течении нормального времени). В фоне идут обмены с битриксом (изменения обмениваются 10-40 минут, полные - пара часов).

Объясните мне непутевому зачем для трехзвенки нужен терминал? С файловой базой все понятно, но зачем городить лишний костыль который не прибавляет ни скорости ни удобства, а в последнем скорее убавляет. Кроме того интерфейс на локальном компьютере намного быстрее отрисовывается.

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

.

Ах, да мой ответ БД, 1С

ибо

На узком канале техзвенка 1с 8.0, 8.1 требует большего времени чтобы перекачать данные на клиента и требует более или менее производительных компьютеров. Тонкий клиент в выигрыше, но для него нужно изменять конфигурацию. Плюс зоопарк из 100 компьютеров несколько легче обновить с удаленником (в этом случае обновил 1с на удаленнике и все, а без рдп нужно обновлять на клиентских компьютерах). Все это мое ИМХО и мы потихоньку движемся к сокращению клиентов в удаленнике, но пока это долгосрочная перспектива.... , аргументы есть какие нибудь?

канал какой промеж 1С и терминала?

Между 2мя серверами - 1Gb (воткнуты вторыми сетевухами перекрестным кабелем друг в друга...)

ну и?

в Я то говорил про канал между пользователем и терминалкой/1с. Напримера удаленный офис, либо руководитель в командировке, ну и т.д....

ап

Ставь SSD - сейчас они уже значительно дешевле, надежнее и гораздо быстрее.   Их не советуют те кто с ними не работал. Последние модели имеют скорость 400. Чтобы это же получить, нужно 6 SAS 15к raid10. Посчитай деньги.

Да, для первого. Немного производительностью мерялись. E5-2643 - 4 ядра, E5-2680(87, 90) 8 ядер. У вас же не 15-20 человек работают одновременно, а 100. Подумал, что может последовать вопрос про hyper-threading, включать или не включать. Думаю, не включать(хотя есть соблазн). Про MS SQL пишут, что он неважно работает с этой технологией, производительность падает(на мисте тоже было про это), про PostgreSQL не знаю, проверять не пробовал. Хотя запускал тесты LINPACK с hyper-threading и без. Во втором случае производительность была выше почти в 2 раза. На десктоповом i3-2130 показало 22 и 44-45 GFlops, а на 4-х процессорном E7-4870(с двумя процессорами) 100 и 172 GFlops. Наверное, к работе  СУБД это может и не иметь непосредственного отношения, но все же...

Пишут, что и у PostgreSQL при включенном HT производительность падает.

О... Спасибо большое... Почитаю...

ага, тек кто с ними работал создают темы тут на мисте:

Ну так это же потребительские SSD. По идее с серверными таких проблем быть не должно... Хотя хорошей статистики пока нет...

В дополнение к сказанному(если еще интересно). Погонял тест Гилева на своем рабочем компе, i3-2130, 3.4 ГГц, 16 ГБ памяти, все 64-х разрядное(CentOS 6.2, PostgreSQL, 1C) с hyper-threading и без. Получилось 37.3 и 40.3 балла соответсвенно. То есть hyper-threading ухудшает производительность, не намного, но все же. Думается, что с ростом количества пользователей будет производительность будет падать быстрее с hyper-threading , чем без.

Странно если честно. По идее на одном процессе разницы быть не должно. По идее, но не точно, если у процессора 4 реальных и четыре виртуальных ядра, то возможно проседание при 5 и выше одновременных потоках.

Все равно циклы перезаписи не бесконечны