Source:How to create a Remote Device Server (RDS): Difference between revisions
No edit summary |
|||
Line 101: | Line 101: | ||
[[Image: | [[Image:Rds config.PNG|center]] | ||
Line 162: | Line 162: | ||
Embedding the client systems in Chemnitz is done as usual. | Embedding the client systems in Chemnitz is done as usual. | ||
=== Backup on the Remote Device Server === | === Backup on the Remote Device Server === |
Revision as of 14:52, 6 June 2016
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:
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:
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:
The virtual loader in the Sesam Server now has two virtual drives (one at the site "Chemnitz" and one on the site "Munich"):
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:
After creating the media pool an archive adjustment is started via the virtual loader. Make sure that the according media pool (PoolChemnitz) is selected.
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:
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
Executing the Backup Task using Immediate Start
Note here that when choosing the media pool "PoolChemnitz" the rider "Interface" is set to "Chemnitz" automatically.