cu scuzele de rigoare, grigore avea dreptate. sper sa NU primesc reply la mail-ul asta de la manac dragos. deci:
> "Daca pui ttl mic o sa ai avantajul ca nu se cacheaza raspunsul la > cererile de DNS, in cazul in care unul din serverele web e mort existand > sansa de a se servi IP-ul celuilalt server web." 1. "sansa" != rezolvare definitiva > Am spus TTL mic deoarece e un tradeoff intre cereri si incarcare, > depinde de setupul tau. Poti pune zero si atunci nu se face caching. 2. tuning in functie de dracu stie ce. poate azi merge bine si maine nu mai e bun ttl-ul. = empirism > 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. asta nu inseamna "redundanta". e o banala distribuire a incarcarii. fyi: "redundanta" vine din frantuzescul "redondance" care inseamna altceva > In functie de sursa cererilor DNS-ul dirijeaza clientii catre unul din > webservere. noua definitie a "redundantei" > Asa cum am explicat mai sus. Combina trickul de mai sus cu TTL zero si > poti face o distribuire interesanta pe N webservere. rezolvarea unei alte probleme practice. intr-adevar reala, dar nu la asta se cerea rezolvare. > 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. alta problema... > Nu paria lucruri valoroase pe asta. eu votez cu grig. el a castigat pariul. manac doar pe cel cu agricultura, la fel ca prietenul nostru, fiul revolutionarului din spania, valter roman > Afair am un oarecare avantaj de experienta teoretica si practica, sper > sa ma ajute. > > /me asteptand o noua slashdotare saptamana asta (setupul e gata, testat > si functional de la ultima:) blabla fiindca vad ca sunt si altii care au "experiente teoretice", revin cu ce am spus intr-un mail de ieri ce a generat rabufniri d'ale elitelor autohtone. problema reala este de a pastra content-ul identic. daca e vorba DOAR de un server ce duce pagini statice, trebuie sa va ganditi la: - sincronizare de fisiere (cu ce stiti voi mai bine ca se face) - sistem de fisiere distribuit (ce asigura si redundanta) - alte solutii (cum ar fi aceea de a utiliza echipamente in share) dar cum un server web este de obicei pe levelul 1, existand paradigme chiar 3-thier (i.e. jsp), incercati sa vedeti cum implementati celelalte level-uri (de exemplu baze de date). poate sincronizarea; sau poate o masina virtuala distribuita; sau altceva. oricum, e de remarcat ca s-a tot speculat pe ideea cu dns-ul si asta e bine. presupunand ca: - se doreste cu adevarat redundanta - se dispune de fonduri - exista cel putin 2 legaturi la internet in cel putin doua locatii A si B legate pe un tronson de mare viteza (de exemplu fibra) - exista posibilitatea de a implementa solutia pe care v-am spus-o initial, eventual usor modificata (sa bagam in schema si treaba cu dns-urile, ca oricum e suficient de excitant, dupa cum vad din ttl-uri, view-uri etc) solutia ar fi: - in locatia A se monteaza ruter, dns si o parte din clusterul de care aminteam - in locatia B se monteaza ruter, dns si o parte din clusterul de care aminteam - daca sunt si alte locatii, asijderea - va jucati cu rutele - va jucati cu dns-ul - va configurati cum siti acest "ansamblu" asta e, aveti o solutie redundanta, care e insensibila la: - cutremure - pene de curent - probleme cu providerul - etc oricum, trebuie sa ne bagam cu totii in cap ca: - apelarea la un provider de hosting nu rezolva problema: sunt cazuri cand si serverele hostate in noc-uri ale firmelor de prestigiu au fost neoperationale - rezolvarea reala (cat mai aproape de redundanta) costa bani tibi cluj --- Detalii despre listele noastre de mail: http://www.lug.ro/
