17.04.2020, 21:07
(Dieser Beitrag wurde zuletzt bearbeitet: 19.04.2020, 09:29 von Jules Dreki.)
Gleich an erster Stelle ein dickes Dankeschön an Copper Tomsen und Eryn Galen vom Metropolis-Grid die mich mit dem Folgenden sehr unterstützt haben.
Mir schwebt als eigene Region eine Flug-Sim vor. Es soll eine performante Region sein, und genügend Platz zum Fliegen bieten. Da das Thema neu für mich ist, war ich mir völlig im Unklaren, was für einen Server ich benötigen würde.
Von Manfred Aabye kam eine erste Abschätzung was man für so eine Sim minimal benötigen würde:
V-Server mit 8Cores und 30GB RAM für eine var16x16 = 4096m x 4096m
Eine var16x16 oder var8x8 erschien mir aber für einen lokalen Test als überdimensioniert, und ich entschied mich diesen mit einer var4x4 durchzuführen. Zunächst musste aber erst die Hürde der Installation der Metropolis-Edition des OpenSimulator und die Nutzung der 64Bit Variante gemeistert werden.
Im MetroWiki gibt es eine Anleitung zur Installation des OpenSimulator, also ging ich frisch und optimistisch ans Werk. https://hypergrid.org/metropolis/wiki/de...?title=SIM
Der Download und das Entpacken der Metropolis-Edition des OpenSimulator war schnell erledigt. Das .NET-Framework in der Version 4.8 war unter Windows 10 bereits installiert, und durch die Verwendung der Metropolis-Edition musste ich mich um das Thema dynDNS nicht kümmern. Wie sich später zeigte war auch das Thema NAT-Loopback mit der Fritz!Box 6490 Cable kein Problem.
Entsprechend der Anleitung und Lenas Beitrag zur neuen Metro gab ich in der Fritzbox die folgenden Ports frei. Ausserdem sorgte ich dafür das der lokale Firewall kein Hindernis für die opensim32.exe und opensim.exe sein würde. https://forum.metrogrid.de/discussion/50...neue-metro
TCP: 80
UDP+TCP: 9000
UDP+TCP: 9051
Dann suchte ich mir mit Hilfe des Dashboards noch freie Koordinaten. Da meine lokale Region nicht ständig online sein würde, wählte ich Koordinaten weit ab der 7000,7000. Damit war der letzte Schritt der Vorbereitung problemlos abgeschlossen, und die Installation selbst erforderte nur das Entpacken der Metropolis-Edition. SQLite sollte als Datenbank beibehalten werden also blieb die Datei ./opensim/bin/config-include/GridCommon.ini unverändert. Gestützt auf die Anleitung und der Beispieldatei Regions.ini.example ertstellte ich nur eine regions.ini für meine Region:
[Midgard]
RegionUUID = XXXXXXXXXXXX
Location = 490,500
InternalAddress = 0.0.0.0
InternalPort = 9051
AllowAlternatePorts = False
ExternalHostName = SYSTEMIP
SizeX = 1024
SizeY = 1024
SizeZ = 1024
NonPhysicalPrimMax = 256
PhysicalPrimMax = 64
ClampPrimSize = False
MaxPrims = 250000
MaxAgents = 100
Als Erstes startete ich dann die opensim32.exe. Der Simulator lief fehlerlos hoch, und Coppers und mein Avatar konnten die Region betreten. Bingo, das war ermutigend. Von der folgenden Seite besorgte ich etliche 256mx256m grosse OARs von Linda Kelly die auf die Region geladen werden sollten.
https://zadaroo.com/oars/
Das ging allerdings quälend langsam, und das permanente Abspeichern schien nicht zu funktionieren. Wie ich aber jetzt von Eryn weiss, gelangen die OAR-Daten zunächst nur in den Cache, und man muss mit dem Befehl "backup" für eine Übertragung in die Datenbank sorgen. Was auch wieder quälend langsam ging.
Neustart der Region nach OAR Upload/Bauen:
1. "backup"
2. "shutdown"
@Eryn: Ich habe das unter Missachtung aller Pausen direkt hintereinander ausgeführt, sobald der Prompt wieder erschien. Trotz aller gegenteiliger Erwartungen funktionierte das.
Da nun die 32Bit Version des OpenSimulators nur mit 4GB RAM (2^32=42949672996) umgehen kann, und die Datenbank SQLite deutlich langsamer als MySQL/MariaDB ist. Sollte nun, auf Eryns Rat hin, der Wechsel zum 64Bit Opensimulator und der Datenbank MariaDB erfolgen.
https://mariadb.org/download/
Zum Wechsel zur 64Bit Variante des Opensimulators muss man statt der opensim32.exe einfach nur die opensim.exe starten. Aber genau das funktionierte nicht ohne Fehlermeldung.
(ERROR - OpenSim.Framework.Servers.HttpServer.BaseHttpServer
[BASE HTTP SERVER]: HandleRequest() threw exception System.FormatException: Die Eingabezeichenfolge hat das falsche Format)
Die Lösung war zum Glück im Metro-Forum zu finden. Pius Noels erster Beitrag im 4.Absatz unter dem folgenden Link: https://forum.metrogrid.de/discussion/co...ment_33408
Also fügte ich in der Datei ./bin/OpenSim.exe.config den folgenden Eintrag im Abschnitt <runtime> hinzu.
<useLegacyJit enabled="1" />
Danach erfolgte die Installation der MariaDB Datenbank. Unter Windows startet man dafür einfach nur das Setup-Programm. Ich habe darauf geachtet das Root-Zugriffe nur lokal erfolgen dürfen und die Datenbank für die Verwendung des UTF8 Zeichensatzes eingerichtet wird. Für die Konfiguration der Datenbank bin ich der Anleitung Maretas gefolgt.
https://hyperweb.eu/server/ubuntu1804/mysql/
Dabei gleich ein Tip, wählt für den user der opensim Datenbank ein Passwort ohne Sonderzeichen. Ihr werdet gleich sehen warum. Nachdem die neue Datenbank lief musste nun der Opensimulator entsprechend der Anleitung im MetroWiki noch auf diese Datenbank umkonfiguriert werden.
https://hypergrid.org/metropolis/wiki/de...figuration
Dabei muss die Zeile für die SQLite Datenbank auskommentiert und die folgenden Zeilen für MySQL aktiviert werden.
StorageProvider = "OpenSim.Data.MySQL.dll"
ConnectionString = "Data Source=localhost;Database=Opensim;User ID=Opensim Password=****;Old Guids=true;"
Wenn ihr Euch jetzt den ConnectionString anschaut müsste klar werden, warum Passwörter mit Sonderzeichen speziell mit Anführungszeichen nicht funktionieren können. :-) Anführungszeichen im Passwort bringen die Syntax des Strings völlig durcheinander. An dieser Stelle war dann auch mein 64Bit Opensimulator mit der MariaDB lauffähig, und ich konnte mich um den Upload der OARs kümmern. Dafür gibt es mehre interessante Links:
http://opensimulator.org/wiki/Load_Oar_0.9.0+
http://opensimulator.org/wiki/Varregion
http://opensimulator.org/wiki/OpenSim_Archives
Als Erstes bin ich wieder genau der Anleitung gefolgt.
load oar oar00.oar
load oar oar01.oar --displacement "<0,256,0>" --merge --force-terrain --force-parcels
load oar oar10.oar --displacement "<256,0,0>" --merge --force-terrain --force-parcels
load oar oar11.oar --displacement "<256,256,0>" --merge --force-terrain --force-parcels
Dabei kommt es aber zu einem unschönen Fehler.
[LAND MANAGEMENT MODULE]: Cannot add parcel "Western Town", local ID 2 at tile 0,0 because this is still occupied by parcel "Your Parcel", local ID 1 in Midgard
Auch hierfür fand sich die Lösung im Metro-Forum in einem Beitrag von Pius Noel unter dem folgenden Link.
https://forum.metrogrid.de/discussion/50...egionen/p2
Es kommt leider dazu, daß für eine Parzelle aufeinmal zwei Namen in der Datenbank stehen und einer muss gelöscht werden. Dafür logge ich mich auf der Datenbankkonsole ein:
mysql -u root --password
Danach führt man die folgenden SQL Befehle aus, und löscht so den Namen "Your Parcel". Dabei muss die UUID des Namens "Your Parcel" verwendet werden:
SELECT UUID,Name FROM opensim.land;
DELETE FROM opensim.land where UUID = '11111111-2222-3333-4444-555555555555';
Schwierig könnte das mit der integrierten SQLite Datenbank werden, ich weiss momentan nicht ob man da überhaupt eine Konsole aufrufen kann. Aber man kann das Problem von vornherein vermeiden. Wenn man den OAR Load-Befehl für die erste Region verändert:
load oar oar00.oar --displacement "<0,0,0>" --merge --force-terrain --force-parcels
load oar oar01.oar --displacement "<0,256,0>" --merge --force-terrain --force-parcels
load oar oar10.oar --displacement "<256,0,0>" --merge --force-terrain --force-parcels
load oar oar11.oar --displacement "<256,256,0>" --merge --force-terrain --force-parcels
Das Nette bei dieser Art des OAR Uploads ist es, das die ursprünglichen Sim-Namen als Parzellennamen erhalten bleiben. Ich habe dabei erst alle Regionen auf diese Weise hochgeladen, und erst danach mit allen neuen Regionen zusammen den Befehl "backup" und anschliessend ein "shutdown" ausgeführt. Das dauert dann natürlich trotz 64Bit System eine geraume Zeit. Das Ergebnis der ganzen Bemühungen ist ein System der folgenden Spezifikation:
CPU 10 Cores
RAM 64GB
upload: 12MBit/s
Var4x4 Region
ca. 92000 Prims
ca. 5500 Skripte
Normalerweise hatte ich vor mit einem geskripteten Auto auf der Sim herumzufahren, und zu schauen ob das flüssig geht. Bei den ersten Tests hab ich das aber aufgegeben. Nicht weil der PC an seine Grenzen war, die Upload Bandbreite von 12Mbit/s war der Flaschenhals. Die Datenrate ging immer wieder bis ans Limit und dann begann es natürlich leicht zu ruckeln. Der PC selbst war recht unbeeindruckt. Bei den folgenden Zahlen darf man aber nicht vergessen, daß auf dem PC noch der Viewer und andere auf einem Desktop übliche Programme wie ein Virenscanner liefen.
- 9GB belegter RAM
- im Mittel 15-20% CPU Last
- CPU Spitzenlast ca. 30%
Es ist jetzt natürlich schwierig hochzurechnen welcher Server bei einer var8x8 oder var16x16 notwendig ist. Geht man nur jeweils von einer Verdoppelung aus? Oder muss man doch berücksichtigen das eine Verdoppelung der Seitenlängen eine Vervierfachung der Fläche bedeutet? Ich denke das ein System entsprechend der Empfehlung Manfreds oben ein guter Startpunkt ist. Wenn ich allerdings seinen Beitrag genau lese, und meine Ergebnisse berücksichtige, ist seine Server Konfiguration eine Minimalforderung für eine Var16x16, sollte meiner Meinung nach aber für ein Var8x8 gut funktionieren.
https://www.gridtalk.de/showthread.php?t...5#pid41585
Aufgrund meines Ergebnisses ziehe ich die folgenden Konfigurationen in Betracht:
A) var8x8: V-Server 8Cores 32GB
B) var16x16: V-Server 16Cores 60GB
Da man V-Server leicht upgraden können sollte, könnte man natürlich auch mit dem kleineren System beginnen, und wenn es notwendig ist, den V-Server später upgraden. Soweit zu den technischen Gesichtspunkten. Mal sehen was das liebe Geld noch dazu sagen wird. :-)
Mir schwebt als eigene Region eine Flug-Sim vor. Es soll eine performante Region sein, und genügend Platz zum Fliegen bieten. Da das Thema neu für mich ist, war ich mir völlig im Unklaren, was für einen Server ich benötigen würde.
Von Manfred Aabye kam eine erste Abschätzung was man für so eine Sim minimal benötigen würde:
V-Server mit 8Cores und 30GB RAM für eine var16x16 = 4096m x 4096m
Eine var16x16 oder var8x8 erschien mir aber für einen lokalen Test als überdimensioniert, und ich entschied mich diesen mit einer var4x4 durchzuführen. Zunächst musste aber erst die Hürde der Installation der Metropolis-Edition des OpenSimulator und die Nutzung der 64Bit Variante gemeistert werden.
Im MetroWiki gibt es eine Anleitung zur Installation des OpenSimulator, also ging ich frisch und optimistisch ans Werk. https://hypergrid.org/metropolis/wiki/de...?title=SIM
Der Download und das Entpacken der Metropolis-Edition des OpenSimulator war schnell erledigt. Das .NET-Framework in der Version 4.8 war unter Windows 10 bereits installiert, und durch die Verwendung der Metropolis-Edition musste ich mich um das Thema dynDNS nicht kümmern. Wie sich später zeigte war auch das Thema NAT-Loopback mit der Fritz!Box 6490 Cable kein Problem.
Entsprechend der Anleitung und Lenas Beitrag zur neuen Metro gab ich in der Fritzbox die folgenden Ports frei. Ausserdem sorgte ich dafür das der lokale Firewall kein Hindernis für die opensim32.exe und opensim.exe sein würde. https://forum.metrogrid.de/discussion/50...neue-metro
TCP: 80
UDP+TCP: 9000
UDP+TCP: 9051
Dann suchte ich mir mit Hilfe des Dashboards noch freie Koordinaten. Da meine lokale Region nicht ständig online sein würde, wählte ich Koordinaten weit ab der 7000,7000. Damit war der letzte Schritt der Vorbereitung problemlos abgeschlossen, und die Installation selbst erforderte nur das Entpacken der Metropolis-Edition. SQLite sollte als Datenbank beibehalten werden also blieb die Datei ./opensim/bin/config-include/GridCommon.ini unverändert. Gestützt auf die Anleitung und der Beispieldatei Regions.ini.example ertstellte ich nur eine regions.ini für meine Region:
[Midgard]
RegionUUID = XXXXXXXXXXXX
Location = 490,500
InternalAddress = 0.0.0.0
InternalPort = 9051
AllowAlternatePorts = False
ExternalHostName = SYSTEMIP
SizeX = 1024
SizeY = 1024
SizeZ = 1024
NonPhysicalPrimMax = 256
PhysicalPrimMax = 64
ClampPrimSize = False
MaxPrims = 250000
MaxAgents = 100
Als Erstes startete ich dann die opensim32.exe. Der Simulator lief fehlerlos hoch, und Coppers und mein Avatar konnten die Region betreten. Bingo, das war ermutigend. Von der folgenden Seite besorgte ich etliche 256mx256m grosse OARs von Linda Kelly die auf die Region geladen werden sollten.
https://zadaroo.com/oars/
Das ging allerdings quälend langsam, und das permanente Abspeichern schien nicht zu funktionieren. Wie ich aber jetzt von Eryn weiss, gelangen die OAR-Daten zunächst nur in den Cache, und man muss mit dem Befehl "backup" für eine Übertragung in die Datenbank sorgen. Was auch wieder quälend langsam ging.
Neustart der Region nach OAR Upload/Bauen:
1. "backup"
2. "shutdown"
@Eryn: Ich habe das unter Missachtung aller Pausen direkt hintereinander ausgeführt, sobald der Prompt wieder erschien. Trotz aller gegenteiliger Erwartungen funktionierte das.
Da nun die 32Bit Version des OpenSimulators nur mit 4GB RAM (2^32=42949672996) umgehen kann, und die Datenbank SQLite deutlich langsamer als MySQL/MariaDB ist. Sollte nun, auf Eryns Rat hin, der Wechsel zum 64Bit Opensimulator und der Datenbank MariaDB erfolgen.
https://mariadb.org/download/
Zum Wechsel zur 64Bit Variante des Opensimulators muss man statt der opensim32.exe einfach nur die opensim.exe starten. Aber genau das funktionierte nicht ohne Fehlermeldung.
(ERROR - OpenSim.Framework.Servers.HttpServer.BaseHttpServer
[BASE HTTP SERVER]: HandleRequest() threw exception System.FormatException: Die Eingabezeichenfolge hat das falsche Format)
Die Lösung war zum Glück im Metro-Forum zu finden. Pius Noels erster Beitrag im 4.Absatz unter dem folgenden Link: https://forum.metrogrid.de/discussion/co...ment_33408
Also fügte ich in der Datei ./bin/OpenSim.exe.config den folgenden Eintrag im Abschnitt <runtime> hinzu.
<useLegacyJit enabled="1" />
Danach erfolgte die Installation der MariaDB Datenbank. Unter Windows startet man dafür einfach nur das Setup-Programm. Ich habe darauf geachtet das Root-Zugriffe nur lokal erfolgen dürfen und die Datenbank für die Verwendung des UTF8 Zeichensatzes eingerichtet wird. Für die Konfiguration der Datenbank bin ich der Anleitung Maretas gefolgt.
https://hyperweb.eu/server/ubuntu1804/mysql/
Dabei gleich ein Tip, wählt für den user der opensim Datenbank ein Passwort ohne Sonderzeichen. Ihr werdet gleich sehen warum. Nachdem die neue Datenbank lief musste nun der Opensimulator entsprechend der Anleitung im MetroWiki noch auf diese Datenbank umkonfiguriert werden.
https://hypergrid.org/metropolis/wiki/de...figuration
Dabei muss die Zeile für die SQLite Datenbank auskommentiert und die folgenden Zeilen für MySQL aktiviert werden.
StorageProvider = "OpenSim.Data.MySQL.dll"
ConnectionString = "Data Source=localhost;Database=Opensim;User ID=Opensim Password=****;Old Guids=true;"
Wenn ihr Euch jetzt den ConnectionString anschaut müsste klar werden, warum Passwörter mit Sonderzeichen speziell mit Anführungszeichen nicht funktionieren können. :-) Anführungszeichen im Passwort bringen die Syntax des Strings völlig durcheinander. An dieser Stelle war dann auch mein 64Bit Opensimulator mit der MariaDB lauffähig, und ich konnte mich um den Upload der OARs kümmern. Dafür gibt es mehre interessante Links:
http://opensimulator.org/wiki/Load_Oar_0.9.0+
http://opensimulator.org/wiki/Varregion
http://opensimulator.org/wiki/OpenSim_Archives
Als Erstes bin ich wieder genau der Anleitung gefolgt.
load oar oar00.oar
load oar oar01.oar --displacement "<0,256,0>" --merge --force-terrain --force-parcels
load oar oar10.oar --displacement "<256,0,0>" --merge --force-terrain --force-parcels
load oar oar11.oar --displacement "<256,256,0>" --merge --force-terrain --force-parcels
Dabei kommt es aber zu einem unschönen Fehler.
[LAND MANAGEMENT MODULE]: Cannot add parcel "Western Town", local ID 2 at tile 0,0 because this is still occupied by parcel "Your Parcel", local ID 1 in Midgard
Auch hierfür fand sich die Lösung im Metro-Forum in einem Beitrag von Pius Noel unter dem folgenden Link.
https://forum.metrogrid.de/discussion/50...egionen/p2
Es kommt leider dazu, daß für eine Parzelle aufeinmal zwei Namen in der Datenbank stehen und einer muss gelöscht werden. Dafür logge ich mich auf der Datenbankkonsole ein:
mysql -u root --password
Danach führt man die folgenden SQL Befehle aus, und löscht so den Namen "Your Parcel". Dabei muss die UUID des Namens "Your Parcel" verwendet werden:
SELECT UUID,Name FROM opensim.land;
DELETE FROM opensim.land where UUID = '11111111-2222-3333-4444-555555555555';
Schwierig könnte das mit der integrierten SQLite Datenbank werden, ich weiss momentan nicht ob man da überhaupt eine Konsole aufrufen kann. Aber man kann das Problem von vornherein vermeiden. Wenn man den OAR Load-Befehl für die erste Region verändert:
load oar oar00.oar --displacement "<0,0,0>" --merge --force-terrain --force-parcels
load oar oar01.oar --displacement "<0,256,0>" --merge --force-terrain --force-parcels
load oar oar10.oar --displacement "<256,0,0>" --merge --force-terrain --force-parcels
load oar oar11.oar --displacement "<256,256,0>" --merge --force-terrain --force-parcels
Das Nette bei dieser Art des OAR Uploads ist es, das die ursprünglichen Sim-Namen als Parzellennamen erhalten bleiben. Ich habe dabei erst alle Regionen auf diese Weise hochgeladen, und erst danach mit allen neuen Regionen zusammen den Befehl "backup" und anschliessend ein "shutdown" ausgeführt. Das dauert dann natürlich trotz 64Bit System eine geraume Zeit. Das Ergebnis der ganzen Bemühungen ist ein System der folgenden Spezifikation:
CPU 10 Cores
RAM 64GB
upload: 12MBit/s
Var4x4 Region
ca. 92000 Prims
ca. 5500 Skripte
Normalerweise hatte ich vor mit einem geskripteten Auto auf der Sim herumzufahren, und zu schauen ob das flüssig geht. Bei den ersten Tests hab ich das aber aufgegeben. Nicht weil der PC an seine Grenzen war, die Upload Bandbreite von 12Mbit/s war der Flaschenhals. Die Datenrate ging immer wieder bis ans Limit und dann begann es natürlich leicht zu ruckeln. Der PC selbst war recht unbeeindruckt. Bei den folgenden Zahlen darf man aber nicht vergessen, daß auf dem PC noch der Viewer und andere auf einem Desktop übliche Programme wie ein Virenscanner liefen.
- 9GB belegter RAM
- im Mittel 15-20% CPU Last
- CPU Spitzenlast ca. 30%
Es ist jetzt natürlich schwierig hochzurechnen welcher Server bei einer var8x8 oder var16x16 notwendig ist. Geht man nur jeweils von einer Verdoppelung aus? Oder muss man doch berücksichtigen das eine Verdoppelung der Seitenlängen eine Vervierfachung der Fläche bedeutet? Ich denke das ein System entsprechend der Empfehlung Manfreds oben ein guter Startpunkt ist. Wenn ich allerdings seinen Beitrag genau lese, und meine Ergebnisse berücksichtige, ist seine Server Konfiguration eine Minimalforderung für eine Var16x16, sollte meiner Meinung nach aber für ein Var8x8 gut funktionieren.
https://www.gridtalk.de/showthread.php?t...5#pid41585
Aufgrund meines Ergebnisses ziehe ich die folgenden Konfigurationen in Betracht:
A) var8x8: V-Server 8Cores 32GB
B) var16x16: V-Server 16Cores 60GB
Da man V-Server leicht upgraden können sollte, könnte man natürlich auch mit dem kleineren System beginnen, und wenn es notwendig ist, den V-Server später upgraden. Soweit zu den technischen Gesichtspunkten. Mal sehen was das liebe Geld noch dazu sagen wird. :-)