Что относится к технологии utility computing
Очередной взгляд на облака. Что такое частное облако?
Рост вычислительных мощностей и развитие технологий виртуализации платформы x86 с одной стороны, и распространение ИТ-аутсорсинга с другой стороны привели к концепции utility computing (ИТ как коммунальная услуга). Почему бы не платить за ИТ так же, как за воду или электричество – ровно столько и ровно тогда, когда это нужно, и не более.
В этот момент и появилась концепция облачных вычислений – потребление ИТ услуг из «облака», т.е. из некоего внешнего пула ресурсов, не заботясь о том, как и откуда берутся эти ресурсы. Так же, как мы не заботимся об инфраструктуре насосных станций водоканала. К этому моменту была проработана и другая сторона концепции – а именно понятие ИТ-услуг и как ими управлять в рамках ITIL / ITSM.
Был разработан целый ряд определений облаков (облачных вычислений), но при этом не следует относиться к ним как к истине в последней инстанции – это лишь способ формализовать способы предоставления utility computing.
Для совсем упрощенного понимания разницы давайте рассмотрим модель Pizza-as-a-Service:
NIST определяет следующие необходимые черты ИТ услуги, позволяющие считаться облачной.
Почему я об этом отдельно говорю? За прошедшие 10 лет с момента появления определения NIST было много споров об «настоящей облачности» согласно определения. В США до сих пор иногда применяется в судебной сфере формулировка «соответствует букве закона, но не духу» — и в случае с облачными вычислениями главное именно дух, ресурсы в аренду в два клика мышью.
Необходимо отметить, что вышеперечисленные 5 характеристик применимы к публичному облаку, но при переходе к частному большинство из них становятся опциональными.
Ответ: частное облако – это переход к новой административной модели взаимодействия ИТ-Бизнес, который на 80% состоит из административных мер и только на 20 из технологий.
Оплата только за потребленные ресурсы и легкий вход, без необходимости закопать несколько сотен миллионов нефти в капитальных затратах, обусловили новый технологический ландшафт и появление компаний-миллиардеров. Например современные гиганты Dropbox и Instagram появились как стартапы на AWS с нулевой собственной инфраструктурой.
Необходимо отдельно подчеркнуть, что инструменты управления облачными услугами становятся значительно более опосредованными, а ключевой обязанностью ИТ директора становится подбор поставщиков и контроль качества. Давайте рассмотрим проблематику этих двух новых обязанностей.
Появившись как альтернатива классической тяжелой инфраструктуре с собственными ЦОДами и железом, облака обманчиво легки. В облако легко войти, но вот вопрос выхода обычно обходится стороной. Как и в любой другой отрасли облачные провайдеры стремятся к защите бизнеса и усложнении конкуренции. Единственный серьезный конкурентный момент возникает лишь при первичном выборе поставщика облачных услуг, а далее поставщик приложит максимум усилий, чтобы заказчик от него не ушел. Причем далеко не все усилия будут направлены на качество услуг или их ассортимент. Прежде всего, это поставка уникальных услуг и использование нестандартного системного ПО, затрудняющего переход к другому провайдеру. Соответственно, при выборе поставщика услуг необходимо одновременно формировать план перехода от этого поставщика (по сути полноценный DRP – disaster recovery plan) и продумывать архитектуру хранения данных и резервных копий.
Второй важный аспект новых обязанностей ИТ директора – контроль качества услуг от поставщика. Практически все облачные провайдеры соблюдают SLA по собственным внутренним метрикам, что можем иметь крайне опосредованное значение к бизнес-процессам заказчика. И соответственно внедрение собственной системы мониторинга и контроля становится одним из ключевых проектов при переносе значимых ИТ систем к облачному провайдеру. Продолжая тему SLA необходимо подчеркнуть, что абсолютное большинство облачных провайдеров ограничивают ответственность за неисполнение SLA в месячный абонентский платеж или в долю от платежа. Например, AWS и Azure при превышении порога в доступности в 95% (36 часов в месяц) сделают 100% скидки к абонентской плате, а Яндекс.Облако – 30%.
Ну и конечно же, не надо забывать, что облака бывают не только в исполнении мастодонтов класса Amazon и слонов класса Яндекса. Облака бывают и поменьше — размером с кошку, или даже мышь. Как показал пример CloudMouse, иногда облако просто берет и заканчивается. Вы не получите ни компенсации, ни скидки — вы не получите ничего, кроме тотальной потери данных.
Ввиду указанных выше проблем с реализацией ИТ систем высокого класса бизнес критичности в облачных инфраструктурах в последние годы наблюдается явление «облачной репатриации».
К 2020 году для облачных вычислений пройден пик раздутых ожиданий и концепция находится на пути к канаве разочарований (согласно хайп циклу Гартнер). Согласно исследованиям IDC и 451 Research до 80% корпоративных заказчиков возвращают и планируют возвращать нагрузки из облаков в собственные ЦОДы по причинам:
Что же делать и как все «на самом деле»?
Нет никаких сомнений, что облака пришли всерьез и надолго. И с каждым годом их роль будет возрастать. Однако мы живем не в далеком будущем, а в 2020 году во вполне определенной ситуации. Что же делать с облаками, если вы не стартап, а классический корпоративный заказчик?
Что такое Utility Computing?
в Компьютеры 08.07.2018 0 323 Просмотров
Люди, которые придумывают термины для компьютерных функций, иногда не имеют большого воображения. Если вы думаете, что термины для вычислений достаточно трудные, вы, вероятно, можете выяснить, что это означает. Utility computing – это форма компьютерного сервиса, при помощи которого компания, предоставляющая услугу, взимает с вас плату за то, сколько вы её используете. Подумайте об электрической компании или о водной компании, и она у вас будет. В этом случае вы, как потребитель, платите за ресурсы, которые вы потребляете, а не за ресурсы, которые должен предоставить вам поставщик вычислительной техники для её использования.
Другими словами, Вы не платите за оборудование. В зависимости от того, сколько вы используете вычислительные службы в данный период времени, это может привести к экономии или потере.
Sun был первым, кто предложил утилиты вычислений, в 2000 году. Хьюлетт-Паккард последовала этому через год. Другие крупные игроки, в том числе IBM, в последующие годы использовали опорную платформу utility computing. С такими большими рыночными силами за стоящими за ними, коммунальные вычисления, кажется, вещь будущего.
Но некоторые эксперты предупреждают, что это не так идиллично, как кажется. Подумайте о электрической компании, например. Откуда берётся ваше электричество? Ты знаешь? У вашей электрической компании есть сетка с вашим именем на ней, и эта сетка исходит только от энергии, предназначенной для вас? Конечно, нет.
Это одна из опасностей вычислений. Ваши вычислительные услуги будут исходить из того, что по существу является большим НДС, который обслуживает не только вас, но и множество других клиентов. Это может быть хорошо, если всё, что вы хотите, это место для хранения ваших данных или его анализ один раз в год для целей показателей продаж, но если вы рассчитываете на utility computing, чтобы доставить ваши повседневные, поминутные потребности, вы можете обратить более пристальное внимание на целостность данных и услуг, которые вы получаете от этого поставщика коммунальных вычислений.
Тем не менее, если вы являетесь владельцем малого бизнеса, который, несмотря на свой размер и базу сотрудников, обладает широкими вычислительными потребностями, тогда коммунальные вычисления могут помочь вам оставаться в бизнесе. У вас могут возникнуть потребности в оборудовании, которые вы никогда не сможете скомпилировать с ограниченным бюджетом, но сможете позволить себе «арендовать» через утилиты. Это тот сервис, который Sun, HP, IBM и другие предоставляют и надеются, что этот сервис станет их билетом на ещё один рынок для их услуг.
utility computing
Смотреть что такое «utility computing» в других словарях:
Utility computing — is the packaging of computing resources, such as computation, storage and services, as a metered service similar to a traditional public utility (such as electricity, water, natural gas, or telephone network). This model has the advantage of a… … Wikipedia
Utility Computing — Unter Utility Computing versteht man Techniken und Geschäftsmodelle, mit denen ein Service Provider seinen Kunden IT Dienstleistungen zur Verfügung stellt und diese nach Verbrauch abrechnet. Beispiele solcher Dienstleistungen sind Rechenleistung … Deutsch Wikipedia
Utility computing — Este artículo o sección sobre tecnología necesita ser wikificado con un formato acorde a las convenciones de estilo. Por favor, edítalo para que las cumpla. Mientras tanto, no elimines este aviso puesto el 17 de agosto de 2008. También puedes… … Wikipedia Español
utility computing — noun A form of computing in which the computer resources are consumed like a traditional utility (water, electricity, gas) … Wiktionary
Utility — (engl. ‚Nutzen‘, ‚Versorgungsbetrieb‘) bezeichnet ein Dienstprogramm, Software Werkzeug zur Verwaltung eines Betriebssystems einen Fahrzeugtyp wie zum Beispiel den Holden Utility Landing Craft, Utility, ein Mehrzweck Landungsboot siehe auch:… … Deutsch Wikipedia
Computing — For the formal concept of computation, see computation. For the magazine, see Computing (magazine). For the scientific journal, see Computing (journal). A difference engine: computing the solution to a polynomial function … Wikipedia
utility — ► NOUN (pl. utilities) 1) the state of being useful, profitable, or beneficial. 2) a public utility. 3) Computing a utility program. ► ADJECTIVE ▪ useful, especially through having several functions. ORIGIN Latin utilitas, from utilis … English terms dictionary
computing — noun 1. the procedure of calculating; determining something by mathematical or logical methods • Syn: ↑calculation, ↑computation • Derivationally related forms: ↑computational (for: ↑computation), ↑compute … Useful english dictionary
Utility Film — Unter einem Utility Film versteht man einen sprachfreien oder spracharmen interaktiven Anleitungsfilm, der aus einzelnen, miteinander verlinkten Videoclips besteht. Jeder Handlungsschritt wird in einem separaten wenige Sekunden langen Videoclip… … Deutsch Wikipedia
Utility — The measure of the welfare or satisfaction of an investor or person. The New York Times Financial Glossary * * * utility u‧til‧i‧ty [juːˈtɪlti] noun utilities PLURALFORM 1. [countable usually plural] COMMERCE a large company that provides… … Financial and business terms
utility computing
Смотреть что такое «utility computing» в других словарях:
Utility computing — is the packaging of computing resources, such as computation, storage and services, as a metered service similar to a traditional public utility (such as electricity, water, natural gas, or telephone network). This model has the advantage of a… … Wikipedia
Utility Computing — Unter Utility Computing versteht man Techniken und Geschäftsmodelle, mit denen ein Service Provider seinen Kunden IT Dienstleistungen zur Verfügung stellt und diese nach Verbrauch abrechnet. Beispiele solcher Dienstleistungen sind Rechenleistung … Deutsch Wikipedia
Utility computing — Este artículo o sección sobre tecnología necesita ser wikificado con un formato acorde a las convenciones de estilo. Por favor, edítalo para que las cumpla. Mientras tanto, no elimines este aviso puesto el 17 de agosto de 2008. También puedes… … Wikipedia Español
utility computing — noun A form of computing in which the computer resources are consumed like a traditional utility (water, electricity, gas) … Wiktionary
Utility — (engl. ‚Nutzen‘, ‚Versorgungsbetrieb‘) bezeichnet ein Dienstprogramm, Software Werkzeug zur Verwaltung eines Betriebssystems einen Fahrzeugtyp wie zum Beispiel den Holden Utility Landing Craft, Utility, ein Mehrzweck Landungsboot siehe auch:… … Deutsch Wikipedia
Computing — For the formal concept of computation, see computation. For the magazine, see Computing (magazine). For the scientific journal, see Computing (journal). A difference engine: computing the solution to a polynomial function … Wikipedia
utility — ► NOUN (pl. utilities) 1) the state of being useful, profitable, or beneficial. 2) a public utility. 3) Computing a utility program. ► ADJECTIVE ▪ useful, especially through having several functions. ORIGIN Latin utilitas, from utilis … English terms dictionary
computing — noun 1. the procedure of calculating; determining something by mathematical or logical methods • Syn: ↑calculation, ↑computation • Derivationally related forms: ↑computational (for: ↑computation), ↑compute … Useful english dictionary
Utility Film — Unter einem Utility Film versteht man einen sprachfreien oder spracharmen interaktiven Anleitungsfilm, der aus einzelnen, miteinander verlinkten Videoclips besteht. Jeder Handlungsschritt wird in einem separaten wenige Sekunden langen Videoclip… … Deutsch Wikipedia
Utility — The measure of the welfare or satisfaction of an investor or person. The New York Times Financial Glossary * * * utility u‧til‧i‧ty [juːˈtɪlti] noun utilities PLURALFORM 1. [countable usually plural] COMMERCE a large company that provides… … Financial and business terms
Облака, сервисы и utility computing
Время монолитных систем прошло, и сегодня стало очевидно, что только слабая связанность может придать сложным системам такие критически важные качества, как динамичность и масштабируемость.
Время монолитных систем прошло, и сегодня стало очевидно, что только слабая связанность может придать сложным системам такие критически важные качества, как динамичность и масштабируемость, однако для создания таких систем ничего лучшего, чем сервисы, пока не придумано.
Сложность — одна из важных характеристик современных информационных систем, отличающая их от других творений человека. По уровню сложности компьютерные системы приближаются к природным экосистемам, которые возникли в результате сочетания глобальных геологических и биологических процессов, но предстают перед наблюдателем настолько тонко организованными и сбалансированными, что невольно возникает ощущение «руки творца». Аналогичное впечатление вызывают современные компьютерные системы, сочетающие в себе облачные и сервисные начала, возникшие в результате эволюции коммунальной (мультиарендной, мультитенантной) организации ИТ, облаков и связующего их слоя в виде сервисов различных видов. И первое, и второе, и третье возникло и развивалось изначально независимо — у каждого из этих технологических направлений есть своя история, однако случилось так, что в какой-то момент времени они «нашли» друг друга и возникло единое целое, которое хочется назвать «трехликим Янусом». Связка между тремя началами настолько прочна, что практически невозможно ее разорвать и «разложить все по полочкам», последовательно показав, что из чего следует. Поэтому пока удается лишь нарисовать достаточно мозаичную картину, состоящую из отрывочных наблюдений, из которых, надеюсь, можно будет сложить целостную картину.
Utility computing
Как бы часто ни употреблялось слово «архитектура» по отношению к информационным системам, подлинную архитектурную стройность они еще не обрели — из состояния ручного хаоса многие предприятия впали в состояние хаоса автоматизированного.
Лет через пятьдесят, а может быть и раньше, пользование вычислительными и другими услугами, обеспечивающими работу с данными, будет так же естественно, как пользование всеми остальными коммунальными инфраструктурами — ведь не топит же сегодня городской житель печь, не зажигает свечи и не приносит домой бидоны с керосином. Предположение о принципиальной возможности организовать ИТ так, чтобы сделать их похожими на традиционные коммунальные услуги, родилось уже давно, тем не менее вплоть до самого последнего времени идея utility computing оставалась нереализуемой из-за отсутствия решения двух базовых задач, о существовании которых при пользовании другими коммунальными услугами мы не задумываемся. Первая — унификация и интеграция ресурсов; в случае воды, газа и даже электричества унификация и интеграция получаются сами собой — для этого не требуется применения каких-то специальных приемов. Вторая — распространение; с естественными ресурсами тоже сложностей нет, а нужны только сети и простейшие конечные устройства. Чего нельзя сказать об ИТ, где понадобилось не одно десятилетие на создание технологий виртуализации и управления ресурсами, решающих первую задачу, и на развитие сервисов, решающих вторую.
Первым свое видение utility computing изложил в 1955 году Херб Грош, более известный как создатель одноименного закона, постулирующего рост производительности компьютера как функцию квадрата стоимости. Грош считал, что вполне естественно для того времени и для сотрудника IBM, что проблему создания utility computing решает всеобщее подключение к мэйнфреймам через простые терминалы. Такой подход имеет право на существование — например, во Франции была успешно реализована построенная на подобных принципах национальная информационная система Minitel, созданная France Telecom и предоставляющая абонентам разную информацию — от прогноза погоды и расписания поездов до котировок акций. Дальнейшее развитие идея мультиарендности получила в трудах создателя термина «искусственный интеллект», соавтора языков Lisp и Algol Джона Маккарти. Однако какими бы мощными ни были мэйнфреймы, они не могли стать основой для utility computing по следующим причинам:
Все эти перечисленные черты utility computing предвосхитил канадский ученый Дуглас Паркхил в своей книге «The challenge of the computer utility», опубликованной еще в 1966 году. Удивительная книга, удивительный автор и удивительные предвидения, настолько актуальные сегодня, что складывается впечатление, будто книга написана вчера. Паркхил раньше других осознал, что, помимо собственно вычислительной мощности, utility computing — это еще и функции по хранению, сбору и распределению информации, а также обеспечение следующих возможностей: одновременная поддержка большого числа пользователей; параллельное выполнение множества программ; представление ресурсов в таком виде, чтобы у пользователя создавалось впечатление, будто он работает на собственном компьютере; оплата услуг по мере их потребления; отсутствие ограничений по потребляемым ресурсам. Кроме наиболее общих форм представления коммунальных ИТ-услуг, могут быть частные системы общего назначения, публичные системы специального назначения и целая иерархия систем от частных до общенациональных. Сегодня эти тезисы звучат банально, но какой силой предвидения нужно было обладать, чтобы прийти к этим выводам более сорока лет назад?
Бристольскую лабораторию HP можно отнести к числу тех немногих мест, где концепцию utility computing превращают из маркетингового лозунга в реальные продуктивные решения.
В 90-е годы центр разработки utility computing сместился в Бристольскую лабораторию HP, где появилась идея UDC (Utility Data Center), реализовать которую решили на Unix-машинах, творчески переработав наследие мэйнфреймов, чтобы понять, как можно изолировать приложения, работающие в одной среде. Еще в 2004 году Джон Мэнли, руководивший направлением UDC, отмечал, что информационные системы представляют собой плохо упорядоченный набор разнообразных ресурсов, и взамен их, в идеале, должна быть создана инфраструктура потребления ИТ-сервисов, обеспечивающая доступ к виртуализованному пулу ресурсов. Для этого в HP на первом этапе были созданы виртуализуемые системы на базе серверов Superdome, затем развернуты ЦОД, а потом планировалось предложить некие глобальные виртуальные структуры. Уже тогда в компании понимали, что utility computing чаще всего сравнивали с системами снабжения, относящимися к категории непрерывных услуг, однако на самом деле услуги, с которыми мы имеем дело в обыденной жизни, по большей части имеют разовый характер. Действительно, чаще потребитель обращается куда-то, где по его требованию выполняется определенный набор действий, и он получает конкретный, часто уникальный результат. Мэнли назвал такие услуги словом batch (объем продукции, выдаваемый в один раз), что, кстати, тоже напоминает мэйнфреймы с их работой в пакетном режиме.
Свою нынешнюю популярность идея коммунальности обрела прежде всего благодаря усилиям популяризатора Николаса Карра с его книгой «The Big Switch», в которой он утверждает, что вместе с облаками ИТ превращаются в «технологию общего назначения» (General-Purpose Technology, GPT). Действительно, появление очередной GPT приводит к инновационному росту, так было, например, с паром и электричеством, и если по степени освоенности сравнивать utility computing с электричеством, то, скорее всего, мы находимся где-то на уровне начала прошлого века и пока еще не можем оценить те последствия, к которым приведет массовое распространение облачных технологий.
Однако есть ряд черт, качественно отличающих ИТ от других GPT, — прежде всего то, что Мэнли назвал batch, и то, чем batch-ресурсы отличаются от непрерывных. Кроме того, темпы инноваций сегодня намного выше, чем тридцать лет назад, когда компьютер с производительностью современного планшета стоил миллион долларов; ничего похожего в других областях до сих пор не наблюдалось. Однако в ИТ гораздо сложнее решаются проблемы масштабирования, где действуют ограничения, устанавливаемые, например, известным законом Амдала, не позволяющим линейно наращивать компьютерные мощности, как в электричестве. Либо ограничения, следующие из теоремы CAP и требующие иных, чем реляционные, подходов при работе с большими объемами данных.
Еще одна проблема ИТ — расстояния; и хотя данные с вычислениями, казалось бы, куда менее материальны, чем другие GPT, здесь приходится передавать непосредственно результаты, а не электромагнитную волну, отсюда проблемы задержки в обмене данными и потребность в каналах с высокой пропускной способностью. И конечно же, имеется отдельная проблема безопасности — разнообразие угроз и, соответственно, методов защиты от них гораздо больше, чем в других GPT. Но, пожалуй, самое главное, ставшее ясным совсем недавно, отличие облака от остальных GPT — это то, что формой распространения ресурсов являются сервисы.
Итак, облака с их разнообразными технологиями виртуализации преобразуют ИТ в форму, доступную для распределения ресурсов между пользователями, а сервисы служат основным инструментом для распределения. К сожалению, термин «сервис» и в английском, и в русском заметно перегружен, он используется и как «услуга», и как «служба», и как «эксплуатация», и еще во многих смыслах в зависимости от контекста.
Обещания и реальность
Сегодня еще рано говорить о провайдерах облаков, предоставляющих любые виды сервисов и в любом объеме, — провайдеры пока реально могут предложить лишь определенный каталог сервисов для своих заказчиков, с определенными SLA, уровнем масштабирования и т. д. Построение универсальной облачной инфраструктуры для провайдера является серьезным вложением в свой ЦОД, а также в проектирование управления сервисами, поэтому любые заявления о возможности предоставления любых облачных сервисов надо пока воспринимать критически.
Кроме этого, на пути реализации всех обещанных выгод от виртуализированных облачных сред имеется ряд препятствий, причем не технологического плана, а связанных с готовностью рынка. Сегодня ожидания заказчиков от облаков часто слишком завышены, однако далеко не все умеют считать операционные расходы на обслуживание сервисов, а ведь это одна из основных статей сокращения расходов. Есть также чисто технические моменты — например, наличие каналов связи до ЦОД провайдеров облаков. Дополнительно к этому, в случае возникновения потребности в гибридном облаке, надо прежде узнать о наличии приложений, умеющих работать в распределенной среде. Есть еще нюансы, связанные с доверием к облачным средам, обеспечением безопасности и соответствием требованиям регуляторов.
Вместе с тем к приходу облаков заказчику надо готовиться и при создании портфеля сервисов учитывать уже не только собственные ресурсы, но и ресурсы провайдеров облаков, а это пока достаточно сложно. Есть много вещей, которые не всегда можно реализовать технически — например, учесть, что наличие каталога сервисов подразумевает под собой и SLA, и стоимость. В случае гибридного облака надо понимать, что сервис будет работать не только у заказчика, но и у провайдера, а SLA и стоимость ресурсов в обоих случаях могут не совпадать.
Отдельно следует сказать про роль ITSM в управлении масштабируемых надежных облачных инфраструктур. Задача управления ИТ-сервисами — помочь внедрить лучшие практики управления сервисом. И, с моей точки зрения, неважно, где этот сервис находится, — у провайдера или у заказчика. Правильно спланированный сервис поможет понять, насколько должна быть масштабируема и надежна инфраструктура его поддержки. В общем случае нет каких-либо особенностей в работе ИТ-служб по управлению облачными сервисами — имеется инфраструктура, сервисы и SLA, а задача айтишников традиционно состоит в обеспечении максимально эффективного использования ресурсов для оптимизации расходов бизнеса.
— Виталий Савченко (6110035@veeam.com), руководитель группы системных инженеров Veeam Software, Россия и СНГ (Москва).
Облака
Несмотря на существование, казалось бы, принятых определений, в точности сказать, что такое облака, невозможно, а есть только несколько их основных отличительных свойств.
Сегодня все это уже звучит почти банально, однако видные эксперты, собравшиеся на конференции Cloud Interop для обсуждения предмета cloud computing, пришли к неутешительному выводу: «Мы не вполне понимаем, о чем приходится говорить». Облака приобретают разные формы, они построены из разных компонентов, и, чтобы понять происходящее, требуются систематизация и классификация, или, как сегодня говорят, таксономия.
Попытка облачной таксономии показана на рис. 1 где выделены пять признаков: физическая модель (Deployment Model), используемые стандарты (Standard), технологии (Technology), философия (Philosphy) и модель предоставления сервисов (Model). С учетом слабости такой классификации, она все-таки дает общее представление, хотя и не учитывает, что само облако является сложной системой, а предоставляемые им сервисы служат для создания сложных систем.
Рис. 1. Таксономия облаков
Практика против сложности
Непременными условиями предоставления сервисов из облаков является оплата по факту использования, самообслуживаемость и масштабируемость — такие сервисы, как VMware SlideRocket (SaaS), Socialcast (SaaS), ITBM (SaaS) или CloudFoundry (PaaS), удовлетворяют этим требованиям. Другие сервисы и решения, предлагаемые компанией, дают возможность нашим партнерам предложить решения, удовлетворяющие перечисленным требованиям. Если говорить про IaaS, то с недавнего времени мы предлагаем комплексное решение vCloud Suite, позволяющее создать инфраструктуру частного, публичного или гибридного облака.
Провайдерам облаков, решившим поддерживать любые виды сервисов и в любом объеме, безусловно, следует сделать прежде масштабные инвестиции в инфраструктуру, однако одному провайдеру сложно охватить все многообразие платформ, моделей сервисов и их доставки. Наша приоритетная зада-
ча — помочь организациям-потребителям сервисов в создании облачных конфигураций, соответствующих уникальным бизнес-требованиям. Вместе с тем на пути реализации всех выгод от виртуализированных облачных сред имеется ряд препятствий. Виртуализация — это только один из кирпичиков, требуемых для построения облака, решающий проблему объединения ресурсов в пулы и необходимый в качестве средства упрощения размещения и управления рабочими нагрузками. К сожалению, далеко не все провайдеры облачных сервисов дополняют виртуализацию решениями по самообслуживанию, автоматизации процессов эксплуатации, обеспечению безопасности, доступности, а также средствами оценки стоимости по факту потребления. Поэтому основное препятствие на пути реализации всех выгод от виртуализированных облачных сред, заключается в ошибочном понимании под облаком лишь пула виртуальных машин.
Если говорить об управлении ИТ-активами гибридных облаков, то каких-то новых задач управления здесь нет, однако следует учесть, что известные задачи, относящиеся к Services Portfolio Management, в динамичной и гибкой среде гибридного облака решаются иначе. Вместе с тем управление ИТ-сервисами, возникшее в результате необходимости переноса внимания с технологий и внутренней организации провайдера ИТ-услуг на качество предоставляемых сервисов, в случае облаков должно опираться на конкретную практику и анализ лучшего опыта. Такие хорошо знакомые по ITIL понятия, как Service Strategy, Service Design, Service Transition, Service Operation и Continuous Service Improvement, применимы и для облачных инфраструктур. Даже если представить себе некую облачную инфраструктуру, гарантирующую 100-процентную доступность предоставляемых на ее основе сервисов, то все равно останется множество задач, эффективное решение которых без ITSM не представляется возможным, например управление конфигурациями.
Подход VMware к обеспечению управления облачными сервисами заключается в трансформации роли ИТ предприятия и превращению ее в сервис-брокера, осуществляющего оркестрацию сервисов, предоставляемых как внутренней ИТ-организацией, так и внешними провайдерами. При этом возникает ряд вопросов, связанных с тем, насколько детализированным должно быть управление внешними сервисами. Например, укрупнение сторонних сервисов позволяет использовать уже существующие в организации практики supplier management, однако это может усложнить реализацию управлениями, изменениями и релизами.
В целом реализация управления изменениями, доступностью и производительностью может оказаться неожиданно сложной в случае облачных сервисов. Для того чтобы помочь организациям эффективно решать задачи ITSM в случае облачных сред, VMware предлагает как различные программные решения, оптимизированные для облаков и автоматизирующие различные процессы ITSM, так и набор лучших практик по проектированию (vCAT) и эксплуатации (Cloud Ops) облачных сервисов.
— Владимир Ткачев (vtkachev@vmware.com), технический директор VMware в России и СНГ (Москва).
Сервисы
Существование сервисов поддерживается системой стандартов и, что не менее важно, системой контактов — кроме формальных правил, по которым происходит взаимодействие, требуется еще и знание того, с кем и каким образом следует производить взаимодействие, своего рода адресная книга. Хорошо известные стандарты SOAP, WSDL, Atom и REST необходимы, но недостаточны — бизнес-сервисы, помимо стандартов, предполагают знание контактов, но обычно это обстоятельство упускают. Под контактами понимают следующие свойства сервисов: когда сервис доступен, какова его производительность, как часто и какое количество раз можно его использовать, кто несет ответственность за возможные сбои, как сервисы изменяются, кто отвечает за модернизацию и т. п. Использование контактов является важной частью управления — собственно говоря, с использованием контактов и строится слабосвязанная системная архитектура. Стандарты служат средством, обеспечивающим согласованность компонентов, а из контактов складывается желаемая связанность. Сочетание стандартов и контактов позволяет автоматически вызывать для исполнения тот функционал, который нужен в данном местe и в данное время.
Есть еще один источник для ошибочной трактовки сервисов SOA — именование их веб-сервисами, хотя прямой связи с WWW может и не быть, а связывает их, пожалуй, лишь то, что стандартизацией занимается консорциум W3C. И напротив, облачные сервисы, или, как их еще называют, облачные архитектурные образы (Cloud Architecture Pattern, CAP), непосредственно связаны с Интернетом, они передаются по сети.
SOA и CAP разделяют ряд общих положений. Прежде всего и то и другое — слабосвязанные системы сервисов, то есть какая-то часть работы отдается провайдеру или другой части бизнес-системы, а пользователь не обременяет себя знанием устройства модуля, реализующего его запрос, что открывает неограниченную возможность для модернизации системы при условии сохранения контрактных обязательств. В то же время между SOA и CAP есть существенные различия. Каждый из компонентов SOA реализует какую-то свою функцию, а совместно они образуют функционал системы — в смысле масштабирования такую инфраструктуру можно назвать горизонтальной. Напротив, совместно сервисы CAP образуют стек, и такую инфраструктуру, скорее, стоит назвать вертикальной.
Другое отличие в ориентации — в том, что первично. По замыслу, SOA подчинена приложениям, то есть при делении системы на составляющие главным обстоятельством, влияющим на то, «как разрезать», является функция, которую назначают тому или иному компоненту. Иначе говоря, при проектировании сначала выделяют задачи, а потом делят систему на части таким образом, чтобы компоненты можно было в дальнейшем повторно использовать. В случае же CAP функциональность не рассматривается, сервисы делятся по той роли, которую они играют в общем стеке, — проектирование облака не связывается с решаемыми на нем задачами.
_250.png "Otkrytye sistemy. SUBD 2 (1392) 250") |
| Рис. 2. Шестиуровневая модель облака |
Говоря о любых облачных сервисах (*aaS), следует иметь в виду, что облака есть способ потребления технологий в привязке к бизнес-процессам, но не собственно технологии. Облака позволяют избавиться от забот об инфраструктуре и сосредоточиться на количестве и качестве потребляемых ресурсов. С пользовательской точки зрения *aaS описывает услуги, оказываемые тем или иным многократно используемым (reusable), тонко гранулированным (fine-grained) программным или аппаратным компонентом, размещенным в облаке. Из всего множества различных *aaS чаще всего встречаются SaaS, IaaS и PaaS, однако в облаках могут предоставляться в сервисной форме системы хранения (Storage as a Service, SaaS), безопасности (Security as a Service, SECaaS), СУБД (Database as a service, DaaS), средства мониторинга и управления (Monitoring/Management as a Service, MaaS), коммуникации, контент и вычисления (Communications, Content & Computing as a Service, CaaS), контроль идентификации (Identity as a Service, IDaaS), резервное копирование (Backup as a Service, BaaS) и десктопы (Desktop as a Service, DaaS). Каждый из перечисленных сервисов можно соотнести с шестиуровневой моделью облака (рис. 2).
На уровне IaaS и SaaS клиент получает в пользование нужный ему объем оборудования, поддерживаемого и обслуживаемого провайдером; PaaS обычно предоставляет в пользование ресурсы серверов приложений; SaaS позволяет использовать уже готовые приложения типа CRM, ERP и т. п. Мониторинг с применением MaaS пока еще новинка, но, по оценкам экспертов, весьма перспективная, поскольку позволяет упрощать процессы миграции приложений между частными и глобальными облаками.
Пока нет каких-либо международных структур, координирующих процессы формирования облаков, а предпринимаются лишь отдельные попытки различных некоммерческих организаций урегулировать ситуацию. В конце октября 2010 года был объявлен альянс Open Data Center Alliance из 50 крупнейших компаний, призванный найти приемлемую для всех модель облаков. Компания Rackspace совместно с NASA выступила с инициативой открытия кодов OpenStack, ведь в идеале стандарты должны распространяться на все уровни стека облачных сервисов, причем чем выше уровень, тем сложнее задача стандартизации. Структуру этого стека, ставшего стандартом де-факто, приняли сейчас все производители, но это вовсе не значит, что между продуктами разных поставщиков есть хоть какая-то совместимость. Нижние уровни (DaaS и IaaS) можно унифицировать уже сейчас, а вот как быть с верхними, пока сказать сложно.
Можно выделить два направления в стандартизации для IaaS: первое распространяется на внутреннее устройство облаков, а второе — на внешние интерфейсы к ним. Первое есть не что иное, как формат описания виртуальных ресурсов внутри шаблонов виртуальной машины, а второе — программный интерфейс для работы с ней. После создания виртуальных машин возникает потребность в управлении ими: загрузке и выгрузке, контроле и конфигурировании готовых шаблонов, а чтобы сделать все это без излишних сложностей, необходим соответствующий интерфейс.
Что же касается SaaS, то здесь дела обстоят плохо — стандартизация приводит тут к ограничению творческой составляющей и, следовательно, качества решения, но в то же время отсутствие совместимости может обернуться большими убытками. Известно пока немного попыток разработки стандартов для SaaS: создание в 2010 году организации CloudAudit, или A6 (Automated Audit Assertion Assessment and Assurance API), и vCloud — как попытка насильственной установки стандарта де-факто на базе наиболее распространенных решений.
Усложнение производственных и информационных систем с неизбежностью приводит к созданию сервисных архитектур, которым сегодня уделяется огромное внимание, но на этом фоне собственно сервисы остаются в стороне.
Альтернативный подход предпринят организацией OGF (Open Grid Forum), отражающей желание некоторых производителей и академической среды, сформировавшейся вокруг грид, выработать единый взгляд на облака. Результатом деятельности такой организации стало создание рабочей группы и инициативы OCCI (Open Cloud Computing Interface), направленной на согласование всех API, в том числе и Amazon AWS, GoGrid и Flexiscale. Здесь же надо упомянуть работу по стандартизации доступа к данным — создание интерфейса SNIA Cloud Data Management Interface (CDMI), который стал первым промышленным открытым стандартом на управление хранением данных в облаке. В разработке документа приняли участие более 180 экспертов, входящих в SNIA Cloud Storage Technical Work Group (TWG). Стандарт CDMI распространяется на публичные, частные и гибридные облачные решения, и ожидается, что он будет использован сервис-провайдерами и производителями инфраструктурных облачных решений. Основанный на протоколе REST, CDMI призван обеспечить единый формат хранимых метаданных в публичных, частных и гибридных облачных средах, охватывая все аспекты хранения данных в облаке, начиная от обмена и миграции данных до управления уровнем сервиса и шифрованием. Использование этого стандарта в облачных решениях позволит заказчикам, за счет единого формата хранения метаданных, безболезненно перемещать основные данные между различными облачными средами и разными поставщиками сервисов. Стандарты OCCI и CDMI взаимодополняют друг друга, построены по общим принципам и ориентированы на близкие технологии, но пока их можно рассматривать лишь как стартовые точки для будущего более широкого процесса стандартизации. В идеале стандарты должны распространяться на все уровни стека облачных сервисов (рис. 2), причем чем выше уровень, тем сложнее задача стандартизации.
Очевидно, что инфраструктура поддержки облачных сервисов должна быть совершенно иной, чем классическая монолитная, и, скорее всего, под влиянием облаков более востребованы будут методы управления ИТ-сервисами. Некоторые эксперты считают, что поскольку приложения, инфраструктуры и целые бизнес-процессы предоставляются в виде сервисов, то сегодня нет другого инструмента для управления ими, кроме ITSM. Потребностям облаков отвечает версия библиотеки ITIL v3, в которой постулируется концепция сервиса как ценности для бизнеса, которую формируют ИТ на базе своих активов: оборудования, программных решений и человеческих компетенций. С ростом востребованности публичных облаков будут созданы стандартные механизмы внешнего регулирования рынка облачных сервисов и появятся метрики качества их предоставления, которые позволят выстроить нормальные финансовые взаимоотношения между провайдерами и потребителями облачных сервисов.
Просто о сложном
Здравый смысл подсказывает, что в любой сфере — от социальной до технической — есть предел сложности монолитных систем управления. Яркий пример — крах плановой системы социалистической экономики. Пагубность гигантизма не понимали не только кибернетики-утописты, мечтавшие о создании в СССР Общегосударственной автоматизированной системы учета и обработки информации (ОГАС), но и более «трезвые» разработчики систем управления для ракетных крейсеров типа «Тикондерога». Это был огромный и дорогостоящий проект — с 1981 по 1992 год для ВМФ США было построено 27 таких суперкораблей, отличавшихся от предшественников высочайшим для того времени уровнем компьютеризации всех возможных функций. В крейсерах вообще не была предусмотрена возможность ручного управления, но проект явно опередил время. Начало восьмидесятых — расцвет мини-ЭВМ и появление микропроцессоров, а крейсер «Тикондерога» был спроектирован как монолит, без возможности обновления программного и аппаратного обеспечения. Постепенно оказалось, что за плановый период эксплуатации таких кораблей, составляющий не менее 30 лет, вооружение успевает безнадежно устареть морально и уже в середине этого срока его нужно менять. При вполне пригодных к эксплуатации корпусах, машинах и механизмах дешевле построить новые корабли, чем пытаться доводить крейсеры этого типа до уровня, соответствующего времени. В итоге, прослужив половину положенного срока, один корабль уплыл в музей, другой стал учебным пособием, три пока в строю, а остальные пустили на плавучие мишени либо подготовили для продажи дружественным странам.
Избежать судьбы проектов «Тикондерога» и ОГАС вполне позволила бы ориентация на сервисные принципы слабой связности (loosely coupling). Данный термин предложил специалист по организационной психологии, профессор Карл Вейк; по его мнению, любая организация, в частном случае информационная система, подчиняется тем же эволюционным законам, что и биологическая система, которая изменяется под влиянием воздействий из внешней среды. Одним из условий успешной эволюции является слабая связанность между компонентами, когда отдельному компоненту нужно обладать ограниченными знаниями об остальных или вообще не знать о них ничего.
Как связаны между собой предприятие следующего поколения, архитектура и облака? Они взаимно дополняют друг друга. Современные предприятия и организации становятся настолько сложными системами, что без отказа от монолитности в пользу слабой связанности невозможно создать архитектуры, обладающие достаточной динамичностью и способностью к масштабированию, а размещенные в облаках сервисы на функциональном, инфраструктурном и эксплуатационном уровнях как раз и открывают возможность для создания таких систем. Преимущества слабо связанных систем по сравнению с монолитными известны давно, но для их реализации не доставало достаточной мощности компонентов и средств взаимодействия между ними.
Поделитесь материалом с коллегами и друзьями