Зачем вообще в облаке может потребоваться высокодоступное файловое хранилище?

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

Архитектура многих существующих приложений такова, что для работы с данными используются сетевые папки или общие хранилища (настроенные RAID, SAN или что-то аналогичное), работающие по протоколу SMB. Есть несолько вариантов миграции таких приложения в Microsoft Azure :

1. Внесение в архитектуру приложений изменения, т.е. напрямую работать с Azure BLOB Storage через REST или SDK, например. Такой подход имеет ряд преимуществ, например, нет затрат на оплату времени работы виртуальных машин, т.е. итоговая стоимость эксплуатации решения будет ниже. Кроме того, запросы на работу с файлами могут идти напрямую в Storage, используя полосу пропускания Storage’а, а не через прокси (при наличии большого количества запросов еще придется масштабировать эту прокси-машину, тогда как в Storage это осуществляется автоматически на уровне самой службы), которым выступает виртуальная машина в случае обсулживания работы с файлами.

2. Но иногда изменения сложно осуществить, если это сторонний компонент или если задача является слишком трудозатратой (особенно на первой стадии миграции в облако). Поэтому возникается необходимость миграции приложения as-is, т.е. без внесения каких-либо изменений в код. В этом случае может быть использована отдельная виртуальной машина (IaaS), на которой настроена  файловая служба (File Services), которая обеспечит работу приложения по SBM протоколу.

Виртуальные машины в Azure и организация файлового хранилища

При выборе второго подхода следует учитывать:

1. Во-первых, ограничение в 16ТБ. К виртуальной машине могут быть подключены от 1 до 16 дисков данных (Data Disk) в зависимости от выбранного шаблона виртуальной машины. Каждый диск данных может иметь объем до 1ТБ, и диски не могут разделяться (быть примонтированным) между виртуальными машинами.

2. Во-вторых, доступность это виртуальной машины, на которой будут хранится файлы. На данный момент SLA на доступность (99,95%) предоставляется для 2х и более виртуальных машин, объединенных в Availability Set. Т.е. если что-то произойдет с физическим оборудованием, или хостом Hyper-V, на котором запущена виртуальная машина, или потребуется перезагрузка виртуальной машины для применения обновлений, то виртуальная машина будет какое-то время недоступна, а значит и файлы. Если запущены две вириальные машины, включенные в Availability Set, то они гарантировано разнесены по разным стойкам и обновления к ним не будут применяться одновременно, т.е. хотя бы одна из машин всегда (99,95%) должна обслуживать поступающие запросы. 

Поэтому возникает вопрос: каким образом в Azure может быть построено распределенное по нескольким машинам файловое хранилище?

Ответ простой - распределенное файловое хранилище можно создать с помощью службы Distributed File System (DFS) в Windows Server. Такой подход позволит обойти вышеописанные ограничения (доступность, максимальный объем хранилища и синхронизацию файлов между дисками данных виртуальных машин). Кроме того, DFS полностью поддерживается для разворачивания в Azure, т.к. входит в состав службы File Services (подробнее о поддерживаемых продуктах в статье Microsoft server software support for Windows Azure virtual machines).

DFS состоит из двух основных технологий:

• DFS Namespace, которая позволяет сгруппировать общие папки на различных файловых серверах в единое пространство имен. Это позволяет клиенту получить доступ к распределенных данных с использованием общего названия\пути и не завязываться на фактическое расположения данных

• DFS Replication, которая позволяет синхронизировать данные в общих папках между всем серверами. Для этого используется эффективный механизм репликации - Remote Differential Compression.

Объединение этих технологий позволит нам реализовать распределенное и высокодоступное файловое хранилище в Azure. Необходимо принимать во внимание, что в случае отказа одного из узлов DFS клиент может заметить небольшую задержку в доступе к данным. Это связано даже не с архитектурой DFS, а с тем, что SBM какое-то время пытается связаться с тем же сервером (что оправдано в случае временного сбоя в работе сети), а не переключается сразу на другой (работающий) сервер. Проведенные тесты в оригинальной статье показали задержку переключения максимально в 90 секунд, а среднее - 60 секунд.

Архитектура решения

На рисунке ниже показана общая архитектура решения:

• DFS инфраструктура развернута в выделенной виртуальной сети в Azure (VNET).

• Приложения или любые другие клиенты, которые будут обращаться к DFS, также должны быть включены в данную сеть.

• На машинах настроена служба DFS и настроены DFS Replication и DFS Namespace. Эти машины включены в Avaliability Set, что соответствует требования SLA в Azure и обеспечивает доступность машин 99,95% времени.

• Для DFS требуется Active Directory. В данном примере для простоты DFS и служба управления доменами (Domain Services) будут установлены на одних и тех же виртуальных машинах. Т.к. DC на машинах, которые уже включены в Avaliability Set, то для них также гарантируется SLA.

• Кроме того, на двух машинах с DC запущена служба DNS, которая настроена как DNS для всей VNET.

• Создана DFS папка, которая будет связана с общей папкой на каждом сервере. Каждая такая папка будет находится на отдельном диске данных (Data Disk) для каждого сервера.

• Клиентские машины, получающие доступ к DSF файлам, могут быть как подключенными к созданному ранее домену, так и не подключенными, а также быть как IaaS, так и PaaS.

Пошаговая настройка DFS

Регистрация DNS сервера

Нам необходимо настроить DNS сервер для того, чтобы резолвить имена машин внутри нашей VNET. Контроллер домена, на котором запущена служба DNS, будет располагаться в отдельной подсети, это позволит нам точно знать его IP адрес. Согласно документации, первый IP-адрес в подсети будет xxx.xxx.xxx.4, второй - xxx.xxx.xxx.5 и так далее. Т.к. в подсети у нас будет только одна виртуальная машина (DC), то ее адрес можно заранее определить.

Обратите внимание, что это не гарантированное поведение и может измениться в будущем. Есть еще возможность зарезервировать внутренний IP адрес за машиной в виртуальной сети с помощью PowerShell – подробнее здесь.

1. Зайдите на портал управления Azure, выберите Network Services – Virtual Network – Register DNS Server:

   • Name: dns01

   • DNS Server IP Address: 10.1.1.4

2. Выберите снова Network Services –> Virtual Network –> Register DNS Server и заполните значения для второго DNS сервера:

   • Name: dns02

   • DNS Server IP Address: 10.1.1.5

   

Создание виртуальной сети

1. Выберите пункт New – Network Services – Virtual Network – Custom Create:

   • Name: dfsvnet

   • Affinity Group: Create a new Affinity Group (данная Affinity Group будет использована для всех ресурсов Azure данной системы)

   • Region: -выберите регион-

   • Affinity Group Name: dfsag

   

2. Теперь выберите DNS сервера (dns01 и dns02), которые создали ранее. При необходимости можно создать VPN тунель с локальной (Configure site-to-site VPN). Кстати, его можно создать и позже.

   

3. Далее заполните значения для сети:

   • Address Space: 10.0.0.0/8

   • Subnet 1:

   • Name: dfs

   • Starting IP/CIDR: 10.1.1.0/29

   • Subnet 2:

   • Name: main

   • Starting IP/CIDR: 10.2.1.0/16

   

4. Виртуальная сеть начнет создаваться.

Создание аккаунта хранилища

1. Создайте новый аккаунт хранилища (обратите внимание, что используете та же Affinity Group, что и для виртуальной сети):

• Name: hadfsstorage

• Affinity Group: dfsag

Создание первой виртуальной машины - dfs01

На данной виртуальной машине будет развернут домен контроллер, DNS, DFS Namespace и DFS Replication на основе Windows Server 2012 R2.

1. Выберите Select New – Compute – Virtual Machine – From Gallery:

   • Platform Image: Windows Server 2012 R2 Datacenter

   • Virtual Machine Name: dfs01

   • Size: Medium

   • New User Name: dfs

   • New Password/Confirm: _DFS0n@zure#

   

2. Теперь сконфигурируем саму виртуальную машину:

   • Cloud Service: Create a new cloud service

   • Cloud Service DNS Name: dfsdemo.cloudapp.net

   • Virtual Network: dfsvnet

   • Subnet: dfs (10.1.1.0/29)

   • Storage Account: hadfsstorage

   • Availability Set: -сreate an availability set-

   • Availability Set Name: dfsavset

   

3. Оставьте значение порта RDP и PowerShell по умолчанию. Машина начнет создаваться, это может занять около 5 минут.

4. Убедитесь, что машине присвоен IP адрес 10.1.1.4.

Присоединение Data Disk'ов к виртуальной машине dfs01

Далее необходимо к виртуальной машине присоединить Data Disk'и, на которых будут хранится файлы база Active Directory и общие папки DFS:

1. На портале управления Azure откройте страницу управления виртуальной машины dfs01.

2. Выберите пункт внизу страницы Attach – Attach empty disk.

3. Укажите размер диска 5ГБ.

4. Зайдите на виртуальную машину по RDP.

5. Откройте Disk Management и инициализируйте создание нового диска.

6. Присвойте тому букву F: и выполните быстрое форматирование.

Промотирование виртуальной машины dfs01 в домен контроллер

Процесс настройки виртуальной машины как контроллера подробно описан здесь, поэтому пройдем только по основным шагам:

1. Присоединитесь к машине dfs01 по RDP.

2. Установите Active Directory Domain Services через Server Manager (Add Roles and Features) .

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

   • Deployment operation: Add a new forest

   • Root Domain Name: dfsdemo.com

   • DSRM Password: _DFS0n@zure#

   • Location of AD DS database: F:\NTDS

   • Log files: F:\NTDS

   • SYSVOL: F:\SYSVOL

4. После настройки машина перезаргузится и сможет теперь выполнять функции контроллера домена.

Создание второй виртуальной машины

Теперь создадим вторую виртуальную машину, котор так же будет содержать домен контролле, DNS сервер, DFS Namespace и DFS Replication и обеспечиваться отказоустойчивость этих служб (в том числе за счет настройки Availability Set).

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

Availability Set: dfsavset

Обратите внимание, что очень важно развернуть виртуальную машину в DFS подсети (subnet) и в том же Availability Set!

Присоединение Data Disk'ов к виртуальной машине dfs02

Присоедините пустой Data Disk к машине dfs02.

Промотирование виртуальной машины dfs02 в домен контроллер и присоединение к домену dfsdemo.com

Теперь приоединим машину к домену dfsdemo и назначим ее резервным домен контроллером.

1. Присоединитесь к машине dfs02 по RDP.

2. Установите Active Directory Domain Services через Server Manager (Add Roles and Features).

3. Выполните промоушен сервера до домен кнтроллера (оставьте все значения по умолчанию и проигнорируйте предупрждения)

   • Deployment operation: Add a domain controller to an existing domain

   • Domain: dfsdemo.com

   • Credentials: dfsdemo\dfs

   • Site name: Default-First-Site-Name

   • DSRM Password: _DFS0n@zure#

   • Replicate from: dfs01.dfsdemo.com

   • Location of

     • AD DS database: F:\NTDS

     • Log files: F:\NTDS

     • SYSVOL: F:\SYSVOL

4. После настройки машина перезаргузится и сможет теперь выполнять функции контроллера домена.

Проверка установки

Убедитесь, что машины созданы, запущены (Running) и имеют корректный IP адрес.

Кроме того, можете убедиться, что оба сервера указаны как домен контроллер в панели Active Directory Users and Computers.

Установка и настройка DFS на dfs01

1. Присоединитесь к dfs01 по RDP.

2. Откройте Add Roles and Features Wizard и выберите DFS Namespaces и DFS Replication в пункте File and Storage Services.

   

3. Создайте пользователя в Active Directory:

   • User logon name: dfsuser

   • Password: _DFS0n@zure#

4. Создайте общую директорию, которая называется Shared, на диске F:\. Предоставьте аккаунту dfsuser  доступ на чтение\запись.

   

5. Если планируете предоставлять доступ к DFS для машин, не включенных в домен, то необходимо настроить DFS на использования FQDN (fully qualified domain names). Если же клиенты будут находится в том же домене, то достаточно обращения по NetBIOS имени. Эти параметры выставляются на уровне DFS сервера и только через PowerShell:

   Set-DfsnServerConfiguration –ComputerName “dfs01″ –UseFqdn $true
   Stop-Service dfs; Start-Service dfs

Установка и настройка DFS на dfs02

Установка аналогично шагам для dfs02. Если ранее натсроили DFS на использование FQDN, то повторите тоже и для dfs02:

Set-DfsnServerConfiguration –ComputerName “dfs02″ –UseFqdn $true
Stop-Service dfs; Start-Service dfs

Настройка DFS на dfs01

1. Откройте DFS Management панель.

2. Из пункта Action выберите New Namespace.

   • Namespace Server: dfs01

   • Namespace Name: dfsns

   • Namespace Type: Domain-based namespace

3. Выберите созданный namespace dfsdemo.com\dfsns.

4. Из пункта Action выберите Add Namespace Server.

   • Namespace Server: dfs02
     

5. Выберите dfsdemo.com\dfsns.

6. Из пункта Action выберите New Folder.

   • Name: dfsshare

   • Add Folder Target: \\dfs01.dfsdemo.com\Shared

   • Add Folder Target: \\dfs02.dfsdemo.com\Shared
     

7. На вопрос о создании группы репликации (replication group) ответьте Yes и примите все значения по умолчанию.

   • Replication Group Name: dfsdemo.com\dfsns\dfsshare

   • Replicated Folder Name: dfsshare

   • Replication Eligibility:
     

   • Primary Member: dfs01

   • Topology: Full Mesh

   • Replication Group Schedule and Bandwidth: Replicate continuously, Full Bandwidth

8. После того как группа репликации будет создана, появится предупреждение. По умолчанию интервал репликации в Active Directory составляет 3 часа, поэтому синхронизация может занять какое-то время.
   

Проверка настройки DFS

1. Зайдите по RPD на dfs01.

2. Откройте панель DFS Management.

3. Выберите папку dfsshare.

4. Убедитесь, что две папки указывают на dfsshare и пути указаны верно.
   

5. Выберите вкладку Replication.

6. Убедитесь, что там указано две сущности Replicated Folders. И проверьте статус репликации (Replication Status).
   

7. Выберите группу репликации dfsdemo.com\dfsns\dfsshare.

8. Убедитесь, что указаны два папки во вкладке Membership.
   

9. Выберите вкладку Connections.

10. Убедитесь, что настроено два участника репликации.
    

11. Выберите вкладку Replicated Folders.

12. Убедитесь, что dfsshare папку указан как реплицируемая, а статус имеет значение Published to Namespace.
    

13. Если все настроено верно, то можно сказать, что у нас получилось распределенное отказоустойчивое файловое хранилище!

Проверка DFS репликации

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

1. Зайдите по RDP на dfs01.

2. Создайте файл FromDFS01.txt в папке F:\Shared.
   

3. Зайдите по RDP на dfs02.

4. Проверьте наличие файла FromDFS01.txt в папке F:\Shared (репликация должна произойти примерно в течение минуты)

5. На сервере dfs01 кликните правой кнопкой мыши dfsdemo.com\dfsns\dfsshare группу и выберите Create Diagnostic Report - DFS Replication Health Report.

6. Создайте файл FromDFS02.txt в папке F:\Shared на dfs02.
   

7. Проверьте рпликацию этого файла в папку F:\Shared на dfs01 сервер.

Создание клиентской машины

Итак, протестируем доступность и работоспособность созданного DFS из сторонней системы. Для этого создадим клиентскую машину, она будет вне домена dfsdemo.com, хотя поддерживаются и присоединенные к домену машины (помните про настройку FQDN?). Если система сочетаем в себе как PaaS, так и IaaS, компоненты, то чаще всего как раз PaaS-компоненты не являются частью домена (хотя, например, Cloud Services также можно добавлять в созданную виртуальную сеть и домен). Именно поэтому протестируем на “недоменном” сценарии. Но в любом случае, создаваемая виртуальная машина должна находится в той же виртуальной сети (в нашем случае dfsvnet), что и DFS (на момент написания данной статьи, к сожалению, добавить Web Sites в виртуальную сеть было нельзя, но все может измениться в будущем, поэтому проверяйте!).

1. Выбирете New – Compute – Virtual Machine – From Gallery

   • Platform Image: Windows Server 2012 Datacenter
   • Virtual Machine Name: dfsclient
   • Size: Small
   • New User Name: dfs
   • New Password/Confirm: _DFS0n@zure#
   

2. Выполните конфигурацию виртуальной машины:

   • Cloud Service: Create a new cloud service
   • Cloud Service DNS Name: dfsclient.cloudapp.net
   • Virtual Network: dfsvnet
   • Subnet main (10.2.1.0/16)
   • Storage Account: hadfsstorage
   • Availability Set: (None)

3. Оставьте значения портов по умолчанию для RDP и PowerShell.

 

Проверка доступности общих папок в DFS

Теперь проверим доступность общих папок DFS с клинтской машины - dfsclient. Для того, чтобы увидеть все в динамике, для проверки используем PowerShell-скрип, который в цикле обращается к DFS:

1. Подключитесь по RDP к dfsclient.

2. Откройте Windows PowerShell ISE.

3. Создайте PowerShell скрипт, который будет в цикле опрашивать DFS каждую секунду, и сохраните его как CheckShare.ps1.
   

   while($true)
   {
   Get-ChildItem -path \\dfsdemo.com\dfsns\dfsshare
   (Get-Date).DateTime
   sleep -Seconds 1
   }

4. Запустите скрипт.
   

5. Вы можете создать новый файл на DFS с данной клиентской машины и проверить корректиность репликации на dfs01 and dfs02.

6. Теперь самое интересное! Сэмулируем недостпность одной ноды DFS (dfs01). Для этого зайдите на портал управления Azure, выберите машину dfs01 и нажмите Shutdown.

   • Теперь сервер dfs02 должен начать обслуживать все входящие запросы к файлам.
   • Это должно быть хорошо видно из вывода запущенного PowerShell скрипта, который опращивает DFS.
   • Будет заметно, что на какое-то время отклика не будет, но потом ответы возобновятся.
   

7. Снова запустите машину dfs01 через портал управления Azure и дождитесь пока машину будет в статусе Running.

8. Теперь через портал управления выключите машину dfs02. Поведение DFS должно быть аналогично описанному выше при отключении первой машины.

Выводы и стоимость

Вот и все. В итоге настроена распределенное высокодоступное файловое хранилище в Azure, которое может быть использовано как только для IaaS инфраструктуры, так и для гибридной IaaS + PaaS. При необходимости в DFS могут быть добавлены новые ноды и namespace’ы, к виртуальным машинам могут быть добавлены дополнительные диски для масштабирования и распределения нагрузки.

Что касается цены такого решения, то она будет заивисеть от нагрузки (запущенных виртуальных машин, объема хранимых данных и т.п.). Например, две Extra-Small (A0) виртуальные машины обойдутся примерно в $28\месяц, а 1ТБ данных в $68\месяц.

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

Как активировать аккаунт Windows Azure?

Для активации аккаунта Windows Azure необходимы Microsoft Account (LiveID), банковская карта (не виртуальная) и номер мобильного телефона (на него поступит смс с кодом активации). Подробнее процесс на примере активации аккаунта и триальной подписки описан здесь.

После успешной активации создается аккаунт Windows Azure, который привязывается к Вашему Microsoft Account (LiveID), и первая подписка.

Предоставляется ли доступ к Windows Azure в рамках программы BizSpark?

Да, предоставляется. Если Вы участник программы BizSpark, то Вам доступно специальное предложение – ежемесячные кредиты на бесплатное использование ресурсов Windows Azure (до 150 USD\месяц). Доступ к Windows Azure предоставляется на все время действия программы BizSpark. Дополнительные подробности в статье.

Кроме того, в рамках программы BizSpark для одной компании может быть зарегистрировано до 8 участников (один администратор и семь дополнительных участников). Каждый участник BizSpark может активировать для себя собственную подписку Windows Azure, в рамках которой бесплатно предоставляется ежемесячный кредит в размере 150 USD на бесплатное использование ресурсов Windows Azure.

Предоставляется ли доступ к Windows Azure в рамках подписки MSDN?

Да, предоставляется. Подробности доступны по ссылке. Доступ к Windows Azure предоставляется на все время действия MSDN подписки.

Какое количество подписок можно создать на один аккаунт Windows Azure?

Вы можете создать любое количество подписок Windows Azure в рамках одного аккаунта (аккаунт привязывается к Вашему Microsoft Account (LiveID)). На портале управление Windows Azure Вы будете видеть все созданные подписки.

В каком случае заведение отдельной подписки может быть удобно? Например, если Вы разворачиваете разные сервисы и желаете получать отдельные счета и информацию по потребляемым ресурсам. Либо одна подписка может быть для целей тестирования, а вторая для боевой системы. Разделение по такому принципу достаточно популярно. Кроме того, разные подписки могут использовать разные методы оплаты.

Следует учитывать, что не рекомендуется (и не всегда это возможно технически) в рамках одной системы или сервиса использовать ресурсы из нескольких подписок.

При активации с моей банковской карты был списан 1 USD? Разве триал\активация не бесплатные?

Данная процедура применяется исключительно для верификации карты, а сумма (1 USD или 30 рублей) не списывается, а блокируется на Вашем счете на какое-то время (время варьируется в зависимости от банка, типа карты и т.п.).  Не волнуйтесь, данная сумма будет возвращена на счет.

Что делать, если моя банковская карта не принимается?

Иногда возникает ошибка в процессе активации аккаунта Windows Azure.

Во-первых, если была заблокирована сумма в 1 USD или 30 рублей, то эти средства позже будут возвращены на счет (если Вы сделал несколько попыток, то может быть несколько блокировок, но для всех будет разблокировка).

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

В-третьих, попробуйте использовать другую именную банковскую карту (не виртуальную).

В-четвертых, попробуйте валидировать способ оплаты через https://commerce.microsoft.com (подробнее в статье Windows Azure: что делать, если карта не проходит?).

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

Можно ли использовать виртуальные карты?

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

Что произойдет при превышении лимитов подписки или моя подписка заблокирована – помогите?

По умолчанию для триальной подписки, MSDN подписки или BizSpark подписки предоставляется возможность бесплатного использования ресурсов Windows Azure на определенную сумму, кроме того, установлена предельная сумма расходов (0 USD или 0 рублей).

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

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

Можно ли включить предельную сумму расходов повторно?

Да, предельную сумму расходов можно установить для MSDN\BizSpark подписки в любой момент. Подробнее в статье Billing: Reset your Spending Limit on MSDN subscriptions.

Каковы ограничения триальной подписки?

Триальная подписка предоставляется в целях ознакомления с платформой и не может быть использована для боевых система. В рамках подписки предоставляется возможность использовать в течение месяца любые службы Windows Azure в переделах 200 USD. Если требуется больше ресурсов, то Вы можете отключить предельную сумму расходов и оплачивать только дельту (превышении) по ресурсам.

По окончании срока действия триальной подписки все данные и сервисы будут приостановлены и удалены. Поэтому рекомендуем либо переводить подписку в Pay as You Go, либо позаботиться о сохранении данных заранее.

Если Вы приняли решение о продолжении использования Windows Azure, т.е. готовы в коммерческому использованию платформы, то конвертируйте триальную подписку (например, по окончании срока ее действия или ранее при необходимости) в платную подписку, например, в Pay as You Go.

Где посмотреть текущее использование ресурсов и счет?

Посмотреть текущее использование ресурсов и счет к оплате Вы можете в разделе Account -> Subscriptions -> [Подписка].

Какие существуют варианты оплаты?

Оплата может осуществляться по банковской карте или через выставленный счет (invoice). Кроме того, есть возможность оплаты по программе Enterprise Agreement.

По умолчанию для MSDN, BizSpark, Trial или Pay as You Go подписок метод оплаты - это банковская карта. Метод оплаты можно поменять, обратившсь в поддержку, – тип запрос Billing, подтип – Change payment type. Если Вы активировали для своей подписки оплаты по счету (invoice), то обратно перейти на оплату по банковской карте возможности нет.

Выставленный счет можно будет оплатить, например, любым банковским переводом (в выставленном счете будут все необходимые данные расчетного счета).

Как можно мигрировать систему\службу\данные с одной подписки на другую?

Наиболее простой способ миграции – это завести обращение в поддержку (обращение будет бесплатным). Тип обращения Billing, подтип - Migration Assistance. При этом потребуется сообщить Subscription ID подписок и удостовериться, что у подписок указан один и тот же администратор. Подробнее здесь.

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

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

Все лабораторные с TechEd доступны по ссылке.

Введение

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

В этой лабораторной работе вы увидите, как можно развернуть простое веб-приложение ASP.NET MVC 4 на веб-сервер, расположенный в Windows Azure, с использованием SQL Server и балансировщика нагрузки, а также познакомитесь с командлетами PowerShell, которые можно использовать для целей автоматизации этих процессов.

Цели

После этой лабораторной работы вы научитесь:

· Создавать веб-ферму, используя портал управления Windows Azure

· Настраивать балансировщик нагрузки в IIS

· Разворачивать простое MVC-4 приложение, использующее SQL Server

· Создавать виртуальную машину с SQL Server и возможностью полнотекстового поиска

Предварительная настройка

Автор: Дмитрий Плотников (SharePoint MVP)

Все лабораторные с TechEd доступны по ссылке.

В Windows Azure есть возможность работы с виртуальными машинами (Infrastructure as a Service или IaaS). Для специалистов и компаний, работающих с SharePoint это означает возможность быстрого развертывания ферм без затрат на оборудование. В рамках лабораторной работы вы узнаете как создать многосерверную ферму SharePoint 2013 и как можно сэкономить ресурсы, если ферма не нужна вам в режиме 24x7 (в случае, если ферма используется для разработки).

Замечание: согласно статье на TechNet Поддержка и лицензирование Windows Azure в SharePoint 2013 SharePoint 2013 поддерживается в Windows Azure. Не поддерживается лишь использование FAST Search Server 2010 для продуктов SharePoint.

Упражнение 1: Создаем контроллер домена

Необходимые условия