Workshop Nexica & NetApp

-1-

Modelos de Alta Disponibilidad y Contingencia (DRS)

-2-

Introducción al cloud Public, private & hybrid cloud

Jordi Tomás

Ingeniero Preventa - Nexica

-3-

Modelos de despliegue

CLOUD PRIVADO CLOUD HIBRIDO CLOUD PÚBLICO

• Mejora la gestión TI

• Mejoras modestas en costes

• Escalabilidad y flexibilidad

limitadas

• Riesgo de obsolescencia

• Gestión limitada de picos de

demanda.

• Proyectos a medida (Cloud

Expertise)

• Mayor escala, costes más

bajos

• Difícil integración con ‘Legacy’

• Dudas sobre calidad y

seguridad

• Mejor para aplicaciones no

críticas.

• Mix de los anteriores

• Dudas sobre calidad

• Dudas sobre seguridad.

• Adecuado en escenarios de

desbordamiento y poco

críticos.

• Proyectos a medida (Cloud

Expertise)

-4-

Public Cloud Un despliegue de Cloud Público se caracteriza por ofrecer una oferta de computación virtualizada (CPU, RAM, Disco, Sistemas operativos, bases de datos, etc.) para múltiples clientes, accediendo estos a través de internet o VPNs.

Agilidad

Opex

Elasticidad

Economía y eficiencia de costes

CPDs Extenos (proveedor del servicio)

Gestión infraestructura

Selección y evolución

tecnológica determinada

por el proveedor

-5-

• Cloud Hosting

• Cloud On Demand

• Cloud Pool

• Cloud Complements: o Redes y direccionamiento

o Balanceo y aceleración

o BackUp

o Seguridad

o Orquestador

o Managed Services

Public Cloud Ejemplo: catálogo de servicios

-6-

Private Cloud Una nube privada o nube interna es aquella en que solamente una organización, utilizando tecnologías de computación en nube como la virtualización, tiene acceso a los recursos que se utilizan para implementar la nube. Es decir, una empresa dispone de un entorno cloud en exclusiva (ya sea IaaS, PaaS y/o SaaS).

Capex + Opex

Pago por Uso

Elasticidad

Agilidad

Seguridad

CPD Cliente CPD Exteno

Control

Obsolescencia Selección

tecnológica

Tipología de clientes: Organización con alta

concentración de recursos y sistemas tecnológicos.

P.e.: Entidades bancarias, Administración Pública,

investigación y desarrollo, consultorías y asesorías

legales / tecnológicas / negocio, factorías de

software / Desarrollo, etc.

-7-

• Mayor agilidad y autonomía en la provisión de servicios:

de días a minutos

• Integración con los servicios de infraestructura propios

(backup, balanceadores, red, etc).

• Normalmente se ofrece con capacidades de

interconexión con infraestructuras de tecnologías

similares e implementaciones comunes

• Capacidad para realizar desarrollos propios

completamente personalizados

• No tiene mucho sentido desarrollar un modelo elástico

en un Cloud Privado (excepto grandes organizaciones)

• No es viable un pago por uso, ya que los recursos

sobrantes no se pueden revender a otras

organizaciones.

Pago por uso

Capacidad Elástica

Recursos Virtualiza

dos

Provisión Automatiz

ada

Provisión Self-

Service

Infraestructura de Terceros

Gestión externa

Cloud Privado

Private Cloud Ventajas genéricas

-8-

• Tecnologías implementadas líderes.

• Capacidades de interconexión con el Cloud Público de Nexica

(Hibridación)

• Absorber puntas de computación

• Establecer un entorno de DRS

• Capacidades de absorber la gestión y administración en nombre

del cliente.

• Capacidades de despliegue de Cloud Manager (orquestador,

planificador, panel de gestión) personalizado.

• Garantías de Nivel de Servicio (SLA) según política de empresa.

• Formación para la Gestión del Servicio y Recursos

• Experiencias de implantación reales:

Private Cloud Ventajas adicionales Nexica

-9-

Un despliegue de Cloud Híbrido es aquel que combina recursos del Cloud Privado con los del Cloud Público.

Infraestructura dedicada

Cloud Público

Control

Seguridad

Selección tec.

Agilidad

Opex

Elasticidad

Líneas dedicadas

Internet

VPN

conexión

Economía y agilidad, sacrificando control

CPD Cliente CPD Exteno

Agilidad

Hybrid Cloud

-10-

Uso ¿Qué aporta la hibridación?

Aplicaciones de Back Office Distribución de carga.

Pruebas de concepto. Laboratorio Recursos de desarrollo siempre

disponible.

Frontales Web Desbordamiento de capacidad.

Soluciones de recuperación de

desastres

“One-click recovery” (mantiene clones actualizados de las VM de las

aplicaciones críticas para un rápido despliegue en caso de

incidencia)

Hybrid Cloud Ejemplos de casos de uso

-11-

+

-

Cri

tici

dad

par

a el

neg

oci

o

+ - Requisitos de rendimiento

Servicio A

Servicio B

Servicio C

Servicio D

Servicio E

Servicio F

Servicio X

1. Analizar la criticidad respecto al negocio.

2. Garantizar el rendimiento de la aplicación:

• Latencias de la conectividad

• IOPs • Capacidad de

computación 3. Análisis de crecimiento

• Elasticidad

Zona de hibridación

Hybrid Cloud Analizar los servicios/aplicaciones a hibridar

-12-

Seguridad En una cloud híbrida, la seguridad se debe iniciar en el sitio

donde comienza la transferencia de datos. Por lo tanto, es

necesario encriptar los datos antes de ser enviados para que

no estén expuestos. Es necesario realizar la comunicación a

través de una conexión privada (VPN).

Hybrid Cloud Principales aspectos a tener en cuenta

Hypervisor Si el hypervisor del Cloud Público es diferente al del Cloud

Privado, es necesario utilizar un SW de conversión eficiente.

Analizar y entender los datos Es necesario un análisis previo de la información y reconocer

que datos requieren mayor nivel de seguridad, cuales

necesitan cumplir determinados requisitos legales, cuales

varían poco con el tiempo, etc. para definir una arquitectura

segura y a la vez flexible.

Gestión y administración Las nubes híbridas requieren niveles mayores de

automatización en la gestión y administración (de lo contrario

se complican los procesos de gestión de cambios). De este

modo lograremos mayores grados de disponibilidad,

rendimiento y seguridad.

Visión completa y unificada del

servicio Puesto que los diferentes recursos se encuentran ubicados en

CPDs diversos y son gestionados por organizaciones

diferentes, es importante asegurar la visibilidad del conjunto a

través de alguna herramienta transparente y única.

-13-

CARACTERÍSTICAS

•Una separación de roles estricta permite implementar un Cloud Híbrido

con el nivel de seguridad alto.

• Los frontales solo pueden consumir información a través de los

servicios publicados por los servidores de aplicación.

• La aplicación reside en un repositorio único en el Cloud Privado.

Servidores de aplicaciones

Bases de Datos

Frontales Permanentes

Cloud Privado Cloud Público Red privada con aislamiento

lógico.

BBDD en Cloud Privado

Servidores frontales Stateless.

comunicaciones seguras

Hybrid Cloud Ejemplo de implementación

• Los servicios en producción se configuran en una solución de Private

Cloud, y los desbordamientos estacionales se absorben desde la capa

elástica del Cloud Público.

•Un único interfaz web de cliente gestiona todo el entorno.

Frontales Temporales

-15-

Modelos de Alta Disponibilidad

y Contingencia (DRS) - I

Javier Ocaña

Systems Engineer - NetApp

-16-

Snapshots, nuestros backups como primer nivel de protección.

NetApp SnapVault. (D2DBackup)

DRS con NetApp SnapMirror.

Topologías DR

-17-

Crecimiento

Crecimiento de datos 30-50% por año

Los métodos

tradicionales de

protección no escalan

a este nivel

Complejidad

Difícil integración

entre tecnologías

nuevas y existentes

Gestionar diferentes productos provoca esfuerzos extras

Coste

Inversión en IT congelada o decreciendo

Necesario utilizar los

recursos existentes

de forma óptima y

eficiente

Riesgo

Tiempos de

recuperación elevados

que impactan en el

negocio

Incumplimiento de

acuerdos de nivel de

servicio

Incumplimiento de requisitos legales

-18-

• Los métodos tradicionales de protección no escalan

con el ritmo del crecimiento de los datos.

• En los sistemas de almacenamiento NetApp:

– La protección es una parte inherente de la

arquitectura de almacenamiento

– El alto grado de integración de las funcionalidades

de protección permite:

• Control

• Eficiencia

• Simplicidad

• Agilidad

-19-

Continuous Availability

Disaster Recovery

Backup & Recovery

Archive & Compliance

Policy Driven Data Availability

RTO

RPO Cero- Minutos- Horas 4-24 Horas Días - Meses

Segundos Minutos Horas - Días

RPO/RTO Optimizado

Coste/TB Optimizado

Retención Días - Semanas Meses - Años Varios Años

-20-

Backup Copies

Snapshot™

Copies

Asynchronous Mirroring

Synchronous Mirroring

Array Clustering

Security & Compliance

Continuous Availability

Disaster Recovery

Backup & Recovery

Archive & Compliance

Policy Driven Data Availability

RPO/RTO Optimizado

Coste/TB Optimizado

-21- 21

Copias de seguridad

NetApp

-22-

Apliaciones de Negocio

FAS/V-Series Primario

1. Snapshots

Primer nivel de protección

integrado en toda la gama de

sistemas de almacenamiento

NetApp

– Backup y restauraciones

instantáneas (mejor RTO)

– No es Copy-On-Write

– 255 Snapshots por volumen

– No penaliza el rendimiento de la

cabina

– Cada Snapshot es un Full Backup

pero solo almacena los cambios

– Permite incrementar la frecuencia

de backup (mejor RPO)

-23-


Apliaciones de Negocio


1. Snapshots

FAS/V-Series Secundario

2. SnapVault

Compresión + Deduplicación

-24-

• SnapVault permite archivar los Snapshots sobre un sistema NetApp secundario:

– Solo necesita conectividad IP

– Posibilidad de almacenar meses o años de puntos de recuperación en el sistema secundario

– Transferencia optimizada en base a bloques modificados minimizando el tiempo de backup

– El Fan-In permite concentrar varios flujos de datos en un único volumen destino

-25-

Production Environments (on NetApp or Non-NetApp Storage)

Host or Array- based Replication

Dynamically-allocated Server Resources

Secure, Native Data on Shared Storage with Fast, Efficient Snapshot™ and Cloning

Public or Private Cloud

Multi-use Copies

Operational recovery

BC with failover test

Test/dev workflows

Big data analytics

Reporting, e-discovery, etc.

-26- 26

-27-

SnapMirror es una solución “thin replication” basada

en la tecnología Snapshot de Data ONTAP.

– Replicación de Volumenes o Qtrees entre orígen y

destino para todos los modelos de NetApp.

– Transfiere únicamente los cambios realizados en

bloques de 4KB.

– Soporta réplicas síncronas, semi-síncronas y

Asíncronas.

– Reduce los requerimientos de ancho de banda en un

70% con la compresion nativa de red.

– Trabaja con Volumenes deduplicados en orígen

– Compatiblilidad entre diferentes sístemas y discos

(Arrays-Third Part) con V-Series.

-28-

Definición del conjunto RPO’s.

Sync: Zero RPO, hasta 200Km.

Semi-Sync: Near-zero RPO; 500Km

Async: RPO minutos-horas, largas distancias

Replicas mediante Snapshots copias para multiples

RPO’s.

Soporte Flexible configuración

Diferentes modelos y discos

Many to Many

3 nodos DR (sync and Asyn conjuntamente)

Extiende los beneficios de la Eficiencia del Storage

Hasta un 90% menos de capacidad requerida

DR Backups permanecen deduplicados

Usando la compresion de red hasta un 70% menos

de datos y reduce los costes/accelera RPO

-29-

SnapMirror síncrono

3 4

1

4 2

SnapMirror semi-síncrono

1

2

SnapMirror asíncrono

3 Cada Escritura

2 Cada Escritura

A B

3

1

2

Bloques cambiados

Intervalos

1 Sin pérdida de datos

Distancia < 100 km

Impacta en rendimiento*

Segundos de pérdida de datos

Distancia > 100 km

Pequeño impacto en rendimiento*

Pérdida de datos 1 min - horas

Sin limite de distancia

Sin impacto en rendimiento*

Volumen o Qtree

-30-

Topologías Disaster

Recovery

-31-

Flexible RPO

SnapMirror ofrece flexibilidad RPO en un único producto

SnapMirror Sync and SnapMirror Async, puede ser configurado en cascada para lograr DR local y regional

Diferentes volumenes pueden ser replicados en diferentes intervalos proveyendo anchos rangos en RPO

Primary Site Remote Site

VolA VolA’’ VolA’

SnapMirror® Sync SnapMirror Async

VolB

SnapMirror Async VolB’

-32-

Tape Library

SnapMirror®

Production Site DR Site

Replication Uninterrupted

DR Testing

FlexClone® Volumes

Flexible, easy, and efficient data replication with SnapMirror

Put the DR site to use by creating space-efficient copies for DR testing, dev/test, and business intelligence

Production operations uninterrupted

Replication uninterrupted

-33-

SnapVault®

Volume SnapMirror®

Async

Multiple systems at primary data center

Disaster recovery for many systems

Protection from regional disasters

FlexClone volumes for multiple purposes

Stagger VSM and SV schedules

FlexClone® Volumes

Production Site Standby DR Site

-34-

One-to-many or many-to-one flexible configuration for async mode

Remote read-only replicas can be used for data distribution

Read-only replicas can be instantly made writable and used for test, dev, and stage purposes

Primary Site

FlexClone® volumes can be made instantly writable

R/W

R/W R/O R/W R/O

Remote Site 2

Replicas can be used for read access

Remote Site 1

-36-

Modelos de Alta Disponibilidad

y Contingencia (DRS) - II

David Suárez

Director de Tecnología y Operaciones - Nexica

-37-

RTO / RPO

Minutos Horas Días Días Horas Minutos

¿Cuánta información puedo perder?

¿Cuánto puedo esperar a recuperar el servicio?

Consistency (Consistencia)

Crash consistency Transaction / Application

• Se mantiene el orden de escrituras de datos a disco de forma que es posible recuperarse de una interrupción inesperada.

• La aplicación que maneja los datos debe tener mecanismos para depurar las operaciones no finalizadas y arrancar correctamente.

• Garantiza el arranque del sistema operativo y la capacidad de leer los ficheros

• La de transacción garantiza la atomicidad de una transacción (no hay transacciones a medias). Ejemplo: transacciones de bases de datos.

• La consistencia de aplicación garantiza un conjunto de transacciones relacionadas en el marco de una o varias aplicaciones. Ejemplo: Creación de un usuario en Active Directory.

-38-

En entornos virtuales

VMware ESX acknowledges a write or read to a guest operating system only after that write or read is acknowledged by the hardware controller to ESX.

Applications running inside virtual machines on ESX are afforded the same crash consistency guarantees as applications running on physical machines or physical disk controllers.

Semanas Días Horas Minutos Segundos 0

RPO

RTO

Múltiples Estrategias de DR

La virtualización no añade nada nuevo a los viejos conceptos sobre consistencia.

-39-

Sin Cloud

x 2

• Duplicamos la infraestructura y complicamos la gestión de los cambios. Se duplican los costes.

• A menudo se sugiere aceptar una degradación de los niveles de calidad de servicio a cambio de relajar los requisitos de infraestructura en el sitio secundario. Lo que aumenta entonces es la complejidad en la gestión de cambios.

• Pago por uso. Pagamos una tarifa muy reducida por el “stand by”.

• Puede ser casi transparente para la gestión de cambios (cloud2cloud)

• Capacidad elástica (no es necesario preocuparse por la capacidad del sitio secundario)

• Planes de recuperación automatizados y simulacros menos costosos.

Con Cloud

-40-

• El hipervisor replica las imágenes de las VM’s.

• Hace una primera copia completa y a partir de aquí va actualizando con snapshots más pequeños.

• No requiere ninguna instalación en la VM y es independiente del sistema operativo. Su gestión es sencilla porque no depende en absoluto del que contenga la máquina.

• No supone una sobrecarga significativa para el servidor replicado (entre un 2% y un 6% de sobrecarga)

• Permite una recuperación de la máquina virtual en minutos.

• Permite la automatización parcial o total de los planes de recuperación (puesto que el hipervisor tiene el control de todos los servidores y a menudo del direccionamiento de red)

Cloud

Cloud

Crash Consistency

Minutos Horas Minutos


RPO


RTO

Basada en Hipervisor

Application Consistency

*

-41-

• Se establece una comunicación directa (alta velocidad) entre 2 cabinas SAN compatibles y se lleva a cabo una replicación en tiempo real de todas las escrituras a la cabina de origen.

• Es completamente transparente para las máquinas protegidas.

• No supone ninguna carga de trabajo para los servidores protegidos.

• Se pueden conseguir RPO’s muy bajos (segundos)

• Se puede utilizar para replicar los volúmenes que contienen las máquinas virtuales, para replicar volúmenes de datos independientes del hipervisor y almacenamiento SAN utilizado por servidores físicos.

Basada en SAN

Cloud Cloud

Crash Consistency

Segundos Horas Minutos


RPO


RTO

Físico Físico

-42-

• Se instalan agentes en cada uno de los servidores que van a replicarse.

• Los agentes penalizan el rendimiento del servidor (un 30% de impacto sobre las operaciones de escritura en disco, según pruebas de concepto de NEXICA)

• Los agentes requieren instalación individualizada, monitorización y actualizaciones.

• No hay agentes para todos los sistemas operativos y versiones.

• Es el único mecanismo capaz de replicar servidores físicos sin necesidad de tener cabinas SAN compatibles en los dos extremos.

• Con agentes específicos para determinadas aplicaciones, se puede asegurar la consistencia a nivel de aplicación

• Los planes de recuperación son manuales, y sólo se replican datos. La gestión de cambios está duplicada

Basada en Agentes

Cloud Cloud


Segundos Horas Minutos


RPO


RTO

Físico Físico

Crash Consistency

-43-

• Algunas aplicaciones y bases de datos disponen de mecanismos propios para la replicación entre varias ubicaciones (ejemplos: SQL Server, Oracle RAC o Dataguard, Exchange, Active Directory)

• Independientes de que los servidores de origen y destino sean físicos o virtuales (cualquier combinación es posible)

• Garantizan el nivel más alto de consistencia. Esto es especialmente importante en bases de datos (consistencia de transacciones, RPO tendiendo a cero)

• Pueden funcionar también como mecanismos de redundancia para el alta disponibilidad, incluso en configuraciones activo/activo.

Nativa de Aplicación

Cloud Cloud


Segundos Minutos


RPO


RTO

Físico Físico

-44-

• Es similar a la replicación basada en agentes, pero en este caso sólo se replican los datos a nivel de aplicación (no los ficheros) con agentes de Backup al lugar de recuperación.

• En el caso de servidores virtuales, el Backup de datos puede copiar los ficheros que contienen las máquinas virtuales (con el que se replicarían datos y servidores).

• En el caso de servidores físicos, sería necesario una virtualización periódica en origen (manualmente) y copiarlos en el lugar de recuperación mediante estos agentes de Backup.

• En este caso los datos estarían sincronizados cada 24 horas (no hay replicación continua en agentes de Backup) y las configuraciones de los servidores lo estarían a periodos más largos (entre 1 y 3 meses)

Backup Remoto

Cloud Cloud


Días Horas


RPO


RTO

Físico Físico

Horas

-45-

RTO: NBD – 1 hora RTO: 6 hores

Replicación en Hipervisor (RPO mínimo: 15 minutos) Replicación en SAN (RPO ~ 0)

Replicación en SAN (RPO ~ 0) Backup Diario de Datos + Virtualización (RPO 24 horas)

Replicación Nativa (Activo/Pasivo) (RPO 0)

RTO: 2 hores

Servidores Virtuales sin BBDD’s

Servidores Físicos sin BBDD’s

Servidores Virtuales o Físicos con BBDD’s

Servidores con BBDD’s Oracle

Backup Diario de Datos + Virtualización (RPO 24 horas) Oracle Streams / Golden Gate (RPO ~ 0)

-46-

Encendido Configuración post-

arranque

Activación de

Servicios

Encendido

Conf. P. A.

Activación Servicios

Configuración post-arranque Activación de

Servicios

RTO total

Declaración del Desastre

-47-

Gestión de Cambios

Controles Periódicos

Recursos

• Hay que identificar claramente qué cambios afectan al DRP (aquellos que no se ejecutan automáticamente en el site secundario).

• Es muy difícil (y costoso) mantener un DRP sin un proceso de gestión de cambios formal.

• Tener en cuenta el impacto de cada solución en la gestión de cambios. La estrategia debe optimizar el TCO de los servicios (no nos fijemos sólo en los costes de infraestructura)

• Automatización = Menos coste

• Menos coste = Más periodicidad

• Más periodicidad = Menos Riesgo

• Siempre hacemos planes, procedimientos y procesos suponiendo una serie de garantías (la gente responderá racionalmente, aplicará el sentido común, vendrán a trabajar al día siguiente, obedecerán a sus superiores, tendremos ordenadores y líneas telefónicas, etc.)

• Según la magnitud del desastre, ninguna de estas garantías puede darse por segura.

• Contar con recursos externos (que no se vean afectados por el desastre) puede ser una buena idea.

-48-

DNS

DNS Internos

Herramientas de Gestión

• Cuando se trata de proteger comercios electrónicos o webs públicas, hay que tener en cuenta la re-configuración de los DNS dentro del RTO.

• O bien modificamos el tiempo de actualización de los DNS (saltándonos buenas prácticas) o recurrimos a soluciones de Global Load Balancing.

• Incluir direcciones IP dentro del código

• No mantener la sincronización de los DNS’s internos que permita resolver los nombres de los servidores internos

• No contar con herramientas de monitorización en el sitio secundario

• No contar con herramientas de administración y soporte a la resolución de incidencias en el sitio secundario (gestión de tickets, consolas de acceso, etc.)

• Continuidad de servicios básicos de Telefonía y Correo

-49-

Hipervisor

Cliente o NEXICA NEXICA Barcelona o Madrid

Agentes

Nativa

• Pago por Uso (en “stand by” las máquinas están apagadas, sólo se paga almacenamiento).

• Todas las ventajas de gestión de entornos virtuales. • Alcance variable en origen, capacidad en destino flexible. • Servicio 100% delegado (en plataformas gestionadas por NEXICA). • Posibilidad de contratar Virtual Datacenters en plataformas gestionadas

por el cliente.

-50-

Hipervisor


Agentes

• Pago por Uso del almacenamiento. • Todas las ventajas de gestión de entornos virtuales. • Alcance variable en origen, capacidad en destino flexible. • Servicio 100% delegado (en plataformas gestionadas por NEXICA). • Posibilidad de implantar proxy de Veeam backup en Nexica y gestion del

cliente.

-51-

Hipervisor


Agentes

• Volúmenes compartidos, réplica de volúmenes y snapshots. • Oferta de todos los tiers de servicio de storage. • Servicio 100% delegado (en plataformas gestionadas por NEXICA) y

compartido en escenario con origen casa del cliente. • Acceso por VPN y circuito dedicado multioperador.

-52-

Gracias por vuestra atención

Workshop Nexica & NetApp

Documents

Transcript of Workshop Nexica & NetApp