iSCSI Target 스레드 구조

Open Source iSCSI target의 비교 자료의 기술에 의하면, IET의 architecture는 이하와 같이 도시할 수 있습니다.

 

IET는, kernel내에서 패킷 수신을 전문으로 수행하는 Receive thread와 송신을 수행하는 Send thread, File I/O를 수행하는 I/O thread의 3 종류의 thread로부터 구성되어 있습니다.

iSCSI protocol로 요구된 READ/WRITE request를, Receive thread→Receive queue→I/O thread→Send queue→Send thread의 순서에 처리해, reply를 돌려준다고 하는 단순한 architecture입니다.

이 구성의 이점은, iSCSI target의 실제 장점은 cache를 관리하지 않아 좋다고 하는 점으로, simple하게 되는 것입니다.
예를 들면, WRITE의 직후에 같은 segment를 READ 한다고 하는 access pattern를 생각해 봅시다.
IET의 architecture이면, VFS(Virtual File System)에 cache의 관리를 맡기고 있기 때문에, 단순하게 WRITE→READ를 VFS에 발행하고, reply를 정직하게 돌려주어 가면 좋게 됩니다.

다만, 이점만이 아닙니다.
request를 받고 나서 reply를 돌려주기 전에 반드시 File I/O를 실시할 필요가 있기 위해, OS의 File I/O이상의 성능은 나오지 않습니다.
현재의 hardware이면, Gigabit Ethernet 대응의 NIC는 이론적으로 1 Gbps, header나 hardware의 overhead를가미해도 Socket I/O로의 실측치로 900 Mbps강의 성능을 내는 것이 가능합니다.그러나, File I/O는 여기까지 빨리 없습니다.

고가의 SAS나 SCSI HDD는, 이론적으로 2 Gbps강의 bus에 접속하는 것이 가능합니다만, 이 값은 어디까지나 bus의 굵기이며, HDD의 I/O성능은 100MB/s = 800 Mbps 이하입니다.

RAID0등의 striping를 이용하고, 늦은 HDD에의 access를 분산해 bus를 유효 이용하지 않는 한 성능을 벌 수 없습니다.

 

염가의 IDE나 SATA HDD의 경우, cache가 효과가 없는 상황의 HDD I/O는, 50MB/s = 400 Mbps 이하의 성능인 일도"자리등"입니다.
즉, 모처럼 Gigabit Ethernet로 iSCSI target와 initiator를 접속해도 OS의 buffer cache가 효과가 없는 경우, File I/O성능에 끌려가 Gigabit Ethernet의 성능이 나오지 않는 상황에 빠져 버립니다.