Блог

Нужно ли иметь отдельные каналы ExpressRoute, если в определенных случаях мне требуется специально выделенная полоса пропускания?

Несколько виртуальных сетей могут быть подсоеди­нены к одному каналу ExpressRoute. Все соединения делят полосу пропускания с накладываемыми служ­бой Quality of Service ограничениями (для управления использованием трафика), кроме трафика для Skype. Если у вас есть рабочий процесс, который должен иметь определенную полосу пропускания, то существует два варианта:

• Использовать виртуальное устройство Network Virtual Appliance для обеспечения нужных значений QoS или размера трафика.
• Задействовать отдельные каналы ExpressRoute, чтобы отделить трафик важного приложения от всех остальных.

В чем разница между ключом, защищенным программным образом, и ключом, защищенным аппаратным модулем HSM, в хранилище ключей Azure Key Vault?

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

При разработке и тестировании желательно выбирать вариант зашиты программным обеспечением, а вот при реальной эксплуатации рекомендуется защищенный HSM ключ. Единственный недостаток применения защищенного HSM ключа — это дополнительная плата каждый месяц, если ключ в этом месяце исполь­зовался.

Я создал образ из виртуальной машины с помощью управляемых дисков, но теперь виртуальная машина, которая использовалась в качестве исходной, не запускается. Почему?

Когда вы создаете образ из виртуальной машины, исходная машина, как правило, является единым целым, как бы подготовленной SYSPREP. и даже если вы не запускали SYSPREP, виртуальная машина про­должает считаться единым целым. А это означает, что она не будет работать. Вы не можете изменить вариант одного исходного образа. Вместо этого вам нужно удалить виртуальную машину, которая была исхо­дной, и создать новую, используя существующий диск. В листинге показаны команды PowerShell, кото­рые заново создают виртуальную машину, используя управляемый диск и местоположения в группе доступ­ности.

SrgName = "RGSavillEastRG"
Slocation = 'East US"
SvmName = "SavTechESTNP2"
ScomputerName = "SavTechESTNP2”
SvnetName = "EastERVnet"
Svnetsub = "InfraStaticInfra"
Svmsize = Standard_A2'
Sassetname = ASSAVNPS’
SosDiskName = "SavTechESTNP2_SavTechESTNP2"
Sdisk = get-azurermdisk -ResourceGroupName SrgName -DiskName SosDiskName Svnet = Get-AzureRmVirtualNetwork -Name SvnetName -ResourceGroupName SrgName Ssubnetld = (Get-AzureRmVirtualNetworkSubnetConfig -VirtualNetwork Svnet -Name Svnetsub).Id
Snic = New-AzureRmNetworklnterface -Force -Name ('nic' + SvmName) -ResourceGroupName Srgname ‘
-Location Slocation -Subnetld Ssubnetld -PrivatelpAddress 10.242.63.32 -DnsServer 10.242.63.11,10.242.63.12
SavSet = Get-AzureRmAvailabilitySet -ResourceGroupName SrgName -Name Sassetname
$vm = New-AzureRmVMConfig -VMName SvmName -VMSize Svmsize -AvailabilitySetld SavSet.Id $vm = Add-AzureRmVMNetworklnterface -VM Svm -Id Snic.ld
$vm = Set-AzureRmVMOSDisk -VM $vm -Name SosDiskName -ManagedDiskld Sdisk.ld -CreateOption Attach -Windows New-AzureRmVM -ResourceGroupName SrgName -Location Slocation -VM $vm 

Поддержка виртуальных машин Azure, обращайтесь office@itfb.com.ua

Я использую Azure Files Sync и замечаю, что файлы не разбиваются по уровням сразу. Почему это происходит?

Файлы не разбиваются по уровням автоматически. Может пройти несколько часов, пока не выполнится мгновенная копия, а потом появится реальное разбие­ние по уровням.

Могу ли я принудительно выполнить разбиение по уровням для данных в Azure Files Sync?

Да. Используя следующую команду PowerShell, вы можете принудительно выполнить разбиение по уров­ням:

SrgName = RGEastUSMinecraft SavSetName = ASEASTUSWEBSRV
SavSet = Get-AzureRmAvailabilitySet -ResourceGroupName SrgName -Name SavSetName
Update-AzureRmAvailabilitySet -AvailabilitySet SavSet -Sku Aligned
foreach($vmlnfo in SavSet.VirtualMachinesReferences)
{
$vm = Get-AzureRmVM -ResourceGroupName SrgName I Where- Object |$_.ld -eq Svmlnfo.idl Write-Output Svm.Name
Stop-AzureRmVM -ResourceGroupName SrgName -Name Svm.Name -Force
ConvertTo-AzureRmVMManagedDisk -ResourceGroupName SrgName -VMName Svm.Name
Import-Module "C:\Program Files\Azure\ StorageSyncAgent\StorageSync. Management.
ServerCmdlets.dll"
Invoke-StorageSyncCloudTiering -Path ctiered path>

Azure Files Sync перемешает файлы между вашим локальным файловым сервером и службой Azure Files. Когда файл делится на уровни, фильтр файловой системы Azure Files Sync локально заменяет файл на указатель. Так, все содержимое файла, которое вы использовали последним, можно сохранить в «обла­ко» (в Azure Files), и у вас появится больше дискового пространства в локальной среде. Однако если к файлу выполняется доступ, указатель обеспечивает авто­матическую загрузку файла из Azure Files конечному пользователю незаметным образом (иначе была бы задержка из-за загрузки).

Поддержка сервисов Azure, обращайтесь office@itfb.com.ua

Блочное хранилище двоичных объектов Azure обеспечивает удобное хранение медиафайлов и документов. Вы можете выгрузить и загрузить данные, используя интерфейсы REST API, CLI, графические инструменты типа Azure Storage Explorer и PowerShell.

Команды PowerShell, представленные в листинге 2, демонстрируют простой пример создания нового контейнера с последующей выгрузкой образа.

Создание контейнера и выгрузка образа в хранилище двоичных объектов

$StrContext = New-AzureStorageContext -Connectionstring "<connection string>"
#Двоичный объект SStrContainer = 'images'
#Создание нового контейнера
New-AzureStorageContainer -Context SStrContext -Name $StrContainer #3агрузка всех данных из папки в контейнер Get-Childltem -Path C:\Users\josavi\OneDrive\Documents\
TestPicturesV I Set-AzureStorageBlobContent-Context $StrContext -Container $StrContainer #Просмотр
Get-AzureStorageBlob -Context SStrContext -Container $StrContainer #Выгрузка с помощью Get-AzureStorageBlob ... Get-AzureStorageBlobContent -Destination <!ocal> -Context $StrContext
#Удаление содержимого
Get-AzureStorageBlob -Context $StrContext -Container $StrContainer I Remove-AzureStorageBlob -Context $StrContext
#Удаление контейнера
Remove-AzureStorageContainer -Context $StrContext -Name $StrContainer

Я настроил свою виртуальную машину 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, так как она имеет правильный суффикс для зоны, где регистрируются записи. Когда клиент ищет webappl, операционная система добавляет заданный по умолчанию суффикс и запрашивает DNS так, что ищется на самом деле webappl. 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. Запишите это значение.

Теперь вам надо либо вручную указать суффикс 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-nameV'kwagipstuffqxwwc.bx. internal. cloudapp.netV; 
»/etc/dhcp/dhclient.confsudo dhclient -v

Команды для Windows приведены в статье по адресу: https://github.com/Azure/azure-quickstart-tempIates/ blob/master/custom-private-dns/nested/windows-client/ setupwinclient.psl.

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

Если я развертываю собственные службы 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.