> Cand o sa apara o sa fie si o metoda de mitigare a lui. > Evident. Voiam doar sa subliniez ca ideea de securitate e relativa in acest caz. > > Pai iei UN server quad-core, pui pe el un super-so si rulezi toate > > aplicatiile de care ai nevoie, despre asta vorbeam. Sau DOUA, pui un > > super-SO care stie sa lucreze in cluster cu ambele, si rulezi toate > > aplicatiile pe el avand si redundanta. Inca o data, e vorba de teorie. > > Inca nu exista acel super so. Daca tot e teorie putem sa ne aberam la > nesfarsit.
Pentrul colegul colistas... poate ca exista deja, si se cheama Linux :) Cum din ce a zis el nu apare necesitatea de SQL, Exchange sau AD, metoda cea mai ieftina ar fi sa le puna pe toate pe o singura masina. > > E vorba de cluster la nivel de SO. Am vazut si eu pacaleala cu SQL-ul > > active-active, dar la care o instanta ruleaza pe un host iar cealalta pe > > cel de-al doilea ( dar care fiind pasiv, instanta de fapt lucreaza in > > regim de avarie tot pe primul) . > > Banuiesc ca scria asta si in documentie si in release notes ce inteleg > ei prin Active/Active, nu ? Da, dar tu asta ti-ai dori de la un cluster? Jumatate din investitia ta sa doarma 90% din timp ? Daca eu pun eticheta de coca cola pe sticla de apa de ploaie, devine mai aproape de coca-cola? Daca ei zic "Active/Active" la un design pe jumatate pasiv, ar trebui sa ii cred? Ziceam doar ca daca as avea un SO care sa stie sa ruleze pe doua masini si sa partajeze resursele amandurora as rezolva problema disponibilitatii care e considerata unul din "big point"-urile virtualizarii. De asta ma gandesc ca virtualizarea vine pe o nisa lasata libera de producatorii de SO. Ce e mai jos chiar ca nu mai e la subiect... > > > Nu scrie nimic de redundanta in RFC . Doar ca exista master si slave, > > computerul tau are setate doua dns-uri ( plus ceva cache) asa ca daca un > > DNS e down nici nu simti. Era doar de un exemplu de rezolvare simpla si > > eleganta a problemei disponibilitatii... de fapt nu prea are legatura cu > > thread-ul principal. > > Replicarea datelor unui server de DNS nu e musai sa se faca numai > folosind AXFR/IXFR. > > > Ma refeream la faptul ca pot exista solutii mai putin monstruoase > > la problemele clasice: redundanta, disponibilitate, load balancing. > > Sigur, la DNS e simplu sa faci load balancing, pt ca round robin e > > (aproape) la fel de bun ca oricare alta metoda ... fiindca practic orice > > cerere produce o incarcare la fel de mare ca alta. > > DNS-ul, ca si protocol, nu-ti ofera balansare round-robin. pentru ca in > functie de cine face query, poti avea mereu hit-uri doar pe un server si > alalalt sa primeasca rar query-uri. > > > La SQL de exemplu e mai complicat, pt ca > > poti sa ai un querry de 2 secunde si altul de 2 ore. Daca vin in secvente > > de cate doua de tipul asta si ai facut round-robin pe doua masini... din > > una s-ar putea sa iasa fum :) . > > Atunci exista solutii mai avansate de load-balancing care pot verifica > si incarcarea masinii, work queue, backlog si alte cele cand decide unde > trebuie plasat un query. > > > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug > > ------------------------------------- > Acest mail a fost scanat de BitDefender instalat pe serverul CG&GC si a > fost considerat OK. ------------------------------------- Acest mail a fost scanat de BitDefender instalat pe serverul CG&GC si a fost considerat OK. _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
