VBrick dme Admin Manual page 105

DME-2, in parallel, has identified missing requested content that is not present in the
mesh, and not locally present. DME-2will then notify Rev of the cache-miss content. Rev
will receive the notification and then immediately re-preposition the content to all pre-
positioned DMEs and the DME that reported the miss.
These case studies illustrate the basic use cases of retrieving data and how the mesh
identifies, locates, and distributes content. This provides for a much more efficient delivery
and distribution of content, but it also fills up our DMEs.
Starting with DME version 3.7, Vbrick introduced an automated process for removing older
prepositioned content. This is done to keep enough storage space ready for additional
downloads. The system monitors disk storage and when it reaches a predefined threshold,
content is then evaluated on the DME and deleted based on a modified LRU (least recently
used) algorithm. The thresholds are defined on the DME Status Bar help page.
The LRU algorithm identifies and orders content (ONLY from the UploadedVideos
directory) by when it was last watched. The rationale reflects the standard caching theory that
important content is watched more often than less important content. Any content not
recently watched represents potential storage savings. The DME then removes sufficient
content (to meet the threshold). The DME will only removes content from the
UploadedVideos folder (which is content prepositioned by Rev), as such, there may be cases
where the DME cannot recover space because of other services using the disk – e.g., multiple
or long running HLS creation that is in Appending mode.
DME Rules for Mesh Architecture
All DMEs will be automatically included within the mesh and utilized for content location
and distribution. As such, reachability (ability to connect) between the DMEs is a critical
issue for the mesh architecture. The mesh architecture has limited usefulness if DMEs cannot
reach each other.
When moving into the DME mesh, the following guidelines should be considered:
• Do not add DMEs to Rev during peak use times. Adding a DME will cause a mesh
update across all DMEs. This will cause playback disruptions as the mesh resets.
• Do not add DMEs to Rev during any live event. This will cause playback disruptions as
the mesh resets. Adding a DME will cause a mesh update across all DMEs. This will
cause playback disruptions as the mesh resets.
• Every meshed DME must have reachability to at least one other DME. DMEs rely on
other DMEs to get and share content. If they cannot communicate, then they cannot
share content. Visit the
their reachability status.
• Every meshed DME must have reachability to at least one other prepositioned DME. As
mentioned above, DMEs need DMEs to share content. However, there should be
reachability to at least 1 prepositioned DME for all DMEs. By doing this, any
prepositioned content will be available to the non-prepositioned DME.
• Every stream and video file must have a unique name across the DMEs and within the
mesh. This is a critical component of the mesh. Within the mesh, streams and pieces of
streams (e.g., HLS .ts files) are flowing between DMEs that are serving them to players.
When a duplicate name is entered into the system from separate DMEs this causes the
mesh to deliver incorrect packets of streams to players. If you are transmuxing,
transrating or creating new streams on DMEs please verify that the names are unique.
• Best Practices:
DME Admin Guide
>
System Configuration Caching
System Configuration
page to see peered DMEs and
93