Archivi categoria: Azure Arc

Azure al tuo fianco: nuove soluzioni per la fine del supporto di Windows Server 2012/R2

Nell’era dell’Intelligenza Artificiale e dei servizi nativi per il cloud, le organizzazioni continuano a fare affidamento su Windows Server come piattaforma sicura e affidabile per i loro workload mission-critical. Tuttavia, è importante ricordare che il supporto per Windows Server 2012/R2 terminerà il 10 ottobre 2023. Dopo tale data, i sistemi Windows Server 2012/R2 diventeranno vulnerabili se non si intraprenderanno dei provvedimenti, poiché non riceveranno più regolarmente gli aggiornamenti di sicurezza. Recentemente, Microsoft ha annunciato che Azure offre nuove soluzioni per gestire al meglio la fine del supporto di Windows Server 2012/R2. Queste soluzioni saranno esaminate nel dettaglio in questo articolo, dopo un breve riepilogo per definire il contesto.

L’impatto del termine del supporto per Windows Server 2012 R2: cosa significa per le aziende?

Microsoft ha annunciato la fine del supporto per Windows Server 2012 e 2012 R2, fissata per il 10 ottobre 2023. Questo evento rappresenta un punto cruciale per molte organizzazioni che si affidano a questi server per accedere alle applicazioni e ai dati. Ma cosa significa esattamente la fine del supporto (EOL) e quali sono le implicazioni per le aziende?

Comprendere la fine del supporto

Microsoft ha una politica di ciclo di vita che fornisce supporto per i suoi prodotti, tra cui Windows Server 2012 e 2012 R2. La fine del supporto si riferisce al momento in cui un prodotto non è più supportato da Microsoft, il che significa che non verranno più forniti aggiornamenti di sicurezza, patch o supporto tecnico.

Perché le aziende dovrebbero preoccuparsi

Senza aggiornamenti e patch regolari, le aziende che utilizzano Windows Server 2012 e 2012 R2 sono esposte a vulnerabilità di sicurezza, come attacchi ransomware e violazioni dei dati. Inoltre, l’utilizzo di un prodotto non supportato come Windows Server 2012 o 2012 R2 può portare a problemi di non conformità. Infine, il software obsoleto può causare problemi di compatibilità con applicazioni e hardware più recenti, ostacolando l’efficienza e la produttività.

Un’opportunità per rivedere la strategia IT

Le aziende dovrebbero utilizzare l’evento di EOL come un’opportunità per rivedere la loro strategia IT e determinare gli obiettivi aziendali desiderati dalla loro tecnologia. In questo modo, possono allineare la tecnologia con i loro obiettivi a lungo termine, sfruttando le ultime soluzioni cloud e migliorando l’efficienza operativa.

Le strategie che è possibile adottare per affrontare questa situazione, evitando così di esporre la propria infrastruttura IT a problematiche di security, sono già state affrontate nell’articolo: Come la fine del supporto di Windows Server 2012 può essere una grande opportunità per i CTO.

A questo proposito, Microsoft ha introdotto due nuove opzioni, fornite tramite Azure, per agevolare la gestione di questa situazione:

  • aggiornamento dei server con Azure Migrate;
  • distribuzione sui server abilitati ad Azure Arc degli aggiornamenti derivanti dall’ESU (Extended Security Updates).

Nei paragrafi seguenti vengono descritte le caratteristiche di queste nuove opzioni.

Aggiornamento dei server Windows in fase di fine supporto (EOS) con Azure Migrate

Azure Migrate è un servizio offerto da Microsoft Azure che consente di valutare e migrare le risorse locali, come macchine virtuali, applicazioni e database, verso l’infrastruttura cloud di Azure. Recentemente, Azure Migrate ha introdotto il supporto per gli aggiornamenti in-place di Windows Server 2012 e versioni successive, durante il passaggio ad Azure. Questo permette alle organizzazioni di spostare le loro applicazioni e i loro database legacy su un sistema operativo completamente supportato, compatibile e conforme come Windows Server 2016, 2019 oppure 2022.

Vantaggi chiave della funzionalità di aggiornamento del sistema operativo di Azure Migrate

Mitigazione del rischio: Azure Migrate crea una replica del server originale in Azure, permettendo l’aggiornamento del sistema operativo sulla replica mentre il server di origine rimane intatto. In caso di problemi, i clienti possono facilmente tornare al sistema operativo originale.

Test di compatibilità: Azure Migrate offre la possibilità di eseguire una migrazione di prova in un ambiente isolato in Azure. Questo è particolarmente utile per gli aggiornamenti del sistema operativo, permettendo ai clienti di valutare la compatibilità del loro sistema operativo e delle applicazioni aggiornate senza impattare la produzione. In questo modo è possibile identificare e risolvere eventuali problemi in anticipo.

Riduzione dello sforzo e del downtime: integrando gli aggiornamenti del sistema operativo con la migrazione al cloud, i clienti possono risparmiare significativamente tempo e sforzo. Con un solo dato aggiuntivo, la versione del sistema operativo di destinazione, Azure Migrate si occupa del resto, semplificando il processo. Questa integrazione riduce ulteriormente il downtime del server e delle applicazioni su di esso ospitate, aumentando l’efficienza.

Nessuna licenza Windows separata: con l’aggiornamento del sistema operativo di Azure Migrate, non è necessario acquistare separatamente una licenza del sistema operativo per effettuare l’aggiornamento. Che il cliente utilizzi Azure Hybrid Benefits (AHB) o PAYG, risulta coperto quando migrerà a un VM Azure utilizzando Azure Migrate.

Aggiornamento dei server su larga scala: Azure Migrate supporta aggiornamenti del sistema operativo dei server su larga scala, permettendo ai clienti di aggiornare fino a 500 server in parallelo durante la migrazione ad Azure. Utilizzando il portale Azure, sarà possibile selezionare fino a 10 VMs alla volta per configurare le repliche. Per replicare più VMs è possibile utilizzare il portale e aggiungere le VMs da replicare in più lotti di 10 VMs, oppure utilizzare l’interfaccia PowerShell di Azure Migrate per configurare la replica.

Versioni del sistema operativo supportate

Azure Migrate è in grado di gestire:

  • Windows Server 2012: supporta l’aggiornamento a Windows Server 2016;
  • Windows Server 2012 R2: supporta l’aggiornamento a Windows Server 2016, Windows Server 2019;
  • Windows Server 2016: supporta l’aggiornamento a Windows Server 2019, Windows Server 2022;
  • Windows Server 2019: supporta l’aggiornamento a Windows Server 2022.

Distribuzione degli aggiornamenti derivanti dall’ESU sui server abilitati ad Azure Arc

Azure Arc è un insieme di soluzioni Microsoft che consentono alle aziende di gestire, governare e proteggere le risorse in vari ambienti, tra cui on-premise, edge e multi-cloud, estendendo le capacità di gestione di Azure a qualsiasi infrastruttura.

Per le organizzazioni che non sono in grado di modernizzare oppure migrare prima della data di fine del supporto di Windows Server 2012/R2, Microsoft ha annunciato gli Extended Security Updates (ESU) abilitati da Azure Arc. Con Azure Arc, le organizzazioni saranno in grado di acquistare e distribuire senza problemi gli Extended Security Updates (ESU) in ambienti on-premise o multicloud, direttamente dal portale Azure.

Per ottenere gli Extended Security Updates (ESU) per Windows Server 2012/R2 e SQL Server 2012 abilitati da Azure Arc, è necessario seguire i passaggi seguenti:

  • Preparazione dell’ambiente Azure Arc: innanzitutto, è necessario un ambiente Azure e un’infrastruttura Azure Arc funzionante. Azure Arc può essere installato su qualsiasi server che esegue Windows Server 2012/R2 oppure SQL Server 2012, a condizione che vengano rispettati i requisiti di connettività.
  • Registrazione del server in Azure Arc: una volta predisposto l’ambiente Azure Arc, è necessario registrare i server Windows o i sistemi SQL Server in Azure Arc. Questo processo consente ai sistemi di diventare risorse gestite in Azure, rendendoli idonei per gli ESU.
  • Acquisto degli ESU: una volta che i server sono registrati in Azure Arc, è possibile acquistare gli ESU, per ogni server che desideri proteggere, attraverso Azure.
  • Attivazione degli ESU: dopo l’acquisto degli ESU, è necessario attivarli sui server. Questo processo comporta l’installazione di una chiave di licenza e il download degli aggiornamenti di sicurezza da Windows Update o dall’infrastruttura locale di distribuzione degli aggiornamenti.
  • Installazione degli aggiornamenti: infine, una volta attivati gli ESU, è possibile effettuare l’installazione degli aggiornamenti di sicurezza sui server. Questo processo può essere gestito manualmente o automatizzandolo attraverso strumenti di gestione degli aggiornamenti.

NOTA: gli ESU forniscono solo aggiornamenti di sicurezza critici e importanti, non includono nuove funzionalità o miglioramenti delle prestazioni. Inoltre, gli ESU sono disponibili solo per un periodo limitato dopo la fine del supporto di Microsoft. Pertanto, si consiglia di prendere in considerazione la migrazione a versioni più recenti dei server per avere accesso a tutte le funzionalità, oltre agli aggiornamenti di sicurezza.

Conclusioni

Quest’anno, Microsoft celebra il 30° anniversario di Windows Server, un traguardo raggiunto grazie all’incessante innovazione e al sostegno dei clienti. Tuttavia, i clienti si devono impegnare a mantenere aggiornati i loro sistemi Windows Server prossimi alla fine del supporto. In particolare, la fine del supporto per Windows Server 2012 e 2012 R2 rappresenta un rischio significativo per le aziende, ma presenta anche un’opportunità per rivedere e migliorare la loro strategia IT. Identificando gli obiettivi aziendali desiderati, impegnandosi nella pianificazione strategica e, se necessario, utilizzando queste nuove soluzioni offerte da Azure, le aziende possono garantire una transizione fluida e di successo, ottimizzando la loro infrastruttura IT per raggiungere i loro obiettivi a lungo termine.

Come preparare l’ambiente IT per affrontare nuovi scenari ibridi e multicloud

Molte realtà aziendali sono impegnate nella diffusione e nell’adozione di applicazioni che possono funzionare in ambienti diversi: on-premises, su più cloud pubblici e negli edge. Tale approccio richiede una preparazione adeguata dell’ambiente IT aziendale per garantire conformità e una gestione efficiente su larga scala dei sistemi server, delle applicazioni e dei dati, mantenendo al contempo una elevata agilità. In questo articolo, vengono introdotti i principali aspetti da tenere in considerazione per l’adozione di tecnologie ibride e multicloud, al fine di soddisfare al meglio le esigenze di business.

Le ragioni che portano all’adozione di soluzioni ibride e multicloud

Sono molte le ragioni per le quali i clienti scelgono di distribuire il loro patrimonio digitale in ambienti ibridi e multicloud. Tra le principali troviamo:

  • Riduzione al minimo oppure rimozione di lock-in dati da un singolo cloud provider
  • Presenza di business unit, aziende sussidiarie o società acquisite che hanno già fatto scelte di adozione di differenti piattaforme cloud
  • Requisiti normativi e di sovranità dei dati differenti nei vari paesi
  • Necessità di migliorare la business continuity ed il disaster recovery andando a distribuire i workload tra due cloud provider differenti
  • Esigenze di massimizzare le prestazioni permettendo di eseguire le applicazioni in prossimità rispetto a dove si trovano gli utenti

Quali aspetti considerare?

Per la preparazione di un ambiente IT idoneo ad ospitare deployment ibridi e multicloud esistono differenti possibilità, motivo per il quale prima di configurare il proprio ambiente Azure o qualsiasi altro cloud pubblico, è importante identificare in che modo l’ambiente cloud dovrà supportare il proprio scenario:

Figura 1 – Diagramma che illustra come diversi clienti distribuiscono i workload tra cloud provider

Nell’immagine sopra riportata ogni punto blu scuro rappresenta un workload ed ogni cerchio di colore azzurro è un processo aziendale, supportato da un ambiente distinto. A seconda del cloud-mix può essere necessaria una diversa configurazione dell’ambiente Azure:

  • Cliente Hybrid-first: la maggior parte dei workload rimane in sede, spesso in una combinazione di modelli di hosting con risorse tradizionali ed ibride. Alcuni workload specifici vengono distribuiti nell’edge, in Azure oppure presso altri provider di servizi cloud.
  • Cliente Azure-first: la maggior parte dei workload risiede in Azure. Alcuni workload rimangono comunque in locale. Inoltre, determinate decisioni strategiche portano alcuni workload a risiedere negli edge oppure in ambienti multicloud.
  • Cliente multicloud-first: la maggior parte dei workload viene ospitata su un cloud pubblico diverso da Azure, come Amazon Web Services (AWS) oppure Google Cloud Platform (GCP). Alcune decisioni strategiche hanno però portato alcuni workload ad essere posizionati in Azure oppure presso gli edge.

A seconda della strategia ibrida e multicloud che si decide di intraprendere per le applicazioni e per i dati, questa dovrà indirizzare determinate scelte.

Come predisporre l’ambiente Azure

Microsoft Azure è un provider di servizi cloud a livello enterprise ed è in grado di supportare al meglio ambienti pubblici, ibridi e multicloud.

Per preparare un ambiente IT e renderlo efficace per qualsiasi deployment ibrido e multicloud è opportuno tenere in considerazione i seguenti aspetti chiave:

  • Topologia e connettività di rete
  • Governance
  • Sicurezza e conformità
  • Discipline di automazione, esperienze di sviluppo e pratiche DevOps

Quando si affronta il tema della preparazione del proprio ambiente IT per nuovi scenari ibridi e multicloud è opportuno definire la “Landing Zone” di Azure che rappresenta, nel percorso di adozione del cloud, il punto di arrivo. Si tratta di un’architettura progettata per consentire di gestire ambienti cloud funzionali, contemplando i seguenti aspetti:

  • Scalabilità
  • Security governance
  • Networking
  • Identità
  • Cost management
  • Monitoring

L’architettura della Landing Zone deve essere definita in base ai requisiti aziendali e tecnici specifici. Risulta quindi necessario valutate le possibili opzioni di implementazione della Landing Zone, grazie alle quali sarà possibile soddisfare le esigenze di deployment ed operatività del portfolio cloud.

Figura 2 – Esempio concettuale di una Azure landing zone

Quali strumenti utilizzare?

Cloud Adoption Framework

Il Cloud Adoption Framework di Microsoft fornisce un ricco set di documentazione, linee guida per l’implementazione, procedure consigliate e strumenti utili per accelerare il percorso di adozione del cloud. Tra queste best practice, che è bene adottare e che è opportuno declinare in modo specifico sui vari clienti in base alle loro esigenze, è presente una sezione specifica riguardante gli ambienti ibridi e multicloud. Questa sezione tratta le diverse best practice che possono aiutare a facilitare vari mix di cloud, che vanno da ambienti totalmente in Azure ad ambienti dove l’infrastruttura presso il cloud pubblico di Microsoft non è presente oppure è limitata.

Azure Arc come acceleratore

Azure Arc consiste in un insieme di differenti tecnologie e di componenti che permettono di disporre di un unico meccanismo di controllo per gestire e governare in modo coerente tutte le tue risorse IT, ovunque si trovino. Inoltre, con i servizi abilitati per Azure Arc, si ha la flessibilità di distribuire servizi completamente gestiti di Azure ovunque, on-premises oppure presso altri cloud pubblici.

Figura 3 –  Azure Arc overview

L’Azure Arc-enabled servers Landing Zone, presente nel Cloud Adoption Framework, consente ai clienti di aumentare più facilmente la sicurezza, la governance e lo stato di conformità dei server distribuiti al di fuori di Azure. Insieme ad Azure Arc, servizi come Microsoft Defender for Cloud, Azure Sentinel, Azure Monitor, Azure Policy e molti altri possono essere estesi a tutti gli ambienti. Per questa ragione Azure Arc lo si deve considerare come un acceleratore per le proprie Landing Zone.

Azure Arc Jumpstart è cresciuto molto e permette di valutare al meglio Azure Arc, con oltre 90 scenari automatizzati, migliaia di visitatori al mese e una community open source molto attiva che condivide le proprie conoscenze su Azure Arc. Come parte di Jumpstart, è stato sviluppato ArcBox, un ambiente sandbox automatizzato per tutto ciò che riguarda Azure Arc, distribuibile nelle sottoscrizioni Azure dei clienti. Come acceleratore per la landing zone dei server abilitati per Azure Arc è stato sviluppato ArcBox per IT pro, che funge da soluzione di automazione sandbox per questo scenario, con servizi come Azure Policy, Azure Monitor, Microsoft Defender for Cloud, Microsoft Sentinel e altro ancora.

Figura 4 – Architettura di ArcBox per IT pro

Conclusioni

L’adozione di pratiche operative coerenti in tutti gli ambienti cloud, associate ad un piano di controllo comune, consente di affrontare in modo efficace le sfide intrinseche nelle strategie ibride e multicloud. Per farlo Microsoft mette a disposizione vari strumenti ed acceleratori, uno tra i quali è Azure Arc che rende più facile per i clienti aumentare la sicurezza, la governance e lo stato di conformità delle risorse IT distribuite al di fuori di Azure.

Come semplificare la gestione dei sistemi con Azure Automanage

L’adozione di soluzioni cloud ha contribuito a ridurre le spese operative (OpEx) e gli oneri di gestione in numerose aree dell’IT. Infatti, molti sistemi che in precedenza venivano eseguiti on-premises ed erano complessi da mantenere ora sono semplici servizi gestiti nel cloud. Allo stesso tempo però, l’esecuzione dei sistemi dislocati in ambienti differenti e la vasta gamma di nuovi servizi Azure, possono rendere articolata la gestione operativa. Microsoft, per gestire al meglio i vari servizi e la relativa configurazione, mette a disposizione la soluzione Azure Automanage, che opportunamente integrata con Azure Arc, consente di automatizzare diverse operazioni durante l’intero ciclo di vita delle macchine, indipendentemente da dove queste risiedono. In questo articolo vengono riportate le caratteristiche della soluzione, mostrando come Azure Automanage, insieme ad Azure Arc, può agevolare le attività quotidiane degli amministratori di sistema e garantire un rispetto ottimale delle best practice Microsoft.

Semplificare la configurazione e la gestione dei sistemi ovunque risiedano

Azure Automanage consente di implementare automaticamente le best practice nella gestione delle macchine garantendo la conformità per quanto riguarda gli aspetti legati alla sicurezza, alla conformità aziendale e alla business continuity. Inoltre, Azure Arc for servers estende le possibilità offerte da Azure in ambito governance e management anche alle macchine fisiche ed ai sistemi virtuali che risiedono in ambienti differenti da Azure. Per ottenere maggiori informazioni in merito alle linee guida per l’implementazione, le best practice e gli strumenti comprovati da Microsoft e progettati per accelerare il percorso di adozione di soluzioni cloud è bene fare riferimento al Microsoft Cloud Adoption Framework.

Configurare rapidamente i server Windows e Linux

Adottando questa soluzione è possibile rilevare, integrare e configurare differenti servizi di Azure durante l’intero ciclo di vita delle macchine, facendo distinzione tra ambienti di Produzione ed ambienti di DevTest. I servizi Azure automaticamente gestiti da Azure Automanage e le relative specifiche sono consultabili in questa documentazione Microsoft:

Figura 1 – Panoramica dei servizi gestiti da Azure Automanage

L’inclusione delle macchine nel servizio può avvenire su larga scala oppure singolarmente, con la certezza che se i sistemi non rispettano le best practice imposte, Azure Automanage sarà in grado di rilevarle e correggerle automaticamente.

Il servizio può essere attivato direttamente dal portale Azure e richiede pochi semplici passaggi.

La scelta dei profili di configurazione

Azure Automanage utilizza dei profili di configurazione per determinare quali servizi Azure devono essere abilitati sui sistemi selezionati. Attualmente sono disponibili di default due profili di configurazione, uno per l’ambiente di DevTest e uno per l’ambiente di Produzione. I due profili si distinguono per le tipologie di servizi che si intendono abilitare sui differenti workload. Inoltre, oltre ai profili standard è consentito configurare dei profili personalizzati con un certo sottoinsieme di preferenze riguardanti i vari servizi.

Dopo aver abilitato il servizio Azure Automanage viene avviato il processo che riconduce le macchine alle best practice specificate nel profilo di configurazione scelto.

Lo stato delle VMs post attivazione del servizio può essere di diverse tipologie, qui descritte.

Azure Automanage ha recentemente introdotto anche nuove opzioni di personalizzazione dei profili e un maggior numero di sistemi operativi supportati, tra i quali Windows 10/11, Red Hat Enterprise Linux, Canonical Ubuntu e SUSE Linux Enterprise Server.

Configurare i server Windows e Linux in ambienti Azure, ibridi oppure multi-cloud attraverso Azure Arc

Azure Automanage può essere abilitato sia sulle macchine virtuali Azure sia sui server abilitati ad Azure Arc. Inoltre, Azure Automanage per Windows Server offre nuove funzionalità specifiche per Windows Server Azure Edition, che migliorano il tempo di attività delle macchine virtuali Windows Server in Azure e in ambiente Azure Stack HCI. Queste funzionalità includono:

  • Hotpatch
  • SMB over QUIC
  • Azure Extended Networking

Vantaggi della soluzione

L’adozione di Azure Automanage comporta diversi vantaggi per il cliente che possono essere sintetizzati nei punti seguenti:

  • Riduzione dei costi, automatizzando la gestione delle macchine
  • Ottimizzazione dell’uptime dei workload grazie all’esecuzione di operazioni in modo ottimizzato
  • Controllo sull’implementazione delle best practices di sicurezza

Conclusioni

La gestione del ciclo di vita delle macchine, specialmente in ambienti eterogenei e di grandi dimensioni, può risultare molto onerosa in termini di tempo e di costi. Inoltre, le attività che vengono ripetute in modo frequente possono essere soggette ad errori, portando i sistemi ad una configurazione non ottimale. Grazie a questa integrazione tra Azure Automanage ed Azure Arc è possibile semplificare ed automatizzare tutte le operazioni necessarie per garantire che i sistemi aderiscano ai requisiti voluti.

Realizzare architetture IT moderne per il Machine Learning

Per la maggior parte delle realtà aziendali, la capacità di fornire e di integrare continuamente soluzioni di intelligenza artificiale all’interno delle proprie applicazioni e nei workflow aziendali, viene considerata un’evoluzione particolarmente complessa. Nel panorama dell’intelligenza artificiale in rapida evoluzione il machine learning (ML) ricopre un ruolo fondamentale insieme alla “data science”. Pertanto, per aumentare i successi di determinati progetti di intelligenza artificiale, le organizzazioni devono disporre di architetture IT moderne ed efficienti per il machine learning. In questo articolo viene descritto come è possibile realizzare ovunque queste architetture grazie all’integrazione tra Kubernetes, Azure Arc ed Azure Machine Learning.

Azure Machine Learning

Azure Machine Learning (AzureML) è un servizio cloud che è possibile utilizzare per accelerare e gestire il ciclo di vita dei progetti di machine learning, portando i modelli di ML in un ambiente di produzione sicuro ed affidabile.

Kubernetes come destinazione di calcolo per Azure Machine Learning

Azure Machine Learning ha recentemente introdotto la possibilità di attivare una nuova destinazione per il calcolo computazionale: AzureML Kubernetes compute. Infatti, risulta possibile utilizzare un cluster Azure Kubernetes Service (AKS) esistente oppure un cluster Kubernetes abilitato per Azure Arc come destinazione di calcolo per Azure Machine Learning e utilizzarlo per validare e per distribuire modelli di ML.

Figura 1 – Panoramica su come portare Azure ML ovunque grazie a K8s ed Azure Arc

AzureML Kubernetes compute supporta due tipi di cluster Kubernetes:

  • Cluster AKS (in ambiente Azure). Utilizzando un cluster gestito Azure Kubernetes Service (AKS), è possibile ottenere un ambiente flessibile, sicuro ed in grado di soddisfare i requisiti di conformità per i workload di ML.
  • Cluster Kubernetes Arc-enabled (in ambienti differenti da Azure). Grazie ad Azure Arc-enabled Kubernetes risulta possibile gestire da Azure cluster Kubernetes in esecuzione in ambienti differenti  (on-premises o su altri cloud) e utilizzarli per distribuire modelli di ML.

Per abilitare e utilizzare un cluster Kubernetes per eseguire workload AzureML è necessario seguire i seguenti passaggi:

  1. Attivare e configurare un cluster AKS oppure un cluster Kubernetes Arc-enabled. A questo proposito si ricorda anche la possibilità di attivare AKS in ambiente Azure Stack HCI.
  2. Distribuire l’estensione AzureML sul cluster.
  3. Collegare il cluster Kubernetes al workspace di Azure ML.
  4. Utilizzare la destinazione di calcolo Kubernetes da CLI v2, SDK v2 e la Studio UI.

Figura 2 – Step per abilitare e per utilizzare un cluster K8s per workload AzureML

La gestione dell’infrastruttura per i workload di ML può risultare complessa e Microsoft consiglia che venga eseguita dal team IT-operations, in modo che il team di data science possa concentrarsi sull’efficienza dei modelli di ML. Alla luce di questa considerazione, la suddivisione dei ruoli può essere la seguente:

  • Il Team IT-operation è responsabile dei primi 3 passaggi riportati in precedenza. Inoltre, solitamente svolge le seguenti attività per il team di data science:
    • Effettua le configurazioni degli aspetti legati al networking ed alla sicurezza
    • Crea e gestisce le tipologie di istanze per i diversi scenari di carico di lavoro di ML al fine di ottenere un utilizzo efficiente delle risorse di calcolo.
    • Si occupa della risoluzione dei problemi relativi al carico di lavoro dei cluster Kubernetes.
  • Il Team di data science, concluse le attività di attivazione in carico al Team IT-operation, può individuare un elenco di destinazioni di calcolo e di tipologie di istanza disponibili nel workspace di AzureML. Queste risorse di calcolo possono essere usate per i workload di training oppure di inferenza. La destinazione di calcolo viene scelta dal team utilizzando gli strumenti specifici come AzureML CLI v2, Python SDK v2 oppure Studio UI.

Scenari d’uso

La possibilità di utilizzare Kubernetes come destinazione di calcolo per Azure Machine Learning, unita alle potenzialità di Azure Arc, consente di creare, sperimentare e distribuire modelli di ML in qualsiasi infrastruttura on-premises oppure su differenti cloud.

Questa possibilità attiva differenti nuovi scenari di utilizzo, precedentemente impensabili utilizzando solo l’ambiente cloud. La tabella seguente fornisce un riepilogo degli scenari d’uso resi possibili da Azure ML Kubernetes compute, specificando la posizione in cui risiedono i dati, la motivazione che guida ogni modello di utilizzo e come viene realizzato a livello di infrastruttura e di Azure ML.

Tabella 1 – Nuovi scenari d’uso resi possibili da Azure ML Kubernetes compute

Conclusioni

Gartner prevede che entro il 2025, a causa di una rapida diffusione di iniziative in ambito dell’IA, il 70% delle organizzazioni avrà reso operative architetture IT per l’intelligenza artificiale. Microsoft, grazie all’integrazione tra differenti soluzioni offre una serie di possibilità per attivare architetture flessibili e all’avanguardia per il Machine Learning, parte integrante dell’intelligenza artificiale.

La modernizzazione del datacenter: un caso reale con soluzioni Microsoft

I dati statistici parlano chiaro, oltre il 90% delle realtà aziendali dispongono già oppure prevedono, nel breve periodo, di adottare una strategia ibrida per la propria infrastruttura IT. Questi dati vengono confermati dalla quotidianità dei fatti, dove diversi clienti includono nei loro piani di investimento sia il mantenimento dei workload sulle infrastrutture on-premises, sia l’adozione di soluzioni nel cloud pubblico. Parallelamente viene affiancato un percorso di modernizzazione delle applicazioni con l’obiettivo di sfruttare al meglio le potenzialità e l’innovazione offerte da queste infrastrutture. Viviamo quindi nell’era del cloud ibrido e Microsoft mette a disposizioni diverse soluzioni interessanti per modernizzare il proprio datacenter e gestire agilmente la propria infrastruttura ibrida. In questo articolo viene portato un esempio reale di come un cliente ha intrapreso il percorso di modernizzazione del proprio datacenter grazie ad Azure Stack HCI e come, tramite Azure Arc, è stato in grado di estendere i servizi ed i principi di gestione di Azure anche alla propria infrastruttura on-premises.

Richiesta iniziale del cliente e problematiche da risolvere

Il cliente in questione voleva attivare presso il proprio datacenter una nuova infrastruttura di virtualizzazione moderna ed integrata, per consentire di configurare in modo rapido, dinamico e flessibile i workload applicativi. L’infrastruttura in uso dal cliente non era adeguata e riscontrava diverse problematiche, tra le quali:

  • Soluzione di virtualizzazione non scalabile e poco flessibile
  • Obsolescenza hardware
  • Configurazioni che non garantivano una disponibilità adeguata dei sistemi virtualizzati
  • Problemi di performance e di stabilità
  • Difficoltà nella gestione dei vari componenti dell’infrastruttura

Caratteristiche delle soluzioni proposte, adottate e benefici ottenuti

Il cliente ha deciso di adottare una infrastruttura hyper-converged (HCI), dove sono stati rimossi diversi componenti hardware, sostituti dal software in grado di unire i layer di elaborazione, storage e rete in un’unica soluzione. In questo modo ha effettuato un passaggio da una tradizionale infrastruttura “three tier”, composta da switch di rete, appliance, sistemi fisici con a bordo hypervisor, storage fabric e SAN, verso infrastrutture hyper-converged (HCI).

Figura 1 – Passaggio da una infrastruttura “Three Tier” verso una Hyper-Converged Infrastructure (HCI)

Azure Stack HCI: lo stack completo dell’infrastruttura Hyper-Converged

Tutto ciò è stato fatto adottando la soluzione Microsoft Azure Stack HCI, che consente l’esecuzione di workload ed una facile connessione ad Azure dell’infrastruttura hyper-converged (HCI).  Nei paragrafi seguenti si riportano le principali caratteristiche della soluzione.

Scelta e personalizzazione dell’hardware

Il cliente ha potuto personalizzare la soluzione hardware in base alle proprie esigenze, andando a configurare il processore, la memoria, lo storage e le caratteristiche delle schede di rete, rispettando le matrici di compatibilità del fornitore.

Figura 2 – Composizione hardware della soluzione Azure Stack HCI

Sono diversi i fornitori hardware che offrono soluzioni idonee per eseguire Azure Stack HCI e possono essere consultate accedendo a questo indirizzo. La scelta è ampia e ricade su oltre 200 soluzioni di oltre 20 partner differenti. Azure Stack HCI richiede hardware appositamente testato e validato dai vari vendor.

Sistema operativo dedicato e specifico

Il sistema operativo della soluzione Azure Stack HCI è un sistema operativo specifico con una composizione semplificata e componenti più aggiornati rispetto a Windows Server. In questo sistema operativo non sono inclusi i ruoli non necessari alla soluzione, ma è presente il più recente hypervisor utilizzato anche in ambiente Azure, con tecnologie storage e di rete software-defined ottimizzate per la virtualizzazione.

L’interfaccia utente locale è minima ed è progettato per essere gestito da remoto.

Figura 3 – Interfaccia del SO di Azure Stack HCI

Disaster recovery e failover delle macchine virtuali

Il cliente ha inoltre sfruttato la possibilità di creare uno stretched cluster per estendere il proprio cluster Azure Stack HCI, nel caso specifico in due edifici differenti. Questa funzionalità si basa su una replica dello storage (sincrona in questo scenario) contemplando la crittografia, la resilienza locale del sito ed il failover automatico delle macchine virtuali in caso di disastro.

Figura 4 – Stretched cluster dell’architettura hyper-converged di Azure Stack HCI

Aggiornamenti di tutto lo stack della soluzione (full-stack updates)

Al fine di ridurre la complessità ed i costi operativi dati dal processo di aggiornamento dell’intera soluzione, il cliente può avviare in Azure Stack HCI il processo che prevede l’aggiornamento full-stack (firmware / driver insieme al sistema operativo) direttamente da Windows Admin Center.

Figura 5 – Solution updates della soluzione Azure Stack HCI marchiata Dell EMC

Servizio ibrido di Azure: familiarità nella gestione e nel funzionamento

Il cliente è in grado di gestire la propria infrastruttura basata su Azure Stack HCI in modo semplice e senza adottare strumenti software specifici, come se fosse un’estensione del cloud pubblico, grazie alle caratteristiche citate nei paragrafi seguenti.

Integrazione nativa in Azure

Azure Stack HCI si integra in modo nativo con i servizi Azure e con Azure Resource Manager (ARM). Per questa integrazione non è richiesto alcun agente, ma Azure Arc è integrato direttamente nel sistema operativo. Questa permette di visualizzare, direttamente dal portale Azure, il cluster Azure Stack HCI presente on-premises esattamente come una risorsa di Azure.

Figura 6 – Integrazione di Azure Stack HCI in Azure

Grazie all’integrazione con Azure Resource Manager il cliente può sfruttare i seguenti vantaggi dati della gestione basata su Azure:

  • Adozione dei costrutti standard basati su Azure Resource Manager (ARM)
  • Classificazione dei cluster con i Tags
  • Organizzazione dei cluster in Resource Groups
  • Visualizzazione di tutti i cluster di Azure Stack HCI in un’unica vista centralizzata
  • Gestione degli accessi tramite Azure Identity Access Management (IAM)

Inoltre, dalla risorsa Azure Stack HCI è possibile individuare, aggiungere, modificare o rimuovere le extension, grazie alle quali è possibile accedere facilmente alle funzionalità di gestione.

Figura 7 – Funzionalità di gestione di Azure Stack HCI

Gestione delle VM Arc-enabled

Oltre che per gestire il cluster, il cliente può utilizzare Azure Arc anche per eseguire il provisioning e la gestione delle macchine virtuali in esecuzione su Azure Stack HCI, direttamente dal portale di Azure. Le macchine virtuali e le loro risorse associate (immagini, dischi, e network) vengono proiettate in ARM come risorse separate mediante una nuova tecnologia multi piattaforma chiamata Arc Resource Bridge.

In questo modo è possibile:

  • ottenere una gestione coerente tra le risorse cloud e le risorse Azure Stack HCI;
  • automatizzare le distribuzioni delle macchine virtuali utilizzando i modelli ARM;
  • garantire un accesso self-service grazie al supporto ad Azure RBAC.

Figura 8 – Funzionalità date dall’integrazione di Azure Arc per le VMs di Azure Stack HCI

Azure Backup ed Azure Site Recovery

Azure Stack HCI supporta Azure Backup ed Azure Site Recovery. Con Microsoft Azure Backup Server (MABS) il cliente effettua il backup degli host e delle macchine virtuali attive in Azure Stack HCI. Inoltre, utilizzando Azure Site Recovery è possibile attivare la replica delle macchine virtuali da Azure Stack HCI ad Azure, per creare scenari di disaster recovery specifici.

Monitor dell’infrastruttura con Azure Monitor Insights per Azure Stack HCI

Grazie alla soluzione Azure Stack HCI Insights il cliente è in grado di consultare informazioni dettagliate sull’integrità, sulle prestazioni e sull’utilizzo dei cluster Azure Stack HCI connessi ad Azure e registrati per il relativo monitoraggio. Azure Stack HCI Insights archivia i propri dati in un workspace di Log Analytics, avendo così la possibilità di utilizzare potenti aggregazioni e filtri per analizzare al meglio i dati raccolti nel tempo. Si ha la possibilità di visualizzare i dati di monitor di un singolo cluster dalla pagina delle risorse Azure Stack HCI oppure è possibile utilizzare Azure Monitor per ottenere una visualizzazione aggregata di più cluster Azure Stack HCI con una panoramica dell’integrità del cluster, lo stato di nodi e delle macchine virtuali (CPU, memoria e consumo di storage), metriche delle prestazioni e altro ancora. Si tratta degli stessi dati forniti anche da Windows Admin Center, ma progettati per scalare fino a 500 cluster contemporaneamente.

Figura 9 – Pannello di controllo di Azure Monitor Insights per Azure Stack HCI

Azure benefit per Windows Server

Microsoft offre vantaggi speciali quando si distribuisce Windows Server in ambiente Azure e gli stessi vantaggi sono disponibili anche su Azure Stack HCI.

Figura 10 – Azure benefit per Windows Server

Azure Stack HCI consente di:

  • Distribuire macchine virtuali con Windows Server 2022 edizione Azure Datacenter, che offre funzionalità specifiche non disponibili nelle classiche edizioni Standard e Datacenter. Per approfondire le caratteristiche disponibili in questa edizione è possibile consultare questo articolo.
  • Ottenere gratuitamente aggiornamenti di sicurezza estesi, proprio come in Azure. Questo vale sia per Windows Server 2008/R2, sia per Windows Server 2012/R2, oltre alle versioni corrispondenti di SQL Server.
  • Ottenere la licenza ed attivare le macchine Windows Server come in Azure. Azure Stack HCI oltre a consentire di utilizzare la propria licenza Datacenter per abilitare l’attivazione automatica delle macchine virtuali (Automatic VM Activation – AVMA), mette a disposizione l’opzione di pagare la licenza di Windows Server per i sistemi guest tramite la propria subscription Azure, proprio come avviene in ambiente Azure.

Team di supporto Azure dedicato

Azure Stack HCI è a tutti gli effetti una soluzione Azure, pertanto il cliente può usufruire del supporto Azure con le seguenti caratteristiche:

  • Potrà richiedere facilmente supporto tecnico direttamente dal portale Azure.
  • Il supporto sarà fornito da un nuovo team di esperti dedicato a supportare la soluzione Azure Stack HCI.
  • Sarà possibile scegliere tra diversi piani di supporto, a seconda delle esigenze.

Innovazione dell’infrastruttura e nuovi scenari evoluti

In ambiente Azure Stack HCI, oltre ad eseguire macchine virtuali, è possibile attivare Azure Kubernetes Service (AKS) ed Azure Virtual Desktop.

Azure Kubernetes Service in Azure Stack HCI

Questo scenario di implementazione di AKS on-premises permette di automatizzare l’esecuzione su larga scala di applicazioni moderne basate su micro-servizi. Grazie ad Azure Stack HCI l’adozione di queste architetture applicative basate su container possono essere ospitate direttamente presso il proprio datacenter, adottando la stessa esperienza di gestione di Kubernetes che si ha con il servizio gestito presente nel cloud pubblico di Azure.

Figura 11 – Panoramica di AKS su Azure Stack HCI

Per maggiori informazioni è possibile consultare l’articolo Azure Kubernetes Service in ambiente Azure Stack HCI.

Azure Virtual Desktop per Azure Stack HCI

In situazioni dove le applicazioni risultano sensibili alla latenza, come ad esempio l’editing video, oppure scenari dove gli utenti hanno bisogno di usufruire di un sistema legacy presente on-premises che non può essere facilmente raggiunto, Azure Virtual Desktop aggiunge una nuova opzione ibrida grazie ad Azure Stack HCI. Azure Virtual Desktop per Azure Stack HCI usa lo stesso piano di gestione cloud del normale Azure Virtual Desktop, ma consente di creare pool di session host utilizzando macchine virtuali in esecuzione su Azure Stack HCI. Queste macchine virtuali possono eseguire Windows 10 e/o Windows 11 Enterprise multi-session. Collocando i desktop più vicini agli utenti, è possibile abilitare l’accesso diretto a bassa latenza e senza round trip.

Conclusioni

Microsoft gestisce tra i più grandi data center del mondo e sta facendo grossi investimenti per portare l’esperienza maturata e l’innovazione del cloud anche in Azure Stack HCI. Questo cliente, affidandosi ad Azure Stack HCI sta usufruendo di un servizio in abbonamento che riceve aggiornamenti regolari delle funzionalità, con l’obiettivo importante di poter sfruttare on-premises la tecnologia collaudata su larga scala nel cloud. Inoltre, è in grado di gestione in modo unificato le risorse del proprio ambiente ed avere una continua innovazione della propria infrastruttura ibrida.

Come estendere i principi di gestione di Azure alle infrastrutture VMware con Azure Arc

La tendenza che si riscontra frequentemente in differenti contesti aziendali è quella di ricorrere a strategie ibride e multi-cloud per i propri ambienti IT. Tutto ciò consente di intraprendere un percorso di innovazione digitale con grande flessibilità ed agilità. Per farlo nel migliore dei modi è opportuno adottare tecnologie che consentano di creare nuove opportunità e allo stesso tempo di gestire le sfide intrinseche in questi nuovi paradigmi. In Microsoft è stata ideata una soluzione specifica e prende il nome di Azure Arc. Uno dei benefici cruciali di Azure Arc è quello di estendere le pratiche di gestione e di governance di Azure anche ad ambienti differenti e di adottare soluzioni e tecniche che tipicamente vengono utilizzate in ambiente cloud anche per gli ambienti on-premises. In questo articolo viene approfondito come Microsoft ha recentemente migliorato in Azure Arc il processo di integrazione delle infrastrutture VMware vSphere e quali opportunità si possono cogliere da questa innovazione.

Perché adottare una strategia ibrida?

Tra le principali ragioni che portano i clienti a adottare una strategia ibrida troviamo:

  • Workload che non possono essere spostati nel cloud pubblico a causa dei requisiti normativi e di sovranità dei dati. Questo aspetto solitamente è comune in settori altamente regolamentati come servizi finanziari, ambienti sanitaria e governativi.
  • Alcuni workload, in particolare quelli che risiedono negli edge, richiedono basse latenze.
  • Molte aziende hanno fatto investimenti significativi nell’ambiente on-premises che desiderano massimizzare, quindi la scelta ricade nel modernizzare le applicazioni tradizionali che risiedono on-premises e le soluzioni adottate.
  • Garantire una maggiore resilienza.

Quali domande porsi per sfruttare e gestire al meglio ambienti ibridi e multi-cloud?

In situazioni dove si sta adottando una strategia ibrida oppure multi-cloud, le domande chiave che è opportuno porsi per trarre maggiori benefici sono:

  • Come posso visualizzare, governare e proteggere le risorse IT, indipendentemente da dove sono in esecuzione?
  • C’è la possibilità di portare l’innovazione del cloud anche nell’infrastruttura esistente?
  • Come è possibile modernizzare i datacenter locali adottando nuove soluzioni cloud?
  • Come estendere l’elaborazione e l’intelligenza artificiale all’edge per sbloccare nuovi scenari di business?

La risposta a tutte queste domande può essere… “adottando Azure Arc!”.

Figura 1 – Panoramica di Azure Arc

Molti sono i clienti che dispongono di infrastruttura basate su VMware e che allo stesso tempo stanno utilizzando servizi Azure. Azure Arc estende le possibilità offerte in ambito governance e management da Azure anche alle macchine virtuali presenti in ambienti VMware. Per migliorare ulteriormente questa esperienza di controllo e di gestione di tali risorse è stata introdotta una profonda integrazione tra Azure Arc e VMware vSphere.

Azure Arc-enabled VMware vSphere: come funziona?

Azure Arc-enabled VMware vSphere è una nuova funzionalità di Azure Arc pensata per i clienti con ambienti VMware vSphere on-premises oppure che adottano Azure VMware Solution.

Questa integrazione diretta di Azure Arc con VMware vSphere richiede di attivare un’appliance virtuale denominata “Arc bridge”. Questa risorsa permette di instaurare la connessione tra il server VMware vCenter e l’ambiente Azure Arc.

Grazie a questa integrazione è possibile effettuare l’onboarding in Azure di alcune oppure di tutte le risorse vSphere gestite dal proprio server vCenter quali: resource pool, cluster, host, datastore, network, template e macchine virtuali esistenti.

Figura 2 – VMware vCenter dal portale Azure

Terminata la fase di onboarding si aprono nuovi scenari di utilizzo che consentono di sfruttare i benefici riportati nel paragrafo seguente.

Benefici di Azure Arc-enabled VMware vSphere

Grazie a questa nuova integrazione è possibile ottenere i seguenti benefici:

  • Eseguire il provisioning di nuove macchine virtuali in ambienti VMware da Azure. La distribuzione delle macchine virtuali su VMware vSphere può essere fatta dal portale oppure utilizzando template ARM. La possibilità di poter descrivere l’infrastruttura, mediante processi di Infrastructure as Code, in modo coerente in Azure e negli ambienti on-premises è molto importante. Infatti, adottando template ARM, i team DevOps possono utilizzare pipeline CI/CD per eseguire il provisioning dei sistemi oppure per aggiornare le macchine virtuali VMware in modo contestuale ad altri aggiornamenti applicativi.

Figura 3 – Provisioning di una VM VMware dal portale Azure

  • Effettuare operazioni di manutenzione ordinaria sulle macchine virtuali direttamente dal portale Azure come: l’arresto, l’avvio, il riavvio, il ridimensionamento, l’aggiunta oppure l’aggiornamento di dischi e la gestione delle schede di rete.
  • Garantire un accesso self-service alle risorse vSphere tramite Azure Arc. Per gli amministratori che gestiscono ambienti vSphere, ciò significa che possono facilmente delegare un accesso self-service alle risorse VMware, governando e garantendo la conformità tramite controlli avanzati di governance di Azure ed Azure RBAC. Infatti, risulta possibile assegnare autorizzazioni granulari sulle risorse computazionali, di archiviazione, di rete e sui template.
  • Fornire un inventario delle macchine virtuali in ambienti vSphere distribuiti.
  • Eseguire e gestire su larga scala l’onboarding di ambienti vSphere nei servizi di management di Azure come ad esempio Azure Monitor Log Analytics ed Azure Policy Guest Configuration. Tale abilitazione permette di orchestrare l’installazione dell’agente specifico di Azure Arc (Connected Machine agent) direttamente da Azure.
  • Mantenere sincronizzate in Azure le modifiche apportate direttamente tramite vCenter, grazie alle funzionalità di rilevamento automatico.

Conclusioni

Grazie a questa nuova integrazione avanzata, i clienti possono avere la flessibilità di innovare, anche utilizzando il loro ambiente VMware esistente. Inoltre, mediante questo approccio è possibile avere un meccanismo efficace di controllo per gestire e governare in modo coerente tutte le risorse IT.

La gestione di ambienti Kubernetes con Azure Arc

Il principio che sta alla base di Azure Arc è quello di estendere le pratiche di gestione e di governance di Azure anche ad ambienti differenti e di adottare soluzioni e tecniche, che tipicamente vengono utilizzate in ambiente cloud, anche per gli ambienti on-premises. In questo articolo viene trattato come Azure Arc consente di effettuare il deploy e la configurazione delle applicazioni Kubernetes in modo omogeneo su tutti gli ambienti, adottando le moderne tecniche DevOps.

Grazie ad Azure Arc-enabled Kubernetes risulta possibile collegare e configurare cluster Kubernetes situati all’interno oppure all’esterno dell’ambiente Azure. Connettendo un cluster Kubernetes ad Azure Arc, questo:

  • Appare nel portale Azure con un ID di Azure Resource Manager ed un’identità gestita.
  • Viene inserito all’interno di una sottoscrizione di Azure e di un resource group.
  • Consente che gli vengano associati tag come per qualsiasi altra risorsa di Azure.

Per connettere un cluster Kubernetes ad Azure è necessaria l’installazione degli agenti sui vari nodi. Tali agenti:

  • Vengono eseguiti nel namespace Kubernetes “azure-arc”.
  • Gestiscono la connettività verso Azure.
  • Raccolgono i log e le metriche di Azure Arc.
  • Verificano le richieste di configurazione.

Figura 1 – Architettura dell’agent Azure Arc-enabled Kubernetes

Kubernetes abilitato per Azure Arc supporta il protocollo SSL per proteggere i dati in transito. Inoltre, per garantire la riservatezza dei dati inattivi, questi vengono archiviati in modo crittografato in un database Azure Cosmos DB.

Gli agenti Azure Arc sui sistemi Kubernetes non richiedono l’apertura di porte in ingresso sui sistemi firewall, ma è necessaria solamente l’abilitazione ad accedere in uscita verso specifici endpoint.

Per maggiori dettagli in merito e per la procedura da seguire per connettere un cluster Kubernetes ad Azure Arc è possibile consultare questa documentazione ufficiale di Microsoft.

Distribuzioni supportate

Azure Arc-enabled Kubernetes è possibile abilitarlo con qualsiasi cluster Kubernetes certificato “Cloud Native Computing Foundation (CNCF)”. Infatti, il team di Azure Arc ha collaborato con i principali partner del settore per convalidare la conformità delle loro distribuzioni Kubernetes con Azure Arc-enabled Kubernetes.

Scenari supportati

Abilitando Azure Arc-enabled Kubernetes risultano supportati i seguenti scenari:

  • Connessione di cluster Kubernetes in esecuzione in ambienti differenti da Azure, per eseguire operazioni di inventario, raggruppamento e tagging.
  • Distribuzione di applicazioni e gestione delle configurazioni basandosi su meccanismi GitOps. In relazione a Kubernetes, GitOps è la pratica di dichiarare lo stato desiderato delle configurazioni del cluster Kubernetes (deployments, namespaces, ecc.) in un repository Git. Questa dichiarazione è seguita da un polling e da una distribuzione basata su pull di queste configurazioni cluster utilizzando un operatore. Il repository Git può contenere:
    • Manifesti in formato YAML che descrivono qualsiasi risorsa Kubernetes valida, inclusi Namespace, ConfigMaps, Deployments, DaemonSets, ecc.
    • Chart Helm per la distribuzione delle applicazioni.

Flux, un popolare strumento open source di GitOps, può essere distribuito sul cluster Kubernetes per facilitare il flusso delle configurazioni da un repository Git ad un cluster Kubernetes.

Per maggiori dettagli sul workflow CI/CD utilizzando GitOps per i cluster Kubernetes abilitati ad Azure Arc è possibile fare riferimento a questa documentazione Microsoft.

  • Visualizzazione e monitor degli ambienti cluster utilizzando Azure Monitor for containers.
  • Protezione dalle minacce mediante Azure Defender for Kubernetes. I componenti dell’extension raccolgono gli audit logs di Kubernetes da tutti i nodi del control plane del cluster e li inviano al back-end di Azure Defender for Kubernetes nel cloud per ulteriori analisi. L’extension viene registrata con un workspace Log Analytics che viene utilizzato per la pipeline dei dati, ma gli audit log non vengono archiviati nel workspace di Log Analytics. L’extension consente di proteggere i cluster Kubernetes dislocati presso altri cloud provider, ma non permette di contemplare i loro servizi gestiti di Kubernetes.
  • Applicazione di impostazioni tramite Azure Policy for Kubernetes.
  • Creazione di location custom utilizzate come target per il deployment di Azure Arc-enabled Data Services, App Services su Azure Arc (che comprende web, function, e logic apps) ed Event Grid su Kubernetes.

Azure Arc-enabled Kubernetes supporta inoltre Azure Lighthouse, che consente ai provider di servizi di accedere al proprio tenant per gestire le sottoscrizioni ed i gruppi di risorse delegati dai clienti.

Conclusioni

Le realtà che devono operare in un ambiente ibrido grazie a questa tecnologia saranno in grado di ridurre al minimo l’effort di gestione dei workload containerizzati, estendendo servizi come Azure Policy ed Azure Monitor ai cluster Kubernetes dislocati in ambienti on-premises. Infine, mediante l’approccio GitOps, sarà possibile semplificare gli aggiornamenti alle configurazioni dei cluster in tutti gli ambienti, riducendo al minimo i rischi associati ai problemi di configurazione.

Azure Arc per la gestione dei sistemi server: benefici e scenari di utilizzo

Infrastrutture eterogenee, applicazioni basate su differenti tecnologie e soluzioni dislocate su diversi cloud pubblici sono elementi sempre più diffusi negli ambienti IT aziendali. Queste complessità, unite ad una continua evoluzione dei propri datacenter fanno emergere sempre più la necessità di visualizzare, governare e proteggere le risorse IT, indipendentemente da dove sono in esecuzione. In Microsoft, questa esigenza dei clienti è stata indirizzata progettando una soluzione che permette di gestire realtà complesse, offrendo inoltre la possibilità di portare l’innovazione del cloud anche utilizzando infrastrutture esistenti: questa soluzione prende il nome di Azure Arc. In particolare, Azure Arc for servers estende le possibilità offerte da Azure in ambito governance e management anche alle macchine fisiche ed ai sistemi virtuali che risiedono in ambienti differenti da Azure. In questo articolo verranno esplorati i principali benefici e gli scenari di implementazione che si possono contemplare adottando Azure Arc nella gestione dei sistemi server.

L’abilitazione dei server ad Azure Arc permette di gestire i server fisici e le macchine virtuali che risiedono all’esterno di Azure, sulla rete aziendale on-premises oppure presso altri cloud provider. Questa esperienza di gestione, valida sia per sistemi Windows sia per i sistemi Linux, è progettata per fornire coerenza con le metodologie di gestione delle macchine virtuali native che risiedono in ambiente Azure. Connettendo infatti una macchina ad Azure tramite Arc viene considerata a tutti gli effetti come una risorsa Azure. Ogni macchina connessa ha un ID specifico, viene inclusa in un resource group e beneficia dei costrutti standard di Azure.

Figura 1 – Azure Arc Management Overview

Principali scenari di utilizzo

La proiezione delle risorse server in Azure utilizzando Arc è un passaggio utile per usufruire delle soluzioni di management e di monitoring in seguito descritte.

Visibilità e organizzazione

In ambienti ibridi e multicloud, può essere particolarmente sfidante ottenere una visione centralizzata di tutte le risorse disponibili. Alcune di queste risorse sono in esecuzione in Azure, alcune in ambiente locale, presso le filiali oppure presso altri provider cloud. Collegando le risorse ad Azure Resource Manager tramite Azure Arc, è possibile organizzare, inventariare e gestire centralmente un’ampia gamma di risorse, inclusi server Windows e Linux, server SQL, cluster Kubernetes e servizi di Azure in esecuzione in Azure e all’esterno di Azure. Questa visibilità è possibile ottenerla direttamente dal portale Azure ed è possibile eseguire query specifiche utilizzando Azure Resource Graph.

Figura 2 – Azure Arc e risorse nel portale Azure

Gestione degli accessi

Con Azure Arc for servers è possibile fornire l’accesso ai sistemi tramite Azure role-based access control (Azure RBAC). Inoltre, in presenza di ambienti e tenant differenti, Azure Arc si integra anche con Azure Lighthouse. Questo scenario può essere di particolare interesse per i provider che offrono servizi gestiti a più clienti.

Monitor

Tramite VM Insights è possibile consultare i dati principali di performance, provenienti dal sistema operativo guest. Grazie alle potenti funzionalità di aggregazione dei dati e di filtering è possibile monitorare agilmente le performance per un numero molto elevato di sistemi ed individuare facilmente quelle che presentano problematiche di performance. Inoltre, si ha la possibilità di generare una mappa con le interconnessioni presenti tra i vari componenti che risiedono su sistemi differenti. Le mappe mostrano come le VMs ed i processi interagiscono tra loro e possono identificare eventuali dipendenze da servizi di terze parti. La soluzione permette anche di controllare eventuali errori di connessione, conteggia le connessioni in tempo reale, i byte di rete inviati e ricevuti dai processi e le latenze riscontrare a livello di servizio.

Figura 3 – Monitoring: Performance

Figura 4 – Monitoring: Map

Azure Policy guest configurations

Le guest Configuration Policy consentono di controllare le impostazioni all’interno di un sistema, sia per le macchine virtuali in esecuzione in ambiente Azure sia per le macchine “Arc Connected”. La convalida viene eseguita dal client e dall’estensione Guest Configuration per quanto riguarda:

  • Configurazione del sistema operativo
  • Configurazione oppure presenza di applicazioni
  • Impostazioni dell’ambiente

Al momento, la maggior parte delle Guest Configuration Policy di Azure permettono solamente di effettuare controlli sulle impostazioni all’interno della macchina, ma non applicano configurazioni. Per maggiori informazioni rispetto a questo scenario è possibile consultare l’articolo Azure Governance: come controllare le configurazioni dei sistemi in ambienti ibridi e multicloud.

Inventory

Questa funzionalità consente di recuperare informazioni di inventario relative a: software installati, files, chiavi di Registry in ambiente Windows, Servizi Windows e Daemons Linux. Il tutto può essere consultato facilmente direttamente dal portale Azure.

Change Tracking

La funzionalità di Change Tracking consente di monitorare le modifiche apportate ai sistemi relativamente a Daemons, File, Registry, Software e Servizi Windows. Tale funzionalità può risultare molto utile in particolare per diagnosticare problemi specifici e per abilitare segnalazioni a fronte di cambiamenti non attesi.

Figura 5 – Change Tracking e Inventory

Update Management

La soluzione di Update Management consente di avere una visibilità complessiva sulla compliance degli update sia per sistemi Windows sia per sistemi Linux. La solution non è solo utile a fini di consultazione, ma consente anche di schedulare dei deployment per l’installazione degli update all’interno di specifiche finestre di manutenzione.

Figura 6 – Update Management

Azure Defender
La proiezione delle risorse server in Azure utilizzando Arc è un passaggio utile per garantire che tutte le macchine dell’infrastruttura siano protette da Azure Defender for Server. Analogamente a una macchina virtuale di Azure, sarà inoltre necessario distribuire l’agente di Log Analytics nel sistema di destinazione. Per semplificare il processo di onboarding questo agente viene distribuito utilizzando la VM extension, e questo è uno dei vantaggi dell’utilizzo di Arc.

Una volta che l’agente di Log Analytics è stato installato e connesso ad un workspace utilizzato da ASC, la macchina sarà pronta per utilizzare e beneficiare delle varie funzionalità di sicurezza offerte nel piano Azure Defender for Servers.

Strumenti di Deployment

I deployment possono essere semplificati grazie all’utilizzo di Azure Automation State Configuration e delle Azure VM extensions. Questo permette di contemplare configurazioni post-deployment oppure l’installazione del software utilizzando la Custom Script Extension.

Conclusioni

Mantenere il controllo e gestire la sicurezza dei workload in esecuzione on-premises, in Azure e su altre piattaforme cloud può risultare particolarmente sfidante. Grazie ad Azure Arc for Servers è possibile estendere facilmente i servizi di management e di monitoring tipici di Azure anche ai workloads che risiedono all’esterno dell’ambiente Azure. Inoltre, Azure Arc consente di ottenere informazioni dettagliate e di organizzare le varie risorse IT in un’unica console centralizzata, utile per gestire e controllare efficacemente tutto il proprio ambiente IT.

Come estendere la protezione di Azure Security Center a tutte le risorse tramite Azure Arc

Azure Security Center (ASC) è stato originariamente sviluppato con la volontà di diventare lo strumento di riferimento per proteggere le risorse in ambiente Azure. La necessità molto sentita dei clienti di proteggere le risorse dislocate anche in ambienti differenti da Azure ha portato ad una evoluzione della soluzione che, grazie all’integrazione con Azure Arc, permette di estendere gli strumenti di protezione e di gestione della sicurezza a qualsiasi infrastruttura. In questo articolo viene spiegato come Azure Security Center ed Azure Arc consentono di proteggere le risorse non Azure situate on-premises oppure su altri cloud provider, come macchine virtuali, servizi Kubernetes e risorse SQL.

L’adozione di Azure Defender utilizzando i principi di Azure Arc

Azure Arc permette di gestire i workload che risiedono all’esterno di Azure, sulla rete aziendale on-premises oppure presso un altro cloud provider. Tale esperienza di gestione è progettata per fornire coerenza con le metodologie di management native di Azure.

Grazie al fatto che Azure Security Center ed Azure Arc possono essere utilizzati in modo congiunto, si ha la possibilità di offrire una protezione avanzata per tre differenti scenari:

Figura 1 – Scenari di protezione

Abilitando in Azure Security Center la protezione di Azure Defender dei workload a livello di subscription è possibile contemplare anche le risorse ed i carichi di lavoro che risiedono in ambienti ibridi e multicloud, il tutto in modo estremamente semplice grazie ad Azure Arc.

Azure Defender per i sistemi server abilitati ad Arc

Connettendo una macchina server ad Azure tramite Arc viene considerata a tutti gli effetti come una risorsa Azure. Ogni macchina connessa ha un ID specifico, viene inclusa in un resource group e beneficia dei costrutti standard di Azure come le Azure Policy e l’applicazione dei tag. Questo vale sia per sistemi Windows sia per i sistemi Linux.

Per offrire questa esperienza è richiesta l’installazione dell’agente specifico di Azure Arc su ogni macchina che si prevede di connettere ad Azure (“Azure Connected Machine”).

L’Azure Arc Connected Machine agent è composto dai seguenti componenti logici:

  • L’Hybrid Instance Metadata service (HIMDS) che gestisce la connessione ad Azure e l’identità di Azure della macchina connessa.
  • Il Guest Configuration agent che fornisce le funzionalità di In-Guest Policy e Guest Configuration.
  • L’Extension Manager agent che gestisce i processi di installazione, disinstallazione ed aggiornamento delle estensioni della macchina.

Figura 2 – Componenti dell’agente Azure Arc

Il Connected Machine agent richiede una comunicazione sicura in uscita verso Azure Arc sulla porta TCP  443.

Questo agente non fornisce altre funzionalità e non sostituisce l’agente di Azure Log Analytics, il quale rimane necessario quando si desidera monitorare in modo proattivo il sistema operativo ed i carichi di lavoro in esecuzione sulla macchina.

Per maggiori informazioni sull’installazione di Azure Arc è possibile consultare questo documento ufficiale Microsoft.

I server abilitati per la soluzione Azure Arc possono beneficiare di diverse funzionalità legate ad Azure Resource Manager come Tags, Policies e RBAC, oltre che ad alcune funzionalità relative ad Azure Management.

L’attivazione di Azure Defender for Server con Azure Arc

La proiezione delle risorse server in Azure utilizzando Arc è un passaggio utile per garantire che tutte le macchine dell’infrastruttura siano protette da Azure Defender for Server. Analogamente a una macchina virtuale di Azure, sarà inoltre necessario distribuire l’agente di Log Analytics nel sistema di destinazione. Per semplificare il processo di onboarding questo agente viene distribuito utilizzando la VM extension, e questo è uno dei vantaggi dell’utilizzo di Arc.

Una volta che l’agente di Log Analytics è stato installato e connesso ad un workspace utilizzato da ASC, la macchina sarà pronta per utilizzare e beneficiare delle varie funzionalità di sicurezza offerte nel piano Azure Defender for Servers.

Per ogni risorsa è possibile visualizzare lo stato dell’agente e le relative raccomandazioni di sicurezza correnti:

Figura 3 – Azure Arc Connected Machine in ASC

Nel caso ci sia la necessità di effettuare l’onboarding in Azure Defender di un server non Azure con una versione del sistema operativo non ancora supportata dall’agente di Azure Arc, è comunque possibile eseguire l’onboarding installando solamente l’agente Log Analytics sulla macchina.

Le icone presenti nel portale Azure consentono di distinguere facilmente le differenti risorse:

Figura 4 – Icone delle differenti risorse presenti in ASC

 

Azure Defender per le risorse Kubernetes abilitate ad Arc

Azure Defender for Kubernetes permette di proteggere anche i cluster dislocati on-premises con le stesse funzionalità di rilevamento delle minacce offerte per i cluster Azure Kubernetes Service (AKS).

Per tutti i cluster Kubernetes differenti da AKS, risulta necessario connettere l’ambiente cluster ad Azure Arc. Una volta connesso l’ambiente cluster, Azure Defender for Kubernetes può essere attivato come cluster extension sulle risorse Kubernetes abilitate per Azure Arc.

Figura 5 – Interazione tra Azure Defender for Kubernetes ed il cluster Kubernetes abilitato per Azure Arc

I componenti dell’extension raccolgono gli audit logs di Kubernetes da tutti i nodi del control plane del cluster e li inviano al back-end di Azure Defender for Kubernetes nel cloud per ulteriori analisi. L’extension viene registrata con un workspace Log Analytics che viene utilizzato per la pipeline dei dati, ma gli audit log non vengono archiviati nel workspace di Log Analytics.

L’extension consente anche proteggere i cluster Kubernetes dislocati presso altri cloud provider, ma non permette di contemplare i loro servizi gestiti di Kubernetes.

Azure Defender per le risorse SQL Server abilitate ad Arc

Azure Defender for SQL permette di monitorare costantemente le implementazioni di SQL Server per rilevare minacce e vulnerabilità note. Anche queste funzionalità sono fruibili non solo per macchine virtuali in Azure, ma anche per SQL Server attivati in ambiente on-premises e in deployment multicloud. I SQL Server abilitati ad Azure Arc fanno parte anche di Azure Arc for servers. Per abilitare gli Azure services, l’istanza di SQL Server deve essere registrata con Azure Arc usando il portale di Azure ed un apposito script di registrazione. Dopo la registrazione, l’istanza verrà rappresentata su Azure come una risorsa SQL Server – Azure Arc. Le proprietà di questa risorsa riflettono un sottoinsieme delle impostazioni di configurazione di SQL Server.

Figura 6 – Diagramma che illustra l’architettura di Azure Arc per le risorse SQL Server


Conclusioni

Gestire la sicurezza e mantenere il controllo dei workload in esecuzione on-premises, in Azure e su altre piattaforme cloud può risultare particolarmente sfidante. Grazie ad Azure Arc è possibile estendere facilmente la copertura di Azure Defender ai carichi di lavoro che risiedono all’esterno dell’ambiente Azure. Inoltre, Azure Security Center consente di ottenere informazioni dettagliate sulla sicurezza del proprio ambiente ibrido in un’unica console centralizzata, utile per controllare efficacemente la security della propria infrastruttura IT.

Azure Governance: come controllare le configurazioni dei sistemi in ambienti ibridi e multicloud

Diverse sono le realtà che stanno investendo in tecnologie ibride e multicloud per ottenere una elevata flessibilità, che consente di innovare e di soddisfare le esigenze aziendali in continua evoluzione. In questi scenari, ai clienti si presenta la sfida di utilizzare in modo efficiente le risorse IT, al fine di raggiungere al meglio i propri obiettivi di business, attuando un processo di IT governance strutturato. Questo risultato è possibile raggiungerlo più agilmente se si dispone di soluzioni che, in modo centralizzato, consentono di inventariare, organizzare ed applicare delle policy di controllo sulle proprie risorse IT ovunque si trovino. La soluzione Azure Arc coinvolge diverse tecnologie con l’obiettivo di sostenere scenari ibridi e multicloud, dove i servizi e i principi di gestione di Azure vengono estesi a qualsiasi infrastruttura. In questo articolo si approfondirà come, grazie all’adozione delle Azure Guest Configuration Policy è possibile controllare le configurazioni dei sistemi in esecuzione in Azure, nei datacenter locali oppure presso altri cloud provider.

Il principio alla base di Azure Arc

Il principio che sta alla base di Azure Arc è quello di estendere le pratiche di gestione e di governance di Azure anche ad ambienti differenti e di adottare soluzioni tipicamente cloud, come tecniche DevOps (infrastructure as code), anche per gli ambienti on-premises e multicloud.

Figura 1 – Panoramica di Azure Arc

L’abilitazione dei sistemi ad Azure Arc

L’abilitazione dei server ad Azure Arc permette di gestire i server fisici e le macchine virtuali che risiedono all’esterno di Azure, sulla rete aziendale on-premises oppure presso un altro cloud provider. Questo vale sia per sistemi Windows sia per i sistemi Linux. Questa esperienza di gestione è progettata per fornire coerenza con le metodologie di gestione delle macchine virtuali native di Azure. Connettendo infatti una macchina ad Azure tramite Arc viene considerata a tutti gli effetti come una risorsa Azure. Ogni macchina connessa ha un ID specifico, viene inclusa in un resource group e beneficia dei costrutti standard di Azure come le Azure Policy e l’applicazione dei tag.

Per offrire questa esperienza è richiesta l’installazione dell’agente specifico di Azure Arc su ogni macchina che si prevede di connettere ad Azure (“Azure Connected Machine”). Attualmente sono supportati i seguenti sistemi operativi:

  • Windows Server 2008 R2, Windows Server 2012 R2 oppure superiore (sono compresi i Server Core)
  • Ubuntu 16.04 and 18.04 LTS (x64)
  • CentOS Linux 7 (x64)
  • SUSE Linux Enterprise Server (SLES) 15 (x64)
  • Red Hat Enterprise Linux (RHEL) 7 (x64)
  • Amazon Linux 2 (x64)
  • Oracle Linux 7

L’Azure Arc Connected Machine agent è composto dai seguenti componenti logici:

  • L’Hybrid Instance Metadata service (HIMDS) che gestisce la connessione ad Azure e l’identità di Azure della macchina connessa.
  • Il Guest Configuration agent che fornisce le funzionalità di In-Guest Policy e Guest Configuration.
  • L’Extension Manager agent che gestisce i processi di installazione, disinstallazione ed aggiornamento delle estensioni della macchina.

Figura 2 – Componenti dell’agente Azure Arc

Il Connected Machine agent richiede una comunicazione sicura in uscita verso Azure Arc sulla porta TCP  443.

Questo agente non fornisce altre funzionalità e non sostituisce l’agente di Azure Log Analytics, il quale rimane necessario quando si desidera monitorare in modo proattivo il sistema operativo ed i carichi di lavoro in esecuzione sulla macchina.

Per maggiori informazioni sull’installazione di Azure Arc è possibile consultare questo documento ufficiale Microsoft.

I server abilitati per la soluzione Azure Arc possono beneficiare di diverse funzionalità legate ad Azure Resource Manager come Tags, Policies e RBAC, oltre che ad alcune funzionalità relative ad Azure Management.

Figura 3 – Azure Management per tutte le risorse IT

Guest Configuration Policy di Azure

Le Guest Configuration Policy permettono di controllare le impostazioni all’interno di una macchina, sia per le macchine virtuali in esecuzione in ambiente Azure che per le macchine “Arc Connected”. La convalida viene eseguita dal client e dall’estensione Guest Configuration per quanto riguarda:

  • Configurazione del sistema operativo
  • Configurazione oppure presenza di applicazioni
  • Impostazioni dell’ambiente

Al momento, la maggior parte delle Guest Configuration Policy di Azure permettono solamente di effettuare controlli sulle impostazioni all’interno della macchina, ma non applicano configurazioni. L’eccezione è una policy incorporata di configurazione del Time Zone del sistema operativo per le macchine Windows.

Requisiti

Prima di poter controllare le impostazioni all’interno di una macchina, tramite le Guest Configuration Policy, è necessario:

  • Abilitare un’extension sulla macchina virtuale di Azure, necessaria per scaricare le assegnazioni delle policy assegnate e le corrispondenti configurazioni. Questa extension non è richiesta per macchine “Arc Connected” in quanto è inclusa nell’agente Arc.
  • Fare in modo che la macchina abbia una system-managed identity, utilizzata per il processo di autenticazione durante la lettura e la scrittura nel servizio Guest Configuration.

Funzionamento

Azure fornisce built-in nella piattaforma delle specifiche initiatives e un numero elevato di Guest Configuration Policy, ma è possibile crearne anche delle personalizzate sia in ambiente Windows, sia in ambiente Linux.

L’assegnazione delle Guest Configuration policy funziona allo stesso modo delle Azure Policy standard, quindi è possibile raggrupparle in initiative. Anche per le Guest Configuration Policy sono configurabili dei parametri specifici ed esiste almeno un parametro che consente di includere i server abilitati ad Azure Arc. Nel momento in cui si possiede la definizione della policy desiderata, è possibile assegnarla a una subscription ed eventualmente in modo più circoscritto ad un Resource Group specifico. Si ha inoltre la possibilità di escludere determinate risorse dall’applicazione della policy.

In seguito all’assegnazione è possibile valutare lo stato di compliance nel dettaglio direttamente dal portale Azure.

All’interno della macchina, il Guest Configuration agent utilizza strumenti locali per eseguire l’audit delle configurazioni:

Il Guest Configuration agent verifica la presenza di assegnazioni di policy guest nuove oppure modificate ogni 5 minuti e una volta ricevuta l’assegnazione le impostazioni vengono controllate a intervalli di 15 minuti.

Costo della soluzione

Il costo delle Guest Configuration Policy di Azure si basa sul numero di server registrati al servizio e che hanno una o più configurazioni guest assegnate. Qualsiasi altro tipo di Azure Policy che non si basa sulla configurazione guest viene offerto senza costi aggiuntivi, comprese le estensioni della macchina virtuali per abilitare servizi come Azure Monitor ed Azure Security Center oppure le policy di auto tagging. La fatturazione è ripartita su base oraria e contempla anche le funzionalità di change tracking presenti tramite Azure Automation. Per maggiori dettagli sui costi è possibile consultare la pagina ufficiale Microsoft.

Conclusioni

Gli ambienti IT sono in continua evoluzione e spesso devono erogare applicazioni critiche per il business aziendale basate su differenti tecnologie, attive su infrastrutture eterogenee e che in alcuni casi utilizzano soluzioni erogate presso differenti cloud pubblici. L’adozione di un processo di IT governance strutturato è più semplice anche grazie alle Guest Configuration Policy e alle potenzialità di Azure Arc, che permettono di controllare e sostenere più facilmente ambienti ibridi e multicloud.