Infinidat Blog

НАРАЩИВАЕМ ЕМКОСТЬ В… ЧАСТНОМ ОБЛАКЕ?

 

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

Никто не хочет платить за инфраструктуру авансом, особенно в сегодняшних условиях финансовой неопределенности, но нехватка ресурсов для поддержки резко подскочившего спроса не обрадует ваше начальство. Опять-таки из-за финансовой неопределенности сейчас сложно что-то предсказывать. Компании, которые грамотно строят свою инфраструктуру, предусматривая возможность быстрого наращивания емкости при необходимости, смогут свести авансовые платежи к минимуму и оптимизировать траты во время сезонной пиковой нагрузки. Если всё так просто, то почему лишь немногим компаниям это удаётся?

Пара слов перед погружением в контекст

Понять главную причину проблемы значит уже наполовину решить её.

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

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

Давайте по пунктам разберем проблемы, связанные с миграцией в публичное облако:

Операционные проблемы

При резком переносе нагрузок в облако администраторы должны поддерживать прежний уровень обслуживания (SLA), соблюдать правовые нормы, требования к управлению и т.д. Добавление облачной инфраструктуры создает новые трудности:

  • Как перенести данные в облако, не прерывая работу сервиса?
  • Как вернуть данные из облака после пиковой нагрузки?

Большинство поставщиков облачных услуг делают упор на инструменты, помогающие мигрировать рабочие нагрузки в облако, но не обратно.

  • Как поддерживать согласованность резервных копий, когда они поступают из нескольких источников?
  • Что будет, если ваша резервная копия данных прошлой недели хранится локально, а сейчас вам нужно восстановить ее в публичном облаке?
  • Сколько стоит миграция данных обратно в локальную инфраструктуру? 

Большие наборы данных соразмерно увеличивают совокупную стоимость владения для всего проекта.

  • Какие инструменты нужны для управления? Они реализованы в публичном облаке?
  • Какие инструменты безопасности необходимы, если мы увеличиваем поверхность атаки?
  • Как протестировать заведомо более сложные решения по аварийному восстановлению?

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

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

Финансовые проблемы

Во время каждого своего выступления на любом мероприятии (давным-давно, когда люди ещё собирались для живого общения) я задавал директорам ИТ-департаментов одни и те же три вопроса:

  1. Вы мигрируете новые приложения в облако?

Все поднимали руки.

  1. Вы это делаете, чтобы сэкономить?

Никто не поднимал руки. Все смотрели на меня так, будто я спятил.

  1. Вы это делаете, чтобы обеспечить гибкость бизнеса?

Все снова поднимали руки, убедившись, что я не псих.

В отличие от малого и среднего бизнеса крупные компании экономят за счет масштаба в частных облаках, поэтому для них переход в публичное облако не столь экономически эффективен: они платят так называемый облачный налог (не буду вдаваться в подробности о величине этого налога; достаточно того, что все, с кем я общался на эту тему, называли двузначные числа).

Итак, крупному бизнесу приходится решать следующее уравнение:

  • Публичное облако = больше гибкости, больше расходов.
  • Частное облако = меньше гибкости, но экономическая эффективность налицо.

Учитывая, что крупному бизнесу нужны сразу и экономическая эффективность, и гибкость, у него есть три пути:

  1. Повысить экономическую эффективность публичного облака.

Это вряд ли, если только вы не найдете цветущий папоротник.

  1. Перейти на сервисы гибридного облака, пользуясь гибкостью публичного облака только при необходимости и тем самым сводя к минимуму дополнительные расходы.

Этот путь обычно чреват упомянутыми выше операционными проблемами.

  1. Изыскать в вашем частном облаке возможность для быстрого наращивания емкости.

Для этого нам нужно вернуться к истокам: главной причине, с которой всё началось.

Находим в вашем частном облаке возможности для быстрого наращивания емкости

Вернемся к истокам нашей проблемы: При модели потребления на базе частного облака вы должны рассчитывать ресурсы заранее, т.е. риск ложится на вас. Однако если публичное облако может взять на себя такой риск при обслуживании многих заказчиков, то ваши поставщики частного облака должны предлагать вам аналогичные возможности. 

С виртуализацией и контейнеризацией масштабироваться очень просто, сеть масштабируется нечасто, т.е., скорее всего, вас будет ограничивать не это, а в большей степени – уровень хранения данных. Решив проблему резкого увеличения объема хранилища, вы одновременно решите финансовую проблему "облачного налога" и устраните все технические проблемы, связанные с резким наращиванием емкости за счет ресурсов публичного облака.

Некоторые поставщики СХД предлагают такие частные облачные хранилища с возможностью быстрого масштабирования, но со следующими оговорками:

  • Это дорогое решение, с которым к вашему частному облаку добавится облачный налог.
  • Применимо только к небольшой части вашего хранилища. 
  • Заказчик будет вынужден потреблять ресурсы по моделям операционных затрат, которые хотят и могут использовать далеко не все заказчики.
  • Если ваши потребности будут расти, потребуется поставка новых емкостей, что повысит операционные расходы и создаст риск задержек.

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

Действительно масштабируемое хранилище

Модель эластичного ценообразования Infinidat снимает приведенные ограничения, о которых так часто говорят поставщики, и позволяет клиентам пятикратно наращивать емкость даже без доставки новых компонентов. Кроме того, заказчики могут использовать модель как капитальных, так и операционных затрат, или обе модели сразу по своему усмотрению, даже в пределах одной системы. Стоимость хранения снижается, и заказчики могут платить только за то, что они реально используют, не боясь ошибиться при планировании ресурсов. И самое главное, такая модель не вынуждает искать компромисс между производительностью, надежностью или доступностью.

Информация Eran Brown
Eran Brown is the EMEA CTO at INFINIDAT.
Over the last 14 years, Eran has architected data center solutions for all layers — application, virtualization, networking and most of all, storage. His prior roles include Senior Product Management, systems engineering and consulting roles, working with companies in multiple verticals (financials, oil & gas, telecom, software, and web) and helping them plan, design and deploy scalable infrastructure to support their business applications.