Миграция БД на Windows Azure SQL VM. BLOB Storage + Azure SDK

В предыдущем примере мы тренировались загружать файлы в Azure Storage при помощи REST API и залили туда бэкап базы данных AdventureWorks2012.
Остается скачать его в облачную виртуальную машину и восстановить на установленном в ней SQL Server. В этом плане работа с Azure Storage совершенно симметрична что со стороны on-premise клиента, что со стороны облачной виртуалки — они передают друг другу файлы через Azure Storage. Один туда закачивает, второй считывает.

Поскольку контейнер container1 был создан как публичный, не требуется формировать цифровую подпись, чтобы перечислить и прочитать содержащиеся в нем блобы:
tststorage.blob.core.windows.net/container1/aaa.txt

Если контейнер был создан как private, для чтения из него блобов нужно авторизоваться. Как мы помним, для этого недостаточно передать primary или secondary access key учетной записи Azure Storage. Требуется аккуратно сформировать строку определенного формата и замешать MD5-хэш, как было сделано в Скрипте 2 предыдущего поста. Работа с Azure Storage через REST API удобна тем, что не предполагает установки дополнительных средств, обходясь по сути HTTP Request/Response, но требует кропотливости. В этом посте мы задействуем Azure SDK, который удобен тем, что маскирует внутри себя подготовительную работу и имеет более человечески понятные интерфейсы для чтения/записи блобов, управления контейнерами и т.д. Он бесплатен и ставится с Windows Azure .NET Developer Center. Для установки Windows Azure SDK потребуется Visual Studio 2010 SP1 или 2012. В процессе установки запускается Web Platform Installer 4.0, который производит дальнейшую установку. В составе SDK устанавливаются Windows Azure Authoring Tools — June 2012 Release, Windows Azure Emulator, Windows Azure Libraries for .NET 1.7, Windows Azure Tools for Microsoft Visual Studio и для LightSwitch. Эмулятор Облака — удобная вещь, позволяющая локально создавать облачные приложения, чтобы не платить лишние деньги за время вычислений и место в сторидже Azure в процессе отладки. Состоит из эмулятора среды для запуска облачных сервисов и эмулятора облачного хранения для таблиц, очередей и блобов. В ссылках на документацию по REST API, которые приводились в предыдущем посте, вы наверняка обратили внимание на то, что наряду с указанием Request URI для методов GET, PUT, … присутствует Emulated Storage Service URI, а также фразы типа Note that the storage emulator only supports blob sizes up to 2 GB.
После установки SDK становится возможно при помощи Server Explorer в Visual Studio просматривать относящуюся к Облаку информацию. Узел Windows Azure Storage первоначально показывает объекты эмулятора хранения. Чтобы соединиться с Azure Storage, надо указать Storage Account

Здесь Account Key — один из пары первичный / запасной, что мы видели на Рис.10 предыдущего поста. Теперь список контейнеров и их содержимое можно просматривать непосредственно из среды Visual Studio аналогично Azure Management Portal.
Блоб можно открыть, выбрав пункт Open из его контекстного меню или нажав на кнопку открыть в верхней строке или просто дважды кликнув по блобу. При этом он даунлоадится в локальную временную директорию. Блоб можно отредактировать и сохранить в локальный файл. Чтобы сохранить его (или любой другой локальный файл) в Azure Storage в VS 2010 существовала кнопка Upload Blob. В 2012 я ее в упор не вижу, причем не я один.
Используем объектную модель Azure SDK для чтения файла из Azure Storage. С ее помощью код получается короче и читабельнее по сравнению с REST API.
using System;
using Microsoft.WindowsAzure;
using Microsoft.WindowsAzure.StorageClient;
using System.IO;

class Program
{
static void Main(string[] args)
{
string storageAccount = «tststorage»;
string accountPrimaryKey = «xws7rilyLjqdw8t75EHZbsIjbtwYDvpZw790lda0L1PgzEqKHxGNIDdCdQlPEvW5LdGWK/qOZFTs5xE4P93A5A==»;
string blobContainer = «container1»;
string blobName = «AdventureWorks2012.bak»; //«aaa.txt»;

CloudStorageAccount acct = new CloudStorageAccount(new StorageCredentialsAccountAndKey(storageAccount, accountPrimaryKey), true);
CloudBlobClient clnt = acct.CreateCloudBlobClient();
CloudBlobContainer cntr = clnt.GetContainerReference(blobContainer);
CloudBlob blob = cntr.GetBlobReference(blobName);

blob.DownloadToFile(@«c:\temp\AdventureWorks2012.bak»);
}
}
Скрипт 1

Предварительно требуется в References проекта добавить в Extensions ссылку на Microsoft.WindowsAzure.StorageClient.
Говорим Build, забираем из папки решения Bin\Debug получившийся exeшник и библиотеку Microsoft.WindowsAzure.StorageClient.dll, копируем их через сессию удаленного доступа на облачную виртуалку, на которой нет ни Visual Studio, ни Windows Azure SDK, запускаем exe, и файл AdventureWorks2012.bak скачивается из Azure Storage внутрь виртуалки. По времени это занимает порядка минуты. После чего открываем SSMS и восстанавливаем резервную копию на SQL Server на виртуальной машине в Облаке.
Следует отметить, что описанный способ переноса резервной копии с локальной машины на облачную виртуалку через Azure Storage не стоил нам ничего в плане трафика, т.к. восходящий трафик в Облако, по определению, бесплатный, а Storage Account для промежуточного хранения бэкапа был создан в том же датацентре, что и виртуалка, т.е. скачивание резервной копии из tststorage в виртуалку тоже ничего не стоило. Однако c точки зрения занимаемого места AdventureWorks2012.bak хранился дважды: сначала он был закачан в блобовский сторидж, затем — скачан в vhd, который по факту есть тоже блобовский сторидж. Для резервных копий значительного размера это может повлечь дополнительные затраты за место — см. pricing, раздел Storage. В следующем посте мы посмотрим, как можно оптимизировать эти затраты.