Reflexiones sobre SQL Server

Para los que no lo conocen, SQL Server es el gestor de bases de datos relacionales de Microsoft. Tiene parecidos con todos los otros motores de otras marcas, gratuitos o pagados, pero tiene chichecitos propios que lo hacen atractivo. Es un producto al cual le tengo bastante cariño y he seguido sus avances a pesar que ya no trabajo directamente con él.

No obstante, últimamente por temas laborales me ha tocado interactuar bastante con él en distintos clientes y, en consecuencia, escenarios.

En este artículo pretendo compartir algunas experiencias relevante recogidas en el trabajo con clientes.

Always On

Esta es una tecnología de alta disponibilidad y recuperación de desastres, que aparece por primera vez en la versión 2012 y que ha ido evolucionando mejorando la cantidad de nodos síncronos permitidos, entre otras cosas. Viene junto a la edición Enterprise, pero hay uno en la edición Standard, pero que no tiene todas las capacidades que la incluida en Enterprise, por lo tanto, si se dispone de los medios, presupuesto, hardware y licencias, hay que usarla.

Las máquinas virtuales son geniales. La idea de optimizar el espacio, optimizar recursos y licenciamiento hace que hoy todo el mundo tenga máquinas virtuales para la mayoría de los escenarios. SQL Server puede correr perfectamente en máquinas virtuales. Eso si, se recomienda que los archivos de datos, log y tempdb queden en discos distintos y en ejes de discos distintos. Me refiero a que los discos duros de las máquinas virtuales son archivos que el hipervisor los interpreta como disco y se los presenta a la máquina virtual como un disco duro.

Volviendo al tema, Always On puede correr sobre máquinas virtuales, pero para conservar la esencia recomiendo lo siguiente:

  • Los nodos de Always On deben estar en host físico distinto. En lo posible en distintos rack, con alimentación eléctrica independiente y conectado a otro switch, en modalidad de multi subnet. El motivo es simple: si se cae el host físico completo, está el otro host que almacena los otros nodos. Si se cae el rack completo, está el otro.
  • Se puede hacer una extensión de Always On hacia un ambiente IaaS en Azure. Esto implica la instalación de un controlador de dominio en la nube. No sirve Azure Active Directory. Instalar el nodo de SQL Server y usar un load balancer. Además de configurar una VPN S2S y configurar reglas de firewall y network security group, según corresponda. Importante que las redes se deben ver, tanto en la nube como la red local. El load balancer debe estar configurado con el puerto de la instancia de SQL Server en Azure, debe ser local y tener una dirección ip local. El listener local se debe configurar con la red y la dirección ip del load balancer. Es él quien hará la “magia” al momento de hacer failover. Para más información sobre el listener leer: https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability-group-listener-overview?view=sql-server-ver15
  • Las versiones deben ser iguales y con el mismo nivel de parchado.
  • La autenticación integrada Windows la encuentro más segura si se está en un dominio. Sino, usar la de SQL Server.
  • NUNCA usar el usuario sa. Es como usar la cuenta administrator de un dominio o un root en Linux. Las razones son más que obvias.
  • Las aplicaciones pueden correr perfectamente en un sistema Linux. Lo importante es que el servidor debe tener configurado el DNS Suffix y debe estar apuntando al servidor DNS del dominio de Active Directory.
  • NUNCA configurar el listener en la tabla de hosts del servidor Linux o Windows. Para eso está el DNS.

SQL Server en dominio

Es muy común que SQL Server se instale en un dominio para aprovechar las características de administración, seguridad e integración con otras plataformas de monitoreo como System Center Operations Manager.

En el caso que este sea el escenario, recomiendo lo siguiente:

  • Iniciar la instalación con una cuenta de dominio que tenga privilegios de administrador local sobre el servidor. Una cuenta de administrador de dominio no es necesaria.
  • Idealmente no cambiar el nombre del servidor. En caso de hacerlo, configurar el SQL Server para que adopte el nuevo cambio.
  • Siempre usar una cuenta de servicio que esté en el dominio. Esto es para la seguridad del dominio y no tener problemas con los SPN. En caso de llegar a tener algún problema con estos usar la herramienta Microsoft Kerberos Configuration Manager for SQL Server Esta herramienta no nos hará perder el tiempo y generará los scripts necesarios, o en caso de tener permisos de administración sobre el dominio, hará los cambios. Un SQL Server con un SPN mal configurado provocará que las aplicaciones no puedan hacer uso del servicio a pesar que esté arriba.

Dos puntos importantes que no cabían arriba son:

  • Documentación al día: modelos, topologías, inventarios, etc.
  • Actualizaciones al día.

Eso. No sé que más les puedo decir. Cuiden sus motores de base de datos.

Chau!