IT-блог компании "ЛанКей"

Предыстория.

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

Проблема случилась у одного из наших клиентов, ИТ-инфраструктуру которого мы обслуживаем по договору ИТ-аутсорсинга. Компания занимается разработкой систем биометрической аутентификации. В рамках одного из плановых аудитов информационной системы инженеры отдела сервисного обслуживания заметили аномальное увеличение размера базы данных службы каталогов ntds.dit. Когда проблема была обнаружена, размер ntds.dit составлял 2 ГБ, но в течение недели он вырос до 8 ГБ. В компании работает всего 50 человек, и в аналогичных компаниях размер базы данных службы каталогов варьируется от 20 до 40 МБ. Поиски в Интернете ни к чему не привели, поэтому нам пришлось разбираться самим. Параллельно мы открыли инцидент в службе поддержки Microsoft, которая в данном случае нам не помогла. Кто-то из специалистов мне пытался объяснить, что мне следует почистить Event Logs, по его мнению они хранились в Active Directory. А я всю жизнь думал, что они хранятся в C:\WINDOWS\system32\config\. Ну да ладно, может быть в тот раз трубку взяла уборщица, кто его знает

Читать далее…

Продолжение статьи: http://blogs.lankey.ru/2009/09/13/configuring-cluster-vmware-ha-and-fault-tolerance-vmotion/

Технология Fault Tolerance, появившаяся в новой версии системы виртуализации VMWare vSphere, позволяет защитить виртуальную машину от сбоя физического хоста, даже не прерывая работы виртуальной машины. Все, что происходит в виртуальной машине, все процессорные инструкции, реплицируются на второй узел. И даже в случае сбоя первого узла – например, если пропало электропитание – виртуальная машина продолжит работать, сетевые соединения клиентов не будут разорваны, а приложения на сервере продолжат выполняться – клиенты и не заметят, что был сбой. Именно этим Fault Tolerance отличается, например, от High Availability – в случае с HA при сбое физического сервера виртуальные машины будут перезапущены на других узлах – при этом даунтайм составит время, необходимое для запуска виртуальных машин и загрузки операционной системы и приложений. В случае с Fault Tolerance даунтайма не будет.

Мы записали видео, демонстрирующее работу технологии Fault Tolerance:
Читать далее…

Вчера был большой день для тех, кто занимается электронной почтой и объединенными коммуникациями – стала доступна для скачивания и установки RTM-версия Microsoft Exchange Server 2010. Вот она – http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=05741f65-2a7b-4070-879f-d74208d6171d

У одного из наших клиентов мы уже внедряем Exchange 2010, поэтому дистрибутив был тут же забран для обновления.

С Release Candidate до RTM версии апгрейд проводится просто запуском установки – обновление прходит без проблем. С Beta-версии до RTM апгрейд не предусмотрен – надо деинсталлировать Beta и устанавливать RTM.

Столкнулись с интересной проблемой – три новых сервера 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 в виде паяльника и набора радиокомпонентов «Сделай сам»

Недавно к нам обратилась одна компания с просьбой восстановить Exchange Server. В компании работает около 500 человек. Занимается компания бизнесом в Интернете. Можно себе представить насколько критичным для данной компании является сервис электронной почты, куда приходят все заказы от клиентов, и происходит общение между сотрудниками. Читать далее…

Мы знаем, что для того, чтобы определить максимальное качество видео, разрешенное участникам видеозвонков в Office Communications Server, нужно задать параметр на закладке Video в настройках сервера Front-End.

Но, кроме этого, ограничение на максимальное качество видеокартинки задается и на клиенте – ключом реестра.

Вообще Office Communicator имеет такую интересную особенность, что в нем невозможно принудительно задать использование определенного видеоразрешения – можно лишь ограничить его сверху, или «порекомендовать», выбрав большой или маленький размер видео в окне звонка. И даже в таком случае, качество видео будет варьироваться прямо по ходу разговора, адаптируясь к скорости сети и мощности процессора.

За задание максимально разрешенного размера видеокартинки на клиенте ответственна ветка реестра HKEY_CURRENT_USER\Software\Microsoft\RTC\Quality, а именно – два находящихся в ней ключа типа DWORD – MaxAllowedSendVideoSize, и MaxAllowedReceiveVideoSize. Как следует из названия, первый ключ ограничивает максимальное качество отправляемой удаленному абоненту видеокартинки, второй ключ – максимальное качество принимаемой от удаленного абонента видеокартинки. Эксперименты показали, что ключи эти могут принимать следующие значения:

Кстати, по умолчанию этих ключей, да и всей ветки, в реестре нет – нужно ее создать. После задания этих ключей необходимо перезапустить Communicator.

Повторюсь – эти ключи не задают точный формат видео – задается лишь максимально разрешенный к использованию. Реальное качество картинки может меняться в течение разговора в зависимости от скорости сети и мощности процессора. Ну и конечно, вышеуказанные ключи влияют только на качество видеозвонка один на один – при конференции с тремя и более участниками качество видео всегда CIF (352×288).

Эксперименты показали, что видеозвонок в HD-качестве очень неплохо так загружает процессор компьютера – например, Core2 Duo 3,06 GHz в течение HD-звонка почти все время загружен на 80-85%.