커튼 뒤의 SAN에주의를 기울이지 마십시오

옛날 옛적에, 나는 내 자신의 SQL 서버를 구축하고 드라이브 구성, RAID 레벨 등을 제어했습니다. 데이터, 로그, tempdb, 백업 (예산에 따라) 분리에 대한 전통적인 조언은 항상 매우 중요한 부분이었습니다. SQL 서버 설계 프로세스

이제 엔터프라이즈 수준의 SAN에서는 데이터, 백업 및 파일 공유를위한 논리 드라이브로 나뉘어 새로운 SQL 서버에 대해 특정 양 의 드라이브 공간을 요청하기 만하면 됩니다. 확실히 내 일을 더 쉽게 만들어 주지만, 실제로는 커튼 뒤에서 실제로 무슨 일이 일어나고 있는지 알기 위해 "커튼 뒤"를 들여다 볼 수 없다는 완전히 편안하지 않은 부분이 있습니다.

SAN 팀은 다른 "유형"드라이브를 다르게 구성하지 않습니다 (랜덤 액세스를위한 데이터 드라이브와 스트리밍 쓰기를위한 로그 드라이브 최적화). 이 중 일부는 SAN 제품 자체 (HP XP12000 및 HP XP24000이 있음)에 따라 달라질 수 있지만 HP 소프트웨어는 모든 종류의 동적 성능 구성 (IO 핫스팟 관찰 및 즉시 재구성)을 수행합니다. 앱 팀과 DBA가 그에 대해 걱정할 필요가 없도록 LUN을 최적화하십시오). "대규모의 스핀들에 모든 서버의로드를 분산시키는 것"또는 이와 유사한 것.

내 질문 / 토론 :

1. SAN 팀에 적을 만들지 않고 저 자신과 응용 프로그램 개발자에게 SQL 서버가 제대로 구성되지 않은 스토리지로 고통받지 않는다는 것을 어떻게 확신시킬 수 있습니까? perfmon 통계 만 사용 하시겠습니까? sqlio와 같은 다른 벤치 마크?

2. 이 SAN 드라이브에로드 테스트를하면 실제로 시작했을 때 볼 수있는 것을 신뢰할 수 있고 반복 가능한 측정 방법으로 제공합니까? (SAN 소프트웨어가 다른 시점에서 다르게 "동적으로 구성"할 수 있다고 가정합니다.)

3. SAN의 한 부분 (예 : Exchange 서버)의 과도한 IO가 SQL 서버에 영향을 줍니까? (각 서버마다 전용 디스크를 제공하지 않는다고 가정하지만 그렇지 않다고 들었습니다)

4. 다른 기능을 위해 논리 드라이브 분리를 요청하면 논리 드라이브 (데이터 대 로그 대 tempdb)가 도움이 되겠습니까? 는 SAN은겠습니까 참조 다음에 다른 IO 활동을 최적 다르게 구성?

5. 우리는 지금 약간의 공간 위기에 처해 있습니다. 응용 프로그램 팀은 데이터 아카이브 등을 정리하라는 지시를받습니다. 공간 문제로 인해 SAN 팀이 서버 성능에 영향을 줄 수있는 내부 저장소 (RAID 수준 등)를 구성하는 방법에 대해 다른 결정을 내립니까?

귀하의 의견에 감사드립니다 ( 이 SF 질문에서 간략하게 논의 된 유사한 주제 )

SAN 팀에 적을 만들지 않으면 서 저 자신과 응용 프로그램 개발자에게 SQL 서버가 스토리지 구성이 잘못되어 있지 않다는 것을 어떻게 확신시킬 수 있습니까? perfmon 통계 만 사용 하시겠습니까? sqlio와 같은 다른 벤치 마크?

간단히 말해, 확실하게 확신 할 수있는 방법이 없을 것입니다. 내가 말하고자하는 것은 (SAN 관리자입니다.) 응용 프로그램이 예상대로 성능을 발휘하더라도 걱정하지 마십시오. SAN / Disk IO 성능과 관련이 있다고 생각되는 성능 문제가 나타나기 시작하면 문의하는 것이 좋습니다. 나는 당신처럼 HP 스토리지를 많이 사용하지 않지만 IBM / NetApp 세계에서는 경험을 통해 "불량"하게 구성 할 수있는 옵션이 많지 않다고 말할 수 있습니다. 오늘날 대부분의 엔터프라이즈 스토리지는 RAID 어레이를 구축 할 때 많은 추측을하므로 실제로 잘못하지는 않습니다. 동일한 RAID 그룹 내에서 드라이브 속도와 용량을 혼합하지 않는 한 대부분의 경우 디스크가 제대로 작동하는지 안심할 수 있습니다.

이 SAN 드라이브에로드 테스트를하면 실제로 시작했을 때 볼 수있는 것을 신뢰할 수 있고 반복 가능한 측정 방법으로 제공합니까? (SAN 소프트웨어가 다른 시점에서 다르게 "동적으로 구성"할 수 있다고 가정합니다.)

부하 테스트는 충분히 신뢰할 수 있어야합니다. 하나의 상자를로드 테스트 할 때 공유 SAN / 디스크 어레이에서 동일한 스토리지를 사용하는 다른 시스템의 성능에 영향을 줄 수 있다는 점을 명심하십시오.

SAN의 한 부분 (예 : Exchange 서버)의 과도한 IO가 SQL 서버에 영향을 줍니까? (각 서버마다 전용 디스크를 제공하지 않는다고 가정하지만 그렇지 않다고 들었습니다)

할 수 있습니다. 서버가있는 디스크 나 디스크에 관한 것은 아닙니다. 모든 데이터는 디스크 컨트롤러와 SAN 스위치를 통해 제공됩니다. 디스크 컨트롤러가 연결된 방식이 해당 디스크 선반 및 해당 SAN에 따라 크게 달라집니다. 전체 어레이가 하나의 단일 가닥의 4gbps 파이버에서 백본 SAN에 연결되면 성능에 분명히 영향을 미칩니다. 어레이가 트렁크 링크를 사용하여로드 밸런싱 된 두 개의 중복 SAN에 연결되어 있으면 교환만으로는 너무 많은 대역폭을 흡수 할 수 없습니다. 고려해야 할 또 다른 사항은 어레이가 얼마나 많은 IO / sec를 사용할 수 있는지입니다. 어레이와 어레이가 연결된 SAN이 올바르게 확장되면

다른 기능을 위해 논리 드라이브 분리를 요청하면 논리 드라이브 (데이터 대 로그 대 tempdb)가 도움이 되겠습니까? SAN에서 이들에 대한 다른 IO 활동을보고 최적으로 다르게 구성합니까?

이는 아마도 기본 설정의 문제 일뿐 아니라 스토리지 관리자가 구성하는 방법에 따라 크게 달라집니다. 동일한 어레이 또는 볼륨에 3 개의 LUN을 제공 할 수 있으며,이 경우 어쨌든 모두 동일합니다. 이들이 다른 어레이, 다른 볼륨 (물리적으로 다른 디스크)의 개별 LUN을 제공 한 경우이를 분리하는 것이 좋습니다.

우리는 지금 약간의 공간 위기에 처해 있습니다. 응용 프로그램 팀은 데이터 아카이브 등을 정리하라는 지시를받습니다. 공간 문제로 인해 SAN 팀이 서버 성능에 영향을 줄 수있는 내부 저장소 (RAID 수준 등)를 구성하는 방법에 대해 다른 결정을 내립니까?

스토리지 관리자가 공간을 확보하기 위해 레이드 레벨을 변경한다고 생각하지 않습니다. 그가 원한다면 아마도 해고 당했을 것입니다. 공간 문제로 인해 구성이 다르게 구성 될 수 있지만 일반적으로 성능에 영향을주지는 않습니다. 그들은 당신에게 얼마나 많은 공간을 주 었는지에 대해 조금 더 타이트해질 수 있습니다. 데이터 중복 제거 (어레이가 지원하는 경우)와 같은 기능을 활성화하여 프로세스가 실행되는 동안 어레이의 성능을 방해 할 수 있지만 24 시간 내내 사용할 수는 없습니다.

SAN 팀에는 앱이 핫스팟인지 여부를 알 수있는 도구가 있어야합니다. 분명히, 당신은 또한 당신의 끝을 모니터링하고 측정해야합니다.

내 경험의 대부분은 EMC와 YMMV에 관한 것입니다. 그러나 다음은 대부분의 SAN 장비에 적용됩니다.

어레이에 들어가는 포트는 너무 많습니다. 때로는 영역을 정의 할 수있는 SAN 스위치가 있습니다. 어레이가 본질적으로 큰 스토리지 풀이라고해서 IO 성능에 대해 걱정할 필요는 없습니다.

따라서 IO 문제가 있다고 생각되면 병목 현상의 위치를 ​​좁혀 야합니다. HBA와 어레이 사이에있는 경우 HBA가 최대인지 또는 스위치 / 배열 측의 SAN 포트가 과다 가입되었는지 알아낼 수 있습니다. 또한 SAN 팀이 콜드 스타트 ​​및 핫 스타트 모두에서 앱의 액세스 패턴을 모니터하도록해야합니다.

분명히, 기본 스토리지는 다른 캐시 레벨에 관계없이 어느 시점에서 디스크에 충돌해야하기 때문에 느린 대형 RAID5와 빠른 RAID10을 실행하는 것과 차이가 있습니다.

HTH. 발굴하는 데 시간이 걸릴 수있는 특정 문제가있는 경우 오프라인으로 핑 (ping) 할 수 있습니다.

SAN 팀에 적을 만들지 않으면 서 저 자신과 응용 프로그램 개발자에게 SQL 서버가 스토리지 구성이 잘못되어 있지 않다는 것을 어떻게 확신시킬 수 있습니까? perfmon 통계 만 사용 하시겠습니까? sqlio와 같은 다른 벤치 마크?

어떤 종류의 벤치마킹을 수행하기 전에 알아야 할 첫 번째 사항은 자체 워크로드를 실행해야하는 허용 오차에 대한 것입니다. 따라서 새 시스템을 확인하기 전에 자신의 작업을 벤치마킹하십시오. 이렇게하면 최대로드 (백업?) 중에 최대 56MB / s를 푸시하고있는 경우 SAN 연결 디스크 어레이가 '최대'시뮬레이트 된 최대로드에서 110MB / s를 푸시한다는 것을 알 수 있습니다. 한계가 I / O 채널이되지 않도록 보장했습니다.

새 디스크 어레이를 체크 아웃 할 때 이런 종류의 성능 테스트를 수행했습니다. 새로운 어레이는 파이버 채널 (SCSI) 드라이브 대신 SATA 드라이브를 사용했으며, 환경에서 제대로 작동하는지 확인해야했습니다. 나는 매우 모호했다. 그러나 특성화 후, 새로운 시스템은 피크보다 더 안정적인 I / O 오버 헤드가있어보다 안정적인 디스크에서 측정 된 피크를 유지할 수 있음을 알게되었습니다. 놀랐어요

이 SAN 드라이브에로드 테스트를하면 실제로 시작했을 때 볼 수있는 것을 신뢰할 수 있고 반복 가능한 측정 방법으로 제공합니까? (SAN 소프트웨어가 다른 시점에서 다르게 "동적으로 구성"할 수 있다고 가정합니다.)

SAN 접속 디스크 어레이의 공유 특성으로 인해 일주일 내내 성능이 변합니다. 피크 I / O로드가 언제인지 이미 알고있는 경우, 피크 I / O로드가있는 시간 동안 일련의로드 테스트를 수행하십시오. 그렇게하면 가장 관심있는 기간 동안 어떤 종류의 I / O 오버 헤드를 사용할 수 있는지 더 잘 특성화 할 수 있습니다. 피크가 아닌 시간 동안의로드 테스트는 '빠른'상황에 대한 느낌을 주지만 피크 테스트는 당신에게 진정한 경계 검사를 제공합니다.

SAN의 한 부분 (예 : Exchange 서버)의 과도한 IO가 SQL 서버에 영향을 줍니까? (각 서버마다 전용 디스크를 제공하지 않는다고 가정하지만 그렇지 않다고 들었습니다)

Exchange LUN이 디스크를 SQL LUN과 공유하는 경우 절대적으로 해당됩니다. 우리는 XP가 아닌 HP EVA를 사용하지만 동일한 "디스크 그룹"용어를 사용한다고 생각합니다. 동일한 디스크 그룹의 LUN은 디스크를 공유하므로 물리적 장치의 I / O에 대해 경쟁합니다. 디스크 그룹에 디스크를 많이 넣을수록 어레이가 I / O를 저글링해야하는 더 많은 공간이 필요합니다. 어레이는 (적어도 EVA는 그렇게하고 더 비싼 XP는 동일한 것으로 가정합니다) 논리적 LUN 블록을 물리적 디스크에 비 순차 방식으로 분배합니다. 이를 통해 제안 된 작업을 수행 할 수 있습니다. 자주 액세스하는 블록 그룹을 다른 물리적 장치에 동적으로 분산하여 디스크 수준에서 병렬 처리를 늘리고 I / O 경합을 줄입니다.

물어볼 질문은 디스크 그룹의 I / O 예산이 얼마인지, 그리고 해당 LUN을 사용하는 응용 프로그램이 I / O에 대해 초과 가입되었는지 여부입니다. 이는 스토리지 관리자가 추적해야 할 질문입니다. Exchange의 최대 I / O (아마도 백업 중)가 SQL로드와 일치하지 않을 수 있으며 두 시스템이 모두 공존 할 수 있습니다.

다른 기능을 위해 논리 드라이브 분리를 요청하면 논리 드라이브 (데이터 대 로그 대 tempdb)가 도움이 되겠습니까? SAN에서 이들에 대한 다른 IO 활동을보고 최적으로 다르게 구성합니까?

HP 어레이의 경우 서로 다른 I / O 패턴을 LUN이 아닌 다른 디스크 그룹 에 넣어야합니다 . 예를 들어, 데이터베이스 I / O 패턴은 웹 서비스 액세스 패턴과 공존해서는 안됩니다. 다른 LUN이 다른 디스크 그룹에 있지 않으면 성능이 크게 향상되지 않습니다. 이들이 동일한 디스크 그룹에 있다면 운영 체제에서 유일한 장점은 디스크 서브 시스템에 대한 병렬성을 향상시키기 위해 커널에서 I / O 스케줄링을 수행 할 수 있다는 것입니다. 그건 ...

어쨌든 HP 어레이는 LUN의 다양한 액세스 패턴을 알고 있지만 실제 논리 블록에 세심한주의를 기울입니다. 로그를 다른 LUN에 배치하면 이러한 종류의 I / O 트래픽을 얻을 수있는 논리 블록에 바운드가 적용되므로 물리 디스크에서 논리 블록을 올바르게 정렬하는 작업이 쉬워집니다.

우리는 지금 약간의 공간 위기에 처해 있습니다. 응용 프로그램 팀은 데이터 아카이브 등을 정리하라는 지시를받습니다. 공간 문제로 인해 SAN 팀이 서버 성능에 영향을 줄 수있는 내부 저장소 (RAID 수준 등)를 구성하는 방법에 대해 다른 결정을 내립니까?

명확히. 공간이 부족하면 I / O 전용 디스크 그룹을 얻지 못할 것입니다 (스토리지 환경이 독점적으로 사용할 수있는 7TB의 물리 디스크를 정당화 할만큼 충분히 큰 경우가 아니라면) ). Raid5 / Raid10 토론은 대부분 조직의 정책에 따라 결정되며 요청하는 것이 최선의 방법입니다.

문제를 해결하기 위해 SAN 팀 및 공급 업체와 대화 상자를 여는 것이 좋습니다. 자체 벤치 마크를 실행할 때 발생할 수있는 문제 중 하나는 테스트에서 생산, 특히 최대 부하시 발생하는 결과와 관련이 없을 수 있다는 것입니다. 대부분의 SAN에는 많은 양의 배터리 백업 캐시가 있습니다. 이는 많은 경우 (특히 합성 벤치 마크를 실행할 때) RAM에 쓰고 킥 아웃 성능을 얻는 것을 의미합니다.

환경과 사용중인 솔루션에 따라 일부 공급 업체 CE는 SAN에 유입되어 원하는 표준으로 SAN을 설정했을 수 있습니다. 그것은 당신이 생각하는 것보다 더 많이 발생합니다. 솔루션이 요구 사항을 충족한다고 확신 할 때까지 "SAN 팀은 모든 것을 알고 있습니다"셸에서 칩을 제거해야합니다.

행운을 빕니다.

데이터베이스에 대한 SAN SAN이라는 주제에 대해 이야기하면서 오라클 회의에 한 번있었습니다.

강연의 요지는 이 PDF 파일 또는 저자 사이트 에서 볼 수 있습니다