Нормативная документация

Элементы облачной мифологии: о роли инфраструктуры

10 июля 2014 г. | Категория: ИТ инфраструктура ЦОД

В последнее время компьютерные облака являются одной из наиболее часто обсуждаемых в ИТ-мире тем. Спектр связанной с облаками проблематики весьма широк, хотя часто обсуждение сводится к уже ставшим стандартными вопросам:

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

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

Рисунок 1. Пример изображения облачной архитектуры. Источник: http://www.ibm.com/developerworks/cloud/library/cl-open-architecture/

В соответствии с определением, данным National Institute of Standards and Technology (NIST)

облачные вычисления (cloud computing) - это модель для обеспечения повсеместного, удобного, предоставляемого по требованию доступа посредством сети к общему пулу конфигурируемых вычислительных ресурсов (например, сетей, серверов, хранения, приложений и услуг), которые могут быть быстро предоставлены и освобождены, с минимальными управленческими усилиями и минимальным взаимодействием с поставщиком услуг[1].

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

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

– гибкость управления ресурсами;
– универсальность доступа;
– масштабируемость.

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

Гибкость управления ресурсами – это возможность эффективно перераспределять имеющиеся ресурсы, определять их предназначение и приоритеты их использования. Как правило, это означает некоторую «универсальность» ресурсов, поскольку в противном случае управление гибким быть, скорее всего, не сможет.

Универсальность доступа – это возможность выполнения операций при произвольном местонахождении пользователя, с применением (почти) произвольного устройства, удовлетворяющего лишь наиболее общим требованиям. Еще одним следствием является неявное предположение централизации управления хранением данных, как ключевого актива. Действительно, без обеспечения доступа к данным целесообразность сервисов в целом попадает под вопрос, а без некоего централизованного управления данными гарантировать доступ невозможно.

Масштабируемость  – это реальная возможность без сколько-нибудь серьезных усилий наращивать ресурсы либо сокращать. Безусловно, это весьма важный, хотя и наиболее спорный элемент всей концепции. Почему – об этом ниже.

Виртуальная реальность vs. реальная виртуальность?

А теперь давайте посмотрим, что же на самом деле означают упомянутые нами (и пока – казалось бы - виртуальные) возможности во вполне реальном мире.

Но для начала предлагаю обратить внимание на один особо не подлежащий обсуждению постулат, который многие под влиянием современных облачных маркетинговых активностей упустили из виду: сколько бы разного рода виртуальных решений не было сформировано, какова бы ни была сложна совокупная виртуальная архитектура, какие бы виртуальные машины не применялись для реализации этой архитектуры, в конце концов исполнение любой программы осуществляется на каком-нибудь абсолютно реальном компьютере. АБСОЛЮТНО РЕАЛЬНОМ! И, таким образом, несмотря на всю красоту и, зачастую – «заумность» предлагаемых облачных сервисов, все они, в конце концов, так или иначе связаны с реальными, реализованными в железе, компьютерами, и исполняются на этих компьютерах. 

Что же реально означают наиболее интересные возможности облачных вычислений с точки зрения «железа»? Давайте разбираться по порядку.

Гибкость управления ресурсами

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

Универсальность доступа

Для обеспечения доступа в первую очередь необходимы каналы связи. С этим параметром на первый взгляд всё проще: например, достаточно сделать приложения (если мы говорим об услугах такого рода) доступными через интернет. При этом, конечно, не следует забывать, что часто приходится иметь дело с не очень качественными интернет-каналами, и это обязательно накладывает ограничения на качество и доступность сервиса. К сожалению, имеются существенно более значимые проблемы, чем уже упомянутая. В первую очередь это обеспечение информационной безопасности, наиболее полное обеспечение которой без применения специальных, реализованных в железе, технологий весьма затруднительно. Кроме этого не следует забывать об ограничениях на объем поступающих запросов и количество одновременно работающих пользователей. Также в ряде случаев существенным ограничением может стать канал от поставщика услуг в интернет.

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

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

Масштабируемость

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

И из этого обозначенного нами положения вытекает ключевое следствие, способное навсегда (или, по крайней мере – надолго) сделать облачную мечту всего лишь мечтой: если говорить о совокупных затратах всех участников модели - экономии на оборудовании не возникает и не может возникнуть! А это значит, что фактически облачные услуги в совокупности обходятся никак не дешевле традиционных, «безоблачных». Конечно, можно придумать ситуацию, когда некий эффект экономии возникает за счет того, что, например, вычислительные мощности становятся доступны потребителям не одновременно, а поочередно – тогда какой-то эффект возможен за счет снижения объема простоя. Но, к сожалению, и физические, и юридические потребители никак не хотят строиться в очередь, и норовят запрашивать ресурсы почти одновременно, будь то доступ к новостным сайтам (утром либо при какой-то сенсации), или доступ к финансовым приложениям (баланс все сводят в конце месяца).

Кстати, элементарные расчеты на основе предлагаемых облачными поставщиками тарифов показывают, что стоимость услуг только на первый взгляд оказывается невысокой. Например, по чуть ли не самой простой и популярной услуге «Google Диск» 1 терабайт хранения обойдется в $120 за год, что явно дороже, чем 1 терабайтный жесткий диск.  Таким образом, срок окупаемости (если не учитывать прочие составляющие услуги) не превышает 1 год. Понятно, что традиционный бизнес редко когда может себе позволить такие сроки окупаемости оборудования, тем более, что только гарантийный срок эксплуатации диска составляет 3 года.

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

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

Именно с этим связано то, что для прошедшей 19-13 мая 2014 года в Лас-Вегасе ежегодной технологической конференции компании IBM Edge 2014 в качестве основного слогана организаторы выбрали фразу «Infrastructure Matters[2]». Поводом стали предварительные результаты проведенного силами IBM глобального исследования 750-ти организаций. В рамках исследования обсуждались следующие темы:

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

В результате оказалось, что более 70% организаций считают, ИТ-инфраструктура существенно влияет на доход и прибыль, а также является ключевым фактором для конкурентного преимущества, но при этом менее чем в 10% случаев ИТ-инфраструктура полностью готова и соответствует потребностям признаваемых приоритетными облачных решений, Big Data и прочим.

Поскольку инфраструктура не может появиться просто так «ниоткуда», ее формированию, обновлению и развитию следует уделять соответствующее внимание.

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

Несколько слов об инженерной инфраструктуре

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

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

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

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

Вместо заключения

Мы не являемся противниками или апологетами облачной модели. Мир сложен и существуют разные условия и конкретные ситуации, когда применение облачной модели окажется полезно или наоборот обманет ожидания. На наш взгляд важно понимать эту модель. И, продвигая облачные решения, учитывать разные аспекты, обращая внимание не только на рекламируемые, но и на реально имеющие существенное влияние факторы. Далеко не последним (если не вообще – наиболее важным)  из которых является инфраструктура.

В общем, желательно просто помнить, что в реальном мире инфраструктура имеет значение.

Заурбек Алехин, независимый консультант

Теги: инфраструктура, Заурбек Алехин