printf(" SaltwaterC ");

Nu o să descriu o metodă generală de kernel upgrade pentru că nu cunosc una ce să meargă pe restul distribuțiilor. Canonical este un susținător activ al virtualizării, iar în cazul Amazon EC2 au pus umărul și oferă suport oficial pentru Ubuntu. Deci o să mă limitez la Ubuntu Server 10.04 LTS.

Dacă ar fi să mă iau după trendul celor de la RightScale de a merge “doar înainte în cloud”, atunci ar trebui să complic problema mai mult decât trebuie să se complice. Din nefericire nu toate aplicațiile au fost create ca să se muleze acestui model: “creez instanțe noi, pe cele vechi le arunc la gunoi”. Iar faptul că au dezactivat butonul de stop instance nu înseamnă că oricine trebuie să se muleze acestui model.

Tipul de management de mai sus presupune:

- apt-get update && apt-get dist-upgrade pentru a avea noul kernel pe disk
- snapshot la EBS (dacă există)
- creat AMI nou cu kernel ID nou
- adăugat instanță nouă in spate la load balancer
- oprit instanță veche

Tipul de management în viziunea subsemnatului:

- apt-get update && apt-get dist-upgrade pentru a avea noul kernel pe disk
- oprire instanță EBS backed
- schimbat atributul kernel (ec2-modify-instance-attribute –kernel $kernel_id $instance_id)
- pornire instanță

TADA!

Load balancerul și aplicația nu o să tușească la acest model. Pe cuvântul meu de cercetaș. Și se poate automatiza la fel de bine ca și modelul pe care-l propun alții.

Bila neagră către Amazon este faptul că nu o să câștige vreodată vreun concurs de uzabilitate. Modul în care și-au gândit anumite chestii sună mai mult a box împotriva unui API și mai puțin simpla utilizare a lui. Din fericire, cum ziceam mai sus, Canonical oferă suport oficial. Deci gasirea acelui $kernel_id magic nu este tocmai căutare în acul cu fân, dacă rogi frumos EC2 API Tools:

Update: Canonical se dovedesc a fi parte a conceptului “world-class pain-in-the-ass”. Noile imagini de kernel, se găsesc folosind:

ec2-describe-images -o 099720109477 --filter name=ubuntu-images/ubuntu-lucid-\*

Ce am zis mai jos rămâne valabil până la kernel 2.6.32.312-ec2. Mai nou, imaginile sunt în /ubuntu-images/.

# pentru mașini 64-bit
ec2-describe-images -o 099720109477 --filter name=ubuntu-kernels/ubuntu-lucid-amd64\*
# sau, pentru mașini 32-bit
ec2-describe-images -o 099720109477 --filter name=ubuntu-kernels/ubuntu-lucid-i386\*

Notabil este faptul că în /ubuntu-kernels/ se găsesc versiunile considerate stabile. Mai există și chestii ceva “bleeding edge”, dar vorbim de mediu de producție, nu de joaca de-a virtualizarea.

Update: la 2.6.32.316 (1 Iunie 2011) au revenit la schema de publicare explicată inițial. Doar 2.6.32.314 nu apare în listă, fiind nevoie să fie pescuit de prin lista de imagini oficiale.

Am stat și am rumegat puțin problema unui cluster memcached ce s-ar putea face peste Amazon EC2. Patru instanțe t1.micro costă mai puțin decât o instanță m1.small ($0.02/h vs $0.085/h, la preț on-demand). În plus, pentru a avea o oarecare disponibilitate a unui cluster de caching, este nevoie de minim două instanțe din moment ce în mod cert în producție vor exista momente în care există mentenanță planificată. Iar la capitolul capacitate, patru instanțe t1.micro depășesc o instanță m1.small. t1.micro are 613MiB RAM dintre care se pot utiliza să zicem vreo 512MiB pentru memcached, pe când dintre cei 1.7GiB RAM disponibili pe o m1.small, sunt utilizabili vreo 1.6GiB. Patru instanțe t1.micro oferă așadar o capacitate mai mare unui cluster memcached decât o singură instanță m1.small. Iar rezervarea pe 3 ani pentru t1.micro costă $84. Deci nu e gaură în cer sau la buzunar.

Cu toate acestea, pentru început, dacă aplicația nu are cerințe mari (iar în general nu sunt pentru multe aplicații), două instanțe t1.micro pentru un cluster minimal sunt suficiente. Iar dacă este nevoie de mai multă capacitate, se poate adăuga oricând o nouă instanță, deci un “building block” poate fi prestabilit.

Acum nu vreau ca lumea să privească memcached ca pe un panaceu. Au pornit mulți de la ideea că a face caching în memcached este eficient în orice mod de utilizare. Nu este. Pentru o singură instanță, un “file based caching” este mult mai eficient. Da, se stochează pe disk, da disk-ul este mai lent decât memoria, dar acel kernel cache nu doarme degeaba. Acolo se duce memoria pe care bobocii cred că le-o mănâncă Linux-ul. Până și acele API-uri de caching din extensiile de PHP ce fac opcode caching sunt mai eficiente decât memcached, deși mai puțin eficiente decât acel PHP API cu condiția ca mașina care rulează aplicația să aibă suficientă memorie disponibilă pentru a face și kernel cache. Da, memcached pe local e mai ineficient pentru că IPC-ul presupune overhead. Au fost concluziile simple pe care le-am tras cu un benchmark simplu scris folosind Codebench. Nu mai am sursele, dar cred că o să-l reproduc curând și o să public rezultatele, pentru a încheia cu mitul memcached = panaceu.

Este totuși util pentru instanțe ce sunt puse în spatele unui ELB, Auto Scaling are grijă de instanțele EC2 ce rulează în spatele acestui ELB, și este nevoie de un cache consistent, distribuit. Un cache local pentru un cluster de mașini ce rulează o aplicație poate pune probleme de coerență și complică mult situația dacă aceasta rulează pe un cluster. Deși e mai lent ca o soluție locală, lentoarea unui RDBMS este în general mai mare, deci aici intervine modul potrivit de utilizare al memcached. S-ar putea utiliza și instanțele pe care rulează efectiv aplicația, dar în acest caz, adăugarea de capacitate devine dificilă. Auto Scaling (folosind strict uneltele Amazon EC2) devine imposibil. Deci, are sens un cluster extern mașinilor ce rulează aplicația. Și nu, nu vreau să aud de cluster file system. Introduce mai multe probleme decât rezolvă și spun asta pe cuvând de cercetaș. Iar Auto Scaling nu este musai să fie acel nume pompos de marketing ce îi face pe unii să creadă că au scăpat de “capacity planning” sau că e o soluție auto-magică la problemele de scalabilitate. Cel mai civilizat mod de utilizare este acela de a menține un număr minim de instanțe de un anume tip să fie “up and running”.

Să dau și o listă de cerințe.

1. OS cu suport îndelungat
2. 32-bit
3. Configurație minimală
4. Mod de adresare fix

Să le iau pe rând.

1. Ubuntu 10.04 LTS este potrivit obiectivului stabilit. Canonical oferă 5 ani de actualizări pentru versiunile de server LTS . În plus, Canonical oferă AMI oficiale pe care le menține, deci pe lângă base system și userland, sunt asigurate și actualizările pentru kernel.
2. Pentru că 64-bit nu aduce un plus de performanță, doar mai mult “overhead” pentru memorie. Deci nu merită efortul de a construi o imagine pentru 64-bit. De la t1.micro pe 64-bit se poate face upgrade doar la instanță m1.large, deci costurile cresc pe măsură iar aplicația trebuie să fie una destul de mare ca să necesite asemenea capacități de memorie pentru un cluster de caching. În același timp, dacă management-ul unui cluster t1.small pe 32-bit devine prea complicat (deși nu ar trebui să fie cu uneltele potrivite), se poate trece la m1.small, deși se primește mai puțin “bang for the buck”.
3. Deși imaginile Canonical sunt destul de subțiri (ideea de JeOS), au totuși prea multe servicii ce rulează în mod implicit și rulează degeaba. În plus, deși în prezent nu mai vin cu un root EBS de 15GiB (de când s-a introdus acel “free tier”), au totuși un root EBS de 8GiB. La exemplul meu inițial cu 4 instanțe, să zicem că 6GiB sunt aproximativ degeaba. 2GiB pentru o instanță memcached sunt suficienți. Într-un an, acei 24GiB de EBS storage nefolosiți practic, se traduc într-un cost suplimentar de $28.8. Nu este mult ținând cont de prețul altor servicii, dar se adună acolo iar cum Amazon au obiceiul să pună taxă pe absolut cel mai mic detaliu, optimizez în această direcție. Pentru că pot.
4. Amazon EC2 în mod implicit are un mod de adresare a mașinilor folosind adrese ce se pot schimba. Pentru a elimina reconfigurarea aplicației, Elastic IP vine în ajutor, dar nu în modul intuit de oricine. Modul implicit presupune costuri suplimentare ce se pot rezolva.

1+2. Ubuntu 10.04 LTS 32-bit

Pe alestic se găsesc multe resurse legate de Ubuntu pe EC2. Partea interesantă este acel tabel de pe prima pagină ce listează imaginile oficiale ale Canonical în funcție de zonă, arhitectură și root device. Restul e can-can. O instanță poate fi adusă sus în maxim câteva minute, deci nu o să insist cu partea ușoară a lucrurilor.

3. Configurație minimală

Din moment ce nu insist asupra lucrurilor ușoare, este evident că o să insist asupra celor mai puțin evidente la o primă vedere. Pentru început, subțierea numărului de servicii. Se ia scriptul de mai jos, se trântește într-un *.sh și se execută.

#!/bin/bash
 
if [ $(id -u) -ne 0 ]
then
	echo "Please run me as root."
	exit 1
fi
 
apt-get -y remove --purge consolekit
rm -rf /var/log/ConsoleKit
apt-get -y autoremove --purge
 
function disable_service
{
	if [ -f /etc/init/$1.conf ]
	then
		echo "Disabling $1"
		stop $1
		mv /etc/init/$1.conf /etc/init/$1.conf.noexec
	else
		echo "$1 is already disabled"
	fi
}
 
function map
{
	if [ $# -le 1 ]
	then
		return
	else
		local f=$1
		local x=$2
		shift 2
		local xs=$@
		$f $x
		map "$f" $xs
	fi
}
 
map disable_service atd cron dbus rsyslog tty2 tty3 tty4 tty5 tty6
 
cpucount=$(grep -c 'model name' /proc/cpuinfo)
if [ $cpucount -ne 1 ]
then
	echo "You have a multicore system, irqbalance is fine"
else
	disable_service irqbalance
fi

Maniacii ar putea stoarce mai mult cu mingetty vs getty, busybox vs Core Utils și Dropbear în loc de OpenSSH, dar personal nu-mi complic viața atât de mult pentru câțiva megi de RAM. Acestea fiind spuse, se poate trece la faza următoare.

Memoria swap nu există pe t1.micro, dar se poate pune într-un fișier. Personal am optat pentru 256MiB. În mod normal nu ar trebui să se atingă pentru un memcached de 512MiB, dar e mai sigur așa decât un crash de sistem pe spinarea unui OOM error.

dd if=/dev/zero of=/swap bs=1M count=256
mkswap /swap
swapon /swap

Pentru a-l pune la boot, trebuie adăugată următoarea linie în coada lui /etc/fstab:

/swap none swap sw 0 0

Se poate șterge linia aia ce ar trebui să monteze “ceva” în /mnt. t1.micro nu are “ephemeral storage” spre deosebire de instanțele mai mari. Pentru mai multe detalii legate de swap, se poate apela cu încredere la documentație, deși înafară de vm.swappiness nu prea văd ce s-ar putea mânări prin configurare.

Instalarea memcached care în zona ușoară: apt-get install memcached. Configurarea presupune editarea lui /etc/memcached.conf și anume -m 64 modificat în -m 512, comentată linia cu -l 127.0.0.1 și restart la serviciu cu /etc/init.d/memcached restart. Cei îngrijorați de faptul că se ascultă pe interfața “externă” pot să stea liniștiți atâta timp cât n-au un Security Group configurat cu picioarele iar 11211 nu e port public.

Recomand instalarea lui ntp pentru a minimiza problemele legate de timp în sistem. apt-get install ntp și se poate uita de faptul că a fost instalat.

Opțional se poate instala și monit pentru a avea un polițai ce să țină un ochi pe celelalte servicii. Personal îl folosesc cu următoarea configurare:

set daemon 60 with start delay 120
set eventqueue basedir /var/monit slots 256
set logfile /var/log/monit.log
include /etc/monit/conf.d/*

Nu mi-am bătut capul cu email reporting aka să instalez și un MTA (sendmail sau echivalent). De fapt totul e minimal. În conf.d am următoarele:

 # fișierul memcached
check process memcached with pidfile /var/run/memcached.pid
start = "/etc/init.d/memcached start"
stop = "/etc/init.d/memcached stop"
if failed host 127.0.0.1 port 11211 type TCP then restart
if 5 restarts within 5 cycles then timeout
 
# fișierul ntp
check process ntpd with pidfile /var/run/ntpd.pid
start program = "/etc/init.d/ntp start"
stop  program = "/etc/init.d/ntp stop"
if failed host 127.0.0.1 port 123 type UDP then restart
if 5 restarts within 5 cycles then timeout
 
# fișierul ssh
check process sshd with pidfile /var/run/sshd.pid
start program "/etc/init.d/ssh start"
stop program "/etc/init.d/ssh stop"
if failed port 22 protocol SSH then restart
if 5 restarts within 5 cycles then timeout

Acum ajung la partea cu disk space-ul minimal pentru root EBS. Amazon cere bani pentru spațiul rezervat, nu pentru spațiul utilizat. Un sistem complet instalat, cu swap de 256MiB și cache apt gol (apt-get clean) ocupă în jur de 894MiB. Am zis 2GiB pentru siguranță și eventualele upgrade-uri mai mari. Deși nu e “rocket science”, este totuși o procedură puțin mai dificilă față de majoritatea operațiilor. Recomand salvarea setup-ului de până acum ca AMI pentru a avea un backup în caz de erori și a nu fi nevoit să repeți toți pașii de mai sus. Personal, folosesc următoarea metodă:

aminame="image-name"
volumeid="vol-volume-id"
snapshotid=$(ec2-create-snapshot "$volumeid" | cut -f2)
kernel="aki-kernel-id" # Spre exemplu pentru 2.6.32-311 este aki-407d9529
 
while ec2-describe-snapshots "$snapshotid" | grep -q pending
do
	echo -n .
	sleep 5
done
 
ec2-register --architecture i386 --name "$aminame" --snapshot "$snapshotid" --kernel "$kernel"

Metoda de mai sus se va folosi și pentru a salva AMI-ul final. Deci nu o să o mai repet.

Partea de resize presupune o nouă instanță la care se va atașa root EBS-ul instanței folosite până în prezent din moment ce nu se poate edita un filesystem montat. Deci se oprește instanța pe care s-a lucrat până acum. EBS-ul se detașează tot din EC2 API Tools:

auxinstanceid='i-instance-id-aux'
ec2-stop-instances $instanceid
while ! ec2-detach-volume $volumeid; do sleep 5; done
ec2-attach-volume --instance $auxinstanceid --device /dev/sdf $volumeid

$auxinstance – așa am botezat noua instață auxiliară pe care se va face resize-ul. Se purcede la micșorarea filesystem-ului existent:

fsck -n /dev/sdf # device-ul montat pe $auxinstance, dacă e totul OK se merge mai departe
tune2fs -O ^has_journal /dev/sdf # se oprește jurnalul - practic partiția devine una ext2
e2fsck -f /dev/sdf
resize2fs /dev/sdf 1500M # aici nu are dimensiunea finală, dar am pus mai mic ca să nu am probleme mai încolo
fsck -n /dev/sdf
tune2fs -j /dev/sdf

După aceasta am creat noul disk de 2GiB pe care să-l atașez lui $auxinstance ca /dev/sdg. De îndată ce noul disk este montat, se poate copia de pe vechiul disk:

dd if=/dev/sdf ibs=16M of=/dev/sdg obs=16M count=128
resize2fs -p /dev/sdg
e2fsck -f /dev/sdg

Este nevoie de aceasta deoarece Amazon nu permite să se creeze un disk mai mic decât snapshot-ul de bază, deci metoda directă: snapshot – create new smaller disk – nu convine. Ambele volume se pot detașa de instanța auxiliară. Noul volum mai mic se va atașa la vechea instanță de bază. Dacă totul e OK, și ar trebui să fie dacă la acele (e2)fsck nu a dat erori, atunci o să pornească instanța pe disk-ul mai mic. Se poate verifica ușor cu df -h. După aceasta se poate creea un AMI pornind de la această instanță și folosind metoda descrisă anterior pentru salvarea unui AMI intermediar.

4. Adresare fixă prin rețeaua internă

Elastic IP-ul este prin definiție public. Adică cel puțin peste tot apare ca fiind un IP public. Din moment ce protocolul memcached nu are autentificare în mod implicit, complică problema și prin faptul că trebuie făcut un firewall pe fiecare instanță ce să țină cont de acest aspect, problemă ce poate pune bețe în roate unui auto-scaling (sau să-l complice foarte mult). În același timp, memcached folosește client side clustering, deci ordinea de adresare a serverelor și adresarea fixă este esențială.

Amazon ar putea oferi un subdomeniu fix ce ține de instanță nu de adresă. Chestia asta ar rezolva problema cel puțin parțial (depinde de context). Cu toate acestea (încă?) n-am văzut astfel de implementare. Ar reduce necesitățile de Elastic IP ce au un număr limitat de 5 per cont, după care trebuie cerută creșterea acestei limite. Cererea nu costă, dar este enervant atunci când se epuizează spațiul de adrese disponibil.

De ce am pomenit de DNS? Simplu. Adresele acelea de Amazon, spre exemplu 1.1.1.1 au atașate un subdomeniu: ec2-1-1-1-1.compute-1.amazonaws.com. Rezolvat din afara rețelei Amazon, acesta va returna 1.1.1.1. Magia se întâmplă în interiorul rețelei Amazon, unde rezolvarea lui ec2-1-1-1-1.compute-1.amazonaws.com se face către adresa internă a serverului, spre exemplu 10.0.0.1. Elastic IP se supune acestei reguli. Folosirea unui Security Group reduce pacostea de a configura dinamic un firewall deoarece mașinile parte a unui grup pot comunica nerestricționat între ele folosind rețeaua internă, cu condiția ca acel grup să conțină o referință către sine. Iar traficul intern, spre deosebire de cel extern, nu este contorizat și facturat. Deci, clientul memcached, dacă se conectează la două mașini, spre exemplu 1.1.1.1 și 1.1.1.2 va folosi adresele ec2-1-1-1-1.compute-1.amazonaws.com și ec2-1-1-1-2.compute-1.amazonaws.com ce vor rezolva adresa internă. Dacă o mașină este oprită, IP-ul intern alocat se va schimba. Deasemenea acest lucru se va întâmpla și dacă se înlocuiește instanța din spatele acelui Elastic IP. Ori, folosind strategia anterioară, aplicația client nu va trebui modificată cu nimic. Totul se face transparent, în spatele scenei.

Câteva referințe:

http://www.howtoforge.com/linux_resizing_ext3_partitions
http://alestic.com/2010/02/ec2-resize-running-ebs-root
http://serverfault.com/questions/183552/shrinking-amazon-ebs-volume-size

Vestea bună este faptul că a apărut Ubuntu 10.04. Vestea proastă este faptul că suportul pentru OpenVZ în kernel 2.6.32 a apărut prea târziu pentru a fi inclus în distribuție. Sunt conștient de faptul că LXC (Linux Containers) va fi următoarea tehnologie de virtualizare la nivel de sistem de operare. De fapt a fost adoptată în mainline la nivel de kernel. Dar între timp OpenVZ a strâns o comunitate destul de mare și suficiente unelte de administrare pentru a nu îl face bun de aruncat la gunoi în secunda numărul doi. În plus, migrarea de la o tehnologie de virtualizare la alta nu se poate face imediat.

Probabil buba cea mai mare pe care o are (momentan?) Ubuntu 10.04 în ceea ce privește suportul pentru OpenVZ nu este faptul că (momentan?) nu poate fi folosit pe post de HN (Hardware Node), ci faptul că are probleme destul de mari în rularea ca guest. Abia acum am înțeles de ce DAB (Debian Appliance Builder) nu a venit cu suport pentru Ubuntu 9.10, iar acum pentru 10.04. Noul sistem de init, upstart, ce practic înlocuiește vechiul SysV init, nu se prea pupă cu OpenVZ, cel puțin nu implicit în unele pachete de servicii incluse în distribuție. Nu o să mai aduc aminte de clasica deja incompatibilitate între udev și OpenVZ.

Există mai sus vreo două întrebări din categoria “momentan”. Prima cel mai probabil va rămâne la stadiul de permanent. Din moment ce echipa din spatele Ubuntu adoptă LXC, eventualele bug-uri legate de OpenVZ vor intra în caregoria “won’t fix / invalid”, deci feedback-ul din partea comunității să se piardă. Sau să se ajungă la “by popular demand” – sper, deși slabe șanse. Cea de-a doua chestie în schimb se poate să fie rezolvabilă printr-un kernel comunitar ce să includă suport pentru OpenVZ (sper și pentru KVM). Între timp, Proxmox rulează și va adopta 2.6.32 și pentru OpenVZ. Momentan știe doar de KVM.

Ca regulă, cel mai probabil anumite servicii nu vor porni automat, la boot, fără a modifica scripturile de init, ce se găsesc în /etc/init nu în /etc/init.d (un upstart job din init.d este practic un symlink). Suport pentru SysV Init script încă mai este posibil dacă init-ul nu a fost convertit în upstart job din moment ce upstart a fost conceput cu gândul la “backward compatibility”. În ceea ce mă privește, cele mai problematice până acum au fost networking, ssh și mysql. Morala este: pentru a folosi Ubuntu 10.04 ca OpenVZ guest, este nevoie de pregătiri pentru doi termeni de bază: “hack” și “patch”. Cu toate acestea, consider că merită efortul. Lucid Lynx include suficiente soluții actualizate pentru a renunța la vechiul LTS, Ubuntu Hardy. Sau, de ce nu, la Debian Lenny.

Pentru că nu dețin toate informațiile, dau următoarele link-uri de unde mă inspir și eu:
Ubuntu 10.04 OpenVZ Templates
Download Ubuntu 10.04 OpenVZ Templates

Pentru că nu îmi place lucrul manual atâta timp cât există lucruri precreate:
http://bodhizazen.fivebean.net/openvz/

Printre altele, a trebuit să downloadez template-ul lamp pentru a mă inspira din scripturile de init pentru minimal. Sunt adeptul stilului minimal peste care să fac lego instalând direct din repo atunci când plasez o soluție. Less is more!

Băieții ăștia faini de la Proxmox ce se ocupă de Proxmox VE printre altele, soluția de virtualizare ce o recomandam în articolul anterior pentru testarea de configurații, au mai scos un hit: Debian Appliance Builder, pe scurt dab. Acum să nu se înțeleagă din fraza anterioară faptul că Proxmox VE nu ar fi bun în producție. Cel puțin OVH folosește în producție produsul menționat anterior.

Dar să revenim la builder. Practic dab este un utilitar menit să subțieze destul de mult procesul de creare al unui template Debian. De fapt procesul în sine nu e mare filosofie, dar este stufos și necesită cel puțin un shell script pentru a reduce repetitivitatea. Cei de la Proxmox au reușit prin automatizarea etapelor de creare să reducă timpul și complexitatea necesară creării unui template OpenVZ pentru Debian. Având în vedere că Ubuntu este compatibil din punct de vedere binar cu upstream-ul (cel puțin la nivel declarativ), dab suportă printre altele și crearea de template-uri pentru câteva versiuni ale acestei distribuții.

Distribuții suportate de către Debian Appliance Builder:

• Debian Etch (4.0) (Legacy Stable)
• Debian Lenny (5.0) (Stable)
• Ubuntu Hardy (8.04) (LTS)
• Ubuntu Intrepid (8.10)
• Ubuntu Jaunty (9.04)

Remarcabilă este absență lui Karmic, deși nu este esențială având în vedere că următorul LTS, Ubuntu Lucid Lynx (10.04), stă să apară. Momentan a poposit la Beta 1.

Practic pașii necesari creării unui template au fost reduși la:

1. crearea unui fișier de configurare (dab.conf) cu o sintaxă “key: value” relativ simplă, explicată în documentație. Joacă rol de “metadata”.
2. init – moment în care se citește lista de pachete din repo-urile distribuției alese
3. bootstrap cu opțiuni, unde subsemnatul preferă “–minimal”. Prefer să am un setup minimal și să instalez din repo pachetele în funcție de context în momentul în care ajung la deploy. Less is more. La bootstrap se face downloadul efectiv al pachetelor în directorul cache al structurii pe care se construiește template-ul.
4. [opțional] instalare de pachete suplimentare. Minimalul lor nu corespunde minimalului meu, ce presupune și: htop, sysv-rc-conf, sysvconfig, bzip2.
5. configurare. Minimal în terminologia mea nu înseamnă o chestie redusă la dimensiune până la absurd, gen template-urile minimale de pe openvz.org ce funcționează cu o târlă de erori ce trebuie reparate de mână înainte de deploy. Plus faptul că sunt actualizate din an în Paște din moment ce sunt în secțiunea contrib iar maintainerii sunt de Duminică (one time only?). Printre altele, le optimizez pentru consum de memorie redus, și anume oprirea serviciilor ce nu sunt necesare cel puțin pe moment: cron, postfix, syslog (cu variații în funcție de distro), ceea ce se traduce prin: într-un container chel o să fie un memory footprint inițial de 1-2MiB necesar serviciului OpenSSH, după cum se lăudau și cei de la IntoVPS. Recordul personal e de 1MiB pe un template Debian Lenny i386 și aș merge pe varianta cu Dropbear în loc de OpenSSH doar de dragul virtualizării și a testării scenariului de “VPS small”. Timp pentru teste să găsesc. Ca dimensiune, ies în jur de 95MiB în urma arhivării gzip, în jur de 275MiB dezarhivat.
6. finalizare – ceea ce presupune curățarea automată a template-ului din containerul temporar urmată de arhivare. Având în vedere faptul că Proxmox VE necesită o sintaxă rigidă în ceea ce privește numele unui template ce trebuie să se regăsească în /var/lib/vz/template/cache (de pe la v1.2 dacă nu mă înșeală memoria), partea de finalize este un real ajutor pentru că se ocupă automat de numele buclucaș.

Singura bubă ce i-am găsit-o până acum este lipsa unui suport bun pentru edit & deploy. Cel puțin mie de îndată ce am rulat dab finalize – nu am mai putut reveni la reconfigurare, rearhivare, retestare. Din fericire dab clean nu șterge lista de pachete. Doar dab dist-clean face curățenie pe acolo, lăsând doar fișierul dab.conf și directorul cache ce e gol (WTF?).

Printre altele suportă crearea de template-uri folosind make și un Makefile. Nu îmi manifest interes deosebit pentru sintaxa Makefile cu care nu sunt familiarizat, iar shell scripting-ul e mai distractiv dacă tot e să automatizăm automatizarea. Suportă anumite scenarii gen bază de date sau PHP, dar cel puțin subsemnatul preferă să facă de mână instalarea de servicii esențiale în funcție de tipul de mașină, fie din repo, fie din surse dacă versiunea din repo e de pe vremea lui Nae.

Per total e un utilitar ce te poate scăpa de stufoșenia creării template-urilor de Debian/Ubuntu folosind debootstrap și un shell, utilitar ce îl Recomand™.

Problema reproducerii unui setup compatibil din punct de vedere binar este mai simplă decât pare cu condiția să se apeleze la anumite ajutoare, ajutoare de natură virtuală. Este destul de contra-productiv să instalezi un OS de fiecare dată pe când este nevoie de o instanță curată, fie că dispui de o mașină dedicată, fie că folosești un hypervisor local. Știu că în aparență propoziția anterioară contrazice folosirea virtualizării, dar nu am menționat ce tip de hypervisor se recomandă pentru acest obiectiv specific.

Atâta timp cât trebuie testată doar compatibilitatea userland-ului, o soluție de virtualizare bazată pe OS level virtualization este suficientă, adică se folosesc containere, nu instanțe virtualizare complet. Spre exemplu un setup testat local în container va putea rula pe un VPS, pe un VDS sau pe o mașină dedicată fără probleme. Nu o să fac referire la FreeBSD Jails și Solaris Containers pentru că am puțină experiență cu Jails și zero experiență cu Containers. În plus, destul de mulți se orientează în prezent spre Linux.

Dacă ești vreun guru în a rula vzctl în shell sau masochist, poți să te oprești din citit. Dacă nu, atunci voi vorbi în continuare despre OpenVZ plus metode civilizate și productive de a reproduce un setup. Bariera de intrare printre membrii ce folosesc tehnologia este destul de sus, motiv pentru care au apărut soluții integrate. Dintre acestea, recomand Proxmox VE (Virtual Environment). Băieții aceștia faini de la Proxmox au luat mai multe tehnologii de virtualizare și le-au pus sub același pachet: KVM (Kernel-based Virtual Machine) și OpenVZ, plus o interfață web pentru administrare. Practic Proxmox VE este un Debian Lenny împachetat cu tehnologiile despre care spuneam mai sus.

Setup-up este cretin de simplu, durează vreo 5 minute, se face pe o mașină ce nu are un alt OS. Își alocă tot disk-ul și își face partiții LVM. Este recomandat minim 2GB de RAM disponibil dacă se folosesc mai multe containere, minim 1GB RAM pentru un container folosind pentru ‘package maintenance’ ce are suport SMP și se folosește parallel build. Spre exemplu la un build de PHP cu make -j 3 am rămas fără memorie în container de 512MB RAM. Da, nu recomand instalarea unui compilator în producție sau build pe live servers. Alternativa ar fi DIY, adică o distribuție de Linux ce folosește kernel cu patch pentru OpenVZ, preferabil din repo, plus o interfață web precum WebVZ sau HyperVM.

Proxmox VE se poate instala fie direct pe fier (bare-metal hypervisor), fie într-o mașină virtuală creată cu VirtualBox ce este soluția pentru “desktop” ce o recomand. Am pus desktop între ghilimele pentru faptul că VirtualBox are o arhitectură complexă expusă prin CLI. În GUI se găsește doar un set limitat de funcții. În cazul în care se instalează într-o mașină virtuală creată cu VirtualBox (sau echivalent), nu se vor putea crea mașini virtuale folosind KVM pentru că este nevoie de extensiile de virtualizare din procesor (VT-x sau AMD-V) pentru aceasta. Oricum, scopul principal al acestui articol este OpenVZ datorită flexibilității ce o oferă. Acesta este motivul pentru care merită chiar și soluția de hypervisor sub hypervisor dacă nu îți permiți luxul unei mașini dedicate. În principiu pe o stație de lucru suficient de puternică nu ar trebui să fie probleme în ceea ce privește rularea unui Proxmox VE sub VirtualBox. Îmi permit aroganță de a menționa faptul că nu am mai lucrat de mult pe o mașină sub quad și 8GB RAM.

Având în vedere faptul că pentru OpenVZ se pot crea relativ ușor template-uri, iar virtualizarea constă în crearea unui container nou, operațiunea prin care se obține un nou setup durează destul de puțin. Iar în cazul în care un container nu mai este necesar, distrugerea acestuia este o operațiune rapidă. Practic se obține propriul mini-cloud, ușor de administrat, ce va scădea timpul în care se creează diferite scenarii ce vor ajunge în producție.

În cazul în care nu am fost suficient de clar la început, repet: setup pentru testarea userland-ului. OpenVZ oferă acces limitat la kernel din moment ce nu folosește virtualizare completă a sistemului de operare, doar rețeaua este virtualizată. Spre exemplu folosind kernel-ul livrat cu Proxmox VE se pot folosi FS-uri virtuale bazate pe FUSE dacă se sapă puțin prin vzctl, ceea ce deschide anumite posibilități în producție gen s3fs (netestat sub OpenVZ de subsemnatul, am testat alte module FUSE) prin intermediul căruia se poate monta un bucket de Amazon S3 ca FS local. De altfel, am reprodus și un sistem desktop într-un container OpenVZ, Ubuntu Hardy, accesat prin FreeNX, deci limitările sunt destul de puține gen lipsa unui suport civilizat pentru loop device.