Archivi categoria: Azure

SQL Server: i retroscena del porting Linux

SQL Server 2017

Fonte: sito ufficiale Microsoft

Questa settimana è stata rilasciata la release candidate 1 (RC1) di SQL Server 2017, prossima major release (sviluppata a tempo di record) del noto RDBMS Microsoft. All’indomani dell’annuncio ufficiale, TechChrunch ha avuto modo di parlare direttamente con uno dei membri del team che ha supervisionato il complesso e delicato porting di SLQ Server su Linux:  Rohan Kumar (general manager Database Systems group presso Microsoft).

A rendere possibile lo sbarco di SQL in ambienti Linux è stata la nomina di Satya Nadella a CEO della compagnia. Lo conferma indirettamente Kumar in questo passaggio:

In passato abbiamo avuto un paio di colloqui [sulla questione del porting Linux ma il progetto non fu approvato]. Non era qualcosa che veniva considerato strategico per il [nostro business]”. Ma tre anni fa – con Satya Nadella ai vertici della compagnia – il team decise di riproporre nuovamente il progetto. ” La cosa più sorprendente è che ci aspettavamo [diverse esitazioni da parte dei piani alti]. Fu una sorpresa constatare la rapidità con la quale fu presa la decisione [di approvare il progetto].

In seconda battuta bisogna poi ricordare i feedback ricevuti dalle aziende. Kumar afferma che, sebbene SQL Server venisse sempre più di frequente utilizzato per workload mission critical, quindi un ottimo segnale per Redmond, diverse compagnie trovavano limitante il dover utilizzare obbligatoriamente Windows Server – tenendo conto della crescente popolarità degli ambienti di lavoro misti (Windows/Linux) in ambito enterprise. Molte aziende cercavano poi un’alternativa ai prodotti Oracle: a coloro che volevano utilizzare un database relazionale proprietario (avvalendosi del supporto enterprise) su Linux il mercato non offriva molte soluzioni.

Parlando con le imprese [abbiamo capito che il porting era necessario]. Stavamo obbligando i nostri clienti ad utilizzare Windows come piattaforma principale.

E’ il caso di notare come il giornalista sottolinei il cambio di mentalità in casa Microsoft: in passato (in un’altra “incarnazione” di Microsoft) quanto appena evidenziato da Kumar non sarebbe stato giudicato come un fattore negativo.

Pianificazione del porting SQL Server

Una volta ottenuta l’approvazione dei piani alti, il team di Kumar si è trovato davanti ad un problema apparentemente insormontabile: come effettuare il porting Linux di milioni di linee di codice senza sacrificare funzionalità ed altre caratteristiche? Sono stati due gli elementi che hanno consentito ai programmatori di rendere possibile l’arrivo di SQL Server su Linux: Drawbridge e SQLOS.

Il primo è un progetto sperimentale (interno all’azienda) avviato nel 2011 e riscoperto, per fortuna di Kumar e colleghi, proprio in quel periodo. L’idea alla base di Drawbridge era quella incrementare la sicurezza delle VM: per ottenere questo risultato si era pensato ad un container con una versione minale di Windows in grado di eseguire applicazioni, gestire la memoria ed altre importanti funzioni integrandosi allo stesso tempo con il sistema operativo sottostante.

SQLOS è invece una parte fondamentale del database relazionale Microsoft pensata per eseguire funzioni solitamente ad appannaggio dei sistemi operativi. Nell’articolo si spiega sinteticamente che ad SQL Server la piattaforma Windows Server stava “stretta”, era necessario gestire “in prima persona” determinate task – come la gestione della memoria. Ed è grazie all’OS Layer che SQL Server è stato in grado di gestire ad esempio la memoria in Drawbridge, osserva l’editorialista. Il passo successivo è stato quello di far convergere l’SQL OS Layer e Drawbridge nell’SQL Platform Abstraction Layer – grazie al quale SQL Server è in grado di funzionare sia su Windows che Linux.

Per quanto riguarda le prossime release…

Anche se SQL Server Linux raggiungerà la disponibilità generale entro la fine dell’anno, alcune compagnie hanno già avuto l’occasione di testarlo in produzione constatando, afferma l’articolo, prestazioni allineate alla controparte Windows (logicamente a parità di hardware).

Interessante infine il commento di Kumar circa la finestra di rilascio della prossima major release (SQL Server 2018): sebbene occorra innovare costantemente le proprie soluzioni per restare altamente competitivi nel settore, non tutti i clienti Microsoft gradiscono aggiornare frequentemente i propri sistemi mission critical – procedura alquanto delicata. Questo significa che SQL Server 2018 uscirà più tardi del previsto? Il giornalista di TechCrunch non ne è molto sicuro.

Fonte: 1

 

 

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.

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.

Intervista a Scott Guthrie: Azure Stack e piattaforme per gli sviluppatori

Scott Guthrie

Pare che Scott Guthrie indossi frequentemente t-shirt rosse.

Il giornalista che ha recentemente intervistato Scott Guthrie afferma di averlo incontrato per la prima volta nel 2000. A quei tempi supervisionava il progetto ASP+, un framework di sviluppo che sarebbe stato rinominato successivamente ASP.NET ed implementato nella piattaforma Microsoft. Guthrie si è poi occupato dello “sfortunato” Silverlight.

Nel 2011 Scott inizia la sua avventura in Azure, piattaforma ancora “giovane” in cerca di una propria identità e di un solido porftfolio: le funzionalità che arrivarano di lì a poco (durable VM, scalable Azure website ed un nuovo portale per gli Admin) rappresentarano sicuramente un passo  avanti per la piattaforma cloud che iniziò a presentarsi come una delle valide competitrici di AWS.

In occasione di un evento (Business Forward) tenutosi il mese scorso a Londra , il giornalista di The Register ha avuto modo di scambiare nuovamente due chiacchere con l’attuale VP della divisione Cloud and Enterprise Microsoft (carica che ricopre dal 2014).

 Di seguito le parti più interessanti; per l’intervista completa vi rimandiamo come sempre al link menzionato nella sezione delle fonti.

The Register (TR): In passato la creazione di ASP.NET fu il tentativo di semplicare la programmazione Web. Quale è invece l’attuale strategia Microsoft [per il mondo degli sviluppatori]?

Scott Guthrie (SG): [Ci stiamo focalizzando sul rendere disponibili i servizi Office via API o blocchi integrabili. Ad esempio cose come Microsoft Teams ed il nostro Bot Framework. […] [Un altro esempio è] Office 365 che utilizza l’Azure Active Directory, quindi la possibilità di adoperare gli stessi meccanismi di autenticazione ed autorizzazione con tutte le tue app, VM, container e risorse. [Altre a questo, ci sono i 100 milioni di utenti Enterprise attivi ogni mese che utilizzano quotidianamente Office 365. Puoi incrementare il valore delle tue app e renderle ancora più semplici da utilizzare].

The Register (TR): Il Regno Unito ha una propria region Azure [che è stata aperta circa un anno fa]. Abbiamo tuttavia sentito parlare di diverse problematiche di “capienza” e di clienti ai quali è stato chiesto di [cambiare region]. Perchè tutti questi problemi?

(SG): Generalmente non abbiamo problemi di capienza nei data center. Continuiamo a costruire data center. A volte – e succede a tutti i cloud vendor – possiamo però avere [scarsa disponibilità] di particolari tipologie di VM e server. Su Azure clienti possono “riservare” una determinata quota [di risorse]. C’è stato un periodo tra Aprile e Maggio in cui per una settimana circa abbiamo imposto un limite alla quota riservabile dai nuovi clienti. La crescita della nostra region del Regno Unito è quattro volte superiore a quanto preventivato dal nostro business plan. Dovevamo attivare più server ed attualmente non abbiamo alcuna restrizione sulle quote riservabili.

The Register (TR): perchè Azure Stack è [un sistema chiuso] che richiede l’acquisto di un sistema preconfigurato?

(SG): Quel che ci è stato riferito dai clienti, ed il motivo per cui abbiamo optato per il supporto [al solo] hardware pre-certificato, sono alcune delle esperienze che la gente ha avuto con OpenStack ed altre tecnologie, con le quali hanno avuto serie difficoltà ad effettuare i deploy ed eseguire [varie soluzioni] in ambienti di produzione.

Il cloud non è solo [capacità di calcolo] ma anche reti, sistemi di storage e [vari elementi condivisi tra questi ultimi]. Se le performance subiscono un drastico calo, ti rivolgi al produttore del server, al produttore della strumentazione di rete, a quello del load balancer o dello storage? Solitamente [si assiste ad uno scaricabarile] e tu impiegherai settimane e mesi [a mettere in sesto il tuo ambiente cloud]. Abbiamo parlato con numerosi clienti che ci hanno detto “per favore non fatelo”. Il modello che abbiamo invece deciso di proporre contempla la collaborazione con il più ampio numero di hardware provider [:] HP, Dell, Lenovo, Cisco e Huawei. Questi sono i cinque più grandi produttori di server al mondo ed avranno sistemi che partono da tre nodi, [non si tratta quindi di acquisti impegnativi]. […] E potrai avere nel giro di uno o due giorni  un ambiente cloud operativo . […]

The Register (TR): Ora che Microsoft si è focalizzata sulle tecnologie cloud i suoi prodotti on-premise hanno perso rilevanza?

(SG): Penso che le soluzioni on premise stiano avanzando rapidamente. Prendiamo ad esempio SQL Server, in precedenza rilasciavamo una nuova versione ogni due o tre anni. L’anno scorso, con SQL 2016, abbiamo probabilmente avuto la più grande release SQL di sempre. […] Sei mesi fa abbiamo rilasciato SQL 2016 SP1. […] Questa estate rilasceremo SQL 2017 ed è la prima volta che rendiamo disponibile una major rev di SQL nell’arco di 12 mesi. Quella versione sarà eseguibile su Linux, Docker […].

Fonte: 1

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.

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.

How to: installare Azure Powershell

Chi come me segue il mondo Microsoft da tanti anni sa sicuramente che dietro a tutti i sistemi operativi e prodotti c’è Powershell.

Automatismo, velocità e potenza sono solo alcuni dei vantaggi di conoscere Powershell per ottimizzare al meglio la gestione della nostra infrastruttura, “on premise” e in “Cloud” (Microsoft Azure). In questa mini guida vediamo come installare il modulo per gestire le nostre risorse in Azure.

Step 1

Primo passo è quello di verificare se abbiamo, sulla nostra macchina, installato il modulo PowerShellGet necessario per installare gli elementi dalla Powershell Gallery.

Eseguire il seguente comando:

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

 L’ouput sarà simile alla seguente schermata:

PS C:\WINDOWS\system32> Get-Module PowerShellGet -list | Select-Object Name,Version,Path

Name                Version Path
—-                    ——-    —-
PowerShellGet   1.0.0.1  C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PowerShellGet.psd1

Se così non fosse seguire questo articolo (Come ottenere PowerShellGet) per installarlo.

Step 2

Secondo passo è quello di installare Azure Powershell così da poter amministrare e gestire le risorse che abbiamo in Azure.

Eseguire il seguente comando (con privilegi elevati):

# Install the Azure Resource Manager modules from the PowerShell Gallery
Install-Module AzureRM

La prima volta che eseguite il comando vi verranno presentati i seguenti messaggi, rispondete “S” al primo e “S” o “T” al secondo per proseguire:

PS C:\WINDOWS\system32> Install-Module AzureRM

Per continuare è necessario il provider NuGet
PowerShellGet richiede il provider NuGet versione ‘2.8.5.201’ o successiva per interagire con i repository basati su
NuGet. Il provider NuGet deve essere disponibile in ‘C:\Program Files\PackageManagement\ProviderAssemblies’ o
‘C:\Users\m.serra\AppData\Local\PackageManagement\ProviderAssemblies’. Puoi anche installare il provider NuGet
eseguendo ‘Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force’. Vuoi che PowerShellGet installi e
importi ora il provider NuGet?
[S] Sì  [N] No  [O] Sospendi  [?] Guida (il valore predefinito è “S”): S

Archivio non attendibile
Stai installando i moduli da un archivio non attendibile. Se ritieni attendibile questo archivio, modifica il relativo
valore InstallationPolicy eseguendo il cmdlet Set-PSRepository. Vuoi installare i moduli da ‘PSGallery’?
[S] Sì  [T] Sì a tutti  [N] No  [U] No a tutti  [O] Sospendi  [?] Guida (il valore predefinito è “N”): Si

Attendere l’installazione dei vari pacchetti.

image

Se si dispone di una versione precedente alla versione 2.8.5.201 di NuGet, viene richiesto di scaricare e installare la versione più recente di NuGet.

Il modulo AzureRM è un modulo di rollup per i cmdlet di Azure Resource Manager, qualsiasi modulo di Azure PowerShell non installato precedentemente viene scaricato da PowerShell Gallery.

Se è installata una versione precedente di Azure PowerShell verrà visualizzato un errore, per risolverlo seguire questo articolo: Eseguire l’aggiornamento a una nuova versione di Azure PowerShell.

Step 3

Dopo aver installato il modulo, è necessario importarlo in una sessione di PowerShell per avere disponibili tutti i cmdlet.

Eseguire il seguente comando (con o senza privilegi elevati):

Import-Module AzureRM

Nota: se vi esce il seguente errore verificare se l’esecuzione degli script e abilitata con il comando Get-ExecutionPolicy

PS C:\WINDOWS\system32> Import-Module AzureRM
Import-Module : Impossibile caricare il file C:\Program Files\WindowsPowerShell\Modules\AzureRM\4.0.2\AzureRM.psm1.
L’esecuzione di script è disattivata nel sistema in uso. Per ulteriori informazioni, vedere about_Execution_Policies
all’indirizzo
http://go.microsoft.com/fwlink/?LinkID=135170.
In riga:1 car:1
+ Import-Module AzureRM
+ ~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : Errore di protezione: (:) [Import-Module], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess,Microsoft.PowerShell.Commands.ImportModuleCommand

Se è in Restricted mode eseguire il seguente comando per sbloccare l’esecuzione degli script  erispondere “S” alla domanda.

Set-ExecutionPolicy Unrestricted

Modifica ai criteri di esecuzione
I criteri di esecuzione facilitano la protezione dagli script non attendibili. La modifica dei criteri di esecuzione
potrebbe esporre l’utente ai rischi di sicurezza descritti nell’argomento della Guida about_Execution_Policies
all’indirizzo http://go.microsoft.com/fwlink/?LinkID=135170. Modificare i criteri di esecuzione?
[S] Sì  [T] Sì a tutti  [N] No  [U] No a tutti  [O] Sospendi  [?] Guida (il valore predefinito è “N”):

Step 4 – Aggiornare Azure Powershell

Se si volesse aggiornare ad una versione più recente Azure Powershell esegiure il seguente comando:

# Install the Azure Resource Manager modules from the PowerShell Gallery
Install-Module AzureRM –AllowClobber

Altri comandi e link utili:

Controllo della versione di Azure Powershell

Get-Module AzureRM -list | Select-Object Name,Version,Path

Come ottenere PowerShellGet

Versione sistema operativo: Il sistema operativo è Windows 10 o Windows Server 2016 –> Integrato in Windows Management Framework (WMF) 5.0 incluso nel sistema operativo
Versione sistema operativo: si vuole eseguire l’aggiornamento a PowerShell 5 –> Installare la versione più recente di WMF

Versione sistema operativo: è in esecuzione una versione di Windows con PowerShell 3 o 4 –> Ottenere i moduli PackageManagement

Altri metodi di installazione

Per informazioni sull’installazione con altri metodi (piattaforma Web o il pacchetto MSI): Other installation methods

Guida ad Azure Powershell

Per altre informazioni sull’uso di Azure PowerShell:  Guida introduttiva ad Azure PowerShell

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

VeeamON 2017 annunciati i nuovi prodotti

VeeamON 2017 annunciati i nuovi prodotti

veeamon2017neworleans01

Durante il recente VeeamON 2017 in New Orleans, Veeam ha annunciato diversi nuovi prodotti e rilasci focalizzando l’attenzione dei numerosi partecipanti.

Veeam Availability Suite v10, Veeam Backup for Office 365 1.5, Veeam Availability for AWS sono alcune delle anticipazioni rivelate durante il VeeamON 2017.

VeeamON è un evento di 3 giornate di Veeam dove vengono annunciati i prodotti nuovi e di imminente uscita supportati da più di 85 sessioni di presentazione, includendo gli approfondimenti tecnici tenuti dai massimi esperti del settore.

 

Veeam Availability Suite v10

L’annuncio principale è stata la presentazione della prossima Veeam Availability Suite v10 che introduce nuove funzionalità ed importanti miglioramenti.

 

Veeam CDP

Veeam CDP è probabilmente la funzione più interessante che fornisce una protezione continua dei dati. La nuova soluzione non utilizza le snapshot (quindi non ha impatto sui carichi protetti) ma si affida alla nuova tecnologia VMware vSphere API for I/O filtering (VAIO) per intercettare i flussi di dati che continuamente invia alle repliche pronte per essere avviate con un RPO di default pari a 15 secondi.

veeamon2017neworleans02

 

Supporto per i backup di file sharing e dei network attached storage (NAS)

La versione 10 è in grado di proteggere le condivisioni SMB (CIFS) ed NFS con un backup scalabile disk to disk con varie opzioni di restore e il pieno supporto del versioning.

E’ presente inoltre l’opzione per specificare policy di retention brevi ed estese con la funzione di effettuare il restore dei file SMB/NFS verso qualsiasi target.

veeamon2017neworleans03

 

Integrazione degli Agenti Windows e Linux

La nuova versione presenta un’integrazione completa degli Agents for Windows e Linux con Veeam Backup & Replication. Questo include l’installazione automatica dell’agente e la gestione del job per le virtual machine nonchè le workstation fisiche, server e failover clusters.

veeamon2017neworleans04

 

Estensione del repository di backup Scale-Out

Il repository di backup Scale-Out attuale viene esteso con il nuovo Archive Tier che permette di spostare automaticamente i backup vecchi in storage economici implementati come device di data archiving (object storage).

Questa funzionalità permette l’utilizzo di qualsiasi sistema di storage inluso Amazon S3, Amazon Glacier e Microsoft Azure blob storage.

 

Extended Veeam “Always-On” Availability Platform

La piattaforma presenta il nuovo Universal Storage API framework che aggiunge IBM, Lenovo e INFINIDAT all’ecosistema di partner Veeam che già include HPE, Cisco, NetApp, Dell EMC, Nimble ed Exagrid.

veeamon2017neworleans05

 

Veeam Availability for AWS

Questa soluzione agentless per le applicazioni AWS permette la protezione dei dati AWS contro cancellazioni accidentali, attività maliziose ed interruzioni fornendo funzioni di backup e restore per le istanze AWS EC2 in cloud.

veeamon2017neworleans06

 

Veeam Backup for Office 365 1.5 e 2.0

Nella nuova versione Veeam Backup for Office 365 1.5 è stata aggiunta la possibilità di supportare una configurazione multi repository e multi tenant permettendo la protezione di grandi installazioni di Office 365.

Durante la presentazione, è stata annunciata anche la nuova versione 2.0 che introduce il tanto richiesto supporto per SharePoint e OneDrive for Business.

veeamon2017neworleans07

 

Veeam Agent for Windows 2.0

Il nuovo Veeam Agent for Windows 2.0 è stato ufficialmente lanciato ed include le nuove edizioni Workstation e Server con funzioni aggiuntive sviluppate per garantire la disponibilità dei carichi di lavoro di Windows:

  • Reduzione del costo e della complessità dei sistemi in esecuzione nei public cloud
  • Fornisce la protezione dei sistemi Windows che non possono essere virtualizzati
  • Raggiungimento di bassi RPO per il personale che utilizza dispositivi laptop

Il software Veeam Agent for Windows 2.0 è già disponibile per il download presso il sito web Veeam.

veeamon2017neworleans08

VeeamON Forums verrà ora presentato in alcune Ecittà Europee per connettere gli esperti IT per condividere ed imparare come garantire l’Availability per l’Always-On Enterprise.

Il prossimo VeeamON 2018 si terrà il  –  2018 in Chicago.

signature

Copyright Nolabnoparty. All Rights Reserved.