System Catalog › Miscellaneous Appliances › NASR Appliance

NASR Appliance

Latest version: 2.0.2-1

Functional Overview

The NASR appliance is a shared file storage appliance. It provides file storage accessible over HTTP, NFS, and CIFS file protocols and web interface for managing files. Additionally, two NASR appliances can be configured in a master-slave synchronization mode so that content on the master is replicated to the slave.

The NASR appliance serves files contained within a configured (pluggable) data volume thus providing the ability for the content served by the appliance to be changed easily and the ability for the volume to have varied sizes. For example, if NASR is being used to store log files, the data volume does not need to be as large as what may be needed to store content for an Apache server.

The root directory of the volume is shared and the HTTP, NFS, and CIFS (samba) servers see the same volume, at the same root. The NFS server exposes the volume as a shared named /mnt/data. The CIFS server exposes the volume as a share named share. The root directory of the volume is accessible for read-only access by the HTTP server and for read/write access by the NFS and CIFS (samba) server.

The CIFS access is anonymous. It is assumed that only appliances that are allowed to access the volume are connected to the cifs terminal. This eliminates the need to configure complex security settings on the client and server and makes it possible to simply connect appliances that need file access to the cifs input.

In its default configuration, NASR serves as a regular NAS appliance. When configured, two NASR appliances can run in master-slave replication so that data on the master is kept replicated on the slave. Replication is one way only, any changes on the slave are not replicated to the master. The replication is asynchronous and is triggered by file changes on the master's data volume. Data is replicated using rsync over its native protocol.

There are several key use cases for the NASR appliance:

1. Serving large files over HTTP. Files may be added through the file manager or via the cifs/nfs terminals.
2. As a shared file server through which other appliances/servers exchange files (fully internal to the application)
3. As a log server through which other appliances/servers store their log files so that those logs may be easily accessed/viewed by an administrator rather than having to log into each individual appliance.
4. As a replicated file storage (in any of the above cases) providing synchronized storage between two instances of an application (possibly running in different locations).

NASR provides GUI access to its data volume which allows easy management of the content while the appliance is running.

Important! The current version of NASR is verified to work with up to 20000 files on the data volume. This is a kernel limitation of the file notification system. See the Notes section for details.

Boundary

Resources

Terminals

The default interface is enabled. This provides the SSH access to the appliance using the 3t ssh comp command to perform maintenance or to troubleshoot problems. The default interface can also be used to access the web-based file browser, which allows management of the content on the data volume while the appliance is running.

User Volumes

The following file may reside within the root directory on the volume:

Properties

Error Messages

The following messages may appear in either the appliance log file or the system log of the grid controller when the appliance fails to start:

Additionally, the following errors may appear on the grid dashboard while the appliance is running:

Replication

Two instances of NASR can be configured in master-slave replication so that data on the master is kept replicated on the slave. Replication is one way only, any changes on the slave are not replicated to the master.

The replication is asynchronous and is triggered by file changes on the master's data volume. Changes are kept in a buffer and every 5 seconds, all changes (if any) to files on the data volume on the master are replicated to the slave. No new synchronization is done until the current pass of transferring changes is completed. The content of the log_dir is not replicated to the slave server, if log_dir is empty or '/', only the samba and httpd log files (/mnt/data/cifs_log, mnt/data/http_access_log, /mnt/data/http_error_log) are excluded from the replication.

When the appliance is started, a full synchronization of the data volume is done. This is also done every time the replication is (re)started by the healthcheck cronjob (described below).

Data is replicated using rsync over its native protocol running on the default port (tcp 873).

Changes on the data volume are monitored using Gamin.

Healthcheck

NASR runs a cronjob every minute that checks the following:

• Is the free space on the data volume less than 20%
• Is rsync daemon running (only if configured as slave)
• Is replication process running (only if configured as master). If not - restart replication process.

If any of the above is true, an error message is sent to the grid dashboard. If more than one test fails, a summary message with all errors will be posted on the grid dashboard. Each error will be sent only once per hour to the grid dashboard. No errors are reported in the first 5 minutes after the appliance start (to prevent from false alarms when the other node in the replication has not started).

Web GUI

NASR provides web GUI access to the filesystem of the data volume. This can be used while the appliance is running to modify the content on the volume. The GUI is available on the web console on the default interface. It uses the same file browser (eXtplorer) as the Filer appliance.

The reference for the Volume Browser GUI can be found in the Grid User Guide.

The eXtplorer licenses and the source to the original un-modified eXtplorer can be found on the NASR appliances in /usr/local/extplorer/monitor/.volume_browser/LICENSES/.

Typical Usage

Content Server

The following diagram shows a typical usage of NASR for a simple web server application:

Appliances in use:

• in - input gateway, class INSSLR
• switch - url switch, class URLSW
• lb - Load Balancer, class HALB
• srv1 - Apache Server, class WEB5
• srv2 - Apache Server, class WEB5
• nas - NAS appliance, class NASR
• db - Mysql server, class MYSQLR64

The nas appliance in this example is used to serve three functions:

• serve the static content of the website (for example, images) as it is simple to configure and less resource-demanding
• provide shared storage for the application server. Both srv1 and srv2 have read/write access to the directories and files served by nas.

HTTP Access:

in accepts HTTP requests coming to the application and passes them to switch through its http terminal. Switch sends HTTP file requests for dynamic content through its out1 terminal to be served by srv1 and srv2 (load balanced by lb). Urlsw forwards all other HTTP requests through its out2 terminal to be served by nas.

Example:

Log Server

The following diagram shows a typical usage of NASR as a log server.

Appliances in use:

• in - input gateway, class INSSLR
• lb - Load Balancer, class HALB
• srv1 - Apache Server, class WEB5
• srv2 - Apache Server, class WEB5
• nas - NAS appliance, class NASR
• db - Mysql server, class MYSQLR64
• ps - Port switch, class PS8

The nas appliance in this example is used to store the log files for the two web servers as well as the database server and makes those files available through its http terminal. The nas appliance also serves as shared storage for the two web servers as described in the previous example.

The log terminals for the web servers (web1 and web2) and the database server (dbase) are all connected to the cifs terminal of nas so that when they write to their log files, the files are stored on the data volume that is configured on nas.

When an administrator needs to inspect the log files, he connects using the in gateway on port 8080, which is connected to a port switch appliance that changes the port from 8080 to 80 and passes the requests to the http terminal of the nas appliance. He logs in with the configured administrator user name and password and is shown a listing of the root directory of the data volume from which the administrator is free to view the log files he is interested in.

Example:

Replicated Shared Storage in Master-Slave Configuration

The following diagram shows a typical usage of NASR in a redundant application, where two copies of the same application run in master-slave mode with the database and file storage being replicated.

Master application:

Slave application:

Appliances in use:

• in - input gateway, class INSSLR
• lb - Load Balancer, class HALB
• srv1 - Apache Server, class WEB5
• srv2 - Apache Server, class WEB5
• nas - NAS appliance, class NASR
• db - Mysql server, class MYSQLR64
• vpn - VPN appliance, class VPN

The nas appliance in this example is used as shared storage for srv1 and srv2. It is also used as a log server for srv1, srv2 and db.

The data on content volume of the nas appliance in the master application is kept replicated to the nas appliance on the slave replication. The rout terminal of the master nas is connected to the ctl terminal which provides an encrypted tunnel to the slave replication, where the traffic is sent to the rin terminal of the slave nas. On the slave application the rout terminal of the db appliance is connected to the ctl of the vpn appliance, so that the slave mysql server can connect to the db appliance in the master application to run mysql replication.

On both applications srv1, srv2 and db are configured to log to the same dir on the nas appliance ("/logs"), which is also used for local nas logs and is also excluded from the replication so each instance of nas keeps the logs for the application that is serves.

Example:

Master nas

Master vpn

Slave nas

Slave vpn

Important! The slave nas can be configured to allow read-only access on the nfs terminal so that no writes are done from the local application servers. Such changes would not be replicated to the master nas as the replication is one way only.

Notes

Be aware of the following:

• The current version of NASR is verified to work with up to 20000 files on the data volume. This is a kernel limitation of the file notification system. Using more than 20000 files may cause the replication to malfunction. This malfunction results in periodic dashboard messages indicating that the replication has failed (once per hour).
• The features of the http and samba servers are limited and only those features that are exposed by properties are supported. All other features of the http server that are controlled by special files stored in the document tree are disabled.

NASR uses a custom kernel (2.6.24-26-xen) which is different from the default kernel for catalog appliances and includes fixes for some nfs related problems. Future versions of NASR may use the standard CA 3Tera AppLogic kernel when it is upgraded to a more recent version that includes the nfs fixes.

Open Source and Third Party Software Used on this Appliance

The following open source 3rd party software is used in addition to that software found on the appliance base class (LUX64 is the base class of PGSQL64).

Third Party Open Source Software Used Inside of the Appliance

NASR uses the following 3rd party open source packages in addition to the 3rd party open source packages used by its base class LUX5.