☰

SCSI와 SAN은 어떻게 신뢰성을 얻습니까?

tag-icon • tag-icon storage scsi san
SCSI와 SAN은 어떻게 신뢰성을 얻습니까?

저는 SCSI를 처음 접했고 실제로 이것이 올바른 포럼인지 확실하지 않습니다. (SCSI 문제를 발견했기 때문에 이렇게 했습니다. :) 자유롭게 개선/마이그레이션하시기 바랍니다.

파이버 채널 전송을 조사하고 있으며 TCP와 달리 FCP-3을 통한 SCSI는 제공이 보장되지 않는다는 내부 문서를 읽었습니다. 따라서 제 질문은 다음과 같습니다.

  1. 이것은 SCSI 표준/프로토콜 자체가 신뢰할 수 없다는 뜻입니까? 하지만 한때는 하드 드라이브가 매우 인기가 있었던 것 같아요. 신뢰성 문제는 어떻게 해결됩니까?
  2. 마찬가지로 SAN 환경에서는 안정성이 어떻게 처리됩니까?

답변1

같은 비교를 하는 비공식 기사를 찾았는데, 대략적인 인상과 일치했습니다. @Sobrique가 언급했듯이 이 기사에서는 다중 경로가 FC 스위치 또는 대규모 SAN의 단일 케이블 장애에도 살아남을 수 있음을 보여줍니다.

SCSI는 삭제 명령을 친절하게 받아들이지 않습니다. SCSI가 명령 손실을 용인할 수 없다는 것은 약간의 오해입니다. 예, 회복하는 데 시간이 오래 걸립니다(상대적으로 말하면). 시스템 속도를 저하시키는 SCSI 오류를 많이 보았습니다. 그러므로 SCSI 명령을 잃지 않는 것이 가장 좋습니다.

https://datacenteroverlords.com/2011/09/14/fibre-channel-and-ethernet-the-odd- Couple/

FCP는 공식적으로보장하다전달되었지만... Wikipedia 기사를 읽으면 FibreChannel은 특정 비트 오류율(허용/예상)을 지정합니다. TCP는 링크에서 작동하도록 설계되었으며 FibreChannel보다 패킷에 대한 관심이 훨씬 적습니다.

FibreChannel에는 정체/버퍼 오버플로로 인한 패킷 손실을 방지하기 위한 흐름 제어도 포함되어 있습니다. IP는 그렇지 않습니다(그리고 기본 네트워크가 어떤 식으로든 그렇게 할 것으로 기대하지 않습니다).

예를 들어 구글에는 이런 것이 있다.멋진 종이그들은 평균 1%에서 1% 사이의 TCP 패킷 손실률을 측정했습니다.20% 이상. (그들은 ISP가 20% 이상의 손실을 유발하는 기술(정책) 대신 1%의 손실을 유발하는 기술(셰이핑)을 사용하도록 옹호합니다. 이러한 기술은 IP 네트워크가 일반적으로 혼잡 문제를 처리하는 방식입니다.

나는 대부분의 SCSI 구현이 실패한 명령을 재시도할 것이라고 생각합니다. 얼마나 표준화되어 있는지는 모르겠지만, 여러 면에서 조정이 가능했으면 좋겠습니다. 기술적으로 이것은 TCP가 결국 시간 초과될 것으로 예상할 수 있는 것처럼 전달을 보장하지 않습니다(TCP는 연결을 포기하고 닫습니다).

답변2

ServerFault에 대한 것일 수 있습니다.

하지만 당신 말이 맞아요. 파이버 채널에는 TCP와 동일한 보호 메커니즘이 없습니다. 이 점에서 이는 UDP와 더 유사하며(비록 비유가 약간 약하긴 하지만) 동일한 이유 때문에 TCP는 이러한 신뢰성 메커니즘으로 인해 일부 응용 프로그램에서는 좋지 않은 솔루션입니다. 스트림이 다시 전송이 중단될 수 있습니다. "이며 이는 패킷 손실보다 거의 실시간 애플리케이션에 더 큰 피해를 줍니다. 스토리지 IO 대기 시간이 20밀리초를 초과하면 "상처"가 발생하기 시작합니다. 이는 실제로 TCP가 작업을 수행하기에 충분한 시간이 아닙니다.

FCP의 경우 엔드포인트의 SCSI 드라이버는 안정성의 일부로 로드 균형 조정도 수행할 수 있으므로 안정성 처리를 담당합니다. 일반적으로 단일 광섬유가 연결되지 않고 이중 독립 스토리지 경로가 있는 이중 HBA가 있습니다.

따라서 드라이버는 원하는 방식으로 패킷을 라우팅할 수 있으며(일부 드라이버는 다른 드라이버보다 더 똑똑합니다. 요즘 대부분은 다중 경로를 수행하지만 일부는 꽤 스마트한 적응형 다중 경로를 수행합니다) 어떤 IO가 승인되었는지 여부를 추적합니다. 운영 체제는 적절한 상황에서 IO를 대기열에 넣을 수 있습니다. 음, 나쁜 생각이라고 생각하는 경우에는 그렇지 않습니다. 실제로 이는 일반 파일 시스템 캐싱 메커니즘의 일부로 수행됩니다.

그렇기 때문에 예를 들어open다음과 같은 옵션이 있습니다 O_DIRECT.

   O_DIRECT (since Linux 2.4.10)
          Try to minimize cache effects of the I/O to and from this
          file.  In general this will degrade performance, but it is
          useful in special situations, such as when applications do
          their own caching.  File I/O is done directly to/from user-
          space buffers.  The O_DIRECT flag on its own makes an effort
          to transfer data synchronously, but does not give the
          guarantees of the O_SYNC flag that data and necessary metadata
          are transferred.  To guarantee synchronous I/O, O_SYNC must be
          used in addition to O_DIRECT.  See NOTES below for further
          discussion.

관련 정보