답변:
로그와 데이터 드라이브에는 드라이브를 공유 할 때 서로 (적어도 이론적으로는) 충돌하는 서로 다른 데이터 액세스 패턴이 있습니다.
로그 쓰기
로그 액세스는 매우 많은 수의 작은 순차적 쓰기로 구성됩니다. 간단히 말해서 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 관리자를 정직하게 유지하는 매우 좋은 방법이라고 주장 할 수 있습니다.
Equallogic 태그와 요청의 내용은 Equallogic SAN에 대해 이야기하고 있다고 가정합니다. 다음은 특히 Equallogic에 대한 것이며 다른 SAN 유형에는 적용되지 않습니다.
Equallogic 스토리지를 사용하면 EMC Clariion 스토리지와 같이 볼륨에 사용되는 특정 디스크를 정확하게 지정할 수 없으므로 접근 방식이 약간 달라야합니다.
평등 아키텍처는 매우 자동화되고 역동적입니다. 기본 빌딩 블록은 다른 SAN에서 볼 수 있듯이 어레이 내의 RAID 팩 / 그룹이 아닌 어레이 장치입니다. 각 어레이는 RAID 5, 6, 10 또는 50에 대해 완전히 구성되어 있지만 이는 어레이 당 하나의 RAID 그룹 만 존재한다는 것을 의미하지는 않으며 해당 수준에서 RAID 그룹을 결정하거나 상호 작용할 수 없습니다. 스토리지 풀에 스토리지를 배치하면 풀이 스토리지 그룹에 속합니다. 스토리지 그룹에는 해당 그룹 내의 모든 볼륨에 대한 iSCSI 검색 대상으로 사용하는 클러스터 / 가상 IP 주소가 있습니다. EQL 그룹 관리 소프트웨어 및 호스트 MPIO 스택은 실제로 가장 적합한 포트로 라우팅하는 데 필요한 IP 레벨 재 지정을 처리합니다. 데이터 블록을 요청할 때 개별 배열이지만 제어 할 수있는 능력이 거의 없습니다.
스토리지 볼륨은 각 풀의 총 여유 공간에서 할당됩니다. 풀 내의 모든 볼륨은 해당 풀의 모든 어레이에 분산되어 (최대 4 개의 개별 어레이까지) 총 네트워크 인터페이스 수 (모델에 따라 Eql 어레이 당 2-4) 및 IO에 네트워크 IO를 분산시킵니다. 가능한 많은 컨트롤러에서 Equallogic 관리 소프트웨어는 시간이 지남에 따라 볼륨 / 배열 성능을 모니터링하고 구성원 어레이 전체의 블록 분포를 동적으로 최적화합니다. 일반적으로 수행중인 작업을 모르는 경우 모든 어레이를 단일 풀에 배치하고 RAID 10으로 고속 디스크 (SAS 10k \ 15k)를 구성하고 RAID 50으로 중간 속도를 구성해야합니다. 또는 최적화 프로세스가 실제로 실제 고성능 드라이브를 선택하도록하기 위해 5입니다.
대략적인 근사치로, 드라이브 유형과 RAID 유형에 따라 PS 어레이 당 2500-5000 IOP 사이에있을 수 있습니다. 충분한 총 IOP를 제공하는 경우 자동화 된 관리 프로세스는 모든 볼륨을 단일 풀로 묶어도 결국 우수한 성능을 제공해야합니다.
그러나 로그, 데이터베이스, 임시 저장소, OS 드라이브 등이 실제로 서로 분리되어 있는지 확인하려면 몇 가지 작업을 수행 할 수 있습니다. 먼저 특정 볼륨이 해당 RAID 유형의 어레이에만 저장되도록 볼륨에 대한 RAID 기본 설정을 정의 할 수 있습니다 (볼륨에 속한 경우). 둘째, 특정 계층에 필요한 다양한 등급의 성능을 제공하고 볼륨을 적절한 풀에 분배하는 어레이 만 포함하는 계층 형 스토리지 풀을 정의 할 수 있습니다. 이 접근법과 함께 제공되는 건강 경고는 일반적으로 더 나은 전반적인 성능을 제공하기 위해 일반적으로 많은 배열이 필요하다는 것입니다. 이는 여전히 중요한 볼륨의 성능을 보장하는 것보다 덜 중요 할 수 있습니다. 선택. Oracle DB에 대한 Dell의 참조 아키텍처는 데이터, 투표 디스크 및 OCR에 2 개의 RAID 10 어레이가있는 하나의 풀과 Flash Recovery Area에 대해 단일 RAID 5 어레이가있는 별도의 풀을 사용합니다.
Equallogic을 사용하는 모든 시점에서 강제 파티셔닝과 관련한 의사 결정이 사용 가능한 네트워크 인터페이스, 디스크 스핀들 및 컨트롤러 측면에서 볼륨에 더 나은 집계 성능을 제공 할 것인지 스스로에게 문의해야합니다. 대답 할 수없는 경우 최소 풀 수를 선택하고 세부 정보를 처리하거나 Equallogic 전문가가 실제 디자인을 수행하도록하십시오. 하나의 어레이 만있는 경우 볼륨 분리 측면에서 수행 할 수있는 작업이 없습니다.
좋은 질문입니다!
먼저이 문제에 대한 Brent Ozar의 "Steel Cage BlogMatch" 토론을 살펴보십시오 .
회사에서는 대부분의 서버에서 데이터 및 로그를 동일한 SAN 드라이브에 배치하고 SAN 팀에 맡겨 모든 것이 올바르게 작동하는지 확인합니다.
이것이 최선의 전략이 아니라고 생각합니다. 특히 대용량 서버에 적합합니다. 근본적인 문제는 SAN 팀이 필요한 공간을 위해 충분한 드라이브를 함께 때리는 것 이상을 실제로 수행하고 있는지 확인할 방법이 없다는 것입니다. 우리는 SAN 드라이브에 대해 IO 벤치 마크를 실행하지 않으며, 단지 "일을 수행하고"(성능과 공간을 조정하는) 것으로 가정합니다.
내 다른 생각은 데이터와 로그에 필요한 액세스 종류 가 다르다는 것입니다. 나는 최근에 읽은 기사를 찾아 두 가지 다른 드라이브 유형이 실제로 매우 다른 방식으로 어떻게 최적화되어야하는지에 대해 이야기하려고합니다 (하나는 순차적 쓰기에 대한 최적화가 필요하고 다른 하나는 임의 읽기에 대한 최적화가 필요하다고 생각합니다. .)
즉, SQL Server 데이터 파일, 로그 파일 및 TempDB 데이터 및 로그 파일을위한 별도의 볼륨을 만들 수 있습니다.
질문에 Equallogic으로 태그를 지정 했으므로 솔루션을 디자인하기 전에 무료 Dell 참조 아키텍처 안내서 : Dell ™ EqualLogic ™ PS5000 시리즈 스토리지 어레이를 사용하여 Microsoft® SQL Server® 배포 (등록 필요) 를 읽으 십시오. 종종 당신은 찾을 수 있습니다 특정 구성에 대한 지침은 일반적인 조언 크게 다를 수 있습니다 .
성능 측면에서 BradC (+1)에 동의합니다. 일반적으로 좋은 SAN에는 예상보다 많은 원시 I / O가 있습니다.
BACKUP을 라이브 시스템에서 분리하는 것이 좋습니다.
또한 tempdb를 로그 파일에서 멀리 두는 것이 좋습니다. SAN 사용자의 텐트는 로그, 데이터 및 온도에 대해 "다른 버킷"(기술 용어)을 원할 때 시선을 끌지 만,이를 알려 주면 각 영역으로 이동하는 각기 다른 양의 데이터 IO를 측정 할 수 있습니다. 멋진 성능 그래프를 보여줄 수 있습니다!
SAN 담당자가 제대로 설정했는지 확인하십시오. RAID 10을 원한다면 RAID 5에 성능 저하가 없다고 주장하더라도 계속 주장합니다.
( "파일 기반"작업의 경우 RAID 5가 좋습니다. 집중 쓰기의 경우 쓰기 버퍼를 채우는 즉시 나사로 고정됩니다!)
여기에서도 모든 용어의 혼합에주의하십시오.
일반적으로 매우 기본적입니다.
동일한 어레이에 여러 볼륨을 가질 수 있으며,이 스레드에서 논의 된 고급 최적화를 수행 할 때 기억해야합니다.
핵심은 다른 사람들이 언급 한 것인데, 잊지 말고 별도의 볼륨이 아닌 다른 드라이브 스핀들에서 데이터 / 로그 / 백업을 분리하십시오.
편집 : 위의 Helvick은 Equallogic SAN에 대한 훌륭한 답변을 제공했습니다!