Source:How to create a Remote Device Server (RDS)

From SEPsesam
Revision as of 09:25, 2 January 2013 by Hg (talk | contribs)

Template:Copyright SEP AG en


Configuration and Launch of a SEP Sesam RDS (Remote Device Server)

General

The SEP Sesam Remote Device Server offer the possibility to administer storage devices across locations using a Sesam server (e.g. removed tape libraries or SAN devices.)

If an infrastructure with several sites that don't allow for fast data transfer to the central Sesam server exists, a Remote Server can come in handy. Then the data of the respective sites that is to be backed up are not sent to the SEP Sesam server but it's backed up from a local Sesam RDS to the storage that's connected there.

The following example shows how a RDS should be set up in Linux.

The example assumes the following situation:

  • Site A (Munich): Sesam Server with NAS storage and Virtual Disk Images
  • Site B (Chemnitz): 5 clients are to be backed up via a Remote Device Server to the NAS storage (Virtual Disk Images) which is connected in Chemnitz

The Administration of all clients and devices is done centrally from the site in Munich.

In the example both systems are running on Debian GNU\Linux (Lenny). The preliminary work for the installation of a Sesam Server were already done in advance (you can find them in the Administration guide.)

Components

Install the following components on the respective sites:

Munich: SEP Sesam Server

Chemnitz: SEP Sesam RDS

The following packages for Linux exist:

Sesam Server: sesam_srv-<version>

Sesam RDS: sesam_rts-<version>

These packages can be acquired from the Downloadcenter.

Hinweis

The Sesam Server Package for Windows OS also includes the Remote Device Server. An according selection of which component should be installed can be chosen at the beginning of the installation. The Setup of a SEP Sesam RDS on Windows is the same as on Linux.


Example of an Installation (Linux)

Munich: Installation of the SEP Sesam Servers

root@muenchen#  apt-get install sesam-srv
Reading package lists... Done
Building dependency tree      
Reading state information... Done
The following NEW packages will be installed:
  sesam-srv
0 upgraded, 1 newly installed, 0 to remove and 293 not upgraded.
Need to get 0B/37.4MB of archives.
After this operation, 63.6MB of additional disk space will be used.
(Reading database ... 212024 files and directories currently installed.)
Unpacking sesam-srv (from .../sesam-srv_3.4.1-67_i386.deb) ...
Setting up sesam-srv (3.4.1-67) ...
STATUS=SUCCESS MSG=ok


Chemnitz: Installation of the SEP Sesam RDS

root@chemnitz:~# apt-get install sesam-rts
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  sesam-rts
0 upgraded, 1 newly installed, 0 to remove and 25 not upgraded.
Need to get 4117kB of archives.
After this operation, 12.3MB of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
  sesam-rts
Install these packages without verification [y/N]? y
Get:1 http://download.sep.de lenny/non-free sesam-rts 3.4.1-67 [4117kB]
Fetched 4117kB in 1min28s (46.4kB/s)                                                                                                                                                             
Selecting previously deselected package sesam-rts.
(Reading database ... 20889 files and directories currently installed.)
Unpacking sesam-rts (from .../sesam-rts_3.4.1-67_i386.deb) ...
Setting up sesam-rts (3.4.1-67) ...


Configuration

Embedding the SEP Sesam RDS

The first step when embedding a Sesam RDS is just like adding a new client. Of course, before that steps according to those that are necessary for the adjustment of a client have to be done (DNS check, adjusting the sm_ctrld.auth on the RDS system, etc).

In this screenshot you can see that a new location called "Chemnitz" was created. This is just for looks.

The Sesam RDS is embedded as a regular client:


Cs.jpg


Adding a new Virtual Drive to the Location Chemnitz

In the example a new virtual drive is created which is supposed to administer the Virtual Disk Images.

First a new drive group has to be defined:


Rds drivegrp.jpg


When creating a new drive the drop-down "Devices Server" has to be set accordingly. Chemnitz is set as Device Server there. Don't choose "diskdrives" here but choose "Chemnitz" instead:


Rds drive.jpg


The virtual loader in the Sesam Server now has two virtual drives (one at the site "Chemnitz" and one on the site "Munich"):


Rds drive2.jpg


Setting up a new Media Pool and Media

As mentioned before the server in Chemnitz has storage mounted via NAS (NFS). This is mounted on the server at /mnt/files/.

Now a new media pool has to be created on this NAS share with 200MB disk space and the according media (size 25MB each, 8 media). Note that "Chemnitz" is chosen as drive group here:

Rds pool.jpg

After creating the media pool an archive adjustment is started via the virtual loader. Make sure that the according media pool (PoolChemnitz) is selected.


Rdsarchive.jpg


If the archive adjustment fails with an error message similar to the following:

E002-MEDIA  [  5062]: Error from submitting SM_ROBOT_2 into queue Chemnitz/PoolChemnitz_<id>

Execute the initialization of the drives again as user root:

root@munich#: source /var/opt/sesam/var/ini/sesam2000.profile
root@munich#: sm_config_drives

Next, restart the archive adjustment.


After successfully creating the media (the process can be viewed in the daily protocol) the media pool has 8 virtual disk images. These disk images were not created on the local Sesam server but on the NAS storage on the Remote Device Server in Chemnitz:


Rds done.jpg


Embedding the Client in Chemnitz

Embedding the client systems in Chemnitz is done as usual.


Backup on the Remote Device Server

Generally speaking, all data of the clients in Chemnitz (backed up on the media pool PoolChemnitz) is only moving on the net segment of that particular site.

There is no transport of the data to the Sesam server via a WAN track. For this a short test-backup is started. A self-backup of the Sesam RDS (Directory /etc) to the storage mounted on the RDS.

To illustrate this, the task is started via Immediate Start. Of course, this can also be done by scheduling the task accordingly.


Setting up a new Backup Task

Rds bck.jpg


Executing the Backup Task using Immediate Start

Note here that when choosing the media pool "PoolChemnitz" the rider "Interface" is set to "Chemnitz" automatically.

Rds bck2.jpg


Rds fin.jpg