On Tue, 2004-09-28 at 12:15, Cristian Grigoriu wrote: > Dragos Manac wrote: > > >>>>>DNSuri cu split view > >>>> > > Frumos, corect, dar nu ajuta la redundanta ci din contra, incurca, > pentru ca va dirija clientii din anumite clase IP catre acelasi server > (presupus) cazut.
Era o solutie eventuala, poti avea doua webservere locale si doua externe, eu am facut o sugestie care s-ar putea sa-i fie de folos. > Am inteles si cu "accesul serverelor", trebuia sa citesc "accesul > la|spre servere". Totusi problema initiala era de availability si nu de > load-balancing. Ok, sper ca a fost entertaining. > > Era o solutie tehnica alambicata care se baza pe supozitia conform > > careia daca ti-a crapat nameserverul ti-a crapat si serverul web si > > masina cu totul. > > "se poate seta de undeva, cumva, vreo kestie, astfel incat daca serverul > 1 nu este accesibil la un anumit moment, un vizitator sa fie directionat > catre cel de-al doilea server ?" > > Uite asa suna enuntul problemei. Mie imi sugereaza crapatul cu totul. Crapat cu totul webserverul? Crapata masina cu totul? Nu e acelasi lucru. > Oricum exista o solutie simpla si la partea cu crapatul serviciului de > web: monitorizezi serviciul de web si cand moare acesta opresti > serviciul DNS pe aceeasi masina. Iar solutia initiala nu e mai > "alambicata" decat instalarea unui serviciu DNS si pe a doua masina. Eu am propus DNS-uri externe tocmai pentru a nu te frige cand iti moare masina (si nu mai poti face schimbari in DNS). In felul asta ai si posibilitatea de a dinamiza inregistrarile. > > Practic e mult mai simplu sa servesti 2 inregistrari > > care nu se vor cachea (de pe un namserver tinut intr-o alta locatie, sau > > de pe mai multe nameservere autoritative). S-ar putea sa-ti doresti sa > > schimbi intrarile din DNS in mers atunci cand unul din webservere e jos > > (hw failiure, retea, os, daemoni morti etc), sau, si mai elegant, sa ai > > un script de monitorizare care sa faca asta pentru tine. Statistic vei > > avea o rata de succes mai mare folosind aceasta abordare si practic un > > raspuns mai rapid. > > Ai mancat un "NU" :) "Statistic *NU* vei avea o rata de succes mai > mare...". Ai 50% sanse sa-ti serveasca mereu IP-ul serverului crapat. > Lucru care daca pentru un operator uman destul de incapatanat si de > norocos s-ar putea sa nu fie o problema, pentru un program va fi, daca > sa zicem servesti XML, RSS, repository etc. Nu ai urmarit toata rezolvarea. Daca monitorizezi masinile respective va da rateuri de 50% doar in perioada in care inca nu te-ai prins ca e mort (sa zicem 5 minute), dupa asta se updateaza recordurile si va fi aruncat spre un server functional. > >>Crezi ca daca reafirmi teoria ta initiala se schimba ceva? *Toate* > >>raspunsurile DNS se cacheaza. Cand expira, e treaba TTL-ului. > > > > Toate se cacheaza, inclusiv alea care nu se cacheaza, absolut corect. > > Uita-te bre in cod daca nu ma crezi. Se cache-aza toate si cand sunt > cerute, daca le-a expirat TTL-ul, se reface interogarea recursiva. In codul cui? Bibliotecii de resolving? Care e utilitatea, practic daca pui TTL 0 chiar daca e cacheata intregistrarea nu va mai fi valida la urmatoarea cerere. Mi se pare doar o chestiune de implementare atat timp cat rezultatul e acelasi. > > /me asteptand o noua slashdotare saptamana asta (setupul e gata, testat > > si functional de la ultima:) > > Slashdotare? Pai de-aia esti tu chitit pe load-balancing. Cand o sa fii > DDoS-uit (bat in lemn si cer scuze lu' Pruteanu) poate o sa-ti fie de > folos setup-ul meu. > > Grig Ma indoiesc ca imi va fi vreodata de folos. In cazul ala o sa-mi fie util DNS Split View si alte manareli artistice (nat and stuff). Alta poveste, daca vrei discutam si despre asta :) -- Arbeit macht frei! --- Detalii despre listele noastre de mail: http://www.lug.ro/
