송주환 
스토리지 서버는 현재 40G 듀얼로 연결된 상태인데, 각 포트가 20G에 바운드되고 있습니다.
아리송하네요.
+ R/W를 50:50으로 잡아도 똑같이 6.8GB/s 정도에서 바운드되네요 네트워크 병목은 아닌 것 같습니다.
+ Block Size를 키우니 거의 기대값과 비슷한 성능이 나와 주네요.
VROC의 오버헤드가 생각보다 크거나, iSER Target의 커널 오버헤드가 상당한 것 같습니다. 좀 더 파봐야겠어요
(6/22 추가)
Linux-IO Target 사용 시 이슈가 있어, StarWind VSAN iSER Target으로 변경했습니다. 테스트 결과는 추후 업데이트 예정입니다.
현 시점에서 가장 의심되는 부분은 VROC 볼륨의 Stripe Size입니다. 64KiB로 맞춰놨거든요.
여담으로 vSphere 7.0 U2부터 vMotion을 수행할 때 VMkernel NIC의 대역폭에 맞춰 여러 개의 채널을 생성하도록 로직이 변경되었습니다.
이제는 vMotion 성능을 끌어올리기 위해 다중 VMKNIC을 할당할 필요가 없습니다 ㅎㅎ
그러면서 재발견(?) 되기도 하구요. 여러모로 신선합니다.
오히려 PCIe slot 대역폭이 병목으로 작용하는 경우가 다반사입니다.
* 특히 듀얼 포트 구성 시에는 더욱 그렇습니다.
사실 RDMA가 PHY Lane의 영향을 피해갈 수 있는 이유는 여전히 모르겠습니다. 혹시 관련 문서나 레퍼런스가 있을까요?
OS or Hypervisor의 경우 Kernel Bypass 로 표현되기도 합니다만,
근본적으로 iSER의 경우 Connection 시에만 TCP/IP를 이용하고 실제 데이터 전송 시 IB와 동일하게 RDMA Read/Write 방식을 이용하기에 PHY Lane 갯수에 따른 제약과 상관없이 전체 하드웨어의 최대 속도로 동작합니다.
Ethernet 진영의 입장에서는 신성모독에 가까운 동작방식이라고 해외에서는 평가하고 있습니다...^^
하기 링크의 그림을 보시면 이해가 되실 듯 해서 링크를 남겨드립니다.
https://www.roceinitiative.org/roce-introduction/
저도 관습적으로 TCP 연결에 대해서는 마치 LACP와 같다고 보고 다중 세션을 만들어주고 있으나, 사실 멀티 레인 구현이 LACP와 동일한 것은 아니니.. 잘은 모르지만 MAC Hash 기반의 LB는 아니겠죠.
제가 PHY Lane의 구현을 몰라서 이런 의문을 가지게 되는 걸지도 모르겠습니다. 친절한 답변 감사드립니다.
즉 케이블에 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를 더 권장하기도 합니다.
도움이 되시길 기원드리며 이만 줄이겠습니다.
궁금한 건 왜 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 추천합니다.
SPDK 사용도 고려했으나, Sample NVMe-oF 타겟은 안정성이 상당히 떨어져서.. 차선책으로 선택한 것이 iSER 입니다.
SPDK Target 안정성 나쁘지 않습니다. 개인적인 경험으로는 iSER 보다 떨어지지 않고 더 빨리 좋아지는것 같습니다.
iSER 장점은 구조상 시스템 사양에 상관없이 좋은 성능이 나지만
SPDK는 시스템 사양에 비례해서 좋은 성능 차이가 발생하죠
님이 보유하신 장비 사양이 떨어지지 않는것 같은데 그렇다면 SPDK가 나쁜 선택지는 아닐겁니다.
물론 ESX 기반이면 뭐...
SPDK 사용을 한번 고려하봐야겠네요.
Target은 스토리지 서버고, initiator는 ESXi 호스트입니다
https://koutoupis.com/2022/04/22/vmware-lightbits-labs-and-nvme-over-tcp/
이게 않되나요?
https://www.youtube.com/watch?v=-ymECwnWabQ
Initiator (EXSi)가 target에 따라서 Path가 활성화되고 안되고 하는게 잘 이해가 가질 않네요. 나름 표준인데...
저희가 SPDK 뿐만 아니라 3가지 Target (제품) 사용하는데 모두 문제 없이 사용하고 있거든요
Linux Kernel nvme-of-rmda target에 버그로 보이는데 찾아봐야 겠습니다. 큰 버근 아닐텐데요 . initiator 쪽이면 뭐 방법없게지만요
즐거운 주말 되겠네요
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이 있다면 귀띔 부탁드리겠습니다. 하하..
예전에는 DEV KIT라고 저렴하게 판매했었는데 요즘에도 DEV KIT이 있는지 모르겠습니다. DEV KIT 팔면 그서 사시면 제일 깔끔합니다
그런데 OFED에 없나요? 있을꺼 같은데....
BMT 데이터는 잠시 후 업로드 하겠습니다.