Розміщення мобільних сутностей
Служби імен, які обговорювалися, використовуються в першу чергу для іменованих сутностей, які мають постійне місце розташування. По своїй природі традиційні системи іменування погано підходять для підтримки відображення імені на адресу, якщо той регулярно змінюється, як це відбувається у випадку мобільних сутностей.
Іменування й локалізація сутностей
Сутності йменуються для того, щоб мати можливість їх знайти й одержати до нихдоступ.Виділяють три типи імен:імена, зручні для сприйняття,ідентифікаторийадреси. Оскільки розподілені системи будуються для людей і для доступу до сутності, необхідно знатиадресу сутності, фактично всі системи іменування підтримують відображення зручних для сприйняттяімен в адреси.
Для ефективної реалізації повномасштабного простору імен, такого як в DNS, зручно розбити простір імен на три рівні: глобальний, адміністративний та управлінський.Глобальний і адміністративний рівні характеризуються тим, щоімена змінюються нечасто. Точніше, вміст вузлів цих частин простору іменвідносно постійний. Внаслідок цього реплікація йкешируванняздатніпідвищити ефективність реалізації.
Вміст вузлів управлінськогорівнячасто змінюється. Томупродуктивність операцій пошуку й відновленняна цьому рівні стає особливо важливою. На практиці вимоги попродуктивностіможна задовольнити шляхомреалізації вузлів на локальних високопродуктивних серверах імен.
Приклад.
Розглянемо тепер ближче, яке допущення варто зробити насправді і як подібний підхід можна використовувати для реалізації великомасштабної системи іменування. Насамперед розглянемо пошук адреси віддаленого хоста ftp.cs.vu.nl. Якщо вважати вміст вузлів глобального й адміністративного рівнів стабільним, клієнт, імовірно, зможе знайти адресу сервера імен домена cs.vu.nl у локальному кеші. Відповідно, йому знадобиться всього один запит до сервера імен, щоб знайти адресу ftp.cs.vu.nl.
Розглянемо далі зміну адреси ftp.cs.vu.nl, наприклад, через перенос FTP-сервера на іншу машину. Доти доки сервер буде залишатися на машині, що входить у домен cs.vu.nl, відновлення можна виконати швидко. У цьому випадку зміні піддасться тільки база даних DNS сервера імен cs.vu.nl. Пошук буде настільки ж ефективний, як і раніше.
Відповідно, у тому випадку, якщо вузли глобального й адміністративного рівнів змінюються рідко, а зміни звичайно обмежуються одним сервером імен, системи іменування, такі як DNS, досить ефективні.
Приклад.
Подивимося тепер, що відбудеться, якщо сервер ftp.cs.vu.nl перенести на машину з іменем ftp.cs.umsa.edu.au, яка знаходиться в абсолютно іншому домені. Перше, на що варто звернути увагу, – ім'я ftp.cs.vu.nl краще було б не міняти, оскільки багато прикладних програм і користувачів могли мати на нього лише символічне посилання. Інакше кажучи, це ім'я приблизно використовується як ідентифікатор. Його зміна зробить всі посилання на нього невірними.
Існує два основних рішення:
Перше рішення – записати адресу нової машини в базі даних DNS для cs.vu.nl.
Друге рішення – записати ім'я нової машини, а не її адресу, включивши fip.cs.vu.nl у символічне посилання. Обидва рішення мають серйозні недоліки.
Спочатку розглянемо запис адреси нової машини (перший підхід). Ясно, що на операцію пошуку подібний підхід не вплине. Однак якщо сервер ftp.cs.vu.nl доведеться ще раз переносити на нову машину, доведеться обновляти і його елемент бази даних DNS в cs.vu.nl. Важливо відзначити, що саме по собі обновлення виконується не довше локальної операції, однак у реальності може потребувати сотень міллісекунд. Недолік, подібний підхід порушує припущення про те, що операції у вузлах управлінського рівня ефективні.
Основний недолік використання символічних посилань (другий підхід) полягає в тому, що губиться ефективність операцій пошуку. Кожна операція пошуку виконується за два кроки:
пошук імені нової машини;
пошук адреси, що відповідає цьому імені.
Якщо сервер ftp.cs.vu.nl знову переміститься, скажемо, на адресу ftp.cs.berke-ley.edu, можна здійснити операцію локального відновлення, помістивши ім'я ftp.cs.unisa.edu.au у символічне посилання на ftp.cs.berkeley.edu і зберігши для cs.vu.nl елемент у базі даних DNS таким, як він є. Недолік – додавання ще одного кроку до операції пошуку.
Для сутностей з високою мобільністю ситуація може бути тільки гірше. Щораз при переносі сутності або доводиться виконувати нелокальну операцію внесення змін, або додається ще один крок до операції пошуку.
Інша серйозна проблема розглянутих підходів полягає в тому, що ім'ятаке як, наприклад,ftp.cs.vu.nlне повинне змінюватися. Таким чином, стає надзвичайно важливим вибирати імена, які (приблизно) не доведеться міняти протягом усього часу існування тієї сутності, яку вони ідентифікують. Більше того, таке ім'я не можна використовувати для яких-небудь інших сутностей. На практиці підбор подібних імен, особливо для довгоживучих сутностей утруднений, що демонструє система іменування в World Wide Web. Багато сайтів відомі під різними іменами і всі ці імена залишаються правильними, тобто завжди посилаються на ту саму сутність, навіть у випадку мобільності.
Із цих причин традиційні служби імен, такі як DNS, не справляються з мобільними сутностями. Тут необхідне інше рішення. По суті, проблеми пов'язані з тим, що традиційні служби іменування підтримують пряме відображеннязручних для сприйняття людиною імен в адреси сутностей. Щоразу, колиім'я або адреса змінюються, доводитьсязмінювати й відображення, як показано на рис. 5.6а.
Рис. 5.6 Пряме однорівневе відображення імен в адреси (а). Дворівневе відображення з використанням ідентифікаторів (б)
Найкраще рішення полягає в тому, щоб відокремити іменування сутностей від їхнього розміщення, увівши ідентифікатори, як показано на рис. 5.6б. Нагадаємо, що ідентифікатори ніколи не змінюються,кожна сутність має тільки один ідентифікатор, іідентифікатор не може бути призначений іншій сутності.У загальному випадку ідентифікатор не призначений для сприйняття людиною. Інакше кажучи, він оптимізований винятково для машинної обробки.
При пошуку сутності засобами служби іменування вона повертає ідентифікатор. Ідентифікатор може бути збережений на локальній машині на будь-який необхідний термін, оскільки він не може а ні почати вказувати на іншу сутність, а ні змінитися. Під яким іменем він збережений, не важливо. Відповідно, коли цей ідентифікатор буде потрібен знову, його можна буде просто взяти з локальної машини, не звертаючись до пошуку засобами служби іменування.
Розміщення сутностівизначається за допомогою окремоїслужби локалізації (location service).Служба локалізаціївикористовує в якості вихідних данихідентифікаторі повертаєпоточну адресувідповідної йому сутності. Якщо є кілька копій сутності, буде повернуто кілька адрес. Зосередимося винятково на проблемі реалізації ефективної служби локалізації.