Деревянко_БС ЭВМ

ственным отличием является обращение к удаленным файлам вместо локальных.

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

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

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

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

91

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

Клиентский компьютер при этом выполняет все функции, специфические для данного приложения, а сервер — функции, реализация которых не зависит от специфики приложения, из-за чего эти функции могут быть оформлены в виде сетевых служб. Поскольку функции управления базами данных нужны далеко не всем приложениям, то в отличие от файловой системы они чаще всего не реализуются в виде службы сетевой ОС, а являются независимой распределенной прикладной системой. Система управления базами данных (СУБД) является одним из наиболее распространённых распределенных приложений.

Рис. 2.3. Двухзвенная модель с равномерным распределением функций между клиентской и серверной частями

Трехзвенные схемы

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

92

при которой на клиентской машине выполняются средства представления и логика представления, а также поддерживается программный интерфейс для вызова частей приложения второго звена — промежуточного сервера (рис. 2.4).

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

Рис. 2.4. Трехзвенная схема

Сервер баз данных, как и в двухзвенной модели, выполняет функции двух последних слоев — операции внутри базы данных и файловые операции.

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

93

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

са и управления базами данных.

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

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

2.1.3. Облачные вычисления

Облачные вычисления (cloud computing) — это технология распределённой обработки данных, которая компьютерные ресурсы и мощности предоставляет пользователю как ин- тернет-сервисы. Этот термин появился как следствие графического обозначения Интернета в виде облака.

Национальный институт стандартов и технологий CША (NIST) определил облачные вычисления следующим образом.

94

Облачные вычисления – это модель обеспечения удобного повсеместного сетевого доступа по требованию к совместно используемому пулу конфигурируемых вычислительных ресурсов, которые можно быстро предоставить и внедрить с минимумом административных усилий или взаимодействия с сер- вис-провайдером.

Пять основных характеристик: самообслуживание по требованию, широкий сетевой доступ, пул ресурсов, возможность быстрой перенастройки или расширения (в любом количестве в любое время) и измеряемое обслуживание. Три сервисных модели – программа (SaaS), платформа (PaaS) и инфраструктура (IaaS) в виде сервиса. Четыре модели внедрения – частная (для одной организации), публичная, общественная и гибридная Общественная – «облачная инфраструктура для использования ограниченным сообществом потребителей из организаций, имеющих общие интересы».

Инфраструктура как сервис (Infrastructure as a Service,

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

Платформа как сервис (Platform as a Service, PaaS) –

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

95

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

Программное обеспечение как сервис (Software as a Service, сокр. SaaS) – подразумевает предоставление приложений для конечного пользователя в виде сервиса «по требованию» вместо его установки на конкретном рабочем месте или на собственном сервере. То есть предприятие обходится без программистов.

Разработчики предоставляют и другие форматы (модели) облачных платформ:

«хранилище данных как услуга» (Storage-as-a- Service),

«база данных как услуга» (Database-as-a-Service, DaaS),

«информация как услуга» (Information-as-a-Service),

«вычислительный процесс как услуга» (Process-as-a- Service),

«средства безопасности как услуга» (Security-as-a- Service),

«отладка как услуга» (Testing-as-a-Service, TaaS) и

другие...

96

Экономические аспекты

1.По затратам на сетевую инфраструктуру, хранение данных и администрирование крупные дата-центры (десятки тысяч серверов) дают 5-7-кратную экономию по равнению с серверными площадками среднего размера (тысячи серверов).

2.Крупные дата-центры меньше зависят от неравномерной нагрузки, вызванной суточным, годовым и отраслевым дисбалансом.

3.Построение крупного ЦОД в США на 50 000 серверов требует около $200 млн., поэтому совершенной конкуренции на этом рынке ожидать не приходится.

Безопасность в облаках

Проработка вопросов безопасности в облаках ведётся по следующим направлениям.

Безопасность нахождения данных в облачных хранилищах — построение зон для SAN-хранилищ и их разметка (mapping), применение средств принудительной очистки физических разделов памяти, которые были задействованы для передачи информации между гетерогенными средами; аутентификация на уровне файловой системы. Для построения облачного хостинга рекомендуется применять шифрование для устройств хранения, а также шифрование на уровне файловой системы.

Безопасность на этапе исполнения заданий — развитие средств изоляции ВМ и ОС.

Безопасность на этапе передачи данных — SSL, VLAN,

VPN.

Безопасность доступа к данным — аутентификация при создании VPN и на уровне применяемой ОС, авторизация пользователей.

97

Юридические вопросы

Юридические аспекты реальной эксплуатации «облачных» ИТ-сервисов требуют глубокой проработки. Важно получить ответы на следующие вопросы:

каковы обязательства поставщика SaaS по отношению к пользовательским данным?

отличаются ли они от обязательств поставщика IaaS, который не осуществляет обработку данных, а просто предоставляют вычислительную площадку?

каковы могут быть юридические последствия в том случае, если поставщики SaaS/PaaS/IaaS-услуг находятся в разных юрисдикциях?

какие права правохранительные органы имеют в отношении данных пользователей из других стран?

насколько пользователи свободны выносить свои данные за пределы своего государства?

что делать с персональными данными (ПД)? Считается ли передача в «облака» таких информационных массивов передачей ПД третьему лицу?

чем и как провайдер отвечает перед компаниейклиентом?

если клиентов сотни и все они одновременно предъявляют финансовые претензии к провайдеру?

98

2.2.Сетевые службы

2.2.1.Сетевые файловые системы

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

Файловая служба имеет две функционально различные части: собственно файловую службу и службу каталогов файловой системы (ФС). Первая имеет дело с операциями над отдельными файлами, такими как чтение, запись или добавление, а вторая — с созданием каталогов и управлением ими, добавлением и удалением файлов из каталогов и т. п.

Клиент сетевой ФС передает по сети запросы серверу сетевой ФС. Сервер, получив запрос, может выполнить его либо самостоятельно, либо передать запрос локальной файловой системе для отработки. После получения ответа от локальной файловой системы сервер передает его по сети клиенту, а тот, в свою очередь, — приложению, обратившемуся с запросом.

Клиент и сервер взаимодействуют по определенному протоколу (например, RPC). В ОС Windows основой сетевой файловой службы является протокол SMB (Server Message Block), который был совместно разработан компаниями Microsoft, Intel и IBM (его последние версии получили название

Common Internet File System, CIFS). Он построен на базе FAT и

относится к классу протоколов, ориентированных на соединение. Как и все протоколы файловых служб, этот протокол работает на прикладном уровне модели OSI.

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

99

сколько возможных ситуаций.

Отказ компьютера, на котором выполняется сервер сетевой файловой системы, во время сеанса связи с клиентом.

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

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

Потери данных и разрушение целостности файловой системы при сбоях и отказах серверных компьютеров. Для повышения отказоустойчивости файловой системы можно хранить копии файлов (или копии локальной файловой системы), причем каждую копию — на отдельном компьютере. Такие копии файлов называются репликами. Репликация файлов повышает отказоустойчивость и повышает производительность системы, так как запросы к файлам распределяются между несколькими серверами. Основным отличием репликации от кэширования является то, что реплики хранят файловые серверы, а кэшированные файлы - клиенты.

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

100