Файл: Облачные сервисы (Классификация «облачных» услуг).pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 17.06.2023

Просмотров: 120

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Рисунок 1.1 – Модель частного корпоративного «облака»

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

1.3 Технология реализации корпоративного «облака»

1.3.1 Инфраструктура частного «облака»

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

Возьмем другой пример. Допустим, существует отдел ИТ-департамента, который отвечает за разработку и сопровождение бизнес-приложений. Почему бы данному отделу не иметь возможности пользоваться инфраструктурой как сервисом из «облака», именуемого частным «облаком», и который обслуживается специальным инфраструктурным отделом, таким образом, избавив себя от ряда инфраструктурных проблем (рис. 1.2). Тем самым сотрудники получат не только непосредственный доступ к данным в «облаке» в пределах предприятия, но и смогут вести свою работу с филиалов, удалённым способом, с мобильных клиентов и так же предоставлять общий доступ партнёрам или смежным предприятиям.

Рисунок 1.2 – Схема доступа к частному облаку

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

В настоящее время более популярно и востребовано создание и построение частного «облака» с предоставлением инфраструктуры как сервиса Данная облачная технология называется IaaS (Infrastructureas a Service). Основной задачей для пользователя частного «облака», построенного при помощи «облачной» технологии IaaS, служит ряд запросов в виде: количества оперативной памяти, количества процессоров и требуемого объема для хранения данных, различных сетевых устройств и интерфейсов, а также в выборе базовой операционной системы, которая будет управлять «облачным» сервисом [9].


Для создания частного «облака» или переноса его с физического сервера на виртуальный необходимо провести исследование, а затем выработать стратегию. В ходе исследования проводятся следующие мероприятия:

  • Аудит текущей ИТ-инфраструктуры
  • Разработка основных архитектурных решений
  • Выборка технических средства по организации ИТ-систем в «облаке»
  • Налаживание защищенной связи между «облаком» и пользователями
  • Настройка контроллера домена в «облаке»
  • Инсталляция почтовой системы
  • Настройка терминальных сервисов
  • Настройка резервного копирования данных почтовых и терминальных серверов с использованием программно-аппаратного комплекса

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

Рисунок 1.3 – Открытая модель частного облака

Ко второму типу относят закрытое частное «облако» (рис. 1.4). Такого вида облачная технология полностью (или частично) изолирована от внешнего доступа из сети интернет. Вопрос о безопасности ложится прямо на сотрудников фирмы и системных администраторов, так как атака из вне полностью исключается. К особенностям стоит отнести:

Размещение физического оборудования на территории предприятия или в ЦОДах у сторонних организациях. Доступ осуществляется не через интернет канал, а по каналам корпоративной сети (например, оптоволокно).

Рисунок 1.4 - Закрытая модель частного облака

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


Как правило, для подобного рода проектов основными компонентами для решения задач являются следующие элементы:

  1. Сервера (несколько однотипных машин объединяются в гипервизор)
  2. Системы хранения данных (с возможностью виртуализации)
  3. Коммуникационное оборудование для передачи трафика

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

  1. Гипервизор, позволяющий создавать элементы виртуализации
  2. Семейство Microsoft SystemCenter – набор продуктов для управления, поддержки и развития гетерогенной облачной инфраструктуры. Состоит из множества продуктов, которые подключаются по мере необходимости.

Все программные продукты предоставляет компания Microsoft в бесплатном (или частично бесплатном) доступе. В подключаемые контуры должны входить средства: виртуализации, обновления, оптимизации, средство слежения и контроля, резервирование и восстановление данных, система сервис-деск (автоматизирует рутинные задачи пользователя и администратора), а так же интеграторы и автоматизаторы для непосредственной работы с пользователями [11].

1.3.2 Создание виртуальной машины с «облаком»

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

Для создания частного корпоративного «облака» отлично подходит инструмент — VirtualMachineManager 2012 R2 [7], который сочетает в себе все необходимые решения и функции для целого спектра задач. Так как основой любого современного облака является технология виртуализации, то первая ассоциация, которая должна возникнуть в начале моделирования — это вычислительные ресурсы. В связи с распространением виртуализации, «облако» как следующий уровень ИТ-модели, использующий для своих задач виртуализацию, говорит о том, что теперь приоритетность возлагается не на сервера при учете мощностей и развертывания сервисов, и приложений, а непосредственно на вычислительные ресурсы. Основными ресурсами, которые нам необходимы и которые мы виртуализируем, это ресурсы ЦП, ресурсы оперативной памяти (ОЗУ), ресурсы хранилища для размещения данных и коммуникационные ресурсы. Конечно, никуда не деться от того, что виртуальные машины и состоящие из них сервисы нужно где-то размещать, и вопрос размещения будет обращен непосредственно к объекту компьютера, хоста виртуализации, но с точки зрения облачного подхода нам больше интересен объем ресурсов — ведь такие технологии как DynamicMemory не позволяют уже в стандартном режиме «по привычке» воспринимать ресурсы негибкими блоками, коими хосты и являются, по сути.


И тот факт, что ОЗУ распределяется динамически, и если говорить про предоставление пространства хранилищ под виртуальные машины и сервисы — используемые методы ThinProvisioning и механизмы дедупликации данных, — это лишь немногие, но самые явные примеры того, что подход к потреблению (а значит и выделению) ресурсов в традиционным стиле не позволяет точно и адекватно дать оценку ресурсам и правильно их выделить под сервисы. Теперь смотреть нужно на количество необходимых именно вычислительных и инфраструктурных ресурсов, когда хотим создать новую ВМ (виртуальную машину) или сервис на базе ВМ. Основной момент заключается именно в том, что, во-первых, мы относимся к ресурсам как к пулам, наборам, а во-вторых — это уровень абстракции, ведь виртуализация абстрагирует нас от физического уровня на логический (ведь ВМ представляет собой ничто иное, как набор файлов — а это логический уровень), т.е. мы оперируем с виртуальными машинами как с файлами.

В контексте VMM (VirtualMachineManager) объект «облака» (cloud) является логическим периметром-ограничителем, который накладывается поверх физических ресурсов. А раз речь зашла про физические ресурсы, то в первую очередь нужно их добавить, т.е. первым делом добавляются хосты виртуализации. В новой версии программы можно выбирать различные порты мировых стандартов, что очень важно на раннем этапе моделирования (ПРИЛОЖЕНИЕ А, рис.1). От этого будет зависеть логическое проектирование коммуникационных виртуальных приборов. После указывается имена целевых хостов под учётной записью администратора. По завершению процесса будет готова платформа для установки виртуального оборудования и настройки сетевых ресурсов.

Далее настраивается глобальные параметры по умолчанию для всех ВМ – допустимое использование ОЗУ, CRU, а так же места адресации стораджа (возможно, как сетевое протоколирование, так и удалённое) (ПРИЛОЖЕНИЕ А, рис.2). Однако большая часть параметров будет выставляться автоматически и подчиняться физическим свойствам сервера, так как за распределением нагрузки на хосты выделяется не администратором и пользовательским ПО, а именно «облачной» технологией, которая в виртуальном обучающемся режиме сама распределяет мощности от пользователя к пользователю, не разрешая использовать всю нагрузку на один хост (пресловутые DDOS атаки на такой машине не страшны).

В последнюю очередь создаётся виртуальная сеть для частного корпоративного «облака» программным средством. Под управлением такой сети необходим виртуальный коммутатор для всех хостов, за которым назначаем сетевой адаптер хоста на связь пользователей и маршрутов к ресурсам (ПРИЛОЖЕНИЕ Б, рис.3). И после этого, когда сеть связана со всеми хостами и готова к работе. Нужно воссоединить данную инфраструктуру виртуальной сети с «облаком», которое формируется и настраивается в одноимённой вкладке VMM. Сети ВМ строятся поверх логических сетей используют сетевую виртуализацию, т.е. создание изолированных сетей, которые ведут себя словно это разные физические сети. Таким образом, сочетание этих механизмов позволяет выстраивать огромное множество изолированных виртуальных сетей вдоль хостов, и естественно, если сети не знают о существовании друг друга — то и IP-адреса в них могут использоваться повторяющиеся. Еще одним важным моментом является тот факт, что «облако», как элемент VMM, работает с компонентом сети на уровне логической сети, т.е. создание логической сети является необходимым условием для создания облачной структуры с динамическим поведением пользователей.


После того, как будет готова инфраструктура, необходимо собрать все компоненты вместе и связать их логической ипостасью объекта «облако» (cloud) в VMM. Далее нужно только создать в мастере «облако» с необходимыми параметрами, выбрать периметр ресурсов, поверх которых встанет «облако», обозначить заранее созданную логическую сеть и назначить хранилище для виртуальных машин. Интересным моментом в создании «облака» является возможность ограничить потребление ресурсов, как в относительном, так и в количественном выражении.

Ну и в заключении к готовому «облаку» необходимо привязать роли – так называемые учётные записи пользователей, которые смогут работать с данным сервисов (так как «облако» частное, то гостевых учётных записей или открытого доступа не будет). На этом этапе нужно распределить все роли, которые бывают нескольких типов, от глобального администратора до рядового пользователя, при чём первому открыт доступ к физическому оборудованию (интерфейсу настроек), настройкам «облака», учётным записей пользователей и другим важным вещам, а рядовым клиентам – только к виртуальной машине (ПРИЛОЖЕНИЕ Б, рис.4). Создание учётных записей так же позволяет следить за каждым из них (на сервере ведётся запись логов действий, операций и почты). Доступ в «облако» будет производить по web интерфейсу как для администратора, так и для пользователя (ПРИЛОЖЕНИЕ В, рис.5). Для удобства пользования так же устанавливается AppController 2012, который позволяет взаимодействовать с «облаком» в привычном для пользователя виде (консоль настроек и рабочая область) [6]. На этом этапе начальный фундамент корпоративного «облака» заложен и готов к установке «облачного» ПО, настройке виртуальной машины и дальнейшего глобального использования с горизонтальным масштабированием.

1.4 Преимущества «облачных» технологий

Основные преимущества следующие:

  • Пулы ресурсов. В частном «облаке» все ресурсы объединены в пулы, что позволяет достичь высокой эффективности их использования и масштабируемости при выделении ресурсов под определенные задачи. Распределяя ресурсы из общего пула между несколькими задачами и бизнес-подразделениями, ИТ-отдел может повысить эффективную загрузку имеющихся ресурсов.
  • Эластичность. После объединения ресурсов в пулы у ИТ-службы появляется возможность в автоматизированном порядке увеличивать и уменьшать объем ресурсов, выделенных под конкретную задачу. Фактически, это позволяет быстро масштабировать сервисы в соответствии с требованиями бизнеса.
  • Самообслуживание. При запросе, настройке и управлении ИТ-службами поставщики услуг и потребители используют интерактивный портал или систему, предназначенную для автоматического предоставления ресурсов.
  • Абсолютный контроль. Частное «облако» строится на основе ресурсов, имеющихся у вашей организации. Это означает, что у вас есть абсолютный контроль над всеми аспектами архитектуры и процессов, протекающих в вашем облаке.