다음을 통해 공유

논리 아키텍처 모델: 기업 배포

  • 아티클

업데이트 날짜: 2009년 4월

적용 대상: Office SharePoint Server 2007

 

마지막으로 수정된 항목: 2015-03-09

이 문서의 내용

  • 모델 정보

  • 전체 디자인 목표

  • 서버 팜

  • 사용자, 영역 및 인증

  • SSP

  • 관리 사이트

  • 응용 프로그램 풀

  • 웹 응용 프로그램

  • 사이트 모음

  • 콘텐츠 데이터베이스

  • 영역 및 URL

  • 영역 정책

이 문서에서는 논리 아키텍처 구성 요소를 실제로 구현하여 작업 가능한 디자인을 구성하는 방법에 대해 설명합니다. 이 문서는 디자인 예제: 기업 배포 및 논리 아키텍처 (영문)(https://go.microsoft.com/fwlink/?linkid=82151&clcid=0x412)에 나와 있는 모델과 함께 사용해야 합니다.

이 모델에서는 Microsoft Office SharePoint Server 2007의 일반적인 기업 배포를 보여 줍니다. 이 모델은 거의 모든 논리 아키텍처 구성 요소에 적용되며 이러한 구성 요소를 전체 디자인에 통합하는 방법을 보여 줍니다. 이 문서에서는 모델의 디자인 목표는 물론, 모델에 나와 있는 논리 아키텍처 구성 요소를 사용하여 이러한 목표를 달성하는 방법에 대해서도 설명합니다.

모델 정보

이 모델에서는 Fabrikam, Inc라는 가상의 회사에 대한 기업 배포를 보여 줍니다. 배포 환경에는 두 개의 서버 팜이 포함되며, 서버 팜 하나는 회사 인트라넷과 파트너 웹 사이트를 호스팅하고 다른 하나는 회사 웹 사이트(www.fabrikam.com)를 호스팅합니다.

인트라넷

회사 인트라넷에는 다음 응용 프로그램이 포함되어 있습니다.

  • HRweb 등의 게시된 인트라넷 콘텐츠

  • 공동 작업 팀 사이트

  • 내 사이트

직원은 이러한 모든 콘텐츠 및 공동 작업 사이트를 매일 사용하게 됩니다. 이러한 개별 응용 프로그램은 서로 다른 콘텐츠 형식을 나타냅니다. 각 콘텐츠 형식에는 다음과 같은 특징이 있습니다.

  • Office SharePoint Server 2007의 서로 다른 기능을 강조합니다.

  • 데이터 특성이 서로 다른 데이터를 호스팅합니다.

  • 서로 다른 사용 프로필에 종속됩니다.

  • 서로 다른 사용 권한 관리 전략이 필요합니다.

따라서 이러한 각 응용 프로그램의 성능과 보안이 최적화되도록 각 응용 프로그램을 디자인해야 합니다.

단일 SSP(공유 서비스 공급자)를 사용하면 이러한 세 응용 프로그램을 통합하여 다음을 제공할 수 있습니다.

  • 여러 응용 프로그램 사이에서 탐색

  • 엔터프라이즈 수준 검색

  • 공유 프로필 데이터

다음 그림에서는 회사 인트라넷을 구성하는 세 가지 응용 프로그램을 보여 줍니다.

회사 모델용 논리적 아키텍처

파트너 웹

파트너 웹 응용 프로그램은 파트너 회사의 직원과 안전하게 공동 작업할 수 있는 외부에서 사용 가능한 사이트를 호스팅합니다. 이 응용 프로그램을 사용하여 보안 공동 작업 사이트를 손쉽게 만들 수 있습니다. 이 응용 프로그램을 디자인할 때 고려할 주요 사항은 다음과 같습니다.

  • **콘텐츠 격리   **파트너는 서버 팜에 호스팅되는 다른 콘텐츠 형식에 액세스할 수 없습니다. 또한 전용 SSP를 사용하여 다음과 같은 방법으로 콘텐츠를 추가로 격리할 수 있습니다.

    • 검색 범위를 사이트 수준으로만 제한

    • 사이트 모음 간 탐색 금지

    • 사이트 모음 간에 프로필 데이터를 사용할 수 없도록 금지

  • **파트너 계정을 별도로 인증   **파트너 계정은 폼 인증을 통해 관리되며 회사 디렉터리에 추가되지 않습니다.

  • **사용 권한 관리   **개별 사이트 소유자는 자신의 사이트에 대한 사용 권한을 관리하고 공동으로 작업할 참가자만 초대합니다.

이 모델에서 파트너 웹 응용 프로그램은 인트라넷 콘텐츠를 호스팅하는 팜에서 호스팅됩니다.

회사 인터넷 사이트

회사 인터넷 사이트는 인터넷에서 회사를 소개하는 위치입니다. 읽기 전용 권한을 갖는 익명 액세스를 구성하여 고객에게 콘텐츠를 제공합니다. 이 응용 프로그램을 디자인할 때 고려할 주요 사항은 다음과 같습니다.

  • 콘텐츠 격리   고객은 서버 팜에 호스팅되는 다른 콘텐츠 형식에 액세스할 수 없습니다.

  • 대상별 관리   관리, 제작 등의 작업을 수행하는 웹 사이트 관리 직원에게는 인증된 액세스가 제공됩니다.

  • 보안 콘텐츠 제작 및 게시   팜 A의 파트너 웹 응용 프로그램에 제작 및 준비를 위한 별도의 사이트 모음이 호스팅됩니다. 이를 통해 내부 직원 및 원격 위치에 있는 직원뿐 아니라 웹 사이트 개발 또는 콘텐츠 제작을 전문으로 하는 편집 파트너도 안전한 공동 작업 및 콘텐츠 개발을 수행할 수 있습니다. 콘텐츠 게시는 제작 사이트 모음에서 팜 A의 준비 사이트 모음으로, 팜 A의 준비 사이트 모음에서 팜 B의 프로덕션 사이트 모음으로 콘텐츠를 자동으로 게시하도록 구성됩니다. 다음 그림에서는 게시 과정을 보여 줍니다.

논리적 팜 아키텍처 - 게시 모델

전체 디자인 목표

이 모델에서는 몇 가지 일반적인 응용 프로그램 유형에서 Office SharePoint Server 2007 기능을 실제로 구현하는 방법을 보여 줍니다. 이 문서에서는 개별 응용 프로그램의 디자인 구현에 대해 설명합니다. 모델에 대한 주요 디자인 목표는 다음과 같습니다.

  • 최소한의 서버 팜을 사용하여 기업에 필요한 가장 일반적인 웹 사이트 유형인 인트라넷, 익스트라넷 및 인터넷 사이트를 호스팅합니다.

  • 확장 가능한 환경을 디자인하는 프레임워크를 만듭니다. 개별 응용 프로그램을 디자인할 때 다른 응용 프로그램을 추가할 수 있게 해야 합니다. 예를 들어 초기 배포에는 공동 작업 팀 사이트만 포함되거나 인트라넷을 구성하는 세 가지 응용 프로그램(팀 사이트, 내 사이트 및 게시된 인트라넷 콘텐츠)만 포함될 수 있습니다. 비슷한 논리 아키텍처 디자인을 사용하면 초기 응용 프로그램의 디자인에 영향을 주지 않고도 솔루션에 응용 프로그램을 추가할 수 있습니다. 즉, 환경을 사용하는 방법을 제한하는 요소는 디자인에 포함하지 말아야 합니다.

  • 서로 다른 응용 프로그램 내에서 콘텐츠의 보안을 약화시키지 않으면서 몇 가지 유형의 사용자에게 액세스를 제공합니다. 네트워크 영역(내부 및 외부)과 인증 공급자가 서로 다른 여러 사용자가 공동 작업에 참여할 수 있습니다. 또한 사용자는 액세스 권한이 부여된 콘텐츠에만 액세스할 수 있습니다. 비슷한 논리 아키텍처 디자인에 따라 여러 위치에 있으며 작업 목표가 서로 다른 여러 사용자에게 액세스 권한을 제공할 수 있습니다. 예를 들어 초기 디자인에서 내부 직원에게만 액세스 권한을 부여하는 경우 비슷한 디자인을 사용하여 원격 위치에 있는 직원, 파트너 직원 및 고객에게 액세스 권한을 부여할 수도 있습니다.

  • 익스트라넷 환경에서 해당 디자인을 사용할 수 있어야 합니다. 경계 네트워크에 서버 팜을 안전하게 배포할 수 있도록 주의 깊게 디자인해야 합니다.

이 문서의 나머지 부분에서는 모델에 나타나는 각 논리적 구성 요소를 위쪽부터 아래쪽으로 설명하고 모델에 적용되는 디자인 선택 사항에 대해 논의합니다. 이런 식으로 설명하는 목적은 응용 프로그램에 따라 논리 아키텍처 구성 요소를 구성할 수 있는 다양한 방법을 보여 주기 위한 것입니다.

서버 팜

이 모델에서는 두 서버 팜을 통합하여 사용합니다. 이 섹션에서는 기업 환경에 필요한 서버 팜의 개수에 영향을 주는 라이선스 요구 사항 및 모델에 나와 있는 서버 팜의 토폴로지에 대해 설명합니다.

라이선스 요구 사항

참고

이전 라이선스 요구 사항에서는 인트라넷 콘텐츠 및 인터넷 사이트를 호스팅하는 데 최소 두 개의 서버(각 라이선스 유형에 대해 서버 하나씩)를 사용해야 한다고 지정했습니다. 이제는 그렇지 않습니다. 이 섹션은 2008년 9월에 구현된 새로운 라이선스 요구 사항을 반영하도록 업데이트되었습니다.

Office SharePoint Server 2007에서는 다음과 같이 두 개의 서버 라이선스를 사용할 수 있습니다. 이러한 라이선스를 같은 서버 팜의 같은 서버 컴퓨터에 결합하여 사용할 수 있습니다.

  • Microsoft Office SharePoint Server 2007, Server License   인트라넷 콘텐츠에 대한 라이선스입니다. 이 라이선스에는 CAL(클라이언트 액세스 라이선스)을 사용해야 합니다. 파트너 공동 작업용 사이트를 만드는 경우 파트너 직원에 맞는 개수의 CAL을 구입해야 합니다.

  • **Microsoft Office SharePoint Server 2007 for Internet sites   **이 라이선스는 인터넷 연결 웹 사이트 전용입니다. 이 라이선스에는 CAL이 필요하지 않습니다. 파트너 공동 작업용 사이트를 만드는 경우 CAL을 추가로 구입할 필요가 없습니다. 이 경우 회사 직원만 사용할 수 있는 사이트는 만들 수 없습니다.

조직에 대해서는 내부 콘텐츠를 배포하고, 동일한 팜의 직원이 아닌 사용자에 대해서는 인터넷 연결 콘텐츠를 배포하려는 경우에는 해당 팜에 대해 두 유형의 라이선스를 모두 구입해야 합니다. 가능한 배포 시나리오의 해결 방법으로, 단일 배포를 통해 Office SharePoint Server 2007 요구를 통합하려는 고객은 두 제품에 대한 라이선스를 구매하고 이 라이선스를 동일 서버에 할당한 다음 두 라이선스를 사용하여 동시에 소프트웨어의 동일한 실행 인스턴스를 사용할 수 있습니다. 그러나 고객은 인터넷 사이트 사용 권한에 대해 Office SharePoint Server 2007에서는 허용되지 않는 방식으로 콘텐츠에 액세스하는 사용자 및 장치에 대해 Office SharePoint Server 2007 사용 권한에서 필요한 CAL을 구입해야 합니다.

라이선스 요구 사항이 필요한 서버 팜 수에 미치는 영향에 대한 자세한 내용은 서버 팜 계획을 참조하십시오.

서버 팜 하나만 필요한 경우이더라도 이 모델에서는 서버 팜 두 개(내부 콘텐츠용 및 고객 배포 콘텐츠용)를 사용하는 경우에 대해 설명합니다. 두 개의 별도 팜을 구현하도록 선택한 경우 가장 중요한 디자인 선택 사항은 파트너 웹 응용 프로그램을 호스트할 팜을 결정하는 것입니다. 이 모델에서는 서버 팜 A가 인트라넷 콘텐츠를 호스트하고 서버 팜 B가 회사 인터넷 사이트를 호스트합니다. 라이선스 조항에 따라 두 팜은 모두 파트너 웹을 호스트할 수 있습니다.

두 팜을 선택한 후 파트너 웹 응용 프로그램을 호스팅할 팜을 결정할 때 일반적인 디자인 지침은 다음과 같습니다.

  • 공동 작업의 특성   파트너 익스트라넷 사이트에서 여러 파트너와 안전하게 정보를 주고받는 것이 주 목적인 경우 가장 경제적인 선택은 인터넷 서버 팜입니다. 반면 적은 인원의 파트너 직원과 공동으로 작업하는 것이 주 목적인 경우에는 인트라넷 서버 팜이 더 좋습니다. 의도된 역할(공동 작업 및 읽기 전용 콘텐츠)에 맞게 팜을 최적화할 수 있는 옵션을 선택합니다.

  • 파트너 직원의 수   공동으로 작업하는 파트너 직원의 수가 많고 비용을 최소화해야 하는 경우 공동 작업 콘텐츠와 익명 콘텐츠 모두를 인터넷 사이트 라이선스가 있는 인터넷 연결 팜에 안전하게 호스팅할 수 있습니다.

이 모델의 경우 파트너 웹에서 여러 파트너 회사와 기업 인터넷 사이트 개발 및 준비를 비롯한 집중적인 공동 작업을 수행해야 합니다. 파트너 웹을 팜 A에 배치하면 조직에서 두 팜을 의도된 용도(공동 작업 및 읽기 전용 콘텐츠)에 맞게 최적화할 수 있습니다.

조직에 적합한 개수의 팜을 선택하는 방법 및 라이선스 요구 사항에 대한 자세한 내용은 서버 팜 계획을 참조하십시오.

서버 팜 토폴로지

모델의 각 서버 팜은 다음과 같은 토폴로지가 사용된 서버 다섯 대로 구성되어 있습니다.

  • 프런트 엔드 웹 서버 두 개

  • 응용 프로그램 서버 하나

  • 클러스터링 또는 미러링된 데이터베이스 서버 두 개

이 모델에서는 다음과 같은 방식으로 Office SharePoint Server 2007의 논리 아키텍처를 보여 줍니다.

  • 모든 사이트가 프런트 엔드 웹 서버 간에 미러링됩니다.

  • 사용자가 직접 액세스할 수 없도록 중앙 관리 사이트가 응용 프로그램 서버에 설치됩니다.

실제 환경에서 서버 컴퓨터의 수와 서버 팜의 토폴로지는 필요에 따라 용량과 성능을 높이려는 경우를 제외하고 논리 아키텍처에서 중요하지 않습니다. 논리 아키텍처는 서버 팜 토폴로지에 관계없이 디자인할 수 있습니다. 성능 및 용량 계획을 세우면 성능 및 용량 목표에 맞게 서버 팜의 규모를 결정할 수 있습니다. 자세한 내용은 성능 및 용량 계획(Office SharePoint Server)을 참조하십시오.

사용자, 영역 및 인증

이 모델에서는 서로 다른 영역에 할당된 다섯 가지 사용자 유형을 보여 줍니다. 각 웹 응용 프로그램 내에서 사용 가능한 영역 이름(기본, 인트라넷, 인터넷, 사용자 지정 또는 익스트라넷) 중 하나를 사용하여 최대 다섯 개의 영역을 만들 수 있습니다. 둘 이상의 웹 응용 프로그램을 호스팅하는 팜에서는 여섯 가지 이상의 네트워크 영역(웹 응용 프로그램당 최대 다섯 가지 영역)에서 들어오는 사용자 요청을 지원할 수 있습니다. 그러나 이 모델에서는 다섯 가지 영역만 보여 줍니다.

사용자 및 인증

이 모델에서는 서로 다른 네트워크 영역의 사용자를 보여 주며, 관리자의 경우 사용 권한 요구 사항이 크게 다른 여러 사용자를 보여 줍니다. 또한 여러 사용자 간에 인증을 적용하는 방법을 보여 줍니다. 다음 표에서는 각 영역에서 사용자를 인증하는 방법을 나열합니다.

영역 사용자 인증

사용자 지정

관리자

Kerberos(Windows 통합)

인트라넷

내부 직원

NTLM(Windows 통합)

기본

원격 직원

NTLM(Windows 통합) 또는 LDAP(Lightweight Directory Access Protocol)를 사용한 폼 인증

익스트라넷

파트너 직원

폼 인증

인터넷

고객

익명

이 모델에서 모든 사용자에게 두 서버 팜에 대한 액세스 권한이 부여되지는 않습니다. 따라서 어느 팜에서도 다섯 가지 영역을 모두 사용하지 않습니다.

관리자

사용자 지정 영역은 사이트에 대한 보안 관리 액세스에 사용됩니다. 이러한 방식을 통해 다음을 수행할 수 있습니다.

  • URL 및 정책 집합을 독립적으로 구현할 수 있습니다. 예를 들어 관리자는 사용자 지정 영역에 연결된 URL을 사용하여 영역의 정책에 따라 관리 작업을 수행할 수 있으며, 인트라넷 URL을 사용하여 인트라넷을 구성하는 응용 프로그램에 구성된 정책에 따라 기타 모든 작업을 수행할 수 있습니다. 이러한 방식을 사용하면 두 컨텍스트가 분리되고 정책 권한이 서로 충돌하지 않습니다.

  • 보다 안전한 방법으로 관리자를 인증할 수 있습니다. 따라서 전체 솔루션의 보안이 강화됩니다.

  • 외부 공급업체에서 사이트를 지원하는 경우 다른 공급자에 대해 인증할 수 있습니다.

이 모델에서는 관리자가 Fabrikam의 직원이며 내부에서 네트워크에 액세스할 수 있다고 가정하고 관리자에 대해 Windows 통합 인증(Kerberos 인증 또는 NTLM)을 사용합니다.

내부 직원

인트라넷 영역은 내부 직원 액세스용으로 사용됩니다. 이때 Windows 통합 인증이 사용됩니다.

원격 직원

기본 영역은 원격 직원 액세스용으로 사용됩니다. 모델의 디자인 목표는 다음과 같습니다.

  • 내부 Active Directory 디렉터리 서비스 환경에 대해 인증합니다.

  • 내부 직원과 원격 직원 모두에 대해 Windows 인증을 사용하여 권한 관리를 간소화합니다. 이 목표가 중요한 이유는 사용자가 서로 다른 두 가지 인증 공급자를 통해 사이트에 연결할 경우 Office SharePoint Server 2007에서 각 사용자에 대해 서로 다른 두 계정을 만들며 두 계정에 모두 사용 권한이 있어야 하기 때문입니다.

이 모델에는 원격 직원을 인증하는 서로 다른 두 가지 옵션이 나와 있습니다. 첫 번째 옵션(NTLM을 사용한 Windows 통합 인증)을 사용하면 두 가지 디자인 목표가 모두 달성되며, 두 번째 옵션(폼 인증)을 사용하면 첫 번째 목표만 달성됩니다. 따라서 첫 번째 옵션을 사용하는 것이 좋습니다.

다음 표에는 두 가지 방식의 차이점이 설명되어 있습니다.

인증 방법 NTLM을 사용한 Windows 통합 인증 LDAP 공급자를 사용한 폼 인증

작동 방식

이 방법에서는 ISA Server를 사용하여 사용자를 인증한 다음 사용자 자격 증명을 Office SharePoint Server 2007에 전송합니다. ISA Server에서는 폼 인증을 사용하여 Active Directory 환경에 대해 사용자를 인증합니다. 그런 다음 ISA는 Windows 자격 증명을 Office SharePoint Server 2007에 전달합니다. 자세한 내용은 다음 리소스를 참조하십시오.

영역이 기본 영역이므로 인덱스 구성 요소의 요구 사항을 충족하기 위해 NTLM 인증이 사용됩니다. 자세한 내용은 이 문서의 뒷부분에서 "기본 영역의 구성 요구 사항"을 참조하십시오.

Office SharePoint Server 2007에서는 LDAP 공급자와 함께 폼 인증을 사용하여 내부 Active Directory 환경에 대해 원격 직원을 인증합니다.

이 방법을 선택하는 경우 인덱스 구성 요소에서 대체 영역을 통해 인증할 수 있는지 확인해야 합니다. 자세한 내용은 이 문서의 뒷부분에서 "기본 영역의 구성 요구 사항"을 참조하십시오.

장점

내부에서도 작업하고 원격으로도 작업하는 사용자에 대해 Office SharePoint Server 2007에서 서로 다른 두 계정을 만들지 않습니다. 따라서 사용 권한 관리가 크게 간소화됩니다.

프록시 서버에서 사용자를 인증하고 자격 증명을 전달할 필요가 없습니다.

단점

ISA Server 2006 또는 기타 프록시 서버 제품에 맞게 조정하고 이러한 제품을 구성해야 합니다.

사용자가 내부 및 원격 위치에서 Office SharePoint Server 2007에 연결하는 경우 Office SharePoint Server 2007에서 서로 다른 두 사용자 계정이 만들어집니다. 따라서 두 계정에 사이트 및 문서에 대한 사용 권한이 필요하며 직원이 내 사이트를 두 개 만들 수 있습니다. 내부 네트워크와 원격 위치에서 모두 작업하려는 직원은 자신의 사이트 및 문서에 대한 사용 권한을 두 사용자 계정 모두에서 관리해야 합니다.

파트너 직원

파트너 직원은 익스트라넷 영역을 통해 네트워크에 액세스하며 폼 인증을 사용하여 인증됩니다. 따라서 익스트라넷에 파트너 계정을 저장할 Microsoft SQL Server 데이터베이스 및 공급자와 같은 별도의 디렉터리 및 공급자가 필요합니다. 이 방법의 장점은 파트너 계정을 별도로 관리할 수 있으며 내부 직원 디렉터리에 파트너 계정을 추가할 필요가 없다는 점입니다.

또는 웹 SSO(Single Sign-On)를 사용하여 파트너의 자체 디렉터리에 대해 인증할 수 있습니다. 그러나 이 방법을 사용하려면 각 파트너 디렉터리에 별도의 영역이 필요합니다.

이 모델에서는 Fabrikam이 같은 파트너 응용 프로그램 내에서 서로 다른 여러 회사와 파트너 관계로 작업한다고 가정하므로 폼 인증이 사용됩니다. 디렉터리 및 공급자는 지정되지 않습니다.

고객

고객 액세스에는 인터넷 영역이 사용됩니다. 이 영역은 읽기 전용 권한이 있는 익명 액세스를 허용하도록 구성됩니다.

영역

영역을 디자인할 때는 성공적인 배포를 위해 몇 가지 주요 사항을 결정해야 합니다. 이러한 사항에는 다음 영역에 대한 디자인 및 구성 결정 사항이 포함됩니다.

  • 기본 영역

  • 외부 액세스용 영역

다음 섹션에서는 이 모델에 통합된 결정 사항에 대해 설명합니다.

기본 영역의 구성 요구 사항

가장 주의 깊게 고려해야 하는 영역은 기본 영역입니다. Office SharePoint Server 2007에서는 기본 영역을 구성하는 방법에 다음과 같은 요구 사항을 적용합니다.

  • 사용자 요청을 특정 영역에 연결할 수 없는 경우 기본 영역의 인증 및 정책이 사용됩니다. 따라서 기본 영역은 가장 보안이 강화된 영역이어야 합니다.

  • 인덱스 구성 요소는 최소한 하나 이상의 영역을 통해 콘텐츠에 액세스하여 콘텐츠를 크롤링할 수 있어야 합니다. 기본적으로 인덱스 구성 요소는 NTLM 인증을 사용합니다. SSP 관리자는 특정 URL 범위를 크롤링할 때 기본 인증 또는 클라이언트 인증서를 사용하도록 크롤링 규칙을 구성할 수 있습니다. 따라서 콘텐츠를 크롤링하려면 최소한 하나 이상의 영역에서 NTLM 인증, 기본 인증 또는 인증서를 사용하도록 구성해야 합니다. 또한 크롤러는 기본 영역, 인트라넷 영역, 인터넷 영역, 사용자 지정 영역, 익스트라넷 영역 순서로 영역을 폴링하여 인증 가능한 영역을 찾습니다. 그러나 크롤러에서 Kerberos 인증을 사용하도록 구성된 영역을 처음 발견하면 크롤러가 인증되지 않고 다음 영역에 대한 액세스가 시도되지 않습니다. 따라서 Kerberos 인증을 사용하는 영역 구성으로 인해 인덱스 구성 요소가 콘텐츠를 크롤링할 수 없는 경우를 방지해야 합니다. 콘텐츠 크롤링과 관련된 인증 요구 사항에 대한 자세한 내용은 인증 방법 계획(Office SharePoint Server)을 참조하십시오.

  • 관리 전자 메일은 기본 영역의 링크와 함께 전송됩니다. 여기에는 할당량 제한에 도달한 사이트 소유자의 전자 메일이 포함됩니다. 따라서 이러한 유형의 전자 메일 및 알림을 받는 사용자는 기본 영역을 통해 링크에 액세스할 수 있어야 합니다. 이는 사이트 소유자에게 특히 중요합니다.

  • 호스트 이름이 지정된 사이트 모음은 기본 영역을 통해서만 사용할 수 있습니다. 호스트 이름이 지정된 사이트 모음에 액세스하려는 모든 사용자는 기본 영역을 통해 액세스할 수 있어야 합니다.

이 모델에서는 다음과 같은 이유로 인해 기본 영역이 원격 직원 액세스용으로 사용됩니다.

  • 직원이 자신의 위치에 관계없이 관리 전자 메일의 링크에 액세스할 수 있습니다.

  • 사용자 요청에 연결된 영역을 확인할 수 없는 경우 내부 서버 이름과 URL이 노출되지 않습니다. 기본 영역이 이미 원격 직원용으로 구성되어 있으므로 이 영역이 적용될 때 URL에 중요한 데이터가 노출되지 않습니다.

익스트라넷 환경에 대한 영역 구성

익스트라넷 환경에서는 다음 두 가지 이유로 인해 영역 디자인이 중요합니다.

  • 서로 다른 여러 네트워크에서 사용자 요청이 시작될 수 있습니다. 이 모델에서는 사용자 요청이 내부 네트워크, 인터넷 및 파트너 회사에서 시작됩니다.

  • 사용자는 여러 웹 응용 프로그램의 콘텐츠를 사용합니다. 이 모델에서 인트라넷은 서로 다른 세 가지 웹 응용 프로그램으로 구성되어 있습니다. 또한 내부 직원과 원격 직원은 모든 웹 응용 프로그램(인트라넷, 파트너 웹 및 회사 인터넷 사이트) 사이에서 콘텐츠를 제공 및 관리할 수 있습니다.

익스트라넷 환경에서는 다음과 같은 디자인 원칙을 따라야 합니다.

  • 여러 웹 응용 프로그램에서 영역을 서로 동일하게 구성합니다. 인증 구성과 의도된 사용자가 같아야 합니다. 그러나 영역에 연결된 정책은 웹 응용 프로그램에 따라 다를 수 있습니다. 예를 들어 모든 웹 응용 프로그램에서 인트라넷 영역이 동일한 직원을 위해 사용되어야 합니다. 즉, 인트라넷 영역을 특정 웹 응용 프로그램에서는 내부 직원용으로 구성하고 다른 웹 응용 프로그램에서는 원격 직원용으로 구성하지 말아야 합니다.

  • 각 영역과 각 리소스에 대해 대체 액세스 매핑을 적절하고 정확하게 구성합니다.

이 모델에서는 각 웹 응용 프로그램의 기본 영역이 원격 직원 액세스용으로 동일하게 구성되어 있습니다. 또한 모든 웹 응용 프로그램에서 인트라넷 영역이 내부 직원 액세스용으로 동일하게 구성되어 있습니다. 익스트라넷 영역과 인터넷 영역은 각각 단일 웹 응용 프로그램에서만 구성되어 있습니다.

영역을 만들면 대체 액세스 매핑이 자동으로 만들어집니다. 그러나 Office SharePoint Server 2007에서 파일 공유 등의 외부 리소스에 있는 콘텐츠를 크롤링하도록 구성할 수 있습니다. 각 영역에서 대체 액세스 매핑을 사용하여 이러한 외부 리소스에 대한 링크를 직접 만들어야 합니다. 예를 들어 내부 URL(file://)을 사용하여 파일 공유를 내부 사용자에게 노출하고, 동일한 파일 공유를 외부 사용자에게 FTP 링크(ftp://)로 노출할 수 있습니다. 이렇게 하면 이러한 리소스를 사용자 영역의 컨텍스트에 따라 제공할 수 있습니다. 사용자는 검색 결과에 나타나는 이러한 리소스에 대한 링크에 액세스할 수 있습니다.

웹 응용 프로그램 간에 영역이 서로 다르고 외부 리소스에 대한 링크가 적절하지 않으면 다음과 같은 위험이 따를 수 있습니다.

  • 서버 이름, DNS(Domain Name System) 이름 및 IP 주소가 내부 네트워크의 외부로 노출될 수 있습니다.

  • 사용자가 웹 사이트 및 기타 리소스에 액세스하지 못할 수 있습니다.

SSP

SSP는 웹 응용 프로그램 및 웹 응용 프로그램에 연결된 사이트의 논리 그룹에 서비스 및 서비스 데이터의 공통 집합을 제공합니다. 서비스 및 서비스 데이터에는 다음이 포함됩니다.

  • 개인 설정 서비스

  • 대상 그룹

  • 비즈니스 데이터 카탈로그

  • Excel 서비스

  • Office SharePoint Server 검색

  • 포털 사용 현황 보고

논리 아키텍처에 SSP가 둘 이상 필요한지 여부를 결정하는 가장 중요한 기준은 콘텐츠를 격리해야 하는지 여부입니다. 예를 들어 서버 팜에서 둘 이상의 사용자 유형에 대한 응용 프로그램을 호스팅하는 경우 별도의 SSP를 사용하여 이러한 사용자 유형을 서로 격리할 수 있습니다.

이 모델에는 다음과 같은 각 응용 프로그램에 대한 별도의 SSP가 통합되어 있습니다.

  • 인트라넷

  • 파트너 웹

  • 고객 인터넷 웹 사이트

    회사 배포를 위한 SSP 모델

인트라넷

인트라넷을 구성하는 세 가지 개별 응용 프로그램인 게시된 인트라넷 콘텐츠, 내 사이트 및 팀 사이트가 단일 SSP로 통합됩니다. 모델에 나와 있는 인트라넷 응용 프로그램은 응용 프로그램 간에 정보를 공유하고 프로필 데이터를 활용하려는 비즈니스 요구 사항과 안전한 격리 사이에서 적절한 균형을 유지하는 예를 보여 줍니다.

  • 개별 응용 프로그램은 웹 응용 프로그램 및 응용 프로그램 풀에 따라 격리됩니다. 서로 구분된 응용 프로그램 풀을 통해 프로세스가 격리됩니다. 전용 웹 응용 프로그램을 사용하면 각 콘텐츠 형식에 대해 서로 다른 사용 권한 정책을 구현할 수 있습니다.

  • 세 가지 응용 프로그램을 단일 SSP로 통합하면 모든 응용 프로그램 사이에서 개인 설정 및 엔터프라이즈 수준 검색이 지원됩니다.

    공유 서비스 공급자 아키텍처

파트너 웹

파트너 웹 응용 프로그램에 별도의 SSP를 사용하면 파트너 사용자가 인트라넷 환경에 있는 중요한 정보를 검색하거나 이러한 정보에 액세스할 수 없습니다. 다음과 같은 방법으로 SSP를 구성하여 사이트 모음 사이에서 콘텐츠를 추가로 격리할 수 있습니다.

  • 검색 범위를 개별 사이트 모음으로 제한합니다.

  • 대상 그룹을 사용하여 콘텐츠의 대상을 특정 사용자 그룹으로 지정합니다.

  • Stsadm 명령줄 도구를 사용하여 사이트 모음의 구성원인 사용자만 사용자 선택에 표시되도록 구성합니다. 이 구성에서는 사용자 이름을 알고 있는 경우 디렉터리에서 모든 사용자를 추가할 수 있지만 사용자 선택에는 사이트 모음에 이미 추가된 사용자만 표시됩니다. 따라서 파트너 사용자가 사용자 선택을 통해 사용자 디렉터리를 탐색할 수 없습니다.

    다음 명령을 사용하여 이 구성을 설정합니다.

    Stsadm.exe -o setproperty –url http://서버 –pn “peoplepicker-onlysearchwithinsitecollection” –pv yes

    다음 명령을 사용하여 이 구성을 해제합니다.

    Stsadm.exe -o setproperty –url http://서버 –pn “peoplepicker-onlysearchwithinsitecollection” –pv no

SSP 내에서 서비스를 구성하여 격리를 구현하는 방법 이외에도 다음과 같은 방법으로 사용 권한을 구성할 수 있습니다.

  • 사이트에 대한 액세스를 특정 사용자 또는 그룹으로 제한합니다.

  • SharePoint 그룹을 사용하여 콘텐츠에 대한 액세스 권한을 부여합니다.

회사 인터넷 사이트

이 모델에서는 익명 사용자가 회사 인터넷 사이트를 사용할 수 있습니다. 익명 사용자를 위한 사이트는 인증된 사용자를 위한 사이트와 항상 분리되어야 합니다. 이 모델에서는 회사 인터넷 사이트에 다음과 같은 격리 방법을 사용합니다.

  • 서로 구분된 응용 프로그램 풀을 통해 프로세스를 격리합니다.

  • 서로 구분된 웹 응용 프로그램을 통해 정책의 대상을 지정합니다.

  • 전용 SSP를 통해 검색 결과를 익명 응용 프로그램으로 제한합니다.

관리 사이트

이 모델에서는 각 관리 사이트가 전용 응용 프로그램 풀 및 웹 응용 프로그램 내에서 호스팅됩니다. 다음 목록에서는 각 관리 웹 사이트를 보여 줍니다.

  • 공유 서비스 관리 웹 사이트   이 모델에는 각 SSP에 대한 전용 관리 사이트가 나와 있습니다. 공유 서비스 관리 사이트는 단일 서버나 서버 집합에 격리할 수 없습니다. 이러한 사이트는 모든 프런트 엔드 웹 서버에서 자동으로 미러링됩니다.

  • 중앙 관리 웹 사이트   이 모델에서는 각 서버 팜의 중앙 관리 사이트가 응용 프로그램 서버에 호스팅되므로 사용자가 이러한 사이트에 직접 액세스할 수 없습니다. 성능 병목 현상이 발생하거나 보안 문제로 인해 프런트 엔드 웹 서버를 사용할 수 없는 경우에도 중앙 관리 사이트를 계속 사용할 수 있습니다.

관리 사이트에 대한 부하 분산 URL은 모델이나 이 문서에서 설명되어 있지 않으며 다음과 같은 지침을 따르는 것이 좋습니다.

  • 관리 URL에 포트 번호가 사용되는 경우 표준이 아닌 포트를 사용합니다. 포트 번호는 기본적으로 URL에 포함되어 있습니다. 고객 연결 URL에는 일반적으로 포트 번호가 사용되지 않지만 관리 사이트에 포트 번호를 사용하면 이러한 사이트에 대한 액세스가 표준이 아닌 포트로 제한되므로 보안이 강화될 수 있습니다.

  • 관리 도메인에서만 관리 사이트에 액세스할 수 있도록 합니다.

  • 관리 사이트에 대한 별도의 DNS 항목을 만듭니다.

이러한 지침 이외에도 여러 응용 프로그램 서버 간에 중앙 관리 사이트의 부하를 분산하여 중복을 구현할 수 있습니다.

응용 프로그램 풀

일반적으로 서로 구분된 IIS(인터넷 정보 서비스) 응용 프로그램 풀을 구현하여 콘텐츠 간에 프로세스를 격리합니다. 응용 프로그램 풀을 통해 같은 서버 컴퓨터에서 여러 사이트를 실행하면서 자체 작업자 프로세스와 ID를 유지할 수 있습니다. 이렇게 하면 공격자가 한 사이트에서 다른 사이트를 공격하는 코드를 서버에 삽입할 위험이 감소합니다.

다음과 같은 시나리오에서는 실제로 전용 응용 프로그램 풀을 사용하는 것이 좋습니다.

  • 인증된 콘텐츠와 익명 콘텐츠를 분리하려는 경우

  • 비즈니스 데이터 카탈로그 연결과 같은 외부 비즈니스 응용 프로그램에 대한 암호를 저장하고 이러한 응용 프로그램과 상호 작용하는 응용 프로그램을 격리하려는 경우

  • 사용자가 자유롭게 사이트를 만들거나 관리하고 콘텐츠에 대해 공동으로 작업할 수 있는 응용 프로그램을 격리하려는 경우

이 모델에서는 응용 프로그램 풀을 다음과 같이 사용합니다.

  • 각 관리 사이트가 전용 응용 프로그램 풀에 호스팅됩니다. 이는 Office SharePoint Server 2007의 요구 사항입니다.

  • 인트라넷 콘텐츠가 서로 다른 두 응용 프로그램 풀로 분할됩니다. 공동 작업 콘텐츠(내 사이트 및 팀 사이트)가 응용 프로그램 풀 하나에 호스팅되고, 게시된 인트라넷 콘텐츠가 별도의 응용 프로그램 풀에 호스팅됩니다. 이러한 구성을 통해 비즈니스 데이터 연결이 사용될 가능성이 더 높은 게시된 인트라넷 콘텐츠에 대해 프로세스가 격리됩니다. 예를 들어 여러 HR(인사 관리) 사이트에서는 비즈니스 데이터 연결을 사용하여 직원이 자신의 개인 데이터에 액세스할 수 있게 합니다.

  • 파트너 웹 응용 프로그램이 전용 응용 프로그램 풀에 호스팅됩니다.

  • 회사 인터넷 사이트가 팜 B의 전용 응용 프로그램 풀에 호스팅됩니다. 이 팜에서 파트너 공동 작업용 콘텐츠도 호스팅하는 경우 이러한 두 가지 콘텐츠 형식(인터넷 및 파트너)을 서로 다른 두 응용 프로그램 풀에 호스팅해야 합니다.

웹 응용 프로그램

웹 응용 프로그램은 SharePoint 제품 및 기술에서 만들고 사용하는 IIS 웹 사이트입니다. 각 웹 응용 프로그램은 IIS에서 서로 다른 웹 사이트로 나타납니다. 각 웹 응용 프로그램에는 고유 도메인 이름을 할당하며, 이 이름을 통해 사이트 간 스크립트 공격을 막을 수 있습니다.

일반적으로 전용 웹 응용 프로그램을 사용하여 다음을 수행할 수 있습니다.

  • 익명 콘텐츠를 인증된 콘텐츠와 구분. 이 모델에서는 회사 인터넷 사이트가 전용 웹 응용 프로그램 및 응용 프로그램 풀에 호스팅됩니다.

  • 사용자 격리. 이 모델에서는 파트너 웹이 전용 웹 응용 프로그램 및 응용 프로그램 풀에 호스팅되므로 파트너가 인트라넷 콘텐츠에 액세스할 수 없습니다.

  • 사용 권한 적용. 전용 웹 응용 프로그램을 통해 중앙 관리의 웹 응용 프로그램 정책 페이지를 사용한 정책별 사용 권한을 적용할 수 있습니다. 예를 들어 회사 인터넷 사이트에서 하나 이상의 사용자 그룹에 대해 쓰기 액세스 권한을 명시적으로 거부하는 정책을 만들 수 있습니다. 웹 응용 프로그램 정책은 웹 응용 프로그램 내에서 개별 사이트나 문서에 대해 구성된 사용 권한에 관계없이 적용됩니다.

  • 성능 최적화. 웹 응용 프로그램에 데이터 특성이 비슷한 여러 응용 프로그램을 함께 배치하면 성능이 향상됩니다. 예를 들어 내 사이트의 데이터 특성에는 크기가 작은 수많은 사이트가 포함되는 반면 팀 사이트에는 일반적으로 적은 수의 대규모 사이트가 포함됩니다. 이렇게 서로 다른 두 가지 유형의 사이트를 별도의 웹 응용 프로그램에 배치하면 결과 데이터베이스가 특징이 서로 비슷한 데이터로 구성되므로 데이터베이스 성능이 향상됩니다. 이 모델에서는 내 사이트와 팀 사이트에 대해 특별히 데이터를 격리할 필요가 없으므로 같은 응용 프로그램 풀이 공유됩니다. 그러나 성능을 최적화하기 위해 내 사이트와 팀 사이트를 별도의 웹 응용 프로그램에 배치합니다.

  • 관리 기능 최적화. 별도의 웹 응용 프로그램을 만들면 별도의 사이트 및 데이터베이스가 만들어지므로 서로 다른 사이트 제한(휴지통, 만료 및 크기)을 구현하고 서비스 수준 계약을 서로 다르게 조정할 수 있습니다. 예를 들어 조직 내에서 내 사이트 콘텐츠가 크게 중요하지 않은 경우 내 사이트 콘텐츠의 복원 시간을 더 길게 설정할 수 있습니다. 이렇게 하면 내 사이트 콘텐츠가 복원되기 전에 더 중요한 콘텐츠가 먼저 복원됩니다. 이 모델에서는 관리자가 다른 응용 프로그램보다 확장을 보다 적극적으로 관리할 수 있도록 내 사이트를 별도의 웹 응용 프로그램에 배치합니다.

사이트 모음

사이트 모음은 논리 아키텍처와 정보 아키텍처를 서로 연결합니다. 모델에서 사이트 모음의 디자인 목표는 URL 디자인 요구 사항을 충족하고 콘텐츠를 논리적으로 분할하는 것입니다.

URL 디자인 요구 사항을 충족하기 위해 각 웹 응용 프로그램에 단일 루트 수준 사이트 모음이 포함되어 있습니다. 관리 경로는 최상위 사이트 모음의 두 번째 계층을 통합하는 데 사용됩니다. URL 요구 사항 및 관리 경로를 사용하는 방법에 대한 자세한 내용은 이 문서 뒷부분의 "영역 및 URL"을 참조하십시오. 사이트 모음의 두 번째 계층 이후에 있는 모든 사이트는 하위 사이트입니다.

다음 그림에서는 팀 사이트의 사이트 계층 구조를 보여 줍니다.

공동 작업 사이트용 논리적 아키텍처

루트 수준 사이트 모음에 대한 요구 사항이 결정되었으면 사이트 모음의 두 번째 계층을 중심으로 디자인을 결정해야 합니다. 이 모델에는 응용 프로그램의 특징에 따른 선택 내용이 적용되어 있습니다.

게시된 인트라넷 콘텐츠

게시된 인트라넷 콘텐츠 응용 프로그램에서는 회사 내의 여러 부서에서 게시된 콘텐츠를 호스팅한다고 가정합니다. 이 모델에서는 각 부서의 콘텐츠가 별도의 사이트 모음에 호스팅됩니다. 이 방법의 장점은 다음과 같습니다.

  • 각 부서에서 자신의 콘텐츠를 독립적으로 관리하고 사용 권한을 부여할 수 있습니다.

  • 각 부서의 콘텐츠를 전용 데이터베이스에 저장할 수 있습니다.

여러 사이트 모음을 사용하는 방법의 단점은 다음과 같습니다.

  • 사이트 모음 사이에서 마스터 페이지, 페이지 레이아웃, 서식 파일, 웹 파트 및 탐색을 공유할 수 없습니다.

  • 사이트 모음 사이에서 사용자 지정 내용 및 탐색을 조정하는 추가 작업을 수행해야 합니다.

정보 아키텍처 및 인트라넷 응용 프로그램의 디자인에 따라 게시된 콘텐츠를 사용자에게 단일 응용 프로그램으로 매끄럽게 표시할 수도 있고, 각 사이트 모음을 별도의 웹 사이트로 표시할 수도 있습니다.

내 사이트

내 사이트에는 독특한 특징이 있으며 내 사이트 배포와 관련된 지침은 단순합니다. 이 모델에서는 내 사이트 응용 프로그램에 URL이 http://my인 최상위 사이트가 통합되어 있습니다. 작성된 첫 번째 최상위 사이트 모음에는 내 사이트 호스트 서식 파일이 사용됩니다. 와일드카드 포함을 사용하여 관리 경로가 통합되므로 사용자가 만들 수 있는 사이트의 수에 제한이 없습니다. 관리 경로 아래의 모든 사이트는 내 사이트 호스트 서식 파일을 상속하는 독립된 사이트 모음입니다. 사용자 이름은 URL에 http://my personal/사용자 이름 형식으로 추가됩니다. 다음 그림에서는 내 사이트를 보여 줍니다.

내 사이트의 논리적 네트워크 아키텍처

내 사이트 응용 프로그램을 디자인하는 방법에 대한 자세한 내용은 내 사이트 아키텍처 디자인을 참조하십시오.

팀 사이트

다음 두 가지 방법 중 하나를 사용하여 팀 사이트 응용 프로그램 내의 사이트 모음을 디자인할 수 있습니다.

  • 팀에서 셀프 서비스 사이트 만들기를 통해 사이트 모음을 만들 수 있도록 허용합니다. 이 방법의 장점은 팀에서 필요에 따라 손쉽게 사이트를 만들 수 있으며 관리자의 도움이 필요하지 않다는 점입니다. 그러나 이 방법에는 다음과 같은 여러 가지 단점이 있습니다.

    • 자세한 분류를 구현할 수 없습니다.

    • 응용 프로그램을 관리하기가 어려워질 수 있습니다.

    • 사이트가 사용되지 않는 경우가 많습니다.

    • 다른 방법을 사용하면 사이트 모음을 공유할 수도 있는 프로젝트나 팀 사이에서 서식 파일 및 탐색을 공유할 수 없습니다.

  • 조직이 운영되는 방식에 따라 조직에 일정한 개수의 사이트 모음을 만듭니다. 이 방식에서는 SharePoint 관리자가 사이트 모음을 만듭니다. 사이트 모음이 만들어지면 팀에서 필요에 따라 사이트 모음 내에 사이트를 만들 수 있습니다. 이 방법을 사용하면 팀 사이트의 관리 및 확장 방식을 체계화하는 정교한 사이트 구조를 구현할 수 있습니다. 또한 사이트 모음을 공유하는 프로젝트 및 팀 사이에서 서식 파일 및 탐색을 공유할 수 있습니다.

이 모델에서는 두 번째 방법을 사용하여 게시된 인트라넷 콘텐츠와 비슷한 사이트 모음 계층 구조를 팀 사이트에 적용합니다. 정보 설계자는 조직에 적합한 방식으로 사이트 모음의 두 번째 계층을 만들어야 합니다. 다음 표에서는 다양한 조직 유형에 대해 권장되는 구조를 보여 줍니다.

조직 유형 권장되는 사이트 모음 구조

제품 개발

  • 개발 중인 각 제품에 대한 사이트 모음을 만듭니다. 참여하는 각 팀에서 사이트 모음 내에 사이트를 만들 수 있도록 허용합니다.

  • 장기 개발 프로젝트의 경우 제품 개발에 참여하는 각 대규모 팀에 대해 사이트 모음을 만듭니다. 예를 들어 디자이너, 엔지니어 및 콘텐츠 개발자 팀에 대해 사이트 모음을 하나씩 만듭니다.

리서치

  • 각 장기 리서치 프로젝트에 대해 사이트 모음을 하나씩 만듭니다.

  • 리서치 프로젝트의 각 범주에 대해 사이트 모음을 하나씩 만듭니다.

고등 교육 기관

  • 학과별로 사이트 모음을 하나씩 만듭니다.

정부 기관

  • 정당별로 사이트 모음을 하나씩 만듭니다. 같은 정당에 속한 공무원들이 서식 파일 및 탐색을 공유할 수 있습니다.

  • 위원회별로 사이트 모음을 하나씩 만들거나 모든 위원회에 대한 단일 사이트 모음을 만듭니다.

기업 법률 사무소

  • 기업 고객별로 사이트 모음을 하나씩 만듭니다.

제조

  • 제품 라인별로 사이트 모음을 하나씩 만듭니다.

파트너 웹

파트너 웹은 범위나 기간이 한정되어 있는 프로젝트에 대해 외부 파트너와 공동으로 작업하는 데 사용됩니다. 파트너 웹 응용 프로그램 내의 각 사이트는 서로 관련되지 않도록 디자인되어 있습니다. 파트너 웹에 대한 요구 사항은 다음과 같습니다.

  • 프로젝트 소유자가 파트너 공동 작업용 사이트를 손쉽게 만들 수 있어야 합니다.

  • 파트너 및 다른 참가자가 자신이 작업하는 프로젝트에만 액세스할 수 있어야 합니다.

  • 사이트 소유자가 사용 권한을 관리해야 합니다.

  • 프로젝트 중 하나에서 검색한 결과에 다른 프로젝트의 내용이 노출되지 않아야 합니다.

  • 더 이상 사용되지 않는 사이트를 관리자가 손쉽게 식별하여 삭제할 수 있어야 합니다.

이러한 요구 사항을 충족하기 위해 이 모델에는 각 프로젝트에 대한 사이트 모음이 하나씩 포함되어 있습니다. 이렇게 하면 다음과 같은 장점이 있습니다.

  • 개별 사이트 모음에서 프로젝트 사이에 적절한 격리 수준을 제공합니다.

  • 셀프 서비스 사이트 만들기를 구현할 수 있습니다.

파트너 웹 응용 프로그램은 회사 인터넷 사이트용 콘텐츠를 개발하는 사이트 모음도 호스팅하므로 제작 및 준비를 위한 별도의 사이트 모음을 만듭니다.

회사 인터넷 사이트

회사 인터넷 사이트에는 단일 루트 수준 사이트 모음이 포함되어 있습니다. 이 사이트 모음 아래의 모든 사이트는 하위 사이트입니다. 이러한 구조를 사용하면 사이트 내의 페이지에 대한 URL이 간소화됩니다. 다음 그림에서는 회사 인터넷 사이트의 아키텍처를 보여 줍니다.

논리적 배포 아키텍처

콘텐츠 데이터베이스

다음과 같은 두 가지 방법을 사용하여 콘텐츠 데이터베이스를 디자인에 통합할 수 있습니다. 이 모델에서는 두 가지 방법을 모두 사용합니다.

  • 적절한 크기 경고 임계값을 사용하여 콘텐츠 데이터베이스의 대상 크기를 설정합니다. 크기 경고 임계값에 도달하면 새 데이터베이스를 만듭니다. 이 방법을 사용하면 대상 크기만을 기준으로, 사용 가능한 하나 이상의 데이터베이스에 사이트 모음이 자동으로 추가됩니다.

  • 사이트 모음을 특정 콘텐츠 데이터베이스에 연결합니다. 이 방법을 사용하면 다른 데이터베이스와 독립적으로 관리할 수 있는 전용 데이터베이스에 하나 이상의 사이트 모음을 배치할 수 있습니다.

사이트 모음을 특정 콘텐츠 데이터베이스에 연결하려는 경우 다음과 같은 방법을 사용할 수 있습니다.

  • Stsadm 명령줄 도구를 사용하여 특정 데이터베이스에 사이트 모음을 만듭니다.

  • 다음과 같은 데이터베이스 용량 설정을 적용하여 데이터베이스를 단일 사이트 모음에만 할당합니다.

    • 경고 이벤트가 발생되기 전의 사이트 수 = 1

    • 이 데이터베이스에서 만들 수 있는 최대 사이트 개수 = 1

  • 다음 단계를 수행하여 전용 데이터베이스에 사이트 모음 그룹을 추가합니다.

    1. 웹 응용 프로그램 내에서 데이터베이스를 만들고 데이터베이스 상태를 준비로 설정합니다.

    2. 다른 모든 데이터베이스의 상태를 오프라인으로 설정합니다. 콘텐츠 데이터베이스가 오프라인 상태이면 새 사이트 모음을 만들 수 없지만, 오프라인 데이터베이스의 기존 사이트 모음에는 계속 액세스하여 읽기 및 쓰기 작업을 수행할 수 있습니다.

    3. 사이트 모음을 만듭니다. 사이트 모음이 데이터베이스에 자동으로 추가됩니다.

    4. 다른 모든 데이터베이스의 상태를 다시 준비로 설정합니다.

게시된 인트라넷 콘텐츠

게시된 인트라넷 콘텐츠의 경우 이 모델에는 부서 사이트 모음마다 전용 데이터베이스가 하나씩 포함되어 있습니다.

이 방법을 사용하면 각 부서에서 자신의 콘텐츠를 독립적으로 관리할 수 있습니다.

내 사이트

내 사이트의 경우 이 모델에서는 최대 대상 크기까지 데이터베이스를 관리하여 규모의 효율성을 구현합니다. 이 목표를 위해 설정을 다음과 같이 구성합니다.

  • 사이트 저장 제한 용량   이 설정은 중앙 관리의 할당량 지정 서식 파일 페이지에서 구성할 수 있으며 개인 사이트의 크기를 제한합니다.

  • 2단계 휴지통   이 설정은 웹 응용 프로그램 일반 설정 페이지에서 구성할 수 있으며 2단계 휴지통에 할당되는 추가 공간을 결정합니다.

  • 이 데이터베이스에서 만들 수 있는 최대 사이트 개수   이 설정은 데이터베이스를 만들 때 구성됩니다. 위에 있는 두 가지 값에 지정한 숫자를 사용하여 허용되는 총 사이트 크기를 계산합니다. 그런 다음 각 데이터베이스의 크기 목표에 따라 데이터베이스에 포함될 수 있는 사이트 수를 결정합니다.

이 모델에서는 대상 데이터베이스 크기를 100GB로, 내 사이트의 대상 크기를 500MB로 가정하고 다음과 같은 예제 크기 설정을 사용합니다.

  • 사이트당 크기 제한 = 500MB

  • 데이터베이스의 대상 크기 = 100GB

  • 최대 사이트 수 = 200

  • 경고 전 사이트 수 = 150

경고 전 사이트 수에 도달하면 새 데이터베이스를 만들어야 합니다. 새 데이터베이스를 만들면 데이터베이스 중 하나의 최대 사이트 수에 도달할 때까지 새로 만드는 내 사이트가 새 데이터베이스와 기존 데이터베이스에 교대로 추가됩니다.

내 사이트에 대한 데이터베이스 설정을 디자인하는 방법에 대한 자세한 내용은 내 사이트 아키텍처 디자인을 참조하십시오.

팀 사이트

팀 사이트의 경우 이 모델에는 팀 사이트 모음마다 전용 데이터베이스가 하나씩 포함되어 있습니다. 이 방법을 사용하면 각 팀의 데이터베이스에 대한 백업, 복원 및 마이그레이션을 독립적으로 관리할 수 있습니다. 또한 프로젝트가 완료되면 해당 프로젝트와 연결된 데이터베이스를 쉽게 보관할 수 있습니다.

파트너 웹

내 사이트의 경우와 마찬가지로 파트너 웹에서는 데이터베이스를 최대 대상 크기까지 관리하여 규모의 효율성을 달성합니다. 그러나 이 모델에서는 파트너 웹에서 회사 인터넷 사이트에 대한 제작 및 준비 사이트 모음도 호스팅하므로 데이터베이스 디자인에 다음과 같은 두 가지 방법이 모두 통합됩니다.

  • 제작 및 준비 사이트 모음이 각각 전용 데이터베이스에 호스팅됩니다.

  • 다른 모든 사이트 및 데이터베이스를 관리하는 데이터베이스 및 크기 설정을 구성합니다.

파트너 웹은 전용 웹 응용 프로그램에 호스팅되므로 작성된 크기 유형에 보다 적합한 크기 제한을 만들 수 있습니다. 이 모델에서는 다음과 같은 예제 크기 설정을 사용합니다.

  • 데이터베이스의 대상 크기 = 100GB

  • 사이트당 저장소 할당량 = 5GB

  • 최대 사이트 수 = 20

  • 전용 데이터베이스에 제작 및 준비 사이트 모음 호스팅

회사 인터넷 사이트

회사 인터넷 사이트를 디자인할 때 단일 사이트 모음을 사용하면 이 웹 응용 프로그램에 단일 데이터베이스를 사용할 수 있습니다.

영역 및 URL

이 모델에서는 기업 배포에서 여러 응용 프로그램 간에 URL을 조정하는 방법을 보여 줍니다.

디자인 목표

다음 목표는 URL의 디자인과 관련된 결정에 영향을 줍니다.

  • 콘텐츠에 액세스하는 데 사용할 수 있는 영역이 URL 규칙에 따라 제한되지 않습니다.

  • 모델의 모든 응용 프로그램 사이에서 표준 HTTP 및 HTTPS 포트(80 및 443)를 사용할 수 있습니다.

  • URL에 포트 번호가 포함되지 않습니다. 실제 프로덕션 환경에서는 일반적으로 포트 번호가 사용되지 않습니다.

디자인 원칙

이러한 디자인 목표를 달성하려면 다음과 같은 디자인 원칙을 적용합니다.

  • 호스트 이름이 지정된 사이트 모음을 사용하지 않습니다. 호스트 이름이 지정된 사이트 모음은 IIS 호스트 헤더와 다르며, 호스트 이름이 지정된 사이트 모음은 대체 액세스 매핑 기능과 호환되지 않습니다. 여러 도메인 URL을 통해 동일한 콘텐츠에 액세스하려면 대체 액세스 매핑 기능이 필요합니다. 따라서 호스트 이름이 지정된 사이트를 사용하면 기본 영역을 통해서만 이러한 사이트를 사용할 수 있습니다. 또한 대체 액세스 매핑 기능은 오프 박스 SSL(Secure Sockets Layer) 종료를 지원하며, 이를 통해 원격 직원 액세스 및 파트너 액세스 시나리오에서 SSL(https)을 사용할 수 있습니다.

  • 각 응용 프로그램에는 단일 루트 사이트 모음이 포함되며, 이렇게 해야 대체 액세스 매핑을 사용할 수 있습니다. 웹 응용 프로그램 내에 여러 루트 사이트 모음이 필요하며 사용자 액세스용으로 기본 영역만 사용하려는 경우에는 호스트 이름이 지정된 사이트 모음을 사용하는 것이 좋습니다.

  • 각 사이트 모음이 최상위 팀이나 프로젝트를 나타내는 팀 사이트 등 높은 수준의 여러 사이트 모음이 포함된 응용 프로그램의 경우 이 모델에는 관리 경로가 포함되어 있습니다. 관리 경로를 사용하면 다음과 같은 사이트 유형의 URL을 보다 세밀하게 제어할 수 있습니다.

디자인 장단점

디자인 목표를 충족하면 다음을 비롯한 몇 가지 장단점이 있습니다.

  • URL이 길어집니다.

  • 호스트 이름이 지정된 사이트 모음을 사용하지 않습니다.

부하 분산 URL 디자인

웹 응용 프로그램을 만들 때는 응용 프로그램에 할당할 부하 분산 URL을 선택해야 합니다. 또한 웹 응용 프로그램 내에 만드는 각 영역에 대한 부하 분산 URL을 만들어야 합니다. 부하 분산 URL에는 프로토콜, 체계, 호스트 이름 및 포트(사용되는 경우)가 포함됩니다. 부하 분산 URL은 모든 웹 응용 프로그램 및 영역 사이에서 고유해야 합니다. 따라서 각 응용 프로그램 및 각 응용 프로그램 내의 각 영역에는 모델 전체에서 고유한 URL이 필요합니다.

인트라넷

인트라넷을 구성하는 세 가지 응용 프로그램에 각각 고유 URL이 필요합니다. 이 모델에서 인트라넷 콘텐츠의 대상 그룹은 내부 직원 및 원격 직원입니다. 다음 표에서는 내부 직원과 원격 직원이 각 응용 프로그램에 액세스하는 데 사용하는 URL을 보여 줍니다.

응용 프로그램 내부 직원 URL 원격 직원 URL

게시된 인트라넷 콘텐츠

http://fabrikam

https://intranet.fabrikam.com

팀 사이트

http://teams

https://teams.fabrikam.com

내 사이트

http://my

https://my.fabrikam.com

파트너 웹

이 모델에서는 내부 직원, 원격 직원 및 파트너 직원이 파트너 웹에 액세스합니다. 원격 직원과 파트너 직원이 모두 외부에서 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입니다.

  • 와일드카드 포함   URL에 추가되는 경로입니다. 이 경로는 경로 이름 바로 뒤에 지정된 모든 사이트가 고유 사이트 모음임을 나타냅니다. 이 방법은 일반적으로 내 사이트와 같이 셀프 사이트 만들기를 지원하는 응용 프로그램에 사용됩니다. 이 방법으로 만든 사이트 모음 URL의 예는 http://my/personal/user1입니다.

이 모델에서는 다음 섹션의 설명에 따라 두 가지 유형을 모두 사용합니다.

명시적 포함: 팀 사이트 및 게시된 인트라넷 콘텐츠

이 모델에서는 팀 사이트 응용 프로그램과 게시된 인트라넷 콘텐츠 응용 프로그램에서 모두 명시적 포함을 사용합니다.

팀 사이트

팀 사이트 응용 프로그램 내에서 각 팀 사이트 모음에 대해 명시적 포함이 사용됩니다. 명시적 포함으로 만든 사이트 모음의 규모 제한은 대략 사이트 100개입니다. 최상위 팀 사이트의 개수는 적절한 수준으로 유지하는 것이 좋습니다. 또한 비즈니스 운영 방식에 맞는 논리적인 구조를 팀 사이트에 적용해야 합니다. 대부분의 조직에서는 100개 이하의 사이트를 사용하는 것이 좋습니다. 조직에서 팀 사이트의 규모가 더 커야 하는 경우 와일드카드 포함을 대신 사용하십시오.

이 모델에서는 명시적 포함을 사용하여 다음 표와 같은 URL을 만듭니다.

내부 직원(인트라넷 영역) 원격 직원(기본 영역)

http://team/Team1

https://team.fabrikam.com/Team1

http://team/Team2

https://team.fabrikam.com/Team2

http://team/Team3

https://team.fabrikam.com/Team3

이 예제에서 루트 사이트 모음인 http://team에는 사용자용 콘텐츠가 호스팅되지 않을 수도 있습니다.

게시된 인트라넷 콘텐츠

게시된 인트라넷 콘텐츠 응용 프로그램 내의 각 하위 사이트인 HR, 시설 관리부 및 구매부에 명시적 포함이 사용됩니다. 이렇게 하면 각 사이트를 독립적으로 관리할 수 있습니다. 필요한 경우 이러한 각 사이트 모음을 서로 다른 콘텐츠 데이터베이스에 연결하여 확장을 관리하고 이러한 사이트를 개별적으로 백업 및 복원할 수 있습니다.

이 모델에서는 명시적 포함을 사용하여 다음 표와 같은 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은 인트라넷의 기본 홈 페이지를 나타냅니다. 이 사이트는 사용자용 콘텐츠를 호스팅합니다.

와일드카드 포함: 파트너 웹 및 내 사이트

파트너 웹 및 내 사이트에 모두 와일드카드 포함이 사용됩니다. 와일드카드 포함은 사용자가 사이트 모음을 직접 만들 수 있는 응용 프로그램에 적합합니다. 와일드카드 포함은 와일드카드 뒤에 나오는 다음 항목이 사이트 모음의 루트 사이트임을 나타냅니다.

내 사이트

내 사이트는 셀프 서비스 사이트 만들기를 지원합니다. 인트라넷을 탐색하는 사용자가 내 사이트를 처음 클릭하면 해당 사용자에 대한 내 사이트가 자동으로 만들어집니다. 이 모델에서 내 사이트에는 /personal(http://my/personal)이라는 와일드카드 포함이 들어 있습니다. 내 사이트 기능에서는 URL에 사용자 이름을 자동으로 추가합니다.

이를 통해 다음 표에 나열된 형식의 URL이 만들어집니다.

내부(인트라넷 영역) 원격 직원(기본 영역)

http://my/sites/user1

https://my.fabrikam.com/personal/user1

http://my/sites/user2

https://my.fabrikam.com/personal/user2

http://my/sites/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

이 모델에는 파트너 웹에 대한 예외가 나와 있습니다. 이러한 예외는 회사 인터넷 사이트용 콘텐츠를 제작 및 준비하는 데 전용으로 할당된 두 사이트 모음입니다. 이러한 두 사이트 모음에는 명시적 포함이 사용됩니다. 이는 동일한 웹 응용 프로그램에서 명시적 포함과 와일드카드 포함을 모두 사용하는 방법을 보여 주는 예입니다.

관리 URL

다음 표에서는 서버 팜에 호스팅되는 각 응용 프로그램의 관리 영역에 대한 URL을 보여 줍니다.

응용 프로그램 URL

게시된 인트라넷 콘텐츠

http://fabrikam.admin

팀 사이트

http://teams.admin

내 사이트

http://my.admin

파트너 웹

http://partnerweb.admin

회사 인터넷 사이트

http://fabrikamsite.admin

이 모델에서는 관리자가 내부에서 회사 네트워크에 액세스한다고 가정합니다.

영역 정책

웹 응용 프로그램에 대한 정책을 만들어 웹 응용 프로그램 수준에서 사용 권한을 적용할 수 있습니다. 정책을 웹 응용 프로그램에 일반적으로 정의하거나 특정 영역에 대해서만 정의할 수 있습니다. 정책을 사용하면 웹 응용 프로그램이나 영역 내의 모든 콘텐츠에 사용 권한이 적용됩니다. 정책 사용 권한은 사이트 및 콘텐츠에 대해 구성된 다른 모든 보안 설정보다 우선합니다. 사용자 또는 사용자 그룹을 기준으로 정책을 구성할 수 있지만 SharePoint 그룹은 기준으로 사용할 수 없습니다.

이 모델에서는 다음을 위한 몇 가지 정책의 예제를 보여 줍니다.

  • 관리자가 모든 콘텐츠에 액세스할 수 있도록 허용합니다.

  • 게시된 콘텐츠에 대한 쓰기 액세스 권한을 거부합니다.

  • 제작자 및 테스터에게 게시된 콘텐츠에 대한 적절한 액세스 권한을 부여합니다.

이 문서의 다운로드

이 항목은 다운로드 가능한 다음 문서에도 포함되어 있어 더 쉽게 읽고 인쇄할 수 있습니다.

사용 가능한 문서의 전체 목록은 다운로드 가능한 Office SharePoint Server 2007 관련 콘텐츠 (영문)를 참조하십시오.