It's Myself

프로젝트 중에 사용자 로그인 관련해서 현재 시스템이 Join 되어 있는 AD 상의 도메인명을
아는 방법에 대해서 잠깐 고민한적이 있다.
특히 MOSS 내에서 사용자 관련 하여 추가 하거나, 특정 정보 중 로그인 정보를 넣어야  하는 경우 두가지 방법으로 처리했다.
한가지는 web.config 에 Application값으로 넣어버리기.
web.config에다 직접 도메인 명을 넣어, 필요할 때마다 읽을 수 있도록 했다.
다른 한가지는 코드에 직접 박아 static 변수로 만들어 버리기.
좀 후진 방법이지만.. 나름 쓰기 편해서...

그런데, 사실 위의 방법으로 할 때, 타 시스템으로 해당 코드의 포팅 작업을 할 때,
좀 귀찮긴 하다. web.config를 수정하거나 코드를 수정해야 하니까.
게다가, 해당 값을 읽어오는 메소드를 추가적으로 짜야 되니 그것 또한 짜증이였다.

이를 간단하게 해결해주는 부분이 있으니...
바로
System.Environment.UserDomainName

위의 프로퍼티를 사용하면 현재 사용 중인 AD 도메인 명을 돌려준다.

P.S. Form 인증일 때, 사용하는 Provider 이름을 가져오는 방법에 대해서는 조금더 고민해봐야 겠다.

Utility 네임 스페이스 안에 있는 수많은 Utility 중에서 또 하나 기가 막히게 자주 쓰는 도구가 있으니 바로 Encoder 다. 언어별 Encoder는 아니고, URL과 HTML에 대한 Encoder다.

간혹 HTML 내용이 있을 때, HTML 소스 그대로를 출력해주어야 할 때가 있다.
그렇다고 우리가 번역하기엔 그 내용도 만만치 않고 귀찮다. 그 때 해주는 Encoder가 아래와 같다.

string Microsoft.SharePoint.Utilities.SPEncode.HtmlEncoder(원본 HTML이 담긴 string 내용)

위의 메소드를 쓰면 < 같은 것이 &lt; 이런식으로 바꿔 주게 된다. 거기서 Encoding된 내용을 웹브라우저에서 보면 <로 바뀌어 보이게 된다.

역으로 Encoding 된 것을 바꿔주는 것이 아래이다.

string Microsoft.SharePoint.Utilities.SPEncode.HtmlDecoder(원본 HTML이 담긴 string 내용)

두번째는 URL 인코더다.
간혹 URL을 통해 GET 메소드에 사용할 값을 넘겨 줄떄가 있다. 그 때 URL 내에 이상한 문자가 들어가면 안되는 경우가 있다.
예를 들어 "http://www.hind.pe.kr/test.php?value1=크크크 호호호호&value2=I&you" 라는 URL이 있을 때 value1에는 한글 가득한데다 그 안에 공백 문자가 있고, Value2에는 I와 you 사이에 & 이라는 문자가 있다. 이러면 명백한 오류. 그러나 그 값들은 꼭 넘어가야 한다고 할때... 처리해 주는 도구가 바로 아래이다.

string Microsoft.SharePoint.Utilities.SPEncode.UrlEncoder(원본 값이 담긴 string 내용) 

저것을 사용하면 크크크 호호호호 라는 값이 #FF02#F022..... 형태로 바뀌는 것을 볼 수 있을 것이다. ( 간혹 아예 value1=크크크 호호호호 라는 것을 통채로 인코딩하시는 분들이 있는데 그건 오해이자 막가는 것이다. 크크크 호호호호 만 인코딩 해줘야 한다. )

물론 이 역함수는 아래와 같다.

string Microsoft.SharePoint.Utilities.SPEncode.UrlDecoder(원본 값이 담긴 string 내용)

하나씩 하나씩 진기로운 도구들이 숨겨져 있어서 나름 재미를 뽐내는(?) SharePoint 인것 같다.

P.S 사실 알고 보면, .NET Framework 내에서도 위와 같은 작업을 해주는 Method들이 있다.

주의 : 이 작업은 MS SQL 2005에만 해당 되며, SQL 2000 혹은 다른 DBMS를 사용중이라면 아래의 쿼리 내용을 수정/편집 해야 한다.

MOSS 2007을 유지 관리하다 보면 데이터베이스 파일 크기에 대해 주의를 기울이게 되는데, 이를 미리 파악하기 위한 쿼리를 만들어 보았다. 하지만, 절대 아래의 쿼리가 튜닝된 데이터는 아니다. SELECT 만 좀 할 줄 아는 사람이 이것 저것 문서보면서 만든 쿼리이기 때문에, 성능상 문제가 되는 경우 알아서 편집을 해야 할 것이다.

아래의 쿼리를 Microsoft SQL Server Management Studio 에서 실행한다.

CREATE table #tot_resultSize
(
name sysname,
fileid smallint,
filename varchar(500),
filegroup varchar(50),
size nvarchar(13) null,
maxsize varchar(50),
growth varchar(50),
usage varchar(50)
)
DECLARE @cmd varchar(500);
DECLARE @name varchar(255);
--SET @name = 'WSS_CONTENT_80'
--INSERT #tot_resultSize  select @cmd = 'use ' +  quotename(@name) + N' exec sys.sp_helpfile'

DECLARE DBLits CURSOR
FOR select name from sys.databases ORDER by name;
OPEN DBLits;
FETCH NEXT FROM DBLits
INTO @name
WHILE @@FETCH_STATUS = 0
BEGIN
select @cmd = 'use ' +  quotename(@name) + N' exec sys.sp_helpfile'
INSERT INTO #tot_resultSize exec (@cmd)
FETCH NEXT FROM DBLits
INTO @name
END
CLOSE DBLits;
DEALLOCATE DBLits;
SELECT name, (convert(decimal, LEFT(size, LEN(size)-2))/1024/1024) as size FROM #tot_resultSize WHERE filegroup = 'PRIMARY'
SELECT name, (convert(decimal, LEFT(size, LEN(size)-2))/1024/1024) as size FROM #tot_resultSize WHERE filegroup IS NULL
DROP TABLE #tot_resultSize

이 내용을 보면 쿼리가 두 종류가 나오는데, 위쪽 결과 물이 데이터 파일, 아래쪽 결과물이 로그 파일들이다.

위의 목록을 모두 긁어서 복사한 뒤, Excel 파일에 붙여 넣기 해서, Excel로 정리해서 보면 보고하기도 좋고, 자신이 관리 처리하기 좋을 것이다.

SharePoint 에서 제공하는 다양한 Utility들이 있는데, 그 중 한가지 재미있는 메소드를 소개한다.

간혹 HTML 원본 문서가 오면, 그 문서의 HTML 관련 태그들을 모두 날리고 표현하고 싶을 때가 있다.

예전 프로젝트 때, 해당하는 HTML 태그를 날리는 기능을 하는 함수를 만들어서 쓴적이 있었는데,

문제는 이 기능을 만들어 넣으려면 점점 그 크기가 커지는 것을 막을 수 없었다.

( 처음에는 단순하게 < 태그 시작에서 끝이 > 인 것이라는 조건으로 시작 &nbsp; 에 &amp;에.....등등)

이 다양한 기능을 위한 레귤러 익스프레스를 가져와 썼지만, 역효과...

도리어 지우지 말아야 하는 부분까지 삭제되는 불상사가 발생하곤 했다.

이를 한큐에 해결 해주는 부분이 있었으니...

바로 이 메소드

string Microsoft.SharePoint.Utilities.SPHttpUtility.ConvertSimpleHtmlToText( 원본 Html 문자열, 가져올 길이)

이 메소드를 사용하면 간단하게 HTML 관련 태그들은 모조리 날리고, 제한 길이 만큼 잘라서 보내주게 된다.

(보통 이 메소드를 사용하는 때가, 요약을 보여줄 떄 많이 사용되는 듯.)

사용방법은 간단.

만일 HTML 원본 Text가 sHtmlSource 라는 변수에 담기고 100글자만 담고 싶다면....

string sResult = Microsoft.SharePoint.Utilities.SPHttpUtility.ConvertSimpleHtmlToText(sHtmlSource, 100)

하면 된다. 물론 Microsoft.SharePoint.dll 이 참조로 걸려 있어야 쓸 수 있다.!

이 자료는 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 서버에서 적절한 메모리 용량에 대해 파악하려면 제일 먼저 메모리 수요에 따른 배포 규모를 확인한다. 편의상 배포 규모를 나눈다면 소규모, 중규모, 대규모 나눌 수 있다.

각 배포 규모는 아래와 같은 기준으로 나눈다.

• 배포 규모가 기준치에 위의 표에 미달하면, 소규모로 판단된다.

• 배포 규모가 위의 수치와 유사하거나, 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)이 증가 될 수 있다.

아래 내용을 참고하여  인터페이스의 선택에 대해 한번 즈음 고려할 필요가 있다.

장점

• 강제 데이터 쓰기를 지원하므로, 데이터 복구율이 높다.

• 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 드라이버들에 대해 하위 호환.

이 자료는 SharePoint Product & Technologies Team Blog에서 보았던 자료 중 하나 입니다. 그 문서를 나름대로 멋대로 번역한 문서입니다. 이 번역 문서는 MS 공식이 아니므로 인용될 수 없습니다. 인용하시고 싶으시면, 원본 문서를 참조하시기 바랍니다. 해당 문서는 Word 문서로 되어 있으며 이 내용의 원본 백서(White Paper)는 http://go.microsoft.com/fwlink/?LinkID=105623&clcid=0x409 에서 다운로드 받을 수 있습니다.

정보 아키텍처 기준 권장사항

성능 향상을 하려면, 제일 먼저 수립해야 하는 것이 바로 정보 아키텍처이다. 이 정보 아키텍처를 수립에 다음 사항들을 고려하여 수립하도록 한다.

SharePoint 제품 군 및 기술의 소프트웨어 한계 범위에 맞추어 정보 아키텍처를 수립

소프트웨어 한계 범위에 대한 더 자세한 사항은  Plan for software boundaries (http://go.microsoft.com/fwlink/?LinkID=105578&clcid=0x409)를 참고한다.

최대 관리 범위의 컨텐츠 데이터베이스의 제한 크기.

실제 적용 환경에 맞는 성능 및 관리적인 측면에 맞추어 데이터베이스 사이즈를 계획한다.

• SharePoint 제품 및 기술 팀에서 제품 성능 향상을 위해 지원을 하다 보면, 대부분 컨텐츠 데이터베이스가 100GB를 넘은 상태가 되어 튜닝 작업에 어려움을 겪는 경우가 많았다. 혹시 데이터베이스의 설계가 100G를 넘기는 형태가 될 것 같다면 가급적 다음 지침들을 따르도록 한다.
  • 데이터만 저장하기 위한 별도 사이트 콜렉션을 구성한다.
  • SharePoint에서 제공하는 백업/복원 도구를 사용하지 말고, SQL Server 또는 Microsoft System Center Data Protection Manager 에서 제공되는 백업 솔루션을 이용 한다.
  • 100GB 크기 컨텐츠 데이터베이스상에 있는 솔루션 들에 대해 이동 작업을 수행하기 전에, 반드시 SQL Server가 동작 중인 서버에서 I/O 서브 시스템을 중점 테스트한다.
• 가능하면, 100GB에 도달된 컨텐츠 데이터베이스에 있는 사이트 컬렉션에 있는 데이터들을 적절히 나누어 새로운 컨텐츠 데이터베이스에 새로운 사이트 콜렉션을 두어 옮겨야 성능 또는 관리적인 문제를 최대한 방지할 수 있다.
• 여러 개 사이트 콜렉션이 담긴 컨텐츠 데이터베이스가 약 100GB를 넘지 않도록 설계한다.

주의: 여기서 제한된 사항들은 SharePoint 제품 군에서 사용되는SQL Server에 대한 권장 사항들 이다. 일반적인 SQL Server에 대한 지침은 아니다.

버전 관리 및 휴지통에 대한 저장 장소 확보하기.

사이트 내에 버전 관리 혹은 휴지통을 사용하거나, 사용할 계획이라면, 사이트 용량제한(Quota)으로 인해 발생될 잠재적인 문제점들에 대해 미리 확인해야 한다.

• 버전 관리를 하고 있는 라이브러리(문서, 그림 등등)에서 과거 버전 데이터들이 이용한 용량 때문에, 사이트 제한 용량을 초과 할 수 있다. 이 점을 주의해서 구성하도록 한다.
• 일반적인 사이트에서는 한 단계 혹은 두 단계의 휴지통을 사용한다. 
  첫 번째 단계의 휴지통(사용자가 직접 사용하는 사이트 휴지통)에서 사이트 제한 용량(Quota)을 초과 시키는 원인이 될 수 있다. 그에 반해 두 번째 단계 휴지통(사이트 콜렉션 - 사이트 모음 - 에서 제공되는 휴지통)은 사이트 제한 용량(Quota)과는 관계없이 동작된다.
  그러나 두 번째 단계의 휴지통에 담기는 사항들은 사이트 콜렉션에서 사용하는 저장 공간에 저장되기 때문에, DB 자체 용량을 초과하는 불상사가 발생할 수 있다.  가급적이면 각 단계의 휴지통에 담긴 내용들은, 일정 주기에 자동으로 지워 지도록 설정하는 것이 좋다.

저장 공간 관리를 위한 용량 제한 템플릿 사용하기

비슷한 성격의 사이트 콜렉션들에 대해서 가급적 용량 제한 템플릿을 사용한다. 용량제한 템플릿들은 사이트 콜렉션에 저장 공간에 대한 제한을 일괄적으로 적용 할 수 있고, 용량이 부족하면 자동으로 관리자에게 이메일로 알림을 보낼 수 있다. 그러나, 템플릿이 적용/변경 되기 전에 만들어진 사이트들에서는 효과가 없다.

많은 문건을 가진 리스트 성능 관리하기.

문건이 지나치게 많은 리스트로 인해 리스트의 View 및 구조에 여러가지 문제를 일으킬 수 있다. 그 문제들에 대해 아래와 같이 대처하도록 한다.

• SharePoint 제품 군에서는 큰 사이즈의 리스트를 지원한다. 그러나, 반드시 사용자 View에서 발생되는 문제점들에 대해 적절한 문제 대응을 위한 설계가 필요하다.
• 많은 문건을 가지고 있는 리스트에서 View의 성능을 향상 시키려면, 리스트 내 한 개 또는 여러 개의 인덱스를 구성한다. 그리고 최소  한 개 이상의 인덱스 처리된 필드에  필터를 설정하도록 한다. 만일 여러 개 필드에 대해 필터를 설정하였다면, 많은 양의 문건을 필터시켜 주는 필터를 첫 번째로 하는 것이 좋다. 필터된 값들이 같아도, 전체적인 필터 성능이 향상 될 수 있기 때문이다.
• 큰 사이즈의 리스트에서 View를 만들 때, 최대 표시 수를5,000 개 보다 적은 수가 나올 수 있도록 하는 것이 좋다.
• 위에서 제시한 규칙을 적용한 View를 리스트의 기본 보기(View)로 설정한다.
• 큰 사이트의 리스트가 아니라면 리스트 단계(예를 들면, list의 root 부분 또는 단일 폴더 등) 에서 가급적 2,000개의 문건만 넣는 것이 좋다. 그래야 최소한의 성능 보장을 할 수 있다.
• 리스트 내 필드 개수가 몇 개인지를 파악하도록 한다. 너무 많은 수의 필드가 있으면 아이템 개수와는 별개로 성능 저하의 원인이 된다.

  
매우 큰 사이즈의 리스트로 설계했거나, 현재 구성되어 있다면, 다음 내용들을 참고할 것을 강력하게 권장한다.

• Manage lists and libraries with many items (http://go.microsoft.com/fwlink/?LinkID=105579&clcid=0x409)
• Working with large Lists in Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=105580&clcid=0x409)

이 자료는 SharePoint Product & Technologies Team Blog에서 보았던 자료 중 하나 입니다. 그 문서를 나름대로 멋대로 번역한 문서입니다. 이 번역 문서는 MS 공식이 아니므로 인용될 수 없습니다. 인용하시고 싶으시면, 원본 문서를 참조하시기 바랍니다. 해당 문서는 Word 문서로 되어 있으며 이 내용의 원본 백서(White Paper)는 http://go.microsoft.com/fwlink/?LinkID=105623&clcid=0x409 에서 다운로드 받을 수 있습니다.

서두

WSS 3.0 및 MOSS 2007의 성능은 Microsoft® SQL Server®의 설정, 데이터 입/출력(I/O)을 처리하는 서브 시스템의 성능에 따라 좌우 된다.( SharePoint 제품 군 및 기술에서 SharePoint란, Windows SharePoint Services 및 Office SharePoint Server 두 제품 모두를 의미한다.). 이 문서는 SharePoint 제품 군 및 기술과 관련된 각종 데이터 저장 관련 설정 및 감시 방법 중 권장하는 사항들을 기술한 내용이다.
SharePoint 제품 군 및 기술에서 가장 중요한 부분이라고 볼 수 있는 것은 바로 잘 만들어진 인프라 스트럭처 설계와 효과적인 감시 시스템, 그리고 잘 튜닝된 제품 환경이라고 볼 수 있다.
이를 위해 SharePoint 제품 군 및 기술 팀에서는 자체적인 투자를 하여 처음부터 끝까지 - 최초 SQL 서버 용량 산정에서부터 응용 프로그램 서버, 웹 프론트 엔드 서버 용량까지 - 가장 효율적인 용량에 대해 계산할 수 있도록 도와 줄 수 있도록 근거들을 마련 하였다.
이 근거를 마련하기 위해서 응용 프로그램 서버 및 웹 프론트 엔드 서버에 까지 부하를 주면서 다양한 사례로 부하를 주고, 동시에 SQL 서버 등 각 Farm을 감시하면서 가장 좋은 사례들을 추려 낸 것이다. 웹 프론트 엔드 서버에 요청 시 전체 응답에 소요되는 시간을 세세히 파악하여 보았으며, 웹 프론트 엔드 서버에서 일반 최종 사용자들을 최대 받아 들일 수 있는 용량, 웹 프론트 엔드 상에서 쌓이는 큐의 크기 및 용량 한도를 넘을 때 발생되는 각종 이벤트들을 파악할 수 있었다.

먼저 알아야 할 것과 준비 사항

하드웨어를 구매하기 전에, 제일 먼저 현실적인 정보 아키텍처를 구성할 필요가 있다( 정보들의 전체 논리적인 구조 및 대략적인 정보 사이즈). 그리고 SharePoint 제품 군 및 기술들과 SQL Server를 동작 시키기에 필요한 각종 요구사항에 따른 성능의 변화들을 판단해야 한다. 또한 이 배포 작업에는 반드시 관련된 자원 계획을 수립할 필요가 있다.
전체적인 배포 계획에 대한 자세한 지침 사항들은 아래의 내용들을 참고하도록 한다.

•    Planning and architecture for Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkID=105576&clcid=0x409)
•    Planning and architecture for Windows SharePoint Services 3.0 technology (http://go.microsoft.com/fwlink/?LinkID=105577&clcid=0x409)

만일 기존에 구축된 환경에서 업그레이드 하는 것이라면, WSS 3.0과 MOSS 2007로 업그레이드 되면서 더 다양해진 기능들 및 변경된 배경 기술들에 대해서 정확히 파악하고 있어야 한다. 특히 이전 버전에서 구축된 인프라 스트럭처 자원들에서 새로운 버전에서 추가적으로 요구되는 사항들에 대해 그 차이점들을 명확히 파악하고 대처할 수 있도록 준비하는 것이 중요하다.

설계에 고려되어야 할 사항

각 설계 중 주요한 사항을 나누면 아래의 3가지로 나눌 수 있다.
•    최적화된 성능
현재까지 대부분의 성능 향상의 작업은 하드웨어 외 적인 부분에서 찾을 수 있었다. 특히 자원의 병목현상과 같은 문제점 같은 경우, 대부분은 병목을 발생하는 원인을 정확히 파악할 수 있는 감시 시스템을 구축하고, 여유로운 자원 쪽으로 적절히 부하 분배를 할 수 있도록 구성하는 것이 중요하다. 대처가능 하도록 유연한 설계와 배포를 하면, 단순한 하드웨어 확장 같은 방법보다 훨씬 더 나은 결과를 가져올 수 있다.

•    규모 산정,
늘어나는 사용자 또는 사용자의 동선에 따른 변화 추이를 항상 파악할 수 있도록 한다. 이에 맞추어 별도 Farm을 재구성하지 않고도 추가적인 SQL 서버 구축, 저장 공간 추가, 및 사이트 와 SSP 추가 구축만으로 계속 확장 할 수 있도록 설계해야 한다. 또한 규모가 늘어나면서 서비스 중단 시간이 길어지는 문제에 대한 대처 방안에 대해서도 설계에 포함 시켜야 한다.

•    관리적인 측면
저장 장치에 대한 관리에 대해 설계 하도록 한다.  매일하는 관리 작업(백업을 수행하거나, SQL 서버 재 인덱싱 작업과 같은)
그리고 가끔 하는 작업(컨텐츠를 복원하거나, 원격 사이트 서비스 중단 복구 작업)으로 나누어 보다 편하게 작업 할 수 있도록 구성한다.

SPUser를 등록하는 방법은 사실 간단하다.

SPWeb.SiteUsers.Add("계정ID", "이메일주소", "보여줄 이름", "기타 메모")

위의 방법으로 사용하게 되면, 사용자 목록에 등록이 된다. 그러나 이렇게 등록하는 것으로는 해당 사용자가 사이트 내에서 제대로 활용할 수 없을 뿐더러 로그인 해봐야, 액세스 거부 창이나 팍팍 뜬다.

그러면 그 즈음 되서 권한 부분을 체크해 보게 된다.

게임은 지금 부터다.
그렇다면 이 권한 등록하는 방법들이 어떻게 있을까?

하나는 MOSS 2007에서 제공되는 그룹에 추가하는 방법이 있고, 다른 하나는 한사람 자체에 따로 권한을 주는 방식이다.

1. MOSS 2007에서 제공되는 그룹에 추가하는 방법
보통 그룹은 기본적으로 "사이트이름"+" 구성원", "사이트이름" + " 관리자" 형식으로 생성되어 진다.
그래서 보통 아래와 같은 형태로 짜기도 한다.

    SPGroup group = web.Groups["Members"];
    SPUser user = web.SiteUsers["KNOIE\\neohind"];
    group.AddUser(user);

그런데 그 그룹 이름이라는게 로컬라이즈 된 이름이라서 만일 "테스트 사이트" 라는 이름의 사이트에는 "테스트 사이트 구성원" 이런 식의 이름이 그룹이름이 된다. 객관적으로 좀 너무한 이름이지 않을까 싶다. 예제와 같은 이름이라면 위의 코드가 아래처럼 되어야 할 것이다.

   SPGroup group = web.Groups["테스트 사이트 구성원"];
   SPUser user = web.SiteUsers["KNOIE\\neohind"];
   group.AddUser(user);

좀... 너무 하지 않을까? 왠지 하드 코딩하는 기분을 지울 수 없고, 만일 어디에 포팅된다면.. 왠지 대박이지 않을까?
(저 같이 유지보수나 남아서 X 치우다 보면, 우울해집니다.)

그렇다면 어떻게 하면 좋을까?
이를 위해서 SPWeb에는 아래와 같이 관련 그룹에 대한 개체를 바로 꺼내 쓸 수 있는 부분이 있다

SPWeb.AssociatedOwnderGroup // ( 관리자 )

SPWeb.AssociatedMemberGroup  // ( 구성원 )

SPWeb.AssociatedVistorGroup // ( 방문자 )

즉 위의 예를 기준으로 변경해 보면 아래와 같은 코드가 된다.

  SPGroup group = web.AssociatedMemberGroup;
  SPUser user = web.SiteUsers["KNOIE\\neohind"];
  group.AddUser(user);

그 외 그룹(디자이너, 계층 구조 관리자)들은 알아서....

여튼 저 그룹에 Users 항목에 SPUser 형태로 더해 주면 된다. 그러면 자동으로 해당 권한을 할당해 줄 수 있다.

2. 개별 계정별 개별로 권한 매기기.

여기서 부터는 조금 복잡하게 돌아간다. 아마도 SPGroup에 특정 권한 쎄우려고 할 떄 사용하곤하는데, 이 또한 개별적으로 처리할 수 있다.

SPUser user = web.SiteUsers["KNOIE\\neohind"];
// 만일 관리자, 구성원, 방문자 단위가 아닌 기능별로 Roledefinition을 만드는 방법을 별도로 더 파악해야 함.
// 범위를 넘어가므로 여기서는 Contributor 즉, 구성원으로 권한을 설정.
SPRoleDefinition defContribute = web.RoleDefinitions.GetByType(SPRoleType.Contributor);
SPRoleAssignment roleContribute = new SPRoleAssignment(user as SPPrincipal);
roleContribute.RoleDefinitionBinding.Add(defContribute);
Web.RoleAssignments.Add(roleContribute);

위의  순서대로 보면 먼저 SPRoleDefinition을 생성 한다.
그리고 난 뒤 SPRoleAssignment를 생성한다. 여기서 생성할 때는 권한을 설정하려는 대상(보통 SPUser나 SPGroup)을 넣는다.
그리고 SPRoleAssgignment 내에 RoleDefinitionBinding에 앞서 만든 SPRoleDefinition을 추가한다.
맨 마지막으로 만들어진 SPRoleAssignment를 실제 권한을 설정하려는 Web, List, ListItem에 추가한다.