Очередной взгляд на облака. Что такое частное облако?

    Рост вычислительных мощностей и развитие технологий виртуализации платформы x86 с одной стороны, и распространение ИТ-аутсорсинга с другой стороны привели к концепции utility computing (ИТ как коммунальная услуга). Почему бы не платить за ИТ так же, как за воду или электричество – ровно столько и ровно тогда, когда это нужно, и не более.

    В этот момент и появилась концепция облачных вычислений – потребление ИТ услуг из «облака», т.е. из некоего внешнего пула ресурсов, не заботясь о том, как и откуда берутся эти ресурсы. Так же, как мы не заботимся об инфраструктуре насосных станций водоканала. К этому моменту была проработана и другая сторона концепции – а именно понятие ИТ-услуг и как ими управлять в рамках ITIL / ITSM.

    Был разработан целый ряд определений облаков (облачных вычислений), но при этом не следует относиться к ним как к истине в последней инстанции – это лишь способ формализовать способы предоставления utility computing.

    • «Облачные вычисления – это технология распределенной обработки данных, в которой компьютерные ресурсы и мощности предоставляются пользователю как Интернет-сервис» Википедия
    • «Облачные вычисления представляют собой модель для обеспечения удобного сетевого доступа к общему пулу настраиваемых вычислительных ресурсов (например, сетей, серверов, систем хранения данных, приложений и услуг) по требованию, которые можно быстро выделить и предоставить с минимальными управленческими усилиями или минимальным вмешательством со стороны поставщика услуг» NIST
    • «Облачные вычисления – это парадигма обеспечения сетевого доступа к масштабируемому и гибкому пулу распределяемых физических или виртуальных ресурсов, предоставляемых в режиме самообслуживания и администрируемых по требованию» ISO/IEC 17788:2014. Information technology — Cloud computing — Overview and vocabulary.

    Согласно NIST существует три основных типа облаков:

    1. IaaS – Infrastructure as a Service — Инфраструктура как сервис
    2. PaaS – Platform as a Service — Платформа как сервис
    3. SaaS — Software as a Service Программное обеспечение как сервис



    Для совсем упрощенного понимания разницы давайте рассмотрим модель Pizza-as-a-Service:



    NIST определяет следующие необходимые черты ИТ услуги, позволяющие считаться облачной.

    • Универсальный сетевой доступ (broad network access) – услуга должна иметь универсальный сетевой интерфейс, дающий возможность подключения и использования услуги практически кому угодно с минимальными требованиями. Пример – чтобы использовать электрическую сеть 220В достаточно подключиться к любой розетке со стандартным универсальным интерфейсом (вилка), который не меняется от того, чайник это будет, пылесос или ноутбук.
    • Измеримость сервиса (measured service) – ключевой характеристикой облачной услуги является измеримость сервиса. Возвращаясь к аналогии с электричеством – вы оплатите ровно столько, сколько потребили с минимальной гранулярностью, вплоть до затрат на один раз вскипятить чайник, если за весь месяц вы были в доме один раз и выпили чашку чая.
    • Самостоятельное конфигурирование сервисов по требованию (on demand self service) – облачный провайдер предоставляет заказчику возможность разумного конфигурирования сервиса, без необходимости взаимодействия с сотрудниками провайдера. Для того, чтобы вскипятить чайник совершенно необязательно заранее связываться с Энергосбытом и заранее их предупреждать и получать разрешение. С момента как дом подключен (заключен договор) все потребители могут самостоятельно распоряжаться предоставленной мощностью.
    • Мгновенная эластичность (rapid elasticity) – облачный провайдер предоставляет ресурсы с возможностью мгновенного наращивания / снижения мощности (в определенных разумных рамках). Как только чайник включен – провайдер немедленно выдает в сеть 3 кВт мощности, и как только выключен – снижает выдачу до нуля.
    • Объединение ресурсов в пул (resource pooling) – внутренние механизмы провайдера услуг позволяют объединять отдельные генерирующие мощности в общий пул (бассейн) ресурсов с дальнейшим предоставлением ресурсов как услуги различным потребителям. Включая чайник, нас менее всего волнует с какой конкретно электростанции поступает мощность. И все остальные потребители потребляют эту мощность вместе с нами.

    Важно понимать, что описанные выше характеристики облака взяты не с потолка, а являются логическим выводом из концепции utility computing. И публичная услуга должна обладать этими характеристиками в рамках концепции. При несоответствии той или иной характеристике услуга не становится хуже и не становится «ядовитой», она всего лишь перестает быть облачной. Ну а кто сказал, что все услуги должны?

    Почему я об этом отдельно говорю? За прошедшие 10 лет с момента появления определения NIST было много споров об «настоящей облачности» согласно определения. В США до сих пор иногда применяется в судебной сфере формулировка «соответствует букве закона, но не духу» — и в случае с облачными вычислениями главное именно дух, ресурсы в аренду в два клика мышью.

    Необходимо отметить, что вышеперечисленные 5 характеристик применимы к публичному облаку, но при переходе к частному большинство из них становятся опциональными.

    • Универсальный сетевой доступ (broad network access) – в рамках частного облака организация полностью контролирует как генерирующие мощности, так и клиентов-потребителей. Таким образом, данную характеристику можно считать автоматически выполняемой.
    • Измеримость сервиса (measured service) – это ключевая характеристика концепции utility computing, оплата по факту потребления. Но как же оплачивать организации самой себе? В данном случае идет деление генерации и потребления внутри компании, ИТ становится провайдером, а бизнес-подразделения потребителями услуг. И взаиморасчет происходит между подразделениями. Возможно два режима работы: chargeback (при реальных взаиморасчетах и движении финансов) и showback (в виде отчетности в потреблении ресурсов в руб, но без движения финансов).
    • Самостоятельное конфигурирование сервисов по требованию (on demand self service) – внутри организации может быть общая ИТ служба, и в этом случае характеристика теряет смысл. Однако при наличии собственных ИТ-специалистов или администраторов приложений в бизнес-подразделениях необходимо организовывать портал самообслуживания. Вывод – характеристика опциональна и зависит от структуры бизнеса.
    • Мгновенная эластичность (rapid elasticity) – в рамках организации теряет смысл ввиду фиксированности набора оборудования для организации частного облака. Может ограниченно применяться в рамках внутренних взаиморасчетов. Вывод – для частного облака неприменимо.
    • Объединение ресурсов в пул (resource pooling) – на сегодня уже практически не существует организаций, не применяющих серверную виртуализацию. Соответственно можно считать данную характеристику автоматически выполняемой.

    Вопрос: Так что же такое все таки это ваше частное облако? Что компании нужно купить и внедрить, чтобы его построить?

    Ответ: частное облако – это переход к новой административной модели взаимодействия ИТ-Бизнес, который на 80% состоит из административных мер и только на 20 из технологий.

    Оплата только за потребленные ресурсы и легкий вход, без необходимости закопать несколько сотен миллионов нефти в капитальных затратах, обусловили новый технологический ландшафт и появление компаний-миллиардеров. Например современные гиганты Dropbox и Instagram появились как стартапы на AWS с нулевой собственной инфраструктурой.

    Необходимо отдельно подчеркнуть, что инструменты управления облачными услугами становятся значительно более опосредованными, а ключевой обязанностью ИТ директора становится подбор поставщиков и контроль качества. Давайте рассмотрим проблематику этих двух новых обязанностей.

    Появившись как альтернатива классической тяжелой инфраструктуре с собственными ЦОДами и железом, облака обманчиво легки. В облако легко войти, но вот вопрос выхода обычно обходится стороной. Как и в любой другой отрасли облачные провайдеры стремятся к защите бизнеса и усложнении конкуренции. Единственный серьезный конкурентный момент возникает лишь при первичном выборе поставщика облачных услуг, а далее поставщик приложит максимум усилий, чтобы заказчик от него не ушел. Причем далеко не все усилия будут направлены на качество услуг или их ассортимент. Прежде всего, это поставка уникальных услуг и использование нестандартного системного ПО, затрудняющего переход к другому провайдеру. Соответственно, при выборе поставщика услуг необходимо одновременно формировать план перехода от этого поставщика (по сути полноценный DRP – disaster recovery plan) и продумывать архитектуру хранения данных и резервных копий.

    Второй важный аспект новых обязанностей ИТ директора – контроль качества услуг от поставщика. Практически все облачные провайдеры соблюдают SLA по собственным внутренним метрикам, что можем иметь крайне опосредованное значение к бизнес-процессам заказчика. И соответственно внедрение собственной системы мониторинга и контроля становится одним из ключевых проектов при переносе значимых ИТ систем к облачному провайдеру. Продолжая тему SLA необходимо подчеркнуть, что абсолютное большинство облачных провайдеров ограничивают ответственность за неисполнение SLA в месячный абонентский платеж или в долю от платежа. Например, AWS и Azure при превышении порога в доступности в 95% (36 часов в месяц) сделают 100% скидки к абонентской плате, а Яндекс.Облако – 30%.



    https://yandex.ru/legal/cloud_sla_compute/

    Ну и конечно же, не надо забывать, что облака бывают не только в исполнении мастодонтов класса Amazon и слонов класса Яндекса. Облака бывают и поменьше — размером с кошку, или даже мышь. Как показал пример CloudMouse, иногда облако просто берет и заканчивается. Вы не получите ни компенсации, ни скидки — вы не получите ничего, кроме тотальной потери данных.

    Ввиду указанных выше проблем с реализацией ИТ систем высокого класса бизнес критичности в облачных инфраструктурах в последние годы наблюдается явление «облачной репатриации».



    К 2020 году для облачных вычислений пройден пик раздутых ожиданий и концепция находится на пути к канаве разочарований (согласно хайп циклу Гартнер). Согласно исследованиям IDC и 451 Research до 80% корпоративных заказчиков возвращают и планируют возвращать нагрузки из облаков в собственные ЦОДы по причинам:

    • Повысить доступность / производительность;
    • Сократить расходы;
    • Для соответствия требованиям ИБ.

    Что же делать и как все «на самом деле»?


    Нет никаких сомнений, что облака пришли всерьез и надолго. И с каждым годом их роль будет возрастать. Однако мы живем не в далеком будущем, а в 2020 году во вполне определенной ситуации. Что же делать с облаками, если вы не стартап, а классический корпоративный заказчик?

    1. Облака – это прежде всего место для сервисов с непредсказуемой или ярко выраженной сезонной нагрузкой.
    2. В большинстве случаев сервисы с предсказуемой стабильной нагрузкой дешевле содержать в собственном ЦОД.
    3. Начинать работу с облаками необходимо с тестовых сред и низкоприоритетных сервисов.
    4. Рассмотрение размещения информационных систем в облаке начинается с разработки методики выхода из облака в другое облако (или назад в собственный ЦОД).
    5. Размещение информационной системы в облаке начинается с разработки схемы резервного копирования в контролируемую вами инфраструктуру.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 2

      +1
      Дополню насчет тестовых сред в случае классического Enterprise, у которого ИТ не является его основной деятельностью. Такого, как например производство, строительство и т.п., и который уже вырастил у себя взрослую большую управляемую инфраструктуру.
      Во всех известных мне случаях имелось такое количество «железа», которое ещё живое и бодрое, но уже не на гарантии, и выведено из Production контура, что его с избытком хватало под размещение тестовых сред. Потребность быстро развернуть что-то реально не влезающее в текущие ресурсы, такая чтобы «вот срочно нужно и нас спасёт только облако» все разы оказывалась надуманной и решалась гораздо дешевле у себя, на земле.
      Реальные сценарии необходимости использования облака можно дополнить теми случаями, когда нужна высокая отказоустойчивость за счет дублирования размещения ИТ сервисов, спроектированных с учетом возможности распараллелить и задублировать все роли и компоненты. Как правило это блоки B2C, несколько реже B2B. Но и в таких сценариях одна нога остается на земле, что существенно снижает общие текущие затраты.
      Точкой раздела у думащих и считающих деньги людей давно является TCO при заданном SLA
      на платформу размещения в пересчете на срок амортизации оборудования. Самый частый маркетинговый ход обман — это расчет TCO из сценария «допустим у вас ничего нет...» Но даже тут без подтасовок с якобы жизненно необходимым высоким SLA оправдать выгодность реализации решеня в облаке бывает непросто.
      Я за облака, но не как цель, а как ещё один инструмент решения задачи «высокая доступность за разумные деньги», в общем за нормальный, грамотный гибрид.
        0
        >Во всех известных мне случаях имелось такое количество «железа»

        У меня часто есть заказчики, у которых железа нет.

        > использования облака можно дополнить теми случаями, когда нужна высокая отказоустойчивость за счет дублирования размещения ИТ сервисов

        А вот здесь зачастую проще, надежнее и дешевле сделать колокейшн, а не облако. Просто потому что облако — это другой ландшафт, другой подход, другое все.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое