Строительство центров обработки данных и оказание «облачных» услуг на их основе чаще всего рассматривается как способ расширения бизнеса оператора связи. Однако это направление активно осваивают и системные интеграторы, в том числе для того, чтобы лучше понять проблемы, с которыми сталкиваются компании при реализации «облачных» вычислений. На базе собственного ЦОД КРОК предлагает все основные виды «облачных» сервисов — IaaS, PaaS и SaaS. И, конечно же, компания готова помочь тем заказчикам, которые хотели бы обзавестись своими частными «облаками». При всей привлекательности внешних услуг многие предприятия не готовы отказаться от собственной ИТ-инфраструктуры, к тому же развертывание частных «облаков» позволяет использовать ее максимально эффективным образом. Однако при внедрении «облаков» приходится преодолевать множество препятствий, из которых технические зачастую оказываются не самыми сложными. О различных аспектах «облачных» вычислений рассказывает Руслан Заединов, заместитель генерального директора, руководитель направления центров обработки данных компании КРОК.

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

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

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

В случае частных «облаков» возможны два подхода: организация такого «облака» на базе собственного ЦОД или с привлечением внешних ресурсов. Какой из них является предпочтительным и в каких ситуациях?

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

Если ИТ-инфраструктура развивалась на протяжении длительного времени и у компании накоплено большое количество различных систем, то естественным выбором является создание «облака» на базе этого оборудования. Так, в докризисный период многие предприятия активно инвестировали в создание собственной инфраструктуры, зачастую про запас, и теперь являются владельцами недогруженных серверов и СХД. Этими ресурсами грех не воспользоваться для развертывания на их базе гибкой автоматизированной инфраструктуры, эксплуатация которой была бы по силам неквалифицированному персоналу. Таким образом, выбор подхода зависит от решаемой задачи: это поиск либо возможности финансирования, либо способа оптимизации существующих ресурсов.

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

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

Главная сложность — неготовность подавляющего большинства разработчиков прикладного программного обеспечения к работе с «облаками». С ростом нагрузки корпоративное ПО масштабируется по преимуществу не вширь, а вверх: приходится увеличивать количество процессоров, наращивать объем памяти и т. п. «Облака» же изначально ориентированы на высоко стандартизованные и относительно недорогие серверные платформы, по сути x86, которые по определению не очень хорошо поддаются вертикальному масштабированию. Всем поставщикам ПО еще предстоит адаптировать свое ПО в расчете на горизонтальную масштабируемость. Если это произойдет, то программные продукты будут достаточно легко внедряться поверх «облаков» — сейчас много препятствий именно в этом, хотя и успехи довольно существенны, о чем свидетельствует пример Google, сервисами которого пользуются миллионы людей. Дело в том, что они с самого начала создавались в расчете на горизонтальное масштабирование.

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

Три перечисленных препятствия и создают ощущение сложности. Если их устранить, останутся одни удобства, но на это требуется время.

Если информационные сервисы действительно будут доступны, как электричество из розетки, то какой квалификацией должен будет обладать ответственный за их получение ИТ-специалист?

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

При развертывании «облака» используется множество систем, как аппаратных, так и программных. Возможно ли в принципе частное «облако» из коробки?

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

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

Вопрос очень многослойный. Если говорить об инфраструктуре «облачного» ЦОД, то требования к надежности и даже самому местоположению ЦОД отражены в международных стандартах. Они написаны кровью и потом тех людей, которые многие годы занимались их эксплуатацией, так что все в них написанное должно быть безоговорочно принято и использовано. Я имею в виду прежде всего стандарт TIA-942, а также стандарты Uptime Institute. Кстати, в 2010 году опубликован весьма полезный стандарт BICSI 002-2010 по построению ЦОД. По этому поводу много сказано, но я бы хотел обратить внимание на то, что в данном контексте много внимания уделяется внешним воздействиям на ЦОД, которые маловероятны и не прогнозируемы, например падение самолета.

Между тем есть один достаточно предсказуемый фактор, на который раньше мало обращали внимания в основном из-за экономических соображений, а именно — климатические аномалии. Так, прошлым летом в Москве внешние блоки систем охлаждения в некоторых ЦОД приходилось поливать водой, чтобы они не расплавились. Это свидетельствует о том, что при создании инженерных систем ЦОД не был предусмотрен необходимый запас прочности. До этого была очень холодная зима, а при низкой температуре начинает замерзать хладагент, чему также есть печальные примеры.

В чем причина происходящих сбоев? В том, что закладывать запас прочности на диапазон температур от -40^0C до +40^0C (как оказалось, это необходимо в нашей климатической зоне) слишком дорого. Для работы системы кондиционирования в условиях таких морозов надо использовать неразбавленный этиленгликоль, к тому же спирт испаряется, и раствор придется регулярно подливать. Для работы в изнуряющую жару необходимо разнести градирни, которые сами по себе должны быть большими, то есть потребуются дополнительные площади. Все это только увеличивает стоимость. Чем более узким оказывается расчетный диапазон, тем дешевле система, поэтому из экономических соображений никто не ориентировался на экстремальные температуры. Однако делать это необходимо, чтобы повышать надежность и производительность ЦОД.

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

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

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

Основной объем услуг КРОК приходится на предложение инфраструктуры в виде сервиса. В то же время, по данным IDC, на российском рынке «облачных» вычислений 94% занимают услуги AaaS/SaaS. Чем объясняется такая разница?

Я много разговаривал с аналитиками IDC во время подготовки ими этого отчета. С учетом принятых в докладе формулировок сильных расхождений с моими замечаниями я не вижу. Дело в существенной разнице терминологии, к тому же IDC рассматривает рынок в целом, а не только его корпоративный сегмент. Как только словосочетание «облачные вычисления» приобрело популярность, очень многие участники рынка хостинга приложений и тому подобных сервисов стали называть себя «облачными» провайдерами. Это хороший маркетинговый ход. И на Web-хостинг, аутсорсинг «1С:Бухгалтерии», хостинг Exchange и другие подобные сервисы действительно приходится значительная часть рынка, но это не «облачные» вычисления в полном смысле слова.

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

Таким образом, от «облака» заказчик хочет получить гибкую инфраструктуру, как в виртуализованном ЦОД.

Все российские коммерческие ЦОД могут разместиться в одном американском, причем не самом крупном. В Китае планируется строительство воистину гигантского ЦОД площадью свыше 600 тыс. м^2. Каковы перспективы строительства мега-ЦОД в России? И нет ли опасности отставания, как на автомобильном рынке?

Такая опасность, безусловно, есть, но есть и надежда. Возможны два варианта. Первый — идти проложенным путем, копировать технологии, пытаясь догнать западные рынки. Но стоит ли это делать? Зачем строятся ЦОД вообще и мега-ЦОД в частности? Для поддержки приложений, причем в основной массе это старые, немасштабируемые, неэффективные — иначе говоря, не «облачные» — приложения. Эти ЦОД заставлены старым железом, и с такими технологиями работают миллионы людей, у которых нет привычки и навыков работы в «облаке». Какова ситуация у нас в стране? Центров обработки данных, соответствующих американским масштабам, у нас просто нет, а значит, наши ЦОД не заставлены всяким старьем, у нас нет огромного шлейфа программного обеспечения и тысяч клерков, обученных работать только с этими решениями, и поэтому нам не надо амортизировать огромный груз капитальных вложений. Получается, что проходить весь этот путь не обязательно — мы можем сразу все делать правильно и эффективно, «по-облачному». И, возможно, не потребуется строить множество ЦОД. Так, например, в США план реформирования управления ИТ на федеральном уровне предусматривает переход на «облачные» технологии для всех уровней государственного управления, что, в частности, предполагает сокращение числа федеральных ЦОД на 800 единиц к 2015 году. Отставание не настолько опасно, как выбор неправильного пути.