'기술자료'에 해당되는 글 351건

MOSS 관련 도구를 ASPX로 만들때 종종 아래와 같은 SPException에 빠져 작업을 할 수 없는 경우가 있다.

"이 페이지에 대한 보안 유효성 검사가 잘못되었습니다. 웹 브라우저에서 [뒤로] 단추를 클릭하고 페이지를 새로 고친 다음 작업을 다시 시도하십시오." [ The security validation for this page is invalid. Click Back in your Web browser ]

초기에는 해당 페이지의 보안 유효성의 문제에 대한 정확한 정의를 알지 못해 오로지 짐작으로만 대략 파악하고 있어, 이에 대한 대처 방안이 전혀 없었다.
혼자 만의 짐작으로는 한개의 ASPX 내에서 너무 다양한 일을 수행하여 Page 자체의 Time-Out 이 걸렸거나, 아니면 SPList를 수정하는 도중 SPListItem의 설정을 동시에 수정하려 하거나 해서 발생하는 것이라 판단했었다.

그러나 어느것 하나 명확치 않았고, 더욱이 해결 방법이 너무 모호해서 알수 없었다.
이 중 헤딩 끝에 간신히 나름 '이거다!' 라고 판단 된 부분만을 언급하도록 하겠다.

1. 위치가 다른 자원을 접근 시도 할 때.
보통 관리용 ASPX 페이지를 작성 한 뒤, 이 페이지를 접근할 때 http://hostname/_layouts/xxxxx.aspx 이런 식으로 하게 된다. 그런데, 만일 저 xxxxx.aspx 페이지 내에 다른 사이트의 SPSite를 열어서 그 안의 값을 수정하는 경우에 바로 페이지 보안 오류가 발생한다.

다시 정리하자면, http://hostname/_layouts/xxxxx.aspx 를 띄운 뒤,
내부 코드에서 SPSite site = new SPSite("http://hostname/sites/childsite") 라는 코드가 들어 있고, 저 site 라는 변수를 통해 web을 얻고(site.RootWeb) 그 web의 Title을 수정하는 경우다.

즉 xxxx.aspx 페이지는 hostname 이라는 Site에서 띄운 것인데, xxxx.aspx 페이지안에서 처리하는 사이트는 hostname/sites/childsite 인 것이다. MOSS 입장에서는 hostname에 소속된 xxxx.aspx 페이지 주제에 다른 site의 자원을 접근하여 처리하는 것을 용납하지 못한다는 의미로 판단하면 된다.

이 경우, 여러 사이트의 자원을 일괄적으로 변경할 필요가 있다면, 별도 Windows Application으로 만들거나, STSADM에 명령어를 추가 구성해서 STSADM을 이용하여 변경하도록 한다.
만일 굳이 ASPX로 하고 싶다면, 저 ASPX에서 해당 사이트로 Redirect 하여, xxxx.aspx를 다시 띄우도록 한다.
즉 this.Response.Redirect("http://hostname/sites/childsite/_layouts/xxxxx.aspx") 라고 해서 xxxx.aspx를 다시 실행하는 것이다.

2. 페이지에 대한 401에러 대처 기능 부재.
아마도 대부분이 이 경우에서 걸리는 경우로 들 수 있다.
보통 application.master나 default.master와 같은 MOSS 내에서 제공되는 Master 페이지를 이용하여 구성하는 경우 이 에러가 발생하지 않는데, 유독 독자적인 ASPX 페이지를 만드는 경우 발생하게 된다. 즉 빈 ASPX 페이지를 만든 뒤, 그 안에 자신이 만든 각종 코드를 넣어 실행하면 바로 페이지 보안 오류가 발생하게 된다.
그렇다고 default.master나 application.master 를 쓰자니 디자인 커스터마이징 할 때는 쥐약인 것이다.

그럼 왜 default.master와 application.master를 끼면 괜찮고, 빈 ASPX 페이지로 구성하면 이런 문제가 발생하는 것일까? 그 이유는 바로 401 에러를 의도적으로 내는 MOSS의 문제로 판단된다.

HttpWatcher 라는 HTTP 프로토콜 송수신 패킷을 확인해 보면, MOSS에서는 항상 ASPX 페이지를 띄울 때 의도적으로 401 에러를 유발하게 되는데, 애석하게도 이 경우 페이지 내 코드에서는 모든 경우에 SPException으로 떨어지게 된다.
그렇다면 우리가 만들 ASPX 페이지에서는 이 에러를 피해 갈 수 없을까?

의외로 간단하게 해결 될 수 있다.
일단 우리가 만드는 ASPX 페이지내에 <form runat="server" /> 가 필요하다. ASPX 페이지를 만들었다면 당연히 들어 있겠지만, 혹시나 해서 언급한다. 일단 Server 컨트롤 로써 동작하는 <form>을 만들어 주고, 그 안에 

  <SharePoint:FormDigest runat=server/>

를 넣어주도록 한다. 그러면 최소한 401 에러가 떨어지는 부분에 대해서는 페이지 처리 없이 넘어가고 그 뒤에 실제 코드를 실행해 주게 된다.

몇가지 더 확인해보고 검토해봐야 겠지만, 위의 2가지 경우가 현재로는 대부분 발생되는 문제로 생각되며, 그 이후에 추가적으로 발견되면 리포트 하도록 할 예정이다.

보통 일반적인 게시판에서는 올린 글에 대해서는 누구든지 보게 된다.
또한 특정 글의 수정 작업은 자신이 작성한 항목에 대해서만 수행할 수 있게 된다.

그런데, 혹시 아래와 같은 기능이 필요할 수 있다.
1. 하나의 게시판을 여러사람이서 공유하지만, 마치 자신만의 글만 보이도록 하고 싶다.
2. 어떠한 글이든, 권한만 있으면 편집이 가능하다.
3. 모든 사용자가 아이템 자체를 편집 못하게 한다. ( 마감 처리 )

사실 1번과 같은 사항은 대개 View를 수정해서 자신이 작성한 글만 보이게 처리할 수 있다.
하지만, 만일 View를 바꿔 보게 되면 전체가 다 보이므로 1번의 조건에 합당하게 처리되지 않는다.  2번 같은 경우에는 글이나 문서가 공유되는 것이라서 팀 사이트 의 경우 팀 구성원이 원하는데로 수정가능한 경우를 의미한다.
3번의 경우는 해당 게시판의 만료적인 의미로 두면 되며, 더 이상 누구도

이 처리를 위한 방법은 SPList의 속성 중 아래의 2개의 프로퍼티가 이런 기능을 제공하게 된다.

 속성 내에 넣는 값
 1 - 모든 사용자가 모든 아이템을 읽을 수 있다.
 2 - 자신이 생성한 아이템에 대해서만 읽을 수 있다.

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

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

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

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

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

보통 ASP.NET 기반의 Web Application을 개발하다 보면, DLL들을 많이 이용하게 되는데,
만일 그 DLL의 일부 코드 수정을 반영 하려면 IIS 서비스를 다시 시작해야 한다.
그래서 보통 IISRESET.EXE 라는 명령어를 이용해 아예 서비스를 내렸다가,
다시 시작하곤 한다.

그러나 단순 DLL의 로직 몇가지 변경 때문에, IISRESET을 하기에는 비용이 비쌀 수 있다.
Web Publishing에 관련 된 대부분의 서비스를 내렸다가 다시 올리는 작업이기 때문에,
Reset 하는 시간도 많이 걸리는데다, IIS를 통해 데이터를 끌어 올리는 비용도 만만치 않다.

이에 IIS 6.0 대 부터는 Application Pool 이라는 것이 있어, 그 Application Pool 만
정리해 주면 새로운 DLL로 올려줄 수 있도록 제공하게 된다.

보통은 INETMGR을 띄워 해당하는 Application Pool 에서 오른쪽 버튼을 클릭해서 재생(혹은 Recycle)을 선택하면 되는데, UI 도구를 사용하는 것이라, 조작이 좀 귀찮긴 하다.

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