Руслан Заединов: «Для нас наиболее важным стало появление ряда крупных проектов, в процессе реализации которых компания выступает в роли облачного интегратора»

Компания «Крок» — постоянный участник форумов «Мир ЦОД». Руслан Заединов, заместитель генерального директора компании, руководитель направления ЦОД и облачных вычислений, рассказал еженедельнику Computerworld Россия о состоянии этого сегмента российского рынка ИТ и работе «Крока» в данной области.

- Каковы наиболее характерные изменения, произошедшие на российском рынке ЦОД после форума «Мир ЦОД 2012»?

Если говорить о коммерческих центрах обработки данных, то здесь можно отметить одну очень важную вещь для провайдеров услуг ЦОД – за это время практически не появилось новых крупных центров, которые могли бы значительно повлиять на сложившуюся рыночную ситуацию. Насколько мне известно, в эксплуатацию введен всего один крупный ЦОД. Он довольно быстро построен в Москве компанией IXcelerate. Но один новый игрок погоды не делает: площадки, принадлежащие «Кроку», «Ай-Теко», Data Space Partners, DataLine и ряду других компаний, еще не заполнены, и предложение на рынке, по существу, осталось тем же.

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

- Что это за проекты, в чем их специфика?

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

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

- Все это относится к коммерческим ЦОД. А что происходит в области строительства предприятиями собственных центров обработки данных?

Этот сегмент, который всегда формировался отдельными проектами, тоже постепенно развивается. Предприятия, хотя и очень сдержано, продолжают вкладывать деньги в собственные ЦОД. Для одного банка мы построили центр обработки данных мощностью в 2 МВт, что является весьма заметным событием для финансового сектора. В настоящее время идет проектирование 15-мегаваттного ЦОД для компании в сфере энергетики.

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

- Каким образом смещается спрос от коллокации к инфраструктурным, платформенным и другим облачным сервисам?

За последний год доходы компании «Крок» от коллокации возросли вдвое, а от облачных сервисов всех видов – в пять раз. Тем не менее, несмотря на рост абсолютных показателей, соотношение между коллокацией и другими сервисами меняется незначительно: на коллокацию приходится около 80% поступлений, примерно 10% приносит аренда виртуальных ресурсов, а оставшиеся 10% — аренда выделенных физических систем. Следует отметить, однако, что виртуальных серверов у нас около тысячи, а специализированных под задачи заказчиков выделенных систем – не более сотни. Эта весьма доходная проектная часть будет расти, поскольку в ней заинтересованы крупные организации. Доходы от собственных ЦОД в обороте компании, хотя и растут значительно быстрее других направлений нашего бизнеса, пока не превышают нескольких процентов.

- Насколько популярны среди ваших заказчиков частные и публичные облака?

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

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

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

- Подтвердилась ли целесообразность сертификации ЦОД «Компрессор» в соответствии с требованиями Uptime Institute?

Безусловно. Прежде всего, мы это обещали и выполнили свои обязательства. Наконец-то появились заказчики, которые указывают сертификацию площадки центра обработки данных в качестве обязательных тендерных требований. Для них важен аудит ЦОД, осуществляемый профессионалами в данной области, как, скажем, важен внешний аудит бухгалтерской отчетности. Среднестатистическое время простоя центров обработки данных Tier II, III и IV составляет сутки, полтора часа и несколько минут в год соответственно. Возможно, нужны более «плавные» оценки, но сегодня стандарты такие, какие они есть, и никто не хочет опускаться ниже «тройки». Наряду с этим сертификация открывает доступ к консультациям специалистов Uptime Institute на всех этапах создания ЦОД – от проектирования до выбора и монтажа оборудования, что существенно упрощает решение многих вопросов. Что же касается цены, то я бы сказал, что сертификация ничего не стоит по сравнению с инвестициями в строительство ЦОД (по данным Uptime Institute, сертификация проекта и готового объекта обходится, в зависимости от энергопотребления, от 100 тыс. до 350 тыс. долл. — А. Ч.).

- После ввода в действие «Компрессора» возникали какие-либо серьезные эксплуатационные проблемы?

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

- Насколько полезным вы считаете участие в форумах «Мир ЦОД»?

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

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

Выставка на «Мире ЦОД» традиционно служит местом самых оживленных неформальных дискуссий

Тематика форума и его пленарных докладов отражает заметные изменения в области отечественных ЦОД, свидетельствующие о растущей зрелости этого рынка. «Если еще пару лет назад у нас были в диковинку объекты мощностью в несколько мегаватт, то теперь в Москве и других городах строятся гораздо более крупные ЦОД, а наша столица может войти в пятерку крупнейших европейских хабов ЦОД», — подчеркнул Александр Барсков, ведущий редактор «Журнала сетевых решений/LAN» и руководитель программного комитета форума.

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

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

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

Вид сертификации зависит и от специфики требований заказчиков ЦОД. По мнению Юрия Самойлова, генерального директора Dataline, наряду с сертификацией инфраструктуры по критериям Uptime Institute не менее важной является сертификация информационной безопасности в соответствии с требованиями стандартов ISO/IEC 27001 и Payment Card Industry Data Security Standard. Такого же мнения придерживаются и в компании Linxdatacenter.

Алексей Солодовников, управляющий директор Uptime Institute Russia, сообщил, что авторитетная организация не только специализируется в сфере сертификации ЦОД, но и проводит регулярные исследования, направленные на изучение ситуации и основных тенденций рынка ЦОД. Последний отчет, 2013 Data Center Survey, составлен по результатам опроса более тысячи респондентов, свыше половины которых – из Северной Америки, а четверть — из Европы, включая 12 российских организаций.

По данным отчета, 55% респондентов увеличили бюджеты ЦОД по сравнению с 2011 годом, почти половина – внедрили или внедряют частные облака, около четверти работают с публичными облаками. Освоение облачных технологий продиктовано в основном желанием снизить расходы на ИТ. Характерно, что в большей части опрошенных организаций инсталлировали или намерены использовать системы Data Center Infrastructure Management. Новейшее решение в этой области — SmartZone Solutions, объединяющее интеллектуальные устройства, шлюзы, ПО и сервисы, представил на пленарной сессии Александр Брюзгин, региональный менеджер Panduit.

По данным Uptime Institute, среднее значение коэффициента энергоэффективности (Power Usage Effectiveness, PUE) в обследованных ЦОД составляет от 1,8 до 1,89. Развертывание модульных ЦОД удвоилось, но по-прежнему их число не велико. Окончательные результаты исследования, включая сведения по использованию облачных технологий, будут опубликованы в июне. «Надеюсь, что в следующий раз отечественных компаний будет намного больше», — заметил Солодовников.

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

Повышению эффективности способствует также внедрение новейших технологий, в состав которых входит программное конфигурирование сетевых ресурсов. Руслан Смелянский, член-корреспондент РАН, утверждает, что использование программно-конфигурируемых сетей (Software Defined Network, SDN) снижает стоимость развертывания и операционных расходов ЦОД, повышает уровень утилизации ресурсов, удобство администрирования, позволяет автоматизировать отладку, упрощает выявление ошибок в работе ЦОД (см. также «Ethernet может все», Computerworld Россия, № 27, 2012).

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

Пленарные обсуждения охватывали весьма широкий спектр вопросов. Среди них – инструменты Citrix для построения облаков и облачный опыт Linxdatacenter, архитектура Cisco UCS, предложения DSCon в области 40 Gigabit Ethernet, модульные концепции Schneider Electric, технологии повышения комплексной надежности и эффективности ИБП Emerson, энергоэффективность водяного охлаждения РСК, 21-мегаваттный ЦОД RadiusGroup. Кроме того, прошли панельные дискуссии по SDN и сертификации ЦОД.

«Чтобы отследить нюансы стремительного развития рынка ЦОД, стоит сделать паузу в работе и обсудить все назревшие вопросы с широким кругом коллег. Такую возможность предоставляет наш форум ‘Мир ЦОД’», — резюмировал Павел Христов, вице-президент издательства «Открытые системы».

Александр Старыгин: «Направления развития ИТ сегодня диктуют пользователи, которые хотят получать инновации по низкой цене»

Вступая в конце 2011 года в должность генерального директора HP, Мег Уитман заявила: «Мы намерены акцентироваться на том, что делаем лучше других». Что это означает применительно к центрам обработки данных, в ходе форума «Мир ЦОД 2013» пояснил Александр Старыгин, директор департамента подготовки технических решений HP в России.

— Что в сфере ЦОД компания HP делает лучше других?

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

Деятельность, связанная с ЦОД, в HP происходит по двум направлениям. Первое – проектирование ЦОД, планирование строительства зданий, внедрение технологий и консалтинг. Второе – наполнение ЦОД с целью создания инфраструктуры под задачи заказчиков. Мы рассказываем клиентам, на что обратить внимание, зачем нужны гибкие модульные структуры, как происходит миграция ресурсов, почему требуется перераспределение ресурсов. Кстати, три из четырех площадок в России, сертифицированных Uptime Institute по Tier III, построены именно по проектам HP.

— Чем прежние вычислительные центры на базе мэйнфреймов или мини-ЭВМ отличаются от современных ЦОД?

Действительно, внешне это те же шкафы, системы охлаждения и машинные залы. Однако единственная задача специалиста ВЦ, на решение которой уходило 100% его времени, состояла в поддержании оборудования в рабочем состоянии. Сегодня у персонала ЦОД две функции — поддержка, которая никуда не исчезла, но теперь она занимает 80-90% рабочего времени, причем эту функцию при желании можно отдать на аутсорсинг; и планирование использования новых технологий, на что уходит 10-15% времени, хотя в идеале этот показатель должен составлять 40-50%.

— Что влияет на требования, которые заказчики предъвляют к ЦОД?

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

Кроме всего этого, требования к ЦОД формируют объективные факторы; например, часть приложений, на поддержку которых ранее особо не обращали внимание, вдруг становятся критичными для бизнеса. Взять хотя бы электронную почту, отсутствие которой уже воспринимается как отсутствие электричества, но если это критичное приложение, то для его поддержки нужна уже совсем иная инфраструктура, адекватная решаемым задачам. Может происходить и обратное: в некоторых технологиях отпадает необходимость, что упрощает инфраструктуру; например, маркировка расположения серверов или специализированная подсистема контроля энергопотребления становятся не нужны – современный сервер сам знает, в какой стойке он размещается, сам меняет уровень энергопотребления в зависимости от загрузки, условий эксплуатации, других факторов.

— Как облака повлияли на судьбу ЦОД?

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

Здесь следует сказать об отношении HP к набирающей популярность концепции программно-конфигурируемых сетей, ведь SDN — это прежде всего стандарты, а многое уже сделанное по этой идеологии, например сеть Google, представляет собой уникальную разработку для нужд и задач одной компании. У HP другой подход – создание коммерческих продуктов, построенных на стандартах. К примеру, уже полтора года все коммутаторы поддерживают протокол OpenFlow. Путь стандартизации долгий, но игра стоит свеч – речь идет о весьма значительном сокращении для конечного пользователя затрат на сетевое оборудование, увеличении гибкости сети, сокращении времени реконфигурирования. Компании, сделавшие себе имя и капитал на других подходах (проприетарные коммутаторы, жестко определяющие сеть), будут вынуждены сменить бизнес-модель. Вряд ли потребители и дальше согласятся покупать дорогие коммутаторы для построения сетей, соответствующих новым требованиям к пропускной способности, вместо того чтобы устанавливать дешевые специализированные коммутаторы, отлично выполняющие лишь одну функцию – адресовать пакеты, передавая серверу или программе интеллектуальные функции гибкого управления сетью.

— Какие современные тенденции в серверных технологиях влияют на развитие ЦОД?

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

— Какие подходы используют сегодня системные архитекторы, проектирующие инфраструктуру корпоративных ЦОД?

Если говорить об ИТ-оборудовании, размещаемом в ЦОД, то прежде всего необходимо отказаться от подхода «один сервер – одно приложение – одна система хранения». Это путь в тупик, если по нему двигаться, то основные усилия будут направлены на постоянное перераспределение ресурсов и обуздание их неконтролируемого роста.

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

Значительная часть деловой программы форума «Мир ЦОД 2013» прошла в формате технических потоков, охвативших самые разные аспекты проектирования и эксплуатации ЦОД.

Технические потоки охватили самые разные аспекты проектирования и эксплуатации ЦОД

Серверы и системы хранения

Открывший заседание технического потока «Серверы и СХД» Грег Кволек, старший директор по развитию облачных технологий HGST, вкратце обрисовал основные тенденции в области проектирования систем хранения ЦОД. Он подчеркнул, что за последние два года создано 50% всей цифровой информации, накопленной человечеством. Темпы увеличения объемов данных неуклонно растут. И если бы накопленные данные со временем просто стирали, так нет! Большинство предприятий, как видно из проведенных опросов, готовы хранить файлы и библиотеки 20-летней давности.

«Из этого вытекает главное требование к проектированию систем хранения ЦОД – гипермасштабируемость», — заявил Кволек.

Вторая важная тенденция – развитие флэш-памяти и рост количества устройств, оснащенных ею. Твердотельные накопители (Solid State Drive, SSD) становятся незаменимым средством при создании систем анализа данных, поскольку обеспечивают доступ к ним без задержек, практически в режиме онлайн. Обеспечить такую скорость доступа к данным, например, из ленточных библиотек невозможно.

Третья тенденция – это дальнейшее развитие жестких дисков, которые пока рано списывать со счетов. В будущем появятся новые технологии, увеличивающие плотность записи на таких устройствах. К числу перспективных можно отнести и термомагнитную запись HAMR, она обещает радикально увеличить емкость жестких дисков (Hard Disk Drive, HDD).

«Я много слышу, что HDD приходит конец, но это не так, — уверен Кволек. — В плане производительности они, конечно, развиваются не столь быстро, как SSD, но зато быстрее дешевеют. Поэтому в настоящее время нет никакого практического смысла в том, чтобы строить хранилище данных с опорой на твердотельные накопители. Последние лучше использовать для повышения производительности серверов. В любом случае HDD и SSD имеют в запасе как минимум десять лет для дальнейшего наращивания производительности за счет новых технологических подходов».

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

Константин Баканович, технический директор компании DSCon, обратил внимание аудитории на проблематику обеспечения совместного доступа к данным в ЦОД. Традиционно для этого используются IP и Ethernet, но оба эти протокола имеют определенные недостатки, на их основе не всегда возможно увеличить производительность коммуникационной системы до нужных параметров и гарантировать требуемый уровень задержки пакетов трафика. Баканович рекомендовал организовывать совместный доступ к данным ЦОД посредством строительства сети хранения на основе высокопроизводительных протоколов, например Fibre Channel. При этом сетевое хранилище должно быть укомплектовано инструментами управления доступом к данным. Подобное решение, в частности, предлагает на рынке компания Quantum. Оно называется StorNext. Поскольку несколько серверов одномоментно обращаются к одной файловой системе, им требуется регулятор, чтобы избежать записи данных двумя системами в одно и то же место на диске, пояснил Баканович. В StorNext эта функция выполняется при помощи контроллера метаданных (MetaData Controller, MDC). Устройства MDC так же подключаются к системам хранения через высокопроизводительные соединения. StorNext является предпочтительным решением для наиболее требовательных к производительности приложений, таких как обработка потокового видео, высокопроизводительные научные вычисления, анализ Больших Данных.

Александр Зейников, региональный менеджер по развитию бизнеса LSI, в своем выступлении обратился к проблеме ускорения доступа к данным. Он предложил использовать методику выделения из общей массы так называемых горячих данных и переноса их на самые быстрые носители. Как образно выразился Зейников, данные, используемые чаще других, нужно «положить поближе к процессору». Это прежде всего относится к данным корпоративных приложений. Представитель LSI, в частности, рекомендовал использовать в ЦОД ускоритель работы приложений Nytro MegaRAID, основанный на встроенной флэш-памяти и оригинальной технологии LSI RAID on Chip (ROC). Интеллектуальные алгоритмы кэширования Nytro MegaRAID позволяют определять наиболее часто запрашиваемые данные, которые передаются во встроенную флэш-память, что делает процесс доступа к ним более быстрым. Применение таких ускорителей может рассматриваться как выгодная альтернатива массивам на базе только твердотельных накопителей или избыточным дисковым массивам прямого подключения.

Инженерная инфраструктура

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

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

Вместе с тем перед проектировщиками большинства ЦОД всегда встает дилемма: что важнее – достижение заданных критериев Uptime Institute или PUE (Power Usage Effectiveness), то есть гарантированный доступ к данным, или энергоэффективность. Ведь чем выше степень резервирования ресурсов в ЦОД, тем больше энергии им требуется и тем хуже показатель PUE. Достижение баланса в этом вопросе и есть искусство проектирования ЦОД. В «Кроке», как утверждает Ласый, нашли оптимальное соотношение надежности и энергоэффективности в своих дата-центрах прежде всего благодаря точному прогнозу потребностей заказчиков. Как заявил Ласый, «главный враг PUE – недогруженность ресурсов», когда системы ЦОД работают вхолостую. Поэтому энергоэффективность ЦОД в большей степени зависит от искусства продаж предлагаемых сервисов, нежели от технологий энергосбережения. Впрочем, заметил он, PUE сильно зависит и от системы охлаждения, которая сама является одним из главных потребителей электроэнергии в ЦОД. Даже PUE для нее рассчитывается отдельно.

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

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

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

Кабельная инфраструктура

В рамках отдельного потока обсуждалась «Кабельная инфраструктура ЦОД». Владимир Стыцько, директор по продажам компании TE Connectivity — Enterprise Networks в России, заострил внимание на одной из самых злободневных тем, пояснив, какая СКС удовлетворяет требованиям дата-центра, предоставляющего облачные сервисы. По словам Стыцько, первым делом СКС в облачном ЦОД должна поддерживать все существующие и перспективные приложения, которые потребуют от кабельной инфраструктуры большей производительности. В этой связи планируемый переход от соединений 10 Gigabit Ethernet к скоростям 40 и 100 Гбит/с должен быть бесшовным и максимально простым, чего можно добиться, например используя 12- и 24-оптоволоконные соединители. Во-вторых, СКС должна обеспечивать оптимальное оснащение соединениями высокоплотных сегментов ЦОД. И главное, от СКС требуется наличие системы автоматизированного управления. Автоматизация управления СКС обеспечивает высокую отказоустойчивость всей коммуникационной среды в ЦОД, повышает ее надежность благодаря наличию достоверной информации о том, что с чем соединено и какие проблемы следует немедленно нейтрализовать. Также упрощается общее администрирование СКС, что приводит к снижению эксплуатационных расходов, а это очень важно для коммерческих ЦОД. С помощью специальных программ сейчас можно управлять всеми сетевыми устройствами дата-центра, к которым относятся и коммутационные панели, утверждает Стыцько. В современных СКС они представляют собой ИТ-устройства со всем набором функций и возможностей для управления.

Константин Баканович: «Нужно ясно понимать, каких результатов мы хотим добиться, работая с Большими Данными»

Многие компании в России, например, крупные банки, телекоммуникационные операторы, накопили огромные массивы данных и понимают, что их детальный анализ мог бы принести ощутимую пользу для бизнеса. Но осознав потенциал Больших Данных, компании не торопятся начинать проекты, связанные с их обработкой, считая подобные инициативы рискованными с точки зрения возврата инвестиций и достижения результативности. О том, как облегчить предприятиям вхождение в мир Больших Данных, на форуме «Мир ЦОД 2013» еженедельнику Computerworld Россия рассказал Константин Баканович, технический директор компании DSCon.

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

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

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

Действительно, есть примеры реализации похожих проектов, есть примеры задач, которые при этом решаются, есть определенные ожидания, связанные с тем, какие именно объемы данных планируется хранить и перерабатывать. Но все равно каждый проект имеет индивидуальные характеристики, целевые показатели и критерии успешности. DSCon часто получает запросы на создание высокомасштабируемых хранилищ данных, но как правило эти запросы звучат так: «Мы хотим приобрести дисковый массив, расширяемый до петабайта, однако наша текущая потребность в ресурсах хранения составляет 20 терабайт». То есть, очень немногие предприятия нуждаются в создании действительно очень больших информационных хранилищ. При этом к нам приходит большое количество запросов на системы архивирования, а иногда нас просят создать системы резервного копирования незначительной емкости. Но запросов на создание систем оперативного хранения Больших Данных немного. Потому что в настоящее время посредством оптимизации головного программного обеспечения, бизнес-процессов или методов обработки данных можно добиться значительного сокращения требований к объему оперативного хранения. То есть, данных генерируется масса, но полезных данных и данных, требующих оперативного доступа к ним, в компаниях немного.

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

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

- Какие сетевые интерфейсы систем хранения имеют оптимальное соотношение цена/производительность применительно к задачам обработки Больших Данных?

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

- Но, например, при использовании продуктов, базирующихся на IP и Ethernet, возникают определенные сложности с обеспечением гарантированного качества сервисов и с задержкой пакетов. Подходят ли они для задач сетевого обеспечения при обработке Больших Данных?

По мере развития технологии Ethernet эти недостатки нивелируются. Скажем, в сетях на основе стандарта 10-Gigabit Ethernet вопросы задержки и управления качеством сервисов в основном решены. Хотя, конечно, не до конца. А системы на 40-Gigabit Ethernet практически лишены указанных недостатков. И эта спецификация может быть рекомендована к применению в критичных приложениях, таких как Большие Данные. Иными словами, 40-Gigabit Ethernet вполне может конкурировать в системах хранения и в ЦОД с высокопроизводительными протоколами Fibre Channel и InfiniBand. Но я не готов сказать, какие именно решения имеют оптимальное соотношение цена/производительность применительно к задачам обработки Больших Данных. Здесь нужно учитывать экономические параметры проекта, понимать, какие задачи в нем ставятся. И прогнозы в отношении разных технологий я бы делать не стал. Например, компания QLogic недавно сообщила о скором появлении 128-гигабитных систем Fibre Channel. То есть, QLogic по сути «проскакивают» очередную эволюционную ступень и выходят на очень высокие скорости сетевых соединений. Наверное, Fibre Channel вернет, утрачиваемые на настоящий момент, позиции в мире ЦОД. Ethernet же хорош тем, что это традиционный и всем отлично известный протокол. С ним привыкли работать ИТ-администраторы, и это большой плюс, поскольку в реализации систем хранения проблема с обслуживающим персоналом — одна из самых острых.

- Способствуют ли решению задачи обработки Больших Данных виртуализация и облачные вычисления? Каким образом?

Несомненно. Виртуализация и облака — это новая степень гибкости системы. Благодаря им разработчики системы хранения данных освобождаются от необходимости централизации инфраструктуры, от необходимости обязательно концентрировать функции хранения данных в каком-то одном месте. У разработчиков появляется возможность территориальной или логической балансировки нагрузки. Причем и на уровне транспорта, и на уровне хранения. Значительно увеличивается степень свободы при проектировании, а это позволяет абстрагироваться от системы хранения как таковой при постановке и реализации задачи обработки Больших Данных на прикладном уровне. Виртуализация и облака позволяют хранить данные там, где это наиболее практично для достижения выбранных целей — скорейшего доступа или максимальной сохранности, например. Следствием чего является лучшая управляемость всей системы хранения данных и лучшие экономические показатели.

- Совсем недавно, 13 мая, DSCon заключила дистрибьюторское соглашение с компанией Solarflare. В чем смысл этого соглашения для вашей компании? Что получат заказчики?

Заказчики получат сетевые адаптеры 10-Gigabit Ethernet, которые обладают рядом интересных особенностей. Прежде всего для нас интересен их функционал по синхронизации. Адаптеры Solarflare умеют очень точно поддерживать одинаковое время на каждом из узлов, формирующих коммуникационную среду предприятия или ЦОД. Это очень важно для реализации финансовых приложений, проведения научных вычислений и других сложных задач. Я думаю, Solarflare сейчас лучше всех обеспечивает синхронизацию. На основе этих адаптеров мы сформируем предложения для очень интересных и перспективных сегментов рынка.

Олег Коверзнев: «Виртуализация представляет собой некую субстанцию, которая объединила прежде разнородные системы ЦОД»

Компания Cisco предлагает унифицированный подход к построению сетевой и компьютерной инфраструктур дата-центров. О преимуществах и возможных ограничениях этого подхода в кулуарах форума «Мир ЦОД 2013» еженедельнику Computerworld Россия рассказал Олег Коверзнев, менеджер по развитию бизнеса ЦОД Cisco в России.

- Как должна поменяться внутренняя коммуникационная инфраструктура в ЦОД, использующем виртуализацию и облака?

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

- Где изменения, обусловленные виртуализацией и облаками, проявятся наиболее зримо — на уровне ядра сети ЦОД, в каналообразующих системах или где-то еще?

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

С понятием облака и облачным развитием ЦОД с недавнего времени неразрывно связана концепция программно-конфигурируемых сетей (Software Defined Networking, SDN). Ее использование в ЦОД обусловлено стремлением поменять архитектуру сети, избавив ее от ограничений традиционной сетевой парадигмы. Но к этому нужно относиться аккуратно, потому что интерес к SDN отчасти подогревается успешными проектами таких компаний, как eBay, Google, Facebook. Им необходимо на уровне всей сети распределять огромные потоки данных, поддерживать мобильность приложений внутри ЦОД и их перенос между дата-центрами. Наша трактовка сетевых решений опирается на традиционный подход к построению сетей, но учитывает и изменения, которые привносит SDN. Сетевой портфель Cisco включает виртуальные коммутаторы Cisco и технологии, обеспечивающие отказоустойчивую работу виртуализованных ЦОД. Например, когда виртуальные машины «переезжают» из одного ЦОД в другой, нужно использовать технологии, которые будут обеспечивать миграцию виртуальных машин без прерывания обслуживания. Сеть ЦОД должна поддерживать технологии миграции, обеспечивать мобильность виртуальных машин. Это сказывается и на системе управления. Она должна быть автоматизированной, так как все, что касается виртуальных машин, облаков, не поддается «ручному» регулированию. В ближайшие годы мы, скорее всего, увидим серьезные изменения в подходах к управлению сетью, с учетом «взросления» технологий, входящих в понятие SDN.

- Стратегия Cisco в области ЦОД предполагает унифицированный подход. В чем его преимущества?

Понятие унифицированного подхода, к сожалению, опирается на перевод-клише слова unified. Прямо скажем, полностью унифицировать что-либо в ЦОД тяжело. ЦОД представляет собой гетерогенную среду с множеством разных технологий. Но есть вектор унификации. Например, на уровне сети он проявляет себя в том, что при подключении серверов на уровне доступа к сети все чаще используется технология FCoE. Что касается подхода Cisco, то FCoE — единственная возможность подключить лезвийный сервер нашей марки к сети ЦОД. Это действительно унифицированная технология доступа к сети, позволяющая уменьшить количество кабелей, упростить СКС, облегчить администрирование в ЦОД. Наш подход полностью проявляется в решениях Cisco Unified Computing System. Когда вы тесно интегрируете сеть с вычислениями, нужна система управления, позволяющая контролировать не какой-то конкретный сервер, а фактически вычислительный ресурс, тем самым достигается унификация вычислений внутри ЦОД. Идеология унификации по Cisco сводится к решению такой задачи: меньше устройств, кабелей и других технических элементов везде, где только этого можно добиться. Также нужно понимать, что унификация ЦОД – долговременный процесс для любой компании. Это максимальная абстракция ресурса от нижележащих технологий. И в наших решениях заложены механизмы, позволяющие добиться такой абстракции.

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

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

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

Это действительно колоссальная по сложности задача. Но она возникла не сегодня и не вчера. ИТ-департаменты решают ее многие годы. Виртуализация, если можно так выразиться, и усложняет, и упрощает управление ЦОД, точнее, поднимает вопрос управления на принципиально иной уровень. Фактически виртуализация объединила прежде разнородные системы. Ранее за систему хранения в ЦОД отвечала одна команда, за сети — другая, за серверы – третья. Их взаимосвязь была минимальна. Виртуализация заставила разные обслуживающие ЦОД подразделения активнее общаться между собой. В некоторых организациях уже происходит объединение служб, в которых специалисты имели бы опыт работы с сетевым оборудованием, вычислительными системами и системами хранения. Многие компании ищут людей с более широкой экспертизой. Вместе с тем единое управление и единое обслуживание представляет собой тоже некую идеальную модель. Думаю, в ЦОД никогда не будет единой системы управления. Инженерная система будет контролироваться из одного кабинета, а управления виртуализацией – происходить из другого. Отдельно будет осуществляться управление высокоуровневыми решениями, ответственными за развертывание приложений и операционных систем. То есть фрагментированный подход к управлению существует и будет существовать впредь. Не нужно пытаться объять необъятное и решить задачу одним махом. Следует постепенно централизовывать управление, сначала хотя бы на уровне инфраструктуры, чтобы в момент развертывания виртуальной машины автоматически происходила подготовка к выдаче ресурсов, соответствующая настройка на стороне всех технологических доменов, и приложение уже действовало бы в единой виртуальной среде с общим SLA. Вообще понятие унификации очень тесно связано с понятием целостности. Это очень важно, чтобы инструмент управления и технологические решения, используемые на уровне сети, вычислительной инфраструктуры и системы хранения, обеспечивали бы требуемый уровень качества обслуживания виртуальной машины. Не думаю, что в ЦОД с разнотипным оборудованием стоит решать задачу объединения всех систем под единое решение для управления. Полагаю, правильнее выделить сегменты ЦОД, растущие быстрее всего, те сегменты, где решаются наиболее критичные задачи и где компания получит наиболее ощутимую отдачу от централизации управления.

- Как должна поменяться вычислительная и коммуникационная инфраструктура в ЦОД в связи с появлением Больших Данных? Что самое сложное в адаптации ЦОД к проблематике Больших Данных?

Из самого термина Big Data можно сделать вывод, что будут передаваться и храниться большие объемы данных. Поэтому сетевое оборудование должно быть подготовлено к увеличению объемов трафика. Также обработка Больших Данных связана с созданием вычислительных доменов, объединенных общей логической архитектурой с предсказуемой производительностью, в том числе на уровнях сети, вычислений и хранения. Зачастую сегмент Больших Данных представляет собой некий аппендикс в ЦОД. Этот сегмент может быть построен по несколько иным принципам, нежели основная часть инфраструктуры. В этом сегменте будут более производительные каналы, системы обработки и хранения данных. Но я бы не сказал, что это принципиально меняет архитектуру ЦОД. Просто компаниям, стремящимся получить преимущества от Больших Данных, нужно быть готовыми создать сегмент, интегрированный в общую архитектуру ЦОД, но в то же время обладающий усиленными решениями для передачи данных, их анализа и хранения. Я бы не расценивал Большие Данные как революционный фактор, способный перевернуть архитектуру ЦОД. У Cisco есть решения для анализа данных (например, для SAP HANA) и для решения других задач (Hadoop и пр.), связанных с проблематикой Больших Данных, но, по сути, это те же решения, которые мы предлагаем для обычных задач в ЦОД. У них только немного иная конфигурация, расширенная память, увеличенная пропускная способность, гарантированная задержка и т. п. Мы адресуем одни и те же решения Cisco UCS сегменту Больших Данных и обычным ЦОД, ппоскольку основные преимущества – высокая интегрированность решений, снижение CAPEX и OPEX, минимизация информационных и операционных рисков, простота масштабирования, высокая надежность – одинаково важны как для традиционных корпоративных приложений, так и для сегмента Больших Данных.

Свой вариант охлаждения с прямым контактом демонстрировала на «Мире ЦОД 2013» компания РСК

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

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

Принятие решения о выборе системы охлаждения сводится к ответу на два основных вопроса: как с меньшими затратами получить холод, желательно при этом использовать возможности внешней среды, и как лучше подвести холод к горячим компонентам. Несколько ответов на эти вопросы можно было получить во время форума «Мир ЦОД 2013», проведенного издательством «Открытые системы», на секциях «Инженерная инфраструктура ЦОД» и «Серверы и СХД». В докладе «Использование фрикулинга в ЦОД» Юрий Хомутский («Ай-Теко») говорил не столько о технологиях, сколько о климатических факторах, открывающих возможности сэкономить на энергозатратах. Он продемонстрировал созданный им калькулятор «Расчет фрикулинга» (http://aboutdc.ru/freecool/), основанный на собранном им обширном материале о метеоусловиях. На данный момент калькулятор пригоден только в Москве, но вскоре он сможет работать во всех городах-миллионниках России.

Вакарис Стакаускас, директор центра инфраструктурных услуг литовской компании Hostex BDC, представил проект, реализованный на технологиях голландской компании Kyoto Cooling, созданных в 2007 году. Он, естественно, сосредоточил внимание на особенностях реализации, хотя технология Kyoto, построенная на базе вращающихся регенераторов, поражает простотой и высокой энергоэффективностью. Она пока еще малоизвестна и сама по себе представляет большой интерес. В ее основе вращающиеся роторы-теплообменники, до 2011 года эта технология доводилась до уровня промышленного изделия. Ротор Kyoto Cooling еще называют «колесом высоких температур». Колесо разделяет два контура, по которым циркулирует воздух, первый осуществляет его забор из окружающей среды, второй – из помещения дата-центра, а ротор-регенератор выполняет функции теплообменника между наружным воздухом окружающей среды и воздухом в помещении ЦОД. Пока российские заказчики проявляют сдержанный интерес к чудо-колесам диаметром в несколько метров, хотя, по некоторым данным, такая установка работает в дата-центре «Яндекса» уже несколько лет.

Представители компании «АМДтехнологии», использующей продукцию Liebert и Rittal и «Спецсервиса», партнера AquaCoolling, сосредоточили свое внимание на совершенствовании доставки холодного воздуха до отдельной стойки, используя более или менее оригинальные технологии, но суть, в общем, та же — не «распылять» холодный воздух по машинным залам, а направлять его поближе к источникам тепла. Для этого холодная вода направляется в теплообменники, расположенные либо над стойками, либо между стойками, либо в дверях. Наиболее оригинальны решения AquaCoolling, в них вода подается не под давлением, что угрожает потопом в случае разрыва трубопроводов, а наооборот, откачивается, что-то вроде пылесоса для воды. Если герметичность нарушается, то начинается подсос воздуха и только, никакой опасности в этом нет. Близкие, по сути, решения предлагают IBM, Coolcentric и Cray.

Наиболее радикальным является отказ от охлаждения воздухом вообще. Существует три возможных варианта — иммерсионный с погружением в жидкость (submerged cooling), аэрозольное охлаждение (spray cooling) и охлаждение с прямым контактом (direct cooling или embedded cooling). В первом случае жидкость, обычно минеральное масло, окружающая платы, отбирает от них тепло, она прокачивается через теплообменники с помощью небольших насосов. Во втором — специальная жидкость распыляется по поверхности плат; испаряясь, она охлаждает их, затем конденсируется и цикл повторяется. В третьем — к поверхности плат прикладываются алюминиевые пластины с расположенными в них каналами, по которым циркулирует жидкость. Все три имеют отличающиеся, но близкие по идее версии. На «Мире ЦОД 2013» последний вариант этого направления представляла компания РСК.

Часто именно охлаждение жидкостью на уровне плат называют жидкостным и позиционируют как новинку. Это неверно, не следует думать, что этот тип охлаждения является чем-то принципиально новым, все три впервые были изобретены и реализованы в начале 80-х годов и использовались в различных мэйнфреймах, которые в те годы производились не только корпорацией IBM. Сегодня, помимо РСК и Eurotech, охлаждением с прямым контактом занимаются датская компания Asetek, американская Clustered Sytems, канадская Coolit Systems и IBM. Иммерсионная технология на форуме не была представлена, однако она достаточно известна; среди производителей соответствующих решений не только американские компании, такие как 3M, Green Revolution Cooling и Liquid Cool Solution и британская Iceopte, но и две российские — «Сторус» и «Экофлопс». Что же касается аэрозольного охлаждения, то в гражданских приложениях оно имеет ограниченное применение, зато широко используется в различного рода летательных аппаратах, особенно в беспилотных дронах.

Андрей Касьяненко: «В решении проблем информационной безопасности мы работаем по инцидентам»

В рамках форума «Мир ЦОД 2013», который был организован издательством «Открытые системы» 28-29 мая, состоялся круглый стол по проблемам предоставления российскими операторами ЦОД и облаков услуг по обеспечению безопасности. Хотя он назывался «ЦОД как точка пересечения интересов CIO и CSO», то есть руководителя информационной службы и главы службы безопасности, с самого начала выяснилось, что никакого пересечения интересов практически нет, поскольку в коммерческом ЦОД часто вообще отсутствует выделенная служба информационной безопасности.

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

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

Ситуацию в коммерческих ЦОД нужно воспринимать так: отдел безопасности является структурным подразделением заказчика, поэтому готовит требования по информационной безопасности для ИТ-службы оператора ЦОД и в дальнейшем следит за соблюдением поставленных требований. Важно при заказе услуг по аренде инфраструктуры и приложений в договоре о качестве обслуживания предусмотреть и требования по защите, а также возможность контроля действий оператора со стороны клиента. В частности, Роман Чаплыгин, руководитель отдела информационной безопасности банка Delta Credit, задался вопросом, как включать в соглашения об уровне обслуживания требования по защите. Эту проблему пока каждому заказчику приходится решать самостоятельно, хотя стоит помнить, что информационная безопасность — это в том числе и целостность системы, и доступность информации. И без правильного функционирования систем защиты очень сложно достигнуть показателя в 99,999% доступности.

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

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