테스트 업그레이드를 사용하여 잠재적 문제 발견(SharePoint Server 2010)
적용 대상: SharePoint Server 2010
마지막으로 수정된 항목: 2016-11-30
Microsoft Office SharePoint Server 2007에서 Microsoft SharePoint Server 2010으로 업그레이드하는 프로세스를 시작하기 전에 업그레이드 프로세스를 테스트하여 업그레이드를 성공적으로 수행하기 위해 필요한 것이 무엇인지 정확하게 확인할 수 있습니다. 시험 업그레이드를 사용하여 업그레이드 프로세스를 테스트할 경우 다음과 같은 사항을 확인할 수 있습니다.
환경에 포함된 사용자 지정 내용 - 업그레이드하는 동안 해당 사용자 지정 내용을 처리할 방법 계획
업그레이드를 보다 효율적이고 빠르게 실행할 수 있도록 하드웨어를 업그레이드해야 할지 여부
업그레이드 시점 및 해당 환경에서 업그레이드에 소요되는 시간
운영을 위해 계획할 내용(예: 사용할 수 있도록 해야 할 리소스)
뿐만 아니라 시험 업그레이드를 사용하면 업그레이드 도구 및 프로세스 자체가 친숙해져 실제 프로세스를 수행할 때 앞으로의 상황을 예상할 수 있습니다. 테스트를 통해 다음을 확인할 수 있습니다.
사용 환경에 적용되는 특수한 경우의 수 및 사용자에게 가장 효율적인 업그레이드 방법
업그레이드 사용자 인터페이스의 모양 및 한 단계가 끝나고 다음 단계로 이동하는 시기 알아보는 방법
로그 파일의 위치 및 읽는 방법과 로그 파일에서 확인 가능한 정보
가동 중지 시간 발생 가능성을 완화하는 데 사용할 수 있는 기법
이 문서에서는 기본적인 업그레이드 테스트 단계를 제공하고, 결과를 검토할 때와 테스트 중에 알게 된 사항을 바탕으로 업그레이드 계획을 조정할 때 권장되는 방법을 제시합니다.
이 문서의 내용
테스트 환경 설정
사용자 지정 내용 확인 및 설치
테스트 환경에 실제 데이터 복사 및 업그레이드 수행
결과 검토
계획 조정 및 다시 테스트
또한 다음과 같은 리소스는 업그레이드 프로세스를 테스트할 때 유용할 수 있습니다.
SharePoint Products 2010 업그레이드 워크시트
업그레이드를 테스트하는 동안 사용자 환경에 대한 정보를 이 워크시트에 기록할 수 있습니다. 해당 워크시트는 https://go.microsoft.com/fwlink/?linkid=179928&clcid=0x412(영문일 수 있음)에서 다운로드할 수 있습니다.
Microsoft SharePoint 2010 제품 - 업그레이드 프로세스 모델 테스트
이 포스터에는 업그레이드 프로세스를 테스트하는 방법에 대한 정보가 시각적으로 표시되어 있습니다. 해당 포스터는 https://go.microsoft.com/fwlink/?linkid=166303&clcid=0x412(영문일 수 있음)에서 다운로드할 수 있습니다.
테스트 환경 설정
가상 또는 실제 하드웨어를 사용하여 업그레이드 프로세스를 테스트할 수 있습니다. 사용 환경은 모두 다르므로 업그레이드하는 데 걸리는 시간이나 특정 사용자 지정 내용을 업그레이드할 때의 난이도에 대해서는 일반적인 기준이 없습니다. 업그레이드 진행 과정을 판단할 수 있는 가장 좋은 방법은 시험 업그레이드를 여러 번 수행하는 것입니다.
테스트 환경을 만들 때는 다음 사항에 주의하십시오.
하드웨어, 소프트웨어, 사용 가능한 공간 등 테스트 팜을 실제 팜과 최대한 비슷하게 조성해야 합니다.
테스트 팜의 URL을 실제 팜과 동일하게 사용해야 합니다. 그렇게 하지 않으면 실제 업그레이드 시에 발생하는 URL 관련 문제를 진단하는 데 시간이 많이 걸립니다.
사용 중인 모든 설정과 사용자 지정 내용을 테스트 환경으로 전송해야 합니다. 사용자 지정 내용 확인 및 설치 섹션에는 이 정보를 수집하는 방법에 대한 정보가 설명되어 있습니다.
가상 테스트 환경 사용
가상화된 환경을 사용하여 테스트할 때는 하드웨어가 많이 필요하지 않습니다. Hyper-V를 실행 중인 두 대의 서버만 있으면 환경을 복제할 수 있습니다. 즉, 프런트 엔드 웹 서버 및 응용 프로그램 서버 이미지가 있는 서버 한 대와 데이터베이스 서버 이미지가 있는 다른 서버 한 대가 필요합니다.
실제 테스트 환경 사용
실제 환경을 사용하여 테스트할 때는 전체 서버 팜 환경을 최대한 그대로 복제해야 합니다. 프런트 엔드 웹 서버, 응용 프로그램 서버 또는 데이터베이스 서버의 수를 너무 많이 줄이면 업그레이드 프로세스에 소요되는 시간을 정확히 예측할 수 없으며, 역할(예: SQL Server 트랜잭션)이 같은 서버 간의 상호 작용에서 발생하는 복잡한 현상을 명확히 파악하지 못할 수도 있습니다. 원본 팜에서 역할 하나에 여러 대의 서버를 포함하고 있다면 테스트 팜에서는 해당 역할에 최소 두 대의 서버를 사용하여 해당 문제를 테스트해야 합니다.
데이터베이스 연결 업그레이드에 대한 추가 테스트 환경
데이터베이스 연결 업그레이드 방법을 사용하는 경우 테스트 환경을 하나 더 만들어야 할 수도 있습니다. Office SharePoint Server 2007을 실행하는 서버 팜 하나가 그것입니다. 이 팜을 사용하면 데이터를 업그레이드하기 전에 업그레이드 사전 검사 도구를 실행할 수 있습니다.
기존 프로덕션 팜에서 업그레이드 사전 검사 도구를 실행하면 이 단계를 생략할 수 있습니다.
사용자 지정 내용 확인 및 설치
정확한 테스트 프로세스를 수행하려면 현재 환경의 모든 사용자 지정 내용을 찾아 테스트 환경으로 복사해야 합니다. 확인해야 하는 사용자 지정 내용의 유형에 대한 자세한 내용은 사용자 지정 내용 처리 방법 결정(SharePoint Server 2010)을 참조하십시오.
업그레이드 사전 검사 도구를 사용하여 사이트 정의, 사이트 서식 파일, 환경의 기능을 확인합니다.
업그레이드 사전 검사 도구는 각 사이트 모음을 단계별로 실행하여 각 사이트의 상태에 대한 보고서를 생성하며, 각 목록에 대한 목록 정의 정보를 저장합니다. 따라서 업그레이드 프로세스를 시작하기 전에 보고서를 검토하여 문제를 파악하고 해결할 수 있습니다. 이 도구는 Office SharePoint Server 2007의 업그레이드 사전 검사 도구와 달리 읽기 전용 도구이므로 사이트를 변경하지 않습니다. 이 도구에 대한 자세한 내용 및 도구 실행 단계는 이후 릴리스에 대한 업그레이드 사전 검사 및 보고(Office SharePoint Server)와 업그레이드 사전 검사 도구 실행(SharePoint Server 2010)을 참조하십시오.
Office SharePoint Server 2007 환경의 모든 콘텐츠 데이터베이스에 대해 Stsadm –o enumallwebs 작업을 사용하여 하위 사이트의 특정 사용자 지정 내용을 확인합니다. 이 작업은 해당 환경의 각 사이트 모음 및 하위 사이트의 ID와 사이트에서 사용하는 서식 파일을 나열합니다. 이 작업은 Office SharePoint Server 2007 서비스 팩 2(SP2)에서 처음 도입되었습니다. 자세한 내용은 Enumallwebs: Stsadm 작업(Office SharePoint Server)을 참조하십시오.
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 Server 2010에 데이터베이스를 연결하기 전에 Windows PowerShell cmdlet test-spcontentdatabase를 사용하여 환경에서 누락된 사용자 지정 내용이 있는지 확인할 수 있습니다. 데이터베이스를 데이터베이스 서버로 복원한 후 업그레이드를 실행하기 전에 각 데이터베이스에 대해 이 명령을 실행합니다. 이 cmdlet은 백그라운드에서 자동으로 실행됩니다. 오류가 없으면 아무 내용도 출력되지 않습니다.
테스트 환경에 실제 데이터 복사 및 업그레이드 수행
실제 데이터를 사용하지 않으면 테스트 목적을 달성할 수 없습니다. 다음 방법을 사용하여 데이터 복사본을 만드십시오.
전체 업그레이드의 경우 팜 백업을 만든 다음 테스트 환경에 복원합니다. 자세한 내용은 전체 팜 백업 및 복원(Office SharePoint Server 2007)(영문일 수 있음)을 참조하십시오.
데이터베이스 연결 업그레이드의 경우 Microsoft SQL Server 백업 및 복원 도구를 사용하여 업그레이드할 콘텐츠 데이터베이스와 기타 모든 데이터베이스의 복사본을 만들어야 합니다. 자세한 내용은 데이터베이스 백업 및 복원(Office SharePoint Server)(영문일 수 있음)을 참조하십시오.
업그레이드 중에 발생할 수 있는 문제를 확인하려면 모든 데이터의 복사본에 대해 테스트를 수행하는 것이 가장 좋습니다. 그러나 처음 테스트할 때는 이 방법을 사용하기가 어려운 경우도 있을 수 있습니다. 데이터베이스가 큰 경우 한 번에 하나의 데이터베이스를 테스트하는 방법으로 테스트 단계를 구분하여 해당 데이터 집합에 대해서만 고유하게 발생하는 문제를 확인하거나 사용 환경의 대표 사이트에서 데이터 하위 집합을 조합할 수 있습니다. 데이터의 하위 집합을 사용하여 처음 테스트하는 경우 다음과 같은 특징이 있는 하위 집합을 사용해야 합니다.
데이터 하위 집합에 사용 환경에서 지원하는 사이트를 대표할 수 있는 전형적인 사이트를 포함해야 합니다.
데이터 하위 집합의 크기 및 복잡성이 사용 환경의 실제 크기 및 복잡성과 비슷해야 합니다.
중요
데이터 하위 집합을 테스트하는 경우에는 사용 환경에 있는 전체 볼륨의 데이터를 업그레이드하는 데 걸리는 시간에 대한 유효한 벤치마크가 생성되지 않습니다.
데이터를 복사한 후에 첫 번째 업그레이드 프로세스를 수행하여 결과를 확인합니다. 이것은 준비 단계일 뿐입니다.
전체 업그레이드 테스트
전체 업그레이드 방법을 사용하려는 경우 다음 단계에 따라 업그레이드 프로세스를 수행하십시오.
팜의 백업을 만듭니다.
테스트 팜에 백업을 복원합니다.
자세한 내용은 전체 팜 백업 및 복원(Office SharePoint Server 2007)(영문일 수 있음)을 참조하십시오.
업그레이드 사전 검사 도구를 실행하고 검색되는 모든 문제를 기록합니다. 프로덕션 팜에서 실제 업그레이드를 실행하기 전에 원래 환경에서 이러한 문제를 해결해야 할 수 있습니다. 자세한 내용은업그레이드 사전 검사 도구 실행(SharePoint Server 2010)을 참조하십시오.
전체 업그레이드 수행(SharePoint Server 2010)의 단계에 따라 전체 업그레이드를 테스트합니다.
결과를 검토합니다.
데이터베이스 연결 업그레이드 테스트
사용 중인 콘텐츠 데이터베이스 및 SSP(공유 서비스 공급자) 데이터베이스의 SQL Server 백업을 만듭니다.
SQL Server를 사용하여 단일 서버 테스트 팜에 백업을 복원하고 콘텐츠 데이터베이스를 해당 환경에 연결합니다.
자세한 내용은 데이터베이스 백업 및 복원(Office SharePoint Server)(영문일 수 있음)을 참조하십시오.
업그레이드 사전 검사 도구를 실행하고 검색되는 모든 문제 및 모든 변경 사항을 기록합니다. 프로덕션 팜에서 실제 업그레이드를 실행하기 전에 원래 환경에서 이러한 문제를 해결하고 변경 사항을 적용해야 할 수 있습니다. 자세한 내용은 업그레이드 사전 검사 도구 실행(SharePoint Server 2010)을 참조하십시오.
데이터베이스 연결 업그레이드를 위한 새 SharePoint Server 2010 환경 준비의 단계에 따라 데이터베이스 연결 업그레이드를 위한 테스트 환경을 구성합니다.
SharePoint Server 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 Server 2010 서버 팜의 모든 프런트 엔드 웹 서버에 대해 다음 Stsadm 작업 stsadm -o localupgradestatus를 실행합니다. 이 작업에 대한 자세한 내용은 Localupgradestatus: Stsadm 작업(Office SharePoint Server)을 참조하십시오.
업그레이드 시 건너뛴 사이트 모음이 있으면 Windows PowerShell cmdlet upgrade-spcontentdatabase -id <GUID>를 사용하여 해당 사이트 모음이 포함된 데이터베이스에 대해 업그레이드 프로세스를 다시 시작할 수 있습니다. 이 cmdlet에 대한 자세한 내용은 Upgrade-SPContentDatabase를 참조하십시오.
자세한 내용은 업그레이드 다시 시작(SharePoint Server 2010)을 참조하십시오.
업그레이드된 사이트 검토
업그레이드된 사이트를 검토하여 프로덕션 환경에서 업그레이드 프로세스를 실행하기 전에 해결해야 하는 모든 문제를 확인합니다. 확인할 구체적인 항목에 대한 자세한 내용은 업그레이드 확인 및 업그레이드된 사이트 검토(SharePoint Server 2010)을 참조하십시오.
계획 조정 및 다시 테스트
업그레이드 중에 발생할 수 있는 모든 문제와 그 해결 방법을 찾을 때까지 테스트 프로세스를 반복합니다. 계획을 잘 파악하는 것을 목표로 해야 합니다. 일요일 오후 4시라면 월요일 아침까지 온라인 상태로 돌아가야 하는데 문제가 해결되지 않았습니다. 이때 돌아갈 지점이 없다면 어떻게 하겠습니까? 실제 업그레이드를 시작하기 전에 롤백 계획을 테스트하여 문제없이 수행할 수 있도록 해야 합니다.