Connectiong The Dots

러스터 환경을 구성할 때 

OSS 서버에서 OST 하나를 다시 포맷하고 마운트하는 과정에서 아래와 같은 메시지가 나올 때가 있다.

mount.lustre: mount /dev/XXX at /mnt/XXX failed: Address already in use The target service's index is already in use. (/dev/XXX)

이는 말 그대로 mkfs를 이용해 디스크를 Lustre 파일시스템으로 포맷을 해줄 때 지정한 주소값과 인덱스가 이미 지정되어 있어 마운트할 수 없다는 뜻이다.

이는 가끔 MDS나 OSS를 재부팅해주면 해결이 되나, 그래도 해결이 되지 않는다면 보통은 MDT를 재포맷해주면 된다.

따라서 이와 같은 오류가 발생한다면 먼저 /var/log/messages에서 로그 메시지를 확인하고

MDS에 있는 MDT를 언마운트해준 후 다시 재포멧시킨 후 마운트해주도록 한다.

https://jaehhhk.tistory.com/31

Lustre 클러스터링을 완료해줬으면 이제는 실제로 파일이 분산처리되는지 확인해보겠다.

아마 이 글이 Lustre 이용해보기 시리즈의 마지막 포스팅이 될 것 같다.

설치과정이 궁금한 분들은 내 블로그의 Lustre 이용해보기 시리즈 1편부터 따라와주면 좋을 것 같다.

실습 목표

파일을 직접 생성하여 분산처리가 실제로 원하는대로 잘 되고 있는지 확인해본다.

진행하기 앞서 Lustre 클러스터링이 제대로 되어 있어야 한다.

파일 생성

Client에 10G파일을 생성하여 OSS에 분산되어 저장되는지 확인해보겠다.

이때 fallocate 명령어를 이용하여 10G 크기의 test.txt라는 임의의 파일을 생성해주겠다.

# Client에서 실행
fallocate -l 10G /mnt/lustre/test.txt

Client 노드에서 Lustre가 마운트된 lusre 디렉터리에 test.txt파일이 생성되어 있을 것이다.

스트라이프 수 설정

파일이 생성되었으면 lfs 명령어 옵션 중 getstripe와 setstripe를 이용하여 스트라이프 수를 확인 및 변경할 수 있다.

우선 현재 스트라이프 수가 어떻게 되어 있는지 getstripe를 이영하여 확인해보겠다.

lfs getstripe /mnt/lustre

stripe_count를 확인해보면 1이라고 나와있다.

이러한 경우 10G 파일이 한 OST에 몰아서 저장되어 있을 것이다.

실제로 OSS에 들어가 아래 명령어를 입력하여 확인해보면

df -hT

아래와 같이 OST1인 /dsv/sdc에 10G 파일이 한번에 저장되어 있음을 알 수 있다.

이제 setstripe와 -c 옵션을 활용해 스트라이프 수를 변경해보겠다.

# 스트라이프 수 2로 변경
lfs setstrpe -c 2 /mnt/lustre

# 스트라이프 수 확인
lfs getstripe /mnt/lustre

이제는 stripe_count가 2로 변경된 것을 볼 수 있다.

이후 OSS에서 다시 아래 명령어를 통해 각 OST에 어떻게 저장되었는지 확인해보면

df -hT

위 사진과 같이 5G씩 2개로 분산되어 저장된 것을 볼 수 있다.

마무리

이렇게 해서 5편으로 나누어 Lustre 파일시스템 설치 및 매우매우 간단한 실습까지 정리해보았다.

혼자 수많은 에러와 좌절을 맛보면서 많이 성장했고, 설치에 성공하는 순간 많이 뿌듯했다.

혹시 예전의 나와 같이 아무것도 모르는 상태에서 레퍼런스라곤 영어로 된 다큐먼트가 다인 상황에 방황하고 있는 사람이 있다면 이 글을 통해 도움이 되었으면 한다.

구글 크롤링 봇이 노출을 많이 시켜주면 좋을텐데ㅎ

한명이라도 누군가는 보고 아주 약간의 도움이 될 수만 있다면 내 글의 목적은 성공한 것이라 생각한다.

다음으로는 Lustre를 이용해 파일시스템 벤치마킹 툴인 IOR, FIO, Filebench와

메타데이터 서버 벤치마킹 툴인 MDtest를 사용해보도록 하겠다.

추후에 기회가 된다면 Lustre 튜닝 가이드를 조금더 공부해 본 후 관련 포스팅을 올려보도록 하겠다.    

https://jaehhhk.tistory.com/30

이번 포스팅에서는 서버내 실제 디스크를 Target으로 잡아 마운트해준 후, Client에서 실제로 클러스터링이 잘 되었는지 확인해볼 것이다.

저저번 포스팅에서도 언급했듯이, 나는 소규모 환경에서 클러스터링을 진행하기 때문에 MGS와 MDS를 하나의 서버에 설치해주었다.

따라서 MGS_MDS, OSS 서버에 있는 디스크(SSD, HDD)를 각각 Lustre에 마운트해주어  하나의 타겟으로 잡은 후 MGS_MDS와 Client를 연결해준 후 Lnet을 통해 각 서버에 Ping이 제대로 도는지 확인함으로써 클러스터링을 완료하도록 하겠다.

MGS_MDS   

우선 각 서버가 보유한 스토리지의 종류와 개수를 파악해야 한다.

lsblk -d -o name, rota

이때 1은 HDD, 0은 SSD를 의미한다.

다음으로 이중에서 마운트 가능한 스토리지(아무것도 마운트되어있지 않은)를 확인하려면

df -hT

통해 온전히 하나의 타겟으로 잡을 수 있는 스토리지는 어떤것이 있는지 확인해볼 수 있다.

확인해 본 결과 MGS_MDS를 설치할 dn2 서버에서 사용가능한 스토리지는 sdd와 sde였다.

이중 나는 sdd를 MDT로 잡기로 했다.

스토리지 포맷

sdd를 MDT로 사용하기로 했으므로 이제 이를 Lustre을 파일시스템으로 하여 포맷해주어야 한다.

mkfs.lustre --fsname=lustre --mgs --mdt --index=0 /dev/sdd

mkfs.lustre --fsname=lustre --mgs --mdt --reformat --index=0 /dev/sdd  # 포맷 다시 할 경우

마운트

Lustre 파일시스템으로 포맷해주었으면, 서버에 마운트를 하면 된다.

mkdir /mnt/mdt  # 마운트 할 디렉터리 생성

mount -t lustre /dev/sdd /mnt/mdt  # Lustre로 마운트

df -hT /mnt/mdt  # 마운트 결과 확인

마운트 결과 Lustre로 제대로 마운트된 것을 확인할 수 있다.

OSS

다음으로 OSS에 OST를 마운트해주어야 한다.

OSS의 스토리지는 아래와 같다.

MGS_MDS때와 마찬가지로 마운트할 디스트를 확인해본 결과, sdd와 sdc를 마운트 할 수 있었다.

+ 추가로 나는 여기에서 Nvme SSD를 설치해주었으므로 이것도 같이 마운트해주겠다.

스토리지 포맷

OST를 잡아줄 때는 인덱스 번호(0~)를 지정해주어야 한다.

mkfs.lustre --fsname=lustre --ost --mgsnode=mgs의 IP주소@tcp --index=0 /dev/sdd
mkfs.lustre --fsname=lustre --ost --mgsnode=mgs의 IP주소@tcp --index=1 /dev/sdc
mkfs.lustre --fsname=lustre --ost --mgsnode=mgs의 IP주소@tcp --index=2 /dev/nvme0n1

마운트

# 마운트할 디렉터리 만들어주기
mkdir /mnt/ost0
mkdir /mnt/ost1
mkdir /mnt/ost2

# 마운트
mount -t lustre /dev/sdd /mnt/ost0
mount -t lustre /dev/sdc /mnt/ost1
mount -t lustre /dev/nvme0n1 /mnt/ost2

Client

Client 경우 스토리지 타겟을 따로 잡아줄 필요는 없다.

mkdir /mnt/lustre

mount -t lustre mgs_mds IP주소@tcp:/lustre /mnt/lustre

클러스터링 확인

위의 과정을 마쳤다면, 이제 Lustre로 제대로 클러스터링이 되었는지 확인해보아야 한다.

Lnet으로 Ping을 쏴보며 제대로 통신되는지 확인해보겠다.

lctl ping IP주소

위와 같이 IP주소로 잘 뜨면 제대로 ping이 돌고 있는 것이다.

다음으로 Client에서 각 타겟들이 잘 잡혀있는지 확인해보겠다.

이 명령어는 Client 터미널에 입력해준다.

lfs df

이는 Nvme를 설치해주기 전에 캡처한 화면이다.

각 서버에서 타겟으로 잡아준 것들이 그대로 뜨게 된다면 제대로 클러스터링된 것이다.

마무리

여기까지 타겟을 잡아주고, 결과를 Client 서버에서 확인해주는 과정까지 마무리해봤다.

다음 포스팅에서는 Lustre 실습을 통해 파일이 제대로 분산처리되는지 확인해보도록 하겠다.

Lustre에 필요한 모듈을 모두 다운로드 했으면, 다음으로 Lustre 전용 네트워크 프로토콜인 Lnet 모듈을 올려준 후 서버들을 Lnet으로 연결해주어야 한다.

이전에 설치에 필요한 모듈을 다운로드 하고, 올려주는 내용은 아래 글을 참고하면 좋을 것 같다.

https://jaehhhk.tistory.com/29

Lnet 모듈 올려주기

Lnet에 필요한 모듈들은 이전 포스팅에서 다운 받았던 rpm 파일을 다 실행해주었기 때문에 바로 올려줄 수 있다.

modprobe -a lnet

모듈을 올리는 데 성공했다면

Config 파일에 옵션을 추가해주어야 한다.

Centos 8 전 버전에는 modprobe.conf 파일에서,

이후 버전에는 modprobe.d 디렉터리 안에 있는 ko2iblnd.conf 파일을 수정해야 한다.

내 서버들은 Rocky Linux 8이므로 ko2iblnd.conf 파일을 수정한다.

vim /etc/modprobe.d/ko2iblnd.conf

# 해당 파일에 아래있는 옵션 추가
option network=tcp(eno1)

해당 파일에 들어간 후 위에 있는 옵션을 추가해준다.

이때 eno1은 내 서버에 있는 tcp 네트워크 파일 이름이다.

각자의 네트워크 이름을 파악해서 기입하면 된다.

이후 Lnet 전용 명령어인 lctl과 lnetctl을 이용해 Lnet을 Configure해준다.

# 네트워크 올려주기
lctl net up

# Lnet Configure
lnetctl lnet configure --all

# Network ID가 잘 달려있는지 확인
lnetctl net show

이를 확인해보면 아래와 같은 결과가 나온다.

검은색으로 마킹해 놓은 부분은 IP주소이다.

Lnet 모듈을 올려준 후 Configure까지 완료했다.

다음 포스팅에서는 이를 바탕으로 MGS, MDS, OSS 서버들의 디스크들을 마운트한 후 타겟(MGT, MDT, OST)을 만들어준 후 Lnet을 통해 Ping을 날려봄으로써 클러스터링이 잘 되었는지 확인해볼 것이다.

이제부터 Lustre(러스터) 설치를 위한 환경 구축을 시작하도록 하겠다!

Lustre를 클러스터링하기 위해서는 전용 커널(Server만)과 모듈을 다운받아주어야 한다.

따라서 이번 글에서는 Lustre를 이용하기 위해 다운받아주어야 할 커널과 모듈에 대해 소개하고,

실제로 다운로드 한 후 모듈을 올려보도록 하겠다.

이전에 Lustre 개념에 대해 아주 살짝 짚고 넘어간 글이 있는데 참고하면 좋을것 같다.

https://jaehhhk.tistory.com/28

환경 정의

연구실에서 내가 사용한 서버는 총 3대이다.

이용한 서버는 각각 Datanode2(dn2), Datanode3(dn3), Datanode4(dn4)로 칭하겠다.

또한 Client가 아닌 MGS, MDS, OSS 서버의 경우 래드햇 계열의 OS에서만 설치가 가능하다.

따라서 나는 Rocky Linux를 사용하였다.

그리고 나와 같이 소규모로 Lustre 클러스터링을하는 경우에는 MGS와 MDS를 하나의 서버에 설치하는 것이 일반적이라 한다.

따라서 나의 경우는 아래와 같이 서버를 배정하였다.

Datanode3

• Client

Datanode2

• MGS (Management Server)
• MDS (Metadata Server)

Datanode4

• OSS (Object Storage Server)

커널 및 모듈 설치 (MGS, MDS, OSS)

우선 MGS, MDS, OSS를 설치할 서버에서 필요한 패키지들을 우선 다운로드하겠다.

Lustre는 버전에 민감하다.

따라서 사용할 서버들의 환경에 맞는 Lustre 릴리즈 버전을 다운받는 것이 중요하다.

Lustre 공식 커뮤니티에 들어가면 Lustre Support Matrix라는 표를 제공한다.

https://wiki.whamcloud.com/display/PUB/Lustre+Support+Matrix

빨간색 박스 부분을 확인한 후 자신의 OS 버전과, 커널 버전을 확인한 후 맞는 Lustre 릴리즈를 다운받는 것이 중요하다.

이때 커널 버전이 맞지 않는다면, 맞는 커널로 업그레이드/다운그레이드해주면 된다.

나 같은 경우는 Rocky Linux 8.7 환경의 서버를 보유했기 때문에 2.15.2 버전을 다운받아주도록 하겠다.

버전을 체크했으면 다운로드 사이트에 들어가 상황에 맞는 RPM 파일을 선택해 다운로드 해주면 된다.

Lustre RPM

https://downloads.whamcloud.com/public/lustre/lustre-2.15.2/el8.7/server/RPMS/x86_64/ 

e2fsprogs RPM

https://downloads.whamcloud.com/public/e2fsprogs/1.46.6.wc1/el7/RPMS/x86_64/

위의 링크들은 내 환경에 맞는 릴리즈 url이다.

여기 들어가서 Parent Directroy를 계속 눌러주면 상위 디렉터리에 설치하기로 한 버전 디렉터리에 들어가서 다운로드 해주면 된다.

위 두 링크 통합하여 내가 다운로드한 파일은 아래와 같다.

Client에 필요한 파일 설치

https://downloads.whamcloud.com/public/lustre/lustre-2.15.2/el8.7/client/RPMS/x86_64/

Client의 경우는 전용 커널을 다운받을 필요가 없으므로 아래의 파일만 다운로드해주었다.

• kmod-lustre-client
• lustre-client
• lustre-iokit

위 파일들을 각 서버에 wget 명령어를 사용하여 다운받아준다.

이때 빈 디렉터리를 하나 만들어서 진행해주면 편하다.

RPM 파일 실행 및 모듈 올려주기

다음으로 다운로드한 RPM 파일들을 실행해주어야 한다.

해당 파일들이 있는 디렉터리에 진입하여 localinstall 명령어를 통해 RPM 파일을 실행시킨다.

yum localinstall *.rpm

다운로드한 파일 전부 rpm파일 이므로 하나하나 명령어를 입력하지 말고,

*을 이용해 한번에 실행시켜주도록 한다.

커널 모듈 올려주기

Lustre는 전용 커널이 존재한다. 위의 RPM 파일들을 다운로드하고 실행시켜줌으로써 전용 커널을 올려줄 준비가 되었다.

올려주도록 하자.

modprobe -a lusre

modprobe 명령어를 통해 lustre 모듈을 올려준다.

이후 커널 버전을 확인해보도록 하자.(MGS, MDS, OSS만!)

uname -r

성공적으로 Lustre 전용 커널이 적용된 것을 볼 수 있다.

아래 명령어를 통해 모듈이 제대로 잘 올라갔는지 확인 가능하다.(여기는 Server, Client 모두 해당)

lsmod | egrep "lustre|lnet"

이렇게 Lustre 릴리즈 버전 확인 및 설치를 진행한 후, 모듈을 올려보는 것까지 진행해보았다.

다음 포스팅에서는 Lustre 전용 네트워크 프로토콜인 Lnet 모듈도 올려준 후 Lnet을 통해 Ping을 날려봄으로써

Lnet으로 서버들이 잘 붙어있는 지 확인해보도록 하겠다!

학부 연구생을 하며 3대의 서버를 Lustre 파일 시스템으로 클러스터링 해보라는 미션을 부여받았다.

Lustre가 무엇이고, 설치는 어떻게 하는 것이며 어떻게 사용하는지 아무것도 모르는 상태에서 참 막막했다.

더군다나 Lustre에 대한 논문은 많았지만, 전부 응용에 관한 내용이었지

처음부터 이걸 어떻게 설치하고 적용하는지에 대한 레퍼런스는 대부분 영어로 된 공식 커뮤니티와 문서들을 제외하고는 드물었다.

https://wiki.lustre.org/Main_Page

정말 이걸 알아가는데 많은 시간을 들였고, 오류들도 정말 많이 직면해 고통스럽기도 했다.

그래서 내가 고통스러워하며 배워갔던 Lustre에 관한 내용과 실제 서버에 적용하는 과정을 아무것도 모르는 과거의 내가 다시 봐도 충분히 따라갈 수 있을 정도로

개념(아주 살짝)부터 설치 과정 및 응용(벤치마킹)을 시리즈로 여러 편에 걸쳐 세세하게 풀어써보려 한다.

물론 지금도 내가 Lustre를 완벽하게 아는 것이 아니다.

학부생 수준에서 지금까지 알게 된 내용들을 정리해서 나만의 언어로 공유하는 것 뿐이다.

따라서 내용상 틀린 내용이 있거나 보완해야 할 점이 있으면 고견을 내어 주시면 정말 감사할 것 같다.

 Lustre 개념 & 구조

리눅스 기반의 오픈 소스, 객체 지향, 분산, 병렬, 클러스터링 파일시스템

Lustre를 한마디로 설명하면 위와 같다

Lustre는 전용 커널을 필요로 하는 네트워크 기반의 클라이언트 - 서버 아키텍처 파일시스템이다.

클러스터링할 서버 각각 클라이언트와 서버 역할을 지정해줘야한다는 것이다.

따라서 Lustre 전용 네트워크 모듈과 각 역할별로 필요한 모듈들을 다운받아 서버에 올려줘야한다. 

우선 Lustre의 구조는 아래와 같다.

앞에서도 언급했듯이 Lustre는 클라이언트 - 서버 아키텍처인데, 여기서 서버는 다시 역할별로 나뉘고

각 서버는 Target이라고 하는 스토리지 오브젝트를 갖는다. (디스크 하나를 마운트 해줘야 함 추후 설명)

클라이언트부터 시작해서 서버까지, 각각의 역할별 카테고리와 하위 타겟은 어떻게 나뉘는지 크게 살펴보면 다음과 같다.

카테고리

Cilent

• Client

Server

• Management Server (MGS)
  • Management Target (MGT)
• Metadata Server (MDS)
  • Metadata Target (MDT)
• Object Storage Server (OSS) 
  • Object Storage Target (OST)

Lnet

• Network Module for Lustre

설명에 앞서 서버 하위에 ~T로 끝나는 타겟(Target)이라는 것이 있을 것이다.

이는 쉽게 말하면 서버 내의 스토리지 디스크 혹은 파티션 하나를 의미한다.

각 서버의 역할에 맞는 데이터를 저장하는 곳인 것이다.

따라서 이 타겟은 서버 구성 상황에 따라 여러개를 마운트할 수 있으며 Lustre 파라미터 설정 시 RAID 설정을 통해 병렬처리가 가능하다.

파일시스템 하에서 각각의 서버가 클라이언트로부터 들어오는 데이터를 서버 별 역할에 맞게 분산처리하고, 이 데이터를 스토리지(타겟)에 저장하여 병렬처리를 하므로 Lustre를 네트워크 기반의 분산, 병렬 파일시스템이라 정의하는 이유이다.

이를 구성하는 내용과 방법은 추후 포스팅에서 설명할 예정이다.

위에서 설명한 카테고리 개요를 조금 더 자세히 설명하면 아래와 같다.

Client

서버의 분산형 스토리지를 사용하여 서버에 엑세스한다.

이때 Lnet을 사용해 서버에 접근한다.

각 클라이언트는 여러 다른 Lustre 파일 시스템 인스턴스에 접근 가능하다.

Server

Lustre 아키텍처를 관리하고, 클라이언트가 전송한 데이터를 기록하는 역할을 수행한다.

MGS가 전체적인 Lustre 파일시스템을 관리하고,

MDS는 파일(클라이언트가 엑세스한)의 메타 데이터,

OSS는 실제 파일을 담당한다.

Management Server (MGS)

MGS는 Lustre 파일 시스템 전체를 관리하는 관리서버이다.

이때 꼭 하나의 Lustre 파일 시스템이 아닌, 여러 Lustre 파일 시스템의 마운트를 관리하기도 한다.

MGS가 이용하는 MGT는 모든 Lustre 노드에 대한 구성정보(파일 크기, 권한, 액세스 날짜와 같은 파일 및 디렉터리에 대한 정보)가 기록된 곳이고, 반드시 한 개 이상의 MGT가 마운트되어 있어야 한다.

기록 주체는 당연히 MGS이다.

Object Storage Server (OSS)

실제 파일을 저장하기 위한 스토리지 타겟을 제공하는 서버이다.

MGS, MDS와 마찬가지로 OST라고 하는 스토리지 타겟에 접근 권한을 주고,

각 OST는 파일을 나타내는 Binary 객체들을 담고 있다.

각 객체들 안에는 파일들이 스트라이프(Stripe와 Mirroring 관련 개념은 구글링 바람)되어 저장된다.

Lustre 공식 문서에서는 스트라이프를 레이아웃(Layout)으로 표현한다.

OSS는 여러개의 OST를 마운트할 수 있으며

각 OST는 서로 독립적이다. 

OST별 종속성이 없기 때문에 더 많은 OST가 증가됨에 따라 파일 시스템의 성능은 선형으로 증가하게 된다. 

Metadata Server (MDS)

Lustre 파일 시스템의 모든 네임스페이스를 제공해 파일 시스템의 아이노드를 저장한다.

즉 파일 열기, 닫기, 삭제, 이름 변경 등의 네임스페이스를 조작하고 관리하는 서버인 것이다.

이때 MDS는 파일 혹은 디렉터리의 메타데이터 처리에만 관여하고,

파일이 한 번 열리면 파일이 닫힐때까지 MDT는 입출력 트랜젝션에 관여하지 않는다.(오버헤드를 피하기 위해)

네임스페이스들을 계층적으로 다루는 것에 더해 파일의 스트라이핑 수, 스트라이핑 한 크기 등을 기록하고 OST에 object들을 할당한다.

MDT는 MDS의 메타 데이터를 저장한다.

이때 저장되는 데이터는 파일 시스템의 디렉토리 구조, 파일 이름, 권한, 파일 레이아웃 등이다.

반드시 한 개 이상의 MDT를 가지고 있어야 한다.

Lnet

 Lustre의 네트워크 프로토콜이다.

클라이언트와 서버를 연결하며, Lustre 내 모든 입출력은 스토리지 서버에서 직접 하는 것이 아닌 Lnet으로 실행한다.

TCP/IP 뿐만아니라 Infiniband 네트워크도 지원한다.

아주 아주 부족하지만, 정리해보았다.

다음 포스팅은 연구실에서 내가 실제로 사용한 서버 구성 사항과 서버(MGS, MDS, OSS) 구성에 필요한 모듈들을

다운받아 올려보고, 디스크도 하나의 타겟으로 잡아 마운트하는 과정을 설명하도록 하겠다!