날아라 병아리

AI 데이터센터 - 스토리지의 변화

삐야악이 — Sun, 12 Jul 2026 00:07:33 +0900

AI 인프라의 가장 큰 병목이 스토리지라고 들었다. 단연 그럴 것이 학습을 위한 데이터 모두를 메모리에 저장할 수 없으니 그때그때마다 스토리지에서 불러오거나, 처리한 데이터를 스토리지에 저장해야하는데 스토리지는 보통 원격지에 있으니 네트워크를 통해 대용량 / 대규모 데이터를 전송해야하니 병목이 될 수 밖에 없다.

이번 글에서는 대규모 스토리지를 대표하는 클라우드 IaaS 의 shared storage 와 AI 인프라의 스토리지가 어떤 차이를 가지는지 / AI 인프라의 스토리지 기술에 대해 간단하게 알아본다.

1. AI 인프라 스토리지는 왜 다른가

전통적 엔터프라이즈 스토리지(SAN/NAS)는 데이터베이스, 가상머신, 파일 공유처럼 비교적 예측 가능한 랜덤 I/O와 안정적 지연시간을 위해 설계됐다. iSCSI 기반 SAN은 종종 밀리초 단위 I/O 지연을 감수하며, 스케일업 컨트롤러에 성능이 묶여 있다. AI 클러스터는 이 전제를 완전히 깬다.

첫째, GPU 경제학이 스토리지 병목에 극도로 민감하다. GPU는 비싸다. 스토리지가 배치(batch) 데이터를 제때 공급하지 못하면 GPU는 다음 작업을 위해 기다리는 시간이 늘어난다. 이는 고가의 GPU를 구축하더라도 성능을 온전히 내지 못하는 낭비로 이어진다.

둘째, 학습 I/O는 양극성을 가진다. 데이터 로딩·전처리·증강 단계에서는 수십억 개 작은 파일에 대한 소규모 랜덤 읽기가 발생한다. 여기서 진짜 병목은 대역폭이 아니라 메타데이터인 경우가 많다. 반면 체크포인트 단계에서는 패턴이 정반대로 뒤집혀 대규모 순차 쓰기가 폭발한다. 분산 학습의 체크포인트는 "다대일(many-to-one)" 쓰기로, 수천 개 GPU 프로세스가 동시에 멈추고 상태를 중앙 스토리지에 쏟아낸다.

셋째, 추론 I/O는 지연시간과 IOPS가 지배한다. 추론은 모델 로딩 속도, KV 캐시 오프로딩, RAG용 벡터 데이터베이스 접근, 사용자 대기시간 최소화를 요구한다. 학습이 "초 단위 지연도 대역폭만 유지되면 괜찮은" 처리량 게임이라면, 추론은 수십만 IOPS와 서브밀리초 지연을 요구하는 다른 게임이다.

2. 클라우드 IaaS 의 스토리지와는 무엇이 다른가?

A) I/O 패턴과 최적화 목표가 정반대

IaaS shared storage(Ceph RBD, EBS 같은 블록 스토리지, NFS 기반 NAS 등)는 VM 부팅 볼륨, DB, 웹 서버 등 수천 개 테넌트의 4K~16K 랜덤 I/O를 처리하는 것이 목표이다. 그래서 IOPS의 공평한 분배(QoS), 안정적인 지연시간, 리소스 사용량이 많은 VM의 격리가 핵심 설계 포인트다.

반면 AI 스토리지는 GPU 수천 장이 동시에 하나의 잡을 돌리면서 초당 수 TB의 순차 읽기와 대량의 쓰기 요청을 쏟아낸다. NVIDIA SuperPOD 기준으로 GPU당 4GB/s 읽기를 요구하는데, 이건 일반 IaaS 볼륨 수십~수백 개 분량의 대역폭을 단일 클라이언트가 소비하는 수준이다.

B) 데이터 경로 아키텍처가 다르다

IaaS 스토리지는 하이퍼바이저 → 스토리지 게이트웨이/컨트롤러 → 백엔드로 이어지는 다단계 경로를 거치며, 이 과정에서 iSCSI/가상화 계층 오버헤드로 밀리초급 지연이 발생해도 VM 워크로드에는 충분하다. AI 스토리지는 이 경로 자체를 제거하는 방향으로 간다. 클라이언트(GPU 노드)가 수십~수백 개 스토리지 서버와 직접 병렬 통신하고, GPUDirect Storage로 CPU와 시스템 메모리까지 바이패스해서 NVMe → GPU 메모리 DMA 직행 경로를 만든다. 컨트롤러를 거치는 스케일업 구조 vs 컨트롤러 병목이 없는 스케일아웃 구조의 차이라고 봐도 된다.

C) 실패의 비용 단위가 다르다.

IaaS에서 스토리지가 느리면 특정 VM 들이 느려지는 문제지만, AI 클러스터에서 스토리지가 느리면 수천 장의 GPU가 동시에 멈춘다. 동기식 분산 학습은 가장 느린 데이터 공급 경로에 전체가 묶이기 때문이다. H100 클러스터에서 체크포인트 쓰기가 5분 걸리면 그 5분 동안 클러스터 전체가 유휴 상태가 되고, 이게 시간당 수천 달러의 손실로 직결된다. 그래서 IaaS 스토리지는 "가용성과 내구성"이 최우선 SLA라면, AI 스토리지는 "GPU를 굶기지 않는 지속 처리량"이 사실상의 SLA이다.

D) 공유의 의미가 다르다.

IaaS의 shared storage는 격리된 볼륨을 여러 테넌트에 나눠주는 "multi-tenancy 공유"이다. 반면 AI 스토리지는 수천 개 클라이언트가 같은 데이터셋, 같은 네임스페이스를 동시에 읽는 "single namespace 공유"이고, 여기서 메타데이터 서버가 새로운 병목으로 등장한다. 수십억 개 작은 파일을 수천 노드가 동시에 open/stat 하는 상황은 전통 NAS가 전혀 상정하지 않은 워크로드이다.

3. AI 인프라의 스토리지 기술

A) NVMe-oF (NVMe over Fabrics)

원격 NVMe를 로컬 직결 수준 성능으로 공유하는 프로토콜이다. 전송 방식에 따라 지연이 갈린다. NVMe/RoCE(RDMA)는 100~150μs(구현에 따라 수십 μs 추가) 수준의 낮은 지연과 일관된 p99를 제공하고, NVMe/TCP는 300~500μs로 높지만 특수 하드웨어 없이 기존 이더넷에서 배포 가능하다.
iSCSI(밀리초급) 대비 두 방식 모두 압도적이다. AI 인프라에서는 지연에 민감한 경로에 RoCE, 범용·클라우드 환경에 TCP를 혼용하는 것이 실무 패턴이다.

B) GPUDirect Storage (GDS)

NVIDIA Magnum IO 제품군의 핵심 기술로, 스토리지와 GPU 메모리 사이에 DMA 직접 경로를 만들어 CPU 시스템 메모리의 "바운스 버퍼"를 제거한다. 전통 경로는 스토리지→시스템 메모리→GPU 메모리의 다단계 복사를 거치며 CPU가 병목이 된다. GDS는 이를 우회해 대역폭을 높이고 지연·CPU 부하를 낮춘다. PCIe 스위치 아래 GPU·NIC·스토리지가 함께 있으면 CPU 경유 대비 최소 2배 대역폭이 가능하다.

C) 오브젝트 스토리지 (S3 호환, MinIO, Cloudian 등)

AI 데이터 레이크의 근간이다. 평면 주소 공간으로 페타바이트→엑사바이트 확장이 쉽고, TensorFlow·PyTorch·Spark가 S3 API로 직접 연결된다. 전통적으로 "빠른 파일 + 느린 대용량 오브젝트" 조합이었으나, 2025년을 기점으로 S3 over RDMA가 판을 바꾸고 있다.

D) 분산 캐싱/데이터 오케스트레이션 (Alluxio, JuiceFS)

느린 데이터 레이크(S3 등)와 GPU 사이에 고속 캐시 계층을 둔다. Alluxio는 글로벌 네임스페이스로 여러 스토리지를 통합하고 데이터 지역성을 최적화해 GPU 활용률을 최대 90%까지 끌어올린다고 밝힌다. JuiceFS는 메타데이터 엔진(Redis/TiKV)과 오브젝트 스토리지를 분리한 POSIX 파일시스템으로, 초당 수백 GB 읽기 처리량과 밀리초급 메타데이터 응답을 표방하며 MiniMax·Zhihu 등 중국 AI 기업들이 멀티클라우드 학습·체크포인트 저장에 쓴다.

E) KV 캐시 오프로딩 (NVIDIA Dynamo, LMCache)

추론 스토리지의 격전지다. LLM은 대화 문맥을 KV 캐시로 GPU 메모리(HBM)에 두는데, 요청이 몰리면 캐시가 비워지고 재계산 비용이 폭발한다. NVIDIA Dynamo는 KV 블록 매니저(KVBM)와 NIXL 전송 라이브러리로 KV 캐시를 GPU HBM→CPU DRAM→NVMe/네트워크 스토리지로 계층 오프로딩한다.

왜 AI 데이터센터는 800V DC로 가는가: 전력 아키텍처 대전환의 모든 것

삐야악이 — Sat, 4 Jul 2026 01:47:04 +0900

최근 NVIDIA의 젠슨황이 AI 데이터센터에 800V DC를 도입한다는 이야기를 자주하고 있다. 수 많은 전압 중에 왜 800V 이고 왜 DC인지 궁금했다. 현재 데이터센터의 서버들은 기본적으로 AC 전원이 공급되기 때문에 왜 DC가 중요한지 궁금했다.

이에 대해 공부해보기 위해 자료를 정리했고, 영상으로 본다면 안될공학에서 매우 잘 설명해주고 있기에 영상도 추천한다.

https://www.youtube.com/watch?v=ozj0cU8339o

TL;DR

AI GPU 랙의 전력 밀도가 Hopper 세대 약 40kW에서 Blackwell(GB200) 약 120kW, 2027년 Rubin Ultra "Kyber" 랙 600kW~1MW로 3년 만에 약 25배 폭증하면서, 기존 54V DC 랙 배전은 물리적 한계(구리 과부하, 공간 부족, 변환 손실)에 부딪혔다. 그 해법이 800V 고전압 직류(HVDC) 아키텍처다.
800V가 선택된 핵심 이유는 전압을 높이면 같은 전력을 더 적은 전류로 보낼 수 있어 구리와 I²R 손실이 급감하기 때문이며(P=VI), 동시에 1500V DC 저전압 규제 한계 이내에 머물면서 전기차(EV) 800V 플랫폼이 이미 성숙시킨 GaN 부품 생태계를 그대로 활용할 수 있어서다.
NVIDIA는 2025년 5월 Computex에서 800V HVDC를 공식화했고 2027년 Kyber 랙과 함께 양산 목표를 제시했다. 엔드투엔드 효율 최대 5% 개선, 유지보수 비용 최대 70% 절감, 구리 사용량 45% 감소, TCO 최대 30% 절감을 내세우지만, 고전압 DC 아크 안전·표준 미비·기존 인프라 호환이라는 과제도 남아 있다.

1. 배경: 기존 전력 아키텍처와 그 한계

전통적인 데이터센터 전력 경로는 여러 번의 변환을 거친다. 전력은 중전압 AC(예: 13.8kV, 혹은 35kV)로 들어와 변압기에서 저전압 AC(415V 또는 480V)로 강압되고, UPS에서 배터리 저장을 위해 DC로 변환됐다가 다시 AC로, 그리고 랙 내부 PSU에서 다시 54V DC로 변환된 뒤 컴퓨트 트레이에서 GPU 코어 전압으로 최종 강압된다.

이 방식은 일반 목적 서버에는 충분했다. SemiAnalysis의 GB200 하드웨어 분석에 따르면 "일반 목적 CPU 랙은 랙당 최대 12kW를 지원하고, 고밀도 H100 공랭식 랙은 통상 약 40kW/랙만 지원"하는 반면, GB200 NVL72는 "랙당 약 120kW를 요구"한다.

즉. AI 랙은 공랭식 H100 랙의 3배, 일반 CPU 랙의 10배에 달한다. NVIDIA에 따르면 GB200/GB300 NVL72는 MGX 컴퓨트·스위치를 구동하기 위해 최대 8개의 파워를 쓰는데, MW 스케일에서 54V로 구동하려면 파워만 랙 공간의 최대 64U를 차지해 컴퓨트를 넣을 자리가 없어진다.

2. 왜 800V인가: 물리적·기술적 이유

핵심 원리는 단순하다. 전력 P = 전압 V × 전류 I이므로, 같은 전력을 전달할 때 전압을 높이면 전류가 반비례로 줄어든다. 54V에서 800V로 올리면 전류는 약 15배 줄고 저항 손실은 약 220~278배까지 감소한다. 실제로는 이 손실 여유를 구리 단면적·무게·비용·배선 공간 절감으로 "환전"한다.

- 800V라는 숫자가 나온 이유

NVIDIA는 "전기차와 유틸리티급 태양광 산업이 이미 효율과 전력 밀도 향상을 위해 800 VDC 이상을 채택해, 데이터센터에 적용할 수 있는 성숙한 부품 및 모범사례 생태계를 만들어 놓았다"고 밝힌다. Porsche Taycan, Hyundai E-GMP 등 800V EV 플랫폼이 이미 SiC/GaN 부품의 양산 규모와 비용 곡선을 성숙시켜 놓은 것이 결정적 배경이다.

즉 이미 시장에 800V DC로 전력 인프라가 잘 갖춰져 있기 때문에 800V라는 숫자가 나온 것이다.

3. 근데 왜 AC가 아니라 DC인가?

- 칩은 어차피 DC로만 동작한다

GPU, CPU, 메모리 등 모든 반도체는 직류로만 작동한다. 그런데 전력망은 AC로 들어온다. 그래서 기존 데이터센터는 전력망 AC → 변압기 → UPS에서 AC→DC(배터리 충전용)→다시 AC → 랙 PSU에서 또 AC→DC → DC-DC 강압 → 칩 의 과정을 거친다.

이 과정에서 AC와 DC 사이를 여러 번 왔다 갔다 한다. 변환할 때마다 몇 %씩 손실이 생기고, 변환 장치 하나하나가 고장 지점이자 발열원이다. 처음부터 시설 레벨에서 DC로 한 번만 정류해서 쭉 DC로 보내면 이 중간 변환들이 통째로 사라진다. 어차피 종착지가 DC라면, 굳이 중간에 AC를 유지할 이유가 없다는 거다.

- 배터리와 신재생 에너지도 전부 DC입니다
UPS 배터리, 대규모 에너지 저장장치, 태양광 패널은 본질적으로 DC 장치이다. AC 체계에서는 이들을 쓰려면 매번 변환기를 거쳐야 하지만, 시설이 DC 버스로 통일되면 배터리를 버스에 직결할 수 있다. AI 학습 워크로드는 전력 수요가 수 밀리초 단위로 요동치는데, DC 버스에 붙은 배터리가 이 변동을 흡수하는 완충 역할까지 해준다.

4. 그럼 현장에서 800V DC AI 데이터센터가 있는가?

대표적 사례) Foxconn 가오슝 K-1

Foxconn의 40MW급 가오슝-1(K-1) 데이터센터가 800 VDC로 실제 가동 중이다. Foxconn은 2025년 10월 NVIDIA와의 협력을 발표하면서 Computex 2025에서 공개된 800 VDC 전력 아키텍처를 가오슝 K-1 AI 데이터센터 프로젝트에 최초로 적용한다고 밝혔고, 이 시설은 AI 서버·데이터센터·신재생에너지 통합 역량을 보여주는 실증 사이트 역할을 한다.

https://www.foxconn.com/en-us/press-center/press-releases/latest-news/1848

Hon Hai Technology Group (Foxconn) Collaborates with NVIDIA On 800 VDC Power Architecture For Next Generation AI Factory - Hon

14 October 2025, San Jose, California – Hon Hai Technology Group (“Foxconn”) (TWSE:2317) today announced it is collaborating with NVIDIA to implement the 800 VDC power architecture for AI factories announced at Computex 2025, marking the next step t

www.honhai.com

5. 앞으로는 어떤가? NVIDIA가 주장하는 800v가 표준이 될 것인가?

방향은 이미 정해졌다고 헌다. 업계는 메가와트급 이상에서 54V가 물리적으로 한계라는 데 모두 동의하며, 800VDC 전환은 실재하고, 자금이 투입됐고, NVIDIA의 2027년 일정에 맞춰져 있다. 용량을 구축하는 입장에서 엔지니어링 질문은 고전압 DC로 갈지 말지가 아니라 어느 토폴로지로 표준화할지이다. 즉 "DC냐 AC냐"는 끝난 논쟁이고, 남은 건 "어떤 DC냐"이다.

https://www.drybulb.com/writing/800vdc-power-architecture

The 800VDC Rollout: How the AI Factory Power Architecture Is Taking Shape | Drybulb

Everyone agrees 54V is dead above a megawatt. Inside the monopolar-vs-bipolar split, the reference designs, and the supplier ecosystem powering the next generation of AI factories.

www.drybulb.com

업계는 800VDC로 수렴했지만 같은 800VDC로 수렴한 건 아니다. NVIDIA는 단극 800V를, Google·Meta·Microsoft·Amazon의 OCP 연합은 양극 ±400V를 쓴다. AMD는 독자 전력 경로를 만들지 않고 Meta의 Open Rack Wide와 OCP 표준 위에 Helios 랙을 올렸는데, 개방성과 EV 기반 ±400V가 비용과 멀티벤더 공급에서 이긴다는 데 베팅한 것이다.

전력에 대해서는 아직 표준이 정해지지 않았다. 하지만 NVIDIA가 시장을 이끌어 가는 추세에서 800V DC를 쓰는 곳이 더 많아지지 않을까 하는 생각이 있다.

시스템 엔지니어로서 AI 데이터센터를 공부하면서 단순히 GPU와 네트워크 뿐 아니라 그 주변 환경인 전력까지도 새롭게 환경이 변화한다는 점에서 매우 흥미로웠다. 전력 뿐 아니라 공조시스템도 많은 변화를 가져오고 있다. 더 이상 공랭식으로는 열을 식힐 수 없으므로 수냉식과 액침식 등 다양한 방법으로 칩을 냉각하는 기술이 나오고 있다.

다음에는 이런 공조시스템에 대해서도 공부해보려고 한다.

AI DC 네트워크 구조의 기본 - Leaf Spine 구조에 대해 알아보자

삐야악이 — Sat, 27 Jun 2026 00:49:29 +0900

AI DC 네트워크를 공부하면 우리가 알던 3계층(액세스–애그리게이션–코어)가 아닌 Leaf-Spine 구조만 나온다.

Leaf Spine 이 무엇이고, AI DC 네트워크에서 왜 필요한지 정리해본다.

전통적인 네트워크

옛날 데이터센터는 north-south(남북) 트래픽 중심이었다. 즉, 외부 사용자 → 서버 → 응답이라는 위아래 방향의 흐름이다. 전통적 3계층(액세스–애그리게이션–코어)은 바로 이걸 잘 처리하도록 설계되어 있었다.
가상화가 본격화되면서, 그리고 MSA 아키텍처가 부상하면서 상황은 달라지기 시작했다.
east-west(동서) 트래픽, 즉 서버 ↔ 서버 간 옆방향 통신이 폭증했다. 3계층 구조에서 서버 A가 서버 B와 통신하려면 트래픽이 액세스 → 애그리게이션 → (때로는 코어까지) → 다시 내려오는 식으로 위로 올라갔다 내려와야 해서 비효율적이었다.

3계층에서는 출발지·목적지에 따라 거치는 홉(hop) 수가 달랐다. 같은 액세스 스위치 아래면 가깝고, 다른 랙 또는 열이면 코어까지 갔다 와야 하고. 그래서 지연시간 예측이 어려웠다. 반면 Leaf-Spine은 어디서 어디로 가든 항상 leaf → spine → leaf의 2홉이라 지연이 일정하고 예측 가능하게 되었다.

Leaf Spine 구조, 그래서 어떤 건데?

리프-스파인은 네트워크 스위치를 딱 두 계층으로만 구성하는 구조다.

리프(Leaf): 서버가 연결되는 스위치. 랙 맨 위에 놓여서 ToR(Top-of-Rack) 스위치라고도 부른다.
스파인(Spine): 리프끼리만 연결해 주는 백본 스위치. 서버는 스파인에 직접 붙지 않는다.

규칙은 간단하다. 모든 리프가 모든 스파인에 연결된다(풀메시). 대신 리프끼리, 스파인끼리는 직접 연결하지 않는다.

Leaf-spine 구조, 구축 방법 (스위치 입장)

리프-스파인이 좋다는 이야기는 많이 들었을 것이다. 그런데 막상 "그래서 스위치 설정이 뭐가 달라지는데?"라고 물으면 설명이 막히는 경우가 많다. 토폴로지 그림은 단순해 보여도, 실제로 스위치에 들어가는 설정은 철학 자체가 다르다. 이 글에서는 전통적 3계층과 리프-스파인의 스위치 설정이 어떻게 달라지는지를 항목별로 비교한다.

1. 루프 방지: STP → 라우팅 (ECMP)

3계층

액세스·애그리게이션 계층이 대부분 L2로 묶여 있다.
루프를 막기 위해 **STP(Spanning Tree Protocol)**가 필수다.
STP는 중복 링크를 **차단(blocking)**해 버린다. 이중화 링크를 깔아도 절반은 놀게 된다.
설정 예: spanning-tree mode rapid-pvst, 루트 브리지 우선순위 지정 등

Leaf-spine

리프–스파인 사이를 L3(라우팅)로 연결한다. L2 루프 자체가 생기지 않으므로 STP의 역할이 거의 사라진다.
대신 ECMP(Equal-Cost Multi-Path)로 모든 등가 경로에 트래픽을 분산한다. 4개의 업링크가 있으면 4개를 동시에 다 쓴다.
STP는 만일을 대비해 리프 아래 서버 포트 쪽에만 최소한으로 남겨두는 정도다(BPDU Guard 등).

2. 라우팅 프로토콜: BGP 중심

3계층

L2가 넓다 보니 스위치 자체에 라우팅 설정이 적었다. L3 경계(게이트웨이 라고 부름)는 주로 애그리게이션/코어에 몰려 있었다.
HSRP/VRRP 같은 게이트웨이 이중화 프로토콜을 스위치에 설정했다.

Leaf-spine

각 리프가 라우터처럼 동작한다. 데이터센터에서는 eBGP가 사실상 표준이다(RFC 7938 권고).
모든 리프–스파인 링크마다 BGP 세션을 맺는다. 보통 /31(또는 /30) 서브넷을 쓴다.
각 리프·스파인에 고유한 AS 번호를 부여하고, BGP가 다중 경로(multipath)를 자연스럽게 광고한다.

3. 확장 방식

3계층

규모를 키우려면 코어 용량을 늘리거나 구조를 다시 짜야 하는 경우가 많았다. 오버서브스크립션도 위로 갈수록 심해졌다.

리프-스파인

서버를 늘리려면 리프를 추가하고, 대역폭을 늘리려면 스파인을 추가한다.
새 스위치를 추가할 때도 동일한 BGP·ECMP 설정 템플릿을 그대로 적용하면 되므로 자동화(Ansible 등 IaC)와 궁합이 좋다.

AI DC 네트워크에서 Leaf Spine이 왜 중요한가?

Leaf-spine은 사실 새로운 기술이 아니다. 일반 데이터센터에서는 이미 10년 넘게 표준이었다. 그런데 요즘 들어 AI 데이터센터 이야기가 나올 때마다 Leaf-spine이 다시 화두에 오른다. 왜일까? 답은 간단하다. AI 학습 트래픽이 Leaf-spine이 가장 잘하는 일을 극단까지 밀어붙이기 때문이다.

핵심: AI 학습은 "east-west 통신"의 끝판왕이다

AI 분산 학습은 이 east-west 트래픽을 상상 이상으로 극단적으로 만든다.

GPU 수백~수천 개가 하나의 모델을 함께 학습할 때, GPU들은 매 학습 스텝마다 계산한 gradient(기울기 값)를 서로 끊임없이 교환해야 한다. 내가 계산한 값과 네가 계산한 값을 모두 합쳐서 다시 모두에게 나눠주는 식이다. 이것을 All-Reduce라고 부른다.

이 통신량이 어느 정도냐면, 405B 규모 모델 기준으로 All-Reduce 한 번에 네트워크로 약 1.4TB가 이동한다. 그것도 학습이 끝날 때까지 수없이 반복된다. 8-GPU 서버 한 대만 봐도 north-south 대비 8~16배의 east-west 트래픽을 만든다. (AI 에게 물어본 결과라 참고만 해야함)

즉, AI 데이터센터의 네트워크는 "가끔 서버끼리 통신하는" 수준이 아니라 "수천 개 GPU가 동시에 풀스피드로 서로 데이터를 쏟아붓는" 환경이다. 이 환경에서 Leaf-spine의 장점은 선택이 아니라 필수가 된다.

Leaf-spine 위에 구현되는 AI 전용 네트워크 기술들

RDMA (RoCEv2 / InfiniBand): CPU와 운영체제를 거치지 않고 GPU 메모리끼리 직접 데이터를 주고받는 기술이다. TCP/IP가 10~50µs 걸릴 지연을 약 2µs까지 낮춘다.
무손실 네트워크 (PFC / ECN / DCQCN): 패킷 하나만 떨어져도 RDMA는 전체 데이터를 재전송해 GPU가 몇 초씩 놀게 된다. 그래서 패킷을 절대 버리지 않는 무손실 패브릭을 구성한다.
Rail-optimized 토폴로지: 각 노드의 같은 번호 GPU(NIC)를 동일한 리프 스위치에 모아 연결해, 같은 역할의 GPU끼리는 항상 1홉으로 통신하게 만드는 변형 설계다. All-Reduce 성능을 극대화한다.
스케일업 vs 스케일아웃 분리: 랙 내부는 초고속 NVLink(스케일업), 랙 사이는 리프-스파인 RDMA 패브릭(스케일아웃)으로 역할을 나눈다.

RoCEv2 학습

삐야악이 — Sun, 21 Jun 2026 17:35:47 +0900

개요

AI 데이터센터 네트워크 기술에 대해 학습하고 있다. 그 중 새롭게 알게된 단어인 RoCEv2 기술에 대해 학습한 내용을 정리해보았다.

컴퓨팅 패러다임의 변화와 RDMA 기술의 부상

현대의 대규모 데이터센터는 인공지능 모델의 분산 학습, 고성능 컴퓨팅(HPC), 그리고 초저지연 스토리지 네트워크 환경으로 급격히 진화하고 있다. 수천 대의 GPU가 병렬로 연산을 수행하고 거대한 파라미터를 실시간으로 동기화하는 환경에서는, 네트워크 패브릭의 대역폭과 극단적인 저지연 성능이 전체 클러스터의 효율성을 결정짓는 핵심 병목이 된다. 전통적인 TCP/IP 스택은 CPU가 네트워크 패킷 처리를 전담하는 구조로, 통신 속도가 100Gbps를 넘어 400Gbps, 800Gbps로 진입하는 현대의 인프라에서 막대한 연산 자원 낭비와 응답 지연을 초래하여 더 이상 지속 가능하지 않다.

이러한 구조적 한계를 근본적으로 해결하기 위해 도입된 기술이 원격 직접 메모리 접근(RDMA, Remote Direct Memory Access)이다. RDMA는 네트워크 어댑터가 호스트의 CPU나 운영체제의 개입 없이, 로컬 메모리와 원격지 노드의 메모리 간에 데이터를 직접 읽고 쓰는 기술이다. 이를 통해 CPU 부하가 최소화되며, 데이터 전송 지연 시간을 마이크로초 단위로 극단적으로 단축할 수 있다.

과거 RDMA는 주로 고비용의 특수 목적용 InfiniBand 네트워크에서 제한적으로 사용되어 왔으나, 기존 이더넷 인프라가 지닌 보편성과 경제성을 유지하면서도 RDMA의 압도적인 성능을 결합하고자 하는 산업계의 요구에 따라 이더넷 기반의 RDMA 프로토콜이 지속적으로 고안되었다. 그 결과, 라우팅이 가능한 Layer 3 프로토콜인 RoCEv2(RDMA over Converged Ethernet version 2)가 등장하였으며, 현재 대규모 멀티 테넌트(Multi-tenant) 클라우드 및 AI 데이터센터 네트워크의 사실상 표준으로 확고히 자리 잡았다.

고성능 통신 프로토콜의 아키텍처 비교 분석

데이터센터 내 고성능 네트워크 시장은 오랜 기간 특수 목적용인 InfiniBand 패브릭이 주도해 왔으나, 점차 범용 이더넷 기반의 iWARP와 RoCE 프로토콜이 그 자리를 대체하거나 보완하는 추세이다. 이 세 가지 프로토콜은 성능, 비용, 운영 복잡성 측면에서 뚜렷한 아키텍처적 차이를 보인다.

특성 및 기준	InfiniBand (IB)	RoCEv2	iWARP
기반 전송 계층	InfiniBand Native	UDP / IPv4 또는 IPv6	TCP / IP
물리적 네트워크 환경	전용 케이블 및 IB 전용 스위치 필수	범용 이더넷 스위치 적용 가능	범용 이더넷 스위치 적용 가능
L3 라우팅 지원 여부	독자적인 서브넷 라우팅 체계	IP 라우팅 지원	IP 라우팅 지원
무손실(Lossless) 보장 방식	Credit-based Flow Control (하드웨어 레벨)	PFC (Priority Flow Control) 및 DCQCN	TCP 본연의 윈도우 기반 재전송 메커니즘
종단 간 지연 시간 (Latency)	1 ~ 2 µs (최저 수준)	2 ~ 5 µs (튜닝에 따라 변동)	5 µs 이상 (TCP 스택 처리 오버헤드 존재)
도입 비용 및 운영 복잡도	매우 높음 / 전문 지식 및 별도 인프라 필요	중간 / 이더넷 기반이나 PFC, ECN 튜닝 요구됨	낮음 / 구성이 간편하나 확장성 및 성능 제약
네트워크 실패 복구	하드웨어 기반의 독립된 고속 페일오버	이더넷 페일오버 (잘못된 설정 시 혼잡 확산 위험)	TCP 재시도 로직에 의존 (지연 시간 증가 수반)
주요 적용 워크로드	단일 테넌트 기반 최고 성능 HPC 클러스터	대규모 AI 훈련, 클라우드 인프라, NVMe-oF	소규모 인프라

초거대 AI 클러스터 및 NVMe-oF 인프라에서의 RoCEv2 활용 전략

현재 구글, 메타, 마이크로소프트 등 대규모 클라우드 서비스 제공자(CSP)들이 수만 대의 최상위 계층 GPU(H100, GB200 등)를 엮어 초거대 모델용 AI 트레이닝 클러스터를 구축할 때, 데이터 분배와 역전파 그래디언트 동기화 처리를 위한 스위칭 백본으로 전면 채택하고 있는 것이 바로 RoCEv2 기반의 레일 최적화 패브릭이다.

1) GPUDirect RDMA와 대규모 분산 모델 학습 가속

AI 모델 학습, 특히 수백 기가바이트의 파라미터를 다루는 분산 학습 알고리즘 과정에서는 각 컴퓨팅 노드의 GPU 메모리 내에 계산된 가중치를 다른 모든 노드의 GPU들과 주기적으로 통합하고 분배하는 집단 통신 연산이 필수적으로 요구된다. 과거의 제한된 TCP/IP 아키텍처에서는 이를 위해 GPU 내부의 텐서 데이터를 PCIe 버스를 통해 호스트 시스템 RAM으로 일일이 복사한 뒤, CPU가 이를 IP 패킷으로 쪼개어 NIC로 전달하는 극도로 비효율적인 파이프라인을 거쳐야 했다. 이 과정은 CPU의 심각한 오버헤드를 유발하고 전송에만 수 초 이상의 지연을 야기하여, 값비싼 GPU 연산 코어를 멈춰 세우는 가장 큰 원인이었다.

이를 혁명적으로 단축시킨 기술이 GPUDirect RDMA이다. 이 기술은 운영체제 커널의 개입 없이 PCIe 스위치 컨트롤러를 통해 원격지의 GPU 물리 메모리와 로컬 호스트의 RNIC를 논리적으로 직접 연결한다. 수백 메가바이트 크기의 거대한 동기화 페이로드가 생성되더라도, RNIC의 하드웨어 엔진은 이 데이터를 원격 시스템의 GPU VRAM 공간으로 즉각적인 DMA(Direct Memory Access)를 통해 전송하며 CPU 사이클을 단 1%도 소모하지 않는다. 일례로 Google Cloud의 A3 Ultra 및 A4 인스턴스는 1대의 노드 내에 무려 8개의 RoCEv2 전용 하드웨어 RNIC를 장착하고, 이를 상단 스위치 계층에 물리적 충돌 없이 독립적으로 배선하는 이른바 '레일(Rail) 토폴로지' 설계를 적용하여, 노드 간 3.2 Tbps라는 경이적인 대역폭의 동기화 패브릭을 구성하고 있다.

2) NVMe over Fabrics (NVMe-oF) 기반의 스토리지 성능 극한화

GPU의 연산 자원 고도화 못지않게 중요한 난제는 끊임없이 소진되는 학습용 원본 데이터셋을 병목 현상 없이 지속적으로 GPU로 밀어넣는 고성능 스토리지 인프라의 확보이다. 과거의 DAS(Direct Attached Storage)나 TCP 기반의 iSCSI SAN 패브릭은 최신 SSD가 제공하는 초고속 IOPS와 대역폭을 네트워크 프로토콜 스택의 오버헤드 병목으로 인해 절반도 소화해 내지 못했다.

NVMe-oF (NVMe over Fabrics) 아키텍처, 그중에서도 NVMe/RoCE 방식은 RDMA가 지닌 이점을 네트워크 스토리지 영역으로 직접 확장한 차세대 규격이다. 이 아키텍처를 도입하면 거대한 데이터센터 반대편 랙에 장착된 수백 개의 JBOF(Just a Bunch of Flash) 내부 NVMe 드라이브를, 마치 서버 내부의 로컬 PCIe 버스 슬롯에 직결된 NVMe 드라이브처럼 마이크로초 수준의 초저지연 상태로 사용할 수 있다.

클라우드 인스턴스에서 devstack 구축하기

삐야악이 — Sun, 25 Jul 2021 12:49:25 +0900

devstack은 openstack 테스트 환경을 구축할 수 있는 가장 손 쉬운 방법이다. 보통은 자신의 컴퓨터에서 virtualbox vm을 생성해서 devstack을 설치하지만, 실수로 vm을 끄기라도 한다면 온전한 형태의 devstack을 다시 만들기는 어렵다. 이 경우 devstack 환경을 다시 만드는 것이 마음이 편하다.

그래서 요즘에 virtualbox를 이용하지 않고, 클라우드 인스턴스에 devstack을 구축해서 항상 구동중이면서 어디에서든지 접근할 수 있도록 하고 싶은 요구사항이 생겨났다. virtualbox에서 구현하는 것과 큰 차이는 없지만, 클라우드라는 환경에서 고려해야하는 점들이 있었고 어떻게 해결하였는지 이제부터 설명하겠다.

고민) provider network를 어떻게 제공할 것인가?

provider network는 OpenStack 입장에서 인터넷 통신이 가능한 (주로 공인 IP를 사용하는) 네트워크를 의미한다. 이 네트워크는 OpenStack에 floating ip를 제공하거나 가상 네트워크의 nat ip를 제공한다. virtualbox를 이용할 경우, 이 네트워크를 컴퓨터가 연결된 공유기의 네트워크와 인터페이스로 지정하고 공유기의 dhcp에서 일정 대역을 빼서 OpenStack에 할당해준다. 그런데 클라우드 인스턴스에서는 이런 네트워크를 어떻게 만들어야할까?

기본적으로 클라우드 인스턴스에는 인터넷이 가능한 네트워크에 연결된 nic 포트 하나가 제공된다. 제공되는 네트워크의 IP는 클라우드에 의해 자동으로 할당 및 관리되기 때문에 OpenStack에서 임의로 사용하기 어렵다. 따라서, 인스턴스 내부에서 가상의 provider network를 만들고 그것을 OpenStack이 사용하도록 해줘야한다.

방법) Linux Bridge로 가상의 provider network만들기

가상의 provider network를 만들기 위해 Linux Bridge를 이용할 것이다. Linux Bridge에 사설 네트워크를 할당한 뒤 iptables를 이용해 인터넷이 가능한 인터페이스와 nat를 시켜주면 bridge network에서도 인터넷이 가능하다.

그림으로 표현하면 다음과 같다.

apt install bridge-utils

brctl addbr mybr0
ifconfig mybr0 192.168.100.1 netmask 255.255.255.0 up
ip link set mybr0 up

iptables -I FORWARD -j ACCEPT
iptables -t nat -I POSTROUTING -s 192.168.100.0/24 -j MASQUERADE

고민2) 외부에서 horizon 접근가능하도록 설정하기

devstack을 설치하면 기본적으로 OS에 설정된 ip로 horizon을 비롯한 api endpoint를 지정한다. 클라우드 인스턴스 OS에 설정된 ip는 사설 대역이므로, 인스턴스에 floating ip (aws는 elastic ip)를 붙인다고 해도, api endpoint와 horizon을 온전하게 외부에서 이용하기 어렵다. 따라서, devstack 설정파일에 인스턴스의 floating ip를 넣어주고, 그 아이피로 바인딩할 수 있게 loopback interface에 ip를 넣어줘야한다.

예를 들어 인스턴스에 연결된 floating ip 가 1.2.3.4 라면 다음과 같이 loopback interface에 ip를 추가한다.

ip addr add 1.2.3.4/32 dev lo

local.conf 설정

마지막으로 local.conf를 설정해주면 devstack을 구축할 준비가 완료되었다.

이 설정에서는 openvswitch를 이용해 네트워크를 구축하며, floating ip 대역으로 192.168.100.0/24 를 사용하고, 그 네트워크를 제공하는 인터페이스는 위에서 생성한 mybr0 Linux Bridge로 지정하였다.

[[local|localrc]]
HOST_IP=1.2.3.4
FORCE=yes
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD

# Disable services
disable_service etcd3
disable_service ovn
disable_service ovn-controller
disable_service ovn-northd
disable_service q-ovn-metadata-agent

# Use openvswitch as the ml2 plugin driver
Q_AGENT=openvswitch

# Enable Neutron services neutron-server, neutron-openvswitch-agent,
# neutron-dhcp-agent, neutron-l3-agent and neutron-metadata-agent
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-meta

## Neutron options
# 인스턴스에 할당할 Floating ip 대역
FLOATING_RANGE="192.168.100.0/24"      
# 인스턴스 fixed ip 대역
IPV4_ADDRS_SAFE_TO_USE="10.0.0.0/22"    
Q_FLOATING_ALLOCATION_POOL=start=192.168.100.50,end=192.168.100.250
PUBLIC_NETWORK_GATEWAY="192.168.100.1"
PUBLIC_INTERFACE=mybr0

# Open vSwitch provider networking configuration
Q_USE_PROVIDERNET_FOR_PUBLIC=True
OVS_PHYSICAL_BRIDGE=br-ex
PUBLIC_BRIDGE=br-ex
OVS_BRIDGE_MAPPINGS=public:br-ex

[[post-config|/$Q_PLUGIN_CONF_FILE]]
[ml2]
type_drivers=flat,gre,vlan,vxlan
tenant_network_types=vxlan
mechanism_drivers=openvswitch,l2population

[agent]
tunnel_types=vxlan,gre

이렇게 설정하면 public interface로 mybr0를 이용하고, ovs가 public network를 이용하기 위한 ovs bridge `br-ex`를 만들어서 floating ip network와 연결하도록 설정한다.

아래는 "ovs-vsctl show" 를 통해 확인한 br-ex ovs bridge 설정 내용이다.

    Bridge br-ex
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        datapath_type: system
        Port phy-br-ex
            Interface phy-br-ex
                type: patch
                options: {peer=int-br-ex}
        Port mybr0
            Interface mybr0
        Port br-ex
            Interface br-ex
                type: internal

그리고 `ip a`를 통해 인터페이스를 확인해보면 mybr0에 할당한 192.168.100.1 이, br-ex로 옮겨져간 것을 확인할 수 있다.

10: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 46:6f:e7:cc:b4:4b brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.1/24 brd 192.168.100.255 scope global br-ex
       valid_lft forever preferred_lft forever
    inet6 2001:db8::2/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::446f:e7ff:fecc:b44b/64 scope link
       valid_lft forever preferred_lft forever

[ Linux ] iptables 를 이용하여 간단히 port forwarding 하기

삐야악이 — Thu, 3 Oct 2019 23:33:07 +0900

서버가 특정 아이피에 대해서만 접속이 허용될 때, 그 아이피를 가진 proxy 서버를 만들어 접속을 하는 방법이 있다.

이 때, proxy 서버를 좀 더 간편하게 만들 방법을 찾아보던 중, iptables 를 이용하여 port forwarding 하는 방법을 찾았다.

이 방법을 쓰니, OpenVPN으로 VPN 서버를 구축하고 클라이언트 설정하는 번거로움을 해결할 수 있었다.

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport [source port] -j DNAT --to [dest IP]:[dest PORT]

위 내용은 eth0 인터페이스를 대상으로 dport 에 적은 포트로 오는 요청을 –to 로 보내버리는 설정이다.

iptables -t nat -D PREROUTING [rule num]

[ maven ] 운영환경 별, 설정 파일 분리하기

삐야악이 — Thu, 3 Oct 2019 23:31:03 +0900

maven profile 을 이용한 설정 파일

어플리케이션을 개발하다보면 다양한 설정파일들을 관리하게 된다. 데이터베이스 접근 정보, 레디스 접근 정보 등..

이런 설정들은 개발, 테스트, 운영 단계별 서로 다른 설정을 가질 수 밖에 없다. 만약 이런 내용들이 코드에 정적으로 들어가 있다면 단계별로 코드의 내용을 수정해서 다시 컴파일을 해야하는 매우 번거로운 상황이 일어날 것이다.

만약 별 다른 기능을 사용하지 않는다면 아마 코드에는 다음과 같은 내용이 들어갈 것이다.

if(env.equals("local")) {
    ......
}
else if (env.equals("dev")) {
    .....
}

maven 을 이용해서 개발하는 java 프로젝트일 경우, maven profile 을 이용하여 빌드 시, 외부에서 넣어주는 파라미터를 기준으로 서로 다른 설정파일을 참조하게 하여 환경 별로 다른 설정파일을 선택하도록 해줄 수 있다.

설정 파일

설정파일은 다양한 포멧을 가질 수 있다. 가장 많이 쓰이는 것이 yaml 와 properties 이다. maven 에서는 properties 파일을 이용해서 설정 파일을 관리하고 있다.

properties 설정 파일의 형태는 다음과 같이 key = value 형태를 가진다.

url = http://printf.kr

그리고 설정 파일은 대부분 src/main/resources 폴더 아래에 위치한다.

환경 별 리소스 폴더 구분

위에서 설정 파일은 대부분은 src/main/resources 에 저장된다고 하였다. 그럼 환경별로 리소스 폴더를 다르게 두고 그것을 classpath 에 넣으면 환경 별로 설정파일을 다르게 가져갈 수 있다.

개발자 환경
- src/main/resources-local
개발 서버 환경
- src/main/resources-dev
운영 서버 환경
- src/main/resources-real

와 같이 리소스 폴더를 구분해 줄 수 있다.

maven profile 설정

이제 maven profile 설정을 통해, 빌드 단계에서 원하는 리소스 폴더를 classpath 에 추가하는 작업을 진행할 것이다.

우선, pom.xml 에 아래와 같이 profile 을 추가한다.

<profiles>
    <profile>
      <id>dev</id>
      <properties>
        <env>dev</env>
      </properties>
    </profile>
    <profile>
      <id>local</id>
      <properties>
        <env>local</env>
      </properties>
    </profile>
    <profile>
      <id>real</id>
      <properties>
        <env>real</env>
      </properties>
    </profile>
</profiles>

이렇게 설정된 profile 을 maven 명령어에서 P옵션으로 같이 선택할 수 있다.

maven clean package -P dev

다음은 선택된 profile 에 맞는 리소스 폴더를 classpath 에 넣는 작업이다. 기본즉으로 src/main/resources 는 들어가고 부가적으로 환경 별 리소스 폴더를 넣으면 된다. 아래 내용을 pom.xml 의 build 부분에 추가한다.

<resources>
  <resource>
    <directory>src/main/resources</directory>
  </resource>
  <resource>
    <directory>src/main/resources-${env}</directory>
  </resource>
</resources>

자 여기까지 하면 빌드 시, 환경에 맞는 설정파일이 classpath 로 들어가게 된다.

코드에서 properties 값 가져오기

이제 코드에서 properties 에 설정된 값을 가져와야 한다.

Properties prop = new Properties();
prop.load(OAuthPayco.class.getClassLoader().getResourceAsStream("payco.properties"));
clientId = prop.getProperty("clientId");
clientSecret = prop.getProperty("clientSecret");

위 코드와 같이 아주 간단하게 코드에서 properties 에 있는 값을 가져올 수 있다.

참고 자료

https://www.lesstif.com/pages/viewpage.action?pageId=14090588

[2017년 회고] 주니어 시스템 엔지니어로써의 1년

삐야악이 — Thu, 3 Oct 2019 23:28:52 +0900

나에게도 생소했던 시스템 엔지니어로써의 1년을 정리한다

2017년 1월 2일 나는 IT인프라 직군으로 입사를 하였고, 현재는 시스템 엔지니어라는 역할을 가지고 일을 하고 있다.
지난 1년동안 나에게도 생소했던 시스템 엔지니어로써의 1년을 정리해보려고 한다.

입사하면서..

그동안 학교에서 배운 것 그리고 활동한 것은 개발에 대한 것이었다. 개발자들과 생활하였고 개발에 대한 문화를 배우고 경험해왔다.
하지만 내가 앞으로 지낼 곳은 인프라를 다루는 곳이다. 평소에 IT인프라에 대해 많은 호기심이 있었다. 쉽게 접할 수 없는 분야이기도 하고 시설과 장비 또한 쉽게 접할 수 없어서 나에겐 우주와 같이 선망의 대상이었다.

인프라에 대해 잘 몰랐던 나는 입사하면서 시스템 아키텍처를 설계하고(예를 들면 MQ는 무엇을 쓰고 어떻게 구성할 것이며.. 디비들은 어떻게 구성할 것인가 등..) 테스트하고 서비스의 인프라를 구축/운영하는 업무를 하게 되지 않을까? 라는 생각을 가졌다.

하지만, 실무에서의 인프라는 내가 처음에 생각했던 것과는 약간 다른 세상이었고, 더 큰 매력을 가지고 있었다.

신입 사원 교육

회사에서 자체적으로 진행하는 신입 사원 교육은 건너뛰고, 팀에 배정받은 다음에 진행한 교육이다. 처음 신입 사원 교육에 진행할 때 이용한 도서는 “인프라 엔지니어의 교과서” 이다.

책은 매우 얇았지만 IT인프라에 대한 모든 내용의 엑기스를 정말 잘 담아냈다. 이 책을 읽고 구두 시험을 보고, 책에서 설명하는 내용이 실제 회사 인프라에 어떻게 적용되어 있는지를 배웠다. IT인프라에 대해 맛을 보고 싶은 분에게 추천한다.

이 책을 시작으로 “서버/인프라를 지탱하는 기술” 과 “서버 부하분산 입문” 을 읽고 세미나를 하면서 시스템 엔지니어로서 기본 역량을 다져나갔다.

동시에 회사 인프라에 대한 교육도 진행되었다. 대충 아래와 같은 내용으로 교육을 받았다.

IDC 에 대한 이해
- 공조, 전력, 화재예방, 입/출고 처리, 라벨링, 하드웨어 파트 관리
- 케이블링, IDC 모니터링 등..
IDC 네트워크 장비에 대한 이해
네트워크 ACL 및 보안 정책
서비스 별 IP 대역 및 IP 할당/관리 정책
다양한 인프라 운영도구
- CMDB 포함
표준 서버 스펙 및 OS 설정
장애 대응 방법
등…

적어놓으니 엄청 많다. 저것들이 시스템 엔지니어로써 업무를 하기 위한 기본 지식이고 서비스별로 특화된 지식들도 더 필요하게 된다.

DNS
CDN
GSLB
Storage
Backup
VMWare ESXi
Windows Hyper-V
등등…

배워야할 것들이 매우 많기에 지금도 나는 업무를 받으면서 계속해서 공부하고 배워나가고 있다.

IDC에 대한 이야기

나에게 IDC는 환상의 나라 에버랜드와 같은 곳이었다. 고등학생 때 친구들과 서버를 구매하여 가지고 놀았기에 몇 번 IDC에 가본적은 있지만, 갈 때 마다 IDC는 신비로운 공간이었고 그 내부를 더 알고 싶었다. 심심할 때면 Youtube 에서 데이터센터, IDC로 검색해서 나오는 데이터센터 소개 영상을 보면서 꿈을 꾸곤 했었다.

이제 나에게 IDC는 더 이상 환상의 나라 에버랜드와 같은 곳이 아니다. IDC에서 직접 일 하는 것은 아니지만 IDC에 있는 서버들과 인프라 요소 하나하나가 나의 삶의 터전이 되었다. 하지만 난 아직도 IDC에 가면 눈이 휘둥그래져서 구경하곤한다.

내가 다니는 회사는 국내에 몇 안되는 자사가 직접 설립한 IDC를 보유한 회사이다. 이것은 주니어 시스템/인프라 엔지니에게 엄청난 복지(?)이다. IDC이용자가 아닌 제공자이기에 IDC에 대한 정말 모든 것들을 생생하게 경험하고 보고 들을 수 있기 때문이다. 상세한 네트워크 구조와 그에 쓰이는 장비들..처음에 IDC에 갔을 때, 통신사와 연결되어있는 코어 라우터를 정말 한동안 바라보곤 했었다.. IDC의 다양한 시설(공조, 전력 등)을 관리하는 방법, 모니터링 대시보드.. 네트워크 현황 등..정말 신기한 것들로 가득차있는 곳이다.

요즘은 클라우드를 많이 쓰기에 많은 주니어 개발자들이 IDC를 경험하진 못할 것 같다. 클라우드라고 부르는 것도 결국 물리적인 장비들로 이루어져있고 IDC가 없으면 안된다는 것을 알고나면 IDC가 궁금해질 것이다. 살면서 꼭! 한번쯤은 IDC에 가보는 것을 추천한다.

무엇을 공부하였나?

지금까지 내가 경험한(직접/간접) 시스템 엔지니어의 주요 업무는 아래와 같다.

인프라 용량 산정을 통해 선정된 스펙에 맞는 서버 공급
- 디스크, CPU, 메모리 등등.. 상황에 맞게 재조립해서 쓴다
- 그리고 운영체제를 설치한다.
서비스에 맞는 시스템 설계 및 구축
- 네트워크에 대한 내용은 네트워크팀에서 해준다.
- 서비스에 맞는 시스템 설정 및 관리
DNS/CDN 설정 및 모니터링
장애 시 1차적 대응 및 원인 분석

이 외에도 시스템 엔지니어의 업무영역은 매우 넓다. (아직 1년차라서 모르는게 많을 뿐이다)

1년동안 지내면서 내가 느낀 시스템 엔지니어에게 가장 필요한 스킬은 ‘리눅스‘ 이다. 회사의 대부분 시스템은 리눅스로 구축이 되어있다. 리눅스에 대한 깊은 이해가 없이는 업무를 절대로 진행할 수 없다. 사소한 설정 하나하나가 어떤 것을 의미하는지, 여러 시스템 로그들은 어떻게 분석하는지, 시스템 설정은 어떻게 해야하는지(예: bonding), 파티션 잡는 방법 등등 리눅스라는 운영체제에 대해 아주 깊은 지식이 필요로 한다. 이 지식을 기반으로 더 고급진(Docker라던지 Openstack 이라던지, HAProxy 라던지..) 기술들을 익히고 연마해 나가는 것이다.

그리고! 또 제일 중요한 것이 하나 있었다. HP, DELL, IBM 등 다양한 벤더에서 나오는 제품에 대한 이해. 어차피 엔지니어들은 물리적인 장비를 직접적으로 다루고 그에 대한 이해가 반드시 필요하다는 것을 알게 되었다. 모델별로 어떤 특징을 가지고 있는지, 설정은 어떻게 바뀌는지.. 하나하나가 업무를 하는데 정말 필요한 지식들이었다.

앞으로도 나는 공부할게 너무 많아서 하하 행복하다…..

앞으로 나는 어떻게 할 것인가?

아직 못 배운 기술들이 너무 많다.

우선은 장비에 대한 이해를 먼저 하고 싶다. 선배 엔지니어들을 보면 다양한 벤더사들의 모델별로 어떤 특징이 있고 무슨 문제점이 있는지 정말 콕 찌르면 술술술술 나온다. 물론 경험적인 면이 많이 차지하겠지만 회사에 예비로 되어있는 장비들을 가지고 메뉴얼과 함께 공부를 해야할 듯 하다.

리눅스… 리눅스를 쓴지는 어느덧 8년이 지나가고 있지만, 시스템 엔지니어로써 일하면서 정말 나는 아무것도 모르고 있었구나를 다시 한번 느끼고 있다. 서점에 가면 볼 수 있는 리눅스 관리하기 같은 책들을 사서 달달 외워야겠다. 업무하는데 리눅스를 몰라서 해맸던 적이 한둘이 아니다…

최신 기술. 요즘 Ansible이니 DevOps 니 여러 최신 기술들이 나오고 적용하는 사례가 나오고 있다. 지난 1년을 돌이켜보면 난 기존 인프라를 익히는데 모든 리소스를 사용하였고 최신 기술은 쳐다볼 엄두도 나지 않았다. 2018년에는 최신 기술이라 불리는 것들을 조금 들여다볼 수 있지 않을까?

마무리하며

간단하게 만 정리한다는 것이 엄청 많이 써버렸다. 두서 없이 써서 빠뜨린 내용도 있겠지만 지금의 나의 생각을 정리하기엔 충분했다. (만족?)
대다수의 또래 전공자들이 선택하지 않은 IT인프라, 시스템 엔지니어로서의 길을 선택했다.
아직은 모르겠다. 1년쯤 더 해보면 이 분야가 어떤지 조금은 알 수 있지 않을까? 아직은 모든게 새롭고 신기하고 흥미진진하다.

많은 사람들이 개발에 관심을 가지고 있다. 인프라에 관심을 가지고 있는 사람도 많아졌으면 좋겠다. 혼자서 놀기엔 심심하다.
2018년에도 열심히 일하는 주니어 일개미가 되어야겠다.
끝!

Virtualbox 네트워크 종류와 설정 방법

삐야악이 — Thu, 3 Oct 2019 23:23:51 +0900

Virtualbox 에서는 가상머신(이하 VM)에 할당할 수 있는 네트워크 종류를 총 6가지를 지원하고 있습니다. 각 네트워크 종류가 어떤 것을 의미하는지 살펴보고, 어떻게 설정을 할 수 있는지 알아보도록하겠습니다.

이 문서에서의 Virtualbox 실행 환경은 OS X 이며, 윈도우와 리눅스/OSX는 기본 설정에서 약간의 차이가 있습니다.

다음은 Virtualbox 에서 지원하는 네트워크 종류입니다.

NAT
NAT network
Bridge Adapter
Internal Network
Host-only Network
Generic Driver

여기에서는 맨 마지막 Generic Driver 를 제외한 나머지 5개에 대해서 설명하도록 하겠습니다.

보다 자세한 내용은 virtualbox 홈페이지의 문서를 참고해주시기 바랍니다.
( https://www.virtualbox.org/manual/ch06.html )

NAT

NAT(Network Address Translation) 는 VM이 외부 네트워크(인터넷)에 접근할 수 있는 가장 간단한 방법입니다. Host / Guest 에 어떠한 설정을 할 필요가 없기 때문에, Virtualbox 에서 VM을 생성하면 기본적으로 attach 되는 네트워크이기도 합니다.

VM에 NAT 인터페이스를 처음으로 붙이게 되면 10.0.2.0/24 대역이, 그 다음에는 10.0.3.0/24 대역이 할당되게 됩니다.

10.0.2.0/24 대역으로 할당되면, VM에는 10.0.2.15 가 부여되고, 기본 게이트웨이는 10.0.2.2 가 됩니다.

여러개의 VM을 만들고, NAT 를 붙이더라도 모두 동일하게 10.0.2.15 를 가지게 됩니다.

NAT Network

NAT Network는 공유기와 같은 환경을 만드는 것으로 이해하면 매우 쉽습니다.

여러 VM을 같은 네트워크에 속하게 하고 싶은데, 모두 인터넷이 가능하게 하고 싶을 때 사용하면 매우 유용합니다.

(보통 VM을 같은 네트워크로 묶고, 인터넷이 가능하게 하려면 VM 에 Host-only, NAT 두 개의 네트워크 인터페이스를 붙입니다)

위와 같이 Virtualbox 의 환경설정에서 GUI로 간단하게 NAT Network 를 구성할 수 있지만, 명령어를 통해서도 NAT Network 를 구성할 수 있습니다.

# 현재 생성되어있는 NAT Network 목록 조회
$ VBoxManage list natnetworks

# 192.168.0.0/24 대역의 DHCP 기능이 있는 NAT Network 생성
$ VBoxManage natnetwork add --netname natnet1 --network "192.168.0.0/24" --enable --dhcp on

# 위에서 생성한 'natnet1' NAT Network 시작하기
$ VBoxManage natnetwork start --netname natnet1

# 'natnet1' NAT Network 삭제하기
$ VBoxManage natnetwork remove --netname natnet1

natnetwork 관련 명령어에 대한 자세한 내용은 여기를 참고해주시기 바랍니다.

Bridge Network

Bridge Network 는 Virtualbox 가 호스트에 있는 네트워크 디바이스를 직접적으로 사용하는 네트워크입니다. 호스트가 사용하는 네트워크 환경을 그대로 이용할 수 있으며, VM이 호스트와 같은 물리적인 네트워크에 존재하게 할 수 있습니다.

사용하는 방법은 VM 설정의 네트워크탭에서 네트워크 어뎁터를 Bridge Network 로 선택하고, 연결할 호스트 네트워크 디바이스를 선택하면 됩니다.

단, OS X와 Linux에서는 무선 네트워크에 대해서는 Bridge Network 사용이 제한됩니다.

Internal Networking

Internal Networking 은 NAT Networking 과 같이 Virtualbox 내에서 완벽한 사설망을 구축할 수 있다는 점에서 동일하지만, 인터넷 연결이 되지 않는 점에서 다르다.

또한, Internal Networking 으로 할당된 IP로는 호스트에서 접근이 불가능하다. 오직 같은 Internal Networking 으로 연결된 VM들간에만 통신이 가능하다.

Internal Networking 을 생성하는 방법은 터미널에서만 가능합니다. 아래 명령어를 통해 생성 및 삭제를 할 수 있습니다.

# testinet 이라는 이름의 Internal Network 생성
vboxmanage dhcpserver add --netname testinet --ip 10.10.10.1 --netmask 255.255.255.0 --lowerip 10.10.10.2 --upperip 10.10.10.240 --enable

# testinet 이름의 Internal Network 제거
vboxmanage dhcpserver remove --netname testinet

생성 후, VM 네트워크 설정 부분에서 Attach to 를 ‘Internal Network’로 선택하고, Name 에 위에서 설정한 이름인 testinet을 입력하면 됩니다.

Host-only Networking

Host-only Networking 은 Internal Networking 과 기능면에서는 동일하다. 하지만 다른점은 Host-only Networking 은 호스트와도 통신이 가능하다는 것이다.

그렇게 때문에 Virtualbox 를 사용하는 사용자들이 호스트에서 VM에 접속하고 싶을 경우, (예를 들면 VM에 웹 서버를 실행하고 호스트에서 접속) Host-only Networking 을 VM에 추가하여 사용한다. (이 경우 VM이 인터넷도 사용해야할 경우 NAT 까지 붙이기도 한다.)

Host-only Networking 은 OS X 의 경우 기본적으로 6개가 생성되어 있다. 이를 이용할 수 도 있고, NAT Networking 에서 확인한 환경설정 화면에서 Host-only Networks 로 들어가서 추가로 생성할 수도 있다.

Openstack Network 구축 과정 이해 – LinuxBridge

삐야악이 — Thu, 3 Oct 2019 23:22:27 +0900

그림1. Openstack Mitaka 설치가이드의 네트워크 구성도

Ubuntu 14.04 Openstack Mitaka Install Guide 에서는 위의 네트워크 구성도를 기반으로 설정을 진행합니다.. 이 그림만 봐서는 Provider Network 의 역할이 무엇인지, 그리고 대부분의 오픈스택의 네트워크 구성도와는 다른 모습이여서 이해하는데 많은 어려움이 있었습니다.

이 포스트에서는 Install Guide 에서 제시하는 네트워크 구성도에 대한 이해와, 그것이 내부적으로 어떻게 구성되는지 명령어단위로 하나하나 분석하면서 알아보도록 하겠습니다.

Openstack Network 종류

많이 공개된 오픈스택 네트워크 구성도를 보면 크게 아래와 같이 3가지 네트워크로 구성됩니다.

Management Network : 관리용 네트워크. 각 컴포넌트(Nova, Neutron 등)이 서로 API 를 호출하는데 사용됩니다.
Tunnel Network : vm instance 간 네트워크를 구축하는데 사용되는 네트워크입니다. GRE, VXLAN 등의 기술이 사용됩니다. Overlay Network 라고도 부릅니다.
External Network : vm instance 가 인터넷과 통신하기 위한 네트워크.

Host 머신에 오픈스택을 설치하기 위한 인터넷 연결으로는 별도의 네트워크를 연결하거나, Management Network 를 인터넷에 연결되도록 구성합니다.

그림1을 보면 오픈스택 설치 가이드에서는 Management Network 와 Provider Network 이렇게 두 가지의 네트워크로만 구성하고 있습니다. Provider Network 는 무엇이고 Tunnel / External Network 는 어디로 간 것일까요? 이것은 설치 가이드에 나오는 Provider / Self-Service Network 에 대해 먼저 이해하고, 가이드에서는 각각의 네트워크를 어떤 용도로 사용하는지 파악하면 알 수 있습니다.

Provider / Self-Service Network 란?

설치 가이드 문서의 Neutron 설정부분에서 네트워킹 서비스를 설정하기 위해서 2가지 옵션 중 한가지를 선택해야합니다.

Provider Network : 오픈스택을 서비스하는 사람이 구축한 네트워크가 vm instance 에 할당되는 네트워크입니다. 서비스하는 사람이 ‘제공’ 하는 네트워크라는 의미에서 Provider Network 라고 합니다. 이 네트워크는 인터넷에 연결이 되어있는 네트워크입니다. (그렇다고 public ip 를 반드시 가진다는 것은 아닙니다.)
Self-Service Network : 오픈스택을 사용하는 사용자(Tenant)가 직접 자신만의 vm instance 를 위한 네트워크를 구축할 수 있는 네트워크입니다. 이 네트워크는 provider network 를 기반으로 GRE, VXLAN 등의 터널링을 통해 구축됩니다.

이 두 가지 옵션과 위에서 설명한 3가지 네트워크 종류와의 연관성을 정리하면 다음과 같습니다.

Provider Network = External Network
Self-Service Network = Tunnel Network + External Network

Virtualbox 로 네트워크 구성하기

이제 오픈스택을 설치하기 위해, virtualbox 로 네트워크를 구성해보도록 하겠습니다.

Internet
- virtualbox의 NAT 인터페이스
- 오픈스택 설치용 네트워크
- IP : Controller / Compute 가 동일하게 10.0.2.15
Provider Network
- virtualbox 의 bridge 인터페이스
- 공유기와 연결된 인터넷을 사용할 수 있는 네트워크
- Controller IP : 할당하지 않음
- Compute IP : 할당하지 않음
- IP 대역 : 172.32.0.0/24
Management Network
- virtualbox 의 host-only network
- host에서 virtualbox 의 vm 에 접속할 수 있는 네트워크
- Controller IP : 192.168.56.101/24
- Compute IP : 192.168.56.102/24

Neutron 주요 설정

Neutron 설정은 Mitaka 설치 가이드의 Self-Service Network 부분대로 진행하였지만, 기록을 위해 주요 설정 부분을 보여드립니다.

Controller

/etc/neutron/plugins/ml2/linuxbridge_agent.ini

[linux_bridge] physical_interface_mappings = provider:eth1 [vxlan] enable_vxlan = True local_ip = 192.168.56.101 l2_population = True

[linux_bridge]
physical_interface_mappings = provider:eth1

[vxlan]
enable_vxlan = True
local_ip = 192.168.56.101
l2_population = True

Compute

/etc/neutron/plugins/ml2/linuxbridge_agent.ini

[linux_bridge]
physical_interface_mappings = provider:eth1

[vxlan]
enable_vxlan = True
local_ip = 192.168.56.102
l2_population = True

Self-Service 네트워크가 구축되는 과정

그림 2. Self-Service networks 개요도

그림 3. Self-Service networks 연결도

설치 가이드 문서의 Launch Instance 의 인스턴스를 위한 네트워크 구축 – Self-Service 파트 에서 위와 같은 구성도를 보여주고 있습니다.

이제 neutron 에서 네트워크, 서브넷, 라우터를 생성하면서 그림 3의 연결도가 어떤 명령어로 어떻게 생성되는지 하나하나 살펴보도록 하겠습니다.

Self-Service Network 는 provider network 를 통해 인터넷과 통신하기에, neutron에 provider network를 사용할 수 있도록 설정해주어야 합니다.

Create the provider network

# 모든 오픈스택 사용자가 사용할 수 있도록 shared 네트워크를 생성.
neutron net-create --shared --provider:physical_network provider \
  --provider:network_type flat provider

# 위에서 생성한 네트워크에 서브넷을 생성.
neutron subnet-create --name provider --allocation-pool start=172.32.0.100,end=172.32.0.200 --dns-nameserver 8.8.8.8 --gateway 172.32.0.1 provider 172.32.0.0/24

위 작업을 하고 나면 Controller 노드에 아래와 같이 구성됩니다.

Controller 노드에서 bridge 와 네임스페이스는 아래와 같이 구성되어있다.

# 리눅스 bridge 확인
$ brctl show 
bridge name bridge id       STP enabled interfaces
brqc1997735-77      8000.08002772b679   no      eth1
                            tape9fb1eac-9b

# 리눅스 네트워크 네임스페이스 확인
$ ip netns
qdhcp-c1997735-771e-463c-b64f-7724800bbb1a

$ sudo ip netns exec qdhcp-c1997735-771e-463c-b64f-7724800bbb1a ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever

2: ns-e9fb1eac-9b@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:07:a8:82 brd ff:ff:ff:ff:ff:ff
    inet 172.32.0.100/24 brd 172.32.0.255 scope global ns-e9fb1eac-9b
       valid_lft forever preferred_lft forever
    inet 169.254.169.254/16 brd 169.254.255.255 scope global ns-e9fb1eac-9b
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe07:a882/64 scope link
       valid_lft forever preferred_lft forever

어떤 명령어들이 저런 구성을 완성했는지, neutron 서비스들의 디버그 메세지를 통해 확인해보겠습니다.

아래 내용은 구성을 위한 필수 명령어들만 정리한 내용입니다.

# 먼저 어디에선가 tape9fb1eac-9b 인터페이스가 만들어집니다 (어디서 만들어지는지 찾지 못했습니다. 명령어도..)

# DHCP Agent 에서 DHCP Namespace 생성하는 작업을 진행합니다.
ip netns add qdhcp-c1997735-771e-463c-b64f-7724800bbb1a
ip netns exec qdhcp-c1997735-771e-463c-b64f-7724800bbb1a ip link set lo up

# 이때 ns-e9 인터페이스가 생성되고, tape9fb 랑 연결됩니다.
ip link add tape9fb1eac-9b type veth peer name ns-e9fb1eac-9b netns qdhcp-c1997735-771e-463c-b64f-7724800bbb1a

ip netns exec qdhcp-c1997735-771e-463c-b64f-7724800bbb1a ip link set ns-e9fb1eac-9b address fa:16:3e:07:a8:82
ip link set tape9fb1eac-9b up
ip netns exec qdhcp-c1997735-771e-463c-b64f-7724800bbb1a ip link set ns-e9fb1eac-9b up

# dhcp 서버에 172.32.0.100 을 할당합니다.
ip netns exec qdhcp-c1997735-771e-463c-b64f-7724800bbb1a ip -4 addr add 172.32.0.100/24 scope global dev ns-e9fb1eac-9b brd 172.32.0.255

ip netns exec qdhcp-c1997735-771e-463c-b64f-7724800bbb1a ip -4 route replace default via 172.32.0.1 dev ns-e9fb1eac-9b

# dhcp 를 구성합니다.
ip netns exec qdhcp-c1997735-771e-463c-b64f-7724800bbb1a dnsmasq --no-hosts --no-resolv --strict-order --except-interface=lo --pid-file=/var/lib/neutron/dhcp/c1997735-771e-463c-b64f-7724800bbb1a/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/c1997735-771e-463c-b64f-7724800bbb1a/host --addn-hosts=/var/lib/neutron/dhcp/c1997735-771e-463c-b64f-7724800bbb1a/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/c1997735-771e-463c-b64f-7724800bbb1a/opts --dhcp-leasefile=/var/lib/neutron/dhcp/c1997735-771e-463c-b64f-7724800bbb1a/leases --dhcp-match=set:ipxe175 --bind-interfaces --interface=ns-e9fb1eac-9b --dhcp-range=set:tag0172.32.0.0static86400s --dhcp-option-force=option:mtu1500 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal

[Linux-Bridge-Agent] Bridge 생성

# 새로운 bridge 생성
brctl addbr brqc1997735-77
ip link set brqc1997735-77 up

# 인터페이스 추가
brctl addif brqc1997735-77 eth1
brctl addif brqc1997735-77 tape9fb1eac-9b

여기까지가 provider 네트워크를 생성했을 때 일어나는 일입니다. 여기서 compute 노드에 vm instance 를 생성하면, compute 쪽에서 provider bridge 가 생성되고 instance 와 연결되는 작업이 이루어집니다

이 부분은 self-service 네트워크를 생성 후, vm instance 를 만드는 것과 비슷한 작업이기에 아래에서 알아보도록 하겠습니다.

Create the Self Service Network

$ neutron net-create selfservice

$ neutron subnet-create --name selfservice --dns-nameserver 8.8.4.4 --gateway 172.16.1.1 selfservice 172.16.1.0/24

위와 같이 self-service network 와 서브넷을 생성하면 아래와 같이 구성됩니다.

그림을 보면 vxlan-70 이 eth0에 연결되어있는 것을 볼 수 있습니다. eth0 은 Management Network 로 할당된 인터페이스입니다.

이걸 통해서 Openstack Mitaka 설치 가이드에서는 Management Network 를 Tunnel Network와 같이 사용한다는 것을 알 수 있습니다.

사실 이것을 설명드리고 싶어서 이 문서를 작성한 것이 가장 큽니다. Management Network 를 통해서 Tunnel Network 를 사용하고 있었습니다.

[DHCP Agent] self-service dhcp namespace 생성

# 마찬가지로 tapb5ab7d31-e1 가 생성됩니다. 어디에선가..

ip netns add qdhcp-34078f0c-3e23-46d5-a03c-4c9af2778899
ip netns exec qdhcp-34078f0c-3e23-46d5-a03c-4c9af2778899 ip link set lo up

# ns-b5ab7d31-e1를 생성하고 tabb5ab7d31-e1 와 연결합니다.
ip link add tapb5ab7d31-e1 type veth peer name ns-b5ab7d31-e1 netns qdhcp-34078f0c-3e23-46d5-a03c-4c9af2778899

ip netns exec qdhcp-34078f0c-3e23-46d5-a03c-4c9af2778899 ip link set ns-b5ab7d31-e1 address fa:16:3e:76:6d:74
ip link set tapb5ab7d31-e1 up
ip netns exec qdhcp-34078f0c-3e23-46d5-a03c-4c9af2778899 ip link set ns-b5ab7d31-e1 up

# dhcp 서버 ip를 172.16.1.2 로 설정합니다.
ip netns exec qdhcp-34078f0c-3e23-46d5-a03c-4c9af2778899 ip -4 addr add 172.16.1.2/24 scope global dev ns-b5ab7d31-e1 brd 172.16.1.255

ip netns exec qdhcp-34078f0c-3e23-46d5-a03c-4c9af2778899 ip -4 addr add 169.254.169.254/16 scope global dev ns-b5ab7d31-e1 brd 169.254.255.255
ip netns exec qdhcp-34078f0c-3e23-46d5-a03c-4c9af2778899 ip -4 route replace default via 172.16.1.1 dev ns-b5ab7d31-e1

# dhcp 기능을 활성화합니다.
ip netns exec qdhcp-34078f0c-3e23-46d5-a03c-4c9af2778899 dnsmasq --no-hosts --no-resolv --strict-order --except-interface=lo --pid-file=/var/lib/neutron/dhcp/34078f0c-3e23-46d5-a03c-4c9af2778899/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/34078f0c-3e23-46d5-a03c-4c9af2778899/host --addn-hosts=/var/lib/neutron/dhcp/34078f0c-3e23-46d5-a03c-4c9af2778899/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/34078f0c-3e23-46d5-a03c-4c9af2778899/opts --dhcp-leasefile=/var/lib/neutron/dhcp/34078f0c-3e23-46d5-a03c-4c9af2778899/leases --dhcp-match=set:ipxe175 --bind-interfaces --interface=ns-b5ab7d31-e1 --dhcp-range=set:tag0172.16.1.0static86400s --dhcp-option-force=option:mtu1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal

[neutron-linuxbridge-agent] bridge 생성

# vxlan-70 인터페이스를 생성하고, vxlan id 는 70로 설정하고 eth0 과 연결되도록 합니다.
ip link add vxlan-70 type vxlan id 70 dev eth0

ip link set vxlan-70 up

# 새로운 bridge 를 생성합니다.
brctl addbr brq34078f0c-3e
brctl stp brq34078f0c-3e off
ip link set brq34078f0c-3e up

# 인터페이스들을 추가합니다.
brctl addif brq34078f0c-3e vxlan-70
brctl addif brq34078f0c-3e tapb5ab7d31-e1
ip link set tapb5ab7d31-e1 up

Create a router

self-service network 와 provider network 를 연결해주는 라우터를 생성합니다.

$ neutron net-update provider --router:external

$ neutron router-create router

$ neutron router-interface-add router selfservice

위 작업을 하고 나면 아래와 같은 구성이 만들어집니다.

[l3-agent] router namespace 생성

# tap19d1547d-a0 가 어디에선가 생성됩니다.

# 새로운 namespace 를 만듭니다.
ip netns add qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8
ip netns exec qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 ip link set lo up
ip netns exec qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 sysctl -w net.ipv4.ip_forward=1

# qr-19d1547d-a0 인터페이스를 만들고 tap19d1547d-a0 와 연결합니다
ip link add tap19d1547d-a0  type veth peer name qr-19d1547d-a0 netns qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8
ip netns exec qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 ip link set qr-19d1547d-a0 address fa:16:3e:02:b0:b9
ip netns exec qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 ip link set qr-19d1547d-a0 up

# qr-19d1547d-a0 인터페이스에 self-service 네트워크의 게이트웨이로 설정하기 위해 172.16.1.1 를 할당합니다.
ip netns exec qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 ip -4 addr add 172.16.1.1/24 scope global dev qr-19d1547d-a0 brd 172.16.1.255

[neutron-linuxbridge-agent] brq34078f0c-3e bridge 에 새로운 인터페이스 추가

# 이전에 만들어져있는 bridge에 router 와 연결되는 인터페이스를 추가합니다.
brctl addif brq34078f0c-3e tap19d1547d-a0

ip link set tap19d1547d-a0  up

‘router’ 이름의 라우터를 provide 네트워크의 gateway 로 설정

neutron router-gateway-set router provider

이 작업을 하고 나면 본격적으로 self-service 네트워크와 provider 네트워크가 연결되어, self-service 네트워크에서 인터넷으로 트래픽이 나갈 수 있게 됩니다.

구성은 아래와 같이 됩니다.

네트워크 인터페이스 구성

여기까지 왔을 때, controller 노드의 네트워크 인터페이스 구성은 아래와 같이 됩니다.

$ brctl show 

bridge name bridge id       STP enabled interfaces
brq34078f0c-3e      8000.7aa146e736c5   no      tap19d1547d-a0
                            tapb5ab7d31-e1
                            vxlan-70
brqc1997735-77      8000.08002772b679   no      eth1
                            tape01914d2-a0
                            tape9fb1eac-9b


$ sudo ip netns exec qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: qr-19d1547d-a0@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:02:b0:b9 brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.1/24 brd 172.16.1.255 scope global qr-19d1547d-a0
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe02:b0b9/64 scope link
       valid_lft forever preferred_lft forever
// 새로 생성
3: qg-e01914d2-a0@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:04:32:27 brd ff:ff:ff:ff:ff:ff
    inet 172.32.0.101/24 brd 172.32.0.255 scope global qg-e01914d2-a0
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe04:3227/64 scope link
       valid_lft forever preferred_lft forever

[l3-agent] router namespace 에 인터페이스 추가

# tape01914d2-a0 가 어디에선가 생성

# qg-e01914d2-a0 를 생성하고, tape01914d2-a 와 연결합니다.
ip link add tape01914d2-a0 type veth peer name qg-e01914d2-a0 netns qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8

ip netns exec qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 ip link set qg-e01914d2-a0 address fa:16:3e:04:32:27
ip link set tape01914d2-a0 up
ip netns exec qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 ip link set qg-e01914d2-a0 up

# qg-e01914d2-a0에 provide 라우터 인터페이스 ip로 172.32.0.101 을 할당합니다.
ip netns exec qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 ip -4 addr add 172.32.0.101/24 scope global dev qg-e01914d2-a0 brd 172.32.0.255
ip netns exec qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 ip -4 route replace default via 172.32.0.1 dev qg-e01914d2-a0

[neutron-linuxbridge-agent] brqc1997735-77에 인터페이스 추가

ip link set brqc1997735-77 up
brctl addif brqc1997735-77 tape01914d2-a0
ip link set tape01914d2-a0 up

여기까지 neutron 에서 provider / self-service 네트워크를 생성 및 설정할 경우 controller 노드에서 물리적(?)으로 어떤 작업을 통해 네트워크들이 구성되는지 확인해보았습니다.

이제 self-service 네트워크에 vm instance 를 생성해보고, 어떤 일이 일어나는지 확인해보겠습니다.

Self-service 네트워크에 vm instance 생성

vm instance 를 생성하면, controller 와 compute 에 작은 변화가 생깁니다. 우선 vm instance 를 생성하면 어떻게 구성되는지 아래 그림으로 확인해보겠습니다.

여기서 중요한 것은, compute 노드에서 vxlan70 인터페이스가 생성되고 그것을 통해 controller 노드와 연결이 되고 있는 것입니다.

이제부터 bridge 구성을 포함해서 어떻게 리눅스에서 vxlan 설정이 들어가는지 알아보도록 하겠습니다.

[compute node 의 neutron-linuxbridge-agent] etables 설정 / 새로운 bridge 생성 / vxlan 설정

# tap66aa1ee8-9b 이 생성된다.

# etables 설정 (이더넷 프레임에 대한 테이블)
ebtables -N neutronMAC-tap66aa1ee8-9b -P DROP
ebtables -A FORWARD -i tap66aa1ee8-9b -j neutronMAC-tap66aa1ee8-9b
ebtables -A neutronMAC-tap66aa1ee8-9b -i tap66aa1ee8-9b --among-src fa:16:3e:3f:4b:28 -j RETURN
ebtables -N neutronARP-tap66aa1ee8-9b -P DROP
ebtables -F neutronARP-tap66aa1ee8-9b
ebtables -A neutronARP-tap66aa1ee8-9b -p ARP --arp-ip-src 172.16.1.3 -j ACCEPT
ebtables -A FORWARD -i tap66aa1ee8-9b -j neutronARP-tap66aa1ee8-9b -p ARP

# vxlan-70 인터페이스를 생성하고 vxlan id 를 70으로 할당 후 eth0 에 연결되도록 설정
ip link add vxlan-70 type vxlan id 70 dev eth0
ip link set vxlan-70 up

# bridge 생성 및 인터페이스 추가
brctl addbr brq34078f0c-3e
brctl addif brq34078f0c-3e vxlan-70
brctl addif brq34078f0c-3e tap66aa1ee8-9b

# 여기에서 vxlan 터널링을 설정합니다.
# vxlan-70 의 모든 l2 트래픽의 목적지를 192.168.56.101 으로 설정
bridge fdb add 00:00:00:00:00:00 dev vxlan-70 dst 192.168.56.101

# 172.16.1.1 에 대한 목적지 ip 는 192.168.56.101, mac address 는  fa:16:3e:02:b0:b9 로 설정
# fa:16:3e:02:b0:b9 는 qrouter-594a2a7a-c79b-42f2-9011-8373f3186cb8 의 qr-19d1547d-a0@if13 인터페이스 mac address
ip -4 neigh replace 172.16.1.1 lladdr fa:16:3e:02:b0:b9 nud permanent dev vxlan-70
bridge fdb replace fa:16:3e:02:b0:b9 dev vxlan-70 dst 192.168.56.101

# 172.16.1.2 에 대한 목적지 ip 는 192.168.56.101, mac address 는  fa:16:3e:76:6d:74 로 설정
# fa:16:3e:76:6d:74 는 qdhcp-34078f0c-3e23-46d5-a03c-4c9af2778899 의 ns-b5ab7d31-e1@if10
# 172.16.1.2 는 self-service dhcp 서버 주소
ip -4 neigh replace 172.16.1.2 lladdr fa:16:3e:76:6d:74 nud permanent dev vxlan-70
bridge fdb replace fa:16:3e:76:6d:74 dev vxlan-70 dst 192.168.56.101

[controller node 의 neutron-linuxbridge-agent]

# vxlan-70 의 모든 l2 트래픽의 목적지를 192.168.56.102로 설정
bridge fdb add 00:00:00:00:00:00 dev vxlan-70 dst 192.168.56.102

# 172.16.1.3 은 instance ip
# 172.16.1.3 으로 가는 트래픽을 fa:16:3e:3f:4b:28 로 가도록 설정
# fa:16:3e:3f:4b:28 는 compute 노드의 tap66aa1ee8-9b 인터페이스 mac address
ip -4 neigh replace 172.16.1.3 lladdr fa:16:3e:3f:4b:28 nud permanent dev vxlan-70

// fa:16:3e:3f:4b:28 로 가는 트래픽의 목적지 ip 를 192.168.56.102 로 설정
bridge fdb replace fa:16:3e:3f:4b:28 dev vxlan-70 dst 192.168.56.102

여기까지 아주 긴 과정을 거쳐 provider network / self-service network 를 생성 및 설정이 이루어지는 방법을 알아보았습니다.

내용은 많지만 중요한 것만 정리하면 다음과 같습니다.

linuxbridge 를 이용하여 네트워크를 구축할 경우, linux bridge, namespace 를 이용해서 가상 네트워크를 구축한다.
linuxbridge 는 vxlan 만 지원하는데 이는, bridge 라는 명령어를 통해 vxlan 을 설정한다.
self-service 네트워크는 provider 네트워크를 통해 외부와 통신한다.

두서없이 정리하느냐 틀린 내용이나 누락된 내용이 있을 수 있습니다. 혹 발견하시면 댓글로 남겨주시면 감사하겠습니다.