14.3. 고가용성 구현

프로세스

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

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

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>BIND_TABLE</bindings-table-name>
                   <message-table-name>MSG_TABLE</message-table-name>
                   <large-message-table-name>LGE_TABLE</large-message-table-name>
                   <page-store-table-name>PAGE_TABLE</page-store-table-name>
                   <node-manager-store-table-name>NODE_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이 발생하지 않습니다. 대신 장애 조치(failover) 이벤트가 발생하면 백업 브로커가 라이브 상태가 되고 다음 백업이 백업이 됩니다. 원래 라이브 브로커가 다시 온라인 상태가 되면 현재 사용 중인 브로커가 이미 백업되어 있으므로 장애 조치를 시작할 수 없습니다.

      restart-backup

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

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

프로세스

1. live-backup 쌍의 두 브로커 모두에 대해 < broker_instance_dir> /etc/broker.xml 구성 파일을 엽니다.

2. 쌍의 두 브로커에 대해 동일한 복제 구성을 구성합니다. 예를 들면 다음과 같습니다.

   <configuration>
       <core>
           ...
           <ha-policy>
              <replication>
                 <primary>
                   <coordination-id>production-001</coordination-id>
                   <manager>
                      <properties>
                        <property key="connect-string" value="192.168.1.10:6666,192.168.2.10:6667,192.168.3.10:6668"/>
                      </properties>
                   </manager>
                 </primary>
              </replication>
           </ha-policy>
           ...
       </core>
   </configuration>

   기본 설정

   브로커 조정 결과에 따라 브로커 중 하나가 기본 브로커일 수 있음을 나타내도록 복제 유형을 primary로 구성합니다.

   reconcile-id

   라이브 백업 쌍의 두 브로커에 대한 공통 문자열 값을 지정합니다. 동일한 Coordination-id 문자열을 사용하는 브로커와 함께 활성화를 조정합니다. 조정 프로세스 중에 두 브로커는 Coordination-id 문자열을 노드 Id로 사용하고 Zoo Cryostat에서 잠금을 가져옵니다. 잠금을 확보하고 최신 데이터가 있는 첫 번째 브로커는 라이브 브로커로 시작되고 다른 브로커가 백업됩니다.

   속성

   Zoo Cryostat 노드에 대한 연결 세부 정보를 제공하기 위해 키-값 쌍 세트를 지정할 수 있는 속성 요소를 지정합니다.

   표 14.2. Zookeeper 연결 세부 정보

   키	현재의
   연결 문자열	Zoo Cryostat 노드의 IP 주소 및 포트 번호의 쉼표로 구분된 목록을 지정합니다. 예를 들어 value="192.168.1.10:6666,192.168.2.10:6667,192.168.3.10:6668".
   session-ms	대다수의 Zoo Cryostat 노드에 대한 연결이 끊어진 후 브로커가 종료되기 전에 대기하는 기간입니다. 기본값은 18000 ms입니다. 유효한 값은 2회에서 20배 사이입니다. Zoo Cryostat 서버의 틱 시간. 참고 가비지 컬렉션에 대한 Zoo Cryostat 일시 중지 시간은 Zoo Cryostat 하트비트가 안정적으로 작동할 수 있도록 세션-ms 속성 값의 0.33 미만이어야 합니다. 일시 중지 시간이 이 제한보다 작도록 할 수 없는 경우 각 브로커에 대한 session-ms 속성 값을 늘리고 느린 페일오버를 수락합니다. 중요 브로커 복제 파트너는 2초마다 자동으로 "핑" 패킷을 교환하여 파트너 브로커가 사용 가능한지 확인합니다. 백업 브로커가 라이브 브로커로부터 응답을 받지 못하면 백업은 브로커의 연결 시간-투-라이브(ttl)가 만료될 때까지 응답을 기다립니다. 기본 connection-ttl은 60000 ms이므로 백업 브로커가 60초 후에 장애 조치를 시도합니다. 더 빠른 장애 조치를 허용하려면 connection-ttl 값을 session-ms 속성 값과 유사한 값으로 설정하는 것이 좋습니다. 새 connection-ttl을 설정하려면 connection-ttl-override 속성을 구성합니다.
   네임스페이스(선택 사항)	브로커가 다른 애플리케이션과 Zoo Cryostat 노드를 공유하는 경우, 브로커에 조정 서비스를 제공하는 파일을 저장하기 위해 Zoo Cryostat 네임스페이스를 만들 수 있습니다. 두 브로커에 대해 라이브 백업 쌍에 동일한 네임스페이스를 지정해야 합니다.

3. 브로커에 대한 추가 HA 속성을 구성합니다.

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

4. 1~3단계를 반복하여 클러스터의 추가 라이브 백업 브로커 쌍을 구성합니다.

프로세스

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

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

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

      이 라이브 백업 그룹의 이름(선택 사항). 라이브 백업 그룹을 만들려면 라이브 및 백업 브로커를 동일한 그룹 이름으로 구성해야 합니다. 그룹 이름을 지정하지 않으면 라이브 브로커와 백업 브로커를 복제할 수 있습니다.

      vote-on-replication-failure

      이 속성은 라이브 브로커가 중단된 복제 연결이 발생할 경우 라이브 투표라는 쿼럼 투표를 시작하는지 여부를 제어합니다.

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

      중요

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

      클러스터에서 더 많은 브로커 쌍을 구성할수록 클러스터의 전반적인 내결함성을 높일 수 있습니다. 예를 들어 라이브 백업 브로커 쌍이 세 개 있다고 가정합니다. 전체 라이브 백업 쌍에 대한 연결이 끊어지면 나머지 두 라이브 백업 쌍이 더 이상 쿼럼 투표를 통해 대부분의 결과를 얻을 수 없습니다. 이 경우 후속 복제 중단으로 인해 라이브 브로커가 종료될 수 있으며 백업 브로커가 시작되지 않을 수 있습니다. 클러스터(예: 5개의 브로커 쌍)를 사용하여 클러스터를 구성하면 클러스터에 두 개 이상의 오류가 발생할 수 있으며 대부분의 경우 쿼럼 투표로 인한 결과가 발생합니다.

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

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

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

   5. HA 정책에 복제를 사용하도록 백업 브로커를 구성합니다.

      <configuration>
          <core>
              ...
              <ha-policy>
                  <replication>
                      <slave>
                          <allow-failback>true</allow-failback>
                          <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이 발생하지 않습니다. 대신 장애 조치(failover) 이벤트가 발생하면 백업 브로커가 라이브 상태가 되고 다음 백업이 백업이 됩니다. 원래 라이브 브로커가 다시 온라인 상태가 되면 현재 사용 중인 브로커가 이미 백업되어 있으므로 장애 조치를 시작할 수 없습니다.

      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. 추가 복제 고가용성 구성입니다.의 내용을 참조하십시오.

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

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