VOBs can be thought of as having two major components, the VOB database and the set of storage pools. The storage pools are where the contents of versioned files (and shared derived objects) are stored. The VOB database is where the configuration management metadata (ex. labels, baselines, version trees, ...) are stored.
Clients never access the VOB database (DB) directly. They always access the metadata through server processes running on the "VOB server host" machine. Thus, only these VOB server processes need to know the path to the DB (the "host path" or "Vob server access path") and that location does not need to be on a network share.
If you're using CCLC (the ClearCase Local Client where dynamic and snapshot views live), the storage pools are typically accessed directly over NFS or SMB. Thus, the storage pools must exist on a network share that is accessible "globally" on the LAN (the "Global path").
ClearCase normally creates the VOB DB directory and the storage pool directories as siblings under the "VOB storage directory". If the VOB storage directory is on a NAS, the VOB server processes still have to run on a "VOB server host" machine (ex. on a Windows Server 2008 or Solaris 10 machine, in your example, the machine called "vob_server") but the global path to the storage pools is is a path directly to the share on the NAS (i.e. under \netapp\vob_storage...).
Note that in your example, the VOB server processes running on the host, "vob_server", are accessing the VOB DB at "/mmm/ClearCase/vob_storage/xxx.vbs". This implies that either (1) 'netapp's share has been mounted at "/mmm/ClearCase" or (2) the VOB creator placed the VOB DB on a local file system at "/mmm/ClearCase" and only the storage pools for that VOB on the NAS.