SAN 아키텍처
컴퓨터 과학의 초창기에는 용량이 부족하면, 다른 컴퓨터에서 빼오든 새로 마련하든 물리적인 저장공간을 마련해서 추가해 주었다. 이런 "물리적"인 측면에서 처음으로 벗어나게 해준 기술이 SAN 아키텍처 기술이다. SAN 아키텍처는 SAN 스위치 허브를 주심으로 스토리지들과 사용 PC 들을 연결해주는 구조를 말하며, 네트워크를 통해 PC에서 스토리지에 접속하는 개념이다. 오늘날 Block Storage 클라우드 서비스의 근간이 되는 구조가 바로 SAN 아키텍처이며, 대표적인 프로토콜로는 FC, iSCSI, iSER 이 있다.
FC 는 Fibre Channel 로, 광케이블을 사용하는 통신 프로토콜을 말한다. 광케이블은 빛을 통해 데이터를 전달하기 때문에 전송 속도와 지연 시간이 비교할 수 없을 정도로 우수하며, 직접적으로 Storage 를 사용하는 아키텍처인만큼 빠른 처리가 중요했기 때문에 많이 광케이블 네트워크가 많이 사용되었다. 하지만 광케이블은 인프라를 확보하는 비용이 크며 기간도 오래걸리는 등 불편함이 존재하기 때문에, NAS와 동일하게 이더넷 스위치를 기반으로 SAN 을 구축하는 iSCSI 프로토콜이 등장하게 되었다.
Block Storage 와 SAN
Block 이란 말은 정말 많이 듣는데, 간단하게라도 이게 뭔지 알고 가는게 좋다. 데이터는 Storage 에 저장될 때 블록이나 레코드 단위로 저장되고, 관련된 것들을 모아서 논리적인 이름을 부여한게 파일이이며, 이 모아놓은 것들을 어떻게 관리하는지에 대한 얘기가 파일 시스템이다. 일정한 크기의 공간(4KB)으로 나누어 저장하는 방식이라는 뜻에서 Block 이라는 이름으로 부르고, Block Storage 역시 그냥 원래 일반 디스크 쓰듯이 Block 저장소로 쓸 수 있다고 해서 Block Storage 라고 부르는 것이다. Block Storage 와 SAN의 관계를 묻는다면, 아무 상관 없다고 보는게 맞는 것 같다. 로컬 디스크들도 모두 Block Storage 기 때문이다. 하지만 Block Storage 를 네트워크로 제공하기 위해선 SAN 아키텍처가 필요한 것이라고 볼 수 있다.
iSCSI 프로토콜
앞서 말했듯이 이더넷 스위치를 기반으로 SAN 아키텍처를 구성하는 iSCSI 프로토콜은 FC 보다 성능적으로는 떨어질 수 있지만, 이더넷 스위치는 가정집부터 어디에나 구축되어 있기 때문에 SAN 아키텍처를 구성하기 훨씬 쉬운데 확실한 정점이 있다. LAN 혹은 WAN 이 형성되어 있는 곳이면 쉽게 구축할 수 있기 때문이다. 이번 포스트에서도 iSCSI 프로토콜로 실습을 정리해놨는데, iSCSI 프로토콜 역시 "이렇게 주고받자, 이런걸 정의하자" 라는 약속이기 때문에, 어떤 약속들이 있는지 살짝 알아볼 필요가 있다.
- IQN (iSCSI Qualified Name) - 프로토콜 상 서버와 클라이언트를 서로 식별하는 고유 이름 (String) 으로, 약속된 형식이 있는데, 바로 "iqn.yyyy-mm.domain-name:unique-name" 이 그것이다. domain-name 은 진짜 도메인일 필요 없다. 이 관계상 도메인 역할을 할 뿐이다.
- LUN (Logical Unit Number) - 기억하면 좋다. "LUN은 Storage 제공측이 자신들이 제공할 디스크에 부여한 번호"로, Client 입장에선 가상 디스크 그 자체로 생각해도 좋다
- ACL (Access Control List) - iSCSI 뿐만 아니라 많은 곳에서 사용되는 용어이다. "나에게 접근을 허용하는 대상자 목록"을 의미하며, iSCSI 같은 경우 허용할 Client 의 IQN 목록이다
- Target 과 Initiator - Target = Storage 제공 서버 = Target 에 대한 End Point 제공 서버. Initiator 는 이 Target 을 사용하는 Client 를 말한다. 쉽게 말하면 그냥 서버 / 클라이언트를 iSCSI 에서 부르는 말이다.
실습하면서 더 이해가 가겠지만, iSCSI 서버에선 "Storage 를 제공하는 객체"를 만들 것이다. 이 객체는 식별하는게 IQN이며, 이 객체 안에는 TPG (Target Portal Group) 이라는 작은 주머니를 두게 된다. 이 TPG 안에는 IQN이 제공할 (자신이 갖고 있는) 디스크 (LUN), 여기에 허용된 친구들 (ACL) 등에 대한 정보가 들어있다고 보면 된다. 참고로 여러 TPG 를 둘 수도 있는데, 이는 보통 접속하는 경로를 달리하기 때문에 굳이 이것까지 들어가진 않겠다.
SAN과 NAS의 차이점 (왜 SAN 이 그렇게 더 빠른가?)
한가지 또 생각해볼만한 부분은, NAS와 SAN의 차이인 부분이다. NAS 는 공유에 강하고, SAN 은 직접 마운트기 때문에 IOPS 와 Throughput 이 좋다는 사실은 유명하다. 하지만 의문이 들었다. NAS 가 이더넷 스위치를 기반으로 동작하기 때문에 IOPS 가 느리고, 파일 단위로 접근하기 때문에 느린 점은 이해했다. 하지만 iSCSI 프로토콜 역시 이더넷 기반으로 형성이 되는데, 왜 NAS 와 이렇게 차이가 나는걸까?
이는 바로 동작 계층의 차이 때문이다. NAS 는 "서버"가 파일 시스템을 직접 관리하고, "클라이언트"는 '파일 좀 제어할게요' 하면서 요청할 뿐이다. 하지만 iSCSI 는 SAN 아키텍처이기 때문에, 디스크 전체를 사용하도록 던지고 제공받는 쪽이 직접 파일 시스템을 관리한다. 이 모습 때문에 "진짜 로컬 티스크처럼 사용" 한다고 비유하는 것이다. NAS는 파일시스템이 해주는 일을 서버측에서 하기 때문에 파일 열기/닫기, 파일 시스템의 관리 및 제어, 권한 확인 등등을 진행하는 시간에서의 결정적인 차이가 나는 것이다. (파일시스템이란 무엇인가는 좀 다른 주제로 갈 필요가 있을 것 같다)
보통 이런 Storage 서비스 아키텍처들은 클라우드 시점에서 볼 필요가 있기 때문에, IaaS와 PaaS 관점에서 어디에 속하는지 생각해보는 것도 좋다. NAS는 계속 뭔가 서버로서 제공해주는 느낌이 든다. 특히, 공유 파일과 내부 파일 시스템 등을 서버가 관리하고 Client 는 "파일 단위"로만 서빙 받는 모습이기 때문이다. 따라서 PaaS인가 하는 생각이 들 수는 있지만, PaaS 에서 Platform 은 개발자가 오직 개발에만 집중하도록 지원해주는 역할이 가장 크다. NAS는 SAN 보단 서버가 개입하는게 많지만, 그래도 Client 가 Storage mount 작업, 권한 관리, 백업 관리 등은 당연히 직접 제어를 해야 하는 수준이기 때문에, NAS 리소스 역시 IaaS 로 분류된다. SAN 은 당연히 기반 인프라를 제공하기 때문에 IaaS 이다. 따라서 둘은 목적과 특징에서 조금 차이가 있는 IaaS Level의 기술이라고 봐야 한다. 일반적으로 비교하는 모습은 다음과 같이 정리해볼 수 있다.
| NAS 아키텍처 기술 | SAN 아키텍처 기술 | |
| 클라우드 상 비유 | 파일 스토리지 서비스 (ex: AWS EFS, Azure Files) | 블록 스토리지 서비스 (ex: AWS EBS, Azure Disk Storage) |
| 접근 방식 | 파일 단위 (파일 시스템이 제공됨) | 블록 단위 (디바이스처럼 제공됨, OS에서 포맷 필요) |
| 주로 연결되는 대상 | 여러 서버가 동시에 파일 공유 | 특정 인스턴스 (1:1 매핑으로 디스크처럼 붙음) |
| 실제 사용 예 | 공유 설정 파일, 웹 콘텐츠, 로깅, 홈 디렉토리 | 데이터베이스, OS 디스크, 고성능 앱 |
| 접근 시 프로토콜 | NFS, SMB 등 (파일 시스템 계층 접근) | iSCSI, NVMe-oF 등 (디스크처럼 접근) |
| 복잡도 | 상대적으로 단순 | 상대적으로 복잡 (디스크 초기화 등 필요) |
| 장점 | 공유성, 간편함 | 성능, IO 처리량, 신뢰성 (특히 DB에 유리) |
| 확장성 측면에서 | 다수의 서버에 마운트 가능, 락 처리 고려 필요 | 보통 1:1, 확장하려면 디스크 추가 |
iSCSI 프로토콜 실습
# Server 10.123.123.1
$ lsblk
...
sdb 8:16 0 600G 0 disk
└─sdb1 8:17 0 600G 0 part
├─vg001-appdata_lv 253:0 0 100G 0 lvm /appdata
└─vg001-var_lv 253:1 0 100G 0 lvm /var/lib
예전에 여분의 LV 를 마련해둔 서버가 생각나서 이 서버에서 실습했다 ㅋㅋㅋㅋㅋ. 이 여분의 파티션이 존재하게 된 과정은 (https://mooncake1.tistory.com/292) 이 포스트 참고하면 된다. 결과적으로 위와 같은 상황이고 현 VG 내 400GB가 남으므로 간단히 10GB 를 공유해보자는 생각으로 새로운 LV 를 만들어서 이를 제공해보겠다.
$ sudo lvcreate -L 10G -n san_test_lv vg001
$ lsblk
sdb 8:16 0 600G 0 disk
└─sdb1 8:17 0 600G 0 part
├─vg001-appdata_lv 253:0 0 100G 0 lvm /appdata
├─vg001-var_lv 253:1 0 100G 0 lvm /var/lib
└─vg001-san_test_lv 253:6 0 10G 0 lvm
하나만 더 알아두면 좋지만 Block Storage 자체는 LVM 시스템과는 별 상관이 없다. Block 디바이스인게 중요하기 때문에 실제 디스크, 디스크가 분할된 파티션 혹은 나처럼 LV로 준비해도 된다. 우선 Storage Server 부터 살펴보자.
$ sudo apt update
$ sudo apt install targetcli-fb
targetcli-fb 라는 프로그램을 설치한다. targetcli 란 리눅스 환경에서 iSCSI 서버를 구성하고 관리하는데 사용되는 스토리지 인터페이스이다. 그 안에서 여러가지 설정을 할 수 있는데, targetcli 명령어를 사용해서 해당 쉘 안에서 제어하면 된다. (쉽게 targetcli 프로그램을 사용할 수 있는 쉘을 사용할 수 있다). 우선 LV를 등록하는 것부터 시작할 것인데, 이 때 등록하는 "경로"는 블록 디바이스 경로여야 한다.
<개인적인 질문, 관심없으면 SKIP>
Q: 일반 경로 /appdata/appuser/hello 이런것과 /dev/vg~~ 이런걸 어떻게 구분해서 하는건지? targetcli 는 블록 디바이스만 등록할 수 있는데, 어떻게 이를 아는건지? 근본적으로는 어차피 LV 도 PV 에 의존해서 여기저기 분산해서 데이터를 저장하는 형태고, 일반 경로도 어떤 방식으로든 물리적 PV에 저장되는건데, 왜 LV 는 되고 일반 경로는 안되는건지 궁금했다.
A: LV는 커널이 직접 접근 가능한 블록 자치의 인터페이스를 제공하지만, 일반 디렉토리는 그렇지 않기 때문이라고 한다. LV는 블록 장치로 커널이 직접 접근하지만, 일반 디렉토리와 파일들은 "파일시스템을 경유"해서 접근하는 차이가 있다고 한다. LV 나 다른 블록 디바이스들은 "device-mapper" 라는 커널 드라이버를 통해 커널이 사용할 수 있는 인터페이스를 제공하고, 일반 파일/디렉토리는 "파일 시스템"이 만든 객체이며, VFS 계층을 거쳐서 접근된다는 차이가 있고, 이를 targetcli 는 인식하기 때문에, targetcli 에 등록할 때는 블록 디바이스만 가능하다.
이제 우리가 만들어 둔 LV 를 등록하고, iSCSI 타겟을 만들어 IQN이 생성되는 모습을 확인해보자. targetcli 쉘을 실행해서 볼건데, 이 쉘 역시 내부적으로 ls, cd 같은 명령어는 기본적으로 지원된다.
$ sudo targetcli ------ targetcli 쉘로 이동, 자체 프롬포트 띄워준다.
targetcli shell version 2.1.fb43
Copyright 2011-2013 by Datera, Inc and others.
For help on commands, type 'help'.
/> ls
o- / ......................................................................................................................... [...]
o- backstores .............................................................................................................. [...]
| o- block .................................................................................................. [Storage Objects: 0]
| o- fileio ................................................................................................. [Storage Objects: 0]
| o- pscsi .................................................................................................. [Storage Objects: 0]
| o- ramdisk ................................................................................................ [Storage Objects: 0]
o- iscsi ............................................................................................................ [Targets: 0]
o- loopback ......................................................................................................... [Targets: 0]
o- vhost ............................................................................................................ [Targets: 0]
해당 노드 내의 iSCSI 시스템의 현황을 확인할 수 있는 공간이며, backstores 는 제공할 storage 들이고, 우리가 관심있는 것은 block storage 이기 때문에 "block" 공간에 등록하며 된다. 명령어마다 출력되는 응답들도 주목해볼만하다.
/> /backstores/block create name=iscsi_sample_storage dev=/dev/vg001/san_test_lv
Created block storage object iscsi_sample_storage using /dev/vg001/san_test_lv.
/> /iscsi create iqn.2025-05.com.mooncake:iscsi.storage1 ## iSCSI 타겟 (endpoint) 만들기
Created target iqn.2025-05.com.mooncake:iscsi.storage1.
Created TPG 1.
Global pref auto_add_default_portal=true
Created default portal listening on all IPs (0.0.0.0), port 3260.
iSCSI 와 연동될 block 을 /backstores/block 에 생성해줄 수 있다. 또한 iSCSI 타겟을 형성하니까 해당 타겟에 대한 ACL, LUN, Portal 디렉토리가 형성되는 것을 확인할 수 있어서, 위에서 말했듯이 이들은 타겟별로 관리되는 정보들임을 알 수 있다. 이렇게 접속 경로, 인증 정보, LUN 구성 등을 모아놓은 단위 그룹인 TPG까지 확인할 수 있다
다시 한 번 정리하면, 한 Endpoint (TG) 에는 TPG 를 부여할 수 있고, 이 EndPoint 에서 특정 TPG로 접근 (로그인) 할 경우, 요청자가 ACL에 있다면 해당 EndPoint 에서 제공하는 LUN을 사용하게 되는 것이다
/> ls #### 현재까지 확인할 수 있는 모습
o- / ..................................................................................................................... [...]
o- backstores .............................................................................................................. [...]
| o- block .................................................................................................. [Storage Objects: 1]
| o- iscsi_sample_storage ....................................... [/dev/vg001/san_test_lv (10.0GiB) write-thru deactivated]
| o- fileio ................................................................................................. [Storage Objects: 0]
| o- pscsi .................................................................................................. [Storage Objects: 0]
| o- ramdisk ................................................................................................ [Storage Objects: 0]
o- iscsi ............................................................................................................ [Targets: 1]
| o- iqn.2025-05.com.mooncake:iscsi.storage1 ........................................................................... [TPGs: 1]
| o- tpg1 ............................................................................................... [no-gen-acls, no-auth]
| o- acls .......................................................................................................... [ACLs: 0]
| o- luns .......................................................................................................... [LUNs: 0]
| o- portals .................................................................................................... [Portals: 1]
| o- 0.0.0.0:3260 ..................................................................................................... [OK]
o- loopback ......................................................................................................... [Targets: 0]
o- vhost ............................................................................................................ [Targets: 0]
이제 나의 iSCSI 프로토콜이 동작하도록 구성해주면 되어서, LUN, ACL 등을 구성해줄 차례다. LUN을 생성한다는 것은 해당 서버의 iSCSI 시스템에 등록된 내부 Storage 들을 해당 IQN 을 통해 사용할 수 있도록 매핑해주는 과정이라고 생각하면 된다. 즉, 서버가 특정 IQN(EndPoint, Target)에서 제공해줄 Storage 를 매핑(LUN 생성)해주면, Client 들이 왔을 경우 "이 접근 경로로 왔어? ACL에 있네? 여기 LUN들을 줄게!" 하고 연결해주는 거라고 생각하면 편하다. 이 부분은 Client 쪽까지 구성하면 훨씬 이해가 잘 가니, 계속 진행해보자.
/> cd ~~
/iscsi/iqn.20...ge1/tpg1/luns> create /backstores/block/iscsi_sample_storage
Created LUN 0.
/iscsi/iqn.20...ge1/tpg1/luns> ls ##### 생성된 lun 을 확인할 수 있고, 어떤 Storage 를 제공하는건지 확인 가능
o- luns .................................................................................................................. [LUNs: 1]
o- lun0 .................................................................... [block/iscsi_sample_storage (/dev/vg001/san_test_lv)]
이렇게 LUN 0 가 잘 만들어진 모습을 확인할 수 있다. LUN 은 여러개 만들 수 있는 것이고, 특정 iSCSI Target 은 여러 LUN 을 제공할 수 있다는 점을 알 수 있다. 이어서 ACL 을 생성해보겠다. ACL에서는 허용할 클라이언트의 IQN이 적혀있어야 한다. IQN 은 당연히 client 의 unique 함을 보장해야 하느니, 실무에서는 인증 과정이 당연히 더 필요하느니 하겠지만, 간단한 실습이기 때문에, 내 맘대로 IQN을 만들 것이고 이 값으로만 인증되게끔 하겠다.
/iscsi/iqn.20...ge1/tpg1/acls> ls
o- acls .................................................................................................................. [ACLs: 0]
/iscsi/iqn.20...ge1/tpg1/acls> create iqn.2025-05.com.mooncake:client1
Created Node ACL for iqn.2025-05.com.mooncake:client1
Created mapped LUN 0.
/iscsi/iqn.20...ge1/tpg1/acls> ls
o- acls .................................................................................................................. [ACLs: 1]
o- iqn.2025-05.com.mooncake:client1 ............................................................................. [Mapped LUNs: 1]
o- mapped_lun0 .......................................................................... [lun0 block/iscsi_sample_storage (rw)]
## 설정이 완료된 시점에서 서버 설정 종료
> saveconfig
> exit
이 때 기본적으로 존재하는 LUN에 대해 해당 ACL을 매핑해줘서 해당 LUN을 쓸 수 있는 권한을 주게 된다. 해당 Client에게 제공하면 안되는 LUN이 있다면 해당 mapping 을 삭제하면 된다.
이미 많이 헷갈리지만, Client 와의 상호작용 측면쪽으로 더 들어가보면 더 헷갈린다. 일단 들어가기 전에 다음과 같은 내용들을 인지한채로 Client 실습으로 들어가자.
- 방금 설정한 ACL의 정보는 "IQN" 뿐이다
- Target 은 "EndPoint에 접근할 수 있는 Client IQN과, 그 IQN이 자신의 어떤 LUN을 쓸 수 있는지" 까지도 알고 있다! (3개 있어도 2개만 줄 수 있는 것)
- Client가 iSCSI에 iSCSI 프로그램을 통해 로그인을 시도한다(EX: iscsiadm ~~ --login)
- 해당 Endpoint에 LUN이 두개 매핑되어 있다고 해보자. 그렇다면 해당 Client IQN은 로그인 성공 시 "자동으로 두 개의 디바이스를 할당받게 된다". 클라이언트가 ISCSI 에 연결되면 "나에게 허락된건 LUN0, LUN1 구나" 하고 강제로 할당받아 버리고, 이에 대한 매핑된 내부 경로가 생성된다 (/dev/sdb, /dev/sdc 이런 가상 경로들 생성)
- 이를 "Client가 Target이 제공한 LUN에 대해 SCSI Inquiry를 진행한다"고 표현한다
- 이제 우리가 볼륨을 쓰던 방식대로 위 가상 경로들을 매핑해서 사용하면 된다
이제 위 절차들을 직접 살펴보기 위해 Client 단 실습을 해보자. (참고로 Portal 설정도 있는데, portal 은 그냥 접근될 Server IP:3260 적으면 되는데, 일단 0.0.0.0 으로 유지하자)
# Client 10.123.123.2
$ sudo apt update
$ sudo apt install open-iscsi
...
$ sudo cat /etc/iscsi/initiatorname.iscsi
## DO NOT EDIT OR REMOVE THIS FILE!
## If you remove this file, the iSCSI daemon will not start.
## If you change the InitiatorName, existing access control lists
## may reject this initiator. The InitiatorName must be unique
## for each iSCSI initiator. Do NOT duplicate iSCSI InitiatorNames.
InitiatorName=iqn.1993-08.org.debian:01:895b5c86fb8
iSCSI 접속 프로그램을 설치한 다음에 지금 사용하는 Client name 을 확인해볼 수 있다. 참고로 경고는 이거 수정하면 Server 단에서 너를 모를 수 있다 이런 내용인데, 지금은 간단한 Test 중이고 내마음대로 IQN 을 쓰고 있으니 수정해도 된다. 아까 내가 Server 해서 설정했던 Client 이름인 iqn.2025-05.com.mooncake:client1 으로 바꿔놓겠다.
$ sudo iscsiadm -m discovery -t sendtargets -p 10.166.233.140:3260
10.166.233.140:3260,1 iqn.2025-05.com.mooncake:iscsi.storage1
$ sudo iscsiadm -m node -T iqn.2025-05.com.mooncake:iscsi.storage1 -p 10.123.123.1:3260 --login
Logging in to [iface: default, target: iqn.2025.mooncake~~, portal: 10.123.123.1,3260] (multiple)
Login to [iface: default, target: iqn.2025.mooncake~~, portal: 10.123.123.1,3260] successful.
iSCSI 서버 EndPoint 가 있는지 discovery 명령어를 통해 확인할 수 있고, 아까 우리가 설정해둔 Target IQN 을 확인할 수 있다. 그럼 이제 로그인을 하면, 위에서 말한대로 Inquiry가 진행되고 Client에 경로가 매핑될 것이다. 과연 디바이스 경로를 Client 에서 인식했을지 확인해보자.
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 62M 1 loop /snap/core20/1611
...
sdc 8:32 0 10G 0 disk <<------------------ 마운트된 모습
...
lsblk 로 블록 디바이스를 확인해보면 맨 아래 sdc 로 10GB 짜리 디스크가 하나 추가된걸 확인할 수 있다. 이는 확실히 서버로부터 블록 스토리지를 제공받은 모습이며, disk type 으로 분류되며, 정말 물리적인 디바이스로 인식되기 때문에 PV 그룹에 포함시킬 수 있는 영역이 된 것이다!! (그냥 평소 디스크랑 똑같이 파티션을 나눠서 사용해도 되고, 디스크 자체를 PV로 써도 된다). 파티션이든 디스크든 사용할 파일 시스템을 생성해준 이후 원하는 곳에 mount 해서 사용하면 되는 것이다. 일반 디스크처럼 직접 마운트해서 사용해도 되고, LVM을 사용해도 된다 (LVM은 볼륨 확장, 스냅샷, RAID 유사한 기능 등에서 이점을 얻기 때문에 이유가 있을 때 사용하는 것이라고 한다).
참고사항들을 정리해보자면, 우선 iSCSI 로그아웃을 하게되면 디바이스 자체가 사라진다. 따라서, 마운트된 채로 로그아웃을 진행하면, 디스크 에러가 발생할 수 있고 이는 제법 치명적인 손상이다. 따라서, 사용하는 경로를 Clean up 후 unmount 한 뒤에 로그아웃을 하는게 맞다. 또한, 해당 디스크를 마운트해서 사용한다고 해서, 제공한 서버측에서 그 파일들을 확인할 수 있는 건 아니다 (NFS와의 차이 인지). 이 모습은 진짜 디스크 자체를 그냥 넘겨준 모습으로 봐야하기 때문에, 마치 타 서버의 파일을 그냥 보려는 행위와 똑같다고 보면 된다. 당연히 내 서버에 저장되어 있으므로 위치를 찾아서 강제로 읽을 수는 있겠지만, 파일 시스템을 해석하거나 파일 내용을 보는 것은 불가능하다 (고 한다... 바이너리 블록 덩어리만 있을 뿐이다).
정리하며
NAS 아키텍처에 이어서 SAN 아키텍처까지 실습해보았다. 프로토콜들의 내용 부분이 조금 이해하기 어렵다는 생각은 들었지만, 어쨌든 아키텍처 구조의 전반적인 흐름을 이해하는데는 도움이 된 시간이였다. 기본기를 공부하는 과정은 항상 아깝지 않은 것 같다. 더 많은 Storage 기술들과 내용들을 이해하는데 기본이되는 내용들일테니, 잘 알아두기로 하자.
참고자료
https://tech.gluesys.com/blog/2019/12/02/storage_1_intro.html
글루시스 기술 블로그
A simple yet classy theme for your Jekyll website or blog.
tech.gluesys.com
'CS 이론 > Storage' 카테고리의 다른 글
| [NFS] NFS 프로토콜을 통해 NAS 아키텍처 이해해보기 (0) | 2025.05.12 |
|---|---|
| [LVM] LV 분할하여 Ubuntu /var 용량 확장하기 (1) | 2024.11.25 |