En nuestra serie de formación continua, cada vez surgen una serie de preguntas, que enumero a continuación con sus respectivas respuestas.
Couchbase 101 - Arquitectura, instalación y configuración
Mi generador de carga basado en Ruby puede descargarse aquí: https://github.com/scalabl3/ruby-couchbase-loadgen
P: Estamos utilizando la versión 2.0 en producción, ¿cuál es la mejor práctica para actualizar a la 2.2?
R: Puede actualizar su clúster de tres formas diferentes. La primera es la actualización en línea Swap Rebalance y es una gran manera de mantener el tiempo de actividad de tu cluster mientras lo actualizas. Para hacer un swap rebalance, añades un número igual de nodos nuevos ejecutando Couchbase 2.2 que el tamaño actual de tu cluster, pero antes de rebalancear, quitas los nodos Couchbase 2.0. Cuando reequilibres, ya que estás añadiendo y quitando el mismo número de nodos, será lo más eficiente. Lee más sobre esto aquí: http://docs.couchbase.com/couchbase-manual-2.0/#swap-rebalance También puedes hacer una actualización offline usando cbbackup/cbrestore desde el cluster antiguo al nuevo, o puedes usar cbtransfer (¡pero tienes que cesar las operaciones que crean datos antes de transferir!)
P: ¿Couchbase Server es gratuito o se necesitan licencias?
R: Couchbase Community es gratis para desarrollo y producción para cualquier número de nodos. Couchbase Enterprise es gratis para desarrollo, cualquier número de nodos, y hasta 2 en producción. Más de 2 nodos en producción requiere licencia, ¡pero nuestra licencia también incluye Soporte Empresarial!
P: ¿Los servidores de aplicaciones son dispositivos físicos o pueden ser máquinas virtuales?
R: Tanto los servidores de aplicaciones como los servidores Couchbase pueden ser máquinas físicas o virtuales.
P: ¿Podría utilizarse Couchbase como alternativa a Clearquest/Clearcase o este producto se utiliza estrictamente para el control de documentos?
R: Couchbase es un almacén de datos sobre el que se construyen aplicaciones, Clearquest/Clearcase son aplicaciones que se basan en almacenes de datos, por lo que la comparación con Couchbase no es realmente "de igual a igual".
P: ¿Se puede monitorizar Couchbase con SNMP? ¿Es posible integrar la monitorización de Couchbase con Solarwinds?
R: Puedes usar SNMP para monitorizar el servidor como cualquier otra máquina, pero Couchbase no tiene integración SNMP por ahora. Hasta donde yo sé, no tengo conocimiento de una integración estándar con Solarwinds, pero imagino que no sería difícil si se puede extender Solarwinds para sondear http/JSON para obtener información y tener disparadores personalizados.
P: ¿Soporta couchbase la conmutación por error a un nodo couchbase en espera? Cómo se sincronizarán los datos almacenados con un clúster couchbase en espera?
R: No tenemos un auto-failover a un nodo standby, principalmente porque el failover implica la promoción de particiones réplica a particiones activas. Si tuvieras que usar un nodo standby tendrías que tener una copia de todos los datos del cluster en él porque no sabes qué nodo (y qué particiones) van a ser inaccesibles/fallar. Esto no tendría sentido, en su lugar tenemos particiones réplica, y en el caso de un fallo, la conmutación por error promoverá las particiones réplica para que estén activas. Si estás manteniendo un cluster separado en standby (y usando Cross Data Center Replication (XDCR) para replicar los datos de tu cluster activo), tendrías que programar tu propia lógica para decidir cuando intercambiar clusters.
P: ¿Puede el sistema CB automatizar los valores de los metadatos (es decir, los identificadores) (por ejemplo, el recuento automático de identificadores), o transfiere esa responsabilidad a la aplicación?
R: Todos los id's (claves) son responsabilidad de la aplicación, no hay mecanismos incorporados en Couchbase para generar ID's. Sin embargo, puedes usar Contadores Atómicos para actuar como columnas IDENTITY en RDBMS's. Echa un vistazo al webinar Couchbase 103 para más información sobre algunos patrones.
P: ¿Podemos almacenar mp3 o cualquier archivo de Audio o Video en Couchbase?
R: Por supuesto que puedes almacenar cualquier cosa en Couchbase, tipos de datos simples, JSON y datos binarios de cualquier tipo (MP3, JPEG, PNG, etc.). Sólo estás limitado por un límite de 20MB por "documento". Sin embargo, los archivos de vídeo tienden a ser bastante grandes, en cuyo caso, sería mejor utilizar un sistema CDN diseñado para archivos de gran tamaño y transmitirlos a grandes audiencias, y almacenar los metadatos de activos para el archivo (como su título, url para transmitirlo, etc.) en Couchbase.
P: ¿Cuánta RAM debemos dejar para el sistema operativo?
R: Depende, si estás usando mucho Views entonces sería prudente asignar más RAM para la caché del sistema de archivos. Generalmente recomendamos dejar alrededor de 40% de RAM disponible para el sistema operativo (así que configura Couchbase para usar 60%) y eso da un buen rendimiento en general. Si no estás usando Views entonces puedes asignar más RAM a Couchbase. Puede ser bueno hacer referencia a las directrices de dimensionamiento en esta entrada del blog: https://www.couchbase.com/blog/how-many-nodes-part-1-introduction-sizing-couchbase-server-20-cluster
P: ¿Qué es un número elevado de OPS en un sistema de 16 GB y 4 núcleos?
R: Otro "depende", va a estar fuertemente influenciado por la velocidad de la red y la capacidad de enviar operaciones binarias a través del cable a Couchbase. Una caja de 16GB y 4 núcleos en Amazon AWS no será lo mismo que una caja física conectada al generador(es) de carga con 10GigE's. No verás este tipo de rendimiento, https://www.couchbase.com/blog/understanding-performance-benchmark-published-cisco-and-solarflare-using-couchbase-server ¡en AWS! Pero esto demuestra que no es realmente Couchbase en sí lo que limita las operaciones, sino más bien la red y la capacidad de entregar operaciones a Couchbase a través de los sockets binarios.
P: ¿Cuántas réplicas recomiendan?
R: Generalmente la mayoría de la gente se siente cómoda con 1 réplica, sin embargo hay algunos que quieren la seguridad de 2 réplicas, no conozco ningún cliente que utilice 3 réplicas. Por supuesto que necesita reforzar sus servidores para más réplicas con más RAM asignada y potencialmente CPU también si va a indexar las réplicas también. En última instancia, esa decisión tiene que ser suya, ya que usted es el más consciente de los datos y la importancia de asegurar los datos contra cualquier pérdida de datos, etc.
P: Para las conexiones cliente sdk, ¿hay que añadir manualmente todas las ips del servidor?
R: Hay un número de maneras de manejar esto, a través de DNS, por ejemplo, donde usted tiene sus servidores de aplicaciones siempre se conectan a un CNAME o un registro A, y la lista de todas las máquinas de clúster (o auto-registro) con el registro A. O puedes poner las IP's en un archivo de configuración que se actualiza a través de los servidores (o localizado centralmente), o escribir las IP's en el código de inicio de tu aplicación, etc.
P: En cuanto al sistema operativo, está disponible para Ubuntu. ¿Hay algún problema si se utiliza otra distribución como Debian?
R: Creo que está bien, pero no lo he probado personalmente. Los sistemas operativos que están listados en la página de descargas son también los que están más probados. Sé que uno de nuestros ingenieros consiguió que Couchbase funcionara en Joyent SmartOS, pero no es una descarga oficial, etc.
P: ¿No persisten los metadatos?
R: Los metadatos también se almacenan en disco, por supuesto, pero también se almacenan en disco. también se mantiene siempre en la RAM. Los documentos estarán en RAM si hay suficiente RAM disponible en el cubo (en todo el cluster) para contener los valores. Si no es así, se utiliza la opción No Utilizado Recientemente (NRU) para expulsar el documento. valores al disco.
P: ¿Para qué sirven los trabajadores IO? ¿Por qué se dividen cuando añadimos nuevos nodos?
R: Los IO workers se utilizan para leer/escribir desde el disco, puedes aumentar el número de hilos (workers) en la configuración de tu bucket dependiendo de tu capacidad para hacerlo (si sólo puedes manejar 4 workers, ponerlo a 8 no cambiará el rendimiento). Cuando añades más nodos a tu cluster, incrementas tus trabajadores IO linealmente, con cada nuevo nodo añadiendo la misma cantidad de trabajadores IO (para su propio IO). No se "dividen", se asignan por nodo.
P: ¿Ha dicho usted: "La marca de pleamar ha cambiado recientemente de 80% a 90%"? ¿Y la marca de bajamar? ¿Sigue siendo 60% o ha cambiado?
R: En realidad estos son parámetros configurables, los ajustes por defecto son aproximadamente 80% para marca de agua baja y 90% para marca de agua alta. En la marca de agua baja, comenzará la expulsión de los datos de la partición réplica de la RAM, y en la marca de agua alta ocurrirá la expulsión de los datos de la partición activa de la RAM. Estos también son parámetros configurables a nivel de cubo, ver: http://docs.couchbase.com/couchbase-manual-2.2/#changing-thresholds-for-ejection
P: ¿Cómo puedo eliminar un cubo de datos?
R: En la interfaz de administración puede eliminar un cubo haciendo clic en Cubos de datos en la parte superior de la navegación, haga clic en el triángulo junto al nombre del cubo para expandirlo, haga clic en el botón Editar en el lado derecho, y en la parte inferior del cuadro de diálogo modal que aparece hay un botón Eliminar. También puede eliminar cubos mediante programación desde el SDK.
P: ¿Qué relación hay entre Couchbase y Apache CouchDB?
R: Los fundadores de CouchDB (Damien Miller y JChris Anderson) dejaron el proyecto Apache CouchDB y se unieron/fusionaron con NorthScale/Membase como fundadores de Couchbase junto con Steve Yen y Dustin Sallings (de Northscale/Membase). Hay muchas similitudes en el estilo Map-Reduce de Views y en la sintaxis de consulta que resultará familiar a los usuarios de CouchDB, sin embargo, también hay muchas diferencias importantes. Couchbase es una empresa independiente de código abierto con ánimo de lucro con su propia base de código independiente que no está vinculada a CouchDB de ninguna manera. Sin embargo, las operaciones CRUD binarias se parecen más a memcached/membase que a algo relacionado con CouchDB. Ciertamente podrían haber elegido un nombre menos confuso...
P: ¿Cómo gestiona la arquitectura las particiones desequilibradas?
R: En realidad, nuestra estrategia de hashing y partición ha demostrado a lo largo de muchos años estar muy bien distribuida, razón por la cual seguimos utilizándola.
Q: ¿Cómo se gestionan los fallos de los nodos?
R: Hay dos maneras de manejar los fallos de nodo, la primera es habilitando auto-failover. En auto-failover, si un nodo está inaccesible durante 30 segundos, ese nodo será automáticamente fallado y las réplicas serán promovidas a activas. La alternativa es conmutar manualmente un nodo (o programarlo para que sea automático pero basado en su propia solución de monitorización), lo que puede darle la flexibilidad de decidir todos los parámetros y tiempos para la conmutación por error de los nodos.
P: Traté de instalar el servidor couchbase enterprise2.2.0 en fedora17 pero obtuve fallas para libcrypto.so y libssl.so, ¿cómo puedo solucionar esto?
R: Sí, debido a una dependencia de erlang en la biblioteca principal erlang necesita yum install openssl098e
P: ¿Qué significa acid para Couchbase?
R: Couchbase soporta "transacciones" ACID a nivel de documento. Puedes usar CAS (Check and Set/Compare and Swap) para concurrencia optimista o usar GetAndLock para bloquear un documento para escenarios de concurrencia pesimista. Las transacciones son generalmente mucho más necesarias en los almacenes de datos RDBMS Normalizados. La razón es que debido a la Normalización, las estructuras de datos están a menudo divididas en muchas tablas diferentes, sin Transacciones, la integridad de los datos colapsa rápidamente. En escenarios NoSQL como Couchbase, ya que los datos están mucho menos normalizados, las transacciones son generalmente menos necesarias que en el mundo RDBMS. Usando el modelo de concurrencia puedes crear transacciones. También tenemos operaciones de durabilidad donde puedes asegurar que los datos han llegado a una réplica y/o al disco.
P: Si uno de los nodos del clúster se cae, ¿cómo se actualiza el mapa del servidor de aplicaciones del cliente y los datos de ese nodo?
R: Cuando se activa una conmutación por error (ya sea automática o manualmente) esto promueve las particiones de réplica a activas. Si un nodo recibe una operación CRUD para un número de partición que no posee, devuelve un error "Not My VBucket" al cliente sdk, el cliente sdk sabe cómo manejar esto. Este error indica que el mapa del cluster está desactualizado/desincronizado y automáticamente solicita uno nuevo desde la conexión HTTP persistente. Sólo hay 2 escenarios en los que un mapa de clúster cambia, en los reequilibrios y en las conmutaciones por error. Así que esos son los momentos en los que la topología cambia y el mapa de clúster se cambia, y el cliente lo verá en la primera operación que devuelva el error "Not My VBucket".
P: ¿Hay un límite de 20 GB en disco duro para cada servidor?
R: No hay límite de almacenamiento, lo que puede haber escuchado mal es que hay un límite de 20MB por valor de documento en Couchbase.
P: ¿Es el append only disk writes similar al journaling y a lo que usa el sistema de archivos OS?
R: Sí, es una estrategia similar pero en nuestro propio formato.
P: ¿Hay alguna forma de monitorizar el tamaño de disco libre? ¿Enviará un buscapersonas o una notificación por correo electrónico cuando alcance los umbrales (por ejemplo, 80% lleno)? ¿Lo mismo ocurre con el uso de CPU / MEM?
R: No tenemos este tipo de sistemas de notificación incorporados, pero es ciertamente trivial integrar tu propio sistema para hacer esto. Estos son más como monitoreo de VM/Computadoras que específicos de Couchbase, pero podrías fácilmente crear una integración para tus propios parámetros personalizados. Toda la información en los gráficos de la consola de administración está disponible como JSON con peticiones http.
Q: ¿Qué es un cubo?
R: Un bucket es una "base de datos", una colección de datos. También es un espacio de nombres para los datos, por lo que todas las claves deben ser únicas dentro de un bucket. También actúa como un espacio de nombres para las vistas, los documentos de diseño y las vistas sólo pueden acceder a los datos dentro del bucket en el que se definen.
P: En el caso de que haya varios servidores couchbase y varios servidores de aplicaciones, ¿pueden todos los servidores de aplicaciones conectarse al mismo servidor couchbase (misma dirección IP)? En este caso el balanceo de carga se realiza automáticamente por couchbase o es mejor distribuir las conexiones entre los servidores de aplicaciones?
R: Gran pregunta, es importante NO poner un balanceador de carga entre los servidores de aplicación y Couchbase. Debido a la partición key-hash, los datos ya están automáticamente distribuidos a través del cluster de Couchbase. Los servidores de aplicaciones se conectarán e interactuarán con los nodos del clúster de Couchbase directamente y debido a la partición ya estarán "equilibrados en carga" en el sentido de que estarán haciendo operaciones CRUD a través del clúster basadas en el hash de las claves. Los servidores de aplicaciones y clientes sdk mantendrán conexiones abiertas a cada nodo en el clúster Couchbase, y por lo general, una sola conexión compartida es todo lo que se necesita para cada servidor de aplicaciones.
P: ¿Qué ocurre cuando las aplicaciones cliente acceden a un documento mientras se está realizando el reequilibrio de ese bucket que contiene documentos?
R: Todas las operaciones continúan con normalidad durante el reequilibrio, y las operaciones normales tienen prioridad sobre el reequilibrio. Esto significa que se seguirá reequilibrando mientras estés realizando operaciones. Por supuesto, en términos generales, es mejor no iniciar un reequilibrio durante los picos de uso. Sin embargo, depende del nivel de uso y de la configuración si puede causar una ralentización o no. En la mayoría de los casos es imperceptible.
P: ¿Cuál es el tipo BLOB similar en Couchbase?
R: Puede almacenar datos binarios directamente como un valor utilizando el SDK, ya que no tenemos un esquema definido o forzado, no necesita especificar que es un BLOB. El BLOB es simplemente el valor del "documento".
P: Cuando realizo una operación set, el documento pasa primero a la RAM y de ahí se envía a la cola de escritura en disco y a la cola de replicación. ¿qué pasa si el nodo se bloquea cuando el documento está en la RAM?
R: Siempre que se produce un fallo en cualquier sistema de cualquier tipo (cualquier tipo de base de datos, servidor de aplicaciones, teléfono móvil, etc.) existe la posibilidad de pérdida de datos. Todas las estrategias son intentos de minimizarlo lo mejor posible, pero en este escenario exacto, sí, es posible llegar a la RAM, pero no llegar a la cola de escritura en disco y / o cola de replicación si la máquina se bloquea con fuerza en ese momento exacto entre el almacenamiento y la RAM y la inserción en las colas.
P: Cuando se añade un servidor, ¿se hace sharding?
R: Sí, usamos "Hash Sharding" para todos los datos, lo que significa que para cada par clave-valor, hacemos un hash de la cadena clave para obtener el número de partición (un contenedor lógico) en el que debería vivir. Buscamos el número de partición en el mapa del cluster para ver dónde se encuentra esa partición en el cluster de Couchbase, y luego hacemos CRUD directamente con el nodo de Couchbase responsable de esa partición. Cuando añades un nuevo servidor (o más de uno), simplemente redistribuimos las particiones uniformemente entre el nuevo número de nodos.
P: ¿Tenemos que añadir servidores sólo para la réplica?
R: Las replicas, para ser efectivas en una situación de failover, necesitan estar localizadas en diferentes nodos para que los nodos puedan ser "failover". Para una réplica, tiene que haber al menos dos nodos Couchbase. Para dos réplicas tiene que haber al menos tres nodos Couchbase, y para tres réplicas tiene que haber al menos cuatro nodos Couchbase. Por supuesto, aumentar el número de réplicas también aumenta la necesidad de mayores recursos para un rendimiento óptimo.
P: ¿Todos los documentos con el mismo valor hash se almacenan en la misma partición?
R: Si, nuestra función Hash simplemente convierte una cadena de claves en un número de [0...1023], todas las claves que tengan como hash el número 2 vivirán dentro del contenedor de particiones #2. Esa partición residirá en un nodo particular de Couchbase en el cluster, si añades más servidores y reequilibras, esa partición puede ser movida a otro servidor, pero sólo hay un nodo que es el "maestro" para esa partición. La "réplica" de esa partición vivirá, por supuesto, en un nodo separado.
P: En tu ejemplo de escala horizontal, el total de particiones es siempre 1024. Es 1024 el máximo de particiones en un clúster?
R: Al conocer por primera vez nuestro esquema de fragmentación y distribución, muchos desarrolladores ven este número como un botón que ajustar, naturalmente, ya que todos somos unos manitas. Sin embargo, el número de particiones no cambia las características de rendimiento. Creemos que 1024 es un buen número de particiones para una distribución uniforme de los datos, no es realmente algo que deba cambiarse y no es un parámetro de configuración. El número podría ser fácilmente 10.000 o 990, y no cambiaría la arquitectura de cómo distribuimos los datos (sólo aumentaría o reduciría el número de archivos de datos).
P: ¿Cuántos Buckets se pueden instalar en una sola máquina virtual?
R: Esta es una pregunta difícil para dar una regla general, porque los recursos asignados a esa máquina virtual pueden variar mucho, pero en general para una máquina de tamaño considerable de 8+ núcleos, alrededor de 10-12 Buckets es factible. Para cada Bucket asignamos recursos para gestionar y monitorizar, por lo que tener un gran número de Buckets aumenta la sobrecarga de la CPU y generalmente no es recomendable.
P: ¿El reequilibrio de los nodos tiene algún efecto sobre la eficiencia de Couchbase?
R: Priorizamos las operaciones primarias sobre las operaciones de rebalanceo en Couchbase, pero dicho esto, hay un incremento de CPU y tráfico de red entre los nodos de Couchbase durante un rebalanceo. Se recomienda hacer el rebalanceo en horas de menor uso, por supuesto, lo mismo va para hacer copias de seguridad, al igual que cualquier otro sistema. Hacer un rebalanceo en horas punta de uso ralentizará el tiempo de rebalanceo si el pico de uso es muy alto.
P: Al reequilibrar, ¿se mueven las particiones a otro nodo o se duplican?
R: Se copian hasta que finaliza el reequilibrio, en caso de que se produzca un fallo durante el reequilibrio. El nodo maestro original sigue siendo el nodo maestro hasta que el reequilibrio finaliza por completo. Una vez finalizado el reequilibrio, el nuevo nodo maestro para esa partición se convierte en el maestro y el antiguo elimina sus datos, y los mapas del clúster se actualizan en consecuencia en todo el clúster, y luego los sdk del cliente.
P: ¿Qué herramientas hay disponibles para hacer copias de seguridad/restaurar y para ayudar a la recuperación en caso de catástrofe?
R: Disponemos de las herramientas de línea de comandos cbbackup y cbrestore para este propósito, puede leer sobre ellas aquí: http://www.couchbase.com/docs//couchbase-manual-2.0/couchbase-backup-restore-backup-cbbackup.html
