Buenos dias!
Gracias por visitar virtualcloudblog.com; hoy escribo este post en Español para ayudar a la comunidad de Hispanohablantes. El Post de hoy esta relaccionado con vSAN y los objetos “inaccessible”. Usar estos comandos bajo vuestra responsabilidad, en caso de duda abrir un caso de soporte con VMWare.
Haciendo trabajo proactivo en mi lab he detectado que hay 10 objetos inaccesibles en vSAN! Antes de nada debemos de concectarnos a nuestra vSAN. Para esto visitar
1. /localhost/arango-lab/computers> vsan.check_state 0
1 2 3 4 5 6 7 8 9 10 11 12 |
2019-02-08 09:11:07 +0000: Step 1: Check for inaccessible vSAN objects Detected 10 objects to be inaccessible Detected 74161859-512b-8913-3345-ecf4bbe4a98c on 10.10.10.5 to be inaccessible Detected 1eedae57-a5cc-9e33-790e-ecf4bbe4a998 on 10.10.10.5 to be inaccessible Detected 84bd4e58-2977-b641-b14f-ecf4bbe4a98c on 10.10.10.5 to be inaccessible Detected 5e1c1859-64ae-f458-31c0-ecf4bbe4a98c on 10.10.10.5 to be inaccessible Detected a116c458-13b4-8e5a-cc61-ecf4bbe4a98c on 10.10.10.5 to be inaccessible Detected 2074ea57-4b81-0f70-e5cd-ecf4bbe4a75c on 10.10.10.5 to be inaccessible Detected 29170f59-fecf-5c71-73c1-ecf4bbe4acbc on 10.10.10.5 to be inaccessible Detected e789ca58-a0d3-e1cf-741e-ecf4bbe4a98c on 10.10.10.5 to be inaccessible Detected d8139a57-10df-87da-d22a-ecf4bbe4a75c on 10.10.10.5 to be inaccessible Detected 6656cf58-2718-27f2-4874-ecf4bbe4a98c on 10.10.10.5 to be inaccessible |
2. Lo primero que se ha hecho es : vsan.check_state -r 0, pero no ha solucionado el problema con dichos objetos.
Con -r, “refrescamos” nuestra vSAN
1 2 3 4 5 6 7 8 9 10 11 |
2019-02-08 09:14:07 +0000 : Step 1b: Check for inaccessible vSAN objects, again Detected 74161859-512b-8913-3345-ecf4bbe4a98c is still inaccessible Detected 1eedae57-a5cc-9e33-790e-ecf4bbe4a998 is still inaccessible Detected 84bd4e58-2977-b641-b14f-ecf4bbe4a98c is still inaccessible Detected 5e1c1859-64ae-f458-31c0-ecf4bbe4a98c is still inaccessible Detected a116c458-13b4-8e5a-cc61-ecf4bbe4a98c is still inaccessible Detected 2074ea57-4b81-0f70-e5cd-ecf4bbe4a75c is still inaccessible Detected 29170f59-fecf-5c71-73c1-ecf4bbe4acbc is still inaccessible Detected e789ca58-a0d3-e1cf-741e-ecf4bbe4a98c is still inaccessible Detected d8139a57-10df-87da-d22a-ecf4bbe4a75c is still inaccessible Detected 6656cf58-2718-27f2-4874-ecf4bbe4a98c is still inaccessible |
3. /usr/lib/vmware/osfs/bin/objtool getAttr -u 74161859-512b-8913-3345-ecf4bbe4a98c.
Pero que es? 74161859-512b-8913-3345-ecf4bbe4a98c. Desde RVC lanzamos el comando
1 2 3 4 5 |
2019-02-0809:46:15.286Z OBJLIB-VSANOBJ: VsanObjReadPolicy: failed to readPolicy for object: Input/output error (327682). 2019-02-08T09:46:15.286Z OBJLIB-VSANOBJ: VsanObjGetExtParams: Could not read policy for 'vsan://74161859-512b-8913-3345-ecf4bbe4a98c'. 2019-02-08T09:46:15.286Z OBJLIB-LIB: ObjLib_GetExtParams : Failed to get ext params : Input/output error (327684) Failed to get object attributes : Input/output error 327684. object getAttr error: Failure |
4. cmmds-tool find -t DOM_OBJECT -u 74161859-512b-8913-3345-ecf4bbe4a98c -f python,
Desde uno de los host de nuetra vSAN, SSH y lanzamos el comando para averiguar que es: 74161859-512b-8913-3345-ecf4bbe4a98c . Y aquí viene la parte interesante del capítulo de hoy en vSAN!
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
cmmds-tool find -t DOM_OBJECT -u 74161859-512b-8913-3345-ecf4bbe4a98c -f python [ { "uuid": "74161859-512b-8913-3345-ecf4bbe4a98c", "owner": "57a47657-61d5-ea58-2937-ecf4bbe4a998", "health": "Healthy", "revision": "1", "type": "DOM_OBJECT", "flag": "2", "md5sum": "7f3e420e88926279a4c93a01caa1b049", "valueLen": "1272", "content": "{\"type\": \"Configuration\", \"attributes\": {\"CSN\": 31, \"addressSpace\": 25769803776, \"compositeUuid\": \"74161859-512b-8913-3345-ecf4bbe4a98c\"}, \"child-1\": {\"type\": \"RAID_1\", \"attributes\": {}, \"child-1\": {\"type\": \"Component\", \"attributes\": {\"capacity\": 25769803776, \"addressSpace\": 25769803776, \"componentState\": 5, \"componentStateTS\": 1494830801, \"staleLsn\": 0, \"staleCsn\": 0, \"bytesToSync\": 0, \"recoveryETA\": 0, \"faultDomainId\": \"57a47657-61d5-ea58-2937-ecf4bbe4a998\"}, \"componentUuid\": \"56001959-7c89-f66f-fd73-ecf4bbe4a75c\", \"diskUuid\": \"5212864c-e8cc-58f4-a933-110fa3c37ddc\"}, \"child-2\": {\"type\": \"Component\", \"attributes\": {\"capacity\": 25769803776, \"addressSpace\": 25769803776, \"componentState\": 6, \"componentStateTS\": 1518081375, \"staleLsn\": 0, \"bytesToSync\": 0, \"recoveryETA\": 0, \"faultDomainId\": \"56253e75-7f59-ee1d-baf0-ecf4bbe4acbc\"}, \"componentUuid\": \"c82d1959-4285-44d7-52e2-ecf4bbe4a75c\", \"diskUuid\": \"52f6773a-5000-56b9-737b-d89ebe732f12\"}}, \"child-2\": {\"type\": \"Witness\", \"attributes\": {\"componentState\": 6, \"componentStateTS\": 1518081375, \"isWitness\": 1, \"faultDomainId\": \"56252b4b-c40b-20fd-98aa-ecf4bbe4a75c\"}, \"componentUuid\": \"55311959-8c48-176e-ddc9-ecf4bbe4a75c\", \"diskUuid\": \"524acdec-6904-3226-50d2-84ac8ba6f019\"}}","errorStr": "(null)"}, ] |
Es comento:
\”componentState\”: 5 significa que el componente esta ACTIVO
\”faultDomainId\”: \”57a47657-61d5-ea58-2937-ecf4bbe4a998\”}, significa que a que host pertenece el componente ACTIVO.
\”componentUuid\”: \”56001959-7c89-f66f-fd73-ecf4bbe4a75c\”, significa cual es nuestro objeto nuestra vSAN!,
\”componentState\”: 6, significa que el componente está ABSENT.
5. /usr/lib/vmware/osfs/bin/objtool getAttr -u 56001959-7c89-f66f-fd73-ecf4bbe4a75c -c –bypassDom.
Como ya sabemos cuál es el componente activo (que hemos sacado con el comando anterior), corremos el comando getAttr
1 2 3 4 5 6 7 8 9 10 11 |
Object Attributes -- UUID:56001959-7c89-f66f-fd73-ecf4bbe4a75c Object type:vsan Object size:25769803776 User friendly name:(null) HA metadata:(null) Allocation type:Zeroed thick Policy:((\"proportionalCapacity\" i100) (\"hostFailuresToTolerate\" i1) (\"forceProvisioning\" i1)) Object class: vmswap Object path: /vmfs/volumes/vsan:52fc70d2d4ee54cb-b5faa5cc606a1c13/dcbec957-fbee-3fdd-33f3-ecf4bbe4a75c/VM-1-e3de853e.vswp |
BIEN!!!! Ya sabemos qué y dónde está nuestro objeto inaccesible, es un objecto vswp (últimas dos lineas)
6. vsan.purge_inaccessible_vswp_objects .
Ahora desde RVC, debemos correr este comando para purgar los inaccessible_vswp.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
2019-02-08 10:06:04 +0000: Collecting all inaccessible vSAN objects... 2018-02-08 10:06:04 +0000: Found 10 inaccessbile objects. 2019-02-08 10:06:04 +0000: Selecting vswp objects from inaccessible objects by checking their extended attributes... Following inaccessabile objects will be skipped for further processing due to errors in querying extended attributes: +--------------------------------------+------------------------------------+ | Object UUID | Error | +--------------------------------------+------------------------------------+ | 74161859-512b-8913-3345-ecf4bbe4a98c | Error getting extended attributes. | | 1eedae57-a5cc-9e33-790e-ecf4bbe4a998 | Error getting extended attributes. | | 84bd4e58-2977-b641-b14f-ecf4bbe4a98c | Error getting extended attributes. | | 5e1c1859-64ae-f458-31c0-ecf4bbe4a98c | Error getting extended attributes. | | a116c458-13b4-8e5a-cc61-ecf4bbe4a98c | Error getting extended attributes. | | 2074ea57-4b81-0f70-e5cd-ecf4bbe4a75c | Error getting extended attributes. | | 29170f59-fecf-5c71-73c1-ecf4bbe4acbc | Error getting extended attributes. | | e789ca58-a0d3-e1cf-741e-ecf4bbe4a98c | Error getting extended attributes. | | d8139a57-10df-87da-d22a-ecf4bbe4a75c | Error getting extended attributes. | | 6656cf58-2718-27f2-4874-ecf4bbe4a98c | Error getting extended attributes. | +--------------------------------------+------------------------------------+ 2019-02-08 10:06:05 +0000: Found 0 inaccessible vswp objects. |
Pero el comando NO nos devuelve nada :(, asi que tendremos que hacer “ingeniería inversa”.
7. cat vmfs/volumes/vsan:52fc70d2d4ee54cb-b5faa5cc606a1c13/dcbec957-fbee-3fdd-33f3-ecf4bbe4a75c/VM-1-e3de853e.vswp
Desde un ESXi de nuestro cluster de VSAN,
1 2 3 4 5 |
cat vmfs/volumes/vsan:52fc70d2d4ee54cb-b5faa5cc606a1c13/dcbec957-fbee-3fdd-33f3-ecf4bbe4a75c/ceapp1717-e3de853e.vswp # Object DescriptorFile version = "1" objectID = "vsan://a5721959-1486-2042-673e-ecf4bbe4a98c" swapObj.lock = "/vmfs/volumes/vsan:52fc70d2d4ee54cb-b5faa5cc606a1c13/dcbec957-fbee-3fdd-33f3-ecf4bbe4a75c/VM-1-e3de853e.vswp.lck" |
De este comando nos interesa objectID = “vsan://a5721959-1486-2042-673e-ecf4bbe4a98c” es el nuevo DOMObj!!!
8. vsan.object_info 0 a5721959-1486-2042-673e-ecf4bbe4a98c
De esta forma sabemos que el objecto inaccesible NO esta en uso (y lo podemos borrar sin problemas). Desde RVC, ya que como hemos visto en el punto anterior, el DOMObj es diferente, ejecutamos el punto 8
1 2 3 4 5 6 7 8 9 10 11 12 |
RAID_1 Component: a1a61959-b0ca-2d83-5b03-ecf4bbe4acbc (state: ACTIVE (5), host: 10.10.10.3, md: naa.5000cca0310f3860, ssd: naa.55cd2e404c0da9a4, votes: 1, usage: 24.0 GB, proxy component: false) Component: a266a559-af6e-4d55-09f3-ecf4bbe4a998 (state: ACTIVE (5), host: 10.10.10.4, md: naa.5000c5009fdda74f, ssd: naa.5002538c4069cfe4, votes: 1, usage: 24.0 GB, proxy component: false) Witness: 01baa559-9f70-8059-1d67-ecf4bbe4a998 (state: ACTIVE (5), host: 10.10.10.5, md: naa.5000cca0310ee244, ssd: naa.55cd2e404c0d311f, votes: 1, usage: 0.0 GB, proxy component: false) Extended attributes: Address space: 25769803776B (24.00 GB) Object class: vmswap Object path: /vmfs/volumes/vsan:52fc70d2d4ee54cb-b5faa5cc606a1c13/dcbec957-fbee-3fdd-33f3-ecf4bbe4a75c/VM-1-e3de853e.vswp Object capabilities: |
9. /usr/lib/vmware/osfs/bin/objtool delete -u a5721959-1486-2042-673e-ecf4bbe4a98c -f -v 10
El Viejo DOM (74161859-512b-8913-3345-ecf4bbe4a98c ) hay que borrarlo a mano!!, por lo que desde unos de nuestros ESXi ejecutar el comando del punto 9.
Por favor, usar estos comandos bajo vuestra responsabilidad, en caso de duda abrir un caso de soporte con VMWare.