В рубрику "Решения корпоративного класса" | К списку рубрик | К списку авторов | К списку публикаций
Сегодня существуют различные варианты классификаций облаков и облочных сервисов (например, по приватности, публичности, гибридные) и облачных сервисов. И по сей день идут споры, какие риски возникают при переходе на облачные сервисы, какие лучшие практики в том или ином случае, как это скажется на бизнесе в целом и так далее. Каждый понимает ситуацию по-своему. Но во всех вариантах есть общая черта: облачным называют именно сервис, а не оборудование или программное обеспечение. Вы покупаете именно услугу. Какую именно – зависит от многих факторов.
Известно много моделей обслуживания, которые обозначают характеристики облачных услуг, такие как SaaS, PaaS, IaaS, CaaS, BPaaS и др. Однако необходимость управления инфраструктурой не теряет своей актуальности. Меняется характер внутренней услуги от IT.
Далеко не всегда удается использовать модели облачных сервисов, в которых предоставляется готовое для использования приложение. В случае вывода на рынок собственной разработки такое готовое облачное приложение просто не существует. В лучшем случае придется использовать Infrastructure as a Service, однако довольно распространена ситуация, когда команда, обеспечивающая информационную безопасность, против этой модели.
Если инфраструктура виртуализи-рована и выделение дополнительных виртуальных мощностей может занимать минуты, на эти серверы надо установить программное обеспечение, настроить как сам сервер, так и установленное ПО и проверить, что все работает так, как планировалось. Только после этого этапа развертывания выделенные ресурсы можно пустить в работу.
Ситуация становится еще сложней, если в компании есть команды разработки, использующие инструменты Continuous Integration/Continuous Delivery (CI/CD) для создания своих приложений. При этом подходе создание инфраструктуры должно быть оперативным, динамичным.
Если к вышеперечисленному добавить, что порой в сложных проектах разработки ПО время на подготовку инфраструктуры к нагрузочному тестированию или бета-тестированию (оно же User Acceptance Testing) может превышать время самого тестирования, несмотря на то, что виртуальные машины могут быть выделены довольно быстро, появляется запрос на IT-инфраструктуру, которая справилась бы с такими задачами.
Разумеется, многие из нас слышали и многие пользуются услугами облачной платформы Amazon. Но что делать, если корпоративная политика полностью запрещает использование внешних виртуальных серверов? Тогда на помощь приходят платформы для самостоятельного создания облачных сервисов. И это не просто серверы виртуализации. Эти сервисы стремятся сделать приватный аналог Amazon.
Сейчас многие производители систем виртуализации предлагают подобные решения. VMware, Microsoft и ряд других производителей предлагают различные расширения своих корпоративных платформ, есть и решения от сообщества Open-Source, например CloudStack и, конечно же, Open-Stack. Последний поддерживается очень активным и быстро растущим сообществом. Свой вклад в разработку имеют более 150 игроков мирового рынка IT, в том числе AMD, Brocade, Dell, HP, IBM, VMware, Yahoo, Redhat и др.
OpenStack распространяется по лицензии Apache License, а значит, бесплатен для использования и предоставляет гибкие возможности по организации инфраструктуры. В том числе важной особенностью для бизнеса является возможность выбора серверов виртуализации: OpenStack прозрачен для пользователя, работает с VMware и Hyper-V, а также поддерживает KVM, XenServer, и количество поддерживаемых решений постоянно растет. Эта гибкость позволяет бизнесу оптимально подбирать используемые средства и методы лицензирования. Некоторые производители операционных систем вводят особые правила лицензирования в случае использования систем виртаулизации этих же производителей.
Такие платформы, как Amazon и OpenStack, выводят управление инфраструктурой на совершенно новый уровень. Инфраструктура перестает быть набором серверов, правил и политик. Инфраструктура становится кодом, управляемым и понятным администраторам инструментом.
Больше не нужна армия системных администраторов, которые управляют серверами. Больше не надо следить за правильностью настроек на сотнях серверов. Нет необходимости при изменении настроек широко используемого сервиса вносить изменения на каждом сервере. Изменения вносятся не на серверах, а в код, описывающий инфраструктуру. И инфраструктура, уже без участия администраторов, приводит серверы и службы к новому состоянию.
Некоторые продукты развивают подход Infrastructure as a Code и позволяют достичь значительного прироста в скорости изменения инфраструктуры.
При использовании подхода Infrastructure as a Code разработчики получают возможность развернуть новый набор серверов, готовый к проведению тестирования, за считанные минуты, возможно даже при помощи используемого CI/CD-инструмента. Появляется возможность автоматического масштабирования приложений в приватном облаке в зависимости от нагрузки. Появляется возможность создания каталога приложений, доступных пользователям приватного или публичного облака.
Как известно, одной из отличительных черт облачных сервисов является наличие портала самообслуживания. Каталог приложений дает возможность пользователям портала самообслуживания самостоятельно развернуть приложение из числа заранее подготовленных шаблонов. В OpenStack для реализации этого функционала развивается проект Murano.
Приложением может быть как одна виртуальная машина с набором сервисов, так и сложные отказоустойчивые архитектуры с front-end, back-end и с балансировкой нагрузки. OpenStack Murano предоставляет гибкие инструменты для описания таких приложений, для их адаптации к разным операционным системам, архитектурам и путям выполнения. Каждое приложение может быть параметризировано. Кроме обычных параметров виртуальных машин, таких как образ операционной системы и выделяемые ресурсы, для кластера как правило указывается начальное число узлов, для сервера баз данных – параметры доступа и так далее.
Каталог приложений может использоваться в качестве отправной точки для единичной настройки сервисов либо для оптимизации затрат на редко используемое программное обеспечение. Например, можно сократить количество конкурентных лицензий за счет развертывания лицензируемых таким образом программных продуктов только на время использования.
Подход Infrastructure as a Code в совокупности с облачными технологиями позволяет по новому взглянуть на инфраструктуру предприятия, оптимизировать как использование ресурсов, так и затраты, обеспечить гибкость при выборе технических решений и существенно уменьшить время проведения изменений.
Литература
Опубликовано: Журнал "Технологии и средства связи" #6, 2015
Посещений: 3619
Автор
| |||
В рубрику "Решения корпоративного класса" | К списку рубрик | К списку авторов | К списку публикаций
