Dell Unity : Comment trouver et télécharger des fichiers de vidage à partir d’un système Unity (corrigible par l’utilisateur)

À partir d’Unisphere 

Disponible uniquement pour Unity OE 4.2.0.9392909 et versions ultérieures).
Connectez-vous à Unisphere et accédez à Service > Downloads > Core Dump.
Ce menu facilite la récupération des fichiers de vidage mémoire à partir de l’un ou l’autre des processeurs de stockage, quel que soit le processeur de stockage principal à ce moment-là.
Une fois les fichiers téléchargés à partir de la baie, chargez-les dans la demande de service. Si le fichier est trop volumineux, demandez un emplacement FTP au représentant du support. 
 

CLI ou SSH

1. Accédez à Unity via SSH et connectez-vous en tant qu’utilisateur de service.
2. Prenez note du processeur de stockage (SP) sur lequel vous êtes. Celui auquel vous êtes automatiquement connecté est le processeur de stockage principal. Si vous n’êtes pas sûr, exécutez pgrep ECOM. Le processeur de stockage principal doit renvoyer un numéro d’ID de processus, contrairement au secondaire, qui ne renvoie rien. Consultez la section Informations supplémentaires pour en voir un exemple.
3. Si votre fichier de vidage se trouve sur le processeur de stockage principal, exécutez les commandes suivantes :
   • svc_dc -lcd pour obtenir la liste des fichiers de vidage de cœur disponibles sur le processeur de stockage local. Chaque résultat correspond à un fichier de vidage. Recherchez celui dont vous avez besoin (la date et l’heure se trouvent dans le nom du fichier).
   • svc_dc -dc /home/service/user <dump file name> pour compresser et copier le fichier (il y a un espace entre /home/service/user et le nom de dump).

4. Si votre fichier de vidage se trouve sur le processeur de stockage secondaire, connectez-vous à celui-ci (homologue SSH) et à partir de là :
   • svc_dc -lcd pour répertorier les fichiers de vidage de cœur disponibles sur le processeur de stockage local.
   • svc_dc -dc peer /home/service/user <dump file name> (Il y a un espace entre /home/service/user et le nom du dump.) Cette commande compresse le dossier de vidage et le déplace vers /home/service/user sur le processeur de stockage homologue. Dans ce cas, nous copions le fichier sur le processeur de stockage principal, à partir duquel nous pouvons l’obtenir avec WinSCP.
   • Dans la syntaxe de la commande, nous spécifions la cible avec « peer », qui déplace le fichier compressé vers le processeur de stockage homologue. Cette commande peut également déplacer le fichier résultant vers des systèmes distants via SSH. Pour de plus amples informations, voir svc_dc -h.
5. Ouvrez un client SFTP (tel que WinSCP) et connectez-vous à l’adresse IP de gestion en tant que service. (Cela vous connecte au processeur de stockage principal uniquement.)
6. Accédez au répertoire /home/service/user (ou /cores/service/user qui est au même endroit), téléchargez le fichier de vidage que vous avez créé à l’étape 3 ou 4, puis ajoutez-le à la demande de service. Si le fichier est trop volumineux, demandez un emplacement FTP au représentant du support. 
7. Une fois téléchargés, supprimez les fichiers de vidage créés de /home/service/user et les fichiers d’origine de /EMC/backend/service/data_collection/cores/ (il faut être un utilisateur root pour y accéder - support technique Dell uniquement).

Si vous avez besoin d’assistance, contactez le support technique Dell ou votre représentant de services agréé en lui communiquant l’identifiant de cet article.
 

Compression et copie manuelle des fichiers de vidage de cœur

Si vous n’êtes pas familiarisé avec la commande « tar » de Linux, n’utilisez pas cette méthode, car elle risque de corrompre les fichiers de vidage ou de provoquer des problèmes supplémentaires (comme le redémarrage d’un processeur de stockage) si les fichiers sont créés à des emplacements incorrects. Cette méthode ne doit être utilisée qu’en dernier recours si tout le reste a échoué et uniquement par les utilisateurs qui maîtrisent Linux.

Si la méthode ci-dessus a été comprise et que tout le reste a échoué, le répertoire du fichier de vidage peut également être compressé manuellement. Les vidages Unity se trouvent dans /EMC/backend/service/data_collection/cores/ sur chaque SP.

Compressez le répertoire de vidage dans un fichier, tar -zcvf /home/service/user <destination_filename.tar.gz><dump_directory_name>.
Si vous effectuez cette opération sur une version d’Unity OE antérieure à 4.5, utilisez /home/service, car l’utilisateur du répertoire de niveau suivant n’a été créé que depuis Unity OE 4.5.

Le fichier .tar.gz qui en résulte se trouve dans le répertoire /home/service/user (ou /cores/service/user, qui constitue le même emplacement).
Sur une version d’Unity OE antérieure à 4.5, le fichier doit être créé dans /cores/service, comme décrit ci-dessus.

N’utilisez pas d’autres répertoires cibles ! Vous pouvez provoquer de graves problèmes système.

Si vous avez besoin de journaux utilisant cette méthode à partir du processeur de stockage secondaire, consultez l’article 22501 de la base de connaissances Dell : Dell Unity : Téléchargement de fichiers depuis le processeur de stockage secondaire à l’aide du processeur de stockage principal (corrigible par l’utilisateur) sur la façon d’obtenir des fichiers à partir du processeur de stockage secondaire avec SCP.

Une fois téléchargés à partir de la matrice, supprimez tous les fichiers de vidage des emplacements suivants sur les deux processeurs de stockage.
/cores/service/user ou /home/service/user (/home/service ou /cores/service sur Unity OE en version antérieure à 4.5)
/EMC/backend/service/data_collection/cores (il faut être un utilisateur root pour y accéder - support technique Dell uniquement).

Cela permet d’éviter des problèmes à l’avenir (tels que les fichiers de vidage de cœur corrompus ou les problèmes décrits dans l’article 52543 de la base de connaissances Dell : Dell Unity : La mise à niveau vers Unity OE 4.2 échoue avec l’erreur : check_cores_existed_files_2 (corrigible par l’utilisateur) 

Les fichiers dans /EMC/backend/service/data_collection/cores ne peuvent être supprimés qu’en tant qu’utilisateur root. Par conséquent, contactez le support technique Dell ou votre représentant de service agréé en mentionnant l’ID de cet article.

À NOTER : Comparez la somme md5 des fichiers (téléchargés par rapport au fichier d’origine sur le processeur de stockage) avant de supprimer définitivement les fichiers.

Vérifiez le fichier de vidage d’origine md5sum sur /EMC/backend/service/data_collection/cores/<dump_folder>, et non sur un fichier que vous avez peut-être compressé manuellement.
Pour vérifier md5sum, exécutez les commandes suivantes :

Linux :       md5sum VotreFichierVidage.gz
Windows :     certUtil -hashfile VotreFichierVidage.gz MD5

 

Exemples des commandes décrites ci-dessus

Utilisation de pgrep pour confirmer quel est le processeur de stockage principal :

service@none spa :~# pgrep ECOM 30065

Vous obtenez un ID de processus (PID) pour ECOM, il s’agit du processeur de stockage principal. ECOM (gestion) s’exécute uniquement sur le processeur de stockage principal. Dans cet exemple, SPA est le principal.

Mais comme prévu, une fois que vous vous connectez via SSH au processeur de stockage secondaire, aucun PID n’est renvoyé pour ECOM, car celui-ci ne s’exécute pas sur le processeur de stockage secondaire :

service@none spa :~#ssh peer service@none spb :~# pgrep ECOM service@none spb :~#

Si les processeurs de stockage sont en mode maintenance, aucun ne renvoie de PID pour ECOM. ECOM ne s’exécute pas si les processeurs de stockage sont en mode maintenance.

Méthode pour répertorier, compresser et déplacer un fichier de vidage sur le processeur de stockage principal :
 

service@(none) spa :/# svc_dc -lcd ======================== [DC copier] : Disponible sur backend : core-dump_dump_spa_CKM0016170xxxx_2017-01-17_15_14_17_320_httpd core-dump_dump_spa_CKM0016170xxxx_2017-02-16_07_19_23_337_xGate kdump_spa_CKM0016170xxxx_2017-01-11 _14_52_40 safe_dump_spa_CKM0016170xxxx_2017-02-24_11_26_28_31949_safe << nous l’utilisons pour l’exemple. ======================== [DC copier] : No known cores at SSD in processed ======================== [DC copier] : Not yet pre-processed core dumps at SSD : ======================== service@(none) spa :/# svc_dc -dc /home/service/user safe_dump_spa_CKM0016170xxxx_2017-02-24_11_26_28_31949_safe [DC copier] : Il existe un bundle de datacenter dans /EMC/backend/service/data_collection/cores/safe_dump_spa_CKM0016170xxxx_2017-02-24_11_26_28_31949_safe_dir. [DC copier] : safe_dump_spa_CKM0016170xxxx_2017-02-24_11_26_28_31949_safe_nogdb.tar contiendra : safe_dump_spa_CKM0016170xxxx_2017-02-24_11_26_28_31949_safe_dir [DC copier] : safe_dump_spa_CKM0016170xxxx_2017-02-24_11_26_28_31949_safe_nogdb.tar transmis à /home/service/user avec succès service@(none) spa :/#cd /home/service/user service@(none) spa :/home/service/user# ll (or ls)... -rw-r--r-- 1 root root 681431040 8 mars 22:24 safe_dump_spa_CKM0016170xxxx_2017-02-24_11_26_28_31949_safe_nogdb.tar

 

Méthode pour répertorier, compresser et déplacer un fichier de vidage sur le processeur de stockage secondaire :

service@(aucun) spa :~# ssh peer << pour passer au processeur de stockage secondaire service@(aucun) spb :~# svc_dc -lcd<<répertoriant tous les vidages mémoire disponibles sur le SPB (secondaire dans ce cas) ======================== [copieur DC] : Disponible sur backend : core-dump_dump_spb_CKM0016170xxxx_2016-09-08_09_18_19_11994_mgmtd <<< nous l’utilisons pour l’exemple. core-dump_dump_spb_CKM0016170xxxx_2017-01-02_13_35_47_10385_grep core-dump_dump_spb_CKM0016170xxxx_2017-01-13_11_38_22_17432_TLDlistener.exe core-dump_dump_spb_CKM0016170xxxx_2017-01-25_09_19_38_338_httpd core-dump_dump_spb_CKM0016170xxxx_2017-01-27_03_15_52_2648_xGate ======================== [DC copier] : No known cores at SSD in processed ======================== [DC copier] : Not yet pre-processed core dumps at SSD : ======================== service@(none) spb :~# svc_dc -dc peer /home/service/user core-dump_dump_spb_CKM0016170xxxx_2016-09-08_09_18_19_11994_mgmtd [DC copier] : There is a DC bundle in /EMC/backend/service/data_collection/cores/core-dump_dump_spb_CKM0016170xxxx_2016-09-08_09_18_19_11994_mgmtd_dir.  [DC copier]:   vous devez entrer les informations d’identification dans les 15 secondes ou le compteur de progression démarrera [copieur DC] : core-dump_dump_spb_CKM0016170xxxx_2016-09-08_09_18_19_11994_mgmtd_nogdb.tar contiendra : core-dump_dump_spb_CKM0016170xxxx_2016-09-08_09_18_19_11994_mgmtd_dir [copieur DC] : core-dump_dump_spb_CKM0016170xxxx_2016-09-08_09_18_19_11994_mgmtd_nogdb.tar transmis avec succès service@(aucun) spb :~# exit <<< ou « ssh peer » pour revenir au processeur de stockage principal et confirmer que le fichier nouvellement créé s’y trouve. déconnexion La connexion à l’homologue est fermée. service@(aucun) spa :~# cd /cores/service/user<<< Même endroit que /home/service/user service@(aucun) spa :~# ll ... -rw-r--r-- 1 root root 222310400 9 mars 14:37 core-dump_dump_spb_CKM001617xxxxx_2016-09-08_09_18_19_11994_mgmtd_nogdb.tar

Notre fichier de vidage (d’origine depuis SPB) se trouve sur le processeur de stockage principal, SPA dans cet exemple, et prêt à être téléchargé. N’oubliez pas de supprimer tous les fichiers de vidage de /cores/service/user ou /home/service/user sur les deux processeurs de stockage une fois les fichiers téléchargés à partir de la matrice.

Dell Unity 300, Dell EMC Unity 300F, Dell EMC Unity 350F, Dell EMC Unity 400, Dell EMC Unity 400F, Dell EMC Unity 450F, Dell EMC Unity 500, Dell EMC Unity 500F, Dell EMC Unity 550F, Dell EMC Unity 600, Dell EMC Unity 600F, Dell EMC Unity 650F , Dell EMC Unity Family |Dell EMC Unity All Flash, Dell EMC Unity Family, Dell EMC Unity Hybrid ... View More View Less