1с центр администрирования настройка

Обновлено: 07.07.2024

Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.

Мы готовим к выпуску beta-версию нового прикладного решения. Рабочее название продукта 1С:Центр администрирования (недавно мы называли его «Библиотека автоматизации», но нам разонравилось :-).

Для кого и для чего предназначен продукт

Если вы занимаетесь задачами администрирования, эксплуатации, сопровождения, вы знаете насколько трудоемким и затратным может стать процесс, например, обновления на новый релиз конфигурации или платформы 1С:Предприятие. Если в вашем контуре количество машин и информационных баз можно сосчитать по пальцам одной руки, то такая задача может быть успешно и в срок выполнена администратором вручную. А если в вашем контуре 100 или 1000 машин?

1С:Центр администрирования предназначен для автоматизации задач администрирования и эксплуатации информационных систем, построенных на платформе 1С:Предприятие 8. На сегодняшний день, когда системы, становятся все более сложными, проекты масштабными, а контуры, где развернуты информационные системы, все более распределенными, остро встает вопрос автоматизации задач администрирования таких систем. Администрирование вручную и/или при помощи нетиповых средств показывают себя тем менее эффективными и тем более затратными, чем крупнее информационная система и администрируемый контур.

  • КОРП внедрения,
  • облачные решения,
  • крупный контур с большим количеством баз, серверов,
  • крупная распределенная информационная база (например, розничная сеть),
  • централизованный процесс эксплуатации большого числа мелких клиентов (вне облака).

Преимущества продукта

  • Универсальное решение для автоматизации любых задач администрирования. Да, вам больше не придется для каждого нового проекта писать автоматизацию «на коленке»;
  • Набор сценариев может расширяться администратором. Мы постарались предусмотреть и подготовить набор основных сценариев для использования «из коробки», но если ваши сценарии очень специфичны, вы легко сможете адаптировать продукт под них;
  • Возможность создания сложных сценариев из более простых (да, там есть конструктор!);
  • Простота встраивания в имеющийся IT-ландшафт. 1С:Центр администрирования можно использовать как самостоятельную конфигурацию или встроить как подсистему в уже существующую.
  • Единое рабочее место и единая точка контроля. Системы любого объема может администрировать один (!) человек;
  • Количество автоматизируемых единиц оборудования не имеет значения.

Концепция и возможности продукта

1С:Центр администрирования работает с командами и скомпонованными из них сценариями. Основное правило – сценарий переводит систему в новое состояние (state).

Команда – это максимально простое, но при этом самодостаточное действие, которое можно произвести над системой для перевода ее из состояния "1" в состояние "2" (запуск службы, обновление конфигурации информационной базы, изменение настройки кластера и т.п.). Команда фактически является простым сценарием автоматизации.

Сценарий автоматизации – это последовательность команд автоматизации выстроенных в порядке, необходимом для перевода системы из состояния "1" в состояние "2".

01.jpg

Основные сценарии автоматизации в виде скриптов и поставляемых данных будут доступны в составе 1С:Центр администрирования «из коробки». Также пользователям решения предоставляется возможность расширять как состав команд, так и создавать в режиме конструктора новые или менять существующие сценарии.

С помощью 1С:Центр администрирования в планируемой к выпуску версии будет предоставлена возможность централизованного выполнения следующих сценариев:

  • скачивание обновлений прикладных конфигураций, технологической платформы 1С:Предприятие 8, PostgreSQL,
  • установка/обновление/удаление технологической платформы 1С:Предприятие 8,
  • обновление прикладных решений (конфигураций) на новые релизы,
  • удаленная настройка кластера серверов 1С:Предприятия 8,
  • настройка программных компонент через централизованное развертывание файлов настроек,
  • выполнение таких типовых задач администрирования как:
    • перезапуск служб,
    • сбор, копирование, архивирование технологических данных (журналы, счетчики и т.д.),

    Со временем мы будем расширять набор поставляемых сценариев.

    Архитектура решения

    1С:Центр администрирования – это многокомпонентный продукт. Логически он состоит из управляющей конфигурации (рабочее место администратора) и исполняющей части (те программные компоненты, которые устанавливаются на машины автоматизируемого контура).

    02.jpg

    Управляющая конфигурация разработана на 1С:Предприятии и выполняет следующие функции:

    • единый интерфейс для управления, планирования и контроля задач автоматизации (рабочее место администратора),
    • создание и редактирование сценариев автоматизации,
    • контроль выполнения и оркестрация сложных распределенных сценариев (например, обновление платформы на кластере из нескольких серверов),
    • анализ результатов выполнения сценариев автоматизации.

    Важным преимуществом является абсолютная автономность данной конфигурации. За счет этой особенности она может использоваться как самостоятельный продукт, а также быть встроенной в виде подсистемы (библиотеки) или расширения в любую имеющуюся в вашем IT-ландшафте конфигурацию.

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

    03.jpg

    04.jpg

    На основании принятой на вход команды Агент запускает необходимый для ее выполнения скрипт.

    Исполняющие скрипты реализованы на Python. Соответствие команд и скриптов расположено в специальном конфигурационном файле, называемом словарем. Конфигурационные файлы, поставляемые вместе со скриптами, написаны на YAML. В них содержится формальное описание параметров скрипта, которые могут быть переданы на вход. С помощью этих файлов происходит валидация входящей команды на предмет корректности.

    Предвкушая возможные вопросы вида " - Теперь нам еще Python и YAML учить?", напоминаем: знание этих языков вам потребуется только в том случае, если поставляемый с 1С:Центр администрирования набор скриптов вас не будет устраивать, и вы решите написать собственные.

    Некоторые интересные возможности управляющей конфигурации

    Базовый функционал - создание сценариев автоматизации из существующих шаблонов.

    05.jpg

    Доступно конструирование новых сценариев.

    06.jpg

    Параметры команд можно заполнять из данных конфигурации, в которую встроен 1С:Центр администрирования.

    07.jpg

    Есть возможность планирования и контроля задач автоматизации с использованием календаря.

    08.jpg

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

    09.jpg

    Для распределенных контуров, а также консолидации процессов автоматизации нескольких проектов, доступна возможность разграничения полномочий ответственных сотрудников в рамках контуров/проектов.

    10.jpg

    Планируемый комплект поставки beta-версии

    • Конфигурация «1С:Центр администрирования»;
    • Расширение конфигурации «1С: Центр администрирования» (функционально идентичное конфигурации);
    • Агент;
    • Набор скриптов и конфигурационных файлов;
    • Поставляемые данные: набор сценариев автоматизации, готовых к запуску «из коробки»;
    • Комплект документации.

    Что в планах к выпуску «финалки»

    В планах на развитие у нас много задумок, которые мы планируем вносить в продукт уже после выпуска beta-версии:

    image alt text

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

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

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

    Если запустить 1С с параметром /ClearCache, то будут очищены только клиент-серверные запросы. Локальные метаданные останутся и их нужно удалять отдельно на уровне файлов и папок. Эти данные хранятся в профиле пользователя, в папках с длинными названиями из GUID баз данных. Если баз на сервере немного, то такой кэш нетрудно удалить руками. Но если БД исчисляется десятками, то чистке вручную вы не обрадуетесь.

    image alt text

    В подобных ситуациях выручит скрипт на Powershell, который запускается каждый раз при выходе пользователя из системы:

    И никаких связанных со старым кэшем проблем.

    Для исправления испорченной файловой базы в поставку 1С входит утилита chdbfl.exe, которая просто считывает содержимое базы во временный файл. Если какие-то данные считать не может — пропускает. При этом у нее нет ключей запуска для автоматизации, и проверку приходится запускать вручную.

    Вообще, правильнее запускать проверку БД конфигуратором, но этот процесс проходит значительно дольше. Если же использовать только проверку физической целостности средствами chdbfl.exe, то не забывайте делать резервную копию из-за возможной потери данных.

    Для баз 8.1 Андрей Скляров создал хороший инструмент Check1CD, с двумя параметрами запуска: "исправлять найденные ошибки" и “путь к базе”.

    Но в Check1CD не хватает двух вещей:

    Раз есть "хотелка" и немного свободного времени, то почему бы не попробовать решить вопрос самостоятельно?

    Доработать код для передачи параметров через ключи командной строки — дело техники.

    image alt text

    image alt text

    С выходом 1С 8.2 возникла проблема — путь к chdbfl менялся с установкой нового релиза. Что ж, дополним скрипт:

    Надо сказать, недавно был опубликован исходный код Check1CD. Да, тоже на AutoIT.

    Аналогичный механизм можно применять и для автоматического запуска различных регламентных механизмов, где нужно запускать 1С и ждать завершения операции.

    При различных регламентных операциях с 1С (ночное обновление конфигурации или бэкап в .dt) важно обеспечить отсутствие подключенных к ней пользователей. Можно конечно запускать 1С: Предприятие с ключом /C ЗавершитьРаботуПользователей, но это не всегда удобно, да и хочется же потом написать личное письмо с рекомендациями по устранению склероза.

    Можно использовать штатную возможность подключения к 1С через COMConnector и скрипт на AutoIT. Код написан под 1С 8.1 и позволяет выкинуть пользователей из базы с записью в журнал.

    Но операцию иногда нужно проворачивать по просьбе самого пользователя, который запустил "тяжелый" отчет и повесил 1С. Если не хотите решать эти вопросы самостоятельно, то просто выведите любителям “тяжелых” отчётов ярлык на скомпилированный скрипт:

    Еще COMConnector помогает проверить наличие обновлений конфигурации, получить какую-то информацию из базы, и автоматизировать заведение пользователей в 1С.

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

    Для примера приведу функцию создания пользователей в типовой Бухгалтерии 2.0.

    image alt text

    Юрлиц развелось слишком много — нужно разбивать на столбцы.

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

    Если нужно перенести базу 1С: Предприятия вместе с ее данными в SQL на другой сервер, то делать это вручную целесообразно только для 1-2 БД.

    При большем их числе рутина станет утомительной - лучше воспользоваться скриптом.

    image alt text

    Список баз для миграции можно брать и из файла, а лог выводить в текстовый файл. Аналогичным образом можно конвертировать несколько десятков баз из файловых в SQL простой выгрузкой-загрузкой в .dt

    Конечно, это далеко не все, что можно автоматизировать в связке с 1С. Но разного рода обмены, получение real-time информации из 1С в других приложениях и прочие сценарии не попали в этот обзор из-за узкой направленности и специфики.

    Наверняка у вас тоже есть свой набор "ноу хау" для администрирования 1С — будет здорово если поделитесь с коллегами в комментариях.

    Скрипты и ноу-хау предоставлены avelor, за что ему огромное спасибо!

    Управлять кластером серверов 1С:Предприятие версии 8.3 возможно как с помощью консоли администрирования серверов 1С, так и из командной строки. Для этих целей служит Сервер администрирования кластера серверов, который состоит из двух утилит: непосредственно самого сервера — программы ras.exe и утилиты командной строки rac.exe, которая обращаясь к запущенному прежде серверу ras позволяет выполнять различные операции с кластером серверов 1С:Предприятия.

    Подробно про данный механизм можно прочитать в поставляемой вместе с платформой книге «Руководство администратора. Клиент-серверный вариант» (или, соответственно, на сайте ИТС).

    А общая схема работы данной связки выглядит следующим образом:


    Сервер администрирования должен быть той же версии, что и версия кластера серверов 1С:Предприятия, причем одновременно к одному кластеру серверов могут быть подключены несколько серверов администрирования, но конкретный сервер администрирования может взаимодействовать только с одним агентом сервера.

    И сервер администрирования и утилита командной строки могут работать в любой поддерживаемой платформой 1С:Предприятия ОС. Но в данной статье мы ограничимся только ОС семейства Windows.

    2. Установка компонент сервера администрирования

    И сам сервер и утилита администрирования входят в состав компонент сервера 1С:Предприятия. Соответственно, на компьютере с запущенной службой агента сервера 1С:Предприятия они уже должны быть установлены по умолчанию.

    Чтобы убедиться в этом, достаточно перейти в каталог с файлами сервера 1С:Предприятия и найти в нем соответствующие утилиты (для удобства файлы можно сгруппировать по типу).


    Подробно про установку сервера 1С:Предприятия я писал здесь.

    Для установки сервера администрирования на компьютере, где ранее не был установлен сервер 1С:Предприятия, необходимо запустить дистрибутив установки сервера 1С и в составе компонент выбрать пункт «Сервер 1С:Предприятия 8».


    Причем, при выбранной данной компоненте на следующем шаге мастер установки предложит установить сервер 1С:Предприятия как службу Windows. От этого пункта конечно же следует отказаться сняв соответствующий флаг.


    После установки необходимо убедиться в наличии всех необходимых компонент описанным выше способом.

    3. Запуск сервера администрирования

    Для получения подробной информации по утилите ras.exe можно вызвать справку выполнив команду


    Из справки видно, что сервер администрирования может работать как в режиме приложения, так и как служба Windows (параметр service). Также мы можем задать сетевой порт, на котором будет работать сервер администрирования (параметр port, по умолчанию используется порт 1545), а для режима администрирования кластера используется режим claster. Вызвать справку к данному режиму можно командой:

    После чего увидим, что у данного режима в качестве аргумента указывается адрес агента кластера серверов 1С:Предприятия. По умолчанию это localhost:1540.


    Таким образом, если сервер администрирования запускается на той же машине, где запущен и агент сервера 1С:Предприятия, достаточно выполнить команду

    Ну а если необходимо подключиться к агенту сервера, запущенном, например, на компьютере с сетевым именем Server1C, причем агент работает на нестандартном порту 2540, то команда будет следующей:

    4. Запуск сервера администрирования в качестве службы Windows

    Конечно же, чтобы не запускать сервер администрирования каждый раз руками, удобно запустить его единожды в качестве службы Windows. Но, к сожалению, разработчики платформы не реализовали возможность автоматической регистрации соответствующей службы в системе, как, например, это сделано для агента сервера 1С. Для добавления службы предлагается воспользоваться системной утилитой sc. Давайте рассмотрим этот процесс чуть более детально.

    Для начала, я рекомендую для создаваемой службы создать отдельного пользователя Windows. Подробно как это сделать я описывал здесь.

    Пусть это будет локальный пользователь с именем USR1CV8_RAS и паролем Pass123

    Далее, необходимо создать и выполнить bat-файл, который будет регистрировать соответствующую службу. Содержания файла следующее:

    В файле указываем:

    • Имя пользователя и пароль из под которого будет запускаться служба — переменные SrvUserNameи SrvUserPwd
    • Адрес и порт агента сервера, который мы собираемся администрировать — переменные AgentNameи CtrlPort
    • А также имя службы и сетевой порт на котором будет работать сервер администрирования — переменные RASPortи SrvcName. Имеет смысл менять эти параметры только если вы хотите запустить параллельно несколько серверов администрирования, например для обслуживания разных серверов 1С.


    В качестве единственного параметра bat-файла выступает текущая версия платформы 1С:Предприятия. Таким образом, для создания службы запускаем командную строку с правами администратора и запускаем созданный ранее файл register-ras.bat, не забыв указать нужную версию платформы.


    Проверяем, что в системе появилась служба с указанным именем. И сразу запускаем ее, выбрав соответствующий пункт в контекстном меню.


    На этом установка сервера администрирования в качестве службы завершена.

    5. Администрирование кластера серверов с помощью утилиты rac.exe

    Итак, сервер администрирования мы установили. Взаимодействием с сервером осуществляется с помощью специальной консольной утилиты rac.exe. Выполним команду

    чтобы получить справку данной программы.


    Как видно из справки, утилита имеет один общий аргумент, задающий адрес сервера администрирования (по умолчанию localhost:1545) и множество режимов работы: для администрирования агента кластера серверов, самого кластера, менеджера кластера, рабочих процессов и т. д. Справку по каждому режиму можно вызвать соответствующей командой.


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

    Получение списка информации о кластерах:


    Получение списка информационных баз на заданном кластере серверов:


    Получение списка соединений с указанной информационной базой:


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

    6. Программные обертки для работы с сервером администрирования

    Главное, мы имеем возможность выполнять различные инструкции на кластере серверов 1С из командной строки. А это значит, что можно добавлять необходимые функции по взаимодействию с кластером серверов 1С:Предприятия в различные программы, обработки или же скрипты.

    Например, среди прочего, работать с сервером администрирования может написанная на языке OneScript программа deployka.

    О скиптовом движке OneScript я уже рассказывал здесь.

    О программе deployka можно подробнее узнать здесь.

    Ну а максимально полный обзор всех имеющихся библиотек и приложений написанных на OneScript приведен в этой замечательной статье.

    7. Установка и работа с программой deployka

    Алгоритм установки OneScript и deployka довольно подробно разобран в статьях по ссылкам, указанным в предыдущем пункте. Ну а если коротко, он состоит из следующих действий:

    1. Скачиваем дистрибутив OneScript с официального сайта.

    2. Устанавливаем, следуя инструкциям мастера.

    3. Перелогиниваемся в системе, чтобы применились новые переменные среды.

    4. Запускаем командную строку с правами администратора, проверяем, что предыдущие пункты выполнены корректно командной


    5. Устанавливаем программу deployka с помощью пакетного менеджера opm, выполнив команду


    6. Проверяем, что все работает, вызвав справку «деплойки» командой


    7. Вот в общем то и все. Все режимы работы программы видны на экране. Далее читаем справку на сайте или в консоли, вызывав подсказку для каждого режима соответствующей командой:


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


    8. Теперь можно использовать «деплойку» в своих скриптах. Например скрипт обновления информационной базы из хранилища, с отключением пользователей и обновлением базы данных может выглядеть так:


    В этой статье выражено личное мнение автора, его видение мира, его путь, и это все не претендует на абсолютную верность и объективность. Автор не несет никакой ответственности за последствия использования данной информации, он только надеется что эта информация поможет сделать кому-то жизнь проще.

    Предисловие

    Сначала я просто хотел написать небольшую статью о том, как мы разносили базы по службам, но в ходе углубления в этот процесс мы добавляли всякие разные штуки (мониторинг служб, потом мониторинг пользователей внутри 1С, потом прикрутили заббикс, и, наконец, пришли к CI/CD на базе 1С). В итоге я понимаю что пихать это в одну статью будет слишком — решил разделить на несколько. Ну а название навеяно циклом статей "сети для самых маленьких", которые принесли мне много приятных минут и к которым я отсылаю всех, кто "хочет изучить сети". Итак, мы приступаем!

    Когда ты признаешь проблему, значит ты на половину уже вылечился (с) один знакомый психиатр

    В этой статье я хочу поделиться своим опытом администрирования большого числа 1С в корпоративном секторе. Базы все разные, есть разработка, есть тестовые, все как у всех. Но их просто достаточно много. И все было хорошо, но в определенный момент проводить какие-то админские работы стало крайне тяжело и рискованно.

    Какие у нас были сложности:

    1. Подвисшая база тянула за собой перезапуск службы, а значит страдали невинные (пользователи других баз)
    2. Было тяжело понять кто сегодня "герой дня" — какая база заняла все ресурсы
    3. Обновление релизов — обновление одной тянуло за собой автоматическое обновление всех баз на этой службе
    4. Ручное подключение баз пользователям, ручное изменение в случае переездов
    5. Мониторинг
      И только сейчас я понимаю что это была только вершина айсберга.

    Акт первый, действие нулевое

    Небольшое отвлечение на основные постулаты, осознание которых далось большой кровью и болью.

    1. Старые версии 1С (до 8.3.11+) имеют просадку по производительности при работе в виртуализированной среде. (Источник — Гилев и собственные тесты)
    2. Кластер есть, но с ним все крайне не просто. Возможно его доработают потом, но пока он в основном для галочки. (источник — собственный опыт)
    3. При выборе процессора смотрите только на частоту. Процессор в 6 ядер по 3,4Ггц порвет в куски процессор на 20 ядер по 2Ггц. Проблема в том, что 1С вообще ничего не знает про параллельные вычисления. По сути это работает так — у нас есть определенное число воркеров для каждой службы, их раскидывают по процессорам, и если в каком то воркере пользователь запустил какой-то тяжелый отчет то в системе будет загружено только одно ядро процессора. Именно то, на котором работает воркер с запущенным заданием… Для БД ситуация кстати ровно обратная. (источник — Гилев, собственный опыт, опыт коллег)
    4. Не используйте логи в "новом" формате (запись в SQLLite) — вы очень быстро столкнетесь с тем, что производительность этого решения еще хуже чем файлового варианта. (Источник — собственный опыт, опыт коллег).
      По подсказкам из комментариев есть вариант вынести логи на отдельный инстанс.
      В 8.3.12 обещали логи в нормальный скуль.
    5. 1С оооочень не любит IPv6. На всех серверах с 1С лучше сразу понижать приоритет IPv6 до минимума. (Источник — Гилев, собственный опыт)
    6. Используйте для виртуальных серверов виртуальные сетевые карточки E1000. С остальными проблема по производительности (Источник — Гилев, но на собственном опыте не подтвердилось, хотя особо и не тестили)
    7. Обслуживание баз дает хороший прирост производительности, особенно периодический пересчет итогов, а так же обслуживание индексов SQL (Источник — собственный опыт, Гилев)
    8. Поиск причин падения 1С сродни поеданию неочищенного кактуса. Выяснить что-то толком можно только через боль, унижения и страдания. (Источник — собственный опыт)
    9. Нет ни одного официального образа ни под один гипервизор. Про докер я вообще молчу. (Источник — сайт 1С)
    10. Программная лицензия для сервера привязывается к — сюрприз, сюрприз — серийному номеру процессора (и еще огромному количеству параметров сервера). В эпоху повсеместной виртуализации ход потрясающий. Поясняю — активировали сервер, переехали на другую ноду, перезагрузили машину — 1С не запуститься. Расчехляйте новый активационный код. (Источник — собственный опыт, болтливая техническая поддержка 1С =))
    11. 1С — это учетная система, а не отчетная. Хотите много нормальных жирных отчетов и быстро — выводите это за рамки 1С. (Источник — собственный опыт)
    12. У 1С есть два неоспоримых достоинства, за счет которых она будет процветать еще долго:
      • стоимость самого продукта/разработчиков
      • скорость разработки
        и к сожалению для российского бизнеса они являются первоочередными. А зачастую и единственными, на что вообще смотрят. (Источник — печальная реальность)
    13. Никогда не используйте файловую шару как место под хранилище конфигураций 1С. Только службу. Иначе маты со стороны разработки о упавшем черт знает когда хранилище станут вашим неизменным спутником по жизни. (Источник — собственный опыт, опыт коллег)

    Акт первый, действие первое

    Первая короткая сценка из корпоративной жизни

    На сцене — Админ (А), программист 1С (П1С) и представитель бизнеса (ПБ)
    ПБ — У нас медленно работает программа!
    А — у меня в системе все хорошо!
    П1С — я все написал правильно, у меня на компьютере все работает быстро!
    ПБ (робко и растерянно) — но она же долго…
    А и П1С хором — у нас все хорошо, проблема на вашей стороне!

    Проблемы всегда случаются не вовремя (с) (5-летний философ)

    И вот в одно прекрасное солнечное утро (на самом деле это была глубокая зимняя ночь) мы поняли что завтра надо запустить новую базу. Завтра наступал тот прекрасный день, который уже много раз описывался тысячами авторов и имя ему — легион! Тьфу, простите, занесло. Имя этому дню был дедлайн. Час ночи, завтра на 200 компах должна запуститься новая база." Да не проблема, у нас же все компы в домене! Сейчас быстренько сделаем логин-скрипт и дело в шляпе!" подумаете вы. И будуте правы — так же подумали и мы. И сделали. Только, как обычно это бывает, погорели на мелочи — я в логон-скрипте я прописал %filename%.bat а коллега выложил %filename%.cmd.

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

    Но мысль автоматизации этого процесса у меня в голове засела очень крепко и стал даже вырисовываться план внедрения.

    В итоге мы пришли к следующей идеологии:

    • Все раздается через AD — создаются группы вида 1cbases-%версия платформы%-%имя базы% и туда силами хелпдеста добавляются пользователи, которым нужна база.
      • одна группа — одна база
      • 1cbases — это префикс по которому удобно искать группы
      • версия платформы 81, 82 и 83 (релиз не принципиален)
      • название базы соответствует имени файла с настройками

      Как мы это делали:

      1. Через групповые политики добавляется новое задание в планировщик (задача планировщика прописать пользователю путь к файлу подключения базы):
        • запускать от имени пользователя
        • событие — разблокировка компьютера
        • действие — запуск нашего скрипта
      2. Создаем нужные группы в АД и заполняем их пользователями
      3. Создаем нужные файлы для запуска самих 1С. Тут остановлюсь чуть поподробнее. Изначально мы долго мучили интернет своими запросами и нашли полное описание структуры файлов *.v8i. Но потом нашелся способ проще и гениальнее.
        • запускаем 1С
        • настраиваем подключение к базе
        • проверяем что все работает
        • кликаем правой клавишей по названию базы и выбираем пункт — "Сохранить ссылку в файл"
      1. Добавление баз теперь не было морокой — просто делали группу, добавляли файл с настройками — дальше все происходило автоматом
      2. Могли спокойно переносить базы куда угодно, просто меняя конфигурацию в файле с настройками подключения к базе (как показала практика — очень удобно)
      3. Сберегли обувь хелпдеску

      Акт первый, действие второе

      Вторая короткая сценка из корпоративной жизни

      И с этой стороны ни чуть не лучше… (с) печальный ослик Иа-Иа в свой собственный день рождения

      Вот представьте себе — сидите вы в удобном кресле, в одной руке чашка вкусного чая, в другой пышущая жаром и свежестью булочка из кулинарии ближайшего магазина, за окном приятно пахнет весной… И это, конечно же, самое подходящие время для звонка с проблемой! Коллега — Байконур, у нас %@па!

      Я — я так понимаю что стадию Хьюстона с проблемами мы уже успешно пролетели?
      Коллега — да. База %имя базы% подвисла, вообще не отвечает, ТОПы уже рвут и мечут. 3 раза мне уже звонили. Надо перезагружать службу.
      Я — так там же еще пачка баз на этой службе.
      Коллега — да, поэтому вторая половина ТОПов тоже рвет и мечет что их отключат.

      В итоге конечно все согласовали, перезапустили, но осадочек остался.

      1. В продуктовой среде мы должны следовать правилу — одна база — одна служба с разнесением по портам
      2. Запускаться службы должны исключительно из-под доменных учеток. Одна служба — одна учетка. Это удобно для раздачи прав на шары, доступ в скуль и прочее. Так же, если у вас внедрена RBAC то вы можете очень оперативно посмотреть куда имеет доступ конкретный экземпляр 1С
      3. Логи нужно вынести на отдельный диск и включить на эти папки сжатие (при разбитии по дням это очень сильно экономит место и ускоряет (незначительно) поиск по логам)
      4. Каждой службе выдается alias в DNS для того, чтобы отвязать разработку от ip и/или dns сервера (в этом случае разработка вообще не волнуется на предмет того, где фактически находится сервер — физика, виртуальная машина в приватном облаке или вообще в публичном облаке)
      5. На каждую службу мы выделяем 500 портов для пользовательских соединений (наше внутреннее решение)

      Как мы это делали (для нового сервера. для уже существующего часть шагов не актуальны):

      1. Создаются учетки под каждую службу
      2. На машине, где они будут работать им выдаются права на "запуск как службе"
      3. Ставиться MS офис, обязательно с активацией по MAK-ключу
      4. Ставится sqlncli — утилита из набора MS SQL Native Client. На данный момент выше 2012 не появлялось
      5. Создается папка C:\Windows\SysWOW64\config\systemprofile\Desktop — в противном случае есть проблемы с выгрузками в Word/Excel
      6. Для Windows 2016 и 1С 8.1 нужно скопировать старую версию dll (В папке C:\Program Files\Common Files\System\Ole DB надо заменить два файла sqloledb.dll и sqloledb.rll взятых со старых серверов)
      7. Ставятся дополнительное ODBC драйверы, если нужно подключатся к MySQL/PostgreSQL

      Настройка папки для службы и логов:

      1. Создается папка на отдельном диске называется в формате 1CServer%basename% (в стандартном случае это делает сама служба, ибо у нее есть в настройках запуска путь к логам)
      2. Если внутрь каталога только что созданной службы переносятся данные из другого каталога (другой службы, другого сервера), то необходимо заменить владельцев (иначе служба не получит к ним доступа) с заменой владельца подконтейнеров
      3. Владельцем папки делается учетная запись службы
      1. Для того, чтобы в службах не было кроказябр
        • в cmd ввести команду chcp 1251
        • файл надо сохранить в ANSI кодировке
      2. Обязательно надо проверить на отсутствие дублирующих ключей в строке запуска — служба с ними не стартует.
      3. Для того, чтобы удалить службу, можно воспользоваться командой — sc delete «Имя заданное в переменной name»
      4. Добавить порты используемые 1С в разрешения в firewall
      5. Нужен всего один физический ключ на сервер — все службы будут активироваться им

      После проведения всех мероприятий в итоге мы пришли к:

      1. Базы можно спокойно перезагружать, не трогая другие базы
      2. Всегда можно найти "героя" — базу, которая съедает все ресурсы
      3. Любые работы с базой касаются только одной конкретной базы

      В следующих статьях я планирую рассказать (если эта статья народу зайдет):

      Читайте также: