Shared Services Configuration/de

From OpenSimulator

(Difference between revisions)
Jump to: navigation, search
(→‎Schritte)
(→‎Discussion)
Line 152: Line 152:
 
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.
 
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=
+
=Diskussion=
  
−
==Disadvantages==
+
==Nachteile==
  
−
===Not supported===
+
===Nicht unterstützt===
−
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.
+
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.
  
−
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.
+
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===
 
===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).
+
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).
  
−
===Access control===
+
===Zugangskontrolle===
−
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.
+
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.
  
−
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.
+
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===
 
===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.
+
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.
  
−
On the other hand, if the friends service is not shared then users will have to manage a separate friends list on each server.
+
Wenn der Freundesdienst nicht freigegeben ist, müssen Benutzer auf jedem Server eine separate Freundesliste verwalten.  
  
−
==Advantages==
+
==Vorteile==
  
−
===Conceptually simpler than the Hypergrid===
+
===Konzeptionell einfacher als das 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.
+
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.
  
−
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.
+
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.  
  
−
===Scalability===
+
===Skalierbarkeit===
−
The scalability issue is complex here.
+
Das Problem der Skalierbarkeit ist hier komplex.
  
−
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.
+
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.
  
−
One could achieve this simply by sharing the asset service as above but none of the others.
+
Man könnte dies erreichen, indem man einfach den Asset-Service wie oben teilt, aber keinen der anderen.
  
−
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.
+
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.
  
 
[[Category:German Translations]]
 
[[Category:German Translations]]

Revision as of 16:24, 2 July 2018

Languages Languages: 

En.png English

Contents

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.

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.

Retrieved from "http://opensimulator.org/index.php?title=Shared_Services_Configuration/de&oldid=46279"
Personal tools
General
About This Wiki