Storage Box проти Object Storage проти HA-NAS: яку архітектуру вибрати?
Ящик для зберігання, зберігання об’єктів і HA-NAS вирішують різні проблеми доступу. Storage Box – це простий віддалений ціль для файлів і резервних копій. Зберігання об’єктів відкриває об’єкти через API і масштабується за простором імен, а не за підключеною файловою системою. HA-NAS надає спільний доступ до файлів для серверів, яким потрібна знайома семантика файлів і висока доступність.
Порівняння допомагає командам вибрати сховище для резервних копій на сервері, сховище для розміщення файлів, медіарівні, архіви та спільні дані додатків, не примушуючи кожне робоче навантаження до однієї моделі продукту.
Використовуйте ящик для зберігання та зберігання об’єктів як робочий процес планування: визначте робоче навантаження, зберіть нормальний і піковий базовий рівень, визначте перший обмежений ресурс, виберіть два життєздатні проекти та перевірте їх за допомогою даних, схожих на виробництво. Тримайте припущення видимими, щоб майбутній перегляд міг оновити модель без повторних відкриттів.
Комерційні варіанти, на які посилається цей посібник: storage box (https://unihost.com/storage-box/); HA-NAS (https://unihost.com/nas/); розміщення файлів (https://unihost.com/dedicated/hosting-for-files/)
Пов’язані статті Unihost: Сховище Unihost як альтернатива AWS S3 (https://unihost.com/blog/unihost-object-storage-an-alternative-to-aws-s3/); контрольний список налаштування резервної копії (https://unihost.com/blog/backups-setup-checklist/); RAID посібник з вибору (https://unihost.com/blog/raid-made-simple-choose-level/)
Ящик для зберігання, зберігання предметів і HA-NAS у практичному плані
Storage Box поводиться як віддалений обсяг файлів, досягнутий через підтримувані протоколи передачі. Об’єктне сховище організовує дані як об’єкти у сегментах, доступ до якого зазвичай здійснюється через S3-сумісне API. HA-NAS сховище надає спільні файли одному або декільком серверам через такі протоколи, як NFS або SMB/CIFS, тоді як платформа зберігання керує доступністю за кінцевою точкою.
Збирайте кількість об’єктів, середній розмір об’єкта, операції з каталогом, поєднання читання/запису, паралелізм, затримку, пропускну здатність і сумісність клієнта під час звичайного трафіку та під час типового піку. Порівняйте мітки часу інфраструктури з трасуванням програми, щоб команда могла підключити повільний запит або невдале завдання до ресурсу, який був обмежений. Середні значення корисні для планування витрат, але p95, p99 і зростання черги показують, чи короткі спалахи вже шкодять службі.
Почніть із того, як програми читають і записують дані, а потім виберіть службу, протокол і модель узгодженості якої підходять без крихкого рівня перекладу. Основний ризик планування полягає у виборі за ціною за терабайт, ігноруючи семантику програми, завантаження метаданих або вимоги до відновлення. Перевірте вибір за допомогою тесту на сумісність клієнта з розмірами робочих файлів, дозволами та паралелізмом. Зберігайте умови тестування та поріг прийнятності в Runbook, щоб пізніші зміни можна було перевірити за тією ж базовою лінією.
Корисне рішення має масштабний шлях. Вкажіть, що можна розширити на місці, що вимагає перезапуску або міграції та який поріг починає цю роботу. Час виконання закупівель, тривалість копіювання даних і вікна змін належать до планування потужності, оскільки ресурс, який можна додати наступного місяця, може не допомогти під час піку наступного тижня.
Порівняльна таблиця ящика для зберігання та зберігання об’єктів проти HA-NAS.
Категорії нижче – це архітектурні тенденції. Конкретна реалізація може додавати керування версіями, знімки, приватну мережу або реплікацію, тому підтвердьте обсяг продукту. Підгонка протоколу зазвичай звужує вибір швидше, ніж необроблена ємність: застарілі файлові програми очікують файлової системи, тоді як рідні хмарні служби часто інтегруються безпосередньо з об’єктними API.
Побудуйте базову лінію на основі підтримуваного протоколу, поведінки простору імен, розподілу затримок, обмежень масштабу, резервування, контролю доступу та моделі стягнення плати. Записуйте однакові сигнали до та після кожного налаштування чи зміни інфраструктури. Якщо пропускна здатність зростає, а хвостова затримка та помилки залишаються під контролем, зміна створила корисну ємність. Якщо черги зростають або затримка зростає, система досягла ліміту, навіть якщо один заголовок показника використання все ще виглядає комфортним.
Усуньте будь-який варіант, який вимагає, щоб програма поводилася проти своєї рідної моделі даних, а потім порівняйте надійність і вартість у межах решти варіантів. Слідкуйте за припущенням, що NAS і об’єктне сховище є лише порівнянням продуктивності. Перед замовленням або міграцією скористайтеся підтвердженням концепції, яке охоплює операції створення, переліку, перейменування, перезапису, видалення, збереження та відновлення. Задокументований критерій відхилення так само важливий, як і критерій успіху, оскільки він говорить команді, коли зупинити розгортання або перейти до наступного рівня потужності.
Вартість має бути пов’язана з одиницею успішної роботи, такою як замовлення, запит, виконане завдання, відновлений терабайт або прийнята відповідь моделі. Таке подання запобігає виграшу дешевої конфігурації, якщо вона не досягає цільової затримки або відновлення, і запобігає розгляду невикористаного резерву як безкоштовного.
Порівняння архітектури зберігання
| Розмір | Ящик для зберігання | Об’єкт зберігання | HA-NAS |
|---|---|---|---|
| Первинний доступ | Протоколи віддаленої передачі файлів | HTTP API, часто S3-сумісний | Навісна NFS або SMB/CIFS лапа |
| Простір імен | Файли та каталоги | Відра, ключі та метадані об’єктів | Спільна файлова система |
| Модель масштабування | Ємність ярус або ящик | Великий простір імен об’єктів і масштаб обслуговування | Ємність пристрою або кластера |
| Профіль затримки | Добре підходить для робочих процесів передачі та резервного копіювання | API затримка, велика для паралельного доступу до об’єктів | Доступ до файлів із перевагою локальної мережі, де це можливо |
| Надмірність | Специфічний продукт | Реплікація на рівні обслуговування або кодування стирання | Дизайн сховища високої доступності |
| Найкраще підходить | Резервне копіювання, архіви та обмін файлами | Хмарні дані, медіа, журнали та S3 альтернатива | Спільні файли та багатосерверні програми |
| Модель витрат | Потужність і план обслуговування | Ємність, операції та передача можуть бути роздільними | Надана потужність і рівень обслуговування |
Порівняйте Storage Box (https://unihost.com/storage-box/), шаблони зберігання об’єктів і HA-NAS (https://unihost.com/nas/).
Найкращий варіант для резервних копій, медіа, архівів, баз даних і спільних файлів
Для резервних копій потрібна незмінність або збереження версії, незалежні облікові дані та передбачуване відновлення. Носії та архіви цінують місткість, паралельне читання та політику життєвого циклу. Для спільних файлів потрібні дозволи та семантика файлової системи. Більшість транзакційних баз даних повинні зберігати активні дані в локальному або виділеному сховищі з низькою затримкою та використовувати віддалене сховище для резервного копіювання, експорту або певних спільних ролей. Резервний сервер зберігання надає пріоритет пропускній здатності та ізоляції відновлення, тоді як хостинг медіа-сховищ надає пріоритет шаблонам доставки та політиці життєвого циклу. Сховище бази даних потребує постійної затримки, чіткого контролю довговічності та шляху резервного копіювання з урахуванням додатків.
Використовуйте час відновлення, збереження, розмір об’єкта, частоту доступу, швидкість метаданих, базу даних IOPS і поведінку блокування файлів як модель невеликої ємності, а не знімок інформаційної панелі. Розділіть постійний попит, планову роботу та виняткові піки. Модель повинна пояснювати, який ресурс насичується першим, як довго триває насиченість і який клієнт або операційний результат змінюється в цей момент.
Використовуйте Storage Box для прямих віддалених копій, сховища об’єктів для API-власного масштабу та розподілу, а також HA-NAS, коли кільком серверам потрібна спільна файлова система. Дизайн все ще може дати збій через розміщення чутливих до затримки файлів бази даних у віддаленому сховищі без підтримки постачальника та тестування робочого навантаження. Доведіть заплановану поведінку за допомогою тимчасового відновлення, тесту доставки медіа або тесту узгодженості додатків відповідно до вибраного випадку використання. Включіть у тест моніторинг, резервне копіювання та контроль безпеки, оскільки виробничі витрати не повинні з’являтися вперше після запуску.
Виберіть Storage Box, HA-NAS або хостинг файлів
Доступність, шифрування та відновлення
Доступність – це більше, ніж резервні диски. Перевірте резервування контролера та мережі, поведінку технічного обслуговування, логіку повторних спроб клієнта, знімки чи версії, шифрування даних у стані спокою та під час передавання, ізоляцію облікових даних і процес відновлення видалених або пошкоджених даних. Реплікація може скопіювати помилку, тому зберігайте незалежну точку відновлення.
Вимірюйте доступність служби, частоту повторних спроб, час знімка, точку відновлення, час відновлення, ротацію ключів і події невдалого доступу з достатньою роздільною здатністю для захоплення пакетів і достатньою тривалістю для виявлення витоків, ефектів кешу та фонових завдань. Тримайте поєднання робочого навантаження видимим. Тест, в якому переважають легкі запити, може повідомити про хороші середні значення, тоді як дорогий шлях уже стоїть у черзі.
Зіставте кожен клас даних із RPO, RTO, політикою зберігання та доступу перед вибором рівня продукту. Не ігноруйте використання RAID або синхронізованих реплік як резервну копію. Підтвердьте рекомендацію за допомогою тренування відновлення, яке видаляє, пошкоджує та відновлює репрезентативні дані з задокументованим часом. Запишіть, яке припущення має найнижчу достовірність, і спочатку повторно перевірте це припущення, коли зміниться трафік, дані або програмне забезпечення.
Три еталонні архітектури зберігання
Дизайн резервного копіювання надсилає зашифровані серверні копії в Storage Box і зберігає окрему копію, контрольовану політикою, якщо потрібно. Дизайн медіа зберігає метадані програми в базі даних, поки об’єкти живуть у сховищі об’єктів і доставляються через кеш або CDN. Багатосерверна програма може монтувати HA-NAS через приватну мережу для спільних файлів, зберігаючи незалежні резервні копії.
Створіть повторюваний набір доказів із потоку даних, кордону довіри, пропускної здатності, одночасних клієнтів, віку резервної копії та шляху відновлення. Зберігайте дані про робоче навантаження поруч із результатами, включаючи версію програмного забезпечення, розмір даних, стан кешу та паралельність. Це перетворює наступний огляд потужності на порівняння замість іншої оцінки з пам’яті.
Зберігайте гарячий шлях простим і розміщуйте потоки резервного копіювання або архівування за межами того самого домену збою. Найдорожчою помилкою буде маршрутизація кожного типу даних через одну спільну кінцеву точку та перетворення сховища на універсальне вузьке місце. Зменште цю невизначеність за допомогою перегляду діаграми з подальшим тестуванням на передачу піків і випробувань на відмову компонентів. Зберігайте шлях оновлення або відкоту, який не залежить від уже обмеженого компонента.
Еталонні архітектури
| Візерунок | Шлях даних | Основна користь | Необхідний контроль |
|---|---|---|---|
| Резервне копіювання сервера | Сервер -> зашифрована передача -> Скринька для зберігання -> додаткова друга копія | Просте цільове відновлення за межами підприємства | Тест збереження, ізоляції облікових даних і відновлення |
| Медіаплатформа | Додаток -> об’єкт API -> сховище об’єктів -> CDN або клієнти | Паралельна доставка та життєвий цикл | Резервне копіювання метаданих і політика доступу |
| Спільні файли програми | Сервери програм -> приватна мережа -> HA-NAS | Загальна файлова система для кількох вузлів | Підвищення стійкості та незалежного резервного копіювання |
Перелік рішень щодо зберігання та наступний крок
Протокол доступу до документів, розміри об’єктів і файлів, паралельність, необхідне розташування, приватне підключення, дозволи, шифрування, зростання, збереження, RPO/RTO, метод відновлення та щомісячна передача. Запитайте, як служба поводиться під час обслуговування, розширення ємності та випадкового видалення. Залиште другий варіант, якщо програма підтримує більше однієї моделі даних.
Відстежуйте всі вхідні дані контрольного списку, а також тестовий набір даних і порогові значення на рівні компонентів і послуг. Запас ресурсів цінний лише тоді, коли він зберігає цілі затримки, коректності та відновлення, які важливі для бізнесу. Використовуйте перший постійно обмежений показник, щоб керувати наступним тестом.
Надсилайте запит на рекомендацію щодо архітектури лише після того, як вимоги до програми та відновлення будуть явними. Поширений режим невдачі – це замовлення зберігання до того, як команда погодиться, які дані є авторитетними та як їх буде відновлено. Використовуйте підписаний приймальний тест на продуктивність, контроль доступу та відновлення, перш ніж розглядати конфігурацію як готову до виробництва. Перевірте результат разом із власником програми та командою інфраструктури.
Попросіть рекомендації щодо архітектури зберігання
Поширені й відповіді
NAS краще, ніж об’єктне сховище?
Ні те, ні інше не є універсальним кращим. NAS підходить для програм, яким потрібна підключена спільна файлова система, звичні дозволи та операції з файлами. Зберігання об’єктів підходить для API-власних програм, великих просторів імен і паралельного доступу до об’єктів. Виберіть за семантикою доступу та дизайном відновлення.
Яке сховище найкраще для резервного копіювання?
Використовуйте сховище, яке не залежить від джерела, підтримує необхідне збереження та може бути відновлене в межах RTO. Storage Box може бути прямим віддаленим об’єктом, тоді як сховище об’єктів може додавати контроль версій або життєвого циклу. Перевірте швидкість відновлення та ізоляцію облікових даних.
Чи можна використовувати Storage Box для медіафайлів?
Так, якщо підтримуваний шаблон передачі та доступу відповідає робочому процесу. Для великої публічної доставки сховище об’єктів плюс CDN може масштабуватися більш природним чином. Вимірюйте паралелізм, пропускну здатність і те, як програма відображає URL-адреси або дозволи для збережених файлів.
Яке сховище підходить для баз даних?
Для активних транзакційних баз даних зазвичай потрібна локальна NVMe або спеціальна спільна платформа, протестована для бази даних. HA-NAS може підійти для підтримуваних випадків спільного використання файлів, тоді як Storage Box або об’єктне сховище краще використовувати для резервного копіювання та експорту. Перевірте послідовність і затримку перед виробництвом.
