Перевірка надійності конфігурації сервера 40 ТБ


21

У мене 40 років в обчислювальній техніці, але мені ніколи не доводилося будувати сервер, як цей, тому це може бути питання n00b.

У мене є клієнт, який буде пропонувати для завантаження музичні файли надвисокої якості. У цьому випадку це означає стиснений FLAC 24/192 КГц = ~ 10 Гб / альбом. (Ні, я не хочу обговорювати бажаність продукту, а лише конфігурацію сервера.) У каталозі буде близько 3000 альбомів, як ультрависоких, так і низьких версій (для їх iPod, я думаю), 35-40 ТБ або близько того первинних даних.

Оскільки це дуже спеціалізований продукт, розмір ринку відносно невеликий (подумайте: люди, які витрачають $ 20 000 + на свої аудіосистеми), що означає, що більшість часу сервер буде на 100% простоювати (або близько до нього). У мене є те, що виглядає як гарна пропозиція щодо колокації від ColocationAmerica з з'єднанням 1 Гбіт / с і пропускною здатністю приблизно $ 20 / ТБ, тому тепер мені просто потрібно створити коробку для доставки товару.

Випадок використання доступу до даних - це один раз / читати-багато, тому я думаю про використання програмного RAID 1 для пар приводів. Це дозволило б мені (я думаю ) переналаштувати запасні накопичувачі для несправних на ходу, тим самим мати можливість розпочати відновлення другого накопичувача до того, як деякий sysadmin помітить червоне світло в системі (вони роблять безкоштовну заміну). Було б чудово, якби я міг отримати більшість дисків у режимі сну / віджиму, якщо вони не потрібні, що буде більшість часу для більшості дисків.

Мені не потрібно багато на шляху до обчислювальної потужності - ця річ - це просто штовхання жирових об’єктів по трубі - і тому процесор / материнська плата можуть бути досить скромними, якщо вони можуть підтримувати таку кількість накопичувачів.

Зараз я розглядаю таку конфігурацію:

Chasis: Supermicro CSE-847E26-RJBOD1
Drives: 30 4TB SAS drives (Seagate ST4000NM0023 ?)
MB: SUPERMICRO MBD-X10SAE-O w/ 8GB
CPU: Xeon E3-1220V3 3.1GHz LGA 1150 80W Quad-Core Server

Отже, я йду в правильному напрямку, чи це абсолютно n00b / динозавр спосіб наближення до проблеми?

Оновіть, щоб уточнити пару пунктів:

  1. Я не маю досвіду роботи з ZFS, оскільки останній продукт Sun, яким я володів, був ще в кінці 80-х. Я зроблю трохи RTFMing, щоб побачити, чи правильно це відчувається.
  2. Мені не дуже потрібна файлова система, щоб робити щось вражаюче, оскільки імена файлів будуть простими UUID, а об'єкти будуть врівноважені між дисками (на зразок великої системи кешування). Тож я насправді думав про це як 40 окремих файлових систем, і це зробило RAID 1 правильним (але я тут визнаю невігластво).
  3. Оскільки ми очікуємо, що ми навряд чи зможемо завантажувати більше декількох десятків файлів одночасно, і в більшості випадків будь-який користувач завантажить будь-який файл, я не знаю, чи потрібні ми тонни пам'яті для буферів. Можливо, 8 Гб трохи легке, але я не думаю, що 128 Гб нічого іншого не витратять, крім споживання енергії.
  4. Є 2 окремих машин , які не йдеться тут: їх поточний інтернет - магазин, і майже повністю роз'єднаний Download Master , який обробляє всі аутентифікації, новий продукт вживає управління, забезпечення дотримання політики ( в кінці кінців, це є майданчиком в RIAA в), створенні ефемерною URL (і , можливо , передача завантажень більш ніж одному з цих звірів, якщо трафік перевищує наші очікування), відстеження використання та створення звітів. Це означає, що цю машину можна було майже побудувати з використанням піщанок на Quaaludes.

ZFS? Де користь?

Гаразд, я розглядаю шлях через кілька посібників із ZFS, поширені запитання та ін. Пробачте, що я звучав нерозумно, але я справді намагаюся зрозуміти користь використання ZFS над моїм допотопним поняттям N пар RAID1. На цій сторінці « Найкращі практики» (з 2006 року) вони навіть пропонують робити не 48 пристроїв ZFS, а 24 дзеркала з 2 пристроями - схоже на те, про що я говорив. На інших сторінках згадується кількість пристроїв, до яких потрібно отримати доступ, щоб доставити 1 (один) блок ZFS. Також пам’ятайте, що при 10 Гб на об'єкт та при 80% використанні диска я зберігаю загальну кількість 320 файлів на 4 ТБ накопичувача . Мій час відновлення з N RAID 1, для будь-якої несправності накопичувача, - це 4 ТБ запису з одного пристрою на інший.Як ZFS робить це кращим?

Я визнаю себе динозавром, але диск дешевий, RAID 1 Я розумію, мої потреби в керуванні файлами тривіальні, а ZFS в Linux (моя вподобана ОС) все ще молодий. Можливо, я занадто консервативний, але коли я дивлюся на виробничу систему, то так я кочуюся.

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


6
Для такої кількості пам’яті я б навіть не подумав використовувати менше 128 ГБ оперативної пам’яті. Також настійно подумайте про використання файлової системи zfs.
ЄЕАА

3
Пари дисків в RAID1 звучать ... жахливо. Особисто я розраховував би сервер / полицю для зберігання, набивав його повною мережею SAS-накопичувачів, помістив все в RAID 10 або 6, додав гарячу запасну або дві і зателефонував це в день.
HopelessN00b

3
@etherfish - оперативна пам'ять не потрібна для обчислювальних цілей, але вона, безумовно, потрібна для кешу файлової системи. Продуктивність лише 8 Гб була б жахливою. Тим більше, що при використанні ZFS, який насправді є єдиним, я б серйозно розглядав цей розмір. Для хорошої роботи ZFS потрібно багато оперативної пам'яті. На щастя оперативна пам’ять відносно дешева.
ЄЕАА

1
Продуктивність буде надмірно достатньою для насичення 1 Гбіт / с. Ефективність буде погіршуватися лише в тому, що файлова система повинна була перечитати блоки з диска, який був вилучений з буфера кешу і дається мало або зовсім не очікує тимчасової локальності, точка зменшення віддачі для додаткової оперативної пам’яті досягнута задовго до 128 ГБ. Враховуючи масштаб файлової системи та великих файлів, навіть метадані файлової системи займатимуть незначну кількість оперативної пам’яті. Він навіть розраховує, що використання буде достатньо рідким, що накопичувачі зможуть повернутися до міста. 73-х.
etherfish

5
Лише зауваження про закручування дисків - НЕ РОБИТИ! (Клацніть мені, щоб дізнатись чому) Spin-Up / Spin-Down сильно зношується на рухомих частинах традиційного жорсткого диска і може призвести до передчасного виходу з ладу. Гроші, які ви заощадите на електроенергії, будуть втрачені заміною несправних дисків.
voretaq7

Відповіді:


12

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

Як згадувалося в коментарях, я б пішов із ZFS за пулом пам’яті (напевно, на FreeBSD, тому що я найбільше знайомий з цією операційною системою і тому, що у мене є довгий перевірений досвід надійної роботи з ZFS - Мій другий вибір ОС буде Illumos , знову ж таки через добре перевірену підтримку ZFS).


Що стосується обслуговування файлів, я згоден - вам не потрібно багато з точки зору обладнання, щоб просто виштовхувати дані з мережевого порту. Вашим основним драйвером для процесора / оперативної пам’яті будуть потреби файлової системи (ZFS).
Загальне правило: ZFS потребує 1 Гб оперативної пам’яті, а також 1 ГБ на кожні 10 ТБ дискового простору, яким він керує (так що для 40 ТБ вам знадобиться 5 Гб оперативної пам’яті для ZFS) - хоча відносини не зовсім лінійні (хоча тут є багато хороші книги / навчальні посібники / документи з ZFS, які можуть допомогти вам скласти оцінку для вашого оточення).
Зауважте, що для додавання в ZFS дзвіночків, таких як дедуплікація, буде потрібно більше оперативної пам'яті.

Очевидно круглі вимоги оперативної пам’яті вгору, а не вниз, і не будьте скупі: якщо ваша математика каже, що вам потрібно 5 Гб оперативної пам’яті, не завантажуйте сервер з 8 ГБ - крок до 16 ГБ.

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


За цією порадою кращі пропозиції , які я можу дати вам уже добре освітлені в нашій серії планування потенціалу питань - в основному «Load Test, Load Test , Load Test ».


Роздумує, що ваша математика вимкнена. За вашою формулою йому знадобиться 41G.
ЄЕАА

@EEAA Дійсно, я впав нуль :-) І зауважте, що це мінімальна кількість оперативної пам’яті. ZFS буде дуже радий використовувати 41G і намочити це кешем :-)
voretaq7

@ voretaq7: дякую за посилання на планування потужностей; це наступне в моєму списку після прочитання про ZFS.
Пітер Роуелл

Якщо ви йдете з ZFS, розгляньте обладнання від ixsystems.com
sciurus

1
@PeterRowell Основні переваги ZFS полягають у тому, що він розроблений для обробки багато терабайтних масштабних файлових систем - він був підроблений в тиглі Sun Microsystems і побудований як файлова система 21 століття для розмірів даних 21 століття (такого типу, про який ви говорите) . Питання про переваги / недоліки ZFS порівняно з <деякою іншою файловою системою> було б гарною темою для іншого окремого запитання, але я відкину цей самородок: Немає такого, як чекати, fsckякщо ви використовуєте ZFS і машину збої. Я буду fsckтерабайтних файлових систем. Це досить страшно.
voretaq7

2

Я використовую ZFS для мультитуберкульозного сервера, і він був міцним. Я використовував OpenIndiana для початку і тепер перейшов до FreeNAS, оскільки він робить те, що мені потрібно для цього.

Я рекомендую використовувати карту HSI LSI (9211-8i - це хороша базова карта) з розширювачами SAS (випадки SuperMicro можна замовити з інтегральними розширювачами SAS, які базуються на LSI чіпсетах). Прошивки LSI підтримуються у FreeNAS та FreeBSD. Перевірте відповідні версії (V16 хороший на FreeBSD V9.x).

Враховуючи, що один раз прочитав багато тексту вашої системи, я використовував би топологію ZFS Z2 (уникайте RAID-5 та Z1 з накопичувачами такого розміру). З огляду на те, що ви використовуєте 4TB диски, час відновлення (resilver) для великого одиночного масиву vDev буде досить довгим, якщо пул заповнений. Щоб уникнути тривалого часу перебудови, організуйте vDevs в групи по 6 або 10 для створення пулу (рекомендації з документації FreeNAS). Пул, що складається з трьох 6-ти дискних vDevs (припускаються 4 ТБ дисковода), матиме корисну ємність ~ 48 ТБ і пропонує хороший рівень відмовостійкості (пам’ятайте, що вам все одно потрібно створити резервну копію даних, оскільки RAID не замінює резервні копії :)).

Для прискорення роботи з файлами, які часто отримують доступ, ви можете підключити пару SSD для L2ARC (швидше за все, не потрібно для вашої програми, але вони досить дешеві для 120 Гб SSD).

І як зазначено, використовуйте багато оперативної пам'яті. 64 Гб не надто дорого, враховуючи інше обладнання в системі. На жаль, менший XEON не може використовувати більше 32 ГБ. Ви можете спробувати, але більше оперативної пам’яті буде краще, згідно з літературою ZFS (я використовую згадуваний вами XEON з 32 ГБ оперативної пам’яті та масивом Z2 ємністю 24 ТБ, і він працює чудово).

Ще одна перевага ZFS полягає в тому, що ви можете встановлювати періодичні знімки. Таким чином, ви можете легко відновити попередні версії, а знімки дуже економічні. Крім того, ви можете копіювати будь-який знімок на інший набір даних (локальний або віддалений), і це можна зробити через SSH для безпеки.

Мені дуже подобається надійність системи ZFS. Мені також подобається те, що це апаратна НЕЗАЛЕЖНА !! Будь-яка система, яка може бачити диски, може імпортувати пул. Ніяких залежностей від вбудованого програмного забезпечення тощо, що може статися з апаратними рейдами (не проблема з кращими картами, але вони дорожчі, ніж картки HBA, і потрібні драйвери тощо - це було трохи раніше).

Враховуючи, що ця посада старша, ви, ймовірно, маєте рішення. Якщо так, розум розповісти, що ви побудували?

Ура,

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.