Как стать автором
Обновить

Комментарии 279

Говоря «одна служба — одна база» вы имеете ввиду «1 сервер 1С — одна база» или что-то другое? Просто 1C лицензируется вроде как на экземпляр сервера, так что ваша схема ой как дорого выйдет…
Если запущено несколько экземпляров «агента сервера 1с» на одном физическом или виртуальном сервере (в категориях логических единиц, т.е. физ сервер и запущенный на нем виртуальный — это разные сервера с точки зрения 1с, разные инстансы(О!)), то они имеют право (и это работает) использовать один физический ключ. Это не нарушение лицензии. Отдельные лицензии приобретаются на разные инстансы сервера.
С программными лицензиями таких экспериментов не ставил, т.к. никто еще из моих заказчиков не приобретал программный ключ на сервер. Формально ограничений тоже нет, но запускать не пробовал.
Если интересно официальное обоснование от 1с по этому поводу, то пишите в личку.
Ставил с программными лицензиями — разные инстансы на разных портах на одной физической/виртуальной машине — работают на одном программном ключе (как сервер, так и пользовательские лицензии) — как и на физическом!
Под инстансами в моем комментарии понимались инстансы СЕРВЕРА ВИНДОВС, если что.
За подтверждение возможности работы нескольких серверов 1с в одном инстансе виндовс на программном ключе (UPD) — спасибо. Буду иметь ввиду при расчете систем.
имеется ввиду процесс ragent
rphost, на каждую базу свой рабочий процесс и не нужно разворачивать авианосец за сдутой фуражкой адмирала.
Метод приказал долго жить в 8.3.
Да ничего подобного. В 8.3 сейчас в настройках можно указать сколько информационных баз на каждый процесс сервера.
Укажите пожалуйста последовательность действий для этого. У меня сейчас под руками только ПРОФ-сервер. На КОРП при необходимости чуть позднее смогу зайти.
image
Таааа. Не зря старые люди говорили: На каждого мудреца достаточно немного простОты :). Спасибо.

Вижу скушанную собаку. Ждём следующую статью. Спасибо.

«Оставайтесь! Будете гениальным механиком планеты». (с) (Робот с планеты Шелезяка)
Статья огонь, пишите еще.
Возникло несколько вопросов по использованной терминологии. Если не сложно, то прошу ответить в конкретных примерах.
1.
Каждой службе выдается alias в DNS для того, чтобы отвязать разработку от ip и/или dns сервера
не совсем понял как… дело в том, что если вы запускаете несколько служб агента сервера 1с на разных портах, то и обращение при запуске будет вида сервер: порт, кроме порта по умолчанию — 1541. А DNS порты не разруливает… Или я ошибаюсь?

2.
Запускаться службы должны исключительно из-под доменных учеток
да еще и админских? Учетки должны быть разные или может быть одна?

3. Вы устанавливаете на каждую базу и свой экземпляр программы 1с? По крайней мере я не знаю другого способа запуска нескольких баз, требующих одинаковой платформы, но при этом висящих на разных агентах… Если есть более простой, то прошу поделиться примером.
Админские права не нужны. Дайте права на папку, куда 1С установлена. Эти криворукие 1С-ники до сих под в Program Files пишут ))
Вообще-то это был сарказм. Рекомендация про доменные учетки может быть излишней/некорректной зависит от архитектуры системы и механизмов применения 1с.
Я к тому, что такие советы надо оговаривать «так работает у меня». В других случаях можно настроить работу по иному механизму. Надо разбирать конкретные случаи. Для общего случая есть механизм установки по дефолту.
Запускаться службы должны исключительно из-под доменных учеток

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

Вообще, проектирование системы на 1с не прекращается никогда. Всегда появляются новые требования по интеграции с чем-то новым, если у вас не продуктовый ларёк, конечно)
Вот это новость. image
Специально на чистой системе по умолчанию все установил. Вдруг забыл чего. Ан нет, не локальный админ. Скажу больше, для работы с файловой шарой на том сервере нужно завести _такого же локального_ пользователя с таким же паролем. И профит. Да и не безопасны нынче шары, есть куча иных механизмов.
Ну и остальные утверждения не могут быть преподнесены в варианте абсолютного знания.
Извиняюсь. Насчёт локального админа я, видимо, заблуждался.
Не претендую на «абсолютное знание». Всё вышесказанное абсолютно субъективно.
На моей памяти, запуск с требованиями прав локального администратора, видел только на ломанных платформах.
Неоднократно встречал пользователя службы 1с с правами администратора. Вместо того чтобы настроить права, их раздают чтобы служба корректно работала с COM-объектами MS Office и в случаях когда сервер 1с выгружал какие-то отчеты в разные расшары в сети.
Потому что существует множество людей, которые все делают из под доменного и корневого админа, вместо того, что бы разобраться какие права нужны учетке для корректной работы служб.

Все что вы встречали в такой реализации — это хуяк-хуяк-и-в-прод.

Все прекрасно работает под юзерскими правами, если осилить документацию с ИТС и поход в локальные политики на компе, для добавления учетки в нужные группы.
swpuser.ini может исправить ситуацию даже если запулили агента с максимальными правами

=))) Такой подход хорош и оправдан… когда у тебя 2-3 базы. А когда их много, доступы нужна давать много куда, то доменная авторизация рулит. Как минимум, если внедрена RBAC то посмотрев на учетку доменную ты сразу знаешь куда у тебя есть доступ у данного экземпляра

Сказать честно, я впервые встречаю настолько сложную (по ощущениям) архитектуру. Но даже более простые варианты мы рекомендовали выпрямлять и экономить на обслуживании. Собсно, это одна из статей нашего дохода.
Есть возможность формально описать текущую архитектуру системы с минимальным функционалом? Может правда будет проще «выпрямить, а не огороды городить»? Количество инстансов, баз, пользователей. Какие конфигурации (с версиями). Чем компания занимается.
=))) ретейлер с магазинами по всей стране (большим количеством магазинов)
Архитектура на самом деле ничем не отличается от бухгалтерии на 3 человек, просто из-за количества баз и людей обслуживание накладывает свои отпечатки
Тогда много баз откуда?
потому что много направлений бизнеса. и компания большая
  1. У нас есть сервер где установлена 1С — server-1c-82.comp.loc с ip 192.168.1.50. У нас есть несколько вариантов развития подключения
    • прописать ip — самый сложно обслуживаемый вариант (при каждом чихе нужно менять везде ip), но самый стабильный в работе.
    • прописать server-name. Это уже лучше — смена ip ему не страшна, но смена имени сервера — такая же чехарда при смене сервера
    • сделать в dns cname app-1c-nazvanie-bazi.company.ru (внешний домен). В этом случае даже смена сервера не приведет к необходимости что-то менять, что удобно, а так же можно будет сервер вынести за пределы компании
  2. Ни в коем случае — только минимально необходимые права. Учеток лучше сделать несколько, так как в случае разбора вы сможете четко увидеть какие базы и куда ломились. А так же очень гранулярно давать необходимые права
  3. Не совсем. Установленный экземпляр только один, а вот служб — несколько.
В первом вопросе я специально взял ЦИТАТУ. У Вас в ней говорилось о DNS и разных службах.

ну и на 3 вопрос в качестве ответа хотелось бы механизм инсталляции нескольких служб с одного установленного экземпляра увидеть. На самом деле будет удобно, если такое возможно.
Аэээм… А вы статью то читали? Под вторым спойлером как бэ =))))
Сорь, читал с мобильного. Сейчас посмотрю. Спасибо. А про ДНС и службы?
а что с ними? я вроде как расписал в комментариях зачем. Да и в статье тоже добавил инфу
Тогда давайте еще раз. Вот цитата:
Каждой службе выдается alias в DNS для того
Ну и т.д. У вас на одном инстансе может быть больше одной службы, просто на разных портах. Как с помощью ДНС разрулить обращение к службам?
никак. DNS позволяет безболезненно менять сервера. Обращение к службам рулиться через v8i — там прописывается порт
Может тогда переформулируете 4ый пункт в статье?
Каждой службе выдается alias в DNS для того, чтобы отвязать разработку
А то как-то запутывает. Я уж обрадовался, что можно службы агентов через DNS рулить. Ан нет, не прокатило :(.
Такое можно или для ситуации, когда подключаются тонким клиентом или иным методом по http (через браузер, например). Тогда это можно разрулить через haproxy.
Ну или заставить 1С-ников ввести уже поддержку srv записей в dns сервере — и тогда счастье наступит всем и сразу.
Парадигма развития 1с, как мне кажется, лежит несколько в иной плоскости. 1с не предоставляет глобальный сервис, так зачем поддержка srv?
А через http — это уже reverse proxi. У меня это сделано через nginx, как вариант. Ну и катит вне зоопарка, только для 8.3-ready конфигураций (конфигураций на тонких клиентах). Т.е. для современных. У автора статьи, как я понял еще и 8.1 где-то есть…
Что с портами? Как клиент узнает на какой порт подключаться в случае если на сервере запущено несколько экземпляров службы?
Это прописывается в файле подключения — %server-name%:%port%
Установленный экземпляр только один, а вот служб — несколько.

Не совсем понимаю, что вы понимаете под термином «экземпляр»? Вроде как экземпляр это как раз и есть запущенная и сконфигурированная служба.
П. 1.3: я правильно понял, что внешний домен имеет ip локальной сети?
для внутренней сети — да. Просто держите у себя зону и настраиваете ее как вам нужно
3. Ставиться MS офис

Не понял для чего нужна установка Offica на боевой сервер, где нет пользователей? Буквально сам недавно воевал со своими 1Сниками из-за установки Office.
Не пробовали модифицировать файл MSI при установки 1С Предприятие, дабы не заморачиваться со скриптом? В нем сразу прописать службы и т.п.
Ранние версии 1С (8.1 точно) нуждались в присутствии на сервере офиса для формирования отчетов. Ересь полная, но факт. для современных 8.3-конф это требование излишне.
Ранние версии 1С (8.1 точно) нуждались в присутствии на сервере офиса для формирования отчетов.


Офис никогда не требовался для формирования отчетов ни для 7.7, ни для 8.х. Формирование отчетов в 1С вполне полноценный функционал.
Ну может быть за давностью уже и ошибаюсь. Офис на серваке не ставил уже очень давно и не могу вспомнить зачем он тогда был нужен.
Учитывая, что и Microsoft не рекомендует использовать офис на сервере, вообще не понятно зачем предусматривать такую конфигурацию ПО и потом весело отлавливать косяки в самый неподходящий момент. И, самое обидное, в техподдержку обращаться бесполезно:
Корпорация Microsoft на сегодняшний день не рекомендует производить и не поддерживает автоматизацию программ из пакета Microsoft Office с помощью автоматических, неинтерактивных клиентских приложений или компонентов (включая ASP, DCOM и службы NT), поскольку при запуске в этом окружении программы пакета Office могут работать нестабильно или зависать.
Ну что могу сказать? молодой был, глупый. Давно это было. Конкретику Вам вряд ли подскажу.
На сколько я помню, офис нужен для работы с файлами (сохранение отчета, вывод на печать, загрузка из экселя и т.д.). Без установки на сервере валятся ошибки и какой нить опенофис плохо подходит — в современных типовых решениях может уже и сделали нормальную совместимость, но в сторонних обработках, обычно, используется именно Microsoft Office (т.е. часть компонентов). Иначе нужно как минимум вручную менять строки в обработках типа: db.ConnectionString = «Provider=Microsoft.ACE.OLEDB.12.0;Data Source=»+ПутьКФайлу+";Extended Properties="«Excel 12.0;IMEX=1;»"";
Насколько помню, не столько нужен офис, сколько наличие в системе какого-либо «принтера». Даж pdf-конвертер подойдет.
Некоторые вещи, выполняемые на сервере (например, генерация xls или doc файлов) могут потребовать наличие офиcа на сервере. Можно генерировать файлы на клиенте, можно работать с xlsx и docx как с xml, но это намного трудозатратнее.
По моим данным для 8.3 Офис уже практически не нужен, за исключением очень специфических отчетов.
А договора и прочие документы (уведомления, акты, технические описания, условия и.т.п.) как генерировать если не через офис?
Мы одно время хотели уйти, но посмотрели на ~12000 шаблонов которые сделали филиалы по всей стране за 15 лет работы, решили что время еще не пришло.
У Вас случаем не УПП?
Нет, у нас свои конфигурации написанные с 0 (которым уже по 15 лет, самой молодой 3 года), плюс сопровождение типовых.
Тогда предположу, что Ваше решение оптимально.
Если имеются хитронавороченные рассылки отчетов, которым недостаточно Записать ТипФайлаТабличногоДокумента.XLSX, а нужна дополнительная постобработка, и эти рассылки выполняются регламентным заданием (т.е. на сервере) — офис нужен.
Под SQLite логгирование не пробовали отдельный сервер 1С с назначенной ролью «только логи» создавать?
Неужели с SQLite всё настолько плохо? Понятно что проблемы индейцев шерифа не волнуют админ далёк от работы в 1с, но при классической схеме поиск в журнале регистрации может занимать до часа реального времени.
Нет, не все так плохо. Из собственного опыта скажу, что реальные проблемы начинаются на _очень больших_ (от 250 пользователей) проектах. Но на таких проектах редко работают эникейщики. Или есть проф-консультанты (получившие сертификаты Экспертов или Эксплуататоров). Они могут предложить несколько выходов, без перехода на старый вариант ведения журнала, например как DikSoft. Поясню: он предложил вынос логов на отдельный инстанс в кластере.
Кстати, в 8.3.12 уже предусмотрен легальный переход на старый формат логов.
К сожалению, 1С с новым форматом логов, мягко говоря лоханулась :( Хорошо что вовремя одумалась и вернулась к истокам.
Каждому гвоздю свой молоток. Мне новые логи нравятся в том числе скоростью.
А я их сильно ненавижу из-за принятого формата дата-время. Двойное беззнаковое целое прочитать ещё реально, но назад вписать — Unreal ))
Я уже запутался в том, что означает словоочетание «новый формат логов». Новый, это до 8.3.12 или начиная с него?
новый формат появился с 8.3.5 и представляет из себя (по сути) sqllite-базу. вернуться на старый тип журнала возможность была, но только через хак (в классическом смысле, используюя особенность). с 8.3.12 это можно сделать средствами платформы.
Понял, спасибо. Я то я читал описание 8.3.12 и из него сделал вывод, что там еще один новый-новый формат. А, выходит, это возврат к старому.
Программная лицензия для сервера привязывается к — сюрприз, сюрприз — серийному номеру процессора.

Либо автор заблуждается, либо что-то со времён 8.2 поменялось, либо заблуждаюсь я.

История из жизни. Перевели службу 1с (8.2) на виртуальный сервер с программной лицензией. Всё работало отлично, но после перезагрузки виртуального сервера 1с сообщила, что лицензии у неё нет. ОК, времени разбираться не было, активировали новый ключ. При перезагрузке история повторяется. Связались с техподдержкой, чтобы нам объяснили, почему слетает лицензия (все параметры сервера хранятся в «файле конфигурации», но файл зашифрован). Нам объяснили следующее:

Ключ получен на сервер с 4-мя ядрами ЦП:
1. 1999 MHz
2. 1999 MHz
3. 1998 MHz
4. 1999 MHz

После загрузки имеем следующее:
1. 1999 MHz
2. 1998 MHz
3. 1999 MHz
4. 1999 MHz

Ядра остались те же самые, но поменялся их порядок — лицензия уже не работает. Система виртуализации — Xen. Админ не захотел решать эту проблему, и 1С была установлена на физический сервер, где и продолжила своё существование.

Ну и чтобы два раза не вставать:

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

2) Изучать структуру файлов *.v8i не обязательно. Важны только следующие строки:
[Название базы, отображающееся в списке]
Connect=Srvr="ИмяСервера";Ref="ИмяБазы";

Всё остальное 1с-ка допишет сама при открытии списка баз. Файл хранится в аппдате и перечитывается при каждом открытии 1cv8s.exe, так что можно менять файл в любое время без всяких последствий. По крайней мере, за несколько лет использования этой схемы ошибок не возникало.
Красотень! Markdown-разметку осваиваете? Завидую, у меня все руки на доходят…
Не понял вопрос. Вы про оформления комментария? Markdown не использую, всё делается банальными html-подобными тегами.
в любом случае красиво.
лучше не брать программные лицензии, а брать хасп и что то вроде usb anywhere. тогда одним ключем можно все инстансы закрыть и с миграцией на другие узлы проблем не будет. у меня тоже слетала активация на 1с, причём без каких либо внешних изменений вообще, на 8.3
А это уже как раз нарушение лицензии будет, если вы с одного ключа закроете два или более инстансов сервера.

Ну для начала я не видел ни одной системы которые могли бы прокидывать USB один ко многим =))) Так что это технически сделать очень тяжело

один ко многим оно не прокидывает, по крайней мере раньше не умело. А вот несколько usb на один сервер — без проблем.
С помощью похожей железки забираю контуровский токен с нескольких машин (ЭДО, подпись документов).
конкретно AnywhereUSB не дают раздавать один ключ на несколько устройств одновременно. Переключаться можно, но одновременно — нет.
У нас после внедрения в серверной части, аналогичное сделали для клиент-банков у бухов. Они ходят по RDP на виртуалки с кб, а «флешки» тыкают в 5 портовые девайсы у себя на столе.
Ну, значит не получится и автор исходного сообщения не будет нарушать лицензию 1с :).
Ради любопытства попробовал — работает. Похоже опрос ключа идет не постоянно, а с какой-то заданной периодичностью. Ну или мульти-механизм основан не на том, что железяка раздает, а на том, что клиенты опрашивают, а железяке ничего особо не мешает отдавать один ключ разным клиентам по запросу. Надо будет как-нить wireshark прикрутить к этому делу.
С USB-ключами тоже есть несколько нюансов.
Во-первых, у нас на хаспе зависали сеансы. То есть, кончились лицензии, смотрим, кто их использует, и оказывается, что часть сеансов давно завершены. Возможно, это уже пофиксили. С программными такой проблемы не было.

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

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

В-четвёртых, usb-ключи дороже. Компания наказывает рублём за нежелание следовать прогрессу.

По поводу слёта активации, пишите в ТП 1с. Там вам помогут выяснить, почему слетел ключ. Возможно, вы размонтировали один из дисков или убрали сетевой интерфейс. В ТП помогут разобраться и подскажут, чего делать не надо)

А вообще, ситуация интересная. В то время как софтверные гиганты, типа MS, раздают лицензии «оптом и в долг», 1С-ка настолько фанатично относится к лицензированию. Причём это не приводит к стойкости защиты, и у добропорядочных пользователей проблем больше, чем у пиратов.
1. вы сейчас уже про пользовательские а не про серверные? Да вылечили, где-то в между 8.2 и 8.3…
2. не очень понял, я написал про железное устройство usb anuwhere, которое прокидывает по ip некоторые классы usb устройств. и оно официально поддерживается Aladdin.
3. см пункт 2
4. на тот момент когда я этим занимался, они стоили одинаково. Плюс у нас со времен 8.0 и 8.1 был неплохой запас ключей.

Вот смотрите, слетела активация, база лежит, пинкоды кончились и вы ждете ответа на обращение. Тем временем у руководства уже начинает идти пар…
вы сейчас уже про пользовательские а не про серверные? Да вылечили, где-то в между 8.2 и 8.3…
Да, я про пользовательские серверные ключи. Немного не по теме, но меня уже было не остановить) Рад, что вылечили.
не очень понял, я написал про железное устройство usb anuwhere, которое прокидывает по ip некоторые классы usb устройств. и оно официально поддерживается Aladdin.
Был не в курсе, спасибо. То ли 6 лет назад устройство было не столь распространено, то ли наши админы про него не знали, то от платформы виртуализации тоже что-то зависит.
на тот момент когда я этим занимался, они стоили одинаково. Плюс у нас со времен 8.0 и 8.1 был неплохой запас ключей.
Компания сначала пыталась действовать идеологически, рассказывая, насколько usb-ключи хуже программных решений. Но потом сдалась и подняла цены на физические ключи. Теперь они дороже на 30-15%, в зависимости от решения. Это не значит, что «usb-ключи — всё», но является дополнительным аргументом в пользу приобретения программных ключей.
Вот смотрите, слетела активация, база лежит, пинкоды кончились и вы ждете ответа на обращение. Тем временем у руководства уже начинает идти пар…
Если мне не изменяет память, мы писали в ТП не когда лицензия упала и нового ключа нет, а когда последний ключ использован, и не осталось запасного. То есть, если сервис не падает каждую неделю, запасной ключ успеет прийти. Ну и на случай полного ада всегда лежала резервная коробочка с пинкодами, которой мы за все годы, что я там работал, так и не воспользовались.
У этого железного решения один большой минус — цена. на 14 портов стоило раньше 2 тысячи английских фунтов. На 5 портов около 500… Я его в 2010 начал использовать, когда столкнулся с большим числом 1с серверов. Поэтому разница программной и аппаратной лицензии 1с ни о чем :)
Программная лицензия. Отдельный виртуальный сервер с ролью «сервер лицензирования» на кластере HyperV W2012R2. В одном из серверов кластера немного другой процессор (доверился и не проверил, что поставщик привёз по факту E5-2680v2 вместо E5-2680) из-за этого включена опция «Выполнить перенос на физический компьютер с другой версией процессора». За два (точно не меньше) года эксплуатации лицензия не слетала ни разу. Платформы 82 и сейчас 83.
Либо автор заблуждается, либо что-то со времён 8.2 поменялось, либо заблуждаюсь я.

Автор, наверно, имеет ввиду параметр ProcessorId (в терминах WMI). Это, конечно, не серийный номер процессора, но тем не менее не самая очевидная вещь что на хостах ВМ процессоры должны совпадать с точностью до ProcessorId.
автору просто нужно раскурить про отдельный сервер с ролью «сервер лицензирования», который разместить на обычной машине с фиксированным железом.
а разве он раздает серверные лицензии а не пользовательские?
Мне тоже кажется, что так можно (чем и пользуюсь) раздавать пользовательские сетевые. Серверная по своей природе локальная, если не пользоваться хитростями аппаратными.
Любые, в т.ч. и серверные.
Опишите пожалуйста настройки для раздачи серверных лицензий. Мои настройки, при котором раздаются сетевые лицензии пользователей не дали раздать серверный ключ.
Увы, видимо не дождемся :)
«Серверную программную лицензию можно устанавливать на сервер лицензирования.»

За подробностями, уже в поиск по партнерскому форуму и документации.
ответ такой себе… в том то и дело, что в официальных мануалах я этого не нашел. А на партнерский форум доступ открыт только франчам. 1С прячет информацию от своих клиентов.
Кажется разговор идет о разном. Поправьте, если не прав
Вот тут acyp ожидает настройки для того, чтобы раздать серверный HASP с помощью сервиса лицензий.
Вот тут yukon39 уже ведет речь о программных лицензиях.
в том то и дело, что в официальных мануалах я этого не нашел.

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

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

Но уже не жду.

Чуть ниже отписал. Сервер лицензирования работает только с программными ключами. Т.е. функционала раздачи каких-либо hasp-ключей в нем нет.
в целом вы правы. надо было конкретезировать о какой лицензии идет речь. целиком и полностью моя недоработка. где-то у себя в голове объединил несколько тредов обсуждения этой статьи.
Вот тут acyp ожидает настройки для того, чтобы раздать серверный HASP

Внимательно посмотрел всю ветку. Про HASP или аппаратный ключ нет ни слова. Зато есть про программные лицензии в самом первом сообщении.

Я, соответственно, писал про возможность раздачи программных ключей с сервера лицензирования. Т.к. сервер лицензирования работает только с программными лицензиями, то я, как-то не ожидал что речь вдруг пойдет об аппаратных серверных ключах.
В kvm можно указать в свойствах виртуальной машины конкретный тип процессора. тогда миграция этой вм между разными хостами не вызывает отвала лицензии. Намеренно проверял даже миграцию между АМД и Интел платформами. Вот в облаках, где нет доступа к гипервизору — это не прокатит. В vmware вроде тоже есть такая опция, но я ее не тестировал. За остальные гипервизору не скажу.
Я бы понял, если бы что-то отваливалось при миграции, но оно отваливалась при каждой перезагрузке.

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

После перешли с XEN на vmware, но сервер 1с остался физическим, ибо «работает не трожь», и заниматься экспериментами на рабочей системе как-то не комильфо — нет никакой гарантии, что в конце концов оно заработает, а не отвалится в последний момент, ибо не «галочка в настройках гипервизора помогла», а «абсолютно случайно ядра выделены в том же порядке, что и в прошлый раз».
Как то раз, мы просто обновили драйвер на сетевой карте сервера. Без нового ПИН вопрос не решился.
вместо мутных схем с планировщиками, попробуйте разместить файлы v8i на dfs шаре. у пользователей надо будет лишь один раз прописать путь к этому файлу, тупо положив cfg в профиль.

Вы не поняли самой идеи. Файлы v8i как раз на общей шаре то и лежат, а планировщик нужен для автоматического подключения этих самых файлов с общей шары

зачем их подключать каждый раз? Один раз подключите одну общую и все, пользователь сможет руками добавлять еще свои базы.
Если вы уберете у пользователя базу то она так и останется висеть в списках. Или вообще удалите базу — тоже самое. Поэтому и решили каждый раз генерировать заново
Всё это отлично разруливается через ACL на v8i. Не нужно городить скрипты.
Вы как то плохо курили интернеты. «Легкое управление списками баз 1С» — 3.5 года как разжевал общую концепцию по управлению списками.

У меня сейчас это даже входит в курс молодого бойца для сисадминов свежепришедших.
1. Проблема вся в том, что мы это делали в 2012, поэтому я описываю свой путь.
2. У вас указано «Файл приводится в соответствие при загрузке ПК, либо раз в 90+- минут.» — у меня — сразу же после блокировки/разблокировки. Максимум — 15 минут, если админ ошибся контроллером домена и нужна синхронизация. Чувствуете разницу?
3. Прочитал вашу статью целиком. Я правильно понимаю что идеология такая — подключить пользователю все базы, а потом к 90% баз просто не дать доступ на уровне шары?
Если так — то это тоже имеет право на жизнь, но на мой взгляд решение странное так как тратиться время на проверку всех файлов на факт доступности.
Ну и почему идет привязка к компу мне тоже не понятно, хотя это и объясняется в статье…
1. На дворе уже вторая половина 2018 так то.
2. В комментах к статье есть описание реализации, когда на ПК хранится только ссылка на файл конфигурации, проверять еще руки не дошли, но если это так, то это оптимальное по скорости решение. Там вообще решение мгновенное по скорости.
Разница не чувствуется, поскольку список баз не меняется настолько часто.
3. У пользователя есть пути до всех баз. Время на проверку доступности не тратится, при запуске 1С нет разницы, в списке 300 баз или 3, из которых доступа только одна. Это вызвано тем, что файловая система возвращает список только тех файлов которые доступны пользователю. Однако в Вашем случае производится запуск powershell скрипта и сборка файла конфигурации, вот это несравнимо дольше :)

В примере скрипта цифровой подписи нет, и мне что то подсказывает, что Вы оное не практикуете. Не секурно.

Еще недостаток Вашей реализации — Ваш скрипт сносит существующий v8i файл в момент пересборки, попутно снося самопрописанные базы у пользователя. Моё решение выдает пользователю фиксированный список, плюс оставляет пространство для прописывания баз (тестовых, личных), т.е. таки проявляет некоторую гибкость.

Судя по Вашей статье в вашей организации не хватает предварительного тестирования перед деплоем в прод.
Все. Я проверил. Dr_Wut, Ваш повершеловский скрипт по обновлению v8i файлов, и мою реализацию по доставке CFG файла со списком баз под учеткой ПК можно сливать в мусорку как устаревшее и не оптимальное решение. Новая реальность банальна:

Делаем один красивый 1CEStart.cfg и тупо льем его на все ПК где установлена 1Ска в C:\ProgramData\1C\1CEStart\1CEStart.cfg групповой политикой.
Он содержит только:
CommonCfgLocation=\\domain.local\dfs-root\Sync1C\cfg\all-bases-list.cfg

указанный файл all-bases-list.cfg содержит список всех баз:
CommonInfoBases=\\domain.local\dfs-root\Sync1C\v8i\company_buh30.v8i
CommonInfoBases=\\domain.local\dfs-root\Sync1C\v8i\company_zup31.v8i
CommonInfoBases=\\bdomain.local\dfs-root\Sync1C\v8i\company_torg4.v8i

Теперь любое пополнение списка мгновенно отображается на всех ПК, запускаешь клиент и база в списке (при условии что пользователь включен в группу которая дает доступ к такому файлу).

Пора менять мануалы.
в общем ответил выше, но тут отдельный момент. Вы уверены что тот факт, что пользователи видят все базы — это правильный шаг? Я считаю что нет. Когда из много — будет путаница

И еще, ваш подход по сути основывается на ошибке (запрете) доступа к файлу. Мой — на формировании доступного списка.
У нас просто разная идеология, и говорить чья правильная — не возьмусь
Уверен. Недоступность файлов настолько обыденное явление, и пользователи с ней сталкиваются незаметно для себя бесконечно большое количество раз за один рабочий день.
Путаница из-за файла, который содержит перечень всех баз и пути подключения к ним? =) По-моему это куда ближе к порядку чем обычно.

Ваша идеология, однако Вам, не мешает:
1. Дергать контроллер домена каждый раз, делая поиск по его структуре. Засоряя логи безопасности бесполезными ивентами. Это не страшно, когда у тебя 100-200-300 пользователей. При 500+ это будет уже ощутимая нагрузка на контроллер, и очень короткий и тормозной лог безопастности.
2. Запускать на ПК пользователя повершелку. Повершелку без подписи.
3. Формирование списка не делает Ваши базы 1С секурнее. Кластер 1С как был доступен всем подряд со всеми базами, так и продолжает быть доступным. Прописывай правильные параметры подключения и между тобой и базой только авторизация 1Ски. Поэтому нет никакого смысла чего то прятать, безопасность через скрытие мнима.
Ухххх! Ну поехали:
>1. Дергать контроллер домена каждый раз, делая поиск по его структуре. Засоряя логи безопасности бесполезными ивентами. Это не страшно, когда у тебя 100-200-300 пользователей. При 500+ это будет уже ощутимая нагрузка на контроллер, и очень короткий и тормозной лог безопастности.

Давайте считать. Берем 10 баз на всю компанию. Делаем предположение что пользователю нужно 4 (всем пользователям, обычно это число 2-3). В компании 500 человек. Блокируют комп 6 раз в день. Запускают 1С 10 раз в день. Рабочий день 8 часов

Мой вариант:
1. Обращение к АД при разблокировке компьютера — 3 000(по 6 разблокировок в день на 500 пользователей) Это получается 0,1 обращение в секунду. то есть одно обращение в 10 секунд. Вы серьезно считаете это серьезным увеличением нагрузки? Что, правда? )
2. Логов AD- 3 тысячи строчек в файловых логах на контроллерах АД
3. Логов с сетевой шары — 40 000 (10 запусков, на 4 файла на две записи в логи (если не включены расширенные логи) на 500 пользователей)
4. Сетевых коннектов 20 000 (4 при каждом запуске ярлыка 1с предположим что это 10 запусков в день на 500 пользователей)

Ваш вариант
1. Обращений к АД — 500 в день (при первом обращении в день к ресурсу если компы на ночь выключают)
2. Логов в АД — 1 000 в день (при первом обращении в день к ресурсу если компы на ночь выключают)
3. Логов на сетевой шаре — 100 000 (10 запусков, на 10 файла на две записи в логи (если не включены расширенные логи) на 500 пользователей)
4. Сетевых коннектов — 50 000 (10 при каждом запуске ярлыка 1с на 10 запусков в день на 500 пользователей)

Как бы мой вариант явно выигрывает по ресурсоемкости. Это я не беру тот факт, что ваш вариант менее лоялен к пользователю — у вас варианты или ждать 90 минут или ребутнуть комп. У меня максимум 15 минут и заблокировать/разблокировать. И это я не начинаю копать в сторону настроек кербероса, ибо если у вас они закручены (например тикет протухает за час) то у вас так же появляются доп коннекты в АД за новым тикетом.

>2. Запускать на ПК пользователя повершелку. Повершелку без подписи.

скрипт запускается с шары, куда все имеют права только на чтение. С правами пользователя. Чем это отличается от логон скриптов или/и GPO?

>3. Формирование списка не делает Ваши базы 1С секурнее. Кластер 1С как был доступен всем подряд со всеми базами, так и продолжает быть доступным. Прописывай правильные параметры подключения и между тобой и базой только авторизация 1Ски. Поэтому нет никакого смысла чего то прятать, безопасность через скрытие мнима.

Аэм… Так как бы это вообще не про безопасность
Прекрасная математика. Я аж слезу пустил. Уточните, как Вы смогли заставить пользователей авторизоваться по одному раз в 10 секунд? При входе в здание висят списки, в которых четко указано до секунды в какой момент конкретному сотруднику можно авторизоваться в системе что бы не создавать нагрузки?

Мой вариант уже изменился в свете новых возможностей информации, Вы оперируете уже устаревшей информацией.
:)) судя по комментарию сказать вам нечего. Ну да ладно, ваш способ тоже работает, тоже имеет право на жизнь.
Ваш способ больше похож на костыль, нежели способ Сергея
вот он пример идиально комментария — полный и беспристраный анализ ситуации, неоспоримые доводы, остроумные шутки и много логических умозаключений.
Перечитал еще раз — это не про ваш коммент, извините :))
а что вам ещё более подробно объяснять? я считаю, что комментарий Сергея итак содержит полную информацию.
по данному способу 1С самостоятельно делает всё то, что делает ваш скрипт, кроме удаления вручную добавленных баз.
плюс, 1С формирует список баз при каждом своём запуске, что гарантирует его актуальность, а не только при блокировании компьютера в случае с вашим скриптом.
Считайте, пользуйтесь методом Сергея. Это ваш выбор. Но в отличие от меня или Сергея вы не сделали ни тот ни другой метод, но при этом даете оценку «степени костыльности» того или иного метода. На мой взгяд это не лучший паттерн поведения, хотя опять же — как себя вести — ваше решение.

Ну и еще, эта задача настолько малоресурсоемка что как ее не сделай — все равноскорее всего будет работать приемлемо.
Можно вообще написать свой интерфейс для запуска 1С — тоже как вариант решения задачи. Можно еще и допфичи туда запихать.
Что значит не сделал ни тот ни другой метод? Я методом Сергея уже лет пять пользуюсь, просто ссылаюсь на него, потому что он первый упомянул здесь в комментариях этот способ. А скрипт повершел у меня тоже есть, но для других целей. Он у нас чистит локальный кэш 1С на компьютерах пользователей.
Если вы заговорили о поведении, то подумайте в первую очередь о своем. Я если и высказался первый раз без всякой аргументации, то это касалось исключительно решения задачи. А вот вы перешли на личности.
Задача конечно малоресурсоемка, но когда есть вариант решить задачу без лишней писанины типа скриптов, то я выберу вариант без писанины скриптов, ведь это проще, а результат практически такой же.
Комментарий тонко намекает что Вы несете столь несусветную чушь, что любое дальнейшее продолжение разговора бессмысленно.
Ну что я вам могу сказать — фапайте на свое решение, ваше право =) Можете за одно объединиться с TeMochkiN в клуб, чтобы вам было вместе веселее. Считайте его единственно верным, главное чтобы ваши волосы были блестящими и шелковистыми =))
Ну а адекватные люди почитают и просто будут знать что у этой задачи есть несколько путей решения. Ни больше, ни меньше.
Разговор был про расчет нагрузки на службы AD. У Вас там не только с матчастью все плохо, но и с логикой тоже. Собственно по этому я и пытался узнать, как Вы умудряетесь так и равномерно размазывать события аутентификации и авторизации в рамках рабочего дня.

Реализация подключения баз, на мой взгляд, не оптимальна, можно проще, быстрее и гибче, но если она работает у Вас — это хорошо. Лучше чем ничего.

Мой пример про распределение это просто попытка показать что увеличение нагрузки на ад незначительна. Ине тоже не нравиться логика вашего решения, но я согласен — это лучше чем ничего. И я уважаю вас как минимум за то что:


  • решили проблему
  • поделились с обществом
  • признаете мое право пользоваться тем, что я считаю правильным :)
Уже лет 5 пользуюсь этим способом) Очень хорошо себя зарекомендовал)
>3. У пользователя есть пути до всех баз. Время на проверку доступности не тратится, при запуске 1С нет разницы, в списке 300 баз или 3, из которых доступа только одна. Это вызвано тем, что файловая система возвращает список только тех файлов которые доступны пользователю. Однако в Вашем случае производится запуск powershell скрипта и сборка файла конфигурации, вот это несравнимо дольше :)

Не согласен.
1. В файле есть путь к файлу и 1С честно будет пытаться его прочитать, получит отлуп от сервера, пойдет дальше.
2. Пока что 1С отлуп не светит, но точно тратит на него время. А если в следующей реализации сделают окно с оповещением того что ссылка на базу не доступна? А если у пользователя 1-2 базы а в компании их 15 — у вас 13 раз вылетит предупреждение скорее всего.

>В примере скрипта цифровой подписи нет, и мне что то подсказывает, что Вы оное не практикуете. Не секурно.

факт =)

>Еще недостаток Вашей реализации — Ваш скрипт сносит существующий v8i файл в момент пересборки, попутно снося самопрописанные базы у пользователя. Моё решение выдает пользователю фиксированный список, плюс оставляет пространство для прописывания баз (тестовых, личных), т.е. таки проявляет некоторую гибкость.

Это сделано намеренно, чтобы люди не делали ручные ссылки на базы. Сделал — сам дурак, у тебя все снесется

>Судя по Вашей статье в вашей организации не хватает предварительного тестирования перед деплоем в прод.

Почему вы так решили?
(на самом деле это была глубокая зимняя ночь) мы поняли что завтра надо запустить новую базу.

Только, как обычно это бывает, погорели на мелочи — я в логон-скрипте я прописал %filename%.bat а коллега выложил %filename%.cmd

с утра хелпдеск побежал делать все руками


Итак, Вы тянете кота за хвост до самого конца.
Нет чейндж менеджмента.
Нет инструментов оперативной доставки и управления пользовательскими системами.
Мало пользователей, ибо техсуппортам быстрее пробежать все ПК, чем админу запустить скрипт обходящий все системы и вносящий нужные изменения.
С тех пор, как это делалось прошло 6 лет. Многое поменялось. Но тогда реально был хаос и много проблем
У файлов в шаре есть один минус — если сервер с шарой станет недоступен, то:
1. 1С-ка начнет долго запускаться
2. Общие ИБ после запуска пропадут из списка.

В итоге имеем ещё одну точку отказа. Да и городить один общий ресурс для полусотни статичных файлов по 1Кб это как из пушки по воробьям.

И да, еще нужно настраивать индивидуальные права доступа для каждого из полусотни (а бывает и более!) файлов сомнительное удовольствие. Особенно, если что-то пошло не так, и шару надо срочно перенести на новое место.
я не спроста сказал про DFS — там несколько реплик и несколько серверов. Шара и DFS это не одно и то же… если не охота еще один namespace поднимать, то разместите в sysvol\netlogon.
1. не начнет, после того как внедрили жалоб не было ни одной
2. я про общие и говорю, при это личные можно добавлять и они тоже будут показываться подсвечиваясь *
>У файлов в шаре есть один минус — если сервер с шарой станет недоступен, то:
1. 1С-ка начнет долго запускаться
2. Общие ИБ после запуска пропадут из списка.

Аэм… DFS? )

>Да и городить один общий ресурс для полусотни статичных файлов по 1Кб это как из пушки по воробьям

Почему нет?

>И да, еще нужно настраивать индивидуальные права доступа для каждого из полусотни (а бывает и более!) файлов сомнительное удовольствие. Особенно, если что-то пошло не так, и шару надо срочно перенести на новое место.

Зачем разные? всем только для чтения — админам для редактирования. Этого хватает
всем только для чтения — админам для редактирования. Этого хватает

В том то и проблема, что не всегда всем нужно давать весь список баз на чтение. Ниже есть моё описание как мы решали проблему через группы AD.
Да, только в таком случае нужно права на чтение параметров группы в AD. Но решение тоже любопытное.
Тут что еще хорошо:
1. Через AD сразу видно к каким базам у пользователя есть доступ.
2. Добавление/изменение/удаление пользователей в группе можно делать и через оснастку AD, и из 1С (это несложно дописать)

Учитывая, что для входа в базу используется только Windows аутентификация, заведение пользователя и приписывание ему базы доступны в «один клик» прямо из интерфейса 1С. Удаление пользователя и базы из списка тоже в «один клик».

Несущественный минус — для работы в «один клик» базы в рабочей среде надо немного подпиливать (добавить пару элементов на форму справочника «Пользователи» и константу).

Огромный плюс — единое понимание и обычными администраторами и техническими специалистами и 1С-никами механизма доступа к базам данных. Кроме того, никаких сетевых шар и т.п. не используется — только локальный профиль пользователя, только гарантированно доступные для записи пути.
Тоже реализовывали прописывание баз через AD. Вариант с кучей файлов рассматривали в первую очередь, но не получалось по тех требованиям. В итоге реализовали так:
1. 1 база — 1 группа AD
2. В каждой группе AD в поле Comment лежит содержимое v8i для этой базы.
3. Логон скрипт по группам пользователей собирает содержимое файла commonbases.v8i, выкладывает его в локальный профиль пользователя, и приписывает путь к этому файлу в 1CEStart.cfg

Так как геолокаций серверов 1С и пользователей было несколько, то на каждой локации прописывался свой логон скрипт и пользователю всегда были доступны базы только текущей локации.
Спасибо, познавательно, местами смешно :)

>В следующих статьях я планирую рассказать (если эта статья народу зайдет):

Зашло, зашло. Продолжение ннада! :)
Подгорело что-то, даже зарегистрировался ради этого))

1С не умеет адекватно работать в виртуализированной среде. Это печальный факт (особенно если учесть что на дворе уже практически 2019 год), судя по всему, исправлять никто не собирается. Виртуализация, даже правильно настроенная, будет вам стоить примерно 15-25% производительности. Смиритесь. (Источник — Гилев и собственные тесты)

Это устаревшая информация. Падение производительности не больше 5-10% в гипервизорах Hyper-V и VMWare.

Забудьте про нормальный кластер — его тут нет.

Если есть виртуализация, то есть и кластер!
Так же есть кластер сервера 1С.

В продуктовой среде мы должны следовать правилу — одна база — одна служба

Есть же настройки процессов, например «количество ИБ на процесс».
Нельзя просто поставить сервер 1С и ожидать высокой производительности.

Это устаревшая информация. Падение производительности не больше 5-10% в гипервизорах Hyper-V и VMWare.

Для 1С это все еще актуально. Это конкретно про 1С


Если есть виртуализация, то есть и кластер!
Так же есть кластер сервера 1С.

Не путайте пожалуйста длинное с кислым. Виртуализация и кластер это абсолютно разные вещи, от друг друга вообще никак не зависящие


Есть же настройки процессов, например «количество ИБ на процесс».
Нельзя просто поставить сервер 1С и ожидать высокой производительности.

Не спорю, но до этого я еще просто не дошел в статьях

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

Напишите тогда что вы называете кластером.
Для меня отказоустойчивый кластер — это как минимум два сервера и СХД (на которой лежат виртуальные машины серверов). В случае отказа железа виртуальный сервер стартует на втором физическом (зависит от конкретного гипервизора, будет отказ в обслуживании или нет).
Про кластер серверов 1С — аналогично. Штатная технология, которая позволяет из физических серверов с установленными службами сервер 1С собрать единый кластер. Отдельная виртуалка для клиентских ключей и службы лицензирования.
Физические USB ключи 1С пробрасываются без проблем в виртуалки (есть несколько вариантов).
Поделитесь пожалуйста знанием «проброс серверного ключа в виртуалку без использования usb-anywhere»
VMWare это штатно делает очень давно.
Я так понимаю, проблема с Hyper-V?
Есть USB over IP, есть на Linux, есть железки.
Проблема то в чем? usb-anywhere не единственное решение.
Да, Вы правы. Вопрос именно с Hyper-V. Возможен ли проброс штатными методами? Вопрос больше теоретический, наверно поэтому я спрашиваю на форуме, а не пытаюсь подключить.
Под штатными я подразумеваю использование только возможностей платформ win2016 и Hyper-V.
К сожалению, штатными средствами никак.
Только отдельное ПО или железо.
Ну или программный ключ) Не так он и страшен.
Правда как то раз я ночью в субботу 3 раза переустанавливал сервер 1С и у меня кончились активации. Я отправил запрос и молился, чтобы прислали новый lic. Не прислали. Пришлось ломать(
Ну и ладно. Нам пока трехзвенного 1с-кластера за глаза. А он на физ.ключах и весь bare-metal. Ну и опять же usb-anywhere есть, правдя для других целей.
За ответ спасибо. Кстати, случайно наткнулся на статью как собрать свой юсб-анивере на отдельной машине с ubuntu на борту. Как-нить на досуге поэксперементирую. Вот это наверно будет интересная статья :).
Настройки ИБ на процесс умерли в 8.3
image
Настройки ИБ на процесс не умерли в 8.3, скорее, наоборот.
Установив этот параметр на 1, мы получаем как минимум по одному процессу на каждую базу 1С.
Да-да, я уже посыпал голову пеплом. Спутал с другим параметром, так удобно существовавшем в 8.2 и отмененном в 8.3 за ненадобностью.
Зачем такие геморойства со службой? Поставь ещё один СП на этой же машине (на других портах), т.к. новый СП будет на этой же машине проблем с лицензией не будет

Вам нужно запустить 2 базы на одной и той же платформе. Как вы будете это делать? Как минимум как вы будете ставить второй экземпляр сервера приложений? И вот тут то и приходит понимание что службы — единственный выход

Так-то вы об одном и том-же говорите :)
Автор пишет все относительно Windows. Для linux версии, например при контейнеризации провалов производительности нет и программная лицензия у меня не слетала, при переездах. Хорошая методика в уменьшение проблем это разделение сервера баз данных и сервера приложений.
Это да, но 1С под Linux… Я пока морально не готов ))))
А зря, там как раз получите плюшки большего контроля и можно будет забыть о том что при «аномальной» нагрузке теряешь управление над сервером.
Могу ошибаться, но программные лицензии на linux выглядят примерно как «мамой клянусь, я не пират») То есть никакой привязки и проверки не производится. По крайней мере так было на первых версиях 1с, способных работать на никсах.
Есть полезные вещи, конечно, но даже пункт «1. Подвисшая база тянула за собой перезапуск службы, а значит страдали невинные (пользователи других баз)» уже говорит о том, что автор не до конца разобрался в том, как работает 1с. Конечно, статья для начинающих, но зачем же вводить их в заблуждение?
Почему? На базе запущен какой-то дикий запрос, база сожрала все ресурсы сервера — подключиться невозможно. Что делать будете?
Или у вас никогда служба не глючила? Если так — то вам очень сильно повезло.
У меня все глючило и не раз. Что такое «На базе запущен какой-то дикий запрос, база сожрала все ресурсы сервера — подключиться невозможно» не понимаю. Вот прям совсем. Даже при загрузке всех ядер всех процессоров и оперативке, уходящей в своп можно подключиться и посмотреть, кто это сделал. И если ситуацию по процессору сложно прогнозировать (но можно, да и менее критичная она с точки зрения возможности обработки), то ограничение по оперативке есть и в скуле и в 1с.
Или у вас никогда служба не глючила

Ну, времена, когда валится ragent и rmngr уже (почти) прошли, а rphostы с зависшими фоновыми убиваются более-менее стандартными средствами без потери данных пользователями (кроме проблемного сеанса).

Ситуация с «диким» запросом — это уже инцидент. Не должно быть такого на проде, а тестовая среда не должна сильно влиять на рабочую. Даже если это один физический сервер, что часто встречается в небольших компаниях.
>Ситуация с «диким» запросом — это уже инцидент. Не должно быть такого на проде, а тестовая среда не должна сильно влиять на рабочую. Даже если это один физический сервер.
— это штатная фича типовых конфигураций. )) Windows Resource Manager на терминале и SCOM+Orchestrator на сервере 1С в помощь!
это штатная фича типовых конфигураций
Позволю не согласиться, хотя я сам заработал не один десяток тысяч рублей на исправлении типового запроса распределения по партиям. Большая часть этого — наследие 8.0, когда отсутствовали пакетные запросы и переходные периоды, когда менялась структура индексов, а запросы под неё — нет (это все достаточно редко возникающие ситуации, которые, к тому же, достаточно быстро исправлялись самой 1с). Для расследования таких ситуаций есть встроенные в 1с и в сервер СУБД средства. Да и не только для расследования, но и для оперативного определения проблемыи реагирования на неё.
Есть, конечно, узкие места типа работы ЗУП на postgres (тут требуется определенный опыт, тестовый стенд и некоторое количество экспериментов, если базы большие), или отсутствие использования нужного условия в «реальном» запросе виртуальной таблицы, которое проявляет себя на больших базах например partners.v8.1c.ru/forum/topic/1751116. Но это все равно инциденты.
Что ЗУП, что УСО, что УПП регулярно и необязательно при неправильно выставленном периоде крашатся на отчетах. Это реалии, а не криворукость локального саппорта.
Инструменты это здорово, но сильно мне легче будет, если я снова найду в _типовой_ отчетности косяк?
За УСО не скажу — не работал. УПП поддерживается «постольку поскольку», а главным драйвером является ERP. Что такое «краш при неправильно выставленном периоде»? Когда 32битный клиент не может переварить результат отчета на 1кк строк? Это нормально, научите пользователей использовать отборы, встройте «сторожа» в обработчик компоновки на потенциально опасные результаты. И более того, говоря о «На базе запущен какой-то дикий запрос, база сожрала все ресурсы сервера — подключиться невозможно», работу остальных пользователей эта ситуация не затрагивает.
в _типовой_ отчетности косяк
Это неприятно, но это опять же, инцидент и решается через ТП 1с.
К теме статьи, ИМХО, неправильные цифры, не имеют отношения.
>Что такое «краш при неправильно выставленном периоде»? Когда 32битный клиент не может переварить результат отчета на 1кк строк?

Если бы. Это когда сервер выжирает CPU и память, при нормально выставленном периоде. В типовом регламентированном отчете.
Типовой отчет не должен быть идеальным. Он именно что «типовой». Для средней конторы в вакууме
У меня бывало. 100% цпу от имени rmngr или rphost, своп, все мертвое. Потом копание в техжурнале. Не всегда получалось понять, приходилось и на фазу Луны пенять
Для этого есть отдельные настройки:
1. Максимальный объем памяти рабочих процессов
2. Безопасный расход памяти за один вызов

Просто так ничего не зависает. Если какой-либо из процессов внезапно стал вести себя неадекватно — можно перезапустить его отдельно.
Через консоль видно даже пользователя, который это сделал.
Есть еще «анализ долгих запросов» и еще много сервисов, которые помогают оценить ситуацию.
да. Постфактум. После аварии.
Нет, не «после аварии».
Один из процессов начинает жрать память, т.к. пользователь запустил отчет за весь период существования базы с максимальной детализацией.
Срубится только этот процесс. Параллельно будет запущен новый и пользователи перейдут работать на него. Руками ничего делать не придется!
Я странно себя чувствую — объясняю базовые вещи по администрированию сервера 1С.
Готов делиться опытом, но информации полно и на сайте Гилева и на других ресурсах.

Тоже сложилось впечатление, что автор недокурил мануалы. Скажем у нас был массовый переезд серверов с физики на виртуалки, в первые пару дней лаги, пока тюнинговали, потом работало как часы. Ну и с некоторыми другими постулатами из статьи не могу согласиться. С упоением жду продолжения про ci cd. Вот там граблей разложено — не счесть! )

Прям жду не дождусь… 2 вещей

* что будет предложено для Zabbix — интересно нашли ли репозиторий на github с настройками @bessonovevgen github.com/bessonovevgen/srv-1c-zabbix-template
* что будет предложено для CICD — делаем ставки господа: будет ли в статье указан oscript.io и github.com/oscript-library/deployka
Тема ci/cd не раскрыта. Раскрыта автоматизация доставки списка баз. Ну и создание большого количества кластеров, и то средствами, с которыми лично я не совсем согласен (которые следуют из-за незнания нюансов работы 1с).
>Тема ci/cd не раскрыта

Серьезно? =))) А вы почитайте все внимательно и вопроса такого не возникнет
выделяется общая файловая шара где выкладываются все файлы с настройкой подключения к базам (одна база — один файл)
при блокировании компьютера вызывается скрипт, который считывает группы пользователя и на их основании добавляет пользователям нужные базы 1С

я на файлы с настройкой подключения просто права доступа настраивал — там же тривиально: один файл — одна группа. И никаких хитрых сопоставлений с группами на клиенте не нужно.
С такими постулатами — статья реально для самых маленьких.
Я бы рекомендовал автору почитать Клиент-серверный вариант. Руководство
администратора.
И писать например как Пушкин — Ума холодных наблюдений / И сердца горестных замет — автора.
Но никак не рекомендация для последователей
А всем остальным не верить слепо всему что здесь написано
Обоснуйте пожалуйста. Судя по комментарию это из серии «я сам свидетелем не был, но резко осуждаю». Это я к тому тут и так описано книет-серверное решение.

Но если я неправ — внесу в статью правки
1. 1С пофигу на виртуализацию, просто виртуальный сервер всегда чуть медленнее работает чем то железо на котором он собран, это издержки гипервизора и прямых рук сисадмина
2. Кластеры в 1С есть
3. Только если один пользователь работает на сервере. У вас так?
4. Возможно есть падение производительности, но это дань повышению надежности. отключите вообще журнал если он вам мешает
5. Можете
6. Откуда вообще такая инфа?
7. особенно периодический пересчет итогов — итогов чего?
8. Есть такая вещь — технологический журнал. Слыхали, настраивали?

11. В принципе знаете что такое СКД и варианты отчетов?

В принципе ваш рассказ про то какая 1С боль и разочарование. А вы просто не умеете с ней работать и половину делаете методом тыка и гугления. Это все равно что на автомобиль приделать педальки и жаловаться всем что он медленно едет.
Ну ок, поехали.
1. Не пофигу. Сделайте тесты, поймете. Я — делал.
2. Мммм… Киньте статейку про active/active кластер на 1С, признаю что был не прав. У него и HA то кластера толком нету.
3. Вы или читали наискосок, или у вас очень туго со знанием как работают компьютеры
4. А почему тогда сами 1С от него отказались? И в чем надежность? В том, что это не txt а один большой файл? Про ACID не рассказывайте пожалуйста, это не про SQLLite
5. Нет, не можете. То есть да, у вас не будет по нему бегать траффик но в системе останется работающий IPv6. В Linux можно, согласен, но тут не про это речь.
6. Я везде указал источник инфы.
7. Отправлю вас в ту же книжку — там подробно расписано что это и зачем это
8. Слыхал. И даже не однократно пользовался. Поэтому и говорю что это боль и страдания
11. Прекрасно знаю. А вы судя по всему ничего, кроме него не видели. Расскажу вам по секрету — его предел — это простенькие отчеты

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

Золотые ваши слова.
Эта статья, как и мои слова лишь частные случаи.
И конкретно в этой статье ляпов именно в терминологии предостаточно из-за этого возможно трудно понять суть.
Если бы она называлась — типа — «Моя борьба...» — то и чудесно, нет вопросов
Слава великим шнягам.
Но как рекомендацию к действию я ее не считаю.
Так то у меня было 156 баз на сервере — то я должен 156 служб поднять?

По поводу 5 мелкософт тут пишет, что выключить IPv6 можно.


Я к 1С отношения не имею, но меня улыбают ваши отсылки к Гилеву, который у себя на сайте утверждает, что CrystalMark — это хороший тест для экспресс оценки дисковой подсистемы. Хотя на самом деле CristalMark годится разве что USB флешки тестировать. То же самое и с вашими/Гилева утверждениями по виртуализации. Во первых не вся виртуализация одинакова, во вторых, как и везде виртуализацию нужно уметь правильно готовить. 15-25% потери производительности больше похоже на страшилку для начинающих детей.


С другой стороныя понимаю, что нельзя быть специалистом во всем. Так что-то вполне хороший спец в 1С может при этом иметь очень поверхностные знания в серверах, сетях хранения, СХД, операционных системах и виртуализации. Главное что бы он сам это осознавал и не порол горячку типа "у меня не получилось, значит и ни у кого не получится". :)

Гилев позиционирует себя как спец в «серверах, сетях хранения, СХД, операционных системах и виртуализации».

Критиков Гилева хватает, но вот конкурентов что то не видно. Это печально.
Могу сказать, что Гилевы (братья) — сильные специалисты, но как, собсно все персонажи продвигающие себя в мир, вынуждены иногда (на внешней стороне) подменять качество количеством. Нужно рассматривать их статьи не как истину в конечной инстанции, а как повод их нанять для решения конкретных проблем. Ну и плюс смотреть на дату статьи.
Кстати именно эта дилемма нами была решена отказом от сайта в стиле Гилева. Решенные проблемы не существенны без описания систем. а это зачастую закрыто пунктами о неразглашении. В итоге мы развиваемся за счет сарафанного радио :).

Может у конкурентов просто ЧСВ не так развито? Хотя про это не мне судить. Я с миром 1С практически не пересекаюсь.

Работа сервера приложений это совокупная работа всех частей — и сети, и сервера, и СХД и виртуализации. Так вот речь сейчас конкретно про сервер приложений 1С — он в виртуализации дает серьезную просадку по производительности. То есть по факту на одной и тоже же физической платформе тестировалось несколько вариантов. И просадка реально есть. Для других апликух это значение сильно меньше. Можете сами взять и потестить на досуге у Гилева есть отличная для этого база тестовая — выдает попугаи, но нам и надо сравнить.

Еще раз, без уточнения что за виртуализация и как именно она настроена, все выше сказанное ни о чем не говорит. Понятно, что гипервизор — это дополнительная прослойка. Но это не отменяет того, что и как любой софт она поддается тюнингу. А значит без уточнения конфигурации стенда и его настроек это всего лишь ваш личный опыт, из которого нельзя делать общие выводы. Вы хотя бы попытались понять, в каком месте возникает узкое место? CPU? DIMM? Дисковые очереди? Что-то еще?

В описании стенда в статье не увидел попытки проанализировать, во что именно "утыкался" тест на гипервизорах. Что касается VMware и дисковых операций, то не вижу что настраивали это и вот это. Что касается производительности MPIO VMware при Round-Robin нужно настраивать это. На старых HBA Qlogic в биосе под виртуализацией еще нужно выкручивать на максимум параметр "Execution Throttle" в "Advanced Adapter Settings".
Опять же указанные в стенде Dell Compellent SC200 — это вроде как SAS полки расширения. А судя по описанию стенда, сервер у вас к СХД цеплялся по FC. Т.е. что за СХД не понятно. Ну и зная компеленты, их надо еще и уметь правильно готовить. Накосячить там можно крайне легко на любом этапе, начиная прямо с составления спецификации на СХД.

Про ipv6. Запрос в гугле «netsh teredo» может навести на пару полезных мыслей. Хотя просто отключить этот интерфейс в настройках карты по большей части хватает за глаза.
Согласен с вами по всем пунктам.

То что я прочитал в статье это набор мифов и баек с mista.ru, разных времен, которые перемешались в голове самоучки, дополнительно сюда примешиваются и грабли на которые наступил автор из за того что не читал документацию. В результате получился такой вот коктейль в виде статьи.

Я мог бы пройтись по пунктам но считаю что это бесполезно и даже вредно.
Сопровождением систем (любых) должны заниматься профессионалы, прошедшие соответствующую подготовку.
Мои попытки ответить по пунктам в лучшем случае приведут к образованию новых мифов и мнений, или превратятся в бесполезную перепалку.

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

Глупые люди с умным видом предлагают «удалить 1с из реальности», умные люди приходят в индустрию и двигают ее вперед зарабатывая на этом деньги.

Главная проблема 1С это низкий порог входа, когда практически любой человек пройдя 2х недельные курсы может стать «программистом», и любой эникейщик вообще не читая документацию а просто нажимая «Далее, далее, готово» может «поднять сервер 1С».
Это очень негативно сказывается на платформе и приводит к появлению таких вот «статей».

В конце по теме статьи «Администрирование 1С для самых маленьких. » от меня 2 совета «начинающим администраторам».
1. 1c.ru/rus/partners/training/uc1/course.jsp?id=459
Если захотите участвовать в крупных проектах и разрвиваться дальше то дополнительно
2. 1c.ru/rus/partners/training/uc1/course.jsp?id=199

Конечно как и любые курсы они не сделают вас профессионалом, но даст вам базу для дальнейшего развития.
=))) Интересная позиция — я выше того, чтобы рассказывать людям как надо, но вы все делаете не так! Я лучше продам курсы!
Еще раз повторяю — сядьте, напишите статью как нужно. Я с удовольствием почитаю, поучусь. Ну или хотя бы разберите то, что считаете неверным и почему.
В статье нет ничего, чего бы не было описано даже в официальной документации или у именитых внедренецев.
Чем плох мой подход? Вот реально, чем? Тем что «так не принято в нашей среде 1С-ников»? Или потому что так на курсах не рассказывают? Объясните пожалуйста «гуру 1С». Не нашел ни одного аргумента против.

По поводу постулатов… Ну да, они местами спорные, но это **лично мое мнение**, которым я делюсь. А ваша позиция — обсирать без аргументов.
Интересная позиция — я выше того, чтобы рассказывать людям как надо, но вы все делаете не так! Я лучше продам курсы!


Курсы делают люди, тратят на это ресурсы, вполне естественно что они хотят получать за это деньги, причем не такие большие.

Еще раз повторяю — сядьте, напишите статью как нужно. Я с удовольствием почитаю, поучусь.

Вы действительно считаете что 2х недельные курсы можно заменить одной статьей?
В этом ваша проблема. Вы считаете что можно нахватать обрывков знаний и типовых ситуаций и стать профессионалом.
Это так не работает.

Ну или хотя бы разберите то, что считаете неверным и почему.

Я считаю неверным то что вы абсолютно не разбираясь в вопросе, при этом пишите статью для начинающих, засоряя им голову.

В статье нет ничего, чего бы не было описано даже в официальной документации или у именитых внедренецев.

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

Чем плох мой подход? Вот реально, чем? Тем что «так не принято в нашей среде 1С-ников»? Или потому что так на курсах не рассказывают? Объясните пожалуйста «гуру 1С». Не нашел ни одного аргумента против.

Ваш подход плох тем что он не системный, это набор каких то лайфхаков которые не опытному человек ничем не помогут а некоторые даже вредны, а даже если и помогут то у человека не будет ясной картины почему это работает.
Опытному же администратору ваши советы не нужны вовсе.

А ваша позиция — обсирать без аргументов.

Я не обсираю, ваши знания не базируются на знании, я об этом и написал.
Также я привел ссылки на источники проверенной информации для «начинающих».

Добавлю еще (для тех кто не хочет разбираться и кому нужны инструкции):
its.1c.ru/db/metod8dev#browse:13:-1:1989:2035
its.1c.ru/db/metod8dev#browse:13:-1:1981
kb.1c.ru (нужна регистрация).

Курсы делают люди, тратят на это ресурсы, вполне естественно что они хотят получать за это деньги, причем не такие большие.

В какой момент статья призвана заменить курсы? Статья призвана показать наши проблемы и как мы их решали.


Вы действительно считаете что 2х недельные курсы можно заменить одной статьей?
В этом ваша проблема. Вы считаете что можно нахватать обрывков знаний и типовых ситуаций и стать профессионалом.
Это так не работает.

См первый ответ.


Я считаю неверным то что вы абсолютно не разбираясь в вопросе, при этом пишите статью для начинающих, засоряя им голову.

Почему вы считаете что не разбираюсь в вопросе? То, что ваше мнение отлично от моего обозначает только одно — мы разные люди с разным опытом.


Ваш подход плох тем что он не системный, это набор каких то лайфхаков которые не опытному человек ничем не помогут а некоторые даже вредны, а даже если и помогут то у человека не будет ясной картины почему это работает.
Опытному же администратору ваши советы не нужны вовсе.

В чем его несистемность? Чем вредны советы? Факты пожалуйста, а не "красные словца"


Я не обсираю, ваши знания не базируются на знании, я об этом и написал.
Также я привел ссылки на источники проверенной информации для «начинающих».

Очередной показатель звиздобольства. Других слов уже просто нет.


Добавлю еще (для тех кто не хочет разбираться и кому нужны инструкции):
its.1c.ru/db/metod8dev#browse:13:-1:1989:2035
its.1c.ru/db/metod8dev#browse:13:-1:1981
kb.1c.ru (нужна регистрация).

О!!! Это прям вообще сказка!!! Открываю раздел админам и что вижу:


  1. Особенности администрирования Windowds XP SP2 — это пять! Там описывается как на пользовательскую ос ставить серверные приложения???!!! Вы это считаете нормой???!!!
  2. Особенности использования MSSQL — раздел tempdb. Что видим? Правильно — шринкануть tempdb!!! Это ж насколько надо вообще ничего не понимать в БД чтобы такое писать. И это — офф сайт!

И вы еще что-то говорите про мою статью?


P.S. Вообще полистал те статьи — там все 10-15 летней давности. И потом вы удивляетесь что людей по 1С нет и все ее не любят. Так вот за это и не любят — инфы от производителя 0, везде франчайзи, которые знают меньше нашего хелпдеска.

потому что «делай как я» — локальное решение частного случая. и без описания системы «до» и «после» или хотя бы входных данных для начинающих особой ценности не имеет. курсы дают базу. базу знаний и терминологии. «системный подход», «системное образование» — слышали?
я тоже долго думал, что сертификаты — ересь. прошел курсы циско, но на сертификат сдавать не стал. «зачем? я в себе уверен и рулю 30ю цисками по сибири и дв. я и без этого крут». через год сертификат (кажись для тендера нужен был аттестованый специалист) понадобился. сдал, но с таким скрипом… понял сколько я еще не знаю, но формальный экзамен помог это выявить. с тех пор сдаю. циско, майкрософт, 1с. на экзамене будут ситуации, которые могут в жизни и не встретиться, но их решение даст возможность тебе самому понять способен ты найти подход к решению или нет. есть база или просто прослушал курс…
как-то так.
сорь за отсутствие больших букв — на руле шифт неудобно нажимается.
По прописываю баз есть вопросы:
WMI фильтр позволит сократить код скрипта, запрет запуска на серверных ОС можно решить «select * from win32_computerSystem where name like 'PC-%' „
Вообще, только средства AD + GPO, долой скиптокостыль…
Например, создать отдельные группы и политики (Конфигурация пользователя — Конфигурация програм — Инф. базы). Добавление списка сведется к добавлению пользователя в группу AD.
1. Запрет на запуск на серверых ос есть
2. Ну как бы… А вы так сделайте, поживите с этим с годик и потом напишите статью про свое видиние процесса. И как у вас это все отрабатывает
Мне не понятно, почему здесь добрая половина такая дотошная?
Никто никому ничего не навязывает. Человек решил проблему вот так, поделился опытом, что бы кто-то мог его перенять. Ещё и потратил своё время, что бы всё это оформить в виде грамотного изложения понятным языком.
Лично от меня спасибо.
Дело в том, что после некоторого размера системы эти советы применимы… но местами. А что бы применить «местами» надо понимать что, как и почему происходит. Но в этой статье ответов точно нет, есть «рецепт».
Плюс этой статьи в том, что автор в основном написал как не надо делать, а в комментариях у кого было время написали как надо.
Правильный путь решения проблем — это чтобы сервер не падал, если упал — сразу разобраться с этим.
А разводить зоосад служб 1С это как раз так себе совет.
А в чем он плох? ну вот объективно? Отличная позиция хаить решения, не предлагая альтеративы. В комментариях нет ни слова как правильно сделать. Особенно от таких вот «гуру».
Почему вы решили что мы не разбираемся почему упал сервер? Есть хоть одно на эту тему слово?
Я в очередной раз говорю — потратьте время, напишите «как надо» — я с удовольствием применю эти знания у себя. А пока я вижу только @#$ство и необоснованные понты на тему что «автор лошаро, не знает как правильно»
Вот конкретно за это вас и минисуют, а не за то, что вы 1С-ник.
Плох он тем, что это нештатная работа сервера 1С — жить на одной машине еще с серверами 1С и на это как раз никто его не тестировал.
Вы настройки разнесли по разным каталогам, но есть еще как минимум файл лицензии, каталог temp и еще места куда ваши сервера лезут одновременно.
Я просто не вижу смысла так делать в продакте. Если программисты 1С которых вы так не любите умудряются подвесить вам rphost, ну поставьте количество ИБ на процесс 1 и Принудительно завершать проблемные процессы
Однозначно поднимая пять серверов 1С вы не сможете оптимально им раздать память

Заметьте, не я это сказал про автора
Хаете как раз вы 1С, хотя за счет ее и кормитесь.

И это тоже сказал не я:
Я — я так понимаю что стадию Хьюстона с проблемами мы уже успешно пролетели?
Коллега — да. База %имя базы% подвисла, вообще не отвечает, ТОПы уже рвут и мечут. 3 раза мне уже звонили. Надо перезагружать службу.
Я — так там же еще пачка баз на этой службе!!!
Коллега — да, поэтому вторая половина ТОПов тоже рвет и мечет что их отключат…

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

Кто сказал? Есть офф документ где говорят что так делать нельзя? Почему несколько платформ на одном сервере — норма, а несколько служб одной — плохо? В чем принципиальная разница? Кто сказал что этого никто не тестировал?


Вы настройки разнесли по разным каталогам, но есть еще как минимум файл лицензии, каталог temp и еще места куда ваши сервера лезут одновременно.

Да? Каталог temp — один для всех, если ПО не выбирает его самостоятельно. Файл лицензий? ну может быть, о нем информации мне попадалось крайне мало, ничего не встречал. И еще места куда лезут и куча других программ на сервере, и ничего, живут же.


Я просто не вижу смысла так делать в продакте. Если программисты 1С которых вы так не любите умудряются подвесить вам rphost, ну поставьте количество ИБ на процесс 1 и Принудительно завершать проблемные процессы
Однозначно поднимая пять серверов 1С вы не сможете оптимально им раздать память.

Вот он ключевой момент — вы не видите смысла делать так в проде. А раз вы не видите, значит этом автоматом ересь? Так вот я вам скажу что это далеко не всегда так. Скорее чаще не так.


Заметьте, не я это сказал про автора
Хаете как раз вы 1С, хотя за счет ее и кормитесь.

А кто сказал что я кормлюсь с 1С? Для меня это обуза — если я от нее избавлюсь мне будет только легче )


А если у вас сервер не падает, то какую проблему вы вообще решаете и какую я вам должен альтернативу предложить?
Могу только предложить успокоиться.

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


Я делюсь опытом с теми, кто вынужден работать с этой платформой. Как я уже писал, это решение, которое годами работает у нас, в среднем в базе по 50-400 человек.


по сути только acyp ведет диалог, хотя и не согласен с моим мнением, за что я ему благодарен. Вы же на пару с VVizard высокомерно заявляете что это все хрень и я в корне не прав, причем так ни разу и не объяснив в чем.

И тут Остапа понесло…
То есть вы не можете для базы в которой 400 человек в среднем годами работает прикупить отдельный сервер?
Вам надо романы писать, а вы вынуждены работать админом 1С
Я могу сказать в чем Вы не правы в корне — в некоторой кажущейся надуманности ситуации.
Мы с коллегами обсудили как Вашу систему (ну, попробовали смоделировать) и из разных постов, выделяя потребности пришли к выводу, что либо у Вас нет целостного представления о системе, либо Вы каждый раз описываете разные (ну например в которых работали ранее).
И второй вывод из наших бесед: с меткой оценки одного из наших инженеров — удаление гланд через сфинктер автогеном.
Отсюда вопросы: пОциент знает, что гланды ему удалили не совсем корректно? Что можно было обойтись без столь травмирующей процедуры? Или он повелся на (относительную, моментную) дешевизну решения? Или применение автогена столь радикальным образом было обосновано? (ну мало ли, рот занят, гланды бронированные).
Если серьезно — даже без описания архитектуры понятно, что целостного решения практически не существует. Ну выкрутились, не используя штатные возможности _современных_ систем. Ну применили пару интересных решений, которые могут пригодиться как времянки быстро поднятые. Первое: без описания архитектуры возникает недоумение — зачем так сложно? Второе: возникает подозрение, что архитектуру не описываете сознательно, ибо сами понимаете ее ущербность (кстати не похоже, т.к. Вы же гордитесь решением).
Ну и резюмирую: очень сильно присутствует или легкий душок фантастики, или непонимание необходимости решать Ваши проблемы не тактикой, а архитектурой.
Если изъявите желание, то могу позадавать вопросы и ткнуть пальцем в больное, предложив более эффективное решение. Правда это уже в личку.
Объясните пожалуйста, что вы имеете в виду под «целостным решением»? Почему решение одна база — одна служба — это плохо? Ну почему? Ну объясните мне глупому.
Сейчас нам удобно, это работает (серверов приложений 8 штук — где-то баз побольше, где-то вообще одна).

Постулаты — да, возможно. Кое-что поправлю.
Потому что по факту получается, что на одну базу ложится один сервер (то, что вы называете службой — это и есть сервер 1с). А это целый пакет продублированных процессов (ragent, rphost, rmngr). Это означает НЕРЕНТАБЕЛЬНЫЙ расход памяти. Это означает настройку КАЖДОГО сервера (конечно, если таковую делаете, а на 400 пользователях ПОЛЮБОМУ надо кастомизировать), который у Вас получился, а это НЕРЕНТАБЕЛЬНОЕ ВРЕМЯ сопровождения.
У меня 1 rmanager занимает 350 мб в памяти и отхомячивает до 1% процессорного тайминга
У Вас их 8, 7*350 = 2,5 Гб оперативки ушло в корзину, от 4 до 6 % проца ушло в корзину. докинем сюда ragent, в целом он маленький, 150 мб * 7 = еще ГИГ в корзине.
Вас это не беспокоит? на 400 пользователях? Ну тогда параметры сервера в студию, пооблизываться хочу, да поудивляться.
Тогда еще подкину — сервер принимает решения о балансировке нагрузки. И ничего не знает о своем соседе (они же у вас в кластер не объединены надеюсь, потому что если объединены, то это совсем шиза, потом могу подробнее рассказать почему), который тоже принимает решения о балансировке нагрузки не зная о соплеменнике, с которым делит общий диск, общую память… хватит воображения и понимания внутренних механизмов понять происходящие процессы?

Вы себе сознательно усложнили систему. Зачем?

Под «целостным решением» я понимаю следующее: расписать бизнес-архитектуру и бизнес-потребности, оценить свою систему, понять где что можно поменять, где что упростить (ибо чем проще — тем легче), может новые конфы посмотреть, ну не знаю КА2 хорошая получилась, под многие виды бизнеса зайдет. Написать план, начать ваять. С ПЛАНОМ В РУКАХ! Тут конкретных советов, кроме «Должен быть ПЛАН, архитектура» нету. Да и не буду в конкретику уходить, это уже серьезная работа. Ну, какие-то общие наводки могу дать, но повторюсь — уже в личку и после обсуждения деталей.
Аааа… Вот вы о чем. Да, согласен, есть перерасход. Но он сделано сознательно, во второй части будет объяснено зачем.
По серверам — самый маленький — 4 ядра, 12Гб мозгов, самый большой — 12 ядер и 50 гигов мозгов.

По поводу плана — так он был, и в итоге по совокупности всех моментов пришли к такому
Чую бред, уж простите старика. У вас 1 сервер а на нем в параллели крутится пачка серверов 1с? или какая в итоге аппаратно-программная архитектура? А то разговор слепого с глухим про звездное небо получился.
Нет, для 1С куплено 4 физических сервера, поверх этого виртуализация и болтаются виртуальные сервера с службами 1С
Сегодня вы говорите, что вынуждены работать с 1С, а завтра скажете, что вынуждены работать с Postgres, например. Это непрофессионально.
Автор, я вот прочитал статью, некоторые абзацы неоднократно. Но так и не понял что у вас происходило. Что-то висло, что-то вводили. Почему список баз не в сетевой шаре? Зачем разделять по портам (привет, Гилеву из прошлых)? Что за одна база — одна служба? Какой смысл в дублировании менеджера кластера? Или это имеется ввиду рабочий процесс? Так он и так на каждую базу создается, а в последних релизах штатно вообще нельзя их изменять.
Если нужно убивать только какую-то одну базу, что мешает определить под каким рабочим процессом работаем база и грохнуть его?
Единственное соглашусь делать отдельного пользователя для службы, но то рекомендует документация для разгуливания блокировок на sql с соответствующими правами.
Еще один момент — в статье почти не затрагивается СУБД.
А это очень важная часть!
Кластеризуются разные СУБД по разному. У PostgreSQL есть отдельный дистрибутив Postgres Pro Enterprise, который разрабатывает команда Олега Бортунова, за что ему большое спасибо.
MS SQL только Enterprise умеет кластер, Standard не умеет(

Еще один вопрос — не рассматривали два физических сервера с отдельными экземплярами сервера 1С (да, на каждый придется купить ключ по 100К рублей), с асинхронной репликацией между ними? Например, БД можно каждые 5 минут бэкапить логами транзакций и поднимать в случае сбоя почти мгновенно, а сервер 1С просто будет готов к работе всегда.
В этом случае простои будут минимальные.
Так тут вообще вопрос производительности не рассматривался. Это вообще отдельная тема, которую я вообще трогать не хочу — это целые книги )
В статье решаются проблемы, применимые только к режиму совместимости и толстыми клиентами. Они не поддерживают кластеризацию в полной мере, например.
К примеру, после перехода на ERP проблемы работы сервера почти полностью ушли (добавились новые, но это другая история). Теперь 1с хорошо разруливает блокировки, хорошо кластеризуется добавляя отказоустойчивости и производительности, теперь хорошо распределяется на многопоточность, совет про частоту процессора больше не актуален, связано это скорее-всего с более эффективной работой с блокировками, но факт остается. В виртуальной среде также все отлично работает, заметного падения производительности нет. Причем ни в УПП в режиме совместимости ни в ERP без оного.
В статье решаются проблемы, применимые только к режиму совместимости и толстыми клиентами. Они не поддерживают кластеризацию в полной мере, например.

Точно) Я уже и забыл, когда работал со старыми конфигурациями. Сейчас же все на управляемых формах в режиме web или тонкого клиента, даже терминального сервера не нужно.
совет про частоту процессора больше не актуален, связано это скорее-всего с более эффективной работой с блокировками

Минутку, а как связана работа с блокировками и скорость работы встроенного языка? Интерпретатор языка как работал в один поток, так и работает. Само собой его быстродействие тоже повышают и оптимизируют, но он как грузил одно ядро так и продолжает грузить.

Другое дело, что обработку данных планомерно переносят на СУБД, которая как раз умеет работать в несколько потоков над одной командой.
Я не знаю что именно они сделали и не силен в понимании внутренностей. Но УПП практически полностью тормозит из-за блокировок. А ERP отлично масштабируется проводя на том же железе значительно больше операций. Многочисленные собственные тесты показали это при одних и тех же версиях платформы.
Статья просто лучик света в серой череде будней программиста 1С.
Я когда первый постулат прочел, сразу понял что будет веселуха.
1С не умеет адекватно работать в виртуализированной среде. Это печальный факт. И ворд не умеет, один блокнот, красавчик умеет, как печатал так и печатает.
Как, может весь сервер тормозит, почему только 1С, где тесты, где графики? Так постановил автор.
И еще наша партячейка постановила, что ёксель нам подкинули враги, чтобы отвлечь от исконно русских деревянных счетов.

в среднем в базе по 50-400 человек это вообще перл изящной словесности,
То есть если кривую распределения построить то левый край уйдет в минус — это значит 1С в некоторые моменты еще и подбрасывает пользователей в сеть.
А верхний предел надо полагать человек 700 на базу.
И судя по файлу настройки у автора таких баз уже 8 раз он порт 8041 занимает.
То есть ЦКТП бьется и срадостью сообщает о серверах на 1000 человек, а автор держит вот так спокойно сервачок на 5К и передает ЦКТП пламенный пролетарский привет, помахивая выцветшей фуражкой.
апплодирую стоя.
Чтобы программная лицензия на сервер 1С не слетала, попробуйте службе закрыть доступ к users.v8.1c.ru. В ходе экспериментов было замечено, что при запуске службы 1С происходит какой-то запрос по указанному выше адресу и далее принимается решение. Видимо идет сравнение с текущей конфигурацией машины и конфигурацией, которая сохранена на серверах 1С. Если не совпадает по каким то критериям, то лицензия слетает. А вот если ответа от серверов 1С не будет, то наша служба будет думать что все ОК и продолжит свою работу.
На 8.12.х.х сработает такой вариант?
И на 8.2 и на 8.3. Возможно в последних редакциях 8.3 что то поменяли (у меня 8.3.11.2867), но не факт. Айпишник users.v8.1c.ru они меняли где то несколько месяцев назад, но суть осталась одна.
Положу в копилку. Спасибо.
Извините, не удержусь:
Приложение «1С: Предприятия» (клиентское или серверное), при необходимости получения лицензии, выполняет поиск файлов лицензий по всем доступным путям (см. здесь). Далее из файлов получаются параметры самой лицензии и характеристики компьютера, для которого лицензия получена. Если параметры текущего компьютера совпадают с полученными ‑ выполняются проверки, связанные с количеством пользователей и типом лицензии (клиентская или серверная), в противном случае лицензия отвергается. Доступ к файлу определяется правами доступа используемой операционной системы. Если пользователь, от имени которого работает приложение, не имеет доступа к файлу лицензии (или каталогу, в котором этот файл расположен), значит лицензия не будет получена.

Отсюда: its.1c.ru/db/v83doc/bookmark/adm/TI000000539
Выделена существенная информация.
Если совсем коротко — можно совсем отключить комп от сети, затем изменить контролируемые параметры и лицензия «протухнет».
Ну я написал то, что использовал на собственном опыте, когда мы настраивали параметры виртуальной машины и нам просто надоело каждый раз при смене конфигурации процессора заново активировать сервер и клиентские лицензии, а потом по несколько дней ждать новый пин от техподдержки 1С. Указанный мной метод отрабатывал на отлично, пока я не прокараулил смену айпишника (глупо было банить доступ по IP-адресу, надо было по имени, что в последствии и сделал). Не утверждаю, что сей метод панацея от всех болезней, но опять же, у меня работал.
А почему не поднять сервис лицензирования на маленьком физическом компе, где не меняются конфигурации процессоров? Сам сервис лицензирования не требует лицензии (пардон за тафтологию). И он специально для этого предназначен (в общем-то).
Потому что сервис лицензирования не раздаёт серверные лицензии. Никак. Никогда. Только клиентские. И потому он внезапно оказывается не особо интересен, когда начинаешь с ним разбираться.
Сервис лицензирования раздает программные серверные лицензии.
Программная лицензия должна быть активирована для компьютера, на котором выполняется (один или несколько) рабочий процесс (rphost) кластера серверов или работает менеджер кластера (rmngr), на который назначен сервис лицензирования.

Источник: its.1c.ru/db/v83doc/bookmark/adm/TI000000308
Дополнительный компьютер — дополнительная точка отказа
Забавно. Значит, они только физические лицензии не осилили так раздавать.
А я вот работаю с 1С и поддержу автора. Нормальное руководство, но, скорее не «рельсовый» гайдлайн (только так, иначе никак!) а сборник рецептов, к которым стоит прислушаться, но где-то сделать по-другому.

Кластер у 1С 8.3 есть, и даже active-active. И он хорошо работает в среде Small&Medium Business (не спрашивайте, зачем мелкому бизнесу кластер). Но вот в сложных окружениях он… может и не работать. Сам лично убил несколько месяцев, пытаясь запустить этот кластер: на стенде работает, на проде — нет. Опытным путем выяснили, что он как-то конфликтует с какими-то групповыми политиками — и дальше разбираться не стали, т.к. повлиять на них было нельзя. Но это — исключение, один случай из сотни.

Злого пользователя, формирующего ОСВ за год действительно быстро и просто нейтрализовать, прибив либо его самого, либо его rphost. Но есть вещи, которые живут не только на рабочих процессах — например, сервис нумерации. Да, такие вещи ломаются крайне редко. Но в такой ситуации ребут всей службы действительно может помочь. Возможнсть запускать несколько служб одновременно с разносом по портам — штатная вещь, описанная в том же «Руководстве администратора». Так что никакой крамолы здесь не вижу.

Во времена 8.2 1С рекомендовала использовать вообще один рабочий процесс, с пафосом добавляя, что «Платформа — современное приложение, которое может использовать преимущества многопроцессорных систем». Потом одумались, к счастью. На практике, из того, что видел, пользоавтельский код выполняется в один поток (но разные ядра могут обслуживать разных пользователей одновременно). Поэтому, соглашусь, частота процессора важнее числа ядер.

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

А как набор рецептов для крупной компании — статья, как минимум, интересная. Спасибо за труд и жду продолжения )
Вы вместе с автором периодически путаетесь большую или маленькую инфраструктуру вы обслуживаете.
Если большую — то количество ядер важнее — потому что все пользователи разойдутся по ядрам, а если у вас пользователей меньше чем ядер — то да частота процессора важнее, но и инфраструктура это невеликая.
Если большую — то число баз у вас будет штук дофига как минимум и все вы их по службам не распихаете, а вот как раз 3 службы: для розницы, бухгалтерии и зарплаты может и имеет смысл сделать когда памяти не хватает на всех, тогда вы сможете их ограничить персонально.

Возможность запускать несколько служб одновременно с разносом по портам — штатная вещь в контексте что у вас разных редакций платформы 8.2 и 8.3 например, а не зоосад из 8.3.
Если в организации есть потребность развести по разным службам сервера 1с хоз.подразделения, то у этой организации есть возможность рассадить их по трем bare-metal. По крайней мере мне пока не встречались ребята с потребностями мощностей, как в ГазПром Ресурс (Сервис-Производственное подразделение, разведка и пр.), а бюджетом как у ларька.
frrrost как я понял тоже из франча и обслуживает заказчиков, сопровождая их системы. Моя история похожа. У меня под руками система корпоративного уровня, принадлежащая нашей ГК и относительно много систем заказчиков. У нас есть и три ларька и два крупных завода в обслуживании. Надо только быть честными — на заводах мы сработали как консультанты и обученцы, но отношения поддерживаем.
Я действительно сейчас работаю как «приглашенный специалист» и вижу разные системы.

Вообще тема такая, что мы можем тут долго препираться: слишком много переменных. Не обговорено изначально число баз, пользователей, серверов — поэтому каждый может «ванговать» удобные для себя параметры окружения и оставаться правым в споре.

По службам — считаю, что это допустимый сценарий, который подходит не к каждой системе.

Про процессоры — да, соглашусь, зависит и от числа пользователей, и от нагрузки. Важно, что в этом обсуждении проговорили, как 1С работает с многопоточкой (никак) — а дальше уже специалист с головой сможет прикинуть свои потребности.

Возвращаясь к статье: тут есть несколько интересных идей, подкрепленных, к тому же, скриптами, т.е. практикой. И это уже интересно и ценно. С чем-то можно поспорить (про кластер или виртуализацию), но в целом, я автора поддерживаю.
Не понял чехарды с подключением баз — можно же на сетевую шару положить файлик со списком баз, при необходимости он правится, и изменения применяются сразу у всех, не нужны никакие костыли в виде скриптов.
Про экземпляр службы на базу — совсем не понял. Это ещё один сервер, запущенный на других портах? Тогда непонятно, что с лицензированием этого зоопарка.
1. Разным пользователям нужен разный набор баз. Поэтому формировать его надо под каждого пользователя индивидуально
2. С лицензированием все хорошо — при использовании физического ключа лицензионным считаются все экземпляры служб 1С
Платформа в серверном варианте позволяет использовать веб-сервис, который возвращает список общих инфобаз. Этот сервис можно написать на 1с. И в этой же базе все настраивать.
Вы этот сервис не используете потому, что он требует корп-лицензию или по каким-то другим причинам?
А, кстати, есть где-то боле-менее понятная аргументация, кроме тех скудных слов на итс (или где-то в недрах их сайта), почему за корп-лицензию нужно выложить в два раза больше денег, причем и серверную, и все клиентские лицензии? Что там этакого навертели?
1. Разным пользователям нужен разный набор баз. Поэтому формировать его надо под каждого пользователя индивидуально

В одной из контор я делал так:
  1. На сервере терминалов был файл по пути C:\ProgramData\1C\1CEStart\1CEStart.cfg
    Состав файла (имена примерные)
    InstalledLocation=C:\Program Files (x86)\1cv8
    CommonInfoBases=\\путь к общей шаре\Бухгалтерия.v8i
    CommonInfoBases=\\путь к общей шаре\Зарплата.v8i
    CommonInfoBases=\\путь к общей шаре\Торговля.v8i
    InstallComponents=DESIGNERALLCLIENTS=1 THINCLIENTFILE=1 THINCLIENT=1 WEBSERVEREXT=1 SERVER=1 CONFREPOSSERVER=0 CONVERTER77=0 SERVERCLIENT=1 ADMINISTRATIONFUNC=1 LANGUAGES=RU
  2. По указанной шаре лежали те самые файлы, а доступы к этим файлам были разрулены на уровне доступа в домене
  3. При запуске платформы у каждого пользователя были только те базы, к которым был доступ к файлам в шаре


Есть один нюанс — на каждой машине, где установлена 1С нужно подменять файл по указанному пути. Теоретически можно попробовать разрулить так, чтобы CFG-файл запрашивал другой файл, в котором будут разрулены пути (ну это если большой парк машин и постоянно надо редактировать список баз)
Не увидел в исходной статье несколько консолей «Администрирования серверов 1С Предприятия x86-64» разных минорных версий, например 8.3.10, 8.3.11 и 8.3.12.
Не было опыта?
Был, но это в других статьях
Ок, ждём с нетерпением :)

Можно создать bat-ник для каждой версии и запускать нужный:


regsvr32 "C:\Program Files\1cv8\8.3.10.2667\bin\radmin.dll" /s
start mmc "C:\Program Files\1cv8\common\1CV8 Servers (x86-64).msc"

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

"1С — это учетная система, а не отчетная. Хотите много нормальных жирных отчетов и быстро — выводите это за рамки 1С. (Источник — собственный опыт)"


Какие системы пробовали, на чем остановились?
Чем не устроила СКД?

Автор админ, откуда ему знать? Подозреваю, такое мнение у него сложилось из-за слабых разработчиков в его компании.

Если автор об этом пишет, но не знает, то должен как минимум узнать у разработчиков, раз возник такой вопрос.

Все очень банально. Простенький плоский отчет с какими-то выборками СКД впрлне осилит. А вот если вам нужны отчеты с навороченной логикой да еще с красивыми графиками, да еще интерактивные вам точно не сюда. Гораздо логичнее вытащить данные в скуль и строить там.
Мы остановились на ms report server + power BI. После этого пиковые нагрузки на 1с упала процентов на 30-40 (их стало меньши и они стали меньше)

А, так вы о том, что специализированные решения для построения аналитических отчётов и графиков производительнее, чем 1С? Ну да, было бы странно, если бы это было не так.
Ну так многие об этом почему-то забывают и пытаются сделать из 1С универсальный нож, а потом ругаются что он плохо работает там, где нужна узкоспециализированная функция
Для того чтобы не слетала программная лицензия рекомендуется выделить отдельный сервер лицензирования. Дополнительных лицензий для него не требуется. Удобно держать его на виртуальной машине с фиксированным характеристиками виртуальных устройств.
По мере добавления программных лицензий делать бэкап.
Вот подробная инструкция: techlab.rarus.ru/news/articles/vydelennyy-server-litsenzirovaniya-1c
автор написал замечательную статью
если не придираться к мелочам, то вектор правильный
а по комментариям понятно одно: большинству комментирующих не важно что написано в статье, лишь бы самоутвердиться
не обращайте внимание на них, пишите ещё
Спасибо :))
Если бы автор написал, что статья про 8.1-8.2 и толстый клиент, многие комментарии бы отпали сами собой.
Я уже в парадигме 8.3 живу давно и новых конфигураций, которые работают в режиме тонкого клиента.
Либо статья запоздала лет на 5.
Автор описывает опыт шестилетней давности. 8.3 ровно как полгода на том момент релизнулась.
Большое спасибо за статью! Очень вовремя!) Никогда не было необходимости запускать 2 службы 1с на одном сервере и, буквально, через пару дней появилась: для обновления бухгалтерии нужна одна из последних платформ, но на ней старая база управления торговлей не работает (как минимум не проводились документы). Разумеется это все выяснилось утром (ночью обновлял), благодаря уже готовому скрипту из статьи, после длительного, 2-х часового, сна, удалось решить задачу за 5 мин. А еще через несколько дней, с подобной задачей обратилась еще одна организация). Никаких проблем с лицензированием не возникло, что с программной защитой, что с аппаратной (2 службы с разными платформами успешно используют одну лицензию, установленную на этом компе).
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.