Watch & Learn

* 단일 장애 지점(SPoF) 이란? 

Single Point of failure (SPoF) 는 복잡한 설치의 특정 부분이 장애가 나면, 전체 환경이 박살나는 그 부분들을 말한다. 메탈 체인이 하나라도 망가진다면 전체 체인이망가진다.일반적인 HA 클러스터는, 여러 SPoF 가 있을 수 있다. 아래는 일부의 예시이다.

하드웨어 SPoF

소프트웨어 SPoF

* Network Redundancy 를 통해 클러스터 가용성 높이기

corosync는 corosync의 네트워크 통신 레이어에서 kronosnet (또는 knet) 에 의존한다. knet은 클러스터 커뮤니케이션에 있어서 추상화 레이어에서 이중화와 보안을 제공한다. knet, corosync를 함께 사용하여 최대 8개의 분리된 네트워크에서 노드간 통신을 설립할 수 있다. 하나의 네트워크가 죽으면, 커뮤니케이션은 다른 남아있는네트워크에서 지속된다. knet은 각 서로 다른 서브넷을 가진 네트워크 링크를 요구한다. 만약 동일한 서브넷에서 여러개의 네트워크 인터페이스를 사용하려면 그대신 티밍을 사용해야 한다.

Red Hat은 크로스오버 이더넷 케이블을 사용하여 두 시스템을 다이렉트로 연결하는 것을 지원하지 않는다. 또한 Red Hat은 일반적인 클러스터 사용시 여러개의 네트워크 연결을 지원하지만, DLM을 사용할 때 하나의 네트워크 연결만 지원합니다. 이 제한은  lvmlockd, LVM 공유 볼륨 그룹 및 GFS2 모두 DLM에 의존하기 때문에 이것들 모두 적용됩니다.  

클러스터를 관리하기 위해 사용하는 pcs명령과 이것과 연관된 pcsd 데몬은  knet을 사용하지 않는다. 이 노드는 클러스터를 만들 때 지정한 노드 이름과 연결된 네트워크를 통해 pcs host auth 및 pcs cluster setup 명령으로 통신한다. 해당 네트워크가 장애나면, pcs 명령은 더이상 작동하지 않는다. 클러스터가 여전히 잘 작동하고 있고, 그것이 여러개의 knet 링크 때문이라 하더라도, pcs. 명령은 더이상 작동하지 않는다.  pcs 명령이 사용되는 네트워크를 보호하려면, teaming을 사용해야 한다.

여러개의 링크와 함께 클러스터 구성하기

pcs cluster setup명령으로 새로은 클러스터를 만들때, 각 서버의 사용할 링크 서브넷의 ip주소를 제공하면 여러개의 링크를 구성할 수 있다. 아래 예시는, 네개노드 클러스터이고, 3개의 통신링크를 만든다. 192.168.0.0/24 , 10.4.0.0/16 , 172.16.0.0/16 서브넷이다. addr 옵션을 각 노드 이름 뒤에 사용하여 각 서브넷들을 제공한다.

존재하는 클러스터에 링크 추가하기

pcs cluster link add 명령으로 존재하는 클러스터에 링크를 추가할 수 있다. 사용자는 꼭 각 노드의 새로운 서브넷의 ip주소를 제공해야 한다.  아래예시는 192.168.100.0/24 대역의 링크 하나를 4개 노드 클러스터에 더하는 것이다.

링크 구성 정보 확인

클러스터는 링크 구성 정보를 /etc/corosync/corosync.conf파일에 저장한다. 아래 예시는 각 클러스터 노드가 링크들을 보여주는 섹션이 있는걸알려준다.  클러스터는 유니크 링 넘버로 각 링크들을 식별한다. 위 예시에서는 0~3까지이다. 0,1,2,3

클러스터에서 링크 삭제하기

링크를 제거하기 위해서는 pcs cluster link remove 링번호. 명령을 사용한다. 아래 예시는 링 넘버 3  (192.168.100.0/24)를 삭제한다.

로그상에서 링크 다운 확인하기

트러블슈팅을 위해, /var/log/cluster/corosync.log파일에서 링넘버등을 확인할 수 있다. 아래 예시는 로그에서 해당 링크가 다운된것을 보여준다. 위corosync.conf 파일대로라면, 해당 링은 링크1인 호스트2가 문제가 있다는것을 확인할 수 있다.

* 실습 : 클러스터 통신에 대한 네트워크 이중화 구성

노드는 a,b,c 3노드이다. 클러스터 구성 전 작업은 모두 되어있다. (방화벽, pcsd 등)

노드a 에서, 아래 확인

클러스터 만들때 리던던트 통신 채널을 함께 만든다.

클러스터 시작 및 enable  

 
클러스터가 이런식으로 구성되어 있다. (펜스 부분은 skip) 

이제 192.168.2.0/24 대역을 쓰는 네트워크를 확인하자. 

해당 네트워크를 끊는다. 

다시 상태를 본다. 멀쩡하다 

corosync 로그를 본다. 링크1이 죽어서 호스트 2,3이 다운된걸 확인할 수 있다.

(호스트1은 현재 이 노드a 이다. 로그는 항상 주관 적이므로) 

corosync 파일을 본다. 

* Fencing Level 만들기

여러 레벨의 펜싱 구성

단일 노드에 여러 개의 펜스 장치를 사용할 수 있는 경우 계층화된 토폴로지로 구성할 수 있다. 예를 들어, IPMI over LAN 및 APC by Schneider Electric(이전의American Power Conversion Corporation) 네트워크 전원 스위치 장치를 사용할 수 있는 환경에서 클러스터는 먼저 fence_ipmilan 펜싱 에이전트를 시도할 수 있다. 이후 실패하면 클러스터는 APC 전원 스위치에 액세스하여 노드의 전원을 끄는 fence_apc 펜싱 에이전트를 사용할 수 있다.

이러한 유형의 이중화 펜싱은 펜싱 레벨로 stonith 리소스를 구성하여 구현할 수 있다. 클러스터는 1부터 시작하는 순차 번호로 각 펜싱 레벨을 식별한다. 클러스터가 노드를 펜싱할 때, 먼저 레벨에 추가한 순서대로 레벨 1에 있는 모든 펜싱 장치를 사용하려고 시도한다. 모두 성공하면 클러스터는 노드가 펜싱된 것으로 간주하고 거기서 멈춘다. 그러나 펜싱 장치 중 하나라도 실패하면 클러스터는 해당 레벨의 처리를 중지하고 레벨 2의 펜싱 장치로 계속 진행하는 식으로 계속 진행한다.

Fencing Level 만들기

펜싱 레벨을 추가하기 전에, 모든 stonith 리소스를 구성해두어야 한다. 다 되었다면, pcs stonith level add  레벨 노드명 장치명 을 사용한다. 아래 예시는 2개의펜스레벨을 노드1에 대하여 지정한다.

Fencing Level 관리하기

pcs stonith level 명령으로 레벨 볼 수 있다.

Fencing Level 제거하기

클러스터 노드에 대한 레벨을 제거하기 위해서는 pcs stonith level remove 레벨 노드 명령을 사용한다.

클러스터 노드의 모든 레벨을 제거하기 위해서는,  pcs stonith level clear 노드명 을 사용한다.

노드 이름을 제공하지 않으면, 모든 노드의 모든 펜스 레벨이 제거된다.

장비를 더 추가하기

pcs stonith level 명령은 현재 존재하는 펜스 레벨에 노드를 추가하는것은 제공하지 않는다. 노드를 더하기 위해서는, 전체 레벨을 삭제하고 다시 만들어야 한다.

* Redundant  파워 서플라이 펜싱 구성하기

신중한 구성이 필요한 일반적인 설정은 중복 전원 공급 장치가 있는 노드에 전원 펜싱을 적용하는 것이다. 펜싱 프로세스 중에 클러스터는 노드를 효과적으로 펜싱하기 위해 두 전원 공급 장치에서 전원을 제거해야 한다.

중복 전원 공급 장치로 노드를 올바르게 펜싱하려면 전원 공급 장치당 하나씩 스토니스 리소스를 생성한 다음 동일한 펜스 레벨에 추가한다. 한 레벨에 여러 장치를 추가하려면 pcs stonith level add 명령에 쉼표로 구분된 STONITH 리소스 목록을 입력한다. 다음 예는 node1 머신을 펜싱하기 위해 두 개의 STONITH 리소스를 생성한다. . 해당 머신에는 두 개의 APC 전원 스위치에 연결된 두 개의 전원 공급 장치가 있다. STONITH 리소스는 fence_apc 에이전트를 사용하여 이 두 전원 스위치를 주소 지정한다. 마지막으로, 마지막 명령은 두 리소스로 펜스 레벨 1을 생성한다.

동일한 레벨에서 stonith 리소스를 추가하면 클러스터는 먼저 모든 서버에 대해 "off" 동작을 수행한 다음 모든 서버에대해 "on" 동작을 실행한다. 이 동작은 특정 시점에 모든 노드의 전원이 꺼지도록 보장하여 노드를 효과적으로 펜싱한다. Red Hat Enterprise Linux 7.1 및 이전 버전에서는 클러스터가 이러한 방식으로 작동하지 않으며 더 복잡한 구성이 필요하다. 상세 추가 정보는 다음 링크를 참고할 것. Knowledgebase: "How can I configure fencing for redundant power supplies in a RHEL 6 or 7 High Availability cluster with pacemaker?" [https://access.redhat.com/solutions/1173123] for more information.

 * 실습 : 여러 펜스 디바이스 레벨 만들기

현재 펜스구성 확인

 
이미 클러스터에는 fence_ipmilan 으로 펜스를 구성해둠.
클래스룸에는 두번째 펜스장치를 할 디바이스를 제공함. fence_rh436을 쓸것임. 

pcmk_host_map 파라미터에는 노드와 , 그에 연관된 플러그 넘버를 적는다. 타임아웃은 180초이며 power_timeout 파라미터를 사용한다.
 
추가된 상태를 보자. 

이렇게 하면 클러스터가 노드a를 펜스해야 할떄, 첫번째로 fence_nodea를 쓰고, 이게 페일되면 그다음 fence_classroom을 쓴다.
 

다른 노드에서 반복하자. 

결과를 보자. 

2번펜싱레벨을 쓰는지 보자.
IP 설정을 broke.example.com으로 변경하여 의도적으로 fence_nodec 펜스 장치의 구성에 문제를 일으킨다.
완료되면 nodec 머신에 펜싱을 시도한 다음 클러스터가 머신을 성공적으로 펜싱했는지 확인합니다. 

상태먼저 보자 

펜싱을 날려보자 

클러스터가 성공이라고 한다. 첫번째 레벨은 안됐지만 두번째 레벨을 진행해서 성공한것이다.
 
 
 
   

* References 

corosync.conf(5) man page 

Knowledgebase: "Support Policies for RHEL High Availability Clusters - Cluster Interconnect Network Interfaces"

https://access.redhat.com/articles/3068841

For more information, refer to Creating a high availability cluster with multiple links section in the Configuring and managing high availability clusters guide at 

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_high_availability_clusters/index#proc_configure-multiple-ip-cluster-creating-high-availability-cluster

For more information, refer to the Configuring fencing levels section in the Configuring and managing high availability clusters guide at

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_high_availability_clusters/index#proc_configuring-fencing-levels-configuring-fencing

 * GFS2 파일시스템의 개요

GFS2 파일시스템은 여러 노드에서 동시에 읽기쓰기를 할 수 있는 클러스터 파일시스템이다. 일반 파일시스템과 비슷한 기능을 지원한다. 예를들어 POSIX ACLs, extended attributes, quotas, symbolic links, SElinux 지원 등 모두 지원한다. 동시 접근을 관리하기 위해, GFS2 는 rhel 클러스터 인프라를 사용해 노드를모니터링하고, 펜싱하고, DLM (distributed lock manager) 을 사용해 파일 및 디렉토릭의 잠금을 제어한다.

각 클러스터 노드는 gfs2파일시스템을 모니터링하는데에 각각 분리된 journal을 사용한다. 한 노드가 죽으면, 클러스터는 해당 노드를 펜스한다. 그리고 다른 노드중하나에서 해당 journal을  replay 한다. 사용자는 이러한 저널을 파일시스템 생성할때 할당한다. 그러나 또한 사용자는 존재하는 파일시스템에 추가적인 저널을 추가할수 있다. 

레드햇은 gfs2파일시스템에 대하여 싱글의 경우, 그리고 16개 이상의 노드를 가진 클러스터의 경우에는 지원하지 않는다. 또한 레드햇은 lvm shared lv에 최상단에파일시스템을 만드는 경우에만 gfs2 를 기술지원한다. 한 노드에 마운트하는 파일시스템을 gfs2로 만들지 말아야 한다. 단독 사용에는 xfs가 더 성능도 좋고 설치와관리도 편하다.

순수한 64비트 환경에서, gfs2 파일시스템은 이론적으로 8EiB까지 확장할 수 있다. 그러나, 최대 gfs2 파일시스템 사이즈는 레드햇은 100TiB까지 지원한다. 또한 대부분 설치 환경에서, 큰 사이즈의 gfs2 1개보다 작은 사이즈의 gfs2 여러개가 더 좋다. 큰 사이즈의 gfs2에서, fsck.gfs2 를 수행하면 엄청난 시간을 소요하며 메모리도 많이 먹는다. 또한 이 파일시스템을 리스토어할 때도 많은 시간을 소요한다.

레드햇은 gfs2 파일시스템을 Resilient Storage Add-on 의 일부로 제공한다. grfs2는 클러스터 인프라스트럭쳐가 필요하기 때문이다. 따라서 Resilient Storage Add-on 외에 High Availability Add-on 도 필요하다.

* gfs2 구성 전 사전 확인사항

요구사항 

High Availability Add-on : resilient storage (gfs2) 는 fence 장치와 함께 작동하기 위해 클러스터 인프라에 의존한다.

lvm 공유 볼륨 그룹과 공유 논리 볼륨 :  레드햇은 LVM 공유 볼륨 그룹의 논리 볼륨 위에 파일 시스템을 배포할 때 GFS2를 지원합니다. 모든 클러스터 노드에서 논리 볼륨을 activate 해야 한다.

시간 프로토콜 : gfs2는 클러스터 노드의 시스템 시간과 동기화가 필요하다. chrony 를 사용할 수 있다.

gfs2-utils RPM 설치 : 아래와 같이 패키지를 설치해야 구성이 가능하다.

gfs2 구성 시 필요한 정보

클러스터 노드 수

gfs2 파일시스템이 동시에 마운트되는 클러스터 노드의 수는 생성해야 하는 journal 개수를 식별해준다. 만약 클러스터에 노드를 추가한다면, 그전에 이미 추가 journal이 준비되어 있어야 한다.

클러스터 이름

gfs2파일시스템을 만들때는 클러스터 이름을 명시해야 한다.이 클러스터의 멤버들만이 해당 파일시스템을 마운트할 수 있다.

파일시스템 명

각 gfs2 파일시스템은 클러스터 내에서 유니크하게 식별되는 이름을 가진다. 이 이름은 gfs2 파일시스템 생성시 16글자로 제한되는 이름을 만들 수 있다.

lvm 공유 논리 볼륨 이름

gfs2 파일시스템을 포맷하고 마운트하는데 LV를 사용한다.

추가 필요한 설정

글로벌 클러스터 파라미터인 no_quorum_policy를 freeze로 설정해야 한다. 이 파라미터는 쿼럼을 잃었을 때 클러스터가 어떻게 동작할지를 컨트롤한다. 디폴트값인stop는 클러스터가 쿼럼을 잃으면 모든 리소스를 클러스터가 stop 시킨다. 그러나, 정상작동하기 위해 gfs2는 클러스터가 be quorate 인 것을 요구한다. (쿼럼이 있는 상태)

따라서 쿼럼을 잃게 되는 경우, 모든 리소스가 stop 되게 되니  GFS2 파일 시스템 리소스를 중지하려고 한다. 그런데 gfs2는 쿼럼이 있어야만 정상작동하므로 이gfs2에 대한 모든 중지 시도가 실패하여 결국 클러스터가 완전히 실패하게 된다. 이를 방지하기 위해 no-qurum-policy를 freeze로 둠으로써, 클러스터는 쿼럼이 회복될 때까지 리소스를 중지시키지 않고 아무 작업도 수행하지 않게 한다.

* gfs 파일시스템 생성하기

모든 전제 조건이 갖추어지면 어느 노드에서나 mkfs.gfs2 명령을 사용하여 GFS2 파일 시스템을 생성할 수 있다. 다음 표에는 mkfs.gfs2에 대한 가장 일반적인 옵션이 나열되어 있다.

-t <lock_table_name>

- Locking Table의 이름을 정의한다.

- 이 형식은 "클러스터네임:파일시스템네임" 을 따른다.

- 클러스터네임 : 해당 클러스터네임에 포함된 노드만 파일시스템을 마운트할 수 있다.

- 파일시스템네임 : 파일시스템을 식별하는 유니크한 이름이다. 이 이름길이는 16자 까지로 제한되어있다.

-j <저널수>

- 처음 생성시 저널의 개수를 의미한다.

- 사용자는 이후 추가 저널을 넣을 수 있다.

- 각 노드가 접근하는 파일시스템은 동시에 하나의 저널이 필요하다.

- 만약 이 옵션을 생략하면, 디폴트로 한개의 저널이 생성된다.

J <저널 크기>

- 각 저널의 크기를 MiB로 표현한다. 최소 사이즈는 8MiB 이고, 최대 사이즈는  1GiB 이다.

- 디폴트로, mkfs.gfs2명령은 파일시스템 사이즈에 기반하여 값을 계산한다.

- 최상의 성능을 위하여, 레드햇은 128MiB 이상을 권고한다.

아래 예시는  gfs2파일시스템을 어떻게 만들지 보여준다. 이름은 examplegfs2이다. 또한 examplecluster 에 포함되어있다.  저널사이즈는 128MiB이고, 공유 로지컬볼륨은 /dev/lvmsharedvg/lv1 이다.

* 주의사항

테스트 목적으로, mount 명령으로 , 일반적인 파일시스템들과 동일하게 일시적으로 gfs2를 마운트해볼 수 있다. 하지만 프로덕션 레벨에서는, gfs2 파일시스템을 마운트하기위해서는 꼭 클러스터 리소스로서만 마운트해야한다. 만약 수동으로 gfs2를 마운트하면 (mount 명령어로) 그때는 항상 서버를 끄거나 리스타트하기전에 수동으로 umount 를 해줘야 한다. 그렇지 않으면, 시스템은 종료중에 hang 이 발생한다. 동일한 이유로, 절대로 /etc/fstab에 gfs2 파일시스템을 넣지 말아야 한다.

* 클러스터 리소스를 사용하여 GFS2 파일 시스템 마운트하기

GFS2 파일 시스템에 클러스터 파일 시스템 리소스를 사용하면 다른 클러스터 리소스처럼 해당 리소스를 관리하고 제어할 수 있다.  또한 파일 시스템이 정확하고 깔끔하게 마운트 및 마운트 해제되도록 보장한다.

GFS2는 LVM 공유 논리 볼륨에 의존하고, 이는 다시 lvmlockd 및 DLM에 의존하므로 이러한 서비스를 관리하기 위한 리소스를 이미 생성했는지 확인해야 한다. 이전에 클러스터 LVM 구성에서 작업한 dlm, lvmlockd 리소스 설정, 공유 LV 리소스 설정, 리소스 실행 순서를 정의하는 Constraint 설정까지 완료한 후에 gfs2 파일시스템을 생성해야 한다. 다음 명령은 /data 마운트 지점에 /dev/lvmsharedvg/lv1 GFS2 파일 시스템을 마운트하는 파일 시스템 리소스를 생성한다.

이 명령은 리소스를 LVMshared_group 리소스 그룹에 추가한다. (이 LVMshared_group 리소스에는 이미 LVM-activate 리소스가 있고 클론이 되어있음) LVMshared_group 리소스 그룹을 복제했기 때문에 클러스터는 모든 클러스터 노드에서 파일 시스템을 마운트하고 관리하게 된다.

* gfs2 관리 : 파일시스템에 저널 추가하기

파일시스템이 가진 저널보다 더 많은 노드에 gfs2 파일시스템을 마운트할 수 없다. 파일시스템이 얼마나 많은 저널을 가지고 있는지 찾기 위해, gfs2_edit -p journals 명령을 사용한다. 아래 예시대로는 2개의 저널을 가지고 있는것을 알수 있다.

저널을 추가하려면, gfs2_jadd 명령을 사용한다. 

-j 옵션을 써서원하는 저널의 개수를 명시한다.

-J 온션은 새로운 저널의 크기를 MiB로 명시한다. (디폴트는 128 이다. 128MiB)

사용자는 파일시스템의 장치명이나, 마운트 포인트를 줄 수 있다. 아래 예시는 256 MiB의 저널을 만드는것이다. 이 명령은 한 노드에서만 하면 된다.

* gfs2 관리 :  파일 시스템 확장하기

GFS2는 LVM 공유 논리 볼륨에 추가한 여분의 공간을 활용하여 파일 시스템을 확장 할 수 있다. 레드햇은 확장작업 할 때 꼭 파일시스템 데이터를 백업하기를 권고한다. 또한, gfs2는 축소를 할 수 없다.

gfs2_grow 명령을 써서 gfs2 파일시스템을 확장할 수 있다.  파일시스템 장치명이나 마운트포인트를 명시한다. 명령은 이 파일시스템이 마운트되어있는곳 아무데서나 할 수 있다. 아래 예시는 10GiB 로지컬 볼륨을 추가하고, gfs2_grow 로 테스트하고, 실제로 작업한다.

-T 옵션은 테스트 모드를 활성화한다. 이 모드에서는 일반 모든 작업을 진행하나, 실제로 변경을 디스크에 commmit하지만 않는다.

* gfs2 관리 : 파일시스템 복구하기

일반 상황에서, gfs2 파일시스템은 수동 복구가 필요하지 않다. 노드가 죽었을 때, 파일시스템의 무결성을 유지하기 위해서, 클러스터는 노드를 펜스하고, 다른 노드는 그 저널을 리플레이한다. 몇몇 상황에서 , 예를들어 스토리지 장치가 죽었을 경우, 시스템에서 gfs2 파일시스템을 dirty상태 또는 손상된 상태로 둘 수 있다.

이 경우 fsck 명령을 사용하여 파일 시스템을 복구할 수 있다. fsck 명령은 GFS2 파일 시스템을 인식하고 fsck.gfs2 명령을 호출하여 실제 검사를 수행한다. fsck.gfs2 명령을 직접 실행할 수도 있다.

주의할 것

fsck.gfs2 실행하기 전에, 파일시스템을 모든 클러스터 노드에서 umount 해야 한다. 파일시스템이 리소스로서 클러스터에서 관리되고 있다면, 해당 리소스를 disable하여 모든 노드에서 umount 하게 하도록 하자.

아래 예시는 clusterfs를 disable 한다. --wait 옵션은 명령이 작업이 완료될때까지 기다렸다가 결과를 반환하도록 지시한다. 이 예제에서는 명령이 최대 180초 동안 대기한 다음 해당 타이머가 만료(작업이 제대로 안끝나면) 오류를 반환한다.

이후 fsck.gfs2가 완료되면, 다시 해당 리소스를 enable 한다.

* 슈퍼블록을 변경하기

gfs2 파일시스템을 다른 클러스터로 옮기거나,  클러스터 이름을 바꾸는경우, 꼭 해당 gfs2 슈퍼블록안에있는 locking table name을 업데이트 해줘야 한다. 또한, gfs2 슈퍼블록에 변경을 가하기 전에, 파일시스템을 모든 클러스터 노드에서 umount 해야한다. 

tunegfs2 -l 명령으로 gfs2슈퍼블록을 본다.

tunegfs2 -o locktable=<newname> 명령으로 locking table name을 변경한다.

아래 예시는 이름을 newcluster 로 변경한다.

* 노드 추가하기

노드3개 있는 시스템에서 노드 1개를 추가하여 총 노드 4개가 되도록 한다.

현재 있는 파일시스템 마운트 한거 확인

저널 확인

위 결과는 GFS2 파일 시스템에 저널이 3개만 있다는 것을 보여준다. 따라서 네 번째 노드에 해당 파일 시스템을 마운트하려는 경우 추가 저널을 추가해야 한다.

저널 추가

* 파일시스템 증설하기

현재 용량 확인

2기가 늘리는 작업

 늘리기 위해 따로 마운트를 해제하지 않는다. 즉 온라인중에 가능. 다만 I/O가 적을때 하는것이 권장된다.

확인

* References

mkfs.gfs2(8) and mount(8) fsck.gfs2(8), gfs2_edit(8), gfs2_grow(8), gfs2_jadd(8), and tunegfs2(8) man pages 

Knowledgebase: "What are the recommended best practices for mkfs.gfs2?" 

https://access.redhat.com/solutions/2883291

For more information, refer to the GFS2 file systems chapter in the Configuring GFS2 file systems guide at 

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_gfs2_file_systems/index#assembly_creating-mounting-gfs2-configuring-gfs2-file-systems

For more information, refer to the GFS2 file systems in a cluster chapter in the Configuring and managing high availability clusters guide at 

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_high_availability_clusters/index#assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters

Knowledgebase: "What are some examples of GFS & GFS2 workloads that should be avoided?"

https://access.redhat.com/solutions/41223

Knowledgebase: "How can Red Hat assist me in assessing the design of my RHEL High Availability or Resilient Storage cluster?" 

레드햇은 고객이 계획한 클러스터 구성이 지원 가능한지를 리뷰하기 위해 Red Hat for an Architectural review와 컨택하는것을 추천한다.

https://access.redhat.com/articles/2359891

For more information, refer to the Planning a GFS2 file system deployment chapter in the Configuring GFS2 file systems guide at

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_gfs2_file_systems/index#assembly_planning-gfs2-deployment-configuring-gfs2-file-systems

Knowledgebase: "Do I need to make changes to my GFS/GFS2 file systems when renaming the cluster in RHEL?" https://access.redhat.com/solutions/18430

For more information, refer to the GFS2 file systems and GFS2 file system repair chapters in the Configuring GFS2 file systems guide at 

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_gfs2_file_systems/index

* LVM configuration 파일 소개

/etc/lvm/lvm.conf 파일은 LVM의 동작을 구성한다. 이 파일은 locking 동작을 제어하는 설정, LVM 서명을 검사해야 하는 장치 및 기타 여러 동작을 제어하는 설정을 가지고 있다. 대부분 상황에서는 이 파일을 수정할 필요가 없다. 클러스터에서는 공유 스토리지로써 LVM을 사용하는 두가지 방법이 있는데, HA-LVM (High Availability LVM) 과 LVM 공유 볼륨 그룹  두가지이다. 각각 방식을 설정할 때lvm.conf의 수정이 필요하다.

* 클러스터 스토리지 방식 1 : High Availability LVM 방식 

한번에 한 노드가 VG를 액세스하고, 그 VG안에 있는 LV에 액세스한다.  HA-LVM은 xfs나 ext4같은 전통적인 파일시스템을 쓰는어플리케이션이 active/passive 형태로 클러스터를 사용할 때 좋은 선택이다. 데이터 커럽션을 막기 위해서, 단 하나의 노드만 vg에 액세스 가능하고 파일시스템 마운트가 가능하다.

HA-LVM 구성 전에, 모든 클러스터 노드에서 LVM을 먼저 설정해야 한다. 이 설정은 여러 노드에서 VG가 활성화되는것을 막기 위해 HA-LVM은 VG 메타데이터 안에 SYSTEM ID를 저장한다. 이 구성을 통해서, 해당 SYSTEM ID와 매치되는 그 볼륨 그룹과 그 볼륨그룹의LV만 활성화 될 수 있다. LVM 은 여러 타입의 SYSTEM ID를 지원하는데, uname 타입은 SYSTEM ID로써 호스트명을 사용한다. 이 방법은 구성하기 쉽다.  uname 타입 구성을 지원하기 위해, 모든 클러스터 노드에서 /etc/lvm/lvm.conf를 수정하고, 거기서system_id_source 파라미터를 uname으로 변경하면 된다.

 이 초기 설정이 끝나면, 평소대로 PV를 만들고 VG를 생성하고 LV를 만들면 된다.

HA LVM 생성 및 리소스 올리기

1. lvm conf 변경

nodea / nodeb / nodec 장비를 HA LVM 쓰도록 준비한다. 각 세 노드에서 /etc/lvm/lvm.conf 에서 아래 부분을 수정한다. (수정 전 백업파일을 꼭 만들도록 하자.)

그리고 각 세 노드에서 lvm systemid 명령으로 확인한다.

2. nodea에서, 평소대로 lvm 생성

PV 생성

VG 생성 

VG를 만들때는, system id도 확인된다. 앞의 결과에서, LVM이 VG의 SYSTEM ID로 호스트명을 사용하는것을 알 수 있다. 이 구성에서는 nodea만 이 VG와 통신할 수 있는것이다. lvm systemid 명령, vgdisplay 명령에서도 해당 VG의 System ID를 확인할 수 있다.

LV 생성

참고로 이 LV에 이전에 FILESYSTEM 시그니쳐가 남아있는경우, 아래처럼 뜨는데 Y 하면 된다.

파일시스템 생성

3. nodea에서 halvm이라는 이름으로  LVM-activate 리소스 에이전트를 만든다.

이 에이전트는 HA-LVM 볼륨그룹을 관리하고,  또한 VG와 VG의 LV 활성화/비활성화를 담당한다. 이리소스는 생성할 때  halvmfs 리소스 그룹에 포함되게 한다. 이 리소스가 시작되면, 해당 리소스를 실행하는 노드에서 clustervg VG가 활성화된다.

4. nodea에 서 파일시스템 리소스를 만든다.

이름은 xfsfs이며, halvmfs 리소스 그룹에 포함된다. 이 파일시스템은 /dev/clustervg/clusterlv LV를 사용하며, 마운트 포인트는 /mnt이다.

LVM-activate 리소스가 먼저 생성되고, 그다음 Filesystem 리소스가 생성되어 순서대로 리소스가 올라가도록 해야한다.

5. 확인

 * 클러스터 스토리지 방식 2 :  LVM 공유 볼륨 그룹

 VG와 LV가 모든 클러스터 노드에 모든 시간에 접근이 가능하다. 한번에 하나의 클러스터 노드에서만 VG에 액세스할 수 있는 HA-LVM과 달리, LVM 공유 VG와 LV는 모든 클러스터 노드에서 동시에 사용할 수 있다. 이를 위해 GFS2 파일시스템을 사용한다. GFS2 파일시스템과 함께 LV 공유 VG는 어플리케이션에서 모든 클러스터 노드에서 해당 데이터에 대한 동시 읽기/쓰기를 제공한다. 이 방식은 여러 노드가 동시에 공유 데이터에 접근하는 방식을 사용하므로, lvm.conf에서 LVM 공유 볼륨 그룹 방식을 구성해야 한다. 다만 실제로 수정하지는 않고 리소스로서 구성한다. 이 구성은 꽤 복잡한 작업이며, 다음 섹션에서 설명한다.

유의해야 할 것은, 클러스터되지 않은 파일시스템, ext4나 xfs를 LVM 공유 볼륨 그룹에서 사용해서는 안된다. 이렇게 구성하고 동시에I/O가 발생하면 해당 파일시스템은 커럽션과 부정합이 나타난다. 이는 데이터 손실을 야기시키므로 절대 해서는 안된다. ext4나 xfs를 사용하지 말고, 클러스터 파일시스템 GFS2와 같은걸 써라. GFS2는 여러 노드에서 동시에 마운트하고 액세스할 수 있다.

LVM 공유 볼륨 그룹을 사용할때, LVM 명령어는 모든 클러스터 내에서 메타데이터 변경을 관리하기 위해 로컬 LVM Locking 데몬(lvmlockd) 과 상호작용한다. 이러한 lvmlockd 프로세스는 각 클러스터 노드에서 실행되고 있어야만 한다. lvmlockd는 High Availability Add-on과 별개로 제공되는 Resilient storage Add-on의 부분 중 하나이며, lvm-2lockd rpm패키지에서 제공된다.

또한 서로 다른 노드에서 실행되고 있는 lvmlockd 프로세스들이 서로 자기들의 작업을 싱크로 하기위해, lvmlockd는 Distributed Lock Manager (DLM)에 의존한다. DLM은 dlm 커널 모듈과 커널 모듈을 pilot하는 dlm_controld 프로세스 두가지로 구성된다. 차례대로, dlm_controld 프로세스는 node membership을 위해 클러스터 infrastructure에 의존한다. dlm RPM 패키지가 DLM을 제공한다.

아래 그래픽은 모든 LVM 공유 볼륨 그룹 사이에 컴포넌트들이 상호작용하는것을 보여준다. DLM과 lvmlockd 인프라스트럭쳐가 구축된 후, 사용자는 전통적인 pvcreate, vgcreate, lvcreate 명령어로 LVM 공유 볼륨그룹을 관리할 수 있다.

LVM 공유 볼륨 그룹 구성을 위한 사전준비 : dlm, lvm2-lockd 구성

1. dlm, lvm2-lockd 설치

dlm은 클러스터 인프라에 의존하므로, 우선 인프라부터 설치해야 한다. 또한 이 인프라는 FENCE DEVICE까지 포함이 된다. 즉 dlm은 클러스터 구성과 펜스등에 연관이 있다는 것이다. dlm과 lvm2-lockd RPM을 각 노드에 설치한다.

2. dlm, lvm2-lockd 프로세스 구성

이제 이 두 dlm_controld와 lvmlockd 프로세스를 모든 노드에서 실행되어야 한다. 그런데 이것은 단순히 데몬으로 띄우는 것이 아니라 클러스터에서 띄워줘야 한다. 따라서 클러스터 리소스로서 이 두가지 프로세스를 실행해야 한다. 레드햇 클러스터에서는 위 두 프로세스를 컨트롤하기 위해  ocf:pacemaker:controld와 ocf:heartbeat:lvmlockd 리소스 에이전트 두가지를 제공한다. 

두 리소스는 하나의 리소스 그룹에서, 정확한 순서대로 생성해야 한다. lvmlockd가 시작하기 전에 DLM이 먼저 시작해야 하기 때문이다. 아래 예시에서는 on-fail 파라미터 fence로 설정했는데, 이것은 어떤 노드에서 이 프로세스중 하나라도 fail이 되면 그 프로세스를 재시작하려고 시도하지 않고 해당 노드를 Fence 한다. 그만큼 이 리소스들은 매우 중요하다.

또한 이 프로세스들이 모든 클러스터 노드에서 무조건 실행되고 있어야 하기 때문에,  이 리소스 그룹을 clone 한다.  interleave 파라미터를 true로 설정하는것은, 로컬 노드에서 dlm_controlled 프로세스가 시작되자마자 lvmlockd 프로세스가 시작될 수 있도록 하는 파라미터이다. 이 파라미터가 없으면 lvmlockd 리소스는 모든 노드에서 모든 dlm_controld 프로세스가 시작될 때까지 대기하게 된다.

3. 상태 확인

pcs status --full 명령을 사용하여, 클러스터와 클러스터 정보에 대한 모든 정보를 보게 한다. 아래 정보는 lock_group 리소스 그룹이 3개의 노드에 실행되고 있음을 보여준다.

4. 참고사항

HA-LVM과 달리,  /etc/lvm/lvm.conf에 있는 system_id_source 파라미터를 건드리지 않는다. LVM 공유 VG의 경우, 기본값인 none 을 그대로 두면 된다. 

LVM 공유 볼륨 그룹과 LV 생성, 그리고 리소스 생성

LVM 공유 VG 인프라스트럭쳐가 설치되었으면, 사용자는 이제 표준 lvm 명령어를 통해 vg와 lv를 생성할 수 있다. (몇가지 옵션을 넣어야 한다) 이 명령어는 한 노드에서만 실행하면 되고, 그 명령어는 lvmlockd가 복제하여 모든 노드에 구성을 실행한다. 참고로 LVM 공유 VG를 변경을 할 때는  lvmlockd가 모든 노드에서 살아있고 정상적이어야 한다.

1. PV 및 VG 생성하기

/dev/sdb에 대하여, 아래 명령을 수행한다. 또한 vgcreate 수행시 --shared 옵션을 넣는다. 이것은 일반적인 로컬 vg가 아닌 LVM 공유VG임을 의미한다.

이후 모든 노드에서, VG가 시작된다. 이 명령을 실행하지 않은 다른 모든 노드에서 VG가 lock을 사용하도록 해야한다.  아래와 같이 수행한다.

2. LV 생성하기

lvcreate에 --activate sy 옵션을 넣어야 한다. 이 옵션은 여러 노드가 LV를 동시에 활성화하고 사용할 수 있게 하는 옵션이다. 이 명령어는 한 노드에서만 하면 된다.

3. 파일시스템 생성

이와 같은 공유 논리 볼륨은 GFS2와 같은 클러스터 파일 시스템에 자주 사용된다.  GFS2 파일 시스템으로 공유 논리 볼륨을 포맷하고 사용하는 방법은 내용이 많아 다음 섹션에서 전달한다.

4.  LVM 공유 VG 리소스 올리기

공유 LV를 클러스터에서 사용하기 위해, 첫번째로 해당 노드에서 activate를 해야한다. RHEL HA 클러스터는 모든 클러스터 노드에서activation을 하기 위해 LVM-activate 라는 리소스 에이전트를 제공한다. 아래 예시는 lvmsharedvg/lv1 LV를 활성화하고LVMshared_group 리소스 그룹에 넣도록 sharedlv1 리소스를 생성한다. 또한 이 예시는 이러한 activation이 모든 클러스터 노드에 수행되도록 resource group를 clone 한다.

현재 해당 리소스 그룹 (LVMshared_group) 은 하나의 리소스만 가지고 있는 상태다. 사용자는 일반적으로 LV를 공유 파일시스템인GFS2로 포맷하고, 이 리소스 그룹의 두번째 리소스로서 파일시스템 마운트를 설정한다. 이것도 마찬가지로 모든 노드에 걸쳐 수행해야 한다. 위 3번 절차처럼 GFS2를 생성하고 마운트하는것은 이후 코스에서 다룬다.

마지막 리소스 그룹 (LVMshared_group) 을 생성한 후에는, 클러스터는 2개의 클론된 리소스 그룹을 가진다. 하나는 DLM과 lvmlockd 프로세스 가 있는 리소스 그룹, 그리고 다른 하나는 공유 LV활성화와 파일시스템 리소스 그룹. 총 2개이다.

공유 LV를 활성화하는것은 DLM과 lvmlockd 프로세스에 의존되므로,  dlm, lvmlcokd 프로세스가 먼저 실행되고, 그 이후에 공유 lv 활성화하는 리소스 그룹이 실행되게 해야 한다. 그렇게 하기 위해 아래와 같이 order와 colocation 컨스트레인트를 두 그룹 사이에 설정해야 한다.

* References

lvmlockd(8) and dlm_controld(8) lvmsystemid(7)  man pages

Knowledgebase: "Support Policies for RHEL Resilient Storage - dlm General Policies" https://access.redhat.com/articles/3068921

For more information, refer to the Configuring a GFS2 file system in a cluster chapter in the Configuring and managing high availability clusters guide at

Configuring and managing high availability clusters Red Hat Enterprise Linux 8 | Red Hat Customer Portal

For more information, refer to the LVM logical volumes in a Red Hat high availability cluster section in the Configuring and managing high availability clusters guide at

Configuring and managing high availability clusters Red Hat Enterprise Linux 8 | Red Hat Customer Portal

 * Logical Volume Management 정의

Logical Volume Management (LVM)은 디스크 공간 관리를 더 쉽게해준다. 예를들어, logical volume에서 생성된 파일시스템이 공간이 더 필요한 경우, logical volume이 있는 volume group의 남는 공간을 사용하여 해당 logical volume을 확장하고, 파일시스템을 리사이즈 할 수 있다. 만약 디스크 장애가 발생하면, 대체 디스크를 해당 volume group에 physical disk로 등록하고 해당 logical volum의 extent들을 새로운 디스크로 마이그레이션 할 수 있다.

* lvm 주요 용어 정의

Physical Devices

물리적 장치는 논리 볼륨에 저장된 데이터를 저장하는 데 사용되는 저장 장치이다. 이러한 장치는 블록 장치이며 디스크 파티션, 전체 디스크, RAID 어레이 또는 SAN 디스크가 될 수 있다. LVM과 함께 사용하려면 장치를 LVM 물리적 볼륨으로 초기화해야 한다. 전체 장치가 물리적 볼륨으로 사용된다.

Physical Volume (PV)

Physical Volume은 LVM과 함께 사용되는 기본 물리 스토리지이다. LVM 시스템에서 사용하기 전에 장치를 물리적 볼륨으로 초기화해야 한다. LVM tool은 물리적 볼륨을 물리적 볼륨에서 가장 작은 스토리지 블록 역할을 하는 작은 데이터 청크인 Physical Extents(PEs)으로 세분화한다.

Volume Group (VG)

볼륨 그룹은 하나 이상의 물리적 볼륨으로 구성된 스토리지 풀이다. 이는 기본 스토리지에서 전체 디스크와 기능적으로 동일하다.  PV는 하나의 VG에만 할당할 수 있다. VG는 사용되지 않는 공간과 논리 볼륨으로 구성될 수 있다.

Logical Volume(LV)

논리 볼륨은 볼륨 그룹의 free physical extents을 가지고 생성되며 애플리케이션, 사용자 및 운영 체제에서 사용하는 "스토리지" 장치를 제공한다. LV는 logical extents (LE) 의 모음으로, PV의 가장 작은 스토리지 청크인 physical Extents (PE)에 매핑된다.  기본적으로 각 LE는 하나의 PE에 매핑된다. 특정 LV 옵션을 설정하면 이 매핑이 변경됩니다. 예를 들어 미러링은 각 LE가 두 개의 PE에 매핑되도록 한다.

* lvm 스토리지 구현하기

LVM 스토리지 생성은 여러 스탭이 있다. 첫번째는, 어떤 physical device를 사용할지 결정하는 것이다. 이러한 physical device는physical volume으로 초기화된다. 이를 통해 PV들은 LVM에 belonging 된다고 인식한다. PV는 VG로 합쳐진다. 이것은 LV를 할당할 수 있는 디스크 공간 풀을 생성하는 것이다.  LV는 VG의 사용가능한 공간으로부터 생성되며, 이것은 파일시스템으로 포맷될 수 있다. 또한 스왑 공간으로 쓸수도 있고, 마운트되고 영구적으로 사용될 수 있다.

* LVM 생성 명령어들

LVM 구성을 진행하기전에 PV를 만들 블록 장치를 찾아야 한다. 이것은 전체 디스크가 될 수도 있고, 디스크 내의 특정 파티션이 될 수도있다. 아래 예제에서는 sdb, sdc를 LVM에 사용할것이다. lsblk, blkid, cat /proc/partitions 명령으로 장치들을 식별할 수 있다.

pvcreate

물리적 장치 또는 파티션에다가 이것이 Physical Volume이라고 라벨링을 한다.  또한 이 명령은 Physical Volume을 고정된 사이즈인 Physical Externts (PEs)로 나눈다. 예를들어 PE의 크기는 4MiB가 될 수 있다. 간단히 정리하면, pvcreate 명령은 물리적 장치 또는 파티션을 PV로 만든다. 이러한 PV는 VG에 할당될 준비가 된다.

vgcreate

하나나 하나 이상의 Physical Volume들을 하나의 Volume Group 으로 만든다. VG는 기능적으로 하드 디스크와 동일하다. 사용자는VG에 할당된 PV들이 가지고 있는 PE의 단위로  Logical Volume을 생성할 수 있다. 간단히 말하면 vgcreate 명령은 PV들을 모아 하나의 Pool을 만들고, 다시 거기서 PE의 개수단위로  LV를 생성하는 것이다. 아래 vg01의 크기는 /dev/sdb, /dev/sdc의 크기를 합친 것이 된다.

lvcreate

VG에서 사용가능하 PE를 가지고 새로운 Logical Volume을 생성한다. 몇가지 옵션이 있다. 아래 예시는 LV 생성을 위해 최소한의 옵션이며, 맨 마지막에는 LV를 생성할 VG를 명시한다. 결과적으로 vg01에서 700M 를 가져와서 lv01을 생성하게 된다.

-n : LV의 이름을 지정한다

-L : LV의 크기를 bite로 명시하여 생성한다. / -l : LV의 크기를 extents 개수로 명시하여 생성한다.

-L 옵션의 경우, 그냥 M이 아니라 MiB로 명시하여 명확하게 값을 지정할 수 있다. (KiB, GiB 등) 또한 -l 옵션은 사전에 정해진 extents의 크기에 따라 실제 크기가 결정된다. 예를들어 extents 크기가 4M 이고 200개라면 800M 가 될 것이다. 또한, lvcreate 명령 사용 시 크기가 정확히 일치하지 않을 경우 크기가 물리적 범위 크기의 인수로 반올림된다.

* Filesystem 생성

mkfs 명령어로 LV를 파일시스템으로 만들 수 있다. xfs 외에 여러 파일시스템이 있으나 더이상 자세한 설명은 생략한다.

* LVM의 상태 확인 명령어들

pvdisplay

이 명령은 PV에 대한 상세 정보를 보여준다. pvdisplay 단독으로 사용할수도 있고, 여러 옵션을 사용할수도 있다.

1. 장치에 매핑된 PV의 이름

2. PV가 할당되어있는 VG의 이름

3. 사용하지 않은 용량을 포함하여, 해당 PV의 물리적 크기

4. Physical Extent의 크기 PE는 해당  lV에서 할당될 수 있는 가장 작은 사이즈 단위이며, 또한 사용된PE, 사용하지 않은 PE 값을

    계산할 때의 곱하기 계수가 된다.예를들어 175개의 PE 와 4MiB(PE크기) 를 곱하면 700MiB가 된다. 또한 LV의 크기는 PE 단위의

    계수로 반올림된다. LVM은 PE 크기를 자동으로 설정하지만 따로 지정을 할 수도 있다.

5. Free PE는 새로운 LV 할당에 사용할 수 있는 PE가 몇개나 남았는지 보여준다.

pvs

다른 정보들을 좀 더 컴팩트하게 보여준다.

vgdisplay

VG에 대한 상세 정보를 보여준다. vgdisplay 단독으로 사용할수도 있고, 여러 옵션을 사용할수도 있다.

1. VG의 이름

2. 논리적 볼륨 할당에 사용할 수 있는 스토리지 풀의 총 크기

3. PE의 개수로 표현된 총 사이즈

4. 새로운 LVf를 만들거나 존재하는 LV를 확장하는데 사용할 수 있는 남은 공간이 얼마나 있는지 보여줌

vgs

다른 정보들을 좀 더 컴팩트하게 보여준다.

lvdisplay

LV 에 대한 상세 정보를 보여준다. lvdisplay 단독으로 사용할수도 있고, 여러 옵션을 사용할수도 있다.

1. LV의 장치명을 보여준다. 어떤 툴에서는 /dev/mapper/vgname-lvname 형태로 보여주기도 하는데, 동일한 것이다.

2. 이 LV가 위치한 VG를 보여준다.

3. LV의 전체 크기를 보여준다. 파일 시스템 도구를 사용하여 데이터 저장을 위한 여유 공간과 사용 공간을 확인할 수 있다.

4. 이 LV에 의해 사용된 LE의 수를 보여준다. LE는 일반적으로 VG 안에서 PE와 1:1 매핑된다. 

lvs

lv에 대한 다른 정보들을 좀 더 컴팩트하게 보여준다.

* References

lvm(8), pvcreate(8), vgcreate(8), lvcreate(8), pvdisplay(8), pvs(8), vgdisplay(8), vgs(8), lvdisplay(8), lvs(8), and lvm.conf(5) man pages

Knowledgebase: "What are the advantages and disadvantages to using partitioning on LUNs, either directly or with LVM in between?"

What are the advantages and disadvantages to using partitioning on LUNs, either directly or with LVM in between? - Red Hat Customer Portal

* Multipath란?

리눅스 시스템에서는 스토리지 시스템 (FC, SAS, iSCSI 등)연결시 동일한 디스크를 하나의 통로가 아닌 여러개의 경로로 액세스하게 할 수 있다. Multipath는 이러이러한 중복 경로를 가지는 가상 스토리지 장치를 구성할 수 있도록 하여 시스템에서 스토리지 접근 시 여러 경로를 사용하도록 한다. 이러한 중복 경로는 다음과 같은 이점을 가진다.

- 가용성 증가 : 여러개의 경로 중 하나의 경로에 문제가 생겨도, 시스템은 남은 정상적인 경로로 스위치하여 운영에 문제가 없게 한다. 다만 스토리지 자체가 문제가 생기면 사용은 불가하게 된다.

- 대역폭 증가 : 여러개의 경로를 그룹으로 모아 스토리지 대역폭을 넓혀 성능을 향상시킬 수 있다.

아래는 HBA 카드를 통해 FC를 사용하여 스토리지에 접근하는 예시이다. 서버가 아래처럼 2개의 FC HBA를 가지고  있다. 각 연결은 독립된 FC 스위치에 연결되며, 또한 스토리지 ARRAY에 있는 독립된 컨트롤러와 연결되게 된다.

다른 예시로, 이전 iSCSI 에서 Portal 주소가 1개가 아니라 여러개인 경우, 하나의 target IQN이지만 Portal 주소 경로가 여러개이므로 이 Muiltipath를 구성하여 가용성을 높이거나 대역폭을 증가시킬 수 있는 것이다.

* Multipath 설치 패키지

레드햇 엔터프라이즈 리눅스는 device-mapper-multipath 라는 패키지를 통해 Multipath의 기본적인 바이너리와 데몬을 제공한다. 이 데몬을 통해 시스템은 동일한 디스크와 연결된 여러개의 경로를 자동으로 감지하고, /etc/multipath.conf 파일의 설정에 따라 그룹으로 결합한다.  그룹은 여러 경로로 구성될 수 있다. 이 구성을 사용하면 시스템이 그룹 내부의 경로 사이에 I/O 트래픽을 분산한다.

또한 레드햇 엔터프라이즈 리눅스는 dm-multipath 서브시스템을 사용하여 multipath 지원을 제공한다. dm_multipath 커널 모듈은 가상 디바이스를 생성한다. (여러개의 경로를 가진 하나의 가상 디스크) multipathd 데몬은 이러한 가상 디바이스를 관리하고, 각 경로를 모니터링한다. 사용자는 multipath 명령어를 통해 멀티패스 장치의 상태를 확인할 수 있다.

멀티패스 패키지를 설치할때는 아래와 같은 명령어를 수행한다.

* Multipath 이름 및 구성

커널은 모든 멀티패스 장치 (가상디바이스)에 WWID(World Wide Identifier)를 할당한다. WWID는 글로벌하게 유니크하며, 바뀌지 않는다. 디폴트로, 시스템은 멀티패스 장치명을 WWID로 세팅한다. 시스템은 또한 /dev/mapper 디렉토리에 각각의 WWID로 된 장치 파일을 생성한다. 그러나 이 WWID 는 길고 복잡하여 식별이 어렵다.

/etc/multipath.conf 파일에서 만약 user_friendly_names 옵션을 yes로 세팅하는 경우, 시스템은 심플하고 변하지 않고 유니크한 값을 해당 멀티패스 장치에 할당한다. 이 이름의 형태는 /dev/mapper/mpathN 로 만들어진다. 또한 만약 해당 멀티패스 장치가 파티션을 가졌다면, 시스템은 또한 파티션에 대한 디바이스 명을 만든다. 예를들어, /dev/mapper/mpathap1은 /dev/mapper/mpatha 장치의 파티션1이다.

또한 mpath라는 기본 이름 말고 사용자가 직접 커스텀해서 사용할 수 있다.  /etc/multipath.conf에서 multipaths 섹션에 alias 옵션을 사용하면 된다.

시스템은 WWID가 장치 이름에 매핑된 정보를 /etc/multipath/bindings 파일에 저장한다. 모든 동일한 클러스터 노드에서 동일한 이름을 가지려면, 각 노드에 /etc/multipath/bindings를 똑같이 배포해야 한다.

시스템은 /dev 경로에 디스크 장치에 대하여 /dev/dm-N 의 형태로 이름을 생성한다. 이러한 장치는 엄격하게 시스템 내부용으로만 사용된다. 저장소에 액세스하는 데 직접 사용하지 말 것.

* Multipath 구성파일

위와 같이 multipath 패키지를 설치한 후에는 /etc/multipath.conf 파일을 생성하여 multipath 구성을 사용자가 직접 config 해야한다. 이 파일은 자동으로 생성되지 않으며, 또한 이 파일이 없으면 multipathd 데몬 서비스는 시작하지 않는다. 이 multipath.conf 파일을 생성하기 위해서는 다음 명령을 사용한다.

이 명령은 /etc/multipath.conf 파일을 생성하고, multipathd 데몬도 시작한다. 또한 mpathconf 명령은 가장 자주 사용되는 구성 파라미터를 세팅할 수 있는 추가적인 옵션을 허용한다. 예를들어 해당 명령은 default로 user_friendly_names 을 y로 활성화하는데, --user_friendly_names n 옵션은 이 파라미터를 multipath.conf 구성파일에서 사용하지 않도록 한다.

user_friendly_names 설정을 y로 하면, /dev/mapper/mpathX 라는 이름으로 multipath 장치가 생성되며, n으로 설정하면 멀티패스 디바이스에 WWID를 기반으로 한 이름이 지정된다.

또한 multipath.conf 파일을 수정하는 경우, multipathd 데몬을 재시작해야 한다.

multipath.conf 파일을 구성이 어려운 경우, 쉽게 구성하도록 하기 위해 레드햇에서는 멀티패스 헬퍼라는 툴을 제공한다. 아래 사이트에서 해당 헬퍼를 사용해볼 수 있다. https://access.redhat.com/labs/multipathhelper

* multipath.conf 파일 톺아보기

/etc/multipath.conf 파일은 아래 섹션으로 구성되어있다.

blacklist{}

- 디스크의 경로들을 찾는동안, 시스템은 찾을 수 있는 모든 장치를 multipath topology에 추가한다.

- 블랙리스트 섹션을 설정하면 이러한 토폴로지 추가에서 제외할 장치들의 리스트를 정의한다.

blacklist_exceptions{}

- 블랙리스트 섹션에 나열되어있음에도 불구하고, 멀티패스 토폴로지에 포함해야 하는 장치를 정의한다.

defaults{}

- 이 섹션은 devices나 multipaths 섹션에 명확하게 덮어씌워지지 않는 이상 모든 멀티패스 장치들에 대하여 디폴트 세팅을 정의한다.

- 즉 여기 설정은 devices나 multipaths 설정보다 후순위라는 것.

devices{}

- device 섹션에는, 특정 타입의 storage controller에 대한 default 섹션에서 정의한 것의 재정의 (덮어씌우는)가 포함된다.

- 시스템은 vender, 제품, revision 키워드를 통해 device를 식별한다.

- 이러한 키워드는 sysfs에 있는 정보와 일치되는 정규표현식이다.

multipaths{}

- 특정 multipath devices에 대한 설정이 포함된다.

- 이 설정은 defaults와 devices에서 정의한 파라미터를 덮어씌운다.

- 시스템은 멀티패스 장치의 WWID 로부터 멀티패스 장치를 식별한다.

특정 multipath device의 파라미터를 검색하려면, 시스템은 multipaths 섹션에서 먼저 일치하는 device를 찾고, 그다음 devices 섹션에서 찾는다. 위 두 섹션에서 일치하는 항목을 찾지 못하는 경우, 이제 파라미터를 defaults에서 찾는다. 즉 multipaths > devices > defaults 순으로 찾는다는 것이다.

* defaults() 파라미터 상세

multipath -t 명령을 사용하여 현재 구성 정보를 볼 수 있다. 여기에는 구성 파일에 명시적으로 세팅되지 않은 모든 파라미터를 보여준다. multipath.conf(5) man 페이지에서 각 파라미터의 기본값을 볼 수 있다.  아래는 몇가지 useful한 세팅들을 보여준다.

path_selector

- 이 설정은 I/O에 사용될 "그룹안에 있는 경로"를 선택하는데 있어 멀티패스가 사용할 알고리즘을 세팅한다.

- service-time 0 : 기본값이다. 예상 서비스 시간이 가장 짧은 경로로 다음 I/O 요청을 보낸다.

- round-robin 0 : 그룹 안의 모든 경로에 걸쳐 I/O를 분배한다.

- queue-length 0 : 처리되지 않은 요청 (outstanding request)의 대기열이 가장 짧은 경로로 다음 I/O 요청을 보낸다. (The "queue-length 0" algorithm sends the next I/O request to the path with the shortest queue of outstanding requests. )

path_grouping_policy

- 이 설정은 시스템이 path(경로)를 그룹으로 결합하는 방법을 정의한다.

- 기본 값은 failover 로, multipath가 각 경로를 별도의 그룹에 넣도록 지시한다. 이 구성을 쓰면 시스템은 I/O에 한나의 경로만 사용하고 장애 발생 시 다음 경로로 전환한다.

- multibus 정책을 사용하면, 시스템은 모든 가능한 경로를 하나의 그룹으로 합친다. 그다음 multipath는 path_selector 알고리즘 설정에 따라서 I/O 요청을 경로들에게 분배한다.

- multibus로 매개변수를 설정하기 전에, storage controller가 active-active 연결을 지원하는지 확인해야 한다.

path_checker

- 이 설정값은 multipathd 데몬이 path가 정상인지 확인하는 방법을 구성한다.

- 기본값은 tur 이며, 이 값은 multipathd 데몬이 TUR(Test Unit Ready) SCSI 명령을 사용하여 스토리지 컨트롤러의 상태를 검색하도록 지시한다.

- 일부 path 검사기는 특정 하드웨어에서만 작동한다. 예를들어 emc_clariion 검사기는 EMC VNX 스토리지를 위해 사용되고, hp_sw 검사기는 HPE MSA 스토리지를 위해 사용된다.

- PATH 검사기는 종종 스토리지 장치에 따라 달라질 수 있으므로, 사용자는 일반적으로 path_check 파라미터를 구성파일의 devices 섹션에다 세팅한다.

no_path_retry

- 이 설정은 모든 path가 fail되었을때 multipath 동작을 제어한다.  디폴트값은 fail 이며, multipath가 즉시 상위 레이어에 I/O 에러를 보고한다.

- 이 파라미터는 또한 오류를 보고하기 전에 재시도 회수를 나타내는 값으로 숫자를 사용할 수 있음.

- 값을 queue로 하면, multipath 경로가 정상화될 때까지 모든 I/O 요청들을 대기열에 추가한다. 이 조건에서는, 일부 프로세스가 중단되지 않는 sleep 상태로 영원히 hang 걸릴 수 있음.

user_friendly_names

- multipath device가 이름을 WWID로 받거나 (no 설정) mpathN으로 받게 (yes 설정) 할 수 있다.

* multipath가 아닌 장치를 제외하기

관리하는 디스크들 중에 multipath가 되지 않도록 할 제외 리스트를 사용한다. 일반적으로 로컬 디스크나 이중화 경로가 없는 스토리지 컨트롤러들에서 설정한다. 이러한 장치들은 /etc/multipath.conf 구성파일의 blacklist 섹션에서 정의한다.

find_multipaths 라는 파라미터가 있다. 이 파라미터는 defaults 섹션에서 정의되는데, yes로 하는경우 이 파라미터는 자동으로 하나의 패스만 있는 모든 장치를 멀티패스에서 제외한다. 이 구성은 로컬 디스크나 이중화 경로가 없는 storage device가 멀티패스 되는것을 막는다. 이렇게 쓰면, 보통으로 blacklist 섹션에는 아무것도입력하지 않는다.

직접 구성파일에서 제외하는 경우, 아래처럼 blacklist에 디스크를 명시하거나 (wwid 등으로) devnode 매개 변수를 사용하여 장치 파일을 기반으로 장치를 제외할 수 있다. 두 방법 모두  정규식을 사용할 수 있다.  아래 예시는 두가지 방식 모두를 보여준다.

또 다른 방식은 blacklist 섹션을 사용하여 모든 디바이스를 제외시킨 다음 blacklist_exceptions 섹션을 사용하여 개별 디바이스를 허용하는 방법도 있다. 이 구성에서 blacklist_exceptions 섹션은 an inclusive list으로 작동하게 된다.

* wwid 찾기

시스템은 device의 serial number를 WWID에 사용한다. 시스템은 udev 데이터베이스를 쿼리하여 해당 정보를 가져온다. udev 데이터베이스는 시스템의 모든 device 목록과 속성을 유지관리한다. 따라서 udevadm info 명령을 사용하여 해당 데이터베이스를 볼 수 있다. 예를들어 iSCSI를 통해 등록된 디스크가 /dev/sda인 경우, 아래 명령으로 wwid를 찾을 수 있다.  

 이 예시는 장치 파일 (/dev/sda)가 ID_SERIAL이라는 속성으로부터 WWID를 검색하여 인수로서 쓰는것을 보여준다. 이 36으로 시작하는 문자열을 multipath.conf의 wwid로 사용하면 된다.

* Multipath를 제공하는 스토리지 종류별 멀티패스 설정 구성하기

스토리지 종류에 따라 Multipath 설정을 다르게 해야할 수 있다. 대부분 일반적인 스토리지 하드웨어는 이미, built-in defaults에 정의된 스토리지들의 섹션이 있다. multipath -t 명령을 통해, 이러한 스토리지 컨트롤러의 구성정보를 볼 수 있다. 아래 예시는 알려진 장치의 몇몇 리스트이다.

만약 해당 리스트에 현재 사용자가 쓰고 있는 스토리지가 리스트에 없다면, 설정값을 찾아 섹션을 추가해야 한다. 현재 Multipath로 사용할 디스크의 스토리지 정보는 여러가지 명령들로 확인 가능하다.

- multipathd show paths format "%d %s" (vendor, product, revision 등)
- cat /sys/block/sda/device/vendor

- cat /sys/block/sda/device/model

- cat /sys/block/sda/device/rev

아래는 존재하지 않는 스토리지 하드웨어에 대한 정보를 정의한 예시이다. 위 명령어들로 확인된 값들을 넣을 수 있다.

* 특정 경로의 상세 정보를 구성하기

specific multipath devices의 경우, 사용자는 multipaths{ } 섹션을 사용하여 defaults{ }와 devices{ } 섹션의 파라미터 값들을 덮어씌울 수 있다.

multipaths 섹션의 일반적인 용도 중 하나는 mulitpath device의 alias를 정의하는 것이다. alias를 정의하면, 시스템은 /dev/mapper/ 디렉토리 안에 있는 device 파일의 이름을 해당 alias로 사용한다. 따라서 여러 multipath devices 들을 더 쉽게 구분할 수 있다. 예를들어, 아래 구성은 해당 multipath device인 WWID 3600140562~~를  알리아스를 clusterstorage라고 설정했다. 결과적으로multipath는 /dev/mapper/clusterstorage라는 디바이스 파일을 생성하게 된다.

* Multipath 장치에 대한 파티션을 만들기

multipath device에서 파티션 생성하려면, 아래 두가지 방식 중 한가지를 선택해서 수행한다.

- 파티션 에디터를 사용한다. parted /dev/mapper/mpatha (상세한 parted의 설명은 여기서는 제공하지 않음)

- udevadm settle 명령 사용. 이 명령은 시스템이 새 파티션을 감지하고 /dev/mapper/ 디렉터리에 관련 장치 파일을 생성할 때까지 기다린다. 완료된 경우에만 결과를 리턴한다.

* Multipath 장치 삭제하기

multipath device의 모든 경로를 제거한 후에는, multipath -f <multipath_device> 명령으로 멀티패스 장치를 클리어한다. 만약multipathd 데몬이 실행중이 아니고, 여전이 multipath device 파일이 존재한다면,  그때는 multipath -F 명령으로 모든 멀티패스 장치들을 flush 한다. (완전히 제거하는 명령)이 명령은 다양한 구성을 테스트할 때 이전 구성의 남아있는것들을 제거하려는 경우에 유용하다.

* Multipath 장치 상태 확인하기

multipath -ll 명령은 모든 경로를 컨트롤하고 그들의 스테이터스를 보여준다. 각 multipath device의 정보를 보여준다. 각 device에 대하여, 이 명령은 path group과 각 그룹에 있는 path들을 보여준다. 가장 많이 사용한다. 또한 multipath -l 명령은 multipath topology에 대한 quick review를 보여준다.

아래 예시에서는 두개의 multipath device가 있다. (mpathb, mpatha)

기본 정보

- 첫번째 라인은 user-friendly name (mpathb)를 보여주고, 그다음 device의 WWID를 보여준다. 그리고 vendor와 product 이름을 보여준다.

- 두번째 라인은 devices size, 그리고 write permission (wp) 및 다른 상세사항을 보여준다.

 각 path 그룹

 - 위는 아래는 각 path 그룹을 보여준다. 이 예시에서는, mpathb 는 2개의 path group을 가진다. 한 번에, 하나의 path group만 active 되어있다.

- 그리고 multipath는 active group이 fail되는 경우 inactive group으로 스위치한다.

- 여기서 status 부분이 path group이 active 되어있는지를 보여준다. 두번째 path group은 enabled로 되어있는데, 이것은 active 그룹이 fail에 대비해 이 path group이 ready 상태라는 것을 의미한다.

- policy 부분은 group의 path들 사이에 I/O 요청을 어떻게 분배할지 multipath가 사용하는 알고리즘을 명시한다.  이 속성은path_selector 파라미터와 연관되어있다.

path 그룹 아래에 path 리스트

- 각 path group,은 위와 같이 path들의 리스트가 있다. multipath는 active group안에 있는 모든 path 들 사이에 I/O 요청을 분배한다.

- 이 status 정보는 path의 상태를 가늠하는데 도움을 준다. up 되어있고 I/O 작업에 대해 준비가된 PATH는 ready 상태이다.

- 다운된 path는 faulty로 나온다.

- 위 이미지의 failed, faulty 각각은 동일한 정보를 보여준다. failed는 커널의 관점에서 path device 의 상태를 리포트한다. faulty는multipath path 검사기로부터 나온 상태를 보여준다.

- /etc/multipath.conf 파일은 path_checker 파라미터를 사용함으로써 path 검사기를 정의한다.

다른 예시

- 아래 결과는 시스템이 두번째 multipath device를 가진 것을 보여준다. 이 devie의 이름은 mpatha이다.

- 이 devie는 2개의 포트그룹을 가졌고 각 그룹마다 하나의 path를 가지고 있다.

* path group 정책 식별하기

multipath -ll 명령은 multipath device의 path 그룹화 정책을 명시적으로 보여주지 않는다. 그러나, 명령의 결과를 잘 보면 해당 정보를 추론할 수 있다.

- path 그룹화 정책이 failover인 multipath device 는 각 그룹마다 오직 하나의 path만 가진다.

- 아래 결과는 이 정책의 예시를 보여준다. 각 path 그룹은 단일 path를 포함한다.

-  path 그룹화 정책이 multibus인 multipath device 는 모든 path를 하나의 그룹에 넣는다.

- 아래 예시는 하나의 path group을 보여준다. 모든 path는 하나의 group의 멤버가 된다.

* Failover 확인하기

multipath -ll 명령어는 multipath device의 failover 활동을 가늠하는데 도움을 준다. 주어진 시간에 단 하나의 path group만 active 상태에 있어야 한다. 남아있는 path group들은 enabled 상태로서 wait 하고 있다. 아래 정상 상태의 예시를 보자.

아래 예시는 passive path group의 한 path가 fail되었을 때 multipath -ll 명령의 결과 내부의 변화를 보여준다. passive path group에 있는 path의 상태가 변경되었다 하더라도, active path group과 여기에 연계된 path의 상태는 변경되지 않고 손상되지 않은 상태로 유지된다.

아래 예시는 active path group이 fail된 것을 보여준다. 이전에 active path (2:0:0:0) 가 failed faulty offline 상태이다. 이에 따라, 이것과 연관된 path group의 상태도 또한 변경된다. active에서 enabled로 변경되는 것이다. passive path group은 active가 된다.

위와 같이 문제가 발생한 후, failed path가 회복된다 하더라도, 현재 active path는 active 인 그대로 남는다. 만약 사용자가 이러한 동작을 컨트롤하고 싶으면 /etc/multipath.conf 파일의 failback이라는 파라미터를 수정하면 된다.  이 failback 파라미터의 default 값은manual이다. manual이면 이전 원래 패스로 돌아가지 않고 그대로 유지하는 것이다.

* References

mpathconf(8), multipath.conf(5), and udevadm(8), multipath(8) man pages

For more information, refer to the Overview of Device Mapper Multipathing and Multipath devices chapter in the Configuring device mapper multipath guide at

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_device_mapper_multipath/index

The Red Hat Multipath Helper Tool 

https://access.redhat.com/labs/multipathhelper/

For more information, refer to the The multipath command section in the Configuring device mapper multipath guide at

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_device_mapper_multipath/index#assembly_multipath-command-managing-mpath

* lab : multipath를 사용하여 스토리지에 이중화 구성하기

nodec, noded에서 작업을 수행한다.

1. 두 노드 로그

2. 이니시에이터 설치

3. 각 노드에 /etc/iscsi/initiatorname.iscsi를 설정한다.  각각 nodec와 noded에 맞춰서 적용한다.

4. iscsi 재시작

5. nodec, noded 각각 discover 진행 (192.168.1.15)

만약 실패하는경우, 각 노드에서  /etc/iscsi/initiatorname.iscsi 파일에 내용을 잘 넣었는지 확인

6. nodec, noded 각각 다시한번 discover 진행 (192.168.2.15)

여기까지 하면 디스크가 보일것이다.

7. 멀티패스 설치

8. nodec에서 conf 파일을  만든다. 설정완료후 noded로 복사할것이다.

9. nodec에서, 새로 생긴 disk를 확인한다. 그리고 해당 iscsi storage의 wwid도 확인한다.

10. 멀티패스 파일을 수정한다. 알리아스를 disk1로 만든다.

11. 멀티패스 파일을 복사한다.

12. 두 노드 모두 멀티패스 데몬 실행하고 enable 한다.

13. 둘다 멀티패스 결과 확인이 가능하다.

14. 각 장치에 알리아스가 잘 들어갔는지도 확인한다.

15. 해당 멀티패스 디스크를 가지고 파일시스템을 만든다. 주의할 점은, 만든 파일시스템을 각각 한 번에 하나의 노드에만 마운트해야한다.

우선 nodec에서 파일시스템을 만든다.

그리고 nodec에서 마운트를해보고 파일을 i/o를 발생시킨다 그리고 마운트를 해제한다.

noded에서 마운트를 해서 값을 확인한다. 그리고 마운트를 해제한다.

* lab : multipath로 이중화 된 스토리지 failover 테스트

노드a에서 /dev/mapper/mpatha가 이미 연결되어 있다. 파일시스템을 만들자. 그리고 마운트까지 하자.

이제 path의 상태를 본다.

현재 active path는 sda이다.

이제 active path의 연결을 제공하는 iscsi 네트워크 정보를 확인한다. iscsiadm 명령으로 active path가 사용하고 있는 ip주소와 remote portal을 확인할 수 있다.

여기 보면 /dev/sda 는 192.168.1.15 target에 access 하고있다.

ip route 명령을 써서, 시스템이 remote portal에 접근하는데 사용하는 네트워크 장치의 이름을 찾는다.

eth2를 쓴다.

이제 failover를 보고 파일시스템 접근도 되는지 확인할 것이다. 우선 watch 명령으로 상태를모니터링한다.

새로운 터미널을 열어 nodea에 로그인하고, 루트유저로 들어간다음, eth2 네트워크를 끊는다.

위의 watch 명령으로 보던게 상태가 바뀐걸 알 수 있다.

또한 마운트된곳에 i/o를 일으켰을때 잘 되는지 보자.

이제 다시 정상화시킨다.

그러면, iscsi 스토리지의 이중화는 회북되는것을 볼 수 있다.

하지만 현재 active는 아까 바뀐 그대로 아래가 active인것을 알 수 있으며, failback은 하지 않는다.

다시 i/o를 일으켜서 문제없는지 보자.

* iSCSI란?

 iSCSI는 IP기반 네트워크에서 SCSI 명령을 보내기 위한 TCP/IP 베이스 프로토콜이다.  즉 iSCSI 서버는 IP기반 네트워크를 통해 클라이언트에 디스크로 동작하게 하는 블록 스토리지를 제공할 수 있다. iSCSI 서버가 있고, 서버에 연결된 클라이언트에게 디스크를 제공하는 방식이다.

iSCSI는 IP네트워크로 디스크 I/O를 수행하므로, 대역폭을 여유있게 하기 위해 일반적인 서비스 네트워크와는 대역을 분리해야 한다. 일반적으로 고성능을 위해서는 10G 네트워크를 사용한다.  WAN 보안을 위해, ISCSI 관리자는 IP 네트워크 트래픽 보안을 위한ipsec 이라는 프로토콜 suite 을 사용할 수 있다.

HA 클러스터에서, 관리자는 종종 공유 스토리지를 모든 노드에 제공하기 위해 iSCSI를 사용한다. 이렇게 하여 클러스터가 관리하는 어플리케이션의 데이터를 공유 스토리지에 저장할 수 있다. 어떤 노드에서든 어플리케이션이 데이터에 접근할 수 있기 때문에, 클러스터는데이터의 복사,복제,이동 등 없이 빠르게 다른 노드에서 재시작할 수 있다.

* iSCSI 서버/클라이언트 구조

target (서버)

- iSCSI 서버에 있는 iSCSI 스토리지 리소스이다.

- target은 유니크 이름을 가져야만 한다. (IQN 참고)

- 각 target은 하나 또는 하나 이상의 블록 디바이스를 제공하거나, logical unit들을 제공한다.

- 대부분의 케이스에서 하나의 target은 정확히 하나의 디바이스를 제공한다.

- 하나의 서버는 여러개의 target을 제공할 수 있다.

initiator (클라이언트)

- iSCSI 에게 디스크를 제공받는 클라이언트는 리모트 서버 스토리지인 target에 SCSI 명령을 보내기 위한 initiator 소프트웨어 구성이 필요하다.

- iSCSI 클라이언트, 일반적으로 소프트웨어로써 사용가능하다.

- 사용자는 또한 HBA iSCSI의 형태로 하드웨어 initiator를 구매할수도 있다.

- initiator는 유니크 이름을 가져야만 한다. (IQN 참고)

- 클라이언트 시스템에서, iSCSI targets은 단순히 SCSI 케이블또는 FC 로 연결된 로컬 SCSI 디스크처럼 보인다.  

* iSCSI 서버에서 사용하는 구성요소

여기서 나오는 구성요소들은 iSCSI "서버"를 구축할 때 사용하는 요소이며, 서버 구축은 이 장에서는 다루지 않는다. 개념만 이해해 두면 된다.

IQN (iSCSI Qualified Name)

- initiator와 target 둘다 식별하는 unique worldwide name 이다.

- IQN은 아래와 같은 형태를 가진다

YYYY-MM

DNS 도메인 이름을 처음으로 컨트롤한 첫번째 해와 전체 월. 예를들어, 2020년 6월이라면 2020-06 이다.

com.reserved.domain

예약된 사용자의 도메인 네임. 예를들어, www.example.com 은 -> com.example.com 으로 쓰면 된다. 정해져 있는것은 아니며 자유롭게 사용 가능.

name_string

관리하는 특정 대상을 식별하는 네임스페이스 (YYYY-MM.com.reserved.domain) 의 고유 문자열이다. 관리하는 특정 대상을 식별하는 것으로, 직접 자유롭게 만들면 된다. 예약된 도메인 이름이 정확히 하나의 target을 가진 단일 서버의 특정한 호스트 이름인 경우 생략하기도 한다.

portal

각 target은 하나 또는 그이상의 portal을 가진다. portal은 해당 target에 도달 할 수 있도록 initiator가 사용할 수 있게 하는 ip주소와 포트 쌍을 가진다.

LUN (Logical Unit Number)

LUN은 target에 의해 제공되는 블록장치를 대표한다. 각 target은 하나나 하나 이상의 LUN을 제공한다. (그러므로, 하나의 target은 여러개의 스토리지 디바이스를 제공할 수 있다)

ACL (Access Control List)

접근 권한을 식별하기 위해서 initiator의 IQN이 사용하는 접근 제한. Initiator의 IQN을 사용하여 액세스 권한을 검증하는 액세스 제한이다. 

TPG (Target Portal Group)

TPG는 target에 대한 완전한 구성이다. portal, LUN, ACL이 포함된다. (Portal, LUN, ACL이 합쳐져 하나의 TPG) 거의 모든target은 하나의 TPG를 사용한다. 하지만 advanced configuration에서는 여러 개의 TPG를 정의하는 경우도 있다.

*  iSCSI 클라이언트 구성하기

여기서는 iSCSI 서버는 이미 구성되어 있다고 가정하고 클라이언트 구성법만 제공한다. 연결을 위한 정보는 다음과 같다.

1. 패키지 설치

iSCSI 클라이언트 initiator를 구성하는것은 iscsi-initiator-utils 패키지 설치가 요구된다. 이 패키지에는 iscsi, iscsid 서비스가 포함되어 있고, /etc/iscsi/iscsid.conf와 /etc/iscsi/initiatorname.iscsi 구성파일이 포함되어있다. 아래와 같이 설치를 진행한다.

2. initiator 의 IQN 생성

iSCSI initiator 로서, 클라이언트는 자신의 유니크한 IQN이 있어야 한다. 해당 IQN은 iSCSI 서버에 등록되어 있어서, 연결시 이 IQN이 일치해야만 연결이 가능하다. iscsi-initiator-utils를 설치한 후에, /etc/iscsi/initiatorname.iscsi 파일에서 관리자는 일반적으로 이 파일에 있는 IQN을 그들의 도메인 명 등으로 입맛에 맞춰 수정한다. vi로 /etc/iscsi/initiatorname.iscsi 파일을 열어 위 예시에 맟게 initiator IQN을 구성한다.

InitiatorName=iqn.2021-04.com.example:noded

3. iscsid.conf 구성

/etc/iscsi/iscsid.conf 파일은 연결할 target의 디폴트 세팅을 포함한다. 이 세팅에는 iscsi timeout이나 retry 파라미터 등이 있고, 인증을 위한 유저명과 패스워드 등이 있다. 여기서는 아무것도 건드리지 않고 default 값으로 진행한다.

4. iSCSI 서비스 실행 및 자동시작 구성

이 패키지는 자동으로 iscsi와 iscsid 서비스를 구성한다. 그래서 시스템 부팅시 initiator는 자동으로 이전에 discover된 target을 재연결한다. 이러한 재연결을 위해서는 iscsid 데몬이 서버 실행시 실행되어야 한다. 다음 명령어로 구성한다. 또한  initiator의 configuration file을 수정하는 경우, iscsid 서비스를 재시작해야 한다.

systemctl start iscsid   /   systemctl enable iscsid

5. iSCSI target (서버) 찾기

iSCSI장치를 사용하고 연결하기 전에, 해당 target을 먼저 discover해야 한다. discover 절차는 target 정보를 저장하고, default인/etc/iscsi/iscsid.conf를 사용하여  /var/lib/iscsi/nodes/ 의 디렉토리에서 세팅을 구성한다. 아래 명령어를 통해 원격 target을 discover 할 수 있다. 이명령은 사용가능한 target의 IQN 넘버를 리턴한다. 

- portal_ip : target portal의 ip주소

6. iSCSI target (서버) 연결하기

discover 명령에서 확인된 target의 IQN을 명시하여 연결한다.

# 주의사항

동시에 동일한 target에서 동일한 파일시스템을 마운트하기 위해 multiple initiator를 허용하지 말 것. local block device와 다르게,  각각의(여러개의) 원격 initiator는 iSCSI block device를 네트워크를 통해 discover 할 수 있다. 로컬 파일시스템, 예를들어 ext4, xfs등은 여러 시스템에서 동시에 마운트하는것을 지원하지 않는다. 그렇게 하면 파일을 읽을 때 파일시스템 무결성이 깨지고 커럽션이 발생한다.

# 연결이 잘 안되는 경우

discover는 성공했는데 initiator가 discover 된 target에 로그인하는데 문제를 겪는 경우, 이 문제는 access control이나authentication에 문제가 연관되어 있을 수 있다.  액세스를 허용해야 하는 initiator의 IQN을 iscsi 서버에 있는 iscsi target에 명시함으로써 권한을 부여된다. 즉 initiator의 이름이 iscsi target 서버에 등록되어 있어야 한다는 것이다. 클라이언트에서는 위 절차 2번 항목에서IQN을 명시한다. 이부분이 오타나 문제가 있을 수 있으므로 확인을 해봐야 한다. 만약  /etc/iscsi/initiatorname.iscsi 파일을 수정했다면iscsid 서비스를 재시작해야 한다. 또한 iscsi target 서버에서도 특이사항이 있을 수 있으므로 확인이 필요하다.

7. 연결된 디스크 장치 식별하기

이 시점에서, 서버에는 새로운 SCSI 블록 디스크가 등록되며, 시스템은 로컬로 연결된 디스크처럼 해당 디스크를 감지한다. 현재  iSCSI 로그인 세션에 대한 정보를 print level 3 으로 표시하는 iscsiadm --mode session --print 3 명령으로 새 장치를 식별할 수 있다. 

또는 dmesg, tail /var/log/messages 또는 ls - l /dev/disk/by-path/*iscsi* 명령의 출력을 살펴볼 수도 있다. 이 로그인 프로세스는 재부팅 시에도 지속되므로, 따라서 부팅 후 자동으로 block device를 사용할 수 있다.

8. 식별된 장치를 포맷하여 사용하기

블록 장치가 이미 파티션/파일시스템 또는 lvm 볼륨을 가지고 있다면, mount 같은 명령어로 데이터에 접근할 수 있다. lsblk --fs 명령으로 이러한 구조를 확인할 수 있는데, 아래에서는 /dev/sda는 3개의 파티션이 있고 (OS 영역), /dev/sdb는 LVM 물리적 볼륨이고 파일시스템이 있다. 즉 마운트할 수 있다. 그리고 /dev/sdc는 아무것도 없다. 사용하려면 파일시스템을 생성해야 한다. (아래 예시는 이 iSCSI 클라이언트 구성 예시와 관계 없음)

7번 진행된 부분의 연장선으로 (/dev/sda가 등록된 것) 연결된 디스크가 /dev/sda이고, 아무것도 없다면 아래처럼 파일시스템을 구성하여 마운트하고 사용할 수 있다.

(1) 파일시스템 생성 (ext4 사용()

(2) 마운트 포인트 생성

(3) uuid 확인

(4) /etc/fstab에 설정

#참고 : iSCSI 디스크를 /etc/fstab에 등록하는 경우, 다음 지침을 따라야 한다.

첫번째, lsblk --fs 명령을 사용하여 파일시스템의 UUID를 확인하고, 파일시스템 마운트 시 해당 UUID를 사용하도록 한다. 디바이스 네임(/dev/sda같은) 를 쓰지 않는다. 이것은 부트할 때 바뀔 수 있기 때문이다. device name은 iSCSI device가 네트워크를 통해 응답한 순서에 따라 달라진다. 만약 /etc/fstab에 device name으로 등록을 하고 리부팅 후에 이름이 바뀐다면, 시스템은 잘못된 마운트 포인트에 마운트할것이다. 두번째, /etc/fstab에서 _netdev 마운트 옵션을 사용한다. iSCSI는 원격 장치에 접근시 네트워크에 의존하므로, 이 옵션을 사용하면 네트워크와 initiator가 올라올까지 시스템이 파일시스템을 마운트하려고 시도하지 않게 한다.

(5)마운트 테스트

* 연결된 iSCSI 해제하기

해제를 위해서는 마운트 해제, fstab 수정, iSCSI 로그오프 및 삭제를 해야한다. 아래 예시는 예시일뿐 위 절차와는 관계가 없음.

(1) 마운트 해제

(2) fstab 내용 수정

(3) iSCSI 로그오프

(4) iSCSI 삭제

이렇게 해야 initiator가 부팅할때 해당 target에 자동으로 로그인하지 않는다.

* References

iscsiadm(8) man page

/usr/share/doc/iscsi-initiator-utils/README

Knowledgebase: "What are the advantages and disadvantages to using partitioning on LUNs, either directly or with LVM in between?"

https://access.redhat.com/solutions/163853

For more information, refer to the Creating an iSCSI initiator section in the Managing Storage Devices Guide at

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/managing_storage_devices/index#creating-an-iscsi-initiator_adding-an-iscsi-target

For more information, refer to the Getting started with XFS and Mounting file systems sections in the Managing File Systems Guide at

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/managing_file_systems/index

The Red Hat iSCSI Helper Tool 

https://access.redhat.com/labsinfo/iscsihelper/

For more information, refer to the Getting started with iSCSI chapter in the Managing Storage Devices Guide at

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/managing_storage_devices/index#getting-started-with-iscsi_managing-storage-devices