Собрание заметок об информационных технологиях
Данный материал является переводом оригинальной статьи "MSDN Blog SQLGardner : SQL 2012 AlwaysOn and Backups - Part 3 - Restore.
Иногда вещи должны немного выскальзывать из рук. Во всяком случае давайте немного поговорим о том, как все эти замечательные параметры резервного копирования в SQL Server 2012 могут повлиять на процесс восстановления.
Данный материал является переводом оригинальной статьи "MSDN Blog SQLGardner : SQL 2012 AlwaysOn and Backups - Part 2 - Configuring Backup Preferences and Automating Backups.
В предыдущем посте я показал, что можно выполнить резервное копирование из ваших реплик. Мысль, которую вы, возможно, подумали — "Хорошо, это здорово. Но как я узнаю, что это экземпляр реплики, и он не стал основным? Что делать, если для выполнения резервного копирования я хочу использовать конкретный экземпляр реплики, но позволить другому экземпляру иметь возможность сделать это в случае, если тот не доступен?" К счастью команда по продукту продумала такие вопросы и создала некоторые параметры конфигурации для настройки резервного копирования.
Данный материал является переводом оригинальной статьи "MSDN Blog SQLGardner : SQL 2012 AlwaysOn and Backups - Part 1 - Offloading the work to a replica".
Одним из величайших аспектов SQL Server AlwaysOn является возможность разгрузить работу резервного копирования и проверку целостности в реплику. Это действительно может помочь сохранить ресурсы на вашей основной рабочей нагрузке приложения. Я собираюсь сосредоточиться главным образом на резервных копиях журнала транзакций в этой статье, так как резервное копирование журнала лучше всего использовать для того, чтобы проиллюстрировать эту новую функцию. Одним из ключевых элементов включения этой резервной способности является цепочка одного журнала, которая поддерживается по всем репликам. Проиллюстрирую это, показывая log_reuse_wait_desc sys.databases и выходные данные инструкции DBCC SQLPERF('logspace').
Пакет управления/базового мониторинга (Management Pack) ОС Windows Server для System Center 2012 R2 Operations Manager (SCOM) в конфигурации по умолчанию выполняет обнаружение и мониторинг состояния фрагментации всех логических дисков системы. Функциональность это безусловно полезная, но есть ситуации, когда нужно отключить такого рода мониторинг (и соответственно его оповещения) для определённых систем, как например серверы System Center Data Protection Manager (DPM), у которых может быть множество логических разделов диска, создаваемых механизмами DPM и “живущих по своим законам”.
“Мал золотник, да дорог!”
В данной статье пойдет речь о вопросах, связанных с использованием технологии репликации виртуальных машин (Hyper-V Replica) в операционной системе Windows Server 2012 R2. Основной информации достаточно в Интернете (см. ссылки в конце заметки), поэтому аспекты логики работы, установки и настройки Hyper-V Replica рассматриваться мной не будут.
Данная технология представлена Microsoft еще с Windows Server 2012 как катастрофоустойчивое решение (DRaaS - Disaster Recovery as a Service) для ЦОД-ов. Но меня она заинтересовала как решение организации в небольших фирмах (например, в филиалах) резервирования хостов виртуальных машин (ВМ) без общего хранилища.
На этапе тестирования и отладки проекта внедрения Hyper-V Replica появилось небольшое количество адекватных вопросов:
1) Настройка расположения ресурсов ВМ на отдельные диски. Например, необходимо виртуальный системный диск ВМ (vhd/-x) хранить на другом логическом диске хоста от виртуального диска ВМ с данными.
2) Отделение трафика репликации от основного.
Решение обоих вопросов оказалось простым!
Оба файла загрузил сюда, если кому всё ещё надо: https://disk.yandex.ru/d/gBRReDO6tBGloQ
Александр. спасибо за интересный содержательный комментарий.
RSS - Записи
Последние комментарии