Моя организация хочет централизованно управлять файлом Oracle TNSnames для всех своих производственных серверов. Когда этот файл изменяется, они хотят иметь возможность распространять изменения на все серверы, которые его используют, с минимальными усилиями.
Рассмотренные подходы:
Обновить Могу ли я использовать для этого DFS?
Это не вопрос Oracle. Это канонический вариант использования инструмента управления конфигурацией, такого как puppet, bcfg2, cfengine, chef и т. Д. (Из них, по крайней мере, puppet имеет некоторую поддержку для управления машинами Windows, а также unix)
Апелляций, с вашей точки зрения, для данного конкретного случая несколько:
Обратной стороной, конечно же, является то, что вам необходимо научиться запускать / настраивать систему управления конфигурацией. Конечно, поступая так, вы, вероятно, найдете много, много других применений, которые сделают вашу среду и администрирование более эффективными.
Поскольку TNSNames не блокируется при использовании сервера, попробуйте выполнить задание cron или запланированную задачу на каждом сервере, который обновляет файл каждые X минут / часов.
Изменить: источником обновления должен быть файловый сервер (CIFS, NFS и т.д.), доступный со всех серверов Oracle. Вы также можете настроить сценарий, чтобы уведомлять вас, если файл не обновляется, хотя сбой будет просто означать отсутствие обновления вместо отсутствия критического файла на ваших серверах баз данных.
Храните отдельную копию файла на каждом сервере (недостаток: изменение содержимого файла требует внесения изменений на многих разных серверах)
Тем не менее, я бы пошел с этим. Напишите сценарий, который читает список серверов для доступа, возможно, с методом управления ОС / входом в систему, который зависит от поля. Альтернативно, Кукольный аналогичным образом можно использовать для передачи файлов конфигурации в Linux или Windows. Puppet также будет изменять версию и регистрировать изменения файла.
Централизованный файловый сервер (недостаток: если файловый сервер или сетевое соединение с файловым сервером выходит из строя, серверы не имеют доступа к критическому файлу)
Вы можете разместить резервные серверы с переключением IP при отказе, но это не решит сетевых проблем. Я бы не стал считать это сильным решением для вашей одноцелевой задачи.
Клиент Subversion на каждом сервере (недостаток: использование инструмента контроля версий в производстве, дополнительная сложность)
Вам все равно нужно будет написать сценарий или отправить запрос на перенос на каждый сервер. Однако я не вижу внутренних недостатков «инструмента управления исходным кодом в производстве».
Для систем Windows должен работать объект групповой политики для копирования файлов из общей папки. Это будет работать и для Linux, если вы используете Centrify, Likewise и т. Д.
Для Linux вы уже используете какую-то систему подготовки? (например, Spacewalk, RHSS) Это лучший вариант для централизованного управления файлами конфигурации.
Вы также можете использовать для этого DFS - это должно исправить отсутствие избыточности, если в корне DFS есть более одного файлового сервера. На машинах Linux вам понадобится SMB-клиент, поддерживающий DFS; Я не знаю, легко ли это / бесплатно / невозможно / ошибочно.