다음을 통해 공유


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 인스턴스를 계속 사용하려는 경우 복제를 수행합니다.

Important

경우에 따라 Azure DevOps Server 배포의 도메인과 해당 하드웨어를 변경할 수 있습니다. 도메인을 변경하는 것은 환경 기반 이동이며 두 이동 형식을 결합해서는 안 됩니다. 먼저 하드웨어 이동을 완료한 다음 환경을 변경합니다.

권한 확인

Azure DevOps Server를 성공적으로 이동하려면 두 하드웨어 집합(이전 및 새 하드웨어)의 관리자여야 합니다. 또한 Azure DevOps Server 및 배포가 종속된 모든 소프트웨어(SQL Server, 보고 및 배포가 상호 운용하는 기타 소프트웨어(예: Project Server)에 대한 관리자(또는 동등한 사용 권한)가 있어야 합니다.

다음 그룹의 구성원인지 확인합니다.

  • 서버: 관리자(로컬 관리자 그룹 또는 해당)
  • Azure DevOps Server: Team Foundation 관리자 및 관리 콘솔 사용자
  • SQL Server: sysadmin

이러한 그룹 중 하나 이상의 멤버가 아닌 경우 지금 사용 권한을 가져옵니다.

데이터베이스 및 암호화 키 백업

  1. Azure DevOps Server에 대한 관리 콘솔을 열고 예약된 백업 페이지에서 전체 백업을 수행합니다 . 백업은 백업 계획에서 백업하도록 구성한 모든 항목을 백업하지만 계획에 예약된 시간이 아니라 즉시 백업됩니다. 배포에서 보고를 사용하는 경우 이 백업 집합의 일부로 암호화 키를 백업할 수 있습니다.

    작업이 완료되는 동안 창을 닫을 수 있습니다.

    (구성된 백업이 없는 경우 전체 백업을 수행하려면 계획을 만들어야 합니다.)

  2. 백업이 완료되면 스토리지 디바이스 또는 네트워크 공유에서 백업을 사용할 수 있고 새 하드웨어에서 이 백업에 액세스할 수 있는지 확인합니다.

새 데이터 계층 서버에 SQL Server 설치 및 구성

  • 새 서버에 SQL Server를 설치하고 작동 중인지 확인합니다. 이전 배포에서 보고를 사용한 경우 보고 및 분석 서비스 구성 요소를 포함해야 합니다. 서비스 팩 및 누적 업데이트 수준을 포함하여 이전에 사용한 버전과 동일한 버전을 설치해야 합니다.

    SQL Server 2008 R2 설치 - 기능

    또는 일치하는 버전이 이미 설치된 서버에 SQL Server 인스턴스를 만들고 Azure DevOps Server 데이터베이스를 해당 인스턴스로 복원할 수 있지만 복원 후 구성이 더 필요합니다.

    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 데이터베이스를 복원하려면 새 데이터 계층 서버에 Azure DevOps Server를 설치하지만 구성하지 말고 예약된 백업 노드에서 복원 함수를 사용해야 합니다.

SQL Server 복원 도구를 사용하여 Azure DevOps Server 데이터베이스를 수동으로 복원하려는 경우 더 어려운 절차입니다. 또한 새 배포에서 데이터베이스의 요구 사항을 수동으로 해제해야 합니다. Azure DevOps Server의 복원 마법사는 복원 프로세스의 일부로 자동으로 이 작업을 수행하지만 해당 기능은 SQL Server의 복원 도구에 포함되지 않습니다.

  1. Azure DevOps Server 설치 미디어를 시작합니다. Team Foundation Server 설치 페이지에서 설치를 선택합니다.

  2. 설치가 완료되면 Team Foundation Server 구성 센터가 열립니다. 닫습니다.

    관리 콘솔이 구성되지 않은 상태로 자동으로 열립니다. 예상된 동작입니다.

  3. 복원 마법사를 시작하려면 Azure DevOps Server에 대한 관리 콘솔을 열고 예약된 백업을 엽니다.

    복원 마법사 시작

  4. 백업 집합의 경로를 지정하고 이전 배포를 정지한 후 만든 집합을 선택합니다.

    네트워크 경로를 선택한 다음 복원 집합을 선택합니다.

  5. 마법사를 완료하고 데이터베이스를 SQL Server의 새 인스턴스로 복원합니다.

    데이터베이스가 새 서버로 복원됩니다.

(복제 옵션) 서버 ID 다시 구성 및 데이터베이스 다시 매핑

참고 항목

PrepareClone은 다른 서버의 프로덕션에 이미 있는 데이터베이스 백업을 사용하여 새 Azure DevOps Server 배포를 진행하기 전에 사용하는 것이 좋습니다. 구성 마법사의 사전 프로덕션 업그레이드 및 복제 시나리오에 해당 기능을 통합했으므로 이 명령은 더 이상 필요하지 않습니다.

원래 Azure DevOps Server 인스턴스를 계속 사용하려는 경우 새 애플리케이션 계층 서버에서 다음 단계 집합을 수행합니다. 이러한 단계는 하나 또는 두 배포의 손상 위험을 방지하기 위해 필요합니다. 두 서버가 모두 라이브 상태이면 손상될 수 있으며, 특히 동일한 보고 리소스를 가리키는 경우 손상될 수 있습니다.

  1. 관리자 권한으로 명령 프롬프트 창을 열고 디렉터리를 Drive:%programfiles%\TFS 12.0\Tools로 변경합니다. 명령 프롬프트 창을 열고 다음을 입력합니다.

  2. TFSConfig PrepareClone 명령을 실행하여 예약된 백업 및 보고 리소스에 대한 정보를 제거합니다.

    TFSConfig PrepareClone /SQLInstance:ServerName /DatabaseName:DatabaseName /notificationURL: ApplicationTierURL
    
  3. TFSConfig ChangeServerID 명령을 실행하여 데이터베이스와 연결된 서버 GUID를 변경합니다. GUID는 Azure DevOps Server 배포 내에서 고유해야 합니다.

    TFSConfig ChangeServerID /SQLInstance:ServerName] /DatabaseName:ConfigurationDatabaseName [/ProjectCollectionsOnly] [/ConfigDBOnly] [/usesqlalwayson]
    
  4. TFSConfig RemapDBs 명령을 실행하여 복제된 Azure DevOps Server를 해당 데이터베이스로 리디렉션합니다.

    TFSConfig RemapDBs /DatabaseName:ServerName;DatabaseName /SQLInstances:ServerName1,erverName2 [/AnalysisInstance:ServerName] [/AnalysisDatabaseName:DatabaseName] [/review] [/continue] [/usesqlalwayson]
    

애플리케이션 계층 서버 구성

  1. Azure DevOps Server에 대한 관리 콘솔에서 설치된 기능 구성을 선택하여 구성 센터를 시작합니다.

  2. 애플리케이션 계층 전용 마법사를 시작하고 데이터베이스에서 Azure DevOps Server 데이터베이스를 복원한 새 SQL Server 인스턴스를 지정합니다. 목록에서 Tfs_Configuration 데이터베이스를 선택합니다.

    SQL Server 및 데이터베이스 백업 집합 선택

  3. 마법사의 마지막 페이지를 닫기 전에 "i" 기호를 찾습니다. 나중에 참조할 수 있는 정보를 의미합니다. 마지막 페이지에는 구성 로그의 위치도 포함됩니다.

    모든 문제 및 로그 파일 위치를 확인합니다.

Azure DevOps Server URL 업데이트

  1. 애플리케이션 계층 노드로 이동하여 알림 및 웹 포털 URL을 확인합니다. 이전 배포의 위치를 계속 가리킵니다. 업데이트합니다.

    알림 및 웹 URL이 만료되었습니다.

  2. 새 서버의 이름으로 URL을 업데이트한 후 정보를 검토하여 올바른지 확인합니다.

    서버 URL은 여전히 localhost를 사용합니다.

모든 서비스 계정 업데이트

Azure DevOps Server(TFSService) 및 TFSReports(데이터 원본 계정)에 대한 서비스 계정을 업데이트해야 합니다. 이러한 계정이 변경되지 않은 경우에도 ID 및 계정 형식이 새 서버에 적합한지 확인하기 위해 정보를 업데이트해야 합니다.

  1. 관리자 권한으로 명령 프롬프트 창을 열고 디렉터리를 Drive:\%programfiles%\TFS 12.0\Tools로 변경합니다.

  2. 명령 프롬프트에서 다음 명령을 입력하여 Azure DevOps에 대한 서비스 계정을 추가합니다. 여기서 DatabaseName 은 구성 데이터베이스의 이름입니다(기본적으로 TFS_Configuration).

    TfsConfig 계정 /add /AccountType:ApplicationTier /account: AccountName /SQLInstance: ServerName /DatabaseName: DatabaseName

  3. 명령 프롬프트에서 다음 명령을 입력하여 데이터 원본 계정을 추가합니다.

    TfsConfig 계정 /add /AccountType:ReportingDataSource /account: AccountName /SQLInstance:ServerName /DatabaseName:DatabaseName

    자세한 내용은 계정 명령을 참조하세요.

빌드 서버 업데이트

이제 이동된 Azure DevOps Server 배포를 가리키도록 빌드 서버를 리디렉션해야 합니다.

  1. 각 빌드 서버에서 관리 콘솔을 열고 빌드 서비스를 중지합니다.

  2. 빌드 서비스의 속성에서 통신 속성을 업데이트합니다.

    서비스를 중지한 다음, 변경

Reporting 및 Analysis Services 구성

배포에서 보고서 서버를 사용하는 경우 Azure DevOps Server를 해당 위치로 리디렉션하고, 웨어하우스를 다시 시작하고, Analysis Services용 데이터베이스를 수동으로 다시 빌드해야 합니다. 보고를 사용하지 않는 경우 이 절차를 건너뜁니다.

  1. 보고 노드로 이동합니다. 나열된 보고서 서버 값은 새 값이 아닌 이전 값이므로 편집합니다.

    보고서는 여전히 이전 서버를 가리킵니다.

  2. 세 탭의 값을 모두 변경하여 새 서버를 가리킵니다. 새 배포에서 데이터 원본 계정에 대한 올바른 정보를 제공해야 합니다.

    모든 3개의 탭에서 정보가 올바른지 확인합니다.

  3. 작업 시작을 선택하여 보고를 다시 시작합니다.

  4. 다시 빌드 시작을 선택하여 웨어하우스를 다시 빌드합니다.

사용자, 그룹 및 서비스 계정에 대한 권한 확인

새 하드웨어로 이동한 후 배포에 대한 모든 사용자, 그룹 및 서비스 계정이 각 서버에서 올바르게 작동하는 데 필요한 권한으로 구성되었는지 확인합니다. SQL Server 또는 로컬 컴퓨터의 추가 권한과 같은 일부 사용 권한은 자동으로 마이그레이션할 수 없습니다. 예를 들어 관리 콘솔을 열려면 Azure DevOps 관리자가 애플리케이션 계층 서버의 로컬 관리자 그룹의 구성원이어야 하므로 해당 그룹에 수동으로 추가해야 합니다.

  • 서버에 로그온하고 사용자, 그룹 및 서비스 계정이 작업에 필요한 권한으로 구성되었는지 확인합니다. 프로젝트 그룹 및 팀의 멤버 자격을 수동으로 확인하고 해당 그룹과 팀에 예상한 권한이 있는지 확인합니다.

  • 프로젝트 컬렉션을 찾아 해당 컬렉션의 모든 프로젝트가 예상대로 표시되고 해당 프로젝트의 사용자가 해당 작업 항목에 적절하게 액세스할 수 있는지 확인합니다.

  • 웹 포털을 열고 팀 사이트와 팀이 예상대로 표시되는지 확인합니다.

어떤 그룹과 사용 권한이 예상되는지 잘 모르겠습니까? 자세한 내용은 프로젝트에 사용자 추가, 프로젝트 컬렉션에 대한 관리자 권한 설정, 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>
    

    사용자는 탐색기 탭에서 프로젝트를 검색하여 각 클론의 URL을 볼 수 있습니다.

    에서 리포지토리를 수동으로 복제하기 위한 URL 복사

백업 구성

이전 배포에 대해 예약된 백업이 있었지만 해당 예약된 백업은 이동된 배포를 백업하도록 변경되지 않았습니다. 구성해야 합니다.

  • 관리 콘솔에서 예약된 백업 노드로 이동하여 예약된 백업을 다시 구성하여 새 서버에서 Azure DevOps Server 데이터베이스를 백업합니다. 자세한 내용은 백업 일정 및 계획 만들기를 참조하세요.

질문 & 답변

Q: 물리적 서버가 아닌 도메인을 변경하려고 합니다. 이것은 가능한가요?

A: 예. 이를 환경 기반 이동이라고 하며 단계는 여기에서 찾을 수 있습니다. 환경 기반 이동을 하드웨어 기반 이동과 결합해서는 안 됩니다. 먼저 하드웨어 이동을 완료한 다음 환경을 변경합니다.

Q: 새 하드웨어로 이동한 후에도 이전 Azure DevOps Server를 계속 사용하고 싶다는 것을 깨달았습니다. 이것은 가능한가요?

A: 예, 하지만 즉시 추가 단계를 수행하는 것이 매우 중요합니다. 이동 또는 복제 단계의 일부로 이러한 단계를 수행하는 것이 가장 좋습니다. 이는 하나 또는 두 배포의 손상 위험을 방지하는 가장 좋은 방법입니다. 두 서버가 모두 라이브 상태이면 손상될 수 있으며, 특히 동일한 보고 리소스를 가리키는 경우 손상될 수 있습니다.

이 문제를 해결하려면 다음을 수행합니다.

  1. 새 서버에서 TFSConfig PrepareClone 명령 실행

  2. 새 서버에서 TFSConfig ChangeServerID 명령 실행

  3. 새 서버에서 TFSConfig RemapDBs 명령 실행

Q: Project Server와 통합되는 배포가 있습니다. 이동한 Azure DevOps Server를 사용하려면 추가 단계를 수행해야 하나요?

A: 예, 하드웨어 이동을 완료한 후에는 /tfs, /force/pwa 옵션과 함께 TFSAdmin ProjectServer /RegisterPWA 명령을 사용하여 Project Server에 Azure DevOps Server를 다시 등록해야 합니다. Project Server 와 Azure DevOps Server 통합에 대한 자세한 내용은 여기를 참조하세요.