Archivi categoria: Cloud

Azure IaaS and Azure Stack: announcements and updates (March 2019 – Weeks: 09 and 10)

This series of blog posts includes the most important announcements and major updates regarding Azure infrastructure as a service (IaaS) and Azure Stack, officialized by Microsoft in the last two weeks.

Azure

Azure South Africa regions are available

Azure services are now available from new cloud regions in Johannesburg (South Africa North) and Cape Town (South Africa West), South Africa. The launch of these regions marks a major milestone for Microsoft as they open their first enterprise-grade datacenters in Africa, becoming the first global provider to deliver cloud services from datacenters on the continent. With 54 regions announced worldwide, the Microsoft global cloud infrastructure will connect the new regions in South Africa with greater business opportunity, help accelerate new global investment, and improve access to cloud and internet services across Africa. The new cloud regions in Africa are connected with Microsoft’s other regions via their global network, which spans more than 100,000 miles (161,000 kilometers) of terrestrial fiber and subsea cable systems to deliver services to customers.

Microsoft Azure Sentinel: intelligent security analytics for the entire enterprise

Security can be a never-ending saga, a chronicle of increasingly sophisticated attacks, volumes of alerts, and long resolution timeframes where today’s Security Information and Event Management (SIEM) products can’t keep pace. Microsoft rethinks the SIEM tool as a new cloud-native solution called Microsoft Azure Sentinel. Azure Sentinel provides intelligent security analytics at cloud scale for your entire enterprise. Azure Sentinel makes it easy to collect security data across your entire hybrid organization from devices, to users, to apps, to servers on any cloud.  It uses the power of artificial intelligence to ensure you are identifying real threats quickly and unleashes you from the burden of traditional SIEMs by eliminating the need to spend time on setting up, maintaining, and scaling infrastructure. Since it is built on Azure, it offers nearly limitless cloud scale and speed to address your security needs. Traditional SIEMs have also proven to be expensive to own and operate, often requiring you to commit upfront and incur high cost for infrastructure maintenance and data ingestion. With Azure Sentinel there are no upfront costs, you pay for what you use.

Virtual network service endpoints for Azure Database for MariaDB are available

virtual network service endpoints for Azure Database for MariaDB are accessible in all available regions. Virtual network service endpoints allow you to isolate connectivity to your logical server from only a given subnet or set of subnets within your virtual network. Traffic to Azure Database for MariaDB from the virtual network service endpoints stays within the Azure network, preferring this direct route over any specific routes that take internet traffic through virtual appliances or on-premises.

M-series virtual machines (VMs) are available in the Korea South region and in the China North 2 region

Azure M-series VMs are now available in the Korea South region and in the China North 2 region. M-series VMs offer configurations with memory from 192 GB to 3.8 TiB (4 TB) RAM and are certified for SAP HANA.

Azure Policy root cause analysis and change tracking features

New functionalities have been added to Azure Policy, including root cause analysis and change tracking features. This means that you’ll be able to see why a resource evaluated as non-complaint and what changes were implemented directly by a policy.

Azure Container Registry firewall rules and Virtual Network

Firewall rules and Virtual Network support in Azure Container Registry are available in preview.  Limit registry access to your resources in Azure, or specific on-premises resources, including Express Route connected devices. Virtual Network access is provided through the Azure Container Registry premium tier. General availability pricing will be announced at a later date. 

Azure Lab Services

Azure Lab Services is generally available. With Azure Lab Services, you can easily set up and provide on-demand access to preconfigured virtual machines (VMs) to teach a class, train professionals, run hackathons or hands-on labs, and more. Simply input what you need in a lab and let the service roll it out to your audience. Your users go to a single place to access all their VMs across multiple labs, and connect from there to learn, explore, and innovate.

Azure Availability Zones in East US

Azure Availability Zones, a high-availability solution for mission-critical applications, is now generally available in East US.

Global VNet Peering in Azure Government regions

Global VNet Peering is generally available in all Azure Government cloud regions. This means you can peer virtual networks across the Azure Government cloud regions. You cannot peer across Azure Government cloud and Azure public cloud regions.

Global VNet Peering supports Standard Load Balancer

Previously, resources in one virtual network could not communicate with the front-end IP address of an internal load balancer over a globally peered connection. The virtual networks needed to be in the same region. This is no longer the case. You can communicate with the internal IP address of a Standard Load Balancer instance across regions from resources deployed in a globally peered virtual network. This support is in all Azure regions, including Azure China and Azure Government regions.

New capabilities in Azure Firewall

Two new key capabilities in Azure Firewall:

  • Threat intelligence based filtering: Azure Firewall can now be configured to alert and deny traffic to and from known malicious IP addresses and domains in near real-time. The IP addresses and domains are sourced from the Microsoft Threat Intelligence feed. Threat intelligence-based filtering is default-enabled in alert mode for all Azure Firewall deployments, providing logging of all matching indicators. Customers can adjust behavior to alert and deny.
  • Service tags filtering: a service tag represents a group of IP address prefixes for specific Microsoft services such as SQL Azure, Azure Key Vault, and Azure Service Bus, to simplify network rule creation. Microsoft today supports service tagging for a rich set of Azure services which includes managing the address prefixes encompassed by the service tag, and automatically updating the service tag as addresses change. Azure Firewall service tags can be used in the network rules destination field.
Azure File Sync in Japan East, Japan West, and Brazil South

Azure File Sync is now supported in Japan East, Japan West, and Brazil South regions.

Azure Premium Blob Storage public preview

Premium Blob Storage is a new performance tier in Azure Blob Storage, complimenting the existing Hot, Cool, and Archive tiers. Premium Blob Storage is ideal for workloads with high transactions rates or requires very fast access times, such as IoT, Telemetry, AI and scenarios with humans in the loop such as interactive video editing, web content, online transactions, and more. Premium Blob Storage has higher data storage cost, but lower transaction cost compared to data stored in the regular Hot tier. This makes it cost effective and can be less expensive for workloads with very high transaction rates.

Update rollup for Azure File Sync Agent: March 2019

An update rollup for the Azure File Sync agent was released today which addresses the following issues:

  • Files may fail to sync with error 0x80c8031d (ECS_E_CONCURRENCY_CHECK_FAILED) if change enumeration is failing on the server
  • If a sync session or file receives an error 0x80072f78 (WININET_E_INVALID_SERVER_RESPONSE), sync will now retry the operation
  • Files may fail to sync with error 0x80c80203 (ECS_E_SYNC_INVALID_STAGED_FILE)
  • High memory usage may occur when recalling files
  • Cloud tiering telemetry improvements

More information about this update rollup:

  • This update is available for Windows Server 2012 R2, Windows Server 2016 and Windows Server 2019 installations that have Azure File Sync agent version 4.0.1.0 or later installed.
  • The agent version of this update rollup is 5.1.0.0.
  • A restart may be required if files are in use during the update rollup installation.
  • Installation instructions are documented in KB4481060.

Azure Stack

Azure App Service on Azure Stack 1.5 (Update 5) Released

This release updates the resource provider and brings the following key capabilities and fixes:

  • Updates to **App Service Tenant, Admin, Functions portals and Kudu tools**. Consistent with Azure Stack Portal SDK version.
  • Updates to **Kudu** tools to resolve issues with styling and functionality for customers operating **disconnected** Azure Stack.
  • Updates to core service to improve reliability and error messaging enabling easier diagnosis of common issues.

All other fixes and updates are detailed in the App Service on Azure Stack Update Five Release Notes.

Azure storage: Disaster Recovery e funzionalità di failover

Microsoft ha recentemente annunciato una nuova funzionalità che consente, per gli Azure storage account geo-ridondati, di effettuare in modo pilotato il failover. Tale caratteristica aumenta le capacità di controllo su questa tipologia di storage account, consentendo di avere una maggiore flessibilità in scenari di Disaster Recovery. In questo articolo viene mostrato il principio di funzionamento e la procedura da seguire per utilizzare questa nuova funzionalità.

Tipologie di storage account

In Azure sono presenti diverse tipologie di storage account con caratteristiche di replica distinte, per ottenere differenti livelli di ridondanza. Nel caso si voglia mantenere il dato presente sugli storage account disponibile anche a fronte di malfunzionamenti di una intera region di Azure è necessario adottare gli storage account di tipologia geo-ridondati, tra i quali se ne distinguono due differenti tipologie:

  • Geo-redundant storage (GRS): il dato viene replicato in modo asincrono in due region geografiche di Azure, distanti centinaia di miglia tra di loro.
  • Read-access geo-redundant storage (RA-GRS): segue lo stesso principio di replica precedentemente descritto, ma con la caratteristica che l’endpoint secondario può essere acceduto per leggere i dati replicati.

Utilizzando queste tipologie di storage account vengono mantenute tre copie del dato nella region primaria di Azure, selezionata in fase di configurazione, e ulteriori tre copie asincrone del dato in un’altra region di Azure, seguendo il principio delle Azure Paired Regions.

Figura 1 – Normale funzionamento dello storage di tipologia GRS/RA-GRS

Per maggiori informazioni sulle differenti tipologie di storage account e le relative caratteristiche di ridondanza è possibile consultare la documentazione ufficiale Microsoft.

Caratteristiche del processo di failover dello storage account

Grazie a questa nuova funzionalità, l’amministratore ha la possibilità di avviare il processo di account failover deliberatamente, nel momento in cui lo ritiene opportuno. Il processo di failover effettua un aggiornamento del record DNS pubblico dello storage account, in questo modo le richieste vengono indirizzate verso l’endpoint dello storage account presente nella region secondaria.

Figura 2 – Processo di failover per uno storage di tipologia GRS/RA-GRS

Al termine del processo di failover lo storage account è configurato per essere di tipologia Locally redundant storage (LRS) ed è necessario procedere con la relativa configurazione per renderlo nuovamente geo-ridondato.

Un aspetto importante da tenere in considerazione, quando si decide di intraprendere un failover dello storage account, è che tale operazione può comportare una perdita di dati, in quanto la replica tra le due region di Azure avviene in modalità asincrona. A causa di questo aspetto, in caso di indisponibilità della region primaria, potrebbero non essere stati replicate verso la region secondaria tutte le modifiche. Per verificare questa condizione è possibile fare riferimento alla proprietà Last Sync Time che indica il momento nel quale viene garantito che il dato è stato correttamente replicato verso la region secondaria.

Procedura di failover dello storage account dal portale Azure

In seguito, viene riportata la procedura per effettuare il failover di uno storage account direttamente dal portale Azure.

Figura 3 – Avvio del processo di failover dello Storage account

Figura 4 – Conferma del processo di failover dello Storage account

La procedura per avviare il failover di uno storage account può essere svolta non solo dal portale Azure, ma anche tramite PowerShell, Azure CLI, oppure utilizzando le API delle risorse Azure Storage.

Come individuare le problematiche sugli storage account

Microsoft raccomanda che gli applicativi che utilizzano gli storage account siano progettati per sostenere possibili errori in fase di scrittura. In questo modo l’applicativo dovrebbe esporre eventuali fallimenti riscontrati nella scrittura, in modo da essere allertati sulla possibile indisponibilità nell’accedere allo storage in una determinata region. Questo consentirebbe di intraprendere le dovute azioni correttive, come ad esempio il failover dello storage account in modalità GRSRA-GRS.

In modo nativo la piattaforma, tramite il servizio Azure Service Health, fornisce indicazioni dettagliate nel caso dovessero verificarsi condizioni che influenzano il funzionamento dei propri servizi presenti in Azure, compreso lo storage. Grazie alla completa integrazione di Service Health in Azure Monitor, il quale detiene il motore di alerting di Azure, è possibile configurare degli Alerts specifici qualora ci siano problemi lato Azure, che impattano sul funzionamento delle risorse presenti sulle proprie subscription.

Figura 5 – Creazione Health alert nel servizio Service Health

Figura 6 – Rule di notifica di problemi sullo storage

La notifica avviene tramite Action Groups, in seguito alla quale è possibile valutare la reale esigenza di intraprendere il processo di failover dello storage account.

Conclusioni

Prima del rilascio di questa funzionalità, in presenza di storage account di tipologia GRS/RA-GRS, il failover doveva comunque essere pilotato dal personale Microsoft a fronte di un fault che impattasse lo storage di una intera region Azure. Grazie a questa funzionalità viene fornito all’amministratore la possibilità di pilotare a piacimento il failover, garantendo così un maggiore controllo sugli storage account. Al momento questa funzionalità è disponibile in preview e solamente per gli storage account creati in determinate region Azure. Come accade per diverse funzionalità Azure in preview è bene attendere il rilascio ufficiale prima di utilizzarla per workload in ambiente di produzione.

Azure management services e System Center: novità di Febbraio 2019

Il mese di Febbraio è stato ricco di novità e diversi sono gli aggiornamenti che hanno interessato gli Azure management services e System Center. In questo articolo vengono riepilogati per avere una panoramica complessiva delle principali novità del mese, in modo da rimanere sempre aggiornati su questi argomenti ed avere i riferimenti necessari per condurre ulteriori approfondimenti.

Azure Monitor

Multi-resource support per metric alerts

Grazie a questa nuova funzionalità è possibile configurare una singola metric alert rule per monitorare:

  • Una lista di macchine virtuali in una region Azure.
  • Tutte le macchine virtuali in uno o più resource groups in una region Azure.
  • Tutte le macchine virtuali di una subscription, presenti in una determinata region Azure.

Azure Automation

Il runbook Update Azure Modules è open source

Azure Automation consente di aggiornare i moduli Azure Powershell importati in un automation account con le ultime versioni disponibili presenti nella PowerShell Gallery. Tale possibilità viene fornita tramite l’action Update Azure Modules presente nella pagina Modules dell’Automation Account, ed è implementata tramite un runbook nascosto. Al fine di migliorare le attività di diagnostica e troubleshooting e di fornire la possibilità di personalizzazione del modulo, questo è stato reso open source.

Supporto per il modulo Azure PowerShell Az

In Azure Automation è stato introdotto il supporto per il modulo PowerShell Az, grazie al quale è possibile utilizzare i moduli Azure aggiornati all’interno dei runbook, per gestire i vari servizi Azure.

Azure Log Analytics

Nuova versione dell’agente per Linux

Questo mese la nuova versione dell’agente OMS per sistemi Linux risolve un bug specifico in fase di installazione. Per ottenere la versione aggiornata dell’agente OMS è possibile accedere alla pagina ufficiale GitHub.

Disponibilità in nuove region di Azure

Risulta possibile attivare un workspace di Log Analytics anche nelle region Azure di West US 2, Australia East e Australia Central. In questo modo i dati vengono mantenuti e processati in queste region.

Azure Site Recovery

Nuovo Update Rollup

Per Azure Site Recovery è stato rilasciato l’Update Rollup 33 che introduce nuove versioni per i seguenti componenti:

  • Microsoft Azure Site Recovery Unified Setup (versione 9.22.5109.1): utilizzato per scenari di replica da VMware verso Azure.
  • Microsoft Azure Site Recovery Provider (versione 5.1.3900.0): utilizzato per scenari di replica da Hyper-V verso Azure oppure verso un secondary site.
  • Microsoft Azure Recovery Services Agent (versione 2.0.9155.0): utilizzato per scenari di replica da Hyper-V verso Azure.

L’installazione di questo update rollup è possibile su tutti i sistemi con installato Microsoft Azure Site Recovery Service Provider, includendo:

  • Microsoft Azure Site Recovery Provider per System Center Virtual Machine Manager (3.3.x.x).
  • Microsoft Azure Site Recovery Hyper-V Provider (4.6.x.x).
  • Microsoft Azure Site Recovery Provider (5.1.3500.0) e versioni successive.

L’Update Rollup 33 per Microsoft Azure Site Recovery Unified Setup si applica a tutti i sistemi che hanno installato la versione 9.17.4860.1 o successive.

Per ottenere maggiori informazioni sulle problematiche risolte, sugli improvements dati da questo Update Rollup e per ottenere la procedura da seguire per la relativa installazione è possibile consultare la KB specifica 4489582.

Protezione di cluster Storage Space Direct

In Azure Site Recovery (ASR) è stato introdotto, con l’Update Rollup 33, anche il supporto per la protezione di cluster Storage Space Direct, utilizzati per realizzare Guest Cluster in ambiente Azure.

Azure Backup

In Azure Backup è stata rilasciata la funzionalità di Instant Restore per le macchine virtuali presenti su Azure, che consente di effettuare il recovery di VMs utilizzando le snapshots archiviate. Inoltre viene data la possibilità all’amministratore di configurare i tempi di retention delle snapshot nelle policy di backup (da uno a cinque giorni, il default è due giorni). Questo consente di aumentare il controllo sulla protezione delle proprie risorse, adattandola su specifiche esigenze e in base alla criticità delle stesse.

Figura 1 – Periodo di retention delle snapshot

System Center Configuration Manager

Rilasciate le versioni 1902 e 1902.2 per il Technical Preview Branch

Tra le principali novità di queste release troviamo la possibilità di gestire in modo più efficace le notifiche di riavvio sui sistemi gestiti da Configuration Manager.

Per tutti i dettagli riguardanti le novità incluse in queste release è possibile consultare questo documento. Si ricorda che i rilasci nel Technical Preview Branch consentono di valutare in anteprima le nuove funzionalità di SCCM ed è consigliato applicare questi aggiornamenti solo in ambienti di test.

System Center Operations Manager

Management Packs

In seguito, si riportano le novità riguardanti i seguenti Management Pack di SCOM:

  • Microsoft System Center 2016 Management Pack per Microsoft Azure version 1.6.0.7
  • Microsoft System Center Management Pack per SQL Server 2017+ Reporting Services version 7.0.12.0
  • Log Analytics Management Pack per SCOM 1801 versione 7.3.13288.0 e SCOM 2016 versione 7.2.12074.0
  • System Center Management Pack per Windows Server DNS versione 10.0.9.3

Valutazione di Azure e System Center

Per testare e valutare in modo gratuito i servizio offerti da Azure è possibile accedere a questa pagina, mentre per provare i vari componenti di System Center è necessario accedere all’Evaluation Center e, dopo essersi registrati, è possibile avviare il periodo di trial.

Azure IaaS and Azure Stack: announcements and updates (February 2019 – Weeks: 07 and 08)

This series of blog posts includes the most important announcements and major updates regarding Azure infrastructure as a service (IaaS) and Azure Stack, officialized by Microsoft in the last two weeks.

Azure

Serial console for Azure Virtual Machines (feature update)

The serial console for Azure Virtual Machines enables you to reboot your VM from within the console experience. This ability will help you if you want to reboot a stuck VM or enter the boot menu of your VM.

Azure File Sync v5 release

Improvements and issues that are fixed:

  • Support for Azure Government cloud
    • Added preview support for the Azure Government cloud. This requires a white-listed subscription and a special agent download from Microsoft.
  • Support for Data Deduplication
    • Data Deduplication is now fully supported with cloud tiering enabled on Windows Server 2016 and Windows Server 2019. Enabling deduplication on a volume with cloud tiering enabled lets you cache more files on-premises without provisioning more storage.
  • Support for offline data transfer (e.g. via Data Box)
    • Easily migrate large amounts of data into Azure File Sync via any means you choose. You can choose Azure Data Box, AzCopy and even third party migration services. No need to use massive amounts of bandwidth to get your data into Azure, in the case of Data Box.
  • Improved sync performance
    • Customers with multiple server endpoints on the same volume may have experienced slow sync performance prior to this release. Azure File Sync creates a temporary VSS snapshot once a day on the server to sync files that have open handles. Sync now supports multiple server endpoints syncing on a volume when a VSS sync session is active. No more waiting for a VSS sync session to complete so sync can resume on other server endpoints on the volume.
  • Improved monitoring in the portal
    • Charts have been added in the Storage Sync Service portal to view:
      • Number of files synced
      • Size of data transferred
      • Number of files not syncing
      • Size of data recalled
      • Agent connectivity status
  • Improved scalability and reliability
    • Maximum number of file system objects (directories and files) in a directory has increased to 1,000,000. Previous limit was 200,000.
    • Sync will try to resume data transfer rather than retransmitting when a transfer is interrupted for large files

Agent installation notes:

  • The Azure File Sync agent is supported on Windows Server 2012 R2, Windows Server 2016, and Windows Server 2019.
  • Azure File Sync agent version 4.0.1.0 or a later version is required to upgrade existing agent installations.
  • A restart may be required if files are in use during the installation.
  • The agent version for the v5 release is 5.0.2.0.

Installation instructions are documented in KB4459989.

Service tags are available in Azure Firewall network rules

A service tag represents a group of IP address prefixes to help minimize complexity for security rule creation. You cannot create your own service tag, nor specify which IP addresses are included within a tag. Microsoft manages the address prefixes encompassed by the service tag, and automatically updates the service tag as addresses change. Azure Firewall service tags can be used in the network rules destination field. You can use them in place of specific IP addresses. Service tags are fully supported in all public regions using PowerShell/REST/CLI by simply including the tag string in a network rule destination field. Portal support is being rolled out and will incrementally be available in all public regions in the near future.

Azure Governance: introduzione alle Azure Policy

L’IT governance è quel processo attraverso il quale è possibile garantire a un’organizzazione un utilizzo efficace ed efficiente delle risorse IT, al fine di poter raggiungere i propri obiettivi. Azure Policy è un servizio disponibile nel cloud pubblico di Microsoft che è possibile utilizzare per creare, assegnare e gestire dei criteri per controllare le risorse presenti in Azure. Le Azure Policy, integrate nativamente nella piattaforma, sono un elemento chiave per la governance dell’ambiente cloud. In questo articolo vengono riportati i principi di funzionamento e le caratteristiche della soluzione.

Negli ambienti Azure si possono trovare differenti subscription sulle quali sviluppano e operano diversi gruppi di operatori. L’esigenza comune è di standardizzare, e in alcuni casi imporre, come vengono configurate le risorse nel cloud. Tutto questo viene fatto per ottenere ambienti che rispettano specifiche normative di conformità, controllare la sicurezza, i costi delle risorse e uniformare il design di differenti architetture. Questi obiettivi si possono ottenere con un approccio tradizionale, che prevede un blocco degli operatori (Dev/Ops) nell’accesso diretto alle risorse cloud (tramite portale, api oppure cli). Questo approccio tradizionale risulta però poco flessibile, in quanto implica una perdita di agilità nel controllare il deployment delle risorse. Utilizzando invece il meccanismo che viene fornito in modo nativo dalla piattaforma Azure è possibile pilotare la governance per ottenere il controllo desiderato, senza impattare sulla velocità, elemento fondamentale nelle operations dell’IT moderno.

Figura 1 – Approccio tradizionale vs cloud-native governance

In ambito Azure Policy è possibile fare quanto in seguito riportato:

  • Attivare policy built-in o configurarle in base alle proprie esigenze.
  • Effettuare in tempo reale la valutazione dei criteri presenti nelle policy e forzarne l’esecuzione.
  • Valutare la compliance delle policy periodicamente oppure su richiesta.
  • Attivare dei criteri di controllo anche sull’ambiente guest delle macchine virtuali (VM In-Guest Policy).
  • Applicare Policy a dei Management Group al fine di ottenere un controllo sull’intera organizzazione.
  • Applicare contemporaneamente più criteri e aggregare i vari stati delle policy.
  • Configurare scope sui quali vengono applicate delle esclusioni.
  • Attivare operazioni per la remediation in tempo reale, anche per risorse già esistenti.

Tutto questo si traduce nella possibilità di applicare e forzare su larga scala dei criteri di compliance e le relative azioni di remediation.

Il meccanismo di funzionamento delle Azure Policy è semplice e integrato nella piattaforma.  Nel momento in cui viene fatta una richiesta di configurazione di una risorsa Azure tramite ARM, questa viene intercettata dal layer contenente il motore che effettua la valutazione delle policy. Tale engine effettua una valutazione sulla base delle policy Azure attive e stabilisce la legittimità della richiesta.

Figura 2 – Principio di funzionamento delle Azure Policy nella creazione di risorse

Lo stesso meccanismo viene poi ripetuto periodicamente oppure su specifica richiesta per valutare lo strato di compliance delle risorse esistenti.

Figura 3 – Principio di funzionamento delle Azure Policy nel controllo delle risorse

In Azure sono già presenti molte policy built-in pronte per essere applicate. Inoltre, in questo repository GitHub è possibile trovare diverse definizioni di Azure Policy, che possono essere utilizzate direttamente oppure modificate in base alle proprie esigenze. La definizione delle Azure Policy è fatta in JSON e segue una struttura ben precisa, descritta in questo documento Microsoft. Si ha inoltre la possibilità di creare delle Initiatives, che sono un insieme di più policy.

Figura 4 – Esempio di definizione di una Azure Policy

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.

Figura 5 – Processo di assegnazione di una Azure Policy

In seguito all’assegnazione è possibile valutare lo stato di compliance nel dettaglio e se lo si ritiene necessario applicare delle azioni di remediation.

Figura 6 – Stato di compliance

Figura 7 – Esempio di azione di remediation

 

Conclusioni

Grazie all’utilizzo delle Azure Policy si ha la possibilità di controllare totalmente il proprio ambiente Azure, in modo semplice ed efficace. Statistiche fornite da Microsoft citano che considerando i 100 top Azure Customers, 92 di questi utilizzano le Azure Policy per controllare il proprio ambiente. Questo perché aumentando la complessità e la quantità di servizi su Azure è indispensabile adottare degli strumenti, come Azure Policy, per avere delle politiche efficaci di governance.

Azure Monitor: introduzione al servizio di monitor delle macchine virtuali

In Azure Monitor è stato introdotto un nuovo servizio che consente di effettuare il monitor delle macchine virtuali, chiamato Azure Monitor for VMs. Questo servizio analizza i dati di performance e lo stato delle macchine virtuali, effettua il monitor dei processi installati e ne esamina le relative dipendenze. In questo articolo sono riportate le caratteristiche della soluzione ed descritta la procedura da seguire per effettuarne l’attivazione.

Caratteristiche della soluzione

Il servizio Azure Monitor for VMs è suddiviso secondo tre differenti prospettive:

  • Health: i componenti logici presenti a bordo delle macchine virtuali vengono valutati secondo specifici criteri pre-configurati, generando alert quando si verificano determinate condizioni. Tale funzionalità, al momento, è presente solo per sistemi che risiedono in Azure.
  • Performance: vengono riportati i dati principali di performance, provenienti dal sistema operativo guest.
  • Map: viene generata una mappa con le interconnessioni presenti tra vari componenti che risiedono su sistemi differenti.

Tale soluzione può essere utilizzata su macchine virtuali Windows e Linux, indipendentemente dall’ambiente in cui esse risiedono (Azure, on-premises oppure presso altri cloud provider).

Azure Monitor for VMs richiede la presenza di un workspace di Log Analytics. Trattandosi di una funzionalità al momento in preview, sono supportati i workspace presenti in queste regions: West Central US, East US, West Europe e Southeast Asia. L’abilitazione di un workspace di Log Analytics può avvenire secondo queste modalità:

Per individuare i sistemi operativi supportati da questa soluzione è possibile consultare la relativa documentazione ufficiale Microsoft.

 

Come abilitare Azure Monitor for VMs

Per abilitare la soluzione per una singola macchina virtuale, dal portale Azure, è possibile procedere accedendo alla sezione Insights della macchina virtuale:

Figura 1 – Abilitazione di Azure Monitor for VMs su una singola VM

Abilitando la soluzione su una singola macchina virtuale è possibile scegliere quale workspace Log Analytics utilizzare ed eventualmente crearne uno nuovo. Il consiglio è di precedere a priori con la creazione del workspace, in modo da potergli assegnare un nome significativo in fase di creazione. Il workspace di Log Analytics deve essere configurato come segue:

  • Deve aver installato le solution ServiceMap e InfrastructureInsights. L’installazione di queste solution può essere fatta tramite dei template JSON, secondo le modalità riportate in questo documento.

Figura 2 – Presenza delle solution ServiceMap e InfrastructureInsights

Figura 3 – Raccolta dei performance counters abilitata sul workspace di Log Analytics

Azure Monitor for VMs richiede la presenza dell’agent di Log Analytics sulle macchine virtuali, inoltre la funzionalità di Map richiede l’installazione del Microsoft Dependency agent. Si tratta di un agente aggiuntivo il quale si affida all’agente di Log Analytics per la connessione al workspace.

Nel caso si voglia abilitare la soluzione per sistemi presenti in Azure è possibile attivare il Dependency agent utilizzando l’apposita extension, che ne effettua l’installazione. Per le macchine virtuali che non risiedono su Azure è necessario effettuarne l’installazione manualmente oppure tramite una soluzione che consente di automatizzare il deployment (ad esempio System Center Configuration Manager).

Per abilitare questa funzionalità in modo automatico sulle nuove macchine virtuali create in ambiente Azure ed ottenere un livello elevato di compliance si possono anche utilizzare le Azure Policy. Tramite le Azure Policy è possibile:

  • Effettuare il deployment dell’agente di Log Analytics e del Dependency agent.
  • Avere un report sullo stato di compliance
  • Avviare delle azioni di remediation per le VMs non compliant.

Figura 4 – Aggiunta di un Assignment

Figura 5 – Initiative definition di esempio per abilitare Azure Monitor for VMs

Figura 6 – Consultazione dello stato di compliance della Policy

 

Consultazione dei dati raccolti dalla soluzione

Per analizzare e identificare eventi critici del sistema operativo, rilevare prestazioni non ottimali e problematiche di rete, è possibile consultare i dati forniti dalla solution direttamente dalla singola VM oppure utilizzando Azure Monitor, nel caso si voglia avere una vista aggregata delle varie macchine virtuali. Il tutto consente di rilevare e identificare se determinati problemi sono relativi a specifiche dipendenze con altri servizi.

Figura 7 – Stato di Health di una singola macchina virtuale

Figura 8 – Performance raccolte da più VMs, consultabili da Azure Monitor

Figura 9 – Mappa delle dipendenze dei vari servizi presenti sulle VMs, consultabili da Azure Monitor

Per maggiori informazioni sull’utilizzo della funzionalità di Health è possibile consultare questa documentazione Microsoft, mentre l’articolo View Azure Monitor for VMs Map mostra come individuare e analizzare le dipendenze rilevate dalla soluzione.

Costi della soluzione

Attivando la solution Azure Monitor for VMs, i dati collezionati dalle macchine virtuali vengono inviati e mantenuti in Azure Monitor e possono dipendere da diversi fattori, come ad esempio il numero dei logical disks e delle schede di rete. I costi sono quelli relativi ad Azure Monitor, il quale prevede delle spese sulla base dei seguenti elementi:

  • Dati inseriti e collezionati.
  • Numero di criteri di health monitorati.
  • Alert rule create.
  • Notifiche inviate.

 

Conclusioni

Il servizio Azure Monitor for VMs consente di avere uno strumento totalmente integrato in Azure per monitorare le macchine virtuali ed ottenere un controllo completo dei sistemi, indipendentemente da dove risiedono. Questa soluzione risulta anche particolarmente utile per condurre operazioni di troubleshooting in modo semplice ed immediato. Tale servizio, nonostante sia attualmente in preview, è comunque già sufficientemente completa ed è sicuramente destinata ad arricchirsi presto con nuove funzionalità.

Come ridurre i costi del cloud con Microsoft Azure

L’evoluzione del data center ci porta ad avere soluzioni completamente nel cloud pubblico oppure scenari ibridi dove, la scelta di utilizzare risorse nel cloud, oltre che da fattori funzionali, deve necessariamente essere fatta tenendo in considerazione l’aspetto fondamentale dei costi. In questo articolo vengono riportate delle indicazioni che è possibile seguire per ottenere un risparmio sui costi, dati dal mantenere i propri workload applicativi in Azure.

Azure Reservations

Il costo dei vari servizi Azure è calcolato sulla base dell’utilizzo delle risorse ed è possibile effettuare una stima dei costi utilizzando lo strumento Azure pricing calculator.

Se, delle risorse in ambiente Azure, ne viene fatto un uso continuativo è possibile valutare l’attivazione delle Azure Reservations.

Le Azure Reservation consentono di ottenere una riduzione dei costi fino al 72% rispetto al prezzo pay-as-you-go, semplicemente prepagando anticipatamente per uno oppure tre anni l’utilizzo delle risorse Azure. Al momento le risorse Azure che consentono di ottenere questi sconti sono: macchine virtuali, Azure SQL Database, Azure Cosmos DB e SUSE Linux. L’acquisto di queste reservation può essere fatto direttamente dal portale Azure ed è fattibile per i clienti che dispongono delle seguenti tipologie di subscription:

  • Enterprise agreement: in questo ambito non sono contemplate le risorse che risiedono in subscription Dev/Test. Risulta possibile attingere all’Azure Monetary Commitment per l’acquisto delle Azure Reservation.
  • Pay-As-You-Go.
  • Cloud Solution Provider (CSP): in questo caso l’acquisto è fattibile anche dal Partner Center.

Tra le Azure reservation troviamo:

  • Reserved Virtual Machine Instance: la reservation contempla solamente i costi computazionali della macchina virtuale, e non copre i costi aggiuntivi dati dal software installato a bordo della VM, dal networking, oppure dall’utilizzo dello storage.
  • SQL Database reserved vCore: anche in questo caso sono compresi solamente i costi computazionali, mentre le licenze vengono fatturate in modo separato.
  • Azure Cosmos DB reserved capacity: la reservation copre il throughput effettivo della risorsa, ma non contempla i costi previsti per lo storage e per il networking.
  • SUSE Linux: consente di risparmiare sui costi di licenza di SUSE Linux Enterprise.

Procedura per acquistare le Azure Reservations dal portale Azure

Per acquistare delle Reservations dal portale Azure è possibile seguire la procedura in seguito riportata.

Figura 1 – Aggiunta Azure Reservation dal portale e selezione della tipologia

Figura 2 – Configurazione dei parametri richiesti per le Reserved Virtual Machine Instances

Figura 3 – Riepilogo delle Azure Reservations acquistate

Per maggiori approfondimenti in merito a come le Reservation influiscono sul calcolo dei costi Azure, è possibile consultare i seguenti documenti Microsoft:

Hybrid Benefit

Un’altra possibilità da tenere in considerazione per la riduzione dei costi Azure è l’utilizzo dell’Azure Hybrid Benefit, che consente di risparmiare fino al 40% sul costo delle macchine virtuali Windows Server che vengono implementate su Azure. Il risparmio è dato dal fatto che Microsoft consente di pagare solamente i costi di infrastruttura Azure, mentre il licensing per Windows Server viene coperto dal contratto di Software Assurance. Questo benefit è applicabile sia alla versione Standard che Datacenter ed è usufruibile per Windows Server 200 R2 o successivi.

Figura 4 – Struttura dei costi per una VM Windows

L’Azure Hybrid Benefit può essere utilizzato in concomitanza con le Azure Reserved VM Instance, consentendo di avere risparmi complessivi che possono raggiungere l’80% (nel caso di acquisto di Azure Reserved Instance per 3 anni).

Figura 5 – Percentuali di possibili risparmi adottando RIs ed Azure Hybrid Benefit

Nel caso non ci si trovi nelle condizioni per usufruire dell’Azure Hybrid Benefit, il costo della licenza di Windows Server viene calcolato in base all’utilizzo orario della macchina virtuale e secondo il numero di core configurati.

L’Azure Hybrid Benefit può essere utilizzato anche per Azure SQL Database e per i SQL Server installati su macchine virtuali Azure. Questi vantaggi facilitano la migrazione verso soluzioni nel cloud e aiutano a massimizzare gli investimenti già effettuati in termini di licenze SQL Server. Per maggiori informazioni su come è possibile utilizzare l’Azure Hybrid Benefit per SQL Server è possibile consultare le FAQ di questo documento.

I risparmi sui costi, garantiti dall’utilizzo dell’Azure Hybrid Benefits, sono stimabili utilizzando lo strumento Azure Hybrid Benefit Savings Calculator.

Recentemente Microsoft ha effettuato degli studi sui costi da sostenere per attivare Windows Server e SQL Server in ambiente cloud che evidenziano come, grazie all’utilizzo delle Azure Reservations e di Azure Hybrid Benefit, AWS risulti fino a 5 volte più costoso rispetto ad Azure. La comparativa tra i costi Azure e quelli di AWS è possibile valutarla facilmente adottando lo strumento Azure vs. AWS Cost Comparison.

Conclusioni

Azure risulta sicuramente la scelta più economicamente vantaggiosa per ospitare in particolare i workload Microsoft, potendo avere dei costi ridotti dati dai vantaggi forniti dalle Azure Reservation e dall’Azure Hybrid Benefit. Inoltre, grazie allo strumento Azure cost management, messo a disposizione in modo gratuito a tutti i clienti Azure, si ha la possibilità di monitorare ed ottimizzare le spese dei vari servizi Azure.

OMS e System Center: novità di Novembre 2018

Microsoft annuncia in modo costante novità riguardanti Operations Management Suite (OMS) e System Center. La nostra community rilascia mensilmente questo riepilogo che consente di avere una panoramica complessiva delle principali novità del mese, per rimanere costantemente aggiornati su questi argomenti ed avere i riferimenti necessari per condurre maggiori approfondimenti.

Operations Management Suite (OMS)

Azure Monitor

SQL Data Warehouse permette ora di inviare le informazioni di diagnostica verso un workspace di Log Analytics. Questa impostazione consente agli sviluppatori di analizzare al meglio il comportamento dei propri workload applicativi al fine di ottimizzare le query, gestire al meglio l’utilizzo delle risorse ed intraprendere operazioni di troubleshooting.

Figura 1 – Impostazioni di diagnostica di SQL Data Warehouse

Log Analytics

A partire dal 1 febbraio 2019 sono previste delle modifiche riguardanti i service-level agreements (SLAs) per Log Analytics e Application Insights (facenti ora parte di Azure Monitor). I nuovi SLAs si riferiscono alla disponibilità delle query (Query Availability SLA) che per una determinata risorsa sarà del 99.9 percento. In precedenza, gli SLA si riferivano alla latenza dei dati (Data latency SLA).

Agente

Questo mese la nuova versione dell’agente OMS per sistemi Linux risolve importanti bug e ne migliora la stabilità. Per ottenere la versione aggiornata dell’agente OMS è possibile accedere alla pagina ufficiale GitHub OMS Agent for Linux Patch v1.8.1-256.

Figura 2 – Elenco Bug Fix e novità del nuovo agente OMS per Linux

Azure Backup

Per Microsoft Azure Backup Server è stata rilasciata la versione 3 (MABS V3), la quale include importanti risoluzioni di bug, introduce il supporto per Windows Server 2019 e SQL Server 2017, e introduce nuove funzionalità e miglioramenti tra i quali:

  • Supporto per la protezione di macchine virtuali VMware anche per ambienti di produzione.
  • Utilizzo di TLS 1.2 per le comunicazioni tra MABS e i server protetti, per le autenticazioni di tipologia certificate-based, e per i cloud backups.

Il codice di MABS V3 è basato su quello di System Center Data Protection Manager 1807. Per ottenere maggiori informazioni a riguardo è possibile consultare la Knowledge Base Microsoft Azure Backup Server v3.

Azure Site Recovery

In Azure Site recovery è stato introdotto il supporto per gli storage account firewall-enabled. Grazie all’introduzione di questo supporto è possibile replicare verso un’altra region, a fini di disaster recovery, macchine virtuali con dischi unmanaged, che risiedono su storage account firewall-enabled. Gli storage account firewall-enabled possono essere selezionati anche come storage target per i dischi unmanaged. Si ha inoltre la possibilità di restringere l’accesso allo storage account di cache, consentendo di scrivere solamente dalle virtual network su cui risiedono le macchine virtuali. In questi casi risulta necessario abilitare l’exception come riportato nella documentazione Microsoft Allow trusted Microsoft services.

 

System Center

System Center Configuration Manager

Per il Current Branch (CB) di System Center Configuration Manager è stato rilasciato l’update 1810, che introduce nuove funzionalità e importanti miglioramenti nel prodotto.

Tra le principali novità di questo aggiornamento emerge la possibilità per i Central administration sites ed i child primary sites di avere un ulteriore site server in modalità passiva, on-prem oppure su Azure.

Figura 3 – Site server High Availability Architecture

Per l’elenco completo delle nuove funzionalità introdotte in questa versione di Configuration Manager è possibile consultare la documentazione ufficiale.

System Center Operations Manager

In seguito, si riportano le novità riguardanti i seguenti Management Pack di SCOM:

  • Windows Server Cluster 2016 e 1709 Plus versione 10.6.6
  • Windows Print Server 2016 e 1709 plus  versione 10.6.1
  • Windows Server Network Load Balancing 2016 e 1709 plus versione 10.2.1
  • Internet Information Service 2016 e 1709 Plus versione 10.9.1
  • Windows Server DNS versione 10.9.2
  • Windows Server DHCP 2016 e 1709 Plus versione 10.11.0
  • Active Directory Federation Services versione 10.3.0
  • Active Directory Federation Services 2012 R2 versione 1.10172.1
  • Skype for Business Server 2019 versione 2046.19
  • Windows Server 2012 DHCP  versione 6.0.7307.0
  • UNIX and Linux Operating Systems versione 7.7.1136.0
  • Microsoft Windows Server File & iSCSI Services 2012 R2 versione 7.1.10100.2
  • Microsoft Windows Server File & iSCSI Services 2016 and 1709 Plus version 10.0.0.0

 

Valutazione di Azure e System Center

Per testare e valutare in modo gratuito i servizio offerti da Azure è possibile accedere a questa pagina, mentre per provare i vari componenti di System Center è necessario accedere all’Evaluation Center e, dopo essersi registrati, è possibile avviare il periodo di trial.

Come monitorare Office 365 con Azure Log Analytics

In Azure Log Analytics è disponibile una solution specifica che consente di consolidare all’interno del workspace di Log Analytics differenti informazioni provenienti dall’ambiente Office 365, rendendo semplice e intuitiva la consultazione dei dati. In questo articolo saranno esaminate le caratteristiche di questa soluzione e verranno illustrati gli step da seguire per la relativa attivazione.

Caratteristiche dalla soluzione

La solution consente di utilizzare Log Analytics per effettuare le seguenti operazioni relative ad Office 365:

  • Monitorare le attività svolte dagli amministratori, al fine di tenere traccia delle modifiche apportate alle configurazioni e delle operazioni che richiedono privilegi elevati.
  • Analizzare le attività degli account Office 365 al fine di identificare le tendenze comportamentali e controllare l’utilizzo delle risorse. Si possono ad esempio esaminare quali file vengono condivisi all’esterno dell’organizzazione oppure controllare i siti di SharePoint più utilizzati.
  • Fornire supporto nelle attività di audit e compliance. Risulta possibile ad esempio controllare l’accesso a specifici file ritenuti confidenziali.
  • Identificare eventuali comportamenti non desiderati che vengono svolti degli utenti, sulla base di specifiche esigenze organizzative.
  • Svolgere con maggiore semplicità operazioni di troubleshooting che si rendono necessarie nel proprio ambiente Office 365.

Per poter attivare questa solution è necessario disporre di un account con il ruolo Global Administrator. Ad un singolo workspace Log Analytics è possibile connettere più sottoscrizioni Office 365. Nel caso si voglia far confluire nel workspace di Log Analytics anche gli eventi di Audit di Office 365 è necessario abilitare l’auditing sulla subscription Office 365, seguendo la procedura riportata in questa documentazione.

Figura 1 – Abilitazione Office 365 audit

Attivazione della soluzione

Per attivare l’Office 365 Management solution è necessario seguire questa procedura. La solution colleziona i dati direttamente da Office 365, senza l’iterazione di alcun agente di Log Analytics.

Figura 2 – Accesso al Workspace summary dal portale Azure e aggiunta solution

Figura 3 – Selezione della solution di Office 365

Figura 4 – Selezione del workspace da utilizzare

La solution richiede la presenza di una applicazione Azure Active Directory, configurata secondo quanto riportato in seguito, la quale viene utilizzata per accedere ai dati di Office 365.

Figura 5 – Aggiunta di una nuova App registration in Azure AD

Figura 6 – Creazione dell’App registration necessaria per la solution

Figura 7 – Attivazione dell’impostazione Multi-tenanted

Figura 8 – Aggiunta API Access per Office 365 Management APIs

Figura 9 – Selezione dei permessi necessari per Office 365 Management APIs

Figura 10 – Assegnazione dei permessi

Per poter configurare la solution è richiesta una chiave per l’applicazione Azure Active Directory creata.

Figura 11 – Generazione di una chiave per l’applicazione

Giunti a questo punto è necessario eseguire lo script PowerShell office365_consent.ps1 che abilita l’accesso amministrativo. Tale script è disponibile a questo indirizzo.

Figura 12 – Command line di esempio per l’esecuzione dello script office365_consent.ps1

Figura 13 – Richiesta del consenso amministrativo

L’ultimo step necessario per completare l’attivazione è l’esecuzione dello script PowerShell office365_subscription.ps1, anch’esso disponibile a questo indirizzo, il quale sottoscrive l’applicazione Azure AD creata al workspace Log Analytics.

Figura 14 – Command line di esempio per l’esecuzione dello script office365_subscription.ps1

In seguito alla configurazione inziale possono essere necessari diversi minuti prima di visualizzare i dati di provenienti da Office 365 in Log Analytics. Tutti i record creati da questa solution in Log Analytics hanno valorizzato il Type in OfficeActivity. Il valore contenuto nella proprietà OfficeWorkload determina a quale Servizio di Office 365 si riferisce: Exchange, Azure Active Directory, SharePoint, oppure OneDrive. Nella proprietà RecordType viene invece riportata la tipologia di operazione svolta.

La solution aggiunge nella dashboard il seguente tile:

Figura 15 – Tile di Office 365

Selezionandolo si viene rimandati nella dashboard specifica, la quale suddivide per servizi le varie attività collezionate di Office 365.

Figura 16 – Dashboard di Office 365

Ovviamente è possibile eseguire anche delle query specifiche in base alle proprie esigenze:

Figura 17 – Esempi di query di riportare specifici record collezionati dalla solution

 

Conclusioni

La raccolta in Log Analytics delle attività svolte in Office 365 consente di avere un controllo capillare dell’ambiente, al fine di poter ottemperare al meglio e con un unico strumento alle normative riguardanti l’auditing e la compliance.

Azure File Sync: panoramica della soluzione

Il servizio Azure File Sync (AFS) permette di centralizzare le cartelle di rete della propria infrastruttura in Azure Files, consentendo di mantenere le caratteristiche tipiche di un file server on-premises, in termini di performance, compatibilità e flessibilità e allo stesso tempo di beneficiare delle potenzialità offerte dal cloud. In questo articolo verranno riportate le caratteristiche principali del servizio Azure File Sync e le procedure da seguire per effettuarne il deployment.

Figura 1 – Schema di overview di Azure File Sync

Azure File Sync è in grado di trasformare Windows Server in una “cache” per accedere rapidamente ai contenuti presenti su una determinata Azure file share. L’accesso locale ai propri dati può avvenire con qualsiasi protocollo disponibile in Windows Server, come SMB, NFS, e FTPS. Si ha la possibilità inoltre di disporre di più server “cache” dislocati in location geografiche differenti.

Queste le caratteristiche principali di Azure File Sync:

  • Multi-site sync: si ha la possibilità di effettuare la sincronizzazione tra differenti site, consentendo di accedere in scrittura agli stessi dati tra differenti Windows Servers ed Azure Files.
  • Cloud tiering: vengono mantenuti localmente solo i dati acceduti di recente.
  • Integrazione con Azure backup: viene a decadere la necessità di effettuare il backup dei dati on premises. La protezione dei contenuti è possibile farla tramite Azure Backup.
  • Disaster recovery: si ha la possibilità di effettuare in modo immediato il ripristino dei metadata dei file e di richiamare solamente i dati necessari, per velocizzare le operazioni di riattivazione del servizio in scenari di Disaster Recovery.
  • Accesso diretto all’ambiente cloud: è consentito accedere direttamente ai contenuti presenti sulla File Share da altre risorse Azure (IaaS e PaaS).

 

Requisiti

Per poter effettuare il deployment di Azure File Sync è necessario disporre dei seguenti requisiti:

Un Azure Storage Account, con una file share configurata in Azure Files, nella stessa region dove si vuole fare il deploy del servizio AFS. Per effettuare la creazione di uno storage account è possibile seguire l’articolo Create a storage account, mentre la procedura di creazione della file share è riportata in questo documento.

Un sistema Windows Server con sistema operativo Windows Server 2012 R2 o successivo, il quale dovrà avere:

  • PowerShell 5.1, che è incluso di default a partire da Windows Server 2016.
  • Moduli PowerShell AzureRM.
  • Agente Azure File Sync. Il setup di installazione dell’agente può essere scaricato a questo indirizzo. Nel caso si intenda utilizzare AFS in ambiente cluster è opportuno installare l’agente su tutti i nodi del cluster. A questo proposito è bene precisare che Windows Server Failover Clustering è supportato da Azure File Sync per deployment di tipologia “File Server for general use”. L’ambiente Failover Cluster non è invece supportato su “Scale-Out File Server for application data” (SOFS) oppure su Clustered Shared Volumes (CSVs).
  • Si consiglia di mantenere l’opzione “Internet Explorer Enhanced Security Configuration” disabilitata sia per gli Administrators che per gli Users.

 

Concetti e configurazione del servizio

Dopo aver verificato la presenza di questi requisiti l’attivazione di Azure File Sync richiede di procedere con la creazione del servizio Storage Sync:

Figura 2 – Creazione servizio Storage Sync

Si tratta della risorsa top-level per Azure File Sync, la quale funge da contenitore per le relazioni di sincronizzazione tra i differenti storage account e molteplici Sync Group. Il Sync Group definisce la topologia di sincronizzazione per un set di files. Gli endpoint che si trovano all’interno dello stesso Sync Group vengono mantenuti in sincronizzazione tra di loro.

Figura 3 – Creazione Sync Group

A questo punto è possibile procedere con la registrazione del server avviando l’agente Azure File Sync.

Figura 4 – Avvio del processo di Sign-in

Figura 5 – Selezione dei parametri di registrazione del server

Figura 6 – Conferma di registrazione dell’agente

Al termine della registrazione il server comparirà anche nella sezione “Registered servers” del portale Azure:

Figura 7 – Server registrati nel servizio Storage Sync

Conclusa la registrazione del server è opportuno inserire un Server Endpoint all’interno del Sync Group, il quale integra un volume oppure una folder specifica, con un Registered Server, creando una location per la sincronizzazione.

Figura 8 – Aggiunta di un Server Endpoint

Aggiungendo un Server Endpoint è possibile abilitare la funzionalità di Cloud tiering che consente di mantenere, localmente sulla cache della macchina Windows Server, i file acceduti più frequentemente, mentre tutti i restanti file vengono salvati in Azure sulla base di specifiche policy che è possibile configurare. Per maggiori informazioni relative alla funzionalità di Cloud Tiering è possibile consultare la documentazione ufficiale Microsoft. A questo proposito è opportuno specificare che al momento non c’è supporto tra Azure File Sync con abilitata la funzionalità di cloud tiering, e la deduplica del dato. Nel caso si desideri abilitare Windows Server Data Deduplication occorre mantenere disabilitata la funzionalità di cloud tiering.

Dopo aver aggiunto uno o più Server Endpoint è possibile consultare lo stato del Sync Group:

Figura 9 – Stato del Sync Group

 

Per ottenere dei deployment di successo di Azure File Sync è inoltre necessario verificare attentamente la compatibilità con le soluzioni antivirus e di backup che vengono utilizzate.

Azure File Sync e DFS Replication (DFS-R) sono due soluzioni per la replica del dato e possono funzionare anche in side-by-side purché siano rispettate queste condizioni:

  1. Azure File Sync cloud tiering deve essere disabilitato sui volumi con cartelle DFS-R replicate.
  2. I Server endpoints non devono essere configurati su cartelle DFS-R read-only.

Azure File Sync può essere un ottimo sostituto di DFS-R e per la migrazione è possibile seguire le indicazioni riportate in questo documento. Rimangono alcuni scenari specifici che possono richiedere l’utilizzo contemporaneo di entrambe le soluzioni di replica:

  • Non tutti i server on-premises che necessitano di una copia dei file possono essere connessi a Internet.
  • Quando i branch servers consolidano i dati in un singolo hub server, sul quale viene poi utilizzato Azure File Sync.
  • Durante la fase di migrazione di deployment di DFS-R verso Azure File Sync.

Conclusioni

Azure File Sync è una soluzione che consente di estendere il classico file server dislocato on-premises con nuove funzionalità di sincronizzazione dei contenuti, beneficando delle potenzialità del cloud pubblico di Microsoft in termini di scalabilità e flessibilità.