Ditributed & Scalable Proxy
-
Man stelle sich die folgende Situation vor:
- Wir haben 1,000,000 private HTTP-Server verteilt auf der ganzen Welt
- Zu jedem Server gehören jeweils 2 bis 10 HTTP-Clients
- Sowohl die Server als auch die Clients sind alle hinter einem NAT versteckt, die Clients können also nicht direkt mit ihrem zugehörigen Server kommunizieren.Dazu eine kleine Veranschaulichung: http://s18.postimg.org/wo6kjzuxl/sit_1.png
Um dies jedoch zu erlauben müsste der trafic, soweit ich weiß, über einen public Reverse-Proxy gehen, der Server muss sich zu aller erst mit dem Proxy verbinden um für ihn erreichbar zu sein, danach kann der Client sich an den Proxy wenden und ihm die Anfrage samt den Authentifizierungsdaten übergeben, der Proxy entscheidet anhand der Authentifizierung welcher der verbundenen Server angesprochen werden soll und leitet die Anfrage an den entsprechenden HTTP-Server, wartet auf seine Antwort und leitet diese dann auch direkt an den Client zurück.
Die Verbindung zwischen dem Server und dem Proxy könnte dabei über VPN aufgebaut werden, somit wäre der Server an das LAN des Proxy gebunden und dadurch für den Proxy erreichbar
Nun die Fragen:
1. Habe ich das Prinzip richtig verstanden und die optimalste Lösung für dieses Problem gefunden? Wenn nein, dann bitte ich euch drum zu erklären, wo ich Fehler gemacht haben konnte
2. Da die Menge an Trafic extrem hoch ist, müsste der Reverse-Proxy verteilt und skalierbar sein, wie bewerkstellige ich es?
3. Kann dieses Problem mit existierender Software gelöst werden oder müsste ich hierfür eine eigene Proxy-Software schreiben um den Trafic anhand der Authentifizierung richtig zu routen?Vielen Dank für die Aufmerksamkeit!
-
Sicher dass 1 mio Server für 2-10 mio Clients brauchst?
Das NAT verstehe ich nicht, welchen Sinn hat das? uU willst du hier upnp oder UDP Holepunching oder dergleichen um das NAT-Problem zu umgehen. Stellt sich nur die Frage, wieso?
Wieso VPN wenn Traffic ein Problem darstellt? Wenn du VPN fahren kannst, wieso ist dann NAT ein Problem? Wieso Authentifiziert dein Load Balancer?
Erklär mal ein bisschen mehr. Und trenne die Probleme auf. Ist NAT denn nun ein Problem oder nicht? Ist das Load Balancing das Problem? Geht es um die Minimierung von Traffic?
Eine eigene Lösung für solche Sachen ist idR immer falsch. Oft ist zB sowetwas simples wie Amazon Cloudfront schon eine perfekte Lösung.
-
Shade Of Mine schrieb:
Sicher dass 1 mio Server für 2-10 mio Clients brauchst?
Die Server sind IST-Zustand, ich kann sie nicht mindern und auch nicht mehren, es ist wie es ist, und jeder hat jeweils seine bestimmten Clients
Shade Of Mine schrieb:
Das NAT verstehe ich nicht, welchen Sinn hat das? uU willst du hier upnp oder UDP Holepunching oder dergleichen um das NAT-Problem zu umgehen. Stellt sich nur die Frage, wieso?
Weil die Clients die Server, welche hinterm NAT versteckt sind, nicht direkt ansprechen können, deswegen muss der Server wohl eine Verbindung zum Proxy aufbauen, um für den Proxy erreichbar zu sein, und die Clients müssen sich ebenfalls zum Proxy verbinden, um über diesen Anfragen auf den entsprechenden Server machen zu können
Shade Of Mine schrieb:
Wieso VPN wenn Traffic ein Problem darstellt? Wenn du VPN fahren kannst, wieso ist dann NAT ein Problem?
Ich denke nicht, dass der overhead einer VPN-Verbindung zum Proxy sehr groß sein wird, kann mich aber auch irren. Sinn und Zweck des ganzen ist, dass der Server sich über VPN in das Netzwerk des Proxy einhängen kann damit Anfragen auf ihn weitergeleitet werden können.
Shade Of Mine schrieb:
Wieso Authentifiziert dein Load Balancer?
Weil jeder Client seinen bestimmten Server anspricht und nicht irgendeinen, dazu muss der Proxy erst den User erkennen und dann die Anfrage an den richtigen Server weiterleiten.
Shade Of Mine schrieb:
Erklär mal ein bisschen mehr. Und trenne die Probleme auf. Ist NAT denn nun ein Problem oder nicht? Ist das Load Balancing das Problem? Geht es um die Minimierung von Traffic?
NAT ist definitiv ein Problem, wäre die NAT nicht dazwischen könnte jeder Client direkt mit seinem Server kommunizieren, aber da die Server hiterm NAT sind ist dies nicht möglich. Der Trafic ist, in diesem Fall, ebenfalls ein Problem, denn bei so vielen Clients und Servern ist ein verteilter und skalierbarer Proxy, mit der genannten Funktionalität (Authentifizierung, Weiterleitung der Anfrage und die Antwort zurück an den Client), vorausgesetzt.
Shade Of Mine schrieb:
Eine eigene Lösung für solche Sachen ist idR immer falsch. Oft ist zB sowetwas simples wie Amazon Cloudfront schon eine perfekte Lösung.
"Amazon Cloudfront" höre ich zum ersten Mal und selbst nach kurzer Recherche auf deren Website bin ich mir immer noch nicht ganz sicher, was es denn nun ist und macht, aber grundsätzlich glaube ich, dass solche Services meist viel zu teuer sind.
-
Mich würde interessieren um welche Anwendung es sich dabei handelt (Art der Anwendung, also was die mit den ganzen HTTP Servern/Clients macht - den genauen Namen musst du uns ja nicht nennen wenn du nicht willst).
Ansonsten...
An wie viele Proxies denkst du denn? 1 Mio VPN Tunnel sind schon sehr sehr viel. Ob du das mit z.B. <= 10 Proxies gebacken bekommst ist fraglich.Eine Lösung ohne VPN, z.B. einfach über ein eigenes nonstandard Protokoll zwischen Server und Proxy, wäre vermutlich viel resourcenschonender. Und vermutlich auch einfacher umzusetzen.
Und was Shade bezüglich UDP Holepunching geschrieben hat würde ich an deiner Stelle auch nicht so schnell abtun. Damit könntest du vermutlich einen Grossteil des Traffic erschlagen => weniger Proxies nötig und weniger Traffic der bei den Proxies anfällt => geringere Betriebskosten.
-
hustbaer schrieb:
Mich würde interessieren um welche Anwendung es sich dabei handelt (Art der Anwendung, also was die mit den ganzen HTTP Servern/Clients macht - den genauen Namen musst du uns ja nicht nennen wenn du nicht willst).
Es handelt sich hierbei um NAS Geräte die zuhause stehen und dadurch public nicht erreichbar sind, bin ich nun also in Brasilien im Urlaub habe ich keinen Zugriff auf meine NAS, dies versuche ich mit diesem Reverse-Proxy zu umgehen. Der Proxy Service soll den Client von jedem Ort aus zum Webfrontend seines NAS bringen können. Das NAS baut also eine Verbindung zum public Proxy auf und identifiziert sich: "Ich gehöre user@mail.com". ein WebClient verbindet sich mit dem Proxy und identifiziert sich ebenfalls: "Ich bin user@mail.com", wenn nun also HTTP Anfragen kommen, muss der Proxy diesen User zum WebFrontend seines NAS bringen, das ist die Aufgabe.
Das Problem ist, dass sowohl das NAS als auch der Client beide hinter einem NAT sein könnten und somit nicht in der Lage sind p2p zu kommunizieren. Aber vielleicht gibt es andere Ansätze dieses Problem zu umgehen, die ich möglicherweise noch nicht kenne?
hustbaer schrieb:
An wie viele Proxies denkst du denn? 1 Mio VPN Tunnel sind schon sehr sehr viel. Ob du das mit z.B. <= 10 Proxies gebacken bekommst ist fraglich.
Ich denke, dass der trafic enorm hoch sein kann und das Reverse-Proxy-System hierfür gut und frei skalieren soll.
hustbaer schrieb:
Eine Lösung ohne VPN, z.B. einfach über ein eigenes nonstandard Protokoll zwischen Server und Proxy, wäre vermutlich viel resourcenschonender. Und vermutlich auch einfacher umzusetzen.
Hmm, wie stellst du dir das genau vor? Wie genau soll denn das Protokoll ausschauen?
hustbaer schrieb:
Und was Shade bezüglich UDP Holepunching geschrieben hat würde ich an deiner Stelle auch nicht so schnell abtun. Damit könntest du vermutlich einen Grossteil des Traffic erschlagen => weniger Proxies nötig und weniger Traffic der bei den Proxies anfällt => geringere Betriebskosten.
UDP und HTTP vertragen sich nicht, ich denke damit ist alles gesagt.
-
Spez schrieb:
hustbaer schrieb:
Eine Lösung ohne VPN, z.B. einfach über ein eigenes nonstandard Protokoll zwischen Server und Proxy, wäre vermutlich viel resourcenschonender. Und vermutlich auch einfacher umzusetzen.
Hmm, wie stellst du dir das genau vor? Wie genau soll denn das Protokoll ausschauen?
Wie du willst.
Ich sehe da jetzt kein grosses Problem. Wichtig ist bloss dass du ne sauber verschlüsselte Verbindung aufbaust, also z.B. über OpenSSL. Und natürlich dass du die Authentifizierung sauber machst, also dass es auch da keine Sicherheitslöcher gibt.Eine ganz einfache Variante wäre z.B. dass die NAS die Requests über "long polling" vom Proxy pollt. Also einfach TCP/IP Connection aufmachen, SSL-Handshake + Authentifizierung, und dann warten ob was daherkommt. Sobald die ersten paar Bytes eintrudeln kann dann parallel schon die nächste Connection aufgemacht werden -- damit nicht alle HTTP Requests serialisiert werden.
Den Teil nach SSL-Handshake + Authentifizierung kannst du dann im Prinzip direkt an einen normalen HTTP Server dranknoten.
Wie man mit Connection=keep-alive umgeht müsste man sich überlegen. Entweder einfach verbieten oder vielleicht fällt dir was schlaues ein.Oder aber du implementierst ein eigenes Protokoll mit dem du mehrere Datenströme parallel übertragen kannst. Also quasi ein einfaches TCP/IP-over-TCP/IP. Dann hast du im Prinzip etwas was einem VPN Tunnel recht ähnlich ist, nur ohne dass du am Proxy pro verbundener NAS ein virtuelles Netzwerkinterface brauchst.
Bzw. alternativ kannst du dich auch umsehen ob es ne Library gibt mit der man nen VPN Tunnel am Proxy annehmen kann, ohne dass wirklich im OS ein virtuelles Netzwerkinterface erstellt wird. Also quasi nen virtuellen VPN Tunnel
Das wäre dann u.U. ausreichend resourcenschonend, und gleichzeitig einfach umzusetzen. Proxyseitig würde sich das kaum von der "einfaches TCP/IP-over-TCP/IP" Variante unterscheiden, aber auf den NASen könntest du dann ne ganz normale VPN Implementierung verwenden.
Wobei Achtung: OpenVPN ist GPL!Spez schrieb:
hustbaer schrieb:
Und was Shade bezüglich UDP Holepunching geschrieben hat würde ich an deiner Stelle auch nicht so schnell abtun. Damit könntest du vermutlich einen Grossteil des Traffic erschlagen => weniger Proxies nötig und weniger Traffic der bei den Proxies anfällt => geringere Betriebskosten.
UDP und HTTP vertragen sich nicht, ich denke damit ist alles gesagt.
Naja, aus deinen Beiträgen ging auch nur implizit, dafür aber sehr klar hervor, dass du die auf den Servern laufende Software modifizieren kannst. Daher bin ich mal davon ausgegangen dass das u.U. auch für die Clients gelten könnte.
Und dann wäre UDP kein unlösbares Problem mehr, auch wenn man HTTP Anfragen darüber tunneln will.Was mich dann aber wieder auf das ebenfalls schon von Shade vorgeschlagene UPNP bringt. Die meisten User drehen das in ihrem Router nicht ab, und damit könnte die NAS direkt nen Port aufmachen. Eure Server würden dann nur noch als Directory-Service benötigt. D.h. der Client logt sich beim Proxy ein, der guckt die Serveradresse in seiner DB nach und macht dann direkt ne Weiterleitung nur NAS.
Und natürlich als Fallback für User wo UPNP wirklich nicht geht. Wobei man das dann auch nachträglich als Update/Upgerade releasen könnte. Was wieder für die TTM gut wäre.
-
Wobei mir gerade noch eine Idee kommt - sehr naheliegend, aber ich hab' einfach nicht früher dran gedacht
Die NASen könnten auch per long-polling (z.B. über ganz normale HTTP Requests) abfragen ob sich gerade jmd. zu ihnen verbinden will.
Und erst wenn sie ein "ja" zurückbekommen bauen sie den VPN Tunnel auf. Damit könntest du die Anzahl der benötigten VPN Tunnel vermutlich um 1-2 Zehnerpotenzen drücken. Und dann gingen vielleicht auch wieder normale Tunnel, trotz dem sie einiges an Resourcen fressen.
-
Spez schrieb:
Es handelt sich hierbei um NAS Geräte die zuhause stehen und dadurch public nicht erreichbar sind, bin ich nun also in Brasilien im Urlaub habe ich keinen Zugriff auf meine NAS, dies versuche ich mit diesem Reverse-Proxy zu umgehen.
Dann einfach deinen Router richtig konfigurieren? Oder einfach uPNP verlangen und automatisch konfigurieren?
Ansonsten ala Skype: udp holepunching.Schau dir die Skype Infrastruktur an, die ist ziemlich genial.
Ich denke der ganze Ansatz ist falsch den du fährt. Mach es wie Skype. Bau dir dein Portforwarding per UDP holepunching, uPNP, händische Einstellung, etc.
Das ist simpel und ist die gängige Variante die andere NAS Hersteller auch machen.
VPN finde ich heirfür komplett falsch.
-
Ich kann die Funktionalität des public intermediate service (Proxy), des NAS als auch deren Kommunikation frei gestalten, der Client bleibt mir jedoch verwehrt. Deswegen konzentriere ich mich auf HTTP, da jeder Client einen Webbrowser zur verfügung hat und darüber sein NAS ansteuern kann.
Mit HTTP gibt es meines Erachtens nach keine Alternative zum reverse proxy, aber vielleicht liege ich ja mit dieser Aussage falsch, wobei ich dies sehr stark bezweifle.
-
Wenn du den Client nicht anfassen kannst, kannst du kein VPN machen und eigentlich gar nichts. Denn ohne Client kannst du nicht auf einen Server zugreifen, egal was fuer einen.
Also: was fuer einen Client hast du denn?
-
Shade Of Mine schrieb:
Wenn du den Client nicht anfassen kannst, kannst du kein VPN machen und eigentlich gar nichts. Denn ohne Client kannst du nicht auf einen Server zugreifen, egal was fuer einen.
Also: was fuer einen Client hast du denn?
Ich denke du hast da etwas missverstanden, denn die VPN-Verbindung wollte ich zwischen Server (NAS) und Proxy aufbauen um den Server in das Netzwerk des Proxy zu schleusen damit Abfragen von externen HTTP-Clients (Webbrowsern) an ihn weitergeleitet werden können.
-
Halte ich für eine schlechte Idee.
Aber du hast meine Frage dennoch noch nicht beantwortet. Was für Clients hast du?
