В прошлый раз мы рассмотрели методы Zero Downtime Upgrade, которые могут быть применены в рамках PaaS варианта развертывания приложения Microsoft Azure. Сегодня мы сосредоточимся на способах, которые можно применить не только к облачным сервисам, а обычным виртуальным машинам в рамках IaaS развертывания.

Load Balanced Endpoint

Как мы знаем любая виртуальная машина, которая обсуживает запросы к вашему приложению делает это через определенный открытый порт (к примеру 80, 8080, 443 и т.д.). Если виртуальных машин несколько, то внутренний балансировщик нагрузки Microsoft Azure распределяет трафик между этими виртуальными машинами. Давайте подумаем, как можно использовать эту возможность для Zero Downtime Upgrade.

Жизненный цикл любого приложения подразумевает его поддержку. Это могут быть какие-либо патчи, хот-фиксы, новые версии и т.д. В случае с desktop приложением все достаточно понятно и привычно. Однако давайте разберемся, как происходит механизм обновления вашего приложения, если оно размещено в облаке. В нашем случае мы будем разговаривать об облаке Microsoft Azure.

Итак, Microsoft Azure предоставляет достаточно широкие средства для автоматического обновления вашего приложения, причем как правило приложением в данный момент пользуются другие люди, поэтому важнейшим вопросом становится обновление «на лету», то есть незаметно для пользователя. Давайте рассмотрим все возможные способы, которые возможно применить для приложения Microsoft Azure.

Добрый день всем жителям Хабра! Напомню, что в прошлый раз я описал работу с облачными мультимедиа сервисами: Windows Azure Media Services и Amazon Elastic Transcoder. Естественно механизм работы с помощью SDK, описанный мной, не единственный. Конечно есть еще возможность работы через REST API, UI или CLI, но объять все в одной статье невозможно. Поэтому я надеюсь начало «инвестигейшена» этих сервисов положено. Мне же осталось только привести сравнение этих сервисов между собой. Поехали!

Возможности

Следует заметить, что как я уже отмечал в описании Amazon Elastic Transcoder, несмотря на релиз SDK для этого сервиса, в нем есть несколько ошибок, которые необходимо будет обойти при работе с ним. Кроме этого в отличие от Windows Azure Media Services облачный сервис от Amazon находится в beta режиме. Соответственно никто не гарантирует его стабильную работу.



Тем не менее, давайте попробуем составить таблицу возможностей облачных мультимедиа сервисов.



Рассмотрим возможности каждого из сервисов подробнее.

Приветствую всех читателей Хабра! Надеюсь все уже отошли от новогодних праздников и готовы приступать к продуктивной работе в новому году. Мне остается лишь пожелать успехов в этом деле.

Напомню, что в прошлом году я поставил задачу сравнить сервисы для обработки видео облачных провайдеров от Microsoft и Amazon. Что ж сегодня пришло время описать работу с Amazon Elastic Transcoder. Итак, поехали!

Несмотря на то, что с версией 2.0, SDK для работы с сервисами Amazon на платформе .NET, перешел в General Availability состояние, в нем все же есть несколько досадных багов. О них я расскажу, когда мы столкнемся с реализацией соответствующего функционала. Чтобы обойти их нам понадобится сделать несколько операций через UI или утилиты командной строки. Но обо всем по порядку.

Amazon Web Services

Итак, первое, что нам необходимо сделать прежде чем использовать Amazon Elastic Transcoder, это создать аккаунт хранилища. В нем будут храниться загруженные для конвертации файлы. По аналогии с Windows Azure, где файлы хранятся в блобах, в Amazon файлы хранятся в корзинах (bucket). Нам необходимо создать одну.
Для того чтобы создать корзину заходим в Amazon Management Console и переходим в раздел Services -> Storage & Content Delivery -> S3.

Добрый день всем, кто нашел в себе силы для того, чтобы заглянуть на Хабр в последнюю рабочую неделю этого года! На этот раз я хотел бы поделиться с вами опытом использования сервисов для работы с мультимедиа контентом, предоставляемого облачными провайдерами. Чтобы процесс был более интересным мы рассмотрим два облачных провайдера: Windows Azure Media Services и Amazon Elastic Transcoder. После этого конечно же не забудем их сравнить! Итак, поехали!

Я приветствую всех жителей Хабрахабра! Всем удачной новой рабочей недели! Итак, мы продолжаем процесс миграции базы данных на использование SQL Azure Federations. Как вы помните, в прошлый раз мы решили, по какой таблице и по какому полю мы будем разбивать базу данных на шарды. Давайте же наконец это сделаем!

Миграция

Итак, будем разбивать базы данных по таблице аккаунтов (Account), поскольку данные, хранящиеся в ней и связанные с ней логически друг с другом не пересекаются. Поскольку у нас есть скрипт создания базы данных, попробуем адаптировать его для использования SQL Azure Federations.

Будем считать, что база данных уже создана в Windows Azure Management Portal либо через SQL Server Management Studio.

В прошлый раз мы рассмотрели теоретическую часть SQL Azure Federations. О чем стоит подумать и что следует учитывать при миграции на использование SQL Azure Federations. Замечу, что суть даже не в самой технологии. Если стоит задача масштабирования базы данных, неважно с использованием Federations, MySQL Cluster или другого способа, первое о чем стоит задумать — об архитектуре базы данных. База данных, которую необходимо масштабировать в первую очередь должна быть архитектурно ориентирована на это.

Итак, вернемся к нашему проекту. Предметная область базы данных — учет личных финансов. Диаграмма базы данных приведена на рисунке.



Как мы видим база данных достаточно простая. Каждый объект системы представляет собой сущность с базовыми свойствами (Id, Name, Description). Конкретными сущностями являются Аккаунт (наследуемые от него: Банковский счет, Кредитная карточка), Категория трат (наследуемые от нее: Бюджет, а также дочерние категории) и Операции по счетам.

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

Исходный текст SQL скрипта по созданию базы данных, может быть найден здесь.



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

Шардинг

Вопрос масштабирования приложений в облаке возникает очень часто. Сама концепция облачных технологий подразумевает масштабирование приложений по запросу. Любой уважающий себя облачный провайдер поддерживает соответствующие функции.

Зачем вообще нужно горизонтальное масштабирование? Когда возникает вопрос повышения производительности приложения, то есть несколько вариантов. Как известно можно купить новое «железо» для сервера, добавить количество оперативной памяти и т. д. Этот принцип называется вертикальным масштабированием. Однако этот способ может быть достаточно дорогим, долгим, да и имеет предел. Можно конечно купить топовое железо, однако оно может не потянуть все требования вашего приложения.

Второй способ, называемый горизонтальным масштабированием, предполагает расширение вычислительных ресурсов доступных приложению за счет увеличения количества серверов или инстансов приложения, в случае PaaS, на которых размещено ваше приложение. То есть если раньше ваше приложение было расположено на одном сервере, и в какой-то момент оно перестало «вытягивать» нагрузку, можно просто купить второй точно такой же сервер. Поставить на него ваше приложение и таким образом часть запросов к приложению будет идти на первый сервер, часть — на второй.

Этот принцип и положен в горизонтальное масштабирование приложений размещенных в «облаке», только вместо реальных физических серверов и у нас есть понятие виртуальная машина. Когда экземпляра одной виртуальной машины недостаточно вашему приложению — вы можете увеличить его, таким образом распределив нагрузку между несколькими виртуальными машинами.

Если рассматривать возможности облачной платформы от Microsoft, то они достаточно широкие. Есть auto-scaling, scaling по запросу, причем все это доступно как с помощью UI, так и с помощью SDK, REST API и PowerShell.

Однако если с масштабированием приложения (PaaS) или виртуальных машин (IaaS) все достаточно просто, указываете сколько инстансов вам необходимо, столько и будет, то в случае если ваше приложение использует базы данных MS SQL, возникает несколько вопросов. Конечно первое что приходит в голову — организовать кластер из виртуальных машин SQL Server. Решение достаточно простое и хорошо всем знакомое. А что делать, если приложение использует базу данных как сервис (SaaS)? Что если мы не хотим заниматьсянастройкой кластера SQL Server?

Конечно же, если мы говорим о Windows Azure, то в качестве SQL базы данных будет использоваться SQL Azure. Эта база данных поддерживает технологию горизонтального масштабирования (шардинг) называемую SQL Azure Federations. Принцип ее работы очень простой: логически независимые друг от друга строки одной таблицы хранятся в разных базах данных. Самый простой пример:



Это одна и та же таблица, данные которой хранятся в разных экземплярах базы данных (шардах). То есть данные аккаунта с идентификатором 1 хранятся в первой базе данных, с идентификатором 2 — во второй и т. д.

Всем привет! Продолжаем настраивать Windows Azure Recovery Services. В прошлый раз мы остановились на том, что загрузили необходимые сертификаты для работы с сервисом. Давайте же теперь наконец настроим Windows Azure Backup Agent для выполнения процесса бэкапирования.

Регистрация нового сервера

Теперь, когда хранилище бэкапов создано, мы создали и импортировали нужные сертификаты на Windows Azure Management Portal и на машины под управлением Windows Server, все что нам осталось – это установить на этих машинах Windows Azure Backup Agent и соответствующим образом его настроить.

Откройте Windows Azure Management Portal и перейдите в раздел Recovery Services. После этого выберите созданное хранилище бэкапов и перейдите на вкладку “Dashboard”.

Всем доброго времени суток! В прошлый раз мы рассмотрели затраты на хранение бэкапов данных с помощью Windows Azure Recovery Services, а также попытались сравнить его с затратами при использовании Windows Azure Storage Services.

Давайте теперь рассмотрим конкретный процесс настройки Windows Azure Recovery Services для хранения бэкапов.

Активация Windows Azure Recovery Services

Поскольку на момент написания статьи данный сервис находился в состоянии «Preview», прежде чем начать с ним работу, его необходимо активировать для вашей подписки Windows Azure. Чтобы это сделать в Windows Azure Management Portal нажимаем кнопку “New”, затем переходим в раздел “Data Services”, “Recovery Services” и, наведя мышку на пункт “Backup Vault”, мы увидим сообщение о том, что прежде чем использовать данную возможность – ее необходимо активировать. Для этого перейдите по ссылке “preview program”.



В списке сервисов, которые в данный момент находятся в “Preview” состоянии, нас интересует пункт “Backup”. Для того, чтобы активировать его нажмите кнопку “Try it now” и в появившемся окне, выберите подписку для которой следует активировать новый сервис.

Довольно часто при работе с облачной платформой Windows Azure многим заказчикам необходим сервис, для бэкапирования данных, хранящихся в облаке либо размещенных на локальных серверах. В случае если мы рассматриваем базу данных SQL Azure, все просто – SQL Azure Data Sync. А как быть, если, к примеру, подобный функционал необходим для виртуальных машин? Для данных, не являющихся реляционными или не хранящихся в реляционной БД?

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

Смысл этого сервиса очень простой. На машину, данные которой следует хранить в облаке и работающую под управлением Windows Server, ставится специальная программа (Windows Azure Backup Agent), которая по расписанию, а также вручную синхронизирует выбранные данные. Поддерживается бэкапирование целых разделов, а также отдельных папок и файлов.

Итак, предыдущая часть была посвящена настройке сервиса SQL Reporting в Windows Azure. Мы рассмотрели два варианта настройки сервисов публикации отчетов: как сервис (SQL Reporting) и с использованием виртуальной машины SQL Server (SSRS). Теперь давайте разберем способ настройки сервисов SQL Reporting и SQL Server для поддержки сценариев multi-tenant, когда один сервис отчетов может использоваться для разных источников данных.

Публикация проекта

1. Откройте проект отчетов в “SQL Server Business Intelligent Development Studio”;
2. В контекстном меню проекта выберите пункт “Properties”;
3. Мы будет разделять отчеты одного заказчика от другого, используя разные корневые каталоги. Для этого в значения полей с префиксом “Target…Folder” укажите корневой каталог с именем заказчика;
   
   
4. Опубликуйте проект отчетов для разных заказчиков в SQL Reporting service и/или виртуальную машину SQL Server.

В прошлый раз мы сравнивали цены при использовании сервисов отчетов, которые доступны как сервис в Windows Azure (SQL Reporting), с вариантом развертывания обычной виртуальной машины с SQL Server (SSRS).
Опять же, я не берусь утверждать, что один сервис лучше или хуже. В большинстве случаев решение о том, какой из сервисов использовать в приложении, необходимо принимать согласно тем задачам, которые стоят перед приложением, и финансовыми требованиями заказчика. Я лишь хочу показать, что для построения решения с использованием сервисов отчетов есть два пути.

Варианты использования

Предположим, что наше приложение работает в Windows Azure и реализовано как Cloud Service (PaaS). Оно использует в качестве источника данных базу данных SQL Azure. Необходимо сконфигурировать сервисы построения отчетов для использования в приложении. Как уже было рассмотрено ранее, сервисы построения отчетов для приложения Windows Azure могут быть построены двумя способами:

1. PaaS: SQL Azure + SQL Reporting;
   SQL Azure будет использован как сервис;
   SQL Reporting будет использован как сервис.
   
2. Гибридное решение: SQL Azure + SQL Server Reporting Services;
   SQL Azure будет использован как сервис;
   SQL Reporting Services должны быть настроены на отдельной виртуальной машине SQL Server (IaaS).
   

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

Платформа Windows Azure становится все более и более популярной в сфере облачных вычислений. Все больше и больше заказчиков хотят перенести свои существующие решения в облако. Очень часто одной из частей приложения, которую необходимо перенести в облако являются сервисы построения отчетов SQL Reporting Services (SSRS). В качестве аналога для платформы Windows Azure выступают SQL Reporting. SQL Reporting – это сервис платформы Windows Azure для построения отчетов в SQL Azure, эквивалентный обычным SQL Server Reporting Services для SQL Server. На первый взгляд оба сервиса предоставляют одинаковые возможности построения отчетов, при том, что SQL Reporting гораздо дешевле обычного SSRS. Давайте проверим так ли это.

Сравнение цен

Оба решения могут быть использованы для построения multi-tenant сценариев, когда одним сервисом пользуется несколько заказчиков, оба решения могут быть использованы в связке с базой данных как обычного SQL Server, так и SQL Azure.
В качестве примера рассмотрим несколько абстрактных заказчиков, веб-сервисы которых размещаются в облаке Windows Azure и обслуживают некоторое количество клиентов.
Давайте посмотрим на таблицу цен обоих решений.


* — SQL Reporting предоставляет возможность генерации 30 отчетов за час вычислений по цене $0,16.
** — Используется цена SQL Server Standard Edition