it-swarm-ko.tech

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

SQL Server 2008과 함께 새 서버를 설치해야합니다. 무엇을 권장합니까? Raid 10이있는 하나의 서버 또는 NAS에있는 파일?

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

SAN은 어떻습니까?

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

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

15
Jedi Master Spooky

[~ # ~] nas [~ # ~]

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

[~ # ~] san [~ # ~]

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

이중 컨트롤러가있는 SAN은 단일 장애 지점이없는 아키텍처를 갖추고 있으며 핫 백업을위한 다양한 옵션을 제공합니다. 이를 통해 관리 용이성과 안정성 측면에서 승리 할 수 ​​있습니다. 그러나 후자가 트랜잭션 시스템에서 문제가되지는 않지만 스트리밍 데이터 볼륨에 대해 비용이 많이 들고 제약이 있습니다.

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

직접 연결

어떤 경우에는 직접 연결 스토리지가 가장 좋습니다. 한 가지 가능성은 대역폭이 제한된 스트리밍 애플리케이션으로, 제한된 수의 파이버 채널 연결로 인해 사용 가능한 대역폭이 하이 엔드 SAS 컨트롤러에서 가능한 것보다 작게 제한됩니다. shared-nothing 아키텍처가 최고의 처리량을 제공 할 수있는 매우 큰 데이터웨어 하우스와 같이 상당히 전문화 된 애플리케이션이어야합니다.

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

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

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

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

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

로컬 또는 SAN는 성능을 유지하는 유일한 방법입니다. 경우에 따라 더 큰 쓰기 캐시 및 병렬 디스크 처리량 구성으로 인해 SAN이 로컬 디스크보다 빠를 수 있음) .

Windows 공유를 통해 고성능 파일 I/O를 수행하지 마십시오. 처리량을 크게 저하시키는 많은 양의 프로토콜 오버 헤드가 있습니다. 예를 들어, 몇 년 전에 저는 WAN를 통한 대용량 파일 전송이 Windows 공유를 통한 FTP를 사용하여 ~ 50 % 더 빨 랐음을 측정했습니다.

2
spoulson

NAS를 사용하지 마십시오.

로컬 (좋은 RAID 컨트롤러로 중기 적으로 괜찮음)을 사용하지만 예산이 허용하는 경우 적절한 SAN을 사용하십시오. 운이 좋으면 SAN을 다른 시스템과 "공유"하고 초기 지출의 대부분을 회수 할 수 있습니다.

4GB RAM 전용 SQL Server 인 한 대부분의 시스템에서 괜찮습니다 (항상 그래야 함). 아직 고려하지 않았다면 64 비트 OS 및 SQL 서버를 사용하여 쉽게 PAE/AWE 물건을 다루지 않고 더 많은 RAM 안으로 던집니다.

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

1
Guy

2Gb의 데이터베이스 크기로 SAN을 고려할 이유가 없습니다. A NAS는 작동하지 않습니다. 백업을 위해 NAS) 만 사용하여 데이터와 동일한 시스템에 백업을 저장하지 않도록 생각해야합니다. 오프 사이트 저장을 위해 NAS에서 쉽게 복사 할 수 있습니다.

작은 데이터베이스의 경우 RAID 1 또는 RAID 10의 로컬 디스크를 사용하십시오. 데이터베이스가 RAM에 맞으면 IO 성능에 대해 크게 걱정할 필요가 없습니다. 64를 사용하십시오. 비트 윈도우에 8Gig를 넣으면 OS에 충분한 공간이 생기고 성장할 수있는 여지가 생깁니다.

1
Eric Z Beard

저는 로컬 RAID 디스크와 파이버 연결 SAN을 모두 사용하는 시스템으로 작업합니다. SAN 이전 시스템이 더 새롭고 빠른 시스템 인 경우에도 더 나은 성능을 보이는 것 같습니다. 중요한 요소는 로컬 디스크 배열이 단일 드라이브이므로 SQL이 디스크 I/O를 OS 및 스왑 파일입니다. 이것은 드래그에 크게 기여할 수 있습니다.

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

이 경우 자동 장애 조치 VERITAS SQL Server 서비스 그룹을위한 중앙 저장소 영역을 제공하기 때문에 SAN을 사용합니다. 기본 컴퓨터가 실패하면 Windows 드라이브가 SAN 핫 백업 머신에 다시 마운트하면 서버가 매우 빠르게 백업됩니다. 물론이를 위해서는 서비스 그룹 관리를 위해 VERITAS와 유사한 시스템이 필요하며 이는 범위를 벗어날 수 있습니다.

우리가 고생 한 한 가지주의 사항은 SAN 디스크 공간 할당이 보수적으로 처리된다는 것입니다. 비용이 많이 들기 때문에 변덕스럽지 않습니다. EMC SAN 사용하는 경우 전체 LUN을 덤프하지 않고는 할당 된 공간을 회수 할 수 없습니다. 따라서 할당 된 공간이 필요한 것보다 많고 해당 공간의 일부를 다른 LUN에 사용하려는 경우 사용할 수 없습니다. 크기가 큰 것을 축소하면됩니다. 삭제하고 재 할당해야합니다. 프로덕션 환경에서는 제대로 작동하지 않습니다.

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

0
Peter

작은 2GB 데이터베이스의 경우 SAN은 과잉입니다.

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

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

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

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

0
Chris B

면책 조항 : 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' )

자세한 내용은 Varun Dhawan의 MSDN 블로그에있는 2010 년 9 월 게시물 에 있습니다.

기술적으로는 NAS에서 SQL Server를 실행할 수 있습니다. 선택은 여러 요인에 따라 달라지며 NAS에서 데이터베이스 용 저장소를 쉽게 사용할 수있는 상황을 상상하기 어렵지 않습니다.

0
Dmitri Chubarov