Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Організація розподілених файлових систем
Цей розділ присвячено опису загальних особливостей організації РФС.
Керування іменами в РФС Є два основні підходи до реалізації керування іменами в розподілених файлових системах із прозорістю доступу. Основні відмінності між ними полягають у вигляді файлової системи віддаленого комп'ютера на комп'ютері-клієнті. Перший підхід ґрунтується на тому, що відображення файлової системи для різних клієнтів може виглядати по-різному. Так відбувається у разі віддаленого монтування файлових систем. У цьому разі перед використанням віддаленої файлової системи її потрібно змонтувати у підкаталог файлової системи клієнта. Різні клієнти можуть монтувати ту саму систему в різні каталоги. Такий підхід реалізувати досить просто (немає потреби відстежувати, яким чином різні клієнти отримують доступ до файлів), але керування системою стає складнішим (у файловій системі клієнта виявляються «перемішаними» локальні та віддалені каталоги, до одного й того самого файла звертаються із використанням різних шляхів тощо). У разі реалізації другого підходу файлова система визначає єдиний простір імен, що матиме однаковий вигляд для всіх її клієнтів. Таке єдине відображення дає змогу спростити використання системи. Цей підхід складніший у реалізації, але є найбільш зручним для користувачів. Важливою додатковою властивістю, що може бути реалізована у РФС, є незалежність від місця розташування (location independence). Якщо її підтримують, шлях до файла залишається незмінним у разі його фізичного переміщення (наприклад, з одного сервера на інший). Ця властивість доволі складна в реалізації і рідко підтримується в сучасних РФС.
Реалізація віддаленого доступу до файлів Припустимо, що клієнт звернувся до віддаленого файла, а засоби керування іменами дали змогу знайти його фізичне місце розташування. Після цього необхідно звернутися мережею до віддаленого файла, обробити його і повернути результат клієнтові. Розглянемо підходи до реалізації такого віддаленого доступу до файла. Найпростішим підходом є передавання кожного запиту на сервер у вигляді окремого віддаленого виклику процедури. При цьому жодного кешування даних не роблять, кожний запит вимагає передавання даних мережею. Це віддалене обслуговування (remote service). Основними його перевагами є простота реалізації та відсутність суперечностей (всі дані негайно зберігаються на диску сервера), а головним недоліком — низька продуктивність, оскільки кожна файлова операція вимагає пересилання даних мережею та звертання до диска на сервері.
Для підвищення продуктивності використовують кешування даних. У даному випадку локальні кеші розташовані на клієнтах (звичайно в їхній основній пам'яті), а основною копією даних є копія даних на сервері. При цьому головною проблемою, як і для багатопроцесорних систем, є необхідність підтримки когерентності локальних кешів. Наведемо два способи підтримки погодженості даних у локальних кешах. Перший зводиться до того, що в разі будь-якої зміни даних в одному із кешів їх негайно записують на диск відповідно до методу віддаленого обслуговування, при цьому очищують усі інші кеші. Фактично так реалізований кеш із наскрізним записом (див. пункт 12.3.2). Операції читання даних продовжують обслуговувати із кеша. Другим способом є використання сеансової семантики (session semantics). При цьому всі зміни, які вносять у файл після його відкриття клієнтським процесом (упродовж сеансу роботи клієнта із цим файлом), будуть доступні тільки цьому процесові. Після закриття файла його змінену копію пересилають на сервер, і вона стає доступною іншим клієнтським процесам.
Файлова система NFS Найвідомішим прикладом реалізації розподілених файлових систем є Network File System (NFS) [44]. Сьогодні NFS є стандартною файловою системою більшості UNIX-сумісних ОС.
Принцип дії NFS Файлова система NFS об'єднує окремі каталоги файлових систем віддалених комп'ютерів у єдине дерево каталогів локального комп'ютера. Таке об'єднання є прозорим для користувачів — з їхнього погляду остаточне дерево каталогів не відрізняється від локальної файлової системи UNIX. Архітектура цієї файлової системи реалізована на базі взаємодії між NFS-клієнтами і NFS-серверами. Зазначимо, що комп'ютер може одночасно відігравати роль клієнта і сервера. 1. Для того щоб NFS-клієнт міг отримати доступ до каталогу локальної файлової системи NFS-сервера, цей каталог потрібно експортувати. Для цього необхідно додати відповідний шлях у список експорту, який зберігають на сервері, зазвичай у спеціальному файлі /etc/exports. Цей список зчитує ядро ОС під час завантаження системи.
2. Для доступу до експортованих каталогів сервера NFS-клієнти мають їх вмонтувати в каталоги своєї локальної файлової системи аналогічно до того, як монтують файлові системи. Різні клієнти можуть монтувати віддалений каталог у різні точки своїх файлових систем, причому сервер не має інформації про точки монтування його каталогів. Віддалений каталог внаслідок монтування може навіть стати кореневим каталогом файлової системи клієнта. Так реалізовано роботу бездискових робочих станцій, які завантажуються через мережу. NFS використовує протокол монтування і протокол NFS. Як базові компоненти обидва протоколи використовують віддалені виклики процедур відповідно до інтерфейсу Sun RPC.
Протокол монтування Протокол монтування використовують для задання вихідного логічного з'єднання між сервером і клієнтом під час операції монтування. Розглянемо кроки цього протоколу. 1. Клієнт виконує RPC-запит MNT для виклику процедури монтування. Параметром цієї процедури на сервер передають шлях до віддаленого каталогу. 2. Якщо цей каталог був експортований і обмеження доступу дають змогу виконати монтування, клієнтові повертають файловий дескриптор, що містить всю інформацію, необхідну для доступу до файлів усередині каталогу (ідентифікатор локальної файлової системи сервера та індексний дескриптор каталогу всередині цієї файлової системи). Є два підходи до монтування віддалених файлових систем. Перший - це явне монтування, аналогічне до монтування локальних файлових систем. Зокрема, специфікації явного монтування можуть бути додані у файл /etc/fstab. Така конфігурація, однак, призводить до проблем, якщо віддалена система недоступна в момент завантаження.
Більш розповсюдженим підходом є автоматичне монтування (automount), коли фактичне монтування каталогу виконують після першого звертання до нього.
Протокол NFS Цей протокол визначає набір RPC-запитів, що реалізують операції із віддаленими файлами і каталогами (пошук файла в каталозі — LOOKUP, читання набору елементів каталогу — READDIR, створення і вилучення файлів і каталогів — CREATE, REMOVE, MKDIR, RMDIR, читання і записування файлів - READ і WRITE, робота з атрибутами файлів - GETATTR, SETATTR). Серед цих NFS-запитів, однак, немає аналогів системних викликів ореп() і ciose(). Це відображає фундаментальну властивість NFS-серверів - вони не зберігають стану між звертаннями клієнтів (див. розділ 11.5.1). Такий підхід використовують через небезпеку втрати стану в разі виходу сервера з ладу (у цьому випадку подальше використання відкритих файлів стане неможливим). Те, що NFS-протокол не зберігає стану, визначає дві важливі характеристики запитів, що входять у нього. 1. NFS-запити є незалежними. Усю інформацію, необхідну для виконання такого запиту, потрібно передавати в нього як параметри. Наприклад, запит WRITE має приймати як параметри унікальний ідентифікатор файла та зсув усередині файла. 2. Більшість NFS-запитів мають бути ідемпотентними. Це означає, що NFS-клієнт може відіслати серверу один і той самий запит кілька разів, при цьому загальний результат їхнього виконання має залишитися тим самим. Наприклад, читання дискового блока із файла (запит READ) є ідемпотентним: внаслідок виконання операції повертаються ті самі дані незалежно від того, скільки разів вона була повторена.
Не всі запити мають властивість ідемпотентності. Наприклад, повторне виконання запиту REMOVE призводитиме до спроби вилучення відсутнього файла. Для вирішення цієї проблеми сучасні реалізації NFS підтримують спеціальний кеш повторних запитів, у якому зберігають інформацію про запити, виконані останнім часом. Якщо новий запит збігається із якимось запитом із цього кеша, його не виконують. Протокол NFS — це реалізація протоколу запиту-квітування. Якщо клієнт не отримає підтвердження виконання запиту до вичерпання часу очікування, він пересилає той самий запит повторно. Це повторюють доти, поки запит не буде виконано (при цьому час очікування підтвердження із кожною новою спробою подвоюють), після чого клієнт продовжує свою роботу, ніби й нічого не сталося (внаслідок ідемпотентності всіх відісланих запитів). Якщо сервер вийде з ладу, клієнт повторюватиме запити в циклі і продовжувати роботу не зможе. Спосіб завершення циклу задають під час монтування каталогу. У разі жорсткого монтування (hard mount) цикл триватиме нескінченно (він може бути перерваний тільки після відновлення роботи сервера), у разі м'якого монтування (soft mount) цикл переривають після закінчення деякого часу (звичайно кількох хвилин), а клієнтові повертають помилку. За замовчуванням використовують жорстке монтування.
Кешування у NFS Проблеми, які виникають під час реалізації кешування в NFS, наведено нижче. Першою з них є можливість втрати даних із кеша. Зокрема у разі виходу з ладу сервера всі дані, які перебувають у його дисковому кеші, але ще не записані на диск, будуть втрачені. Вихід із ладу клієнта, з іншого боку, може спричинити втрати модифікованих даних у локальному кеші клієнта. Для вирішення цієї проблеми у NFS застосовують кеш із наскрізним записом. Внаслідок виконання виклику WRITE всі модифіковані дані мають зберігатися на диску сервера до того як керування буде повернене клієнтові. Клієнт може кешу-вати дані локально, але після того як їх передали серверу, вважають, що вони записані на диск. Це значно зменшує продуктивність (тепер кожна операція записування спричиняє звертання до диска на сервері), але гарантує, що вихід із ладу сервера не впливатиме на відображення даних для клієнта (після повернення сервера до роботи клієнт може негайно продовжувати працювати з ним без повторного монтування файлової системи).
Другою проблемою є забезпечення когерентності кеша клієнтів. Опишемо базовий спосіб вирішення цієї проблеми у NFS. Якщо клієнт змінює файл, дані зберігають на сервері. При цьому інші клієнти продовжують використовувати стару версію зі своїх кешів до вичерпання деякого часового проміжку (довжина якого може бути змінена адміністратором сервера; звичайно вона становить від 3 до ЗО с). Після цього перевіряють, чи не змінився файл на сервері, і, якщо змінився, клієнт отримує нову копію і зберігає її в локальному кеші. Як наслідок під час роботи з NFS звичайною є ситуація, коли файли, створені одним клієнтом, залишаються невидимими для всіх інших упродовж досить тривалого часу.
Файлові блокування у NFS Організація файлових блокувань на рівні NFS-протоколу неможлива, оскільки для цього потрібне збереження інформації на сервері. Сучасні версії NFS реалізують підтримку блокувань за допомогою окремого протоколу NLM (Network Lock Manager). Коли NFS-клієнт запроваджує або знімає файлове блокування, буде згенеровано RPC-виклик відповідно до цього протоколу. Протокол NLM підтримує збереження стану. У зв'язку з цим його використання ускладнює обробку збоїв клієнта і сервера. ♦ У разі виходу з ладу сервера клієнти знімають свої блокування; це відбувається тоді, коли вони перестають отримувати від NLM-сервера повідомлення, що підтверджують його функціонування. ♦ У разі перезапуску клієнта він має надіслати серверу відповідне повідомлення, після чого сервер вивільняє всі його блокування. Зазначимо, що в разі аварійного завершення клієнт зазвичай не встигає відіслати таке повідомлення, і його блокування адміністратор системи має вивільняти вручну.
Безпека даних у NFS Керування доступом у NFS ґрунтується на рівнях аутентифікації Sun RPC. Вихідна модель керування доступом не є безпечною, оскільки вона використовує рівень аутентифікації AUTH_UNIX. Кожен NFS-запит супроводжують uid і набір gid, які порівнюють з атрибутами безпеки необхідного файла. У разі збігу ідентифікаторів і наявності відповідних прав вважають, що доступ до файла дозволено. Проблеми, що виникають при цьому, описані у пункті 20.2.2. Деякі сучасні реалізації NFS дають змогу використовувати аутентифікацію рівня AUTH_DES, таку технологію називають Secure NFS.
|
||||||||
Последнее изменение этой страницы: 2017-02-06; просмотров: 238; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.16.29.209 (0.018 с.) |