Archivi categoria: Microsoft Azure

Azure Multi-Factor Authentication: Introduzione alla Soluzione

Per rendere più sicuro l’accesso ai dati e alle applicazioni critiche può essere necessario prevedere l’autenticazione a più fattori che generalmente richiede l’utilizzo di almeno due dei seguenti metodi di verifica:

 

  • Qualcosa che si conosce (tipicamente una password).
  • Qualcosa che si possiede (un dispositivo unico e non facilmente duplicabile, come ad esempio un telefono).
  • Un sistema di riconoscimento biometrico che ha lo scopo di identificare una persona sulla base di una o più caratteristiche biologiche o comportamentali (biometria).

 

Microsoft consente di adottare una soluzione di autenticazione a due fattori utilizzando l’Azure Multi-Factor Authentication (MFA) che prevede l’adozione di un secondo metodo di verifica dell’identità durante il processo di autenticazione. Utilizzando questa soluzione sono configurabili i seguenti fattori di autenticazione aggiuntivi:

 

  • Chiamata telefonica: viene effettuata una chiamata verso il telefono registrato per l’utenza. In questo caso verrà richiesto all’utente di rispondere alla chiamata e di verificare l’accesso premendo il pulsante # oppure inserendo un codice PIN.
  • Messaggio di testo (SMS): viene inviato al cellulare dell’utente un SMS che contiene un codice pin di 6 cifre il quale dovrà essere inserito durante il processo di autenticazione.
  • Notifica tramite Mobile App: sullo smartphone dell’utente viene inviata tramite Mobile App una richiesta di verifica che deve essere approvata dall’utente per completare il processo di autenticazione.
  • Codice di verifica tramite Mobile App: nella Mobile App presente sullo smartphone dell’utente viene generato un codice di 6 cifre ogni 30 secondi. L’utente dovrà quindi inserire il codice più recente nel momento in cui effettua l’autenticazione.
  • Token OATH di terze parti: c’è la possibilità di configurare Azure Multi-Factor Authentication per accettare metodi di verifica messi a disposizione da soluzione di terze parti.

 

L’Azure Multi-Factor Authentication (MFA) prevede due possibili modelli di deployment:

 

  • MFA come soluzione interamente nel Cloud.
  • Sistema MFA installato e configurato su sistemi on-premises.

 

Per individuare il modello di deployment più opportuno è necessario prendere in considerazione diversi aspetti: cosa sto mettendo in sicurezza, dove si trovano gli utenti che devono accedere alla soluzione e di quali funzionalità ho realmente bisogno.

 

Cosa si sta Tentando di Proteggere?

Questa è sicuramente la prima domanda che occorre porsi la cui risposta ci può già indirizzare a un modello di deployment specifico. Nel caso infatti ci sia la necessità di abilitare il doppio fattore di autenticazione per applicazioni IIS non pubblicate tramite Azure AD App Proxy oppure soluzioni di accesso remoto (VPN oppure Remote Desktop Gateway) è necessario utilizzare il server Azure MFA implementato sui sistemi on-premises.

 

Figura 1 – Cosa si intende proteggere tramite MFA

 

Dove si Trovano gli Utenti?

Un altro aspetto importante da tenere in considerazione è dove si trovano gli utenti sulla base del modello di Identity adottato, come mostra la figura 2.

 

Figura 2 – Ubicazione degli utenti

 

Quali funzionalità sono necessarie?

A seconda del modello di deployment scelto (MFA nel cloud oppure MFA locale) sono disponibili funzionalità differenti che ci potrebbero far optare per una scelta piuttosto che per un’altra, come mostra la figura 3.

 

Figura 3 – Funzionalità MFA disponibili nei due modelli

 

Requisiti necessari per l’utilizzo della MFA

Per poter utilizzare l’Azure Multi-Factor Authentication (MFA) è necessario avere accesso a una subscription Azure. Nel caso si volesse testare il servizio è possibile eventualmente utilizzare una subscription di trial di Azure.

 

I requisiti hardware per quanto riguarda l’Azure Multi-Factor Authentication Server sono minimi (200 MB di spazio disco e 1 GB di RAM), mentre sono richieste le seguenti caratteristiche software:

 

  • Sistema Operativo: Windows Server 2008 R2 o superiore
  • Microsoft .NET 4.0 Framework
  • IIS 7.0 o superiore se si vuole installare lo User Portal oppure il Web Service SDK

 

Ogni server MFA deve essere in grado di comunicare sulla porta 443 in uscita verso i seguenti indirizzi web:

 

  • https://pfd.phonefactor.net
  • https://pfd2.phonefactor.net
  • https://css.phonefactor.net

 

Inoltre nel caso ci siano policy firewall di blocco in uscita verso la porta 443 è necessario aprire i range di indirizzi IP documentati nel paragrafo “Azure Multi-Factor Authentication Server firewall requirements” della documentazione ufficiale Microsoft.

 

Azure Multi-Factor Authentication nel cloud

L’abilitazione della MFA nello scenario cloud è molto semplice ed avviene per utente. Per farlo è necessario accedere al servizio Azure Active Directory, figura 4, dal portale Azure:

 

Figura 4 – Step 1: abilitazione MFA nel cloud

 

Dopo aver selezionato la Directory, nella sezione “Users and groups” selezionare “Multi-Factor Authentication”:

 

Figura 5 – Step 2: abilitazione MFA nel cloud

 

Si verrà rediretti su un altro portale dove selezionando l’utente specifico, figura 6, è possibile abilitare la MFA:

 

Figura 6 – Step 3: abilitazione MFA nel cloud

 

Giunti a questo punto l’utente sarà abilitato all’utilizzo della MFA. La stessa operazione può essere fatta anche selezionando più utenti contemporaneamente e dallo stesso portale è possibile configurare le varie impostazioni dell’Azure Multi-Factor Authentication. Per maggiori dettagli a riguardo vi invito a consultare la documentazione ufficiale Microsoft.

 

La stessa operazione può essere portata a termine anche utilizzando i cmdlet Powershell per Azure AD i quali ci consentono facilmente di effettuare l’abilitazione della MFA per più utenti con poche righe di codice, come riportato nell’esempio seguente:

 

$users = “user1@ugisystemcenter.org”,”user2@ugisystemcenter.org”,”user3@ugisystemcenter.org”

foreach ($user in $users)

{

    $st = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement

    $st.RelyingParty = “*”

    $st.State = “Enabled”

    $sta = @($st)

    Set-MsolUser -UserPrincipalName $user -StrongAuthenticationRequirements $sta

}

 

Azure Multi-Factor Authentication on-premises

Il deployment on-premises dell’Azure Multi-Factor Authentication Server richiede di effettuare il download del setup di installazione direttamente dal portale Azure. Nel caso si voglia licenziare Azure Multi-Factor Authentication come servizio autonomo con opzioni di fatturazione per utente e per autenticazione è necessario creare dal portale Classic di Azure un nuovo Multi-Factor Auth Provider (tale funzionalità presto sarà disponibile anche sul nuovo portale Azure).

 

Figura 7 – Creazione nuovo Multi-Factor Auth Providers

 

Selezionando il pulsante Manage si viene rediretti verso il portale dell’Azure Multi-Factor Authentication, figura 8, dal quale è possibile effettuare il donwload del setup e generare le credenziali di attivazione del servizio.

 

Figura 8 – Download del Multi-Factor Authentication Server e generazione credenziali

 

Nel caso si voglia utilizzare la licenza in bundle a Enterprise Mobility Suite, Azure AD Premium oppure Enterprise Cloud Suite non è necessario creare un Multi-Factor Auth Provider ma è sufficiente accedere al portale dell’Azure Multi-Factor Authentication per effettuare direttamente il download del setup.

 

Dopo essere entrati in possesso del setup è possibile effettuare l’installazione dell’Azure MFA Server. Durante il setup verrà richiesto solamente il percorso di installazione, figura 9.

 

Figura 9 – Setup Azure MFA Server

 

Figura 10 – Setup Azure MFA Server

 

Giunti a questo punto è necessario eseguire il Multi-Factor Authentication Server appena installato che ci guiderà nella procedura di attivazione.

 

Figura 11 – Applicazione Multi-Factor Authentication Server

 

Figura 12 – Step 1: Procedura attivazione Multi-Factor Authentication Server

 

Nella schermata seguente è necessario inserire le credenziali di accesso che vengono generate dal Portale dell’Azure Multi-Factor Authentication (vedi Figura 8).

 

Figura 13 – Step 2: Procedura attivazione Multi-Factor Authentication Server

 

Dopo aver completato l’attivazione del primo server Azure MFA è possibile avviare il Wizard di configurazione, figura 14, per attivare la replica tra più server Azure MFA e configurare il servizio in alta disponibilità.

 

Figura 14 – Wizard di configurazione Multi-Server MFA

 

Nello scenario dove il Multi-Factor Authentication Server è abilitato su più sistemi, i server Azure MFA comunicano tra di loro attraverso chiamate RPC e per fare in modo che il tutto avvenga in modo sicuro devono autenticarsi in modo reciproco. Tale processo di autenticazione può avvenire sia tramite l’appartenenza a un gruppo di security specifico in Active Directory (denominato Phone Factor Admins) sia tramite l’utilizzo di certificati SSL.

 

Ora che il server Azure MFA è stato configurato c’è la possibilità di importare facilmente gli utenti da Active Directory, figura 15, e su questi abilitare il doppio fattore di autenticazione desiderato.

 

Figura 15 – Import degli utenti da Active Directory

 

Nello scenario di utilizzo dell’Azure Multi-Factor Authentication (MFA) Server è bene specificare che i dati relativi agli utenti vengono salvati sui sistemi on-premises e nessun dato viene memorizzato in modo persistente sul cloud. Infatti nel momento in cui un utente effettua il processo di autenticazione a più fattori il server Azure MFA invia i seguenti dati verso il servizio Cloud Azure MFA per effettuare la verifica e a fini di reportistica:

 

  • ID univoco dell’utente (username oppure ID del server MFA interno)
  • Nome e Cognome (opzionali)
  • Indirizzo Email (opzionale)
  • Numero di telefono (in caso di chiamata Telefonica oppure di invio SMS)
  • Device token (quando viene utilizzata l’autenticazione tramite mobile app)
  • Metodo di autenticazione
  • Esito autenticazione
  • Nome e inidirizzo IP del server Azure MFA
  • Client IP (se disponibile)
  • Esito verifica (successo o negata) e motivazione in caso di deny

 

Oltre all’import mirato dei diversi utenti da Active Directory sui quali si vuole abilitare il doppio fattore di autenticazione è possibile integrare il server Azure MFA con il servizio Active Directory e impostare una importazione mirata e schedulata degli utenti secondo determinati criteri. Per maggiori dettagli in merito è possibile consultare la documentazione ufficiale Integrazione di directory tra il server Azure MFA e Active Directory.

 

Modelli di Licensing della soluzione

Azure Multi-Factor Authentication è disponibile come servizio autonomo, con opzioni di fatturazione per utente e per autenticazione, oppure in bundle con Azure Active Directory Premium, Enterprise Mobility Suite e Enterprise Cloud Suite. Azure Multi-Factor Authentication è disponibile attraverso un contratto Enterprise Microsoft, il programma di licenza Open Volume, il programma Cloud Solution Provider e un contratto Direct, come modello annuale per utente. Il servizio è anche disponibile con un modello in base al consumo per utente e per autenticazione, fatturato ogni mese secondo l’Azure monetary commitmen.

 

Per maggiori informazioni sui costi della soluzione è possibile consultare il seguente documento: Prezzi di Multi-Factor Authentication.

 

Conclusioni

Azure Multi-Factor Authentication è una soluzione semplice da usare, scalabile e affidabile che offre la possibilità di introdurre un secondo metodo di validazione in modo che gli utenti siano in grado di accedere in modo più sicuro ai propri dati e alle applicazioni, sia esse presenti on-premises che in ambienti cloud. Per chi è interessato a provare il servizio può facilmente attivare una subscription Azure gratuitamente accedendo alla Free Trial di Azure.

OMS Log Analytics: come effettuare il monitor del networking di Azure

All’interno di Log Analytics c’è la possibilità di abilitare delle solution specifiche che consentono di effettuare il monitor di alcuni componenti dell’infrastruttura di rete presente in Microsoft Azure.

Tra queste solution troviamo Network Performance Monitor (NPM) la quale è stata approfondita nell’articolo Monitorare le performance di rete con la nuova solution di OMS e che si presta molto bene anche per monitorare lo stato di salute, la disponibilità e la raggiungibilità del networking di Azure. Sono inoltre attualmente disponibili nella gallery di Operations Management Suite le seguenti solution che arricchiscono le potenzialità di monitoring lato OMS:

  • Azure Application Gateway Analytics
  • Azure Network Security Group Analytics

Abilitazione delle Solution

Accedendo al portale OMS è possibile aggiungere facilmente queste solution presenti nella gallery seguendo gli step che trovate documentati nel seguente articolo: Aggiungere soluzioni di gestione di Operations Management Suite (OMS).

Figura 1 – Solution Azure Application Gateway Analytics

Figura 2 – Solution Azure Network Security Group Analytics

Azure Application Gateway Analytics

L’Azure Application Gateway è un servizio che è possibile configurare in ambiente Azure in grado di fornire funzionalità di Application Delivery garantendo un bilanciamento applicativo layer 7. Per ottenere maggiori informazioni relative all’Azure Application Gateway è possibile consultare la documentazione ufficiale.

Per poter collezionare i log di diagnostica in Log Analytics è necessario posizionarsi nel portale Azure sulla risorsa Application Gateway che si intende monitorare e nella sezione Diagnostics logs selezionare l’invio dei log verso il workspace Log Analytics opportuno:

Figura 3 – Application Gateway Diagnostics settings

Per l’Application Gateway è possibile selezionare la raccolta dei seguenti log:

  • Log relativi agli accessi effettuati
  • Dati di performance
  • Firewall log (nel caso l’Application Gateway abbia il Web Application Firewall abilitato)

Dopo aver completato questi semplici passaggi la solution OMS installata consente di consultare facilmente i dati inviati dalla platform:

Figura 4 – Azure Application Gateway Analytics Overview nel portale OMS

All’interno della solution è possibile visualizzare un sommario delle informazioni raccolte e selezionando i singoli grafici si accede ai dettagli relativi alle categorie seguenti:

  • Application Gateway Access log
    • Errori client e server riscontrati nei log di accesso dell’Application Gateway
    • Richieste ricevute dall’Application Gateway per ora
    • Richieste fallite per ora
    • Errori rilevati per user agent

Figura 5 – Application Gateway Access log

  • Application Gateway performance
    • Stato di salute degli host che rispondono alle richieste dell’Application Gateway
    • Richieste fallite dell’Application Gateway espresso come numero massimo e con il 95° percentile

Figura 6 – Application Gateway performance

  • Application Gateway Firewall log

 

Azure Network Security Group Analytics

In Azure è possibile controllare le comunicazioni di rete tramite i Network Security Group (NSG) i quali aggregano una serie di regole (ACL) per consentire oppure negare il traffico di rete basandosi sulla direzione (in ingresso o in uscita), il protocollo, l’indirizzo e la porta sorgente oppure l’indirizzo e la porta di destinazione. I NSG vengono utilizzati per controllare e proteggere le virtual network oppure direttamente le interfacce di rete. Per tutti i dettagli relativi ai NSG è possibile consultare la documentazione ufficiale Microsoft.

Per poter collezionare i log di diagnostica dei Network Security Group in Log Analytics è necessario posizionarsi nel portale Azure sulla risorsa Network Security Group che si intende monitorare e nella sezione Diagnostics logs selezionare l’invio dei log verso il workspace Log Analytics opportuno:

Figura 7 – Abilitazione diagnostica NSG

Figura 8 – Configurazione diagnostica NSG

Sui Network Security Group è possibile raccogliere le seguenti tipologie di log:

  • Eventi
  • Contatori relativi alle rule

Giunti a questo punto nell’home page del portale OMS è possibile selezionare il tile di Overview della solution Azure Network Security Group Analytics per accedere ai dati dei NSG raccolti dalla platform:

Figura 9 – Azure Network Security Group Analytics Overview nel portale OMS

La solution mette a disposizione un summary dei log raccolti suddividendoli nelle seguenti categorie:

  • Network security group blocked flows
    • Regole del Network Security Group con traffico bloccato
    • Indirizzamenti di rete con regole di traffico bloccato

Figura 10 – Network security group blocked flows

  • Network security group allowed flows
    • Regole del Network security group con traffico consentito
    • Indirizzamenti di rete con regole di traffico consentito

Figura 11 – Network security group allowed flows

La metodologia di invio dei log di diagnostica degli Application Gateway e dei Network Security Group di Azure verso Log Analytics è cambiata recentemente introducendo i seguenti vantaggi:

  • La scrittura dei log in Log Analytics avviene direttamente senza la necessità di utilizzare degli storage account come repository. Si può comunque scegliere di salvare i log di diagnostica sugli storage account, ma non è necessario per l’invio dei dati verso OMS.
  • La latenza tra il tempo di generazione dei log e la loro consultabilità in Log Analytics è stata ridotta.
  • Sono stati semplificati gli step necessari per la configurazione.
  • Tutti le informazioni di diagnostica di Azure sono state uniformate come formato.

Conclusioni

Grazie a una sempre più completa integrazione tra Azure e Operations Management Suite (OMS) è possibile monitorare e controllare lo stato dei componenti dell’infrastruttura di rete realizzata su Azure in modo completo ed efficace, il tutto con passaggi semplici e intuitivi. Questa integrazione della platform Azure con OMS è sicuramente destinata ad arricchirsi con nuove soluzioni specifiche anche per altri componenti. Per chi è interessato ad approfondire ulteriormente questa e altre funzionalità di OMS ricordo che è possibile provare la soluzione OMS gratuitamente.

Windows Server 2016: Configurazione del Cloud Witness in ambito Failover Cluster

Nell’articolo Windows Server 2016: What’s New in Failover Clustering sono state approfondite tutte le principali novità introdotte con Windows Server 2016 in ambito failover clustering. In questo articolo entreremo del dettaglio della configurazione del witness del cluster nel cloud Microsoft Azure, analizzando i possibili scenari supportati e i benefici di questa nuova funzionalità.

 

Possibili scenari supportati dal Cloud Witness

Tra gli scenari supportati che si prestano maggiormente per questo tipo di configurazione troviamo:

  • Multi-site stretched cluster.
  • Failover Cluster che non necessitano di storage condiviso (SQL Always On, Exchange DAGs, etc).
  • Failover Cluster composti da nodi ospitati su Microsoft Azure, altri cloud pubblici oppure in private cloud.
  • Cluster di tipologia Scale-out File Server.
  • Cluster realizzati in realtà small branch-office.

 

Configurazione del Cloud Witness

Iniziamo con il specificare che un requisito necessario per poter configurare il cluster per l’utilizzo del Cloud Witness è che tutti i nodi che compongono il cluster abbiano un accesso internet verso Azure. Il Cloud Witness infatti utilizza il protocollo HTTPS (porta 443) per stabilire una connessione con il servizio blob dell’Azure Storage Account.

 

La configurazione del Cloud Witness richiede la presenza di una subscription Azure all’interno della quale configurare uno Storage Account che sarà utilizzato come Cloud Witness e sul quale saranno scritti i blob file utilizzati per l’arbitration del cluster.

 

Dal portale Azure è necessario creare uno storage account di tipologia Genaral Purpose. Per questo scopo è corretto crearlo con un livello di performance standard in quanto non sono necessarie elevate prestazioni che vengono fornite con l’utilizzo di dischi SSD. Dopo aver selezionato la policy di replica e la location più opportuna si può procedere con il processo di creazione.

 

Figura 1 – Creazione dello Storage Account

 

Dopo aver creato lo storage account è necessario recuperare la relativa chiave di accesso necessaria per l’autenticazione, che verrà richiesta negli step successivi di configurazione.

 

Figura 2 – Chiavi di accesso dello Storage Account

 

Giunti a questo punto è possibile modificare le impostazioni del Quorum del cluster da Failover Cluster Manager seguendo i passaggi sotto riportati:

 

Figura 3 – Configurazione delle impostazioni Quorum da Failover Cluster Manager

 

Figura 4 – Selezione del Quorum Witness

 

Figura 5 – Selezione del Cloud Witness

 

Figura 6 – Nome e chiave di accesso dello Storage Account

 

Al termine della configurazione sarà presente tra le varie risorse del cluster anche il Cloud Witness:

 

Figura 7 – Risorsa Cloud Witness

 

Sullo Storage Account di Azure viene creato un container denominato msft-cloud-witness, all’interno del quale sarà presente un unico blob file che ha come nome l’ID univo del cluster. Questo comporta che è possibile utilizzare lo stesso Microsoft Azure Storage Account per configurare il Cloud Witness su cluster differenti, dove sarà presente un blob file per ogni cluster.

 

Figura 8 – Container presente all’interno dello Storage Account e relativo contenuto

 

Vantaggi nell’utilizzo del Cloud Witness

L’utilizzo del Cloud Witness consente di ottenere i seguenti vantaggi:

  • Viene eliminata la necessità di disporre di un ulteriore data center separato per determinate configurazioni cluster utilizzando invece Microsoft Azure.
  • Viene annullato l’effort amministrativo necessario per mantenere una macchina virtuale aggiuntiva con il ruolo di witness del cluster.
  • Considerata la quantità ridotta di dati scritti sullo Storage Account il costo del servizio è irrisorio.
  • Lo stesso Microsoft Azure Storage Account può essere utilizzato come witness per cluster differenti.

 

Conclusioni

Anche in ambito failover cluster Windows Server 2016 si dimostra pronto per l’integrazione con il cloud. Grazie all’introduzione del cloud Witness è possibile realizzare più facilmente sistemi cluster riducendo sensibilmente i costi complessivi per l’implementazione, l’effort di gestione e aumentando la flessibilità dell’architettura cluster.

Come migrare sistemi verso Microsoft Azure utilizzando OMS Azure Site Recovery

Nell’articolo OMS Azure Site Recovery: panoramica della soluzione sono state presentate le caratteristiche di Azure Site Recovery e sono stati esaminati gli aspetti che la rendono una efficace e flessibile soluzione per la creazione di strategie di business continuity e di disaster recovery per il proprio data center. In questo articolo vedremo come utilizzare Azure Site Recovery per migrare ambienti anche potenzialmente eterogenei verso Microsoft Azure. Sempre più spesso ci si trova infatti di fronte all’esigenza non solo di creare nuove macchine virtuali nella cloud pubblica di Microsoft, ma anche di migrare sistemi già esistenti. Per svolgere queste migrazioni è possibile adottare diverse strategie, tra le quali compare anche Azure Site Recovery (ASR) che ci consente di migrare agilmente macchine virtuali presenti su Hyper-V, VMware, sistemi fisici e workload di Amazon Web Services (AWS) verso Microsoft Azure.

Nella seguente tabella vengono riportati quali scenari di migrazione è possibile affrontare con ASR:

Sorgente Destinazione Tipologia di SO Guest supportati
Hyper-V 2012 R2 Microsoft Azure Tutti i SO guest supportati in Azure
Hyper-V 2008 R2 SP1 and 2012 Microsoft Azure Windows e Linux *
VMware e Server Fisici Microsoft Azure Windows e Linux*
Amazon Web Services (Windows AMIs) Microsoft Azure Windows Server 2008 R2 SP1+

* Supporto limitato a Windows Server 2008 R2 SP1+, CentOS 6.4, 6.5, 6.6, Oracle Enterprise Linux 6.4, 6.5, SUSE Linux Enterprise Server 11 SP3

Quando si ha la necessità di effettuare attività di migrazione solitamente è di fondamentale importanza rispettare i seguenti punti:

  • Ridurre al minimo il tempo di downtime dei workload di produzione durante il processo di migrazione.
  • Avere la possibilità di testare e validare il funzionamento della soluzione nell’ambiente di destinazione (Azure nel caso specifico) prima di convalidare la migrazione.
  • Effettuare un’unica migrazione dei dati utile sia per il processo di convalida che per la migrazione vera e propria.

Con ASR tutto ciò è possibile seguendo questo semplice flusso di operazioni:

Figura 1 – Flusso di migrazione con ASR

 

Vediamo ora nel dettaglio quali sono le operazioni da svolgere in uno scenario di migrazione di macchine virtuali presenti su un host Hyper-V 2012 R2 verso Microsoft Azure.

Come prima cosa dal portale Azure è necessario creare un Recovery Service Vault nella subscription sulla quale si desidera migrare le macchine virtuali:

Figura 2 – Creazione Recovery Service Vault

In seguito è necessario preparare l’infrastruttura per poter utilizzare Azure Site Recovery. Il tutto è possibile farlo seguendo la procedura guidata  proposta dal portale Azure:

Figura 3 – Preparazione infrastruttura

Dopo aver dichiarato lo scenario di migrazione (macchine virtuali su host Hyper-V non gestito da SCVMM verso Azure), assegno un nome al site Hyper-V e associo ad esso l’host Hyper-V che detiene le macchine virtuali:

Figura 4 – Preparazione Source: step 1.1

Figura 5 – Preparazione Source: step 1.2

Giunti a questo punto è necessario installare sull’host Hyper-V il provider Microsoft Azure Site Recovery. Durante l’installazione è possibile specificare un server proxy e la chiave di registrazione al vault, la quale è necessario scaricarla direttamente dal portale Azure:

Figura 6 – Installazione provider ASR

Figura 7 – Configurazione accesso al vault

Figura 8 – Impostazioni proxy

Figura 9 – Registrazione al vault ASR

Dopo aver atteso qualche istante il server Hyper-V appena registrato al vault di Azure Site Recovery comparirà sul portale Azure:

Figura 10 – Preparazione Source: step 2

Lo step successivo richiede di specificare su quale subscription Azure verranno create le macchine virtuali e il modello di deployment (Azure Resource Manager – ARM nel caso riportato). A questo punto è importante verificare che sia presente uno storage account e una virtual network su cui attestare le macchine virtuali:

Figura 11 – Preparazione Target

Lo step seguente consente di specificare quale policy di replica associare al site. Nel caso non siano presenti policy in precedenza create è opportuno configurare una nuova policy stabilendo i parametri riportati in seguito, più idonei al proprio ambiente:

Figura 12 – Impostazione policy di replica

Figura 13 – Associazione alla policy di replica

L’ultimo step di preparazione dell’infrastruttura richiede l’esecuzione del Capacity Planner, strumento molto utile per stimare l’utilizzo di banda e di storage. Inoltre permette di valutare una serie di altri aspetti che è necessario prendere bene in considerazione in scenari di replica per evitare problematiche. Lo strumento può essere scaricato direttamente dal portale Azure:

Figura 14 – Capacity planning

Giunti a questo punto sono state completate tutte le operazioni di configurazione e preparazione dell’infrastruttura ed è possibile proseguire selezionando quali macchine si desidera replicare dal site precedentemente configurato:

Figura 15 – Abilitazione replica

Nello step successivo è possibile selezionare le configurazioni delle macchine replicate in termini di Resource Group, Storage Account e Virtual Network – Subnet:

Figura 16 – Impostazioni di recovery del target

Tra tutte le macchine ospitate sull’host Hyper-V è opportuno selezionare per quali si desidera attivare la replica verso Azure:

Figura 17 – Selezione VMs da replicare

Per ogni macchina virtuale selezionata è necessario specificare il sistema operativo guest (Windows oppure Linux), qual’è il disco che detiene il sistema operativo e quali dischi dati si vuole replicare:

Figura 18 – Proprietà delle VMs in replica

Dopo aver concluso la configurazione di tutti gli step inizierà il processo di replica secondo le impostazioni configurate nella policy specifica:

Figura 19 – Step di replica

Terminata la replica iniziale è consigliato verificare che la macchina virtuale funzioni regolarmente in ambiente Microsoft Azure effettuando un “Test Failover” (punto 1 dell’immagine seguente) e dopo aver svolto i controlli opportuni è necessario effettuare un “Planned Failover” (punto 2) per avere la macchina virtuale disponibile e pronta per essere utilizzata in ambiente di produzione. Al termine di questa operazione può ritenersi completata la migrazione verso Azure del vostro sistema e sarà possibile rimuovere la configurazione della replica all’interno del Recovery Service Vault (punto 3).

Figura 20 – Finalizzazione del processo di migrazione

Conclusioni

Azure Site Recovery con semplici passaggi guidati ci consente di migrare facilmente, in modo sicuro e con un downtime minimo sistemi che si trovano presso i propri datacenter oppure workload presenti in Amazon Web Services (AWS) verso Microsoft Azure. Vi ricordo che le funzionalità di Azure Site Recovery possono essere testate attivando un ambiente trial di Operations Management Suite oppure di Microsoft Azure.

Windows Server 2016: What’s New in Failover Clustering

Molto frequentemente per poter garantire l’alta disponibilità e la business continuity per applicazioni e servizi critici è necessario implementare un Failover Cluster in ambiente Microsoft. In questo articolo approfondiremo le principali novità introdotte con Windows Server 2016 in ambito failover clustering e analizzeremo i vantaggi nell’adottare la più recente tecnologia.

Cluster Operating System Rolling Upgrade

In Windows Server 2016 è stata introdotta una importante funzionalità che consente di aggiornare i nodi di un cluster Hyper-V oppure di uno Scale-Out File Server da Windows Server 2012 R2 a Windows Server 2016 senza nessun disservizio ed evitando di fermare i workload da esso ospitati.

Il processo di aggiornamento prevede questi step:

  • Mettere il nodo che si vuole aggiornare in pausa e spostare tutte le machine virtuali oppure gli altri workload sugli altri nodi del cluster
  • Rimuovere il singolo nodo dal cluster ed effettuare un’installazione pulita di Windows Server 2016
  • Aggiungere il nodo Windows Server 2016 al cluster esistente. Da questo momento il cluster entrerà in modalità Mixed con nodi sia Windows Server 2012 R2 che nodi Windows Server 2016. A questo proposito è bene specificare che il cluster continuerà ad erogare i servizi in modalità Windows Server 2012 R2 e non saranno ancora disponibili le funzionalità introdotte in Windows Server 2016. In questa fase sarà possibile aggiungere e rimuovere nodi sia Windows Server 2012 R2 che nodi Windows Server 2016
  • Procedere con l’aggiornamento di tutti i nodi del cluster nella stessa modalità precedentemente descritta
  • Solo quando tutti i nodi del cluster saranno stati aggiornati a Windows Server 2016 sarà possibile cambiare il functional level del cluster portandolo a Windows Server 2016. Tale operazione non è reversibile e per portarla a termine è necessario utilizzare il cmdlet PowerShell Update-ClusterFunctionalLevel. Dopo aver eseguito tale comando sarà possibile sfruttare tutti i vantaggi introdotti in Windows Server 2016 di seguito riportati

Cloud Witness

Windows Server 2016 introduce la possibilità di configurare il witness del cluster direttamente nel cloud Microsoft Azure. Il Cloud Witness, esattamente come per le alte tipologie di witness, fornirà un voto arbitrario partecipando al calcolo del quorum.


Figura 1 – Cloud Witness in Failover Cluster Manager

La configurazione del Cloud Witness prevede due semplici passaggi:

  • Creazione su una subscription Azure di un Azure Storage Account che sarà utilizzato dal Cloud Witness
  • Configurazione del Cloud Witness in una delle seguenti modalità

PowerShell

Failover Cluster Manager


Figura 2 – Configurazione Cloud Witness Step 1


Figura 3 – Configurazione Cloud Witness Step 2

 


Figura 4 – Configurazione Cloud Witness Step 3

L’utilizzo del Cloud Witness consente di ottenere i seguenti vantaggi:

  • Sfrutta Microsoft Azure eliminando così la necessità di disporre di un ulteriore data center separato per determinate configurazioni cluster
  • Utilizza direttamente un Microsoft Azure Blob Storage annullando in questo modo l’effort amministrativo necessario per mantenere una macchina virtuale in una cloud pubblica
  • Lo stesso Microsoft Azure Storage Account può essere utilizzato per più cluster
  • Vista la mole ridotta di dati scritti sullo Storage Account il costo del servizio è irrisorio

Site-Aware Failover Clusters

Windows Server 2016 introduce il concetto di failover cluster site-aware ed è in grado di raggruppare gruppi di nodi in una configurazione stretched cluster in base alla location geografica (site).  Durante il ciclo di vita di un cluster site-aware le policy di placement, l’heartbeat tra i nodi e le operazioni di failover e di calcolo del quorum sono pensate e migliorate per questa specifica configurazione dell’ambiente cluster. Per maggiori dettagli a riguardo vi invito a consultare l’articolo Site-aware Failover Clusters in Windows Server 2016.

Workgroup e Multi-domain Cluster

In Windows Server 2012 R2 e nelle precedenti versioni di Windows tutti i nodi di un cluster dovevano necessariamente appartenere allo stesso dominio Active Directory. Con Windows Server 2016 vengono rimosse queste barriere e viene fornita la possibilità di creare un Failover Cluster senza dipendenze da Active Directory.

In Windows Server 2016 sono supportate le seguenti configurazioni:

  • Single-domain Cluster: cluster dove tutti i nodi appartengono allo stesso dominio
  • Multi-domain Cluster: cluster composto da nodi in join a domini Active Directory differenti
  • Workgroup Cluster: cluster con nodi in workgroup (non in join a un dominio)

A tal proposito è bene specificare quali sono i workload supportati e le relative limitazioni per i Multi-domain e Workgroup cluster:

 Cluster Workload

 Supporto

DettagliMotivazione
SQL Server

Supportato

Raccomandato l’utilizzo dell’autenticazione SQL Server.
File Server

Supportato, ma non raccomandato

L’autenticazione Kerberos (non disponibile in questi ambienti) è il protocollo di autenticazione consigliato per il traffico Server Message Block (SMB).
Hyper-V

Supportato, ma non raccomandato

Non è supportata la Live Migration, ma solo la Quick Migration.
Message Queuing (MSMQ)

Non supportato

Message Queuing salva proprietà in AD DS.

Diagnostic in Failover Clustering

In Windows Server 2016 sono state introdotte le seguenti novità per facilitare le operazioni di troubleshooting nel caso dovessero emergere problematiche relative all’ambiente cluster:

SMB Multichannel e Multi-NIC Cluster Network

In Windows Server 2016 diverse sono le novità introdotte anche in ambito network per quanto riguarda l’ambiente cluster che consentono di facilitare la configurazione e di ottenere maggiori performance.

I benefici principali introdotti in Windows Server 2016 possono essere sintetizzati nei seguenti punti:

  • SMB Multichannel viene abilitato di default
  • Il failover cluster è in grado di riconoscere in automatico le NIC attestate sulla stessa subnet stesso switch
  • Una singola risorsa IP Address viene configurata per ogni Cluster Access Point (CAP) Network Name (NN)
  • Le network con solo indirizzi IPv6 Link Local (fe80) sono riconosciute come reti private (cluster only)
  • Il cluster validation non riporta più messaggi di warning nel caso siano presenti più NIC attestate sulla stessa subnet

Per maggiori informazioni a riguardo vi rimando alla documentazione Microsoft: Simplified SMB Multichannel and Multi-NIC Cluster Networks.

Conclusioni

Windows Server 2016 introduce importanti cambiamenti anche in ambito Failover Clustering rendendo la soluzione maggiormente flessibile e aprendo nuovi possibili scenari di configurazione. Inoltre il processo di upgrade ci consente di aggiornare facilmente ambienti cluster già esistenti per beneficiare di tutti i vantaggi introdotti da Windows Server 2016 per i differenti workload.

OMS Azure Site Recovery: panoramica della soluzione

Poter disporre di una adeguata strategia di business continuity e di disaster recovery che consenta di mantenere in esecuzione le applicazioni e ripristinare le normali condizioni di lavoro quando si ha l’esigenza di effettuare attività manutentive pianificate oppure durante fermi non previsti è di fondamentale importanza.

Azure Site Recovery favorisce l’attuazione di queste strategie orchestrando le repliche delle macchine virtuali e dei server fisici presenti all’interno del proprio data center. Si ha la possibilità di replicare i server e le macchine virtuali che si trovano in un data center primario locale verso il cloud (Microsoft Azure) oppure verso un data center secondario.

Nel caso dovessero verificarsi interruzioni nel data center primario è possibile avviare un processo di failover per mantenere i carichi di lavoro accessibili e disponibili. Quando sarà possibile utilizzare nuovamente le risorse nel data center primario verrà gestito il processo di failback.

Possibili scenari di replica

In Azure Site Recovery sono contemplati i seguenti scenari di replica:

  • Replica di macchine virtuali Hyper-V

In questo scenario se le macchine virtuali Hyper-V vengono gestite da System Center Virtual Machine Manager (VMM) è possibile prevedere la replica sia verso un data center secondario sia verso Microsoft Azure. Nel caso invece le macchine virtuali non siano gestite tramite VMM la replica sarà possibile solo verso Microsoft Azure.

  • Replica di macchine virtuali VMware

Le macchine virtuali presenti su VMware possono essere replicate sia verso un data center secondario utilizzando un canale dati di InMage Scout sia verso Microsoft Azure.

  • Replica di server fisici Windows e Linux

I server fisici possono essere replicati sia verso un data center secondario (tramite canale dati di InMage Scout) che verso Microsoft Azure.

Figura 1 – Scenari di replica di ASR

Configurazione di Azure Site Recovery

Nella seguente tabella sono riportati i documenti con le specifiche da seguire per configurare Azure Site Recovery nei differenti scenari:

Tipologia dei sistemi da replicare Destinazione della replica
Macchine virtuali VMware Microsoft Azure

Data center Secondario
Macchine virtuali Hyper-V gestite in cloud VMM Microsoft Azure

Data center Secondario
Macchine virtuali Hyper-V gestite in cloud VMM, con archiviazione su SAN Data center Secondario
Macchine virtuali Hyper-V senza VMM Microsoft Azure
Server fisici Windows/Linux locali Microsoft Azure

Data center Secondario

 

Principali vantaggi nell’adozione di Azure Site Recovery

Dopo aver esaminato cosa è possibile fare con Azure Site Recovery e quali step seguire per implementare i piani di recovery riportiamo quelli che sono alcuni dei principali vantaggi che si possono avere con l’adozione di questa soluzione:

  • Utilizzando gli strumenti di Azure Site Recovery si semplifica il processo di creazione di piani di business continuity e di disaster recovery. Nei piani di ripristino è infatti possibile includere script e runbook presenti in Azure Automation in modo da poter modellare e personalizzare le procedure di DR anche per applicativi con architetture complesse.
  • Si può avere una elevata flessibilità grazie alle potenzialità della soluzione che consente di orchestrare repliche di server fisici e di macchine virtuali in esecuzione sia su Hyper-V che su VMware.
  • Grazie alla possibilità di replicare i carichi di lavoro direttamente su Azure in alcuni casi si può valutare di eliminare completamente un data center secondario realizzato solo a fini di business continuity e di disaster recovery.
  • Si ha la possibilità di eseguire periodicamente test di failover per validare l’efficacia dei piani di recovery realizzati, senza dare nessun impatto all’ambiente applicativo di produzione.
  • Risulta possibile integrare ASR con altre tecnologie BCDR già esistenti in azienda (come ad esempio SQL Server AlwaysOn oppure SAN replication).

 

Tipologie di Failover in Azure Site Recovery

Dopo aver completato la creazione di un piano di recovery è possibile eseguire differenti tipologie di failover. Nella tabella seguente sono elencate le varie tipologie di failover e per ognuna di essa è specificato il relativo scopo e quali azioni comporta il processo di esecuzione.

Conclusioni

Azure Site Recovery è una soluzione potente e flessibile per la creazione di strategie di business continuity e di disaster recovery per il proprio data center, in grado di orchestrare e gestire anche infrastrutture eterogenee e complesse. Tutto ciò rende ASR uno strumento adeguato per la maggior parte degli ambienti. Per chi volesse esplorare direttamente sul campo le funzionalità di Azure Site Recovery può attivare un ambiente di trial di Operations Management Suite oppure di Microsoft Azure.

Microsoft Azure Site Recovery: Replica di macchine virtuali di Hyper-V in Microsoft Azure

Microsoft Azure Site Recovery offre la possibilità di replicare macchine virtuali presenti su Hyper-V verso uno specifico cloud service a fini di disaster recovery.

Accedendo al seguente link è possibile consultare tutti i dettagli sui prerequisiti e sugli scenari supportati per utilizzare Azure Site Recovery: http://msdn.microsoft.com/it-it/library/azure/dn469078.aspx Continua a leggere→