Întreţinerea la zi a sistemelor Linux (I)

În acest articol, care e structurat în mai multe părți, se va analiza problema menținerii sistemului de pe serverele Linux actualizat. Deseori, când se începe administrarea serverelor unei afaceri incipiente, echipa de administratori de sisteme găsește o instalare de servere în centrul de calcul axată în jurul unor servere instalate cu programele necesare și configurate haotic de prima echipă de programatori doar cu scopul "să meargă". Acești programatori fac atât muncă de dezvoltare cât și administrare de sisteme, care este cunoscută în termenii IT internaționali ca DevOps (Development and Operations).

Această situație reprezintă un obstacol, creator de ore suplimentare, atunci când dorim să păstrăm serverele de producție, sau chiar și pe cele de dezvoltare, actualizate. Deseori, administratorii de sisteme găsesc sisteme care sunt pornite de timp îndelungat și care nu au fost actualizate cu anii. Din punctul de vedere al afacerii, atât timp cât acele sisteme funcționează și își fac datoria, nu contează dacă sunt actualizate sau nu. Doar atunci când ceva rău se întâmplă, spre exemplu când baza de date cu utilizatorii și parolele sau alte date valoroase se scurg în mâinile persoanelor neautorizate sau chiar către tot Internetul din cauza unei breșe de securitate, sau când programatorii observă că programele lor au nevoie de o versiune actualizată de programe care e incompatibilă cu versiunea sistemelor de operare folosite pe producție, echipa de conducere grăbește echipa de administrare de sisteme să facă actualizări urgente. Această grabă cauzează în continuare instalarea pe sistemele de producție a unor sisteme testate insuficient.

Pentru a simplifica și formaliza procesul de actualizare fără a fi nevoie de achiziția de noi echipamente, noi am atacat problema în doi pași: întâi, am virtualizat stratul aplicației folosind Containere Linux (LxC). Această formă de virtualizare ne-a permis să creăm "mașini virtuale", fără a pierde din performanța sistemelor sau fără a le supraîncărca cu un strat de simulare a părții fizice, cum se face în cazul VMWare sau KVM de la RedHat sau în cazul Oracle VirtualBox sau XEN; al doilea pas a fost să "virtualizăm" nodurile fizice (calculatoarele fizice) folosind ca sistem de fișiere rădăcină un fișier imagine al unei partiții.

Câștigul în a avea "sistemul de fișiere rădăcină într-un fișier imagine" e că acum putem înlocui sistemul de fișiere rădăcină cu unul nou doar prin repornirea sistemului; revenirea la sistemul anterior se face de asemenea ușor, doar cu ajutorul unei noi reporniri a sistemului. Un alt câștig al instalării unui sistem de fișiere rădăcină într-un fișier imagine este că sistemul de operare instalat în interiorul fișierului poate fi actualizat și testat eficient pe un sistem de dezvoltare decuplat de producție, pentru ca apoi să poată fi publicat pe toate serverele deodată, automat. Când oricare dintre acele servere trebuie actualizat, este suficientă o repornire a sistemului. Această soluție poate fi întâlnită aproape pe toate sistemele înglobate (embedded systems), unde producătorii publică "fișiere imagine" ce pot fi încărcate în router-e, plăci de administrare decuplată (DRAC, iLO, AMT), etc. .

În cazul nostru, am utilizat o distribuție de Linux bazată pe surse - Gentoo Linux. Vă puteți întreba "De ce ar vrea cineva să compileze totul din surse când este extrem de ușor să instalezi pachete binare?". Când instalează un server, administratorul de sisteme se trezește compilând programe din mai multe surse din varii motive: pachete disponibile prea vechi, nevoia de anumite opțiuni ce pot fi activate sau dezactivate doar la compilare, petice ce trebuie aplicate pentru a rezolva greșeli în program, etc. . Dacă adăugăm la această muncă și munca de actualizare periodică, administratorul se găsește în situația de "a-și câștiga banii cu sudoarea frunții". Se mai poate întâmpla ca nu doar un anumit program să necesite compilarea din surse, ci și programele de care depinde. Pe o distribuție binară, întâmpinăm multe probleme la compilarea din surse, una din ele fiind cunoscuta problemă a "iadului dependențelor", alta fiind înlocuirea componentelor de care depinde sistemul (python, perl) cu versiuni nesuportate. Concluzia e că cel mai bine e să construim tot sistemul din surse folosind metode de automatizare cum este "portage", managerul de pachete de la Gentoo (care seamănă cu sistemul "ports" din FreeBSD).

CONFIGURAȚIA SISTEMULUI

În această primă parte a articolului, vom analiza sistemul gazdă, neavând în vizor container-ele virtualizate sau calculatoarele simulate.

Când am proiectat imaginea sistemului de fișiere rădăcină a sistemului gazdă, cunoscută și sub numele de fișierul imagine rădăcină al "nodului fizic", am observat că ea trebuie să satisfacă câteva cerințe:

• trebuie doar să furnizeze un mediu unde putem rula LxC, KVM și, la un moment dat, OpenStack - care momentan nu e suportat pe alte sisteme decât Ubuntu și RedHat- precum și Docker. Am ales să folosim KVM pentru a rula câteva instanțe de Windows Server;
• schema de partiționare trebuie să conțină doar două partiții: o partiție de tip EFI pentru a conține încărcătorul de sistem de operare - Grub v2, care e capabil să acceseze direct imagini de partiții, după ce-și creează un dispozitiv autoreferențiat (loop device); a doua partiție care va conține cel puțin un fișier imagine de unde va porni sistemul;
• partiția EFI va fi montată în directorul /boot/loader;
• sistemul de stocare gazdă va folosi GPT ca metodă de partiționare, nu MBR, pentru a permite folosirea unui dispozitiv de stocare gazdă (dispozitiv RAID) mai mare de 2 TB;
• pe partiția gazdă (cea care conține fișierul imagine rădăcină) orice alte date vor fi stocate într-un director "data";
• partiția gazdă va fi montată în directorul /hostpart.
• partițiile vor fi etichetate și montate folosind eticheta: partiția EFI va fi etichetată cu "EFI-BOOT", iar partiția gazdă și cu date va fi etichetată "hostpart"; /data0 va fi o legătură simbolică spre /hostpart/data.
• un sistem de stocare distribuit va rula pe toate nodurile fizice pentru a furniza o soluție de stocare rezistentă la intemperii și distribuită; nu vom folosi soluțiile de stocare oferite de OpenStack (deoarece nu este suportat pe Gentoo la data scrierii acestui articol), ci vom folosi XtreemFS; fiecare nod va juca rolul tuturor celor trei componente ale lui XtreemFS - server director (DIR), server de metadate și catalog al duplicării (MRC) și dispozitiv de stocare obiecte (OSD);
• sistemul de stocare distribuită va putea fi accesat în directorul /warehouse pe toate sistemele fizice și pe toate sistemele virtuale interesate;
• fișierul imagine rădăcină va fi numit "hn-root.img";
• fișierul imagine rădăcină actualizat va fi numit "hn-root-new.img";
• fișierul imagine rădăcină vechi va fi numit "hn-root-old.img";
• dacă pe partiția gazdă există un fișier numit "system-revert", sistemul va redenumi fișierul hn-root.img la hn-root-broken.img și hn-root-old.img la hn-root.img și va porni imaginea rădăcină veche;
• toată procesarea de imagini de fișiere se întâmplă în timpul fazei de initrd din procesul de pornire;
• în momentul în care imaginea partiției rădăcină este rulată pe un server, trebuie aplicate câteva configurări particularizate pentru acel server: numele sistemului, adresa de rețea, chei ssh, identitate puppet, etc.; pentru a nu introduce aceste modificări manual pentru fiecare server nou sau la fiecare actualizare de imagine a partiției rădăcină. Am creat artizanal un script ce introduce aceste modificări bazându-se pe date stocate într-un "registru de stare" care este un simplu director cu câteva "fișiere de stare" stocat pe sistemul de stocare distribuit.

Mai jos este diagrama partițiilor sistemului gazdă și a fișierului imagine rădăcină:

Diagrama fazei initrd a procesului de inițializare

Genkernel este un script dezvoltat în cadrul proiectului Gentoo, care ajută utilizatorii să-și compileze nucleele (kernels); Acesta ar putea să funcționeze și în alte distribuții, nu doar în Gentoo. Dacă doriți o distribuție binară care asigură compatibilitatea cu Gentoo și permite genkernel să ruleze nativ, puteți încerca Sabayon Linux sau Calculate Linux, două distribuții bazate de asemenea pe Gentoo. Pentru a putea inițializa sistemul direct din imaginea de partiție rădăcină, am modificat fișierul din genkernel default/linuxrc și am adăugat logica descrisă în diagrama de mai sus. Puteți clona genkernel-ul modificat de pe github, la adresa https://github.com/psihozefir/genkernel.git.

De asemenea, scriptul de inițializare care trebuie să curețe fișierul imagine hn-root.img de fișierele și configurările nedorite, va fi disponibil pe github în curând. Între timp, puteți curăța fișierul manual. Scopul acestui script e de a facilita înlocuirea sistemelor imagine cu un fișier imagine dintr-o singură sursă pe toate serverele fără a cauza confuzie în rețeaua și aplicațiile de administrare (precum Nagios sau Icinga, sau panourile de administrare ale sistemelor) din centrul de calcul.

Pentru a instala un sistem într-o imagine de partiție rădăcină, putem urma următorii pași .Această procedură va șterge complet dispozitivul de stocare al sistemului, deci faceți copii de rezervă înainte de a vă apuca de treabă:

1. Folosind parted, creați o nouă etichetă GPT dacă nu ați partiționat deja utilizând GPT serverul; acest pas va distruge toate datele existente pe dispozitivul de stocare;
2. Creați o partiție minusculă pentru a găzdui încărcătorul de sistem de operare Grub2 (128 MB), formatați-o cu FAT32 sau FAT16, dacă utilitarul mkfs se plânge de dimensiunea tabelei de alocare a fișierelor. Apoi etichetați-o "EFI-BOOT" (a se observa capitalizarea);
3. Creați o a doua partiție care să umple restul de spațiu de stocare și formatați-o cu orice sistem de fișiere Linux (se recomandă BTRFS);
4. Pe un alt sistem (care poate fi o stație de lucru), creați o partiție de 15 GB. Aceasta poate fi mai mare sau mai mică, depinde de necesitățile dumneavoastră, dar cu cât e mai mare cu atât va dura mai mult publicarea pe toate serverele, iar cu cât e mai mică, cu atât se va umple mai repede. Apoi instalați o distribuție de Linux la alegere; de îndată ce instalarea e terminată, creați o imagine a acelei partiții folosind utilitarul dd; a se observa că directorul /boot se află în interiorul acestei partiții, astfel încât nucleul și initramfs vor fi accesate de grub după ce s-a creat un "dispozitiv grub2 autoreferențiat" (grub2 loop device), care e diferit de dispozitivul autoreferențiat /dev/loop0 al nucleului;
5. Recompilați nucleul utilizând genkernel; dacă doriți doar să generați un initramfs compatibil, puteți să folosiți comanda genkernel initramfs în locul comenzii de compilare completă genkernel --menuconfig all;
6. În directorul /boot, fișierul "kernel" trebuie să fie o legătură simbolică spre fișierul ce conține efectiv nucleul, iar fișierul "initramfs" trebuie să fie o legătură simbolică spre fișierul ce conține efectiv initramfs;
7. Montați undeva fișierul imagine cu mount -o loop și în fișierul /boot/loader/grub/grub.cfg, creați o nouă intrare în meniul Grub (imaginea din textul articolului este formatată ca reiserfs, astfel încât s-a adăugat modulul pentru reiserfs; va trebui să încărcați modulul ext2 dacă aveți o imagine de partiție formatată ca ext, ext3 sau ext4):

menuentry "GNU/Linux in a file" {
  insmod part_gpt
  insmod fat
  insmod reiserfs
  insmod ext2
  insmod gzio
  set root="hd0,gpt2"
  loopback loop ($root)/hn-root.img
  echo "Loading Linux…"
  linux (loop)/boot/kernel root=/dev/ram0 
    real_root=/hn-root.img raw_loop_root_host_  
    partition=LABEL=hostpart ro
  
  echo "Loading initial ramdisk…"
  initrd (loop)/initramfs
}

1. Editați /etc/fstab și ștergeți tot conținutul fișierului, apoi adăugați următoarele linii:

   LABEL=EFI-BOOT /boot/loader vfat noauto,noatime 1 2
   LABEL=hostpart /hostpart auto noatime 0 1

2. Demontați fișierul și copiați-l pe sistemul destinație; instalați grub pe dispozitivul de stocare al serverului: grub2-install --target=x86_64-efi --boot-directory=/boot/loader --efi-directory=/boot/loader; va trebui să utilizați chroot de pe un stick USB cu Live Linux (System Rescue CD, de exemplu) pentru a putea instala grub, însă această procedură e în afara scopului acestui articol.

Un alt câștig al utilizării fișierelor imagine e că face posibilă schimbarea distribuțiilor Linux extrem de facilă. Doar copiați un fișier hn-root.img ce conține altă distribuție de Linux și ați terminat!

În partea a doua din articol se va prezenta sistemul de stocare distribuită XtreemFS, iar în partea a treia, se va analiza virtualizarea sistemelor (folosind LxC și KVM) și aplicațiilor (utilizând Docker). Când openStack va fi disponibil în una dintre imaginile noastre,se va realiza a patra parte, în care vom expune detalii despre modul în care noi vom folosi OpenStack.

Configurația descrisă este momentan în construcție, iar unele componente nu sunt create încă. Deci, rămâneți pe fir!