Прозрачность: иллюзии единой системы. Часть 2

Предыдущие части: Часть 1

Одной из (множества) причин сложности распределенных систем является то, что они пытаются делать множество вещей одновременно. Распределенная система создает для конечного пользователя ощущение целостности. Однако для того, чтобы достичь этого, приходится учитывать множество нюансов.

В первой части серии мы начали разбираться с иллюзиями, которые распределенная система создает для пользователя. Если вкратце, то прозрачность распределения — это то, что позволяет распределенной системе, состоящей из множества автономных и независимых узлов, изображать роль единой системы. Существуют разные способы для достижения прозрачности системы. В первой части мы обсуждали три разновидности прозрачности: доступа, расположения и перемещения.

Давайте продолжим разбираться с остальными формами прозрачности!

Еще больше форм прозрачности

Прозрачность переноса

Мы уже познакомились с формой прозрачности под названием «прозрачность перемещения». Она позволяет распределенной системе перемещать свои ресурсы из узла А в узел В даже в момент обращения к ним пользователя. Возможен и такой вариант: пользователь обращается к ресурсу, ресурс переносится в новый узел, и уже оттуда этот пользователь вновь обращается к тому же ресурсу. Прозрачность переноса — это то, что реализует процесс перемещения ресурсов внутри системы, незаметно для потребителя ресурса (пользователя).

Прозрачность переноса можно расценивать как менее строгую версию прозрачности перемещения. В отличие от прозрачности перемещения, здесь мы предполагаем, что система не будет переносить ресурс, пока он потребляется пользователем.

При прозрачности переноса процесс перемещения ресурса из точки А в точку В может проходить по-разному. Ресурс может изменить свой физический адрес в системе. Поэтому все, что указывает на ресурс или ссылается на него, будет также изменяться в соответствие с новым местоположением. Прозрачность переноса обеспечивает перемещение ресурса в новое место внутри системы и его неизменную доступность для пользователя. При переносе ресурса ему не нужно задавать новое имя.

Прозрачность репликации

Возможность получения доступа, переноса и изменения расположения ресурса сопряжена с рядом рисков. Еще большая неопределенность возникает при наличие одного ресурса, к которому обращаются все пользователи системы!

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

При проектировании распределенной системы с прозрачностью репликации необходимо учитывать три составляющие: создание, поддерживаемость и доступность реплицированного ресурса.

Данные составляющие необходимо предусмотреть для реализации копий ресурса с их последующей доступностью и использованием. Это важно, потому как любая форма прозрачности — не более, чем иллюзия.

Создание нескольких копий ресурса требует определенных усилий и продуманности.

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

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

Если ресурсом является процесс, то эта прозрачность сделает так, чтобы другой (идентичный или реплицированный) процесс перешел в то же состояние, что и первый (недоступный), и продолжил выполнение заданной операции. По сути, реплицированный процесс — это отличный пример того, насколько важно поддерживать одинаковое состояние всех копий ресурса!

Есть и другой важный плюс прозрачности репликации — улучшенная производительность. Когда на сервере присутствует несколько копий данных, то пользователи, обращающиеся к этому ресурсу, быстрее получают доступ к достоверным данным. Это возможно благодаря тому, что пользователи не обращаются к одному общему ресурсу одновременно. Репликация рулит!

Прозрачность параллельного доступа

Совместное использование ресурсов является важной частью функционирования распределенной системы. Как мы уже знаем, прозрачность репликации создает и поддерживает несколько копий ресурса, из-за чего пользователи неосознанно «делятся» доступом к ресурсу. Но что произойдет в случае, если ресурс будет изменен или «перезаписан» пользователем (а не просто открыт или «прочтен» пользователем)? Или же вдруг что-то изменится в самом ресурсе в тот момент, когда к нему обращаются сразу несколько пользователей?

Прозрачность параллельного доступа (иногда ее еще называют прозрачность транзакций) позволяет нескольким пользователям распределенной системы «соперничать» за доступ к ресурсу и выполнять действия с файлом параллельно, без уведомления об этом других пользователей.

Обработать параллельные операции в распределенной системе куда сложнее, чем в единой, нераспределенной и центральной системе.

В единой системе один ресурс существует в одном месте, и «условия гонки» (когда два пользователя пытаются изменить один и тот же ресурс) сводятся к принципу живой очереди: «обратился первым — изменил ресурс!»). Истинного параллелизма не существует.

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

Крайне трудно поддерживать одинаковое состояние общего ресурса для пользователей и обрабатывать изменения в том же ресурсе в процессе обращения к нему. В мире распределенных систем алгоритмы управления параллельным доступом являются отдельной и объемной темой для изучения!

Прозрачность отказа

Наряду с большим количеством «подробностей» системы, которые необходимо скрыть от пользователей, есть нечто, неподвластное контролю — отказы в частях системы. Отказы возможны и в единой системе. А для распределенной системы с обилием движимых частей, работающих вместе, как единой целое, отказы — это суровая реальность.

Прозрачность отказа позволяет конечному пользователю распределенной системы продолжать работу с системой и обращаться к ресурсам, не замечая, что в части системы возникли ошибки. Отказы в распределенной системе называются сбоями.

Поскольку от сбоев в системе никуда не деться, мы, как разработчики распределенной системы, должны продумать все возможные отказы и способы их устранения. Зачастую бывает трудно «отловить» ошибки системы, поскольку они сопряжены не только с программными, но и аппаратными отказами!

Во многих случаях реализация прозрачности отказов сводится к отображению пользователю сообщения о приостановлении работы. Параллельно с этим система определяет, что именно пошло не так, находит причину сбоя и обрабатывает ошибку так, как было задумано разработчиком системы. Подобная реакция системы может вводить в заблуждение. Например, возникает отказ на сервере, а пользователь не знает о сбое в системе. Тогда он, скорее всего, решит, что не работает весь процесс, хотя на деле он просто приостановлен. Здесь пригодится прозрачность репликации — мы можем воспользоваться другой репликой ресурса, если первая копия окажется причиной отказа.

Прозрачность отказов распространена шире, чем мы думаем. И многие привычные нам распределенные системы рассчитаны на некоторое подмножество (потенциальных) сбоев в системе. Например, в системе управления базами данных заложен метод по обеспечению прозрачности отказов. Реализация прозрачности отказов — одна из самых сложных задач при разработке и поддержке распределенной системы.

Насколько прозрачными мы можем быть?

Рассмотрев основные формы прозрачности, мы поняли, почему реализация одних форм прозрачности проще, чем других. Бывает и так, что размер или масштаб системы не дает в полной мере реализовать прозрачность отказов или параллельного доступа. А количество сведений, которые нужно скрыть от пользователей, просто зашкаливает. Как же предусмотреть все нужные иллюзии при создании распределенной системы?!

В реальной жизни достичь полной прозрачности распределения и успешно реализовать прозрачность доступа, расположения, перемещения, переноса, репликации, параллельного доступа и сбоев в распределенной системе — невозможно.

На практике мы, как разработчики распределенной системы, сильно ограничены в своих возможностях! Иногда ни нам, ни пользователям не требуется поддержка иллюзии единой системы. Прозрачность — это сложная тема. Не стоит изводить себя, если не удается создать полную прозрачность . Помните, что в реальности достичь этого просто невозможно. Но лучше все-таки знать матчасть. Так будет легче понять, что именно вы захотите сделать прозрачным, а какие темные и мрачные части системы лучше скрыть.

Специально для сайта ITWORLD.UZ. Новость взята с сайта NOP::Nuances of programming