다음을 통해 공유


테스트 업그레이드를 사용하여 잠재적 문제 발견(SharePoint Foundation 2010)

 

적용 대상: SharePoint Foundation 2010

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

Windows SharePoint Services 3.0에서 Microsoft SharePoint Foundation 2010으로 업그레이드하는 프로세스를 시작하기 전에 업그레이드 프로세스를 테스트하여 업그레이드를 성공적으로 수행하기 위해 필요한 것이 무엇인지 정확하게 확인할 수 있습니다. 시험 업그레이드를 사용하여 업그레이드 프로세스를 테스트할 경우 다음과 같은 사항을 확인할 수 있습니다.

  • 환경에 포함된 사용자 지정 내용 - 업그레이드하는 동안 해당 사용자 지정 내용을 처리할 방법 계획

  • 업그레이드를 보다 효율적이고 빠르게 실행할 수 있도록 하드웨어를 업그레이드해야 할지 여부

  • 업그레이드 시점 및 해당 환경에서 업그레이드에 소요되는 시간

  • 운영을 위해 계획할 내용(예: 사용할 수 있도록 해야 할 리소스)

또한 시험 업그레이드를 해 봄으로써 업그레이드 도구와 프로세스 자체에 친숙해지면 실제 프로세스에서 예상되는 내용을 파악할 수 있습니다. 테스트를 통해 다음을 확인할 수 있습니다.

  • 현재 환경에 적용되는 특수 사례와 현재 환경에 사용하면 가장 효과적일 업그레이드 방법

  • 업그레이드 사용자 인터페이스의 모양과 구성, 한 단계를 마치고 다음 단계로 넘어가는 시점

  • 로그 파일 위치, 로그 파일을 읽는 방법, 로그 파일에서 제공되는 정보

  • 가동 중지 시간을 줄이기 위해 사용할 수 있는 방법

이 문서에서는 업그레이드 테스트의 기본 단계를 소개하고, 테스트가 진행되는 동안 확인한 내용에 기반하여 업그레이드 계획을 조정하고 결과를 검토할 때의 권장 사항을 제시합니다.

이 문서의 내용

  • 테스트 환경 설정

  • 사용자 지정 내용 확인 및 설치

  • 테스트 환경으로 실제 데이터를 복사한 후 업그레이드

  • 결과 검토

  • 계획 조정 및 다시 테스트

이외에 업그레이드 프로세스를 테스트할 때 유용한 참고 리소스는 다음과 같습니다.

테스트 환경 설정

가상 하드웨어 또는 실제 하드웨어를 사용하여 업그레이드 프로세스를 테스트할 수 있습니다. 모든 환경은 고유하기 때문에 업그레이드에 걸리는 시간이나 특정 사용자 지정 내용 업그레이드의 난이도에 대한 일반적인 지침은 없습니다. 업그레이드가 어떤 식으로 이루어지고 있는지 평가할 수 있는 최선의 방법은 시험 업그레이드를 여러 번 수행하는 것입니다.

테스트 환경을 만드는 경우

  • 테스트 팜의 하드웨어, 소프트웨어, 사용 가능한 공간 등을 실제 팜과 가능한 한 비슷하게 구성합니다.

  • 테스트 팜에서 실제 팜과 동일한 URL을 사용합니다. 그러지 않으면 실제 업그레이드에 포함되지 않는 URL 관련 문제를 진단하느라 시간을 낭비하게 됩니다.

  • 테스트 환경으로 모든 설정과 사용자 지정 내용을 전송합니다. 사용자 지정 내용 확인 및 설치 섹션에서 이 정보를 수집하는 방법을 설명합니다.

가상 테스트 환경 사용

가상화된 환경을 사용하여 테스트하는 경우 많은 하드웨어가 필요하지 않습니다. Hyper-V를 실행하는 두 대의 서버만 사용하여 환경을 복제할 수 있습니다. 한 서버에는 프런트 엔드 웹 서버 및 응용 프로그램 서버에 대한 이미지가 있고 다른 서버에는 데이터베이스 서버에 대한 이미지가 있습니다.

시험 업그레이드를 위한 가상 테스트 환경

실제 테스트 환경 사용

실제 환경을 사용하여 테스트하는 경우 가능한 한 전체 서버 팜 환경을 비슷하게 복제해야 합니다. 프런트 엔드 웹 서버, 응용 프로그램 서버 또는 데이터베이스 서버 수를 너무 줄여서 테스트하면 업그레이드 프로세스에 걸리는 시간을 정확히 예측할 수 없고 SQL Server 트랜잭션과 같은 동일한 역할을 갖는 서버 간 상호 작용에서 발생할 수 있는 복잡한 조건을 고려하지 못할 수 있습니다. 원본 팜에 같은 역할의 서버가 여러 대 있는 경우 테스트 팜에서 해당 역할의 서버를 최소 두 대 이상 사용하여 그러한 문제를 테스트해 봐야 합니다.

시험 업그레이드를 위한 실제 테스트 팜

데이터베이스 연결 업그레이드에 대한 추가 테스트 환경

데이터베이스 연결 업그레이드 방법을 사용하는 경우 추가 테스트 환경으로, 데이터 업그레이드 전에 업그레이드 사전 검사 도구(pre-upgrade checker)를 실행하는 데 사용할 수 있는 Windows SharePoint Services 3.0을 실행하는 단일 서버 팜을 만들어야 합니다.

기존 프로덕션 팜에서 업그레이드 사전 검사 도구를 실행하면 이 단계를 건너뛸 수 있습니다.

사용자 지정 내용 확인 및 설치

정확한 테스트 프로세스를 수행하려면 현재 환경의 모든 사용자 지정 내용을 찾아 테스트 환경으로 복사해야 합니다. 파악해야 할 사용자 지정 유형에 대한 자세한 내용은 사용자 지정 내용 처리 방법 결정(SharePoint Foundation 2010)을 참조하십시오.

  • 업그레이드 사전 검사 도구를 사용하여 현재 환경의 사이트 정의, 사이트 서식 파일 및 기능을 확인합니다.

    업그레이드 사전 검사 도구는 각 사이트 모음을 단계별로 검사하여 각 사이트의 상태에 대한 보고서를 생성합니다. 또한 각 목록에 대한 목록 정의 정보를 저장합니다. 따라서 업그레이드 프로세스를 시작하기 전에 보고서를 검토하여 문제를 발견하고 해결할 수 있습니다. Windows SharePoint Services 3.0용 업그레이드 사전 검사 도구(pre-upgrade scan tool)와 달리 업그레이드 사전 검사 도구(pre-upgrade checker)는 읽기 전용 도구이며 사이트를 변경하지 않습니다. 이 도구 및 도구 실행 단계에 대한 자세한 내용은 이후 릴리스에 대한 업그레이드 사전 검사 및 보고(Windows SharePoint Services)업그레이드 사전 검사 도구 실행(SharePoint Foundation 2010)을 참조하십시오.

  • 현재 Windows SharePoint Services 3.0 환경의 모든 콘텐츠 데이터베이스에서 Stsadm –o enumallwebs 작업을 사용하여 하위 사이트의 특정 사용자 지정 내용을 확인합니다. 이 작업을 통해 환경의 각 사이트 모음 및 하위 사이트에 대한 ID와 사이트가 이용하는 서식 파일이 표시됩니다. 이 작업은 Windows SharePoint Services 3.0 서비스 팩 2(SP2)에서 처음 도입되었습니다. 자세한 내용은 Enumallwebs: Stsadm 작업(Windows SharePoint Services)을 참조하십시오.

  • WinDiff 같은 도구(대부분의 Microsoft 운영 체제에서 제공됨)를 사용하여 프로덕션 환경 서버를 테스트 팜 서버와 비교해 봅니다. 이 도구를 사용하여 서버에 어떤 파일이 있는지, 그러한 파일 간 차이점은 무엇인지 확인할 수 있습니다.

  • web.config 파일의 변경된 내용을 확인하고 SafeControls 요소에서 사용자 지정 컨트롤을 찾습니다.

  • SharePoint 진단 도구(SPDiag)를 사용하여 배포된 솔루션을 찾습니다. 자세한 내용은 SharePoint 진단 도구(SPDiag)(영문일 수 있음)를 참조하십시오.

  • 검색한 모든 사용자 지정 내용의 목록을 만듭니다. 가능하다면 사용자 지정 내용의 원본을 확인합니다. 예를 들어 사내에 사용자 지정된 타사 추가 기능이나 서식 파일이 있는지 확인합니다. 원본을 확인한 후에는 사용자 지정 내용의 업데이트 또는 업그레이드된 버전을 확인할 수 있습니다. 워크시트를 사용하여 업그레이드 사전 검사 도구의 결과 데이터와 사용자 지정 내용 조사 내용을 바탕으로 한 환경 관련 정보를 기록할 수 있습니다.https://go.microsoft.com/fwlink/?linkid=179928&clcid=0x412(영문일 수 있음)에서 워크시트를 다운로드하여 필요에 맞게 사용자 지정하십시오.

다른 사용자가 만든 사용자 지정 내용에 대해서는 누구에게 문의해야 합니까?

  • Microsoft 웹 사이트에서 다운로드한 서식 파일(예: Windows SharePoint Services 3.0 응용 프로그램 서식 파일)에 문제가 있을 경우 Microsoft에 문의하십시오.

  • 이전 버전에서 제공된 서식 파일 또는 구성 요소에 문제가 있으면 해당 타사 솔루션 공급업체에 문의하십시오. 해당 업체에서 업그레이드된 버전을 보유하고 있을 수도 있습니다.

모든 사용자 지정 내용을 확인했으면 테스트 팜의 해당하는 서버에 복사합니다. SharePoint Foundation 2010에 데이터베이스를 연결하기 전에 Windows PowerShell cmdlet test-spcontentdatabase를 사용하여 환경에서 누락된 사용자 지정 내용이 없는지 확인할 수 있습니다. 데이터베이스 서버에 데이터베이스를 복원한 후 업그레이드를 실행하기 전에 각 데이터베이스에서 이 명령을 실행합니다. 이 cmdlet 명령은 자동으로 실행되므로 오류가 없으면 출력을 반환하지 않습니다.

테스트 환경으로 실제 데이터를 복사한 후 업그레이드

실제 데이터를 사용해야만 테스트 목적을 달성할 수 있습니다. 다음 방법을 사용하여 데이터 복사본을 만들 수 있습니다.

업그레이드하는 동안 진행 과정을 확인하는 가장 좋은 방법은 모든 데이터 복사본을 테스트하는 것이겠으나, 처음 테스트하는 경우 이는 현실적인 방안이 되지 못할 수 있습니다. 데이터베이스가 큰 경우 한 번에 한 데이터베이스씩 테스트를 진행하면 해당 데이터 집합에 고유한 내용을 테스트하거나 현재 환경의 대표 사이트에서 데이터의 하위 집합을 조합할 수 있습니다. 먼저 데이터의 하위 집합을 사용하여 테스트하는 경우 다음과 같은 특성을 갖는 하위 집합이어야 합니다.

  • 현재 환경에서 지원하는 사이트를 대표하는 사이트가 포함된 데이터 하위 집합이어야 합니다.

  • 데이터 하위 집합의 크기 및 복잡성이 환경의 실제 크기 및 복잡성과 매우 비슷해야 합니다.

중요

데이터 하위 집합 테스트를 통해 해당 환경의 전체 데이터 볼륨을 처리할 때 걸리는 시간에 대한 올바른 기준이 생성되는 것은 아닙니다.

데이터 복사 후 업그레이드 프로세스의 첫 단계를 수행하여 어떤 결과가 생기는지 확인합니다. 이 단계는 단지 준비 작업입니다.

전체 업그레이드 테스트

전체 업그레이드 방법을 사용하려는 경우 다음 단계를 수행하여 업그레이드 프로세스를 테스트해 봅니다.

  1. 팜의 백업을 만듭니다.

  2. 테스트 팜에 백업을 복원합니다.

    자세한 내용은 전체 팜 백업 및 복원(Windows SharePoint Services 3.0 기술)(영문일 수 있음)을 참조하십시오.

  3. 업그레이드 사전 검사 도구를 실행합니다. 여기서 발견된 문제를 모두 기록해 둡니다. 그러면 프로덕션 팜에서 실제 업그레이드를 실행하기 전에 원래 환경에서 이러한 문제를 해결할 수 있습니다. 자세한 내용은 업그레이드 사전 검사 도구 실행(SharePoint Foundation 2010)을 참조하십시오.

  4. 전체 업그레이드 수행(SharePoint Foundation 2010)의 단계에 따라 전체 업그레이드를 테스트합니다.

  5. 결과를 검토합니다.

데이터베이스 연결 업그레이드 테스트

  1. 콘텐츠 데이터베이스의 SQL Server 백업을 만듭니다.

  2. SQL Server를 사용하여 단일 서버 테스트 팜으로 백업을 복원하고 해당 환경에 콘텐츠 데이터베이스를 연결합니다.

    자세한 내용은 콘텐츠 데이터베이스 백업 및 복원(Windows SharePoint Services 3.0)을 참조하십시오.

  3. 업그레이드 사전 검사 도구를 실행합니다. 여기서 발견된 문제와 변경 내용을 모두 기록해 둡니다. 그러면 프로덕션 팜에서 실제 업그레이드를 실행하기 전에 원래 환경에서 이러한 문제를 해결하고 변경 내용을 적용할 수 있습니다. 자세한 내용은 업그레이드 사전 검사 도구 실행(SharePoint Foundation 2010)을 참조하십시오.

  4. 새 SharePoint Foundation 환경 준비의 단계에 따라 데이터베이스 연결 업그레이드 테스트 환경을 구성합니다.

  5. 데이터베이스 연결 및 SharePoint Foundation 2010으로 업그레이드의 단계에 따라 데이터베이스 연결 업그레이드 프로세스를 수행합니다.

결과 검토

테스트 업그레이드를 마친 후 결과를 검토하고 계획을 재고할 수 있습니다. 로그 파일과 업그레이드된 사이트를 보고 사용자 지정 내용을 확인합니다. 업그레이드가 어떻게 진행되었습니까? 어떤 결과를 발견했습니까? 업그레이드 계획에서 어떤 부분을 재고해야 합니까?

로그 파일 검토

다음 로그 파일을 검토합니다.

  • 업그레이드 사전 검사 도구 로그 파일

    업그레이드 사전 검사 도구(stsadm -o preupgradecheck)의 로그 파일은 %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\LOGS에 있습니다. 로그 파일 이름은 PreUpgradeCheck_YYYYMMDD-HHMMSS-SSS-난수.log 형식으로 지정되며, 여기서 YYYYMMDD는 날짜이고 HHMMSS-SSS는 시간(24시간제 형식의 시간, 분, 초 및 밀리초)입니다. 난수는 업그레이드 사전 검사 도구를 실행하기 위해 동시에 발생하는 여러 시도를 구분하는 데 사용됩니다.

  • SharePoint 제품 구성 마법사(Psconfig.exe) 로그 파일(테스트 전체 업그레이드 중 이 마법사를 실행할 때 생성됨)

    PSCDiagnostics 로그 파일은 %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS에 있습니다.

  • 업그레이드 로그 파일 및 업그레이드 오류 로그 파일(업그레이드를 실행할 때 생성됨)

    업그레이드 로그 파일(.log) 및 업그레이드 오류 로그 파일(.err)은 %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS에 있습니다. 로그 파일의 이름은 Upgrade-YYYYMMDD-HHMMSS-SSS.log 형식으로 지정되며, 여기서 YYYYMMDD는 날짜이고 HHMMSS-SSS는 시간(24시간제 형식의 시간, 분, 초 및 밀리초)입니다.

로그 파일을 검토하여 문제를 찾아 해결하려면 파일 맨 위부터 시작합니다. 오류나 경고는 환경의 여러 사이트 모음에서 발생하거나 업그레이드 프로세스를 완전히 차단할 경우 반복될 수 있습니다. 예를 들어 구성 데이터베이스에 연결할 수 없는 경우 업그레이드 프로세스가 여러 번 시도 후에 실패하고 해당 시도가 로그 파일에 표시됩니다.

다음 항목을 검색하거나 찾습니다.

  • Finished upgrading SPFarm Name= <구성 데이터베이스 이름>

  • In-place upgrade session finishes. Root object = SPFarm= <구성 데이터베이스 이름> , recursive = True. 0 errors and 0 warnings encountered.

로그에 이 항목이 있으면 설치가 올바르게 이루어진 것입니다.

앞선 단계에서 이 항목을 찾지 못한 경우에는 Upgrade.log 파일에서 다음 용어를 검색하거나 찾아 오류를 발생시킨 특정 문제를 파악할 수 있습니다.

  • 로그 파일에서 ERROR를 검색하여 오류 항목(예: 오류를 일으킨 구성 요소, 잘못된 데이터베이스 연결)을 찾습니다.

  • WARNING을 검색하여 누락된 기능 또는 구성 요소와 같은 문제를 찾습니다.

업그레이드 문제를 찾으려면 로그 파서를 사용하여 로그 파일에 대해 쿼리를 실행하는 것이 좋습니다.

필요한 경우 업그레이드 다시 시작

데이터베이스 연결 업그레이드를 수행하는 동안 업그레이드할 수 없는 사이트는 건너뜁니다. 전체 업그레이드인 경우 서버를 다시 시작하거나 업그레이드에 실패하면 업그레이드 프로세스를 다시 시작하여 나머지 사이트를 업그레이드해야 합니다.

업그레이드 중에 누락되었거나 건너뛴 사이트가 있는지 확인하려면 SharePoint Foundation 2010 서버 팜의 모든 프런트 엔드 웹 서버에서 다음 Stsadm 작업 stsadm -o localupgradestatus를 실행하십시오. 이 작업에 대한 자세한 내용은 Localupgradestatus: Stsadm 작업(Windows SharePoint Services)을 참조하십시오.

업그레이드 중에 사이트 모음을 건너뛴 경우 다음 Windows PowerShell cmdlet: upgrade-spcontentdatabase -id *<GUID>*를 사용하여 해당 사이트 모음을 포함하는 데이터베이스에서 업그레이드 프로세스를 다시 시작할 수 있습니다. 이 cmdlet에 대한 자세한 내용은 Upgrade-SPContentDatabase를 참조하십시오.

자세한 내용은 업그레이드 다시 시작(SharePoint Foundation 2010)을 참조하십시오.

업그레이드된 사이트 검토

업그레이드된 사이트를 검토하여 프로덕션 환경에서 업그레이드 프로세스를 실행하기 전에 해결해야 하는 모든 문제를 확인합니다. 확인할 구체적인 항목에 대한 자세한 내용은 업그레이드 확인 및 업그레이드된 사이트 검토(SharePoint Foundation 2010)를 참조하십시오.

계획 조정 및 다시 테스트

발생할 수 있는 모든 문제를 확인하고 해결 방법을 찾을 때까지 테스트 프로세스를 반복합니다. 일요일 오후 4시인데 월요일 아침까지 온라인 상태로 복구해야 하지만 문제가 있는 경우, 어떤 계획이 필요한지 확인하는 것이 목표입니다. 되돌릴 수 없는 지점이 있습니까? 롤백 계획을 테스트하고 실제 업그레이드를 시작하기 전에 제대로 작동하도록 합니다.