Лекція 10. Система coda та iншi розподiленi файловi системи Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України


НазваЛекція 10. Система coda та iншi розподiленi файловi системи Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Дата конвертації14.03.2013
Розмір445 b.
ТипЛекція


Лекція 10. Система CODA та iншi розподiленi файловi системи

  • Діденко Дмитро Георгійович

  • Старший викладач кафедри ММСА ННК «ІПСА»

  • Національний технічний університет України

  • «Київський політехнічний інститут»

  • м. Київ, Україна


Питання заняття

  • Система CODA.

  • Система PLAN 9.

  • Файлова система xFS.

  • Захищена файлова система SFS.



1. Система CODA



1.1. Історія розвитку CODA

  • Файлову систему CODA розроблено в унiверситетi Карнегi-Мелона CMU (Carnegie Mellon University) наприкiнцi 1987 року й iнтегровано в ОС UNIX, LINUX. У системi забезпечено масштабованiсть i високу доступнiсть користувачiв за рахунок удосконаленої схеми кешування, яка дозволяє клiєнту продовжувати роботу пiсля вiдключення вiд сервера, i прозорiсть вiдмов системи. Прототипом системи є система AFS на 10000 робочих станцiй i має ту ж саму AFS Virtue органiзацiю.



1.2. Вузли AFS

  • Вузли AFS подiляють на двi групи: робочi станцiї клiєнтiв Virtue i видiленi файловi сервери Vice з централiзованим адмiнiструванням.



1.3. Внутрішня структура станцiї Virtue системи CODA



1.4. Прикладний процес Venus

  • Прикладний процес Venus вiдповiдає за надання доступу до файлiв серверiв Vice, а також за продовження виконання операцiй клiєнтами, коли сервери тимчасово недоступнi. Рiвень VFS перехоплює виклики з клiєнтських додаткiв i передає виклик у локальну файлову систему або процесу Venus.



1.5. Прикладний процес Venus (продовження)

  • Взаємодiю iз сервером здiйснює спецiальна програма VENUS. Ця програма також пiдтверджує роботу вузла VIRTUE в умовах, коли немає зв'язку iз серверами VICE. Venus спiлкується з Vice через RPC користувацького рiвня, надбудованим над UDP. На боцi сервера є три рiзнi процеси: файловий сервер Vice, сервер автентифiкацiї i процеси вiдновлення для збереження непротисуперечностi метаiнформацiї на кожному iз серверiв Vice.



1.6. Операцiї CODA

  • На користувацькому рiвнi пiдтримується бiльшiсть операцiй NFS, але на вiдмiну вiд NFS в CODA є глобальний розподiлений простiр iмен, який пiдтримується серверами Vice. Клiєнти отримують доступ до цього простору через спецiальний вкладений каталог у своєму локальному адресному просторi.



1.7. Система RPC2

  • Система RPC2 складнiша за звичайний RPC. Запити RPC2 реалiзують надiйнi виклики RPC на базi ненадiйного протоколу UDP. Iз кожним викликом RPC код клiєнта RPC2 запускає потiк виконання, який передає запит на сервер i блокується. Сервер регулярно вiдповiдає повiдомленнями про його обробку. Якщо таких повiдомлень не надходить, потiк повертає повiдомлення про помилку в додаток.



1.8. Система RPC2 (продовження)

  • Система RPC2 пiдтримує побiчнi ефекти (side effects), пiд якими розумiють взаємодiю клiєнта i сервера з використанням специфiчного протоколу додатка. Сервер i клiєнт установлюють постiйний потiк даних у режимi iзохронного передавання з гарантованою затримкою передавання даних мiж мiнiмальним i максимальним значеннями.



1.9. Операції RPC2

  • Зокрема, RPC2 здiйснює групове розсилання повiдомлень про наявнi кешованi файли в локальнiй файловiй системi VIRTUE. Система RPC2 надбудована над ненадiйним протоколом UDP i виконує всi операцiї для забезпечення надiйного зв'язку. RPC2 запускає потiк виконання, що передає запит на сервер, i блокується. Сервер регулярно повiдомляє про оброблення отриманого запиту. Якщо немає зворотного повiдомлення, робиться висновок про вiдключення сервера. Тодi вузол VIRTUE переходить в автономний режим роботи з керованими файлами, отриманими iз сервера.



1.10. Зв’язок між сервером і клієнтом

  • Сервер i клiєнт установлюють постiйний потiк даних у режимi iзохронного передавання даних з гарантованим затриманням у межах мiнiмального i максимального значень. Це дозволяє передавати в реальному часi вiдеоданi з використанням спецiального iнтерфейсу побiчних процесiв, якi реалiзуються додатком.



1.11. Паралельні виклики RPC

  • Для паралельних викликiв RPC застосовують систему MultiRPC, яка є частиною RPC2 i прозорою для отримувача. Отримувач сприймає виклик MultiRPC як звичайний RPC з подiбною семантикою.



1.12. Процеси в CODA

  • Процеси в CODA чiтко подiляються на клiєнтськi та сервернi. Клiєнтськi реалiзуються за допомогою програми VENUS, а сервернi - за допомогою Vice. Цi типи процесiв органiзовано у виглядi паралельних потокiв в адресному просторi iмен користувача. Для органiзацiї неперервної операцiї за умови блокувальних запитiв уведення-виведення застосовують окремий потiк виконання, який перебирає на себе операцiї виконання багаторiвневих асинхронних операцiй базової ОС. Такий потiк виконання ефективно малює синхронне введення-виведення без блокування процесу в цiлому.



1.13. Iменування в CODA

  • Iменування в CODA подiбно до UNIX: файли групуються у модулi (томи - Volumes), яким вiдповiдають певнi дiлянки на диску. Зазвичай том - це колекцiя файлiв, яка належить одному користувачу. Томи можуть монтуватись; монтажною точкою служить кореневий вузол iншого тому.



1.14. Повне iм'я файлу

  • Повне iм'я файлу часто мiстить кiлька монтажних точок. Для прозоростi сервер VICE повертає у VENUS iнформацiю про монтування. Це дозволяє VENUS автоматично монтувати томи у просторi iмен клiєнта з використанням рiвня VFS iнтерфейсу локальної файлової системи.



1.15. Простір імен

  • Програма VENUS пiдтримує структуру загального простору iмен. Клiєнтам гарантується однаковiсть файлiв сумiсного використання, хоча визначення iмен файлiв грунтується на локальнiй реалiзацiї простору iмен.



1.16. Ідентифікатори файлів

  • Файлам вiдповiдають iдентифiкатори файлiв. Iдентифiкатори є унiкальними i пов'язанi зi зберiганням файлiв точно в одному томi. Том може бути реплiковано на кiлькох серверах.



1.17. Види томів

  • Логiчнi томи - передбачають можливiсть реплiкацiї фiзичного тому i мають iдентифiкатор реплiкованого тому RVID (Replicated Volume Idetifier). Iз RVID асоцiює кiлька реплiк;

  • Фiзичний том - має iдентифiкатор VID (Volume Idettifier) для уточнення конкретної реплiки незалежно вiд її мiсцеперебування.



1.18. Пошук по ідентифікатору файлу

  • Кожен файл має 96-бiтний iдентифiкатор файлу, який складається з двох частин: RVID i дескриптора файлу. Перша частина, що складається з 32 бiт, являє собою iдентифiкатор логiчного тому. Для пошуку файлу клiєнт передає RVID у БД реплiкацiї томiв (Volume Replication Databasе), i БД повертає список VID (Volume ID). Вiн вiдповiдає iдентифiкатору RVTD i може мати кiлька значень: VID1, VID2.



1.19. Реалiзацiя файлiв у CODA



1.20. Приклад пошуку по ідентифікатору файлу

  • Отримавши VID, клiєнт шукає сервер, на якому мiститься робоча реплiка логiчного тому. Пошук здiйснюється надсиланням VID у БД розмiщення томiв VLDB (Volume Location Database), яка повертає поточне мiсцеперебування конкретного фiзичного тому.



1.21. Приклад пошуку по ідентифікатору файлу (продовження)

  • Друга частина складається з 64 бiт i є дескриптором, який унiкально iдентифiкує файл у межах тому. Вiн є iдентифiкатором вузла iндексу вiртуальної файлової системи VFS i має назву вiртуального вузла (VNODE) (аналогiчно i-node в UNIX).



1.22. Розподiлення файлiв мiж клiєнтами

  • Розподiлення файлiв мiж клiєнтами вiдбувається подiбно до транзакцiї сеансу використання файлу. Якщо клiєнт А вiдкриває або модифiкує файл, то клiєнт В продовжує використовувати стару версiю цього файлу.

  • Вiдкриття, модифiкацiя файлу клiєнтом В не впливає на використання клiєнтом А старої версiї файлу.



1.23. Реалiзацiя транзакцiй у разi сумiсного використання файлiв



1.24. Транзакції

  • У транзакцiях застосовують поняття роздiлу (partition), пiд яким розумiють частину мережi, iзольованої вiд решти мережi i яка мiстить колекцiю серверiв, клiєнтiв або тих i тих. Iз вiдновленням з роздiлу файлова система перевiряє множину транзакцiй роздiлу.



1.25. Блокування

  • За системним одночасним викликом на однiй машинi встановлюється тип сеансу для кожного клiєнта з вiдповiдними встановленнями потрiбних блокувань читання i записування файлу за допомогою процесу VENUS. Семантика розподiлу файлiв виглядає як технологiя двофазного блокування.



1.26. Оброблення конфлiктiв

  • У процесi оброблення конфлiктiв мiж роздiлами використовується проста схема версiй файлу. Номер версiї вказує на кiлькiсть разiв унесення змiн у цей файл з моменту створення файлу. Пiсля закiнчення сеансiв роботи з файлами i повернення серверу сервер порiвнює номери версiй. Файл у ходi сеансу оновлюється лише за умови

  • Vnow + 1 = Vclient + Nupdates,

  • де Vnow - поточна версiя файлу; Vclient - номер версiї файлу, отриманий у процессi передавання файлу вiд сервера до клiєнта; Nupdates - кiлькiсть змiн за сеанс, переданих клiєнтом i прийнятих сервером пiсля повторного пiдключення.



1.27. Розв'язання конфлiкту

  • Розв'язання конфлiкту перекладається на клiєнта. У випадку незбiжностi версiї сервер вiдхиляє файл, який залишається у клiєнта для його повторного пiдключення.

  • У разi виникнення конфлiкту оновлення файлу в паралельних сеансах вiдмiняється, але версiї зберiгаються клiєнтом для подальшого узгодження.



1.28. Кешування i реплiкацiя

  • Кешування i реплiкацiя в CODA забезпечують високу доступнiсть до файлiв. Кешування на клiєнтi полiпшує масштабованiсть i вiдмовостiйкiсть. Сервер фiксує данi про кешування файлу у клiєнта i за допомогою зворотного виклику (callback promise). Пiсля першої змiни файлу клiєнтом за допомогою вiдмiни зворотного виклику (callback break) сервер повiдомляє про некоректнiсть копiї. Вiдкриваючи файл надалi, у наступному сеансi всi клiєнти отримають нову версiю файлу iз сервера.



1.29. Реплiкацiя томiв

  • Реплiкацiя томiв для колекцiї серверiв, якi називають групою сховища файлiв VSG (Volume Storage Group), дозволяє клiєнту обмежитись доступними серверами VSG - AVSG (Accessible Volume Storage Group). Якщо AVSG порожня для цього клiєнта, то клiєнт вважається вiд'єднаним (disconnected).



1.30. Несуперечність реплiкованого тому

  • Пiдтримання несуперечностi реплiкованого тому здiйснюється протоколом реплiкованого запису, зокрема з використанням варiанта "читаємо раз - пишемо все" ROWA (read one write all). Зi змiною прочитаного файлу в разi закриття файлу клiєнт пересилає його всiм членам AVSG за допомогою паралельного пересилання MultyRPC.

  • Групи AVSG мають версiї, якi описуються вимiром версiї CODA для кожного файлу.



1.31. Клiєнти з двома рiзними AVSG одного реплiкованого файлу



1.32. Приклад реплікації

  • На початку роботи деякий файл F, що використовується клiєнтами А i В, має вектор (1;1;1) для серверiв S1, S2, S3. За наявностi розриву i в разi змiни файлу F у першiй групi для клiєнта A F набуває вектор (2;2;1), а в другiй групi для клiєнта В - (1;1;2). З усуненням розриву надалi вiдбувається узгодження конфлiкту (версiй файлу) в автоматичному або ручному режимi.



1.33. Вiдмовостiйкiсть у CODA

  • Вiдмовостiйкiсть у CODA пiд час роботи клiєнта забезпечується використанням автоматичного режиму з наперед отриманим нагромадженим файлом з тому.



1.34. Взаємодiя тому i клiєнта в CODA



1.35. Стани клієнта

  • Зазвичай клiєнт перебуває у станi нагромадження, у якому вiн може надсилати запити серверу на файл. Якщо AVSG нульовий (порожнiй), клiєнт переходить у стан емуляцiї з використанням кешованих копiй файлу для тому. Але для iнших томiв AVSG можуть бути не порожнiми. Пiсля вiдновлення зв'язку клiєнт переходить у стан вiдновлення змiн у файлi сервера з узгодженням конфлiкту. Пiд час вiдновлення можливий розрив iз сервером. Механiзмом прiоритетiв користувач визначає iмена важливих для нього файлiв у БД нагромадження (hoard database).



1.36. Рiвновага кешу

  • Рiвновага кешу забезпечується виконанням трьох умов:

  • наявнiстю файлу з найвищим прiоритетом;

  • заповненням кеша файлами з ненульовими прiоритетами;

  • пiдтриманням кожного файлу в AVSG.



1.37. Пiдвищення вiдмовостiйкостi

  • Для пiдвищення вiдмовостiйкостi додатково застосовують механiзм вiдновленої вiртуальної пам'ятi RVM (Recoverable Virtual Memory) для пiдтримання важливих структур даних.



1.38. Захист даних у CODA

  • Захист даних у CODA забезпечується наявнiстю захищених каналiв i використанням захищених викликiв RPC iз застосуванням системної автентифiкацiї. Авторизацiя в серверах VICE виконується для каталогiв, а не для файлiв.



2. Система PLAN 9



2.1. Опис системи PLAN 9

  • У системi PLAN 9 застосовують потужнi сервери з централiзованим керуванням. Доступ до ресурсiв розподiленої системи, зокрема до процесiв й iнтерфейсiв мережi, виконується одноманiтно з використанням операцiй роботи з файлами, подiбними до операцiй UNIX. Кожний сервер має iєрархiчнi простори iмен ресурсiв. Клiєнт може монтувати локально свiй простiр iмен за аналогiєю з NFS на основi локальних просторiв iмен серверiв.



2.2. Організація зв'язку

  • Зв'язок здiйснюється за протоколом операцiй з файлами 9Р, який надiйно працює з транспортними протоколами, протоколами дейтаграм IL (Internet Link) i TCP. Мережевi iнтерфейси дають змогу створювати файлову систему, подiбну до UNIX.



2.3. Типи серверів

  • Сервери PLAN 9 можуть бути рiзних типiв з власною iєрархiєю iмен. Зокрема, це можуть бути файловi сервери, сервери для роботи з вiкнами (файли для роботи з пристроями "мишки" або екраном).



2.4. Органiзацiя системи PLAN 9



2.5. Iменування файлів

  • Iменування в PLAN 9 грунтується на внутрiшньому просторi iмен з локально монтованих вiддалених просторiв iмен. Файл має унiкальний номер, шлях стосовно сервера або пристрою i версiю, яка збiльшиться на одиницю у разi змiни файлу. Клiєнт пiд час монтування повинен знати тип i номер пристрою сервера, за яким створено файлову систему. Клiєнти можуть керувати файлами з використанням спецiального сервера cfs, який запускається автоматично пiд час завантаження машини.



2.6. Коректнiсть файлів

  • Коректнiсть забезпечується перевiркою останньої версiї файлу iз сервера. Автентифiкацiя користувачiв у PLAN 9 подiбна до протоколу Нiдхема-Шредера.



3. Файлова система xFS



3.1. Історія розробки xFS

  • Систему xFS розроблено в унiверситетi Берклi (США) для локальних мереж зi швидкiсними каналами зв'язку. Данi та функцiї керування розподiляються по машинах у xFS за допомогою процесiв: сервера зберiгання (storage server), менеджера метаданих (metadata manager) i клiєнта (client).



3.2. Сервери зберiгання

  • Сервери зберiгання реалiзують керування масивом вiртуальних дискiв подiбно до технологiї RAID. Менеджер метаданих вiдслiдковує мiсцеперебування блокiв файлiв, можливо по кiлькох серверах, i передає запити клiєнтiв до серверiв зберiгання. Клiєнт приймає запити користувачiв i виконує операцiї з файлами.



3.3. Клієнти та менеджери

  • Функцiї клiєнтiв, менеджерiв i серверiв можуть виконувати довiльнi машини. Для повнiстю симетричних систем усi три процеси наявнi в кожнiй машинi.



3.4. Зв'язок у xFS

  • Зв'язок у xFS спочатку реалiзувався за RPC, але тепер застосовують активнi повiдомлення (active messages), у яких вказуються процес оброблення на боцi отримувача i параметри повiдомлення. Обробляється лише одне повiдомлення i обробники не спроможнi блокуватися.



3.5. Масив вiртуальних дискiв

  • Масив вiртуальних дискiв реалiзовано як файлову систему зi структурою журналу LFS (Log-Structured File System), у якiй операцiї записування, включаючи модифiкацiю вузлiв iндексiв, блокiв каталогiв i блокiв даних, буферизуються i записуються на диск сумiсно - однiєю операцiєю. Якщо до журналу додається черговий сегмент, вiн дiлиться на фрагменти сталої довжини, включаючи нарiзування (stripping).



3.6. Організація серверів

  • Сервери органiзовано в групи нарiзування (strip groups), належнiсть до якої сервера визначається за глобальною реплiкованою таблицею. Фрагмент паритету (parity fragment) дозволяє вiдновити сегмент з фрагментiв, припинивши роботу одного iз серверiв.



3.7. Принцип нарiзування в системi xFS



3.8. Таблиця індексів

  • У xFS використовують менеджери для кожного файлу, який пiдтримує карту iндексiв - таблицю посилань на iндекснi вузли, за якими в журналi можна знайти реальний iндекс вузла файлу. У разi виконання або змiни файлу iндексний файл також може змiнюватись. Керування файлами розподiлено мiж кiлькома менеджерами. Для пошуку менеджера файлу застосовують карту менеджерiв (manager map).



3.9. Зчитування блокiв



3.10. Приклад зчитування блоків

  • На основi файлу f за каталогом знаходять iдентифiкатор файлу fid. За цим iдентифiкатором на кроцi 2 виконується пошук менеджера, шо дає змогу на кроцi 3 знайти блок, у якому розмiщується реальний iндекс. На кроцi 4 визначається мiсцеположення в серверi вузла за iдентифiкатором групи нарiзування, iдентифiкатором сегмента i змiщенням в цьому сегментi. Результатом є список серверiв, у яких було збережено сегмент з вiдповiдним iндексним вузлом. На кроцi 5 передається адреса вузла на диску i повторюються кроки 4, 5 для зчитування блоку.



3.11. Глобальні ідентифікатори

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



3.12. Кешування в xFS

  • Кешування в xFS подiбне до системи CODA, за винятком того, що вiдбувається кешування файлiв, а не блокiв.



3.13. Вiдмовостiйкiсть у xFS

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



4. Захищена файлова система SFS



4.1. Особливості SFS

  • У системi SFS (Secure File System) засоби керування ключами вiдокремленi вiд засобiв захисту файлової системи. Тобто клiєнт не отримує доступу до файлу, не маючи секретних ключiв, одержання яких не залежить вiд доступу до файлiв.



4.2. Структури системи SFS



4.3. Клiєнт SFS

  • Клiєнт SFS являє собою сервер для NFS з використанням ONC RPC за протоколом NFS. Клiєнт SFS вiдповiдає за органiзацiю захищеного каналу iз сервером SFS i зв'язок з користувацьким агентом (user agent), який автоматично виконує iдентифiкацiю користувача. Система SFS не визначає способу автентифiкацiї користувачiв, а використовує рiзних агентiв для рiзних протоколiв автентифiкацiї користувача у разi органiзацiї окремого процесу. Сервер SFS створює процес ядра SFS для оброблення запитiв клiєнтiв SFS з використанням видiленого сервера автентифiкацiї.



4.4. Кешування у SFS

  • У разi вiдкриття файлу клiєнтом вiн отримує атрибути, якi може кешувати з орендою. Сервер дозволяє клiєнту припинити оренду на пiдставi оголошення недiйсностi атрибутiв файлу. Фактично SFS подiбна до NFS версiї 4.



4.5. Робота клієнта

  • Процеси SFS є типовими процесами типу "клiєнт-сервер", але клiєнт SFS не може конфiгуруватись пiд конкретне мiсцеположення. Тобто клiєнт SFS не залежить вiд конкретного мiсцеположення користувача SFS, що дозволяє користувачу отримати доступ з довiльної точки земної кулi. Сервер SFS забезпечує доступ не клiєнтам, а користувачам.



4.6. Самосертифіковані імена

  • Унiкальним у SFS є пiдтримання глобального простору iмен з коренем у каталозi /sfs на основi самосертифiкованих iмен SSPN (self-sertifying path names), достатнiх для автентифiкацiї сервера SFS.



4.7. Структура системи SFS



4.8. Місцеположення файлів

  • Поле LOC у SSPN визначає мiсцеположення у виглядi iмен DNS сервера SFS. Кожен сервер S має вiдповiдний вiдкритий ключ Ks*. Частина HID є iдентифiкатором хоста (host), який обчислює хеш-функцiю H за мiсцеположенням сервера i його вiдкритим ключем:

  • HID = H(LOC, Ks*).



4.9. Місцеположення файлів (продовження)

  • Поле HID є числом з 32 цифр у системi з основою 32. Iм'я шляху утворено локальним iменем шляху сервера SFS, на якому мiститься файл. У системi вiдокремлено механiзми керування ключами вiд механiзмiв захисту файлової системи. Зокрема, можна зберiгати колекцiю ключiв локально адмiнiстратором системи. Тодi до сервера звертатись не потрiбно, оскiльки ключ знаходиться локально пiд час розв'язання iменi.



Питання заняття

  • Система CODA.

  • Система PLAN 9.

  • Файлова система xFS.

  • Захищена файлова система SFS.



Питання?

  • Розподілені інформаційні системи

  • www.simulation.kiev.ua/dis/



Схожі:

Лекція 10. Система coda та iншi розподiленi файловi системи Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 07. Розподілена система dcom діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Використовується переважно у ос windows, хоча була реалізована на декількох платформах
Лекція 10. Система coda та iншi розподiленi файловi системи Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 03. Програмне забезпечення проміжного рівня Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Концепції програмних рішень Основними програмними компонентами рiс є ос I системи промiжного рiвня
Лекція 10. Система coda та iншi розподiленi файловi системи Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 01. Структура І основні задачі створення розподілених систем Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Визначення розподіленої системи Розподілена система це комплекс незалежних комп'ютерів, які користувач сприймає як єдину об'єднану...
Лекція 10. Система coda та iншi розподiленi файловi системи Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 12. Моделi I системи узгодження Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Типи моделей узгоджень Системи узгодження передбачають вiддiлення обчислювальних процесiв вiд механiзмiв їх узгодження
Лекція 10. Система coda та iншi розподiленi файловi системи Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 11. Розподiленi системи документiв Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
За стандартизацiю протоколiв удосконалення мiжоперацiйної взаємодiї та удосконалення систем на основi World Wide Web (www) з 1994...
Лекція 10. Система coda та iншi розподiленi файловi системи Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 06. Промисловий стандарт corba діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Першi версiї специфiкацiї з'явились на початку 90-х рокiв. Поширеними є версiї 4 i 3
Лекція 10. Система coda та iншi розподiленi файловi системи Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 04. Зв'язок процесів на рівні протоколів Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Т. к. Ріс побудовані з використанням принципа відкритості, то використовуються стандартні протоколи обміну даними між процесами
Лекція 10. Система coda та iншi розподiленi файловi системи Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 09. Файлова система nfs діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Мережева файлова система nfs (Network File System) компанiї Sun Microsystems надає клiєнту набiр протоколiв подання розподiленої...
Лекція 10. Система coda та iншi розподiленi файловi системи Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 05. Зв'язок на основі повідомлень І потоків Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Зв'язок на основi повiдомлень Зв'язок на пiдставi повiдомлень дозволяє уникнути блокування клiєнта у процесi здiйснення операцiї,...
Лекція 10. Система coda та iншi розподiленi файловi системи Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України iconЛекція 15. Розподiлене пiдтвердження та вiдновлення процесiв Діденко Дмитро Георгійович Старший викладач кафедри ммса ннк «іпса» Національний технічний університет України
Розподiлене пiдтвердження (Distributed commit) являє собою бiльш загальне завдання порiвняно з атомарним груповим розсиланням i передбачає...

Додайте кнопку на своєму сайті:
dok.znaimo.com.ua


База даних захищена авторським правом ©dok.znaimo.com.ua 2013
звернутися до адміністрації
dok.znaimo.com.ua
Головна сторінка