This post is also available in: Inglese

Questo è il primo articolo di una serie realizzata per StarWind blog sul tema del design, pianificazione ed implementazione di un’infrastruttura per uno scenario ROBO. L’articolo originale (in inglese) è disponibile a questo link.

Lo scenario ROBO

Con l’acronimo ROBO (Remote Office / Branch Office) si identifica normalmente un ufficio remoto, in un altro sito (spesso geograficamente lontano) rispetto all’ufficio principale (o ad un altro ufficio). Molte aziende hanno diversi uffici remoti, in altre città ma anche in altri paesi o continenti. Possono essere semplici filiali o controllate o franchising o qualunque altra tipoligia… ma in molti di questi casi l’infrastruttura IT è governata e gestita dalla capogruppo o in qualche forma distribuita (ad esempio delegando ogni nazione ad avere un proprio IT).

Per varie ragioni che affronteremo in un post successivo, negli uffici remoti sono comunque necessari degli apparati IT e in molti casi anche dei veri e propri server (server di filiale), fisici o virtuali, per implementare dei servizi locali.

In termini di dimensione (ma anche in termini di workload), un ufficio remoto è in tutto e per tutto assimilabile ad una piccola realtà (una PMI), in molti casi si parla di uno o pochi server. Basta questo per catalogare questo scenario comunque un normale scenario Small and Medium Business (SMB)?

In realtà, se sommiamo tutti gli uffici remoti e le esigenze di business di queste realtà, ci troviamo quasi sempre di fronte ad un vero e proprio ambiente di tipo enterprise!

Con però delle sfide da risolvere diverse dai normali casi enterprise e specifici per il mondo ROBO:

• Il budget IT è inevitabilmente limitato, non che normalmente non lo sia, ma è chiaro che per una realtà con 20-30 filiali i numeri si fanno interessanti e la corretta progettazione di una filiala può far cambiare i costi in modo significativo (il numero di filiali agisce da fattore moltiplicativo).
• La mancanza di personale IT locale, tipico nella maggior parte delle filiali remote, che rappresenta una sfida nella gestione ordinaria e straordinaria dei servizi IT di filiale.
• La difficoltà nella gestione degli assett, dovuta spesso a diversità di configurazione (hardware e/o software) tra le diverse filiali, utilizzo di soluzioni diverse per ogni filiale, mancanza di un sistema di controllo delle modifiche, …
• La mancanca di soluzioni di business continuity (o la loro limitata applicazione/applicabilità) nelle filiali, a partire dalle soluzioni di data protection, fino ad arrivare alla mancanza vera a propria (quasi sempre) di un piano di disaster recovery.
• La limitazione degli spazio e delle infrastrutture necessarie alla parte IT, difficilmente si trovano vedere e proprie sale CED, ma spesso non si trovano neppure armadi attrezzati, sistemi di climatizzazione adeguati o carichi elettrici dimensionati correttamente. In alcuni casi (e più frequentemente di quanto ci si aspetti) i server di filiale si trovano in sottoscale, scantinati, o comunque locali non adeguati ad ospitare materiale tecnologico.

Obiettivi di business

Ovviamente parte degli obiettivi è quella di risolvere i possibili problemi visti in precedenza, con soluzioni che siano sostenibili (anche econimocamente).

Si possono quindi identificare alcuni requisiti fondamentali e abbastanza vincolanti:

• Gestione centralizzata: dato che nelle filiali manca personale IT (che non avrebbe neppure senso visto la dimensione tipica di una filiale, almeno dal punto di vista dell’infrastruttura IT), la gestione centralizzata di tutte le funzionalità, o almeno di una buona parte, permette una maggiore economia di scala, sfruttanto le risorse IT della sede centrale (nel caso si possa facilmente identificare) per la gestione di tutta l’infrastruttura. Chiaramente affinché la gestione si pro-attiva, è fondalmentale che vi sia anche un sistema di monitoraggio centralizzato.
• Scalabilità: sarà banale, ma al crescere delle filiali i numeri aumentano e quindi l’infrastruttura deve essere il più possibile scalabile (non necessariamente a livello di singola filiale, ma sicuramente a livello globale).
• Business Contuinuity: la soluzione deve prevedere un buon compromesso di business continuity soprattuto in termini di disponibilità, ma anche in termini di data e system protection.

Ma vi sono poi anche degli aspetti desiderati e desiderabili da considerare:

• Compliance: l’utilizzo di standard e l’identificazione di soluzioni il più possibili standard per tutte le filiali semplica poi processi come quelli relativi alla compliance o all’adeguamento di normative (o di criteri di sicurezza).
• Ripetibilità: la standarizzazione delle configurazioni delle filiali semplifica non sono la gestione, ma anche la messa in opera e riduce il rischio di variazioni e deviazioni di configurazione tra le varie filiali.
• Agilità: è un mantra che si sente spesso, ma è chiaro che piiù i numeri crescono, più gli strumenti di automazione possono semplificare i compiti dell’IT.
• Infrastruttura service-oriented: inutile girarci intorno… i servizi sono l’unico aspetto che veramente conta e quindi ogni soluzione deve essere focalizzata più sul servizio che sull’infrastruttura (ovviamente deve poter sostenere i servizi richiesti), e quindi maggiore attenzione ai livelli di servizi, alla gestione degli stessi, al livello di protezione, al monitoraggio dei servizi (più che dei sistemi), …

Vincoli

Come descritto in precedenza, uno dei maggiori vincoli (se non il maggiore nella maggior parte di questi casi) è il budget: una variazione anche solo di 1000€ per una filiale si moltiplica su tutte le filiali (soprattutto se si cerca di progettare tutte le filiali partendo da uno, o pochi, building block standard). Per contro bisogna mediare questo vincolo con tutti i requisiti visti in precedenza e trovare soprattutto il giusto equilibio per le soluzioni di disponibilità.

Ma non dobbiamo dimenticarci dei possibili vincoli a livello di infrastruttura fisica in ogni filiale. Quanto spazio è disponibile per ospitare l’infrastruttura IT? Esiste un armadio tecnologico o i server saranno semplicemente appoggiati su tavoli o scaffali? L’ambiente è climatizzato in modo adeguato? L’UPS (se esiste) può reggere il carico dell’infrastruttura e per quanto tempo? Molte domande alle quali bisogna dare una risposta per capire che tipo di vincoli si avranno.

La mancanza poi di personle IT locale, comporta poi dei vincoli sul come gestire l’infrastruttura (abbiamo visto che una gestione centralizzata potrebbe essere la risposta), ma anche di come gestire l’installazione ed eventuali attività di manutenzione hardware.

Rischi

Le limitate risorse IT portano poi a dei possibili rischi, spesso molto gravi od impattanti sulla progettazione di uno scenario ROBO. Ad esempio il carico elettrico può bastare per l’infrastruttura (o l’UPS può alimentare l’infrastruttura? L’eventuale armadio rack ha spazio o è profondo abbastanza per un server? Nel caso si stia rinnovando o aggiornando una filiale con sistemi nuovi, c’è spazio e carico elettrico sufficiente sia per l’infrastruttura vecchia che per quella nuova (almeno durante la migrazione)?

Ma non dimentichiamoci della rete sia quella locale che quella geografica. La rete locale è adeguarda? Che tipo di switch sono disponibili? Hanno porte a 1 Gbps (molto spesso nelle filiali si trovano ancora switch 100Mbs o persino hub). Il cablaggio è adeguato (per le reti a 1 Gbps serve almeno la categoria 5e)?

E la rete geografica è dimensionata in modo adeguato? Quanta banda c’è tra la filiale e la sede centrale (o quella che ospiterà tutta la parte di gestione/monitoraggio centralizzati)? Ma soprattutto quanta banda è realmente disponibile nei vari momenti di un giorno? Un’assunzione sbagliata a questo livello potrebbe compromettere completamente la gestione centralizzata!

La presenza poi un piano di business continuity non esime dal riverelo ed adattarlo alla nuova realtà, sia perché molti aspetti potrebbero non essere più applicabili, sia perché con la nuova infrastruttura vi potrebbere essere maggiori possibilità o opzioni.

La sicurezza poi può essere un altro grosso rischio: la limitata sicurezza fisica (ad esempio l’impossibilità di limitare l’accesso al locale tecnologico) rende molto più complicato gestire le problematiche di sicurezza.

Requisiti tecnologici

Nel prossimo post analizzeremo i requisiti e le possibili soluzioni dal punto di vista tecnologico cercando di considerare gli aspetti di:

• disponibilità (availability)
• gestibilità (manageability)
• prestazioni e scalabilità (performance)
• data e system protection (recoverability)
• sicurezza (security)
• risk management

Andrea Mauro

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-24. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-23. Nutanix NTC 2014-20. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.