{"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":"Dallo \u2018startup\u2019 a migliaia di server in una decina di data center. Come abbiamo perseguito la crescita dell'infrastruttura Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

\"Dallo
\n<\/a><\/noindex>
\nNaturalmente, NSPK non \u00e8 una startup, ma un'atmosfera simile regnava in azienda nei primi anni della sua esistenza, ed erano anni molto interessanti. Mi chiamo Dmitrij Korneyakov<\/a><\/noindex>, da oltre 10 anni supporto un'infrastruttura Linux con elevate esigenze di disponibilit\u00e0. Sono entrato a far parte del team di NSPK a gennaio 2016 e, purtroppo, non ho vissuto l'inizio dell'esistenza dell'azienda, ma ho fatto il mio ingresso in un periodo di grandi cambiamenti.<\/p>\n

In generale, si pu\u00f2 dire che il nostro team fornisce due prodotti per l'azienda. Il primo \u00e8 l'infrastruttura. La posta deve funzionare, il DNS deve essere attivo e i controller di dominio devono permettervi di accedere ai server, i quali non devono mai andare offline. Il panorama IT dell'azienda \u00e8 vasto! Si tratta di sistemi critici per il business e la missione, con requisiti di disponibilit\u00e0 per alcuni pari al 99,999. Il secondo prodotto sono i server stessi, fisici e virtuali. \u00c8 necessario monitorare quelli esistenti e fornire regolarmente nuovi server ai clienti di diversi dipartimenti. In questo articolo voglio mettere in evidenza come abbiamo sviluppato l'infrastruttura che gestisce il ciclo di vita. server<\/a>.<\/p>\n

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

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

Tutto ci\u00f2 era suddiviso in 3 domini, distribuiti su vari data center. In un data center si trovavano i sistemi per ufficio e i laboratori di test, negli altri invece i sistemi di produzione.<\/p>\n

La creazione dei server a un certo punto appariva cos\u00ec:<\/p>\n

\"Dallo<\/p>\n

Nel template VM CentOS minimal e il minimo indispensabile 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, il sistema operativo veniva installato utilizzando Cobbler: gli indirizzi MAC del server di destinazione vengono aggiunti alla configurazione di Cobbler, il server ottiene un indirizzo IP tramite DHCP e poi viene installato il sistema operativo.<\/p>\n

All'inizio abbiamo anche provato a gestire la configurazione tramite Cobbler. Ma col tempo, ci\u00f2 ha iniziato a causare problemi con la portabilit\u00e0 delle configurazioni, sia per i diversi data center che per il codice Ansible per la preparazione delle VM.<\/p>\n

All'epoca, molti di noi consideravano Ansible come un'estensione utile di Bash e non esitavano ad usare costrutti con shell e sed. Insomma, era una specie di Bashsible. Questo 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 eseguirlo nuovamente. Di fatto non c'era versione dei script e neanche 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\/CED. A volte non in un giorno: le esigenze di disponibilit\u00e0 e la legge dei grandi numeri non consentono di applicare tutte le modifiche contemporaneamente. Alcuni cambiamenti sono potenzialmente distruttivi e richiedono il riavvio di qualcosa, dai servizi al sistema operativo stesso.<\/li>\n
  2. Correzioni in Ansible<\/li>\n
  3. Correzioni in Cobbler<\/li>\n
  4. Ripetiamo N volte per ogni segmento logico\/CED<\/li>\n<\/ol>\n

    Per garantire che tutte le modifiche avvengano senza problemi, \u00e8 necessario considerare numerosi fattori, e i cambiamenti sono costanti.<\/p>\n