Download - 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
-14-
-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-
FAS/V-Series Primario
Apliaciones de Negocio
FAS/V-Series Primario
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
-35-
-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
¿Cuánta información puedo perder?
RPO
¿Cuánto puedo esperar a recuperar el servicio?
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
¿Cuánta información puedo perder?
RPO
¿Cuánto puedo esperar a recuperar el servicio?
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
Application Consistency
Segundos Horas Minutos
¿Cuánta información puedo perder?
RPO
¿Cuánto puedo esperar a recuperar el servicio?
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
Application Consistency
Segundos Minutos
¿Cuánta información puedo perder?
RPO
¿Cuánto puedo esperar a recuperar el servicio?
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
Application Consistency
Días Horas
¿Cuánta información puedo perder?
RPO
¿Cuánto puedo esperar a recuperar el servicio?
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
Cliente o NEXICA NEXICA Barcelona o Madrid
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
Cliente o NEXICA NEXICA Barcelona o Madrid
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