Blog

Google Cloud – Regiones y Zonas de Disponibilidad
Curso Google Cloud

Con este post comienzo una serie dedicada a Google Cloud y a sus diferentes servicios y recursos. En este caso hablaré de regiones y zonas de disponibilidad en la plataforma Google Cloud.

Ventajas de mover aplicaciones a un proveedor de Cloud

Cuando ejecutamos nuestras aplicaciones en un datacenter on-premise siempre tenemos que planificar con anterioridad la capacidad que los servidores van a poder soportar, si nos equivocamos, tendremos que realizar la compra y provisión de nuevos servidores, lo cuál equivale no sólo a más dinero sino también conlleva tiempo.

En contraposición, en un proveedor de Cloud el pago de los recursos es por uso y éstos son elásticos, de manera que si la carga de nuestro sistema aumenta, podemos adaptar la capacidad del mismo en minutos. Los puntos clave por tanto son los siguientes:
- Coste de la infraestructura variable en función del uso frente al coste que nos supone on-premise (pago por uso).
- Beneficio a partir de la economía de escala, al utilizar la infraestructura de grandes gigantes como son los proveedores de cloud pública.
- Ya no desearemos más capacidad en nuestro sistema, pues tendremos el que sea necesario.
- No necesitamos realizar una inversión para tener nuestro data-center.
- Podemos ejecutar nuestros sistemas y aplicaciones a nivel global en minutos.
Cuando hablamos de Google Cloud tenemos las siguientes ventajas:
- Es uno de los 3 principales proveedores de cloud pública del mundo junto con Amazon Web Services (AWS) y Azure.
- Provee más de 200 servicios en la nube.
- Destaca por su confiabilidad, seguridad y alto-rendimiento ya que es la misma infraestructura que utiliza Google para servir sus aplicaciones a más de mil millones de usuarios: Gmail, YouTube, Google Search, etc.
- Es la nube más limpia, ya que es una nube carbon-neutral. El 100% de la electricidad es generada a través de energía renovable.
¿Porqué necesitamos regiones y zonas?

Imaginemos que tenemos un data-center en Londres que es donde ejecutamos nuestra aplicación, cómo resolveríamos los siguientes puntos:
- Acceso lento desde otras partes del mundo (high latency).
- Qué pasaría si el data center se cae. La aplicación no estaría disponible.
1 región + 1 datacenter

Para solucionar los retos anteriores, podemos añadir otro data-center en la región de Londres y desplegar en él otra instancia de nuestra aplicación. Veamos si resuelve los problemas encontrados:
- (PENDIENTE) Sigue existiendo un acceso lento desde otros puntos del planeta.
- (RESUELTO) Si se cae un data-center la aplicación estaría disponible en el otro datacenter.
- Pero qué ocurre si toda la región de Londres cae? La aplicación no estaría disponible.
1 región + 2 datacenters

Qué ocurre si añadimos a lo anterior otra región idéntica a la de Londres en Los Ángeles:
- (RESUELTO PARCIALMENTE) Dependiendo de la zona desde la que accedes la aplicación puede ser servida desde la región más cercana para evitar una latencia elevada.
- (RESUELTO) Si un data-center se cae podemos servir la aplicación desde el otro data-center de cada región.
- (RESUELTO) Si una región se cae, la aplicación sigue estando disponible desde la otra región mientras la región se restaura.
2 regiones + 2 datacenters por región

Entendiendo las regiones y zonas de disponibilidad en google cloud

Una REGIÓN es una localización específica de los recursos. Google Cloud provee de más de 20 regiones en todo el mundo y se expanden año a año. Las ventajas de tener un mayor número de regiones:
- Alta-Disponibilidad.
- Baja Latencia. Puedes servir tus aplicaciones desde la región más próxima a tus usuarios.
- Aplicaciones y compañías globales. Una compañía del tamaño que sea puede servir sus productos alrededor de todo el planeta independientemente de dónde se ubique.
- Ser capaz de cumplir con las regulaciones de los distintos gobiernos. Por ejemplo la normativa de tener los datos almacenados dentro de un país específico.
Regiones de Google Cloud Platform

Para obtener alta disponibilidad en las regiones, se incorporan las ZONAS (data-centers dentro de la misma región geográfica). Cada REGIÓN tiene 3 o más ZONAS para incrementar la disponibilidad y la tolerancia a fallos dentro de la región. Las ZONAS tienen enlaces de muy baja latencia entre ellas, pero están los suficientemente separadas para evitar fallos globales.

El nombre de las zonas se corresponde con el nombre de la región, seguido de una letra que las identifica (a, b, c, d…) como puede verse en la siguiente tabla:

En este post hemos visto el concepto de Regiones y Zonas en Google Cloud en futuros artículos veremos los demás servicios de Google Cloud.
15 enero, 2023
Elastic Cloud on Kubernetes
Elastic Cloud on Kubernetes o ECK amplía la capacidad de orquestación de Kubernetes para desplegar, securizar y actualizar tu clúster de Elasticsearch. En este artíulo aprenderás a desplegar Elastic Cloud en un clúster de Kubernetes en Google Cloud. ECK está basado en el patrón kubernetes operator y además de Elasticsearch también soporta la configuración y administración de Kibana. Puedes desplegar sobre la distribución que tú elijas, incluidos Google Kubernetes Engine, Azure Kubernetes Service, Amazon Elastic Kubernetes Service y Openshift.

Las versiones soportadas por ECK son las siguientes:
- kubectl 1.11 o superior
- Kubernetes 1.12 o superior o Openshift 3.11 o superior
- Elastic Stack 6.8 o superior, 7.1 o superior
Google Kubernetes Engine

Lo primero que necesitamos para desplegar a través de ECK es tener disponible un cluster de Kubernetes. Google Kubernetes Engine o GKE es el entorno gestionado de kubernetes de Google Cloud Platform.

Para crear un cluster de kubernetes en Google Cloud Platform tan solo tenemos que entrar en la consola (https://console.cloud.google.com) y una vez que nos hemos autenticado y estamos dentro, entrar en el menú de navegación y seleccionar Kubernetes Engine / Clusters. Una vez dentro pulsamos la opción «Crear clúster«.

Nos aparecerá un formulario para especificar las características de nuestro clúster. Lo primero es darle un nombre, por ejemplo cluster-eck y seleccionamos la zona, por ejemplo europe-west1-c o a europe-west1-b. La versión de kubernetes ya vimos que tenía que ser la 1.12 o superior, así que podemos dejar la que venga por defecto.

En grupo de nodos seleccionamos el tipo de nodo en cuanto a cpu y memoria. Podemos arrancar el clúster con el mínimo de memoria, pero si queremos un deployment de Elasticsearch con varios nodos para alta disponibilidad + un deployment de Kibana, necesitaremos al menos nodos de 7,5Gb.

Cómo se trata de un cluster para probar ECK seleccionamos la opción de clúster público en la categoría Redes.

Pulsamos crear y comenzará a desplegarse el clúster en nuestro proyecto de Google Cloud. Si lo deseamos podemos crear el clúster a través del SDK o de Cloud Shell a través del comando que te ofrece el propio proceso de creación.

Crear clúster desde SDK de Google Cloud

Creación del clúster de Kubernetes completada

Kubernetes Operator

Una vez que tenemos el cluster de kuberntes listo, necesitamos instalar las custom resource definitions y el operador de kubernetes con sus reglas RBAC. Para ello tenemos que tener instalado el cliente kubectl en el SDK de Google Cloud Shell, ya está instalado por defecto en Cloud Shell. Para shell en local ejecutar:
gcloud components install kubectl
Antes de operar el cluster con kubectl necesitamos obtener las credenciales con el siguiente comando y así generar la entrada correspondiente en kubeconfig. Debes modificar la zona y el nombre del proyecto por el que corresponda.
```
gcloud container clusters get-credentials cluster-eck --zone europe-west1-b --project miprimerproyecto

Fetching cluster endpoint and auth data.
kubeconfig entry generated for cluster-eck.
```
La instalación del operador de kubernetes se realizaría con el comando:
kubectl apply -f https://download.elastic.co/downloads/eck/1.0.1/all-in-one.yaml
El comando anterior crea en el clúster un namespace llamado elastic-system. Podemos ver los logs del operador con el siguiente comando:
kubectl -n elastic-system logs -f statefulset.apps/elastic-operator
Desplegar un cluster Elasticsearch

Para desplegar un cluster de Elasticsearch, debes aplicar la siguiente especificación. En ella verás que se especifica un único nodo. El nodo debe tener más de 2Gb de memoria o el pod no arrancará adecuadamente:
cat <<EOF | kubectl apply -f - apiVersion: elasticsearch.k8s.elastic.co/v1 kind: Elasticsearch metadata: name: quickstart spec: version: 7.6.1 nodeSets: - name: default count: 1 config: node.master: true node.data: true node.ingest: true node.store.allow_mmap: false EOF
El operador automáticamente crea el clúster de Elasticsearch con la configuración deseada. Esto lleva algunos minutos hasta que el clúster está preparado para su uso. Puedes ver el estado con el siguiente comando:
kubectl get elasticsearch NAME HEALTH NODES VERSION PHASE AGE quickstart green 1 7.6.0 Ready 3m4s
Para acceder a Elasticsearch necesitamos obtener las credenciales de acceso. Un usuario predeterminado llamado elastic se crea automáticamente con la contraseña almacenada en un secreto de Kubernetes:
PASSWORD=$(kubectl get secret quickstart-es-elastic-user -o=jsonpath='{.data.elastic}' | base64 --decode)
Ahora podemos acceder al cluster a través del comando curl:
curl -u "elastic:$PASSWORD" -k "https://quickstart-es-http:9200" { name: "quickstart-es-default-0", cluster_name: "quickstart", cluster_uuid: "I2jl0QQlT_GEbzFhNUXy2Q", version: { number: "7.6.0", build_flavor: "default", build_type: "docker", build_hash: "7f634e9f44834fbc12724506cc1da681b0c3b1e3", build_date: "2020-02-06T00:09:00.449973Z", build_snapshot: false, lucene_version: "8.4.0", minimum_wire_compatibility_version: "6.8.0", minimum_index_compatibility_version: "6.0.0-beta1" }, tagline: "You Know, for Search" }
Si tenemos SDK Shell en local, en vez de probarlo con un curl como en el párrafo anterior, podemos hacer forward del puerto y probar desde el navegador con el usuario «elastic» y la contraseña obtenida desde los secrets de kubernetes:
```
kubectl port-forward service/quickstart-es-http 9200
```
Desplegar Kibana

Para desplegar kibana debemos especificar la siguiente configuración. En ella debemos asociar kibana con el cluster de Elastic:
cat <<EOF | kubectl apply -f - apiVersion: kibana.k8s.elastic.co/v1 kind: Kibana metadata: name: quickstart spec: version: 7.6.1 count: 1 elasticsearchRef: name: quickstart EOF
Puedes ver el estado con el siguiente comando:
kubectl get kibana NAME HEALTH NODES VERSION AGE quickstart red 7.6.0 4s
Para acceder a kibana podemos ver el servicio creado para kibana:
kubectl get service quickstart-kb-http NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE quickstart-kb-http ClusterIP 10.44.4.49 <none> 5601/TCP 3m57s
Usamos kubectl port-forward para acceder a Kibana desde el pc local:
kubectl port-forward service/quickstart-kb-http 5601
Abrimos en el navegador la url https://localhost:5601 y accederemos a la interfaz de kibana a la que podemos acceder con el usuario elastic y la password obtenida más arriba.

Si has llegado hasta aquí habrás sido capaz de desplegar Elastic cloud en un cluster de Kubernetes en Google Cloud. Se trata de un despliegue básico que puedes ir completando. Si modificas la especificación y aumentas el número de nodos, verás que el clúster irá añadiendo nodos de forma transparente. También puedes añadir nodos para master dedicados, subir de versión, etc. Desde luego se trata de un paso adelante para la orquestación de nuestros despliegues de Elasticsearch. IMPORTANTE: No olvides eliminar tus despliegues y cluster de kubernetes si no quieres incurrir en gastos innecesarios.
19 abril, 2020
Elasticsearch Services en AWS
En este post vamos a comparar los servicios Elasticsearch como SaaS con los que contamos en AWS. Elasticsearch se ha convertido en una de las herramientas más ampliamente usadas para desplegar diferentes capacidades de búsqueda en aplicaciones empresariales.

Elasticsearch fue lanzado como implementación open source por Shay Banon en 2010. Fundó la compañía de búsqueda Elastic en 2015 para vender una versión comercial a través de licenciamiento. Elasticsearch implementa motores de búsqueda optimizados para búsquedas «full text search». Pero Elasticsearch no sólo almacena texto, sino también logs, métricas, lo que permite la analítica del dato, monitorización de aplicaciones y analítica de seguridad.

Elasticsearch puede descargarse de manera gratuita e instalarse en diferentes plataformas en modo servicio o también dentro de contenedores docker. En entornos empresariales existe la posibilidad de desplegar Elasticsearch en Elastic Cloud Enterprise, que se encarga de orquestar múltiples clusters de Elasticsearch on-premise. Otra opción consiste en desplegar Elasticsearch en Kubernetes, a través de un operador de kubernetes creado por Elastic. Para instalar Elasticsearch como servicio gestionado en AWS hay dos enfoques diferentes:
- Amazon Elasticsearch Service.
- Elastic Cloud.
Un tercer enfoque «auto-gestionado» sería instalar el software open source sobre una instancia EC2. Este último requiere más recursos de gestión y más technical expertise.

Amazon ES vs Elastic Cloud

Amazon ES Service y Elastic Cloud ofrecen funcionalidades similares pero difieren en puntos clave. Todas las capacidades son compartidas, como el soporte de Kibana. Kibana es la herramienta que utilizamos para analizar los datos indexados en Elasticsearch. Ambos servicios soportan Beats y Logstash, lo que simplifica la indexación y transformación de los datos. Ambos proveen un fácil despliegue, escalabilidad y requieren menos intervención humana comparándolo con un despliegue manual on-premise o sobre instancias EC2.

Amazon ES Service ofrece una mayor integración con otros servicios AWS:
- Kinesis Streams
- Kinesis Firehose
- CloudWatch Logs
- Buckets S3
- Funciones Lambda
Elastic Cloud incorpora herramientas para portar fácilmente desde otros proveedores cloud o desde infraestructura on-premise. Además soporta una variedad de nuevas capacidades que no tiene el servicio de Amazon. Entre ellas están:
- Data rollups. Usa menos espacio de almacenamiento para resumir y almacenar datos históricos.
- Elasticsearch SQL Provee nuevas herramientas para consulta a Elastic de la manera tradicional pero con la velocidad increíble de la herramienta.
- Kibana Spaces. Facilita la creación y organización de dashboards por grupos de usuarios y funcionalidad.
- Elastic Commercial Plugins. Quizá sea la gran diferencia. Elastic cloud ofrece Seguridad a nivel de acceso a los datos, Reporting, monitorización/alertas y Machine Learning para el entrenamiento y búsqueda de pautas y detección de anomalías. Amazon Elasticsearch Service está incorporando poco a poco su propia implementación de las anteriores funcionalidades basada en Opendistro for Elasticsearch y en muchos casos sólo para nuevos despliegues (ver documentación).
- Canvas. Para la presentación de los datos.
Claves para elegir AWS ES o Elastic Cloud
- Elastic Cloud ofrece más control a las organizaciones y requiere menos trabajo de mantenimiento.
- Si habitualmente trabajas con los servicios de AWS (Kinesis, S3, lambda…), se recomienda utilizar el servicio Elasticsearch de AWS, ya que el mantenimiento y el coste será menor.
- A favor de Elastic Cloud está el hecho de que incorpora plugins de seguridad, machine learning y alertas. Estas características no están aún incluidas en su totalidad en el servicio de Amazon. La propia Elastic ha creado documentación para indicar las diferencias entre ambos servicios.
- Otro punto a tener en cuenta es evitar el efecto «vendor lock-in». Cuantos más servicios AWS se utilicen, más duro será salir de allí por razones económicas o técnicas.
- Por último, organizaciones que utilicen Elasticsearch de manera intensa y como core de su negocio, que quieran el mayor control sobre sus cargas de trabajo, deberían estudiar su propio despliegue y su propia gestión de Elasticsearch.
8 marzo, 2020
Balanceo de carga en Redis con Nginx
Vuelvo a la carga con un post de Arquitectura para compartir cómo usar Nginx (tanto la versión Open Source como la versión de pago – Nginx Plus) para balancear la carga entre varios servidores Redis.

Introducción a Nginx y Redis

Nginx es un servidor proxy HTTP inverso, un servidor proxy de correo y un servidor proxy TCP / UDP genérico. Productos similares serían HAProxy y Apache.

Redis es un almacén en memoria de estructuras de datos open-source, utilizado como base de datos, caché y broker de mensajes.

Solución al balanceo de carga

El balanceo de carga se refiere a la distribución del tráfico de red entre múltiples servidores backend. Estamos más acostumbrados a utilizar el módulo HTTP de Nginx utilizándolo de proxy o balancear la carga de tráfico HTTP. Desde hace algunas versiones Nginx admite el balanceo de carga de tráfico tanto TCP como UDP.

Para cambiar la configuración de Nginx debemos modificar el fichero o ficheros de configuración, en el caso de que tengamos varios que luego incluiremos con claúsulas «include«. El fichero de configuración principal por defecto de Nginx generalmente se encuentra en /etc/nginx/nginx.conf:
```
stream {
 server {
 listen 12345;

 #TCP traffic will be proxied to the "stream_backend" upstream group
 proxy_pass stream_backend;
 }

 server {
 listen 12346;

 #TCP traffic will be proxied a proxied server
 proxy_pass backend.example.com:12346;
 }

 server {
 listen 53 udp;

 #UDP traffic will be proxied to the "dns_servers" upstream group
 proxy_pass dns_servers;
 }
 

 upstream stream_backend {
 server 10.0.18.4:18840;
 server 10.0.18.5:18840;
 server 10.0.18.6:18840;
 }
 
 upstream dns_servers {
 server 10.0.18.4:18840;
 server 10.0.18.5:18840;
 server 10.0.18.6:18840;
 }
}
```
1. Crearemos un bloque «stream {}» de primer nivel
2. Definiremos uno o más bloques «server {}» para configurar cada servidor virtual dentro del bloque stream.
3. Dentro de cada bloque server definiremos mediante la directiva «listen» el puerto en el que el servidor (nginx) escucha tráfico (si es tráfico udp lo especificamos).
4. Incluiremos además dentro de «server» la directiva «proxy-pass» para definir el servidor o el grupo de upstreams en los cuales se redigirá el tráfico.
5. Definimos uno o más bloques «upstream {}» de configuración dentro del bloque «stream» estableciendo un nombre a los mismos.
6. Añadimos a los upstreams una directiva «server» por cada uno de los servidores Redis junto con su dirección IP y su puerto
Conclusión

Hasta aquí la configuración más básica, podemos especificar además el método de balanceo de carga (round-robin, least_conn, least_time, hash) así como parámetros específicos tanto para el número de conexiones máximo, el peso de cada servidor, etc. Al igual que el tráfico de Redis esta solución es aplicable a todo tráfico de red a través del protocolo TCP/UDP. Tienes más información aquí: tcp-load-balancing
13 marzo, 2017
Descubrimiento de Microservicios con Nginx y Consul
En una entrada previa ya traté el enfoque de Microservicios y cómo dividir en servicios de grado más fino, independientes, que exponen un API y que colaboran juntos a través de peticiones HTTP. En esta veremos una solución con Nginx y Consul para el descubrimiento dinámico de microservicios.

Una vez que tenemos unos cuantos microservicios, incluso varias instancias de cada uno para balancear la carga, nuestra atención pasa inevitablemente por conocer dónde están desplegados cada uno de ellos, ya que los mismos pueden «convivir» en el mismo servidor, en diferentes servidores de nuestra infraestructura, o en servicios cloud como el de Amazon. Necesitamos conocer si están o no en ejecución además de su IP y puerto.

La solución pasa por un mecanismo de autoregistro de los microservicios en el momento del despliegue en un catálogo de servicios en «runtime», una forma de decir: «Estoy vivo y me puedes encontrar en esta IP y este puerto». En el momento del «undeploy» debería desregistrarse del mismo.

Consul

Consul es un sistema distribuido open source creado por Hashicorp para el registro de servicios y la configuración de los mismos. Provee un API que permite a los servicios el registro/desregistro en su catálogo. Consul provee igualmente de un chequeo constante de la salud de los servicios, marcando aquéllos que no pasan el mismo. El cluster de Consul se compone de diferentes procesos agente que se encuentran ejecutándose en los mismos servidores en los que se localizan los servicios, de manera que cada servicio se registra en el agente Consul de su servidor. Estos procesos agente pueden ejecutarse en modo cliente o en modo Servidor. Se recomienda ejecutar entre 3 y 5 agentes en modo Servidor.

Cualquier registro/desregistro en un nodo del cluster se propaga por el mismo. Todos los nodos del cluster conocen el catálogo de servicios (sus nombres, direcciones ip y puertos).

Una vez que tenemos un catálogo «runtime» de servicios necesitamos un proxy inverso como Apache, HAProxy o Nginx que enrute las peticiones y balancee la carga entre las distintas instancias de un servicio. Todas las peticiones llegarán a uno o más proxies y éste será el encargado del enrutamiento. El problema a resolver en este escenario es llegar a hacer dinámica la configuración de Nginx, o del proxy que se desee de los expuestos anteriormente.

La configuración de servicios se realiza en un fichero, por lo que si la misma se modifica (modificando el fichero), Nginx debería recargarse y leer la nueva. Pero, ¿quién se encarga de reescribir la configuración de Nginx cuando el catálogo de Consul recibe un alta o una baja de un servicio?

Consul-Template

Consul-Template es un proceso que se ejecuta en uno de los nodos del cluster de Consul (mismo servidor que uno de los agentes Consul) y es capaz de escribir en un fichero del File System los cambios en el catálogo de servicios a través de una plantilla. Esta plantilla la transforma en un fichero de configuración en disco y cuando finaliza puede ejecutar un comando del sistema, forzando a nginx a recargar la configuración.
```
$ consul-template \
  -consul my.consul.internal:6124 \
  -template "/tmp/nginx.ctmpl:/var/nginx/nginx.conf:service nginx restart"
```
Con el comando de arriba se ejecuta el proceso que estará ejecutándose en segundo plano consultando al agente Consul que indicamos en el parámetro -consul. El parámetro -template indica que la plantilla para el rendering del fichero se encuentra en /tmp/nginx.ctmpl y sobrescribe la configuración de nginx en /var/nginx/nginx.conf. Una vez sobreescrito el fichero se ejecuta el comando que recarga la configuración de Nginx, service nginx restart, en el ejemplo de arriba.

All together

En el siguiente esquema observamos todos los componentes unidos y colaborando tal y cómo se ha expuesto más arriba.

Arquitecturas de este tipo son fáciles de implementar y distribuir incluso si nos vamos a una infraestructura basada en contenedores docker. El sistema es escalable y de alta disponibilidad con la inclusión de varios nodos con Nginx y Consul-Template.
28 marzo, 2016