Подождите, подождите. Я же не написал в заголовке «Как обойтись без резервного копирования». Обойтись без резервного копирования нельзя, об этом знает любой первокурсник. А вот навсегда забыть о резервном копировании — это, пожалуй, мечта любого ИТ-менеджера. Но мечта эта до сих пор казалась несбыточной. Потому что даже если на вашем предприятии прекрасно налажено резервное копирование, вы вспомните о нем сразу после большого отказа, и далеко не добрым словом. Вы скажете не что-нибудь вроде «Как же здорово, что у нас каждую ночь работает бэкап», а скорее: «Сколько часов прошло после бэкапа?»
Давайте разберемся, в чем заключаются ключевые цели резервного копирования баз данных, и почему ни одно из существовавших до сих пор решений этим целям не удовлетворяло.
Бизнес требует, чтобы системы никогда не теряли критичных для бизнеса данных, и чтобы при этом резервирование не влияло на работу бизнес приложений. Соответственно, решения должны гарантировать восстановление баз данных после сбоев.
Но резервное копирование базы данных требует особого подхода, недостаточно рассматривать базу данных, как набор файлов. И в этом заключается проблема традиционных решений для резервного копирования баз данных — они не удовлетворяют потребностям в защите критически важных данных, поскольку они рассматривают базу данных как набор файлов, которые нужно копировать, а не как с транзакционную систему со специфическими требованиями к целостности данных, производительности и доступности. Просто скопировать файлы базы данных недостаточно, потому что это не гарантирует целостности базы данных. После восстановления из такой копии база может просто не открыться для пользователей.
К тому же традиционный подход не позволяет резервировать данные в реальном времени, чтобы оно не влияло на производительность системы. Надо находить временные «окна» для резервного копирования — куда ни шло в странах, живущих в одном-двух часовых поясах, но это, сами понимаете, не про нас. При этом мало того, что объем баз данных растет, как на стероидах, так еще и количество баз неудержимо умножаются. И как, спрашивается, с таким количеством систем создать единую политику резервирования? А масштабирование самой системы резервирования в таких условиях и вовсе становится адом.
Итак, мы разобрались, «кто виноват». Имеем три основные проблемы — риск потери данных при резервном копировании баз данных в виде файлов, снижение производительности информационной системы предприятия из-за выполнения резервного копирования, трудность создания централизованной службы резервного копирования из-за большого количества корпоративных баз данных. Переходим к вопросу «что делать».
Компания Oracle решила этот вопрос просто и естественно. Во-первых, чтобы не терять данные и минимизировать влияние на производительность, надо ее рассматривать, как транзакционную, а не файловую, систему, и резервировать журналы транзакций. Во-вторых, чтобы обеспечить масштабируемость, сервис резервного копирования должен обеспечиваться программно-аппаратным комплексом — appliance. Полученное решение, которое обеспечивает резервирование без потери данных, называется Oracle Zero Data Loss Recovery Appliance.
Recovery Appliance защищает все базы данных Oracle вашего ЦОДа, поддерживая все редакции, все версии Oracle Database от 10.2 до 12.2 на любых платформах. Чтобы обеспечить надежное восстановление баз данных, Recovery Appliance постоянно проверяет целостность данных. Сжатием данных тоже занимается Recovery Appliance, и резервное копирование на ленты, если оно практикуется в вашей организации, также будет выполнять Recovery Appliance, высвобождая ваши промышленные серверы для основной работы. Все, что нужно, чтобы подключить сервер базы данных к Recovery Appliance — установить на него утилиту резервного копирования и восстановление данных, которая называется Recovery Manager (RMAN). Никакое дополнительное программное обеспечение, ответственное за резервное копирование данных, на стороне сервера работать не будет.
На Recovery Appliance хранится также Recovery Catalog — это информация обо всех выполненных резервных копиях, она нужна для процедур инкрементального резервного копирования и восстановления данных. После того, как выполнено полное резервное копирование, процесс DeltaPush передает в Recovery Appliance только изменения баз данных, что означает минимальное влияние на продуктивность рабочих серверов (рис. 1). В промежутках между инкрементами резервируются журналы транзакций.
Понятно? Recovery Appliance всегда хранит самые последние версии баз данных, при этом минимизируется объем передаваемой информации из базы данных в систему резервного копирования. Все проверенные и сжатые изменения базы находятся на Recovery Appliance в специальном хранилище, которое называется Delta Store. С помощью Delta Store Recovery Appliance может быстро воссоздать полную копию БД на любой момент времени, быстро сложив все «дельты». Управляется все это через Enterprise Manager.
Кроме этого, Recovery Appliance может автономно, в асинхронном режиме, копировать данные на ленту и на резервный ЦОД. Нагружать рабочие серверы базы данных не нужно, данные копируются с Recovery Appliance (рис. 2). Восстановить базу данных RMAN можно как с Recovery Appliance в основном или в резервном ЦОД, а также и напрямую с ленточной библиотеки.
Архитектура, благодаря которой достигается беспрецедентно высокая скорость резервного копирования, называется Delta-Only. RMAN никогда выполняет резервную копию дубликатов блоков, блоков «Undo» для завершенных транзакций или неиспользованных блоков. В Delta Store хранятся только изменения, реплицируются тоже только изменения, данные сжимаются на уровне блока.
Мой любимый новый термин, который появился благодаря Recovery Appliance — «виртуальная полная копия БД». Если вы внимательно читали начало статьи, вы про него уже все поняли — сначала один только раз делается полная резервная копия, а затем благодаря инкрементальным копиям Recovery Appliance может на лету воссоздать «виртуальную полную копия БД». При этом благодаря сохранению журналов транзакций от базы данных непосредственно в реальном масштабе времени обеспечивается нулевая потеря данных (рис. 3).
И это не то же самое, что сумма полной копии со всеми инкрементальными, кумулятивными и дифференциальными при использовании традиционных систем. Полная виртуальная копия объединяет блоки полной копии бэкапа с инкрементальными копиями, т.е. просто содержит ссылки на нужные версии блоков. В результата она равноценна полной резервной копии. Экономия дискового пространства и времени — сами понимаете, какая. Полная виртуальная копия и журнал транзакций с момента последнего инкрементального резервирования составляют необходимый и достаточный набор для быстрого восстановления базы данных на любой момент времени. Больше вам никогда не придется делать полную резервную копию, в этом просто нет смысла.
Собственно процесс восстановления файловой базы данных называется «restore», а процедура отражения в ней последних изменений из журнала транзакций — «recovery». А поскольку журналы транзакций накапливаются в промежутках между всеми сессиями инкрементального копирования, можно быстро восстановить базу данных по состоянию на любой момент времени в прошлом. И для этого не нужно, как раньше, выполнять слияние полной и инкрементальных копий, задействуя рабочие серверы — виртуальная резервная копия содержит ссылки на все блоки, необходимые блоки просто извлекаются из Delta Store.
Настраивается Recovery Appliance, согласно всем правилам хорошего тона, посредством политик. Политики определяют, сколько дней нужно хранить резервные копии на диске, сколько дней — на ленте, сколько дней — на резервном ЦОДе. Политик может быть несколько — например, для некритичных, критичных и самых критичных баз данных. Набор политик стандартизирует весь регламент резервного копирования на предприятии (рис. 4). Благодаря этому управлять регламентом резервного копирования становится очень легко — например, если вдруг окажется, что резервные копии финансовых данных нужно хранить не месяц, а год, вы просто назначите для соответствующей политики значение 365 дней вместо 30 — и все базы, которые управляются этой политикой, будут иметь новый регламент резервного копирования, что очень удобно. Recovery Appliance будет вести статистику загрузки дисковой подсистемы и прогнозировать, на какой срок ее хватит.
Политики резервного копирования также определяют, для каких данных нужно создавать реплики в резервном ЦОДе, причем для организаций, у которых есть несколько ЦОДов, на каждом из которых хранятся активные базы данных, реплики могут быть двунаправленными (рис. 5).
Для организаций с разветвленной структурой настраивается схема консолидации — Recovery Appliance в каждом филиале отправляет данные в Recovery Appliance в главном ЦОДе (рис. 6). Причем восстановление базы данных можно произвести как с главного, так и с резервного Recovery Appliance — это может потребоваться, если вышел из строя один из локальных ЦОДов.
Очень важно, что управление процессом резервного копирования Recovery Appliance, всеми базами данных, всеми репликами и копиями на ленту выполняется через единый интерфейс Enterprise Manager. Все копии регистрируются в Recovery Catalog, и администратор базы видит все способы, какими он может восстановить базу данных.
Базовая комплектация Zero Data Loss Recovery Appliance называется Base Rack и состоит из двух серверов, выполняющих резервное копирование (в каждом — по пять портов 10Gb Ethernet, по два порта 40Gb InfiniBand и опционально по два порта 16Gb Fibre Channel для подключения ленточной библиотеки), и трех серверов хранения, на которых хранятся резервные копии (в каждом — по двенадцать 4 ТБ-дисков со скоростью вращения 7200 оборотов в минуту). Объем дискового хранения, с учетом зеркального резервирования блоков, составляет 42 ТБ. Расширять дисковое хранилище можно до 18 серверов хранения, такая версия называется Full Rack, или, говоря по-русски, полный серверный шкаф, объем хранения которого составляет 320 ТБ, а скорость резервирования — 12 ТБ/час. Этого достаточно, полагаю, для резервного копирования любой базы данных, а для резервирования большого количества баз данных внутри ЦОДа этот аппаратный комплекс можно масштабировать до Full Rack, или даже до 18 Full Rack 18 таких шкафов со скоростью резервирования 216 ТБ/час.
Работает система под управлением ПО Zero Data Loss Recovery Appliance Software, которое лицензируется на каждый диск серверов хранения. Все прочее программное обеспечение, включая Oracle Secure Backup, Oracle Database, Oracle Partitioning и т.д. — в отличие, скажем, от решения с использованием Oracle Data Guard — вы получаете внутри Recovery Appliance бесплатно.
Крайне рекомендую почитать материалы по ссылкам www.oracle.com/recoveryappliance, www.oracle.com/goto/ha и www.oracle.com/goto/maa.
И обязательно записывайтесь на наши онлайн-тренинги.
Давайте разберемся, в чем заключаются ключевые цели резервного копирования баз данных, и почему ни одно из существовавших до сих пор решений этим целям не удовлетворяло.
Бизнес требует, чтобы системы никогда не теряли критичных для бизнеса данных, и чтобы при этом резервирование не влияло на работу бизнес приложений. Соответственно, решения должны гарантировать восстановление баз данных после сбоев.
Но резервное копирование базы данных требует особого подхода, недостаточно рассматривать базу данных, как набор файлов. И в этом заключается проблема традиционных решений для резервного копирования баз данных — они не удовлетворяют потребностям в защите критически важных данных, поскольку они рассматривают базу данных как набор файлов, которые нужно копировать, а не как с транзакционную систему со специфическими требованиями к целостности данных, производительности и доступности. Просто скопировать файлы базы данных недостаточно, потому что это не гарантирует целостности базы данных. После восстановления из такой копии база может просто не открыться для пользователей.
К тому же традиционный подход не позволяет резервировать данные в реальном времени, чтобы оно не влияло на производительность системы. Надо находить временные «окна» для резервного копирования — куда ни шло в странах, живущих в одном-двух часовых поясах, но это, сами понимаете, не про нас. При этом мало того, что объем баз данных растет, как на стероидах, так еще и количество баз неудержимо умножаются. И как, спрашивается, с таким количеством систем создать единую политику резервирования? А масштабирование самой системы резервирования в таких условиях и вовсе становится адом.
Итак, мы разобрались, «кто виноват». Имеем три основные проблемы — риск потери данных при резервном копировании баз данных в виде файлов, снижение производительности информационной системы предприятия из-за выполнения резервного копирования, трудность создания централизованной службы резервного копирования из-за большого количества корпоративных баз данных. Переходим к вопросу «что делать».
Компания Oracle решила этот вопрос просто и естественно. Во-первых, чтобы не терять данные и минимизировать влияние на производительность, надо ее рассматривать, как транзакционную, а не файловую, систему, и резервировать журналы транзакций. Во-вторых, чтобы обеспечить масштабируемость, сервис резервного копирования должен обеспечиваться программно-аппаратным комплексом — appliance. Полученное решение, которое обеспечивает резервирование без потери данных, называется Oracle Zero Data Loss Recovery Appliance.
Recovery Appliance защищает все базы данных Oracle вашего ЦОДа, поддерживая все редакции, все версии Oracle Database от 10.2 до 12.2 на любых платформах. Чтобы обеспечить надежное восстановление баз данных, Recovery Appliance постоянно проверяет целостность данных. Сжатием данных тоже занимается Recovery Appliance, и резервное копирование на ленты, если оно практикуется в вашей организации, также будет выполнять Recovery Appliance, высвобождая ваши промышленные серверы для основной работы. Все, что нужно, чтобы подключить сервер базы данных к Recovery Appliance — установить на него утилиту резервного копирования и восстановление данных, которая называется Recovery Manager (RMAN). Никакое дополнительное программное обеспечение, ответственное за резервное копирование данных, на стороне сервера работать не будет.
На Recovery Appliance хранится также Recovery Catalog — это информация обо всех выполненных резервных копиях, она нужна для процедур инкрементального резервного копирования и восстановления данных. После того, как выполнено полное резервное копирование, процесс DeltaPush передает в Recovery Appliance только изменения баз данных, что означает минимальное влияние на продуктивность рабочих серверов (рис. 1). В промежутках между инкрементами резервируются журналы транзакций.
Понятно? Recovery Appliance всегда хранит самые последние версии баз данных, при этом минимизируется объем передаваемой информации из базы данных в систему резервного копирования. Все проверенные и сжатые изменения базы находятся на Recovery Appliance в специальном хранилище, которое называется Delta Store. С помощью Delta Store Recovery Appliance может быстро воссоздать полную копию БД на любой момент времени, быстро сложив все «дельты». Управляется все это через Enterprise Manager.
Кроме этого, Recovery Appliance может автономно, в асинхронном режиме, копировать данные на ленту и на резервный ЦОД. Нагружать рабочие серверы базы данных не нужно, данные копируются с Recovery Appliance (рис. 2). Восстановить базу данных RMAN можно как с Recovery Appliance в основном или в резервном ЦОД, а также и напрямую с ленточной библиотеки.
Архитектура, благодаря которой достигается беспрецедентно высокая скорость резервного копирования, называется Delta-Only. RMAN никогда выполняет резервную копию дубликатов блоков, блоков «Undo» для завершенных транзакций или неиспользованных блоков. В Delta Store хранятся только изменения, реплицируются тоже только изменения, данные сжимаются на уровне блока.
Мой любимый новый термин, который появился благодаря Recovery Appliance — «виртуальная полная копия БД». Если вы внимательно читали начало статьи, вы про него уже все поняли — сначала один только раз делается полная резервная копия, а затем благодаря инкрементальным копиям Recovery Appliance может на лету воссоздать «виртуальную полную копия БД». При этом благодаря сохранению журналов транзакций от базы данных непосредственно в реальном масштабе времени обеспечивается нулевая потеря данных (рис. 3).
И это не то же самое, что сумма полной копии со всеми инкрементальными, кумулятивными и дифференциальными при использовании традиционных систем. Полная виртуальная копия объединяет блоки полной копии бэкапа с инкрементальными копиями, т.е. просто содержит ссылки на нужные версии блоков. В результата она равноценна полной резервной копии. Экономия дискового пространства и времени — сами понимаете, какая. Полная виртуальная копия и журнал транзакций с момента последнего инкрементального резервирования составляют необходимый и достаточный набор для быстрого восстановления базы данных на любой момент времени. Больше вам никогда не придется делать полную резервную копию, в этом просто нет смысла.
Собственно процесс восстановления файловой базы данных называется «restore», а процедура отражения в ней последних изменений из журнала транзакций — «recovery». А поскольку журналы транзакций накапливаются в промежутках между всеми сессиями инкрементального копирования, можно быстро восстановить базу данных по состоянию на любой момент времени в прошлом. И для этого не нужно, как раньше, выполнять слияние полной и инкрементальных копий, задействуя рабочие серверы — виртуальная резервная копия содержит ссылки на все блоки, необходимые блоки просто извлекаются из Delta Store.
Настраивается Recovery Appliance, согласно всем правилам хорошего тона, посредством политик. Политики определяют, сколько дней нужно хранить резервные копии на диске, сколько дней — на ленте, сколько дней — на резервном ЦОДе. Политик может быть несколько — например, для некритичных, критичных и самых критичных баз данных. Набор политик стандартизирует весь регламент резервного копирования на предприятии (рис. 4). Благодаря этому управлять регламентом резервного копирования становится очень легко — например, если вдруг окажется, что резервные копии финансовых данных нужно хранить не месяц, а год, вы просто назначите для соответствующей политики значение 365 дней вместо 30 — и все базы, которые управляются этой политикой, будут иметь новый регламент резервного копирования, что очень удобно. Recovery Appliance будет вести статистику загрузки дисковой подсистемы и прогнозировать, на какой срок ее хватит.
Политики резервного копирования также определяют, для каких данных нужно создавать реплики в резервном ЦОДе, причем для организаций, у которых есть несколько ЦОДов, на каждом из которых хранятся активные базы данных, реплики могут быть двунаправленными (рис. 5).
Для организаций с разветвленной структурой настраивается схема консолидации — Recovery Appliance в каждом филиале отправляет данные в Recovery Appliance в главном ЦОДе (рис. 6). Причем восстановление базы данных можно произвести как с главного, так и с резервного Recovery Appliance — это может потребоваться, если вышел из строя один из локальных ЦОДов.
Очень важно, что управление процессом резервного копирования Recovery Appliance, всеми базами данных, всеми репликами и копиями на ленту выполняется через единый интерфейс Enterprise Manager. Все копии регистрируются в Recovery Catalog, и администратор базы видит все способы, какими он может восстановить базу данных.
Базовая комплектация Zero Data Loss Recovery Appliance называется Base Rack и состоит из двух серверов, выполняющих резервное копирование (в каждом — по пять портов 10Gb Ethernet, по два порта 40Gb InfiniBand и опционально по два порта 16Gb Fibre Channel для подключения ленточной библиотеки), и трех серверов хранения, на которых хранятся резервные копии (в каждом — по двенадцать 4 ТБ-дисков со скоростью вращения 7200 оборотов в минуту). Объем дискового хранения, с учетом зеркального резервирования блоков, составляет 42 ТБ. Расширять дисковое хранилище можно до 18 серверов хранения, такая версия называется Full Rack, или, говоря по-русски, полный серверный шкаф, объем хранения которого составляет 320 ТБ, а скорость резервирования — 12 ТБ/час. Этого достаточно, полагаю, для резервного копирования любой базы данных, а для резервирования большого количества баз данных внутри ЦОДа этот аппаратный комплекс можно масштабировать до Full Rack, или даже до 18 Full Rack 18 таких шкафов со скоростью резервирования 216 ТБ/час.
Работает система под управлением ПО Zero Data Loss Recovery Appliance Software, которое лицензируется на каждый диск серверов хранения. Все прочее программное обеспечение, включая Oracle Secure Backup, Oracle Database, Oracle Partitioning и т.д. — в отличие, скажем, от решения с использованием Oracle Data Guard — вы получаете внутри Recovery Appliance бесплатно.
Крайне рекомендую почитать материалы по ссылкам www.oracle.com/recoveryappliance, www.oracle.com/goto/ha и www.oracle.com/goto/maa.
И обязательно записывайтесь на наши онлайн-тренинги.