Журналювання в ОС FreeBSD

Задача моніторингу

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

В результаті, головним завданням ІТ-керівництва компанії стає мінімізація ризиків з підтримки працездатності існуючих рішень.

Завдання, для вирішення яких створено систему моніторингу та управління СУБД, операційними системами та додатками:

- збір та аналіз даних про стан сервісів та додатків;

- аналіз продуктивності критично важливих систем;

- контроль доступності критично важливих систем;

- виявлення збоїв в роботі;

- управління сервісами та додатками;

- надання звітності про стан об’єктів, що контролюються.

Основні властивості та функції системи моніторингу та управління СУБД, операційними системами та додатками:

- велика кількість платформ та додатків, що підтримуються;

- великий перелік параметрів, за якими відбувається контроль;

- великий перелік правил та політик управління операційними системами, сервісами та додатками, що підтримуються;

- механізм кореляції подій, який дозволяє полегшити контроль за станом сервісів та додатків;

- інтелектуальний аналіз стану об’єктів, що контролюються;

- наявність засобів сповіщення, що настроюються;

- можливість побудови звітів;

- можливість моніторингу віддалених систем, що знаходяться за міжмережевим екраном;

- маштабуємість системи;

- можливість побудови ієрархічної системи управління;

- наявність механізмів автоматичної передачі обов’язків при відмові одного з серверів системи;

- можливість інтеграції з іншими рішеннями.

Журналювання, що надається системою GEOM в FreeBSD 7.X, не є особливістю файлової системи (на відміну від, наприклад, файлової системи ext3 в Linux ®), воно функціонує на блочному рівні. А це означає, що воно може бути застосоване до різних типів файлових систем, однак для FreeBSD 7.0-RELEASE журналювання може бути застосоване лише для UFS2.

Можливість журналювання забезпечується завантаженням модуля geom_journal.ko в ядро (або створенням власного ядра з активуванням відповідних опцій) і використанням команди gjournal для конфігурування файлової системи. Загалом, ви віддасте перевагу журналювати файлові системи великого розміру, наприклад - /usr. Однак, вам доведеться зарезервувати деяку кількість вільного місця.

Коли файлова система журналюється, деяка частина дискового простору потрібно для зберігання самого журналу. Дисковий простір, що містить дані, називається постачальником даних (data provider), а частина простору, яка містить журнал, називається постачальником журналу (journal provider). Постачальники даних і журналу повинні бути на різних розділах, якщо журнал роботи добудовується до містить дані розділу. А якщо журналювання включається для нового розділу, у вас є можливість використовувати один постачальник для даних і журналу. У будь-якому з двох вищезазначених випадків команда gjournal задіє постачальники та створить кінцеву журнальовану файлову систему. Наприклад:

- Ви маєте намір журналювати файлову систему /usr, розміщену на /dev/ad0s1f, файлова система вже містить дані.

- Ви зарезервували частину дискового простору на розділі /dev/ad0s1g.

- Використовуючи команду gjournal, створюємо новий файл пристрою /dev/ad0s1f.journal, для якого /dev/ad0s1f є постачальником даних, а /dev/ad0s1g - постачальник журналу. Це новий пристрій необхідно використовувати у всіх подальших операціях.

Розмір дискового простору, відведеного під постачальник журналу, залежить від завантаженості файлової системи, а не від розміру самого постачальника даних. Наприклад, для типового настільного комп'ютера досить відвести 1 Гб під постачальник журналу для файлової системи /usr, в той час як комп'ютер, що має інтенсивну дискову активність (наприклад, редагування відео) може знадобитися більше. Якщо вільне місце на постачальнику журналу закінчується раніше, ніж відбувається скидання журналу на диск, - ви отримаєте паніку ядра.

Дуже малоймовірно те, що розміри журналу, запропоновані за замовченням, стануть причиною проблем зі звичайним настільним комп'ютером (на якому ви переглядаєте веб-сторінки, обробляєте текст або програєте мультимедійні файли). Якщо робота вашого комп'ютера на увазі інтенсивну дискову активність, то для забезпечення стабільності слід дотримуватися наступного правила: розмір ОЗУ повинен уміститися в 30% розміру, відведеного під журнал. Наприклад, якщо у вашому комп'ютері встановлений 1 Гб ОЗУ, створіть під постачальник журналу розділ розміром близько 3.3 Гб. (Помножте розмір ОЗУ в 3.3 рази, щоб отримати розмір журналу).

В новій системі ZFS журналювання втрачає свій смисл, адже нова файлова система слідкує за цілісністю кожного файлу.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Кешуючий проксі-сервер Squid	\|	Алгоритми симетричного і асиметричного шифрування

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.003 сек.