Architettura raccomandazione per carico bilanciato sito ASP.NET

Question

UPDATE 2009-05-21

Ho testato il metodo # 2 di utilizzare un unico condivisione di rete. Esso si traduce in alcuni problemi con Windows Server 2003 sotto carico:

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

aggiornamento fine

ho ricevuto una proposta per un sito ASP.NET che funziona nel modo seguente:

Hardware load balancer -> 4 server Web IIS6 -> SQL Server DB con cluster di failover

Ecco il problema ...

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

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

2) Inserire una singola copia dei file Web in una condivisione di rete accessibile dai 4 server Web. I web-root sui 4 server IIS verranno mappati sulla singola condivisione di rete.

Qual è la soluzione migliore? L'opzione 2 è ovviamente più semplice per le distribuzioni poiché richiede la copia dei file solo in una singola posizione. Tuttavia, mi chiedo se ci saranno problemi di scalabilità poiché quattro server web stanno tutti accedendo a un singolo set di file. IIS memorizzerà questi file in locale? Colpirebbe la condivisione di rete su ogni richiesta del cliente? Inoltre, l'accesso a una condivisione di rete sarà sempre più lento di ottenere un file su un disco rigido locale? Il carico sulla condivisione di rete peggiora notevolmente se vengono aggiunti altri server IIS?

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

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

UPDATE 2009-03-05

Per chiarire la mia situazione - gli "schieramenti" in questo sistema sono molto più frequenti di quanto 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 trasferite al sito live. Le implementazioni sono fondamentalmente "su richiesta". Teoricamente, questa spinta potrebbe accadere più volte in un minuto o più. Quindi non sono sicuro che sarebbe pratico implementare un server web alla volta. Pensieri?

Answer 1

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

Non si desidera che il singolo punto di contesa sia durante la distribuzione o quel singolo punto di errore nella produzione.

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

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

Answer 2

Se la vostra preoccupazione principale è la prestazione, che presumo sia da quando si spendono tutti questi soldi sull'hardware, quindi non ha senso condividere un filesystem di rete solo per comodità. Anche se le unità di rete sono estremamente performanti, non funzioneranno altrettanto bene quanto le unità native.

Distribuire le risorse Web è comunque automatico (giusto?), Quindi farlo in multipli non è davvero un inconveniente.

Se è più complicato di quello che si sta facendo, allora qualcosa come DeltaCopy potrebbe essere utile per mantenere quei dischi sincronizzati.

Answer 3

Un motivo per cui la condivisione centrale è negativa è 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

Che cosa ottieni in NLB con il 4IIS lo perdi con il BottleNeck con il server dell'app.

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 aiuti!

saluti!

Answer 5

Utilizzare uno strumento di distribuzione, con un processo che distribuisce uno alla volta e il resto del sistema continua a funzionare (come ha detto Mufaka). Si tratta di un processo collaudato che funzionerà sia con i file di contenuto sia con qualsiasi parte compilata dell'applicazione (che implementa causa un riciclo del processo asp.net).

Per quanto riguarda la frequenza degli aggiornamenti questo è qualcosa che è possibile controllare. Gli aggiornamenti passano attraverso una coda e hanno un unico processo di distribuzione che controlla quando distribuire ciascun elemento. Si noti che ciò non significa che si elabora ciascun aggiornamento separatamente, poiché è possibile acquisire gli aggiornamenti correnti nella coda e distribuirli insieme. Ulteriori aggiornamenti arriveranno in coda e verranno raccolti una volta terminata la serie di aggiornamenti corrente.

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

La coda non deve contenere tutte le informazioni, è sufficiente 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 far sì che si unisca alle informazioni da pubblicare, in modo da non doverle affrontare nello strumento/processo di pubblicazione.

Le modifiche del DB verranno eseguite durante il processo di pubblicazione, è sufficiente sapere dove sono le informazioni per le modifiche richieste e lasciare che lo strumento/processo di pubblicazione lo gestisca. Per quanto riguarda cosa usare per la coda, i 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: assicurarsi che le modifiche DB siano compatibili con le versioni precedenti. Questo è davvero importante, quando stai spingendo le modifiche in diretta su server diversi.

Answer 6

Abbiamo una situazione simile a voi e la nostra soluzione è utilizzare un modello di editore/sottoscrittore. La nostra app CMS memorizza i file effettivi in ​​un database e notifica un servizio di pubblicazione quando un file è stato creato o aggiornato. Questo editore quindi notifica a tutte le applicazioni Web sottoscriventi e quindi va a prendere il file dal database e posizionarlo sui propri file system.

Abbiamo gli abbonati impostati in un file di configurazione sull'editore, ma è possibile eseguire l'intera attività e fare in modo che l'app Web esegua l'iscrizione stessa all'avvio dell'app per semplificare ulteriormente la gestione.

È possibile utilizzare un UNC per lo storage, abbiamo scelto un DB per praticità e portabilità tra gli ambienti di produzione o di test (abbiamo semplicemente copiato il DB e abbiamo tutti i file del sito live e anche i dati).

Answer 7

Un metodo molto semplice di distribuzione su più server (una volta che i nodi sono stati configurati correttamente) è l'uso di robocopy.

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

robocopy è incluso nel MS ResourceKit - utilizzarlo con l'interruttore/MIR.

Answer 8

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

Con la maglia, si scarica un piccolo servizio Windows su ciascuna macchina Windows che si desidera nella mesh e quindi si nominano le cartelle sul sistema che fanno parte della mesh. Quando copi un file in una cartella Live Mesh - che è esattamente la stessa operazione che copia su qualsiasi altro foler sul tuo sistema - il servizio si occupa di sincronizzare quel file con tutti gli altri dispositivi partecipanti.

Come esempio tengo tutti i miei file sorgente di codice in una cartella Mesh e li faccio sincronizzare tra lavoro e casa. Non devo fare nulla per mantenerli sincronizzati con l'azione di salvataggio di 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 essere caricati su più server, e presumibilmente si devono applicare altri autori per tali modifiche, è possibile inserire il servizio Mesh su ciascun server Web e gli autori hanno aggiunto, modificato o rimosso i file gli aggiornamenti sarebbero spinti automaticamente. Per quanto riguarda gli autori, avrebbero semplicemente salvato i loro file in una normale cartella vecchia sul loro computer.

Answer 9

Con IIS6 e 7, lo scenario di utilizzo di una singola condivisione di rete su N macchine Web/app server collegate è esplicitamente supportato. MS ha fatto un sacco di test di perf per assicurarsi che questo scenario funzioni bene. Sì, viene utilizzato il caching. Con un server dual-NIC, uno per l'internet pubblico e uno per la rete privata, otterrai prestazioni davvero buone. Lo schieramento è a prova di proiettile.

Vale la pena dedicare del tempo a un benchmark.

È inoltre possibile valutare un provider di percorsi virtuali ASP.NET, che consente di distribuire un singolo file ZIP per l'intera app. Oppure, con un CMS, puoi pubblicare i contenuti direttamente da un database del contenuto, piuttosto che da un filesystem. Questo presenta alcune opzioni davvero interessanti per il controllo delle versioni.

VPP For ZIP via #ZipLib.

VPP for ZIP via DotNetZip.

Answer 10

Supponendo che i server IIS eseguano Windows Server 2003 R2 o superiore, è necessario cercare su DFS Replication. 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 trama piena). La replica si occupa automaticamente del resto incluso l'utilizzo della compressione differenziale remota per inviare solo i delta dei file che sono stati modificati.

Answer 11

Sono stato responsabile dello sviluppo di un sito web di giochi che ha avuto 60 milioni di visite al mese. Il modo in cui lo abbiamo fatto è stato l'opzione n. L'utente ha avuto la possibilità di caricare immagini e tali e quelli sono stati messi su un NAS che è stato condiviso tra i server. Ha funzionato abbastanza bene. Suppongo che tu stia facendo anche il caching delle pagine e così via, dal lato delle applicazioni della casa. Vorrei anche distribuire su richiesta, le nuove pagine a tutti i server contemporaneamente.

Answer 12

In una situazione ideale ad alta disponibilità, non ci dovrebbe essere un singolo punto di errore.

Ciò significa che una casella singola con le pagine Web su di essa è un no-no. Avendo svolto lavori di HA per un'importante Telco, inizialmente proponevo:

• Ciascuno dei quattro server ha la propria copia dei dati.
• In un momento di tranquillità, portare due dei server off-line (ad esempio, modificare il bilanciatore HA per rimuoverli).
• Aggiorna i due server off-line.
• Modificare il bilanciatore HA per iniziare a utilizzare i due nuovi server e non i due vecchi server.
• Verificare che per garantire la correttezza.
• Aggiornare gli altri due server e portarli online.

Ecco come è possibile farlo senza hardware aggiuntivo. Nel mondo anale a ritenzione del Telco ho lavorato per, ecco cosa avremmo fatto:

• Avremmo avuto otto server (al momento, abbiamo avuto più soldi di quanto si potrebbe colpire un bastone). Quando è arrivato il momento della transizione, i quattro server offline verrebbero configurati con i nuovi dati.
• Quindi il bilanciatore HA potrebbe essere modificato per utilizzare i quattro nuovi server e interrompere l'utilizzo dei server precedenti. Questo ha reso il passaggio (e, cosa più importante, il ritorno a capo se riempito) un processo molto veloce e indolore.
• Solo quando i nuovi server erano in esecuzione da un po 'di tempo prenderemmo in considerazione il prossimo passaggio. Fino a quel momento, i quattro vecchi server erano tenuti fuori linea ma pronti, per ogni evenienza.
• Per ottenere lo stesso effetto con un minore esborso finanziario, è possibile avere dischi aggiuntivi anziché interi server aggiuntivi. Il ripristino non sarebbe altrettanto rapido dato che dovresti spegnere un server per reinserire il vecchio disco, ma sarebbe comunque più veloce di un'operazione di ripristino.

Answer 13

Siamo felici di utilizzare 4 server Web ciascuno con una copia locale delle pagine e un server SQL con un cluster di failover.