Dell Unity: SP's kunnen in servicemodus gaan als gevolg van een opgeblazen gevoel van logboek (/nbsnas-partitie wordt 100% vol)
Summary: Een array kan in de servicemodus gaan (data niet beschikbaar) vanwege een opgeblazen gevoel in het logboek (op te lossen door Dell)
Symptoms
Bij dual-SP-arrays gaat één SP van het storagesysteem in servicemodus en kan niet het hele systeem worden bediend via beheerinterfaces, waaronder CLI, UI, REST API en SMI-S. Dit kan zich ook manifesteren als SP's die afwisselend opnieuw opstarten totdat beide SP's in de servicemodus terechtkomen.
Een Unity array met beide SP's in de servicemodus zal de I/O niet ondersteunen, dus dit zou een DU (Data Unavailable)-situatie zijn.
Voor VSA kan de enkele SP opnieuw opstarten in de servicemodus of gewoon in de normale modus blijven, waarbij in beide gevallen beheer verloren gaat.
Het hele systeem kan niet worden bediend via beheerinterfaces, waaronder CLI, UI, REST API en SMI-S.
SSH of IPMI zou moeten werken. IPMI werkt altijd, SSH werkt mogelijk alleen nadat de array is gestabiliseerd.
Dit probleem is te vinden in OE versie 4.0.0.x en is opgelost in OE versie 4.0.1.x.
Cause
Het logbestand /nbsnas/http/logs/mod_jk.log, dat elk verzoek van UI en REST registreert, bevindt zich in een bestandssysteem dat is gekoppeld aan /nbsnas van de primaire SP. Zonder een mechanisme voor logboekrotatie blijft een opgeblazen gevoel van dit bestand de beschikbare ruimte van het bestandssysteem in beslag nemen. Andere interne verbruikers beginnen te mislukken als er geen ruimte meer over is op het bestandssysteem. Een van de SP's gaat in servicemodus wanneer herhaalde storingen van deze componenten worden gedetecteerd.
In het lab werd waargenomen dat wanneer dit gebeurt en services proberen over te schakelen naar de secundaire SP, deze ook dezelfde symptomen ervaart. De SP's worden afwisselend een paar keer opnieuw opgestart en uiteindelijk gaan beide in servicemodus.
Klanten zien dit probleem als: altijd de gebruikersinterface of REST API gebruiken om het storagesysteem te configureren, of de gebruikersinterface in de browser openen en daar laten staan zonder te sluiten. Met alleen UI-toegang, normaal gesproken duurt het een paar maanden voordat klanten dit probleem zien. Als klanten REST API gebruiken om regelmatig query's uit te voeren op data van het storagesysteem, doet dit probleem zich sneller voor.
Er is een tweede probleem gevonden waarbij upgraden naar Unity OE 4.0.1.8320161 het probleem kan verergeren, omdat het het betreffende logboekbestand kan dupliceren tijdens de NDU, waardoor het proces wordt versneld.
U kunt dit bevestigen door het ruimteverbruik op /nbsbas te controleren. Als het ruimteverbruik minimaal of laag is, hebt u dit probleem NIET ervaren tijdens NDU en is er dus niets anders nodig.
4.0.1.x-codes bevatten al de oplossing voor het hoofdprobleem, dus de logrotatie zelf werkt correct.
Als de partitie een zeer hoog percentage gebruikt weergeeft, moeten de verantwoordelijke logbestanden mogelijk worden verwijderd (hiervoor is Dell support vereist).
Een voorbeeld van hoe u het ruimtegebruik kunt controleren en welke logbestanden u moet verwijderen, vindt u in het gedeelte Notities.
Dell heeft besloten om Unity OE 4.0.1.8320161 voor Unity en UnityVSA uit support.emc.com te verwijderen. In september 2016 is een herziene Unity OE-release (4.0.1.8404134) gepubliceerd.
Resolution
Om dit probleem op te lossen, moet de technische support roottoegang tot de array krijgen.
Neem contact op met de technische support van Unity en vermeld dit KB-artikel: 489057
Additional Information
Voorbeeld van het controleren van het ruimtegebruik:
spX:~> df -h /nbsnas Filesystem Size Used Avail Use% Mounted on /dev/c4nasdba1 1013M 55M 908M 6% /nbsnas
Het logbestand of de logs die dit veroorzaken zijn te vinden in /nbsnas/http/logs:
spx:~> cd /nbsnas/http/logs spx:/nbsnas/http/logs> ll -h total 975M -rw-r--r-- 1 root root 12K Sep 8 13:32 access_log -rw-r--r-- 1 root root 165K Sep 8 08:45 access_log.1.gz -rw-r--r-- 1 root root 239K Sep 8 06:59 access_log.2.gz -rw-r--r-- 1 root root 1.6M Sep 8 13:32 error_log -rw-r--r-- 1 root root 167K Sep 3 04:56 error_log.1.gz -rw-r--r-- 1 root root 495M Sep 8 13:32 mod_jk.log <<<<<<<<<< -rw-r--r-- 1 root root 475M Sep 8 08:45 mod_jk.log.1 <<<<<<<<<<
svc_dc -lcd (lijst met kerndumps) kan ook enkele dumps weergeven met het achtervoegsel "_mgmtd".
Deze zijn gemaakt wanneer de SP's in paniek raken omdat sommige services niet kunnen worden gestart (omdat /nbsnas vol zijn).
spx:/> svc_dc -lcd ======================== [DC copier]: Available on backend: CP_dump_spb_CKM00161701xxx_2016-09-08_13_29_47_17275_ECOM core-dump_dump_spb_CKM00161701xxx_2016-09-08_08_46_23_778_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_09_18_19_11994_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_09_18_53_21524_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_09_41_05_11446_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_09_41_45_24620_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_13_28_30_3067_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_13_29_08_15086_mgmtd