Traveler an entfernten Standorten

[Tannibal]

Hallo ihr,

wir haben aktuell nur einen Traveler Server an unserem Haupt-Standort. Größere Standorte haben eigene Domino-Server, angebunden entweder über MPLS oder S2S-VPN.
In letzter Zeit häufen sich die Beschwerden über eine langsame Synchronisierung oder sogar kompletten Stillstand.
Besonders an den Standorten in Asien mit erhöhter Latenz (Indien: 140ms, China: 200ms)

Installiert ihr hierzu eigene Traveler Server oder läuft alles problemlos?

Danke

[schmiddi87]

Wir haben aus diesen Gründen dezentralen Travelerserver (Asien und Amerika).

Diese haben die Beschwerden verringert.

[maxritti]

Ein interessantes Thema. Denn wir haben leider auch Beschwerden bzgl Travelernutzen.

Auch wir haben in Deutschland einen zentralen Travelerserver (bzw. 2 in HAP), welche auf weltweit verteilte Dominoserver zugreifen. Klar, dass dort die Verbindung manchmal eher fragwürdig ist und damit die Synchronisation nicht immer klappt.
Zumal wir auch noch nicht nur IBM Verse nutzen, sondern noch eine externe Anwendung als gesicherter Container auf iOS Geräten. Dafür gibts beim Provider der Anwendung ein Managementserver, der auf die o.a. Traveler navigiert.

Die Lösung in den Problemstandorten einen eigenen Travelerserver zu stationieren gefällt mir.

Aber wie geht das dann bei Euch mit dem Einstiegspunkt?

Dann muss man doch bestimmt 2 oder mehrere Adressen haben, damit die Endgeräte wissen auf welchen Traveler diese sollen.
Dürfte dann mit der von uns genutzten Software eher schwierig werden. Werde ich aber mal nachfragen.

Auch wenn es nicht ganz zum Thema passt, haben wir aufgrund der Konstellation eines zentralen Einstiegs Probleme bei der Nutzung von iNotes. Manchmal kommt bei den Benutzer "Server not responding" oder so ähnlich, wenn Sie in iNotes arbeiten. Für mich auch ein Fall, dass der Dominoserver nicht wirklich gut erreichbar ist. Aber auch hier haben wir eine Einstieg über einen Apache Reverse Proxy, der dann auf die einzelnen Dominos verzweigt.
Auch da wäre ein in den Problemstandorten separater Einstieg interessant.

[Tode]

Off Topic: Einen Traveler ohne vorgeschaltetes MDM zu betreiben ist nicht nur höchst bedenklich, sondern kann inzwischen (Dank DSGVO) so richtig teuer werden. Mit MDM stellt sich die Frage nach dem Einstiegspunkt aber gar nicht.

Doch nun zur eigentlichen Frage: Also wir haben für mehrere internationale Kunden ausführliche Performancetests und Log- Analysen wegen genau dieses Problems gemacht. Und die Quintessenz war IMMER:
Der Traveler muss in räumlicher Nähe zum Mail- Home- Server stehen, und Ping- Zeiten über 50ms führen unweigerlich ab einer bestimmten Belastung zu genau dem oben beschriebenen Problem.

Das hässliche dabei ist: Zuerst sind nur einzelne Geräte der Mitarbeiter an den langsamen Standorten betroffen. Bei steigendem Workload verbreitet sich das dann aber wie ein Lauffeuer: Die langsamen Verbindungen werden nicht mehr getrennt und plötzlich haben nicht nur einige wenige das Problem, das Synchronisation langsam ist, sondern als nächstes kann keiner mehr ein neuer Gerät registrieren und als letzte Stufe kann dann fast keiner mehr synchronisieren, EGAL an welchem Standort.

Das ist die Punkt, wo dann die Kacke richtig am dampfen ist...

[Tannibal]

Wir haben AirWatch MDM im Einsatz, zwar noch im Rollout, aber besser als nichts.

Genau das gleiche Verhalten haben wir auch, Tode.

Und ihr empfehlt eine extra VM pro Standort oder lohnt sich das für Domino´s mit 50-200 User nicht?

[DomAdm]

Hallo,

die IBM schreibt dazu:
https://www.ibm.com/support/knowledgecenter/SSYRPW_10.0.0/capacity_network.html

"In general, geographical proximity improves network performance. The closer all the components are the faster the network is between them. In a perfect environment, all components of a Traveler environment are in the same lab on the same subnet.
When possible, set up Traveler environments that are geographically close to your user base. In general, the closer your users are to your Traveler environment, the more responsive the service is."

"In general, a ping time of <50ms is desirable for communication between Traveler and mail servers. "

Jacob

[Tode]

Ja, so ist unserer Erfahrung: Auch kleine Standorte brauchen -für eine performante Traveler- Anbindung- einen Traveler- Server vor Ort.
Die Netzwerk- Performance zwischen SEG (bzw. MobileIron Sentry) und Traveler hatte dabei interessanterweise keine messbaren Auswirkungen auf die Performance:
Die "Proxies" konnten also tatsächlich an einem Ort stehen, nur die Traveler mussten zu den Mailservern gestellt werden.

[Tannibal]

Vielen Dank für eure Antworten.
Werden wir so planen und umsetzen

[maxritti]

Off Topic: Einen Traveler ohne vorgeschaltetes MDM zu betreiben ist nicht nur höchst bedenklich, sondern kann inzwischen (Dank DSGVO) so richtig teuer werden.

Hast Du dazu ggf noch ein paar hilfreiche Infos bzw Links?
Ich habe mich mal mit einer Bekannten Juristin unterhalten. Irgendwie waren die beiden Ansichten technisch und juristisch aber nicht unter einen Hut zu bringen.

Geht es darum, dass der Traveler indirekt auf Personen bezogene Daten (nämlich die Postfächer) zugreifen kann, was durch ein MDM mehr oder weniger "verschleiert" wird?

Mit MDM stellt sich die Frage nach dem Einstiegspunkt aber gar nicht.

D.h. dass das MDM eine Verbindung zum Endgerät aufbaut und quasi nicht das Endgerät die Verbindung startet?
Und bei mehreren Traveleren (nehmen wir an pro Kontinent gibt es einen) ordnet das MDM dem Endgerät dann quasi den richten Tarveler zu?

Sorry, wenn ich so dumm Frage, bin aber durch Google & Co nicht wirklich weitergekommen. 

[Tode]

Also zur DSGVO: Ihr habt personenbezogene Daten von ANDEREN auf den mobilen Endgeräten (Adressen, Telefonnummern, EMail- Adressen, Mails, etc.) und diese personenbezogenen Daten sind quasi "ungeschützt", und das ist das Haupt- Problem. Ihr könnt sie nicht zuverlässig von den Geräten entfernen, und auch nicht gewährleisten, dass niemand unbefugtes Zugriff erhält. Ihr könnt z.B. ohne MDM nicht verhindern, dass der User WhatsApp installiert und damit sämtliche Kontaktdaten beim Datenmoloch Facebook landen. Das selbe gilt für sämtliche Apps mit Kontakt- Zugriff.

Wir haben hier eine ganze Abteilung, die solche Analysen für unsere Kunden durchführen und für DSGVO- Konformität (nicht nur auf den mobilen Endgeräten) sorgen, und die haben auch die ganzen relevanten Links und noch viel mehr zu dem Thema, damit kann ich also leider nicht dienen.

Zu MDM / Traveler: Im MDM werden entsprechende Mail- Profile hinterlegt, und in diesen sind die Traveler- Server konfiguriert. Und diese Mailprofile werden per Gruppenzugehörigkeit, Standort, oder sonstigen Kriterien den Benutzern vollautomatisch oder auch manuell (je nach Wunsch) zugewiesen. Damit ist gewährleistet, dass jeder auf den Traveler zugreift, der für ihn am geschicktesten ist.

Das Endgerät spricht dann entweder direkt mit dem MDM (z.B. mit der MobileIron Sentry), und das MDM leitet die Anfragen an den internen Traveler weiter, oder aber (im Fall von Verse) baut ein Per- App- VPN zum Traveler auf, und spricht dann direkt mit dem Traveler (weil die Produkte der MDM Hersteller eben nur ActiveSync sprechen und nicht das für die Verse- App notwendige SyncML), aber eben durch einen geschützten VPN- Tunnel.