Э. Таненбаум, М. ван Стеен - Распределённые системы (принципы и парадигмы) (1162619), страница 66
Текст из файла (страница 66)
Запись в кэше становится неправильной, поскольку возвращаетнелокальный адрес, в то время как существует локальныйДругой оставшийся открытым вопрос — когда содержимое кэша перестает соответствовать действительности. Предположим, что пользователь из нашего примера получил столько заявок из Нью-Йорка, что решил открыть офис на Ман-4.2. Размещение мобильных сущностей255хэттене и поручил одному из своих приятелей отправлять все приходящие на егоимя запросы в район Нью-Йорка. В терминах службы локализации у него появился постоянный адрес в домене Манхеттен.
На все запросы на поиск из НьюЙорка должен возвращаться этот новый адрес, а не кэшированный указатель нанаправляющий узел Калифорнии, как показано на рис. 4.20.Проблемы масштабированияОдна из основных проблем иерархических служб локализации состоит в том, чтокорневой узел должен хранить локализующие записи и обрабатывать запросы ковсем сущностям. Объем хранимой информации сам по себе не является главнойпроблемой. Локализующая запись невелика, она состоит только из идентификатора сущности и одного или более указателей на направляющие узлы нижнегоуровня. Если размер каждой локализующей записи приблизительно составляет1 Кбайт, то для хранения, скажем, миллиарда сущностей необходим всего одинтерабайт.
Этот объем обеспечат десять дисков по 100 Гбайт.Настоящая проблема состоит в том, что без принятия специальных мер корневой узел должен будет обрабатывать такое количество запросов на поиск и обновление, что здесь неизбежно возникнет узкое место. Решение этой проблемысостоит в разбиении корневого узла и других направляющих узлов верхнегоуровня на вложенные узлы. Каждый вложенный узел будет отвечать за обработку запросов к определенному поднабору сущностей, поддерживаемых службойлокализации.К сожалению, просто разделить узлы верхнего уровня на части недостаточно.Чтобы продемонстрировать проблему масштабируемости, рассмотрим разбиениекорневого узла, скажем, на 100 вложенных узлов. Вопрос состоит в том, где будет находиться каждый из вложенных узлов в сети, охваченной службой локализации, физически.Одна из возможностей — расположить вложенные узлы в соответствии с централизованным подходом, недалеко друг от друга, например собрать их в кластер.
Действительно, корневой узел в этом случае реализуется посредством параллельного компьютера типа COW или МРР (с которыми мы познакомились вглаве 1). Однако несмотря на то, что вычислительной мощности в этом случаебудет достаточно, пропускной способности входящих и исходящих сетевых соединений для выполнения всех запросов может не хватить.Следовательно, более удачной альтернативой является равномерное распределение вложенных узлов по сети. Однако, если сделать это неправильно, подобный способ может привести к появлению проблемы масштабирования. Рассмотрим снова мобильного пользователя, перемещающегося в основном между СанФранциско и Лос-Анджелесом. Корневой узел разбит на вложенные узлы, и вопрос, который предстоит решить, — какой вложенный узел сделать ответственным за этого пользователя.Предположим, что для постоянного хранения локализующих записей данного пользователя выбран вложенный узел, находящийся в Финляндии.
Опускаякэширование указателей, это будет означать, что запрос, например, из Бразилии,перед тем как он будет передан на направляющий узел в Калифорнии, должен256Глава 4. Именованиепройти через корневой узел в Финляндии. Однако, как показано на рис. 4.21, разумней было бы пропустить запрос через вложенный узел, расположенный, например, в Калифорнии.
Вопрос о том, какому вложенному узлу за какую сущность отвечать, для крупномасштабных служб локализации остается открытым.Домен, в которомв настоящее времянаходится сущность ЕгЛ3Вложенный узел корневого узлаГотвечающий за обработкузапросов для сущности ЕТекущий маршрут^ с==.^V^запроса на поиск^v^^ у чАльтернативныймаршрутзапросана поискКлиент, запросивший текущий адрес сущности Е^j'Рис. 4 . 2 1 . Иллюстрация проблем масштабирования, связанных с задачей равномерногораспределения вложенных узлов разделенного корневого узлаВозможным решением было бы использовать то местоположение, в которомбыла создана сущность Е, В частности, вложенный узел корневого узла, расположенный неподалеку от места, где была создана сущность £, может быть назначенответственным за обработку относящихся к Е запросов корневого уровня.
Эторешение срабатывает для сущностей, которые имеют тенденцию находиться неподалеку от места, где они были созданы. Однако если сущность перемещаетсяв отдаленное место, проблема остается. Детальное описание этого подхода можно найти в [31].4.3. Удаление сущностей,на которые нет ссылокСлужбы именования и локализации предоставляют глобальные службы ссылокна сущности. До тех пор пока в службе имеются ссылки на сущность, эта сущность доступна пользователям и может использоваться. После того как доступк сущности прекращается, ее следует удалить.Во многих системах удаление сущностей реализуется явным образом.
Например, если процесс Р знает, что он — последний из процессов, использующих не-4.3. Удаление сущностей, на которые нет ссылок257который файл, причем в будущем этот файл ни одному процессу не понадобится, Р может при своем завершении удалить этот файл. К сожалению, управлениеудалением сущностей в распределенных системах обычно сложнее. Так, в частности, нередко неизвестно, где в системе были созданы ссылки на удаляемуюсущность с намерением воспользоваться ими позднее для доступа к ней. Есливпоследствии к удаленной сущности действительно произойдет попытка доступа с помощью одной из таких ссылок, это приведет к ошибке.С другой стороны, недопустимо также вообще не удалять сущность простоиз-за отсутствия гарантий, что на нее не существует ссылок.
Если ссылок все жене существует, мы окажемся в ситуации, когда сущность, которая продолжает потреблять ресурсы, никогда не будет использоваться. Понятно, что эта сущность —просто мусор и ее следует удалить.Для снижения остроты проблем, связанных с удалением сущностей, на которые нет ссылок, распределенные системы могут предоставить механизмы их автоматического удаления. Эти механизмы известны под общим названием распределенных сборщиков мусора {distributed garbage collectors). В этом разделе мыпоближе познакомимся с взаимоотношениями сущностей именования и локализации, а также с автоматической уборкой «ничейных» сущностей.4 . 3 . 1 .
Проблема объектов, на которые нет ссылокЧтобы понять, как производится уборка мусора, сосредоточимся на уборке распределенных объектов, в частности удаленных объектов. Напомним, что удаленный объект реализуется так, что его состояние целиком находится на сервереобъектов, а клиент работает исключительно с заместителем. Как мы узнали в разделе 2.3, ссылка на удаленный объект обычно реализуется парой (заместитель,скелетон).
Заместитель клиента содержит всю информацию, необходимую дляработы с объектом через связанный с ним скелетон, реализованный на сервере.В наших примерах скелетон принимает участие в администрировании, необходимом для сборки мусора, вместе с заместителем. Другими словами, все что необходимо сделать для сборки мусора, скрыто как от пользователя, так и от самого объекта. Отметим, что и сам объект может содержать удаленные ссылки на другиеобъекты, например локальные ссылки на заместители этих объектов.
Точно также удаленные ссылки могут передаваться другим процессам путем копированиязаместителя, связанного с процессом, в другой процесс.Из этого следует, что к объекту можно получить доступ, только если у насесть удаленная ссылка на него. Объект, на который отсутствуют удаленные ссылки, можно удалять из системы. С другой стороны, наличие удаленных ссылок неозначает, что объект будет доступным всегда. По различным причинам возможно возникновение двух объектов, ссылающихся друг на друга и не имеющих других ссылок. Эта ситуация может быть легко обобщена на цепочку объектов, каждый из которых ссылается на соседа.
Подобные объекты также следует выявлятьи удалять.В общем виде модель ссылок на объекты может быть представлена в виде графа, каждый узел которого — это объект. Ребро, идущее от узла М к узлу N, отра-258Глава 4. Именованиежает тот факт, что объект М содержит ссылку на объект N.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
