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: Konfigurieren Sie den LoginService von Grid B so, dass er ggf. die Dienste von Grid A verwendet
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.
Diskussion
Nachteile
Nicht unterstützt
Um zu betonen, was in der Einleitung gesagt wurde, ist dies keine Konfiguration von OpenSimulator, die offiziell vom Projekt unterstützt wird. Da es nicht häufig verwendet wird, können Fehler oder andere Probleme auftreten, die mit dieser ungewöhnlichen Konfiguration zusammenhängen. Änderungen im Laufe der Zeit erfordern möglicherweise Konfigurationsanpassungen, die an anderer Stelle nicht dokumentiert sind. Es bedeutet auch, dass diese Konfiguration nicht gut getestet wurde.
Abgesehen davon gibt es keinen Grund zu der Annahme, dass dies nicht mehr funktionieren wird. Es basiert auf grundlegenden Konfigurationsanforderungen für OpenSimulator (verteilte Dienste und Konnektoren), die für andere Funktionen erforderlich sind.
Hypergrid
Es ist unbekannt, ob Hypergrid mit dieser Konfiguration arbeitet. Es kann durchaus möglich sein, dass jedes Gitter seinen eigenen Dienst hat, obwohl eine zusätzliche Konfiguration auf jeden Fall erforderlich ist (z. B. Einrichten von Anschlüssen).
Zugangskontrolle
Sobald jemand ein Benutzerkonto hat, kann er sich ohne Unterschied zwischen den Installationen bewegen, die diese Dienste teilen. Es könnte möglich sein, dies durch einen nicht gemeinsam genutzten Authentifizierungsdienst (oder sogar eine alternative Authentifizierungsdienstimplementierung) zu begrenzen, der steuern kann, ob ein Benutzer nur Zugriff auf Grid A oder Grid B erhält.
Ohne dies müssen Sie, wenn Sie auf die Steuerung zugreifen müssen, dies entweder über die normalen Konfigurationsoptionen (z. B. Bereichszugriffslisten) tun, die Sie in einem einheitlichen Grid verwenden, oder über Hypergrid, das Zugriffskontrollen entwickelt und entwickelt hat. Es könnte auch möglich sein, eine Zugangskontrolle über eine Netzwerk-Firewall-Konfiguration zu erzwingen.
Friends Service
Wenn der Freundesdienst freigegeben ist, werden Benutzer Freunde sehen, die sich in anderen Grids befinden. Dies kann verwirrend sein, da sie nicht mit ihnen kommunizieren können, da IMs nur an Simulatoren im selben Grid weitergeleitet werden.
Wenn der Freundesdienst nicht freigegeben ist, müssen Benutzer auf jedem Server eine separate Freundesliste verwalten.
Vorteile
Konzeptionell einfacher als das Hypergrid
Der Hauptvorteil bezieht sich auf den anderen Mechanismus (das Hypergrid), mit dem Benutzer die gleichen Kontodetails und das gleiche Inventar in verschiedenen Grids beibehalten können. Im Gegensatz zum Hypergrid gibt es keine Nicht-Second-Life-Konzepte wie Inventarkoffer oder Hypergrid-Links.
Dieser Ansatz ermöglicht es einem Benutzer jedoch nicht, sich zwischen den Rastern zu bewegen, es sei denn, sie melden sich von einem Raster ab und melden sich wieder an, auch wenn diese Raster dieselben Konto- und Authentifizierungsdetails verwenden. Dies macht es ziemlich schwierig, sich Szenarien vorzustellen, in denen die oben beschriebene naive Dienstfreigabe nützlich ist.
Skalierbarkeit
Das Problem der Skalierbarkeit ist hier komplex.
Auf der einen Seite, wenn man mehrere Grids mit gemeinsamen Benutzerkonten / Inventar anstelle eines einzelnen großen Grids haben muss, werden Sharing-Services immer noch Skaleneffekte ermöglichen. Wenn Sie beispielsweise einen deduplizierenden Asset-Service verwenden, erfolgt die Deduplizierung über mehrere Grids, die einen Asset-Service gemeinsam nutzen, anstatt potenziell zwei Kopien des gleichen Assets in zwei verschiedenen Grids zu haben.
Man könnte dies erreichen, indem man einfach den Asset-Service wie oben teilt, aber keinen der anderen.
Dieselbe Konzentration von Anforderungen in einem gemeinsam genutzten Dienst kann jedoch ein Skalierbarkeitsproblem sein, das die Performance erfordert, um die gemeinsam genutzten Dienste zu skalieren. Dies wäre kein Problem, wenn die Grids vollständig getrennt wären oder wenn die Grid-Konnektivität über Hypergrid erreicht würde, wobei beide Grids ihre eigenen Dienstinstanzen beibehalten.
