Сьогодні ми розглянемо вибір серверного «заліза» для невеликої організації на 25-30 користувачів, з розподіленою інфраструктурою (торгові точки, склад), якою потрібні термінальний сервер та програма «1С:Підприємство». Цими сервісами користуватимуться всі працівники.
Більшість малих компаній, для здешевлення вартості обладнання, воліють мінімізувати кількість техніки, що купується і просять адміністраторів «впхнути» всі запитані ними сервіси в один фізичний сервер. Бажання зрозуміле і пробачливе, але тут є нюанси.
Можна організувати термінальний сервер і використовувати там файлову версію 1С, але за такої кількості користувачів компанія-розробник рекомендує переходити на клієнт-серверний варіант. Тому нам знадобиться ще сервер під «1С:Підприємство» та сервер баз даних. Уточнимо одразу, що організувати термінальний сервер, сервер SQL та сервер 1С на одній операційній системі можливо, але, з точки зору безпеки та стабільності роботи сервісів, це вкрай не рекомендується. А якщо все ж таки дуже хочеться використовувати один фізичний сервер для всіх трьох ролей, то рекомендуємо використовувати віртуалізацію, наприклад, VMWare ESXi або Hyper-V.
Таким чином, вимальовується три варіанти:
Для вирішення цих завдань можна запропонувати таку конфігурацію серверів:
У випадку з одним фізичним серверомми зупинили вибір на Dell R710, з двома шестиядерними процесорами Xeon X5650, 64 Гб оперативної пам'яті та шістьма дисками: два SSD у RAID 1 і чотири SAS-диски у RAID 10.
У випадку з двома фізичними серверамими зупинили вибір на таких конфігураціях:
З погляду процесорного часу термінальні сесії займають невелику частку. За досвідом впровадження термінальних рішень у різних організаціях, для підтримки комфортної роботи 30 користувачів достатньо буде 4-6 фізичних ядер процесора, по одному ядру на 6-8 сесій. Для невеликої бази SQL-серверу знадобиться одне ядро. Але ми орієнтуватимемося на розширення бази в майбутньому (або збільшення кількості баз) і візьмемо два ядра на SQL.
Для сервера «1С: Підприємство» важлива не так кількість ядер, як їх тактова частота і частота шини. Тому закладемо ще два ядра на сервер 1С.
І не забудемо, що у разі використання віртуалізації одне чи два ядра нам знадобиться для забезпечення роботи хостової операційної системи.
Разом у нас виходить:
Спочатку подивимося, скільки потрібно оперативної пам'яті під послуги: 
Це традиційне пляшкове шийка багатьох систем. Правильний вибіржорстких дисків дуже важливий для забезпечення швидкодії серверів. При роботі 1С з базою SQL відбувається безліч операцій читання/запису за секунду (IOPS). Якщо користувачі працюють на термінальному сервері з тонких клієнтів (тобто, повноцінно використовують термінальний сервер як робоче середовище), це сильно навантажує дискову систему сервера. Наприклад, 30 користувачів термінального сервера на RAID 1, SATA 3 Гбіт/с, з дисками WD Velociraptor почуваються некомфортно під час роботи з поштою та активному серфінгу в інтернеті. Для термінальних серверів ми рекомендуємо використовувати SSD-накопичувачі. Для серверів баз даних - SAS-диски, зібрані в стійкі до відмови масиви. Крім накопичувачів, слід приділити увагу дисковому контролеру. Сучасні сервери мають на борту досить хороші контролери, наприклад HP SmartArray і DELL PERC. Однак некоректно використовуватиме «набортні» рішення при серйозному навантаженні, коли потрібна максимальна продуктивність. Трохи заощадивши, ви легко можете отримати потужний сервер, який не тягне навантаження. Тому контролер має бути апаратним, а не програмним, зі своєю енергонезалежною пам'яттю.
Розглянемо варіанти розв'язання цього завдання.
Другий масив краще створити із чотирьох SAS-дисків у RAID 10 (дзеркало + страйп), але можна і з двох SSD-накопичувачів у RAID 1. Вибір залежить тільки від вартості дисків та моделі сервера.
Як сказано вище, у невеликих організацій досить велике бажання розмістити всі послуги на одному сервері. До переваг використання одного сервера та віртуалізації можна вважати нижче енергоспоживання та гнучкіше розподіл ресурсів між віртуальними машинами. Та й перенесення віртуальних машин, у разі чого, набагато зручніше, ніж перенесення фізичних ОС.
Однак два сервери мають ширші можливості щодо апгрейду. Наприклад, у нашому варіанті недорогий IBM x3550 M3 з додаванням ще одного процесора та ОЗУ перетворюється на елегантні шорти термінальний сервер на 50 і навіть більше користувачів.
Ще одне "вузьке місце" у нашому випадку, яке необхідно враховувати при виборі двох фізичних серверів, це обмін даними між ними по мережі. У віртуальних серверів обмін даними йде через віртуальний комутатор. Тут же, для збільшення пропускної спроможності мережі, можна встановити в кожен сервер по мережній карті з двома гігабітними інтерфейсами, які можна агрегувати між собою і безпосередньо з'єднати обидва сервери агрегованими 2 гігабітними лінками. Або ж використовувати мережеві картки з SPF+ 10GBASE, але це дороге задоволення.
Так що, якщо вам буде потрібно розширення, або кількість сервісів збільшиться, то тут є великі перспективи, а існуючі сервери ще довгий час ефективно виконуватимуть свої завдання. Можливо, через рік нам несподівано буде потрібно збільшити кількість користувачів вдвічі, до 60 осіб? Будь ласка.
Якщо ви використовували один сервер DELL R710, то можна докупити недорогий IBM x3550 M3, підняти на ньому гіпервізор, перенести туди віртуальну машину з БД та 1С-сервером, а на DELL всі ресурси віддати віртуальній машині з терміналом. Це буде швидко, і не потрібно буде «все викинути і купити нове».
Якщо ж ви використовували два сервери IBM, то x3550 M3 з додаванням другого процесора та невеликої кількості ОЗУ перетворюється із середнячка на досить потужну машину. А в x3250 M5 можна оновити процесор із E3-1220v3 до E3-1285v3.
Як організувати комфортну роботу 7 і більше людей у 1c? Як забезпечити безперервну роботу системою 1c? Як гарантувати збереженість всіх даних 1с? Який купити сервер для 1cта як його правильно вибрати? Ці та інші питання рано чи пізно постають перед IT-фахівцями та керівниками організацій.
Вибір конфігурації сервера для роботи 1Сзалежить від обсягу бази та активності роботи з нею. Наступні рекомендації вироблені на основі вимог фірми "1С" та багаторічної практики. Покупая 1С сeрвeр необходимо убедиться что он отвечает сoврeмeнным трeбoвaниям oткaзoустoйчивoсти и прeдусмaтривaет пoвышeниe нaгрузки при нeoбхoдимoсти рaсширeния прoизвoдствeнных прoцeссoв нa прeдприятии, гaрaнтирoвaть высoкую рaбoтoспoсoбнoсть сeрвeрoв 1с при любых нaгрузкaх, их дoлгoвeчнoсть и высoкиe эксплуaтaциoнныe хaрaктeристики
| до 20 | до 30 | до 50 | до 100 | |
|---|---|---|---|---|
| Процесор | 4-ядерний процесор Intel Xeon E3-12xx | 2 процесори Intel Xeon E5-26xx | ||
| Пам'ять | 16 GB RAM | 16-32 GB RAM | від 32 GB RAM | від 64 GB RAM |
| Кількість юнітів | від 1U | 1U або 2U | 1U або 2U | від 3U |
| Дискова підсистема | 2 x SAS | від 4 x SAS | від 8 швидких дисків SAS (RAID 10), можливі конфігурації із SSD дисками | від 16 швидких дисків SAS (RAID 10), можливі конфігурації із SSD дисками |
| Апаратний RAID-контролер | рекомендується кеша із захистом | із захистом кешу | із захистом кешу | із захистом кешу |
| Можливість масштабування та платформа із встановленням у стійку |
Є | Є | Є | Є |
| Орієнтовна вартість 1 сервера для БД | від $2 000 | від $4 000 | від $5 600 | від $9 990 |
| Зв'яжіться з нашим консультантом для уточнення конфігурації та вартості замовлення | ||||
| Рекомендована кількість серверів для архітектури під 1С | 1 | 1 | 2 сервери в кластері (відмовостійкість та загальні обчислення) | |
| Зовнішня дискова полиця | Ні | Ні | Так | Так |
| Коментар | Для БД (Може виконувати функції сервера 1C), Інтернет-шлюз, Файл-сервер. Можна налаштувати однопроцесорні машини в корпусах під 8 дисків. | Для БД, Інтернет-шлюз, Файл-сервер | Рекомендується 1 або 2 сервери під БД, об'єднаних у кластер, зовнішня СГД. Рекомендується фізичний поділ серверів: сервер БД, сервер додатків, термінальний сервер | Рекомендується 1 або 2 сервери під базу даних, об'єднаних у кластер, зовнішня СГД. Рекомендується фізичний поділ серверів: сервер БД, сервер додатків, термінальний сервер |
На основі вищенаведеної таблиці можна скласти конфігурацію сервера 1с для невеликого офісу
* Додається, якщо необхідно використання віддалених робочих столів.
Організаційна діаграма такого рішення виглядає так.
Як сервера бази данихми рекомендуємо наступні машини:Dell PowerEdge T320, Dell PowerEdge R420, Dell PowerEdge T620.
Сервери Dell T320і R420відрізняються в основному лише конструктивно (підлоговий і стічковий відповідно), а Dell T620вміщує більшу кількість дисків і оперативної пам'яті, що може знадобитися при дуже високому навантаженні або "з прицілом" на майбутнє, якщо бізнес компа. Якщо недостатньо місця в стійці, можна звернути увагу на компактний 1U сервер Dell R320.
Основними вузькими місцями сервера бази даних зазвичай є дискова підсистема і пов'язаний з цим обсягом оперативної пам'яті. Оскільки розмір бази даних у таких компаніях, як правило, невеликий (звичайно не більше 5-10 ГБ), то цілком можливо повністю кешування. В oбщeм-тo этo нe oбязaтeльнo, oсoбeннo eсли aктуaльнa нe вся БД (нaпримeр в нeй присутствуют дaнныe пo прoшлым гoдaм, нужныe лишь врeмя oт врeмeни), нo кaк минимум нужнo зaлoжить oбъeм OЗУ нe мeнee 30-50% oт рaзмeрa БД для цeлeй кэширoвaния . Плюс, зрозуміло, як мінімум 1 ГБ для потреб ОС. Якщо на цьому фізичному сервері працює і сервер додатків 1С, То треба виділити пам'ять і йому - від 1 ГБ до 2-4 ГБ (краще проконсультуватися з франчайзі - це залежить від їх конфігурації).
Як сервер бази даних з ПО 1С 8.2 розрахованим на 50-100 користувачів ми рекомендуємо використовувати сервери Dell PowerEdge T620, Dell PowerEdge R720і Dell PowerEdge R720XD. Вони мають потужні дискові підсистеми на 16 і 24 диски. Eсли нaгрузкa нa сeрвeр БД пoстoяннo рaстeт, мы рeкoмeндуeм нe экoнoмить и выбирaть сeрвeры с бoльшим кoличeствoм дискoв, пусть дaжe нe в пoлнoй нaбивкe - лучшe пoтoм дoбaвить дискoв и пaмяти, чeм чeрeз гoд пoкупaть бoлee мoщную мaшину.
Як сервера додатківОптимальним вибором стане Dell PowerEdge T420з 4-8 ГБ пам'яті. У принципі, звичайно, можна подивитися і однопроцесорну машину, але краще два більш слабких процесора, ніж один потужний (не плутати з 1000000000000000000000000). Навантаження на сервер додатків дуже сильно залежить від використовуваної вами конфігурації 1С, тому рекомендуємо проконсультуватися з Вашими впроваджувачами.
З сервером терміналівпроще всього - термінальні серверимастабуються горизонтально. Тобто можливо просто поставити два або три Dell PE R420або R620- Залежно від навантаження. Причому й відмовостійкість забезпечується автоматично - при поломці одного сервера клієнтські сесії можна перепустити на іншому. Головне - заздалегідь поставити ЗЗУ із запасом
Вибираючи, який сервер потрібен для 1С, слід пам'ятати, що під час роботи користувачів з ним виконуватиметься безліч операцій читання та запису даних за секунду.
Швидше за все, відразу зрозуміло, чому таке важливе грамотне проектування сервера для 1С - якщо "залізо" спочатку підібрано неправильно і не відповідає навантаженню на систему, тобто ризик, що або взагалі працювати з перебоями, що втратяться важливі дані. З іншого боку, створити сервер під 1С, купити для нього все апаратне та програмне забезпеченняможе коштувати відчутну для компанії суму, тому бажано підбирати обладнання те щоб уникнути зайвих витрат.
Коли нашим фахівцям потрібно зробити вибір конфігурації для сервера 1С, перше, про що вони запитують - скільки користувачів буде працювати з 1С в компанії і який набір сервісів планується використовувати, якими будуть, хто і як виконуватиме адміністрування серверів 1С. Від цих відомостей ми відштовхуємося під час створення сервера 1С.
В апаратній структурі 1С сервера для нас будуть важливі характеристики процесора, оперативної пам'яті, дискової підсистеми та мережеві інтерфейси.
Необхідно, щоб вони забезпечували стабільну та досить продуктивну роботу наступних компонентів:
Оптимальна кількість ядер процесора зазвичай розраховують, виходячи з того, що на роботу ОС потрібно зарезервувати 1-2 ядра, 1-2 ядра на роботу бази SQL, ще 1 на роботу сервера додатків і орієнтовно по 1 ядру на кожні 8-10 одночасних користувацьких сесій (щоб користувачі потім не скаржилися, що сервер 1С гальмує).
Зверніть увагу, що швидкість обробки запитів залежить не так від кількості ядер, як від тактової частоти процесора, а кількість ядер більше впливає на стабільність роботи при великій кількості користувачів і одночасних завдань від них.
Скільки пам'яті потрібно серверу 1С
Крім того, якщо вам потрібен сервер під 1С на 100 і більше користувачів, ми рекомендуємо розгортати кластер з як мінімум двох фізичних серверів 1С.
Розмір необхідної оперативної пам'яті ми пропонуємо рахувати, виходячи з таких показників:
Наведемо свої орієнтовні розрахунки параметрів сервера 1С 8.3:
Оперативну пам'ять краще купувати із запасом – це один із найважливіших факторів високої продуктивності 1С-сервера і в той же час це зараз один із найдешевших компонентів. Якщо недостатньо пам'яті на сервері 1С Підприємства, це буде дуже відчутно під час роботи, тому коли стоїть питання, який сервер 1С вибрати, завжди звертайте увагу на те, щоб у нього був достатній обсяг RAM.
Вибираючи, який сервер потрібен для 1С, слід пам'ятати, що під час роботи користувачів з ним виконуватиметься безліч операцій читання та запису даних за секунду. Цей параметр – з якою швидкістю жорсткий диск дозволяє обробляти дані – також є одним із ключових для швидкодії сервера 1С.
При проектуванні сервера 1С, вимоги до обладнання дискової підсистеми ми радимо дотримуватися таких:
У цій статті ми навели деякі поради та приблизні розрахунки, як вибрати сервер для 1С, сподіваємося, вони виявляться корисними для вас.
На закінчення додамо ще одне - не варто намагатися заощадити, використовуючи комп'ютер для сервера 1С (як часто роблять в маленьких компаніях) - користувальницьке "залізо" куди менш надійно і відмовостійке, ніж аналогічне за продуктивністю серверне. Не варто ризикувати обліковою системою свого підприємства. Якщо придбання відповідного апаратного забезпечення не вкладається у ваш бюджет, можливо, слід розглянути можливість розгорнути 1С у хмарі
Якщо вам складно зорієнтуватися, який сервер вибрати для 1С підприємство 8.3, як зробити сервер 1С, тому що ви не стикалися з цим завданням раніше, ви завжди можете звернутися до компанії-системного інтегратора, щоб досвідчені технічні фахівці допомогли вам спроектувати, купити, встановити та налаштувати відповідний вам сервер для 1С.
1С:Підприємство 8 може виявитися ресурсомістким додатком навіть при невеликій кількості користувачів. Вибираючи сервер під 1С, будь-який власник хотів би уникнути «родових травм» – закладених у нього потенційно вузьких місць. З іншого боку, сьогодні мало хто купує сервери надмірної потужності, на виріст. Добре якщо профіль навантаження вдається зняти заздалегідь - тоді проектувати сервер під конкретну конфігурацію додатків компанії простіше.
Для визначеності, розглянемо платформу «1С:Підприємство 8.2» у її популярних базових конфігураціях «Бухгалтерський облік», «Торгівля та склад», «Зарплата та Управління Персоналом», «Управління Торговим Підприємством» та, частково, «Управління Виробничим Підприємством». Виходимо з того, що для підприємств із 10 і більше співробітниками, що працюють у 1С, використовується «1С:Підприємство 8.2. Сервер додатків». Врахуємо варіант роботи у режимі віддаленого робочого столу (Remote Desktop), з кількістю одночасних користувачів бази даних до 100-150. Рекомендації будуть застосовні і для "важчих" БД 1С, але "важкі випадки" завжди вимагають індивідуального підходу.
Якщо компанія зовсім маленька (2-7 користувачів у системі), база невелика (до 1GB), а «1С:Підприємство 8.2» працює у файловому режимі на комп'ютері, то ми отримуємо класичну реалізацію файл-сервера. З таким завданням навантаження на CPU впорається навіть Intel Core i3, тим більше Intel Xeon E3-12xx. Обсяг необхідної оперативної пам'яті (RAM) вважається дуже просто: 2GB під операційну систему та 2GB під системний файловий кеш.
Якщо в компанії 5-25 користувачів 1С, розмір бази даних до 4GB, то додатку "1С:Підприємство 8.2" має вистачити 4-х ядерного Intel Xeon E3-12xx або AMD Opteron 4ххх. Крім 2GB оперативної пам'яті під ОС, необхідно виділити 1-4GB під 1С:Підприємство 8.2. Сервер додатків» і ще стільки ж під MS SQL Server як кеш - всього 8-12GB RAM. Для невеликих БД бажано кешувати в оперативній пам'яті щонайменше 30% БД, а краще всі 100%.
Відомий (хоч і не особливо афішується) факт: «1С:Підприємство 8.2. Сервер додатків» дуже не любить, коли операційна система вивантажує його в swap-файл на жорсткий диск, і схильно при цьому іноді втрачати відгук. Тому на сервері, де запущено «Cервер додатків», завжди має бути запас вільного простору в оперативній пам'яті – тим більше вона сьогодні недорога.
У компаніях більше користувачі 1С зазвичай працюють через віддалений доступ до програми (Remote Desktop) - тобто в термінальному режимі. Як правило, при 10-100 користувачах 1С з базою даних від 1GB і вище, «1С:Підприємство 8.2. Сервер додатків» і додаток «1С:Підприємство 8.2» запускається на одному і тому ж сервері.
Для визначення необхідних процесорних ресурсів виходять з того, що одне фізичне ядро може ефективно обробляти не більше 8 потоків користувача - це пов'язано з внутрішньою архітектурою процесорів. Як показує практика, під завдання 1С+Remote Desktop не варто брати серверні процесори молодших лінійок з низькими частотами розрахункових ядер та урізаною архітектурою. Якщо користувачів небагато (до 15-20), вистачить одного процесора із високочастотних Intel Xeon E3-12xx. При цьому мінімум одне його фізичне ядро (2 потоки) піде під потреби SQL Server, ще одне (2 потоки) - під «1С:Підприємство 8.2. Сервер додатків», а решта 2 фізичних ядра (4 потоки) - під ОС і термінальних користувачів. При кількості користувачів 1С більше 20 або при обсягах БД більше 4GB настав час переходити до 2-х процесорних систем на Intel Xeon E5-26xx або AMD Opteron 62xx.
Розрахунок потрібного обсягу оперативної пам'яті відносно простий: 2GB треба віддати ОС, 2GB і більше – MS SQL Server як кеш (не менше 30% БД), 1-4GB – під «1С:Підприємство 8.2. Сервер додатків», решта пам'яті сервера має вистачати під термінальні сесії. Один термінальний користувач, залежно від конфігурації, споживає у додатках «Бухгалтерський облік», «Торгівля та склад» - 100-120MB, «Зарплата та Управління Персоналом», «Управління Торговим Підприємством» - 120-160MB, «Управління Виробничим Підприємством 180-240MB. Якщо користувач запускає додатково на сервері MS Word, MS Excel, MS Outlook, то кожен додаток треба виділити ще близько 100MB. Як правило, мінімум для сервера терміналів – 12GB RAM.
Наприклад, для сервера 1С з усім пакетом ПЗ, 50 термінальними користувачами в конфігурації «Управління Торговим Підприємством», та базою даних у 8GB оптимальною буде обчислювальна потужність двох процесорів Intel Xeon E5-2650 (8 ядер, 16 потоків, 2.0 GHz). Оперативній пам'яті знадобиться мінімум 2 (ОС) + 4 (SQL) + 4 (1C-сервер) + 8 (160 "УТП" * 50 користувачів) = 18GB, а краще 24-32GB (6-8 каналів DIMM по 4GB).
Більшість скарг на повільну роботу серверів 1С:Підприємство 8 пов'язане з нерозумінням, які на них виконуються типи операцій введення-виведення, над якими даними та з якою інтенсивністю. Найчастіше саме дискова підсистема є ключем до забезпечення достатньої продуктивності сервера в цілому - адже для навантажених БД найбільшою проблемою є блокування таблиць при одночасної роботі з ними безлічі користувачів або при масових завантаженнях/вивантаженнях/проводках. Моніторинг та оптимізація дискової підсистеми сервера .
1С має 5 потоків даних для дискової підсистеми, з якими вона працює:
Структура даних у 1С - об'єктно-орієнтована, з безліччю об'єктів та зв'язків між ними. p align="justify"> Для роботи з таблицями даних надзвичайно важлива кількість операцій читання та запису, які здатна проробити дискова підсистема за проміжок часу (Input Output Operation per Second, IOPS). При цьому її здатність видати високу потокову швидкість передачі даних (MBp/s) куди менш важлива. Дуже скромна база об'ємом 200-300MB із 3-5 користувачами може генерувати в піках до 400-600 IOPS. База на 10-15 користувачів та обсягом в 400-800MB здатна видати 1500-2500 IOPS, 40-50 користувачів БД 2-4GB породжують 5000-7500 IOPS, а бази під 80-100 користувачів легко досягають 12000-180.
Зрозуміло, середнє навантаження на дискову підсистему може становити і 10-15% від пікової. Тільки насправді важлива саме продуктивність у період пікових навантажень: автоматичних завантажень даних із інших систем, обміну даних розподіленої системи чи перепроведення періоду.
Сучасні диски в операціях читання та запису з випадковим доступом (Random Read/Write) поодинці справляються з такими навантаженнями:
|
Intel 910 400 GB |
|||||
|
2400 – 8600 IOPS |
Добре видно, що:
Поодинокі диски на серверах БД не використовуються, тільки RAID-масиви. Для подальшого розрахунку реальної продуктивності дискової підсистеми потрібно врахувати витрати (штраф) на запис в IOPS, які несе дискова група в RAID:
Якщо зібрати 6 дисків у RAID 10, то на кожен запис в 1 IOPS даних буде витрачено 2 IOPS фізичних дисків, а якщо в RAID 6 - 6 IOPS дисків. Таким чином, при розрахунку можливостей навантаження дискової групи на запис потрібно спочатку скласти IOPS всіх дисків RAID-групи, а потім розділити їх на «штраф».
Приклад 1: 2 HDD SATA 7200 RAID 1 забезпечать на запис: (100 IOPS *2) / 2 = 100 IOPS.
Приклад 2: 4 SATA 7200 RAID 5 забезпечать на запис: (100 IOPS *4) / 4 = 100 IOPS.
Приклад 3: 4 SATA 7200 RAID 10 забезпечать на запис: (100 IOPS *4) / 2 = 200 IOPS.
Приклади 2 і 3 наочно демонструють, чому для зберігання баз даних, у яких типовий розподіл читання/запис становить 68/32, кращий RAID 10.
З даних трьох таблиць зрозуміло, чому продуктивності типового «джентльменського набору» 2 HDD SATA 7200 в RAID 1 серверу недостатньо: при пікових навантаженнях зростає черга звернень до диска, користувачі очікують відповіді системи, іноді по багато годин.
Як збільшити продуктивність дискової підсистеми для запису? Нарощують кількість дисків у RAID-групі, переходять до дисків із більшою швидкістю обертання, вибирають рівень RAID з меншим штрафом на запис. Добре допомагає кешування RAID-контролером із увімкненим режимом відкладеного запису Write back. Дані пишуться не безпосередньо на диски (як у режимі Write Through), а в кеш контролера, і тільки потім, у пакетному режимі та впорядкованому вигляді – на диски. Залежно від специфіки завдання продуктивність запису вдається підняти на 30-100%.
Під слабо навантажені або відносно невеликі БД (до 20GB) підійде недорогий спосіб видобутку IOPS - гібридний RAID із SSD/HDD. Більшого і не потрібно філій БД на 3-15 користувачів у розподіленій структурі на кшталт мережі кафе або СТО.
Для об'ємних (200GB і більше) БД з довгим історичним шлейфом даних або обслуговування декількох об'ємних БД ефективним може виявитися SSD-кешування (технології LSI CacheCade 2.0 або Adaptec MaxCache 3.0). За досвідом експлуатації таких систем, саме в задачах 1С за допомогою їх можна відносно недорого і без істотних змін в інфраструктурі зберігання прискорити дискові операції на 20-50%.
Чемпіоном зі швидкодії в IOPS передбачувано є RAID-масиви на серверних SSD – як традиційні, з використанням SAS RAID-контролера, так і PCIe SSD. Заважають їхній популярності два обмежувачі: технологічний (продуктивність RAID-контролерів або необхідність радикально ламати структуру зберігання) та ціна реалізації.
Окремо слід сказати про зберігання індексних файлів та TempDB. Індексні файли оновлюються дуже рідко (зазвичай 1 раз на добу), проте читаються дуже часто (IOPS). Таким даними просто необхідно зберігатися на SSD, з їх показниками читання! TempDB, що використовуються для зберігання тимчасових даних, як правило, невеликі за об'ємом (1-4-12GB), проте дуже вимогливі до швидкості запису. Індексні та часові файли поєднує те, що їхня втрата не призводить до втрати реальних даних. Отже, вони можуть розміщуватися на окремому (ще краще - на двох окремих томах) SSD. Хоча б і на бортовому контролері SATA материнської плати. З точки зору надійності та швидкодії, під TempDB бажано віддати дзеркало (RAID1) із SSD, можна на бортовому контролері, але з обов'язковим вимкненням усіх кешів на запис. З цією роллю впораються і десктопні SSD - на зразок Intel 520-серії, де апаратна компресія даних при записі в TempDB буде доречною. Винесення цих завдань із загальної системи зберігання на виділену швидкісну підсистему позитивно позначається на продуктивності системи загалом, особливо у моменти пікових навантажень.
У випадках, коли є можливість забезпечити максимально швидку реакцію адміністраторів при збоях і коли є складні розрахункові завдання (складська або транспортна логістика, Виробництво в УПП, об'ємні обміни в УРБД), TempDB виносять на RAMDrive. Таке рішення дозволяє виграти іноді до 4-12% від загальної продуктивності системи. Деяка незручність виникає тільки у разі рестарту сервера: якщо автоматично RAMDrive не запуститься, буде потрібно втручання адміністратора для ручного старту – інакше стане вся система.
Ще один важливий компонент – log-файли. Вони мають неприємну для будь-якої дискової підсистеми особливість - генерувати постійний потік дрібних звернень на запис. Це непомітно при середніх навантаженнях, але погіршує швидкодію сервера 1С при пікових навантаженнях. p align="justify"> Розумно виносити log-файл (особливо, log-файл SQL) на окремий фізичний том, до якого немає високих вимог по IOPS, і на який буде йти практично лінійний запис. Для спокою можна створити дзеркало з недорогих та об'ємних SATA/NL SAS (для Full log), або недорогих десктопних SSD все тієї ж Intel 520 серії (Simple log, або Full log, з щоденним його Backup і очищенням).
Загалом можна сказати, що прихід SSD у сервери відкрив нові можливості збільшення продуктивності масових серверів - за рахунок багаторівневого зберігання даних та розумного конфігурування дискового вводу/виводу.
Дискова підсистема «ідеального сервера під 1С» виглядає так:
1. Таблиці бази даних розміщені на RAID 10 (або RAID 1 для малих баз даних) з надійних серверних SSD з обов'язковим апаратним RAID-контролером. При високих вимогах щодо IOPS можна розглянути варіант PCIe SSD. Для БД великого обсягу ефективним є SSD-кешування масивів HDD. Якщо конфігурація 1С і структура даних, що використовується, не надто вимогливі до IOPS, а кількість користувачів невелика - вистачить традиційного масиву з HDD SAS 15K rpm.
2. Індексні файли винесені на швидкий та недорогий одиночний SSD, TempDB – на 1-2 (RAID 1) SSD або RAMDrive.
3. Під log-файли SQL (а бажано і 1С) відведений виділений том (одинаковий фізичний диск або RAID-1) на SATA/NL SAS HDD або недорогих SSD, або логічний диск на RAID-масиві, на якому розташована операційна система сервера користувацькі файли/папки.
4. Операційна система та дані користувача зберігаються на RAID 1 з HDD або SSD.
Якщо IT-інфраструктура віртуалізована, вкрай бажано, щоб SQL Server було встановлено не як віртуальна машина, а безпосередньо на фізичний сервер, на голе залізо. Ціна питання – від 15 до 35% продуктивності дискової підсистеми (залежно від обладнання, драйверів, засобів віртуалізації та способів підключення тому). У віртуалізованому середовищі SQL-сервера підключення томів з таблицями БД, індексними файлами та TempDB до VM обов'язково в монопольному режимі Direct Access.
При побудові систем 1С:Підприємство 8 для малих та середніх підприємств (до 100-150 активних користувачів одночасно) слід мінімізувати втрати на мережевих операціях через інтерфейс Ethernet. В ідеалі - обслуговувати і SQL Server, і «1С:Підприємство 8 Сервер додатків х64», і сесії користувача 1С в Remote Desktop одним фізичним сервером. Спірна з точки зору забезпечення стійкості до відмов, така рекомендація дозволяє вичавити максимум з обладнання та ПЗ, а за рахунок застосування віртуалізації дає певний рівень безпеки і «повторюваність середовища» на іншому устаткуванні.
Навіщо виключати Ethernet з ланцюжка SQL-сервер -> Сервер додатків 1С:Підприємство 8 -> сесія користувача 1С:Підприємство 8? Мережевий інтерфейс Ethernet, з його упаковкою даних відносно невеликі блоки для передачі, завжди буде створювати додаткові затримки: і при упаковці/розпакуванні трафіку, і при самій передачі (висока латентність). У 1С:Підприємство 8 досить великі масиви даних передаються для обробки та відображення по всьому ланцюжку, в деяких ситуаціях - в обидві сторони. При прямій передачі даних від одного процесу іншому в рамках оперативної пам'яті сервера (на одному сервері без віртуалізації), або ж через віртуальний мережевий інтерфейс (в рамках все того ж одного фізичного сервера, при хороших серверних мережевих адаптерах з перенесенням блоків RAM між VM) затримки набагато нижчі. Сучасні двопроцесорні сервери з великою оперативною пам'яттю та дисковою підсистемою на SSD дозволяють комфортно обслужити БД 1С на 100-150 активних користувачів.
Якщо для навантажених БД використання кількох фізичних хостів є неминучим, бажано зв'язати всі сервери по 10Gb Ethernet. Або, як мінімум, 2-4 агрегованими з'єднаннями 1Gb Ethernet з апаратним прискоренням TCP/IP (TCP/IP Offloader) та апаратною підтримкою віртуалізації.
Найбільше від втрат продуктивності на портах Ethernet страждають бюджетні рішення. Не секрет, що мережеві адаптери 1Gb, що розпаюються на більшості серверних материнських плат, не призначені для обслуговування інтенсивного мережевого трафіку. Навіть якщо на платі є 2 або 3 порти GbE, вони зазвичай реалізовані на десктопних чіпах. Достатні управління, вони породжують додаткові накладні витрати з обслуговування мережевих обмінів, особливо у віртуалізованому середовищі. Весь процес передачі даних через такий чіп забезпечується за рахунок ресурсів процесора, оперативної пам'яті та навантаження на внутрішні шини. Ніякого прискорення передачі IP-трафіку такі чіпи не дають, кожен приймається та переданий Ethernet-пакет вимагає окремого переривання на процесор. У віртуалізованому середовищі втрати продуктивності інтерфейсу можуть досягати 25-30%. Найнеприємніше, що навантаження саме мережного інтерфейсу засобами моніторингу можна і не помітити. За нього віддується центральний процесор, а якщо не працює, то простоює в очікуванні відповіді від мережевої карти. Порти на десктопних чіпах бажано виключити з потоку даних у віртуалізованих середовищах, залишивши під завдання управління сервером. Під інтенсивний мережевий трафік варто додати дискретну мережну картку на серверному чіпсеті.
Обговорення продуктивності серверів майже завжди супроводжується суперечками про їхню надійність. Забезпечення стійкості до відмов завжди потребує додаткових витрат, особливо за підтримки безперервних виробничих процесів. Не принижуючи ролі та місця 1С, можна сказати, що здебільшого її користувачів дилему «продуктивність/надійність» вирішує в різних площинах: за першу борються оптимізацією апаратних рішень, за другу – організацією процесів та процедурами. Коли програми помірковано критичні, основну увагу у підтримці працездатності приділяють не засобам індивідуального захисту серверів, а мінімізації простою інфраструктури загалом.
Зрозуміло, для підприємств із відносно великою кількістю одночасно підключених користувачів (25-150) та розміщенням усіх додатків на одному сервері обов'язкове застосування джерел безперебійного енергопостачання, надлишкових блоків живлення самих серверів, кошиків гарячої заміни дисків та RAID-масивів із гарячим резервуванням. Але жодні апаратні засоби не замінять планового резервування самих даних. Маючи щоденний (точніше, щоночовий) backup та оперативний файл із Full SQL log, можна повністю відновити БД 1С за відносно короткий проміжок.
Допустимий час простою центральної системи 1С для малих та середніх підприємств - 1-2 аварії на місяць, тривалістю 1-4 години. Насправді це величезний запас часу - якщо до відновлення бути готовими заздалегідь. Необхідною умовою швидкого рестарту є наявність образів всіх віртуальних та фізичних серверів у вигляді VM на окремому сховищі/томі – для відновлення самої інфраструктурної частини на резервному сервері. Обов'язковий щоденний backup (а також щотижневий та закриття періоду) на інший фізичний пристрій і Full SQL log для випадків, коли втрата даних «з початку робочого дня» критична і важко відновна вручну. За наявності підмінного обладнання можна вкластися в 1-2 години для відновлення працездатності загалом, хай і з меншою продуктивністю. Ну а там, де потрібна безперервність роботи 24х7, першочерговими завданнями будуть вибір відповідної архітектури, обладнання з мінімальною кількістю точок відмови та повноцінних технологій кластеризації. Але це вже зовсім інша історія.
Оригінал статті: http://ko.com.ua/proektirovanie_servera_pod_1s_66779
З дозволу редактора журналу "Комп'ютерний огляд"
Для початку пропоную виділити кілька сценаріїв роботи:
1.) Робота з файловою базою через загальний ресурс (веб-сервер)
2.) Робота з файловою базою у терміналі
3.) Робота з серверною (MSSQL) базою
Робота із файловою базою через загальний ресурс (веб-сервер)
Тут все досить просто. Якщо це звичайні форми та 1-3 користувача. То на "сервер" (машина, на якій лежатиме база вибираємо:
Інший момент, якщо база на керованих формах. Ось тут вже якщо все здати як описано вище, вийдуть гальма. Проте вихід є:
Якщо з базою буде працювати локально один користувач то цього достатньо для його комфортної роботи, але швидкість мережної роботи через загальний ресурс буде так само повільною. Але і тут є вихід – робота через web-сервер. На просторах інтернету ви зможете знайти велику кількість статей, де описується як організувати роботу з 1С подібним чином, не зупинятимуся в цій статті на цьому. Єдине, поділюся з Вами своїми спостереженнями: краще налаштувати роботу у користувачів не через web-браузер, а через тонкий клієнт (коли додаємо до списку ІБ нову базу, на сторінці розміщення ІБ є пункт "на web сервері"). Це, за моїми спостереженнями, швидше, ніж через браузер. Крім того, при роботі через браузер зустрічаються помилки в інтерфейсі (що з'їхала ТЧ і т.п.), яких немає при роботі через тонкий клієнт.
Власне, скориставшись даним рецептом (ssd, процесор з великою частотою, web-сервер, тонкий клієнт). Можна розвіяти міф "якщо кількість користувачів більше 1 (за деякою версією більше 0:)) - потрібна серверна база*.
*Хоча, звичайно, з застереженням що це не УПП або база розміром > ~4гб, а кількість користувачів не перевищує 4 (це максимальні розмір бази та кількість користувачів, які бачив я, можливо хтось зустрічав випадки, коли через web-сервер з файловою базою працювало більше людей?
Робота з файловою базою у терміналі
Перейдемо до наступного варіанта. Ми маємо термінальний сервер і маємо файлову базу. Тут все аналогічно сценарію 1 за винятком процесора:
Робота з серверною (MSSQL) базою
Цей сценарій найскладніший і, мабуть, потребує окремої статті. Пропоную в рамках цієї статті розглянути лише базові принципи, що впливають на продуктивність
Наче все. Якщо питання/скарги/пропозиції - wellcome в коментарі;)
