Share via


자습서: 고가용성 및 재해 복구를 사용하여 WebSphere 애플리케이션 서버를 Azure Virtual Machines로 마이그레이션

이 자습서에서는 Azure VM(Virtual Machines)의 WebSphere 애플리케이션 서버를 사용하여 Java용 HA/DR(고가용성 및 재해 복구)을 구현하는 간단하고 효과적인 방법을 보여 줍니다. 이 솔루션은 WebSphere 애플리케이션 서버에서 실행되는 간단한 데이터베이스 기반 Jakarta EE 애플리케이션을 사용하여 RTO(복구 시간 목표) 및 RPO(복구 지점 목표)를 달성하는 방법을 보여 줍니다. HA/DR은 여러 가지 가능한 솔루션을 갖춘 복잡한 주제입니다. 최상의 솔루션은 고유한 요구 사항에 따라 달라집니다. HA/DR을 구현하는 다른 방법은 이 문서의 끝에 있는 리소스를 참조하세요.

이 자습서에서는 다음을 하는 방법을 알아볼 수 있습니다.

  • Azure 최적화 모범 사례를 사용하여 고가용성 및 재해 복구를 달성합니다.
  • 쌍을 이루는 지역에서 Microsoft Azure SQL Database 장애 조치(failover) 그룹을 설정합니다.
  • Azure VM에서 기본 WebSphere 클러스터를 설정합니다.
  • Azure Site Recovery를 사용하여 클러스터에 대한 재해 복구를 설정합니다.
  • Azure Traffic Manager를 설정합니다.
  • 기본에서 보조로 장애 조치(failover)를 테스트합니다.

다음 다이어그램에서는 빌드하는 아키텍처를 보여 줍니다.

고가용성 및 재해 복구를 사용하는 Azure VM의 WebSphere 솔루션 아키텍처 다이어그램.

Azure Traffic Manager는 지역 상태를 검사 그에 따라 트래픽을 애플리케이션 계층으로 라우팅합니다. 주 지역에는 WebSphere 클러스터의 전체 배포가 있습니다. 주 지역이 Azure Site Recovery에 의해 보호된 후 장애 조치(failover) 중에 보조 지역을 복원할 수 있습니다. 결과적으로 주 지역은 사용자의 네트워크 요청을 적극적으로 서비스하는 반면 보조 지역은 수동적이며 주 지역에서 서비스 중단이 발생하는 경우에만 트래픽을 수신하도록 활성화됩니다.

Azure Traffic Manager는 조건부 라우팅을 구현하기 위해 IBM HTTP Server에 배포된 앱의 상태를 검색합니다. 애플리케이션 계층의 지역 장애 조치(failover) RTO는 주 클러스터를 종료하고, 보조 클러스터를 복원하고, VM을 시작하고, 보조 WebSphere 클러스터를 실행하는 시간에 따라 달라집니다. RPO는 Azure Site Recovery 및 Azure SQL Database의 복제본(replica)tion 정책에 따라 달라집니다. 이 종속성은 클러스터 데이터가 VM의 로컬 스토리지에 저장되고 복제본(replica) 애플리케이션 데이터가 유지되고 Azure SQL Database 장애 조치(failover) 그룹에 복제본(replica) 있기 때문입니다.

위의 다이어그램은 HA/DR 아키텍처를 구성하는 두 지역으로 주 지역과 보조 지역을 보여 줍니다. 이러한 지역은 Azure 쌍을 이루는 지역이어야 합니다. 쌍을 이루는 지역에 대한 자세한 내용은 Azure 지역 간 복제본(replica)tion을 참조하세요. 이 문서에서는 미국 동부와 미국 서부를 두 지역으로 사용하지만 시나리오에 적합한 쌍을 이루는 지역일 수 있습니다. 지역 페어링 목록은 Azure 지역 간 복제본(replica) Azure 쌍을 이루는 지역 섹션을 참조하세요.

데이터베이스 계층은 주 서버와 보조 서버가 있는 Azure SQL Database 장애 조치(failover) 그룹으로 구성됩니다. 읽기/쓰기 수신기 엔드포인트는 항상 주 서버를 가리키며 각 지역의 WebSphere 클러스터에 연결됩니다. 지역 장애 조치(failover)는 그룹의 모든 보조 데이터베이스를 주 역할로 전환합니다. Azure SQL Database의 지역 장애 조치(failover) RPO 및 RTO는 Azure SQL Database를 사용한 비즈니스 연속성 개요를 참조하세요.

이 자습서는 이러한 서비스의 HA 기능을 사용하므로 Azure Site Recovery 및 Azure SQL Database 서비스를 사용하여 작성되었습니다. 다른 데이터베이스 선택도 가능하지만 선택한 데이터베이스의 HA 기능을 고려해야 합니다.

필수 조건

쌍을 이루는 지역에서 Azure SQL Database 장애 조치(failover) 그룹 설정

이 섹션에서는 WebSphere 클러스터 및 앱과 함께 사용할 쌍을 이루는 지역에 Azure SQL Database 장애 조치(failover) 그룹을 만듭니다. 이후 섹션에서는 세션 데이터를 이 데이터베이스에 저장하도록 WebSphere를 구성합니다. 이 연습에서는 세션 지속성을 위한 테이블 만들기를 참조합니다.

먼저 빠른 시작: 단일 데이터베이스 만들기 - Azure SQL Database의 Azure Portal 단계에 따라 기본 Azure SQL Database를 만듭니다. "리소스 정리" 섹션을 포함하지만 포함하지 않는 단계를 수행합니다. 문서를 진행할 때 다음 지침을 사용한 다음, Azure SQL Database를 만들고 구성한 후 이 문서로 돌아갑니다.

  1. 단일 데이터베이스 만들기 섹션에 도달하면 다음 단계를 사용합니다.

    1. 새 리소스 그룹을 만들기 위한 4단계에서 리소스 그룹 이름 값(예myResourceGroup: )을 따로 저장합니다.
    2. 데이터베이스 이름에 대한 5단계에서 데이터베이스 이름 값(예mySampleDatabase: .)을 따로 저장합니다.
    3. 서버를 만들기 위한 6단계에서 다음 단계를 사용합니다.
      1. 고유한 서버 이름(예: sqlserverprimary-mjg022624.)을 입력합니다.
      2. 위치의 경우 (미국) 미국 동부를 선택합니다.
      3. 인증 방법의 경우 SQL 인증 사용을 선택합니다.
      4. 서버 관리자 로그인 값(예azureuser: .)을 따로 저장합니다.
      5. 암호 값을 따로 저장합니다.
    4. 8단계에서 워크로드 환경의 경우 개발을 선택합니다. 설명을 살펴보고 워크로드에 대한 다른 옵션을 고려합니다.
    5. 11단계에서 Backup 스토리지 중복성에 대해 로컬 중복 백업 스토리지를 선택합니다. 백업에 대한 다른 옵션을 고려합니다. 자세한 내용은 Azure SQL Database에서 자동화된 백업의 Backup 스토리지 중복성 섹션을 참조하세요.
    6. 14단계의 방화벽 규칙 구성에서 Azure 서비스 및 리소스가 이 서버에 액세스하도록 허용하려면 [예]를 선택합니다.
  2. 데이터베이스 쿼리 섹션에 도달하면 다음 단계를 사용합니다.

    1. 3단계에서 로그인할 SQL 인증 서버 관리자 로그인 정보를 입력합니다.

      참고 항목

      IP 주소가 'xx.xx.xx.xx.xx'인 클라이언트와 유사한 오류 메시지와 함께 로그인이 실패하면 오류 메시지 끝에 있는 서버<에서> 허용 목록 IP xx.xx.xx.xx.xx를 선택합니다. 서버 방화벽 규칙 업데이트가 완료될 때까지 기다린 다음 확인을 다시 선택합니다.

    2. 5단계에서 샘플 쿼리를 실행한 후 편집기를 지우고 다음 쿼리를 입력한 다음, 실행을 다시 선택합니다.

      CREATE TABLE sessions (
         ID VARCHAR(128) NOT NULL,
         PROPID VARCHAR(128) NOT NULL,
         APPNAME VARCHAR(128) NOT NULL,
         LISTENERCNT SMALLINT,
         LASTACCESS BIGINT,
         CREATIONTIME BIGINT,
         MAXINACTIVETIME INT,
         USERNAME VARCHAR(256),
         SMALL VARBINARY(MAX),
         MEDIUM VARCHAR(MAX),
         LARGE VARBINARY(MAX)
      );
      

      성공적으로 실행되면 쿼리 성공: 영향을 받은 행 수: 0 메시지가 표시됩니다.

      데이터베이스 테이블 sessions 은 WebSphere 앱에 대한 세션 데이터를 저장하는 데 사용됩니다. 트랜잭션 로그를 포함한 WebSphere 클러스터 데이터는 클러스터가 배포된 VM의 로컬 스토리지에 유지됩니다.

그런 다음, Azure SQL Database에 대한 장애 조치(failover) 그룹 구성의 Azure Portal 단계에 따라 Azure SQL Database 장애 조치(failover) 그룹을 만듭니다. 장애 조치(failover) 그룹 만들기 및 테스트 계획된 장애조치 섹션만 있으면 됩니다. 문서를 진행하면서 다음 단계를 수행한 다음, Azure SQL Database 장애 조치(failover) 그룹을 만들고 구성한 후 이 문서로 돌아갑니다.

  1. 장애 조치(failover) 그룹 만들기 섹션에서 다음 단계를 사용합니다.

    1. 장애 조치(failover) 그룹을 만들기 위한 5단계에서 고유한 장애 조치(failover) 그룹 이름(예 failovergroup-mjg022624: )을 입력하고 저장합니다.
    2. 서버를 구성하기 위한 5단계에서 새 보조 서버를 만드는 옵션을 선택한 다음, 다음 단계를 사용합니다.
      1. 고유한 서버 이름(예: .) sqlserversecondary-mjg022624을 입력합니다.
      2. 주 서버와 동일한 서버 관리자 및 암호를 입력합니다.
      3. 위치의 경우 (미국) 미국 서부를 선택합니다.
      4. Azure 서비스에서 서버에 액세스하도록 허용이 선택되어 있는지 확인합니다.
    3. 그룹 내의 데이터베이스를 구성하기 위한 5단계에서 주 서버에서 만든 데이터베이스(예: mySampleDatabase)를 선택합니다.
  2. 테스트 계획된 장애조치 섹션의 모든 단계를 완료한 후 장애 조치(failover) 그룹 페이지를 열어 두고 나중에 WebSphere 클러스터의 장애 조치(failover) 테스트에 사용합니다.

Azure VM에서 기본 WebSphere 클러스터 설정

이 섹션에서는 Azure VM의 IBM WebSphere 애플리케이션 서버 클러스터를 사용하여 Azure VM에 기본 WebSphere 클러스터를 만듭니다 . 보조 클러스터는 나중에 Azure Site Recovery를 사용하여 장애 조치(failover) 중에 주 클러스터에서 복원됩니다.

기본 WebSphere 클러스터 배포

먼저 브라우저에서 Azure VM 제품에서 IBM WebSphere 애플리케이션 서버 클러스터를 열고 만들기를 선택합니다. 제품의 기본 창이 표시됩니다.

다음 단계를 사용하여 기본 사항 창을 작성 합니다 .

  1. 구독대해 표시된 값이 필수 구성 요소 섹션에 나열된 역할이 있는 값과 동일한지 확인합니다.
  2. 빈 리소스 그룹에 제품을 배포해야 합니다. 리소스 그룹 필드에서 새로 만들기를 선택하고 리소스 그룹에 대한 고유한 값을 입력합니다(예: was-cluster-eastus-mjg022624).
  3. 인스턴스 세부 정보에서 지역에 대해 미국 동부를 선택합니다.
  4. 기존 WebSphere 자격 또는 평가 라이선스를 사용하여 배포하려면 이 자습서에 대한 평가를 선택합니다. 자격 증명을 선택하고 IBMid 자격 증명을 제공할 수도 있습니다.
  5. IBM 사용권 계약을 읽고 동의합니다.
  6. 다른 필드의 기본값을 그대로 둡니다.
  7. 다음을 선택하여 클러스터 구성 창으로 이동합니다.

Azure VM 기본 사항 창의 IBM WebSphere 애플리케이션 서버 클러스터를 보여 주는 Azure Portal의 스크린샷.

다음 단계를 사용하여 클러스터 구성 창을 작성합니다.

  1. VM 관리자용 암호의 경우 암호를 입력합니다.
  2. WebSphere 관리자용 암호의 경우 암호를 입력합니다. WebSphere 관리자의 사용자 이름과 암호를 따로 저장합니다.
  3. 다른 필드의 기본값을 그대로 둡니다.
  4. 다음을 선택하여 부하 분산 장치 창으로 이동합니다.

Azure VM 클러스터 구성 창에서 IBM WebSphere 애플리케이션 서버 클러스터를 보여 주는 Azure Portal의 스크린샷.

다음 단계를 사용하여 부하 분산 장치 창을 작성합니다.

  1. VM 관리자용 암호의 경우 암호를 입력합니다.
  2. IBM HTTP Server 관리자용 암호의 경우 암호를 제공합니다.
  3. 다른 필드의 기본값을 그대로 둡니다.
  4. 다음을 선택하여 네트워킹 창으로 이동합니다.

Azure VM 부하 분산 장치 창의 IBM WebSphere 애플리케이션 서버 클러스터를 보여 주는 Azure Portal의 스크린샷.

네트워킹 창에 기본값으로 미리 채워진 모든 필드가 표시됩니다. 다음을 선택하여 데이터베이스 창으로 이동합니다.

Azure VM 네트워킹 창에서 IBM WebSphere 애플리케이션 서버 클러스터를 보여 주는 Azure Portal의 스크린샷

다음 단계에서는 데이터베이스 창을 채우는 방법을 보여줍니다.

  1. 데이터베이스에 커넥트 경우 예를 선택합니다.
  2. 데이터베이스 유형 선택에서 Microsoft SQL Server를 선택합니다.
  3. JNDI 이름에 jdbc/WebSphereCafeDB를 입력합니다.
  4. 데이터 원본 연결 문자열(jdbc:sqlserver://<host>:<port>; database=<database>). 자리 표시자를 Azure SQL Database의 장애 조치(failover) 그룹에 대한 이전 섹션에 저장한 값으로 바꿉니다. 예를 들면 다음과 같습니다jdbc:sqlserver://failovergroup-mjg022624.database.windows.net:1433;database=mySampleDatabase.
  5. 데이터베이스 사용자 이름의 경우 이전 섹션에서 저장한 서버 관리자 로그인 이름 및 장애 조치(failover) 그룹 이름을 입력합니다(예azureuser@failovergroup-mjg022624: .).

    참고 항목

    주 또는 백업 데이터베이스의 서버 호스트 이름 및 사용자 이름 대신 장애 조치(failover) 그룹에 올바른 데이터베이스 서버 호스트 이름 및 데이터베이스 사용자 이름을 사용하도록 주의해야 합니다. 장애 조치(failover) 그룹의 값을 사용하면 실제로 WebSphere가 장애 조치(failover) 그룹과 통신하도록 합니다. 그러나 WebSphere에 관한 한 ss는 일반 데이터베이스 연결일 뿐입니다.

  6. 데이터베이스 암호에 대해 이전에 저장한 서버 관리자 로그인 암호를 입력합니다. 암호 확인에 대해 동일한 값을 입력합니다.
  7. 다른 필드의 기본값을 그대로 둡니다.
  8. 검토 + 만들기를 선택합니다.
  9. 최종 유효성 검사 실행이 완료될 때까지 기다린 다음 만들기를 선택합니다.

Azure VM 데이터베이스 창의 IBM WebSphere 애플리케이션 서버 클러스터를 보여 주는 Azure Portal의 스크린샷

잠시 후 배포가 진행 중인 배포 페이지가 표시됩니다.

참고 항목

최종 유효성 검사를 실행하는 동안 문제가 표시되는 경우 문제를 해결한 후 다시 시도하세요.

선택한 지역의 네트워크 조건 및 기타 활동에 따라 배포를 완료하는 데 최대 25분이 걸릴 수 있습니다. 그런 다음 배포가 완료된 텍스트가 배포 페이지에 표시됩니다.

클러스터 배포 확인

클러스터에 IBM HTTP Server(IHS) 및 WebSphere Deployment Manager(Dmgr)를 배포했습니다. IHS는 클러스터의 모든 애플리케이션 서버에 대한 부하 분산 장치 역할을 합니다. Dmgr은 클러스터 구성을 위한 웹 콘솔을 제공합니다.

다음 단계를 사용하여 다음 단계로 이동하기 전에 IHS 및 Dmgr 콘솔이 작동하는지 확인합니다.

  1. 배포 페이지로 돌아가서 출력을 선택합니다.

  2. ihsConsole 속성의 값을 복사합니다. 새 브라우저 탭에서 해당 URL을 엽니다. 이 예제에서는 IHS에 사용하지 https 않습니다. 오류 메시지 없이 IHS의 시작 페이지가 표시됩니다. 그렇지 않은 경우 계속하기 전에 문제를 해결하고 해결해야 합니다. 콘솔을 열어 두고 나중에 클러스터의 앱 배포를 확인하는 데 사용합니다.

    IBM HTTP Server 시작 화면의 스크린샷.

  3. adminSecuredConsole 속성 값을 복사하고 저장합니다. 새 브라우저 탭에서 엽니다. 자체 서명된 TLS 인증서에 대한 브라우저 경고를 적용합니다. 자체 서명된 TLS 인증서를 사용하여 프로덕션으로 이동하지 마세요.

    WebSphere 통합 솔루션 콘솔로그인 페이지가 표시됩니다. 이전에 저장한 WebSphere 관리자의 사용자 이름과 암호를 사용하여 콘솔에 로그인합니다. 로그인할 수 없는 경우 계속하기 전에 문제를 해결하고 해결해야 합니다. 콘솔을 열어 두고 나중에 WebSphere 클러스터의 추가 구성에 사용합니다.

다음 단계를 사용하여 IHS의 공용 IP 주소 이름을 가져옵니다. 나중에 Azure Traffic Manager를 설정할 때 사용합니다.

  1. 클러스터가 배포된 리소스 그룹을 엽니다. 예를 들어 개요를 선택하여 배포 페이지의 개요 창으로 다시 전환한 다음 리소스 그룹으로 이동을 선택합니다.
  2. 리소스 테이블에서 형식 열을 찾습니다. 리소스 유형을 기준으로 정렬하려면 선택합니다.
  3. 접두사로 접두사로 ihs지정된 공용 IP 주소 리소스를 찾은 다음 해당 이름을 복사하여 저장합니다.

클러스터 구성

먼저 모든 구성을 모든 애플리케이션 서버에 자동으로 동기화할 수 있도록 노드와 변경 내용 동기화 옵션을 사용하도록 설정하려면 다음 단계를 사용합니다.

  1. WebSphere 통합 솔루션 콘솔로 다시 전환하고 로그아웃한 경우 다시 로그인합니다.
  2. 탐색 창에서 시스템 관리>콘솔 기본 설정을 선택합니다.
  3. 콘솔 기본 설정 창에서 노드와 변경 내용 동기화를 선택한 다음 적용을 선택합니다. 기본 설정이 변경되었다는 메시지가 표시됩니다.

그런 다음, 다음 단계를 사용하여 모든 애플리케이션 서버에 대해 데이터베이스 분산 세션을 구성합니다 .

  1. 탐색 창에서 서버>서버 유형>WebSphere 애플리케이션 서버를 선택합니다.
  2. 애플리케이션 서버 창에 3개의 애플리케이션 서버가 나열됩니다. 각 애플리케이션 서버에 대해 다음 지침을 사용하여 데이터베이스 분산 세션을 구성합니다.
    1. 다음 리소스를 관리할 수 있는 텍스트 아래의 표에서 애플리케이션 서버의 하이퍼링크를 선택합니다. 이 하이퍼링크는 로 MyCluster시작합니다.
    2. 컨테이너 설정 섹션에서 세션 관리를 선택합니다.
    3. 추가 속성 섹션에서 분산 환경 설정을 선택합니다.
    4. 분산 세션의 경우 데이터베이스를 선택합니다(웹 컨테이너에만 지원됨).
    5. 데이터베이스를 선택하고 다음 단계를 사용합니다.
      1. Datasource JNDI 이름의 경우 jdbc/WebSphereCafeDB를 입력합니다.
      2. 사용자 ID의 경우 이전 섹션에서 저장한 서버 관리자 로그인 이름과 장애 조치(failover) 그룹 이름을 입력합니다(예: azureuser@failovergroup-mjg022624).
      3. 이전에 암호용으로 저장한 Azure SQL Server 관리자 로그인 암호를 입력합니다.
      4. 테이블 공간 이름의 경우 세션을 입력합니다.
      5. 여러 행 스키마 사용을 선택합니다.
      6. 확인을 선택합니다. 분산 환경 설정 창으로 돌아갑니다.
    6. 추가 속성 섹션에서 사용자 지정 튜닝 매개 변수를 선택합니다.
    7. 튜닝 수준에 대해 낮음(장애 조치(failover) 최적화)을 선택합니다.
    8. 확인을 선택합니다.
    9. 메시지에서 저장을 선택합니다. 완료될 때까지 기다립니다.
    10. 위쪽 이동 경로 표시줄에서 애플리케이션 서버를 선택합니다. 애플리케이션 서버 창으로 돌아갑니다.
  3. 탐색 창에서 서버>클러스터>WebSphere 애플리케이션 서버 클러스터를 선택합니다.
  4. WebSphere 애플리케이션 서버 클러스터 창에 나열된 클러스터 MyCluster 가 표시됩니다. MyCluster 옆에 있는 검사 상자를 선택합니다.
  5. Ripplestart를 선택합니다.
  6. 클러스터가 다시 시작될 때까지 기다립니다. 상태 아이콘을 선택하고 새 창에 시작됨이 표시되지 않으면 콘솔로 다시 전환하고 잠시 후 웹 페이지를 새로 고칠 수 있습니다. 시작이 표시 될 때까지 작업을 반복합니다. 시작됨 상태에 도달하기 전에 부분 시작이 표시될 수 있습니다.

콘솔을 열어 두고 나중에 앱 배포에 사용합니다.

샘플 앱 배포

이 섹션에서는 나중에 재해 복구 장애 조치(failover) 테스트를 위해 WebSphere 클러스터에서 샘플 CRUD Java/Jakarta EE 애플리케이션을 배포하고 실행하는 방법을 보여 줍니다.

데이터 원본 jdbc/WebSphereCafeDB 을 사용하여 세션 데이터를 이전에 저장하도록 애플리케이션 서버를 구성했습니다. 이를 통해 WebSphere 애플리케이션 서버 클러스터 간에 장애 조치(failover) 및 부하 분산이 가능합니다. 또한 샘플 앱은 동일한 데이터 원본jdbc/WebSphereCafeDB에 애플리케이션 데이터를 coffee 유지하도록 지속성 스키마를 구성합니다.

먼저 다음 명령을 사용하여 샘플을 다운로드, 빌드 및 패키지합니다.

git clone https://github.com/Azure-Samples/websphere-cafe
cd websphere-cafe
git checkout 20240326
mvn clean package

상태에 있는 것에 Detached HEAD 대한 메시지가 표시되면 이 메시지는 무시해도 안전합니다.

패키지는 성공적으로 생성되고 부모 경로에서 로컬 클론>으로/websphere-café/websphere-café-application/target/websphere-café.ear에 위치<해야 합니다. 이 패키지가 표시되지 않으면 문제를 해결한 후 계속 진행합니다.

그런 다음, 다음 단계를 사용하여 샘플 앱을 클러스터에 배포합니다.

  1. WebSphere 통합 솔루션 콘솔로 다시 전환하고 로그아웃한 경우 다시 로그인합니다.
  2. 탐색 창에서 애플리케이션 애플리케이션>유형>WebSphere 엔터프라이즈 애플리케이션을 선택합니다.
  3. 엔터프라이즈 애플리케이션 창에서 파일 선택 설치>를 선택합니다. 그런 다음 부모 경로에서 local-clone>/websphere-café/websphere-café-application/target/websphere-café.ear에 있는< 패키지를 찾아 열기를 선택합니다. 다음 다음>>을 선택합니다.
  4. 서버로 모듈 매핑 창에서 Ctrl 키를 누르고 클러스터 및 서버 아래에 나열된 모든 항목을 선택합니다. websphere-café.war 옆에 있는 검사 상자를 선택합니다. 적용을 선택합니다. 마침 단추가 표시될 때까지 다음선택합니다.
  5. 저장 완료>를 선택한 다음 완료될 때까지 기다립니다. 확인을 선택합니다.
  6. 설치된 애플리케이션websphere-cafe을 선택한 다음 시작을 선택합니다. 애플리케이션이 성공적으로 시작되었음을 나타내는 메시지가 표시될 때까지 기다립니다. 성공한 메시지를 볼 수 없는 경우 계속하기 전에 문제를 해결하고 해결해야 합니다.

이제 다음 단계를 사용하여 앱이 예상대로 실행되고 있는지 확인합니다.

  1. IHS 콘솔로 다시 전환합니다. 배포된 앱의 컨텍스트 루트/websphere-cafe/(예http://ihs70685e.eastus.cloudapp.azure.com/websphere-cafe/: 주소 표시줄)를 추가한 다음 Enter 키를 누릅니다. 샘플 앱의 시작 페이지가 표시됩니다.

  2. 이름 및 가격으로 새 커피를 만듭니다(예: 가격이 $10Coffee 1). 이 커피는 데이터베이스의 애플리케이션 데이터 테이블과 세션 테이블 모두에 유지됩니다. 표시되는 UI는 다음 스크린샷과 유사해야 합니다.

    샘플 애플리케이션 UI의 스크린샷.

UI가 비슷해 보이지 않는 경우 문제를 해결하고 계속 진행합니다.

Azure Site Recovery를 사용하여 클러스터에 대한 재해 복구 설정

이 섹션에서는 자습서: Azure VM에 대한 재해 복구 설정의 단계에 따라 Azure Site Recovery를 사용하여 주 클러스터에서 Azure VM에 대한 재해 복구를 설정합니다. Recovery Services 자격 증명 모음 만들기 및 복제본(replica) 설정 설정 섹션만 있으면 됩니다. 문서를 진행할 때 다음 단계에 주의한 다음, 기본 클러스터가 보호된 후 이 문서로 돌아갑니다.

  1. Recovery Services 자격 증명 모음 만들기 섹션에서 다음 단계를 사용합니다.

    1. 리소스 그룹에 대한 5단계에서 구독에 고유한 이름을 가진 새 리소스 그룹을 만듭니다(예: was-cluster-westus-mjg022624).

    2. 자격 증명 모음 이름에 대한 6단계에서 자격 증명 모음 이름(예: recovery-service-vault-westus-mjg022624>)을 제공합니다.

    3. 지역에 대한 7단계에서 미국 서부를 선택합니다.

    4. 8단계에서 검토 + 만들기를 선택하기 전에 다음: 중복성을 선택합니다. 중복 창에서 백업 스토리지 중복에 대한 지역 중복선택하고 지역 간 복원에 사용하도록 설정합니다.

      참고 항목

      중복 창에서 백업 스토리지 중복성에 대한 지역 중복선택하고 지역 간 복원사용하도록 설정 해야 합니다. 그렇지 않으면 주 클러스터의 스토리지를 보조 지역에 복제본(replica) 수 없습니다.

    5. Site Recovery 사용 섹션 의 단계에 따라 Site Recovery를 사용하도록 설정합니다.

  2. 복제본(replica) 설정 섹션에 도달하면 다음 단계를 사용합니다.

    1. 원본 설정 선택 섹션에서 다음 단계를 사용합니다.
      1. 지역에 대해 미국 동부를 선택합니다.

      2. 리소스 그룹의 경우 주 클러스터가 배포되는 리소스를 선택합니다(예: )was-cluster-eastus-mjg022624.

        참고 항목

        원하는 리소스 그룹이 나열되지 않은 경우 먼저 해당 지역에 대해 미국 서부를 선택한 다음 미국 동부로 다시 전환할 수 있습니다.

      3. 다른 필드의 기본값을 그대로 둡니다. 다음을 선택합니다.

    2. 섹션에서 VM을 선택하고 가상 머신에 대해 나열된 5개의 VM을 모두 선택한 다음, 다음을 선택합니다.
    3. 복제본(replica) 설정 검토 섹션에서 다음 단계를 사용합니다.
      1. 대상 위치의 경우 미국 서부를 선택합니다.
      2. 대상 리소스 그룹의 경우 서비스 복구 자격 증명 모음이 배포되는 리소스 그룹을 선택합니다(예: was-cluster-westus-mjg022624).
      3. 주 지역의 가상 네트워크와 매핑되는 새 장애 조치(failover) 서브넷을 적어둡니다.
      4. 다른 필드의 기본값을 그대로 둡니다.
      5. 다음을 선택합니다.
    4. 관리 섹션에서 다음 단계를 사용합니다.
      1. 복제 정책의 경우 기본 정책 24시간 보존 정책을 사용합니다. 비즈니스에 대한 새 정책을 만들 수도 있습니다.
      2. 다른 필드의 기본값을 그대로 둡니다.
      3. 다음을 선택합니다.
    5. 검토 섹션에서 다음 단계를 사용합니다.
      1. 복제본(replica) 사용을 선택한 후 Azure 리소스를 만드는 메시지를 확인합니다. 이 블레이드를 닫지 마세요. 페이지 아래쪽에 표시됩니다. 아무 작업도 수행하지 않으며 창이 자동으로 닫히기 전까지 기다립니다. Site Recovery 페이지로 리디렉션됩니다.

      2. 보호된 항목에서 복제된 항목을 선택합니다. 처음에는 복제본(replica) 진행 중이므로 항목이 나열되지 않습니다. 복제본(replica) 완료하는 데 약 1시간이 걸립니다. 다음 예제 스크린샷과 같이 모든 VM이 보호된 상태에 있음을 확인할 때까지 페이지를 주기적으로 새로 고칩니다.

        복제본(replica) 및 보호된 VM을 보여 주는 Azure Portal의 스크린샷

다음으로, 함께 장애 조치(failover)할 수 있도록 모든 복제본(replica)ted 항목을 포함하는 복구 계획을 만듭니다. 다음 사용자 지정과 함께 복구 계획 만들기의 지침을 사용합니다.

  1. 2단계에서 계획의 이름(예 recovery-plan-mjg022624: .)을 입력합니다.
  2. 3단계에서 원본에 대해 미국 동부를 선택하고 대상에 대해 미국 서부를 선택합니다.
  3. 항목 선택 4단계에서 이 자습서에서 보호된 VM 5개를 모두 선택합니다.

다음으로 복구 계획을 만듭니다. 페이지를 열어 두면 나중에 장애 조치(failover) 테스트에 사용할 수 있습니다.

보조 지역에 대한 추가 네트워크 구성

또한 장애 조치(failover) 이벤트에서 보조 지역에 대한 외부 액세스를 사용하도록 설정하고 보호하려면 추가 네트워크 구성이 필요합니다. 이 구성에 대해 다음 단계를 사용합니다.

  1. 빠른 시작의 지침 에 따라 보조 지역에서 Dmgr에 대한 공용 IP 주소를 만듭니다. 다음 사용자 지정을 사용하여 Azure Portal을 사용하여 공용 IP 주소를 만듭니다.

    1. 리소스 그룹의 경우 서비스 복구 자격 증명 모음이 배포되는 리소스 그룹(예: was-cluster-westus-mjg022624)을 선택합니다.
    2. 지역의 경우 (미국) 미국 서부를 선택합니다.
    3. 이름값을 입력합니다(예: .)dmgr-public-ip-westus-mjg022624.
    4. DNS 이름 레이블의 경우 고유한 값(예dmgrmjg022624: .)을 입력합니다.
  2. 다음 사용자 지정을 사용하여 동일한 가이드에 따라 보조 지역에서 IHS에 대한 또 다른 공용 IP 주소를 만듭니다.

    1. 리소스 그룹의 경우 서비스 복구 자격 증명 모음이 배포되는 리소스 그룹(예: was-cluster-westus-mjg022624)을 선택합니다.
    2. 지역의 경우 (미국) 미국 서부를 선택합니다.
    3. 이름값을 입력합니다(예: .)ihs-public-ip-westus-mjg022624. 기록하세요.
    4. DNS 이름 레이블의 경우 고유한 값(예ihsmjg022624: .)을 입력합니다.
  3. 다음 사용자 지정을 사용하여 네트워크 보안 그룹 만들기, 변경 또는 삭제의 네트워크 보안 그룹 만들기 섹션에 있는 지침에 따라 보조 지역에 네트워크 보안 그룹을 만듭니다.

    1. 리소스 그룹의 경우 서비스 복구 자격 증명 모음이 배포되는 리소스 그룹(예: was-cluster-westus-mjg022624)을 선택합니다.
    2. 이름값을 입력합니다(예: .)nsg-westus-mjg022624.
    3. 지역으로 미국 서부를 선택합니다.
  4. 다음 사용자 지정을 사용하여 동일한 문서의 보안 규칙 만들기 섹션에 있는 지침에 따라 네트워크 보안 그룹에 대한 인바운드 보안 규칙을 만듭니다.

    1. 2단계에서 만든 네트워크 보안 그룹(예: nsg-westus-mjg022624)을 선택합니다.
    2. 3단계에서 인바운드 보안 규칙을 선택합니다.
    3. 4단계에서 다음 설정을 사용자 지정합니다.
      1. 대상 포트 범위의 경우 9060,9080,9043,9443,80을 입력합니다.
      2. 프로토콜의 경우 TCP를 선택합니다.
      3. 이름ALLOW_HTTP_ACCESS 입력합니다.
  5. 연결의 지침 에 따라 네트워크 보안 그룹을 서브넷과 연결하거나 동일한 문서의 서브넷 섹션과 네트워크 보안 그룹을 분리하고 다음 사용자 지정을 사용합니다.

    1. 2단계에서 만든 네트워크 보안 그룹(예: nsg-westus-mjg022624)을 선택합니다.
    2. 연결을 선택하여 이전에 적어 두었던 장애 조치(failover) 서브넷에 네트워크 보안 그룹을 연결합니다.

Azure Traffic Manager 설정

이 섹션에서는 전역 Azure 지역에 걸쳐 공용 애플리케이션에 트래픽을 배포하기 위한 Azure Traffic Manager를 만듭니다. 기본 엔드포인트는 주 지역에 있는 IHS의 공용 IP 주소를 가리킵니다. 보조 엔드포인트는 보조 지역에 있는 IHS의 공용 IP 주소를 가리킵니다.

빠른 시작의 지침 에 따라 Azure Traffic Manager 프로필을 만듭니다. Azure Portal을 사용하여 Traffic Manager 프로필을 만듭니다. Traffic Manager 프로필을만들고 Traffic Manager 엔드포인트를 추가하기만 하면 됩니다. App Service 리소스를 만들도록 지시되는 섹션을 건너뛰어야 합니다. 다음 단계를 사용하여 이러한 섹션을 진행한 다음, Azure Traffic Manager를 만들고 구성한 후 이 문서로 돌아갑니다.

  1. Traffic Manager 프로필 만들기 섹션의 2단계에서 Traffic Manager 프로필 만들기에 대해 다음 단계를 사용합니다.

    1. 이름에 대한 고유한 Traffic Manager 프로필 이름을 따로 저장합니다(예: .)tmprofile-mjg022624.
    2. 리소스 그룹의 새 리소스 그룹 이름(예myResourceGroupTM1: .)을 따로 저장합니다.
  2. Traffic Manager 엔드포인트 추가 섹션 도달하면 다음 단계를 사용합니다.

    1. 2 단계에서 Traffic Manager 프로필을 연 후 구성 페이지에서 다음 단계를 사용합니다.
      1. DNS TTL(Time to Live)의 경우 10을 입력합니다.
      2. 엔드포인트 모니터 설정에서 경로에 대해 배포된 샘플 앱의 컨텍스트 루트인 /websphere-café/를 입력합니다.
      3. 빠른 엔드포인트 장애 조치(failover) 설정에서 다음 값을 사용합니다.
        • 내부 검색의 경우 10을 선택합니다.
        • 허용되는 오류 수의 경우 3을 입력합니다.
        • 프로브 시간 제한의 경우 5를 사용합니다.
      4. 저장을 선택합니다. 완료될 때까지 기다립니다.
    2. 기본 엔드포인트 myPrimaryEndpoint를 추가하기 위한 4단계에서 다음 단계를 사용합니다.
      1. 대상 리소스 유형의 경우 공용 IP 주소를 선택합니다.
      2. 공용 IP 주소 선택 드롭다운을 선택하고 이전에 저장한 미국 동부 지역의 IHS 공용 IP 주소 이름을 입력합니다. 일치하는 항목이 하나 표시됩니다. 공용 IP 주소에 대해 선택합니다.
    3. 장애 조치/보조 엔드포인트 myFailoverEndpoint를 추가하기 위한 6단계에서 다음 단계를 사용합니다.
      1. 대상 리소스 유형의 경우 공용 IP 주소를 선택합니다.
      2. 공용 IP 주소 선택 드롭다운을 선택하고 이전에 저장한 미국 서부 지역의 IHS 공용 IP 주소 이름을 입력합니다. 일치하는 항목이 하나 표시됩니다. 공용 IP 주소에 대해 선택합니다.
    4. 잠시 기다립니다. 엔드포인트에 대한 모니터 상태 온라인이고 엔드 myFailoverEndpoint 포인트 myPrimaryEndpoint 에 대한 모니터 상태 성능이 저하될 때까지 새로 고침을 선택합니다.

다음으로, 다음 단계를 사용하여 기본 WebSphere 클러스터에 배포된 샘플 앱이 Traffic Manager 프로필에서 액세스할 수 있는지 확인합니다.

  1. 만든 Traffic Manager 프로필에 대한 개요를 선택합니다.

  2. Traffic Manager 프로필의 do기본 이름 시스템(DNS) 이름을 선택하고 복사한 다음, 다음과 같이 /websphere-cafe/http://tmprofile-mjg022624.trafficmanager.net/websphere-cafe/추가합니다.

  3. 브라우저의 새 탭에서 URL을 엽니다. 이전에 만든 커피가 페이지에 나열되어 있어야 합니다.

  4. 다른 이름 및 가격(예: 가격 20의 Coffee 2)을 사용하여 다른 커피를 만듭니다. 이 커피는 데이터베이스의 애플리케이션 데이터 테이블과 세션 테이블 모두에 유지됩니다. 표시되는 UI는 다음 스크린샷과 유사해야 합니다.

    두 번째 커피가 있는 샘플 애플리케이션 UI의 스크린샷.

UI가 비슷하지 않으면 계속하기 전에 문제를 해결하고 해결합니다. 콘솔을 열어 두고 나중에 장애 조치(failover) 테스트에 사용합니다.

이제 Traffic Manager 프로필을 설정합니다. 페이지를 열어 두고 나중에 장애 조치(failover) 이벤트의 변경 상태 엔드포인트를 모니터링하는 데 사용합니다.

기본에서 보조로 장애 조치(failover) 테스트

장애 조치(failover)를 테스트하려면 Azure SQL Database 서버 및 클러스터를 수동으로 장애 조치(failover)한 다음, Azure Portal을 사용하여 장애 복구(failback)합니다.

보조 사이트로 장애 조치(failover)

먼저 다음 단계를 사용하여 주 서버에서 보조 서버로 Azure SQL Database를 장애 조치합니다.

  1. 예를 들어 failovergroup-mjg022624Azure SQL Database 장애 조치(failover) 그룹의 브라우저 탭으로 전환합니다.
  2. 장애 조치(Failover>)를 선택합니다.
  3. 완료될 때까지 기다립니다.

다음으로, 다음 단계를 사용하여 복구 계획을 사용하여 WebSphere 클러스터를 장애 조치(failover)합니다.

  1. Azure Portal 위쪽의 검색 상자에 Recovery Services 자격 증명 모음을 입력한 다음 검색 결과에서 Recovery Services 자격 증명 모음을 선택합니다.

  2. Recovery Services 자격 증명 모음의 이름을 선택합니다(예: recovery-service-vault-westus-mjg022624.).

  3. 관리에서 복구 계획(Site Recovery)을 선택합니다. 만든 복구 계획(예: recovery-plan-mjg022624.)을 선택합니다.

  4. 장애 조치(failover)를 선택합니다. 위험을 이해합니다. 테스트 장애 조치(failover)를 건너뜁니다. 다른 필드의 기본값을 그대로 두고 확인을 선택합니다.

    참고 항목

    필요에 따라 테스트 장애 조치(failover) 및 정리 테스트 장애 조치(failover)를 실행하여 장애 조치(failover)를 테스트하기 전에 모든 것이 예상대로 작동하는지 확인할 수 있습니다. 자세한 내용은 자습서: Azure VM에 대한 재해 복구 훈련 실행을 참조 하세요. 이 자습서에서는 장애 조치( Failover )를 직접 테스트하여 연습을 간소화합니다.

    장애 조치(failover) 창을 보여 주는 Azure Portal의 스크린샷.

  5. 완료될 때까지 알림에서 장애 조치(failover)를 모니터링합니다. 이 자습서의 연습에는 약 10분이 걸립니다.

    진행 중인 장애 조치(failover)를 보여 주는 Azure Portal 알림 창의 스크린샷

    완료된 장애 조치(failover)를 보여 주는 Azure Portal 알림 창의 스크린샷.

  6. 필요에 따라 알림에서 장애 조치(failover) 이벤트(예: 'recovery-plan-mjg022624'의 장애 조치(failover)가 진행 중임) 을 선택하여 장애 조치(failover) 작업의 세부 정보를 볼 수 있습니다.

    장애 조치(failover) 작업 세부 정보를 보여 주는 Azure Portal 장애 조치(failover) 페이지의 스크린샷.

그런 다음, 다음 단계를 사용하여 보조 지역의 WebSphere 통합 솔루션 콘솔 및 샘플 앱에 대한 외부 액세스를 사용하도록 설정합니다.

  1. Azure Portal 위쪽의 검색 상자에 리소스 그룹을 입력한 다음 검색 결과에서 리소스 그룹을 선택합니다.
  2. 보조 지역의 리소스 그룹 이름을 선택합니다(예 was-cluster-westus-mjg022624: .). 리소스 그룹 페이지에서 형식별로 항목을 정렬합니다.
  3. 접두사로 접두사로 dmgr된 네트워크 인터페이스를 선택합니다. IP 구성 ipconfig1>선택합니다. 공용 IP 주소 연결을 선택합니다. 공용 IP 주소의 경우 접두사로 dmgr된 공용 IP 주소를 선택합니다. 이 주소는 이전에 만든 주소입니다. 이 문서에서는 주소의 이름을 dmgr-public-ip-westus-mjg022624지정합니다. 저장을 선택한 다음 완료될 때까지 기다립니다.
  4. 리소스 그룹으로 다시 전환하고 접두사로 된 네트워크 인터페이스ihs선택합니다. IP 구성 ipconfig1>선택합니다. 공용 IP 주소 연결을 선택합니다. 공용 IP 주소의 경우 접두사로 ihs된 공용 IP 주소를 선택합니다. 이 주소는 이전에 만든 주소입니다. 이 문서에서는 주소의 이름을 ihs-public-ip-westus-mjg022624지정합니다. 저장을 선택한 다음 완료될 때까지 기다립니다.

이제 다음 단계를 사용하여 장애 조치(failover)가 예상대로 작동하는지 확인합니다.

  1. 이전에 만든 Dmgr의 공용 IP 주소에 대한 DNS 이름 레이블을 찾습니다. 새 브라우저 탭에서 Dmgr WebSphere 통합 솔루션 콘솔의 URL을 엽니다. 를 사용하는 https것을 잊지 마세요. 예들 들어 https://dmgrmjg022624.westus.cloudapp.azure.com:9043/ibm/console입니다. 로그인 시작 페이지가 표시될 때까지 페이지를 새로 고칩니다.

  2. 이전에 저장한 WebSphere 관리자의 사용자 이름 및 암호를 사용하여 콘솔에 로그인한 다음 다음 단계를 사용합니다.

    1. 탐색 창에서 서버>모두 서버를 선택합니다. 미들웨어 서버 창에는 WebSphere 클러스터 MyCluster 로 구성된 3개의 WebSphere 애플리케이션 서버와 IHS인 1개의 웹 서버를 포함하여 4개의 서버가 나열됩니다. 모든 서버가 시작될 때까지 페이지를 새로 고칩니다.

      미들웨어 서버 페이지를 보여 주는 Dmgr WebSphere 통합 솔루션 콘솔의 스크린샷.

    2. 탐색 창에서 애플리케이션 애플리케이션>유형>WebSphere 엔터프라이즈 애플리케이션을 선택합니다. 엔터프라이즈 애플리케이션 창에 나열되고 시작된 1개의 애플리케이션 websphere-cafe 이 표시됩니다.

      엔터프라이즈 애플리케이션 페이지를 보여 주는 Dmgr WebSphere 통합 솔루션 콘솔의 스크린샷

    3. 보조 지역에서 클러스터 구성의 유효성을 검사하려면 클러스터 구성 섹션의 단계를 수행합니다. 다음 스크린샷과 같이 노드분산 세션을 사용하여 변경 내용을 동기화하는 설정이 장애 조치(failover) 클러스터에 복제본(replica) 표시됩니다.

      노드 검사box를 사용하여 동기화 변경 내용의 선택한 상태를 보여 주는 Dmgr WebSphere 통합 솔루션 콘솔의 스크린샷

      분산 세션 설정의 상태가 있는 데이터베이스 설정 페이지를 보여 주는 Dmgr WebSphere 통합 솔루션 콘솔의 스크린샷

  3. 이전에 만든 IHS의 공용 IP 주소에 대한 DNS 이름 레이블을 찾습니다. 루트 컨텍스트 /websphere-cafe/와 함께 추가된 IHS 콘솔의 URL을 엽니다. 을 사용하면 https안 됩니다. 이 예제에서는 IHS에 사용하지 https 않습니다(예: http://ihsmjg022624.westus.cloudapp.azure.com/websphere-cafe/.). 이전에 만든 두 개의 커피가 페이지에 나열되어 있어야 합니다.

  4. Traffic Manager 프로필의 브라우저 탭으로 전환한 다음 엔드포인트의 모니터 상태 값이 온라인상태가 되고 엔드포인트 myFailoverEndpoint 의 모니터 상태myPrimaryEndpoint 이 저하때까지 페이지를 새로 고칩니다.

  5. Traffic Manager 프로필의 DNS 이름을 사용하여 브라우저 탭으로 전환합니다(예: http://tmprofile-mjg022624.trafficmanager.net/websphere-cafe/.). 페이지를 새로 고치면 애플리케이션 데이터 테이블에 동일한 데이터가 유지되고 세션 테이블이 표시됩니다. 표시되는 UI는 다음 스크린샷과 유사해야 합니다.

    장애 조치(failover) 후 샘플 애플리케이션 UI의 스크린샷.

    이 동작을 관찰하지 않으면 Traffic Manager가 장애 조치(failover) 사이트를 가리키도록 DNS를 업데이트하는 데 시간이 걸리기 때문일 수 있습니다. 문제는 브라우저가 실패한 사이트를 가리키는 DNS 이름 확인 결과를 캐시한 것일 수도 있습니다. 잠시 기다렸다가 페이지를 다시 새로 고칩니다.

장애 조치(failover) 커밋

장애 조치(failover) 결과가 만족되면 다음 단계를 사용하여 장애 조치(failover)를 커밋합니다.

  1. Azure Portal 위쪽의 검색 상자에 Recovery Services 자격 증명 모음을 입력한 다음 검색 결과에서 Recovery Services 자격 증명 모음을 선택합니다.

  2. Recovery Services 자격 증명 모음의 이름을 선택합니다(예: recovery-service-vault-westus-mjg022624.).

  3. 관리에서 복구 계획(Site Recovery)을 선택합니다. 만든 복구 계획(예: recovery-plan-mjg022624.)을 선택합니다.

  4. 커밋>확인을 선택합니다.

  5. 커밋이 완료될 때까지 알림에서 모니터링합니다.

    진행 중인 장애 조치(failover) 커밋을 보여 주는 Azure Portal 알림 창의 스크린샷

    완료된 장애 조치(failover) 커밋을 보여 주는 Azure Portal 알림 창의 스크린샷.

  6. 복구 계획에서 항목을 선택합니다. 장애 조치(failover)가 커밋된 것으로 나열된 5개 항목이 표시됩니다.

    복제본(replica)ted 항목을 커밋된 장애 조치(failover)로 보여 주는 Azure Portal의 스크린샷.

복제본(replica) 사용 안 함

다음 단계를 사용하여 복구 계획의 항목에 대한 복제본(replica)tion을 사용하지 않도록 설정한 다음 복구 계획을 삭제합니다.

  1. 복구 계획의 항목에 있는 각 항목에 대해 줄임표 단추(...)를 선택한 다음 복제 사용 안 함을 선택합니다.

  2. 이 가상 머신에 대한 보호를 사용하지 않도록 설정하는 이유를 입력하라는 메시지가 표시되면 원하는 가상 머신을 선택합니다. 예를 들어 내 애플리케이션 마이그레이션을 완료했습니다. 확인을 선택합니다.

  3. 모든 항목에 대해 복제본(replica)tion을 사용하지 않도록 설정할 때까지 1단계를 반복합니다.

  4. 완료될 때까지 알림의 프로세스를 모니터링합니다.

    복제본(replica)ted 항목을 제거하기 위한 완료된 메시지를 보여 주는 Azure Portal 알림 창의 스크린샷

  5. 개요>삭제를 선택합니다. 를 선택하여 삭제를 확인합니다.

장애 복구 준비: 장애 조치(failover) 사이트 다시 보호

이제 보조 지역이 장애 조치(failover) 사이트 및 활성 상태입니다. 주 지역에서 다시 보호해야 합니다.

먼저 다음 단계를 사용하여 사용되지 않는 리소스를 클린 Azure Site Recovery 서비스가 나중에 주 지역에서 복제본(replica). 사이트 복구는 리소스를 기존 리소스 그룹으로 복원하므로 리소스 그룹을 삭제할 수 없습니다.

  1. Azure Portal 위쪽의 검색 상자에 리소스 그룹을 입력한 다음 검색 결과에서 리소스 그룹을 선택합니다.
  2. 주 지역의 리소스 그룹 이름(예 was-cluster-eastus-mjg022624: .)을 선택합니다. 리소스 그룹 페이지에서 형식별로 항목을 정렬합니다.
  3. 다음 단계를 사용하여 가상 머신을 삭제합니다.
    1. 형식 필터를 선택한 다음, 값 드롭다운 목록에서 가상 머신선택합니다.
    2. 적용을 선택합니다.
    3. 모든 가상 머신을 선택하고 삭제를 선택한 다음 삭제를 입력하여 삭제를 확인합니다.
    4. 삭제를 선택합니다.
    5. 완료될 때까지 알림의 프로세스를 모니터링합니다.
  4. 다음 단계를 사용하여 디스크를 삭제합니다.
    1. 유형 필터를 선택한 다음 값 드롭다운 목록에서 디스크선택합니다.
    2. 적용을 선택합니다.
    3. 모든 디스크를 선택하고 삭제를 선택한 다음 삭제를 입력하여 삭제를 확인합니다.
    4. 삭제를 선택합니다.
    5. 알림에서 프로세스를 모니터링하고 완료될 때까지 기다립니다.
  5. 다음 단계를 사용하여 엔드포인트를 삭제합니다.
    1. 형식 필터를 선택하고 값 드롭다운 목록에서 프라이빗 엔드포인트선택합니다.
    2. 적용을 선택합니다.
    3. 모든 프라이빗 엔드포인트를 선택하고 삭제를 선택한 다음 삭제를 입력하여 삭제를 확인합니다.
    4. 삭제를 선택합니다.
    5. 완료될 때까지 알림의 프로세스를 모니터링합니다. 프라이빗 엔드포인트 유형이 나열되지 않은 경우 이 단계를 무시합니다.
  6. 다음 단계를 사용하여 네트워크 인터페이스를 삭제합니다.
    1. 드롭다운 목록에서 유형 필터 > 선택 네트워크 인터페이스선택합니다.
    2. 적용을 선택합니다.
    3. 모든 네트워크 인터페이스를 선택하고 삭제를 선택한 다음 삭제를 입력하여 삭제를 확인합니다.
    4. 삭제를 선택합니다. 완료될 때까지 알림의 프로세스를 모니터링합니다.
  7. 다음 단계를 사용하여 스토리지 계정을 삭제합니다.
    1. 드롭다운 목록에서 유형 필터 > 선택 스토리지 계정을 선택합니다.
    2. 적용을 선택합니다.
    3. 모든 스토리지 계정을 선택하고 삭제를 선택한 다음 삭제를 입력하여 삭제를 확인합니다.
    4. 삭제를 선택합니다. 완료될 때까지 알림의 프로세스를 모니터링합니다.

다음으로, 다음 차이점을 제외하고 주 지역에 대한 Azure Site Recovery 섹션을 사용하여 클러스터에 대한 재해 복구 설정에서 동일한 단계를 사용합니다.

  1. Recovery Services 자격 증명 모음 만들기 섹션의 경우 다음 단계를 사용합니다.
    1. 주 지역에 배포된 리소스 그룹(예 was-cluster-eastus-mjg022624: .)을 선택합니다.
    2. 서비스 자격 증명 모음의 다른 이름(예: .) recovery-service-vault-eastus-mjg022624을 입력합니다.
    3. 지역에 대해 미국 동부를 선택합니다.
  2. 복제본(replica) 설정의 경우 다음 단계를 사용합니다.
    1. 원본지역에 대해 미국 서부를 선택합니다.
    2. 복제 설정의 경우 다음 단계를 사용합니다.
      1. 대상 리소스 그룹의 경우 주 지역에 배포된 기존 리소스 그룹(예: was-cluster-eastus-mjg022624)을 선택합니다.
      2. 장애 조치(failover) 가상 네트워크의 경우 주 지역의 기존 가상 네트워크를 선택합니다.
  3. 복구 계획 만들기의 경우 원본에 대해 미국 서부를 선택하고 대상에 대해 미국 동부를 선택합니다.
  4. 이전에 이러한 리소스를 만들고 구성했기 때문에 보조 지역에 대한 추가 네트워크 구성 섹션의 단계를 건너뜁니다.

참고 항목

Azure Site Recovery는 대상 VM이 있을 때 VM 다시 보호를 지원합니다. 자세한 내용은 자습서의 VM 다시 보호 섹션을 참조하세요. Azure VM을 보조 지역으로 장애 조치(failover)합니다. WebSphere에 대한 접근 방식 때문에 이 기능은 작동하지 않습니다. 그 이유는 확인 결과에 따라 원본 디스크와 대상 디스크 간의 유일한 변경 내용이 WebSphere 클러스터에 대해 동기화되기 때문입니다. VM 다시 보호 기능의 기능을 대체하기 위해 이 자습서에서는 장애 조치(failover) 후 보조 사이트에서 기본 사이트로의 새 복제본(replica) 설정합니다. 전체 디스크는 장애 조치된 지역에서 주 지역으로 복사됩니다. 자세한 내용은 다시 보호 중에 어떻게 되나요? Azure 가상 머신을 주 지역으로 장애 조치(failover)한 다시 보호 섹션을 참조하세요.

기본 사이트로 장애 복구

다음 차이점을 제외하고 보조 사이트 섹션에 대한 장애 조치(failover)의 동일한 단계를 사용하여 데이터베이스 서버 및 클러스터를 포함한 기본 사이트로 장애 복구합니다.

  1. 주 지역에 배포된 복구 서비스 자격 증명 모음을 선택합니다(예 recovery-service-vault-eastus-mjg022624: .).
  2. 주 지역에 배포된 리소스 그룹(예 was-cluster-eastus-mjg022624: .)을 선택합니다.
  3. 주 지역의 WebSphere 통합 솔루션 콘솔 및 샘플 앱에 대한 외부 액세스를 사용하도록 설정한 후 WebSphere 통합 솔루션 콘솔의 브라우저 탭과 이전에 연 주 클러스터의 샘플 앱을 다시 방문합니다. 예상대로 작동하는지 확인합니다. 장애 복구에 걸린 시간에 따라 이전에 1시간 이상 만료된 경우 샘플 앱 UI의 새 커피 섹션에 세션 데이터가 표시되지 않을 수 있습니다.
  4. 장애 조치(failover) 커밋 섹션에서 주 복제본에 배포된 Recovery Services 자격 증명 모음을 선택합니다(예: recovery-service-vault-eastus-mjg022624).
  5. Traffic Manager 프로필에서 엔드포인트가 온라인 상태가 되고 엔드포인트 myPrimaryEndpoint 가 성능이 저하되는 것을 myFailoverEndpoint 볼 수 있습니다.
  6. 장애 복구 준비: 장애 조치(failover) 사이트 다시 보호 섹션에서 다음 단계를 사용합니다.
    1. 주 지역은 장애 조치(failover) 사이트이며 활성 상태이므로 보조 지역에서 다시 보호해야 합니다.
    2. 보조 지역에 배포된 리소스(예: 배포된 was-cluster-westus-mjg022624리소스)를 정리합니다.
    3. 다음 변경 내용을 제외하고 보조 지역의 주 지역을 보호하기 위해 Azure Site Recovery 섹션을 사용하여 클러스터에 대한 재해 복구 설정에서 동일한 단계를 사용합니다.
      1. 이전에 만들었기 때문에 Recovery Services 자격 증명 모음 만들기 섹션의 단계를 건너뜁니다(예: recovery-service-vault-westus-mjg022624.).
      2. 복제본(replica)tion>복제 설정>장애 조치(failover) 가상 네트워크 사용의 경우 보조 지역에서 기존 가상 네트워크를 선택합니다.
      3. 이전에 이러한 리소스를 만들고 구성했기 때문에 보조 지역 섹션에 대한 추가 네트워크 구성의 단계를 건너뜁니다.

리소스 정리

WebSphere 클러스터 및 기타 구성 요소를 계속 사용하지 않려면 다음 단계를 사용하여 리소스 그룹을 삭제하여 이 자습서에 사용된 리소스를 클린.

  1. Azure Portal 맨 위에 있는 검색 상자에 Azure SQL Database 서버의 리소스 그룹 이름(예 myResourceGroup : )을 입력하고 검색 결과에서 일치하는 리소스 그룹을 선택합니다.
  2. 리소스 그룹 삭제를 선택합니다.
  3. 리소스 그룹 이름을 입력하여 삭제를 확인하려면 리소스 그룹 이름을 입력합니다.
  4. 삭제를 선택합니다.
  5. Traffic Manager의 리소스 그룹에 대해 1-4단계를 반복합니다(예: myResourceGroupTM1).
  6. Azure Portal 위쪽의 검색 상자에 Recovery Services 자격 증명 모음을 입력한 다음 검색 결과에서 Recovery Services 자격 증명 모음을 선택합니다.
  7. Recovery Services 자격 증명 모음의 이름을 선택합니다(예: recovery-service-vault-westus-mjg022624.).
  8. 관리에서 복구 계획(Site Recovery)을 선택합니다. 만든 복구 계획(예: recovery-plan-mjg022624.)을 선택합니다.
  9. 복제본(replica) 해제 섹션에서 동일한 단계를 사용하여 복제본(replica)ted 항목에 대한 잠금을 제거합니다.
  10. 기본 WebSphere 클러스터의 리소스 그룹에 대해 1-4단계를 반복합니다(예 was-cluster-westus-mjg022624: .).
  11. 예를 들어 was-cluster-eastus-mjg022624보조 WebSphere 클러스터의 리소스 그룹에 대해 1-4단계를 반복합니다.

다음 단계

이 자습서에서는 활성-수동 데이터베이스 계층이 있는 활성-수동 애플리케이션 인프라 계층으로 구성되고 두 계층이 지리적으로 다른 두 사이트에 걸쳐 있는 HA/DR 솔루션을 설정합니다. 첫 번째 사이트에서는 애플리케이션 인프라 계층과 데이터베이스 계층이 모두 활성화됩니다. 두 번째 사이트에서는 보조 do기본 Azure Site Recovery 서비스를 사용하여 복원되고 보조 데이터베이스는 대기 상태입니다.

HA/DR 솔루션을 빌드하고 Azure에서 WebSphere를 실행하는 추가 옵션에 대한 다음 참조를 계속 살펴봅니다.