Современные системы хранения данных. Часть 3 - ПО для создания мгновенных и полных копий данных.

 

Следующее по популярности решение – ПО для создания мгновенных и полных копий данных. Различные производители по-разному называют свои программные продукты и механизмы создания этих копий. Мы для обобщения можем манипулировать словами снапшот (snapshot) и клон (clone). К примеру, для уже упоминавшихся систем хранения EMC программное обеспечение для создания клонов и снапшотов называется EMC SnapView.

Создание копий с помощью EMC SnapView (web-интерфейс)

Клон делается средствами дисковой стойки внутри самой стойки – это полная внутренняя копия данных. Сфера применения довольно широка – от бэкапа (backup) до создания «тестовой версии» исходных данных, к примеру, для рискованных модернизаций, в которых нет уверенности и применять которые на актуальных данных небезопасно. Тот, кто внимательно следил за всеми прелестями СХД, которые мы тут разбирали, спросит – для чего же нужен бэкап данных внутри стойки, если она обладает такой высокой надёжностью? Ответ на этот вопрос на поверхности – никто не застрахован от человеческих ошибок. Данные сохранены надёжно, но если сам оператор сделал что-то не так, к примеру, удалил нужную таблицу в базе данных, от этого не спасут никакие аппаратные ухищрения. Клонирование данных обычно выполняется на уровне LUN. Более интересная функциональность обеспечивается механизмом снапшотов. В какой-то мере мы получаем все прелести полной внутренней копии данных (клона), при этом не занимая 100% объёма копируемых данных внутри самой стойки, ведь такой объём нам не всегда доступен. По сути снапшот – мгновенный «снимок» данных, который не занимает времени и процессорных ресурсов СХД. Объём же дискового пространства для хранения снапшота определяется объёмом модернизированных данных, которые появились с момента создания снапшота. К примеру, если в 8 часов утра мы создали снапшот с LUN объёмом 1Tбайт, при этом к 18 часам вечера в исходных данных поменялось 20% информации, наш снапшот станет занимать 200 Гбайт, что, конечно же, значительно меньший объём, чем при создании клона. Оба механизма (снапшот и клон) позволяют восстановить исходные данные, т.е. сделать rollback. Если, к примеру, обнаружилось, что после создания нашего снапшота в 12.30 система дала сбой и все вновь накапливаемые данные оказались повреждены, нам ничего не стоит сделать rollback с нашего снапшота, и все данные на исходном LUN будут возвращены в состояние на момент точки создания снапшота – то есть на момент 8 часов утра. При этом корректные данные, которые были накоплены с 8 утра до 12.30, будут потеряны. Если же делать снапшот каждый час рабочего дня, мы сможем «откатить» назад изменения до нужного момента, то есть мы бы могли откатиться до точки создания снапшота в 12.00 – тогда бы мы потеряли данные только за промежуток 12.00-12.30, то есть за полчаса.

Rollback: восстановление состояния LUN

На самом деле вышеприведённые механизмы очень гибкие, они позволяют манипулировать данными с широкими возможностями. Клон и снапшот имеют как свои достоинства, так и недостатки – углубляться в этот вопрос мы не будем, однако я упомяну самый популярный механизм использования снапшотов – вопрос создания резервных копий. К примеру, если нам необходимо стандартными средствами создать бакап базы данных (БД), мы проделываем следующие действия – останавливаем БД, после чего запускаем сам механизм создания резервных копий, к примеру, на стримерную ленту. Это может занять много часов, в этот момент с базой работать нельзя. Часто такой механизм неприемлем, система не должна так долго простаивать. В этом случае очень просто обходиться созданием снапшотов, если БД хранится на СХД – база останавливается, с неё делается мгновенный снимок (снапшот), после чего работа с базой возобновляется. При автоматизации такой процесс может занимать всего лишь минуты. Полученный на системе хранения снапшот может быть подключён к любому серверу, который и будет осуществлять резервное копирование базы на ленту сколь угодно долго – при этом основная БД будет находиться в рабочем состоянии. Однако тут следует учесть следующее – хотя логически исходная БД и снапшот – это два разных LUN (подключённых к двум или более серверам), физически все те данные, которые не успели измениться в исходном LUN с момента создания снапшота, так и находятся на исходном LUN, и доступ к ним уже будут осуществлять не только серверы СУБД, но и сервер, осуществляющий backup – что может в какой-то мере снизить производительность.

Конечно нельзя не упомянуть ПО для репликации (replication) данных, которое часто называют зеркалированием (mirroring). Это механизм синхронного или асинхронного реплицирования (дублирования) информации с одной системы хранения на одну или несколько удалённых систем хранения. Репликация возможна по различных каналам – к примеру, стойки с интерфейсами FibreChannel могут асинхронно, через Интернет и на большие расстояния, реплицироваться на другую СХД. Такое решение обеспечивает надёжность хранения информации и защиту от катастроф. Все мы помним 11 сентября в США, когда были полностью разрушены два здания Всемирной Торговой Организации (WTC) – при этом были безвозвратно утеряны огромные объёмы данных. Реплицирование на удалённые площадки, создание резервных ВЦ позволяет избежать потери данных при катастрофах, они ведь не так редки, как кажется – обычный пожар может уничтожить все данные в любой самой совершенной системе хранения. Ну конечно, не стоит забывать и про обычное резервное копирование, даже реплицирование – не панацея от всех бед.

Кроме всех перечисленных механизмов, существует большое число других возможностей манипуляций данными, которые зачастую невозможно осуществить вне дисковой стойки. К примеру, миграция данных с одной LUN на другой без остановки системы и без прерывания работы. Например, администратора перестала устраивать скорость работы LUN, находящегося на RAID уровня 5, и он решил переместить все данные на RAID 10, состоящий из большего числа дисков. Задача в обычных условиях нетривиальная, однако некоторое оборудование позволяет осуществить такую операцию незаметно для хостов – постепенно, с заданным приоритетом, данные внутри системы хранения копируются (мигрируют) с одного LUN на другой (с RAID5 на RAID10), после полной синхронизации и незаметно для пользователей сама система переключает все хосты, работающие с первым LUN на второй, то есть самостоятельно производит нужную переконфигурацию системы. Администратору остаётся только перераспределить место, занимаемое первым LUN – теперь он неактуален. Также хочется упомянуть о возможности динамического изменения размера LUN без остановки системы – тут уже всё упирается в операционную систему хост-машины, которая должна правильно отработать такое событие.

Кратко хочется упомянуть о средствах коммутации в среде FibreChannel – о коммутаторах (switches). Основные игроки на этом рынке Cisco, McData, Brocade, QLogic. Практически все коммутаторы, поставляемые крупнейшими производителями СХД под своей торговой маркой – это OEM от Cisco, McData или Brocade.

Коммутаторы Cisco для SAN

Коммутаторы, обладающие большим числом портов, внутренним резервированием управляющих модулей и шин, часто называют «директор» (director). Обычно надёжность директоров составляет т.н. «пять девяток» – 99,999%, они предназначены для работы в качестве ядра (core) сетевой инфраструктуры FibreChannel (или FICON, к примеру) и зачастую строятся по модульному принципу, позволяя создавать нужные конфигурации портов с требуемыми возможностями. К примеру, это может быть большое количество неблокируемых портов, когда все порты могут одновременно функционировать на полной заявленной скорости – в данный момент это 2 Gb и полным ходом идем переход на 4 Gb, таких устройств уже немало. Скорости выше, вплоть до 10 Gb, используются обычно для организации связей между самими коммутаторами (ISL). Коммутаторы для сетей SAN обладают широкими возможностями, позволяя выстраивать подключение устройств по разным схемам, без изменения физической топологии. Управление осуществляется, как и у СХД – web-интерфейс, командная строка, также широки возможности оповещения о критических событиях. Некоторые устройства позволяют обновлять внутреннее программное обеспечение (firmware) без остановки работы, что также немаловажно – например, фирменная технология HotCAT от McData. Одна из основных функций коммутаторов – организация зонного разделения устройств SAN, так называемый zoning (зонирование). Зонирование позволяет создавать зоны, которые ограничивают возможность взаимодействия FC-устройств в SAN – ведь абсолютно не нужно (за редким исключением), чтобы два сервера сети «видели» друг друга – это некорректно с точки зрения безопасности и излишне нагружает сеть. Коммутаторы в единой фабрике функционируют как единое целое, позволяя также управлять безопасностью сети – возможно ограничивать подключение новых устройств в конкретный коммутатор или в фабрику в целом, а также ограничивать подключение неавторизованных устройств в активные порты (контролируется по WWN) и так далее. Коммутатор сетей SAN – это сложное и недешёвое устройство, которое требует конфигурирования специалистом и является ядром коммутации всей сети, при нарушении конфигурации вся работа может в мгновение остановиться. Чтобы избежать таких проблем и повысить надежность, в SAN используют несколько коммутаторов в различных фабриках (что будет рассмотрено ниже).

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