| A/I Orange Book (1.0): Un how-to sulla replicazione e distribuzione di una rete resistente di server autogestiti | ||
|---|---|---|
| Indietro | Capitolo 2. Rete | Avanti |
Per il funzionamento di uno schema come quello che stiamo qui descrivendo, una delle parti più essenziali è proprio il servizio DNS.
Nell'organizzazione del DNS è evidente la separazione tra il livello di gestione e i servizi destinati agli utenti: la struttura di rete sopra descritta richiede una nomenclatura efficace degli indirizzi assegnati alle varie interfacce, in modo che sia sempre chiaro a quale connessione si fa riferimento. D'altra parte, dal punto di vista degli utenti è invece auspicabile avere meno specificità possibile, per mantenere l'impressione di aver a che fare con un'unica "organizzazione virtuale" (vale a dire che tutta l'infrastruttura si colloca sotto la soglia della percezione dell'utente che si collega a www.dominio.org e non vuole davvero sapere a quale macchina specifica si stia collegando, o se la sua posta si trova in Brasile o in Malesia).
La scelta per la parte infrastrutturale è stata di usare un dominio apposito (nel nostro caso infra.org), su cui appoggiare la risoluzione degli IP delle varie macchine e di altri servizi che eventualmente non dovessero essere pubblici. Dato che su questo dominio non vengono offerti servizi agli utenti, non è neanche necessario che tale dominio sia pubblico (o meglio, pubblicamente conosciuto). Questa separazione ovviamente non è assolutamente necessaria, ma può aiutare a mantenere chiarezza nell'organizzazione dei servizi.
Questa più o meno è la struttura dei record DNS di questa zona:
infra.org NS ns1.infra.org
ns2.infra.org
ns3.infra.org
ns1.infra.org A 1.2.3.4
ns2.infra.org A 2.3.4.5
ns3.infra.org A 3.4.5.6
mx1.infra.org A 1.2.3.4
mx2.infra.org A 2.3.4.5
mx3.infra.org A 3.4.5.6
server1.infra.org A 1.2.3.4
server2.infra.org A 2.3.4.5
server3.infra.org A 3.4.5.6
server1-vpn.infra.org A 172.16.1.1
server2-vpn.infra.org A 172.16.1.2
server3-vpn.infra.org A 172.16.1.3
È abbastanza facile aggiungere a questa zona degli alias per alcuni servizi o ruoli particolari, per esempio:
ldap-master.infra.org CNAME server1
La struttura del DNS dei domini "normali" invece è standardizzata (tutte le zone cioè sono fatte nello stesso modo), ed essenzialmente implementa tutti i meccanismi di round-robin con cui il carico viene approssivatimanente distribuito tra i vari server.
La parte comune a tutti i domini è fatta in questo modo:
public.org NS ns1.infra.org
NS ns2.infra.org
NS ns3.infra.org
public.org MX 10 mx1.infra.org
MX 10 mx2.infra.org
MX 10 mx3.infra.org
www.public.org A 1.2.3.4
A 2.3.4.5
A 3.4.5.6
Che significa, brevemente, che la posta viene indirizzata con eguale
probabilità ad uno qualsiasi dei server di posta, e le
richieste web vengono mandate in modo ugualmente casuale ai vari
server web.
Gli unici domini che si differenziano dagli altri in questo senso sono quelli per cui è necessario identificare singolarmente ciascuna macchina. Questa situazione la si riscontra sia nel caso dei sottositi (www.dominio.org/qualcosa), che sono assegnati ad una macchina specifica per via della difficoltà / infattibilità della replicazione MySQL multi-master, sia nel caso di alcuni servizi forniti tramite https (la webmail, ad esempio). Per questo motivo i record A del dominio dominio.org sono fatti così:
www.dominio.org A 1.2.3.4
A 2.3.4.5
A 3.4.5.6
www1.dominio.org A 1.2.3.4
www2.dominio.org A 2.3.4.5
www3.dominio.org A 3.4.5.6
Un'ultima cosa da dire riguardo all'organizzazione del DNS (cosa che verrà approfondita nel capitolo dedicato ad Apache) è che è stato deciso di accentrare tutti i servizi web forniti su SSL su di un unico dominio (in questo caso www.dominio.org), per mantenere la coerenza con il nome indicato sul certificato SSL (che comunque è unico, per ciascun server).