{"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\/pt\/blog\/administrirovanie\/ot-startapa-do-tysyach-serverov-v-desyatke-czod-kak-my-gnalis-za-rostom-linux-infrastruktury","title":{"rendered":"De \"startup\" a milhares de servidores em dez data centers. Como buscamos o crescimento da infraestrutura Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Se a sua infraestrutura de TI est\u00e1 crescendo rapidamente, mais cedo ou mais tarde voc\u00ea ter\u00e1 que enfrentar a decis\u00e3o de aumentar linearmente os recursos humanos para seu suporte ou come\u00e7ar a automa\u00e7\u00e3o. At\u00e9 certo ponto, vivemos na primeira paradigma, e depois come\u00e7ou um longo caminho em dire\u00e7\u00e3o ao Infrastructure-as-Code.<\/p>\n

\"De
\n<\/a><\/noindex>
\n\u00c9 claro que a NSPK n\u00e3o \u00e9 uma startup, mas essa atmosfera reinava na empresa nos primeiros anos de exist\u00eancia, e foram anos muito interessantes. Meu nome \u00e9 Dmitry Koryakov<\/a><\/noindex>, h\u00e1 mais de 10 anos eu suporte a infraestrutura Linux com altos requisitos de disponibilidade. Entrei para a equipe da NSPK em janeiro de 2016 e, infelizmente, n\u00e3o vivenciei o in\u00edcio da exist\u00eancia da empresa, mas cheguei em um momento de grandes mudan\u00e7as.<\/p>\n

De maneira geral, pode-se dizer que nossa equipe oferece 2 produtos para a empresa. O primeiro \u2013 \u00e9 a infraestrutura. O e-mail deve funcionar, o DNS deve operar, e os controladores de dom\u00ednio \u2013 devem permitir acesso aos servidores, que n\u00e3o podem falhar. O cen\u00e1rio de TI da empresa \u00e9 imenso! S\u00e3o sistemas cr\u00edticos para os neg\u00f3cios e miss\u00f5es, com requisitos de disponibilidade de alguns \u2013 99,999. O segundo produto \u2013 s\u00e3o os pr\u00f3prios servidores, f\u00edsicos e virtuais. \u00c9 necess\u00e1rio monitorar os existentes e fornecer novos regularmente aos clientes de v\u00e1rias divis\u00f5es. Neste artigo, quero enfatizar como n\u00f3s desenvolvemos a infraestrutura que \u00e9 respons\u00e1vel pelo ciclo de vida servidores<\/a>.<\/p>\n

In\u00edcio da jornada<\/b><\/p>\n

No in\u00edcio, nosso stack de tecnologias parecia assim:
\nOS CentOS 7
\nControladores de dom\u00ednio FreeIPA
\nAutoma\u00e7\u00e3o \u2013 Ansible(+Tower), Cobbler<\/i><\/p>\n

Tudo isso estava distribu\u00eddo em 3 dom\u00ednios, espalhados por v\u00e1rios data centers. Em um data center \u2013 sistemas de escrit\u00f3rio e ambientes de teste, nos outros, produ\u00e7\u00e3o.<\/p>\n

A cria\u00e7\u00e3o de servidores em algum momento parecia assim:<\/p>\n

\"De<\/p>\n

No template VM CentOS minimal e o m\u00ednimo necess\u00e1rio, como um correto \/etc\/resolv.conf, o restante \u00e9 obtido atrav\u00e9s do Ansible.<\/p>\n

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

Se o servidor \u00e9 f\u00edsico, em vez de copiar a m\u00e1quina virtual, o sistema operacional \u00e9 instalado usando o Cobbler \u2013 os endere\u00e7os MAC do servidor de destino s\u00e3o adicionados \u00e0 configura\u00e7\u00e3o do Cobbler, o servidor recebe um endere\u00e7o IP via DHCP, e ent\u00e3o o sistema operacional \u00e9 instalado.<\/p>\n

No in\u00edcio, tent\u00e1vamos at\u00e9 fazer algum gerenciamento de configura\u00e7\u00e3o no Cobbler. Mas, com o tempo, isso come\u00e7ou a trazer problemas de portabilidade das configura\u00e7\u00f5es tanto para outros data centers quanto para o c\u00f3digo do Ansible para preparar a VM.<\/p>\n

Durante um tempo, muitos de n\u00f3s viam o Ansible como uma extens\u00e3o conveniente do Bash e n\u00e3o economiz\u00e1vamos nas constru\u00e7\u00f5es usando shell, sed. Em resumo, Bashsible. Isso acabava resultando em um cen\u00e1rio onde, se um playbook n\u00e3o funcionasse por algum motivo no servidor, era mais f\u00e1cil excluir o servidor, corrigir o playbook e reaplic\u00e1-lo. N\u00e3o havia na pr\u00e1tica versionamento de scripts nem portabilidade de configura\u00e7\u00f5es.<\/p>\n

Por exemplo, decidimos alterar alguma configura\u00e7\u00e3o em todos os servidores:<\/p>\n

    \n
  1. Alterando a configura\u00e7\u00e3o em servidores existentes no segmento l\u00f3gico\/datacenter. \u00c0s vezes isso n\u00e3o \u00e9 feito em um s\u00f3 dia \u2013 os requisitos de disponibilidade e a lei dos grandes n\u00fameros n\u00e3o permitem aplicar todas as mudan\u00e7as de uma vez. Algumas altera\u00e7\u00f5es s\u00e3o potencialmente destrutivas e requerem a reinicializa\u00e7\u00e3o de algo \u2013 desde servi\u00e7os at\u00e9 o pr\u00f3prio sistema operacional.<\/li>\n
  2. Corrigindo no Ansible<\/li>\n
  3. Corrigindo no Cobbler<\/li>\n
  4. Repetimos N vezes para cada segmento l\u00f3gico\/datacenter<\/li>\n<\/ol>\n

    Para que todas as mudan\u00e7as ocorressem sem problemas, era necess\u00e1rio considerar uma variedade de fatores, e as mudan\u00e7as ocorrem constantemente.<\/p>\n