Come bilanciare il carico di SQL Server 2008 per applicazioni ASP.NET ad alto utilizzo?

Immagina di avere un'applicazione Web di successo che utilizza ASP.NET e IIS 7. Genera molte chiamate a un database SQL Server 2008 e dovrebbe essere disponibile al pubblico con tempi di attività del 99,9% (tempo di inattività di 8 ore, 45 minuti per anno).

I nostri obiettivi sono:

• Installa gli aggiornamenti di Windows sul server senza causare tempi di inattività per i nostri clienti
• Impedire l'arresto anomalo dell'hardware sul server dal rallentamento delle applicazioni ASP.NET a causa dei timeout

A differenza del bilanciamento del carico di un'applicazione ASP.NET, il bilanciamento del carico SQL sembra essere molto più difficile. Quali sono le best practice per la configurazione di un semplice cluster SQL Server 2008 R2 con bilanciamento del carico per un Micro-ISV che utilizza lo stack Microsoft?

Se è necessaria la disponibilità elevata, le soluzioni di clustering di Windows / SQL Server o Mirroring del database di SQL Server offrono soluzioni. Il clustering richiede molta pianificazione e familiarizzazione se non l'hai mai fatto prima, ma sarà trasparente per l'applicazione.

Il bilanciamento del carico è possibile con SQL Server, ma non è per i deboli di cuore. È una soluzione che utilizza Bilanciamento carico di rete (NLB) di Windows davanti ai server SQL. I server SQL stessi nel bilanciamento del carico di rete sono più facili da gestire se sono di sola lettura, ma possono essere di lettura-scrittura se si utilizza la replica transazionale con abbonati aggiornabili. Questo tipo di replica è tuttavia contrassegnato per la deprecazione in una versione futura.

Un'ultima possibilità sono i database condivisi scalabili, ma sono sicuramente di sola lettura.

Più lettura:

Dai un'occhiata ai libri Apress di Allan Hirt su SQL Server 2005 High Availability e Pro SQL Server 2005/2008 Replication di Apress.

Database condivisi scalabili: http://technet.microsoft.com/en-us/library/ms345392.aspx

I sistemi di database relazionali raramente vengono bilanciati in base al carico allo stesso modo dei server Web. Il problema con l'approccio classico al bilanciamento del carico è che tutti i database devono essere in costante sincronizzazione. Il modello relazionale è inutile se due server non hanno lo stesso stato in qualsiasi momento.

Dalla tua domanda, non sembra che tu stia nemmeno cercando di realizzare il bilanciamento del carico, che è principalmente una misura delle prestazioni per garantire che solo un numero pari di utenti colpisca ciascun server quanti ne è in grado di gestire. Sembra che tu voglia una configurazione ad alta disponibilità . Dato che dici che stai usando SQL Server, esaminerei i failover. Ciò significa che, se il database primario non è disponibile, i client tenteranno di accedere ai server di failover. SQL Server gestisce la sincronizzazione dell'istanza primaria e di ogni failover e gestisce anche la risincronizzazione dell'istanza primaria con il failover quando il primario torna online dalla modalità offline.

Ok, eccoci. NON PUÒ ESSERE FATTO. Non senza modifiche all'app.

• Installa gli aggiornamenti: usa il clustering o il mirroring per assicurarti di avere DUE database che funzionano o possono eseguire il failover più velocemente su un altro computer. Il mirroring è fortemente preferito.
• Riscrivi l'applicazione per gestirla (ad es. Connessioni non riuscite, è necessario riconnetterle in modo trasparente, quindi si connette a una copia).

Tieni presente che devi comunque smontare l'app per manutenzione quando distribuisci una nuova copia / apporta modifiche allo schema db.

Una risposta economica qui è abbastanza spesso per bufferizzare il database con un servizio di applicazioni di hosting di livello server bilanciato a basso costo che fornisce elaborazione logica e archiviazione dei dati che altrimenti legerebbero le risorse del database. Ovviamente ciò richiede una riflessione sulla volatilità dei dati e sulle strategie di memorizzazione nella cache.

Lascia che ti dia una risposta giurassica. Se i tuoi obiettivi includono "installare gli aggiornamenti di Windows", non puoi fare altro.

Ho la barba grigia e ricordo un momento in cui un'applicazione poteva funzionare 10 anni senza dover subire "aggiornamenti del sistema operativo". La durata utile di un'app è stata misurata in decenni, non anni.

Quindi il mio consiglio è questo: stabilire una versione funzionante del database + applicazione di SQL Server e ISOLARE IL SERVER DATABASE DAGLI AGGIORNAMENTI DI MICROSOFT. Se non è rotto, non ripararlo.

Utilizzare dischi RAID sostituibili a caldo.

Avere a portata di mano un server di database di immagini speculari (su suggerimento di TomTom) nel caso in cui l'hardware si rompa.