Реклама
Реклама
Реклама

SQL сервер для 1С: вибір конфігурації сервера

Матеріал надано сайтом www.learn1c.ru /

Cвершілось! Ви дозріли для перекладу бази 1С в формат SQL, і радість від прийняття такого рішення затьмарює лише одне - ви не знаєте з чого почати. Ця стаття, сподіваюся, допоможе Вам визначитися, що і в якому порядку Вам слід зробити, щоб обійти можливі підводні камені. Скажу відразу, тут не буде рекомендацій щодо вибору конкретного "заліза" і процедурі перенесення бази на SQL сервер. Це окремі питання, відповіді на які можна знайти в методичній літературі та форумах в Інтернеті.

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

вибираємо сервер

Я думаю, Ви переводите 1С на SQL з метою збільшення надійності і здатності навантаження програми. Тому приділіть особливу увагу вибору сервера, на якому буде виконуватися програма MS SQL Server (в статті буде розглядатися MS SQL Server 2000, далі за текстом - SQL сервер):

  1. Відразу вибирайте справжній сервер, тобто комп'ютер з серверної архітектурою. Тим самим Ви позбавите себе від головного болю в майбутньому, коли з невідомих причин буде валитися база 1С, перезавантажуватися комп'ютер, і додавання диска буде перетворюватися в нездійсненне завдання.
    Ця вимога особливо актуально для підприємств, на яких вихід з ладу інформаційної системи тягне за собою великі збитки. Прийміть це до уваги, якщо все-таки схиляєтеся до покупки звичайного комп'ютера.
  2. На сервері бажано наявність 2х і більше процесорів. Це пов'язано з тим, що SQL сервер може ефективно використовувати кілька процесорів для розпаралелювання завдань. До того ж в багатопроцесорної середовищі не буде настільки явною конкуренції за процесорний час між операційною системою і SQL сервером.
  3. Переконайтеся, що на сервері встановлена ​​гигабитная мережева карта. Цим вимогою можна знехтувати, якщо Ви плануєте організувати термінальний сервер, на якому будуть працювати і 1С, і SQL сервер.
  4. Не економте на оперативній пам'яті.
    Звичайно, не слід ставити 16Гб пам'яті на сервер під керуванням MS Windows Server 2003 Standard Edition (32-розрядної версії). Це буде марною тратою грошей, так як ця редакція Windows підтримує тільки 4 ГБ пам'яті.
    У той же час установка 2ГБ пам'яті при тих же умовах буде теж нераціональною, так як SQL сервер не зможе скористатися всіма 2ГБ, які теоретично йому може виділити операційна система.
    Вибір обсягу оперативної пам'яті залежить як від версії операційної системи, так і від редакції SQL сервера. Наприклад, якщо Ви збираєтеся використовувати MS Windows Server 2003 Standard Edition (32-розрядної версії) і MS SQL Server 2000 Standard Edition, ставте 4 ГБ пам'яті.
    Примітки: обмеження по пам'яті для різних версій Windows Ви можете подивитися в статтях " Memory Limits for Windows Releases "І" Memory Support and Windows Operating Systems ".
    Дані щодо максимального об'єму оперативної пам'яті, який може використовувати кожна редакція SQL сервера, можна знайти в Books Online (BOL) по рядку пошуку "Maximum Amount of Physical Memory". Невеликий фрагмент цієї таблиці наведено нижче:
    Матеріал надано сайтом   www
  5. Заздалегідь визначте, скільки жорстких дисків Вам знадобиться. Це питання буде розглянуто далі в статті.
  6. Подбайте, щоб сервер дозволяв змінювати що вийшли з ладу диски в "гарячому" режимі, тобто без виключення сервера. Зазвичай для цих цілей в серверах застосовуються спеціальні кошики для жорстких дисків.
  7. Вибирайте сервер з таким розрахунком, щоб в майбутньому в нього можна було встановити ще кілька дисків. Такий хід подій дуже ймовірний, тому що при експлуатації програми може виявитися, що сервер "гальмує" саме через дискової підсистеми.
  8. Використовуйте RAID-контролер з батарейкою. Це дозволить Вам зберегти дані навіть в разі знеструмлення сервера.
  9. Віддавайте перевагу сервера, в якому кілька блоків живлення. Причина очевидна - якщо один блок живлення виходить з ладу, Ваш сервер буде продовжувати працювати на справних блоках харчування.
    До того ж, якщо необхідна кількість жорстких дисків буде велике (наприклад, через півроку Ви вирішите підсилити дискову підсистему), може вийти так, що один блок живлення не зможе "витягнути" таке навантаження, і сервер буде працювати нестабільно (якщо взагалі буде).
  10. Завжди підключайте сервер до потужного джерела безперебійного живлення (ІБП), який зможе забезпечити час автономної роботи не менше 30 хвилин. За цей час користувачі зможуть завершити свою роботу в 1С, а Ви - не поспішаючи вимкнути сервер.
    В наявності потужного ДБЖ є ще один плюс: за проміжок часу між відключенням електрики і вимиканням сервера батареї ДБЖ не встигають сильно розрядитися. Таким чином, якщо за першим відключенням через невеликий інтервал часу піде друге, ДБЖ буде в змозі тримати навантаження, і Ви вдруге роботу сервера без ризику втратити дані.

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

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

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

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

Примітка: розгляд рівнів RAID виходить за рамки даної статті. Детальну інформацію по цій темі Ви можете отримати з BOL, використовуючи рядок пошуку "RAID", а також з численних статей в Інтернеті, наприклад, " Конфігурація і планування підсистеми введення-виведення ".

Наступний етап - визначення кількості дисків для бази даних в форматі SQL. SQL сервер зберігає базу даних як мінімум в 2-х файлах:

  • файл даних (* .mdf);
  • файл транзакцій (* .ldf).

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

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

Зімітуйте роботу SQL сервера, створивши інтенсивне навантаження на дискову підсистему сервера за допомогою якої-небудь спеціалізованої програми, наприклад, Performance Test або SQLIO . Під час виконання тесту спробуйте що-небудь зробити на сервері. Як працюється? Відчуваєте, яке "гальмування"? Це відбувається через те, що тестуються програма і операційна система використовують для своїх потреб один і той же дисковий масив і заважають один одному. Якщо не винести інтенсивну дискову навантаження на окремі диски, операційна система або зовсім перестане відповідати на запити, або буде працювати дуже повільно.

Сподіваюся, Ви погодилися, що файли бази даних слід розміщувати окремо від файлів операційної системи. Тепер запитаємо себе, наскільки раціонально розміщувати файл даних (* .mdf) і файл транзакцій (* .ldf) на одному дисковому масиві. Згадаймо кілька особливостей роботи SQL сервера:

  • доступ до файлу даних переважно довільний, тобто в будь-який момент часу система може зчитувати і записувати найрізноманітніші дані. Це призводить до того, що головки жорстких дисків постійно перепозиціюють, а це призводить до уповільнення операцій введення / виводу;
  • доступ до файлу транзакцій переважно послідовний, практично завжди в файл проводиться запис і лише іноді читання. Головки жорстких дисків переміщаються в основному на сусідні доріжки, що не займає багато часу;
  • при внесенні змін до бази даних, ці зміни спочатку фіксуються в файлі транзакцій, і лише потім у файлі даних під час чергової "chekpoint". Детальну інформацію по роботі з файлом транзакцій можна отримати з BOL по рядку пошуку "Write-Ahead Log".

Довільний введення-виведення, що генерується для файлу даних, буде заважати послідовного запису в файл транзакцій, в цілому знижуючи продуктивність підсистеми введення виведення. Хорошим рішенням буде рознести ці файли за різними масивів, тобто виділити один RAID1 для файлу даних та іншої RAID1 для файлу транзакцій. Рекомендації Microsoft з приводу розміщення файлу транзакцій можна дізнатися з BOL, рядок пошуку "Optimizing Transaction Log Performance".

Підведемо підсумки.
Нам необхідно 6 жорстких дисків, організованих в 3 масиву RAID1. Таке рішення забезпечить надійність зберігання даних, відмовостійкість операційної системи і швидкість обробки інформації SQL сервером.

Якщо фінансові можливості дозволяють, можна зробити SQL сервер ще швидшим. Для цього треба винести базу tempdb на окремий диск або масив RAID0. Ось що говориться з цього приводу в BOL:

Рекомендації Microsoft з приводу налаштування і розміщення tempdb можна дізнатися з BOL, рядок пошуку Optimizing tempdb Performance Рекомендації Microsoft з приводу налаштування і розміщення tempdb можна дізнатися з BOL, рядок пошуку "Optimizing tempdb Performance". Подивіться також обговорення цього питання на форумі www.sql.ru .

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

  • купити 2 або більше жорстких дисків;
  • замість RAID1, на якому зберігається файл даних, зробити RAID10 з 4, 6 і т.д. дисків

Якщо Ви наперед знаєте, що навантаження на диски буде великий, відразу купите не 6, а 8 або 10 дисків. Це позбавить Вас від необхідності в майбутньому перебудовувати масив з RAID1 в RAID10.

Я рекомендую розміщувати файл даних на масивах RAID10 або RAID1. Це найдорожче, але в той же час найнадійніше і швидке рішення (RAID0 не розглядається, тому що він не забезпечує відмовостійкості). RAID5 не підходить для роботи з 1С, тому що у нього дуже низька швидкість запису.

На закінчення хочу дати ще одну пораду - створіть резерв з 2-3 вінчестерів. Якщо раптом щось станеться з жорсткими дисками сервера, Ви зможете оперативно замінити їх на справні.

Передбачаю Ваше питання - навіщо такий великий резерв? У наш час характеристики жорстких дисків змінюються дуже швидко, і нові моделі приходять на зміну старим. Може вийти так, що до того моменту, коли на Вашому сервері вийде з ладу жорсткий диск (наприклад, через рік), такі моделі дисків вже не будуть проводитися.

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

Примітка: в статті висвітлено моя думка з приводу вибору конфігурації для SQL сервера. Воно може не збігатися з Вашою думкою і / або думкою інших фахівців.

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