EKZAMEN

Хотя для хранения объемов данных и программ необходимы значительные емкости, им не обязательно размещаться локально. Такие интерфейсы, как FireWire, SATA, SCSI, DAS, Fibre Channel и iSCSI позволяют подсоединять накопители на значительном удалении от процессоров. По аналогии с сетевыми подключениями (а интерфейс iSCSI опирается только на них) соответствующие устройства могут быть размещены в корпусе блэйд-системы или смонтированы на выделенных блэйд-слотах. Специальное решение в виде блэйд-системы, загружаемой через локальную сеть (SAN), позволяет создать исключительно надежную и компактную серверную систему.

Специализированные блэйд-слоты Стандартизация интерфейса блэйд-слота позволяет создавать устройства, способные не только производить вычисления, но и

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

Области применения

В стандартных серверных стойках минимальный размер сервера принято называть 1U или 1 юнит (19 дюймов в ширину х 1,75 дюйма в высоту). Как правило, такие стойки вмещают 42 юнита оборудования, то есть максимум 42 сервера. Использование блэйд-серверов позволяет обойти это ограничение не выходя за размеры стандартой стойки и разместить до 100 серверов в каждой.

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

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

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

56.Grid системы. Системы облачных вычислений

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

Сам термин "грид" (grid - решѐтка) возник в середине 90-х годов и обозначал рас-пределенную вычислительную инфраструктуру для сложных инженерных и научных рас-четов. В настоящее время концепция grid (название предложено по аналогии с электриче-скими сетями - electric power grid) состоит прежде всего в глобальной интеграции компь-ютерных ресурсов.

grid - это возможность вычислений на глобальных компьютерных ресурсах. Вычис-ление означает использование процессора и дисков удаленных компьютеров. Соответст-венно владельцы компьютеров должны принимать решение о допуске "посторонних" пользователей на более продуманной и надежной основе.

Систему можно называть grid, если она:

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

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

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

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

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

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

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

57.Принципы, поколения, примеры Grid

Систему можно называть grid, если она:

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

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

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

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

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

•Уровень связи (Connectivity layer) – устанавливает базовый набор коммуникационных и аутентификационных протоколов, необходимых для выполнения специфических для гридов сетевых транзакций.

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

•Уровень кооперации (Collectivity layer) – в то время, как уровень ресурсов нацелен на взаимодействие с одним ресурсом, уровень кооперации обеспечивает управление глобальными ресурсами и взаимодействие с коллекцией ресурсов. Протоколы этого уровня реализуют широкий набор способов, используя достаточно малое количество протоколов уровня ресурсов и уровня связи.

•Уровень приложений (Application layer) – дает возможность использования ресурсов в среде грид с помощью различных корпоративных протоколов и протоколов доступа к ресурсам.

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

Архитектура Grid протоколов описывается моделью "песочных часов", которой также описывается TCP/IP. Узкое горлышко таких часов содержит минимальный набор протоколов (для TCP/IP - узкое горлышко транспортные протоколы

TCP, UDP). В модели объединяется максимально большое количество сервисов, расположенных на дне песочных часов, с максимально большим количеством сервисов на их вершине через узкое горлышко. Число протоколов в горлышке должно быть малым. Технологии, разработанные в рамках модели "песочных часов", обеспечивают надежность,

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

Практическую реализацию архитектуры Grid протоколов иллюстрируют протоколы, определенные в Globus Toolkit. Они широко используются в Grid проектах NSF - National Technology Grid, NASA - Information Power Grid, DOE - DISCOM, GriPhyN (www.griphyn.org), NEESgrid (www.neesgrid.org), Particle Physics Data Grid (www.ppdg.net), и European Data Grid (www.eu-datagrid.org).

Базовый уровень Grid (Grid Fabric layer) описывает службы, непосредственно работающие с ресурсами, к которым предоставляется разделяемый доступ посредством Grid-протоколов. Термин "ресурсы" достаточно широк, и включает как аппаратные, так и программные средства: вычислительные ресурсы, хранилища данных, каталоги, сетевые ресурсы, датчики, и т.п. Ресурсом может быть любая логическая единица, например, распределенная файловая система, компьютерный кластер или распределенный компьютерный пул. В таких случаях, ресурс может использовать

внутренние протоколы (например, протокол NFS или протоколы управления кластером), которые не являются компонентами Grid архитектуры.

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

Однако, стандартная архитектура гридов третьего поколения не удовлетворяет требования гридов следующего поколения (NGG – Next Generation grids) и ориентированных на службы утилит знаний (SOKU). Несколько лет назад созданная Европейской комиссией группа независимых экспертов четко сформулировала все эти недостатки и взяла их за основу при определении потенциальных приоритетов в европейских грид-исследованиях на период до 2010 года и далее. В представлении экспертов информационные возможности грид-систем, возможности работы со знаниями и возможности обработки должны реализовываться как набор коммунальных программных служб. Вследствие этого, мы являемся свидетелями появления новых грид-систем, в которых делаются попытки реализовать это видение. В нашей статье мы делаем обзор новейших гридов и производим их классификацию с целью выявления мотивации дальнейших исследований и формирования надежной понятийной базы в этой быстро развивающейся области.

Фундаментальная разница между грид-технологиями и перспективным видением NGG состоит в том, как расставляются приоритеты в грид-исследованиях между проникаемостью и способностью к самоуправлению. Проникаемость – это сложное свойство, зависящее от других примитивных атрибутов, среди которых главными являются: доступность, ориентация на пользователя или настраиваемость (user-centricity) и динамическое взаимодействие. В нашей работе мы делаем обзор новейших гридов и классифицируем их на основе четырех признаков – доступность, настраиваемость, интерактивность и управляемость параметров, определяющих материализацию видения NGG. Для простоты мы используем термин традиционные гриды для ссылок на гриды первого, второго и третьего поколений, для которых упомянутые четыре свойства безусловно не стоят на первых местах; термин новейшие гриды относятся к последним грид-проектам, в которых по крайней мере одно из этих свойств явно становится ведущим.

Используя эти свойства, мы можем распределить новейшие гриды по четырем главным группам: гриды доступа, настраиваемые гриды, интерактивные гриды и управляемые гриды.

Примеры известных проектов с использованием grid-вычислений: обработка большого массива данных с радиотелескопа в поисках внеземного разума SETI@homeи перебор комбинаций химических веществ для создания перспективных лекарственных средств Folding@home.

Свободно распространяемый инструментарий Globus Toolkit стал фактическим стан-дартом конструирования Grid-систем. На его основе созданы самые разные проекты: от систем обеспечения работы научных групп, которым требуется удаленный доступ к спе-циализированными экспериментальным лабораториям, например, Network for Earthquake Engineering Simulation (NEESgrid, www.neesgrid.org), до систем распределенной аналити-ческой обработки больших объемов информации, таких как

Grid Physics Network, EU DataGrid Project (www.griphyn.org) и Particle Physics Data Grid (www.ppdg.net).

Наиболее существенными компонентами ИК Globus являются: грид-протокол Рас-пределения и управления ресурсами (Grid

Resource Allocation and Management protocol - GRAM) и его служба, так называемый, ―привратник‖– gatekeeper,

обеспечивающая безо-пасное, надѐжное создание служб и управление; служба мета каталогов (Meta Directory Service – MDS-2), осуществляющая на основе программно выполняемой регистрации об-наружение информации и построение модели данных и ведение локального системного реестра (―GRAM reporter‖); грид-инфраструктура безопасности (Grid Security Infrastructure – GSI), которая поддерживает одноразовую регистрацию (single sign on), де-легирование полномочий и отображение сертификатов.

58.Примеры протоколов для реализации Grid

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

Архитектура Grid протоколов описывается моделью "песочных часов" , которой также описывается TCP/IP. Узкое горлышко таких часов содержит минимальный набор протоколов (для TCP/IP - узкое горлышко транспортные протоколы TCP, UDP). В модели объединяется максимально большое количество сервисов, расположенных на дне песочных часов, с максимально большим количеством сервисов на их вершине через узкое горлышко. Число протоколов в горлышке должно быть малым. Технологии, разработанные в рамках модели "песочных часов", обеспечивают надежность, качество совместимости разнообразных сервисов. В архитектуре Grid горлышко часов расположено в области ресурсного и связывающего уровней, упрощающих разделение ресурсов. Протоколы этих уровней с одной стороны, могут являться вершиной большого количества типов ресурсов, определенных на базовом уровне (уровне локального управления), а с другой стороны, могут быть использованы как базовые для широкого спектра глобальных сервисов и приложений на коллективном уровне.

Практическую реализацию архитектуры Grid протоколов иллюстрируют протоколы, определенные в Globus Toolkit . Они широко используются в Grid проектах NSF - National Technology Grid, NASA - Information Power Grid, DOE - DISCOM, GriPhyN (www.griphyn.org), NEESgrid (www.neesgrid.org), Particle Physics Data Grid (www.ppdg.net), и European Data Grid (www.eu-datagrid.org).

Базовый уровень Grid (Grid Fabric layer) описывает службы, непосредственно работающие с ресурсами, к которым предоставляется разделяемый доступ посредством Grid-протоколов. Термин "ресурсы" достаточно широк, и включает как аппаратные, так и программные средства: вычислительные ресурсы, хранилища данных, каталоги, сетевые ресурсы, датчики, и т.п. Ресурсом может быть любая логическая единица, например, распределенная файловая система, компьютерный кластер или распределенный компьютерный пул. В таких случаях, ресурс может использовать внутренние протоколы (например, протокол NFS или протоколы управления кластером), которые не являются компонентами Grid архитектуры.

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

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

Современная реализация Grid, Globus Toolkit, была разработана таким образом, чтобы использовать существующие сервисы, соответствующие базовому уровню, включая протоколы и интерфейсы производителей. Если эти сервисы не предоставляют необходимый набор механизмов управления и функций опроса базового уровня, Globus Toolkit восполняет пробелы в функциональности. Например, в Globus Toolkit был создан механизм опроса, обеспечивающий сбор информации для самых разнообразных и наиболее распространенных типов ресурсов, таких как компьютеры (включая тип операционной системы, аппаратные конфигурации, загрузку и состояние очередей), хранилища данных (доступность свободного пространства), сети (текущую загрузку и предсказание состояния). Управление ресурсами на этом уровне оставлено в зоне ответственности локальных систем. Исключение составляет многофункциональная архитектура резервирования и выделения ресурсов (General-purpose Architecture for Reservation and Allocation - GARA). Она предоставляет, так называемый, "менеджер слотов" для выполнения продвинутого резервирования тех ресурсов, которые не обеспечены изначально подобной возможностью. Другие разработки Globus Toolkit касаются усовершенствования уже существующих систем Portable Batch System (PBS) и Condor, которые сами поддерживают возможности продвинутого резервирования.

59.Сравнение Grid и облачных систем

Как и облачные вычисления, grid-вычисления позволяют выполнять

вычислительные задачи на удаленных компьютерах. Однако у этих концепций разные особенности и приоритеты. Gridвычисления ориентированы на выполнение ресурсоемких вычислительных задач, чаще всего научного характера, параллельно на большом числе компьютеров. Примеры известных проектов с использованием grid-вычислений: обработка большого массива данных с радиотелескопа в поисках внеземного разума SETI@homeи перебор комбинаций химических веществ для создания перспективных лекарственных средств Folding@home.

Вотличие от grid computing в облачных вычислениях пользователи сами определяют характер решаемых задач: при этом обработка данных может вестись как распределенно, так и на одном компьютере — все зависит от того, как спроектирована архитектура облачного приложения и как устроена «внутренняя кухня» конкретного облачного поставщика.

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

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

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

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

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

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

2)грид и облачные вычисления фокусируются на различные типы вычислений. Из-начально, грид вычисления были ориентированы на решение научных задач посредством суперкомпьютерных систем. В настоящее время грид применяется для научно-исследовательских задач, решение котрых требует объединение нескольких суперкомпь-ютерных платформ. С другой стороны облачные вычисления ориентированы не на реше-ние отдельных задач, а на перманентное предоставление определенных сервисов конеч-ным пользователям. Они обеспечивают динамическое распределение физических ресур-сов для удовлетворения переменной загрузки таких сервисов.

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

4)различные области применения. Грид-платформы предоставляют базу для раз-вертывания вычислительной инфраструктуры. Облачные вычисления предоставляют ин-тегрированных подход на всех уровнях предоставления информационных ресурсов: IaaS, PaaS, SaaS.

5)расширение количества пользовательских интерфейсов. Грид вычисления ориен-тированы на представление различных вычислительных ресурсов в гетерогенных вычис-лительных средах для решения конкретных задач. Таким образом, интерфейсы грид ори-ентированны на взаимодействие вычислительных инфраструктур на физическом уровне посредством API, которым может воспользоваться только профессиональный програм-мист. Облачные вычисления разрабатываются таким образом, чтобы предоставлять ин-терфейсы конечным пользователям через веб-доступ или посредством API. На каждом слое (IaaS, PaaS, SaaS) предоставляется свой собственный интерфейс. Повышение уровня абстракции позволяет обеспечить применение облачных вычислений как на уровне от-дельных пользователей, так и на уровне корпоративных клиентов.

60.Преимущества и недостатки облачного подхода Достоинства.

•Недорогие компьютеры для пользователей. Пользователям нет необходимости покупать дорогие компьютеры, с большим объемом памяти и дисков, чтобы использовать программы через веб-интерфейс. Также нет необходимости в СD и DVD приводах, так как вся информация и программы остаются в "облаке". Пользователи могут перейти с обычных компьютеров и ноутбуков на более компактные и удобные нетбуки.

•Увеличенная производительность пользовательских компьютеров. Так как большая часть программ и служб запускаются удаленно в сети Интернет, пользовательские компьютеры с меньшим числом программ быстрее запускаются и работают. Одним из хороших примеров является антивирусное решение Panda Cloud Antivirus, которое позволяет сканировать данные на вирусы удаленно на мощных серверах и тем самым в 2 раза снижает нагрузку на пользовательский компьютер.

•Уменьшение затрат и увеличение эффективности IT инфраструктуры. Обычные сервера средней компании загружены на 1015%. В одни периоды времени есть потребность в дополнительных вычислительных ресурсах, в других эти дорогостоящие ресурсы простаивают. Используя необходимое количество вычислительных ресурсов в "облаке" (например, Amazon EC2) в любой момент времени, компании сокращают затраты на оборудование и его обслуживание до 50%. При этом многократно увеличивается гибкость производства в постоянно меняющейся экономической обстановке. Если достаточно большая фирма обеспокоена тем, что ценная информация будет храниться и обрабатываться на стороне, для такой фирмы можно построить свое собственное "облако" и наслаждаться всеми выгодами от виртуализации инфраструктуры.

•Меньше проблем с обслуживанием. Так как физических серверов с внедрением Cloud Computing становится меньше, их становится легче и быстрее обслуживать. Что касается программного обеспечения, то последнее установлено, настроено и обновляется в "облаке".

•Меньше затрат на приобретаемое программное обеспечение. Вместо приобретения пакетов программ для каждого локального пользователя, компании покупают нужные программы в "облаке". Данные программы будут использоваться только теми пользователями, которым эти программы необходимы в работе. Более того, стоимость программ, ориентированных на доступ через Интернет, значительно ниже, чем их аналогов для персональных компьютеров. Если программы используются не часто, то их можно просто арендовать с почасовой оплатой. Затраты на обновление программ и поддержку в работоспособном состоянии на всех рабочих мечтах вовсе сведены к нулю.

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

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

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

•Совместимость с большинством операционных систем. В Cloud Computing операционные системы не играют никакой роли. Пользователи Unix могут обмениваться документами с пользователями Microsoft Windows и наоборот без каких либопроблем. Доступ к программам и виртуальным компьютерам происходит при помощи веб-браузера или другими средствами доступа, устанавливаемые на любой персональный компьютер с любой операционной системой.

•Улучшенная совместимость форматов документов. Если пользователи пользуются одной "облачной" программой для создания и редактирования документов, у них просто нет несовместимости версий и форматов, в отличие от тех, кто, например, получит документ Word 2007 и не сможет прочитать его на локальном компьютере с Word 2003 или OpenOffice. Хорошим примером совместимости является офисный пакет Google Docs, позволяющий совместную работу над документами, презентациями и таблицами имея под рукой любой компьютер с веб-браузером.

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

•Повсеместный доступ к документам. Если документы хранятся в "облаке", они могут быть доступны пользователям в любое время и в любом месте. Больше нет такого понятия как забытые файлы: если есть Интернет - они всегда рядом.

•Всегда самая последняя и свежая версия. В "облаке" всегда находится самая последняя и самая свежая версия программы или документа.

•Доступность с различных устройств. Пользователи Cloud Computing имеют гораздо более широкий выбор устройств доступа к документам и программам. Теперь можно выбирать между обычным персональным компьютером, ноутбуком, Интернетпланшетом, наладонником, смартфоном или нетбуком.

•Дружелюбие к природе, экономное расходование ее ресурсов. Cloud Computing позволяет не только экономить на электричестве, вычислительных ресурсах, физическом пространстве, занимаемом серверами, но и разумно подходить к расходованию природных ресурсов. Центры обработки информации, те самые "облака", можно расположить в более прохладном климате, пользователи могут заменить тяжелые, ресурсоемкие компьютеры и ноутбуки на легкие и экономичные нетбуки. При этом экономится не только электроэнергия и место, но и материалы, из которых все это изготавливается.

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

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

Недостатки.

•Постоянное соединение с сетью Интернет. Cloud Computing всегда требует соединения с сетью Интернет. Или почти всегда. Некоторые "облачные" программы загружаются на локальный компьютер и используются в то время, когда Интернет недоступен. В остальных случаях, если нет доступа в Интернет - нет работы, программ, документов. Это наверное самый

сильный аргумент против Cloud Computing. Но признайтесь честно, как сейчас современному человеку обойтись без услуг, доступных в сети Интернет? Также не обойтись, как и без мобильного телефона, платежных карт и многого другого. Многие уже ни дня не могут обойтись без электронной почты. Поэтому, учитывая развитие современного мира, Интернет будет доступен всегда и везде, где Вы находитесь, как, например, электричество и вода.

•Плохо работает с медленным Интернет-доступом. Многие "облачные" программы требуют хорошего Интернет-соединения с большой пропускной способностью. Если Вы "счастливый" обладатель модема 56К, Вам можно только посочуствовать. Сегодня все реже и реже встречаются старые неоптоволоконные магистрали для сети Интернет, скорости доступа постоянно растут, а цены - снижаются.

•Программы могут работать медленнее чем на локальном компьютере. Некоторые программы, в которых требуется передача значительного количества информации, будут работать на локальном компьютере быстрее не только из-за ограничений скорости доступа в Интернет, но и из-за загруженности удаленных серверов и проблем на пути между пользователем и "облаком".

•Не все программы или их свойства доступны удаленно. Если сравнивать программы для локального использования и их "облачные" аналоги, последние пока проигрывают в функциональности. Например, таблицы Google Docs имеют гораздо меньше функций и возможностей, чем Microsoft Excel.

•Безопасность данных может быть под угрозой. Здесь ключевым является слово "может". Все зависит от того, кто предоставляет "облачные" услуги. Если этот кто-то надежно шифрует Ваши данные, постоянно делает их резервные копии, уже не один год работает на рынке подобных услуг и имеет хорошую репутацию, то угрозы безопасности данных может никогда не случиться. Как сказал известнейший специалист по криптографии и компьютерной безопасности Брюс Шнайер, весь сопрос в доверии.

•Если Ваши данные в "облаке" потеряны, они потеряны навсегда. Это факт. Но потерять данные в "облаке" гораздо сложнее, чем на локальном компьютере.

61.Клиентское оборудование и ПО для облачных систем

Необходим компьютер с сетевой картой, подключение к интернету (модем), браузер.

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

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

Платформа как услуга (PaaS, англ. Platform-as-a-Service) — модель, когда потребите-лю предоставляется возможность использования облачной инфраструктуры для размеще-ния базового программного обеспечения для последующего размещения на нѐм новых или существующих приложений (собственных, разработанных на заказ или приобретѐн-ных тиражируемых приложений). В состав таких платформ входят инструментальные средства создания, тестирования и выполнения прикладного программного обеспечения — системы управления базами данных, связующее программное обеспечение, среды ис-полнения языков программирования — предоставляемые облачным провайдером.

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

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

62.Виртуальные машины при реализации облачных систем Виртуальная ОС EyeOS.

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

Виртуальная ОС Cloudo.

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

Виртуальная ОС Glide OS.

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

Виртуальная ОС iCube OOS.

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

Русскоязычным пользователям, конечно же, хотелось бы обладать виртуальной ОС, имеющей русскоязычный интерфейс. До недавнего времени оптимальной в этом плане была виртуальная ОС ICloud. Но сейчас ее купила компания Apple практически за 4,5 млн. американских долларов, что автоматически сделало ее недоступной. Компания Apple на основе домена icloud.com формирует облачное хранилище информации. Кстати, не так давно его очень помпезно презентовали вместе с новейшей ОС Apple iOs 5, полностью заточенной именно под «облака».

На данный момент остается одно лишь достойное предложение, имеющее поддержку русского языка. Это виртуальная ОС

CloudMe.

63.Базовые типы облачных систем

Модели развѐртывания

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

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

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

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

Модели обслуживания Программное обеспечение как услуга

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

Платформа как услуга

Платформа как услуга (PaaS, англ. Platform-as-a-Service) — модель, когда потребителю предоставляется возможность использования облачной инфраструктуры для размещения базового программного обеспечения для последующего размещения на нѐм новых или существующих приложений (собственных, разработанных на заказ или приобретѐнных тиражируемых приложений). В состав таких платформ входят инструментальные средства создания, тестирования и выполнения прикладного программного обеспечения — системы управления базами данных, связующее программное обеспечение, среды исполнения языков программирования — предоставляемые облачным провайдером.

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

Инфраструктура как услуга

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