Qual è la definizione di "bestiame non animali domestici"?

Il termine "tratta i tuoi server come bestiame e non animali domestici" è proliferato negli ultimi anni, in particolare quando applicato ai contenitori Docker e alle macchine virtuali

Cosa significa attualmente?

Randy Bias racconta la storia del termine affermando che probabilmente ha avuto origine nel 2011 o 2012 quando Bill Baker ha usato l'analogia nel descrivere strategie architettoniche "scale-up" vs "scale-out". Bias lo ha adottato nelle sue presentazioni sugli schemi architettonici delle nuvole:

Nel vecchio modo di fare le cose, trattiamo i nostri server come animali domestici, ad esempio Bob il server di posta. Se Bob scende, è tutto sul mazzo. Il CEO non può ricevere la sua email ed è la fine del mondo. Nel nuovo modo, i server sono numerati, come bestiame in una mandria. Ad esempio, da www001 a www100. Quando un server si arresta, viene rimosso, sparato e sostituito sulla linea.

Bias continua a definire Animali domestici come

Server o coppie di server trattati come sistemi indispensabili o unici che non possono mai essere disattivati. In genere sono costruiti, gestiti e "alimentati a mano" manualmente. Gli esempi includono mainframe, server solitari, bilanciamento del carico / firewall HA (attivo / attivo o attivo / passivo), sistemi di database progettati come master / slave (attivo / passivo) e così via.

e bestiame come

Matrici di più di due server, costruite utilizzando strumenti automatizzati e progettate per guasti, in cui nessuno, due o persino tre server sono insostituibili. In genere, durante gli eventi di errore non è richiesto alcun intervento umano poiché l'array mostra gli attributi di "routing intorno agli errori" riavviando i server guasti o replicando i dati attraverso strategie come la tripla replica o la codifica di cancellazione. Gli esempi includono array di web server, datastore multi-master come i cluster Cassandra, più rack di dispositivi messi insieme in cluster e qualsiasi cosa sia bilanciata dal carico e multi-master.

Fondamentalmente, ciò che Bias e Baker stanno cercando di comunicare è che ci deve essere una transizione dal modo in cui trattiamo i server da "Fiocchi di neve unici" con nomi e allegati emotivi, a un modello in base al quale se abbiamo un problema con il server creiamo una sostituzione e distruggere il server problematico.

Infine, probabilmente vale la pena ricordare che in ambienti regolamentati estrarre un server da dietro e sparare potrebbe non essere ottimale. In questi casi è spesso vantaggioso "congelare" il server, ad esempio utilizzando docker pauseper bloccare un contenitore. Questo può quindi essere utilizzato per eseguire un'analisi della causa principale come parte del processo di gestione degli incidenti o dei problemi.

Per aggiungere alla risposta di Richard, in genere l'analogia è utile in termini di considerazione dell'impatto della perdita di un server.

Se provi una sorta di angoscia per la perdita di un singolo pezzo di infrastruttura, consideralo un animale domestico (leggi l'antipasto).

Se ti sentiresti abbastanza a tuo agio sapendo che se una qualsiasi flotta smettesse di funzionare non ci sarebbe alcun impatto reale sulle operazioni, allora stai parlando di bestiame.

Spesso si è tentati di usare l'analogia per classificare semplicemente i propri server, vale a dire "i nostri nodi di carico di lavoro sono bovini ma i nostri bilanciatori di carico sono animali domestici", ma cadere in quella trappola è esattamente il problema. Non c'è posto per gli animali domestici in un moderno ambiente informatico (ad es. Nel cloud, su hardware di merce ecc.) Se tutti i tuoi server sono considerati bestiame e sono facilmente sostituibili, puoi iniziare a guardare cose come la scimmia del caos per aiutare costruire la certezza che la propria infrastruttura sia veramente resistente.