Skip to end of metadata
Go to start of metadata

Difference between NAS and SAN and ISCSI 

Purpose 

The purpose of this document is to explain the basic differences  of these file storage options and their use as repositories in Business Objects Cluster configurations

Overview 

This article explains
1.What is the difference between NAS & SAN & ISCSI
2.Solution to solve the inconsistency data 
3.FRS (Input/Ouput) servers
4.Configurations Available

Difference between NAS & SAN 

A NAS typically makes Ethernet and TCP/IP connections.A SAN commonly utilizes Fibre Channel interconnects

Network Attached System (NAS)

When server computers need to use the same data, a Network File System (also called NAS - Network Attached Storage) can be used. The Network File System is implemented using a File Server and a network. The File Server is a regular computer or specialized OS that has a regular File System and regular disk devices controlled with this File System. Since only the File Server computer has direct access to the physical disk, all servers computers connecting to these disks use the same File System (The File System of the NAS). That File System guarantees the data consistency
 

Storage Area Network 

Storage Area Network is a special type of network that connects computers and disk devices; in the same way as SCSI cables connect disk devices to one computer. SAN provides Shared Disks, but SAN itself does not provide a Shared File System. The space of the SAN disk is called a LUN (Logical unit number). If you have several computers that have access to the LUN (via SAN or dual-channel SCSI), and try to use that space the disk logical structure will be damaged very quickly. So by default a single server can see a single LUN at any one time. So the area (LUN) on the SAN could not be accessed by the 2 servers at the same time. 

Internet SCSI (ISCSI)

The iSCSI (for "Internet SCSI") protocol allows clients (called initiators) to send SCSI commands to SCSI storage devices (targets) on remote servers. It is a popular Storage Area Network (SAN) protocol. Unlike Fibre Channel, which requires special-purpose cabling, iSCSI can be run over long distances using existing network infrastructure. However we will have the same problem than with the SAN

Solution to solve the inconsistent data

Cluster File System

Cluster File Systems are software products designed to solve the problems outlined above. They allow you to build multi-computer systems with Shared Disks, solving the inconsistency problems.
Cluster File System products are available for several Operating Systems: VERITAS Cluster File System or Microsoft Cluster Server (MSCS)      

Microsoft Cluster Server (MSCS)

Microsoft Cluster Server (MSCS) is software designed to allow servers to work together as computer cluster, to provide failover and increased availability of applications. In our case, this software will be used to handle concurrent access (for the FRS) to the SAN and for Failover

FRS (Input/Output) servers

For faileover purpose, you may have to set up multiple FRs (Input/Output) servers. Multiple FRS should be able to access the same files on the same "FRS folder" at any time. True simultaneous access is never required but the ability to quickly allow either server to access the files must be provided for failover to occur smoothly.
In the case of multiple FRS, even you all your FRS service are enable and started, only one FRs services will ever be actively reading and writing files and these are designated by the system as the "active" FRS's. The other pair that does not access files is the "passive" pair. The services that are granted active status are the ones that start first. Any FRS services that start later cannot register as active and therefore, even though they are running, are deemed "passive" by the system and not used.

All configurations available


Configuration A : 1 BO computer with 1 FRS (Input/Output) server

The simplest configuration : you have only one FRs (Input/Output) server. This FRS (Input/Output) server need to be actived. You can access a local or "shared disk", as only one Frs (Input/Output) server is accessing this disk, you won't have any problem with FRS files lock / unlock. In this configuration you don't have any fail-over.


Configuration B : 1 BO cluster (at least 2 computers) with only 1 FRS (Input/Output) server Enabled and Started 

One FRS (Input/Output) server is Enabled and started, one FRS (Input/Output) server is Enabled and Stopped. As you have only one FRs Enabled and started, you won't have any problem when accessing the "shared disk" as only one Frs (Input/Output) server is accessing this disk. You won't have any problem with files lock/unlock. If the active FRS (Input/Output) server shutdown, you have to start the "stopped" FRS (Input/Output) server (in case of SAN, you also may enable and start the access to the LUN). This is not a fast method but it works

 

Configuration C1 (SAN with 1 Frs directory)

You set mutiple FRS's to point to the same "shared disk", so multiple FRs are started and enabled. And your "shared disk" is a SAN. By definition a SAN is not able to manage the lock / unlock of your FRs files. So mutiple computers can not access the same LUN at the same time. So you need to have a 3rd parties software to handle this task. In this case, we used a Microsoft Cluster Server (MSCS) to handle this problem. All Frs (Input/Oupout) servers are enabled and started, the active FRs is the first computer started (see chapter D).


Configuration C2 (iScsi with 1 Frs directory)

You set mutiple FRS's to point to the same "shared disk", so multiple FRs are started and enabled. And your "shared disk" is a ISCSI disk. By definition a ISCSI disk is not able to manage the lock / unlock of your FRs files. So mutiple computers can not access the same LUN at the same time. So you need to have a 3rd parties software to handle this task. In this case, we use a Microsoft Cluster Server (MSCS) to handle this problem. All Frs (Input/Oupout) servers are enabled and started, the active FRs is the first computer started (see chapter D).


Configuration C3 (NAS + SAN with 1 Frs directory)

You set mutiple FRS's to point to the same "shared disk", so multiple FRs are started and enabled. And your "shared disk" is a NAS. By definition a NAS is able to manage the lock / unlock of your FRs files. So you don't need a 3rd parties. In this case, the NAS is connected to a SAN. All Frs (Input/Oupout) servers are enabled and started, the active FRs is the first computer started (see chapter D). So the faileover is managed for BusinessObjects servers but not for the NAS

Configuration C4 (SAN + 2 FRs directories)


You set mutiple FRS's to point to the different "shared disk". The FRs of the computer A is pointing to the "shared disk" LUNA and computer A is pointing to the "shared disk" LUNB , so multiple FRs are started and enabled. You need to have a 3rd parties software in order to manage the lock / unlock on the LUNA and LUNB and to manage the synchronization. In our case this software is Veritas. All Frs (Input/Oupout) servers are enabled and started, the active FRs is the first computer started (see chapter D)

 

Related Documents 
NAS and SAN and ISCSI 

 Related SAP Notes/KBAs 

https://service.sap.com/sap/support/notes/1686440 

 

  • No labels