모범 사례 Block Storage for Classic

저장 공간의 성능을 극대화하고 애플리케이션 다운타임을 피하기 위해 최고의 방법을 따르십시오.

우수 사례 1-경로 지우기

최대 IOPS를 달성하려면 적절한 네트워크 리소스가 제 위치에 있어야 합니다.

전용 VLAN에서 스토리지 트래픽을 실행하십시오. 소프트웨어 방화벽을 통해 스토리지 트래픽을 실행하면 대기 시간이 늘어나서 결국 스토리지 성능이 저하됩니다. 방화벽을 우회하는 VLAN을 통해 스토리지 트래픽을 실행하는 것이 가장 좋습니다. 자세한 정보는 자체 VLAN 인터페이스로 스토리지 트래픽 라우팅 을 참조하십시오.
가능할 때마다 스토리지 트래픽을 게이트웨이 디바이스로 라우팅하지 마십시오. 스토리지 트래픽이 게이트웨이 디바이스로 라우팅되면 스토리지 트래픽에 대기 시간을 추가하거나 게이트웨이 디바이스의 방화벽이 잘못 구성된 경우 스토리지 트래픽이 중단될 수 있습니다. 스토리지 중단은 특히 단일 (클러스터되지 않은) 게이트웨이 디바이스에서 다시 시작과 같은 유지보수가 필요한 경우에 적용됩니다. 저장 트래픽이 게이트웨이 장치를 통해 라우팅되어야 하는 경우, 게이트웨이 장치에 최소 10Gbps 인터페이스가 있는지 확인하십시오. 그렇지 않으면 게이트웨이 장치가 네트워크 병목 현상이 될 수 있습니다.
더 빠른 NIC를 사용하십시오. 처리량 한계는 LUN 레벨에서 설정되며 더 빠른 인터페이스는 해당 한계를 늘리지 않습니다. 그러나 이더넷 연결이 느려지면 대역폭이 최상의 성능 레벨을 달성하는 데 잠재적인 방해가 될 수 있습니다.
더 높은 대역폭을 선택하십시오. 이더넷 연결 속도는 볼륨의 예상 최대 처리량보다 빨라야 합니다.일반적으로는 이더넷 연결이 사용 가능한 대역폭의 70%를 초과하여 사용하지 않아야 합니다.

예를 들어, IOPS가 6,000이며 16KB 블록 크기를 사용하는 경우 볼륨은 약 94MBps의 처리량을 처리할 수 있습니다.그러나 볼륨에 1Gbps 이더넷 연결이 되어 있으면, 서버가 사용 가능한 최대 처리량을 사용하려고 할 때 병목 현상이 발생합니다. 1Gbps 이더넷 연결(초당 125MB)의 이론적 한계치인 70%가 초당 88MB밖에 허용하지 않기 때문입니다.

우수 사례 2-중복성을 위해 다중 경로 설정

Block Storage for Classic 최고의 성능을 자랑하는 검증된 엔터프라이즈급 하드웨어와 소프트웨어를 기반으로 구축되어 높은 가용성과 가동 시간을 제공합니다. 데이터는 HA 페어링 노드의 여러 물리적 디스크에 중복 저장됩니다. 각 스토리지 노드에는 자체 SSD(Solid-State Drive) 및 파트너 노드의 SSD에 대한 여러 경로가 있습니다. 이 구성은 지속적인 생산성을 위해 노드가 파트너의 디스크에 계속 액세스할 수 있으므로 경로 실패 및 제어기 실패를 방지합니다. 실제로 시스템은 고객 성능을 저하시키거나 데이터 손실 위험을 줄이지 않고 동시에 클러스터에서 여러 디스크를 유실할 수 있습니다. 중복 네트워크 포트 및 경로는 클라우드 연결 전반의 네트워크 장애로부터 보호합니다.

802.3ad LACP 포트 채널을 통해 iSCSI 트래픽을 실행하지 마십시오. LACP(Link Aggregation Control Protocol)는 iSCSI를 사용한 권장 구성이 아닙니다.
입출력 밸런싱과 중복성을 위해 다중 경로 입출력(MPIO) 프레임워크를 사용하십시오. MPIO는 스토리지 장치에 대한 연결을 위해 로드 밸런싱 및 장애 복구 프로세스를 구성하는 프레임워크입니다. 다중 경로 지정 솔루션은 어댑터, 케이블 및 네트워크 스위치와 같은 중복 물리적 경로 구성요소를 사용하여 서버와 스토리지 장치 간의 논리 경로를 작성합니다. 각 스토리지 노드에는 SSD 드라이브에 대한 다중 경로가 있습니다. 호스트에는 경로 간에 I/O 로드를 분산시키고 한 경로에서 다음 경로로 내부 장애 복구를 처리하는 방법이 필요합니다. 이 상황에서 MPIO가 작동하면 서버는 MPIO 없이 동일한 디스크의 여러 인스턴스를 볼 수 있습니다.

MPIO 구성을 사용하는 경우, 여러 NIC가 있는 서버가 사용 가능한 모든 인터페이스에서 해당 MPIO 지원 스토리지 디바이스로 I/O를 전송 및 수신할 수 있습니다. 이 구성은 하나 이상의 네트워크 구성 요소가 실패하여 경로가 실패하더라도 스토리지 트래픽이 안정적으로 유지되도록 하는 중복성을 제공합니다. 다중 경로 논리는 애플리케이션이 여전히 데이터에 액세스할 수 있도록 I/O에 대한 대체 경로를 사용합니다. 서버에 1Gb NIC가 두 개 있고 스토리지 서버에 1Gb NIC가 두 개 있다면, 이론상 최대 처리량은 약 200MB/s입니다.

단일 경로로 Block Storage for Classic 첨부하는 것도 가능하지만, 서비스 중단이 발생하지 않도록 두 경로 모두에 연결을 설정하는 것이 중요합니다. MPIO가 올바르게 구성되지 않은 경우 네트워크 가동 중단이 발생하거나 IBM Cloud® 팀이 유지보수를 수행할 때 스토리지 디바이스의 연결이 끊기고 오프라인으로 표시될 수 있습니다.
필요한 경우 iSCSI 다중 세션을 추가하십시오. 대상당 다중 세션 (MS/T) 을 갖는 것은 Oracle에서 문서화된 스토리지 성능 튜닝 전략입니다. MS/T를 사용하고 여러 TCP 연결을 생성하면 네트워킹 스택을 더 잘 활용할 수 있습니다. 여러 개의 송수신 스레드를 사용하면 성능을 향상시킬 수 있습니다.

iscsiadm CLI를 통해 지속적 iscsi 다중 세션을 추가하십시오.
1. 기존 세션을 나열합니다.
```
iscsiadm -m session
```
2. 다음 명령을 사용하여 세션 수를 수정하십시오. 이 구성 변경은 호스트가 다시 부팅될 때 지속됩니다.
```
iscsiadm -m node -T <IQN> -p <IP> --op update -n node.session.nr_sessions -v <TOTAL_SESSION>
```
  다음 예제는 대상 포털 161.26.115.77:3260에 세 개의 세션 (총 네 개) 을 추가하는 것을 보여줍니다.
```
iscsiadm -m node -T iqn.1992-08.com.netapp:stfdal1306 -p 161.26.115.77:3260 --op update -n node.session.nr_sessions -v 4
```
3. 포털에 로그인하여 추가 세션을 설정하십시오.
```
iscsiadm -m node -T iqn.1992-08.com.netapp:stfdal1306 -p 161.26.115.77:3260 -l
```
4. 단일 포털 IP에 대해 추가된 세션을 보려면 세션을 나열하십시오.
```
iscsiadm -m session
```
5. 다음 명령에서 X 대신 세션 ID를 사용하여 iSCSI 세션에서 로그아웃하십시오.
```
iscsiadm -m session -r X -u
```

우수 사례 3-호스트 및 애플리케이션 최적화

사용자의 요구를 가장 잘 충족하는 I/O 스케줄러를 사용하십시오. I/O 스케줄러는 디스크 액세스 요청을 최적화하는 데 도움이 됩니다. 이들은 일반적으로 I/O 요청을 병합하여 최적화를 수행합니다. 디스크의 유사한 섹션에서 요청을 그룹화하면 드라이브가 자주 "탐색" 할 필요가 없으므로 디스크 조작에 대한 전체 응답 시간이 향상됩니다. 최신 Linux 구현에서는 여러 I/O 스케줄러 옵션을 사용할 수 있습니다. 각 스케줄러에는 디스크 액세스 요청을 스케줄링하는 고유한 방법이 있습니다.
- 최종 기한 은 Red Hat 7.9의 기본 I/O 스케줄러이며 일반적으로 다른 I/O 스케줄러로 변경할 필요가 없습니다. 대기 시간 지향 스케줄러이며 별도의 읽기 큐 및 쓰기 큐를 작성하여 작동합니다. 각 입출력 요청에는 만기 시간 동안 커널에서 사용할 수 있도록 연관된 시간소인이 있습니다. 이 스케줄러가 가능한 가장 효율적인 순서를 기반으로 큐를 서비스하려고 시도하는 동안 만기 시간은 각 I/O 요청에 대한 "최종 기한" 으로 작동합니다. I/O 요청이 최종 기한에 도달하면 가장 높은 우선순위로 푸시됩니다.
- 조작 없음 (NOOP) 은 들어오는 I/O를 전달하는 기본 스케줄러입니다. 이 스케줄러는 모든 I/O 요청을 FIFO (First In, First Out) 큐에 배치합니다. 이는 다른 스케줄러의 복잡한 I/O 스케줄링 결정이 I/O 성능 저하를 유발하는지 여부를 확인하는 데 유용한 도구입니다. 이 스케줄러는 지능형 스토리지 또는 다중 경로 환경과 같은 I/O 스케줄링을 수행하는 디바이스를 사용하는 설정에 권장됩니다. 호스트에서 더 복잡한 스케줄러를 선택하면 호스트의 스케줄러와 스토리지 디바이스의 스케줄러가 서로 경쟁하여 성능을 저하시킬 수 있습니다. 스토리지 디바이스는 일반적으로 I/O를 스케줄하는 가장 좋은 방법을 판별할 수 있습니다. I/O 스케줄러를 확인하고 구성하는 방법에 대한 자세한 정보는 Red Hat의 NOOP 또는 없음 IO 스케줄러 사용 방법을 참조하십시오.
- 완전히 공정한 큐잉 (CFQ) 은 엘리베이터 및 요청 병합을 모두 사용하며 NOOP 또는 최종 기한 스케줄러 보다 약간 더 복잡합니다. 많은 Linux 배포판의 표준 스케줄러입니다. 모든 큐에 대해 디스크를 사용하기 위해 시간 조각을 할당하기 전에 조작에 의해 작성된 동시 요청을 일련의 프로세스당 풀로 그룹화합니다.
작업 로드가 대화식 애플리케이션에 의해 지배되는 경우, 사용자는 많은 입출력 조작을 수행하는 데이터베이스의 성능이 저하되는 것을 불평할 수 있습니다. 이러한 환경에서 읽기 조작은 쓰기 조작보다 훨씬 더 자주 발생하며 애플리케이션은 데이터를 읽기 위해 대기할 가능성이 더 높습니다. 기본 IO 스케줄러 설정을 확인하고 다양한 스케줄러를 사용해 보며 특정 작업량에 맞게 최적화할 수 있습니다.
I/O큐 깊이를 조정하십시오. /etc/iscsi/iscsid.conf node.session.queue_depth 를 기본값 32에서 64로 변경하십시오. 대부분의 호스트 버스 어댑터 (HBA) 의 기본 큐 깊이는 약 32이며, 이는 일반적으로 최대 대상 IOPS까지 생성하기에 충분합니다. 볼륨에 대한 경로가 하나뿐이라면, 그것이 최대 IOPS 수입니다. 그러나 2개 이상의 세션이 있는 동일한 볼륨은 목표 볼륨에 대한 초당 스토리지 처리량의 I/O를 더 많이 밀어붙일 수 있습니다. I/O 깊이를 늘리는 것의 반대 측면은 지연 시간이 늘어난다는 것입니다. 대기 시간을 줄이려면 점보 프레임을 사용으로 설정하십시오. 호스트 큐 깊이 권장사항에 대한 자세한 정보는 호스트 큐 설정 조정 을 참조하십시오.
점보 프레임 활성화 전체 네트워크 경로에서 동일하게 구성하십시오. 소스 장치 > 스위치 > 라우터 > 스위치 > 대상 장치에서. 전체 체인이 동일하게 설정되지 않은 경우에는 체인에서 가장 낮은 설정으로 기본 설정됩니다. IBM Cloud®의 네트워크 디바이스는 현재 9000으로 설정되어 있습니다. 최상의 성능을 위해서는 모든 고객 디바이스를 값 9,000으로 동일하게 설정해야 합니다.

호스트에서 MTU를 9000으로 설정하면 다음과 같은 이점이 있습니다.
- 데이터는 더 적은 수의 프레임으로 전송될 수 있습니다.
- 패킷 헤더에 저장되는 형식 정보의 바이트가 적게 필요하므로 데이터를 더 빠르게 전송할 수 있습니다.
- 패킷 처리를 위한 CPU 주기 및 명령어 수를 줄여 처리량을 증가시킵니다.
- 점보 프레임은 패킷이 순서를 벗어나 도착하거나 유실될 가능성이 적으므로 재전송이 줄어듭니다. 재전송 횟수가 적을수록 TCP 복구에 소요되는 시간이 줄어듭니다. 결과적으로 처리량이 더 많아집니다.
팀 구성을 위한 VMware 특정 우수 사례를 따르십시오. 스토리지 어레이에 대한 네트워크 액세스의 가용성을 높이기 위해 팀 구성을 사용하려는 경우 가상 IP 주소가 공유되는 두 포트의 스위치에서 포트 보안을 꺼야 합니다. 이 포트 보안 설정의 목적은 IP 주소의 스푸핑을 방지하는 것입니다. 따라서 많은 네트워크 관리자가 이 설정을 사용합니다. 이를 변경하지 않으면 포트 보안 설정이 한 스위치 포트에서 다른 스위치 포트로 가상 IP의 장애 복구를 방지하며 팀 구성은 한 경로에서 다른 경로로 장애 복구할 수 없습니다. 대부분의 LAN 스위치의 경우 포트 보안은 포트 레벨에서 사용 가능하므로 각 포트에 대해 설정 또는 해제할 수 있습니다.