active standby что это
Failover на Cisco ASA
Read the article FAILOVER ON CISCO ASA in 
English
Перед тем, как настраивать резервирование на Cisco ASA (режим failover) необходимо четко понять следующее:
Я сознательно умалчиваю об исключениях из этих правил, дабы свести к минимуму возможные дальнейшей проблемы с настройкой.
Обратите внимание!
В вопросе настройке failover не так важны строки конфигурации, как последовательность их ввода и подключения двух Cisco ASA друг к другу.
Шаг 0. Проверка
Удостоверьтесь, что версии IOS на обоих устройствах идентичны, а также поддерживают режим failover. Для этого используйте команду « sh ver »
FW-DELTACONFIG-1# sh ver
Cisco Adaptive Security Appliance Software Version 9.4(2)6
.
Failover : Enabled
.
Если IOS различаются, то обновите версию на одном из устройств.
Шаг 1. Выбор интерфейса для синхронизации
Шаг 2.
Включите режим failover на Cisco ASA №1
FW-DELTACONFIG (config)#
failover
failover lan unit primary
failover lan interface STATE GigabitEthernet0/3
failover polltime unit 1 holdtime 3
failover link STATE GigabitEthernet0/3
failover interface ip STATE 10.0.0.1 255.255.255.252 standby 10.0.0.2
Шаг 3. Подготовка Cisco ASA №2
Перед тем, как настраивать Cisco ASA №2, полностью очистите конфигурацию и отключите от устройства все провода.
FW-DELTACONFIG (config)#
clear configure all
Шаг 4. Настройка Cisco ASA №2
failover
failover lan unit secondary
failover lan interface STATE GigabitEthernet0/3
failover polltime unit 1 holdtime 3
failover link STATE GigabitEthernet0/3
failover interface ip STATE 10.0.0.1 255.255.255.252 standby 10.0.0.2
После этого сохраните конфигурацию и выключите устройство из сети питания.
FW-DELTACONFIG (config)#
write
Шаг 5. Подключение
Шаг 6. Проверка работы failover
Важно!
Алгоритм работы failover
1) При включении Cisco ASA проверяет наличие соседей и, если таковой имеется, берет на себя роль Standby, при этом полностью копирует текущую конфигурацию с активного устройства и переходит в ждущий режим.
2) Если соседей не найдено, то Cisco ASA переходит в состояние Active и работает как отдельно стоящее устройство.
3) Если все настроено корректно и состояние межсетевых экранов выглядит как Active/Standby, то переключение ролей происходит в следующих случаях:
— ручное переключение из консоли активного устройства через команду «no failover active». Устройства меняются ролями и трафик начинает идти через соседнее устройство.
— автоматическое переключение на соседнее устройство, если на активном устройстве выйдет из строя хотя бы один из интерфейсов. Если точно такой же интерфейс уже был неактивен на Standby устройстве, то переключения не произойдет
Важно!
Важно!
Primary и Secondary – исключительно номера устройств. Они не имеют особого значения.
Active и Standby – роли устройств. Имеют определяющее значение и указывают на устройство, которое на данный момент работает с трафиком.
Для справки:
Обычно возникает вопрос: Как подключить канал от оператора связи сразу в оба межсетевых экрана? Каким образом сделать из одного провода два?
Очень просто – используйте коммутатор. Возьмите существующее оборудование, подключив Cisco ASA №2 к портам с такими же настройками Vlan, что и на потах, куда подключен Cisco ASA №1 или возьмите дополнительное устройство.
Достаточно самого простого коммутатора на 8 портов за 10$ — 20$. Подключите провод от провайдера в порт 1, а порты 2 и 3 соедините с обоими Cisco ASA. Этот вариант дешев, прост и понятен. В случае выхода из строя коммутатора его элементарно заменить за 5 минут на любой другой подобный. Один такой коммутатор требуется на каждый общий интерфейс.
Если позволяют финансы и бюджет, то для надежности я посоветую использовать коммутатор Cisco 2960, создав на нем нужное количество Vlan для каждого из интерфейсов на Cisco ASA.
Важно!
Не забудьте сохранить конфигурацию на Active устройстве командой write или copy run start. Иначе после перезагрузки все изменения будут потеряны.
FW-DELTACONFIG-1# write
Building configuration.
[OK]
Cisco ASA Failover: Настройка
Общая
Небольшая шпаргалка по настройке Cisco ASA Failover в режиме Active/Standby failover с версией 9.x.
Какие варианты существуют?
Существует два типа работы Failover:
Active/Active failover — где трафик обрабатывается двумя устройствами. Данный метод не является средством увеличения производительности устройств и используется для балансировки нагрузки. При данном типе работы нельзя использовать IPsec VPN, SSL VPN и динамическую маршрутизацию.
Active/Standby failover — где трафик обрабатывается первым (активным) устройством, а второе находится в режиме ожидания и принимает нагрузку только в случае отказа первого. В данном типе работы доступно VPN failover.
Так как мы рассматриваем настройку Active/Standby failover то углубимся в данный тип работы.
В Active/Standby failover есть два режима работы :
Stateful failover — где обе ASA обмениваются информацией о состоянии сеансов по выделенному линку (Statefull Failover Link) и если какая-либо из ASA выйдет из строя, то другая подхватит существующие сеансы и продолжит работу.
Stateless failover — где при отказе основной (Active) все сеансы связи сбрасываются; активируется резервная (Standby) ASA, соединения для всех сеансов устанавливаются заново.
Перед тем как начать следует убедиться в следующем:
1. Обе ASA должны быть полностью одинаковыми во всем (модель, тип установленных модулей, количество ОЗУ и т.д.);
2. Обе ASA должны иметь одинаковый IOS;
3. Обе ASA должны иметь одинаковый загруженный образ AnyConnect (если таковой имеется или используется) и одинаковый файл профиля AnyConnect (если нет то копировать эти файлы вручную);
4. Обе ASA должны быть одинаково соединены с одними и теми же устройствами.
Что реплицируется и что нет?
Так же следует учесть что после настройки не все команды или файлы реплицируются межу Active и Stanby ASA.
Не реплицируются такие файлы как:
Файлы образ и профиль AnyConnect;
Образ Cisco Secure Desktop (CSD);
Не реплицируются следующие команды:
Команда Copy (исключение copy running-config startup-config );
Команда Write (исключение write memory );
Команда Debug и все ее составляющие;
Команда Failover lan unit и все ее составляющие;
Команда Firewall и все ее составляющие;
По поводу лицензий на устрйоство.
Начиная с версии 8.3(1) достаточно лицензии только для Active устройства.
Настройка устройств.
Обе ASA никак не подключены друг к другу.
Настройка ASA-01
Первым делом необходимо выбрать интерфейс для Statefull Failover Link по которому ASA будут обмениваться состояниями.
На обоих ASA интерфейс должны быть одним и тем же.
Настройка Statefull Failover Link.
interface GigabitEthernet0/1
description STATE-REPLICATION Failover Interface
no nameif
no security-level
no ip address
no shutdown
Включаем режим failover на ASA-01
failover
failover lan unit primary
failover lan interface STATE-REPLICATION GigabitEthernet0/1
failover polltime unit 1 holdtime 3
failover link STATE-REPLICATION GigabitEthernet0/1
failover interface ip STATE-REPLICATION 172.16.0.1 255.255.255.252 standby 172.16.0.2
wri
Настройка ASA-02
Настройка Statefull Failover Link.
interface GigabitEthernet0/1
description STATE-REPLICATION Failover Interface
no nameif
no security-level
no ip address
no shutdown
Включаем режим failover на ASA-02
failover
failover lan unit secondary
failover lan interface STATE-REPLICATION GigabitEthernet0/1
failover polltime unit 1 holdtime 3
failover link STATE-REPLICATION GigabitEthernet0/1
failover interface ip STATE-REPLICATION 172.16.0.1 255.255.255.252 standby 172.16.0.2
wri
После этого выключаем ASA-02, соединяем между собой интерфейсы GigabitEthernet0/1 обеих ASA и включаем ASA-02.
После загрузки ASA-02 появится следующее:
Detected an Active mate
Beginning configuration replication from mate.
Если существуют какие-то недочеты и ошибки то они будут выведены в консоль.
Проверку работоспособности Failover проверяем командой sh failover на ASA-01 и получаем вывод:
Если хотим доступность ASA Standby в сети.
Если вам необходима доступность Standby ASA в сети то выполните на Active ASA, на нужном вам интерфейсе следующее:
int НОМЕР ИНТЕРФЕЙСА
ip address IP-АДРЕС МАСКА standby IP-АДРЕС
Что делать если у вас подключен провайдре к одной из ASA?
Команды Show, которые помогут.
Show conn count
Show failover
Show failover exec
Show failover exec mate
Show failover group
Show monitor-interface
Show running-config failover
Настройка Failover режима на Cisco ASA.
Что такое режиме Failover в Csco ASA?
Режим Failover подразумевает резервирование основного устройства другим – резервным устройством.
То есть у нас должны быть две одинаковые Cisco ASA модели, например Cisco ASA 5512, которые соединяются между собой как минимум одним линком (обычно одного достаточно, но для желающих можно и два завернуть).
Логика работы режима Failove следующая:
Основной межсетевой экран всегда находится в активном состоянии и выполняет свою функциональную работу до тех пор, пока не выйдет из строя например или не упадет какой-либо важный для жизнеспособности офиса соединение. Пока основное устройство работает в полную силу, вторая Cisco находится в режиме ожидания и содержит в себе полную копию конфигурации
основной Asa. Соответственно, как только резервная Cisco перестает получать от основного hello-пакеты или видит в них падение какого-либо линка, сразу же берет на себя роль Active.
Переключение происходит так быстро, что пользователи не замечают, что произошла серьезная операция по спасению стабильности работы офиса.
1. Начнем настройку c “Cisco ASA основная (active)”.
1.1. Выбираем интерфейс, который будет играть роль связующего между основной и резервной Cisco, например interface 0/1.
1.2. Далее переходим непосредственно к настройке Failover следующими командами:
Если после данной команды вы видите сообщение:
Это означает, что вам нужно отключить dhcp client на интерфейсе Gi1/1. Отключается он следующими командами:
Если сообщение, что выше у вас не появилось, продолжаем вводу команд ниже.
2. Настройку первого устройства завершили, переходим к настройке второго – резервного Cisco ASA (standby).
Настройка почти одинакова, кроме того, что нам нужно объяснить устройству, что оно Secondary, в отличии от первого где мы объявляли его Primary.
Также объявляем интерфейс, который по завершению можно будет объединить патчкордом.
Настраиваем сам failover режим:
3. Проверка работы Failover режима Cisco ASA.
Командой sh failover мы видим статус текущего устройства и общее состояние режима Failover.
На этом завершаем статью, успехов в настройке.
Стекирование коммутаторов Cisco. Часть 2
Всех приветствую!
В первой части данной статьи мы рассмотрели достаточно старые технологии стекирования для семейства коммутаторов Cisco 3750, а именно StackWise и StackWise Plus. Сегодня предлагаю продолжить рассмотрение остальных технологий. Напомню, у нас остались StackWise-160, StackWise-480, FlexStack и FlexStack Plus.
Технология StackWise-160 возникла с появлением коммутаторов серии 3650. С другими версиями технологий стекирования она не совместима. Основные алгоритмы работы позаимствованы у StackWise Plus. При этом есть отличия. Первое – это новая архитектура самого коммутатора, построенная на базе новых ASIC’ов (Unified Access Data Plane (UADP) ASIC).
Новые ASIC’и наделены достаточной интеллектуальностью для обеспечения функций коммутации. Из-за этого в отличии от 3750E/3750X больше нет выделенной коммутационной фабрики. Интересный момент заключается в том, что коммутация трафика между портами, обслуживаемыми разными ASIC’ами, обеспечивается через стековый интерфейс.
Хотел бы напомнить, что в старых ASIC’ах (в коммутаторах 3750E/3750X) элементы, отвечающие за обработку входящих пакетов, и элементы, отвечающие за обработку исходящих пакетов, разделены. Они не имеют общей шины внутри ASIC’а. Поэтому даже если пакет передаётся между портами, обслуживаемыми один и тем же ASIC’ом, этот пакет обязательно попадает на коммутационную фабрику.
Второе отличие StackWise-160 – увеличенная пропускная способность стековой шины. Пропускная способность стекового кабеля теперь равна 40 Гбит/с (full duplex). Таким образом, пропускная способность всей стековой шины для технологии StackWise-160:
40 Гбит/с * 2 (в каждую сторону) * 2 (количество портов) = 160 Гбит/с
Стоит отметить, что в отличии от серии коммутаторов 3750, стековый комплект для 3650 покупается отдельно.
Для технологии StackWise-160 изменена общая схема работы стека на программном уровне. Теперь для обеспечения отказоустойчивости используется схема Stateful Switch Over (SSO). Как мы помним, в предыдущих технологиях (StackWise и StackWise Plus) используется более простая схема восстановления после отказа. Один из коммутаторов выбирается в качестве мастера (stack master). Он выполняет логические операции (control-plane) для всего стека. Между коммутаторами стека синхронизируются только аппаратные таблицы (MAC-таблицы и таблиц CEF (FIB/Adj)). Остальные таблицы, в том числе таблица маршрутизации, на новом мастере заполняются заново. Т.е. control-plane запускается с нуля. На коммутаторах 3650 для обеспечения отказоустойчивости стала использоваться более продвинутая схема — Nonstop Forwarding with Stateful Switchover (NSF/SSO). Больше нет такого понятия как мастер. Теперь используется схема Active-Standby. Один из коммутаторов выбирается основным (Active), ещё один — его горячим резервом (Standby), синхронизирующим с основным всю необходимую информацию (L2 и L3). Control-plane теперь работает в режиме Active-Standby. Это обеспечило минимизацию времени, необходимого на восстановления в случае отказа основного коммутатора.
Давайте теперь посмотрим на технологию StackWise-480. С помощью неё можно объединить в стек коммутаторы серии 3850.
Коммутаторы 3650 и 3850 очень похожи. Обе эти серии построены на базе UADP ASIC. Соответственно алгоритмы работы стека StackWise-480 и StackWise-160 сходны. Правда есть отличие. В технологии StackWise-480 используется три физических стековых кольца. Достигается это тем, что внутри одного стекового кабеля для коммутаторов 3850, находится три провода (Рис. 6). Каждый с пропускной способностью 40 Гбит/с (full duplex).
Пропускная способность всей стековой шины для технологии StackWise-480:
40 Гбит/с * 2 (в каждую сторону) * 3 (количество проводов) *2 (количество портов) = 480 Гбит/с
На логическом уровне стек представлен шестью путями (по два логических пути на один провод). Пакеты по трём логическим путям «крутятся» в одну сторону, а по трём другим — в другую (Рис. 7).
Выбор пути осуществляется так же, как и раньше, с помощью токенов.
На этом с обзором технологий стекирования семейства Stackwise предлагаю закончить. Давайте теперь посмотрим на семейство коммутаторов 2960 и технологии стекирования FlexStack и FlexStack Plus.
Стекирование для 2960 появилось впервые на коммутаторах 2960-S. Для объединения коммутаторов по технологии FlexStack используется стековый модуль и специализированные кабели с пропускной способностью 10 Гбит/с (full duplex). Каждый стековый модуль имеет два порта. Коммутаторы при объединении соединяются в кольцо (хотя это и не обязательно). Общая пропускная способность всей стековой шины равна:
10 Гбит/с * 2 (в каждую сторону) * 2 (количество портов) = 40 Гбит/с.
Для стека FlexStack передача пакетов между коммутаторами происходит устройство-за-устройством. Коммутатор для каждого пакета определяет, куда его отправить: на обычный или на стековый порты. Такое взаимодействие напоминает работу нескольких коммутаторов, подключённых друг к другу по протоколу Ethernet. Разница в том, что связь между коммутаторами стека обеспечивает протокол FlexStack. Выбор того, через какой из стековых портов отправить пакет, определяется специальным алгоритмом, напоминающим работу OSPF. Т.е. выбирается кратчайший путь до коммутатора в стеке, на котором находится порт назначения. Если происходят какие-то изменения (например, отказал один из коммутаторов или отключился стековый кабель) данный алгоритм пересчитывает пути заново.
Отдельно нужно отметить механизм предотвращения зацикливания трафика. Речь идёт о трафике, где нет точного получателя (broadcast, multicast, unknown unicast). Так как этот трафик попадает на все коммутаторы стека, должен быть механизм, который предотвращает его зацикливание в случае, если коммутаторы соединены в кольцо (задействованы все стековые порты). Для этого используется механизм пассивных соединений (Passive link). Для каждого коммутатора в стеке выбирается стековое соединение, находящееся максимально далеко от рассматриваемого коммутатора. Это соединение становится пассивным. У каждого коммутатора в стеке будет своё такое соединение. При проходе через него отбрасывается весь broadcast, multicast и unknown unicast трафик, который попал в стек через коммутатор, для которое это соединение является пассивным. Т.е. у нас просто размыкается кольцо. Но в отличие от STP для каждого коммутатора в стеке кольцо размыкается в разных местах. Это даёт более эффективную передачу трафика, чем в случае классического STP.
На программном уровне схема работы FlexStack напоминает StackWise/StackWise Plus. Один из коммутаторов выбирается мастером и control-plane запускается только на нём.
Стек FlexStack Plus отличается от своего предшественника тем, что в стек можно объединить до 8 коммутаторов (для FlexStack эта цифра равна 4) и пропускная способность по специализированному кабелю увеличена до 20 Гбит/с. Таким образом, общая пропускная способность стековой шины составляет – 80 Гбит/с.
В заключение хотелось бы отметить несколько моментов.
Все рассмотренные технологии позволяют объединять коммутаторы в стек, находящиеся рядом друг с другом. Максимальная длина стекового кабеля 3 метра. Это, конечно, не очень удобно. Правда, Cisco и не позиционирует данные серии коммутаторов для построения распределённых стеков. Для этого в частности предлагается технология виртуализации коммутаторов Virtual Switching System (VSS). Её поддержка начинается на коммутаторах Cisco серии 4k.
Судя по временным характеристикам восстановления после сбоя, технологии StackWise более быстрые, нежели технологии FlexStack. Частично обусловлено это тем, что FlexStack все типы отказов отрабатывает программно. В принципе это не удивительно, так как серия Cisco 2960 младше. Наиболее интересными из рассматриваемых являются Stackwise-160 и 480, так как они поддерживают «взрослый» SSO.
На коммутаторах 3750X и 3850 появился ещё один тип стека – стек по питанию (StackPower). Он предназначен для перераспределения «лишних» мощностей между блоками питания коммутаторов, объединённых в данный тип стека. Это позволяет обеспечить работу коммутатора стека, в случае выхода из строя его локального блока питания. Или же предоставить дополнительный бюджет PoE.
Из практики могу сказать, что чаще приходилось сталкивать именно со стеками Stackwise (и его продолжениями). Особых проблем с их работой не было. Есть примеры, где такие стеки прекрасно отработали 5-7 лет в качестве ядра сети в сравнительно больших сетях. FlexStack на практике встречается реже. Правда и с ними особых проблем не было.
С версии IOS XE 16.3.3 появилась поддержка технологии StackWise Virtual. Она позволяет объединить в стек два коммутатора 3850-48-XS. С другими версиями StackWise данная технология не совместима. В качестве стековой шины используются обычные порты Ethernet (10 Гбит/с или 40 Гбит/с). Можно задействовать до четырёх портов. StackWise Virtual поддерживает SSO/NSF (переключение с сохранением состояния и передачей пакетов в момент переключения). StackWise Virtual в плане работы похожа на технологию VSS.
Еще раз про Oracle standby
Перед тем, как мы начнем, стоит немного сказать о тех принципах организации БД Oracle, которые понадобятся нам для понимания механизма работы резервного копирования и восстановления данных в СУБД Oracle.
Экземпляр БД Oracle содержит следующие виды файлов:
Управляющие файлы (Control files) — содержат служебную информацию о самой базе данных. Без них не могут быть открыты файлы данных и поэтому не может быть открыт доступ к информации базы данных.
Файлы данных (Data files) — содержат информацию базы данных.
Оперативные журналы (Redo logs) — содержат информацию о всех изменениях, произошедших в базе денных. Эта информация может быть использована для восстановления состояния базы при сбоях.
Существуют другие файлы, которые формально не входят в базу данных, но важны для успешной работы БД.
Файл параметров — используется для описания стартовой конфигурации экземпляра.
Файл паролей — позволяет пользователям удаленно подсоединяться к базе данных для выполнения административных задач.
Архивные журналы — содержат историю созданных экземпляром оперативных журнальных файлов (их автономные копии). Эти файлы позволяют восстановить базу данных. Используя их и резервы базы данных, можно восстановить потерянный файл данных.
Главная идея при создании standby экземпляра состоит в том, чтобы с помощью выполнения транзакций, сохраненных в оперативных или архивных журналах основной БД, поддерживать резервную БД в актуальном состоянии (такой механизм для Oracle называется Data Guard).
Отсюда следует первое требование к нашей основной базе — она должна быть запущена в archivelog mode.
Вторым требованием является наличие файла паролей. Это позволит удаленно подключаться к нашей БД в административном режиме.
Третье требование — это режим force logging. Этот режим нужен для принудительной записи транзакций в redo logs даже для операций, выполняемых с опцией NOLOGGING. Отсутствие этого режима может привести к тому, что на standby базе будут повреждены некоторые файлы данных, т.к. при «накатке» архивных журналов из них нельзя будет получить данные о транзакциях, выполненных с опцией NOLOGGING.
Также необходимо отметить, что если вы используете Oracle ниже 11g, то необходимо, чтобы сервера для основной базы и для standby имели одинаковую платформу. Т.е., если ваша основная база работает на Linux-сервере, то standby-сервер не может быть под управлением Windows.
Все примеры в этой статье будут ориентиваны на unix-системы, однако, их отличие от случая Windows-систем, в основном, состоит только в способе написания путей к файлам.
Не забываем также, что обмен данными между основным и standby серверами будет происходить по SQL-Net, поэтому необходимо, чтобы соединения на соответствующий порт (как правило, 1521 tcp) было открыто в обоих направлениях.
Будем считать, что наша база называется test. Мы будем так настраивать конфигурацию основной и standby базы, чтобы в любой момент мы могли поменять их роли местами (switchover). Мы планируем, что наша система будет использовать Data Guard protection mode, который называется MAXIMUM PERFORMANCE.
Итак, поехали.
Для начала поверяем соответствие нашей БД необходимым требованиям.
1. Смотрим, в каком режиме работает наша основная БД:
SQL> select name, open_mode, log_mode from v$database;
Если вы не видите значения ARCHIVELOG в поле LOG_MODE, выполняем следующие команды:
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;
2. Проверяем наличие файла паролей:
SQL> select * from v$pwfile_users;
Если вы не видите этот результат, создаем необходимый файл:
$ orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=xxxxxxxx force=y
Вместо ‘xxxxxxxx’ необходимо вставить текущий пароль пользователя SYS.
3. Включаем режим force logging:
SQL> alter database force logging;
Переходим к конфигурированию нашей системы. Для начала выполним необходимые настройки на основной базе. Будем сохранять все данные в каталоге /data/backup.
Создаем standby redo logs. Они нужны только на standby базе для записи данных, сохраняемых в redo logs на основной базе. На основной базе они нам понадобятся, когда мы будем переключать ее в режим standby и при этом использовать real-time apply redo. Файлы standby redo logs должны быть такого же размера как и online redo logs. Посмотреть размер online redo logs можно с помощью команды:
SQL> select bytes from v$log;
BYTES
———-
52428800
52428800
52428800
Смотрим, какие группы для redo logs есть в нашей базе:
SQL> select group# from v$logfile;
Создаем standby redo logs:
SQL> alter database add standby logfile group 4 ‘/oradata/test/stnbylog01.log’ size 50m;
Database altered.
SQL> alter database add standby logfile group 5 ‘/oradata/test/stnbylog02.log’ size 50m;
Database altered.
SQL> alter database add standby logfile group 6 ‘/oradata/test/stnbylog03.log’ size 50m;
Database altered.
Создаем файл с параметрами нашего экземпляра (pfile). Мы будем учитывать, что наша основная база может быть переключена в режим standby, а это требует задания параметров, которые будут использоваться только в standby режиме.
SQL> create pfile=’/data/backup/pfilePROD.ora’ from spfile;
Нам необходимо добавить некоторые параметры в получившийся файл, если их там нет:
db_name=’test’ — это имя нашей базы (одинаковое для основного и standby экземпляра).
db_unique_name=’testprod’ — а это уникальное имя для каждого экземпляра, оно не будет изменяться при смене ролей со standby на production.
log_archive_config=’dg_config=(testprod,teststan)’ — определяем имена экземпляров, между которыми будет происходить обмен журналами.
log_archive_dest_1=’SERVICE=teststan LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=’teststan’ – когда экземпляр является основной базой (PRIMARY_ROLE), мы будем передавать архивные журналы на standby сервер с помощью процесса LGWR. Параметр ASYNC указывает, что данные, сгенерированные транзакцией, не обязательно должны быть получены на standby до завершения транзакции – это не приведет к остановке основной базы, если нет связи со standby.
log_archive_dest_2=’LOCATION=/oradata/test/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=testprod’ – здесь мы указываем каталог, куда будут локально сохранятся архивные журналы (для основной базы) или куда будут складываться пришедшие с основной базы журналы (для standby базы).
log_archive_dest_state_1=ENABLE – включаем запись архивных журналов в log_archive_dest_1. Пока мы не создали standby базу, этот параметр можно поставить в значение DEFER, если мы не хотим видеть лишние сообщения о недоступности standby базы в alert_log.
log_archive_dest_state_2=ENABLE – включаем запись архивных журналов в log_archive_dest_2.
fal_client=’testprod’ – этот параметр определяет, что когда экземпляр перейдет в режим standby, он будет являться клиентом для приема архивных журналов (fetch archive log).
fal_server=’teststan’ – определяет FAL (fetch archive log) сервер, с которого будет осуществляться передача архивных журналов. Параметры fal_client и fal_server работают только когда база запущена в standby режиме.
standby_file_management=’AUTO’ – задаем режим автоматического управления файлами в standby режиме. При таком значении параметра все создаваемые или удаляемые файлы основной базы будут автоматически создаваться или удаляться и на standby базе.
Если мы все-таки хотим разместить нашу standby базу в каталогах, отличных от тех, в которых размещена основная база, нам понадобятся дополнительные параметры:
db_file_name_convert=’/oradata_new/test’,’/oradata/test’ – этот параметр указывает, что в именах файлов данных, которые будут создаваться в standby базе (т.е. когда наш основной экземпляр начнет работать в режиме standby), необходимо изменить пути с ‘/oradata_new/test’ на ‘/oradata/test’.
log_file_name_convert=’/oradata_new/test/archive’,’/oradata/test/archive’ – этот параметр указывает, что в именах журнальных файлов, которые будут создаваться в standby базе, необходимо изменить пути с ‘/oradata_new/test/archive’ на ‘/oradata/test/archive’.
В итоге файл параметров для основной базы помимо всего прочего должен иметь следующие записи:
# эти параметры нам понадобятся для работы в режимах PRIMARY и STANDBY
db_name=’test’
db_unique_name=’testprod’
log_archive_config=’dg_config=(testprod,teststan)’
log_archive_dest_1=’SERVICE=teststan LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=’teststan’ log_archive_dest_2=’LOCATION=/oradata/test/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=testprod’
log_archive_dest_state_1=ENABLE
log_archive_dest_state_2=ENABLE
# эти параметры нам понадобятся для работы только в режиме STANDBY
fal_client=’testprod’
fal_server=’teststan’
standby_file_management=’AUTO’
Если есть такая возможность, перезапускаем основную базу с новыми параметрами и создаем новый spfile на основе переработанного нами pfile:
SQL> shutdown immediate;
SQL> startup nomount pfile=’/data/backup/pfilePROD.ora’;
SQL> create spfile from pfile=’/data/backup/pfilePROD.ora’;
SQL> shutdown immediate;
SQL> startup;
Если у нас нет возможности остановить основную базу на время наших манипуляций, то придется вносить изменения в текущую конфигурацию с помощью ALTER SYSTEM.
Тут надо учитывать, что нам не удастся сменить db_unique_name на работающей базе. Поэтому, нам придется в конфигурации использовать то имя, которое есть на данный момент. Посмотреть его можно с помощью команды:
Задаем необходимые параметры:
SQL> alter system set log_archive_config=’dg_config=(test,teststan)’;
System altered.
Задаем места для записи архивных журналов. На работающей базе мы не сможем поправить параметр log_archive_dest_1, если он задан. Поэтому только добавляем направление копирования в standby базу:
SQL> alter system set log_archive_dest_2=’SERVICE=teststan LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=teststan’;
System altered.
SQL> alter system set log_archive_dest_state_2=ENABLE;
System altered.
SQL> alter system set FAL_SERVER=teststan;
System altered.
SQL> alter system set FAL_CLIENT=test;
System altered.
SQL> alter system set standby_file_management=’AUTO’;
System altered.
Добавляем в tnsnames.ora запись о standby базе:
TESTSTAN =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = standbysrv)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = teststan)
)
)
Пришло время создать backup-ы (если их нет). Для этого мы будем пользоваться утилитой rman.
Необходимо, чтобы место, где располагается бэкап, из которого мы будем разворачивать standby базу, было точно таким же, как и место, куда мы этот бэкап сохраняли. Т.е. если мы складываем бэкап в каталог ‘/data/backup’, то при восстановлении базы на standby-сервере rman будет искать данные бэкапа в таком же каталоге. Для решения этой задачи есть два очевидный пути: скопировать данные бэкапа с основного сервера на standby в точно такой же каталог, созданный там, или использовать для бэкапа сетевой ресурс, который одинаково монтируется на обоих серверах.
Запускаем rman на основном сервере:
$ rman target /
Создаем контрольный файл для standby базы:
RMAN> backup current controlfile for standby format ‘/data/backup/standbycontrol.ctl’;
Создаем бэкап нашей основной базы и архивных журналов:
RMAN> run
2> <
3> allocate channel c1 device type disk format ‘/data/backup/%u’;
4> backup database plus archivelog;
5> >
Здесь нас может поджидать неприятность, если по каким-то причинам у нас нет полного набора архивных журналов (например, они были удалены). Тогда rman выдаст ошибку:
RMAN-20242: Specification does not match any archivelog in the recovery catalog
Для исправления ситуации необходимо проверить и изменить статусы архивных журналов в репозитории rman. Для этого выполним следующую команду:
RMAN> change archivelog all crosscheck;
Если бэкап прошел успешно, копируем содержимое каталога /data/backup/ на standby сервер (если мы не использовали общий сетевой ресурс для бэкапа) и приступаем к созданию экземпляра на standby сервере.
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /oracle)
(PROGRAM = extproc)
)
(SID_DESC =
(GLOBAL_DBNAME = teststan)
(ORACLE_HOME = /oracle)
(SID_NAME = test)
)
)
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = standbysrv)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
)
)
Следует заметить, что параметр SID_NAME в данном случае чувствителен к регистру, т.к. listener будет искать файл паролей с именем orapw$SID_NAME.
Кстати, сейчас самое время скопировать файл паролей ($ORACLE_HOME/dbs/orapw$ORACLE_SID) с основного сервера на standby.
Нам также следует прописать нашу основную и standby базы в tnsnames.ora:
TEST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = standbysrv)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = teststan)
)
)
TESTPROD =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = productionsrv)(PORT = 1521))
)
(CONNECT_DATA =
(SID = test)
)
)
Т.к. подразумевается, что приложения «знают» нашу базу под именем test, то и для standby базы мы задаем SID test.
Не забываем перестартовать listener:
$ORACLE_HOME/bin/lsnrctl stop
$ORACLE_HOME/bin/lsnrctl start
Также нам необходимо создать на основе файлов параметров основной базы файл параметров для standby. Для этого перепишем на standby сервер файл pfilePROD.ora, переименовав его в pfileSTAN.ora, и внесем необходимые исправления в ту его часть, которую мы редактировали ранее:
# эти параметры нам понадобятся для работы в режимах PRIMARY и STANDBY
db_name=’test’
db_unique_name=’teststan’
log_archive_config=’dg_config=(testprod,teststan)’
log_archive_dest_1=’SERVICE=testprod LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=’testprod’ log_archive_dest_2=’LOCATION=/oradata/test/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=teststan’
log_archive_dest_state_1=ENABLE
log_archive_dest_state_2=ENABLE
# эти параметры нам понадобятся для работы только в режиме STANDBY
fal_client=’teststan’
fal_server=’testprod’
standby_file_management=’AUTO’
При размещении standby базы в других каталогах также добавляем необходимые параметры:
Пришло время стартовать standby экземпляр базы:
SQL> startup nomount pfile=’/data/backup/pfileSTAN.ora’;
SQL> create spfile from pfile=’/data/backup/pfileSTAN.ora’;
SQL> shutdown immediate;
SQL> startup nomount;
Разворачиваем standby базу из бэкапа. Для этого переходим на основной сервер и запускаем rman.
Подключаемся к будущей standby базе и выполняем дуплицирование (мы помним, что бэкап данных и контрольный файл у нас лежат в каталоге, который и с основного сервера и со standby виден как /data/backup):
RMAN> connect auxiliary sys@teststan
RMAN> duplicate target database for standby nofilenamecheck dorecover;
Параметр nofilenamecheck нам нужен, чтобы rman не ругался на повторяющиеся имена файлов (если мы используем одинаковую структуру каталогов на основном и standby серверах).
Если все прошло успешно, то переводим систему в режим автоматического применения транзакций на standby базе.
Переключаем журнальный файл и смотрим последний номер архивного журнала на основной базе:
SQL> alter system switch logfile;
System altered.
SQL> select max(sequence#) from v$archived_log;
Теперь переходим на standby сервер.
Проверяем состояние базы:
SQL> select name,open_mode,log_mode from v$database;
SQL> select max(sequence#) from v$log_history;
Мы видим, что последний примененный лог на standby отстает от основной базы, а также, что процессы ARCH не работают.
Проверяем наличие standby redo logs:
SQL> select * from v$standby_log;
Если их нет – создаем:
SQL> alter database add standby logfile group 4 ‘/oradata/test/stnbylog01.log’ size 50m;
Database altered.
SQL> alter database add standby logfile group 5 ‘/oradata/test/stnbylog02.log’ size 50m;
Database altered.
SQL> alter database add standby logfile group 6 ‘/oradata/test/stnbylog03.log’ size 50m;
Database altered.
Переводим нашу standby базу в режим Real-time apply redo:
SQL> alter database recover managed standby database using current logfile disconnect;
Смотрим, что получилось:
SQL> select recovery_mode from v$archive_dest_status;
RECOVERY_MODE
————————
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
SQL> select max(sequence#) from v$log_history;
Как видим, все работает.
Если мы не хотим использовать режим Real-time apply redo, а хотим дожидаться когда будет закончено формирование очередного архивного журнала на основном сервере и он будет передан на standby для применения сохраненных в нем транзакций, то нам необходимо переводить нашу standby базу в режим redo apply командой:
SQL> alter database recover managed standby database disconnect;
Если что-то пошло не так, то для решения проблемы в первую очередь необходимо остановить «накатку» логов:
SQL> alter database recover managed standby database cancel;
Возможно, что в процессе дуплицирования на standby сервер были переданы не все архивные журналы. Тогда их надо вручную скопировать на standby сервер (в нашем случае в каталог /oradata/test/archive), произвести ручную «накатку»:
SQL> recover standby database;
и после этого опять запустить режим Real-time apply redo:
SQL> alter database recover managed standby database using current logfile disconnect;
Процессы переключения ролей между экземплярами (switchover) и перевода standby базы в режим primary в случае падения основной базы (failover) имеют множество своих подводных камней, поэтому это тема отдельной статьи.