'분류 전체보기'에 해당되는 글 1246건

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 이 참조로 걸려 있어야 쓸 수 있다.!

어제 도착했다.

Microsoft Wireless Notebook Presenter Mouse 8000

나의 두번째 무선 마우스. 이번에는 수신기를 달기 싫어서 블루투스로 질렀다. 물론 수신기도 제공하는 모델로 구매했다.

하지만, 내 놋북에서 블루투스를 제공하므로 굳이 동굴이를 꽂을 필요가 없다는 사실.

그러나 단순한 무선 마우스를 구매하지 않았다.

바로 프리젠테이션 기능을 제공하는 마우스!!!!

프리젠테이션 모드에 들어가면 마우스 아랫쪽에 있는 버튼으로 프리젠테이션을 제어할 수 있다. (앞/뒤)

게다가 레이저 포인터도 나온다 !!!! ㅎㅎ

생각보다 블루투스의 감도는 그닥 좋지는 않지만, 그대로 만족스럽다.

강추보다는 한번 생각해보고 구매해보는 것이 좋다 정도?

일단 개인적으로는 마음에 든다. 조만간 있을 교육에 써먹어야 겠다 ㅋ

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

아... 개인적으로는 이 Jazz버전이 훨 나은듯...
나이를 먹어서인가...
들어보면 Jazz 버전 원본 노래의 가사는 그대로 사용하더군요  ㅋ

리믹스 버전 : Richard Cheese People = Shit

원곡 : SLIPKNOT People = Shit

이 자료는 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)

늘 버릇대로 내 홈페이지 주소를 브라우저에 입력하고, 혹시나 있을 댓글(사실 거의 한달에 한번? 그것도 친구 한 녀석만) 있을까봐, 혹시나 방명록에 누가 있을까바 해서 들렸다.

그런데.. 왠걸...트래픽 오버 페이지가 떴다...

이게.. 무슨 일인가 싶어서, 관리 페이지에 가보니, 내 제한 용량을 거의 다 잡아먹은 녀석을 발견했다.

79.166.10.147

어느 나라 녀석인지는 모르겠지만(워낙 컴퓨터 돌려 치기들을 잘해서리...) 왜 남의 서버에 찝적 거려서 오버 시키는 걸까...

뭘 도데체 다운 받길래 그랬나.. 의문이다.

일단 웹서버 상에서 막긴 했는데, 다른 IP로 또 오버 시키면... 어떻게 할까.. 고민중이다.

이 자료는 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 서버 재 인덱싱 작업과 같은)
그리고 가끔 하는 작업(컨텐츠를 복원하거나, 원격 사이트 서비스 중단 복구 작업)으로 나누어 보다 편하게 작업 할 수 있도록 구성한다.

다른 곳에서 구한 것은 아니고, MSDN 내의 Subscription을 통해 받은 RC1 입니다.이미 Vista가 나온 상태이기 때문에, 전체적인 UI 구성이나, 배치 등은 Vista에서 보여준 형태 거의그대로여서 큰 문제점은 없더군요.

우려 했던 드라이버 문제들도, 이미 나온 Vista 드라이버로 거의 설치가 되었습니다.(최소한 제 개인 개발 PC내의 드라이버에서는 문제가 없더군요)

Vista가 가지고 있던 클라이언트의 UI가 깨끗히 걷히고, 딱 필요한 부분만 적용된 것 같습니다.그리고 2003에서 처음 제시했던 서버 Role에 대한 페이지도 더 다양하게 제시되어 있어

훨씬 접근성도 좋더군요.
게다가, 2003에서 .NET 1.1이 미리 들어가 있던 것 처럼 이번 2008에는 2.0이 미리 들어가 있었습니다. 또한 3.0도 추가 옵션을 통해 더할 수 있었으며, WPF(Windows Presentation Framewrok) 및 WWF(Windows Workflow Framework)도 있더군요.

게다가 이번에 가장 놀라게 한 것은 IIS 7.0.
일단 기능 추가 부분에서 훨씬 다양한 조건들과 옵션들의 압박도 대단했지만,
iismgr ( IIS Manager )는 정말이지 걸작이다 싶습니다.
거의 완벽하게 UI 스럽게 뜯어 고쳐서, 자주 만져주지 않으면 정말이지 딴세상 가버릴듯 하더군요.

일단, Vista 기반의 드라이버와 프로그램들이라면, 2008을 쓰는데는 무리가 없어보입니다.
이제 MOSS 2007을 설치해 보고, 무엇이 부족한지 무엇이 좋은지를 차츰 확인해 보도록 하겠습니다.