Capella App Services es un backend en la nube totalmente gestionado para sus aplicaciones frontales móviles, de escritorio e IoT. En el otro extremo del espectro, el paradigma de "Edge Computing ha ganado mucha tracción en los últimos años. La informática de borde es una topología informática distribuida que pretende acercar la computación y el almacenamiento al borde, que es esencialmente el lugar donde se generan y consumen los datos. Las aplicaciones que se ejecutan en el perímetro se benefician de respuestas en tiempo real de baja latencia, costes reducidos de ancho de banda de red a la nube y cumplimiento de las restricciones de privacidad de datos y normativas que prescriben que los datos sensibles se procesen en el perímetro.
Edge Computing complementa a Cloud Computing. La nube sigue siendo la fuente de la verdad. Los datos procesados en el perímetro se transmiten a la nube para garantizar su coherencia e integridad. Entonces, ¿cómo habilitamos una topología de despliegue de este tipo que combine la potencia del entorno de nube gestionada de Capella con el despliegue de borde autogestionado on-prem? Esto es posible con el Replicación Inter-Sync Gateway que ofrece sincronización escalable y segura de nivel empresarial entre la nube de couchbase y los clústeres de borde.
En este post, vamos a ver un ejemplo de cómo se puede configurar un despliegue híbrido entre un despliegue gestionado por Capella App Services y un despliegue autogestionado de Couchbase Mobile.
Topología de implantación híbrida y casos de uso
En el contexto de este post, utilizamos la topología de despliegue híbrido para referirnos a una topología que consiste en un Capella App Services totalmente gestionado que sincroniza datos con uno o más clústeres móviles couchbase autogestionados. Un clúster móvil de couchbase autogestionado podría ser uno desplegado y gestionado por un usuario en una nube pública, una nube privada o un centro de datos, o bien on-prem. A continuación se muestra una topología híbrida sencilla. En este modelo, los datos se almacenan y procesan en Capella App Services, así como en el clúster móvil couchbase autogestionado. Los datos se sincronizan entre la nube y el clúster de borde utilizando Inter-Sync Gateway Replication. Las aplicaciones cliente móviles y de escritorio pueden sincronizar los datos con Capella App Services o con el clúster autogestionado Couchbase Mobile.
Existen varios casos de uso de las implantaciones distribuidas en la nube, como se describe en este libro blanco. Entre ellas figuran la resistencia a las interrupciones de Internet y la reducción de la latencia en el procesamiento de datos.
En concreto, la topología de despliegue híbrida ofrece las siguientes ventajas :-
-
- Privacidad y gobernanza de datos: Cumplimiento de las políticas normativas que dictan que los datos sensibles sólo deben almacenarse y procesarse en centros de datos autogestionados, privados u on-prem.
- Migración gradual a Capella: No es tan obvio, pero la topología híbrida con Capella simplificará la migración de las implantaciones móviles on-prem de Couchbase existentes a Capella. Mientras que Migración basada en XDCR permite una migración de una sola vez de clústeres móviles on-prem a Capella App Services, en la que todos los clientes tienen que cambiar del clúster autogestionado a Capella. Por otro lado, una topología híbrida con una replicación bidireccional Inter-Sync Gateway permitirá una migración por fases, permitiendo a los clientes migrar a lo largo del tiempo.
- Servicios de borde de proveedores de nube emergentes: A medida que los proveedores de servicios en la nube siguen ampliando su infraestructura a los extremos con ofertas como Zonas locales de AWS, los usuarios pueden aprovechar estas ofertas conectando sus clústeres móviles couchbase autogestionados desplegados en el borde de la red del proveedor de la nube con Capella App Services.
Configuración
Clúster activo
El clúster de Sync Gateway en el que se inicializa o programa la replicación es el Clúster activo. Piensa que es equivalente a un cliente en una conexión cliente-servidor clásica que está inicializando una conexión. En un despliegue híbrido, esto correspondería al cluster autogestionado de Couchbase Mobile. En otras palabras, todas las réplicas (bidireccionales y unidireccionales) se inicializan en el lado autogestionado.
Clúster pasivo
El clúster de Sync Gateway que es el objetivo de la replicación es el Clúster pasivo. Piense que equivale a un servidor en una conexión cliente-servidor clásica que está a la escucha de conexiones entrantes.
Recorrido
Recorreremos un ejemplo sencillo que demuestra cómo puede configurar una topología híbrida con Capella App Services. En aras de la brevedad, no vamos a caminar a través de los detalles de cómo implementar y aprovisionar Sync Gateway on-prem o en Capella App Services. Si usted es nuevo en Capella App Services, por favor refiérase a la Primeros pasos con App Services guía. Si es la primera vez que utiliza Couchbase Mobile, consulte Primeros pasos con Sync Gateway guía.
Estado inicial
Con el fin de apoyar el despliegue híbrido con Capella App Services, el Clúster activo que es la agrupación móvil autogestionada DEBE estar ejecutando las versiones v3.0.5 y v2.8.4 de Sync Gateway.
Clúster autogestionado
Esta es la configuración de la base de datos de Sync Gateway en el lado autogestionado de la implantación, tal y como se recupera utilizando GET db llamar.
Solicitar
|
1 2 3 4 |
rizo --ubicación --solicitar GET https://on-prem-syncgateway:4985/travel-sample/_config \ --cabecera 'Accept: application/json' \ --cabecera Content-Type: application/json' \ --cabecera 'Autorización: Basic c2d3X2FkbWluOnBhc3N3b3Jk' |
Respuesta
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
{ "servidor": "couchbases://on-prem-couchbase-server", "cubo": "viaje-muestra", "nombre de usuario": "sgw_admin", "contraseña": "xxxxx", "nombre": "viaje-muestra", "sync": "\nfunction sync(doc, oldDoc) {\n if (doc.type) {\n channel(\"channel.\"+doc.type);\n }\n else {\n channel(\"!\");\n }\n"}, "importar_docs": verdadero, "caché": { "rev_cache": {}, "channel_cache": {} }, "sin soporte": { "umbrales_aviso": { "xattr_size_bytes": 943718, "canales_por_doc": 50, "access_and_role_grants_per_doc": 50, "canales_por_usuario": 50000, "canal_nombre_tamaño": 250 } }, "enable_shared_bucket_access": verdadero, "num_index_replicas": 0, "delta_sync": { "activado": verdadero } } |
Como puede ver, la configuración es sencilla.
-
- Tengo una base de datos Sync Gateway llamada "viaje-muestra" respaldado por un "viaje-muestra"en el servidor Couchbase. El bucket "travel-sample" es un bucket de muestra que se carga en el servidor.
- "sgw_admin"es el usuario de la puerta de enlace de sincronización que se utiliza para autenticar la puerta de enlace de sincronización con el servidor Couchbase.
- La función de sincronización hace lo siguiente:
- Todos los documentos que tienen un "tipo"se asignan a un canal correspondiente a ese tipo de documento. Por ejemplo, los documentos que tienen una propiedad "tipo": "compañía aérea" se asignan a un canal denominado "channel.airline", un documento que tiene un "tipo": "aeropuerto" se asignan a un canal denominado "canal.aeropuerto" etc.
- Los documentos que no tienen " tipo"se asignan a un canal público.
El resto de la configuración es por defecto.
Capella App Services
Esta es la configuración en el lado de Capella App Services.
Tengo un Punto final de la aplicación nombrado "viaje-muestra" que está respaldada por una base de datos de "viajes-muestra". En mi ejemplo, la base de datos "viaje-muestra"La base de datos vacío.
En Función de control de acceso es idéntica a la función de sincronización en el lado autogestionado.
Tengo un Usuario de la aplicación nombrado "demo@example.com"que tiene acceso a "canal.aerolínea"(además del canal público "!" del sistema).
Configuración de la replicación de Inter-Sync Gateway
El clúster móvil autogestionado de Couchbase es el "clúster activo" y es el clúster en el que las réplicas DEBE inicializarse.
Inicializaré una replicación bidireccional y continua llamada "pushandpull-with-target-continuous" en el Sync Gateway autogestionado mediante la función PUT _replicación API.
Solicitar
Validación de la sincronización de datos
Por último, dado que tenemos una configuración de sincronización bidireccional entre Capella App Services y un clúster autogestionado, puedo validar que los cambios de documentos realizados en cualquiera de los puntos finales se sincronizan en el otro lado.
Sincronización del clúster autogestionado Couchbase Mobile con Capella App Services
Los cambios realizados en cualquier documento autogestionado se sincronizan automáticamente con la nube, como se muestra a continuación. Esto se debe a que no tenemos ningún filtro establecido en la replicación.
Los cambios en el documento del servidor Couchbase autogestionado (derecha) se sincronizan con Capella (izquierda).
Sincronización desde capella App Services al clúster autogestionado Couchbase Mobile
Por el contrario, sólo los cambios realizados en documentos que tengan una propiedad "tipo"de "aerolínea"en Capella App Services se sincronizan con el clúster autogestionado. Esto se debe a que el usuario de la aplicación en Capella App Services, "demo@example.com" sólo tiene acceso al "channel.airline". Así, el usuario de la aplicación sólo puede leer documentos de "tipo"igual a"aerolínea“.
Los cambios en el documento de Capella (izquierda) se sincronizan con el servidor Couchbase autogestionado (derecha).
Supervisión de las réplicas
Una vez que sus configuraciones estén en funcionamiento, puede supervisarlas a través de la función replicationStatus punto final.
Recursos
Puede Pruebe Capella App Services gratis hoy mismo y despliegue topologías híbridas con clústeres de borde autogestionados.
Asegúrese de implantar las versiones v3.0.5 o v2.8.4 de Sync Gateway, que puede descargar desde nuestro página de descargas.
Si quiere profundizar en los detalles, aquí encontrará más información:
En Foros de Couchbase es un buen lugar para plantear preguntas. Por favor, deje un comentario a continuación o no dude en ponerse en contacto conmigo a través de Twitter o envíame un correo electrónico
Agradecimientos
Me gustaría dar las gracias a Mark Gamble por su revisión y comentarios sobre la entrada del blog.
