MCTS: Virtual Machine Manager
Продолжаю месяц виртуализации – в пятницу получен MCTS: System Center Virtual Machine Manager, Configuration.
Продолжаю месяц виртуализации – в пятницу получен MCTS: System Center Virtual Machine Manager, Configuration.
Этот месяц у меня определенно – месяц виртуализации. На этой неделе я отслушал курс VMWare vSphere Installation & Configuration. Так сказать, изменил Hyper-V
. Было очень интересно, хоть курс и не покрывает все темы – буду готовиться самостоятельно.
В планах – сдача экзамена на VCP.
кросс-пост с рабочего блога: http://blogs.lankey.ru/2010/02/12/data-protection-manager-2010-release-candidate-i-ego-interesnosti/.
На днях, а именно 9-го февраля 2010 года, компания Microsoft выпустила на тестирование Release Candidate продукта Data Protection Manager 2010. Хотя продукт еще не вышел в релиз – он нам очень интересен, потому что бэкапит Exchange 2010, внедренный некоторым нашим клиентам. Кстати, скачать DPM можно с официального сайта здесь.
DPM 2010 RC интересен (кроме того, что его выход означает – релиз уже близко!) тем, что он поддерживает бэкап виртуальных машин кластера Hyper-V 2 с Cluster Shared Volumes. Чисто случайно как раз такой кластер оказался под рукой, поэтому было принято решение – устанавливать
Развертывание DPM 2010 RC открыло несколько любопытных вещей, которыми я и хочу поделиться:
Кросс-пост с рабочего блога: http://blogs.lankey.ru/2010/02/01/virtualnye-mashiny-linux-na-hyper-v/.
Чаще всего платформа виртуализации Hyper-V используется для запуска на ней операционных систем Microsoft Windows. Но на ней также работают и Linux-системы. В пятницу, 29 января, Microsoft выпустил и выложил в свободный доступ очередные компоненты интеграции Linux для Hyper-V – они доступны здесь.
Компоненты интеграции предназначены для обоих версий платформы Hyper-V – как для первой версии, входящей в состав Windows Server 2008, так и для второй, входящей в состав Windows Server 2008 R2. Эти компоненты включают в себя:
Драйвер мыши для графической оболочки Linux в комплект не входит.
Обращаем внимание, что для большинства виртуальных машин Linux доступно использование только одного виртуального процессора. Полноценная поддержка Hyper-V в ядре начинается с ядра версии 2.6.32.
Кросспост с рабочего блога: http://blogs.lankey.ru/2009/11/16/demonstracia-fault-tolerance-v-vmware-vsphere/
Технология Fault Tolerance, появившаяся в новой версии системы виртуализации VMWare vSphere, позволяет защитить виртуальную машину от сбоя физического хоста, даже не прерывая работы виртуальной машины. Все, что происходит в виртуальной машине, все процессорные инструкции, реплицируются на второй узел. И даже в случае сбоя первого узла – например, если пропало электропитание – виртуальная машина продолжит работать, сетевые соединения клиентов не будут разорваны, а приложения на сервере продолжат выполняться – клиенты и не заметят, что был сбой. Именно этим Fault Tolerance отличается, например, от High Availability – в случае с HA при сбое физического сервера виртуальные машины будут перезапущены на других узлах – при этом даунтайм составит время, необходимое для запуска виртуальных машин и загрузки операционной системы и приложений. В случае с Fault Tolerance даунтайма не будет.
Я записал видео, демонстрирующее работу технологии Fault Tolerance:
[Читать целиком...]
Кросспост с рабочего блога – http://blogs.lankey.ru/2009/11/10/blue-screen-in-windows-server-2008-r2-hyper-v/
Столкнулись с интересной проблемой – три новых сервера HP, на абсолютно новом железе, под управлением Windows Server 2008 R2 и с ролью Hyper-V, периодически выпадают в синий экран. Поскольку поведение это явно ненормальное, начали копать.
Само железо было оттестировано различными мемтестами – ничего не показало. Да и очень вряд ли в брендовых серверах что-то не так с компонентами
В журнале производительности записывается ошибка:
The computer was rebooted from a bugcheck. The bugcheck was: 0x00000101 (0x000000000000000d, 0x0000000000000000, 0xfffff880022e2180, 0x000000000000000c).
Причина оказалась очень интересной. Дело в том, что в серверах стоят новые процессоры Intel Xeon E5520, с архитектурой Nehalem. И, оказывается, в этих процессорах есть ошибка – что-то не так с прерываниями. Intel выпустила описание ошибки, и соответственно, Microsoft сформировала knowledge base и опубликовала патч – http://support.microsoft.com/kb/975530. И проявляется эта ошибка именно под управлением операционной системы Windows Server 2008 R2 и ролью Hyper-V. Причем, так как проблема проявляется только на строго определенных процессорах – данный патч недоступен через Windows Update, и его надо качать вручную.
Решение: установка специального патча с сайта Microsoft, взятого по адресу http://support.microsoft.com/kb/975530. После установки – перезагрузить сервер.
Ждем патча от Intel в виде паяльника и набора радиокомпонентов «Сделай сам»
Кросспост на рабочий блог – http://blogs.lankey.ru/2009/11/07/ustanovka-razresheniya-video-v-microsoft-office-communicator/
Мы знаем, что для того, чтобы определить максимальное качество видео, разрешенное участникам видеозвонков в Office Communications Server, нужно задать параметр на закладке Video в настройках сервера Front-End.
Но, кроме этого, ограничение на максимальное качество видеокартинки задается и на клиенте – ключом реестра.
Вообще Office Communicator имеет такую интересную особенность, что в нем невозможно принудительно задать использование определенного видеоразрешения – можно лишь ограничить его сверху, или «порекомендовать», выбрав большой или маленький размер видео в окне звонка. И даже в таком случае, качество видео будет варьироваться прямо по ходу разговора, адаптируясь к скорости сети и мощности процессора.
За задание максимально разрешенного размера видеокартинки на клиенте ответственна ветка реестра HKEY_CURRENT_USER\Software\Microsoft\RTC\Quality, а именно – два находящихся в ней ключа типа DWORD – MaxAllowedSendVideoSize, и MaxAllowedReceiveVideoSize. Как следует из названия, первый ключ ограничивает максимальное качество отправляемой удаленному абоненту видеокартинки, второй ключ – максимальное качество принимаемой от удаленного абонента видеокартинки. Эксперименты показали, что ключи эти могут принимать следующие значения:
| «MaxAllowedSendVideoSize»=dword:00000001 «MaxAllowedReceiveVideoSize»=dword:00000001 |
Качество видео – только CIF (352×288) |
| «MaxAllowedSendVideoSize»=dword:00000002 «MaxAllowedReceiveVideoSize»=dword:00000002 |
Качество видео – до VGA (640×480) |
| «MaxAllowedSendVideoSize»=dword:00000004 «MaxAllowedReceiveVideoSize»=dword:00000004 |
Какой-то очень странный режим, сильно вытянутый по горизонтали – уж не картинка ли для RoundTable? |
| «MaxAllowedSendVideoSize»=dword:00000008 «MaxAllowedReceiveVideoSize»=dword:00000008 |
Качество видео – до HD (1280×720) |
Кстати, по умолчанию этих ключей, да и всей ветки, в реестре нет – нужно ее создать. После задания этих ключей необходимо перезапустить Communicator.
Повторюсь – эти ключи не задают точный формат видео – задается лишь максимально разрешенный к использованию. Реальное качество картинки может меняться в течение разговора в зависимости от скорости сети и мощности процессора. Ну и конечно, вышеуказанные ключи влияют только на качество видеозвонка один на один – при конференции с тремя и более участниками качество видео всегда CIF (352×288).
Эксперименты показали, что видеозвонок в HD-качестве очень неплохо так загружает процессор компьютера – например, Core2 Duo 3,06 GHz в течение HD-звонка почти все время загружен на 80-85%.
Кросспост на рабочий блог – http://blogs.lankey.ru/2009/10/17/integracia-ocs-2007-r2-i-google-talk/.
Известно, что пользователи Office Communications Server 2007 R2, используя Office Communicator, могут общаться не только друг с другом, но и с клиентами других систем обмена сообщениями – AOL (и официальным ICQ), MSN Live Messenger, Yahoo – этот процесс называется федерация (federation). Пользователи видят таких клиентов в своем списке контактов, видят их состояние присутствия (так же, как и федеративные пользователи видят их состояние), и могут обмениваться текстовыми сообщениями.
Теперь количество интегрируемых с OCS систем увеличилось. Первого октября команда разработчиков Office Communications Server выпустила бесплатное дополнение для OCS 2007 R2 – XMPP Gateway, сервер для федерации с системами, работающими по протоколу Jabber – а это, например, Google Talk, или известный в России QIP.
Сервер XMPP Gateway устанавливается в сети периметра – той же самой, где находится сервер Edge. Сосуществовать с другими ролями OCS эта роль не может – для нее нужен отдельный сервер (или виртуальная машина). И, несмотря на то, что роль называется Gateway – она требует для работы лишь один сетевой интерфейс. Главное – чтобы XMPP Gateway мог связаться с сервером Edge по TCP-порту 5061, и с другими Jabber-серверами в Интернете по TCP-порту 5269. Второго мы можем добиться, например опубликовав порт 5269 на нашем внешнем firewall.
Обязательное требование к серверу XMPP Gateway – что он не должен быть членом домена, в котором развернут Office Communications Server. Рекомендуется, чтобы этот сервер просто принадлежал какой-либо рабочей группе.
Давайте попробуем развернуть эту роль и на практике посмотреть, как же можно связать пользователей Communicator и Google Talk:
Кросспост с рабочего блога – http://blogs.lankey.ru/2009/10/15/posle-obnovleniya-windows-ne-zapuskaetsya-ocs/.
14 октября была выпущена очередная порция критических обновлений операционных систем от Microsoft. Но после их установки на серверы Office Communications Server или Live Communications Server службы OCS/LCS не запускаются.
Проблема в обновлении KB974571 – «MS09-056: Vulnerabilities in CryptoAPI could allow spoofing». После установки этого обновления службы Front-End, Access Edge не запустятся.
Например, для Office Communications Server 2007 R2 в журнале событий появляются записи:
Event Type: Error
Event Source: OCS Server
Task Category: (1000)
Event ID: 12290
Description:
The evaluation period for Microsoft Office Communications Server 2007 R2 has expired. Please upgrade from the evaluation version to the full released version of the product.
Event Type: Error
Event Source: OCS Server
Task Category: (1000)
Event ID: 12299
Description:
The service is shutting down due to an internal error.
Error Code: C3E93C23 (SIPPROXY_E_INVALID_INSTALLATION_DATA)
Resolution:
Check the previous event log entries and resolve them. Restart the server. If the problem persists contact product support.
Решение: если вы еще не разворачивали обновления – не устанавливайте обновление KB974571. Если уже установили – деинсталлируйте это обновление.
Поскольку данное обновление имеет статус «Критическое» – его установка в дальнейшем крайне желательна. Ожидаем разрешения проблемы и свежего обновления от Microsoft.
Кросспост на рабочий блог – http://blogs.lankey.ru/2009/09/03/udalenie-staryx-rezervnyx-kopii-v-data-protection-manager-2007/
Все мы знаем продукт для резервного копирования данных от Microsoft – System Center Data Protection Manager 2007. Его основная задача – выполнять резервные копии и складировать их на подключенные к серверу жесткие диски. В дальнейшем для долговременного хранения данные могут быть перенесены на ленты, но основным местом хранения является жесткий диск. При создании группы хранения DPM сам разбивает выделенный ему диск на разделы, в зависимости от предполагаемого им размера резервных копий и частоты копирования.
Естественно, при создании группы защиты DPM спрашивает, каков срок хранения резервных копий для восстановления – recovery points. И, само собой, по истечении этого срока он должен удалять старые копии, чтобы на их место сохранять новые.
Но мы столкнулись с ситуацией, что старые резервные копии DPM не удаляет. Они так и копятся на диске – и, рано или поздно, наступает время, когда места под новую резервную копию уже не хватает, и DPM вываливается с ошибкой «Recovery Point Volume threshold exceeded».