A clip mirror provides an optional, hot-backup capability for the SGI Media Server. Though optional, a clip mirror platform is recommended. A clip mirror duplicates ingested media content processed by the primary SGI Media Server. This redundant structure ensures the availability of important media in the event of a catastrophic SGI Media Server failure. This chapter describes clip mirror configuration and provides guidance to allocate bandwidth for content transfers between a primary SGI Media Server and the mirror platform.
The clip mirror feature requires installation of the clipmirror subsystem. This subsystem contains the executable logic necessary to configure, initiate, and manage a clip mirror server. The clip mirror actively synchronizes with the primary SGI Media Server clip cache to acquire an exact copy of the media ingested by or transferred to the primary. The primary SGI Media Server normally performs media playout and record operations and may also be the principal recipient of file transfers from other video processing servers or workstations.
The SGI Media Server supports only solitary clip mirror configurations—that is, those with a one-to-one (peer-to-peer) mapping of a mirror to the primary server. Alternative clip mirror topologies are possible but are neither supported nor encouraged.
This appendix consists of the following sections:
Clip cache mirroring is performed using a TCP/IP network communications interface. The clip mirror subsystem transfers clip cache content from the primary SGI Media Server to the clip mirror platform. The transfer is unidirectional and automatic between the primary and mirror platforms and is accomplished using FTP.
The media transfer consumes both network and real-time filesystem bandwidth and, thereby, diminishes the allocated resources on the primary SGI Media Server platform. Wise allocation planning can minimize over-subscription of the real-time filesystem resource, which may adversely affect the performance of the primary SGI Media Server during playout or recording. The speed of FTP operations depends on the clip bit rate, the network infrastructure connecting the servers, and the available compute cycles to initiate the transfer.
The clip mirror service is event-driven. Certain actions performed with the primary SGI Media Server infrastructure generate clip cache activity that generates a concurrent and simultaneous action on the mirror platform. Removing clip content, creating clips, clip metadata modification, and other activities generate mirror platform actions.
Automatic clip cache transfers to the mirror platform is subject to the following specific conditions, constraints, and events:
New content generated by or transferred to the primary SGI Media Server effects an automatic transfer.
Upon initial clip mirror activation, if the mirror's clip content is newer (more recent modification date) than that of the primary SGI Media Server, the clip is considered synchronized; that is, no transfer takes place.
Upon initial clip mirror activation, if the size of the clip content on the mirror is identical to that on the primary and the clip content modification date on the primary SGI Media Server is more recent, the mirror clip content is considered synchronized.
Media content modification or metadata changes (such as protection attribute modifications) to the content on the primary SGI Media Server effects transfers.
If content resides on the mirror platform and is absent from the primary SGI Media Server, a message is generated in /usr/vtr/adm/logs/vtrlog on the primary SGI Media Server.
Clip removal or renaming on the primary SGI Media Server generates clip removal or renaming on the mirror platform. The clip may be removed manually from the mirror using an MVCP commands (CRM).
If the primary SGI Media Server becomes unavailable while being actively mirrored, the mirror platform attempts to reconnect and reestablish mirror operations. This feature persists until service to the primary SGI Media Server is restored.
In a dual-server environment, if the primary server becomes unavailable for an extended period of time, you can reconfigure the redundant server to be the primary server. When the original primary server is available again, you can reconfigure it as the new redundant server. All clips on the new primary server are then automatically copied to the newly organized and enabled mirror platform.
Clip mirroring ceases if the mirror platform fails. When the platform is restored, the service resumes; all new or changed clips will be transferred from the primary SGI Media Server. Once the clip caches on the primary SGI Media Server and mirror platform are fully synchronized, the the clip mirror subsystem monitors the primary SGI Media Server for content changes to the clip cache.
The file /usr/vtr/config/system-defaults/clipmirror holds the control parameters specific to configuring the clip mirror subsystem. Table 10-1 lists the four control parameters for clip mirroring. The parameters are described in the subsequent subsections.
Table 10-1. Clip Mirror Control Parameters
Control Parameter | Meaning |
|---|---|
vtr.clipmirror.primary_server.hostname | Specifies the primary SGI Media Server to mirror. Set on the clip mirror platform. |
vtr.clipmirror.local_server.hostname | Contains the named identity of the primary SGI Media Server network interface dedicated for file transfer. Set on the primary SGI Media Server. |
vtr.clipmirror.max_threads | Specifies the number of threads spawned on clip mirror server. Set on the clip mirror platform. |
vtr.clipmirror.reconnect_interval | Specifies the connection retry interval if the primary SGI Media Server goes offline. Set on the clip mirror platform. |
The vtr.clipmirror.primary_server.hostname control parameter must be assigned on the clip mirror platform to initiate clip mirror operations. The control value specifies the server name of the primary SGI Media Server. The following is an example file entry:
vtr.clipmirror.primary_server.hostname colossus.cia.gov |
This entry establishes colossus.cia.gov as the primary SGI Media Server to mirror. This platform must reside within the network domain defined by the company.
An application can dynamically control clip mirroring with the MVCP SSET command, shown in the following example:
SSET clipmirror vtr.clipmirror.primary_server.hostname colossus.cia.gov |
The vtr.clipmirror.primary_server.hostname control can also terminate clip mirror operations. Apply the SSET command with a null hostname on the mirror platform to terminate mirror activities following completion of any in-progress operations, as shown in the following example:
SSET clipmirror vtr.clipmirror.primary_server.hostname ““ |
The vtr.clipmirror.local_server.hostname control specifies the name of the network interface alias for transfers between the primary SGI Media Server and the mirror. A primary SGI Media Server may possess multiple network interfaces, each described by a static IP address and name alias. This control routes clip content network traffic over a specific interface from the primary SGI Media Server to the mirror platform. Clip content transfers use the default network interface configured by the primary SGI Media Server at bootstrap. Use this parameter to establish an alternate, exclusive interface for clip transfers.
Changing this control using the SSET command does not have an immediate effect. The clip mirror process on the SGI Media Server must be stopped and restarted using vtrstart –f for the new value to become active.
The vtr.clipmirror.max_threads control parameter specifies the number of concurrent mirror operations supported by the mirror platform. The value specified by this control should be calculated from the network connection throughput and the real-time filesystem resource on the primary SGI Media Server; the default is 20 with a minimum of 1 and maximum of 100. Using a value of 1 for this control severely constrains mirror operations especially when used for high-content capture on the primary SGI Media Server.
Changing this control using the SSET command does not have an immediate effect. The clip mirror process on the SGI Media Server must be stopped and restarted using vtrstart –f for the new value to become active.
The vtr.clipmirror.reconnect_interval establishes a polling interval for connection attempts by the mirror platform to the primary SGI Media Server. The default value is 30 seconds, and 1 second is the minimum possible. Should the primary SGI Media Server cease service, the mirror platform will continue connection attempts until service resumes.
Alternatively, the mirror platform can replace the primary SGI Media Server, and the former primary SGI Media Server can be configured as a mirror platform upon service resumption.
The SGI Media Server filesystem requires precise tuning and configuration to provide optimal resource allocation. Therefore, it is important to match filesystem structures between the primary SGI Media Server and a mirror platform. Nonmatching filesystem structures may impede operation. The following steps ensure that the filesystems match:
Verify that the clip content filesystem on the mirror platform matches the real-time extent size of the primary SGI Media Server. As root, enter the following command:
# xfs_growfs -n /usr/vtr/clips
The output should resemble the following, which has been slightly reformatted:
meta-data=/usr/vtr/clips/ isize=256 agcount=8, agsize=8192 blks data = bsize=16384 blocks=65536, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 1 bsize=16384 log =internal bsize=16384 blocks=1000 realtime =external extsz=2097152 blocks=4445586, rtextents=34731In the last line, the extsz value is the extent size of the filesystem.
On the mirror platform, use the versions command to verify that the following subsystems are installed:
vst_eoe.sw.clipmirror
vst_eoe.sw.ftpd
On the primary SGI Media Server, verify that the vst_eoe.sw.ftpd component is installed.
On the mirror platform, verify that the configuration file /usr/vtr/config/system-defaults/clipmirror contains clip mirror controls and values with one control specification per line. A comment line is denoted with a leading # character. Remove the # for each control desired for mirror platform configuration as described in section “Controlling Clip Mirror Operation”.
On the primary SGI Media Server platform, verify that the configuration file /usr/vtr/config/system-defaults/clipmirror contains the control vtr.clipmirror.local_server.hostname and has the proper value to permit transfers over a dedicated network interface.
On the primary SGI Media Server and mirror platform, create a new user account named vtrsync as shown in the following:
/usr/sysadm/privbin/addUserAccount -l vtrsync -u idnumber -g 0 -H /usr/vtr/clips -S /bin/csh -P
The user ID (the variable idnumber in the example above) must be unique in the system; it can differ for different servers. To check user IDs already in the system, open the file /etc/passwd and view the third field. In the following example, the user ID is 994:
tutor::994:997:Tutorial User:/usr/tutor:/bin/csh
For the new user account vtrsync (on each server), set the password to vtrsync as shown in the following:
# passwd vtrsync New Password: Re-enter new password:
At each prompt shown above, enter vtrsync.
The access mode and ownership of the real-time filesystem on the primary SGI Media Server must be set to allow access by the clip mirror. On the primary SGI Media Server, enter the following:
# chmod -R 776 /usr/vtr/clips /usr/vtr/index # chown root:sys /usr/vtr/clips /usr/vtr/index
The clip mirror service does not create subdirectories; they must be manually created on the mirror real-time filesystem as needed to match the clip directory hierarchy on the primary SGI Media Server.
To redesignate a mirror platform as the primary SGI Media Server, follow these steps:
Disable clip mirroring on the mirror platform, as shown in the following command:
SSET clipmirror vtr.clipmirror.primary_server.hostname ""
On a new primary SGI Media Server server, verify that the /usr/vtr/config/system-defaults/clipmirror file has the following control unset, as shown in the following entry:
vtr.clipmirror.primary_server.hostname ""
Unset the control if necessary.
On the mirror platform, set the value of the control parameter vtr.clipmirror.primary_server.hostname to the name of the new primary SGI Media Server.
Each SGI Media Server must have an XFS filesystem organized to support real-time I/O operations. This persistent storage structure must be managed by a guaranteed rate I/O (GRIO) daemon to enable predictable SGI Media Server execution. Each SGI Media Server system is parameterized by the maximum number of full-rate video streams that it supports. This constraint is based on the clip video format and the number of video codecs installed and used concurrently.
Bandwidth is consumed by the SGI Media Server for each transfer to and from an XFS real-time filesystem. Hence, bandwidth management for clip mirror operations comprises one aspect of SGI Media Server resource allocation. This bandwidth management is accomplished by limiting the total number of simultaneous transfers and the transfer rate.
The clip mirror controls and FTP controls parameterize this aspect of SGI Media Server resource allocation. The total number of simultaneous clip mirror operations is specified with vtr.clipmirror.max_threads.
The bandwidth consumed by FTP operations is specified by the controls contained in the /usr/vtr/config/vtrftpd.conf file. Table 10-2 describes these controls. The values for these controls must be specified in megabits per second.
 | Note: The FTP control values must match on both the primary SGI Media Server and the mirror platform. |
Table 10-2. FTP Control Parameters
Control Parameter | Meaning |
|---|---|
vtr.ftp.io.rate.default | Specifies the default clip transfer rate (bits/s) for clip mirror operations. |
vtr.ftp.io.rate.enforce | Specifies whether the transfer rate may exceed the value specified by the control vtr.ftp.io.rate.default.The value 0 allows the bandwidth to exceed that default. The value 1 enforces default transfer rate. |
vtr.ftp.procs.max | Specifies the number of concurrent FTP transfers the primary SGI Media Server supports. |
The vtr.ftp.procs.max control should be tuned to account for primary SGI Media Server activity, load, and workflow. The following are two possible scenarios to consider:
Assume a primary SGI Media Server that has four video codecs with an active clip mirror. If the value of control vtr.ftp.procs.max is 4 and four video codecs concurrently ingest video, all four streams will be mirrored simultaneously. In this case, the values for the controls vtr.clipmirror.max_threads and vtr.ftp.procs.max should be equal.
Assume again the same configuration of four concurrent ingest operations but also that an external source transfers content into the primary SGI Media Server. In this case, vtr.ftp.procs.max and vtr.clipmirror.max_threads should both have the following value:
4 + 2 * number-of-external-source-transfers
The /usr/vtr/config/vtrftpd.conf file should contain an additional record that specifies the FTP rate into and out of the clip cache path on the primary SGI Media Server. This following is an example of such an entry:
/usr/vtr/clips 32000000 |
This entry indicates that a maximum FTP transfer value of 32 megabits/s is allocated for clip mirroring.
The transfer rate should be slightly above the video input bit rate for the the SGI Media Server. The example above (32000000) represents approximately 1.2 times the real-time rate for a single DVCPRO 25 video stream.
The number of FTP transfers set by the vtr.ftp.procs.max control plus the total number of active video codecs defines the number of concurrent data streams under SGI Media Server control. This value, when multiplied by the number the value of control vtr.ftp.io.rate.default, determines the peak bandwidth of the XFS real-time filesystem in megabits per second. The following formula shows this symbolically:
max-bandwidth = (vtr.ftp.procs.max + #active_codecs) * vtr.ftp.io.rate.default |
The capacity requirements for the filesystem resource can be tuned to suit this anticipated load.