http://summit.solidq.com
En esta sesión veremos diferentes escenarios de uso de replicación de SQL Server para cubrir necesidades de sincronización de información entre múltiples entornos geográficamente dispersos.
2. Agenda
3
1. Replicación en escenarios complejos
2. Balanceo de carga SQL
3. Entornos desconectados de la nube
4. Reducción de latencias contra la nube
4. Replicación en escenarios complejos
Organizaciones complejas
– Oficinas, múltiples CPDs y cloud
– Master data management
WAN vs LAN
– Ancho de banda
– Latencia
Patrones de replicación
Escalado horizontal
Tolerancia a fallos
Reducción de latencia
12. Ancho de banda disponible
TCP utiliza regulación
de flujo mediante
ACKs
– Si no llega un ACK se
presupone congestión
Uso de redes móviles
– Mayor tasa de errores
– Mayor latencia
13. Latencia y transacciones/sec
Crítica en sistemas OLTP
Crítica en sistemas con
procesos operando fila
a fila.
Consideraciones
– Reubicación de capas
– Empaquetado en
batches
– Explotar paralelismo
14. Cómo ayuda la replicación
Localidad de los datos
– Cloud / CPD remoto
– CPD local
– Máquina local
Ancho de banda y latencia
– Cloud / CPD remoto Pocos Mbps, compartidos, asimétricos,
alta latencia
– CPD local Algunos cientos de Mbps, compartidos,
simétricos, baja latencia
– Máquina local
• Por TCP 1 Gbps, dedicados, simétricos, muy baja latencia
• Por Shared Memory Decenas de Gbps, dedicados, simétricos,
ultrabaja latencia
18. Master-Master por filas
Acceso lectura/escritura
Resolución de conflictos
Coordinador de
sincronización
Replicación de mezcla
19. Master-Master por transacciones
Acceso lectura/escritura
Diseño específico
– Sin conflictos
– Sin bucles
Replicación transaccional actualizable
Replicación P2P
– Puede ser multinivel
– Conectada totalmente o parcialmente
22. Escenarios de balanceo
Escalabilidad horizontal y alta disponibilidad
Carga de solo lectura
– Transaccional 1 a N
– Snapshot 1 a N
– Mezcla 1 a N (artículos download only)
Carga de lectura/escritura
– Transaccional actualizable 1 a N
– P2P N a N
– Mezcla 1 a N
23. Balanceadores
Transparentes
– Balanceador hardware
– Afinidad por IP, round robin…
– Detección de nivel de carga y no-disponibilidad de nodo
No transparentes
– Controlado por software (middleware o cliente)
– Particionado de carga más inteligente
– Más flexible y adaptable
– Adaptación de aplicaciones existentes
Mixtos
24. DEMO
25
Balanceo con sistema automático
de suscripciones en función de la
carga
25. Balanceo de carga SQL
La replicación permite crear soluciones con
escalabilidad horizontal
Requiere trabajo de diseño y mayor
mantenimiento
Puede combinarse con esquemas en cascada
– Reducción de latencia
– Aumento de disponibilidad local
Tolerancia a estados incoherentes entre nodos
Troubleshooting más complejo
27. Escenarios desconectados
Criticidad de la operativa
– Cajas de un supermercado
– Acceso a datos hospitalarios
Conectividad limitada a Internet o sincronización
controlada
– Entornos móviles
– Tarifas de datos / Wifi
En nube pública
– No controlamos las ventanas de mantenimiento del
proveedor
– Poca capacidad de presión en caso de incidencia
28. Escenarios desconectados en la nube
Máquinas virtuales pequeñas
– Escenarios con republicaciones
– BBDD escalables/particionadas horizontalmente
Alta disponibilidad más compleja
– El distribuidor solo soporta HA con failover clustering
– Grupos de disponibilidad para las distintas VMs
Si no queremos utilizar VPNs
– Protocolo TDS con SSL
– Replicación de mezcla con sincronización web por
https
29. DEMO
30
IIS balanceado en la nube para
replicación de mezcla con Web
Synchronization
30. Escenarios desconectados en la nube
La nube encaja bien como CPD global, no tanto como CPD
local
– Disponibilidad de recursos casi ilimitados
– El alta disponibilidad no está garantizada
• SLA VMs >= 99,95% uptime tolerar hasta 5 minutos de downtime
por semana
• Uptime < 99,95% 10% descuento, Uptime < 99% descuento 25%
• “Los abonos de servicio en cualquier mes no excederán, bajo ninguna
circunstancia, las tasas mensuales de Servicio del Cliente” Peor
escenario para MS = no cobrar ese mes
La seguridad de las comunicaciones es importante
– La replicación transmite los datos en claro
– Muy poca gente utiliza SSL sobre TDS (por defecto en SQL
Database)
32. Estrategias de cacheo
Cacheo “in-process”
– Más rápido
– No compartido
– Capacidad total limitada
Cacheo “out of process”
– Puede ser compartida
– Mayor capacidad
– Azure Cache, MemCached, Redis…
– Instancia de SQL Server In-Memory
– Ficheros locales Filetable
33. Estrategias de empaquetado
Batches pequeños vs batches grandes
Procedimientos almacenados temporales
SET NO COUNT
Compresión de datos
– Compresión de texto
– Compresión binaria
35. Conclusiones
Cada vez las organizaciones tienen
infraestructuras más complejas
Sincronización con CPDs remotos y cloud
– Latencia
– Ancho de banda
Patrones de replicación de datos
Escalado horizontal
Tolerancia a fallos
Reducción de latencia
36. Si quieres disfrutar de las mejores sesiones de
nuestros mentores de España y Latino América,
ésta es tu oportunidad.
http://summit.solidq.com
Síguenos:
40
Notas del editor
16:48 – 3 minutos
Las organizaciones medianas-grandes tienen muchas ubicaciones, los clientes valoran la localidad
WAN vs LAN
Tipica aplicación que “nace” en LAN y empieza a dar más servicio a distintas oficinas y dptos. Una opción es rediseñarla, otra adaptarla para replicación.
16:53 – 8 minutos
17:00 – 15 minutos
17:05 – 20 minutos
SQL no dispone de un sistema de balanceo incorporado
Transparentes:
Menos control por parte de la aplicación, solo ve una IP,
Mas sencillos
Si no los redundamos, riesgo de punto de fallo
No transparentes:
Más control por la aplicación, que tiene N IPs donde enviar conexiones
Permite enviar peticiones priorizadas de un Idcliente a un nodo más potente por ejemplo o hacer una especie de federaciones/sharding manual
Más complicado de manejar
17:10 – 25 minutos