В последнее время тема внедрения облачных технологий перешла от разговоров к реальным проектам. И одной из компаний, где приступили к созданию частного облака, стала страховая компания «Ростра». Данный проект позволит предоставлять бизнес-пользователям ИТ‑сервисы, соответствующие динамике развития компании. Пока завершен первый этап, который можно считать только пилотным. Например, выделены весьма скромные ресурсы для хранения данных. Но результаты, пусть и довольно скромные, все же получены, в том числе относящиеся к управлению данными. Все это и стало предметом нашего разговора с ИТ-директором СК «Ростра» Дмитрием Савельевым.
Intelligent Enterprise: До начала работ у вас имелся опыт использования облачных сервисов? Насколько он был успешным?
Дмитрий Савельев: Внутри нашей инфраструктуры опыта использования и построения облачных сервисов до сих пор не было. Однако на прежнем месте работы, в банковской сфере, я работал с внешними сервисами, такими как SWIFT, который уже давно стал облачным. Этот пример далеко не единственный. Все без исключения, кто постоянно пользуется ИТ, применяют облачные сервисы, часто даже не подозревая об их природе. Я не могу назвать свой опыт однозначно положительным или отрицательным. Ведь требования постоянно меняются по мере осознания потребностей. Хотя никаких серьезных проблем тоже не могу припомнить.
Какие ресурсы (серверы, СХД) были выделены для создания облака? Они закупались дополнительно, или использовалось то, что уже имелось? Кто и как выбирал программную платформу?
В компании «Ростра» используется централизованная модель построения ИТ-инфраструктуры. Все территориальные отделения используют вычислительные ресурсы, физически находящиеся в головном офисе. Естественно, что требования к инфраструктуре у нас очень серьезные. Основу ее составляют серверы компании HP, включая блейд-платформы.
Задолго до того, как мы задумались о применении облачных технологий, мы начали активно внедрять системы виртуализации от Microsoft Hyper-V. Когда коллеги из компании «Астерос Консалтинг» предложили повысить эффективность использования инфраструктуры и увеличить скорость предоставления новых сервисов с помощью облачного решения на базе Hyper-V Cloud, то для этой цели было использовано оборудование, не задействованное в промышленных системах. Оно применялось для технологических нужд, и бизнес-пользователи на этих серверах не работали.
В пилотной фазе проекта мы ограничились собственными накопителями серверов. В компании есть несколько систем хранения данных, задействованных на обслуживании продуктивных систем, но использовать их в нашем проекте мы не стали.
Дополнительных закупок софта также не делалось. У нас есть достаточный объем лицензий на ПО, включая системы мониторинга System Center Operations Manager. И мы использовали то, что уже было.
Что касается выбора Hyper-V Cloud в качестве платформы, то он был вполне осознанно сделан на основе анализа существующих продуктов, проведенного с помощью наших внешних консультантов. Кроме того, результаты тестирования других решений, в частности от VMware, не показали существенных преимуществ. Я допускаю, что они есть, но в наших условиях мы их не смогли ощутить. При этом стоимость лицензирования альтернативного ПО была существенно выше. Таким образом, по соотношению цены, производительности и качества Hyper-V Cloud выиграл, и мы выбрали именно его. Хотя накопленный нами опыт работы с этим решением тоже сыграл немалую роль.
Как шли работы по проекту? Какие были сложности, и если были — то прежде всего технические или организационные?
Проект шел в несколько этапов: разработка архитектуры и подготовка площадки, развертывание и настройка систем, консультации и обучение сотрудников. Все шло согласно разработанному с консультантами плану работ. Проект длился около шести недель. Естественно, это касается активной фазы, не включая переговоров, разработки и согласования планов, а также ряда других подготовительных работ.
Второй этап проекта — непосредственно внедрение — длился около трех недель. За это время было развернуто около десяти различных систем. Мы перенесли в «облако» несколько серверов, научились проводить балансировку нагрузки на хосты Hyper-V и разобрали вместе с консультантами из «Астерос Консалтинг» сценарии решения возможных проблем.
Технические сложности бывают всегда. Но в рамках этого проекта они скорее служили базой для отработки инцидентов в рамках специально организованных для этой цели семинаров. Например, у нас не получалось интегрировать Virtual Machine Manager и System Center Operations Manager. С помощью наших партнеров по проекту мы решили эту и другие проблемы. В итоге мы получили подробное руководство для дальнейших самостоятельных действий по развитию наших облачных систем.
Организационные проблемы в проекте тоже возникали и имели куда большее значение. Прежде всего они были связаны с выделением людских ресурсов. ИТ-персонал всегда занят текущей работой и дополнительные нагрузки часто воспринимает без большого энтузиазма. Надо отдать должное коллегам из «Астерос Консалтинг» и Microsoft, которые нам очень помогли, взяв на себя большую часть функционала по проекту. Благополучно решить все остальные организационные сложности позволил четкий план — кто и что должен делать, какие ресурсы необходимы на том или ином этапе.
Потребовались ли какие‑то усилия, чтобы минимизировать объемы данных, передаваемых по сети между филиалами?
В рамках этого проекта нам не пришлось прибегать к мерам по сокращению объема передаваемых данных. Наши филиалы используют терминальные технологии доступа к вычислительным ресурсам. При этом все данные обрабатываются внутри головного офиса. Так построена наша инфраструктура, и облачный проект ее никак не изменил в этом плане — в территориальные подразделения основной объем данных просто не передается.
Кроме того, мы уже довольно давно и регулярно проводим оптимизацию данных. Системы, обеспечивающие поддержку бизнес-процессов в страховых компаниях, оперируют гигантскими объемами информации. Это и оцифрованные образы документов, и фотографии объектов страхования, например автомобилей или домов. Без постоянной оптимизации и удаления неактуальных данных просто не обойтись. Этот процесс был отлажен и автоматизирован в свое время с помощью внешних консультантов. Теперь мы справляемся своими силами. В компании разработаны соответствующие регламенты и политики для соответствующего ПО. Например, регламентированы правила по оцифровке документов, хранению и пересылке сканов, фотографий и прочих документов. Все инструкции доведены до сведения бизнес-пользователей, и они их соблюдают и стараются не нарушать. За этим следят средства мониторинга. В компании применяются и другие современные технологии, в частности дедупликация данных. Но пока они задействованы не для всего объема информационных ресурсов.
Одним из основных слабых мест облачных технологий называют зависимость от каналов связи. Как решается эта проблема у вас?
Да, эта проблема существует, и решать ее довольно сложно. Нельзя исключить повторения летних событий, когда две страны остались без Интернета в результате повреждения магистрального канала. Такое нередко происходит при земляных работах, так что подобное бедствие даже называют «эффектом пьяного экскаваторщика». Подобные эксцессы, к сожалению, происходят регулярно.
Однако везде есть стандарты по обеспечению отказоустойчивости. В компании «Ростра» они работают для всех территориальных филиалов и касаются как серверного оборудования, так и подключения к сетям. Помимо основного ЦОД, у нас существует территориально удаленный от него резервный дата-центр. Центральный офис организации работает с несколькими поставщиками услуг связи, и при сбое на одном из них происходит автоматическое переключение на другой, причем на всех филиалах. Если произойдет сбой в одном из территориальных подразделений, это никак не скажется на работе всей компании.
Часто приходится слышать, что облачные технологии построены на нестандартных протоколах обмена данными, что приводит к разного рода сложностям. Насколько эти опасения обоснованны?
Для нас это не составляет большой проблемы, потому что мы используем централизованную архитектуру. Филиалы подключаются с использованием стандартного IP-протокола. И переход к облачной модели эту ситуацию никак не меняет. В итоге, несмотря на все опасения, перенос наших бизнес-приложений в облако не потребовал какой‑либо существенной «донастройки». В рамках пилотного проекта мы убедились, что больших проблем с дальнейшей миграцией в облако не возникнет именно за счет преимуществ, которые дает централизованная архитектура.
Правда, такая модель увеличивает риски, связанные с утечкой информации. Особенно при сосредоточении больших объемов данных в руках технического персонала, имеющего к ней полный доступ. Снизить риски помогает сочетание технических и организационных мер, в частности по ограничению доступа к тем или иным ресурсам.
Предполагается ли использование каких‑либо внешних сервисов в дальнейшем?
Пока никаких конкретных планов у нас нет, но мы оставляем для себя такую возможность. Нельзя исключать того, что внешние услуги окажутся для нас выгоднее. Тут можно провести прямую аналогию с электричеством: мы ведь не задумываемся, от какой электростанции получаем энергию. С вычислительными ресурсами, получаемыми по облачной модели, ситуация может развиваться по такому же сценарию.
Экономический эффект применительно к подсистеме хранения при переносе ее в облако будет выше или ниже, чем в случае чисто вычислительных мощностей?
Об этом пока рано говорить. Чтобы оценивать экономический эффект, нужно, во‑первых, перенести в облако хотя бы часть продуктивных систем и, во‑вторых, проработать так некоторое время. Тогда уже можно будет говорить о какой‑то базе для проведения расчетов. По нашим предположениям, экономический эффект от перехода в облако может составить минимум 10%. Также мы надеемся на 35% сократить операционные издержки, а риск простоя корпоративных приложений — на 80%. Но я бы не стал делить возможный выигрыш для разных подсистем, вычислительных или хранения данных. В нашем случае серьезной разницы, мне кажется, нет. Хотя для систем поддержки других бизнес-процессов, например в другой отрасли, это вполне может быть справедливо.
Как планируется развивать и расширять масштабы проекта?
Прежде всего предстоит перенести в облако продуктивную среду. Все работы мы надеемся проделать в течение 2012 г. Потребуется существенное изменение программной и аппаратной среды, а также довольно глубокая «донастройка» систем.
Начальные затраты могут быть нулевыми
Василий Маланин,
менеджер по продуктам для ЦОД MicrosoftДля развертывания частного облака у заказчиков зачастую есть все необходимое оборудование: серверы, системы хранения данных, сетевая инфраструктура. Таким образом, с точки зрения аппаратной части начальные затраты могут оказаться полностью нулевыми. Что касается программной части, решение Microsoft для виртуализации относится к семейству серверных операционных систем Windows Server и распространяется совершенно бесплатно. Эта система виртуализации позволяет заложить основу частного облака с базовыми возможностями консолидации и динамической миграции нагрузки. Минимальность последующих вложений гарантируется высокой гибкостью и преемственностью современных программных решений, позволяющих подключать новые функции и сегменты инфраструктуры и выводить из эксплуатации оборудование, отслужившее свой срок.
