Можно ли использовать вложенную виртуализацию в Azure?
Вложенная виртуализация была введена в Windows Server 2016 Hyper-V. Когда она активирована, расширенные технологии виртуализации в центральном процессоре доступны в виртуальной машине, при этом виртуальные процессоры vCPU позволяют запускать внутри нее Hyper-V. Новые серии виртуальных машин Dv3 и Ev3 будут поддерживать вложенную виртуализацию, которая будет предоставлять новые типы сценариев тестирования, где потребуется вложенная виртуализация. Кроме того, вложенная виртуализация позволяет задействовать контейнеры Hyper-V (с изоляцией в режиме ядра) в Azure, что предполагает хостирование контейнеров.
Могу ли я изменить размер управляемого диска в Azure?
Да, вы можете изменить размер на больший. Остановите работу виртуальной машины, измените размер диска на больший, а затем снова запустите виртуальную машину. Уменьшить размер управляемого Azure диска вы не можете.
Как перейти в Azure на диск меньшего размера?
Стандартное неуправляемое хранилище данных рекомендуется создавать с наибольшим возможным размером, например 1 Тбайт, поскольку оплачиваются только записанные данные. Но при наличии хранилища данных класса премиум и управляемых дисков (стандартных и класса премиум), которые будут основаны на размере диска, а не на количестве записанных данных, ситуация меняется.
В Azure невозможно уменьшить размер диска, поэтому процесс, показанный ниже, является самым лучшим вариантом для перехода на диск меньшего размера:
- Создайте меньший по размеру неуправляемый диск, основываясь на размере целевого диска.
- Смонтируйте диск к виртуальной машине.
- Остановите все службы, которые записывают текущие данные на диск.
- Скопируйте данные с текущего диска данных на новый диск, например: robocopy E:\F:\*.*/j/e/sec/Xd «System Volume Information» «$RECYCLE. BIN»/Xo
- Отмонтируйте больший по размеру диск от виртуальной машины.
- Измените букву драйвера так, чтобы она соответствовала старому диску данных.
- Перезапустите приложение.
Теперь вы можете подключиться к управляемым дискам. Обратите внимание, это работает только для дисков данных. Единственный способ уменьшить размер диска с операционной системой — это загрузить VHD локально, уменьшить размер раздела диска внутри гостевой операционной системы, уменьшить размер VHD, выгрузить обратно в Azure, а затем вновь создать виртуальную машину. Очевидно, что такой процесс приведет к значительному простою в работе.
Как создать виртуальную машину в Azure при помощи PowerShell, чтобы использовать управляемые диски?
При наличии управляемых дисков не происходит никакого взаимодействия с учетными записями хранилища данных. Управляемые диски — это первоклассный ресурс Azure, при использовании которого управление учетными записями хранилища данных осуществляется автоматически в фоновом режиме.
Использовать управляемые диски очень легко, поскольку в большинстве случаев вам не надо задавать учетные записи хранилища данных. Код PowerShell, представленный в листинге 1, создает виртуальную машину, использующую управляемый диск для диска операционной системы и управляемый диск для накопителя данных.
Я использую вторую версию командного интерфейса Azure CLI (v2) в Azure, но мне необходимо аутентифицироваться в «облаке» US Government. Как это сделать?
Для использования «облака» типа Government используйте команду:
az cloud set — name AzureUSGovernment
Затем продолжите аутентификацию как обычно, то есть командой az login.
Надо ли мне использовать chkdsk в виртуальной машине Azure IaaS?
Chkdsk применяется, когда есть повреждения в файловой системе. Теоретически этот инструмент может потребоваться в виртуальной машине, которая развернута в Azure. Если у вас есть какое-либо повреждение в логике, то вам надо запустить chkdsk внутри гостевой операционной системы.
Могу ли я использовать протокол Х в виртуальной сети Azure?
Azure поддерживает ТСР и UDP в виртуальных сетях Azure. Другие протоколы не будут работать до тех пор, пока они не будут упакованы в ТСР и UDP. Например, NAT-T (NAT Traversal) упаковывает IPSec ESP в формат UDP.
Я пытаюсь использовать функцию OpenBaseKey в системе Windows 7, но она не работает. Почему?
Функция OpenBaseKey дает возможность работать с параметром реестра системы. Эта функция была введена в третьей версии PowerShell, поэтому она не работает в Windows 7, где используется вторая версия PowerShell.
Пользователи Windows 7 могут применять функцию OpenRemoteBaseKey. Например, вместо команды
$Registry = [Microsoft.Win32.RegistryKey]:: OpenBaseKey
('CurrentUser', 'Default')
можно вводить команду:
$Registry = [Microsoft.Win32.RegistryKey]:: OpenRemoteBaseKey (‘CurrentUser’,’localhost’)
Затем вы сможете использовать параметр для взаимодействия с реестром. Например:
$key = $registry.OpenSubKey (‘Software\Microsoft\Internet Explorer’) $key.GetSubKeyNames ()
Применяется ли лимит в 500 000 объектов к версии Azure AD Free, если я использую Office 365?
Нет. Обычно экземпляр Azure AD с бесплатными учетными записями пользователей ограничен количеством в 500 000 объектов (не только учетных записей пользователей). Для удаления лимита вам нужны версии Azure AD Basic и выше. Однако если вы используете подписку абонента Azure AD с Office 365, тогда лимит в 500 000 объектов также удаляется, поскольку Office 365 создает массу объектов в Azure AD. Процесс описан в документе по адресу: https://www.microsoft.com/en- us/cloud-platform/azure- active-directory-features.
Какие существуют способы ограничения доступа к экземпляру базы данных Azure SQL?
Экземпляры базы данных Azure SQL имеют собственные сетевые экраны, которые позволяют вам указывать, кто может иметь доступ к точке подключения из общедоступной сети, (обратите внимание, что если у вас есть доступ с другого ресурса Azure, то реальное соединение выполняется по опорной сети Azure). Существует два способа настройки параметров сетевого экрана:
- для адресов IP, через которые производится доступ к службе из общедоступной сети;
- для служб Azure (то есть для любой службы, которая запущена в инфраструктуре Azure у любого абонента).
Например, вы можете не разрешить доступ с какого-либо IP-адреса общего доступа. Тогда вы активируете доступ только для служб Azure.
Если вы хотите более надежной защиты, тогда можете разрешить доступ только из определенной виртуальной сети. Для этого можно применить такой подход: вы развертываете виртуальное устройство на периметре виртуальной сети, а затем маршруты User Defined Routes задаются таким образом, чтобы трафик из общей сети шел именно по ним, и далее, задав на виртуальном устройстве набор IP-адресов общего пользования, вы на сетевом экране SQL указываете IP-адреса общего пользования виртуального устройства. Работы при этом больше, зато обеспечивается безопасное функционирование экземпляра базы данных Azure SQL, поскольку только системы, которые присоединены именно к вашей виртуальной сети, смогут использовать его.
Как взаимодействовать с системой хранения двоичных объектов в Azure, используя команды PowerShell?
Блочное хранилище двоичных объектов Azure обеспечивает удобное хранение медиафайлов и документов. Вы можете выгрузить и загрузить данные, используя интерфейсы REST API, CLI, графические инструменты типа Azure Storage Explorer и PowerShell.
Команды PowerShell, представленные в листинге 2, демонстрируют простой пример создания нового контейнера с последующей выгрузкой образа.
Как можно приобрести Azure Stack?
Azure Stack является локальным устройством, которое можно приобрести как готовое решение у ряда партнеров, таких как Dell, Lenovo и HP. Устройство предоставляет настроенный набор функций для работы с общедоступным «облаком» Azure. Если у вас есть шаблон JSON для развертывания служб на виртуальных машинах Azure, то этот же самый шаблон будет работать и в Azure Stack, и в общедоступном Azure.
Работа с общедоступным «облаком» Azure тарифицируется в зависимости от потребления ресурсов, то же происходит и в Azure Stack. Ресурсы оплачиваются в зависимости от времени использования виртуального процессора или за 1 Гбайт хранилища в месяц. Полную информацию можно найти в документе по адресу: https://azure.microsoft.com/en-us/overview/azure-stack/how-to-buy/. Формирование счетов на оплату производится в результате отправки измеряемых показателей в Azure. Оплата может происходить в рамках стандартного договора на услуги Azure.
Если у вас есть автономная среда, то вы можете реализовать режим автономной работы. В этом случае вы выкупаете набор системных блоков, базируясь на числе физических процессоров в рамках пакетов IaaS или App Service (в зависимости от тех функций Azure, которые вам нужны). Обратите внимание, что когда вы используете модель с числом блоков, вам надо предоставить собственные лицензии Windows Server и SQL Server; вариант «оплата по факту потребления» может включать при желании модель почасовой оплаты за лицензию или можно использовать собственную (AHUB не требуется, поскольку это локальные системы). Подробно все это описано в документе по адресу: https://go.microsoft.com/fwlink/? LinkId=851536&clcid=0x409.
Кроме того, нужно учитывать и цену самого оборудования, которая назначается поставщиком аппаратного обеспечения.
Использование Azure Stack оплачивается за час или поминутно?
Поминутная оплата такая же, как в общедоступном «облаке» Azure. Правила ценообразования предусматривают почасовую оплату (https://azure.microsoft.com/en-us/overview/azure-stack/how-to-buy/), однако это в общем случае, а реальная оплата сводится к поминутной. Об этом говорится в документе о лицензировании клиента: https://go.microsoft.com/fwlink/? LinkId=851536&clcid=0x409.
Зачем использовать Azure Stack вместо общедоступного Azure?
Azure Stack можно приобрести у поставщиков аппаратного обеспечения, поскольку это интегрированное решение, которое предоставляет настроенные службы Azure в локальном варианте. Но некоторые потребители интересуются, в чем разница между использованием общедоступного «облака» Azure и локальным решением Azure Stack. Я советую рассматривать общедоступный Azure как место, где размещаются «облачные» службы, а Azure Stack использовать в ситуациях, выпадающих из правил, таких как:
- Автономная работа. Возьмем нефтяную вышку с узкой полосой пропускания и большой задержкой, подводную лодку, круизный лайнер. Там нет никакого соединения с внешним миром или связь ограничена. То же самое и с Azure, и такое положение вещей делает запуск служб из общедоступного Azure невыполнимой задачей, поэтому использование Azure Stack позволяет запускать такие же службы Azure, но локально.
- Соответствие обязательным требованиям. Общедоступное «облако» Azure соответствует ряду обязательных требований, которые описаны в документе по адресу: https://www.microsoft.com/en-us/trustcenter/compliance/complianceofferings. Однако есть страны, где у Azure нет центров данных, зато существуют правила, согласно которым данные не могут выходить за пределы страны. В этих случаях использование Azure Stack позволит задействовать службы Azure, только локально.
- Необходимость запускать «облачное» приложение как можно ближе к пользователям. Зачастую решения с выделенным подключением, такие как службы ExpressRoute, могут запускаться в «облаке» при наличии быстрых соединений с локальными пользователями. Однако, если есть особенные приложения, которые должны быть как можно ближе к пользователям, можно задействовать Azure Stack для того, чтобы разрешить «облачному» приложению запускаться локально, без необходимости внесения в него изменений.
Если я покупаю комплект Azure Stack, буду ли я иметь доступ к базовым виртуальным машинам, которые будут запускать Azure Stack?
Нет. Представьте себе Azure Stack как закрытое оборудование, черный ящик. Единственный вариант доступа для потребителей — это портал абонентов и команды PowerShell для доступа к интерфейсу Azure REST. Не существует функции RDP или команд PowerShell для получения доступа к базовым виртуальным машинам, которые определяют функционирование Azure Stack. Есть конфиденциальная точка входа, ее будет использовать в случае возникновения проблем с оборудованием техническая поддержка Microsoft, которой требуется доступ на нижнем уровне, но такой вариант недоступен конечным пользователям. Смысл оборудования как раз и состоит в том, что вы не беспокоитесь об операционной системе, программном обеспечении, настройках оборудования. Всем этим управляют за вас, а вы можете сосредоточить внимание на использовании его возможностей. Это также означает, что вы не можете устанавливать на оборудование собственных агентов.
Как определить срок предстоящего технического обслуживания моей виртуальной машины в Azure IaaS?
Изнутри виртуальной машины Azure IaaS откройте ссылку http://169.254.169.254/metadata/scheduledevents? api-version=2017-03-01, по которой загрузится файл JSON, где будет обозначен срок предстоящего технического обслуживания. Отследить его вы также можете, используя следующую служебную утилиту:
curl -H Metadata: true http://169.254.169.254/metadata/ scheduledevents? api-version=2017-03-01
Процесс использования описан в руководстве: https://azure.microsoft.com/en-us/blog/get-started-with-scheduled-events/? v=17.23 h.
Могу ли я объединять в одноранговые виртуальные сети с подписками в разных экземплярах службы каталогов Azure AD?
Нет. Можно объединять в одноранговые виртуальные сети в разных подписках, но они должны использовать один и тот же экземпляр службы каталогов Azure AD. Если виртуальные сети используют другие экземпляры службы каталогов Azure AD, то на сегодня вы не можете объединять виртуальные сети в одноранговые. Вместо этого вам следует использовать соединение VPN типа «сеть-сеть» или ExpressRoute.
У меня есть зарезервированный публичный IP-адрес в регионе Azure. Можно ли переместить его в другой регион?
Нет. Публичные IP-адреса индивидуальны для региона и их нельзя перемещать из одного региона в другой. Точно так же вы не можете вводить собственные публичные IP-адреса в Azure. Вам потребуется свой публичный IP-адрес для каждого региона. А для регулирования работы экземпляра службы для данного региона используйте диспетчер трафика Azure Traffic Manager.
Как сделать так, чтобы конкретный виртуальный адаптер vmNIC в виртуальной машине Azure использовал Azure DNS?
Обычно настройка службы DNS виртуальных машин выполняется в виртуальной сети, и это может быть:
- Azure DNS;
- пользовательская служба DNS (такая, как служба DNS локальной сети или любые другие серверы DNS, заданные набором IP-адресов).
Можно также обойти настройки DNS на уровне виртуального адаптера vmNIC и задать другой набор IP-адресов. Однако как сделать так, чтобы он использовал Azure DNS? Просто настройте его на 168.63.129.16. Это тот же самый IP-адрес, который вы указываете для ваших служб DNS в Azure для того, чтобы переадресовать запросы к Azure DNS, согласно документу, опубликованному по адресу: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances.
Если я развертываю собственные службы DNS в Azure, существует ли способ переадресовать рекурсивные запросы к Azure DNS для разрешения?
Обычно сервер DNS является полномочным для конкретных доменов, то есть для тех, которые он поддерживает. Для любых других запросов DNS он делает рекурсивный запрос для того, чтобы разрешить требуемое имя в IP-адрес. Другой вариант — настроить переадресацию любого запроса к зоне, которую он не уполномочен обслуживать, другому набору серверов DNS, которые выполняют рекурсивный просмотр и могут иметь больший кэш разрешений.
Если вы хотите переадресовать запросы к Azure DNS, укажите сервер пересылки для вашего сервера DNS как 168.63.129.16, согласно документу, опубликованному по адресу: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances. Это действие активирует привязку имен хостов, предоставляемых Azure.
Я настроил свою виртуальную машину Azure на применение Azure DNS на уровне NIC, используя IP-адрес, но разрешение записи имени хост-системы завершается неудачей. Этого не происходит при настройке на уровне виртуальной сети на выполняемое Azure разрешение имен. Почему?
На уровне виртуальной сети в Azure вы можете выполнить настройку на службу разрешения имени IDNS, обеспечиваемую Azure, либо можете указать пользовательский список IP-адресов. Эта настройка применяется к виртуальным машинам в виртуальной сети через DHCP. Кроме того, настройки DNS могут быть указаны на уровне vmNIC, что позволяет задать список IP-адресов, которые считаются службой DNS пользователя, даже если вы зададите адрес 168.63.129.16, по которому направляются запросы к IDNS (это важно).
Динамическая служба DNS представляет собой технологию, которая позволяет экземплярам операционной системы регистрировать записи имени хост-системы (А) для того, чтобы сопоставить их имя хоста с их IP-адресом, или при использовании службы DHCP сервер DHCP может зарегистрировать запись от имени клиента, что требуется для операционных систем типа Linix. В случае с Azure инфраструктура Azure всегда регистрирует запись хоста во внутренней службе DNS для экземпляров операционной системы (даже если применяется пользовательская служба DNS). Записи создаются во внутренней зоне в формате < VNet encoded ID>..internal.cloudapp.net. Инфраструктура Azure получает имя хост-системы операционной системы как часть запроса обнаружения DHCP, отсылаемого клиентом во время запуска системы.
Когда настройка для vmNIC DNS осуществляется из виртуальной сети и настраивается на использование IDNS (заданные по умолчанию службы Azure DNS), клиенту отсылается IP-адрес внутренних DNS-служб, 168.63.129.16 и заданный по умолчанию суффикс DNS внутренней зоны, например kwagipstuffqxwwc.bx.internal.cloudapp.net. Эта часть важна, поскольку она разрешает операционной системе клиента впоследствии запрашивать DNS, так как она имеет правильный суффикс для зоны, где регистрируются записи. Когда клиент ищет webapp1, операционная система добавляет заданный по умолчанию суффикс и запрашивает DNS так, что ищется на самом деле webapp1.kwagipstuffqxwwc.bx.internal.cloudapp.net. Это означает, что разрешение имени работает для записей внутри виртуальной сети.
Когда настройка для vmNIC DNS выполняется на уровне vmNIC, она считается пользовательской службой DNS, даже когда она настроена на значение 168.63.129.16 (IDNS). Таким образом, клиенту отсылается IP сервера DNS, но не отсылается суффикс DNS внутренней зоны. Поскольку инфраструктура Azure регистрирует упомянутую выше запись хоста в виртуальные сети, соединенные с внутренней зоной, гостевая операционная система не знает, что это за зона, следовательно, когда она запрашивает DNS, результата не будет, так как она не запрашивает по правильному имени FQDN (имя хост-системы плюс суффикс DNS). Вот почему вы видите разницу в поведении.
Решение состоит в том, чтобы настроить гостевую операционную систему с заданным по умолчанию суффиксом виртуальной сети. Этот суффикс вы можете найти, открыв сайт https://resources.azure.com и перейдя к разделу сетевого адаптера NIC, соединенного с виртуальной сетью, которая запущена. Там вы увидите имя суффикса internalDomainNameSuffix (см. экран). Запишите это значение.
.jpg) |
| Экран. Внутренний суффикс домена |
Теперь вам надо либо вручную указать суффикс DNS внутри гостевой операционной системы, либо настроить его как часть развертывания виртуальной машины с помощью пользовательских расширений. Пример такого подхода можно найти в документе по адресу: https://github.com/Azure/azure-quickstart-templates/tree/master/custom-private-dns. Обратите внимание, этот пример создает всю среду. Ключевая часть — это вложенная папка, которая собирает все значения суффикса. Например, команда для выполнения на Lunix будет такой (согласно https://github.com/Azure/azure-quickstart-templates/blob/master/custom-private-dns/nested/linux-client/setuplinuxclient.sh):
sudo echo «supersede domain-name\"kwagipstuffqxwwc.bx.internal.cloudapp.net\"; >>/etc/dhcp/dhclient.confsudo dhclient -v
Команды для Windows приведены в статье по адресу: https://github.com/Azure/azure-quickstart-templates/blob/master/custom-private-dns/nested/windows-client/setupwinclient.ps1.
После выполнения всех перечисленных действий локальная виртуальная машина получит правильный суффикс и сможет разрешить записи.
$vmname = "TestVM" $IPAddr = "10.1.1.11" Write-Output "Creating VM $vmname ($IPAddr)" $user = "localadmin" $password = 'Pa55word!' $securePassword = ConvertTo-SecureString $password -AsPlainText -Force $cred = New-Object System.Management.Automation. PSCredential ($user, $securePassword) $rgname = "Dal-Infra-RG" $availSet = Get-AzureRmAvailabilitySet -Name "Dal-Infra-DC-AS" ` -ResourceGroupName $rgname $loc = "EastUS" $networkname = "Prod-Dal-VNet" $subnetname = "$networkname-Sub1" $vnetRG = "Dal-VNets-RG" $VNet = Get-AzureRmVirtualNetwork -Name $networkname -ResourceGroupName $vnetRG $subnet = get-azurermvirtualnetworksubnetconfig -VirtualNetwork $vnet -Name $subnetname $subnetID = $subnet.Id # Create VM Object $vm = New-AzureRmVMConfig -VMName $vmname -VMSize $vmsize -AvailabilitySetId $availSet.Id $nic = New-AzureRmNetworkInterface -Force -Name (‘nic-’ + $vmname) -ResourceGroupName $rgname ` -Location $loc -SubnetId $subnetID -PrivateIpAddress $IPAddr # Add NIC to VM $vm = Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id $vm = Set-AzureRmVMSourceImage -VM $vm -PublisherName MicrosoftWindowsServer -Offer WindowsServer -Skus 2016-Datacenter -Version latest $vm = Set-AzureRmVMOSDisk -VM $vm -StorageAccountType StandardLRS -DiskSizeInGB 128 ` -CreateOption FromImage -Caching ReadWrite -Name "$vmname-OS" $vm = Set-AzureRmVMOperatingSystem -VM $vm -Windows -ComputerName $vmname ` -Credential $cred -ProvisionVMAgent -EnableAutoUpdate #Add data disk $diskConfig = New-AzureRmDiskConfig -AccountType PremiumLRS -Location $loc -CreateOption Empty ` -DiskSizeGB 128 $dataDisk1 = New-AzureRmDisk -DiskName "$vmname-data1" -Disk $diskConfig -ResourceGroupName $rgName $vm = Add-AzureRmVMDataDisk -VM $vm -Name "$vmname-data1" -CreateOption Attach -ManagedDiskId $dataDisk1.Id -Lun 1 #Create Virtual Machine New-AzureRmVM -ResourceGroupName $rgname -Location $loc -VM $vm
$StrContext = New-AzureStorageContext -ConnectionString "" #Двоичный объект $StrContainer = 'images' #Создание нового контейнера New-AzureStorageContainer -Context $StrContext -Name $StrContainer #Загрузка всех данных из папки в контейнер Get-ChildItem -Path C:\Users\josavi\OneDrive\Documents\ TestPictures\* | Set-AzureStorageBlobContent -Context $StrContext -Container $StrContainer #Просмотр Get-AzureStorageBlob -Context $StrContext -Container $StrContainer #Выгрузка с помощью Get-AzureStorageBlob ... Get-AzureStorageBlobContent -Destination -Context $StrContext #Удаление содержимого Get-AzureStorageBlob -Context $StrContext -Container $StrContainer | Remove-AzureStorageBlob -Context $StrContext #Удаление контейнера Remove-AzureStorageContainer -Context $StrContext -Name $StrContainer