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

Основним критерієм при виборі серверів для організації є набір сервісів, які будуть використовуватися, і кількість користувачів.
Сьогодні ми розглянемо вибір серверного «заліза» для невеликої організації на 25-30 користувачів, з розподіленою інфраструктурою (торгові точки, склад), якій потрібні термінальний сервер і програма «1С: Підприємство». Цими сервісами будуть користуватися всі співробітники.
Більшість малих підприємств, для здешевлення вартості обладнання, воліють мінімізувати кількість придбаної техніки і просять адміністраторів «впихнути» всі запитані ними сервіси в один фізичний сервер. Бажання зрозуміле і можна пробачити, але тут «є нюанси».
Можна організувати термінальний сервер і використовувати там файлову версію 1С, але при такій кількості користувачів компанія-розробник рекомендує переходити на клієнт-серверний варіант. Тому нам потрібно ще сервер під «1С: Підприємство» і сервер баз даних. Уточнимо відразу, що організувати термінальний сервер, сервер SQL і сервер 1С на одній операційній системі можливо, але, з точки зору безпеки та стабільності роботи сервісів, це вкрай не рекомендується. А якщо все-таки дуже хочеться використовувати один фізичний сервер для всіх трьох ролей, то рекомендуємо використовувати віртуалізацію, наприклад, VMWare ESXi або Hyper-V.
Таким чином, вимальовується три варіанти:

1. Один сервер з файлової 1С. Поганий варіант, далі ми його розглядати не будемо.
2. Один сервер з двома віртуальними машинами.
3. Два фізичних сервера, один термінальний, другий з БД і 1С.

Для вирішення цих завдань можна запропонувати наступну конфігурацію серверів:
У випадку з одним фізичним сервером ми зупинили вибір на Dell R710, з двома шестиядерними процесорами Xeon X5650, 64 Гб оперативної пам'яті і шістьма дисками: два SSD в RAID 1 і чотири SAS-диска в RAID 10.
У випадку з двома фізичними серверами ми зупинили вибір на таких конфігураціях:

• Термінальний сервер: IBM x3550 M3 з одним процесором Xeon E5620, 32 Гб оперативної пам'яті і двома SSD в RAID 1, з додатковою мережевою картою на два гігабітних інтерфейсу. У цього сервера також є багаті можливості для апгрейда, так як він двохпроцесорний, має 18 слотів під модулі пам'яті і підтримує до 288 Гб ОЗУ.
• Сервер баз даних: IBM x3250 M5 з одним процесором Xeon E3-1220v3, 16 Гб ОЗУ, додатковим RAID-контролером SAS / SATA, чотирма SAS-дисками в RAID 10, з додатковою мережевою картою на 2 гігабітних інтерфейсу.

Чому ми вибрали саме такі конфігурації? Для відповіді на це питання давайте підрахуємо, що нам потрібно для забезпечення комфортної роботи користувачів в нашій невеликій організації на 25-30 співробітників. Щоб не було непорозумінь: це лише один з прикладів недорогого впровадження 1С, і в багатьох випадках доцільніше вибрати інші конфігурації.

процесор

З точки зору процесорного часу термінальні сесії займають не дуже велику частку. З досвіду впровадження термінальних рішень в різних організаціях, для підтримки комфортної роботи 30-ти користувачів досить буде 4-6 фізичних ядер процесора, по одному ядру на 6-8 сесій.
Для невеликої бази SQL-сервера знадобиться одне ядро. Але ми будемо орієнтуватися на розширення бази в майбутньому (або збільшення кількості баз) і візьмемо два ядра на SQL.
Для сервера «1С: Підприємство» важливо не стільки кількість ядер, скільки їх тактова частота і частота шини. Тому закладемо ще два ядра на сервер 1С.
І не забудемо, що в разі використання віртуалізації одне або два ядра нам стане в нагоді для забезпечення роботи хостовой операційної системи.
Разом у нас виходить:

• для сервера з двома віртуальними машинами потрібно 12 фізичних ядер. Можна і менше, але завжди повинен залишатися запас по потужності. Сервер з двома шестиядерними процесорами підходить для цього ідеально.
• для термінального сервера досить одного процесора Xeon E5620 з шістьма ядрами, для сервера баз даних - процесора Xeon E3-1220v3 з чотирма ядрами.

Оперативна пам'ять

Спочатку подивимося, скільки потрібно оперативної пам'яті під сервіси:

• Операційна система Windows Server тільки під себе вимагає 2 Гб ОЗУ.
• Для SQL і невеликої бази 1С достатньо буде 4-6 Гб ОЗУ.
• Сервер «1С: Підприємство» вимагає ще 2-3 Гб ОЗУ.
• Розраховуємо, що кожному користувачеві буде потрібно 700 Мб ОЗУ в термінальній сесії, тоді на 30 користувачів потрібно 21 Гб.

Тепер застосуємо це до наших варіантів.

• Для одного сервера з двома віртуальними машинами потрібно близько 40 Гб ОЗУ.
• Для термінального сервера досить буде 24 Гб або 32 Гб ОЗУ (візьмемо з запасом, припускаючи майбутнє розширення). Для сервера з базами даних потрібно не менше 8 Гб, але це «впритул», тому 16 Гб з запасом. Пам'ять зараз - один з найдешевших компонентів сервера.

дискова підсистема

Це традиційне пляшкове горлечко багатьох систем. Правильний вибір жорстких дисків дуже важливий для забезпечення швидкодії серверів. При роботі 1С з базою SQL відбувається безліч операцій читання / запису в секунду (IOPS). Якщо користувачі працюють на термінальному сервері з тонких клієнтів (тобто повноцінно використовують термінальний сервер як робоче середовище), це сильно навантажує дискову систему сервера. Наприклад, 30 користувачів термінального сервера на RAID 1, SATA 3 Гбіт / с, з дисками WD Velociraptor відчувають себе некомфортно при роботі з поштою і активному серфінгу в інтернеті. Для термінальних серверів ми рекомендуємо використовувати SSD-накопичувачі. Для серверів баз даних - SAS-диски, зібрані в відмовостійкі масиви.
Крім накопичувачів, слід приділити увагу і дискового контролера. Сучасні сервери мають на борту досить хороші контролери, наприклад, HP SmartArray і DELL PERC. Однак некоректно буде використовувати «набортні» рішення при серйозної навантаженні, коли потрібна максимальна продуктивність. Трохи заощадивши, ви легко можете отримати потужний сервер, який абсолютно не тягне навантаження. Тому контролер повинен бути апаратним, а не програмним , Зі своєю незалежною пам'яттю.
Розглянемо варіанти вирішення цього завдання.

• Для одного сервера з двома віртуальними машинами бажано використовувати два RAID-масиву: на одному будуть розташовуватися файли віртуальної машини термінального сервера, на другому - файли віртуальної машини сервера баз даних і «1C: Підприємства». Для створення першого масиву найкраще використовувати два SSD-накопичувача в RAID 1 (дзеркало).
  Другий масив краще створити з чотирьох SAS-диска в RAID 10 (дзеркало + страйп), але можна і з двох SSD-накопичувачів в RAID 1. Вибір залежить тільки від вартості дисків і моделі сервера.
• Для двох серверів все те ж саме, тільки масиви будуть рознесені по серверам. На термінальному - RAID 1 з двох SSD, на сервері баз даних - RAID 10.

Один або кілька серверів

Як сказано вище, у невеликих організацій досить велике бажання розмістити всі сервіси на одному сервері.
До переваг використання одного сервера і віртуалізації можна вважати більш низьке енергоспоживання і більш гнучкий розподіл ресурсів між віртуальними машинами. Ну і перенесення віртуальних машин, в разі чого, набагато зручніше, ніж перенесення фізичних ОС.
Однак два сервера мають ширші можливості по апгрейду. Наприклад, в нашому варіанті недорогий IBM x3550 M3 з додаванням ще одного процесора і ОЗУ перетворюється в елегантні шорти термінальний сервер на 50 і навіть більше користувачів.
Ще одне «вузьке місце» в нашому випадку, яке необхідно враховувати при виборі двох фізичних серверів, це обмін даними між ними по мережі. У віртуальних серверів обмін даними йде через віртуальний комутатор. Тут же, для збільшення пропускної здатності мережі, можна встановити в кожний сервер по мережевої карти з двома гігабітними інтерфейсами, які можна агрегувати між собою і безпосередньо з'єднати обидва сервера агрегованими 2-х гігабітними лінками. Або ж використовувати мережеві карти з SPF + 10GBASE, але це дороге задоволення.

Запас по потужності

При розрахунках і виборі сервера необхідно брати до уваги пікові навантаження. Також обов'язково потрібно пам'ятати, що база даних буде тільки «пухнути», обсяги даних на термінальному сервері будуть рости, а кількість користувачів може збільшитися. Багато підприємств економлять на запасі потужності і через півроку-рік стикаються з перебоями в роботі і скаргами користувачів. Це той випадок, коли надмірна економія призводить до нових витрат в майбутньому - скупий платить двічі. Обрані нами варіанти розраховані з запасом потужності і можливістю апгрейда. Враховано, що в DELL R710 можна буде додати ще два жорсткі диски і ОЗУ, а також замінити процесори на більш продуктивні.
Так що, якщо вам буде потрібно розширення, або кількість сервісів збільшиться, то тут є великі перспективи, а існуючі сервери ще довгий час будуть ефективно виконувати свої завдання. Можливо, через рік нам несподівано потрібно збільшити кількість користувачів в два рази, до 60 чоловік? Будь ласка.
Якщо ви використовували один сервер DELL R710, то можна докупити недорогий IBM x3550 M3, підняти на ньому гипервизор, перенести туди віртуальну машину з БД і 1С-сервером, а на DELL-е всі ресурси віддати віртуальній машині з терміналом. Це буде швидко, і не буде потрібно «все викинути і купити нове».
Якщо ж ви використовували два сервера IBM, то x3550 M3 з додаванням другого процесора і невеликої кількості ОЗУ перетворюється з середнячка в досить потужну машину. А в x3250 M5 можна оновити процесор з E3-1220v3 до E3-1285v3.

висновок

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

+7

Refurbished-сервери HP, Dell і IBM (Lenovo)

Схожі публікації

Коментарі (50)

А бекапи? Або передбачається, що вже є, куди їх робити?
Чим поганий варіант з сервером на Xeon 2600 серії для двох віртуалок?
В ідеалі, окремі диски треба під систему і окремо диски під профілі термінальних користувачів, бази 1С та інше добро. З нормальної політикою зберігання документів десь на файловому сервері. Навіть у відносно дешевих варіантах таке є (за умови, що файловий сервер вже є). А якщо файлового сервера немає - немає і бекапов?
А ще, хотілося б дізнатися у тих, хто це використовує: RAID 1 на SSD варто цього? Диски не вмирають одночасно?

Звичайно варіантів реалізації сервісу 1С дуже багато. Ми рекомендуємо робити бекапи на окрему залізяку, для зручності.
Варіант на Xeon 2600 не поганий, але він значно дорожче, а для даного завдання досить і Xeon 5600 серії.
Про SSD диски спостерігали практику в дата центрах, коли диски ставили в Raid 1 з різних партій, але можливо це зайві обережності.
У практиці не зустрічали щоб SSD вмирали одночасно.

А в разі виходу з ладу окремих компонентів - не буде потім проблем з пошуком заміни при використанні застарілого заліза?
Xeon 5600 вже років 5 не виробляють же.

В основному використовуємо Raid10, ще не разу не вмирали одночасно диски. Хоча намагаємося ставити різних виробників (в основному samsung і intel) або різні моделі одного виробника.

Рік тому зробив RAID0 з 2-х SSD, сервер нормально крутиться до сих пір. Щодо RAID1 з SSD нічого сказати не можу.

Ем вважаю що термінальний сервер це зайва трата грошей, якщо в якості кінцевого сервісу це тільки 1С підприємство, набагато дешевше і розумніше вчинити інакше:
1. Всі на одному сервері, для доступу клієнтів використовуємо Apache під Windows
2. Два сервера, 1с ОС Linux для доступу клієнтів до бд, другий це наш SQL + 1C Підприємство.
Конкретизувати конфігурації я не буду, для доступу 50 осіб в базу нам вистачить сервера з 2 ГБ оперативної пам'яті, найповільнішим диском і тд, для цих цілей можна взагалі орендувати сервер в хмарі за 500 рублів в середньому в місяць. При цьому для масштабування системи в майбутньому, фронтедом вішаємо Nginx налаштовуючи його як балансувальник по 443 порту, а бакендом апач на цьому ж сервері, в разі зростання компанії додаємо ще один сервер з Апачем і рядок в конфігурацію Nginx.
Якщо ж все вішаємо на 1 сервер то там просто віндовий апач, з опублікованої БД. І ось саме для БД я б подбав не тільки процесором а саме SSD причому бажано рознести дані логи і tempdb на різні диски.
І не витрачав би гроші на сервер терміналів і термінальні ліцензії і по 700 метрів ОЗУ на кожного користувача, мені здається це в сучасних реаліях просто марнотратство ресурсів і не достатня глибина знань предмета.

Це за умови, що ваша конфігурація через веб працює як треба. Що, взагалі кажучи, не завжди правда (банально, сканер ШК підключити не вийде, як і запустити конфігурацію, яка з «Інтернетом» не друг).

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

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

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

> Абсолютно вірно, в тому випадку, якщо кінцевий сервіс тільки 1С.
Це те з чого і треба було починати статтю. Тобто термінальний сервер вам потрібен НЕ ДЛЯ 1С.
* Для саме 1С темінальний сервер марний (в разі використання тонкого клієнта звичайно), тільки зайві витрати на ліцензії MS
* У разі економії і розміщення сервера 1С і MSSQL на одній машині з'являється дуже приємний бонус у вигляді підключення через SharedMemory з помітним прискоренням.
* Для 1С критична до частоти процесора (це дійсно важливо), тому що не паралельний один процес. Але багатоядерність потрібна в разі значного числа активних користувачів. Так що для невеликих груп дуже вигідно виглядає серія Е3.
* А ось MSSQL набагато частіше може паралелі один запит на кілька процесорів. Як результат досягнуто не забуваємо про існування cpu affinity.
* Не варто забувати що в разі складних звітів на СКД йде обробка локально в тимчасових файлах на стороні сервера 1С. Тому бажано виносити дані кластера 1С на окремий дисковий тім (за замовчуванням він на системному розділі).
* Про оптимізацію самого mssql окремі трактати і дуже важливо їх не ігнорувати.
*! *! Найголовніше в продуктивності 1С - це сам код конфігурацій. Ніякі танці навколо потімізаціі «заліза» не замінять голову програмісту, який РАПТОМ вирішить вибрати по сотні тисяч записів з десятка таблиць потім їх об'єднати (в екстремальних випадках без Джойна навіть) і тільки після цього накласти фільтри.
PS: Радити дивитися на серію 56 ** якось дуже дивно в 2016 році

Робів подібний проект на двох серверах dell r420 для відмовостійкості, це булу Основна Вимога. Додатково там же працювала IP АТС на базі elastix. Разом на 2х серверах 2 * 2640v2 / 32Гб / 2 * ssd 240Гб: домен, термінальній сервер, сервер 1С з базою mssql, ip атс. У разі відмови будь-якого сервера робота зупиняється максимум на хвилину. Бекап на зовнішнє мережеве сховище.

А Вам не страшно віртуалі DC і розміщувати на тій же хостовой машині?

Які ви бачите ризики?

Неможливість вирішити проблему віддалено, якщо щось не так з машиною DC. Та й по продуктивності - віртуалізація повільніше.
Та й принцип «не класти всі яйця в одну корзину» - збільшувати кількість точок відмови, щоб не накрилося відразу все (хоча реплікація на рівні віртуальних машин рятує, так).

дистанційне керування сервером є, можна під локальної учеткой зайти якщо що. І серверів 2, контролерів теж м2 (не 1 на 2 віртуалкою)

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

А що такого в КД на виртуалке? Віндовий кластер навчився працювати при їх недоступності в 2012.

Небажання КД в виртуалке - пережиток минулого. Ну а якщо забув вимкнути синхронізацію часу гостя з хостом через VM-tools, то ССЗО.

Там ще пачка просунутих налаштувань, але з 2012 жити стало набагато простіше.

• yosemity 19 липня 2016 о 17:13 (коментар був змінений)

Я живу з vSphere і в вус не дую :)

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

А чи не поділитеся інформацією про ці настройках?

Ще в Windows Server 2012 з'явився VM-Generation-ID (потрібна підтримка з боку гипервизора), який змінюється при відновленні з снепшот і КД звалюється в DSRM щоб уникнути втрати даних.

Я так і не зрозумів, це аргумент «за» КД на виртуалке або «проти»?
Або це просто попередження - не використовувати снепшот для КД?

Напевно «за», так як стало трохи складніше вистрілив собі в ногу.

Спочатку автор пише, що хоче по-дешевше все зробити, але потім пішло про MSSQL і вінду? Тут постгрес і лінукс, а не мсскл і винда ...

• Melex 19 липня 2016 о 19:32

Та ну блін, і не набридло вічно про це згадувати?
Ліцензія скулячи + вінди буде значно дешевше, ніж найняти адекватного спеца, який нишпорить в Лінуксі і постгрі.
1с під виндой - працює швидше ніж під лінуксом, і на вилиці - з коробки, теж працює швидше.
Ті рівні змін, які потрібно зробити в постгрі, що б він почав працювати на рівні з sql - дуже високі. Тобто необхідний спец, не дешевий, і ви постгрі ніколи не налаштуєте за 10 хвилин, та навіть за 1 день. Так як з ним необхідно воювати постійно, ви повинні його підлаштовувати під реальні процеси компанії (кількість документів, масштаби звітів і прочє-таке інше).
Тобто мінімум на пів року. Це раз.
Два - спецам необхідного рівня - ваще не в кайф сидіти і колупати 1С, отримуючи гнівні відгуки від бабусь з Бухгатер, за те, що повільно щось працює і взагалі - полагодь і заправити їй принтер.
Звідси висновок - мс скульптура + винда, це єдине що має сенс ставити компанії зі штатом до 100 чоловік.
А ось якщо у вас 200 чоловік, кілька баз і т.д., ось тоді так, тоді інша пісня.
І якщо ви зараз скажіть, що ви постгрі налаштували за 10 хвилин і все літає, я, і не тільки я - просто не повірю.

Насправді все простіше.
Для невеликих баз в загальному то немає особливої ​​різниці Postgres або SQL.
Для великих і навантажених все одно потрібно вміти налаштовувати і Postgres і SQL і фахівці потрібні з відповідними рівнями.
Установка Postgres (https://postgrespro.ru/products/1c_build) в загальному то просто не складніше SQL (само собою для Linux адміністратора).
Щодо спеців, якщо це рішення для бізнесу то в і для Win і для Nix потрібні тямущі адміністратори, то що в Win поріг входу нижче я б записав в недоліки.
У тому вигляді в якому описано в статті використовувати Win платформу є сенс тільки якщо адмін всю цю систему буде та ж сама людина який буде супроводжувати і допрацьовувати 1С (для невеликих компаній і / або філій це нормально).
Більшість 1С ників (включаючи і мене) «win only» так як 1С довгі роки була так само «win only» і тільки останнім часом розгорнулася в бік * NIX, в результаті фахівців з 1С вміють працювати з чим то крім MSSQL + WIN досить мало .
* З приводу того що фахівцям «ваще не в кайф сидіти і колупати 1С», на мій погляд це дуже спірне твердження. Якщо 1С це серце бізнесу (а так часто буває) то що там «в кайф спецам» власників бізнесу мало хвилює. Як на мене так напрямок Linux + 1C дуже перспективне.

• Melex 21 липня 2016 о 17:19

Ви багато в чому мають рацію, але так, постгря налаштовується за 10 хвилин, якщо знаєш. Для початку просто беремо pgtune + правка деяких налаштувань, звичайно потрібно знати будь. За своєю інструкції сервер на дебіане 8 х64 + 1с х32 + ПГ 64 9.4.8 від ПостгресПро я підніму за півгодини з нуля, включаючи установку ОС. При чому вже з настройками. Не впевнений чи потрібна така невелика інструкція на Хабре.

\\ «для невеликої організації на 25-30 користувачів»
Тільки мені здається що пропоноване залізо виходить за рамки невеликої організації.
\\ це лише один з прикладів недорогого впровадження 1С
Недорогого? Мабуть я зовсім відстав від життя.

Планую робити ферму віртуалок. Призначені для користувача виртуалки будуть на linux і windows для використання 1с, офісного пакету і браузера.
Писати статтю?