(v)Server-Struktur für Nutzer in Saudi-Arabien, China, Indonesien, u.a.

[Kalleos]

Irgendwie wurde ich ausgeloggt und alles was ich geschrieben habe verworfen.. darum jetzt alles nochmal

Hallo miteinander!

Ich habe ein kleines Startup für welches ich auf einem Strato-VServer Unternehmenssoftware hoste (Jira, ERP-Lösung).
Nun werde ich globaler und habe Partner in Saudi-Arabien, China, Vietnam, Indonesien und ggf. Australien.

Die Antwortzeiten aus den Ländern auf den Strato-VServer in Deutschland sind sehr lange und können keine Lösung darstellen.

Was wäre die schnellste Lösung zur Spiegelung des deutschen VServer in Ländern wie China, Vietnam oder Saudi-Arabien? Ich habe bis jetzt mit Spiegelungen noch nichts zutun gehabt, wo lese ich mich ein? Sollte ich für eine schnelle Lösung Cloud-Dienstleistungen wie die von Amazon in Betracht ziehen? Letzteres könnte wegen Datenschutz problematisch werden oder? Wie siehts mit Synchronisation der Datenbanken und selbiges für Backups aus?
Könntet ihr mir etwas empfehlen?

Vielen Dank!

 

[marce]

was brauchst Du denn? Reicht Dir ein Hoster "vor Ort", damit die lokalen Zugriffe auf eine komplett ded. Installation dort schneller ist oder sind zentrale Komponenten vorhanden, auf die alle beteiligten Server zugreifen müssen?

 

[Kalleos]

Hi,
ja es sind zentrale Komponenten vorhanden, die serverübergreifend konsistent sein müssen.
Damit meine ich konkret PostgreSQL-Datenbanken, welche Jira und Confluence und vor allem die ERP-Software nutzt.
Edit: Die ERP-Software managet eben Lieferungen, Beschaffungen, Kontrakte etc. die für alle Partner in den genannten Länder einsehbar/änderbar sein sollten.
Edit2: Aber jetzt hast du mein Denken glaube ich auf den wesentlichen Kern geleitet. Eine mögliche Lösung ist wohl in mehreren Orten separate Installationen der Software einzurichten, aber eine verteilte PostgreSQL Datenbank einzurichten, die sich synchronisiert/repliziert?

 

[marce]

Grundlegend hast Du folgende Möglichkeiten:
* ded. Instanzen pro Standort, die keine gemeinsam genutzten Daten haben
* ded. Instanzen pro Standort, die auf eine gemeinsame Datenhaltung zurückgreifen
* ded. Instanzen pro Standort, die lokale Daten halten, die regelmäßig auf eine zentrale Stelle konsolidiert werden
* eine zentrale Instanz

generell gilt, für alles, was zentral ist, sollte eine möglichst umfassend gut angebundener Standort gewählt werden - ob dafür ein StratoV-Server gut geeignet ist, kann ich nicht beurteilen.

Ideal wäre ein ded. Server in einem zentralen RZ mit einem Provider, der Dir auch noch ermöglicht, deine notwendiigen Routings für VPN-Verbindungen der Standorte auf das zentrale System zu optimieren und evtl. auch QoS garantieren kann.

Was grundlegend ideal ist hängt sehr von den einzelnen Anforderungen an Aktualität und Umfang der gemeinsam genutzten Daten ab und von den Möglichkeiten, die die Software da bietet.
Mit PostGres hast Du (AFAIK immer noch) das Problem, daß dort die Replikate nur lesend verfügbar sind und Du alle Schreiboperationen auf dem zentralen Master durchführen musst (es gibt zwar Proxy-Lösungen, die das auch ein wenig umgehen können) - sprich die Anwendung muss das auch unterstützen (ded. Server für Schreiben und Lesen konfigurieren können - bei Jira / Confluence geht das AFAIK nicht).

Ob z.B. ein regelmäßiger Abgleich von Standortdaten möglich wäre, ... - da darf und kann man viel Hirnschmalz reinstecken.