Archivi categoria: Cloud & Datacenter Management

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.