로그와 데이터 드라이브에는 드라이브를 공유 할 때 서로 (적어도 이론적으로는) 충돌하는 서로 다른 데이터 액세스 패턴이 있습니다.

로그 쓰기

로그 액세스는 매우 많은 수의 작은 순차적 쓰기로 구성됩니다. 간단히 말해서 DB 로그는 디스크의 특정 위치에 데이터 항목을 쓰는 명령 목록이 들어있는 링 버퍼입니다. 액세스 패턴은 완료를 보장해야하는 다수의 작은 순차적 쓰기로 구성되므로 디스크에 기록됩니다.

이상적으로, 로그는 조용한 (즉, 다른 것과 공유하지 않는) RAID-1 또는 RAID-10 볼륨에 있어야합니다. 논리적으로 프로세스를 로그를 작성하는 기본 DBMS 및 로그를 소비하고 변경 사항을 데이터 디스크에 기록하는 하나 이상의 로그 리더 스레드로 프로세스를 볼 수 있습니다 (실제로 프로세스는 데이터 쓰기가 기록되도록 최적화됩니다) 가능한 경우 즉시 밖으로). 로그 디스크에 다른 트래픽이있는 경우 헤드는 이러한 다른 액세스에 의해 이동되고 순차 로그 쓰기는 임의의 로그 쓰기가됩니다. 이 속도는 훨씬 느리므로 사용량이 많은 로그 디스크는 전체 시스템에서 병목 현상을 일으키는 핫스팟을 생성 할 수 있습니다.

데이터 쓰기

(업데이트 됨) 트랜잭션이 유효하고 커밋 될 수 있으려면 로그 쓰기를 디스크에 커밋해야합니다 (안정적인 미디어라고 함). 논리적으로 이것을 로그 항목으로 기록한 다음 비동기 프로세스에 의해 디스크에 데이터 페이지를 기록하는 지침으로 사용합니다. 실제로 디스크 페이지 쓰기는 실제로 로그 항목이 작성 될 때 준비되고 버퍼링되지만 트랜잭션을 커밋하기 위해 즉시 쓰여질 필요는 없습니다. 디스크 버퍼는 Lazy Writer 프로세스에 의해 안정적인 미디어 (디스크)에 기록됩니다 (이 점을 지적 해 준 Paul Randal에게 감사합니다). 이 Technet 기사 에서 좀 더 자세히 설명합니다.

이는 매우 임의적 인 액세스 패턴이므로 동일한 물리적 디스크를 로그와 공유하면 시스템 성능에 인위적인 병목 현상이 발생할 수 있습니다. 트랜잭션을 커밋하려면 로그 항목을 작성해야하므로 임의 검색을 수행하면이 프로세스 속도가 느려집니다 (임의 I / O가 순차 로그 I / O보다 훨씬 느림). 이로 인해 사용량이 많은 시스템에서 심각한 성능 병목 현상이 발생하므로 피해야합니다. 로그 영역과 임시 영역을 공유 할 때도 마찬가지입니다.

캐싱의 역할

SAN 컨트롤러는 RAM 캐시가 크므로 임의 액세스 트래픽을 어느 정도 흡수 할 수 있습니다. 그러나 트랜잭션 무결성을 위해서는 DBMS에서 디스크 쓰기를 완료해야합니다. 컨트롤러가 후기 입 캐싱을 사용하도록 설정되면 더티 블록이 캐시되고 I / O 호출이 호스트에 완료된 것으로보고됩니다.

캐시는 물리적 디스크로 나가는 많은 I / O를 흡수 할 수 있으므로 많은 경합 문제를 해결할 수 있습니다. 또한 RAID-5의 패리티 읽기 및 쓰기를 최적화하여 RAID-5 볼륨의 성능에 미치는 영향을 줄입니다.

이러한 관점은 다음과 같이 몇 가지 한계가 있음에도 불구하고 ‘SAN이 처리하도록’학교를 추진하는 특성입니다.

• 후기 입 캐싱에는 여전히 데이터가 손실 될 수있는 장애 모드가 있으며 컨트롤러는 실제로 블록이 디스크에 기록되지 않았다고 DBMS에 꽂습니다. 이러한 이유로, 데이터 무결성 문제가 비즈니스에 심각한 결과를 초래할 수있는 미션 크리티컬 또는 재무 데이터를 보유하는 트랜잭션 애플리케이션에 대해 후기 입 캐싱을 사용하지 않을 수 있습니다.

• SQL Server (특히)는 호출이 반환되기 전에 플래그 (FUA 또는 강제 업데이트 액세스)가 디스크에 물리적 쓰기를 강제하는 모드에서 I / O를 사용합니다. Microsoft에는 인증 프로그램이 있으며 많은 SAN 공급 업체에서 이러한 의미를 준수하는 하드웨어를 생산합니다 (요구 사항은 여기에 요약되어 있음 ). 이 경우 디스크 쓰기를 최적화 할 수있는 캐시 양이 없으므로 로그 트래픽 이 사용량이 많은 공유 볼륨에있을 경우 스래쉬됩니다.

• 응용 프로그램이 많은 디스크 트래픽을 생성하는 경우 작업 세트가 캐시를 초과하여 쓰기 경합 문제가 발생할 수 있습니다.

• SAN이 다른 응용 프로그램 (특히 동일한 디스크 볼륨)과 공유되는 경우 다른 응용 프로그램의 트래픽으로 인해 로그 병목 현상이 발생할 수 있습니다.

• 일부 응용 프로그램 (예 : 데이터웨어 하우스)은 일시적인 대량로드 스파이크를 생성하여 SAN에서 상당히 반 사회적으로 만듭니다.

대규모 SAN에서도 별도의 로그 볼륨을 권장합니다. 가볍게 사용하는 응용 프로그램의 레이아웃에 대해 걱정하지 않아도됩니다. 실제로 큰 응용 프로그램에서는 여러 SAN 컨트롤러를 활용할 수도 있습니다. 오라클은 대규모 구성 중 일부에 여러 컨트롤러가 포함 된 일련의 데이터웨어 하우스 레이아웃 사례 연구를 게시합니다.

성능에 대한 책임

볼륨이 크거나 성능이 문제가 될 수있는 곳에서는 SAN 팀이 응용 프로그램의 성능을 책임 져야합니다. 구성에 대한 권장 사항을 무시하려는 경우 관리 담당자가이를 인식하고 시스템 성능에 대한 책임이 적절한 위치에 있는지 확인하십시오. 특히, I / O 대기 또는 페이지 래치 대기 또는 허용 가능한 응용 프로그램 I / O SLA와 같은 주요 DB 성능 통계에 대한 허용 가능한 지침을 설정하십시오.

여러 팀에 걸쳐 성과 분할에 대한 책임이 있으면 지루한 동기 부여가되어 다른 팀에게 책임을 전가 할 수 있습니다. 이것은 알려진 관리 반 패턴이며 해결되지 않고 몇 달 또는 몇 년 동안 발생하는 문제에 대한 공식입니다. 이상적으로는 애플리케이션, 데이터베이스 및 SAN 구성 변경을 지정할 권한이있는 단일 설계자가 있어야합니다.

또한로드중인 시스템을 벤치마킹하십시오. 배열이 가능하다면, 중고 서버와 직접 연결 어레이를 Ebay에서 매우 싸게 구입할 수 있습니다. 하나 또는 두 개의 디스크 배열로 이와 같은 상자를 설정하면 물리 디스크 구성을 조작하여 성능에 미치는 영향을 측정 할 수 있습니다.

예를 들어, 대규모 SAN (IBM Shark)에서 실행되는 애플리케이션과 직접 연결 U320 어레이가있는 2 소켓 박스를 비교했습니다. 이 경우 ebay에서 구매 한 3,000 파운드의 하드웨어가 거의 동등한 CPU 및 메모리 구성을 가진 호스트에서 2 백만 배의 £ 1M 하이 엔드 SAN을 능가했습니다.

이 특정 사건에서, 이와 같은 것을 갖는 것이 SAN 관리자를 정직하게 유지하는 매우 좋은 방법이라고 주장 할 수 있습니다.

답변