Azure DevOps 온-프레미스에 대해 한 하드웨어에서 다른 하드웨어로 이동 또는 복제
Azure DevOps Server 2022 | Azure DevOps Server 2020 | Azure DevOps Server 2019
Azure DevOps Server 소프트웨어 배포를 이동하거나 복제할 수 있습니다. Azure DevOps Server 새 하드웨어(복원 기반 이동이라고 함)로 복원하여 한 컴퓨터에서 다른 컴퓨터로 이동합니다. 예를 들어 더 큰 용량 또는 향상된 처리 속도를 가진 서버로 Azure DevOps Server 이동할 수 있습니다. 새 서버로 이동하면 프로젝트 기록이 손실되지 않습니다.
Azure DevOps Server 배포를 복제하려면 이동과 동일한 단계와 몇 가지 추가 단계를 수행합니다.
원래 하드웨어 및 Azure DevOps Server 배포 사용을 중단하려는 경우 이동을 수행합니다. 원래 Azure DevOps Server instance 계속 사용하려는 경우 복제를 수행합니다.
중요
일부 상황에서는 하드웨어뿐만 아니라 Azure DevOps Server 배포의 도메인을 변경할 수도 있습니다. 도메인 변경은 환경 기반 이동이며, 두 이동 유형을 결합하면 안 됩니다. 먼저 하드웨어 이동을 완료한 다음 환경을 변경합니다.
권한 확인
Azure DevOps Server 성공적으로 이동하려면 두 하드웨어 집합(이전 및 신규)의 관리자여야 합니다. 또한 Azure DevOps Server 및 배포가 종속된 모든 소프트웨어(SQL Server, 보고 및 배포가 상호 운용되는 기타 소프트웨어(예: Project Server)에 대한 관리자(또는 동등한 권한)가 있어야 합니다.
다음 그룹의 구성원인지 확인합니다.
- 서버: Administrators(로컬 Administrators 그룹 또는 동등 수준 그룹)
- Azure DevOps Server: Team Foundation 관리자 및 관리 콘솔 사용자
- SQL Server: sysadmin
이러한 그룹 중 하나 이상의 구성원이 아닌 경우 지금 사용 권한을 가져옵니다.
데이터베이스 및 암호화 키 백업
Azure DevOps Server 관리 콘솔을 열고 예약된 백업 페이지에서 전체 백업을 수행합니다. 백업을 수행하면 백업 계획에서 백업에 대해 구성된 모든 항목이 백업되지만 이 백업은 계획에서 예약된 시간이 아니라 즉시 수행됩니다. 배포에서 보고를 사용하는 경우 이 백업 집합의 일부로 암호화 키를 백업할 수 있습니다.
(구성된 백업이 없는 경우 전체 백업을 수행하려면 계획을 만들어야 합니다.)
백업이 완료되면 저장 장치 또는 네트워크 공유에서 백업을 사용할 수 있고 새 하드웨어에서 이 백업에 액세스할 수 있는지 확인합니다.
새 데이터 계층 서버에 SQL Server 설치 및 구성
새 서버에 SQL Server 설치하고 작동 중인지 확인합니다. 이전 배포에 보고가 사용된 경우 보고 및 Analysis Services 구성 요소를 포함해야 합니다. 서비스 팩 및 누적 업데이트 수준을 포함하여 이전에 사용한 것과 동일한 버전을 설치해야 합니다.
또는 이미 일치하는 버전이 설치된 서버에 SQL Server instance 만들고 Azure DevOps Server 데이터베이스를 해당 instance 복원할 수 있지만 복원 후 구성이 더 필요합니다.
SQL Server 설치 및 구성하기 위한 옵션에 대한 자세한 내용은 여기를 참조하세요.
SQL Server를 설치한 후 배포에 보고가 포함된 경우 SQL Server Management Studio를 열고 ReportServer 및 ReportServerTempDB 데이터베이스를 분리합니다. 그렇지 않으면 Azure DevOps Server 데이터베이스에 대해 만든 백업을 사용하여 이러한 데이터베이스를 복원하지 못할 수 있습니다.
새 응용 프로그램 계층 서버에 소프트웨어 설치 및 구성
Azure DevOps Server 새 서버 또는 서버를 구성하려면 먼저 지원하는 데 필요한 소프트웨어를 설치하고 구성해야 합니다. 이 소프트웨어에는 다음과 같은 구성 요소가 포함되어 있습니다.
배포 구성에 지원되는 운영 체제
Windows, IIS(기본적으로 구성되지 않은 경우)를 설치 및 구성하고 서버와 해당 소프트웨어가 작동하는지 확인합니다.
Azure DevOps Server 데이터베이스 복원
복원 도구를 사용하여 Azure DevOps Server 데이터베이스를 복원하려면 새 데이터 계층 서버에 Azure DevOps Server 설치하지만 구성하지 말고 예약된 백업 노드에서 복원 함수를 사용해야 합니다.
SQL Server 복원 도구를 사용하여 Azure DevOps Server 데이터베이스를 수동으로 복원하려는 경우 더 어려운 절차입니다. 또한 새 배포에서 데이터베이스를 수동으로 정지 해제해야 합니다. Azure DevOps Server 복원 마법사는 복원 프로세스의 일부로 자동으로 이 작업을 수행하지만 해당 기능은 SQL Server 복원 도구의 일부가 아닙니다.
Azure DevOps Server 설치 미디어를 시작합니다. Team Foundation Server 설치 페이지에서 설치를 선택합니다.
설치가 완료되면 Team Foundation Server 구성 센터가 열립니다. 설치 미디어를 닫습니다.
관리 콘솔이 구성되지 않은 상태로 자동으로 열립니다. 예상된 동작입니다.
복원 마법사를 시작하려면 Azure DevOps Server 관리 콘솔을 열고 예약된 백업을 엽니다.
백업 집합의 경로를 지정하고 이전 배포를 정지한 후에 만든 집합을 선택합니다.
마법사를 완료하고 새 SQL Server 인스턴스로 데이터베이스를 복원합니다.
(복제 옵션) 서버 ID 다시 구성 및 데이터베이스 다시 매핑
참고
PrepareClone은 다른 서버에서 이미 프로덕션에 있는 데이터베이스 백업을 사용하여 새 Azure DevOps Server 배포를 설치하기 전에 사용하는 것이 좋습니다. 구성 마법사의 사전 프로덕션 업그레이드 및 복제 시나리오에 해당 기능을 통합했기 때문에 이 명령은 더 이상 필요하지 않습니다.
원래 Azure DevOps Server instance 계속 사용하려는 경우 새 애플리케이션 계층 서버에서 다음 단계 집합을 수행합니다. 이러한 단계는 하나 또는 두 배포 모두가 손상되는 위험을 방지하기 위해 필요합니다. 두 서버가 모두 라이브 상태인 경우 특히 동일한 보고 리소스를 가리키는 경우 손상이 발생할 수 있습니다.
관리자 권한으로 명령 프롬프트 창을 열고 디렉터리를 Drive:%programfiles%\TFS 12.0\Tools로 변경합니다. 명령 프롬프트 창을 열고 다음을 입력합니다.
TFSConfig PrepareClone 명령을 실행하여 예약된 백업 및 보고 리소스에 대한 정보를 제거합니다.
TFSConfig PrepareClone /SQLInstance:ServerName /DatabaseName:DatabaseName /notificationURL: ApplicationTierURLTFSConfig ChangeServerID 명령을 실행하여 데이터베이스와 연결된 서버 GUID를 변경합니다. GUID는 Azure DevOps Server 배포 내에서 고유해야 합니다.
TFSConfig ChangeServerID /SQLInstance:ServerName] /DatabaseName:ConfigurationDatabaseName [/ProjectCollectionsOnly] [/ConfigDBOnly] [/usesqlalwayson]TFSConfig RemapDBs 명령을 실행하여 복제된 Azure DevOps Server 해당 데이터베이스로 리디렉션합니다.
TFSConfig RemapDBs /DatabaseName:ServerName;DatabaseName /SQLInstances:ServerName1,erverName2 [/AnalysisInstance:ServerName] [/AnalysisDatabaseName:DatabaseName] [/review] [/continue] [/usesqlalwayson]
애플리케이션 계층 서버 구성
Azure DevOps Server 관리 콘솔에서 설치된 기능 구성을 선택하여 구성 센터를 시작합니다.
Application-Tier 전용 마법사를 시작하고 데이터베이스에서 Azure DevOps Server 데이터베이스를 복원한 새 SQL Server instance 지정합니다. 목록에서 Tfs_Configuration 데이터베이스를 선택합니다.
마법사의 최종 페이지를 닫기 전에 "i" 기호를 찾습니다. 이 기호는 나중에 참조할 수 있는 정보를 나타냅니다. 마지막 페이지에는 구성 로그의 위치도 포함됩니다.
Azure DevOps Server URL 업데이트
애플리케이션 계층 노드로 이동하여 알림 및 웹 포털 URL을 확인합니다. 여전히 이전 배포 위치를 가리키고 있습니다. 정보를 업데이트합니다.
새 서버의 이름으로 URL을 업데이트한 후 정보가 올바른지 검토합니다.
모든 서비스 계정 업데이트
Azure DevOps Server(TFSService) 및 데이터 원본 계정(TFSReports)에 대한 서비스 계정을 업데이트해야 합니다. 이러한 계정이 변경되지 않았더라도 계정의 형식 및 ID를 새 서버에 적절하게 하려면 정보를 업데이트해야 합니다.
관리자 권한으로 명령 프롬프트 창을 열고 디렉터리를 Drive:\%programfiles%\TFS 12.0\Tools로 변경합니다.
명령 프롬프트에서 다음 명령을 입력하여 Azure DevOps에 대한 서비스 계정을 추가합니다. 여기서 DatabaseName 은 구성 데이터베이스의 이름입니다(기본적으로 TFS_Configuration).
TfsConfig Accounts /add /AccountType:ApplicationTier /account:AccountName/SQLInstance:ServerName/DatabaseName:DatabaseName
명령 프롬프트에 다음 명령을 입력하여 데이터 소스 계정을 추가합니다.
TfsConfig Accounts /add /AccountType:ReportingDataSource /account:AccountName/SQLInstance:ServerName/DatabaseName:DatabaseName
자세한 내용은 계정 명령을 참조하세요.
빌드 서버 업데이트
이제 이동된 Azure DevOps Server 배포를 가리키도록 빌드 서버를 리디렉션해야 합니다.
각 빌드 서버에서 관리 콘솔을 열고 빌드 서비스를 중지합니다.
빌드 서비스의 속성에서 통신 속성을 업데이트합니다.
보고 및 Analysis Services 구성
배포에서 보고서 서버를 사용하는 경우 Azure DevOps Server 해당 위치로 리디렉션하고, 웨어하우스를 다시 시작하고, Analysis Services용 데이터베이스를 수동으로 다시 빌드해야 합니다. 보고를 사용하지 않는 경우에는 이 절차를 건너뜁니다.
보고 노드로 이동합니다. 나열된 보고서 서버 값이 이전 값으로 새 값이 아니므로 편집합니다.
새 서버를 가리키도록 3개의 탭 모두에서 값을 변경합니다. 새 배포의 데이터 소스 계정에 대한 올바른 정보를 제공해야 합니다.
작업 시작을 선택하여 보고를 다시 시작합니다.
다시 빌드 시작을 선택하여 웨어하우스를 다시 빌드합니다.
사용자, 그룹 및 서비스 계정의 권한 확인
새 하드웨어로 이동한 후에는 배포에 대한 모든 사용자, 그룹 및 서비스 계정이 각 서버에서 올바르게 작동하는 데 필요한 권한을 사용하여 구성되었는지 확인합니다. SQL Server 또는 로컬 컴퓨터의 추가 권한 같은 일부 권한은 자동으로 마이그레이션할 수 없습니다. 예를 들어 Azure DevOps 관리자는 관리 콘솔을 열려면 애플리케이션 계층 서버의 로컬 Administrators 그룹의 구성원이어야 하므로 해당 그룹에 수동으로 추가해야 합니다.
서버에 로그온하고 사용자, 그룹 및 서비스 계정이 작동하는 데 필요한 권한으로 구성되었는지 확인합니다. 프로젝트 그룹과 팀의 멤버 자격을 수동으로 무작위 검사하고 이러한 그룹과 팀에 필요한 권한이 있는지 확인합니다.
프로젝트 컬렉션을 찾아 해당 컬렉션의 모든 프로젝트가 예상대로 표시되고 해당 프로젝트의 사용자가 작업 항목에 적절하게 액세스할 수 있는지 확인합니다.
웹 포털을 열고 팀 사이트와 팀이 예상대로 표시되는지 확인합니다.
필요한 그룹과 권한을 잘 모르시겠습니까? 자세한 내용은 프로젝트에 사용자 추가, 프로젝트 컬렉션에 대한 관리자 권한 설정, Azure DevOps Server 대한 관리자 권한 설정 및 Azure DevOps Server 서비스 계정 및 종속성을 참조하세요.
클라이언트 컴퓨터에서 데이터 캐시 새로 고치기
서버에 로그온하고 ClientService 웹 서비스를 사용하여 클라이언트가 작업 항목을 추적하고 Azure DevOps 버전 제어를 위해 캐시를 업데이트하도록 강제합니다.
http://ServerName:8080/tfs/WorkItemTracking/v3.0/ClientService.asmx자세한 내용은 클라이언트 컴퓨터에서 데이터 캐시 새로 고침을 참조하세요.
다음에 로그온할 때 모든 사용자의 전체 캐시를 새로 고치려면 witadmin rebuildcache 명령을 사용합니다.
참고
데이터베이스를 다른 시점으로 복원한 경우 클라이언트 컴퓨터의 데이터 캐시 새로 고침에 설명된 대로 버전 제어 캐시를 새로 고쳐야 합니다.
사용자에게 알림
이제 Azure DevOps Server 이동했으므로 이동된 배포에 연결하는 방법을 사용자에게 알려야 합니다. 특히, 다음 정보를 제공해야 합니다.
새 서버의 이름 및 웹 포털의 URL이므로 프로젝트에 다시 연결할 수 있습니다.
보고가 배포에 포함되어 있는 경우 보고의 새 데이터베이스 이름
Git을 사용하는 프로젝트의 멤버인 경우 해당 프로젝트의 모든 리포지토리에 대해 로컬로 있는 모든 클론을 업데이트하는 방법에 대한 지침입니다. 특히, 모든 복제에 대해 다음 명령을 실행해야 합니다.
git remote set-url <remote name> <new URL>사용자는 Explorer 탭에서 프로젝트를 검색하여 각 클론의 URL을 볼 수 있습니다.
백업 구성
이전 배포에 대해 예약된 백업은 이동한 배포를 백업하도록 변경되지 않았습니다. 해당 백업을 구성해야 합니다.
- 관리 콘솔에서 예약된 백업 노드로 이동하여 예약된 백업을 다시 구성하여 새 서버에서 Azure DevOps Server 데이터베이스를 백업합니다. 자세한 내용은 백업 일정 및 계획 만들기를 참조하세요.
Q & A
Q: 물리적 서버가 아닌 도메인을 변경하려고 합니다. 이것은 가능한가요?
A: 예. 이를 환경 기반 이동이라고 하며 단계는 여기에서 찾을 수 있습니다. 환경 기반 이동을 하드웨어 기반 이동과 함께 사용하지 않도록 해야 합니다. 먼저 하드웨어 이동을 완료한 다음 환경을 변경합니다.
Q: 새 하드웨어로 전환한 후에도 이전 Azure DevOps Server 계속 사용하고 싶다는 것을 깨달았습니다. 이것은 가능한가요?
A: 예, 하지만 즉시 추가 단계를 수행하는 것이 매우 중요합니다. 이동 또는 복제 단계의 일부분으로 이러한 단계를 수행하는 것이 가장 좋습니다. 그러면 배포 중 하나 또는 둘 다의 손상 위험을 방지할 수 있습니다. 두 서버가 모두 라이브 상태인 경우 특히 동일한 보고 리소스를 가리키는 경우 손상이 발생할 수 있습니다.
이 문제를 해결하려면 다음을 수행합니다.
새 서버에서 TFSConfig PrepareClone 명령 실행
새 서버에서 TFSConfig ChangeServerID 명령 실행
새 서버에서 TFSConfig RemapDBs 명령 실행
Q: 프로젝트 서버와 통합하는 배포가 있습니다. 이동한 Azure DevOps Server 작동하려면 추가 단계를 수행해야 하나요?
A: 예, 하드웨어 이동을 완료한 후 TFSAdmin ProjectServer/RegisterPWA 명령을 /tfs, /force 및 /pwa 옵션과 함께 사용하여 Project Server에 Azure DevOps Server 다시 등록해야 합니다. Project Server와의 Azure DevOps Server 통합에 대한 자세한 내용은 여기에서 확인할 수 있습니다.