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