Ошибка добавления узла в кластере

Доброе время суток.

В кластеризации я слаб, так как это мой первый опыт борьбы с кластеризацией.

Поиски ни чего не дали, с английским дружу плохо.

Описываю все с самого начала.

Приобрели 3 сервера.

1. HP DL320e Gen8 (Windows Server 2012 Standart ActiveDirectory лес: corp.company.ru)

2-3. HP DL360p Gen8 (WinSrv 2012 DataCenter FailoverCluster + Hyper-V) (Name CL1-HV1 и CL1-HV2)

4. HP P2000 G3 MSA iSCSI Dual Controller LFF (установлены 6 HDD по 1Tb Raid10 и 4 HDD по 300Gb Raid10, разбиты на Lun0 10Gb (Quorum), Lun1 590Gb, Lun2 2Tb)

Изначально все установли в таком виде, но в связи с тем что у HP под MPIO надо делать изменения, но на тот момент не знали про это и приняли решение поставить Windows SRV 2008 R2 DC, внесли все изменения все сделали, собрали
кластер, начали запускать виртуальные машины все было хорошо, но ровно через неделю начал переводить все виртуальные машины с одного сервера на другой, но машины не хотели мигрировать. Начал смотреть в чем проблема
смотреть логи и разбираться, проводил проверку кластера все было хорошо, но ни чего не помогало. После этого отвалился от кластера один сервер, потом на первом сервере кластер вообще перестал работать, операционка перестала запускаться
удачно. Было принято решение переустановить операционную систему. Установив Win2008R2 DC на всех двух нодах, проделав все действия с настройкой MPIO iSCSI начал собирать кластер, но проблема возникла с тем что ни в какую не хотел собираться.
Пишет одну и туже ошибку:

Начало настройки кластера Hyper-V.

Инициализация кластера Hyper-V.

Проверка состояния кластера на узле CL1-HV1.corp. company.ru.

Поиск в домене объекта-компьютера «Hyper-V».

Создание в домене новой учетной записи компьютера (объекта-компьютера) для «Hyper-V».

Настройка объекта-компьютера «Hyper-V in organizational unit OU=Cluster,OU=Server,DC=corp,DC= company,DC=ru» как объекта имени кластера.

Проверка установки FT-драйвера сети на узле CL1-HV1.corp.company.ru.

Проверка установки драйвера дисков кластера на узле CL1-HV1.corp.company .ru.

Настройка службы кластеров на узле CL1-HV1.corp.company.ru.

Проверка установки FT-драйвера сети на узле CL1-HV2.corp.company.ru.

Проверка установки драйвера дисков кластера на узле CL1-HV2.corp.company.ru.

Настройка службы кластеров на узле CL1-HV2.corp.tyumen-judo.ru.

Ожидание уведомления о запуске службы кластеров на узле CL1-HV1.corp.company.ru.

Формирование кластера «Hyper-V».

Не удалось завершить очистку.

Произошла ошибка при создании кластера. Узлы будут очищены. Пожалуйста, подождите…

Произошла ошибка при создании кластера. Узлы будут очищены. Пожалуйста, подождите…

Произошла ошибка при очистке узлов кластера. Воспользуйтесь командой Clear-ClusterNode, чтобы очистить узлы вручную.

Произошла ошибка при очистке узлов кластера. Воспользуйтесь командой Clear-ClusterNode, чтобы очистить узлы вручную.

Произошла ошибка при создании кластера.
Возникла ошибка при создании кластера «Hyper-V».
Возврат из операции произошел из-за превышения времени ожидания

Для устранения неполадок при создании кластера запустите мастер проверки конфигурации на серверах, которые вы хотите включить в кластер.

Но все тесты проходят удачно, проблем не выявляется.

После не многих мучений под WinSrv 2008R2, снова переустановили на WinSrv 2012 DC, произвели все настройки MPIO все работает замечательно, но кластер не собирается ни в какую, попробовали создать кластер с из одной ноды и подключить вторую
ноду, На одной ноде все создалось удачно, но ввести второй узел не получается, создать отказоустойчивый кластер не получается создать.

Люди помогите покажите куда копать….. 

Создан кластер Hyper-V на базе Windows Server 2012 R2 с единственным узлом и диском-свидетелем. После этого пытаемся добавить в кластер новый узел. В результате появляется ошибка:

Если смотреть отчёт (View Report), то видно что узел проходит первичную валидацию, а потом операция безуспешно завершается с сообщением о каким-то таймауте ожидания:

Adding KOM-AD01-VM07.holding.com to the cluster.
Validating cluster state on node KOM-AD01-VM07.
Getting current node membership of cluster KOM-AD01-VMFC01.
Adding node KOM-AD01-VM07 to Cluster configuration data.
Validating installation of the Network FT Driver on node KOM-AD01-VM07.
Validating installation of the Cluster Disk Driver on node KOM-AD01-VM07.
Configuring Cluster Service on node KOM-AD01-VM07.
Waiting for notification that Cluster service on node KOM-AD01-VM07.holding.com has started.
Waiting for notification that node KOM-AD01-VM07 is a fully functional member of the cluster.
Cluster service on node KOM-AD01-VM07 did not reach the running state. The error code is 0x5b4. For more information check the cluster log and the system event log from node KOM-AD01-VM07. This operation returned because the timeout period expired.
Unable to successfully cleanup.
The server 'KOM-AD01-VM07.holding.com' could not be added to the cluster.
An error occurred while adding node 'KOM-AD01-VM07.holding.com' to cluster 'KOM-AD01-VMFC01'.
This operation returned because the timeout period expired

Чтобы понять корень проблемы требуется дополнительная отладочная информация, получить которую помогут рекомендации из статьи Failover Clustering and Network Load Balancing Team Blog — How to Troubleshoot Create Cluster failures in Windows Server 2012. В частности, для получения лога компоненты кластеризации выполним на обоих серверах (на действующем узле кластера и добавляемом в кластер сервере) Powershell командлет выгружающий в текстовый файл этот самый лог:

Get-ClusterLog -Destination C: –UseLocalTime

В результате, по указанному пути появиться лог-файл с именем вида KOM-AD01-VM04_cluster.log

В нашем конкретном примере изучение лога на добавляемом в кластер сервере не внесло ясности, однако в логе сервера-владельца кластера были замечены множественные предупреждения вида:

00000ad8.00001dd4::2014/10/29-20:14:55.154 WARN  mscs::ListenerWorker::operator (): (5060)' because of '[FTI][Initiator] Discarding connection from 10.160.35.58:~3343~ to 10.160.35.57:~3343~ (node KOM-AD01-VM07) because it uses a disabled network.'

В итоге выяснилось, что выключенная в кластере подсеть, относящаяся к Live Migration и стала причиной возникновения проблемы.

После включения соответствующей кластерной сети новый узел успешно был добавлен в кластер.

Другие материалы, которые могу оказаться полезными при разборе ситуаций с невозможностью добавления нового узла в кластер:

• SQLServerScribbles.COM — windows cluster freezes at “waiting for notification that node ‘‘ is a fully functional member of the cluster”
• Microsoft GTSC Romania — Enterprise Platforms Support Blog —  The case of the server who couldn’t join a cluster – operation returned because the timeout period expired
• TechNet Forum — Can’t add Hyper-V 2012R2 Node

В статье приведены решения наиболее часто возникающих проблем, связанных с работой VMmanager KVM.

Проблемы с панелью управления

Обновление ПО кластера VMmanager KVM до VMmanager Cloud

Такое обновление не поддерживается.

VMmanager зависает и тормозит, в логе фигурирует ошибка «too many connections»

Наиболее частой причиной такой проблемы является зависание libvirt. Проверьте, что libvirt отвечает, попробуйте его перезапустить.

Какие процессы важны для VMmanager? Что можно отслеживать?

Важен процесс ihttpd. Также на серверах должен быть запущен libvirt.

Какие единицы измерения используются в панели управления?

В панели управления используются KiB и MiB:

• KiB (кибибайт) — 2 в степени 10 = 1024;
• MiB (мебибайт) — 2 в степени 20 = 1048576.

Что отлично от привычных KB и MB:

• MB (мегабайт) — 10 в степени 6 = 1000000;
• KB (килобайт) — 10 в степени 3 = 1000.

Формирование виртуальной машины:

• если требуется создать виртуальную машину c 2GB оперативной памяти, то в форме редактирования необходимо указать 1907MiB (точное значение 2GB = 1907,35MiB);
• если требуется создать диск виртуальной машины размером 15GB, то в панели необходимо указать 14305Mib;
• обратите внимание на калькулятор величин от Google.

Проблемы с узлами кластера

После добавления виртуальной машины один из узлов кластера становится недоступен, а при попытке подключения к нему по SSH происходит подключение к виртуальной машине

При выдаче IP-адресов виртуальным машинам из той же подсети, в которой выделены IP-адреса для узлов кластера, возможна выдача IP-адреса, присвоенного узлу кластера. Вследствие этого узел будет недоступен. Для избежания данной проблемы зарезервируйте адреса узлов кластера в локальной базе IP-адресов или в IPmanager, если настроена интеграция.

Для освобождения занятого адреса виртуальной машиной выделите для неё новый IP-адрес. Перейдите в Управление → Виртуальные машины → IP-адреса. Создайте новый IP-адрес и удалите адрес, который пересекается с адресом узла кластера. Для использования виртуальной машиной нового IP-адреса измените настройки сетевого интерфейса и перезапустите сеть командой:

systemctl restart network

Ошибка при добавлении узла кластера: «Ошибка установки пакетов ‘vmmanager-kvm-pkg-vmnode’ на удалённом сервере. Дополнительная информация доступна в журнале панели управления»

Причина: пакет libguestfs устанавливается только в интерактивном режиме.

Решение: установите пакет vmmanager-kvm-pkg-vmnode из консоли.

Не добавляется узел с операционной системой CentOS

Возможная проблема — не устанавливаются необходимые пакеты. Причина — отсутствие подключённого репозитория epel. Возможная причина — неверная дата на сервере — репозиторий не находится. Проверьте и исправьте при необходимости время и дату и повторите попытку.

Не добавляется узел. Ошибка: «Невозможно применить правила брандмауэра: ошибка в синтаксисе iptables»

В логах vmmgr.log при этом видно ошибку запуска скрипта /etc/libvirt/hooks/firewall.sh:

# /etc/libvirt/hooks/firewall.sh
# Generated by VMmanager KVM on Сбт Апр 18 21:31:18 CEST 2015 *filter
# ISPsystem firewall rules
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-F INPUT
-F FORWARD

COMMIT --------------------------------
ip6tables-restore v1.4.7: ip6tables-restore: unable to initialize table 'filter'

Error occurred at line: 2
Try 'ip6tables-restore -h' or 'ip6tables-restore --help' for more information.

Для решения проблемы закомментируйте строки в конфигурационном файле /etc/modprobe.d/ipv6.conf и перезапустите модуль ipv6.

Утилиты управления кластером

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

/usr/local/mgr5/sbin/nodectl --op exec --target all --cmd 'echo "Hello, world!"'

Переход по SSH на узел кластера:

/usr/local/mgr5/sbin/nodectl login <id узла кластера>

Просмотр списка узлов кластера:

/usr/local/mgr5/sbin/nodectl list

Проблемы с хранилищами

Проблемы с LVM-хранилищем

Невозможно создать хранилище с типом LVM. При попытке добавить новый узел в кластер иногда возникает ошибка «unsupported configuration: cannot find any matching source devices for logical volume group»

Убедитесь, что команды LVM подтверждают существование физических томов, которые планируется добавить. Попробуйте удалить хранилище и узел кластера и добавить заново. Удаление хранилища выполняется с помощью команды:

virsh pool-undefine название-хранилища.

Проблемы с сетевым LVM-хранилищем

Не удаётся обнаружить группу томов на узлах

Если команда vgs на узлах не отображает группу томов LVM с iSCSI-хранилища, проверьте, работает ли с ней iscsi-target. Для этого на узле таргета выполните команду:

tgtadm -m target --op show

Если в списке lun необходимый раздел отсутствует, добавьте его вручную:

tgtadm -m logicalunit --op new --tid 1 -b /dev/sda2 --lun 1

После этого перезагрузите tgtd, переподключите узлы к таргету и выполните на узлах pvscan для обнаружения пула.

Проблема при подключении нового узла кластера

После внесения изменений в файл /etc/tgt/targets.conf (например, требуется подключить ещё один узел и был добавлен ещё один initiator-address) узел не удаётся подключить (команда iscsiadm -m discovery -t st -p … возвращает «iscsiadm: No portals found»). Причина, скорее всего, заключается в том, что сервис фактически не перезапускается и не перечитывает конфигурационный файл, пока к нему подключены клиенты.

При перезагрузке сервиса убедитесь, что он перезапустился:

service tgtd stop
killall -9 tgtd
service tgtd start

Проблемы с iSCSI-хранилищем

Requested operation is not valid: storage pool is not active

Ошибка возникает, если есть проблемы с iSCSI-хранилищем. Проверьте статус службы tgtd на сервере с хранилищем (должна быть запущена). Если проблема появляется при добавлении нового узла, то подключитесь по SSH на добавляемый узел и выполните команду:

virsh pool-list --all

Если в выводе команды присутствует строка вида iSCSI-UGLY_004 | не активен | yes, то можно попробовать удалить это хранилище и добавить узел ещё раз:

virsh pool-undefine iSCSI-UGLY_004

internal error Child process (/sbin/iscsiadm —mode discovery —type sendtargets —portal xxx.xxx.xxx.xxx:3260,1) status unexpected: exit status 255

VMmanager не может подключиться к серверу с iSCSI по 3260 порту. Причин может быть несколько:

1. SELinux должен быть отключён;
2. Нужный порт закрыт в файерволе.

Ошибка: «operation failed: Storage source conflict with pool: ‘…’ «

Эта ошибка может появляться на этапе создания хранилища типа dir или netfs. Означает, что на сервере уже существует хранилище данного типа, которое расположено в той же директории, что и создаваемое.

Решение: Найти и удалить существующее хранилище на всех узлах кластера:

virsh pool-list
virsh pool-dumpxml <pool-name>
virsh pool-destroy <pool-name>
virsh pool-undefine <pool-name>

Проблемы с RBD-хранилищем

Ошибка при добавлении хранилища на узел кластера

ceph auth get-or-create client.vmmgr mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=isptest' key for client.vmmgr exists but cap osd does not match

Решение: Зайдите на монитор и удалите пользователя client.vmmgr

ceph auth del client.vmmgr

Требуется сменить IP-адрес Ceph-монитора

Для создаваемых виртуальных машин:

Непосредственно на самом Ceph-мониторе IP-адрес может быть изменён вручную администратором Ceph-хранилища. В базе MySQL «vmmgr» на мастере VMmanager в таблице «metapool» необходимо заменить поле «srchostname» на новый узел. В таблице «rbdmonitor» убедитесь, что значение «metapool» соответствует значению «id» из таблицы «metapool». После правки базы удалите кэш:

rm -rf /usr/local/mgr5/var/.db.cache.vm*

Затем перезапустите панель управления:

Для существующих виртуальных машин выполните следующие команды:

sed -i 's/old_IP/new_IP/g' /etc/libvirt/qemu/*.xml
virsh define /etc/libvirt/qemu/*.xml

Проблемы с GlusterFS-хранилищем

При размещении двух хранилищ VMmanager в одном и том же томе и директории GlusterFS, но с разными типами (QCOW2 и RAW) невозможно выполнить перемещение виртуального диска между этими хранилищами

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

Импорт виртуальных машин из другого VMmanager или из другого сервера с libvirt напрямую в хранилище GlusterFS не работает, так как драйвер libvirt не поддерживает запись содержимого диска из потока

Для решения проблемы при определении параметров импорта укажите перенос в хранилище другого типа, а затем переместите диски импортированных машин в хранилище GlusterFS.

Проблемы с NFS-хранилищем

Проблема при создании виртуального диска

Если libvirt не может создать образ в хранилище, а в логе /var/log/syslog присутствуют подобные строки:

rpc.idmapd[706]: nss_getpwnam: name 'root@testers' does not map into domain 'ispsystem.net'.

Для решения проблемы в файле /etc/idmapd.conf на сервере и клиенте укажите корректное и одинаковое значение параметра «Domain». После редактирования  перезагрузите сервер и клиент, повторно добавьте хранилище в VMmanager.

Проблема при удалении данных из хранилища

Если диски, созданные в хранилище NFS, не удаляются с ошибкой: Ошибка libvirt при выполнении операции «VolDelete»: «cannot unlink file ‘/nfs-pool/volume’: Permission denied».

В /var/log/messages содержится подобное сообщение:

Sep 16 13:11:07 client nfsidmap[7340]: nss_getpwnam: name 'www-data@lan' does not map into domain 'localdomain'

Для решения проблемы в файле /etc/idmapd.conf на сервере и клиенте укажите корректное и одинаковое значение параметра «Domain». После редактирования  перезагрузите сервер и клиент, повторно добавьте хранилище в VMmanager.

Проблемы с виртуальными дисками

Ошибка libvirt при изменении размера диска

Ошибка libvirt при выполнении операции «Grow»: «unknown procedure: 260».

Эта ошибка чаще всего возникает из-за устаревшей версии libvirt. Обновите libvirt.

Ошибка: «Не удалось примонтировать диски виртуальной машины» при смене пароля

Проблема проявляется при попытке сменить пароль для виртуальной машины с файловой системой XFS внутри, размещённой на хост-сервере с ext4 и ядром версии менее 3.10. Для более точной диагностики запустите вручную команду:

guestmount -v -x -a <образ_диска> -i <путь к точке монтирования>

Если в выводе видны сообщения «mount: wrong fs type, bad option, bad superblock», то работа с этой машиной с помощью libguestfs невозможна. Причина — неполная поддержка гостевой xfs в ядре RHEL/CentOS 6. Подробнее см. virt-inspector can’t obtain info from rhel7.3 guest image on rhel6.9 host. К сожалению, по заявлениям разработчиков libguestfs, это поведение не может быть исправлено.

Проблемы с настройкой сети

IPv6 на Ubuntu 12.04

При добавлении узла кластера с IPv6-адресом выводится ошибка: «Невозможно подключиться к серверу XXX. Возможно, на сервере не работают службы ssh или libvirt-bin».

В логах:

Mar 13 13:26:09 [2157:0x95E700] virt TRACE ErrorCallback libvirt error code=38 message=Cannot recv data: ssh: external/libcrypto.so.1.0.0: no version information available (required by ssh) : Connection reset by peertname [2a01:230:2:3::3]: Name or service not known
Mar 13 13:26:09 [2157:0x95E700] virt DEBUG vir_host.cpp:70 Connect to qemu+ssh://[2a01:230:2:3::3]/system?keyfile=etc/ssh_id_rsa
Mar 13 13:26:09 [2157:0x95E700] err ERROR Error: Type: 'vir_connection'
Mar 13 13:26:09 [2157:0x95E700] virt TRACE Fail libvirt message: 'Cannot recv data: ssh: external/libcrypto.so.1.0.0: no version information available (required by ssh)

Эта ошибка является багом Ubuntu 12.04. Подробнее см. на launchpad.

Решение: Добавьте узел с IPv4 адресом.

Проблемы с виртуальными машинами

Проблемы при создании виртуальных машин

Ошибка при создании виртуальной машины: «ERROR: Exception 1: Insufficient RAM for VM creation», хотя в Swap ещё достаточно оперативной памяти

Свободная оперативная память — это free + cached. Swap не учитывается.

При попытке создания виртуальной машины возникает ошибка. Ошибка libvirt при выполнении операции «Start»: «internal error Process exited while reading console log output: qemu-kvm: -chardev pty,id=charserial0: Failed to create chardev».

Для решения проблемы выполните команду:

mount -n -t devpts -o remount,mode=0620,gid=5 devpts /dev/pts

При попытке создания виртуальной машины возникает ошибка. Ошибка libvirt при выполнении операции «Start»: «internal error cannot create rule since ebtables tool is missing»

Проверьте вывод команды lsmod |grep ebt. Если нет результата, значит в ядре нет поддержки ebtables. Пересоберите ядро либо скачайте другое и правкой grub.conf измените порядок загрузки.

Проблемы с установкой операционной системы

Установщик не может скачать файл ответов

Эта ошибка может быть обнаружена при подключении к виртуальной машине по VNC.

Причин может быть несколько:

1. IP-адрес виртуальной машины не может быть прикреплён к узлу кластера, на котором эта машина создана. Так бывает, например, если IP-адреса в дата-центре привязаны к MAC-адресам.
2. Не работает резолвер на виртуальной машине. В качестве резолвера используется первый резолвер с родительского сервера (файл /etc/resolv.conf).
3. VMmanager пытается предоставить файл ответов по внутреннему IP-адресу, который не доступен снаружи, а установщик скачивает файл ответов через внешнюю сеть.
4. В настройках ihttpd настроен redirect для http-соединений. IP-адрес, на который будет предоставлен файл ответов, VMmanager получает от ihttpd и узнать его можно с помощью команды:

/usr/local/mgr5/sbin/ihttpd

Не удаётся полностью получить preseed-файл при установке Debian

Для решения проблемы уберите опцию «nocunked» в файле конфигурации ihttpd (по умолчанию /usr/local/mgr5/etc/ihttpd.conf).

После этого перезапустите сервис ihttpd.

Проблемы с установкой Windows 2016 на виртуальной машине: В VNC наблюдается, что установка зависла на этапе загрузки

Встречается на серверах с версией QEMU 1.5, 0.12, 1.1.2.

Решение: при создании виртуальной машины включите режим эмуляции процессора host-passthrough. Для QEMU 2.6 установка этих шаблонов работает без необходимости изменения режима эмуляции, но иногда может потребоваться перезапуск службы libvirt (service libvirtd restart) (если было обновление системы).

При установке FreeBSD-amd64 на некоторых типах процессоров могут возникнуть проблемы:

• установка зависает;
• при подключении по VNC наблюдается ошибка:

• нет реакции на нажатие клавиш.

В таких случаях рекомендуем использовать образы FreeBSDx32. Также для решения проблемы помогает установка kernel-lt. Подробнее см. http://elrepo.org/tiki/kernel-lt.

Проблемы с доступностью виртуальных машин

Виртуальная машина недоступна после перезагрузки

Проверьте следующее:

1. Узлы кластера должны иметь связь с мастер-сервером.
2. Сервис vmwatch-master на мастер-сервере слушает нужный IP-адрес (IP-адрес определяет параметр VmwatchListenIp конфигурационного файла VMmanager). Если адрес не задан явно, используется адрес подключённого локального узла кластера. Если локального узла кластера нет, используется первый IP-адрес первого интерфейса. После изменения конфигурации запустите переконфигурирование сервисов из консоли с помощью команды:

/usr/local/mgr5/sbin/mgrctl -m vmmgr vmwatch.configure

Проблемы с миграцией виртуальных машин

Ошибка, возникающая при живой миграции: virt TRACE ErrorCallback libvirt error code=38 message=Unable to read from monitor: Connection reset by peer.

Такая ошибка возникает в некоторых конфигурациях с версией libvirt 0.9.12.3 при выборе типа сетевого интерфейса виртуальной машины «virtio». Для успешной живой миграции в настройках сетевого интерфейса виртуальной машины укажите модель эмулируемого сетевого устройства отличную от «virtio», например «e1000». Для изменения этого параметра у существующей виртуальной машины потребуется её перезагрузка.

Ошибка: «internal error: unable to execute QEMU command ‘migrate’: this feature or command is not currently supported».

Эта ошибка возникает при попытке мигрировать включённую виртуальную машину на кластере с CentOS-7. Это вызвано ошибкой QEMU на CentOS-7.

Возможные пути решения:

1. Отключите виртуальную машину и мигрируйте в выключенном состоянии.

2. Установите QEMU из репозитория centos-release-qemu-ev. Все команды выполняются в консоли каждого узла кластера от имени суперпользователя (root):

   yum install centos-release-qemu-ev
   yum update

   BASH

   Будут обновлены все установленные пакеты, для которых доступно обновление. В списке обновляемых пакетов должны присутствовать:

   libcacard-ev
   qemu-img-ev
   qemu-kvm-common-ev
   qemu-kvm-ev
   qemu-kvm-tools-ev

   BASH

   После обновления QEMU/KVM перезапустите виртуальные машины и сервис libvirtd.

Ошибка миграции и резервного копирования для виртуальных машин с диском qcow2 на серверах с версией QEMU 2.6

Не создаются резервные копии и не выполняется миграция виртуальных машин с виртуальным диском qcow2 и созданным внутри снапшотом во включённом состоянии. Версия QEMU 2.6, версия libvirt 2.0.

Эта проблема является ошибкой QEMU 2.6. Исправление вошло в QEMU 2.7.

Возможные пути решения:

1. Перезагрузите виртуальную машину. После перезагрузки можно продолжать работу;
2. Обновите QEMU до версии 2.7. Этот вариант не тестировался и не гарантируется его эффективность. Используйте на свой страх и риск.

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

Эта проблема является ошибкой QEMU. Подробнее см. https://bugs.launchpad.net/qemu/+bug/1449687 https://bugzilla.redhat.com/show_bug.cgi?id=1219541.

Исправить её можно только в QEMU. Варианта два: мигрировать выключенную машину или использовать qemu-img convert после миграции для уплотнения диска.

Ошибка: «Attempt to migrate guest to the same host».

Если миграция виртуальной машины не происходит и в логе var/migratevm.log появляется эта ошибка, то причины могут быть следующие:

1. На узлах кластера установлен один и тот же hostname. Решение: исправьте hostname. Отредактируйте файлы /etc/hostname и /etc/hosts, замените в них старое имя сервера на новое.

2. Узлы кластера имеют одинаковый product_uuid. Для проверки запустите команду на всех узлах кластера:

   cat /sys/class/dmi/id/product_uuid

   BASH

   Если значения совпадают, то проблема действительно в одинаковом product_uuid. Решение: на узлах кластера, у которых совпадают product_uuid, отредактируйте файл /etc/libvirt/libvirtd.conf. Раскомментируйте строку:

   #host_uuid = "00000000-0000-0000-0000-000000000000"

   BASH

   Значение host_uuid заполните самостоятельно. Значение не может состоять из всех одинаковых цифр. Для создания uuid можно использовать утилиту uuidgen. После этого необходимо перезапустить Libvirt.

Ошибка libvirt при выполнении операции «Define»: «unknown OS type hvm»

В большинстве случаев проблема решается перезагрузкой сервера. Также рекомендуется проверить состояние аппаратной виртуализации в BIOS:

modprobe kvm
egrep '^flags.*(vmx|svm)' /proc/cpuinfo

Если ответ пустой, то виртуализация отключена, включите.

Миграция виртуальной машины <наименование vm> невозможна: происходит процесс резервного копирования

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

Проблемы с импортом виртуальных машин

Ошибка ERROR Error: Type: ‘host_missing’ Object: Value: при импорте

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

Ошибка ERROR Error: Type: ‘xml’ Object: ‘parse_file’ Value: ‘/nfsshare/metainfo.xml’ при импорте

Для решения проблемы создайте файл /nfsshare/metainfo.xml. Содержимое файла можно скопировать из metainfo.xml любого шаблона ОС.

В статье «Диагностика проблем кластеров Windows Server 2008 R2», опубликованной в Windows IT Pro/RE № 10 за 2012 год, говорилось об устранении неполадок кластеров с обходом отказов. В частности, приводились рекомендации по извлечению информации, необходимой для диагностики проблем. На этот раз я хочу рассказать о расширенных средствах поиска и устранения неисправностей кластеров с обходом отказов в Windows Server 2012 и об их наиболее эффективном применении.

Знакомство с новыми каналами событий

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

Экран 1. Каналы событий кластеров с?обходом отказов в?Server 2012

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

* FailoverClustering

— Diagnostic. Это главный журнал, генерируемый всякий раз при запуске службы кластеров. Если функция ведения журнала выклю-чена, события могут выводиться в окно программы просмотра со-бытий Event Viewer. Данные журнала можно преобразовать в тек-стовый файл.

— Operational. Здесь регистрируются все информационные события в кластере, такие как перемещение групп, подключение к сети или переход в автономный режим.

— Performance-CSV. Этот канал используется для сбора информа-ции, касающейся функционирования общих томов кластера (CSV).

* FailoverClustering-Client

— Diagnostic. Этот канал используется для сбора данных журнала трассировки API Cluster. Данные журнала могут быть полезны для выявления причин ошибок при выполнении действий по созданию кластера (Create Cluster) и добавления узла в кластер (Add Node Cluster).

* FailoverClustering-CsvFlt (новый канал в Server 2012)

— Diagnostic. По этому каналу осуществляется сбор данных жур-нала трассировки драйвера фильтра CSV (CsvFlt.sys), установ-ленного только на узле координатора для CSV. Данные журнала позволяют выявить причины сбоев операций с метаданными и пе-ренаправленных операций ввода/вывода.

* FailoverClustering-CsvFs (новый канал в Server 2012)

— Diagnostic. Этот канал используется для сбора данных журнала трассировки драйвера файловой системы CSV (CsvFs.sys), ус-тановленного на всех узлах кластера. Данные журнала позволяют диагностировать проблемы прямых операций ввода/вывода.

* FailoverClustering-Manager

— Admin. На этом канале регистрируются ошибки, связанные с диалоговыми окнами и всплывающими предупреждениями, отобра-жаемыми в окне диспетчера кластеров.

* FailoverClustering-WMIProvider

— Admin. Этот канал используется для регистрации событий, связанных с поставщиком WMI кластеров с обходом отказов.

— Diagnostic. Журнал трассировки, связанный с поставщиком WMI кластера, который можно использовать для диагностики ошибок сценариев инструментария управления Windows (WMI) или прило-жений Microsoft System Center.

Использование канала FailoverClustering-Client/Diagnostic

При создании кластеров и присоединении узлов к кластеру нередко возникают проблемы, поэтому важно знать, как применять журнал FailoverClustering-Client/Diagnostic. По умолчанию этот канал выключен, и данные не регистрируются. Для включения канала щелкните на нем правой кнопкой и выберите Enable Log. После этого начинается сбор информации, относящейся к операциям присоединения и создания.

Предположим, что при включенном канале Diagnostic возникла проблема при создании кластера. Для просмотра собранных данных щелкните на канале правой кнопкой и выберите Disable Log. В журнале FailoverClustering-Client/Diagnostic можно увидеть следующее:

Event ID: 2
Level: Error
Description: CreateCluster (1883): Create cluster failed
with exception. Error = 8202, msg: Failed to create
cluster name CLUSTER on DC \DC.CONTOSO.COM. Error 8202.
Event ID: 2
Level: Error
Description: CreateClusterNameCOIfNotExists (6879): Failed
to create computer object CLUSTER on DC \DC.CONTOSO.COM
with OU ou=Clusters,dc=contoso,dc=com. Error 8202.

Для просмотра значения кода состояния ошибки (8202) восполь-зуемся командой Net.exe:

NET HELPMSG 8202

Команда возвращает сообщение The specified directory service attribute or value does not exist («Указанное значение или атрибут службы каталогов не существует»). Новые возможности кластеров с обходом отказов Server 2012 предполагают, что кластер создается в том же подразделении (OU), что и узлы. Для создания имени кластера активный пользователь должен иметь, как минимум, разрешения Read и Create Computer Objects. Если пользователь не обладает такими правами, имя кластера не соз-дается, и выдается ошибка такого типа.

Теперь предположим, что ошибка возникает при добавлении узла в существующий кластер. При просмотре журнала FailoverClustering-Client/Diagnostic видим следующее:

Event ID: 56
Level: Warning
Description: AsyncNotificationCallback (1463): ApiGetNotify
on hNotify=0x0000000021EBCDC0 returns 1 with rpc_error 0
Event ID: 2
Level: Error
Description: SCMStateNotify (837): Repost of
NotifyServiceStatusChange failed for node
'NodeX': status = 1168

Описание первого события указывает на ошибку вызова удаленной процедуры (RPC). В описании второго события содержится код состояния 1168. Чтобы узнать значение кода, снова воспользуемся командой Net.exe:

NET HELPMSG 1168

На этот раз команда возвращает сообщение Element not found («Элемент не найден»). При попытке присоединения узла кластеру необходимо установить соединение RPC с присоединяемым узлом. В данном случае кластер не находит узел.

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

Новые тесты мастера проверки настроек

Полезным инструментом диагностики ошибок является мастер про-верки настроек Validate a Configuration Wizard, который в Server 2012 дополнен новыми тестами кластеризации. В приведенном ниже списке новые тесты выделены жирным шрифтом.

* Hyper-V (только если установлена роль Hyper-V):

— List Hyper-V Virtual Machine Information;

— List Information About Servers Running Hyper-V;

— Validate Compatibility of Virtual Fibre Channel SANs for Hyper-V;

— Validate Firewall Rules for Hyper-V Replica Are Enabled;

— Validate Hyper-V Integration Services Version;

— Validate Hyper-V Memory Resource Pool Compatibility;

— Validate Hyper-V Network Resource Pool and Virtual Switch Compatibility;

— Validate Hyper-V Processor Pool Compatibility;

— Validate Hyper-V Role Installed;

— Validate Hyper-V Storage Resource Pool Compatibility;

— Validate Hyper-V Virtual Machine Network Configuration;

— Validate Hyper-V Virtual Machine Storage Configuration;

— Validate Matching Processor Manufacturers;

— Validate Network Listeners Are Running;

— Validate Replica Server Settings.

* Cluster Configuration (только для рабочего кластера):

— List Cluster Core Groups;

— List Cluster Network Information;

— List Cluster Resources;

— List Cluster Volumes;

— List Clustered Roles;

— Validate Quorum Configuration;

— Validate Resource Status;

— Validate Service Principal Name;

— Validate Volume Consistency;

* Inventory:

— Storage

—List Fibre Channel Host Bus Adapters

—List iSCSI Host Bus Adapters

—List SAS Host Bus Adapters

— System

—List BIOS Information

—List Environment Variables

—List Memory Information

—List Operating System Information

—List Plug and Play Devices

—List Running Processes

—List Services Information

—List Software Updates

—List System Drivers

—List System Information

—List Unsigned Drivers

* Network:

— List Network Binding Order;

— Validate Cluster Network Configuration;

— Validate IP Configuration;

— Validate Network Communications;

— Validate Windows Firewall Configuration.

* Storage:

— List Disks

— List Potential Cluster Disks

— Validate CSV Network Bindings

— Validate CSV Settings

— Validate Disk Access Latency

— Validate Disk Arbitration

— Validate Disk Failover

— Validate File System

— Validate Microsoft MPIO-Based Disks

— Validate Multiple Arbitration

— Validate SCSI device Vital Product Data (VPD)

— Validate SCSI-3 Persistent Reservation

— Validate Simultaneous Failover

— Validate Storage Spaces Persistent Reservation

* System Configuration:

— Validate Active Directory Configuration

— Validate All Drivers Signed

— Validate Memory Dump Settings

— Validate Operating System Edition

— Validate Operating System Installation Option

— Validate Operating System Version

— Validate Required Services

— Validate Same Processor Architecture

— Validate Service Pack Levels

— Validate Software Update Levels

Кроме тестов хранилища, все тесты можно запускать в любой мо-мент, так как они не нарушают работу кластера.

Использование мастера проверки настроек

Рассмотрим применение мастера проверки настроек Validate a Configuration Wizard. Для предыдущего примера с проблемой при добавлении узла предположим, что IP-адрес на DNS правильный, и соединение между узлами за пределами кластера может быть установлено. В этом случае можно запустить мастер проверки настроек.

При работе мастера возникает ошибка выполнения теста Net-work/Validate Windows Firewall Configuration. В ходе этого теста при анализе параметров брандмауэра Windows выясняется, что порт 3343, используемый кластером, не включен. Если порт отключен, вся идущая через него связь блокируется, и канал Diagnostic выдает ошибки.

Новый параметр команды Get-ClusterLog

Команда Get-ClusterLog из инструментария PowerShell позволяет преобразовать регистрируемые в журнале (например, Failover-Clustering/Diagnostics) события в текстовый файл. Текстовый файл именуется Cluster.log и помещается в папку C:WindowsClusterReports. По умолчанию, при выполнении команды для каждого узла создается свой файл Cluster.log. Изменить это можно с помощью перечисленных ниже параметров, например, UseLocalTime.

• -Cluster – имя кластера, к которому применяется команда. Этот параметр позволяет указать удаленный кластер. Если параметр опущен, то команда применяется к текущему кластеру.
• -Node – имя узла, к которому применяется команда. Эта команда используется, если файл Cluster.log генерируется только для конкретного узла.
• * -Destination – папка, в которую копируются файлы Cluster.log. При использовании этого параметра PowerShell не только создает файл Cluster.log в папке C:WindowsClusterReports для каждого узла, но и копирует все файлы журнала в заданную папку. Имя узла составляет часть имени файла, копируемого в целевую папку (например, Node1_Cluster.log, Node2_Cluster.log), что позволяет легко идентифицировать журналы.
• -TimeSpan. Этот параметр используется для создания журнала за заданный интервал времени в минутах (например, 5), что по-зволяет значительно уменьшить анализируемый файл. Этот параметр можно использовать при воспроизведении ошибки, то есть воспроизвести предполагаемую ошибку и сгенерировать журнал за последние 5 минут, чтобы проверить предположение.
• -UseLocalTime. Как уже говорилось, это новый параметр в Server 2012. Вся информация в кластере регистрируется во вре-менной зоне GMT. Например, в часовом поясе GMT-5, когда местное время составит 13:00 (1:00 p.m.), в журнале Cluster.log по умолчанию будет указано время 18:00 (6:00 p.m.). Это облегчает сопоставление времени, возвращаемого командой Get-ClusterLog, со временем в журнале Event Log.

Освоив создание журналов Cluster.log, следует научиться из-влекать из них нужную информацию.

Анализ файлов Cluster.log

Анализ файлов Cluster.log может отнимать много времени из-за большого объема информации. Ниже приведены рекомендации, которые помогут правильно приступить к делу.

Прежде всего, следует знать строение файла Cluster.log. Каждая запись имеет свою основную структуру. В частности, запись о подключении ресурса с данным IP-адресом, выглядит следующим образом:

00000bb8.000001d4::2013/05/15-01:13:24.852
INFO [RES] IP Address:
Online: Opened object handle for netinterface
353c85ee-7ea7-4b2a-927d-1538dffcdecd

Разобьем запись на отдельные фрагменты и поясним их смысл.

00000bb8 – шестнадцатеричное представление идентификатора процесса. Обычно процессом является Resource Host System (RHS). Сортируя или применяя поиск строк, включающих этот ID, можно узнать, какие ресурсы использует процесс. Это удобно в случае отладки дампа RHS при наличии нескольких файлов. Каждый дамп идентифицируется по ID, поэтому знание идентификатора гарантирует работу именно с нужным дампом процесса. Если есть полный дамп памяти, то в нем представлены несколько процессов RHS, каждый из которых идентифицируется по ID.

000001d4 – идентификатор цепочки в шестнадцатеричном пред-ставлении. Сортируя или применяя поиск строк, включающих этот ID, можно отследить действия цепочки. Используя этот ID для поиска, можно перейти прямо к нужной цепочке – например, при отладке процесса RHS, имеющего 100 цепочек.

2013/05/15-01:13:24.852 – дата и время в зоне GMT (если журнал генерируется без использования параметра UseLocalTime). В часовом поясе GMT-5 данное время соответствует местному времени 14 мая 2013 г., 8:13 p.m. Время детализируется с точностью до миллисекунд.

INFO – уровень записи: INFO (информация), WARN (предупреждение), ERR (ошибка) или DBG (отладка). Есть и другие, но в большинстве случаев используются именно эти уровни. Строка с ERR обычно означает проблему с ресурсом. Открыв файл Cluster.log, можно выполнить поиск по конкретному уровню, чтобы быстрее локализовать проблемный участок.

[RES] IP Address – тип ресурса. В журнале каждый ресурс иден-тифицируется по типу. Располагая этой информацией, можно быстро отследить проблемный подключающийся ресурс, если в одно и то же время подключаются ресурсы разных типов.

. Это – фактический ресурс, отображаемый в диспетчере кластеров.

Online: Opened object handle for netinterface 353c85ee-7ea7-4b2a-927d-1538dffcdecd – описание того, что происходит с ре-сурсом. В данном случае ресурс открывает дескриптор доступа к драйверу сетевого адаптера для привязки к нему IP-адреса. Если здесь возникает сбой, то это может указывать на проблему с драйвером сетевого адаптера, либо на неисправность самого се-тевого адаптера. Следующим шагом будет анализ записей в журнале системных событий и поиск событий, относящихся к сети (сбой сети или сетевого адаптера). Выявить причину проблемы помогают описания. Особенно полезны описания последних действий перед наступлением отказа.

Поиск в файлах Cluster.log

Анализируя файлы Cluster.log, стоит задействовать поиск по ключевым словам. В таблице приведен список ключевых слов, ко-торые я использую для поиска ресурсов.

Ключевые слова следует вводить в точности так, как они ото-бражены, то есть с двумя дефисами и знаком «больше» (—>) и без пробелов.

Ключевые слова также позволяют быстро определить, сколько времени требуется ресурсу для отключения или подключения. Предположим, например, что подключение некоторой группы занимает больше времени, чем обычно. В этом случае сначала можно применить поиск по —>OfflinePending, а затем по —>Offline для всех ресурсов группы. Другой вариант: сначала поиск по —>OnlinePending, а затем по —>Online. Для каждого ресурса суммируем значения времени, чтобы узнать, сколько времени ему требуется на подключение. Проделав это для каждого ресурса, сравним суммарные значения, чтобы узнать, какому ресурсу тре-буется наибольшее время. Затем можно проанализировать записи в журнале Cluster.log, чтобы определить причину. Например, если подключение группы занимает в целом 30 секунд на одном узле и три минуты на другом, то следует сгенерировать файлы Cluster.log для обоих узлов и сравнить их.

Для групп можно использовать те же ключевые слова, но за сим-волом «больше» должен следовать пробел. Например, при анализе отключения сначала используется —> OfflinePending, а затем —> Offline. Различается еще лишь запись при анализе отказа: для группы используется —> Failed, а для отказа —>ProcessingFailure.

Сведение информации воедино

Сведение представленной информации воедино мы рассмотрим на примере кластера, состоящего из двух узлов, обслуживаемых не-сколькими файловыми серверами, использующих разные сети и сеть хранения данных SAN с подключением по Fibre Channel. Для сетей используются следующие установки:

• Cluster Network 1 = IP scheme 192.168.0.0/24
• Cluster Network 2 = IP scheme 1.0.0.0/8
• Cluster Network 3 = IP scheme 172.168.0.0/16

В сетевых подключениях узлов сетевые адаптеры идентифицируются следующим образом:

• CORPNET = IP scheme 192.168.0.0/24
• MGMT = IP scheme 1.0.0.0/8
• BACKUP = IP scheme 172.168.0.0/16

Сервер FILESERVER1 использует сеть Cluster Network 1, функ-ционирующую на узле NODE1, а сервер FILESERVER2 – сеть Cluster Network 2 на узле NODE2.

Предположим, ночью произошел сбой, и группа файлового сервера FILESERVER2 переместилась с узла NODE2 на узел NODE1. Требуется выяснить причину отказа.

В диспетчере кластеров щелкаем правой кнопкой на группе FI-LESERVER2 и выбираем Show Critical Events («Показать критические события»). На экран выдаются следующие события:

Event ID: 1069

Description: Cluster Resource ‘IP Address 1.1.1.1’ of

type ‘IP Address’ in Clustered Role ‘FILESERVER’ failed.

Event ID: 1205

Description: The Cluster service failed to bring clustered

service or application ‘FILESERVER2’ completely online or

offline. One or more resources may be in a failed state.

Первое событие указывает на сбой ресурса с IP-адресом 1.1.1.1. Щелкаем правой кнопкой на этом ресурсе в диспетчере кластеров и выбираем Show Critical Events («Показать критические события»). На экран выдаются следующие события:

Event ID: 1077

Description: Health check for IP Interface

‘IP Address 1.1.1.1’ (address 1.1.1.1) failed (status is

1168). Run the Validate a Configuration wizard to ensure

that the network adapter is functioning properly.

Event ID: 1069

Description: Cluster Resource ‘IP Address 1.1.1.1’ of

type ‘IP Address’ in Clustered Role ‘FILESERVER’ failed.

На основании описания первого события (1077) воспользуемся мастером проверки настроек Validate a Configuration Wizard. Запускаем только тест Network/Validate Network Communication для проверки всех адаптеров и сетевых путей между узлами.

После выполнения теста Network/Validate Network Communication анализируем отчет. В отчете нет ни ошибок, ни предупреждений, поэтому откладываем его в сторону.

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

Event ID: 1153

Description: The Cluster service is attempting to failover

the clustered service or application ‘FILESERVER2’ from

node ‘NODE2’ to node ‘NODE1’

На основании этого описания переходим к каналу FailoverClus-tering/Diagnostics, где имеются следующие события:

Event ID: 2051

Description: [RCM] rcm::RcmResource::HandleFailure:

(IP Address 1.1.1.1)

Event ID: 2051

Description: [RES] IP Address:

Failed to query properties of adapter id

F3EDD1C8-6984-82BC-498806B841CA, status 87.

Генерируем файл Cluster.log для этого узла, в журнале выполняем поиск >ProcessingFailure и находим следующие записи:

[RES] IP Address: IP Interface

3600A8C0 failed LooksAlive check, status 1168.

[RES] IP Address: IP Interface

3600A8C0 failed IsAlive check, status 1168.

[RHS] Resource IP Address 1.1.1.1 has indicated failure.

[RCM] Res IP Address 1.1.1.1: Online -> ProcessingFailure

( State Unknown )

[RCM] TransitionToState( IP Address 1.1.1.1)

Online—>ProcessingFailure.

Далее в Cluster.log находим записи, в которых говорится о том, что группа была перемещена. Это указывает на то, что записи, найденные в результате поиска —>ProcessingFailure, имеют отношение к проблеме, обусловившей перемещение группы. По ошибкам, обозначенным в этих записях, мы точно знаем, что произошел сбой ресурса с данным IP-адресом. Чтобы выяснить значение кода статуса ошибки, воспользуемся командой Net.exe:

NET HELPMSG 1168

Команда возвращает сообщение Element not found («Элемент не найден»). После более тщательного изучения записей видим, что проблема может быть связана с сетевым адаптером. Несколько аппаратных тестов применительно к адаптерам выявляют неисправный адаптер, который даже не виден в Windows. Проблему решает замена неисправного адаптера.

Однако остается вопрос, почему в результатах теста Net-work/Validate Network Communication отсутствуют ошибки. Этот тест предусматривает проверку всех сетевых адаптеров, от одного узла к другому, независимо от их местонахождения (в одной или в разных сетях). Переходы между узлами осуществляются по всевозможным известным маршрутам. Поэтому существуют ожидаемые отказы, обусловленные особенностями организации кабельных соединений в сетях между узлами или разбиения сетей на сегменты.

При более тщательном изучении результатов теста обращаем вни-мание на информацию, представленную на экране 2.

Экран 2. Результаты теста Network/Validate Network Communication

Мы видим, что узел NODE1 не имеет сетевого адаптера, опреде-ляемого как MGMT. По сути, это означает то же, что и события, то есть что у NODE1 – две сети, а у NODE2 – три. Следовательно, недостаточно просто просматривать ошибки и предупреждения в верхней части отчета. Необходимо также изучать результаты теста.

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

Таблица. Ключевые слова, используемые для поиска ресурсов

Ключевое слово Описание

—>OnlinePending Это ключевое слово появляется в журнале, когда в диспетчере кластеров отображается состояние «Ожидание подключения» (Online Pending) для ресурса. Именно здесь должен начинаться поиск, если требуется отследить подключение ресурса

—>OfflinePending Это ключевое слово появляется в журнале, когда в диспетчере кластеров отображается состояние «Ожидание отключения» (Offline Pending) для ресурса. Именно здесь должен начинаться поиск, если требуется отследить отключение ресурса

—>Offline Это ключевое слово появляется в журнале, когда в диспетчере кластеров отображается состояние «Автономная работа» (Offline) для ресурса. Если отслеживается ресурс, то смотреть дальше необходимости нет. Если этот ресурс зависит от другого ресурса, то тот другой ресурс мог начать процесс отключения первым

—>Online Это ключевое слово появляется в журнале, когда в диспетчере кластеров отображается состояние «В сети» (Online) для ресурса. Если отслеживается ресурс, то смотреть дальше нет необходимости. Если от этого ресурса зависит другой ресурс, то тот другой ресурс не начнет свой процесс подключения к сети, пока не завершен этот процесс

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