ASP.NET

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. 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. 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.

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.

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

Guten Tag, wir möchten verschiedene (Web)Anwendungen hosten, durch die ein relativ umfangreicher Mix aus verschiedenen Technologien zusammen kommt (siehe unten). Bisher haben wir schon etwas rumprobiert, wodurch wir zu dem Schluss gekommen sind auf jeden Fall zu virtualisieren, hauptsächlich um Konflikte zu vermeiden. Aber auch um das System skalierbar zu halten. Die Hostmaschine ist ein leistungsstarker QuadCore Xeon mit 32GB RAM und Windows Server 2012 R2. Zur virtualisierung soll das Microsoft eigene Hyper-V eingesetzt werden. Wir sind uns jedoch noch nicht so ganz sicher, wie wir das aufteilen und realisieren. Ein Mix aus Windows und Linux wird unvermeidbar sein, da z.B. Varnish nativ nur unter Linux läuft. Lösungen wie Cygwin gefallen mir nicht wirklich, ich ziehe da eine richtige Linux-VM vor. Erfahrung in der Administration von Windows und Linux ist vorhanden. Als Linux-Distribution wird Debian oder Ubuntu eingesetzt, das sollte denke ich keinen Unterschied machen. Zusätzlich werden noch ein paar Entwickler-Tools wie z.B. Jenkins dazu kommen. Um das ganze möglichst übersichtlich zu gestalten, werde ich unsere bisherigen Planungen und Bedenken strukturiert in einzelnen Punkten auflisten: Virtuelle Server: VM #1: Active Directory Der MS-Verzeichnisdienst soll das 'Herzstück' werden. Jeder Nutzer wird ein AD-Konto besitzen, und damit per Single Sign-on ALLE unsere Projekte nutzen können. Teilweise werden wir dafür in den Projekten selbst auf Plugins, teilweise auf Eigenentwicklungen zurückgreifen. Der AD-Server läuft in einer Windows Server 2012R2 VM. VM #2: Varnish Fronted-Server Varnish soll in einer Debian-VM auf Port 80 von außen erreichbar sein. Bei dem momentanen Traffic wird er schätzungsweise die Hälfte aller dynamisch generierten Requests cachen können. Die übrigen leitet er an den IIS (VM #3) und Tomcat (VM #4) weiter. VM #3: IIS + PHP + ASP.NET Der IIS ist unser Haupt-Backend und soll in einer zweiten VM mit Windows Server 2012 R2 laufen. Er kümmert sich um unsere PHP sowie ASP.NET Anwendungen. Momentan gibt es auf PHP-Basis sowohl fertige CMS-Systeme, aber auch Eigenentwicklungen. Selbst entwickelte ASP.NET Programme existieren noch nicht, werden bald folgen. Überlegung: IIS nur für ASP.NET nutzen, PHP mit einem schlanken Webserver wie nginx oder Lighttpd (würden beide vollkommen ausreichen) in einer Linux-VM laufen lassen. Vorteil: Bessere Performance Nachteil: Overhead durch zusätzliche VM und zusätzlicher Webserver, Infrastruktur wird komplizierter da PHP und ASP.NET Requests getrennt werden müssen. VM #4: Apache Tomcat Wird für eine JavaServer Pages Webanwendung benötigt, zu der wir bisher keine Alternative gefunden haben, die alle Anforderungen erfüllt. Hier ist eine vergleichsweise geringe Last zu erwarten, da dieser Server lediglich als Intranet für ca. 20 Leute genutzt wird. Als OS dürfte Linux sinnvoll sein. VM #5: MariaDB (MySQL Fork) Dieser Datenbankserver wird zurzeit ausschließlich für PHP-Projekte genutzt. Wir denken Linux wäre hier die beste Wahl. VM #6: MS-SQL Server 2013 MS-SQL soll ausschließlich für ASP.NET Anwendungen genutzt werden unter Windows Server 2012 R2. Überlegung1: MS-SQL komplett weglassen und stattdessen in ASP.NET auch den MySQL-Server aus VM #6 nutzen. Vorteil: Alle Daten zentral in einer Datenbank, keine zwei Datenbankserver (und damit eine extra VM) am laufen. Nachteil: Möglicherweise Performance-Einbußen oder Kompabilitätsprobleme in ASP.NET? MySQL-Treiber wurde in ASP.NET kurz angetestet und funktioniert offenbar, jedoch bisher keine ausführlicheren Tests und Vergleiche zu MSSQL. VM #7: Git Für eigene Software haben wir momentan testweise den TFS im Einsatz. Wahrscheinlich werden wir aber zu Git wechseln, da flexibler und besser für unsere Zwecke geeignet. Hier halten wir eine eigene VM für sinnvoll. OS noch nicht festgelegt. Virtualisierung Wir haben das ganze recht großzugüg aufgeteilt, da genug Ressourcen zur Verfügung stehen und wir Konflikte möglichst vermeiden wollen. Mit Hyper-V soll zudem der RAM dynamisch verteilt werden. Generell soll alles möglichst performant laufen. Kleinere Abstriche die der Vermeidung von Komplikationen und anderen Probleme dienen wären jedoch vertretbar. Die Server sollen ein internes Netzwerk bilden. Jeder Server erhält eine eigene interne IP. Über internes Routing und NAT soll die Kommunikation stattfinden. Varnish bekommt z.B. alle Requests der öffentlichen IP auf Port 80. Was nicht gecached werden kann wird an den IIS (192.168.0.2) bzw. Tomcat (192.168.0.3) weitergeleitet. Einschätzungen und Verbesserungsvorschläge sind natürlich gerne gesehen. Auch wenn ihr Erfahrung damit habt, bestimmte Komponenten zusammen auf eine Maschine zu legen, die wir hier getrennt haben. Gerade bei PHP würde mich stark interessieren, ob es sich lohnen würde das in eine Linux-VM zu legen, oder ob es da sinnvoller ist den IIS mit FastCGI zu nutzen.