Внедрение Oracle RAC может быть дорогостоящим для небольшого предприятия, но как это будет, если будет реализован кластер Linux, а затем развернута стандартная база данных Oracle в этом кластере для достижения доступности, подобной Oracle RAC?

  • Можно ли добиться автоматического переключения при сбое, балансировки нагрузки и т.д. В кластере Linux? Если один узел выходит из строя, все равно служба БД Oracle будет обслуживаться существующими и новыми соединениями?

  • Какие могут быть преимущества и недостатки?

1 ответ1

1

Вопрос скорее всего привлечет ответы, основанные на мнении. Это одна из них.

Балансировка нагрузки не может быть легко доступна, если вы запускаете процесс Oracle DB как службу в кластере Red Hat. Лучшее, что вы можете сделать, когда дело доходит до кластеризации, это активный режим ожидания, т.е. в любой конкретный момент времени процессы БД Oracle выполняются только на одном из узлов кластера, а при сбое один из них переключается на другой. Даже это может оказаться довольно трудным для выполнения, хотя.

Причина, по которой сценарий балансировки нагрузки неосуществим в этом случае, заключается в том, что наличие более одного процесса Oracle DB, обращающегося к разделам данных без их ведома друг о друге, может повредить ваши данные. В настоящее время способ информировать узлы друг о друге на уровне БД Oracle - это купить RAC, поэтому они продают его.

Тем не менее, конфигурация активного ожидания может выглядеть примерно так: связать процессы БД Oracle с дополнительным IP-адресом, который затем перемещается от узла к узлу со службой, т.е. IP-адрес службы, процессы базы данных Oracle и разделы данных являются службами в кластере Red Hat, проходя от узла к узлу при сбое. Сервисный IP дает вам одно преимущество: таким образом ваши клиенты могут восстановить соединение, когда один из узлов выходит из строя, а другой занимает его место. Тем не менее, все существующие соединения будут разорваны во время переключения в сценарии активного ожидания.

Помимо недостатков, перечисленных выше, есть и другие проблемы, например, будет сложно получить поддержку от Oracle, если что-то пойдет не так, как вы думаете, сценарий, который вы не считаете рекомендованным Oracle.

Подводя итоги, можно подумать о том, чтобы пересмотреть решение, и, если вам действительно требуется балансировка нагрузки на уровне базы данных Oracle и т.д., Вам, вероятно, лучше купить RAC, чем пытаться создать собственное решение, имитирующее некоторые функции, предлагаемые RAC.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .