IoT Platform:Requisitos previos

Límites

Antes de empezar

Antes de realizar la migración, revise la siguiente información para evaluar el impacto en su negocio.

• Datos por migrar:

  Al migrar una instancia pública, IoT Platform sincroniza y migra automáticamente los productos, dispositivos y datos de reenvío de mensajes. La siguiente tabla describe los datos migrados.

  Elemento de datos	Datos migrados	Notas
  Producto	Información del producto: ProductKey, nombre, tipo de nodo, categoría, entre otros. Definiciones de funciones: Propiedades, servicios, eventos y modelos extendidos de Thing Specification Language (TSL), incluidos los datos de modelos TSL en borrador. Scripts: Scripts de análisis de datos, incluidos los datos de scripts en borrador.	La migración admite productos y dispositivos que utilizan certificados por dispositivo o por producto para la autenticación de prerregistro. En el caso de subdispositivos de gateway, la relación topológica permanece sin cambios durante la migración. Después de esta, pueden conectarse a IoT Platform con normalidad. Por lo tanto, si migra un dispositivo gateway o sus subdispositivos, debe migrarlos juntos a la misma instancia Enterprise. No es posible migrar productos ni dispositivos autorizados. La función de autorización para productos y dispositivos no es compatible con instancias Enterprise. No se pueden migrar productos y dispositivos que utilizan DataService Studio. No se pueden migrar productos y dispositivos con el servicio de video habilitado. No se pueden migrar productos y dispositivos conectados a IoT Edge o Link WAN. Después de la migración, el tipo de validación del modelo TSL del producto permanece sin cambios. Tras la migración, los datos originales se conservan en la instancia pública heredada. Para evitar operaciones accidentales, elimine manualmente estos datos una vez completada la migración de la instancia y tras confirmar que sus servicios funcionan correctamente.
  Dispositivo	Información del dispositivo: Información del certificado del dispositivo. Se garantiza que el certificado del dispositivo sea único a nivel global. Datos del dispositivo: Datos de propiedades, eventos y servicios del modelo TSL.	Importante No se pueden migrar los dispositivos distribuidos bajo la instancia. Los dispositivos por migrar deben contar con una función de reconexión. Debe completar el desarrollo del SDK del lado del dispositivo y conectarlo a IoT Platform para garantizar una comunicación normal. Nota Si utiliza el Link SDK proporcionado por IoT Platform para desarrollar el dispositivo, este se conectará automáticamente a la instancia Enterprise. No es necesario modificar el nombre de dominio de conexión del dispositivo. Para obtener más información sobre Link SDK, consulte Device connection. Si no utiliza el SDK del lado del dispositivo proporcionado por IoT Platform, deberá modificar el nombre de dominio de conexión del dispositivo y desarrollar su propia lógica de reconexión. Durante la migración, si un dispositivo está en línea, se forzará su desconexión. Después de la migración, los dispositivos migrados se eliminan automáticamente de la instancia pública heredada. No es necesario modificar el SDK del lado del dispositivo. Los dispositivos podrán conectarse correctamente a la instancia Enterprise de destino y comunicarse con normalidad. Solo los usuarios incluidos en la lista blanca pueden migrar dispositivos que utilizan autenticación basada en ID². Puede submit a ticket para solicitar permiso de inclusión en la lista blanca. Para obtener más información sobre la autenticación basada en ID², consulte ID²-authenticated devices. Instrucciones para la migración de datos del modelo TSL: De forma predeterminada, la sincronización de datos está deshabilitada. Tras crear la tarea de migración, puede habilitar manualmente la sincronización de datos para asegurar que sus servicios no se vean afectados durante la migración de la instancia. Al habilitar la sincronización de datos, los datos reportados por los dispositivos del producto a migrar en la instancia pública se sincronizan con la instancia Enterprise de destino. La sincronización comienza con un retraso máximo de 1 minuto. A partir del día en que habilite la sincronización, los datos se pueden sincronizar durante un máximo de 30 días. Puede deshabilitar y volver a habilitar manualmente la función de sincronización de datos del dispositivo. Si no la deshabilita manualmente, el sistema desactivará la sincronización automáticamente después de 30 días. Antes de que se deshabilite la sincronización, asegúrese de completar la migración de la instancia para evitar afectar los servicios relacionados. La sincronización de datos es unidireccional. Solo admite la sincronización de datos reportados por los dispositivos del producto a migrar desde la instancia pública hacia la instancia Enterprise. Cuando la sincronización de datos está habilitada, si un dispositivo se revierte desde la instancia Enterprise a la instancia pública, los datos migrados del dispositivo no se revierten. Cuando el dispositivo se migra nuevamente a la instancia Enterprise, los datos en dicha instancia estarán completos, pero los datos en la instancia pública estarán incompletos.
  Reenvío de mensajes	Suscripción del lado del servidor: Configuraciones y relaciones de suscripción del lado del servidor AMQP y MNS. Reenvío de datos: Reglas de reenvío, incluida la configuración SQL, orígenes de datos, destinos de datos como RocketMQ, TSDB, RDS y FC, así como scripts de análisis. Grupos de consumidores: Información del grupo de consumidores. Después de la migración, se crea un nuevo ID de grupo de consumidores.	Después de la migración, los datos originales se conservan en la instancia pública heredada. Para evitar operaciones accidentales, elimine manualmente estos datos una vez completada la migración de la instancia y tras confirmar que sus servicios funcionan correctamente. Si configuró una suscripción del lado del servidor AMQP o reenvío de mensajes a AMQP, debe iniciar dos clientes AMQP. Esto garantiza que tanto la instancia pública como la instancia Enterprise tengan un cliente AMQP para recibir datos, lo cual previene la pérdida de información. Las instancias Enterprise no admiten la suscripción del lado del servidor mediante HTTP/2. Cambie el método de suscripción del lado del servidor de HTTP/2 en la instancia pública original a AMQP.

• Uso de funciones:

  Una vez migrados los dispositivos a la instancia Enterprise de destino, podrá continuar utilizando las configuraciones migradas. Para usar funciones adicionales, puede reconfigurarlas en la instancia Enterprise. Para obtener más información sobre el uso de funciones, consulte Feature usage after migration.

• Facturación:

  Para los dispositivos migrados a una instancia Enterprise, dejará de facturársele por comunicación de mensajes, duración de conexión o actualizaciones over-the-air (OTA).

Preparativos antes de la migración

Evalúe el impacto comercial y modifique sus sistemas empresariales antes de migrar la instancia para garantizar que los dispositivos se comuniquen correctamente después de la migración.

Flujo general de migración

El flujo de migración de instancias consta de las siguientes cuatro partes.

Procedimiento de migración

1. Step 1: Create a migration task. Agregue una tarea de migración para un producto específico.

   Importante

   Para garantizar que sus servicios no se vean afectados durante la migración de la instancia, puede habilitar manualmente la sincronización de datos después de crear la tarea de migración. Esta acción migra los datos reportados por los dispositivos del producto a migrar desde la instancia pública hacia la instancia Enterprise de destino. Para obtener más información, consulte Enable data synchronization.

2. Step 2: Perform a grayscale migration. Copie secuencialmente los datos del producto y de reenvío de mensajes, y luego migre los datos de los dispositivos específicos en la fase gradual.

   Aviso

   Si configuró una suscripción del lado del servidor AMQP o reenvío de mensajes a AMQP, debe copiar y actualizar el ID del grupo de consumidores e iniciar el nuevo SDK del cliente AMQP para recibir datos una vez completada la migración gradual.

   Supervise la tarea y asegúrese de que la migración no afecte sus servicios antes de proceder con la migración completa.

3. Step 3: Perform a full migration. Consulte todos los datos bajo el producto especificado y migre todos los datos de los dispositivos.

   Aviso

   Asegúrese de que la refactorización del sistema esté completa y publicada. Por ejemplo, las llamadas a las API en la nube deben incluir el ID de la instancia Enterprise y el ID del grupo de consumidores en el SDK del cliente AMQP debe estar actualizado. Para obtener más información, consulte Preparations before migration.

   Una vez completada la migración total, compruebe el estado y los resultados de ejecución del servicio para garantizar que las llamadas a las API en la nube se hayan redirigido a la instancia Enterprise de destino.

4. Optional: Roll back the migration task. Si la migración falla o surge algún problema, puede revertir todos los datos migrados del dispositivo, como la información del certificado y los datos del modelo Thing Specification Language (TSL), a la instancia pública para restaurar el funcionamiento normal. Esta operación no elimina los datos de suscripción del lado del servidor ni de reenvío de mensajes migrados de la instancia Enterprise de destino.

Referencias

• Instance migration best practices

• Instance migration FAQ

Preguntas frecuentes

Antes de la migración

• What do I need to know when migrating a legacy public instance to an Enterprise instance?

• Does migrating a legacy public instance to an Enterprise instance consume the resource specifications of the Enterprise instance?

• Can I migrate a legacy public instance of IoT Platform from one account to an Enterprise instance of another account?

• Can I migrate an IoT Platform Enterprise instance? If so, how?

• When migrating an IoT Platform public instance to an Enterprise instance, can OTA update packages be migrated as well?

• Can authorized products and devices in a legacy public instance be migrated to an Enterprise instance?

• Can a legacy public instance be migrated to all types of Enterprise instances?

• Does the migration of a legacy public instance support cross-region or cross-account migration to an Enterprise instance?

Durante la migración

• What does grayscale migration mean in the context of instance migration?

• When migrating a legacy public instance to an Enterprise instance, do I need to create products and devices and configure message forwarding in the Enterprise instance first?

• Will migrating a legacy public instance affect connected devices?

Después de la migración

• After a grayscale migration of legacy public instances, the migration details page does not display any devices or migration information

• Do I need to update the connection domain name after migrating a legacy public instance?

• After a legacy public instance is successfully migrated, do server-side calls to cloud APIs need to include the ID of the Enterprise instance?