Образованная недавно организация ODCA (Open Data Center Alliance) представляет ряд стандартизированных рекомендаций по внедрению облачных технологий, которые помогут предотвратить зависимость заказчиков от продукции одного производителя. В то же самое время альянс продвигает идею безопасного перемещения виртуальных нагрузок от одного поставщика облачных услуг к другому. Организация насчитывает около двухсот членов, среди которых JP Morgan Chase, Lockheed Martin, Marriott и проч.
Появляются и другие организации, объединяющие пользователей облачных технологий, например Совет клиентов по облачным стандартам (Cloud Standards Customer Council — CSCC). Однако именно ODCA в июне разработал восемь универсальных моделей использования облачных вычислений, которые предприятия могут использовать для определения своих базовых потребностей при реализации соответствующих проектов.
Формирование обоих объединений происходит в критический для отрасли ЦОДов момент. Ввиду повсеместного использования виртуализации ИT-специалисты в сфере обработки и хранения данных, сетевых технологий, приложений и рабочих станций вынуждены добиваться максимально эффективного использования дорогостоящих ресурсов. Одним из способов снизить эксплуатационные издержки является частичный или полный аутсорсинг виртуальных нагрузок.
Публикация рекомендованных моделей внедрения облачных вычислений, предпринятая альянсом ODCA, отображает серьезные изменения в принципах работы ЦОДов. Сегодня ИT-менеджеры должны консультировать руководителей высшего звена и глав бизнес-направлений в отношении того, какие изменения в архитектуре влекут за собой виртуализация и облачные вычисления и как предотвратить зависимость от одного производителя.
Предложенные модели использования облачных технологий могут облегчить эти усилия, но мой анализ показывает, что некоторые рекомендации можно дополнить и сделать более практичными. Например, в руководстве по выбору поставщика решений для обеспечения безопасности данных (Security Provider Assurance) ODCA не оговаривает точно, каким должен быть уровень правоприменительного действия, позволяющий правительственным структурам получить доступ к данным.
В частном ЦОДе существуют понятные процедуры и границы в отношении обысков и просмотра данных. Однако во внешних средах процедуры защиты информации от неоправданных обысков, устраиваемых правоохранительными органами, довольно неясны. Следовательно, на тот случай, если в дверь вдруг постучатся представители таковых органов, ИT-менеджеры должны требовать от поставщиков услуг точных сведений о внедренных технологиях обеспечения сохранности данных.
Стандартные модели внедрения облачных вычислений
Было опубликовано восемь универсальных моделей внедрения облачных вычислений, которые можно разнести по четырем категориям: безопасное объединение, автоматизация, общие принципы управления и политик, прозрачность.
1. В категорию “безопасное объединение облаков” попадают модели мониторинга безопасности (Security Monitoring — SM) и гарантии безопасности от провайдера (Security Provider Assurance — SPA). Модель SM в большей степени зависит от работы, выполняемой альянсом Cloud Security или группой CloudAudit, — обе эти организации в первую очередь состоят из поставщиков услуг безопасности.
Среди особо строгих требований к использованию облачных технологий следует назвать способность провайдера предоставить выделенные мощности с необходимыми ресурсами, зарезервированные для определенных клиентов.
Документ SPA имеет три области целевого применения, базирующиеся на категоризации клиентов по традиционной рейтинговой системе (“бронза”, “серебро”, “золото”, “платина”). Кроме того, документ позволяет потребителям облачных вычислений сравнивать уровни безопасности, предлагаемые различными провайдерами, и сопоставлять безопасность во внутренних и внешних облаках.
Эта модель должна облегчить заказчикам задачу выбора между различными уровнями безопасности, предлагаемыми провайдерами. Как было сказано выше, модель следует дополнить возможностью выяснить, есть ли риск того, что законный обыск, предпринимаемый государственными структурами, снизит степень контроля сохранности данных.
2. Категория автоматизации включает в себя модели контроля операций ввода-вывода (I/O Control — I/OC) и обеспечения интероперабельности виртуальных машин. Модель I/OC — это короткий документ, затрагивающий одну из самых больших проблем, из-за которой увеличивается плотность виртуальных машин в облачных средах, — конфликт между разными операциями ввода-вывода.
Разработка модели I/OC зависит от работы Национального института стандартов и технологий США и организации DMTF (Distribution Management Task Force) над устранением эффекта “бутылочного горлышка” при операциях ввода-вывода. Чтобы контролировать образование “бутылочных горлышек”, модель I/OC учитывает средства мониторинга, метрики SLA (Service-Level Agreement), программный интерфейс API, контроль коэффициента временного соотношения и резервирование мощностей для проведения операций ввода-вывода. Ожидается, что эти требования можно выполнить в мультивендорных средах, используя непроприетарные протоколы.
Углубляя категорию автоматизации, ODCA использует результаты работы DMTF над форматом OVF (Open Virtualization Format), что позволяет требовать, чтобы виртуальная машина могла быть перенесена с одной платформы гипервизора на другую или из одного ЦОДа в другой.
Так как ODCA высказывается за поддержку протокола OVF, становится ясно, что он является форматом взаимодействия для виртуальных машин, который надо внедрять. VMWare и Citrix давно поддерживали идею внедрения OVF, и вычислительные центры, которые используют платформы этих производителей, скорее всего разделяют мнение, что OVF полезен при переводе виртуальных машин с одной платформы на другую.
3. Общая среда управления и политик определяются моделью Regulatory Framework (RF). Эта модель подробно описывает, как провайдеры облачных услуг могут обеспечить степень соответствия услуги требованиям, хотя и со справедливым замечанием, что потребители должны отдавать себе отчет в возможных рисках.
Модель RF концентрируется на текущей программе соответствия облачных сред корпоративным стандартам, и ее практические рекомендации для применения в частных ЦОДах — лучшие из того, что я видел в своей жизни. Это значит, что применяемые в вашей организации практики не претерпят особых изменений, если данные и приложения будут перенесены в общую облачную среду.
Что в этом случае меняется — это то, что провайдер облачных услуг становится источником данных об оценке рисков и управлении. Таким образом, ИT-менеджеры должны использовать модель RF как отправную точку для исследования способности провайдера облачных услуг удовлетворить требования организации в области контроля и отчетности.
4. Категория прозрачности включает в себя модели SUoM (Standard Units of Measure), SC (Service Catalogue) и CF (Carbon Footprint). Первая из них описывает определения и системы измерений, чтобы облегчить пользователям задачу сравнения данных разных отчетностей, когда приходит время оплачивать услуги.
Описание модели SC — едва ли не самая подробная публикация из вышеперечисленных и представляет собой кодификацию непосредственных взаимодействий между поставщиками и потребителями облачных услуг. Модель SC описывает, чтó может предоставить интерфейс API крупным потребителям облачных сервисов.
“Графический интерфейс не так важен заказчику нашего профиля — он может и не использовать его для поиска и выбора сервисов. Потребители облачных услуг нуждаются в устойчивом, детализированном наборе программных функций <...> чтобы хорошо изучить каталог сервисов”. Это вступление к более чем десятистраничному описанию, что же такое “устойчивый и детализированный набор программных функций”, содержащемуся в публикации модели SC.
Модель SC отрезвляет порой легкомысленные дискуссии, сопутствующие теме облачных вычислений, это своеобразный учебник, рассказывающий, что могут предложить компаниям облачные вычисления. Детально характеризуя требования к каталогу сервисов, модель SC касается каждого аспекта операций в облаке и говорит о роли, которую ИT играют в обеспечении эффективности предоставляемых сервисов.
Модель CF описывает способы измерения поставщиками облачных услуг воздействия инфраструктуры на экологию в том случае, если ИT-менеджеры заботятся об окружающей среде при выборе облачных сервисов. Модель CF открыто указывает на то, что SUoM не учитывает влияние на окружающую среду, когда строится ЦОД.
В методику подсчета выброса углерода не включена и утилизация оборудования. В этом отношении модель CF представляется мне как подход, созданный для того, чтобы было хоть какое-то начало.
Действительно, ODCA нужно было с чего-нибудь начать, поэтому ИT-менеджерам стоит взглянуть на документацию и оценить ее как руководство перехода в облако.
