{"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\/cs\/blog\/administrirovanie\/ot-startapa-do-tysyach-serverov-v-desyatke-czod-kak-my-gnalis-za-rostom-linux-infrastruktury","title":{"rendered":"Od \"startup\" po tis\u00edce server\u016f v des\u00edtk\u00e1ch datov\u00fdch center. Jak jsme usilovali o r\u016fst Linux infrastruktury","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pokud va\u0161e IT infrastruktura roste p\u0159\u00edli\u0161 rychle, d\u0159\u00edve \u010di pozd\u011bji se setk\u00e1te s volbou \u2013 bu\u010f line\u00e1rn\u011b zvy\u0161ovat lidsk\u00e9 zdroje na jej\u00ed podporu, nebo za\u010d\u00edt automatizovat. Do ur\u010dit\u00e9ho okam\u017eiku jsme \u017eili v prvn\u00ed paradigmy, a pak za\u010dala dlouh\u00e1 cesta k Infrastructure-as-Code.<\/p>\n

\"Od
\n<\/a><\/noindex>
\nSamoz\u0159ejm\u011b, NSPK nen\u00ed startup, ale takov\u00e1 atmosf\u00e9ra panovala ve spole\u010dnosti v prvn\u00edch letech jej\u00ed existence, a to byly velmi zaj\u00edmav\u00e9 roky. Jmenuji se Dmitrij Kornev<\/a><\/noindex>, v\u00edce ne\u017e 10 let udr\u017euji infrastrukturu Linux s vysok\u00fdmi po\u017eadavky na dostupnost. K t\u00fdmu NSPK jsem se p\u0159ipojil v lednu 2016 a bohu\u017eel jsem neza\u017eil samotn\u00fd za\u010d\u00e1tek existence spole\u010dnosti, ale p\u0159i\u0161el jsem ve f\u00e1zi velk\u00fdch zm\u011bn.<\/p>\n

Celkov\u011b lze \u0159\u00edci, \u017ee n\u00e1\u0161 t\u00fdm dod\u00e1v\u00e1 spole\u010dnosti dva produkty. Prvn\u00ed \u2013 to je infrastruktura. Po\u0161ta mus\u00ed fungovat, DNS mus\u00ed pracovat, a \u0159adi\u010de dom\u00e9ny \u2013 mus\u00ed v\u00e1s pustit na servery, kter\u00e9 nesm\u00ed padat. IT krajina spole\u010dnosti je obrovsk\u00e1! Jsou to business & mission critical syst\u00e9my, po\u017eadavky na dostupnost n\u011bkter\u00fdch z nich \u2013 99,999. Druh\u00fd produkt \u2013 to jsou samotn\u00e9 servery, fyzick\u00e9 i virtu\u00e1ln\u00ed. O existuj\u00edc\u00ed je t\u0159eba se starat a nov\u00e9 pravideln\u011b dod\u00e1vat z\u00e1kazn\u00edk\u016fm z mnoha odd\u011blen\u00ed. V tomto \u010dl\u00e1nku chci zd\u016fraznit, jak jsme vyv\u00edjeli infrastrukturu, kter\u00e1 odpov\u00edd\u00e1 za \u017eivotn\u00ed cyklus servery<\/a>.<\/p>\n

Za\u010d\u00e1tek cesty<\/b><\/p>\n

Na za\u010d\u00e1tku na\u0161\u00ed cesty n\u00e1\u0161 technologick\u00fd stack vypadal takto:
\nOS CentOS 7
\n\u0158adi\u010de dom\u00e9ny FreeIPA
\nAutomatizace \u2013 Ansible(+Tower), Cobbler<\/i><\/p>\n

V\u0161echno to bylo um\u00edst\u011bno ve 3 dom\u00e9n\u00e1ch, rozprost\u0159en\u00fdch na n\u011bkolika datov\u00fdch centrech. V jednom datov\u00e9m centru byly kancel\u00e1\u0159sk\u00e9 syst\u00e9my a testovac\u00ed plochy, v ostatn\u00edch PROD.<\/p>\n

Vytv\u00e1\u0159en\u00ed server\u016f v ur\u010dit\u00e9m okam\u017eiku vypadalo takto:<\/p>\n

\"Od<\/p>\n

Ve \u0161ablon\u011b VM CentOS minimal a pot\u0159ebn\u00e9 minimum jako spr\u00e1vn\u00e9 \/etc\/resolv.conf, zbytek p\u0159ich\u00e1z\u00ed p\u0159es Ansible.<\/p>\n

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

Pokud je server fyzick\u00fd, m\u00edsto kop\u00edrov\u00e1n\u00ed virtu\u00e1ln\u00edho stroje se na n\u011bj instaloval OS s pomoc\u00ed Cobbler \u2013 do konfigurace Cobbler se p\u0159id\u00e1vaj\u00ed MAC adresy c\u00edlov\u00e9ho serveru, server z\u00edsk\u00e1v\u00e1 IP adresu p\u0159es DHCP, a pak se nahr\u00e1v\u00e1 OS.<\/p>\n

Zpo\u010d\u00e1tku jsme se dokonce pokou\u0161eli o n\u011bjakou spr\u00e1vu konfigurac\u00ed v Cobbler. Ale s \u010dasem to za\u010dalo p\u0159in\u00e1\u0161et probl\u00e9my s p\u0159enositelnost\u00ed konfigurac\u00ed jak do jin\u00fdch datov\u00fdch center, tak do Ansible k\u00f3du pro p\u0159\u00edpravu VM.<\/p>\n

Mnoz\u00ed z n\u00e1s v t\u00e9 dob\u011b vn\u00edmali Ansible jako pohodln\u00e9 roz\u0161\u00ed\u0159en\u00ed Bash a ne\u0161et\u0159ili konstrukcemi vyu\u017e\u00edvaj\u00edc\u00edmi shell nebo sed. Ve zkratce, Bashsible. To nakonec vedlo k tomu, \u017ee pokud playbook z n\u011bjak\u00e9ho d\u016fvodu nefungoval na serveru, bylo snaz\u0161\u00ed server smazat, opravit playbook a znovu ho spustit. V podstat\u011b neexistovalo \u017e\u00e1dn\u00e9 verzov\u00e1n\u00ed skript\u016f ani p\u0159enositelnost konfigurac\u00ed.<\/p>\n

Nap\u0159\u00edklad jsme cht\u011bli zm\u011bnit n\u011bjak\u00fd konfigura\u010dn\u00ed soubor na v\u0161ech serverech:<\/p>\n

    \n
  1. M\u011bn\u00edme konfiguraci na existuj\u00edc\u00edch serverech v logick\u00e9m segmentu\/datov\u00e9m centru. N\u011bkdy to netrv\u00e1 jen jeden den \u2014 po\u017eadavky na dostupnost a z\u00e1kon velk\u00fdch \u010d\u00edsel neumo\u017e\u0148uj\u00ed prov\u00e1d\u011bt v\u0161echny zm\u011bny najednou. A n\u011bkter\u00e9 zm\u011bny jsou potenci\u00e1ln\u011b destruktivn\u00ed a vy\u017eaduj\u00ed restart n\u011b\u010deho \u2014 od slu\u017eeb a\u017e po samotn\u00fd opera\u010dn\u00ed syst\u00e9m.<\/li>\n
  2. Opravy v Ansible<\/li>\n
  3. Opravy v Cobbler<\/li>\n
  4. Opakujeme Nkr\u00e1t pro ka\u017ed\u00fd logick\u00fd segment\/datov\u00e9 centrum<\/li>\n<\/ol>\n

    Aby v\u0161echny zm\u011bny prob\u011bhly hladce, bylo nutn\u00e9 zohlednit \u0159adu faktor\u016f a zm\u011bny se neust\u00e1le objevuj\u00ed.<\/p>\n