Заметки на полях: облако типа IaaS

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

И так, идеи которые лежат в основе IaaS:
  • агрегирование ресурсов в динамически разделяемые пулы
  • модель экономии pay-as-you go (или “по требованию”)
  • автоматизация управление ресурсами (zero-touch интерфейс пользователям и развитый инструмент перекрестного разделения и управление облаком)

Такие базовые идеи и принципы присутствуют в любой модели IaaS. Эти идеи разработаны и сконструированы быть примененными как к облакам сервис провайдеров, так исключительно за стенами предприятия (приватное облако).

И это в общем не новинка! Большинство компаний пытаются выстраивать собственные модели обслуживания внутренних ИТ сервисов приближаясь к этим базовым принципам уже давно.

Подавляющее большинство предприятий сегодня использует модель планирования ресурсов с весьма значимым запасом на внеплановые или планируемые в будущем нагрузки. Это дает некий ограниченный запас гибкости и скорее всего является разумной оправданной необходимостью. Но, так как такая избыточная часть ресурсов либо закупается заранее и простаивает до наступления события того самого будущего, либо проектируется как легкий upgrade, на обработку которого поставщиками могут уходить недели, согласитесь что это весьма далеко от рационализированного использования ресурсов.

Давайте рассмотрим процессы обслуживания нагрузки ресурсами предприятия предлагаемые облаком спроектированного на принципах модели IaaS.

Попробуем смоделировать нагрузку. Допустим вашей компании необходимо сконструировать гиперэффективный дата центр, который будет обладать инструментами самообслуживания по экономической модели pay-as-you go под сервисы начиная от решений Exchange и Sharepoint и заканчивая ландшафтами SAP и Oracle, а так же легко поддерживать задачи разработок и тестирования вашего предприятия.

Конечно, тут необходима абстракция каждого уровня инфраструктуры. Вот краткая диаграмма, которая показывает базовую архитектуру модели, что ожидает пользователь и требования на каждом уровне абстракции.

image
Обратите внимание на:
  • Чем же обеспечивается многопользовательский режим и развертывание виртуальных машин? По определению это происходит в слое виртуализации и выше, представленный на диаграмме решениями vSphere. К примеру, на этой диаграмме используя интерфейс vCloud API, построен портал zero-touch интерфейса пользователя, позволяющий получить преимущества саморазвертывания, самообслуживания, механизм оплаты за услугу и развитый инструмент перекрестного разделения и управление облаком.
  • Необходимо иметь масштабируемый слой вычисления. При этом такой слой должен обладать в своей основе поддержкой экономической модели заложенной в IaaS, другими словами, обеспечить возможность учета испрользования ресурсов, например, деньги/ВМ/час.
  • Такой вычислительный слой должен обладать определенной степенью возможности презентовать (выделять) ресурсов нагрузкам больше, чем имеется физически. Для предприятия это может быть малое значение. Для сервис провайдера значительно большее. Это так же означает, что инструменты позволяющие контролировать заданное качество услуги очень важны.
  • Хранилища в при данном подходе, так же претерпевают значительные требованиям. Они, как и вычислительные ресурсы, должны занять свой абстрактный слой, и, позволяя учитывать ресурсы согласно экономической модели, допустим деньги/Gb/месяц и деньги/IO/месяц, обладать возможностью масштабирования, что позволяло бы начинать с малого и идти к более высокому потреблению.

По материалам: http://virtualgeek.typepad.com/virtual_geek/2009/10/cloud-storage-what-the-hell-is-emc-building.html
  • –10
  • 1,4k
  • 9
Поделиться публикацией

Похожие публикации

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

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

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

    +8
    ни о чём.
      –3
      Рад за вас, что для Вас это уже ни о чем. Для некоторых думаю это будет полезной шпоргалкой, или своеобразным стартом, особенно для сектора предприятий.
      Но все равно спасибо за критику))
      0
      Попробуем смоделировать нагрузку.

      И где расчет и моделирование? Как пример, посчитайте-ка, какова будет нагрузка?

      Исходные данные.
      • Сервер приложений — Resin Open Source,
      • БД — Oracle 11, Размер базы порядка 30 Gb,
      • Нагрузка на сервер — 20 клиентских запросов в минуту.
      • Каждый запрос генерит около 20-30 запросов к БД.


      Ну и какова будет средняя оплата услуг в месяц?

      А по сути статья — просто набор предложений, который начинающим ничего не скажет. Уж лучше бы по нормальному перевели исходную статью.
        0
        Спасибо, учту Ваше пожелание в следующем посте, если хватит кармы))
        0
        Простите, но не могли бы вы сделать вывод к статье? Хотя бы от себя.
          +1
          Основная бизнес идея IaaS та же, что и идея предоставления интернета частным лицам значительно дешевле юридических. Частники статистически как правило значительно не выбирают свой лимит. Отсюда выгода. То же самое с IaaS.

          Если говорить о виртуализации внутри предприятия (может это назвать private IaaS), то это как правило немного другая история.

          1. Pay as you go исчезает, хозяйство то все собственное.

          2. Потребность в инструментарии (автоматизация управление виртуалками и любые другие) уже определяется реальной ситуацией на предприятии. На практике публичный провайдер IaaS не может предвидеть как будут задействованы его ресурсы клиентами и отсюда серьезные требования к управлению IaaS. Полная противоположность в случае private IaaS — все свое с совершенно другим уровнем прогнозирования и контроля за тем что происходит.

          3. Поднятый вопрос о прогнозировании. Собственно публичный провайдер не прогнозирует конкретную нагрузку. У него масштаб другой. Он оценивает статистику и принимает решение об увеличении мощностей или в каких-то случаях об уменьшении (сервера можно выключить).

          Альтернативно для private случая. Нагрузка известна по практическим наблюдением за существующими системами или на основе оценки активности. При принятии решения о необходимых мощностях есть два практических решения. Брать по минимуму если нет проблем с последующим приобретением дополнительных если потребуются. Брать по максимуму если проблемы с дополнительным инвестированием будут (гос. случаи как правило).

          4. Time sharing и публичные провайдеры. Как правило нагрузка имеет пик в рабочее время. Публичный провайдер имеющий клиентуру в различных временных зонах получает супер бонус — пока одни спят другие работают.

          Альтернативно с private случаем по понятным причинам. Только транс национальные компании с персоналом по всему миру получат этот бонус. И чудо, как правило именно крупные компании все outsource'ят подрядчикам.

          Собственно простой вопрос состоит в следующем. Должен ли private IaaS быть похожим на публичный технически?

          Ответ — не зачем инвестироваться, если нельзя получить бонусы, которые получает публичный IaaS провайдер. Проще все скинуть ему и не мучиться.
            0
            Вопрос к автору по картинке.

            На картинке есть слово Multitenancy. Какой смысл заложен в его наличии в этой иллюстрации?
              0
              Ответ в принципе тот же, что и к п.1 Вашего комментария выше. В больших компаниях обычно это поможет более прозрачно оценивать использование подразделениями компании ее департамента ИТ. Мултитенанси будет полезн именно в таком разрезе, когда все общее не считается общим. Когда нужно четко понимать, грубо говоря, какая точно часть бюджета ИТ потребляется определенным филиалом за, допустим, прошедший квартал.
                0
                Maltitenancy является архитектурой программного продукта. А IaaS является инфраструктурой, то есть находится уровнем ниже. Конечно в мультитеннантных программных продуктах делают различные метрики для оценки загрузки систем клиентами. Но это собственно не имеет никакого отношения к IaaS и виртуализации. Multitenant продукты эксплуатируются как правило без IaaS. Собственно для этого архитектура и была создана чтобы не было лишних звеньев.

                Управленческий вопрос возникает такой. Допустим сделали IaaS и оценили загрузку от подразделений. И что после этого. Сказать им вы теперь получите минус 50% ресурсов следующий квартал? Какой собственно процент эффективности от вложений ресурсов?

                Тут бы стоило добавить, что скорее всего, тот же Amazon скорее всего имеет 50% эффективности только от time sharing своих ресурсов по временным зонам клиентов. И допустим еще 50% от статистической недогрузки ресурсов клиентами (хотя в реальности эта цифра скорее больше). Взяв эти цифры мы получим 75% эффективности. Дальше они говорят клиенту — мы готовы дать тебе то что нужно в два раза дешевле и получают прямой доход 25% от общей возможной суммы расходов себе.

                С частным IaaS мы получим следующее. Оценили нагрузку подразделений и допустим оптимизировали их на 15%. Может проще сразу получить экономию 50% купив публичный IaaS и потом оптимизировать свою деятельность допустим еще на 15% получить общую экономию 62.5% в итоге от изначального уровня расходов. Фокус состоит в том, что в подавляющем большинстве случаев в private нельзя получить те бонусы, которые получаются в public. И обратно, в public можно получить почти все бонусы, что и в private. Но частью бонуса эффективности придется поделиться с IaaS провайдером :)

                Все выше сказанное абсолютно не означает, что я лично считаю виртуализацию внутри компаний ненужным занятием. Даже наоборот, я активный сторонник этого. Но, подходить к этому вопросу, так как к нему подходят публичные провайдеры IaaS явно не следует.

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

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