Обзоры

Система наблюдения за ресурсами

Теперь перейдем к системе наблюдения за ресурсами Resource Host System (RHS), одной из функций которой является отслеживание состояния всех ресурсов в кластере. Система выполняет серию проверок (базовых и полных). Если ресурс не реагирует на проверку, то RHS генерирует следующее системное событие: Идентификатор события: 1230

Описание: ресурс кластера Disk 1’(resource type”, DLL .dll’) либо поврежден, либо заблокирован. Если диск не отреагировал на проверку состояния, то кластер выводит данный ресурс из работы и перезапускает его для возврата в рабочий процесс. Если бы такие проверки не проводились, отказ ресурса мог бы привести к «зависанию» компьютера или невозможности подключения из клиентского приложения.

Проводя диагностику события RHS, необходимо проанализировать проблемный ресурс. Если диск заблокирован, следует проверить все содержимое стека диска. Возможно, причиной является медленный ввод-вывод диска, либо потерян путь к нему. Это должно быть ориентиром проводимой диагностики. На следующем этапе выполняется поиск относящихся к диску событий в системном журнале, анализ системного монитора, обновление драйверов и т. д. Если ресурсом является IP-адрес или сетевое имя, то в центре внимания должен быть сетевой стек и все его содержимое.

Проверка кластера

Последняя тема обсуждения —отчет о результатах проверки кластера Cluster VaUdate. Чтобы кластер был «кондиционным», все его компоненты должны быть перечислены в каталоге Windows Server и необходимо, чтобы он прошел полную проверку. Многие запускают проверку кластера до или сразу после создания. Однако если проблемы возникают позже, то лишь немногие помнят об этой функции, которую также можно использовать как средство диагностики. Если возникают проблемы с диском, запустите тесты хранилища Storage Tests. При наличии проблем с сетевой передачей данных воспользуйтесь сетевыми тестами Network Tests. С помощью функции проверки кластера можно также получить данные о группах, ресурсах и параметрах текущего отказоустойчивого кластера для обращения к этим сведениям в дальнейшем.

Достоинством проверки кластера является возможность ее запуска без прерывания рабочего процесса. При выборе теста хранилища Storage Test выдается вопрос, следует ли переводить работающие группы в автономный режим (экран 5). Установка по умолчанию предполагает невмешательство в работу групп, находящихся в режиме онлайн, и рабочий процесс не затрагивается. Тесты хранилища предусматривают проверку дисков, которые:

• принадлежат группам в автономном режиме;

• принадлежат активной группе хранения;

• не являются частью кластера.

При каждом запуске проверки кластера в каталоге C:\Windows\Cluster\Reports на каждом проверяемом узле создается файл с именем, часть которого составляют дата и время.

Существуют и другие способы диагностики отказоустойчивых кластеров, однако для их описания в этой статье не хватило бы места. Однако приведенные здесь рекомендации применимы к большинству проблем, с которыми вы можете столкнуться. Для получении дополнительной информации посетите блог Ask the Core Team (http://blogs.technet.com/b/askcore/) или Clustering and High Availability (http:// blogs. msdn .com /b / clustering). Успешной кластеризации!

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

Диспетчер отказоустойчивости кластеров

Для упрощения анализа системные ошибки и предупреждения можно просматривать из окна диспетчера отказоустойчивости кластеров. На главной странице на центральной панели находится ссылка на последние события кластера Recent Cluster Events (экран 2). Эта ссылка позволяет вывести на экран все предупреждения и ошибки, связанные с отказоустойчивым кластером, за последние 24 часа. События, собранные со всех узлов, сосредоточены в одном месте, что избавляет от необходимости открывать несколько журналов событий на нескольких компьютерах.

Дорогие пользователи, любые программы для компьютера вы можете на сайте pc-program.ru. Ресурс предоставляет софты для скачивания с официальных сайтов.

Для просмотра конкретных событий можно использовать элемент Query, доступ к которому открывается из элемента Cluster Events на левой панели главной страницы. В меню, которое мы открываем правым щелчком на Cluster Events, выберите пункт Query либо укажите Query на панели Actions справа. На экране 3 показан фильтр событий кластера.

Диспетчер отказоустойчивости кластеров —удобный инструмент для отображения всех данных в одном месте. Предположим, что произошел отказ некоего ресурса диска. В окне диспетчера отказоустойчивости кластеров можно запросить все узлы, журнал системных событий System, а также указать уровень событий и конкретную дату. На главной странице можно будет увидеть, когда и на каких узлах случился отказ диска, и просмотреть все относящиеся к этому событию данные. Запросы можно сохранить для последующего использования. Поиск событий определяют два параметра. События появления отказов можно искать по всем ресурсам либо только по конкретному ресурсу. Для этого в меню Actions (экран 4) можно выбрать пункт Show the critical events for this application («Отображение критических событий для данного приложения») или Show the critical events for this resource («Отображение критических событий для данного ресурса»). Это позволяет формировать запрос всех событий из текущих журналов, создаваемых на всех узлах, либо ограничить список запрашиваемых событий рамками заданного периода времени или узла.

Журнал диагностики —эквивалент Cluster.Log в Wmdows 2003 Server Cluster. Начиная с отказоустойчивой кластеризации, реализованной в Server 2008, функции журнала больше соответствуют процессу трассировки событий для Windows Event Tracing (ETW). Вместо текстового файла Cluster.Log запись осуществляется в журнал диагностики, хранящийся в папке C:\Windows\System32\winevt\logs. Существует три журнала диагностики, куда осуществляется запись (clusterlog.etl.001, clusterlog.etl.002 и clusterlog.etl.003). В ходе каждой отдельной загрузки запись происходит только в один из журналов. Более подробные сведения о файлах журналов и их применении можно найти в блоге Understanding the Cluster Debug Log in 2008 (http://blogs.technet.соm/b/askcore/archive/2010/04/13/ understanding-the-cluster-debug-log-in-2008.aspx).

Журнал диагностики включен и постоянно осуществляет запись. Если в меню, открываемом правым щелчком на FailoverClustering\Diagnostic, выбрать команду Disable log («Отключить журнал»), то можно просмотреть все записанные события. После отключения журнала система перестает записывать в него данные, и информация не сохраняется. Если журнал был отключен, то лучше всего сохранить данные в виде журнала событий или текстового файла и включить журнал снова. В журнале регистрируются три основных типа событий:

• событие 2049 —информационное;

• событие 2050 —предупреждение;

• событие 2051 —ошибка. Эти события выводятся только из текущего журнала трассировки событий .ETL, в который осуществляется запись. Информация о событиях отображается так же, как в системном журнале и журнале приложения. Однако каждое событие занимает отдельную строку, поэтому просмотр всего журнала диагностики может оказаться делом довольно утомительным. Можно создать текстовый файл Cluster.Log с помощью команд, позволяющих свести воедино три журнала, что значительно облегчает восприятие информации.

Команда PowerShell Get-ClusterLog инициирует на всех узлах создание журнала Cluster.Log, который помещается в папку C:\Windows\Cluster\Reports. Меню Get-ClusterLog содержит пункты, которые могут оказаться полезными в определенных обстоятельствах. Например, для выяснения причин проблемы можно воспроизвести ее, а затем воспользоваться командой

Get-ClusterLog-TimeSpan 5

для вывода данных за последние 5 минут. Поскольку требуется журнал только с одного узла, на котором воспроизводится проблема, можно добавить параметр Node Nodename для создания Cluster.Log только на этом узле. Если требуется пересылка журналов с нескольких узлов, то установление соединения с каждым из них для получения нужного файла может занять некоторое время. В этом случае можно воспользоваться параметром-Destination, который обеспечит создание Cluster.Log на каждом узле и последующее копирование этого журнала в заданную папку в виде файла под именем, к которому прикреплено имя компьютера (например, W2K8-R2-Node1_Cluster. Log). Создаваемый журнал Cluster.Log —это моментальный снимок во времени, который фиксирует текущее состояние и уже не обновляется. Если при создании журнала в папке Reports уже есть Cluster.Log, то существующий файл удаляется и освобождается место для нового.

Главное, что следует искать

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

Первое, с чем предстоит работать, —диспетчер отказоустойчивости кластеров. Этот новый инструмент управления кластером позволяет руководить группами и ресурсами и выполнять диагностику неполадок. Диспетчер отказоустойчивости кластеров открывается из пункта «Администрирование» в меню «Пуск».

Каналы событий

Каждый, вероятно, знаком с журналом системных событий, в котором регистрируются критически важные события, ошибки и предупреждения. Однако это не единственное место, где фиксируются события. Начиная с Server 2008 существуют еще и каналы событий. На экране 1 показано, как найти каналы, имеющие отношение к отказоустойчивой кластеризации. Именно здесь следует искать все информационные и отладочные/диагностические события. На схеме мы видим следующие журналы и их каналы.

• FailoverClustering:

— Operational;

— Diagnostic (если выбран пункт Show Analytic and Debug Logs («отобразить журналы анализа и отладки»));

— Performance-CSV (если выбран пункт Show Analytic and Debug Logs).

• FailoverClustering-Client:

— Diagnostic (если выбран пункт Show Analytic and Debug Logs).

• FailoverClustering-Manager:

— Admin;

— Diagnostic (если выбран пункт Show Analytic and Debug Logs).

• FailoverClustering-WMIProvider:

— Admin;

— Diagnostic (если выбран пункт Show Analytic and Debug Logs).

События запуска/остановки службы кластеров, перемещения групп, перевода групп в онлайн/автономный режим и т. д. регистрируются в журнале FailoverClustering\Operational. Например:

Идентификатор события: 1061 Описание: служба кластеров успешно настроила отказоустойчивый кластер JohnsCluster.

Неудачные попытки установления соединения с другими узлами при открытии диспетчера отказоустойчивости кластеров регистрируются в журнале FailoverClustering-Manager\Admin. Например: Идентификатор события: 4684 Описание: диспетчеру отказоустойчивости кластеров не удалось связаться с серверами DNS для разрешения имени W2K8-R2-NODE2.contoso.com. Дополнительные сведения можно найти в канале диагностики диспетчера отказоустойчивости кластеров.

В журнале FailoverClustering-Manager\ Diagnostic можно увидеть следующее:

Идентификатор события: 4609

Описание: ошибка при попытке проверки связи с W2K8-R2-NODE2.contoso.com. System.ApplicationException: не удалось связаться с одним или несколькими DNS-серверами. Убедитесь в правильности настройки DNS и полном подключении компьютера к сети.

Идентификатор события: 4612 Описание: проверка связи с W2K8-R2-NODE2.contoso.com завершилась сбоем.

Именно по этим событиям можно установить проблему подключения узла к серверу DNS и затем приступить к ее устранению. Не просматривая указанные журналы, о наличии неполадок можно будет судить по тому, что в диспетчере отказоустойчивости кластеров узел W2K8-R2-NODE2 будет отображен как неисправный. Еще один журнал в числе упомянутых выше, Failover-Clustering\Diagnostic, мы обсудим несколько позже.

Шаг первый: проверьте трубы с помощью Repadmin

Предварительная подготовка к установке первого контроллера домена версии 2008/2008 R2

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

После выхода Consumer Preview (в конце февраля 2012 года) произошло два изменения. Во-первых, мы лучше освоились с Windows 8 и теперь можем делать более обоснованные выводы. Во-вторых, к выпуску Release Preview вся система была заметно переработана и, что более важно, значительно усовершенствованы встроенные приложения, ранее реализованные лишь в ознакомительной форме, а это позволяет теперь получить о них более полное представление.

Оценка Windows 8 в целом. При целостной оценке Windows 8 становится очевидной историческая значимость этого выпуска, которому предстоит определить, станет ли Windows лидером в мире вычислений или останется рядовым игроком.

Радикальные изменения в новой операционной системе Microsoft

На момент публикации этой статьи уже выйдет в свет Wmdows 8 Release Preview —последний предварительный общедоступный выпуск новой настольной операционной системы Microsoft.

Эффективный инструмент для работы с журналами событий.