En este post, repasamos algunas consideraciones importantes para planificar la continuidad del negocio (BC) y la recuperación ante desastres (DR).
La continuidad del negocio necesita una cuidadosa consideración cuando se usa Couchbase como un servicio central del negocio. Hoy nos centraremos en la capa de aplicación y en las razones e implicaciones de los impactos en los servicios.
Cuando se utiliza Couchbase como sistema persistente de registro, Alta disponibilidad (HA), DR y BC deben entenderse cuidadosamente para garantizar que cumplen los niveles de servicio acordados (SLA).
En un mundo en el que las interrupciones del servicio y el tiempo de inactividad pueden afectar gravemente al negocio, las empresas deben asegurarse de que están sólidamente protegidas para minimizar el impacto en el negocio, ya sea para sus accionistas y clientes internos o externos.
Además, las bases de datos suelen ser críticas para el funcionamiento del negocio y centrales en la ecosfera de aplicaciones de una empresa. Si la base de datos se cae, su fallo afectará a otros servicios. La importancia de este impacto solidifica por qué debe protegerse contra las interrupciones inesperadas del servicio.
Históricamente, las empresas se conformaban con un 99,9 de tiempo de actividad del servicio. Ahora las organizaciones buscan seis nueves o más (99,9999 o 31 segundos al año). Antes, las empresas podían tolerar interrupciones de varias horas, pero esto ya no es así, por lo que es imprescindible comprender los requisitos de la empresa.
Antes de diseñar una estrategia para satisfacer un requisito empresarial, primero tenemos que entender los Acuerdos de Nivel de Servicio (SLA) y cómo se miden.
Un SLA es un compromiso con su cliente para poner en marcha los servicios en un plazo acordado.
Medir los SLA en función de lo que importa
También tenemos que entender las métricas con las que se miden generalmente la disponibilidad y los SLA, y hay principalmente dos:
Objetivo de Punto de Recuperación (RPO)
"¿Cuántos datos puedo permitirme perder?".
-
- Expresado hacia atrás en el tiempo desde el instante en que se produce un fallo.
- Puede especificarse en segundos, minutos, horas o días.
Objetivo de tiempo de recuperación (RTO)
"¿Cuánto tiempo puedo permitirme que el servicio no esté disponible?".
-
- ¿Cuánto tardarán los datos en volver a estar disponibles?
- Función del grado en que la interrupción perturba las operaciones normales y la cantidad de ingresos perdidos por unidad de tiempo como resultado del desastre.
- Puede especificarse en segundos, minutos, horas o días.
Cuando hablamos de HA/DR y BC, ¿qué queremos conseguir? La capacidad de restablecer el funcionamiento normal (o casi normal) de la empresa, desde la perspectiva de las aplicaciones empresariales críticas, tras producirse un incidente que interrumpa las operaciones empresariales. Esencialmente, cumplir los requisitos RPO/RTO deseados.
Entender por qué falla un servicio
Además, hay que tener en cuenta la anatomía de por qué falla un servicio, ya que esto afectará a la forma en que los servicios necesitan protección.
Cada una de las razones citadas (a continuación) para el fallo de aplicaciones/servicios tiene diferentes impactos y connotaciones, y con frecuencia requieren otras soluciones, consideraciones y construcciones para garantizar una protección completa.
Otra consideración crítica que hay que revisar es la idea errónea de que las interrupciones del servicio sólo afectan a la pérdida directa de ingresos; normalmente no es así, ya que muchos sistemas no son generadores de ingresos. Si ampliamos este concepto, hay muchas más razones para disponer de soluciones de continuidad de negocio:
-
- Daños a la reputación o a la marca
- Pérdida de negocio en favor de una empresa o proveedor rival
- Pérdida de productividad: los equipos no pueden desempeñar sus funciones y servicios internamente.
- Sanciones económicas de los consejos reguladores: posibilidad de que no se le permita operar.
- Muerte Fallo de los sistemas hospitalarios/médicos que provoca la cancelación de operaciones/tratamientos
- Repercusión en otros servicios internos
Opciones de mitigación
Entonces, ¿cuáles son las opciones para proteger y mitigar una interrupción del servicio de aplicaciones?
-
- Agrupación en clústeres: varios nodos para evitar un único punto de fallo
- Replicación: garantizar que las aplicaciones y los datos estén disponibles en múltiples ubicaciones y geografías.
- Copias de seguridad: para recuperarse de incidentes catastróficos
Cada una de estas opciones puede ayudar a proteger contra la interrupción del servicio y la recuperación de los servicios empresariales normales. Y cada una de ellas tiene diferentes implicaciones de RPO y RTO que deben tenerse en cuenta en los SLA exigidos por la empresa.
Uno de los principios clave de Couchbase, nuestro ADN si se quiere, es que estamos diseñados para estar altamente disponibles, proporcionar resiliencia y garantizar el cumplimiento de los SLA.
Couchbase ofrece estas tres soluciones (clustering, replicación, copias de seguridad), que están totalmente diseñadas e integradas para mitigar las interrupciones del servicio y minimizar el tiempo de inactividad.
Disponibilidad estratégica
Recuerde que la elección de la estrategia de disponibilidad correcta tendrá un gran impacto en la disponibilidad y el cumplimiento de los SLA. Es fundamental comprender y definir los SLA necesarios.
Es mejor acertar con la estrategia inicial que revisarla tras una interrupción del servicio.
Tendrá que ser realista en cuanto a los plazos de recuperación y tener en cuenta las implicaciones económicas y quién las financiará.
El primer paso es comprender los objetivos empresariales y las necesidades de las aplicaciones. A partir de ahí, investigue qué cumplirá sus SLA y los objetivos de la empresa.
La próxima vez, veremos cómo Couchbase puede hacer soluciones altamente disponibles con clustering.
