Freigeben über

Installation & Configuration of Windows NFS Client to enable Windows to Mount a UNIX File System

  • Artikel

Installation & Configuration of Windows NFS Client to enable UNIX to Windows to Mount a UNIX File System

When migrating a SAP system from UNIX/Oracle or UNIX/DB2 to Windows/SQL it is sometimes useful to be able to mount a UNIX file system on a Windows server. The Network File System protocol (NFS) is used by most UNIX and Linux operating systems such as Solaris, HPUX, AIX etc. The Windows equivalent of NFS is Server Message Block known as SMB or CIFS

SAP fully support “heterogeneous” SAP application servers, that is a UNIX/Oracle or DB2 database server and Windows/Intel application servers. The Windows platform offers integrated clustering/HA (documented, supported and free of charge from SAP) and single sign on. Windows applications servers are fully supported on both Hyper-V and VMWare.

How to Setup Windows to UNIX File System Interoperability

There are several technologies to enable connectivity between Windows servers and UNIX operating systems:

1. Samba is a freeware software available from www.samba.org that exposes UNIX server file systems as Windows (actually SMB Compatible) shares. Samba also allows some integration into Microsoft Windows Domains & Active Directory. Samba is configured and managed on the UNIX server and requires installation/configuration by the UNIX administrator

2. Windows 2003 has an add on component called Windows Services for UNIX has a component called Client for NFS. Services for UNIX setup is used to add/remove Client for NFS.

3. Windows 2008 and Windows 2008 R2 the Services for Network File System have been made part of the File Server Role. The Server Manager tool is used to add/remove the Services for Network File System as of Windows 2008 or later. Windows 2008 and higher also has additional interoperability features for UNIX environments called Subsystem for UNIX-based Applications however installation of this component is not required to enable simple NFS connectivity

In all cases it is highly recommended to use the Windows 2008 R2 product if possible. Check the SAP Product Availability Matrix or post a question in this blog to verify if your SAP version is supported on Windows 2008 R2. In general all SAP Kernel 7.0 or higher systems are supported on Windows 2008 R2 since November 2010.

Installation Tasks:

1. Follow the step-by-step procedure to add NFS support for Windows 2008 R2 and basic configuration

To install Services for NFS components

1. Click Start, point to Administrative Tools, and then click Server Manager.

2. In the left pane, click Roles.

3. Under Roles Summary in the right pane, click Add Roles. The Add Roles Wizard appears. Click Next.

4. Select the File Services check box to install this role on the server, and then click Next.

5. Select the Services for Network File System check box, and then click Next.

6. Confirm your selection, and then click Install.

7. When the installation completes, the installation results appear. Click Close.

2. Logon to the UNIX host and type

id –u <sid>adm

id –g <sid>adm

or while logged on as <sid>adm type id

3. The next step involves “mapping” the Windows user id to the UID and GID of the <sid>adm account on the UNIX server

There are three ways of doing this, however in most cases we recommend option #1

Username mapping:

#1 Configure the UID/GID using the registry entries explained in this blog – (Recommended technique)

#2 Configure Active Directory Lookup or ADLDS (for Win2008 or higher) - optional

#3           User Name Mapping if required (for Win2003 see this post) - optional

4. Ensure the Windows host is defined in the /etc/hosts file on the UNIX server. Add the UNIX server to the \Windows\Drivers\etc\hosts file on the Windows server

5. Ensure NFS configuration (/etc/dfs/dfstab or similar) on the UNIX server is correct – the Windows hostname must be allowed to mount the file system usually

6. Mount the SAP profile directory using Windows Explorer or command line with the syntax unixserver:/export (recommended) or use the traditional Windows \\servername\share

7. Test creating and deleting a file

8. Install a SAP instance using SAPInst or use SAPInst to export the UNIX/Oracle system to Win/SQL

Note: SAP requires that the NFS connection has a drive letter. It is therefore always necessary to logon the Windows host and ensure the NFS drives are connected prior to starting the SAP application server. NFS is not a particularly robust protocol therefore it is not to be used as a Export or Import location. It is not permitted to export an SAP system to dump files on an NFS source. In addition it is not recommended to store dump files on a NFS source and import on a Windows server. Always read/write to dump files on a local disk

Several Great Uses of Windows to UNIX File System Interoperability

During OS/DB Migrations from proprietary UNIX systems to Intel/AMD commodity solutions the R3LOAD export/dump files need to be transferred to Windows.

SAP Migration Monitor supports FTP to transfer dump files to a Windows environment. However this requires the installation of FTP on the Windows server.

There are three good reasons for establishing Windows to UNIX interoperability:

1. The ability to use powerful Intel/AMD servers for the Migration. This will greatly speed up the export/import process

2. The ability to use SAPInst GUI to complete the full OS/DB Migration process without the need to use command line tools.  A full manual procedure for exporting and importing a SAP system has been documented in this blog, however the latest versions of SAPInst for SAP Kernel 7.0 systems and higher can be exported/imported provided that the UNIX file system containing the SAP profiles is exposed. SAPInst will check the profile directory before starting the export. Provided a Wintel server can access the profile directory, SAPInst will allow a GUI based export of a UNIX system.

3. Increasing numbers of customers are using modern Intel and AMD servers as SAP application servers connecting to UNIX database servers. Modern Intel and AMD based servers are vastly cheaper than proprietary UNIX servers and deliver comparable or better performance. SAP OLTP type applications such as ECC 6.0 usually require 60% to 80% of the system CPU resources on the Application Tier with the remainder on the Database Tier. Therefore 60% to 80% of the SAPS (Unit of SAP workload sizing) can run on low cost Intel or AMD commodity servers.

As of February 2010 a typical fully configured SAP application server deployed in our customer base costs less than $15,000 inclusive of 96-128GB RAM service & support.

A typical medium size SAP system may have about 100,000 SAPS in total with 30,000 SAPS for Database Layer and about 70,000 SAPS for the SAP Application Layer (a typical 30% Database / 70% Application Tier split). In this hypothetical case where the application workload requirement is equal to 70,000 SAPS, this requirement can be met with only 3 Intel or AMD servers at a cost of approximately $45,000 in total. The energy consumption is much lower than UNIX systems and the rack space required is only 2U each or less if blades are used.

Many customers compare the workload capabilities of modern Intel and AMD based servers and the total all up cost including Operating System License, Energy/Aircon/rackspace, 3 year maintenance and administration + OS patching costs (practically zero for a Windows 2008 R2 server with Internet Explorer removed and all other Windows features secured/disabled) find that Intel/AMD based systems cost is 1/8th to 1/10th that of proprietary UNIX platforms.

Additional information about Intel/AMD systems increase in market share vs. UNIX system and Intel displacement of high cost proprietary UNIX systems confirms a general trend to commodity type hardware.

 

 

4. Windows NFS Services also allows a customer to preserve a single SAP Transport directory and domain during a migration from UNIX/Oracle to Win/SQL. During a period of 2-6 weeks the Dev and QAS systems are running on Win/SQL and the Production system is running on UNIX/Oracle. It is still supported to transport configuration settings, SAP Security and ABAP programs from a Win/SQL Development system to a Production system running on UNIX/Oracle (because SAP is largely OS/DB independent).

Useful Links

Below are some useful links. If you have any questions feel free to post them in this blog.

https://brneurosci.org/linuxsetup108.html - a very good overview of setup and configuration process for Win2003

https://www.softpanorama.org/Net/Application_layer/nfs.shtml - a generic overview of UNIX side configuration

https://technet.microsoft.com/en-us/library/cc785878(WS.10).aspx – troubleshooting NFS Client (Win2008 R2)

https://technet.microsoft.com/en-us/library/cc737549(WS.10).aspx – general overview of NFS Client (Win2008 R2)

More information on SAP Benchmarks can be found on the official SAP Benchmark website. The above statements about SAPS as unit of SAP sizing and cost of various hardware platforms are derived out from real SAP customer deployment or migration. The term “SAPS” is used as a measure of equivalent workload.

SAP Note 80266 - Installing NT Applicn. Servers in UNIX Environment

SAP Note 97993 - Central NT/UNIX transport directory

Note 680617 - INST: Appl.Server in Heterogeneous SAP System Environment

Note 1067221 - Composite note for heterogeneous installation

Note 1148109 - Heterogeneous Inst.(Appl. Server Windows, DB Unix)

Thanks to:

Ashish Sahu - owner of https://blogs.msdn.com/b/sfu/

Warwick Chai - owner of https://www.bnw.com.au

Comments

  • Anonymous
    June 03, 2014
    > In all cases it is highly recommended to use the Windows 2008 R2 product if possible. What specific advantages does the 2008r2 implementation have over the 2003r2 one? It's just that 2003 has the superior GUI, flatter configuration layout and organisation, etc. which just makes it far more productive to use in general. > NFS is not a particularly robust protocol In what way does it lack robustness? Most UNIX facilities are highly robust. If I have Solaris 11.1 and Windows Server 2003 r2 x64, which would be more reliable:
  1. configure Solaris to use SMB/CIFS so Windows doesn't have to do anything exotic;
  2. configure Windows to use NFS so Solaris doesn't have to do anything exotic? My previous research has indicated NFS is a superior, faster, more efficient protocol. Your webpage is the first I have seen to claim the opposite. I would like to see your rationale. Thanks!
  • Anonymous
    December 14, 2014
    The comment has been removed