Устраняем ошибку Component metadata health (VSAN)
Иногда в VMware vSphere возникает ошибка типа:
Virtual SAN Health Alarm "Component metadata health"
Которая сопровождается еще такими ошибками:
Virtual SAN Health Alarm "Physical disk"
Virtual SAN Health Service Alarm for Overall Health Summary
Заходим в vSphere WEB-клиент, становимся на кластер, справа в горизонтальном меню выбираем Virtual SAN, затем слева выбираем Health и видим следующую картину:
Становимся курсором на нашу ошибку Component metadata health и снизу видим на каких хостах у нас ошибка и uuid компонента. Запоминаем эти uuid, хотя бы один.
Заметьте, что первый и последний октеты у них одинаковые, а середина отличается.
Теперь подключаемся по SSH к нашему vCenrter Server Apliance.
Видим приглашение:
Command>Запускаем Ruby vSphere Console и подключаемся к vCenter используя логин Administrator@vsphere.local
Command> rvcInstall the "ffi" gem for better tab completion.Host to connect to (user@host): Administrator@vsphere.local@localhostpassword:0 /1 localhost/>Используя команды ls и cd проходим до computers
/localhost/DC01/computers/>И тут выполняем поиск по uuid который видели в клиенте vSphere
/localhost/DC01/computers> vsan.cmmds_find 0 -u 0f9b0458-d8da-395f-7f78-9457a5537ac4+---+-------------+--------------------------------------+--------------------+---------+-----------------------------------------------------------+| # | Type | UUID | Owner | Health | Content |+---+-------------+--------------------------------------+--------------------+---------+-----------------------------------------------------------+| 1 | LSOM_OBJECT | 0f9b0458-d8da-395f-7f78-9457a5537ac4 | cl01esx01.domain.ru| Healthy | {"diskUuid"=>"52895cc8-effb-8122-4618-bdedbf3851a1", || | | | | | "compositeUuid"=>"0f9b0458-00f0-9c5e-acea-9457a5537ac4", || | | | | | "capacityUsed"=>106019422208, || | | | | | "physCapacityUsed"=>106019422208, || | | | | | "dedupUniquenessMetric"=>0, || | | | | | "formatVersion"=>1} |+---+-------------+--------------------------------------+--------------------+---------+-----------------------------------------------------------+Тут видим compositeUuid, далее по нему смотрим инфу такой командой:
/localhost/DC01/computers> vsan.object_info 0 0f9b0458-00f0-9c5e-acea-9457a5537ac42017-04-29 12:16:39 +0300: Fetching VSAN disk info from cl01esx01.domain.ru (may take a moment) ...2017-04-29 12:16:39 +0300: Fetching VSAN disk info from cl01esx03.domain.ru (may take a moment) ...2017-04-29 12:16:39 +0300: Fetching VSAN disk info from cl01esx04.domain.ru (may take a moment) ...2017-04-29 12:16:39 +0300: Fetching VSAN disk info from cl01esx02.domain.ru (may take a moment) ...2017-04-29 12:16:42 +0300: Done fetching VSAN disk infosDOM Object: 0f9b0458-00f0-9c5e-acea-9457a5537ac4 (v3, owner: cl01esx02.domain.ru, policy: spbmProfileGenerationNumber = 11, hostFailuresToTolerate = 1, spbmProfileId = d8ff7779-8393-49cc-a626-bedbddb3ce3d, proportionalCapacity = 10, cacheReservation = 0, stripeWidth = 1) RAID_1 Component: 0f9b0458-a01d-375f-6cf5-9457a5537ac4 (state: ACTIVE (5), host: cl01esx04.domain.ru, md: naa.5000c50095ca6d0b, ssd: naa.55cd2e404c1aa512, votes: 1, usage: 98.7 GB) Component: 0f9b0458-d8da-395f-7f78-9457a5537ac4 (state: ACTIVE (5), host: cl01esx01.domain.ru, md: naa.5000c50095ca1417, ssd: naa.55cd2e404c1a97bb, votes: 1, usage: 98.7 GB) Witness: 0f9b0458-4818-3c5f-6fea-9457a5537ac4 (state: ACTIVE (5), host: cl01esx03.domain.ru, md: naa.5000c50095ca6b33, ssd: naa.55cd2e404c1a8789, votes: 1, usage: 0.0 GB) Extended attributes: Address space: 107374182400B (100.00 GB) Object class: vdisk Object path: /vmfs/volumes/vsan:42544a60db7cf3f1-2ba3635cc5fbd93c/84470158-4884-c505-0e21-9457a5537ac4/Postgresql-1 (7e575060-09d6-45f1-84a9-362f679165c4).vmdk Object capabilities: NONEА вот и проблемный объект, мигрируем этот vmdk на соседний датастор. После чего в vCenter в той же вкладке жмем кнопку "Retest", выдыхаем :-)
После прохождения теста мигрируем vmdk обратно. Если Вам не помогла эта статья, то возможно у вас ситуация хуже, читайте это