Onde Como armazenar dados de configuração distribuídos

Question

Uma única instalação de nossos produtos armazena sua configuração em um conjunto de tabelas de banco de dados.

Nenhuma das instalações 'sabe' sobre qualquer outra instalação.

Sempre foi comum os clientes instalarem várias cópias do nosso produto em diferentes datacentros, que estão geograficamente distantes. Isso significa que as informações de configuração precisam ser criadas uma vez e depois exportadas para outros sistemas. Parte da configuração é então modificada para se adequar às condições locais. Por exemplo, alterações de endereços IP, etc. Esta é uma abordagem desajeitada e propensa a erros.

Agora estamos recebendo pedidos de capacidade de ter uma estratégia mais perfeita para compartilhar dados globais, mas ainda permitindo modificações locais.

Se não fosse o bit de modificações locais, poderíamos usar os recursos de replicação de dados da Oracle.

Devido aos requisitos de HA ter toda a configuração no banco de dados One não é uma opção.

Alguém mais encontrou esse problema e você já descobriu uma boa solução programática para isso? Conhece algum bom documento que possa descrever uma solução parcial ou completa?

Estamos *baseados em nix e usamos o Oracle. As alterações devem ser replicadas para todos os nós rapidamente (um segundo ou 2).

Answer 1

Não tenho certeza de como é possível mudar a maneira como você lida com sua configuração, mas implementamos algo semelhante a isso usando a idéia de substituições locais. Especificamente, você tem duas tabelas de configuração que são idênticas (chame -as de CentralConfig e LocalConfig). O CentralConfig é mantido no local central e é replicado em seus locais de satélite, onde é somente leitura. LocalConfig pode ser configurado no site local. Seu procedimento, que consulta os dados de configuração, procura primeiro os dados na tabela LocalConfig e, se não for encontrado, recupera -os da tabela CentralConfig.

Por exemplo, se você estava tentando fazer isso com os valores na tabela V $ parâmetro, poderá consultar sua configuração usando a função First_Value no 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;

A coluna Localsort nos sindicatos existe apenas para garantir que os valores LOCAL_PARAMETER tenham precedência sobre os valores dos parâmetros V $.

Em nosso sistema, na verdade é muito mais sofisticado do que isso. Além do "nome" do parâmetro que você está procurando, também temos uma coluna "contexto" que descreve o contexto que estamos procurando. Por exemplo, podemos ter um parâmetro "Timeout" que é definido centralmente, mas mesmo localmente, temos vários componentes que usam esse valor. Todos podem ser iguais, mas também podemos querer configurá -los de maneira diferente. Portanto, quando a ferramenta procura o valor "Timeout", também restringe o escopo. Na própria configuração, podemos usar curingas quando definirmos o que queremos para o escopo, como:

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

A configuração acima diz que, para todos os componentes, use um tempo limite de 30, mas para mecanismos de comp compensação de qualquer tipo, use um tempo limite de 5, no entanto, para os mecanismos de compactos A&B, use 15 e 10, respectivamente. As duas últimas configurações podem ser mantidas no CentralConfig, mas as outras duas podem ser mantidas no LocalConfig, e você resolveria as configurações da seguinte maneira:

  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;

É basicamente a mesma consulta, exceto que estou inserindo que traduz a expressão antes do meu local de local e estou restringindo o contexto. O que está fazendo é converter os caracteres % e _ em Chr (1) e Chr (2), o que os fará classificar após caracteres alfanuméricos no tipo descendente. Dessa forma, o mecanismo de comp explicitamente definido "virá antes de" Comp Engine %", que por sua vez virá antes de" %". Nos casos em que os contextos são definidos de forma idêntica, a configuração local tem precedência sobre os centrais; Se você quisesse que o local sempre fugisse central, mesmo nos casos em que a Central era com mais força, você apenas reverteria as posições dos dois termos de classificação.

Answer 2

A maneira como estamos fazendo isso é semelhante à de Steve. Primeiro, você precisa de um serviço de configuração central para salvar toda a configuração que deseja aplicar no ambiente distribuído. Toda vez que você deseja modificar a configuração, modifique -a no serviço de configuração central. Em cada host de produção, você pode escrever um script de loop para atualizar a configuração. Para uma solução mais sofisticada, você precisa configurar alguma estratégia para evitar um lote de configuração errada em todos os servidores, isso seria um desastre. Talvez você precise de um bloqueio simples ou um processo de liberação cinza.