14.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>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이 발생하지 않습니다. 대신 장애 조치 이벤트가 발생하면 백업 브로커가 활성화되고 다음 백업이 백업이 됩니다. 원래 라이브 브로커가 다시 온라인 상태가 되면 현재 살고 있는 브로커에 이미 백업이 있기 때문에 역백을 시작할 수 없습니다.

      restart-backup

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

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

절차

1. ZooKeeper 조정 서비스를 사용하여 복제 고가용성을 사용하도록 라이브 브로커를 구성합니다.

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

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

      <configuration>
          <core>
              ...
              <ha-policy>
                  <replication>
                      <primary>
                          <manager>
                          ...
                          </manager>
                            <group-name>my-group-1</group-name>
                      </primary>
                  </replication>
              </ha-policy>
              ...
          </core>
      </configuration>

      primary

      이 브로커가 초기 구성 후 라이브 브로커로 시작됨을 나타냅니다.

      group-name

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

   3. 관리자 섹션에서 라이브 브로커를 ZooKeeper 노드에 연결하도록 속성을 구성합니다.

      <configuration>
          <core>
              ...
              <ha-policy>
                  <replication>
                      <primary>
                          <manager>
                              <class-name>org.apache.activemq.artemis.quorum.zookeeper.CuratorDistributedPrimitiveManager</class-name>
                              <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>

      class-name

      ZooKeeper 조정 서비스의 클래스 이름은 org.apache.activemq.artemis.quorum.zookeeper.CuratorDistributedPrimitiveManager 입니다. 이 요소는 Apache Curator가 기본 관리자인 경우 선택 사항입니다.

      속성

      ZooKeeper 노드의 연결 세부 정보를 제공하기 위해 키-값 쌍 집합을 지정할 수 있는 속성 요소를 지정합니다.

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

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

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

2. ZooKeeper 조정 서비스를 사용하여 복제 고가용성을 사용하도록 백업 브로커를 구성합니다.

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

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

      <configuration>
          <core>
              ...
              <ha-policy>
                  <replication>
                      <backup>
                          <manager>
                           ...
                          </manager>
                          <group-name>my-group-1</group-name>
                          <allow-failback>true</allow-failback>
                       </backup>
                  </replication>
              </ha-policy>
              ...
          </core>
      </configuration>

      Backup

      이 브로커가 초기 구성 후 백업 브로커로 시작됨을 나타냅니다.

      group-name

      이 백업이 연결되는 라이브 브로커의 그룹 이름입니다. 백업 브로커는 동일한 그룹 이름을 공유하는 라이브 브로커에만 연결됩니다. 그룹 이름을 지정하지 않으면 백업 브로커는 라이브 브로커와 복제할 수 있습니다.

      allow-failback

      true 로 설정하면 현재 라이브 브로커인 백업 브로커를 허용하고 라이브 역할을 다시 복제 파트너에게 제공할 수 있습니다.

      라이브 (primary) 브로커로 구성된 브로커가 시작되면 최신 데이터가 있는지 확인하고 라이브 브로커로 실행할 수 있습니다. 데이터가 최신 상태가 아닌 경우 브로커는 빈 저널로 다시 시작하여 현재 라이브 브로커에 연결하여 최신 데이터를 복제할 때까지 기다립니다. 기본 브로커로 구성된 브로커는 데이터를 복제한 후 현재 활성 상태인 백업 브로커를 요청하여 장애 조치(failover)하고 다시 라이브 브로커가 될 수 있도록 다시 시작합니다.

      allow-failback 이 true 로 설정된 경우 백업 브로커는 복제 파트너가 다시 활성화될 수 있도록 다시 시작합니다. allow-failback 이 false 로 설정된 경우 백업 브로커는 재시작되지 않으므로 두 브로커 모두 현재 역할을 유지합니다.

   3. 관리자 섹션에서 백업 브로커를 ZooKeeper 노드에 연결하도록 속성을 구성합니다.

      <configuration>
          <core>
              ...
              <ha-policy>
                  <replication>
                      <backup>
                          <manager>
                              <class-name>org.apache.activemq.artemis.quorum.zookeeper.CuratorDistributedPrimitiveManager</class-name>
                              <properties>
                                  <property key="connect-string" value="192.168.1.10:6666,192.168.2.10:6667,192.168.3.10:6668"/>
                              </properties>
                          </manager>
                      ...
                      </backup>
                  </replication>
              </ha-policy>
              ...
          </core>
      </configuration>

      class-name

      ZooKeeper 조정 서비스의 클래스 이름은 org.apache.activemq.artemis.quorum.zookeeper.CuratorDistributedPrimitiveManager 입니다. 이 요소는 Apache Curator가 기본 관리자인 경우 선택 사항입니다.

      속성

      다음과 같이 ZooKeeper 노드의 연결 세부 정보를 제공하기 위해 키-값 쌍 집합을 지정할 수 있는 속성 섹션을 지정합니다.

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

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

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

3. 1단계와 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>
                          <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이 발생하지 않습니다. 대신 장애 조치 이벤트가 발생하면 백업 브로커가 활성화되고 다음 백업이 백업이 됩니다. 원래 라이브 브로커가 다시 온라인 상태가 되면 현재 살고 있는 브로커에 이미 백업이 있기 때문에 역백을 시작할 수 없습니다.

      group-name

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

      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 그룹에 대해 이 절차를 두 번 더 반복합니다.