Backup

L'avventura continuava, e il tempo era sempre di meno. Ecco come proseguiva la creazione di un'infrastruttura di rete per una società di post-produzione cinematografica.

Avatar di Tom's Hardware

a cura di Tom's Hardware

Backup

A dir la verità, lo script che divide i backup in file da 4GB, copiati ogni ora sui server, venne creato da uno dei tecnici del montaggio video. Lo scopo principale dello script era ridurre le possibilità che un file venisse modificato durante l'esecuzione di un backup. Il difetto di questo sistema è che i backup non contengono necessariamente il materiale con le ultimissime modifiche.

I backup di file da 50 o 100GB non sono istantanei, per cui era probabile che un redattore accedesse al file modificandolo o utilizzandolo in altro modo proprio mentre il sistema ne stava creando una copia di sicurezza; ciò avrebbe bloccato tutti i 50 o 100GB impedendone la copia. Durante il backup quindi, lo script copiava localmente ogni file con un nome diverso, lo divideva in porzioni da 4GB, li inviava al server dei backup e sucessivamente rimuoveva la copia dal disco locale.

Al fallimento del primo tentativo di copia di un file, lo script ne aggiungeva il nome ad una lista che veniva rielaborata alla fine di ogni backup. Se anche il secondo trasferimento non fosse andato a buon fine, la copia del file sarebbe stata posticipata al backup successivo.

Con questa configurazione i tecnici editori catturavano, modificavano e facevano backup sulla rete mentre io aggiungevo il resto dei fileserver. Gli switch Dell PowerConnect 5324 gestivano il carico di lavoro molto bene, con una velocità media di trasferimento dati pari a 1.33GB al minuto.

Sul lato client del gruppo Media, c'erano dieci utenti con due workstation ognuno, per un totale di venti macchine. Ricorderete dalla Parte 1 di questo articolo, che scelsi di organizzare il gruppo Media con cinque client per switch, uno switch per NIC e quattro client NIC per server (col NIC integrato collegato allo switch del Controller di Dominio). Leggendo qualche commento lasciato alla fine dell'articolo, mi è sembrato che ci siano delle incomprensioni sul mio schema, ecco perchè vorrei spiegarlo meglio.

C'erano esattamente due fileserver multimediali (li chiamerò Media e Media Backup). Quello principale, Media, era il fulcro dei trasferimenti di file audio e video e allo stesso tempo la macchina dove si eseguivano le codifiche e le conversioni dei filmati. Ricordate anche che ogni utente di Media utilizzava due macchine. La prima, collegata al dispositivo di conversione e codifica dei filmati nei formati desiderati, rinominava e trasferiva automaticamente ogni file in una directory del fileserver Media. Una volta completata l'intera conversione e il salvataggio del nastro o della bobina, la directory veniva trasferita completamente al server Media Backup.

La seconda workstation Media veniva utilizzata per funzioni di montaggio video. Ciò includeva una serie di trasferimenti, della durata di otto ore, dal server Media principale verso le dieci stazioni di montaggio. I progetti salvati venivano successivamente ritrasferiti dalle dieci postazioni verso il server Media con un backup eseguito ogni ora e inviato al server Media Backup. Ogni trasferimento di dati sulle e dalle macchine di montaggio video muoveva 50GB.

Dieci postazioni dedicate al montaggio trasferivano ogni volta un minimo di 500GB alla velocità media per stazione, di 1,33GB al minuto. Ogni switch quindi, doveva riuscire a gestire circa 13.3GB al minuto, provenienti esclusivamente dalle postazioni del montaggio video; aggiungendo anche le produzioni delle workstation di conversione e codifica, possiamo tranquillamente raddoppiare la quantità di dati gestita ogni minuto dagli switch.

La Figura 3 mostra uno scenario ipotetico in cui si utilizza un solo NIC. Come potete vedere, le due workstation utilizzate dai client Media bombardano lo switch con quasi 26.6GB di dati al minuto. Ma con una sola connessione gigabit verso il fileserver, il throughput è strozzato fino a 1,33GB al minuto, la velocità effettiva di trasferimento dati di un scheda gigabit.

Quindi, mentre la rete principale, dal Firewall sino al Controller di Dominio/Server DHCP e ai client, funzionava efficentemente, gli addetti al montaggio video subivano enormi ritardi e rallentamenti dovuti all'impossibilità di gestire 26.6GB di dati al minuto con una sola scheda di rete.

Figura 3: Scenario ipotetico con 1 NIC

Nella Figura 4 è mostrato ciò che implementai nella realtà. Aggiungendo tre schede NIC, il throughput venne portato a circa 5.32GB al minuto (lasciate da parte qualche MB per il sovraccarico di lavoro della CPU e della memoria). Decisi di utilizzare la funzione di bilanciamento del carico della rete integrata in Windows per gestire le schede. Immagino avrei anche potuto costruire un Port Listener in Java per comandare instradamenti "Round Robin" a ogni NIC... ma a volte la vita è troppo breve.

Figura 4: Soluzione basata su 4 schede NIC

Per prevenire altri problemi col server Media principale installai quattro schede di rete anche sul server Media Backup, nonostante solo una scheda di rete (quella integrata) fosse collegata al server Media tramite lo switch Server. Bastò trasferire le connessioni sul server di backup. Se vi state chiedendo perchè non scelsi una scheda Ethernet 10GB, posso dirvi che sfortunatamente non me la potevo permettere, non era molto pratica e, ai tempi, nemmeno tanto diffusa.