Существует множество угроз, от которых современным организациям приходится оберегать свои данные. Чтобы предотвратить искажение или потерю данных вследствие вирусных атак или ошибок в ПО, необходимо обеспечить постоянную готовность резервной копии данных. Другая угроза, способная привести к потере данных, заключается в отказах оборудования. Сейчас большинство устройств резервируется, но существуют и другие технологии, позволяющие защититься от отказа компонента с сохранением доступности приложений, например, кластеризация.
 Рисунок 1. Первым шагом при выборе технологии послеаварийного восстановления должно стать определение допустимого уровня потери данных приложения и допустимого времени восстановления |
С повышением уровня защиты от логических угроз и отказов компонентов растет зависимость от защищаемых информационных систем. Многие компании поняли недостаточность локальной репликации для того, чтобы организация оставалась доступной. Доступ может прекращаться в результате запланированных событий (например, полное техническое обслуживание офиса) или внеплановых простоев, вызванных разными причинами — от прекращения подачи электроэнергии или отказа системы кондиционирования воздуха до природных катастроф (пожар, наводнение, террористические акты, военные действия). Потеря всего оборудования вычислительного центра подорвет работоспособность организации, поэтому наиболее эффективным методом считается защита на уровне вычислительного центра.
Многие компании для защиты от полной потери оборудования реализовали планы послеаварийного восстановления (disaster recovery, DR), которые, как правило, включают шаги по восстановлению линий связи, обеспечению выполнения критически важных функций, а также по восстановлению данных и бизнес-приложений на удаленной территории. Одна из проблем, общих для многих планов DR, заключается в обеспечении наличия информации для реализации плана послеаварийного восстановления. Многие годы компании регулярно выполняли процедуры резервного копирования в главном вычислительном центре, а затем дублировали эти ленты и перевозили копии на удаленную территорию в целях послеаварийного восстановления. Хотя решение резервного копирования на основе магнитной ленты является необходимой мерой безопасности для планирования послеаварийного восстановления, в самой ИТ-среде тоже необходимо обеспечить более высокий уровень защиты критически важных данных. Подход к созданию резервных магнитных лент может отвечать требованиям защиты большинства данных в организации, но существует множество типов данных, для которых уровень потери данных, характерный для подхода резервного копирования на магнитную ленту, недопустим.
Чтобы сделать первый шаг к пониманию того, какие технологии защиты требуются для тех или иных типов данных, нужно определить, в какое время и в каких случаях необходимы определенные технологии. Основными критериями сравнения технологий послеаварийного восстановления служат допустимый уровень потери данных и допустимое время восстановления.
Полный план послеаварийного восстановления обеспечивается не одной технологией или службой, а представляет собой последовательность шагов, реализуемых с целью гарантировать допустимый уровень потери данных (recovery point objective, RPO) и допустимое время восстановления (recovery time objective, RTO) для каждого приложения и каждой бизнес-функции. Допустимый уровень потери данных — это момент времени, на который должны быть восстановлены данные для продолжения деловых операций. Чтобы гарантировать доступность приложения, при анализе решения послеаварийного восстановления нужно рассмотреть многие компоненты.
На рис. 1 показаны технологии, отражающие требования заказчиков по RPO и RTO. Взрыв в середине изображает катастрофу. Слева от взрыва приводятся допустимый уровень потери данных и соответствующая программная технология восстановления, которая зависит от бизнес-требований. Например, если бизнес-приложение допускает потерю данных за день или больше, то для него вполне достаточно резервного копирования на магнитную ленту. Однако если потеря данных за день или более приведет к существенным последствиям для бизнеса, в ИТ-среду должны быть встроены технологии репликации для защиты от существенной потери данных. Справа от взрыва указано допустимое время восстановления. Если предприятие может позволить себе отвести на восстановление нормальной работы день или два, то его требования будут удовлетворены восстановлением данных с ленты вручную. Для улучшения показателя RTO организация может использовать технологии восстановления с нуля, чтобы существенно уменьшить время, необходимое для ввода сервера в эксплуатацию. Однако если и эти технологии не отвечают требуемому RTO, в ИТ-среде следует реализовать кластерные технологии для защиты от существенных простоев.
Когда необходима репликация
Репликация — технология, предназначенная для сохранения копии данных в полностью независимой системе хранения данных, которая расположена на территориально удаленном объекте. От методов резервного копирования и восстановления с магнитной ленты репликация отличается тем, что осуществляется автоматически и со значительно меньшими трудозатратами. К тому же технологии репликации могут использоваться для уменьшения допустимого уровня потери данных в критически важных приложениях.
Независимо от того, чем вызвано применение технологий репликации — катастрофой, аварией или плановым перемещением офиса, они позволяют распределять данные, делая их беспрепятственно доступными на каждом объекте. Система Veritas Storage Foundation by Symantec обеспечивает возможность дистанционного зеркального отображения данных через Fibre Channel. Для организаций, желающих реплицировать свои данные по стандартной IP-сети, без преобразования протокола, в Veritas Storage Foundation существует дополнительная опция Veritas Volume Replicator, позволяющая надежно, эффективно и согласованно реплицировать данные на удаленные устройства хранения. Технология репликации Symantec представляет собой решение послеаварийного восстановления, не зависящее от системы хранения данных и предназначенное для недопущения потери данных и продолжительных простоев.
Режимы репликации
Существуют два основных типа репликации: синхронная и асинхронная. Оба имеют свои преимущества и недостатки, и каждый тип предоставляет системному администратору определенные возможности.
Они используют разные процессы для достижения одной и той же цели и по-разному учитывают состояние сети. Производительность и эффективность обоих методов зависит в конечном итоге от бизнес-требований, одним из которых является время отражения обновлений данных на удаленном объекте. Производительность жестко определяется доступной полосой пропускания, временем задержки сети, числом участвующих серверов, количеством реплицируемых данных и географическим расстоянием между объектами.
Синхронная репликация
При синхронной репликации операция записи считается завершенной на уровне приложения только после того, как обновленная запись поступит на главный и на резервный объект (или объекты). Таким образом, в случае аварии на главном объекте данные, восстановленные на резервном объекте, будут точной копией данных главного объекта. Синхронная репликация обеспечивает точное соответствие между данными на главном и резервном объектах, так что RPO для приложений, использующих синхронную репликацию, оказывается нулевым. Однако ввиду того, что прежде чем приложение сможет начать следующую операцию, текущая операция должна быть передана на удаленный объект и возвратиться на главный объект — такая репликация влияет на производительность приложения. Эффективнее всего синхронная репликация работает в городских сетях с приложениями, не допускающими потери данных, но выдерживающими определенное влияние на производительность.
Существует множество сценариев, которые позволяют управлять производительностью приложения в синхронном режиме. В их числе — ограничение процедур записи в системе, организация сетевого конвейера, соединяющего главный объект с резервными, а также выбор расстояния между двумя объектами. Золотое правило: задержка не должна превышать 3 мс на каждые 100 миль (161 км) расстояния между главной и резервной системами. Большинство конфигураций, в которых используется синхронная репликация, настроено на переход в асинхронный режим в случае потери связи между главным и резервным объектами. Это предотвращает зависимость основного приложения от работы сети.
Асинхронная репликация
Асинхронная репликация исключает потенциальные проблемы производительности, характерные для методов синхронной репликации. Резервный объект может отставать от основного, как правило, всего лишь менее чем на одну минуту, что, по существу, обеспечивает репликацию в режиме реального времени без влияния на производительность приложения. При асинхронной репликации обновление данных приложения записывается в главной системе и ставится в очередь на передачу в каждый из резервных объектов в соответствии с пропускной способностью сети. В отличие от синхронной репликации, запись данных приложения не страдает от влияния репликации на производительность приложения и для пользователя протекает так, будто ничего не происходит. Асинхронная репликация эффективна в тех организациях, которые могут допустить минимальную потерю данных, но хотят исключить влияние на производительность приложения, или в организациях, в которых данные репликации передаются по территориально распределенной сети. Этот выбор может быть правильным и тогда, когда полоса пропускания сети, соединяющей два объекта, достаточно велика, чтобы справиться со средним объемом данных, но недостаточна для пиковых нагрузок при записи данных.
Согласованность данных
Какой бы режим репликации не применялся, необходимо гарантировать невозможность повреждения или рассогласования данных на резервном объекте. Самое неприятное — получить невосстанавливаемые данные репликации на резервном объекте в тот момент, когда они больше всего нужны. Единственный способ гарантировать восстанавливаемость данных на резервном объекте — обеспечить поступление данных в той же последовательности, в какой они записываются на основной территории (правильный порядок записи). Без него невозможно гарантировать, что на резервном объекте будут присутствовать согласованные восстанавливаемые данные. В среде базы данных все изменения вносятся в определенном порядке в журнал регистрации событий и в пространство данных СУБД. Журнал и пространство данных обычно находятся в разных томах, а сами данные могут быть разбросаны еще по нескольким томам. Хорошо спроектированное решение репликации должно в точности сохранять правильный порядок записи. Этого можно добиться логическим группированием томов данных таким образом, чтобы порядок обновлений в этой группе сохранялся для всех резервных копий томов.
Решениям репликации, работающим на уровне оборудования, обычно недостает способности сохранять правильный порядок записи при работе в асинхронном режиме. Это вызвано отсутствием постоянной очереди записей, еще не переданных в резервную систему. В случае, если применяется аппаратная репликация и необходимо избежать влияния синхронной репликации на производительность, теряется восстанавливаемость данных на удаленном объекте, что делает удаленную копию практически бесполезной. По этой причине сохранение правильного порядка записи при использовании технологий репликации должно быть обязательным требованием, гарантирующим восстанавливаемость данных на удаленном объекте.
Технические особенности репликации
С архитектурной точки зрения полное решение репликации должно обеспечивать копию всех данных на основной и резервной территориях, включая файлы базы данных и любые другие двоичные и управляющие файлы. Технология репликации должна гарантировать также точность и восстанавливаемость данных.
Решение репликации должно допускать конфигурирование для поддержки резервной системы на любом расстоянии. Организации должны иметь возможность использовать существующую инфраструктуру, включая действующие вычислительные центры, независимо от расстояния. Решение репликации должно работать на любом расстоянии, когда вычислительные центры разнесены на несколько (или на тысячи) километров, не добавляя лишних расходов или сложностей. Это означает, что технология репликации должна обеспечивать асинхронную поддержку на дальнее расстояние без дополнительных дорогостоящих устройств (преобразователей протоколов связи или дополнительных дисков для многоуровневого хранения данных). Решение репликации должно быть достаточно гибким, чтобы допускать изменение конфигурации реплицируемых наборов данных. Некоторые тома могут не реплицироваться, так как в них хранятся временные файлы или файлы, которые после аварии не понадобятся. Для подтверждения восстанавливаемости резервных данных должна быть предусмотрена возможность тестирования удаленной системы.
Дистанционное зеркальное отображение и репликация
Технологии репликации и зеркального отображения могут существенно ускорить восстановление и исключить потерю данных, делая текущие данные немедленно доступными на удаленной территории. Чтобы удовлетворять свои требования по послеаварийному восстановлению данных, организации могут реплицировать или зеркально отображать данные по территориально распределенной сети или по IP-сети. В отличие от фирменного (негибкого) аппаратного подхода, технологии репликации и зеркального отображения Symantec не зависят от какой-либо конкретной аппаратной платформы хранения данных. Например, репликация может осуществляться между дисковыми массивами от разных поставщиков. Единственное требование заключается в том, чтобы размеры томов с той и с другой стороны совпадали.
