DB as a (self) service - gestion des conflits sur username
Bonjour,
Je souhaiterais savoir s'il existe une extension, un outil, une façon de modéliser mon infra ou toute autre alternative permettant de gérer dans le cadre de DB self-service les conflits sur les noms de users.
L'idée sur laquelle je pars pour l'instant est de mapper un user utilisé lors de la connexion à un role ayant un nom différent en DB, cela selon la source de connexion.
Exemple:
Existant :
Entreprise A - client1 : requêtes avec le rôle "toto" vers "db1"
Entreprise A - client2 : requêtes avec le rôle "toto" vers "db2"
Entreprise B - client3 : requêtes avec le rôle "toto" vers "db3"
Entreprise B - client4 : requêtes avec le rôle "toto" vers "db4"
Entreprise C - client5 : requêtes avec le rôle "toto" vers "db5"
Cible:
Mon cluster A - requêtes avec "toto" du client 1 sur "db1" -> mappé sur le role "cli1_toto"
Mon cluster A - requêtes avec "toto" du client 2 sur "db2" -> mappé sur le role "cli2_toto"
Mon cluster A - requêtes avec "toto" du client 3 sur "db3" -> mappé sur le role "cli3_toto"
Mon cluster B - requêtes avec "toto" du client 4 sur "db2" -> mappé sur le role "cli4_toto"
Mon cluster B - requêtes avec "toto" du client 5 sur "db5" -> mappé sur le role "cli5_toto"
Les pistes étudiées pour mon idée :
1. avec pg_ident.conf : ne convient pas, il ne s'agit pas de user OS + je ne sais pas distinguer client 1 de client 2 ou de client 3 (et donc mapper sur le bon rôle sur le même cluster)
2. avec pgbouncer : en cours d'étude (quitte à mettre 1 bouncer derrière chaque DB. Implémentation en cours de lecture : https://access.crunchydata.com/docum...ouncer_fdw.pdf)
3. autre à me proposer ?
Les autres pistes étudiées :
1. demander aux applis de modifier leur user : complexité + temps + coût ne le permettent pas (sans rentrer dans les détails, mais je crois que tout DBA a déjà fait face aux NoGo projets ^^)
2. faire 1 instance par client (donc plusieurs instances par cluster) : problématique de gestion des ressources + gestion du fencing sur le cluster (notamment sur le no-quorum-policy=suicide de pacemaker)
3. règle interdisant d'utiliser un username déjà existant : c'est faisable pour les nouvelles DB (même si difficile à vendre), mais pas pour les migrations
4. autre à me proposer ?
Pour info, mon infra :
- chaque cluster est composé de 3 noeuds physiques (1 noeud par DataCenter)
- cluster linux étendu piloté par pacemaker / corosync
- 1 master + 1 slave sync + 1 slave async
Des idées / pistes à me suggérer ?
Merci à vous
ps: la problématique pourrait être similaire avec les dbnames mais là, on a fait simple, on interdit 2 dbnames identiques sur un même cluster (par contre, il peut y en avoir des identiques sur des clusters différents)
