업그레이드 프로세스 소요 시간 및 필요 공간 예측(SharePoint Foundation 2010)

적용 대상: SharePoint Foundation 2010

마지막으로 수정된 항목: 2016-11-30

Windows SharePoint Services 3.0에서 Microsoft SharePoint Foundation 2010으로의 업그레이드를 계획하는 데 있어서는 업그레이드 프로세스의 소요 시간과 필요한 저장 공간을 확인하는 것도 중요합니다. 모든 환경은 고유하며, 서로 다른 하드웨어 기능과 사이트 특징을 포함합니다. 따라서 업그레이드를 실행하는 데 필요한 공간과 시간도 환경에 따라 크게 달라집니다. 업그레이드 프로세스에 필요한 공간과 소요 시간을 예상하는 가장 효율적인 방법은 시험 업그레이드 단계를 수행한 다음 공간 크기 및 소요 시간을 검토하는 것입니다. 시험 업그레이드를 수행하는 방법에 대한 자세한 내용은 테스트 업그레이드를 사용하여 잠재적 문제 발견(SharePoint Foundation 2010)을 참조하십시오.

이 문서의 내용

• 업그레이드에 필요한 공간 예상

• 업그레이드 소요 시간 예상

업그레이드에 필요한 공간 예상

전체 업그레이드 방식과 데이터베이스 연결 업그레이드 방식에서는 데이터베이스가 거의 확장될 수 있습니다. 또한 업그레이드 프로세스가 실행되는 동안 많은 트랜잭션이 수행되므로 발생하는 변경 내용을 저장할 수 있도록 로그 파일이 확장되어야 합니다. 즉, 두 데이터베이스와 로그 파일의 확장을 모두 계획해야 합니다.

업그레이드를 계획할 때는 업그레이드 환경과 성능이 최적화되도록 현재 환경이 Windows SharePoint Services 3.0 저장소와 관련한 최적의 방법에 따라 구성되었는지 확인해야 합니다. 자세한 내용은 실제 저장소 권장 사항(Office SharePoint Server)(영문일 수 있음)을 참조하십시오. 또한 SharePoint Foundation 2010과 관련한 최적의 구성 방법도 참조하여 업그레이드된 환경에 맞게 구성을 조정해야 합니다.

새 버전에서 테이블 구조가 변경됨에 따라 데이터를 재구성하는 동안 일시적으로 데이터베이스 크기가 증가합니다. 이 공간은 업그레이드 후에 다시 확보할 수 있지만 전체 업그레이드 또는 데이터베이스 연결 업그레이드를 실행하는 동안 데이터베이스가 현재 크기보다 50%이상 커지더라도 충분히 감당할 수 있는 공간이 있는지 확인해야 합니다. 다시 한번 말하지만 이 공간은 업그레이드 후에 데이터베이스 크기를 줄여 대부분 다시 확보할 수 있습니다. 또한 데이터베이스 서버에 일반적인 사용에 따른 데이터베이스 확장을 수용할 공간이 충분한지도 확인해야 합니다. 현재 데이터베이스의 크기를 확인하려면 Microsoft SQL Server의 엔터프라이즈 관리자를 사용하십시오. 데이터베이스 공간 외에 다음 항목에 대한 공간도 필요합니다.

• 임시 데이터베이스. 임시 데이터베이스의 급격한 증가를 수용할 수 있도록 데이터베이스 공간이 충분해야 합니다. 공간이 충분하지 않으면 업그레이드 프로세스의 시간이 초과되고 업그레이드가 실패합니다.

• 업그레이드 로그 파일

• 데이터베이스의 트랜잭션 로그 파일입니다. 데이터베이스에서 발생하는 많은 변경 내용을 저장하려면 이 로그 파일의 크기가 빠르게 증가되어야 합니다.

  참고

  대규모 환경의 경우 트랜잭션 로그 파일의 기본 증가율(10%)로는 업그레이드 프로세스를 기록하기가 어려울 수 있으며, 이로 인해 시간 초과가 발생할 수 있습니다. 이 경우에도 트랜잭션 로그 파일이 업그레이드 프로세스를 기록할 수 있는지 확인하는 가장 좋은 방법은 시험 업그레이드를 수행하는 것입니다. 환경이 매우 크거나 시험 업그레이드 중에 프로세스의 시간이 초과된 경우에는 처리해야 하는 트랜잭션 수에 대해 충분한 공간을 확보하기 위해 SQL Server 트랜잭션 로그 파일의 크기를 미리 확장할 수 있습니다. SQL Server 트랜잭션 로그 파일의 크기를 늘리는 방법에 대한 자세한 내용은 데이터베이스 확장(SQL Server 2005)(https://go.microsoft.com/fwlink/?linkid=182619&clcid=0x412) 또는 데이터베이스 확장(SQL Server 2008)(https://go.microsoft.com/fwlink/?linkid=182620&clcid=0x412)을 참조하십시오.

업그레이드 소요 시간 예상

디스크 공간 예상치를 계산하고 몇 가지 테스트를 실행한 후에는 실제 업그레이드 프로세스의 소요 시간을 대략적으로 계산할 수 있습니다. 업그레이드 시간은 환경에 따라 확연한 차이를 보입니다. 업그레이드 성능은 사용하는 하드웨어, 사이트 복잡도, 구현의 특정 특징 등에 크게 좌우됩니다. 예를 들어 큰 문서 라이브러리가 많은 경우에는 단순한 사이트에 비해 업그레이드 시간이 오래 걸릴 수 있습니다.

다음 표에서는 성능에 영향을 미치는 요인을 설명합니다.

데이터의 구조는 업그레이드 소요 시간에 영향을 미칠 수 있습니다. 예를 들어 각각 10개 항목이 포함된 목록 10,000개보다 10,000개 항목이 포함된 목록 10개를 업그레이드하는 데 걸리는 시간이 짧습니다. 목록 인프라를 업그레이드하는 데 필요한 작업은 항목 수에 관계없이 각 목록마다 수행해야 하므로 목록 수가 많을수록 작업도 늘어납니다. 이 원칙은 위 테이블의 "콘텐츠 요인"에 나열된 대부분의 항목에 적용됩니다.

하드웨어의 구조도 성능에 큰 영향을 미칠 수 있습니다. 일반적으로 데이터베이스 서버의 성능이 웹 서버 성능보다 중요하지만 하드웨어 성능 부족 또는 연결 문제는 두 계층 중 어디에서든 업그레이드 성능에 크게 영향을 미칠 수 있습니다.

업그레이드 프로세스의 소요 시간은 선택한 업그레이드 방식에 따라서도 크게 달라집니다. 데이터베이스 연결 업그레이드가 가장 빠른 방법이지만 업그레이드 전 단계와 업그레이드 후 단계가 전체 업그레이드에 비해 오래 걸립니다. 전체 업그레이드의 경우 사이트는 물론 환경까지 업그레이드하기 때문에 시간이 좀 더 걸리지만 업그레이드 전/후에 수행할 단계가 데이터베이스 연결 업그레이드보다 적습니다.

전체 업그레이드 소요 시간을 예상하는 가장 효율적인 방법은 데이터 중 일부 또는 전부를 사용하여 시험 업그레이드를 수행한 다음 업그레이드 로그 파일을 검토하는 것입니다. 이 로그 파일에는 업그레이드 소요 시간이 기록되어 있습니다. 업그레이드 로그 파일의 맨 아래에서 총 경과 시간을 확인한 후 이 시간을 기준으로 전체 전체 콘텐츠 집합의 소요 시간을 예측하면 됩니다. 로그 파일을 통해 업그레이드 프로세스 중에 진행률을 확인할 수도 있습니다. upgrade.log 파일은 %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\14\LOGS에 있습니다.

시험 업그레이드를 기준으로 계산하는 예상 소요 시간은 데이터에 대한 실제 업그레이드 프로세스의 소요 시간일 뿐이며, 이 단계 전후에 수행해야 하는 모든 단계(데이터 업그레이드 자체보다 더 오래 걸릴 수 있음)는 포함되지 않습니다. 업그레이드 소요 시간을 예상할 때는 데이터를 처리하는 데 필요한 시간 외에 업그레이드 전/후 단계 중에 수행되는 작업의 소요 시간도 포함해야 합니다.

업그레이드 전 단계의 소요 시간을 결정하는 요인은 다음과 같습니다.

• 사용자 지정 요소 만들기   웹 파트를 업그레이드하거나 새 기능을 활용할 수 있도록 사용자 지정 서식 파일을 다시 구성하려면 시간이 걸릴 수 있습니다. 사용자 지정 요소를 만드는 프로세스는 초기(프로젝트 평가 단계 중)에 시작해야 합니다.

• 데이터베이스 백업   드물지만 업그레이드가 실패하여 서버 팜을 다시 만들어야 하는 경우에 데이터베이스를 복구할 수 있도록 차등 백업이 아닌 전체 환경에 대한 전체 업그레이드를 수행해야 합니다. 대규모 환경의 경우에는 이 단계에 시간이 매우 오래 걸릴 수 있습니다. 특히 네트워크 위치로 백업하는 경우에는 네트워크 지연 문제로 인해 이 프로세스의 속도가 떨어질 수 있습니다.

업그레이드 후 단계의 소요 시간을 결정하는 요인은 다음과 같습니다.

• 사이트 확인 및 변경   업그레이드 후에 사용자가 충분한 시간 동안 사이트의 유효성을 검사할 수 있도록 합니다. 이 작업은 며칠이 걸릴 수 있습니다. 자세한 내용은 업그레이드 확인 및 업그레이드된 사이트 검토(SharePoint Foundation 2010)를 참조하십시오.

다음을 비롯한 환경의 기타 요인에 의해서도 업그레이드 시간이 길어질 수 있습니다.

• 매우 큰 문서 라이브러리   250,000개가 넘는 문서가 모두 폴더가 아닌 문서 라이브러리 루트에 있는 문서 라이브러리의 경우 업그레이드하는 데 시간이 오래 걸릴 수 있으며, 업그레이드가 실패할 수도 있습니다. 폴더 사용에 대한 Windows SharePoint Services 3.0 지침에 따라 큰 문서 라이브러리를 분할하면 라이브러리 크기를 관리할 수 있습니다. 예를 들어 동일한 문서 라이브러리를 다시 정렬하여 250,000개의 문서를 125개의 폴더로 구분하면 업그레이드가 훨씬 쉬워집니다.

• 매우 큰 데이터베이스   100GB가 넘는 데이터베이스의 경우 업그레이드하는 데 시간이 오래 걸릴 수 있습니다.

  참고

  100GB가 넘는 콘텐츠 데이터베이스는 업그레이드하기 전에 작은 데이터베이스로 나누는 것이 좋습니다. 데이터베이스 크기가 크면 업그레이드 시간이 오래 걸릴 뿐 아니라 업그레이드가 제대로 완료되지 않는 경우 복구하기도 어렵습니다.
  Stsadm.exe에서 mergecontentdbs 작업 또는 backup 작업과 restore 작업을 사용하여 데이터베이스 간에 사이트를 이동할 수 있습니다. 자세한 내용은 Mergecontentdbs: Stsadm 작업(Windows SharePoint Services)과 백업 및 복원: Stsadm 작업(Windows SharePoint Services)을 참조하십시오.

  데이터베이스의 크기가 100GB 이상으로 매우 크지만 대부분의 콘텐츠가 단일 사이트 모음에 포함되어 있어서 데이터베이스를 분할할 수가 없는 경우에는 다른 업그레이드 방식을 사용해 볼 수 있습니다. 데이터베이스 연결 업그레이드 방식을 사용하는 경우 매우 큰 데이터베이스를 처리하기가 더 어려운데, 이렇게 큰 데이터베이스는 백업 및 복원하기가 힘들기 때문입니다.

  경고

  업그레이드를 수행하기 전에 이전 버전과 새로운 버전의 용량 계획 지침을 모두 따르는지 확인하십시오. 최상의 성능을 위한 지침을 초과하는 경우 업그레이드 프로세스가 더 오래 걸리거나, 크기가 큰 동일 문서 라이브러리에서 프로세스 시간이 계속 초과되는 등 업그레이드 자체가 제대로 수행되지 않을 수 있습니다. 배포가 권장 용량 지침을 충족하지 않는 경우에는 업그레이드를 수행하기 전에 지침 충족을 위해 특정 작업을 수행해야 하는지를 확인하십시오. 이 경우에도 시험 업그레이드를 수행하면 도움이 됩니다.

• 정보 교환 요구 사항

  사용자와 팀원에게 일정을 업그레이드하도록 알리고 일정 작업을 수행할 시간을 주어야 합니다. 자세한 내용은 정보 교환 계획 만들기(SharePoint Foundation 2010)를 참조하십시오.

• 시스템 센터 알림 및 경고 관리

  업그레이드를 진행하는 동안 시스템 성능을 모니터링해야 하지만 특정 기능을 모니터링할 필요는 없습니다. Microsoft Systems Center Operations Manager 또는 Microsoft Operations Manager에서 불필요한 알림과 경고를 모두 일시 중지한 다음 업그레이드 후에 다시 설정하십시오.

• SQL 미러링 및 로그 전달 설정/해제

  업그레이드하기 전에 미러링 및 로그 전달 기능을 해제한 다음 업그레이드하고 난 후에 환경이 정상적으로 실행되는 것으로 확인되면 다시 설정해야 합니다. 미러링이나 로그 전달을 실행하면 부하가 추가로 발생하고 임시 데이터를 미러링하거나 전달하는 데 리소스가 낭비되므로 SQL Server를 실행하는 서버에 업그레이드를 진행하는 동안에는 미러링 또는 로그 전달을 실행하지 않는 것이 좋습니다.

업그레이드 프로세스를 테스트하여 예상 소요 시간을 확인한 다음 업그레이드 작업 일정을 작성하고 테스트를 통해 일정을 확인합니다. 이때 업그레이드 전/후 단계를 수행하는 데 필요한 시간도 작업 일정에 반영해야 합니다. 예를 들어 업그레이드를 시작하기 전에 환경을 백업하는 데 5시간이 걸린다면 가동 중지 기간이 이 5시간을 포함해야 합니다. 또한 환경을 복원하거나 복구해야 할 경우를 대비해 여유 시간도 두어야 합니다. 즉, 계획된 가동 중지 시간(일반적인 시나리오)과 비상 가동 중지 시간(최악의 시나리오)을 모두 결정해야 합니다.