maronet 06-19

어마무시 합니다!

송주환 06-19

그냥저냥 쓰기에는 나쁘지 않은 성능인데, 들인 돈을 생각하면 더 잘 나와야 하는 거 아닌가 싶기도 하고.. 그렇습니다 ㅎㅎ

maronet 06-19

vMotion도 포트그룹 하나면 최대 전송속도 제한(싱글스레드의 한계?)되잖아요. VROC+iSER 조합의 경우는 그런 구간이 없을까? 하는 생각도 듭니다. 40G/100G NIC이 10x4, 25x4 구조인 것도 영향이 있을 것 같구요.

송주환 06-19

RDMA는 Lane에 따른 제약이 없다고 들었으나 확실하지는 않습니다. 이 점을 고려해서 듀얼 포트로 멀티패스 구성을 해 뒀고, 최악의 경우에도 4호스트 * 2 = 8개의 세션이 생성되도록 하였습니다. 256KiB Block Size 테스트에서 16GB / 2 = 8GB, 즉 64Gb/s 정도의 단방향 트래픽이 처리되고 있는 것을 감안하면, 네트워크는 병목 지점이 아닌 것으로 보입니다.
현 시점에서 가장 의심되는 부분은 VROC 볼륨의 Stripe Size입니다. 64KiB로 맞춰놨거든요.

여담으로 vSphere 7.0 U2부터 vMotion을 수행할 때 VMkernel NIC의 대역폭에 맞춰 여러 개의 채널을 생성하도록 로직이 변경되었습니다.
이제는 vMotion 성능을 끌어올리기 위해 다중 VMKNIC을 할당할 필요가 없습니다 ㅎㅎ

maronet 06-19

생각해보니 예전에 core에서 관련글 보고도 깜빡깜박합니다 ㅠ.ㅠ

송주환 06-19

저도 이번에 아키텍처 디자인하면서 새로 알게 된 내용입니다. 의외로 New Feature에 대한 KT가 일률적으로 이루어지지는 않는 것 같아요 ㅎㅎ
그러면서 재발견(?) 되기도 하구요. 여러모로 신선합니다.

Inbusiness 06-22

RDMA 이용 시 Lane 구성과 상관없이 최대 대역폭에 근접하는 성능을 보여줍니다.
오히려 PCIe slot 대역폭이 병목으로 작용하는 경우가 다반사입니다.
* 특히 듀얼 포트 구성 시에는 더욱 그렇습니다.

송주환 06-22

PCI-E 4.0 + CX-6 구성이라 PCI-E 대역폭 문제는 아닙니다. VROC Stripe Size를 32KiB나 16KiB로 줄인 뒤 다시 테스트 해보려고 합니다.
사실 RDMA가 PHY Lane의 영향을 피해갈 수 있는 이유는 여전히 모르겠습니다. 혹시 관련 문서나 레퍼런스가 있을까요?

Inbusiness 06-23

OSI 7 Layer 구성 중 하단부터 4개의 단계를 뛰어넘어 작동하는 방식이기 때문에 그렇습니다.
OS or Hypervisor의 경우 Kernel Bypass 로 표현되기도 합니다만,
근본적으로 iSER의 경우 Connection 시에만 TCP/IP를 이용하고 실제 데이터 전송 시 IB와 동일하게 RDMA Read/Write 방식을 이용하기에 PHY Lane 갯수에 따른 제약과 상관없이 전체 하드웨어의 최대 속도로 동작합니다.

Ethernet 진영의 입장에서는 신성모독에 가까운 동작방식이라고 해외에서는 평가하고 있습니다...^^

하기 링크의 그림을 보시면 이해가 되실 듯 해서 링크를 남겨드립니다.

https://www.roceinitiative.org/roce-introduction/

송주환 06-23

실제로 IB 패킷을 덤프해보면 패킷은 패킷이고, 결국 스위치 입장에서는 패킷의 형태로 들어갈 터인데, IB에서 단일 QP로 예를 들어 10G*4 = 40G 대역폭을 풀로 뽑아줄 수 있다면, TCP 세션도 당연히 가능해야 하지 않나.. 라는 생각이 드네요.
저도 관습적으로 TCP 연결에 대해서는 마치 LACP와 같다고 보고 다중 세션을 만들어주고 있으나, 사실 멀티 레인 구현이 LACP와 동일한 것은 아니니.. 잘은 모르지만 MAC Hash 기반의 LB는 아니겠죠.

제가 PHY Lane의 구현을 몰라서 이런 의문을 가지게 되는 걸지도 모르겠습니다. 친절한 답변 감사드립니다.

Inbusiness 06-27

TCP/IP session의 특성 때문에 그렇습니다.
즉 케이블에 4 Lane 구성이 되어있어도 실제로 이용하는 Lane은 1개입니다.
그렇기 때문에
01. TCP/IP의 경우 PHY Lane 1개만 이용하고
02.RDMA의 경우 OSI 7 Layer 중 몇개를 건너 뛴 상위 레벨에서 전송만을 지시하면 바로 목적지 상위 레벨에서 인식하고 작동합니다.

그런 이유로 물리적인 모든 연결(link)를 이용합니다.

이런 이유 때문에 vSphere 7.0.x에서 추가된 NVMeOF over TCP/IP를 이용하시는 경우 오히려 40GbE 보다 25GbE를 더 권장하기도 합니다.

도움이 되시길 기원드리며 이만 줄이겠습니다.

송주환 06-27

감사합니다.

epowergate 06-23

VROC 이슈는 아닐겁니다.  확인하시려면 VMWARE 빼고 그냥 LINUX 설치하시고 FIO/VDBENCH 수행해 보시면 알 수 있을겁니다.

궁금한 건 왜 iSER를 사용했을까 입니다.  3번 정도 읽어 봤는데 여전히 이해를 하지 못했습니다.
iSER는 아시는것처럼 iSCSI over RDMA입니다.
iSCSI Protocol을 보면 Control과 Data 2가지로 나누어 집니다.
그런데 iSCSI에서는 Control은 TCP로 전달을 하고 DATA만 RMDA로 통신을 합니다.
Control은 IPoIB를 사용할 겁니다 (예전에는 그랬습니다.  아마 지금도 그럴겁니다)
DDR/QDR 및 적당한 수준의 DISK를 사용하는 Target에서는 IPoIB의 오버헤드가 크지않지만
NVMe/EDR 수준에서는 영향을 미칠겁니다.  (데이터는 없습니다)

그냥 NVME over RDMA로 설정해보시면 어떨까 합니다.
Target은 SPDK 추천합니다.

송주환 06-23

NVMe-oF 사용을 먼저 고려해보았는데, ESXi에서 사용하려면 Fused command가 지원되어야 하나 Kernel NVMe-oF는 해당 명령어를 지원하지 않아 사용이 불가했습니다.

SPDK 사용도 고려했으나, Sample NVMe-oF 타겟은 안정성이 상당히 떨어져서.. 차선책으로 선택한 것이 iSER 입니다.

epowergate 06-23

ESX에서 target을 운영하는지는 몰랐습니다.
SPDK Target 안정성 나쁘지 않습니다.  개인적인 경험으로는 iSER 보다 떨어지지 않고 더 빨리 좋아지는것 같습니다.
iSER 장점은 구조상 시스템 사양에 상관없이 좋은 성능이 나지만
SPDK는 시스템 사양에 비례해서 좋은 성능 차이가 발생하죠
님이 보유하신 장비 사양이 떨어지지 않는것 같은데 그렇다면 SPDK가 나쁜 선택지는 아닐겁니다.
물론 ESX 기반이면 뭐...

송주환 06-23

아. ESXi에서 타겟을 운용하는 것은 아닙니다 ㅎㅎ 타겟은 베어메탈 스토리지 서버입니다. ESXi에서 타겟을 Stroage Device로 인식시키려면 Fused Command가 지원되어야 하는데, 커널 NVMe-oF에선 지원하지 않았습니다. 대신 SPDK Example target에서는 지원됩니다.

SPDK 사용을 한번 고려하봐야겠네요.

epowergate 06-23

ESXi에서 NVMe-Of를 DataStore로 잡고 GuestOS에서 그 DataStore를 사용하지 않으시나요?

송주환 06-23

맞습니다. Kernel NVMe-oF 사용 시 lun path가 dead로 뜨며, 그 이유는 Kernel nvmeof가 fused command를 지원하지 않기 때문입니다.
Target은 스토리지 서버고, initiator는 ESXi 호스트입니다
https://koutoupis.com/2022/04/22/vmware-lightbits-labs-and-nvme-over-tcp/

epowergate 06-23

제가 뭘 착각을 하던지 이해를 못하는 것 같습니다.
이게 않되나요?
https://www.youtube.com/watch?v=-ymECwnWabQ

송주환 06-23

네. 안 됩니다. Path가 활성화되지 않아요. SPDK Target은 될 겁니다.

epowergate 06-23

응...
Initiator (EXSi)가 target에 따라서 Path가 활성화되고 안되고 하는게 잘 이해가 가질 않네요.  나름 표준인데...
저희가 SPDK 뿐만 아니라 3가지 Target (제품) 사용하는데 모두 문제 없이 사용하고 있거든요
Linux Kernel  nvme-of-rmda target에 버그로 보이는데 찾아봐야 겠습니다.  큰 버근 아닐텐데요 .  initiator 쪽이면 뭐 방법없게지만요
즐거운 주말 되겠네요

송주환 06-23

initiator쪽 이슈로 볼 수도 있고, 타겟 이슈로 볼 수도 있습니다. 예를 들어 원래 NVMe 표준은 SCSI-3 Command 중 하나인 COMPARE AND WRITE를 Atomic하게 구현할 수 없었는데 리비전 1.2.1에서 Atomic COMPARE AND WRITE 커맨드를 fused command 형태로 구현하였습니다.
ESXi는 VAAI에서 타겟 볼륨에 대한 fine-grained lock을 얻기 위한 수단으로 COMPARE AND WRITE 커맨드를 이용하는데, ESXi NVMe-oF Initiator에서는 이걸 fused command request로 전송합니다. 그리고 타겟이 이 기능을 지원하지 않으니 정상적인 연결로 보지 않는 것이죠.

일단 NVMe 표준에 있는 기능이니, 타겟이 지원하는 것이 가장 깔끔하지만 적어도 Kernel NVMe-oF 모듈은 당분간 지원될 것 같지 않습니다. 관련 패치가 코드 패스가 너무 지저분하다는 이유로 리젝되었거든요. 하기 링크가 도움이 될 것입니다.

https://lore.kernel.org/linux-nvme/20210105224939.1336-2-clay.mayers@kioxia.com/T/

P.S. 혹시 홈랩에 사용할 수 있을 정도의 가격을 가진 상용 NVMe-oF Target이 있다면 귀띔 부탁드리겠습니다. 하하..

epowergate 06-29

PS답: Mellanox에 연락하셔서 상황 설명하고 하나 달라고 하면 줄겁니다. 
예전에는 DEV KIT라고 저렴하게 판매했었는데 요즘에도 DEV KIT이 있는지 모르겠습니다.  DEV KIT 팔면 그서 사시면 제일 깔끔합니다
그런데 OFED에 없나요? 있을꺼 같은데....

송주환 06-29

감사합니다. OFED에선 못 본 것 같고, SPDK 타겟으로 타협해야 할 것 같아요. libaio로 블럭 디바이스에 접근함에도 성능이 꽤 괜찮게 나오네요. iSER보다 나아요.
BMT 데이터는 잠시 후 업로드 하겠습니다.