Routing und RAS für HTTP(S) Traffic

[ASP.NET 0]

Hallo,

 

wir haben ein Windows Server 2012 R2 Host-System, auf dem verschiedene PHP- und demnächst auch ASP.NET Anwendungen gehostet werden. Hierzu verwenden wir den IIS. Varnish soll als Fronted-Cache genutzt werden. Um das zu realisieren, haben wir virtualisiert mit zwei VMs, die sich in einem eigenen Subnetz befinden:

 

VM #1: Debian mit Varnish (192.168.0.2)

VM #2: Windows Server 2012 R2 mit IIS (192.168.0.3)

 

Port 80 des Host-Systems soll auf VM#1 (192.168.0.2) geleitet werden. Dort liefert Varnish den Request aus dem Cache aus sofern vorhanden. Ansonsten leitet er ihn an den IIS (192.168.0.3) weiter und cached die Antwort für zukünftige Anfragen. 

Port 443 soll direkt an den IIS an VM2 gehen, da wir SSL nur für angemeldete Benutzer verwenden (nicht angemeldete werden auf HTTP geleitet, sofern die Seite über HTTPs aufgerufen wird). Hier wäre das Caching der kompletten Seite sowieso sinnfrei, da zu viele dynamische Inhalte wie Benutzername etc. vorhanden. Außerdem unterstützt Varnish kein HTTPS-Caching. 

 

Lösen wollte ich das ganze über NAT mit Routing und RAS von Windows Server 2012. Das erfüllt meine Anforderungen vollkommen. Leider ist es extrem langsam. Die Ladezeit geht auf über 10 Sekunden hoch:

 

 

Mit einer normalen IIS-Installation auf dem Host-System lag die Ladezeit vorher bei 1,5 bis 1,8 Sekunden. Ich vermute das Problem darin, dass über Routing und RAS kein Keep-Alive möglich ist und somit für jeden Request eine komplett eigene Verbindung geöffnet wird. 

 

Daher meine Fragen:

1. Ist es möglich, Routing und RAS für HTTP(S)-Traffic mit Keep-Alive zu nutzen, sodass vernünftige Ladezeiten entstehen?

2. Wenn nein was ich eher vermute: Was für Alternativen gibt es? Am liebsten wäre mir etwas das die Möglichkeiten von Routing und RAS bietet, also einen einzelnen Port auf einer einzelnen IP an eine eigene VM im Intranet leiten zu können. Bisher habe ich nur die Möglichkeit von Reverse Proxys gefunden. Testweise nutze ich nginx. Das ist aber eher suboptimal: Meine PHP-Anwendungen prüfen, ob der User SSL nutzt oder nicht und leiten den User entsprechend um: Nicht angemeldete User werden auf HTTP umgeleitet wenn sie über HTTPs reinkommen. Ich muss also im Nginx meine SSL-Zertifikate hinterlegen, und die Requests ebenfalls per SSL an den IIS weiterleiten. Heißt ich habe bei jedem Request Overhead. SSL einfach nur stumpf weiterleiten kann nginx scheinbar nicht, genau das bräuchte ich aber. 

Außerdem gefällt mir bei dieser Lösung nicht, dass die Requests im dümmsten Fall über drei Server laufen: nginx => varnish => IIS

[zahni 550]

Mir ist nicht ganz klar, wozu man hier RAS braucht. Alle Anforderungen, auch das Caching von statischen und dynamischen Inhalten, können vom IIS erledigt werden,

Den muss man halt richtig einrichten.

 

Beachte bitte auch die Anforderungen an die Lizensierung der Windows Server-Installationen inkl. CAL's.

bearbeitet 28. Juni 2014 von zahni

[ASP.NET 0]

Leider nein. Um statische Inhalte geht es dabei auch nicht, das kann wie du sagtest der IIS genau so gut wie wohl jeder andere Webserver übernehmen. Varnish cached dynamische Inhalte, bisher ausschließlich PHP. Der IIS verfügt zwar über Möglichkeiten, dynamisch generierte Inhalte zu Cachen. Das Problem ist, dass bei unseren Anwendungen immer Cookies gesetzt werden, auch für nicht angemeldete User. Unsere Caching-Regeln basieren also darauf, dass bestimmte Cookies die nur gesetzt sind wenn jemand angemeldet ist dazu führen, dass nicht gecached wird. Ansonsten darf gecached werden, auch wenn Cookies gesetzt werden. Standardmäßig wird bei vielen Caching-Mechanismen (auch bei Varnish) nämlich nicht gecached wenn Cookies gesetzt werden, da man hier von Session ausgeht. Das ist meines wissens nach mit dem IIS so nicht möglich. 

 

Ein weiterer Grund dafür ist die Tatsache, dass mit Routing und RAS sehr flexibel einzelne Ports gezielt an eine spezielle VM geleitet werden können. So können andere Dienste (z.B. Gameserver) problemlos in einer eigenen VM isoliert und auch unter einem anderen OS (z.B. Linux) laufen, und sind von außen über die gleiche IP erreichbar wie z.B. der Webserver. 

 

Lizenztechisch habe ich mich bereits vorher informiert, das müsste in Ordnung sein. Wir haben Server 2012 R2 Standard und im Moment eine Installation auf dem Hostsystem und eine VM, das ist bei dieser Version laut Microsoft erlaubt. Da wir das Hostsystem ausschließlich zur Virtualisierung nutzen wären sogar 2 VMs erlaubt. Auf dem Hostsystem läuft nur Hyper-V und eben Routing und RAS, beides dient ja ausschließlich zur Virtualisierung.

[Dukel 451]

Wie hängt der Host am Internet? Gibt es einen Router oder eine DMZ?

Ich würde einfach dort (wenn ja) den Port 80 und 443 an die entsprechenden Hosts leiten.

[zahni 550]

http://www.iis.net/configreference/system.webserver/Caching

Vor allen Dingen klappt es dann auch mit HTTPS.

HTTP Traffic kann der IIS auch selber intern an andere Ports oder IP-Adressen weiterleiten.

 

Und direkte externe Zugriffe auf bestimmte Ports sollte Dein Router effektiver weiterleiten können.

 

Bei Windows geht es um die CAL's hier bewegst Du Dich auf einem schmalen Grat, was lizenzfreie Zugriffe angeht.

Wenn sich User anmelden benötigst Du u.U. eine External Connector License. Mehr können Dir sicher die Lizenz-Spezis hier schreiben.

Einen 1. Blick kannst Du hier riskieren:  http://download.microsoft.com/download/E/8/E/E8EDAE36-CBC6-4123-BC5A-F651D174FD6C/PUR_Explained.pdf

[Daniel -MSFT- 129]

Wenn die Webseite nicht-öffentliche Bereiche enthält, dann braucht der OP in der Regel den externen Connector.

[ASP.NET 0]

Mich würde auch generell interessieren, wieso das mit Routing und RAS so langsam ist. Wenn ich noch mal darüber nachdenke finde ich es nämlich irgendwie doch etwas unlogisch:
HTTP Request geht auf die öffentliche IP des Servers, über NAS wird er auf die interne IP des IIS (Varnish habe ich für die Testumgebung mal weggelassen) "geleitet". Also müsste Keep-Alive doch theoretisch möglich sein? NAT hat ja mit HTTP nichts zutun. Zumal bei jedem DSL-Anschluss NAT eingesetzt wird wenn auch anders rum, wenn es an NAT selbst liegt müsste also jeder Seitenaufruf so lahm sein, was aber nicht der Fall ist. 

Oder ist das tatsächlich alles Overhead? Mir war ja klar, dass durch softwareseitiges NAT ein bisschen Overhead produziert wurde. Aber SO viel? Ich hielt das für absolut minimal und vernachlässigbar. 

 

Wie hängt der Host am Internet? Gibt es einen Router oder eine DMZ?
Ich würde einfach dort (wenn ja) den Port 80 und 443 an die entsprechenden Hosts leiten.

Es handelt sich um einen dedizierten Server von Strato. Ich vermute also, dass der Server über einen Hardware-Router am Netz hängt. Das ich da als Kunde Zugriff bekomme, ist mir nicht bekannt und das bezweifle ich auch.

 

http://www.iis.net/configreference/system.webserver/Caching
Vor allen Dingen klappt es dann auch mit HTTPS.
HTTP Traffic kann der IIS auch selber intern an andere Ports oder IP-Adressen weiterleiten.
 
Und direkte externe Zugriffe auf bestimmte Ports sollte Dein Router effektiver weiterleiten können.

 

Wie oben schon gesagt ist das leider kein Homeserver wo ich am Router schalten und walten kann wie ich möchte, ansonsten hätte ich es auch direkt dort gemacht anstatt softwareseitig auf dem Zielserver. 

 

Das Caching-Modul vom IIS habe ich mir bereits angeschaut und erfüllt wie im letzten Beitrag gesagt nicht meine Anforderungen, da es im Gegensatz zu Varnish nur sehr eingeschränkte Möglichkeiten bietet das Caching-Verhalten anhand von Regeln festzuhalten. Man kann lediglich Abfragenzeichenfolgen oder Header-Felder wählen. Regeln anhand einzelner Cookies sind komplett nicht möglich. Einzige Möglichkeit wäre also das Cookie bzw. Set-Cookie Field. Da keine Einschränkungen festgelegt werden können und unser eingesetztes CMS auch nicht angemeldeten Usern per Cookie eine Session-Id zuweist sowie den Zeitpunkt des letzten Seitenaufrufes per Cookie speichert, würde hier jeder Seitenaufruf in den Cache gelegt und nie wieder abgerufen werden. 

Resultat: RAM-Verschwendung ohne Nutzen. 

 

Varnish haben wir so konfiguriert, dass nur die Seiten von nicht angemeldeten Usern im Cache abgelegt werden und oben genannte Cookies fürs Caching nicht berücksichtigt werden. Alles andere ist wenig Sinnvoll, da die Seiten bei angemeldeten Usern den individuellen Username beinhalten und in der Regel erst dann erneut aufgerufen werden, wenn sich der Inhalt geändert hat. Dann wurde der Cache aber sowieso bereits gepurged und muss sowieso erneuert werden.  

 

Vom IIS an den Varnish zu leiten wäre prinzipiell möglich, halte ich aber für nicht sinnvoll. Ein Großteil unserer Requests (ca. 60-70%) kann aus dem Cache bedient werden. Diese Requests müssten somit den Umweg über den IIS gehen. Dazu kommt, dass beim Cachen einer Seite der Request im Netz 10x hin und her muss: Request geht an den IIS, der merkt er könnte im Cache liegen, leitet ihn an Varnish, der merkt er ist nicht im Cache, holt ihn sich vom IIS, und die Antwort geht noch mal über den IIS wieder zurück zum User. Da gefällt mir die Lösung mit Varnish als Fronted der bei Bedarf einen Request an den IIS sendet besser. 

 

Zur Lizenzierung: Ja es gibt Anmeldemöglichkeiten, allerdings nicht über oder mit Windows sondern über ein eigenes Accountsystem innerhalb des CMS (Forum). Auf den Server haben keine User in irgend einer Form Zugriff, laut http://blogs.technet.com/b/volume-licensing/archive/2014/03/10/licensing-how-to-when-do-i-need-a-client-access-license-cal.aspx müsste das in Ordnung sein.

bearbeitet 28. Juni 2014 von ASP.NET

[zahni 550]

Auch In Deinem verlinkten Blog steht nichts davon, dass sich die User gegen Windows anmelden müssen. Hier sind durchaus alle personalisierten Zugriffe gemeint.

Hier ist noch ein wenig zum Caching am Beispiel ASP.NET beschrieben:

http://www.nullskull.com/a/1515/aspnet-caching-concepts.aspx

 

Ich gehe mal davon aus, dass der IIS mit 'Pragma: no-cache' umgehen kann.

Wenn eine Anwendung, egal warum, eine Session bekommt, sollte sie extern nicht gecacht werden. Das muss dann die jeweilige Application übernehmen.

Z.B. kann man auch SQL-Queries cachen. Typo3 hat auch einen eigenen internen Cache.

[Daniel -MSFT- 129]

Hast Du den Strato-Rootserver mit der Windows Serverlizenz gemietet oder betreibst Du Deine eigene Lizenz auf dem Server (Bring your own license)?

 

In dem verlinkten Blogartikel steht übrigens explizit drin, dass Du CALs oder einen externen Connector brauchst. Der Verzicht auf die Authentifizierungsschnittstellen von Windows und der Einsatz von eigenen in dem CRM bedeutet nicht, dass man dann keine CALs braucht. Im Gegenteil - es kommt auf eine solche Unterscheidung überhaupt nicht an.

 

Zitat (Hervorhebungen von mir):

 

"Access to content, information, and/or applications within the internet web solution must be publically accessible. In other words, they cannot be restricted to you or your affiliate’s employees. Also whether you are running a “web workload” or not – if users exchange personally identifiable information, or are otherwise individually identifiable (or the users are authenticated via a Microsoft or third party product) – CALs or External Connector licenses will be required to access the Windows Server(s) used to authenticate/identify users."

Zur Frage: Als erstes denke ich da an TCP Offloading und VM Queuing. Hast Du die aktuellsten Netzwerkkartentreiber eingespielt? Schau Dir mal die Empfehlungen von http://blogs.technet.com/b/askpfeplat/archive/2013/03/10/windows-server-2012-hyper-v-best-practices-in-easy-checklist-form.asp

Alternativ kannst Du auch der Linux-VM die externe IP geben und Port 443 per Netcat umlenken oder Firewallregeln auf den IIS natten. Möglichkeiten gibt es da viele. Habt ihr auch mal daran gedacht, die Usersessions mit no-cache und no-proxy allowed über den IIS auszuliefern (das sollte das Caching der nicht-authentifizierten Sessions erlauben)? Wenn ihr Varnish weiterhin einsetzen wollt, solltet ihr nur sicherstellen, dass dieser private Seiten nicht cached: https://www.varnish-cache.org/trac/ticket/1124

bearbeitet 29. Juni 2014 von Daniel -MSFT-