Shared Services Configuration/fr
From OpenSimulator
Introduction
Dans certains cas, nous aimerions avoir 2 installations de OpenSimulator ou plus, plutot qu'une grille large. Cependant, ceci crée des inconvénients majeurs si les utilisateurs tentent d'accéder aux deux grilles - un compte utilisateur a besoin d'être créé sur les deux et ils auraient deux inventaires totalement différents ( donc les vêtements, body parts et attachements )entre les installations de OpenSimulator.
une approche consiste à avoir un seul compte utilisateur sur une des grilles et autoriser l'utilisateur à voyager vers les autres grilles à travers Hypergrid.
Une autre approche (que nous allons détailler içi) consiste à partager les services de compte utilisateur, autentification, avatar, asset, entre les multiples installation mais pas les autres services comme grid ou griduser. Ceci autorisera alors les deux grilles à être séparées (l'une d'elles ne sera pas capable de téléporter entre les régions de différentes grilles) tandis qu'on pourra autoriser l'utilisateur à conserver le même compte, inventaire et attachements entre les multiples installations de OpenSimulator.
Cette approche doit être considérée comme expérimentale. Ceci n'est actuellement pas supporté par le projet OpenSimulator. Je l'ai vu utilisé avec succès dans quelques situations mais elle peut cacher des effets de bord causant des problèmes. -- Justincc (talk) 22:35, 30 April 2014 (UTC)
Etapes
Voici les étapes permettant de partager des services entre deux installations de OpenSimulator (Grille A et Grille B).
Nous allons faire les hypothèses suivantes
- Les deux installations sont exécutées en mode "grid".
- Chaque installation est hébergée sur une machine séparée ou un ensemble de machines. Si les deux installations sont sur la même machine alors vous aurez besoin d'ajuster les numéros de ports par défaut sur les services non partagés afin qu'ils ne crashent pas.
- Hypergrid est inactif.
- Grille A et Grille B s'exécutent sur le même réseau local. Les adresses des services ROBUST sont comme suit :
Grille A - 192.168.1.2 (8002 public port, 8003 private port) Grille B - 192.168.1.3 (8002 public port, 8003 private port)
Etape 1: Decider quelle installation de grille hébergera les services partagés
Une instance de grille ROBUST (ou plus dans des configurations sophistiquées) hébergera les sservices devant être partagés entre les installations multiples. La configuration des autres simulateurs et ROBUST sera changée pour utiliser les services partagés plutot que les siens. Dans ces instructions, la grille A abritera les services partagés.
Etape 2: Configurer les simulateurs sur la Grille B afin d'utiliser les services de la grille A
Sur la grille B, nous avons besoin de configurer les simulateurs afin qu'ils se connectent à la grille B pour quelques services mais garde la grille A pour les autres.
Les services que nous avons besoin de partager sont :
- Asset - pour partager les assets utilisés dans les éléments d'inventaires.
- Authentication - afin que les logins et mots de passe soient autentifiés à partir des mêmes infos de connexion.
- Avatar - pour partager l'information entre les attachements portés, les vêtements et les éléments du corps.
- Inventaire - pour partager les éléments d'inventaire.
- UserAccount - pour partager les informations utilisateur.
Pour faire cela, nous configurons le ServerURI dans chaque section de service applicable pour connecter les services de la grille A plutot que la grille B. Dans cet exemple, la configuration serait comme suit :
[AssetService] AssetServerURI = "http://192.168.1.2:8003" [AuthenticationService] AuthenticationServerURI = "http://192.168.1.2:8003" [AvatarService] AvatarServerURI = "http://192.168.1.2:8003" [InventoryService] InventoryServerURI = "http://192.168.1.2:8003" [UserAccountService] UserAccountServerURI = "http://192.168.1.2:8003"
Etape 3: Configurer le LoginService de la grille B pour utiliser les services de la grille A quand cela est approprié
Aussi bien que d'orienter les simulateurs de la grille B vers l'utilisation des services de la grille A, nous avons besoin de configurer le service de login de la grille B afin d'utiliser les services de la grille A.
Nous avons besoin de faire cela car le service de login consulte ces autres services soit pour autentifier l'utilisateur (services Authentication et UserAccount), soit pour obtenir des informations afin de générer la réponse de login (Avatar, Inventory).
La configuration içi est plus complexe car nous avons besoin de dire au service de login de la grille B d'utiliser des connecteurs afin d'accéder aux services de la grille A plutot que d'instancier ses propres services locaux.
Etape 3A: Configurer les Login Service pour utiliser des connecteurs afin de partager des services
Ceci est fait dans la section [LoginService] de Robust.ini. Plutot que de spécifier les services dans les DLL de services locaux, nous demandons aux service de login d'instancier des connecteurs.
Par exemple, la configuration habituelle de UserAccountService est :
[LoginService] UserAccountService = "OpenSim.Services.UserAccountService.dll:UserAccountService"
Ce qui instancie un service local de compte utilisateur depuis OpenSim.Services.UserAccountService.dll. Mais pour une configuration de connecteur, ceci devient :
[LoginService] UserAccountService = "OpenSim.Services.Connectors.dll:UserAccountServicesConnector"
Les sections de service de [LoginService] change de :
[LoginService] UserAccountService = "OpenSim.Services.UserAccountService.dll:UserAccountService" AuthenticationService = "OpenSim.Services.AuthenticationService.dll:PasswordAuthenticationService" InventoryService = "OpenSim.Services.InventoryService.dll:XInventoryService" AvatarService = "OpenSim.Services.AvatarService.dll:AvatarService"
vers :
[LoginService] UserAccountService = "OpenSim.Services.Connectors.dll:UserAccountServicesConnector" AuthenticationService = "OpenSim.Services.Connectors.dll:AuthenticationServicesConnector" InventoryService = "OpenSim.Services.Connectors.dll:XInventoryServicesConnector" AvatarService = "OpenSim.Services.Connectors.dll:AvatarServiceConnector"
Dans ce cas, nous n'avons pas besoin de configurer le service des assets puisque le service de login n'a pas besoin d'y accéder.
Nous ne pouvons pas non plus reconfigurer le service library puisqu'il n'a actuellement pas de connecteur. Alors les grilles connectées de cette manière doivent avoir des configuration identiques de la library.
Etape 3B: Configurer les connecteurs avec les URI des services de ROBUST de la grille A
Autant que d'obtenir que le login service utilise les connecteurs des services de la grille A, nous avons besoin de dire à ces connecteurs quels URI ils doivent utiliser. Ici la configuration est actuellement la même que pour le simulateur. Donc pour chacun des connecteurs que nous avons configurés auparavant, nous devons ajouter les entrées de ServerURI correspondantes.
Donc pour le service de user account, par exemple, nous devons ajouter
[UserAccountService] UserAccountServerURI = "http://192.168.1.2:8003"
Donc au total, les entrées suivantes ont besoin d'être ajoutées :
[AuthenticationService] AuthenticationServerURI = "http://192.168.1.2:8003" [AvatarService] AvatarServerURI = "http://192.168.1.2:8003" [InventoryService] InventoryServerURI = "http://192.168.1.2:8003" [UserAccountService] UserAccountServerURI = "http://192.168.1.2:8003"
Encore une fois, c'est la même chose que la configuration des simulateurs sauf que nous n'avons pas besoin de configurer le service des assets.
C'est aussi une bonne idée de commenter les entrées inutilisées de ces sections (comme LocalServiceModule). Elles ne feront surement pas de problème en étant présentes mais elles ne seront pas utilisées par les connecteurs.
Etape 3C: Désactiver les connecteurs non utilisés sur la grille B (optionnel)
Ceci est techniquement une étape optionnelle, mais je pense que c'est une tres bonne idée de désactiver les services de la grille B qui ne sont plus requis afin d'éviter des confusions si tout n'est pas bien configuré.
Pour faire cela, commenter les connecteurs rendus disponibles dans la section [ServiceList] du fichier Robust.ini de la grille B. Dans ce cas, ce sont les connecteurs de service qui sont rendus disponibles aux autres parties. Alors les connecteurs suivants devraient être commentés :
[ServiceList] ;InventoryInConnector = "8003/OpenSim.Server.Handlers.dll:XInventoryInConnector" ;AuthenticationServiceConnector = "8003/OpenSim.Server.Handlers.dll:AuthenticationServiceConnector" ;AvatarServiceConnector = "8003/OpenSim.Server.Handlers.dll:AvatarServiceConnector" ;UserAccountServiceConnector = "8003/OpenSim.Server.Handlers.dll:UserAccountServiceConnector" ;AvatarServiceConnector = "8003/OpenSim.Server.Handlers.dll:AvatarServiceConnector"
Conclusion
Vous devriez maintenant être capable d'utiliser le même compte avatar pour vous connecter sur la grille A (via http://192.168.1.2:8002 dans cet exemple) et sur la grille B (via http://192.168.1.3:8002). Les utilisateurs auront les mêmes détails utilisateur, inventaire et attachements sur les deux grilles. Cependant ces deux grilles sont encore conceptuellement séparées - les régions peuvent se supperposer (ex : la grille A et la grille B ont des régions différentes à 1000,1000à et il y a aucun moyen de se déplacer de l'une à l'autre sans avoir hypergrid activé.
Discussion
Inconvénients
Non supporté
Pour mettre l'accent sur ce qui a été dit en introduction, ceci n'est pas une configuration de OpenSimulator officiellement supportée par le projet. Etant donné que ce n'est pas souvent utilisé, vous pouvez vous retrouver avec des bugs et des problemes multiples liés à cette configuration inhabituelle. Les changements au fil du temps nécéssiteront des ajustement de configuration qui ne sont pas documentés autre part. Ceci veut aussi dire que cette configuration n'a pas été bien testée.
Ceci étant dit il n'y a pas de raison de penser que ceci s'arrêtera de fonctionner. Ceci repose sur les besoin fondamentaux de configuration de OpenSimulator (services distribués et connecteurs) qui sont nécéssaires aux autres fonctionnalités.
Hypergrid
Nous ne savons pas si Hypergrid fonctionnera avec cette configuration. Cela peut bien être possible quand chaque grille possède son propre service à partir d'une configuration supplémentaire nécessaire (comme définir les connecteurs).
Contrôle d'acces
Une fois que tout le monde possède un compte utilisateur, ils peuvent se déplacer entre les installations en partageant ces services. Il peut être possible de limiter cela avec un service non partagé d'autentification (ou bien une implémentation alternative) qui puisse contrôler si un utilisateur est autorisé à accéder à la grille A ou bien la grille B.
Sans cela, si vous avez besoin de contrôler les acces vous aurez besoin de faire cela soit par les options normales de configuration (comme les listes d'acces des régions) que vous utiliseriez sur une grille unifiée ou par Hypergrid qui a développé et développe des contrôles d'acces. Il serait aussi possible de renforcer certains contrôles d'acces par la configuration réseau d'un pare feux.
Service Friends
Si le service d'amis est partagé, alors les utilisateurs veront les amis étant sur l'autre grille. Ceci peut être déroutant car ils ne seront pas capables de communiquer avec eux car les ims sont routés seulement entre simulateurs de la même grille.
D'un autre côté, si le service friends n'est pas partagé alors les utilisateurs devront gérer une liste séparée d'amis sur chaque serveur.
Avantages
Conceptuellement plus simple que Hypergrid
L'avantage principal se rapporte à l'autre mécanisme (l'hypergrid) pour autoriser les utilisateurs à garder les mêmes détails du compte utilisateur sur des grilles différentes. Contrairement à hypergrid, il n'y a pas de concept non-Second Life à comprendre comme le suitcase de l'inventaire ou les liens hypergrid.
Cependant cette approche n'autorise par un utilisateur à se déplacer entre les grilles tant qu'il ne se déconnecte pas d'une grille pour se connecter sur l'autre, même si ces grilles utilisent les mêmes détails d'autentification.
Evolutivité
Le problème d'évolutivité est complexe içi.
D'un côté, si on a plusieurs grilles avec les comptes/inventaires partagés plutot qu'une seule grande grille, les services partagés rendront encore l'evolutivité possible. Par exemple, si quelqu'un utilise un service d'assets de déduplication alors la déduplication sera active sur les différentes grilles en partageant le service d'assets plutot qu'avoir deux copies potentielles du même asset sur les différentes grilles.
On pourrait faire cela en partageant simplement le service d'assets comme au dessus mais pas les autres.
Cependant, cette même concentration de requetes dans un service partagé peut entrainer des problemes de mise à l'échelle nécéssitant des techniques de Performance pour dimensionner les services partagés. Ceci ne devrait pas être un problème si les grilles sont complètement séparées ou si la connectivité de la grille a été faite par Hypergrid, dans le cas où les deux grilles conservent leur propres instances de services.
