CUCM 10.5 - Partition Explanation

[DemPackets]

So I setup some monitoring tools to monitor the partitions on my CUCMs. Unfortunately I've come to the realization that the partitions I am monitoring are not the ones I should be super concerned about. Through SNMP I am able to pull statistics on disk space for the following:

• /dev/sda1
• /dev/sdb1
• /dev/sdc1

Does anyone know what exactly those partitions are? Does anyone know a better way for me to monitor the active, inactive, and logging partitions on my CUCMs? I actually ran into an issue about 6 months ago that completely nerfed my Dev CUCM (VMware logging issue) and I don't want the same issue to occur without me knowing in my production environment. Thanks in advance!

[Jaime Valencia]

You can run the command "show tech runtime disk" to get more detail on the partitions and current usage

[DemPackets]

I tried that command. What's interesting is that /dev/sda1 appears but /dev/sdb1 and /dev/sdc1 don't appear. I'd really like to know what those partitions are or rather, what CUCM is doing with those partitions. 

[FRANZ EDUARD PETERMANN · Accepted solution]

I guess it is already solved. Anyway maybe you hit one of these two BUGs.
CSCux90747
CSCuz50894
In this case vmware-caf logs can consuming 100% of the active root partition.

[Sanjay Khurana]

The disk names in Linux are alphabetical. /dev/sda is the first hard drive (the primary master), /dev/sdb is the second etc. The numbers refer to partitions, so /dev/sda1 is the first partition of the first drive.

If you want to see the current status of the partitions you can run "show status' the output will be like:

admin:show status

Host Name : CUCM
Date : Wed Jun 15, 2016 16:48:03
Time Zone : Timor-Leste Time (Asia/Dili)
Locale : en_US.UTF-8
Product Ver : 10.5.2.11900-3
Unified OS Version : 6.0.0.0-2

Uptime:
16:48:05 up 161 days, 9:39, 1 user, load average: 0.23, 0.21, 0.19

CPU Idle: 94.43% System: 02.03% User: 03.29%
IOWAIT: 00.25% IRQ: 00.00% Soft: 00.00%

Memory Total: 3925456K
Free: 105708K
Used: 3819748K
Cached: 590456K
Shared: 0K
Buffers: 38328K

Total Free Used
Disk/active 14652904K 1862188K 12641848K (88%)
Disk/inactive 14652904K 13741144K 167416K (2%)
Disk/logging 50986188K 28181044K 20215192K (42%)

It will show you the current state of the partitions. Some of the alerts are preconfigured in the system like:

LogPartitionHighWaterMarkExceeded

LogPartitionLowWaterMarkExceeded

LowActivePartitionAvailableDiskSpace

LowAvailableVirtualMemory

LowInactivePartitionAvailableDiskSpace

LowSwapPartitionAvailableDiskSpace

So you can monitor RTMT for these alerts and if you want can configure RTMT to send these alerts to an email

HTH

Sanjay

[DemPackets]

I understand the Linux side of things. I understand how the partitions are named and why they are named that way. I more or less want to know, what is the CUCM system writing to those specific drives. The reason being is that I only have 7% free space left on those drives and it's slowly creeping up daily. 

[DemPackets]

Yeah. I appreciate the direct bug link though. This issue completely nerfed my dev environment and what's terrible is that Cisco didn't even offer to help me rebuild it. I actually just recently put together a SOW to get our VAR who originally setup the dev environment to come back out and build it up again new. The dev environment works, but I can't add any new phones or do anything that adds space to the system and I haven't been able to do a successful back up for about a year or so. Restoring the current configuration will not be possible as it is only a single UCM server.

Fortunately, I caught the issue in production before I lost access to the SSH session so Cisco TAC was able to help prevent our production environment from crapping out. I only lost one subscriber, which was easy enough to rebuild.