Archivi categoria: cloud

Come crittografare una VM su Azure utilizzando Key Vault e lo standard BitLocker

Microsoft Azure mette a disposizione nuovi strumenti per la sicurezza dei nostri dati. Utilizzando pochi comandi PowerShell e concetti base su Key Vault in questo articolo vedremo come crittografare il disco di una VM con lo standard BitLocker.

Prerequisiti:

  • Azure PowerShell
  • Configurazione di un Key Vault

Per soddisfare i prerequisiti potete consultare il precedente articolo https://www.ictpower.it/guide/configurare-microsoft-azure-keyvault.htm

Configurare la VM

Creiamo una nuova VM associata al resource group NewResourceGroup, che avevamo creato nel precedente articolo, utilizzando Resource Manager come modello di deployment.

Figura 1: Scelta del deployment model

Figura 2: parametri per la creazione della nuova VM

Assicuriamoci che tutte le configurazioni siano relative al resource group corretto, cioè quello dentro il quale abbiamo abilitato Key Vault.

Al termine della creazione della VM, cliccando su Disks è possibile constatare che il disco non è crittografato.

Figura 3: Verifica che il disco creato non è crittografato

Scarichiamo dal repository GitHub ufficiale di Azure lo script denominato Azure Disk Encryption Prerequisite Setup, che si occuperà di soddisfare i prerequisiti necessari.

Utilizzando PowerShell ISE, configuriamo il contesto nel quale lo script verrà eseguito con i comandi:

Login-AzureRmAccount

Set-AzureRmContext -SubscriptionId <SubscriptionID>

Eseguiamo lo script:

Figura 4: Esecuzione dello script che verifica i prerequisiti per Azure Disk Encryption

Durante l’esecuzione, lo script chiederà alcune informazioni:

  • Il resource group da utilizzare
  • Il nome di una chiave; se non presente sarà creata automaticamente
  • L’area geografica
  • Il nome di un’applicazione: questa verrà usata per scrivere il segreto nel Key Vault; se non presente, verrà anch’essa creata automaticamente.

Figura 5: Inserimento dei parametri nello script di verifica

Crittografare la VM

Per crittografare la VM è necessario alcuni comandi PowerShell. Dichiariamo qual è il resource group da utilizzare e il nome della VM interessata utilizzando i comandi:

$resourceGroupName ‘NewResourceGroup’

$vmName ‘VMtestKV’

Dopo aver configurato il contesto corretto, possiamo utilizzare il seguente comando per eseguire l’azione di crittografia:

Set-AzureRmVMDiskEncryptionExtension -ResourceGroupName $resourceGroupName -VMName $vmName -AadClientID $aadClientID -AadClientSecret $aadClientSecret -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -DiskEncryptionKeyVaultId $keyVaultResourceId -VolumeType All

Confermiamo per concludere l’operazione:

Figura 6: richiesta di conferma prima dell’abilitazione della crittografia del disco

Al termine dell’esecuzione, lo script ritorna il seguente output:

Figura 7: Crittografia del disco completata

Verificando nuovamente nei dettagli della macchina potremo constatare che l’operazione è avvenuta correttamente.

Figura 8: Il disco della VM risulta crittografato

Conclusioni

Azure fornisce diverse soluzioni in ambito crittografico e quella descritta in questo articolo è particolarmente utile soprattutto se il monitoraggio delle macchine viene effettuato tramite Azure Security Center. Inoltre, con pochi click è possibile applicare la stessa procedura agli storage account in merito a files e blob, rispettando lo standard BitLocker e aumentando la sicurezza delle nostre infrastrutture su cloud.

Oracle Cloud: nuovi investimenti in Europa, Medio Oriente ed Africa

Oracle Cloud

“Il nostro business cloud sta crescendo a velocità incredibile, è quindi il momento giusto per portare [in Oracle] una nuova generazione di talenti” ha dichiarato nella giornata di ieri Tino Scholman, vicepresidente Oracle cloud computing per l’area EMEA. A circa un mese dal verdetto dei mercati e degli azionisti, le cui aspettative sono state ampiamente ripagate dai buoni risultati della compagnia (+58% di crescita su base annuale per i servizi cloud o +2.9 miliardi rispetto all’anno precedente), Oracle rilancia la propria piattaforma cloud computing incrementando lo staff in area EMEA.

Sebbene non siano stati resi noti gli uffici di destinazione dei nuovi arrivati (potrebbero essere anche aperte nuove sedi), si è appreso che l’azienda necessita di 1000 figure professionali con almeno 2-6 anni di esperienza alle spalle per supportare varie attività legate ai servizi cloud: finance, management, staff sales, recruitment, marketing e human resources.

EU: nuovo terreno di scontro

Attualmente Oracle dispone di 51.000 impiegati negli USA e 85.000 a livello internazionale. L’area EMEA, nel consueto bilancio dell’anno fiscale, ha contribuito al 28% delle rendite totali ma ha registrato anche un calo delle vendite pari al 2% – che si sono assestate sui 10.6 miliardi di dollari. La causa principale della flessione, osserva Data Center Knowledge, è la migrazione dei clienti dalle “vecchie” soluzioni software enterprise ai servizi cloud.

Degli 82 miliardi di spesa in servizi cloud previsti per l’anno 2020 potrebbe beneficiarne anche Oracle, prevedono gli analisti: “[le soluzioni IaaS Oracle] stanno guadagnando popolarità ed il prossimo anno potrebbero diventare uno dei principali pilastri di crescita, [pur con] la crescente competitività di Amazon” sottolinea Bloomberg Intelligence nel rapporto di Luglio.

In generale la notizia di nuovi posti di lavoro ed investimenti destinati anche alla region europea è un buon segno. A discapito di Brexit, GDPR ed altre problematiche, l’interesse dei cloud provider per il Vecchio continente resta sempre elevato. Ne è ulteriore conferma la recente apertura della region londinese di Google (europe-west2) che in futuro progetta di aprirne ulteriori a Francoforte, nei Paesi Bassi ed in Finlandia (arriveranno nel corso del 2018?).

Fonti: 1, 2

 

Creare una connessione Site-to-Site in Microsoft Azure

Microsoft Azure è la soluzione di cloud pubblico che permette di poter eseguire facilmente gran parte dei workload aziendali utilizzando le risorse hardware messe a disposizione online. Io sono dell’idea che un cloud ibrido, in cui alcuni workload sono online ed altri sono on-premises possa essere la soluzione più interessante per le aziende italiane.

In questo articolo voglio mostrarvi come connettere la rete aziendale on-premises con la rete virtuale di Azure (VNET), in modo tale che il cloud sia una naturale estensione della nostra infrastruttura. Per poterlo fare verrà creato un tunnel VPN IPsec/IKE (IKEv1 o IKEv2) tra due dispositivi: il primo dispositivo si troverà nella nostra infrastruttura (Local Network Gateway) e sarà raggiungibile dal cloud tramite un secondo dispositivo creato su Azure (Virtual Network Gateway).

Prerequisiti

Per poter realizzare una connessione Site-to-Site tra la vostra sede aziendale e Microsoft Azure è necessario che vengano rispettati alcuni prerequisiti:

  • Avere a disposizione in azienda un dispositivo VPN compatibile
  • Un indirizzo IP IPv4 pubblico esterno per il dispositivo VPN. L’indirizzo IP non può trovarsi dietro NAT

Figura 1: Schema di funzionamento di una connessione Site-to-Site

Configurazione della connessione

Per prima cosa è necessario avere una Virtual Network (VNET) all’interno della propria sottoscrizione Azure. Alla VNET verranno collegate tutte le macchine virtuali e i servizi che volete ospitare nel cloud. Scegliete di creare una nuova Virtual Network e indicate i parametri relativi al nome della rete, allo spazio di indirizzi da utilizzare e alle sottoreti ed ovviamente alla Regione di Azure dove volete crearla, come mostrato in figura:

Figura 2: Creazione della VNET

Figura 3: VNET creata – Visualizzazione Subnet

Una volta che è stata creata la VNET sarà necessario creare una subnet per il Gateway. In genere è sufficiente utilizzare una sottorete /27 o /28. Per poterlo fare vi basterà selezionare la VNET creata e scegliere il comando per aggiungere la Gateway Subnet. Il Nome per la subnet verrà compilato automaticamente con il valore ‘GatewaySubnet’. Questo valore è obbligatorio per consentire ad Azure di riconoscere la subnet come GatewaySubnet, quindi non modificatelo.

Figura 4: Aggiunta della Gateway Subnet

A questo punto siete pronti per la creazione del Gateway, che farà da Endpoint per la connessione VPN. Si tratta di due macchine virtuali messe in alta disponibilità e create da Microsoft che assicureranno la connessione con il dispositivo VPN che avere in casa.

Cliccate su Nuovo (+) à Networking à Virtual Network Gateway ed inserite i dati richiesti: nome, tipo di Gateway, SKU, Virtual Network a cui associarlo e indirizzo IP pubblico, come mostrato in figura:

Figura 5: Creazione del Virtual Network Gateway

Quando si crea il Virtual Network Gateway è necessario specificare un tipo di VPN. Il tipo di VPN scelto dipende dal tipo di connessione che si desidera creare. Ad esempio, una connessione Point-to-Site (P2S) richiede obbligatoriamente un tipo di VPN RouteBased. Dopo avere creato un gateway non è possibile modificare il tipo di VPN. È necessario eliminare il gateway e ricrearne uno nuovo. Lo SKU del Gateway VPN stabilisce il numero massimo di connessioni e la velocità effettiva aggregata. Attualmente sono disponibili le seguenti configurazioni:

SKU

Tunnel S2S/
rete virtuale-rete virtuale

Connessioni
P2S

Velocità effettiva
aggregata

VpnGw1

Max. 30

Max. 128

500 Mbps

VpnGw2

Max. 30

Max. 128

1 Gbps

VpnGw3

Max. 30

Max. 128

1,25 Gbps

Basic

Max. 10

Max. 128

100 Mbps

Per maggiori informazioni potete visitare la pagina https://docs.microsoft.com/it-it/azure/vpn-gateway/vpn-gateway-about-vpn-gateway-settings#gwsku

La creazione del gateway può richiedere fino a 45 minuti. Nell’attesa potete procedere alla creazione del Local Network Gateway, che rappresenta il dispositivo VPN che avete in azienda e che volete usare per la connessione Site-to-Site. Per crearlo è sufficiente cliccare su Nuovo (+) à Networking à Local network gateway e compilare i campi indicando la rete (o le reti) presente in azienda e l’indirizzo IP pubblico del dispositivo VPN aziendale, come mostrato in figura:

Figura 6: Creazione del Local Network Gateway

Dopo aver atteso il completamento della creazione del Virtual Network Gateway, siamo pronti per creare la connessione Site-to-Site. Selezionate il Gateway e nel tab Settings cliccate su Connections, come mostrato in figura:

Figura 7: Scheda Connections del gateway VPN appena creato

Cliccando su Add avrete la possibilità di scegliere il Tipo di connessione, il Local Network Gateway e la Pre-Shared Key (PSK) necessaria a configurare la connessione IPSEC/IKE, come mostrato in figura:

Figura 8: Configurazione della connessione Site-To-Site

A questo punto il Gateway avrà lo Status Connecting fino a quando non avrete configurato il dispositivo in azienda.

Figura 9: Creazione VPN Site-to-Site completata

Configurazione del dispositivo VPN aziendale

Maggiori informazioni su come configurare i dispositivi VPN e sui parametri IPsec/IKE per le connessioni del Gateway VPN possono essere visualizzate alla pagina https://docs.microsoft.com/it-it/azure/vpn-gateway/vpn-gateway-about-vpn-devices . Microsoft ha predisposto un elenco dei dispositivi VPN dei maggiori vendor con relativa configurazione.

Personalmente nei miei laboratori utilizzo come endpoint Microsoft RRAS installato su Windows Server 2012 R2. È possibile configurarlo manualmente per la connessione IKEv2 oppure potete trovare uno script di configurazione al link https://github.com/Azure/Azure-vpn-config-samples/tree/master/Microsoft

Conclusioni

La connessione VPN Site-to-Site ci permette di poterci collegare alle VNET create in Microsoft Azure ed utilizzare il cloud come estensione delle nostre reti aziendali, dandoci di fatto l’opportunità di accedere alle notevoli risorse di calcolo offerte, come se fossero disponibili in azienda.

Abilitare la nested virtualization con le nuove Azure VM Dv3 ed Ev3

Sono disponibili solo da un paio di giorni (e non in tutte le Regioni di Azure) le nuove macchine virtuali della Serie Dv3 ed Ev3. Queste macchine virtuali sono le prime ad essere ospitate su host Hyper-V basati su Windows Server 2016 e sono le prime che usano la tecnologia Hyper-Threading.

L’utilizzo dell’Hyper-Threading permetterà di creare macchine virtuali con più core e quindi migliorerà le performance e l’efficienza delle VM. I processori utilizzati sono Intel® Broadwell E5-2673 v4 2.3GHz e Intel® Haswell 2.4 GHz E5-2673 v3.

Grazie all’host Windows Server 2016 è adesso possibile abilitare la Nested Virtualization, che permette di poter eseguire il ruolo di Hyper-V anche in una macchina virtuale e di farci girare macchine virtuali annidate oppure Hyper-V Containers. Per maggiori informazioni su cosa sia la virtualizzazione annidata e come abilitarla in Windows Server 2016 vi rimando alla lettura dell’articolo https://docs.microsoft.com/it-it/virtualization/hyper-v-on-windows/user-guide/nested-virtualization

Alla pagina https://azure.microsoft.com/it-it/blog/introducing-the-new-dv3-and-ev3-vm-sizes/ potrete trovare un elenco dettagliato delle nuove VM disponibili, dei tagli previsti e delle Regioni dove attualmente sono abilitate.

Creazione di una nuova VM di tipo Ev3 su Azure

Per poter sfruttare la Nested Virtualization è necessario creare una macchina virtuale di tipo Dv3 oppure Ev3 in una delle regioni abilitate. Io ho deciso di utilizzare una macchina E4s_v3 e l’ho creata in West Europe, scegliendo come sistema operativo Windows Server 2016.

Figura 1: Creazione della VM in West Europe

Figura 2: Scelta della dimensione della VM

Figura 3: Configurazione dello storage, della rete e dell’IP pubblico della VM

Figura 4: Schermata riassuntiva con le scelte selezionate

Al termine della creazione della VM potete collegarvi in desktop remoto per configurarla. Dal Server Manager aggiungete il ruolo di Hyper-V e vedrete che non riceverete nessun messaggio di errore, come mostrato in figura:

Figura 5: Abilitazione del ruolo Hyper-V nella nested VM in Azure

Abilitazione della Nested Virtualization

Per semplificare l’abilitazione e la creazione di macchine virtuali annidate, potete scaricare uno script in PowerShell realizzato da Charles Ding, ingegnere del gruppo di sviluppo Microsoft Azure, all’indirizzo https://aka.ms/azurenestedvirtualization. Lo script vi permetterà di configurare il ruolo di Hyper-V e tutte le altre caratteristiche necessarie alla creazione della Nested VM.

Eseguite lo script in PowerShell ISE (lanciato con privilegi elevati) e la prima volta lo script provvederà ad installare il ruolo di Hyper-V, come mostrato in figura:

Figura 6: Esecuzione dello script che installa Hyper-V e che crea la VM annidata

L’installazione di Hyper-V richiede un paio di riavvii, quindi verrete disconnessi dal desktop remoto. Dopo qualche minuto, potrete ricollegarvi e rilanciare lo script per creare la VM. Modificate il valore $VMName “NestedVM-Level2” scegliendo il nome che volete assegnare alla vostra Nested VM e rilanciate lo script. Lo script verificherà che i prerequisiti sia tutti rispettati e creerà la macchina virtuale, abilitando tutte le estensioni necessarie alla virtualizzazione annidata, come mostrato in figura:

Figura 7: Lo script ha creato la VM annidata

Dopo aver avviato la VM annidata, nel mio caso chiamata NestedVM-Level2, potete installare il sistema operativo, come mostrato in figura:

Figura 8: Accensione della nested VM e installazione del sistema operativo

Se volete permette alla macchina annidata di navigare, poiché il MAC Address spoofing non è abilitato su Azure per motivi di sicurezza, sarà necessario creare una rete NAT nell’hypervisor (la VM su Azure) e poi assegnare alla Nested VM un indirizzo statico oppure potete usare il DHCP.

Per prima cosa create nella macchina “host” (la VM su Azure) un nuovo internal switch chiamato NAT utilizzando il comando PowerShell (lanciato con privilegi elevati):

#Creazione di uno switch di tipo Internal

New-VMSwitch -SwitchName “NAT” -SwitchType Internal

Con il comando Get-NetAdapter individuate l’indice assegnato alla nuova interfaccia di rete creata

Figura 9: Interfaccia di rete creata dallo switch di tipo Internal

A questo punto potete assegnare alla nuova scheda di rete un indirizzo IP statico (nel mio caso ho scelto 192.168.0.1), che poi verrà utilizzato dalla nested VM come gateway:

#Assegnazione dell’IP alla nuova interfaccia (sarà il gateway della rete)

New-NetIPAddress -IPAddress 192.168.0.1 -PrefixLength 24 -InterfaceIndex 13

Figura 10: Assegnazione dell’IP statico alla nuova interfaccia di rete

Create la rete di NAT utilizzando il comando PowerShell (lanciato con privilegi elevati):

#Creazione della rete di NAT

New-NetNat -Name NATnetwork -InternalIPInterfaceAddressPrefix 192.168.0.0/24

Adesso che avete completato la configurazione della rete potete collegare la Nested VM al virtual switch NAT che avete creato in precedenza, come mostrato in figura:

Figura 11: La nested VM viene collegata al virtual switch chiamato NAT

Potete installare sulla macchina Azure il servizio DHCP e quindi fare in modo che gli indirizzi vengano assegnati automaticamente. In alternativa potete configurare la scheda di rete della Nested VM con un IP statico, come mostrato in figura:

Figura 12: Configurazione dell’IP statico nella Nested VM

Come è possibile vedere dalla figura sotto, adesso la Nested VM è in grado di navigare in Internet.

Figura 13: La nested VM è connessa ad Internet

Conclusioni

La Nested Virtualization su Azure permette di utilizzare la nuova funzionalità di Windows Server 2016 e di eseguire macchine virtuali annidate oppure gli Hyper-V Containers di Docker. Un possibile caso d’uso della virtualizzazione annidata potrebbe essere la configurazione di un laboratorio di Hyper-V in un ambiente virtualizzato e il test di scenari a più computer (come ad esempio un cluster) senza la necessità di avere dei server fisici.

Configurare Microsoft Azure KeyVault

Azure KeyVault è un sistema di gestione di chiavi crittografiche e relativi segreti adoperati da applicazioni e servizi su Azure.

Con KeyVault è possibile crittografare chiavi di autenticazione, certificati .pfx, password ecc., utilizzando anche HSM.

Questo piccolo articolo è un’introduzione al concetto di sicurezza su Cloud e analizzerà come far comunicare un’applicazione con un’infrastruttura su Azure, attraverso l’utilizzo di una chiave crittografata. Tale configurazione viene effettuata tramite Azure PowerShell.

Per informazioni sui costi: https://azure.microsoft.com/it-it/pricing/details/key-vault/

Per velocizzare le cose utilizzeremo un’applicazione d’esempio che Microsoft mette a disposizione: https://www.microsoft.com/en-us/download/details.aspx?id=45343

Installare Azure PowerShell da PowerShell Gallery

Verifichiamo l’installazione di PowerShellGet:

Get-Module PowerShellGet -list Select-Object Name,Version,Path

Se il risultato è quanto segue, abbiamo già cosa serve:

In caso contrario, installiamo il seguente update:

https://www.microsoft.com/en-us/download/details.aspx?id=51451

Eseguendo PowerShell come amministratore, lanciamo il comando:

Install-Module AzureRM

Nel caso in cui fosse la prima volta che utilizziamo PowerShell Gallery, ci verrà richiesta una conferma prima di installare il modulo.

Confermiamo quindi l’installazione e, una volta terminata, importiamo i nuovi moduli con il comando:

Import-Module AzureRM

A questo punto siamo pronti per iniziare!

Configurare il KeyVault

Il primo passo consiste nell’effettuare il login alla propria sottoscrizione su Azure:

Login-AzureRmAccount

Selezioniamo la specifica sottoscrizione con i comandi:

Get-AzureRmSubscription

Set-AzureRmContext -SubscriptionId <subscription ID>

Creiamo un nuovo Resource Group, che con molta poca fantasia chiameremo “NewResourceGroup”, nel quale effettuare le nostre configurazioni:

New-AzureRmResourceGroup –Name ‘NewResourceGroup’ –Location ‘West Europe’

A questo punto possiamo creare un nuovo KeyVault associato al resource group:

New-AzureRmKeyVault -VaultName ‘FKeyVault’ -ResourceGroupName ‘NewResourceGroup’ -Location ‘West Europe’


L’output di quest’ultimo comando mostra una delle proprietà più importanti: il Vault URI. Tutte le applicazioni che dovranno utilizzare il nuovo KeyVault attraverso le API Rest lo faranno attraverso questo URI.

Aggiungiamo una key al nostro KeyVault:

$key Add-AzureKeyVaultKey -VaultName ‘FKeyVault’ -Name ‘NewKey’ -Destination ‘Software’

Per verificare l’URI, utilizziamo il comando:

$Key.key.kid


Per configurare una stringa a questa chiave, ad esempio una password chiamata “Segreto” il cui valore è “123password”, è necessario effettuare due operazioni:

  • convertire la stringa in una stringa sicura;
  • associare la stringa sicura alla chiave.

$secretval ConvertTo-SecureString ‘123password’ -AsPlainText –Force

$secret Set-AzureKeyVaultSecret -VaultName ‘FKeyVault’ -Name ‘Segreto’ -SecretValue $secretval

Per verificarne l’URI:

$secret.Id


Per verificare quanto appena configurato:

Get-AzureKeyVaultKey –VaultName ‘NKeyVault’

Get-AzureKeyVaultSecret –VaultName ‘NKeyVault’

Configurare l’applicazione

Dopo aver scaricato l’applicazione d’esempio, apriamo la solution con Visual Studio


Contestualmente nella directory scripts troveremo lo script GetAppConfigSettings.ps1 da modificare ed eseguire.


È sufficiente modificare le prime righe configurando ciò che abbiamo appena creato:

  • Nome del KeyVault
  • Nome del Resurce Group
  • Nome dell’applicazione


Eseguiamo lo script.

Quando richiesto, inseriamo una password per il certificato.

Al termine dell’esecuzione dello script in output avremo delle chiavi da inserire all’interno del file app.config dell’applicazione.


Caricando lo snap-in dei certificati relativi all’account locale è possibile comprovare l’avvenuta creazione del certificato, senza il quale l’applicazione non sarà in grado di verificare le credenziali su Azure.


Le applicazioni che utilizzano KeyVault devono autenticarsi utilizzando un token generato da Active Directory, nel nostro caso Azure Active Directory.

Per farlo, clicchiamo su “Azure Active Directory”, successivamente su “App registrations” e cerchiamo la nostra applicazione HelloKeyVault.


Abilitiamo l’applicazione all’utilizzo della chiave copiando il clientID (Application ID) e utilizziamo il seguente comando:

Set-AzureRmKeyVaultAccessPolicy -VaultName ‘FKeyVault’ -ServicePrincipalName 341efa38-faf5-459e-903a-05e9a5ad7309 -PermissionsToKeys all

Per verificare che tutto sia andato a buon fine proviamo a eseguire l’applicazione dal sistema in cui è installato il certificato. In questo modo vedremo come questa utilizzi il KeyVault generato e la relativa chiave, con la possibilità di eseguire tutte le operazioni che il KeyVault stesso mette a disposizione:


Conclusioni

La sicurezza è sempre una tematica attuale e, spesso, sottovalutata.

In questo contesto, Azure fornisce delle soluzioni pratiche anche per quei clienti spaventati dall’avere i propri dati sul Cloud.

Fornire agli sviluppatori delle chiavi crittografate, centralizzandone la gestione e mantenendo uno standard di sicurezza adeguato è solo uno dei pregi di questa soluzione, benché sia facilmente intuibile di aver trattato solo scalfito la superficie di quest’ampia tematica.

StarWind Cloud VTL per AWS e Veeam

StarWind Cloud VTL per AWS e Veeam

starwindcloudvtlawsveeam01

StarWind Cloud VTL per AWS e Veeam è un nuovo prodotto StarWind che elimina la necessità della cassetta fisica emulando il tape hardware standard.

Questa soluzione aggiunge un livello di cloud storage all’infrastruttura di backup garantendo la conformità con la regola di backup 3-2-1. Viene creata una copia di backup aggiuntiva sostituendo il costoso storage locale con uno storage cloud più conveniente come Amazon S3 e Glacier

StarWind Cloud VTL per AWS e Veeam può essere integrato nell’infrastruttura di backup esistente senza l’aggiunta di software di terze parti.

 

La regola di backup 3-2-1

Per garantire di avere i propri dati sempre disponibili, una buona strategia di backup deve rispettare la regola del 3-2-1:

  • 3 copie dei propri dati
  • 2 diversi supporti
  • 1 backup fuori sede

starwindcloudvtlawsveeam02

 

Come funziona StarWind Cloud VTL

Il backup effettuato su cassetta non solo richiede più tempo, ma deve essere organizzato attentamente. Lo staff IT deve gestire le cassette, ruotarle, monitorare i backup e così via. Le cassette e la loro archiviazione fuori sede richiedono costi aggiuntivi presentando un certo rischio di errore poichè è un processo completamente manuale.

Il concetto dietro questa soluzione consiste nel sostituire le cassette fisiche nell’infrastruttura di backup esistente fornendo una replica completamente automatizzata e una collocazione sullo storage cloud Amazon. I dati vengono replicati su uno storage cloud veloce Amazon S3 fornendo una riorganizzazione efficiente verso il più economico Glacier.

starwindcloudvtlawsveeam03

Questa nuova soluzione porta i seguenti benefici:

  • Implementazione della strategia di backup Disk-to-Disk-to-Cloud (D2D2C)
  • StarWind Cloud VTL è una soluzione compatibile con Veeam
  • La capacità di aggiungere un livello di backup tra il cloud storage con diverse prestazioni e le specifiche di efficienza

 

Cos’è il VTL

Utilizzando un backup basato su tape, il trasferimento dei dati è generalmente lento ed incrementa l’RTO. Per velocizzare il processo l’unica possibile soluzione è l’utilizzo della cache dei dischi. Utilizzando la cache come virtual tape library (VTL), i dati vengono scritti nella cache (dischi SATA) in maniera più veloce permettendo di stare nella finestra di backup eliminando il carico verso l’infrastruttura.

starwindcloudvtlawsveeam04

StarWind Virtual Tape Library (VTL) converte gli economici drive SATA in tape virtuali emulando l’esistente cassetta hardware con la possibilità di scaricare i dati nello storage cloud pubblico come Amazon Glacier e Amazon S3, decisamente meno costosi.

Questa soluzione permette inoltre di soddisfare la regola di backup 3-2-1.

 

Integrazione con Veeam

StarWind Cloud VTL è una soluzione compatibile con Veeam ed ogni componente software è stato testato e verificato per garantirne la piena compatibilità.

La tecnologia VTL sarà introdotta nella prossima release Veeam Backup & Replication v10.

starwindcloudvtlawsveeam05

StarWind Cloud VTL per AWS e Veeam è disponibile come 30-day trial per poter testare e provare l’applicazione.

signature

Copyright Nolabnoparty. All Rights Reserved.

Turbonomic 5.9 amplia la visibilità del cloud

Turbonomic 5.9 amplia la visibilità del cloud

turbonomic59released01

Turbonomic ha rilasciato la nuova release 5.9 che introduce importanti nuove funzioni per gestire i costi e il posizionamento dei sistemi nel cloud ibrido.

La nuova release estende le funzionalità della piattaforma on-premises con il nuovo supporto per gli ambienti di cloud pubblico Amazon Web Services (AWS) e Microsoft Azure rendendo più semplice la migrazione verso il cloud ibrido ottenendo le massime prestazioni al costo minimo.

turbonomic59released02

Anche la versione 5.9 offre ancora la vecchia GUI poichè la nuova UI HTML5 è ancora in fase di sviluppo e probabilmente farà il suo debutto nella prossima versione 6.0.

 

Novità

Nella versione 5.9 sono state introdotte alcune interessantissime funzioni. Il processamento è stato migliorato notevolmente ed è ora da 100 fino a 400 volte più veloce. La tebella sottostante mostra alcuni esempi del tempo richiesto per l’analisi dell’ambiente in base al numero delle VM.

turbonomic59released03

 

Abbassare i costi Cloud

Turbonomic ora visualizza i costi in tempo reale dei propri sistemi posizionati negli ambienti AWS ed Azure. E’ possibile consultare analisi dettagliate raggruppate in diverse visualizzazioni per meglio analizzare i costi in base alle prestazioni.

turbonomic59released04

Cloud Account – è disponibile il dettaglio costi per Cloud Account.

turbonomic59released05

Cloud Service Provider – è possibile visualizzare anche il dettaglio costi per Cloud Service Provider.

turbonomic59released06

Budget Management – è possibile specificare un budget mensile fisso da spendere fornendo il miglior posizionamento possibile con i target cloud disponibili.

turbonomic59released07

 

Pianificazione migrazione Cloud

E’ un tool molto interessante che permette agli amministratori di migrare verso AWS ed Azure in modo preciso e sotto budget. I piani di migrazione sono basati sulla propria infrastruttura posizionando i sistemi nelle zone e regioni più idonee a fornire prestazioni affidabili al minor costo

La procedura è molto semplice ed intuitiva. Dalla sezione Global Environment, cliccare sul bottone PLAN.

turbonomic59released08

Selezionare la voce Migrate to Public Cloud come tipologia di piano.

turbonomic59released09

Selezionare le VM da migrare.

turbonomic59released10

E’ possibile scegliere su quale provider si desidera migrare (AWS, Azure o entrambi) e le regioni disponibili. Selezionare i Provider e le Regions desiderate.

turbonomic59released11

L’applicativo visualizza i costi con o senza Turbonomic per il piano selezionato mostrando le differenze in termini di risparmio.

turbonomic59released12

 

Compliance Assurance

I sistemi configurati in HA sono posizionati in regioni cloud multiple e zone di disponibilità o data center, cluster e host on-premises rispettando le specifiche di gestione del rischio per le applicazioni critiche.

 

Assure Performance

I sistemi applicativi possono ricevere le risorse che necessitano, quando ne necessitano continuamente in tempo reale al costo minore.

I costi possono essere controllati con Turbonomic grazie alla sua funzionalità di ridurre o sospendere automaticamente le istanze quando non sono necessarie senza impatti sulle prestazioni.

turbonomic59released13

 

Visibilità Cloud Ibrido

Con Turbonomic 5.9 si ha a disposizione la visione globale da un’unica schermata del consumo delle risorse tra data center on-premises e servizi cloud.

turbonomic59released14

Le funzionalità introdotte nella versione 5.9 rendono Turbonomic una soluzione unica in grado di ottimizzare i costi, la gestione e le prestazioni dei sistemi on-premises ed in cloud. Informazioni aggiuntive possono essere consultate presso il sito web Turbonomic.

signature

Copyright Nolabnoparty. All Rights Reserved.

Adozione di Office 365 indolore con gli strumenti di Office365Italia.com

Oggi vi segnalo un’iniziativa molto interessante che riguarda il mondo che gira intorno all’offerta cloud di collaboration di Microsoft: il sito https://www.office365italia.com, un’offerta per aiutare l’adozione in azienda degli strumenti di Office 365 e SharePoint in modalità eLearning.
Office 365, presente da anni sul mercato, è ormai una piattaforma solida e in grado di offrire strumenti utili al nostro lavoro di tutti i giorni, sia in privato che in collaborazione con colleghi o persone esterne all’azienda. Strumenti, molto integrati gli uni con gli altri, che vengono tenuti aggiornati con cadenza mensile e rinnovati nelle loro funzionalità.
Passare ad Office 365 è una passeggiata dal punto di vista tecnico, ma necessita di un piano di adozione ad hoc per gli utenti finali, utile a facilitare l’adozione dei nuovi strumenti in azienda. Bisogna tenere sempre ben a mente che la formazione per gli utenti finali è la base per l’introduzione di qualsiasi nuovo software in azienda e anche in questo caso non possiamo certo sentirci esclusi da questo dato di fatto.
Ecco quindi dove si posiziona Office365Italia.com: con centinaia di video corsi, fatti ognuno da brevi lezioni, è possibile formare gli utenti finali della propria intranet all’utilizzo dei principali strumenti di Office 365 contenendo i costi di formazione con la possibilità, allo stesso tempo, di coprire una popolazione aziendale molto ampia.
Assieme all’offerta di supporto all’adozione in modalità eLearning, è possibile integrare attraverso attività formative on-site, corsi 1 to 1 in video-conferenza e webinar.
Per chi di voi è interessato ad approfondire, Office365Italia.com ci offre gratis 5 licenze del corso di OneDrive for Business.
Scrivete pure a contatta@office365italia.com dando come riferimento il sito ictpower.it 😉

Nic

Configurare diversi indirizzi IP per la stessa scheda di rete nelle VM in Microsoft Azure

Una delle novità più interessanti in ambito Networking riguardo Microsoft Azure è stata presentata pochi giorni fa nell’annuncio General availability: Multiple IP addresses per network interface

Trovo questa funzionalità particolarmente interessante perché risolve diversi problemi che mi avevano posto alcuni clienti. Ad esempio una web agency che ha creato diversi web server in Microsoft Azure ha bisogno di far girare diversi siti web e servizi con differenti indirizzi IP e certificati digitali sulla stessa scheda di rete della VM.

Questo tipo di funzionalità è utilizzabile per poter creare dei bilanciatori di carico o dei firewall utilizzando macchine virtuali gestite da noi.

È anche disponibile da pochissimi giorni la possibilità di avere almeno due schede di rete in tutte le macchine virtuali (Windows e Linux) create in Azure, come annunciato in General availability: Dual network interfaces for all Azure VMs

Per poter assegnare alla stessa scheda di rete due indirizzi IP diversi è sufficiente collegarsi al portale di Azure, selezionare la VM da modificare e cliccare sulla scheda di rete utilizzata dalla VM, come mostrato in figura:

Figura 1: Selezione dell’interfaccia di rete da modificare per la VM

Dopo aver cliccato sull’interfaccia di rete interessata, nel nuovo blade che vi si aprirà selezionate IP Configurations e cliccate sul pulsante Add per aggiungere un nuovo indirizzo, come mostrato in figura:

Figura 2: Blade IP Configurations per la scheda da modificare

Nel Blade Add IP configuration scegliete un nome simbolico per l’indirizzo IP da aggiungere, scegliete se volete mantenere statico o dinamico l’indirizzo IP privato (vi consiglio di mantenerlo statico) e successivamente scegliete se volete abilitare l’indirizzo IP Pubblico, come mostrato in figura:

Figura 3: Aggiunta del secondo indirizzo IP pubblico

Una volta completata la procedura ed assegnato il nome al secondo indirizzo IP pubblico vi verrà mostrata la schermata con gli indirizzamenti per la vostra scheda di rete, come mostrato in figura:

Figura 4: Indirizzamenti IP privati e pubblici per la scheda di rete della VM

Avete un numero limitato di indirizzi IP privati e pubblici da assegnare, come documentato dall’articolo https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits?toc=%2fazure%2fvirtual-network%2ftoc.json#azure-resource-manager-virtual-networking-limits

Per completare l’operazione è necessario collegarsi in desktop remoto alla macchina virtuale ed assegnare gli indirizzi privati manualmente. Se infatti eseguite il comando ipconfig /all all’interno della VM vedrete che verrà visualizzato solo l’indirizzo primario, come mostrato in figura:

Figura 5: Presenza solo dell’indirizzo Primario assegnato alla scheda di rete della VM

Modificate le proprietà della scheda di rete aggiungendo manualmente gli indirizzi IP interni che avete assegnato staticamente nel portale di Azure, come mostrato in figura:

Figura 6: Assegnazione statica degli indirizzi privati scelti

Dopo aver assegnato gli indirizzi (attenti a non sbagliare perché altrimenti non vi riconnetterete più alla VM) la connessione in desktop remoto potrebbe disconnettersi per un secondo, ma poi sarete nuovamente collegati.

Rilanciando il comando ipconfig /all potrete verificare che adesso la scheda di rete ha i due IP interni che avete assegnato, come mostrato in figura:

Figura 7: Scheda di rete con doppio indirizzo IP interno

La macchina virtuale sarà raggiungibile in Desktop remoto su tutti gli indirizzi pubblici che avete assegnato, in quanto le regole di firewall sono definite dallo stesso Network Security Group.

Volendo è possibile dare un’occhiata alle proprie configurazioni di rete utilizzando lo strumento Network Watcher, che è possibile abilitare per ogni regione. Cliccate su Monitor nella Dashboard e abilitate il Network Watcher per le regioni disponibili per la vostra sottoscrizione.

Figura 8: Abilitazione del Network Watcher

Tra le funzionalità messe a disposizione del Network Watcher c’è la visualizzazione della Topologia del proprio scenario di rete, che mostra le varie interconnessioni e le associazioni tra le risorse di rete in un gruppo di risorse. Dal menù a tendina in alto scegliete la vostra sottoscrizione, il resource group e la scheda di rete da monitorare e vi verrà creata automaticamente la topologia di rete, con le diverse connessioni, come mostrato in figura:

Figura 9: Topologia di rete creata col Network Watcher

Conclusioni

La possibilità di avere due schede di rete su tutte le macchine virtuali in Azure e assegnare alla stessa scheda di rete diversi indirizzi IP, sia pubblici che privati, ci permette di implementare degli scenari di networking anche complesso che finora non era possibile realizzare. Creare bilanciatori di carico e firewall con le macchine virtuali su Azure non è mai stato così facile!