Raccomandazione sull'architettura per il sito ASP.NET con bilanciamento del carico

Question

AGGIORNAMENTO 2009-05-21

Ho testato il metodo n. 2 per utilizzare una singola condivisione di rete. Si stanno verificando alcuni problemi con Windows Server 2003 sotto carico:

http://support.microsoft.com/kb/810886

fine aggiornamento

Ho ricevuto una proposta per un sito Web ASP.NET che funziona come segue:

Bilanciamento del carico hardware - > 4 server Web IIS6 - > DB di SQL Server con cluster di failover

Ecco il problema ...

Stiamo scegliendo dove archiviare i file web (aspx, html, css, images). Sono state proposte due opzioni:

1) Crea copie identiche dei file Web su ciascuno dei 4 server IIS.

2) Metti una singola copia dei file web su una condivisione di rete accessibile dai 4 server web. I webroot sui 4 server IIS verranno mappati sulla condivisione di rete singola.

Qual è la soluzione migliore? L'opzione 2 ovviamente è più semplice per le distribuzioni poiché richiede la copia dei file in un'unica posizione. Tuttavia, mi chiedo se ci saranno problemi di scalabilità poiché quattro server Web accedono tutti a un singolo set di file. IIS memorizzerà nella cache questi file localmente? Colpirebbe la condivisione di rete su ogni richiesta del client? Inoltre, l'accesso a una condivisione di rete sarà sempre più lento rispetto all'ottenimento di un file su un disco rigido locale? Il carico sulla condivisione di rete peggiora notevolmente se vengono aggiunti più server IIS?

Per dare una prospettiva, questo è per un sito web che attualmente riceve circa 20 milioni di hit al mese. Al picco recente, stava ricevendo circa 200 colpi al secondo.

Per favore fatemi sapere se avete una particolare esperienza con una tale configurazione. Grazie per l'input.

AGGIORNAMENTO 2009-03-05

Per chiarire la mia situazione, le "implementazioni" in questo sistema sono molto più frequenti di una tipica applicazione web. Il sito Web è il front-end per un CMS di back office. Ogni volta che il contenuto viene pubblicato nel CMS, le nuove pagine (aspx, html, ecc.) Vengono automaticamente inviate al sito live. Le distribuzioni sono sostanzialmente "su richiesta". Teoricamente, questa spinta potrebbe avvenire più volte entro un minuto o più. Quindi non sono sicuro che sarebbe pratico distribuire un server Web alla volta. Pensieri?

Answer 1

Condividerei il carico tra i 4 server. Non sono così tanti.

Non si desidera quel singolo punto di contesa né durante la distribuzione né quel singolo punto di errore nella produzione.

Durante la distribuzione, è possibile eseguirli 1 alla volta. Gli strumenti di distribuzione dovrebbero automatizzare ciò notificando al bilanciamento del carico che il server non deve essere utilizzato, distribuendo il codice, qualsiasi lavoro di pre-compilazione necessario e infine notificando al bilanciamento del carico che il server è pronto.

Abbiamo utilizzato questa strategia in oltre 200 server Web server e ha funzionato perfettamente per la distribuzione senza interruzione del servizio.

Answer 2

Se la tua preoccupazione principale è la prestazione, che presumo sia dal momento che stai spendendo tutti questi soldi per l'hardware, allora non ha molto senso condividere un filesystem di rete solo per comodità. Anche se le unità di rete hanno prestazioni estremamente elevate, non funzioneranno come le unità native.

L'implementazione delle risorse Web è comunque automatizzata (giusto?), quindi farlo in multipli non è davvero un inconveniente.

Se è più complicato di quanto non ti aspetti, forse qualcosa come DeltaCopy sarebbe utile per mantenere sincronizzati quei dischi.

Answer 3

Un motivo per cui la condivisione centrale è errata è perché rende la scheda di rete sul server di condivisione il collo di bottiglia per l'intera farm e crea un singolo punto di errore.

Answer 4

Con IIS6 e 7, lo scenario di utilizzo di una condivisione singola di rete su N macchine server Web / app collegate è esplicitamente supportato. MS ha fatto un sacco di test perf per assicurarsi che questo scenario funzionasse bene. Sì, viene utilizzata la memorizzazione nella cache. Con un server dual-NIC, uno per Internet pubblico e uno per la rete privata, otterrai prestazioni davvero buone. La distribuzione è a prova di proiettile.

Vale la pena prendersi il tempo per confrontarlo.

Puoi anche valutare un provider di percorsi virtuali ASP.NET, che ti consentirebbe di distribuire un singolo file ZIP per l'intera app. Oppure, con un CMS, potresti servire il contenuto direttamente da un database del contenuto, piuttosto che da un filesystem. Questo presenta alcune opzioni davvero interessanti per il controllo delle versioni.

VPP per ZIP tramite #ZipLib .

VPP per ZIP tramite DotNetZip .

Answer 5

In una situazione di elevata disponibilità ideale, non dovrebbe esserci un singolo punto di errore.

Ciò significa che una singola casella con le pagine web su di essa è un no-no. Dopo aver svolto il lavoro HA per un importante Telco, inizialmente proporrei quanto segue:

• Ciascuno dei quattro server ha la propria copia dei dati.
• In un momento di inattività, porta in off-line due server (ovvero modifica il bilanciamento HA per rimuoverli).
• Aggiorna i due server offline.
• Modifica il bilanciamento HA per iniziare a utilizzare i due nuovi server e non i due vecchi server.
• Provalo per assicurarti che sia corretto.
• Aggiorna gli altri due server e portali online.

Ecco come puoi farlo senza hardware aggiuntivo. Nel mondo di ritenzione anale di Telco per cui ho lavorato, ecco cosa avremmo fatto:

• Avremmo avuto otto server (al momento, avevamo più soldi di quanti tu potessi trovare). Al momento della transizione, i quattro server offline sarebbero stati configurati con i nuovi dati.
• Quindi il bilanciamento HA sarebbe modificato per usare i quattro nuovi server e smettere di usare i vecchi server. Ciò ha reso il passaggio (e, soprattutto, il ritorno se abbiamo riempito) un processo molto veloce e indolore.
• Solo quando i nuovi server erano in esecuzione da un po 'di tempo considereremmo il passaggio successivo. Fino a quel momento, i quattro vecchi server erano tenuti fuori linea ma pronti, per ogni evenienza.
• Per ottenere lo stesso effetto con un esborso finanziario inferiore, potresti avere dischi extra anziché interi server extra. Il recupero non sarebbe altrettanto rapido poiché dovresti spegnere un server per rimettere il vecchio disco, ma sarebbe comunque più veloce di un'operazione di ripristino.

Answer 6

Mi occupavo dello sviluppo di un sito Web di giochi con 60 milioni di hit al mese. Il modo in cui lo abbiamo fatto è stata l'opzione n. 1. L'utente ha avuto la possibilità di caricare immagini e simili e quelle sono state inserite in un NAS condiviso tra i server. Ha funzionato abbastanza bene. Suppongo che stai anche eseguendo la memorizzazione nella cache delle pagine e così via, sul lato dell'applicazione della casa. Distribuirò anche su richiesta, le nuove pagine su tutti i server contemporaneamente.

Answer 7

Quello che guadagni su NLB con 4IIS lo perdi con BottleNeck con l'app server.

Per la scalabilità, consiglierò le applicazioni sui server Web front-end.

Qui nella mia azienda stiamo implementando quella soluzione. L'app .NET nei front-end e un server APP per Sharepoint + un cluster SQL 2008.

Spero che sia d'aiuto!

saluti!

Answer 8

Abbiamo una situazione simile a te e la nostra soluzione è quella di utilizzare un modello di editore / abbonato. La nostra app CMS memorizza i file effettivi in ??un database e avvisa un servizio di pubblicazione quando un file è stato creato o aggiornato. Questo editore notifica quindi tutte le applicazioni Web di sottoscrizione e quindi vanno a prendere il file dal database e lo inseriscono nei loro file system.

Abbiamo gli abbonati impostati in un file di configurazione sull'editore, ma potresti andare avanti e fare in modo che l'app Web esegua l'abbonamento stesso all'avvio dell'app per semplificarne la gestione.

È possibile utilizzare un UNC per l'archiviazione, abbiamo scelto un DB per comodità e portabilità tra ambienti di produzione e test (copiamo semplicemente il DB e disponiamo di tutti i file del sito live e dei dati).

Answer 9

Un metodo molto semplice per distribuire su più server (una volta che i nodi sono impostati correttamente) è usare robocopy.

Preferibilmente avresti un piccolo server di gestione temporanea per i test e quindi "robocopy" su tutti i server di distribuzione (anziché utilizzare una condivisione di rete).

robocopy è incluso in MS ResourceKit : utilizzalo con l'opzione / MIR.

Answer 10

Per darti qualche spunto di riflessione potresti guardare qualcosa come Live Mesh di Microsoft . Non sto dicendo che è la risposta per te, ma potrebbe essere il modello di archiviazione che utilizza.

Con Mesh scarichi un piccolo servizio Windows su ogni macchina Windows che desideri nella tua Mesh e poi nomina le cartelle sul tuo sistema che fanno parte della mesh. Quando copi un file in una cartella di Live Mesh - che è esattamente la stessa operazione della copia su qualsiasi altro foler sul tuo sistema - il servizio si occupa di sincronizzare quel file con tutti gli altri dispositivi partecipanti.

Ad esempio, tengo tutti i miei file di codice sorgente in una cartella Mesh e li sincronizzo tra lavoro e casa. Non devo fare assolutamente nulla per mantenerli sincronizzati all'azione di salvare un file in VS.Net, Blocco note o qualsiasi altra app avvia l'aggiornamento.

Se si dispone di un sito Web con file che cambiano frequentemente e che devono andare su più server e presumibilmente per molti utenti autori di tali modifiche, è possibile inserire il servizio Mesh su ciascun server Web e quando gli autori aggiungono, modificano o rimuovono i file il gli aggiornamenti verrebbero inviati automaticamente. Per quanto riguarda gli autori, avrebbero semplicemente salvato i loro file in una normale vecchia cartella sul loro computer.

Answer 11

Utilizza uno strumento di distribuzione, con un processo che lo distribuisce uno alla volta e il resto del sistema continua a funzionare (come ha detto Mufaka). Questo è un processo provato che funzionerà sia con i file di contenuto che con qualsiasi parte compilata dell'applicazione (la cui distribuzione provoca un riciclo del processo asp.net).

Per quanto riguarda la percentuale di aggiornamenti è qualcosa che puoi controllare. Far passare gli aggiornamenti in una coda e disporre di un singolo processo di distribuzione che controlla quando distribuire ciascun elemento. Nota che questo non significa che elabori ogni aggiornamento separatamente, in quanto puoi prendere gli aggiornamenti correnti nella coda e distribuirli insieme. Ulteriori aggiornamenti arriveranno in coda e verranno prelevati al termine dell'attuale serie di aggiornamenti.

Aggiornamento: Informazioni sulle domande nel commento. Questa è una soluzione personalizzata basata sulla mia esperienza con processi pesanti / lunghi che richiedono il controllo del loro tasso di aggiornamenti. Non ho avuto la necessità di utilizzare questo approccio per scenari di distribuzione, in quanto per tali contenuti dinamici di solito vado con una combinazione di DB e cache a diversi livelli.

La coda non deve contenere le informazioni complete, deve solo disporre delle informazioni appropriate (ID / percorsi) che consentiranno al processo di passare le informazioni per avviare il processo di pubblicazione con uno strumento esterno. Dato che si tratta di un codice personalizzato, puoi unirlo alle informazioni da pubblicare, quindi non devi occupartene nel processo / strumento di pubblicazione.

Le modifiche al DB verrebbero eseguite durante il processo di pubblicazione, ancora una volta devi solo sapere dove sono le informazioni per le modifiche richieste e lasciare che il processo / strumento di pubblicazione le gestisca. Per quanto riguarda cosa usare per la coda, quelli principali che ho usato sono msmq e un'implementazione personalizzata con informazioni in SQL Server. La coda è lì solo per controllare la velocità degli aggiornamenti, quindi non è necessario nulla di specifico per le distribuzioni.

Aggiornamento 2: assicurati che le modifiche al tuo DB siano compatibili con le versioni precedenti. Questo è davvero importante, quando stai inviando le modifiche in tempo reale a server diversi.

Answer 12

Supponendo che i tuoi server IIS eseguano Windows Server 2003 R2 o versioni successive, consulta sicuramente Replica DFS . Ogni server ha la propria copia dei file che elimina un collo di bottiglia della rete condivisa, come molti altri hanno messo in guardia. La distribuzione è semplice come copiare le modifiche su uno qualsiasi dei server nel gruppo di replica (presupponendo una topologia a maglie complete). La replica si occupa automaticamente di tutto il resto, incluso l'uso della compressione differenziale remota per inviare solo i delta dei file che sono stati modificati.

Answer 13

Siamo abbastanza contenti di usare 4 server Web ciascuno con una copia locale delle pagine e un SQL Server con un cluster di failover.