Недавно коллеги прислали ссылки на интересный спор признаных специалистов по разным системам виртуализации Антона Жбанкова и Андрея Маркелова, о том какие процессоры виртуальная машина получает при работе под Red Hat Enterprise Virtualization и vSphere. Получается, что внутри старых версий RHEV виртуальная машины получала по умолчанию процессор Pentium II. Это не позволяло виртуальным машинам задействовать инструкции новых поколений процессоров и вело к неэффективной работе. В случае использования более новой версии RHEV появляется возможность выбрать более современную модель процессоров.

В связи с этим возникает вопрос, а как обстоят дела с процессорами виртуальных машин при использовании Hyper-V?

Представим, что у нас есть физический хост Hyper-V со следующими характеристиками процессора, ОЗУ и материнской платы:

Теперь представим что мы хотим объединить этот физический хост еще с одним или несколькими хоставми в кластер Failover Cluster. Если все узлы кластера у нас одиаковые, то мы автоматически получим внутри виртуальной машины Windows 7 следующие характеристики виртуального оборудования.

Виртуальная машина получает такой же процессор как и хостовая ОС. Изменения видны лишь в материнской плате. ОС внутри виртуальной машины может воспользоваться всеми преимуществами оптимизированных инструкций современных процессоров.

Рассмотрим следующий случай. Представим, что в кластере у нас есть физические узлы с разными версиями процессоров. Такое явление хоть и не сильно распространено, но все же встречается. Происходит это, потому что обычно мало кто закупает все узлы кластера сразу. С течение лет узлы, добавляемые в кластер Hyper-V, могут начать различаться. Стоит отметить, что в кластер можно объединять только процессоры одного производителя. Либо Intel, либо AMD. Для того чтобы виртуальная машина могла мигрировать с помощью Live migration c одного физического узла на другой, отличающийся процессором, необходимо чтобы внутри виртуальной машины был процессор инструкции которого могут быть реализованы процессорами обоих физических узлов участвующих в миграции. То есть некий общий знаменатель возможностей процессоров узлов кластера. Для получения такого “общего” процессора виртуальная машина должна быть помечена специальным флагом под названием “Migrate to physical computer with different processor version”. Установить этот флаг можно в свойствах виртуальной машины. В результате она автоматически получит немного другой процессор и следующие виртуальные компоненты.

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

Перейдем к другому случаю. Что если нам в целях совместимости в виртуальной машине, нужно запустить какую либо устаревшую версию ОС. Все очень просто в свойствах виртуальной машины ставим флаг “Run an older operating system such as Windows NT”. После этого модель процессора в виртуальной машине снова поменяется. Никаких больше процессоров Intel Core 2 Quad получаем более старый и простой процессор Intel Core 2. Впрочем, старые операционные системы все равно не могут воспользоваться преимуществами новых процессоров, так что Intel Core 2 как раз то что надо для таких ОС.

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

Я достаточно часто пишу о том, как проектировать, внедрять и управлять DirectAccess. Как объединить DirectAccess и UAG для получения наибольшей выгоды и удобства. Но для полноценного перехода на эту технологию нужно в том или ином виде применять IPv6, NRPT, DNSSEC. Не все понимают, как это сделать, поэтому мы расширяем набор документации по работе с этой технологией.

Обычно я рекомендую прочитать подробную инструкцию по развертыванию DirectAccess в тестовой лаборатории. Если технология вам понравилась, то можно почитать Capacity Planning for DirectAccess Servers, чтобы понять какие аппаратные и программные ресурсы от вас потребует внедрение этого функционала.

Так же очень полезно ознакомиться с этим документами. Они показывают, как разграничивать доступ DirectAccess клиентов к вашей внутренней инфраструктуре.

Full Intranet Access Example

Selected Server Access Example

Design for Remote Management

Design Your DNS Infrastructure for DirectAccess

Design Your PKI for DirectAccess

Appendix B: Reviewing Key DirectAccess Concepts

Forefront UAG DirectAccess Deployment Guide

В документ DirectAccess Deployment Guide добавился список дополнительных материалов. Этот список можно использовать как шпаргалку при разработке плана внедрения DirectAccess.

Если в процессе развертывания DirectAccess у вас что либо не работает, то для поиска и устранения неисправности можно воспользоваться следующими документами:

Test Lab Guide: Troubleshoot DirectAccess

DirectAccess Troubleshooting Guide

DirectAccess Design, Deployment, and Troubleshooting Guides

Еще один интересный набор документов посвящен манипуляциям c IPsec при работе с DirectAccess.

Moving the IPsec Gateway to Another Server

Configure the Intra-Server Subnet

Configure the IPv6 Connectivity Server

Configure the IPsec Gateway Server

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

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

Добрый день всем кому интересны вопросы резервного копирования и восстановления данных. Говорят что на свете есть два вида ИТ специалистов - те кто еще не пострадал и те кто уже де��ает резервные копии. Вторую категорию тоже можно разделить на две части – тех, кто уже проверил свои резервные копии и попытался восстановить из них данные и тех, у кого сюрприз еще впереди. Понятно, что эта шуточное описание состояния дел во многих компаниях несколько преувеличивает частоту возникновения проблем, но зато оно готовит нас к самому худшему. В реальности конечно все нет так уж и плохо и катастрофическая потеря данных обычно случается довольно редко. В тоже время я предполагаю что ни вам, ни вашему руководству не хочется испытывать свою удачу и рисковать потерей данных и остановкой бизнеса. Если вы уже начали работать над проблемой резервного копирования, то полпути к спокойной жизни вы уже прошли.

Сегодня хочется поделиться набором документов, которые помогут защищать данные генерируемые типовыми бизнес приложениями Exchange Server, SQL Server, SharePoint Server с помощью SC DPM 2010. Часть из них написана Microsoft часть партнерами. Поэтому читать их вдвойне интересно, т.к. это взгляд на проблему не только со стороны Microsoft.

What’s New with Microsoft Data Protection Manager 2010
Product Overview of DPM 2010

How to protect Exchange with DPM 2010
DPM 2010 datasheet for Exchange
Protecting Exchange 2010, including DAGs, with DPM 2010

How to protect SQL Server with DPM 2010
DPM 2010 datasheet for SQL Server

How to protect SharePoint with DPM 2010
DPM 2010 datasheet for SharePoint

How to protect Hyper-V with DPM 2010

How to protect Windows Clients with DPM 2010

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

Сегодня опубликовали документ, описывающий как правильно проектировать и развертывать Remote Desktop Gateway в Windows Server 2008 R2. В нем подробно рассказывается о рекомендуемой методике нагрузочного тестирования, демонстрируются результаты проверок на масштабируемость, дано описание типовых вариантов развертывания RD Gateway. Так же в документе говорится об основных факторах, влияющих на то, сколько пользовательских подключений сможет обслужить ваш проект на основе RD Gateway. Плюс к этому в документе описываются экспериментальные результаты при комбинировании разных вариантов оборудования и типовых сценариев использования данной технологии.

P.S.

Если вы все еще не знаете что такое Remote Desktop Gateway и чем он может быть полезен, то рекомендую посмотреть вот эти доклады:

Что нового в терминальных службах Windows Server 2008

Обзор возможностей Windows Server 2008 R2 Remote Desktop Services и Virtual Desktop Infrastrurcture

Установка и настройка Remote Desktop Gateway / Terminal Services Gateway