Пiд пресом петабайта

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

Далі - більше. Роздмухування первинних сховищ відбивається на системах резервного копіювання. За бэкап суміші важливих даних і неактивних даних відповідають одні та ті ж політики. Повне резервне копіювання просаджує продуктивність клієнтських серверів, мереж і сховищ. У результаті, турбота про пасиви витрачає місце, вимагає усе більш потужних серверів і швидких мереж - множить витрати.

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

Метадані, блендери, налаштування помелу

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

Пом'якшує завдання використання інтегрованого пошуку за допомогою розширених метаданих, "даних про дані". Метадані містять відомості про супутні ознаки та властивості, дозволяючи автоматично шукати і управляти вибірками даних в інформаційних потоках. Робочі навантаження мають справу з файлами, кожен з яких генерує метадані. І добре генерують. За даними постачальників файлових систем, на метадані доводиться до 80% усіх операцій введення-виведення. Звичні системи зберігання упираються в стелю можливостей не тому, що нікуди підключати полиці розширення, а тому що не забезпечують продуктивність і керованість під змішаними навантаженнями.

Навіть системи зберігання, які працюють з послідовним навантаженням (відеоспостереження, відеовиробництво), отримують певний відсоток запитів випадкового доступу : при вичитуванні даних на тлі потокового запису або обслуговуванні конкурентних запитів. Перемелювання послідовних запитів у випадкові називають I/O- блендером (а у віртуалізованому середовищі - могильником систем зберігання). Запис метаданих. покажчиків файлових систем і блоків службової інформації добиває найстійкіші СЗД. Виживають ті, налаштування яких відповідають патернам даних. Робота настроювача розпочинається з аналізу природи даних, і тільки потім підбору/підгонки СЗД. Універсальних систем зберігання не буває, навіть якщо усі вони "масштабу петабайта".

SSD- кешування

Дані рідкісного звернення - "холодні". Таких в архівах більшість. Чим частіше до даних звертаються, тим вони "тепліші". У системах зберігання використовують SSD- кешування - як буфер між ініціаторами і основним масивом. "Популярні" блоки переміщаються на SSD і читатимуться з меншою затримкою. Отримавши ж запит на запис, система розміщує блоки даних на інших SSD. Завдяки швидким носіям, сповіщення ініціаторів про успішну транзакцію відбувається з мінімальними затримками. У міру заповнення кеша система поступово переносить дані в основне сховище.

Об'єм SSD- кеша обмежений, в кожній системі зберігання існують свої алгоритми, які блоки даних витісняти і за яким принципом робити заміщення. Наприклад, в кеш читання зазвичай копіюються блоки даних повторного звернення. А в кеш запису потрапляють усі випадкові запити на запис, у яких розмір блоку менше встановлюваного параметра, скажімо, 32kb. Звідси зрозуміло, навіщо під кеш запису програмно-визначуваних систем потрібні SSD з великим ресурсом і швидким відгуком.

Детальніше про алгоритми витіснення і принципи обміну даними з основним сховищем можна прочитати тут. SSD- кешування доповнює HDD- масиви: механічні диски успішно справляються з послідовними навантаженнями, але пасують перед випадковим доступом - і тоді їх переймають на себе SSD, де дозволяє логіка сховища, що управляє. Об'єм SDD- кеша при цьому складає близько 5-10% від місткості основної дискової підсистеми.

Системи, які використовують SSD- кеш разом з HDD- дисками, - гібридні. Якби не йшлося про сотні терабайт даних, вистачало б сховищ all - flash. А так доводиться ставити СЗД на суміші носіїв під широкий спектр завдань і навантажень. Ціна має значення.

Ущільнення даних

Понизити накладні витрати на зберігання інформації допомагає стискування масиву даних (компресія) з усуненням надмірних копій (дедуплікація). Але не всім і не завжди. "Міфологія дедуплікації" твердо говорить тільки про одне: та, що просіла продуктивності на масиві гарантована, а полегшення - ні. Великі обчислювальні ресурси відволікаються незалежно від методу і рівня деталізації (файли - блоки - байти). Навіть якщо ваша система зберігання з дедуплікацією може зберігати десять копій в місці, достатньому для зберігання однієї копії, ви все одно заплатите, тим або іншим способом.

Файли, блоки, об'єкти

Звичне файлове зберігання побудоване на ієрархічних каталогах: дані зберігаються у файлах, ті - в теках, для доступу до даних потрібний точний шлях. Блокові сховища звертаються до даних по табличних адресах блоків. Об'єктні сховища зв'язують дані з причетними метаданими в об'єкти, розміщують їх "десь" і звертаються до них по унікальному покажчику. Сильна сторона об'єктного зберігання - хороша масштабованість за об'ємом.

Управління адресацією даних (і метаданими) визначає застосовність системи зберігання більшою мірою, чим її обчислювальна потужність або фізичні носії. Помилки вибору СЗД приводить до множення проблем з масштабуванням місткості.

Може, піти в хмару?

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

Ціна виходу

 Вартість виведення даних - ключовий параметр для схвалення або ветування перенесення зберігання в хмару. Перш ніж туди переходити, перевірте тарифи хмарних провайдерів на данні які виходять. Розміщення даних і додатків в хмарі (вхід) коштує недорого. Зате ціна виведення, переміщення даних, в іншу область (вихід) може неприємно здивувати. Від постачальника до постачальника ціни міняються не сильно. Ось тарифи основних операторів:

В очікуванні петабайта

Петабайт помірно активних даних зберігають на механічних дисках. Під трафік метаданих і кешування змістовних запитів використовують SSD. На цьому закінчується загальне містких систем зберігання. Далі їх дороги розходяться - згідно з обставинами і патернами обслуговуваних даних. Первинний не вибір СЗД, а аналіз додатків. У програмно-визначуваному світі зберігання будь-яка функціональність - як ущільнення даних або їх погоджене переміщення між рівнями зберігання (наприклад, даних що остигають в об'єктні сховища) - не є козирем або обов'язковою вимогою. Є виклики бізнес-логіки, є програмні моделі роботи з даними, є ціна рішення.

Якщо немає уявлення про трафік даних, не допоможе ніякий Ceph.