저장 장치에 대한 설계 및 감시 방법에 대한 성능을 위한 권장 사항-3
이 자료는 SharePoint Product & Technologies Team Blog에서 보았던 자료 중 하나 입니다. 그 문서를 나름대로 멋대로 번역한 문서입니다. 이 번역 문서는 MS 공식이 아니므로 인용될 수 없습니다. 인용하시고 싶으시면, 원본 문서를 참조하시기 바랍니다. 해당 문서는 Word 문서로 되어 있으며 이 내용의 원본 백서(White Paper)는 http://go.microsoft.com/fwlink/?LinkID=105623&clcid=0x409 에서 다운로드 받을 수 있습니다.
물리적 측면의 지침
전체 시스템 성능은 SQL 서버의 배치 방법, 네트워크, 물리적 저장 장소 형태 및 내부 캐쉬가 어떻게 구성되어 있는지에 따라 달라 진다. 또한 하드웨어 구성 시, 32bit 기반의 운영체제 및 데이터베이스로 운영되어야 하는 경우, 가급적 최신 버전의 SharePoint 제품군을 사용하는 것이 좋다.
중요: 단계적인 업그레이드 방법을 고객에게 제시 할 때, SQL 서버가 허용치 내의 응답 시간을 유지 하기 위해 SQL 서버 자원 중 최소한 한 가지 혹은 두 가지의 요소에 대한 업그레이드를 고려한다.
다음의 권장 사항들은 SharePoint 제품 군을 사용하는 서버에서 SQL 서버 데이터베이스를 이용하는 경우를 기준으로 제품군 팀에서 찾아낸 최적의 실례들을 기반으로 제시하는 내용이다.
독립적으로 설치된 SQL Server 2005를 사용하는 경우
• 단일 서버에 모든 서비스를 올릴 계획이 아니면, 이 독립적으로 구성된 SQL Server 상에 다른 Farm 역할을 할당하지 않는다. 오로지 SQL Server로서만 동작하게 한다.
• 구성 상황에 중대한 문제가 있는 경우가 아니면, SQL Server 구성 시 반드시 64-bit 운영체제에 64-bit SQL Server로 구성하는 것이 좋다. 이 구성이 최상의 설정을 위한 최고의 권장사항이다..
• SQL Server 2005를 사용할 때, 구성 상황에 중대한 문제가 있어 이전 버전을 사용하고 있는 경우가 아니라면, 최신의 Service Pack(이 문서가 작성될 시점을 기준으로 SP2)가 설치되어야 최적의 성능 보장이 가능하다.
• SQL Server에서 이용하는 I/O 채널들 (디스크들) 은 다른 응용 프로그램들(운영체제 가상 메모리 파일 또는 IIS 로그 등등)과 공유해서 사용하지 않는다.
자원 추가가 예상되는 확장 시 고려사항
SQL 서버 성능을 좌우 하는 세가지 중요한 자원 요소가 있다. CPU, 메모리, I/O 서브 시스템이 바로 그 세가지다. 혹시 구성요소 중 확장시킬 예정인 경우, 현재 또는 예상되는 작업량을 기반으로 각종 대처 방안들을 파악하여 최적의 방안을 찾고, 자원 또는 SQL 서버 자체를 추가 함으로써 얻을 수 있는 성능 향상되는 항목들을 확인하도록 한다. 보통, 제품 팀에서 권장하는 성능 향상 방법이 일반적으로 서버 자원을 추가 증설 방법이다.
하드웨어 선정 시, SQL 서버 지침 따르기
SQL 서버 팀에서 권장하는 하드웨어 관련 지침 사항 중에는 SharePoint 제품군에서 중요하게 다루는 중요한 요소들은 아래와 같다.
메모리
SQL 서버에서 적절한 메모리 용량에 대해 파악하려면 제일 먼저 메모리 수요에 따른 배포 규모를 확인한다. 편의상 배포 규모를 나눈다면 소규모, 중규모, 대규모 나눌 수 있다.
| 조 건 | 값 |
| 컨텐츠 데이터베이스 크기 | 50 GB 초과 |
| 컨텐츠 데이터 베이스 수 | 20 개 초과 |
| SQL 서버 내 동시 접속 요청 수 | 200 개 초과 |
| 사용자 수 | 1000 명 초과 |
| 일반적으로 접근 가능한 리스트 내의 아이템 수 | 2000 개 초과 |
| 일반적으로 접근 가능한 리스트 내의 필드 수 | 20 개 초과 |
각 배포 규모는 아래와 같은 기준으로 나눈다.
• 배포 규모가 기준치에 위의 표에 미달하면, 소규모로 판단된다.
• 배포 규모가 위의 수치와 유사하거나, 2가지 정도 내의 항목만 넘어서는 경우 중규모로 판단된다.
• 배포 규모가 위의 수치를 초과하거나, 대부분의 값이 수치를 넘어서는 경우 대규모로 판단된다.
단 위의 표에서 나타내는 기준은 일반적인 구성 형태의 사이트를 기준으로 작성되어 있다. 만일 특이한 형태를 갖춘 형태로 구성되거나 계획 예정인 형태에서는 위의 지침대로 구분할 수 없다.
메모리 용량에 영향을 받는 다른 요소들로는 다음과 같다.
• SQL 서버 미러링을 사용여부
• 15MB 보다 큰 파일을 자주 사용하는 경우
대략적인 권장되는 메모리는 아래와 같다. (SQL 서버용 메모리)
• 최소 4GB의 메모리가
• 중규모에서는 8G 정도
• 대규모에서는 16GB 이상
Cache
• SQL 서버가 동작하는 서버 상에서 L2 캐쉬가 CPU당 최소 2MB 이상의 캐쉬 용량을 갖추어야 한다.
Bus Bandwidth
대형 버스 대역폭(bus bandwidth )은 성능 및 가용성을 확장하는 중요한 요소이다. 주의 해야 할 점은 디스크를 활용하는 것이 아니라는 것이다. 예를 들면, 네트워크 접근 등을 들 수 있다.
• 중간 규모에서 대규모의 서버들은, 대형 버스 대역폭을 갖추어야 시스템 가용성을 갖출 수 있다. 특히 multi-pathing 소프트웨어을 추가할 계획이면 중요하다. (작은 규모의 시스템에서는 대형 버스 대역폭이 가용성 증대에 대해서는 별의미가 없다.) 버스 대역폭의 가용성은 시스템 내 여유 Path를 고려해 줄 수 있으며, 하드웨어 장치에서 오류가 발생할 때, 단일 시스템이 갖는 문제점들을 방지할 수 있다.
• 대형 버스 대역폭은 순차 I/O 및 대규모 블록 전송을 자주 사용하는 시스템에서 특히 성능 향상을 가져올 수 있다.
• 대부분 순차적인 I/O를 사용하는 소규모 서버에서 PCI 장치인 경우 3대의 디스크 정도 연결되는 경우 병목현상이 발생할 수 있다. 또한 임의 I/O가 많이 수행되는 소규모 시스템인 경우에는 최대 8대 디스크 정도로 구성할 수 있다. 물론 PCI로 충분할 수 있지만, 가급적 PCI-X 기반의 인터페이스를 통해 처리되도록 하는 것이 좋다.
• 대형 버스 대역폭은 많은 수의 디스크 연결에 반드시 필요한 요소 중 하나이다.
• 시스템 위상의 제한으로 버스 대역폭의 용량에 제한을 받을 수 있다. 만일 시스템이 직접 연결형 디스크를 사용한다면, 디스크 슬롯 수의 제한으로 충분히 연결 할 수 없을 수 있다. 하지만, 만일 SAN 기반 시스템이라면, 이와 같은 물리적인 제한 요소가 없다..
• 대형 또는 고속 버스는 일반적으로 가격이 비싼 서버들에 구성된다. 간혹 대치 서버 없이 버스의 대역폭 용량을 늘릴 수 없는 경우가 있다. 하지만, 대형 서버들은 다양한 형태의 구성을 시도해 볼 수 있다. 이 경우 해당 서버의 담당자에게 상세한 점검을 요구한다.
Disk | RAID | SAN 인터페이스
시스템에서 사용하는 인터페이스에 따라 가용성 및 성능에 미치는 영향이 틀리다.
대형 드라이브들은 대부분 또는 동일하게 탐색 시간(Seek time)이 증가 될 수 있다.
아래 내용을 참고하여 인터페이스의 선택에 대해 한번 즈음 고려할 필요가 있다.
인터페이스 : SCSI
장점
• 강제 데이터 쓰기를 지원하므로, 데이터 복구율이 높다.
• TCQ를 갖춘 SCSI는 다중 I/O 요청을 처리할 수 있다.
• 핫-스왑(hot-swapping )을 지원한다.
• SCSI 는 채널당 최대 15개의 드라이브를 연결 할 수 있다.
• 물리적인 케이블 길이의 제한이 적다.
단점
비고
• 채널에 너무 많은 수의 드라이브를 연결하면, 전송률 제한에 도달하는 경우가 증가됨
인터페이스 : IDE
장점
• 핫-스왑(hot-swapping ) 지원
• 채널당 1개의 드라이브만 장착했을 때 높은 전송률을 보임
• 보통 SCSI 보다 큰 용량의 드라이브 장치가 많다.
• 보통 SCSI 드라이브 보다 GB 당 가격이 저렴하다.
단점
• 채널 당 I/O 요청에 대하여 한번에 하나씩 처리되는 경향이 강함
인터페이스 : SATA
장점
• TCQ가 내장된 SCSI 에서는 멀티 I/O 요청을 지원한다.
• 핫-스왑(hot-swapping ) 지원
• 대부분 채널당 한대의 드라이브를 지원하도록 설계되어 있는 경우가 많지만, 2~12개 이상의 SATA 채널을 지원하는 추가 인터페이스 카드가 있음
• 보통 SCSI 보다 큰 용량의 드라이브 장치가 많다.
• 보통 SCSI 드라이브 보다 GB 당 가격이 저렴하다.
인터페이스 : SAS
장점
• 매우 빠르다..
• SCSI 프로토콜을 지원.
• SCSI보다 더 많은 수의 디스크를 장착할 수 있다
비고
• DAS에서만 적용됨.
• 병렬 SCSI를 기술적 대치
• SATA 드라이버들에 대해 하위 호환.
Disk Topology (Direct Attach/SAN/NAS)
현재 시스템에서 사용 중인 Disk Topology은 시스템의 가용성과 성능에 영향을 미칠 수 있다.
• SQL 서버가 동작 중인 서버의 I/O 시스템에서 최소 대기 시간은 매우 중요하다. I/O 시스템에서 느린 응답을 주는 경우에는 아무리 다른 자원들(CPU나 메모리 등)을 추가해도 성능 향상을 가져다 주지 않는다. 단지, Farm 전체적인 이슈를 조장하고, 유발하게 된다. 그러므로 배포 전에 최소 지연에 대한 계획을 수립하고, 다음 섹션에 있는 감시 부분에서 설명하는 것처럼 기존 시스템에 대한 지속적인 감시를 해야 한다.
아래의 내용을 활용하여 Topology에 대해 정확히 왜 선택했는지에 대해 명확히 할 필요가 있다.
인터페이스 : SAN
장점
• 다중 서버에 연결하여 서비스 할 수 있다.
• 사용할 디스크의 수에 대한 제한이 없다.
• 많은 수의 서버를 쉽게 추가/관리할 수 있다.
• 서버간의 디스크 저장 공간을 재 설정할 수 있다.
• DAS에 비해 저렴한 비용으로 관리 할 수 있다.
단점
• 채널에 너무 많은 수의 드라이브를 연결하면, 전송률 제한에 도달하는 경우가 증가됨
인터페이스 : DAS
장점
• 최고속 대역폭을 제공
• 적은 수의 서버에 대해 관리하기 쉽다.
• SAN 보다 초기 비용이 저렴하다.
단점
• 서버 당 구축해야 한다.
• 디스크 장착용 슬롯 수 및 사용되는 인터페이스의 종류가 제약이 있다.
인터페이스 : 네트워크 기반 저장 장치
장점
• TCQ가 내장된 SCSI 에서는 멀티 I/O 요청을 지원한다.
• 핫-스왑(hot-swapping ) 지원
• 대부분 채널당 한대의 드라이브를 지원하도록 설계되어 있는 경우가 많지만, 2~12개 이상의 SATA 채널을 지원하는 추가 인터페이스 카드가 있음
• 보통 SCSI 보다 큰 용량의 드라이브 장치가 많다.
• 보통 SCSI 드라이브 보다 GB 당 가격이 저렴하다.
단점
• NAS 환경에서는 SQL Server에 필요한 I/O 응답 시간에 대해, 보장하거나, 관리할 수 없다.
• iSCSI 는 낮은 I/O 량에 대해서만 지원된다.
인터페이스 : SAS
장점
• 매우 빠르다..
• SCSI 프로토콜을 지원.
• SCSI보다 더 많은 수의 디스크를 장착할 수 있다
비고
• DAS에서만 적용됨.
• 병렬 SCSI를 기술적 대치
• SATA 드라이버들에 대해 하위 호환.