Реплікація - студопедія
Розподілені системи часто забезпечують реплікацію (тиражування) файлів в якості однієї з послуг, що надаються клієнтам. Реплікація - це асинхронний перенесення змін даних вихідної файлової системи в файлові системи, що належать різним вузлам розподіленої файлової системи. Іншими словами, система оперує кількома копіями файлів, причому кожна копія знаходиться на окремому файловому сервері. Є кілька причин для надання цього сервісу, головними з яких є:
1. Збільшення надійності за рахунок наявності незалежних копій кожного файлу на різних файл-серверах.
2. Розподіл навантаження між декількома серверами.
Як завжди, ключовим питанням, пов'язаним з реплікацією є прозорість. До якої міри користувачі повинні бути в курсі того, що деякі файли реплікуються? Чи повинні вони грати будь-яку роль в процесі реплікації або реплікація повинна виконуватися повністю автоматично? В одних системах користувачі повністю залучені в цей процес, в інших система все робить без їх відома. В останньому випадку говорять, що система репликационная прозора.
На малюнку 3.12, б показаний альтернативний підхід - лінива реплікація. Тут створюється тільки одна копія кожного файлу на деякому сервері. Пізніше сервер сам автоматично виконає реплікації на інші сервери без участі програміста. Ця система повинна бути досить швидкою для того, щоб оновлювати всі ці копії, якщо буде потрібно.
Мал. 3.12. а) Точна реплікація файлу; б) Ледача реплікація файлу;
в) Реплікація файлу, яка використовує групу
Розглянемо, як можуть бути змінені існуючі реплікованих файли. Існує два добре відомих алгоритму вирішення цієї проблеми.
Перший алгоритм, званий "реплікація першої копії", вимагає, щоб один сервер був виділений як первинний. Решта сервери є вторинними. Коли реплицироваться файл модифікується, зміна посилається на первинний сервер, який виконує зміни локально, а потім посилає зміни на вторинні сервери.
Щоб запобігти ситуації, коли через відмову первинний сервер не встигає повідомити про зміни все вторинні сервери, зміни повинні бути збережені в постійному пристрої, що запам'ятовує ще до зміни первинної копії. У цьому випадку після перезавантаження сервера є можливість зробити перевірку, чи не проводилися якісь поновлення в момент краху. Недолік цього алгоритму типовий для централізованих систем - знижена надійність. Щоб уникнути його, використовується метод, запропонований Гіффорд і відомий як "голосування". Нехай є n копій, тоді зміни повинні бути внесені в будь-W копій. При цьому сервери, на яких зберігаються копії, повинні відстежувати порядкові номери їх версій. У разі, коли який-небудь сервер виконує операцію читання, він звертається із запитом до будь-яких R серверів. Якщо R + W> n, то, хоча б один сервер містить останню версію, яку можна визначити за максимальним номером.
Цікавою модифікацією цього алгоритму є алгоритм "голосування з привидами". У більшості додатків операції читання зустрічаються набагато частіше, ніж операції запису, тому R зазвичай роблять невеликим, а W - близьким до N. При цьому вихід з ладу кількох серверів призводить до відсутності кворуму для запису. Голосування з привидами вирішує цю проблему шляхом створення фіктивного сервера без дисків для кожного відмовив або відключеного сервера. Фіктивний сервер не бере участі в кворумі читання (перш за все, у нього немає файлів), але він може приєднатися до кворуму записи, причому він просто записує в нікуди передається йому файл. Запис тільки тоді успішна, коли хоча б один сервер справжній.
Коли відмовив сервер перезавантажується, то він повинен отримати кворум читання для виявлення останньої версії, яку він копіює до себе перед тим, як почати звичайні операції. В іншому цей алгоритм подібний до основного.
- Організація роботи в гетерогенних мережах.