Как построить облако?

• LAN: Как подготовить ЦОД к переходу к частному облаку, какие программные и аппаратные платформы вы считаете оптимальными для этой цели? В каких случаях публичные облачные сервисы выгоднее действительно развертывания частного облака на площадке заказчика, а в каких лучше создавать собственные облака?

Подготовка перехода ЦОД к частному облаку – это не просто смена парадигмы предоставления ресурсов или услуг, это решение, которое изменит стратегию развития ИТ в любой компании. Прежде всего, стоит отметить, что строительство частного облака может быть целесообразно только в том случае, если есть четкое понимание того, зачем именно это облако нужно, и какие возможности строительство облачной инфраструктуры даст бизнесу. Что же касается непосредственно подготовки, то основные требования давно известны. Это должна быть консолидированная и стандартизированная инфраструктура. Что касается выбора программной платформы, то на сегодняшний момент на рынке наблюдается большое количество решений, позволяющих создавать разные облачные среды под разные нужды заказчика. Однако, на сегодняшний день у наших заказчиков, наиболее востребованными являются продукты для реализации модели IaaS и PaaS.

В качестве примера можно привести семейство продуктов IBM SmartCloud, которое не просто позволяет строить облачные среды, одновременно включающие разные аппаратные платформы CISC и RISC, но и разные средства виртуализации, такие как Microsoft Hyper-v, VMware, KVM и PowerVM. Кроме того, семейство продуктов IBM SmartCloud интегрировано с платформой Open Stack, что позволяет строить не просто гибкие решения, но, в первую очередь, решения, построенные на базе открытых стандартов. В качестве аппаратной платформы для большого количества заказчиков выгоднее использовать интегрированные, или как их еще называют «конвергентные» решения, такие как IBM PureSystems. Это обусловлено не только простотой развертывания таких решений, но и значительным снижением затрат при эксплуатации облачного ЦОД.

• LAN: От чего зависит выбор оптимальной программной и аппаратной платформы?

Выбор аппаратной платформы должен основываться на понимании и наличии стратегии развития компании, строящей облачный ЦОД. Без стратегии развития строительство облака практически невозможно. Отсутствие понимания того, в каком направлении будет двигаться компания, скорее всего, приведет к тому, что вместо облачного ЦОД будет иметь место «лоскутная» виртуализация и автоматизация.

При выборе аппаратной платформы одним из первостепенных факторов является «время жизни» платформы – срок, в течение которого производитель готов ее развивать и поддерживать. В противном случае может оказаться так, что уже через пару лет после начала развития ЦОД его основа морально и физически устареет, а заказчику придется добавлять в ЦОД компоненты, интеграция которых в имеющуюся инфраструктуру и средства управления будет затруднена или невозможна. В качестве примера стратегической платформы можно привести IBM PureSystems, стратегия развития которой на ближайшие годы понятна, и которая включает в себя все самые современные технические решения.

С программной платформой все не так просто, как это может показаться на первый взгляд. От количества ПО для создания облаков, предлагаемого на рынке, просто рябит в глазах, и может сложиться обманчивое впечатление, что, выбрав любое из этих предложений, заказчик получит некое «облако из коробки», затраты на развертывание и эксплуатацию которого будут минимальны, а выгода очевидна.

Для правильного выбора программной платформы заказчик должен, понять, а каких, собственно, результатов он хочет достичь, развертывая облако в своем ЦОД, насколько важно снижение затрат на администрирование и сопровождение инфраструктуры, которые по некоторым данным превышают 60% от всего бюджета ИТ-подразделений, насколько важна гибкость и эластичность при наращивании  ресурсов внутри облака, и в каком направлении будет развиваться ЦОД. Наконец, ограничится ли все моделью Iaas, или в дальнейшем планируется переход к PaaS, SaaS или гибридным моделям? Только, ответив на эти вопросы, можно построить действительно эффективный облачный ЦОД. В противном случае, попытка перехода к облачной модели может стать неудачной, либо потребовать большего количества ресурсов на введение в эксплуатацию и дальнейшее сопровождение.

• LAN: Какие преимущества и недостатки характерны для комплексных интегрированных (конвергентных) платформ - готовых к развертыванию решений, объединяющих серверы, системы хранения и сетевые компоненты?

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

1) Дизайн системы на следующие, по меньшей мере, 7-10 лет. Как уже отмечалось, строить облачный ЦОД на платформе, которая через пару лет будет снята с производства, по крайней мере неразумно.

2) Гибкая масштабируемость и эластичность инфраструктуры. Желание производителей продавать больше «железа» понятно, однако может противоречить потребностям заказчика. Настоящая интегрированная система предоставляет право выбора, а не ограничивает заказчика в построении облачной инфраструктуры.

3) Безопасность. Вопросы безопасности в облачной среде стоят гораздо острее, нежели в традиционной инфраструктуре. Какие ресурсы используются? Кем и как они управляются? Где физически находятся используемые ресурсы? Что происходит при добавлении новых ресурсов в облако, и сколько времени потребуется для их интеграции в систему безопасности. Настоящая интегрированная система позволяет построить единую систему безопасности для всех используемых в облачной инфраструктуре виртуальных и физических ресурсов (таких как вычислительные узлы, сетевое оборудование, системы хранения данных, виртуальные машины и библиотеки образов системного и прикладного ПО). Кроме того, должна быть предусмотрена возможность разделения прав доступа для пользователей управляющих и сопровождающих облачную инфраструктуру.

4) Надежность и доступность. Что произойдёт в облачном ЦОД, если выйдет из строя система хранения данных? Что будет, если для обновления микрокода оборудования придётся остановить все приложения? Как отреагирует облако, если с тем или иным оборудованием начнутся проблемы или появятся признаки скорого выхода этого оборудования из строя? Сколько будет стоить час простоя облачного ЦОД? От ответа на эти вопросы зависит и выбор интегрированной системы. В качестве примера интегрированных систем с высокой надёжностью и доступностью можно привести IBM PureSystems. Так, например, с использованием IBM PureSystems можно построить облачный ЦОД, в котором будет отсутствовать  единая точка отказа (SPOF – Single Point Of Failure и SPOR – Single Point Of Replacement), а при намечающихся проблемах с тем или иным оборудованием, например серверным, возможно автоматическое перемещение приложения на другой сервер или другую площадку

5) Открытые стандарты. Строительство не то что облачного, но и простого ЦОД с использованием проприетарных технологий и протоколов чревато не только большими проблемами при дальнейшем масштабировании инфраструктуры, но и финансовой зависимостью от производителя оборудования. Избежать подобных проблем помогут интегрированные системы, построенные исключительно на открытых стандартах и легко интегрируемые в существующую инфраструктуру заказчика.

6) Производительность. Как ни странно, но вопросы производительности различных компонентов облачного ЦОД напрямую влияют на те финансовые затраты, которые понесёт заказчик при строительстве и дальнейшей эксплуатации ЦОД. Настоящая интегрированная система должна позволять создавать плотные вычислительные среды, получать на небольшой площади большую вычислительную мощность, одновременно использовать различные архитектуры (такие как CISC и RISC), что дает возможность сэкономить на лицензиях на ПО десятки, а то и сотни тысяч долларов, а также предусматривать возможность использования различных сетевых технологий и топологий, что является ключевым фактором влияющем на производительность при решении ряда задач.

7) Совместимость. Настоящая интегрированная система может быть легко интегрирована в существующую инфраструктуру заказчика, и не должна зависеть от того какое сетевое оборудование или системы хранения данных используются в ЦОД на текущий момент.

8) Низкая стоимость обслуживания и простота администрирования. Главной идеей, лежащей в основе интегрированных систем, является снижение затрат на сопровождение систем, через возможность управления всеми компонентами инфраструктуры из единой консоли и возможность автоматизации большинства рутинных операций. Так, например, при использовании обычных систем на выполнение простейших операций, таких как развертывание виртуальных машин, операционных систем, баз данных может потребоваться до нескольких дней. Интегрированная система должна позволить выполнить все эти действия за считанные минуты. В качестве примера можно привести системы IBM PureSystems, единая консоль управления которых позволяет автоматизировать выполнение большинства рутинных действий (начиная от обновления микрокода, установки гипервизоров и операционных систем на серверы, и заканчивая возможностью автоматической установки промежуточного и прикладного ПО и интеграцией с облачными средами).

Резюмируя, можно сказать, что правильно выбранная интегрированная система позволяет построить облачный ЦОД с минимальными затратами, легко интегрироваться в существующую инфраструктуру, а также значительно снизить затраты на дальнейшее сопровождение и обслуживание.

• LAN: Должны ли такие платформы быть универсальными или специализированными, ориентированными на выполнение конкретных приложений и нагрузок (баз данных, бизнес-аналитики, Web-приложений и др.)?

Несомненно, все зависит от задачи, и от тех преимуществ, которые могут дать заказчику те или иные системы. С одной стороны, создание системы под базу данных «с нуля» может дать такие преимущества как гибкость конфигурации и возможность построения некоей универсальной системы, которая может быть использована, как и под сервер баз данных, так, например, и для Web приложений. С дугой стороны, использование таких специализированных систем, как IBM PureData или PureApplication, позволяет, во-первых, значительно сэкономить на лицензиях на ПО, а, во вторых, существенно уменьшить время запуска системы в эксплуатацию и снизить риски, возникающие при строительстве своими силами.

• LAN: Некоторые вендоры предлагают для развертывания облаков так называемые эталонные или референсные архитектуры. В чем преимущества и недостатки такого подхода, насколько он перспективен?

По сути, референсная архитектура является своеобразной «дорожной картой», использование которой позволяет быстро получить результат, но подчас, этот результат достигается в ущерб гибкости и потенциальным возможностям. Использование референсной архитектуры оправдано, например, в тех случаях, когда необходимо быстро развернуть решение, или когда не хватает экспертизы на разработку решения, ориентированного на потребности конкретного заказчика. Именно поэтому, компания IBM приглашает к сотрудничеству все те компании, которые задумываются о строительстве облачного ЦОД. Мы поможем подобрать решение, максимально отвечающее требованиям бизнеса и ориентированное на рост и долговременное использование.

• LAN: Как вы считаете, в какой степени получат распространение "программно-определяемые" или "программно-конфигурируемые" платформы, уже ставшие общим подходом на уровне сетевой инфраструктуры и теперь захватывающие уровень систем хранения данных? Станет ли программно-определяемый ЦОД (SDDC) типовым решением? Насколько облачная платформа уже сейчас должна быть "программно-конфигурируемой"?

Концепция программно-определяемого ЦОД определяет  некую идеальную модель, к которой, рано или поздно, придет большинство заказчиков. Идея создания полностью виртуальной инфраструктуры, содержащей серверное оборудование, системы хранения данных и сети управляемые из единой консоли, идеально соответствует тому, что уже имеется в основе систем IBM PureSystems. Для того, что бы SSDC можно было реализовать, необходимо, чтобы все его компоненты соответствовали тем требованиям, которые предъявляются, например, к интегрированным системам. SSDC невозможно построить, если хотя бы малая его часть будет использовать проприетарные технологии и протоколы, а производительность или выбор ПО будет ограничен только определенной платформой или гипервизором.

• LAN: Какова роль так называемых Ethernet-фабрик в облачной платформе и в облачном ЦОД?

Роль Ethernet-фабрики заключается в виртуализации сети передачи информации внутри облачного ЦОД, равномерном распределении нагрузки, минимизации затрат на управление сетевым оборудованием и повышение доступности виртуальных машин и приложений. Конечно же, вышеперечисленным роль Ethernet-фабрик не ограничивается и количество задач, которое можно решить, используя Ethernet-фабрики, очень велико. Так, например, реализация программно-определяемого ЦОД невозможна без построения гибкой сетевой инфраструктуры и дальнейшему переходу к модели SDN (Software Defined Network).

• LAN: Иногда говорят, что основная сложность заключается не в выборе облачной платформы, а в выборе системы автоматизации. Так ли это и почему?

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

• LAN: С какими основными проблемами приходится сталкиваться заказчикам на этом пути в облако?

На текущий момент у большого количества заказчиков можно наблюдать так называемую «лоскутную» автоматизацию и виртуализацию. Большое количество разных аппаратных платформ, систем хранения данных, несметное количество средств управления и проблемную систему безопасности, которая, зачастую не охватывает все компоненты ЦОД. А нехватка квалифицированных специалистов значительно снижает эффективность ЦОД в целом и значительно увеличивает затраты на обслуживание. Для того, чтобы справиться со всеми этими и многими другими проблемами существует ряд решений, к которым можно отнести и интегрированные (конвергентные системы), такие как IBM PureSystems.