 |
Gridmodis in Opensim
- Hilfe bei der Auswahl der nach Anwendungsfall am besten geeigneten.
Opensim ist eine sehr flexible Konstruktion für unterschiedliche Bedürfnisse.
Diese unterschieden sich hinsichtlich Installationsaufwand, Flexibilität, Hardwarebedarf, Kosten, Ausbaufähigkeit und natürlich der geplanten Nutzung.
Was für den Profi Flexibilität bietet macht aber den Anfänger das Leben schwer.
Daher eine kurze Einführung in die Gridmodis von Opensim bezüglich der Auswahl und Konfiguration.
Ausdrücklich lasse ich alle anderen Wahlmöglichkeiten weg.
Folgende Betriebsmodi kennt Opensim:
1. Standalone :
Eine mini Testinstallation auf einem Rechner mit einer Instanz (ohne eigene Robust) und maximal ca. 4 Sims, ohne Hypergrid Anschluß.
Anwendungsfall: Ein Testrechner daheim ohne Internetzugang. Ein Mesh Entwicklungs Rechner um Uploadkosten in Sl zu sparen.
Performance: schlecht da nicht skalierbar. Alle Dienste (Griddienste, und alle Sims) laufen in einer einzigen gemeinsamen Instanz.
Für das gesamte Opensim Set kann aber nur genau ein Core einer CPU verwendet werden!!!!
Benutzte Konfig Dateien
(im Ordner config-include) : Standalone.ini und Standalone.common.ini
( im Ordner bin): Opensim.ini
Bewertung: Den standalone Gridmodus nutze man wirklich nur für lokale private Sandboxen und kleine Entwicklungs/Test Umgebungen.
Er macht nur Sinn wenn man auf eine "richtige" Datenbank verzichtet um einfache Backups durch kopieren der gesamten Ordnerstruktur durchzuführen.
Dann bleibt dieser Ordner auch super portabel. Man kann so die gesamte Installation auf USB Medium zwischen Rechnern und Standorten bewegt werden oder Snapshots durch kopieren anlegen.
Typisch sind da 1-2 Avatare und maximal bis zu 4 Sims. Darüber leidet die Performance massive da für alles zusammen nur 1 Core verwendet wird.
Dafür benötigt diese einfache Umgebung keinen eigenen Rechner. Es reicht eine VM oder die Ausführung am gleichen Rechner der den Viewer startet.
Nachteil: Nicht Wachstumsfähig, geringe Performance die ab 2 Sims einbricht, kein Hypergird Material. Administration selbst zu erbringen. Nicht geeignet für mehrere Nutzer.
Vorteil: Unabhängigkeit, gesicherte Testumgebung ohne äußere Einflüsse, leichte Backup, wenig Konfiguration, keine SQL Datenbank.
-------------------------------------
2. Standalone Hypergrid: (wie Standalone, jedoch nun mit Hypergrid Anschluß).
Anwendungsfall: Typisch ein Rechner daheim am privaten DSL Anschluß.
Man hat bis ca 4 Sim, wenig Performance da nur 1 Core verwendet wird, kann aber im Hypergrid rumspringen.
Performance: schlecht da nicht skalierbar. Alle Dienste (Griddienste, und alle Sims) laufen in einer einzigen gemeinsamen Instanz.
Für das gesamte Opensim Set kann wieder nur genau ein Core einer CPU verwendet werden!!!!
Benutzte Konfig Dateien
(im Ordner config-include) : StandaloneHypergrid.ini und Standalone.common.ini
( im Ordner bin): Opensim.ini
Bewertung: Dieses System ist typisch für eine private 1-Personen Opensim Umgebung die nicht ständig am Netz ist, und nur bei Bedarf gestartet wird,
Das ist sicher die einfachste (Konfiguration) und billigste Möglichkeit (Internet, variable IP, keine Domäne, Rechner, Strom) um am Opensim Geschehen teilzunehmen und ein bissl selber zu bauen.
Typisch ist dafür ein eigener zusätzlicher (alter) Rechner zuhause der bei Bedarf gestartet wird. Es kann aber auch eine Mitnutzung eines performanteren Systems sein auf dem der Viewer läuft.
Nachteil: Nicht Wachstumsfähig, geringe Performance die ab 2 Sims einbricht. Administration selbst zu erbringen. Wenig geeignet für mehrere Nutzer.
Vorteil: Unabhängigkeit, leichte Backup, mittlere Konfiguration, keine SQL Datenbank, daheim betreibbar, geringe Kosten.
-------------------------------------
3. Grid: Ein mittleres bis großes abgeschottetes Grid ohne Hypergrid Zugang.
Anwendungsfall: Ein abgeschlossenes Grid wie SL mit eigenen Benutzern und eigenem Kontent. Es ist keine Interaktion mit anderen Grids möglich.
Eine Anwendung im Schulungscenter, Schule etc ist denkbar, wo die User von externen Einflüssen im Internet abgeschirmt werden sollen.
Performance: sehr gut skalierbare Performance, da (mindestens) eine separate Robust Instanz für Griddienste verwendet wird,
und je Sim einen eigene Instanz möglich ist. Ausserdem kommt die viel performantere MYSQL Datenbank zum Einsatz.
So wird die Last über mehrere Cores verteilt, und bei Bedarf sogar über mehrere Server skaliert.
Benutzte Konfig Dateien ist unterschiedlich ob Robust Instanz oder SIM Instanz:
( im Ordner config-include) : Grid.ini und Grid.common.ini
( in SIM Instanzen im Ordner bin): Opensim.ini
( in Robust Instanz im Ordner bin): robust.ini
Bewertung: Wer viele User oder viele Sims hat, aber nicht mit anderen in Kontakt kommen will wird in diesem Gridmodell glücklich.
Die Performance ist beliebig skalierbar. Das Grid kann sich über eine oder mehrer Datenbanken erstrecken. Ausserdem können mehrer Server die Sims hosten.
Dafür wird aber unbedingt eine vollwertige Datenbank wie MYSQL benötigt. Auch eine Feste IP ist Pflicht. Sim Instanzen und Robust Instanz kommunizieren über IP.
Typisch ist dafür die Anmietung mindestens eines Servers im Rechenzentrum, oder hosting im eigenen Unternehmen / Schulungsbetrieb, etc.
Nachteil: beschränkte Attraktivität. Useranzahl und Materialauswahl ist viel geringer als im Gridverbund. Hohe Verantwortung, hoher Pflegeaufwand für Backups, Datenbank Pflege, IT Sicherheit, Verwaltung. ggf. Kosten für Internetanbindung, Servermiete, Administration.
Hoher Aufwand bei Gridumstellung und Hardwareumzug durch MYSQL Datenbank(en).
Vorteil: skalierbare gute Performance, fremd gemanagtes System für unbedarfte User
-------------------------------------
4. Grid Hypergrid: Ein mittleres bis großes Grid mit Hypergrid Zugang.
Dieses ist die gebräuchlichste, scalierbarste und damit zukunftsfähigste Gridform in Opensim.
Anwendungsfall: Technisch ähnlich wie Gridmodus, jedoch dürfen User (frei) mit anderen Grids interagieren.
Material und Nachrichten können ausgetauscht werden.
Und es ist möglich fremde Sim Instanzen an das eigene Grid anzubinden.
Letzteres ist ein Sonderfall, wo alle Avatar Dienste zentral bereit gestellt weden, jedoch die Siminstanzen dezentral auf eigenen Resourcen betrieben werden.
Beispiel ist OSGrid wo man eigene Sims "andocken" kann.
Performance: Wie Gridmodus, super und breit skalierbar. Das Grid kann bei Wachstum beliegig erweitert werden.
Benutzte Konfig Dateien:
( im Ordner config-include) : Hypergrid.ini und Grid.common.ini
( in SIM Instanzen im Ordner bin): Opensim.ini
( in Robust Instanz im Ordner bin): robust.hg.ini
Bewertung: Flexibelste wachstumsfähige Installation. Aber die Verantwortung des Administrators wächst mit der Userzahl.
Es braucht einen Profi der sich um Datensicherheit, Datenbankpflege, Konfiguraton, Backups, Userprobleme und nicht zu vergessen IT Sicherheit kümmert.
Fehler im System treffen viele und sind schmerzlich. Beispiel halbjähriger OSG Ausfall wegen Datenverlust bei RAID Problem.
Nachteil: hohe Verantwortung, hoher Pflegeaufwand für Backups, Datenbank Pflege, IT Sicherheit, Verwaltung. Kosten für Internetanbindung, Servermiete, Administration. Hoher Aufwand bei Gridumstellung und Hardwareumzug durch MYSQL Datenban(en).
Vorteil: skalierbare hohe Performance, fremd gemanagtes System für unbedarfte User, maximale User Flexibilität.
-------------------------------------
5. und 6. Simian und SimianHypergrid: Proprietäres Grid, wird nicht mehr unterstützt seit Version 0.9.2
-------------------------------------
KONFIGURATION:
Wenn man sich für das geeignete Grid entschieden hat, gilt es diese Auswahl dem Simulator in der Konfiguration mitzuteilen.
Dazu muss man wissen das diese Gesamtkonfiguration (um es den Admins zu erleichtern) in etliche verschiedenen Dateien verteilt wurde.
Diese orientieren sich grob an dem Gridmodus (mit/ohne separater Robust Instanz, mit/ohne Hypergrid Unterstützung)
Es könnten aber auch alle gewählten Einstellungen in eine Datei kopiert werden.
Diese einzelnen Konfig (.ini) Dateien werden in einer festgelegen (aber beeinflussbaren) Reihenfolge aufgerufen.
Dabei werden jeweils Variablen definiert und mit Werten belegt.
Duch den Aufruf nacheinander ist es vorgesehen das ein und dieselbe Variable an verschiedenen Stellen unterschiedliche Werte zugewiesen bekommt, und die zuletzt aufgerufenen Stelle vorhergehende Werte überschreibt.
Grob gesagt geschieht dies folgendermaßen in jeder Instanz (mit Ausnahme der Robust Instanz!):
Zuerst wird im bin Verzeichnis die "default" Datei aufgerufen (OpenSimDefaults.ini) und die Werte belegt.
Danach die Spezifikations .ini Datei (Opensim.ini) in der ihr unpassende default Werte durch eure gewünschte eigene Konfiguration überschreibt.
In dieser Opensim.ini gibt es einen Aufruf zu den ausgelagerten Grid Modi Konfigurations Dateien.
Diese befinden sich in der Opensim.ini unter:
[Architecture]
Include-Architecture = "Wert"
Wobei Wert je nach dem oben gewählten Gridmode auf das Verzeichnis und die zugehörige Config Datei hinweist:
1. Include-Architecture = "config-include/Standalone.ini"
2. Include-Architecture = "config-include/StandaloneHypergrid.ini"
3. Include-Architecture = "config-include/Grid.ini"
4. Include-Architecture = "config-include/GridHypergrid.ini"
An dieser Stelle könnt ihr ablesen in welchem Modus euer Simulator läuft!
Also überschreibt diese jeweilige Datei bereits vorhandene Einträge der Variablen aus den vorhergenannten 2 Dateien
Die Dateien je Modus, habe ich ja oben in der Modi Beschreibung schon angegeben.
Wir sehen also das die 3. aufgerufenen Konfig Datei die "spezielle" pro Gridmodus ist.
Am Anfang dieser Dateien befindet sich dann jeweils wieder ein Aufruf auf ihre zugehörige "Common" Datei.
Es gibt davon aber nur 2 Unterschiedliche:
1.) und 2.) nutzen die StandaloneCommon.ini
3.) und 4.) nutzen die GridCommon.ini
da in den Dateien Standalone.ini, StandaloneHypergrid.ini, Grid.ini, GridHypergrid.ini der Aufruf der Common Datei am Anfang steht wird wohl diese Common jeweils zuerst ausgeführt.
Dies Konstrukt gibt es pro "Nicht Robust" Instanz". Die Dateien unterschiedlicher Instanzen sollten sich nicht widersprechen.
In meinem Grid sind sie bis auf die Portnummern und die Region Dateien identisch gehalten, was die Pfelge erleichtert.
Nun das Konstrukt ist flexibel ,aber hochgradig verwirrend.
Man braucht sich nicht zu wundern wenn gesetzte Parameter dann wieder überschrieben werden.
Ausserdem verwirren unbenötigte brachliegende Dateien zusätzlich.
Daher mein Tip: Beim Aufsetzten des Grids vorab überlegen welchen Gridmodus man will,
und von den in diesem Artikel genannten, nicht benötigte inis, und .default Vorlagen löschen was nicht benötigt wird.
Ausserdem macht euch eine externe Doku welche Optionen wie konfiguriert sind, dies braucht ihr spätestens beim nächsten Opensim Versionsupdate.
Dies gilt für alle "Nicht Robust" Instanzen.
ROBUST INSTANZ :
In der Robust Instanz wird die Robust.ini oder die Robust.HG.ini verwendet (je ob ohne oder mit Hypergrid)
Diese schaut nach weiteren nachzuladenden Konfig Dateien in das Verzeichnis "robust-include"
ConfigDirectory = "robut-include"
Ich habe keinen Aufruf in der robust Instanz auf weiterere (Gridmodus-) Config Dateien gefunden.
Somit ist insbesondere egal was in der Opensim.ini der Robust Instanz drin steht.
So- das wars im Groben.
Es ist verwirrend, und erfordert große Ordnung
Aber es ist kein Hexenwerk wenn man die Zusammenhänge kennt.
|
