업데이트: 8개의 추가 SATA 포트가 있는 보드에서 이 시나리오를 시도했는데 작동했습니다. 생각보다 느리지만 그래도 괜찮습니다. David Schwartz와의 토론에 따르면 병리학적으로 문제가 있다는 그의 말이 맞을 수도 있고 RHEL이 동시에 많은 호스트 컨트롤러를 처리할 수 없다는 Ali Chen의 말이 맞을 수도 있다고 생각합니다. 여기까지 왔고 기본적으로 이 시점에서 호기심을 가지게 되었기 때문에 좀 더 실험해 볼 예정입니다. :)
원본 게시물 시작
그래서 설정이 조금 길어졌습니다. 우리 시스템에는 대역폭 문제를 방지하기 위해 PCIe 2.0 소켓에 하나, PCIe 3.0 소켓에 하나 등 두 개의 RocketU 1144D 4 포트 USB 3.0 카드가 있습니다. 각 USB 카드에는 외부 전원 공급형 Silver Stone Raven 인클로저에 4개의 Crucial MX300 1TB SSD가 부착되어 있습니다. 고객별로 필요한 것은 MD5 체크섬을 계산하기 위해 다른 4개의 디스크에서 파일을 읽는 동안 8개의 디스크 중 4개의 디스크에 동일한 파일 세트를 동시에 쓸 수 있는 것입니다. 각 디스크는 파일을 읽을 때나 모든 파일을 쓴 후에 크기가 대략 1GB인 파일로 가능한 한 용량에 가깝습니다.
이제 카드 중 하나의 디스크에만 액세스하거나 파일을 쓰는 경우 속도는 그다지 나쁘지 않습니다. 전체 TB에서는 파일당 평균 3~4초(읽기/계산 또는 쓰기)가 발생합니다. 문제는 동시에 두 가지 작업을 시도할 때 읽기 및 쓰기 속도가 파일당 약 1.5초에서 시작하여 파일당 60초 이상으로 매우 빠르게 저하된다는 것입니다.
시스템의 유일한 다른 카드는 PCIe 3 16x 슬롯의 비디오 카드와 다른 PCIe 3 8x 슬롯의 Intel X540-T2 어댑터(현재 사용되지 않음)입니다.
우리는 2개의 6코어 Zenon 프로세서가 탑재된 듀얼 CPU X10DRL-i 서버 MOBO와 SATA 포트에 연결된 다른 Crucial MX300에서 RHEL 7.2를 실행하는 64GB RAM을 보유하고 있습니다.
따라서 문제는 다음과 같이 정의된 적절한 시간 내에 위에 설명된 작업을 수행할 수 있느냐는 것입니다. SSD당 1,001GB 파일을 읽고 카드 1에 연결된 4개의 SSD에서 읽고 카드 2에 연결된 4개의 SSD에 기록해야 합니다. (고객 때문에) 한 시간 이내에 모두 병렬로 완료됩니까?
내가 배운 것에서 나는 아니오쪽으로 기울기 시작했지만 나보다 더 많은 지식을 가진 사람이 더 확실한 것이 있는지 물어보고 확인해야겠다고 생각했습니다. 도움, 조언, 특히 답변을 주시면 대단히 감사하겠습니다.
David Schwartz의 제안에 따라 편집:
카드당 필요한 대역폭 USB 3.0 포트당 5Gbps x4 포트 = 20Gbps
레인당 500MBps에서 사용 가능한 대역폭 PCIe 2.0 x4 = 16Gbps
한 카드는 PCIe 3 레인을 사용하고 다른 카드는 PCIe 2 레인을 사용하므로 해당 리소스에 대한 충돌이 없어야 한다고 생각합니다.
메모:
카드가 대역폭에서 과도하게 판매되었다는 것을 알고 있지만 읽기 및 쓰기는 GB 파일당 몇 분 안에 이루어져서는 안 됩니다.
편집 2:
David Schwartz의 제안 이후 시스템 모니터와 htop을 사용하여 코어 사용량을 모니터링했습니다. 시스템은 처음 12개의 파일 IO에 대해 100% 또는 거의 100%에 가까운 사용량 또는 4개의 코어를 표시합니다. 그러면 시스템이 몇 초 동안 정지되고 이때 파일 IO 저하가 발생합니다. 또한 이후 코어 활용도가 100%에 도달하는 경우는 거의 없으며, 100%에 도달하더라도 매우 짧은 시간입니다.
편집 3: 최종 편집일 가능성이 높습니다.
약간의 연구와 실험을 거친 후에는 이것이 현재 사용 중인 카드에 대해 작동하지 않을 것이라고 말할 수 있다고 생각하며 의견에 언급된 StarTech 카드도 작동하지 않을 것이라고 장담합니다. 나는 우리가 여러 가지 사실을 바탕으로 그러한 결론에 도달할 수 있다고 믿습니다. 즉, 하나의 SSD가 카드에서 훌륭하게 작동합니다. 두 개는 약간의 속도 저하 없이 정상적으로 작동합니다. 머리 위인 것 같아요. 그러나 3명 이상이 나쁜 짓을 하기 시작합니다. 이는 우리가 16Gbps 상당의 PCIe 레인을 통해 20Gbps를 추진하려고 시도하고 있으며 이론상 최대 16Gbps를 얻는 대신 전송 양쪽의 컨트롤러가 서로 걸려 넘어져 일반적으로 상황이 다음 지점으로 백업될 수 있기 때문이라고 생각합니다. 크롤링으로의 데이터 전송 속도가 느려집니다. 이것은 단지 이론일 뿐이지만 고객이 USB 요구 사항을 낮추고 SATA 및 기타 방법을 시도할 수 있게 하기에 충분했습니다. SATA가 훨씬 더 잘 작동하고 있으므로 승자가 있다고 생각합니다. 도움과 제안을 주신 David Schwartz와 Ali Chen에게 감사드립니다.
편집 4: 실제 최종 편집
그래서 어제 SATA 솔루션을 살펴보던 중 여러 부분에서 제 질문에 대한 답을 우연히 발견했습니다. 실제 문제는 두 가지였으며 첫 번째 문제가 발견된 후에야 분명해졌습니다.
그래서 첫 번째 문제는 메모리 관리였습니다. 쓰기 위해 대용량 파일을 읽는 소프트웨어를 테스트한 결과 파일을 한 번 읽은 다음 여러 번 쓰는 것처럼 보였습니다. 사실은 그렇지 않았습니다. 따라서 여러 1GB 파일에 대한 여러 읽기 요청이 지속적으로 발생했습니다. 이것이 테스트에서는 작동했지만 실제로는 작동하지 않은 이유는 확실하지 않지만 사후 분석을 수행할 시간이 없었기 때문에 기록으로 남겨 두었습니다.
두 번째 문제는 우리가 하드웨어 전문가가 아니기 때문에 Linux 시스템에서 작업하는 동안 매우 중요한 세부 사항 하나를 알지 못했다는 것입니다. NTFS는 Linux에 고유한 것이 아니기 때문에(우리는 이것을 알고 있습니다) 분명히 거의 10배 느리게 실행될 것입니다(우리는 몰랐습니다). 이것이 Windows 상자였다면 문제가 없었을 것입니다.
이 두 가지 요소를 결합하면 우리가 경험한 불규칙한 동작이 발생합니다. 모든 디스크를 EXT4로 완전히 다시 포맷한 후에는 예측할 수 없는 읽기/쓰기 시간이 전혀 표시되지 않았고 모든 것이 예상대로 작동했습니다. 허용되는 매개변수 내에서 동시 쓰기 및 읽기/md5 계산을 수행할 수 있습니다.