기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 관리형 통합 허브 오프보드 ## Hub SDK 오프보드 프로세스 개요 허브 오프보딩 프로세스는 AWS 클라우드 관리 시스템에서 허브를 제거합니다. 클라우드가 [DeleteManagedThing](https://docs.aws.amazon.com/iot-mi/latest/APIReference/API_DeleteManagedThing.html) 요청을 보내면 프로세스는 두 가지 기본 목표를 달성합니다. **디바이스 측 작업**: + 허브의 내부 상태 재설정 + 로컬로 저장된 모든 데이터 삭제 + 향후 재온보딩 가능성을 위해 디바이스 준비 **클라우드 측 작업**: + 허브와 연결된 모든 클라우드 리소스 제거 + 이전 계정과의 연결 해제 완료 고객은 일반적으로 다음과 같은 경우에 허브 오프보딩을 시작합니다. + 허브의 연결된 계정 변경 + 기존 허브를 새 디바이스로 교체 이 프로세스는 허브 구성 간에 깔끔하고 안전한 전환을 보장하여 원활한 디바이스 관리와 계정 유연성을 제공합니다. ![허브 오프보딩 다이어그램](https://docs.aws.amazon.com/ko_kr/iot-mi/latest/devguide/images/iot-managedintegrations-hub-sdk-offboarding-architecture.png) ## 사전 조건 + 온보딩된 허브가 있어야 합니다. 지침은 [허브 온보딩 설정을 참조하세요](managedintegrations-sdk-v2-cookbook-hubsetup.md). + **/data/aws/iotmi/config/**에 있는 `iotmi_config.json` 파일에서가 `iot_provisioning_state`를 표시하는지 확인합니다`PROVISIONED`. + 에서 참조되는 영구 인증서와 키가 지정된 경로에 `iotmi_config.json` 있는지 확인합니다. + HubOnboarding, Agent, Provisioner 및 MQTT 프록시가 올바르게 구성되고 실행 중인지 확인합니다. + 허브에 하위 디바이스가 없는지 확인합니다. 계속하기 전에 [ DeleteManagedThing](https://docs.aws.amazon.com/iot-mi/latest/APIReference/API_DeleteManagedThing.html) API를 사용하여 모든 하위 디바이스를 제거합니다. ## Hub SDK 오프보드 프로세스 다음 단계에 따라 허브를 오프보드합니다. ### hub\_managed\_thing ID 검색 `iotmi_config.json` 파일은 관리형 통합 허브의 관리형 사물 ID를 저장하는 데 사용됩니다. 이 식별자는 허브가 AWS IoT Managed Integrations 서비스와 통신할 수 있도록 하는 중요한 정보입니다. 관리형 사물 ID는 JSON 파일의 **rw**(읽기-쓰기) 섹션 내 `managed_thing_id` 필드 아래에 저장됩니다. 이는 다음 샘플 구성에서 볼 수 있습니다. ``` { "ro": { "iot_provisioning_method": "FLEET_PROVISIONING", "iot_claim_cert_path": "{{PATH}}", "iot_claim_pk_path": "{{PATH}}", "UPC": "{{UPC}}", "sh_endpoint_url": "{{ENDPOINT_URL}}", "SN": "{{SN}}", "fp_template_name": "{{TEMPLATENAME}}" }, "rw": { "iot_provisioning_state": "PROVISIONED", "client_id": "{{ID}}", "managed_thing_id": "{{ID}}", "iot_permanent_cert_path": "{{CERT_PATH}}", "iot_permanent_pk_path": "{{KEY}}", "metadata": { "last_updated_epoch_time": 1747766125 } } } ``` ### 오프보드 허브로 명령 전송 계정 자격 증명을 사용하고 이전 섹션에서 `managed_thing_id` 검색된 로 명령을 실행합니다. ``` aws iot-managed-integrations delete-managed-thing \ --identifier {{HUB_MANAGED_THING_ID}} ``` ### 허브가 오프보딩되었는지 확인 계정 자격 증명을 사용하고 이전 섹션에서 `managed_thing_id` 검색된 로 명령을 실행합니다. ``` aws iot-managed-integrations get-managed-thing \ --identifier {{HUB_MANAGED_THING_ID}} ``` ### 성공 및 실패 시나리오 #### 성공 시나리오 허브 오프보드 명령이 성공하면 다음 샘플 응답이 예상됩니다. ``` { "Message" : "Managed Thing resource not found." } ``` 또한 허브 오프보딩 명령이 성공하면 다음 샘플이 관찰`iotmi_config.json`됩니다. **rw** 섹션에 `iot_provisioning_state` 및 선택적으로 **메타데이터**만 포함되어 있는지 확인합니다. **메타데이터**의 부재는 허용됩니다.는 **NOT\_PROVISIONED**여야 `iot_provisioning_state` 합니다. ``` { "ro": { "iot_provisioning_method": "FLEET_PROVISIONING", "iot_claim_cert_path": "{{PATH}}", "iot_claim_pk_path": "{{PATH}}", "UPC": "1234567890101", "sh_endpoint_url": "{{ENDPOINT_URL}}", "SN": "1234567890101", "fp_template_name": "test-template" }, "rw": { "iot_provisioning_state": "NOT_PROVISIONED", "metadata": { "last_updated_epoch_time": 1747766125 } } } ``` #### 장애 시나리오 허브 오프보드 명령이 실패한 경우 다음 샘플 응답이 예상됩니다. ``` { "Arn" : "{{ARN}}", "CreatedAt" : 1.748968266655E9, "Id" : "{{ID}}", "ProvisioningStatus" : "DELETE_IN_PROGRESS", "Role" : "CONTROLLER", "SerialNumber" : "{{SERIAL_NO}}", "Tags" : { }, "UniversalProductCode" : "{{UPC}}", "UpdatedAt" : 1.748968272107E9 } ``` + **ProvisioningStatus**가 인 경우 [Hub 복구](#hub-recovery)의 지침을 `DELETE_IN_PROGRESS`따릅니다. + **ProvisioningStatus**가가 아닌 경우 허브를 오프보드하는 `DELETE_IN_PROGRESS`명령이 Managed Integrations 클라우드에서 실패했거나 Managed Integrations 클라우드에서 수신되지 않았습니다. [Hub 복구](#hub-recovery)의 지침을 따릅니다. + 오프보딩에 실패한 경우 `iotmi_config.json` 파일은 아래 샘플 파일과 같습니다. ``` { "ro": { "iot_provisioning_method": "FLEET_PROVISIONING", "iot_claim_cert_path": "PATH", "iot_claim_pk_path": "PATH", "UPC": "123456789101", "sh_endpoint_url": "ENDPOINT_URL", "SN": "123456789101", "fp_template_name": "test-template" }, "rw": { "iot_provisioning_state": "PROVISIONED", "client_id": "ID", "managed_thing_id": "ID", "iot_permanent_cert_path": "PATH", "iot_permanent_pk_path": "PATH", "metadata": { "last_updated_epoch_time": 1747766125 } } } ``` ## (선택 사항) 오프보딩 후 Hub SDK **중요** 다음 시나리오에서는 오프보딩 Hub SDK가 실패한 후 또는 오프보딩 후 허브를 다시 온보딩하려는 경우 수행할 선택적 작업을 나열합니다. **재온보딩** 오프보딩에 성공한 경우 [3단계: 관리형 사물 생성(플릿 프로비저닝)](managedintegrations-sdk-v2-cookbook-hubsetup.md#managedintegrations-sdk-v2-cookbook-managedthing) 및 나머지 온보딩 프로세스에 따라 Hub SDK를 온보딩합니다. **허브 복구** **디바이스 허브 오프보딩 성공 및 클라우드 오프보딩 실패** [ GetManagedThing](https://docs.aws.amazon.com/iot-mi/latest/APIReference/API_GetManagedThing) API 호출`iotmi_config.json`이 `Managed Thing resource not found` 메시지를 반환하지 않지만 파일이 오프보딩된 경우. 샘플 json 파일은 [성공 시나리오](#hub-offboarding-success-scenarios)를 참조하세요. 이 시나리오에서 복구하려면 [강제 삭제](#forced-deletion)를 참조하세요. **디바이스 허브 오프보딩 실패** 이 시나리오는 파일이 올바르게 오프보드되지 않는 경우`iotmi_config.json`입니다. 샘플 json 파일의 [실패 시나리오](#hub-offboarding-failure-scenarios)를 참조하세요. 이 시나리오에서 복구하려면 [강제 삭제](#forced-deletion)를 참조하세요. `iotmi_config.json`가 아직 오프보딩되지 않은 경우 허브를 공장 초기화해야 합니다. **디바이스 허브 오프보딩 및 클라우드 오프보딩 실패** 이 시나리오에서 `iotmi_config.json`는 여전히 오프보딩되지 않으며 허브 상태는 `ACTIVATED`또는 입니다`DISCOVERED`. 이 시나리오에서 복구하려면 [강제 삭제](#forced-deletion)를 참조하세요. 강제 삭제`iotmi_config.json`에 실패하거나 여전히 오프보딩되지 않는 경우 허브를 초기 기본값으로 재설정해야 합니다. **허브가 오프라인 상태이고 허브 상태가 DELETE\_IN\_PROGRESS임** 이 시나리오에서는 허브가 오프라인 상태이고 클라우드가 오프보딩 명령을 수신합니다. 이 시나리오에서 복구하려면 [강제 삭제](#forced-deletion)를 참조하세요. **강제 삭제** 성공적인 디바이스 허브 오프보딩 없이 클라우드 리소스를 삭제하려면 다음 단계를 따르세요. 이 작업을 수행하면 클라우드와 디바이스 상태 간에 불일치가 발생하여 향후 운영에 문제가 발생할 수 있습니다. 허브의 `managed_thing_id` 및 **force** 파라미터를 사용하여 [ DeleteManagedThing ](https://docs.aws.amazon.com/iot-mi/latest/APIReference/API_DeleteManagedThing) API를 호출합니다. ``` aws iot-managed-integrations delete-managed-thing \ --identifier {{HUB_MANAGED_THING_ID}} \ --force ``` 그런 다음 [ GetManagedThing ](https://docs.aws.amazon.com/iot-mi/latest/APIReference/API_GetManagedThing) API를 호출하고를 반환하는지 확인합니다`Managed Thing resource not found`. 이렇게 하면 클라우드 리소스가 삭제됩니다. 클라우드 상태와 디바이스 상태 간에 불일치가 발생할 수 있으므로이 접근 방식은 권장되지 않습니다. 일반적으로 클라우드 리소스를 삭제하기 전에 성공적인 디바이스 허브 오프보딩을 보장하는 것이 좋습니다.