1Cv8.3 on Linux

Дистрибутив: CentOS 7.
Количество рабочих мест: 4.
Задача: ускорить работу 1Cv8.3 и свести к минимуму повреждение базы данных в следствие работы вредоносных ПО.
Имеется: 4 толстых клиента с программной лицензией и сервер 8 потоков, 8ГБ оперативной памяти (а также Windows Server 2012 R2).
Количетсво баз данных: 8 считая синтетический тест Гилева.
Использование веб-сервера не будет рассматриваться поскольку в этом случае не будет доступа к конфигуратору и ограничены ресурсы моих серверов.

Установка PostgreSQL

Устанавливаем репозиторий и сам postgres:

rpm -ivh http://1c.postgrespro.ru/keys/postgrespro-1c-centos94.noarch.rpm
yum install postgresql-pro-1c-9.4

Переносим postgres в тот раздел, где больше всего пространства:

mv /var/lib/postgresql /opt/
ln -s /opt/postgresql /var/lib/
systemd start postgresql-9.4
systemd enable postgresql-9.4

Настраиваем права доступа в файле /opt/postgresql/data/pg_hba.conf:

# TYPE DATABASE USER ADDRESS METHOD

# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
#host all all 127.0.0.1/32 trust
host all all 0.0.0.0/0 trust
# IPv6 local connections:
host all all ::1/128 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local replication postgres trust
#host replication postgres 127.0.0.1/32 trust
#host replication postgres ::1/128 trust

systemd reload postgresql-9.4

Логинимся в postgres, инициализируем базу данных с русской локализацией и зададим пароль пользователю postgres:

sudo -u postgres psql
/usr/pgsql-9.4/bin/initdb -D /opt/postgresql --locale=ru_RU.UTF-8
alter user postgres with password 'pass';

В моем случае все базы вместе весят около 6ГБ. Настраиваем postgres исходя из этого:

shared_buffers = 128MB
temp_buffers = 64MB
checkpoint_segments = 32
seq_page_cost = 1.0
random_page_cost = 6.0
cpu_tuple_cost = 0.01
cpu_index_tuple_cost = 0.005
cpu_operator_cost = 0.0025
effective_cache_size = 2GB

systemd restart postgresql-9.4

Установка сервера приложений 1C

Для установки нам понадобятся следующие пакеты:

1C_Enterprise83-server-8.3.8-2054.x86_64
1C_Enterprise83-common-nls-8.3.8-2054.x86_64
1C_Enterprise83-common-8.3.8-2054.x86_64
1C_Enterprise83-ws-8.3.8-2054.x86_64
1C_Enterprise83-server-nls-8.3.8-2054.x86_64
1C_Enterprise83-ws-nls-8.3.8-2054.x86_64

Пакеты ws можно не ставить если не планируете использовать веб-сервер: rpm -ivh 1C_* (если обновляете, то:  rpm -Uvh 1C_*)
После установки будет создан пользователь usr1cv8 и в его домашней директории  будут храниться все конфиги создаваемые приложениями.
К сожалению  пакеты не ориентированы на использование в systemd, а стартовые скрипты  для init.d почему то отказались запускаться потому сперва избавляемся от  стартовых скриптов, которые можно найти в следующих директориях:
/etc/init.d/
/etc/rc.d/
Попытка создать вручную стартовые скрипты для systemd тоже провалились, так что  пришлось накидать простенький скрипт и ставить в автозагрузку:

#!/bin/bash

RAGENT="/opt/1C/v8.3/x86_64/ragent"
USERHOME="/home/usr1cv8"

function check {
        PGSQL=`ps -ef|grep postmaster|head -n1|wc -l`
        if [ $PGSQL -ne "1" ]; then
                echo "1C Enterprise Server:"
                echo "postgresql not running"
                exit 1
        fi
}

function start {
        check
        echo "1C Enterprise Server: starting..."
        su - usr1cv8 -c "$RAGENT -daemon -port 1540 -regport 1541 -range 1560:1591 -d $USERHOME -debug"
}

function stop {
        echo "1C Enterprise Server: stopping..."
        pkill ragent
        pkill rmngr
        pkill rphost
}

function status {
        echo "1C Enterprise Server status:"
        AGENT_CHECK=`ps -auxwww|grep ragent|sed '1d'|wc -l`
        if [ "$AGENT_CHECK" -eq "1" ]; then
                echo "ragent running..."
        else
                echo "ragent not running"
        fi
        MANAGER_CHECK=`ps -auxwww|grep rmngr|sed '1d'|wc -l`
        if [ "$MANAGER_CHECK" -eq "1" ]; then
                echo "rmngr running..."
        else
                echo "rmngr not running"
        fi
        HOST_CHECK=`ps -auxwww|grep rphost|sed '1d'|wc -l`
        if [ "$HOST_CHECK" -eq "1" ]; then
                echo "rphost running..."
        else
                echo "rphost not running"
        fi
}

case $1 in
        start)
                start
        ;;
        stop)
                stop
        ;;
        status)
                status
        ;;
        restart)
                stop
                sleep 1
                start
        ;;
        *)
                echo "Usage: $0 (start|stop|restart|status)"
        ;;
esac

Установим дополнительные зависимости, которые пригодятся для работы клиента 1С:

yum install ImageMagick.x86_64
yum install libgsf.x86_64
yum install msttcore-fonts-installer.noarch
yum install t1utils.x86_64
yum install unixODBC.x86_64

Настройка кластера

Оснастку администрирования устанавливаем на Windows Server.
В моем случае используется внутренний dns сервер и все обращения к серверу приложений идут через доменное имя 1c.example.com.
В этом случае на linux сервере необходимо поменять hostname на fqdn иначе сервер приложений будет отказывать в подключении:

echo "1c.example.com" > /etc/hostname
hostname -f

На Windows Server'е в %systemroot%\system32\drivers\etc\hosts необходимо сопоставить fqdn linux сервера с ip linux сервера.
В оснастке администрирования 1С нажимаем правой кнопкой по дереву Central 1C:Enterprise 8.3 servers и выбираем создать -> центральный сервер, где в поле имя прописываем fqdn linux сервера.
Далее раскрываем ветку кластеры и заходим в свойства ветки local cluster и задаем следующие параметры:

Интервал перезапуска: 86400 <- сутки
Допустимый объем памяти: 6000000 <- 6GB
Интервал допустимого объема памяти: 60 <- сервер приложений будет перезапускаться через минуту после того как процессы раздуются до 6ГБ при этом клиенты даже не заметят этих перезапусков.

Перезапуски нужны, чтобы процессы не попали в swap иначе тонкие клиенты просто зависнут. В этом случае можно будет завершать сеансы с оснастки администрирования без последствий для баз данных.
Чтобы узнать на сколько раздуются процессы надо понаблюдать за ними в течении одного/двух рабочих дней.

Настройка клиента

Запускаем толстый клиент в режиме конфигуратора и идем в меню администрирование -> тестирование и исправление и если все ОК, то выгружаем базы. Если база содержит такие критичные для sql ошибки как "совпадение уникальных значений", то эти базы не импортируются в sql и как правило такие ошибки не чинятся штатными средствами 1С.
Повторяем эти действия для всех файловых баз данных.
Далее создаем новую информационную базу, но в этот раз выбираем размещение на сервере 1С предприятие.
Указываем fqdn linux сервера и логин postgres, а также пароль пользователя postgres после чего будет создана новая база. Открываем вновь созданную базу в режиме конфигуратора и загружаем информационную базу.
Повторяем для всех баз данных.
Обычно настройка клиентов индивидуальна потому за одно решил избавиться от этого недуга.
Переименовываем файлы с списоком баз данных на каждом клиентском ПК: mv %appdata%\roaming\1c\ibases.v8i %appdata%\roaming\1c\ibases.bak
На шаре где лежат файловые базы создадим директорию config внутри которой создадим директорию bases.
В директории bases создадим настройки для каждой базы данных (пример конфигурации зарплатного учета предприятия):

[ЗУП]
Connect=Srvr="1c.example.com";Ref="ZUP";
ID=10ab4a73-6609-41f6-983c-7078ef9b5d6b
OrderInList=543
Folder=/
OrderInTree=344320
External=0
ClientConnectionSpeed=Normal
App=Auto
WA=1
Version=8.3

Все файлы должны быть в кодировке UTF-8.
И так для каждой базы данных.
В директории config создаем файл bases.cfg и вписываем строки для каждой базы данных: CommonInfoBases=\\winserv\шара\config\bases\zup.v8i
На каждом клиентском ПК в %programdata%\1c\1cestart\1cestart.cfg указываем общий конфиг: CommonCfgLocation=\\winserv\шара\config\bases.cfg
Можно таким же образом создавать списки баз данных для разных отделов.
Теперь списками баз можно управлять удаленно и просто просить перезапустить клиенты, чтобы подхватились новые списки.

Тюнинг дистрибутива

В /etc/sysctl.conf запишем следующий параметры:
vm.swappiness = 1 <- перед тем как уйти в swap сервер использует 99% оперативной памяти
vm.dirty_background_ratio = 25 <- размер страницы памяти при достижении которого данные будут записаны на диск
vm.dirty_ratio = 20 <- размер системной памяти при достижении которого процессы начнут инициализацию записи на диск
Применяем настройки: sysctl -p

Лицензии

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

Показать комментарии