SQL Server 파일 로컬 또는 NAS 또는 SAN?

SQL Server 2008과 함께 새 서버를 설치해야합니다. Raid 10이 포함 된 하나의 서버 또는 NAS의 파일은 무엇입니까?

iSCSI는 어떻게 사용해야합니까?

SAN은 어떻습니까?

서버에는 4Gb의 RAM이 있으며 해당 데이터베이스 파일은 약 2GB입니다.

오늘날 서버에 RAID가 없다는 것을 분명히하기 위해 어떤 종류의 전략을 구현해야하므로 어떤 일이 발생하면 파일을 안전하게 유지할 수 있습니다. 로컬 파일, NAS, SAN을 어떻게 선택해야합니까? 어떤 옵션이 가장 성능이 좋으며 더 안전한가요?

NAS

SQL Server 용 NAS가 아닙니다. SMB / CIFS는 DBMS를 지원하기 위해 파일 잠금을 적절히 지원하지 않습니다 (적어도 몇 년 전에는 2002 년부터 2003 년까지는 없었습니다). NFS 는 NFS 서버에서 Oracle을 사용하여 실제로이를 수행 할 수 있습니다. 그러나 프로토콜 제한으로 인해 CIFS 공유의 SQL Server는 신뢰할 수 없습니다. CIFS 마운트 공유에 파일을 넣지 못할 수도 있습니다.

SAN

이는 RAID 컨트롤러의 캐시가 상당히 큰 작업 세트를 흡수 할 수 있기 때문에 트랜잭션 애플리케이션에 좋습니다. SAN RAID 컨트롤러는 일반적으로 호스트 기반 RAID 컨트롤러보다 더 많은 캐시를 지원합니다. 특히 RAID 컨트롤러가 서버만큼 강력한 멀티 프로세서 박스 일 수있는 고급 키트에서.

이중 컨트롤러가있는 SAN에는 단일 장애 지점이없는 아키텍처가 있으며 핫 백업을위한 많은 옵션을 제공합니다. 따라서 관리 효율성 및 안정성 측면에서 유리합니다. 그러나 데이터 볼륨 스트리밍에는 비용이 많이 들고 제한적이지만 후자는 트랜잭션 시스템에서 문제가되지는 않습니다.

운영 체제의 경우 SAN은 사용 가능한 경우 거의 항상 최선의 선택입니다. 또한 중간 규모 볼륨 시스템을 실행하는 여러 서버간에 공유 할 수 있습니다. 그러나 가격표가 제공되어 기술과 함께 사용할 수있는 가장 작은 시스템에는 상당한 한계가 있습니다.

직접 연결

경우에 따라 직접 연결 스토리지가 가장 좋습니다. 한 가지 가능성은 제한된 대역폭의 스트리밍 애플리케이션으로, 제한된 수의 파이버 채널 연결이 사용 가능한 대역폭을 고급 SAS 컨트롤러에서 가능한 것보다 적게 제한합니다. 그러나 이들은 무 공유 아키텍처가 최상의 처리량을 제공 할 수있는 초대형 데이터웨어 하우스와 같이 상당히 전문화 된 응용 프로그램 일 가능성이 높습니다 .

실제로 다음과 같은 여러 가지 이유로 데이터웨어 하우스 시스템의 경우 SAN보다 직접 연결 스토리지가 더 좋습니다.

• 데이터웨어 하우스는 디스크 하위 시스템에 일시적인 일시적인로드 스파이크를 발생시킵니다. 이는 SAN에서 다른 시스템의 성능에 영향을 줄 수 있으므로 SAN에서 상당히 반 사회적입니다.

• 위에서 언급 한 스트리밍 병목 현상.

• 직접 연결 스토리지는 SAN 스토리지보다 훨씬 저렴합니다.

직접 연결 스토리지의 또 다른 시장은 SAN에 충분한 비용을 지불하지 않는 시장에 판매 할 때입니다. 이는 종종 중소기업 고객에게 판매 된 응용 프로그램에 해당됩니다. 6 명의 사용자가있는 POS 시스템 또는 실무 관리 시스템의 경우 SAN이 과도 할 수 있습니다. 이러한 유형의 상황에서 일부 내부 디스크가있는 소규모 독립형 타워 서버가 훨씬 더 적합한 솔루션입니다.

로컬 또는 SAN은 성능을 유지하는 유일한 방법입니다. 쓰기 캐시 및 병렬 디스크 처리량 구성이 더 커서 SAN이 로컬 디스크보다 빠를 수 있습니다.

Windows 공유에서 고성능 파일 I / O를 수행하지 마십시오. 처리량을 획기적으로 낮추는 많은 양의 프로토콜 오버 헤드가 있습니다. 예를 들어, 몇 년 전에 WAN을 통한 대용량 파일 전송이 Windows over FTP 공유를 사용하여 ~ 50 % 더 빠르다고 측정했습니다.

NAS를 사용하지 마십시오.

로컬 (좋은 RAID 컨트롤러로 중기에는 OK)을 사용하지만 예산이 허락한다면 괜찮은 SAN으로 가십시오. 운 좋게도 다른 시스템과 SAN을 "공유"하고 초기 비용을 많이 회수 할 수 있습니다.

4GB RAM은 전용 SQL Server 인 한 대부분의 시스템에 적합합니다 (항상 있어야 함). 아직 고려하지 않은 경우 64 비트 OS 및 SQL Server를 사용하여 PAE / AWE를 사용하지 않고도 더 많은 RAM을 쉽게 넣을 수 있습니다.

가상화에 대해서도 생각하십시오. 테스트 서버가 필요하십니까? 개발자 서버? SP1 설치를 테스트 하시겠습니까? (이전 게시물의 뻔뻔한 플러스 : sql-server-in-vmware )

데이터베이스 크기가 2Gb이므로 SAN을 고려해야 할 이유가 없습니다. NAS가 작동하지 않습니다. 백업용 NAS 만 사용하면 데이터와 동일한 시스템에 백업을 저장하지 않아도되며 오프 사이트 저장을 위해 NAS에서 쉽게 복사 할 수 있습니다.

작은 데이터베이스의 경우 RAID 1 또는 RAID 10의 로컬 디스크 만 사용하십시오. 데이터베이스가 RAM에 적합하면 IO 성능에 대해 크게 걱정할 필요가 없습니다. 64 비트 창을 사용하고 8Gig를 넣습니다. 그것은 OS를 위해 많은 것을 남겨두고 성장할 여지를 줄 것입니다.

로컬 RAID 디스크와 광섬유 연결 SAN을 모두 사용하는 시스템을 사용합니다. SAN이 더 새롭고 더 빠른 시스템 인 경우에도 SAN이 더 잘 작동하는 것으로 보입니다. 중요한 요소는 로컬 디스크 배열이 단일 드라이브이므로 SQL이 OS 및 스왑 파일과 디스크 I / O를 공유한다는 것입니다. 이것은 아마도 드래그에 크게 기여하고 있습니다.

@spoulson이 언급했듯이 SAN은 훨씬 더 나은 디스크 성능을 제공 할 수 있습니다. 별도의 드라이브 일뿐만 아니라 디스크 하드웨어 속도가 훨씬 빠릅니다.

이 경우 SAN은 자동 장애 조치 VERITAS SQL Server 서비스 그룹을위한 중앙 집중식 스토리지 영역을 제공하기 때문에 SAN을 사용하고 있습니다. 기본 머신에 장애가 발생하면 SAN에 마운트 된 Windows 드라이브가 핫 백업 머신에 다시 마운트되고 서버가 매우 빠르게 백업됩니다. 물론, 서비스 그룹 관리를 위해서는 VERITAS와 유사한 시스템이 필요합니다.

우리가 어려움을 겪었던 한 가지 단점은 SAN 디스크 공간 할당이 보수적으로 처리된다는 것입니다. 비싸기 때문에 변덕에 빠지지 않습니다. 우리가 사용하는 EMC SAN을 사용하면 전체 LUN을 덤프하지 않고 할당 된 공간을 회수 할 수 없습니다. 따라서 할당 된 공간이 필요한 것보다 많고 다른 LUN에 해당 공간 중 일부를 사용하려는 경우에는 큰 공간을 축소 할 수 없습니다. 우리는 그것을 버리고 재 할당해야합니다. 프로덕션 환경에서는이 기능이 제대로 작동하지 않습니다.

다른 사람들이 제안했듯이 NAS를 피하십시오. 데이터 파일을 USB 외장 하드 드라이브에 넣을 수도 있습니다.

작은 2GB 데이터베이스의 경우 SAN이 과도하게 사용됩니다.

일반적으로 SQL 드라이브가 다른 응용 프로그램과 공유되는 것을 원하지 않습니다. 마찬가지로 파일을 분산시킬 수있는 스핀들 (디스크)이 많을수록 좋습니다. 다시 말하지만, 설명과 같이 작은 데이터베이스를 사용하면 RAM에 필요한 모든 것을 맞출 수 있으므로 디스크 성능이 중요하지 않습니다.

즉, 단일 RAID-10 볼륨을 만들고 모든 데이터베이스 파일을 넣지 마십시오. 데이터-2x 73GB 15K RPM, RAID1 로그-2x 73GB 15K RPM, RAID1 백업-단일 대형 7200 RPM 또는 RAID1의 쌍과 같은 간단한 것으로 시작할 수 있습니다.

업그레이드 예산이있는 경우 TempDB에 대해 별도의 별도 볼륨을 추가하거나 (복잡한보고 / 분석 쿼리를 수행하는 경우) 로그 볼륨에 더 많은 디스크를 제공하고 시스템이 볼륨이 많은 트랜잭션 일 경우 RAID10으로 구성하십시오. 업데이트.

SAN은 동등한 수의 드라이브에 대한 직접 연결 스토리지보다 3-4 배 많은 비용이들 것입니다. SAN은 백업 / 스냅 샷, 클러스터링 지원 및 LUN 마이그레이션 및 확장을위한 많은 고급 기능을 제공합니다. 이것들이 당신에게 중요하다면, 추가 비용이들 수 있습니다.

면책 조항 : NAS에 SQL Server 데이터베이스 파일을 저장하는 데 많은 심각한 문제가 있습니다. 다른 모든 옵션은 동일하므로 SAN 옵션을 선택하는 것이 맞습니다. 관련 문제에 대한 자세한 내용은 MS KB304261에 나와 있습니다. 그러나이 스레드는 네트워크 공유의 SQL Server와 관련된 다른 질문에 대한 모든 것을 포착했습니다 .SQL Server 버전에서 NAS 지원 상태에 대한 참조를 게시하고 싶습니다.

현재 상당수의 사람들이 MS SQL과 함께 NAS를 사용하는 실험을합니다.

기본적으로 금지되어 있었지만 MS SQL 2008 및 MS SQL 2005에서 제한을 해제 할 수 있습니다. MS SQL 2008 R2 이후에는 이러한 제한이 없습니다.

MS SQL 2005 및 2008에서 키는 네트워크 공유 사용을 금지하는 추적 플래그입니다. 하나는 발행 할 수 있습니다

 DBCC TRACEON(1807, -1)
 CREATE DATABASE [test] ON  PRIMARY 
 ( NAME = N'test', FILENAME = N'\\storage\mssql_db\test.mdf' )

자세한 내용은 2010 년 9 월 Varun Dhawan의 MSDN 블로그 게시물 을 참조하십시오.

적어도 기술적으로 NAS에서 SQL Server를 실행하는 것이 가능합니다. 선택은 많은 요인에 따라 다르며 NAS 용으로 데이터베이스 스토리지를 쉽게 사용할 수있는 상황을 상상하기 어렵지 않습니다.