Hace m谩s de 10 a帽os, Microsoft anunci贸 la disponibilidad de la plataforma Azure para una amplia audiencia de usuarios. Durante este tiempo, muchas empresas quer铆an aprovechar la infraestructura de la nube para resolver los problemas de TI actuales. Algunos de ellos se pusieron en contacto con nosotros para pedirnos asesoramiento sobre c贸mo implementar sistemas en la nube. Pero pas贸 el tiempo y ahora la empresa est谩 considerando la posibilidad de colocar en las nubes sistemas de uso intensivo de recursos como SAP HANA. Nosotros, a su vez, ya hemos implementado varios proyectos similares y estamos listos para compartir esas observaciones que pueden garantizar una implementaci贸n m谩s exitosa del sistema SAP en la nube de MS Azure. Algunas observaciones no ser谩n un descubrimiento, pero quer铆amos mostrar la aplicabilidad de algunos enfoques en una plataforma en la nube. Queremos compartir contigo las principales lecciones aprendidas.
# 1: Optimice constantemente la arquitectura de TI utilizando la nube
Como parte de la migraci贸n de un sistema productivo, nos enfrentamos al problema del alto consumo de recursos en los procesos de testing y desarrollo, lo que finalmente nos hizo pensar en por qu茅 necesitamos tantos recursos para el entorno de Test y Dev y c贸mo optimizar el consumo de recursos de infraestructura por parte de un sistema productivo.
El enfoque recomendado para construir un sistema SAP se basa en una evaluaci贸n de la capacidad requerida utilizando la calculadora SAP Quick Sizer. Hasta ahora, las metodolog铆as de SAP se basan en enfoques est谩ndar que no tienen en cuenta las peculiaridades de las tecnolog铆as en la nube. Recibimos los requisitos del Cliente, ingresamos los datos iniciales en los estimadores de SAP y recibimos una configuraci贸n preliminar del panorama. En el caso de la infraestructura convencional, fue posible detenerse all铆 y pasar a la compra de equipos, pero en nuestro caso fue posible aprovechar la nube. En la nube, los recursos se pueden incrementar en cualquier momento, por lo que abandonamos el exceso de reserva de recursos en el estimador y desplegamos m谩quinas de menor rendimiento. Esto nos permiti贸 reducir costos,y a medida que aumenta la carga, siempre podemos aumentar el rendimiento de las m谩quinas virtuales de SAP en minutos.
Microsoft proporciona soporte de SAP solo en m谩quinas virtuales de la serie M. El uso de recursos de prueba similares al entorno de producci贸n en t茅rminos de nivel de soporte en la etapa de desarrollo inicial nos parec铆a redundante.
Al mismo tiempo, las m谩quinas de la serie E tienen caracter铆sticas similares a las de la serie M, pero su costo es significativamente menor. Como resultado, reemplazamos las m谩quinas de prueba con la serie E. La desventaja de este reemplazo es la transferencia de la responsabilidad de la operaci贸n del sistema en entornos de prueba del proveedor al integrador. Esto impone la necesidad de que el integrador tenga experiencia en SAP.
# 2: C贸mo ahorrar en el consumo de recursos
MS Azure le permite ahorrar significativamente al reservar recursos con un prepago simult谩neo durante uno o 3 a帽os.
A menudo, en la etapa inicial, el cliente no puede estimar con precisi贸n la fecha de lanzamiento de un sistema de producci贸n, ya que su desarrollo y prueba a menudo se asocian con muchas variables que est谩n del lado de los desarrolladores de empresas o contratistas.
Por ejemplo, en el momento del lanzamiento de uno de los proyectos, planificamos el despliegue simult谩neo de todos los entornos en base a los planes actuales del Cliente. Como suele ser el caso, el desarrollo requiri贸 una coordinaci贸n m谩s prolongada con la empresa, lo que retras贸 el lanzamiento productivo durante varios meses.
En este ejemplo, al reservar recursos con un prepago, el Cliente perder铆a una cantidad significativa de fondos. Por supuesto, es necesario reservar recursos, pero es m谩s eficiente hacerlo en etapas posteriores del proyecto, cuando la mayor parte del sistema productivo se ha estabilizado y el desarrollo se ha vuelto predecible en t茅rminos de consumo de recursos. A menudo, cuando reserva recursos inform谩ticos durante 3 a帽os, puede obtener aproximadamente un 70% de ahorro en comparaci贸n con el m茅todo de pago Pay-As-You-Go.
# 3: C贸mo elegir una regi贸n de Azure
Azure tiene una amplia gama de regiones de hospedaje de recursos. Uno de los principales criterios para elegir una regi贸n es la lejan铆a de su infraestructura a los usuarios finales, lo que afecta la respuesta del sistema y el funcionamiento de las integraciones y los usuarios finales.
El segundo criterio, no menos importante, es la lista de servicios en una regi贸n en particular.
Algunos servicios est谩n disponibles seg煤n la regi贸n. Muy a menudo, los servicios se proporcionan como una vista previa antes del lanzamiento oficial. Algunas regiones son m谩s r谩pidas para introducir nuevas tecnolog铆as y permiten probar uno u otro servicio emergente. No todas las regiones ofrecen la posibilidad de utilizar la gama completa de series de m谩quinas virtuales.
En nuestra pr谩ctica, la comparaci贸n de la velocidad de acceso a menudo muestra la ventaja de la regi贸n de Europa Occidental. Esto es especialmente notable para las empresas cuyos servidores y clientes se encuentran en la parte europea de Rusia. En cada caso espec铆fico, y especialmente si sus centros de datos y clientes est谩n ubicados en el Lejano Oriente, tiene sentido verificar los retrasos desde su centro de datos (o desde la regi贸n geogr谩fica donde se encuentran sus clientes) para elegir la mejor regi贸n de Azure.
Los servicios como la prueba de latencia de Azure le permiten probar la latencia de forma proactiva en cada una de sus regiones de Azure desde la red de su centro de datos. Un ejemplo de los resultados de medir la latencia utilizando el servicio mencionado al realizar pruebas desde nuestra oficina de Mosc煤:
# 4: C贸mo aplicar m茅todos terrestres a instalaciones en la nube
En cada migraci贸n, nos preguntamos c贸mo utilizar las soluciones tradicionales probadas por la infraestructura cl谩sica en la nube. En particular, al preparar una soluci贸n, confiamos en las recomendaciones del proveedor para desarrollar una soluci贸n t茅cnicamente correcta. Los proyectos de SAP HANA no son una excepci贸n y tambi茅n pasan por el prisma de recomendaciones y mejores pr谩cticas.
En uno de los proyectos, durante la primera etapa de la soluci贸n, se implement贸 un servidor Jump basado en Windows. Para optimizar los costos de la etapa de desarrollo inicial, se implement贸 un servidor NFS en el mismo servidor para las necesidades de entornos improductivos, lo que cubri贸 las necesidades actuales de los desarrolladores y permiti贸 ahorros significativos en recursos.
A medida que pas贸 el tiempo, los entornos y los requisitos de recursos crecieron y el servidor NFS hizo frente a todas las tareas. Poco a poco, en el marco del proyecto, nos acercamos al agotamiento de los recursos de la VM inicial. Los recursos de VM en MS Azure se pueden aumentar en minutos, pero al mismo tiempo se han incrementado los requisitos de tolerancia a fallas del servidor, lo que nos hizo considerar una reconfiguraci贸n mayor.
Para la implementaci贸n se utiliz贸 un servidor Linux, servicio DRBD y la funcionalidad de Conjunto de Disponibilidad, lo que cerr贸 el tema de la replicaci贸n de datos entre los nodos del cl煤ster NFS y aument贸 la disponibilidad en caso de falla de uno de los dos nodos del cl煤ster.
Por cierto: un par de meses despu茅s de la implementaci贸n de la soluci贸n de cl煤ster, se agreg贸 el servicio NetApp Files a Azure, lo que le permite aprovechar los arreglos de NetApp, pero se paga mediante el modelo Pay-As-You-Go.
# 5: C贸mo automatizar la programaci贸n de VM
Cuando se usa cualquier infraestructura en la nube, siempre tiene sentido analizar qu茅 mecanismos adicionales se pueden usar para maximizar el ahorro de costos.
En nuestro caso, los sistemas se prueban durante el horario comercial. Mientras que en la infraestructura convencional el tiempo de inactividad de los servidores se traduce principalmente en un aumento de las facturas de energ铆a, en la nube, los servidores no 煤tiles consumen financiaci贸n para alquilar capacidad. Evaluamos los gr谩ficos de carga en los servidores de prueba y desarrollo y notamos que la inmensa mayor铆a de desarrolladores y evaluadores utilizan el sistema los d铆as de semana de 8 a 20 a 20 a 00.
En los casos en los que el programa de carga en sistemas improductivos es predecible y c铆clico, intentamos usar scripts para automatizar el encendido / apagado de la VM. Azure tiene varias herramientas: apagado autom谩tico, cuentas de automatizaci贸n y Cloud Shell. No todos fueron adecuados para nosotros. Se excluy贸 el apagado autom谩tico porque solo puede apagar la m谩quina virtual. Cloud Shell tampoco estuvo involucrado, ya que requiere que se preparen scripts adicionales, se desarrollen gr谩ficos y en alg煤n lugar seguro para almacenar todo esto con redundancia, lo que redujo los ahorros al m铆nimo.
En nuestro caso, se utiliza un mecanismo m谩s flexible. Automation Accounts ofrece una soluci贸n de trabajo lista para usar en forma de runbooks, lo que le permite encender y apagar las m谩quinas virtuales en un horario.
Preparamos gr谩ficos para los recursos respectivos, cargamos los runbooks y formamos v铆nculos entre los gr谩ficos y los recursos.
Como resultado, hemos reducido a煤n m谩s el costo total de propiedad. Inicialmente, estas herramientas no estaban previstas para su implementaci贸n, pero ya se implementaron en la etapa de operaci贸n preliminar.
El cambio de horario se realiza en unos minutos. Primero, se forma una nueva programaci贸n, luego la programaci贸n generada se asocia con el recurso requerido. Si es necesario y hay una gran cantidad de cambios, es posible usar Cloud Shell para automatizar este proceso.
# 6: Monitoreo del consumo de recursos
Mientras que para los centros de datos convencionales, la supervisi贸n del estado y el consumo de recursos, desafortunadamente, generalmente se desvanecen en un segundo plano, en Azure no es deseable permitir esto. La informaci贸n sobre el historial del consumo de recursos afecta directamente las posibilidades de optimizaci贸n de costos. Y en el caso de la reserva anticipada de recursos, puede servir como se帽al para mejoras arquitect贸nicas.
# 7: Seguro de fuerza mayor
Muchas empresas temen colocar sus sistemas de TI en los recursos de la nube debido al temor a los bloqueos, que anteriormente eran el objetivo de los reguladores. Como cualquier otro riesgo, esto tambi茅n se puede tener en cuenta al dise帽ar un sistema. En los proyectos, por regla general, implementamos una descarga semanal de las copias de seguridad del sistema desde la nube al centro de datos del Cliente. Esto le permite estar seguro de que el sistema se puede restaurar en cualquier eventualidad. Adem谩s de esto, utilizamos una estrategia de instalaci贸n multinube, que permitir谩, en caso de restricciones de acceso, no quedarse sin acceso a los recursos. En este escenario, los proveedores de nube alternativos se utilizan como sitios de recuperaci贸n ante desastres para la nube principal, lo que permite restaurar el sistema en caso de bloqueos masivos.
No. 7 + Tratamiento de datos personales
Durante nuestro trabajo, hemos creado un enfoque sobre c贸mo almacenar y procesar datos personales en sistemas que incluyen recursos de nube externos. Tenga en cuenta que la implementaci贸n de este enfoque debe llevarse a cabo teniendo en cuenta los requisitos de los reguladores. Este tema es bastante extenso, y trataremos de cubrirlo en los siguientes art铆culos si notamos el correspondiente inter茅s en los comentarios.
Salir
En este art铆culo, revisamos varias lecciones pr谩cticas sobre el alojamiento de SAP en la nube de MS Azure. Obviamente, el tema es extremadamente extenso y pudimos tocar solo una parte de las posibles optimizaciones al migrar a la nube.
驴Qu茅 matices has encontrado? Le agradecer铆amos que compartiera su experiencia en los comentarios.