내보내기(0) 인쇄
모두 확장

가상 SharePoint 2013 팜의 자세한 디자인 및 시스템 지정 프로세스

 

적용 대상: SharePoint Server 2013, SharePoint Foundation 2013

마지막으로 수정된 항목: 2013-12-18

요약: SharePoint 2013 팜 및 Hyper-V 호스트 컴퓨터의 세부 토폴로지 디자인 및 시스템 요구 사항 사양 작성 프로세스를 구현합니다.

이 문서에는 가상화된 SharePoint 2013 팜의 세부 아키텍처 및 시스템 요구 사항을 작성하는 데 사용할 수 있는 예제가 포함되어 있습니다. 이 아키텍처는 팜 서버 역할에 사용되는 가상 컴퓨터와 팜 서버로 사용할 수 있는 실제 컴퓨터, 그리고 가상화 호스트 컴퓨터로 구성됩니다. 세부 디자인은 이처럼 가상 컴퓨터와 실제 컴퓨터를 모두 포함하는 가상 환경의 이중성을 반영하며 가상 컴퓨터, 가상화 호스트 컴퓨터, 네트워크 및 저장소의 제약 조건과 요구를 수용해야 합니다.

세부 디자인은 프로덕션 환경의 새 SharePoint 팜에 적용되는 모든 비즈니스 및 기술 기준과 기대치를 충족해야 합니다. 효율적인 디자인에서는 작업 지원, 지속적인 유지 관리 작업 및 향후 업그레이드도 고려합니다.

이 문서의 내용

이 문서에서는 허용되는 모범 사례에 따라 세부 팜 토폴로지, 가상화 아키텍처 및 가상 컴퓨터와 Windows Server 2008 Hyper-V 기술 컴퓨터의 시스템 요구 사항 사양을 작성하는 데 필요한 프로세스를 단계별로 안내합니다. SharePoint 2013용 가상화 계획 세우기가상 팜 요구 사항 파악 섹션에 설명되어 있는 방식에 따라, 실제 플랫폼에 배포되는 팜을 디자인하는 것과 같은 방식으로 토폴로지와 서버를 처리하는 것이 좋습니다. SharePoint 2013 요구 사항은 기술과는 관계가 없으므로 토폴로지 및 시스템 사양을 기본 가상 계층으로 확장하기에 충분한 정보를 수집할 때까지는 가상화 요소를 파악할 필요가 없습니다. 또한 반복 프로세스를 통해 디자인을 작성 및 구체화하는 것이 좋습니다. 이러한 프로세스에서는 먼저 가용성과 성능 같은 필수 및 중요 요구 사항을 파악합니다. 이 기술은 디자인을 구체화 및 완성하는 데 필요한 정보를 수집할 때 자주 사용되며 효율성이 입증되었습니다.

디자인 프로세스의 일부분으로, 팜 토폴로지와 시스템 사양이 최초 프로덕션 이전 배포 단계(대개 POC(개념 증명) 또는 파일럿 환경)에 적합한지를 확인하기 위한 평가 기준도 마련해야 합니다.

참고참고:
이 문서에서는 성능과 관련하여 벤치마크 테스트를 작성 및 실행하는 방법에 대해 자세히 설명하지 않으며 벤치마크 데이터 분석 및 해석 지침도 제공하지 않습니다.

요구 사항을 파악한 후에는 다음과 같은 일련의 단계를 지침으로 하여 디자인 및 사양 프로세스를 계속합니다.

  1. SharePoint 2013 솔루션 및 아키텍처 지침에 따라 배포할 솔루션에 가장 적합한 토폴로지를 작성합니다.

  2. 초안 토폴로지 디자인을 사용하여 필요한 팜 서버의 수를 확인하고 역할에 따른 각 서버의 최소 구성 요구 사항을 문서화합니다. 이러한 데이터는 단순히 기준일 뿐이며 최종 팜 디자인 및 구성 사양이 아니라는 점을 기억해야 합니다.

  3. 가상화 인프라를 포함하도록 팜 토폴로지를 확장합니다. 여기서도 게시된 지침을 사용해 모든 가상화 호스트 컴퓨터에 대한 최적의 팜 서버 역할 분산을 결정합니다. 이 단계의 일부분으로 각 호스트 컴퓨터가 호스트에 배포하려는 가상 컴퓨터를 지원하는 데 필요한 리소스를 예측합니다.

    참고참고:
    가상화 호스트 컴퓨터의 기능 및 제한을 아키텍처에 반영해야 합니다.
  4. 계속해서 토폴로지를 구체화하여 프로덕션 이전 환경에 테스트 팜을 배포하는 데 적합한 디자인을 완성합니다. 토폴로지를 구체화함과 동시에, 팜 가상 컴퓨터 또는 호스트 컴퓨터의 구성 요구 사항에 대한 추가 정보가 수집되면 시스템 사양을 조정할 수 있습니다. 이전 배포의 벤치마크 데이터가 없는 경우 시스템 사양은 추정치이며, 벤치마크 테스트를 통해 의미 있는 결과가 확인되면 사양을 조정할 수 있습니다.

이 문서의 프로세스 및 지침은 Windows Server 2008 Hyper-V 기술 솔루션을 사용하여 SharePoint 제품을 설치 및 구성하는 방법을 중점적으로 설명합니다. 그러나 SVVP(서버 가상화 유효성 검사 프로그램)에서 인증하는 모든 가상화 솔루션에 이 전략을 적용할 수 있습니다. 자세한 내용은 서버 가상화 프로그램 FAQ를 참조하세요.

이 문서에서는 SharePoint 제품 팜에 필요한 가상 컴퓨터 또는 가상화 호스트 컴퓨터를 설치 및 구성하는 방법은 자세히 설명하지 않습니다. 자세한 내용은 SharePoint 2013 가상 컴퓨터 및 Hyper-V 환경에 모범 사례 구성 사용를 참조하십시오.

참고참고:
이 SharePoint 2013 릴리스의 경우 Windows Server 2012의 가상화 변경 내용 및 기능은 지원되지 않습니다.

이 문서에서는 다음과 같은 주제에 대한 다양한 수준의 설명을 제공합니다. 그러나 각 주제 영역에 대한 자세한 내용은 별도의 문서에서 제공됩니다.

  • 비즈니스 연속성 - 가상 환경의 고가용성 및 재해 복구

  • 보안 - Hyper-V 가상화 호스트 컴퓨터 보호를 위한 모범 사례

  • 성능 및 용량

  • 유지 관리 및 운영

세부 디자인을 작성할 때는 먼저 SharePoint 2013 및 이를 지원하는 가상화 인프라에 대한 기능/기술/운영 요구 사항을 설정 및 검토하고 우선 순위를 설정합니다. 우선 순위를 설정하는 이유는 각 관련자의 우선 순위가 상충할 수 있기 때문입니다. 그리고 각 조직 구성 단위 간에도 요구 사항(실제로는 기대치)이 크게 다릅니다. 예를 들어 사용자는 항상 빠른 응답 속도를 기대하는 반면 IT 보안 그룹에는 시스템 침입 위험을 줄이는 디자인이 필요하기 때문입니다.

요구 사항 파악 및 우선 순위 설정 프로세스를 진행할 때는 디자인이 팜에 대해 적합하여 프로덕션 이전 환경에서 배포할 수 있는 시기를 결정하기 위해 점수 매기기 기준도 개발해야 합니다.

다양한 방식과 도구를 사용하여 요구 사항의 우선 순위를 설정할 수 있으며, 특정 시나리오에 가장 적합하거나 올바른 방식은 없습니다. 예를 들어 이 문제와 관련하여 가장 많이 사용되는 방식 중 하나는 요구 사항을 필수, 매우 중요 등으로 분류하는 것입니다. 가중치 지정 시스템이나 순위 체계를 사용하여 우선 순위를 설정하는 방식도 있습니다. 어떤 방법을 사용하든, 신뢰할 수 있는 우선 순위를 설정하여 요구 사항을 파악 및 구체화할 때 일관성 있게 적용할 수 있도록 하는 방식을 선택하십시오.

요구 사항을 주요 범주로 그룹화한 다음 개별 범주로 세분화하여 특정 요구 사항에 대한 세부 정보를 제공하는 것이 좋습니다. 예를 들어 '보안'은 매우 범위가 넓은 범주이며, 필요한 사용자 권한 수준 또는 팜 기능이나 구성 요소에 액세스할 수 있는 사용자에 대한 세부 정보는 보안 시스템을 이해, 디자인 및 구현하는 데 있어 매우 중요합니다.

참고참고:
요구 사항을 구분하는 경우의 이점은 관련성이 높은 세부 정보를 보다 효율적으로 파악하고 필요한 사항을 놓칠 가능성을 줄일 수 있다는 것입니다. 그러나 범주는 서로 분리되지 않으며 항상 겹치거나 상호 종속됩니다. 따라서 이러한 중복 및 주요 종속성을 파악 및 통합할 수 있는 전체적인 디자인 방식을 사용해야 합니다.

이 문서에서는 4가지 주요 범주를 사용하여 디자인 요구 사항을 그룹화합니다. 이러한 범주(우선 순위 순서)는 다음과 같습니다.

  • 고가용성

  • 보안

  • 성능

  • 용량

참고참고:
성능과 용량은 상호 의존적인 항목이지만 독자의 편의를 위해 여기서는 개별 범주로 구분합니다.

고가용성을 디자인할 때는 먼저 조직에서 업무 지원을 위해 갖춰야 하는 SharePoint 가용성 수준을 확인해야 합니다. 일반적으로 조직의 고가용성 요구 사항은 업무 유형, 전역화 수준, 고객 및 파트너에 의해 정의됩니다. 내부 측면에서는 개별 사업부뿐 아니라 조직 전체에 필요한 가용성 수준을 문서화해야 합니다.

참고참고:
HA(고가용성) 및 DR(재해 복구)은 보다 광범위한 BCM(비즈니스 연속성 관리) 전략과 프로세스에 속합니다. 이 문서에서는 팜을 프로덕션 상태로 설정하는 데 필요한 직속 디자인 요소에 대해 중점적으로 설명합니다. 재해 복구 요구 사항은 아키텍처 디자인 프로세스에서 무시해서는 안 되는 매우 중요한 요소입니다. 따라서 DR 요구 사항, 모범 사례 및 옵션에 대해 보다 중점적이고 자세하게 설명하기 위해 재해 복구를 별도의 배포 후 작업으로 분류하기로 했습니다.

다음 단계에서는 모든 팜 구성 요소를 평가하여 가용성에 대한 잠재적 영향을 확인하고, 항상 사용할 수 있는 구성 요소 제공을 위한 옵션을 검토한 다음 아키텍처에 가장 적합한 옵션을 결정합니다.

참고참고:
비용은 조직에서 항상 중요한 요인으로 작용하지만, 가용성 저하가 업무에 줄 수 있는 잠재적 영향에 대한 비용의 가중치를 고려해야 합니다.

고가용성 측면에서 최소한 다음과 같은 팜 구성 요소를 평가하는 것이 좋습니다.

  • SharePoint 데이터베이스

  • 응용 프로그램 서버

  • 프런트 엔드 웹 서버

  • 검색 등의 SharePoint 서비스 및 기능

  • 팜에 사용되는 가상 컴퓨터

  • 여러 가상화 호스트 컴퓨터로 팜 서버 역할 분산

  • 가상화 호스트 컴퓨터

  • 라우터, 전원 부하 분산 장치 등의 인프라 요소

가상화를 사용하는 경우 적절한 조치를 취해야 하는 보안 계층이 추가로 적용됩니다. 가상화 호스트 컴퓨터에서는 호스팅 대상 가상 컴퓨터에 단일 액세스 지점을 제공하는데, 이로 인해 공격 범위가 넓어집니다. 또한 가상 네트워크 역시 팜 네트워크를 보호하는 데 있어 추가적인 문제를 유발할 수 있습니다.

조직에는 대개 IT 시스템과 인프라의 보안 및 인증을 관리하기 위한 정책, 절차 및 도구가 이미 있습니다. Windows Server 2008 또는 Windows Server 2008 R2를 실행하는 서버를 보호할 때 사용하는 것과 같은 방법을 사용하여 가상화 서버를 보호해야 합니다. 또한 가상 컴퓨터, 구성 파일 및 데이터를 보호하기 위한 추가 대책도 구현해야 합니다. Windows Server 2008 작업을 보호하는 방법에 대한 자세한 내용은 Windows Server 2008 보안 가이드를 참조하세요.

SharePoint 2013에서는 새로운 기능, 새로 디자인된 기능 및 확장된 기능을 제공하므로 팜 서버 성능 특성과 리소스 요구 사항이 SharePoint 2010 제품의 요구 사항과는 다릅니다. 각 팜 서버의 리소스 요구 사항을 이해하려면 SharePoint 2013에 도입된 변경 사항을 상세하게 파악해야 합니다. 사용 프로필이나 성능 데이터와 같은 이전 데이터를 팜 서버 시스템 사양의 기준으로 사용하려는 경우에는 이러한 변경 내용의 영향을 파악하는 것이 특히 중요합니다. 성능에 대한 자세한 내용은SharePoint Server 2013에서 성능 및 용량 관리 계획를 참조하십시오.

사용 현황 데이터

이전의 사용 현황 데이터를 활용하면 기준 테스트에 사용할 수 있는 테스트 매개 변수를 보다 쉽게 얻을 수 있습니다. 그러나 이러한 데이터는 새 SharePoint 2013 기능의 컨텍스트에서 평가해야 합니다. 또한 이러한 기능이 사용자 동작 패턴에 줄 수 있는 영향을 확인합니다. 예를 들면 다음과 같습니다.

  • 기존 기능을 개선하는 경우 대개 더 많은 사용자가 해당 기능을 더 자주, 더 오래 사용하게 됩니다.

  • 새로운 기능이나 확장된 기능은 개선된 기능과 같은 영향을 주며, 많은 요청이 있었던 기능이 이전에는 제공되지 않았던 경우를 비롯한 일부 경우에는 SharePoint 사용량이 크게 증가합니다.

  • 인수 합병 등의 결과로 사용자층의 규모가 크게 증가하는 경우에도 사용 프로필에 영향을 줍니다.

사용 패턴(예: 동시 연결의 수, 평균 연결 시간)의 변화는 전체 시스템 요구 사항에 큰 영향을 줄 수 있습니다.

성능 데이터

성능 데이터는 시스템에서 작업을 처리하는 동안 사용되는 컴퓨터 리소스(예: CPU 사용량, 메모리)와 더불어 서버가 해당 역할에 따라 SharePoint 작업을 처리하는 효율성에 대한 척도를 제공합니다. 팜 서버 그룹의 전체 처리량을 다른 성능 척도로 사용할 수도 있습니다. 최적의 성능을 얻으려면 작업을 처리하는 데 충분한 컴퓨터 리소스를 사용할 수 있어야 합니다. 소프트웨어 필수 구성 요소를 제외한 시스템 요구 사항 사양에서는 서버 역할에 대해 기대되는 부하를 처리하기 위한 각 서버의 구성을 지정해야 합니다. 서로 다른 부하에서 미리 결정된 작업을 수행할 때의 성능 데이터를 수집하는 반복적인 테스트(벤치마크)의 결과로 최종 구성이 완성됩니다. 프로젝트 팀 테스터가 벤치마크 데이터를 기준과 비교하여 부하 및 작업이 성능에 주는 영향을 확인합니다. 이전 데이터를 사용할 수 있는 경우에는 성능 테스트의 기준을 보다 쉽게 작성할 수 있습니다.

중요중요:
다시 디자인되었거나 업데이트된 모든 기능의 성능 특성을 철저하게 테스트하고, 전체 시스템 성능에 대한 해당 기능의 영향을 파악해야 합니다. 이러한 기능 중 일부는 성능 요구를 크게 또는 식별 가능할 정도로 높이지 않을 수도 있습니다. 그러나 기능에 의해 발생하는 부하를 다른 팜 서버 역할로 옮길 수 있습니다. 특정 역할에 대한 추정 사항은 새로운 벤치마크 테스트를 수행하여 반드시 실제로 확인해야 합니다.

조직에서 첫 번째로 배포된 SharePoint 팜의 경우에는 이전 데이터를 참조하여 성능 기준을 설정할 수 없습니다. 즉, SharePoint 2013용으로 제공되는 지침 및 제한을 사용하여 기준을 새로 작성해야 합니다. 기준 설정 방법과는 관계없이, 특정 데이터를 수집하도록 설계된 여러 벤치마크 테스트를 실행하여 아키텍처 디자인 및 시스템 요구 사항 사양을 구체화해야 합니다.

중요중요:
각 서버 역할에 대한 성능 테스트 분석 결과를 조합하여 전체 팜 성능에 대한 성능 프로필을 만들어야 합니다. 이렇게 하면 팜의 성능 병목 현상을 쉽게 파악할 수 있습니다.

SharePoint 2013 팜의 용량 요구 사항을 파악한 후에는 팜, 팜의 서버 및 가상화 인프라의 규모를 지정합니다. 이 단계와 관련하여 팜 설계자가 중점적으로 확인하는 두 가지 주요 영역은 콘텐츠 저장소와 팜 성능입니다. 용량에 대한 자세한 내용은 SharePoint Server 2013의 용량 관리 및 크기 조정 개요을 참조하십시오.

SharePoint 2013는 단순 텍스트 파일에서 대형 미디어 파일에 이르기까지 다양한 콘텐츠 형식을 처리하는 기능을 제공합니다. 이러한 기능으로는 콘텐츠 만들기/편집, 공동 작업을 위한 공유, 장/단기 저장, 보관 등이 있습니다. 크기 지정 측면에서 볼 때 디자인은 단기적인 요구 사항을 충분히 처리할 수 있어야 합니다. 콘텐츠 데이터베이스가 확장되면 팜을 수직 확장하여 이러한 확장을 수용할 수 있습니다.

용량과 관련하여 두 번째로 중요한 요소는, 필요한 성능 수준을 일관되게 충족하거나 초과하는 팜의 기능입니다. 성능 용량은 보통 미리 정의된 임계값 집합과 비교하여 팜 서버에 적용되는 부하의 종류로 정의 및 평가됩니다. 임계값은 허용 가능한 부하와, 제한 초과 시 팜을 불안정한 상태로 만드는 부하를 정의하는 데 사용되는 구성 가능한 제한입니다. 자세한 내용은 SharePoint 2013의 소프트웨어 경계 및 제한 사항을 참조하십시오.

참고참고:
성능 용량은 일반적으로 페이지 로드 시간 등의 콘텐츠 제공 측정값도 포함합니다.

팜의 성능 용량은 팜이 지원하는 솔루션을 기준으로 하는 팜의 크기와 여러 팜 구성 요소의 특징에 의해 결정됩니다. 이러한 구성 요소의 예로는 팜 서버 자체, 네트워크 대역폭, 대기 시간, 페이지 디자인, 사용자 지정 코드 등이 있습니다.

성능의 경우와 마찬가지로, 팜이 조직에서 첫 번째로 배포한 SharePoint 2013 팜인지 아니면 기존 팜인지에 따라 용량 계획 전략이 결정됩니다.

하드웨어 계층부터 시작하여 가상 팜에 대해 적절하게 정의된 아키텍처는 가상화 호스트 컴퓨터, 네트워크 인프라, 저장소 시스템 및 SharePoint 2013 환경의 일부분인 가상 컴퓨터로 구성됩니다. 유형이 다른 아키텍처 디자인의 경우 실제 팜 서버도 포함됩니다. 이 문서의 그림에서 지침으로 제공하는 디자인에 따라 세부 아키텍처 및 시스템 사양 작성을 위한 자체 프로세스 및 기준을 설정하십시오. 그리고 가상 환경에서 배포하려는 SharePoint 제품 솔루션의 요구 사항과 조직의 요구 사항을 모두 반영하도록 작업 방식을 조정하십시오.

이 문서에서 소개하는 디자인 전략은 모델링 및 반복을 통해 실제 테스트를 수행할 수 있는 가상 팜 아키텍처 및 시스템 사양을 작성합니다.

모델링은 솔루션에 대해 SharePoint 제품 팜 배포의 모든 구성 요소를 확인할 수 있는 매우 유용한 가상화 도구입니다. 모델에 시스템 사양이 포함되는 경우에는 필요한 모든 사양을 파악 및 문서화했는지 확인하는 검사도 수행할 수 있습니다. 모델은 작은 문서이므로 관련자들에게 쉽게 제공할 수 있으며, 관련자 역시 쉽게 검토하여 의견을 제공할 수 있습니다.

모델에서 사용할 세부 정보의 양은 전적으로 개발자가 선택합니다. 이 문서에서 디자인 프로세스를 보여 주기 위해 사용하는 모델은 팜 서버, 각 서버에서 설치 및 구성되는 SharePoint 제품 구성 요소, 그리고 각 서버의 시스템 사양으로 구성됩니다. SharePoint 제품 처리 워크플로 또는 네트워크 인프라의 경우 모델 유용성은 유지하면서 최대한 간단한 모델을 제공하기 위해 포함하지 않기도 했습니다.

반복 디자인 프로세스는 응용 프로그램 및 시스템 디자인을 위한 널리 알려진 뛰어난 방식입니다. 반복 디자인을 사용하는 경우 다음과 같은 여러 가지 이점이 있습니다.

  • 누락되었거나 잘못된 정보를 파악할 수 있습니다.

  • 추가 조사가 필요한 의심스러운 디자인 요소나 시스템 사양을 쉽게 파악할 수 있습니다.

다음 작업 목록에서는 가상 팜과 지원 인프라를 작성, 구성 및 배포하는 주요 단계를 설명합니다.

  1. 실제 서버에 배포되는 팜용 아키텍처 모델 및 시스템 사양을 작성합니다.

  2. 실제 아키텍처 및 시스템 사양을 서식 파일로 사용하여 예비 가상 팜 아키텍처 및 필요한 지원 실제 플랫폼을 만듭니다.

    팁팁:
    SharePoint 2013, SQL Server 및 Hyper-V와 관련하여 기술 백서, KB 문서 등의 자세한 기술 참조 자료를 수집합니다. 이 정보를 사용하여 디자인 도구로 사용할 수 있는 기술 자료를 만듭니다. 이 기술 자료는 프로덕션 이전 테스트 중에 테스트 팀이 성능 문제를 해결하고 최적의 솔루션을 확인하는 가장 효율적인 방법을 결정해야 하는 경우 매우 유용합니다.
  3. 가상화 호스트 컴퓨터와 해당 시스템 사양을 모델에 추가합니다.

  4. 반복 디자인 프로세스를 시작합니다. 아키텍처 모델을 분석하여 모델이 팜 솔루션에 필요한 모든 요소를 지정하는지 확인합니다. 그런 다음 각 팜 서버의 시스템 사양에 대해 적합성 테스트를 수행하고, 팜 디자인 또는 사양을 조정하는 데 사용할 수 있도록 누락되었거나 불완전한 정보를 확인 및 수집합니다.

  5. 새로운 정보나 업데이트된 정보를 통합하여 분석 결과를 토대로 아키텍처를 구체화합니다.

  6. 추가 반복 과정(검토->수정->검토)을 시작합니다. 이 과정을 계속하여 아키텍처 및 사양을 평가하고 구체화합니다. 최종적으로는 가상 팜의 모든 요소가 POC(개념 증명) 또는 제한된 파일럿과 같은 프로덕션 이전 환경에서 팜을 배포 및 테스트하기 위한 기준을 충족해야 합니다.

  7. 팜을 배포합니다.

사용 가능한 경우 이전 데이터를 사용하거나, 아니면 SharePoint 2013용으로 제공되는 요구 사항 및 지침을 사용하여 실제 아키텍처 모델을 만듭니다. 이전 데이터를 사용하는 경우에는 디자인이 새로운 기능이나 업데이트된 기능도 모두 포함하도록 요구 사항 및 업데이트된 지침과 관련한 새로운 정보로 해당 데이터를 보완하는 것이 좋습니다.

중요중요:
실제 서버에서 SharePoint 제품을 설치 및 구성할 때 수행하는 것과 같은 작업을 수행하고 동일한 시간을 할애하는 것이 가장 좋습니다. 이렇게 하면 실제 디자인 및 시스템 사양을 가상 환경으로 변환할 때 효율적입니다. 또한 가상 컴퓨터 및 가상화 호스트 컴퓨터에서 토폴로지와 크기를 불필요하게 변경할 필요가 없어집니다.

모델이 적절하며 새 팜의 요구 사항을 효과적으로 처리한다고 판단되면 실제 보기를 가상 환경으로 매핑할 수 있습니다.

예제 팜

팜 디자인 및 시스템 사양을 만들고 구체화하는 프로세스를 보여 주기 위해, 이 문서에서는 검색을 사용하도록 구성된 중소 규모 팜을 사용합니다. 예제를 쉽게 파악할 수 있도록 하기 위해, 실제 디자인에서 고려해야 하는 다른 서비스 응용 프로그램은 포함되어 있지 않습니다.

다음 그림에서는 실제 컴퓨터에 배포된 예제 팜을 보여 줍니다. 개념 증명 또는 파일럿 팜으로 배포하는 데 적합한 시스템 사양 및 가상 팜 아키텍처를 개발하는 프로세스에서는 이 팜을 기준으로 사용합니다.

그림 1. 실제 컴퓨터에 배포된 중소 규모 팜

실제 서버의 팜 아키텍처
참고참고:
그림 1의 번호가 지정된 레이블(1X - 6X)은 확인이 필요한 팜 구성 요소 또는 서버 구성을 나타냅니다.

실제 팜 토폴로지 디자인 및 시스템 사양을 기준으로 하여 가상 환경을 모델링합니다. 가상 환경에는 Hyper-V 호스트 컴퓨터가 포함됩니다.

참고참고:
가상화 호스트 컴퓨터의 기능 및 잠재적 재한을 완전히 파악하여 디자인 계획의 일부분으로 포함해야 합니다.

가상 모델을 개발할 때는 다음과 같은 작업 순서를 기준으로 사용하십시오.

  1. 실제 모델 및 시스템 사양을 최종적으로 검토하여 가상 모델의 기준으로 적절한 디자인 및 크기를 사용하고 있는지를 확인합니다.

    실제 모델에서 사양을 전송하기 전에 주요 구성을 파악합니다. 그러면 SharePoint 2013 요구 사항을 점검하여 구성 또는 누락 정보를 확인할 수 있습니다. 이 문서에서 소개하는 예제의 경우 다음 사항을 확인할 수 있습니다.

    1. 각 프런트 엔드 웹 서버(FE-1, FE-2)는 24GB RAM을 사용하도록 구성됩니다. 이 메모리 구성은 특히 검색 구성 요소를 호스팅하는 응용 프로그램과 비교할 때 높은 값처럼 보입니다.

    2. 두 응용 프로그램 서버(SA-1 및 SA-2)는 검색 구성 요소 호스팅 전용입니다. RAM 구성은 적절해 보이지만 인덱스의 하드 디스크 용량은 충분하지 않을 수 있습니다.

    3. 세 번째 응용 프로그램 서버(AP-1)는 팜의 다른 응용 프로그램 역할과 마찬가지로 나머지 검색 구성 요소를 호스팅합니다. 고가용성은 프로비전되지 않습니다.

    4. AP-1 응용 프로그램 서버에는 메모리가 충분합니다. 그러나 하드 디스크 용량은 충분하지 않을 수 있습니다.

    5. 데이터베이스 서버(SQ-1 및 SQ-2)에는 하드 디스크 요구 사항 관련 정보가 없으며 메모리 구성은 너무 낮아 보입니다.

    6. 항상 사용할 수 있는 데이터베이스에 대한 요구 사항이 나와 있기는 하지만 고가용성 솔루션에 대한 구체적인 정보는 제공되지 않습니다.

  2. 필요한 가상 컴퓨터의 수를 파악하고 각 가상 서버의 역할을 실제 모델의 해당 서버에 매핑합니다.

  3. 실제 서버 사양을 사용하여 각 가상 컴퓨터의 구성(프로세서 수, 메모리의 양, 디스크 공간)을 문서화합니다. 실제 모델에서 사양을 전송하는 동안 주요 구성을 파악합니다. 그러면 SharePoint 2013 요구 사항을 점검하여 의심스러운 구성을 확인할 수 있습니다.

    참고참고:
    SharePoint 2013 팜의 서버에 대한 사양을 확인하는 동안 SQL Server 요구 사항도 확인해야 합니다.
  4. 호스트 컴퓨터에 대한 가상 컴퓨터 분산을 결정합니다. 여러 호스트 컴퓨터에 가상 컴퓨터를 분산시킬 방법을 결정할 때는 팜 가용성 요구 사항, 최적의 성능을 위한 역할 분산 모범 사례, 최소 호스트 컴퓨터 수, 호스트 용량(알려진 경우) 등의 요인을 고려하십시오.

  5. 가상화 호스트 컴퓨터에 대한 팜 서비스 분산을 점검하여 호스트 컴퓨터에 오류가 발생하는 경우 이러한 서비스를 사용하지 못할 위험이 있는지를 확인합니다.

  6. 가상 컴퓨터 용량 요구 사항을 사용하여 최소 호스트 컴퓨터 시스템 사양(코어 수, 메모리, 로컬 하드 디스크 또는 네트워크 저장소)을 결정합니다.

    참고참고:
    가상 컴퓨터 및 가상화 호스트 컴퓨터에 대한 구성 모범 사례를 사용합니다. 자세한 내용은 SharePoint 2013 가상 컴퓨터 및 Hyper-V 환경에 모범 사례 구성 사용를 참조하십시오.
  7. 가용성, 성능 및 용량 디자인 목표를 고려하여 일반 네트워크 요구 사항, 저장소 요구 사항 및 전원 요구 사항을 파악합니다.

    "디자인 전략 선택 및 주요 작업 파악" 섹션에서 설명한 것처럼, 이 문서에서 설명하는 모델은 최대한 간단하게 유지해야 하므로 네트워크 및 저장소 요구 사항은 자세하게 다루거나 설명하지 않습니다.

  8. 아키텍처 및 시스템 사양을 검토하고 각 Hyper-V 호스트 컴퓨터에 대해 반영되지 않은 리소스를 파악합니다. 추가 호스트 컴퓨터 용량에 따라 호스트 컴퓨터에서 가상 컴퓨터를 수직 확장할 수 있는 범위 또는 호스트 컴퓨터에 가상 컴퓨터를 추가하여 팜을 수평 확장할 수 있는지 여부가 결정됩니다.

가상 아키텍처 모델 및 시스템 사양의 첫 버전을 완성한 후에는 반복 프로세스를 수행하여 아키텍처 및 시스템 사양을 구체화하는 것이 좋습니다. 이러한 반복 프로세스의 목표는 시스템을 작성하는 데 사용된 가정 사항과 디자인 요구 사항을 검증하는 것입니다. 또한 이 프로세스를 통해 솔루션과 팜의 기능 요구 사항을 검토하여 모델을 구체화하기 전에 고려해야 하는 변경 내용이 없는지도 확인할 수 있습니다. 마지막으로, 새로운 벤치마크 데이터 또는 업데이트된 제품 사양이 있는 경우 해당 정보를 수정된 모델에 통합할 수 있습니다.

SharePoint 2013 팜 아키텍처 및 시스템 사양을 분석하는 프로세스에서는 팜 토폴로지와 서버 구성이 프로덕션 환경에서 팜을 배포하기 전에 변경되며 배포 후에도 어느 정도 변경된다는 점을 기억해야 합니다. 변경 정도와 범위는 솔루션에 따라 다르지만, 변경이 진행된다는 점은 염두에 두고 디자인 검토 전략에 포함해야 합니다.

다음 그림에는 실제 팜용으로 작성된 토폴로지 및 시스템 사양을 사용하는 가상 아키텍처의 첫 번째 초안이 나와 있습니다. 가상 컴퓨터와 같은 수의 팜 서버가 구현되었으며, 실제 서버와 같은 역할이 할당되었습니다. 가상 컴퓨터는 Hyper-V 호스트 서버 두 대에 분산되어 있습니다. 실제 모델에 사용된 고가용성 디자인과 일치하도록 하려면 최소 두 개의 Hyper-V 호스트가 필요합니다.

중요중요:
다음 다이어그램에 나와 있는 가상 컴퓨터 및 Hyper-V 호스트 컴퓨터의 시스템 사양은 설명용으로만 제공되며, 반드시 이 사양을 사용해야 하는 것은 아닙니다.
가상 컴퓨터는 SharePoint 2013의 하드웨어 및 소프트웨어 요구 사항 문서에 설명되어 있는 것처럼 각 서버 역할에 대한 최소 요구 사항에 따라 구성되었습니다.

그림 2. Hyper-V 호스트 컴퓨터 두 대가 있는 가상 팜 토폴로지

가상화된 팜의 초기 아키텍처
참고참고:
그림 2의 번호가 지정된 레이블(1X - 5X)은 확인이 필요한 팜 구성 요소 또는 서버 구성을 나타냅니다.

이 문서에서 사용하는 디자인 검토 방식은 디자인에 대한 기본 프레임워크를 제공하며, 3개 단계(범주)로 구성됩니다. 다음 단계를 기준으로 하여 고유 디자인 검토 프로세스를 개발할 수 있습니다.

  1. 가상 팜 아키텍처 및 이를 지원하는 실제 플랫폼의 디자인 검토를 수행합니다.

  2. 가상 컴퓨터 및 가상화 호스트 컴퓨터의 시스템 사양을 분석합니다.

  3. 아키텍처 및 시스템 사양을 단일 엔터티로 검토합니다.

    참고참고:
    아키텍처 또는 시스템 사양을 구체화하는 데 필요한 수준의 세부 정보를 확보하기 위해 필요한 만큼 주요 검토 단계 또는 범주를 세분화합니다.

가상 아키텍처 및 실제 아키텍처 디자인 평가

가상 아키텍처는 특정 팜 서버 역할에 대한 가용성 전략을 실제 모델로 구현합니다. 이 모델에서는 데이터베이스에 대한 고가용성 요구 사항 외에 프런트 엔드 웹 서버 중복성도 유지됩니다. 검색 쿼리 및 검색 인덱스 구성 요소를 호스팅하는 두 응용 프로그램 서버(SA-1, SA-2)에 대해서도 가용성이 유지됩니다.

참고참고:
가상 아키텍처에서 실제 아키텍처의 가용성 디자인이 유지되기는 하지만, 가상화 전략의 일부분으로 포함되어야 하는 가용성이 개선되지는 않습니다.

호스트 컴퓨터 두 대를 사용하고 이러한 호스트로 팜 서버 역할을 분산시키면 두 가지 목표를 달성할 수 있습니다. 첫째로, 팜 서버에서 대부분의 요소가 단일 오류 지점에 취약해지지 않습니다. 둘째로, 역할을 분산시키면 작업도 분산되므로 전체 팜 성능도 개선됩니다.

디자인 결함

디자인에서 해결해야 하는 문제는 다음과 같습니다.

  • 프런트 엔드 서버의 중복성 수준은 프로덕션 이전 환경에는 적합하지만, 팜을 프로덕션 상태로 설정하기 전에 다시 평가해야 합니다. 프런트 엔드 웹 서버 하나를 사용할 수 없게 되면 팜의 콘텐츠 제공 기능이 50% 감소합니다. 가상화 호스트 컴퓨터에는 고가용성 옵션이 없습니다. Host-2에 오류가 발생하는 경우에는 팜이 계속 작동할 수 있지만 Host-1에 오류가 발생하는 경우에는 팜이 작동하지 않습니다.

  • 모든 응용 프로그램 서버에 대해 고가용성 기능이 제공되지는 않습니다. AP-1의 검색 관리 구성 요소 및 검색 분석 구성 요소의 경우 두 인스턴스가 모두 같은 Hyper-V 호스트에서 실행되기 때문에 가용성 면에서 취약점이 있습니다.

  • 가상화 호스트 컴퓨터에 대해서도 고가용성 옵션은 제공되지 않습니다. Host-2에서 오류가 발생하는 경우에는 팜이 계속 작동하며 서비스가 중단되지 않지만, Host-1에서 오류가 발생하면 콘텐츠 크롤링 또는 분석 처리와 같은 주요 서비스를 사용할 수 없게 됩니다.

가상 컴퓨터 시스템 사양 분석

가상 컴퓨터 시스템 사양은 실제 모델의 서버 구성을 기반으로 합니다. 이러한 사양을 검토하면 두 가지 구성이 적합성 테스트를 통과하지 않음을 확인할 수 있습니다. 즉, 다음 서버에 대해서는 추가 정보가 필요합니다.

  • 프런트 엔드 웹 서버. 이 문서에서 사용하는 구성에서는 SharePoint 2013 요구 사항을 다시 확인한 후 메모리 구성을 콘텐츠를 제공하는 시스템에 대한 권장 최소값인 8GB로 줄였습니다. 웹 서버 구성에서 확인해야 하는 또 다른 요소는 가상 프로세서의 수입니다. 여기서는 이러한 서버에 가상 프로세서 4개가 필요한지를 확인해야 합니다.

  • 데이터베이스 서버. 이러한 서버의 경우 메모리 사양이 낮은 것으로 보입니다. 그러나 이 모델에서는 데이터베이스 트랜잭션의 유형이나 예상 볼륨에 대한 정보가 제공되지 않습니다.

  • 저장소 역시 추가로 확인해야 하는 영역입니다. 데이터베이스 서버의 경우 시스템 디스크에 필요한 용량 정보만 나와 있고 다른 데이터베이스 하드 디스크의 용량 요구 사항 관련 정보는 없습니다.

Hyper-V 호스트 컴퓨터 시스템 사양 분석

Hyper-V 호스트 컴퓨터(Host-1 및 Host-2)에 대한 시스템 사양이 나와 있는 다음 표에서는 메모리, 프로세서 구성 및 확장성을 기준으로 사용하여 가상화 호스트 컴퓨터의 성능 용량을 분석한 내용을 보여 줍니다.

Hyper-V 호스트 컴퓨터(Host-1 및 Host-2)의 시스템 사양

사양 분석

메모리

Host-1: 96GB RAM

총 메모리 요구 사항은 68GB(4GB 오버헤드 허용, 가상 컴퓨터용으로 64GB)입니다. 이 경우 가상 컴퓨터 수직 확장 또는 팜 수평 확장용으로 28GB RAM을 사용할 수 있습니다.

참고참고:
Hyper-V 가상화 호스트 컴퓨터에 대해 허용되는 메모리 오버헤드는 대개 2GB로 예측됩니다. 그러나 가상화된 SharePoint 제품 환경에서는 메모리 요구 사항을 계산할 때 오버헤드로 4GB를 사용하는 것이 좋습니다.

Host-2: 96GB RAM

총 메모리 요구 사항은 48GB(4GB 오버헤드 허용, 가상 컴퓨터용으로 44GB)입니다. 이 경우 가상 컴퓨터 수직 확장 또는 팜 수평 확장용으로 48GB RAM을 사용할 수 있습니다.

프로세서

가상 CPU와 논리 CPU의 비는 Host-1에서는 2:1이고 Host-2에서는 1.5:1입니다. 이러한 비율은 적절한 제한 범위 내에 포함됩니다.

참고참고:
가상화된 SharePoint 제품 환경에서는 가상화 호스트 컴퓨터에서 초과 수용(oversubscribe)된 CPU보다 가상 컴퓨터 메모리 할당이 성능에 훨씬 더 큰 영향을 줍니다.

확장성

두 호스트 컴퓨터에는 모두 가상 컴퓨터를 수직 확장하거나 가상 컴퓨터를 더 추가하여 수평 확장을 하는 데 충분한 리소스가 있습니다.

참고참고:
Hyper-V 호스트 컴퓨터 CPU 아키텍처
Hyper-V 호스트에서 CPU 초과 수용(oversubscribe) 상태는 문제가 되지 않습니다. 그러나 가상화 호스트 CPU 아키텍처에서 HT(하이퍼스레딩) 기술을 지원하는지 여부는 알아 두면 유용합니다. HT 기능은 성능을 향상시키기 때문입니다.

이 문서에서는 요구 사항을 중점적으로 검토하여 자세한 정보를 파악한 후에 아키텍처와 시스템 사양을 업데이트합니다. 다음 단계에서는 팜의 다음 측면에 대한 정보를 수집합니다.

  • 데이터베이스 용량 요구 사항

    팜 데이터베이스(특히 콘텐츠 데이터베이스)의 크기는 사용할 데이터베이스 파일의 수와 저장소 시스템에서 이러한 파일의 분산을 예측하기 위한 결정 요인입니다. 또 다른 유용한 정보로는 저장할 데이터 형식(문서, 미디어), 주로 수행하는 데이터베이스 작업(읽기, 업데이트), 거버넌스 및 예상 확장 요구 사항 등이 있습니다.

  • 로컬 및 공유 저장소 요구 사항

    저장소 문제를 전반적으로 해결하기 위한 추가 정보가 필요합니다. 이 시점에서는 모든 저장소가 로컬인지, 로컬 저장소와 공유 네트워크 저장소를 함께 사용할지를 모르는 상태입니다. 프런트 엔드 웹 서버 및 검색 응용 프로그램(SA-1, SA-2) 서버에는 SharePoint 제품 바이너리 및 인덱스용으로 충분한 저장 공간이 있는 것으로 보이지만, 다른 응용 프로그램 서버(AP-1)에 있는 기타 모든 서비스 및 검색 구성 요소에 대한 저장소 요구 사항은 확인해야 합니다.

    가상화 호스트 컴퓨터(Host-1, Host-2)에 대한 저장소 요구 사항을 결정하기 위해 전체 저장소 전략도 파악해야 합니다. 위의 모델을 기준으로 하면 로컬 저장소만 사용되는 것으로 보이며, 이는 하드 디스크 레이아웃 및 가상 컴퓨터 배치에 영향을 줍니다.

  • 가상 하드 디스크 구성

    가상 하드 디스크 구성은 호스트 컴퓨터 저장소 요구 사항 및 구성에 직접적인 영향을 줍니다. 예를 들어 호스트에서 로컬 저장소를 사용하는 경우 직접 연결된 실제 디스크(통과 디스크라고도 함) 구성에서는 가상 컴퓨터의 모든 하드 디스크를 예약합니다. 가상 컴퓨터 하드 디스크 구성은 SAN 스냅숏 등의 백업 및 복원 옵션에도 영향을 주며, 가상화 호스트 컴퓨터 고가용성 구성에도 영향을 줄 수 있습니다.

    s

  • 고가용성

    응용 프로그램 서버에서 고가용성이 제공되지 않는 문제를 해결하기 위한 추가 정보가 필요합니다. 고가용성은 데이터베이스 서버의 요구 사항으로 지정되어 있지만, 사용하려는 솔루션(예: 클러스터링 또는 미러링)에 대한 구체적인 정보가 필요합니다. 이러한 사항은 아키텍처, 특히 데이터베이스 시스템 사양에 영향을 주기 때문입니다.

추가 모델 변경 내용

아키텍처 및 시스템 사양 변경의 정도와 범위는 초기 디자인 검토 및 시스템 사양 분석의 결과에 따라 결정됩니다.

구현 계획 역시 프로세스에서 중요한 역할을 할 수 있습니다. 구현 계획을 통해 구현할 변경 내용과 각 변경의 우선 순위를 결정할 수 있기 때문입니다. 특히 수량화할 수 있는 중요한 이점이 없는 경우 다음 시나리오는 변경할 필요가 없을 수도 있습니다. 다음과 같은 경우를 예로 들 수 있습니다.

  • 개념 증명 또는 파일럿 배포 단계의 초기 테스트에 예비 아키텍처가 적합한 경우

  • 가상화 호스트 컴퓨터가 테스트 전용이며 사용자 수용 테스트 시에는 해당 컴퓨터를 교체하려는 경우. 이러한 경우에는 확장성 또는 가용성 문제를 해결할 필요가 없습니다.

  • 팜을 테스트 또는 평가용으로 사용할 예정이며 이러한 작업이 완료되면 팜을 해제하려는 경우

팁팁:
향후 테스트 작업을 위해 팜을 다시 만들 수 있도록 가상 컴퓨터를 보관해 둘 수 있습니다.

권장 사항 및 요청을 추가로 확인하여 디자인 및 시스템 사양 검토의 결과에서 얻은 정보를 파악한 후에는 모델 및 시스템 사양을 업데이트할 수 있습니다.

다음 그림에는 누락된 정보 및 세부 사항과 함께 권장 변경 내용이 통합되어 수정된 모델이 나와 있습니다. 여기서는 프로덕션 팜에 보다 적합한 수정된 아키텍처를 보여 줍니다.

그림 3. 수정된 가상 팜용 아키텍처

가상화된 팜의 수정된 아키텍처

가상 아키텍처 및 실제 아키텍처 디자인 평가

수정된 가상 아키텍처 및 실제 아키텍처는 이전 검토에서 제기된 문제를 반영한 여러 변경 내용을 구현합니다. 수정된 아키텍처에서는 첫 번째 모델의 두 호스트를 수직 확장하는 대신 가상화 호스트 플랫폼을 수평 확장하기로 결정했습니다.

참고참고:
가상화 호스트 컴퓨터 수직 확장 또는 수평 확장에 대한 결정은 조직의 하드웨어 전략에 의해 결정되며, 이 전략은 IT 표준, 비즈니스 목표, 예산 등의 요인을 기반으로 합니다. 추가 용량을 제공하기 위한 두 방식을 모두 사용할 수 있으며, 각 확장 방식을 선택하는 경우 장단점이 있습니다.

또한 새로운 아키텍처는 다음 목표를 충족하도록 디자인되었습니다.

  • 모든 팜 서버에 고가용성을 제공하고 가용성 수준을 높입니다.

  • 팜 및 해당 구성 요소를 수직 확장하거나 수평 확장할 수 있도록 하여 확장성을 개선합니다.

  • Hyper-V 호스트 간에 가상 컴퓨터를 보다 유동적으로 이동할 수 있도록 하여 필요한 경우 작업의 균형을 다시 조정하고 용량 또는 하드웨어 오류로 인해 가상 호스트 컴퓨터 기능이 떨어지는 경우 실시간 마이그레이션을 수행할 수 있도록 합니다.

이러한 목표를 달성하기 위해 다음과 같은 사항이 변경되었습니다.

  • 보다 효율적으로 부하를 분산하고 해당 특정 팜 역할의 가용성을 높이기 위해 프런트 엔드 웹 서버의 수가 4대로 늘어났습니다.

  • 가상화 호스트 컴퓨터의 수가 4대로 증가했으며, 다음과 같은 구성을 사용함으로써 이러한 각 컴퓨터의 용량도 증가했습니다.

    • CPU: 16개 코어(하이퍼스레딩 사용)

    • 메모리: 96GB

  • SQL Server 2012 AlwaysOn 사용 가능 그룹을 사용하여 데이터베이스 서버에 대한 고가용성을 구현했습니다.

    호스트 컴퓨터 2대가 추가됨으로써 Hyper-V 호스트 하나(Host-3)를 AG-1 사용 가능 그룹의 PR(주 복제본) 전용으로 지정하기 위한 충분한 용량이 확보되었습니다. SR(보조 복제본)은 Host-2에 설치되며, 이 호스트 역시 SQL Server 2012 실행 전용으로 지정됩니다. 이 전략을 사용하는 경우 팜 데이터베이스 서버의 용량과 성능이 증가합니다. 그러나 가상화 호스트 컴퓨터 사용률이 떨어집니다. 데이터베이스 가상 컴퓨터의 메모리를 32GB로 늘려도 미할당 메모리 60GB가 남아 있습니다. 가상 프로세서 대 논리 프로세서의 비율은 1:4에 불과해, 가상화 호스트 컴퓨터가 크게 수용 미달(undersubscribe) 상태가 됩니다.

    이에 따라 Hyper-V 호스트를 보다 효율적으로 사용하는 데이터베이스 구성을 사용하기로 결정하고, 작업 균형을 보다 효율적으로 조정하여 데이터베이스 성능을 높였으며, 가용성을 추가로 개선했습니다. 이 구성에서는 두 개의 사용 가능 그룹(AG-1 및 AG-2)을 사용합니다. AG-2의 주 복제본은 AG-1의 보조 복제본과 Host-2를 공유하며, AG-2의 보조 복제본은 AG-1의 주 복제본과 Host-3을 공유합니다.

    수정된 아키텍처 및 시스템 사양에서 주목해야 할 또 다른 측면은, 데이터베이스 가상 컴퓨터에 대해 통과 디스크를 사용하기로 결정한 것입니다. 이 구성에서는 SQL Server를 실행하는 가상 컴퓨터에 대해 하드 디스크 구성을 위한 모범 사례 지침을 따릅니다. 데이터베이스 서버에 대해 권장되는 Hyper-V 디스크 구성은 통과 디스크입니다. 통과 디스크는 고정 크기 디스크에 비해 성능은 약간 더 우수할 뿐이지만, 대용량 디스크 및 디스크 I/O를 많이 사용하는 응용 프로그램(SharePoint 제품 데이터베이스의 널리 알려진 특성)에는 통과 디스크가 보다 효율적입니다. 또한 통과 디스크를 사용하는 경우 다른 가상 하드 디스크가 실제 디스크에 액세스할 수 없으므로 디스크 경합도 발생하지 않습니다.

  • 가상화 호스트를 수평 확장하면 가상 컴퓨터 작업의 균형을 보다 유동적으로 조정할 수 있습니다.

  • 가상화 호스트 컴퓨터 4대를 사용하면 장애 조치(failover) 클러스터링 구현을 위한 효율적인 기반을 마련할 수 있을 뿐 아니라, 가상 컴퓨터의 신속한 실시간 마이그레이션도 가능해집니다. 자세한 내용은 클러스터의 컨텍스트에서 Hyper-V 및 가상 컴퓨터 이해(http://technet.microsoft.com/library/dd759249.aspx)를 참조하십시오.

가상화 호스트 컴퓨터 시스템 사양 분석

가상화 호스트 컴퓨터(Host-1, Host-2, Host-3, Host-4)에 대한 수정된 시스템 사양이 나와 있는 다음 표에서는 메모리, 프로세서 구성 및 확장성을 기준으로 사용하여 가상화 호스트 컴퓨터의 성능 용량을 분석한 내용을 보여 줍니다.

가상화 호스트 컴퓨터(Host-1, Host-2, Host-3, Host-4)에 대한 수정된 시스템 사양

사양 분석

메모리

각 가상화 호스트 컴퓨터에 4GB RAM을 허용한 후 Hyper-V 호스트 컴퓨터의 미할당 메모리는 다음과 같습니다.

  • Host-1: 36GB

  • Host-2: 28GB

  • Host-3: 28GB

  • Host-4: 36GB

모든 호스트 컴퓨터의 미할당 메모리는 실시간 마이그레이션 또는 확장을 위해 충분한 용량을 제공합니다.

프로세서

수정된 아키텍처에서 가상 프로세서 대 논리 프로세서의 비율은 다음과 같습니다.

  • Host-1: 1:1

  • Host-2: 1:2

  • Host-3: 1:2

  • Host-4: 1:1

이러한 비율은 적절한 제한 범위 내에 포함됩니다.

확장성

수정된 아키텍처에서는 팜 전체 및 모든 팜 구성 요소에 대해 확장성을 지원합니다.

이처럼 아키텍처 디자인과 시스템이 변경되어 최초 모델에 비해 개선되었습니다. 그러나 여기서도 반복 프로세스를 통해 다음 작업을 수행해야 합니다.

  • 데이터베이스 서버 가상 컴퓨터를 위한 저장소 전략(로컬 또는 공유 네트워크)과 관련하여 보다 자세한 사양 제공. 이를 위해 팜에 저장할 콘텐츠의 형식 및 볼륨에 대한 정보를 수집해야 합니다.

  • 프런트 엔드 웹 서버에 대한 사양 구체화. 이를 위해 동시 연결 수, 평균 연결 시간 등의 예상 사용 방식 관련 정보를 수집해야 합니다.

검토 및 수정을 반복하는 필수 횟수 또는 최적의 횟수는 없습니다. 추가 수정 시 디자인 또는 시스템 사양이 크게 개선되지 않는 단계에 도달할 때까지 해당 주기를 계속하십시오. 이 단계가 되면 실제 환경에서 팜을 테스트해야 합니다.

아키텍처 및 시스템 사양을 아무리 자세하게 작성한다고 해도, 이러한 모든 정보는 팜을 프로덕션 이전 테스트 환경에 배포하고 일련의 벤치마크를 수행할 때까지는 이론적인 데이터에 불과합니다. 필요한 벤치마크 횟수는 하드웨어 전략에 따라 다릅니다. 해당 전략이 높게 지정된 요구 사항을 기준으로 하는 경우 벤치마크 요구 사항은 감소합니다.

팁팁:
필요한 것 이상의 용량 및 성능 기능을 제공하는 하드웨어 비용에 대해, 포괄적인 벤치마크를 수행하는 데 필요한 비용과 시간의 가중치를 계산하십시오. 상황에 따라 하드웨어에 투자하는 것이 더 효율적일 수도 있습니다.

벤치마크에서는 효율적인 플랫폼 간 변경을 평가한 후 구현하기 위해 필요한 데이터를 제공합니다. 첫 번째 벤치마크 데이터 집합을 통해 필요한 변경의 범위, 특성 및 정도를 파악할 수 있습니다. 일반적으로 배포 팀이 고려하는 첫 번째 변경은 다음과 같습니다(우선 순위 순서 아님).

  • 작업 분산을 위해 팜 토폴로지 아키텍처 변경

  • 가상 컴퓨터 수직 확장 또는 가상 컴퓨터를 추가하여 팜 수평 확장

  • Hyper-V 호스트 컴퓨터 수직 확장 또는 호스트 컴퓨터를 더 추가하여 하드웨어 플랫폼 수평 확장

배포 팀은 이러한 변경의 우선 순위, 변경으로 인해 얻을 수 있는 이점 및 영향을 확인해야 합니다. 이러한 결정을 내리는 데 사용할 수 있는 데이터가 충분하지 않을 수도 있으므로 추가 벤치마크가 필요할 수 있으며, 원하는 데이터를 얻기 위해 벤치마크도 변경해야 할 수 있습니다.

참고참고:
프로덕션 환경에서 사용할 모니터링 및 보고 전략과 도구를 테스트하는 것이 좋습니다. 프로덕션 이전 팜에 대해 테스트를 수행하면 팜이 프로덕션 상태로 전환될 때 완전히 작동하는 모니터링 및 보고 기능을 바로 적용할 수 있습니다.

요약하자면, 아키텍처 및 시스템 사양은 프로덕션 이전 단계에서 프로덕션 단계로 이동함에 따라 계속해서 개선됩니다. 따라서 팜이 프로덕션 환경에서 안정될 때까지 벤치마크를 계속 실행하는 것이 좋습니다.

이 정보가 도움이 되었습니까?
(1500자 남음)
의견을 주셔서 감사합니다.
Microsoft는 MSDN 웹 사이트에 대한 귀하의 의견을 이해하기 위해 온라인 설문 조사를 진행하고 있습니다. 참여하도록 선택하시면 MSDN 웹 사이트에서 나가실 때 온라인 설문 조사가 표시됩니다.

참여하시겠습니까?
표시:
© 2014 Microsoft