В. Как использовать доступ на основе ролей в Azure?

О. Новый портал Azure (portal.azure.com) предусматривает управление доступом на основе ролей (RBAC), что дает больше гибкости, чем доступ от имени администратора или просто отсутствие доступа, что возможно на старом портале, где вы либо являетесь администратором, либо не имеете никакого доступа. На сегодня доступны три роли (хотя в будущем их станет больше).

  • Владелец: полный доступ к ресурсам и системе управления.
  • Участник: все как у владельца, но без доступа к возможностям управления.
  • Читатель: просмотр ресурсов, за исключением конфиденциальных данных ресурсов.

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

Чтобы настроить уровни доступа RBAC, перейдите к подписке, ресурсной группе или ресурсу внутри нового портала Azure, выбрав Browse в левой части экрана (см. экран 1). Затем вверху выберите Everything, будут показаны все типы, включая подписки. Выберите объект (Subscriptions («Подписки»), Resource groups («Ресурсные группы») или Resource («Ресурс»), затем в области Access («Доступ») укажите роль, которую хотите предоставить пользователям или группам. Щелкните Add («Добавить»), чтобы добавить пользователей (см. экран 2). Замечу, что это работает только на новом портале; старый портал не позволяет производить настройку RBAC.

 

Настройка уровней доступа
Экран 1. Настройка уровней доступа

 

Назначение ролей
Экран 2. Назначение ролей

Кроме того, вы можете использовать команду New-AzureRoleAssignment среды PowerShell для назначения RBAC. Например:

New-AzureRoleAssignment -Mail kev@savilltech.net -RoleDefinitionName Contributor -ResourceGroupName JohnGroup

Можно удалить пользователей и группы, выбрав роль, пользователя или группу, а затем щелкнув Remove («Удалить»). В качестве альтернативы можно задействовать команду Remove-AzureRoleAssignment.

Чтобы получить более детальную информацию о RBAC, обратитесь к руководству по Microsoft Azure под названием Role-based access control in Azure Preview portal (azure.microsoft.com/en-us/documentation/articles/role-based-access-control-configure/).

В. Когда я перемещаю виртуальную машину в Azure, может ли она сохранить свой IP-адрес?

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

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

Единственным возможным решением мог бы быть вариант, при котором Azure поддерживает сетевую виртуализацию между локальной сетью и Azure. Это позволит отделить сети от базовой сетевой структуры. Однако Azure уже использует сетевую виртуализацию для управления IP, что означает добавление поддержки взаимодействия Azure и локальной сети. В дальнейшем это будет способствовать перекидыванию «мостиков» между разными виртуальными сетями. А это, в свою очередь, требует более тесной интеграции управления и планов администрирования сетевой виртуализации, а также, конечно, и интеграции с System Center Virtual Machine Manager.

В. Как мне выполнить перенос всего хранилища в другое место?

О. Недавно мне потребовалось переместить все свое виртуальное хранилище из одного места в другое на определенном хосте Hyper-V. Приведу код PowerShell, который обеспечивает самый простой способ выполнения этой задачи:

$VMstoMove = Get-VM | Get-VMHardDiskDrive | where {$_.Path.StartsWith(«C:\ClusterStorage\VMs»)}
foreach ($VM in $VMstoMove)
{
write-host $VM.VMName
$vmobj = get-vm -Name $VM.VMName
$newpath = «C:\ClusterStorage\StorageSpace_VMs\» + $VM.VMName
Move-VMStorage -DestinationStoragePath $newpath -VM $vmobj
}

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

В. У меня два хост-адаптера на сервере Hyper-V. Мне создавать одну или две виртуальные SAN?

О. Если у вашего сервера Hyper-V два канала к SAN через отдельные хост-адаптеры (HBA), тогда у вас есть выбор:

  • создать одну виртуальную сеть SAN и присоединить к ней оба HBA;
  • создать две виртуальных сети SAN, к каждой из которых по отдельности будет подсоединен HBA.

В обоих случаях вы создаете два адаптера Fibre Channel для виртуальной машины, а затем либо подсоединяете их к одной SAN, либо каждый к своей SAN. Затем вы используете функцию Multipath I/O внутри виртуальной машины, чтобы повысить устойчивость подсоединения к SAN.

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

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

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF