Ich suche eine neue Lösung für den wöchentlichen Präprozessorlauf für die BRouter Daten.
Problem, was ich habe mit der aktuellen Lösung (Strato Level 2 VServer, 400 GB Diskspace,8 GB RAM) ist ein EXTREM schlechte IO-Performance bzgl des Disk-Storage. Das Ding ist aber nicht komplett unbrauchbar, es handabt immerhin pro Monat > 1 TB pro Monat Download-Volumen und ca 0,5 Mio Routing Requests völlig problemlos und sehr performant. Abdr nur, weil das alles aus dem Dateisystem-Cache kommt und nicht wirklich aus dem Disk-Storage. Da reden wir zeitweise über Modem-Geschwindigkeit…
Lange Rede, kurzer Sinn, ich suche Hilfe von jemandem, der einen Server betreibt, auf dem der weekly-Planet sowieso schon rumliegt und der 200 GB Disk-Space und paar Stunden Rechenzeit pro Woche übrighat, um das BRouter-Präprozessing zu rechnen. Das wäre alles nur im Hintergrund, der Daten-Download sowie die BRouter-Web Instanz würden auf dem Strato-Server bleibenm (weil sie ja gut funktionieren)
Es geht also nur darum, aus dem ca 35 GB weekly-planet und ca 70 GB Höhendaten unter Zuhilfenahme von ca 40 GB Zwischenspeicher, 5 Stunden Rechenzeit und einer Java-VM ca 4 GB BRouter-Datenfiles zu machen und die zur einmaligen Übertragung zur Verfügung zu stellen.
wir von Historic.Place stehen auch vor der Aufgabe, unsere Serverstruktur zu ändern.
Dies wird Ende Januar 2017 geschehen.
Wenn du solange warten kannst…
Geplant ist eine Trennung von Entwicklungs- und Anwendungsserver, Entwicklungsserver mit Raid 1,
um ständige Ausfälle durch Festplattenschäden zu vermeiden usw.
Für die Anwendung selbst reicht warscheinlich ein guter Webspace…
Zur Zeit arbeitet Zecke zB. daran, eine lokale Overpass-Api zu testen, um langfristig stündliche Updates bieten zu können.
Was wir dann genau nehmen, ist noch nicht entschieden, hängt natürlich auch von den Testergebnissen ab.
danke für das Angebot, ja, das hat solange Zeit. Der SRTM1-Upgrade muss halt warten, aber kann der auch, da steht keine wirkliche Nachfrage dahinter, und irgendwann platzt mir das 2,6 GB Limit für eine 32-bit Java-VM, aber wohl nicht in den nächsten Wochen.
An einen fossgis-geförderden dedicated Server hatte ich ehrlich gesagt auch gedacht. Für einen eigenen Server bzw. Förderantrag ist mein Problem einfach zu klein. Das IO was ich machen muss ist rein sequentiell, von meiner Seite also keine Notwendigkeit für SSD Storage, aber andererseits sinds auch nur 35 GB planet-latest.pbf (geshared?) + 63 GB Höhendaten + 40 GB temporärer Plattenspeicher - passt also vielleicht auch in eine reine SSD-Lösung mit drauf.
Da ich der IT Laie bei Historic.Place bin, wende dich bitte mit den genauen technischen Details an unseren Admin Zecke <zecke@historic.place>
Das ist wichtig, weil er festlegt, wie der neue Server ausgestattet werden muß, um langfristig sicher zu laufen.
Wir wollen ja nicht jedes Jahr einen neuen Server einrichten
Von Ihm wirst du auf den neuen Server auch die Zugriffsrechte bekommen.
Ich gehe davon aus, das du Anfang Februar dein Toolchain installieren kannst
wollte nur kurz berichten, dass das jetzt alles so läuft, und auch gut läuft, also das BRouter-Präprozessing auf dem (dedicated) Server von Historic-Place.
Der Daten-Dowload und die Online-Instanz von brouter-web ( http://brouter.de/brouter-web ) aber weiterhin auf meinem Strato-V-Server.
Damit kann die Zugriffsspitze am 20-Grad Mai-Wochenende kommen, das Ding wird keine Schwäche zeigen …
Nochmal vielen Dank an Lutz und Zecke von Historic-Place und auch an den Fossgis e.v., der das ganze fördert.
