Wir planen, die Last von 10 .NET 3.5-Webservern auszugleichen. Für die Sitzungsverwaltung verwenden wir den SQL 2008-Sitzungsstatusserver.
Was benötigen wir für den Lastenausgleich der .NET-Webserver?
Dinge, die wir bisher festgestellt haben:
- Die Webinhalte müssen identisch sein.
- Der Sitzungsstatusserver muss für Sitzungsstatusinformationen auf dasselbe SQL 2008 verweisen.
- Der Maschinenschlüssel muss in der Datei web.config derselbe sein.
Antwort1
Wenn Sie tatsächlich von einer Umgebung mit einem einzelnen Server zu einem Cluster mit Lastenausgleich von 10 Servern wechseln, schrillen bei mir sofort die Alarmglocken. Ich habe eine Reihe von Fragen, die Sie hoffentlich bereits beantwortet haben, aber ich werde sie trotzdem ansprechen und dann einige allgemeine Überlegungen anstellen.
Wie sind Sie auf die Zahl 10 gekommen? Warum skalieren Sie nicht auf 2 oder 3 und fügen bei Bedarf weitere hinzu?
Warum führen Sie überhaupt einen Lastausgleich durch? Wollen Sie beispielsweise hohe Last, hohe Verfügbarkeit oder beides? Besteht ein unmittelbarer Bedarf oder handelt es sich um einen vorhersehbaren Bedarf?
Wenn Sie jetzt unter Überlastung stehen und versuchen, das Problem durch Skalierung zu lösen, würde ich Ihnen vor allem die Frage stellen, ob Sie den Engpass tatsächlich identifiziert haben. Sie erwähnen, dass Sie .NET und SQL für den Sitzungsstatus verwenden. Ich würde also davon ausgehen, dass Sie auch mit einer SQL-gestützten Anwendung arbeiten. Balancieren Sie auch den SQL-Server aus? Kann der SQL-Server das Zehnfache der Verbindungen verarbeiten, die Sie jetzt haben?
Wenn Sie auf Verfügbarkeit setzen, haben Sie alle anderen Ausfallpunkte berücksichtigt? Haben Sie Redundanz auf Ihrem Load Balancer? Haben Sie Redundanz auf Ihren Datenbankservern? Haben Sie Redundanz auf Ihrem Internet-Uplink (berücksichtigen Sie alle Punkte: einzelnes Kabel, einzelner Switch usw.)? In Bezug auf die Verfügbarkeit sind Sie nur so sicher wie Ihr schwächstes Glied. Es spielt keine Rolle, ob Sie 10 oder sogar 100 Front-End-Webserver haben, wenn Sie nur einen Datenbankserver haben und dieser ausfällt.
Ihr Datenbankserver stellt häufig den Engpass dar. In diesem Fall spielt es keine Rolle, wie viele Frontends Sie haben.
Wenn Sie SSL verwenden, gibt es zwei typische Modi, in denen Load Balancer normalerweise arbeiten, die sich auf die Funktionsweise von SSL auswirken:
- Schicht 4: Dies ist die TCP-Ebene. SSL wird von jedem Server gehandhabt, und daher muss das SSL-Zertifikat auf jedem Server installiert werden.
- Schicht 7: Dies ist die Anwendungsebene, auch Reverse-Proxy genannt. Der Load Balancer verwaltet die HTTP-Sitzung und stellt eine zweite Verbindung zum Anwendungsserver her. In diesem Modus wird das SSL-Zertifikat nur auf dem Balancer installiert und die Verbindung zu App-Servern erfolgt normalerweise über HTTP. Dies wird manchmal als „SSL-Offloading“ bezeichnet und ist normalerweise nützlich, wenn Ihr Load Balancer leistungsstark ist und Sie nicht möchten, dass Ihr App-Server den Verschlüsselungsaufwand von SSL übernimmt (z. B. wenn Ihre App CPU-intensiv ist).
Stellen Sie sicher, dass Ihr Balancer so eingerichtet ist, dass Server aus der Rotation genommen werden, wenn sie ausfallen, und testen Sie diese Funktion. Sie sollten in der Lage sein, Server herunterzufahren, ohne dass dies Auswirkungen auf die übrigen Server hat. Beachten Sie die Überprüfungen von PING im Vergleich zu HTTP und Antwortzeit. (Ping bedeutet nicht, dass HTTP antwortet)
Führen Sie einen Belastungstest Ihrer Umgebung durch. Sie können möglicherweise nicht die volle Leistung erbringen, aber Sie sollten in der Lage sein, mindestens ein paar Server auszulasten (mit nur diesen beiden im Balancer).
Führen Sie eine Staging-Umgebung aus. Dies müssen nicht unbedingt 10 Server sein, sollte aber ausreichen, um das Produktionssystem für Bereitstellungstests zu replizieren.
Verwenden Sie ein automatisiertes Bereitstellungsskript und gehen Sie sehr streng mit der Quellcodeverwaltung und Konfigurationsverwaltung um. Im Idealfall bedeutet dies, dass ALLES (einschließlich Konfigurationsdateien) in einem Quellcodeverwaltungssystem liegt und Sie über automatisierte Builds verfügen, um alles bis hin zu Ihrem Installationsprogramm/Skript zu erstellen.
Holen Sie sich ein Tool, das sowohl Ihre externe Site als auch alle internen Server überwacht. Wenn ein Server ausfällt, ändert sich aus Sicht der Außenwelt nichts, aber Sie möchten es trotzdem wissen und den Server reparieren. Wenn Sie tatsächlich Probleme mit der Leistung oder Verfügbarkeit haben, möchten Sie nicht feststellen, dass drei Server seit einem Monat ausgefallen sind und der Rest mit der zusätzlichen Belastung zu kämpfen hat.