Файл: Шпора.docx

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

[править] Инфраструктура как услуга

Основная статья:IaaS

Инфраструктура как услуга(IaaS,англ.IaaS or Infrastructure-as-a-Service) предоставляется как возможность использования облачной инфраструктуры для самостоятельного управления ресурсами обработки, хранения, сетей и другими фундаментальными вычислительными ресурсами, например потребитель может устанавливать и запускать произвольное программное обеспечение, которое может включать в себяоперационные системы, платформенное и прикладное программное обеспечение. Потребитель может контролировать операционные системы, виртуальные системы хранения данных и установленные приложения, а также ограниченный контроль набора доступных сервисов (например,межсетевой экран,DNS). Контроль и управление основной физической и виртуальной инфраструктурой облака, в том числе сети, серверов, типов используемых операционных систем, систем хранения осуществляется облачным провайдером.

Вопрос № 42

Принципы создания Web-приложений с архитектурой БДMulti-Tenant.

http://ru.wikipedia.org/wiki/Software_on-demand

http://msdn.microsoft.com/en-us/library/aa479086.aspx

Saas(Softwareasaservice) – это централизованное решение, при котором ряд продуктов, предназначенных для разных заказчиков, устанавливается в одну общую инфраструктуру.

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

Есть несколько подходов к обеспечению многодоменности:

1. Для каждого клиента своя база данных

2. База данных общая, но для каждого клиента своя схема (т.е. для каждого делаются копии таблиц)

3. Данные хранятся совместно

Первый случай:

1. Полная изоляция данных

2. Хранятся метаданные, позволяющие ассоциировать заказчика с Tenant’ом

3. Можно легко модифицировать структуру

4. Легко делать backup

5. Поддержка требует значительных усилий

6. Надо больше оборудования, в результате стоимость такого решения будет чувствительно выше, чем в остальных случаях.

Второй случай:

1. Может быть больше заказчиков

2. Легче обслуживание

3. Проблемы с backup– откатывается вся база, а нужно откатить только 1 домен (Tenant). Приходится разворачиватьbackupна новый сервер, а потом переносить туда данные всех заказчиков, кроме того, для которого делалсяbackup(или приостановить работу исходного сервера и перелить туда данные целевогоTennent’aиз нового сервера).

Третий случай:

Одна база, один набор таблиц. Добавляется новое поле TenantId

1. Наименьшие требования к аппаратуре

2. Легче всего обслуживать

3. Проблемы с backup

4. Много возни с обеспечением безопасности (вплоть до шифрации данных)

Подходит, если заказчиков очень много (тысячи)

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

Но при архитектуре SaaSтакой подход неэффективен, так как при работе с одним заказчиком нам не нужны данные остальных заказчиков. Эту проблему можно решить, используя разбиение на разделы (Partishnen). При этом данные при хранении будут группироваться по значению какого-то поля. Например:

Физически на диске будет храниться так:

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

При партишен архитектуре данные будут храниться так:

Партишен поддерживается только в Enterprise-версиях.

Вопрос № 43

Протокол SOAPи механизм удаленного вызова подпрограмм службы.

SOAP(отангл.Simple Object Access Protocol— простой протокол доступа к объектам) —протоколобмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в форматеXML, а не только для вызова процедур. Официальнаяспецификацияпоследней версии 1.2 протокола никак не расшифровывает название SOAP. SOAP является расширением протоколаXML-RPC.

SOAP может использоваться с любым протоколом прикладного уровня: SMTP,FTP,HTTP,HTTPSи др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP.

SOAP является одним из стандартов, на которых базируются технологии веб-служб.

Сообщение SOAP выглядит так:

SOAP-конверт

SOAP-заголовок

Элемент заголовка 1

Элемент заголовка 2

…

Элемент заголовка N

Тело SOAP

Элемент тела N

…

Элемент тела 2

Элемент тела 1

Использование SOAP для передачи сообщений увеличивает их объём и снижает скорость обработки. В системах, где скорость важна, чаще используется пересылка XML-документов через HTTP напрямую, где параметры запроса передаются как обычные HTTP-параметры.

Хотя SOAP является стандартом, некоторые программы часто генерируют сообщения в несовместимом формате. Например, запрос, сгенерированный AXIS-клиентом, не будет понят серверомWebLogic.

Вопрос № 44

Понятие масштабируемой распределенной базы данных.

РБД состоит из набора узлов, связанных коммуникационной сетью, в которой:

каждый узел — это полноценная СУБДсама по себе;

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

Каждый узел сам по себе является системой базы данных. Любой пользователь может выполнить операции над данными на своём локальном узле точно так же, как если бы этот узел вовсе не входил в распределённую систему. Распределённую систему баз данных можно рассматривать как партнёрство между отдельными локальными СУБД на отдельных локальных узлах.

Фундаментальный принцип создания распределённых баз данных («правило 0»): Для пользователя распределённая система должна выглядеть так же, как нераспределённая система.

Фундаментальный принцип имеет следствием определённые дополнительные правила или цели. Таких целей всего двенадцать:

1. Локальная независимость. Узлы в распределённой системе должны быть независимы, или автономны. Локальная независимость означает, что все операции на узле контролируются этим узлом.

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

3. Непрерывное функционирование. Распределённые системы должны предоставлять более высокую степень надёжности и доступности.

4. Независимость от расположения. Пользователи не должны знать, где именно данные хранятся физически и должны поступать так, как если бы все данные хранились на их собственном локальном узле.

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

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

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

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

9. Аппаратная независимость. Желательно иметь возможность запускать одну и ту же СУБД на различных аппаратных платформах и, более того, добиться, чтобы различные машины участвовали в работе распределённой системы как равноправные партнёры.

10. Независимость от операционной системы. Возможность функционирования СУБД под различными операционными системами.

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

12. Независимость от типа СУБД. Необходимо, чтобы экземпляры СУБД на различных узлах все вместе поддерживали один и тот же интерфейс, и совсем необязательно, чтобы это были копии одной и той же версии СУБД.