Shared Services Configuration/de
From OpenSimulator
 |
Languages: |
|
Einführung
In einigen Szenarios können zwei oder mehr separate Installationen von OpenSimulator anstelle von einem großen Raster gewünscht werden. Dies führt jedoch zu großen Unannehmlichkeiten, wenn Benutzer Zugriff auf beide Grids benötigen - auf beiden muss ein Benutzerkonto erstellt werden, und sie haben zwischen OpenSimulator-Installationen ein völlig anderes Inventar (und damit Kleidung, Körperteile und Anhänge).
Ein Ansatz besteht darin, ein einziges Benutzerkonto in einem der Grids zu haben und es dem Benutzer zu ermöglichen, über das Hypergrid zu anderen Grids zu reisen.
Ein weiterer Ansatz, den wir hier näher erläutern werden, ist die gemeinsame Nutzung von Benutzerkonten, Authentifizierungs-, Avatar-, Asset- und Inventardiensten zwischen mehreren Installationen, jedoch nicht mit anderen Diensten wie dem Grid oder Griduser. Dadurch können die beiden Grids getrennt bleiben (eine Region kann nicht zwischen Regionen auf verschiedenen Grids teleportieren), während der Benutzer die gleichen Kontodetails, Inventar und Anhänge zwischen mehreren OpenSimulator-Installationen beibehalten kann.
Dieser Ansatz sollte als experimentell betrachtet werden. Es wird derzeit vom OpenSimulator-Projekt nicht offiziell unterstützt. Ich habe gesehen, dass es in einigen Situationen erfolgreich verwendet wurde, aber es kann durchaus Fälle geben, die Probleme verursachen. -- Justincc (talk) 22:35, 30 April 2014 (UTC)
Schritte
Dies sind Schritte zum Freigeben von Diensten zwischen zwei separaten OpenSimulator-Installationen (Grid A und Grid B).
Wir machen folgende Annahmen
- Beide Installationen werden im Rastermodus ausgeführt.
- Jede Installation wird auf einem separaten Computer oder einer Gruppe von Computern gehostet. Wenn sich beide Installationen auf demselben Computer befinden, müssen Sie die Standardportnummern für nicht gemeinsam genutzte Dienste anpassen, damit sie nicht miteinander kollidieren.
- Hypergrid ist inaktiv.
- Grid A und Grid B werden im selben lokalen Netzwerk ausgeführt. Die ROBUST-Dienstadressen lauten wie folgt.
Grid A - 192.168.1.2 (8002 public port, 8003 private port) Grid B - 192.168.1.3 (8002 public port, 8003 private port)
Schritt 1: Entscheiden Sie, welche Grid-Installation die gemeinsamen Dienste hosten soll
Die ROBUST-Instanz eines Gitters (mehr in ausgeklügelten Setups) hostet die Dienste, die von mehreren Installationen gemeinsam genutzt werden. Die Simulator- und ROBUST-Konfiguration des anderen Gitters wird so geändert, dass die Shared-Services statt der eigenen verwendet werden. In diesen Anweisungen wird Grid A die gemeinsamen Dienste hosten.
Schritt 2: Konfigurieren Sie die Simulatoren in Grid B, um die Dienste von Grid A zu verwenden
In Grid B müssen die Simulatoren so konfiguriert werden, dass sie für einige Diensttypen mit Grid B verbunden sind, für andere jedoch mit Grid A.
Die Dienste, die geteilt werden müssen, sind
- Asset - Zum Freigeben von Inhalten, die in Inventarobjekten verwendet werden.
- Authentifizierung - damit Login-Passwörter gegen die gleichen gespeicherten Hashes authentifiziert werden.
- Avatar - um Informationen über getragene Befestigungen, Kleidung und Körperteile zu teilen.
- Inventar - um Inventargegenstände zu teilen.
- UserAccount - um Benutzerkontoinformationen zu teilen.
Um dies zu tun, konfigurieren wir die ServerURI in jedem relevanten Dienstabschnitt, um eine Verbindung zu den Grid A-Diensten statt zu Grid B herzustellen. In diesem Beispiel wäre die Konfiguration wie folgt
[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"
Schritt 3: Configure Grid B's LoginService to use Grid A services where appropriate
Neben der Umleitung der Simulatoren von Grid B auf die Dienste von Grid A müssen wir den Anmeldungsdienst von Grid B so konfigurieren, dass die Dienste von Grid A verwendet werden.
Wir müssen dies tun, da der Login-Service diese anderen Dienste konsultiert, um entweder den Benutzer zu identifizieren und zu authentifizieren (Authentation- und UserAccount-Dienste) oder Informationen zu erhalten, um die Login-Antwort zu füllen (Avatar, Inventar).
Die Konfiguration hier ist komplexer, da wir dem Grid B-Login-Dienst mitteilen müssen, dass Connectors für den Zugriff auf die Dienste von Grid A verwendet werden sollen, anstatt seine eigenen lokalen Dienstinstanzen zu instanziieren.
Schritt 3A: Konfigurieren Sie den Anmeldungsdienst für die Verwendung von Connectors für gemeinsame Dienste
Dies geschieht im Abschnitt [LoginService] von Robust.ini. Anstatt Services in lokalen Service-DLLs anzugeben, bitten wir den Login-Service, Connectors zu instanziieren.
Zum Beispiel ist die übliche UserAccountService-Konfiguration hier
[LoginService] UserAccountService = "OpenSim.Services.UserAccountService.dll:UserAccountService"
der einen lokalen Benutzerkontodienst von der OpenSim.Services.UserAccountService.dll instanziiert. Aber für eine Steckerkonfiguration. das wird
[LoginService] UserAccountService = "OpenSim.Services.Connectors.dll:UserAccountServicesConnector"
Insgesamt ändern sich die Servicebereiche von [LoginService] von
[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"
zu
[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"
In diesem Fall müssen wir den Asset-Dienst nicht konfigurieren, da der Anmeldedienst nicht darauf zugreifen muss.
Wir können den Bibliotheksdienst auch nicht neu konfigurieren, da er derzeit keinen Connector hat. Daher müssen die auf diese Weise verbundenen Gitter identische Bibliothekskonfigurationen haben.
Schritt 3B: Konfigurieren Sie die Anschlüsse mit den ROBUST-Service-URIs von Grid A.
Neben dem Login-Dienst, Connectors für die Services von Grid A zu verwenden, müssen wir den Connectors mitteilen, welche URIs verwendet werden sollen. Die Konfiguration ist hier die gleiche wie für den Simulator. Daher müssen wir für jeden der oben konfigurierten Konnektoren den entsprechenden ServerURI-Eintrag hinzufügen.
Also müssen wir zum Beispiel für den Benutzerkontodienst hinzufügen
[UserAccountService] UserAccountServerURI = "http://192.168.1.2:8003"
Insgesamt müssen also folgende Einträge hinzugefügt werden
[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"
Auch hier gilt dasselbe wie für die obige Konfiguration des Simulators, mit der Ausnahme, dass der Asset-Service nicht konfiguriert werden muss.
Es ist auch eine gute Idee, alle anderen Einträge in diesen Abschnitten (zB LocalServiceModule) zu kommentieren. Sie werden sehr wahrscheinlich keinen Schaden anrichten, wenn sie da sind, aber sie werden nicht von den Anschlüssen benutzt.
Schritt 3C: Deaktivieren Sie nicht verwendete Anschlüsse in Grid B (optional)
Dies ist technisch ein optionaler Schritt, aber ich denke, dass es eine sehr gute Idee ist, die Grid B-Dienste, die nicht mehr benötigt werden, zu deaktivieren, um Verwirrung zu vermeiden, wenn etwas falsch konfiguriert wird.
Um dies zu tun, kommentiert man die im Abschnitt [ServiceList] der Datei robust.ini von Grid B zur Verfügung gestellten Konnektoren aus. In diesem Fall sind dies Dienstverbindungen, die anderen Parteien zur Verfügung gestellt werden. Die folgenden Konnektoren sollten daher auskommentiert sein.
[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"
Fazit
Sie sollten nun dasselbe Avatar-Konto verwenden können, um sich bei Grid A (in diesem Beispiel http://192.168.1.2:8002 ) und bei Grid B (über http://192.168.1.3:8002 ) anzumelden. Benutzer haben die gleichen Details, Inventar und abgenutzte Gegenstände / Anhänge auf beiden Gittern. Diese Gitter sind jedoch immer noch konzeptionell getrennt - Regionen können sich überlappen (z. B. Gitter A und Gitter B haben unterschiedliche Regionen bei 1000, 1000), und es gibt keine Möglichkeit, sich direkt zwischen ihnen zu bewegen, ohne dass Hypergrid aktiv ist.
Discussion
Disadvantages
Not supported
To emphasise what was said in the introduction, this is not a configuration of OpenSimulator officially supported by the project. As it's not commonly used, you may run into bugs or other issues associated with this unusual setup. Changes over time may require configuration adjustment that is not documented elsewhere. It also means that this configuration is not well tested.
Having said that, there's no reason to think that this will stop working. It relies on fundamental configuration requirements for OpenSimulator (distributed services and connectors) which are necessary for other functionality.
Hypergrid
It's unknown whether Hypergrid will work on this configuration. It may well be possible when each grid has its own service, though extra configuration will definitely be required (e.g. setting up connectors).
Access control
Once somebody has a user account they can move indiscrimnately between the installations sharing those services. It might be possible to limit this with a non-shared authentication service (or even an alternative authentication service implementation) that can control whether a user is allowed access to only Grid A or Grid B.
Without this, if you need to access control you will need to do this either via the normal configuration options (e.g. region access lists) that you would use on a unified grid, or via Hypergrid instead which does have developed and developing access controls. It might also be possible to enforce some access control via network firewall configuration.
Friends Service
If the friends service is shared, then users will see friends who are at other grids. This may be confusing, since they won't be able to communicate with them as IMs are routed only to simulators in the same grid.
On the other hand, if the friends service is not shared then users will have to manage a separate friends list on each server.
Advantages
Conceptually simpler than the Hypergrid
The chief advantage relates to the other mechanism (the Hypergrid) for allowing users to keep the same account details and inventory on different grids. Unlike the Hypergrid, there are no non-Second Life concepts to understand, such as inventory suitcases or Hypergrid links.
However, this approach doesn't allow a user to move between grids unless they logout from one grid and login back to another, even though those grids use the same account and authentication details. This makes it quite difficult to imagine scenarios where the naive service sharing described above is useful.
Scalability
The scalability issue is complex here.
On the one hand, if one has to have multiple grids with shared user accounts/inventory rather than a single big grid, sharing services will still make efficiencies of scale possible. For instance, if one is using a deduplicating asset service, then deduplication will occur over multiple grids sharing an asset service instead of potentially having two copies of the same asset in 2 different grids.
One could achieve this simply by sharing the asset service as above but none of the others.
However, this same concentration of requests into a shared service may be a scalability problem, requiring the techniques in Performance to scale the shared services. This would not be an issue if the grids were completely separate or if the grid connectivity was achieved via Hypergrid, where both grids retain their own service instances.
