Digi Data - Оптимізація апаратного забезпечення 1С:

1. Як збільшити продуктивність дискової системи?
2. Таблиці баз даних
3. Індексні файли і файли TempBD
4. Log-файли
5. Оптимальне обладнання для 1С: якою має бути дискова підсистема?
6. Компроміс між надійністю і продуктивністю

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

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

Щоб вести предметну розмову, візьмемо для прикладу платформу 1С: Підприємство 8.2. Як показує практика, що склалася, коли 1С 8.2 повільно працює, дуже поширені. Ми будемо розглядати базові конфігурації: «Управління торгівлею», «Зарплата і Управління Персоналом», «Бухгалтерський облік», «Управління Торговим Підприємством», а також «Управління Виробничим Заходом». У наших розрахунках ми будемо відштовхуватися від того, що при наявності більше 10 співробітників, що працюють з платформою, підприємство також використовує 1С: Підприємство 8.2. Сервер Додатків. Крім того, припустимо можливість роботи в режимі Remote Desktop (віддалений робочий стіл), число користувачів БД, підключених одноразово - від 100 до 150.

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

Як збільшити продуктивність дискової системи?

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

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

Бази даних 1С мають п'ять потоків даних для дискових підсистем.

1. Таблиці баз даних.
2. Тимчасові файли tempDB.
3. Індексні файли.
4. log-файли SQL і log-файли для користувача додатків платформи.

Організація роботи з потоком даних кожного типу має свою специфіку.

Таблиці баз даних

У процесі роботи з таблицями баз даних особливого значення набуває те, скільки операцій запису і читання дискова підсистема здатна виконати за проміжок часу. Число цих операцій позначається як IOPS. Одночасно з цим параметри потокової швидкості передачі даних в MBp / s важливі набагато менше. Навіть якщо 1С повільно працює по мережі, її продуктивність буде достатньою за умови нормального показника IOPS.

Які потреби IOPS для баз з об'ємом даних і числом користувачів?

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

Які показники для сучасних дисків в операціях Random Read / Write?

Дана таблиця дозволяє зробити відразу кілька висновків.

1. Для кожної з моделей показники IOPS для операцій запису набагато нижче аналогічних показників для операцій читання.
2. SSD набагато випереджає традиційні HDD по числу операцій запису і читання в одиницю часу. Ця різниця зберігається навіть при порівнянні з моделями десктопних SSD, що вийшли досить давно (IOPS в 3-40 вище). Серверні SSD демонструють ще більш високі показники: IOPS в 12-40 разів вище в порівнянні з HDD.
3. SSD класу Intel 910 або LSI WarpDrive - краща відповідь на питання про те, як збільшити продуктивність 1С: у цих дисків продуктивність в IOPS максимальна.

Якщо одним із завдань є оптимізація роботи БД, варто врахувати, що при побудові дискової підсистеми в серверах використовуються не поодинокі диски, а RAID масиви. Це накладає певну специфіку на розрахунок фактичної продуктивності дискової підсистеми: потрібно враховувати, які саме витрати на запис в IOPS несе дискова група в масиві.

Значення в колонці - це IOPS фізичного диска, який буде потрібно для запису або читання даних в масиві. Візьмемо для прикладу RAID 5. Щоб записати 1 IOPS, буде потрібно 4 IOPS фізичних дисків.

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

сума IOPS фізичних дисків RAID-групи / витрати на запис IOPS, які несе дискова група в масиві.

Для пояснення досить двох прикладів.

1. 2 диска HDD SATA 7200 (IOPS = 100) в масиві RAID 1 при операціях запису дадуть наступну продуктивність: (100 + 100) / 2 = 100 IOPS.
2. 4 диска HDD SATA 7200 (IOPS = 100) в масиві RAID 5 при операціях запису забезпечать наступну продуктивність: (100 + 100 + 100 + 100) / 4 = 100 IOPS.

Нескладні розрахунки показують, що RAID 10 є найкращим для зберігання баз даних, типове розподіл операцій читання і запису у яких становить 68/32. Якщо ж спиратися на всі три таблиці, то зрозуміло, що в багатьох випадках повільна робота 1С пов'язана з тим, що в якості дискової підсистеми використовується «джентльменський набір», що складається з 2 дисків HDD SATA 7200, об'єднаних в масив RAID 1. При пікових навантаженнях потужність такого набору виявляється явно недостатньою, і 1С «гальмує» просто тому, що виростає величезна черга звернень до диску, в результаті чого користувачам доводиться подовгу чекати відповіді системи.

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

1. Збільшення числа дисків в RAID групі. Якщо «висне» 1С, таке рішення може збільшити швидкість виконання операцій запису.
2. Заміна наявних дисків на диски з більшою швидкістю обертання (стосовно HDD).
3. Використання RAID груп, у яких різниця між IOPS масиву і IOPS фізичних дисків мінімальна.
4. Використання кешу RAID-контролера для проміжного розміщення даних. У режимі Write Trough дані записуються на диски безпосередньо. Якщо включити режим відкладеного запису Write Back, то спочатку дані будуть писатися в кеш контролера, а потім, в упорядкованому вигляді, на диски. Якщо 1С 8 повільно працює, такий прийом може збільшити продуктивність записи на 30-100% залежно від специфіки завдання.
5. Якщо гальмує БД порівняно невеликого обсягу (до 20GB) або слабо навантажена БД, можна використовувати гібридний RAID, в складі якого знаходяться HDD і SSD диски. У розподілених структурах для філіальних БД на 3-15 користувачів більшого не потрібно. Такий вибір обладнання для 1С можливий, наприклад, при побудові дискової підсистеми для сервера на СТО, кафе, в невеликому магазині.
6. Якщо гальмує 1С з об'ємною базою даних (розмір становить 200GB і вище, є великий обсяг збережених, «історичних» даних), можна використовувати SSD-кешування. Воно виконується з використанням технології Adaptec MaxCache 3.0 і LSI CasheCade 2.0. Саме при вирішенні завдань 1С такий прийом дозволяє прискорити запис даних на диски на 20-50%.

RAID-масиви, побудовані на SSD серверного типу є лідерами за швидкодією з точки зору IOPS. Це можуть бути традиційні RAID групи, що використовують SAS RAID контролер, так і PCIe SSD. Існує всього дві причини, що заважають їх повсюдного поширення: досить висока вартість і технологічні обмеження. Зокрема, продуктивність RAID-контролерів поки відстає від продуктивності самих серверних SSD. Крім того, щоб використовувати описані RAID масиви, необхідно радикально змінювати структуру зберігання даних.

Індексні файли і файли TempBD

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

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

Якщо потрібно забезпечити максимальну стабільність 1С, то краще розмістити TempBD на дзеркалі SSD (в RAID 1). Якщо файл розміщується на контролері, то обов'язково потрібно вимкнути всі кеші на запис. Як дзеркала не обов'язково використовувати серверні SSD - цілком підійдуть десктопні диски (Intel 520 або аналогічні).

Що дасть винос TempBD із загальної системи зберігання даних 1С на виділену підсистему з більш високим IOPS? В першу чергу - більш високу продуктивність, а також поліпшення роботи системи під час пікових навантажень.

У разі, якщо необхідно вирішувати складні розрахункові завдання і є можливість забезпечити швидку реакцію адміністраторів на ситуації, коли відбувається зависання 1С, можна винести TempBD на RAMDrive. Загальна продуктивність системи в цьому випадку може вирости на 4-12%. Єдиний нюанс, який необхідно враховувати - при запуску сервера необхідний контроль автоматичного запуску RamDrive. Якщо він не запуститься, потрібно ручной старт, що виконується адміністратором. В іншому випадку відбудеться зупинка всієї системи.

Log-файли

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

Log-файл SQL потрібно винести на окремий том. Вимоги по IOPS до нього можуть бути не дуже високими, запис буде йти в лінійному режимі. Крім того, можна зробити дзеркало на диску SATA або NL SAS, виділивши для цього недорогий і об'ємний носій. Також для цього можуть використовуватися десктопні SSD серії Intel 520.

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

Оптимальне обладнання для 1С: якою має бути дискова підсистема?

Можна дати чотири основних рекомендації по розміщенню даних різних типів.

1. Таблиці БД повинні знаходитися на дисках масивів RAID 10 (для баз даних невеликого об'єму - RAID 1). Як фізичних дисків потрібно використовувати серверні SSD, обов'язково доповнені апаратним RAID контролером. Якщо вимоги до продуктивності по IOPS є досить високими, можливе використання PCIe SSD. Для об'ємних БД додатково можна використовувати SSD кешування перед безпосереднім записом на HDD. Традиційний масив, побудований на дисках HDD SAS 15K rpm, може використовуватися за умови, що вимоги до продуктивності по IOPS є не надто високими.
2. Для індексних файлів краще використовувати окремого тому. Це може бути недорогий, але швидкий SSD. Файли TempDB краще розміщувати на RAMDrive або 1 або 2 дисках SSD в масиві RAID 1.
3. Збереження даних користувача та операційної системи переважно на DDS або HDD дисків в масиві RAID 1.
4. Log-файли (як 1С, так і SQL) варто розташовувати на виділеному томі, який може являти собою як масив RAID-1, так і одиночний фізичний диск. Для цього можуть використовуватися недорогі SSD, SATA / NL SAS HDD або логічний диск, на якому розташовується серверна ОС і призначені для користувача файли, і який входить до складу RAID-групи.

Зберігання даних 1С необхідно оптимізувати і у випадку з виртуализированной IT-структурою. У цьому випадку SQL сервер необхідно встановлювати на фізичний сервер, він не повинен бути встановлений як віртуальна машина. Це дозволяє вигравати 15-35% продуктивності дискової підсистеми. Точна цифра буде залежати від цілого ряду параметрів, а саме коштів віртуалізації, характеристик обладнання, способів підключення томи, використовуваних драйверів і т.д.

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

Компроміс між надійністю і продуктивністю

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

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

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

Як правило, для захисту серверів використовуються наступні апаратні заходи.

1. Установка ДБЖ - фізичний захист сервера від перебоїв харчування.
2. Застосування надлишкових блоків живлення серверів.
3. Використання корзин гарячої заміни дисків.
4. Застосування в складі дискової підсистеми RAID-масивів, що мають гаряче резервування.

Всі ці заходи є дієвими і необхідні, однак вони не вирішують завдання резервування даних. Бекап 1С повинен виконуватися планово так, щоб у критичній ситуації велика частина БД (крім самих останніх змін) могла бути оперативно відновлена. Рекомендується виконувати backup 1C щодоби (в нічний час, наприклад), резервуючи БД і оперативний файл, який містить Full SQL log.

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

Для того, щоб виконати рестарт швидко, необхідні образи всіх фізичних і віртуальних серверів в VM, розташовані на окремому томі. Це дозволить швидко відновити інфраструктуру на резервному серверному обладнанні. Бекап Full SQL log повинен виконуватися щодня, щотижня і після закриття періоду. Резервування файлу повинна виконуватися на іншу фізичну пристрій. Якщо в розпорядженні підприємства є підмінне обладнання, рестарт може бути виконаний всього за 1-2 години. Тут варто зазначити, що в тих випадках, коли необхідно забезпечити безперервну роботу в режимі 24 * 7, завдання набагато ускладнюється: потрібно розробка відповідної архітектури, підбір обладнання, яке має мінімум потенційних точок відмови, використання повноцінних технологій кластеризації.