Электронный коспект лекций (1162752), страница 6

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 6)

Что происходит, если два процесса одновременноработали с одним файлом - либо результат будет определятьсяпроцессом, последним закрывшим файл, либо можно толькоутверждать, что один из двух вариантов файла станет текущим.Транзакции.Процесс выдает операцию «НАЧАЛО ТРАНЗАКЦИИ», сообщаятем самым, что последующие операции должны выполняться безвмешательствадругихпроцессов.Затемвыдаетпоследовательностьчтенийизаписей, заканчивающуюсяоперацией«КОНЕЦТРАНЗАКЦИИ».Еслинесколькотранзакций стартуют в одно и то же время, то система гарантирует,что результат будет таким, каким бы он был в случаепоследовательного выполнения транзакций (в неопределенномпорядке).

Пример - банковские операции.5.2Реализация распределенных файловых систем.Выше были рассмотрены аспекты распределенных файловыхсистем, которые видны пользователю. Ниже рассматриваютсяреализационные аспекты.5.2.1Использование файлов.Приступая к реализации очень важно понимать, как система будетиспользоваться. Приведем результаты некоторых исследованийиспользования файлов (статических и динамических) вуниверситетах. Очень важно оценивать представительностьисследуемых данных.a) большинство файлов имеют размер менее 10К. (Следуетперекачивать целиком).b) чтение встречается гораздо чаще записи. (Кэширование).c) чтение и запись последовательны, произвольный доступ редок.(Упреждающее кэширование, чтение с запасом, выталкиваниепосле записи следует группировать).d) большинство файлов имеют короткое время жизни.

(Создаватьфайл в клиенте и держать его там до уничтожения).e) мало файлов разделяются (кэширование в клиенте и семантикасессий).f) существуют различные классы файлов с разными свойствами.(Следует иметь в системе разные механизмы для разных классов).5.2.2Структура системы.Есть ли разница между клиентами и серверами? Имеютсясистемы, где все машины имеют одно и то же ПО и любая машинаможет предоставлять файловый сервис.

Есть системы, в которыхсерверы являются обычными пользовательскими процессами имогут быть сконфигурированы для работы на одной машине склиентами или на разных. Есть системы, в которых клиенты исерверы являются фундаментально разными машинами с точкизрения аппаратуры или ПО (требуют различных ОС, например).Второй вопрос - должны ли быть файловый сервер и сервердиректорий отдельными серверами или быть объединенными водин сервер. Разделение позволяет иметь разные серверыдиректорий (UNIX, MS-DOS) и один файловый сервер.Объединение позволяет сократить коммуникационные издержки.В случае разделения серверов и при наличии разных серверовдиректорий для различных поддеревьев возникает следующаяпроблема. Если первый вызванный сервер будет поочереднообращаться ко всем следующим, то возникают большиекоммуникационные расходы.

Если же первый сервер передаетостаток имени второму, а тот третьему, и т.д., то это не позволяетиспользовать RPC.Возможный выход - использование кэша подсказок. Однако в этомслучае при получении от сервера директорий устаревшегодвоичного имени клиент должен быть готов получить отказ отфайлового сервера и повторно обращаться к серверу директорий(клиент может не быть конечным пользователем!).Последний важный вопрос - должны ли серверы хранитьинформацию о клиентах.Серверы с состоянием.

Достоинства.a) Короче сообщения (двоичные имена используют таблицуоткрытых файлов).b) выше эффективность (информация об открытых файлах можетхраниться в оперативной памяти).c) блоки информации могут читаться с упреждением.d) убедиться в достоверности запроса легче, если есть состояние(например, хранить номер последнего запроса).e) возможна операция захвата файла.Серверы без состояния. Достоинства.a) устойчивость к ошибкам.b)c)d)e)не требуется операций ОТКРЫТЬ/ЗАКРЫТЬ.не требуется память для таблиц.нет ограничений на число открытых файлов.нет проблем при крахе клиента.5.2.3Кэширование.В системе клиент-сервер с памятью и дисками есть четырепотенциальных места для хранения файлов или их частей.Во-первых, хранение файлов на дисках сервера.

Нет проблемыконсистентности, так как только одна копия файла существует.Главная проблема - эффективность, поскольку для обмена сфайлом требуется передача информации в обе стороны и обмен сдиском.Во-вторых, кэширование в памяти сервера. Две проблемы помещать в кэш файлы целиком или блоки диска, и какосуществлять выталкивание из кэша.Коммуникационные издержки остаются.Избавиться от коммуникаций позволяет кэширование в машинеклиента.В третьих, кэширование на диске клиента.

Оно может не датьпреимуществ перед кэшированием в памяти сервера, а сложностьповышается значительно.Поэтому рассмотрим подробнее четвертый вариант - организациюкэширования в памяти клиента. При этом имеется три различныхспособа:a) кэширование в каждом процессе. (Хорошо, если c файломактивно работает один процесс - многократно открывает изакрывает файл, читает и пишет, например в случае процессабазы данных).b) кэширование в ядре.

(Накладные расходы на обращение к ядру).c) кэш-менеджеросвобождаетсявотвидеотдельногофункций файловойпроцесса.(Ядросистемы, но напользовательском уровне трудно эффективно использоватьпамять, особенно в случае виртуальной памяти. Возможнафиксация страниц, чтобы избежать обменов с диском).Оценить выбор того или иного способа можно только при учетехарактера приложений и данных о быстродействии процессоров,памятей, дисков и сети.Консистентность кэшей.Кэширование в клиенте создает серьезную проблему - сложностьподдержания кэшей в согласованном состоянии.Алгоритм со сквозной записью.Этот алгоритм, при котором модифицируемые данные пишутся вкэш и сразу же посылаются серверу, не является решениемпроблемы.

При его использовании в мультипроцессорах все кэши“подслушивали” шину, через которую там осуществляются все“сквозные” записи в память, и сразу же обновляли находящиеся вних данные. В распределенной системе такое “подслушивание”невозможно, а требуется перед использованием данных из кэшапроверять, не устарела ли информация в кэше. Кроме того, записьвызывает коммуникационные расходы.Алгоритм сотложеннойзаписью. Через регулярныепромежутки времени все модифицированные блоки пишутся вфайл (так на традиционных ЭВМ работает OC UNIX).Эффективность выше, но семантика непонятна пользователю.Алгоритм записи в файл при закрытии файла.

Реализуетсемантику сессий. Такой алгоритм, на первый взгляд, кажетсяочень неудачным для ситуаций, когда несколько процессоводновременно открыли один файл и модифицировали его. Однако,аналогичная картина происходит и на традиционной ЭВМ, когдадва процесса на одной ЭВМ открывают файл, читают его,модифицируют в своей памяти и пишут назад в файл.Алгоритм централизованного управления. Можно выдержатьсемантику UNIX, но не эффективно, ненадежно, и плохомасштабируется.5.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 - архитектура, протоколы и реализация.Архитектура NFS.Позволяет иметь произвольное множество клиентов и серверов напроизвольных ЭВМ локальной или широкомасштабной сети.Каждый сервер экспортирует некоторое число своих директорийдля доступа к ним удаленных клиентов.

Характеристики

Список файлов лекций