{"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\/da\/blog\/administrirovanie\/ot-startapa-do-tysyach-serverov-v-desyatke-czod-kak-my-gnalis-za-rostom-linux-infrastruktury","title":{"rendered":"Fra \u2018startup\u2019 til tusind servere i ti datacentre. Hvordan vi jagede v\u00e6ksten af Linux-infrastrukturen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hvis din IT-infrastruktur vokser for hurtigt, vil du f\u00f8r eller senere st\u00e5 over for valget - enten at \u00f8ge bemandingen line\u00e6rt for at st\u00f8tte den eller begynde at automatisere. Indtil et vist punkt levede vi i den f\u00f8rste paradigme, hvorefter den lange rejse mod Infrastructure-as-Code begyndte.<\/p>\n

\"Fra
\n<\/a><\/noindex>
\nSelvf\u00f8lgelig er NSPK ikke en startup, men s\u00e5dan en atmosf\u00e6re herskede i virksomheden de f\u00f8rste \u00e5r af dens eksistens, og det var meget sp\u00e6ndende \u00e5r. Mit navn er Korjakov Dmitrij<\/a><\/noindex>, jeg har i over 10 \u00e5r underst\u00f8ttet Linux-infrastruktur med h\u00f8je tilg\u00e6ngelighedskrav. Jeg sluttede mig til NSPK-teamet i januar 2016 og, desv\u00e6rre, fik jeg ikke opleve virksomhedens tidlige dage, men kom ind i en fase med store \u00e6ndringer.<\/p>\n

Generelt kan man sige, at vores team leverer to produkter til virksomheden. Det f\u00f8rste er infrastrukturen. E-mail skal fungere, DNS skal fungere, og dom\u00e6necontrollere skal give dig adgang til serverne, som ikke m\u00e5 g\u00e5 ned. IT-landskabet i virksomheden er enormt! Det drejer sig om business & mission critical systemer, nogle med tilg\u00e6ngelighedskrav p\u00e5 99,999. Det andet produkt er selve serverne, b\u00e5de fysiske og virtuelle. De eksisterende skal overv\u00e5ges, og nye skal regelm\u00e6ssigt leveres til kunderne fra mange afdelinger. I denne artikel vil jeg fokusere p\u00e5, hvordan vi udviklede infrastrukturen, der er ansvarlig for livscyklussen servere<\/a>.<\/p>\n

Starten p\u00e5 rejsen<\/b><\/p>\n

I starten s\u00e5 vores teknologi-stack s\u00e5dan ud:
\nOS CentOS 7
\nDom\u00e6necontrollere FreeIPA
\nAutomatisering \u2014 Ansible(+Tower), Cobbler<\/i><\/p>\n

Alt dette var placeret i 3 dom\u00e6ner, spredt over flere datacentre. I \u00e9t datacenter - kontorsystemer og testmilj\u00f8er, i de andre PROD.<\/p>\n

Oprettelse af servere s\u00e5 p\u00e5 et tidspunkt s\u00e5dan ud:<\/p>\n

\"Fra<\/p>\n

I VM-skabelonen CentOS minimal og det n\u00f8dvendige minimum som korrekt \/etc\/resolv.conf, resten kommer gennem Ansible.<\/p>\n

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

Hvis serveren er fysisk, blev OS installeret ved hj\u00e6lp af Cobbler i stedet for at kopiere den virtuelle maskine til den - MAC-adresserne p\u00e5 den m\u00e5lserver tilf\u00f8jes til Cobbler-konfigurationen, serveren f\u00e5r en IP-adresse via DHCP, og derefter installeres OS.<\/p>\n

I starten fors\u00f8gte vi endda at lave en form for konfigurationsstyring i Cobbler. Men med tiden begyndte det at medf\u00f8re problemer med portabiliteten af konfigurationerne b\u00e5de til andre datacentre og til Ansible-koden til forberedelse af VM.<\/p>\n

Ansible blev dengang opfattet af mange af os som en praktisk udvidelse af Bash, og vi var ikke tilbageholdende med at bruge konstruktioner med shell og sed. Generelt som Bashsible. Dette f\u00f8rte til, at hvis en playbook af en eller anden grund ikke fungerede p\u00e5 serveren, var det lettere at slette serveren, rette playbooken og k\u00f8re den igennem igen. Der var i praksis ingen versionering af scripts, og konfigurationens portabilitet var ogs\u00e5 frav\u00e6rende.<\/p>\n

For eksempel \u00f8nskede vi at \u00e6ndre en konfiguration p\u00e5 alle servere:<\/p>\n

    \n
  1. \u00c6ndrer konfigurationen p\u00e5 eksisterende servere i det logiske segment\/datacenter. Nogle gange ikke p\u00e5 en dag \u2013 kravene til tilg\u00e6ngelighed og loven om store tal tillader ikke at anvende alle \u00e6ndringer p\u00e5 \u00e9n gang. Nogle \u00e6ndringer er potentielt destruktive og kr\u00e6ver genstart af noget \u2013 fra tjenester til selve operativsystemet.<\/li>\n
  2. Retter i Ansible<\/li>\n
  3. Retter i Cobbler<\/li>\n
  4. Gentager N gange for hver logisk sektion\/datacenter<\/li>\n<\/ol>\n

    For at sikre, at alle \u00e6ndringer forl\u00f8ber glat, var det n\u00f8dvendigt at tage h\u00f8jde for adskillige faktorer, og \u00e6ndringerne forekommer konstant.<\/p>\n