В.А. Крюков - Операционные системы распределенных вычислительных систем (1158860), страница 7
Текст из файла (страница 7)
При этом имеется три различных способа:a) кэширование в каждом процессе. (Хорошо, если c файлом активно работает один процесс многократно открывает и закрывает файл, читает и пишет, например в случае процессабазы данных).b) кэширование в ядре. (Накладные расходы на обращение к ядру).c) кэш-менеджер в виде отдельного процесса. (Ядро освобождается от функций файловойсистемы, но на пользовательском уровне трудно эффективно использовать память,особенно в случае виртуальной памяти.
Возможна фиксация страниц, чтобы избежатьобменов с диском).Оценить выбор того или иного способа можно только при учете характера приложений иданных о быстродействии процессоров, памятей, дисков и сети.Консистентность кэшей.Кэширование в клиенте создает серьезную проблему - сложность поддержания кэшейсогласованном состоянии.вАлгоритм со сквозной записью.Этот алгоритм, при котором модифицируемые данные пишутся в кэш и сразу же посылаютсясерверу, не является решением проблемы.
При его использовании в мультипроцессорах всекэши “подслушивали” шину, через которую там осуществляются все “сквозные” записи впамять, и сразу же обновляли находящиеся в них данные. В распределенной системе такое“подслушивание” невозможно, а требуется перед использованием данных из кэша проверять,не устарела ли информация в кэше. Кроме того, запись вызывает коммуникационные расходы.Алгоритм сотложеннойзаписью. Через регулярные промежутки времени всемодифицированные блоки пишутся в файл (так на традиционных ЭВМ работает OC UNIX).Эффективность выше, но семантика непонятна пользователю.Алгоритм записи в файл при закрытии файла. Реализует семантику сессий.
Такойалгоритм, на первый взгляд, кажется очень неудачным для ситуаций, когда несколькопроцессов одновременно открыли один файл и модифицировали его. Однако, аналогичнаякартина происходит и на традиционной ЭВМ, когда два процесса на одной ЭВМ открываютфайл, читают его, модифицируют в своей памяти и пишут назад в файл.Алгоритм централизованного управления. Можно выдержать семантику UNIX, но неэффективно, ненадежно, и плохо масштабируется.285.2.4Размножение.Система может предоставлять такой сервис, как поддержание для указанных файловнескольких копий на различных серверах. Главные цели:1) Повысить надежность.2) Повысить доступность (крах одного сервера не вызывает недоступность размноженныхфайлов).3) Распределить нагрузку на несколько серверов.Имеются три схемы реализации размножения:a) Явное размножение (непрозрачно).
В ответ на открытие файла пользователю выдаютсянесколько двоичных имен, которые он должен использовать для явного дублированияопераций с файлами.b) «Ленивое» размножение. Сначала копия создается на одном сервере, а затем он самавтоматически создает (в свободное время) дополнительные копии и обеспечивает ихподдержание.c) Симметричное размножение. Все операции одновременно вызываются в несколькихсерверах и одновременно выполняются.Протоколы коррекции.Просто посылка сообщений с операцией коррекции каждой копии является не оченьхорошим решением, поскольку в случае аварий некоторые копии могут остаться нескорректированными.
Имеются два алгоритма, которые решают эту проблему.(1)Метод размножения главной копии. Один сервер объявляется главным, а остальные подчиненными. Все изменения файла посылаются главному серверу. Он сначалакорректирует свою локальную копию, а затем рассылает подчиненным серверамуказания о коррекции.
Чтение файла может выполнять любой сервер. Для защиты отрассогласования копий в случае краха главного сервера до завершения им рассылки всехуказаний о коррекции, главный сервер до выполнения коррекции своей копиизапоминает в стабильной памяти задание на коррекцию. Слабость - выход из строяглавного сервера не позволяет выполнять коррекции.(2)Метод одновременной коррекции всех копий. Все изменения файла посылаются(используя надежные и неделимые широковещательные рассылки) всем серверам.Чтение файла может выполнять любой сервер.(3)Метод голосования. Идея - запрашивать чтение и запись файла у многих серверов(запись - у всех!). Для успешного выполнения записи требуется, чтобы Nw серверов еевыполнили.
При этом у всех этих серверов должно быть согласие относительно номератекущей версии файла. Этот номер увеличивается на единицу с каждой коррекциейфайла. Для выполнения чтения достаточно обратиться к Nr серверам и воспользоватьсяодним из тех, кто имеет последнюю версию файла. Значения для кворума чтения (Nr) икворума записи (Nw) должны удовлетворять соотношению Nr+Nw>N. Поскольку чтениеявляется более частой операцией, то естественно взять Nr=1. Однако в этом случае длякворума записи потребуются все серверы.5.2.5Пример: Sun Microsystem’s Network File System (NFS).Изначально реализована Sun Microsystem в 1985 году для использования на своих рабочихстанций на базе UNIX.
В настоящее время поддерживается также другими фирмами для UNIXи других ОС (включая MS-DOS). Интересны следующие аспекты NFS - архитектура,протоколы и реализация.29Архитектура NFS.Позволяет иметь произвольное множество клиентов и серверов на произвольных ЭВМлокальной или широкомасштабной сети.Каждый сервер экспортирует некоторое число своих директорий для доступа к ним удаленныхклиентов.
При этом экспортируются директории со всеми своими поддиректориями, т.е.фактически поддеревья. Список экспортируемых директорий хранится в специальном файле,что позволяет при загрузке сервера автоматически их экспортировать.Клиент получает доступ к экспортированным директориям путем их монтирования. Есликлиент не имеет дисков, то может монтировать директории в свою корневую директорию.Если несколько клиентов одновременно смонтировали одну и ту же директорию, то они могутразделять файлы в общей директории без каких либо дополнительных усилий.
Простота достоинство NFS.Протоколы NFS.Поскольку одна из целей NFS - поддержка гетерогенных систем, клиенты и серверы могутработать на разных ЭВМ с различной архитектурой и различными ОС. Поэтомунеобходимо иметь строгие протоколы их взаимодействия. NFS имеет два таких протокола.Первый протокол поддерживает монтирование. Клиент может послать серверу составное имядиректории (имя пути) и попросить разрешения на ее монтирование.
Куда будет монтироватьдиректорию клиент для сервера значения не имеет и поэтому не сообщается ему. Если путьзадан корректно и директория определена как экспортируемая, то сервер возвращает клиентудескриптор директории. Дескриптор содержит поля, уникально идентифицирующие тип ЭВМ,диск, номер i-вершины (понятие ОС UNIX) для данной директории, а также информацию оправах доступа к ней. Этот дескриптор используется клиентом в последующих операциях сдиректорией.Многие клиенты монтируют требуемые удаленные директории автоматически призапуске (используя командную процедуру shell-интерпретатора ОС UNIX).Версия ОС UNIX, разработанная Sun (Solaris), имеет свой специальный режимавтоматического монтирования.
С каждой локальной директорией можно связать множествоудаленных директорий. Когда открывается файл, отсутствующий в локальной директории,ОС посылает запросы всем серверам (владеющим указанными директориями). Кто ответитпервым, директория того и будет смонтирована. Такой подход обеспечивает и надежность,и эффективность (кто свободнее, тот раньше и ответит). При этом подразумевается, что всеальтернативные директории идентичны. Поскольку NFS не поддерживает размножениефайлов или директорий, то такой режим автоматического монтирования в основномиспользуется для директорий с кодами программ или других редко изменяемых файлов.Второй протокол - для доступа к директориям и файлам.
Клиенты посылают сообщения,чтобы манипулировать директориями, читать и писать файлы. Можно получить атрибутыфайла. Поддерживается большинство системных вызовов ОС UNIX, исключая OPEN иCLOSE. Для получения дескриптора файла по его символическому имени используетсяоперация LOOKUP, отличающаяся от открытия файла тем, что никаких внутренних таблиц несоздается. Таким образом, серверы в NFS не имеют состояния (stateless). Поэтому для захватафайла используется специальный механизм.NFS использует механизм защиты UNIX.
В первых версиях все запросы содержалиидентификатор пользователя и его группы (для проверки прав доступа). Несколько летэксплуатации системы показали слабость такого подхода. Теперь используетсякриптографический механизм с открытыми ключами для проверки законности каждогозапроса и ответа. Данные не шифруются.30Все ключи, используемые для контроля доступа, поддерживаются специальным сервисом (исерверами) - сетевым информационным сервисом (NIS). Храня пары (ключ, значение), сервисобеспечивает выдачу значения кода при правильном подтверждении ключей.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
