На вопросы читателей отвечает Джон Сэвилл

В. Как мне активировать архивацию ключей в Active Directory Certificate Services?

О. Секретный ключ критичен для любого сертификата. Хотя вы можете сделать резервную копию ключа, существует и другая возможность для Certificate Authority (CA). Вы можете заархивировать секретный ключ в базе данных CA, который впоследствии может быть при необходимости восстановлен. Чтобы это сделать, нужно выполнить ряд шагов.

1. Для одного или нескольких администраторов требуется сертификат Key Recovery Agent. Для этого нужен шаблон сертификата Key Recovery Agent. Откройте оснастку Certificate Authority консоли Microsoft Management Console (MMC), правой кнопкой мыши щелкните по Certificate Templates и выберите Manage.
2. Откройте свойства шаблона Key Recovery Agent. В моем примере я блокировал необходимость в одобрении Key Recovery Agent, не выбрав вариант CA certificate manager approval («одобрение менеджера сертификата CA») на вкладке требований публикации Issuance Requirements. На вкладке Security вы увидите, что по умолчанию только администраторы домена и предприятия имеют разрешение на регистрацию сертификата. Нажмите ОК и закройте консоль шаблонов сертификата Certificate Templates Console.
3. Как администратор, вы должны запросить Key Recovery Certificate через оснастку MMC Certificates, который будет виден в хранилище Personal Certificates.
4. В оснастке Certificate Authority правой кнопкой мыши щелкните по CA и выберите Properties.
5. На вкладке Recovery Agents измените вариант на Archive the key («архивировать ключ») и выберите Add for recovery agents («добавить агентов восстановления»). Выберите сертификат для администратора, затем щелкните Apply, чтобы изменение вступило в силу. Нажмите ОК.
6. Шаблоны сертификата нужно активировать для того, чтобы заархивировать секретный ключ. Выберите Certificate Templates и щелкните Manage. Выберите шаблон сертификата для активации архивирования и выберите Properties. Выберите вкладку обработки запроса Request Handling, затем выберите Archive subject's encryption private key («шифрование секретного ключа объекта архива»), как показано на экране 1. Нажмите ОК.
7. Новые сертификаты, сгенерированные из шаблона, теперь получат ключ архивации, который будет показан в Issued Certificates, когда вы добавите колонку Archived Key (View, Add/Remove Columns), см. экран 2.

Экран 1. Включение архивации

Экран 2. Проверка наличия ключа архивации

В. Как загрузить VHD из моей учетной записи Azure Storage на локальный диск?

О. Существует несколько способов загрузить файлы с Azure. Самый простой – с помощью инструментов Azure Storage сторонних фирм, например CloudXplorer от ClumsyLeaf Software (clumsyleaf.com/products/cloudxplorer). Другой способ – использовать PowerShell, например:

Save-AzureVhd -Source «https://.blob.core.windows.net/vhds/.vhd» -LocalFilePath «c:\temp\.vhd»

Вы можете перейти к контейнеру VHD учетной записи хранилища на портале Azure, чтобы найти нужный URL для VHD. Затем просто выберите значок copy to clipboard («копировать в буфер обмена»).

В. У меня есть виртуальная машина, которая соединена с доменом. Когда я пытаюсь зарегистрироваться на ней, появляется сообщение о проблеме с отношениями доверия. Что делать?

О. На самом деле с Hyper-V это не имеет ничего общего. Если вы видите сообщение The security database on the server does not have a computer account for this workstation trust relationship («У базы данных системы безопасности на сервере нет учетной записи компьютера для доверительного отношения с рабочей станцией»), когда пытаетесь зарегистрироваться, то либо пароль неверен, либо Active Directorу не знает операционную систему. Такое часто случается на компьютерах, которые либо были выключены в течение долгого времени, а объект в AD был очищен, либо вы сохранили резервную копию, у которой неправильный пароль учетной записи.

Виртуальные машины часто бывают долгое время не подключены к сети. Вдобавок, с такими технологиями как контрольные точки и моментальные снимки, легко переместить виртуальную машину назад и вперед во времени, что, в свою очередь, увеличивает вероятность возникновения проблем с паролем машины. В лабораторной среде вы можете увеличить период времени между изменениями пароля учетной записи машины или даже совсем блокировать изменение, как описано в статье Frequency of machine account password changes (windowsitpro.com/windows/frequency-machine-account-password-changes).

Такое же решение проблемы и в случае физических систем: переместите операционную систему в рабочую группу, а затем вновь подсоедините к домену.

В. Какие существуют варианты аварийного восстановления сайта System Center Configuration Manager 2012, если я теряю все серверы на сайте?

О. Мне как-то пришлось работать с клиентом, который искал варианты аварийного восстановления первичного сайта, где содержались все системы сайта и, что самое важное, база данных. Вопрос состоял в том, чтобы сделать сайт высокодоступным и, что самое главное, способным к аварийному восстановлению.

Первоначальный сайт System Center Configuration Manager состоит из базы данных сайта, которая располагается на SQL Server (может быть и кластер SQL Server), и ролей, таких как точки управления Management Points и точки распределения Distribution Points. Поддержка использования SQL Server AlwaysOn для репликации базы данных Configuration Manager на другой сервер SQL Server отсутствует. Внутри сайта вы достигаете высокой доступности посредством того, что имеете множественные экземпляры ролей, например несколько точек Management Points и несколько Distribution Points, и благодаря тому что база данных сайта располагается в кластере SQL Server. Однако такой подход не работает при аварийном восстановлении из различных мест из-за базы данных SQL Server.

Вот три варианта (начиная с предпочтительного).

• Выполните восстановление сайта в месте аварийного восстановления, которое состоит из созданного нового сервера Configuration Manager (названного так же, как и сервер, находящийся в аварийном состоянии). Затем вы переустанавливаете Configuration Manager, но выбираете вариант Recover a site («Восстановить сайт»). Далее вы выбираете местоположение своей копии на сайте и местоположение резервной копии базы данных SQL Server. Таким образом, предполагается, что у вас создано задание регулярного резервного копирования, которое через одинаковые промежутки времени копирует как настройки Configuration Manager, так и базу данных SQL Server. Этот вариант должен задействовать встроенную задачу Site Maintenance — Backup Site, которая по умолчанию не включена.
• Неподдерживаемый, но широко используемый вариант – это виртуализация различных ролей, включая SQL Server, а затем виртуализация высокой доступности и перенос виртуальных машин, содержащих системы сайта Configuration Manager в случае аварии. Сюда же может включаться управление Hyper-V Replica.
• Наличие другого первоначального сайта в местоположении аварийного восстановления. Тогда в случае аварии вы сможете переместить всех клиентов на первоначальный сайт аварийного восстановления. Однако это ведет к большому объему работ у клиентов и трафику, включая и тот, что возникает, когда вы вынуждены перемещать их назад.

В. Какой размер блока мне следует использовать в виртуальной машине, на моем CSV и т.д.?

О. Лучше всего использовать блок размером 64 Кбайт. Это гарантирует наилучшую производительность, поскольку когда речь идет о виртуализации, вы имеете дело с большими файлами VHD и VHDX.

• Для оперативной памяти используйте размеры полос данных 64 Кбайт.
• Используйте размер кластера в 64 Кбайт для файловой системы на хосте.
• Используйте размер кластера в 64 Кбайт для файловой системы внутри виртуальной машины.

VHD использует размер блока объемом в 2 Мбайт, а VHDX — размер блока объемом в 32 Мбайт. И тот и другой являются кратными 64 Кбайт. Это обеспечит наилучшую производительность для всего.

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

О. Каждый диск, присоединенный к стандартной виртуальной машине, имеет лимит в 500 операций ввода-вывода в секунду. Однако учетная запись хранилища также имеет лимит на число операций, который сейчас составляет 20 000, как написано в документе «Azure Subscription and Service Limits, Quotas, and Constraints» (azure.microsoft.com/en-us/documentation/articles/azure-subscription-service-limits/). Это означает, что если у вас более 40 дисков для одной пользовательской учетной записи хранилища, вы попадаете под ограничение до наступления лимита для реального диска, и производительность начнет страдать. Таким образом, важно иметь не более 40 дисков для одной учетной записи хранилища, если вы намерены задействовать свои диски на пределе числа их операций ввода-вывода.

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

Get-AzureDisk | Where-Object {$_.AttachedTo } | Group-Object {$_.Medialink.Host.Split('.')[0]} –NoElement

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

В. Если я использую Azure Site Recovery и обрабатываю сбой в Azure, копирует ли Azure Site Recovery данные обратно в локальную сеть в непрерывном режиме?

О. Нет. После того, как вы обработали сбой в Azure, впоследствии копирования в непрерывном режиме обратно в локальную сеть не происходит. Защита в Azure построена на использовании географически реплицируемого хранилища, что означает, что если что-то случится с центром данных Azure, хранилище будет доступно на параллельном центре данных на расстоянии в сотни километров. Когда вы захотите вернуть систему в состояние до сбоя, оно вновь копируется на локальный сайт, и выполняется обработка сбоя.

В. Сжимает ли Azure Site Recovery данные, когда они отсылаются в Azure?

О. Нет. Azure Site Recovery не сжимает данные. Однако он эффективен и передает только значимые данные на диске; например, если файл VHD размером 70 Гбайт содержит только 20 Гбайт данных, тогда только 20 Гбайт будут отосланы в Azure.

В. Могу ли я увеличить полосу пропускания, используемую для репликации виртуальной машины в Azure через Azure Site Recovery?

О. Количество потоков, используемых репликацией на Azure, может быть увеличено до 32. Однако по умолчанию Azure Site Recovery будет пытаться задействовать настолько широкую полосу пропускания, насколько это возможно. Чтобы увеличить количество используемых потоков, создайте раздел реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Backup\Replication, затем добавьте новый параметр типа DWORD, который называется UploadThreadsPerVM, и установите его значение равным 32. Данные отсылаются в большие двоичные файлы Azure через API REST и, соответственно, через Azure Site Recovery.

Если у вас есть VPN типа «сеть-сеть» из локальной сети в Microsoft Azure, тогда VPN типа «сеть-сеть» использоваться не будет; вместо этого данные будут отсылаться через постоянное Интернет-соединение. Если у вас есть канал ExpressRoute, то он будет использоваться для трафика Azure Site Recovery, о чем говорится на сайте Microsoft в статье ExpressRoute + ASR = Efficient DR solution (blogs.technet.com/b/virtualization/archive/2014/07/20/expressroute-and-azure-site-recovery.aspx). Так происходит, потому что в то время как VPN типа «сеть-сеть» идет из вашей инфраструктуры только в вашу виртуальную сеть Azure Virtual Network, ExpressRoute обеспечивает подсоединение к вашей инфраструктуре Azure, а также к службам общего пользования Azure, таким как интерфейсы хранилища.

В. Я организовал виртуальные машины на конкретных узлах в своем кластере. Я хочу, чтобы, когда это возможно, виртуальные машины всегда запускались на текущем узле. Как мне указать текущий узел в качестве предпочтительного?

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

$ClusVMs = Get-ClusterGroup |? { $_.GroupType –eq «VirtualMachine» }
Foreach ($ClusVM in $ClusVMs)
{
$ClusVMCurrentOwner = $ClusVM.OwnerNode.Name
Set-ClusterOwnerNode -Group $ClusVM $ClusVMCurrentOwner
(Get-ClusterGroup -Name $ClusVM.Name).AutoFailbackType = 1

В. Как проверить, доступно ли конкретное имя «облачной» службы в Azure?

О. Имена «облачных» служб должны быть уникальными в Azure. Чтобы проверить, доступно ли имя, запустите код PowerShell:

Test-AzureName -Service 'CloudServiceNameToTestFor'

Если результат будет False, то имя доступно.

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

О. Azure задействует много различных адресов URL, которые зависят от того, какие службы вы используете. Проще всего выяснить имена служб, которые использует ваша компания, а затем добавить их к вашему белому списку. Этот подход даст вам максимально защищенную схему. Если это невозможно, посмотрите на следующий список ключевых URL:

*.windowsazure.com
*.azure.com
*.*.core.windows.net (storage access, etc., but needs to allow two levels; e.g., *.blob.core.windows.net, *.table.core..., *.queue..., *.file...).
*.cloudapp.net
*.azurewebsites.net
*.database.windows.net
*.trafficmanager.net

Заметьте, что это будет белый список любой организации, которая использует службы Azure, а не только вашей.

В. Могу ли я задействовать стартовый экран вместо меню «Пуск» в Windows 10?

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

1. Правой кнопкой мыши щелкните по панели задач и выберите Properties («Свойства»).
2. Выберите вкладку Start Menu.
3. Очистите флажок Use the Start menu instead of the Start screen («Использовать меню «Пуск» вместо стартового окна»), как показано на экране 3.
4. Выйдите из системы и зайдите снова, чтобы изменения вступили в силу.

Экран 3. Настройка начального экрана

В. Как мне добавить дополнительные сетевые адаптеры vmNIC к существующей виртуальной машине?

О. Сейчас вы не можете добавить адаптеры сети vmNIC к существующей виртуальной машине Azure. Адаптеры vmNIC должны быть добавлены в процессе создания виртуальной машины. Если у вас есть виртуальная машина, к которой вы хотите добавить vmNIC, вам необходимо удалить виртуальную машину вместе с хранящимися VHD, а потом создать новую, используя существующий VHD и добавляя новые vmNIC в ходе процесса инициализации виртуальной машины.

В. Почему мне все еще приходится использовать группы подобия Affinity Group в Azure, хотя виртуальные сети основаны на регионе?

О. Группы Affinity Groups раньше были важным требованием для виртуальной сети Virtual Network, поскольку она была ограничена особой группой подобия (а не региональными виртуальными сетями), которая сама по себе является специфическим кластером серверов Azure. Один из ключевых аспектов кластера Azure (также называемого блоком масштабирования) состоит в том, что все серверы внутри кластера имеют одно и то же аппаратное обеспечение. Это означает, что группа подобия может быть полезной, если вы хотите убедиться, что у вас развернуто одно и то же аппаратное обеспечение. Однако помните, что разработчики Microsoft выравнивают уровни производительности разнородного аппаратного обеспечения. Таким образом, вы всегда должны видеть равную производительность, даже в среде разнородного аппаратного обеспечения. Если вы хотите быть на 100% уверены, что у вас один и тот же тип аппаратного обеспечения, разверните группу подобия.

В. Я использую службу каталогов Azure AD. Где хранятся данные? И если сотрудники работают в географически удаленных офисах, будут ли они иметь доступ к ближайшему к ним центру данных Azure в целях установления связи с Azure AD?

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

Чтобы узнать об этом больше, обратитесь к публикации в журнале Active Directory Team «Azure AD: Under the hood of our geo-redundant, highly available, distributed cloud directory.» (http://blogs.technet.com/b/ad/archive/2014/09/02/azure-ad-under-the-hood-of-our-geo-redundant-highly-available-geo-distributed-cloud-directory.aspx).

.

В. Обычный диск Azure имеет лимит в 500 операций ввода-вывода. Однако иногда я наблюдаю более 500 операций ввода-вывода, когда выполняю тест на производительность. Почему?

О. Каждый диск Azure имеет доступные варианты кэширования, такие как чтение кэша, чтение и запись кэша или отсутствие кэша. По умолчанию диск операционной системы имеет активированный кэш чтения и записи, а диски данных имеют ту настройку кэша, которая была установлена во время их создания. При наличии активного кэширования порции диска хоста и памяти используются для обеспечения кэширования диска, что улучшит производительность. Если вы отмечаете более 500 операций ввода-вывода на стандартном диске, вы, вероятно, наблюдаете работу кэширования, которое улучшает производительность, что вы и видите. Если вы получаете доступ к данным, которые считывали ранее, то вы увидите более высокую производительность. Лимит в 500 операций ввода-вывода накладывается на систему хранения Azure и не учитывает преимуществ кэширования.

Помните, что лимит в 500 операций ввода-вывода – это лимит на каждый диск. Если у вас множественные диски данных и вы скомбинировали их, используя пространства системы хранения Storage Spaces, тогда следует ожидать повышенной агрегированной производительности. Например, четыре диска с 500 операций ввода-вывода должны давать производительность в 2000 операций ввода-вывода.

В. В чем суть новой возможности наличия нескольких сетевых адаптеров multi-NIC в Azure?

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

Множественные адаптеры должны быть добавлены в процессе создания виртуальной машины и включены через PowerShell. Заметьте, что только сетевые адаптеры, заданные по умолчанию, могут осуществлять соединения через сеть (см. рисунок 1).

Рисунок 1. Подключение к Cloud Service VIP

Дополнительные сетевые адаптеры должны быть добавлены в процессе создания виртуальной машины посредством указания дополнительных интерфейсов сети с помощью команды Add-AzureNetworkInterfaceConfig. Например:

Add-AzureNetworkInterfaceConfig -Name «Ethernet1» -SubnetName «Midtier» -StaticVNetIPAddress «10.1.1.111» -VM $vm

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

Дополнительную информацию можно найти в статье Microsoft Create a VM with Multiple NICs (msdn.microsoft.com/en-us/library/dn848315.aspx).

В. Если я помещу виртуальные машины в различные «облачные» службы в Azure, они смогут сообщаться друг с другом?

О. Это довольно непростая тема. Прежде всего, подумайте об одиночной «облачной» службе. Каждая виртуальная машина имеет внутренний динамический IP-адрес (DIP), который назначен инфраструктурой Azure. Все виртуальные машины внутри «облачной» службы могут сообщаться друг с другом посредством DIP. «Облачная» служба имеет виртуальный IP-адрес (VIP), через который она выходит в Интернет. Вдобавок конечные точки могут быть созданы так, чтобы определенные порты на системе с VIP указывали на конкретные порты для особых виртуальных машин внутри «облачной» службы. Это активирует соединения виртуальных машин в «облачной» службе посредством Интернета, как показано на рисунке 2 (если у вас эти конечные точки активированы).

Рисунок 2. Адреса DIP и VIP

Теперь задумайтесь об использовании двух различных «облачных» служб, каждая из которых имеет виртуальные машины. Виртуальные машины внутри каждой «облачной» службы могут общаться, но единственный способ взаимодействия для них – через конечные точки, определенные на «облачной» службе с VIP. Это неплохо для ограниченной коммуникации, однако такой способ неэффективен. Как показано на рисунке 3, виртуальная машина, имеющая DIP2, сообщается с виртуальной машиной, имеющей DIP3, в другой «облачной» службе посредством «облачной» службы с VIP. Помните, что этот способ требует, чтобы конечная точка была определена на целевой «облачной» службе для открытого соединения с Интернетом.

Рисунок 3. Две системы в разных службах

Решение состоит в том, чтобы поместить «облачные» службы в виртуальную сеть, что впоследствии позволяет всем виртуальным машинам в «облачных» службах одной и той же виртуальной сети осуществлять коммуникацию напрямую, используя внутренние адреса (DIP), как показано на рисунке 4. При помощи виртуальной сети вы можете определять диапазон IP-адреса для использования (из маршрутизируемого не через Интернет RFC 1597).

Рисунок 4. Две системы в одной виртуальной сети

1. Всегда создавайте виртуальную сеть с первоначальным использованием схемы адресации IP, не совпадающей с адресацией в локальной сети.
2. Создавайте «облачную» службу и виртуальные машины и присоединяйте виртуальные машины к виртуальной подсети в виртуальной сети в процессе создания. Это действие привяжет «облачную» службу к виртуальной сети, а все последовательно созданные виртуальные машины в «облачной» службе будут вынуждены присоединяться к виртуальной подсети в виртуальной сети.

В результате все ваши виртуальные машины будут связываться друг с другом, используя внутренние IP-адреса, даже если они находятся в разных «облачных» службах.

В. Как мне конвертировать виртуальные машины Linux из VMware в Hyper-V?

О. Microsoft предоставляет бесплатный инструмент Microsoft Virtual Machine Convertor (MVMC, виртуальный конвертер машины Microsoft, www.microsoft.com/en-us/download/details.aspx?id=42497), который выполняет конвертацию виртуальных машин для Windows и Linux. Если вы хотите использовать инструменты сторонних фирм, то у 5nine Software существует бесплатный V2V Easy Converter 4.3 (www.5nine.com/vmware-hyper-v-v2v-conversion-free.aspx). Другие поставщики систем хранения данных (например, NetApp) тоже имеют свои инструменты конвертирования.

В. Как создать плитки меню Start с использованием своих изображений?

О. Я нашел хорошее приложение на сайте XDA Developers, которое называется OblyTile (forum.xda-developers.com/showthread.php?t=1899865). Оно может открывать любую ссылку и использовать плитку на базе изображения, которое вы зададите. OblyTile — очень простой в применении инструмент. Я использовал его при создании плиток меню Start для любимых фильмов своих детей на их планшетах.