1с linux создание кластера из оснастки

Обновлено: 05.07.2024

Итак, у нас есть два настроенных сервера (физических или виртуальных) с CentOS 7. Пусть это будут v83node1 и v83node2 с IP-адресами 172.16.0.101 и 172.16.0.102 соответственно. Так же у нас будет v83sql, который является виртуальным IP-адресом (VIP) 172.16.0.200. Подразумевается, что в сети присутствует сервер DNS, который в состоянии правильно разрешить доменные имена в IP-адреса. Если это не так, то нужно соответствующим образом заполнить файл /etc/hosts:

Примечание 1. Здесь и далее при описании конфигурационных файлов приводятся только изменённые или добавленные строки.
Примечание 2. Если специально не оговорено, то приведённые операции выполняются на обоих серверах.

Для установки необходимого ПО нам потребуются дополнительные репозитории. Это Extra Packages for Enterprise Linux (EPEL), репозиторий с пропатченной для 1С версией PostgreSQL от российской компании Postgres Professional, а так же официальный репозиторий PostgreSQL (если у вас один сервер, то данный репозиторий не обязателен). Подключим их:

Так как репозитории postgrespro-1c и pgdg96 содержат одинаковые пакеты, то необходимо задать правильные приоритеты для yum. В противном случае у вас наверняка возникнет ситуация, когда пропатченный PostgreSQL будет заменён «ванильным» и 1С работать не будет. Установим необходимый плагин и зададим приоритет postgrespro-1c над pgdg96:

Теперь можно установить сервер PostgreSQL и repmgr. Последний позволяет управлять потоковой репликацией, но не является обязательным для её работы:

Для корректной работы репликации настроим SSH-аутентификацию по ключам для пользователя postgres, предварительно задав ему пароль. Сам же ключ создаётся без пароля. Обратите внимание, что при выполнении команды ssh-copy-id на v83node1 в аргументах указываем v83node2 и наоборот. Выполняем на v83node1:

И на v83node2:

Все операции выполняются на v83node1.

Произведём инициализацию базы данных:

Отредактируем /var/lib/pgsql/9.6/data/pg_hba.conf в соответствии со своими нуждами и политиками безопасности. Так как данная конфигурация будет распространена на другой сервер, то следует предусмотреть все возможные варианты подключения. Приведённые ниже настройки разрешают все локальные подключения и межсерверное взаимодействие без пароля. Так лучше не делать! 😉

Переходим к непосредственной настройке PostgreSQL. В файле /var/lib/pgsql/9.6/data/postgresql.conf отредактируем как минимум приведённые ниже параметры. Хорошей идеей будет сразу настроить PostgreSQL в соответствии со своими потребностями, так как это приведёт к значительному увеличению быстродействия. Для начальных значений есть смысл использовать PgTune, дополнительную информацию можно найти в разделе методической поддержки 1С:ИТС. Более глубокое понимание даст чтение документации, практика и тесты… много тестов:

Примечания. Помним, что данные настройки будут применены к standby-серверу. Поэтому параметрам listen_addresses и hot_standby присваиваем универсальные значения. Значение max_wal_senders должно быть как минимум на 1 больше, чем планируемое количество ведомых серверов. Выключение synchronous_commit приводит к заметному росту производительности, но в случае непредвиденного сбоя могут быть потеряны последние транзакции (с настройками по умолчанию за 600 мс до сбоя).

С данными настройками потоковая репликация будет асинхронной. Если нужна синхронная репликация, то в этом случае нельзя выключать synchronous_commit (но можно настроить, например, указав remote_write) и потребуется добавить в postgresql.conf параметр synchronous_standby_names = '*' . Расплатой за синхронность будет существенное падение производительности.

Отредактируем файла /etc/repmgr/9.6/repmgr.conf. В отличии от настроек PostgreSQL, настройки repmgr индивидуальны для каждого сервера:

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

Запустим PostgreSQL, создадим базу данных для repmgr, после чего зарегистрируем primary-сервер.

Все операции выполняются на v83node2. По сути, настройка сводится к копированию конфигурации с primary-сервера.

Отредактируем файл /etc/repmgr/9.6/repmgr.conf:

Далее выполняем клонирование конфигурации с primary-сервера (директория /var/lib/pgsql/9.6/data должна быть пустой):

Теперь можно запустить PostgreSQL и зарегистрировать standby-сервер:

Доверяй, но проверяй. Никогда не доверяй и всегда проверяй.

Проверим состояние со стороны primary-сервера (v83node1). Видно, что v83node2 (application_name) подключен с IP-адреса 172.16.0.102 (client_addr):

Со стороны standby-сервера (v83node2) команда будет другая и показывает статус репликации:

Так же состояние репликации можно проверить с любого сервера средствами repmgr:

Для проверки репликации на практике посмотрим список баз на v83node2:

Создадим на v83node1 новую базу данных:

И снова проверим список баз на v83node2:

Как видим, репликация работает.

Данный раздел должен был называться «Настройка автоматической обработки отказов». Но данный вопрос требует более ответственного подхода, чем «хаутушечка» в Интернете. Поэтому если вам нужна статья для настройки автоматической обработки отказов, то вам не нужна автоматическая обработка отказов. Вместо этого упростим ручную миграцию primary-сервера путём настройки VIP. Установим keepalived:

Отредактируем файл /etc/keepalived/keepalived.conf на v83node1:

Описание основных параметров:

global_defs — секция с глобальными параметрами, в частности можно задать настройки для уведомлений по электронной почте;
vrrp_script — секция описываем скрипт для проверки состояния PostgreSQL (primary или standby), его вес и периодичность вызова;
state — задает режим работы при запуске;
interface — на каком интерфейсе работать;
dont_track_primary — не принимать во внимание состояние сетевого интерфейса;
track_script — скрипт для дополнительной оценки состояния, в случае положительного вызова его вес будет прибавлен к приоритету сервера
virtual_router_id — уникальный идентификатор VIP, должен быть одинаковым на всех серверах;
priority — приоритет сервера при выборе нового мастера, чем выше значение тем больше приоритет;
advert_int — частота оповещения мастером других серверов через широковещательный адрес 224.0.0.18 (в секундах);
authentication — задаёт пароль (не более 8 символов), должен быть одинаковым на всех серверах;
virtual_ipaddress — собственно сам VIP, можно указать несколько;
smtp_alert — отправлять уведомления о событиях по электронной почте.

На v83node2 конфигурационный файл будет отличаться секцией vrrp_instance. Поменяли режим при запуске и понизили приоритет:

Пример скрипта /etc/keepalived/repmgr_check:

Запустим keepalived и проверим, что VIP появился на указанном интерфейсе:

Если всё настроили правильно, то при миграции primary-сервера PostgreSQL виртуальный IP-адрес последует за ним.

Плановое ручное переключение

Если по каким-то причинам надо поменять primary и standby местами, то сделать это можно одной командой. Внимание! Данная команда запускает довольно сложную серию операций на двух серверах, поэтому перед запуском убедитесь в надёжности вашего оборудования, стабильности сетевого соединения, отсутствии активных клиентов и наличии резервной копии (в первую очередь наличие резервной копии!). Выполним на standby-сервере:

Вернуть всё обратно можно той же командой, только выполнить её теперь надо на v83node1.

Аварийное ручное переключение и восстановление

Случилось страшное — primary-сервер упал:

Если вы понимаете, что быстро вернуть в строй его не получится, то можно перевести standby-сервер в режим primary:

Снова проверим состояние кластера:

Как видим, роль v83node2 была повышена до primary, но и у v83node1 тоже primary. Исправим это, указав соответствующий node-id:

После этих операций вернуть primary-сервер в строй просто так уже нельзя. Предварительно его надо будет завести в кластер как standby-сервер (см. часть 2).

У сервера 1С:Предприятия внушительный список зависимостей, поэтому предварительно установим их:

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

После чего установить:

После завершения установки сервер сразу готов к работе, поэтому запустим его:

Запускаем оснастку «Администрирование серверов 1С Предприятия» и пробуем подключиться к серверу:

Дальнейшая процедура настройки сервера 1С:Предприятия достаточно хорошо освещена в документации, прилагаемой к серверу.

Сервер предприятия 8.1, а также SQL сервер могут работать на операционной системе Linux (Fedora, CentOS). В качестве SQL сервера в этом случае может использоваться PostgreSQL.

Не стоит устанавливать сервер 1C предприятия и Postgresql с установочных дисков 1С – там обычно устаревшие версии.

Установка операционной системы

1. Убедитесь, что устанавливаемая сборка Linux поддерживает имеющееся оборудование (особенно сетевую плату и RAID-контроллеры)

2. Для нормальной работы некоторых Linux (например CentOS 5.0) необходимо подключение к интернету.

3. Установку RPM пакетов удобно выполнять из графической оболочки, поэтому при установке выберите GNOME

4. Установите также клиент «Самба», если необходим доступ к сети Microsoft.

5. При установке не стоит устанавливать СУБД «PostgreSQL», входящую в дистрибутив (из раздела «Server»). Эта версия не подходит для 1С. Необходима специальная с патчами (можно взять с официального сайта 1С).

6. Обязательно выберите для установки midnight commander (mc) – удобно для тех кто на ВЫ с консольными командами Linux.

7. После установки Linux первым делом настройте сетевое подключение и подключение к интернету. Убедитесь что сетевое подключение и подключение к интернету работает (Система – Администрирование - Сеть).

8. Установите сетевое имя компьютера (Система – Администрирование – Сеть - DNS)

Установка защитного ключа

До двенадцати пользователей могут работать без ключа! Справедливо для версии 1С 8.1.11

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

До установки необходимо установить имя сервера в настройках сети на закладке DNS (Система/Администрирование/Сеть)

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

Если на сервере уже стояла предыдущая версия сервера 1С, то её следует удалить из системы. Для этого в главном меню Приложения войдите в Установка/удаление программ , перейдите на вкладку List , снимите флажки со всех пунктов, начинающихся на 1C_Enterprise , и нажмите Применить . Если переустановка выполняется полностью (если необходимо удалить информацию о кластере), то необходимо удалить пользователя «srvr1cv81», утвердительно ответив на вопрос об удалении вместе с ним его домашнего каталога в /home. Также необходимо удалить каталоги /opt/1C/ и /root/.srvr1cv81

Теперь откройте папку с дистрибутивом и двойным щелчком запускайте установки в следующей последовательности:

Не бойтесь устрашающих предупреждений – это нормальное явление.

Теперь нужно запустить агент сервера ragent в режиме демона. Для этого запустите консоль bash из меню Приложения – Стандартные – Терминал и введите следующие команды:

Для 64-х разрядных серверов вместо «i386» надо применять « x86_64 ».

По команде «top – u usr1cv81» или «ps -aux» процессы сервера приложений в списке называются «ragent», «rmngr» и «rphost» - запущены от имени «usr1cv81».

По команде netstat -na|grep tcp в списке должны бать строки:

tcp 0 0 0.0.0.0:1540 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:1541 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:1560 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:1561 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:1562 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:1563 0.0.0.0:* LISTEN

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

В следующих каталогах хранятся данные кластера: файл srvribrg.lst, каталог REG_:

Если после установки сервера 1С изменили сетевое имя сервера, то в этих файлах его также надо изменить!

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

chkconfig --add srv1cv81

chkconfig srv1cv81 on

chkconfig --list для проверки

Установка SQL сервера

Проверено для версии 8.2.4

Для нормальной работы сервера 1С необходима особая версия PostgreSQL, пропатченная. Поэтому если на сервере уже установлена обычная версия PostgreSQL, придётся её деинсталлировать! Для этого в главном меню Приложения войдите в Установка/удаление программ, найдите слева пункт Серверы и снимите птичку рядом с пунктом База данных PostgreSQL. Потом нажмите кнопку Применить и дождитесь завершения операции.

SELinux надо отключать: «Система-Администрирование-Уровень безопасности и межсетевой экран», закладка «Настройка SELinux»

Откройте папку и запускайте установки двойным щелчком в следующей последовательности:

Следующие компоненты являются опциональными:

В терминале запустите следующую команду консоли (перед этим команда su root должна уже быть исполнена):

LANG=ru_RU.utf-8 /etc/init.d/postgresql start

Если эта команда не выполнилась и в комментарии что-то написано про команду «InitDB», то

1. Удалите каталог /var/lib/pgsql/data/ (если он существует с помощью mc)

2. Переключитесь на пользователя «postgres» надо выполнить: su postgres

3. Выполните команду initdb –D /var/lib/pgsql/data/

Эта команда помимо прочего заполнит папку /var/lib/pgsql/data/ умолчальными настройками.

gedit /var/lib/pgsql/data/postgresql.conf или «F4» в mc

Откроется редактор. Найдите по Ctrl-F или F7 и измените там следующие параметры:

Рекомендуется увеличить значение параметра effective_cache_size в конфигурационном файле postgresql.conf. Значение этого параметра рекомендуется устанавливать не менее половины объема оперативной памяти установленной на компьютере.

Сохраните файл и закройте редактор.

В файле, открываемом командой

host all all 127.0.0.1/32 trust

host all all 0.0.0.0/0 md5

Эти параметры вы сможете отконфигурировать позднее (имеет смысл в целях безопасности ограничить подключения, например, только локальным хостом localhost), когда убедитесь, что всё (включая клиента 1С) работает.

Теперь перезапустите сервер PostgreSQL:

Если сервер PostgreSQL не стартует, то проблемы следует искать в лог-файле. Лог-файлы PostgreSQL находятся в каталоге /var/lib/pgsql/data/pg_log. Просмотр лог-файлов можно выполнять с помощью команды «cat», формат: cat имя_файла

Войдите в консоль PostgreSQL командой:

psql -h localhost postgres postgres или psql -h 127.0.0.1 postgres postgres

(Формат команды psql –h имя_хоста имя_базы имя_пользователя)

и добавьте строку:

Теперь консоль должна запуститься. Введите пароль postgres (ввод пароля не отмечается ни буквами, ни звёздочками).

Если Вам не удается подключиться к консоли PostgreSQL по причине того что не подходит пароль, то в файле /var/lib/pgsql/data/pg_hba.conf для строки:

host all all 127.0.0.1/0 md5

необходимо «md5» поменять на «trust» (убедитесь что строка раскомментирована) и перезапустить сервер PostgreSQL

Теперь консоль должна запуститься без требования пароля.

При первом запуске PostgreSQL создаётся учётная запись postgres с паролем postgres. Первое, что надо сделать в консоли – сменить этот пароль командой:

ALTER USER postgres PASSWORD 'your_new_password';

В версии 8.2 PostgreSQL пароль по умолчанию уже почему-то не «postgres», поэтому что бы не путаться лучше изменить его на «postgres»:

ALTER USER postgres PASSWORD 'postgres';

По окончании работы с консолью PostgreSQL следует выполнить команду:

Если в файле /var/lib/pgsql/data/pg_hba.conf Вы меняли «MD5» на «trust», то можно выполнить обратную замену, (если доступ к консоли сервера ограничен, то можно не делать) перезапустить сервер PostgreSQL и проверить подключение к консоли с помощью измененного Вами пароля

По команде «ps -aux» процесс в списке называется «postmaster», запущен от имени «postgres».

По команде netstat -na|grep tcp в списке должны быть строка:

tcp 0 0 0.0.0.0: 5432 0.0.0.0:* LISTEN

Проверьте подключение к серверу PostgreSQL с другого компьютера сети с помощью «PGAdmin»

Для автоматического запуска SQL сервера при старте системы необходимо выполнить команды:

chkconfig --add postgresql

chkconfig postgresql on

chkconfig --list для проверки

Создание базы данных

Установите на клиентскую Windows-машину клиента 1С v8.1 со средствами доступа к серверу предприятия 1С.

Если для опредения URL адресов в локальной сети используется сервер DNS, то в его базу необходимо внести информацию о сервере, иначе пропишите сервер на каждом клиенте в файл %SYSTEMROOT%\system32\drivers\etc\hosts. Его можно отредактировать, например, блокнотом, добавив строку, подобную этой:

где 192.168.1.1 – это IP-адрес линукс-сервера, а centos – его имя. Не пренебрегайте этим шагом, так как доступ к серверу из оснастки просто по IP-адресу весьма затруднителен.

Проверьте что сервер доступен по имени. С клиентского компьютера выполните команду:

Также проверьте что выполняется обратное определение для имени сервера. С клиентского компьютера выполните:

В заголовке результата этой команды должно быть имя сервера «Centos».

Запустите оснастку управления серверами предприятия из меню Пуск – 1С Предприятие 8.1 – Серверы 1С Предприятия. Создайте центральный сервер правым щелчком.

Создайте пустую БД из консоли кластера

Если при создании базы возникает ошибка «11004»:

Ошибка соединения с рабочим процессом

server_addr=tcp://localhost.localdomain:1563 descr=Ошибка сетевого доступа к серверу

(Windows Sockets-11004(0x00002AFC). Затребованное имя допустимо и оно найдено в базе данных, но для имени отсутствуют связанные с ним данные, которые были разрешены для него.) line=546 file=.\scr\DataExchangeTcpClientImpl.cpp

То решения следующие:

1. Проверить имя сервера: Центральные серверы 1С Предпрития – Сервер – Кластеры – 1541 – Рабочие серверы – Имя сервера. Если имя сервера 1С отличается от сетевого имени сервера, то необходимо изменить имя сервера 1С. (описано в конце установки сервера 1С)

2. IP-адреса имени и . выполняется по разному. Проверить:

- как задано имя сервера 1С:Предприятия при регистрации ИБ на клиентском приложении?

- выполняется ли ping по этому имени и определяется ли IP адрес?

- совпадает ли IP адрес с тем, который выдает ping из того же домена?

3. Отстутствует имя компьютера центрального сервера в DNS или в файле C:\WINNT\system32\drivers\etc\hosts

- попробуйте имя сервера внести в файл hosts на проблемном компьютере, указав ему IP адрес, вырываемый ping-ом с компьютера, на котором 1С:Предприятие стартует нормально.

4. Нет прав на сервер

Войдите в конфигуратор пустой базы и загрузите *.dt

Если при загрузке *.dt в пустую базу возникли проблемы связанные с региональными установками, то в исходной базе необходимо изменить региональные установки «Администрирование – Региональные установки информационной базы» и выгрузить *.dt еще раз.

Резервное копирование и восстановление

Выполнить резервное копирование и восстановление можно из консоли «pgAdmin III». В контекстном меню на выделенной базе данных есть пункты «Резервная копия…» и «Восстановить…»

Postgres обеспечивает две утилиты для резервного копирования системы: pg_dump для резервного копирования индивидуальных баз данных и pg_dumpall для резервного копирования установки за один шаг.

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

% pg_dump dbname > dbname.pgdump

и восстановить с помощью

cat dbname.pgdump | psql dbname

Эта техника может быть использована для перемещения базы данных в новое место, и для переименования существующих баз данных.

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

Так как pg_dump пишет в stdout, ты можешь использовать стандартные утилиты *nix для работы над этой возможной проблемой:

Используй сжатие при сбросе:

% pg_dump dbname | gzip > filename.dump.gz

восстановив с помощью

% gunzip -c filename.dump.gz | psql dbname

% cat filename.dump.gz | gunzip | psql dbname

% pg_dump dbname | split -b 1m - filename.dump.

восстановив с помощью

% cat filename.dump.* | pgsql dbname

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

Для резервного копирования по расписанию я рекомендую следующий код:

pg_dump dbname > /путь/dbname.pgdump

tar czf /путь/pgdump-`date +%d.%m.%y`.tgz /путь/dbname.pgdump

вторая строчка отвечает за создание архива, с именем pgdump -текущая_дата.tgz
таким образом вы получаете ежедневную копию баз Postgres и можете откатится на любой день.

Этот код можно добавить в cron двумя путями:
1) создать текстовый файл в директории /etc/cron.daily/ , скопировать туда код и сделать его исполняемым (chmod +x имя_файла)

2) использовать crontab -e для редактирования расписания cron.
туда нужно ввести:

0 0 * * * pg_dump dbname > /путь/dbname.pgdump;tar czf /путь/pgdump-`date +%d.%m.%y`.tgz /путь/dbname.pgdump

и сохранить файл.

Стандартное расположение резервных копий PostgreSQL:

Если необходимо выполнять резервное копирование сразу нескольких баз (например двух), то в каталог /etc/cron.daily/ можно поместить текстовый файл с именем «pgdump» следующего содержания:

pg_dump --host=localhost --username=postgres ZUP > /var/lib/pgsql/backups/ZUP.pgdump;tar czf /var/lib/pgsql/backups/ZUP-`date +%y.%m.%d`.tgz /var/lib/pgsql/backups/ZUP.pgdump;pg_dump --host=localhost --username=postgres BU > /var/lib/pgsql/backups/BU.pgdump;tar czf /var/lib/pgsql/backups/BU-`date +%y.%m.%d`.tgz /var/lib/pgsql/backups/BU.pgdump

Если команда просит ввести пароль, то в файле /var/lib/pgsql/data/pg_hba.conf для строки:

host all all 127.0.0.1/0 md5

измените «md5» на «trust» (не забудьте убрать комментарий) и перезапустите сервер Postgres

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

Каждые сутки будет выполняться резервное копирование баз ZUP и BU в каталог /var/lib/pgsql/backups/. Также резервные копии будут архивироваться в файлы с именами, содержащими дату резервного копирования.

Расписание выполнения файлов из каталогов /etc/cron.*/ находится в файле /etc/crontab

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

Если необходимо восстановить в новую базу, то необходимо ее сначала создать:

createdb –h localhost dbname

Собственно команды для восстановления:

% tar xzf filename.tgz

В результате будет распакован файл: «dbname.pgdump». Будьте внимательны! Архив может быть распакован с учетом путей, начиная с текущего каталога. Если так случилось, файл «dbname.pgdump» надо переместить в текущий каталог.

% cat dbname.pgdump | psql –h localhost dbname postgres

Ввести пароль для postgres…

Основным средством физического и аналитического сопровождения баз данных в PostgreSQL является команда SQL VACUUM и ее аналог — сценарий vacuumdb. Оба средства выполняют две общие функции:

· удаление всех данных, оставшихся в результате отмены транзакций и других операций, оставляющих временные данные;

· анализ операций с базами данных, по результатам которого PostgreSQL конструирует более эффективные запросы.

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

Создать текстовый файл с именем «vacuumdb» в директории /etc/cron.daily/ , скопировать туда код:

vacuumdb –h localhost –U postgres –W postgres –a –z -v

vacuumdb –h localhost –U postgres –a –z -v

Сделать этот файл исполняемым (chmod +x имя_файла)

Каждую ночь будет выполняться оптимизация всех баз данных

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

Приложение 1. Некоторые команды консоли Linux

Запуск консоли осуществляется: «Приложения – Стандартные - Терминал»

«cd» - переход по каталогам

«ls» просмотр содержимого каталога

«cat имя_файла» просмотр содержимого текстового файла (удобно просматривать файлы логов)

gedit – редактирование текстового файла

Вместо этих команд удобней использовать «mc» - аналог «Norton Commander»

«su» - переключение между пользователями или вход в режим root

«top –u ИмяПользователя» выводит список процессов пользователя, показывает использование процессора и памяти

«ps -aux» выводит список всех процессов

«kill НомерПроцесса» убивает указанный процесс

«cat /proc/version» - покажет версию дистрибутива Linux

«cd /media/имя_флешки» - переход в каталог флешки

/etc/grub.conf – файл конфигурации загрузчика GRUB – можно указать чтобы по умолчанию загружался Windows, если установлено две системы.

Приложение 2. Назначение IP портов

1540 – порт центрального сервера кластера, процесс «ragent»

1541 – порт первого рабочего сервера кластера, процесс «ragent»

Установка Платформы «1С:Предприятие» в ОС Linux

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

Сервер «1С:Предпритие» 64-bit версии 8.3.13.1644. Пакеты для установки доступны здесь:

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

Если в дальнейшем работа с сервером «1С:Предприятие» на Linux и управление будет осуществляться c других машин, необходимо убедиться в том, что ip-адрес компьютера, на котором расположен сервер, будет корректно разрешаться в его hostname. Откроем консоль сервера от имени пользователя root и получим адрес компьютера:

Имя компьютера можно получить так:

Теперь данные о соответствии ip-адреса и имени необходимо внести в файлы hosts тех машин, откуда будут устанавливаться соединения с кластером серверов:

Для Windows он расположен обычно:

В противном случае при установке клиентского соединения с рабочим процессом кластера будет возникать ошибка.

Установка платформы в Debian-системах на примере Ubuntu Server 16.04

Откроем консоль сервера от имени пользователя root.
Создадим директорию, куда поместим (любым удобным образом) архив с Deb-пакетами для установки Сервера 1С:Предприятие, скачанный предварительно.

Войдем в каталог /1c/soft/1с:

Распакуем архив (при помощи команды tar xzf):

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

Устанавливаем сервер «1С:Предприятие»:

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

Установка будет осуществлена в директорию /opt/1C/v8.3/x86_64.

Для корректной работы приложений необходимо установить шрифты из состава Microsoft Core Fonts:

Для того, чтобы система «увидела» установленные шрифты, нужно выполнить команду:

Устанавливаем дополнительные внешние библиотеки:

Запускаем службу:

Проверить статус работы можно при помощи команды:

Будет выполнена проверка, запущен ли сервис (Starting 1C:Enterprise 8.3 server: OK), и выведено детальное состояние сервиса.

Проверить, запущены ли процессы кластера, можно при помощи команды:

Перейдем к установке драйвера HASP. Для данного примера скачиваем драйвер по адресу:

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

Создадим каталог /1c/soft/hasp:

В этот каталог любым удобным образом поместим скачанный пакет установки драйвера и перейдем в него:

Поскольку драйвер использует 32-битные библиотеки, устанавливаем их:

Устанавливаем драйвер:

Запускаем драйвер защиты HASP:

Проверить статус можно так:

Установка платформы в RPMS на примере CentOS 7

Откроем консоль от имени root.
Создадим директорию, куда поместим (любым удобным образом) архив с RPM-пакетами для установки Сервера 1С:Предприятие, скачанный предварительно.

Перейдем в директорию /1c/soft/1с

tar xzf rpm64_8_3_13_1644.tar.gz

В данном примере будут установлены все пакеты, но, если в вашей системе не планируется использовать языки, отличные от русского и английского, nls-пакеты вы можете не устанавливать - они содержат только языковые файлы.

Для пакетов x86_64 установка будет осуществлена в директорию /opt/1C/v8.3/x86_64.

Для корректной работы приложений необходимо установить шрифты из состава Microsoft Core Fonts.

Скачиваем любым удобным образом (например, при помощи wget) файлы пакета с сервера SourceForge:

Надо скачать все .exe-файлы, кроме wd97vwr32.exe.

Переименовываем все скачанные .exe-файлы, присвоив им расширение .zip, после чего распакуем их и удалим все, кроме имеющих расширение .ttf – это файлы шрифтов.
Файлы шрифтов (.ttf-файлы) копируем в каталог /usr/share/fonts/truetype/

Для того, чтобы система «увидела» установленные шрифты, нужно выполнить команду:

Устаналиваем дополнительные внешние библиотеки:

Запускаем службу:

Проверить статус работы можно при помощи команды:

Будет выполнена проверка, запущен ли сервис (Starting 1C:Enterprise 8.3 server: OK), и выведено детальное состояние сервиса.

Проверить, запущены ли процессы кластера, можно при помощи команды:

Перейдем установке драйвера HASP. Для данного примера скачиваем драйвер по адресу :

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

Создадим каталог /1c/soft/hasp:

В этот каталог любым удобным образом поместим скачанный пакет установки драйвера и перейдем в него:

Поскольку драйвер использует 32-битные библиотеки, устанавливаем их:

Устанавливаем драйвер:

Запускаем драйвер защиты HASP:

Проверить статус можно так:

Основные проблемы и вопросы по установке Платформы «1С:Предприятие» в Linu x

1. При работе возникают ошибки «Не найдена библиотека …»

В зависимости от вашего дистрибутива Linux и функционала системы для корректной работы 1С:Предприятие вам может понадобиться дополнительно самостоятельно установить внешние библиотеки. Полный список их представлен в документации:

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

2. Как запустить сервер в режиме отладки?

Для того, чтобы на сервере была доступна отладка, необходимо запустить его в ключом –debug. Для этого сначала остановим сервер "1С:Предприятие":

ВАЖНО! Не редактируйте параметры запуска сервера в процессе его работы, это может привести к ошибкам при его перезапуске.

Теперь необходимо отредактировать параметры его запуска в конфигурационном файле srv1cv83 (в данном примере с использованием редактора vim):

Сохраняем изменения и выходим из файла.

Перезапускаем сервер «1С:Предприятия 8»:

3. Где находится каталог данных кластера серверов и как его изменить?

По умолчанию каталог кластера находится в директории пользователя, от имени которого запущен сервер 1С:Предприятие - $HOMEDIR/.1cv83/1C/1Cv83, например:

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

ВАЖНО! Не забудьте убедиться в наличии прав на директорию данных кластера у пользователя, от имени которого запущен сервер. Увидеть права можно при помощи команды:

Предоставить права можно так:

В конфигурационном файле /etc/sysconfig/srv1cv83 также задаются порты, на которых будут работать процессы кластера, и другие параметры запуска.

4. Как настроить технологический журнал сервера в Linux ?

На сервере создадим каталоги, в который будут помещаться файлы журнала:

Создадим каталог для настроек журнала /opt/1C/v8.3/x86_64/conf:

Поместим в этот каталог файл logcfg.xml со следующим (например) содержимым:

В данном случае собирается полный технологический журнал (не стоит делать так на постоянной основе в продуктиве), срок хранения файлов журналов - 24 часа, находиться они будут в директории /var/log/1c/logs.

ВАЖНО! Необходимо предоставить пользователю, от имени которого работает сервер 1С:Предприятие, права на запись в каталог логов. Например, так:

Единый дистрибутив 1С:Предприятие для Linux. Установка сервера

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

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

Новый способ предусматривает поставку в виде универсального run-файла, который содержит клиентскую и серверную часть, дополнительные компоненты и подходит как для RPM, так и для DEB-систем. Установка при этом производится в обход пакетного менеджера и слабо поддается контролю со стороны администратора. Если для клиентских систем это несущественно, то на серверах многие админы предпочитают держать руку на пульсе любых изменений системы.

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

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

В нашем примере мы будем устанавливать сервер 1С:Предприятие на Ubuntu 20.04 LTS и Debian 10, однако данная инструкция одинаково пригодна для любого поддерживаемого платформой Linux-дистрибутива с поправками на работу с пакетным менеджером. Все приведенные ниже команды следует выполнять с правами суперпользователя.

Начнем с установки требуемых зависимостей. Их немного, это набор шрифтов Microsoft True Type Core Fonts и библиотека UnixODBC, для работы через одноименный интерфейс.

В Debian для этого следует подключить репозитории с несвободным ПО, для этого откройте /etc/apt/sources.list и добавьте после main в каждую строку contrib и non-free.

Обновим список пакетов и установим зависимости:

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

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

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

В контексте серверного применения нам могут быть интересны:

server - кластер серверов 1С:Предприятия
server_admin - сервер администрирования кластера серверов 1С:Предприятия
liberica_jre - Java Runtime Environment (JRE)
config_storage_server - сервер хранилища конфигураций
ws - модули расширения веб-сервера

С полным списком опции можно ознакомиться в официальной документации.

Допустим, мы хотим установить кластер серверов 1С:Предприятие и модуль расширения веб-сервера, для этого запустим инсталлятор со следующими ключами:

Начиная с платформы 8.3.18, когда появилась возможность одновременной установки нескольких версий на платформе Linux инсталлятор не производит автоматическую регистрацию службы. Это нужно сделать самостоятельно. Для этого скопируем, точнее сделаем символические ссылки для скрипта запуска и файла конфигурации. В настоящий момент 1С:Предприятие продолжает использовать подсистему инициализации init, переход на systemd планируется в платформе 8.3.21.

Затем добавим ее в автозагрузку:

Управлять службой можно как "по старинке":

Так и через systemd:

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

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

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

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

При обновлении платформы вам потребуется:

Остановить службу
Установить новую платформу
Удалить старую
Обновить символические ссылки на скрипт запуска и конфигурации
Запустить службу

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

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