×
Комментарии: Как будут эволюционировать центры обработки данных в ближайшие годы

ЦОДы банков: виртуализация процессов для себя и на продажу

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

 

Задача максимум в Промсвязьбанке — за два года перестроить полностью процесс по факторингу и создать новый кредитный процесс. И в качестве вызова по этим проектам мы договорились, что делаем их как бы на продажу. То есть цель — создать не просто для себя лучшие процессы, а создать бизнес-процессы как сервис и продавать их другим банкам, пусть даже своим конкурентам. Мы одни из лидеров по факторингу, и у нас много возможностей создать конкурентоспособную систему. А затем мы возьмем наших конкурентов, не входящих в топ-5 ближайших преследователей, и просто предлагаем им это как [готовый] бизнес-процесс.

 

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

 

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


Владимир Соловьев, директор по информационным технологиям, Финансовый университет при правительстве России

 

ЦОДы университетов: из унаследованной инфраструктуры в облака

Владимир Соловьев, Финансовый университет при правительстве России: «Финансовый университет при правительстве России — это 90 тысяч студентов, 9 тысяч сотрудников, 37 регионов, 11 больших кампусов в Москве, где примерно 5 тысяч рабочих мест, и достаточно серьезные требования и к инфраструктуре, и к сервисам. В период с 2011 по середину 2013 года произошел существенный рост: мы выросли с 18 до 90 тысяч студентов путем присоединения ряда других больших образовательных учреждений. Было много унаследовано и инфраструктуры. У нас есть сейчас 200 физических серверов, на которых крутится около 1000 виртуальных серверов. Это три территории. По большому счету, этого с точки зрения доступности, непрерывности нам достаточно. А вот что касается стоимости владения, то, конечно, обходится это дело достаточно дорого.

 

Часто представители крупных российских интеграторов к нам приходят как в деревню, оторванную от внешнего мира, как будто у нас нет интернета, и мы не знаем о современных технологиях. С инфраструктурной точки зрения полноценного частного облака у нас пока нет, но к этому мы близки. Выгоды от виртуализации нам уже достаточно давно понятны. Наше «железо» на 70 – 75% загружено. Количество мы, по крайней мере, раза в два сократили, и стоимость падений за счет виртуализации тоже сократилось вдвое. Достаточно серьезные преимущества и перспективы для образовательных учреждений мы видим в развитии VDI (Virtual Desktop Infrastructure — архитектура виртуальных рабочих столов). Сейчас эта технология мало в каких университетах используется, поскольку не так удобно упакована, как хотелось бы. Но на самом деле это и серьезные выгоды от утилизации лицензий, поскольку одно и то же программное обеспечение может использоваться в разных компьютерных классах время от времени, а большую часть простаивать. А если мы это выдаем в виде виртуальных машин, то загружаем гораздо сильнее.

 

Того, что сейчас называется компьютерными классами, в ближайшем будущем не будет, поскольку само понятие компьютерного класса было вызвано редкостью вычислительной техники. 20 компьютеров на крупный университет, понятно, надо делить между общим количеством студентов. А сейчас устройства есть у всех, причем много, и фактически мы должны с этих устройств обеспечить доступ к тем сервисам, которые предоставляем. Движемся к тому, чтобы переносить сервисы из внутренних наших центров обработки данных во внешние. В среднем, простой сервер, который в аренду обойдется порядка 3 тысяч рублей в месяц, для нас в собственности обходится в расчете на месяц порядка 18 – 19 тысяч рублей. Конечно, во внешнем ЦОДе, в облаке, он будет дешевле.

 

Что касается программного обеспечения как сервиса стандартизованного типа электронной почты, облачных CRM-систем и т.д., то крупные вендоры предлагают для вузов эти решения вообще бесплатно. Для университетов что GoogleApps, что Office365 — бесплатны абсолютно, а Dynamics CRM Online обходится на пользователя в профессиональном пакете порядка 500 рублей в месяц, то есть раза в 4 дешевле.

 

Развернуть CRM-решения в облаке мы за месяц смогли совершенно спокойно, и затраты понятны. 20 пользователей умножить на 500 рублей в месяц — это принципиально несравнимо даже со стоимостью лицензии на программное обеспечение, которое мы бы развертывали у себя. Под него нужна инфраструктура и инженеры. Однако перетаскивание всех сервисов в облако и во внешние ЦОДы происходит не так быстро, как могло бы, в силу ряда причин. По NPV (net present value — чистая приведенная стоимость), естественно, аренда получается дешевле, чем постройка, но есть проблемы, связанные с пропускной способностью каналов. Ну, скажем, у нас в Москве 11 территорий, на каждую мы должны подать хороший интернет, должны быть хорошие каналы связи между территориями. У нас сетей в собственности нет, поэтому мы их покупаем, и, несмотря на тенденцию снижения цен, пока это достаточно серьезные статьи расходов. И с увеличением расходов на интернет мы урезаем наши проекты развития трансформации.

 

Что касается непрерывности и безопасности, это тоже достаточно серьезно. Если, например, у нас почта не будет работать 40 минут, в принципе, это не так страшно. Если мы развернули в облаке VDI, на котором есть лабораторные работы, кто-то 1C «крутит» в облаке, кто-то из студентов «мучает» Windows Server. И вот у нас 45 минут недоступен интернет — все, значит университет встал. И если мы говорим про 90 тысяч студентов, то это серьезные потери. SLA (service level agreement, соглашение об уровне услуг) компенсирует, в лучшем случае, стоимость обслуживания во время простоя. Понятно, что такие штрафные санкции смешны. Фактически никак компенсировать возможные убытки мы не можем. Несмотря на это, мы часть сервисов в публичные облака вытащили уже больше двух лет назад, и серьезных инцидентов у нас не было. Были всякие мелкие неприятности: траффик наш какое-то время уходил через Китай, недели две мы с этим боролись, задержки были ощутимы. А таких инцидентов, чтобы сервисы были недоступны, мы за два года не наблюдали.

 

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

 

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

 

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

 


Сергей Белик, независимый эксперт

 

Доживет ли ЦОД до заплыва в жидкость?

Сергей Белик, независимый эксперт: «Обычно любой, кто строит ЦОД, рассчитывает, что он будет жить лет 15. Имеется в виду инженерная инфраструктура. При этом ЦОД, который построен в 2006-07 годах, был рассчитан на 3 – 5 кВт в лучшем случае, а скорее всего еще и меньше. Сейчас у нас 2014 год, и ЦОД, который построен в 2006 году, еще теоретически не устарел, не амортизировался, не отбил своих вложенных средств. То, что к 2020 году 10 – 15 кВт на стойку, будет необходимым минимумом, всем уже очевидно. А еще через несколько лет, скорее всего, сервера будут в жидкости плавать, потому что по-другому отвести тепло будет уже невозможно. А мы сейчас строим ЦОД, и он должен, по идее, работать с теми самыми жидкими [т.е. опущенными в жидкость] серверами. На самом деле любой ЦОД будет модернизироваться и реконструироваться. Будут вноситься специализированные зоны с повышенной теплоотдачей. Всегда возникает вопрос на определенном этапе развития: что проще — построить новый ЦОД или реконструировать? Мы говорим не о том, чтобы уйти совсем в облако, потому что не все готовы уходить в облако по многим причинам.

 

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

 

Теперь о стереотипах. У нас есть [законы] 94-ФЗ, 223-ФЗ, которые призывают к тому, чтобы госзаказчики покупали максимально дешево. Все остальные критерии в результате действия в результате действия этих законов ушли в небытие. Дешево, дешево и дешево…

 

Ни в одном из проектов, с которыми я сталкивался (хотя, может быть, мне просто не повезло), не было дублирования системы управления кондиционерами. И ни один из производителей оборудования не рекомендует дублировать центральные модули управления. Есть еще один интересный момент — вендоры. Они вкладывают огромные средства в то, чтобы разработать новые технологии, быть конкурентоспособными, теснить конкурентов. Для них основной критерий — это продавать новые решения. Всегда ли они хорошие, или же они еще «сыроваты», и их стоит апробировать? ЦОД, к сожалению, не та вещь, где стоит экспериментировать, потому что купив один раз «сыроватое» решение, можно очень здорово обмануться. Например, в свое время были кондиционеры Chiller с технологией Turbo Cooling, которые не работали зимой. При –15 градусах магнитная подвеска начинала давать сбои. И они продавались в России. Вендоры их продавали и рекомендовали. И самое неприятное, что у вендора каждый сотрудник прежде всего мотивирован на то, чтобы продать то, что нужно центральному офису. И он вряд ли порекомендует оптимальное в данной конкретной ситуации решение.

 

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