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.