디자인 예제: 회사 배포(SharePoint Server 2010)
적용 대상: SharePoint Foundation 2010, SharePoint Server 2010
마지막으로 수정된 항목: 2017-01-18
이 문서에서는 논리 아키텍처 구성 요소를 실제로 구현하여 실행 가능한 디자인을 얻는 방법에 대해 설명합니다. 이 문서는 다음 디자인 예제와 함께 사용하도록 작성되었습니다.
디자인 예제: 클래식 인증을 사용하는 회사 포털
디자인 예제: 클레임 기반 인증을 사용하는 회사 포털
이러한 모델을 다운로드하려면 SharePoint Server 2010 디자인 예제: 클래식 인증 또는 클레임 기반 인증을 사용하는 회사 포털(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=196872&clcid=0x412)(영문일 수 있음)을 참조하십시오.
이 문서의 내용:
디자인 예제 정보
전체 디자인 목표
서버 팜
사용자, 영역 및 인증
서비스
대안적 제작 및 게시 방법
관리 사이트
응용 프로그램 풀
웹 응용 프로그램
사이트 모음
콘텐츠 데이터베이스
영역 및 URL
영역 정책
이 디자인 예제에서는 Microsoft SharePoint Server 2010의 일반적인 기업 배포에 대해 설명합니다. 거의 모든 논리 아키텍처 구성 요소에 적용되는 이 디자인 예제에서는 이러한 구성 요소를 전체 디자인에 통합하는 방법을 다루고 있습니다. 두 예제는 동일한 서비스 및 사이트에 대해 설명하지만 다음과 같이 서로 다른 인증 방법이 통합되어 있습니다.
클래식 인증: 이 디자인 예제는 사이트를 Microsoft Office SharePoint Server 2007에서 Microsoft SharePoint Server 2010으로 업그레이드하기 위한 경로를 나타냅니다. 이 예제에는 사이트 액세스를 위해 Windows 인증 방법을 사용하는 클래식 인증이 통합되어 있습니다. 인증 방법마다 각기 다른 영역이 사용됩니다. Windows 인증을 SharePoint 사이트에 사용하는 경우 SharePoint Server 2010으로 전달되는 Windows 자격 증명을 수집하기 위해 폼 인증을 사용하도록 방화벽 또는 게이트웨이 제품을 구성할 수 있습니다. 파트너 직원 계정은 회사 디렉터리에 추가됩니다.
클레임 인증: 이 디자인 예제에는 새로운 클레임 인증 모델이 통합되어 있습니다. 또한 단일 영역에 여러 인증 공급자 및 인증 유형이 구현되어 있습니다. 클레임 인증에서는 폼 기반 인증, SAML 토큰 기반 인증 및 Windows 인증을 지원합니다. 이 디자인 예제에서는 SAML 토큰 기반 인증을 통해 파트너 디렉터리에 대해 직접 인증을 수행하여 파트너 회사를 추가합니다. 아울러 파트너 직원 계정을 위한 여러 가지 공급자 옵션을 사용할 수 있습니다.
특정한 인증 요구 사항이 가장 잘 반영된 디자인 예제를 사용합니다.
이 문서에서는 예제의 디자인 목표는 물론 예제에 나와 있는 논리 아키텍처 구성 요소를 사용하여 이러한 목표를 달성하는 방법에 대해서도 설명합니다.
디자인 예제 정보
이 디자인 예제에서는 Fabrikam, Inc.라는 가상의 회사에 대한 배포를 보여 줍니다. 배포 환경에는 두 개의 서버 팜이 포함됩니다. 서버 팜 하나는 회사 인트라넷 및 파트너 웹 사이트를 호스팅합니다. 다른 서버 팜은 회사 웹 사이트(www.fabrikam.com)를 호스팅합니다. 이 섹션의 나머지 부분에서는 다음과 같은 최상위 사이트에 대해 설명합니다.
인트라넷
회사 인트라넷에는 다음 사이트가 포함되어 있습니다.
HRweb 등의 게시된 인트라넷 콘텐츠
공동 작업 팀 사이트
내 사이트
직원은 이러한 모든 콘텐츠 및 공동 작업 사이트를 매일 사용하게 됩니다. 이러한 개별 응용 프로그램은 서로 다른 콘텐츠 형식을 나타냅니다. 각 콘텐츠 형식에는 다음과 같은 특징이 있습니다.
SharePoint Server 2010의 서로 다른 기능을 강조합니다.
데이터 특성이 서로 다른 데이터를 호스팅합니다.
서로 다른 사용 프로필에 종속됩니다.
서로 다른 사용 권한 관리 전략이 필요합니다.
따라서 이러한 각 응용 프로그램의 성능과 보안이 최적화되도록 각 응용 프로그램을 디자인해야 합니다.
서비스 응용 프로그램을 디자인하면 이러한 세 응용 프로그램을 통합하여 다음을 제공할 수 있습니다.
여러 응용 프로그램 간의 탐색
기업 전체 검색
공유 프로필 데이터 및 기업 메타데이터
다음 다이어그램에서는 회사 인트라넷을 구성하는 세 가지 응용 프로그램을 보여 줍니다.
.gif "인트라넷 사이트")
이 그림의 URL은 클래식 인증 디자인 예제에서 가져온 것입니다.
파트너 웹 응용 프로그램
파트너 웹 응용 프로그램은 파트너 회사 및 개별 파트너와 안전하게 공동 작업할 수 있는 외부에서 사용 가능한 사이트를 호스팅합니다. 직원은 이 응용 프로그램을 사용하여 보안이 유지되는 공동 작업 사이트를 손쉽게 만들 수 있습니다. 파트너는 서버 팜에서 호스팅되는 다른 콘텐츠 형식에 액세스할 수 없습니다. 영역 및 서비스 응용 프로그램 디자인에서는 이러한 목표를 다룹니다.
이 디자인 예제에서 파트너 웹 응용 프로그램은 인트라넷 콘텐츠를 호스팅하는 팜에 의해 호스팅됩니다.
회사 인터넷 사이트
회사 인터넷 사이트는 인터넷에서 회사를 소개하는 사이트입니다. 읽기 전용 권한을 갖는 익명 액세스를 구성하여 고객에게 콘텐츠를 제공합니다. 이 응용 프로그램을 디자인할 때 고려할 주요 사항은 다음과 같습니다.
콘텐츠 격리: 고객은 서버 팜에서 호스팅되는 다른 콘텐츠 형식에 액세스할 수 없습니다.
대상별 관리: 관리 및 제작 작업을 수행하는 웹 사이트 관리 직원에게는 인증된 액세스가 제공됩니다.
보안 콘텐츠 제작 및 게시: 팜 A의 파트너 웹 응용 프로그램에서 제작을 위한 별도의 사이트 모음이 호스팅됩니다. 이를 통해 내부 직원 및 원격 위치에 있는 직원뿐 아니라 웹 사이트 개발 또는 콘텐츠 제작을 전문으로 하는 편집 파트너도 공동 작업 및 콘텐츠 개발을 안전하게 수행할 수 있습니다. 콘텐츠 게시는 첫 번째 팜의 제작 사이트 모음에서 두 번째 팜의 프로덕션 사이트 모음으로 콘텐츠를 자동으로 게시하도록 구성됩니다. 다음 다이어그램에서는 게시 프로세스를 보여 줍니다.
.gif "게시된 사이트")
전체 디자인 목표
이 디자인 예제에서는 여러 일반적인 유형의 응용 프로그램 내에 SharePoint Server 2010의 기능을 실제로 구현합니다. 이 문서에서는 개별 응용 프로그램의 디자인 구현에 대해 설명합니다. 이 디자인 예제의 주요 디자인 목표는 다음과 같습니다.
최소한의 서버 팜을 사용하여 기업에서 흔히 필요로 하는 가장 일반적인 웹 사이트 유형인 인트라넷, 엑스트라넷 및 인터넷 사이트를 호스팅합니다.
확장 가능한 환경을 디자인하는 프레임워크를 만듭니다. 개별 응용 프로그램의 디자인 관련 사항을 결정할 때 다른 응용 프로그램을 추가할 수 있게 해야 합니다. 예를 들어 초기 배포에는 공동 작업 팀 사이트만 포함되거나 인트라넷을 구성하는 세 가지 응용 프로그램(팀 사이트, 내 사이트 및 게시된 인트라넷 콘텐츠)만 포함될 수 있습니다. 비슷한 논리 아키텍처 디자인을 사용하면 초기 응용 프로그램의 디자인에 영향을 주지 않고도 솔루션에 응용 프로그램을 추가할 수 있습니다. 즉, 환경을 사용하는 방법을 제한하는 요소는 디자인에 포함하지 않아야 합니다.
서로 다른 유형의 사이트 내에서 콘텐츠의 보안을 약화시키지 않으면서 여러 사용자 그룹에 액세스를 제공합니다. 네트워크 영역(내부 및 외부)과 인증 공급자가 서로 다른 여러 사용자가 공동 작업에 참여할 수 있습니다. 또한 사용자는 액세스 권한이 부여된 콘텐츠에만 액세스할 수 있습니다. 비슷한 논리 아키텍처 디자인에 따라 여러 위치에 있으며 작업 목표가 서로 다른 여러 사용자에게 액세스 권한을 제공할 수 있습니다. 예를 들어 초기 디자인에서 내부 직원에게만 액세스 권한을 부여하는 경우 비슷한 디자인을 사용하여 원격 위치에 있는 직원, 파트너 직원, 파트너 회사 및 고객에게 액세스 권한을 부여할 수도 있습니다.
엑스트라넷 환경에서 해당 디자인을 사용할 수 있어야 합니다. 경계 네트워크에 서버 팜을 안전하게 배포할 수 있도록 주의 깊게 디자인해야 합니다.
이 문서의 나머지 부분에서는 디자인 예제에 나타나는 각 논리적 구성 요소를 위쪽부터 아래쪽으로 설명하고 디자인 예제에 적용되는 디자인 선택 사항에 대해 논의합니다. 이런 식으로 설명하는 목적은 응용 프로그램에 따라 논리 아키텍처 구성 요소를 구성할 수 있는 다양한 방법을 보여 주기 위한 것입니다.
서버 팜
이 디자인 예제에서는 두 서버 팜을 통합하여 사용합니다. 이 섹션에서는 기업 환경에 필요한 서버 팜의 수에 영향을 주는 라이선스 요구 사항 및 디자인 예제에 나와 있는 서버 팜의 토폴로지에 대해 설명합니다.
라이선스 요구 사항
인트라넷 콘텐츠와 인터넷 사이트를 모두 호스팅하려면 라이선스 요구 사항을 충족하기 위해 최소 두 대의 서버가 필요합니다.
SharePoint Server 2010에서는 다음과 같은 두 개의 서버 라이선스를 사용할 수 있습니다.
Microsoft SharePoint Server 2010, Server License: 공동 작업 인트라넷 콘텐츠에 대한 라이선스입니다. 이 라이선스에는 CAL(클라이언트 액세스 라이선스)을 사용해야 합니다. 파트너 공동 작업용 사이트를 만드는 경우 파트너 직원에 맞는 개수의 CAL을 구입해야 합니다.
Microsoft SharePoint Server 2010 for Internet sites: 이 라이선스는 인터넷 연결 웹 사이트 전용입니다. 이 라이선스에는 CAL이 필요하지 않습니다. 파트너 공동 작업용 사이트를 만드는 경우 CAL을 추가로 구입할 필요가 없습니다. 이 경우 회사 직원만 사용할 수 있는 사이트는 만들 수 없습니다.
참고
이러한 라이선스는 같은 서버 컴퓨터 또는 같은 서버 팜에서 조합하여 사용할 수 없습니다.
라이선스 옵션이 결정된 후 가장 중요한 디자인 선택 사항은 파트너 웹 응용 프로그램을 호스팅할 팜을 결정하는 것입니다. 이 디자인 예제에서는 첫 번째 팜에서 인트라넷 콘텐츠를 호스팅하고 두 번째 팜에서 회사 인터넷 사이트를 호스팅합니다. 라이선스 조항에 따라 어느 쪽 팜에서든 파트너 웹 응용 프로그램을 호스팅할 수 있습니다.
두 팜을 선택한 후 파트너 웹 응용 프로그램을 호스팅할 팜을 결정할 때 적용되는 일반적인 디자인 지침은 다음과 같습니다.
공동 작업의 특성: 파트너 엑스트라넷 사이트에서 여러 파트너와 안전하게 정보를 주고받는 것이 주 목적인 경우 가장 경제적인 선택은 인터넷 서버 팜입니다. 반면 적은 인원의 파트너 직원과 공동으로 작업하는 것이 주 목적인 경우에는 인트라넷 서버 팜이 더 좋습니다. 의도된 역할에 맞게 팜을 최적화할 수 있는 옵션을 선택합니다.
파트너 직원의 수: 공동으로 작업하는 파트너 직원의 수가 많고 비용을 최소화해야 하는 경우 인터넷 사이트 라이선스를 사용하여 공동 작업 콘텐츠와 익명 콘텐츠를 모두 인터넷 연결 팜에서 안전하게 호스팅할 수 있습니다.
이 디자인 예제의 경우 파트너 웹 응용 프로그램에서 여러 파트너 회사와 함께 회사 인터넷 사이트 개발 및 준비를 비롯한 집중적인 공동 작업을 수행해야 합니다. 파트너 웹 응용 프로그램을 첫 번째 팜에 배치하면 조직에서 두 팜을 예정된 용도(공동 작업 및 읽기 전용 콘텐츠)에 맞게 최적화할 수 있습니다. 그러나 어느 쪽 팜에서든 파트너 웹 응용 프로그램을 호스팅할 수 있습니다.
이 디자인 예제에는 Microsoft Office Web Apps가 포함되어 있습니다. Office Web Apps를 사용하려면 Microsoft Office 2010 클라이언트 라이선스가 있어야 합니다. 즉, 파트너가 Office Web Apps를 사용할 수 있게 하려면 파트너를 위한 Office 2010 클라이언트 라이선스도 구입해야 합니다.
서버 팜 토폴로지
디자인 예제의 각 서버 팜은 다음과 같은 토폴로지가 사용된 서버 다섯 대로 구성되어 있습니다.
프런트 엔드 웹 서버 두 대
응용 프로그램 서버 하나
클러스터링 또는 미러링된 데이터베이스 서버 두 대
이 디자인 예제에서는 다음과 같은 SharePoint Server 2010의 논리 아키텍처를 보여 줍니다.
모든 사이트가 프런트 엔드 웹 서버 간에 미러링됩니다.
사용자가 직접 액세스할 수 없도록 중앙 관리 사이트가 응용 프로그램 서버에 설치됩니다.
실제 환경에서 서버 컴퓨터의 수와 서버 팜의 토폴로지는 필요에 따라 용량과 성능을 높이려는 경우를 제외하고 논리 아키텍처에서 중요하지 않습니다. 논리 아키텍처는 서버 팜 토폴로지에 관계없이 디자인할 수 있습니다. 성능 및 용량 계획을 세우면 성능 및 용량 목표에 맞게 서버 팜의 규모를 결정하는 데 도움이 됩니다. 자세한 내용은 성능 및 용량 관리(SharePoint Server 2010)를 참조하십시오.
세 개 이상의 팜으로 확장
기업에서 세 개 이상의 팜을 나타내야 하는 경우가 있을 수 있습니다. 전용 팜으로 사용할 수 있는 사이트는 다음과 같습니다.
내 사이트: 직원 또는 학생 수가 많은 여러 조직에서는 내 사이트를 전용 서버 팜에서 호스팅합니다.
제작 및 준비 사이트: 게시된 콘텐츠가 복잡하거나 포괄적인 경우 Microsoft SharePoint Server 2010 for Internet sites 라이선스를 사용하여 제작 및 준비 사이트를 전용 단일 서버 팜에서 호스팅하면 이러한 사이트를 보다 효과적으로 최적화할 수 있습니다. 예를 들어 태그가 지정된 메타데이터가 포함된 콘텐츠를 게시하면 제작 팜과 게시된 팜 간에 서비스 디자인 예제의 복잡도가 늘어날 수 있으며, 여기에는 팜 간에 서비스를 공유하는 문제와 다용도 팜에서 다른 웹 응용 프로그램 유형 간에 서비스를 공유하는 방식을 결정하는 부분 등이 포함됩니다.
파트너 사이트: 보안 및 격리 요구 사항이 있는 경우에는 파트너 공동 작업에 전용 팜을 사용해야 할 수 있습니다. 이렇게 하면 내부 전용 콘텐츠와 외부 파트너와의 공동 작업을 통해 개발되는 콘텐츠가 물리적으로 격리됩니다.
사용자, 영역 및 인증
SharePoint Server 2010에서 웹 응용 프로그램을 만드는 경우 클레임 기반 인증 또는 클래식 모드 인증 가운데 하나를 선택해야 합니다. 인증 모드에 따라 SharePoint Server 2010 내부에서 계정이 사용되는 방식이 결정됩니다. 다음 표에는 이러한 두 가지 방식이 요약되어 있습니다.
인증 유형 |
설명 |
권장 사항 |
클래식 모드 인증 |
사용자 계정이 SharePoint Server 2010에서 기존 Windows Active Directory 계정으로 취급됩니다. 또한 Kerberos, NTLM, 기본, 다이제스트 및 익명 같은 인증 프로토콜이 지원됩니다. 폼 기반 인증은 지원되지 않습니다. 영역당 하나의 인증 방법만 구성할 수 있습니다. |
클래식 모드는 폼 기반 인증을 사용할 필요가 없는 Microsoft Office SharePoint Server 2007에서 환경을 업그레이드하는 경우에 사용하는 것이 좋습니다. 클래식 모드 인증을 업그레이드 및 선택하는 경우에는 사용자 마이그레이션을 실행할 필요가 없습니다. |
클레임 기반 인증 |
사용자 계정이 SharePoint Server 2010에서 클레임 ID로 취급됩니다. Windows 계정은 자동으로 클레임 ID로 변환됩니다. 또한 이 모드에서는 폼 기반 인증 및 신뢰할 수 있는 ID 공급자 인증도 지원합니다. 단일 영역에 여러 인증 유형을 구성할 수 있습니다. |
클레임 기반 인증은 SharePoint Server 2010을 새로 배포하는 경우에 사용하는 것이 좋습니다. 또한 폼 기반 인증을 사용해야 하는 Office SharePoint Server 2007 솔루션을 업그레이드하는 경우에도 필요합니다. |
이 문서에서 설명하는 두 디자인 예제에는 이러한 두 가지 옵션이 나타나 있습니다. 다음 섹션에서는 두 디자인 예제에 인증이 통합된 방식에 대해 설명합니다.
클래식 모드 인증 디자인 예제
클래식 모드 인증을 사용하는 디자인 예제에는 이전 릴리스에 포함된 인증 유형당 하나의 영역을 사용하는 기존 접근 방식이 통합되어 있습니다. 따라서 이 예제에서는 Office SharePoint Server 2007을 SharePoint Server 2010으로 업그레이드하기 위한 경로를 제공합니다.
한 가지 주의할 사항은 클래식 모드에서는 폼 기반 인증이 지원되지 않는다는 점입니다. 클래식 모드 인증을 사용하는 경우에는 모든 인증된 계정이 AD DS(Active Directory Domain Services) 내에 있어야 합니다. 사이트에 원격으로 액세스하는 사용자는 방화벽 또는 게이트웨이 제품에서 폼 기반 인증을 사용하여 SharePoint 팜으로 전달되는 Windows 자격 증명을 수집하는 것이 좋습니다.
클래식 모드 예제에서는 서로 다른 영역에 할당된 네 가지 사용자 유형을 보여 줍니다. 각 웹 응용 프로그램 내에서 사용 가능한 영역 이름(기본, 인트라넷, 인터넷, 사용자 지정 또는 엑스트라넷) 중 하나를 사용하여 최대 다섯 개의 영역을 만들 수 있습니다.
다음 표에서는 클래식 모드 디자인 예제에 설명된 영역, 사용자 및 인증 유형을 보여 줍니다.
.gif "영역, 사용자 및 인증이 표시된 테이블")
검색 크롤링 계정은 NTLM 인증을 사용하여 하나 이상의 영역에 액세스해야 합니다. 사용자에 대해 NTLM을 사용하도록 구성된 영역이 없는 경우 NTLM 인증을 사용하도록 사용자 지정 영역을 구성합니다.
클레임 기반 인증 디자인 예제
클레임 기반 인증은 SharePoint Server 2010의 모든 새로운 배포에 사용하는 것이 좋으며 폼 기반 인증을 사용해야 하는 Office SharePoint Server 2007 솔루션을 업그레이드하는 경우에는 반드시 사용해야 합니다. 클레임 기반 인증을 사용하면 표준 Windows 인증 방법이 제공되는 것은 물론 다른 디렉터리, 즉 Windows Live ID, Active Directory Federation Services 2.0 또는 SAML 토큰 및 WS Federation 프로토콜을 지원하는 타사 ID 공급자 등에 대해 인증을 수행할 수 있습니다.
클레임 기반 인증 디자인 예제에서는 클레임 기반 인증이 공동 작업 팜에서 사용됩니다. 클레임 기반 인증을 사용하면 동일한 영역에서 여러 인증 유형을 사용할 수 있습니다. 이 디자인 예제에서는 모든 인증 유형에 대해 기본 영역을 사용합니다. 다음 표에서는 예제에서 공동 작업 팜에 대해 지정된 영역, 사용자 및 인증 유형을 보여 줍니다.
.gif "영역, 사용자 및 인증이 표시된 테이블")
이 디자인 예제에서 게시된 인트라넷 콘텐츠 사이트, 팀 사이트 및 내 사이트는 네트워크 내부 또는 외부에 있는 직원만 액세스할 수 있습니다. 이 디자인 예제에서는 내부 및 외부 모두에서 사용할 수 있는 하나의 URL(SSL 사용)만 구현합니다. Active Directory 계정이 사용되며, 필요한 경우 LDAP를 폼 기반 인증이나 SAML과 함께 사용할 수 있는데 이 경우 추가 구성 과정을 거처야 합니다.
이 디자인 예제에서 파트너 웹 응용 프로그램은 파트너 직원 및 파트너 회사에서 액세스할 수 있는 엑스트라넷 사이트를 나타냅니다. 이 시나리오에서 클레임 기반 인증을 사용하려면 하나 이상의 외부 STS(Secure Token Service)를 사용하여 트러스트를 구성해야 합니다. 이렇게 하려면 다음 접근 방식 중 하나를 사용해야 합니다.
Windows Live와 연결된 STS(개별 파트너 인증용) 또는 파트너 회사에 있는 STS(파트너 디렉터리 직접 인증용) 같은 외부 STS를 신뢰하도록 SharePoint 팜을 구성할 수 있습니다.
외부 STS를 신뢰하도록 회사 환경 내의 STS를 구성할 수 있습니다. 이러한 관계는 두 조직의 관리자가 명시적으로 설정해야 합니다. 이 시나리오에서 SharePoint 팜은 해당 회사 환경에 있는 STS만 신뢰하도록 구성됩니다. 이 내부 STS는 외부 STS로부터 수신하는 토큰을 확인한 다음 파트너 사용자가 SharePoint 팜에 액세스할 수 있도록 하는 토큰을 발급합니다. 가능한 한 이 방법을 사용하는 것이 좋습니다.
클레임 기반 환경을 구현하여 파트너를 인증하는 대신 폼 기반 인증을 사용하고 데이터베이스 같은 별도의 저장소를 통해 이러한 계정을 관리할 수도 있습니다.
클레임 기반 인증 환경을 구현하는 방법에 대한 자세한 내용은 Windows용 클레임 기반 ID: Active Directory Federation Services 2.0, Windows CardSpace 2.0 및 Windows Identity Foundation 소개(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=196776&clcid=0x412)(영문일 수 있음) 백서를 참조하십시오.
클레임 기반 인증 디자인 예제에서는 게시된 팜이 클래식 모드 인증을 사용하도록 설정됩니다. 이렇게 하는 대신 게시된 팜에도 클레임 기반 인증을 사용하고 익명 사용자를 위한 별도의 영역을 구현할 수도 있습니다. 디자인 과정에 고려해야 할 중요한 요소는 익명 사용자를 위한 별도의 영역을 사용하여 구현된 인증 모드에 관계없이 읽기 전용 환경과 읽기/쓰기 환경을 격리시키는 것입니다. 다음 표에서는 게시된 팜에 대해 설명된 영역, 사용자 및 인증 유형을 보여 줍니다.
.gif "영역, 사용자 및 인증이 표시된 테이블")
검색 크롤링 계정은 NTLM 인증을 사용하여 하나 이상의 영역에 액세스해야 합니다. 필요한 경우 NTLM 인증을 클레임 인증 영역에 추가할 수도 있습니다. 클래식 모드에서 사용자에 대해 NTLM을 사용하도록 구성된 영역이 없는 경우 NTLM 인증을 사용하도록 사용자 지정 영역을 구성합니다.
영역
영역을 디자인할 때는 성공적인 배포를 위해 몇 가지 주요 사항을 결정해야 합니다. 이러한 사항에는 다음 영역에 대한 디자인 및 구성 결정 사항이 포함됩니다.
기본 영역
외부 액세스용 영역
다음 섹션에서는 이 디자인 예제에 통합된 결정 사항에 대해 설명합니다.
기본 영역의 구성 요구 사항
가장 주의 깊게 고려해야 하는 영역은 기본 영역입니다. SharePoint Server 2010에서는 기본 영역을 구성하는 방법에 다음과 같은 요구 사항을 적용합니다.
사용자 요청을 특정 영역에 연결할 수 없는 경우 기본 영역의 인증 및 정책이 적용됩니다. 따라서 기본 영역은 가장 보안이 강화된 영역이어야 합니다.
관리 전자 메일은 기본 영역의 링크와 함께 전송됩니다. 여기에는 할당량 제한에 도달한 사이트 소유자의 전자 메일이 포함됩니다. 따라서 이러한 유형의 전자 메일 및 알림을 받는 사용자는 기본 영역을 통해 링크에 액세스할 수 있어야 합니다. 이는 사이트 소유자에게 특히 중요합니다.
호스트 이름이 지정된 사이트 모음은 기본 영역을 통해서만 사용할 수 있습니다. 호스트 이름이 지정된 사이트 모음에 액세스하려는 모든 사용자는 기본 영역을 통해 액세스할 수 있어야 합니다.
엑스트라넷 환경에 대한 영역 구성
엑스트라넷 환경에서는 다음과 같은 두 가지 이유로 인해 영역 디자인이 중요합니다.
서로 다른 여러 네트워크에서 사용자 요청이 시작될 수 있습니다. 이 디자인 예제에서는 사용자 요청이 내부 네트워크, 인터넷 및 파트너 회사에서 시작됩니다.
사용자가 여러 웹 응용 프로그램의 콘텐츠를 사용합니다. 이 디자인 예제에서 인트라넷은 서로 다른 세 가지 웹 응용 프로그램으로 구성되어 있습니다. 또한 내부 직원과 원격 직원은 모든 웹 응용 프로그램(인트라넷, 파트너 웹 및 회사 인터넷 사이트) 사이에서 콘텐츠를 제공 및 관리할 수 있습니다.
엑스트라넷 환경에서는 다음과 같은 디자인 원칙을 따라야 합니다.
여러 웹 응용 프로그램에서 영역을 서로 동일하게 구성합니다. 인증 구성과 의도된 사용자가 같아야 합니다. 그러나 영역에 연결된 정책은 웹 응용 프로그램에 따라 다를 수 있습니다. 예를 들어 인트라넷 영역은 모든 웹 응용 프로그램에서 동일한 직원을 위해 사용되어야 합니다. 즉, 인트라넷 영역을 특정 웹 응용 프로그램에서는 내부 직원용으로 구성하고 다른 웹 응용 프로그램에서는 원격 직원용으로 구성하지 말아야 합니다.
각 영역과 각 리소스에 대해 대체 액세스 매핑을 적절하고 정확하게 구성합니다. 영역을 만들면 대체 액세스 매핑이 자동으로 만들어집니다. 그러나 SharePoint Server 2010에서 파일 공유 등의 외부 리소스에 있는 콘텐츠를 크롤링하도록 구성할 수 있습니다. 각 영역에서 대체 액세스 매핑을 사용하여 이러한 외부 리소스에 대한 링크를 직접 만들어야 합니다.
웹 응용 프로그램 간에 영역이 서로 다르고 외부 리소스에 대한 링크가 적절하지 않으면 다음과 같은 위험이 따를 수 있습니다.
서버 이름, DNS(Domain Name System) 이름 및 IP 주소가 내부 네트워크의 외부로 노출될 수 있습니다.
사용자가 웹 사이트 및 기타 리소스에 액세스하지 못할 수 있습니다.
서비스
여기에 나와 있는 서비스 아키텍처에서는 서로 다른 세 사이트 유형(인트라넷, 파트너 웹 및 회사 인터넷 사이트)에 서비스를 배포하기 위한 가장 복잡한 옵션을 보여 줍니다. 파트너 웹 사이트에 대해서는 전용 및 분할된 서비스가 배포됩니다. 제작 사이트 모음 및 게시된 인터넷 사이트에서만 사용하도록 별도의 Managed Metadata Service 응용 프로그램 인스턴스가 배포됩니다.
이보다 훨씬 간단한 대안은 서비스 응용 프로그램 집합 하나를 배포하고 필요에 따라 사이트 간에 각 서비스를 공유하는 것입니다. 이 아키텍처에서는 보안 조정을 활용하여 사용자가 액세스할 수 있는 콘텐츠만 표시합니다. 다음 다이어그램에서는 이와 비슷한 접근 방식을 보여 줍니다.
.gif "서비스 아키텍처")
서비스 응용 프로그램을 배포하기 위한 주요 디자인 결정 사항은 조직 분류를 배분하는 범위입니다. 모든 웹 응용 프로그램에서 관리되는 메타데이터, 사용자 프로필 및 검색을 공유하고 보안 조정을 활용하여 콘텐츠에 대한 액세스를 관리하면 서비스 아키텍처를 단순화할 수 있습니다. 이 문서에 설명된 단순화된 아키텍처에서는 모든 사이트에서 Managed Metadata Service 인스턴스 하나를 공유합니다. 하지만 이 구성에서는 모든 사용자가 회사 분류에 액세스할 수 있습니다. 솔루션 설계자는 여러 개의 Managed Metadata Service 인스턴스를 구현할지 여부를 결정해야 합니다. 또한 사용자 프로필 데이터를 공유하는 범위도 결정해야 합니다.
파트너 웹 사이트
파트너 웹 사이트(팜 1의 사용자 지정 그룹)의 경우 이 디자인 예제에 설명된 최소한의 서비스는 Search Service와 Managed Metadata Service입니다. 파트너 웹 사이트에서 사용되는 서비스 그룹에 Office Web Apps를 추가하는 경우 파트너를 포함하여 이 사이트의 모든 사용자에 대한 적절한 라이선스를 가지고 있어야 합니다. 파트너 사용자가 조직에서 사용자 데이터를 검색하지 못하도록 하기 위해 이 디자인 예제에는 User Profile Service 응용 프로그램이 포함되어 있지 않습니다.
단순화된 아키텍처에서는 파트너가 전체 회사 분류에 액세스하고 조직에서 사용자 데이터를 검색할 수 있습니다. 하지만 검색 결과는 파트너가 액세스할 수 있는 사이트 및 콘텐츠로 제한됩니다.
파트너 사이트에서 프로젝트 간에 콘텐츠를 격리해야 하는 경우에는 이 디자인 예제에서처럼 전용 및 분할된 서비스 응용 프로그램을 배포하는 것이 좋습니다. 이렇게 하면 서비스 아키텍처의 복잡도가 늘어나지만 파트너가 인트라넷 콘텐츠와 연결된 메타데이터나 심지어 파트너 웹 사이트 내의 다른 프로젝트에도 액세스할 수 없게 됩니다.
회사 인터넷 사이트
단순화된 디자인 아키텍처에서는 회사의 Managed Metadata Service 응용 프로그램도 게시된 인터넷 사이트와 공유합니다. 이 디자인 예제에서는 제작 사이트 모음 및 게시된 팜에서만 사용하도록 공동 작업 팜에 전용 Managed Metadata Service 응용 프로그램 인스턴스가 배포됩니다.
게시된 팜이 익명이거나 읽기 전용인 경우에는 게시된 콘텐츠와 연결되지 않은 관리되는 메타데이터가 노출될 위험이 없습니다. 익명 사용자는 게시된 콘텐츠에만 액세스할 수 있으며 등급을 전송하거나 다른 메타데이터 유형을 만들 수는 없습니다.
이 문서의 단순화된 아키텍처에서처럼 조직 전반에 걸쳐 Managed Metadata Service 응용 프로그램을 공유하면 제작자가 회사 분류를 활용할 수 있게 됩니다. 이와 반대로 디자인 예제에서처럼 제작 및 게시를 위해 전용 서비스 인스턴스를 배포하면 관리되는 메타데이터가 격리됩니다.
회사 인터넷 사이트를 호스팅하는 팜에는 전용 Search Service 응용 프로그램 인스턴스가 배포됩니다. 이러한 구성은 게시된 인터넷 연결 사이트에 사용하는 것이 좋습니다.
대안적 제작 및 게시 방법
회사 인터넷 사이트의 경우 이 디자인 예제에서는 콘텐츠 배포 기능을 사용하여 콘텐츠를 제작 사이트 모음에서 게시 팜으로 옮기는 작업이 포함된 게시 프로세스를 설명합니다. 이보다 간단한 방식은 게시 팜에서 직접 제작하는 것인데, 이를 일반적으로 프로덕션 환경에서의 제작이라고 합니다.
프로덕션 환경에서 제작을 수행하면 하나의 팜에 서비스가 통합되고 콘텐츠를 배포할 필요성이 사라져 솔루션이 크게 단순해집니다. 이 디자인 예제에는 제작자가 익명 사용자에게 영향을 주지 않고 안전하게 작업하는 데 사용할 수 있는 추가 영역이 포함되어 있습니다. 이 경우 제작자가 사용하는 영역과 연결된 포트에서 들어오는 익명 액세스를 차단해야 합니다. 사이트에서 제작 작업 시간당 쓰기 횟수가 500회 미만인 경우에는 프로덕션 환경에서 제작을 수행하더라도 게시된 사이트의 성능에 영향이 발생할 가능성이 낮습니다.
SharePoint Server 2010에는 콘텐츠의 준비가 완료될 때까지 익명 사용자에게 해당 콘텐츠가 노출되지 않도록 하기 위해 이러한 시나리오에서 사용할 수 있는 게시 기능이 포함되어 있습니다. 자세한 내용은 다음 문서를 참조하십시오.
게시된 페이지의 시작 및 종료 날짜 일정 지정(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=196777&clcid=0x412)(영문일 수 있음)
전송 보류 중인 항목 승인 또는 거부(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=196778&clcid=0x412)(영문일 수 있음)
게시 권한 설정(영문일 수 있음)(https://go.microsoft.com/fwlink/?linkid=196779&clcid=0x412)(영문일 수 있음)
관리 사이트
이 디자인 예제에서 각 서버 팜의 중앙 관리 사이트는 응용 프로그램 서버에서 호스팅되므로 사용자는 중앙 관리 사이트에 직접 액세스할 수 없습니다. 성능 병목 현상이 발생하거나 보안 문제로 인해 프런트 엔드 웹 서버의 가용성이 영향을 받더라도 중앙 관리 사이트는 계속 사용 가능한 상태를 유지합니다.
관리 사이트에 대한 부하 분산 URL은 디자인 예제나 이 문서에서 설명되어 있지 않으며 다음과 같은 지침을 따르는 것이 좋습니다.
관리 URL에 포트 번호가 사용되는 경우 표준이 아닌 포트를 사용합니다. 포트 번호는 기본적으로 URL에 포함되어 있습니다. 고객 연결 URL에는 일반적으로 포트 번호가 사용되지 않지만 관리 사이트에 포트 번호를 사용하면 이러한 사이트에 대한 액세스가 표준이 아닌 포트로 제한되므로 보안이 강화될 수 있습니다.
관리 사이트에 대한 별도의 DNS 항목을 만듭니다.
이러한 지침 외에 여러 응용 프로그램 서버 간에 중앙 관리 사이트의 부하를 분산하여 중복을 구현할 수도 있습니다.
응용 프로그램 풀
일반적으로 서로 구분된 IIS(인터넷 정보 서비스) 응용 프로그램 풀을 구현하여 콘텐츠 간에 프로세스를 격리합니다. 응용 프로그램 풀을 통해 같은 서버 컴퓨터에서 여러 사이트를 실행하면서 자체 작업자 프로세스와 ID를 유지할 수 있습니다. 이렇게 하면 공격자가 한 사이트에서 다른 사이트를 공격하는 코드를 서버에 삽입할 위험이 감소합니다.
다음과 같은 시나리오에서는 전용 응용 프로그램 풀을 사용하는 것이 더 실용적입니다.
인증된 콘텐츠와 익명 콘텐츠를 구분하려는 경우
외부 비즈니스 응용 프로그램에 대한 암호를 저장하고 이러한 응용 프로그램과 상호 작용하는 응용 프로그램을 격리하려는 경우(대신 이를 위해 Secure Store Service를 사용할 수도 있음)
사용자가 자유롭게 사이트를 만들고 관리하며 콘텐츠에 대해 공동으로 작업할 수 있는 응용 프로그램을 격리하려는 경우
이 디자인 예제에서는 응용 프로그램 풀을 다음과 같이 사용합니다.
각 관리 사이트가 전용 응용 프로그램 풀에서 호스팅됩니다. 이는 SharePoint 2010 제품의 요구 사항입니다.
인트라넷 콘텐츠가 서로 다른 두 응용 프로그램 풀로 분할됩니다. 공동 작업 콘텐츠(내 사이트 및 팀 사이트)가 응용 프로그램 풀 하나에서 호스팅되고, 게시된 인트라넷 콘텐츠가 별도의 응용 프로그램 풀에서 호스팅됩니다. 이러한 구성을 활용하면 비즈니스 데이터 연결이 사용될 가능성이 더 높은 게시된 인트라넷 콘텐츠에 대해 프로세스가 격리됩니다.
파트너 웹 응용 프로그램은 전용 응용 프로그램 풀에서 호스팅됩니다.
회사 인터넷 사이트가 두 번째 팜의 전용 응용 프로그램 풀에서 호스팅됩니다. 이 팜에서 파트너 공동 작업용 콘텐츠도 호스팅하는 경우 이러한 두 가지 콘텐츠 형식(인터넷 및 파트너)을 서로 다른 두 응용 프로그램 풀에서 호스팅해야 합니다.
웹 응용 프로그램
웹 응용 프로그램은 SharePoint 2010 제품에서 만들고 사용하는 IIS 웹 사이트입니다. 각 웹 응용 프로그램은 IIS에서 서로 다른 웹 사이트로 나타납니다.
일반적으로 전용 웹 응용 프로그램을 사용하여 다음을 수행할 수 있습니다.
익명 콘텐츠를 인증된 콘텐츠와 구분. 이 디자인 예제에서는 회사 인터넷 사이트가 전용 웹 응용 프로그램 및 응용 프로그램 풀에서 호스팅됩니다.
사용자 격리. 이 디자인 예제에서는 파트너 웹 사이트가 전용 웹 응용 프로그램 및 응용 프로그램 풀에서 호스팅되므로 파트너가 인트라넷 콘텐츠에 액세스할 수 없습니다.
사용 권한 적용. 전용 웹 응용 프로그램을 통해 중앙 관리의 웹 응용 프로그램 정책 페이지를 사용하여 사용 권한을 정책별로 적용할 수 있습니다. 예를 들어 회사 인터넷 사이트에서 하나 이상의 사용자 그룹에 대해 쓰기 액세스 권한을 명시적으로 거부하는 정책을 만들 수 있습니다. 웹 응용 프로그램 정책은 웹 응용 프로그램 내에서 개별 사이트나 문서에 대해 구성된 사용 권한에 관계없이 적용됩니다.
성능 최적화. 웹 응용 프로그램에 데이터 특성이 비슷한 여러 응용 프로그램을 함께 배치하면 성능이 향상됩니다. 예를 들어 내 사이트의 데이터 특성에는 크기가 작은 수많은 사이트가 포함되는 반면 팀 사이트에는 일반적으로 적은 수의 대규모 사이트가 포함됩니다. 이렇게 서로 다른 두 가지 유형의 사이트를 별도의 웹 응용 프로그램에 배치하면 결과 데이터베이스가 특성이 서로 비슷한 데이터로 구성되므로 데이터베이스 성능이 최적화됩니다. 이 디자인 예제에서는 내 사이트와 팀 사이트에 대해 특별히 데이터를 격리할 필요가 없으므로 같은 응용 프로그램 풀이 공유됩니다. 그러나 성능을 최적화하기 위해 내 사이트와 팀 사이트를 별도의 웹 응용 프로그램에 배치합니다.
관리 효율성 최적화. 별도의 웹 응용 프로그램을 만들면 별도의 사이트 및 데이터베이스가 만들어지므로 서로 다른 사이트 제한(휴지통, 만료 및 크기)을 구현하고 서비스 수준 계약을 서로 다르게 조정할 수 있습니다. 예를 들어 조직 내에서 내 사이트 콘텐츠가 크게 중요하지 않은 경우 내 사이트 콘텐츠의 복원 시간을 더 길게 설정할 수 있습니다. 이렇게 하면 내 사이트 콘텐츠가 복원되기 전에 더 중요한 콘텐츠가 먼저 복원됩니다. 이 디자인 예제에서는 관리자가 다른 응용 프로그램보다 확장을 더 적극적으로 관리할 수 있도록 내 사이트를 별도의 웹 응용 프로그램에 배치합니다.
사이트 모음
사이트 모음은 논리 아키텍처와 정보 아키텍처를 서로 연결합니다. 디자인 예제에서 사이트 모음의 디자인 목표는 URL 디자인 요구 사항을 충족하고 콘텐츠를 논리적으로 분할하는 것입니다.
URL 디자인 요구 사항을 충족하기 위해 각 웹 응용 프로그램에는 단일 루트 수준 사이트 모음이 포함되어 있습니다. 관리 경로는 최상위 사이트 모음의 두 번째 계층을 통합하는 데 사용됩니다. URL 요구 사항 및 관리 경로를 사용하는 방법에 대한 자세한 내용은 이 문서 뒷부분의 "영역 및 URL"을 참조하십시오. 사이트 모음의 두 번째 계층 이후에 있는 각 사이트는 하위 사이트입니다.
다음 다이어그램에서는 팀 사이트의 사이트 계층 구조를 보여 줍니다.
.gif "팀 사이트")
루트 수준 사이트 모음에 대한 요구 사항이 결정되었으면 사이트 모음의 두 번째 계층을 중심으로 디자인을 결정해야 합니다. 이 디자인 예제에는 응용 프로그램의 특징에 따른 선택 내용이 적용되어 있습니다.
게시된 인트라넷 콘텐츠
게시된 인트라넷 콘텐츠 웹 응용 프로그램에서는 회사 내의 여러 부서에서 게시된 콘텐츠를 호스팅한다고 가정합니다. 이 디자인 예제에서는 각 부서의 콘텐츠가 별도의 사이트 모음에서 호스팅됩니다. 이 방법의 장점은 다음과 같습니다.
각 부서에서 자신의 콘텐츠를 독립적으로 관리하고 사용 권한을 부여할 수 있습니다.
각 부서의 콘텐츠를 전용 데이터베이스에 저장할 수 있습니다.
여러 사이트 모음을 사용하는 방법의 단점은 다음과 같습니다.
사이트 모음 간에 마스터 페이지, 페이지 레이아웃, 서식 파일, 웹 파트 및 탐색을 공유할 수 없습니다.
사이트 모음 간에 사용자 지정 내용 및 탐색을 조정하는 추가 작업을 수행해야 합니다.
정보 아키텍처 및 인트라넷 응용 프로그램의 디자인에 따라 게시된 콘텐츠를 사용자에게 단일 응용 프로그램으로 매끄럽게 표시할 수도 있고, 각 사이트 모음을 별도의 웹 사이트로 표시할 수도 있습니다.
내 사이트
내 사이트에는 독특한 특징이 있으며 내 사이트 배포와 관련된 지침은 단순합니다. 이 디자인 예제에서는 내 사이트 응용 프로그램에 URL이 http://my인 최상위 사이트가 통합되어 있습니다. 작성된 첫 번째 최상위 사이트 모음에는 내 사이트 호스트 서식 파일이 사용됩니다. 와일드카드 포함을 사용하여 관리 경로가 통합되므로 사용자가 만들 수 있는 사이트의 수에 제한이 없습니다. 관리 경로 아래의 모든 사이트는 내 사이트 호스트 서식 파일을 상속하는 독립된 사이트 모음입니다. 사용자 이름은 URL에 http://my personal/사용자 이름 형식으로 추가됩니다. 다음 그림에서는 내 사이트를 보여 줍니다.
.gif "내 사이트")
팀 사이트
다음 두 가지 방법 중 하나를 사용하여 팀 사이트 응용 프로그램 내의 사이트 모음을 디자인할 수 있습니다.
팀에서 셀프 서비스 사이트 만들기를 통해 사이트 모음을 만들 수 있도록 허용합니다. 이 방법의 장점은 팀에서 필요에 따라 손쉽게 사이트를 만들 수 있으며 관리자의 도움이 필요하지 않다는 점입니다. 그러나 이 방법에는 다음과 같은 여러 가지 단점이 있습니다.
자세한 분류를 구현할 수 없습니다.
응용 프로그램을 관리하기가 어려워질 수 있습니다.
사이트가 사용되지 않는 경우가 많습니다.
다른 방법을 사용하면 사이트 모음을 공유할 수도 있는 프로젝트나 팀 간에 서식 파일 및 탐색을 공유할 수 없습니다.
조직이 운영되는 방식에 따라 조직에 일정한 수의 사이트 모음을 만듭니다. 이 방식에서는 SharePoint 관리자가 사이트 모음을 만듭니다. 사이트 모음이 만들어지면 팀에서 필요에 따라 사이트 모음 내에 사이트를 만들 수 있습니다. 이 방법을 사용하면 팀 사이트의 관리 및 확장 방식을 체계화하는 정교한 사이트 구조를 구현할 수 있습니다. 또한 사이트 모음을 공유하는 프로젝트 및 팀 간에 서식 파일 및 탐색을 공유할 수 있는 기회가 더 많아집니다.
이 디자인 예제에서는 두 번째 방법을 사용하여 게시된 인트라넷 콘텐츠와 비슷한 사이트 모음 계층 구조를 팀 사이트에 적용합니다. 정보 설계자는 조직에 적합한 방식으로 사이트 모음의 두 번째 계층을 만들어야 합니다. 다음 표에서는 다양한 조직 유형에 대해 권장되는 구조를 보여 줍니다.
| 조직 유형 | 권장되는 사이트 모음 분류 |
|---|---|
제품 개발 |
|
리서치 |
|
고등 교육 기관 |
|
정부 기관 |
|
회사 법률 사무소 |
|
제조 |
|
파트너 웹 응용 프로그램
파트너 웹은 범위나 기간이 한정되어 있는 프로젝트에 대해 외부 파트너와 공동으로 작업하는 데 사용됩니다. 파트너 웹 응용 프로그램 내의 각 사이트는 서로 관련되지 않도록 디자인되어 있습니다. 파트너 웹 응용 프로그램에 대한 요구 사항은 다음과 같습니다.
프로젝트 소유자가 파트너 공동 작업용 사이트를 손쉽게 만들 수 있어야 합니다.
파트너 및 다른 참가자가 자신이 작업하는 프로젝트에만 액세스할 수 있어야 합니다.
사이트 소유자가 사용 권한을 관리해야 합니다.
프로젝트 중 하나에서 검색한 결과에 다른 프로젝트의 콘텐츠가 노출되지 않아야 합니다.
더 이상 사용되지 않는 사이트를 관리자가 손쉽게 식별하여 삭제할 수 있어야 합니다.
이러한 요구 사항을 충족하기 위해 이 디자인 예제에는 각 프로젝트에 대한 사이트 모음이 하나씩 포함되어 있습니다. 이렇게 하면 다음과 같은 이점이 있습니다.
개별 사이트 모음에서 프로젝트 사이에 적절한 격리 수준을 제공합니다.
셀프 서비스 사이트 만들기를 구현할 수 있습니다.
파트너 웹 응용 프로그램은 회사 인터넷 사이트용 콘텐츠를 개발하는 사이트 모음도 호스팅하므로 제작 및 준비를 위한 별도의 사이트 모음을 만듭니다.
회사 인터넷 사이트
회사 인터넷 사이트에는 단일 루트 수준 사이트 모음이 포함되어 있습니다. 이 사이트 모음 아래의 모든 사이트는 하위 사이트입니다. 이러한 구조를 사용하면 사이트 내의 페이지에 대한 URL이 간소화됩니다. 다음 다이어그램에서는 회사 인터넷 사이트의 아키텍처를 보여 줍니다.
.gif "회사 인터넷 사이트")
콘텐츠 데이터베이스
다음과 같은 두 가지 방법을 사용하여 콘텐츠 데이터베이스를 디자인에 통합할 수 있습니다. 이 디자인 예제에서는 두 가지 방법을 모두 사용합니다.
적절한 크기 경고 임계값을 사용하여 콘텐츠 데이터베이스의 대상 크기를 설정합니다. 크기 경고 임계값에 도달하면 새 데이터베이스를 만듭니다. 이 방법을 사용하면 대상 크기만을 기준으로, 사용 가능한 하나 이상의 데이터베이스에 사이트 모음이 자동으로 추가됩니다. 이는 가장 일반적으로 사용되는 방법입니다.
사이트 모음을 특정 콘텐츠 데이터베이스에 연결합니다. 이 방법을 사용하면 다른 데이터베이스와 독립적으로 관리할 수 있는 전용 데이터베이스에 하나 이상의 사이트 모음을 배치할 수 있습니다.
사이트 모음을 특정 콘텐츠 데이터베이스에 연결하려는 경우 다음과 같은 방법을 사용할 수 있습니다.
Windows PowerShell을 사용하여 특정 데이터베이스에 사이트 모음을 만듭니다.
다음과 같은 데이터베이스 용량 설정을 적용하여 데이터베이스를 단일 사이트 모음에만 할당합니다.
경고 이벤트가 생성되기 전 사이트 수 = 1
이 데이터베이스에서 만들 수 있는 최대 사이트 개수 = 1
다음 단계를 수행하여 전용 데이터베이스에 사이트 모음 그룹을 추가합니다.
웹 응용 프로그램 내에서 데이터베이스를 만들고 데이터베이스 상태를 준비로 설정합니다.
다른 모든 데이터베이스의 상태를 오프라인으로 설정합니다. 콘텐츠 데이터베이스가 오프라인 상태이면 새 사이트 모음을 만들 수 없지만, 오프라인 데이터베이스의 기존 사이트 모음에는 계속 액세스하여 읽기 및 쓰기 작업을 수행할 수 있습니다.
사이트 모음을 만듭니다. 사이트 모음이 데이터베이스에 자동으로 추가됩니다.
다른 모든 데이터베이스의 상태를 다시 준비로 설정합니다.
게시된 인트라넷 콘텐츠
게시된 인트라넷 콘텐츠의 경우 이 디자인 예제에는 관리 편의를 위해 단일 데이터베이스가 통합되어 있습니다. 필요한 경우 대상 크기 목표에 따라 데이터베이스를 추가합니다.
내 사이트
내 사이트의 경우 이 디자인 예제에서는 최대 대상 크기까지 데이터베이스를 관리하여 규모의 효율성을 구현합니다. 이 목표를 위해 설정을 다음과 같이 구성합니다.
사이트 저장 제한 용량: 이 설정은 중앙 관리의 할당량 지정 서식 파일 페이지에서 구성할 수 있으며 개인 사이트의 크기를 제한합니다.
2단계 휴지통: 이 설정은 웹 응용 프로그램 일반 설정 페이지에서 구성할 수 있으며 2단계 휴지통에 할당되는 추가 공간을 결정합니다.
이 데이터베이스에서 만들 수 있는 최대 사이트 개수: 이 설정은 데이터베이스를 만들 때 구성됩니다. 위에 있는 두 가지 값에 지정한 숫자를 사용하여 허용되는 총 사이트 크기를 계산합니다. 그런 다음 각 데이터베이스의 크기 목표에 따라 데이터베이스에 포함될 수 있는 사이트 수를 결정합니다.
이 디자인 예제에서는 대상 데이터베이스 크기를 200GB로, 내 사이트의 대상 크기를 1GB로 가정하고 다음과 같은 예제 크기 설정을 사용합니다.
사이트당 크기 제한 = 1GB
데이터베이스의 대상 크기 = 175GB
2단계 휴지통을 위해 예약된 비율 = 15%
최대 사이트 수 = 180
경고 전 사이트 수 = 150
경고 전 사이트 수에 도달하면 새 데이터베이스를 만들어야 합니다. 새 데이터베이스를 만들면 데이터베이스 중 하나의 최대 사이트 수에 도달할 때까지 새로 만드는 내 사이트가 새 데이터베이스와 기존 데이터베이스에 교대로 추가됩니다.
팀 사이트
팀 사이트의 경우 이 디자인 예제에서는 최대 대상 크기까지 데이터베이스를 관리하여 규모의 효율성을 구현합니다. 대부분의 조직에서 팀 사이트는 내 사이트보다 훨씬 커지게 됩니다. 이 디자인 예제에서 제공하는 데이터베이스 설정의 경우 사이트 모음의 제한을 30GB 기준으로 하지만, 실제 조직에서는 팀 사이트에 적합한 제한을 선택하십시오.
큰 저장 공간이 필요한 팀이 있는 조직에서는 각 최상위 팀 사이트 모음마다 전용 단일 데이터베이스를 할당할 수도 있습니다.
파트너 웹
내 사이트의 경우와 마찬가지로 파트너 웹에서는 데이터베이스를 최대 대상 크기까지 관리하여 규모의 효율성을 달성합니다. 그러나 이 디자인 예제에서는 파트너 웹에서 회사 인터넷 사이트에 대한 제작 사이트 모음도 호스팅하므로 데이터베이스 디자인에 다음과 같은 두 가지 방법이 모두 통합됩니다.
제작 사이트 모음이 전용 데이터베이스에서 호스팅됩니다.
다른 모든 사이트 및 데이터베이스를 관리하는 데이터베이스 및 크기 설정을 구성합니다.
파트너 웹은 전용 웹 응용 프로그램에서 호스팅되므로 작성된 사이트 유형에 보다 적합한 크기 제한을 만들 수 있습니다. 이 디자인 예제에서는 다음과 같은 예제 크기 설정을 사용합니다.
데이터베이스의 대상 크기 = 200GB
사이트당 저장소 할당량 = 5GB
최대 사이트 수 = 40
전용 데이터베이스에서 호스팅되는 제작 사이트 모음
회사 인터넷 사이트
회사 인터넷 사이트를 디자인할 때 단일 사이트 모음을 사용하면 이 웹 응용 프로그램에 단일 데이터베이스를 사용할 수 있습니다.
영역 및 URL
이 디자인 예제에서는 회사 배포에서 여러 응용 프로그램 간에 URL을 조정하는 방법을 보여 줍니다.
디자인 목표
다음 목표는 URL의 디자인과 관련된 결정에 영향을 줍니다.
콘텐츠에 액세스하는 데 사용할 수 있는 영역이 URL 규칙에 따라 제한되지 않습니다.
디자인 예제의 모든 응용 프로그램 간에 표준 HTTP 및 HTTPS 포트(80 및 443)를 사용할 수 있습니다.
URL에 포트 번호가 포함되지 않습니다. 실제 프로덕션 환경에서는 일반적으로 포트 번호가 사용되지 않습니다.
디자인 원칙
이러한 디자인 목표를 달성하려면 다음과 같은 디자인 원칙을 적용합니다.
호스트 이름이 지정된 사이트 모음을 사용하지 않습니다. 호스트 이름이 지정된 사이트 모음은 IIS 호스트 헤더와 다르며 대체 액세스 매핑 기능과 호환되지 않습니다. 여러 도메인 URL을 통해 동일한 콘텐츠에 액세스하려면 대체 액세스 매핑 기능이 필요합니다. 따라서 호스트 이름이 지정된 사이트를 사용하면 기본 영역을 통해서만 이러한 사이트를 사용할 수 있습니다.
각 응용 프로그램에는 단일 루트 사이트 모음이 포함되며, 이렇게 해야 대체 액세스 매핑을 사용할 수 있습니다. 웹 응용 프로그램 내에 여러 루트 사이트 모음이 필요하며 사용자 액세스용으로 기본 영역만 사용하려는 경우에는 호스트 이름이 지정된 사이트 모음을 사용하는 것이 좋습니다.
각 사이트 모음이 최상위 팀이나 프로젝트를 나타내는 팀 사이트 같은 높은 수준의 여러 사이트 모음이 포함된 응용 프로그램을 위해 이 디자인 예제에는 관리 경로가 포함되어 있습니다. 관리 경로를 사용하면 다음과 같은 사이트 유형의 URL을 보다 세밀하게 제어할 수 있습니다.
디자인 장단점
디자인 목표를 충족하면 다음을 비롯한 몇 가지 장단점이 있습니다.
URL이 길어집니다.
호스트 이름이 지정된 사이트 모음을 사용하지 않습니다.
부하 분산 URL 디자인
웹 응용 프로그램을 만들 때는 응용 프로그램에 할당할 부하 분산 URL을 선택해야 합니다. 또한 웹 응용 프로그램 내에 만드는 각 영역에 대한 부하 분산 URL을 만들어야 합니다. 부하 분산 URL에는 프로토콜, 체계, 호스트 이름 및 포트(사용되는 경우)가 포함됩니다. 부하 분산 URL은 모든 웹 응용 프로그램 및 영역 간에 고유해야 합니다. 따라서 각 응용 프로그램 및 각 응용 프로그램 내의 각 영역에는 디자인 예제 전체에서 고유한 URL이 필요합니다.
인트라넷
인트라넷을 구성하는 세 가지 웹 응용 프로그램에 각각 고유한 URL이 필요합니다. 이 디자인 예제에서 인트라넷 콘텐츠의 대상 그룹은 내부 직원 및 원격 직원입니다. 클레임 인증 디자인 예제에서는 직원이 현장에 있든 원거리에 있든 관계없이 이러한 각 응용 프로그램에 대해 동일한 URL을 사용합니다. 이 방식에서는 SharePoint 디자인(모든 트래픽이 SSL임)에 보안 계층이 추가되지만 방화벽 또는 게이트웨이 제품을 통해 원격 트래픽과 내부 트래픽을 함께 라우팅하거나 분할된 DNS 환경을 설정하여 내부 네트워크 내에서 내부 요청을 확인해야 합니다.
클래식 인증 디자인 예제의 경우 내부 직원과 원격 직원의 URL이 서로 다릅니다. 다음 표에서는 클래식 인증 디자인 예제에서 내부 및 원격 직원이 각 응용 프로그램에 액세스하는 데 사용하는 URL을 보여 줍니다.
| 응용 프로그램 | 내부 직원 URL | 원격 직원 URL |
|---|---|---|
게시된 인트라넷 콘텐츠 |
http://fabrikam |
https://intranet.fabrikam.com |
팀 사이트 |
http://teams |
https://teams.fabrikam.com |
내 사이트 |
http://my |
https://my.fabrikam.com |
파트너 웹 사이트
이 디자인 예제에서는 내부 직원, 원격 직원 및 파트너 직원이 파트너 웹 사이트에 액세스합니다. 클레임 인증 디자인 예제에서 이러한 각 사용자는 인증 방법에 관계없이 동일한 URL을 입력합니다. 클래식 인증 디자인 예제에서는 서로 다른 유형의 각 사용자가 각기 다른 URL을 입력합니다. 원격 직원과 파트너 직원이 모두 외부에서 SSL(HTTPS)을 사용하여 파트너 웹 사이트에 액세스하지만 별도의 영역을 사용할 때의 장점(서로 다른 인증 방법 및 영역 정책)을 적용하려면 그룹별로 각기 다른 URL이 필요합니다. 다음 표에서는 내부 직원, 원격 직원 및 파트너가 클래식 인증 디자인 예제에서처럼 파트너 웹 사이트에 액세스하는 데 사용하는 URL을 보여 줍니다.
| 영역 | URL |
|---|---|
내부 직원 URL |
http://partnerweb |
원격 직원 URL |
https://remotepartnerweb.fabrikam.com |
파트너 URL |
https://partnerweb.fabrikam.com |
회사 인터넷 사이트
회사 인터넷 사이트는 공용 사이트이며 모든 사용자가 기본 URL인 http://www.fabrikam.com을 사용하여 액세스할 수 있습니다. 이때 인터넷 영역의 정책인 익명 액세스 및 쓰기 거부가 적용됩니다.
그러나 공용 사이트에 대한 관리 및 제작 작업을 지원하기 위해 이 디자인 예제에는 내부 및 원격 직원용 URL이 포함되어 있습니다. 제작 및 관리 작업을 위해 대상 보안 그룹에 적절히 액세스할 수 있도록 이러한 영역에 정책을 사용할 수 있습니다. 클래식 인증 및 클레임 인증 디자인 예제 모두 이 팜에 대해 동일한 방법을 사용합니다. 다음 표에서는 각 영역의 URL을 보여 줍니다.
| 영역 | URL |
|---|---|
내부 직원 URL |
http://fabrikamsite |
원격 직원 URL |
https://fabrikamsite.fabrikam.com |
고객 URL |
http://www.fabrikam.com |
URL 경로에 명시적 포함 및 와일드카드 포함 사용
관리 경로를 정의하면 웹 응용 프로그램의 URL 네임스페이스에서 사이트 모음에 사용되는 경로를 지정할 수 있습니다. 루트 사이트 아래에 있는 별도의 경로에 하나 이상의 사이트 모음이 있도록 지정할 수 있습니다. 관리 경로를 사용하지 않는 경우 루트 사이트 모음 아래에 만드는 모든 사이트가 루트 사이트 모음의 일부가 됩니다.
다음과 같은 두 가지 유형의 관리 경로를 만들 수 있습니다.
명시적 포함: 명시적으로 할당된 URL이 적용된 사이트 모음입니다. 명시적 포함은 사이트 모음 하나에만 적용됩니다. 루트 사이트 모음 아래에 명시적 포함을 여러 개 만들 수 있습니다. 이 방법으로 만든 사이트 모음 URL의 예는 http://fabrikam/hr입니다. 경로를 명시적으로 추가할 때마다 성능에 영향이 발생하므로 명시적 포함을 통해 만드는 사이트의 모음의 수를 20개 정도로 제한하는 것이 좋습니다.
와일드카드 포함: URL에 추가되는 경로입니다. 이 경로는 경로 이름 바로 뒤에 지정된 모든 사이트가 고유 사이트 모음임을 나타냅니다. 이 옵션은 일반적으로 내 사이트와 같이 셀프 사이트 만들기를 지원하는 사이트 모음에 사용됩니다. 이 방법으로 만든 사이트 모음 URL의 예는 http://my/personal/user1입니다.
이 디자인 예제에서는 다음 섹션의 설명에 따라 두 가지 유형을 모두 사용합니다.
명시적 포함: 게시된 인트라넷 콘텐츠
이 디자인 예제에서 게시된 인트라넷 웹 응용 프로그램은 명시적 포함을 사용합니다.
게시된 인트라넷 콘텐츠
게시된 인트라넷 콘텐츠 웹 응용 프로그램 내의 각 하위 사이트인 HR, 시설 관리부 및 구매부에 명시적 포함이 사용됩니다. 필요한 경우 이러한 각 사이트 모음을 서로 다른 콘텐츠 데이터베이스와 연결할 수 있습니다. 이 예제에서 명시적 포함을 사용할 때는 웹 응용 프로그램에서 와일드카드 포함 같은 다른 유형의 사이트를 만들지 않는 것으로 가정합니다.
명시적 포함을 사용하여 만드는 사이트의 수는 20개 정도로 제한하는 것이 좋습니다. 조직에 이보다 많은 사이트 모음이 필요한 경우에는 와일드카드 포함 또는 호스트 이름이 지정된 사이트 모음을 사용하는 것이 좋습니다.
클래식 인증 디자인 예제에서는 명시적 포함을 사용하여 다음 표와 같은 URL을 만듭니다.
| 내부 직원(인트라넷 영역) | 원격 직원(기본 영역) |
|---|---|
http://fabrikam |
https://intranet.fabrikam.com |
http://fabrikam/hr |
https://intranet.fabrikam.com/hr |
http://fabrikam/facilities |
https://intranet.fabrikam.com/facilities |
http://fabrikam/purchasing |
https://intranet.fabrikam.com/purchasing |
이 예제에서 루트 사이트 모음인 http://fabrikam은 인트라넷의 기본 홈 페이지를 나타냅니다. 이 사이트는 사용자용 콘텐츠를 호스팅합니다.
와일드카드 포함: 팀 사이트, 내 사이트 및 파트너 웹
팀 사이트, 내 사이트 및 파트너 웹 응용 프로그램에서는 와일드카드 포함을 사용합니다. 와일드카드 포함은 사용자가 고유한 사이트 모음을 만들어야 하는 응용 프로그램 및 많은 사이트 모음이 포함된 웹 응용 프로그램에 적합합니다. 와일드카드 포함은 와일드카드 뒤에 나오는 다음 항목이 사이트 모음의 루트 사이트임을 나타냅니다.
팀 사이트
팀 사이트 응용 프로그램 내에서 각 팀 사이트 모음에 대해 와일드카드 포함이 사용됩니다. 최상위 팀 사이트의 수는 적절한 수준으로 유지하는 것이 좋습니다. 또한 팀 사이트를 비즈니스 운영 방식에 맞도록 논리적으로 분류해야 합니다.
클래식 인증 디자인 모드에서는 와일드카드 포함을 사용하여 다음 표와 같은 URL을 만듭니다.
| 내부 직원(인트라넷 영역) | 원격 직원(기본 영역) |
|---|---|
http://teams/sites/Team1 |
https://teams.fabrikam.com/sites/Team1 |
http://teams/sites/Team2 |
https://teams.fabrikam.com/sites/Team2 |
http://teams/sites/Team3 |
https://teams.fabrikam.com/sites/Team3 |
이 예제에서 루트 사이트 모음인 http://team에는 사용자용 콘텐츠가 호스팅되지 않을 수도 있습니다.
내 사이트
내 사이트는 셀프 서비스 사이트 만들기를 지원합니다. 인트라넷을 탐색하는 사용자가 내 사이트를 처음 클릭하면 해당 사용자에 대한 내 사이트가 자동으로 만들어집니다. 이 디자인 예제에서 내 사이트에는 /personal(http://my/personal)이라는 와일드카드 포함이 들어 있습니다. 내 사이트 기능에서는 URL에 사용자 이름을 자동으로 추가합니다.
클래식 인증 디자인 예제에서는 이를 통해 다음 표와 같은 형식의 URL이 만들어집니다.
| 내부(인트라넷 영역) | 원격 직원(기본 영역) |
|---|---|
http://my/personal/user1 |
https://my.fabrikam.com/personal/user1 |
http://my/personal/user2 |
https://my.fabrikam.com/personal/user2 |
http://my/personal/user3 |
https://my.fabrikam.com/personal/user3 |
파트너 웹 응용 프로그램
파트너 웹 응용 프로그램은 직원이 외부 파트너와 공동으로 작업할 수 있는 안전한 사이트를 손쉽게 만들 수 있도록 디자인됩니다. 이 목표를 지원하기 위해 셀프 서비스 사이트 만들기가 허용됩니다.
이 클래식 인증 디자인 예제에서는 파트너 웹 응용 프로그램에 /sites(http://partnerweb/sites)라는 와일드카드 포함이 들어 있습니다. 이를 통해 다음 표와 같은 형식의 URL이 만들어집니다.
| 내부 직원(인트라넷 영역) | 원격 직원(기본 영역) |
|---|---|
http://partnerweb/sites/project1 |
https://remotepartnerweb.fabrikam.com/sites/project1 |
http://partnerweb/sites/project2 |
https://remotepartnerweb.fabrikam.com/sites/project2 |
http://partnerweb/sites/project3 |
https://remotepartnerweb.fabrikam.com/sites/project3 |
파트너 참가자는 다음 표에 나와 있는 URL을 사용하여 파트너 웹 사이트에 액세스할 수 있습니다.
| 파트너(엑스트라넷 영역) |
|---|
https://partnerweb.fabrikam.com/sites/project1 |
https://partnerweb.fabrikam.com/sites/project2 |
https://partnerweb/fabrikam.com/sites/project3 |
이 디자인 예제에는 파트너 웹 응용 프로그램에 대한 예외가 나와 있습니다. 이러한 예외는 회사 인터넷 사이트용 콘텐츠를 제작하는 데 전용으로 할당된 사이트 모음입니다. 이 사이트 모음에는 명시적 포함이 사용됩니다. 이는 동일한 웹 응용 프로그램에서 명시적 포함과 와일드카드 포함을 모두 사용할 경우를 보여 주는 예입니다.
영역 정책
웹 응용 프로그램에 대한 정책을 만들어 웹 응용 프로그램 수준에서 사용 권한을 적용할 수 있습니다. 정책을 웹 응용 프로그램에 일반적으로 정의하거나 특정 영역에 대해서만 정의할 수 있습니다. 정책을 사용하면 웹 응용 프로그램이나 영역 내의 모든 콘텐츠에 사용 권한이 적용됩니다. 정책 사용 권한은 사이트 및 콘텐츠에 대해 구성된 다른 모든 보안 설정보다 우선합니다. 사용자 또는 사용자 그룹을 기준으로 정책을 구성할 수 있지만 SharePoint 그룹은 기준으로 사용할 수 없습니다. 영역 정책을 추가하거나 변경하는 경우 새 사용 권한을 선택하려면 검색을 통해 사이트를 다시 크롤링해야 합니다.
단일 영역에서 여러 유형의 인증을 사용하도록 설정하는 공동 작업 팜에 대한 클레임 인증 디자인 예제에서는 정책이 사용되지 않습니다. 정책은 클래식 인증 디자인 예제와 Windows 인증이 설명된 클레임 인증 디자인 예제의 게시된 팜에 구현됩니다. 게시된 팜에서 정책을 사용하면 익명 사용자와 사이트 관리를 위한 액세스 권한이 있는 사용자 간에 보안 계층이 추가됩니다.
이 디자인 예제에서는 다음을 위한 몇 가지 정책의 예를 보여 줍니다.
게시된 콘텐츠에 대한 쓰기 액세스 권한을 거부합니다.
제작자 및 테스터에게 게시된 콘텐츠에 대한 적절한 액세스 권한을 부여합니다.