Завдання системи зберігання даних

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

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

Відмово стійкість доступу серверів до даних досягається дублюванням шляхів доступу. Стосовно до SAN дублювання полягає в наступному: мережа SAN будується як дві фізично незалежні мережі, ідентичні по функціональності і конфігурації. У кожний з серверів, включених до SAN, встановлюється як мінімум по два FCHBA. Перший з FCHBA підключається до однієї «половинці «SAN, а другий — до іншої. Відмова обладнання, зміна конфігурації або регламентні роботи на одній з частин SAN не впливають на роботу іншої. У дисковому масиві відмовостійкість доступу до даних забезпечується дублюванням RAIDконтролерів, блоків живлення, інтерфейсів до дисків і до серверів. Для захисту від втрати даних Віддзеркалюються ділянки кешпам’яті, що беруть участь в операції запису, а електроживлення кешпам’яті.

резервують батареями. Шляхи доступу серверів до дискового масиву теж дублюються. Зовнішні інтерфейси дискового масиву, включеного в SAN, підключаються до обох її «половинкам ». Для перемикання з вийшов з ладу шляхи доступу на резервний, а також для рівномірного розподілу навантаження між усіма шляхами, на серверах встановлюється спеціальне програмне забезпечення, що постачається або виробником масиву (EMC CLARiiON — PowerPath, HP EVA — AutoPath, HDS — HDLM), або третім виробником (VERITAS VolumeManager) .

Необхідну продуктивність доступу серверів до даних можна забезпечити створенням виділеної високошвидкісний транспортної інфраструктури між серверами і пристроями зберігання даних (дисковим масивом і стрічковими бібліотеками). Для створення такої інфраструктури в даний час найкращим рішенням є SAN. Використання сучасних дискових масивів з достатнім об'ємом кешпам’яті і продуктивної, яка не має «вузьких місць» внутрішньою архітектурою обміну інформацією між контролерами і дисками, дозволяє здійснювати швидкий доступ до даних. Оптимальне розміщення даних (.

disklayout (1)) по дисках різної ємності та продуктивності, з потрібним рівнем RAID залежно від класів додатків (СУБД, файлові сервіси і т.д.), є ще одним способом збільшення швидкості доступу до даних.

(1) Disklayout — це схема розподілу даних програми по дисках. Вона враховує в які рівні RAID організовані диски, число і розміри розділів на дисках, які файлові системи використовуються і для зберігання яких типів даних вони призначені.

Необхідно зауважити, що оптимізація налаштувань програмних засобів, як самих додатків, так і операційної системи, дає істотно більший приріст продуктивності системи, ніж використання більш потужної апаратури. Обумовлено це в першу чергу тим, що оптимізація налаштувань усуває «вузькі місця «(bottleneck) на шляхах проходження потоків даних, тоді як нова апаратура робить «горлечко пляшки «трохи ширше і тільки (хоча іноді й цього достатньо для вирішення проблем швидкодії). У рішенні задачі оптимізації може допомогти застосування спеціального ПО, в якому реалізовані функції, що враховують особливості взаємодії апаратури, операційної системи і прикладного ПЗ. Прикладом такого ПО служить опція Quick I / O файлової системи VxFS. Опція Quick I / O ліцензується у складі пакету VERITAS DataBaseEdition (DBE) for ORACLE. Зазначена опція дозволяє СУБД ORACLE використовувати KernelAsynchronous IO (KAIO) для доступу до файлів даних, що істотно підвищує продуктивність операцій введення-виведення СУБД. Детальніше про це можна прочитати в .Крім досягнення необхідних показників продуктивності, відмовостійкості та надійності зберігання даних в СГД, замовники також прагнуть скоротити сукупну вартість володіння системою (Totalcostofownership — TCO). Впровадження системи управління дозволяє скоротити витрати на Адміністрування СГД та спланувати витрати на її модернізацію. Консолідація технічних засобів також сприяє скороченню витрат на експлуатацію СГД.

Рисунок 8 Конфлікт цілей

Таблиця 2.

Одним з найбільш часто використовуваних методів забезпечення високої доступності СГД є дублювання, яке підвищує вартість системи. Якщо не враховувати бізнес-вимог замовника до доступності системи, то система стає невиправдано дорогою. Погоня за непотрібною продуктивністю також призведе до використання дорогих технічних засобів. Крім високих показників продуктивності, доступності та низької вартості потрібно також забезпечити необхідну функціональність — об'єм зберігання і число підключаються серверів. На жаль, замовники не завжди можуть описати вимоги по продуктивності в кількісних характеристиках, прийнятих для систем зберігання — пропускної здатності (Мбайт / с) або продуктивності (операцій введення-виведення в секунду — I / O persecond (IOPS)). Тому, щоб визначити якщо не кількісні характеристики, то хоча б характер навантаження, проектувальнику необхідно з’ясувати, роботу яких додатків повинна забезпечувати СГД.

Різні класи додатків створюють різне навантаження на дискову підсистему .

Від того, яке навантаження дає додаток, залежить вибір способу розподілу даних по дисках і визначення об'єму кешпам’яті дискового масиву. Так для OLTPзадач наявність кешпам’яті в дисковому масиві може зіграти істотну роль для підвищення продуктивності введення-виведення. Навпаки, в задачах класу DSS відбувається зчитування великих обсягів даних, що практично виключає їх повторне потрапляння в кешпам’ять (на відміну від OLTP — задач). Таким чином, кешування зчитувальних даних при обробці DSSзадач не завжди збільшує їх продуктивність.

Рисунок 9 Рівні RAID.

До типами навантаження на СГД, виробленими завданнями класу OLTP, DSS і файловими сервісами можна віднести інші відомі типи додатків. Так, поштовий сервіс, побудований на базі MS Exchange або LotusDomino, дає подібну навантаження на СГД, що і OLTP, оскільки зазначені продукти побудовані на базі СУБД. Поштовий же сервіс, заснований на sendmail, виробляє навантаження на СГД, характерну для файлової системи з частою зміною метаданих. Кошти резервного копіювання виконують послідовне читання даних, що підлягають резервному копіюванню, що робить характер їх операцій схожим з DSS-завданнями.

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

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

Визначити класи задач, які буде обслуговувати СГД, необхідно не тільки для вироблення політики роботи з кеш, але також для розподілу даних по дисках (disklayout). Для забезпечення надійного зберігання інформації диски організовуються в рівні RAID 1, 0 +1 / 1 +0 або 5. Найекономічнішим з точки зору використання додаткового (дублюючого) дискового простору є рівень RAID 5. Однак продуктивність RAID 5 нижче, ніж у RAID 1 або 0 +1 при частих випадкових змінах даних, характерних для OLTPзадач, і висока при зчитуванні даних, що характерно для DSSзадач .

Також різні рівні RAID забезпечують різні рівні відмовостійкості дискової пам’яті до збоїв окремих дисків. Так RAID 5 не рятує від двох послідовних відмов дисків, втім, як і RAID 0 +1, якщо це диски різних половин «дзеркала». Найбільш ВІДМОВОСТІЙКО є рівень RAID 1 +0 (попарне «зеркалирование «дисків і потім їх «striping (1) »), тому його рекомендується застосовувати для зберігання критичних даних, наприклад, журналів транзакцій СУБД. Практика показує, що для зберігання файлових систем і даних DSSзадач достатньо використовувати RAID 5 .

Однак, якщо файлова система часто змінюється як, наприклад, у поштових системах sendmail, то має сенс використовувати журналірованную файлову систему або файлову систему з окремо збереженими метаданими, наприклад файлову систему Sun QFS. Тоді для зберігання журналів або окремих метаданих краще застосовувати RAID 1 або 1 +0 .

(1) Striping — метод розміщення даних на дисках, при якому послідовно йдуть блоки даних, що становлять логічний тому, записуються по черзі на кожен фізичний диск, що входить до дискову групу. Таким чином досягається велика продуктивність, оскільки операції читання і запису на диски можуть проводитися паралельно в порівнянні з варіантом, коли всі блоки логічного тому записується на один диск. Детальніше про striping та його вплив на продуктивність введеннявиведення можна прочитати в .

Детальніше про вплив кешпам’яті і disklayout на продуктивність введеннявиведення завдань класу OLTP і DSS можна прочитати в .

Для «великих» систем актуальною стає оптимізація налаштувань СГД, спрямована на підвищення швидкодії для досягнення заданого рівня сервісу. Під «великий» розуміється така система, в якій обробляється значний обсяг даних — одиниці і десятки терабайт, та / або до СГД підключені десятки серверів. Для невеликих систем проблеми з швидкодією можна вирішити застосуванням більш продуктивної апаратури. У «великих» системах такий підхід може виявитися неприйнятним або у зв’язку з тим, що буде потрібно дуже дорога апаратура, або у зв’язку з тим, що вже досягнута межа апаратної продуктивності. Єдиним рішенням у даному випадку є оптимізація. Для оптимізації продуктивності СГД бажано мати можливість керувати налаштуваннями на всьому шляху проходження даних від процесора до дисків і назад. Для СУБД ORACLE така оптимізація полягає в можливості використовувати KAIO, а також можливості відключити кеш файлової системи для файлів даних ORACLE (оскільки СУБД ORACLE кешируєт дані у власній області пам’яті SGA). Для цієї мети можна використовувати згаданий раніше пакет VERITAS DBE. Якщо в системі експлуатуються OLTP — і DSSзавдання (що є типовим для більшості систем), то для оптимізації продуктивності дискового масиву бажано мати можливість керувати налаштуваннями кешпам’яті для кожного логічного диска (LUN) окремо. Це необхідно для того, щоб для тих дисків, де розташовані дані OLTPзавдання, використовувати кеш (і бажано великого обсягу), а для дисків з даними DSSзавдання використання кешпам’яті відключити. Однак, якщо для OLTP — і DSSзадач використовуються одні й ті ж таблиці даних, то такі настройки втрачають сенс до тих пір, поки не буде вирішено питання про фізичне рознесенні даних завдань по різних дисках, а виконання самих завдань перенесено на різні сервери. Це можна реалізувати засобами СУБД, наприклад, за допомогою експорту даних у файл та імпорту їх в іншу базу. Якщо обсяг даних великий і синхронізацію баз даних OLTP — і DSSзадач треба проводити досить часто, цей варіант може виявитися неефективним. Тут може допомогти технологія створення PITкопій даних, реалізована в більшості сучасних дискових масивів .

Вище говорилося, що СГД є важливою ланкою в забезпеченні заданого рівня сервісів, що надаються інформаційною системою. Рівень сервісу залежить не тільки від продуктивності СГД, питання забезпечення якої щойно обговорювалися, але також від готовності та надійного зберігання даних, іншими словами, від доступності СГД. Виходячи з бізнес-вимог до інформаційної системи, необхідно визначити режими її роботи (24×7, 12×5 і т.п.), ступінь критичності даних в залежності від ступеня критичності сервісів, що використовують ці дані, вимоги до готовності та надійності даних в залежності від ступеня їх критичності і режимів роботи системи .

Для відмово стійкості доступу до даних в серверах АБС необхідно встановити як мінімум по 2 FCНВА і підключити їх до різних контролерам дискового масиву. При цьому компоненти дискового масиву повинні бути продубльовані, а ділянки кешпам’яті, що використовуються для операцій запису, задзеркальовані і захищені від збоїв харчування.

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

Тип додатки впливає на те, як здійснюватиметься резервне копіювання. Наприклад, для резервного копіювання СУБД ORACLE засобами RecoveryManager (RMAN) рекомендується використовувати окремий сервер (а, отже, і окремий екземпляр бази даних і дисковий простір для нього), де буде розміщений RMAN RecoveryCatalog. Для резервного копіювання файлових систем цього не потрібно. Щоб відновити базу даних ORACLE необхідно мати копії журналів транзакцій, для чого рекомендується активізувати в СУБД ORACLE режим архівації журналів транзакцій (ARCHIVELOG). Для архіву журналів транзакцій буде потрібно виділити дисковий простір. Для його захисту від руйнування рівня RAID 5 буде достатньо. Який тип резервного копіювання використовувати (повне або інкрементальне) залежить від того, за який час можна буде скопіювати базу даних і журнали транзакцій з стрічок на диски, і чи вкладається повне резервне копіювання у відведений тимчасове вікно. Використання повного щоденного резервного копіювання дозволяє відновити базу швидше, ніж, наприклад, застосування повної щотижневого і щоденного інкрементального. При розрахунку часу відновлення СУБД ORACLE рекомендується врахувати, що дані c стрічки копіюються на диски повільніше, ніж записуються з дисків на стрічки, оскільки треба записувати метадані файлової системи. Також треба врахувати, що після копіювання файлів даних і журналів транзакцій з стрічок на диски СУБД ORACLE повинна буде виконати процедуру відновлення бази — RECOVERY, тобто «накотити «все незавершені транзакції з журналів.

Реплікація може виконуватися програмним забезпеченням, встановленим на серверах (програмна реплікація), або вбудованим в дискові масиви програмним забезпеченням «прозоро» для серверів (апаратна реплікація). Для організації реплікації або зеркалирования необхідно створити високопродуктивну інфраструктуру передачі даних, об'єднуючу обидві площадки. Як правило, для цього застосовують SAN .

При розробці проекту СГД для збереження вкладених інвестицій необхідно врахувати наявні технічні засоби і найбільш оптимальним чином вписати їх у нову систему. Треба також врахувати наявність, навички та досвід обслуговуючого персоналу. Якщо кваліфікації персоналу недостатньо для обслуговування високотехнологічної системи, то крім організації навчання, ретельного опрацювання регламентів складання детальних інструкцій та іншої робочої документації, необхідно впровадити систему управління СГД. Система управління не тільки полегшить роботу, але ще і знизить імовірність помилкових дій персоналу, які можуть привести до втрати даних.

Не секрет, що наявність плану розвитку системи полегшує її впровадження і знижує витрати на модернізацію, в порівнянні з хаотичним розвитком. З іншого боку, бізнес піддається змінам — змінюються завдання, з’являються нові користувачі і т.п. Тому, навіть добре спроектована СГД з часом перестає задовольняти бізнесвимогам.Допомогти у вирішенні вказаних проблем може знову ж впровадження все тієї ж системи управління, яка дозволить відстежити зміну навантажень на систему зберігання, врахувати утилізацію дискового простору, спрогнозувати потреби в його нарощуванні і т.д.

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