Creating NAS Files
This appendix describes the Network Attached Storage (NAS) feature. This appendix consists of the following topics:
•
Introduction
•
Creating a NAS XML File
•
NAS XML File Example
Introduction
Network-attached Storage (NAS) is supported as a read-only storage respository at the root location (Content Acquirer) in the CDS. Content is written to the NAS by an external agent, such as the Origin Server, a publishing subsystem, or a data storage application. The NAS offers a "new content category," similar in characteristics to dynamically-cached content, which does not require metadata attachment.
Note
NAS is only supported in lab integrations as proof of concept.
The following rules apply to NAS support:
•
NAS cannot be used as a source for prefetched or hybrid content.
•
Only content serviced by the Web Engine is supported (HTTP content and Flash Media Streaming).
Note
NAS for Windows Media Streaming and Movie Streamer is not supported.
•
Only Network File System (NFS) mounts are supported for acquiring content from the NAS.
•
Content acquired from the NAS is not written to local storage on the SEs at the root location; when reading content, NAS is considered an extension of the local file system.
•
If there is more than one SE in a root location for a delivery service, then the SE that acquires the content from NAS is based on a hash of the content URL (similar to dynamically-cached content).
•
NFS share can be mounted from multiple IP addresses simultaneously.
•
Multiple mounts for the same volume on a NAS is supported.
•
NAS should be colocated with the SEs at the root location; if WAN link is used, then WAN link failover scenario should be provided.
•
IP address failover by the NAS should be implemented to avoid service disruption.
•
NAS is not applicable to live streaming
•
NAS lookup is tried before pulling content from the Origin Server
•
When Web Engine performs FastCAL lookup, NAS file lookup is performed first; followed by cached content, then prefetched content.
•
In a cache-miss scenario, the Origin Server is queried last.
Note
Ingress traffic from NAS mounts is not distributed evenly over port channels. Separate interfaces can be used for NAS outside of the port-channel configuration to achieve better load balancing. Ingress traffic to the CDS is determined by the switch, this applies to all application traffic over port channels.
Network traffic performance can be impacted by too small a value for the TCP parameter: net.inet.tcp.rexmit_slop. If it is determined that network throughput performance is impacted, the net.inet.tcp.rexmit_slop value on the NAS server should be reviewed.
The permissions for directories on the NAS-mounted file system should be a minimum of "read" and "execute" by others, and files on the NAS-mounted file system should be a minimum of "read" by others.
For example, a directory permission at a minimum should be:
and a file permission at a minimum should be:
If access to a NAS-mounted content results in a 500 error, the permissions of the files should be verified.
Reading NAS Metadata
Metadata for content stored on network-attached storage (NAS) devices is now fetched. Metadata is associated with a content file. The metadata for a content file is stored as <file>.metadata, in the same directory as the content file. For example, if the content file is located at /datap1/vod/flv/sample.flv, the metadata file is located at /datap1/vod/flv/sample.flv.metadata.
Note
NAS is only supported in lab integrations as proof of concept.
It is assumed that the content store (NAS) has the metadata of the content that is to be stored as a separate file with name such as <content_name>.metadata in the same directory location. It is also assumed that the format of the file complies with the following rules:
•
File format is a simple text file with each line of the file having an attribute name and an associated attribute value separated by a colon (:). No spaces are allowed anywhere in the metadata file. Format and pattern for the metadata file is as follows:
–
<attribute1>:<value1>
–
<attribute2>:<value2>
–
<attribute3>:<value3>
•
Basic attributes supported are as follows:
–
expires
–
s-maxage
–
max-age
–
must-revalidate
–
proxy-revalidate
–
etag
–
content-type
–
content-encoding
–
age
–
retry-after
Any header attributes other than the basic attributes listed are considered custom and are written into the client response header.
Configuring NAS
Configuring NAS in the CDS consists of the following tasks:
1.
Create a NAS XML file.
2.
Register a NAS XML file with the CDSM by uploading or importing the file.
3.
Associate a NAS XML file with a Content Origin.
For information on registering a NAS file, see the "NAS File Registration" section. For information on associating a NAS XML file with a Content Origin, see the "Content Origins" section.
NAS Mount Removal
When removing NAS mounts, the SE configuration should be updated before the NAS IP addresses are removed.
Note
Any NAS mount changes should be performed in a maintenance window to avoid service disruption.
To remove NAS mounts, do the following:
Step 1
Remove from the NAS XML file the IP addresses that are to be removed from the NAS server.
Step 2
Update the NAS XML configuration file in the CDSM GUI.
a.
Register the updated NAS XML file with the CDSM by choosing System > Configuration > NAS File Registration.
b.
Associate the NAS file with the Content Origin of the delivery service by choosing Services > Service Definition > Content Origins.
Step 3
Verify the configuration has been propagated to each SE in the delivery service by entering the show content-origin command on each SE in the delivery service.
Step 4
Remove the IP addresses on the NAS server.
Creating a NAS XML File
The XML Schema file describes and dictates the content of the XML file. The CdsOrigin.xsd file contains the XML schema. To view or download a copy of the CdsOrigin.xsd file, see the "Viewing or Downloading XML Schema Files" section.
The NAS file can be created using any ASCII text-editing tool.Table 1 describes the NAS XML file elements. The NAS
Table 1 NAS XML File Elements
|
|
|
|
CdsOrigin |
server |
name |
Name for the NAS server. This is used as an internal reference. |
host |
Domain name or IP address of NAS server. |
sourceNFS |
name |
Internal name reference used on the localMount section as the "source." |
sharePoint |
Exported file system from the NAS server. |
access |
Mount option, only "ro" read-only is supported. |
maxRetry |
Number of retries performed on a failed mount point before raising the alarm from a minor to major severity. |
rsize |
Maximum negotiated buffer size between the SE and the NAS server. |
localMount |
name |
Name of the local mount. This is used as an internal reference. |
source |
Reference to the sourceNFS subelement name. |
mountPoint |
Defines the local mount point base. |
num-of-mounts |
Number of mount points to be used from the serverList. This number cannot be greater than the number of entries in serverList. |
order |
Defines how the servers in the serverList are selected: • fcfs —Use the first num-of-mounts from the serverList • random—Randomly select the servers to use from the serverList |
serverList |
List of servers to use from the servers defined in the server subelement. List is comma delimited, or comma and space delimited. |
NAS XML File Example
Following is an example of the NAS XML file:
<server name="nas1" host="192.168.252.67"/>
<server name="nas2" host="192.168.252.68"/>
<sourceNFS name="NAS" sharePoint="nas_nfs" access="ro" maxRetry="10" rsize="131072"/>
<localMount name="localMount" mountPoint="vod" source="NAS" num-of-mounts="2"
order="fcfs" serverList="nas1, nas2"/>