Questo è il secondo articolo della serie dedicata alla costruzione di una rete di produzione multimediale. Per chi si fosse perso la prima parte, può leggerla a questo link: Il Tao della rete di produzione multimediale - Parte 1
Introduzione
Iniziavo ad abituarmi al nuovo ambiente di lavoro. In aggiunta ai ruvidi tappetini e ai divanetti arrivarono anche sei o sette amache; con il riscaldamento impostato alla massima temperatura sarebbe stato difficile non sentirsi come a casa, a Sacramento; di sicuro, quella non fu una delle classiche installazioni di reti a cui sono solito lavorare. La cosa che mi infastidì di più, però, fu il continuo pensiero che moltiplicando il numero di utenti per dieci e aggiungendoli tutti al sistema, l'intera rete avrebbe potuto collassare inesorabilmente e, come se non bastasse, il tempo a mia disposizione per terminare il progetto era già troppo poco il giorno della mia assunzione e ora me ne rimaneva sempre meno.
La figura 1 mostra lo schema della rete. Raggruppai tutti i file server, per poi inserirli in domini separati. Seguii anche la raccomandazione di aggiungere ogni server a ciascun file Hosts così che, nel caso in cui il Controller di Dominio/DHCP e relativo sistema di backup fossero caduti per qualche oscuro motivo, i client avrebbero comunque raggiunto i server.
Figura 1: Schema di base dell'infrastruttura di rete
Avendo a che fare con una rete abbastanza estesa, dove le cose che potevano andare male erano davvero tante, preferii tenermi le spalle ben coperte, progettando il più alto numero possibile di soluzioni di riserva. Ciò non sarebbe un grande problema se si dovessero gestire dieci o quindici macchine, ma in un progetto che prevede centinaia di nodi, un'accurata analisi di tutti i potenziali problemi e delle relative soluzioni può rivelarsi elemento chiave per accorciare il downtime della rete, mentre la si esamina e si studia una soluzione.
La parola chiave è sempre ridondanza. Esistono un paio di modi per configurare una rete come questa. Gli utenti potrebbero venir divisi in diversi gruppi, con accessi ai server individuali in base al gruppo di appartenenza (Vendite, Amministrazione, etc.). In quel caso scelsi di dividere gli utenti in domini (Windows), principalmente perchè era lo stesso sistema organizzativo della rete del loro quartier generale. Per risparmiare tempo importai le utenze già esistenti. L'organizzazione in domini si dimostrerà molto importante nella terza parte di questo articolo, quando parlerò della creazione di un tunnel VPN verso la rete del quartier generale.
La Figura 2 fornisce un'immagine più completa della rete. Notate che le linee singole che connettono i server agli switch rappresentano gruppi di connessioni individuali tra ciascun server e una porta dello switch. Ci sono quindi 7 porte in totale, da utilizzare per ogni switch. Se lo switch del primo server fosse stato sommerso dalla lava o distrutto dalla donna delle pulizie, portando con se ogni fileserver collegato, la rete sarebbe sopravvissuta in ogni caso.
Figura 2: Schema dettagliato della disposizione dei server sulla rete
Il primo motivo della sua sopravvivenza fu la precauzione che presi aggiungendo un file hosts con ogni server elencato su ciascuna macchina, per garantire una produttività senza interruzioni, anche nel caso in cui un Controller di Dominio fosse improvvisamente impazzito. I server di backup sarebbero comunque entrati in azione alla presenza del minimo problema sul rispettivo server principale, il tutto con una minima perdita di attività. Infine, lo schema generale era abbastanza dettagliato e appendendone una copia sul muro al centro della stanza server, anche gli utenti avrebbero potuto capire a quale server fare riferimento in caso di problemi.