SharePoint 2013으로의 테스트 업그레이드를 사용하여 잠재적 문제 발견

아티클
03/08/2023

적용 대상: 예-img-13 2013 no-img-16 2016 no-img-19 2019 no-img-se Subscription Edition no-img-sop SharePoint in Microsoft 365

SharePoint 2010 제품에서 SharePoint 2013으로 업그레이드를 시작하기 전에 업그레이드 프로세스를 테스트하여 성공적인 업그레이드를 위해 수행해야 하는 작업을 정확히 알고 있는지 확인해야 합니다. 시험 업그레이드를 사용하여 업그레이드 프로세스를 테스트할 경우 다음과 같은 문제를 확인할 수 있습니다.

업그레이드 계획을 그대로 사용하면 되는지 아니면 조정이 필요한지 확인
업그레이드 중에 해당 처리 방법을 계획하기 위해 환경에 포함된 사용자 지정 내용 확인
업그레이드를 보다 효율적이고 빠르게 실행할 수 있도록 하드웨어를 업그레이드해야 할지 여부 확인
업그레이드 시간 또는 해당 환경에서 업그레이드에 소요되는 시간 확인
운영상 계획할 내용(예: 확보해야 할 리소스) 확인

그뿐만 아니라 시험 업그레이드를 사용하면 업그레이드 도구 및 프로세스 자체에 대해 익힘으로써 실제 프로세스를 수행할 때 앞으로의 상황을 예상할 수 있습니다. 테스트를 통해 다음과 같은 문제를 파악할 수 있습니다.

업그레이드 사용자 인터페이스는 어떤 모습인가요? 한 단계를 완료하고 다른 단계를 통해 이동하는 경우 어떻게 알 수 있습니까?
로그 파일은 어디에 있으며 어떻게 읽나요? 어떤 정보를 제공합니까?
업그레이드 프로세스 중에 사용되는 스크립트나 명령을 조정해야 할지 여부(특히 SharePoint 2010 제품으로 업그레이드하는 데 사용했던 스크립트를 사용하는 경우)
정전에 대비한 적절한 계획의 유무

이 문서에서는 기본적인 업그레이드 테스트 단계에 대해 설명하고 결과를 검토할 때와 테스트 중에 알게 된 사항을 바탕으로 업그레이드 계획을 조정할 때 권장되는 방법을 제시합니다.

또한 업그레이드 프로세스를 테스트할 때 다음과 같은 리소스가 유용할 수 있습니다.

SharePoint 2013 - 업그레이드 프로세스 모델 테스트

SharePoint 2013 Products Preview - 업그레이드 프로세스 테스트 모델 포스터를 다운로드하여 업그레이드 프로세스의 테스트 방법에 대한 정보를 그림으로 확인할 수 있습니다.
업그레이드 프로세스 테스트를 위한 모범 사례는 SharePoint 2010에서 SharePoint 2013으로의 업그레이드 모범 사례를 참조하세요.

테스트 환경 설정

가상 하드웨어 또는 실제 하드웨어를 사용하여 업그레이드 프로세스를 테스트할 수 있습니다. 모든 환경은 고유합니다. 따라서 업그레이드에 걸리는 시간 또는 특정 사용자 지정이 업그레이드하는 데 얼마나 어려운지에 대한 일반적인 지침은 없습니다. 업그레이드 방법을 측정하는 가장 좋은 방법은 일련의 평가판 업그레이드를 수행하는 것입니다.

테스트 환경을 만들 때 고려할 몇 가지 사항은 다음과 같습니다.

하드웨어, 소프트웨어, 사용 가능한 공간 등 테스트 팜을 실제 팜과 최대한 비슷하게 조성해야 합니다.
테스트 팜에서 실제 팜과 동일한 URL을 사용해야 합니다. 그렇게 하지 않으면 실제 업그레이드 시에는 발생하지 않는 URL 관련 문제를 진단하는 데 시간이 많이 걸립니다. 동일한 URL을 사용하고 호스트 파일이 변경된 컴퓨터에서만 테스트를 수행하면 됩니다.
웹 서버와 응용 프로그램 서버에 각기 다른 컴퓨터 이름을 사용해야 합니다.

그러면 AD DS(Active Directory 도메인 서비스) 충돌을 방지할 수 있습니다.
테스트 팜에 SQL Server를 실행하는 별도의 서버를 사용해야 합니다.

테스트 및 프로덕션 팜에 대해 SQL Server를 실행하는 동일한 서버를 사용하는 경우 테스트를 실행하는 동안 프로덕션 팜의 성능에 영향을 줄 수 있습니다. 프로덕션 및 테스트 팜에 다른 SQL Server 컴퓨터(인스턴스뿐만 아니라)를 사용하는 것이 좋습니다.
테스트 환경에서 동일한 데이터베이스 이름을 사용해야 합니다.

이렇게 하면 환경을 관리하는 데 사용하는 모든 스크립트의 유효성을 검사할 수 있습니다. 다시 SQL Server를 실행하는 별도의 서버를 사용하거나 프로덕션 환경에 영향을 미칠 위험이 있는지 확인합니다.
사용 중인 모든 설정과 사용자 지정 내용을 테스트 환경으로 전송해야 합니다. 사용자 지정 내용 확인 및 설치 섹션에는 이 정보를 수집하는 방법에 대한 정보가 설명되어 있습니다.

테스트 환경에서 수행하는 작업이 실제 환경에 영향을 주지 않도록 해야 합니다. 특히 다음 사항에 주의하십시오.

외부 데이터 연결

환경의 복사본을 사용하여 작업하더라도 데이터 원본에는 실제로 연결됩니다. 따라서 테스트 환경에서 적용하는 데이터 변경 내용은 프로덕션 환경에 영향을 주게 됩니다.
프로덕션 환경에 계속 포함되는 실제 데이터베이스에 대한 명령 실행

프로덕션 환경의 실제 버전이 아닌 테스트용 데이터베이스 복사본을 사용해야 합니다. 예를 들어 복사본이 아닌 실제 데이터베이스에 대해 Test-SPContentDatabase를 실행하면 프로덕션 환경의 성능에 영향을 줄 수 있습니다.

가상 테스트 환경 사용

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

그러나 가상 환경의 성능 메트릭이 실제 환경과 동일하지 않을 수도 있습니다. 프로덕션 환경이 실제 환경인 경우 프로덕션 환경을 업그레이드하는 데 필요한 시간을 계산할 때 이러한 차이를 고려해야 합니다. 일반적으로 SQL Server에 물리적 서버를 사용하는 경우 성능 추정치를 높일 수 있습니다. 프로덕션 환경에서 SQL Server를 실행하는 서버와 비슷한 성능 사양이 있는지 확인합니다.

가상 테스트 환경에 서버 배포

업그레이드를 위한 가상 테스트 팜

실제 테스트 환경 사용

실제 환경을 사용하여 테스트할 때는 제안 프로덕션 서버 팜 환경을 최대한 그대로 복제해야 합니다. 프런트 엔드 웹 서버, 응용 프로그램 서버 또는 데이터베이스 서버의 수를 너무 많이 줄이면 업그레이드 프로세스에 소요되는 시간을 정확히 예측할 수 없습니다. 동일한 역할의 서버 간 상호 작용(예: SQL Server 트랜잭션)에서 발생하는 복잡성을 고려하지 않을 수 있습니다. 제안 프로덕션 팜에서 역할 하나에 여러 대의 서버가 있는 경우에는 테스트 팜에서는 해당 역할에 최소 두 대의 서버를 사용하여 해당 문제를 테스트해야 합니다.

실제 테스트 환경에 서버 배포

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

사용자 지정 확인 및 설치

정확한 테스트 프로세스를 수행하려면 현재 환경의 모든 사용자 지정 내용을 찾아 테스트 환경으로 복사해야 합니다. 식별해야 하는 사용자 지정 유형에 대한 자세한 내용은 SharePoint 2013으로 업그레이드하는 동안 현재 사용자 지정에 대한 계획 만들기를 참조하세요.

SharePoint 2010 제품 환경의 모든 콘텐츠 데이터베이스에서 Stsadm -o 열거형 웹 작업을 사용하여 하위 사이트에서 특정 사용자 지정을 식별합니다. 이 작업은 해당 환경에 포함된 각 사이트 모음 및 하위 사이트의 ID와 사이트에서 사용하는 서식 파일을 나열합니다. 자세한 내용은 Enumallwebs: Stsadm 작업을 참조하십시오.
대부분의 Microsoft 운영 체제에 제공되는 도구인 WinDiff와 같은 도구를 사용하여 프로덕션 환경 서버와 테스트 팜 서버를 비교합니다. 이 도구는 서버에 있는 파일 및 파일 간의 차이를 확인할 때 사용할 수 있습니다.
web.config 파일의 변경 내용을 확인하고 SafeControls 요소에서 사용자 지정 컨트롤이 있는지 확인합니다.
검색한 모든 사용자 지정 내용의 목록을 만듭니다. 가능하면 사용자 지정 내용의 원본을 확인합니다. 예를 들어 조직 내에서 사용자 지정한 타사의 추가 기능이나 서식 파일이 있는지 확인합니다. 원본을 확인하면 해당 사용자 지정 내용의 업데이트된 버전이나 업그레이드된 버전을 확인할 수 있습니다.

팁

직접 만들지 않은 사용자 지정 내용에 대해서는 다음과 같이 문의할 수 있습니다. > Microsoft 웹 사이트에서 다운로드한 템플릿에 문제가 있는 경우 Microsoft에 문의하세요. > 이전 버전에 대해 제공한 템플릿 또는 구성 요소에 문제가 있는 경우 타사 솔루션 공급업체에 문의하세요. 업그레이드된 버전이 제공될 수 있습니다.

모든 사용자 지정 내용을 확인한 후에는 해당 내용을 테스트 팜의 적절한 서버로 복사합니다. 다음과 같은 사용자 지정 내용이 배포되었는지 확인합니다.

솔루션 - 이전 솔루션은 기본적으로 /14 디렉터리에 배포됩니다. 솔루션을 설치할 때 CompatibilityLevel 매개 변수를 사용하여 이전 솔루션을 /15 디렉터리로 배포하십시오. 자세한 내용은 Install-SPSolution을 참조하십시오.
사용자 지정 마스터 페이지
사용자 지정 JavaScript
사용자 지정 CSS 파일(테마용 파일 포함)
사용자 지정 워크플로 작업(작업 파일에 포함되어야 함)
사용자 지정 큰 목록 쿼리 제한 설정 - 큰 목록이 정상적으로 표시되도록 합니다.

사용자 지정 내용을 테스트할 때는 다음 지침을 따릅니다.

표시 변경 내용을 확인합니다.
동작 변경 내용을 확인합니다.
2010 및 2013 모드 사이트 모음 둘 다에서 테스트를 수행합니다.
언어 또는 리소스 로드 문제를 파악합니다.

이 문제는 2010 모드의 사용자 지정 내용이 2013 모드에서 새 사용자 지정 내용으로 바뀌는 경우 발생할 수 있습니다. 언어 리소스용 전역 디렉터리는 하나뿐이므로 올바른 파일을 로드하는 데 문제가 있을 수 있습니다. 두 모드에서 사용자 지정 내용이 계속 정상적으로 작동하도록, 교체되는 2013 사용자 지정 내용에 2010 리소스가 포함되는지 확인하십시오.
업그레이드가 사용자 지정에 영향을 미치지 않는지 확인합니다. 사용자 지정이 사이트 모음 업그레이드를 차단하지 않는지 확인합니다.

SharePoint 2013에 데이터베이스를 연결하기 전에 Test-SPContentDatabase Microsoft PowerShell cmdlet을 사용하여 사용자 지정이 환경에서 누락되었는지 여부를 확인할 수 있습니다. 데이터베이스를 데이터베이스 서버로 복원한 후 업그레이드를 실행하기 전에 각 데이터베이스에 대해 이 명령을 실행합니다. 이 cmdlet은 자동으로 실행되며 발견된 문제가 없으면 아무 내용도 출력되지 않습니다.

테스트 환경에 실제 데이터 복사 및 데이터베이스 업그레이드

실제 데이터를 사용하지 않으면 테스트 목적을 달성할 수 없습니다. Microsoft SQL Server 백업 및 복원 도구를 사용하여 콘텐츠 및 서비스 데이터베이스의 복사본을 만듭니다.

업그레이드 중에 발생할 수 있는 작업을 모든 데이터의 복사본에 대해 테스트를 수행하는 것보다 더 좋은 방법은 없습니다. 그러나 초기 테스트에 항상 현실적인 옵션이 아닐 수도 있습니다. 한 번에 하나의 데이터베이스(데이터베이스가 큰 경우)를 테스트하여 단계별로 테스트할 수 있으므로 해당 데이터 세트에 대한 고유한 항목을 테스트할 수 있습니다. 또는 사용자 환경의 대표 사이트에서 데이터의 하위 집합을 어셈블할 수 있습니다. 먼저 데이터의 하위 집합을 사용하여 테스트하는 경우 다음과 같은 특성을 갖는 하위 집합이어야 합니다.

데이터 하위 집합에 사용 환경에서 지원하는 사이트를 대표할 수 있는 전형적인 사이트를 포함해야 합니다.
데이터 하위 집합의 크기 및 복잡성이 사용 환경의 실제 크기 및 복잡성과 비슷해야 합니다.

중요

데이터 하위 집합을 테스트하는 경우에는 사용 환경에 있는 전체 데이터 볼륨을 처리하는 데 걸리는 시간에 대한 유효한 벤치마크가 생성되지 않습니다.

데이터를 복사한 후에 첫 번째 업그레이드 프로세스를 수행하여 결과를 확인합니다. 이것은 준비 단계일 뿐입니다. SharePoint 2010에서 SharePoint 2013으로 콘텐츠 데이터베이스 업그레이드의 단계에 따라 데이터베이스 연결 업그레이드 프로세스를 시도합니다.

업그레이드 프로세스를 테스트할 때는 여러 팜에서 공유되는 서비스를 테스트해야 합니다. 다음과 같은 모든 상태를 고려하십시오.

SharePoint 2013 서비스 팜에 연결된 SharePoint Server 2010 팜
SharePoint 2013 서비스 팜에 연결된 SharePoint 2013 팜
각 서비스에 대한 서로 다른 버전의 팜

테스트 환경에서 서비스 응용 프로그램의 보안, 구성, 호환성 및 성능 관련 문제를 확인합니다.

데이터베이스 업그레이드 후 결과 검토

테스트 업그레이드가 완료되면 결과를 검토하고 계획을 다시 검토할 수 있습니다. 로그 파일을 보고, 업그레이드된 사이트를 살펴보고, 사용자 지정을 검토합니다. 업그레이드가 어떻게 진행되었습니까? 무엇을 발견했나요? 업그레이드 계획에 대해 무엇을 재고해야 합니까?

로그 파일 검토

업그레이드 로그 파일 및 업그레이드 오류 로그 파일(업그레이드를 실행할 때 생성됨)을 검토합니다. 업그레이드 로그 파일(.log) 및 업그레이드 오류 로그 파일(.err)은 %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LOGS에 있습니다. 로그 파일의 이름은 Upgrade- YYYYMMDD-HHMMSS-SSS.log 형식으로 지정됩니다. 여기서 YYYYMMDD 는 날짜이고 HHMMSS-SSS 는 시간(24시간 클록 형식, 분, 초 및 밀리초)입니다.

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

2010 모드의 사이트 검토

업그레이드되지 않은 사이트 모음이 2010 모드에서 정상적으로 작동하는지 확인합니다. 사이트는 SharePoint 2010 제품에서와 같이 보이고 동작해야 합니다. 단, 몇 가지 사항은 변경됩니다. 예를 들어 SharePoint 2013에서는 Office Online 및 웹 분석 기능이 변경되었으며 이러한 기능을 사용한 사이트가 영향을 받습니다. 찾을 특정 항목에 대한 자세한 내용은 SharePoint 2010에서 SharePoint 2013으로 업그레이드 프로세스 개요를 참조하세요.

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

필요한 경우 Upgrade-SPContentDatabase Microsoft PowerShell cmdlet을 사용하여 데이터베이스에 대한 업그레이드 프로세스를 다시 시작할 수 있습니다. 이 cmdlet에 대한 자세한 내용은 Upgrade-SPContentDatabase를 참조하십시오. 자세한 내용은 데이터베이스 연결 업그레이드 다시 시작 또는 SharePoint 2013으로 사이트 모음 업그레이드를 참조하세요.

사이트 모음 및 내 사이트 업그레이드

콘텐츠 및 서비스 데이터베이스에 대한 업데이트를 테스트하고 유효성을 검사한 후에는 사이트 모음에 대한 업그레이드 프로세스를 테스트할 수 있습니다. 사이트 모음을 SharePoint 2013으로 업그레이드의 단계에 따라 사이트 모음 업그레이드 프로세스를 테스트합니다. 사용자 환경에 내 사이트가 있는 경우 업그레이드 프로세스에 대한 자세한 내용은 SharePoint 2010에서 SharePoint 2013으로 업그레이드 프로세스 개요를 참조하세요.

참고

내 사이트에 대한 콘텐츠는 SharePoint 2013에만 적용됩니다.

사이트 모음 업그레이드 후 결과 검토

업그레이드된 사이트의 모양을 검토하여 프로덕션 환경에서 업그레이드 프로세스를 실행하기 전에 해결해야 하는 모든 문제를 확인합니다. 찾을 특정 항목에 대한 자세한 내용은 SharePoint 2010에서 SharePoint 2013으로 업그레이드 프로세스 개요를 참조하세요.

사이트 모음 업그레이드 로그 파일을 검토하여 위에서 아래로 시작하는 문제를 확인합니다. 로그 파일 끝 부근의 요약 섹션을 확인하여 문제 수 및 실제 업그레이드 상태를 확인합니다(상태가 없는 경우 업그레이드 프로세스가 실패하고 사이트 업그레이드를 다시 시도해야 한다는 의미). 사이트 모음 로그 파일은 사이트 모음 자체(_catalogs/업그레이드 문서 라이브러리)와 파일 시스템에 모두 저장됩니다. 문제에 대한 세부 정보를 원하는 경우 파일 시스템 로그 파일에 자세한 정보가 있습니다. 사이트 업그레이드 로그 파일의 파일 시스템 버전은 %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LOGS에 있습니다. 로그 파일의 이름은 SiteUpgrade- YYYYMMDD-HHMMSS-SSS.log 형식으로 지정됩니다. 여기서 YYYYMMDD 는 날짜이고 HHMMSS-SSS 는 시간(24시간 형식, 분, 초 및 밀리초)입니다.

계획 조정 및 다시 테스트

업그레이드 중에 발생할 수 있는 모든 문제와 그 해결 방법을 찾을 때까지 테스트 프로세스를 반복합니다. 계획을 잘 파악하는 것을 목표로 해야 합니다. 예를 들어 지금이 일요일 오후 4시이고 월요일 아침까지 온라인 상태로 돌아가야 하는데 문제가 해결되지 않은 경우 대체 방법이 없다면 곤란할 것입니다. 실제 업그레이드를 시작하기 전에 대체 계획을 테스트하여 문제없이 수행할 수 있도록 해야 합니다.