it-swarm-ko.tech

ISCSI의 SQL Server 디스크 설계 SAN

로그 및 데이터 파일을 OS에서 분리 된 디스크로 분리하는 표준 관행 (tempdb, 백업 및 스왑 파일도) 드라이브가 모두 SAN 기반이고 LUNS) 일 때이 논리가 여전히 의미가 있습니까? 특정 디스크 또는 RAID 세트로 조각되지 않음-SAN)에있는 드라이브 x 개의 일부일 뿐이며 LUN은 공간 할당 일뿐입니다.

27
CPU_BUSY

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

로그 쓰기

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

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

데이터 쓰기

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

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

캐싱의 역할

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

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

다음은 'SAN이 생각하는 학교'를 이끄는 특성입니다.이 관점에는 몇 가지 제한이 있습니다.

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

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

  • 응용 프로그램이 많은 디스크 트래픽을 생성하는 경우 작업 집합이 캐시를 오버런하여 쓰기 경합 문제를 일으킬 수 있습니다.

  • SAN이 다른 애플리케이션 (특히 동일한 디스크 볼륨에서)과 공유되는 경우 다른 애플리케이션의 트래픽이 로그 병목 현상을 생성 할 수 있습니다.

  • 일부 애플리케이션 (예 : 데이터웨어 하우스)은 일시적인로드 스파이크를 크게 생성하여 SAN에서 반사회적이지 않게 만듭니다.

큰 SAN의 경우에도 별도의 로그 볼륨이 여전히 권장되는 방법입니다. 가볍게 사용하는 응용 프로그램의 레이아웃에 대해 걱정하지 않고 벗어날 수 있습니다. 정말 큰 응용 프로그램에서는 여러 SAN 컨트롤러의 이점을 얻을 수도 있습니다. 오라클은 일부 대규모 구성에 여러 컨트롤러가 포함 된 일련의 데이터웨어 하우스 레이아웃 사례 연구를 발표합니다.

소속 된 성능에 대한 책임감

볼륨이 크거나 성능이 문제가 될 수있는 경우 SAN 팀이 애플리케이션 성능에 대해 책임을지게하십시오. 구성에 대한 권장 사항을 무시할 경우 관리자가이를 인식하고 시스템 성능에 대한 책임이 적절한 위치에 있는지 확인하십시오. 특히 I/O 대기, 페이지 래치 대기 또는 수용 가능한 애플리케이션 I/O SLA와 같은 주요 DB 성능 통계에 대한 수용 가능한 지침을 설정합니다.

성과에 대한 책임을 여러 팀으로 나누면 손가락을 가리키고 다른 팀에 돈을 전달하는 인센티브가 생성됩니다. 이것은 알려진 관리 안티 패턴이며 해결되지 않은 채 몇 달 또는 몇 년 동안 지속되는 문제에 대한 공식입니다. 이상적으로는 애플리케이션, 데이터베이스 및 SAN 구성 변경을 지정할 수있는 권한이있는 단일 설계자가 있어야합니다.

또한 부하가 걸린 시스템을 벤치마킹하십시오. 당신이 그것을 배열 할 수 있다면, 중고 서버와 직접 연결 배열은 Ebay에서 상당히 싸게 구입할 수 있습니다. 하나 또는 두 개의 디스크 어레이로 이와 같은 상자를 설정하면 물리적 디스크 구성을 사용하여 성능에 미치는 영향을 측정 할 수 있습니다.

예를 들어, 큰 SAN (IBM Shark)에서 실행되는 애플리케이션과 직접 연결 U320 어레이가있는 2 소켓 상자를 비교했습니다. 이 경우, eBay에서 구입 한 £ 3,000 상당의 하드웨어는 CPU 및 메모리 구성이 거의 동일한 호스트에서 £ 1M 하이 엔드 SAN보다 2 배 높은 성능을 보였습니다.

이 특별한 사건에서 이와 같은 물건을 눕히는 것이 SAN 관리자를 정직하게 유지하는 아주 좋은 방법이라고 주장 할 수 있습니다.

Equallogic 태그와 요청 내용이 Equallogic SAN에 대해 생각하고 있음을 의미한다고 가정합니다. 다음은 Equallogic에 대한 내용이며 다른 SAN 유형에는 적용되지 않습니다.

Equallogic 어레이에서는 볼륨에 사용되는 특정 디스크를 EMC Clariion 어레이와 같이 정확하게 지정할 수 없으므로 접근 방식이 약간 달라야합니다.

Equallogic 아키텍처는 매우 자동화되고 동적입니다. 기본 빌딩 블록은 다른 SAN에서 볼 수 있듯이 어레이 내의 RAID 팩\그룹이 아닌 어레이 단위입니다. 각 어레이는 RAID 5, 6, 10 또는 50에 대해 완전히 구성되지만 이는 어레이 당 하나의 RAID 그룹 만 있음을 의미하지는 않으며 해당 레벨에서 결정하거나 상호 작용할 수 없습니다. 스토리지 풀에 어레이를 배치하면 풀이 스토리지 그룹에 속합니다. 스토리지 그룹에는 해당 그룹 내의 모든 볼륨에 대한 iSCSI 검색 대상으로 사용하는 클러스터\가상 IP 주소가 있습니다. EQL 그룹 관리 소프트웨어 및 호스트 MPIO 스택은 실제로 가장 적절한 포트로 라우팅하는 데 필요한 IP 수준 재 지정을 처리합니다. 데이터 블록을 요청할 때 개별 배열을 사용하지만 제어 할 수있는 능력이 거의 또는 전혀 없습니다.

스토리지 볼륨은 각 풀의 총 여유 공간에서 할당됩니다. 전체 네트워크 인터페이스 수 (2-4 개)에 네트워크 IO)를 배포하기 위해 풀 내의 모든 볼륨이 해당 풀의 모든 어레이 (최대 4 개의 개별 어레이까지)에 분산됩니다. Eql 어레이는 모델에 따라 다름) 및 IO 가능한 한 많은 컨트롤러에 걸쳐 있습니다. Equallogic 관리 소프트웨어는 시간에 따라 볼륨/어레이 성능을 모니터링하고 멤버 어레이 전체에 걸쳐 블록 분포를 동적으로 최적화합니다. 수행중인 작업을 알지 못하는 경우 모든 어레이를 단일 풀에 배치하고 작업을 수행하도록해야합니다. 고속 디스크 (SAS 10k\15k)를 RAID 10, 중간 속도는 RAID 50 또는 5로 구성해야합니다. 최적화 프로세스가 실제로 실제 고성능 드라이브를 선택하는지 확인하기 위해 실제로 최적 상태에 도달하는 데는 며칠 (7+)이 소요될 수 있지만 일반적으로 볼륨을 즉시 배포하므로 균형 잡힌 배포에 매우 빠르게 도달해야합니다. 가능한 한 많은 배열 (다시 t o 4) 초기 생성 시점.

대략적으로 말하자면 드라이브 유형 및 RAID 유형에 따라 PS 어레이 당 2500-5000 IOP 사이에있을 것입니다. 충분한 총 IOP를 제공하면 모든 볼륨을 단일 풀로 묶는 경우에도 자동화 된 관리 프로세스가 결국 좋은 성능을 제공합니다.

그러나 로그, 데이터베이스, 임시 저장소, OS 드라이브 등이 실제로 서로 격리되어 있는지 확인하려면 몇 가지 작업을 수행 할 수 있습니다. 먼저 특정 볼륨이 항상 해당 RAID 유형의 어레이에만 저장되도록 볼륨에 대한 RAID 기본 설정을 정의 할 수 있습니다 (볼륨이 속한 풀에있는 경우). 두 번째로 특정 계층에 필요한 다양한 등급의 성능을 제공하는 어레이 만 포함하는 계층 형 스토리지 풀을 정의한 다음 볼륨을 적절한 풀에 배포 할 수 있습니다. 이 접근 방식과 함께 제공되는 상태 경고는 실제로 더 나은 전체 성능을 제공하기 위해 일반적으로 많은 어레이가 필요하다는 것입니다. 이는 중요한 볼륨의 성능을 보장하는 것보다 덜 중요 할 수 있으므로 여전히 최고입니다. 선택. Oracle DB에 대한 Dell의 참조 아키텍처는 데이터, 투표 디스크 및 OCR에 대해 2 개의 RAID 10 어레이가있는 하나의 풀과 플래시 복구 영역을위한 단일 RAID 5 어레이가있는 별도의 풀을 사용합니다.

Equallogic을 사용하는 모든 시점에서 강제 파티셔닝과 관련하여 내리는 결정이 사용 가능한 네트워크 인터페이스, 디스크 스핀들 및 컨트롤러 측면에서 볼륨에 대해 더 나은 집계 성능을 제공 할 것인지 자문해야합니다. 대답 할 수없는 경우 최소 풀 수를 선택하고 세부 사항을 처리하도록 두거나 Equallogic 전문가에게 실제 설계를 요청하십시오. 어레이가 하나만있는 경우 볼륨 분리와 관련하여 수행 할 수있는 작업이 없습니다.

9
Helvick

우리는 DB를 단일 SAN 상자에 저장하지만 각기 다른 디스크 그룹에 속도별로 계층화 된 별도의 데이터, 로그 및 백업 LUN을 사용합니다. 로그는 RAID 10 15Krpm LUN에, 데이터는 RAID에 저장합니다. 1 10/15krpm LUN 및 RAID 5 7.2krpm LUN에 백업 또한 동일한 SAN의 다른 컨트롤러를 통해 로그와 데이터를 제공합니다.

5
Chopper3

좋은 질문입니다!

먼저이 문제에 대한 Brent Ozar의 "Steel Cage BlogMatch" 토론을 살펴보십시오.

우리 회사에서는 대부분의 서버에서 데이터와 로그를 동일한 SAN 드라이브에 저장하고 모든 것이 제대로 작동하는지 확인하기 위해 SAN 팀에 맡깁니다.

특히 대용량 서버의 경우 이것이 최선의 전략이 아니라고 생각하기 시작했습니다. 근본적인 문제는 SAN 팀이 필요한 공간에 충분한 드라이브를 함께 두드리는 것 이상을 실제로 수행하고 있는지 확인할 방법이 없다는 것입니다. 우리는 IO 벤치 마크를 우리 쪽 또는 그 어떤 것에서든 SAN 드라이브에 대해 실행하지 않습니다. 우리는 단지 그들이 "작업을 수행"하고 있다고 가정합니다 (성능 및 공간 조정 ), 아마도 약간 순진합니다.

내 다른 생각은 데이터와 로그에 필요한 액세스의 종류 가 다르다는 것입니다. 저는 최근에 읽은 두 가지 드라이브 유형이 실제로 매우 다른 방식으로 어떻게 최적화되어야하는지에 대한 기사를 찾아 보겠습니다 (순차 쓰기를위한 최적화가 필요하고 다른 하나는 임의 읽기를위한 최적화가 필요하다고 생각합니다. .)

4
BradC

즉, SQL Server 데이터 파일, 로그 파일, TempDB 데이터 및 로그 파일에 대해 별도의 볼륨을 만들 수 있습니다.

Equallogic으로 질문에 태그를 지정 했으므로 솔루션을 설계하기 전에 무료 Dell 참조 아키텍처 가이드 : Dell ™ EqualLogic ™ PS5000 시리즈 스토리지 어레이와 함께 Microsoft® SQL Server® 배포 (등록 필요)를 읽어보십시오. 종종 특정 구성에 대한 지침 은 일반적인 지침 과 크게 다를 수 있습니다.

4
Peter Stuer

성능 측면에서 BradC (+1)에 동의합니다. 일반적으로 좋은 SAN는 예상보다 더 많은 원시 I/O를 갖습니다.

라이브 시스템에서 백업을 분리하는 것은 여전히 ​​좋은 생각입니다.

또한 tempdb를 로그 파일에서 멀리 두는 것이 좋습니다. SAN 로그, 데이터 및 온도에 대해 "다른 버킷"(기술 용어)을 원할 때 눈을 뗄 수없는 남자 텐트이지만, 말해 주면 다른 것을 측정 할 수 있습니다. 데이터의 양 IO 각 영역으로 이동하여 멋진 성능 그래프를 보여줍니다!

SAN 사람이 당신을 위해 그것을 설정했는지 두 번/두 번 확인하십시오. RAID 10을 원한다면 RAID 5가 성능이 없다고 계속 말하더라도 그것을 주장하십시오 (저는)) 패널티.

( "파일 기반"작업의 경우 RAID 5가 좋습니다. 집중적 인 쓰기의 경우 쓰기 버퍼를 채우 자마자 나사로 조입니다!)

3
Guy

여기서도 모든 용어의 혼합에 유의하십시오.

일반적으로 매우 기본적인 사항 :

  • 어레이 = RAID 설정의 디스크 풀 (예 : RAID5)
  • 볼륨 = LUN이있는 SAN에서 호스트에 제공되는 어레이의 일부)

동일한 어레이에 여러 볼륨을 가질 수 있습니다.이 스레드에서 논의한 고급 최적화를 수행 할 때 기억해야 할 사항입니다.

핵심은 여러 다른 사람들이 언급 한 것입니다 (잊지 마세요). 별도의 볼륨이 아닌 다른 드라이브 스핀들에서 데이터/로그/백업을 분리합니다.

편집 : 위의 Helvick은 Equallogic SAN에 대한-훌륭한 답변을 제공했습니다!

2
pauska