Dragos Manac wrote:

>>>>>DNSuri cu split view
>>>>
>>>>N-are nici o relevanta in context, oricum nu ajuta la redundanta. Split 
>>>>view faci cand doresti sa servesti atat adrese publice cat si adrese 
>>>>private (probabil din DMZ) din aceeasi zona, folosind acelasi server DNS 
>>>>(vrei ca o parte din zona sa nu fie vizibila din Internet sau ai adrese 
>>>>diferite pentru acelasi nume).
>>>
>>>
>>>Ai mai citit tu despre DNS dar nu suficient. Repeta lectia cu Split
>>>View. Cand ve sti ce inseamna o sa vezi si relevanta sfatului meu.
>>
>>Prefer o umilire in public din partea ta. Hai, explica-mi tu split view 
>>si cum ajuta el aici, te rog.
> 
> 
> "eventual DNSuri cu split view (daca vrei sa dirijezi accesul serverelor
> in functie de sursa)."
> 
> In primul rand, DNS split view sau split horizon sau dualhead sau cum
> vrei tu sa ii spui implementeaza notiunea de view-uri; pe scurt in
> functie de IP-ul de la care ii vine cererea da un raspuns. Cele mai dese
> exemple sunt cele cu clase interne, despre care probabil ai citit si tu.
> Sa luam un exemplu practic. 
> Gigel vrea sa ofere siteul gigel.ro vizitatorilor sai. 
> Din pacate Gigel are o conexiune buna in metropolitana dar o banda
> externa mica, motiv pentru care foloseste si un server extern, in US
> (unde banda e multa si ieftina).
> Gigel vrea ca vizitatorii din reteaua metropolitana sa acceseze serverul
> web din metropolitana iar cei "de pe Internet" sa acceseze serverul lui
> din US.
> Pentru a indeplini acesta sarcina Gigel, fiind baiat destept si studios
> intr-ale DNSului procedeaza in felul urmator:
> Instaleaza Bind cu split views si defineste zona gigel.ro.metro care
> face match clients pe retelele din Romania (multumim Alin Nastac) dar si
> zona gigel.ro.int care face match clients any. 
> In zona gigel.ro.metro gigel trece www IN A IP-Metro, iar in zona
> gigel.ro.int el trece www IN A IP-US.
> In functie de sursa cererilor DNS-ul dirijeaza clientii catre unul din
> webservere.

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.

Am inteles si cu "accesul serverelor", trebuia sa citesc "accesul 
la|spre servere". Totusi problema initiala era de availability si nu de 
load-balancing.

> 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.

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.

> 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.

>>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.

> /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

--- 
Detalii despre listele noastre de mail: http://www.lug.ro/


Raspunde prin e-mail lui