1С администрирование серверов 1с предприятия: Консоль администрирования сервера 1С 8.3
Консоль администрирования сервера 1С 8.3
Как многим наверное известно, система 1С Предприятие поддерживает два варианта работы. Это:
- клиент–сервер;
- файловый вариант работы.
Для клиент-серверного режима необходимо установить Сервер 1С: Предприятия.
В данной статье рассмотрим, как администрировать этот сервер с помощью утилиты Консоль администрирования серверов 1С 8.3 (8.2).
Сразу сервисное отступление — если при запуске консоль выдает сообщение «Различаются версии клиента и сервера (8.3.х.х-8.3.х.х), клиентское приложение: Консоль кластера», Вам необходимо пройти регистрацию с помощью соответствующего ярлыка из меню «Пуск»:
Консоль администрирования серверов 1C Предприятия
У сервера 1С нет собственного интерфейса для управления. Администрирование ведется при помощи консоли серверов 1С. Консоль входит в поставку 1С Платформы и устанавливается локально на компьютер пользователя. Сами Информационные базы могут размещаться как локально, так и на удаленных компьютерах или серверах.
Создание, редактирование и удаление баз на Сервере 1С
Если вы только начинаете программировать в 1С или просто хотите систематизировать свои знания — попробуйте Школу программирования 1С нашего друга Владимира Милькина. Пошаговые и понятные уроки даже для новичка с поддержкой учителя.
Попробуйте бесплатно по ссылке >>
Чтобы создать информационную базу на Сервере 1С, необходимо сначала создать Центральный сервер и Кластер, к которому будет принадлежать база. На строке 1C:Enterprise 8.3 Central Servers нужно «кликнуть» правой кнопкой мыши и выбрать в контекстном меню пункт «Создать». В открывшемся окне вводим имя сервера и номер порта.
Теперь создадим Кластер. Также воспользуемся контекстным меню и выберем пункт «Создать». Заполним параметры кластера.
В ветке «Информационные базы» с помощью контекстного меню добавляем новую базу. После заполнения ее параметров нажимаем «Ок». Информационная база готова к работе.
С помощью контекстного меню базу можно удалить или отредактировать свойства.
Действия в консоли
Чем может быть полезна нам консоль администрирования? Часто случается так, что у пользователя «зависает» компьютер, и при этом программа 1С у конкретного пользователя не запускается. Выходит сообщение, что под данным пользователем уже кто-то работает. Все дело в том, что на сервере 1С остаются «нерабочие» сеансы. Эти пользователи даже остаются в разделе «Активные пользователи». И когда в программе нужно сделать операции, требующие монопольного режима (например, удаление помеченных на удаление объектов), то если попросить всех пользователей выйти, операцию все равно не всегда получается осуществить.
В консоли администрирования очень удобно посмотреть такие «зависшие» сеансы и скинуть их.
В контекстном мену строки с сеансом можно выбрать три пункта: «Удалить», «Свойства» и «Справка».
Также из консоли можно управлять блокировками.
К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.
Установка сервера администрирование кластера серверов 1С:Предприятия
В данной статье познакомимся с сервером администрирования кластера серверов, а конкретно с утилитами rac.exe и ras.exe, а также программы deployka с помощью которых становится возможным администрирование кластера серверов 1С:Предприятие из командной строки.
По традиции, всем кому лень читать, предлагаю посмотреть вебинар на указанную тему
Ну а остальным добро пожаловать под кат:
0. Оглавление
- Общие сведения
- Установка компонент сервера администрирования
- Запуск сервера администрирования
- Запуск сервера администрирования в качестве службы Windows
- Администрирование кластера серверов с помощью утилиты rac.exe
- Программные обертки для работы с сервером администрирования
- Установка и настройка с программы deployka
1. Общие сведения
Управлять кластером серверов 1С:Предприятие версии 8.3 возможно как с помощью консоли администрирования серверов 1С, так и из командной строки. Для этих целей служит Сервер администрирования кластера серверов, который состоит из двух утилит: непосредственно самого сервера — программы rac.exe и утилиты командной строки rac.exe, которая обращаясь к запущенному прежде серверу ras позволяет выполнять различные операции с кластером серверов 1С:Предприятия.
Подробно про данный механизм можно прочитать в поставляемой вместе с платформой книге «Руководство администратора. Клиент-серверный вариант» (или, соответственно, на сайте ИТС).
А общая схема работы данной связки выглядит следующим образом:
Сервер администрирования должен быть той же версии, что и версия кластера серверов 1С:Предприятия, причем одновременно к одному кластеру серверов могут быть подключены несколько серверов администрирования, но конкретный сервер администрирования может взаимодействовать только с одним агентом сервера.
И сервер администрирования и утилита командной строки могут работать в любой поддерживаемой платформой 1С:Предприятия ОС. Но в данной статье мы ограничимся только ОС семейства Windows.
2. Установка компонент сервера администрирования
И сам сервер и утилита администрирования входят в состав компонент сервера 1С:Предприятия. Соответственно, на компьютере с запущенной службой агента сервера 1С:Предприятия они уже должны быть установлены по умолчанию.
Чтобы убедиться в этом, достаточно перейти в каталог с файлами сервера 1С:Предприятия и найти в нем соответствующие утилиты (для удобства файлы можно сгруппировать по типу).
Подробно про установку сервера 1С:Предприятия я писал здесь.
Для установки сервера администрирования на компьютере, где ранее не был установлен сервер 1С:Предприятия, необходимо запустить дистрибутив установки сервера 1С и в составе компонент выбрать пункт «Сервер 1С:Предприятия 8».
Причем, при выбранной данной компоненте на следующем шаге мастер установки предложит установить сервер 1С:Предприятия как службу Windows. От этого пункта конечно же следует отказаться сняв соответствующий флаг.
После установки необходимо убедиться в наличии всех необходимых компонент описанным выше способом.
3. Запуск сервера администрирования
Для получения подробной информации по утилите ras.exe можно вызвать справку выполнив команду
ras help
Из справки видно, что сервер администрирования может работать как в режиме приложения, так и как служба Windows (параметр service ). Также с мы можем задать сетевой порт, на котором будет работать сервер администрирования (параметр port, по умолчанию используется порт 1545), а для режима администрирования кластера используется режим claster. Вызвать справку к данному режиму можно командой:
rac help cluster
После чего увидим, что у данного режима в качестве аргумента указывается адрес агента кластера серверов 1С:Предприятия. По умолчанию это localhost:1540.
Таким образом, если сервер администрирования запускается на той же машине, где запущен и агент сервера 1С:Предприятия, достаточно выполнить команду
rac cluster
Ну а если необходимо подключиться к агенту сервера, запущенном, например, на компьютере с сетевым именем Server1C, причем агент работает на нестандартном порту 2540, то команда будет следующей:
rac cluster server1c:2540
4. Запуск сервера администрирования в качестве службы Windows
Конечно же, чтобы не запускать сервер администрирования каждый раз руками, удобно запустить его единожды в качестве службы Windows. Но, к сожалению, разработчики платформы не реализовали возможность автоматической регистрации соответствующей службы в системе, как, например, это сделано для агента сервера 1С. Для добавления службы предлагается воспользоваться системной утилитой sc. Давайте рассмотрим этот процесс чуть более детально.
Для начала, я рекомендую для создаваемой службы создать отдельного пользователя Windows. Подробно как это сделать я описывал здесь.
Пусть это будет локальный пользователь с именем USR1CV8_RAS и паролем Pass123
Далее, необходимо создать и выполнить bat-файл, который будет регистрировать соответствующую службу. Содержания файла следующее:
Файл register-ras.bat:
@echo off rem %1 - полный номер версии 1С:Предприятия set SrvUserName=.\USR1CV8_RAS set SrvUserPwd="Pass123" set CtrlPort=1540 set AgentName=localhost set RASPort=1545 set SrvcName="1C:Enterprise 8.3 Remote Server" set BinPath="\"C:\Program Files\1cv8\%1\bin\ras.exe\" cluster --service --port=%RASPort% %AgentName%:%CtrlPort%" set Desctiption="1C:Enterprise 8.3 Remote Server" sc stop %SrvcName% sc delete %SrvcName% sc create %SrvcName% binPath= %BinPath% start= auto obj= %SrvUserName% password= %SrvUserPwd% displayname= %Desctiption%
В файле указываем:
- имя пользователя и пароль из под которого будет запускаться служба — переменные SrvUserName и SrvUserPwd
- адрес и порт агента сервера, который мы собираемся администрировать — переменные AgentName и CtrlPort
- А также имя службы и сетевой порт на котором будет работать сервер администрирования — переменные RASPort и SrvcName. Имеет смысл менять эти параметры только если вы хотите запустить параллельно несколько серверов администрирования, например для обслуживания разных серверов 1С.
В качестве единственного параметра bat-файла выступает текущая версия платформы 1С:Предприятия. Таким образом, для создания службы запускаем командную строку с правами администратора и запускаем созданный ранее файл register-ras.bat, не забыв указать нужную версию платформы.
Проверяем, что в системе появилась служба с указанным именем. И сразу запускаем ее, выбрав соответствующий пункт в контекстном меню.
На этом установка сервера администрирования в качестве службы завершена.
5. Администрирование кластера серверов с помощью утилиты rac.exe
Итак, сервер администрирования мы установили. Взаимодействием с сервером осуществляется с помощью специальной консольной утилиты rac.exe. Выполним команду
rac help
чтобы получить справку данной программы.
Как видно из справки, утилита имеет один общий аргумент, задающий адрес сервера администрирования (по умолчанию localhost:1545) и множество режимов работы: для администрирования агента кластера серверов, самого кластера, менеджера кластера, рабочих процессов и т. д. Справку по каждому режиму можно вызвать соответствующей командой.
Описывать все режимы работы, очевидно, нет никакого смысла. Приведу лишь несколько примеров работы.
Получение списка информации о кластерах:
Получение списка информационных баз на заданном кластере серверов:
Получение списка соединений с указанной информационной базой:
Утилита администрирования позволяет выполнить весь объем работ, необходимый для администрирования кластера серверов, за исключением аутентификация ОС для администраторов кластера серверов, рабочего сервера и информационной базы.
6. Программные обертки для работы с сервером администрирования
Как видно из примеров, работать из командной строки с утилитой rac то еще удовольствие. Но данный механизм и не создавался для ручного управления. Например, на сайте ИТС есть Java-архивов, который позволяет взаимодействовать с сервером администрирования из программы на языке Java, без помощи консольной утилиты администрирования. Скачать данный пакет можно здесь.
Главное, мы имеем возможность выполнять различные инструкции на кластере серверов 1С из командной строки. А это значит, что можно добавлять необходимые функции по взаимодействию с кластером серверов 1С:Предприятия в различные программы, обработки или же скрипты.
Например, среди прочего, работать с сервером администрирования может написанная на языке OneScript программа deployka.
О скиптовом движке OneScript я уже рассказывал здесь.
О программе deployka можно подробнее узнать здесь.
Ну а максимально полный обзор всех имеющихся библиотек и приложений написанных на OneScript приведен в этой статье.
7. Установка и настройка с программой deployka
Алгоритм установки OneScript и deployka довольно подробно разобран в статьях по указанным в предыдущем пункте ссылкам. Ну а если коротко, он состоит из следующих пунктов:
1. Скачиваем дистрибутив OneScript с официального сайта.
2. Устанавливаем, следуя инструкциям мастера.
3. Перелогиниваемся в системе, чтобы применились новые переменные среды.
4. Запускаем командную строку с правами администратора, проверяем, что предыдущие пункты выполнены корректно командной
oscript -help
5. Устанавливаем программу deployka с помощью пакетного менеджера opm, выполнив команду
opm install deployka
6. Проверяем, что все работает, вызвав справку «деплойки» командой
deployka help
7. Вот в общем то и все. Все режимы работы программы видны на экране. Далее читаем справку на сайте или в консоли, вызывав подсказку для каждого режима соответствующей командой:
Вот так, например, можно завершить все сеансы в указанной информационной базе с последующей установкой блокировки начала сеансов.
deployka session kill -db Accounting_Demo -rac "C:\Program Files\1cv8\8.3.11.2867\bin\rac.exe" -db-user "АбрамовГС (директор)"
8. Теперь можно использовать «деплойку» в своих скриптах. Например скрипт обновления информационной базы из хранилища, с отключением пользователей и обновлением базы данных может выглядеть так:
@echo on rem Устанавливаем значения переменных set ServerName="1CAPP:2541" set RacPath="C:\Program Files\1cv8\8.3.11.2954\bin\rac.exe" set uccode="123" set BaseName="ERP_Test" set UserName="Admin" set UserPass="Pass123" set ConStr="/1CAPP:2541\ERP_Test" set RepoPath="tcp://1CAPP/ERP_DEV" set RepoUserName="test" set RepoUserPass="123" rem Завершаем работу пользователей call deployka session kill -db %BaseName% -db-user %UserName% -db-pwd %UserPass% -rac %RacPath% -lockuccode %uccode% rem Обновляем конфигурацию базы из хранилища call deployka loadrepo %ConStr% %RepoPath% -db-user %UserName% -db-pwd %UserPass% -storage-user %RepoUserName% -storage-pwd %RepoUserPass% -uccode %uccode% rem Обновляем конфигурацию базы данных call deployka dbupdate %ConStr% -db-user %UserName% -db-pwd %UserPass% -uccode %uccode% rem Снимаем блокировку сеансов call deployka session unlock -db %BaseName% -db-user %UserName% -db-pwd %UserPass% -rac %RacPath% -lockuccode %uccode%
Всем спасибо, кто дочитал до конца. Пишите, если у вас остались вопросы.
Смотрите также:
- Конфигурация сервера (серверов) для работы в 1С:ERP
Каким должны быть сервера (или сервер) для комфортной работы пользователей в системе 1С:ERP? Давайте попробуем разобраться вместе. В нашей компании начинается новый проект внедрения 1С:ERP в…
- Установка системы 1С:Предприятие 7.7 в Windows x64
Установка платформы 1С:Предприятие 7.7 на 64-х битную операционную систему сопряжена с некоторыми трудностями. Дело в том, что установить 1С через обычный установщик не получится, даже если запускать программу в режиме…
- Установка веб-сервера IIS 8 в Windows 8
IIS (Internet Information Services) – один из немногих штатных инструментов Windows, которым можно пользоваться, не ища более приемлемых альтернатив от других разработчиков. Веб-сервер IIS с поддержкой языка PHP можно использовать…
Администрирование 1С для самых маленьких. Часть первая — разделяй и властвуй
Дисклеймер
В этой статье выражено личное мнение автора, его видение мира, его путь, и это все не претендует на абсолютную верность и объективность. Автор не несет никакой ответственности за последствия использования данной информации, он только надеется что эта информация поможет сделать кому-то жизнь проще.
Предисловие
Сначала я просто хотел написать небольшую статью о том, как мы разносили базы по службам, но в ходе углубления в этот процесс мы добавляли всякие разные штуки (мониторинг служб, потом мониторинг пользователей внутри 1С, потом прикрутили заббикс, и, наконец, пришли к CI/CD на базе 1С). В итоге я понимаю что пихать это в одну статью будет слишком — решил разделить на несколько. Ну а название навеяно циклом статей «сети для самых маленьких», которые принесли мне много приятных минут и к которым я отсылаю всех, кто «хочет изучить сети». Итак, мы приступаем!
Когда ты признаешь проблему, значит ты на половину уже вылечился (с) один знакомый психиатр
В этой статье я хочу поделиться своим опытом администрирования большого числа 1С в корпоративном секторе. Базы все разные, есть разработка, есть тестовые, все как у всех. Но их просто достаточно много. И все было хорошо, но в определенный момент проводить какие-то админские работы стало крайне тяжело и рискованно.
Какие у нас были сложности:
- Подвисшая база тянула за собой перезапуск службы, а значит страдали невинные (пользователи других баз)
- Было тяжело понять кто сегодня «герой дня» — какая база заняла все ресурсы
- Обновление релизов — обновление одной тянуло за собой автоматическое обновление всех баз на этой службе
- Ручное подключение баз пользователям, ручное изменение в случае переездов
- Мониторинг
И только сейчас я понимаю что это была только вершина айсберга…
Акт первый, действие нулевое
Небольшое отвлечение на основные постулаты, осознание которых далось большой кровью и болью.
- Старые версии 1С (до 8.3.11+) имеют просадку по производительности при работе в виртуализированной среде. (Источник — Гилев и собственные тесты)
- Кластер есть, но с ним все крайне не просто. Возможно его доработают потом, но пока он в основном для галочки. (источник — собственный опыт)
- При выборе процессора смотрите только на частоту. Процессор в 6 ядер по 3,4Ггц порвет в куски процессор на 20 ядер по 2Ггц. Проблема в том, что 1С вообще ничего не знает про параллельные вычисления. По сути это работает так — у нас есть определенное число воркеров для каждой службы, их раскидывают по процессорам, и если в каком то воркере пользователь запустил какой-то тяжелый отчет то в системе будет загружено только одно ядро процессора. Именно то, на котором работает воркер с запущенным заданием… Для БД ситуация кстати ровно обратная. (источник — Гилев, собственный опыт, опыт коллег)
- Не используйте логи в «новом» формате (запись в SQLLite) — вы очень быстро столкнетесь с тем, что производительность этого решения еще хуже чем файлового варианта. (Источник — собственный опыт, опыт коллег).
По подсказкам из комментариев есть вариант вынести логи на отдельный инстанс.
В 8.3.12 обещали логи в нормальный скуль!!! - 1С оооочень не любит IPv6. На всех серверах с 1С лучше сразу понижать приоритет IPv6 до минимума. (Источник — Гилев, собственный опыт)
- Используйте для виртуальных серверов виртуальные сетевые карточки E1000. С остальными проблема по производительности (Источник — Гилев, но на собственном опыте не подтвердилось, хотя особо и не тестили)
- Обслуживание баз дает хороший прирост производительности, особенно периодический пересчет итогов, а так же обслуживание индексов SQL (Источник — собственный опыт, Гилев)
- Поиск причин падения 1С сродни поеданию неочищенного кактуса. Выяснить что-то толком можно только через боль, унижения и страдания. (Источник — собственный опыт)
- Нет ни одного официального образа ни под один гипервизор. Про докер я вообще молчу. (Источник — сайт 1С)
- Программная лицензия для сервера привязывается к — сюрприз, сюрприз — серийному номеру процессора (и еще огромному количеству параметров сервера). В эпоху повсеместной виртуализации ход потрясающий. Поясняю — активировали сервер, переехали на другую ноду, перезагрузили машину — 1С не запуститься. Расчехляйте новый активационный код. (Источник — собственный опыт, болтливая техническая поддержка 1С =))
- 1С — это учетная система, а не отчетная. Хотите много нормальных жирных отчетов и быстро — выводите это за рамки 1С. (Источник — собственный опыт)
- У 1С есть два неоспоримых достоинства, за счет которых она будет процветать еще долго:
- стоимость самого продукта/разработчиков
- скорость разработки
и к сожалению для российского бизнеса они являются первоочередными. А зачастую и единственными, на что вообще смотрят. (Источник — печальная реальность)
- Никогда не используйте файловую шару как место под хранилище конфигураций 1С. Только службу. Иначе маты со стороны разработки о упавшем черт знает когда хранилище станут вашим неизменным спутником по жизни. (Источник — собственный опыт, опыт коллег)
Акт первый, действие первое
Первая короткая сценка из корпоративной жизни
На сцене — Админ (А), программист 1С (П1С) и представитель бизнеса (ПБ)
ПБ — У нас медленно работает программа!
А — у меня в системе все хорошо!
П1С — я все написал правильно, у меня на компьютере все работает быстро!
ПБ (робко и растерянно) — но она же долго…
А и П1С хором — у нас все хорошо, проблема на вашей стороне!
Проблемы всегда случаются не вовремя (с) (5-летний философ)
И вот в одно прекрасное солнечное утро (на самом деле это была глубокая зимняя ночь) мы поняли что завтра надо запустить новую базу. Завтра наступал тот прекрасный день, который уже много раз описывался тысячами авторов и имя ему — легион! Тьфу, простите, занесло. Имя этому дню был дедлайн. Час ночи, завтра на 200 компах должна запуститься новая база.» Да не проблема, у нас же все компы в домене! Сейчас быстренько сделаем логин-скрипт и дело в шляпе!» подумаете вы. И будуте правы — так же подумали и мы. И сделали. Только, как обычно это бывает, погорели на мелочи — я в логон-скрипте я прописал %filename%.bat а коллега выложил %filename%.cmd.
Ну и понятное дело с утра хелпдеск побежал делать все руками, а мне было очень стыдно за такой тупой фейл. Извинялся перед парнями тортиком.
Но мысль автоматизации этого процесса у меня в голове засела очень крепко и стал даже вырисовываться план внедрения.
В итоге мы пришли к следующей идеологии:
- Все раздается через AD — создаются группы вида 1cbases-%версия платформы%-%имя базы% и туда силами хелпдеста добавляются пользователи, которым нужна база.
- одна группа — одна база
- 1cbases — это префикс по которому удобно искать группы
- версия платформы 81, 82 и 83 (релиз не принципиален)
- название базы соответствует имени файла с настройками
- выделяется общая файловая шара где выкладываются все файлы с настройкой подключения к базам (одна база — один файл)
- при блокировании компьютера вызывается скрипт, который считывает группы пользователя и на их основании добавляет пользователям нужные базы 1С
Как мы это делали:
- Через групповые политики добавляется новое задание в планировщик (задача планировщика прописать пользователю путь к файлу подключения базы):
- запускать от имени пользователя
- событие — разблокировка компьютера
- действие — запуск нашего скрипта
- Создаем нужные группы в АД и заполняем их пользователями
- Создаем нужные файлы для запуска самих 1С. Тут остановлюсь чуть поподробнее. Изначально мы долго мучили интернет своими запросами и нашли полное описание структуры файлов *.v8i. Но потом нашелся способ проще и гениальнее.
- запускаем 1С
- настраиваем подключение к базе
- проверяем что все работает
- кликаем правой клавишей по названию базы и выбираем пункт — «Сохранить ссылку в файл»
Код скрипта:
#Первым шагом создаем место для логов
if (Test-Path "$env:HOMEDRIVE\!script_report\add_1c_bases_report.txt")
{
Remove-Item "$env:HOMEDRIVE\!script_report\add_1c_bases_report.txt" -Force -ErrorAction SilentlyContinue;
}
New-Item "$env:HOMEDRIVE\!script_report\add_1c_bases_report.txt" -ItemType file -Force -ErrorAction SilentlyContinue;
Add-Content -Value ("Дата последнего запуска: " + (Get-Date -Format F)) -Path "$env:HOMEDRIVE\!script_report\add_1c_bases_report.txt";
if ( (gwmi Win32_OperatingSystem | select Caption, CSDVersion) -notlike "*server*") # запрет запуска на серверных ОС
{
Add-Content -Value "Операционная система распознана как клиентская" -Path "C:\!script_report\add_1c_bases_report.txt";
if (!(Test-Path "$env:APPDATA\1C\1CEstart\ibases.v8i")) #если нет этого файла 1С подтягивает данные из списка баз 8.1 и игнорирует список баз 8.2
{
New-Item "$env:APPDATA\1C\1CEstart\ibases.v8i" -ItemType file -Force; # Создаем этот файл если его нет
Add-Content -Value "Файл $env:APPDATA\1C\1CEstart\ibases.v8i не найден, создали его" -Path "C:\!script_report\add_1c_bases_report.txt";
}
if (Test-Path "$env:APPDATA\1C\1CEstart\1CEStart.cfg")
{
Remove-Item "$env:APPDATA\1C\1CEstart\1CEStart.cfg" -Force #-ErrorAction SilentlyContinue #удаление старого конфигурационного файла для 8.1
}
New-Item "$env:APPDATA\1C\1CEstart\1CEStart.cfg" -ItemType file -Force #создание нового конфигурационного файла для 8.2
$GroupList = ([ADSISEARCHER]"samaccountname=$($env:USERNAME)").Findone().Properties.memberof -replace '^CN=([^,]+).+$','$1' # Создание списка групп пользователя
foreach ($Group in $GroupList) # генерация списка общих баз на основе имени группы
{
if ($Group.Length -gt 6) # Проверка длины имени группы
{
If ($Group.Substring(0,7) -eq "1cbases") # вычисление группы указывающей на базу 1С
{
Switch ($Group.Substring(8,2)) # выбор платформы 8.1 или 8.2
{
"81" {Add-Content "$env:APPDATA\1C\1Cv81\ibases.v8l" -Value ("\\gold585.int\TechFiles\CommonBases\" + $Group.Substring(11) +".v8i")} # Создание строчки из файла со списком общих баз для 8.1
"82" {Add-Content "$env:APPDATA\1C\1CEstart\1CEStart.cfg" -Value ("CommonInfoBases=\\gold585.int\TechFiles\CommonBases\" + $Group.Substring(11) +".v8i")} # Создание строчки из файла со списком общих баз для 8.2
"83" {Add-Content "$env:APPDATA\1C\1CEstart\1CEStart.cfg" -Value ("CommonInfoBases=\\gold585.int\TechFiles\CommonBases\" + $Group.Substring(11) +".v8i")} # Создание строчки из файла со списком общих баз для 8.3
}
Add-Content -Value ("Пользователь принадлежит групп $Group") -Path "C:\!script_report\add_1c_bases_report.txt";
Add-Content -Value ("Добавлено значение: CommonInfoBases=\\gold585.int\TechFiles\CommonBases\" + $Group.Substring(11) +".v8i") -Path "C:\!script_report\add_1c_bases_report.txt";
}
}
}
}
else
{
Add-Content -Value "Операционная система распознана как серверная" -Path "C:\!script_report\add_1c_bases_report.txt";
}Что получили:
- Добавление баз теперь не было морокой — просто делали группу, добавляли файл с настройками — дальше все происходило автоматом
- Могли спокойно переносить базы куда угодно, просто меняя конфигурацию в файле с настройками подключения к базе (как показала практика — очень удобно)
- Сберегли обувь хелпдеску
Акт первый, действие второе
Вторая короткая сценка из корпоративной жизни
На сцене — Админ (А), программист 1С (П1С), разговор после ухода представителя бизнеса
А — Ваш этот 1С — $#%но!!! Сколько можно решать железом проблемы архитектуры и уровня разработчиков!
П1С — да это ваши сервера #$@но! У меня на локальной файловой базе все летает! Настройте уже ваше хозяйство по нормальному!
Спорщики удаляются со сцены сыпля взаимными обвинениями, опускается занавес, свет гаснет.
И с этой стороны ни чуть не лучше… (с) печальный ослик Иа-Иа в свой собственный день рождения
Вот представьте себе — сидите вы в удобном кресле, в одной руке чашка вкусного чая, в другой пышущая жаром и свежестью булочка из кулинарии ближайшего магазина, за окном приятно пахнет весной… И это, конечно же, самое подходящие время для звонка с проблемой! Коллега — Байконур, у нас %@па!
Я — я так понимаю что стадию Хьюстона с проблемами мы уже успешно пролетели?
Коллега — да. База %имя базы% подвисла, вообще не отвечает, ТОПы уже рвут и мечут. 3 раза мне уже звонили. Надо перезагружать службу.
Я — так там же еще пачка баз на этой службе!!!
Коллега — да, поэтому вторая половина ТОПов тоже рвет и мечет что их отключат…
В итоге конечно все согласовали, перезапустили, но осадочек остался.
Идеология:
- В продуктовой среде мы должны следовать правилу — одна база — одна служба с разнесением по портам
- Запускаться службы должны исключительно из-под доменных учеток. Одна служба — одна учетка. Это удобно для раздачи прав на шары, доступ в скуль и прочее. Так же, если у вас внедрена RBAC то вы можете очень оперативно посмотреть куда имеет доступ конкретный экземпляр 1С
- Логи нужно вынести на отдельный диск и включить на эти папки сжатие (при разбитии по дням это очень сильно экономит место и ускоряет (незначительно) поиск по логам)
- Каждой службе выдается alias в DNS для того, чтобы отвязать разработку от ip и/или dns сервера (в этом случае разработка вообще не волнуется на предмет того, где фактически находится сервер — физика, виртуальная машина в приватном облаке или вообще в публичном облаке)
- На каждую службу мы выделяем 500 портов для пользовательских соединений (наше внутреннее решение)
Как мы это делали (для нового сервера. для уже существующего часть шагов не актуальны):
- Создаются учетки под каждую службу
- На машине, где они будут работать им выдаются права на «запуск как службе»
- Ставиться MS офис, обязательно с активацией по MAK-ключу
- Ставится sqlncli — утилита из набора MS SQL Native Client. На данный момент выше 2012 не появлялось
- Создается папка C:\Windows\SysWOW64\config\systemprofile\Desktop — в противном случае есть проблемы с выгрузками в Word/Excel
- Для Windows 2016 и 1С 8.1 нужно скопировать старую версию dll (В папке C:\Program Files\Common Files\System\Ole DB надо заменить два файла sqloledb.dll и sqloledb.rll взятых со старых серверов)
- Ставятся дополнительное ODBC драйверы, если нужно подключатся к MySQL/PostgreSQL
Настройка папки для службы и логов:
- Создается папка на отдельном диске называется в формате 1CServer%basename% (в стандартном случае это делает сама служба, ибо у нее есть в настройках запуска путь к логам)
- Если внутрь каталога только что созданной службы переносятся данные из другого каталога (другой службы, другого сервера), то необходимо заменить владельцев (иначе служба не получит к ним доступа) с заменой владельца подконтейнеров
- Владельцем папки делается учетная запись службы
Описание настройки службы
@echo off
chcp 1251
установка кодировки
set base=%base_name%
название базы без пробелов на английском – для каталога с логами
set dsce=%base name%
название базы с пробелами на английском – для имени службы
set dscr=%Имя базы%
название базы на русском – для представления службы
set sver=8.3
краткая версия – для имени и представления службы
set fver=1cv8\8.3.9.2170
часть пути к нужной нам версии платформы 1С
set port=8040
управляющий порт
set regp=8041
основной порт
set rnge=8060:8491
диапазон портов для службы
set name="1C:Enterprise %sver% Server Agent (x86-64) %dsce%"
имя службы (для реестра) по аналогии с типовыми, только добавляется название базы для уникальности названий
set bpth=\"C:\Program Files\%fver%\bin\ragent.exe\" -srvc -agent
путь к исполняемому файлу для запуска службы
set logs=D:\1C_Server_%base%
каталог для логов
set user="%login%@%domain_name%"
такой формат позволяет использовать логины длиннее 20 символов
пароль нигде не указывал при создании, потому что потом всё равно надо его заново указать, только тогда у пользователя будут права на запуск служб;
set view="Агент сервера 1С:Предприятия %sver% (x86-64) %dscr%"
представление службы в оснастке
sc create %name% binPath= "%bpth% -regport %regp% -port %port% -range %rnge% -d \"%logs%\"" type= "own" start= "auto" error= "severe" depend= "Tcpip/Dnscache/lanmanworkstation/lanmanserver" obj= %user%DisplayName= %view%
тут:
type= "own" – тип службы, какие бывают еще сам посмотри
start= "auto" – автоматический запуск
error= "severe" – не помню что значит, но устанавливает правильное значение ключа в реестре ErrorControl = 2
depend= "Tcpip/Dnscache/lanmanworkstation/lanmanserver" – зависимости (на четвертой вкладке указаны, вручную не настраиваются)
sc description %name% %view%
задает представление в оснастке, сразу при создании не указывается
sc failure %name% reset= 0 actions= "restart/0"
настройка на вкладке восстановление – перезапуск во всех случаях, через 0 минут; сброс счетчика через 0 дней
То же самое без комментариев:
@echo off
chcp 1251
set base=%base_name%
set dsce=%base name%
set dscr=%Имя базы%
set sver=8.3
set fver=1cv8\8.3.9.2170
set port=8040
set regp=8041
set rnge=8060:8491
set name="1C:Enterprise %sver% Server Agent (x86-64) %dsce%"
set bpth=\"C:\Program Files\%fver%\bin\ragent.exe\" -srvc -agent
set logs=D:\1C_Server_%base%
set user="%login%@domain.company"
set view="Агент сервера 1С:Предприятия %sver% (x86-64) %dscr%"
sc create %name% binPath= "%bpth% -regport %regp% -port %port% -range %rnge% -d \"%logs%\"" type= "own" start= "auto" error= "severe" depend= "Tcpip/Dnscache/lanmanworkstation/lanmanserver" obj= %user% DisplayName= %view%
sc description %name% %view%
sc failure %name% reset= 0 actions= "restart/0"Нюансы:
- Для того, чтобы в службах не было кроказябр
- в cmd ввести команду chcp 1251
- файл надо сохранить в ANSI кодировке
- Обязательно надо проверить на отсутствие дублирующих ключей в строке запуска — служба с ними не стартует!!!
- Для того, чтобы удалить службу, можно воспользоваться командой — sc delete «Имя заданное в переменной name»
- Добавить порты используемые 1С в разрешения в firewall
- Нужен всего один физический ключ на сервер — все службы будут активироваться им
После проведения всех мероприятий в итоге мы пришли к:
- Базы можно спокойно перезагружать, не трогая другие базы
- Всегда можно найти «героя» — базу, которая съедает все ресурсы
- Любые работы с базой касаются только одной конкретной базы
В следующих статьях я планирую рассказать (если эта статья народу зайдет):
- как мы перевели авторизацию в MSSQL на kerberos и вообще оптимизировали доступы
- как мы сделали мониторинг служб — кто сколько занял ресурсов
- как мы сделали мониторинг внутри службы 1С выявления блокировок пользователями быстрее, чем они позвонят
- как мы пытались внедрить CI для 1С и что из этого вышло
UPD. Дополнил кое-что по комментариям
Особенности использования консоли администрирования серверов 1С:Предприятие разных версий
21/03/2016
Особенности использования консоли администрирования серверов 1С:Предприятие разных версий
Введение
В продолжение ранее опубликованной статьи, описывающей возможность запуска нескольких служб 1С на одном сервере, хотели бы рассказать об особенностях использования консоли администрирования северов 1С:Предприятия разных версий. Дело в том, что при штатной установке данной консоли администрировать получится только сервер 1С одной версии. Если установлено несколько версий платформы на одном сервере и работает несколько служб 1С, встает вопрос о том, как же администрировать сервера 1С разных версий в рамках одного сервера?
Регистрация консоли 1С
Для регистрации консоли администрирования серверов 1С:Предприятие фирма 1С предлагает использовать исполняемый файл RegMSC.cmd, расположенный в папке bin каталога сервера 1С. Данный файл можно запустить из меню «Пуск» в Windows: «1С Предприятие 8 -> Дополнительно -> [нужная версия платформы 1С] -> Регистрация утилиты администрирования серверов 1С Предприятия».
Файл RegMSC.cmd содержит следующий скрипт:
regsvr32 /n /i:user radmin.dll
Цель данного скрипта состоит только в том, чтобы зарегистрировать компоненту radmin.dll. На практике использовать данный скрипт неудобно, так как каждый раз перед запуском консоли администрирования серверов 1С:Предприятие нужной версии приходится запускать соответствующий файл RegMSC.cmd. Плюс ко всему данный скрипт неработоспособен и нуждается в доработке (скорее всего, при его выполнении вы получите сообщение об успешной регистрации компоненты, но работать консоль не будет).
Итак, мы хотим получить работоспособный скрипт, который нам позволит автоматизировать и выполнять в один клик следующие действия:
- Регистрация компоненты radmin.dll нужной версии;
- Запуск консоли кластера 1С.
Предлагаем изменить вышеуказанный скрипт и создать основной универсальный скрипт регистрации компоненты и запуска оснастки (консоли), а также создать «скрипты-стартеры» консолей нужных версий. Вот, что у нас получилось:
rem %1 – полный номер версии 1С:Предприятия
@echo off
start /wait regsvr32 /s «C:\Program Files (x86)\1cv8\%1\bin\radmin.dll»
start «C:\Windows\System32\mmc.exe» «C:\Program Files (x86)\1cv8\common\1CV8 Servers.msc»
Данный скрипт следует сохранить в исполняемый файл формата .bat (например, «start_console.bat»). Разберем данный скрипт поподробнее. За корректную регистрацию компоненты radmin.dll отвечает строка:
start /wait regsvr32 /s «C:\Program Files (x86)\1cv8\%1\bin\radmin.dll»
В качестве параметра (%1) в неё передается номер версии платформы 1С. Следующая строка отвечает за запуск консоли MMC с оснасткой для администрирования серверов 1С:Предприятие:
start «C:\Windows\System32\mmc.exe» «C:\Program Files (x86)\1cv8\common\1CV8 Servers.msc»
Далее создадим «скрипт-стартер», который позволит запустить консоль для администрирования сервера 1С:Предприятие, например, версии 8.3.7.1873. Выглядеть он будет следующим образом:
start_console 8.3.7.1873
Этот скрипт также нужно сохранить в исполняемый файл с расширением .bat и назвать соответствующим образом с указанием версии платформы 1С.
Так как регистрация компоненты radmin.dll не оказывает влияния на работу уже запущенных консолей администрирования серверов 1С:Предприятие, то с помощью данного подхода и предложенных скриптов мы можем запускать одновременно консоли администрирования серверов 1С:Предприятие разных версий и успешно в них работать, с кластером своей версии в каждой. Готово, теперь вы можете администрировать несколько версий сервера 1С на одном сервере.
Обратите внимание, что в предложенных скриптах используются 32-разрядные версии компонентов. При попытке аналогичным образом зарегистрировать 64-разрядной компоненту, вы получите сообщение о том, что она успешно зарегистрирована, однако затем при запуске консоли администрирования серверов 1С:Предприятие вероятнее всего увидите ошибку вида:
MMC could not create the snap in, Name: 1C:Enterprise (x86-64) Servers, CLSID:…
Пока данная проблема не решена, использование нескольких 64-разрядных консолей администрирования серверов 1С:Предприятие в рамках одного сервера не представляется возможным. Если у вас есть другая информация и вы знаете, как можно решить эту проблему – пишите нам, с радостью обновим статью.
Заключение
Ошибка консоли администрирования серверов 1С:Предприятие 8.3
1c:1c-enterprise-server-administration-console-8-3-mmc-could-not-create-the-snap-in
Ошибка консоли администрирования серверов 1С:Предприятие 8.3 — MMC could not create the snap-in
После установки 1С:Предприятие 8.3 с компонентами администрирования на сервере Windows Server 2012 R2 при попытке запуска консоли администрирования «Администрирование серверов 1С Предприятия» (вызываемая оснастка C:\Program Files (x86)\1cv8\common\1CV8 Servers.msc) мы можем получить ошибку MMC could not create the snap-in.
Решение проблемы
В стартовом меню ОС находим ярлык с именем «Регистрация утилиты администрирования серверов (<версия платформы>)», ссылающийся на командный файл «C:\Program Files (x86)\1cv8\<версия платформы>\bin\RegMSC.cmd», и запускаем его с правами Администратора.
В результате выполнения командного файла мы получим сообщение об успешной регистрации библиотеки, необходимой для работы консоли управления 1С.
После этого повторно запускаем консоль управления и убеждаемся в её работоспособности.
Проверено на следующих конфигурациях:
| Версия ОС | Версия 1С:Предприятие |
|---|---|
| Microsoft Windows Server 2012 R2 Standard EN (6.3.9600) | 8.3.12.1567 32-bit |
Автор первичной редакции:
Алексей Максимов
Время публикации: 18.10.2018 06:08
1c/1c-enterprise-server-administration-console-8-3-mmc-could-not-create-the-snap-in.txt · Последнее изменение: 18.10.2018 11:44 — Алексей Максимов
Про кластер серверов 1С / Блог компании 1С / Хабр
Кластер — это разновидность параллельной
или распределённой системы, которая:
1. состоит из нескольких связанных
между собой компьютеров;
2. используется как единый,
унифицированный компьютерный ресурс
Gregory F. Pfister, «In search of clusters».
Дано: есть бизнес-приложение (например, ERP-система), с которым работают одновременно тысячи (возможно, десятки тысяч) пользователей.
Требуется:
- Сделать приложение масштабируемым, чтобы при увеличении количества пользователей можно было за счёт наращивания аппаратных ресурсов обеспечить необходимую производительность приложения.
- Сделать приложение устойчивым к выходу из строя компонентов системы (как программных, так и аппаратных), потере связи между компонентами и другим возможным проблемам.
- Максимально эффективно задействовать системные ресурсы и обеспечить нужную производительность приложения.
- Сделать систему простой в развертывании и администрировании.
Чтобы решить эти задачи, мы в платформе 1С:Предприятие используем кластерную архитектуру.
К желаемому результату мы пришли не сразу.
В этой статье расскажем о том, какие бывают кластеры, как мы выбирали подходящий нам вид кластера и о том, как эволюционировал наш кластер от версии к версии, и какие подходы позволили нам в итоге создать систему, обслуживающую десятки тысяч одновременных пользователей.
Как писал автор эпиграфа к этой статье Грегори Пфистер в своей книге «In search of clusters», кластер был придуман не каким-либо конкретным производителем железа или софта, а клиентами, которым не хватало для работы мощностей одного компьютера или требовалось резервирование. Случилось это, по мнению Пфистера, ещё в 60-х годах прошлого века.
Традиционно различают следующие основные виды кластеров:
- Отказоустойчивые кластеры (High-availability clusters, HA, кластеры высокой доступности)
- Кластеры с балансировкой нагрузки (Load balancing clusters, LBC)
- Вычислительные кластеры (High performance computing clusters, HPC)
- Системы распределенных вычислений (grid) иногда относят к отдельному типу кластеров, который может состоять из территориально разнесенных серверов с отличающимися операционными системами и аппаратной конфигурацией. В случае grid-вычислений взаимодействия между узлами происходят значительно реже, чем в вычислительных кластерах. В grid-системах могут быть объединены HPC-кластеры, обычные рабочие станции и другие устройства.
Для решения наших задач (устойчивость к выходу из строя компонентов системы и эффективное использование ресурсов) нам требовалось объединить функциональность отказоустойчивого кластера и кластера с балансировкой нагрузки. Пришли мы к этому решению не сразу, а приближались к нему эволюционно, шаг за шагом.
Для тех, кто не в курсе, коротко расскажу, как устроены бизнес-приложения 1С. Это приложения, написанные на предметно-ориентированном языке, «заточенном» под автоматизацию учётных бизнес-задач. Для выполнения приложений, написанных на этом языке, на компьютере должен быть установлен рантайм платформы 1С:Предприятия.
1С:Предприятие 8.0
Первая версия сервера приложений 1С (еще не кластер) появилась в версии платформы 8.0. До этого 1С работала в клиент-серверном варианте, данные хранились в файловой СУБД или MS SQL, а бизнес-логика работала исключительно на клиенте. В версии же 8.0 был сделан переход на трехзвенную архитектуру «клиент – сервер приложений – СУБД».
Сервер 1С в платформе 8.0 представлял собой СОМ+ сервер, умеющий исполнять прикладной код на языке 1С. Использование СОМ+ обеспечивало нам готовый транспорт, позволяющий клиентским приложениям общаться с сервером по сети. Очень многое в архитектуре и клиент-серверного взаимодействия, и прикладных объектов, доступных разработчику 1С, проектировалось с учетом использования СОМ+. В то время в архитектуру не было заложено отказоустойчивости, и падение сервера вызывало отключение всех клиентов. При падении серверного приложения СОМ+ поднимал его при обращении к нему первого клиента, и клиенты начинали свою работу с начала – с коннекта к серверу. В то время всех клиентов обслуживал один процесс.
1С:Предприятие 8.1
В следующей версии мы захотели:
- Обеспечить нашим клиентам отказоустойчивость, чтобы аварии и ошибки у одних пользователей не приводили авариям и ошибкам у других пользователей.
- Избавиться от технологии СОМ+. СОМ+ работала только на Windows, а в то время уже начала становиться актуальной возможность работы под Linux.
При этом мы не хотели разрабатывать новую версию платформы с нуля – это было бы слишком ресурсозатратно. Мы хотели по максимуму использовать наши наработки, а также сохранить совместимость с прикладными приложениями, разработанными для версии 8.0.
Так в версии 8.1 появился первый кластер. Мы реализовали свой протокол удаленного вызова процедур (поверх ТСР), который по внешнему виду выглядел для конечного потребителя-клиента практически как СОМ+ (т.е. нам практически не пришлось переписывать код, отвечающий за клиент-серверные вызовы). При этом сервер, реализованный нами на С++, мы сделали платформенно-независимым, способным работать и на Windows, и на Linux.
На смену монолитному серверу версии 8.0 пришло 3 вида процессов – рабочий процесс, обслуживающий клиентов, и 2 служебных процесса, поддерживающих работу кластера:
- rphost – рабочий процесс, обслуживающий клиентов и исполняющий прикладной код. В составе кластера может быть больше одного рабочего процесса, разные рабочие процессы могут исполняться на разных физических серверах – за счёт этого достигается масштабируемость.
- ragent – процесс агента сервера, запускающий все другие виды процессов, а также ведущий список кластеров, расположенных на данном сервере.
- rmngr – менеджер кластера, управляющий функционированием всего кластера (но при этом на нем не работает прикладной код).
Под катом – схема работы этих трёх процессов в составе кластера.
Клиент на протяжении сессии работал с одним рабочим процессом, падение рабочего процесса означало для всех клиентов, которых этот процесс обслуживал, аварийное завершение сессии. Остальные клиенты продолжали работу.
1С:Предприятие 8.2
В версии 8.2 мы захотели, чтобы приложения 1С могли запускаться не только в нативном (исполняемом) клиенте, а ещё и в браузере (без модификации кода приложения). В связи с этим, в частности, встала задача отвязать текущее состояние приложения от текущего соединения с рабочим процессом rphost, сделать его stateless. Как следствие возникло понятие сеанса и сеансовых данных, которые нужно было хранить вне рабочего процесса (потому что stateless). Был разработан сервис сеансовых данных, хранящий и кэширующий сеансовую информацию. Появились и другие сервисы — сервис управляемых транзакционных блокировок, сервис полнотекстового поиска и т.д.
В этой версии также появились несколько важных нововведений – улучшенная отказоустойчивость, балансировка нагрузки и механизм резервирования кластеров.
Отказоустойчивость
Поскольку процесс работы стал stateless и все необходимые для работы данные хранились вне текущего соединения «клиент – рабочий процесс», в случае падения рабочего процесса клиент при следующем обращении к серверу переключался на другой, «живой» рабочий процесс. В большинстве случаев такое переключение происходило незаметно для клиента.
Механизм работает так. Если клиентский вызов к рабочему процессу по какой-то причине не смог исполниться до конца, то клиентская часть способна, получив ошибку вызова, этот вызов повторить, переустановив соединение с тем же рабочим процессом или с другим. Но повторять вызов можно не всегда; повтор вызова означает, что мы отправили вызов на сервер, а результата не получили. Мы стараемся повторить вызов, при этом при выполнении повторного вызова мы оцениваем, каков результат на сервере был у предшествующего вызова (информация об этом сохраняется на сервере в данных сеанса), потому что если вызов успел там «наследить» (закрыть транзакцию, сохранить сеансовые данные и т.п.) – то просто так повторять его нельзя, это приведет к рассогласованию данных. Если повторять вызов нельзя, клиент получит сообщение о неисправимой ошибке, и клиентское приложение придется перезапустить. Если же вызов «наследить» не успел (а это наиболее частая ситуация, т.к. многие вызовы не меняют данных, например, отчеты, отображение данных на форме и т.п., а те, которые меняют данные – пока транзакция не зафиксирована или пока изменение сеансовых данных не отправлено в менеджер – следов вызов не оставил) — его можно повторить без риска рассогласования данных. Если рабочий процесс упал или произошел обрыв сетевого соединения – такой вызов повторяется, и эта «катастрофа» для клиентского приложения происходит полностью незаметно.
Балансировка нагрузки
Задача балансировки нагрузки в нашем случае звучит так: в систему заходит новый клиент (или уже работающий клиент совершает очередной вызов). Нам надо выбрать, на какой сервер и в какой рабочий процесс направить вызов клиента, чтобы обеспечить клиенту максимальное быстродействие.
Это стандартная задача для кластера с балансировкой нагрузки. Есть несколько типовых алгоритмов её решения, например:
- Round-Robin (циклический) – серверам присваиваются порядковые номера, первый запрос отправляется на первый сервер, второй запрос – на второй и т. д. до достижения последнего сервера. Следующий запрос направляется на первый сервер и всё начинается с начала. Алгоритм прост в реализации, не требует связи между серверами и неплохо подходит для «легковесных» запросов. Но при балансировке по этому алгоритму не учитывается производительность серверов (которая может быть разной) и текущая загруженность серверов.
- Weighted Round Robin – усовершенствованный Round-Robin: каждому серверу присваивается весовой коэффициент в соответствии с его производительностью, и сервера с бо́льшим весом обрабатывают больше запросов.
- Least Connections: новый запрос передается на сервер, обрабатывающий в данный момент наименьшее количество запросов.
- Least Response Time: сервер выбирается на основе времени его ответа: новый запрос отдаётся серверу, ответившему быстрее других серверов.
Для нашего кластера мы выбрали алгоритм, близкий по сути к Least Response Time. У нас есть механизм, собирающий статистику производительности рабочих процессов на всех серверах кластера. Он делает эталонный вызов каждого процесса сервера в кластере; эталонный вызов задействует некоторое подмножество функций дисковой подсистемы, памяти, процессора, и оценивает, насколько быстро выполняется такой вызов. Результат этих измерений, усредненный за последние 10 минут, является критерием — какой сервер в кластере является наиболее производительным и предпочтительным для отправки к нему клиентских соединений в данный период времени. Запросы клиентов распределяются таким образом, чтобы получше нагрузить наиболее производительный сервер – грузят того, кто везет.
Запрос от нового клиента адресуется на наиболее производительный на данный момент сервер.
Запрос от существующего клиента в большинстве случаев адресуется на тот сервер и в тот рабочий процесс, в который адресовался его предыдущий запрос. С работающим клиентом связан обширный набор данных на сервере, передавать его между процессами (а тем более между серверами) – довольно накладно (хотя мы умеем делать и это).
Запрос от существующего клиента передается в другой рабочий процесс в двух случаях:
- Процесса больше нет: рабочий процесс, с которым ранее взаимодействовал клиент, более недоступен (упал процесс, стал недоступен сервер и т.п.).
- Есть более производительный сервер: если в кластере есть сервер, отличающийся по производительности в два и более раза по сравнению с сервером, где запушен текущий рабочий процесс, то платформа считает, что даже ценой миграции клиентского контекста нам выгоднее выполнять запросы на более производительном сервере. Переноситься клиенты с одного сервера на другой будут постепенно, по одному, с периодической оценкой результата – что в плане производительности стало с серверами после переноса каждого из клиентских процессов. Цель этой процедуры – выравнивание производительности серверов в кластере (т.е. равномерная загрузка серверов).
Резервирование кластеров
Мы решили повысить отказоустойчивость кластера, прибегнув к схеме Active / passive. Появилась возможность конфигурировать два кластера – рабочий и резервный. В случае недоступности основного кластера (сетевые неполадки или, например, плановое техобслуживание) клиентские вызовы перенаправлялись на резервный кластер.
Однако эта конструкция была довольно сложна в настройке. Администратору приходилось вручную собирать две группы серверов в кластеры и конфигурировать их. Иногда администраторы допускали ошибки, устанавливая противоречащие друг другу настройки, т.к. не было централизованного механизма проверки настроек. Но, тем не менее, этот подход повышал отказоустойчивость системы.
1С:Предприятие 8.3
В версии 8.3 мы существенно переписали код серверной части, отвечающий за отказоустойчивость. Мы решили отказаться от схемы Active / passive кластеров ввиду сложности её конфигурирования. В системе остался только один отказоустойчивый кластер, состоящий из любого количества серверов – это ближе к схеме на Active / active, в которой запросы на отказавший узел распределяются между оставшимися рабочими узлами. За счет этого кластер стал проще в настройке. Ряд операций, повышающих отказоустойчивость и улучшающих балансировку нагрузки, стали автоматизированными. Из важных нововведений:
- Новая настройка кластера «Уровень отказоустойчивости»: число, указывающее, сколько серверов может выйти из строя без последствий в виде аварийного завершения сеансов подключенных пользователей. Исходя из этой настройки кластер будет тратить определённый объём ресурсов на синхронизацию данных между рабочими серверами, чтобы иметь всю необходимую для продолжения работы клиентов информацию на «живых» серверах в случае выхода из строя одного или нескольких серверов.
- Количество рабочих процессов не задается вручную, как раньше, а автоматически рассчитывается исходя из описаний требований задач по отказоустойчивости и надежности.
- Появился ряд настроек, связанных с максимальными объемами памяти, которые разрешается потреблять рабочим процессам, а также настройки, определяющие что делать, если эти объемы превышены:
Главная идея этих наработок – упростить работу администратора, позволяя ему настраивать кластер в привычных ему терминах, на уровне оперирования серверами, не опускаясь ниже, а также минимизировать уровень «ручного управления» работой кластера, дав кластеру механизмы для решения большинства рабочих задач и возможных проблем «на автопилоте».
Три звена отказоустойчивости
Как известно, даже если компоненты системы по отдельности надёжны, проблемы могут возникнуть там, где компоненты системы вызывают друг друга. Мы хотели свести количество мест, критичных для работоспособности системы, к минимуму. Важным дополнительным соображением была минимизация переделок прикладных механизмов в платформе и исключение изменений в прикладных решениях. В версии 8.3 появилось 3 звена обеспечения отказоустойчивости «на стыках»:
- Связь между клиентом, работающим по HTTP(S), и веб-сервером. В случае веб-клиента этот механизм стандартно реализуется веб-технологиями. В случае тонкого клиента, работающего по HTTP с веб-сервером, или мобильного клиента (мобильный клиент всегда работает по HTTP) мы используем библиотеку libcurl с открытым исходным кодом.
- Отслеживание разрывов соединений, механизм балансировки нагрузки и механизм повторов вызовов позволяют как можно раньше узнать о возникшей проблеме и предпринять действия по её устранению.
- Связь между ТСР-клиентом и рабочим процессом. Клиентом ТСР может выступать либо клиент 1С, либо расширение веб-сервера при работе клиента через НТТР. При выполнении каждого НТТР-вызова происходит выбор наиболее подходящего соединения с рабочим процессом и отправка этого вызова. Наиболее подходящее соединение выбирается исходя из того, в какой рабочий процесс отправлялся предыдущий вызов данного клиента. Если следующий вызов клиента можно отправить в тот же рабочий процесс, куда ушел предыдущий вызов – мы так и поступаем. Только если по какой-то причине в данный рабочий процесс вызов отправить нельзя (потому, что рабочий процесс стал недоступен, либо мы знаем, что есть другой рабочий процесс с существенно лучшей производительностью) – мы отправляем новый клиентский вызов в более подходящий рабочий процесс.
- Связь между рабочими процессами сервисами кластера, реализованными в процессах rmngr. Сервисов кластера около 20 (в зависимости от версии платформы) — сервис сеансовых данных, сервис транзакционных блокировок и т.д. На этом уровне существенную роль играют механизм распределения сервисов по серверам и репликация данных сервисов кластера. Балансировка нагрузки на уровне 1С:Предприятия позволяет получать приблизительно одинаковую лучшую производительность от всех рабочих серверов.
В заключение
Благодаря механизму отказоустойчивости приложения, созданные на платформе 1С:Предприятие, благополучно переживают разные виды отказов рабочих серверов в кластере, при этом бо́льшая часть клиентов продолжают работать без перезапуска.
Бывают ситуации, когда мы не можем повторить вызов, или падение сервера застает платформу в очень неудачный момент времени, например, в середине транзакции и не очень понятно, что с ними делать. Мы стараемся обеспечить статистически хорошую выживаемость клиентов при падении серверов в кластере. Как правило, средние потери клиентов за отказ сервера – единицы процентов. При этом все «потерянные» клиенты могут продолжить работу в кластере после перезапуска клиентского приложения.
Надежность кластера серверов 1С в версии 8.3 существенно повысилась. Уже давно не редкость внедрения продуктов 1С, где количество одновременно работающих пользователей достигает нескольких тысяч. Есть и внедрения, где одновременно работают и 5 000, и 10 000 пользователей — например, внедрение в «Билайне», где приложение «1С: Управление Торговлей» обслуживает все салоны продаж «Билайн» в России, или внедрение в грузоперевозчике «Деловые Линии», где приложение, самостоятельно созданное разработчиками ИТ-отдела «Деловых Линий» на платформе 1С:Предприятие, обслуживает полный цикл грузоперевозок. Наши внутренние нагрузочные тесты кластера эмулируют одновременную работу до 20 000 пользователей.
В заключение хочется кратко перечислить что ещё полезного есть в нашем кластере (список неполный):
- Настройки безопасности, ограничивающие прикладному решению потенциально опасные для функционирования кластера операции. Например, можно ограничить доступ к файловой системе сервера или запретить прикладному решению запускать приложения, установленные на сервере.
- Требования назначения функциональности – механизм, позволяющий администратору указать, какие сервисы кластера, прикладные решения (или даже отдельные функции прикладных решений – отчёты, фоновые и регламентные задания и т.д.) должны работать на каждом из серверов. Например, если заранее известно, что с конкретным прикладным решением (например, бухгалтерией) будет работать существенно меньше пользователей, чем с ERP, возможно, имеет смысл настроить более мощный сервер на работу исключительно с ERP.
- Управление потреблением ресурсов – механизм, отслеживающий потребление кластером ресурсов (память, процессорное время, вызовы СУБД и т.д.). Он позволяет, в частности, выставлять пользователям квоты ресурсов, которые они не могут превысить, и прерывать операции, выполнение которых влияет на производительность сервера в целом.
Администрирование сервера 1с
Автоматизированная система 1С Предприятия позволяет осуществлять управленческий, торговый, бухгалтерский учет, получать необходимые отчеты. Предусмотрены два типа работы программы:
- Файловый – 1С устанавливается только на один компьютер, работать с базами данных не может ни один менеджер. Этот вариант подходит для малых компаний с небольшим торговым оборотом.
- Клиент-версия. В работе с 1С задействована система пользователей, базы данных расположены на одном компьютере, с которым связаны все остальные. Вариант работы имеет трехуровневую архитектуру, состоящую из клиентского приложения, сервера 1С Предприятия и баз данных в формате MS SQL Server или PostgreSQL. В этом случае применяется администрирование серверов 1С, чтобы обеспечить правильную настройку.
Консоль администрирования серверов 1С: основные функции
У сервера 1С отсутствует встроенный интерфейс для осуществления администрирования, поэтому используется консоль. Она входит в стандартный пакет поставки соответствующей версии 1С Предприятия. Эта стандартная утилита устанавливается на каждый локальный компьютер, при этом базы данных могут размещаться здесь же или на удаленном сервере.
При помощи консоли для администрирования сервера 1С Предприятия можно решить следующие задачи:
- Вносить изменение в функционирование сервера, создавать новые, удалять ненужные. На них можно размещать базы данных, определять взаимодействие между различными пользователями.
- Создавать администраторов. Это пользователи, которые имеют права доступа для внесения изменений серверов. Каждый администратор может управлять только закрепленным сервером. Если не добавить ни одного администратора, администрированием сервера 1С может заниматься любой зарегистрированный пользователь.
- Создание рабочих процессов кластера 1С. Добавление рабочих процессов позволяет оказывать влияние на производительность конкретного пользователя в системе. В свойствах можно установить максимальное значение производительности (до 1000). Запускаемые сеансы присоединяются к процессу с максимальной производительностью. Систематически система самостоятельно проводит анализ и перераспределяет эти значения для оптимизации.
- Создание баз данных в 1С Предприятии. Можно установить возможность подключения к ней пользователей или разрешить работу только локально.
- Принудительное завершение сеансов. Иногда сообщение сервера информирует о том, что под указанным именем пользователя уже производится работа. Система не всегда самостоятельно прекращает этот процесс, поэтому администрирование позволяет принудительно завершить сеанс для любого пользователя.
Как начать работу в 1С?
Клиентское приложение 1С Предприятия – это пустая платформа. Чтобы она начала функционировать, необходимо выполнить несколько последовательных действий:
- Инсталлируется консоль. Она позволяет осуществлять последующее администрирование серверов 1С.
- Создание Центрального сервера. После на его основе можно создавать подотчетные ему структуры. Для этого при помощи контекстного меню вводится имя, используемый протокол, номер применяемого для связи порта.
- Создание кластера. В этом случае также поможет контекстное меню. Необходимо заполнить запрашиваемую информацию (имя кластера, используемого компьютера, порт для соединения, не обязательно совпадающий с портом, указанным ранее).
- Создание информационной базы данных. В соответствующей ветке необходимо также воспользоваться контекстным меню. В нем вводятся требуемые параметры (наименование, описание, тип соединения, место дислокации, тип СУБД, имя пользователя и его пароль). После подтверждения правильности введенных данных база создана. Теперь в нее можно вносить необходимые данные.
На первый взгляд, администрирование 1С Предприятия – процесс несложный, но без правильных настроек система не будет работать правильно, пользователь не сможет использовать ее возможности максимально. Также возможны дополнительные технические проблемы.
Администрирование профессионалами: основные преимущества
Клиент-версию 1С используют компании среднего и крупного бизнеса, которым необходимо связать в единую систему все компьютеры, включая удаленные структурные подразделения. Это позволяет принимать управленческие решения, получать консолидированные отчеты, вести общую бухгалтерию.
Важную роль играет правильная настройка и постоянное поддержание работоспособности платформы, создание пользователей, кластеров, администраторов, внесение изменений в базы данных. Для этого нужно иметь определенный штат специалистов. Для этого можно нанять новых сотрудников, постоянно обучать имеющихся людей или отдать услугу на аутсорсинг. Каждая компания сама решает, какой из методов целесообразен в конкретных условиях функционирования.
Администрирование платформы 1С, выполняемое профессиональными специалистами, имеет ряд преимуществ:
- Правильная настройка системы, которая позволяет гарантировать 1С адекватную работу, без технических сбоев.
- Постоянное внесение изменений, контроль безопасности. Деятельность компании динамична, она ставит перед автоматизированной системой новые задачи для принятия управленческих, стратегических решений.
- Установка новых модулей, правильное распределение прав доступа, создание подсистем. Особенно важно для крупных компаний, имеющих филиалы, удаленные подразделения.
- Контроль загруженности системы, распределение нагрузки на разные серверные компьютеры.
1С работает с различным расположением компонентов архитектуры, они могут находиться на одном или разных компьютерах. Для обеспечения максимальной системы защиты рекомендуется каждый элемент размещать на разных компьютерах.
1С: Предприятие 8.3. Клиент-серверный режим. Руководство администратора. Глава 4. Запуск компонентов системы
ГЛАВА 4. ЗАПУСК КОМПОНЕНТОВ СИСТЕМЫ
При установке 1С: Предприятия
папка с именем 1С
Enterprise 8 создается в меню Пуск — Программы. В этой папке будет меню
конструкция, аналогичная показанной на рис. 26:
Рис. 26. Структура меню
Товаров | Назначение |
1С Предприятие | Запускает программу запуска (1CEStart.exe) |
8.3.3.658 8.3.3.659 | Папки со ссылками для запуска |
Установите драйвер устройства HASP | Запускает установку драйвера безопасности |
Удаление драйвера устройства HASP | Запускает удаление драйвера безопасности |
1С Предприятие 8 (тонкий клиент) | Запускает программное обеспечение в системе 1С: Предприятие. |
1С: Предприятие (толстый клиент) | Запускает программное обеспечение в системе 1С: Предприятие. |
Дизайнер | Запускает программу в режиме конструктора |
ReadMe — Дополнительная информация | Дополнительная информация, не включенная в |
1С Предприятие 7.7 Конвертер IB | Программа конвертации информационной базы 1С: Предприятие 7.7 |
Администрирование 1С Предприятие | Сервер |
Запуск сервера 1С Предприятия | Работает на сервере 1С: Предприятия. |
Остановить сервер 1С Предприятия | Остановите 1С: Предприятие |
Регистрация консоли MSC | Регистры 1С: Предприятие |
4.1. ЗАПУСК СЕРВЕРНОГО АГЕНТА
Для запуска кластера серверов 1С: Предприятия необходимо
запустить агент сервера (ragent). Все последующие действия будут выполнять
система автоматически. При запуске агент сервера ищет список
кластеры, зарегистрированные на этом компьютере.
Если список находится, агент сервера запускает указанный
кластерные менеджеры. Эти менеджеры предоставляют агенту информацию о
рабочие процессы, выполняемые в каждом кластере, и агент запускает эти
процессы самостоятельно или с помощью агентов, запущенных на других рабочих
серверы кластера.
Если список кластеров не найден, агент сервера создает
кластер по умолчанию. Параметры кластера по умолчанию следующие:
Сеть
номер порта — 1541;
Сеть
диапазон портов — 1560: 1591;
Поддержка
отключено несколько рабочих процессов;
А
единый рабочий процесс, номер порта выбирается из указанного диапазона.
4.1.1. Окна
4.1.1.1. Запуск как приложение
Агент сервера может быть запущен как приложение. Для этого
выполните следующую команду:
ragent -debug -port <порт> -regport <порт> -диапазон <диапазон> -seclev <уровень> -d <каталог>
ВАЖНО!
Имена параметров и их значения должны быть
Разделены пробелами.
Команда запуска может использовать следующие параметры:
-порт <порт>
Номер сетевого порта агента сервера (ragent).Этот порт используется консолью кластера для отправки запроса на центральный сервер.
Порт кластера агентов также указывается как сетевой порт рабочего сервера.
Значение по умолчанию: 1540.
-регистр <порт>
Номер сетевого порта главного диспетчера кластера (rmngr)
создается по умолчанию при первом запуске ragent. Значение по умолчанию: 1541.
-seclev <уровень>
Уровень безопасности процесса агента кластера.Это определяет
уровень безопасности соединений с агрессивным процессом. Возможное
значения для уровня:
0 (автор
по умолчанию) — незащищенные соединения;
1 —
безопасные соединения только на время аутентификации пользователя; 2 — постоянно защищенный
соединения.
-диапазон <диапазоны>
Диапазоны сетевых портов для динамического распределения. Кластер
сервисные порты процессов выбираются из этих диапазонов, когда они не могут быть
выбирается исходя из настроек соответствующего рабочего сервера.По умолчанию
значение: 1560: 1591.
Примеры значений диапазонов: «45:49», «45: 67,70: 72,77: 90».
-отладка
Запуск кластера серверов в режиме отладки конфигурации.
-d <каталог>
Каталог, в котором будут храниться служебные файлы кластера серверов.
находятся или находятся в настоящее время (включая список кластеров и список информационных баз кластеров).
Если опция не указана, используется каталог по умолчанию. % USERPROFILE% \ Local
Настройки \ Данные приложения \ 1С \ 1Cv8 (% LOCALAPPDATA% \ 1C \ 1Cv8 для
Windows Vista и выше).Если путь к каталогу содержит пробелы, весь
путь должен быть заключен в кавычки, т.е.
-d
«c: \ Данные сервера \ кластер 2»
ПРИМЕЧАНИЕ
Имя каталога не должно заканчиваться на «\», если оно
цитируется. Правильно: «c: \ my path», неверно: «c: \ my path \».
Подробнее об уровне безопасности подключения см. Стр. 48.
Агент сервера, запущенный как приложение, можно закрыть с помощью
Ctrl
+ C ярлык.
4.1.1.2. Работает как служба
Если вы выбрали запуск агента центрального сервера в качестве службы
при установке кластера серверов эта служба будет запущена
автоматически и запускается каждый раз при запуске операционной системы.
Если агент центрального сервера установлен как приложение,
вы можете зарегистрировать сервис вручную, а затем запустить его.
Название службы отличается в 32- и 64-битной версиях
1С: Предприятие.
1С: Предприятие | Сервис |
32-битная версия | 1С: Предприятие 8.3 Агент сервера |
64-битная версия | Агент сервера 1С: Предприятие 8.3 (x86-64) |
Служба регистрируется с помощью следующей команды:
ragent -instsrvc | -rmsrvc -usr <имя> -pwd <пароль> -start | -stop -debug -port <порт> -regport <порт> -диапазон <диапазон> -seclev <уровень> -d <каталог>
ВАЖНО!
Имена опций и их значения должны быть
Разделены пробелами.
ПРИМЕЧАНИЕ
Такие операции, как регистрация, отмена
регистрация, запуск и завершение работы службы кластера агентов (ragent) должны быть
выполняется под учетной записью администратора. Необходимые для работы привилегии:
проверяются во время работы, и если они недоступны, система запрашивает
для повышения привилегий.
-instsrvc
Регистрация агента кластера в качестве службы Windows. Если ярость
запускается с этой опцией, он зарегистрируется в списке служб Windows и будет
неисправность.
Ключ -instsrvc несовместим с -rmsrvc.
-rmsrvc
Отмена регистрации
агент кластера как служба Windows. Если ragent запускается с этой опцией, он отменяет регистрацию
агент в списке служб Windows и будет выключен.
Ключ -rmsrvc не
совместим с -instsrvc.
— начало
Запуск ragent, зарегистрированного как служба Windows. Бежит ярость
уже зарегистрирован как служба Windows и отключается.
— остановка
Stop ragent зарегистрирован и запущен как служба Windows.
Останавливает ярость
уже зарегистрирован и запущен как служба Windows и отключается.
-отладка
Запуск кластера серверов в режиме отладки конфигурации.
ТИП
Поскольку в режиме отладки производительность сервера ниже, мы
рекомендую использовать режим отладки только
для отлаживаемых серверов.
-usr <имя>, -pwd <пароль>
Имя и пароль учетной записи пользователя Windows ragent
должен запускаться как служба Windows под. Их можно использовать только вместе
с -instsrvc
вариант при ярости
зарегистрирован как служба Windows.
-порт <порт>
Номер сетевого порта агента сервера (ragent).
Этот порт используется консолью кластера для отправки запросов на центральный сервер.Порт кластера агентов также указывается как сетевой порт рабочего сервера.
Значение по умолчанию: 1540.
-регистр <порт>
Номер сетевого порта главного диспетчера кластера (rmngr)
создается по умолчанию при первом запуске ragent. Значение по умолчанию: 1541.
-диапазон <диапазоны>
Диапазоны сетевых портов для динамического распределения. Кластер
сервисные порты процессов выбираются из этих диапазонов, когда они не могут быть
выбирается исходя из настроек соответствующего рабочего сервера.По умолчанию
значение: 1560: 1591.
Примеры значений диапазонов: «45:49», «45: 67,70: 72,77: 90».
-seclev <уровень>
Безопасность
уровень процесса агента кластера. Он определяет уровень безопасности для
связи с агрессивным процессом. Возможны следующие значения для
уровень:
0 (автор
по умолчанию) — незащищенные соединения;
1 —
безопасные соединения только на время аутентификации пользователя; 2 — постоянно защищенный
соединения.
-d <каталог>
Каталог, в котором будут храниться служебные файлы кластера серверов.
находятся или находятся в настоящее время (включая список кластеров и список информационных баз кластеров).
Если опция не указана, используется каталог по умолчанию:% USERPROFILE% \ Local
Настройки \ Данные приложения \ 1С \ 1Cv8 (% LOCALAPPDATA% \ 1C \ 1Cv8 для
Windows Vista и выше).
ПРИМЕЧАНИЕ
Имя каталога не должно заканчиваться на «\», если оно
цитируется.Правильно: «c: \ my path», неверно: «c: \ my path \».
Пример:
ярость
-instsrvc -usr usr1cv8 -pwd SuperSecurePassword
Подробнее об уровне безопасности подключения см. Стр. 48.
Служба по умолчанию запущена
автоматически при запуске компьютера. Запуск службы также можно выполнить с помощью
Функции Windows: Мой компьютер — Управление — Компьютер
Менеджмент — Услуги и
Приложения — Услуги — Агент сервера 1С: Предприятия 8.Отключение также
выполняется с использованием функций Windows.
Для отмены регистрации услуги:
ярость
-rmsrvc
4.1.2. Linux
Программа установки настраивает процессы сервера так, чтобы они
запускаются в режиме демона, т.е. без привязки к терминалу управления. Это
дает возможность запускать серверные процессы 1С: Предприятия при операционной системе
запускается без входа пользователя в систему.
При необходимости агент сервера может быть запущен командой
параметры линии.
4.1.2.1. Запуск агента сервера
Следующие параметры командной строки используются для запуска
агент сервера:
./ragent –daemon –debug -port <порт> -regport <порт> -диапазон <диапазоны> -seclev <уровень> -d <каталог>
ВАЖНО!
Имя опции и ее значение должны быть разделены
пространство.
-демон
Этот ключ можно использовать для запуска агента сервера в демоне.
режим, т.е.е., как фоновое приложение, которое не взаимодействует с
терминал, с которого запускается это приложение. Запуск агента сервера с
этот ключ не означает, что он будет автоматически выполнен после того, как система
перезапускается.
-отладка
Запускает кластер серверов в режиме отладки конфигурации.
-порт <порт>
Номер сетевого порта агента сервера (ragent).
Этот порт используется консолью кластера для отправки запросов на центральный сервер.Порт кластера агентов также указывается как сетевой порт рабочего сервера.
Значение по умолчанию: 1540.
-регистр <порт>
Номер сетевого порта главного диспетчера кластера (rmngr)
создается по умолчанию при первом запуске ragent. Значение по умолчанию: 1541.
-диапазон <диапазоны>
Диапазоны сетевых портов для динамического распределения. Кластер
сервисные порты процессов выбираются из этих диапазонов, когда они не могут быть
выбирается исходя из настроек соответствующего рабочего сервера.По умолчанию
значение: 1560: 1591.
Примеры значений диапазонов: «45:49», «45: 67,70: 72,77: 90».
-seclevel <уровень>
Необязательно. Уровень безопасности процесса агента кластера. Это
определяет уровень безопасности соединений с процессом ragent. Возможное
значения для уровня:
0 (автор
по умолчанию) — незащищенные соединения;
1 —
безопасные соединения только на время аутентификации пользователя; 2 — постоянно защищенный
соединения.
Подробнее об уровне безопасности подключения см. Стр. 48.
-d <каталог>
Каталог, в котором хранятся служебные файлы кластера серверов.
расположены (или будут расположены), включая список кластеров и список
кластерные информационные базы. Если параметр не указан, каталог по умолчанию
используется: ~ / .1cv8.
Если путь к каталогу содержит пробелы, вставьте его в кавычки, например:
-d
«~ / данные кластера»
Агент сервера, запущенный как приложение, может быть остановлен
нажатие Ctrl
+ С.
4.1.2.2. Запуск агента сервера с помощью сценария
Для управления 1С: Предприятием предназначен специальный скрипт.
агент сервера: /etc/init.d/ srv1cv8. Скрипт всегда регистрирует
сервер в режиме демона. В сценарии используются следующие параметры командной строки:
/etc/init.d/srv1cv8
начало | стоп | перезапуск | информация | статус
— начало
Запускает сервер. Скрипт позволяет запустить
единый экземпляр сервера 1С: Предприятия.
— остановка
Останавливает сервер. При этом останавливается только сервер
который ранее был запущен скриптом (см. начало).
-перезапуск
Перезапускает сервер. Эквивалентно последовательности остановки и
команды запуска.
-инфо
Отображает информацию о настройках сервера: порты
указывается при запуске, каталог кластера, состояние режима отладки конфигурации,
уровень безопасности соединений.
— статус
Отображается информация о состоянии сервера (есть ли
запущен или нет, и работает ли он в данный момент времени, если
начал).
Для настройки параметров запуска сервисного агента 1С: Предприятия,
вы можете использовать файл конфигурации / etc / sysconfig / srv1cv8 (если продукт
был установлен для системы RPM) или /etc/init.d/srv1cv8
файл конфигурации (если продукт был установлен для системы DEB).За
Описание параметров конфигурационного файла см. в «1С: Предприятие 8.3.
Руководство администратора ».
Пример файла конфигурации:
# ------------------------------------------------ ------------ # 1С: Параметры конфигурации Enterprise Сервера # ------------------------------------------------- ----------- # 1С: Файл ключевой таблицы Сервера Предприятия. # по умолчанию - файл usr1cv8.keytab в 1С: Предприятие Сервер # каталог установки # SRV1CV8_KEYTAB = # Номер порта кластера, созданного по умолчанию при первом # запуск ragent # по умолчанию - 1540 SRV1CV8_PORT = 1540 # Номер основного порта агента кластера.Этот порт используется # кластерная консоль для обращения к центральному серверу. Агент кластера # порт также указывается как IP-порт рабочего Сервера. # по умолчанию - 1541 SRV1CV8_REGPORT = 1541 # Диапазон портов для пула соединений # пример значений: # 45:49 # 45: 67,70: 72,77: 90 # по умолчанию - 1560: 1691 SRV1CV8_RANGE = 1560: 1691 # 1С: Режим отладки конфигурации Enterprise Сервера # 0 - по умолчанию - выключено # 1 - на SRV1CV8_DEBUG = 0 # Путь к каталогу с данными кластера # по умолчанию - $ HOMEDIR /.1cv8 / 1C / 1cv8 SRV1CV8_DATA = $ HOMEDIR / .1cv8 / 1C / 1cv8 # Уровень безопасности: # 0 - по умолчанию - незащищенные соединения # 1 - защищенные соединения только на время пользователя # аутентификация # 2 - постоянно защищенные соединения SRV1CV8_SECLEV = 0 # ------------------------------------------------- ----------- # конец конфигурации # ------------------------------------------------- -----------
4.1.2.3. Установка 1С: Предприятия Автозапуск Сервера
Для автоматического запуска сервера 1С: Предприятия, когда ваша ОС
запускается, выполните одну из следующих команд:
Для систем RPM:
chkconfig
-добавить srv1cv8
Для систем DEB:
update-rc.d
srv1cv8 по умолчанию
Эти команды добавляют скрипт запуска сервера 1С: Предприятия
(подробности см. на стр. 100) в список автоматически запускаемых служб. В
в этом случае параметры сервера будут получены из конфигурационного файла / etc / sysconfig / srv1cv8
(если продукт был установлен для системы RPM) или файл /etc/init.d/srv1cv8
(если продукт был установлен для системы DEB). Для описания
параметры конфигурационного файла см. «1С: Предприятие 8.3. Администратор.
Руководство».
4.2. ПОДДЕРЖКА НЕСКОЛЬКИХ СОВМЕСТНЫХ СЕРВЕРНЫХ ПРОЦЕССОВ
В большинстве случаев один серверный агент работает на одном рабочем сервере.
Если один серверный агент создает несколько кластеров, он
предотвращает конфликты сетевых портов. Если кластеры созданы другим сервером
агентов, вам нужно будет предотвратить конфликты сетевых портов менеджеров кластера
вручную.
Всегда помните о предотвращении конфликтов сетевых портов
рабочие процессы на сервере (если этот сервер используется в разных кластерах),
даже если такие кластеры работают под управлением одного агента сервера.
Ситуация, когда два или более серверных агента работают одновременно
на одном компьютере управлять своими собственными наборами кластеров вполне нормально, хотя
редкий и специфический. Это может быть необходимо, например, когда разные
На одном компьютере должны использоваться серверные версии 1С: Предприятия.
Для обеспечения параллельной работы двух серверов
агентов, управляющих разными кластерами, должны выполняться следующие условия:
Сервер
агенты должны иметь разные сетевые порты;
Сервер
агенты должны иметь доступ к разным каталогам служебных файлов;
Сервер
кластеры, созданные для каждого агента сервера, должны иметь разные сетевые порты;
Сеть
диапазоны портов, используемые рабочими процессами на сервере, не должны перекрываться (если
сервер используется в разных кластерах).
4.2.1. Для ОС Windows
Ниже приводится описание операций, которые необходимо выполнить для
запустить на компьютере второй экземпляр сервера 1С: Предприятия.
ТИП
Любой второй экземпляр сервера 1С: Предприятия будет
устанавливается как приложение, а не как служба Windows. При необходимости
сервер может быть зарегистрирован как сервис позже, указав необходимые
параметры при регистрации.
ПРИМЕЧАНИЕ
Такие операции, как регистрация, отмена
регистрация, запуск и завершение работы службы кластера агентов (ragent) должны быть
выполняется под учетной записью администратора.Необходимые для работы привилегии:
проверяются во время работы, и если они недоступны, система запрашивает
для повышения привилегий.
Следует помнить, что программа установки не
позволяет изменить сетевые порты сервера и, следовательно, новый экземпляр
сервера не будет работать после установки.
Будет предоставлено
примеров для запуска 1С: Предприятия.
сервер в операционной системе аналогичной разрядности (т. е. 32-разрядный сервер в
32-битная ОС или 64-битный сервер в 64-битной ОС).Если 32-битный сервер 1С: Предприятия
запускается в 64-битной ОС Windows, путь C: \ Program Files должен быть
заменен на C: \ Program Files (x86) во всех приведенных ниже примерах.
4.2.1.1. Одновременная работа разных версий Сервера 1С: Предприятия
Как услуга
Для запуска и запуска 1С: Предприятия Сервер 8.3 под Windows
сервиса одновременно с работой 1С: Предприятия Сервер 8.1 выполните следующие действия:
Навигация
в корзину
каталог только что установленной версии Сервера 1С: Предприятия.В примере используется 1С: Предприятие 8.3.1.150.
с: cd "c: \ Program Files \ 1cv8 \ 8.3.1.150 \ bin"
Удалить
регистрация 1С: Предприятия Сервер 8.3.
ярость
-rmsrvc
Удалите содержимое каталога реестра кластера. В
расположение каталога определяется методом установки
1С: Предприятие Server 8.3 (подробнее см. Стр. 58).
rmdir
-s -q «c: \ Program Files \ 1cv8 \ srvinfo»
Зарегистрироваться
сервис с другими настройками сетевого порта.
ярость
-instsrvc -port 2540 -regport 2541 -range 2560: 2590 -usr. \ usr1cv8 -pwd UsrPwd8
-d «d: \ DbData \ srvinfo»
В примере показана регистрация сервера с
следующие настройки порта:
○ Сеть
номер порта агента сервера — 2540.
○ Сеть
номер порта менеджера кластера — 2541.
○ Порт
диапазон для динамического выбора — 2560: 2590.
○ Кластер
данные реестра находятся в каталоге d: \ DbData \ srvinfo.
○ Пользователь
учетная запись, под которой работает серверная служба 1С: Предприятия — usr1cv8.
○ Пароль учетной записи пользователя, под которой
Работает сервис сервера 1С: Предприятия — UsrPwd8.
○ Чтобы включить отладку для сервиса
зарегистрирован, ключ -debug будет добавлен в командную строку.
Запуск
сервер 1С: Предприятия.
ярость
-старт
Как приложение
Если сервер 1С: Предприятия запущен как приложение,
для изменения сетевых портов выполните следующие действия:
Выйти
экземпляра сервера, нажав Ctrl + C в окне консоли с рабочим
сервер.
Навигация
в корзину
каталог только что установленной версии сервера 1С: Предприятия.
В примере используется 1С: Предприятие 8.3.1.150.
с: cd "c: \ Program Files \ 1cv8 \ 8.3.1.150 \ bin"
Удалите содержимое каталога реестра кластера. В
расположение каталога определяется методом установки
1С: Предприятие Server 8.3 (подробнее см. Стр. 58).
rmdir
-s -q «% USERPROFILE% \ Local Settings \ Application Data \ 1C \ 1cv8»
Запуск
сервер 1С: Предприятия с новыми настройками сетевого порта и другими параметрами.
ярость
-port 3540 -regport 3541 -range 3560: 3590 -d «d: \ DbData \ srvinfo»
В примере показана регистрация сервера с
следующие настройки порта:
○ Сеть
номер порта агента сервера — 2540.
○ Сеть
номер порта менеджера кластера — 2541.
○ Порт
диапазон для динамического выбора — 2560: 2590.
○ Кластер
данные реестра находятся в каталоге d: \ DbData \ srvinfo.
○ Чтобы включить отладку для сервиса
зарегистрирован, ключ -debug будет добавлен в командную строку.
○ Та же командная строка запуска будет использоваться в
последующие пусковые операции. Чтобы упростить это, его можно вставить в Windows
командный файл.
4.2.1.2. Запуск одной версии сервера 1С: Предприятия на нескольких серверах одновременно
Как услуга
1С: Предприятие не предоставляет инструментов по умолчанию для
зарегистрировать несколько экземпляров одной и той же серверной службы 1С: Предприятия
версия. Используйте утилиту sc.exe для завершения такой регистрации.пожалуйста
различать имена служб, номера сетевых портов и каталог кластеров
адреса.
Давайте рассмотрим пример командного файла, который регистрирует
серверная служба.
файл register-service.bat:
@echo off rem% 1 - полный номер версии 1С: Предприятие rem% 2 - первые две цифры номеров портов. Используйте 15 для портов 1540,1541,1560: 1591 rem% 3 - каталог, в котором хранятся данные реестра кластера. установить SrvUserName = <имя пользователя> установить SrvUserPwd = <пароль пользователя> установить RangePort =% 260:% 291 установить BasePort =% 241 установить CtrlPort =% 240 установить SrvcName = "1С: Предприятие 8.3 Агент сервера% CtrlPort%% 1 " установить BinPath = "\" C: \ Program Files \ 1cv8 \% 1 \ bin \ ragent.exe \ "-srvc -agent -regport% BasePort% -port% CtrlPort%
-range
% RangePort% -d \ «% ~ 3 \» -debug «
set Desctiption = "Агент сервера 1С: Предприятия 8.3. Параметры:% 1,% CtrlPort%,% BasePort%,% RangePort%" если не существует "% ~ 3" mkdir "% ~ 3" sc stop% SrvcName% sc stop% SrvcName% sc create% SrvcName% binPath =% BinPath% start = auto obj =% SrvUserName% password = % SrvUserPwd% displayname =% Desctiption% depends = Dnscache / Tcpip6 / lanmanworkstation / lanmanserver
Перед применением этого командного файла подробные сведения (имя пользователя и
пароль) реальной учетной записи, под которой будет запускаться служба кластера серверов
(набор
SrvUserName = и установить SrvUserPwd = strings) следует указать в этом
файл.В этом командном файле регистрируется указанная версия 1С: Предприятия.
сервер. Имя службы — это строка, содержащая следующую информацию:
1С: Предприятие
8.3 Агент сервера,
Сеть
номер порта главного диспетчера кластера,
Полный номер версии 1С: Предприятие.
Если вы регистрируете сервер 8.3.1.100, который использует сетевой порт
главный менеджер кластера 2540, название сервиса будет выглядеть так: 1С: Предприятие
8.3 Агент сервера 2540 8.3.1.100.
Пример:
служба регистрации 8.3.1.100 25 "c: \ cluster_data \ cluster 1" register-service 8.3.1.100 35 "c: \ cluster_data \ cluster 2"
В этом сценарии первая строка регистрирует сервер
сервис со следующими параметрами:
Имя
услуги: 1С: Предприятие
8.3 Агент сервера 2540 8.3.1.100.
Сервер
порты: 2540, 2541, 2560: 2591.
А
каталог, содержащий данные реестра кластера: c: \ cluster_data \ cluster 1.
Описание
услуги: 1С: Предприятие
8.3 серверный агент. Параметры: 8.3.1.100, 2540, 2541, 2560: 2591.
Во второй строке регистрируется служба сервера с
следующие параметры:
Имя
услуги: 1С: Предприятие
8.3 Агент сервера 3540 8.3.1.100.
Сервер
порты: 3540,
3541, г.
3560: 3591.
А
каталог, содержащий данные реестра кластера: c: \ cluster_data \ cluster 2.
Описание
услуги: 1С: Предприятие
8.3 серверный агент. Параметры: 8.3.1.100, 3540, 3541, 3560: 3591.
Если вам необходимо отменить регистрацию серверной службы, вы
можно использовать следующий командный файл:
unregister-service.bat файл:
@echo off rem% 1 - полный номер версии 1С: Предприятие rem% 2 - первые две цифры номеров портов. Используйте 15 для портов 1540,1541,1560: 1591 set SrvcName = "Агент сервера 1С: Предприятия 8.3% 240% 1" sc stop% SrvcName% sc stop% SrvcName%
Пример:
отмена регистрации
8.3.1.100 25
Этот командный файл останавливает службу и отменяет ее
Регистрация. Название сервиса создается по тем же правилам, что и
применяется при регистрации новой (настраиваемой) серверной услуги 1С: Предприятия.
Как приложение
Для запуска той же версии сервера 1С: Предприятия
работая как приложение, используйте командную строку. В этом случае командная строка
опции должны отличаться не только номерами сетевых портов, но и адресами
каталогов кластера:
запустить "Сервер 1" "C: \ Program Files \ 1cv8 \ 8.3.1.100 \ bin \ ragent.exe "-port 2540 -regport 2541 -диапазон 2560: 2590 -d d: \ ClusterData \ Srv1 запустить "Сервер 2" "C: \ Program Files \ 1cv8 \ 8.3.1.100 \ bin \ ragent.exe" -port 3540 -regport 3541 -range 3560: 3590 -d d: \ ClusterData \ Srv2
В этом примере два экземпляра сервера 1С: Предприятия
запущен со следующими параметрами:
Первая
сервер имеет сервер
1 в заголовке окна, работает на 25хх сетевых портах и
хранит данные кластера в d: \ ClusterData \ Srv1.
Секунда
сервер имеет сервер
2 в заголовке окна, работает на 35хх сетевых портах и
хранит данные кластера в d: \ ClusterData \ Srv2.
4.2.1.3. Изменение сетевых портов
Сервера 1С: Предприятия
Текущий экземпляр
Изменение сетевых портов действующей 1С: Предприятия
экземпляр сервера не поддерживается. Если возникнет такая необходимость, сделайте следующее:
Создать
новый экземпляр сервера с желаемыми настройками сетевого порта и другими
параметры.
Зарегистрироваться
существующие информационные базы на новом сервере.
Передача
клиентов на новый сервер.
Выйти
и удалите предыдущий экземпляр сервера 1С: Предприятия (с данными кластера).
4.2.2. Для ОС Linux
Ниже приводится описание операций, которые необходимо выполнить, чтобы
запустить на компьютере второй экземпляр сервера 1С: Предприятия.
Вы
следует помнить, что утилита установки не позволяет изменять
сетевые порты сервера, поэтому новый экземпляр сервера не будет работать после
установка.
ПРИМЕЧАНИЕ
Сервер 1С: Предприятия в ОС Linux всегда
установлен в режиме демона.
Допускаются только разные версии серверов 1С: Предприятия.
одновременно работать под ОС Linux.
4.2.2.1. Как демон
Чтобы изменить сетевые порты работающего экземпляра сервера,
сделать следующее:
Выйти
сервер 1С: Предприятия.
/etc/init.d/srv1cv83
остановка
Удалить
каталог кластера.
пог.м
-rf /home/usr1cv8/.1cv8
Изменить
настройки запуска сервера 1С: Предприятия, указав соответствующую сеть
настройки порта и другие параметры (включая каталог реестра кластера).
См. «1С: Предприятие 8.3. Руководство администратора» для описания
файл конфигурации.
Запуск
сервер 1С: Предприятия.
/etc/init.d/srv1cv83
начало
4.2.2.2. Как приложение
Если сервер 1С: Предприятия работает как приложение, выполните
следующее для изменения сетевых портов:
Выйти
экземпляр сервера, нажав Ctrl + C в окне консоли с работающим
сервер.
Удалить
содержимое каталога реестра кластера. Как обычно, это .1cv8
каталог домашнего каталога учетной записи пользователя, под которой работает сервер.
пог.м
-rf /home/<ÏîëüçîâàòåëüCåðâåðà>/.1cv8
Навигация
в каталог с бинарными файлами 1С: Предприятия.
Для 32-разрядной версии:
кд
/opt/1C/v8.3/i386
Для 64-битной версии:
кд
/ opt / 1C / v8.3 / x86_64
Запустить сервер 1С: Предприятия с новыми настройками сетевых портов и
другие параметры.
. / Агент
-port 2040 -regport 2041 -range 2060: 2090 -d /home/usr1cv8/dbinfo/.1cv8
В примере показан запуск сервера со следующим
настройки порта:
○ Сеть
номер порта агента сервера — 2040.
○ Сеть
номер порта менеджера кластера — 2041.
○ Порт
диапазон для динамического выбора — 2060: 2090.
○ Кластер
данные реестра находятся в каталоге /home/usr1cv8/dbinfo/.1cv8.
○ Чтобы включить отладку для сервиса
зарегистрирован, ключ -debug будет добавлен в командную строку.
○ Та же командная строка запуска будет использоваться в
последующие пусковые операции. Чтобы упростить это, его можно вставить в Linux
командный файл.
.Утилита администрирования кластера
для Windows
Утилита администрирования серверов 1С: Предприятия для Windows предназначена для выполнения следующих задач:
- Создание, изменение и удаление кластеров серверов
- Модификация кластеров: создание и удаление рабочих серверов, изменение их параметров и указание их требований к функциональности назначения
- Определение уровня отказоустойчивости кластера
- Ручная балансировка нагрузки между рабочими серверами
- Управление списком администраторов центрального сервера в кластере и списком администраторов кластера
- Мониторинг подключений пользователей к информационным базам и служебных подключений
- Отключение пользователей от информационных баз
- Мониторинг блокировок объектов 1С: Предприятия и блокировок клиентских подключений
- Анализ блокировок транзакций СУБД в реальном времени
- Управление блокировками соединения пользователя с информационной базой
- Управление блокировками выполнения запланированных заданий
Утилита реализована в виде оснастки MMC (Microsoft Management Console), вы можете запустить ее на любом компьютере, на котором установлено это программное обеспечение.
Все возможности администрирования серверов 1С: Предприятия также доступны в скрипте 1С: Предприятия.
Требования к функциональному назначению
Администратор управляет кластером, указывая список компьютеров (рабочих серверов), составляющих кластер. При необходимости они также могут указать требования к серверам: какие службы и подключения к информационной базе доступны на каждом рабочем сервере. Менеджеры кластеров и рабочие процессы запускаются автоматически в соответствии с заданными требованиями.Уточнять требования к работающим серверам можно в интерактивном режиме с помощью консоли администрирования кластера или скрипта 1С: Предприятия.
Уровень отказоустойчивости
Уровень отказоустойчивости кластера можно указать как количество отказов рабочего сервера, не прерывающих работу пользователя. Службы резервного копирования, необходимые для обеспечения желаемой отказоустойчивости, запускаются автоматически, а репликация каждой активной службы в резервные выполняется в режиме реального времени.
Ручная балансировка нагрузки
Балансировка нагрузки между рабочими серверами основана на анализе их производительности в реальном времени. Также доступна ручная балансировка нагрузки, что включает ограничение количества информационных баз и соединений, обрабатываемых одним рабочим процессом на определенном сервере.
Ограничение объема памяти, выделяемой для рабочих процессов
Доступно ограничение объема памяти, выделяемой для рабочих процессов.Это включает ограничение общего объема памяти для всех рабочих процессов, а также ограничение объема памяти для одного вызова рабочего процесса. Это увеличивает отказоустойчивость кластера от сбоев, инициированных человеком.
Служба лицензирования и служба внешнего управления сеансами
Служба лицензирования рассылает лицензии на программное обеспечение, необходимое для запуска клиентских приложений и серверов 1С: Предприятия, чтобы администраторы могли свободно настраивать любой из рабочих серверов кластера или развертывать кластеры на виртуальных серверах, параметры которых подвержены динамическим изменениям.
Служба внешнего управления сеансами ограничивает количество пользователей, подключенных к каждой информационной базе. Он уведомляет внешние системы, когда пользователи подключаются к информационным базам или отключаются от них, и получает ответы, разрешающие или запрещающие подключения. Взаимодействие с внешними системами осуществляется с помощью веб-сервиса, который предоставляет определенный набор методов.
Профили безопасности
Профили безопасности предотвращают выполнение прикладными решениями потенциально небезопасных операций, которые могут повлиять на работу кластера серверов.
Администратор кластера может назначить любой из профилей безопасности, доступных в кластере, информационной базе. Это ограничивает набор потенциально небезопасных операций теми, которые разрешены профилем безопасности.
Вновь созданный профиль с настройками по умолчанию запрещает все потенциально небезопасные операции:
Это включает в себя:
- Доступ к файловой системе сервера
- Запуск COM-объектов
- С помощью надстроек 1С: Предприятия
- Запуск внешних отчетов и процессоров данных
- Запуск приложений, установленных на сервере
- Доступ к Интернет-ресурсам
Таким образом, когда вы запускаете прикладное решение, которое вы еще не очень хорошо знаете, вы можете избежать всех рисков, просто создав пустой профиль безопасности и назначив его информационной базе.Затем вы можете при необходимости настроить профиль безопасности, добавив разрешенные операции.
Следующая страница: Обновление конфигурации
См. Также:
.
Добро пожаловать в 1С: Предприятие
Эта книга представляет собой руководство, которое поддерживает быстрое освоение техник развития
и адаптация приложений с помощью программы «1С: Предприятие 8».
На основе примеров из реального приложения демонстрируется структура
различных системных объектов, их функций и использования.Процедуры, написанные в
встроенный язык, включая те, которые включают язык запросов, содержат подробные
Комментарии.
Книга рассчитана как на начинающих разработчиков, не знакомых с 1С: Предприятием.
программное обеспечение, а также для тех, кто уже создал или поддерживал приложения
с помощью этого программного обеспечения.
Книгу можно использовать как практическое пособие и как справочник. Заключительный
главы содержат ссылки на методы разработчика, описанные в книге с
ссылки на соответствующие разделы.
Приложение, используемое в этой книге, учитывает накопленный опыт
в разработке для 1С: Предприятие 8.
.