HOB Techtalk

The desire to work at home can become a necessity, as currently discussed reaction plans for the event of a serious influenza pandemic have shown. To guaranty business continuity for the successful operation of external workplaces, enterprises should deploy highly performant remote access solutions before a crisis strikes.

The discussion of how enterprises can maintain business continuity in the event of an influenza pandemic is not new: Already in August 2007, the Swiss pharmaceutical giant Roche announced that their emergency business plan also foresees the need for employees to have secure remote access to the company's IT system, in order to ensure business operations continuity and protect the employees from exposure to health risks. "The most important service that we have defined is the remote access of our employees to the computer systems," said Jennifer Allerton, CIO of Roche Pharma. However, a study carried out by the corporate consulting firm Mercer in 2007 showed that only 47 percent of major corporations had created an emergency plan and only 17 percent had planned a budget for pandemic contingency planning. Even if the home country of an enterprise is not directly affected, problems may nonetheless arise, as was demonstrated this May in Hong Kong: Hundreds of travelers and hotel guests were placed under quarantine by the Chinese health authorities, as it was feared they may have come into contact with just one Mexican visitor who had tested positive for the swine flue virus.

Securing Business Continuity from Outside

Whereas one usually thought of business continuity assurance in terms of secure computer centers and databases, backups and restart times, when one considers the possibility of employees being unavailable, the topic gets a new dimension: In such a case, the enterprise must follow two goals:

• The systems must be able to be remotely operated and administered.

• Employees must be able to work from home or other remote locations.

The Solution: Secure Remote Access

Corporations that want to ensure smooth business continuity even in such times of crisis when only a skeleton staff may be available on location, require a readily available, performant and easy-to-use secure remote access solution. That this also increases the attractiveness of the workplace and thus the entire enterprise, is a welcome side effect. In many cases, the use of home offices or the use of freelancers can also lead to cost reductions. The First Step: Needs Assessment The first basic question in a remote access project is whether this access, and thus the ability to work at home, should be set up only for use in the event of a crisis or whether it should be implemented as part of standard business procedure. When this has been decided, it must be decided which employees or home office workplaces are to be equipped with secure remote access. Depending on the employee's duties, the type and range of secure remote access is to be determined: From access to only their own desktop to comprehensive secure remote access to the entire enterprise network. Finally there is the question of which technology to use. Decisive factors here are , availability, performance, cost and, of course, security. The Internet can make workstation PC's and systems available from all over the world, but this brings with it security risks.

Which Access for What Purpose?

The technical prerequisites for remote access from and to home offices are already available almost anywhere: Just about everyone has a PC or laptop and uses an economical DSL connection. Laptops and PDA's can be used during business trips and, in an emergency, one can read one's e-mail from an Internet Café or a PC in the hotel lobby. HOB provides two proven solutions for secure remote access: HOB RD VPN, which uses the SSL protocol for encryption, and HOBLink VPN, which is an IPSec-based VPN.

Secure End-to-End Connection via SSL: HOB RD VPN

In the opinion of IT experts, the SSL protocol is increasingly being deployed for secure remote access solutions. HOB RD VPN uses SSL encryption to protect its End-to-End connections tot the application level, which works in every environment and in only a very few cases is blocked.

With HOB RD VPN, there is no need to install any HOB software on the client side, neither are special drivers nor administrator rights needed; the client machine only needs a Java-capable browser.

In addition to secure remote access to an Intranet, Web applications and file servers, HOB RD VPN also has powerful Java Remote Desktop clients for Windows Terminal Servers, which also require no installation on either the client or target machine. HOB RD VPN can also provide full network access with the HOB PPP Tunnel component. With this, the user can get secure remote access to any network resource for which he or she is authorized.

Full Network Access Over IPSec: HOBLink VPN

For secure remote access over IPSec, HOB has the product HOBLink VPN, which, using its "Silent Installation" feature is easy to centrally  implement and administrate. Hereby the enterprise-wide rollout is carried out via a client CD, which when started automatically installs all of the features, rules and ad-ons.

After entering user name and password, the user can logon to the enterprise network and, depending on the authorization given, directly access his or her applications and data. 

HOB GmbH & Co. KG
Marketing/Public Relations
Petra Körwer
Schwadermühlstraße 3
90556 Cadolzburg
Tel. 09103/715-284
Fax 09103/715-271
E-Mail: marketing@hob.de

Before we put a new file server into production, we make a few benchmarks for the CIFS and NFS performance. The new server was a Solaris box with huge ZFS volumes. On the Solaris server an NFS server and Samba (for CIFS) are running out of the box. Samba was configured to use our MS Active Directory for Authentication.

As benchmarks we use the following:

A program that reads files of different sizes (5GB, 100MB, 10MB 1MB) from the server share.

Different copy jobs with a 5GB file and 1GB folders with different file sizes.

If you are interested in the detailed environment, benchmark description, values and charts you can download this pdf .

For all the benchmarks we measure the time for completion and calculate the transfer rates.
To omit compression of the used protocols we used files created with /dev/urandom.

We expected nearly the same values for reading a file and copying to a local drive, since both tests do the same (copy additionally writes to a local disk and might therefore be slower).

Reading from a server share is the most common task done in the real world, so this performance has more effect in real environments.

The CIFS and NFS shares are in the same shared folder on the server.

We discovered that NFS was very fast, but CIFS was very slow. Especially when we read from the server or copied from the server. With NFS we read a 5 GB file with over 80 MB/s (about one minute), the same file has only 7 MB/s (about 12 minutes) with CIFS! All the different copy jobs from the server share to the local drive are under 10MB/s for CIFS; for NFS we are never under 40MB/s.

For the copy the files to the server jobs, NFS was also always faster than CIFS, but only by about 10 MB/s. So sending files to the server with CIFS has no such bad performance.

We were very surprised about the bad values for CIFS. To verify the results, we decided to measure another system. A Windows Server 2008 with a faster CPU and a fast storage system. The results were in the range of the Solaris NFS System. When copying to the server share, the Windows system is always faster than the Solaris system.

So CIFS is not slow, but our Solaris system is slow; maybe Samba is the problem?

To verify this we used a slower Linux box with Samba and NFS. On the Linux server we have also nearly 80 MB/s for NFS for the 5 GB file. If we use smaller files the transfer-rates are slower compared to our Solaris NFS server. As expected, asynchronous NFS was a bit faster than synchronous NFS. For the CIFS share we measured 37 MB/s. For the most benchmarks CIFS and NFS have comparable results. With some benchmarks CIFS wins, with others, NFS.

As expected Samba is not slow at all.

Back to our Solaris system, we discussed the next steps to find out why we measure such bad values for CIFS. First we tried some performance parameters in the Samba configuration. This gave us minimally better results. This made us think, maybe our Active Directory authentication is the problem, so we decided to use local authentication for Samba. This gave us marginally better results. After asking a Linux specialist in our IT Department to take a look at this, he found the problem (high log level for Samba) and solved it. Now Samba on the Solaris box is comparable to the Windows 2008 Server. As our tests are now finished, we can say the winner is NFS: If you are reading from a server share, the results are slightly better than for CIFS. When writing to a server share, CIFS is clearly faster for all writing benchmarks.

If you are interested in the results with charts, please download this pdf .