16.3. 고가용성 구현

절차

1. 클러스터의 브로커를 라이브 백업 그룹으로 그룹화합니다.

   대부분의 경우 실시간 백업 그룹은 라이브 브로커와 백업 브로커의 두 가지 브로커로 구성되어야 합니다. 클러스터에 6개의 브로커가 있는 경우 3개의 라이브 백업 그룹이 필요합니다.

2. 하나의 라이브 브로커와 하나의 백업 브로커로 구성된 첫 번째 라이브 백업 그룹을 생성합니다.

   1. 라이브 브로커의 < broker-instance-dir> /etc/broker.xml 구성 파일을 엽니다.

   2. 사용 중인 경우:

      1. 공유 저장소를 제공하는 네트워크 파일 시스템에서 라이브 브로커의 페이징, 바인딩, 저널 및 대규모 메시지 디렉터리가 백업 브로커에서 액세스할 수 있는 공유 위치를 가리키는지 확인합니다.

         <configuration>
             <core>
                 ...
                 <paging-directory>../sharedstore/data/paging</paging-directory>
                 <bindings-directory>../sharedstore/data/bindings</bindings-directory>
                 <journal-directory>../sharedstore/data/journal</journal-directory>
                 <large-messages-directory>../sharedstore/data/large-messages</large-messages-directory>
                 ...
             </core>
         </configuration>

      2. 공유 저장소를 제공할 데이터베이스는 마스터 및 백업 브로커 모두 동일한 데이터베이스에 연결하고 broker.xml 구성 파일의 database-store 요소에 지정된 것과 동일한 구성을 사용할 수 있는지 확인합니다. 구성 예는 다음과 같습니다.

         <configuration>
           <core>
             <store>
                <database-store>
                   <jdbc-connection-url>jdbc:oracle:data/oracle/database-store;create=true</jdbc-connection-url>
                   <jdbc-user>ENC(5493dd76567ee5ec269d11823973462f)</jdbc-user>
                   <jdbc-password>ENC(56a0db3b71043054269d11823973462f)</jdbc-password>
                   <bindings-table-name>BINDINGS_TABLE</bindings-table-name>
                   <message-table-name>MESSAGE_TABLE</message-table-name>
                   <large-message-table-name>LARGE_MESSAGES_TABLE</large-message-table-name>
                   <page-store-table-name>PAGE_STORE_TABLE</page-store-table-name>
                   <node-manager-store-table-name>NODE_MANAGER_TABLE<node-manager-store-table-name>
                   <jdbc-driver-class-name>oracle.jdbc.driver.OracleDriver</jdbc-driver-class-name>
                   <jdbc-network-timeout>10000</jdbc-network-timeout>
                   <jdbc-lock-renew-period>2000</jdbc-lock-renew-period>
                   <jdbc-lock-expiration>15000</jdbc-lock-expiration>
                   <jdbc-journal-sync-period>5</jdbc-journal-sync-period>
                </database-store>
             </store>
           </core>
         </configuration>

   3. HA 정책에 공유 저장소를 사용하도록 라이브 브로커를 구성합니다.

      <configuration>
          <core>
              ...
              <ha-policy>
                  <shared-store>
                      <master>
                          <failover-on-shutdown>true</failover-on-shutdown>
                      </master>
                  </shared-store>
              </ha-policy>
              ...
          </core>
      </configuration>

      failover-on-shutdown

      이 브로커가 정상적으로 중지되면 이 속성은 백업 브로커가 활성화되고 인수되어야 하는지 여부를 제어합니다.

   4. 백업 브로커의 < broker-instance-dir> /etc/broker.xml 구성 파일을 엽니다.

   5. 사용 중인 경우:

      1. 공유 저장소를 제공하는 네트워크 파일 시스템에서 백업 브로커의 페이징, 바인딩, 저널 및 대규모 메시지 디렉터리가 라이브 브로커와 동일한 공유 위치를 가리키는지 확인합니다.

         <configuration>
             <core>
                 ...
                 <paging-directory>../sharedstore/data/paging</paging-directory>
                 <bindings-directory>../sharedstore/data/bindings</bindings-directory>
                 <journal-directory>../sharedstore/data/journal</journal-directory>
                 <large-messages-directory>../sharedstore/data/large-messages</large-messages-directory>
                 ...
             </core>
         </configuration>

      2. 공유 저장소를 제공할 데이터베이스는 마스터 및 백업 브로커 모두 동일한 데이터베이스에 연결하고 broker.xml 구성 파일의 database-store 요소에 지정된 것과 동일한 구성을 가질 수 있는지 확인합니다.

   6. HA 정책에 공유 저장소를 사용하도록 백업 브로커를 구성합니다.

      <configuration>
          <core>
              ...
              <ha-policy>
                  <shared-store>
                      <slave>
                          <failover-on-shutdown>true</failover-on-shutdown>
                          <allow-failback>true</allow-failback>
                          <restart-backup>true</restart-backup>
                      </slave>
                  </shared-store>
              </ha-policy>
              ...
          </core>
      </configuration>

      failover-on-shutdown

      이 브로커가 활성 상태가 되고 정상적으로 중지되면 이 속성은 백업 브로커(원래 라이브 브로커)가 활성화되고 인수되어야 하는지 여부를 제어합니다.

      allow-failback

      장애 조치가 발생하고 라이브 브로커에 대해 백업 브로커가 가져왔으면 이 속성은 다시 시작하고 클러스터에 다시 연결할 때 백업 브로커가 원래 라이브 브로커로 돌아가야 하는지 여부를 제어합니다.

      참고

      failback은 실시간 백업 쌍(단일 백업 브로커와 페어링된 라이브 브로커)을 위한 것입니다. 라이브 브로커가 여러 백업으로 구성된 경우 failback이 발생하지 않습니다. 대신 장애 조치 이벤트가 발생하면 백업 브로커가 활성화되고 다음 백업이 백업이 됩니다. 원래 라이브 브로커가 다시 온라인 상태가 되면 현재 살고 있는 브로커에 이미 백업이 있기 때문에 역백을 시작할 수 없습니다.

      restart-backup

      이 속성은 라이브 브로커로 다시 실패한 후 백업 브로커가 자동으로 다시 시작하는지 여부를 제어합니다. 이 속성의 기본값은 true 입니다.

3. 클러스터의 나머지 라이브 백업 그룹에 대해 2단계를 반복합니다.

절차

1. 클러스터의 브로커를 라이브 백업 그룹으로 그룹화합니다.

   대부분의 경우 실시간 백업 그룹은 라이브 브로커와 백업 브로커의 두 가지 브로커로 구성되어야 합니다. 클러스터에 6개의 브로커가 있는 경우 3개의 라이브 백업 그룹이 필요합니다.

2. 하나의 라이브 브로커와 하나의 백업 브로커로 구성된 첫 번째 라이브 백업 그룹을 생성합니다.

   1. 라이브 브로커의 < broker-instance-dir> /etc/broker.xml 구성 파일을 엽니다.

   2. HA 정책에 복제를 사용하도록 라이브 브로커를 구성합니다.

      <configuration>
          <core>
              ...
              <ha-policy>
                  <replication>
                      <master>
                          <check-for-live-server>true</check-for-live-server>
                          <group-name>my-group-1</group-name>
                          <vote-on-replication-failure>true</vote-on-replication-failure>
                          ...
                      </master>
                  </replication>
              </ha-policy>
              ...
          </core>
      </configuration>

      check-for-live-server

      라이브 브로커가 실패하면 이 속성은 클라이언트가 다시 시작할 때 클라이언트가 다시 실패해야 하는지 여부를 제어합니다.

      이 속성을 true 로 설정하면 이전 장애 조치 후 라이브 브로커가 다시 시작되면 동일한 노드 ID가 있는 클러스터에서 다른 브로커를 검색합니다. 라이브 브로커가 동일한 노드 ID가 있는 다른 브로커를 발견하면 라이브 브로커가 실패했을 때 백업 브로커가 성공적으로 시작되었음을 나타냅니다. 이 경우 라이브 브로커는 데이터를 백업 브로커와 동기화합니다. 그런 다음 라이브 브로커는 백업 브로커를 종료하도록 요청합니다. 백업 브로커가 장애백에 대해 구성된 경우 아래와 같이 종료됩니다. 그런 다음 라이브 브로커는 활성 역할을 다시 시작하고 클라이언트가 다시 연결합니다.

      주의

      라이브 브로커에서 check-for-live-server 를 true 로 설정하지 않으면 이전 페일오버 후 라이브 브로커를 다시 시작할 때 중복 메시징 처리가 발생할 수 있습니다. 특히 이 속성이 false 로 설정된 라이브 브로커를 다시 시작하면 라이브 브로커는 데이터를 백업 브로커와 동기화하지 않습니다. 이 경우 라이브 브로커는 백업 브로커가 이미 처리한 것과 동일한 메시지를 처리하여 중복을 유발할 수 있습니다.

      group-name

      이 Live-backup 그룹의 이름입니다. 라이브 백업 그룹을 만들려면 동일한 그룹 이름으로 실시간 및 백업 브로커를 구성해야 합니다.

      vote-on-replication-failure

      이 속성은 활성 브로커가 중단된 복제 연결 시 실시간 투표 라는 쿼럼을 시작할지 여부를 제어합니다.

      실시간 투표는 라이브 브로커가 복제 연결 중단의 원인인지 여부를 결정하는 방법입니다. 투표 결과에 따라 라이브 브로커는 계속 실행 중이거나 종료됩니다.

      중요

      쿼럼 투표가 성공하려면 클러스터 크기가 대부분의 결과를 얻을 수 있어야 합니다. 따라서 복제 HA 정책을 사용하면 클러스터에 3개 이상의 실시간 백업 브로커 쌍이 있어야 합니다.

      클러스터에서 구성한 브로커 쌍이 많을수록 클러스터의 전체 내결함성이 증가할 수 있습니다. 예를 들어, 세 개의 라이브 백업 브로커 쌍이 있다고 가정합니다. 전체 라이브 백업 쌍에 대한 연결이 끊어지면 나머지 두 개의 live-backup 쌍은 더 이상 쿼럼 투표에서 대부분의 결과를 얻을 수 없습니다. 이는 이후의 복제 중단으로 인해 라이브 브로커가 종료되고 백업 브로커가 시작되지 않을 수 있음을 의미합니다. 예를 들어 5개의 브로커 쌍을 사용하여 클러스터를 구성하면 클러스터에 오류가 두 개 이상 발생할 수 있지만 쿼럼 투표에서 대다수의 결과를 보장할 수 있습니다.

   3. 라이브 브로커의 추가 HA 속성을 구성합니다.

      이러한 추가 HA 속성에는 대부분의 일반적인 사용 사례에 적합한 기본값이 있습니다. 따라서 기본 동작을 원하지 않는 경우에만 이러한 속성을 구성해야 합니다. 자세한 내용은 부록 F. 복제 고가용성 구성 ScanSetting의 내용을 참조하십시오.

   4. 백업 브로커의 < broker-instance-dir> /etc/broker.xml 구성 파일을 엽니다.

   5. HA 정책에 복제를 사용하도록 백업(즉, 슬레이브) 브로커를 구성합니다.

      <configuration>
          <core>
              ...
              <ha-policy>
                  <replication>
                      <slave>
                          <allow-failback>true</allow-failback>
                          <restart-backup>true</restart-backup>
                          <group-name>my-group-1</group-name>
                          <vote-on-replication-failure>true</vote-on-replication-failure>
                          ...
                      </slave>
                  </replication>
              </ha-policy>
              ...
          </core>
      </configuration>

      allow-failback

      장애 조치가 발생하고 라이브 브로커에 대해 백업 브로커가 가져왔으면 이 속성은 다시 시작하고 클러스터에 다시 연결할 때 백업 브로커가 원래 라이브 브로커로 돌아가야 하는지 여부를 제어합니다.

      참고

      failback은 실시간 백업 쌍(단일 백업 브로커와 페어링된 라이브 브로커)을 위한 것입니다. 라이브 브로커가 여러 백업으로 구성된 경우 failback이 발생하지 않습니다. 대신 장애 조치 이벤트가 발생하면 백업 브로커가 활성화되고 다음 백업이 백업이 됩니다. 원래 라이브 브로커가 다시 온라인 상태가 되면 현재 살고 있는 브로커에 이미 백업이 있기 때문에 역백을 시작할 수 없습니다.

      restart-backup

      이 속성은 라이브 브로커로 다시 실패한 후 백업 브로커가 자동으로 다시 시작하는지 여부를 제어합니다. 이 속성의 기본값은 true 입니다.

      group-name

      이 백업을 연결해야 하는 라이브 브로커의 그룹 이름입니다. 백업 브로커는 동일한 그룹 이름을 공유하는 라이브 브로커에만 연결됩니다.

      vote-on-replication-failure

      이 속성은 활성 브로커가 중단된 복제 연결 시 실시간 투표 라는 쿼럼을 시작할지 여부를 제어합니다. 활성 상태가 된 백업 브로커는 라이브 브로커로 간주되며 라이브 투표가 시작될 수 있습니다.

      실시간 투표는 라이브 브로커가 복제 연결 중단의 원인인지 여부를 결정하는 방법입니다. 투표 결과에 따라 라이브 브로커는 계속 실행 중이거나 종료됩니다.

   6. (선택 사항) 백업 브로커가 시작하는 쿼럼 투표의 속성을 구성합니다.

      <configuration>
          <core>
              ...
              <ha-policy>
                  <replication>
                      <slave>
                      ...
                          <vote-retries>12</vote-retries>
                          <vote-retry-wait>5000</vote-retry-wait>
                      ...
                      </slave>
                  </replication>
              </ha-policy>
              ...
          </core>
      </configuration>

      vote-retries

      이 속성은 백업 브로커를 시작할 수 있는 대부분의 결과를 받기 위해 백업 브로커가 쿼럼을 다시 시도하는 횟수를 제어합니다.

      vote-retry-wait

      이 속성은 쿼럼 투표의 각 재시도 사이에 백업 브로커가 대기하는 시간(밀리초)을 제어합니다.

   7. 백업 브로커의 추가 HA 속성을 구성합니다.

      이러한 추가 HA 속성에는 대부분의 일반적인 사용 사례에 적합한 기본값이 있습니다. 따라서 기본 동작을 원하지 않는 경우에만 이러한 속성을 구성해야 합니다. 자세한 내용은 부록 F. 복제 고가용성 구성 ScanSetting의 내용을 참조하십시오.

3. 클러스터의 추가 라이브 백업 그룹에 대해 2단계를 반복합니다.

   클러스터에 6개의 브로커가 있는 경우 나머지 각 Live-backup 그룹에 대해 이 절차를 두 번 더 반복합니다.