SQL Server & Containers

Visits: 769

Containers – Que y para qué?

Un Contenedor es fundamentalmente una manera de empaquetar el software para que una aplicación pueda ser ejecutada, incluyendo los binarios y sus dependencias pero haciendo a esta independiente de la arquitectura subyacente.

Todo código, bibliotecas y dependencias de la aplicación se agrupan en un paquete como como un artefacto inmutable.  Es decir, que cuando una aplicación es empaquetada en un Contenedor , sabremos exactamente cómo se ejecutará de manera predecible, repetible e inmutable. No encontraremos ningún error inesperado al moverlo a una nueva máquina, o entre entornos.

Un Contenedor puede ser pensado como ejecutar una máquina virtual, pero sin todo el overhead de tener que levantar todo un sistema operativo. Por esta razón, empaquetar una aplicación en un contenedor frente a instanciar una máquina virtual mejorará el tiempo total de encendido significativamente y reducirá el footprint total de consumo de recursos. 

Las características anteriores hacen a los Contenedores una gran herramienta y un bloque de construcción esencial en una arquitectura de la nube moderna o de microservicios.

Los contenedores originalmente construidos sobre instrucciones de Kernel Linux, se volvieron disponibles sobre Windows a partir Windows Server 2016.

Ref.: https://msdn.microsoft.com/en-us/magazine/mt797649

https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/

El objetivo principal de usar contenedores fue y es actualmente poder ejecutar las aplicaciones en un entorno de servidor de la misma manera que lo realiza en un entorno de desarrollo, evitando los cambios de arquitectura y dependencias. 

Ahora bien, a esta excelente idea le faltaba un componente esencial para poder ser utilizada. De qué manera los usuarios pueden interactuar con esta tecnología? Esto incluye la administración, la orquestación y la seguridad para los contenedores. La respuesta lleva a otro componente de software, como Docker (ampliamente utilizado), Kubernetes, y otros más específicos en Cloud como Azure Container Server (AKS). 

https://kubernetes.io/

https://www.docker.com/

https://docs.microsoft.com/en-us/azure/aks/

Construcción y Deploy de Containers con Docker

Docker es un software de código abierto, que provee un amplio set de herramientas para construir e implementar software en contenedores.

Para descargar la versión Destkop (para Windows o Mac) : https://www.docker.com/get-started

Una vez instalado el software, como primer paso, se crea un archivo especial llamado “Dockerfile”. Los archivos “Dockerfile” definen un proceso de construcción, el cual una vez utilizado con el comando ‘docker build’ , se produce una “imagen docker” inmutable. Este proceso sería como pensar en un “Snapshot” de la aplicación, que se prepara para ser instanciada en cualquier momento.

Para iniciar esta imagen, se ejecuta el comando ‘docker run’ en cualquier ambiente donde se encuentre corriendo el proceso de docker. Este puede correr tanto en un desktop como en un servidor de producción o en la Nube. Sin importar donde se ejecute la imagen, esta correrá de la misma forma siempre.

Adicionalmente Docker provee un repositorio en la Nube, llamado Docker Hub. Podríamos pensar en esto como si fuera GitHub para imágenes Docker. De esta forma se puede utilizar Docker Hub para almacenar y distribuir las imágenes de los contenedores que uno construya.

Bien, hasta este punto hicimos una introducción a Containers y Docker, pero… Que somos? Somos Base de datos!

Entonces, veamos un ejemplo para descargar una imagen de SQL Server 2017 sobre Linux ya contenerizada sobre Docker, desde el repositorio oficial de Micosoft.

Docker Pull – Descargando la imagen

Desde la linea de comandos, realizaremos un Pull de la imagen de SQL Server 2017 para Linux la cual es completamente compatible para ser ejecutada en containers. Este proceso es realmente rápido pensando en que estamos bajando una imagen funcional de SQL Server.

docker pull mcr.microsoft.com/mssql/server:2017-latestdocker

Docker Run – Instanciando la imagen

Una vez finalizado el proceso de Pull, solo resta instanciar la imagen. En el caso de SQL Server se deben configurar los parámetros de Aceptación de Contrato de Usuario Final, establecer la Contraseña del SysAdmin, el puerto TCP para conectarnos y el nombre de la instancia docker.


docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=Strong!Passw0rd@" `
   -p 1433:1433 --name sql1 `
   -d microsoft/mssql-server-linux:2017-latest

Inmediatamente tendremos nuestro contenedor ejecutando un SQL Server 2017 completo y listo para conectarnos y trabajar.

Conectándonos a la Instancia

Podemos conectarnos directamente desde la misma línea de comandos, invocando un shell de Linux sobre nuestro container:

docker exec -it sql1 "bash"

Y luego, una vez dentro de la instancia, podemos utilizar el viejo y querido SQLCMD

/opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P 'Strong!Passw0rd@'

Todo esto en cuestión de escasos minutos y pudiendo realizar todos los pasos en una forma completamente programática. En definitiva un proceso completamente definible como DEVOps.

En próximos posts, veremos cómo avanzar en la configuración y la orquestación de estas nuevas tecnologías.

SQL Server Contained Databases

Visits: 109

Presentación sobre el feature de Contained Databases, donde repasamos sus características y cómo podemos utilizarlo en entornos productivos.

Adicionalmente a la posibilidad que brinda de segmentar la seguridad de los usuarios, también nos permite trabajar con múltiples Collations para cada Base de Datos auto-contenida. Esto aumenta la capacidad de una instancia para consolidar más bases de datos independientemente del collation utilizado.

En el siguiente repositorio de GitHub se encuentran publicados los scripts de la Demo:

https://github.com/MarianoKovo/ContainedDatabases

SQL Server Upgrade & Assessment Guía Paso a Paso

Visits: 166

En esta guía describiremos paso a paso como instalar y ejecuta las herramientas de MAP Toolkit y Data Migration Assistant para realizar un relevamiento y evaluar las instancias de SQL Server en situación de Upgrade.

Always On Availability Groups – Error Node Down. Event ID 1000 : Faulting Application name clussvc.exe

Visits: 649

Para todo hay una primera vez, y esta fue el turno de un nodo caído en una solución de Always On Availability Groups en un Failover Cluster de 5 nodos distribuidos geográficamente.

La configuración de cada nodo se compone:

  • Virtual Machine – VMWare ESX Hypervisor
  • 2 Socket – 2 Processors
  • Windows Server 2012 R2 RTM
  • SQL Server 2016 SP1 Build 13.0.4001.0        
  • 1 Availability Group sobre 2 nodos
  • 1 Availability Group sobre 5 Nodos

Arquitectura

Luego de un reinicio inesperado sobre el nodo secundario del AG1, las bases de datos quedaron en un estado de Recovery Pending.

El nodo 2 de la solución quedó permanente en estado de Offline dentro del Failover Cluster Manager.

Los eventos que aparecieron en el Event Viewer y Failover Cluster Manager:

Event ID 1000

Event ID 1135

Para resolver esta situación, oficialmente Microsoft tiene un KB que repara esta situación. El mismo debe ser aplicado a nivel de Windows:  

https://support.microsoft.com/en-us/help/2984324/clussvc-exe-or-cluster-node-crashes-when-a-node-sends-a-message-to-ano

Una vez aplicado el KB en todos los nodos y reinicio correspondiente, automáticamente el servicio de Cluster inicia correctamente en todos los nodos y la solución de Always On vuelve a sincronizar a los nodos..

Moraleja de la historia, es importante tener un plan de actualización de Service Packs y KBs ya que se pueden evitar situaciones como ésta en Producción y evitar downtimes.