Продуктивний файловий сервер під Windows
Частина ніяка - роздуми без спогадів.
Без зайвих вступів почнемо з думки про те, що таке файловий сервер, як він функціонує і що нам потрібно, щоб зробити файловий сервер якомога більше спритним, наприклад, щоб якомога повніше використовувати нашу гигабитную мережу. На перший погляд все просто. Прийшов клієнт, попросив файл, злазили на диск за файлом і віддали клієнтові. Куди простіше. На другий і більш просунуті погляди - все набагато складніше. Файловий сервер це щось більше, ніж просто мережевий інтерфейс до жорсткого диска. Звичайно, швидкість читання у сучасних вінчестерів не маленька, але що буде, коли прийде не один клієнт, а кілька десятків? Крім того, що доведеться ділити це саме читання між клієнтами, доведеться ще й стрибати, зчитуючи дані з різних місць диска. А час доступу величина вже досить пристойна: Механіка, блін, ніякої продуктивності. Щоб все працювало швидко, і клієнти від роботи з файловим сервером мали таке ж враження, що і від роботи з локальним диском, треба цю механіку якось замінити на електроніку. Тобто клієнти повинні отримувати дані не з жорсткого диска, а з оперативної пам'яті, якої повинно бути достатньо. Стандартний механізм роботи файлового сервера -
Диск -> пам'ять -> мережа
Стежить за всім цим, зрозуміло, процесор.
Отже, візьмемо за вихідне те, що нам слід:
- Багато працювати з пам'яттю, переміщаючи дані з жорсткого диска в пам'ять і з пам'яті - в мережевий адаптер.
- Робити все це одночасно.
Зробити швидше передачу будь-яких даних можна двома з половиною способами - збільшити швидкість передачі (наприклад, частоту шини) або распараллелить передачу.
Що залишився дуже ефективний полуспособ - взагалі уникати передачі даних скрізь, де це можливо.
Найбільше робота файлового сервера нагадує роботу серцево-судинної системи з двома колами кровообігу. І, як ми побачимо далі, економити на ньому складно.
Частина перша - вибираємо платформу.
Чіп і сет поспішають на допомогу.
Відмінності видно, якщо подивитися на діаграми чіпсетів:
Мал. 1 - діаграма чіпсета високопродуктивної робочої станції Intel 995X.
Мал. 2 Діаграма чіпсета сервера початкового рівня Intel E7230
Питання в тому, куди ми будемо кидати кістки, в сенсі встромляти обладнання. У 955x швидкісна 8-Гігабітна шина PCI Express x16 використовується для графіки. Для підключення дискових і мережевих адаптерів ми можемо використовувати PCI або PCI-X через південний міст (ICH7R). Але продуктивність шини DMI між південним і північним мосто становить 2GB / s, які будуть ділитися між диском і мережею. Шина синхронна і тут гігабайти, а не гігабіта, тобто швидкість цілком пристойна, але все ж. Серверна платформа має додатковий PCI Hub, що забезпечує підключення до портів PCI-X через шину PCI Express x8 і порти PCI Express x8 і x4, що дозволяють на повну використовувати навіть 10 гігабітний Ethernet, причому при цьому дискова підсистема зможе використовувати іншу шину. Чим платформа, тим розташовуються швидкісні периферійні шини і тим більше цих шин підключено безпосередньо до північного мосту, дозволяючи з мінімальними затримками переміщати дані від зовнішніх пристроїв до пам'яті і процесору.
З пам'яттю все ясно. Цей ресурс для нас найкритичніший, тому пам'ять повинна бути максимально спритна.
Процесор? Який процесор?
З одного боку процесор в файловому сервері завжди залишається трохи збоку від основних потоків даних, якщо мережевий адаптер підтримує апаратне обчислення контрольних сум і сегментацію даних і якщо, звичайно, ми, з дуру, не вирішили, наприклад, шифрувати весь трафік. З іншого боку - він не зайвий, тому що кожен пакетик, який ми відправляємо в мережу, повинен бути сформований: А пакетик цей не великий, значить їх буде багато, особливо якщо мережа, не дай бог, дуже продуктивна, і робота для процесора є . Крім того, наш процесор керує і отримує повідомлення від різних пристроїв - мережевих адаптерів, контролерів дисків. Чим швидше він ці повідомлення обробить, тим краще. А ще краще, якщо повідомлення від різних пристроїв будуть оброблятися паралельно на різних процесорах. Отже, при виборі процесора слід враховувати:
- Як не дивно це звучить для знавців паралельних обчислень, краще два повільних процесора, ніж один швидкий, і чим більше різних контролерів і адаптерів ми маємо, тим більше переваг від многопроцессорности ми отримаємо.
- Чим більше паралельних звернень до пам'яті (більше системний кеш), тим сильніше впливає розмір процесорного кешу. Причому кеші двох різних процесорів не сумуються.
- Багато потужних процесорів буде потрібно, коли ми дійдемо до многогігабітной мережі.
- Частота шини процесора може впливати на частоту шини пам'яті. Тому треба вибрати процесор, що працює з частотою шини, що не уповільнює роботу з пам'яттю.
Як ми вже підрахували, 1 Gb / s (Гигабит в секунду) і 1GB / s (Гігабайт в секунду) - це зовсім не одне і теж. Якщо ми будемо дивитися на гігабітний Ethernet, то реальна швидкість передачі за більш-менш тривалий період часу в ньому буде не більше 90 MB / s по одному порту через асинхронности шини. І, щоб обслуговувати велику кількість клієнтів, гигабитного Ethernet може бути недостатньо. Перша альтернатива перейти на 10 гігабітний Ethernet, що дорого і не дуже стандартно. Особливо це стосується адаптерів, здатних працювати по швидкісним версіями PCI-X або PCI Express x4 / x8. Подібне рішення може окупитися на серверах корпоративного рівня. У якості більш дешевої і менш швидкісний альтернативи можна мати багато гігабітних адаптерів. Драйвери багатьох адаптерів дозволяють об'єднувати їх в один віртуальний для підвищення продуктивності. Але запам'ятаємо, що такий режим роботи може викликати подив у деяких комутаторів (світчей) і обов'язково вимагає ретельного тестування. Продуктивності шини PCI не вистачає навіть для гігабітного адаптера, з урахуванням дуплексной передачі, краще, звичайно, використовувати PCI Express або PCI- X адаптери. Не рекомендується використовувати здвоєні адаптери. Для Ethernet 10 Gb / s необхідно використовувати порти PCI-X 266/533 або PCI Express x4 / x8. PCI-X - синхронна шина і реальна її продуктивність близька до максимальної 1 GB / s для PCI-X, 2 GB / s для PCI-X 266 і 4 GB / s для PCI-X 533. PCI Express - асинхронна шина і реальна швидкість передачі нижче теоретичної максимальної. Але ідеологічно до Ethernet ближче PCI Express.
У більшості сучасних адаптерів підтримуються можливості "TCP Offload" - тобто перенесення обчислювальних задач, пов'язаних з організацією мережевого з'єднання з процесора на мережеву карту. Зазвичай підтримується виконання як мінімум двох завдань: обчислення контрольних сум пакета (Checksum Offload) і сегментування великих пакетів (TCP Segmentation offload, в деяких драйвери Realtek і HP це називається TCP Large Send Offload). Для продуктивного сервера на гігабітних швидкостях ці завдання критичні, тому що складають до 30% всіх обчислювальних задач сервера через те, що весь потік даних піде в процесор для обчислення контрольних сум. Тому дуже важливо, щоб мережевий адаптер виконував ці завдання, причому виконував коректно. У разі, коли необхідно шифрування трафіку, мережевий адаптер повинен підтримувати і IPSec Offload. Адаптери з підтримкою IPSec коштують значно дорожче, але навіть на них продуктивність в кілька гігабіт залишиться мрією.
Перше питання - SCSI або SATA.
Якщо ми не женемося в сторону сотень мегабайт в секунду, то зійде і SATA. Для високопродуктивних систем, звичайно все-таки SCSI. Недолік рішень на шині SCSI - маленькі обсяги і висока вартість на одиницю об'єму. Але вона швидше. 320 MB / s в Ultra320 SCSI це відсотків на 10% швидше, ніж 3 Gb / s в SATA II, знову ж таки через фокусів послідовної шини, якої є SATA. Реальна усталена швидкість читання / запису передових моделей SCSI дисків так само приблизно в півтора рази вище, ніж дисків SATA-II, наближаючись до 100 MB / s. Ще одна перевага дисків SCSI - їх набагато простіше набити у великій кількості. Чим більше ми наб`ємо дисків, тим вище буде продуктивність дискової підсистеми, тому що доступ до дисків може здійснюватися паралельно. Звичайно, маючи в розпорядженні практично SATA, гріх ним не скористатися хоч якось, наприклад, розмістити на ньому систему або навіть якісь дані.
Виходячи з наведених цифр, можна настійно порекомендувати використовувати двоканальні або чотирьохканальні SCSI контролери і не вішати на канал SCSI більш 2-3х дисків. При необхідності мати більше 6 дисків, треба мати двоканальний контролер, використовувати кілька контролерів SCSI або дивитися в бік більш швидкісних інтерфейсів, таких як Fibre Channel. На сьогодні є вже достатня кількість продуктивних контролерів SCSI, наприклад, MegaRAID від LSI з підтримкою PCI Express до x8. Нам цілком вистачить PCI-X або PCI Express x4 для добре набитого дисками двоканального контролера, але звичайного PCI Express буде замало. Ідеологічно SCSI адаптер ближче до PCI-X.
Друге питання: який RAID використовувати?
Питання, чи використовувати RAID для файлових серверів, не варто. Завдання для RAID в даному випадку дві - забезпечити відмовостійкість дисків і максимально підвищити швидкодію дискової підсистеми за рахунок розпаралелювання записи і читання по дискам. Звичайно, самий швидкий RAID - це RAID 0. Проте отказоустойчивостью він не володіє. RAID 5, на жаль, уповільнює операцію запису, особливо при записі невеликих шматків даних, але при цьому залишається досить швидким на читанні. Це наслідок необхідності перераховувати і перезаписувати контрольні суми під час запису неповного блоку. Добре збалансовану продуктивність на читання і запис має RAID 10 (один-нуль), але при цьому ми втрачаємо половину ємності дисків. Тому, можна порекомендувати RAID 10 для зберігання даних, з якими йде постійна робота, наприклад, поточних документів, RAID 5 для різних архівів і сховищ і RAID 0 для тимчасових даних, таких як кеш оптимизирующего проксі-сервера. Природно, для більш якісного розпаралелювання, краще використовувати в RAID'е максимальне число дисків і бажано з різних каналів.
Ну, а як ви самі думаєте, який потрібно мати корпус, щоб в нього все це:
З того, що було сказано вище, відразу промальовувалися два типи файлових серверів. Перший - файловий сервер початкового рівня з продуктивністю до гігабіта в секунду, до якого немає практично ніяких вимог по обладнанню (за умови, що воно досить сучасне) - фактично, можна використовувати гарне десктопних залізо з інтегрованим SATA RAID 1-0. У мультігігабітном файловому сервері заощадити не вийде ні на чому, коштувати він буде на порядки дорожче.
Частина друга - вибираємо і тюнінгуем систему.
вибираємо систему
Краще використовувати англомовну версію системи на серверах - в разі виникнення проблем легше знайти відповідну статтю в базі знанійMicrosoft.
налаштовуємо систему
Власне, стандартна настройка системи під файловий сервер мінімальна. У властивостях мережевого підключення необхідно відкрити властивості File and Printer Sharing for Microsoft Networks (служби доступу до файлів і принтерів) і поставити жирну крапку на Maximize data throughput for file sharing.
Рис.3 вибір оптимізації Microsoft File Sharing
Як працює і системний кеш?
Оптимізація і розгін файлового сервера.
Зараз я всіх дуже розчарую. Реальна оптимізація файлового сервера відбувається на рівні обладнання, що ми вже обговорили. Той. про який ми будемо говорити, дасть виграш більше 10% тільки на погано збалансованому обладнанні. Усунення вузького місця в обладнанні (наприклад, заміна процесора) в такому випадку дасть набагато кращі результати. Як ми бачимо, робота файлового сервера досить проста. Все що ми можемо - це скоротити будь-які затримки - час, що йде на відкриття / закриття файлу, на простий запиту в черзі і т.д. Все інше - виключно питання обладнання.
З огляду на особливості роботи кеша і обробки черги запитів, файловий сервер не буде показувати чудеса продуктивності, якщо на ньому крутяться якісь програми, інтенсивно використовують пам'ять (особливо з постійним виділенням і звільненням) або нерівномірно завантажують процесор. Не варто давати файловому серверу будь-які додаткові ролі в мережі, крім, може бути, ролі контролера домену та сервера Active Directory, за умови дуже невеликого числа (порядку десятків) користувачів сервера.
Оптимізація роботи з обладнанням
Microsoft рекомендує, щоб в багатопроцесорних системах (реально багатопроцесорних, мова не йде про технології гіпертрідінга) переривання від одного і того ж мережевого адаптера оброблялися одним і тим же процесором. За замовчуванням переривання може бути оброблено будь-яким процесором. Можна використовувати IntFiltr (ftp://ftp.microsoft.com/bussys/winnt/winnt-public/tools/affinity/) для прив'язки переривань певного пристрою до одного процесору.
HKLM \ System \ CurrentControlSet \ Session Manager \ I / O System \ CountOperations
Зі значенням 0 відключає різні лічильники для жорсткого диска, що може прискорити операції введення / виводу.
Апаратний RAID контролер може виконувати більше запитів SRB за рахунок розпаралелювання. Рекомендується підняти це значення в діапазоні від 32 до 96.
HKLM \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ Memory Management \ IoPageLockLimit
Скільки пам'яті (в кілобайтах) може заблокувати система під операцію введення / виводу. Значення за замовчуванням 512 KB. Збільшення цього параметра призведе до збільшення обсягу даних, які можна передати за одну операцію. Можна зустріти рекомендації збільшити це значення аж до 128Мб, однак, збільшення понад декілька мегабайт (наприклад, в межах 8-16) навряд чи буде ефективно.
Оптимізація параметрів файлової системи
HKLM \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ Memory Management \ PagedPoolSize
Вивантажуваний пул і файловий кеш поділяють одну і ту ж область пам'яті. Вивантажуваний пул потрібно для роботи з файлом підкачки, який при достатньому обсязі пам'яті на файловому сервері нам практично не буде потрібно. Ми можемо трохи збільшити доступну пам'ять для файлового кеша за рахунок зниження розміру вивантажується пулу (вказується в байтах). Можна брати значення порядку 128MB або навіть менше.
Забороняє створення коротких псевдонімів імен файлів. Ця можливість потрібна в тому випадку, якщо на диску будуть зберігатися дані, оброблювані додатками MS-DOS або Windows 3.x (потрібно мати на увазі, що такими є багато інсталяторів). Відключення (значення 1) незначно прискорює процедуру створення файлів.
При установці в 1 забороняє зміну часу доступу при зверненні до файлу на читання. Час останнього доступу застосовується вкрай рідко (на відміну від часу створення і модифікації). Заборона його поновлення дозволяє прискорити процедуру відкриття файлу на читання.
Оптимізація мережевих параметрів
Непогано б почати з того, що відключити всі невикористовувані мережеві з'єднання (для мінімізації роутінговой таблиці), протоколи та клієнти. Можна зазирнути сюди:
Розмір вікна TCP. Розмір вікна слід збільшити в мережах з високою пропускною здатністю і великими затримками. Це можуть бути: мережі продуктивністю в кілька гігабіт на секунду, сильно віддалені мережі (через супутник або кілька маршрутизаторів), завантажені мережі, в яких досить високо кількість усунених колізій, мережі зі слабкими клієнтами, наприклад зі старими комп'ютерами. При збільшенні вікна (TcpWindowSize) понад 65,535 (близьке до цього значення використовується для гігабітних і вище інтерфейсів) слід поставити в 1 значення TCP1323Opts.
Вказує на розмір хеш-таблиці TCP-з'єднань (за замовчуванням 128). Максимальне значення - 65535. Оптимальне значення - не менше ніж числа очікуваних одночасних підключень. Можна підняти і до максимального значення.
Вказує на скільки TCP пакетів (за замовчуванням 2) надсилається ACK. Microsoft рекомендує збільшити це значення до 13, щоб знизити число переданих по мережі пакетів.
На цьому все. Пишіть. Діліться враженнями. Зауваженнями. Радами.
Передрук даної статті неможлива без дозволу видавництва Gameland