Сравнение между базой данных кластера Oracle RAC (10gR2, 11gR2 и 12cR1) и развернутой базой данных Oracle в кластере Linux
Внедрение Oracle RAC может быть дорогостоящим для небольшого предприятия, но как это будет, если кластер Linux будет внедрен, а затем развернута стандартная база данных Oracle в этом кластере для достижения доступности, подобной Oracle RAC?
Можно ли добиться автоматического переключения при сбое, балансировки нагрузки и т. Д. В кластере Linux? Если один узел выходит из строя, служба БД Oracle будет обслуживать существующие и новые соединения?
Какие могут быть преимущества и недостатки?
1 ответ
Вопрос, скорее всего, привлечет ответы, основанные на мнении. Это одна из них.
Балансировка нагрузки не может быть легко доступна, если вы запускаете процесс Oracle DB как службу в кластере Red Hat. Лучшее, что вы можете сделать, когда дело доходит до кластеризации, это активный режим ожидания, т.е. в любой конкретный момент времени процессы БД Oracle выполняются только на одном из узлов кластера, а при сбое один из них переключается на другой. Даже это может оказаться довольно трудным для выполнения, хотя.
Причина, по которой сценарий балансировки нагрузки невозможен, заключается в том, что наличие более одного процесса Oracle DB, обращающегося к разделам данных без их ведома друг о друге, может повредить ваши данные. В настоящее время способ информировать узлы друг о друге на уровне базы данных Oracle - это купить RAC, поэтому они продают его.
Тем не менее, конфигурация активного ожидания может выглядеть примерно так: привязать процессы БД Oracle к дополнительному IP-адресу, который затем перемещается от узла к узлу со службой, т.е. IP-адрес службы, процессы базы данных Oracle и разделы данных являются службами в кластере Red Hat, проходя от узла к узлу при сбое. Сервисный IP дает вам одно преимущество: таким образом ваши клиенты могут восстановить соединение, когда один из узлов выходит из строя, а другой занимает его место. Тем не менее, все существующие соединения будут разорваны во время переключения в сценарии активного ожидания.
Помимо перечисленных выше недостатков, есть и другие проблемы, например, будет сложно получить поддержку от Oracle, если что-то пойдет не так, как вы думаете, сценарий, который вы считаете не совсем рекомендованным Oracle.
Подводя итог, возможно, было бы неплохо переосмыслить, и если вам действительно требуется балансировка нагрузки на уровне базы данных Oracle и тому подобное, вам, вероятно, лучше купить RAC, чем пытаться создать собственное решение, имитирующее некоторые из функций, предлагаемых RAC.