9.3. iSCSI Timeouts
9.3. iSCSI 타임아웃
iSCSI recovery actions are often dependent on iSCSI time-outs being recognized and acted upon before SCSI time-outs.
iSCSI 복구 작업은 SCSI 타임아웃 이전에 인식되고 조치를 취하는 iSCSI 타임아웃에 따라 달라지는 경우가 많습니다.
Determining the right time-outs to use for various iSCSI actions (command acknowledgements expected, status acknowledgements, etc.) is very much dependent on infrastructure (hardware, links, TCP/IP stack, iSCSI driver).
다양한 iSCSI 작업 (예상되는 명령 승인, 상태 승인 등)에 사용할 적절한 타임아웃을 결정하는 것은 인프라 (하드웨어, 링크, TCP/IP 스택, iSCSI 드라이버)에 따라 크게 달라집니다.
As a guide, the implementer may use an average Nop-Out/Nop-In turnaround delay multiplied by a "safety factor" (e.g., 4) as a good estimate for the basic delay of the iSCSI stack for a given connection.
참고로, 구현자는 특정 연결에 대한 iSCSI 스택의 기본 지연에 대한 적절한 추정치로 "안전 계수" (예: 4)를 곱한 평균 Nop-Out/Nop-In 전환 지연을 사용할 수 있습니다.
The safety factor should account for the network load variability.
안전계수는 네트워크 부하 변동성을 고려해야 합니다.
For connection teardown the implementer may want to consider also the TCP common practice for the given infrastructure.
연결 해제를 위해 구현자는 주어진 인프라에 대한 TCP 일반적인 관행도 고려할 수 있습니다.
Text negotiations MAY also be subject to either time-limits or limits in the number of exchanges.
문자 협상에는 시간 제한이나 교환 횟수 제한이 적용될 수도 있습니다.
Those SHOULD be generous enough to avoid affecting interoperability (e.g., allowing each key to be negotiated on a separate exchange).
이는 상호 운용성에 영향을 주지 않을 만큼 충분히 관대해야 합니다 (예: 각 키가 별도의 교환에서 협상되도록 허용).
The relation between iSCSI timeouts and SCSI timeouts should also be considered.
iSCSI 타임아웃과 SCSI 타임아웃 사이의 관계도 고려해야 합니다.
SCSI timeouts should be longer than iSCSI timeouts plus the time required for iSCSI recovery whenever iSCSI recovery is planned.
SCSI 타임아웃은 iSCSI 타임아웃보다 길어야 하며 iSCSI 복구를 계획할 때마다 iSCSI 복구에 필요한 시간을 더해야 합니다.
Alternatively, an implementer may choose to interlock iSCSI timeouts and recovery with SCSI timeouts so that SCSI recovery will become active only where iSCSI is not planned to, or failed to, recover.
또는 구현자는 iSCSI 타임아웃 및 복구를 SCSI 타임아웃과 연동하도록 선택하여 iSCSI가 복구할 계획이 없거나 복구에 실패한 경우에만 SCSI 복구가 활성화되도록 할 수 있습니다.
The implementer may also want to consider the interaction between various iSCSI exception events - such as a digest failure - and subsequent timeouts.
구현자는 다이제스트 실패와 같은 다양한 iSCSI 예외 이벤트와 후속 타임아웃 간의 상호 작용을 고려할 수도 있습니다.
When iSCSI error recovery is active, a digest failure is likely to result in discovering a missing command or data PDU.
iSCSI 오류 복구가 활성화되면 다이제스트 오류로 인해 누락된 명령이나 데이터 PDU가 검색될 가능성이 높습니다.
In these cases, an implementer may want to lower the timeout values to enable faster initiation for recovery procedures.
이러한 경우 구현자는 복구 절차를 더 빠르게 시작할 수 있도록 타임아웃 값을 낮출 수 있습니다.