Сейчас модно говорить про облачные вычисления и облака. За счет виртуализации эти разговоры становятся реальностью во многих компаниях (частные облака) и у сервис-провайдеров (публичные облака). Есть такой ресурс doublecloud.org, где Steve Jin выкладывает паттерны построения облаков.
Эти паттерны он формализует по определенным правилам и рассматривает проблемы и решения, которые возникают в процессе размышлений над различными аспектами облачной инфраструктуры.
Кое-что весьма интересно:
Шаблон виртуальной машины. Самый простой путь стандартизации развертывания виртуальных машин в виртуальной инфраструктуре, соответствующих определенным уровням безопасности и содержащих необходимые приложения. Здесь рассматривается проблема иерархии шаблонов, поскольку корпоративное приложение обычно реализовывается набором виртуальных машин, которые нужно поддерживать на определенном уровне безопасности и своевременно патчить.
Машина независящая от состояния, то есть готовая к развертыванию (то есть бэкапить машину не нужно - нужно только данные). Такие машины в облаке очень нужны, поэтому нужно уделить внимание зависимостям от других систем (то есть что-то можно ей дать уже готовое внутри себя, а что-то она должна подцеплять снаружи, в том числе и из внешнего облака), уменьшению занимаемого дискового пространства и способам взаимодествия с внутрикорпоративными и внешними приложениями.
Централизация сервисов в облаке. Подход такой: отбираем повторяющиеся функции у приложений и централизуем их в облаке на базе стандартных служб - логирование, базы данных, работа с сообщениями и т.п. Для таких служб должны быть отдельные системы, которые работают, конечно же, в виртуальных машинах вашего или публичного облака.
Пулы виртуальных машин. То, что сейчас реализовано в VMware View - мы имеем пул развернутых виртуальных машин, которые пользователи могут извлекать и возвращать в пул по требованию (Check out - Check in). Этот подход позволяет добиться максимальной скорости доступа пользователей к запрошенным сервисам или данным.
"Фабрика виртуальных машин". Здесь предлагается стандартизация подходов к развертыванию сервисов в виртуальных машин - то, что у VMware сейчас делают vCloud Director и Request Manager. У пользователя должен быть свой фронтэнд, где он задает основные требуемые ему параметры, а остальное пусть конфигурируется автоматически или ИТ-персоналом компании (например, сервис-провайдера).
Естественно, должен быть API для унификации этого процесса между разнородными облаками.
Виртуальные машины, реализующие PaaS (App VM). Зачем вам пользоваться чужой платформой-как-услугой (PaaS), если вы можете развернуть ее сами в виртуальных машинах на базе вашей IaaS (инфраструктуры как услуги)? Вот такие машинки для PaaS и предлагается развертывать во внутреннем облаке. Они очень хорошо масштабируются и могут помочь вам в построении инфраструктуры накручиваемых на них сверху приложений.
Сервисные виртуальные машины. Масштабировать облачную инфраструктуру с помощью шаблонов и App VM хорошо, но нужео еще и следовать концепции централизации общих сервисов (например, службы каталога или машины, предоставляющие ресурсы хранения). Вот тут и надо давать возможность просто масштабировать такие служебные виртуальные машины, при этом они должны обладать самым высоким показателем доступности, поскольку от них зависят остальные машины ("рабочие лошадки").
Поток сервисов в виртуальных машинах. В облачной инфраструктуре, где модульный характер приложений имеет большое значение, а виртуальная среда дает намного большую гибкость, чем физическая. Поэтому хорошо бы строить облачные сервисы, опираясь на уже созданные службы, чтобы не проводить работу по развертыванию и конфигурированию повторно, тем более, что с шаблонами и снапшотами виртуальных машин это несложно.
"Облачный брокер". Если вы сами не можете торговать на бирже, то вы нанимаете брокера, который играет от вашего имени (и за ваш счет:) А вот если вы планируете пользоваться услугами нескольких сервис-провайдеров, то вам нужен такой софт, который сможет обеспечивать подключение к сторонним сервисам и взаимодействие с ними в рамках вашей "виртуальной" инфраструктуры (здесь слово виртуальной взято в кавычки, так как это второй уровень виртуальности - то есть объединение виртуальных ресурсов от разных провайдеров). Например, такой брокер может делать vMotion от одного провайдера к другому на базе доступных ресурсов, показателей качества обслуживания или даже стоимости аренды виртуальных машин или приложений.
"Фасадная виртуальная машина". Под этим подразумевается сервис, который будет вам предоставлять глобальную информацию о вашей облачной инфраструктуре. Он будет контролировать жизнедеятельность информационных систем, предоставлять комплексную информацию о конфигурациях и будет являться единой точкой обзора облака, взаимодействуя с сервисами по унифицированным интерфейсам. Кстати, в этой связи советую взглянуть на продукт Veeam Reporter для инфраструктуры VMware vSphere. Многие в облаках используют именно его.
Чтиво интересное, такое, что можно сломать мозги. Будьте аккуратны.
RSS
