PowerScale OneFS: Запит на монтування з <IP клієнта> для <Path> не вдалося
Summary: Реагування на повторювані сповіщення «Засідати з».
Symptoms
Одним із найбільших порушників є наступне попередження:
Recurring: Mount request from <Client IP Address> on <Node IP Address> for <Share> failed with errno: <2 or 13>
Правильно реагуючи на це сповіщення, ми можемо зменшити навантаження на CELOG і покращити роботу сповіщень/подій та звітність.
Cause
Клієнт запускає ці сповіщення, намагаючись отримати доступ до спільного ресурсу, який або не існує як експорт, або він не має дозволу на доступ
.Сканери безпеки, InsightIQ або клієнти Windows, які можуть мати увімкнену функцію Services for Network File System (NFS), часто викликають такі сповіщення.
Resolution
Щоб правильно реагувати на ці сповіщення, ми повинні визначити, хто отримує доступ до вказаного Share-Share з відповідної IP-адреси клієнта:
# isi event events list | grep "Mount.*fail" | awk '{print $10}' | sort | uniq -c | sort -rn
110 xxx.xxx.xxx.57
63 xxx.xxx.xxx.63
61 xxx.xxx.xxx.54
39 xxx.xxx.xxx.55
37 xxx.xxx.xxx.250
37 xxx.xxx.xxx.240
24 xxx.xxx.xxx.61
23 xxx.xxx.xxx.65
22 xxx.xxx.xxx.44
20 xxx.xxx.xxx.45
19 xxx.xxx.xxx.56
16 xxx.xxx.xxx.62
І про невдачу, яку вони переживають:
# isi event events list | grep "Mount.*fail" |awk '{print $NF}' | sort | uniq -c|sort -rn
876 STATUS_NOT_FOUND
63 STATUS_ACCESS_DENIED
З наведеною вищею інформацією можна визначити, хто намагається отримати доступ до експорту і чому це не працює, таким чином створюючи подію.
Якщо звернутися до непорушних клієнтів неможливо, сповіщення можна придушити, починаючи з OneFS 9.3 і вище.
У WebUI це можна зробити у розділі Events and Alerts ->Alert Management ->Search for mount in Event Type ID.
З CLI можна було використати наступну команду:
# isi event suppress modify --suppress=true --id=400130001
Ідентифікатор події можна побачити у наступному документі на сторінці 54.