Что такое veritas oracle
В этом режиме все узлы могут предоставлять услуги (нет запроса пользователя на бездействие в режиме ожидания). В большинстве случаев аппаратная конфигурация участников кластера одинакова, что позволяет избежать возможных проблем с производительностью и упрощает балансировку нагрузки. Активные / активные кластеры требуют более сложного программного обеспечения для управления всеми ресурсами, такими как диск и память, которые необходимо синхронизировать между всеми узлами. Чаще всего в качестве контрольного соединения используется частная сеть. Программное обеспечение для управления кластером должно уметь обнаруживать проблемы с узлами, такие как отказ узла или проблемы связи с кластером.
Сплит-мозг (split-brain) - плохая ситуация в кластере: внутренняя связь отключается, когда все кластеры в кластере работают. В этом случае кластер разделен на несколько частей, каждая часть программного обеспечения кластера будет пытаться захватить ресурсы других узлов, потому что кажется, что другие узлы вышли из строя. Может возникнуть следующая проблема: если приложение может нормально подключаться к этим частям кластера, поскольку эти части кластера в это время не синхронизированы, на диск могут быть записаны разные данные. Опасность разделения мозга на кластер очевидна, и поставщик программного обеспечения кластера должен предоставить решение для решения этой проблемы.
【подводить итоги】
- В этой статье освещается архитектура высокой доступности Oracle RAC + ADG, указываются ограничения RAC, описываются два применения ADG, простое предложение - использовать ADG для создания «избыточности данных», ненормальной в среде RAC. В этих обстоятельствах предоставьте способ возобновить деловое использование в течение короткого времени;
- В то же время АДГ также является «наркотиком сожаления», в случае неправильной работы человека, когда основная библиотека не работает, неправильная операция восстанавливается с минимальными затратами;
- Отслеживание этой общедоступной учетной записи даст конкретный случай операции.
To be continued.
Если вы нашли эту статью полезной, можете сканировать и следовать следующей общедоступной учетной записи WeChat.
Включаем режим Copilot
В режиме Copilot ситуация выглядит иначе. В нашем тесте создание резервной копии происходило каждые 12 часов, а время резервного копирования фиксировалось от момента создания снапшота Oracle до окончания момента записи резервной копии в storage pool на устройстве NBU.
Type | DB Load | Elapsed Time | Megabytes | Speed TB/h |
Backup | Yes | 0:36:53 | 1 294 153 | 2,6 |
Backup | Yes | 0:32:14 | 1 126 525 | 2,5 |
Backup | Yes | 0:33:34 | 1 152 365 | 2,7 |
Backup | Yes | 0:31:23 | 1 123 620 | 2,6 |
Backup | Yes | 0:44:04 | 1 681 999 | 2,9 |
Результаты этого теста оказались средними. Однако стоит учитывать, что синтезирование резервной копии с последующей записью в storage pool происходило в NFS Share. Возможно, частично за низкую производительность отвечают дополнительные ограничения скорости чтения и записи NFS Share. К тому же для более «старших» моделей NetBackup Appliance существует технология Optimized Share, так что скорость работы в подобном режиме должна быть выше. Мы использовали Veritas Appliance в минимальной конфигурации с одной полкой, тогда как вендор рекомендует применять минимум две полки для режима Copilot.
Таким образом, главным преимуществом использования Copilot остается восстановление последней полной резервной копии без необходимости наката инкрементальных копий. Использование функции Instant Restore для быстрого доступа к СУБД еще в процессе восстановления также является большим плюсом.
ДОСТУПНЫЕ ИЗДАНИЯ, АГЕНТЫ И ВАРИАНТЫ
Backup Exec Editions Backup Exec доступен со следующими лицензиями:
Резервное копирование Backup Exec и параметров
Backup Exec обеспечивает масштабируемое, простое в управлении резервное копирование и восстановление для облачных, виртуальных и физических сред. Наличие дополнительных агентов и опций расширяет возможности и функции Backup Exec для поддержки критически важных приложений, баз данных, конфигураций хранилищ и многих других.
Возможность выбора между постоянными и ограниченными по времени лицензиями, позволяет быстро и адаптироваться к меняющимся потребностям вашего бизнеса. Лицензия на подписку на Backup Exec дает вам доступ к унифицированному программному обеспечению для защиты данных, а также к обновлениям и новым выпускам функций, которые все сводятся к одной цене подписки. Существует три подписных издания: Бронза, Серебро и Золото.
Предложения по подписке на Backup Exec Bronze, Silver и Gold включают неограниченное развертывание сервера Backup Backup, параметров и агентов, если количество защищенных данных на терабайтах не превышает количество терабайт, указанное вашей лицензией, с минимум 1 ТБ на сервер Backup Exec. «Front-end терабайт» (FETB) определяется как размер защищенных несжатых данных (т. Е. Данных, которые не были дедуплицированы). Вы можете приобретать лицензии на столько TB, сколько вам нужно, исходя из количества данных, которые необходимо защитить. Количество серверов Backup Exec не может превышать количество приобретенных ТБ, поскольку каждый сервер Backup Exec должен иметь лицензию не менее 1 ТБ.
Уникальность vs сложность
Остановимся чуть подробнее на обозначенных выше пунктах. Как в фильме характеры каждого персонажа вносят свой вклад в развитие сюжета, так и в нашем проекте выбор заказчика предопределил последующий накал страстей.
Знакомство с Veritas Backup Exec
Backup Exec обеспечивает всестороннюю защиту от внешних угроз. Поэтому, если это немыслимо, ваши критические данные будут скопированы и готовы к восстановлению быстро и легко.
Дьявол в деталях
Хотим поделиться еще несколькими нюансами, не все из которых были задокументированы на момент реализации нашего проекта.
Не забудьте сконфигурировать Anti-affinity правила, чтобы оба узла виртуального кластера случайно не оказались на одном гипервизоре. Для этого потребуется лицензия VMware vSphere Enterprise Plus с ее функционалом DRS.
Даже несмотря на то, что использовать снапшоты нельзя, администраторы системы резервного копирования (СРК) могут случайно поставить на безагентский бэкап ваши виртуальные машины. Пара кликов мыши в консоли управления СРК — и кластер из двух узлов неработоспособен. Расследование инцидента показало следующее: СРК принудительно включает CBT на виртуальном диске (а как мы уже зафиксировали, данная технология не поддерживается с multi-writer диском) и при первой попытке записать что-то на виртуальный диск гипервизор сыпет ошибками. Чтобы избежать этого, мы рекомендуем:
добавить параметр ctkDisallowed="true" (он был описан в базе знаний VMware, но по неизвестным причинам статья закрыта);
в СРК контрольно добавить в исключения общие диски узлов кластера.
Начиная с версии VMware vSphere 6.7 P01 (build 15160138) на vSAN можно не использовать общие диски в формате thick eager-zeroed. До этой версии общие диски приходилось создавать вручную из командной строки с помощью утилиты vmkfstools.
А с версии VMware vSphere 6.7 Update 3 (build 14320388) vSAN поддерживает SCSI-3 persistent резервации, но применение технологии SCSI-3 PR IO fencing с общими VMDK-дисками в Veritas Cluster не поддерживается. Для арбитража ситуации Split Brain требуется задействовать Coordination Point Server.
Oracle на VMware — можно
Очень долго компания Oracle вела негласную войну с VMware, отказываясь официально предоставлять техподдержку заказчикам, которые запускали СУБД Oracle на VMware. Наверняка администраторы СУБД Oracle знакомы со статьей в базе знаний Metalink Note 249212.1. В 2019 году политика вендора изменилась. Oracle объявил о стратегическом партнерстве с VMware и наконец начал оказывать техподдержку.
Использовать ли Copilot?
Мы возлагали большие надежды на NetBackup Copilot — все-таки эта технология изначально создавалась для работы с СУБД и использует Oracle incremental merge, чтобы перейти на схему резервного копирования forever incremental. При работе в режиме Copilot система взаимодействует с менеджером резервного копирования СУБД Oracle RMAN для запуска команд резервного копирования СУБД.
Если разложить процесс резервного копирования с использованием NetBackup Copilot по стадиям, он выглядит так:
- на устройстве NetBackup Appliance настраивается устройство хранения резервных копий, доступное серверу СУБД Oracle по протоколу NFS;
- после этого настраивается политика резервного копирования в консоли администрирования СРК NetBackup;
- сам процесс резервного копирования начинается с создания базовой копии (level-0), после чего выполняются только инкрементальные резервные копии (level-1);
- изменения, возникающие с момента создания базовой резервной копии level-0, применяются к образу, который актуализируется на момент создания последней резервной копии level-1;
- NetBackup создает мгновенные снимки образа резервной копии на NFS-хранилище устройства (используя функции интегрированного в устройство ПО InfoScale);
- каждая резервная копия и мгновенный снимок добавляются в каталог менеджера резервных копий Oracle RMAN и в служебную базу данных NetBackup.
Кроме этого, администраторы СУБД могут использовать утилиты резервного копирования и восстановления Oracle. Инкрементальные копии позволяют работать с большим количеством точек восстановления, а все копии находятся в файловом хранилище, которым не нужно управлять.
Вопрос брошен здесь:
Что мне делать, если бизнес не может быть слишком длинным или прерываться, когда библиотека достигает уровня T?
Одно из решений: в этом сценарии вы можете использовать ADG для восстановления. Некоторые студенты спрашивали, не синхронизируется ли ADG в режиме реального времени, как его можно восстановить в данных перед операцией по человеческим ошибкам, у ADG есть параметр задержки, использующий разницу во времени журнала приложения задержки для быстрого восстановления резервной копии до точки сбоя, а затем с помощью логического выражения exp & imp для достижения Восстановление уровня таблицы.
Шаги операции следующие:
- Используйте следующую команду, чтобы отложить синхронизацию приложения журнала библиотеки
Укажите атрибут delay в резервной базе данных, резервная база данных откладывает 60 минут для применения журнала основной библиотеки
sql> alter database recover managed standby database delay 60 disconnect from session;
Единицей этого параметра являются минуты, здесь библиотека сэмпловой синхронизации и основная библиотека имеют 60-минутный интервал обновления данных, то есть 60-минутный «препарат сожаления», конечно, он также может быть установлен на любой период времени, Время восстановления / время журнала приложения связано с производительностью сервера и объемом журнала резервного порта. Например, база данных T-уровня, управляемая нашим офисом, полностью восстанавливается до 16 часов, а интервал задержки, установленный нашим офисом, составляет 60 * 24 = 1140 в день.
2. Когда вам нужно восстановить базу данных, выполните следующие действия:
2.1 В режиме ожидания момент времени выполнения не полностью восстановлен
2.2 Логический экспорт и импорт, затем используйте метод логического резервного копирования для экспорта / экспорта данных перед аварийной точкой и импортируйте основную базу данных с помощью метода imp / impdp для восстановления данных.
3. Затем основная библиотека восстанавливает исходный интервал времени.
SQL> alter database recover managed standby database cancel;
SQL>alter database recover managed standby database delay 60 disconnect from session;
Внутреннее соединение
Межкластерное соединение - одна из характеристик Oracle RAC. Он не только позволяет кластеру преодолевать алгоритм проверки связи блоков при передаче блоков данных между разными экземплярами, но также может использоваться для контрольных сигналов и регулярного обмена данными. Сбой подключения приведет к реорганизации кластера, чтобы избежать разделения функций, и Grid Infrastructure перезапустит один или несколько узлов. Вы можете настроить отдельное соединение для RAC и Grid Infrastructure. В этом случае вам необходимо настроить RAC для использования правильного соединения. Это соединение всегда должно быть частным, и ему не должны мешать другие сети. Пользователи RAC могут использовать две технологии для достижения внутреннего взаимодействия: Ethernet и Infiniband.
Что в результате?
В нашем случае получилось создать необходимую конфигурацию и выполнить все требования заказчика. Критичные базы данных Oracle получили эшелонированную защиту от различных сбоев.
Подойдет ли описанная конфигурация всем? Хм, сомневаемся. На выходе получается слоеный пирог из нескольких технологий с весомым списком ограничений при дальнейшей эксплуатации. Но с ограничениями придется смириться, если на другой чаше весов находятся драгоценные минуты простоя и огромное влияние системы на бизнес. И перед использованием подобного решения мы рекомендуем оценить все «за» и «против» в каждом отдельном случае.
Автор: Дмитрий Горохов, руководитель направления виртуализации «Инфосистемы Джет»
Роман Родин, инженер-проектировщик вычислительных комплексов «Инфосистемы Джет»
Давайте познакомимся в лидером среди программ резервного копирования - Veritas Backup Exec. Программы Veritas признаются лидерами в своей области в течении многих лет. Знакомство с Veritas Backup Exec начинается прямо сейчас.
Veritas Backup Exec ™ - это решение для резервного копирования без барьеров. Вы выбираете резервную копию, где ее хранить и как платить за нее. Ваши данные остаются безопасными и доступны на каждом этапе - будь то резервное копирование на месте в облаке, защита рабочих нагрузок в облаке, восстановление из облака или подключение к хранилищу на предварительном этапе. Благодаря Backup Exec вы можете подключаться к постоянно расширяющемуся семейству решений, которые помогут вам уверенно управлять своим бизнесом.
Backup Exec доступен для покупки либо в режиме бессрочной лицензии, либо в виде годовой подписки, с требуемым уровнем функциональности - бронзой, серебром или золотом.
Бронзовый набор предлагает самый экономичный вариант.
Серебряный набор предлагает наиболее часто используемые функции.
Золотая версия включает все функции и функции, доступные в Backup Exec.
Стоимость покупки основана на объеме данных, для которых необходимо создать резервные копии. Выбранный набор лицензий доступен в любых количествах, которые вам нужны.
Основные характеристики и преимущества Veritas Backup Exec
- Унифицированное решение для общедоступных и гибридных облачных, виртуальных и физических сред упрощает резервное копирование и устраняет стоимость и сложность нескольких точечных продуктов.
- Экономичное и комплексное решение, разработанное для многократного использования и предназначенное для цифрового бизнеса.
- Быстрые снимки виртуальной машины благодаря глубокой интеграции с Microsoft® Volume Shadow Copy Service (VSS) и API-интерфейсами VMware vStorage ™ для защиты данных (VADP) минимизируют влияние нагрузки на нагрузку на процессор, память и производительность ввода-вывода на виртуальном хосте.
- Быстрое и гибкое восстановление на всех уровнях, в любом месте.
- Мгновенное восстановление виртуальных машин VMware и Hyper-V обеспечивает мгновенно пригодную для использования копию сервера и данные для DR, соответствия, тестирования и развертывания приложений.
- Функция готовности к восстановлению для автоматического тестирования и восстановления DR для резервных копий виртуальной машины.
- Дедупликация повсюду позволяет защитить больше данных и пропускную способность, минимизируя дисковое пространство, необходимое для файлов резервных копий.
- Veritas-сертифицированная совместимость практически с любым устройством хранения, включая облачные, дисковые и ленточные средства. Backup Exec поддерживает стратегию хранения вашей организации, а не наоборот.
- Интегрированное восстановление с нуля, от физического до виртуального (P2V) и виртуального до физического (V2P) помогает минимизировать время простоя и сбои.
- Глобальная прозрачность данных путем интеграции с Информационной картой и поддерживает соответствие нормативным требованиям для ВВП.
- Повышенная безопасность ваших данных с помощью встроенного 128/256-битного шифрования AES.
Внимание к виртуальным дискам
Чтобы создать классический отказоустойчивый кластер, данные нужно хранить на общем диске, и к нему должны иметь доступ все узлы кластера.
Если есть внешняя СХД, то для подобной конфигурации на платформе виртуализации используют RDM-диски. В случае с vSAN применяются виртуальные VMDK-диски с дополнительными настройками. По умолчанию VMware vSphere защищает данные от ошибок администратора, позволяя подключить виртуальный жесткий диск в один момент времени только к одной виртуальной машине. Чтобы обойти это ограничение, для общих виртуальных дисков надо прописать вручную параметр multi-writer .
Выключаем виртуальную машину и добавляем параметр вида scsiX:Y.sharing = "multi-writer" в конфигурационный файл. Также важно не забыть для общих дисков в этом же конфигурационном файле добавить параметр disk.EnableUUID = "TRUE" для корректной работы кластерного ПО Veritas.
Однако за высокую доступность и надежность придется заплатить существенными ограничениями, с которыми придется мириться при дальнейшей эксплуатации системы. Основные из них:
Нельзя менять размер общего диска «на лету». Для этого придется выключать оба узла кластера и только после этого производить манипуляции с диском. Пожалуй, это самая больная тема. Когда заканчивается место на диске, где лежит критичная БД, становится не до шуток.
Нельзя использовать снапшоты для общих дисков. Соответственно, нельзя будет использовать средства безагентского резервного копирования для бэкапа данных. Как следствие, технология Change Block Tracking для инкрементального резервного копирования также не поддерживается.
Без Storage vMotion миграцию общих виртуальных дисков на горячую выполнить будет невозможно.
Хорошая новость — обычный vMotion для перемещения виртуальных машин между гипервизорами успешно работает.
[Производство] _Oracle ADG технология синхронизации - «наркотик сожаления», необходимый для DBA
НАДЕЖНЫЙ
Сложные продукты резервного копирования и восстановления могут быть неэффективными, трудоемкими и дорогими в управлении. Благодаря интуитивно понятным мастерам и проницательным панелям, Backup Exec прост в реализации, использовании и управлении, будь то обновление с предыдущей версии или переход от конкурирующего продукта.
Простота управления
Быстро отслеживайте и контролируйте каждое задание резервного копирования и восстановления через простой в использовании интерфейс с интуитивно понятными панелями мониторинга и мастерами. В нескольких простых кликах вы можете установить задания резервного копирования, просмотреть состояние резервного копирования и выполнить быстрое восстановление. Вместо использования сложных политик экономить время и упростить реализацию защиты резервного копирования с помощью визуального рабочего процесса, который позволяет реплицировать данные на предварительном, вне сайта или в облако. Кроме того, централизованная консоль администрирования Backup Exec обеспечивает масштабируемое управление распределенными сайтами и помогает сократить время и ресурсы, необходимые для управления операциями резервного копирования.
Улучшенная видимость
Более разумные решения начинаются с лучшей видимости. Backup Exec обеспечивает видимость всей инфраструктуры резервного копирования и восстановления, чтобы вы могли при необходимости действовать. Легко выполнять подробный поиск резервных копий данных, включая данные почтовых ящиков по темам, базы данных Microsoft SQL по имени или данные SharePoint по имени документа. Настройте Backup Exec для интеллектуального просмотра вашей среды и обнаружения рисков, связанных с серверами, виртуальными машинами и другими данными.
Гибкое лицензирование
Backup Exec - это экономичное решение, которое легко приобрести, лицензировать, развернуть и масштабировать. Благодаря Backup Exec вы получаете возможность выбирать правильную модель лицензирования для своей среды - все по доступным ценам.
Снизить информационный риск и оптимизировать хранение информации
Интеграция Backup Exec с информационной картой Veritas ™ отображает вашу информационную среду в визуальном контексте и направляет пользователей к беспристрастному принятию решений в области управления информацией.
Используя динамическую навигацию по информационной карте, клиенты могут определять области риска, области ценности и области отходов в своей среде хранения и принимать решения, которые помогают снизить информационный риск и оптимизировать хранение информации.
Плюсы Veritas NBU
Сначала мы оценили, какие уникальные технологии могут ускорить процессы резервного копирования и восстановления. Поскольку речь шла о резервном копировании СУБД Oracle, а в качестве сетевого подключения использовался 10 GbE (никаких Fiber Channel), наиболее полезными оказались следующие инструменты Veritas:
- Media Server Deduplication Pool (MSDP) — дедупликация данных «на лету», которая оптимизирует репликацию резервных копий между устройствами и создает синтетические полные резервные копии за время инкрементальных;
- NetBackup Optimized Duplication устраняет избыточность передаваемых данных за счет передачи только уникальных блоков, которые отсутствуют на принимающем устройстве;
- NetBackup Copilot сокращает время создания резервных копий СУБД Oracle, используя мгновенные снимки файловой системы устройства NetBackup и интеграцию с менеджером резервного копирования Oracle RMAN.
Узел кластера
Кластер состоит из отдельных узлов. В Oracle RAC разрешенное количество узлов связано с версией кластера. В общедоступном документе указано, что программное обеспечение кластера Oracle 10.2 поддерживает 100 узлов, а 10.1 поддерживает 63 экземпляра. Даже когда узел выходит из строя, приложения на основе RAC могут продолжать работать, вы все равно должны приложить некоторые усилия, чтобы убедиться, что отдельный компонент на сервере базы данных не имеет единой точки отказа (SPOF).
При покупке нового оборудования следует использовать компоненты с возможностью горячей замены, такие как встроенные диски и вентиляторы.Кроме того, необходимо обеспечить резервирование источника питания сервера, адаптера шины хоста, сетевой карты и жесткого диска. Если возможно, лучше всего выполнить логическую привязку, например, аппаратный RAID жесткого диска или программный RAID, привязку сетевой карты и многопутевость сети хранения. Следует также обратить внимание на центр обработки данных: использовать источники бесперебойного питания, адекватные меры по рассеиванию тепла и профессиональные серверные полки. Лучше иметь удаленную консоль управления отключением света. Когда узел зависает по неизвестным причинам, может потребоваться срочное устранение неполадок или перезапуск.
Используйте внутреннее соединение на основе Infiniband
Используйте межсоединение на основе Ethernet
Использование 10G Ethernet в качестве внутреннего соединения кластера может быть наиболее распространенным в настоящее время, а фоновый процесс кластера использует TCP / IP для связи. Cache Fusion (используется для поддержания согласованности кеша) использует другой метод связи: UDP (UserData, ramProtocol). UPD и TCP относятся к транспортному уровню, который ориентирован на установление соединения и использует явное квитирование связи, чтобы гарантировать поступление сетевых пакетов данных по порядку и пересылку пакетов с ошибочными данными. UDP не содержит статуса, это протокол типа «запустил и забыл». UDP просто отправляет пакет данных по назначению. Основное преимущество UDP над TCP в том, что он легче.
заметка: Следует избегать использования перекрестных кабелей для прямого соединения между двумя кластерами узлов.Внутренняя связь кластера должна быть заменена.Использование перекрестных кабелей должно быть прямо запрещено!
Использование jumbo-кадров может повысить эффективность и производительность обмена данными внутри кластера. Кадры Ethernet могут иметь разные размеры, обычно ограниченные 1500 байтами (значение MTU). Размер кадра определяет, сколько данных может передать один кадр Ethernet.Чем большую нагрузку данных несет кадр, тем меньше работы требуется серверу и коммутатору, что обеспечивает более высокую эффективность связи. Многие коммутаторы позволяют разместить в кадре большее количество байтов (1500-9000), чем стандартное значение MTU, также называемое кадром большого размера. Обратите внимание, что кадры jumbo не маршрутизируются, поэтому их нельзя использовать в общедоступных сетях. Принимая решение об использовании jumbo кадров, убедитесь, что все узлы в кластере используют одинаковый MTU.
Я просто сказал, что связанные компоненты сервера базы данных должны быть простыми, и сетевая карта также является одним из них. Несколько сетевых портов можно связать в логическую единицу с помощью технологии связывания в Linux.В отличие от многих других операционных систем, привязка сетевых карт в Linux может быть достигнута без покупки другого программного обеспечения.
ИННОВАЦИОННЫЙ
Благодаря сотням патентов, присуждаемых в таких областях, как резервное копирование, восстановление, виртуализация, дедупликация и т. Д., Backup Exec продолжает давнюю традицию продвижения на рынок передовых технических технологий.
Clusterware/Grid Infrastructure
Изоляция ввода / вывода:
Когда в кластерной системе есть проблема «разделения мозга», мы можем использовать «алгоритм голосования» для решения проблемы того, кто получает контроль над кластером. Но этого недостаточно.Мы также должны убедиться, что удаленный узел не может манипулировать общими данными. Это проблема, которую необходимо решить с помощью IO Fencing.
IO Fencing можно реализовать двумя способами: аппаратным и программным.
Программный метод: для устройств хранения, поддерживающих команды SCSI Reserve / Release, вы можете использовать команды SG для достижения. Нормальный узел использует команду SCSI Reserve для «блокировки» устройства хранения. После того, как отказавший узел обнаруживает, что устройство хранения заблокировано, он знает, что оно было вытеснено из кластера, что означает, что он находится в ненормальной ситуации и должен перезапустить его для восстановления. В нормальное состояние. Этот механизм также называют Sicide (самоубийство). Sun и Veritas используют этот механизм.
Аппаратный метод: STONITH (Shoot The Other Node in the Head), этот метод напрямую управляет выключателем питания, когда один узел выходит из строя, если другой узел может его обнаружить, он будет Команды подаются через последовательный порт для управления выключателем питания неисправного узла, и неисправный узел перезапускается путем временного выключения и включения. Этот метод требует аппаратной поддержки.
VMware vSAN
Это программно-определяемая система хранения данных от VMware. Для создания общего отказоустойчивого хранилища используются локальные диски, установленные в серверах виртуализации. Во всем мире более 30 тысяч компаний используют VMware vSAN в своих ИТ-инфраструктурах.
【введение】
Суть всех решений высокой доступности - «избыточность». Конечно, бюджетные расходы станут чрезвычайно дорогими, поскольку требования к высокой доступности возрастут.
При построении архитектуры базы данных, независимо от бюджетных ограничений, они часто содержат несколько требований: высокая доступность, высокий параллелизм, балансировка нагрузки и Для масштабируемости SLA потребуется 99,99%, 99,999% или выше 99,9999%. Среди этих требований, лично считаю, что первой должна быть обеспечена высокая доступность. Это требование может гарантировать, что когда сервер в архитектуре базы данных ненормально не сможет предоставить услуги передачи данных, уровень базы данных все еще может обеспечить стабильные услуги передачи данных.
Архитектура высокой доступности уровня Oracle - это RAC. Друзья, знакомые с этой архитектурой, знают, что RAC может отвечать требованиям высокой доступности и высокого одновременного доступа, но это отражается только на избыточности вычислительных ресурсов. Источник данных по-прежнему один. Когда источник данных поврежден или ненормальный, он не может предоставлять услуги данных. Решением этой ситуации является использование архитектуры RAC + ADG для обеспечения избыточности на уровне данных путем создания резервной библиотеки ADG.
Согласно вашему собственному опыту, следующая статья приблизительно знакомит с двумя распространенными применениями ADG:
Цель ADG 1: Переключатель высокой доступности под ненормальной основной библиотекой
1. Эта архитектура может удовлетворить требование о том, что, когда основная среда RAC является ненормальной и не может предоставлять услуги передачи данных, переключитесь на библиотеку синхронизации ADG, чтобы обеспечить восстановление бизнес-использования в кратчайшие сроки. Нормальное время переключения примерно на минутном уровне, но на этот раз вам нужно изменить соединение приложения с базой данных: большинство приложений разрабатываются на java, и пример использования jdbc для подключения к базе данных выглядит следующим образом:
Как указано выше, для подключения к экземпляру базы данных требуется три информации: ip библиотечного сервера, номер порта библиотеки, имя экземпляра / службы.
Когда среда RAC является ненормальной, и вам нужно переключиться на библиотеку ADG, например, исходя из предположения, что конфигурация имени экземпляра RAC и ADG остается неизменной,
Информация базы данных связи приложения может быть изменена с исходного RAC service-ip / scan-ip на IP-адрес ADG. В этом случае, если в java-программе есть несколько операторов для подключения к библиотеке, вы можете установить db-service-ip в качестве глобальной переменной приложения. В настоящее время вы можете изменять только параметры db-service-ip. Однако после изменения конфигурации библиотеки подключений к приложениям часто возникает необходимость перезапустить приложение, что приводит к перерыву в работе, включая: время переключения библиотеки + конфигурация подключения библиотеки модификации приложения и время перезапуска, время прерывания работы больше.
Один вопрос: как сократить время прерывания бизнеса в этом случае?
Ответ таков: вы можете запустить vip на сервере ADG. Этот vip является service-ip / scan-ip RAC, который экономит время для приложения на изменение конфигурации подключения библиотеки и перезапуск, Значительно сократить продолжительность прерывания бизнеса. Конкретная команда для запуска vip на сервере ADG выглядит следующим образом:
Использование ADG 2: метод восстановления данных при неправильной эксплуатации человека
В соответствии с приведенными выше объективными факторами база данных также имеет субъективный фактор, который часто является причиной ненормальности базы данных: ошибки при работе человека.
В этом случае есть три распространенных метода:
- Выполните восстановление базы данных в другой среде, и непосредственно перед восстановлением до точки аварии, после нахождения правильных данных, импортируйте данные в производственную среду: это решение можно использовать, когда база данных мала, а время прерывания бизнеса короткое;
- Используйте Oracle Flashback для восстановления. Oracle Flashback - это набор функций базы данных Oracle. Flashback позволяет просматривать состояние объектов базы данных за один раз в прошлом, или вы можете восстановить объекты базы данных до прежнего состояния без помощи восстановления базы данных;
- Используя logminner, LogMiner представляет собой практический и очень полезный инструмент анализа, предоставляемый Oracle начиная с продукта 8. Используя этот инструмент, вы можете легко получить конкретный контент файлов онлайн / архивных журналов Oracle, особенно этот инструмент может анализировать все операции базы данных. DML и DDL заявления. Этот инструмент особенно подходит для отладки, аудита или отката конкретной транзакции.
Вышеупомянутыми тремя ситуациями являются либо длительное время восстановления, либо занятие дополнительного места для хранения, либо искусственно сложный анализ, такой как Flashback / Logmnr (если это тип DML, вы можете использовать запрос обратной передачи или извлечение logmnr; если он отброшен, вы можете использовать таблицу обратной связи, но если это Поле изменяет или усекает операции, указанные выше не будут работать).
Не больше 25% и в пределах 50 Тб
Вернемся к случаю заказчика. Тестирование на синтетической БД оказалось полезным, так как помогло клиенту увидеть все «за» и «против» первоначально симпатичного решения. Поиграв с параметрами, мы пришли к выводу, что использовать Veritas NetBackup целесообразно для СУБД размером до 50 Тб, а также при суточных изменениях в БД не более 25%. Поскольку БД розничной сети менялись каждые сутки на 50%, то Veritas NetBackup не стал подходящим решением.
Побочный эффект нашего тестирования оказался ценным. Мы нашли оптимальные режимы для работы Veritas NBU вместе с СУБД Oracle. За счет настройки параметров и выбора режима (классическая копия или Copilot) можно создать достойную и более доступную альтернативу для резервного копирования и восстановления СУБД Oracle при относительно небольшом количестве суточных изменений в БД в десятки Тб. Для тех, кто уже пользуется СРК Veritas, такой выход оптимален. Это использование более доступной по стоимости СРК и управление всем резервным копированием через одну консоль.
Автор: Артем Хмеленко, инженер систем хранения данных «Инфосистемы Джет»
В одном проекте мы строили новую ИТ-инфраструктуру и консолидировали на нее базы данных Oracle. Базы были разных объемов и степени критичности (вплоть до Business Critical). Казалось бы, штатная задача. Но в ней таилась одна особенность, о которую мы поломали немало копий, — развертывание на VMware кластера Veritas HA.
ГИБКИЙ
Не каждое решение для резервного копирования имеет гибкость для защиты всей информации вашей организации - облачной, виртуальной и физической. Выберите архитектуру защиты данных, которая работает для вас, вместо того, чтобы позволить программе диктовать вашу настройку. Резервное копирование всего на любое устройство хранения данных и восстановление практически в любом месте. Резервное копирование Exec - это единственное решение для всех ваших потребностей в защите данных: от виртуальных машин до целых серверов, приложений, отдельных файлов и папок или гранулярных объектов приложений.
По настоящему унифицированное решение
Защита облачных, виртуальных и физических данных Снижение затрат и упрощение задач резервного копирования начинается с развертывания единого решения, предназначенного для всей вашей инфраструктуры, независимо от платформы: виртуальной, физической или облачной. Система Backup Exec, полностью интегрированная с платформами VMware, Microsoft и Linux, может защитить от одного до тысячи серверов и виртуальных машин от одной и той же пользовательской консоли, обеспечивая оптимальную производительность и эффективность. Масштабируемость является важным фактором при резервном копировании и восстановлении, а Backup Exec поддерживает вас по мере роста вашей организации.
Гибридные архитектуры для облаков, дисков и ленты
Backup Exec обеспечивает гибкость для защиты сред VMware и Hyper-V с использованием агентов или методов без агента, в дополнение к физическим машинам на базе Microsoft и Linux, будь то on-prem или in cloud. Гибкие целевые параметры позволяют записывать практически на любое устройство хранения, включая диск, ленту, размещенное хранилище или непосредственно в общедоступные облачные сервисы, такие как Amazon S3, Google Cloud Storage и Microsoft Azure. Шлюзовые устройства, такие как Amazon Storage Gateway или Microsoft StorSimple, позволяют быстро перейти на экономичное облачное хранилище.
Быстрое, эффективное и универсальное восстановление
Backup Exec быстро восстанавливает данные на любом уровне детализации, «из любого места в любое место» с однократной резервной копией. В нескольких простых кликах вы можете восстанавливать данные с облачного сервера, виртуальных машин и физических серверов, включая целые приложения, отдельные объекты, файлы, папки и детализированные элементы приложения из Microsoft® Exchange, Active Directory®, SQL Server® и SharePoint ®.
Backup Exec интеллектуально индексирует и каталогизирует данные резервного копирования, поэтому вы не тратите драгоценное время и места на резервное копирование места на диске, определяя, что внутри, и ищете конкретные данные. Backup Exec эффективно восстанавливает данные непосредственно из резервной копии, что упрощает и ускоряет восстановление, когда вам это нужно больше всего.
Backup Exec также обеспечивает встроенное аварийное восстановление (DR) для минимизации простоев, снижения риска и устранения сбоев в работе бизнеса. В случае катастрофы Backup Exec может восстановить весь сервер из голого состояния металла на одно и то же или несходное оборудование за считанные минуты, а не часы или дни. Он также может преобразовывать ваши физические серверы или их резервные копии в виртуальные машины. Защищенные виртуальные машины можно быстро создать из набора резервных копий для немедленного использования.
Настроить активный / пассивный кластер
Активный / пассивный кластер работает иначе, чем активный / активный кластеры. Аппаратная конфигурация элементов в активном / пассивном кластере должна быть такой же или в основном такой же, но только один из двух узлов может обрабатывать запросы пользователей одновременно. Программное обеспечение для управления кластером будет постоянно контролировать состояние ресурсов в кластере. Когда ресурс выходит из строя, программное обеспечение для управления кластером пытается перезапустить ресурс несколько раз. Если он по-прежнему недействителен, резервный узел берет на себя.
В соответствии с опциями во время установки ресурсы кластера могут быть выделены в общем хранилище или файловой системе, и последняя также выполнит аварийное переключение при отказе ресурса. Использование совместно используемой файловой системы имеет больше преимуществ, чем использование не разделяемой файловой системы, которая может потребовать обнаружения fsck (8) перед повторным подключением к резервному узлу. Набор кластеров Veritas, кластер Sun (Oracle) и IBM HACMP можно использовать в качестве инструментов управления кластером для установки активных / пассивных кластеров.
Менее известно, что использовать Oracle Grid Infrastructure для установки активного / пассивного кластера очень просто. Используя интерфейс прикладных программ Grid Infrastructure и Oracle ASM в качестве диспетчера логических томов кластера, вы можете легко контролировать базу данных Oracle с одним экземпляром без прерывания. Когда узел выходит из строя, база данных автоматически переносится на резервный узел. В зависимости от параметра инициализации fast_start_mttr_target и размера набора для восстановления этот отказоустойчивый процесс может быть очень быстрым. Однако в процессе отработки отказа соединение с базой данных пользователя будет отключено.
Активный / пассивный режим может быть Параметр active_instance_count установлен в 1 для открытия, но он действителен, только когда количество узлов равно 2.
Настроить сетевые компоненты
Для правильной работы сетевой инфраструктуры требуются некоторые IP-адреса: каждый хост оснащен общедоступным сетевым адресом; каждый хост имеет частный сетевой адрес; каждый хост имеет виртуальный IP-адрес (не назначен); 1-3 неназначенных IP-адреса Используется для функции имени доступа единого клиента; если используется Grid plug and play, неиспользуемый виртуальный IP-адрес также должен быть назначен службе именования Grid.
Виртуальный IP-адрес узла - одна из самых полезных функций Oracle Cluster. Их необходимо настроить в сегменте сети с общедоступным IP-адресом и поддерживать как ресурсы кластера в сетевой инфраструктуре. В 9i, когда узел выходит из строя, общедоступный IP-адрес не может отвечать на запросы соединения. Когда сеанс клиента пытается подключиться к вышедшему из строя узлу, он должен дождаться истечения времени ожидания соединения, что может оказаться долгим процессом. С виртуальным IP-адресом это происходит намного быстрее: при отказе узла грид-инфраструктура переключает виртуальный IP-адрес узла на другой узел в кластере. Когда клиентский сеанс подключается к виртуальному IP-адресу отказавшего узла, Grid Infrastructure знает, что узел не работает должным образом, и позволит ему подключиться к следующему узлу в кластере. Другое требование - это 1-3 IP-адреса. Независимо от размера кластера, это требование добавляется к сетевой инфраструктуре. Этот тип адреса называется SCAN (имя доступа единого клиента). SCAN создается и настраивается во время обновления или установки сетевой инфраструктуры.Перед выполнением установки вам необходимо добавить эти IP-адреса SCAN в DNS для циклического разрешения. Если вы используете Grid Naming Service (GNS), вам необходимо назначить ему виртуальный IP-адрес в общедоступной сети.
Наладить резервное копирование СУБД Oracle инструментами того же вендора — просто. А если попытаться оптимизировать стоимость решения? Тогда возможные ИТ-инструменты стоит придирчиво рассмотреть в действии. Так и получилось: в поиске ответа на запрос заказчика обнаружилось, когда стоит «женить» Oracle и NBU, а когда лучше это не делать. Делимся опытом тестирования системы резервного копирования Veritas NBU для защиты данных в СУБД Oracle и интересными нюансами процесса настройки.
Один из наших клиентов — ритейлер федерального масштаба — озаботился резервированием данных в СУБД Oracle. По умолчанию для этого подходит Oracle Zero Data Loss Recovery Appliance (ZDLRA). Но стоит комплекс как круизный ледокол. К тому же ZDLRA не дал бы клиенту контролировать все процессы резервного копирования через единую консоль. Эти соображения заставили искать альтернативы. Одной из них стало устройство Veritas NetBackup Appliance 5240 — СРК среднего уровня с хорошей производительностью в стандартных условиях. Оптимизма добавляла и технология Copilot в арсенале Veritas, предназначенная специально для работы с СУБД Oracle.
Прежде чем испытывать Veritas NetBackup Appliance 5240 в «живой» инфраструктуре, заказчик попросил протестировать его. Мы собрали стенд и проверили решение в боевых условиях. Выводы оказались любопытными.
Делаем инкрементальные копии
Чтобы оценить производительность в режиме создания инкрементальных резервных копий, мы проводили копирование 2 раза в сутки в 10:00 и 22:00. СУБД находилась под нагрузкой, а дедупликация на клиенте была включена.
Type | Job Schedule | DB Load | Client deduplication | Elapsed Time | Speed TB/h |
Backup | Incremental 10:00 | Yes | Enable | 0:10:58 | 2,2 |
Backup | Incremental 22:00 | Yes | Enable | 0:09:58 | 2,2 |
Backup | Incremental 10:00 | Yes | Enable | 0:10:03 | 2,3 |
Backup | Incremental 22:00 | Yes | Enable | 0:09:04 | 2,2 |
Backup | Incremental 10:00 | Yes | Enable | 0:11:13 | 2,3 |
Backup | Incremental 22:00 | Yes | Enable | 0:12:01 | 2,2 |
Backup | Incremental 10:00 | Yes | Enable | 0:12:21 | 2,3 |
Backup | Incremental 22:00 | Yes | Enable | 0:10:53 | 2,5 |
Backup | Incremental 10:00 | Yes | Enable | 0:12:03 | 2,3 |
Backup | Incremental 22:00 | Yes | Enable | 0:12:04 | 2,2 |
Backup | Incremental 10:00 | Yes | Enable | 0:12:13 | 2,3 |
Backup | Incremental 22:00 | Yes | Enable | 0:12:01 | 2,2 |
Backup | Incremental 10:00 | Yes | Enable | 0:12:21 | 2,3 |
Backup | Incremental 22:00 | Yes | Enable | 0:10:53 | 2,5 |
Время создания инкрементальных копий было намного меньше, но и скорость сессий резервного копирования также оказалась ниже.
Настроить архитектуру Shared-Nothing
В кластере базы данных без совместного использования каждый узел имеет собственное частное независимое хранилище, и другие узлы не могут получить к нему доступ. База данных разделена на несколько частей узлами в кластере, и возвращаемый набор структур запроса представляет собой комбинацию наборов результатов каждого узла. Потеря узла сделает соответствующие данные недоступными. Поэтому кластер с общей записью часто реализуется в виде отдельных активных / пассивных или активных / активных кластеров для повышения доступности. Кластер MySQL основан на архитектуре без совместного использования ресурсов.
К тестированию готовы? Да, но нет
Мы развернули тестовый стенд, который включал в себя NetBackup Master Server, NetBackup Media Server и Oracle Linux Server 6.7. NetBackup Appliance (выступал в роли NetBackup Media Server) был подключен к базе данных через два порта 10 GbE, а NetBackup Master Server развернули на виртуальной машине в среде виртуализации VMware vSphere 6.0.
В качестве источника РК использовали физический сервер с установленной ОС Oracle Linux Enterprise 6.7 и СУБД Oracle 19. Чтобы смоделировать работу системы в условиях, близких к требованиям заказчика, объем тестовой базы Oracle мы установили в размере 1 Tб в формате Bigfile. База данных находилась под нагрузкой, а объем изменений в течение 12 часов составлял 50-60% от изначального объема базы.
Итак, поехали! Мы запустили резервное копирование, но уровень производительности оказался удивительно низким — 2,3–2,8 TB/h. По результатам — привет из 90-х! В документах по работе Veritas NBU с СУБД Oracle готовых решений для сложившейся ситуации не было. Но сам факт наличия Copilot и хорошая производительность решения на стандартных задачах, как, например, резервное копирование файловых систем, наводили на мысль, что мы упускаем из виду какие-то моменты. Тогда вместе с коллегами из Veritas мы начали поиск тонких настроек NetBackup, которые повысили бы производительность.
Мы проверили несколько десятков настроек и нашли для них оптимальные значения. В числе параметров, которые влияли на производительность тестового стенда, оказались:
- значения Jumbo Frame (размеры фреймов Ethernet, в которых можно передавать данные);
- политика передачи хэша (xmit_hash_policy), напрямую влияющая на скорость и эффективность резервного копирования;
- размеры буферов (Number Disk, Size Disk) Veritas Appliance требовалось менять для резервного копирования часто меняющейся БД
Структура процесса
После завершения установки будут созданы некоторые фоновые процессы, чтобы убедиться, что кластер работает правильно и может взаимодействовать с внешним миром. Некоторые из упорядоченных требований платформы Linux необходимо активировать с полномочиями пользователя root. Например, для изменения конфигурации сети требуются более высокие права доступа. Другие фоновые процессы будут выполняться под управлением пользователя системы, в которой находится программное обеспечение grid. В следующей таблице описаны основные фоновые процессы.
закулисный процесс | Описание |
Служба высокой доступности Oracle (OHAS) | OHAS - это первый компонент сетевой инфраструктуры, открытый после запуска сервера. Он настроен на открытие с помощью init (1) и отвечает за создание процесса агента. |
Oracle Agent | Грид-инфраструктура использует два процесса агента Oracle. Первый, вкратце, отвечает за открытие некоторых ресурсов, которым необходим доступ к файлам OCR и VOTING. Он был создан дизайнером OHAS. Второй процесс агента создается CRSD и отвечает за открытие всех ресурсов, для доступа к которым не требуются права root. Этот процесс выполняется под управлением пользователя, которому принадлежит Grid Infrastructure, и отвечает за работу, выполняемую racg в RAC 11.1. |
Oracle Root Agent | Подобно процессу агента Oracle, создаются два корневых процесса агента. Первоначальный процесс агента запускается OHAS, который обеспечивает инициализацию ресурсов, требующих более высоких привилегий в системе Linux. Основные создаваемые фоновые процессы - это CSSD и CRSD. В свою очередь, CRSD запустит другой корневой агент. Этот агент будет открывать основные и сетевые ресурсы, которым требуются права root. |
Кластерный процесс обслуживания (CRSD) | Основной фоновый процесс программного обеспечения кластера использует регистрационную информацию кластера Oracle для управления ресурсами в кластере. |
Процесс службы синхронизации кластера (CSSD) | Управление конфигурацией кластера и членством в узлах |
Мониторинг процессов Oracle (OPROCD) | oprocd отвечает за изоляцию ввода-вывода в версии 11.1. Он был введен для системы Linux в наборе исправлений 10.2.0.4. Перед установкой этого патча ядро Модуль таймера зависания используется для выполнения аналогичных задач. Интересно, что oprocd раньше часто использовался на платформах, отличных от Linux. Грид-инфраструктура заменила процесс opocd процессом cssdagent. |
Менеджер мероприятий (EVM) | EVM отвечает за публикацию событий, созданных Grid Infrastructure. |
Служба синхронизации времени кластера (CTSS) | Услуга CTSS является дополнительной. Она обеспечивает синхронизацию времени для кластера через сервер сетевого протокола времени. Эта синхронизация времени очень важна для RAC. Он может работать в двух режимах: ждать и смотреть или активен. Когда NTP активирован, он работает в режиме наблюдения.Если NTP не активирован, он синхронизирует время всех узлов в соответствии с главным узлом. |
Служба предупреждений Oracle (ONS) | Основной фоновый процесс, отвечающий за публикацию событий через среду быстрого приложения. |
В RAC11.2 последовательность запуска сетевой инфраструктуры значительно изменилась. Вместо открытия CRS, CSS и EVM напрямую через inittab (5) процесс OHAS теперь в основном отвечает за создание процессов агентов, мониторинг состояния других узлов и открытие ресурсов кластера. В процессе управления, не относящемся к Oracle, NTP играет особую роль: в каждом кластере он должен обеспечивать синхронизацию часов, и Grid Infrastructure не является исключением.
МОЩНЫЙ
Когда вы можете решить больше проблем с меньшей сложностью, у вас есть простое, но мощное решение для повышения производительности. Backup Exec может помочь вам:
• Познакомьтесь с бизнес-ожиданиями для резервного копирования и восстановления.
• Сократите расходы на хранение.
• Защита конфиденциальных данных.
• Достижение нормативных требований.
• Ликвидируйте инструменты резервного копирования ниши из своей инфраструктуры.
Быстрая, экономичная, многоузловая резервная копия для уверенности и выбора
Благодаря наличию большего количества вариантов интеграции облачных хранилищ Backup Exec позволяет легко перемещать резервные копии в облако с помощью интеграции облачного хранилища одним щелчком мыши. Получите единую защиту данных облака с сквозной дедупликацией и сертифицированными облачными коннекторами для ведущих в отрасли поставщиков облачных вычислений с более низкой стоимостью и меньшим риском - независимо от того, где находятся данные.
Быстрое и надежное резервное копирование и восстановление
Backup Exec позволяет удовлетворить ожидания защиты данных вашей организации за счет сокращения времени, необходимого для резервного копирования и восстановления важной информации, приложений и серверов. С помощью Backup Exec вы можете снизить риск и сократить время простоя, используя широкий спектр гибких методов резервного копирования и восстановления. Если вы используете диск, ленту или облако, ваша информация может быть легко и надежно восстановлена.
Расширенная интеграция с VMware и Hyper-V
Backup Exec предлагает полную защиту вашей виртуальной среды и Центра данных, определяемого программным обеспечением, включая новые программные средства хранения данных, такие как VMware® Virtual SAN и виртуальные тома.
Восстановите то, что вам нужно, когда и где вам это нужно. Легко создавать резервные виртуальные копии ваших физических систем для аварийного восстановления в минутах или для общих миграций P2V.
Backup Exec обращается к разрастанию виртуальной машины, автоматически определяя и защищая новые виртуальные машины по мере их появления, поэтому вы можете быть уверены, что ваши виртуальные машины защищены от первого дня.
Сохранить больше, хранить меньше
Гибкая глобальная дедупликация в Backup Exec помогает вам решать растущие проблемы с данными, независимо от того, насколько сильно ваши данные изменяются. Это помогает минимизировать окна резервного копирования, уменьшает сетевой трафик и сокращает дисковое пространство, необходимое для хранения данных резервного копирования. Новая дедупликация в облаке снижает общую стоимость владения (TCO) с помощью всеобъемлющей дедупликации для облачных вычислений, что позволяет сэкономить затраты на хранение и инфраструктуру.
Настроить общую архитектуру
Кластер, в котором все узлы имеют доступ к общему хранилищу и данным одновременно, называется структурой общего доступа или общего доступа. Oracle RAC основан на архитектуре общего доступа: база данных находится в общем хранилище и доступна через экземпляры, запущенные на каждом узле кластера. В терминологии Oracle экземпляр состоит из структуры памяти и некоторых процессов. Соответственно, база данных хранится в файле данных на диске. В RAC отказ экземпляра не означает потерю данных, которыми управляет экземпляр. После выхода из строя узла другой экземпляр в кластере выполнит восстановление экземпляра, а все оставшиеся узлы продолжат работу. Использование технологий высокой доступности, таких как FCF или TAF, может минимизировать влияние сбоя экземпляра на пользователей. Отказавший узел в конечном итоге снова присоединится к кластеру и разделит рабочую нагрузку.
Условия задачи
Итак, мы строили абсолютно новую ИТ-инфраструктуру на заранее выбранных нашим заказчиком решениях. Исходные условия:
БД Oracle должны запускаться в виртуальных машинах на платформе виртуализации VMware vSphere.
Данные виртуальных машин должны располагаться на двух разных хранилищах: программно-определяемой СХД VMware vSAN и отдельной внешней СХД.
Защита критичных БД Oracle должна быть обеспечена двумя эшелонами:
с помощью ПО Veritas InfoScale Availability (он же хорошо известный в Enterpise сегменте как Veritas Cluster Server);
наличием отдельной Standby копии.
Схема решения выглядит так:
Veritas InfoScale Availability в виртуальных машинах
С понятными условиями разобрались. Как делать Standby и зачем он нужен — тоже все ясно. Но в условиях задачи есть суперважные базы данных, простой которых критичен. Крупные компании часто одним из инструментов защиты критически важных СУБД Oracle выбирают решение Veritas InfoScale Enterprise (он же Veritas Cluster Server). Заказчик нас попросил применить это решение, чтобы защитить самые критичные БД Oracle в виртуальных машинах.
Мы проконсультировались с Veritas и VMware и выяснили, что такие конфигурации используют несколько заказчиков в Европе, а в нашей стране подобное никто раньше не делал. Звучало как вызов!
Вообще у VMware vSphere есть встроенный механизм обеспечения высокой доступности виртуальных машин (vSphere HA). Он позволяет перезапустить виртуальную машину, если случился сбой гипервизора, на котором она работала. Механизм проверен годами и работает без нареканий. Зачем же тогда использовать что-то еще? vSphere HA не может обеспечить некоторые важные опции:
не проверяет статус работы приложения внутри виртуальной машины и не «умеет» реагировать на различные сбои, возникающие в гостевой ОС (например, сбой сетевого адаптера);
не отвечает за порядок старта сервисов внутри гостевой ОС и выполнение необходимых проверок в случае рестарта виртуальной машины;
всегда есть задачи по эксплуатации критичных сервисов (например, выполнение обновлений версий ПО), при исполнении которых хотелось бы минимизировать время простоя.
Получается, что повысить надежность работы приложения и его доступность можно двумя способами — на уровне приложения (если оно это умеет) и средствами кластеризации. А в отдельных случаях, как у нас — обоими сразу.
А если на скорость?
Насколько же быстро все это работает? После оптимизации и ручной настройки отдельных параметров мы получили вполне приличную скорость резервного копирования.
В таблице даны сводные результаты создания полной резервной копии с включенной и выключенной дедупликацией на клиенте, включенной и выключенной «срезкой» Redo logs, в условиях, когда СУБД находится под нагрузкой и без нагрузки.
Type | Job Schedule | DB Load | Client deduplication | Redo logs | Elapsed Time | Speed TB/h |
Backup | Full | Yes | Enable | Disable | 0:14:06 | 4,4 |
Backup | Full | Yes | Disable | Disable | 0:18:22 | 4,2 |
Backup | Full | Yes | Enable | Enable | 0:22:36 | 4,1 |
Backup | Full | Yes | Disable | Enable | 0:30:07 | 3,6 |
Backup | Full | No | Enable | Disable | 0:12:16 | 4,7 |
Backup | Full | No | Disable | Disable | 0:16:45 | 4,2 |
Backup | Full | No | Enable | Enable | 0:16:15 | 4,3 |
Backup | Full | No | Disable | Enable | 0:17:40 | 3,9 |
Система резервного копирования NBU показала хорошую скорость записи резервных копий. Очевидным узким местом в нашем тесте оказалась дисковая подсистема Veritas Appliance в модели 5240 (количество дисков в RAID-группе и скорость работы интерфейса). В тестировании использовалась минимальная конфигурация с одной дисковой полкой.
Читайте также: