Où comment stocker les données de configuration distribuées

Question

Une seule installation de notre produit stocke sa configuration dans un ensemble de tables de base de données.

Aucune des installations «ne connaît» aucune autre installation.

Il a toujours été courant que les clients installent plusieurs copies de notre produit dans différents datacentres, qui sont géographiquement éloignés. Cela signifie que les informations de configuration doivent être créées une fois, puis exportées vers d'autres systèmes. Une partie de la configuration est ensuite modifiée pour s'adapter aux conditions locales. EG change les adresses IP, etc. Il s'agit d'une approche maladroite et sujette aux erreurs.

Nous obtenons maintenant des demandes de capacité à avoir une stratégie plus transparente pour partager les données mondiales, mais autoriser des modifications locales.

Si ce n'était pas pour le bit de modifications locales, nous pourrions utiliser les fonctionnalités de réplication des données d'Oracle.

En raison des exigences HA, la configuration de la base de données n'est pas une option.

Quelqu'un d'autre a-t-il rencontré ce problème et avez-vous déjà trouvé une bonne solution programmatique pour cela? Vous connaissez de bons papiers qui pourraient décrire une solution partielle ou complète?

Nous sommes basés sur le NIX et utilisons Oracle. Les modifications doivent être reproduites sur tous les nœuds assez rapidement (une seconde ou 2).

Answer 1

Je ne sais pas dans quelle mesure il est possible pour vous de changer la façon dont vous gérez votre configuration, mais nous avons implémenté quelque chose de similaire à cela en utilisant l'idée de remplacements locaux. Plus précisément, vous avez deux tables de configuration identiques (appelez-les CentralConfig et LocalConfig). CentralConfig est maintenu à l'emplacement central et est reproduit dans vos emplacements satellites, où il est en lecture seule. LocalConfig peut être configuré sur le site local. Votre procédure qui interroge les données de configuration recherche d'abord les données dans la table LocalConfig, et si elle n'est pas trouvée, la récupère à partir de la table CentralConfig.

Par exemple, si vous essayiez de le faire avec les valeurs dans la table des paramètres V $, vous pouvez interroger votre configuration en utilisant la fonction First_Value dans 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 colonne Localsort dans les syndicats est là juste pour s'assurer que les valeurs locales_paramètre ont priorité sur les valeurs des paramètres V $.

Dans notre système, c'est en fait beaucoup plus sophistiqué que cela. En plus du "nom" pour le paramètre que vous recherchez, nous avons également une colonne "Context" qui décrit le contexte que nous recherchons. Par exemple, nous pourrions avoir un "délai d'expiration" paramètre qui est défini au centre, mais même localement, nous avons plusieurs composants qui utilisent cette valeur. Ils peuvent tous être les mêmes, mais nous pouvons également vouloir les configurer différemment. Ainsi, lorsque l'outil recherche la valeur "délai d'expiration", il contraint également par la portée. Dans la configuration elle-même, nous pouvons utiliser les jokers lorsque nous définissons ce que nous voulons pour la portée, comme:

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

La configuration ci-dessus indique que, pour tous les composants, utilisent un délai d'expiration de 30, mais pour les moteurs de composition de tout type, utilisez un délai de 5, mais pour les moteurs de composition A&B, utilisez respectivement 15 et 10. Les deux dernières configurations peuvent être maintenues dans CentralConfig, mais les deux autres peuvent être maintenues dans LocalConfig, et vous résolvez les paramètres de cette façon:

  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;

C'est essentiellement la même requête, sauf que j'inserte cette expression traduit avant mon LocalSort et que je me libère sur le contexte. Ce qu'il fait, c'est de convertir les caractères% et _ en Chr (1) & Chr (2), ce qui les fera trier après les caractères alphanumériques dans le type descendant. De cette façon, le "moteur Comp MOTEUR explicitement défini A" sera avant "Comp Moteur%", qui à son tour viendra avant "%". Dans les cas où les contextes sont définis de manière identique, la configuration locale prit la priorité sur celles centrales; Si vous vouliez que local l'emporte toujours sur Central, même dans les cas où Central était plus étroitement étendu, vous inverseriez simplement les positions des deux termes de tri.

Answer 2

La façon dont nous faisons cela est similaire à celle de Steve. Vous avez d'abord besoin d'un service de configuration central pour enregistrer toute la configuration que vous souhaitez appliquer à l'environnement distribué. Chaque fois que vous souhaitez modifier la configuration, modifiez-la dans le service Central Configure. Dans chaque hôte de production, vous pouvez écrire un script de boucle pour mettre à jour la configuration. Pour une solution plus sophistiquée, vous devez configurer une stratégie pour éviter un mauvais lot de configuration dans tous les serveurs, ce serait une catastrophe. Vous avez peut-être besoin d'un verrou simple ou d'un processus de libération gris.