Виртуальные машины в Windows Azure: Data Disk, виртуальные сети и Availability Set

Приветствую, Хабровчане!
Один из сервисов, которые предоставляет Windows Azure, — это виртуальная инфраструктура и виртуальные машины. В статье я хотела бы рассказать о трех простых вещах, которые могут пригодиться в начале пути знакомства с платформой. Все эти вещи не являются секретными и описаны в документации, но кто же ее читает :)

Хранение данных на OS Disk, Data Disk или temp-диск или что же выбрать?

В виртуальным машинах в Windows Azure есть несколько типов дисков: OS Disk, Data Disk и временные диски. Все очень подробно написано здесь ^[1].

Когда виртуальная машина создается, то для нее автоматически создается OS Disk, на котором установлена ОС (Windows, Ubuntu, CentOS и т.п.). Если зайти по RDP в виртуальную машину, то можно увидеть следующую картину: C: — это и есть OS Disk, D: — это временный диск (Temporary Storage)! Что значит временный диск? Если машина перезагрузится или будет перенесена на другой сервер (например, если что-то не так с текущим сервером), то данные на временно диске не сохранятся, т.к. временный диск – это физический диск сервера, на котором поднята ваша виртуальная машина. Временный диск предназначен для временного хранения файлов.

Поэтому для длительного хранения файлов необходимо подключать и использовать Data Disk. Если подключить Data Disk (и инициализировать его), то выглядеть это будет так, как на рисунке ниже. F: диск – это подключенный Data Disk, т.е. данные на нем переживут все-все-все и являются persistent. Для «не Windows-машин», т.е. Linux, ситуация аналогичная.

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

Что из этого следует:

1. Храните все, что должно быть в сохранности, на подключенных Data Disk'ах.
2. На OS Disk храните ОС и другие установки, но не данные, т.к. хотя OS Disk тоже сохраняет все изменения, но OS Disk – оптимизирован для быстрой загрузки, а Data Disk для random IO.
3. Данные, которые не страшно потерять, можно хранить на temp-диске, что позволит повысить скорость доступа к ним. Например, если включить для Data Disk режим кэширования, то как раз кэш будет хранится в памяти и на temp-диске. Или же temp-диск рекомендуется использовать для tempdb базы SQL Server.

Виртуальные сети

Виртуальная сеть позволяет объединить виртуальные машины в изолированную сеть (о как, кто бы мог подумать). И что же это дает? Это дает возможность виртуальным машинам общаться напрямую между собой по внутреннему ip, т.е. не гонять трафик через Load Balancer в Windows Azure.
Так же через виртуальные сети рекомендуется настраивать взаимодействие между IaaS и PaaS, это позволит трафик пускать напрямую, а не через VIP, а так же не открывать на виртуальных машинах «лишних» портов наружу.

Кстати, замечу, что ip адреса для всех виртуальным машин (т.е. внутренние ip — internal ip), включенных в виртуальную сеть, раздаются динамически (из того пула адресов, который был указан при создании виртуальной сети). Поэтому не следует заходить в виртуальную машину и прописывать статический адрес (это приведет к сетевой ошибке, и трафик, в том числе RDP, к вашей машине не дойдет).

Что из этого следует:

1. Все виртуальные машины и сервисы, которые являются частью одной системы, включаем в виртуальную сеть (Virtual Network).
2. Используем динамические ip адреса, не прописываем самостоятельно ip адреса в настройках сетевого адаптера.

Ктстати, вот хабростатья на тему публичных ip адресов Время жизни статических IP-адресов в Windows Azure ^[2].

Availability Set и отказоустойчивость

Для того чтобы гарантировать или повысить отказоустойчивость вашей системы, развернутой на виртуальных машинах, необходимо поднять несколько виртуальных машин и включить их в балансировку (если требуется) и Availability Set.

С балансировкой все понятно, ее включить очень просто — Load Balancing Virtual Machines ^[3]. Балансировка осуществляется по round-robin схеме. С Availability Set тоже все не сложно. Availability Set просто говорит Windows Azure, что виртуальные машины, включенные в этот сет, должны располагаться на различных физических серверах (т.е. если что-то случится, то вероятность выхода из строя одновременно двух и более виртуальных машин сильно уменьшается) и апдейт для них (их root OS) должен выполняться по очереди (Manage the Availability of Virtual Machines ^[4]), т.е. фактически виртуальные машины будут разнесены по разным стойкам.

Что из этого следует:

1. Если делаем отказоустойчивое решение (ферма, кластер), то добавляем машины в балансировку и обязательно в Availability Set.

Надеюсь, что кому-то эти простые советы будут полезны.

Автор: inatale

Источник ^[5]