Al momento disponiamo di una classica applicazione di livello n: DB / servizio web / front-end. Ha altri componenti, ma è il layout di base.

Vogliamo migliorare la disponibilità dell'applicazione per 3 motivi principali:

1. Il nostro host a volte subisce interruzioni (come fanno tutti) e vogliamo ridurre al minimo l'impatto sui nostri clienti, quindi, ad esempio, accenderebbero il centro dati B se il centro dati A è inattivo.
2. Quando aggiorniamo la versione, chiudiamo il sito per manutenzione e di solito ci vogliono alcune ore (script di migrazione, ecc.). Vorremmo che gli utenti avessero una transizione più fluida, con il minimo tempo di inattività possibile (usano il server B mentre il server A viene aggiornato).
3. Opzionalmente, i nostri clienti si trovano in tutto il mondo e vogliamo che abbiano la migliore esperienza possibile nonostante le loro connessioni forse scadenti (chiunque abbia lavorato con gli sviluppatori indiani dovrebbe sapere cosa intendo). Idealmente, vorremmo essere in grado di collegare un server nel loro ufficio (o utilizzare un datacenter vicino alla loro città) e si integrerebbe perfettamente nella nostra architettura.

Non abbiamo bisogno da remoto del 99% di disponibilità, nemmeno del 95%. È un'app di gestione dei documenti. A nessuno importa. Ma poiché le migrazioni possono richiedere del tempo e ci sono clienti in tutto il mondo, a volte impediamo a un cliente di lavorare per gran parte della giornata.

Per la parte SQL, anche se non ci sono DBA "corretti", conosciamo le possibilità di SQL : replica, mirroring, ecc. Sul lato DB, è abbastanza facile trovare risorse per questo. Ciò che è più difficile è tutto il resto: memorizzazione delle sessioni, del codice, ecc. Se il mio server web non funziona, come fa la mia IU a sapere che deve cambiare? Come vengono mantenute le mie sessioni tra i server?

Sfortunatamente, nessuno di noi ha esperienza in questo settore e non sappiamo nemmeno da dove cominciare a cercare. Ci sono le migliori pratiche per questo? Modelli di progettazione? Biblioteche (che dovrebbero essere gratuite perché non abbiamo soldi)?

Stiamo utilizzando ASP.Net e SQL Server, con un servizio web WCF nel mezzo. Abbiamo un sacco di servizi Windows in giro, ma non sono mission-critical e presumo che i metodi per gestire il sito Web saranno applicabili ai servizi.

Capisco che la maggior parte delle piattaforme cloud forniscono un sistema integrato per questo, ma l'hosting cloud è un no-go a causa del nostro amministratore di sistema, che vuole gestire tutto da solo e non fare affidamento su nessuno.

Devi chiarire che tipo di disponibilità elevata stai cercando. Esistono applicazioni ad alta disponibilità che eseguo e che richiedono un aumento del 95% delle volte. Ci sono altri che devono funzionare al 99%. Posso pensare a scenari di vita o di morte che richiedono un uptime del 100%. Solo quei tre hanno approcci e costi drasticamente diversi.

Indovina solo in base alle tue esigenze e uno SLA di uptime del 95-99%:

• Le migrazioni del database dovrebbero poter avvenire in tempo reale per la maggior parte delle modifiche. Pratica progettazione di database evolutivi . Per le modifiche che richiedono un comportamento più invasivo, sono disponibili alcune opzioni. Uno è il tempo morto. Se possibile, l'esecuzione del servizio in modalità di sola lettura potrebbe funzionare. Per la piena funzionalità, ho voluto provare ScaleArc per un po '. Sembra uno strumento davvero fluido per il ridimensionamento e la resilienza nel mondo di SQL Server.
• Inserire i server nei siti dei clienti è una ricetta per un disastro ingestibile a meno che non si disponga di strategie di distribuzione di livello mondiale (che, in base alla descrizione delle migrazioni, non sono ancora disponibili). Non inviare i servizi cloud on-prem perché hai problemi di prestazioni. Risolvi i problemi di prestazioni di tanto in tanto non dovrai occuparti di quelli più costosi fatti su strada.
• Il tuo server di stato dovrebbe essere un database di qualche tipo. Segui le loro linee guida HA. È possibile utilizzare SQL Server per questo, poiché è già disponibile.
• Parlando di database, la replica non abilita l'HA. In effetti, la replica SQL causerà mal di testa in ogni momento (parlando per esperienza con scenari di replica a più nodi). Il mirroring può funzionare, ma per ultimo ricordo che il clustering SQL richiede 1-5 minuti per il failover sul nuovo server. Ho sentito cose positive su AlwaysOn, ma sono ancora sospettoso, dato il track record di Microsoft. Qualcosa come ScaleArc potrebbe essere di maggiore aiuto qui.
• Il tuo server web dovrebbe essere apolide. Fai girare tre o quattro e mettili dietro un bilanciamento del carico. Questo risolve le preoccupazioni di uptime lì. Come menzionato in precedenza da Frederik, è anche possibile eseguire distribuzioni rolling in questo modo.
• Il tuo servizio web dovrebbe probabilmente essere apolide. In caso contrario, vedere se è possibile suddividerlo in bit senza stato e con stato. Mettere più istanze di esso dietro lo stesso bilanciamento del carico risolve nuovamente i problemi di uptime e consente scenari di distribuzione più interessati (ad esempio distribuzioni blu / verde).

A differenza di Frederik, non definirò la tua paranoia cloud ingiustificata. Dipende dai requisiti di uptime. È ipotizzabile che un servizio debba essere eseguito in più data center gestiti da diversi provider in diversi paesi per motivi di ridondanza. Dato il tuo stato attuale, tuttavia, concordo sul fatto che AWS, Azure o simili sono probabilmente scommesse sicure per la tua azienda.

Ottenere un certo livello di HA sul livello Web e delle applicazioni:

1. Idealmente, scomporre qualsiasi stato, incluso lo stato della sessione in sistemi a stato condiviso come un database o un server dello stato della sessione in memoria. A seconda della progettazione dell'applicazione, ciò può causare problemi di prestazioni a causa della latenza aggiunta che ottiene una grande quantità di stato.

2. Il sito Web e il livello applicazione devono avere ciascuno un bilanciamento del carico indipendente davanti a loro. NGINX farà il trucco, ma anche IIS può farlo (ARR).

3. Se un singolo database non è in grado di gestire il carico, sfruttare il partizionamento dello stato della sessione (o sharding o hashing coerente) per instradare una particolare richiesta a una particolare casella di database.

Se lo stato del factoring è troppo difficile, è possibile utilizzare l'affinità del server per il bilanciamento del carico (ovvero gli utenti vengono instradati in modo coerente nella stessa casella, spesso basata su cookie). Non è altamente disponibile come un approccio round robin apolide, perché un'interruzione della scatola avrà un impatto su tutti gli utenti e lo dichiarerà su quella casella, ma batte un'interruzione completa (dipendente dal caso d'uso).

Per quanto riguarda l'aggiornamento:

1. Progettare gli script del database in modo tale da poter eseguire gli aggiornamenti del database mentre il sistema è in esecuzione, in altre parole, mantenere la compatibilità con le versioni precedenti. Un modello che funziona bene per questo è "espandi, quindi contratta" -> apporta solo modifiche additive, retrocompatibili ma rimuovendo le dipendenze dai campi (ecc.) Di cui vuoi liberarti; quindi aggiornare tutti i client del database a v-latest; quindi eseguire un altro aggiornamento db per eliminare i vecchi campi (ecc.) nel database. Questo può essere un processo lento se si dispone di un database di grandi dimensioni e si deve fare attenzione a non ridurre le prestazioni del sistema.

2. Aggiornamento del livello app: poiché non si utilizza un ambiente cloud, ti consiglio di seguire il modello di distribuzione canary: esegui un aggiornamento continuo delle tue caselle Web e di livello intermedio. Se la distribuzione non va a buon fine, estrarre la scatola dal bilanciamento del carico, proprio come se si fosse verificato un errore.

Avvertenza: l'evoluzione di un sistema che non è stato progettato per l'HA in uno che è, può essere un processo lungo e costoso. Dovrai fare dei compromessi lungo il percorso (costo vs sforzo per raggiungere un determinato livello di disponibilità)

La tua paranoia nel cloud è ingiustificata - fornitori come AWS in combinazione con le buone pratiche da parte tua possono controllare / mitigare la maggior parte dei rischi - dai un'occhiata alla loro pagina di conformità per avere un'idea di quali regolamenti sono conformi: https: // aws .amazon.com / compliance /

TL; DR: costruzione ridondante, modulare; verifica la disponibilità; monitorare attentamente.

Dopo aver realizzato che provare a spremere qualsiasi spiegazione potrebbe richiedere molto tempo, quindi scriverò tutte le osservazioni che ho fatto.

Mettere in discussione la premessa

Il sistema cloud è una panacea

Anche se dovessi andare completamente sul cloud, con un fornitore di cloud leader, dovrai comunque progettare la tua applicazione per la resilienza. AWS potrebbe sostituire la VM, ma l'applicazione dovrebbe essere in grado di riavviarsi se lasciata nel mezzo del calcolo.

Non vogliamo usare il sistema cloud, a causa di x / y / z

A meno che tu non sia un'organizzazione ultra grande, stai meglio usando i sistemi cloud. I primi 3 sistemi cloud (AWS, MSFT, Google), impiegano migliaia di ingegneri per offrirti SLA promessi e dashboard facile da gestire. In realtà è un buon affare usarli al posto di spendere un centesimo su questo in-house.

Problemi di scoping e design

Definire, quantificare e quindi misurare continuamente la disponibilità di un servizio è una sfida più grande della scrittura di una soluzione per i problemi di disponibilità.

Definire e misurare la "disponibilità" è più difficile del previsto

Diverse parti interessate hanno una visione diversa della disponibilità e ciò che può accadere è la definizione preferita da una persona con il salario più alto che supera altre definizioni. Questa è talvolta una definizione corretta, ma spesso l'ecosistema non è costruito attorno alla misurazione della stessa cosa perché quella definizione ideale è molto difficile da misurare, per non parlare del monitoraggio in tempo reale. Se hai una definizione di disponibilità che non può essere monitorata in tempo reale, troverai il tuo progetto simile fai da te ancora e ancora con strane somiglianze. Attenersi a qualcosa di sensato e qualcosa che può essere facilmente monitorato.

Le persone sottovalutano le complessità del sistema sempre disponibile.

Per parlare dell'elefante nella stanza, lasciami dire questo: "Nessun sistema multi-computer è disponibile al 100%, potrebbe in futuro ma non con la tecnologia attuale". Qui con la tecnologia attuale, mi riferisco alla nostra incapacità di inviare segnali più velocemente della velocità della luce e cose del genere. Tutti gli ingegneri informatici che meritano il loro sale conoscono i limiti del calcolo distribuito e la maggior parte di loro non lo menzionerà nelle riunioni, temendo che sembreranno dei rumori. Per compensare tutti coloro che non menzionano i limiti del calcolo distribuito , dirò, è complicato ma non sempre fidarsi dei computer .

Le persone sopravvalutano le capacità del proprio ingegnere

Sfortunatamente, la disponibilità rientra nella categoria, dove non sai cosa vuoi ma sai cosa non vuoi. È un po 'più complicato che la categoria "conosci i desideri" come l'interfaccia utente. Richiede un po 'di esperienza e molta lettura per imparare dall'esperienza altrui e altro ancora.

Costruire un sistema disponibile da zero

Assicurati di evangelizzare per ogni team di architettura e design la giusta priorità della disponibilità come requisito di sistema.

Attributi del sistema che aiutano la disponibilità

Le seguenti caratteristiche del sistema hanno dimostrato di aver contribuito alla disponibilità del sistema:

Ridondanza

Alcuni esempi di questo sono di non avere mai una sola VM dietro un VIP o di non archiviare mai una sola copia dei tuoi dati. Queste sono le domande che un buon IAAS ti renderà più facile da risolvere, ma dovrai comunque prendere queste decisioni.

modularità

Un REST modulare è migliore del SOA monolitico. Un microservizio persino modulare è in realtà più disponibile rispetto al solito REST HATEOS . Il ragionamento potrebbe essere trovato nella discussione relativa alla resa nella prossima sezione. Se si sta eseguendo l'elaborazione in batch, è meglio l'elaborazione in batch in un batch ragionevole di 10s rispetto alla gestione di un batch di 1.000.000.

elasticità

"I am always angry"
                    - Hulk

Un sistema resiliente è sempre pronto per il ripristino. Questa resilienza si applica a casi come il riconoscimento di ACK per una scrittura solo dopo la scrittura sul disco RAID, e possibilmente su almeno due data center. Un'altra tendenza recente è quella di utilizzare strutture di dati prive di conflitti , in cui la struttura dei dati si assume la responsabilità di risolvere i conflitti quando viene presentata con due versioni diverse. Un sistema non può essere resiliente come ripensamento, deve essere previsto e integrato. Un fallimento è garantito a lungo termine, quindi dovremmo essere sempre preparati con un piano di recupero.

Traccia di registro

Questo è tecnicamente un sottotipo di Resilienza, ma molto speciale perché cattura tutte le funzionalità. Nonostante il massimo sforzo, potremmo non essere in grado di prevedere il modello di indisponibilità. Se possibile, mantenere una traccia log sufficiente delle attività di sistema per poter riprodurre eventi di sistema. Ciò consentirà, a costi manuali elevati, di riprendersi da situazioni impreviste.

Attributi di disponibilità

L'elenco di attributi "non disponibili" non esaustivi di "disponibilità": per motivi di discussione, supponiamo che la domanda che l'utente pone sia: "Quanti articoli ho nel carrello?"

Correttezza

Non si deve produrre il più preciso possibile risposta o è errori make ok? Solo per riferimento, quando si preleva denaro dal bancomat, non è garantito che sia corretto. Se la banca scopre che ha commesso un errore, potresti invertire le transazioni. Se il tuo sistema sta producendo numeri primi, quindi immagino, potresti voler sempre risposte giuste.

dare la precedenza

Salta questo punto, se hai sempre risposto correttamente alla domanda precedente sull'argomento. A volte la risposta alle domande non deve essere precisa, ad es. Quanti amici ho su Facebook in questo momento? Ma la risposta dovrebbe essere sempre nel campo da baseball +/- 1. Quando produci il risultato atteso, la tua resa è 100.

Consistenza

La tua risposta potrebbe essere corretta in un determinato momento, ma quando la luce ha lasciato lo schermo ed è entrata nella retina dell'osservatore, le cose potrebbero essere cambiate. Rende la tua risposta sbagliata? No, lo rende incoerente. Molte applicazioni sono eventualmente coerenti, ma il trucco sta nel definire quale tipo di modello di coerenza fornirà la tua applicazione. Per caso la tua applicazione può essere eseguita su un singolo computer, puoi saltare questa bella lettura sul teorema di CAP .

Costo

Molto dipende dall'impatto totale degli effetti a breve termine (perdita di entrate) e degli effetti a lungo termine (cattiva reputazione, fidelizzazione dei clienti). A seconda del tipo di cliente (pagamento / gratuito, ripetizione / unico, captive) e disponibilità delle risorse, è necessario integrare diversi livelli di garanzia di disponibilità.

Verso il miglioramento della disponibilità di un sistema esistente

La gestione operativa delle singole macchine e di una rete è così complessa, che presumo tu l'abbia lasciato al fornitore del cloud o che tu sia già abbastanza esperto da sapere cosa stai facendo. Toccerò altri argomenti in base alla disponibilità. Per la strategia a lungo termine Define-Measure-Analyse-Control è una partita paradisiaca, qualcosa che mi sono visto.

1. Definisci cos'è la "disponibilità" per i tuoi stakeholder
2. Come misurerai ciò che hai definito
3. Analisi della causa principale per identificare i colli di bottiglia
4. Compiti per miglioramenti
5. Monitoraggio continuo ( controllo ) del sistema

Cause di non disponibilità

Poiché abbiamo concordato che la gestione operativa che dovrebbe coprire qualsiasi gestione delle infrastrutture fisiche, dovrebbe essere effettuata da professionisti, toccherò altre cause di indisponibilità per completezza. La disponibilità dell'IMO dovrebbe includere anche la mancanza di comportamenti previsti, il che significa che se all'utente non viene mostrata l'esperienza prevista, qualcosa non è disponibile. Con questa ampia definizione in mente, ciò che segue potrebbe causare indisponibilità: - Bug di codice - Incidenti di sicurezza - Problemi di prestazioni