Содержание
Установка 1С:Предприятие 8.3 на Debian 10
Установка PostgreSQL Pro для 1С
Настройка PostgreSQL для работы с 1С
Установка и настройка HASP Licence manager
Обслуживание баз 1С на сервере PostgreSQL
Проверка бэкапов postgresql баз
Выгрузка баз 1С в dt из командной строки Linux
Введение
Сервер 1С не умеет работать со стандартной версией PostgreSQL. Её нужно патчить. Существует как минимум 2 версии postgresql с патчами для запуска 1С:
- PostgreSQL Pro – https://1c.postgres.ru.
- Версия от фирмы 1С. Установочный файл обычно называется Дистрибутив СУБД PostgreSQL для Linux x86 (64-bit) одним архивом. Скачать можно только с портала https://releases.1c.ru имея актуальную учетную запись.
Я всегда в своей практике использовал версию от postgresql pro, так как она обновляется быстрее и проще скачать. С ней как правило меньше проблем. Я лично вообще не сталкивался с ними, так что могу рекомендовать именно эту версию.
Используя Linux сервер для установки 1С вы экономите деньги на следующих лицензиях:
- Microsoft Windows Server.
- Microsoft SQL Server.
- Клиентский доступ к MS SQL Server.
Вам понадобится приобрести только лицензию на сам 1С сервер. А операционная система Linux и БД PostgreSQL бесплатны. Более подробно стоимость лицензий и их подбор я рассматривал в своем телеграм канале отдельной заметкой. Там же есть полезные комментарии в обсуждениях на этот счет.
Если вы в данный момент используете файловые базы, но их производительность вас не устраивает, посмотрите мою статью про ускорение файловых баз 1С. Возможно вам удастся немного отсрочить момент перехода на клиент-серверную версию, так как это сопряжено с дополнительными расходами. Причем расходы будут как на начальную покупку лицензий и железа, так и на последующее сопровождение. Иногда можно обойтись без них.
В этой статья я всё буду настраивать на базе дистрибутива Debian 10.
Если у вас еще не настроен сервер с Debian, рекомендую мои материалы на эту тему:
Далее переходим к самой настройке 1С. Если у вас нет отдельной серверной и сервера под это дело, то удобнее арендовать dedic, например, у Selectel. Для комфортной работы с 1С средней компании хватит бюджетного дедика за 4000-5000 р. в месяц.
Установка 1С:Предприятие 8.3 на Debian 10
Начнем нашу настройку с установки сервера 1С. Для этого нам надо установить дополнительные пакеты в систему, которые находятся в разделах системного репозитория contrib и non-free. Их нужно добавить в конфиг репозиториев Debian. Для этого редактируем файл /etc/apt/sources.list и приводим его примерно к следующему виду:
deb http://mirror.yandex.ru/debian buster main contrib non-free deb-src http://mirror.yandex.ru/debian buster main contrib non-free deb http://mirror.yandex.ru/debian buster-updates main contrib non-free deb-src http://mirror.yandex.ru/debian buster-updates main contrib non-free deb http://security.debian.org/ buster/updates main contrib non-free deb-src http://security.debian.org/ buster/updates main contrib non-free
Сами адреса репозиториев у вас могут быть другие. Выполняем обновление списка пакетов:
# apt update
Теперь устанавливаем нужные для работы 1С в linux пакеты. Начнем со шрифтов mscorefonts.
# apt install ttf-mscorefonts-installer
Установка будет идти достаточно долго, так как скачивается целая куча дополнительных пакетов и файлов.
Добавляем еще несколько необходимых пакетов:
# apt install imagemagick unixodbc sudo curl
Следующий важный этап подготовки к установке сервера 1С – настройка локали. Для этого выполняем команду в терминале:
# dpkg-reconfigure locales
Нам нужно выбрать ru_RU.UTF-8 UTF-8. Так же убедитесь на всякий случай, что en_US.UTF-8 тоже выбрана. В дефолте так и должно быть, но я сталкивался с ситуациями, когда эту локаль тоже приходилось добавлять.
По умолчанию выбираем ее же – ru_RU. После того, как вы разлогинитесь из системы и зайдёте снова, у вас в консоли будет русский язык. Немного непривычно с ним работать, но придется потерпеть это неудобство.
Теперь нам необходимо скачать deb пакеты сервера с портала 1С. Для этого логинимся под действующей учетной записью на https://releases.1c.ru и скачиваем файл Cервер 1С:Предприятия (64-bit) для DEB-based Linux-систем.
Имя файла будет deb64_8_3_19_1150.tar.gz. Его нужно передать на Debian сервер. Я обычно winscp для этого использую. Распаковываем архив в отдельную директорию.
# mkdir 1c-server # mv deb64_8_3_19_1150.tar.gz 1c-server/ # cd 1c-server/ # tar xzvf deb64_8_3_19_1150.tar.gz # rm deb64_8_3_19_1150.tar.gz
Вы получите список распакованных пакетов для сервера 1С.
# ls -lh итого 470M -rwxrwxrwx 1 1001 1001 29M июн 2 03:27 1c-enterprise-8.3.19.1150-common_8.3.19-1150_amd64.deb -rwxrwxrwx 1 1001 1001 8,9M июн 2 03:27 1c-enterprise-8.3.19.1150-common-nls_8.3.19-1150_amd64.deb -rwxrwxrwx 1 1001 1001 31K июн 2 03:27 1c-enterprise-8.3.19.1150-crs_8.3.19-1150_amd64.deb -rwxrwxrwx 1 1001 1001 323M июн 2 03:27 1c-enterprise-8.3.19.1150-server_8.3.19-1150_amd64.deb -rwxrwxrwx 1 1001 1001 110M июн 2 03:27 1c-enterprise-8.3.19.1150-server-nls_8.3.19-1150_amd64.deb -rwxrwxrwx 1 1001 1001 311K июн 2 03:27 1c-enterprise-8.3.19.1150-ws_8.3.19-1150_amd64.deb -rwxrwxrwx 1 1001 1001 22K июн 2 03:27 1c-enterprise-8.3.19.1150-ws-nls_8.3.19-1150_amd64.deb drwxr-xr-x 3 root root 4,0K июн 7 23:01 license-tools
Если вы в 1С используете только русский или английский язык, то пакеты с добавлением в имени nls вам не нужны. А все остальное устанавливаем.
# dpkg -i 1c-enterprise-8.3.19.1150-common_8.3.19-1150_amd64.deb 1c-enterprise-8.3.19.1150-server_8.3.19-1150_amd64.deb 1c-enterprise-8.3.19.1150-ws_8.3.19-1150_amd64.deb
Не забудьте изменить версию платформы в имени файла на свою.
Запускаем Сервер 1С на Debian:
# systemctl start srv1cv83
Если получили ошибку: “Failed to enable unit: Unit file srv1cv83.service does not exist.“, значит при установке пакета не был добавлен init скрипт для запуска сервера. Сделаем это вручную, создав символьную ссылку:
# ln -s /opt/1cv8/x86_64/8.3.19.1150/srv1cv83 /etc/init.d/srv1cv83 # systemctl daemon-reload
После этого запускаем сервер 1С еще раз той же командой выше. Ошибки теперь быть не должно.
Проверим, все ли службы запустились:
# netstat -tulnp | grep "rphost\|ragent\|rmngr"
Всё на месте. Если у вас включен Firewall на сервере, не забудьте открыть указанные порты. Данная настройка не относится к тематики статьи, так что я ее опускаю.
На этом установка самого Сервера 1С закончена. Переходим к установке и настройке базы PostgreSQL для него.
Установка PostgreSQL Pro для 1С
Для работы с 1С в PostgreSQL необходимо внести некоторые изменения в виде патчей. Существует несколько редакций этих патчей, но наиболее известные две:
- От самой 1С.
- От компании PostgreSQL Pro.
Я не берусь судить сам, какая сборка PostgreSQL для 1С будет лучше. Я всегда использую от Postgresql Pro. Эта компания активно участвует в разработке самого движка БД, так что компетенций у нее достаточно. Есть мнение, что эти сборки лучше, чем от 1С. К тому же в последних версиях, я заметил, что эти сборки автоматически настраивают конфиг postgresql под параметры памяти и процессоров вашего сервера. Не нужно это делать потом вручную.
Загрузить PostgreSQL Pro для 1С можно по ссылке – https://1c.postgres.ru. Для этого ответьте на 3 вопроса установщика и в конце укажите вашу почту. Туда придёт инструкция по установке.
Инструкция достаточно простая. Подключаем репозитории postgresql:
# curl -o apt-repo-add.sh https://repo.postgrespro.ru/pg1c-13/keys/apt-repo-add.sh # sh apt-repo-add.sh
Устанавливаем базу данных:
# apt-get install postgrespro-1c-13
База данных запустилась автоматически, добавляем её в автозагрузку:
# systemctl enable postgrespro-1c-13
Проверьте статус сервиса postgrespro-1c-13. Он должен быть запущен.
# systemctl status postgrespro-1c-13
Далее переходим к настройке postgresql.
Настройка PostgreSQL для работы с 1С
Первым делом зададим пароль внутреннего пользователя postgers, под которым будет работать сервер 1С.
# sudo -u postgres /usr/bin/psql -U postgres -c "alter user postgres with password 'postgrespwd';" ALTER ROLE
Далее перенесём хранение временной статистики с жёсткого диска в память. Это немного увеличит быстродействие и сократит износ ресурса SSD диска. Эта статистика постоянно перезаписывается. Подробнее об этом я писал в своей заметке в telegram. В документации postgresql указано, что статистику без проблем можно перенести в RAM.
По умолчанию под статистику расходуется порядка 25 мегабайт дискового пространства. Я решил перенести ее на ram диск размером 512M. Занимать в памяти место будет только реально используемый объем, так что не стоит опасаться пустого расхода оперативной памяти.
Для начала создаем директорию, куда будем мапить виртуальный диск:
# mkdir /var/lib/pgsql_stats_tmp # chown postgres:postgres /var/lib/pgsql_stats_tmp
Теперь добавляем в /etc/fstab в самый конец еще одну строку (не забудьте в конце переход на новую строку поставить):
tmpfs /var/lib/pgsql_stats_tmp tmpfs size=512M,uid=postgres,gid=postgres 0 0
Монтируем диск в систему:
# mount /var/lib/pgsql_stats_tmp
Теперь идём в конфиг бд по пути /var/lib/pgpro/1c-13/data/postgresql.conf и меняем параметр:
stats_temp_directory = '/var/lib/pgsql_stats_tmp'
Перезапускаем postgresql:
# systemctl restart postgrespro-1c-13
Всё, перенесли статистику в оперативную память. В целом, больше ничего добавлять в конфигурацию PostgreSQL для её настройки работы с 1С не обязательно. Все и в таком виде будет нормально функционировать.
Создание баз 1С
Теперь идём на любую машину, где у вас установлена консоль администрирования 1С. Обычно её на какую-то виндовую машину ставят. Для этого надо скачать Технологическую платформу той же версии, что и установленный сервер 1С на Debian.
Во время установки обязательно выбрать компонент Администрирование сервера 1С.
После установки запускаем Администрирование серверов 1С Предприятия x86-64 и добавляем туда сервер 1С на Debian, который мы установили ранее. Можно по dns имени, если оно настроено, либо просто по ip.
Если получите ошибку: “Консоль управления (MMC) не может создать оснастку.“, то сделайте следующее.
Запустите командную строку с правами администратора. Это важно. И выполните там:
"C:\Program Files\1cv8\8.3.19.1150\bin\RegMSC.cmd"
Не забудьте поменять версию платформы на свою. После этого оснастка управления сервером 1С нормально заработает. Подключаем наш сервер на Debian.
Дальше всё управление выполняется как обычно. Создавайте новую базу. В качестве сервера БД указываем 127.0.0.1, пользователя postgres и пароль, который вы задали ранее.
Если получите ошибку “Ошибка соединения с рабочим процессом.” и дальше некоторые подробности сетевых проблем, то добавьте DNS запись или запись в файл hosts с именем и ip адресом вашего сервера 1С. Потом попробуйте создать базу снова. Так же эта ошибка может появляться, если включен и не настроен firewall. Вам как минимум нужно открыть порты tcp 1540, 1541, 1560.
После этого к базе можно подключиться обычной платформой и залить конфигурацию.
В целом, на этом настройка сервера 1С закончена. Дальше ставятся софтовые лицензии и начинается работа. Если у вас лицензия аппаратная, то необходимо установить и настроить HASP Licence manager.
Установка и настройка HASP Licence manager
Для того, чтобы компьютеры могли получать лицензии по сети от сервера, куда вставлен usb ключ, на него надо установить и запустить HASP Licence manager. Для начала вставьте ключ в сервер и проверьте, видит ли его система:
# lsusb | grep -i hasp
Вы должны увидеть устройство с именем наподобие Aladdin Knowledge Systems HASP copy protection dongle. Если его нет, то разбирайтесь с подключением и пробросом usb портов, если у вас это виртуальная машина.
Дальше идем на страницу https://download.etersoft.ru/pub/Etersoft/HASP/stable/x86_64/Debian/, выбираем свою версию системы и скачиваем два файла:
- haspd-modules_7.90-eter2debian_amd64.deb
- haspd_7.90-eter2debian_amd64.deb
На момент написания статьи пакетов для Debian 10 не было, но нам подойдут и для 9-й версии.
# wget https://download.etersoft.ru/pub/Etersoft/HASP/stable/x86_64/Debian/9/haspd-modules_7.90-eter2debian_amd64.deb # wget https://download.etersoft.ru/pub/Etersoft/HASP/stable/x86_64/Debian/9/haspd_7.90-eter2debian_amd64.deb
Устанавливаем пакеты haspd, но перед этим установим пару пакетов – make и libc6-i386, если они у вас отсутствуют:
# apt install make libc6-i386 # dpkg -i haspd*.deb
Запускаем службу haspd и добавляем в автозагрузку:
# systemctl start haspd # systemctl enable haspd
Проверяем, запустился ли hasp:
# netstat -tulnp | grep hasp tcp 0 0 0.0.0.0:1947 0.0.0.0:* LISTEN 2526/hasplmd udp 0 0 0.0.0.0:46563 0.0.0.0:* 2526/hasplmd udp 0 0 0.0.0.0:1947 0.0.0.0:* 2526/hasplmd udp 0 0 0.0.0.0:475 0.0.0.0:* 2517/hasplm udp 0 0 127.0.0.1:2790 0.0.0.0:* 2508/winehasp
Все в порядке. Теперь лицензии должны нормально работать, а клиенты их получать по сети.
Бэкап баз 1С на postgresql
Без регулярного автоматического бэкапа баз 1С невозможно себе представить эксплуатацию. Так что этим вопросом надо заняться в первую очередь после настройки сервера и добавления баз. Посмотрим, какие базы postgresql у нас существуют:
# sudo -u postgres psql -U postgres -l
Я создал две тестовые базы: buh30 и zup31. Их и будем бэкапить. Я для этого предлагаю использовать обычный pg_dump, а затем дамп сразу же сжимать архиватором pigz. Его отличительная особенность в том, что он умеет жать всеми ядрами процессора, а не только одним, как, к примеру, gzip. Более подробно про pigz я рассказывал в заметке.
В самом простом случае бэкап базы данных выглядит следующим образом:
# sudo -u postgres /usr/bin/pg_dump -U postgres buh30 | pigz > /mnt/backup/buh30.sql.gz
Если посмотреть на dump, то в случае успешного создания, в начале дампа будет строка:
-- PostgreSQL database dump
а в конце:
-- PostgreSQL database dump complete
В будущем эта информация нам понадобится для мониторинга создания бэкапов и получения уведомления, если дамп не завершился корректно.
Для того, чтобы бэкапить автоматически все базы сразу я предлагаю использовать простой скрипт.
#!/bin/bash
BASES=("buh30" "zup31")
#BASES=`sudo -u postgres /usr/bin/psql -U postgres -l | grep "_buh\|_zup" | awk '{print $1}'`
DATA=`date +"%Y-%m-%d_%H-%M"`
LOGS=/var/lib/pgpro/service_logs
BACKUPDIR=/var/lib/pgpro/backup
for i in ${BASES[@]};
do
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start backup $i" >> $LOGS/$DATA.log
sudo -u postgres /usr/bin/pg_dump -U postgres $i | pigz > $BACKUPDIR/$DATA-$i.sql.gz
echo "`date +"%Y-%m-%d_%H-%M-%S"` End backup $i" >> $LOGS/$DATA.log
done
В скрипте предложены 2 варианта указания списка баз для бэкапа:
- Последовательное перечисление.
- Бэкап всех баз, что имеют в своем названии _zup или _buh.
Я обычно ставлю некоторые метки в именах баз, чтобы потом было проще формировать списки для бэкапа. Например, все тестовые базы можно помечать в имени _test – company_buh30_test и потом исключать из списка бэкапа все базы с дополнением _test в названии. Либо просто все рабочие базы сразу именовать с приставкой _buh или _zup и по этому признаку их выводить в список.
Для работы скрипта в таком виде, не забудьте создать каталоги:
# mkdir -p /var/lib/pgpro/service_logs # mkdir -p /var/lib/pgpro/backup
И еще важно учесть, что так как в скрипте мы запускаем команды от системного пользователя postgres, необходимо, чтобы у него был доступ к скрипту, когда добавите его в планировщик.
На выходе у вас получится примерно такой список бэкапов баз 1С из postgresql.
В дальнейшем мы их будем забирать отсюда и удалять.
Обслуживание баз 1С на сервере PostgreSQL
В качестве обслуживания баз 1С на сервере PostgreSQL я предлагаю регулярно запускать следующие процедуры:
- Чистку базы данных – vacuumdb.
- Перестройку индексов – reindexdb.
Я не буду подробно расписывать для чего всё это нужно. Эта информация без проблем ищется в интернете. Сразу даю готовый скрипт для обслуживания всех баз 1С. Список формируется по аналогии со скриптом для бэкапа – либо вручную, либо по какому-то признаку.
#!/bin/bash
BASES=("buh30" "zup31")
#BASES=`sudo -u postgres /usr/bin/psql -U postgres -l | grep "_buh\|_zup" | awk '{print $1}'`
DATA=`date +"%Y-%m-%d_%H-%M"`
LOGS=/var/lib/pgpro/service_logs
BACKUPDIR=/var/lib/pgpro/backup
for i in ${BASES[@]};
do
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start vacuumdb $i" >> $LOGS/$DATA.log
sudo -u postgres /usr/bin/vacuumdb --full --analyze --username postgres --dbname $i
echo "`date +"%Y-%m-%d_%H-%M-%S"` End vacuumdb $i" >> $LOGS/$DATA.log
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start reindexdb $i" >> $LOGS/$DATA.log
sudo -u postgres /usr/bin/reindexdb --username postgres --dbname $i
echo "`date +"%Y-%m-%d_%H-%M-%S"` End reindexdb $i" >> $LOGS/$DATA.log
echo "=========================================" >> $LOGS/$DATA.log
done
Я обычно запускаю этот скрипт по ночам сразу после выполнения бэкапа. Имейте ввиду, что подобное обслуживание может занимать много времени, которое будет зависеть от размера баз и производительности сервера. Убедитесь, что с базами никто не работает в часы обслуживания. Если в будни это сложно отследить, так как могут выполнять какие-то работы программисты 1С или обслуживающий персонал, то перенесите выполнение раз в неделю в какой-то выходной день.
Проверка бэкапов postgresql баз
То, что вы настроили дамп баз 1С, еще не значит, что у вас успешно работает бэкап. Дампы надо обязательно проверять. Я для этого использую еще один подобный сервер. Обычно просто клонирую виртуальную машину после того, как полностью её настрою. Тут встает вопрос лицензионности. Сервер 1С на Linux не просит на себя лицензию до какого-то числа пользователей. Точно не помню сколько их может быть, так как в проде всегда покупается лицензия. А вот клон запускается без лицензии только для проверки бэкапов. Пользователи к нему не подключаются. Не уверен, что такая схема эксплуатации допускается без приобретения лицензии, так что используйте её на свой страх и риск.
Как я уже сказал, делается копия рабочего сервера. На нём создаются те же самые базы 1С через панель администрирования. Далее мы на этот сервер забираем дампы с прода. Я это делаю с помощью rsync:
# rsync -av --progress --files-from=<(ssh root@10.20.1.30 '/usr/bin/find /var/lib/pgpro/backup -type f -mtime -1 -exec basename {} \; | egrep -v timestamp') root@10.20.1.30:/var/lib/pgpro/backup/ /data/backup/
Тут немного замороченная конструкция получилась. Смысл её в том, что нам надо забрать дампы только за последние сутки, поэтому список для копирования мы формируем на исходном сервере с помощью подключения туда по ssh. Подробно эту схему описал в отдельной заметке на канале. В моем примере timestamp это имя файла, который нам не надо копировать.
Эта команда оформляется в скрипт и регулярно запускается. Дальше работает следующий скрипт, который восстанавливает базы данных из дампов.
#!/bin/bash
BASES=("buh30" "zup31")
#BASES=`sudo -u postgres /usr/bin/psql -U postgres -l | grep "_buh\|_zup" | awk '{print $1}'`
BACKUP_DIR="/data/backup"
for i in ${BASES[@]};
do
echo "`date +"%Y-%m-%d_%H-%M-%S"` Drop database ${i}"
sudo -u postgres /usr/bin/dropdb -U postgres ${i}
echo "`date +"%Y-%m-%d_%H-%M-%S"` Create database ${i}"
sudo -u postgres /usr/bin/createdb -U postgres -T template0 ${i}
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start extract $i"
/usr/bin/find /data/backup -type f -name *${i}* -exec /usr/bin/unpigz '{}' \;
echo "`date +"%Y-%m-%d_%H-%M-%S"` End extract $i"
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start restore $i"
sudo -u postgres /usr/bin/psql -U postgres ${i} < ${BACKUP_DIR}/`ls ${BACKUP_DIR} | grep ${i}` 1>/dev/null
echo "`date +"%Y-%m-%d_%H-%M-%S"` End restore $i"
echo "`date +"%Y-%m-%d_%H-%M-%S"` rm dump ${i}"
/usr/bin/rm ${BACKUP_DIR}/`ls ${BACKUP_DIR} | grep ${i}`
done
Для каждой базы 1C в postgresql последовательно выполняются следующие действия:
- Удаление базы – dropdb.
- Создание базы – createdb.
- Распаковка дампа – unpigz.
- Восстановление базы из дампа.
- Удаление дампа.
Я не делаю тут никаких проверок на ошибки, так как далее у меня будет автоматическая выгрузка этих баз в dt и там я уже буду смотреть, всё ли в порядке. Если вы этого не будете делать, то обязательно следите за результатами работы этого скрипта, чтобы увидеть какие-то проблемы в процессе. Если с дампами всё в порядке, то восстановление пройдет штатно и никаких ошибок не будет.
Выгрузка баз 1С в dt из командной строки Linux
Для того, чтобы точно убедиться в валидности бэкапов баз 1С, настроим автоматическую выгрузку баз, восстановленных из них, в dt файлы. Если эта процедура пройдет успешно можно считать, что бэкапы живые.
Основная сложность тут будет в том, что у нас сервер без графического окружения и устанавливать его мне не хочется, так что будем обходиться без него. Нам нужно будет установить программу xvfb для запуска клиента 1С в консоли. А для ее работы нужен пакет libwebkitgtk-3.0-0, которого нет в репах для Debian 10.
Я долго возился с этой историей и никак не мог разрешить все зависимости для корректной работы xvfb. В итоге решил вопрос подключением репозитория от stretch. Для этого создаем файл /etc/apt/sources.list.d/stretch.list следующего содержания:
deb http://deb.debian.org/debian/ stretch main contrib non-free
После этого обновляем пакеты и ищем libwebkitgtk.
# apt update # apt search libwebkitgtk
Есть то, что нам нужно. Устанавливаем:
# apt install libwebkitgtk-3.0-0
Если все прошло успешно, то ставим дальше xvfb:
# apt install xvfb dbus-x11
Теперь нам нужно установить дистрибутив клиента 1С для Linux. Опять идём на сайт 1С и качаем «Клиент 1С:Предприятия (64-bit) для DEB-based Linux-систем».
После загрузки копируем архив на сервер, распаковываем и ставим клиента:
# tar xzvf client_8_3_19_1150.deb64.tar.gz # dpkg -i 1c-enterprise-8.3.19.1150-client_8.3.19-1150_amd64.deb
Теперь попробуем сделать выгрузку базы 1С в dt напрямую через консоль:
# xvfb-run -a /opt/1cv8/x86_64/8.3.19.1150/1cv8 CONFIG /DumpIB ~/buh30.dt /Out ~/out.log /S 10.20.1.30\\buh30 /N admin /P password /DumpResult ~/result.log
| /opt/1cv8/x86_64/8.3.19.1150/1cv8 | бинарник 1С, не забудьте изменить путь в соответствии со своей версией платформы |
| CONFIG | указываем, что используем конфигуратор |
| /DumpIB ~/buh30.dt | выгружаем базу в dt файл |
| /Out ~/out.log | лог записываем в отдельный файл |
| /S 10.20.1.30\\buh30 | путь к базе на сервере 1С |
| /N admin /P password | учетка для доступа к базе |
| /DumpResult ~/result.log | результат работы записываем в отдельный лог |
Если у вас всё получилось с первого раза, поздравляю. У меня редко так получается. То лицензию не найдет клиент, то учётка неверная, то еще что-то. Постоянно возникают какие-то накладки, а так как у тебя нет графического окружения, ты не можешь посмотреть, что происходит с клиентом 1С и почему он не выполняет выгрузку в dt. Но эту проблему можно решить. Установим x11vnc, подключим сервер в экрану xvfb и посмотрим, что там происходит.
# apt install x11vnc
Теперь снова запустим xvfb-run и подключимся к его экрану.
# xvfb-run -a /opt/1cv8/x86_64/8.3.19.1150/1cv8 CONFIG /DumpIB ~/buh30.dt /Out ~/out.log /S 10.20.1.30\\buh30 /N admin /P password /DumpResult ~/result.log
Посмотрим параметры, с которыми запустился xvfb:
# ps ax | grep xvfb-run 22027 pts/0 S+ 0:00 /bin/sh /usr/bin/xvfb-run -a /opt/1cv8/x86_64/8.3.19.1150/1cv8 CONFIG /DumpIB /root/buh30.dt /Out /root/out.log /S 10.20.1.30\buh30 /N Администратор /DumpResult /root/result.log 22037 pts/0 Sl+ 0:00 Xvfb :100 -screen 0 1280x1024x24 -nolisten tcp -auth /tmp/xvfb-run.uNVA1Y/Xauthority 22157 pts/2 S+ 0:00 grep xvfb-run
Я выделил жирным ту информацию, что для нас важна. Используем её для запуска vnc сервера:
# x11vnc -display :100 -bg -nopw -listen 10.20.1.30 -xkb -auth /tmp/xvfb-run.uNVA1Y/Xauthority
Если всё в порядке, то x11vnc сервер запустится на указанном адресе и порту. Не забудьте открыть его в firewall. Теперь можно подключиться любым vnc клиентом к нашему серверу и посмотреть, что там происходит с 1С. Авторизация не потребуется.
В моем случае все остановилось на окне логина. Я для примера специально указал несуществующую учётную запись, поэтому процесс выгрузки в dt не прошёл, а мы остались на моменте логина в систему. Таким образом вы можете отладить проблемы с подключением linux клиента 1C даже не имея полноценного графического окружения на сервере.
Если вы всё укажете верно, то выгрузка пройдёт корректно. На выходе у вас будет:
- dt файл с базой 1С
- out.log с информацией в нём в случае успеха: “Выгрузка информационной базы успешно завершена”
- result.log с информацией в нем в случае успеха: “0”
Записи в лог файлах можно использовать для мониторинга результатов выгрузки. Напомню, что я выгрузку в dt настроил на втором сервере, где тестируются бэкапы. Вы можете всё то же самое настроить и на боевом, если у вас есть потребность в сохранении .dt выгрузок через консоль в linux сервере. Это достаточно удобно для автоматизации. Можно не только дампы postgresql баз снимать, но подстраховываться 1сными выгрузками. Единственное, в чем будет проблема, если делать это на боевом – вам придётся всех выгонять из баз, иначе выгрузка не пройдет. На резервном сервере с этим проблем нет, так как там никто не работает, поэтому dt я выгружаю именно там и потом передаю их на бэкап сервер. Плюс, на этом сервере стоит во всех базах блокировка регламентных заданий.
В завершении этой темы приведу свой простой скрипт по автоматизации этого процесса:
#!/bin/bash
BASES_ZUP=`/usr/bin/psql -U postgres -l | grep "_zup" | awk '{print $1}'`
BASES_BUH=`/usr/bin/psql -U postgres -l | grep "_buh" | awk '{print $1}'`
BACKUP_DIR="/data/dt"
USER_ZUP="adminzup"
PASS_ZUP="passzup"
USER_BUH="adminbuh"
PASS_BUH="passbuh"
/usr/bin/rm -f /data/dt/*
for i in ${BASES_BUH};
do
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start export dt database ${i}"
/usr/bin/xvfb-run -a /opt/1cv8/x86_64/8.3.18.1363/1cv8 CONFIG /DumpIB ${BACKUP_DIR}/`date +"%Y-%m-%d_%H-%M-%S"`-${i}.dt /Out ${BACKUP_DIR}/`date +"%Y-%m-%d_%H-%M-%S"`-${i}-out.log /S 10.1.5.12\\${i} /N ${USER_BUH} /P ${PASS_BUH} /DumpResult ${BACKUP_DIR}/`date +"%Y-%m-%d_%H-%M-%S"`-${i}-result.log
echo "`date +"%Y-%m-%d_%H-%M-%S"` Finish export dt database ${i}"
done
for i in ${BASES_ZUP};
do
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start export dt database ${i}"
/usr/bin/xvfb-run -a /opt/1cv8/x86_64/8.3.18.1363/1cv8 CONFIG /DumpIB ${BACKUP_DIR}/`date +"%Y-%m-%d_%H-%M-%S"`-${i}.dt /Out ${BACKUP_DIR}/`date +"%Y-%m-%d_%H-%M-%S"`-${i}-out.log /S 10.1.5.12\\${i} /N ${USER_ZUP} /P ${PASS_ZUP} /DumpResult ${BACKUP_DIR}/`date +"%Y-%m-%d_%H-%M-%S"`-${i}-result.log
echo "`date +"%Y-%m-%d_%H-%M-%S"` Finish export dt database ${i}"
done
В моем примере все базы промаркированы в имени файла приставкой _zup или _buh. У каждого типа базы своя учётка для экспорта в dt. Перед началом экспорта я удаляю все старые выгрузки, которые лежат в директории, так как они уже уехали на бэкап сервер. Если вам не нужно ничего удалять, уберите этот код с rm. Разумно оставить этот запасной сервер и в качестве хранения бэкапов, так как тут они уже проверены. А при передачи их по сети есть шанс, что они побьются и их по хорошему надо будет еще раз проверять уже на месте окончательного хранения.
Мониторинг бэкапов 1С
Разберемся далее с тем, как нам мониторить бэкапы, чтобы быть уверенным в том, что у нас всё в порядке. Я тут использую многоступенчатый подход:
- Проверяю, что дамп 1с базы, сделанный напрямую из postgresql, завершился корректно.
- Слежу за экспортом в dt баз, восстановленных с дампов боевого сервера.
- Отправляю всё на бэкап сервер и слежу за тем, чтобы туда приехало всё, что должно приехать.
Статья уже получилась очень объемной, так что я не буду в ней раскрывать по шагам тему мониторинга, потому что всё это у меня уже описано в других статьях. Я дам на них ссылки и прокомментирую. Весь мониторинг настроен в Zabbix.
Мониторинг дампов postgresql баз делаем по аналогии с тем, как я описал мониторинг дампов mysql – https://serveradmin.ru/nastrojka-mysqldump-proverka-i-monitoring-bekapov-mysql/ Берём начало дампа и конец. Смотрим, есть ли там нужные строки, которые характеризуют корректность выполнения дампа. Если строки есть, значит всё ОК. Какие это строки, я указывал в разделе про создание дампов.
В этой же статье выше показано, как мониторить лог файл с результатами процесса. То есть берем логи с выгрузки в dt и анализируем их. Если нет необходимых нам строк, означающих, что все в порядке, срабатывает триггер в zabbix.
Информация по мониторингу бэкапов есть в моей статье – https://serveradmin.ru/monitoring-bekapov-s-pomoshhyu-zabbix/. Там рассмотрены различные подходы к этой процедуре. В рамках данной статьи я бы сделал следующие проверки:
- Создавал тестовый файл в директории источника бэкапов, а после передачи бэкапов на сервер для долгосрочного хранения там бы проверял, есть ли этот тестовый файл и какая у него дата создания. Его наличие и свежая дата будет означать, что процесс переноса данных прошел успешно и в запланированное время.
- Так же я бы следил за размером и датой создания самих дампов. Если размер ниже разумного или среднего за какой-то период, то выводил бы предупреждение.
Все это есть с примерами в статье, которую я привёл.
Заключение
Я рассмотрел практически все аспекты, связанные с разворачиваем Сервера 1С с базой PostgreSQL полностью на Linux сервере. Весь материал не гипотетический, а основанный на моем лично опыте подобных установок. Все примеры, скрипты, подходы взяты с работающих по этой схеме серверов. Поэтому нужно понимать, что описанная выше настройка не набор лучших практик, а мой субъективных опыт. Возьмите его себе на вооружение, но настройте всё так, как нужно именно вам и как вы считаете правильно. Если я что-то делаю неверно и можно сделать лучше, удобнее, поделитесь этим в комментариях.
В дополнение к данной статье будет полезна ссылка на публикацию баз 1С без графического окружения. В примере используется операционная система Centos, но для нашего случая с Debian всё будет аналогично практически один в один. Только веб сервер называется по-разному – там httpd, а здесь apache2.
Вообще, посмотрев на всё настроенное выше, может возникнуть вопрос, зачем вообще все это делать у себя? Нужно железо, администратор с хорошей квалификацией, который сможет всё это настроить и поддерживать. Проще купить готовый сервис и платить абонентскую плату. А всё остальное возьмет на себя сервис. На практике не всегда это получается удобнее и дешевле. С бэкапами и их проверкой всё равно придётся решать вопрос самостоятельно, потому что полностью доверить его людям со стороны может быть опасно.
Свежие комментарии