Впровадження технічних засобів безпеки в мережі операторів

Размещено на http://www.allbest.ru/

Зміст

1. Назва операцій. Мета. Вимоги до системи резервного копіювання. Види резервного копіювання

2. Схеми ротації та її види

2.1 Зберігання резервної копії. Методи боротьби з втратою інформації

2.2 Безпека в мережах зберігання даних

2.3 Рівень даних

2.4 Рівень мережевої взаємодії

2.5 Рівень управління доступом

2.6 Методи побудови систем зберігання даних

3. Складові системи зберігання даних

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

4. Вибір дискового масиву

4.1 Можливість створення PIT - копії даних засобами масиву. Вимоги до продуктивності. Вимоги по відмово стійкості та надійності. Вимоги по масштабованості

4.2 Безпека в мережах зберігання даних

4.3 Рівень даних

4.4 Рівень мережевої взаємодії

4.5 Рівень управління доступом

4.6 Методи побудови систем зберігання даних

5. Оцінка загального об'єму архіву

5.1 Вибір коефіцієнта для оцінки об'єму внутрішніх накопичувачів

6. Системний аналіз вразливостей сервера резервного копіювання мережевої файлової системи

6. Системний аналіз вразливостей і підбір механізмів їх усунення

6.1 Типова сукупність програмних засобів для захисту сервера

резервного копіювання мережевої файлової

7. Втрата зв'язку з сервером БД і / або фізича відмова сервера

7.1 Позаштатна робота ПО і персоналу

7.3 Падіння під навантаженням

7.4 Розрахунок середнього часу напрацювання до руйнування

8. Оцінка загального об'єму архіву

8.1 Вибір коефіцієнта для оцінки об'єму внутрішніх накопичувачів

Висновки та рекомендації

Перелік посилань



Размещено на http://www.allbest.ru/

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



1. Назва операцій. Мета. Вимоги до системи резервного копіювання. Види резервного копіювання

* Резервне копіювання даних ( Резервне дублювання даних ) - процес створення копії даних

* Відновлення даних - процес відновлення в оригінальному місці

Мета

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

Крім цього вирішуються суміжні проблеми:

* Дублювання даних

* Передача даних і робота з загальними документами

Вимоги до системи резервного копіювання

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

* Простота в експлуатації - автоматизація (по можливості мінімізувати участь людини : як користувача , так і адміністратора) .

* Швидке впровадження - проста установка та налаштування програм , швидке навчання користувачів .

Размещено на http://www.allbest.ru/

Рисунок 2



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

Таблиця1



2. Cхеми ротації

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

Одноразове копіювання

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

Проста ротація

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

«Дід , батько , син»

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

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

« Ханойська вежа»

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

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

« 10 наборів »

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

Схеми « Ханойська вежа» « 10 наборів » використовуються нечасто , оскільки багато системи резервування їх не підтримують.



2.1 Зберігання резервної копії. Методи боротьби з втратою інформації

Размещено на http://www.allbest.ru/

Рисунок 3

Размещено на http://www.allbest.ru/

Рисунок 4

2.2 Безпека в мережах зберігання даних

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

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

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

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

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

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

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

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

Аж до недавнього часу йшли дискусії , чому віддати перевагу : SAN або NAS ? Сьогодні ж фахівці все частіше приходять до думки , що обидва підходи мають співіснувати .

Тепер про SAN. Вона являє собою відокремлену мережу , відокремлену від локальної , з можливістю зберігання величезних обсягів інформації , які можна нарощувати практично нескінченно . Типова SAN включає ряд дискових масивів , підключених до комутатора , який, у свою чергу , з'єднаний з серверами , службовцями для організації доступу до збережених даних . Технічну основу мережі зберігання даних складають волоконно-оптичні з'єднання , адаптери шини вузла FC HBA і FC- комутатори , в даний час забезпечують швидкість передачі 200 Мбайт / с і віддаленість між сполучаються об'єктами до 10 км (до 120 км за допомогою спеціальних рішень ) . САН дозволяє будь-якого сервера отримати доступ до будь-якого накопичувача , не завантажуючи при цьому ні інші сервери , ні локальну мережу компанії. Крім того , можливий обмін даними між системами зберігання без участі серверів.

Істотним недоліком SAN є висока ціна . Вартість обладнання та проекту з впровадження мережі може становити до декількох сотень тисяч доларів. Проте досвід показує , що такі суми витрачаються не даремно , адже мережеве зберігання даних дозволяє створювати інформаційні системи високої готовності і безвідмовності в роботі.Завдяки використанню в SAN FibreChannel вдалося домогтися максимального захисту інформації. Набір вбудованих в SAN інструментів включає аутентифікацію хостів шляхом процедур Тканина Вхід і процес входу , управління доступом хостів до цілей за допомогою розбиття на зони і списків доступу , і , що не менш важливо , технологію VSAN . Остання ділить SAN на безліч віртуальних комутуючих структур. Найбільш очевидна перевага SAN - зменшення навантаження на локальну мережу. У мережі зберігання можна запустити процедуру повного резервного копіювання , при цьому не побоюватися негативного впливу на трафік додатків. Як відомо , резервне копіювання помітно уповільнює роботу інших додатків , а оскільки мережа зберігання використовує дуже швидкий мережевий протокол , то це значно скорочує час для створення резервної копії. Більш того , ємність SAN відносно легко збільшити , додаючи нові дискові масиви .

Останнім часом в SAN стали застосовувати технології віртуалізації пам'яті. По суті , за допомогою віртуалізації сервери можуть використовувати кілька жорстких дисків (або їх певну ємність ) як один логічний том. Безпека в SAN реалізується на рівні сервера SAN , в той час як в NAS застосовується безпеку на рівні доступу до файлів. І в тому і іншому випадку додаткові засоби керування даними забезпечують реплікацію даних , моментальні знімки даних , високошвидкісне архівування та відновлення .



Размещено на http://www.allbest.ru/

Рисунок 5

Джерела загроз можуть бути як зовнішніми , так і внутрішніми.

Размещено на http://www.allbest.ru/

Рисунок 6

Основні рівні безпеки NAS і SAN :

рівень пристроїв

рівень даних

рівень управління і контролю

рівень мережевої взаємодії

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

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

Для авторизації користувачів слід задіяти схему із застосуванням списків контролю доступу ( Access ControlList ) . Найчастіше необхідно обмежити доступ до пристрою за допомогою багатофакторної ідентифікації .

На цьому рівні NAS працюють як файлові сервери. Однак крім традиційних каналів , для доступу до пристроїв зберігання (у тому числі до зовнішніх по відношенню до самого серверу NAS) можуть задіятися елементи архітектури SAN. Як правило , це жорсткі диски , підключені до сервера по оптичних лініях з використанням протоколів FibreChannel або FC -AL . У такому випадку на даний сегмент повинні поширюватися вимоги , аналогічні тим , що висуваються до архітектури SAN.

2.3 Рівень даних

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

блоків даних на рівні самих серверів. Незважаючи на те що для архітектури

SAN характерний блоковий доступ до збережених даних , самі обчислювальні вузли в разі активізації відповідних служб можуть виступити в ролі серверів NAS з наданням доступу за протоколами CIFS / SMB , а також NFS. Архітектура SAN передбачає підключення серверів і робочих станцій з єдиною зоною доступу до пристроїв зберігання . Тому вимога безпеки при доступі до даних повинне застосовуватися рівною мірою як до серверів , так і до робочих станцій . Таким чином виключається виконання серверами додатків невластивою їм ролі вузлів NAS , через які зловмисник міг би отримати несанкціонований доступ до конфіденційної інформації.

Враховуючи, що доступ до даних на серверах NAS здійснюється за протоколами CIFS / SMB і NFS , саме вони будуть розглядатися з точки зору можливих загроз. Згадані протоколи передбачають лише слабкий захист переданих паролів , особливо це стосується NFS. Коли це можливо , від використання NFS необхідно відмовитися , відключивши відповідну службу. Якщо ж до конфіденційності даних пред'являються високі вимоги , щоб уникнути компрометації паролів повинні бути передбачені додаткові заходи по авторизації користувачів із застосуванням необхідних програмно - апаратних засобів.

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

2.4 Рівень мережевої взаємодії

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

З точки зору безпеки на рівні мережевої взаємодії слід зазначити загрози несанкціонованого підключення до каналів з ??підміною адрес , що в рівній мірі відноситься до обладнання та каналам як в самих центрах обробки даних , так і у філіях . В силу відкритості архітектури і взаємної віддаленості комутуючого і конвертуючого обладнання пристрої можуть стати об'єктами атаки з подальшою втратою контролю над каналами і отриманням зловмисником неавторизованого доступу до переданих даних. Невірно сконфігуровані кінцеві пристрої мережі зберігання також стають привабливою мішенню для атаки.Оскільки мережевий рівень серверів NAS в більшості випадків організований па базі протоколу TCP / IP , основна загроза виходить від можливих атак через мережу : DoS , перехоплення сеансів , підміна адрес .

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

однієї компанії. Якщо трафік виходить за межі контрольованого мережного сегмента , обов'язково повинні бути встановлені міжмережеві екрани , а також кошти IDS .

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



2.5 Рівень управління доступом

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

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

На відміну від SAN , доступ до даних на вузлах NAS здійснюється на рівні файлів . При цьому сам вузол функціонує як файловий сервер , а потреба в його конфігурації і налаштувань мінімальна. Часто виробники серверів NAS (в силу досить вузької спеціалізації ) більшу частину налаштувань виконують до поставки сервера до замовника , і згодом за замовчуванням використовуються саме вони. Цю обставину необхідно враховувати при інтеграції серверів NAS як в локальну мережу , так і в мережу зберігання даних.

Одна з найбільш частих атак на сервери NAS - несанкціонований доступ з використанням слабкого захисту при передачі паролів по мережі за допомогою протоколів Telnet і HTTP.

Як і на всіх розглянутих раніше рівнях , важливо здійснювати строгий контроль за системними журналами.



2.6 Методи побудови систем зберігання даних

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

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

За даними Gartner , серед компаній , постраждалих від катастроф і пережили велику необоротну втрату корпоративних даних , 43 % ( !) Не змогли продовжити свою діяльність.

Відсутність доступу до даних рівноцінно відсутності даних !

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



3. Складові системи зберігання даних

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

Якщо дисковий масив виконаний у вигляді окремого пристрою , то для його підключення до серверів використовується певна інфраструктура . Залежно від протоколу доступу (транспорту ) , реалізованого в HBA і дисковому масиві , вона може бути простою шиною (як у випадку з протоколом SCSI) , так і мережею (як у випадку з протоколом FibreChannel ( FC )) . Якщо це мережа , що отримала назву " мережа зберігання даних" ( StorageAreaNetwork - SAN) , то , як і належить мережі , в ній використовується активне обладнання - концентратори і комутатори , що працюють по протоколу FC , ??маршрутизатори протоколу FC в інші протоколи (зазвичай в SCSI) . Таким чином, крім пристроїв зберігання даних до складу СГД необхідно ще додати інфраструктуру доступу , що зв'язує сервера з пристроями зберігання .

Відповідаючи на питання, де правильно провести межу, що відокремлює систему зберігання від серверного комплексу , пропонується розглядати систему зберігання даних як "чорний ящик". Тоді , для підключення сервера до системи зберігання , досить встановити в сервер HBA з необхідним протоколом , підключити його до системи зберігання і сервер відразу " побачить" свої дані - тобто за принципом " plugandplay " . Це ідеальна ситуація, до якої IT -індустрія , можливо , прийде в майбутньому. Сьогодні кордон, що відокремлює систему зберігання даних від серверів , треба проводити на самих серверах вище рівня менеджера дискових томів. А чому саме так , можна переконатися на такому прикладі : у системах , де потрібен високий рівень готовності , дисковий масив може вважатися єдиною точкою відмови ( SinglePointOfFailure - SPOF ) . Для ліквідації SPOF зазвичай встановлюється другий масив , при цьому дані Віддзеркалюються на обидва масиву. Сьогодні одним із найпоширеніших засобів дзеркалювання є менеджер дискових томів (наприклад , VERITAS VolumeManager ) . Таким чином , менеджер дискових томів залучений в процес забезпечення відмовостійкості системи зберігання даних і стає її компонентом.

Мережевою інфраструктурою , яка об'єднує велику кількість серверів і пристроїв зберігання , необхідно управляти і, як мінімум , відстежувати її стан. Сказане не означає , що немає необхідності моніторингу стану , наприклад , двох серверів і одного масиву , підключеного до них безпосередньо. Однак , це можна реалізувати підручними засобами - вбудованими утилітами серверів , масиву і операційної системи , безкоштовними ( freeware ) утилітами або " самописні " скриптами . Кожне з пристроїв в СГД має декілька об'єктів , що вимагають управління і контролю стану , наприклад дискові групи і томи у масивів , порти у масивів і комутаторів , адаптери в серверах. Як тільки число об'єктів управління в СГД починає обчислюватися десятками , управління такою конфігурацією за допомогою " підручних " засобів забирає у адміністраторів надто багато часу і сил , і неминуче призводить до помилок . Справитися з таким завданням можна тільки використовуючи повномасштабну систему управління. Це справедливо для будь-яких великих систем і для великої системи зберігання даних , зокрема. Впровадження системи управління стає особливо актуальним у тих випадках , коли система зберігання даних виділена не тільки структурно і функціонально , але й організаційно.

Размещено на http://www.allbest.ru/

Рисунок 7

Поняття Point -In- Time копії даних ( PIT - копія , іноді зустрічається скорочення PIT - копія) випливає з його назви - це копія даних , зроблена на певний момент часу , і стан даних " заморожено" у момент створення копії . Іноді плутають PIT - копії з " моментальними знімками " ( SnapShot ) , які насправді є тільки одним з методів створення PIT -копій . До інших методів створення PIT -копій відносяться методи клонування ( clone ) даних.

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

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

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

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

Відмово стійкість доступу серверів до даних досягається дублюванням шляхів доступу . Стосовно до SAN дублювання полягає в наступному : мережа SAN будується як дві фізично незалежні мережі , ідентичні по функціональності і конфігурації. У кожний з серверів , включених до SAN , встановлюється як мінімум по два FC- HBA . Перший з FC- HBA підключається до однієї " половинці " 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) . Впровадження системи управління дозволяє скоротити витрати на

Адміністрування СГД та спланувати витрати на її модернізацію. Консолідація технічних засобів також сприяє скороченню витрат на експлуатацію СГД.

Размещено на http://www.allbest.ru/

Рисунок 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 та ін ) підключаються серверів. Іншими словами , при створенні СГД проектувальник повинен виходити від завдань і бізнес-вимог замовника.



4. Вибір дискового масиву

Однією з головних складових системи зберігання даних є дисковий масив . У процесі проектування СГД неминуче виникає питання , який масив вибрати?

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

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

Размещено на http://www.allbest.ru/

Рисунок 10



4.1 Можливість створення PIT - копії даних засобами масиву

Дана функціональність масиву може знадобитися , якщо , наприклад , прийнято проектне рішення про завантаження даних з OLTP -завдання в DSS - задачу засобами масиву. Функція створення PIT -копій може бути реалізована різними методами - через " моментальний знімок" ( SnapShot ) (Мал. 4 ) або через повне копіювання даних ( clone ) . Різниця між цими методами полягає в тому , що SnapShot економить дисковий простір , оскільки для його створення потрібно всього лише місце для бітової карти і деякого пулу для збереження старих значень змінених блоків. Навпаки , clone вимагає того ж ( корисного ) обсягу , що і копійований LUN . Однак , якщо вихідний LUN схильний до частих змін , то необхідний для підтримки SnapShot обсяг дискового простору може істотно зрости. Якщо з копією LUN , створеної за допомогою SnapShot вестиметься інтенсивна робота (велике число запитів на введення-виведення), це може знизити продуктивність обміну даними з вихідним LUN . Копія LUN за допомогою SnapShot створюється моментально (звідси і назва - " моментальний знімок" ) , оскільки процес " копіювання " полягає лише у створенні бітової карти . Для створення clone потрібен певний час , оскільки відбувається повне копіювання блоків даних. У цей момент навантаження по вводу - висновку на копійований LUN істотно зростає. Існують проміжні способи створення PIT -копій , коли спочатку створюється SnapShot , а потім він поступово перетворюється на clone . Проектувальник повинен врахувати всі ці

особливості методів створення PIT -копій і у вимогах чітко вказати який метод планується використовувати.

Вимоги до продуктивності. Вимоги по відмово стійкості та надійності. Вимоги по масштабованості

* Дисковий масив повинен забезпечувати продуктивність N IOPS , а агрегована пропускна здатність масиву повинна становити M МБ / с. Як вже зазначалося , отримати такі цифри не просто . Якщо існує прототип системи або вибір дискового масиву здійснюється для модернізації існуючої СГД , то можна провести " натурні " заміри продуктивності та апроксимувати їх для очікуваного зростання навантаження на СГД. Якщо система створюється з " нуля" , то можна спробувати отримати ці цифри в якості вимог виробника прикладного ПЗ ( що практично не реально) або обраться до виробників масивів , щоб ті провели визначення необхідних параметрів масиву ( sizing ) . Зазвичай виробники мають методики "грубої " оцінки необхідної продуктивності . Але вхідними даними для цих методик , як правило , служать очікуване число транзакцій і їх " вага " ( light , medium , heavy ) , які теж не завжди можна визначити .

Специфічні функції управління кеш- пам'яттю масиву. Наприклад , до таких функцій відносяться:

можливість закріплення ділянки кеш -пам'яті за конкретним LUN ( може придатися для розміщення в кеш часто використовуваних службових таблиць бази даних);

відключення використання кеш на запис та / або читання для конкретного LUN (може знадобитися для DSS - задач);

забезпечення рівня сервісу у вигляді заданого рівня продуктивності ( IOPS ) або пропускної здатності ( МБ / с) для зазначеного сервера.

Размещено на http://www.allbest.ru/

Рисунок 11



Можливість створення PIT -копій даних для використання їх у системі резервного копіювання. У ряді систем , де обробляються великі обсяги даних ( терабайти ) , а сервіси повинні бути доступні 24х7 при великих навантаженнях , необхідно застосовувати Serverless резервне копіювання . Для цього використовується механізм створення PIT -копій засобами дискового масиву.

Вимоги по обслуговуваності

* Можливість заміни компонентів масиву "на ходу" без зупинки системи . Виконання цієї вимоги важливо для систем , що працюють в режимі 24х7 .

Размещено на http://www.allbest.ru/

Рисунок 12



Размещено на http://www.allbest.ru/

Рисунок 13

Класи масивів придумувати не треба , вони вже визначені самим ринком , це : початковий клас ( low - end ) , середній клас ( mid - range ) і вищий клас ( high - end ) .Масиви зазначених класів відрізняються , в першу чергу, не кількісними характеристиками , а функціональністю і архітектурою. До функціональності

low - end масивів можна віднести підтримку різних рівнів RAID і можливість дублювання контролерів ( якщо це не JBOD ) . Від масивів класу mid - range вже потрібна підтримка LUN - masking і створення PIT -копій . А в масивах класу high - end на додаток до зазначених можливостям також реалізовані апаратна реплікація , підтримка OS/390 ( zOS ) та управління якістю сервісу ( на рівні продуктивності в IOPS або пропускної здатності в Мбайт / с).

Але все ж основним критерієм , за яким можна віднести масив до одного з класів mid - range або high - end , є архітектура . Багато виробників заявляють , що mid - range масиви мають модульну архітектуру , а high - end масиви - монолітну . Це не зовсім вірно. Модульна або монолітна "архітектура" говорить про конструктив масиву - збирається з окремих блоків або шаф. Насправді архітектуру всіх mid - range масивів (і багатьох low - end ) можна характеризувати як " двухконтроллерную із загальною шиною " .

Для high - end масивів характерна коммутируемая або матрична архітектура ( 1 ) (рис.13 ) . Очевидно , що в даній архітектурі немає " вузьких місць" , тоді як в mid - range архітектурі вузькими місцями є : контролер , оскільки кожен контролер обслуговує свої RAID- групи ( набір дисків , на яких реалізовано один рівень RAID) , шина між контролерами , обмежене число FC -AL петель до дисків , розташування дисків RAID- групи "вздовж " однієї петлі FC -AL . У high - end масивах RAID- групи розташовуються " впоперек" FC -AL петель.

...