On 15 Feb 2002, Florin Andrei wrote: > numai daca) se pricepe mult mai bine ca mine. Nu am nici un interes sa > dovedesc nimanui ce tare sint eu ca stiu sa compilez si chernelu', > mincatzi-as! Am insa un mare interes ca serviciile care ruleaza pe > masina aia sa mearga bine (fara caderi neasteptate, etc.) > Asadar, are o mai mare prioritate sa zici "nu mi se pare corect sa nu-mi > mearga bine serverul". Criteriul _asta_ decide ce e corect sau nu in > continuare. Restul sint detalii. >
Pai man totul inseamna control. Nu pot avea nici un control asupra unor programe care sunt compilate de unii , instalate de packager-ului meu etc... Ideea era ca punand binare si lucruri facute de altii pot avea surprize si ca sa le rezolv voi fi nevoit sa recurg tot la ei. Pe cand atunci cand am pus cu manuta mea tot voi sti unde sa caut cand sunt probleme si doar cand este ceva ce depinde de ei in 90% (buguri care mi-ar luat mult sa le rezolv eu) apelez la ei. E exact motivul pentru care nu am ales sa merg pe FreeBSD acum 2 ani cand puteam sa fac acest lucru. Am ales linux-ul pentru ca am considerat ca primeaza timpul de rezolvare a problemelor care este invers proportional cu numarul de ore "petrecute" cu acel sistem de operare, soft etc... Ori daca eu las pe altii sa imi puna ei soft pe sistem , sa il configureze ei si nu intru in cele mai mici detalii, sa nu ma mir de ce cand va apare vre-o problema voi fi in plop. > Cu alte cuvinte, efectiv nu ma intereseaza cine a compilat softul cutare > (eu sau altcineva) cita vreme ruleaza cel mai bine (nu pica, am > performanta buna). > E compilat de mine? Ok. E compilat de altii? Ok. > Teribilismele copilaresti apar tocmai la cramponarea de una sau alta din > alternative, si ridicarea ei la gradul de adevar absolut. > Normal ca acestea nu conteaza in uptime-ul serverului si al serviciilor sale. Dar sunt 2 lucruri care le urmaresc in instalarea/configurarea unui server (si a serviciilor): uptime cat mai mare, downtime cat mai mic. Poate ca logic nu prea face sens pentru ca daca ai uptime cat mai mare ai si downtime mai mic dar ideea era ca sa incerc sa il fac sa nu crape, dar de crapat TOT va crapa (am invata-o pe propria piele) indiferent ce voi face eu, doar ca timpul de repus in picioare (adica am invatat ca orice serviciu se ruleaza dintr-un watchdog care este la randul lui pornit respawn din init, si multe altele). Tot in reducerea downtime-ului intervine si abilitata mea personala de a identifica si rezolva problema (mai ales cele noi, care nu au putut fi prevenite). Acest timp depinde de abilitatea ta de a "hackui" acel siste/serviciu. Punand RPM-uri (doar ca idee, nu ca as avea ceva special cu RPM-ul) de la mysql si altii nu voi reusi sa reduc acest timp de downtime (adica nu ma indoiesc ca cele compilate de ei ruleaza "As Good As It Gets.. (TM)" :) doar ca oricum vor apare probleme si prefer o solutie facuta de mine chiar daca va rula mai slabut dar atunci cand vor apare probleme "noi"/originale voi avea un timp mic de identificat/eliminat problema). > (Bre, uite ca acuma mi-a venit o idee. Mai depinde si ce hardware > folosesti. Pe un taivanism e normal ca tweakuiesti kernele pina-ti vine > acru. Dar pe un brand-name trintesti distributia de la mama ei, mai ales > daca hardware-ul e in lista de certificari, si merge de n-are aere.) > Mda :). Ghici de ce am ales un Dell PowerEdge cand mi s-a cerut parerea despre o configuratie de server acceptabila. Cateodata nu ai de ales din acest punct de vedere, pentru ca pur si simplu in tara asta se vand taiwanisme in proportie de 99.99%. Daca ar fi un producator local care sa aiba echipa lui de ingineri care sa testeze configuratii si ar scoate un fel de semi-brand name (la preturi 30% din cele brand name serioase) sa mor io daca nu ar sparge piata (de servere ;) ) din Romania. > Daca spui ca asta e adevarat _intotdeauna_, atunci nu mai sintem de > acord (dupa cum am zis si mai sus). > Sint cazuri cind e adevarat, sint cazuri cind nu. Smecheria e sa > distingi intre ele. ;-) > Pe 99% din hardware-ul din Romania ( serverele din Romania ) trebuie sa testez solutia hardware pana ma plictisesc. De fapt asta ma oftica pe mine ca nu au cam toti developerii Open Source suita de scripturi de test. Pai e mult mai beton cu aia. Inteleg ca binarele lor sunt "certificate" si ca le-au verificat dar vreau sa le "certific" si pe ale mele , pe configuratia mea software/hardware (care conteaza foarte mult in medii de productie). > Daca "ultimul tick" inseamna >20%, sint de acord. Daca nu... > Plus ca eficienta utilizarii CPU-ului nu e unicul criteriu, desi > hackerul tipic intr-adevar cam asa tinde sa gindeasca. > Pentru orice hacker, ar fi un upgrade la creier semnificativ daca ar > gindi in proportie de 10% si ca un manager. E surprinzator ce multe se > schimba daca introduci aceasta proportie infima de stil de gindire > diferit (si reciproc, ca in cazul acelor rari manageri care stiu sa > gindeasca putin ca un hacker)! > CPU-ul, memoria, MTBF-ul, etc. sint resurse. Dar tot resursa e si timpul > pe care-l petrece Dizzy compilind MySQL. ;-) > Trebuie facuta o minimizare _globala_, nu doar una pe resursele pur > tehnice. Ideea e ca tu esti doar o bucatica dintr-o chestie mai mare, > care e intreaga firma, si optimizarile trebuie facute global, indiferent > ce inseamna asta pentru deciziile luate strict la nivelul tau. > Hmm poate pentru un manager nu e mare lucru , el calculeaza banii, el nu poate intelege ca eu NU sunt omul care sa revin asupra aceluias lucru de 10 ori. Domnule daca am pus/compilat/configurat/testat ceva apoi nu am chef ca 10 luni de acum inainte sa tot repar fac debugging/repar buguri. Ori asta se intampla cu softul "testat" de altii (care l-au testa in configuratia lor, care le mine nu prea se aplica). "Resursa" Dizzy compiland are si un temperament/atitudine/sentimente si s-ar putea sa nu mai lucreze prea productiv daca ultimele 10 luni a facut bugreporturi si a fost trezit din somn ca a crapat nu stiu ce serviciu... Ar trebui sa ia si asta in calcul :) > As putea povesti cum s-a ajuns la concluzia ca solutia optima (optim > global) pentru nucleul serviciilor SMTP la SGI este Sendmail, desi > optimul tehnic ar fi fost altul (vorbesc de o reconstruire din temelii a > nucleului care s-a facut recent); am urmarit procesul in toate fazele > lui si pot sa spun ca da, a fost o alegere corecta (per total, criterii > tehnice + non-tehnice). Asta in afara de faptul ca am invatat o gramada > de chestii (netehnice) din treaba asta doar belind ochii si ascultind. > Dar deja m-am intins la vorba (din nou :-D), si risipesc o resursa :-D > care ma doare foarte tare acuma: timpul. > Ideea mea este ca, intr-un mediu productie si HA ar trebui un departament de QA. Sa testeze, hackeze tot! Luand cazul particular pentru linux ar trebui sa aiba o distribuie proprie (sau poate o alegere din cele existente), versiuni de softuri proprii (adica cand e vorba de sql se pune mysql versiunea x.y.z ca stiu ei ca au testat pe acel hardware si e beton). Testele vendorilor linux NU pot inlocui acest lucru... Dar nu toate firmele isi permit departamente QA asa ca departamentul devine adminul ce are rolul de a instala acel soft. Ca altfel tot el o ia pe cocoasa cand e trezit la 5 dimineata de numarul de SMS-uri care le primeste de la programul de monitorizare :) > Pai din nou, asta e o afirmatie care "in principiu" e adevarata (vezi ce > ziceam mai sus despre resurse). Problemele apar atunci cind unii cred ca > este in mod absolut adevarata. Nu absolut ci in medii HA. > M$ a cistigat piata minimizind utilizarea resurselor non-tehnice pentru > cei care folosesc OS-urile lor (in detrimentul resurselor tehnice). O > atitudine extrema, care e bineinteles gresita. Dar si extrema cealalta e > tot gresita. > Corect. In incheiere, experienta m-a invatat ca pe sisteme de o anumita "complexitate" software (consider un sistem UNIX cu server pop3, imap, web, ftp un sistem muuuuuuuult mai complex dpdv software decat un ruter cisco, sau altfel spus decat echipamente dedicate) foarte greu (cu costuri enorme) poti ridica un sistem single dupa un anumit grad de uptime al serviciilor (sa zicem 96%). Adica sa cresc de la 96% la 97% tre sa ma apuc sa hackuiesc multe kestii pe acolo. Apoi sa mai cresc cu inca un procent deja rescriu parti din kernel ... Ideea este ca in medii HA daca vrei peste 96% uptime va trebui sa apelezi la redundanta... Deci mai multe sisteme oferind aceleasi servicii. Aici deja incepem alta poveste cu lipsurile linuxului in acest domeniu :). ---------------------------- Mihai RUSU "... and what if this is as good as it gets ?" --- Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to unsubscribe from this list.
