Azure · Sitecore
Bases de datos de Sitecore – usando Azure SQL
Desde que vi el término CLOUD por primera vez, ya escuché muchas suposiciones de personas “enamoradas” o “sin partidarios”. Cada quien tiene su propia perspectiva, y ¿quién no olfatearía una rata cuando su entorno está en juego, verdad?
En esta publicación, compartiré mi experiencia hasta ahora trabajando con entornos de Sitecore usando Azure SQL Server como plataforma de base de datos.
¿Qué es AZURE SQL?
Asumiendo que ya conoces SQL Server, es prácticamente lo mismo, sin embargo tiene su lugar en la nube y, por supuesto, utiliza una versión especial como su back-end.
Azure SQL, según Kurkekar, S (2016)
“ofrece rendimiento predecible, escalabilidad sin tiempo de inactividad, continuidad del negocio y protección de datos, todo con una administración casi cero”
¿Qué hay sobre tiers, características, tiempo de actividad y así sucesivamente?
Para manejar mejor diferentes cargas de trabajo, Azure SQL tiene tres niveles de servicio conocidos como Basic, Standard y Premium, dentro de un SLA de tiempo de actividad del 99,99%. Además, según Rabeler, C (2016, [1]), “tienes la flexibilidad de elegir el nivel que mejor se adapte a las demandas de tu carga de trabajo.”
Como puedes ver en la imagen anterior, Rabeler, C (2016, [2]) “cada tier de Azure SQL tiene uno o más niveles de rendimiento que brindan potencia para ejecutar tus bases de datos de manera predecible.” También, según Rabeler, C (2016, [3]) la disponibilidad garantizada para tu base de datos aumenta desde Basic a Standard y luego a Premium.
¿Sigues conmigo? ¡Genial!
En los viejos tiempos, siguiendo la guía de instalación de Sitecore instalation guide tu mayor preocupación era
“ejecutar la base de datos en un servidor separado del servidor web”
Y en ese momento ese sería tu principal preocupación desde la perspectiva de la base de datos, ¿verdad? Entonces, podrás preguntarte “Hoy en día, ¿tengo otra preocupación si me mudo a Azure SQL?”
¡SÍ! ¡SÍ! Y, una vez más ¡sí! Y aquí está la razón
¿Te suena familiar? Pues ahora sí 🙂
Para mostrarte mejor, compartiré una experiencia que tuve que afrontar hace unos meses.
Como puedes ver, tengo una Suscripción de Microsoft Azure y los siguientes recursos:
- 1 Servidor como Content Management
- 2 Servidores como Content Delivery
- 4 Bases de datos en Azure SQL Server S1 Standard
- 1 Balanceador de carga para gestionar el tráfico de Content Delivery
Todo iba bien, hasta que en un día soleado alguien dijo que el sitio web se cayó!
“Houston, ¡tenemos un problema!”
¡Y, por supuesto, lo tenemos!
Como sabrás, dentro del caos todo se ve MÁS DIFÍCIL. De pronto, me vino a la mente mi última publicación
“Entonces, esperando que no tengas un ataque al corazón ni pánico, relájate! Luego, respira profundo, pon la cabeza a pensar y ¡sígueme!”
No hay que alarmarse ni entrar en pánico… ¡COMPROBADO! Respira hondo… ¡COMPROBADO!
¡Logros desbloqueados! Vamos a ello. Ideas a su sitio, continuemos….
Entonces, como Content Delivery cayó, ¿funcionó Content Management?
Paso 1 – Prueba del nodo CM
Fui a Content Management y la página cargó, y funciona como un encanto. ¡YAY! ¡YAY! Bueno, “ Not so fast buddy!”(https://sitecoresysadmin.wordpress.com/2016/03/24/sitecore-installations-tips-and-tricks-1/), antes de avanzar me gustaría resaltar dos configuraciones importantes que Sitecore podría tener –que fue mi caso.
- Sitecore Scaling Guide: aquí verás formas de separar las características de Content Delivery y Content Management, como quitar referencias a la base Master en nodos CD.
- Sitecore Multisites: como su nombre indica, te permitirá configurar diferentes sitios para la misma instancia de Sitecore
En resumen, al tener ambas cosas configuradas, la instancia CM utilizaba Master para cargar su instancia de Sitecore, lo que significa que Sitecore Multisites está haciendo su trabajo. Y, con razón, el sitio cargó cuando los CDs estaban caídos.
Aunque, al menos sabemos que la base de datos Master está funcionando. Y con base en esta información, ¿qué pasaría si reemplazamos la base Master por la base Web en CM?
Como CM funciona usando la base Master para mostrar su contenido, ¿por qué no reemplazar la Base Master por la Web?
Paso 2 – Trabajando con ConnectionStrings
- Navega a Website\App_Data\
- Abre ConnectionStrings.config
3. Cambia el recurso de Database=mysitecore_Sitecore_Master por Database=mysitecore_Sitecore_Web, y guarda ConnectionStrings.config
4. Abrir navegador e ir a la instancia CM
¡Y no funcionó!
En este punto, sabemos con certeza que la Web database es el problema. Ahora, volvamos CM a su estado original.
Además, como hemos notado que el problema podría estar relacionado con la Web database, ¿por qué no dejar un proceso de recuperación en ejecución para esta base de datos y seguimos con nuestra solución de problemas?
Paso 3 – Verificar el Event Viewer
Por ahora, olvídate del servidor CM y enfoquémonos en CD, ya que el problema es la Web database.
¿Se registró el problema en algún lugar? Vamos a comprobar
Nota rápida: si lo recuerdas, en una publicación anterior te mostré las recomendaciones de Sitecore, así que en mi escenario estas recomendaciones se siguieron.
1. Navega a la ruta de la instancia de Sitecore
2. Luego, abre la carpeta Data\logs
3. Revisa los archivos de registro y verifica si hay algo que apunte a una falla de base de datos
¡Nada! No encontré nada! Bueno, por último, pero no menos importante, vamos a revisar Event Viewer
Nota rápida 2: asumo que estás usando Windows 2012, ¿ok?
1. Haz clic, de vuelta en los viejos tiempos, en el botón Start
2. Verás la Interfaz de Usuario Metro
3. Luego escribe Event Viewer – nota un campo de búsqueda que aparece y puedes tocar Event Viewer
En la ventana de Event Viewer, en el panel izquierdo expande Windows Logs y haz clic en Application
Luego, verifiquemos qué tenemos allí
¡Hey! Mira lo que encontré
“El límite de solicitudes para la base de datos es de 90 y ha sido alcanzado”
En ese momento no era consciente de que existe un límite y ¡se había alcanzado! Sin embargo, ahora lo sabemos, ¿verdad?
Como estamos usando Azure SQL, es posible que te preguntes “Bueno, ¿por qué no cambias el tier de servicio” (https://azure.microsoft.com/en-us/documentation/articles/sql-database-scale-up/) de S1 a S2, por ejemplo?
Buena idea, parece que todavía estás conmigo 🙂 y, lo hice, así que una vez que el proceso terminó, ¡el sitio volvió a estar en vivo! ¡YAY!
¡Otro problema resuelto y salvamos el día!
¡Pero no tan rápido, amigo!
Bien, entonces hemos cambiado de S1 a S2 y ¿qué haremos si vuelve a ocurrir? ¿Pasar a S3? ¿Y seguir con este juego hasta que no vuelva a ocurrir? NO!
La idea es seguir la guía de instalación de Sitecore, y como sabes te he animado a usarla y seguiré haciéndolo. Y como no podría ser de otra manera, Sitecore también tiene una recomendación para Azure SQL, y no estaba cubierta en este entorno.
“Se recomienda usar al menos el tier Standard S3 de Azure SQL en cualquier sistema de producción”
¡Oh Dios! Y estábamos usando Standard S1!!!!
¿Sigues conmigo? ¡Genial! Así que ten en cuenta que es muy importante obtener las recomendaciones de Sitecore, especialmente para el “mundo cloud”!
¡Eso es todo! ¡Gracias por leer y nos vemos en mi próxima publicación!