soluciones de alta disponibilidad y escalabilidad con sql server 2000 diego casali systems engineer...
TRANSCRIPT
Soluciones de Alta Disponibilidad y Escalabilidad con SQL Server 2000
Diego CasaliSystems Engineer
Microsoft de Argentina
Region Cordoba y NOA
Agenda• Que entendemos por Alta
Disponibilidad (HA)?
• Tecnologías de HA
• Administrando para HA
• Diseñando una Solución para HA
Alta Disponibilidad• Es
– Una combinación de diseño, personas, procesos, y tecnología
• No es– Solo una solución tecnológica– Sinónimo de escalabilidad o managability– Una decisión de IT sin conocimiento del
negocio– Una decisión de negocio aislada del costo de
“downtime”
Cinco Que?
• Que es un Nueve?
Respuesta Ecuación
Por Año ( 8760 – HorasBajoPorAño) / 8760
Por mes ( (24 * NumDiasEseMes) – HorasBajoPorMes)/ (24 * NumDiasEseMes)
Por semana ( 168 – HorasBajoEsaSemana) / 168
12 34599.999 % uptime
A=(F-R)/FA=disponibilidadF=MTBF(Tiempo medio entre fallas)R=Tiempo medio para reparar
Bajando los NuevePorcentaje Sin Respuesta (por Año)
100% Nada
99.999% < 5.26 minutos
99.99% 5.26 – 52 minutos
99.9 % 52 m – 8 h, 45 min
99 % 8 h, 45 m – 87 h, 36 m
90% 788 h, 24 m – 875 h, 54 m
Que significa No Disponible?
• Total de No Disponibilidad– Mantenimiento planeado de Servidores– Caídas no planeadas (ataques, fallas de
hardware, etc.)– Tiempo para switchear a tecnología Disponible– Restauración de Bases de Datos– Que mas……
Que significa No Disponible? (cont.)
• No Disponibilidad perceptible– SitioWeb/aplicación/etc. caído, SQL Server
Funcionando– Problemas de Red– Implementando nueva versión de aplicación– Errores de usuario o aplicación– Recursos mal entrenados
– Etc.
Como obtener mayor Disponibilidad
– Hardware redundante y de Calidad• Correctamente Administrado (SW & HW)
– Procesos que funcionen, incluyendo control de cambios
– Planes apropiados de mitigación (recuperación de desastres, etc.) que estén probados
– Excelencia en Operación, planificación y diseño
– Staff entrenado y calificado – valido en cualquier disciplina
Como obtener mayor Disponibilidad (cont)
• … pero cuales son sus barreras a la Alta Disponibilidad?– Personas?– Procesos?– Dinero?– Tiempo?– Tecnología?– …
El Costo de HA
99 99.1 99.2 99.3 99.4 99.5 99.6 99.7 99.8 99.9 100
Availability
Cos
t
Calculando el Tiempo y Costo de HA
2: Costos de Administración /Procedimientos
1: Hardware y Software
7: Costos de Usaurios finales
3: Soporte
4: Desarrollo
5: Costos de Telecomunicaciones
6: Caídas
Factores de TCO
Agenda• Que entendemos por Alta
Disponibilidad (HA)?
• Tecnologías de HA
• Administrando para HA
• Diseñando una Solución para HA
Dos Niveles …
• Tecnología SQL– Failover Clustering – Log Shipping– Replicación
• Tecnología Windows– Windows Clustering– NLB
COMBINACIONESCOMBINACIONES
Como funciona el Failover Clustering
PC Clientes
Nodo A Nodo B
Array de discos compartido
HeartbeatSQL ServerSQL Server SQL ServerSQL Server
Log Shipping
SecondaryPrimary
Log Shipping Monitor
Transaction Logs
Usos de Log Shipping
• Usos para HA:– Facilita la actualización 7.0 2000– Método de HA secundario para un failover
cluster (resuelve el problema de la distancia)– Llevar a cabo mantenimiento en el Servidor
principal– Chequeo de estado de la BD
• También para reportes y consultas (no HA)
Evaluando la Replicación como una solución para HA
• Si están descartados failover clustering y log shipping
• Detección de fallas y failover no son automáticos• Cuando una funcionalidad Warm-standby sea
aceptable• Standby server no es idéntico al primario:
– Algunos esquemas de usuario y algunos datos de sistemas no son replicados
– Los datos pueden no estar actuales– La replicación Merge no es consistente transaccional
mente
• Hay algunos beneficios:– Particionar los datos en el standby server (se pueden
replicar partes de tablas)– Acceso a datos para reportes
Comparacion de Soluciones Standby Hot y Warm
• Definiciones– Hot standby– Warm standby
• Soporte de failover Hot standby– Se requiere Failover clustering– Detección de Falla y Failover son automáticos
• Soluciones Warm standby– Log shipping – Transfiere backups desde un
servidor primario a uno secundario– Replicación – Provee acceso simultaneo a
datos en otro nodo y particionamiento de objetos y datos
Comparación Tecnológica de HA en SQL
Feature Failover Clustering Log Shipping Transactional Replication
Failure detection Automatic Not Automatic Not Automatic
Automatic switch to secondary
Yes Manual Manual
Protects against failed server process
Yes Yes, but … Yes, but …
Protects against failed disk
No, Shared-disk clustering Yes, but … Yes, but …
Meta data support All system and user schema and data for all databases
Some system, all user schema and data for select databases
Some user schema and data
Transactionally consistent
Yes Yes Yes
Transactionally current
Yes No, since last transaction log backup
No, since last replicated transaction
Feature Failover Clustering Log Shipping Transactional Replication
Performance impact
None Minimal (file copying on primary)
Log reader continually running
Time to switch Seconds to minutes, depends on db recovery time
Seconds, more to recover more thoroughly
Seconds, more to recover more thoroughly
Locations Close (unless using distance clusters on HCL)
Not location bound Not location bound
Additional complexity
Some Some More
Maximum number of servers
4 32 with NLB, otherwise no limit
No limit
Standby available for reporting, etc.
N/A – not a warm standby solution Yes. Possible Read-only access when logs are not being loaded
Yes
Partitioning of data to standby
No No Yes
Comparación Tecnológica de HA en SQL
Backup/Restore• Se necesita una buena estrategia siempre
pero …– Para HA, debe ser el ultimo resorte
• Pros– Usted conoce de esto y lo Ama !!!!!
• Cons– Fallos de medios, como cinta– Tiempo para llevarlo acabo– No crea redundancia– En realidad, se necesita mas que datos de
usuario – BD de sistema, SO, etc.
Balance de carga de red (NLB)
• Generalmente utilizado para escalabilidad no de SQL Server
• Puede ser usado con BD para obtener HA – usarlo solo en las situaciones correctas– Servidores de datos redundantes para solo
lectura (i.e. información de catalogo)– Front end switch para el cambio de rol en log
shipping– Servidor en espera para los Servicios de
Análisis (BI-DW)
Agenda
• Que entendemos por Alta Disponibilidad (HA)?
• Tecnologías de HA
• Administrando para HA
• Diseñando una Solución para HA
Prevención de Desastres
• Administración de Riesgos
• Estrategias para prevención de desastres
Manejo de Riesgos
Lista de
Riesgos
Descartados Planear
3
Analizar2
Controlar5
Identificar1
Documento
con Riesgos
Seguir4
Topn
Estrategias para prevención de desastres
• Determinar potenciales causas de caida
• Crear Procesos operacionales efectivos
• Prevenir caídas en forma automática– Hardware redundante– Volcado automático a un Servidor en espera– ....DDR y replicación o log shipping con NLB
• Principios de Data Centers
• Control de Cambios
• Staff
• Plan de recuperación ante desastres
• Libro de Acción
Establecer excelencia operacional
Monitoreo para HA
• Dos Teorías:– Todos los contadores el 100% del tiempo– Solo lo que se necesite
• No olvidar el Profiler
• Coordinar con Event Logs, SQL Logs, IIS Logs, etc. – Horarios de diferencia entre servidores– HA es una solución total … no solo SQL
Backup y Restore
• Desarrollar una estrategia de backup• Full database backups• File/filegroup backups• Transaction log backups• Imagen de disco de SO
• Probar backups en otro servidor
• Rotar cintas off-site– Usar servicios profesionales– Asegurarnos que utilizan buenos principios de
Data Centers
Backup y Restore (cont)
• Testear los planes de recupero– Localizar cintas– Testear usando la interfase grafica– Testear usando solo script– Testear con diferentes personas en todos los
equipos
• Cuanto tiempo lleva?• Conocerá al CEO/CFO/CIO cuando un
servidor importante este caído…• “esta listo ya, esta listo ya?”
• Una de las claves para HA– Sin esto, …..rece para que todo funcione
• Diferentes planes: – Sitio caído– Servidor caído– Perdida de Datos
• Documentar el plan (mantenerlo actualizado) – testear, testear TESTEAR! Almacenar resultados/aprendizajes
• Almacenamiento de backups Off-site, incluyendo el manual de operaciones (libro de acción)
Diseñando un Plan de recuperación en desastres
• Desastre ocasionado por la naturaleza ou Hombre
• Buen caso para geoclusters/log shipping
• Puede darse que cada minuto sea crucial – tener un hot/warm/cold standby es crucial
• Si no se cuenta con un hot/warm/cold standby, estar preparado para reconstruir ….rece por que cuente con buenos y recientes backups
Sitio Caído
• Esto tiende a ser un falla de sw/sw failure o un error human
• Otro buen argumento para geoclusters/log shipping y redundancia
• Si necesita reconstruir, tenga a mano:– Configuración de Sistema (Libro de Acción)– Cintas/CDs disponibles– Software, Claves de CD– Números de soporte
Servidor Caído
Perdida de Datos
• Error Human? Falla de Hardware? – Puede hacer rollback/solucionar el problema?
(i.e. deshacer vía aplicación, instrucción SQL, o herramienta como Lumigent, etc.)
• En estos casos es cuando un plan de backup/restore real, probado, testeado lo salvara
Agenda
• Que entendemos por Alta Disponibilidad (HA)?
• Tecnologías de HA
• Administrando para HA
• Diseñando una Solución para HA
Preguntas Básicas
• Es Misión Critica? Que ocurre cuando esta caído? (Perdida de dinero? Perdida de vidas?)
• EN cuanto impacta el negocio no disponer de HA? Calcular cuanto costaría estar fuera de servicio
• Que industria? Es OLTP, DSS?
• Cual es el presupuesto?
• Que disponibilidad y performance espera el usuario final?
• No hay ninguna guía al 100% que sirva para cualquier situación
• Asegurarse que la tecnología sea soportable en nuestro entorno
• Solo porque algo “esta de moda”, puede que no sea correcto– i.e. Así como failover clustering es la mejor
opción en la mayoría de las situaciones, no es siempre la elección correcta
Seleccionando la tecnología correcta
Invertir en su App?
• Contrario a lo que se piensa, no importa cuan confiable sea el HW, mala app = baja disponibilidad– Invertir mucho en el desarrollo de su aplicación
• Proyecto Nuevo?– Mejor escenario
• Haga lo correcto desde el comienzo
• Entorno/app existente? – Evaluar la infraestructura
• Necesita nueva estrategia de mantenimiento?• Nuevo HW? Migración de Datos?
– Rediseño de App?
• Crecimiento …– Capacidad, escalabilidad
• Ajustar índices, esquema, mantenimiento; posibles cambios de diseño
• Que hacer si el HW no escala mas? Minimizar el downtime por el upgrade
Invertir en su App? (cont)
Diseñar su Aplicación de BD para HA
• Involucrar a sus programadores desde el inicio
• Utilizar versioning & source control para todo el código – incluyendo SQL
• Manejar la implementación con cuidado – construir programas con instaladores y desinstaladores “Limpios”
• Utilizar tecnologías apropiadas en el código
• Establecer entornos de desarrollo, testing, mas uno que sea exacto al entorno de producción (con los datos actuales de producción)
• Tener en cuenta las caídas, y como manejarlas – no dejarlo para IT
• Datos de solo lectura deben manejarse en cache para mejorar la performance de la aplicación (XML)
Diseñar su Aplicación de BD para HA (cont)
• Resolver cualquier problema de la aplicación que afecte directamente SQL Server– Locking/blocking– Optimizar Consultas/Indización– No procesar sobre la BD (cursores, grandes sp)– Usar sp para IUD– Asegurarse que las estadísticas esten
actualizadas
Diseñar su Aplicación de BD para HA (cont)
• En lo posible codificar aplicaciones sin estado, si se mantiene estado, seleccionar una forma adecuada de hacerlo
• La experiencia del usuario debe ser positiva• Seguridad• Hacer competir y convivir su app con otras con
las que tenga que vivir• No codificar para un Service Pack/Versión
específicos (OS/SQL)• Dejar que los requerimientos definan la
tecnología
Diseñar su Aplicación de BD para HA (cont)
Diseñar su Aplicación de BD para HA (cont)
• Utilizar nombre completos para tablas y procedimientos almacenados
• Colocar todos los objetos en BD de usuario, no de sistema
• No “harcodear” en la aplicacion nombres de servidores, nombres de instancias, y direcciones IP
• Reutilizar conexiones de BD (Connection pooling)
Diseñar su Aplicación de BD para HA (cont)
• De ser necesario crear errores personalizados de SQL Server, pero asegurarse que no entren en conflicto con errores personalizados de la app
• Analizar Database collations• Nombres de Usuario y logins únicos• Asegurarse que trabajos de una app no
entren en conflicto con otras app• Transacciones pequeñas (rollback de
failover clustering y Log Shipping)
En Resumen
• Una vez que el servidor este corriendo, déjelo en paz….
• Cuatro pilares de HA– Diseño
– Personas
– Procesos
– Tecnología (comprar un nuevo cluster e instalar SS2KEE no es suficiente)
9
Hardware bien administradoHardware bien administrado
• Puede tolerar algunas fallas de HW
9Buena administración y planificaciónBuena administración y planificación
• Puede tolerar la mayoría de las fallas de HW• Puede tolerar tareas normales de ope (ej., UPG de SW)• Puede tolerar algunas fallas de SW
9
Excelencia operacional, de diseño y de planificaciónExcelencia operacional, de diseño y de planificación
• Puede soportar la mayoría de las caídas planeadas o no• Puede tolerar algunas fallas de operaciones
99Casi sin administrarCasi sin administrar
En
Res
um
en (
con
t)
Para mas Información … • SQL Server Technical Information
(http://www.microsoft.com/sql/techinfo/)– Mucha info & links, incluyendo:
• SQL Server 2000 Operations Guide• SQL Server 2000 Resource Kit (info only; you need the printed
book the CD-ROM)• SQL Server 2000 Failover Clustering Whitepaper
• Capacity Planning – Microsoft SQL Server 2000 Administrator’s Companion
• MS Support Homepage (Q Articles)
© 2002 Microsoft Corporation. All rights reserved.© 2002 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.