Storage Management using Openfiler, Part 3

The Openfiler RAID 1 setup that we discussed last month uses mirroring for data volumes, and a single additional OS hard disk. Here, to recover from a crashed OS disk, one must replace the disk, reinstall the OS and restore backups. The RAID data volumes remaining intact, the server is back in action after that. Disadvantages here are the need for an additional OS disk (and its power consumption) and having to reinstall the OS to recover. It is also possible to have both OS partitions and RAID 1 volumes on just two disks, in two steps:

1. Create required OS partitions, configure them in RAID 1, modify GRUB to include the second hard disk as a bootable disk.
2. Create RAID 1 volumes, and assign user rights from the Web-based Openfiler GUI.

Hardware configuration used was an Intel Dual-Core CPU-based PC with 2 GB RAM, 2×500 GB SATA hard disks, and a DVD drive for installation. Openfiler version 2.3 was used.

Start by booting from the Openfiler CD, and continue with GUI-based installation. The most important step required for RAID 1 installation is creating the RAID partitions manually using Disk Druid. Check the following table for the brief layout.

The remaining installation options are straightforward — Ethernet interface parameters (don’t forget to set the interface to activate at boot); setting timezone and assigning a root password. Once done, open the Web GUI from any computer (https://ipaddress:446). Verify the RAID configuration –> navigate to Volumes –> Software RAID and verify all the three RAID volumes created earlier. If any change is required, now is the time to fix the partitions.

Next, log in as root and update Openfiler with the following commands:

conary updateall
conary update conary

Confirm that all updates have been applied, by running the same command till you receive the message: “no new troves were found”.

One important step remains. The Openfiler setup has only the GRUB register hda as a boot drive; hdb should also be made bootable. To do this, use the following commands (apply GRUB commands corresponding to the detected hard disks; here, hda was detected as sda and hdb as sdb):

root@localhost:~# grub
grub> device (hd0) /dev/sda
grub> root (hd0,0)
grub> setup (hd0)
grub> device (hd1) /dev/sdb
grub> root (hd1,0)
grub> setup (hd1)
grub> quit
root@localhost:~#

Figure 3 lists the terminal output for the above commands.

Verifying the installation

You can remove one hard disk at a time, and check whether the system boots properly. Once up and running using a single disk, check under Volumes –> Software RAID; you will see the “clean” and “degraded” volumes (which remain unsynchronised), as shown in Figure 4.

After re-installing the removed disk, proceed to add the member to the RAID 1 array, for synchronisation to start. Then select Add Member from the ADD column; carefully check the partition sizes, and add the required RAID 1 member to the array. You can see the synchronisation process status (Figure 5) immediately after this. If a new hard disk is added, you will require to create the partitions and then add them to the RAID array.

The remaining setup requires you to configure network access via System –> Network Setup; create the Network Access Configuration to allow access to the full subnet.

Important tips

1. Use only manual partitioning. Auto partitioning will use the full disk for the OS, leaving no space for data storage.
2. Make all software RAID partitions primary partitions — check the “Force primary” checkbox.
3. By default, logs are stored on the root (/) partition. If it runs out of space, the system stops functioning. To protect against this, a separate /var/log partition is recommended.
4. Do not configure swap partitions as either RAID type, or primary partitions.
5. You must configure GRUB to allow booting from both disks — else, if hda fails, the system will not boot — and OS redundancy by RAID 1 will be useless.
6. Further configuration steps, with screenshots, are given in the August and September articles. Refer to those for more information.

Enabling FTP

In the Web GUI, create a user group: Accounts –> Administration –> Group Administration; create ftpgroup, overriding GID to 1001. Then create the ftpuser1 user in Accounts –-> Administration –> User Administration, overriding UID to 501. Go to Services –> FTP Server and click Enable.

After you add volumes to your volume group and create an ext3 partition (of 150 GB, for instance), use Make share as FTP and configure ftpgroup as the primary group (PG); allocate read-write (RW) access to ftpgroup. Under the host access configuration, select RW access for FTP to the Internal PCs group. Now, you can access the FTP share with standard FTP clients from your internal network.

Accessing the FTP server from the Internet

To access this server from the Internet, you require to set up a small network with a firewall capable of port forwarding. IPCop is an excellent GNU firewall distribution for this purpose. Internal PCs/servers access the Internet via the firewall, which passes requests from internal PCs, to the requested Internet address, and passes replies back to the originating internal PCs. To allow external computers to access internal servers, we use a firewall feature called port forwarding. For more information, see Wikipedia on port forwarding.

Basically, connections to the firewall at certain port numbers used for different services can be passed on to servers behind the firewall, and the servers’ responses relayed back to the computer on the Internet that requested the service. Some well-known ports are TCP 20, 21 for FTP data and FTP; TCP and UDP 53 for DNS; TCP 80 and 443 for HTTP/HTTPS; and UDP 161 for SNMP.

Prudent firewall installations first block all incoming Internet traffic to the internal network, and vice versa. Then, depending on the requirements, access is allowed for the requested services.

Configuring IPCop for port forwarding

Internet traffic to TCP ports 20 and 21 on the public Internet interface must be forwarded to the internal FTP (Openfiler) server. Port forwarding configuration instructions will differ depending on firewall type. Figure 6 shows IPCop’s port forwarding screen. Access can be restricted to a particular source IP address/range of IP addresses by entering the corresponding IP or network address in the Source IP field, as you can see in Figure 6. The ports are forwarded to the internal FTP server only if the originating IP address is the configured source IP.

That is all, folks! Now, the internal Openfiler FTP server can be accessed from preconfigured public IP addresses with any standard FTP client software such as Filezilla or CoreFTP.

Once installation is complete, don’t forget to back up your system and LDAP configuration via System–Backup/Restore –> Download and Services –> LDAP setup –> Backup LDAP.

For several important installation details, please refer to the August and September articles.