Il blog del team MSDN Italia

How to: Riattivare le macchine virtuali di Windows Azure dopo aver riattivato una sottoscrizione bloccata

Eva Gjeci — Mon, 17 Jun 2013 09:58:01 GMT

Se vi capita di superare la soglia di utilizzo delle risorse di Windows Azure associate alla vostra sottoscrizione, per esempio i 150 euro di credito mensile della trial o il credito mensile della vostra sottoscrizione MSDN, e ricevete la mail in cui vi viene segnalato che la vostra sottoscrizione è stata disabilitata, nessun PANICO.

Quello che succede quando raggiungete il limite mensile di risorse gratuite di Windows Azure e non avete precedentemente sbloccato il limite di spesa associato alla vostra sottoscrizione, è che il vostro account di archiviazione viene impostato come read-only. I file VHD delle vostre macchine virtuali rimangono nello storage ma le VM deployate vengono cancellate. Questo viene fatto perchè le macchine virtuali anche se spente riservano capacità computazionale.

Per poter “ripristinare” i vostri servizi dovete per prima cosa modificare il limite di spesa che è impostato nella vostra sottoscrizione (cosi potete stare TRANQUILLI che i vostri servizi saranno always-on).

In seguito potete utilizzare i dischi VHD delle vostre VM per creare una nuova macchina virtuale, seguendo questi passaggi:

1. Dal portale andate su New – Compute - Virtual machine – From Gallery

2. Nei Dischi personali scegliete il disco che era stato creato per la macchina virtuale precedente

3. Completate gli step successivi per creare la macchina virtuale

Nota: Per usare lo stesso DNS che era stato creato per la VM originale, è necessario cancellare il cloud services relativo prima di creare la nuova VM. In caso contrario si ottiene un errore che indica che il DNS è già in uso.

In questo modo avrete la vostra macchina virtuale con le stesse configurazioni di quella originale e con tutti i vostri dati.

Quando lavorate con le macchine virtuali fatte attenzione al disco D: , è un disco temporaneo. Il Temporary Storage (D: ), a differenza del disco OS e del disco dei dati non è persistente sullo storage di Windows Azure. I dati che memorizzate nell’unità D: vengono persi quando la macchina virtuale viene spostata o se avviene un guasto hardware. Anche nel caso illustrato precedentemente, quando vi viene disabilitato il servizio perchè avete superato la soglia limite di risorse gratuite, quando ricreate la macchina virtuale a partire dal file VHD della vostra VM originale, se avete memorizzato dei dati in D:, questi dati non li ritrovate sulla nuova macchina, sono persi.

L’unità D: è prevista solo per la memorizzazione dei dati temporanei. Non utilizzate questa unità per memorizzare dati che non volete perdere.

Di seguito trovate una guida che vi spiega come agganciare dei dichi persistenti alle vostre VM: http://www.windowsazure.com/en-us/manage/windows/how-to-guides/attach-a-disk/

Guest post: Windows Azure Service bus Topics, prima esperienza

Vito Flavio Lorusso — Fri, 14 Jun 2013 07:00:00 GMT

Questo post è stato scritto da Alessandro Alpi, MVP SQL Server

Windows Azure Service bus Topics, prima esperienza

Windows Azure fornisce un servizio chiamato Service Bus per implementare il messaging direttamente in cloud. Per avere maggiori informazioni riguardanti il messaging su Azure, leggere qui.

In questi giorni sto pensando a come implementare un notification server e sembra che il servizio suddetto possa proprio essere di aiuto. L'articolo descrive i concetti su "Queues, Topics e Subscriptions":

"These “brokered” messaging capabilities can be thought of as asynchronous, or decoupled messaging features that support publish-subscribe, temporal decoupling, and load balancing scenarios using the Service Bus messaging fabric. Decoupled communication has many advantages; for example, clients and servers can connect as needed and perform their operations in an asynchronous fashion."

Sembra proprio quello che mi serve. Ok, iniziamo a scrivere un progetto di test in modo da capire come si sviluppa una cosa del genere. Sono un dba, quindi apprezzate il mio sforzo e ovviamente, correggetemi ovunque ci fossero imprecisioni

Introduzione

Ci serve un progetto, possibilmente con Visual Studio 2012 (anche se c'è il template per 2010) con almeno tre progetti, il sender, il receiver ed un model con cui lavorare (che poi è il tipo del messaggio). Utilizzeremo il template proposto proprio da Visual Studio per la gestione di Queues (code) per poi convertirlo in uno che utilizza Topics/Subscriptions (Argomenti e sottoscrizioni). Approfondiremo il loro significato più tardi.

Step 1 - Prerequisiti

Di default, la versione corrente di Visual Studio 2012 non fornisce fin da subito. Quindi è necessario scaricare l'SDK direttamente con il web platform installer. Selezionando il linguaggio che si vuole utilizzare (nel mio caso C#), sotto la voce Cloud, è sufficiente fare doppio click sulla voce "SDK Download". La web platform scaricherà circa 40MB.

Step 2 - Nuovo progetto con Visual Studio

Aggiungendo il progetto cloud (che ho chiamato MessagingTest), la relativa soluzione verrà creata (MessagingTest anch'essa). Durante questo processo comparirà un popup in cui ci viene chiesto di scegliere che "Role" aggiungere. Noi avremo bisogno di un Worker Role, che possiamo definire come un'applicazione di Back-End (se guardate bene, troverete anche Web Role, ovvero una tipica applicazione web di frontend). Il tipo di Worker che andremo ad aggiungere è quello denominato "Worker Role With Service Bus Queue". Come si può evincere dal nome, il progetto creerà un gestore per una coda, mentre a noi serve quella a topic (argomenti) e subscriptions (sottoscrizioni). Lo cambieremo in seguito. Intanto ecco il popup di esempio:

Il template aggiungerà nel progetto il riferimento a Microsoft.ServiceBus.dll e i namespace seguenti:

using Microsoft.ServiceBus;

using Microsoft.ServiceBus.Messaging;

Sono stati aggiunti anche due tipi di file .cscfg e .csdef (il cosiddetto Windows Azure Service Configuration System) sul progetto cloud. Questi file determinano la connection string per connettersi al NAMESPACE, preventivamente creato per utilizzare il service bus. In poche parole andremo a creare un endpoint al quale invieremo messaggi alla nostra struttura (Topic per noi), utilizzando la connection string e la chiave generata direttamente dal Windows Azure Portal.

Step 3 - Configurazioni

Prendiamo ora il file ServiceConfigurationLocal.cscfg nel progetto cloud e andiamo a cambiare la connection string. Supponendo di avere un namespace <mynamespace> e una <key> formeremo una connection string così fatta:

Endpoint=sb://<mynamespace>.servicebus.windows.net/;SharedSecretIssuer=owner;SharedSecretValue=<key>

Ecco la procedura per creare la chiave direttamente dal portale.

Step 4 - Creazione del modello di messaggio

Andiamo ora a creare un progetto di tipo Class Library che chiameremo MessagingModel e che conterrà la struttura del messaggio con cui vogliamo lavorare. Possiamo parlare di "Tipo del messaggio". Aggiungiamo il progetto alla stessa soluzione:

Il modello che andremo a creare è il seguente:

Tre semplici proprietà che descrivono la struttura del nostro messaggio di notifica. Come possiamo vedere al progetto è stato aggiunto un file NotificationModel.cs in cui abbiamo definito appunto, la struttura del messaggio.

Il modello verrà referenziato dal Worker Role (perchè dovrà ricevere il messaggio e tipizzarlo per gestirlo) e dal Sender (luogo in cui il messaggio verrà composto per l'invio).

Step 5 - Preparare il message receiver (Worker Role)

Quando creiamo questo tipo di progetto, buona parte della struttura è praticamente completa. Ci sono già tre metodi, OnStart(), OnStop() e Run(). Abbiamo già la definizione della coda, la sua creazione, il caricamento delle configurazioni, la parte in cui si riceve il messaggio e così via. Sembra semplice, sì vero, ma ovviamente questo è un progetto di demo. Quando dovremo mettere mano, in base alle specifiche del consumer dell'item della coda, il progetto potrebbe complicarsi notevolmente. Pensate infatti alle varie logiche da applicare per lo smistamento e la gestione del messaggio, oppure all'applicazione di un log o di procedure di auditing, di cache e così via. In aggiunta, è possibile cambiare anche le specifiche di lettura (abbiamo PeekLock o "lettura non distruttiva" e la ReceiveAndDelete o "lettura distruttiva").

Tuttavia il progetto creato, come dicevamo, gestisce una coda e non un Topic/Subscriber. Lo scopo di questo post è convertire il tipo fornito nativamente in uno a Topic. Per capire la differenza, ecco due immagini:

Queues (code)

I vari sender inviano un messaggio alla coda, e il consumer legge un messaggio. Ogni messaggio è processato da un consumer solo alla volta.

Topics (argomenti)

I sender inviano i messaggi al topic e ogni consumer crea una sottoscrizione, creando, di fatto, una relazione uno a molti.

Ora passiamo al refactor del Worker role, partendo dalla testata, come impostarla?

Avremo bisogno di un nome topic, di un nome sottoscrizione e il client per gestire la messaggistica:

public class WorkerRole : RoleEntryPoint

{

const string TopicName = "MyFirstTopic"; // Topic name

const string SubscriptionName = "MySubscription"; // Subscription name

// client for managing messages

SubscriptionClient Client;

// stop flag

bool IsStopped;

[...]

SubscriptionName e TopicName verranno utilizzati anche nel progetto che invia i messaggi (più avanti nel post).

Ora, come definiamo il metodo OnStart()?

In questo metodo creeremo la sottoscrizione e utilizzeremo la connection string indicata nei file di configurazione:

public override bool OnStart()

{

// Set the maximum number of concurrent connections

ServicePointManager.DefaultConnectionLimit = 12;

// Get configs from config file

string connectionString = CloudConfigurationManager.GetSetting("Microsoft.ServiceBus.ConnectionString");

// Inserts a new topic if not exists

var namespaceManager = NamespaceManager.CreateFromConnectionString(connectionString);

if (!namespaceManager.TopicExists(TopicName))

{

namespaceManager.CreateTopic(TopicName);

}

// Creates the subscription if not exists

if (!namespaceManager.SubscriptionExists(TopicName, SubscriptionName))

{

namespaceManager.CreateSubscription(TopicName, SubscriptionName);

}

// Creates the subscription client

Client = SubscriptionClient.CreateFromConnectionString(connectionString, TopicName, SubscriptionName);

IsStopped = false;

return base.OnStart();

}

Il metodo CreateSubscription, utilizzato con due parametri, crea una sottoscrizione senza filtro. Per applicare filtri, è possibile utilizzare la classe SQLFilter. Ad esempio:

// The MessageType property must be set on the message when sending

namespaceManager.CreateSubscription(TopicName, SubscriptionName, new SqlFilter("MessageType = 'NOTIFICATION'"));

Il filtro deve essere impostato prima di inviare il messaggio, e chi lo gestisce deve poi applicarlo.

Come cambiare il metodo OnStop()?

Non c'è da cambiare nulla visto che disalloca già correttamente quello che utilizziamo.

Come leggere il messaggio ricevuto nel metodo Run()?

Utilizzeremo come detto la PeekLock (che è il metodo di lettura di default). In questo modo i messaggi letti non verranno "distrutti" e rimarranno nel topic. Il metodo tuttavia può essere cambiato utilizzando gli overload del metodoCreateFromConnectionString() utilizzato nell'OnStart(). Applicheremo qui di seguito un ciclo infinito che "attende" la ricezione del messaggio:

while (!IsStopped)

{

try

{

// Receive the message

BrokeredMessage receivedMessage = Client.Receive();

    if (receivedMessage != null)

    {

// Process the message

      // Do something..

receivedMessage.Complete();

    }

}

[...]

Il resto del metodo è costituito dalla gestione delle eccezioni (anche, ad esempio, per le retry). Quello che manca è il "Do something.." e proprio qui andremo ad aggiungere la Trace del nostro messaggio:

if (receivedMessage != null)

{

// Process the message (cast into our model)

NotificationModel model = receivedMessage.GetBody<NotificationModel>();

// Here's the message

Trace.WriteLine("Message id", model.NotificationId.ToString());

Trace.WriteLine("Message description", model.NotificationDescription);

Trace.WriteLine("Message date", model.NotificationDate.ToShortDateString());

receivedMessage.Complete();

}

La prima cosa che si nota è la get del messaggio. GetBody<T>() consente di castare l'oggetto ricevuto nel tipo che abbiamo disegnato appositamente. Molto comodo. T = NotificationModel.

Step 6 - Inviare il messaggio di tipo NotificationModel

Siamo quindi pronti per inviare il messaggio. Possiamo aggiungere un qualunque tipo di progetto (client), ma la cosa più semplice è creare una console application. In quest'ultima andremo a referenziare il nostro model e le due dllMicrosoft.WindowsAzure.Configuration.dll e Microsoft.ServiceBus.dll. A questo punto, nell'app.config della console andremo ad aggiungere la connectionstring nella sezione apposita, come segue:

<appSettings>

<add key="Microsoft.ServiceBus.ConnectionString" value="Endpoint=sb://<mynamespace>.servicebus.windows.net/;SharedSecretIssuer=owner;SharedSecretValue=<key>" />

</appSettings>

ed ecco il metodo Main():

NotificationModel model = new NotificationModel();

// prepare the message

model.NotificationDate = DateTime.Now;

model.NotificationDescription = "This is my first message";

model.NotificationId = 1;

// get the connection string from config (app.config in this sample)

string connectionString = CloudConfigurationManager.GetSetting("Microsoft.ServiceBus.ConnectionString");

TopicClient Client = TopicClient.CreateFromConnectionString(connectionString, TopicName);

// Create message, passing our model

BrokeredMessage message = new BrokeredMessage(model);

// Send message to the topic

Client.Send(message);

Come dicevamo prima, per creare il valore su cui filtrare poi in sottoscrizione, basta aggiungere una proprietà al volo, appena prima di inviare:

// Message type for filtering on subscription (optional)

message.Properties["MessageType"] = "NOTIFICATION";

Step 7 - Test

La solution appare come segue:

- Abbiamo un progetto MessagingTest di tipo cloud.

- Un progetto WorkerRole che alla fine è il manager del topic (receiver)

- Un progetto SendTest che è il sender (console application)

- Una class library che fa da modello condiviso, chiamato MessagingModel

Facciamo partire il worker role. Verrà creato il topic e la sottoscrizione relativa. Il debugger rimarrà in attesa della ricezione dei messaggi. Parte quindi il ciclo infinito.

Possiamo monitorare il worker utilizzando una UI chiamata "Windows Azure Compute and Storage emulator UI". Noterete nel systray un'icona dalla quale è possibile aprire la user interface (tasto destro -> "Show Compute Emulator UI"):

Quando il worker role parte la finestra cambierà in questo modo:

Come possiamo vedere il worker rimane in attesa. Per inviare il messaggio, andiamo sulla bin del progetto console ed eseguiamo il SendTest.exe. In base a come abbiamo configurato le nostre strutture, invieremo al "MyFirstTopic", con una "MyFirstSubscription", un messaggio di tipo NotificationModel. Il messaggio, a sua volta, avrà potenzialmente (se specificato) una proprietà "MessageType" come valore di filtro. Una volta che il messaggio è arrivato, vedremo quanto segue sul monitor:

Funziona! Vedo la traccia! Questo è il monitor locale, ma sul Windows Azure Portal abbiamo il monitor del cloud "reale":

se siete interessati a questo approccio nelle vostre applicazioni vi consiglio i seguenti link:

Windows Azure Service Bus

How to use Service Bus Queues

How to use Service Bus Topics

Guest Post: Conflitti durante lo sviluppo concorrente

Lorenzo Barbieri [MSFT] — Mon, 27 May 2013 08:00:00 GMT

Questo post è stato scritto da Gian Maria Ricci, MVP Visual Studio ALM

Gestione conflitti in sistemi centralizzati

I conflitti possono accadere in entrambe le tipologie di VCS (Version Control Systems), sia in quello centralizzato sia in quello distribuito, è comunque interessante capire a fondo come i vari sistemi riescano ad identificarli per permetterne la risoluzione.

Nel source control standard di Team Foundation Server i conflitti vengono rilevati sia durante la fase di Check-In, sia durante la fase di Get-Latest. Durante un Get-Latest infatti, per ogni file modificato nel server e che viene quindi scaricato per aggiornare la versione locale, Visual Studio verifica se il file ha modifiche pendenti ed in caso affermativo si ha un conflitto, poiché il file è stato modificato da due distinte parti.

In caso di conflitto Visual Studio cerca di capire se è possibile effettuare un merge automatico delle modifiche, senza richiedere dunque l’intervento manuale dell’utente. Questo accade ad esempio se le modifiche riguardano parti differenti di un file.

Nel caso non sia possibile procedere ad un merge automatico, lo sviluppatore viene notificato e si procede ad effettuare un merge manuale utilizzando Visual Studio o altri strumenti equivalenti. Come nota si consiglia comunque di controllare sempre dopo il Get-Latest se sono state scaricate nuove modifiche ed in caso affermativo, anche se non vi sono conflitti, è sempre buona norma rieseguire gli Unit Test per vedere se le modifiche scaricate sono compatibili con le modifiche pendenti locali.

Durante un check-in la situazione è invece leggermente differente; si supponga infatti che Marco abbia fatto un Get-Latest recuperando il changeset con id 100 ed inizi a lavorare su di un file. Nel frattempo Giorgio modifica lo stesso file effettuando Check-In e creando quindi un changeset con id superiore, supponiamo il 101. Per correttezza Marco dovrebbe sempre effettuare un Get-Latest e risolvere eventuali conflitti prima di tentare un check-in; supponiamo invece che utilizzi la procedura meno corretta e tenti di effettuare direttamente il check-in senza curarsi di eseguire un Get-Latest.

In questo caso durante le operazioni di check-in, per ogni file viene associato il numero di versione che tale file aveva nel workspace locale quando sono iniziate le modifiche, nel nostro esempio 100. Il server verifica quindi la versione attuale del file (in questo caso la 101 perché è stato modificato da Giorgio), e se le due versioni non corrispondono il file è stato modificato da entrambi. Anche in questo caso è possibile che le modifiche possano essere risolte da un automerge, ma in caso non siano compatibili, il check-in viene bloccato.

Questo blocco è fondamentale, perché se non ci fosse Marco avrebbe erroneamente sovrascritto ed annullato le modifiche di Giorgio. Quando il check-in viene bloccato, si rende necessario procedere ad un Get-Latest e risolvere i conflitti localmente prima di tentare nuovamente un check-in.

Gestioni conflitti in git

In un sistema distribuito la gestione dei conflitti è molto simile, ma complicata dal concetto di commit locale. In questo scenario di esempio si hanno due utenti: Gian Maria Ricci ed alkampferOutook, i quali possono modificare entrambi lo stesso file e fare commit in locale contemporaneamente. Questo accade perché il commit è locale, ogni sviluppatore ha una linea di codice composta dai suoi commit e quindi nessun conflitto si genera se due sviluppatori modificano e fanno commit di uno stesso file. Si supponga che entrambi gli sviluppatori abbiano fatto un clone di un repository, costituito per ora da un singolo commit con id 202396b ed abbiano fatto alcune modifiche creando ognuno due commit nel proprio repository locale.

NOTA: Nella descrizione seguente, ogni qualvolta si parla di origin si intende implicitamente il server remoto predefinito collegato al repository locale, che di base è il server da cui si è effettuato il clone. Data la sua natura distribuita, è possibile che il proprio repository locale Git si sincronizzi con più server (detti remote) e quindi la dicitura server può risultare ambigua, non esistendo di fatto il concetto di un unico server centralizzato.

Sebbene non si sia ancora parlato di branch, per ora si consideri semplicemente che quando si effettua il primo commit in un repository Git, viene automaticamente creata una prima branch chiamata master che costituisce l’unica branch attiva.

Quando Gian Maria Ricci tenta di effettuare il push verso il server origin, git non fa altro che verificare la posizione della branch corrispondente nel sistema destinazione e se non ci sono stati cambiamenti dall’ultima volta che è stato fatto pull esegue un fast-forward, ovvero copia semplicemente i commit nel sistema destinazione.

Quello che accade in dettaglio è: quando uno sviluppatore effettua un pull (o il clone iniziale), tutti i commit del sistema remoto vengono scaricati nel repository locale, cosi che i due repository siano perfettamente allineati ed identici (nei sistemi distribuiti infatti ogni sviluppatore ha una copia completa del repository). Quando uno sviluppatore effettua commit locali, questi vengono aggiunti sequenzialmente alla branch attiva ed ognuno ha un id (costituito da un hash SHA1), come si può vedere con un git logf. (il comando logf non è altro che un alias creato con l’istruzione git config --global alias.logf "log --graph --oneline --all --decorate")

Il dato interessante è dato dalla colorazione, che identifica in maniera univoca la situazione del repository. In primo luogo, in verde, è mostrata la branch attiva locale; la master è attualmente pari alla HEAD (è infatti l’unica branch ed è quella attiva), ed è associata all’ultimo commit con hash ca9fd1e. La master remota, ovvero quella del TF Service, è invece mostrata in rosso ed è chiamata origin/master ad indicare appunto che è la branch master del remote chiamato origin. Avendo effettuato due commit, la branch master locale è due commit più avanti della master remota, che invece è ferma al 202396b. L’operazione di push non fa altro che tentare di inviare i due commit locali al server e se nel frattempo nessuno ha effettuato operazioni di push, questi commit locali vengono semplicemente copiati nel server.

Effettuando di nuovo un log da riga di comando si può notare come ora la origin/master sia allineata alla master locale, ed i due commit sono stati correttamente copiati nel server.

Supponiamo ora che l’altro sviluppatore (AlkampferOutlook) abbia anche lui effettuato due commit e tenti di effettuare l’operazione di push. In questo caso i due commit sono sempre successivi al commit 202396b, ma nel frattempo la branch master del server è stata aggiornata ed ora punta al commit ca9fd1e. In questo caso l’operazione viene fermata, dato che non è più possibile effettuare il fast-forward; AlkampferOutlook deve quindi effettuare il merge con le modifiche che nel frattempo sono state inviate da Gian Maria Ricci. L’interfaccia suggerisce quindi di effettuare un pull (operazione analoga al get-latest) ed effettuare la merge in locale.

Tentando il push da command line il messaggio è molto più esplicito

Fetch, pull e risoluzione di conflitti in locale

La soluzione al conflitto è fare un pull, ma prima di procedere in questa direzione è preferibile entrare più a fondo nel funzionamento di git per comprendere più in dettaglio cosa accade durante questa operazione.

Una volta che il suo tentativo di Push è stato rigettato, AlkampferOutlook può effettuare un log a riga di comando per capire lo stato del suo repository.

La situazione è esattamente omologa a quella vista da Gian Maria Ricci precedentemente, ovvero la master locale è due commit più avanti della branch remota, ma questa informazione è purtroppo oramai obsoleta, perché nel frattempo Gian Maria Ricci ha fatto push sulla master remota. Per aggiornare la situazione del repository locale e scaricare i commit che nel frattempo sono stati aggiunti al server è necessario usare il comando fetch (git fetch)

Questo comando contatta il server remoto, scaricando le eventuali modifiche effettuate dall’ultimo aggiornamento. Visual Studio ha il vantaggio di mostrare una comoda visualizzazione grafica di quello che è cambiato dopo che viene effettuato il fetch

Dall’immagine precedente è immediatamente chiaro che Gian Maria Ricci ha fatto due commit rispetto il nostro ultimo aggiornamento ed è necessario dunque procedere ad un merge.

La stessa visualizzazione si può avere in command line:

In questo caso è leggermente più difficile comprendere cosa sia successo, ma la rappresentazione grafica premette comunque di capire che la branch master locale è partita dal commit 202396b, ed è evoluta con due commit (806c743 e d9f7cc7), mentre la origin/master, partita anche essa dal commit 202396b è ora evoluta con altri due commit (8374733 e ca9fd1e) che sono stati effettuati da Gian Maria Ricci.

Un tool utile per familiarizzare con questi concetti ed avere una chiara visualizzazione è stato scritto da Phil Haack e permette di avere una visualizzazione grafica del proprio repository, in maniera analoga alle varie immagini che si vedono sui tutorial o libri su Git. Il tool si chiama SeeGit ed è possibile trovarlo qui (http://haacked.github.io/SeeGit/)

Se invece si vuole una visualizzazione grafica veramente completa è possibile utilizzare un altro tool completamente gratuito chiamato SourceTree, il quale permette di gestire un repository Git o Mercurial fornendo una interfaccia molto intuitiva e che permette facilmente di visualizzare le differenze tra i file.

A discapito del tool utilizzato, una volta effettuato il fetch, è necessario procedere al merge tra le proprie modifiche e quelle appena scaricate con il comando

git merge origin/master

Questo comando non fa altro che effettuare una merge tra la branch locale correntemente attiva (la master in questo caso) e la origin/master. Se non vi sono conflitti, ovvero le modifiche nei vari commit non riguardano le stesse porzioni di file, il merge viene eseguito in maniera automatica e lo sviluppatore dovrà quindi procedere alla verifica del merge stesso, in maniera analoga a quello che si fa dopo un merge su un VCS centralizzato.

Le operazioni di fetch e merge sono comuni per allineare la propria branch con quella di un server di upstream, per cui in git è presente il comando pull che effettua entrambi i comandi in uno. In Visual Studio infatti abbiamo la possibilità di effettuare il fetch o direttamente il pull. Sia che venga fatto a riga di comando o da Visual Studio o con qualsiasi altro tool questa è la situazione che si ha dopo un fetch+merge (o pull)

La situazione è ancora più chiara utilizzando l’utility di Phil Haack.

Dato che ogni sviluppatore possiede un repository locale, è molto comune la situazione in cui, partendo da un singolo commit, si abbia la divergenza con più linee di codice, una sviluppata in locale e l’altra in uno dei remote con cui si sta lavorando. In questo caso quindi il commit 140f00a8 ha due commit padri, perché costituisce la merge dei due distinti rami di codice che si sono generati dal primo commit 202396b4. A tutti gli effetti quindi quando avvengono conflitti quello che si fa è fare un merge della branch locale con la corrispondente branch remota che è stata portata in locale con il comando fetch.

Una volta che la correttezza del merge è stata verificata (Unit Test e/o verifica manuale), è possibile effettuare il push. Se nel frattempo nessuno ha inviato altri commit, i tre commit (i due effettuati in locale ed il risultato della merge) verranno inviati al server, altrimenti sarà necessario procedere nuovamente ad un nuovo pull.

Risoluzione di conflitti all’interno di Visual Studio

Naturalmente è possibile che entrambi gli sviluppatori abbiano modificato lo stesso file, in questo caso durante il merge git notificherà l’utente della presenza di uno o più conflitti.

La comodità di uno strumento grafico come Visual Studio è capire con facilità tutti i file che hanno attualmente generato conflitti ed avere quindi un quadro preciso della situazione. È comunque possibile utilizzare la command line anche per le operazioni di merge, dato che gli eventuali conflitti vengono comunque risolti con un tool visuale, lanciato in automatico dalla command line stessa.

In questo caso il conflitto è su un singolo file, è possibile premere sul link Compare Files per lanciare il compare tools di Visual Studio e capire cosa è cambiato.

Di base però si preme il bottone Merge e si gestiscono i conflitti direttamente da Visual Studio

Se avete installato precedentemente msysgit o i tool di GitHub è possibile che premendo il bottone Merge vi si apra il KDiff3 o qualche altro strumento di risoluzione conflitti. Questo accade perché git memorizza nelle configurazioni gli strumenti da usare per il compare e la risoluzione di conflitti, in modo che possano essere lanciati durante il merge da command line. Dato che il plugin per git integrato in Visual Studio preserva le configurazioni, se nel config è indicato di usare kdiff3, Visual Studio onora la configurazione e non usa il suo strumento integrato. Per risolvere questo problema ed usare Visual Studio è possibile editare direttamente il file di configurazione di git locale o globale inserendo questa configurazione

[diff]

tool = vsdiffmerge

[difftool]

prompt = true

[difftool "vsdiffmerge"]

cmd = \"C:\\Program Files (x86)\\Microsoft Visual Studio 11.0\\Common7\\IDE\\vsdiffmerge.exe\" \"$LOCAL\" \"$REMOTE\" //t

keepbackup = false

trustexistcode = true

[merge]

tool = vsdiffmerge

[mergetool]

prompt = true

[mergetool "vsdiffmerge"]

cmd = \"C:\\Program Files (x86)\\Microsoft Visual Studio 11.0\\Common7\\IDE\\vsdiffmerge.exe\" \"$REMOTE\" \"$LOCAL\" \"$BASE\" \"$MERGED\" //m

keepbackup = false

trustexistcode = true

Il file di configurazione locale si chiama config ed è nella cartella .git del repository locale, mentre il file di configurazione globale per l’utente si chiama .gitconfig ed è nella cartella di profilo dell’utente c:\users\nomeutente. Entrambi sono file di testo che possono essere editati senza problemi. Localizzate le eventuali sezioni già presenti (quelle tra parentesi quadre) e sostituitele con quelle mostrate sopra

Se non è stato configurato nessuno strumento, Visual Studio di default utilizza i suoi strumenti integrati.

Indipendentemente dallo strumento utilizzato per la risoluzione dei conflitti, una volta che tutti sono stati risolti, i file risultano modificati e debbono quindi essere committati nel repository locale prima di poter effettuare il push verso il server remoto. Nella figura sottostante è infatti rappresentata la situazione in cui ho due commit da inviare al remote, il primo è il commit che ha generato conflitto, il secondo è quello che risolve il conflitto.

Guest post: Utilizzare gli SMS per l’autenticazione nelle app Windows Store

Lorenzo Barbieri [MSFT] — Fri, 24 May 2013 09:05:00 GMT

Questo post è stato scritto da Giancarlo Lelli (@itsonlyGianca), Microsoft Student Partner di Cagliari.

In questo articolo vedremo come implementare un’autenticazione SMS nelle nostre app Windows Store, ovvero come Windows 8 permette questo tipo di procedura, quali sono le classi che permettono di interfacciarsi ad un dispositivo mobile broadband e soprattutto i prerequisiti hardware e a livello di ambiente di sviluppo necessari per usufruire di tutte le potenzialità di questo particolare metodo di autenticazione.

Prefazione

Prima di addentrarci nell’argomento preciso che le procedure riportate in questo articolo non si possono applicare a coloro cha hanno intenzione di sviluppare app per operatori di telefonia mobile, ma solamente a coloro che vogliono utilizzare all’interno della loro field application (per cui mi riferisco a coloro che svilupperanno app del tipo LOB) questo tipo di layer di sicurezza. Gli esempi di codice forniti in questi articolo saranno in C#

Background

Il supporto alla tecnologia mobile broadband non è qualcosa di nuovo al dir la verità, infatti era già presente ai tempi di Windows 7, tuttavia la maniera in cui poteva essere utilizzata risultava piuttosto problematica, dovuta alla necessità di installare software e driver di terze parti per rendere operativo il nostro mobile broadband device. In Windows 8 queste problematiche sono state risolte, introducendo delle funzionalità che ad oggi permettono all’ utente di avere un esperienza utente sempre connessa, permettendo di considerare le connessioni a consumo come qualcosa (in certi casi) analogo al Wi-Fi. A questo proposito è stato fatto un lavoro di re-ingegnerizzazione dello stack di wireless networking che ha portato una serie di interessanti novità, due delle principali sono:

Introduzione del Mobile Broadband Interface Model (MBIM) ovvero sia una nuova specifica hardware che i produttori potranno adottare nei loro dispositivi garantendo così un hardware experience di gran lunga superiore a quella a cui eravamo abituati. Infatti all’ interno di Windows 8 la specifica MBIM viene fornita come qualcosa out of the box, ovvero già nativamente supportata, infatti il class driver che è destinato a supportare questo particolare tipo di device è già nativamente disponibile all’ interno del SO, quello che dobbiamo fare noi è semplicemente connettere il dispositivo al nostro pc/tablet, senza nemmeno preoccuparci di eventuali aggiornamenti perché è tutto gestito da Windows Update.

Introduzione di due nuovi namespace strettamente collegati:

· Windows.Device.Sms: che espone classi e metodi gestiti e fruibili da tutti i linguaggi supportati da WinRT per interfacciarsi ai dispositivi mobile broadband connessi al nostro pc/tablet.

· Windows.Networking.Connectivity: permette di ottenere informazioni sulla connettività, l’uso e il piano dati per la connessione a consumo attiva. I dati ottenuti tramite questi metodi possono essere usati per evitare il cosiddetto bill-shock, ovvero costi superiori al normale dovuti a sfori sul piano dati.

In questo articolo ci concentreremo soprattutto sul primo del due namespace illustrati sopra.

Windows.Device.Sms – Features

Le funzionalità messe a disposizione a noi developer da questo namespace sono innumerevoli, le principali, e quelle che consumeremo noi negli esempi di questo articolo sono elencato di seguito:

· Invio e ricezione di SMS in formato di testo

· Interfacciamento con il dispositivo mobile broadband

· Letture, scrittura e cancellazione di sms dal message store (memoria della sia card)

· Enumerazioni di tutti i dispositivi mobile broadband connessi

· Nuovo event trigger per background task

Ovviamente molti dei metodi di questo spazio dei nomi rispettano la filosofia asincrona di Windows 8 perciò supportano pienamente le due nuove keyword async/await, tuttavia alcune operazioni sono ancora collegate al vecchio concetto di callback associati ad un evento, a questo proposito mi riferisco agli eventi che riguardano la ricezione di un nuovo SMS e al cambiamento di stato del nostro mobile broadband device.

Per facilitare l’integrazione di un app mobile broadband con il sistema operativo è stato introdotto anche un nuovo event trigger che potrà essere usato nella definizione di nuovi background task per permettere ad un app la cui funzione è strettamente di messaggistica di potersi svegliare qualora venga ricevuto un sms, sganciandosi così dal vincolo dei callback che ovviamente vengono eseguiti solo quando l’app è in esecuzione.

Operazioni preliminari

Prima di buttarci nei meandri di Visual Studio ci sono alcuni step preliminari da eseguire, che permettono alla nostra app di avere i privilegi di accesso al MB device, ovvero, definire il metadata package per il nostro dispositivo MB e impostare le capabilities nella nostra solution di VS2012.

I requisiti software sono i seguenti:

· PC con Windows 8 (preferibilmente Pro) installato

· Visual Studio 2012

· Windows Driver Kit installato

I requisiti hardware invece:

· Dispositivo mobile broadband che sfrutta lo standard MBIM collegato al pc/tablet. [List]

Completati questi step strettamente preparatori, la prima cosa che dobbiamo fare (se non lo abbiamo già fatto) è collegare il nostro MB device al nostro pc/tablet. Non appena il device verrà collegato, il sistema operativo riconoscerà che si tratta di un dispositivo che sfrutta il MBIM e quindi attraverso il Device Metadata Retrieval Client (DMRC) controllerà in primis che all’interno del nostro computer non ci sia già un metadata package relativo a quella periferica (device metadata cache – device metadata store), qualora non esistesse o ha bisogno di essere aggiornato il DMRC farà una query al Windows Metadata and Internet Services website (WMIS) per determinare l’esistenza di un package per tale dispositivo, qualora esistesse il DMRC lo scarica lo scompatta e lo memorizza all’ interno della cartella che contiene la cache dei metadati. (%PROGRAMDATA%\Microsoft\Windows\DeviceMetadataStore\). Arrivati a questo punto possiamo aprire VS2012, subito noteremo che nella barra dei menù è apparsa una nuova voce ovvero “Drivers”. Navighiamo come mostra la figura uno sino ad arrivare al menù relativo ai MB device metadata.

Una volta aperto quel menù ci ritroveremo davanti il wizard per l’authoring di service metadata, noi per comodità sceglieremo di modificarne uno già esistente (quello scaricato dal DMRC) e una volta che verrà aperto muoviamoci nella scheda “Applications” e andiamo a riempire i campi raggruppati nelle sezioni Metro Style device app e privileged application. Una volta fatto andiamo nella scheda finish e salviamo il newly edited package sostituendolo a quello già esistente. Con questa procedura abbiamo aggiunto la nostra app alla whitelist di tale dispositivo. Una feature collegata ai metadata package è la possibilità di specificare degli URL di app già nello store di modo che una, volta fatto il deploy del pacchetto, quando verrà connesso un dispositivo qualsiasi che abbia dei metadati già definiti, Windows 8 scaricherà automaticamente l’app indicata dallo store.

Il prossimo step sta nel definire le capabilities nella nostra solution di VS2012, questo step è abbastanza banale ma leggermente diverso da quello a cui siamo abituati poiché il file *.appxmanifest non permette l’aggiunta di tale feature tramite interfaccia grafica. Per cui dovremmo aprire tale file in modalità di testo e inserire il seguente codice:

Adesso siamo pronti a sviluppare la nostra app.

Code snippet per app di Windows Store C#

Presupponendo l’aggiunta di questi namespace e la dichiarazione di queste tre variabili:

Inizializziamo il MB device

Il codice sopra riportato è abbastanza autoesplicativo, ovvero per prima cosa creiamo un grande blocco try-catch, poi inizializziamo la variabile mai device con l’istanza del dispositivo Mb di default, se non vengono sollevate eccezioni utilizziamo una messagebox per far visualizzare alcune info sulla periferica collegata, altrimenti visualizziamo il tipo di errore. Le info base che visualizzeremo sono: il numero di telefono della sim inserita, la classe cellulare della scheda lo stato del device e la capienza della memoria della sim.

Enumerazione di tutti i dispositivi mobile broadband

Tralasciando la parte identica allo snippet precedente notiamo come il metodo .GetDeviceSelector() permetta di utilizzare una stringa AQS per identificare all’ interno del nostro pc/tablet tutti i dispositivi mobile broadband, dopodiché con un semplice ciclo for visualizziamo tutte le info base per ogni device, identificando il singolo device attraverso il suo Id univoco utilizzato il inizializzare ad ogni ciclo la variabile di tipo SmsDevice a meno di eventuali eccezioni.

Invio SMS

Lettura messaggi dalla memoria della sim

In questo snippet vediamo come è possibile legge gli SMS dallo store della sim, vale la pena evidenziare due cose, ovvero, l’enumerazione SMSMessageFilter permette di identificare la tipologia di msg da leggere (inviati, ricevuti, eliminati, bozze, tutti) e il fatto che all’ interno del ciclo i messaggi sono convertiti dal formato binario al formato testo con il metodo della classe SmsTextMessage .FromBinaryMessage().

Cancellazione messaggi dal message store

Tralasciando il codice già spiegato nello snippet precedente, le righe 6-7 mostrano come sia possibile cancellare in massa più messaggi semplicemente specificandone il tipo grazie all’ enumerazione spiegata prima, oppure come cancellare un singolo messaggio specificandone l’id al’ interno della lista instanziata in riga 3. La sottile differenza dei due metodi sta nel fatto che uno è singolare e l’altro è plurale!

Sottoscrizione e cancellazione ad eventi (messaggio ricevuto, stato device cambiato)

L’Intellisense provvederà creare i metodi di callback, nel primo caso un parametro del metodo sarà una variabile che permetterà di ottenere info sull’ SMS appena ricevuto, mentre nel secondo caso si potrà capire in che modo il dispositivo ha cambiato stato tramite la proprietà .DeviceStatus

Autenticazione via SMS concetti e algoritmi

Ora che abbiamo visto come poter sfruttare un MB device in Windows 8 per poter fare inviare sms alla nostra app, vediamo che tipo di approccio dobbiamo avere per essere sicuri dell’ efficacia di questo metodo. In questo articolo vedremo l’implementazione .NET degli algoritmi più usati in questi casi ovvero quelli definiti nei documenti RFC4226 e l’ RFC6238. Il primo fornisce una autenticazione basata su contatore mentre il secondo una basata su un determinato time span calcolato sul tempo UNIX. In questo articolo vedremo nel dettaglio il primo algoritmo (dato che per il secondo l’unica differenza sta nel primo valore fornito in input, che varia da un intero, ad un valore intero random dipendente dalla seguente formula calcolato su un intervallo di 30 secondi)

Y = (Now-UNIX_time) /30

Algoritmo RFC4226

L’algoritmo è definite come segue:

1. Prendi in input il numero di volte che è stato eseguito l’algoritmo + 1 insieme alla secret key

2. Incapsula tutto in un array di byte e calcola il SHA1 HMAC

3. Esegui delle operazioni bitwise e calcola il modulo del risulta dividendolo per 10^x dove X è il numero di cifre che vogliamo abbia il nostro codice di verifica.

4. Nel caso in cui il risultato dello step 3 abbia meno cifre di X fai un padding con zero

Code snippet dell’ algoritmo e chiamata del metodo

Il codice appena riportato è inserito dentro una Task<T> poiché proviene da un cloud service hostato su Windows Azure.

Questo snippet mostra la chiamata a tale funzione e l’invio del codice via sms. La classe SmsAuthServiceClient esiste perché deriva da una service reference che punta al cloud service dove è definito l’algoritmo della pagina precedente

Per quanto riguarda l’algoritmo RFC6238 il metodo avrà un parametro ovvero la chiave segreta e il resto sarà tutto definito a run time. Sotto è riportato l’algoritmo.

Grazie per avere letto questo articolo e per ora è tutto, se hai suggerimenti dubbi o domande contattami pure all’ indirizzo email: gcarlo.lelli@outlook.com

Aspettando Windows 8.1…

Lorenzo Barbieri [MSFT] — Thu, 16 May 2013 17:56:09 GMT

…potete sempre sviluppare una o più app per Windows 8, in modo da essere pronti al nuovo sistema operativo, che sarà disponibile gratuitamente per tutti gli utenti che hanno Windows 8!

In attesa di Build 2013 (a San Francisco a fine giugno) dove verranno presentate tutte le novità e rese disponibili le preview su cui testare tutte le innovazioni, se non avete mai sviluppato un’app per il Windows Store vi ricordo che potete usare C#/VB e XAML, HTML5 e JavaScript oppure C++ con XAML o direttamente DirectX.

Sul Windows Store è possibile “prenotare” i nomi delle applicazioni, che devono essere univoci, per cui se avete già applicazioni su altre piattaforme o se avete un’idea geniale non aspettate. Registratevi e bloccate i nomi delle app che volete realizzare, prima che li prenda qualcun altro.

Le app possono essere gratuite, a pagamento (con la trial opzionale) e supportare l’acquisto all’interno dell’app stessa di funzionalità aggiuntive. Possono inoltre supportare la pubblicità con il PubCenter di Microsoft o con qualsiasi altro fornitore.

Sono sempre di più gli SDK e gli strumenti che supportano Windows 8, molti anche multipiattaforma (Unity per fare un esempio, ma ce ne sono tantissimi altri).

Se volete provare come gira la vostra app su Windows 8 (x86/x64 o ARM) vi invito a venire ad una delle prossime tappe del tour che si concluderà a giugno (Catania, Cagliari, Cesena, Milano e Roma sono le tappe dei prossimi giorni).

Se vi serve documentazione potete guardare il nuovo DevCenter, appena rifatto:

Se avete bisogno di ulteriori informazioni potete scriverci o lasciare un commento a questo post.

Non aspettate!

-Lorenzo

modern.IE (parte 2)

PietroBr — Tue, 14 May 2013 16:16:00 GMT

Vi avevo già raccontato in un precedente post di modern.ie, il sito che vi dà la possibilità di testare errori comuni (e non) di vostri siti web. Inoltre è possibile testare il proprio sito su diversi browser e device utilizzando BrowserStack.

Da circa un mese potete scaricare anche macchine virtuali per il test su Windows, Linux e Mac, scegliendo tra diverse piattaforme di virtualizzazione, ad esempio selezionando Windows e VirtualBox avrete così diverse versioni di IE su diverse piattaforme!

Un’altra cosa interessante è che potete ora anche fare il test di siti protetti da Firewall scaricando una versione locale del sito moder.ie.

Per maggiori informazioni leggete qui e buon download!

Pisa, Perugia, Cosenza, Catania, Milano, Cagliari, Roma, Cesena… Dev Camp, DotNetCampus, Community Days, di tutto di più…

Lorenzo Barbieri [MSFT] — Wed, 08 May 2013 09:49:47 GMT

Nei prossimi giorni io e Pietro saremo in giro per l'Italia, io per vincere la maglia “blue”, lui invece ha già vinto la maglia “azure”

Ecco le date con un po’ di informazioni:

9 maggio – Pisa – Dev Camp in collaborazione con DotNetToscana
10 maggio – Perugia – Dev Camp in collaborazione con DotNetUmbria 2.0 (ci sarò io e il mitico Vito , Pietro si eclisserà per tutta la giornata )
15 maggio – Cosenza – DotNetCampus la più grande conferenza italiana su .NET fa tappa in Calabria, ci saremo anche io e Sara al laboratorio su Windows 8
16 maggio – Torino – Dev Camp su Windows 8 organizzato dal MIC
20 e 21 maggio – Catania – Community Days – l’evento più importante organizzato dalle principali community Microsoft italiane, con speaker da tutta Italia, fa tappa in Sicilia per un evento memorabile!
6 giugno – Torino – Dev Camp su Windows Phone organizzato dal MIC
7 giugno – Cagliari – Dev Camp - io e Pietro saremo in Sardegna, iscrivetevi in tanti, altrimenti ci tocca andare al mare!
14 giugno – Cesena – DotNetCampus, nella suggestiva location del Technogym Village, l’ultima tappa del DotNetCampus, non mancate!

Mi raccomando, per tutti questi eventi i posti sono limitati, per cui iscrivetevi subito, non aspettate l’ultimo minuto!

In molte tappe ci saranno per i più fortunati e/o bravi anche alcune sorprese!

p.s. mancano i link alle tappe di Milano e Roma, aggiornerò il post quando saranno disponibili.

-Lorenzo

Windows Azure Conf con DotNetLombardia – 6 Maggio

PietroBr — Thu, 02 May 2013 15:07:55 GMT

Lunedì prossimo 6 Maggio si terrà un evento dedicato a Windows Azure, organizzato dalla community DotNetLombardia in collaborazione con Microsoft. L’obiettivo dell’evento è raccontare le funzionalità di Azure tramite esperienze reali di sviluppatori che utilizzano nella loro vita lavorativa diverse funzionalità di Windows Azure e condividere esperienze con le persone della community che spesso sono i primi utilizzatori di Windows Azure, sempre disponibili a dare consigli e condividere esperienze.

Alla conferenza avrò la possibilità di raccontarvi in breve qualche ultima novità sulle funzionalità di Azure, introducendo la giornata organizzata dalla Community.

L’evento di una giornata intera, totalmente gratuito, si terrà nella sede Microsoft di Peschiera Borromeo e potete registrarvi sul sito a questo link, dove trovate tutte le informazioni sulla logistica.

Vi aspetto & Happy Coding!

Backup di Windows Server 2012 su Windows Azure

Eva Gjeci — Mon, 22 Apr 2013 10:22:14 GMT

Con l’ultimo aggiornamento di Windows Azure è stato introdotto un nuovo servizio in anteprima, Recovery Services, che mette a disposizione un nuovo modo semplice e intuitivo per effettuare il backup e il rispristino di Windows Server 2008 R2 SP1, Windows Server 2012, Windows Server 2012 Essentials e System Center Data Protection Manager 2012 SP1.

È quindi ora possibile gestire il backup sul cloud attraverso gli strumenti familiari di Windows Server, sfruttando le nuove funzionalità di configurazione, monitoraggio e recupero dei backup su Windows Azure Storage.

Questa guida nello specifico spiega passo a passo come effettuare il backup di Windows Server 2012 su Windows Azure.

Nota: per poter effettuare il backup di Windows Server 2012 su Windows Azure è necessario avere un certificato X.509 v3 per registrare il server. Il certificato deve avere una chiave lunga almeno 2048 bit che dovrebbe risiedere nel deposito dei certificati personali del computer locale.

E’ possibile utilizzare:

un certificato self-signed
qualsiasi certificato SSL valido rilasciato da un autorità di certificazione (CA) considerata attendibile da Microsoft.

Per ulteriori informazioni consultare http://support.microsoft.com/kb/931125.
In questa guida utilizzeremo un certificato self-signed generato con il tool di creazione dei certificati, makecert.exe.

1. Creazione del certificato self-signed

Per creare il proprio certificato seguire i seguenti passaggi:

a. Makecert.exe è disponibile come parte di Windows SDK che potete scaricare al seguente link: http://go.microsoft.com/fwlink/?linkid=84091

b. Installare Windows SDK per Windows 8. Il tool makecert.exe lo troverete in <system drive>:\Program Files (x86)\Windows Kits\8.0\bin\x64

c. Lanciare il prompt dei comandi (cmd.exe) con privilegi da amministratore ed eseguire il seguente comando sostituendo CertificateName con il nome che volete dare al vostro certificato:

makecert.exe -r -pe -n CN=CertificateName -ss my -sr localmachine -eku 1.3.6.1.5.5.7.3.2 -len 2048 -e 01/01/2016 CertificateName.cer

d. Installare il certificato

2. Abilitazione delle funzionalità in “Preview”

Per attivare il Recovery Services dal portale di gestione di Windows Azure è necessario:

a. Accedere al portale di gestione di Windows Azure inserendo username/indirizzo email e password del proprio account;

b. Sulla barra dei comandi in fondo alla pagina del portale di gestione, scegliere New, quindi dalla voce Data Services scegliere Recovery Services e poi posizionarsi su Backup Vault e cliccare sul link preview program (come indicato nella figura sottostante):

c. Dalla lista dei servizi in preview attivare il servizio di Backup effettuando il sign up. Una volta ricevuta l’email di conferma di attivazione del servizio potrete tornare nel portale di gestione di Windows Azure e iniziare ad utilizzarlo.

3. Creazione di un deposito per il backup

Per creare il deposito per il backup del vostro server seguire i seguenti passaggi:

a. Sulla barra dei comandi in fondo alla pagina del portale di gestione, scegliere New, quindi dalla voce Data Services scegliere Recovery Services poi Backup Vault poi Quick Create:

- in Name, inserire il nome del deposito per il backup;

- in Region, selezionare la regione per l’archiviazione;

- infine cliccare su Create Vault.

Dopo che l’account di archiviazione è stato creato lo status passerà ad active e l’account sarà pronto ad essere utilizzato:

b. Prima di poter registrare il server di cui vogliamo gestire il backup si deve caricare il certificato. Sulla barra dei comandi a centro pagina cliccare Manage Certificate e caricare il certificato (.cer) creato nel primo punto di questa guida.

4. Download e installazione di Windows Azure Online Backup Agent

Per poter eseguire il backup del server su Windows Azure è necessario prima scaricare e installare l’agente di backup sul vostro Windows Server 2012.

a. Dalla Dashbord cliccare su Download Agent e scaricare l’agente relativo a Windows server 2012 e System Center 2012 SP1;

b. Installare l’agente nel server eseguendo WABIstaller.exe:

1. Verrà visualizzato l'avviso Informativa supplementare per il servizio. Fare clic su Accetto le condizioni del contratto di assistenza e quindi su OK per continuare l'installazione;

2. Nella pagina Prerequisites Check verrà selezionato per l'installazione tutto il software mancante. Scegliere Next per confermare l'installazione del software prerequisito e continuare l'installazione;

3. Nella pagina Installation Settings, specificare un valore nei campi Installation Folder e Cache Location per Windows Azure Online Backup. La cartella di installazione predefinita è <system drive>:\Program Files\Windows Azure Online Backup Agent. Per scegliere un nuovo percorso in cui creare la cartella Windows Azure Online Backup, fare clic su Browse. Durante il processo di installazione verrà creata una cartella denominata Scratch all'interno della cartella Agente di Windows Azure Online Backup Agent nel percorso della cache. Nel percorso della cache deve essere disponibile uno spazio minimo di 2,5 GB. Dopo avere identificato le cartelle che dovranno essere utilizzate dall'Windows Azure Online Backup Agent, fare clic su Next;

4. Verrà visualizzata la pagina Installation. Quando l'installazione ha inizio viene visualizzato un indicatore di stato, che indica lo stato dell'installazione. Al termine dell'installazione, verrà visualizzato un messaggio per informare che l'installazione dell'Windows Azure Online Backup Agent è stata completata. A questo punto è possibile scegliere se verificare la disponibilità di aggiornamenti. È consigliabile consentire il controllo degli aggiornamenti.

Fare clic su Finish. Se si è scelto di verificare la disponibilità di aggiornamenti, verrà avviato automaticamente Internet Explorer e verrà eseguito il controllo. Dopo l'installazione di eventuali aggiornamenti, è possibile iniziare a configurare l'Windows Azure Online Backup Agent.

5. Registrazione del server con Windows Azure Online Backup Agent

a. Eseguire l’agente Windows Azure Backup appena installato e scegliere Register server dal menu Action per avviare la Registrazione guidata server;

b. Verrà visualizzata la pagina Proxy Configuration. Se si desidera che l'Windows Azure Online Backup Agent utilizzi un server proxy univoco per la connessione Internet, fare clic su Use a proxy server for Windows Azure Online Backup e quindi digitare l'URL del server proxy. Utilizzare il nome di dominio completo o l'indirizzo IP del server proxy, ad esempio http://proxy.corp.contoso.com oppure http://10.186.173.132, e il numero di porta del server configurato per le connessioni Internet.

Se il server proxy richiede l'autenticazione prima di consentire connessioni, fare clic su The proxy server requests authentication quindi digitare il nome utente e la password che l'Windows Azure Online Backup Agent dovrà inviare quando vengono richieste le credenziali. Scegliere Next per continuare;

c. Verrà visualizzata la pagina Vault Identification. Caricate il certificato creato e specificate il Backup Vault di Windows Azure su cuoi volete che venga memorizzato il backup;

d. Verrà visualizzata la pagina Encryption Setting. In Enter Passphrase digitare una passphrase composta da almeno 16 caratteri per crittografare i backup dal server. Per creare una passphrase casuale, fare clic su Generate passphrase. In questa fase è necessario specificare una passphrase per proteggere la riservatezza del backup. È consigliato salvare una copia in locale di questa passphrase poiché non è possibile chiamare Microsoft in seguito per ottenere l’accesso ai vostri dati se dimenticate o perdete questa frase;

Dopo avere immesso la passphrase, fare clic su Register per iniziare il processo di registrazione del server. In caso di esito positivo, verrà visualizzato un messaggio di conferma della registrazione e sarà quindi possibile chiudere la procedura guidata.

e. Programmare il backup cliccando su Scehdule Backup;

f. Cliccate su Add Items per aggiungere i file e le cartelle per il backup;

g. Cliccare Next e successivamente specificate quando dovrà essere effettuato il backup specificando per quanti giorni dovrà essere effettuato;

h. Cliccare Finish e successivamente Close per completare la procedura;

Per ulteriori approfondimenti:

http://technet.microsoft.com/en-us/library/hh831419.aspx

http://msdn.microsoft.com/en-us/library/windowsazure/dn169036.aspx

http://msdn.microsoft.com/en-us/171fe77a-8686-4dd1-a45a-b44df729b40b

Backup di SQL Server 2012 su Windows Azure

Eva Gjeci — Fri, 19 Apr 2013 14:34:00 GMT

A partire dall’aggiornamento cumulativo 2 di SQL Server 2012 SP1, è possibile fare il backup e il restore sul Blob Storage di Windows Azure, sfruttando le funzionalità native di SQL Server sia che esso sia on-premise all’interno dell’azienda o che sia ospitato all’interno di una Virtual Machine. Il database SQL, consente di creare, scalare ed estendere rapidamente le applicazioni localmente e nel cloud con strumenti familiari permettendo così di archiviare economicamente dati quali video, audio e immagini. L’esecuzione del backup nel cloud garantisce vantaggi quali disponibilità, archiviazione illimitata in una posizione esterna replicata a livello geografico e facilità di migrazione dei dati nel cloud. Questa funzionalità, introdotta in SQL Server 2012 SP1 CU2, consente di eseguire il Backup o Restore tramite T-SQL o SMO.

Ecco quindi una guida passo a passo che spiega come effettuare il backup dei database SQL Server 2012 su Windows Azure in soli 4 step.

1. Creazione dell’account di archiviazione su Windows Azure

Per creare un account di archiviazione dal portale di gestione di Windows Azure, attenersi ai passaggi seguenti:

a. Accedere al portale di gestione di Windows Azure con il proprio account:

b. Sulla barra dei comandi in fondo alla pagina del portale di gestione, scegliere New, quindi dalla voce Data Services scegliere Storage e poi Quick Create:

- in URL, inserire il nome di un sottodominio da usare nell’URL dell’account di archiviazione;

- in Region/Affinity Group, selezionare la regione/gruppo di affinità per l’archiviazione;

- se non si desidera una geo-replica per il vostro account di archiviazione, spuntare la casella Enable Geo-Replication;

- cliccare su Create Storage Account. Dopo che l’account di archiviazione è stato creato lo status sarà online ed è pronto ad essere utilizzato;

- sulla barra dei comandi a centro pagina cliccare Manage Keys per visualizzare le informazioni sull’account. Copiare il nome dell’account di archiviazione e la chiave primaria di accesso. Queste informazioni sono necessarie per creare le credenziali di SQL Server utilizzate per accedere all’account di archiviazione e per creare il backup.

2. Creazione di un contenitore BLOB

I BLOB costituiscono il modo più semplice di archiviare grandi quantità di dati binari o testo non strutturato quali video, audio e immagini. Un contenitore fornisce un raggruppamento di un set di BLOB. Un account di archiviazione può contenere un numero illimitato di contenitori e in un contenitore è possibile archiviare un numero illimitato di BLOB.

Per creare un contenitore :

- selezionare l’account di archiviazione appena creato, fare click sulla scheda Containers, quindi su Add Container nella parte inferiore della schermata in cui verrà visualizzata una nuova finestra di dialogo;

- immettere il nome associato al contenitore;

- selezionare Privato come tipologia di accesso. É consigliabile creare contenitori privati per proteggere i file di backup;

3. Creare le credenziali di SQL Server

Nelle credenziali di SQL Server sono archiviate le informazioni di autenticazione utilizzate da SQL Server per la scrittura o lettura di un BLOB nel servizio di archiviazione BLOB di Windows Azure.

Per creare le credenziali di SQL Server seguire i seguenti passaggi:

- connettersi a SQL Server Management Studio

- in Object Explorer connettersi all’istanza del motore di database con il database a cui fare il backup;

- sulla barra degli strumenti Standard cliccare New Query;

- copiare e incollare l’esempio seguente nella finestra Query modificando il nome dell’account di archiviazione e la chiave primaria di accesso;

CREATE CREDENTIAL mycredential

WITH IDENTITY = '%mystorageaccount%',

SECRET = '%storage account access key%';

dove:

‘%mystorageaccount%’ è il nome dell’account di archiviazione

‘%storage account access key%’ è la chiave primaria o secondaria del vostro account di archiviazione

- verificare l’istruzione T-SQL e fare click su Execute.

4. Backup completo del database nel servizio di archiviazione BLOB di Windows Azure

Per creare un backup completo del database attenersi ai passaggi seguenti:

- da SQL Server Management Studio fare click su New Query sulla barra del menu;

- copiare e incollare l’esempio seguente nella finestra Query, modificando le informazioni necessarie, quindi fare click su Execute

BACKUP DATABASE [dbName]

TO URL = 'http://mystorageaccount.blob.core.windows.net/blobcontainername/dbName.bak'

WITH CREDENTIAL = 'mycredential';

GO

dove:

l’URL include l’endpoint del servizio BLOB, seguito dal nome del contenitore e il nome del file di backup

e ‘mycredential’ sono le credenziali create nel passo precedente

- in Object explorer, connettersi a Azure Storage. L’Account key richiesto è la chiave primaria o secondaria del vostro account di archiviazione.

Sfogliare per individuare il contenitore e il file di backup appena creato.

Infine per eseguire il restore da un backup del database attenersi ai seguenti passaggi:

- da SQL Server Management Studio fare click su New Query sulla barra del menu;

- copiare e incollare l’esempio seguente nella finestra Query, modificando le informazioni necessarie, quindi fare click su Execute;

RESTORE DATABASE dbName

FROM URL = 'http://mystorageaccount.blob.core.windows.net/blobcontainername/dbName.bak'

WITH CREDENTIAL = 'mycredential';

GO

Per Approfondimenti:

· http://msdn.microsoft.com/en-us/library/jj919148.aspx