Donde\Cómo almacenar la configuración distribuida de datos

Question

Una sola instalación de nuestro producto se almacena la configuración en un conjunto de tablas de base de datos.

Ninguna de las instalaciones de "saber" acerca de cualquier otro tipo de instalación.

Siempre ha sido común para los clientes a instalar varias copias de nuestros productos en los diferentes centros de datos, los cuales se encuentran geográficamente distantes.Esto significa que la información de configuración se debe crear de una vez, y luego exportados a otros sistemas.Algunos de los config se modifica para adaptarse a las condiciones locales.por ejemplo,el cambio de direcciones IP, etc.Este es un torpe, propenso al error de aproximación.

Ahora estamos recibiendo las solicitudes de la capacidad para tener una estrategia uniforme para el intercambio de datos a nivel mundial, pero sigue permitiendo modificaciones locales.

Si no fuera por las modificaciones locales bits, entonces podríamos usar Oracle de datos de las características de la replicación.

Debido a los requisitos HA de tener toda la configuración en la base de datos no es una opción.

Ha nadie se encontraron con este problema y has encontrado una buena solución programática para esto?Saben de alguna buena papeles que podría describir una parcial o completa de la solución?

Estamos basados en *nix, y el uso de Oracle.Los cambios deben ser replicado en todos los nodos con bastante rapidez (una o 2 segundos).

Answer 1

No estoy seguro de lo posible que sea que cambie la forma en que maneja su configuración, pero implementamos algo similar a esto utilizando la idea de las anulaciones locales. Específicamente, tiene dos tablas de configuración que son idénticas (llámalas CentralConfig y LocalConfig). CentralConfig se mantiene en la ubicación central y se replica en sus ubicaciones satelitales, donde solo es de lectura. LocalConfig se puede configurar en el sitio local. Su procedimiento que consulta los datos de configuración primero busca los datos en la tabla LocalConfig, y si no se encuentra, lo recupera de la tabla CentralConfig.

Por ejemplo, si intentaba hacer esto con los valores en la tabla de parámetros V $, podría consultar su configuración utilizando la función First_Value en SQL Analytics:

  SELECT DISTINCT
         NAME
       , FIRST_VALUE(VALUE) OVER(PARTITION BY NAME 
                                     ORDER BY localsort
                                ) VALUE
    FROM (SELECT t.*
               , 0 localsort
            FROM local_parameter t
           UNION
          SELECT t.*
               , 1 localsort
            FROM v$parameter t
         )
ORDER BY NAME;

La columna Localsort en los sindicatos está allí solo para asegurarse de que los valores locales_parameter tengan prioridad sobre los valores del parámetro V $.

En nuestro sistema, en realidad es mucho más sofisticado que esto. Además del "nombre" para el parámetro que está buscando, también tenemos una columna de "contexto" que describe el contexto que estamos buscando. Por ejemplo, podríamos tener un "tiempo de espera" de parámetro que se establece centralmente, pero incluso localmente, tenemos múltiples componentes que usan este valor. Todos pueden ser los mismos, pero también es posible que deseemos configurarlos de manera diferente. Entonces, cuando la herramienta busca el valor de "tiempo de espera", también se limita por alcance. En la configuración en sí, podemos usar comodines cuando definimos lo que queremos para el alcance, como:

CONTEXT       NAME    VALUE
------------- ------- -----
Comp Engine A timeout    15
Comp Engine B timeout    10
Comp Engine % timeout     5
%             timeout    30

La configuración anterior dice, para todos los componentes, use un tiempo de espera de 30, pero para motores de compensación de cualquier tipo, use un tiempo de espera de 5, sin embargo, para los motores COMP A&B, use 15 y 10 respectivamente. Las dos últimas configuraciones se pueden mantener en CentralConfig, pero las otras dos pueden mantenerse en LocalConfig, y usted resolvería la configuración de esta manera:

  SELECT DISTINCT
         NAME
       , FIRST_VALUE(VALUE) OVER(PARTITION BY NAME 
                                     ORDER BY (TRANSLATE(Context
                                                        , '%_'
                                                        , CHR(1) || CHR(2)
                                              ) DESC
                                            , localsort
                                ) VALUE
    FROM (SELECT t.*
               , 0 localsort
            FROM LocalConfig t
           WHERE 'Comp Engine A' LIKE Context
           UNION
          SELECT t.*
               , 1 localsort
            FROM CentralConfig t
           WHERE 'Comp Engine A' LIKE Context
         )
ORDER BY NAME;

Básicamente es la misma consulta, excepto que estoy insertando que traduzca la expresión antes de mi lugar de locales y estoy limitando en el contexto. Lo que está haciendo es convertir el % y _ caracteres a chr (1) y chr (2), lo que los hará ordenar después de los caracteres alfanuméricos en el tipo descendente. De esta manera, el "motor Comp Motor A" Comp a "Comp Motor %", que a su vez vendrá antes " %". En los casos en que los contextos se definen de manera idéntica, la configuración local tiene prioridad sobre los centrales; Si quisiera que el local siempre triunfe a Central, incluso en los casos en que Central se alcanzó con más fuerza, simplemente revertiría las posiciones de los dos términos de tipo.

Answer 2

La forma en que estamos haciendo esto es similar con la de Steve. Primero necesita un servicio de configuración central para guardar toda la configuración que desea aplicar al entorno distribuido. Cada vez que desea modificar la configuración, modifíquela en el servicio de configuración central. En cada host de producción, puede escribir un script de bucle para actualizar la configuración. Para una solución más sofisticada, debe configurar una estrategia para evitar un lote de configuración incorrecto en todos los servidores, eso sería un desastre. Tal vez necesite un bloqueo simple o un proceso de lanzamiento gris.