Capordia애플리케이션에 필요한 교환을 설계하기
각 흐름마다 시작 지점, 목적지, 필요한 담당자를 기록하세요. 채택한 프로토콜, 연결 개시 방향, 빈도, 예상 용량을 추가하세요. 초기 가져오기, 관리 연결, 지속적으로 호출되는 서비스는 같은 기준으로 준비되지 않습니다. 알 수 없는 목적지는 무작정 열어 둘 권한이 아니라 해결해야 할 항목입니다.
이 목록은 팀이 무엇에 접근을 허용하고 무엇을 닫아 둘지 결정하는 데 도움이 됩니다. 또한 누가 변경을 승인하는지도 명시합니다. 연결 특성은 GPU 모델만으로 판단할 수 없습니다: 대역폭, 주소, 포트, 접근 방식은 실제로 제공되는 환경에 대해 확인해야 합니다. 아래 매트릭스는 가상의 프로젝트를 나타낸 것이며, 포함된 서비스로 안내된 것이 아닙니다.
| 흐름 | 명시할 기준 | 담당자 |
|---|---|---|
| 관리 지점에서 환경으로 | 프로토콜, 대상 및 허용된 접근 | 접근 담당자 |
| 데이터 저장소에서 GPU 작업으로 | 초기 용량, 빈도, 재개 | 데이터 소유자 |
| 애플리케이션에서 외부 의존성으로 | 대상, 인증 방식, 허용 가능한 지연 | 애플리케이션 담당자 |
| 결과에서 보존 대상으로 | 최종 용량 및 수령 확인 | 산출물 담당자 |
일정에 중요한 전송 측정
예정된 작업과 파일 수와 크기가 비슷한 대표 샘플을 선택하세요. 단일 압축 파일과 수천 개의 작은 파일은 절차에 서로 다른 부하를 줍니다. 실제로 선택한 대상으로 가져오기와 내보내기를 따로 측정하세요. 두 번째 측정과 비교할 수 있도록 유효 용량, 소요 시간, 도구, 매개변수, 테스트 조건을 기록하세요.
iperf3와 같은 도구는 클라이언트와 테스트 서버 사이의 네트워크 흐름을 측정합니다. 해당 문서는 특히 정방향과 역방향을 구분합니다. 이런 시험에는 양쪽 끝점의 허용이 필요하며, 그것만으로 파일 복사 속도를 입증하지는 못합니다. 파일 복사 속도는 스토리지, 처리, 프로토콜에도 좌우됩니다. 일정이 실제로 의존하는 애플리케이션 전송부터 시작하세요.
측정값을 전송 시간대로 전환
전적으로 가상의 예시: 600GB를 내보내야 합니다. 여기서 1GB는 1,000MB이고 속도는 초당 MB로 표시합니다. 유효 속도 120MB/s에서 600,000 ÷ 120은 5,000초, 즉 1시간 23분 20초입니다. 더 보수적인 70MB/s 가정에서는 약 8,571초, 즉 2시간 22분 51초입니다. 이 속도 중 어느 것도 Capordia의 제공 조건을 설명하지 않습니다.
팀이 패키지를 완성하고 수령을 확인하는 데 45분을 추가하면, 두 번째 가정은 약 3시간 08분이 걸립니다. 3시간 10분의 시간대를 잡고, 필요한 만큼의 여유를 별도로 추가할 수 있습니다. 이 시간대는 조건부입니다: 용량, 파일 수, 전송 조건이 바뀌면 계산을 다시 해야 합니다. 이 추정치를 인터페이스의 이론상 속도로 대체하지 마세요.
| 가정 | 전송만의 소요 시간 | 준비 및 확인 45분 포함 |
|---|---|---|
| 유효 120MB/s | 1시간 23분 20초 | 2시간 08분 20초 |
| 유효 70MB/s | 약 2시간 22분 51초 | 약 3시간 07분 51초 |
필요 이상으로 열지 않고 접근과 재개 준비
먼저 예상 정보로 대상과 호스트 신원을 확인한 다음, 권한과 작업 경로를 확인하세요. 접근 거부는 공용 문서에 명령 계정의 비밀번호를 공유해서 해결되지 않습니다. 환경 접근과 Capordia 계정 로그인은 서로 다른 기능입니다. 비밀을 복사하지 말고 각각의 담당자를 기록하세요.
절차에서 OpenSSH SFTP를 선택하면 전송은 SSH를 통해 이루어집니다. 해당 문서는 부분 재개가 이미 존재하는 조각이 원본 파일과 일치한다고 가정한다는 점도 명시합니다. 원본이 변경되었다면 무작정 재개하면 잘못된 복사본이 만들어질 수 있습니다. 따라서 전송할 버전을 고정하고, 부분 파일을 식별하며, 납품 완료를 선언하기 전에 결과를 확인하세요.
관찰 가능한 단계로 대기 진단
파일은 도착하는데 애플리케이션이 응답하지 않으면 전체 구성을 수정하기보다 애플리케이션 흐름을 살펴보세요. 이름 확인, 연결 열기, 인증, 첫 데이터 읽기, 전체 전송을 구분하세요. 시간, 방향, 유용한 정확한 메시지를 기록하세요. 지원팀과 공유하는 내용에서 자격 증명, 토큰, 데이터는 제외하세요.
복사가 시작된 뒤 느려지면 동일한 조건에서 두 번째 전송을 비교하고, 원본 읽기, 아카이브 준비, 대상 쓰기 등 인접한 단계를 관찰하십시오. 'GPU 사용률 낮음'이라는 관찰만으로 네트워크가 원인이라고 단정할 수는 없습니다. 진단 문서에는 무엇이 무엇을 기다리는지, 그리고 어떤 관찰로 가능한 원인들을 가려낼 수 있는지가 명시되어야 합니다.
외부 접속과 GPU 간 통신 분리하기
애플리케이션에 접속하는 데 사용되는 네트워크와 멀티 카드 연산의 내부 통신은 서로 다른 요구를 충족합니다. CUDA 가이드는 시스템에 따라 달라지는 접근 가능성과 함께 장치 간 데이터 및 연산의 명시적 분배를 설명합니다. 카드 수나 로컬 워크스테이션에서의 양호한 파일 복사는 분산 처리의 작동을 입증하지 못합니다.
따라서 예상 시나리오를 기술하십시오. 각 카드에 할당된 독립 작업인지, 아니면 카드 간에 데이터를 교환하는 처리인지입니다. 그런 다음 소프트웨어가 실제로 사용하는 경로를 확인하십시오. 필요한 스트림이 작동하고, 점검이 기록되며, 중단된 전송을 재개할 수 있는 담당자가 있을 때 수령이 완료됩니다. 이렇게 확정된 조건은 배포 문서에 포함됩니다.
결정을 위한 질문
기획에서 Mo/s와 Mb/s를 구분해야 하는 이유는 무엇인가요?
1바이트는 8비트입니다. 예시의 십진 단위로 70 MB/s는 560 Mb/s에 해당합니다. 두 단위를 혼용하면 추정값이 8배가 되거나 8분의 1이 됩니다. 각 측정값에 단위를 함께 적고 전송의 실제 유효 대역폭을 기준으로 계산하세요.
전송의 양방향을 모두 테스트해야 하나요?
예, 프로젝트가 데이터를 가져온 뒤 결과를 내보내는 경우에는 그렇습니다. 경로, 대상, 조건이 다를 수 있습니다. 가져오기 측정이 양호하다고 해서 최종 회수도 같은 시간 안에 끝난다는 보장은 없습니다. 각 마감이 의존하는 방향을 테스트하십시오.
암호화된 전송이면 파일 점검을 하지 않아도 되나요?
아니요. 전송과 패키지 검증은 서로 다른 문제를 다룹니다. 예상 파일, 무결성, 대상에서의 열기 가능 여부도 확인하십시오. 파일을 잘못 선택하면 전송은 정상적으로 되어도 사용할 수 없는 상태로 남을 수 있습니다.