Windows Server 2008 R2: Устранение неполадок отказоустойчивых кластеров

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

• Все аппаратные и программные компоненты должны отвечать требованиям для получения логотипа «Certified for Windows Server 2008 R2».
• Готовое решение должно пройти проверочный тест в отделе Failover Cluster Management.

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

Эти изменчивые кластеры

В Windows Server 2008 R2 понятие кластера серьезно поменялось благодаря появлению мастера проверки кластеров Cluster Validation .aspx, который входит в состав компонента Failover Clustering. Мастер проверки кластеров позволяет выполнить ряд специализированных тестов на подмножестве серверов, которые предполагается использовать в качестве узлов кластера.

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

Для тех, кто предпочитает сценарии, в отказоустойчивых кластерах теперь поддерживается Windows PowerShell.  Эту оболочку придется изучить, так как CLUSTER.EXE больше не обновляется. Если вы не знаете, что такое командлеты и для чего они нужны, можете выполнить команду Get-Help *Cluster*. Она предоставит список с описанием команд, например такой:

Name                         Synopsis
----                             --------
New-Cluster               Create a new failover cluster. Before you can create a
cluster, you must...

Если вы не знаете, как использовать командлет, можете воспользоваться командой Get-Help New-Cluster –Examples, чтобы увидеть примеры:

NAME

New-Cluster

SYNOPSIS

Create a new failover cluster. Before you can create a cluster, you
must connect the hardware (servers, networks, and storage), and run
the validation tests.

-------------------------- EXAMPLE 1 --------------------------

C:\PS>New-Cluster -Name cluster1 -Node node1,node2,node3,node4

Name
----
cluster1

Description
-----------
This command creates a four-node cluster named cluster1, using default
settings for IP addressing.

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

Все начинается с журналов событий

При возникновении неполадки прежде всего надо смотреть в журнал событий Cluster. Любые критические и простые ошибки и предупреждения попадают в системный журнал. Информационные сообщения (например, о переходе группы в автономный режим, перенос группы на другой узел и т. п.) находятся в журнале Cluster Operational Channel. Эти события можно увидеть здесь: Event Viewer/Application and Services Logs/Microsoft/Windows/FailoverClustering.

Если вы не знаете, что не так с той или иной службой или группой, можете посмотреть журнал Failover Cluster Management. Если выделена определенная группа, выберите команду «Show Critical Events for this application». Если выделена определенный ресурс, выберите команду «Show Critical Events for this resource».

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

Определив проблемный ресурс, вы можете перейти в системный журнал, чтобы просмотреть его на предмет других обстоятельств неполадки. Пусть вас не обманывают симптомы — сконцентрируйтесь на причине проблемы. Например, в случае сбоя сетевого имени или IP-адреса посмотрите, нет ли других связанных с сетью событий, которые могут приводить к этой неполадке (сбой стека TCPIP, неработоспособная сетевая карта и т. п.).

Журнал отладки кластера перенесен в сеансы трассировки событий. Файла CLUSTER.LOG больше нет — теперь система записывает информацию в ETL-файлы (extract, transform and load), размещенные в папке %WinDir%\System32\winevt\logs. Из этих ETL-файлов можно сгенерировать единый файл CLUSTER.LOG. Однако это снимок на определенный момент времени. Иначе говоря, при создании файла Cluster.log запись в оригинальный Cluster.log не производится. Каждый раз, когда вы генерируете этот файл на узле, он перезаписывает предыдущую копию.

Можно генерировать журналы командой Get-ClusterLog оболочки Windows Powershell. Она применяется ко всем узлам кластера и создает файл на каждом кластере в папке %WinDir%\Cluster\Reports. Для регулирования числа узлов и размера файлов применяются дополнительные параметры.

Допустим, у вас кластер из девяти узлов и вы хотите получить все журналы. Можете воспользоваться параметром –Destination — будут сгенерированы все журналы и скопированы в указанное место. Они все попадут в одно указанное вами место. В имени файла будет указано имя узла (например, команда Get-ClusterLog –Destination c:\logs создаст файлы <имя_узла_1>_Cluster.log, <имя_узла_2>_cluster.log и т. д. в папке C:\LOGS).

Если нужно выяснить, легко ли воспроизводится неполадка, воспользуйтесь параметром периода времени –Timespan (в минутах). Просто воспроизведите неполадку на узле и выполните команду Get-ClusterLog –Timespan 5 –Node <имя_узла_1>. Она сгенерирует Cluster.log только для узла 1 и только за последние пять минут.

Вот некоторые советы по устранению неполадок на таком уровне:

• Этот журнал подробный и сложный и это должно быть не самое первое место, в котором надо искать информацию.
• Позаботьтесь о записи данных как минимум за последние три дня. В этом случае если сбой произойдет в пятницу, при выходе на работу в понедельник данные все еще будут доступны. Каждый журнал занимает 100 МБ. Если надо увеличить этот размер, используйте в Windows Powershell команду Set-Clusterlog –Size 200 (можете указать другой, более подходящий вам размер).
• Некоторые приложения слишком «шумные» или «многословные», когда речь идет о записях в журналах. В этом случае также придется увеличить размер журнала.
• В журнале отладки кластера используется время GMT, поэтому придется преобразовывать время в локальное.
• Если журналы должны быть в определенном месте или охватывать определенное время, используйте соответственно параметр –Destination или –Timespan.

В следующем выпуске мы поговорим о некоторых стандартных сценариях устранения неполадок.