[OpenStack] OpenStack Manila 도입 1년 회고

목차

• 1. 왜 OpenStack Manila를 보게 되었는가
• 2. OpenStack Manila란 무엇인가
• 핵심 개념 한 번에 정리
• 다른 스토리지와 무엇이 다른가
• 3. 도입 전에 꼭 봐야 했던 설계 포인트
• 4. OpenStack Manila 실전 구현: 제가 실제로 잡았던 기본 흐름
• 1) 서비스 상태 확인
• 2) share type 생성
• 3) share network 생성
• 4) 공유 스토리지 생성
• 5) 접근 제어 추가
• 6) 인스턴스에서 마운트
• 7) 설정 예시
• 5. 1년 운영하며 좋았던 점: 명(明)
• 6. 1년 운영하며 아쉬웠던 점: 암(暗)
• 첫째, 문제의 절반은 결국 백엔드와 네트워크입니다
• 둘째, 권한 설계가 느슨하면 금방 복잡해집니다
• 셋째, 장애 분석이 생각보다 단순하지 않습니다
• 7. ⚠️ 실제로 겪었던 트러블슈팅
• 문제 1. share는 생성됐는데 마운트가 안 되는 경우
• 문제 2. 생성 속도는 괜찮은데 체감 성능이 들쭉날쭉한 경우
• 문제 3. 공유는 살아 있는데 운영 기록이 남지 않는 경우
• 문제 4. 기대보다 운영 난도가 높게 느껴지는 경우
• 8. 검증과 운영 결과: 무엇이 달라졌나
• 9. FAQ와 마무리: 다음 단계는 어떻게 가면 좋을까
• 자주 묻는 질문

[OpenStack] OpenStack Manila 도입 1년 회고

프라이빗 클라우드 파일 스토리지 이야기를 하면, 많은 분들이 처음엔 Cinder(신더, 블록 스토리지)나 Swift(스위프트, 오브젝트 스토리지)부터 떠올리시더라고요. 저도 그랬습니다. 그런데 VM(가상머신) 여러 대와 컨테이너 워크로드가 같이 굴러가기 시작하면, 결국 팀에서 꼭 묻는 질문이 하나 나옵니다. "공유 폴더처럼 쓸 수 있는 스토리지는 없나요?" 바로 그 지점에서 OpenStack Manila가 등장합니다.

저는 지난 1년 동안 홈랩과 사내와 유사한 형태의 프라이빗 환경에서 Manila 운영 방식을 꽤 집요하게 다듬어봤습니다. 처음엔 "이게 Nova(노바, 컴퓨트)나 Neutron(뉴트론, 네트워크)처럼 그냥 붙이면 되겠지" 했었는데요. 막상 들어가 보니 기능은 명확한데, 프라이빗 클라우드 파일 스토리지 운영할 때 고려할 포인트가 생각보다 많더라고요. 특히 Manila로 파일 스토리지를 운영하면 자동화가 편해지는 대신, 네트워크와 백엔드 설계를 대충 하면 나중에 꼭 되돌아오니까요. 오늘은 OpenStack Manila 도입 1년 회고라는 관점에서, 좋았던 점과 아쉬웠던 점을 솔직하게 정리해보겠습니다.

OpenStack Manila, 컴퓨트 노드, 스토리지 백엔드, 사용자 네트워크가 어떻게 연결되는지 한눈에 보여주는 아키텍처 이미지가 들어갈 자리입니다.

1. 왜 OpenStack Manila를 보게 되었는가

처음 문제는 단순했습니다. 프로젝트마다 VM 안에 데이터를 따로 넣어두다 보니, 배치 작업 서버와 애플리케이션 서버가 같은 데이터를 봐야 하는 상황에서 계속 복사본이 생겼거든요. 이러면 데이터 일관성도 깨지고, 백업 정책도 꼬이고, 장애가 나면 복구 지점도 애매해집니다.

프라이빗 클라우드 파일 스토리지 요구가 계속 나오면서 선택지를 세 가지로 놓고 봤습니다.

• VM 내부 디스크를 각자 관리한다
• Cinder 볼륨을 붙여서 우회한다
• 공유 파일 스토리지 자체를 서비스로 제공한다

세 번째가 바로 OpenStack Manila, 즉 프라이빗 클라우드 파일 스토리지 서비스의 자리였습니다. 실제로 써보니까, 파일 공유를 사람 손으로 매번 만들어주는 방식보다 API(에이피아이, 프로그램 호출 인터페이스) 기반으로 표준화하는 게 훨씬 관리가 잘 되더라고요.

2. OpenStack Manila란 무엇인가

쉽게 말해 OpenStack Manila는 공유 파일 시스템을 서비스 형태로 제공하는 컴포넌트입니다. Cinder가 블록 디바이스를 내주는 역할이라면, Manila는 NFS(엔에프에스, 네트워크 파일 시스템)나 SMB(에스엠비, 파일 공유 프로토콜) 같은 형태의 공유 스토리지를 만들어주는 쪽에 가깝습니다.

처음엔 이름이 좀 낯설죠. 저도 처음엔 "왜 이름이 Manila지?" 싶었는데, 기능 자체는 꽤 직관적입니다. 핵심 개념만 잡아두면 어렵지 않거든요.

핵심 개념 한 번에 정리

• Share: 실제로 사용자에게 제공되는 파일 공유 자원
• Share Type: 성능, 백엔드, 기능 정책을 구분하는 템플릿
• Share Network: 공유 스토리지가 붙을 네트워크 정보
• Backend Driver: CephFS(세프에프에스), NetApp, Generic driver 같은 실제 구현체와 연결되는 계층
• Access Rule: 어떤 IP나 사용자에게 접근을 허용할지 정하는 규칙

여기서 중요한 포인트! Manila 자체가 스토리지를 저장하는 제품은 아닙니다. 정확히는 백엔드 파일 스토리지를 OpenStack 방식으로 관리해주는 제어 계층이라고 생각하시면 돼요. 이 차이를 이해 못 하면 설계가 꼬입니다.

다른 스토리지와 무엇이 다른가

구분	주 용도	접근 방식	운영 시 느낌
Ephemeral Disk	인스턴스 로컬 작업	VM 내부 로컬 디스크	빠르지만 수명과 이동성 제약이 크다
Cinder	데이터베이스, 단일 서버 디스크	블록 디바이스 마운트	명확하지만 다중 공유에는 부적합
Swift	백업, 아카이브, 객체 저장	HTTP API	확장성은 좋지만 파일시스템처럼 쓰긴 어렵다
Manila (프라이빗 클라우드 파일 스토리지)	공유 파일 스토리지	NFS/SMB 등	협업과 공용 데이터셋에 강하다

3. 도입 전에 꼭 봐야 했던 설계 포인트

제가 1년 운영하면서 느낀 건, Manila는 설치보다 설계가 더 중요하다는 점입니다. 특히 아래 세 가지를 먼저 정리해야 나중에 덜 고생합니다.

1. 백엔드 선택: CephFS처럼 분산 파일 시스템을 붙일지, 전통적인 NAS(나스, 네트워크 스토리지)를 붙일지 결정해야 한다
2. 네트워크 분리: 스토리지 트래픽과 테넌트 트래픽을 어느 정도 분리할지 판단해야 한다
3. 운영 권한 모델: 누가 share를 만들고, 누가 접근 규칙을 열 수 있는지 기준을 세워야 한다

사실 여기서 많이들 놓치는 게 두 번째입니다. 프라이빗 클라우드 파일 스토리지는 결국 네트워크 영향을 강하게 받습니다. 스토리지 백엔드는 멀쩡한데도 MTU(엠티유, 최대 전송 단위)나 라우팅, 보안그룹 정책 때문에 체감 성능이 무너지는 경우를 꽤 봤거든요.

4. OpenStack Manila 실전 구현: 제가 실제로 잡았던 기본 흐름

이제 구현 얘기를 해보겠습니다. 환경마다 패키지 설치 방식은 다를 수 있으니, 여기서는 운영 개념과 명령 흐름 위주로 정리하겠습니다. 저는 처음에 모든 설정을 한 번에 넣으려다가 꼬여서, 결국 가장 단순한 형태부터 올리는 방식으로 갔습니다. 이게 훨씬 낫더라고요.

1) 서비스 상태 확인

openstack share service list
openstack endpoint list --service manila
openstack network list

맨 처음엔 화려한 기능보다 서비스가 보이느냐부터 확인했습니다. 생각보다 기본 서비스 등록이나 엔드포인트 누락이 자주 나옵니다.

2) share type 생성

openstack share type create default_share false
openstack share type set --extra-specs snapshot_support=true default_share

Share Type은 나중에 Manila 운영 정책의 중심이 됩니다. 성능 클래스, 스냅샷 허용 여부, 백엔드 매핑 기준을 여기에 녹여두면 사용자 설명이 쉬워지거든요.

3) share network 생성

openstack share network create \
  --name manila-share-net \
  --neutron-net-id <tenant-network-id> \
  --neutron-subnet-id <tenant-subnet-id>

여기서 저도 한 번 크게 삽질했습니다. 인스턴스가 붙은 네트워크와 share network 관계를 대충 맞추면 될 줄 알았는데, 실제로는 접근 경로와 라우팅이 명확해야 마운트 단계에서 덜 막힌다더라고요.

4) 공유 스토리지 생성

openstack share create \
  --name project-data \
  --share-type default_share \
  --share-network manila-share-net \
  --size 100 \
  NFS

생성 직후 바로 쓰려고 하면 안 됩니다. 상태가 available이 될 때까지 기다려야 합니다.

openstack share list
openstack share show project-data

Share type, share network, backend driver, tenant network가 어떤 순서로 연결되는지 보여주는 구성 다이어그램이 들어갈 자리입니다.

5) 접근 제어 추가

openstack share access create project-data ip 10.10.20.15
openstack share access list project-data

Manila 운영하면서 가장 체감이 좋았던 부분 중 하나가 이겁니다. 예전엔 파일 공유를 열 때 네트워크팀, 스토리지팀, 운영팀이 각각 손대야 했었는데요. Manila를 붙이니 최소한 권한과 절차가 API로 정리되니까 일이 많이 단순해졌습니다.

6) 인스턴스에서 마운트

sudo mkdir -p /mnt/project-data
sudo mount -t nfs <share-export-location> /mnt/project-data
df -h
mount | grep project-data

여기서 export location이 올바르게 나오는지 확인해야 합니다. 실제 사용자는 이 지점만 보기 때문에, 앞단 자동화가 아무리 좋아도 마운트 실패하면 평가가 박해집니다. 냉정하죠 ㅎㅎ

7) 설정 예시

[DEFAULT]
default_share_type = default_share
enabled_share_backends = cephfsnfs

[cephfsnfs]
share_backend_name = CEPHFSNFS
driver_handles_share_servers = false

설정은 백엔드마다 달라지니 그대로 복붙하시면 안 되고, 운영 중인 백엔드 문서와 정확히 맞춰야 합니다. 다만 관점 자체는 비슷합니다. 어떤 백엔드를 활성화할지, 드라이버가 share server를 직접 다룰지 여부를 정하는 구조니까요.

5. 1년 운영하며 좋았던 점: 명(明)

OpenStack Manila 운영을 1년쯤 해보니까, 분명 장점이 있습니다. 이건 꽤 명확했습니다.

• 셀프서비스화: 사용 부서가 요청만 하면 표준 절차로 공유 스토리지를 만들 수 있다
• 정책 통일: share type 중심으로 Manila 운영 기준을 맞추기 쉽다
• 접근 제어 가시성: 누가 어떤 share에 접근 가능한지 추적이 쉬워진다
• 자동화 친화적: Terraform(테라폼, 인프라 선언형 자동화)이나 내부 포털과 엮기 좋다

특히 프로젝트 단위로 수명주기를 관리할 때 편했습니다. 인스턴스는 바뀌어도 데이터 공유 계층은 유지할 수 있으니, 작업 서버를 새로 올려도 공유 데이터를 다시 설계할 필요가 없거든요. 이거 진짜 편하더라고요.

또 하나는 운영 책임 구간이 분리된다는 점입니다. 예전엔 "공유 폴더 느려요"라는 말이 나오면 원인 범위가 너무 넓었는데, Manila 도입 후에는 적어도 API 계층, 네트워크 계층, 백엔드 계층으로 잘게 나눠서 볼 수 있었습니다.

6. 1년 운영하며 아쉬웠던 점: 암(暗)

근데 여기서 중요한 게 있습니다. Manila는 만능이 아닙니다. 오히려 기대치를 너무 높게 잡으면 실망하기 쉽습니다.

첫째, 문제의 절반은 결국 백엔드와 네트워크입니다

사용자 입장에서는 OpenStack Manila가 파일 스토리지를 제공하는 것처럼 보이지만, 실제 체감 품질은 백엔드 스토리지와 네트워크 설계에 크게 좌우됩니다. 즉, Manila가 느린 게 아니라 뒤쪽이 느린 경우가 많습니다. 이걸 분리해서 설명하는 데 시간이 꽤 들었습니다.

둘째, 권한 설계가 느슨하면 금방 복잡해집니다

처음엔 "필요한 사람에게 IP만 열어주면 되지" 했었는데요. 몇 달 지나면 예외 규칙이 누적됩니다. 접근 규칙을 누가 승인하는지, 만료 기준은 뭔지, 프로젝트 종료 시 어떻게 닫을지 초반에 정해야 합니다.

셋째, 장애 분석이 생각보다 단순하지 않습니다

마운트 실패 하나만 놓고 봐도 원인이 다양합니다. DNS(디엔에스, 이름 해석), 라우팅, 보안그룹, export location, 백엔드 상태, 커널 NFS 클라이언트 옵션까지 봐야 하거든요. 처음엔 "왜 이렇게 복잡하지?" 싶었는데, 결국 파일 공유라는 게 여러 계층이 맞물리는 서비스라 그렇더라고요.

7. ⚠️ 실제로 겪었던 트러블슈팅

이 섹션은 좀 현실적으로 적어볼게요. 저도 처음엔 문서만 보면 금방 될 줄 알았는데, 실제 Manila 운영에선 아래 이슈를 자주 만났습니다.

문제 1. share는 생성됐는데 마운트가 안 되는 경우

• 증상: `mount.nfs: access denied by server`
• 원인 후보: 접근 규칙 누락, 클라이언트 IP 변경, 잘못된 네트워크 경로
• 해결: `openstack share access list`로 허용 규칙 확인 후, 실제 클라이언트 IP와 비교

openstack share access list project-data
ip addr
ip route

생각보다 NAT(엔에이티, 주소 변환)나 점프 구간 때문에 사용자가 보는 IP와 실제 서버가 보이는 IP가 다른 경우가 있었습니다.

문제 2. 생성 속도는 괜찮은데 체감 성능이 들쭉날쭉한 경우

• 증상: 어떤 VM은 빠르고 어떤 VM은 유독 느림
• 원인 후보: 네트워크 경로 차이, MTU 불일치, 혼잡 구간 존재
• 해결: 경로별 성능 차이를 먼저 분리 측정하고, Manila 문제로 단정하지 않기

여기서 제가 배운 건 하나입니다. 스토리지 문제를 API 문제로 착각하지 말 것. 관리 평면(control plane)과 데이터 평면(data plane)을 분리해서 봐야 합니다.

문제 3. 공유는 살아 있는데 운영 기록이 남지 않는 경우

• 증상: 누가 왜 접근 규칙을 열었는지 추적이 어려움
• 원인 후보: 수동 작업, 표준 요청 절차 부재
• 해결: 변경 요청 번호나 티켓 번호를 share 이름 또는 메타데이터 규칙에 반영

이건 기술 이슈 같지 않지만 실제 Manila 운영에선 꽤 큽니다. 나중에 감사나 보안 점검 때 힘들어지거든요.

문제 4. 기대보다 운영 난도가 높게 느껴지는 경우

사실 OpenStack 스토리지는 모두 그렇지만, Manila도 "기능 추가"보다 "운영 모델 정리"가 더 어렵습니다. 백엔드 드라이버 특성, 네트워크 토폴로지, 접근 정책이 모두 연결되니까요. 그래서 제가 추천하는 방식은 이겁니다.

1. 처음엔 딱 한 가지 share type만 운영한다
2. 접근 제어는 가장 보수적으로 시작한다
3. 사용자 수요가 확인된 뒤에 스냅샷, 멀티 백엔드, 성능 클래스 분리를 확장한다

한 번에 다 하려 하지 않는 것, 이게 제일 중요했습니다.

8. 검증과 운영 결과: 무엇이 달라졌나

그럼 1년 운영해서 뭐가 남았냐, 이 질문이 제일 중요하겠죠. 제가 직접 해보니 결과는 꽤 분명했습니다.

• 프라이빗 클라우드 파일 스토리지 개설 절차가 표준화됐다
• 프로젝트별 데이터 공유 방식이 단순해졌다
• 수동 NAS 작업이 줄어들었다
• 장애 시 원인 구간을 더 빨리 좁힐 수 있게 됐다

반대로, 운영 문서와 접근 정책이 없으면 Manila 운영은 금방 복잡해진다는 것도 확인했습니다. 즉, OpenStack Manila의 성공 조건은 설치가 아니라 운영 규칙이에요.

openstack share list
openstack share service list
openstack share type list
openstack share network list

검증할 때는 단순히 리소스가 보이는지보다, 아래 항목을 같이 확인했습니다.

1. Share 상태가 `available`인지
2. 접근 규칙이 기대한 대상에만 열려 있는지
3. 실제 인스턴스에서 마운트와 읽기/쓰기가 되는지
4. 장애 시 로그와 변경 이력이 추적 가능한지

Share 상태, 접근 규칙, 마운트 성공 여부, Manila 운영 지표를 한 화면에서 점검하는 대시보드 이미지가 들어갈 자리입니다.

9. FAQ와 마무리: 다음 단계는 어떻게 가면 좋을까

자주 묻는 질문

• Q. Manila는 모든 환경에서 꼭 필요한가요?
  아닙니다. 프라이빗 클라우드 파일 스토리지 요구가 적고 운영 단순성이 더 중요하면 굳이 넣지 않는 게 나을 수도 있습니다.
• Q. 프라이빗 클라우드 파일 스토리지로 바로 도입해도 될까요?
  가능은 하지만, 먼저 한두 팀 대상 파일 공유 서비스로 시작해 Manila 운영 모델을 검증하는 걸 추천합니다.
• Q. OpenStack 스토리지 중 우선순위는 어떻게 잡아야 하나요?
  블록, 오브젝트, 파일의 요구가 다르니 워크로드 기준으로 판단해야 합니다. "공유 파일"이 핵심이면 Manila가 후보가 됩니다.

정리해보면 이렇습니다. OpenStack Manila는 프라이빗 클라우드 파일 스토리지 운영을 표준화하는 데 꽤 좋은 도구입니다. 다만 제품만 올린다고 끝나는 게 아니고, 백엔드 선택과 네트워크 설계, 접근 정책, 운영 문서화까지 같이 가야 진짜 효과가 납니다.

저도 처음엔 이게 뭔가 싶었는데, 1년쯤 지나고 나니 보이더라고요. Manila 운영의 핵심은 "기능 활성화"가 아니라 "운영 경계 정의"였습니다. 이걸 빨리 이해할수록 삽질이 줄어들더라고요.

다음 글에서는 OpenStack Manila 운영 시 백엔드 선택 기준, 예를 들면 CephFS 계열과 전통적인 NAS 연동 관점에서 무엇을 봐야 하는지 더 구체적으로 다뤄볼 예정입니다. 이전 글에서 다뤘던 OpenStack 네트워크 설계 내용과도 연결해서 보시면 훨씬 이해가 쉬우실 겁니다.

도입 전 수동 운영 방식과 도입 후 표준화된 프라이빗 클라우드 파일 스토리지 운영 방식을 비교하는 요약 인포그래픽이 들어갈 자리입니다.

혹시 지금 OpenStack Manila 도입을 고민 중이시라면, 제 경험상 가장 먼저 할 일은 하나입니다. "누가 어떤 데이터를 어떤 방식으로 공유해야 하는가"를 먼저 적어보세요. 그 다음에 Manila를 붙이면 훨씬 덜 헤맵니다. 이 순서, 생각보다 정말 중요합니다. 🎉

📚 함께 읽으면 좋은 글

• OpenStack Floating IP 연결 문제 해결: 보안 그룹 디버깅
• OpenStack 보안 그룹 취약점과 Floating IP 보안 강화 전략
• OpenStack Designate 마이그레이션: 기존 DNS 연동 전략