Відмінності між версіями «Тема 3. Дискове планування.»

Версія за 02:55, 9 січня 2012

Сучасний Linux- сервер: як планувати дискові ресурси

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

Постановка завдання

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

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

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

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

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

Ієрархія рівнів представлення дискових даних

Сучасний Linux- сервер є багатофункціональним пристроєм, працюючим в мережі. Якщо абстрагуватися від його прикладного призначення і спробувати представити увесь спектр можливих рівнів і способів доступу до даних, то вийде велика схема, що нагадує багатошаровий пиріг. Ієрархію мережевого доступу до даних теж прийнято зображувати у вигляді багаторівневої схеми інкапсуляції. Тільки якщо мережева модель вже давно канонізована, то схема вкладеності рівнів доступу до дискових даних не має звичного вигляду, що допускає вільності в її уявленні. Отже, якщо усі доступні в SuSE Linux 10.0 технологій спробувати укласти в єдину схему, взаємозв'язок, що відбиває їх, і взаємодію, то вийде щось на зразок зображеного на мал. 1.

Малюнок 1. Схема ієрархії рівнів представлення дискових даних

Прокоментую цю схему. Хоча усі абревіатури і позначення є традиційними в Linux, розшифрую їх:

n DISK - фізичний дисковий пристрій;

n MD - так званий multiple device або програмний RAID;

n LVM - віртуальний диск за технологією Logical Volume Manager;

n DRB/iSCSI - мережевий диск за відповідною технологією;

n EXT3... - рівень представлення, що відповідає файловим системам;

n NFS... - рівень представлення, що відповідає мережевим файловим системам і протоколам, використовуваним для організації мережевого доступу до файлів.

Кожен забарвлений прямокутник відділяє регіон, що включає технології відповідної категорії. Їх три:

n SAS - пристрої, що фізично підключаються до сервера;

n SAN - блокові пристрої, що підключаються по мережевих інтерфейсах;

n NAS - файлові системи, доступні через мережу.

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

Далі виходитимемо з припущення, що усі використовувані технології застосовуються до одного фізичного дискового пристрою. Це не виключає надалі використання додаткових дисків, але задає жорсткіші рамки варіантів вибору. Наприклад, під MD надалі розумітиметься виключно RAID1.

Діаграми переходів

Для того, щоб визначити ключові, або, в нашій термінології, " дорогі" технологічні елементи, побудуємо діаграму переходів в процесі можливих налаштувань від самого нижнього рівня DISK до самого верхнього NFS... Отримана діаграма представлена на мал. 2.

Малюнок 2. Діаграма налаштувань

Вузли відповідають технологічним рівням представлення даних, а стрілки означають можливі напрями в процесі налаштування сервера. Нумерація вузлів проставлена в порядку щонайдовшого маршруту налаштувань. Все очевидно і не потребує пояснень. А ось тепер повернемо стрілки у зворотному напрямі! Уявимо, що деякий крок налаштування виявився помилковим, але рішення про його відміну прийшло лише в процесі експлуатації, через деякий час. Наприклад, в процесі установки були послідовно пройдені етапи 1 DISK, 5 EXT3..., 6 NFS.... І через деякий час з'явилася необхідність перевести працюючу систему під LVM. Тобто потрібно послідовно перевести сервер по діаграмі налаштувань 6 NFS..., 5 EXT3... і потім у вузол 3 LVM. Після чого знову в поступальній ході по діаграмі налаштувань повернутися у вузол 6 NFS..., який відповідає повністю працездатному серверу. Другу діаграму назвемо діаграмою переробок. У ній все вектору змінили напрям на протилежне, і поряд з кожним з них додався коментар, що оцінює вартість переробки. Результат зображений на рис 3.

Малюнок 3. Діаграма переробок

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

Таким чином, найсерйозніша ситуація складається навколо переробок, що вимагають установки LVM. Якщо підключення RAID або переразметка диска можуть бути проведені без резервного копіювання усіх даних в деяких випадках, то приміщення томів з даними під управління LVM зажадає 100% збереження усієї задіяної інформації. Тут можна зробити висновок, що саме LVM є тією критичною технологією, рішення про використання якої потрібно приймати на самому ранньому етапі планування дискових ресурсів.

Таблиця операцій

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

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

Таблиця 1. Операції і вартості

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

Далі, у нас два кандидати для можливого збільшення відмовостійкості шляхом гарячого резервування. Безумовно, порівнювати RAID і мережеві блокові пристрої просто некоректно. Але у рамках даної моделі ми не враховуємо нічого, окрім можливості перенастроювати потрібний рівень представлення даних і наслідків такого перенастроювання. І наслідуючи цей принцип, виходить, що створення мережевого блокового пристрою на основі локального - це лише запуск відповідного сервісу, а перемикання локально підмонтованого диска на мережевий режим роботи без зміни його об'єму або розміщення теж не представляє особливої проблеми. Отже, з двох технологічних підходів, MD і DRB/iSCSI, будемо самими незручними в модифікації, і тому " найдорожчим", рахувати MD.

На цьому етапі можна сформулювати перші принципи планування дискових ресурсів.

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

Принцип 2. Слідує, по можливості, об'єднати усі створені фізичні томи під управлінням LVM - для того, щоб надалі, при необхідності, легко маніпулювати об'ємом використовуваних логічних томів.

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

оригінальне джерело і продовження статті [тут | http://www.opennet.ru/docs/RUS/disk_plan/]