Una de las nuevas características más interesantes de Couchbase Server 2.0 es la adición de Cross Data Center Replication (XDCR). Usando esta característica puedes aumentar la fiabilidad de tu aplicación operando en múltiples centros de datos y mejorar el rendimiento para tus usuarios almacenando sus datos más cerca de su ubicación física.
Empezar a utilizar la replicación entre centros de datos es fácil, y Amazon EC2 es un buen lugar para probarlo.
Infraestructura
En primer lugar, necesitaremos 2 clusters de Couchbase en regiones separadas. Yo he elegido usar las regiones de US East (N. Virginia) y US West (N. California). En cada región he aprovisionado 2 servidores (m1.large) ejecutando la AMI estándar de Amazon Linux. Una vez aprovisionados los servidores, tendrás que instalar Couchbase Server 2.0 beta en cada servidor.
IMPORTANTE: Hay un cambio sustancial que debe hacerse en cada servidor. Por defecto, Couchbase Server identificará la dirección IP local del servidor y la usará para todas las comunicaciones del cluster. Esto funciona bien dentro de la región, pero no funcionará a través de Internet. Para solucionar este problema, configuraremos Couchbase para que utilice explícitamente el nombre DNS público proporcionado por Amazon para cada servidor. Esto resolverá correctamente a la dirección IP interna para la comunicación intra-clúster y a la dirección IP pública para la comunicación inter-clúster.
- Detener el servidor
sudo /etc/init.d/couchbase-server stop
- Edite el archivo /opt/couchbase/bin/couchbase-server
- Encuentra la última línea en la sección _start
- Añade un " al final de la línea
…
- Añade una nueva línea inmediatamente después que diga:
-nombre ns_1@
- Borra los archivos bajo:
- /opt/couchbase/var/lib/couchbase/data/*
- /opt/couchbase/var/lib/couchbase/mnesia/*
- /opt/couchbase/var/lib/couchbase/config/config.dat
- Iniciar el servidor
sudo /etc/init.d/couchbase-server start
Una buena manera de comprobar que tus servidores han sido configurados correctamente con su nombre DNS público es mirar en la pestaña Servidor en la interfaz de usuario de Couchbase Server. Deberías ver los servidores listados con sus nombres DNS, si ves sus direcciones IP privadas vuelve a comprobar los pasos anteriores.
Cargar conjunto de datos de muestra
Para que tengamos algunos documentos que replicar, cargaré el conjunto de datos de la muestra de cerveza en el clúster de la costa este.
$ ./cbdocloader -u Administrador -p contraseña -b por defecto -n 127.0.0.1:8091 ../../muestras/muestra-cerveza.zip
{'username': 'Administrator', 'node': '127.0.0.1:8091', 'password': 'Couchbase', 'bucket': 'default', 'ram_quota': 100} ['../../samples/beer-sample.zip']
[2012-10-09 14:29:02,833] - [rest_client] [140174671374080] - INFO - cubos existentes : [u'default']
[2012-10-09 14:29:02,834] - [rest_client] [140174671374080] - INFO - encontrado cubo por defecto
trabajar con beer.json
trabajando con 110fa32467.json
trabajando con 110fe062a9.json
...salida larga omitida...
trabajando con 110f179fca.json
trabajando con 110f25fe73.json
Ver: _diseño/cerveza/vista/cervecería_cervezas
Ver: _diseño/cerveza/vista/por_ubicación
Ve al Oeste, jóvenes documentos
Empecemos con una replicación unidireccional desde el cluster de la costa este al cluster de la costa oeste. Navegaré a la pestaña XDCR de mi cluster de la costa este. Pulsa el botón "Create Cluster Reference". En el campo IP/hostname asegúrate de utilizar el nombre DNS público de uno de los servidores del cluster remoto.
Ahora pulsa el botón "Crear replicación". Seleccione el bucket "por defecto", el clúster "WestSide" y escriba "por defecto" para el clúster remoto.
No se alarme, la columna de estado seguirá diciendo "Starting Up", eso es normal. En este momento, todos los documentos del clúster de la costa este se replicarán en el clúster de la costa oeste.
Ahora vamos a la pestaña "Cubos de datos". Haga clic en el cubo "por defecto". Desplácese hacia la parte inferior y expanda la sección "Replicación saliente".
Inicialmente la cola de cambios será alta, y los documentos comprobados y replicados serán 0. A medida que la replicación avanza, la cola de cambios se drenará a 0 y los documentos comprobados y replicados se asentarán en el recuento total de documentos. Este es el aspecto que tiene cuando termina de replicar los documentos (NOTA: Las réplicas de XDCR son continuas, aunque haya terminado de replicar todos los cambios hasta el momento, continuará ejecutándose y transfiriendo futuros cambios)
Echemos un vistazo al cluster de la costa oeste en la interfaz de usuario de Couchbase Server.
El recuento de documentos en el bucket por defecto coincide con el valor del clúster de la costa este. La replicación entre centros de datos funciona.
Viaje de ida y vuelta
Muchos casos de uso requieren replicación bidireccional, así que vamos a configurar la replicación desde la costa oeste a la costa este. Los pasos son los mismos que antes, sólo cambian los nombres de clúster y DNS. De nuevo, asegúrate de utilizar los nombres DNS públicos de los servidores de Amazon.
Para comprobar que la replicación bidireccional funciona, debemos realizar un cambio en los datos de este lado.
Después de mi presentación en la CouchConf SF, recibimos un tweet de @PabstBlueRibbon informándonos de que nuestro conjunto de datos de muestras de cerveza necesita una actualización.
Así que vamos a ocuparnos de eso ahora. En nuestro conjunto de datos el valor actual es 0. Voy a editar el documento con ID 110fa43a2e y cambiarlo a 12.
Después de guardar el cambio, si miramos las estadísticas del cubo en el clúster de la costa oeste, veremos que el cambio se está replicando.
Observe como la cola de cambios subió brevemente a 1, y vemos que el documento 1 fue replicado. También vale la pena observar que aunque ha comprobado todos los documentos sólo ha replicado el que ha cambiado, esto demuestra que XDCR está comprobando las revisiones y sólo replica los datos necesarios.
Ahora vamos a cargar el documento en el cluster de la costa este para verificar que ha funcionado.
Funcionó, ¡el ibu muestra el valor 12 en ambos clusters!
Buenas prácticas
He intentado que los ejemplos sean sencillos, pero hay dos cuestiones que debes tener en cuenta antes de ponerlo en práctica.
Nombres de servidores
En este ejemplo he utilizado directamente los nombres DNS públicos de la instancia EC2. Esto no es recomendable en producción porque las direcciones IP de las instancias de Amazon (y sus nombres DNS públicos asociados) pueden cambiar. Recomendamos una de estas dos opciones:
- Utilice un servicio DNS dinámico de terceros. Cada vez que cambie la dirección IP del servidor, actualiza un registro CNAME que apunte al nombre DNS público de tu servidor. Es importante que sea un registro CNAME y que apunte al nombre DNS público porque necesita que la dirección se resuelva a la dirección correcta tanto dentro como fuera de Amazon.
- Utilice un Dirección IP elástica de Amazon. No cuestan dinero extra (cuando están en uso), pero es posible que tengas que pedir más a Amazon.
Seguridad de los datos
Los datos transferidos por XDCR se envían sin cifrar y cuando se replican entre regiones de Amazon esto significa que están transitando por la Internet pública.
- Puedes utilizar XDCR para conectar clusters en diferentes zonas de disponibilidad sin transitar por la Internet pública. Esto no ofrece tanta fiabilidad, pero evita el posible problema de seguridad.
- Puede utilizar un Servicio VPN de terceros para tunelizar datos entre tus regiones de Amazon.
Más información
Esperamos que este tutorial haya mostrado cómo puedes tener XDCR funcionando en cuestión de minutos en AWS. Para más información sobre Couchbase XDCR ver:
- Inscríbase para asistir al Webinar XDCR el 17 de octubre
Muchas gracias.
¿Necesitamos hacer esta configuración -name ns_1@, si estamos usando Couchbase 2.2? Por favor, hágamelo saber
Tienes razón, ya no es necesario editar este script. Cuando se configura inicialmente el nodo, la interfaz de usuario de Couchbase ahora te permite proporcionar el nombre de host deseado para el nodo. Puedes ver esta configuración descrita en esta sección del manual: https://docs.couchbase.com/couc…
Debe seguir las mismas directrices que se explican en esta entrada del blog para establecer este valor.
Gracias.
¿Esta prueba se realiza con replicación síncrona o asíncrona? La captura de pantalla no muestra una configuración para elegir el tipo de replicación.
La replicación XDCR es siempre asíncrona.
Hola,
Estoy recibiendo un error como "Atención - No se pudo conectar a "104.155.232.39" en el puerto 9092. Esto podría ser debido a una combinación incorrecta de host / puerto o un firewall en el lugar entre los servidores.\ ", mientras que la creación de replicación. ¿Puede alguien ayudarme?