Hallo,
möchte einen OSM-Server aufsetzen und benötige aktuelle Hardwareanforderungen.
Wie Groß soll SSD sein wenn man OSM als Planet mit Zoomstufe bis ca. 17 darstellen möchte?
Reichen für den flüssigen Betrieb (Darstellung, Updates) 4TB aus?
Habe Paar aktuelle HP-Server mit bis 2x 20-Kern, 64-128GB RAM, SSD-RAIDs.
Oder reicht für den Betrieb auch 4-Kern mit 8GB RAM aus?
Wenn du dein geplantes Nutzungsszenario genauer beschreibst, können die Hardware-Empfehlungen besser ausfallen. Fragen die sich so stellen: Benötigst du wirklich den Planet? Wie soll die DB aktualisiert werden (laufend, zyklisch, …)? Wieviele Nutzer erwartest du? …
Nutzungszenario:
In einem Immobilien-Makler-Website mit zunächst geringen Besucherzahlen sollen die Immobilien mit Einblendung der Ortungen auf Karte dargestellt werden. Es funktioniert soweit, es wird der zentrale OSM-Server verwendet. Zu manchen Zeiten kommen die Einblendungen der Karte aber stark verzögert an. Manchmal dauert das 5-10 Sekunden bis die Karte angezeigt wird.
Website soll zunächst Deutschlandweit später Europaweit bzw. Weltweit abgebildet werden (falls einer eine Immobilie in Spanien verkauft). Besucherzahlen zunächst 1 bis max. 20 gleichzeitig. Updates - ein mal pro Jahr würden ausreichen. Wichtig ist dass, die Karte mit Zoomstufe bis ca. 17 eingeblendet wird.
Bei mir werkelt jetzt für meinen MapOSMatic Server auf get-map.oprg ein Root-Server mit 16 Kernen (32 mit HyperThreads), 128GB, ca. 7.5TB SSD.
Die CPU laste ich dabei definitiv nicht aus, und den Speicher eigentlich auch nur bei einem Planet-Komplettimport. 64GB wird für einen kompletten Planet-Import mittlerweile evtl. nicht mehr reichen um alles in den RAM-Cache zu bekommen, aber dann wird es halt beim ersten Import ein klein wenig langsamer, funktionieren tut es trotzdem noch. Im Render-Betrieb und zum Einspielen von OSM planet diffs baucht man längst nicht so viel.
Nun zum SSD-Platz: ich würde da mit 4TB kaum noch auskommen, habe auf dem Server aber auch deutlich mehr drauf als auf einem typischen Tileserver, insbesondere wenn der nur einen bestimmten Stil rendern soll, und nicht wie bei mir möglichst alles was an Mapnik- und CartoCSS Kartenstilen als Open Source zu finden ist.
Ich habe zur Zeit (aufgerundet)
In PostGis Datenbanken
Dazu kommem dann noch:
Ich würde also mit 4TB mittlerweile so nicht mehr auskommen (obwohl es mit etwas Mühe und Aufräumen noch klappen würde).
Für einen reinen Tileserver, würden 4TB aber wohl locker reichen (abhängig davon wie viele Tiles man fertig auf Festplatte gecached vorhalten will).
Insbesondere wenn man nur einen konkreten Kartenstil rendern will (dann braucht man nicht alle Tags in die Datenbank zu importieren, sondern nur die, die tatsächlich von dem Stil auch ausgewertet werden). Selbst wenn man einen Still mit Hillschading und/oder Höhenlinien anbieten will (die meisten Stile, insbesondere auch der OSM-Standardstil, bieten das ja nicht an) braucht man dafür nicht so viel Platz wie ich da ich drei verschiedene Varianten davon, und alle Rohdaten dazu, mit auf dem Server habe.
Wenn man auch den Datenimport auf einer anderen, größeren, Maschine durchführt und dann die fertige Datenbank per Datenverzeichnis-Transfer importiert dann könnte als reiner Tile-Render-Server evtl. sogar tatsächlich ein 4-Kerner mit 8GB reichen, je nachdem wie viele Zugriffe erwartet werden.
Aber ein eigener Tile-Server ist tatsächlich so mit das einzige was ich nicht selbst auf meinem Server betreibe (ich rendere da ja keine Kacheln, sondern jeweils komplett für die ausgewählte Papiergröße in einem Rutsch), von daher fehlt mir zu dem Thema die “Hands On” Erfahrung, möglicherweise liege ich mit meinen Einschätzungen da auch komplett daneben …
Für dein Nutzungsszenario könntest du auch überlegen, anstatt des kostenfreien Servers des OSM-Projektes, einen kostenpflichtigen Dienst zu nutzen. Dann brauchst du zum einen (vermutlich) nur die URL ändern, und zum anderen ersparst du dir das aufwändige Aufsetzen und den aufwändigen Betrieb eines eigenen Servers.
Das erscheint mir sehr viel … bei mir sind das ‘nur’ 418 GB.
Habe 20 core (40 treads) Intel Xeon dran gesetzt. Mit 64GB RAM ging es, war jedoch etwas langsamer. Den ersten Versuch die Daten zu importieren habe ich wohl zu früh abgebrochen. Habe bei “Completed planet_osm_roads” neu gestartet. Hat an Paar stellen gemeckert, dass es etwas gefehlt hat. Beim zweiten Versuch habe 160GB RAM reingesteckt. Jetzt ging es etwas floter. CPU-Last liegt im Moment bei ca. 5-10%, 4TB SSD ist jetzt bei 737GB. Das Ding importiert scheinbar noch etwas.
Aktuell steht die Meldung “Completed planet_osm_point”.
Wann kann man den Rechner neu starten oder das Fenster schließen?
Meint Ihr wirklich 4TB SSD? Ich lege Tiles, Höhendaten etc. auf einer großen HDD ab, eine SSD scheint mir dafür verschwendet - zumindest wenn man sie bezahlen muß. 
Auf der anderen Seite habe ich für den Import gute Erfahrung mit 2 kleineren SSDs gemacht. Die Datenbank liegt auf einer eigenen SSD, die anderen Daten insbesondere die Nodelist auf der anderen. Dadurch addieren sie die Lese- bzw. Schreibrate von beiden Geräten.
Na ja, HP Rard- Controller mit 2GB Cache, Raid 1 mit 2x Samsung 870 QVO 4TB. Habe noch Paar 870 EVOs liegen. QVOs mit 70MB/Sek Schreibgeschwindigkeit scheinen mir etwas träge zu sein. Mit EVOs 500MB/Sek habe ich noch nicht probiert. Ich denke, wenn ich die Installation geschaft habe ist es egal ob es QVO oder EVO sind. Lesen tun die beiden gleich schnell. Belegt sind zurzeit 754GB.
Installation läuft weiter. Jetzt steht der Server bei “Create geometry index on planet_osm_line”. Danach kommen warscheinlich Polygone.
Die Importroutine (Bash) schint mir nicht optimal programmiert zu sein. Dass beim Schreiben von DBs der ganze Arbeitsspeicher belegt wird ist schon etwas Eigenartiges.
Das Ganze ist zurzeit nur ein Test von dem was möglich ist. Ob nam so etwas selber hostet?! Für eine Joomla Website ist es definitiv ein overshoot. Aber man kann Erfahrung sammeln, womit man den Kunden zufrieden stellen kann.
Das liegt nur daran, daß in den OSM Daten zuerst die Punkte kommen, dann die Linien. Für die Auswertung der Linien müssen aber die Punkte vorhanden sein und daher zwischengespeichert werden. In Deinem Fall passiert das im Hauptspeicher. Das kann man auch in der DB tun (zu lahm) oder in einer speziellen Nodelist-Datei auf der SSD - so verwende ich das. Dann läuft der Import auch mit viel weniger Speicher.