Укажите пожалуйста последовательность действий для этого. У меня сейчас под руками только ПРОФ-сервер. На КОРП при необходимости чуть позднее смогу зайти.
Сказать честно, я впервые встречаю настолько сложную (по ощущениям) архитектуру. Но даже более простые варианты мы рекомендовали выпрямлять и экономить на обслуживании. Собсно, это одна из статей нашего дохода.
Есть возможность формально описать текущую архитектуру системы с минимальным функционалом? Может правда будет проще «выпрямить, а не огороды городить»? Количество инстансов, баз, пользователей. Какие конфигурации (с версиями). Чем компания занимается.
В первом вопросе я специально взял ЦИТАТУ. У Вас в ней говорилось о DNS и разных службах.
ну и на 3 вопрос в качестве ответа хотелось бы механизм инсталляции нескольких служб с одного установленного экземпляра увидеть. На самом деле будет удобно, если такое возможно.
Вот это новость.
Специально на чистой системе по умолчанию все установил. Вдруг забыл чего. Ан нет, не локальный админ. Скажу больше, для работы с файловой шарой на том сервере нужно завести _такого же локального_ пользователя с таким же паролем. И профит. Да и не безопасны нынче шары, есть куча иных механизмов.
Ну и остальные утверждения не могут быть преподнесены в варианте абсолютного знания.
Нет, не все так плохо. Из собственного опыта скажу, что реальные проблемы начинаются на _очень больших_ (от 250 пользователей) проектах. Но на таких проектах редко работают эникейщики. Или есть проф-консультанты (получившие сертификаты Экспертов или Эксплуататоров). Они могут предложить несколько выходов, без перехода на старый вариант ведения журнала, например как DikSoft. Поясню: он предложил вынос логов на отдельный инстанс в кластере.
Кстати, в 8.3.12 уже предусмотрен легальный переход на старый формат логов.
Ключевое слово «возможно». Я исповедую принцип «необходимой достаточности» и анализа потребностей при проектировании системы. И возражаю, когда «возможно» преподносится как «однозначно надо».
Ранние версии 1С (8.1 точно) нуждались в присутствии на сервере офиса для формирования отчетов. Ересь полная, но факт. для современных 8.3-конф это требование излишне.
Вообще-то это был сарказм. Рекомендация про доменные учетки может быть излишней/некорректной зависит от архитектуры системы и механизмов применения 1с.
Я к тому, что такие советы надо оговаривать «так работает у меня». В других случаях можно настроить работу по иному механизму. Надо разбирать конкретные случаи. Для общего случая есть механизм установки по дефолту.
Если запущено несколько экземпляров «агента сервера 1с» на одном физическом или виртуальном сервере (в категориях логических единиц, т.е. физ сервер и запущенный на нем виртуальный — это разные сервера с точки зрения 1с, разные инстансы(О!)), то они имеют право (и это работает) использовать один физический ключ. Это не нарушение лицензии. Отдельные лицензии приобретаются на разные инстансы сервера.
С программными лицензиями таких экспериментов не ставил, т.к. никто еще из моих заказчиков не приобретал программный ключ на сервер. Формально ограничений тоже нет, но запускать не пробовал.
Если интересно официальное обоснование от 1с по этому поводу, то пишите в личку.
Возникло несколько вопросов по использованной терминологии. Если не сложно, то прошу ответить в конкретных примерах.
1.
Каждой службе выдается alias в DNS для того, чтобы отвязать разработку от ip и/или dns сервера
не совсем понял как… дело в том, что если вы запускаете несколько служб агента сервера 1с на разных портах, то и обращение при запуске будет вида сервер: порт, кроме порта по умолчанию — 1541. А DNS порты не разруливает… Или я ошибаюсь?
2.
Запускаться службы должны исключительно из-под доменных учеток
да еще и админских? Учетки должны быть разные или может быть одна?
3. Вы устанавливаете на каждую базу и свой экземпляр программы 1с? По крайней мере я не знаю другого способа запуска нескольких баз, требующих одинаковой платформы, но при этом висящих на разных агентах… Если есть более простой, то прошу поделиться примером.
Есть возможность формально описать текущую архитектуру системы с минимальным функционалом? Может правда будет проще «выпрямить, а не огороды городить»? Количество инстансов, баз, пользователей. Какие конфигурации (с версиями). Чем компания занимается.
ну и на 3 вопрос в качестве ответа хотелось бы механизм инсталляции нескольких служб с одного установленного экземпляра увидеть. На самом деле будет удобно, если такое возможно.
Специально на чистой системе по умолчанию все установил. Вдруг забыл чего. Ан нет, не локальный админ. Скажу больше, для работы с файловой шарой на том сервере нужно завести _такого же локального_ пользователя с таким же паролем. И профит. Да и не безопасны нынче шары, есть куча иных механизмов.
Ну и остальные утверждения не могут быть преподнесены в варианте абсолютного знания.
Кстати, в 8.3.12 уже предусмотрен легальный переход на старый формат логов.
Я к тому, что такие советы надо оговаривать «так работает у меня». В других случаях можно настроить работу по иному механизму. Надо разбирать конкретные случаи. Для общего случая есть механизм установки по дефолту.
С программными лицензиями таких экспериментов не ставил, т.к. никто еще из моих заказчиков не приобретал программный ключ на сервер. Формально ограничений тоже нет, но запускать не пробовал.
Если интересно официальное обоснование от 1с по этому поводу, то пишите в личку.
1. не совсем понял как… дело в том, что если вы запускаете несколько служб агента сервера 1с на разных портах, то и обращение при запуске будет вида сервер: порт, кроме порта по умолчанию — 1541. А DNS порты не разруливает… Или я ошибаюсь?
2. да еще и админских? Учетки должны быть разные или может быть одна?
3. Вы устанавливаете на каждую базу и свой экземпляр программы 1с? По крайней мере я не знаю другого способа запуска нескольких баз, требующих одинаковой платформы, но при этом висящих на разных агентах… Если есть более простой, то прошу поделиться примером.