Server Room and InfrastructureMay 10, 2026Serdar8 min read

iSCSI and SAN Fundamentals: The SME Server Room

TL;DR: iSCSI and SAN basics — centralised storage architecture, performance evaluation, and cost analysis for the SME server room.

Summary: A SAN (Storage Area Network) is a networked-storage architecture that gives multiple servers block-level access to a shared central storage pool. Fibre Channel (FC) is high-performance but expensive; iSCSI runs over standard Ethernet (TCP/IP) and is the dominant cost-effective choice at SME scale. With iSCSI, even a Synology / QNAP NAS can serve multi-host storage; or a full-class SAN from Dell EMC, NetApp, or HPE Nimble builds a corporate-grade environment. Where SAN earns its keep: VM live migration, multi-host clusters, high availability. At SME scale, if you only have a single server, SAN is overkill; if you have a 2+ server cluster, SAN/iSCSI is the natural choice.

When you say "storage" in an SME, what usually comes to mind is the RAID disks inside the server. But multi-server environments (Hyper-V cluster, VMware cluster, file-server HA) need central storage — the servers run independently yet must see the same data. This article covers SAN, with a focus on iSCSI as the typical SME variant, its architecture, and the decision criteria.

Target audience: IT managers, system administrators, and decision-makers who want to turn "do we need central storage?" into a concrete decision.

Comparing Storage Architectures

There are three core storage approaches in SME environments:

DAS (Direct Attached Storage)

Disks inside the server itself
Managed by the RAID controller
Cheap, simple
Limitation: tied to that one server; nobody else can reach it

NAS (Network Attached Storage)

File sharing over the network (SMB, NFS)
File-level access
Synology, QNAP, Windows file server
Multi-user, file-based

SAN (Storage Area Network)

Block-level access over the network
iSCSI (over Ethernet) or Fibre Channel (dedicated fabric)
The server sees the disk as if it were local
Multi-server, block-based

NAS vs SAN — the Clear Distinction

Property	NAS	SAN
Access level	File	Block
Protocol	SMB, NFS	iSCSI, FC, FCoE
Usage	File sharing	Used as virtual disks
Boot	No	Yes (boot from SAN)
Multi-server	Many users on the same file	One LUN per server (cluster: shared)
Example use	Office files	VM disks, databases

When SAN Actually Matters

SAN isn't required for every SME.

SAN is the Right Call

2+ hypervisor hosts (Hyper-V / VMware cluster)
Live migration (moving a VM between hosts without downtime)
VM HA (a VM that auto-restarts on another host when its host fails)
DB clusters requiring high availability
Storage replication (DR scenarios)

SAN is Overkill

A single server (local disk is enough)
Multiple servers that run independently (no clustering)
Pure backup use (a NAS is more appropriate)

iSCSI Fundamentals

iSCSI = Internet Small Computer System Interface. It carries SCSI commands over standard Ethernet.

Key Concepts

Initiator: the side that requests storage (a server)
Target: the side that provides storage (a NAS, a SAN appliance)
LUN (Logical Unit Number): the virtual disk presented to the server
IQN (iSCSI Qualified Name): a unique name for an initiator / target
Portal: the target's network address

iSCSI Flow

Configure the Microsoft iSCSI Initiator (Windows) or open-iscsi (Linux) on the server
Enter the target portal's IP
The available LUNs are listed
The server attaches to the LUN
It appears on the server as a new disk (Disk Manager / lsblk)
Format it, use it

Hardware Requirements

Standard Ethernet (1 Gbps, 10 Gbps)
A dedicated SAN switch (recommended, not required)
Compatible initiator and target software

Whereas Fibre Channel needs extra hardware (FC HBAs, FC switches), iSCSI runs over standard Ethernet — costs drop.

iSCSI vs Fibre Channel

The SME decision usually favours iSCSI.

Property	iSCSI	Fibre Channel
Speed	1 / 10 / 25 / 100 Gbps Ethernet	8 / 16 / 32 / 64 Gbps FC
Hardware	Standard Ethernet	FC HBA, FC switch
Cost	Low	High
Complexity	Low	High
Latency	Higher (TCP/IP overhead)	Lower
Management	Standard networking	Dedicated SAN team
SME fit	High	Limited

10 Gbps iSCSI satisfies most SME production databases. Fibre Channel today is for enterprise-tier and very high-IO environments.

Practical iSCSI Scenarios for an SME

Scenario 1: Synology / QNAP NAS + Hyper-V cluster

2 Hyper-V hosts
Synology DS1821+ NAS (10 Gbps)
iSCSI LUNs as VM-disk storage

Affordable, useful, and popular at SME scale.

Scenario 2: Windows Storage Server iSCSI Target

The iSCSI Target Server role on Windows Server
Using an existing file server as an iSCSI provider
Native fit for the Microsoft ecosystem

Scenario 3: Open-source FreeNAS / TrueNAS

ZFS-based storage
Snapshots, deduplication
Open source, cost-effective
Requires technical know-how

Scenario 4: Corporate SAN (Dell EMC PowerStore, NetApp, HPE Nimble)

High performance, advanced features
Replication, snapshot, deduplication
For the upper end of SME scale

iSCSI Design Best Practices

When building an SME iSCSI environment:

Network Design

Separate VLAN: iSCSI traffic should be isolated from the general LAN
MTU 9000 (jumbo frames): for performance gain
Dual NICs: redundancy via multi-path I/O
Dedicated switch (ideal): best performance
QoS: priority for iSCSI traffic

Multi-Path I/O (MPIO)

Multiple paths to the target
If one path drops, the other takes over
Load balancing

CHAP Authentication

Password-based authentication between initiator and target
One-way or mutual
A standard security measure

Encryption

iSCSI isn't encrypted by default
IPSec can encrypt it, with a performance cost
SME environments usually run iSCSI on a physically isolated VLAN — extra encryption isn't required

Performance Expectations

Typical performance in an SME iSCSI environment:

Setup	Expected IOPS	Throughput
1 Gbps + HDD NAS	2,000–5,000	100–120 MB/s
1 Gbps + SSD NAS	10,000–20,000	110–120 MB/s
10 Gbps + HDD	5,000–10,000	800–1,000 MB/s
10 Gbps + SSD	50,000–200,000+	1,100–1,200 MB/s
25 Gbps + NVMe	500,000+	3,000+ MB/s

A typical SQL Server in a VM needs 5,000–10,000 IOPS; a 10 Gbps + SSD setup handles that comfortably.

Backup and Snapshot

A lot of SAN's value comes from advanced features like snapshots and clones.

Snapshot Use

Captures the current data state in place
A 1 TB snapshot in seconds
Runs at the storage layer; no load on the server
Restore takes minutes
Cloning between production and DR/test environments

SME Backup Strategy

iSCSI LUN snapshots (hourly)
Backup from snapshot (Veeam, Acronis)
The backup target on a different NAS / cloud

Cost Analysis

Indicative SME-scale costs:

Synology / QNAP iSCSI Scenario

8-bay NAS (e.g. DS1821+): ~30,000 TL
8 × 6 TB SSDs: ~80,000 TL
10 Gbps NIC module: 15,000 TL
10 Gbps switch (8 ports): ~25,000 TL
Total: ~150,000 TL

Corporate SAN Scenario

HPE Nimble HF20: 700,000–1,200,000 TL
Redundant switches: 100,000+ TL
5-year maintenance: 200,000–300,000 TL
Total: 1,000,000+ TL

At SME scale, Synology / QNAP iSCSI is usually optimal.

Common Mistakes

Typical pitfalls in SME iSCSI deployments:

iSCSI traffic on the general LAN: bandwidth contention, security risk
MPIO not configured: one path drops and the server loses its disk
Single point of failure: one NAS, one switch
No backup plan: snapshots on the SAN but no off-box backup
No capacity planning: at 95% full, performance collapses
No backup window: the backup run kills production performance
Outdated firmware: known vulnerabilities sitting open

What Yamanlar Bilişim Offers

Our SAN/iSCSI support areas at SME scale:

"Do we need a SAN?" assessment
iSCSI architecture design
Synology / QNAP / TrueNAS rollout
Windows Storage Server configuration
VLAN, MPIO, jumbo frames
Snapshot and backup strategy
Performance testing and tuning
Annual SAN health audit

Frequently Asked Questions

Conclusion

iSCSI and SAN aren't "enterprise-only" technologies — they're the natural choice for any SME environment with multiple servers, VM clusters, and high-availability needs. With NAS devices like Synology and QNAP, a serious SAN environment can be built on a budget of 100–200K TL. A single-server SME doesn't need a SAN; but as soon as a 2+ host cluster is on the table, starting with iSCSI is the most pragmatic path.

Yamanlar Bilişim provides storage-architecture design, rollout, performance tuning, and annual health-audit services sized to your needs — turning central storage in your server room into a planned win rather than a surprise.

Frequently Asked Questions

As an SME, isn't a NAS enough — do I really need a SAN?

It depends. For pure file sharing, a NAS is enough. But: if you need a VM cluster, live migration, multi-host shared storage, a SAN/iSCSI becomes necessary. Devices like Synology and QNAP can serve both NAS and SAN roles via iSCSI — for an SME, a single device often covers both needs.

Can I use SMB 3.0 instead of iSCSI for shared storage?

Hyper-V supports VM-disk storage over SMB 3.0 (Microsoft SMB Direct ). For VMware, iSCSI / NFS is standard, not SMB. Inside the Hyper-V ecosystem SMB 3.0 is a viable alternative; weigh licensing and performance. iSCSI offers broader compatibility.

How many VMs can I run on a single 10 Gbps Ethernet link?

10 Gbps = 1,250 MB/s theoretical throughput. An average VM uses 50–150 MB/s (averaged, not peak); so 8–25 VMs comfortably. IOPS matters more — usually 10,000–50,000 IOPS (depending on NAS specs). At SME scale, a 10 Gbps + SSD NAS easily carries 10–15 VMs.

Is CHAP authentication mandatory?

On a physically isolated VLAN, the extra security gain is limited. But best practice says enable it. On a shared LAN with many users/devices, CHAP is closer to mandatory. Setup takes five minutes; the return is high.

iSCSI vs NFS — which is better for VMs?

VMware ESXi supports both. NFS is easier to configure and its snapshot management is straightforward; iSCSI, being block-level, has performance advantages in some scenarios. For an SME: whichever your team is more comfortable with usually decides. NFS is simpler operationally; iSCSI is more common in Microsoft shops.

Is taking backups on the SAN enough, or do I need a separate NAS?

You need a separate target. SAN snapshots live inside the same SAN — a hardware failure, ransomware event, or physical damage to the SAN takes the snapshots with it. Backups must go to a different location / medium : a secondary NAS, cloud object storage, offline disk. The 3-2-1 rule applies to SAN environments too.