Estrategias de implementación de IBM Db2 Warehouse en Google Cloud

Este documento es la primera parte de un conjunto de varias partes en el que se analizan las opciones para implementar IBM Db2 Warehouse en Google Cloud. En esta parte, se proporciona una descripción general de lo que es Db2 Warehouse, para qué se usa y algunos puntos importantes y opciones que se deben tener en cuenta cuando se planifica una implementación.
La serie consta de estas partes:

Introducción

IBM Db2 Warehouse es un almacén de datos de estadísticas que se implementa mediante contenedores de Docker. Db2 Data Warehouse ofrece estadísticas escalables en la base de datos, procesamiento en la memoria y compatibilidad con aplicaciones de datos.

Terminología

Los siguientes términos son importantes para comprender una implementación de IBM Db2 Warehouse en Google Cloud.

Nodo de datos
Es cualquier miembro de un clúster de IBM Warehouse Db2.
Nodo principal
Es una designación para un nodo de datos que ejecuta la consola web del administrador y que funciona como el administrador del clúster. Cada clúster contiene exactamente un nodo principal.
Clúster de IBM Db2 Warehouse
Un grupo de máquinas que funcionan como una instancia de IBM Db2 Warehouse y que están configuradas para ofrecer conectividad, elección de líder, conmutación por error y escalamiento. El clúster consta de un nodo principal y dos o más nodos de datos adicionales.
Sistema de archivos compartido
Es un sistema de archivos que se activa como un recurso de lectura y escritura en todos los nodos del clúster. Esto es un requisito de un clúster de Db2 Warehouse.

Cuándo implementar IBM Db2 Warehouse en Google Cloud

Puedes considerar la implementación de Db2 Warehouse en Google Cloud en las siguientes condiciones:

  • Ya estás operando un Db2 Warehouse local o en otro proveedor de servicios en la nube y deseas mover (“lift-and-shift”) esa carga de trabajo a Google Cloud sin migrar a un producto de almacén de datos diferente.
  • Estás considerando una implementación híbrida, con fines de recuperación ante desastres o disponibilidad.
  • Ya estás usando Db2 Warehouse y quieres usar las capacidades y experiencias de tu equipo a fin de implementar un almacén de datos para una nueva carga de trabajo de estadísticas.

Arquitectura de alto nivel de un clúster de Db2 Warehouse

En el siguiente diagrama, se ilustra una implementación típica de Db2 Warehouse. La implementación consta de un nodo principal, dos nodos de datos y un sistema de archivos compartido, además de acceso de usuario interactivo y conexión de aplicación.

Arquitectura de alto nivel de una implementación de Db2 Warehouse en GCP

Para todas las implementaciones de Db2 Warehouse:

  • Las imágenes de Docker de Db2 Warehouse se obtienen de la Docker Store. Estas imágenes son necesarias a la hora de implementar instancias nuevas (por ejemplo, para el escalamiento) y cuando necesitas actualizar instancias existentes a una nueva versión de Db2 Warehouse.
  • Para ejecutar cargas de trabajo en producción, necesitarás una licencia apropiada una vez que hayas pasado el período de prueba gratuita.
  • Un clúster de Db2 Warehouse toma una topología de red fija, lo cual significa que las direcciones IP y los nombres DNS de los nodos no cambian con el tiempo. Los cambios en la configuración del clúster requieren que retires el clúster y que realices las actualizaciones en la configuración de forma manual.
  • El sistema de archivos compartido que utilizas debe activarse en modo de lectura y escritura en todos los nodos del clúster.
  • Los nodos del clúster requieren que una amplia gama de puertos estén abiertos para facilitar las comunicaciones.

Consideraciones sobre la implementación

En esta sección, se describen las diferentes opciones para implementar y ejecutar Db2 Warehouse en Google Cloud.

Recursos de procesamiento

En los instructivos de esta serie, se demuestra cómo implementar Db2 Warehouse en Google Cloud de dos maneras diferentes:

Cuándo elegir Compute Engine

Compute Engine es un servicio a nivel de IaaS. Elige Compute Engine cuando necesites control total de tus recursos virtualizados de procesamiento y de la configuración de la red. Las piezas fundamentales de tu implementación de Db2 Warehouse son las máquinas virtuales. IBM Db2 Warehouse es un almacén de datos empresarial. Por lo tanto, es una carga de trabajo que suele encajar con este enfoque de IaaS.

Cuándo elegir GKE

GKE se encarga de administrar los clústeres de Kubernetes por ti. Las cargas de trabajo de los almacenes de datos como Db2 Warehouse no suelen implementarse en GKE. Por lo tanto, implementar IBM Db2 Warehouse en GKE requiere conocimientos avanzados de Kubernetes. Si tu equipo de DevOps quiere utilizar GKE para la implementación en general, tal vez tenga sentido que uses GKE en la implementación de Db2 Warehouse.

Opciones de almacenamiento

Puedes elegir diferentes sistemas de almacenamiento compartido para Db2 Warehouse. Por ejemplo, puedes elegir volúmenes de NFS, sistema de archivos IBM Spectrum Scale (GPFS), o GlusterFS. Cada una de estas opciones requiere una conexión de red rápida y confiable entre los nodos de datos de Db2 Warehouse y el sistema de almacenamiento compartido.

Cuando elijas un sistema de almacenamiento compartido, ten en cuenta lo siguiente:

  • Licencias y costos: Por ejemplo, GlusterFS es una solución de código abierto, mientras que IBM Spectrum Scale requiere la compra de una licencia.
  • Administración de servicios: Si necesitas una solución completamente administrada, podrías elegir Filestore. Por otro lado, si necesitas la capacidad de ajustar tu solución de almacenamiento, tal vez sea mejor para tus necesidades que implementes tus propios servidores NFS o que uses un sistema de archivos distribuido.
  • Red: Los sistemas de archivos compartidos requieren una red rápida y confiable para la comunicación entre los nodos y el clúster. Los requisitos de ancho de banda dependen de la capacidad de procesamiento de lectura y escritura que necesites. Existen algunas diferencias entre las diversas soluciones de almacenamiento. Por ejemplo, cuando usas almacenamiento NFS remoto, debes tener una conexión rápida desde los nodos a los servidores NFS. Si el sistema de archivos distribuido se implementa directamente en los nodos, las comunicaciones entre nodos requieren más ancho de banda en comparación con el caso de NFS remoto.
  • Experiencia y capacidades del equipo: Si tu equipo tiene experiencia con una tecnología o solución determinada, suele ser más económico, en términos de tiempo y recursos, que continúes usando esa tecnología.
  • Herramientas actuales: Si administras tu solución de almacenamiento existente con una cadena de herramientas establecida, puede que resulte lento y costoso tener otra cadena de herramientas solo para administrar los componentes de almacenamiento recién implementados.

En los instructivos de esta serie, utilizarás dos tipos de almacenamiento diferentes:

  • NFS. Debes usar Filestore, un servicio de almacenamiento de archivos completamente administrado y de alto rendimiento que tiene una interfaz de sistema de archivos y se puede usar para compartir datos. Se puede acceder a los volúmenes de datos administrados con Filestore mediante el protocolo Sistema de archivos de red (NFS).
  • GlusterFS, un sistema de archivos distribuido escalable diseñado para la escalabilidad y la replicación. Ofrece varias interfaces de acceso, incluido el cliente nativo de GlusterFS, un cliente basado en FUSE y NFS. Con GlusterFS, también puedes ajustar la configuración del backend de almacenamiento del entorno (por ejemplo, la cantidad de réplicas). Un servidor de GlusterFS puede ejecutarse tanto en Compute Engine como en un clúster de Kubernetes (en este caso, creado y administrado en GKE). Ten en cuenta que cuando configures GlusterFS también debes aprovisionar dispositivos de almacenamiento en bloque, los cuales quedarán bajo la administración exclusiva de los daemons de GlusterFS.

Próximos pasos