05.04.2017 |

Кластер 1С 8.3

Насамперед, після встановлення кластера 1С раніше потрібно було створити робочі процеси. Як виявилося, процеси кластера почали створюватись автоматично залежно від навантаження бази.

Пробний запуск фонових завдань основної бази змусило кластер 1С нескінченно перевантажувати rphost.exe і додатковий rphost.exe не хотів створюватися. Покопавшись у налаштуваннях, все стало зрозуміло.

Максимальний обсяг пам'яті робочих процесів- Це обсяг пам'яті, який можуть використовувати робочі процеси разом. Потрібно бути дуже уважними при установці параметра, що вимірюється в байтах. Якщо встановити неправильне значення (недостатнє для нормальної роботи користувачів) користувачам буде видано помилку "Недостатньо вільної пам'яті на сервері 1С". Також цю помилку можна отримати, коли на сервері 1С закінчилася квота по пам'яті.

Безпечна витрата пам'яті за один виклик- дозволяє контролювати витрати пам'яті при серверному виклику, що вимірюється в байтах. Якщо дзвінок використовує більше пам'ятічим належить, цей виклик буде завершено в рамках кластера 1С без перезапуску робочого процесу (rphost.exe). Відповідно "невдаха", який виконав виклик сервера, втратить сеанс з базою 1С без впливу на роботу інших користувачів.

в одному ГБ – 1073741824 Байт, отже в 2 ГБ – 2147483648 Байта

Об'єм пам'яті робочих процесів, до якого сервер вважається продуктивним - при перевищенні цього параметра сервер кластері 1С перестане приймати нові з'єднання.

Кількість ІБ на процес- дозволяє ізолювати інформаційні бази щодо робочих процесів. За умовчанням у поточного кластера 1С було встановлено значення - "8", але протягом кількох годин роботи сервер себе дуже нестабільний, сеанси користувачів зависали. Після ізоляції кожної інформаційної бази(Значення - "1") проблеми зникли.

Кількість з'єднань на процес- за промовчанням значення "128". Так як у поточної бази дуже велике навантаження фоновими завданнями(Розрахунок логістики, аналіз прайсів, аналіз конкурентів та інше) було прийнято рішення зменшити кількість до "25".

Трохи змінилися налаштування і самого кластера 1С:

Рівень відмовостійкості- це кількість робочих серверів, які можуть одночасно вийти з ладу, і це не спричинить аварійного завершення роботи користувачів. Резервні послуги запускаються автоматично в кількості, необхідної для забезпечення заданої стійкості до відмови. У реальному режимічасу виконується реплікація активного обслуговування на резервні.

Режим розподілу навантаження- є два варіанти параметра: "Пріоритет з продуктивності" - пам'яті сервера витрачається більше і продуктивність вище, "Пріоритет з пам'яті" - кластер 1С заощаджує пам'ять сервера.

Сервер 8.3 характеризується переробленим заново внутрішнім кодом, хоча «зовні» може здатися що це трохи доопрацьований 8.2.

Сервер став більш «автонастроюваним», частина параметрів типу кількості робочих процесів тепер не створюється вручну, а розраховується виходячи з описів вимог завдань щодо відмовостійкості та надійності.

Це знижує ймовірність неправильного налаштуваннясервера та знижує вимоги до кваліфікації адмінів.

Набув розвитку механізм балансування навантаження, який можна використовувати або для підвищення продуктивності системи в цілому, або використовувати новий режим"економії пам'яті", який дозволяє працювати "з обмеженою пам'яттю" у випадку якщо використовувана конфігурація "любить від'їдати пам'ять".

Стабільність роботи під час використання великих обсягів пам'яті визначаться новими параметрами робочого сервера.

Особливо цікавим є параметр «безпечна витрата пам'яті за один виклик». Для тих хто погано уявляє, що це таке - краще не тренуйтеся на «продуктивній» базі. Параметр «Максимальний обсяг пам'яті робочих процесів» дозволяє при переповненні не обвалювати весь робочий процес, а лише один сеанс «з невдахою». «Об'єм пам'яті робочих процесів, до якого сервер вважається продуктивним» дозволяє заблокувати нові з'єднання, як тільки буде подолано цей поріг пам'яті.

Рекомендую ізолювати робочі процеси з інформаційних баз, наприклад вказати параметр "Кількість ІБ на процес = 1". За кількох високонавантажених баз це дозволить зменшити взаємний вплив як у надійності, і по продуктивності.

Окремий внесок у стабільність системи робить «витрачання» ліцензій/ключів. У 8.3 з'явилася можливість використання менеджера програмних ліцензій» Нагадуючи менеджер «Аладіна». Мета – можливість винести ключ на окрему машину.

Реалізовано він у вигляді ще одного «сервісу» менеджера кластера. Ви можете використовувати, наприклад, «вільний» ноутбук. Додайте його до кластера 1с 8.3, створіть на ньому окремий менеджер із сервісом «сервіс ліцензування». У ноутбук можна встромити апаратний hasp-ключ, або активувати програмні ліцензії.

Найбільший інтерес для програмістів має становити «Вимоги призначення функціональності».

Вимоги призначеної функціональності 1с

Так на ноутбуці з ключем захисту, щоб не запускати користувачів на сервер кластера, треба додати «вимоги» для об'єкта вимоги «Клієнтське з'єднання з ІБ» - «Не призначати», тобто. заборонити робочим процесам даного сервераобробляти клієнтські з'єднання.

Ще більший інтерес надає можливість запускати лише фонові завдання на робочому сервері кластера без сеансів користувачів. Таким чином можна високонавантажені завдання (код) винести на окремі машини. При чому можна одне фонове завдання "закриття місяця" через "Значення додаткового параметра" запускати на одному комп'ютері, а фонове завдання "Оновлення повнотекстового індексу" на іншому. Уточнення відбувається через вказівку "Значення додаткового параметра". Наприклад, якщо вказати BackgroundJob.CommonModule як значення, можна обмежити роботу робочого сервера в кластері тільки фоновими завданнями з будь-яким вмістом. Значення BackgroundJob.CommonModule.<Имя модуля>.<Имя метода>- Вкаже конкретний код.

Кластер 1С 8.2

Сеанси дозволяють виконувати балансування завантаженості та відмовостійкості в керованому додатку.

Менеджер кластера тепер став складнішим. Частину функцій тепер можна виділити окремий процес і навіть розмістити іншому робочому сервері кластера. Це дозволяє балансувати завантаженість сервера.

Відмовостійкість сервера 8.2 досягається за рахунок:

Зберігання інформації про сеанс роботи користувача.
Користувач не прив'язаний більше до робочого процесу.
Резервування робочих процесів у кластері.
Має бути кілька робочих процесів, у тому числі резервовані
Резервування кластерів.

Вказується запасний кластер, при підключенні - перераховуються у рядку з'єднання

Це дозволяє забезпечити безперервність роботи!

При розриві фізичної сполукиклієнта з кластером (прибиральниця висмикнула кабель, відключилося харчування) мережевого обладнання, неполадки у провайдера) не доводиться знову підключатися до інформаційної бази і починати всю роботу спочатку. Після відновлення фізичного з'єднання користувач може продовжити роботу з місця, на якому вона була перервана.

Якщо необхідно технічне обслуговуваннякомп'ютерів кластера, їх можна вимикати під час роботи, не зупиняючи роботу користувачів з інформаційною базою.

При виході з ладу будь-якого сервера кластера робота користувачів не зупиниться, вона буде автоматично переведена на резервний кластер та/або на резервні робочі процеси. Для користувачів такий перехід буде непомітним.

Якщо один із робочих процесів кластера завершиться аварійно, користувачі будуть автоматично переведені на інші або резервні робочі процеси. Такий перехід також буде непомітним для користувачів.

Найчастіше на машині разом із сервером 1С:Підприємство працюють інші служби - термінальний сервер, SQL-сервер і т.д. І в якийсь момент сервер 1С:Підприємство, а точніше робочий процес rphost від'їдає пам'яті більше ніж планувалося або всю пам'ять. Що призводить до уповільнення роботи інших служб та зомбування сервера. Щоб уникнути таких ситуацій, необхідно налаштувати автоматичний перезапуск робочих процесів сервера 1С:Підприємства

Рішення

1. Відкриємо консоль адміністрування серверів 1С Підприємства;
2. Розгорнемо дерево центрального сервера до кластерів і виділимо цікавий наc кластер. У прикладі кластер лише один;
3. Відкриємо властивості виділеного кластера та побачимо наступну форму

Властивості кластера сервера 1С:Підприємство 8.3

Розберемо приклад, вказаний на зображенні:

Інтервал перезапуску— час, через який процес rphost буде примусово перезапущений. Перед завершенням роботи процесу запускається новий процес rphost, на який передаються всі з'єднання, і лише тоді буде завершено роботу старого процесу. На роботі користувача це ніяк не позначиться. Інтервал вказується в секундах, у прикладі вказано 24 години.

Допустимий обсяг пам'яті— обсяг пам'яті, у якого робочий процес може без проблемно працювати. Обсяг вказується в кілобайтах, у прикладі вказана величина 20 гігабайт (насправді цифра занадто велика і необхідно відштовхуватися від конкретної системи, але середня цифра 4 Гб). Як тільки пам'ять зайнята робочим процесом перевищить зазначену величину, починається відлік часу.

Інтервал перевищення допустимого обсягу пам'яті— після того, як таймер запущений після перевищення допустимого обсягу пам'яті відрахує вказаний час, буде запущено новий робочий процес, на який передаються всі з'єднання, старий процес позначається як вимкнений. Інтервал вказується в секундах, у прикладі вказано 30 секунд.

Вимкнені процеси зупиняти через— час, через який буде зупинено робочий процес, позначений як вимкнений, якщо вказано значення 0, процес не буде завершений. Інтервал вказується в секундах, у прикладі вказано 60 секунд.

Після застосування налаштувань можна не перезапускати службу сервера, вони застосовуватимуться динамічно.

Разом

Так ми налаштували автоматичний перезапуск робочих процесів сервера 1С:Підприємства та отримуємо більш стабільну систему, якщо відбувається витік пам'яті, то буде припинено роботу конкретного сеансу.

Так само в деяких ситуаціях можна грати налаштуваннями, і запобігти можливому падінню сервера при допущенні помилок.

Сервер став більш «автонастроюваним», частина параметрів типу кількості робочих процесів тепер не створюється вручну, а розраховується виходячи з описів вимог завдань з відмовостійкості та надійності.

Отримав розвиток механізм балансування навантаження, який можна використовувати або для підвищення продуктивності системи в цілому, або використовувати новий режим «економії пам'яті», який дозволяє працювати «з обмеженою пам'яттю» у випадку, якщо конфігурація «любить від'їдати пам'ять».

Особливо цікавим є параметр "безпечна витрата пам'яті за один виклик". Для тих хто погано уявляє, що це таке - краще не тренуйтеся на "продуктивній" базі. Параметр "Максимальний обсяг пам'яті робочих процесів" дозволяє при переповненні не обвалювати весь робочий процес, а тільки один сеанс "з невдахою". "Обсяг пам'яті робочих процесів, до якого сервер вважається продуктивним" дозволяє заблокувати нові з'єднання, як тільки буде подолано цей поріг пам'яті.

Окремий внесок у стабільність системи робить «витрачання» ліцензій/ключів. У 8.3 з'явилася можливість використання менеджера програмних ліцензій нагадуючи менеджер аладина. Мета – можливість винести ключ на окрему машину.

Найбільший інтерес для програмістів має становити «Вимоги призначення функціональності».

Так на ноутбуці з ключем захисту, щоб не запускати користувачів на сервер кластера, треба додати «вимоги» для об'єкта вимоги «Клієнтське з'єднання з ІБ» — «Не призначати», тобто. заборонити робочим процесам даного сервера обробляти клієнтські з'єднання.

Зрозуміло, що немає сенсу переказувати документацію. Але якщо хтось порадить слушне, розширю статтю.

Друк (Ctrl+P)

У цій статті я роблю огляд основних заходів, які потрібно виконати для збільшення продуктивності 1С у клієнт-серверному варіанті роботи 1С:

Збільшення апаратних потужностей.
Налаштування сервера 1С: Підприємства
Налаштування SQL сервера
Оптимізація коду та алгоритмів у 1С.

1. Збільшення апаратних потужностей

Мінімальні вимоги до комп'ютерів, представлених на сертифікацію у фірму «С» для отримання логотипу «Сумісно! Система програм 1С:Підприємство» написані

Продуктивність сервера 1С: підприємство досить сильно залежить від частоти процесора, а для сервера бази даних характеристики комп'ютера повинні відповідати вимогам Microsoft SQL Server, PostgreSQL, IBM DB2, Oracle Database.

2. Налаштування сервера 1С: Підприємства

Інструкція з налаштування робочих серверів із Технологічною Платформою 1С:Підприємство можна подивитися на диску ІТС

У версії 8.3 було додано кілька нових параметрів у налаштуванні робочих серверів:

Максимальний обсяг пам'яті робочих процесів. Налаштування дозволяє регулювати обсяг пам'яті, який можуть зайняти всі робочі процеси кластера на даному робочому сервері.
Безпечна витрата пам'яті за один виклик. Налаштування дозволяє обмежити обсяг пам'яті, який буде зайнятий під час виконання серверного виклику на цьому робочому сервері.
Кількість ІБ на процес та кількість з'єднань на процес. Ці налаштування дозволяють опосередковано регулювати кількість робочих процесів на цьому робочому сервері.
Менеджер під кожний сервіс. Налаштування дозволяє запустити кожний сервіс менеджера кластеру як окремий процес.

3. Налаштування SQL сервера

Особливість налаштування Microsoft Sql Server з метою збільшення продуктивності можна подивитися на диску ІТС

За допомогою Maintenance Plan у розділі Management необхідно виконувати для підвищення продуктивності наступні регламентні завдання:

Дефрагментацію індексів та оновлення статистики необхідно проводити щодня, т.к. якщо фрагментованість індексів > 25%, це різко знижує продуктивність сервера.
Дефрагментація та оновлення статистики – робиться швидко та не вимагає відключення користувачів. Також рекомендується робити щодня.
Повна реіндексація – робиться із блокуванням БД, рекомендується робити хоча б раз на тиждень. Звичайно, після повної переіндексації одразу ж робиться дефрагментація індексів та оновлення статистики.

3.1 Аналіз ступеня фрагментації індексів

Надмірна фрагментація індексів створює проблеми великих операцій вводу-вывода. Після виконання інтенсивних операцій з модифікації даних у таблицях бази даних збільшується час виконання запитів та операцій з модифікації даних.

Це зумовлено тим, що при таких операціях відбувається модифікація індексів, що призводить до їх фрагментації та збільшення кількості операцій уведення-виведення при використанні індексів у процесі виконання операцій читання та запису даних.

Для ефективності використання індексів Microsoft SQL Server потрібно

Регулярна переіндексація таблиць бази даних за допомогою команди DBCC DBREINDEX ( table_name ) .
Регулярна дефрагментація індексів бази даних за допомогою команди DBCC INDEXDEFRAG (database_name, table_name, index_name) .

Вибір способу вирішення цієї проблеми залежить від інтенсивності операцій модифікації таблиць бази даних.

У MS SQL Server 2005 з'явилися нові засоби контролю цього параметра.

Функція таблиці динамічного керування sys.dm_db_index_physical_statsповертає відсоток фрагментації у стовпці avg_fragmentation_in_percent. Якщо значення в цьому стовпці перевищує 25%, для відновлення вихідних параметрів продуктивності рекомендується виконати дефрагментацію цього індексу. Від зниження фрагментації індексів можуть виграти операції сканування великих діапазонів даних, звичайні у додатках сховищ даних та звітів.

Використання цієї інформації може суттєво знизити навантаження на систему та уникнути непотрібних операцій із дефрагментації тих індексів, для яких вона не потрібна.

3.2 Використання фізичної пам'яті розміром більше 2 ГБ у Microsoft SQL Server

Microsoft SQL Server 2000 Standard Editionта Microsoft SQL Server 2005 Workgroup Editionможуть використовувати до 2 ГБ фізичної пам'яті, яка динамічно розподіляється та звільняється залежно від робочого навантаження. У разі збільшення обсягів бази даних цього обсягу оперативної пам'ятістає недостатньо для ефективного кешування даних та підтримки продуктивності на прийнятному рівні.

3.3 Зменшення розміру журналу транзакцій Microsoft SQL Server

Виконання інтенсивних операцій із модифікації даних інформаційної бази призводить до збільшення розмірів файлів даних та журналу транзакцій. У якийсь час старі записи журналу транзакцій стають не потрібними для відновлення бази даних і можуть бути видалені, звільняючи тим самим місце для нових записів. Якщо вчасно не видаляти старі записи журналу транзакцій, через деякий час файл журналу транзакцій може зайняти все вільне дисковий простірі робота з базою даних стане неможливою.

Для зменшення розміру файлу журналу необхідно видалити неактивні записи журналу транзакцій за допомогою команди BACKUP LOGа потім вже за допомогою команди DBCC SHRINKFILEзменшити розмір файлу журналу транзакцій. Послідовність команд, яку потрібно виконати в Query Analyzer, виглядає наступним чином:

BACKUP LOG Ім'я_Бази_Даних WITH TRUNCATE_ONLY

DBCC SHRINKFILE(Ім'я_Файла_Журналу_Транзакцій)

3.4 Переміщення бази даних TEMPDB на інший більший диск.

TEMPDB є системною базою даних Microsoft SQL Server, де зберігаються тимчасові таблиці, створені як самим сервером, і користувачами. Ця база даних створюється заново під час кожного перезапуску Microsoft SQL Server. За замовчуванням розмір цієї бази даних необмежений і збільшення його здійснюється за потреби автоматично, порціями по 10% від поточного розміру TEMPDB. Однак, ці параметри можуть бути перевизначені користувачем. За промовчанням мінімальний розмір цієї бази даних, який встановлюється при старті Microsoft SQL Server, визначається розміром системної базиданих MODEL. Очищення журналу транзакцій у цій базі даних здійснюється автоматично, при цьому видаляються лише неактивні записи журналу транзакцій.

Під час роботи 1С:Підприємства 8 в режимі клієнт-сервер широко використовуються тимчасові таблиці . Крім того, TEMPDB використовуєтьсяMicrosoft SQL Server при виконанні запитів, які використовують оператори GROUP BY, UNION, DISTINCTі т.п.

У процесі роботи 1С:Підприємства 8 можливе значне збільшення розміру бази даних TEMPDB. Якщо розмір диска, на якому розташована база даних TEMPDB, виявиться недостатнім, робота 1С:Підприємства 8 може завершитися аварійно.

Якщо ця проблема проявляється регулярно, рекомендується перемістити TEMPDB на інший диск більшого розміру.

Цю операцію можна виконати у такий спосіб:

1. визначити логічні імена файлів бази даних TEMPDB (колонка “NAME” результату виконання процедури). Для цього потрібно в Query Analyzer виконати таку команду:

USE tempdb GO EXEC sp_helpfile GO 2.змінити розташування файлів бази даних TEMPDB за допомогою команди ALTER DATABASE. Для цього потрібно в Query Analyzer виконати наступну послідовність команд: USE master GO ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, FILENAME = "Новий_Диск:\Новий_Каталог\tempdb.mdf") GO ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = "Новий_Диск:\Новий_Каталог\templog.ldf") GO 3. Перезапустити Microsoft SQL Server.

4. Оптимізація коду та алгоритмів у 1С

4.1 Оптимізація запитів

Значна частина проблем, що призводять до неоптимальної роботи запитів, може бути виявлена шляхом аналізу коду конфігурації та структури метаданих. Є список типових помилоку коді та структурі даних, наслідки яких досить добре вивчені та легко передбачувані. Аналіз коду з використанням цього переліку дозволяє вирішити більшу частину проблем із продуктивністю запитів, не заглиблюючись у детальну. технічну інформацію(текст запиту на мові SQL, план запиту і т.д.).

Основні причини неоптимальної роботи запитів, що діагностуються на рівні коду конфігурації та структури метаданих розглядаються на диску ІТС:

з'єднання з підзапитами
з'єднання з віртуальними таблицями
невідповідність індексів та умов запиту
використання логічного АБО в умовах
використання підзапитів за умови з'єднання
отримання даних через точку від полів складового типу
фільтрація віртуальних таблиць без використання параметрів

4.2 Використання вимірювання продуктивності

1С:Підприємство 8 дозволяє налагоджувати та вимірювати продуктивність для коду вбудованою мовою, що виконується як на клієнті, так і на сервері. Особливістю роботи виміру продуктивності для клієнт-серверної інформаційної бази в 1С:Підприємстві 8 є те, що результати виміру продуктивності об'єднуються в один файл. Вони включають дані про хід виконання коду вбудованою мовою як на клієнті, так і на сервері. Для отримання такого виміру достатньо запустити сервер 1С: Підприємства 8 у режимі налагодження (за допомогою ключа командного рядка /debug)і в конфігураторі в потрібний момент просто включити режим вимірювання продуктивності.

Режим виміру продуктивності в 1С: Підприємстві 8 дозволяє успішно оптимізувати роботу клієнт-серверних додатків. Для виконання такої оптимізації достатньо виконати лише кілька дій, після чого проаналізувати результати виміру продуктивності та перейти до покращення коду вбудованою мовою.

Докладніше про використання виміру продуктивності можна подивитися на диску ІТС.

Перед початком робіт з оптимізації системи необхідно завжди отримувати початкову оцінку продуктивності за допомогою “Оцінки інтегральної продуктивності системи за методикою APDEX”.

4.3 Інструменти рефакторингу коду

Функції рефакторингу коду, реалізовані в конфігураторі платформи 8.3.5, 1068. автоматичного перетвореннямодальних методів та ділянок коду показано на рис 1.

Рис 1 Інструменти рефакторингу коду в конфігураторі

Необхідність цих інструментів розробники платформи пояснюють тим, що код прикладних рішеньмає бути зрозумілим, особливо коли над конфігурацією працює група з кількох розробників. Тоді програмний кодлегко підтримувати та модифікувати.

Перемога далася нелегко.
Я постараюся описати все детально, хоч і минуло чимало часу. Сподіваюся інформація, зібрана мною допоможе системним адміністраторамі дасть пишу для роздумів.
Переніс я бази на 1 скуль і перепризначив користувача для 8.3 агента – не допомогло…

Знівечив я наш рунет вздовж і впоперек і знайшов дві цікаві статті, які пропоную і вам ознайомитися.

Вперше досить детальний тестміж двома платформами: ПС-мідл варіанта та двоядерного сервера. З'ясовується досить цікаві моментиякі були підкреслені і мною під час роботи в інших компаніях.
efsol.ru/articles/tuning-1c.html

Друга ж відноситься до тестів 1с на віртуальних машинах. У ній я і побачив причину затримки запуску конфігурації:
efsol.ru/articles/performance-comparison-1c.html

Покопавшись десь із тиждень і перепробувавши кілька методик, проблему з першим запуском я вирішити не зміг. Але помітив одну цікаву закономірність. тонкого клієнта, Другий запуск системи відбувається майже моментально. Змінив налаштування кількість ІБ на процес: 8 (баз на 8.3 поки що 5). У результаті оскільки створення RPHOST сервер перестав витрачати час під час заходу у слід. основу і решту він витрачав тільки на вивантаження конфи зі скиля. Скоротив час старту другої бази на 10-7 секунд.

Такий варіант мене в принципі влаштовує повністю, враховуючи, що з кожною базою працює по 7-10 користувачів, конфа тримається постійно в RPHOSTe і час заходу дорівнює 4-8 секунд з автентифікацією разом.

Якщо ж у вас є проблеми, що базу відкривають не часто, то як варіант можу запропонувати напиляти невелике рег. завдання із заходу корист. у кожну базу та налаштувати перезавантаження сервісу на вечірній час (або через сервіси чи інтервал перезапуску). Думаю, це має допомогти, хоча тут ми упираємося в наявність ліцензії, тому треба думати)))

Але сплив ще один неприємний момент, на одному з форумів я отримав таку відповідь:
Offtop. У вас ліцензії КОРП?

Розширені можливості сервера рівня КОРП «1С:Підприємства 8.3» порівняно з 64-розрядним сервером рівня ПРОФ:
* безпечна витрата пам'яті за один виклик;
* кількість ІБ на процес;
* обсяг пам'яті робочих процесів, до якого сервер вважається продуктивним;
* максимальний обсяг пам'яті робочих процесів;
*стратегія балансування (по пам'яті, за продуктивністю);

Використання перерахованих функціональних можливостейза допомогою продуктів «1С:Підприємство 8. Ліцензія на сервер (x86-64)» рівня ПРОФ, тобто позначки КОРП, що не мають в назві, є неправомірним.

Вирішив уточнити у хлопці із трьох різних компанійЧи знають вони що є платформа корп і проф. На що була отримана відповідь у вигляді: пальця, що крутиться біля скроні і посилка на форум 1с. І ось нижче відповідь від саппорта 1с:

1) >>> Хотілося б уточнити різницю між платформою 8.3 корп і 8.3 проф.
https://partners.v8.1c.ru/forum/message/1301566#m_...
www.1c.ru/news/info.jsp?id=16733

Фактично при використанні Платформи ПРОФ, згідно з ліцензією, можна використовувати лише дефолтні налаштування кластера.

Якщо при налаштуваннях кластера "за замовчуванням" у Вас виникають проблеми (нестача пам'яті, неможливість оновити конфігурацію тощо), то
ця поведінка є помилкою (або платформи або даного прикладного рішення).
Прохання з конкретними прикладамистворювати звернення на виправлення.
На час виправлення помилки може бути письмово видано дозвіл (за підписом директора ЗАТ "1С") використання функціонала ліцензії Корп.
2) >>> Прошу уточнити, тобто. Є дві платформи 8.3?
Ні. Платформа не поточний момент одна.
Проте право використання функціоналу КОРП з'являється лише за умови придбання відповідної ліцензії.
Програмного контролю цієї ліцензії на даний момент також немає.
Таким чином, ліцензія КОРП є більш юридичним поняттям.

Чесно кажучи, я не вірю в різні види змов, але коли компанія має майже 100% монополію на ринку малого та середнього бізнесу думки лізуть різні.
«Вийде оновлення якоїсь конфігурації для здачі звітності, яка вимагатиме оновлення платформи, в якій вже буде реалізований програмний контроль... І тут то ви нам (1с) проплатите по повній с...ни діти.»
P.S. Хочу уточнити що сервер у мене на базі 2008r2 і можуть бути відмінності від 2012. Все ж таки ядро там детально перепиляне і hyper-v 3.0 теж плюшками під ріс. Але як кажуть «IT`s Alive!!!» і робота 1с на віртуальних машинах не тільки можлива, а й вітається. На виході ми маємо 30 користувачів 8.2 та 20 користувачів 8.3. Успіхів Вам усім, будьте терпимішими і ніколи не здавайтеся)))