Archivi categoria: Microsoft Azure

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→