ИТ-инфраструктура

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

Из чего состоят гиперконвергентные решения

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

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

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

• Гипервизор и виртуальные машины

Гипервизоры бывают разными, и в зависимости от потребностей компании можно использовать различные решения. Сегодня существуют проприетарные гипервизоры, такие как Microsoft Hyper-V или VMware vSphere, а также решения с открытым исходным кодом, например KVM с хорошим потенциалом и качественной архитектурой. В недавнем прошлом наша компания приняла решение создать свой собственный гипервизор именно на базе KVM. Тем самым удалось получить прирост производительности и эффективности утилизации ресурсов для целого ряда распространенных задач, а также обеспечить совместимость с open-source-экосистемой KVM.

• Контейнеры приложений

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

• Хранилище данных

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

Реальная экономия от применения гиперконвергенции

Популярность гиперконвергентных решений продолжает расти: только за 2016 год аналитики зафиксировали рост на 80%, и, по оценкам Gartner, системы нового класса займут около четверти рынка интегрированных систем уже в 2019 году (в 2012 году их доля была практически нулевой).

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

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

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

Но и это еще не все: гиперконвергентные системы позволяют экономить средства на обеспечение соответствия требованиям регуляторов. С 1 июля в России вступил в силу «закон Яровой», при этом никто не отменял закон «О персональных данных» и другие нормативные акты. Все компании, обслуживающие в том числе европейские рынки, обеспокоены на сегодняшний день требованиями GDPR, выполнить которые без обеспечения высокой доступности данных оказывается просто невозможно.

Работая с гиперконвергентной инфраструктурой, можно не только обеспечить отказоустойчивость и высокую доступность хранилища данных без приобретения дорогостоящих дисковых массивов, но и сэкономить на количестве дисков, используемых для реплик данных. Например, задействуя алгоритмы Erasure Coding, удается обеспечить двойную защиту 1 Тбайт информации с постоянной доступностью, занимая при этом лишь 1,7 Тбайт. То есть затраты на защиту данных снижаются почти вдвое.

Перспективы развития систем

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

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

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

Автор – Алексей Кобец, старший вице-президент по разработке Virtuozzo.

Черные пятницы и киберпонедельники – источники радости для покупателей и периоды наибольшей занятости для многих продавцов. В компании Hudson’s Bay Company (HBC), которой принадлежат торговые марки Lord & Taylor, Saks 5th Avenue и ряд других, прошлогодняя предпраздничная лихорадка стала самым подходящим поводом для испытания новых функций веб-сайтов.

HBC использует типичный сервер приложений Oracle WebLogic и платформу электронной коммерции Blue Martini, предлагаемую разработчиками RedPrairie. Общий ее стек создавался и совершенствовался на протяжении многих лет. «Она работала, но были проблемы с ее развертыванием, сложно было вносить изменения и обновления», – указал Мэтью Пик, управляющий в HBC командой инженеров по инфраструктуре.

Инженеры HBC стали выяснять, как можно решить эти вопросы. Для решения проблемы были предложены микросервисы и контейнеры.

Для начала реализации своего проекта по смене платформы Пик выбрал Product Detail Page (PDP). PDP представляет собой часть приложения электронной коммерции, в котором содержатся описания и фотографии товаров. Вместо того чтобы встраивать PDP в приложение, разработчики из HBC разбили его на 12 отдельных микросервисов, размещавшихся в контейнерах приложения (один из них загружал изображения, другой обслуживал текстовую часть и т. д.).

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

Запуская PDP в прошлогодние черную пятницу и киберпонедельник, HBC решила подстраховаться и направила на микросервисы PDP лишь часть трафика. В случае возникновения нештатных ситуаций их можно было бы отключить и вернуть весь трафик в традиционное русло. «Мы не стали рисковать всем сайтом, – вспоминал Пик, следивший за ситуацией на протяжении всего запуска новых технологий, с пятницы и до понедельника. – Но рано или поздно настает момент, когда нужно просто сказать: “Давайте попробуем”».

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

Что такое микросервисы?

Эксперты описывают микросервисы по-разному, и согласованного их определения пока не существует. По сути, идея заключается в том, чтобы вместо монолитных приложений проектировался набор компонентов, из которых и будут складываться приложения. Аналитик IDC Эл Хилуа описывает микросервисы как «децентрализованную программную архитектуру, в которой компоненты приложений проектируются и развиваются независимо друг от друга». Связь между отдельными компонентами поддерживается через общие API. Таким образом, приложение или сервис разбиваются на множество компонентов, которые взаимодействуют с помощью API.

Звучит знакомо? Несложно предположить, что микросервисы восходят к модному термину прошлых лет – сервисно ориентированной архитектуре (SOA), воплощавшей идею создания независимых отдельных компонентов приложения.

«Заинтересованность предприятий в микросервисах объясняется поиском нового подхода к построению сервисно ориентированной архитектуры, а также к использованию микросервисов с контейнерами», – пояснил старший вице-президент консультационной компании Cloud Technology Partners Дэвид Линтикум.

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

Преимущества

Микросервисный подход дает следующие преимущества:

Гибкость. Благодаря разбиению приложения на компоненты каждая отдельная его часть разрабатывается независимо. «Вам больше не нужно беспокоиться о синхронизации действий разработчиков», – заметил Сид Сиджбрандидж, генеральный директор стартапа GitLab, предлагающего репозитарий кода, который составляет конкуренцию GitHub. Вместо того чтобы собирать команду из 100 человек, которые будут работать над одним приложением, вы формируете 10 команд по 10 человек, проектирующих отдельные компоненты и внедряющих новые функции по мере их готовности. Не нужно составлять расписание обновлений и собирать приложение полностью – новые функции появляются сразу, как только они будут готовы.

Частичные нарушения. Если какой-то компонент приложения перестает работать, нет опасности того, что откажет все приложение полностью. «Цель заключается в том, чтобы сузить круг неисправностей и минимизировать их последствия», – пояснил аналитик 451 Research Донни Беркхольц. Например, если банковский сайт создан с использованием микросервисного подхода, при отказе функции перевода денег возможность проверить свой баланс у клиентов все равно остается.

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

Однако на словах разработка приложений на основе микросервисов выглядит гораздо проще, чем на деле.

Задачи

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

В таких средах код пишется, тестируется и внедряется быстрее. Многие предприятия, придерживающиеся концепции DevOps, имеют автоматизированную инфраструктуру с самообслуживанием – например, виртуализированные или облачные среды для тестирования и разработки или для поставки уже готовых приложений. Исследования, проведенные 451 Research, показывают, что две трети организаций применяют при разработке приложений методологию agile-проектирования, а около 40% – концепцию DevOps. Именно в таких организациях вероятность успешного внедрения микросервисов наиболее высока. У компаний, не придерживающихся тенденции разработки следующего поколения, процесс перехода к микросервисам будет протекать сложнее.

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

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

«Разработчики, выстраивающие микросервисы, не идут в ИТ-службу оформлять заявку на новую виртуальную машину, – пояснил он. – При agile-проектировании разработчики вправе ожидать, что инфраструктурные ресурсы будут автоматически выделяться им по требованию через API и эластичное масштабирование».

Для поддержки инфраструктурной среды такого рода существует множество различных инструментов. Строить внутреннее облако можно при помощи программного обеспечения для частных облаков, предлагаемого VMware или OpenStack. Если ИТ-служба не хочет заниматься построением инфраструктуры самостоятельно, она может обратиться к платформам публичных облаков Amazon, Microsoft, Google и других поставщиков. Автоматизировать управление инфраструктурой можно при помощи платформ PaaS Cloud Foundry или Red Hat. Для приложений, управляемых событиями (например, для сценариев Интернета вещей), идеально подходят так называемые бессерверные вычислительные платформы. Каждая такая платформа меняет роль ИТ-службы – теперь перед ней могут ставиться разные задачи, начиная от поставок инфраструктуры и заканчивая построением среды, где разработчики самостоятельно будут развертывать микросервисы.

Для чего микросервисы подходят лучше всего

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

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

Важно понимать также, какие функции приложения имеет смысл разбивать на компоненты, а какие – нет. По мнению вице-президента консультационной компании DISYS по глобальным сервисам Ахмара Аббаса, различные компоненты микросервисов должны работать относительно независимо друг от друга. Компоненты, которые нуждаются в совместном использовании данных или в их передаче, замедляют создание приложений в стиле микросервисов.

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

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

– Brandon Butler. What you need to know about microservices. Network World. November 9, 2016

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

От перфокарт – к лентам

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

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

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

Архитектура для библиотек

В 2010 году в институте был в целом завершен многолетний проект модернизации ИТ-инфраструктуры и переноса гидрометеорологических данных на современные носители информации.

Как пояснил Шаймарданов, сейчас главным звеном в архитектуре системы хранения центра является пара роботизированных ленточных библиотек максимальной емкостью 4 Пбайт каждая. Это два ряда устройств хранения, в одном из которых 17 библиотечных шкафов, а в другом – 14. Управляет работой библиотек мэйнфрейм с операционной системой Linux. Он сопряжен с дисковым массивом общей емкостью порядка 100 Тбайт. Массив используется по сути как «внешний диск» для мэйнфрейма. Запись данных на картриджи с целью резервного копирования осуществляется специализированным ПО.

«Лента – наиболее подходящий инструмент долговременного хранения. Удельная стоимость хранения данных на ней оптимальна. Использовать для создания архива жесткие диски – дорого и не очень ненадежно. Мы также присматривались к оптическим библиотекам, но возникли опасения, что через некоторое время DVD могут выйти из строя и данные на них будут потеряны. К тому же у нас просто нет необходимости скоростной потоковой записи и чтения данных. Мы записываем их постепенно и последовательно, скорость для нас – не главное», – сообщил Шаймарданов.

Нюансы хранения и доступа

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

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

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

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

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

С другой стороны, и библиотека не целиком используется для архивных нужд. Часть ее отрезана логически и представляет собой отдельную подсистему, которая тоже нужна для оперативной работы, прежде всего для создания цифровых копий документов уже из бумажного архива. Он, к слову, насчитывает более 352 тыс. единиц хранения в самом институте, а в целом российской службой по гидрометеорологии накоплено более 2 млн единиц хранения, рассредоточенных в подразделениях по всей России. Поэтому вопрос оцифровки бумажных источников данных является актуальным для Росгидромета.

***

По словам Шаймарданова, в настоящий момент возможности, заложенные в архитектуре системы, достаточно широки, поэтому в ближайшие десять лет она должна полностью обеспечить все нужды Росгидромета в надежном хранении данных. При этом по-прежнему актуальна задача развития структурных элементов системы: отдельные узлы нуждаются в обновлении, необходимо постоянно повышать скорость доступа к сохраненным материалам и инструментам для обработки метеоданных. Развивать систему в центре планируют эволюционным путем. Устаревшие диски или элементы библиотек будут меняться на более совершенные версии по мере их появления на рынке. А вот от мэйнфрейма в центре, скорее всего, откажутся и перейдут на альтернативную платформу управления библиотеками. Задачи, которые он решает, уже могут быть перенесены на устройства стандартной архитектуры x86. В этой связи центр ведет активные программные разработки под системы Linux и Unix.

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

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

Список задач

Как пояснил исполняющий обязанности начальника Управления-службы информационных технологий СПбГУ Андрей Жамойдо, одна из наиболее актуальных задач, которую сейчас решают в университете, связана с долговременным хранением видео: «Существует ряд законодательных требований к продолжительности хранения некоторой видеоинформации, и мы должны соблюдать эти требования. В частности, мы обязаны сохранять все записи защит диссертаций (а за год это почти триста событий). Этот объем данных довольно большой. Кроме того, уже начиная с этого года по инициативе ректора СПбГУ мы будем публиковать в открытом доступе все дипломные работы наших студентов до даты защиты. Это большой и важный проект, он будет реализован в СПбГУ в рамках проекта “Открытое образование”».

Кроме того, СПбГУ реализует долгосрочный проект, в рамках которого будет записываться весь процесс обучения студентов с первого курса до завершения учебы. Разумеется, видеоконтент будет адаптирован и обработан, для того чтобы можно было воспользоваться этими записями и получить готовый образовательный продукт (в том числе для формирования курсов дистанционного обучения). Но университету придется хранить и сырые видеоданные. Это позволит при необходимости вернуться к исходным материалам и убедиться в том, что во время редактирования ничего не было потеряно.

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

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

К выбору оптимального решения

До настоящего времени ядром архитектуры хранения данных в СПбГУ являются дисковая система и ленточная библиотека IBM. Этому комплексу, как замечают в университете, присущи функциональные ограничения. Во-первых, дисковая система хранения данных имеет довольно высокие показатели по энергопотреблению; во-вторых, ленточная библиотека действует по принципу последовательной записи и чтения, и поэтому требуется немалое время доступа к хранящейся на ленточных картриджах информации.

Летом 2014 года компания Panasonic предложила СПбГУ рассмотреть вариант внедрения системы долговременного хранения данных на основе роботизированной оптической библиотеки LB-DH8 на дисках Blu-ray.

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

Библиотека имеет модульную конструкцию, и ее емкость может быть легко увеличена. Данные хранятся в картриджах, каждый из которых содержит 12 оптических дисков и может хранить в совокупности до 1,2 Tбайт данных. В систему входят базовый модуль (устройство записи картриджей), модуль расширения и загрузчик картриджей. Максимальная загрузка каждого модуля – 76 картриджей. Таким образом, в одном модуле можно хранить до 91,2 Tбайт данных. В зависимости от требуемого объема хранения в 19-дюймовую стойку устанавливается нужное число дополнительных модулей расширения. В максимальной конфигурации с семью модулями в стойке емкость библиотеки увеличивается до 638,4 Tбайт.

В модулях чтения-записи установлены по 12 приводов, это позволяет системе одновременно работать с 12 оптическими дисками и очень быстро считывать и записывать данные (со скоростью до 216 Мбайт/с). Заявленный производителем ресурс хранения данных на дисках составляет не менее 50 лет.

Притягательная экономичность

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

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

Когда система на дисках Blu-ray не производит операций чтения-записи, модуль хранения потребляет всего 7 Вт электроэнергии Источник: Panasonic

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

Также, по оценкам специалистов СПбГУ, библиотека Panasonic производит операции записи и чтения значительно быстрее, чем имеющаяся ленточная библиотека.

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

Если результаты тестирования библиотеки Panasonic удовлетворят СПбГУ, на ней планируется разместить прежде всего видеоархив, затем архив служебных документов, возможно, мастер-копии сканов научной библиотеки им. М. Горького СПбГУ, результаты научных экспериментов – то есть все виды данных, которые генерируются в больших объемах, но востребованы бывают спорадически. Это позволит университету решить основные задачи длительного хранения, а заодно высвободить емкость более дорогой и более быстрой системы хранения данных IBM XIV, чтобы использовать ее для других приложений.

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

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

Непредвиденные обстоятельства

Еще в 2008 году компанией было принято решение создать специальный Центр хранения сейсмической информации (ЦХСИ) на базе научно-исследовательского и проектного института «РН-КрасноярскНИПИнефть» (хотя сама идея создания подобного банка данных вынашивалась давно). Центр должен был решить важнейшие задачи по сбору, обработке и интерпретации полевых данных, полученных в ходе сейсмических исследований, а также обеспечить их длительную сохранность и предоставление оперативного доступа к ним пользователей «Роснефти».

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

Созданию технологического комплекса ЦХСИ препятствовали некоторые внезапно возникшие обстоятельства, с которыми в тот период, вероятно, столкнулись многие российские компании.

«Изначально мы планировали построить комплекс на базе оборудования компании Sun Microsystems. Но, поскольку стоимость проекта была высокой, приобретение оборудования затормозилось, а за это время произошли серьезные изменения на рынке – Oracle приобрела Sun, и было неясно, как в дальнейшем станет развиваться ее продуктовая линейка и обеспечиваться техническая поддержка», – рассказывает Леонид Афанасьев, главный специалист – заместитель начальника отдела технологий ГРР и проектирования «РН-КрасноярскНИПИнефти».

Из планируемого списка оборудования (пять серверов, три дисковые системы хранения и две ленточные библиотеки) были приобретены лишь один сервер Sun для СУБД Oracle и одна система хранения данных Sun.

«В результате мы приняли решение отказаться от построения комплекса на базе серверов и систем хранения Sun и перенести систему на платформу x86 и оборудование компании IBM», – пояснил Афанасьев.

Таким образом, комплекс был построен на базе серверов IBM System X и рабочих станций на базе процессоров x86-архитектуры. Также в системе используются: ленточная библиотека IBM TS3200 и ленточные приводы IBM и HP; система хранения данных IBM. Сеть хранения данных построена на коммутаторах SAN компании IBM (Brocade), а сеть передачи данных (Ethernet) – на коммутаторах Cisco.

То есть собственно система долговременного хранения данных ЦХСИ не работает отдельно – она тесно интегрирована с другими элементами построенного комплекса. Поэтому каждый из них следует рассмотреть подробнее.

Интегрированный комплекс

Первый элемент – система ввода исходной информации – это не что иное, как специализированные рабочие станции с подключенными к ним устройствами ввода-вывода различных форматов: Exabyte (ленты 8 мм), DAT (ленты 4 мм), DLT, LTO разных поколений, IBM TS и др. В состав системы ввода-вывода также включены оптические приводы DVD; пока встречается даже такая экзотика, как диски ZIP.

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

Второй элемент – система хранения данных – включает в себя ленточную библиотеку, серверы баз данных Oracle и сервер хранения, играющий роль сетевого хранилища (NAS), а также сервер обработки (облачных вычислений).

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

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

Для хранения больших объемов обработанных сейсмических данных (кубов 3D) используется другой подход: данные регистрируются в системе и помещаются на дисковый массив в виде объекта базы данных BFILE (внешний двоичный файл External Binary File). Такой объект хранится вне базы данных как файл операционной системы, но он доступен из таблиц БД.

А вот результаты обработки сейсмических профилей 2D хранятся непосредственно в базе данных Oracle в файлах данных типа BLOB (Binary Large Object).

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

Что касается системы предоставления доступа к данным, то она представляет собой кластер из двух веб-серверов Аpache.

Предпочтение – лентам

Большая часть данных ЦХСИ хранится на лентах. Основным носителем данных являются ленты LTO третьего, четвертого и пятого поколений. В следующем году центр планирует начать использовать ленты шестого поколения.

«Предпочтение лентам было отдано потому, что формат LTO достаточно распространен в отрасли. Стоимость лент в соотношении цены за единицу хранимой информации можно считать низкой. Ленты устойчивы к ударам, и их проще транспортировать, в отличие от жестких дисков. Формат LTO активно развивается, на мой взгляд, у этой технологии есть будущее», – подчеркнул Афанасьев.

На жесткие диски системы хранения отправляются файлы данных СУБД Oracle и BFILE (которые по сути тоже являются объектами Oracle). Есть также отдельная категория данных – результаты работ с сейсмической информацией. Это отчеты и графические приложения к отчетам. До недавнего времени такие материалы записывались на оптические носители CD и DVD, сейчас же они переносятся в базы данных и доступны уже не в виде краткого описания, а в виде полноценного файла отчета, содержащего графические приложения. Это стало возможным благодаря увеличению объема дискового массива системы хранения.

***

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

Также в настоящее время в ЦХСИ тестируется технология автоматизации переноса исходных полевых данных на ленты LTO. А в отдаленной перспективе специалисты «РН-КрасноярскНИПИнефти» рассчитывают построить полностью автоматизированное хранилище, где основное обслуживание системы хранения сейсмических данных «Роснефти» будут выполнять роботизированные системы.

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

Бесконечная масштабируемость лент

Магнитные ленты используются в ИТ-индустрии с 1952 года, относительно недавно они рассматривались как основное средство для записи данных. Однако с развитием компьютерных систем на базе жестких дисков, которые работают значительно быстрее ленточных библиотек, основным применением лент стало долговременное хранение данных.

Еще в прошлом десятилетии существовало несколько несовместимых между собой типов ленточных накопителей (в том числе Quantum SuperDLT, Sony AIT, Exabyte Mammoth), в настоящее время стандартом де-факто хранения на ленте стал открытый стандарт Linear Tape Open (LTO), актуальность которого совместно поддерживают HP, IBM и Quantum.

Последняя версия этого стандарта – LTO-6 – обеспечивает хранение на одном картридже 2,5 Тбайт данных, а при использовании аппаратного сжатия емкость картриджа можно увеличить до 6,25 Тбайт. В сентябре нынешнего года опубликована спецификация LTO-7, позволяющая хранить на одном картридже 5 Тбайт данных (при использовании сжатия – до 15 Тбайт). Консорциум LTO планирует выпустить с интервалом около трех лет еще как минимум четыре поколения устройств, при этом емкость картриджа с каждым новым поколением будет увеличиваться примерно вдвое. Прогнозируется, что один картридж LTO-10 будет вмещать 48 Тбайт данных (без сжатия). Важно отметить, что LTO не предусматривает полноценной преемственности поколений считывающих устройств. Нет никаких гарантий, что привод нового поколения сможет читать и записывать данные на картриджах предыдущих версий. Например, на приводе LTO-6 можно читать и записывать картриджи LTO-5, но записывать данные на картриджи LTO-4 нельзя – их можно только прочесть.

Производители систем хранения сейчас предлагают ленточные библиотеки разного класса – например, у компании HP библиотека StorEver MSL2024 в начальной конфигурации вмещает 24 картриджа и 2 привода LTO, а библиотека корпоративного класса StorEver ESL G3 расширяется от 100 до 12 тыс. картриджей и 192 приводов LTO, занимая в максимальной конфигурации 16 шкафов.

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

У ленты также значительно ниже, чем у жестких дисков, удельная стоимость размещения данных на носителе. Так, стоимость 1 Гбайт полезной емкости на картридже LTO-6 составляет порядка 0,08 долл. Но и хранение записанных на ленте данных обходится существенно дешевле, чем на дисках. Это связано с тем, что кассеты с магнитной лентой, в отличие от винчестеров, установленных в работающем дисковом массиве, после записи на них данных не потребляют энергию и их можно переместить в специальное хранилище для экономии места в дата-центре.

Срок хранения данных на ленте составляет 20-30 лет

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

Для ускорения поиска и считывания записанных на ленте данных в LTO применяется технология Linear Tape File System (LTFS), позволяющая организовать с помощью файловой системы содержимое ленты таким образом, что ее работа будет аналогична работе файловой системы на жестких дисках или флеш-накопителях. Например, можно будет выводить каталог записанных на картридже файлов или перетаскивать на него файлы мышью.

Как утверждают производители ленточных систем, срок хранения данных на ленте составляет 20-30 лет. Однако нужно учитывать, что по истечении этого срока приводы, на которых производилась запись, будут давно сняты с производства, а на современных приводах уже нельзя будет прочитать картриджи, записанные несколько десятилетий назад (напомним, что LTO обеспечивает совместимость по чтению только с двумя предыдущими поколениями, поэтому на современных приводах LTO-6 нельзя прочесть картриджи LTO-4, записанные десять лет назад).

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

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

Уязвимая органика оптических дисков

Первые компакт-диски появились в 1982 году, и этот тип носителей по-прежнему широко используется домашними пользователями ПК, несмотря на популярность флеш-накопителей и внешних жестких дисков. Чаще всего домашние пользователи хранят на компакт-дисках свои фото или библиотеку фильмов. Тем не менее обычные оптические диски CD и DVD плохо подходят для долговременного хранения данных из-за химических процессов, которые со временем приводят к постепенному разрушению изготовленного из органических материалов записывающего слоя диска, и записанная на диске информация теряется уже через 7-15 лет. Поэтому производители оптических дисков разработали специальные накопители для архивного хранения.

Компании Sony и Panasonic совместно разработали формат дисков Archival Disc, обеспечивающий сохранение информации в течение не менее 50 лет. Первое поколение Archival Disc, представленное нынешним летом, обеспечивает хранение на одном диске 300 Гбайт данных, а у второго и третьего поколений емкость диска увеличится до 500 Гбайт и 1 Тбайт соответственно. Как заявляют разработчики Archival Disc, все три поколения будут полностью совместимы между собой.

Новый формат оптических дисков обеспечивает сохранение информации в течение не менее 50 лет

Компания Millenniata, основанная в 2007 году ученым-химиком Мэтью Линфордом, разработала оптические диски для архивного хранения M-Disc, в которых имеется специальный защитный слой из неорганического материала. По утверждению Millenniata, M-Disc способен сохранять записанную на диске информацию до 1 тыс. лет. Компания Verbatim в нынешнем году начала производить диски M-Disc и предлагает для решений корпоративного класса накопители емкостью 100 и 200 Гбайт. Для записи информации на диски M-Disc используется специальный привод M-Writer, но прочитать их можно на обычных приводах DVD и Blu-Ray.

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

Быстрый доступ к массивам жестких дисков

Хранение архивов на жестких дисках обходится довольно дорого, тем не менее ряд производителей систем хранения предлагают дисковые системы, разработанные для обслуживания электронных архивов. Например, компания EMC уже почти десять лет выпускает систему Centera, а входящая в состав WD компания HGST предлагает систему Active Archive System, масштабируемую до 4,7 Пбайт. Производители жестких дисков выпускают специальные модели для архивных систем, отличающиеся пониженным энергопотреблением и высокой емкостью, – например, 8-терабайтные диски Seagate Archive HDD.

В конце прошлого десятилетия стоимость хранения архивов и других «холодных» данных на жестких дисках пытались снизить с помощью технологии MAID (massive of idle discs), позволяющей уменьшить энергопотребление дисковых систем за счет снижения скорости вращения тех накопителей, к которым за последнее время не было обращений. Но технология не получила широкого распространения. Некоторые вендоры пытались создать архивные системы на базе съемных жестких дисков, которые можно перемещать из системы в специальное хранилище так же, как ленточные картриджи и оптические диски, однако и эти проекты потерпели неудачу.

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

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

А как же флеш-память?

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

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

Соответствовать ожиданиям бизнеса

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

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

«В прошлом году ярким примером такого бизнес-проекта стало внедрение платформы электронной коммерции Oracle Commerce — крупный проект, который длился больше двух лет», — говорит Сергеев. С ноября было запущено решение, которое позволило компании успешно пройти «высокий сезон» с учетом нынешних рыночных реалий и обеспечило новые возможности для развития бизнеса. Как результат, в прошлом году интернет-продажи выросли на 90%.

Специально под этот проект была создана модульная виртуализованная ИТ-инфраструктура. Это обеспечило высокую скорость масштабирования ИТ-комплекса и упростило его обслуживание.

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

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

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

Например, осенью «М.Видео» развернула виртуальные рабочие места пользователей по технологии VDI (Virtual Desktop Infrastructure). Для подключения к виртуальным рабочим станциям VDI на местах сотрудников установлены нулевые клиенты. Они не требуют обслуживания, а работают в среднем в полтора-два раза дольше, чем традиционные системные блоки, и при необходимости мгновенно заменяются. Благодаря консолидации пользовательских и серверных вычислительных ресурсов в среднем в пять раз снизилось энергопотребление, сократились затраты на администрирование и модернизацию рабочих мест.

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

Когда время имеет значение

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

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

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

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

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

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

Непрерывность как преимущество

«Меня приглашали именно для модернизации информационных систем. Новой ERP-платформой для компании на ближайшие пять лет стала Microsoft Dynamics AX 2012», — рассказывает Станислав Гумницкий, директор по ИТ Concept Group, проработавший в компании уже два с половиной года.

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

Concept Group — компания, работающая в индустрии моды; ее розничная сеть насчитывает около 200 магазинов и 170 франчайзинговых партнеров. Кроме того, есть интернет-магазин и крупный склад с высокой оборачиваемостью товаров. Нельзя забывать про специфику модной одежды: жизненный цикл каждой коллекции крайне короток — всего девять месяцев, плюс несколько недель непосредственно на продажу, после чего про нее можно забыть. Таким образом, задача компании — не только продать, но и выйти к концу сезона с нулевыми остатками.

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

До определенного времени компания работала на решениях «1С». Однако они имеют предел производительности, и наступает момент, когда вкладывать деньги в оборудование становится бессмысленно. Кроме того, появились планы по развитию бизнеса, идеи о внедрении бизнес-аналитики, CRM, POS-решений в магазинах. Но главное — требовалась более серьезная ERP-платформа, под которую пришлось создавать новую инфраструктуру: следовало выжать из решения максимум производительности.

Начать с виртуализации

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

«Начальной точкой изменений стала виртуализация ресурсов: все бизнес-сервисы за пару месяцев были перенесены в свое частное облако, построенное на Microsoft Hyper-V», — подчеркивает Сергей Соколов, руководитель группы администрирования инфраструктуры Concept Group. Появилась гибкая инфраструктура, в которой «поддать газу» какому-нибудь сервису было достаточно просто. Помимо этого, была достигнута экономия серверных ресурсов: сейчас они используются на 70–80%. В итоге все оборудование вошло в состав единого облака, его ресурсы можно перемещать на различные задачи в зависимости от ситуации. В качестве новой аппаратной платформы были выбраны решения IBM.

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

В основу новой инфраструктуры положено решение, спроектированное на базе IBM Flex System x240 и многоуровневого комплекса хранения данных, в который вошли Storwize V7000, FlashSystem 840, а также система хранения данных начального уровня IBM Storwize V3700. Флеш-система — самый быстрый элемент системы хранения — используется для обработки «горячих» блоков баз данных ERP.

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

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

Узкие места облаков

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

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

Кроме того, облака негативно влияют на вопросы непрерывности бизнеса. Как только облако выносится вовне, каналы связи мгновенно становятся узким местом.

Наконец, по мнению Гумницкого, в России пока нет компаний, продающих полноценные облака. По крайней мере, этот рынок еще не дошел до среднего бизнеса. Слово «сервис» на постсоветском пространстве пока не приобрело того значения, какое должно в себе нести, включая формирование адекватных, учитывающих прежде всего интересы заказчика соглашений об уровне обслуживания (Service Level Agreement, SLA) и их соблюдение, резервирование мощностей и т. д. Даже если предположить возможность заключения SLA, отвечающего требованиям бизнеса, то такие контракты будут сверхзатратными.

«От своего подразделения я могу потребовать любой надежности, ограниченной здравым смыслом, причем за каждый сервис будут отвечать конкретные сотрудники. У сервис-провайдеров несколько инженеров отвечают за десятки и сотни клиентов — о какой оперативной реакции в этом случае может идти речь?» — задается вопросом Гумницкий.

Справедливости ради следует отметить, что инфраструктура Concert Group вынесена на площадку коммерческого ЦОД. Такие задачи, как электропитание и кондиционирование, внешнему поставщику доверить все-таки смогли.

***

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

Вычислительные мощности есть у всех дата-центров, и во всех в той или иной мере присутствует охлаждение. Конечно, доступные вычислительные мощности могут отличаться, но большинство ЦОД вполне способно удовлетворить потребности большей части клиентов. На недавней конференции Finance and Investment Forum, прошедшей в Лондоне, от клиентов и инвесторов исходил четкий посыл: «Нас не заботят ваши пустые заявления. Нам интересны лишь безопасность ЦОД и получаемый уровень обслуживания».

Между тем большинство владельцев ЦОД, похоже, больше беспокоит то, что они думают о себе сами. (Возможно, мы просто преувеличиваем степень их зрелости?) «Мой ЦОД отвечает стандарту Tier 3, а мой – Tier 3*, у моего показатель PUE, характеризующий эффективность энергопотребления, составляет 1,2, а у меня – 1,1» – слышим мы то и дело.

Но: a) на самом деле это не так; б) такие уровни по большей части недостижимы; в) практически всегда это не более чем похвальба; г) клиентов все это совершенно не интересует.

Клиенты справедливо ждут, что ЦОД будет находиться в состоянии постоянной готовности. Источник: Leonardo Rizzi — CC BY-SA 3.0

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

Клиенты справедливо ждут, что ЦОД будет находиться в состоянии постоянной готовности. Они рассчитывают также, что мощности его обладают достаточным уровнем резервирования, и, если один элемент выйдет из строя, его тут же заменит другой без какого-либо прерывания обслуживания. Клиенты надеются, что ЦОД работает максимально эффективно. В конце концов, на протяжении многих лет нам постоянно твердят об этом. Редко когда можно встретить владельца коммерческого ЦОД, который не упомянул бы о «Tier 3» (очень часто это является саморекламой) или не утверждал, что у него показатель PUE меньше, чем у кого бы то ни было (еще одно голословное заявление). А вот о чем многие предпочитают не упоминать, так это о безопасности и реальном качестве обслуживания,  ведь это отнюдь не является их сильной стороной.

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

Почти каждую неделю мы слышим очередную историю о брешах в системе ИТ-безопасности.

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

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

Позиция облачных провайдеров по вопросу надежности предоставляемых сервисов

Как показал опрос, проведенный в начале 2015 года Аналитической группой OSP Data, главным препятствием на пути использования облачных сервисов компании по-прежнему считают проблемы информационной безопасности. Опасения пользователей также вызывает надежность предлагаемых провайдерами сервисов. Между тем подавляющее большинство провайдеров предусматривают заключение соглашения SLA, чаще всего обязательное.

Источник: OSP Data, 2015

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

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

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

Оптимальный вариант размещения ИТ-систем

На VI форуме «МИР ЦОД – 2015» аналитическая группа OSP Data провела блицопрос относительно оптимального варианта размещения ИТ-систем.

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

Источник: OSP Data, 2015

 

В федеральной сети автосервисов «Белый сервис» инициатором полного вывода инфраструктуры в облака стало руководство компании, оно отстояло проект, несмотря на серьезное сопротивление ИТ-специалистов.

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

В экономию поверили не сразу

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

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

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

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

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

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

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

Разумеется, перевести бизнес-потребности в характеристики приобретаемой инфраструктуры далеко не просто, как и наоборот — перевести технические термины в язык, понятный «простым смертным».

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

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

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

Проект оказался настолько удачным, что в итоге в облако были переведены все используемые системы. Сначала это были просто решения «1С», и к ним были подключены около 20 компаний. В дальнейшем в облако были перенесены все интегрированные с корпоративной системой решения. Все программные продукты, поддерживающие работу 51 автосервиса федеральной сети, сейчас эксплуатируются в облаке. Эти решения интегрированы с «1С» для обеспечения единой точки доступа к ним. Речь идет о многих специализированных программах — например, о решениях по подбору запчастей, нормированию различных работ и т. п.

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

Гибкость как преимущество

«Белый сервис» предоставляет единые услуги для всей сети партнеров, поэтому так важны надежность и стабильность.

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

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

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

Быстрота и гибкость компании — критически важные качества на нынешнем рынке.

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

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

Надежность с минимальными затратами

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

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

«Помимо значительного увеличения надежности, других бизнес-требований как таковых не было. В результате было принято решение в пользу более современной облачной технологии», Андрей Столяров, руководитель группы системного администрирования банка «ДельтаКредит»

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

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

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

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

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

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

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

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

«С первоначальной задачей мы справились — созданное хранилище успешно используется. С его помощью мы получили возможность смотреть на клиента, на его поведение внутри нашего бизнеса: какие счета открывает, как ведет себя при просрочках и т. п. Это замечательно, но дает видение клиента лишь с одной стороны — не более чем на 180 градусов», — говорит Сотниченко. Как только клиент покидает виртуальные границы банка, про него ничего не известно. Банк не способен понять его мотивацию, предсказывать его действия.

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

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

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

Стоимость имеет значение

Что такое «озеро данных» и почему оно позволяет решить поставленные аналитические задачи?

«Идея очень простая: мы все данные грузим в кластер на платформе Hadoop, и все приложения используют эти данные, — объясняет Сотниченко. — Можно использовать и другие платформы, но Hadoop, на наш взгляд, имеет много плюсов, в том числе экономических».

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

Что еще немаловажно, Hadoop реально, а не на словах поддерживается сообществом разработчиков — любую возникшую проблему можно довольно оперативно решить.

«Как ни странно, в проприетарных системах это может стать непростой задачей — у нас есть опыт, когда бизнес-критичная проблема в коммерческом аналитическом решении “живет” уже три года, и мы ничего не можем с ней сделать, несмотря на обращение к руководству вендора. Надеемся, что open source позволит избежать таких ситуаций», — говорит Сотниченко.

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

Не превратить озеро в болото

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

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

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

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

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

Хранилища еще пригодятся

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

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

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

Потоки данных внутри Hadoop напоминают потоки в классическом хранилище. Вопрос их реализации является одним из ключевых. Изначально в ТКС эту задачу пытались решать на платформе Java, однако попытки были не очень удачными — получился хаос. «Наводить порядок» пришлось с помощью решений Informatica — вся обработка и трансформация данных внутри Hadoop теперь доверены им.

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

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