Blog about Microsoft Azure Platform

Azure Container Service

2017-01-13T08:59:00.001-08:00

Всем привет! Второй доклад был посвящен не менее интересной теме - Azure Container Service. В рамках доклада мы познакомились с принципами контейнеризации приложений, используя Docker, а также развернули кластер ACS на базе оркестратора DC/OS от Mesosphere. Чуть ниже представлены материалы доклада

Презентация:

Видеозапись:

Introduction to Microsoft Azure Automation

2017-01-11T07:17:00.000-08:00

Всем привет!
Совсем недавно в рамках проектного тренинга мне довелось провести пару докладов на достаточно интересные темы , одной из которых и будет посвящен сегодняшний пост. Это введение в автоматизацию Azure. В рамках доклада мы обсудили предназначение автоматизации, развертывание Automation аккаунта в облаке и создание нескольких сценариев автоматизирующих процессы деплоймента приложений в Azure App Services. Презентация и видеозапись доступны ниже.

Microsoft Azure. Диагностика и мониторинг

2016-02-29T14:19:00.003-08:00

Всем привет! Наконец-то дошли руки выложить материалы третьего доклада, посвященного на этот раз диагностике и мониторингу приложений в Azure. В течение лекции мы познакомились с тем как получать доступ к логами приложения, управлять удаленным дебагингом, стримить логи, а также увидели как использовать продукты ElasticSearch для аггрегации логов. Чуть ниже вы увидите ссылк у на презентацию и видеозапись доклада.

Azure Powershell. Azure Automation

2016-01-18T06:11:00.000-08:00

Здравствуйте, друзья! Наконец-то состоялась вторая лекция в EPAM, посвященная Microsoft Azure. На этот раз мы больше сконцентрировались на развертывании инфраструктуры нашего приложения, используя связку PowerShell + Azure Resource Manager. Кроме того, познакомились с основами Azure Automation. Все , кого заинтересовала данная тематика смогут найти подкатом видеозапись презентации, а также ссылку на слайды.

Презентация:

Видеозапись доклада:

Azure App Service Architecture. Web Apps.

2015-12-22T02:50:00.001-08:00

Всем привет! 16 декабря в компании EPAM Systems состоялась первая лекция из 3-х, посвященная новинкам платформы Windows Azure. В рамках первого доклада мы знакомились с Azure App Services и Azure Web Apps. Кроме того были рассмотрены такие вопросы как:

Развертывание вебсайтов напрямую из Visual Studio а также используя VSO
Использование стейджинг слотов
App Service Environments

и многое другое. Видеозапись презентации, а также сама презентация представлены ниже

Automating Azure VMs with PowerShell

2015-05-17T14:06:00.001-07:00

Всем привет!
25 апреля состоялся Global Azure Bootcamp. В Харькове, при содействии компании EPAM Systems, это событие происходило впервые. Я, как докладчик, принимал в нем участие. Темой моего доклада была автоматизация создания виртуальных машин при помощи Powershell. И вот сегодня наконец-то дошли руки выложить в публичный доступ материалы доклада. Чуть ниже добавлена ссылка на презентацию а также видеозапись доклада.
Презентация:

Видеозапись доклада:

Ссылка на исходники скриптов: PowerShell Scripts

Новинки Service Bus 2.0. Shared Access Signatures.

2013-06-13T05:35:00.000-07:00

Совсем недавно в мире Windows Azure произошло знаменательное событие – вышел в свет новый Windows Azure SDK 2.0, который привнес большое количество изменений в процесс разработки под платформу.
Кратко напомню о том, что же нового мы увидели в версии 2.0:

Веб сайты. Были значительно расширены инструменты разработки для Visual Studio, изменения в основном коснулись процессов разворачивания, управления и мониторинга облачных приложений.
Облачные сервисы. Добавлена поддержка высокопроизводительных машин A6 и A7. Ускорен процесс публикации сервисов.
Хранилище. Добавлена возможность работы с Azure Tables прямо из Visual Studio Server Explorer.
Service Bus. Добавлен целый ряд функциональных возможностей среди которых message pump, shared access signatures, поддержка получения сообщений из очереди без их блокировки и т.д.
Командлеты Powershell. Расширен набор команд для работы с облачными сервисами и сайтами.

Для более детального ознакомления со списком обновлений рекомендую проследовать на блогпост Скота Гатри, посвященный новой версии SDK 2.0: http://weblogs.asp.net/scottgu/archive/2013/04/30/announcing-the-release-of-windows-azure-sdk-2-0-for-net.aspx
Сегодняшняя публикация будет посвящена Shared Access Signatures для Service Bus 2.0. Как я уже отметил возможность использовать SAS для Service Bus появилась лишь с выходом версии 2.0. До этого SAS были доступны только для хранилища. Основное назначение в принципе не изменилось. Shared Access Signatures позволяют предоставлять доступ к Service Bus при помощи предварительного сконфигурированного криптографического ключа. Под доступом подразумевается возможность беспрепятственно работать с такими компонентами Service Bus как очереди, темы и нотификационные хабы (в будущем будет добавлена поддержка relay). Сам по себе криптографический ключ входит в состав правила. Каждое правило определяет уровни доступа, предоставляемые владельцу ключа. При создании правила обязательными параметрами являются первичный ключ, название правила и уровни доступа. Существует ограничение на количество применяемых правил для одной сущности – сейчас это 12. Для того, чтобы получить доступ к защищенному компоненту Service Bus при помощи SAS, клиент обязан предоставить security-токен. Такой токен состоит из URL ресурса, к которому клиент пытается получить доступ, цифровой подписи, вычисляемой при помощи HMAC-SHA256, названия самого правила и времени жизни токена. Токен сохраняется в заголовке Authorization при создании HTTP запроса к Service Bus. В общем виде его структура следующая:

SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>

При получении токена инфраструктура Service Bus запускает процесс его валидации и определения разрешена ли указанным правилом запрашиваемая компонентом операция. В случае положительного результата проверки требуемая операция успешно выполняется.
Давайте теперь на примере посмотрим как использовать Shares Access Signatures для аутентификации и получения доступа к Service Bus. Специально для публикации я подготовил простейший солюшен, состоящий из 2-х проектов. Первый проект называется SASRulesManager – это обычное веб-приложение позволяющее создавать правила. Второй проект называется QueueClient – это консольное приложение, при помощи которого мы будем проверять работоспособность созданных правил. Чуть ниже на скриншоте можно увидеть, как выглядит проект в Visual Studio

Как я уже говорил, правило можно применять практически к каждой сущности Service Bus, но в нашем случае мы будем использовать очередь под названием sasdemo. Предварительно ее можно создать, используя расширенный в последней версии VS Server Explorer. Давайте вкратце рассмотрим содержимое основных классов проекта. Итак, начнем прежде всего с ServiceBusManager.cs – здесь собрана вся логика по взаимодействий с Service Bus в общем и с очередью в частности.

namespace SASRulesManager.Models
{
    public class ServiceBusManager
    {
        private const string DEMO_QUEUE_NAME = "sasdemo";
        private NamespaceManager currentNamespaceManager;
        private QueueDescription demoQueue;

        public ServiceBusManager()
        {
            Uri serviceBusUri = ServiceBusEnvironment.CreateServiceUri("https", WebConfigurationManager.AppSettings["ServiceBusNamespace"], String.Empty);
            TokenProvider tokenProvider = TokenProvider.CreateSharedAccessSignatureTokenProvider(
                WebConfigurationManager.AppSettings["ManagementKeyName"], 
                WebConfigurationManager.AppSettings["ManagementKey"]);
            currentNamespaceManager = new NamespaceManager(serviceBusUri, tokenProvider);
            demoQueue = currentNamespaceManager.GetQueue(DEMO_QUEUE_NAME);
        }

        public IEnumerable<SB.AuthorizationRule> GetQueueRules()
        {
            return demoQueue.Authorization.ToList();
        }

        public IEnumerable<SB.AuthorizationRule> AddRule(string keyName, IEnumerable<AccessRights> accessRights)
        {
            var currentRules = GetQueueRules();
            if (currentRules.Count(rule => rule.KeyName.Equals(keyName)) > 0)
            {
                return currentRules;
            }
            var authorizationRule = new SharedAccessAuthorizationRule(keyName, SharedAccessAuthorizationRule.GenerateRandomKey(), accessRights);
            demoQueue.Authorization.Add(authorizationRule);
            currentNamespaceManager.UpdateQueue(demoQueue);
            return GetQueueRules();
        }
    }
}

Код относительно прост. Как видим у нас есть 2 основных метода и конструктор класса, в котором происходит инициализация очереди. Первый метод GetQueueList возвращает нам список уже существующих правил для выбранной очереди. Второй метод позволяет добавить новое правило к очереди (всего таких правил может быть до 12 штук для одной сущности). Следует отметить, что для получения данных очереди и добавления правил все запросы должны быть аутентифицированы. Достигается это при помощи все тех же Shared Access Signatures, как видим название правила и криптографический ключ берутся из Web.config при создании экземпляра класса TokenProvider. По умолчанию при создании очереди создается правило с полным набором прав, посмотреть которое можно в диалоге ConnectionInformation на портале разработчика.

Следующий важный элемент – это MVC контроллер SASController. Исходный код контроллера представлен ниже:

 namespace SASRulesManager.Controllers
{
    public class SASController : Controller
    {
        //
        // GET: /SAS/

        public ActionResult Index()
        {
            var serviceBusManager = new ServiceBusManager();
            return View(serviceBusManager.GetQueueRules());
        }

        [HttpPost]
        public ActionResult Index(string ruleKeyName, string ruleAccessRights)
        {
            var serviceBusManager = new ServiceBusManager();
            var accessRights = ruleAccessRights.Split(new string[] { "|" }, StringSplitOptions.RemoveEmptyEntries).
                ToList().
                Select(entry =< (AccessRights)Enum.Parse(typeof(AccessRights), entry));
            serviceBusManager.AddRule(ruleKeyName, accessRights);
            return View("Index", serviceBusManager.GetQueueRules());
        }
    }
}

Здесь мы видим 2 экшена, первый для отображения странички с созданными правилам и контрола для создания новых. Вот как она выглядит:

На скриншоте можно заметить 3 правила, каждое из которых содержит различный набор прав. Всего существует 3 вида прав:

Listen. На чтение очереди
Send. На отправку сообщений в очередь
Manage. На управление очередью.

Естественно их можно комбинировать в любой последовательности.
Второй экшен контроллера предназначен для приема POST запросов от страницы, разбора параметров и добавления созданного правила к тестовой очереди.
Давайте теперь перейдем к проекту QueueClient – он очень простой. Основной код сосредоточен в Program.cs.

namespace QueueClient
{
    class Program
    {
        static void Main(string[] args)
        {
            Uri serviceBusUri = ServiceBusEnvironment.CreateServiceUri("sb", "feschenko", String.Empty);
            TokenProvider tokenProvider = TokenProvider.CreateSharedAccessSignatureTokenProvider(
                "SimpleSendRule", "J9SCe/giY2aO6vaY1mcB2oCtXeRANHiUmhlzLAibDtg=");
            MessagingFactory factory = MessagingFactory.Create(serviceBusUri, tokenProvider);
            var queueClient = factory.CreateQueueClient("sasdemo");
            var message = new BrokeredMessage("Test Rule Message");
            message.MessageId = Guid.NewGuid().ToString();
            queueClient.Send(message);
        }
    }
}

В коде мы создаем экземпляр очереди и пытаемся отправить тестовое сообщение. В случае если мы используем правило, позволяющее нам это сделать (то есть содержащее право Send) – код выполняется успешно. Иначе, обязательно вылетит исключение, извещающее нас о том, что мы не авторизованы для подобных действий.

На этом всё, как видим Shared Access Signatures - это мощное средство, которые можно использовать для получения доступа к элементам Service Bus в удобном и быстром виде с поддержкой различных уровней доступа.
Ссылка на скачивание разработанного проекта: https://dl.dropboxusercontent.com/u/18522369/Blog/ServiceBusSAS.zip

Windows Azure Notification Hubs - новый способ отправки push-уведомлений

2013-05-02T11:59:00.003-07:00

Всем привет! Тема моей сегодняшней публикации будет касаться нового механизма отправки push-уведомлений мобильным клиентам - Windows Azure Notification Hubs. Эта технология была представлена в январе 2013 года. Несмотря на то, что технология находится в режиме превью - она уже успела привлечь внимание многих разработчиков. Если вкратце, то Notification Hubs - это построенная на базе Windows Azure Service Bus система, позволяющая значительно упростить и расширить существующие механизмы отправки push-уведомлений мобильным клиентам (для тех из вас, кто незнаком с понятием пуш уведомлений - вот здесь можно посмотреть краткое описание механизма: Push Notifications: What are they and how do I send them). При помощи Windows Azure Notification Hubs мы можем с легкостью организовать систему уведомлений для наших мобильных устройств, при этом поддерживаются 2 платформы:

The Windows Push Notification Services (WNS) for Windows 8.
The Apple Push Notification service (APNs)

В будущем планируется поддержка Google Cloud Messaging for Android. Сегодня мы на примере увидим как отправить push-уведомление Windows 8 устройству, используя Windows Azure Notification Hubs.
Итак, наша цель отправить push-уведомление Windows Store приложению, используя при этом консольную программу и Windows Azure Notification Hubs. Само решение выглядит довольно просто (ссылка на скачивание солюшена находится в конце поста):

Солюшен состоит из 2-х проектов. Первый - EventSource, представляет собой консольное приложение, основная задача которого - это генерация сообщения и коммуникация с хабом с целью отправки push-уведомления. Второй проект - собственно само Windows Store приложение, которое будет получать приходящие уведомления. С него мы и начнем. Это пустое HTML5+Javascript приложение, основная логика которого находится в файле default.js. Другой важный файл, который можно также увидеть в проекте, это - NotificationHub,js, он содержит всю логику по взаимодействию с нотификационным хабом. Скачать данный файл можно с MSDN.

Прежде чем мы разберем исходный код приложения необходимо выполнить настройку приложения. Во-первых, для того чтобы оно стало способным принимать пуш уведомления, необходимо включить Toast Notifications в манифесте приложения. На скриншоте внизу можно увидеть как это сделать:

Во-вторых, нам необходимо ассоциировать приложение с Windows Store аккаунтом (если у вас нет аккаунта по следующей ссылке можно прочитать как его создать: Registering for a Windows Store developer account). Связывание приложения можно осуществить при помощи пункта меню Store >Associate App With The Store

После чего откроется простой диалог, выполнив все шаги которого, мы перейдем на сайт Windows Store разработчика, где нас попросят ввести имя приложения и задать дополнительные характеристики. Из этих характеристик нас интересуют Advanced Features.

При выборе этого пункта откроется новая страница, на которой следует кликнуть на ссылке Push Notifications And Live Services Info, после чего нас перебросят на следующую страницу, позволяющую увидеть ключи доступа (они понадобятся нам при насстройке самого хаба). Вот как выглядит конечная страница:

Следующим шагом в настройке проекта будет создание хаба. Делается это на портале Windows Azure выбором пункта New > App Services > Service Bus > Notification Hub

Нас попросят задать имя хаба, географический регион и Service Bus неймспейс, в рамках которого будет функционировать хаб. После этого новый хаб будет создан и мы сможем задать ключи безопасности для отправки уведомлений Windows 8 клиентам. Делается это в разделе Configure.

PACKAGE SID и CLIENT SECRET мы получили в момент ассоциирования Windows Store приложения с аккаунтом Windows 8 разработчика, поэтому все, что нам необходимо это перенести значения в настройки хаба.

На этом этап настройки инфраструктуры можно считать завершенным. Давайте перейдем непосредственно к коду. Исходный код Windows Store приложения представлен в листинге ниже:

(function () {
    "use strict";

    WinJS.Binding.optimizeBindingReferences = true;

    var app = WinJS.Application;
    var activation = Windows.ApplicationModel.Activation;
    var messaging = Microsoft.WindowsAzure.Messaging;

    var hub = new messaging.NotificationHub("https://[YOUR_SB_NAMESPACE].servicebus.windows.net/", "[NOTIFICATION_HUB_KEY]", "pushdemo");

    app.onactivated = function (args) {
        if (args.detail.kind === activation.ActivationKind.launch) {
            if (args.detail.previousExecutionState !== activation.ApplicationExecutionState.terminated) {
                var toastTemplate = '$(message)';
                var pushNotifications = Windows.Networking.PushNotifications;
                var channelOperation = pushNotifications.PushNotificationChannelManager.createPushNotificationChannelForApplicationAsync();

                channelOperation.then(function (newChannel) {
                    return newChannel.uri;
                }).then(function (channelUri) {
                    return hub.registerTemplateForApplicationAsync(channelUri, 'toast1', [], { 'X-WNS-Type': 'wns/toast' }, toastTemplate);
                }).done();
            }
            args.setPromise(WinJS.UI.processAll());
        }
    };

    app.oncheckpoint = function (args) {
    };

    app.start();
})();

Начнем с наиболее интересных участках кода. Первый важный фрагмент - это создание экземпляра хаба.

var hub = new messaging.NotificationHub("https://[YOUR_SB_NAMESPACE].servicebus.windows.net/", "[NOTIFICATION_HUB_KEY]", "pushdemo");

Для того, чтобы создать хаб нам необходимо задать имя Service Bus неймспейса, в рамках которого функционирует хаб, и ключ безопасности (третьим параметром идет название хаба, задаваемое на портале). Ключ безопасности берется из настроек хаба, на картинке ниже можно увидеть, что для нашего приложения достаточно ключа только с правами прослушивания канала.

Далее, в обработчике события запуска приложения происходит его регистрации на хабе путем вызова метода hub.registerTemplateForApplicationAsync. Регистрация принимает адрес канала, по которому будет происходит коммуникация, название используемого шаблона уведомлений (весь список поддерживаемых темплейтов здесь) и само содержимое уведомления. В нашем случае мы используем простой текстовый темплейт, который содержит подстановочный элемент $(message). Данный элемент позволяет динамически подменять содержимое уведомлений.

Давайте теперь посмотрим на содержимое файла Program.cs проекта EventSource.

using Microsoft.ServiceBus;
using Microsoft.ServiceBus.Messaging;
using Microsoft.ServiceBus.Notifications;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace EventSource
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Please, enter the message: ");
            var message = Console.ReadLine();
            var cn = ServiceBusConnectionStringBuilder.CreateUsingSharedAccessSecretWithFullAccess(new Uri("sb://[YOUR_SB_NAMESPACE].servicebus.windows.net"), "[NOTIFICATION_HUB_KEY]");
            var hubClient = NotificationHubClient.CreateClientFromConnectionString(cn, "pushdemo");
            hubClient.SendTemplateNotification(new Dictionary<string, string> { { "message", message } });
        }
    }
}

После своего запуска, консольное приложение просит ввести текст отправляемого уведомления. Далее происходит создание клиента к хабу, для чего необходимо опять же задать название Service Bus неймспейса и ключ безопасности (теперь нам нужен ключ с полными правами доступа к хабу). Как только клиент будет создан, можно отправлять уведомление. Делается это при помощи метода hubClient.SendTemplateNotification. Метод принимает набор ключей и их значений. При отправке уведомления инфраструктура хаба самостоятельно подменит все упоминания названий ключей на их значения. Для того, чтобы приложение успешно скомпилировалось необходимо предвартельно установить Nuget-пакет ServiceBus.Preview.dll
В итоге, после запуска приложения и ввода сообщения мы должны получить долгожданное уведомление.

На этом всё! Код разработанного проекта можно найти по ссылке

Для более детального знакомства с Windows Azure Notification Hubs рекомендую ознакомиться с дополнительным материалами по следующим ссылкам:

http://channel9.msdn.com/Blogs/Subscribe/Service-Bus-Notification-Hubs-Code-Walkthrough-Windows-8-Edition

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

http://channel9.msdn.com/Shows/Cloud+Cover/Episode-100-Introduction-to-the-Windows-Azure-Service-Bus-Notification-Hubs

http://channel9.msdn.com/Blogs/Subscribe/Service-Bus-Notification-Hubs-with-ElioDamaggio

Введение в Windows Azure IaaS

2013-02-06T06:29:00.001-08:00

Всем привет! 23 января я читал доклад на тему "Введение в Windows Azure IaaS" в рамках мероприятия IT-Share, которое проводится еженедельно в компании Epam Systems. Доклад был посвящен технологиям Windows Azure, предлагаемых в рамках услуги инфраструктура как сервис. Мы подробно рассмотрели вопросы создания и разворачивания виртуальных машин в облаке Windows Azure, а также поверхностно познакомились с предназначением и особенностями виртуальных сетей Windows Azure (Azure Virtual Private Networks).
Сегодня я хотел бы поделиться материалами доклада. Чуть ниже можно найти презентацию, а также видеозапись моего доклада.

Настраиваем Git развертывание для виртуальных машин Windows Azure.

2012-10-22T07:25:00.003-07:00

Привет всем! Сегодня я постараюсь подробно описать процесс настройки Git-публикации для виртуальных машин в Windows Azure. Многие из Вас уже знают, что Windows Azure предоставляет разработчикам возможность публикации приложений в облаке посредством Git (подробное описание этого процесса можно найти здесь http://habrahabr.ru/company/microsoft/blog/150086/), но немногие знают что Git публикация функционирует за счет так называемого проекта Kudu.
Kudu - это механизм, обеспечивающий в Windows Azure возможность развертывания Ваших приложений при помощи Git. Он распространяется под open source лицензией и доступен на GitHub (https://github.com/projectkudu/kudu). Большим преимуществом данного механизма является то, что он имеет способность запускаться вне среды Windows Azure. Это значит, что мы можем беспрепятственно загрузить его себе на машину и настроить Git развертывание в своей локальной среде. Учитывая эту особенность, было бы очень неплохо настроить подобный механизм для виртуальных машин Windows Azure. Именно это мы и попытаемся сделать.
Итак, прежде всего нам необходима целевая виртуальная машина, на которой будет разворачиваться наше приложение. Создать ее можно на портале Windows Azure в разделе Virtual Machines. Для наших целей можно воспользоваться опцией поднятия машины из галереи, что является наиболее быстрым вариантом.

Как только виртуальная машина будет настроена и запущена, мы сможем удаленно зайти на нее посредством протокола RDP и перейти к следующему шагу. На втором шаге нам необходимо склонировать удаленный репозиторий Kudu на нашу виртуальную машину и запустить мастер настройки нового приложения. Давайте последовательно это выполним. В первую очередь установим клиент Git для Windows. Для этого перейдем на сайт http://msysgit.github.com/, скачаем и установим программный комплекс (можно воспользоваться любым альтернативным клиентом Git). Как только инсталляция завершится, запустим git bash и склонируем репозиторий в любой каталог на диске С: (для тестирования жизнеспособности решения этот диск нас полностью устроит). Адрес репозитория можно найти на https://github.com/projectkudu/kudu.

Для клонирования Kudu запустим следующую команду в git bash.

git clone https://github.com/projectkudu/kudu.git

Результат операции должен выглядеть следующим образом.

Следующим шагом будет билд проекта. Для этого найдем в нашем каталоге файл [kudu_installation_dir]/kudu/build.cmd и запустим его с правами администратора. Процесс сборки проекта может длиться до 1 минуты, после чего нам необходимо будет создать новый сайт на локальном инстансе IIS для запуска консоли управления Kudu. Новый сайт необходимо направить на подкаталог [kudu_installation_dir]/kudu/Kudu.Web. Вот как это выглядит на IIS-инстансе виртуальной машины:

Мы используем кастомный 8080 порт, оставляя свободным 80-й порт, который будет использоваться основным приложением. Так как Kudu требует для своего правильного функционирования прав администратора, необходимо запустить наш пул приложений под менее ограниченным аккаунтом. Для этого перейдем в раздел Application Pools и в расширенных настройках пула сменим его Identity. На моей машине есть пользователь Administrator, который вполне нам подойдет.

После этого, не выходя из удаленного терминала, откроем браузер и проверим правильно ли работает сайт путем перехода по ссылке http://localhost:8080. Если все удачно настроено, мы должны увидеть консоль управления Kudu.

Как видим при первом запуске установленных приложений нет, поэтому нам необходимо создать новое. Делается это очень просто, путем выбора пункта меню Create Application, при этом все что нам необходимо будет сделать дальше - это выбрать имя создаваемого приложения Давайте остановимся на имени GitWithKudu.

Как только мы нажмем кнопку "Create Application", на локальном для виртуальной машины веб-сервере будут созданы 2 сайта: один предназначен для запуска основного приложения, а второй для поддержки Git-развёртывания. Вот как созданная нами инфраструктура будет выглядеть в итоге:

Сайт Kudu Enrironment - это Kudu-консоль управления всеми приложениями веб-сервера. Сайт kudu_gitwithkudu - наше приложение, разворачиваемое посредством Git. Сайт kudu_service_gitwithkudu - вспомогательное приложение, через которое будет происходить публикация. Давайте теперь снова на минутку вернемся к консоли управления Kudu. После создания нового приложения мы увидим следующий результат:

Как видим на этой странице представлена очень полезная информация. Тут мы можем найти адрес нашего Git-репозитория, адрес самого приложения, а также несколько вспомогательных вкладок, позволяющих отслеживать историю публикаций, изменять конфигурацию и т.д. По умолчанию Kudu использует простой механизм случайного выбора портов для основного приложения и deployment-сервиса, поэтому мы видим, что наше приложение будет использовать не стандартный порт 36263. Для его смены можно воспользоваться обычной техникой изменения привязок сайта в IIS Manager, что собственно мы и сделаем для перевода сайта на 80-й порт.

На этом все работы, связанные с настройкой нашей целевой виртуальной машины, можно считать завершенными. Все, что нам осталось сделать - это развернуть наше приложение посредством созданной инфраструктуры. Напомню, что после окончания настройки Kudu у нас появилось 3 сайта:

http://gitdeploy.cloudapp.net:8080 - консоль управления Kudu
http://gitdeploy.cloudapp.net - тестовое приложение
http://gitdeploy.cloudapp.net:60972 - deployment-сервис

*gitdeploy.cloudapp.net - это доменное имя нашей виртуальной машины, задается на стадии ее создания.
Но прежде чем приступить к разворачиванию приложения необходимо добавить порт 60972 в список разрешенных портов на портале Windows Azure. В конечном итоге наша секция Endpoints должна выглядеть подобным образом:

Как только новая точка с портом 60972 будет добавлена можно приступить к публикации. Для этого нам необходимо выполнить простую последовательность действий. Сначала создадим пустой каталог на диске и запустим git bash для него. Воспользуемся командой

git init

,для инициализации нового Git-репозитория. Добавим новый файл в репозиторий под названием index.html. Содержимое данного файла представлено ниже:

<html>
<head>
<title>
Windows Azure Kudu Engine!
</title>
</head>
<body>
<h1>
Hello Windows Azure!
</h1>
</body>
</html>

После создания файла последовательно выполним 2 git-команды:

git add .
git commit -m "First commit"

Нам осталось развернуть новый файл в облаке. Для этого выполним следующую git-комманду:

git push http://gitdeploy.cloudapp.net:60972/gitwithkudu.git

Для проверки откроем в браузере сайт http://gitdeploy.cloudapp.net. Мы должны увидеть наши изменения на сервере:

Кроме того в консоли управления Kudu во вкладке Deployments можно отследить всю историю развертываний:

Как видим мы успешно настроили Git-развёртывание для виртуальной машины Windows Azure на базе проекта Kudu. Несмотря на то, что этот проект еще молод и имеет ряд недостатков, я считаю его достаточно перспективным и интересным. На этом всё, спасибо за внимание! Надеюсь пост был интересным и познавательным.

Запускаем Windows Azure Service Bus локально.

2012-08-20T09:10:00.002-07:00

Всем привет! Совсем недавно в мире Windows Azure произошло очень важное событие, а именно был выпущен набор компонентов, позволяющих эмулировать Windows Azure Service Bus на локальной машине. Именно этой новой возможности и будет посвящен мой сегодняшний пост. Мы узнаем как установить эмулятор Service Bus себе на машину, как сконфигурировать его, а также напишем небольшое приложение для проверки его работоспособности.
Итак, согласно определению из MSDN, Windows Azure Service Bus for Windows Server – это набор инсталлируемых компонентов, предоставляющих возможность эмулирования соответствующей облачной технологии на ваших собственных серверах, с предустановленной ОС Windows Server. Программная модель абсолютна идентична облачной версии поэтому переключиться с локальной на облачную не составит большого труда и Вам не нужно будет переписывать приложение.
Основные возможности:

Симметричная модель программирования. Написав код один раз для локальной версии его не надо будет менять при переключении на облачную.
Отлаживать и тестировать приложения стало намного проще так как шина находится локально, что позволяет нам настраивать большинство ее параметров.
Быть может сейчас Вы не готовы переходить в облако по каким-то причинам (безопасность, юридические аспекты и др.). Эмулятор позволяет начать писать приложение сразу, а перейти на облачную версию тогда, когда вы будете готовы.

Для установки эмулятора можем воспользоваться Web Platform Installer. Компонент носит название Service Bus 1.0 Beta. Кроме установки самих компонентов необходимо также проверить следующие характеристики вашей машины:

У Вас есть доступ к инстансу SQL Server (Express версия также подходит)
Сервис SQL Browser должен быть разрешен и запущен
TCP/IP должен быть разрешен

Как только установка компонентов будет завершена необходимо настроить кластер. Здесь необходимо дать некоторые пояснения. Дело в том, что Service Bus for Windows Server имеет встроенную поддержку высокой доступности сервиса. Достигается это за счет использования кластеров вычислительных машин. Добавив как минимум 3 машины в кластер – Вы получите отказоустойчивое и высокодоступное решение. Схема такого решения представлена чуть ниже.

Следует отметить, что данная схема работает только для вычислительных инстансов. Для слоя хранения данных встроенной поддержки отказоустойчивости нет, необходимо использовать сторонние подходы, например, SQL Server Mirroring. Итак, первоначально нам необходимо создать новый кластер и добавить туда нашу девелоперскую машину. Делается это при помощи следующих PowerShell команд:

$mycert=ConvertTo-SecureString -string <password> -force -AsPlainText
New-SBFarm -FarmMgmtDBConnectionString "data source=localhost\sqlexpress;integrated security=true" –CertAutoGenerationKey $mycert
Add-SBHost -certautogenerationkey $mycert -FarmMgmtDBConnectionString "data source=localhost\sqlexpress; integrated security=true"

Здесь, в первой строке мы определяем пароль, который будет использоваться при генерации сертификата безопасности. Во второй строке мы создаем кластер/ферму, при этом необходимо указать правильный адрес SQL Server и криденшиалы для доступа к нему. Последней командой мы добавляем текущую машину в только что созданный кластер (здесь также следует обратить внимание на строку соединения). Как только все вышеуказанные команды выполняться успешно, на используемом экземпляре SQL Server мы должны увидеть 3 базы данных, которые буду служить как центром конфигурации кластера так и хранилищем данных для сообщений, курсирующих по шине.

Для проверки работоспособности кластера можно запустить специальную команду:

Get-SBFarmStatus

В результате выполнения команды мы должны получить следующую информацию:

Если какой либо из сервисов Service Bus не находится в состоянии Running, значит на предыдущем этапе возникли ошибки. В случае успешного запуска всех сервисов на следующем шаге нам необходимо создать неймспейс (как мы помним в облачной версии этот шаг выполняется на портале). Для этого необходимо выполнить следующую команду:

New-SBNamespace –Name TestSbNamespace –ManageUsers  yourDomain\yourUsername

В параметре –Name мы задаем название создаваемого неймспейса. В параметре –ManageUsers задается список пользователей, которые будут иметь права по управлению создаваемым неймспейсом. Как только команда выполнится успешно мы сможем перейти к написанию своего первого приложения, использующего локальную сервисную шину.

Реализация сценария Sender/Receiver на базе Windows Server Service Bus

Для тестирования напишем простое решение, позволяющее отправлять сообщения и принимать их посредством запущенной локально сервисной шины. Структура проекта относительно проста.

Это 2 консольных приложения.Одно из них используется для отправки сообщений, другое для приема. Давайте посмотрим на исходный код отправителя (Sender.cs).

namespace Microsoft.Samples.MessagingWithQueues
{
    using System;
    using System.Collections.Generic;
    using Microsoft.ServiceBus;
    using Microsoft.ServiceBus.Messaging;
    using System.Net.NetworkInformation;
    using System.Collections.Generic;

    public class Sender
    {
        const string QueueName = "MessagesQueue";
        static string ServiceNamespace;
        static string ServerDomainName = "localhost";
        static int HttpPort = 4446;
        static int TcpPort = 9354; 

        static void Main(string[] args)
        {
            GetUserCredentials();    
            
            Uri rootAddressManagement = ServiceBusEnvironment.CreatePathBasedServiceUri("sb", ServiceNamespace, string.Format("{0}:{1}", ServerDomainName, HttpPort));
            Uri rootAddressRuntime = ServiceBusEnvironment.CreatePathBasedServiceUri("sb", ServiceNamespace, string.Format("{0}:{1}", ServerDomainName, TcpPort));


            MessagingFactorySettings mfSettings = new MessagingFactorySettings();
            mfSettings.TokenProvider = TokenProvider.CreateWindowsTokenProvider(
                           new List<Uri>() { rootAddressManagement });           

            MessagingFactory factory = MessagingFactory.Create(rootAddressRuntime, mfSettings); 


            try
            {     
                NamespaceManagerSettings nmSettings = new NamespaceManagerSettings();               
                nmSettings.TokenProvider = TokenProvider.CreateWindowsTokenProvider(new List<Uri>() { rootAddressManagement });
                
                NamespaceManager namespaceManager = new NamespaceManager(rootAddressManagement, nmSettings);
                Console.WriteLine("\nCreating Queue '{0}'...", Sender.QueueName);

                // Delete if exists
                if (namespaceManager.QueueExists(Sender.QueueName))
                {
                    namespaceManager.DeleteQueue(Sender.QueueName);
                }
                namespaceManager.CreateQueue(Sender.QueueName);
                QueueClient myQueueClient = factory.CreateQueueClient(Sender.QueueName);
                string message = String.Empty;
                do
                {
                    message = Console.ReadLine();
                    myQueueClient.Send(CreateMessage(Guid.NewGuid().ToString(), message));
                } while (!String.IsNullOrEmpty(message));
            }
            catch (Exception e)
            {
                Console.WriteLine("Unexpected exception {0}", e.ToString());
                throw;
            }
            finally
            {
                // Closing factory close all entities created from the factory.
                if(factory != null)
                    factory.Close();
            }
            
        }

        static void GetUserCredentials()
        {
            Console.Write("Please provide the server Fully Quaified Domain Name to use (blank for localhost): ");
            ServerDomainName = Console.ReadLine();
            if (ServerDomainName.Equals("localhost") || String.IsNullOrEmpty(ServerDomainName))
            {
                var ipProperties = IPGlobalProperties.GetIPGlobalProperties();
                ServerDomainName = string.Format("{0}.{1}", ipProperties.HostName, ipProperties.DomainName);
            }
            
            Console.Write("Please provide the service namespace to use: ");
            ServiceNamespace = Console.ReadLine();
        }

        private static BrokeredMessage CreateMessage(string messageId, string messageBody)
        {            
            BrokeredMessage message = new BrokeredMessage(messageBody);
            message.MessageId = messageId;
            return message;
        }
    }
}

В первую очередь для начала отправки сообщений необходимо собрать информацию о месторасположении сервера и неймспейсе. Это происходит в методе GetUserCredentials, где мы запрашиваем DNS-имя сервера (в случае запуска шины локально можно ничего не вводить) и название неймспейса (в нашем случае это будет TestSbNamespace). Как облачная так и серверная версия Service Bus используют access-токены для предоставления доступа к своим внутренним элементам (subsriptions, topics, queues, entities ...). Но в отличие от серверной версии, облачная тесно интегрирована с Windows Azure Access Control Service поэтому для локальной версии была разработана своя подсистема, называемая Service Bus Security Token Service (SBST). Эта подсистема интегрирована с моделью безопасности Windows и позволяет генерировать токены, базируясь на Windows аккаунтах (поддерживается как локальное хранилище так и Active Directory). Для получения токена от локальной SBST мы используем метод TokenProvider.CreateWindowsTokenProvider, принимающий список защищаемых неймспейсов. В нашем случае нам необходимо сгенерировать токен дважды: для объекта класса MessagingFactory и для NamespaceManagerSettings. Для отправки сообщения в очередь необходимо создать объект класса BrokeredMessage и передать его методу Send, который доступен у объекта класса QueueClient.
Если в процессе написания кода вы столкнетесь в проблемой отсутствующих сборок, то скорее всего Вам необходимо будет инсталлировать пакет под названием Service Bus 1.0 Beta (for Windows Server) – делается это из окна пакетного менеджера Nuget

Код обработчика сообщений очень похож на код отправителя за исключением того, что здесь мы входим в бесконечный цикл ожидания сообщений и для их получения из очереди используем метод Receive. Полностью код обработчика сообщений представлен ниже:

namespace Microsoft.Samples.MessagingWithQueues
{
    using System;
    using Microsoft.ServiceBus;
    using Microsoft.ServiceBus.Messaging;
    using System.Net.NetworkInformation;
    using System.Collections.Generic;
    using System.Threading;

    public class Receiver
    {
        const string QueueName = "MessagesQueue";
        static string ServiceNamespace;
        static string ServerDomainName = "localhost";
        static int HttpPort = 4446;
        static int TcpPort = 9354; 

        static void Main(string[] args)
        {
            GetUserCredentials();

            Uri rootAddressManagement = ServiceBusEnvironment.CreatePathBasedServiceUri("sb", ServiceNamespace, string.Format("{0}:{1}", ServerDomainName, HttpPort));
            Uri rootAddressRuntime = ServiceBusEnvironment.CreatePathBasedServiceUri("sb", ServiceNamespace, string.Format("{0}:{1}", ServerDomainName, TcpPort));


            MessagingFactorySettings mfSettings = new MessagingFactorySettings();
            mfSettings.TokenProvider = TokenProvider.CreateWindowsTokenProvider(
                           new List<Uri>() { rootAddressManagement });

            MessagingFactory factory = MessagingFactory.Create(rootAddressRuntime, mfSettings); 

            try
            { 
                QueueClient myQueueClient = factory.CreateQueueClient(Receiver.QueueName, ReceiveMode.PeekLock);
                Console.WriteLine("\nReceiving messages from Queue '{0}'...", Receiver.QueueName);

                while (true)
                {
                    var message = myQueueClient.Receive();
                    if (message != null)
                    {
                        Console.WriteLine(String.Format("Message received: Id = {0}, Body = {1}", message.MessageId, message.GetBody<string>()));
                        message.Complete();
                    }
                }
            }
            catch (Exception e)
            {
                Console.WriteLine("Unexpected exception {0}", e.ToString());
                throw;
            }
            finally
            {
                // Closing factory close all entities created from the factory.
                if (factory != null)
                    factory.Close();
            }
        }

        static void GetUserCredentials()
        {
            Console.Write("Please provide the server FQDN to use (blank for localhost): ");
            ServerDomainName = Console.ReadLine();
            if ((string.Compare(ServerDomainName, "localhost", true) == 0) || string.IsNullOrEmpty(ServerDomainName))
            {
                var ipProperties = IPGlobalProperties.GetIPGlobalProperties();
                ServerDomainName = string.Format("{0}.{1}", ipProperties.HostName, ipProperties.DomainName);
            }

            Console.Write("Please provide the service namespace to use: ");
            ServiceNamespace = Console.ReadLine();
        }
    }
}

Метод Complete необходим для оповещения сервисной шины о том, что сообщение успешно обработано. После вызова этого метода сообщение физически удаляется из очереди. Если в обработчике произойдет сбой во время обработки сообщения, то оно снова станет доступным по истечение определенного промежутка времени. Это один из вариантов функционирования очереди, называемый PeekLock (Все варианты получения сообщений описаны на сайте Windows Azure). Сам процесс взаимодействия отправителя и получателя хорошо продемонстрирован на видео:

Как видим разработанное приложение на базе Service Bus for Windows Server работает исправно. Надеюсь информация была представлена в максимально удобном и понятном виде. Если будут вопросы или предложения, пишите в комментариях, будем обсуждать :) Спасибо за внимание! Ссылка на скачивание готового решения:

Асинхронная загрузка больших файлов в Blob Storage.

2012-08-17T04:38:00.000-07:00

Привет всем! Сегодня я хотел бы подробно описать процедуру загрузки больших файлов в хранилище блобов. Данная задача возникла пару месяцев назад на одном из наших проектов и заставила меня искать возможные варианты ее решения. Предложенный подход не является чем-то совершенно новым и скорее всего не вызовет у Вас удивления. Он заключается в использовании такой распространенной библиотеки как JQuery File Upload (http://blueimp.github.com/jQuery-File-Upload/) в связке с возможностью поблочной загрузки блобов в хранилище. Процесс загрузки должен оптимально использовать канал и в меньшей степени нагружать промежуточный веб-сервер, поэтому собственно и было принято решение не загружать файл целиком, а предварительно разбивать его на небольшие фрагменты.

Итак, для демонстрации я создал простое тестовое веб-приложение, в котором существует одна простая страница. На этой странице пользователь имеет возможность выбрать файл и стартовать процесс загрузки. Механизм загрузки файла естественно должен быть асинхронным и пользователь должен иметь возможность отслеживать прогресс операции. Давайте посмотрим на последовательность операций, необходимых для успешной загрузки файла в хранилище.

Прежде чем инициировать загрузку нового файла, клиент (в нашем случае браузер) создает новую загрузочную сессию и присваивает ей уникальный идентификатор. После чего файл автоматически разбивается на части и загружается последовательно на сервер. Сервер в свою очередь принимает входящий поток байтов и отправляет его в виде блока в хранилище блобов (для этого используется операция PutBlock). Как только все фрагменты файла успешно загружены на сервер, клиент инициирует операцию их слияния. Для этого отправляется HTTP запрос на сервер, где он трансформируется в операцию PutBlockList, после чего исходный файл становится доступным в хранилище блобов.
Давайте посмотрим на то, как этот процесс реализован в Visual Studio. Проект относительно простой, на следующей картинке можно увидеть его структуру.

Из всех присутствующих файлов нас интересуют лишь 5. Прежде всего очень важно представление Index.chtml – здесь сосредоточена вся логика связанная с клиентской частью. Исходный код этого файла представлен ниже.

<html>
<head>
    <link href="../../Content/bootstrap.css" rel="stylesheet" type="text/css" />
    <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
    <script src="../../Scripts/jquery.ui.widget.js" type="text/javascript"></script>
    <script src="../../Scripts/jquery.iframe-transport.js" type="text/javascript"></script>
    <script src="../../Scripts/jquery.fileupload.js" type="text/javascript"></script>
    <script type="text/javascript">
        function guidGenerator() {
            var S4 = function () {
                return (((1 + Math.random()) * 0x10000) | 0).toString(16).substring(1);
            };
            return (S4() + S4() + "-" + S4() + "-" + S4() + "-" + S4() + "-" + S4() + S4() + S4());
        }
        function MergeBlocks(filename) {
            $.post('/upload/mergeblocks', { FileName: filename, SessionId: $('#sessionId').val() });
        }
        $(function () {
            $('#dictionaryFileInputContainer').fileupload({
                url: '/filetransfer.ashx',
                paramName: "dictionaryFile",
                maxChunkSize: 4194304,
                add: function (e, data) {
                    $('#createButton').on('click', function () {
                        $('#sessionId').val(guidGenerator());
                        data.submit();
                    })
                }
            })
                .bind('fileuploadprogressall', function (e, data) {
                    var progress = parseInt(data.loaded / data.total * 100, 10);
                    progress = progress == 99 ? 100 : progress;
                    $('#uploadingProgressBar').css('width', progress + '%');
                })
                .bind('fileuploadalways', function (e, data) {
                    $('#uploadingProgressBar').css('width', '100%');
                    MergeBlocks(data.files[0].name);
                })
        })
    </script>
</head>
    <body>
        <div class="container">
            <form class="form-horizontal" enctype="multipart/form-data" id="dictionaryCreationForm" action="upload" method="POST">
                <fieldset>
                    <input type="hidden" name="sessionId" id="sessionId" />
                    <div class="control-group">
                        <div class="controls">
                            <input type="file" id="dictionaryFileInputContainer" name="uploadedFileName" />
                        </div>
                    </div>
                    <div class="control-group">
                        <label class="control-label" for="uploadingProgressBar">
                            Uploading Progress</label>
                        <div class="controls">
                            <div class="progress progress-info" style="width: 30%">
                                <div class="bar" style="width: 0%;" id="uploadingProgressBar">
                                </div>
                            </div>
                        </div>
                    </div>
                    <div class="control-group">
                        <div class="controls">
                            <input type="button" id="createButton" class="btn" value="Submit">
                        </div>
                    </div>
                </fieldset>
        </form>
        </div>
    </body>
</html>

Визуальных элементов на этой странице минимум – это кнопки выбора файла и начала загрузки. Больший интерес представляет js-код. Здесь используется библиотека JQuery File Upload. Все, что нам необходимо это сконфигурировать движок и “подвеситься” на необходимые нам обработчики событий.

        $(function () {
            $('#dictionaryFileInputContainer').fileupload({
                url: '/filetransfer.ashx',
                paramName: "dictionaryFile",
                maxChunkSize: 4194304,
                add: function (e, data) {
                    $('#createButton').on('click', function () {
                        $('#sessionId').val(guidGenerator());
                        data.submit();
                    })
                }
            })
                .bind('fileuploadprogressall', function (e, data) {
                    var progress = parseInt(data.loaded / data.total * 100, 10);
                    progress = progress == 99 ? 100 : progress;
                    $('#uploadingProgressBar').css('width', progress + '%');
                })
                .bind('fileuploadalways', function (e, data) {
                    $('#uploadingProgressBar').css('width', '100%');
                    MergeBlocks(data.files[0].name);
                })
        })

Как видим обрабатывать фрагменты файлов будет хендлер filetransfer.ashx, а максимальный размер запроса не будет превышать 4Мб (это обусловлено ограничением на размер одного блока в хранилище блобов). Как только файл будет выбран и пользователь нажмет на кнопку его отправки – будет создана новая сессия и клиент начнет отправлять файл. Вот как это реализовано:

  add: function (e, data) {
                    $('#createButton').on('click', function () {
                        $('#sessionId').val(guidGenerator());
                        data.submit();
                    })
                }

Для того, чтобы отслеживать прогресс загрузки мы используем 2 обработчика события – это fileuploadprogressall и fileuploadalways. Последний срабатывает в момент завершения загрузки финального фрагмента. В этом обработчике мы отправляем запрос на слияние предварительно загруженных фрагментов путем вызова метода MergeBlocks. Вот его код.

        function MergeBlocks(filename) {
            $.post('/upload/mergeblocks', { FileName: filename, SessionId: $('#sessionId').val() });
        }

Как видим мы просто отправляем POST-запрос на определенный URL с указанием названия файла и идентификатора сессии.

Следующий, интересующий нас файл, это FileTranfer.ashx. Он обрабатывает приходящие фрагменты файлов и отправляет их в хранилище. Вот его исходный код:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using Microsoft.WindowsAzure;
using Microsoft.WindowsAzure.StorageClient;
using System.IO;
using Newtonsoft.Json;
using System.Text;
using AsyncLargeFilesUpload.Web.Models;

namespace AsyncLargeFilesUpload.Web
{
    public class FileTransfer : IHttpHandler
    {
        private const string SessionIdKeyName = "sessionId";

        public void ProcessRequest(HttpContext context)
        {
            if (!context.Request.Params.AllKeys.Contains(SessionIdKeyName))
            {
                throw new ArgumentNullException("Session id required");
            }
            SessionsManager.CreateIfNotExists(context.Request[SessionIdKeyName]);
            context.Response.AddHeader("Pragma", "no-cache");
            context.Response.AddHeader("Cache-Control", "private, no-cache");
            UploadFile(context);
        }

        private void UploadFile(HttpContext context)
        {
            var headers = context.Request.Headers;

            if (!String.IsNullOrEmpty(headers["X-File-Name"]))
            {
                UploadPartialFile(Path.GetFileName(headers["X-File-Name"]), context);
            }

            WriteResponse(context);
        }

        private void WriteResponse(HttpContext context)
        {
            context.Response.AddHeader("Vary", "Accept");
            try
            {
                if (context.Request["HTTP_ACCEPT"].Contains("application/json"))
                    context.Response.ContentType = "application/json";
                else
                    context.Response.ContentType = "text/plain";
            }
            catch
            {
                context.Response.ContentType = "text/plain";
            }

            context.Response.Write(@"{ Result: 1, Message: ""Chunk Uploaded"" }");
        }

        private void UploadPartialFile(string fullName, HttpContext context)
        {
            if (context.Request.Files.Count != 1)
                throw new HttpRequestValidationException("Attempt to upload chunked file containing more than one fragment per request");
            var inputStream = context.Request.Files[0].InputStream;
            byte[] fileBytes;
            using (var reader = new BinaryReader(inputStream))
            {
                fileBytes = reader.ReadBytes((int)inputStream.Length);
            }
            var blockId = Guid.NewGuid().ToString();
            SessionsManager.AddItem(context.Request[SessionIdKeyName], blockId);
            var storageAccount = CloudStorageAccount.Parse("UseDevelopmentStorage=true");
            var blobClient = storageAccount.CreateCloudBlobClient();
            CloudBlobContainer container = blobClient.GetContainerReference(MvcApplication.FilesContainerName);
            container.CreateIfNotExist();
            var permission = container.GetPermissions();
            permission.PublicAccess = BlobContainerPublicAccessType.Container;
            container.SetPermissions(permission);
            CloudBlockBlob blob = container.GetBlockBlobReference(fullName);
            using (var stream = new MemoryStream(fileBytes, true))
            {
                blob.PutBlock(Convert.ToBase64String(Encoding.UTF8.GetBytes(blockId)), stream, null);
            }
        }

        public bool IsReusable
        {
            get
            {
                return false;
            }
        }
    }
}

Код относительно прост и не требует особых пояснений. В нем можно отметить лишь процесс отправки блока. Для этого используется метод PutBlock, он принимает идентификатор блока (в кодировке base64) и собственно сам набор байтов. Так как нам для слияния блоков в дальнейшем потребуются их идентификаторы – необходимы их где-то хранить. Для этого был разработан класс SessionsManager. Вот его исходный код:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace AsyncLargeFilesUpload.Web.Models
{
    public static class SessionsManager
    {
        static Dictionary<string, IList<string>> fileParts = new Dictionary<string, IList<string>>();

        public static void AddItem(string key, string value)
        {
            fileParts[key].Add(value);
        }

        public static bool CreateIfNotExists(string key)
        {
            bool result = false;
            if (
          !fileParts.Keys.Contains(key) ||
          fileParts[key] == null ||
          fileParts[key].Count == 0)
            {
                fileParts.Add(key, new List<string>());
                result = true;
            }
            return result;
        }

        public static IList<string> GetBlockListBySessionId(string sessionId)
        {
            return fileParts[sessionId];
        }

        public static void RemoveSessionBlocks(string sessionId)
        {
            fileParts.Remove(sessionId);
        }
    }
}

Для тестирования решения мы просто храним идентификаторы блоков в статической коллекции (в производственной среде возможно следует подумать о другом хранилище). Каждая такая коллекция привязана к одной сессии поэтому используется структура Dictionary<string, IList<string>>. Последний проектный файл, который необходимо рассмотреть – это UploadController. Вот его исходный код:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using AsyncLargeFilesUpload.Web.Models;
using Microsoft.WindowsAzure;
using Microsoft.WindowsAzure.StorageClient;
using System.Text;

namespace AsyncLargeFilesUpload.Web.Controllers
{
    public class UploadController : Controller
    {
        public ActionResult Index()
        {
            return View();
        }

        public JsonResult MergeBlocks(CompleteFileUploadRequest file)
        {
            var storageAccount = CloudStorageAccount.Parse("UseDevelopmentStorage=true");
            var blobClient = storageAccount.CreateCloudBlobClient();
            CloudBlobContainer container = blobClient.GetContainerReference(MvcApplication.FilesContainerName);
            var blockList = SessionsManager.GetBlockListBySessionId(file.SessionId);
            var blob = container.GetBlockBlobReference(file.FileName);
            blob.PutBlockList(blockList.Select(entry => Convert.ToBase64String(Encoding.UTF8.GetBytes(entry))));
            SessionsManager.RemoveSessionBlocks(file.SessionId);
            return Json("Ok");
        }
    }
}

Для слияния блоков используется экшен MergeBlocks, он принимает комплексный объект CompleteFileUploadRequest, содержащий название файла и идентификатор сессии. Последовательность действий очень проста:

Получить ссылку на интересующий блоб
Получить список блоков для переданной в параметре сессии var blockList = SessionsManager.GetBlockListBySessionId(file.SessionId)
Слить блоки в один блоб blob.PutBlockList(blockList.Select(entry => Convert.ToBase64String(Encoding.UTF8.GetBytes(entry))));

Вот собственно и все. Ссылку на скачивание готового решения можно найти чуть ниже. Аргументированная критика и возможности по улучшению подхода приветствуются :) Спасибо за внимание!

Тренинг по Windows Azure. Масштабирование и кеширование.

2012-06-30T06:14:00.002-07:00

Последний день тренинга был посвящен разновидностям масштабирования приложений в облаке (Scale Up vs Scale Out), технике распределенного кеширования данных в Windows Azure (Azure Caching Service), а также основам функционирования Windows Azure Traffic Manager. Презентация доступна чуть ниже, скачать ее можно на сайте Slideshare.

Windows Azure. Scaling, Caching and Performance

Для загрузки практической части можно воспользоваться следующей ссылкой: Windows Azure Caching Service

Тренинг по Windows Azure. Безопасность и диагностика.

2012-06-30T06:06:00.002-07:00

Третий день был целиком и полностью посвящен безопасности приложений в облаке и их диагностике. В течение занятия слушатели познакомились с уровнями безопасности, предлагаемые платформой, начиная от физической и заканчивая информационной. Во второй части занятия был рассмотрен облачный сервис Access Control Service, его предназначение и принципы работы. В заключительной части занятия были рассмотрены средства диагностирования приложений в облаке при помощи Windows Azure Diagnostics.

Windows Azure Security and Diagnostics

Для скачивания практической части можно воспользоваться следующей ссылкой: Windows Azure Security and Diagnostics

Тренинг по Windows Azure. Windows Azure Storage.

2012-06-30T05:52:00.001-07:00

Второй день был посвящен хранилищу данных в Windows Azure. В течение занятия кратко рассмотрели варианты реализации реляционной и нереляционной моделей в Windows Azure. Большая часть занятия была посвящена Windows Azure Storage, а если конкретнее, то такими популярным абстракциям как Blobs, Tables, Queues, Drives.

Windows Azure Storage

Скачать практическую часть можно по следующей ссылке: Windows Azure Storage Demo

Тренинг по Windows Azure. Обзор платформы и жизненный цикл приложения

2012-06-30T05:38:00.002-07:00

Привет всем! Совсем недавно я прочитал тренинг, посвященный платформе Windows Azure. Тренинг проходил на базе Харьковского Национального Университета Радиоэлектроники. Желающих послушать присутствовать было на удивление очень много, но к сожалению Microsoft Innovation Center принять всех не смог. Занятия были разбиты на 4 дня по 2 часа каждое. И сегодня я начинаю публикацию материалов и презентаций.

Первый день был вводным. В течение занятия было рассказано о облачных вычислениях и платформе Windows Azure. Во второй части доклада больший упор был сделан на жизненном цикле облачного приложения. Презентацию можно посмотреть чуть ниже, а скачать на сайте Slideshare

Uneta 18.05.2012. Материалы доклада.

2012-05-19T06:55:00.002-07:00

18-го мая в Харькове прошла очередная встреча юзер-группы Uneta, на которой я выступал в качестве докладчика с темой "Высокопроизводительные приложения на базе Windows Azure. Пример реального проекта". Несмотря на теплый майский вечер встречу посетило достаточно много IT-людей. В течение своего доклада я рассказал о примере запуска нашей компанией высоконагруженного проекта SQL Server Launch. И хотя доклад получился относительно коротким, надеюсь он понравился слушателям и принес немало пользы. Посмотреть или скачать презентацию заново можно на сервис Slideshare, куда я заблаговременно ее загрузил.

Анонсирован новый набор Azure-сервисов по работе с медиа контентом

2012-04-17T14:54:00.000-07:00

Совсем недавно на официальном блоге Скота Гатри был анонсирован новый набор облачных сервисов по работе с медиа контентом. Новая услуга будет распространяться согласно модели PaaS и будет предоставлять пользователям возможности по построению и доставке эффективных медиа-решений конечным пользователям. Наиболее распространенные сценарии применения новой услуги представлены на рисунке ниже (взято с официального сайта http://windowsazure.com)

Контент может доставляться к любым клиентам, начиная от HTML5, Silverlight, Flash и заканчивая Windows 8, IPad, Android и WP7. При этом поддерживаются различные варианты стриминга содержимого – Smooth Streaming, Http Live Streaming и Flash Media Streaming. Услугу можно будет использовать для построения как облачных решений так и гибридных, в которых будет использоваться лишь небольшая часть функциональности медиа сервисов (примером, может послужить загрузка видео-файлов для последующей конвертации в различные форматы и распространения их через системы доставки контента). Построена услуга на базе популярной медиа платформы Microsoft (http://www.microsoft.com/en-us/mediaplatform/). Среди большого списка заявленных возможностей хотелось бы отметить следующие:

Кодирование. Сервисом поддерживается целый набор кодеков и форматов кодирования видео, включая Smooth Streaming, HTTP Live Streaming, MPEG-DASH и Flash. Кроме того у разработчика всегда есть возможность воспользоваться либо встроенным декодером Windows Azure Media Encoder либо любым другим внешним решением.
Конвертирование. Сервис предлагает ряд средств по конвертации медиа-файлов в любой формат. При этом процесс абсолютно прозрачен и контролируем.
Защита содержимого. Система поддерживает такие глобально известные системы по защите медиа-содержимого как MPEG Common Encryption и Microsoft PlayReady, с помощью которых Вы можете с легкостью добавлять DRM-подобную защиту к вашему содержимому.
Стриминг содержимого по требованию. Системой поддерживается доставка контента при помощи Windows Azure CDN, а также при помощи сторонних сетей доставки содержимого. При этом, как всегда в облаке, обеспечиваются широкие возможности по масштабированию таких решений.
Живой стриминг (Live Streaming). При помощи Azure медиа сервисов каждый разработчик сможет создавать свои собственные live-стриминг каналы, используя такие возможности платформы как DVR и Instant Replay

В общем звучит это очень интересно и загадочно. Пока что медиа сервисы находятся в стадии CTP, но уже сейчас их можно попробовать (подробности получения доступа можно прочитать на блоге Скота Гатри).
Если кого-то заинтересовала новая функциональность платформы, то поверхностно можно ознакомиться с ней по следующим ссылкам:

Ждем более подробного описания услуги ибо заявленная функциональность впечатляет и однозначно будет востребована на рынке разработки программного обеспечения.

Повышение отказоустойчивости облачных приложений при помощи Transient Fault Handling Block.

2012-04-09T14:45:00.001-07:00

Привет всем ! Сегодня речь пойдет об отказоустойчивости облачных приложений. В принципе механизм, который будет рассматриваться в сегодняшней публикации, не новый. Мы все его прекрасно знаем – это обработка временных сбоев программы при помощи Retry Logic. Данная техника славится своей простотой и высокой надежностью.

В процессе написания облачного приложения, программист сталкивается с большим количеством программных сбоев, особое место среди которых занимают так называемые временные сбои. Это могут быть как проблемы с сетевой коммуникацией, так и проблемы связанные с определенными ограничениями используемого сервиса. Вероятность появления такого рода ошибок в облаке возрастает в разы, так как каждый сервис, предоставляемый платформой, содержит ряд ограничений. Например, в Azure Caching сервисе присутствует целый ряд ограничений, начиная от количества транзакций в час и заканчивая максимально допустимым количеством одновременных соединений (http://msdn.microsoft.com/en-us/library/windowsazure/hh697522.aspx#C_BKMK_FAQ8). Если ваше приложений превысит установленную квоту – сработает так называемый механизм тротлинга (throttling). При этом в приложении выскочит исключение, что естественно не порадует конечного пользователя. Как правило подобного рода сбои носят временный характер и если повторить операцию через определенный промежуток времени – она завершится успешно. Учитывая тот факт, что все облачные сервисы содержат ряд квот – данная проблема становится очень актуальной и важной.
Именно для решения подобного вида проблем командой Microsoft Patterns&Practices был разработан модуль библиотеки Enterprise Library, именуемый Thransient Fault Handling Application Block. Этот блок повышает отказоустойчивость вашего приложения путем предоставления механизмов для обработки временных сбоев. Блок доступен через NuGet, подключить его к вашему проекту можно при помощи следующей команды:

Install-Package EnterpriseLibrary.WindowsAzure.TransientFaultHandling

Блок оперирует таким понятием как стратегия. Стратегия позволяет блоку, во-первых, определить действительно ли сбой связан с временной проблемой, а во-вторых, предоставляет наилучший способ решения этой проблемы. На сегодняшний день вместе с блоком поставляются 4 стратегии для 4-х облачных сервисов:

SQL Azure
Windows Azure Service Bus
Windows Azure Storage Service
Windows Azure Caching Service

Способ решения временных сбоев у блока один – это повторное выполнение операции. Он позволяет настроить интервал времени, по прошествии которого операция будет повторно выполнена. По умолчанию поддерживаются 3 варианта формирования временного отрезка:

Кроме того блок позволяет настроить собственную политику формирования временных интервалов, а также механизмы определения временных сбоев, что предоставляет нам прекрасные возможности по расширению этого полезного модуля Enterprise Library.
Познакомившись с предназначением блока и с принципами его функционирования, давайте посмотрим как программно можно его использовать для повышения отказоустойчивости приложений, использующих SQL Azure.
SQL Azure, как и многие другие, сервисы Windows Azure содержит ряд ограничений и квот, нарушение которых будет вести к "падениям" ваших приложений. Немного поискав в Интернете список ограничений SQL Azure я наткнулся на следующую табличку:

Throttling type	Soft Throttling limit exceeded	Hard Throttling limit exceeded
Temporary disk space problem occurred	0x01	0x02
Temporary log space problem occurred	0x04	0x08
High-volume transaction/write/update activity exists	0x10	0x20
High-volume database input/output (I/O) activity exists	0x40	0x80
High-volume CPU activity exists	0x100	0x200
Database quota exceeded	0x400	0x800
Too many concurrent requests occurred	0x4000	0x8000

То есть, например, если наше приложение открыло “тяжелый” курсор на сервере и он стал “пожирать” процессорное время – мы получим в приложении ошибку с кодом 0х100 (на самом деле код ошибки будем немного другим, но нас сейчас это не сильно интересует), на которую необходимо как-то реагировать. Первый и самый простой вариант – это попробовать заново выполнить неудачную операцию. И сделаем мы это при помощи Transient Fault Handling Application Block. Блок содержит в себе механизмы, применимые как к чистому ADO.NET так и к Entity Framework. Вот пример, как изменить программный код с целью добавления логики повторного выполнения неудачной операции:

RetryPolicy retryPolicy = new RetryPolicy‹SqlAzureTransientErrorDetectionStrategy›(3, TimeSpan.FromSeconds(30));
using (ReliableSqlConnection connection = new ReliableSqlConnection(connectionString, retryPolicy, retryPolicy))
{
    try
    {
        connection.Open();
        using (var command = connection.CreateCommand())
        {
            command.CommandText = "SELECT * FROM Employees";
            using (var rdr = cnn.ExecuteCommand‹IDataReader›(cmd))
            {
                //
            }
        }
    }
    catch (Exception ex)
    {
        MessageBox.Show(ex.Message.ToString());
    }
}

Как мы видим необходимо лишь задать политику и изменить стандартный класс SQLConnection на ReliableSqlConnection. В данном случае наша политика гласит: “Использовать стратегию определения временных падений SQL Azure. В случае неудачной операции – попробовать выполнить ее снова. Количество попыток равно 3. Интервал между попытками равен 30 секундам. В случае, если ничего не получится – передать исключение внешнему коду”. Похожим образом можно добавить логику повторных операций для приложений, использующих Entity Framework в качестве слоя для доступа к данным:

using (NorthwindEntities dc = new NorthwindEntities())
{
    RetryPolicy myPolicy = new RetryPolicy‹SqlAzureTransientErrorDetectionStrategy›(3);
    Employee e1 = myPolicy.ExecuteAction‹Employee›(() =>
        (from x in dc.Employees
            where x.LastName == "King"
            select x).First());
}

В данном случае мы снова создаем политику (логика работы такая же как и в предыдущем случае, так как 30-секундный интервал используется блоком по умолчанию). Но сам код немного изменился по сравнению с предыдущим случаем. Процесс создания контекста не изменился, изменился способ выполнения запроса. Он оборачивается методом политики ExecuteAction, принимающий в качестве параметра Action. Если запрос по каким-то причинам не выполнится, инфраструктура блока попробует запустить его заново по прошествии 30 секунд.
Как видим техника использования Transient Fault Handling Application Block довольно таки проста и понятна. Поэтому если в приложении вы используете вышеперечисленные Azure-сервисы (Storage, Service Bus, Caching, SQL Azure), не задумываясь прикручивайте retry-логику к нему – это сделает ваше приложение более отказоустойчивым, а ваши ночи более спокойными :)
Спасибо за внимание ! Надеюсь этот пост был для вас полезным.

Несколько ссылок для более глубокого знакомства с Transient Fault Handling Application Block:

Новые центры обработки данных Windows Azure

2012-04-08T15:00:00.000-07:00

Привет всем ! Буквально на днях (5 апреля) в семействе датацентров Windows Azure произошло пополнение – были добавлены 2 новых датацентра. Новые центры обработки данных расположены в США. На портале разработчика их можно увидеть под именами West US и East US. На сегодняшний день новые центры доступны для сервисов Azure Compute и Azure Storage. В течение нескольких последующих месяцев обещают добавить поддержку новых датацентров в SQL Azure.

Что касается гео-репликации, то американские датацентры будут сгруппированы следующим образом:

US East и West
US North и South

Как я говорил, новые датацентры уже доступны на девелоперском портале, поэтому можно прямо сейчас начать их тестировать. Прайсинговая модель не изменилась и распространяется она, как и прежде, на все центры обработки данных Windows Azure. Официальный анонс данного события можно найти по данной ссылке
Спасибо !

Как я выступал на MSSWIT 2012

2012-03-26T13:14:00.003-07:00

Привет всем ! Давно я не писал в свой блог. Пора исправлять эту ситуацию, тем более повод появился очень значимый,а именно мое выступление на MSSWIT 2012. Если говорить о том, когда я узнал о своем выступлении, то это произошло приблизительно 2 месяца назад. И хотя тема для меня была выбрана не профильная (я все же больше ожидал темы по Windows Azure, так как являюсь экспертом в данной области), отказываться от выступления на таком масштабном мероприятия было бы глупо.
Поэтому сбор информации с моей стороны начался сразу же после извещения о моем участии в конференции. Тема была связана с HTML5 WebSockets и WebWorkers, что сразу меня несколько обрадовало, так как я слышал, что это интереснейшие технологии, которые могут править Вебом в будущем. В процессе подготовки я не один раз в этом убедился :)

Что касается самого доклада, то он прошел увы не без проблем. О чем говорить,если сама моя поездка началась с приключений на поезде. Был куплен неправильный билет, поэтому пришлось его в экстренном порядке менять и бежать на отправляющийся поезд ! Сама презентация также была омрачена сразу несколькими проблемами. Во-первых каким-то чудом сломалась первая демонстрация функциональности веб-сокетов, причем прогонялась она дома с десяток раз :(( Позднее, уже после доклада, ее удалось снова магическим способом запустить без каких-либо изменений, поэтому все мои подозрения упали на презентер. По-видимому он блокирует 80-й порт, что не позволяет IIS нормально обрабатывать запросы. Вторая проблема возникла в середине доклада, когда внезапно сломался микрофон, к счастью у админов нашелся запасной !

В целом надеюсь мой доклад несмотря на ряд проблем, слушателям понравился и принес немало пользы. Вот собственно сама презентация:

По данной ссылке можно скачать исходные коды демонстраций (а их было 3, включая демонстрацию работы веб-сокетов, веб-воркеров и библиотеки SignalR):
Забрать демо

Спасибо организаторам за прекрасную конференцию и моим слушателям, которые проявили недюжинный интерес к технологии, несмотря на определенные проблемы, возникавшие во время доклада :)

Я пополнил ряды MVP !

2012-01-12T14:44:00.000-08:00

Привет всем ! Сегодня ко мне наконец-то добралась моя посылка от Microsoft, подтвердившая звание Windows Azure MVP. И хотя я узнал о номинации еще в начале января - все ждал пока прибудет мой MVP Kit, чтобы официально запостить эту информацию в своем блоге. Для меня это первая номинация поэтому она самая волнующая.
Мой путь к MVP был достаточно долгим, учитывая тот факт, что впервые я познакомился с платформой еще в университете, когда выполнял курсовую работу с использованием облака (тогда еще платформа была в стадии CTP и работала через пень-колоду). Еще тогда для меня это было очень интересным - прикоснуться к совершенно новой модели построения и распространения приложений. И сейчас, когда мы уже видим как облачные технологии медленно но уверенно становятся доминирующей силой на рынке, я нисколько не жалею что выбрал именно эту экспертизу. Хотелось бы отдельно поблагодарить Дениса Резника и Владимира Лещинского, которые помогали советами и направляли в нужное русло, а также вас - читателей моего блога, также отыгравшим немаловажную роль в получении МVP. Обещаю быть достойным такого звания и продолжать предоставлять сообществу интересную информацию о Windows Azure. See you in 2012 !

Windows Azure & Amazon Web Services. Сравнительная характеристика.

2011-12-24T11:44:00.001-08:00

Привет всем ! Сегодня я попытаюсь дать сравнительную характеристику двух гигантов облачного рынка, а именно Windows Azure и Amazon Web Services. В процессе своей работы мне приходилось выполнять проекты, основанные как на одной так и на другой технологии, поэтому идея составить сравнительную характеристику назревала уже довольно таки давно. После анализа большого количества подобных материалов в Интернете, а также основываясь на личном опыте и помощи одного из Windows Azure MVP и было принято решение написать этот пост.

Как мы все знаем обе платформы были введены в эксплуатацию сравнительно недавно (AWS в 2006, Windows Azure в 2008-м), услугами обеих платформ пользуются всемирно известные корпорации (чего стоят только NASA, Ericsson, T-Mobile, Boeing и другие), обе платформы позиционируют себя как лидера в сфере облачных вычислений поэтому их сравнение является едва ли не самой важной альтернативой, позволяющей оценить уровень предоставляемых услуг. Сравнение будет организовано в виде описания основных категорий в сфере облачных вычислений и описания того как та или иная категория реализована в AWS и Windows Azure

Стратегия развития
И начнем мы с наиболее важного как я считаю аспекта – это стратегии развития. Как нам всем известно на сегодняшний день облачные провайдеры умеют предоставлять свои услуги по 3-м схемам – это IaaS, PaaS и SaaS. Углубляться в описание данных терминов я не стану так как они уже “изжеваны” по всей Сети, скажу лишь то, что AWS предоставляет свои услуги по схеме IaaS, Windows Azure в свою очередь по схеме PaaS и этим они кардинально отличаются. Хотя обе платформы делают определенные сподвижки в сторону других схем, их первоначальная “природа” остается той же.

Соглашения о уровне предоставляемых услуг
Обе платформы предоставляют своим клиентам SLA`s, гарантирующие высокий уровень услуг (вычислительные мощности доступны в течение 99,95 % времени, для других сервисов гарантируется доступность в течение 99,9 % общего времени).

Масштабируемость
Как Windows Azure так и Amazon Web Services поддерживают автоматическое масштабирование. Это касается как горизонтального (повышение производительности решения за счет увеличения количества виртуальных инстансов, что позволяет распределить полезную нагрузку и тем самым значительно повысить общую производительность системы) так и вертикального масштабирования (увеличение производительности системы за счет добавления ресурсов к отдельным виртуальным машинами, например. за счет увеличения объема оперативной памяти). Помимо горизонтального масштабирования вычислительных мощностей Windows Azure поддерживает масштабирование баз данных за счет технологии Federations, доступной при использовании сервиса SQL Azure. Кроме того существуют решения. позволяющие упростить процесс наращивания ресурсов. У Амазона это Auto Scaling Service, у Windows Azure – Auto-Scaling Application Block.

Дополнительные возможности
Кроме базовых сервисов (аренда вычислительных мощностей и хранилищ данных) обе платформы предоставляют набор дополнительных услуг. Здесь преимущество остается за Windows Azure, так как список таких сервисов значительно шире

AWS

Windows Azure

Amazon DevPay – простой сервис биллинга и управления аккаунтом
Amazon Marketplace Web Service – сервис благодаря которому продавцы имеют возможность повысить эффективность продаж и качество взаимодействия с клиентами
Public Data Sets – централизованный репозиторий открытых данных (включая человеческий геном и статистику посещений портала Wikipedia)

Сервисы Bing
- Bing API
- Bing Maps
Онлайн сервисы
- Exchange Online
- Sharepoint Online
- Lync Online
- Office 365
Windows Live
- Skydrive
- Photogallery
- Messenger

Вычислительные мощности
Обе платформы предоставляют довольно таки широкий спектр размеров виртуальных машин, начиная от микро инстансов и заканчивая чрезвычайно мощными экземплярами. Сравнить предложения от Amazon и Microsoft можно при помощи следующей таблички

	Amazon Web Services	Windows Azure
Micro-инстанс	Micro instance	Extra-Small instance
Стандартные предложения	Small, Large, Extra Large	Small, Medium, Large, Extra Large
Память	От 1,7 Гб до 15 Гб	От 1,7 Гб до 14 Гб
Процессор	От 1 до 4-х ядер	От 1 до 8-ми ядер
Специальные предложения	High-memory, High-CPU, Cluster
Операционные системы	Linux, Windows Server	Windows Server

Хранилища данных
Обе платформы поддерживают популярные на сегодняшний день системы хранения данных, включая как стандартные реляционные так и NoSQL-решения.

	Amazon Web Services	Windows Azure
Blob/Object хранилище	Размер одного объекта в Amazon S3 не может превышать 5 Тб. Нет ограничений на общий объем данных и количество объектов	Размер одного объекта не может превышать 200 Гб (блочный блоб) и 1 Тб (страничный блоб). Размер всех объектов одного аккаунта не может превышать 100 Тб, на количество таких аккаунтов ограничений не существует * Поддерживается гео-репликация данных, что позволяет значительно повысить надежность хранения данных
Табличное хранилище	В Amazon SimpleDB нет ограничения на количество записей. Таблицы организуются в “домены”, размер которых не может превышать 10 Гб. На количество “доменов“ ограничений не существует	В Windows Azure Table Storage не существует ограничений на количество записей. Запись может иметь до 255 полей и не может превышать 1 Мб размере. Размер объектов в одном аккаунте не может превышать 100 Тб. Нет ограничений на количество аккаунтов

Реляционное хранилище
В данной категории у AWS существует довольно таки интересное предложение. Платформа предлагает клиентам 2 варианта запуска реляционного движка в облаке: управляемый и неуправляемый. В случае использования неуправляемого варианта вам предоставляются на выбор готовые образы (так называемые Application Machine Images) с уже предустановленными СУБД (поддерживаются IBM DB2, Oracle, MySQL, SQL Server Express, SQL Server Standart, Postgres, Syba). После выбора конкретного образа с него запускается виртуальная машина и ваша СУБД становится доступной. Так как сами виртуальные машины непостоянны и им требуется внешнее хранилище данных вам еще необходимо будет настроить Amazon EBS сервис для периодического сброса бекапов в хранилище. Второй подход – управляемый. В этом случае используется сервис Amazon Relational Database Service, при котором для вас разворачивается СУБД MySQL либо Oracle и сама платформа уже берет на себя задачи по обновлению, репликации и хранению резервных копий.
Windows Azure предоставляет реляционный сервис SQL Azure. Разработчику нет необходимости инсталлировать и конфигурировать сервера, можно использовать аналогичную модель программирования под SQL Server. Протокол взаимодействия все тот же – TDS. Размер базы данных ограничен 150 Гб. Существует нативная поддержка шардинга базы данных при помощи технологии SQL Azure Federations, что позволяет поднять производительность до нереальных высот. Кроме того поддерживаются ряд вспомогательных и полезных сервисов: SQL Azure Reporting Services, SQL Azure DataSync и др.

Высокопроизводительные вычисления
Как правило для решения сложных научных, инженерных и бизнес задач требуется огромное количество одновременно работающих вычислительных центров, каждый из которых выполняет лишь часть работ но все вместе они решают одну задачу (примером может быть задачи молекулярного моделирования). Как AWS так и Windows Azure поддерживают высокопроизводительные вычисления. Amazon предоставляет специальный вид виртуальной машины, называемый Cluster Machine, что позволяет объединять инстансы в кластера и выполнять тяжелые вычисления. У Microsoft в свою очередь существует Windows Server HPC 2008 R2 позволяющий объединять собственные сервера с облачными виртуальными машинами в любой пропорции для выполнения распределенных вычислений. Кроме того обе платформы поддерживают и значительно упрощают запуск такого популярного на сегодняшний день решения как Hadoop, что позволяет проводить в облачных условиях анализ больших объемов данных.

Разработка решений
Обе платформы поддерживают большинство современных языков программирования, кроме того значительные инвестиции вливаются в разработку различного рода SDK, аддонов и плагинов к популярным средам разработки и т.д.

	Amazon Web Services	Windows Azure
Портал разработчика	Присутствует	Присутствует
Eclipse Tools	Присутствует	Присутствует
Visual Studio Tools	Присутствует	Присутствует
Java SDK	Присутствует	Присутствует
Мобильное SDK	iOS, Android	iOS, Android, WP7
PHP SDK	Присутствует	Присутствует
Python SDK	Присутствует	Отсутствует
Ruby SDK	Присутствует	Присутствует
.NET SDK	Присутствует	Присутствует

Эмуляторы
Большое преимущество здесь остается за Windows Azure так для локальной разработки предоставляется очень полезная и удобная среда (эмулируется как среда выполнения так и хранилище данных), максимально имитирующая облачную, чего нельзя сказать о Amazon Web Services.

Мониторинг состояния сервисов
AWS включает службу Amazon CloudWatch, позволяющую собирать и аггрегировать детальные метрики с EC2-инстансов, балансировщиков нагрузки, баз данных и т.д.
Windows Azure предоставляет специальную диагностическую подсистему, позволяющую мониторить, аггрегировать и хранить логи приложения, IIS логи, счетчики производительности, статистику базы данных и так далее.

Скорость
Наверное одна из наиболее важных составляющих успеха той или иной платформы. Здесь безоговорочная победа Windows Azure. Независимые тесты производительности были проведены компанией Compuware с использованием их собственной утилиты CloudSleuth, дебютировавшей в этом году. Каждый может посмотреть результаты за последний месяц на сайте CloudSleuth https://www.cloudsleuth.net/web/guest/global-provider-view. На этом же сайте можно также посмотреть модель тестирования облачных сервисов. На момент написания данного поста ситуация была следующей:

Суммируя все вышеописанное можно составить итоговую таблицу по всем сервисам обеих платформ.

Категория	Amazon Web Services	Windows Azure
Вычислительные мощности
Вычисления	Amazon Elastic Compute (EC2)	Windows Azure Compute
Высокопроизводительные вычисления	Amazon EC2 HPS Clusters	Windows HPC Server
Обработка данных	Amazon Elastic MapReduce (Hadoop)	Hadoop on Windows Azure Compute
Авто масштабирование	Auto Scaling, Elastic Beanstalk	Scaling Application Block
Распределенное кеширование	Amazon ElasticCache	AppFabric Caching
Контент
CDN	Amazon CloudFront	Windows Azure CDN
База данных
NoSQL	Amazon SimpleDB	Windows Azure Table Storage
Реляционная база	Amazon Relational DB Service	SQL Azure
Репортинг		SQL Azure Reporting
Синхронизация		SQL Azure DataSync
Федерация		SQL Azure Federations
Разворачивание
IaaS разворачивание	Amazon Elastic Compute	VM Role
PaaS разворачивание	Elastic Beanstalk	Web/Worker Roles
Массовый деплоймент	AWS CloudFormation
Маркетплейс
Маркетплейс приложений	Custom App Catalog	Windows Azure Marketplace
Маркетплейс данных		Windows Azure Marketplace
Мониторинг и управление
Мониторинг	Amazon CloudWatch	Диагностическое API
Ручное управление	AWS Management Console	Windows Azure Developer Portal
Коммуникация
Простая очередь	Amazon Simple Queuing Service	Windows Azure Queue Storage
Продвинутая очередь		Windows Azure Service Bus Queues
Нотификация	Simple Notification Service	Windows Azure Service Bus
Почта	Simple Email Service
Сеть
Траффик менеджмент	Amazon Route 53	Windows Azure Traffic Manager
VPN/Гибридное облако	Virtual Private Cloud, Direct Connect	Windows Azure Connect
Балансировка нагрузки	Elastic Load Balancing	Windows Azure Compute
Безопасность
Управление подлинностью		AppFabric Access Control Service
Хранилище
Блоб хранилище	Amazon S3	Windows Azure Blob Storage
Диски	Amazon Elastic Block Storage	Windows Azure Drives
Импорт/экспорт медиа	Amazon Import/Export

Как видим по функциональности платформы сопоставимы, поэтому решение стоит принимать уже основываясь на требованиях проекта и четко понимая разницу между IaaS и PaaS принципами ! Спасибо за внимание, надеюсь публикация будет полезной !

App Fabric Service Bus. Ретрансляция сообщений на примере Echo-сервиса.

2011-12-06T14:57:00.001-08:00

Всем привет ! Мы продолжаем знакомиться с технологией от Microsoft под названием App Fabric Service Bus. Данная публикация является уже второй по счету, посвященной этому механизму. В первой я напомню мы познакомились с определением и основными сценариями применения технологии, а также узнали как создать свой первый неймспейс. Посмотреть ее можно вот по этой ссылке: Введение в AppFabric Service Bus. Сценарии применения.Сегодня пост будет более техническим – попытаемся создать и использовать WCF-сервис посредством Service Bus.
Итак, задача стоит следующая: построить WCF-сервис, содержащий один единственный метод. Метод будет принимать строковый параметр и сразу же возвращать его клиенту. Захостить этот сервис постараемся на сервисной шине. То есть по факту Service Bus будет выступать как ретранслятор сообщений между клиентом и WCF-сервисом.Для решения поставленной задачи был создан новый солюшен со следующими проектами: EchoService.Client, EchoService.Server, EchoService.Source. В студии это выглядит следующим образом:

EchoService.Client представляет собой консольное приложение, через которое пользователь может отправлять сообщения на сервер. EchoService.Server – это наша серверная часть (также консольное приложение), на базе которой будет открываться WCF-хост, запускающий необходимый нам WCF-сервис. Так как и клиенту и серверу необходим контракт WCF-сервиса – мы поместили его в совместно используемую сборку под названием EchoService.Source. В данной сборке находится один единственный интерфейс, код которого представлен ниже.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel;

namespace EchoService.Source
{
    [ServiceContract(Name = "EchoContract", Namespace = "http://samples.microsoft.com/ServiceModel/Relay/")]
    public interface IEchoContract
    {
        [OperationContract] 
        string Echo(string message);
    }
}

Ничего необычного – стандартный интерфейс с одним единственным методом Echo, принимающий и возвращающий строковый параметр. В сборке EchoService.Server находится реализация данного интерфейса – это класс под названием EchoServer – его код также представлен чуть ниже.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using EchoService.Source;
using System.ServiceModel;

namespace EchoService.Server
{
    [ServiceBehavior(Name = "EchoService", Namespace = "http://samples.microsoft.com/ServiceModel/Relay/")]
    public class EchoServer : IEchoContract
    {
        public string Echo(string message)
        {
            Console.WriteLine("Received: {0}", message);
            return message;
        }
    }
}

Здесь также все стандартно – класс реализует интерфейс IEchoService и помечается атрибутом ServiceBehavior (тем самым класс помечается как реализация WCF-сервиса). Метод Echo помимо того, что возвращает пришедшую в параметре строку обратно клиенту, также выводит ее в консоль сервера. Основная же функциональность сервера заключена в файле Program.cs. Давайте посмотрим на его содержимое:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.ServiceBus;
using System.ServiceModel;
using System.ServiceModel.Description;

namespace EchoService.Server
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.Title = "Сервер";
            Console.Write("Введите Service Bus неймспейс: ");
            string serviceNamespaceDomain = Console.ReadLine();
            Console.Write("Issuer Name: ");
            string issuerName = Console.ReadLine();
            Console.Write("Issuer Secret: ");
            string issuerSecret = Console.ReadLine();

            Uri address = ServiceBusEnvironment.CreateServiceUri("sb", serviceNamespaceDomain, "EchoService");

            TransportClientEndpointBehavior sharedSecretServiceBusCredential = new TransportClientEndpointBehavior();
            sharedSecretServiceBusCredential.CredentialType = TransportClientCredentialType.SharedSecret;
            sharedSecretServiceBusCredential.Credentials.SharedSecret.IssuerName = issuerName;
            sharedSecretServiceBusCredential.Credentials.SharedSecret.IssuerSecret = issuerSecret;

            ServiceHost host = new ServiceHost(typeof(EchoServer), address);
            IEndpointBehavior serviceRegistrySettings = new ServiceRegistrySettings(DiscoveryType.Public);
            foreach (ServiceEndpoint endpoint in host.Description.Endpoints)
            {
                endpoint.Behaviors.Add(sharedSecretServiceBusCredential);
            }
            host.Open();
            Console.WriteLine("Адрес сервиса: " + address);
            Console.WriteLine("Нажмите [Enter] для выхода");
            Console.ReadLine();
            host.Close();
        }
    }
}

Давайте более подробно разберемся что же происходит. Итак, во-первых для запуска сервиса необходимы входные данные, а именно криденшалы для доступа к Service Bus и название неймспейса. Они то как раз и собираются в первых строчках программы. После этого создается уникальный всеобще доступный адрес сервиса (на выходе мы получим вот такого формата адрес: sb://<YOUR-NAMESPACE>.servicebus.windows.net/EchoService). Для доступа к Service Bus все клиенты должны быть аутентифицированными. В нашем случае используется так называемая аутентификация SharedSecret и происходит это следующем сегменте кода:

           
            TransportClientEndpointBehavior sharedSecretServiceBusCredential = new TransportClientEndpointBehavior();
            sharedSecretServiceBusCredential.CredentialType = TransportClientCredentialType.SharedSecret;
            sharedSecretServiceBusCredential.Credentials.SharedSecret.IssuerName = issuerName;
            sharedSecretServiceBusCredential.Credentials.SharedSecret.IssuerSecret = issuerSecret;

Данный способ аутентификации похож на стандартные схемы, при которых передается пара логин/пароль (кроме того поддерживаются следующие схемы аутентификации: Saml, SimpleWebToken и Unauthenticated). Ну и в конце концов при помощи стандартного инструментария из сборки System.ServiceModel.dll создается WCF-хост и запускается наш Echo-сервис (конечно же при этом для каждой точки доступа устанавливается созданное ранее поведение, гарантирующее возможность подключения лишь аутентифицированных пользователей).

Давайте теперь взглянем на исходный код клиента.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.ServiceBus;
using System.ServiceModel;
using EchoService.Source;

namespace EchoService.Client
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.Title = "Клиент";
            Console.Write("Введите Service Bus неймспейс: ");
            string serviceNamespaceDomain = Console.ReadLine();
            Console.Write("Issuer Name: ");
            string issuerName = Console.ReadLine();
            Console.Write("Issuer Secret: ");
            string issuerSecret = Console.ReadLine();

            Uri serviceUri = ServiceBusEnvironment.CreateServiceUri("sb", serviceNamespaceDomain, "EchoService");

            TransportClientEndpointBehavior sharedSecretServiceBusCredential = new TransportClientEndpointBehavior();
            sharedSecretServiceBusCredential.CredentialType = TransportClientCredentialType.SharedSecret;
            sharedSecretServiceBusCredential.Credentials.SharedSecret.IssuerName = issuerName;
            sharedSecretServiceBusCredential.Credentials.SharedSecret.IssuerSecret = issuerSecret;

            ChannelFactory<IEchoContract> channelFactory = new ChannelFactory<IEchoContract>("RelayEndpoint", new EndpointAddress(serviceUri));

            channelFactory.Endpoint.Behaviors.Add(sharedSecretServiceBusCredential);
            IEchoContract channel = channelFactory.CreateChannel();
            ((ICommunicationObject)channel).Open();

            Console.WriteLine("Введите текст для отправки на сервер:");
            string input = Console.ReadLine();
            while (!String.IsNullOrEmpty(input))
            {
                try
                {
                    Console.WriteLine("Сервер ответил: {0}", channel.Echo(input));
                }
                catch (Exception e)
                {
                    Console.WriteLine("Ошибка: " + e.Message);
                }
                input = Console.ReadLine();
            }

            ((ICommunicationObject)channel).Close();
            channelFactory.Close();
        }
    }
}

Алгоритм подключения к шине совершенно идентичный оному в серверной части. Различия заключаются лишь в том, что мы не открываем новый хост, а открываем канал при помощи вот этого кода:

            ChannelFactory<IEchoContract> channelFactory = new ChannelFactory<IEchoContract>("RelayEndpoint", new EndpointAddress(serviceUri));
            channelFactory.Endpoint.Behaviors.Add(sharedSecretServiceBusCredential);
            IEchoContract channel = channelFactory.CreateChannel();
            ((ICommunicationObject)channel).Open();

Все, что нам осталось сделать это добавить пару строчек кода в конфигурационные файлы обоих проектов. В серверную часть добавим следующую конфигурацию:

<?xml version="1.0"?>
<configuration>
<startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/></startup>
  <system.serviceModel>
    <services>
      <service name="EchoService.Server.EchoServer">
        <endpoint contract="EchoService.Source.IEchoContract" binding="netTcpRelayBinding"></endpoint>
      </service>
    </services>
  </system.serviceModel>
</configuration>

В клиентскую же отправляется следующий фрагмент:

<?xml version="1.0"?>
<configuration>
<startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/></startup>
  <system.serviceModel>
    <client>
      <endpoint name="RelayEndpoint" contract="EchoService.Source.IEchoContract" binding="netTcpRelayBinding"></endpoint>
    </client>
  </system.serviceModel>
</configuration>

В обоих случаях указывается основная точка доступа к сервису и новый биндинг под названием netTcpRelayBinding (этот вид биндинга находится в сборке Microsoft.ServiceBus.dll и обеспечивает безопасную и надежную коммуникацию между компьютерами посредством Service Bus)

Все готово, осталось сделать лишь один маленький шаг перед запуском системы. А именно узнать на портале криденшалы для доступа (это наши Issuer Name и Issuer Secret, требуемые как клиентом так и сервером). Найти их можно в разделе AppFabric –> Service Bus в свойстве неймспейса под названием Default Key

По клику на кнопочке View откроется модальное окошко, в котором как раз и будут содержаться необходимые нам данные.

На этом все приготовления можно считать завершенными. Для демонстрации я покажу пару скриншотов ,показывающих функционирование системы.

Как видим система работает прекрасно, а для создания сервиса нам не пришлось прикладывать значительных усилий, большинство рутинной работы за нас выполняет новый WCF-биндинг, находящийся в пространстве имен Microsoft.ServiceBus.

На этом пост можно завершать. Исходные файлы проекта можно взять по следующей ссылке: AppFabric Service Bus Echo Service. Очень скоро мы познакомимся с более прогрессивными и изощренными вариантами применения Service Bus, а пока что спасибо за внимание, надеюсь публикация была полезна и интересна :)

Windows Azure Internals

2011-11-20T06:32:00.001-08:00

Привет всем ! 18 ноября прошла очередная встреча профессиональных .NET разработчиков UNETA. Встреча вызвала немалый ажиотаж, так как доклады затрагивали актуальные на сегодняшний день темы: "Обзор возможностей HTML5" и "Внутренняя организация Windows Azure". Я принимал участие во встрече как докладчик и рассказывал об архитектуре Windows Azure. Для тех, кто не смог попасть на встречу выкладываю материалы презентации.