SharePoint Server 제로 가동 중지 시간 패치 단계
적용 대상:
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
ZDP(제로 가동 중지 시간 패치)는 SharePoint Server 2016, SharePoint Server 2019 및 SharePoint Server 구독 버전 사용할 수 있습니다. SharePoint Server 팜을 패치할 때 사용자가 문서를 계속 작업, 저장 및 검색할 수 있도록 합니다.
가동 중지 시간 패치 0은 Microsoft 365의 SharePoint에서 개발된 패치 및 업그레이드 방법입니다. 사용자가 구독을 계속 사용하고 있을 때 관리자가 서비스를 패치할 수 있도록 하기 위한 방법입니다. 즉, 이 테스트된 방법은 사람들이 SharePoint Server 팜에서 파일 및 검색 크롤링을 사용하고, 결과를 렌더링하는 동안 패치를 허용하도록 설계되었습니다. 이것이 '가동 중지 시간 0'의 의미입니다.
ZDP을 논의할 때 유의해야 할 몇 가지 사항이 있습니다(이 문서 뒷부분에 이러한 요소에 대해 논의됨).
SharePoint Server에서 MinRole을 사용하여 ZDP 환경을 향상시킬 수 있지만 MinRole은 요구 사항이 아닙니다 .
팜은 ZIP의 이점을 높이기 위해 HA(고가용성) 기능을 활용해야 합니다. 고가용성 SharePoint Server 팜 은 ZDP에 대한 요구 사항입니다.
ZDP의 목적은 사용자를 위한 가동 시간을 확보하는 것이므로 이 문서에서 팜 패치 및 재부팅과 관련된 모든 결정은 이러한 성향을 염두에 두고 내려집니다.
중요
SharePoint Server 팜의 모든 서버가 '사용자 지정' 역할을 사용하도록 구성된 경우에도 고가용성 팜을 수동으로 구성할 수 있습니다. 고가용성 팜을 구성하는 데 도움이 되는 문서가 있으며, 내결함성(중복 하드웨어 포함) 및 고가용성(장애 조치(failover) 및 가동 시간 연속을 지원하기 위한 시스템 및 소프트웨어 사용)의 원칙은 동일합니다. 더 복잡한 고가용성 또는 사용자 지정 팜에서는 HA를 지원하는 방식으로 검색 서버를 패치하는 데 특히 주의해야 합니다. 예를 들어 한 번에 하나의 인덱스 복제본을 패치하고 동시에 동일한 파티션에서 인덱스 복제본을 패치하거나 업그레이드하지 않아야 합니다.
ZDP 프로세스
이 예제에서는 MinRole을 사용하여 SharePoint Server 팜 설정에 대해 ZDP를 사용합니다. 예제 환경은 다음과 같습니다.
이 구조를 분류하기 위해, 현재 요청을 처리하고 있는 두 WFE(웹 프런트 엔드)(SPWeb01 및 02)가 부하 분산 장치에 연결됩니다. 두 대의 응용 프로그램 서버(SPApp01 및 02), 두 대의 분산 캐시 서버(SPDCH01 및 02), 두 대의 검색 서버(SPSRCH01 및 02)가 있습니다. 이 구조 이면에는 ZDP 프로세스에 직접 포함되지는 않지만 SQL Server 클러스터(예: SQL Server Always-On)가 있습니다.
이상적으로 이 다이어그램에서 팜 중앙을 관통해서 위에서 아래로 선을 그릴 수 있습니다. 줄의 한쪽에는 '01'(열 1)로 끝나는 모든 서버가 있고 , '02'의 중복 서버는 다른 쪽(열 2)에 있습니다. 패치하는 동안 사용자를 위해 팜을 유지하기 위해 이 이중 구성을 사용합니다.
대부분의 경우 줄의 한쪽(01개 서버)에서 수행하는 모든 작업은 정확히 02에 대해 반복됩니다. 비교적 간단한 2단계의 ZDP 프로세스에 포함된 모든 단계에서 WFE(SPWeb01 및 02)를 사용하여 수행되는 작업이 가장 복잡합니다. 여기서 시작하겠습니다.
참고
SharePoint Server용 소프트웨어 업데이트 대한 일반적인 정보는 여기에서 확인할 수 있습니다. 이 문서는 SharePoint Server에 대한 사용 권한 설정 에 대한 설명서로 연결됩니다. 필요에 따라 이러한 문서를 검토하고, 패치 부분에 데이터베이스 업데이트가 포함된다는 사실을 기억하세요. 예를 들어 설치 후 SharePoint 계정에 대한 SQL Server 권한을 변경한 경우 이러한 문서를 검토해야 합니다.
먼저 패치할 WFE가 회전에서 제외되고 다른 WFE가 결과 부하를 처리하지 않는 상황을 방지하기 위해 부하 분산 장치에서 나가기 전에 WFE를 다시 부팅하고 테스트했는지 확인합니다. 팜의 모든 서버는 재부팅 후에 원래 상태가 되고, 패치 전에 정상 상태여야 합니다. 또한 업그레이드 또는 패치 기간 동안 검색 크롤링 및 프로필 가져오기를 중지하는 것이 좋습니다.
중요
병렬로 실행하면, 주어진 WFE의 정적 파일이 업그레이드 또는 대체되는 동안에도 팜의 모든 웹 프런트 엔드가 업그레이드 중에 동일한 정적 콘텐츠를 제공하게 됩니다. 병렬은 PSCONFIG에 기본 제공되지만 사용하도록 설정해야 합니다. 이 기능은 파일 시스템 파일이 변경 및 업데이트되는 동안에도, 사용자들이 SharePoint를 검색하고 파일로 작업을 수행할 때 동일한 사이트 환경을 사용할 수 있도록 합니다.
병렬 기능을 사용하도록 설정하려면 콘텐츠 웹 애플리케이션 중 하나에 대한 URL을 사용하여 다음 PowerShell 스크립트를 한 번 실행합니다.
$webapp = Get-SPWebApplication <webappURL>
$webapp.WebService.EnableSideBySide = $true
$webapp.WebService.update()
SharePoint Server 2016 이상에 대한 KB3178672 (2017년 3월 업데이트)를 기준으로 PSCONFIG는 폴더 내 16-HIVE\TEMPLATE\LAYOUTS 의 모든 .js, .css 및 .htm 파일을 폴더 16-HIVE\TEMPLATE\LAYOUTS\<NEW BUILD NUMBER> 에 자동으로 복사하며, 새 사용자 인터페이스 파일로 전환하고 2단계 - PSCONFIG 업그레이드(4단계)의 뒷부분에 설명된 대로 병렬 프로세스를 완료할 수 있어야 합니다.
1단계 - 패치 설치
첫 번째 단계는 서버에서 패치 바이너리를 가져오고 설치하는 것입니다.
부하 분산 장치에서 첫 번째 WFE(SPWeb01)를 꺼내 'STS' 및 'WSS' 패키지로 패치합니다.
패치가 완료되면 서버를 다시 부팅합니다.
부하 분산 장치에서 순환할 서버를 반환합니다.
부하 분산 장치에서 두 번째 WFE(SPWeb02)를 꺼내서 'STS' 및 'WSS' 패키지로 패치합니다.
패치가 완료되면 서버를 다시 부팅합니다.
전체 업그레이드가 완료될 때까지 이 서버를 부하 분산 장치에서 제외합니다.참고
유지 관리 기간에 업그레이드를 실행하지 않으며 팜에 많은 부하가 발생할 경우 PSCONFIG를 실행할 준비가 될 때까지 이 WFE를 네트워크 부하 분산 장치로 반환할 수 있습니다.
열 1의 SPApp, SPDCH 및 SPSRCH 각각에 대해 'STS' 및 'WSS' 패키지를 사용하여 패치합니다.
완료되면 다시 부팅합니다. SPWeb01에서 보낸 작업은 열 2의 서버에 포함됩니다.
이제 열 2에 대해 '패치 및 다시 부팅'을 반복합니다. 열 2의 SPApp02, SPDCH02 및 SPSRCH02 각각에 대해 'STS' 및 'WSS' 패키지를 사용하여 패치합니다.
완료되면 다시 부팅합니다. (볼 수 있듯이 SPWeb01에서 보낸 작업은 이제 열 1의 서버에 포함됩니다.)
2단계 - PSCONFIG 업그레이드
SharePoint Server 팜의 모든 노드에는 패치가 설치되어 있으며 모두 다시 부팅되었습니다. 빌드-빌드 업그레이드를 수행해야 할 때입니다.
참고
ZDP 프로세스 중에 Upgrade-SPContentdatabase 를 실행하여 PSCONFIG 실행을 완료하는 데 걸리는 전체 시간을 줄일 수 있습니다. 많은 수의 데이터베이스가 있거나 큰 데이터베이스를 선택하는 경우 이 방법을 고려하세요.
부하 분산된 회전(SPWeb02)이 아닌 WFE로 돌아가 SharePoint 관리 셸을 열고 다음 PSCONFIG 명령을 실행합니다.
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install이 명령이 완료되면 이 WFE(SPWeb02)를 부하 분산 장치로 반환합니다. 이 서버는 완벽하게 패치된 후 업그레이드됩니다.
팁
PSCONFIG 프로세스의 마지막 단계는 UI(사용자 인터페이스)에 대한 업데이트를 /layouts 폴더에서 버전별 폴더로 복사되도록 하는 것입니다. 이것은 팜을 검색하는 사용자가 업그레이드가 완료되고 새 인터페이스로 전환할 준비가 될 때까지 한 가지 UI만 볼 수 있도록 하는 병렬 UI 업데이트에 해당됩니다.
병렬 복사가 성공했는지 확인하려면 연결된 로그 파일을 확인합니다. 기본적으로 다음 아래에 있습니다.
C:\program files\common files\Microsoft shared\web server extensions\16\logs. (루트 드라이브 문자는 다를 수 있습니다!)
어떤 이유로 PSCONFIG에서 UI 파일을 성공적으로 복사하지 못한 경우 이 명령을 실행하여 Copy-SidebySideFiles를 수동으로 복사하세요.
부하 분산 장치에서 SPWeb01을 제거합니다. > SharePoint 관리 셸을 열고 동일한 PSCONFIG 명령을 실행합니다.
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install이 WEF(SPWeb01)를 부하 분산 장치로 되돌립니다. 또한 이제 완전히 패치되고 업그레이드되었습니다.
두 WFE 모두 패치되고 업그레이드됩니다. 팜의 나머지로 이동하지만 필요한 Microsoft PowerShell 명령이 동시에 실행되지 않고 한 번에 하나의 서버를 실행해야 합니다. 즉, 모든 열 1에 대해 한 번에 하나의 서버 명령을 실행합니다. 그런 다음 겹치지 않고 열 2의 서버에 대해 한 번에 하나의 서버로 실행합니다. 최종 목표는 가동 시간을 유지하는 것입니다. PSCONFIG 명령을 직렬로 실행하는 것이 ZDP 프로세스를 완료하는 가장 안전하고 예측 가능한 수단이므로 이 작업을 수행합니다.
열 1의 나머지 모든 서버(SPApp01, SPDCH01, SPSRCH01)에 대해 SharePoint Management Shell에서 동일한 PSCONFIG 명령을 실행합니다. 열 1에 있는 모든 서버가 업그레이드될 때까지 한 번에 하나씩 각 서버에서 이 작업을 수행합니다.
중요
PSCONFIG를 실행하기 전에 정상적으로 분산 캐시를 제거하고 완료된 후에 다시 분산 캐시를 서버에 추가해야 합니다.
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
열 2의 나머지 모든 서버(SPApp02, SPDCH02, SPSRCH02)에 대해 SharePoint 관리 셸에서 동일한 PSCONFIG 명령을 실행합니다. 열 2에 있는 모든 서버가 업그레이드될 때까지 한 번에 하나씩 각 서버에서 이 작업을 수행합니다.
중요
PSCONFIG를 실행하기 전에 정상적으로 분산 캐시를 제거하고 완료된 후에 다시 분산 캐시를 서버에 추가해야 합니다.
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install중요
모든 서버가 PSCONFIG를 성공적으로 통과한 후에는 아래 SharePoint Management Shell 명령을 실행하여 새 사용자 인터페이스 파일로 전환하고 병렬 프로세스를 완료해야 합니다.
$webapp = Get-SPWebApplication <webappURL>$webapp.WebService.SideBySideToken = <current build number in quotes, ex: "16.0.4338.1000">
$webapp.WebService.update()
이제 작업이 끝났으며 팜은 사용 중인 동안 가동 중지 시간 없이 완전히 업그레이드되었습니다.
MinRole이 도움이 되는 이유
ZDP에 대해 이야기할 때 MinRole의 개념도 다루어야 합니다. MinRole은 SharePoint Server 2016, SharePoint Server 2019 및 SharePoint Server 구독 버전 설치하는 옵션입니다. 팜의 구성을 프런트 엔드(WFE), 애플리케이션 서버(앱), DCache(분산 캐시), 검색 또는 사용자 지정(사용자 지정 코드 또는 타사 제품의 경우)과 같은 역할로 나눕니다. 이 구성은 WFE 2대, 앱 서버 2대, DCache 서버 2대, 검색 서버 2대 등 평균 4대의 서버를 제공합니다.
기본적으로 WFE는 낮은 대기 시간을 위해 조정되고, 앱 서버는 높은 처리량을 위해 조정됩니다. 마찬가지로 호출이 시작된 상자를 그대로 둘 필요가 없도록 검색 구성 요소를 번들로 묶으면 검색 서버가 더 효율적으로 작동합니다. MinRole의 가장 큰 장점 중 하나는 내결함성을 기본적으로 제공한다는 것입니다.
고가용성이 필요한 이유
HA는 SharePoint에서 포괄적으로 적용되는 기능입니다. 이 설명서와 같이 전체 백서 및 온라인 문서가 있습니다. 개념을 단순화하기 위해 적어도 이 문서에서는 ZDP(및 MinRole)가 Microsoft 365의 SharePoint에서 시작되었음을 인식합니다. Microsoft 365의 SharePoint에서 가상화된 서버에는 중복성이 기본 제공되므로 동일한 SharePoint 팜의 동일한 서버 역할 중 두 가지가 동일한 호스트 또는 랙에 있지 않습니다. 따라서 SharePoint의 내결함성이 높아집니다. 각 SharePoint Server 역할 2개를 자체 데이터 센터의 다른 랙에 있는 별도 호스트에 배치하고, 보다 빠른 통신을 위해 랙 간에 공유 라우터 및 배선을 사용해서 동일한 상황을 모델링할 수 있습니다. 또한 테스트 환경에서 각 SharePoint Server 역할에 대해 2개의 실제 서버를 설정할 수 있습니다(팜의 각 절반에 대해 별도의 전원 표시줄을 선택하고, 서버 집합 간의 라우팅이 빠른지 확인하고, 가능한 경우 대기 시간을 낮추기 위해 좀 더 광범위한 네트워크 트래픽을 우회함).
여기서 목표는 고가용성과 내결함성입니다. 즉, 최우선 순위는 랙 또는 서버 간에 역할을 분리하고, 각 역할을 2개씩 유지하고, 이러한 두 계층 간에 빠른 네트워크 트래픽을 촉진하고, 모니터링할 시스템을 설정하고 데이터베이스 서버를 자동으로 장애 조치(failover)하도록 설정하는 것입니다. SharePoint에서 서비스를 수동으로 설치하는 경우('사용자 지정' 역할을 선택하는 경우와 같음) 서비스가 팜 내에서 중복성을 가져야 합니다. 예를 들어 분산 캐시가 클러스터되고, 팜에 여러 WFE가 있고, 응용 프로그램 및 검색 서버를 쌍으로 설정해야 합니다. 이러한 식으로 한 서버에 심각한 문제가 발생할 경우 다른 서버가 사용자 부하를 처리할 수 있습니다.
여기서 사용된 예제에서는 개념을 보다 쉽게 나타내기 위해 실제 서버를 사용합니다. ZDP를 계획할 때는 어디에 있든 고유한 환경을 만들어야 합니다(랙 이름/번호 및 각 SharePoint Server 역할을 찾을 수 있는 서버 이름 포함). 이렇게 하는 것은 설정의 크기에 관계 없이 설정에서 나타날 수 있는 역할 중복 및 내결함성 목표 위반 사례를 찾아내는 가장 빠른 방법 중 하나입니다.