ЦОД должен обеспечить удобную работу с информацией
Системы хранения данных (СХД) позволяют «развязать» процессы наращивания вычислительных мощностей и емкостей хранения и управлять ими независимо друг от друга, исходя из задач компании. Грамотная организация хранилищ данных оптимизирует физический объем, занимаемый различным оборудованием в серверных помещениях, а также количество потребляемого питания, затраты на приобретение оборудования и его эксплуатацию. Количество выделяемого тепла снижается. Кроме того, СХД обеспечивают консолидированное управление гетерогенной информационно-вычислительной инфраструктурой компании — т.е. такой инфраструктурой, которая состоит из оборудования различных производителей. Виртуализация Допустим, хранилище данных организовано по принципу распределенного решения — т. е. имеется некоторое количество простых аппаратных однотипных серверов, которые подсоединены к массивам информации. Они служат для очень важной задачи, выполнение которой не должно прерваться ни на минуту, классический пример - процессинг банковских карт. Даже в том случае, если аппаратный сервер, который отвечает за выполнение этой задачи, выйдет из строя, необходимо, чтобы система продолжала выполнять задачу, и клиенты, пользователи этого приложения, не заметили аварии. Алексей Свержановский, руководитель направления СХД компании «Комптек», рассказал, как эта задача решена в системах хранения данных компании EMC: «операционная система VMware устанавливается «поверх» нескольких серверов, в результате чего создается виртуальный сервер с консолидированным управлением. Благодаря встроенному в VMware механизму VMotion, в тот момент, когда неожиданно аппаратный сервер выходит из строя, теряет питание, на соседнем сервере тут же создается аналогичная виртуальная машина и приложение продолжает работать там, хотя физически сервер уже не существует. Таким образом, работа приложения не останавливается, благодаря тому, что система, получив сигнал об отказе одного из серверов, обеспечила миграцию на резервную аппаратную платформу, и приложение продолжило работу через IP адреса». Но задача может быть и обратная. Например, есть мощный сервер, хотя задачи, которые приходится на нем решать, до какого-то момента не требуют всех его возможностей. Руководитель ИТ-департамента знает, что будут появляться приложения, которые потребуют достаточно больших вычислительных мощностей для решения других задач. Соответственно, администратор может создать в одной большой машине несколько виртуальных серверов. Например, 5% мощности выделяют в отдельный виртуальный сервер, управляемый отдельной операционной системой, и устанавливают на нем все необходимые приложения. Затем, когда понадобилось установить другое приложение, с другими требованиями, администратор создает новый виртуальный сервер, забирающий, например, 30% от мощности всей машины, устанавливает на нем необходимую операционную систему и назначает каждому серверу определенный приоритет. Таким образом, решается обратная задача: если в первом случае собирали несколько маленьких аппаратов в одну мощную отказоустойчивую большую виртуальную систему, в данном случае берется одна большая система и выделяются вычислительные мощности под появляющиеся приложения. Что при этом делает операционная система, которая управляет всей машиной (в частности VMware)? Смотрит, какие у нее есть процессоры, сколько свободной мощности, то есть анализирует всю аппаратную структуру. После этого, когда администратор просит выделить дополнительные ресурсы, VMware создает виртуальный сервер, которому выделяет процессоры, мощности, определенное количество оперативной памяти. На этот виртуальный сервер ставится другая ОС, например Windows, которая видит только то, что ей показывает VMware, она не видит, что этот же процессор используется соседней ОС Linux, или Unix, или любой другой. При этом те ОС и приложения, которые уже работают, никак не влияют на новые. Таким образом, администратор может достаточно легко создавать виртуальные сервера, назначать им свои задачи, устанавливать приоритеты, защищать и централизованно управлять. Технологии виртуализации позволяют централизовано управлять вычислительными мощностями для решения определенных задач. Вычислительные ресурсы, в свою очередь, решают назначенные задачи, обрабатывают определенные данные, которые получают из разнообразных бизнес-приложений и информационных систем предприятия. Собственно от того, как организован доступ к информации, ее поиск, хранение и защита зависит надежная и стабильная работа всей информационной инфраструктуры и непрерывность бизнеса. Консолидация Для эффективного управления большим количеством разнородных информационных приложений, архивов и баз данных требуется их в первую очередь консолидировать, т.е. объединить для единого управления. Сама по себе консолидация информации нужна только как первый шаг для дальнейшего структурирования, организации хранения и защиты информации, поэтому уже при объединении информации в единые хранилища ее желательно определенным образом структурировать по видам приложений. В любой компании есть как бизнес-образующие приложения (например в банках это те, что обеспечивают банковский день), так и задачи, которые покрывают простые офисные нужды — например электронную почту или хранение файлов в сети. Следовательно, можно выделить, как минимум две большие группы задач — бизнес-образующие и бизнес-обеспечивающие, которые необходимо между собой разделить внутри всего консолидированного массива информации, чтобы потом в соответствии с их приоритетом вести политику защиты, хранения, уничтожения и т.д. — т.е. управления жизненным циклом информации. Приоритеты разных приложений понятны, исходя из анализа рисков потери той или иной информации для бизнеса. Например, если банк потеряет информацию о банковском дне — это может означать серьезную угрозу, вплоть до потери бизнеса, если потеряется почта — бизнесу будет нанесен урон, но он восстановим. Наконец, если потеряется сетевое хранилище — это неприятно, но для бизнеса не смертельно. Естественно, это обобщение, бывает и так, что сетевое хранение является основным для бизнеса - например, если компания занимается разработкой программного обеспечения, то потеря хранения всех наработок может нанести существенный урон. Главное - понимать уже на стадии консолидации информационных ресурсов, что информация по своей структуре неоднородна и представляет разную ценность для бизнеса. По мнению Андрея Кормильцева, директора ИТ-депаратемнта компании «Черус», задача структурировать информацию - существенно более сложная, чем просто разделить ее по видам, потому что и внутри каждого вида она неоднородна. Если, например, попытаться нарисовать график жизненного цикла информации, в котором отразить зависимость стоимости единицы информации от времени, будет видно, что есть информация, у которой максимальная стоимость приходится на момент непосредственно после ее создания, потом она постепенно дешевеет, а есть информация, которая в момент создания, сиюминутно, не интересна, но через два года станет ценной (например, информация, которая нужна для аналитики продаж и т.п. Таким образом, информацию можно разделить на разные виды, и внутри каждого вида она имеет разные графики ценности относительно времени. Поэтому следующим логичным шагом развития СХД стали системы иерархического хранения данных, которое первыми придумали в IBM. Появились различные системы, которые отличались стоимостью за Гб емкости хранения. Сегодня у всех ведущих производителей систем хранения данных (Hitachi, HP, ЕМС, IBM) есть в продуктовой линейке hi-end системы (от 20$ за гигабайт хранения), middle-range системы и недорогие ленточные массивы. Управление ЖЦ информации Появление разных по стоимости за ГБ емкостей хранения позволило распределять информацию на них сообразно ее стоимости. Например, БД Oracle подключается к дорогой емкости хранения, почта и хранение сетевых файлов — к системам среднего уровня, а на ленточных накопителях делаются раз в неделю back-up-копии. Подразумевается, что информация уже централизована, потом внутри этой централизации сделано иерархичное разделение, сообразно ее структуре. Таким образом, информацию внутри нашей иерархичной сети хранения можно рассортировывать изначально правильно, то есть более дорогие системы хранения будут брать на себя бизнес-образующие системы, более дешевые системы хранения — почту и сетевое хранение. Введение иерархического хранения позволило сделать следующий шаг в развитии СХД, который состоит в том, чтобы обеспечить наиболее ценной в данный момент времени информации хранение на дорогих и качественных системах и соответствующую защиту. Затем, по мере снижения ценности, информация должна перемещаться на более дешевые ленточные массивы, а в какой-то момент времени вообще уничтожаться, чтобы освобождать пространство для новых информационных волн и не занимать дорогое место на серверах и в системах хранения. Это и есть задача управления жизненным циклом информации. Таким образом, сначала информация была разделена по вертикали, была установлена определенная иерархия хранения. Следующая задача - разделить ее по горизонтали в плане времени. Здесь нужны механизмы, которые внутри этих иерархических систем хранения умели бы управлять информацией сообразно ее стоимости в данный момент времени. Необходимость таких систем очевидна. Например, банки работают с оперативными данными за последние полгода — год. Кроме того, у банков есть обязательства хранить информацию 3 года, а рекомендательные стандарты Центробанка и Basel II обязывают хранить информацию не менее 5 лет. Но вся информация, которая старше одного года для оперативной деятельности не нужна, ее необходимо только хранить и защищать. По словам Андрея Кормильцева, в случае банка можно сделать так, чтобы вся информация моложе года хранилась в базе данных и обрабатывалась АБС (автоматизированной банковской системой), а все, что старше года и младше 5-ти лет, аккуратно отрезалась каждый раз программными средствами, убиралась из базы и складывалось в архив. «Тогда облегчается не только обработка информации, но и ее оперативное сохранение (создание backup копий), сокращается размер необходимых для back-up емкостей. Стоимость хранения тоже будет меньше, скорость восстановления в случае сбоя будет выше, защита — надежнее», - отмечает эксперт. Таким образом, задача управления жизненным циклом информации сводится к тому, что необходимо наложить какую-то сеть на иерархическую систему хранения, которая будет в соответствии с некоторой политикой переливать информацию с более дорогих на более дешевые системы и, возможно, обратно. Очевидно, это самая сложная задача, потому что для ее решения необходимо понимать бизнес-процессы компании. Ведущие разработчики СХД поставляют специализированное ПО, которое является инструментарием, позволяющим программировать эти правила «под себя». К примеру, компания EMC только за 2003-2007 гг. приобрела несколько десятков компаний, занимающихся разработкой комплексных программно-аппаратных решений в сфере ILM — information life cycle management. Аналогичные решения есть и у HP, Sun, IBM. Масштабы приобретений говорят о том, что управление жизненным циклом наряду с защитой информации являются в настоящий момент главными парадигмами систем хранения данных. Защита информации На каждом этапе создания дата-центров наиболее важным вопросом является защита информации. Это большой и комплексный вопрос, поэтому здесь будут рассмотрены только основные уровни защиты, которые обеспечивают безопасность информации (за рамками будут оставлены вопросы физической безопасности и защиты ЦОД на уровне инженерной инфраструктуры, территориально-распределенное и катастрофоустойчивое резервирование). Сегодня во многих компаниях информационная инфраструктура организована так, каждый сервер работает со своими приложениями, и администраторам приходится держать в голове, как защищать от потери данных каждое из них. Например, «Oracle» копируется, архивируется и защищается по одной схеме, почтовые приложения — по другой, с сетевым хранением вообще зачастую никто не разбирается. Чтобы упорядочить этот процесс, надо создавать централизованные хранилища данных, чтобы потом ими можно было управлять и катастрофоустойчиво защищать. В первую очередь необходимо обеспечить защиту от аппаратных сбоев. Это достигается путем применения физического дублирования аппаратных платформ по схеме «n+1»- резервирование, когда в системе предусмотрены резервные платформы, готовые включиться в работу в случае аппаратного сбоя до его устранения. Второй уровень защиты — дублирование хранилищ данных по схеме «1+1». Третий уровень - физическое резервирование дисков, «n+1»- резервирование, т.е. в системе всегда есть +1 диск, готовый занять место вышедшего из строя на время его восстановления. Для сохранения данных на дисках применяются механизмы локального резервирования, репликации, отображения и т.д. Для защиты самой информации используются системы шифрования и криптографической защиты. Применяются уникальные алгоритмы хранения, по принципу «черного ящика», когда неизвестно, по какому алгоритму записывается информация в систему хранения и как она декодируется в случае обращения к ней. Пример ситуации: один из сотрудников компании вернулся из отпуска и отправил одинаковые письма с прикрепленным фото с юга 3-м друзьям, соответственно по 3-м адресам. Интеллектуальный алгоритм хранения позволяет системе идентифицировать изменяемую часть информации и неизменяемую часть. Неизменяемая часть информации хранится 1 раз, изменяемая — хранится отдельно по определенной схеме. В случае обращения к этой информации система по определенному алгоритму ее восстанавливает. Надежность систем хранения Чтобы определить требуемый уровень надежности системы, необходимо ответить на вопрос, сколько времени можно ждать полного восстановления данных и работы системы? Надежность системы хранения определяется совокупным временем не работы системы и рассчитывается по формуле: RPO + RTO = Т, где T — общее время не работы системы, RPO (recover point object) — время между произошедшим сбоем и последним копированием системы, RTO (recovery time object) — время, которое требуется на восстановление системы после сбоя Общее время неработоспособности системы
Пример ситуации: предположим, в 11:30 было произведено последнее резервное копирование системы, а в 12:00 произошел сбой и затем еще час, до 13:00, потребовался на восстановление работы системы, итого - 1 час 30 минут простоя системы. Таким образом, получается, что тех операций, которые были произведены в системе с 11:30 до 12:00, вообще не существует, т.е. информации о них в системе нет. Не надо обладать богатым воображением, чтобы представить, что такая ситуация может означать для банка, в котором ежесекундно совершаются операции, связанные с процессингом карт, переводом платежей и т.д. Современные катасторофоустойчивые схемы защиты позволяют создавать дата-центры, в которых RPO+RTO = 0 , т.е. на практике время не работы системы составляет миллисекунды, что снижает до 0 вероятность проведения любой транзакции в этот момент. Полная катастрофоустойчивость ЦОД подразумевает его территориальное резервирование на расстоянии 300 +1 км. Алексей Альмендингер |
При строительстве ЦОД, помимо наращивания вычислительных мощностей и емкости систем хранения данных, или построения инженерной инфраструктуры, необходимо обеспечить ряд мероприятий по иерархическому хранению данных, управлению жизненным циклом информации и ее защите. Эти мероприятия должны гарантировать надежность хранения информации и удобство работы с ней.
