Tomar la decisión de gasto correcta es esencial para migrar a Google Cloud. En cualquier proceso de migración a la nube, el costo es fundamental para la discusión del caso de negocios. En un seminario web anterior , revisamos las ventajas de comprar SUSE a través del mercado.

Érase una vez la historia de un cliente que migra a Google Cloud

Ya tenía suscripciones de SUSE locales y su contrato aún era válido, por lo que decidió llevar las suscripciones a la nube a través de Bring Your Own Subscriptions (BYOS), simplemente porque el cronograma del proyecto no permitía una investigación exhaustiva de las opciones en el mercado de la nube.

Sin embargo, su departamento de compras firmó un compromiso de gasto en la nube con Google la semana pasada. Centralizar las compras de proveedores en un solo lugar hace que las adquisiciones sean más rápidas, eficientes y rentables. Está marcando muchas casillas para cumplir sus objetivos comerciales. Su estrategia es aumentar el consumo en el mercado porque negociaron descuentos sobre el volumen de transacciones en el mercado, y te preguntan si puedes priorizar el mercado: Pago por uso (PAYG) o Descuentos por uso comprometido (CUD) . ) .

El gasto en TI es una parte fundamental de la estrategia FinOps de su departamento de TI. Su dirección ha decidido reforzar la estrategia FinOps y examinar de cerca sus facturas; Sabes que puedes hacer algunos progresos aquí, pero realmente no tuviste tiempo para pensar en ello – ¡Ups!
Además de eso, después de unos meses de experiencia con Google Cloud, ahora que su equipo comprende completamente las especificidades y ventajas de la nube, es posible que se pregunte por qué paga por una suscripción de un año completo en BYOS cuando el tiempo de actividad de la VM son sólo 100 horas al mes, lo que representa aproximadamente el 14% de todo el año…

Ahora se pregunta cómo cambiar sus suscripciones BYOS SUSE a suscripciones Marketplace SUSE ...

La discusión comienza aquí: “Estimado cliente, no se preocupe; nunca es demasiado tarde. Tenemos una solución para ti."
Dado que las bases de datos de SAP HANA suelen ser la mayor fuente de gasto, comencemos desde allí.

Utilice la replicación del sistema HANA para cambiar el modelo de consumo

En la mayoría de los casos, cambiar de modelo de instancia y consumo puede ser complicado y requerir tiempo de inactividad. Se pueden seguir las siguientes técnicas y procedimientos para ayudar a los clientes a lograr un proceso más fluido para SAP HANA.

Replicación del sistema SAP HANA

La replicación del sistema SAP HANA (HSR) brinda la capacidad de copiar y sincronizar continuamente una base de datos SAP HANA en una ubicación secundaria en el mismo centro de datos o en otro. SAP admite el uso de HANA System Replication, por ejemplo, intercambio con un tiempo de inactividad mínimo.

En esta técnica, el usuario puede configurar la replicación del sistema HANA entre las bases de datos que se ejecutan en una instancia BYOS SLES para aplicaciones SAP (origen) y una instancia PAYG/CUD SLES para SAP (destino); ambos ejecutan SAP HANA. La versión del destino debe ser la misma o superior, y la configuración, como el SID y el número de instancia, debe ser idéntica (consulte el manual de SAP para obtener más detalles). Una vez que la base de datos de origen se replica en el sistema de destino, realice una toma de control para convertir el sistema de destino en el nuevo principal, dirija las aplicaciones para que se conecten a la nueva base de datos principal de HANA y cancele el registro de la configuración de replicación del sistema; ahora el sistema HANA se está ejecutando en la instancia PAYG/CUD. La instancia de origen anterior se puede reutilizar o eliminar.

El tiempo de inactividad para cambiar la instancia será el tiempo de ejecución de la transferencia del sistema primario al sistema secundario. Por lo general, esto ocurre dentro del rango de unos pocos minutos. Para obtener más información, consulte la nota de SAP 1984882 : uso de la replicación del sistema HANA para el intercambio de hardware con un tiempo de inactividad mínimo.

Requisito previo: Tanto la instancia de origen como la de destino deben aparecer en el Directorio de hardware certificado y compatible de SAP HANA .

Caso de uso

Debido a que SAP HANA System Replication permite un tiempo de inactividad mínimo, tiene muchos casos de uso. El modelo de consumo del cambio es uno de ellos. Otros usos incluyen cambio de tamaño de instancia, retiro de instancia, actualización del sistema operativo, cambio de región, etc. Se recomienda encarecidamente a los clientes que primero realicen pruebas en lugares que no sean de producción.

Conclusión

Convertir suscripciones BYOS en suscripciones de Marketplace es una pregunta muy común que recibimos de muchos de nuestros clientes; Esperamos que este blog responda a tus preguntas. Si necesita ayuda y desea hablar con el equipo de Google Cloud, no dude en contactar en google@suse.com . 

Por Elodie Mallet y Sherry Yu