Comments 32
>>Добрая 1С позволяет использовать 1С сервер предприятия на Linux для 12 клиентов без ключа сервера предприятия, для Windows подобного нет. Бонус сомнительный, ведь 10 пользователей смогут и на файловой пережить, но все же приятный.
Добрая 1С распространяет бесплатно сервер на 12 пользователей под linux или у них просто нет проверки на наличие лицензии для сервера на 12 пользователей?
Добрая 1С распространяет бесплатно сервер на 12 пользователей под linux или у них просто нет проверки на наличие лицензии для сервера на 12 пользователей?
проверка есть, раз пускает до 12 пользователей, а потом перестает.
Очень давно, писали вопрос 1сникам, боюсь напутать, ответ был, это условие, для тестирования 1с на платформе линукс, исторически так и осталось.
такж в каких то офиц. документах встречали, поправку, что на очередном обновлении может закончится.
Очень давно, писали вопрос 1сникам, боюсь напутать, ответ был, это условие, для тестирования 1с на платформе линукс, исторически так и осталось.
такж в каких то офиц. документах встречали, поправку, что на очередном обновлении может закончится.
Без лицензии на линукс нельзя использовать в продакшен, даже несмотря на то, что работает.
Ну и да — программные лицензии на винде также работают, так что не совсем корректное сравнение. Равно как и USB на линуксе. Лично я считаю, что USB лучше, проблем с ними меньше.
Ну и да — программные лицензии на винде также работают, так что не совсем корректное сравнение. Равно как и USB на линуксе. Лично я считаю, что USB лучше, проблем с ними меньше.
Как отметили ранее, то, что технически сервер позволяет 10-12 пользователям работать с ним, не делает установленную программу лицензионной.
Другими словами, настроенный по второму способу сервер будет использовать пиратское ПО.
Не подведите своих клиентов под монастырь.
Да и в статье, наверное, стоит об этом упомянуть.
Другими словами, настроенный по второму способу сервер будет использовать пиратское ПО.
Не подведите своих клиентов под монастырь.
Да и в статье, наверное, стоит об этом упомянуть.
подобной не «кошерной» связке Linux + Postgres SQLА мне кажется, что связка «Linux + Postgres SQL» в любом случае кошернее, чем «Windows + MSSQL», а не только в случае с 1С.
Недавно шеф решил сделать отдельный сервер для 1С, хоть я его и отговаривал, т.к. у нас 1С пользуется всего 3 человека. Но хозяин барин. Его знакомый рассчитал стоимость внедрения: серверная Windows + сервер + лицензия за 1С сервер… В общей сумме вышло около 200000 руб. Шеф за голову схватился. Я пару дней подумал… В итоге собрал сервер самостоятельно, что вылилось в 40000 + лицензия 1С сервер мини (на 5 подключений) — 14400 руб. И это все. Поставил CentOS, PostgreSQL, все настроил, работает 3й месяц и есть не просит. Экономия — 140000 руб!
P.S. На сколько я знаю, без оплаты будет работать 12 соединений, не пользователей. Например при администрировании сервера через «Конфигуратор» тоже создается соединение, даже несколько. У нас тоже работало некоторое время, пока количество соединений не превысило 12, после сервер запросил лицензию и работать отказывался.
P.S. На сколько я знаю, без оплаты будет работать 12 соединений, не пользователей. Например при администрировании сервера через «Конфигуратор» тоже создается соединение, даже несколько. У нас тоже работало некоторое время, пока количество соединений не превысило 12, после сервер запросил лицензию и работать отказывался.
Классно. Рассыпется диск на сервере «собранном самостоятельно» — никто замену на след. день не привезет, IPMI/iLO/DRAC у сервера нет.
Придет какой-нибудь кривой админ, не знающий линухов/PostgreSQL — тоже все классно будет.
Это не экономия. Это урезание расходов из-за того, что «бизнес» жадничает. Может жадничает и по делу. Может и не нужно там хорошего сервера и MS SQL.
Но экономией то это называть не надо.
Придет какой-нибудь кривой админ, не знающий линухов/PostgreSQL — тоже все классно будет.
Это не экономия. Это урезание расходов из-за того, что «бизнес» жадничает. Может жадничает и по делу. Может и не нужно там хорошего сервера и MS SQL.
Но экономией то это называть не надо.
Диски стоят в RAID1 + SSD для текущих баз, если один из дисков посыпется — магазин недалеко, съезжу и сразу заменю.
Фирма хоть и небольшая, но я там штатный админ, так что никто левый на сервер не полезет.
Но вы правы, для таких объемов отдельный сервер совершенно не нужен, я это объяснял начальнику, он не послушал.
Фирма хоть и небольшая, но я там штатный админ, так что никто левый на сервер не полезет.
Но вы правы, для таких объемов отдельный сервер совершенно не нужен, я это объяснял начальнику, он не послушал.
Не учли еще что клиентские программные и аппаратные лицензии расходуются по разному в клиент-серверном режиме.
-Программные расходуются на каждое подключение
-Аппаратные на компьютер.
То есть если пользователи одновременно работаю одновременно с двумя конфигурация — аппаратный ключ выгоднее.
Если работаю только с одной то выгоднее программные, то есть с ключами нужно считать в каждом конкретном случае что выгоднее.
Под Linux бага(фича) известна уже несколько лет, 1С говорит что может внезапно перестать работать, тем более недавно в продажу ввели 1С: сервер мини на 5 подключений.
-Программные расходуются на каждое подключение
-Аппаратные на компьютер.
То есть если пользователи одновременно работаю одновременно с двумя конфигурация — аппаратный ключ выгоднее.
Если работаю только с одной то выгоднее программные, то есть с ключами нужно считать в каждом конкретном случае что выгоднее.
Под Linux бага(фича) известна уже несколько лет, 1С говорит что может внезапно перестать работать, тем более недавно в продажу ввели 1С: сервер мини на 5 подключений.
1C + Linux + Postgres SQL использую около 2-х лет, примерно до 120-150 одновременных подключений. 1С и сервер баз данных находятся на разных машинах. По опыту эксплуатация сам 1С сервер можно выносить на виртуалку, а вот Postgres SQL лучше на отдельной машине с большим коллличеством RAM для кеша. При этом 1С хорошо живет на OpenVZ с минимальными накладными расходами.
А точно нужно столько клиентских лицензий MS SQL — на каждого пользователя?
Мне казалось, что лицензия нужна только тем, кто работает напрямую с сервером MS SQL. То есть в случае 1С — для сервера 1С.
Или клиенты 1С устроены так, что лезут к базе данных мимо сервера 1С?
Мне казалось, что лицензия нужна только тем, кто работает напрямую с сервером MS SQL. То есть в случае 1С — для сервера 1С.
Или клиенты 1С устроены так, что лезут к базе данных мимо сервера 1С?
v8.1c.ru/predpriyatie/questions_licence.htm
В Лицензии на клиентский доступ к Microsoft SQL Server сказано: «Каждая Лицензия на клиентский доступ дает право доступа к Серверной Программе с одного конкретного компьютера, рабочей станции или иного цифрового электронного устройства». Таким образом, число лицензий на использование Microsoft SQL Server должно быть не меньше числа пользователей, одновременно работающих с 1С: Предприятием 8 в клиент-серверном варианте.
То ещё разъяснение…
«Серверная Программа» — это кто? MS SQL? Или сервер 1С?
Если MS SQL — то к нему у меня обращается только сервер 1С. А если сервер 1С — то при чём тут MS? В общем, хрен поймёшь этих 1Совсцев.
Пошел прямо к MS:
Так что всё же клиентские лицензии нужны…
«Серверная Программа» — это кто? MS SQL? Или сервер 1С?
Если MS SQL — то к нему у меня обращается только сервер 1С. А если сервер 1С — то при чём тут MS? В общем, хрен поймёшь этих 1Совсцев.
Пошел прямо к MS:
Вы должны приобрести и назначить соответствующую клиентскую лицензию SQL Server 2008 R2 каждому устройству или пользователю, которые прямо или опосредованно обращаются к вашим экземплярам серверного программного обеспечения.
Так что всё же клиентские лицензии нужны…
Но, есть нюансы (с)
Во многих типовых конфигурациях используется «Автоматический» режим блокировки. А это значит, что после внедрения Postgres SQL вы получите вид блокировки «на уровне ТАБЛИЦ».
Вот пруф
То есть, тот же файловый режим только в профиль. Например, переводя на Postgres конфигурацию УТ-10.х вы получите расход бюджета и практически нулевой профит
Во многих типовых конфигурациях используется «Автоматический» режим блокировки. А это значит, что после внедрения Postgres SQL вы получите вид блокировки «на уровне ТАБЛИЦ».
Вот пруф
То есть, тот же файловый режим только в профиль. Например, переводя на Postgres конфигурацию УТ-10.х вы получите расход бюджета и практически нулевой профит
вы говорите про времена БП 1.6, УТ 10.3. В новых типовых все более-менее нормально.
Ну и да — в любом случае работать будет быстрее (из-за более хорошей работы СУБД с индексами, кэшированием и прочим, практика показывает, что эффект есть) + бабушка не переполнится, когда данных станет реально много.
Ну и да — в любом случае работать будет быстрее (из-за более хорошей работы СУБД с индексами, кэшированием и прочим, практика показывает, что эффект есть) + бабушка не переполнится, когда данных станет реально много.
Типовых с автоматическим режимом блокировок — великое множество. Только относительно новые конфигурации имеют управляемый режим блокировок.
Зачем народ с файловой БД переходит на SQL? Потому что, надоело лицезреть окошко блокировок. А в этом случае, они как были, так и останутся.
Поэтому, для конфигураций с автоматическим режимом блокировок нужно с файловой БД уходить в IBM DB2 Express (фришный). DB2 спокойно вытянет 20-30 юзеров.
Зачем народ с файловой БД переходит на SQL? Потому что, надоело лицезреть окошко блокировок. А в этом случае, они как были, так и останутся.
Поэтому, для конфигураций с автоматическим режимом блокировок нужно с файловой БД уходить в IBM DB2 Express (фришный). DB2 спокойно вытянет 20-30 юзеров.
У нас были ДБ2 бесплатные варианты. и то ли мы не умели их готовить, то-ли еще что-то, но при обновлениях, например, частенько бывали проблемы, требующие потом ручной подчистки таблиц _NG (после этого со второго раза как правило все проходило нормально), + некоторые ограничения у DB2 по сравнению с postgre по длине типов и ПОДОБНО в запросах. Наверняка я не все вспомнил, но и этого хватит.
Про окошко блокировок повторюсь — БП 2, УТ11, КА 1.6 работают на управляемых. То, что на неуправляемых, наверняка содержит всего несколько «узких мест» по блокировкам, которые не так долго и переписать.
Ну и да — в постгре (собственно, как в любой с клиент-серверным вариантом) реально быстрее отчеты строятся, чем в файловой.
Про окошко блокировок повторюсь — БП 2, УТ11, КА 1.6 работают на управляемых. То, что на неуправляемых, наверняка содержит всего несколько «узких мест» по блокировкам, которые не так долго и переписать.
Ну и да — в постгре (собственно, как в любой с клиент-серверным вариантом) реально быстрее отчеты строятся, чем в файловой.
Тут, конечно, нужно не забывать, что
а) лицензии 1с привязываются ко всему, до чего их программеры научились дотягиваться (в т.ч. к ВЕРСИЯМ отдельных элементов ПО на сервере 1с, к аппаратным составляющим компьютера, к mac-адресам...) — что ОЧЕНЬ неприятно, если, например, есть желание хоть иногда ПО обновлять. При этом заранее новый ключ для переактивации не попросить, нужно обновить сервер, получить 1с со слетевшими лицензиями, и только тогда обратиться в ТП 1с, получить их соизволение и новый ключ.
Выглядит, кстати, так, что нужна была защита — программеры написали «как умели» (а сумели не хорошо, а тупо взяли все перечисления, что в ОС есть: версии ПО, типы железа), и отправляют в 1с. Что смешно — в 1с точно знают, на каком железе вы запускаете сервер, и прямо цитируют, что у вас было так, а стало так.
Одно хорошо, что некоторые вещи (увеличение ОЗУ, напр.), так и быть, позволено сделать без перезапроса ключа. Выглядит такое, как радость человека, которому вдруг выкрутили одну руку — радуется, знаете, что хоть не обе выкрутили, т.е. не все в жизни плохо!
б) лицензии не всегда сразу освобождаются после выхода клиента. Т.е. покупать их надо с запасом, если не хочется ждать таймаута (а это небыстро). ТП эта тема заботит мало, так что сразу лучше счет написать на число лицензий большее.
в) готовить постгрю не умеют даже сами 1с-овцы. Т.е. дать пакет для установки — могут (целевые версии ОС причем не сказать чтобы свежие; самая свежая версия Ubuntu из LTS-релизов — 11.04, так что не забудьте поправить репозитарии в ней!), а вот методики, что крутить в ими кастрированной версии СУБД, чтобы сам сервер 1с побыстрее работать мог — этого как-то маловато. Стандартные же рекомендации от «обычной» версии Postgres помогают, но не во всем, ибо только 1с понимает, что она в запрос лепит: вот только видел запрос от нее на 20 (!!!) страниц текста)
Грустное зрелище: программисты 1с не особо оптимизируют работу БД, надеясь, что для настройки СУБД у клиентов будет свой админ СУБД. Даже если таковой и есть, он за головоу схватится и не факт что возьмется «оптимизировать то, не знаю что». Получается, как в анекдоте — «с моей стороны пули вылетели, проблема на вашей стороне» — т.е., «мы ПО написали, а его тормоза, кривости — это вы сами разбирайтесь, нам невыгодно делать хорошо!»
а) лицензии 1с привязываются ко всему, до чего их программеры научились дотягиваться (в т.ч. к ВЕРСИЯМ отдельных элементов ПО на сервере 1с, к аппаратным составляющим компьютера, к mac-адресам...) — что ОЧЕНЬ неприятно, если, например, есть желание хоть иногда ПО обновлять. При этом заранее новый ключ для переактивации не попросить, нужно обновить сервер, получить 1с со слетевшими лицензиями, и только тогда обратиться в ТП 1с, получить их соизволение и новый ключ.
Выглядит, кстати, так, что нужна была защита — программеры написали «как умели» (а сумели не хорошо, а тупо взяли все перечисления, что в ОС есть: версии ПО, типы железа), и отправляют в 1с. Что смешно — в 1с точно знают, на каком железе вы запускаете сервер, и прямо цитируют, что у вас было так, а стало так.
Одно хорошо, что некоторые вещи (увеличение ОЗУ, напр.), так и быть, позволено сделать без перезапроса ключа. Выглядит такое, как радость человека, которому вдруг выкрутили одну руку — радуется, знаете, что хоть не обе выкрутили, т.е. не все в жизни плохо!
б) лицензии не всегда сразу освобождаются после выхода клиента. Т.е. покупать их надо с запасом, если не хочется ждать таймаута (а это небыстро). ТП эта тема заботит мало, так что сразу лучше счет написать на число лицензий большее.
в) готовить постгрю не умеют даже сами 1с-овцы. Т.е. дать пакет для установки — могут (целевые версии ОС причем не сказать чтобы свежие; самая свежая версия Ubuntu из LTS-релизов — 11.04, так что не забудьте поправить репозитарии в ней!), а вот методики, что крутить в ими кастрированной версии СУБД, чтобы сам сервер 1с побыстрее работать мог — этого как-то маловато. Стандартные же рекомендации от «обычной» версии Postgres помогают, но не во всем, ибо только 1с понимает, что она в запрос лепит: вот только видел запрос от нее на 20 (!!!) страниц текста)
Грустное зрелище: программисты 1с не особо оптимизируют работу БД, надеясь, что для настройки СУБД у клиентов будет свой админ СУБД. Даже если таковой и есть, он за головоу схватится и не факт что возьмется «оптимизировать то, не знаю что». Получается, как в анекдоте — «с моей стороны пули вылетели, проблема на вашей стороне» — т.е., «мы ПО написали, а его тормоза, кривости — это вы сами разбирайтесь, нам невыгодно делать хорошо!»
При этом заранее новый ключ для переактивации не попросить, нужно обновить сервер, получить 1с со слетевшими лицензиями, и только тогда обратиться в ТП 1с, получить их соизволение и новый ключ.
Там же вроде несколько активаций на один ключ позволено?
Грустное зрелище: программисты 1с не особо оптимизируют работу БД, надеясь, что для настройки СУБД у клиентов будет свой админ СУБД.
На каком-то майкрософтовском шабаше пару лет назад товарищ, читавший лекцию про 1С сказал, что настройками БД для ускорения скорости работы 1С заморачиваться смысла нет. Оптимизацией должны заниматься программисты самой 1С.
> Там же вроде несколько активаций на один ключ позволено?
Нет, при покупке дается несколько ключей. 1 активация на ключ. Как ключи кончились — падай в ноги к ТП. Причем ТП на вопрос «пришлите мне несколько ключей, я буду ночью сервер оптимизировать» отвечает «мы так не можем, мы только по одной штуке ключи даем, как старый протухнет».
> Оптимизацией должны заниматься программисты самой 1С.
Они-то об этом знают? )
И оптимизацией чего — настроек БД, или просто на стороне 1с код создания запросов писать? Или он имел в виду прикладных программистов на языке 1с, которые уже пользуются как нижележащими стоями 1с-кой и СУБД, какая бы она не была? Впрочем, на любой из этих вопрос ответ один: схема распространения 1с никак не способствует созданию качественного и быстро работающего кода как самой 1с, так и решений на ее основе. На этом основании я бы не стал верить в то, что программеры 1с смогут чем-то ускорить работы СУБД — тупо не хватит знаний.
Честно говоря, лучше бы они умели хотя бы запросы сочинять. А то INSERT в базу в размере 39 экранных страниц (вот только из лога увидел, это я даже рекорды не искал) — это нечто, я бы таким людям оптимизировать работы с БД не позволил ) Не зря консалтинговые компании, помогающие внедрять Postgres, отказываются помогать точить СУБД под нужды 1с.
Наверное, я утрирую, ведь 1с — это наследованная вещь, и хорошо, что она хотя бы работает вообще. Но и схема продаж, и механизмы улучшения рынка (читай — подталкивания юзеров в руки франчази) построены так, что на каждом шагу покупатель остается более или менее недоволен, то ли «защитой» от копирования, то ли удивлением, какое немалое железо ему надо для 5 (пяти!) юзеров со вполне средней нагрузкой на сервер… Но «собаки лают, караван идет», всем проще так: кто-то чуть больше платит, кто-то чуть качественнее пишет, кто-то чуть больше зарабатывает — и все из-за откровенно наплевательского отношения к конечным покупателям, что любопытно!
Нет, при покупке дается несколько ключей. 1 активация на ключ. Как ключи кончились — падай в ноги к ТП. Причем ТП на вопрос «пришлите мне несколько ключей, я буду ночью сервер оптимизировать» отвечает «мы так не можем, мы только по одной штуке ключи даем, как старый протухнет».
> Оптимизацией должны заниматься программисты самой 1С.
Они-то об этом знают? )
И оптимизацией чего — настроек БД, или просто на стороне 1с код создания запросов писать? Или он имел в виду прикладных программистов на языке 1с, которые уже пользуются как нижележащими стоями 1с-кой и СУБД, какая бы она не была? Впрочем, на любой из этих вопрос ответ один: схема распространения 1с никак не способствует созданию качественного и быстро работающего кода как самой 1с, так и решений на ее основе. На этом основании я бы не стал верить в то, что программеры 1с смогут чем-то ускорить работы СУБД — тупо не хватит знаний.
Честно говоря, лучше бы они умели хотя бы запросы сочинять. А то INSERT в базу в размере 39 экранных страниц (вот только из лога увидел, это я даже рекорды не искал) — это нечто, я бы таким людям оптимизировать работы с БД не позволил ) Не зря консалтинговые компании, помогающие внедрять Postgres, отказываются помогать точить СУБД под нужды 1с.
Наверное, я утрирую, ведь 1с — это наследованная вещь, и хорошо, что она хотя бы работает вообще. Но и схема продаж, и механизмы улучшения рынка (читай — подталкивания юзеров в руки франчази) построены так, что на каждом шагу покупатель остается более или менее недоволен, то ли «защитой» от копирования, то ли удивлением, какое немалое железо ему надо для 5 (пяти!) юзеров со вполне средней нагрузкой на сервер… Но «собаки лают, караван идет», всем проще так: кто-то чуть больше платит, кто-то чуть качественнее пишет, кто-то чуть больше зарабатывает — и все из-за откровенно наплевательского отношения к конечным покупателям, что любопытно!
Или он имел в виду прикладных программистов на языке 1с, которые уже пользуются как нижележащими стоями 1с-кой и СУБД, какая бы она не была?
Вот именно этих он имел ввиду. Лекция была на тему настройки MS SQL под работу 1С.
Если вкратце, то было сказано «вот вам базовые настройки для MS SQL, а всерьез оптимизировать всё надо на уровне самой 1С, пинайте программистов».
Наверное, я утрирую, ведь 1с — это наследованная вещь, и хорошо, что она хотя бы работает вообще
А обычно так и бывает. И проблемы с производительностью бывает дешевле заткнуть апгрейдом железа, чем оптимизацией конфигурации 1С.
В прошлую пятницу, еще до переноса базы на Linux-сервер, фирма «обновила что-то там»… И сразу стало не до «линукса»… Отвались операции с банком, не возможно работать с платежками… На вопрос, может… это перенесем базу как договорились подписанным договором еще на прошлой неделе последовало в ответ (от инженерной службы), — какой нафиг перенос?, тут вот ничего не работает (оказалось не у нас одних)… ждите когда программеры исправят то, что «наобновляли», а уж потом и переносом базы на линукс займемся…
Кстати, справедливости ради надо сказать, что «наша база» с MSSQL «не пошла», но силами именно инженерной службы была «подправлена» под PostgreSQL и тестовая вроде нормально работала, оставалось только выполнить «актуализацию», как случилось «обновление»… :)
Кстати, справедливости ради надо сказать, что «наша база» с MSSQL «не пошла», но силами именно инженерной службы была «подправлена» под PostgreSQL и тестовая вроде нормально работала, оставалось только выполнить «актуализацию», как случилось «обновление»… :)
Ошибка связанная с отсутствием типа mvarchar в PostgreSQL остается актуальной на нынешних платформах 1С?
Прошу прощения, что поднимаю старую тему.
Если несколько линукс-серверов 1С поднять на разных машинах и одном кластере без активации лицензии, то количество подключений по прежнему будет 12? Или можно распределить по машинам?
Если несколько линукс-серверов 1С поднять на разных машинах и одном кластере без активации лицензии, то количество подключений по прежнему будет 12? Или можно распределить по машинам?
Sign up to leave a comment.
Пример экономии на лицензии при внедрении сервера 1С предприятия