1c сервер 12 подключений
Во время поиска решения "как лучше настроить терминальный сервер" для нужд компании, в основном сталкивался с разрозненной информацией по каждой из проблем в отдельности, но единой статьи как настроить от и до так и не нашел. Данный материал является компиляцией различной информации.
Вводные
Настроенный и работающий AD
Наличие файлового сервера (Желательно на основе Windows server)
Установка системы
Во время установки системы важно учесть только один нюанс — дисковую систему необходимо разбить на два логических раздела. Первый (малый, 70 – 120 Гб) выделить для системных файлов, второй — под пользовательские данные.
На это есть две основные причины:
Системный диск малого размера быстрее работает и обслуживается (проверка, дефрагментация, антивирусное сканирование и так далее)
Пользователи не должны иметь возможность хранить свою информацию на системном разделе. В противно случае, возможно переполнение диска и, как результат, медленная и нестабильная работа сервера.
Установка служб удаленных рабочих столов
После перезагрузки открываем Диспетчер серверов и нажимаем Управление - Добавить роли и компоненты:
В окне «Выбор типа установки» выбираем Установка служб удаленных рабочих столов и нажимаем Далее:
В окне «Выбор типа развертывания» выбираем Быстрый запуск и нажимаем Далее:
В «Выбор сценария развертывания» — Развертывание рабочих столов на основе сеансов — Далее:
Еще раз Далее — при необходимости, ставим галочку «Автоматически перезапускать конечный сервер, если это потребуется» и кликаем по Развернуть.
Настройка лицензирования удаленных рабочих столов
Для корректной работы сервера, необходимо настроить службу лицензирования. Для этого открываем диспетчер серверов и кликаем по Средства - Terminal Services - Диспетчер лицензирования удаленных рабочих столов:
В открывшемся окне кликаем правой кнопкой мыши по нашему серверу и выбираем Активировать сервер:
В открывшемся окне дважды кликаем Далее - заполняем форму - Далее - Далее - Снимаем галочку «Запустить мастер установки лицензий» - Готово.
Снова открываем диспетчер серверов и переходим в «Службы удаленных рабочих столов»:
В «Обзоре развертывания» кликаем по Задачи - Изменить свойства развертывания:
В открывшемся окне переходим в Лицензирование - Выбираем тип лицензий - прописываем имя сервера лицензирования (в данном случае локальный сервер) и наживаем Добавить:
Применяем настройки, нажав OK.
Добавление лицензий
Открываем диспетчер серверов и кликаем по Средства - Terminal Services - Диспетчер лицензирования удаленных рабочих столов:
В открывшемся окне кликаем правой кнопкой мыши по нашему серверу и выбираем Установить лицензии:
В открывшемся окне нажимаем Далее - выбираем программу, по которой куплены лицензии, например, Enterprise Agreement - Далее - вводим номер соглашения и данные лицензии - выбираем версию продукта, тип лицензии и их количество - Далее - Готово.
Проверить статус лицензирования можно в диспетчере серверов: Средства - Terminal Services - Средство диагностики лицензирования удаленных рабочих столов.
1С:Предприятие 8.2
В версии 8.2 мы захотели, чтобы приложения 1С могли запускаться не только в нативном (исполняемом) клиенте, а ещё и в браузере (без модификации кода приложения). В связи с этим, в частности, встала задача отвязать текущее состояние приложения от текущего соединения с рабочим процессом rphost, сделать его stateless. Как следствие возникло понятие сеанса и сеансовых данных, которые нужно было хранить вне рабочего процесса (потому что stateless). Был разработан сервис сеансовых данных, хранящий и кэширующий сеансовую информацию. Появились и другие сервисы — сервис управляемых транзакционных блокировок, сервис полнотекстового поиска и т.д.
В этой версии также появились несколько важных нововведений – улучшенная отказоустойчивость, балансировка нагрузки и механизм резервирования кластеров.
В заключение
Благодаря механизму отказоустойчивости приложения, созданные на платформе 1С:Предприятие, благополучно переживают разные виды отказов рабочих серверов в кластере, при этом бо́льшая часть клиентов продолжают работать без перезапуска.
Бывают ситуации, когда мы не можем повторить вызов, или падение сервера застает платформу в очень неудачный момент времени, например, в середине транзакции и не очень понятно, что с ними делать. Мы стараемся обеспечить статистически хорошую выживаемость клиентов при падении серверов в кластере. Как правило, средние потери клиентов за отказ сервера – единицы процентов. При этом все «потерянные» клиенты могут продолжить работу в кластере после перезапуска клиентского приложения.
Надежность кластера серверов 1С в версии 8.3 существенно повысилась. Уже давно не редкость внедрения продуктов 1С, где количество одновременно работающих пользователей достигает нескольких тысяч. Есть и внедрения, где одновременно работают и 5 000, и 10 000 пользователей — например, внедрение в «Билайне», где приложение «1С: Управление Торговлей» обслуживает все салоны продаж «Билайн» в России, или внедрение в грузоперевозчике «Деловые Линии», где приложение, самостоятельно созданное разработчиками ИТ-отдела «Деловых Линий» на платформе 1С:Предприятие, обслуживает полный цикл грузоперевозок. Наши внутренние нагрузочные тесты кластера эмулируют одновременную работу до 20 000 пользователей.
В заключение хочется кратко перечислить что ещё полезного есть в нашем кластере (список неполный):
Установка сервера 1С:Предприятие
Для примера установим сервер 1С:Предприятие 8.3.16.1063 со следующими параметрами:
Рисунок 1 - Установка сервера 1С. Выбор компонентов
Нажимаем далее и убираем галочку с «Установить сервер 1С:Предприятие как сервис», так как на сервере уже есть служба агента сервера 1С:Предприятие.
Рисунок 2 - Установка сервера 1С. Выбор пользователя
На этом завершаем установку сервера 1С:Предприятие. Далее нужно установить платформу.
1С:Предприятие 8.0
Первая версия сервера приложений 1С (еще не кластер) появилась в версии платформы 8.0. До этого 1С работала в клиент-серверном варианте, данные хранились в файловой СУБД или MS SQL, а бизнес-логика работала исключительно на клиенте. В версии же 8.0 был сделан переход на трехзвенную архитектуру «клиент – сервер приложений – СУБД».
Сервер 1С в платформе 8.0 представлял собой СОМ+ сервер, умеющий исполнять прикладной код на языке 1С. Использование СОМ+ обеспечивало нам готовый транспорт, позволяющий клиентским приложениям общаться с сервером по сети. Очень многое в архитектуре и клиент-серверного взаимодействия, и прикладных объектов, доступных разработчику 1С, проектировалось с учетом использования СОМ+. В то время в архитектуру не было заложено отказоустойчивости, и падение сервера вызывало отключение всех клиентов. При падении серверного приложения СОМ+ поднимал его при обращении к нему первого клиента, и клиенты начинали свою работу с начала – с коннекта к серверу. В то время всех клиентов обслуживал один процесс.
1С:Предприятие 8.1
В следующей версии мы захотели:
- Обеспечить нашим клиентам отказоустойчивость, чтобы аварии и ошибки у одних пользователей не приводили авариям и ошибкам у других пользователей.
- Избавиться от технологии СОМ+. СОМ+ работала только на Windows, а в то время уже начала становиться актуальной возможность работы под Linux.
Так в версии 8.1 появился первый кластер. Мы реализовали свой протокол удаленного вызова процедур (поверх ТСР), который по внешнему виду выглядел для конечного потребителя-клиента практически как СОМ+ (т.е. нам практически не пришлось переписывать код, отвечающий за клиент-серверные вызовы). При этом сервер, реализованный нами на С++, мы сделали платформенно-независимым, способным работать и на Windows, и на Linux.
На смену монолитному серверу версии 8.0 пришло 3 вида процессов – рабочий процесс, обслуживающий клиентов, и 2 служебных процесса, поддерживающих работу кластера:
- rphost – рабочий процесс, обслуживающий клиентов и исполняющий прикладной код. В составе кластера может быть больше одного рабочего процесса, разные рабочие процессы могут исполняться на разных физических серверах – за счёт этого достигается масштабируемость.
- ragent – процесс агента сервера, запускающий все другие виды процессов, а также ведущий список кластеров, расположенных на данном сервере.
- rmngr – менеджер кластера, управляющий функционированием всего кластера (но при этом на нем не работает прикладной код).
Клиент на протяжении сессии работал с одним рабочим процессом, падение рабочего процесса означало для всех клиентов, которых этот процесс обслуживал, аварийное завершение сессии. Остальные клиенты продолжали работу.
Резервирование кластеров
Мы решили повысить отказоустойчивость кластера, прибегнув к схеме Active / passive. Появилась возможность конфигурировать два кластера – рабочий и резервный. В случае недоступности основного кластера (сетевые неполадки или, например, плановое техобслуживание) клиентские вызовы перенаправлялись на резервный кластер.
Однако эта конструкция была довольно сложна в настройке. Администратору приходилось вручную собирать две группы серверов в кластеры и конфигурировать их. Иногда администраторы допускали ошибки, устанавливая противоречащие друг другу настройки, т.к. не было централизованного механизма проверки настроек. Но, тем не менее, этот подход повышал отказоустойчивость системы.
Установка службы 1С
Далее нам необходимо установить службу 1С:Предприятие, так как при установке платформы мы этот шаг пропустили. Ее необходимо будет установить в ручном режиме. Для этого необходимо запустить командную строку от администратора и ввести команду:
Рисунок 5 - Установка службы Агент 1С: Предприятие
Теперь необходимо изменить параметры службы, чтобы подключения осуществлялись к ней через другой порт, который отличается от стандартного. А также укажем место, где будут храниться логи. Для этого необходимо:
- Зайти в реестр. Пуск->Выполнить->regedit
- Далее в реестре идем по пути HKEY_LOCAL_MACHINE->System->CurrentControlSet->Services->1C:Enterprise 8.3.16.1063 ServerAgent
- В параметре ImagePath указываем "C:\Program Files\1cv8\8.3.16.1063\bin\ragent.exe" -srvc -agent -regport 1941 -port 1940 -range 1960:1991 -d "C:\Program Files\1cv8\srvinfo_8.3.16.1063"
Рисунок 6 - Настройка подключений в реестре
Отказоустойчивость
Поскольку процесс работы стал stateless и все необходимые для работы данные хранились вне текущего соединения «клиент – рабочий процесс», в случае падения рабочего процесса клиент при следующем обращении к серверу переключался на другой, «живой» рабочий процесс. В большинстве случаев такое переключение происходило незаметно для клиента.
Настройка консоли администрирования
Замечание: для каждой версии платформы нужно регистрировать соответствующую версию консоли администрирования.
Указываем имя кластера, порт из параметров службы.
Рисунок 9 - Настройка кластера
Теперь можем перенести нужную базу на новую платформу. Чтобы перенести ее на новую платформу, базу сначала нужно удалить из старой консоли администрирования.
Далее в новой консоли правой кнопкой мыши нажимаем на «информационные базы» и выбираем создать информационную базу. Указываем параметры подключения к базе. На этом все. Обе службы 1С:Предприятие должны работать.
Добрый день, статья написана в качестве некоего продолжения данного опуса. Компания 1С довольно часто подвергается критике, нередко объективной, но я попытаюсь своим примером показать, что 1С предоставляет свободу выбора, что в нынешнее время как минимум заслуживает уважения. Также немного посчитаем деньги.
Пролог.
Основной вид деятельности нашей небольшой компании является IT аутсорсинг. Скорее в маркетингово-энтузиастских целях, мы создаем шаблоны решений, которые нам позволяют немного стандартизировать IT инфраструктуру подопечных, а клиенту получить и главное осознать экономию (если сам себя не похвалишь отчетом, то никто не заметит). Клиенты — небольшие компании от 20 до 200 человек. Одним из таких решений является реализация 1С сервера предприятий на свободной платформе Linux + Postgres SQL. В статье не будет очередной технической реализации, так как все давно разжевано и пережевано. Будет лишь сравнение стандартного предложения от 1С франчайзи и наш экономный вариант на май 2014.
Задача №1.
Осуществить переход базы с файлового режима работы на SQL-ный вариант с возможностью использования до 20 клиентов.
Расчет двух вариантов.
Мы не занимаемся сопровождением 1С, потому все рекомендации: о необходимости перехода с файловой базы на SQL, покупки лицензий, аппаратного комплекса клиент получает от сопровождающего его 1С франчайзи. Далее проходит консультация с нами, мы предлагаем альтернативное решение на связке 1С+Linux+Postgres SQL, сами же и внедряем.
Предложение на 20 пользователей.
Наименование | Стандартное предложение 1С франчайзи Windows + MSSQL (руб.) | Вариант здравомыслия Linux + Postgres SQL (руб.) |
---|---|---|
Лицензии 1С | ||
1С: Предприятие 8.3.Лицензия на сервер (x86-64) | - | 86400 |
1С: Предприятие 8.3.Лицензия на сервер (x86-64) (USB) | 103700 | - |
Клиентская лицензия на 20 рабочих мест 1С: Предприятие 8 (USB) | 97600 | - |
1С: Предприятие 8. Клиентская лицензия на 20 рабочих мест | - | 78000 |
Лицензии SQL | ||
Лицензия на сервер MS SQL Server Standard 2012 Runtime для пользователей 1С: Предприятие 8 | 13381 | 0 |
Клиентский доступ на 20 рабочих мест к MS SQL Server 2012 Runtime для 1С: Предприятие 8 | 117748 | 0 |
Итого | 332429 | 164400 |
Экономия | 168029 |
Пояснения и нюансы:
- Внедренцы 1С (во вселенной конечно же есть и другие, которые пытаются сэкономить клиенту, но нам такие не попадались) по умолчанию предлагают ключи варианта USB, они ощутимо дороже файловых лицензий. Естественно, выбор типа ключа никак не зависит от платформы реализации. Выходит в таблице сделано ухищрение в пользу Linux платформы. Все же напомню, что речь идет не о скрупулезной оценке предложений, а о свежем примере из практики. Объективности ради, должен уточнить, что на мой взгляд внедренцы склоняются в пользу USB ключей не в целях увеличить траты, а ради надежности применения и простоты дальнейшего обслуживания, «тем более» если речь идет о реализации на Linux + Postgres SQL.
- Часто, мы также для небольших компаний приобретаем ключ 1С: Предприятия x86, а не 64. При этом Postgres SQL используем 64 битный вариант, а 1С сервер предприятия 32 битный. Применение в масштабах организаций до 60 человек, считаем приемлемым, тезис субъективный.
- Не учтена стоимость работ. В нашем случае она включена в контракт обслуживания, потому для клиента равна нулю. Будем считать что внедрение и дальнейшее сопровождение, примерно одинаковы.
Осуществить переход базы с файлового режима работы на SQL-ный вариант с возможностью использования до 10 клиентов.
Предложение на 10 пользователей
Наименование | Стандартное предложение 1С франчайзи Windows + MSSQL (руб.) | Вариант здравомыслия Linux + Postgres SQL (руб.) |
---|---|---|
Лицензии 1С | ||
1С: Предприятие 8.3.Лицензия на сервер (x86-64) | - | 0 |
1С: Предприятие 8.3.Лицензия на сервер (x86-64) (USB) | 103700 | - |
Клиентская лицензия на 10 рабочих мест 1С: Предприятие 8 (USB) | 51900 | - |
1С: Предприятие 8. Клиентская лицензия на 10 рабочих мест | - | 41400 |
Лицензии SQL | ||
Лицензия на сервер MS SQL Server Standard 2012 Runtime для пользователей 1С: Предприятие 8 | 13381 | 0 |
Клиентский доступ на 10 рабочих мест к MS SQL Server 2012 Runtime для 1С: Предприятие 8 | 58874 | 0 |
Итого | 227855 | 41400 |
Экономия | 186455 |
Дополнение к нюансам из примера №1
- Добрая 1С позволяет использовать 1С сервер предприятия на Linux для 12 клиентов без ключа сервера предприятия, для Windows подобного нет. Бонус сомнительный, ведь 10 пользователей смогут и на файловой пережить, но все же приятный.
Часто, экономия в рамках нашей страны губит любые добрые системные начинания. Мне кажется, что данный случай все же из другого разряда. Три года назад когда мы вводили 1С сервер предприятия на Linux за стандарт для наших компаний, мы действительно без ложной озабоченности выслушивали от внедренцев 1С, что они снимают с себя ответственность за работоспособность поддерживаемой конфигурации на подобной не «кошерной» связке Linux + Postgres SQL, при этом вводя и клиента в состояние паники.
Возможно, в приведенные мною расчеты можно пульнуть еще с десяток критических стрел, на объективность претендовать сложно, но хотелось донести общее представление финансовой составляющей вопроса.
Часто, работодатели коллег, которые внедряют похожие решения и не догадываются о сэкономленных средствах. У нас же работает следующая схема.
Предложение от 1С франчайзи на ПО, от нас предложение на сервер. «Наш» бюджет на сервер урезают, обычно в два раза. Мы предлагаем альтернативное лицензионное решение, настаивая на том, что сэкономленные средства вернуться на аппаратную часть. Получается, что 1С лоббирует наше желание работать с серверным оборудованием.
Кластер — это разновидность параллельной
или распределённой системы, которая:
1. состоит из нескольких связанных
между собой компьютеров;
2. используется как единый,
унифицированный компьютерный ресурс
Дано: есть бизнес-приложение (например, ERP-система), с которым работают одновременно тысячи (возможно, десятки тысяч) пользователей.
- Сделать приложение масштабируемым, чтобы при увеличении количества пользователей можно было за счёт наращивания аппаратных ресурсов обеспечить необходимую производительность приложения.
- Сделать приложение устойчивым к выходу из строя компонентов системы (как программных, так и аппаратных), потере связи между компонентами и другим возможным проблемам.
- Максимально эффективно задействовать системные ресурсы и обеспечить нужную производительность приложения.
- Сделать систему простой в развертывании и администрировании.
К желаемому результату мы пришли не сразу.
В этой статье расскажем о том, какие бывают кластеры, как мы выбирали подходящий нам вид кластера и о том, как эволюционировал наш кластер от версии к версии, и какие подходы позволили нам в итоге создать систему, обслуживающую десятки тысяч одновременных пользователей.
Как писал автор эпиграфа к этой статье Грегори Пфистер в своей книге «In search of clusters», кластер был придуман не каким-либо конкретным производителем железа или софта, а клиентами, которым не хватало для работы мощностей одного компьютера или требовалось резервирование. Случилось это, по мнению Пфистера, ещё в 60-х годах прошлого века.
Традиционно различают следующие основные виды кластеров:
- Отказоустойчивые кластеры (High-availability clusters, HA, кластеры высокой доступности)
- Кластеры с балансировкой нагрузки (Load balancing clusters, LBC)
- Вычислительные кластеры (High performance computing clusters, HPC)
- Системы распределенных вычислений (grid) иногда относят к отдельному типу кластеров, который может состоять из территориально разнесенных серверов с отличающимися операционными системами и аппаратной конфигурацией. В случае grid-вычислений взаимодействия между узлами происходят значительно реже, чем в вычислительных кластерах. В grid-системах могут быть объединены HPC-кластеры, обычные рабочие станции и другие устройства.
Для тех, кто не в курсе, коротко расскажу, как устроены бизнес-приложения 1С. Это приложения, написанные на предметно-ориентированном языке, «заточенном» под автоматизацию учётных бизнес-задач. Для выполнения приложений, написанных на этом языке, на компьютере должен быть установлен рантайм платформы 1С:Предприятия.
Балансировка нагрузки
Это стандартная задача для кластера с балансировкой нагрузки. Есть несколько типовых алгоритмов её решения, например:
-
– серверам присваиваются порядковые номера, первый запрос отправляется на первый сервер, второй запрос – на второй и т. д. до достижения последнего сервера. Следующий запрос направляется на первый сервер и всё начинается с начала. Алгоритм прост в реализации, не требует связи между серверами и неплохо подходит для «легковесных» запросов. Но при балансировке по этому алгоритму не учитывается производительность серверов (которая может быть разной) и текущая загруженность серверов. – усовершенствованный Round-Robin: каждому серверу присваивается весовой коэффициент в соответствии с его производительностью, и сервера с бо́льшим весом обрабатывают больше запросов.
- Least Connections: новый запрос передается на сервер, обрабатывающий в данный момент наименьшее количество запросов.
- Least Response Time: сервер выбирается на основе времени его ответа: новый запрос отдаётся серверу, ответившему быстрее других серверов.
Запрос от нового клиента адресуется на наиболее производительный на данный момент сервер.
Запрос от существующего клиента в большинстве случаев адресуется на тот сервер и в тот рабочий процесс, в который адресовался его предыдущий запрос. С работающим клиентом связан обширный набор данных на сервере, передавать его между процессами (а тем более между серверами) – довольно накладно (хотя мы умеем делать и это).
Запрос от существующего клиента передается в другой рабочий процесс в двух случаях:
- Процесса больше нет: рабочий процесс, с которым ранее взаимодействовал клиент, более недоступен (упал процесс, стал недоступен сервер и т.п.).
- Есть более производительный сервер: если в кластере есть сервер, отличающийся по производительности в два и более раза по сравнению с сервером, где запушен текущий рабочий процесс, то платформа считает, что даже ценой миграции клиентского контекста нам выгоднее выполнять запросы на более производительном сервере. Переноситься клиенты с одного сервера на другой будут постепенно, по одному, с периодической оценкой результата – что в плане производительности стало с серверами после переноса каждого из клиентских процессов. Цель этой процедуры – выравнивание производительности серверов в кластере (т.е. равномерная загрузка серверов).
1С:Предприятие 8.3
В версии 8.3 мы существенно переписали код серверной части, отвечающий за отказоустойчивость. Мы решили отказаться от схемы Active / passive кластеров ввиду сложности её конфигурирования. В системе остался только один отказоустойчивый кластер, состоящий из любого количества серверов – это ближе к схеме на Active / active, в которой запросы на отказавший узел распределяются между оставшимися рабочими узлами. За счет этого кластер стал проще в настройке. Ряд операций, повышающих отказоустойчивость и улучшающих балансировку нагрузки, стали автоматизированными. Из важных нововведений:
- Новая настройка кластера «Уровень отказоустойчивости»: число, указывающее, сколько серверов может выйти из строя без последствий в виде аварийного завершения сеансов подключенных пользователей. Исходя из этой настройки кластер будет тратить определённый объём ресурсов на синхронизацию данных между рабочими серверами, чтобы иметь всю необходимую для продолжения работы клиентов информацию на «живых» серверах в случае выхода из строя одного или нескольких серверов.
- Количество рабочих процессов не задается вручную, как раньше, а автоматически рассчитывается исходя из описаний требований задач по отказоустойчивости и надежности.
- Появился ряд настроек, связанных с максимальными объемами памяти, которые разрешается потреблять рабочим процессам, а также настройки, определяющие что делать, если эти объемы превышены:
Главная идея этих наработок – упростить работу администратора, позволяя ему настраивать кластер в привычных ему терминах, на уровне оперирования серверами, не опускаясь ниже, а также минимизировать уровень «ручного управления» работой кластера, дав кластеру механизмы для решения большинства рабочих задач и возможных проблем «на автопилоте».
Установка платформы 1С:Предприятие
Устанавливаем платформу той же версии, что и сервер - в данном случае 8.3.16.1063 со следующими параметрами:
Рисунок 3 - Установка платформы 1С
Тюнинг терминального сервера
Ограничение сессий
По умолчанию, пользователи удаленных рабочих столов могут находиться в системе в активном состоянии без ограничения. Это может привести к зависаниям или проблемам при повторном подключении. Для решения возможных проблем установите ограничения на терминальные сессии.
Открываем диспетчер серверов и кликаем по Службы удаленных рабочих столов
Выбираем ранее созданную коллекцию сеансов, далее в разделе Свойства открываем меню Задачи > изменить свойства
В открывшемся окне в разделе Сеанс устанавливаем ограничения, их следует выбирать опираясь на особенности работы сотрудников для которых выполняется настройка сервера
Настройка хранения кэша 1С
Теперь нужно решить, где будет храниться кэш сервера 1С. По умолчанию он хранится в каталоге C:\Program Files\1cv8\srvinfo. Этот каталог мы трогать не будем, так как там уже хранится кэш работающего сервера, поэтому создадим каталог C:\Program Files\1cv8\srvinfo_8.3.16.1063.
Рисунок 4 - Перенос каталога кэша 1С
Три звена отказоустойчивости
Как известно, даже если компоненты системы по отдельности надёжны, проблемы могут возникнуть там, где компоненты системы вызывают друг друга. Мы хотели свести количество мест, критичных для работоспособности системы, к минимуму. Важным дополнительным соображением была минимизация переделок прикладных механизмов в платформе и исключение изменений в прикладных решениях. В версии 8.3 появилось 3 звена обеспечения отказоустойчивости «на стыках»:
Диски профилей пользователей + миграция профилей
Одной из задач при настройке терминального сервера является организация хранения данных пользователей работающих на нем.
1-й способ
Во многих компаниях используется миграция профилей пользователей. Это дает возможность перенести место хранения данных на специально выделенное место для данных задач. данный способ позволяет перемещать все персональные каталоги пользователя (Документы, Загрузки, Рабочий стол и др.)
Но не позволяет перемещать
Данные о профиле
В результате чего, в процессе работы терминального сервера происходит "захламление" реестра сервера, и крайне осложняет перенос конфигурации пользователя.
2-й способ
Использовать Диски профилей пользователя
Данная технология является крайне полезной для обеспечения более высокого уровня безопасности , так же позволяет легко, бесследно удалять старые профили пользователей, и переносить в случае необходимости настройки на другой терминальный сервер, так как все данные пользователя хранятся на отдельном VHDX Диске для каждого пользователя.
Проблемой данного метода является сложность изменения размера дискового пространства выделенного пользователю, и вносит изменение в конфигурацию оборудования сервера, что вызывает проблемы с лицензиями 1С, но об это будет дальше.
3-й способ
Скомбинировать лучшее из первых 2х методов. а именно.
Активируем Диски профилей пользователя, но данные каталогов пользователя перемещаем на файловый сервер.
Для активации дисков профилей пользователя необходимо перейти в Службы удаленных рабочих столов > в разделе Свойства открываем меню Задачи > изменить свойства > Диски профилей пользователя.
Открываем папку с файлами установки сервера «1С:Предприятие» и нажимаем на файл setup.exe.
Запуститься помощник установки «1С:Предприятия». Нажимаем «Далее».
На следующей странице требуется выбрать те компоненты, которые будут установлены:
- «Сервер 1С:Предприятие» - компоненты сервера «1С:Предприятие»
- «Администрирование сервера 1С:Предприятия» — дополнительные компоненты для администрирования серверов «1С:Предприятия»
Сделав выбор, нажимаем «Далее».
Определяем язык интерфейса, который будет использоваться по умолчанию, и нажмем «Далее».
Если сервер «1С:Предприятие» устанавливается как служба Windows (а так в большинстве случаев и следует его устанавливать) - рекомендуем сразу создать отдельного пользователя, из-под которого будет запускаться эта служба.
Также данному пользователю обязательно следует дать необходимые права на каталог служебных файлов сервера (по умолчанию C:\Program Files\1cv8\srvinfo для 64-х разрядного и C:\Program Files (x86)\1cv8\srvinfo для 32-х разрядного сервера).
Созданный автоматически пользователь USR1CV8 будет обладать всеми перечисленными правами.
Заполнив соответствующие параметры, жмем «Далее».
Нажимаем «Установить» для того чтобы начать установку. При этом будет произведено копирование файлов выбранных компонент, создание конфигурационных файлов, регистрация компонентов программы, создание ярлыков, а также запуск службы сервера «1С:Предприятия».
По завершении установки помощник предложит установить драйвер защиты — HASP Device Driver. Если используется программная лицензия на сервер «1С:Предприятия», производить установку драйвера нет необходимости. Оставляем или снимаем флаг «Установить драйвер защиты» и жмем «Далее».
Если установка завершена успешно, откроется последняя страница помощника установки. Нажимаем «Готово» для завершения работы мастера.
На рисунке ниже изображены основные компоненты необходимые для базовой установки сервера.
При первой установке в следующем окне ничего менять не нужно.
Для выбранных компонент экземпляра необходимо создать пользователей с административными правами для запуска этих компонентов в качестве службы.
На следующем этапе необходимо указать смешанный режим проверки подлинности и указать пароль пользователя sa, а также добавить пользователя Windows, которые будет иметь право администрировать СУБД.
На вкладке «Каталоги данных» необходимо указать дефолтное размещение пользовательских баз данных, а также указать каталоги системных баз данных. Для повышения производительности SQL Server желательно разносить функционально разные базы данных. Так на отдельные физические диски необходимо разносить пользовательские данные, журнал пользовательских баз данных, базу данных temp и ее журнал. Также возможно указать дефолтный каталог для хранения резервных копий баз данных.
Если все сделано правильно, остается прощелкать кнопку «Далее» и дождаться установки SQL Server.
3.1. Включаем режим Shared memory.
«Shared Memory» включится только на платформе начиная с 1С 8.2.17, на более ранних релизах включится «Named Pipe» – несколько уступающий в скорости работы. Актуально, если службы 1С и MS SQL установлены на одном физическом или виртуальном сервере.
3.2. Настройка кластера 1С:Предприятие.
Настройки кластера 1С отвечают за параметры всех серверов 1С, принадлежащих кластеру. Кластер подразумевает работу нескольких физических или виртуальных серверов, работающих с одними и теми же информационными базами.
- Интервал перезапуска – отвечает за частоту перезапуска рабочих процессов кластера. Автоматический перезапуск был разработан в платформе «для минимизации отрицательных последствий фрагментации и утечки памяти в рабочих процессах». Однако, автоматический перезапуск может приводить к разрыву соединений в активных сессиях, поэтому в некоторых случаях предпочтительнее регламентные операции по перезапуску процессов 1С и очистке серверного кэша проводить вручную, либо с помощью скрипта.
- Допустимый объем памяти – защищает сервера 1С от перерасхода памяти. При превышении процессом этого объема в интервале превышения допустимого объема, процесс перезапускается. По сути – это максимальный размер ОЗУ, занимаемый процессами «rphost» в периоды пиковой нагрузки серверов. Рекомендуется установить небольшой порог превышения допустимого объема.
- Допустимое отклонение количества ошибок сервера. Платформа рассчитывает среднее количество ошибок сервера по отношению к числу обращений к серверу в течение 5 минут. Если это отношение превысит допустимое, то рабочий процесс считается «проблемным», и может быть завершен системой, если установлен флаг «Принудительно завершать проблемные процессы».
- Выключенные процессы останавливать через « ». При превышении допустимого объема памяти, рабочий процесс не завершается сразу, а становится «выключенным», чтобы было время «перенести» рабочие данные без потери на новый запущенный рабочий процесс. Если указан этот параметр, то «выключенный» процесс в любом случае завершится по истечении этого времени. Если наблюдаются «зависшие» рабочие процессы в работе сервера 1С, то рекомендуем рассмотреть использование данного параметра путем установки таймера на 3-5 минут.
3.3. Настройка сервера 1С:Предприятие.
Эти настройки устанавливаются для каждого сервера 1С персонально.
- Максимальный объем памяти рабочих процессов – это объем совокупной памяти, которую могут занимать рабочие процессы (rphost) на текущем кластере.
- Если параметр установлен в «0», то процесс может потреблять до 80% ОЗУ сервера.
- Если «1» - без ограничений.
- Если параметр установлен в «0», то объем безопасного расхода ОЗУ будет равен 5 % от «Максимального объема памяти рабочих процессов».
- «1» - без ограничения, что крайне не рекомендуется. В большинстве случаев этот параметр лучше оставлять «0».
4.1. Настройка SQL сервера.
- Включаем Shared memory (показано на картинке). Актуально если службы 1С и MSSQL установлены на одном физическом или виртуальном сервере.
Проверить можно, выполнив запрос:
- Устанавливаем максимально отведенное серверу количество памяти.
- Устанавливаем сжатие БД при резервном копировании и дефолтные места для хранения файлов БД
4.2. Настройка Базы данных.
После того, как сервер СУБД оптимизирован – переходим к настройкам баз.
- Рекомендуется указать автоувеличение размера
- Размещение файлов данных на разных дисках высокой производительности.
- Установка простой модели восстановления пользовательских баз для избегания разрастания файла журнала транзакций.
4.3. Настройка регламентных заданий.
Мы также готовы оказать помощь в установке и настройке сервера 1С, оптимизации.
Альтернативным вариантом является аренда готового сервера 1С, где уже произведены все настройки и включено обслуживание.
Иногда возникает проблема, что для одной конфигурации базы 1С требуется другая версия платформы 1С:Предприятие, отличная от той, которая установлена на сервере. Поэтому чтобы не трогать другие базы, можно установить два сервера 1С:Предприятие на одном сервере Windows. В нашем примере на сервере установлено 1С:Предприятие версии 8.3.15.1830, нам нужно установить дополнительно новую версию:
- Скачиваем новую платформу и сервер. Необходимо скачать «Сервер 1С:Предприятие (64-bit) для Windows» и «Технологическая платформа 1С:Предприятие для Windows»
- Распаковываем скачанные архивы в отдельные каталоги.
Теперь начнем установку скачанных файлов.
Тюнинг терминального сервера
Ограничение сессий
По умолчанию, пользователи удаленных рабочих столов могут находиться в системе в активном состоянии без ограничения. Это может привести к зависаниям или проблемам при повторном подключении. Для решения возможных проблем установите ограничения на терминальные сессии.
Открываем диспетчер серверов и кликаем по Службы удаленных рабочих столов
Выбираем ранее созданную коллекцию сеансов, далее в разделе Свойства открываем меню Задачи > изменить свойства
В открывшемся окне в разделе Сеанс устанавливаем ограничения, их следует выбирать опираясь на особенности работы сотрудников для которых выполняется настройка сервера
Настройка службы агента 1С
Теперь необходимо настроить новую службу Агент 1С:Предприятие 8.3.16.1063. Нужно указать от какого пользователя будет запускаться наша служба.
Рисунок 7 - Запуск службы
Далее выставляем тип запуска «автоматически» и запускаем службу.
Рисунок 8 - Запуск службы в автоматическом режиме
Если все сделано правильно, то служба запустится. Далее необходимо настроить консоль администрирования.
Читайте также: