Ehi Habr! Presento alla vostra attenzione la traduzione dell'articolo di Adib Daw.
Se quel titolo non ti fa venire un leggero brivido lungo la schiena, dovresti passare al paragrafo successivo o visitare la nostra pagina dedicata a - vorremmo parlare.
Кто мы
Siamo un team di 4 pinguini che amano scrivere codice e lavorare con l'hardware. Nel nostro tempo libero, siamo responsabili dell'implementazione, della manutenzione e del funzionamento di una flotta di oltre 7000 server fisici che eseguono Linux, distribuiti in 3 diversi data center negli Stati Uniti.
Abbiamo avuto l'opportunità di farlo anche a 10 km di distanza dai siti, comodamente dal nostro ufficio, situato a breve distanza dalla spiaggia sul Mar Mediterraneo.
Problemi di scala
Sebbene sia logico per una startup iniziare ospitando la propria infrastruttura nel cloud a causa dell'investimento iniziale relativamente basso, noi di Outbrain abbiamo deciso di utilizzare i nostri server. Lo abbiamo fatto perché i costi dell'infrastruttura cloud superano di gran lunga i costi di gestione delle nostre apparecchiature situate nei data center dopo lo sviluppo fino a un certo livello. Inoltre, il server offre il massimo grado di controllo e funzionalità di risoluzione dei problemi.
Man mano che ci sviluppiamo, i problemi sono sempre vicini. Inoltre, di solito vengono in gruppi. La gestione del ciclo di vita dei server richiede un costante miglioramento personale per poter funzionare correttamente nel contesto del rapido aumento del numero di server. I metodi software per la gestione dei gruppi di server nei data center diventano rapidamente ingombranti. Rilevare, risolvere i problemi e mitigare gli errori rispettando gli standard QoS diventa una questione di destreggiarsi tra array estremamente diversi di hardware, carichi di lavoro variabili, scadenze di aggiornamento e altre cose interessanti di cui nessuno vuole preoccuparsi.
Padroneggia i tuoi domini
Per risolvere molti di questi problemi, abbiamo suddiviso il ciclo di vita del server in Outbrain nei suoi componenti principali e li abbiamo chiamati domini. Ad esempio, un dominio copre i requisiti delle apparecchiature, un altro riguarda la logistica relativa al ciclo di vita dell'inventario e un terzo riguarda le comunicazioni con il personale sul campo. Ce n'è un altro riguardante l'osservabilità dell'hardware, ma non descriveremo tutti i punti. Il nostro obiettivo era studiare e definire i domini in modo che potessero essere astratti utilizzando il codice. Una volta sviluppata un'astrazione funzionante, questa viene trasferita in un processo manuale che viene distribuito, testato e perfezionato. Infine, il dominio è configurato per integrarsi con altri domini tramite API, formando un sistema di ciclo di vita dell'hardware olistico, dinamico e in continua evoluzione che è distribuibile, testabile e osservabile. Come tutti gli altri nostri sistemi produttivi.
L'adozione di questo approccio ci ha permesso di risolvere correttamente molti problemi, creando strumenti e automazione.
Hai bisogno di dominio
Sebbene all’inizio la posta elettronica e i fogli di calcolo fossero un modo praticabile per soddisfare la domanda, non si è rivelata una soluzione di successo, soprattutto quando il numero di server e il volume delle richieste in entrata hanno raggiunto un certo livello. Per organizzare e dare priorità alle richieste in arrivo a fronte di una rapida espansione, abbiamo dovuto utilizzare un sistema di ticketing in grado di offrire:
- Possibilità di personalizzare la visualizzazione dei soli campi rilevanti (semplice)
- API aperte (estensibili)
- Conosciuto dal nostro team (capito)
- Integrazione con i nostri flussi di lavoro esistenti (unificati)
Poiché utilizziamo Jira per gestire i nostri sprint e le attività interne, abbiamo deciso di creare un altro progetto che aiutasse i nostri clienti a inviare ticket e monitorare i loro risultati. L'utilizzo di Jira per le richieste in entrata e per la gestione delle attività interne ci ha permesso di creare un'unica scheda Kanban che ci ha permesso di considerare tutti i processi nel loro insieme. I nostri "clienti" interni hanno visto solo richieste di attrezzature, senza approfondire i dettagli meno significativi di attività aggiuntive (come migliorare gli strumenti, correggere bug).
Tabellone Kanban in Jira
In più, il fatto che le code e le priorità fossero ora visibili a tutti permetteva di capire “dove in coda” si trovava una particolare richiesta e cosa la precedeva. Ciò ha consentito ai proprietari di ridefinire le priorità delle proprie richieste senza dover contattarci. Trascinalo e il gioco è fatto. Ci ha inoltre consentito di monitorare e valutare i nostri SLA in base ai tipi di richiesta in base alle metriche generate in Jira.
Dominio del ciclo di vita delle apparecchiature
Prova a immaginare la complessità della gestione dell'hardware utilizzato in ciascun rack di server. Ciò che è ancora peggio è che molti componenti hardware (RAM, ROM) possono essere spostati dal magazzino alla sala server e viceversa. Inoltre si guastano o vengono ammortizzati, sostituiti e restituiti al fornitore per la sostituzione/riparazione. Tutto ciò dovrà essere comunicato agli addetti del servizio di colocation coinvolti nella manutenzione fisica delle apparecchiature. Per risolvere questi problemi, abbiamo creato uno strumento interno chiamato Floppy. Il suo compito è:
- Gestione delle comunicazioni con il personale sul campo, aggregazione di tutte le informazioni;
- Aggiornamento dei dati “magazzino” dopo ogni intervento di manutenzione delle apparecchiature completato e verificato.
Il magazzino, a sua volta, viene visualizzato utilizzando Grafana, che utilizziamo per tracciare tutte le nostre metriche. Utilizziamo quindi lo stesso strumento per la visualizzazione del magazzino e per altre esigenze di produzione.
Pannello di controllo attrezzature di magazzino a Grafana
Per i dispositivi server in garanzia, utilizziamo un altro strumento chiamato Dispatcher. Lui:
- Raccoglie i log di sistema;
- Genera report nel formato richiesto dal fornitore;
- Crea una richiesta dal fornitore tramite API;
- Riceve e memorizza l'identificatore dell'applicazione per un'ulteriore tracciabilità del suo avanzamento.
Una volta accettato il nostro reclamo (di solito entro l'orario lavorativo), il pezzo di ricambio viene inviato al data center appropriato e accettato dal personale.
Uscita della console Jenkins
Dominio della comunicazione
Per tenere il passo con la rapida crescita della nostra attività, che richiede capacità sempre maggiori, abbiamo dovuto adattare il modo in cui lavoriamo con gli specialisti tecnici nei data center locali. Se all'inizio lo scale-up significava l'acquisto di nuovi server, dopo un progetto di consolidamento (basato sul passaggio a Kubernetes) è diventato qualcosa di completamente diverso. La nostra evoluzione dall'"aggiunta di rack" alla "riconversione dei server".
L'utilizzo di un nuovo approccio richiedeva anche nuovi strumenti che consentissero di interagire più comodamente con il personale del data center. Questi strumenti dovevano:
- Semplicità;
- Autonomia;
- Efficienza;
- Affidabilità.
Abbiamo dovuto escluderci dalla catena e strutturare il lavoro in modo che i tecnici potessero lavorare direttamente con le apparecchiature server. Senza il nostro intervento e senza sollevare regolarmente tutte queste questioni relative al carico di lavoro, agli orari di lavoro, alla disponibilità delle attrezzature, ecc.
Per raggiungere questo obiettivo, abbiamo installato iPad in ogni data center. Dopo la connessione al server, accadrà quanto segue:
- Il dispositivo conferma che questo server richiede effettivamente del lavoro;
- Le applicazioni in esecuzione sul server vengono chiuse (se necessario);
- Una serie di istruzioni di lavoro viene pubblicata su un canale Slack che spiega i passaggi richiesti;
- Al termine del lavoro, il dispositivo verifica la correttezza dello stato finale del server;
- Riavvia le applicazioni se necessario.
Inoltre, abbiamo preparato anche un bot Slack per aiutare il tecnico. Grazie a un'ampia gamma di funzionalità (espandevamo costantemente le funzionalità), il bot ha semplificato il loro lavoro e ha reso la nostra vita molto più semplice. In questo modo abbiamo ottimizzato la maggior parte del processo di riconversione e manutenzione dei server, eliminandoci dal flusso di lavoro.
iPad in uno dei nostri data center
Dominio hardware
Per scalare in modo affidabile la nostra infrastruttura di data center è necessario avere una buona visibilità su ciascun componente, ad esempio:
- Rilevamento di guasti hardware
- Stati del server (attivo, ospitato, zombie, ecc.)
- Consumo di energia
- Versione del firmware
- Analisi per l'intera attività
Le nostre soluzioni ci consentono di prendere decisioni su come, dove e quando acquistare le attrezzature, a volte anche prima che siano effettivamente necessarie. Inoltre, determinando il livello di carico sulle diverse apparecchiature, siamo riusciti a ottenere una migliore allocazione delle risorse. In particolare, il consumo energetico. Ora possiamo prendere decisioni informate sul posizionamento di un server prima che venga installato nel rack e collegato a una fonte di alimentazione, durante tutto il suo ciclo di vita e fino al suo eventuale ritiro.
Cruscotto energetico a Grafana
E poi è apparso il COVID-19...
Il nostro team crea tecnologie che consentono alle società di media e agli editori online di aiutare i visitatori a trovare contenuti, prodotti e servizi pertinenti che potrebbero interessarli. La nostra infrastruttura è progettata per servire il traffico generato quando vengono rilasciate notizie interessanti.
L’intensa copertura mediatica relativa al COVID-19, unita all’aumento del traffico, ha fatto sì che avessimo urgentemente bisogno di imparare come affrontare queste pressioni. Inoltre, tutto ciò ha dovuto essere fatto durante una crisi globale, quando le catene di approvvigionamento erano interrotte e la maggior parte del personale era a casa.
Ma, come abbiamo detto, il nostro modello presuppone già che:
- Le apparecchiature dei nostri data center sono, per la maggior parte, fisicamente inaccessibili per noi;
- Svolgiamo quasi tutto il lavoro fisico da remoto;
- Il lavoro viene svolto in modo asincrono, autonomo e su larga scala;
- Soddisfiamo la domanda di attrezzature utilizzando il metodo "costruito da parti" invece di acquistare nuove attrezzature;
- Disponiamo di un magazzino che ci consente di creare qualcosa di nuovo e non solo di eseguire riparazioni di routine.
Pertanto, le restrizioni globali che hanno impedito a molte aziende di accedere fisicamente ai propri data center hanno avuto un impatto minimo su di noi e per quanto riguarda i pezzi di ricambio e i server, sì, abbiamo cercato di garantire il funzionamento stabile delle apparecchiature. Ma questo è stato fatto con l'obiettivo di prevenire possibili incidenti quando improvvisamente si scopre che qualche componente hardware non è disponibile. Ci siamo assicurati che le nostre riserve fossero riempite senza mirare a soddisfare la domanda attuale.
In sintesi, vorrei dire che il nostro approccio al lavoro nel settore dei data center dimostra che è possibile applicare i principi di una buona progettazione del codice alla gestione fisica di un data center. E forse lo troverai interessante.
originale:
Fonte: habr.com