 |
|
|
|
Сетевая версия SQL под Linux. Перевод серверной части «1C:Предприятие 7.7»
Сетевая версия SQL под Linux Практика показывает, что при переходе компаний на использование Linux на своих компьютерах программное обеспечение бухгалтерии обычно становится камнем преткновения. Несмотря на то что продукт «1С:Предприятие 8» имеет больше возможностей работать под Linux [18], бухгалтеры средних и крупных фирм не спешат переходить с версии 7.7 на 8. Не дожидаясь светлого будущего, системные администраторы уже сейчас вынуждены запускать «1С:Предприятие 7.7» под Linux. Можно ответить, что существует много способов запуска «1С:Предприятие» под Linux, данная тема не раз обсуждалась на форумах [3, 4], а об одном из них было написано на страницах журнала [1], однако все эти способы описывают запуск клиентских приложений, оставляя в тени серверную часть. Получается, что переход на Linux осуществляется наполовину? Не совсем так. Давайте разберёмся, что же понимать под серверной частью и как её перевести под Linux? Локальную версию (не сетевую) мы не рассматриваем, так как этот случай тривиален. Сетевая версия «1С:Предприятия» может работать в двух режимах:
Небольшие фирмы обычно используют общие файлы. В качестве протокола обмена используется SMB или CIFS. В Windows поддержка этих протоколов выглядит как использование «Сетевого окружения», а в Linux используется пакет Samba. По мере роста базы и увеличения числа одновременно работающих бухгалтерских работников в системе фирмы сталкиваются с тем, что при общем хранении файлов операции, ранее выполнявшиеся за 10-15 секунд, требуют нескольких минут ожидания. Связано это с неоптимальной организацией базы, что приводит к возникновению множества взаимных блокировок. Выход из ситуации есть – это переход на использование SQL-сервера, который изначально рассчитан на одновременную работу большого числа пользователей и позволяет оптимально работать с данными. Какой SQL-сервер выбрать? У большинства предприятий размер бухгалтерских баз не очень велик, чтобы переходить на Oracle, это всё равно что из пушки стрелять по воробьям. Наиболее простые базы, вроде mSQL или MySQL, не поддерживают триггеры и процедуры в полном объёме, как это может понадобиться. Да, и не стоит забывать: когда 10 лет назад вышла версия 7.7, у большинства фирм стояли пиратские ОС, доступность которых, как и дистрибутивов СУБД, определялась низкой ценой и безнаказанностью их использования. В таких условиях логичнее всего было сделать поддержку СУБД Microsoft SQL. Сейчас наша экономика входит в цивилизованное русло, фирмы начинают задумываться о легальности используемого ПО, эффективнее оценивают функциональную необходимость, затраты и риски. Если где-то ещё не перешли на полностью лицензионное программное обеспечение, то, по крайней мере, стараются умалчивать об этом. Возможно, что не все знают об альтернативных решениях, об одном из которых сейчас и пойдёт речь. PostgreSQL альтернатива Microsoft SQL Покупка СУБД Microsoft SQL – это дорого, плюс надо вложить деньги в покупку серверной ОС, так как под пользовательской ОС или под Linux данная СУБД не работает. Также необходимо обучить персонал для работы с этими продуктами. PostgreSQL – это объектно-реляционная система управления базами данных, разработка которой в различных формах ведётся с 1977 года [5]. PostgreSQL считается самой совершенной СУБД, распространяемой на условиях открытых исходных текстов. Несмотря на глубокие исторические корни и более чем 32-летние наработки, грустная действительность современного мира такова, что редко какие технические решения развиваются без рекламы и массового использования. Возьмите пример с операционной системой ОS/2 или стандартом Betacam. В таких условиях самым главным направлением в популяризации преимуществ PostgreSQL может быть только практическое применение данной СУБД. Что интересно, многие разработчики программного обеспечения понимают это и, например, восьмая версия «1С:Предприятия» умеет изначально работать с PostgreSQL. Но как быть тем, у кого версия 7.7? Не для них ли написана эта статья? Для тех программных продуктов, которые «не знают» о существовании СУБД PostgreSQL (т.е. не могут работать с ней напрямую), следует использовать конвертор запросов. Предполагая, что все существующие приложения укладываются в рамках клиент-серверной модели, зададимся вопросом: а где расположить конвертор – на сервере или на клиенте? Несомненно, более прозрачным решением было бы установить один конвертор на стороне сервера. Технически это сложная задача, готовые проекты нам неизвестны, но работы в этом направлении ведутся. Более простой вариант – это конвертирование на стороне клиента. Мнимая простота компенсируется другими затратами, конвертор необходимо не только устанавливать на каждом из клиентов, но он ещё должен учитывать особенности реализаций на всём множестве клиентов. Если количество клиентов конечно, их вариативность небольшая или вообще отсутствует, задача получается не такой сложной. Именно по второму пути сейчас развивается проект универсального транслятора SQL-запросов из диалекта T-SQL в pgSQL с названием SELTA@Etersoft [6]. Первоначально существовала задача сделать максимально простой транслятор, главным образом для «1С:Предприятия 7.7», сейчас же проект перерастает в создание более универсального инструмента. На выбранном направлении есть и подводные камни из-за особенностей проекта. Так, предполагается, что на клиентской стороне используются Windows или программы, работающие под эмулятором wine. Логично спросить: а как быть тем, у кого клиент под UNIX, например, используется связка FreeBSD + FreeTDS [14] + Apache + PHP? С этим вопросом мы обратились к Станиславу Коробейникову, главному идеологу проекта. Его ответ был следующим: «Данная ситуация скорее редкость, чем правило, но несмотря на это в ближайших планах развития есть создание серверного варианта. Как бы то ни было, быстрый старт SELTA был невозможен благодаря простоте и включению функций парсера SQL-запросов в ODBC-драйвер. Начни мы по-другому, возможно, не было бы этого проекта вообще». Из ответа стало ясно, что структурная схема работы транслятора запросов следующая (см. рис. 1).
Рисунок 1. Структурная схема работы транслятора запросов SELTA Рассмотрим, что представляет данный проект сегодня. SELTA@Etersoft Идея проекта такова, что SELTA + PostgreSQL фактически выступают эмулятором сервера MS SQL. Несмотря на то что данный транслятор запросов изначально разрабатывался с целью запуска «1С:Предприятие» под Linux, его возможности постоянно расширяются, вводится поддержка новых приложений. Даже если вы не используете продукты «1С» в своей работе, а применяете какие-то другие, использующие MS SQL, или планируете приобрести, например, программу «САМО-Тур», то вам пора задуматься о миграции на PostgreSQL и возможной экономии. Транслятор SELTA@Etersoft является коммерческим продуктом, к которому прилагается техническая поддержка. Но если вы не намерены что-то покупать сразу, а просто хотите изучить возможности транслятора перед покупкой, то фирма лояльно относится к просьбам о тестировании, требуя лишь гарантийное письмо о том, что вы сотрёте продукт со своего компьютера после завершения тестирования. В описании продукта [6] можно встретить фразу: «Создать универсальный транслятор запросов практически невозможно, поэтому данный продукт предназначен только для некоторых приложений». Задавшись вопросом, почему конвертор не всегда работает, какие проблемы возникают при его реализации и каков же полный список поддерживаемых сегодня приложений, мы обратились к разработчику и получили следующий ответ: «SQL-серверы отличаются друг от друга не только и не столько синтаксисом. Ключевыми моментами являются механизмы блокировок, версионность, уровни изоляции транзакций, типы данных и, как следствие, работа с ними. PL/pgsql, используемый в Postgres, сильно отличается от t-sql, с которым работает MS SQL Server. Есть и мелкие отличия, с которыми постоянно сталкиваются разработчики. Например, в t-sql, если переменной присвоить значение поля запроса, не возвращающего строк, переменная не изменит своего значения. В plpgsql в том же случае переменная станет NULL. Таких отличий множество, поэтому чаще всего для каждого нового ПО, поддерживаемого SELTA, требуется доработка. Тем не менее SELTA универсальна и может работать с разными продуктами. На данный момент она ориентирована на «1С:Предприятие 7.7». Однако если вы заинтересованы во включении в список программ, поддерживаемых SELTA, конкретного приложения, использующего MS SQL, вы можете обратиться к разработчикам Etersoft». От себя добавим, что сейчас SELTA@Etersoft полностью поддерживаются следующие программы:
В ближайшее время планируется поддержка:
Чаще проверяйте список поддерживаемых программ по адресу [11]. Недалёк тот день, когда вы в списке полностью поддерживаемых программ обнаружите какой-нибудь «САМО-Тур»[1] или другое используемое вами ПО, а если хотите ускорить процесс, то пишите разработчикам проекта и присоединяйтесь. Несмотря на оптимизм разработчиков, мы всё же копнули глубже и задались научной стороной вопроса трансляции запросов. Что из запросов перевести нельзя, или Какие проблемы встречаются? Ответ Станислава Коробейникова был следующим: «Боль_шая проблема изначально была вызвана отсутствием у Postgres динамических курсоров (на странице с неподдерживаемыми функциями [9] можно видеть: B034 Dynamic specification of cursor attributes). Программы же, работающие с MS SQL Server, очень активно используют именно динамические курсоры. Первым шагом к добавлению этого функционала было пересоздание простых курсоров при каждом обращении. Метод имеет несколько минусов. Один из них – время, затрачиваемое на пересоздание курсора. От этого частично удалось уйти в версии SELTA 1.0.5. через триггеры, отслеживающие изменения в таблицах. Недостаток такого подхода – лишние накладные расходы при изменении данных. Чтобы избежать замедления, в SELTA была включена таблица с масками имён таблиц, требующих наличие триггеров [10]. Для «1С» была собрана статистика, и эти маски создаются при загрузке данных. Но этот подход также требует доработки. Немаловажен в работе с СУБД механизм блокировок. В MS SQL возможен такой принцип работы: для целостности данных и получения только актуальной информации при множественном изменении блокируются все участвующие таблицы. При этом доступ к информации без требования актуальности может быть обеспечен с помощью механизма, называемого «грязным чтением». «Чистое чтение» будет ожидать, пока блокировка таблицы закончится. Философия работы с PostgreSQL иная, и такой механизм не реализован. Чтобы имитировать подобное поведение, SELTA блокирует таблицы при «чистом чтении», исключая возможность взаимного изменения данных и разрешая при этом чтение данных, ставшее таким образом «грязным». Получив достаточно сведений о проекте с разных сторон, мы решили попробовать SELTA@Etersoft в действии и перевести серверную часть программы «1С:Предприятие» на Linux. Практическая часть Первым делом необходимо выбрать дистрибутив Linux для тестирования. Приоритетными при тестировании и для сборки новых версий являются платформы ALT Linux Server и Ubuntu Server. Связано это с широкой распространённостью последнего дистрибутива и тесными связями с производителями первого. Сама же SELTA, по заверениям разработчиков, тестируется под различные ОС Windows (от 2000 вплоть до 2008 Server) и WINE@Etersoft. Можно сделать вывод, что принципиальных предпочтений того или иного дистрибутива у разработчиков SELTA@Etersoft нет, поэтому среди десятка поддерживаемых был выбран уже установленный на сервере Linux Fedora 11. Вполне вероятно, что всё описанное ниже также заработает и под вашим дистрибутивом с небольшими поправками. В качестве wine использовался WINE@Etersoft 1.0 SQL 1.0.11-eter8/3. Вся настройка «1С» для работы с серверной частью под Linux сводится к четырём несложным этапам:
Пройдём подробнее по всем этапам. Пошаговую инструкцию по установке и настройке компонентов можно найти тут [7]. Установка PostgreSQL на сервер Если на вашем компьютере уже установлен PostgreSQL-сервер, то, к сожалению, его придётся удалить. Проверить, установлены пакеты или нет, можно командой: # rpm -qa|grep postgresql Удалить можно через команду: # rpm -e имя_пакета или через: # yum remove имя_пакета Удалять – не самое хорошее решение, но, к сожалению, патчей для наиболее популярных готовых сборок не существует. Те же, кто могут разобраться с исходными кодами, и так разберутся, обратившись к [8]. Для всех остальных существуют бесплатные сборки PostgreSQL (Postgres@Etersoft), размещённые по адресу: ftp://updates.etersoft.ru/pub/Etersoft/Postgres@Etersoft/stable. По полученной информации от разработчиков SELTA, в сборку Postgres@Etersoft входят все последние патчи [8], включая патч от «1С» (Бартунова и Сигаева) со строковыми типами, делающими работу со строками идентичной MS SQL. Итак, скачав для своего дистрибутива необходимые установочные пакеты PostgreSQL компании Etersoft, начинаем установку, подробнее см. [15]. # rpm -ih vpostgresql-8.3eter-8.3.7-eter4fedora.i586.rpm
Перед первым запуском СУБД необходимо поменять настройки в файле /etc/sysctl.conf: общий размер shared memory в страницах (kernel.shmall) и максимальный размер сегмента shared memory в байтах (kernel.shmmax), установив: kernel.shmall=134217728 kernel.shmmax=134217728 Чтобы внесенные изменения вступили в силу без перезагрузки системы, выполняем команду: # sysctl -p Инициализация базы производится автоматически при первом запуске PostgreSQL, файлы баз данных будут храниться в каталоге /var/lib/pgsql/data, владельцем каталога и процессов PostgreSQL устанавливается системный пользователь с учётной записью postgres, который создаётся автоматически, при установке пакетов. Для того чтобы иметь возможность подключиться к СУБД, мы должны задать пароль главному пользователю СУБД – владельцу всех баз данных – postgres. Это выполняется следующим образом. Перед первым запуском в файле конфигурации /var/lib/pgsql/data/pg_hba.conf изменяем строчку: local all all ident sameuser на: local all all trust Данное изменение позволит локальным пользователям подключаться к СУБД без пароля. (В целях безопасности не забудьте вернуть значение обратно, когда всё будет настроено.) Запускаем PostgreSQL командой: # service postgresql start или: # /etc/rc.d/init.d/postgresql start После удачного старта необходимо подключиться к СУБД и задать пароль главному пользователю СУБД (владельцу всех баз данных – postgres), выполнив в консоли следующую команду: $ psql -U postgres -d template1 -c "ALTER USER postgres PASSWORD "новый пароль" " Установив пароль для пользователя СУБД postgres, отключаем локальным пользователям возможность подключаться к базе без пароля. Для этого в файле var/lib/pgsql/data/pg_hba.conf возвращаем настройки обратно и перезапускаем СУБД PostgreSQL командой: # /etc/rc.d/init.d/postgresql restart или: # service postgresql restart Проверить, что всё работает правильно, можно, попытавшись подключиться к PostgreSQL с помощью консольного клиента psql командой: В случае удачного подключения вы увидите на консоли примерно следующее приглашение от СУБД:
Отключаемся от базы, набрав q. При необходимости прописываем PostgreSQL в стартовые скрипты системы в /etc/rc.d/rc?.d, например, командой: # chkconfig postgresql on Подробнее о настройках и как работать с PostgreSQL можно прочитать в книге [5], об оптимальных настройках см. [16]. Установка программы SELTA на стороне клиента Так как программа SELTA работает на стороне клиента, то она может быть установлена как на комьютере с Windows, так и на компьютере с Linux под эмулятором wine. Принципиальных отличий в установке нет. Заметим, что PostgreSQL и SELTA обычно устанавливаются на разных компьютерах, но могут работать и на одном. Скачиваем с сайта Etersoft установщик selta.msi или английскую версию seltaEng.msi: $ wget ftp://updates.etersoft.ru/pub/Etersoft/SELTA@Etersoft/1.0.7/Windows/selta.msi Далее запускаем под обычным пользователем установку командой: $ wine start selta.msi Выбираем директорию установки для программы. После установки запускаем SELTA под учётной записью установившего её пользователя: $ wine "c:/Program Files/Selta/Selta.exe" При первом запуске программы нужно будет указать путь к файлу лицензии. Его можно получить на сайте Etersoft, выбрав необходимую программу (в данном случае SELTA@Etersoft) и пройдя регистрацию на сайте. Получить лицензию на тестирование продукта на пару месяцев не так и сложно. После того как файл лицензии был указан, появится окно программы (см. рис. 2).
Рисунок 2. Окно программы SELTA@Etersoft В появившемся окне выбираем меню «Утилиты -> Инициализация БД». И заполняем данные для подключения к базе PostgreSQL, после чего жмём кнопку «Соединение». Если соединение прошло удачно, появится окно «Инициализация Баз Данных» (см. рис. 3). В нем будут отображены существующие базы, к ним имеет доступ пользователь, которого вы указали при подключении. Для того чтобы создать базу, нужно нажать кнопку «Создать БД» и в появившемся окне написать название будущей базы.
Рисунок 3. Окно «Инициализация Баз Данных» Данная установка SELTA должна быть проведена на всех клиентских машинах, где планируется работа «1С:Предприятие» с сервером PostgreSQL. Более подробную информацию по установке программы SELTA можно найти тут [12]. Установка клиента «1С:Предприятие 7.7» на компьютер с Linux Запускаем установку «1С:Предприятие» под учётной записью обычного пользователя: $ wine 1CSetup27.exe На предложение выбрать компоненты программы для установки оставляем всё по умолчанию (см. рис. 4).
Рисунок 4. Установка «1С:Предприятие 7.7». Выбор компонентов После того как «1С:Предприятие» установилось, устанавливаем путь к месту хранения конфигурации и запускаем режим конфигуратора. Далее заходим в меню «Окна -> Панель Окон -> Показать». И снимаем галочку с меню «Показать»; если этого не сделать, то в некоторых случаях программа будет аварийно завершать работу [1]. После чего осталось только прописать настройки подключения. Заходим в меню «Администрирование -> Параметры базы данных SQL» и в появившемся окне вписываем необходимые значения для подключения к базе данных. Перенос данных в PostgreSQL для «1С:Предприятия 7.7» Существует два наиболее простых варианта переноса данных из MS SQL в Postgres@Etersoft: Вариант 1: воспользоваться конвертором [13] программы SELTA@Etersoft для создания дампа старой базы и загрузки его в новую базу. Вариант 2: выгрузить базу через конфигуратор «1С:Предприятия» в zip-файл все настройки и базы, будучи подключёнными к MS SQL, затем переподключиться к PostgreSQL через SELTA и восстановить из ранее сохранённого zip-файла информацию, используя всё те же штатные возможности конфигуратора. Рассмотрим эти варианты подробнее: Перенос данных с помощью конвертора программы SELTA@Etersoft Перенос начинается с создания новой информационной базы при помощи программы SELTA@Etersoft. Запускаем программу (см. рис. 2). В появившемся окне выбираем меню «Утилиты -> Инициализация БД». И заполняем данные для подключения к базе PostgreSQL, после чего жмём кнопку «Соединение». Если соединение прошло удачно, появится окно «Инициализация Баз Данных» (см. рис. 3). Для того чтобы создать базу, нужно нажать кнопку «Создать БД» и в появившемся окне написать название будущей базы. Запускаем «1С:Предприятие» в режиме конфигуратора. Далее появится окно, предлагающее выбрать вам формат хранения данных. Выбираем MS SQL Server и жмём кнопку ОК (см. рис. 5). В меню «Администрирование -> Параметры базы данных SQL» указываем параметры для подключения к PostgreSQL, в качестве имени базы укажите ту базу, которую создали ранее.
Рисунок 5. Выбор формата хранения данных Далее необходимо загрузить .md-файл конфигурации, для которой вы переносите данные, и выполнить её сохранение. Заходим в меню «Администрирование -> Загрузить данные» и указываем путь к файлу .md. При этом будут созданы все необходимые таблицы, индексы и хранимые процедуры – создание структуры базы данных завершено. Для переноса самих данных воспользуйтесь графической утилитой «Конвертор» [13]. Для этого запускаем SELTA@Etersoft и в меню выбираем «Утилиты -> Конвертор» (см. рис. 6).
Рисунок 6. Графическая утилита «Конвертор» Выберите кнопку MS SQL Server –> CSV, в открывшемся окне укажите параметры подключения к MS SQL Server, на котором лежит база данных, из нее вы переносите данные. А в качестве пути для дампа укажите папку на машине клиента, в которую будут скопированы данные. Нажмите «Выполнить» и дождитесь выполнения операции, копирование всех таблиц может занять продолжительное время. Далее полученный CSV-дамп необходимо загрузить в PostgreSQL@Etersoft. Запустите «Конвертор», выберите кнопку CSV –> PostgreSQL. В открывшемся диалоге необходимо указать параметры подключения к базе, в которой до этого была сохранена ваша конфигурация. Нажмите «Выполнить» и дождитесь выполнения операции, копирование всех таблиц может занять продолжительное время (для больших баз – до нескольких часов). После окончания копирования база готова к работе, можете запускать «1С» и работать с ней в обычном режиме! Загрузка CSV-дампа в MS SQL Server выполняется аналогично. Подробнее с переносом данных при помощи конвертора можно ознакомиться тут [17]. Перенос данных с помощью штатных средств программы «1С:Предприятие» Создаём базу данных при помощи утилиты SELTA@Etersoft, как было описано выше. Затем запускаем «1С:Предприятие» в режиме конфигуратора, предварительно указав путь к хранению файлов. После чего нажимаем кнопку ОК. Далее появится окно, предлагающее выбрать вам формат хранения данных. Выбираем MS SQL Server и жмём кнопку ОК. Выбираем меню «Администрирование -> Выгрузить данные» и делаем полную выгрузку старой базы. После того как выгрузка будет завершена в меню «Администрирование -> Параметры базы данных SQL», прописываем параметры для подключения к PostgreSQL, в качестве имени базы укажите ту базу, которую создали ранее. Далее необходимо загрузить выгруженные файлы в новую базу PostgreSQL. Заходим в меню «Администрирование -> Загрузить данные» и указываем путь к файлам. После завершения загрузки можно запустить программу в обычном режиме. «1С:Предприятие» готово к использованию.
|
АЛЕКСАНДР ГЕРНГРОСС, системный администратор турфирмы «Лабиринт»,
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
