{"id":87282,"date":"2020-07-06T13:44:51","date_gmt":"2020-07-06T11:44:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ot-startapa-do-tysyach-serverov-v-desyatke-czod-kak-my-gnalis-za-rostom-linux-infrastruktury"},"modified":"2021-02-01T11:41:48","modified_gmt":"2021-02-01T09:41:48","slug":"ot-startapa-do-tysyach-serverov-v-desyatke-czod-kak-my-gnalis-za-rostom-linux-infrastruktury","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ot-startapa-do-tysyach-serverov-v-desyatke-czod-kak-my-gnalis-za-rostom-linux-infrastruktury","title":{"rendered":"Da \"startup\" a migliaia di server in dieci datacenter. Come abbiamo inseguito la crescita dell'infrastruttura Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Se la vostra infrastruttura IT cresce troppo rapidamente, prima o poi vi troverete di fronte a una scelta: aumentare linearmente le risorse umane per supportarla o iniziare l'automazione. Fino a un certo punto, abbiamo vissuto nella prima scelta, poi \u00e8 iniziato un lungo percorso verso l'Infrastructure-as-Code.<\/p>\n

\"Da
\n<\/a><\/noindex>
\nNaturalmente, NSPK non \u00e8 un startup, ma questa atmosfera permeava l'azienda nei primi anni di vita, e sono stati anni molto interessanti. Mi chiamo Dmitry Koryakov<\/a><\/noindex>, da oltre 10 anni gestisco l'infrastruttura Linux con elevate esigenze di disponibilit\u00e0. Sono entrato nel team di NSPK a gennaio 2016 e, sfortunatamente, non ho vissuto l'inizio dell'azienda, ma sono arrivato in un periodo di grandi cambiamenti.<\/p>\n

In generale, si pu\u00f2 dire che il nostro team fornisce all'azienda 2 prodotti. Il primo \u00e8 l'infrastruttura. La posta deve funzionare, il DNS deve lavorare, e i controller di dominio devono permettervi di accedere ai server, che non devono mai bloccarsi. Il paesaggio IT dell'azienda \u00e8 enorme! Si tratta di sistemi critici per il business e per la missione, con requisiti di disponibilit\u00e0 per alcuni del 99,999%. Il secondo prodotto sono i server stessi, fisici e virtuali. \u00c8 necessario monitorare i server esistenti e fornire regolarmente nuovi server ai clienti provenienti da molteplici divisioni. In questo articolo voglio sottolineare come abbiamo sviluppato l'infrastruttura che gestisce il ciclo di vita server<\/a>.<\/p>\n

Inizio del percorso<\/b><\/p>\n

All'inizio del nostro percorso, il nostro stack tecnologico era composto da:
\nOS CentOS 7
\nController di dominio FreeIPA
\nAutomazione \u2014 Ansible(+Tower), Cobbler<\/i><\/p>\n

Tutto ci\u00f2 era distribuito su 3 domini, sparsi su diversi data center. In un data center \u2013 sistemi d'ufficio e ambienti di test, negli altri PROD.<\/p>\n

La creazione di server in un certo momento si presentava cos\u00ec:<\/p>\n

\"Da<\/p>\n

Nel template VM CentOS minimal e il minimo necessario come un corretto \/etc\/resolv.conf, il resto arriva tramite Ansible.<\/p>\n

CMDB \u2013 Excel.<\/p>\n

Se il server \u00e8 fisico, invece di copiare una macchina virtuale, veniva installato il sistema operativo tramite Cobbler: negli config di Cobbler si aggiungono gli indirizzi MAC del server target, il server ottiene un indirizzo IP tramite DHCP, e successivamente viene installato il sistema operativo.<\/p>\n

Inizialmente abbiamo anche provato a realizzare una sorta di gestione della configurazione in Cobbler. Ma col tempo questo ha iniziato a portare problemi di portabilit\u00e0 delle configurazioni sia verso altri data center che nel codice Ansible per la preparazione delle VM.<\/p>\n

Ansible era visto da molti di noi come un comodo ampliamento di Bash, e non ci si \u00e8 trattenuti nell'utilizzare costrutti con shell, sed. In generale, Bashsible. Questo alla fine portava al fatto che, se un playbook per qualche motivo non funzionava sul server, era pi\u00f9 semplice eliminare il server, correggere il playbook e riprovare. In sostanza, non c'era alcun versioning degli script, n\u00e9 portabilit\u00e0 delle configurazioni.<\/p>\n

Ad esempio, abbiamo voluto modificare qualche configurazione su tutti i server:<\/p>\n

    \n
  1. Modifichiamo la configurazione sui server esistenti nel segmento logico\/centro dati. A volte non in un solo giorno: i requisiti di disponibilit\u00e0 e la legge dei grandi numeri non permettono di applicare tutte le modifiche contemporaneamente. Alcune modifiche sono potenzialmente distruttive e richiedono il riavvio di qualcosa, dai servizi fino al sistema operativo stesso.<\/li>\n
  2. Correggiamo in Ansible<\/li>\n
  3. Correggiamo in Cobbler<\/li>\n
  4. Ripetiamo N volte per ogni segmento logico\/centro dati<\/li>\n<\/ol>\n

    Per garantire che tutte le modifiche avvengano senza intoppi, era necessario tenere conto di numerosi fattori, e le modifiche avvengono costantemente.<\/p>\n