SharePoint 2010: 중복성과 가용성을 위한 SharePoint 2010 구축
고가용성과 중복성을 염두에 두고 계획한다면 SharePoint 2010 배포에서 투자 가치를 많이 회수할 수 있습니다.
William Stanek
SharePoint 2010은 투자 가치 잠재력이 높은 플랫폼입니다. 중복성과 고가용성을 염두에 두고 배포를 구축한다면 투자 가치를 기대 이상으로 회수할 수 있습니다. 엔터프라이즈의 규모와는 관계없이 환경을 주의 깊게 계획하면 부가적인 이익을 거둘 수 있습니다.
SharePoint 2010은 이전 제품들과는 다릅니다. SharePoint Portal Server 2003을 사용하고 있거나 32비트 환경에서 MOSS(Microsoft Office SharePoint Server) 2007을 실행하고 있다면 사용 중 업그레이드가 불가능할 수 있습니다. SharePoint 2010은 64비트 버전의 Windows Server 2008 또는 Windows Server 2008 R2에서만 실행됩니다. 또한 64비트 버전의 SQL Server 2005, SQL Server 2008 또는 SQL Server 2008에서 실행 중인 R2 SQL Server 데이터베이스가 필요합니다.
하드웨어가 이러한 요구 사항을 충족하는 경우 전체 서버 팜을 사용 중 업그레이드할 수 있습니다. 다양한 방법으로 기존 환경을 새 환경으로 마이그레이션할 수도 있습니다. 업그레이드 프로세스를 지원하기 위해 그림 1에 나오는 업그레이드 전 검사를 수행할 수 있습니다. 이에 대한 설명은 TechNet Magazine 2010년 6월 기사 “SharePoint 2010으로의 업그레이드 준비”를 참조하십시오.
그림 1 업그레이드 전 검사를 통해 배포 준비도 테스트
예산에 대한 고민이 많은 IT 관리자라면 이러한 요구 사항을 감안해야 합니다. SharePoint 2010이 실제로 원하는 기능을 제공할 수 있는지 여부도 궁금할 것입니다. 분명한 것은 SharePoint 2010이 소셜 컴퓨팅, 콘텐츠 관리, 문서 처리, 엔터프라이즈 검색, 비즈니스 인텔리전스, 응용 프로그램 개발 및 웹 생산성에 있어 새롭고 향상된 기능을 풍부하게 제공한다는 것입니다.
SharePoint 2010은 또한 확장성, 관리 효율성 및 제어 부분에서 큰 발전을 이루었습니다. 소셜 컴퓨팅의 향상된 기능에는 태그, 등급, 풍부한 프로필, 탐색을 위한 소셜 피드백, 소셜 책갈피, 검색 및 필터링이 포함됩니다. 또한 새로운 웹 기반 공동 작업 제작 도구와 확장된 클라이언트 기능도 있습니다.
선택 가능한 클라이언트에는 이제 Office, 전체 브라우저, 그리고 SharePoint Workspace를 사용한 모바일 모드와 오프라인 모드가 포함됩니다. 보고 기능이 향상되어 모니터링 기능으로 잠재적인 문제를 더 신속하게 식별할 수 있습니다. Business Connectivity Service는 데이터 연결과 읽기/쓰기 기능을 더 풍부하게 제공합니다. 조직의 문서와 미디어 파일을 저장하는 리포지토리인 자산 라이브러리는 이제 개체를 수백만 개까지 포함할 수 있습니다.
Visio 및 SharePoint Designer에 추가된 향상된 워크플로, Visual Studio 2010 통합을 통해 제공되는 더 강력한 개발자 도구, Silverlight 통합, 개발자 대시보드와 디버깅 도구까지 SharePoint 2010으로 전환하여 활용 가능한 매력적인 장점이 많습니다.
아직 SharePoint를 고려해 보지 않았다면 바로 지금이 최적의 시기입니다. Orlando ITxpo 2010에서 Gartner Inc.의 분석가는 2015년이 되면 SharePoint가 소비자 제품 부문에서 아이폰과 아이패드 수준의 인기 있는 플랫폼이 될 것으로 예측했습니다.
상황에 맞는 구성
물론 SharePoint 2010이 모든 상황에 맞는 한 가지 구성을 제공하지는 않습니다. 기본 제공 데이터베이스를 포함하는 단일 서버 환경, SQL Server 데이터베이스를 포함하는 단일 서버 환경, 그리고 다중 계층을 포함하는 다중 서버 환경에 이르기까지 다양한 설치 옵션이 있습니다.
2계층 환경에서는 SharePoint 서버 구성 요소와 데이터베이스 구성 요소를 분리된 서버에 설치합니다. 이 경우 SharePoint가 있는 첫째 계층을 웹(또는 프런트 엔드) 계층이라고 하며, SQL Server가 있는 둘째 계층을 데이터베이스(또는 백 엔드) 계층이라고 합니다. 3계층 환경의 경우 그림 2에 나오는 것처럼 SharePoint가 있는 프런트 엔드 웹 서버, 중간 계층 응용 프로그램 서버, 그리고 백 엔드 데이터베이스 서버가 모두 함께 작동하여 SharePoint 사이트와 서비스를 제공합니다.
.jpg)
그림 2 3계층 SharePoint 2010 서버 팜
모든 환경에 최소 4개의 프로세스 코어와 8GB 이상 RAM을 갖춘 64비트 하드웨어가 필요합니다. Windows Server 2008 및 Windows Server 2008 R2에는 기본적으로 IPv4와 IPv6이 설치되고 활성화됩니다. 두 프로토콜이 모두 활성화된 경우 IPv6이 우선 사용됩니다. SQL Server와 SharePoint 2010은 모두 IPv6을 지원하지만 SharePoint 2010이 올바르게 작동하려면 모든 최종 사용자 URL이 AAAA 레코드를 포함한 DNS 이름에 기반을 두고 있어야 합니다.
IPv6 리터컬 주소를 사용하는 SharePoint URL로 브라우징하는 것은 리터럴 주소 형식이 필요한 특정한 관리 기능을 제외하고는 지원되지 않습니다. 이 경우 http://[2001:db8:85a3:8d3:1319:8a2e:370:7344]와 같이 리터럴 주소를 대괄호로 묶어야 합니다.
서버 가상화 역시 하나의 가능성입니다. Windows Server 2008 Hyper-V 기술을 사용하여 SharePoint Server 2010 팜의 일부로 VM(가상 시스템)을 구성할 수 있으며 이를 프런트 엔드 웹 서버, 중간 계층 응용 프로그램 서버 및 백 엔드 계층 데이터베이스 서버로도 사용이 가능합니다. VM은 외부에 있는 서버 및 부모 파티션과 통신하는 데 외부 네트워크를 사용합니다. 또한 동일한 실제 서버에 있는 다른 VM 및 부모 파티션과 통신하는 데는 내부 네트워크를 사용하며, 동일한 실제 서버에 있는 다른 VM과만 통신하는 데는 개인 네트워크를 사용합니다.
아키텍처: 매크로부터 마이크로까지
SharePoint 2010 구현을 위한 논리적인 아키텍처에 대해 살펴보겠습니다. 이 아키텍처는 매크로 수준의 서버 팜으로 시작해서 마이크로 수준으로 드릴다운하면 사이트와 페이지가 있습니다. 서버 팜은 콘텐츠에 대한 물리적 격리를 제공합니다. 추가적인 격리 요구 사항을 충족하려면 다른 자산 라이브러리를 위한 다른 서버 팜을 구성할 수 있습니다. 성능 및 확장 목표를 달성하기 위해 추가적인 서버 팜을 만드는 것도 가능합니다.
SharePoint 2010에는 서비스를 독립적으로 관리하고 중앙으로 집중할 수 있는 새로운 서비스 아키텍처가 도입되었습니다. 서비스 응용 프로그램 리소스를 활용하면 서비스를 사용자 지정하고 하나의 팜 내에서, 그리고 때로 여러 팜에 걸쳐 공유할 수 있습니다. 단일 서버 팜 내에 동일한 서비스 응용 프로그램의 여러 인스턴스를 배포하는 것도 가능합니다. 새로운 서비스 응용 프로그램이 제공되므로 이제 더 이상 SharePoint 서비스를 단일 SPP(공유 서비스 공급자) 내에 포함시킬 필요가 없습니다. 서비스 응용 프로그램은 서비스 설정 및 데이터베이스 하나 이상을 포함하거나 서비스 설정만 포함할 수 있습니다.
서비스 응용 프로그램은 여러 논리적 아키텍처 구성 요소 중 하나입니다. 다른 구성 요소로는 SharePoint가 만들고 사용하는 IIS 웹 사이트인 웹 응용 프로그램이 있습니다. 필요한 서비스만 사용하도록 웹 응용 프로그램을 구성할 수 있으며, 각 사이트가 하나의 영역으로 처리되는 IIS 웹 사이트를 최대 5개까지 포함하도록 각 웹 응용 프로그램을 확장하는 것도 가능합니다. 영역은 동일한 웹 응용 프로그램에 액세스하는 다른 논리적 경로(URL)입니다.
SharePoint 2010에서 웹 응용 프로그램과 서비스를 만드는 경우 이러한 항목은 지정하는 응용 프로그램 풀에 연결됩니다. 응용 프로그램 풀은 하나 이상의 작업자 프로세스를 통해 서비스가 제공되는 URL의 그룹입니다. 각 응용 프로그램 풀에는 자체 작업자 프로세스가 있으며, 각 응용 프로그램 풀을 격리하는 데 도움이 되는 별도의 ID를 가질 수도 있습니다.
웹 응용 프로그램 내의 모든 콘텐츠에 사용 권한을 적용하는 데는 정책을 사용합니다. 기본적으로 웹 응용 프로그램의 모든 콘텐츠는 단일 콘텐츠 데이터베이스에 저장됩니다. 콘텐츠를 사이트 컬렉션 수준에서 여러 데이터베이스로 분리할 수도 있습니다. 한 콘텐츠 데이터베이스가 사이트 컬렉션을 하나 이상 포함할 수는 있지만 한 사이트 컬렉션이 여러 데이터베이스에 걸칠 수는 없습니다. 일반적으로 웹 응용 프로그램별 콘텐츠 데이터베이스가 100개를 넘는 경우는 거의 없습니다.
사이트 컬렉션은 소유자가 동일하고 관리 설정을 공유하는 웹 사이트의 집합입니다. 각 사이트 컬렉션은 최상위 웹 사이트 하나를 포함하며 일반적으로 하위 사이트를 하나 이상 포함합니다. 사이트는 관련 웹 사이트 하나 이상과 사이트 컬렉션에서 호스트되는 다른 항목으로 구성됩니다. 콘텐츠 데이터베이스별 사이트 컬렉션은 최대 50,000개로 제한하는 것이 좋으며, 실제로 10,000개 이하를 사용해야 최적의 성능이 보장됩니다.
사이트 컬렉션을 여러 데이터베이스 서버로 병렬 확장하십시오. 이 전략으로 저장소 용량과 처리량을 늘릴 수 있습니다. 또한 일반적인 경우에는 사이트 컬렉션당 사이트의 수를 최대 250,000개로 제한하는 것이 좋으며, 백업과 업그레이드를 간소화하려면 5,000개 미만으로 제한하는 것이 바람직합니다.
SharePoint 2010 서버 환경의 전체적인 복잡도는 궁극적으로 조직이나 특정 프로젝트의 세부적인 요구 사항에 따라 달라집니다. 다양한 구현과 구성을 제공하여 다양한 필요성을 충족할 수 있습니다. 예를 들어 한 프로젝트에는 팀이나 부서 수준에 자산 라이브러리 하나를 사용하고, 다른 프로젝트에는 전체 조직에 대한 중앙 리포지토리를 사용할 수 있습니다. 계획에는 최소한 몇 가지 요소가 포함되어야 합니다.
- 디지털 자산 관리 역할 식별: 참가자와 관계자를 구분합니다.
- 자산 사용 분석: 다양한 디지털 자산을 사용하는 사용자, 관련된 디지털 자산의 유형, 그리고 자산을 사용하는 방법을 식별합니다.
- 자산 라이브러리 구성 계획: 필요한 라이브러리의 수, 라이브러리를 만들 위치, 라이브러리를 사용하는 방법 및 이를 구성하는 방법을 결정합니다.
- 콘텐츠 유형 계획: 특정 라이브러리에 포함시킬 콘텐츠의 유형(예: 텍스트, 이미지, 오디오 및 비디오)을 결정합니다.
- 콘텐츠 제어 계획: 각 콘텐츠 범주에 대한 적절한 제어 수준, 저장소 위치, 그리고 감사, 보존 및 레이블 지정을 위해 적용해야 하는 정책을 결정합니다.
- 콘텐츠 워크플로 계획: 각 라이브러리 내에서 문서 버전 관리, 체크 아웃 및 체크 인 사용 여부 및 사용 방법을 결정합니다.
이미지, 오디오 및 비디오와 같은 회사의 미디어 자산을 문서 및 다른 유형의 텍스트 파일에서 함께 또는 별도로 관리할 수 있습니다. 일반적으로 단일 또는 분리 사이트 컬렉션 방식을 사용하여 디지털 자산을 구성하는 것이 좋습니다. 단일 사이트 방식의 경우 콘텐츠 데이터베이스가 모든 미디어 자산을 비롯한 모든 사이트 콘텐츠를 포함합니다.
분리 사이트 컬렉션 방식의 경우 사이트 콘텐츠와 미디어 자산에 다른 컬렉션을 사용합니다. 예를 들어 사이트 콘텐츠용으로 사이트 컬렉션 1이라는 콘텐츠 데이터베이스를 설정하고, 미디어 자산용으로 사이트 컬렉션 2이라는 콘텐츠 데이터베이스를 설정할 수 있습니다. 문서 파일에서 미디어 파일을 분리하는 것이 좋은 경우도 많습니다. 이렇게 하면 두 가지 데이터 유형을 별도로 관리하고 더 신속하게 병렬로 확장할 수 있습니다.
매크로 수준에서 자산 아키텍처를 고려할 때는 특히 다음과 같은 일반적인 구성에 대해서도 고려해야 합니다.
- 비트 전송률 제한: 비트 전송률 제한을 사용하면 미디어 파일 및 데이터 다운로드 속도를 측정하고 전체 성능이 저하되지 않도록 할 수 있습니다. 자산 라이브러리에 오디오 및 비디오와 같은 큰 파일이 포함되어 있는 경우 반드시 비트 전송률 제한을 사용해야 합니다. 이 기능은 IIS 7의 기능이므로 모든 프런트 엔드 웹 서버 상의 IIS 7에서 이 기능을 설치, 활성화 및 구성해야 합니다.
- 디스크 기반 BLOB(Binary Large Object) 캐시: 자주 사용되는 이미지, 오디오, 비디오, 그리고 .js 및 .css 파일과 같이 웹 페이지를 표시하는 데 사용되는 파일을 포함하는 BLOB 캐싱을 제어합니다. 환경에 자산 라이브러리가 있는 경우 BLOB 캐시를 사용해야 합니다. BLOB 캐시는 IIS 7에서 활성화되며 각각의 프런트 엔드 웹 서버에 저장됩니다. 캐싱을 사용하려면 웹 서버에 저장소 공간을 충분하게 구성해야 합니다. RBS(Remote Blob Storage)를 사용하는 것도 고려할 수 있습니다. 데이터베이스에서 BLOB을 제거하면 대규모 콘텐츠를 확장하기 수월해집니다(그림 3 참조).
- 최대 파일 업로드 크기: 사용자가 서버에 업로드할 수 있는 최대 파일 크기를 제어합니다. 이 옵션은 중앙 관리를 호스트하는 서버에서 각 웹 응용 프로그램별로 구성합니다. 자산 라이브러리에 업로드해야 하는 파일의 유형과 일반적인 크기를 바탕으로 이 기능을 조정해야 합니다. 이러한 유형의 파일을 지원할 수 있는 충분한 크기의 저장소로 데이터베이스 서버를 구성하십시오.
.jpg)
그림 3 다른 콘텐츠로부터 BLOB 데이터 분리
환경이 단일 서버 환경 다중 서버 팜, 가상 서버 또는 고유 구현 중 어떤 것이든지 관계없이 엔터프라이즈 전체에서 비즈니스 연속성에 대한 계획은 필수적입니다. 비즈니스 연속성 계획은 중복성과 가용성 메커니즘을 적절하게 사용하여 회사의 디지털 자산을 보호하는 데 중점을 둡니다.
콘텐츠 보호
모든 SharePoint 2010 환경에 충분한 콘텐츠 보호를 마련해야 합니다. 콘텐츠 보호의 시작은 휴지통과 버전 제어입니다. SharePoint 2010에서는 두 가지 유형의 휴지통을 지원합니다.
- 사용자 휴지통(1단계 휴지통)
- 사이트 컬렉션 휴지통(2단계 휴지통)
휴지통을 활성화하면 항목을 두 단계로 삭제할 수 있습니다(그림 4 참조). 첫째 단계는 휴지통입니다. 이 휴지통을 사용하면 사용자가 삭제한 파일을 복원하고 항목, 목록, 문서 라이브러리 및 다른 항목을 나열할 수 있습니다. 사용자가 항목을 휴지통으로 보내서 삭제하면 이 항목은 만료되거나 복원될 때까지 휴지통에 보관됩니다. 휴지통은 사이트 수준에서 사용되며 사이트에 대한 제출, 디자인 또는 전체 제어 권한이 있는 사용자가 사용할 수 있습니다. 사용자 또는 사이트 컬렉션 관리자는 휴지통에서 항목을 복원하여 삭제된 항목을 복구할 수 있습니다.
.jpg)
그림 4 SharePoint 2010의 2단계 휴지통
사용자 및 사이트 컬렉션 관리자가 모두 휴지통에서 항목을 삭제할 수 있습니다. 여기에서 삭제된 항목은 사이트 컬렉션 휴지통으로 이동합니다. 이 휴지통은 사이트 컬렉션 관리자 수준에 있으며 사이트 관리자만 사용할 수 있습니다.
기본적으로 삭제된 항목은 30일 동안 유지됩니다. 알아둘 사실은 사용자 휴지통에서 20일이 경과하여 삭제 및 사이트 컬렉션 휴지통으로 이동된 항목은 10일만 더 경과하면 자동으로 영구 삭제된다는 것입니다.
사이트 컬렉션 관리자는 휴지통에 보관 중인 항목의 시간 제한을 설정하여 삭제된 항목의 만료를 제어합니다. 사이트 컬렉션 휴지통이 크기 제한에 도달한 경우 관리자는 수동으로 항목을 미리 삭제할 수 있습니다.
문서 버전이 생성되는 방법 및 시기를 더 잘 제어하기 위해 문서 체크 아웃과 체크 인, 그리고 콘텐츠 승인 사용 권한을 포함하는 콘텐츠 제어의 한 부분인 버전 제어를 사용하여 중복성을 구축할 수도 있습니다. 기본 문서 제어는 특정 자산 라이브러리에 한정되며 해당 자산 라이브러리에 적용된 사이트 컬렉션 템플릿에 따라 작동합니다. SharePoint 2010에는 세 가지 버전 관리 옵션이 있습니다.
- 버전 관리 없음: 버전 관리가 비활성화되며 문서의 이전 버전이 생성되지 않습니다. 결과적으로 문서 기록이 보존되지 않습니다.
- 주 버전을 만듭니다: 문서가 저장될 때마다 이전 버전을 보존합니다. 관리자는 저장할 이전 버전의 수를 제어할 수 있습니다. 자산 라이브러리에 대한 사용 권한이 있는 사용자가 문서 및 해당 주 버전을 볼 수 있습니다.
- 주 버전과 부 버전(초안)을 만듭니다: 문서의 주 버전은 게시된 버전이라고 생각할 수 있으며, 부 버전은 초안 버전이라고 생각할 수 있습니다. 주 버전은 .0으로 끝나며 부 버전은 .1, .2, .3과 같이 0이 아닌 확장자로 끝납니다. 사용자가 문서를 저장할 때마다 SharePoint도 이전 주 버전과 주 버전을 저장합니다. 읽기 권한이 있는 사용자는 문서의 주 버전을 볼 수 있으며, 일반적으로 편집 권한이 있는 사용자는 문서의 부 버전을 볼 수 있고 이를 사용하여 작업할 수 있습니다.
향상된 백업 및 복구
콘텐츠 보호 계획에는 반드시 가용성, 백업 및 복구 전략이 포함되어 있어야 합니다. 이러한 전략은 비즈니스 요구 사항, 관련된 디지털 자산의 유형, 그리고 이러한 자산의 가치에 따라 달라집니다.
고가용성을 위해서는 시스템 업데이트와 같은 계획된 가동 중지 시간과 정전과 같은 예기치 않은 가동 중지 시간의 영향을 완화하는 데 도움이 되는 서버의 컬렉션을 사용할 수 있습니다. 웹 서버와 응용 프로그램 서버를 팜에 추가하여 병렬로 확장할 수 있습니다. 이렇게 하면 서비스와 응용 프로그램의 가용성을 보장하는 데 도움이 됩니다.
백 엔드 데이터베이스 가용성을 높이려면 데이터베이스 클러스터링을 위한 도구 상자와 데이터베이스 미러링 도구에 대해 자세히 알아볼 필요가 있습니다. 데이터베이스 클러스터링은 장애 조치 클러스터링을 사용하여 가용성을 제공하며, 노드라고 하는 클러스터된 서버는 실제 케이블과 소프트웨어를 통해 연결됩니다.
한 노드가 작동하지 않으면 다른 노드가 서비스를 제공하기 시작합니다. 이 프로세스를 장애 조치라고 하며 사용자가 겪을 서비스 및 백 엔드 데이터베이스에 대한 연결 중단을 최소화하기 위한 것입니다. 장애 조치 클러스터는 높은 수준의 가용성, 확장성 및 안정성이 요구되는 응용 프로그램과 서비스의 가용성을 높여 줍니다.
데이터베이스 미러링은 주 데이터베이스에서 "미러" 또는 복제 데이터베이스로 트랜잭션을 전송하여 가용성 지원을 제공합니다. SharePoint 2010은 미러링을 위해 "자동 장애 조치 포함 보호 우선 모드" 구성을 사용하는데, 여기에는 주 서버, 미러 서버, 그리고 미러링 모니터 서버가 포함됩니다. 미러링 모니터 서버는 중단 시간을 몇 초 수준으로 줄이면서 주 서버에서 미러 서버로 자동으로 장애 조치를 수행할 수 있도록 해줍니다. 미러링은 SharePoint 콘텐츠와 구성 데이터베이스에 대한 중복을 제공합니다.
백업과 복구에서는 먼저 보호할 대상을 결정해야 합니다. 계획을 개발하는 데는 SharePoint 2010 제품 백업 및 복구 계획 통합 문서를 사용해 보십시오. SharePoint 백업과 데이터베이스 백업을 결합하면 SharePoint 인프라의 대부분을 보호할 수 있습니다.
단일 사이트 컬렉션이 한 데이터베이스에 저장된 경우 팜 수준 및 데이터베이스 수준 백업 및 복원을 사용하여 사이트 컬렉션 복구를 수행할 수 있습니다. 이러한 백업 수준을 연결되지 않은 데이터베이스 복구와 함께 사용해서 사이트 컬렉션, 사이트 목록 및 구성을 복원할 수도 있습니다. 팜 수준 및 데이터베이스 수준 백업 및 복원은 RBS 저장소에 저장된 디지털 자산을 다른 콘텐츠(RBS 공급자에 기능이 있는 경우)와 함께 백업 및 복구합니다.
그러나 이러한 백업에는 특정한 사용자 지정 유형은 포함되지 않습니다. 중앙 관리를 사용하여 수행하지 않은 web.config 파일에 대한 변경 내용은 파일 시스템 수준에서 백업해야 합니다. 마찬가지로 SharePoint를 통해 수행하지 않은 IIS 구성에 대한 변경 내용도 IIS/OS 수준에서 백업해야 합니다. SharePoint 팜의 구성 데이터베이스 및 중앙 관리 콘텐츠 데이터베이스도 복구할 수 있지만 동일한 서버를 포함하는 동일한 팜에 대한 전체 팜 복구의 일부로만 가능합니다.
서비스 응용 프로그램의 경우 관련된 데이터베이스만 복원하는 것으로는 전체 서비스 응용 프로그램을 복원할 수 없다는 것을 기억하십시오. 데이터베이스를 복원한 다음 서비스 응용 프로그램을 다시 프로비전해야 합니다. 마지막으로 SharePoint 백업 및 복구와는 별도로 SQL Server Reporting Services 데이터베이스를 백업 및 복구해야 합니다. 이러한 작업에는 SQL Server 도구를 사용합니다.
지금까지 중복성과 가용성을 제공하도록 SharePoint Server 환경을 구축하는 방법을 살펴보았습니다. SharePoint 2010에서는 모든 상황에 맞는 구성이란 없으며 물리적 아키텍처를 디자인할 때 다양한 논리적 구성 요소를 고려해야 합니다. 또한 디지털 자산을 보호할 수 있도록 SharePoint 환경을 최적으로 구성하는 방법도 고려해야 합니다.
그런데 SharePoint가 정말로 소비자 제품의 아이폰과 아이패드만큼 인기 있는 엔터프라이즈 콘텐츠 제품이 될까요? 정말로 그렇게 될지는 직접 확인해야 할 것 같습니다.
.jpg)
William R. Stanek*(williamstanek.com)은 앞서 가는 기술 전문가이자 강사이며 100권 이상의 서적을 집필한 유명한 저자이기도 합니다. 신간 및 출간 예정인 서적으로는 “Active Directory Administrator’s Pocket Consultant”(Microsoft Press, 2009), “Windows Group Policy Administrator’s Pocket Consultant”(Microsoft Press, 2009), “Microsoft SQL Server 2008 Administrator’s Pocket Consultant 2nd Edition”(Microsoft Press, 2010), “Windows 7: The Definitive Guide”(O'Reilly Media, 2009), “Windows Server 2008 Inside Out”(Microsoft Press, 2008), “Windows PowerShell 2.0 Administrator’s Pocket Consultant”(Microsoft Press, 2009), “Windows 7 Administrator’s Pocket Consultant”(Microsoft Press, 2009), “Windows Server 2008 Administrator’s Pocket Consultant, 2nd Edition”(Microsoft Press, 2009) 등이 있습니다. .twitter.com/WilliamStanek에서 Stanek을 팔로우해 보십시오.*