Основні можливості кластера серверів

Найчастіше для установки 1C:Підприємства 8.х у варіанті “клієнт-сервер” достатньо запуску програми установки 1С:Підприємства 8.х. У цьому сервер 1С:Підприємства отримує стандартні значення параметрів, необхідні його нормального функціонування.

Розглянемо встановлення сервера 1С:Підприємства більш детально. У процесі встановлення сервера 1С:Підприємства 8.х програма установки 1С:Підприємства 8.х виконує такі дії:

* Копіює завантажувальні модулі сервера 1С:Підприємства в каталог, вказаний програмі установки 1С:Підприємства як кінцева папка.
* Якщо в процесі установки вибрано "Створити користувача USR1CV81", створює користувача USR1CV81. Від імені цього користувача працює сервер 1С:Підприємства 8.1, якщо він запускається як сервіс. Йому доступні ті ресурси, які необхідні серверу 1С:Предприятия. Важливо, що серверу 1С:Підприємства для роботи необхідні два каталоги: загальний каталог з даними сервера (зазвичай "C: Program Files 1cv81 server") і каталог тимчасових файлів (звичайно C: Documents and Settings usr1cv81 Local Settings \Temp" або "C:\WINNT\Temp"). Користувач USR1CV81 отримує права на загальний каталог із даними сервера. Каталог тимчасових файлів зазвичай доступний для всіх користувачів.
* Якщо в процесі установки включено "Встановити сервер 1С:Підприємства 8.1 як сервіс Windows", то реєструє в Windows сервіс агента сервера 1С:Підприємства та запускає його. При першому запуску створюється кластер серверів 1С:Підприємства з стандартними налаштуваннями. У ньому один робочий сервер та один робочий процес. Адреса робочого сервера збігається з ім'ям комп'ютера, на якому встановлена ​​установка.

Користувач USR1CV81 або USR1CV82 та його права

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

Розглянемо докладніше права, які встановлюють користувач USR1CV81. Сервер 1С:Підприємства використовує такі каталоги:

* Каталог завантажувальних модулів знаходиться в каталозі, заданому програмі установки 1С: Підприємства як кінцева папка. У ньому розташовані завантажувальні модулі сервера 1С:Підприємства. Користувач USR1CV81 необхідні права на читання даних та запуск програм з цього каталогу та його підкаталогів. Він отримує ці права неявно завдяки включенню до групи Users.
* Каталог даних сервера зазвичай має ім'я "C: Program Files 1cv81 server". Користувачеві USR1CV81 необхідні повні права на цей каталог. Програма встановлення 1С:Підприємства при створенні користувача USR1CV81 наділяє його правами на цей каталог.
* Каталог тимчасових файлів зазвичай має ім'я "C:\Documents and Settings\usr1cv81\Local Settings\Temp" або "C:\WINNT\Temp", яке визначається значенням змінної TEMP оточення користувача або змінної TEMP системного оточення. Подивитися значення цієї змінної можна в діалозі System Properties (Start -> Settings -> Control Panel -> System -> Advanced -> Environment Variables). Програма установки 1С:Підприємства задає користувачу USR1CV81 повні права на цей каталог. Зазвичай при інсталяції Windows каталог тимчасових файлів доступний всім користувачам за допомогою включення до списку доступу групи CREATOR OWNER. Однак це доступ не повний. Зокрема, всім користувачам не доступна операція пошуку файлів у цьому каталозі. Установка користувачу USR1CV81 повних прав на каталог тимчасових файлів дозволяє серверу 1С:Підприємства виконувати всі необхідні йому операції. Подивитися список доступу можна у діалозі властивостей каталогу на закладці Security. Наявність групи CREATOR OWNER дозволяє звертатися до каталогу будь-якому користувачеві, який створює файли в цьому каталозі або володіє якими-небудь файлами в цьому каталозі. При цьому в списку доступу створеного файлу замість групи CREATOR OWNER буде записаний користувач, який створив файл. Серед користувачів, яким дозволено доступ до цього каталогу, має бути і користувач USR1CV81, наділений повними правами на цей каталог.
Важливо пам'ятати, що каталог тимчасових файлів певного користувача (зокрема і користувача USR1CV81) визначається комбінацією змінних оточення цього користувача та системних змінних оточення. Щоб дізнатися цей каталог, програма встановлення 1С:Підприємства запитує контекст користувача USR1CV81. Для цього в Windows 2000 користувачу, від імені якого запускається програма установки 1С:Підприємства, можуть знадобитися привілеї: Act as part of the operating system і Bypass traverse checking. Перевірити привілеї користувача можна утилітою Local Sequrity Settings у гілці Local Policies -> User Rights Assignment. У процесі встановлення нового програмного забезпечення програма установки зазвичай отримує ці привілеї автоматично.

Реєстрація сервера 1С:Підприємства як сервісу Windows

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

Для перегляду списку сервісів Windows та їх параметрів призначена утиліта Component Services (Start -> Settings -> Control Panel -> Administrative Tools -> Services). Сервер 1С:Підприємства представлений у списку сервісів сервісом "Агент сервера 1С:Підприємства 8.1". Параметри сервісу визначають запуск процесу "Агент сервера 1С:Підприємства" (ragent), користувача, від якого він запускається, а також спосіб перезапуску в аварійних ситуаціях.

У діалозі властивостей сервісу "Агент сервера 1С:Підприємства 8.1" на закладці General показано рядок запуску процесу ragent, який є Агентом сервера 1С:Підприємства. Зазвичай цей рядок має вигляд:


У ній зазначено, що:

* процесом Агента сервера є завантажувальний модуль "C: Program Files 1cv81 bin ragent.exe";
* процес ragent запускається як сервіс Windows і має управлятися менеджером сервісів (-srvc);
* використовується як Агент сервера 1С:Підприємства (-agent);
* при першому запуску сервісу повинен бути створений кластер з параметрами за промовчанням та головним IP-портом номер 1541 (-regport 1541). У цьому порту клієнтські додатки повинні з'єднуватися з інформаційними базами, зареєстрованими у кластері;
* IP-порт агента сервера повинен мати номер 1540 (port 1540). У цьому порту Консоль кластера має з'єднуватися з центральним сервером для виконання адміністративних функцій;
* при запуску процесів кластера на даному сервері їм динамічно призначатимуться IP-порти з діапазону 1560-1591 (-range 1560:1591).
* загальні дані кластера будуть розміщені в каталозі "C: Program Files 1cv81 server" (-d "C: Program Files 1cv81 server").

Сервіс "Агент сервера 1С:Підприємства 8.1" може бути доданий або видалений не тільки при встановленні або видаленні 1С:Підприємства програмою встановлення 1С:Підприємства 8.1, але й вручну. Для цього можна виконати з командного рядка утиліту ragent, вказавши відповідні параметри.

Для створення сервісу потрібно вказати параметр -instsrvc та параметри: -usr - ім'я користувача, від імені якого має бути запущено сервіс, -pwd - пароль цього користувача. При цьому решта параметрів стане параметрами рядка запуску Агента сервера 1С:Підприємства як сервісу. Наприклад, для стандартної реєстрації сервісу Агента сервера 1С:Підприємства у налагоджувальному режимі набір параметрів повинен бути таким:

"C:\Program Files\1cv81\bin\ragent.exe" -instsrvc -usr .\USR1CV81 -pwd Password -regport 1541 -port 1540 -range 1560:1591 -d "C:Program Files\1cv81\server" - debug

Для видалення сервісу необхідно вказати параметр -rmsrvc. Наприклад:
"C:\Program Files\1cv81\bin\ragent.exe" -rmsrvc

Іноді буває поліно змінити рядок запуску Агента сервера або інші параметри сервісу Агента, наприклад, увімкнути режим налагодження або створити кілька сервісів різних версій. Діалог властивостей сервісу не дозволяє редагувати рядок запуску сервісної програми та деякі інші параметри, наприклад, ідентифікатор сервісу. Для редагування потрібна утиліта regedit, призначена для перегляду та редагування реєстру Windows.

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

Запустіть утиліту regedit (відкрийте Start -> Run і наберіть regedit) і оберіть гілку:


Серед її параметрів є параметр ImagePath, значенням якого є рядок запуску Агента сервера 1С:Підприємства. Тут можна додати нові параметри запуску або змінити значення існуючих. Повний список можливих параметрів наведено у книзі "1С:Підприємство 8.1 Клієнт-сервер" документації.

При необхідності реєстрації кількох незалежних сервісів Агента сервера 1С:Підприємства потрібно вказати їм різні модулі завантаження, різні порти і різні каталоги даних кластера. Також потрібно зареєструвати їх з різними ідентифікаторами сервісів. Це можна зробити так:

* Створити перший сервіс:
"C:\Program Files\1cv81\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:Program Files\1cv81\server"

* За допомогою утиліти regedit змінити ідентифікатор зареєстрованого сервісу. Для цього: вибрати гілку
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.1 Server Agent

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.1 Server Agent First
* Створити другий сервіс:
"C:\Program Files\1cv81_10\bin\ragent.exe" -srvc -agent -regport 1641 -port 1640 -range 1660:1691 -d "C:Program Files\1cv81_10\server"

* Можливо, його ідентифікатор теж змінити. Для цього: вибрати гілку
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.1 Server Agent
і змінити її ім'я, наприклад:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.1 Server Agent Second

Що не може зробити програма встановлення 1С:Підприємства?

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

Щоб сервер 1С:Підприємства був доступний з інших комп'ютерів у локальній мережі, необхідно перевірити налаштування мережі на серверному та клієнтському комп'ютері, а також для мережі в цілому. Для передачі даних між клієнтськими програмами та сервером 1С:Підприємства, а також між процесами кластера серверів використовується TCP/IP. Від правильності його налаштування залежить робота 1С:Підприємства у варіанті клієнт-сервер.

Процеси кластера серверів 1С:Підприємства з'єднуються один з одним за адресами, визначеними як значення властивості "Комп'ютер" діалогу властивостей робочих серверів. Для кластера необхідно, щоб значенням властивості "Комп'ютер" була або IP-адреса в точковій нотації, або така символічна адреса, за якою може бути визначена IP-адреса за допомогою функції gethostbyname, визначеної в програмному інтерфейсі протоколу TCP. Визначення IP-адреси виконується або на підставі локальної таблиці символічних адрес (C:WINNTsystem32driversetchosts), або за таблицями адрес у доступних DNS серверах. Якщо за символічною адресою робочого сервера його IP-адреса не визначається або визначається неправильно (наприклад, IP-адреса не збігається з фактичною IP-адресою даного комп'ютера), то кластер не працюватиме. Важливо, щоб імена комп'ютерів та їх адреси, визначені у Windows кожному з робочих серверів кластера, не суперечили їх іменам в DNS.

На кожному робочому сервері процеси кластера використовують такі порти: IP порт робочого сервера (зазвичай 1540); IP порти з діапазонів IP портів робочого процесу (зазвичай 1560-1591). Крім того, на центральному сервері кластера використовується порт кластера (зазвичай 1541). Якщо в системі використовуються мережні екрани, то передача даних по цих портах має бути дозволена. Замість дозволу портів із наведеного списку можна дозволити передачу даних процесам кластера (ragent, rmngr, rphost).

З'єднання клієнтського додатка 1С: Підприємства із сервером виконується у 2 етапи. Спершу воно встановлює з'єднання з менеджером кластера. При цьому використовується адреса центрального сервера (символічний або числовий) та порт кластера (зазвичай 1541). Далі клієнтська програма встановлює з'єднання з одним із робочих процесів. Як його адреса використовується значення властивості "Комп'ютер" відповідного робочого сервера та порт робочого процесу, який вибирається з діапазону IP портів робочого сервера. Передача даних на ці порти має бути дозволена у всіх мережевих екранах на маршруті від комп'ютера клієнтської програми до комп'ютерів кластера серверів 1С:Підприємства. Визначення IP-адреси серверних процесів виконується за допомогою функції gethostbyname на комп'ютері клієнта. Важливо, щоб імена центрального та робочих серверів та їх адреси, визначені в Windows на кожному із серверів кластера, не суперечили їхнім іменам у DNS, доступному комп'ютеру клієнта.

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

Особливості налаштування SQL-сервера

1С:Підприємство у варіанті «клієнт-сервер» використовує для зберігання даних SQL-сервер. При цьому до SQL-сервера звертається лише Сервер 1С:Підприємства. Клієнти 1С: Підприємства безпосереднього доступу до SQL-сервера не мають. Встановлення та налаштування SQL-сервера детально описано в документації Microsoft SQL Server. Для успішної роботи сервера 1С:Підприємства з SQL-сервером необхідно звернути особливу увагу на наступні налаштування.

* Необхідні компоненти SQL-сервера. Для доступу до SQL-сервера з боку Сервера 1С:Підприємства на комп'ютері Сервера 1С:Підприємства повинні бути встановлені компоненти Microsoft Data Access 2.6 або пізніший.
* Аутентифікація користувача SQL-сервером. Права доступу до баз даних SQL-сервера визначаються користувачем, від імені якого відбувається звернення до баз даних. З комп'ютера, на якому встановлено SQL-сервер, запустимо утиліту SQL Server Enterprise Manager, знайдемо вузол Local (Console Root -> Microsoft SQL Servers -> SQL Server Group -> (Local)) та відкриємо його властивості. На закладці Sequrity можна бачити, що SQL-сервер підтримує два способи автентифікації користувачів: SQL Server і Windows та Windows лише. Аутентифікація Windows дозволить Серверу 1С:Підприємства звертатися до SQL-серверу тільки від імені користувача USR1CV81, що не дозволяє розрізняти права доступу до різних інформаційних баз, які обслуговує один сервер 1С:Підприємства. Рекомендовано вибирати режим SQL Server та Windows. У цьому випадку звернення до конкретної інформаційної бази виконуватиметься від імені користувача, який заданий як користувача SQL-сервера під час створення даної інформаційної бази. Важливо, що цей користувач повинен мати не лише повні права на базу даних інформаційної бази, але й права на створення баз даних у SQL-сервері та читання таблиць бази даних Master.
* Мережеві протоколи для доступу до SQL-сервера. Якщо сервер 1С:Підприємства та SQL-сервер розміщені на різних комп'ютерах, то необхідно виконати налаштування мережевих протоколів доступу до SQL-сервера. Це можна зробити за допомогою утиліти SQL Server Client Network Utility. На закладці General можна вибрати список протоколів мережі, які використовуються для доступу до SQL-сервера. Найбільш швидким та універсальним є використання протоколу TCP/IP. При використанні інших протоколів необхідно мати на увазі, що деякі з них, наприклад Named Pipes, виконують додаткову аутентифікацію засобами Windows під час обміну даними із SQL-сервером. У цьому випадку для успішної роботи з SQL-сервером на комп'ютері з SQL-сервером повинен бути зареєстрований користувач USR1CV81, який має відповідні права. Протокол доступу до цього SQL-сервера може бути змінений на закладці Alias.

На додаток до статті

Немає сумніву, що зв'язка MS SQL Server + сервер "1С: Підприємство 8" - у своїй ніші найбільш затребувана і зв'язка, що часто застосовується. Для її якісної підтримки бажане розуміння обох продуктів. У той же час, на практиці спеціаліст підтримки зазвичай або спеціалізується на адмініструванні MS SQL Server і не орієнтується в особливостях сервера "1С: Підприємство 8", або, навпаки, спеціалізується на адмініструванні сервера "1С: Підприємство 8" і не орієнтується в особливостях MS SQL Server.

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

Для полегшення сприйняття інформації наводяться випадки з практики, примітки та поради (виділені курсивом).

Триланкова схема

Як, можливо, вже відомо читачеві, база даних у цьому випадку має триланкову архітектуру:

Ланка 1: СУБД MS SQL Server. "Зберігає" та обслуговує базу даних, в кінцевому рахунку виконує всі види операцій з базою даних. Таким чином, продуктивність роботи бази даних, швидкість і паралельність читання-запису даних багато в чому визначаються продуктивністю MS SQL Server.

Ланка 2: Сервер "1С: Підприємство 8". Служить посередником у взаємодії між клієнтами (користувачами) та MS SQL Server. Всі клієнтські запити надсилаються на сервер, який "переводить" їх на мову запитів MS SQL Server, отримує результати виконання цих запитів, надсилає результати клієнту.

Є лише мала частина операцій, що виконуються на рівні сервера "1С: Підприємство 8", без звернення до MS SQL - це, зокрема, відстеження так званих "керованих блокувань", читання-запис "параметрів сеансу". Звернення до СУБД у разі не потрібно, оскільки ці операції проводяться з даними бази, і з допоміжною інформацією сервера.

Ланка 3: Клієнтська частина "1С: Підприємство 8". Звертається до сервера "1С: Підприємство 8", отримує від нього результати (тобто, наприклад, вибірки даних), відповідає за інтерфейс користувача.

"Хотів якнайкраще".

Після переустановки сервера "1С: Підприємство 8" користувачі скаржаться на різке падіння продуктивності. Фахівець із впровадження ПП "1С: Підприємство", який робив переустановку – лише дивується – мовляв, хотів як краще, система мала почати працювати швидше... Аналіз ситуації показав, що серверу "1С: підприємство 8" було виділено надто багато ресурсів: його Процеси (див. пункт 3) rphost зайняли 15.5 Гб з 16Гб оперативної пам'яті сервера, в результаті для поступливого MS SQL Server практично не залишилося доступної оперативної пам'яті.

Як результат - постійний "своп", непотрібне навантаження на дискову підсистему, і вкрай повільне виконання операцій із базою даних - внаслідок того, що MS SQL Server не встигає обробляти запити, що надходять від "розігнаного" сервера "1С: Підприємство 8".

Сумісність продуктів

Актуальні дані про версії MS SQL Server, що рекомендуються до використання у зв'язку з "1С: Підприємство 8", слід з'ясовувати за посиланням http://v8.1c.ru/requirements/.

На момент підготовки статті розробники фірми "1С" рекомендують наступні варіанти:

1. SQL Server 2008 R2.

2. SQL Server 2008, потрібно інсталювати пакет оновлень 1 (SP1).

3. SQL Server 2005, потрібно інсталювати пакет оновлень 3 (SP3).

Технічно можливо, але не рекомендується застосування MS SQL Server 2000, для нього потрібна установка пакета оновлень 2 (SP2) та бажана установка пакета оновлень 4 (SP4).

Слід враховувати, що на даний момент ця версія знята з підтримки, а також не має 64-розрядної версії для архітектури x86-64.

Зверніть увагу:

Необхідно звертати увагу на налаштування операційної системи: наприклад, для ефективної роботи M SQL Server 2008 під ОС Server 2008R2 потрібно відключення збалансованого режиму енергопостачання та переведення в режим максимальної продуктивності.

Установка клієнт-серверної версії "1С: Підприємство 8"

"1C встановив"

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

Звісно, ​​це нетиповий приклад виключно неуважного ставлення до роботи.

При встановленні "1С: Підприємства 8" слід враховувати, що окремо встановлюються:

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

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

При встановленні платформи слід приділити увагу вибору компонентів:

Компонента "1С: Підприємство" може не встановлюватись на сервері (серверах).

У цьому випадку сервер надаватиме клієнтським комп'ютерам доступ до баз даних "1С: Підприємство", але робота з БД в режимі користувача безпосередньо з сервера буде неможлива.

Зверніть увагу:

64-бітна версія платформи не містить клієнтської частини. Тому при встановленні на сервер окремо встановлюються 64-бітові серверні компоненти, і окремо – 32-бітові компоненти клієнтської програми.

Компонента "Сервер 1C: Підприємства" потрібна для підключення до MS SQL Server - це сервер додатків, що зв'язує ланку між платформою на клієнтських робочих місцях та MS SQL Server.

Можливе встановлення компоненти в режимі простої програми або системного сервісу, і рекомендується, звичайно, другий варіант.

При встановленні "як сервіс" ця компонента буде запускатися та виконуватися від імені обраного користувача:




Після завантаження компонента породжує кілька процесів, як-от: "агент сервера", "менеджер кластера серверів", "робочі процеси сервера".

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

Робочими процесами сервера можна буде керувати (додавати, видаляти, ставити обмеження на використання ОЗП, оголошувати основним або резервним), якщо буде встановлено компонент "Адміністрування сервера 1С: Підприємства".



Зверніть увагу:

Для 32-бітної версії сервера рекомендується встановлення робочих процесів у такій кількості, щоб не залишати оперативну пам'ять незадіяною – кожен з них має помітне обмеження на використання оперативної пам'яті від 2 до 4Гб залежно від конфігурації системи.

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

"Уроборос"

Після невдалої оптимізації налаштувань сервера "1С: Підприємство 8", користувачі просигналізували про вкрай повільну роботу системи, а системний адміністратор відзначив постійне 100% завантаження процесора на сервері.

Аналіз ситуації показав джерело проблеми - при налаштуванні було встановлено дуже маленьке обмеження використання оперативної пам'яті робочими процесами.

А річ у тому, що це обмеження працює наступним чином:

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

Встановлене обмеження було настільки маленьким (300Мб), що робочий процес було повністю обслужити навіть одного інтенсивно працюючого користувача - у результаті менеджер кластера серверів безперервно перезапускав робочі процеси і перепідключав користувачів. Як тільки створювався новий процес і користувачі до нього підключалися – ліміт оперативної пам'яті майже миттєво досягався та викликав наступний перезапуск. На це і витрачалося 100% завантаження процесора.

Компонента "Сервер 1C: Підприємства" не потрібна на клієнтських робочих місцях, та й не зможе там запуститись, оскільки вимагає фізичної наявності ключа захисту.

У випадку, якщо кількість користувачів, що підключаються, невелика (менше 50) - сервер додатків зазвичай встановлюють на тому ж комп'ютері, де працює MS SQL Server.

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

Компонента "Адміністрування сервера 1С: Підприємства" може бути корисною і на клієнтах – наприклад, за її допомогою можна побачити список інформаційних баз, підключених до заданого сервера "1С: Підприємства".

На самому сервері її рекомендується встановити.

Доступ

Зверніть увагу:

Для перевірки того, що доступ забезпечений, недостатньо використання утиліти адміністрування серверів 1C: Підприємства, а тим більше недостатньо присутності сервера в "Мережевому оточенні"!

Необхідно на кожному клієнті виконати вхід до бази даних, встановлену на сервері – тільки це дасть 100% впевненість, що доступ забезпечений.

1. Залежно від політик безпеки, для MS SQL Server застосовується автентифікація облікового запису Windows або автентифікація облікового запису MS SQL Server.




У разі створення бази даних "1С: Підприємства" система буде запитувати логін і пароль облікового запису MS SQL Server (наприклад, sa), у першому випадку логін і пароль слід залишати порожніми:



і тому користувачеві системи, від імені якого запущено сервер 1С: Підприємства, необхідно надати права в MS SQL Server, а саме:

повні права на базу даних, в якій міститься інформаційна база

доступ до бази даних master (роль public)

рекомендується – права створення бази даних, інакше кожну нову базу даних потрібно спочатку створювати засобами MS SQL Sever, а потім підключати до серверу 1С: Підприємства

рекомендується - право видалити свою базу даних

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

Порада.

Якщо у всіх користувачів одночасно зник доступ до робочої бази даних – потрібно перевірити ще раз права та ролі користувача в MS SQL Server, у тому числі встановлені для конкретної бази даних, тобто User mapping:




2. Сервер 1С: Підприємства звертається до MS SQL Server через механізм Microsoft Data Access, тому його компоненти мають бути встановлені, а користувача сервера 1С: Підприємства (див. попередній пункт) мають права їх запуск.

3. Зв'язок між клієнтами та сервером підтримується протоколом TCP, тому необхідно, щоб цей протокол підтримувався обома сторонами. Можливі проблеми зі зіставленням імені сервера та його IP адреси, наприклад, якщо використовується однорангова мережа. У такому випадку слід записати відповідність у файлі [С: WINDOWS] system32driversetchosts .

Порада.

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

4. У разі використання протоколу Named Pipes, і якщо MS SQL Server та сервер 1С: Підприємства встановлені на різних комп'ютерах – користувач, від імені якого працює сервер 1С: Підприємства, має бути зареєстрований у списку користувачів комп'ютера, на якому запущено MS SQL Server.

5. У деяких випадках може знадобитися додаткове налаштування брендмауера Windows, тобто додавання винятків.

6. Деякі антивіруси можуть блокувати "небажаний" мережевий трафік, тому може знадобитися доповнення їх списків винятків.

7. Реліз платформи "1С: Підприємства 8" має бути абсолютно однаковим на клієнті та на сервері.

"Близнюки"

"У одного із замовників застосовувалося два сервери баз даних, на кожному з яких розташовувалась одна робоча база. Користувачі працювали - кожен одночасно з обома базами. Служби підтримки виконала оновлення платформи "1С: Підприємства 8" на серверах та клієнтах…. І тут посипалися скарги на неможливість підключення - то до однієї, то до іншої бази.Аналіз ситуації показав - оновлення на клієнтах і серверах робили кілька людей, і встановлювальні фахівці не перевіряли ще раз, що встановлюють один і той же реліз.Тому на одному сервері був один реліз платформи, на другий – інший, на половині клієнтів – перший із цих релізів, на іншій половині – інший, вийшло, що кожен користувач має доступ лише до однієї з баз даних.

Для швидкого вирішення проблеми довелося встановлювати кожному користувачеві обидва релізи платформи та створювати окремі ярлики для входу до кожної бази даних.

Початкові налаштування MS SQL Server та бази даних

"І так працює"

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

Наприклад, якщо база призначена для ведення обліку – перед складанням податкової звітності найчастіше виникає необхідність терміново перерахувати ті чи інші дані, причому перерахувати масово, скажімо "всі надходження основних засобів з початку року". Причому протягом робочого дня, без зупинки роботи решти користувачів бази даних.

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

Цей свого роду "закон Мерфі" стосується кожного з наведених нижче пунктів.

Перед початком використання MS SQL Server як СУБД для "1С:Підприємство" рекомендується:

1. Встановити значення параметра max degree of parallelism рівним 1.

Тобто:

після під'єднання до сервера увійти до властивостей сервера через контекстне меню, пункт Properties

далі вибрати сторінку Advanced та відредагувати параметр max degree of parallelism

В іншому випадку деякі запити, що формуються сервером 1С: Підприємства, можуть викликати помилку "Intra-query parallelism caused your server command (process ID #XX) to deadlock. Rerun the query without intra-query parallelism by using the query hint option (maxdop 1 )". Після цієї помилки клієнтська частина найчастіше аварійно завершується.

Помилка не виявлятиметься стабільно, оскільки план запиту формується по-різному залежно від накопичених статистик – вона виявить себе на об'ємних і складних запитах, тобто в найневдаліший момент.

2. Створити План обслуговування (Maintance Plan), що обрізає (shrink) базу даних тимчасових таблиць tempdb. Автоматично база тимчасових таблиць сервером 1С: Підприємства очищається який завжди, котрий іноді, внаслідок невдало написаного запиту, може бути сформована і очищена тимчасова таблиця розміром, наприклад, 50 Гб. Внаслідок цього може закінчитися місце на диску, внаслідок цього можливе аварійне завершення і клієнтської, і серверної частини, також є невеликий ризик порушення цілісності даних.

Тобто потрібно:

зайти до MS SQL Management Studio

після під'єднання до сервера розкрити розділ "Maintance plans"

створити новий (або доповнити наявний) План обслуговування,

додати до нього пункт "Execute T-SQL Statement task" (оскільки завдання "Shrink database" не можна вибрати базу tempdb) з кодом

1.USE
2.
3.GO
4.
5.DBCC SHRINKFILE (N"tempdev", 0, TRUNCATEONLY)
6.
7.GO
8.
9.DBCC SHRINKFILE (N"templog", 0, TRUNCATEONLY)
10.
11.GO

Слід врахувати, що ім'я файлу бази даних тимчасових таблиць може бути рівним " tempdev " . Для перевірки цього імені можна використовувати скрипт

1.USE tempdb
2.
3.GO
4.
5.EXEC sp_helpfile
6.
7.GO




"Горщик, не вари"

Найпоширеніший на практиці спосіб переповнити tempdb і тим самим "упустити" сервер - це забути вказати умову при з'єднанні таблиць.

А саме, скажімо, у нас в базі є дві таблиці, розміром по 20 тисяч записів кожна. Допустимо, між їхніми записами можна встановити однозначну відповідність, і ми пишемо запит, який створює тимчасову таблицю, яка містить 20 тисяч записів з полями обох вихідних таблиць. Але якщо ми забудемо вказати умову з'єднання – кожен запис першої таблиці з'єднається з кожним другий записом! Тобто вийде результуюча таблиця з 20 000 * 20 000 = 400 млн. записів. І так далі.

3. Для зниження навантаження на дискову підсистему рекомендується по можливості розносити по різних фізичних дисках робочу базу і tempdb, логи, файл підкачування системи.

Потрібний шлях для зберігання файлів робочої бази краще задати при її створенні, відредагувавши стовпчик Path (Шлях):




Для зміни фізичного розташування файлів бази часових таблиць використовується команда ALTER DATABASE, тобто в MS SQL Management Studio потрібно виконати наступний скрипт (команда "New query")

1.USE master
2.
3.GO
4.
5.ALTER DATABASE tempdb
6.
7.MODIFY FILE (NAME = tempdev, FILENAME = "Новий_Диск:\Новий_Каталог\tempdb.mdf")
8.
9.GO
10.
11.ALTER DATABASE tempdb

12.
13.MODIFY FILE (NAME = templog, FILENAME = "Новий_Диск:\Новий_Каталог\templog.ldf")
14.
15.GO

4. Не слід ускладнювати "зростання" робочої бази даних та її лога - обмеження на розмір бути не повинно, властивість "Autogrowth" має бути встановлена ​​у відсотках, рекомендоване значення 10%. В іншому випадку додавання даних до бази, відновлення з архіву та інші операції можуть виконуватися невиправдано довго.

Для встановлення цієї властивості потрібно через контекстне меню зайти до властивостей бази, вибрати розділ Files, відкрити редагування властивостей файлу:



5. Рекомендується включити в MS SQL Server підтримку мережного протоколу TCP/IP і вимкнути решту, інакше спільна робота MS SQL Server і сервера 1С: Підприємства буде менш стабільної.




6. Там - очистити розділ Alias, т.к. її встановлення призводить до помилок взаємодії MS SQL Server та сервера 1С: Підприємства.

Перед початком експлуатації бази даних рекомендується:

1. При створенні бази даних з "1С:Підприємства" встановити "зміщення дат" 2000, в протилежному спроба запису дати раніше 01.01.1753 (що можливо через людський фактор) - буде викликати збої в роботі бази даних.

Увага! Усунення дат не можна буде змінити у існуючої бази даних!



2. Встановити Режим відновлення (Recovery model) у значення Простий (Simple), або створити План обслуговування (Maintance Plan), який щодня створюватиме резервну копію (backup) бази даних та обрізатиме журнал транзакцій (log-файл). В іншому випадку при деяких операціях журнал транзакцій (log-файл) дуже швидко зростатиме: наприклад, при реструктуризації бази даних зростання розміру log-файлу може в кілька разів перевищити розмір самої бази даних.




3. Створити План обслуговування (Maintance Plan), що виконує такі регламентні завдання щонайменше раз на тиждень:

Створення резервної копії (backup) бази даних.

Оновлення статистик бази даних та очищення процедурного кешу (слід зазначити, що властивість autoupdate statistics не передбачає очищення процедурного кешу).

Очищення процедурного КЕШу – не входить до стандартних операцій Планів обслуговування, цей крок потрібно визначати як виконання скрипту (Execute T-SQL Statement) з таким вмістом:

DBCC FREEPROCCACHE

Реіндексація таблиць бази даних.

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




Висновок

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

Автор сподівається, що досить послідовно та доступно висвітлив "обидві сторони медалі".

P.S. Найчастіше робіть бекапи!

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

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

Основні можливості кластера серверів

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

Загальна схема клієнт-серверного варіанта роботи

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

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

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

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

Робочий процес виконує аутентифікацію користувача та обслуговує з'єднання до закінчення сеансу роботи клієнта з цією інформаційною базою.

Склад найпростішого кластера серверів

Найпростіший кластер серверів може розташовуватися на одному комп'ютері та містити один робочий процес:

На малюнку представлені всі елементи, які задіяні у роботі кластера серверів, а саме:

• процеси кластера серверів:
  • ragent.exe;
  • rmngr.exe;
  • rphost.exe;
• сховища даних:
  • список кластерів;
  • реєстр кластера.

Функціонування комп'ютера у складі кластера забезпечується процесом ragent.exe, який називається агентом сервера. Відповідно комп'ютер, на якому запущено агента сервера, називається робочим сервером. Однією з функцій агента сервера є ведення списку кластерів, розміщених на цьому робочому сервері.

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

Безпосередньо кластер серверів включає такі елементи:

• один або кілька процесів rmngr.exe;
• реєстр кластера;
• один або кілька процесів rphost.exe.

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

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

Масштабованість

Масштабованість кластера серверів може здійснюватися кількома способами:

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

Використання кількох менеджерів

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

Частина сервісів може використовуватись тільки на головному менеджері кластера:

• обслуговування конфігурації кластера,
• сервіс блокувань кластера,
• обслуговування управління предметами налагодження.

Інші послуги можуть бути призначені довільним менеджерам кластера:

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

Використання кількох робочих процесів

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

Використання кількох робочих серверів

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

Відмовостійкість

Відмовостійкість роботи кластера забезпечується у трьох напрямках:

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

Резервування кластера

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

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

Резервування робочих процесів

Кожному робочому процесу можна зазначити варіант його використання: Використати, Використовувати як резервний, Не використовувати.

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

Стійкість до обриву каналу зв'язку

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

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

Сеанси

Сеанс визначає активного користувача інформаційної бази та потік управління цього користувача. Існують такі види сеансів:

• Товстий клієнт, Тонкий клієнт, Веб-клієнт- створюються при зверненні, відповідно, товстого, тонкого та веб-клієнта до інформаційної бази,
• Конфігуратор- створюється під час звернення конфігуратора до інформаційної бази,
• COM-з'єднання- Створюється при зверненні до інформаційної бази через зовнішнє з'єднання,
• WS-з'єднання- створюється при зверненні веб-сервера до інформаційної бази в результаті звернення до Web-сервісу, опублікованого на веб-сервері,
• Фонове завдання- Створюється при зверненні робочого процесу кластера до інформаційної бази. Призначений для виконання коду процедури фонового завдання,
• Консоль кластера- створюється при зверненні утиліти адміністрування клієнт-серверного варіанта до робочого процесу,
• COM-адміністратор- Створюється при зверненні до робочого процесу через зовнішнє з'єднання.

Робота під управлінням різних операційних систем

Усі процеси кластера серверів здатні функціонувати як під керуванням операційної системи Windows, і під керуванням операційної системи Linux. Завдяки тому, що взаємодія процесів між собою здійснюється за протоколом TCP/IP, у складі одного кластера можуть бути робочі сервери з різними операційними системами.

Утиліта адміністрування кластера серверів

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

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

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

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

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

Почнемо із клієнтів, поточна версія платформи (8.2) передбачає використання трьох типів клієнтів. Розберемо їх докладніше.

Товстий клієнт

Це класична клієнтська програма 1С, до виходу платформи 8.2 він був єдино доступним видом клієнта. Схема роботи товстого клієнта наступна: клієнтський додаток запитує дані у сервера 1С, то своє чергу запитує їх із БД і зраджує назад клієнту, у якому виробляється їх обробка. Як можна помітити, дана схема неоптимальна: сервер 1С по суті є лише прошарком між клієнтом і БД, всі обчислення відбуваються на клієнті. Це накладає підвищені вимоги клієнтські ПК, т.к. обчислювальні потужності сервера не використовуються. Варто чітко розуміти, що в режимі товстого клієнта ви не отримаєте збільшення швидкодії від переходу до клієнт-серверної версії, можливо навіть навпаки.

Тонкий клієнт

Його можна назвати основним видом клієнтської програми для платформи 8.2, теоретично, на практиці не все так гладко і ми ще до цього повернемося. Схема його роботи кардинально інша: клієнт запитує дані у сервера 1С, той отримує їх з БД, обробляє та віддає клієнту результат обчислень. Основна обчислювальна навантаження у своїй лягає на сервер, тому особливих вимог до клієнтським ПК і каналу від клієнта до сервера не пред'являється.

Також тонкий клієнт може працювати як за протоколом TCP/IP у локальній мережі, і через HTTP через інтернет. Для цього потрібно ще один посередник - веб-сервер, який передає запити клієнта серверу 1С, ніякої обробки даних на веб-сервері не провадиться, він використовується виключно як транспорт. Переваги тонкого клієнта зрозумілі, він дозволяє за наявності потужного сервера значно прискорити роботу з програмою, також значно знижується мережевий трафік, що дуже актуально для офісних мереж.

Веб-клієнт

Його існування логічно випливає з деяких властивостей тонкого клієнта, якщо всі запити обробляються сервером, транспортом служить HTTP, то чому б не використовувати для роботи браузер? Схема роботи веб-клієнта нічим не відрізняється від тонкого, проте на сьогоднішній день не всі функції, що підтримуються тонким клієнтом, реалізовані і коректно працюють у веб-клієнті. Частково це можна виправити в конфігурації, частково накладає обмеження механізму виведення інформації в браузер. Однак веб-клієнт у 1С є і він працює і ніхто не заважає вам (знову таки теоретично) працювати в програмі лежачи на пляжі з планшетом.

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

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

На сьогоднішній день в режимі керованого додатка працює лише частина типових конфігурацій, такі як: Управління невеликою фірмою, Управління торгівлею 11, Роздріб 2 та Зарплата та управління персоналом. Ці рішення можуть використовувати всі переваги нової платформи. Бухгалтерія підприємства 2.0 не використовує режим керованого додатка і в тонкому і веб-клієнтах працювати не буде, це стосується і багатьох сторонніх рішень, таких як "Камін" і т.п.

Висновки

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

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

Кластер серверів 1С

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

Також система не накладає жодних вимог до платформ. Ви можете спільно використовувати як Windows так і Linux сервери, як веб-сервер можна використовувати Apache і IIS, з СУБД підтримуються PostgreSQL, MS SQL Server, IBM DB2 і Oracle. Тому ніхто не заважає вам створити схему, в якій сервер 1С, що працює на платформі Linux, працюватиме спільно з сервером БД під керуванням Windows Server і IIS і навпаки. Крім того, ви можете використовувати кілька серверів СУБД (як і веб-серверів) розташовуючи різні бази на різних серверах.

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

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

Будь-який кластер складається з Центрального сервера 1С Підприємство та робочих серверів. У найпростішій конфігурації це буде той самий фізичний сервер. Однак за потреби ми можемо додати додаткові робочі сервери, навантаження на які балансуватиме центральний сервер. Це дозволяє швидко і прозоро для користувачів збільшити обчислювальну потужність системи та збільшити стійкість до відмови. Кластер також не накладає вимог до однорідності платформи, у його складі можуть працювати сервери як під керуванням Windows, і під керуванням Linux.

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

Наприклад, якщо у вас невелике навантаження і ви використовуєте товстий клієнт і конфігурацію, що не підтримує режим керованого додатка, має сенс поєднати кластер серверів 1С і сервер СУБД на одному фізичному сервері, так як виділяти окрему машину для прошарку між клієнтом і БД дуже марнотратно.

І навпаки, при використанні керованого додатка в режимі тонкого клієнта сервер СУБД і кластер серверів краще рознести на різні сервери, кожен з яких буде оптимізований під своє завдання.

Замовити демонстрацію Замовити

У цій статті буде розглянуто кілька варіантів структури 1С для високонавантажених систем (від 200 активних користувачів), побудованих на базі клієнт-серверної архітектури – їх переваги та недоліки, вартість інсталяції та порівняльні тести продуктивності кожного варіанту.

Ми не проводитимемо опис, оцінку та порівняння загальноприйнятих і всім давно відомих класичних схем побудови серверної структури 1С, таких як окремий сервер 1С та окремий сервер СУБД, або кластер Microsoft SQL з кластером 1С. Таких оглядів безліч, у тому числі і проведених самими виробниками програмних продуктів. Ми запропонуємо огляд схем побудови структури 1С, які зустрічалися за останні кілька років у наших ІТ-проектах для середнього та великого бізнесу.

Вимоги до високонавантажених систем 1С

Високонавантажені системи 1С, що працюють з великими масивами даних в режимі 24/7/365, схильні до факторів ризику, які в стандартних ситуаціях зазвичай не спостерігаються. Як наслідок, для їх усунення та попередження потрібне застосування особливих схем архітектури 1С та нових технологій.

Катастрофостійкість СУБД.У процесі проектування архітектури 1С наголошується на обчислювальні потужності і високу доступність сервісів, виражену в їх кластеризації. Сервери 1С:Підприємство за умовчанням здатні працювати в дублюючому кластері, а для кластера СУБД зазвичай застосовується промислова система зберігання даних (СХД) та технологія кластеризації (наприклад, Microsoft SQL Cluster). Однак, ситуація стає плачевною, коли проблеми трапляються із самою СГД (часто, на наш досвід останніх років – це проблеми програмного характеру). Тоді у ІТ-інженера різко виникають дві проблеми – де взяти актуальні дані та куди їх розгорнути у найкоротші терміни, оскільки система зберігання даних із потрібним обсягом швидкого масиву дисків недоступна.

Вимоги до безпеки бази даних.Працюючи з проектами середнього та великого бізнесу, ми регулярно стикаємось із вимогами щодо захисту персональних даних (зокрема, для виконання пунктів ФЗ-152). Однією з умов виконання цих вимог є забезпечення належної безпеки персональних даних, що вимагає шифрування бази даних 1С.

При розробці схеми високонавантажених систем 1С зазвичай звертають увагу насамперед на параметри дискової системи вводу/виводу, на якій розташовані бази даних. Але ще існує активна утилізація ресурсів ЦПУ і споживання ОЗУ сервером 1С. Найчастіше саме цього ресурсів і не вистачає, можливості апаратної модернізації поточного сервера 1С вичерпуються і потрібно додавання нових серверів 1С, що працюють з єдиним сервером СУБД.

Схеми організації кластерів серверів 1С

Схема з кластером 1С-серверів, приєднаним до кластера із синхронною реплікацією SQL AlwaysOn за протоколом IP.Дана схема є одним із якісних варіантів вирішення проблеми катастрофостійкості бази даних 1С (див. рисунок 1). Технологія кластеризації баз SQL AlwaysOn заснована на принципі онлайн-синхронізації таблиць SQL між основним та резервним серверами без втручання кінцевого користувача. За допомогою SQL Listener є можливість переключитися на резервний сервер SQL у разі виходу з ладу основного, що дозволяє назвати цю систему повноцінним катастрофічним кластером SQL, завдяки використанню двох незалежних серверів SQL. Технологія SQL Always On доступна лише у версії Microsoft SQL Enterprise.

Малюнок 1 - схема кластера серверів 1С + SQL AlwaysOn

Друга схема ідентична першої, додано лише шифрування баз SQL на основному та резервному сервері.Ми вже згадували про те, що робота з останніми ІТ-проектами показала, що компанії почали набагато більше уваги приділяти питанню безпеки даних, з різних причин – вимоги ФЗ-152, рейдерські захоплення серверів, витік даних у хмарі тощо. Отже, вважаємо даний варіант схеми 1С досить актуальним (див. малюнок 2).

Малюнок 2 - схема кластера серверів 1С + SQL AlwaysOn із шифруванням

Кластер серверів 1С "active-active", приєднаний до єдиного сервера СУБД за протоколом IP.На противагу потребам у відмовостійкості та безпеці – деяким структурам насамперед потрібна підвищена продуктивність, так би мовити, «вся обчислювальна міць». Тому максимальний пріоритет надається збільшенню кількості обчислювальних кластерів сервера 1С, на які сучасна платформа 1С дозволяє диференціювати різні типи обчислень та фонові завдання (див. рис. 3). Звичайно ж, комплектація основних ресурсів сервера SQL теж повинна бути на рівні, проте сам сервер баз даних представлений в однині (мабуть, розрахунок йде на своєчасне резервне копіювання баз).

Малюнок 3 – схема кластера серверів 1С з одним сервером СУБД

Сервер 1С та СУБД на одному апаратному сервері з SharedMemory.Оскільки наші практичні тести орієнтовані порівняння продуктивності різних схем, обов'язково потрібен певний еталон для порівняння кількох варіантів (див. малюнок 4). Як зразок, на нашу думку, потрібно взяти схему розташування сервера 1С і СУБД на одному апаратному сервері без віртуалізації із взаємодією по SharedMemory.

Малюнок 4 - схема сервера 1С та СУБД на одному апаратному сервері з SharedMemory

Нижче наведено загальну порівняльну таблицю, в якій показано загальні результати за ключовими критеріями оцінки організації структури системи 1С (див. Таблиця 1).

Критерії оцінки архітектур 1С	Кластер 1С + SQL AlwaysOn	Кластер 1С + SQL AlwaysOn із шифруванням	Кластер 1С з одним сервером СУБД	Класичний 1С+СУБД SharedMemory
Легкість інсталяції та обслуговування	Удовл.	Удовл.	добре	Відмінно
Відмовостійкість	Відмінно	Відмінно	Удовл.	Не застосовується
Безпека	Удовл.	Відмінно	Удовл.	Удовл.
Бюджетність	Удовл.	Удовл.	добре	Відмінно

Таблиця 1 – порівняння варіантів побудови систем 1С

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

Опис методики тестування

Етап тестування складається з двох ключових інструментів синтетичної генерації навантаження та імітації роботи користувачів у 1С. Це тест Гільова (TPC-1C) та «Тест центр» з інструментарію 1С: КВП.

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

Спеціалізований «Тест-центр» з інструментарію 1С: КВП.Тест-центр – інструмент автоматизації розрахованих на багато користувачів навантажувальних випробувань інформаційних систем на платформі 1С:Підприємство 8. З його допомогою можна моделювати роботу підприємства без участі реальних користувачів, що дозволяє оцінювати застосовність, продуктивність і масштабованість інформаційної системи в реальних умовах. Використовуючи інструментарій 1С: КВП, на основі процесів та контрольних прикладів формується матриця «Список Об'єктів макета бази ERP 2.2» для сценарію тестування продуктивності. У макеті бази 1С: ERP 2.2 генеруються обробкою дані щодо Нормативно-довідкової інформації (НСІ):

• Декілька тисяч номенклатурних позицій;
• Декілька організацій;
• Декілька тисяч контрагентів.

Тест здійснюється у межах кількох груп користувачів. Група складається з 4 користувачів, кожен з яких має свою роль і перелік послідовних операцій. Завдяки гнучкому механізму завдання параметрів для тестування можна запускати тест на різну кількість користувачів, що дозволить оцінити поведінку системи при різних навантаженнях і визначити параметри, які можуть призвести до зниження показників продуктивності. Проводиться 3 тести по 3 ітерації у яких розробник 1С запускає тест з емуляцією роботи користувачів та заміряє час виконання кожної операції. Виконуються виміри всіх трьох ітерацій кожної зі схем структури 1С. Результатом тесту є отримання середнього часу виконання операції кожного документа матриці.

Показники «Тест центру» та тесту Гільова будуть відображені у зведеній таблиці 2.

Тестовий стенд

Сервер термінального доступу- Віртуальна машина, використовувалася для управління інструментами тестування:

• vCPU - 16 ядер 2.6GHz
• RAM - 32 ГБ
• I\o: Intel Sata SSD Raid1

• RAM – 96 ГБ
• I\o: Intel Sata SSD Raid1

Сервер 1С та СУБД - фізичний сервер

• CPU - Intel Xeon Processor E5-2670 8C 2.6GHz - 2 шт
• RAM – 96 ГБ
• I\o: Intel Sata SSD Raid1
• Ролі: Сервер 1С 8.3.8.2137, Сервер MS SQL 2014 SP 2

Висновки

Можемо зробити висновок, що за середнім часом виконання операції найбільш оптимальною є схема №3 "Кластер серверів 1С "active-active", приєднаний до єдиного сервера СУБД за протоколом IP" (див. Таблиця 2). Для забезпечення відмовостійкості такої архітектури ми рекомендуємо будувати класичний відмовостійкий кластер MSSQL з розміщенням бази даних на окремій СГД.

Важливо відзначити, що найбільш оптимальне співвідношення факторів мінімізації простою, відмовостійкості та збереження даних - у схеми №1 «Кластер 1С-серверів, приєднаний до кластера з синхронною реплікацією SQL AlwaysOn за протоколом IP», при цьому падіння продуктивності по відношенню до самого продуктивного приблизно 10%.

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

На базі хмари EFSOL ми пропонуємо нашим клієнтам кластер серверів 1Св оренду. Це дозволяє суттєво заощадити кошти на побудову власної стійкої до відмови архітектури для роботи з 1С.

Схема архітектури 1С	Середній час виконання операції, сек			Середній відсоток відхилення від зразка	Тест Гільова, ум. од.
	50 користувачів	100 користувачів	150 користувачів
Схема структури №1 "Кластер 1С-серверів, приєднаний до кластера із синхронною реплікацією SQL AlwaysOn за протоколом IP"	0,42245	0,44433	0,4391	на 14%	25,13
Схема структури №2 "Кластер 1С-серверів, приєднаний до кластера із синхронною реплікацією SQL AlwaysOn за протоколом IP із шифруванням"	0,435505	0,425227	0,425909	на 12%	21,65
Схема структури №3 "Кластер серверів 1С "active-active", приєднаний до єдиного сервера СУБД за протоколом IP."	0,40901	0,41368	0,42852	на 9%	28,09
Еталон. Схема структури №4 "Розташування сервера 1С та СУБД на одному апаратному сервері без віртуалізації із взаємодією по SharedMemory"	0,36020	0,42385	0,36335	---	34,23

Таблиця 2 - Підсумкова таблиця (скорочений варіант) практичних випробувань різних варіантів побудови систем 1С