Запускаем 2 сервера 1С 8.2 на одной машине

В связи с предстоящим переходом на 8.2.14.540 с установленной сейчас 8.2.13.205, потребовалось протестировать новую платформу. У нас есть два сервера - рабочий, виртуальный, к которому ключи проброшены средствами VMWare ESXi и тестовый, физический, в котором ключи воткнуты "напрямую".
На тестовом сервере я и начал играться.
Первый блин вышел комом. При установке я не снял галку "запускать серверную часть как службу" и 14-я платформа благополучно установилась ВМЕСТО 13-й. К счастью, 8.2 устанавливается не затирая файлы предыдущей версии и все что мне потребовалось сделать - в реестре изменить путь к исполняемому файлу ragent (с "C:\Program Files (x86)\1Cv82\8.2.14.540\bin\ragent.exe" на  "C:\Program Files (x86)\1Cv82\8.2.13.205\bin\ragent.exe").
"Хорошо", - подумал я. И попытался запустить ragent.exe из командной строки (все порты были изменены так, чтобы не пересекаться с портами других серверов, как 1С 8.1, так и 8.2, плюс, дополнительно был изменен каталог с серверной информацией - temp_srvinfo):

"C:\Program Files (x86)\1cv82\8.2.14.540\bin\ragent.exe" -regport 2641 -port 2640 -range 2660:2691 -d "C:\Program Files (x86)\1cv82\temp_srvinfo" -debug

К моему удивлению, все запустилось:

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

Поиск в интернетах показал, что есть люди у которых все работает, но, увы, никто из них не делился конкретным рецептом как это сделать.
Тогда я решил попробовать остановить службу 8.2.13.205 и запустить оба сервера "как приложения". Оба запустились замечательно, но в итоге, ни к одному из них не получилось подключиться, ошибка все та же.
Поиск в интернетах привел на мисту. В итоге, все оказалось очень и очень просто. Подключившись "напрямую" к тестовому серверу через IP-KVM, я запустил сервер, и БИНГО! Все заработало.
Жаль, что этот момент ("Все "однотипные" сервера должны запускаться как службы, либо НЕ из терминальной сессии") напрямую не прописан нигде.
Результат. 8.2.14.540

и 8.2.13.205

upd 20.08.2015

Понадобилось мне запустить два сервера 8.3, причём оба как службы, поскольку запускалось всё на виртуальной машине и KVM бы не помог. Всё оказалось не намного сложнее. Стояла и была запущена как служба 8.3.6.2041, установил как обычное приложение 8.3.6.2152. Запустил FAR от администратора, из него cmd и выполнил sc create 1CNewServer binPath= "C:\Program Files\1Cv8\8.3.6.2152\bin\ragent.exe". В "Службах" появилась новая служба, отредактировал через regedit параметр ImagePath и всё, на одном сервере запущены две службы 8.3.

Чудеса с журналом регистрации в 1С 8.2.13.205

В конце мая пришлось столкнуться со следующей проблемой.
После того как все пользователи выйдут из одной из информационных баз 1С (по причине обновления, перезапуска службы, перезагрузки сервера, либо просто все закончили работу и отправились по домам), подключение к этой же базе 1С занимало неоправданно долгое время - 3-5 минут. Потом, спустя эти самые 3-5 минут, наконец появляось окно для ввода логина и пароля, и никаких проблем в дальнейшем пользователи не испытывали. До тех пор пока все снова не выйдут из 1С. После этого ситуация повторялась. При этом, проблема возникала только на одной, основной, информационной базе. Из других баз пользователи могли входить и выходить когда им удобно, "злополучное" окно появлялось моментально.
В качестве временной меры было выбрано такое решение - на моем компьютере, включенном постоянно, 1С не закрывалась никогда. Если мне тоже требовалось выйти из 1С, чтобы программисты могли обновиться - у нас была договоренность - до тех пор пока три человека не войдут в эту ИБ, они не закрывают конфигуратор. Естественно, это не избавляло нас от всех проблем. Во-первых, программисты могли забыть об этом и закрыть конфигуратор, во-вторых, сервер 1С "любит" перезагрузки. Увы, но это так, если не перезагружать его длительное время, начинаются непонятные тормоза в произвольные моменты времени у произвольных пользователей (к серверу СУБД это не имеет никакого отношения). Соответственно, время этих процедур увеличивалось на 5 минут, что было совершенно неприемлимо. С одной стороны, если бы это была какая-нибудь редкоиспользуемая ИБ, никто даже не обратил бы на это внимания, но именно для этой базы требовалось обеспечить максимальную скорость работы.
Тогда, в мае, я обратил внимание на следующее: на любой копии базы, на любом сервере (как тестовом, так и на рабочем) проблема не появляется. При этом, процесс rmngr.exe (Менеджер кластера сервера 1С) потреблял 25 процентов процессорного времени, т.е. фактически захватывал одно ядро, на все 5 минут, которые длилось ожидание. После того, как он переставал "жрать" процессор, работа возобновлялась в нормальном режиме.
Зная, что у 1С возможны проблемы с "локальным кэшем", я предположил, что серверный кэш так же может быть причиной проблемы. Однако, ни удаление всех "временных" папок, создаваемых 1С, ни удаление каталога snccntx, ни запуск сервера 1С под другим пользователем, ни даже полная переустановка платформы не приносили никакого результата. В результате, я удалил информационную базу с сервера 1С и создал ее под другим именем. И, о чудо, проблема решилась.
Прошло 4 месяца.
Возникла та же самая проблема. Программисты "выгнали" всех из 1С для проведения обновления, а когда работу можно было продолжить - оказалось, что войти в эту самую информационную базу, никто не может. Окно с предложением ввести логин и пароль появилось только через 5 минут...
В этот раз, я твердо знал, что "пересоздание" информационной базы на сервере 1С поможет железно, но решил, что это решение не отличается ни простотой, ни красотой и следует найти что-нибудь более удобное. В первую очередь задумался: в чем разница между новой информационной базой и старой, при условии, что сама база данных на сервере СУБД остается нетронутой. И единственное различие, которое я увидел - это журнал регистрации.
Да, журнал регистрации, в который могут записываться ошибки, предупреждения и просто все действия пользователей. У нас, это было известно точно, в журнал регистрации писалось все возможное и еще немного сверху. В то время когда мы принимали участие в проекте ЦКТП, программисты добавляли в журнал регистрации записи о времении выполнения самых важных для предприятия процедур. После завершения проекта было решено, продолжать записывать эти данные, поскольку по ним можно увидеть как себя ведет система с течением времени.
Заглянув в каталог журнала регистрации (по адресу C:\Program Files\1cv82\srvinfo\reg_1641\id_базы\ - чтобы узнать id_базы посмотрите содержимое файла 1CV8Reg.lst) я увидел два каталога: 1Cv8FTxt и 1Cv8Log. Первый из которых содержал кучу файлов (период разделения ЖР установлен в "день") с совершенно нечитаемым содержимым, а второй содержал вполне привычные файлы журнала регистрации с расширениями .lgf и .lgp.
Итак, поскольку, я решил, что проблема найдена, в Конфигураторе был выбран пункт меню Сервис->Настройки журнала регистрации и нажата кнопка "Сократить". Я сохранил сокращаемые записи ЖР в папку и решил, что проблема решена. Увы, это оказалось не так. Суммарный размер файлов журнала регистрации составлял 900 мегабайт до сокращения и 450 мегабайт после его сокращения. Казалось бы, минимум в два раза время ожидания должно сократиться. Но нет, время не уменьшилось, совсем.
Готовясь плюнуть на все и "пересоздать" ИБ на сервере 1С, я, для успокоения совести, решил скопировать папки с ЖР на тестовый сервер, в идентичную базу и посмотреть что из этого получится. Как только копирование завершилось, я решил войти в эту ИБ конфигуратором - и, вот здесь произошло второе чудо, не смог. Тестовый сервер жалобно пыхтел одним ядром, а я любовался на белый квадрат в середине экрана. Окна с предложением ввести логин и пароль, не было. Спустя 35 минут окно появилось, конфигуратор открылся, rmngr.exe снова потреблял не больше 1-2 процентов процессорного времени.
Таким образом, было очевидно - причина в журнале регистрации. Однако, уменьшение его в размере совершенно не помогало. Тут произошло третье чудо - я вспомнил про чудесную утилиту FileMon от Марка Руссиновича. Оказалось, что такого продукта больше не существует, а его место занял ProcMon, совмещающий в себе функционал как FileMon, так и RegMon. Скачать его можно здесь.
Первым делом, нужно настроить фильтр, поскольку на работающей операционке каждую секунду производятся десятки и сотни вызовов к реестру, файловой системе, сети и другим ресурсам. В первую очередь я создал правило, исключающее всю информацию о процессах, имя которых отличается от "rmngr.exe" и еще одно правило, отсекало все записи, в которых путь не содержал в себе "C:\Program Files (x86)\1Cv82\" (это каталог в который устанвливается 32-х разрядная серверная и клиентская части 1С на 64-битной ОС).
И вот что я увидел:

Процесс rmngr.exe медленно и грустно "пережевывал" файл 1Cv8.lgf в папке журнала регистрации. Самое удивительное для меня заключалось в том, что размер файла был очень и очень небольшим - 11 мегабайт.
Когда rmngr.exe закончил с этим файлом, я вошел в режиме Конфигуратора и снова сократил журнал регистрации. Каково же было мое удивление, когда я увидел, что из папки журнала регистрации удалились файлы .lgp до той даты которую я выбрал, а вот файл 1Cv8.lgf остался нетронутым!
И, естественно, при следующей попытке запуска конфигуратора, rmngr.exe снова "прочесывал" весь 1Сv8.lgf. Методом научного тыка было выяснено:

• если сокращать журнал регистрации до определенного момента в прошлом, файл 1Cv8.lgf, проверяемый процессом rmngr.exe, не изменяется в размерах;
• если сокращать журнал регистрации на сегодняшний день, 1Cv8.lgf не изменяется;
• если выбрать дату завтрашнего дня - бинго! файл 1Cv8.lgf очищается.

Естественно, при выборе последнего (да и второго варианта) информационная база, фактически остается без журнала регистрации (т.е. встроенными средствами через Сервис->Журнал регистрации) его нельзя будет просмотреть, поэтому требуется, при сокращении, ЖР сохранять его в папку, доступ к которой должен быть у всех пользователей, работающих с журналом регистрации.