J'utilise actuellement IDS4 en tant qu'instance unique dans une région (base de données unique pour la configuration et le magasin opérationnel). Je dois maintenant distribuer l'installation dans deux régions afin que les services / utilisateurs de la région A accèdent à l'IDS dans la région A et les services / utilisateurs de la région B accèdent à l'IDS dans la région B.
Les deux instances doivent accéder au même magasin de données, mais IDS de la région B ne devrait pas avoir à effectuer de requêtes de lecture interrégionales dans la base de données de la région A.
Nous utilisons Azure SQL Server et la fonctionnalité de géoréplication qui offre une seule instance accessible en écriture (dans la région A ou B) et plusieurs instances lisibles. Nous avons pointé IDS dans la région B vers une instance en lecture seule dans la même région, mais cela ne fonctionne pas car IDS doit écrire des données opérationnelles comme des octrois persistants.
Existe-t-il une architecture recommandée pour y parvenir ou avez-vous une expérience dans la mise en œuvre d'un déploiement IDS multirégional et à charge équilibrée? Est-il possible de configurer IDS pour utiliser une base de données différente pour les opérations d'écriture et la base de données dans la même région pour les opérations de lecture?
3 Réponses :
Il est peu probable que vous trouviez une architecture recommandée pour un scénario comme celui-ci en raison de l'ampleur de ce problème dans votre domaine professionnel. De plus, il n'y a rien de prêt à l'emploi dans la bibliothèque Identity Server 4 ou ses bibliothèques de prise en charge qui répondrait à vos critères.
Cela dit, j'ai une exigence similaire (sans rapport avec Identity Server 4 mais des exigences fonctionnelles identiques en un mot) et il devrait être possible d'adapter la même idée dans votre cas.
Premièrement , votre seul problème comme vous l'avez dit est le fait qu'en utilisant le package EF d'Identity Server 4, le PersistedGrantStore utilise un IPersistedGrantDbContext qui écrit et lit à partir de la base de données. Donc, pour résoudre ce problème, vous devez essentiellement créer votre propre implémentation de IPersistedGrantStore et dans cette implémentation personnalisée, vous pouvez techniquement utiliser deux types de DbContext différents, dont l'un serait créé en utilisant une chaîne de connexion à une seule instance inscriptible de la base de données et ne serait utilisé que pour implémenter des méthodes d'interface qui font des écritures et une autre serait utilisée pour les méthodes de lecture uniquement et utiliserait une chaîne de connexion pour une instance en lecture seule de la base de données.
L'idée de base du résumé ci-dessus est ci-dessous:
public class MyCustomPersistedGrantStore : IPersistedGrantStore
{
private readonly WriteOnlyPersistedGrantDbContext _writeContext;
private readonly ReadOnlyPersistedGrantDbContext _readContext;
public PersistedGrantStore(WriteOnlyPersistedGrantDbContext writeContext, ReadOnlyPersistedGrantDbContext readContext)
{
_writeContext = writeContext;
_readContext = readContext;
}
public Task StoreAsync(PersistedGrant token)
{
//Use _writeContext to implement storage logic
}
public Task<PersistedGrant> GetAsync(string key)
{
//Use _readContext to implement read logic
}
...other interface methods
}
Après avoir implémenté votre version personnalisée, il vous suffit d'ajouter votre implémentation de IPersistedGrantStore comme ainsi que les DbContext dans le système DI.
Enfin, il est intéressant de noter que si vous arrêtez d'utiliser .AddOperationalStore (... config) code > alors vous perdez également l'utilisation de TokenCleanupHostService , vous devrez donc l'implémenter également.
@lunzi Vous avez marqué cela comme la réponse acceptée, mais vous avez commenté la réponse d'Alberto Morillo selon laquelle vous l'avez fait fonctionner en utilisant sa suggestion. Comme nous avons le même problème, je me demandais ce que vous aviez fini par faire.
Au lieu de la géoréplication, vous pouvez utiliser Azure SQL Data Sync pour avoir des réplicas inscriptibles d'Azure SQL Database, en définissant l'un d'entre eux comme base de données concentrateur et les autres comme base de données membre. La synchronisation entre toutes les bases de données peut être configurée de manière bidirectionnelle ainsi toutes les bases de données peuvent être mises à jour. Vous pouvez commencer à configurer Azure SQL Data Sync sur cette documentation.
Nous avons réussi à configurer la synchronisation des données entre les deux bases de données et cela fonctionne très bien. Contrairement à la réplication de données en temps quasi réel de la géoréplication Azure SQL, la synchronisation des données ne se réplique que toutes les 5 minutes. Je me demande si cela pourrait conduire à des situations problématiques. En fonctionnement normal, un utilisateur frappe toujours la même région et donc la même base de données. En cas de basculement, le pire des cas serait que l'utilisateur doive s'authentifier de nouveau car l'attribution persistante n'a pas été synchronisée. Toutes les autres données (par exemple, les données de configuration) seront synchronisées une fois que la région sera à nouveau disponible.
Sur la fréquence de synchronisation, vous pouvez choisir les secondes. "Si vous choisissez Activé, entrez un nombre et sélectionnez Secondes, Minutes, Heures ou Jours dans la section Fréquence de synchronisation." Cliquez ici pour en savoir plus sur le paramètre "Synchronisation automatique". docs.microsoft.com/en-us/azure/sql-database/...
J'ai déjà vérifié les documents et il est dit: La durée minimale entre les synchronisations est de cinq minutes.
Je suis en train de résoudre les problèmes dans mon propre fork privé de IdentityServer4. Contrib.CosmosDB . Si vous jetez un œil au code source atm (très inachevé), vous comprendrez approximativement comment implémenter votre propre fournisseur de base de données qui gère avec grâce une telle exigence. En fait, vous voudrez peut-être penser hypothétiquement à l'utilisation d'une banque de données NoSQL pour IDServer, car je pense qu'il est `` optimisé '' pour les lectures / écritures multirégionales par rapport à SQL Server.
Bienvenue à SO. Veuillez prendre une minute pour lire stackoverflow.com/help/how-to-ask