Newsgroup: it.comp.reti.ip-admin
Titolo: le tecniche di akamai....

Salve,
    sento molta pubblicita a propostio della tecnologia di Akamai
(
http://www.akamai.com/
)  pe rla gestione
di siti di livello enterprise (yahoo,lycos, msnbc,ebay etc etc).
A leggere sul sito loro hanno un loro network, ma quello che mi
interessava capire è al gestione del "server near you"...
Io avrei due sedi con due provider diversi et etc , vorrei fare qualcosa
simile,minimalista e piccolo piccolo, giusto per diletto usando linux e
apache.
Ho letto a propostio di alcune regole di rewriting, ma vorrei capire
come fare in modo che l'utente pincopalla vada sul server con meno hops
in mezzo...
Grazie

in mezzo...
Non c'e` un modo semplice per farlo (e nemmeno per akamai e` cosi`
facile...).
-- 
ciao, | Does a route flap if nobody is listening to it?
Marco | (Ri)scoprire fidonet: 
http://bbs.bofh.it

 wrote:
Prova a dare un'occhiata a mod_backend
-- 
Ciao, Maurizio.


Bene, siginifica ch epe rcomplicato ch esia comunque è possibile farlo.
Hai, alle volte, dei documenti, non dico how-to, ma qualcosa da leggere dove
mettere insieme pezzi per arrviare a qualcosa di simile??
non ho la pretesa di fare qualcosa che costa milioni di dollari, ma saperne
di piu sarebbe utile...
grazie

 Prova a dare un'occhiata a mod_backend
Lo vorrei tanto, peccato che sul sito di apache non se ne fa menzione,
ne su freshmeat, ne su yahoo....
Nei sorgenti non c'è neppure....
ciao

 writes:
    michele> Maurizio Cimaschi wrote:
    >> Prova a dare un'occhiata a mod_backend
    michele> Lo vorrei tanto, peccato che sul sito di apache non se ne
    michele> fa menzione, ne su freshmeat, ne su yahoo....  Nei
    michele> sorgenti non c'è neppure....
Perche' e' mod_backhand.
Ciao,
Andrea

mettere insieme pezzi per arrviare a qualcosa di simile??
Inizia a imparare bene bene BGP, poi ne riparliamo.
(Hint: se la gente potesse farselo in casa Akamai non ne venderebbe
cosi` tanto.)


Prova a dare un'occhiata a mod_backend
Non c'entra niente.
(E chi lo ha scritto non ha le idee chiare su come funziona un grande
sito web, visto che un coso simile aumenta enormemente la latenza.)


 cosi` tanto.)
questa non la capisco: anche i firewall o i web server con linux te li puoi fare
in casa, ma ms,cisco,etc etc continuano a vendere i loro prodotti.
Non penso che le due cose si escludano, penso solo che si deve avere la
conoscenza, quella si, quella davvero serve.

 interessava capire č al gestione del "server near you"...


 > interessava capire è al gestione del "server near you"...


Bravo, ma sarà veramente cosi??
se fosse cosi , allora, basterebbe ( :) ) un dns di un certo tipo, ma è davvero
cosi???

 ha scritto nel
messaggio news:3A658D2A...@lastminutetour.com...

Massì, dài... Mi sa che è così.
La cosa richiede, tuttavia, che i tuoi providers accettino che tu gestisca
il contenuto del name server relativo alla tua zone. Devono pubblicare
quello che dice il tuo DNS server: non quello che vogliono loro. La cosa non
è sempre possibile, in funzione del tipo di contratto che hai con il
provider.
Inoltre, non è banalissimo 'calcolare' la migliore destinazione in funzione
di chi emette la richiesta: devi farti un database così!
Per farti il database ci sono molti metodi. Potresti ottenere (da RIPE o da
NIC o vacchiappa da chi) il database dei set di indirizzi assegnati per area
geografica, ma poi devi anche tenerlo aggiornato...
Oppure potresti utilizzare un metodo adattivo: tutte le volte che ricevi una
richiesta DNS da un IP relativo ad un bunch di indirizzi sconosciuto al tuo
database, potresti effettuare un traceroute sulla destinazione fino a
trovare un router nel percorso che sia a te noto. A quel punto, ottieni una
stima dell'area geografica nella quale potrebbe risiedere il nodo.
Eventualmente, potresti addirittura inviare una segnalazione ai tuoi server
sparsi per il mondo, per fare sì che effettuino un 'traceroute' al mittente
della richiesta per scoprire quale dei server gli è più vicino.
Infine, potresti anche utilizzare un approccio promiscuo, in cui parti da un
database 'fatto' che aggiorni ogniqualvolta trovi nodi di origine ignota.
Vabbé, su quest'argomento ci sarebbe molto da parlare.
Perché non provi a sentire che ti dicono quelli del Bind8 (il DNS) di Linux?
Magari ci fanno su un pensierino e tra un po' ci troviamo il DNS con
'source-dependent zones'.
Saluti,
PS: Allora, formaggio tipico, Lardo di Colonnata o Caviale?
      Niente servito di piatti per sei, taccagno!


'source-dependent zones'.
Ti risponderebbero di attaccarti e tirare forte, che non e` compito di
BIND fare cose simili.
(Ma cosa credi, che siano tutti scemi e nessuno ci abbia mai pensato?
Magari prova a guardare nel manuale di BIND l'opzione sortlist.)


 Magari prova a guardare nel manuale di BIND l'opzione sortlist.)
A) Non credo affatto che siamo tutti scemi. Credo che tu non ci avevi
pensato.
     Avevi suggerito una soluzione basata su BGP. Anzi, non avevi suggerito
niente:
     ti eri limitato a fare l'espertone centellinatore di conoscenza:
"inizia a imparare
     bene il BGP, poi ne riparliamo...". Scusi dotto' se l'abbiamo
disturbata.
B) Ahahah! La sortlist viene utilizzata in /etc/resolv.conf per stabilisce
     l'ordine con cui si vuole che la libreria di bind (cioé, la parte
client del
     sistema di risoluzione dei nomi) restituisca gli indirizzi. Mi sa
proprio che hai
     pisciato fuori, stavolta...
[LEAVING AGGRESSIVE MODE LEVEL 1]
Saluti,


B) Ahahah! La sortlist viene utilizzata in /etc/resolv.conf per stabilisce
No, leggi /usr/share/doc/bind/html/options.html#sortlist e poi per
favore continua a rosicare in silenzio.


 l'utente, ma in effetti potrei non sapere cosa e` un hook.
Ciao,
    lo si può scaricare??? giusto per fare delle prove...
Comunque anche se del tutto lontana dalla realta di akamai, il modulo
mod_backhand si potrebbe usarlo per
il mio caso specifico: un macchina dual homed, collegata a FW e unisource, la
quale mi sembra vada meglio come
collegamento nazionale(non fosse altro che ha davero meno latenza per
raggiungere interbussiness).
ciao

    lo si può scaricare??? giusto per fare delle prove...
Tra un po', segui ifm-d.


 e poi per favore continua a rosicare in silenzio.
??? Sento puzza. L'hai fatta?


OK, OK.
Ci avete convinti.
Siete entrambi ferratissimi.
Quello che non va è che vi sparate addosso l'un l'altro.
Usate le vostre conoscenze come armi.
Perchè invece non provate a metterle assieme?
Ne verrebbe fuori un trattato sicuramente molto serio ed utile a VOI e al
prossimo.
E ...
... ne guadagnereste in salute.
Ciao

 >
Su un 3ead precedente indicavo una implementazione, ma mi hanno
cagato a spruzzo tutti :-) Si vede che l'ho scritto con i piedi.
Comunque la soluzione appropriata (bgp-path based) e'
parziale e sfortunatamente anche l'unica. Il problema e'
che il path piu' corto non corrisponde necessariamente al
path piu' efficiente (salvo tuning bgp con i controk).
Ma meglio che niente del tutto. E inoltre occorre avere una scelta
MOLTO oculata di upstream...
Sent via Deja.com
http://www.deja.com/

 MOLTO oculata di upstream...
Caro Franscesco,
non sono riuscito a trovare il thread di cui parli, quindi volevo chiederti
ulteriori informazioni.
La tecnica a cui ti riferisci serve anche ad instradare il traffico al nodo
topologicamente più vicino, o solo ad individuare il percorso più breve?
Mi spiego meglio: un sito implementato secondo questa tecnica dispone di più
nodi con lo stesso indirizzo e, quindi, è il routing bgp-based ad instradare
le richieste al nodo più vicino, od i vari nodi dispongono di indirizzi IP
diversi e le informazioni di routing vengono utilizzate al solo fine di
stabilire quello 'più vicino' al client?
Se si tratta della 1 (= instrada il traffico), allora sospetto che non sia
né l'unica, né, forse, la più efficiente (anche se dovremmo prima definire
questo termine).
A quanto ho capito, il sito della Akamai (
www.akamai.com
) mi pare funzionare
come ho già illustrato in questo thread, cioé tramite l'uso di un
authoritative DNS server opportunamente archibugiato. Quindi, eventualmente,
viene utilizzata la 2 (= bgp per sola rilevazione nodo più breve) per
'trovare' l'indirizzo IP che deve essere indicato dal DNS server.
La 1 non mi pare affidabile dato che la semplice inserzione o sconnessione
di una nuova tratta di rete potrebbe modificare la topologia della rete,
così che, ad esempio, i pacchetti relativi ad una connessione già instaurata
vengano dirottati su qualche altro nodo (con lo stesso IP address).
Ovviamente, dato che il nodo che è subentrato al primo non ha traccia dello
stato della connessione, non può che provocare un reset della connessione
stessa... Il problema di questa soluzione è nel fatto che il routing viene
effettuato sui contenuti del livello IP.
Probabilmente non mi sono affatto spiegato. Se lo ritieni opportuno tornerò
sull'argomento.
Ciao,


 Ciao
Ciao,


 stabilire quello 'più vicino' al client?
La seconda, chiaramente. La complicazione e' legata al fatto che devo
sempre avere un aggiornamento bgp 'locale' rispetto a ciascun nodo
candidato. Questo perche' l'AS potrebbe essere confederato e quindi
adottare policy non omogenee: cio' comporta  N possibili
tabelle BGP (1 per confederazione) tra cui scegliere quella con as-path
piu' corto fino al AS destinaizione. Secondo me se il sistema non
e' confederato tutta la faccenda ha poca e scarsa utilita' se uso
sempre un unico AS.  A meno che non restituisca  l'ip secondo anche
altre politiche di bilanciamento ovviamente (carico di CPU, traffico).
In tal caso l'as-path rimane sempre lo stesso e vado in realta' a
bilanciare altre cose. Se sono in grado di mappare IP di altri
AS dovro' avere un peer in ciascuno di essi invece per sapere
che mapping usare e ricadiamo nel discorso precedente.
Insomma il bilanciamento per as-path ha senso in caso di AS multipli
oppure confederati, non in caso di singolo AS (full-connected
o mirrorato). Mi saro' spiegato? Mah...

Nella soluzione shortest-path ci vedo un problema legato al fatto
che non necessariamente l'as-path minimo e' quello migliore per
quello che riguarda la connettivita'. Ma questo penso che sia
un limite ovvio...



wrote:

Stavo notando che la metrica DRP di Cisco sui Director consente
di aggiungere un costo amministrativo oltre a quello legato
all'as-path. Mi sa comunque che fare un tuning della faccenda
deve essere un qualcosa da mal di testa. Comunque mi chiedo
in cosa si differenzia la soluzione di Akamai da Director...
A parte il fatto magari che un sistema general purpose
puo' essere impiegato magari per scelte piu' intelligenti...
