Archivi categoria: Cloud & Datacenter Management

Cloud Security Posture Management (CSPM) di Defender for Cloud: proteggi le tue risorse con una soluzione di sicurezza avanzata

Nel contesto del panorama digitale odierno, l’adozione del cloud computing ha aperto nuove opportunità per le organizzazioni, ma allo stesso tempo sono emerse nuove sfide in termini di sicurezza delle risorse cloud. L’adozione di una soluzione di Cloud Security Posture Management (CSPM) è fondamentale per garantire che le risorse cloud siano configurate in modo sicuro e che gli standard di sicurezza siano adeguatamente implementati. Microsoft Azure offre Defender for Cloud, una soluzione completa che combina la potenza di una piattaforma di CSPM con funzionalità avanzate di sicurezza per aiutare le organizzazioni a proteggere le loro risorse cloud in modo efficace. In questo articolo vengono approfondite le caratteristiche di CSPM offerte da Defender for Cloud.

I pilastri della sicurezza contemplati da Microsoft Defender for Cloud

Le funzionalità di Microsoft Defender for Cloud sono in grado di contemplare tre grandi pilastri della sicurezza per le architetture moderne che adottano componenti cloud:

DevOps Security Management (DevSecOps): Defender for Cloud aiuta a incorporare già durante il processo di sviluppo del software le best practice di sicurezza. Infatti, consente di proteggere gli ambienti di gestione del codice (GitHub e Azure DevOps), le pipeline di sviluppo e permette di ottenere informazioni sulla security posture dell’ambiente di sviluppo. Defender for Cloud include attualmente Defender for DevOps.
Cloud Security Posture Management (CSPM): si tratta di insieme di pratiche, processi e strumenti volti a identificare, monitorare e mitigare i rischi di sicurezza nelle risorse cloud. CSPM offre un’ampia visibilità sulla security posture delle risorse, consentendo alle organizzazioni di identificare e correggere le configurazioni non conformi, le vulnerabilità e le potenziali minacce. Questo approccio proattivo riduce il rischio di violazioni della sicurezza e aiuta a mantenere un ambiente cloud sicuro.
Cloud Workload Protection Platform (CWPP): i principi di sicurezza proattiva richiedono l’implementazione di pratiche di sicurezza che proteggano i workload dalle minacce. Defender for Cloud include una ampia gamma di protezioni avanzate ed intelligenti per i workload, fornite tramite piani di Microsoft Defender specifici per le differenti tipologie di risorse presenti nelle subscription Azure ed in ambienti ibridi e multi-cloud.

Figura 1 – I pilastri della sicurezza contemplati da Microsoft Defender for Cloud

CSPM in Defender for Cloud

Defender for Cloud è la soluzione di sicurezza avanzata di Microsoft Azure che contempla l’ambito CSPM per offrire un’ampia gamma di funzionalità e controlli di sicurezza per le risorse cloud. Con Defender for Cloud, le organizzazioni possono ottenere una visibilità completa delle loro risorse, identificare e risolvere le vulnerabilità e monitorare costantemente la security posture delle risorse. Alcune delle funzionalità principali offerte da Defender for Cloud includono:

Analisi delle configurazioni: Defender for Cloud esamina le configurazioni delle risorse cloud alla ricerca di impostazioni non conformi e fornisce raccomandazioni per correggerle. Ciò garantisce che le risorse siano configurate in modo sicuro e che gli standard di sicurezza siano rispettati.
Identificazione delle vulnerabilità: la soluzione analizza continuamente le risorse cloud per individuare le vulnerabilità note. Vengono fornite raccomandazioni e priorità per affrontare queste vulnerabilità e ridurre il rischio di sfruttamento da parte di potenziali minacce.
Monitoraggio continuo: Defender for Cloud monitora costantemente la postura di sicurezza delle risorse cloud e fornisce avvisi in tempo reale in caso di configurazioni non sicure o attività sospette. Questo consente alle organizzazioni di rispondere prontamente alle minacce e di mantenere un ambiente cloud protetto.
Automazione e orchestrazione: Defender for Cloud automatizza gran parte del processo di gestione della postura di sicurezza degli ambienti cloud, consentendo alle organizzazioni di risparmiare tempo e risorse preziose.

Defender for Cloud offre gratuitamente le funzionalità fondamentali in ambito CSPM. Queste funzionalità sono automaticamente abilitate su qualsiasi subscription o account che abbia effettuato l’onboarding a Defender for Cloud. Qualora lo si ritenga necessario è possibile ampliare il set di funzionalità attivando il piano Defender CSPM.

Figura 2 – Comparativa tra i piani in ambito CSPM

Per una comparativa completa è possibile fare riferimento alla documentazione ufficiale Microsoft.

Il piano Defender CSPM opzionale offre funzionalità avanzate di gestione della security posture, tra le principali troviamo:

Security Governance: i team di security sono responsabili del miglioramento della postura di sicurezza delle loro organizzazioni, ma potrebbero non avere le risorse oppure l’autorità per implementare effettivamente le raccomandazioni di sicurezza. L’assegnazione di responsabili con date di scadenza e la definizione di regole di governance creano responsabilità e trasparenza, in modo da poter guidare il processo di miglioramento della sicurezza dell’organizzazione.
Regulatory compliance: grazie a questa funzionalità Microsoft Defender for Cloud semplifica il processo per soddisfare i requisiti di conformità normativa, fornendo una dashboard specifica. Defender for Cloud valuta continuamente l’ambiente per analizzare i fattori di rischio in base ai controlli e alle best practice degli standard applicati alle sottoscrizioni. La dashboard riflette lo stato di conformità a questi standard. Il Microsoft cloud security benchmark (MCSB) viene invece assegnato automaticamente alle sottoscrizioni e agli account quando si accede a Defender for Cloud (foundational CSPM). Questo benchmark si basa sui principi di sicurezza del cloud definiti dall’Azure Security Benchmark e li applica con una guida dettagliata all’implementazione tecnica per Azure, per altri fornitori di cloud (come AWS e GCP) e per altri cloud Microsoft.
Cloud Security Explorer: consente di identificare in modo proattivo i rischi per la sicurezza nell’ambiente cloud eseguendo graficamente query sul Cloud Security Graph, che è il motore di definizione del contesto di Defender for Cloud. Alle richieste del team di sicurezza è possibile dare priorità, tenendo conto del contesto e delle specifiche norme dell’organizzazione. Con il Cloud Security Explorer è possibile interrogare i problemi di sicurezza ed il contesto dell’ambiente, come l’inventario delle risorse, l’esposizione a Internet, le autorizzazioni e il “lateral movement” tra le risorse e tra più cloud (Azure e AWS).
Attack path analysis: l’analisi dei percorsi di attacco aiuta ad affrontare i problemi di sicurezza, relative all’ambiente specifico, che rappresentano minacce immediate con il maggior potenziale di sfruttamento. Defender for Cloud analizza quali problemi di sicurezza fanno parte di potenziali percorsi di attacco che gli aggressori potrebbero utilizzare per violare l’ambiente specifico. Inoltre, evidenzia le raccomandazioni di sicurezza che devono essere risolte per mitigarle.
Agentless scanning for machines: Microsoft Defender for Cloud massimizza la copertura dei problemi di postura del sistema operativo e va oltre alla copertura data dagli assessment basati su agenti specifici. Grazie alla scansione agentless per le macchine virtuali è possibile ottenere una visibilità immediata, ampia e senza ostacoli in merito ai potenziali problemi di postura. Il tutto senza dover installare agenti, rispettare requisiti di connettività di rete oppure impattare sulle prestazioni delle macchine. La scansione agentless per le macchine virtuali fornisce la valutazione delle vulnerabilità e l’inventario del software, entrambi tramite Microsoft Defender Vulnerability Management, in ambienti Azure e Amazon AWS. La scansione agentless è disponibile sia in Defender Cloud Security Posture Management (CSPM) sia in Defender for Servers P2.

Conclusioni

Nel contesto sempre più complesso della sicurezza delle risorse IT, soprattutto in presenza di ambienti ibridi e multi-cloud, il Cloud Security Posture Management (CSPM) è diventato una componente essenziale della strategia di sicurezza delle organizzazioni. Defender for Cloud di Microsoft Azure offre una soluzione avanzata di CSPM, che combina analisi delle configurazioni, identificazione delle vulnerabilità, monitoraggio continuo e automazione per garantire che le risorse IT siano protette in modo adeguato. Investire in una soluzione di CSPM come Defender for Cloud consente alle organizzazioni di mitigare i rischi di sicurezza e proteggere le risorse IT.

Come la fine del supporto di Windows Server 2012 può essere una grande opportunità per i CTO

La fine del supporto dei sistemi operativi Windows Server 2012 e 2012 R2 sta avvicinandosi rapidamente e, per i Chief Technology Officer (CTO) delle aziende, questo aspetto deve essere attentamente valutato in quanto ha degli impatti significativi sull’infrastruttura IT. Allo stesso tempo, la fine del supporto può rappresentare un’occasione importante per modernizzare l’ambiente IT al fine di garantire una maggiore sicurezza, nuove funzionalità e un miglioramento della continuità del business. In questo articolo vengono riportate le strategie che è possibile adottare per affrontare questa situazione, evitando così di esporre la propria infrastruttura IT a problematiche di security causate da questa situazione.

Quando termina il supporto di Windows Server 2012/2012R2 e cosa comporta?

Il 10 ottobre 2023 segna la fine del supporto esteso di Windows Server 2012 e Windows Server 2012 R2. Senza il supporto di Microsoft, Windows Server 2012 e Windows Server 2012 R2 non riceveranno più patch di sicurezza, a meno che non vengano svolte determinate azioni riportate in seguito. Ciò significa che eventuali vulnerabilità scoperte nel sistema operativo non saranno più corrette e questo potrebbe rendere i sistemi vulnerabili ad attacchi informatici. Inoltre, questa condizione comporterebbe lo stato di non conformità rispetto a specifici regolamenti, come ad esempio il General Data Protection Regulation (GDPR).

Inoltre, gli utenti non riceveranno più correzioni di bug e altri aggiornamenti necessari per mantenere il sistema operativo in linea con le ultime tecnologie, il che potrebbe comportare problemi di compatibilità con i software più recenti e introdurre potenziali problemi di prestazioni.

Oltre a tutto ciò, Microsoft non garantirà più un supporto tecnico e un aggiornamento dei contenuti tecnici disponibili online per questo sistema operativo.

Tutti questi aspetti comportano un impatto significativo sulle realtà IT che utilizzano ancora questi sistemi operativi.

Possibili strategie e opportunità legate alla fine del supporto

Questa situazione è certamente poco piacevole per chi si ritrova ad affrontarla ora, visti i tempi ristretti, ma può anche essere vista come una importante opportunità di rinnovo e innovazione della propria infrastruttura. Nei paragrafi seguenti vengono riportate le possibili strategie che si possono attuare.

Aggiornamento dei sistemi on-premises

Questa strategia prevede il passaggio a una nuova versione di Windows Server in ambiente on-premises. Il consiglio in questo caso è di approcciare come piattaforma almeno Windows Server 2019, ma è preferibile adottare la versione più recente, Windows Server 2022, che può fornire le ultime innovazioni in materia di sicurezza, prestazioni e modernizzazione delle applicazioni.

Inoltre, laddove tecnicamente possibile è preferibile non procedere con aggiornamenti in place del sistema operativo, ma di gestire la migrazione in side-by-side.

Questo metodo solitamente richiede un coinvolgimento del fornitore applicativo, per garantire la compatibilità software con la nuova versione del sistema operativo. Trattandosi di software non recenti, spesso viene richiesta l’adozione di versioni aggiornate degli stessi, che possono prevedere un adeguamento dell’architettura e una fase approfondita di test della nuova release. Adottando questo processo di upgrade i tempi e l’effort sono considerevoli, ma il risultato che si ottiene è fondamentale per rispettare il rinnovo tecnologico.

Mantenimento dei sistemi Windows Server 2012/2012 R2, ma con aggiornamenti di security per altri 3 anni

Per continuare a ricevere gli update di security per i sistemi Windows Server 2012\2012 R2 ospitati in ambiente on-premises, una possibilità è quella di aderire al programma Extended Security Update (ESU). Tale programma a pagamento garantisce il provisioning degli Update di Security classificati come “critical” e “important” per ulteriori tre anni, nel caso specifico fino al 13 ottobre 2026.

Il programma Extended Security Update (ESU) è un’opzione per i clienti che hanno bisogno di eseguire alcuni prodotti Microsoft legacy oltre la fine del supporto e che non sono nelle condizioni di intraprendere altre strategie. Gli aggiornamenti inclusi nel programma ESU non includono nuove funzionalità e aggiornamenti non legati agli aspetti di sicurezza.

Adozione di Azure

Migrazione dei sistemi in Azure

Migrando i sistemi Windows Server 2012 e Windows Server 2012 R2 presenti on-premises in ambiente Azure si continueranno a ricevere per altri tre anni i security update, classificati come critici e importanti, senza dover aderire al programma ESU. Questo scenario non solo è utile per garantire il rispetto della compliance dei propri sistemi, ma apre la strada verso architetture ibride dove sarà possibile ottenere i vantaggi dati dal cloud. A questo proposito Microsoft offre un’ottima soluzione in grado di fornire un ampio set di strumenti necessari per affrontare al meglio i più comuni scenari di migrazione: Azure Migrate, che struttura il processo di migrazioni in fase differenti (discovery, assessment, e migrazione).

Anche Azure Arc può risultare molto utile per inventariare il patrimonio digitale in ambienti eterogenei e distribuiti.

L’adozione di questa strategia può risultare più veloce rispetto all’aggiornamento dei sistemi e consente di avere più tempo a disposizione per affrontare il rinnovo software. A questo proposito il cloud consente di avere un’ottima flessibilità e agilità nel testare gli applicativi in ambienti paralleli.

Prima di iniziare il percorso di migrazione verso Azure è fondamentale anche strutturare il networking dell’ambiente ibrido in modo opportuno e valutare le iterazioni con gli altri componenti dell’infrastruttura, per constatare se l’applicativo può funzionare bene anche in ambiente cloud.

La migrazione in Azure può avvenire verso macchine virtuali IaaS oppure, in presenza di un numero elevato di sistemi da migrare in ambiente VMware, Azure VMware Solution può essere una soluzione da tenere in considerazione per affrontare una migrazione massiva in tempi rapidi e riducendo al minimo l’interruzione dei servizi erogati.

Estensione di Azure nel proprio datacenter con Azure Stack HCI

Azure Stack HCI è la soluzione Microsoft che permette di realizzare una infrastruttura hyper-converged (HCI) per l’esecuzione di workload in ambiente on-premises e che prevede una strategica connessione a vari servizi di Azure. Azure Stack HCI è stato appositamente progettato da Microsoft per aiutare i clienti a modernizzare il proprio datacenter ibrido, offrendo un’esperienza Azure completa e familiare in ambiente on-premises. Per un approfondimento sulla soluzione Microsoft Azure Stack HCI vi invito a leggere questo articolo oppure a visualizzare questo video.

Azure Stack HCI consente di ottenere gratuitamente, proprio come in Azure, importanti patch di sicurezza per i prodotti legacy di Microsoft che hanno superato il termine del supporto, tramite il programma Extended Security Update (ESU). Per maggiori informazioni a riguardo è possibile consultare questo documento Microsoft. Questa strategia consente di avere più tempo per intraprendere un percorso di modernizzazione applicativa, senza trascurare gli aspetti legati alla sicurezza.

Modernizzazione applicativa

In determinate circostanze si potrebbe intraprendere un percorso di modernizzazione applicativa, magari incentrato sul cloud pubblico, con l’obiettivo di aumentare l’innovazione, l’agilità e l’efficienza operativa. Microsoft Azure offre la flessibilità di scegliere tra un’ampia gamma di opzioni per ospitare le proprie applicazioni, coprendo lo spettro di Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), Container-as-a-Service (CaaS) e serverless. In un percorso per abbandonare sistemi operativi legacy i clienti possono utilizzare i container anche per le applicazioni non appositamente progettate per utilizzare architetture basate su microservizi. In questi casi è possibile attuare una strategia di migrazione delle applicazioni esistenti che prevede solo modifiche minimali del codice dell’applicazione oppure modifiche alle configurazioni. Si tratta di modifiche strettamente necessarie per ottimizzare l’applicazione al fine di essere ospitata su soluzioni PaaS e CaaS. Per ottenere alcuni spunti a riguardo vi invito a leggere questo articolo.

Passaggi per una transizione di successo

Per le imprese che intendono intraprendere una delle strategie riportate, ci sono alcuni passaggi importanti che devono essere presi per garantire una transizione di successo.

Indipendentemente dalla strategia che si decide adottare il consiglio è di fare un assessment dettagliato, in modo da poter categorizzare ciascun workload per tipologia, criticità, complessità e rischio. In questo modo è possibile dare delle priorità e procedere con un piano di migrazione strutturato.

Inoltre, è necessario valutare attentamente la strategia di transizione più idonea considerando come minimizzare eventuali interruzioni delle attività aziendali. Ciò può includere la pianificazione dei test e la creazione di set di backup adeguati prima della migrazione.

Infine, una volta completata la migrazione, è importante attivare un moderno sistema di monitor per garantire che il workload applicativo sia stabile e che funzioni come previsto.

Conclusioni

La fine del supporto di Windows Server 2012 e Windows Server 2012 R2 rappresenta una sfida per molte aziende che utilizzano ancora questi sistemi operativi. Tuttavia, può anche essere vista come un’opportunità per le imprese di avviare un percorso di modernizzazione dell’infrastruttura oppure applicativa. In questo modo si potrà disporre di risorse più moderne, sfruttando anche le opportunità che offrono in termini di sicurezza, scalabilità e prestazioni.

Massimizza le prestazioni di Azure Stack HCI: scopri le migliori configurazioni per il networking

Le infrastrutture iperconvergenti (HCI) sono sempre più diffuse in quanto consentono di semplificare la gestione dell’ambiente IT, ridurre i costi e scalare facilmente in caso di necessità. Azure Stack HCI è la soluzione Microsoft che permette di realizzare una infrastruttura hyper-converged per l’esecuzione di workload in ambiente on-premises e che prevede una strategica connessione a vari servizi di Azure per modernizzare la propria infrastruttura IT. Configurare correttamente il networking di Azure Stack HCI è fondamentale per garantire la sicurezza, l’affidabilità e le prestazioni delle applicazioni. In questo articolo, vengono esplorati i fondamenti della configurazione del networking di Azure Stack HCI, approfondendo le opzioni di rete disponibili e le best practice per la progettazione e la configurazione del networking.

Sono differenti i modelli di rete che è possibile prendere come riferimento per progettare, distribuire e configurare Azure Stack HCI. Nei paragrafi seguenti vengono riportati gli aspetti principali da considerare per indirizzare le possibili scelte di implementazione a livello di rete.

Numero di nodi che compongono il cluster Azure Stack HCI

Un singolo cluster Azure Stack HCI può essere composto da un unico nodo e può scalare fino a 16 nodi.

Se il cluster è composto da un singolo server a livello fisico è consigliato prevedere i seguenti componenti di rete, riportati anche nell’immagine:

singolo switch TOR (L2 oppure L3) per il traffico in direzione nord-sud;
due\quattro porte di rete in team per gestire il traffico di management e computazionale collegate allo switch;

Inoltre, opzionalmente è possibile prevedere i seguenti componenti:

due NIC RDMA, utili se si prevede di aggiunge un secondo server al cluster per scalare la configurazione;
una scheda BMC per la gestione remota dell’ambiente.

Figura 1 – Architettura di rete per un cluster Azure Stack HCI composto da un singolo server

Se il cluster Azure Stack HCI è composto da due o più nodi è necessario approfondire i parametri seguenti.

Necessità di switch Top-Of-Rack (TOR) e relativo livello di ridondanza

Per i cluster Azure Stack HCI composti da due o più nodi, in ambiente di produzione, è fortemente consigliata la presenza di due switch TOR, in modo da poter tollerare interruzioni delle comunicazioni riguardanti il traffico nord-sud, in caso di guasto oppure di manutenzione del singolo switch fisico.

Se il cluster Azure Stack HCI è composto da due nodi si può fare in modo di non prevedere una connettività tramite switch per il traffico riguardante lo storage.

Configurazione a due nodi senza switch TOR per la comunicazione storage

In un cluster Azure Stack HCI composto da solo due nodi, per ridurre i costi degli switch, andando magari ad utilizzare switch già in possesso, è possibile collegare in modalità full-mesh le NIC RDMA dello storage.

In determinati scenari, che includono ad esempio branch office, oppure laboratori, si può adottare il seguente modello di rete che prevede un unico switch TOR. Applicando questo modello si ottiene una tolleranza agli errori a livello di cluster, ed è idonea se è possibile tollerare interruzioni della connettività in direzione nord-sud quando il singolo switch fisico si guasta oppure richiede manutenzione.

Figura 2 – Architettura di rete per un cluster Azure Stack HCI composto da due server, senza switch per lo storage e con un unico switch TOR

Sebbene i servizi SDN L3 siano pienamente supportati per questo schema, i servizi di routing come BGP dovranno essere configurati sul dispositivo firewall che si trovano sopra allo switch TOR, se questo non supporta i servizi L3.

Nel caso si voglia ottenere una maggiore tolleranza ai guasti per tutti i componenti di rete è possibile prevedere la seguente architettura, che prevede due switch TOR ridondati:

Figura 3 – Architettura di rete per un cluster Azure Stack HCI composto da due server, senza switch per lo storage e switch TOR ridondati

I servizi SDN L3 sono pienamente supportati da questo schema. I servizi di routing come BGP possono essere configurati direttamente sugli switch TOR se questi supportano i servizi L3. Le funzionalità legate alla sicurezza della rete non richiedono una configurazione aggiuntiva per il dispositivo firewall, poiché sono implementate a livello di virtual network adapter.

A livello fisico è consigliato prevedere i seguenti componenti di rete per ciascun server:

duequattro porte di rete in team, per gestire il traffico di management e computazionale, collegate alloagli switch TOR;
due NIC RDMA in una configurazione full-mesh per il traffico est-ovest per lo storage. Ogni nodo del cluster deve avere una connessione ridondata all’altro nodo del cluster;
come opzionale, una scheda BMC per la gestione remota dell’ambiente.

In entrambi i casi sono necessarie le seguenti connettività:

Reti	Management e computazionale	Storage	BMC
Velocità di rete	Almeno 1 GBps, 10 GBps recommendata	Almeno 10 GBps	Tbd
Tipologia di interfaccia	RJ45, SFP+ oppure SFP28	SFP+ oppure SFP28	RJ45
Porte e aggregazione	Duequattro porte in teaming	Due porte standalone	Una porta

Configurazione a due o più nodi utilizzando switch TOR anche per la comunicazione storage

Quando si prevede un cluster Azure Stack HCI composto da più di due nodi oppure se non si vuole precludere la possibilità di poter aggiungere facilmente ulteriori nodi al cluster, è necessario far confluire anche il traffico riguardante lo storage dagli switch TOR. In questi scenari si può prevedere una configurazione dove si mantengono delle schede di rete dedicate per il traffico storage (non-converged), come mostrato nella seguente immagine:

Figura 4 – Architettura di rete per un cluster Azure Stack HCI composto da due o più server, switch TOR ridondati utilizzati anche per il traffico storage e configurazione “non-converged”

A livello fisico è consigliato prevedere i seguenti componenti di rete per ciascun server:

due schede di rete in team per gestire il traffico di management e computazionale. Ogni NIC è collegata a uno switch TOR diverso;
due NIC RDMA in configurazione standalone. Ogni NIC è collegata a uno switch TOR diverso. La funzionalità multicanale SMB garantisce l’aggregazione dei percorsi e la tolleranza agli errori;
come opzionale, una scheda BMC per la gestione remota dell’ambiente.

Queste le connettività previste:

Reti	Management e computazionale	Storage	BMC
Velocità di rete	Almeno 1 GBps, 10 GBps recommendata	Almeno 10 GBps	Tbd
Tipologia di interfaccia	RJ45, SFP+ oppure SFP28	SFP+ oppure SFP28	RJ45
Porte e aggregazione	Due porte in teaming	Due porte standalone	Una porta

Un’altra possibilità da tenere in considerazione prevede una configurazione “fully-converged” delle schede di rete, come riportato nella seguente immagine:

Figura 5 – Architettura di rete per un cluster Azure Stack HCI composto da due o più server, switch TOR ridondati utilizzati anche per il traffico storage e configurazione “fully-converged”

Quest’ultima soluzione è preferibile quando:

i requisiti di larghezza di banda per il traffico nord-sud non richiedono schede dedicate;
le porte fisiche degli switch sono un numero ridotto;
si vogliono mantenere contenuti i costi della soluzione.

A livello fisico è consigliato prevedere i seguenti componenti di rete per ciascun server:

due schede di rete RDMA in team per il traffico di management, computazionale e storage. Ogni NIC è collegata a uno switch TOR diverso. La funzionalità multicanale SMB garantisce l’aggregazione dei percorsi e la tolleranza agli errori;
come opzionale, una scheda BMC per la gestione remota dell’ambiente.

Queste le connettività previste:

Reti	Management, computazionale e storage	BMC
Velocità di rete	Almeno 10 GBps	Tbd
Tipologia di interfaccia	SFP+ oppure SFP28	RJ45
Porte e aggregazione	Due porte in teaming	Una porta

I servizi SDN L3 sono pienamente supportati da entrambi i modelli sopra riportati. I servizi di routing come BGP possono essere configurati direttamente sugli switch TOR se questi supportano i servizi L3. Le funzionalità legate alla sicurezza della rete non richiedono una configurazione aggiuntiva per il dispositivo firewall, poiché sono implementate a livello di virtual network adapter.

Tipologia di traffico che deve passare dagli switch TOR

Per scegliere gli switch TOR più adatti è necessario valutare il traffico di rete che confluirà da tali apparati di rete, il quale può essere suddiviso in:

traffico di management;
traffico computazionale (generato dai workload ospitati dal cluster), il quale può essere suddiviso in due categorie:
- traffico standard;
- traffico SDN;
traffico storage.

Microsoft ha recentemente cambiato l’approccio a riguardo. Infatti, non è più richiesto che gli switch TOR rispettino ogni requisito di rete riguardante le varie funzionalità, indipendentemente dal tipo di traffico per il quale lo switch viene utilizzato. Questo consente di avere switch fisici supportati in base al tipo di traffico che trasportano e permette di poter scegliere tra un maggior numero di dispositivi di rete ad un costo più contenuto, ma sempre di qualità.

In questo documento sono elencati gli standard di settore obbligatori per i ruoli specifici degli switch di rete utilizzati nelle implementazioni di Azure Stack HCI. Questi standard contribuiscono a garantire comunicazioni affidabili tra i nodi dei cluster Azure Stack HCI. In questa sezione sono invece riportati i modelli degli switch supportati dai vari vendor, in base alla tipologia di traffico prevista.

Conclusioni

Configurare correttamente il networking di Azure Stack HCI è fondamentale per garantire che l’infrastruttura hyper-converged funzioni in modo corretto, garantendo sicurezza, affidabilità e prestazioni ottimali. In questo articolo sono stati riportati i concetti fondamentali riguardanti la configurazione del networking di Azure Stack HCI, analizzando le opzioni di rete disponibili. Il consiglio è di pianificare sempre attentamente gli aspetti legati al networking di Azure Stack HCI, scegliendo l’opzione di rete più appropriata per le esigenze del vostro business e seguendo le best practice di implementazione.