Обычно у нас есть два способа восстановить QMGR. Один из них backup and restore QMGR data&log, а другой create backup QMGR. Мой вопрос: какой из них лучше подходит для ситуации восстановления QMGR? Или у них обоих есть свои сценарии использования? Пожалуйста, помогите ответить на это.
Спасибо
Восстановление от чего именно? С каким целевым временем восстановления или каким целевая точка восстановления? Оптимальный ответ зависит от этих требований, а также от того, как написаны ваши приложения. Лучший способ с архитектурной точки зрения — рассматривать обмен сообщениями как транспорт. Когда вы создаете резервные копии сетевых маршрутизаторов, вы не создаете резервные копии сообщений, находящихся в пути на маршрутизаторах, вы просто создаете резервные копии конфигураций маршрутизаторов. То же самое с менеджером очередей. Если вы сделаете резервную копию определений объектов, авторизации, ini-файлов, выходов и параметров выхода, вы можете воссоздать пустую версию QMgr и возобновить работу с того места, где остановилась старая.
К сожалению, большинство приложений спроектированы так, как если бы уровень обмена сообщениями был базой данных, а не транспортом. Это означает, что они хотят восстановить сообщения из неработающего QMgr. Это то, что Backup QMgr используется для. Это работает так, что основной QMgr использует линейные файлы журналов. Со временем активные файлы журналов расширяются, и старые файлы, которые больше не требуются для восстановления, «скатываются» с конца набора журналов. Затем эти файлы отправляются туда, где живет и применяется резервный QMgr. Резервный QMgr будет иметь точную копию сообщений, которые находились в очередях, когда этот файл журнала был активен в последний раз.
Между сообщениями основного администратора очередей и сообщениями резервного администратора очередей всегда будет задержка, которая представлена пространством, занимаемым основным и дополнительным активными экстентами журнала. Если первичный и вторичный журналы имеют небольшой размер и количество, количество сообщений, потерянных при отработке отказа, можно свести к минимуму. Таким образом невозможно достичь нулевой точки восстановления, однако это НАМНОГО лучше, чем резервное копирование на определенный момент времени.
Что приводит нас к другой методологии резервного копирования, которую вы упомянули. Резервное копирование на определенный момент времени (т. е. резервное копирование очереди и файлов журнала QMgr) не может работать, если резервное копирование выполняется во время работы QMgr. На загруженном QMgr журналы и очереди постоянно записываются и должны быть синхронизированы. Но резервное копирование этих файлов в активном состоянии в значительной степени гарантирует, что резервные копии журналов не будут синхронизированы с резервными копиями очередей. Возможно, что QMgr будет восстановлен с поврежденными очередями или QMgr даже не запустится после восстановления.
Эта стратегия резервного копирования работает единственный раз, когда QMgr остановлен, и тогда ее лучше всего использовать для восстановления после обновления, а не для активной системы. Например, предположим, что вы делаете действительное резервное копирование на определенный момент времени в воскресенье утром в 1:00. Потом в течение недели кто-то удаляет файл очереди из-под QMgr и вам нужно его восстановить. Восстановление onbe-файла не сработает, потому что он не будет синхронизирован с логом и будет отображаться как поврежденный объект. Вы должны восстановить весь QMgr. Вы получаете все сообщения, которые были во всех очередях по состоянию на 1:00 в прошлое воскресенье. Хуже того, если QMgr участвует в кластере, восстановление его до предыдущего момента времени сбрасывает порядковые номера в командных сообщениях кластера, поэтому, даже если выглядит так, будто QMgr восстановлен и исправен, кластер может игнорировать его или любые изменения, которые вы в него вносите.
Единственная стратегия резервного копирования, которая является наиболее распространенной, но не упомянутой в вашем посте, — это резервное копирование конфигурации QMgr. Это включает:
Из них вы сможете воссоздать конфигурацию администратора очередей, и все эти резервные копии могут быть выполнены во время работы QMgr. При восстановлении генерирует пустой QMgr, к которому приложения могут подключаться так же, как и раньше. Основное требование состоит в том, что приложения (или человеческие процессы) должны согласовывать любые отсутствующие сообщения.
Существует один подход к аварийному восстановлению, при котором достигается нулевая точка восстановления, т. е. не теряются никакие сообщения. Это использует синхронную репликацию диска в файлах QMgr. Каждое обновление очереди или файла журнала реплицируется в режиме реального времени на сайт аварийного восстановления, поэтому DR QMgr имеет точную копию основного QMgr. Когда первичный сервер выходит из строя, вы прерываете репликацию и запускаете DR QMgr. Предполагая, что ваш DNS также настроен на отработку отказа, все удаленные QMgr и программы будут использовать DR QMgr, как если бы он был основным.
Также есть несколько вариантов HA. Использование аппаратного кластера, такого как PowerHA или Veritas Cluster Server, может привести к аварийному переключению QMgr с одного сервера на другой при условии, что файлы QMgr размещены на высокодоступном диске, таком как SAN. Multi-Instance QMgr может выполнять аналогичную отработку отказа без программного обеспечения аппаратного кластера и основан на высокодоступном хранилище NFS. Это оба решения высокой доступности, а не решения аварийного восстановления, поскольку оба экземпляра QMgr видят одно и то же дисковое хранилище. Поэтому они должны находиться на одном и том же расстоянии (в терминах сети) от этого дискового хранилища, иначе производительность самого удаленного QMgr будет страдать от задержки, а пропускная способность может оказаться неприемлемой.
Дополнительная информация доступна в < em>Доступность, восстановление и перезагрузка в разделе Инфоцентра.
