Qual è il momento giusto per introdurre la disponibilità elevata per il sito Web?

16

Ci sono molti articoli sulle opzioni di alta disponibilità. Non è così ovvio, tuttavia QUANDO è il momento giusto per passare dalla configurazione del singolo server alla configurazione ad alta disponibilità.

Si prega di considerare la mia situazione:
http://www.postjobfree.com è un sito web 24/7 con traffico significativo:
http://www.similarweb.com/website/postjobfree.com

Attualmente lo eseguo su un singolo server: sia il server Web IIS 7.0 che SQL Server 2008 funzionano sulla stessa scatola hardware.

Si verificano occasionalmente (~ uno al mese) ~ 5 minuti di inattività causati solitamente dal riavvio richiesto da alcuni aggiornamenti di Windows Server. Di solito i tempi di fermo sono programmati e si verificano di notte. È comunque spiacevole, perché Google Bot e alcuni utenti sono ancora attivi di notte.

Le entrate correnti del sito Web sono pari a ~ $ 8.000 al mese.

Considero il passaggio alla configurazione a due server (web farm di 2 server Web e cluster di 2 server SQL ospitati su due server hardware).

Pro:
1) Alta disponibilità (teoricamente nessun tempo morto). Anche se uno dei server si arresta, un altro server subentrerebbe.
2) Nessuna perdita di dati: senza cluster SQL, è possibile perdere fino a un giorno di dati in caso di guasto dell'hardware (eseguiamo il backup giornaliero).

Contro:
1) Maggiore impegno per impostare e mantenere tale configurazione.
2) Costi di hosting più elevati. Invece di ~ $ 600 / mese sarebbe circa $ 1200 / mese.

Quale sarebbe la tua raccomandazione?

— Dennis Gorelik
fonte

La risposta alla mia domanda potrebbe influire sullo sviluppo. Ad esempio, posso considerare di dividere il database in parti e conservare i dati che richiedono alta affidabilità (input dell'utente) separatamente dai dati che richiedono alte prestazioni (calcoli).

2

Ciao Dennis, questa non è davvero una raccomandazione, quindi l'ho bloccata come commento, ma i tuoi costi di hosting sembrano piuttosto elevati per un singolo server Windows? Suppongo che sia un server completamente dedicato (non una VM), ma anche allora dovresti guardare forse metà del costo per un server di specifiche decente con 8 GB di RAM, una buona quantità di spazio su disco, ecc. Potrebbe valere la pena parlare con la tua società di hosting per ottenere un prezzo migliore.

— Ewan Leith,

6

Penso che l'alta disponibilità dovrebbe essere pianificata dal primo momento dell'ideazione del progetto.

— Tom O'Connor,

Ewan, voglio che il mio sito web funzioni velocemente, quindi ho un processore Quad con 8 GB di memoria e unità SDD. Fattore di costo delle licenze software (Windows, SQL Server), SSL e supporto tecnico. Hai una buona soluzione a basso prezzo per questo? Attualmente uso Server Intellect (supportato da SoftLayer) per l'hosting. Consiglieresti qualcosa di meglio?

— Dennis Gorelik,

2

Windows Update arriva con aggiornamenti di sicurezza. Se non patch il mio server, potrebbe essere vulnerabile agli attacchi. Quale frequenza di aggiornamento consiglieresti per il server di produzione di Windows?

— Dennis Gorelik,

15

Risposta breve: quando i tempi di inattività o il rischio derivano da un costo maggiore di quanto ti costerebbe avere un'alta disponibilità.

È fondamentalmente una decisione economica. Come esempio. $ 8k / mese implicano che un'interruzione di 2 ore ti costerà $ 22. Se riesci a configurare il tuo sistema in modo tale da poter passare da zero a un sito completamente funzionale in 2 ore, l'alta disponibilità ti farebbe guadagnare solo $ 22 di funzionalità oltre.

Detto in altro modo, puoi risparmiare denaro a meno che / fino a quando non hai 54 ore di inattività imprevedibile in un determinato mese.

— Slartibartfast
fonte

16

Devi considerare anche il rischio per la reputazione

— gbn

7

Il costo per ora di inattività dipenderà quasi sicuramente dal momento in cui il server si arresta. È molto improbabile che le transazioni siano distribuite uniformemente su un periodo di 24 ore. È più normale che si verifichino solo poche ore di punta, quando la perdita sarebbe molto maggiore.

— John Gardeniers,

Slartibartfast, capisco la tua risposta in questo modo: assicurati che il tempo di recupero dopo un guasto catastrofico sia ragionevole (poche ore), la perdita di dati sia ragionevole (poche ore) e mi permetta di avere brevi tempi di inattività programmati di volta in volta (almeno per ora) . Ciò significherebbe avere backup giornalieri, backup parziali incrementali e un server disponibile per ripristinare tutta quella configurazione. Suona bene?

— Dennis Gorelik,

Risposte: gbn: concordato; Stavo cercando una spiegazione semplice, ma la reputazione potrebbe facilmente essere un fattore significativo. John Gardeniers: Certo, ma se il sito viene utilizzato solo la domenica tra le 11:00 e le 13:00, i tempi di inattività programmati non sono un problema, mentre il prezzo da $ 2k per un'interruzione non pianificata di 2 ore lo è. A quel punto devi capire quanto è probabile che l'interruzione intempestiva (al costo di entrate di $ 2k) rispetto al certo costo di $ 600 / mese per il server addnl. Suggerimento: a meno che non si verifichino guasti casuali durante il periodo critico più spesso di 4 / anno, non ne vale la pena.

— Slartibartfast,

Dennis Gorelik: Decidi i rischi da cui vuoi proteggere (ad es. Perdita di attività commerciali durante la manutenzione, perdita di server, perdita di centro dati, account / sicurezza / problemi di database) e agire per proteggerli. In questo caso stai proteggendo dai tempi di fermo dovuti a manutenzione e guasti imprevedibili (per quanto ne so). Quello che descrivi dovrebbe fare il trucco, ma tieni presente che non devi possedere il server fintanto che puoi essere sicuro di poterlo procurare e impostarlo nel periodo di ripristino.

— Slartibartfast,

11

I tuoi stakeholder / business folk (che potresti essere tu!) Devono decidere

perdita accettabile di entrate
conseguenze perdita di reputazione, rispettabilità ecc
accettabile perdita di dati ( obiettivo del punto di ripristino )
tempo di inattività accettabile ( obiettivo del tempo di recupero )

La perdita di entrate è facile da quantificare: non si può rispondere al resto qui scusate ...

— GBN
fonte

2

Penso che la maggior parte degli utenti possa gestire un po 'di tempo di inattività pianificato. Considera che eBay ha aggiornamenti settimanali il venerdì sera e le offerte in giro a volte non funzionano. L'online banking della mia (maggiore australiana) banca ha programmato interruzioni per ore ogni settimana. Twitter è sempre offline. Heroku / EC2 era inattivo da giorni di recente.

Lo terrei in quella prospettiva, se in realtà parli solo 5 minuti al mese, stai facendo un ottimo lavoro come amministratore di sistema.

— Chris
fonte

1

Hai già menzionato Google come fattore in termini di indicizzazione, ma potrebbe anche valere la pena considerare l'impatto che la latenza / la reattività del sito potrebbe avere sul SEO. È una scatola nera e tutto il resto, così difficile da quantificare - anche se per quello che vale, Matt Cutts ritiene che sia un percento . Sarei più preoccupato per la reputazione, come hanno affermato altri.

1

Tieni presente che l'HA, come la sicurezza, non è un prodotto, ma piuttosto un processo.

Ad esempio, la replica del database ti porterà al punto in cui ciascun mirror del database sarà in grado di continuare da solo, ma avrai anche bisogno di una strategia per la risincronizzazione dopo la sostituzione dei componenti guasti.

Considera un sistema di ordinazione come esempio: il cliente invia un ordine e durante l'elaborazione il sistema fisico con cui stava parlando fallisce dopo aver memorizzato le informazioni dell'ordine nella sua copia locale del database. Impaziente, il cliente preme di nuovo "Invia" e viene indirizzato a un altro server, che accetta l'ordine. Se i database si risincronizzano semplicemente riproducendo le istruzioni INSERT mancanti sull'altro lato, l'ordine verrà duplicato, il che potrebbe non essere quello desiderato.

Come suggerito da @Slartibartfast, tutto si riduce a una decisione economica, tuttavia ti consiglio di pianificare anche qualche anno in futuro qui. Se ti aspetti di aver bisogno di una corretta configurazione HA, allora sarebbe un buon momento per mettere da parte le risorse per il lavoro preparatorio.

— Simon Richter
fonte

1

Mentre ci pensi, penso che tu consideri la creazione di una pagina "fail whale".

Ci sono molti modi per farlo, ma la combinazione aws di route53 e s3 funziona bene sui miei piccoli siti.

Ho impostato il dominio con controlli di integrità in modo che in caso di errori DNS invii gli utenti agli utenti a una pagina html statica che si trova in s3; Costa quasi nulla.

Nella mia esperienza avere il tuo sito dire "mi dispiace che le cose siano rotte ma ci stiamo lavorando" fa la differenza per gli utenti. Un account Twitter in cui è anche possibile comunicare con gli utenti è ancora meglio.

Ciò contribuisce a mitigare la "perdita di reputazione" che può essere l'impatto più significativo di un'interruzione.

vedi: https://aws.amazon.com/blogs/aws/create-a-backup-website-using-route-53-dns-failover-and-s3-website-hosting/ per una guida su come configurarlo.

Il failover sociale di DynDns http://dyn.com/managed-dns/social-failover/ è una cosa semplice.

È possibile eseguire il rollup dei propri controlli di integrità e quindi eseguire lo script delle modifiche DNS, a condizione che i record DNS abbiano un TTL basso e che sia possibile manipolarli in modo programmatico.

— Nath
fonte

Questi controlli di salute devono essere eseguiti dallo stesso server che ospita DNS? Non riesco a immaginare come effettuare l'aggiornamento DNS condizionale.

— Dennis Gorelik,

@DennisGorelik non necessariamente, ma i tuoi record DNS hanno bisogno di un breve TTL e qualunque cosa stia facendo il tuo controllo di salute deve essere in grado di cambiare rapidamente i record. Aggiornata la risposta con maggiori informazioni su come raggiungere questo obiettivo.

— Nath,

Un breve TTL per DNS in combinazione con la dipendenza dal controllo dello stato potrebbe rendere il sistema un po 'meno stabile (potrebbe cambiare anche se il server principale funziona correttamente). Potrebbe effettivamente peggiorare la situazione per gli utenti finali, non meglio.

— Dennis Gorelik,

Il TTL corto da solo non dovrebbe essere un problema con nessun fornitore DNS decente e se imposti una barra piuttosto bassa sui tuoi controlli di salute (cioè Failover se non http 200s per 10 minuti), la stabilità non è un problema. In alternativa puoi saltare la parte di controllo della salute e avere un ritaglio manuale. Ciò significherà un periodo di tempo più lungo in cui gli utenti ottengono il "timeout della connessione" e altri brutti errori ma nessuna possibilità di falsi positivi.

— Nath,

0

Hai mai pensato di utilizzare qualcosa come EC2 che ti consentirà di ridimensionare in modo flessibile e anche di negare i tuoi contro? In definitiva, è una decisione economica se valga la pena utilizzare EC2 o meno, ma è almeno un'opzione da considerare.

— Manku
fonte

-2

Per evitare la perdita di dati, dovresti esaminare le configurazioni Raid prima dei cluster. È inoltre necessario configurare un IP di failover che è possibile passare da un server all'altro in caso di disastro senza dover attendere la propagazione del DNS.

— YQT
fonte

da dove viene? cosa ti fa pensare che il poster non stia già utilizzando RAID?

— Chopper3

Chopper3. Tutto quello che ho detto è che Raid avrebbe risolto il suo problema di perdita di dati.

— YQT

2

Come? se un disco si fosse spento, ma se il suo controller fosse andato male

— Chopper3