|
| Sun ONE Directory Server 5.2 설치 및 조정 설명서 |
적절한 하드웨어 크기 조정은 디렉토리 서비스 계획 및 배포의 중요한 구성 요소입니다. 하드웨어 크기 조정에서 가장 중요한 요인은 사용할 수 있는 메모리 양과 로컬 디스크 공간 크기입니다.
이 장에서는 Directory Server 인스턴스의 디스크 및 메모리 요구 사항을 추정하는 방법에 대해 설명하며 네트워크 및 SSL 액셀러레이터 하드웨어 요구 사항에 대해서도 간략하게 다룹니다.
최소 요구 사항
표 4-1에서는 생산 환경에서 소프트웨어를 설치 및 사용하는 데 필요한 최소 메모리 및 디스크 공간 요구 사항을 보여줍니다.
지정된 항목 수에 대한 실제 최소 요구 사항은 표 4-1과 다를 수도 있습니다. 여기에 제시된 요구 사항은 기본 구성에 따라 색인이 설정되어 있고 최소 수준으로 캐시가 조정된 비교적 소수의 항목을 기준으로 상정한 것입니다. 항목에 디지털 사진과 같은 큰 이진 속성 값이 포함되어 있거나 색인화 또는 캐시를 다른 방식으로 구성할 경우 최소 디스크 공간 및 메모리 추정 값도 이에 따라 상향 조정하십시오.
최소 디스크 공간 요구 사항에는 액세스 로그에 할당된 1GB가 포함되어 있습니다. 기본적으로 Directory Server는 각각 최대 100MB(cn=config의 nsslapd-accesslog-maxlogsize)의 메시지를 저장하는 액세스 로그 파일 10개(cn=config의 nsslapd-accesslog-maxlogsperdir)를 순환적으로 사용하도록 구성되어 있습니다. 오류 로그와 감사 로그 용량은 Directory Server 구성 방법에 따라 달라집니다. 로깅 구성에 대한 자세한 내용은 Sun ONE Directory Server 관리 설명서를 참조 하십시오.
사용 가능한 최소 메모리
최소 메모리 추정 값은 일반 배포 시 Directory Server 인스턴스에서 사용하는 메모리를 반영합니다. 시스템 및 다른 응용 프로그램에서 사용하는 메모리는 이 추정 값에 포함되어 있지 않습니다. 보다 정확하게 산정하기 위해서는 실제 메모리 사용량을 측정해야 합니다. 자세한 내용은 "물리적 메모리 크기 조정"을 참조하십시오.
일반적으로 사용 가능한 메모리 양이 많을수록 더 바람직합니다.
최소 로컬 디스크 공간
최소 로컬 디스크 공간 추정 값은 일반 배포 시 Directory Server 인스턴스에 필요한 공간을 반영합니다. 경험에 따르면 디렉토리 항목이 클 경우 디스크에 있는 해당 LDIF 크기의 최소 네 배에 해당하는 공간이 필요합니다. 자세한 내용은 "디스크 하위 시스템 크기 조정"을 참조하십시오.
네트워크 디스크에는 서버 또는 이 서버에서 액세스하는 데이터를 설치하지 마십시오. Sun ONE Directory Server 소프트웨어는 NFS, AFS 또는 SMB를 통해 네트워크에 연결된 저장소의 사용을 지원하지 않습니다. 설치 후에도 구성, 로그, 데이터베이스 및 색인 파일은 모두 로컬 저장소에 있어야 합니다.
Windows 시스템을 사용하는 경우 드라이브를 FAT 대신 NTFS로 포맷하십시오. FAT는 Directory Server에서 지원되지 않습니다. NTFS를 사용하면 파일과 디렉토리에 대해 액세스 제어를 설정할 수 있습니다.
최소 처리 능력
일반적으로 대규모 시스템은 여러 개의 고속 프로세서를 사용하여 동시 다중 검색, 광범위한 색인화, 복제 및 기타 기능에 필요한 처리 능력을 제공합니다. 자세한 내용은 "다중 프로세서 시스템 크기 조정"을 참조하십시오.
최소 네트워크 용량
테스트에 따르면 예상되는 최대 처리량에 따라 100Mbit 이더넷으로 서비스 공급자 성능도 제공할 수 있습니다. 아래 수식에 의해 이론적인 최대 처리량을 추정할 수 있습니다.
최대 처리량 = 반환된 최대 항목 수/초 x 평균 항목 크기
예를 들어, Directory Server에서 초 당 최대 5000개의 검색에 응답해야 하며 각 검색에 대해 1개의 항목을 반환하고 항목의 평균 크기가 2000바이트이면 이론적인 최대 처리량은 10MB 또는 80Mbit가 됩니다. 80Mbit는 100Mbit 이더넷 어댑터 한 개가 제공할 수 있는 처리량보다 많습니다. 실제 성능은 이와 다를 수 있습니다.
WAN상에서 다중 마스터 복제를 수행하는 경우 네트워크 연결이 최소 대기 시간과 제로에 가까운 패킷 손실을 보장하면서 충분한 처리량을 제공하는지 확인합니다.
자세한 내용은 "네트워크 용량 크기 조정"을 참조하십시오.
물리적 메모리 크기 조정
Directory Server는 데이터베이스 기술을 사용하여 정보를 저장합니다. 데이터베이스 기술을 이용하는 모든 응용 프로그램의 경우와 마찬가지로 Directory Server 성능을 최적화하려면 빠른 메모리가 필요합니다. 일반적으로 사용 가능한 메모리 양이 많을수록 더 많은 디렉토리 정보를 캐시에 저장하여 신속하게 액세스할 수 있습니다. 항상 전체 디렉토리 내용을 캐시하기에 충분한 메모리가 각 서버에 있다면 가장 바람직할 것입니다. Sun ONE Directory Server 5.2는 64비트 메모리 주소 지정을 지원하기 때문에 캐시 크기가 몇 GB로 제한되지 않으며, 이론적으로 64비트 구조에서 총 1.5테라바이트 이상의 캐시 크기를 처리할 수 있습니다.
주 생산 환경에 Directory Server를 배포하는 경우 캐시 크기를 이론적인 프로세스 제한보다 훨씬 낮게 구성하여 일반 시스템 작동에 필요한 자원을 남겨 두십시오.
Directory Server 실행에 필요한 메모리 크기를 계산하려면 특정 Directory Server 구성에 필요한 메모리와 Directory Server를 실행하는 기본 시스템에 필요한 메모리를 추정해야 합니다.
Directory Server 메모리 크기 조정
특정 배포에 예상되는 구성 값이 있으면 Directory Server 인스턴스에 필요한 물리적 메모리를 추정할 수 있습니다. 표 4-2에는 이 절에 설명된 계산에서 사용하는 값이 요약되어 있습니다.
표 4-2 Directory Server 메모리 크기 조정 값
값
설명1
nsslapd-cachememsize
접미사의 항목 캐시 크기
항목 캐시에는 클라이언트 요청에 응답하여 바로 보낼 수 있는, 서식이 지정된 항목이 포함되어 있습니다. 한 개의 인스턴스에서 여러 개의 항목 캐시를 처리할 수 있습니다.
nsslapd-dbcachesize
데이터베이스 캐시 크기
데이터베이스 캐시에는 데이터베이스 요소와 서버에서 사용하는 색인이 저장됩니다.
nsslapd-import-cachesize
대량 가져오기용 데이터베이스 캐시 크기
가져오기 캐시는 항목을 가져올 때만 사용됩니다. 오프라인 가져오기만 수행하는 경우 가져오기 캐시에 추가 메모리를 할당하는 대신 항목 캐시나 데이터베이스 캐시에 할당된 메모리를 다시 사용할 수 있습니다.
nsslapd-maxconnections
관리되는 최대 연결 수
nsslapd-threadnumber
서버를 시작할 때 작성된 작업 스레드 수
자세한 설명은 Sun ONE Directory Server Reference Manual을 참조하십시오.
대략적인 메모리 크기를 추정하려면 다음 단계를 수행합니다.
- 서버 프로세스 slapdBase의 기본 크기를 추정합니다.
slapdBase = 75MB +(nsslapd-threadnumber x 0.5MB) +(nsslapd-maxconnections x 0.5KB)
- 항목 캐시 크기의 합계인 entryCacheSum을 결정합니다.
entryCacheSum = Sum all entry caches(nsslapd-cachememsize)
- 모든 캐시의 전체 크기인 cacheSum을 결정합니다.
cacheSum = entryCacheSum + nsslapd-dbcachesize + nsslapd-import-cachesize
- Directory Server 프로세스의 전체 크기인 cacheSum을 결정합니다.
slapdSize = slapdBase + cacheSum
Solaris 시스템에서 pmap(1)와 같은 유틸리티를 사용하거나 Windows 작업 관리자를 사용하여 Directory Server에서 사용한 물리적 메모리를 측정할 수 있습니다.
- 들어오는 클라이언트 요청인 slapdGrowth를 처리하는 데 필요한 메모리를 추정합니다.
slapdGrowth = 20% x slapdSize
첫 번째 추정 값에서는 클라이언트 요청을 처리하는 데 20%의 오버헤드를 가정합니다. 실제 백분율은 특정 배포의 특징에 따라 달라질 수 있습니다. Directory Server를 생산 환경에 설치하기 전에 실제 테스트를 통해 이 백분율을 확인하십시오.
- Directory Server의 전체 메모리 크기인 slapdTotal을 결정합니다.
slapdTotal = slapdSize + slapdGrowth
32비트 서버가 포함된 대규모 배포의 경우 slapdTotal이 실제 제한인 3.4GB는 물론 약 3.7GB의 이론적인 프로세스 제한까지 초과할 수 있습니다. 이 경우 6장 "캐시 크기 조정"에 설명된 것처럼 시스템 제한 내에서 작동하도록 캐시를 조정하거나 64비트 버전의 제품을 사용하도록 선택할 수 있습니다.
운영 체제 메모리 크기 조정
세부적인 시스템 구성에 따라 운영 체제 메모리 요구 사항이 크게 달라질 수 있으므로 기본 운영 체제를 실행하는 데 필요한 메모리는 실제 테스트를 통해 추정해야 합니다. 따라서 기본 운영 체제에 필요한 메모리를 추정하기 전에 5장 "운영 체제 조정"에 설명된 것처럼 배포용 샘플 시스템을 조정해 보십시오. 시스템을 조정한 후 메모리 사용을 모니터하여 초기 추정 값 systemBase에 도달하는지 확인합니다. Solaris 시스템에서 sar(1)과 같은 유틸리티를 사용하거나 Windows 작업 관리자를 사용하여 메모리 사용을 측정할 수 있습니다.
주 최상의 성능을 내려면 Directory Server 서비스 전용으로 시스템을 실행하십시오.
다른 응용 프로그램이나 서비스를 실행해야 한다면 필요한 총 메모리 크기를 조정할 때 이들 응용 프로그램이나 서비스에서 사용하는 메모리도 모니터해야 합니다.
일반적인 시스템 오버헤드와 정상적인 관리 용도를 위한 메모리도 할당하십시오. 첫 번째 추정 값인 systemOverhead는 수백 메가바이트 이상 또는 전체 물리적 메모리의 10% 중에서 더 큰 값이어야 합니다. systemOverhead에 충분한 공간을 할당하면 시스템이 작업 중에 페이지를 메모리로 스왑인 및 스왑아웃하는 것을 방지할 수 있습니다.
이렇게 해서 운영 체제에 필요한 총 메모리인 systemTotal은 다음과 같이 추정할 수 있습니다.
systemTotal = systemBase + systemOverhead
총 메모리 크기 조정
이전 절에서 계산된 slapdTotal 및 systemTotal 추정 값을 사용하여 필요한 총 메모리인 totalRAM을 추정합니다.
totalRAM = slapdTotal + systemTotal
totalRAM은 필요한 총 메모리의 추정 값입니다. 단, 시스템이 Directory Server 프로세스 전용이라고 가정하며 시스템에서 실행하는 다른 모든 응용 프로그램과 서비스의 예상 메모리 사용량을 포함합니다.
메모리가 부족한 경우의 대처 방법
대부분의 경우 Directory Server에서 사용하는 모든 데이터를 캐시하기에 충분한 메모리를 설치하는 것은 비용 효과적이지 않습니다.
하지만 최소한 Directory Server 실행으로 인해 지속적인 페이지 스와핑이 발생하지 않을 정도의 메모리는 서버에 설치되어 있어야 합니다. 지속적인 페이지 스와핑은 서버 성능을 크게 저하시킵니다. Solaris 및 기타 시스템에서는 vmstat(1M)와 같은 유틸리티를 사용하여 Directory Server 시작 및 항목 캐시 초기화 전후의 메모리 통계를 볼 수 있습니다.
MemTool과 같이 Solaris 시스템에 지원되지는 않지만 별도로 사용할 수 있는 유틸리티는 테스트 시스템에서 응용 프로그램을 실행할 때 메모리가 어떻게 사용 및 할당되는지 모니터하는 데 유용할 수 있습니다.
지속적인 페이지 스와핑이 발생하는 상황에서 시스템에 추가 메모리를 설치할 수 없는 경우에는 데이터베이스 캐시와 항목 캐시의 크기를 줄이십시오. 스왑 공간이 부족하면 Directory Server가 중단될 수 있습니다.
모든 디렉토리 데이터를 캐시하기에 충분한 물리적 메모리를 제공할 수 없을 때의 대체 방안에 대해서는 6장 "캐시 크기 조정"을 참조하십시오.
디스크 하위 시스템 크기 조정
디스크 사용 및 입출력 기능은 성능에 큰 영향을 줄 수 있습니다. 특히 다수의 수정 작업을 지원하는 배포 시 디스크 하위 시스템은 입출력 병목이 될 수 있습니다. 이 절에서는 Directory Server 인스턴스의 전체 디스크 용량을 추정하고 디스크 입출력 병목을 줄이기 위해 권장되는 작업에 대해 설명합니다.
디스크 입출력 병목을 줄이는 방법은 8장 "로깅 조정"을 참조하십시오.
디렉토리 접미사 크기 조정
접미사의 디스크 공간 요구 사항은 디렉토리 항목의 크기와 개수는 물론 디렉토리 구성과 특히 접미사 색인화 방법에 따라 달라집니다. 대규모 배포에 필요한 디스크 공간을 측정하려면 다음 단계를 수행합니다.
- 10,000개 항목, 100,000개 항목, 1,000,000개 항목에서 각각 한 개씩 선정하여 배포용으로 예상되는 세 가지 샘플 항목 집합의 LDIF를 생성합니다.
생성된 항목은 예상되는 항목 유형의 혼합(사용자, 그룹, 역할, 확장된 스키마 항목)은 물론, 특히 userCertificate 및 jpegPhoto와 같은 단일 대규모 속성 값이 예상되는 경우 개별 속성 값의 평균 크기도 반영해야 합니다.
- 배포에 예상되는 방식으로 Directory Server 인스턴스를 구성합니다.
특히 생산 디렉토리와 같은 방식으로 데이터베이스를 색인화합니다. 나중에 색인을 추가하려면 색인 공간도 추가해야 합니다.
- 각 항목 집합을 로드하고 각 집합에 사용된 디스크 공간을 기록합니다.
- 결과를 그래프로 작성하여 배포에 예상되는 접미사 크기를 추정합니다.
- 오류 및 편차를 보완하기 위해 여분의 디스크 공간을 추가합니다.
접미사 디스크 공간과 더불어 Directory Server의 디스크 사용 방법도 고려해야 합니다.
Directory Server의 디스크 사용 방법
디렉토리 접미사는 Directory Server에서 디스크에 저장하는 항목 중 하나입니다. 디스크 사용에 영향을 주는 기타 많은 요소는 배포 후 Directory Server의 사용 방법에 따라 크게 달라질 수 있으므로 여기서는 일반적인 경우에 대해서만 설명합니다. 여기에 설명된 항목 구성에 대한 자세한 내용은 Sun ONE Directory Server 관리 설명서를 참조하십시오.
Directory Server 이진
이 버전의 Directory Server를 설치하려면 약 200MB의 디스크 공간이 필요합니다. 이 추정 값은 제품 이진에 필요한 공간이며 데이터 공간은 포함되지 않습니다.
이벤트 로깅
로그 파일의 디스크 사용 추정 값은 Directory Server 작업 속도, 로깅 유형 및 수준, 로그 순환 전략에 따라 달라집니다.
로깅 요구 사항은 대부분 미리 예측하여 계획할 수 있습니다. Directory Server에서 로그, 특히 감사 로그에 쓰면 디스크 사용량이 로드 수준만큼 증가합니다. 로드가 큰 배포에 광범위한 로깅이 필요하면 높은 로드를 수용하기 위한 여분의 디스크 공간을 계획하십시오. 지능적 로그 순환과 보관 시스템을 구축하고, 자주 로그를 순환시키며, 이전 파일을 테이프나 값싼 디스크 클러스터와 같은 저렴한 대규모 저장 매체로 자동 이전함으로써 로드가 큰 로깅을 사용하는 배포의 디스크 공간 요구 사항을 줄일 수 있습니다.
로깅 요구 사항을 쉽게 예측할 수 없는 경우도 있습니다. 예를 들어, 디버그 로깅은 일시적이긴 하지만 errors 로그 크기를 급격하게 증가시킬 수 있습니다. 로드가 큰 대규모 배포의 경우 일시적인 대규모 디버그 로깅을 위해 몇 기가바이트의 전용 디스크 공간을 설정하는 것이 좋습니다. 자세한 내용은 8장 "로깅 조정"을 참조하십시오.
트랜잭션 로그
트랜잭션 로그 용량은 최대 쓰기 로드에 따라 달라지며, 쓰기 로드가 일정할 때보다 갑자기 증가할 때 더 많은 공간이 사용됩니다. Directory Server에서 정기적으로 트랜잭션 로그를 지우기 때문에 트랜잭션 로그는 계속 증가하지 않습니다. 하지만 온라인 백업 중에는 트랜잭션 로그가 플러시되지 않습니다.
Directory Server는 일반적으로 영구적 트랜잭션을 사용하여 실행됩니다. 영구적 트랜잭션 기능을 사용하는 Directory Server는 각 수정 작업(add, delete, modify, modrdn)을 동기적 방식으로 트랜잭션 로그에 씁니다. 이 경우 해당 디스크를 사용 중이면 작업이 차단될 수 있으므로 잠재적 입출력 병목이 발생합니다.
업데이트 성능이 중요하면 트랜잭션 로그 전용의 빠른 쓰기 캐시를 제공하는 디스크 하위 시스템을 사용합니다. 자세한 내용은 8장 "로깅 조정"을 참조하십시오.
복제 변경 로그 데이터베이스
배포 시 복제가 발생하는 경우 Directory Server 공급자는 변경 로깅을 수행합니다. 변경 로그 크기는 수정 용량과 사용된 변경 로그 지우기 유형에 따라 달라집니다. 변경 로그 지우기 방법에 따라 용량을 계획하십시오. 로드가 큰 대규모 배포의 경우 수정량이 비정상적으로 높은 기간 동안의 변경 로그 증가를 처리하기 위해 몇 기가바이트의 디스크 공간을 설정하는 것이 좋습니다. 자세한 내용은 8장 "로깅 조정"을 참조하십시오.
접미사 초기화 및 LDIF 파일
대량 로드 또는 가져오기라고도 하는 접미사 초기화 동안 Directory Server에는 접미사 데이터베이스 파일과 접미사 초기화에 사용된 LDIF를 저장할 디스크 공간 및 초기화 프로세스 중에 사용된 중간 파일을 저장할 공간이 필요합니다. 접미사 초기화 중에 사용된 LDIF 파일과 중간 파일을 저장할 데이터베이스 파일이 위치해 있는 디렉토리에 여분의 임시 용량을 계획하십시오.
백업 및 LDIF 파일
일반적으로 백업을 수행하면 다량의 디스크 공간이 소모됩니다. 백업 크기는 관련된 데이터베이스 파일의 크기와 같습니다. 데이터베이스 파일 용량의 몇 배에 해당하는 공간을 할당하여 여러 백업을 수용하고 데이터베이스와 해당 백업이 별도의 디스크에서 유지관리되게 합니다. 오래된 백업을 저렴한 저장 매체로 이전하는 지능형 전략을 사용하십시오.
초기화 LDIF 파일은 백업 LDIF 파일과 다르기 때문에 배포 시 복제가 발생하는 경우 초기화 LDIF 파일을 저장할 추가 공간을 계획합니다.
디스크 기반이 아닌 메모리 기반의 파일 시스템
일부 시스템은 메모리 기반의 tmpfs 파일 시스템을 지원합니다. 예를 들어, Solaris에서 /tmp는 성능을 향상시키기 위해 메모리 기반의 파일 시스템으로 마운트됩니다. 시스템의 다른 응용 프로그램과 공유하는 /tmp에 캐시 파일이 있을 경우 시스템의 /tmp 공간이 소모되지 않게 하십시오. 메모리가 부족하면 메모리 기반의 파일 시스템에 저장된 Directory Server 파일이 스왑 분할 영역에 할당된 디스크 공간으로 페이징될 수 있습니다.
일부 시스템은 RAM 디스크 및 메모리 기반의 다른 대체 파일 시스템을 지원합니다. 메모리 기반의 파일 시스템 작성 및 관리에 대한 자세한 내용은 운영 체제 설명서를 참조하십시오. 이러한 파일 시스템에 저장된 모든 내용은 휘발성이며, 시스템 재부트 후에 다시 메모리에 로드해야 합니다.
(UNIX 플랫폼) 코어 파일
최소한 core 파일 한두 개를 저장할 공간은 남겨 두십시오. Directory Server에서 코어를 덤프해서는 안 되지만 시스템 중단 중에 생성된 core 파일을 사용하여 검사할 수 있으면 시스템 중단 후의 복구 및 문제 해결이 훨씬 간편해집니다. 생성된 core 파일은 cn=config의 nsslapd-errorlog에서 지정된 파일과 동일한 디렉토리에 저장되거나, 시작 중에 시스템이 중단된 경우 ServerRoot/bin/slapd/server/ 아래에 저장됩니다.
관리 공간
시스템 및 Directory Server 관리를 비롯한 예상되는 시스템 사용 공간을 남겨 두십시오. 기본 Directory Server 설치, 로컬 인스턴스에 있는 경우의 구성 접미사, 구성 파일 등에 충분한 공간이 할당되어 있는지 확인합니다.
디스크에 파일 분산
자주 업데이트되는 Directory Server 데이터베이스와 로그 파일을 별도의 디스크 하위 시스템에 저장하면 여러 개의 디스크 스핀들과 컨트롤러에 입출력 트래픽을 분산하여 입출력 병목을 방지할 수 있습니다. 다음 각 항목에 대해 전용 디스크 하위 시스템을 제공하는 것이 좋습니다.
트랜잭션 로그
영구적 트랜잭션 기능을 사용하는 Directory Server는 각 수정 작업을 동기적 방식으로 트랜잭션 로그에 씁니다. 따라서 해당 디스크를 사용 중이면 작업이 차단됩니다. 트랜잭션 로그를 전용 디스크에 저장하면 쓰기 성능이 향상되며 Directory Server에서 처리할 수 있는 수정량이 증가합니다.
자세한 내용은 "트랜잭션 로깅"을 참조하십시오.
데이터베이스
다중 데이터베이스 지원에서는 각 데이터베이스를 자체 물리적 디스크에 저장할 수 있으므로 자체 디스크 하위 시스템에 있는 여러 데이터베이스에 Directory Server 로드를 분산시킬 수 있습니다. 데이터베이스 작업을 위한 입출력 경쟁을 방지하려면 각 데이터베이스 파일 집합을 별도의 디스크 하위 시스템에 저장하는 것이 좋습니다.
최상의 성능을 내려면 큰 입출력 버퍼가 있는 빠른 전용 디스크 하위 시스템에 데이터베이스 파일을 저장하십시오. Directory Server는 캐시에서 후보 항목을 찾지 못하면 디스크에서 데이터를 읽고 정기적으로 쓰기를 플러시합니다. 빠른 전용 디스크 하위 시스템을 이러한 작업에 사용하면 잠재적인 입출력 병목을 줄일 수 있습니다.
cn=config,cn=ldbm database,cn=plugins,cn=config의 nsslapd-directory 속성은 Directory Server에서 색인 파일을 비롯한 데이터베이스 파일을 저장하는 디스크 위치를 지정합니다. 기본적으로 이러한 파일은 ServerRoot/slapd-ServerID/db/에 저장됩니다.
데이터베이스 위치를 변경하면 Directory Server를 다시 시작해야 할 뿐만 아니라 데이터베이스를 완전히 다시 작성해야 합니다. 생산 서버에서 데이터베이스 위치를 변경하는 것은 쉬운 작업이 아니므로 서버를 생산 환경에 설치하기 전에 가장 중요한 데이터베이스를 식별하여 별도의 디스크에 저장하십시오.
로그 파일
Directory Server는 버퍼 로깅 기능을 사용하여 액세스, 오류 및 감사 로그를 제공합니다. 버퍼링 기능이 있긴 하지만 로그 파일에 쓰려면 디스크에 액세스해야 하기 때문에 다른 입출력 작업과 경쟁하게 될 수도 있습니다. 성능, 용량 및 관리 향상을 위해 별도의 디스크에 로그 파일을 저장하는 것이 좋습니다.
자세한 내용은 8장 "로깅 조정"을 참조하십시오.
메모리 기반 파일 시스템의 캐시 파일
tmpfs 파일 시스템에서 파일은 물리적 메모리가 모두 사용되었을 경우에만 디스크로 스왑됩니다. 물리적 메모리에 모든 캐시 파일을 저장하기에 충분한 메모리가 있으면
Solaris 플랫폼의 tmpfs 파일 시스템이나 다른 플랫폼의 기타 메모리 기반의 파일 시스템(예: RAM 디스크)에 이와 동등한 디스크 공간을 할당한 다음, Directory Server에서 이 파일 시스템에 캐시 파일을 저장하도록 nsslapd-db-home-directory 값을 설정하여 성능을 향상시킬 수 있습니다. 이 경우 시스템이 메모리에 매핑된 캐시 파일을 불필요하게 디스크로 플러시하는 것을 방지할 수 있습니다.디스크 하위 시스템 대체 방안
"Fast, cheap, safe: pick any two." - Sun Performance and Tuning, Cockroft and Pettit.
빠르고 안전한 대안
성능과 작동 시간이 모두 중요한 배포를 구현하는 경우, 대형 디스크 어레이에 분산된 고속 버퍼 입출력을 제공하기 위해 비휘발성 메모리 캐시가 있는 하드웨어 기반의 RAID 컨트롤러를 사용해 보십시오. 다수의 스핀들에 로드를 분산시키고 고속 연결을 통한 버퍼링 액세스를 제공함으로써 입출력을 최적화할 수 있으며, 고성능 RAID 스트라이핑 또는 패리티 블록을 통해 우수한 안정성이 제공됩니다.
Sun StorEdge™ 제품에서 제공하는 것과 같은 대규모의 비휘발성 입출력 버퍼와 고성능 디스크 하위 시스템은 Directory Server 성능과 작동 시간을 크게 향상시킬 수 있습니다.
특히 트랜잭션 로그 전용으로 빠른 쓰기 캐시 카드를 사용하면 쓰기 성능이 향상됩니다. 빠른 쓰기 캐시 카드는 디스크 컨트롤러의 영향을 받지 않는 비휘발성 메모리 캐시를 제공합니다.
빠르고 저렴한 대안
빠르고 저렴한 성능을 원할 경우 다수의 디스크에 적절한 용량을 분산하십시오. 회전 속도가 빠르고 탐색 시간이 짧은 디스크를 사용하는 것이 좋습니다. 최상의 결과를 내려면 각 분산 구성 요소에 전용 디스크를 할당합니다. 단일 장애 지점을 피하기 위해 다중 마스터 복제를 사용하는 것이 좋습니다.
저렴하고 안전한 대안
저렴하고 안전한 구성을 원할 경우 Solaris Volume Manager와 같은 소프트웨어 기반의 저렴한 RAID 컨트롤러를 사용해 보십시오.
RAID 대체 방안
RAID는 Redundant Array of Inexpensive Disks(저렴한 디스크의 중복 어레이)의 약어입니다. 이름에서 알 수 있듯이 RAID는 주로 복구 작업에 사용됩니다. 어레이에 구성된 특정 디스크에 장애가 발생해도 해당 디스크의 데이터는 손실되지 않고 이 어레이에 포함된 한 개 이상의 다른 디스크에서 계속 사용할 수 있습니다. 복구 기능을 구현하기 위해 RAID는 다중 디스크 드라이브를 볼륨이라는 보다 큰 가상 디스크로 구성할 수 있는 추상화를 제공합니다. 이 경우 물리적 디스크를 연결하거나 미러링 또는 스트라이핑해야 합니다. 연결을 구현하려면 논리적으로 특정 디스크 블록이 다른 디스크 블록 뒤에 오게 합니다. 예를 들어, 디스크 1에는 0-99 블록이 있고 디스크 2에는 100-199 블록이 있습니다. 미러링을 구현하려면 특정 디스크 블록을 다른 디스크에 복사한 다음 두 디스크가 계속해서 동기화되게 합니다. 스트라이핑은 여러 물리적 디스크에 가상 디스크 블록을 분산하는 알고리즘을 사용합니다.
스트라이핑은 성능 향상을 위해 사용됩니다. 디스크가 병렬로 작업할 수 있기 때문에 기록되는 데이터가 스트라이프 볼륨에 있는 두 개 이상의 디스크로 보내져서 매우 신속하게 임의 쓰기를 처리할 수 있습니다. 임의 읽기의 경우도 마찬가지입니다. 대규모의 순차적 읽기 및 쓰기에서는 큰 효과가 없을 수도 있지만 순차적 입출력 성능은 확실히 향상시킬 수 있습니다. 예를 들어, 한 개의 응용 프로그램이 다수의 입출력 요청을 생성하여 단일 디스크 컨트롤러를 무력하게 만들 수 있습니다. 하지만 스트라이프 볼륨 형식의 모든 디스크에 각각 전용 컨트롤러가 있으면 이러한 무력화를 방지할 수 있으므로 성능이 향상됩니다.
RAID는 소프트웨어나 하드웨어 RAID 관리자 장치를 사용하여 구현할 수 있습니다. 두 방법의 장단점은 다음과 같습니다.
- 일반적으로 하드웨어에 구현되는 하드웨어 RAID가 성능이 더 뛰어나기 때문에 소프트웨어 RAID보다 처리 오버헤드의 발생 가능성이 낮습니다. 또한 하드웨어 RAID는 호스트 시스템에서 분리되므로 호스트 자원으로 다른 응용 프로그램을 실행할 수 있습니다.
- 일반적으로 하드웨어 RAID가 소프트웨어 RAID보다 가격이 높습니다.
- 소프트웨어 RAID는 하드웨어 RAID보다 유연성이 뛰어날 수 있습니다. 예를 들어 하드웨어 RAID 관리자는 대체로 단일 디스크 어레이나 예정된 어레이 집합과 연결되는 반면, 소프트웨어 RAID는 수에 관계 없이 디스크 어레이를 캡슐화하거나 원할 경우 어레이 내의 특정 디스크만 캡슐화할 수 있습니다.
다음 절에서는 수준이라는 RAID 구성에 대해 설명합니다. 가장 일반적인 RAID 수준인 0, 1, 1+0, 5에 대해서는 어느 정도 자세히 다루고 있지만 일반적이지 않은 수준에 대해서는 간단한 비교 설명만 제공합니다.
RAID 0, 스트라이프 볼륨
스트라이핑은 여러 물리적 디스크에 데이터를 분산합니다. 논리적 디스크인 볼륨은 청크나 스트라이프로 나뉘어진 후에 라운드 로빈 방식으로 물리적 디스크에 분산됩니다. 스트라이프는 항상 한 개 이상의 디스크 블록 크기이며 모든 스트라이프 크기가 같습니다.
RAID 0은 중복을 제공하지 않는다는 점에서 이름과 모순됩니다. RAID 0 스트라이프에서 디스크 장애가 발생하면 전체 논리적 볼륨이 손실됩니다. 하지만 RAID 0은 모든 디스크가 데이터 전용이기 때문에 RAID 수준 중에서 가장 저렴합니다.
RAID 1, 미러 볼륨
미러링은 중복을 제공하기 위해 사용됩니다. 미러링되고 있는 디스크 중 하나에 장애가 발생해도 데이터를 계속 사용할 수 있으며 계속 처리됩니다. 한 가지 단점은 각 물리적 디스크가 미러링되므로 물리적 디스크 공간의 절반이 미러링에 사용된다는 것입니다.
RAID 1+0
RAID 10이라고도 하는 RAID 1+0은 가장 높은 수준의 성능과 복구 기능을 제공하기 때문에 구현 비용이 가장 높은 RAID 수준입니다. 장애가 발생한 모든 디스크에서 다른 미러를 형성하는 경우 최대 세 개의 디스크에 장애가 발생해도 계속 데이터를 사용할 수 있습니다. RAID 1+0은 각 세그먼트가 RAID 1인 스트라이프 어레이로 구현됩니다.
RAID 0+1
RAID 0+1은 RAID 1+0보다 복구 기능이 다소 떨어지며 스트라이프가 작성된 다음 미러됩니다. 미러의 같은 쪽에 있는 디스크는 한 개 이상에 장애가 발생해도 계속 데이터를 사용할 수 있지만 미러의 다른 쪽에 있는 디스크에 장애가 발생하면 논리적 볼륨이 손실됩니다. RAID 1+0과의 미세한 차이점은 같은 쪽에 있는 디스크는 동시에 장애가 발생해도 데이터를 계속 사용할 수 있다는 것입니다. RAID 0+1은 각 세그먼트가 RAID 0인 미러 어레이로 구현됩니다.
RAID 5
RAID 5는 미러링만큼 복구 기능이 뛰어나지는 않지만 단일 디스크 장애 후에도 데이터를 사용할 수 있다는 점에서 중복을 제공합니다. RAID 5는 다른 디스크의 해당 스트라이프 바이트에 대해 배타적 논리합 OR(XOR)을 수행하여 작성된 패리티 스트라이프를 사용하여 중복을 구현합니다. 특정 디스크에 장애가 발생하면 이 디스크의 데이터는 나머지 디스크의 해당 스트라이프에 있는 데이터와 패리티를 사용하여 다시 계산됩니다. 하지만 이러한 수정 계산을 수행할 경우 성능이 저하됩니다.
RAID 5 볼륨은 각각의 논리적 쓰기에 대해 네 번의 물리적 입출력 작업을 해야 하기 때문에 정상적으로 작동하는 RAID 5는 대체로 RAID 0, 1+0 및 0+1보다 성능이 낮습니다. 이전 데이터와 패리티를 읽고 두 번의 배타적 논리합 OR(XOR) 작업을 수행한 다음 새 데이터와 패리티를 씁니다. 읽기 작업은 별로 영향을 받지 않기 때문에 동등한 수의 디스크를 사용하는 표준 스트라이프보다 약간 성능이 떨어질 뿐입니다. 즉, RAID 5 볼륨의 스트라이프에는 실제로 디스크 수가 한 개 부족하며 이 공간은 패리티에 사용됩니다. RAID 5는 보다 많은 여유 디스크 공간을 데이터에 할당하기 때문에 RAID 5 볼륨이 일반적으로 RAID 1+0 및 0+1보다 저렴합니다.
성능 문제를 감안할 때 데이터가 읽기 전용이거나 볼륨에 대한 쓰기가 거의 없는 경우가 아니면 RAID 5는 일반적으로 권장되지 않습니다. 하지만 디스크 어레이에 쓰기 캐시와 빠른 배타적 논리합 OR 엔진이 있으면 이러한 성능 문제가 완화되므로 RAID 5는 일부 배포의 미러링에 적합한 저렴한 대안이 될 수 있습니다.
RAID 수준 2, 3, 4
RAID 수준 2와 3은 비디오 스트리밍과 같은 대규모의 순차적 데이터 전송에 적합합니다. 두 수준은 한 번에 한 개의 입출력 작업만 처리할 수 있으므로 임의 액세스가 필요한 응용 프로그램에는 바람직하지 않습니다. RAID 2는 해밍 오류 정정 코드(ECC)를 사용하여 구현됩니다. 즉, ECC 데이터를 저장하는 데 세 개의 물리적 디스크 드라이브가 필요하기 때문에 RAID 5보다는 비싸지만 스트라이프에 네 개 이상의 디스크가 있을 경우 RAID 1+0보다 저렴합니다. RAID 3은 비트 패리티 방법을 사용하여 중복을 구현합니다. 패리티는 RAID 5와 같이 분산되지 않고 단일 전용 디스크에 기록됩니다.
RAID 수준 2 또는 3과 달리 RAID 4는 여러 디스크 드라이브를 동시에 액세스하는 독립적인 액세스 방법을 사용합니다. 또한, 단일 디스크에 패리티를 쓰는 것을 제외하면 RAID 5와 유사한 방식으로 패리티를 사용합니다. 따라서 다중 쓰기를 효과적으로 일련화하여 쓰기를 수행할 때마다 패리티 디스크를 액세스하기 때문에 패리티 디스크가 병목이 될 수 있습니다.
소프트웨어 볼륨 관리자
Solaris™ Volume Manager와 같은 볼륨 관리자도 Directory Server 디스크 관리에 사용할 수 있습니다. 생산 환경에 배포할 때 Solaris Volume Manager는 다른 소프트웨어 볼륨 관리자보다 훨씬 뛰어난 성능을 보입니다.
입출력 및 디스크 사용 모니터
정상 작동 시 디스크 공간이 불필요하게 소모되어서는 안 됩니다. Solaris 및 기타 시스템에서는 iostat(1M)와 같은 유틸리티를 사용하여 잠재적인 입출력 병목을 확인할 수 있습니다. Windows 시스템에서 입출력 병목을 처리하는 방법은 Windows 도움말을 참조하십시오.
다중 프로세서 시스템 크기 조정
Directory Server 소프트웨어는 다중 프로세서로 확장할 수 있도록 최적화되어 있습니다. 일반적으로 프로세서를 추가하면 전체적인 검색, 색인 유지 관리 및 복제 성능이 향상됩니다.
하지만 특정 디렉토리 배포 시에는 프로세서를 추가해도 성능에 큰 효과가 없는 한계효용 체감점에 도달할 수 있습니다. 검색, 색인화 및 응용 프로그램에 대한 매우 엄격한 성능 요구 사항을 처리해야 하는 경우 로드 균형 조정과 디렉토리 프록시 기술을 솔루션의 일부로 사용해 보십시오.
네트워크 용량 크기 조정
Directory Server는 네트워크 사용량이 많은 응용 프로그램입니다. Directory Server 인스턴스의 네트워크 가용성을 향상시키려면 시스템에 두 개 이상의 네트워크 인터페이스를 설치하십시오. Directory Server는 한 프로세스를 처리할 때 다중 네트워크 인터페이스에서 수신하여 이러한 하드웨어 구성을 지원할 수 있습니다.
로드 균형을 조정하기 위해 같은 네트워크에 디렉토리 서버 클러스터를 구현하려면 네트워크 인프라가 생성된 추가 로드를 지원할 수 있는지 확인합니다. WAN 환경에서 복제를 위한 고속 업데이트를 지원하려면 실제 테스트를 통해 네트워크 품질과 대역폭이 복제 처리량 요구 사항을 충족시키는지 확인합니다.
SSL 크기 조정
기본적으로 SSL(Secure Sockets Layer) 프로토콜 지원은 소프트웨어에서 구현됩니다. 소프트웨어 기반의 SSL 구현을 사용하면 Directory Server 성능이 크게 저하될 수 있습니다. SSL 모드로 디렉토리를 실행하려면 전체적인 성능 요구 사항을 충족시키기 위해 여러 개의 디렉토리 복제본이 필요합니다.
하드웨어 액셀러레이터 카드도 SSL 사용으로 인한 영향을 완전히 제거할 수는 없지만 소프트웨어 기반의 구현에 비해 성능이 훨씬 향상됩니다. Sun ONE Directory Server 5.2는 지원되는 Sun Crypto Accelerator 하드웨어와 같은 SSL 하드웨어 액셀러레이터의 사용을 지원합니다.
Sun Crypto Accelerator 보드는 SSL 키 계산이 병목인 경우에 유용할 수 있습니다. 하지만 그 외의 경우에서는 이러한 하드웨어를 사용해도 성능이 향상되지 않습니다. Sun Crypto Accelerator 보드는 특히 연결을 협상하는 SSL 핸드셰이크 중에 키 계산을 가속화하지만 이후의 메시지 암호화 및 암호 해독은 가속화하지 않습니다. Directory Server 인스턴스에서 이러한 하드웨어를 사용하는 방법은 부록B "Sun Crypto Accelerator 보드 사용"을 참조하십시오.