Wie kann man SQL Server 2008 für ASP.NET-Anwendungen mit hoher Auslastung ausgleichen?

Stellen Sie sich vor, Sie haben eine erfolgreiche Webanwendung, die ASP.NET und IIS 7 verwendet. Sie generiert viele Aufrufe an eine SQL Server 2008-Datenbank und wird voraussichtlich mit einer Verfügbarkeit von 99,9% für die Öffentlichkeit verfügbar sein (Ausfallzeit von 8 Stunden, 45 Minuten pro Sekunde) Jahr).

Unsere Ziele sind:

• Installieren Sie Windows-Updates auf dem Server, ohne dass dies zu Ausfallzeiten für unsere Kunden führt
• Verhindern Sie, dass Hardware-Abstürze auf dem Server ASP.NET-Anwendungen aufgrund von Zeitüberschreitungen verlangsamen

Im Gegensatz zum Lastenausgleich einer ASP.NET-Anwendung scheint der Lastenausgleich in SQL wesentlich schwieriger zu sein. Was sind Ihre bewährten Methoden zum Einrichten eines einfachen SQL Server 2008 R2-Clusters mit Lastenausgleich für einen Micro-ISV, der den Microsoft-Stapel verwendet?

Wenn Sie eine hohe Verfügbarkeit benötigen, bieten Windows / SQL Server-Clustering oder SQL Server-Datenbankspiegelung Lösungen. Das Clustering erfordert viel Planung und Einarbeitung, wenn Sie es noch nie zuvor durchgeführt haben, ist jedoch für die Anwendung transparent.

Der Lastenausgleich ist mit SQL Server möglich, aber nichts für schwache Nerven. Hierbei handelt es sich um eine Lösung, die den Windows-Netzwerklastenausgleich (Network Load Balancing, NLB) vor den SQL-Servern verwendet. Die SQL Server selbst in der NLB sind einfacher zu verwalten, wenn sie schreibgeschützt sind. Wenn Sie die Transaktionsreplikation mit aktualisierbaren Abonnenten verwenden, können sie jedoch mit Lese- und Schreibzugriff ausgeführt werden. Diese Art der Replikation ist jedoch in einer zukünftigen Version als veraltet markiert.

Eine letzte Möglichkeit sind skalierbare gemeinsam genutzte Datenbanken, die jedoch definitiv schreibgeschützt sind.

Lesen Sie weiter:

Sehen Sie sich die Apress-Bücher von Allan Hirt zu SQL Server 2005 High Availability und Pro SQL Server 2005/2008 Replication von Apress an.

Skalierbare gemeinsam genutzte Datenbanken: http://technet.microsoft.com/en-us/library/ms345392.aspx

Relationale Datenbanksysteme werden selten so wie Webserver mit einem Lastenausgleich versehen. Das Problem mit dem klassischen Ansatz zum Lastenausgleich besteht darin, dass alle Ihre Datenbanken in ständiger Synchronisation sein müssen. Das relationale Modell ist wertlos, wenn zwei Server zu keinem Zeitpunkt den gleichen Status haben.

Aus Ihrer Frage geht hervor, dass Sie nicht einmal versuchen, einen Lastenausgleich durchzuführen. Dies ist in erster Linie eine Leistungsmessung, um sicherzustellen, dass nur so viele Benutzer auf jeden Server zugreifen, wie dieser Server verarbeiten kann. Es hört sich so an, als ob Sie ein Hochverfügbarkeits- Setup wünschen . Da Sie sagen, dass Sie SQL Server verwenden, würde ich mich mit Failovers befassen. Dies bedeutet, dass Clients versuchen, auf die Failover-Server zuzugreifen, wenn die Primärdatenbank nicht verfügbar ist. SQL Server verwaltet die Synchronisierung der Primärinstanz und jedes Failovers sowie die Neusynchronisierung der Primärinstanz mit dem Failover, wenn die Primärinstanz wieder online ist und nicht mehr offline ist.

Ok, los geht's. NICHT MACHBAR. Nicht ohne App-Änderungen.

• Installieren Sie Updates. Verwenden Sie entweder Clustering oder Spiegelung, um sicherzustellen, dass Sie ZWEI Datenbanken haben, die funktionieren oder schneller auf einen anderen Computer übertragen werden können. Spiegelung stark bevorzugt.
• Schreiben Sie die Anwendung neu, um dies zu beheben (dh, wenn die Verbindung fehlschlägt, muss die Verbindung transparent wiederhergestellt werden, damit eine Verbindung zu einer Kopie hergestellt werden kann).

Beachten Sie, dass Sie die App für Wartungszwecke immer noch herunterfahren müssen, wenn Sie eine neue Kopie bereitstellen oder Änderungen am DB-Schema vornehmen.

Eine kostengünstige Lösung besteht darin, die Datenbank häufig mit einem kostengünstigen Server mit ausgeglichenem Warenbestand zu puffern, der Anwendungsdienste hostet, die Logikverarbeitung und Datenspeicherung bereitstellen und ansonsten Datenbankressourcen belegen würden. Offensichtlich erfordert dies einige Überlegungen zu Datenvolatilität und Caching-Strategien.

Lassen Sie mich eine jurassische Antwort geben. Wenn Ihre Ziele "Installieren von Windows-Updates" umfassen, sind Sie nicht mehr zu retten.

Ich habe einen grauen Bart und kann mich an eine Zeit erinnern, in der eine Anwendung 10 Jahre lang ausgeführt werden konnte, ohne dass "Betriebssystem-Updates" durchgeführt werden mussten. Die Nutzungsdauer einer App wurde in Jahrzehnten und nicht in Jahren gemessen.

Mein Rat lautet also: Richten Sie eine funktionierende Version Ihrer SQL Server-Datenbank + -Anwendung ein und ISOLIEREN SIE DEN DATENBANK-SERVER AUS MICROSOFT-UPDATES. Wenn es nicht kaputt ist, reparieren Sie es nicht.

Verwenden Sie Hot-Swap-fähige RAID-Festplatten.

Halten Sie einen Spiegelbild-Datenbankserver (gemäß dem Vorschlag von TomTom) für den Fall bereit, dass Ihre Hardware ausfällt.