La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Soluciones de Alta Disponibilidad y Escalabilidad con SQL Server 2000 Diego Casali Systems Engineer Microsoft de Argentina Region Cordoba y NOA.

Presentaciones similares


Presentación del tema: "Soluciones de Alta Disponibilidad y Escalabilidad con SQL Server 2000 Diego Casali Systems Engineer Microsoft de Argentina Region Cordoba y NOA."— Transcripción de la presentación:

1 Soluciones de Alta Disponibilidad y Escalabilidad con SQL Server 2000 Diego Casali Systems Engineer Microsoft de Argentina Region Cordoba y NOA

2 Agenda Que entendemos por Alta Disponibilidad (HA)? Tecnologías de HA Administrando para HA Diseñando una Solución para HA

3 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

4 Cinco Que? Que es un Nueve? RespuestaEcuación Por Año( 8760 – HorasBajoPorAño) / 8760 Por mes( (24 * NumDiasEseMes) – HorasBajoPorMes) / (24 * NumDiasEseMes) Por semana( 168 – HorasBajoEsaSemana) / % uptime A=(F-R)/F A=disponibilidad F=MTBF(Tiempo medio entre fallas) R=Tiempo medio para reparar

5 Bajando los Nueve PorcentajeSin Respuesta (por Año) 100%Nada %< 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

6 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……

7 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.

8 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

9 Como obtener mayor Disponibilidad (cont) … pero cuales son sus barreras a la Alta Disponibilidad? –Personas? –Procesos? –Dinero? –Tiempo? –Tecnología? –…

10 El Costo de HA

11 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

12 Agenda Que entendemos por Alta Disponibilidad (HA)? Tecnologías de HA Administrando para HA Diseñando una Solución para HA

13 Dos Niveles … Tecnología SQL –Failover Clustering –Log Shipping –Replicación Tecnología Windows –Windows Clustering –NLB COMBINACIONES

14 Como funciona el Failover Clustering PC Clientes Nodo ANodo B Array de discos compartido Heartbeat SQL Server

15 Log Shipping

16 Usos de Log Shipping Usos para HA: –Facilita la actualización –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)

17 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

18 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

19 Comparación Tecnológica de HA en SQL FeatureFailover ClusteringLog ShippingTransactional Replication Failure detectionAutomaticNot Automatic Automatic switch to secondary YesManual Protects against failed server process YesYes, but … Protects against failed disk No, Shared-disk clusteringYes, but … Meta data supportAll 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 Transactionally current YesNo, since last transaction log backup No, since last replicated transaction

20 FeatureFailover ClusteringLog ShippingTransactional Replication Performance impact NoneMinimal (file copying on primary) Log reader continually running Time to switchSeconds to minutes, depends on db recovery time Seconds, more to recover more thoroughly LocationsClose (unless using distance clusters on HCL) Not location bound Additional complexity Some More Maximum number of servers 432 with NLB, otherwise no limit No limit Standby available for reporting, etc. N/A – not a warm standby solutionYes. Possible Read- only access when logs are not being loaded Yes Partitioning of data to standby No Yes Comparación Tecnológica de HA en SQL

21 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.

22 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)

23 Agenda Que entendemos por Alta Disponibilidad (HA)? Tecnologías de HA Administrando para HA Diseñando una Solución para HA

24 Prevención de Desastres Administración de Riesgos Estrategias para prevención de desastres

25 Manejo de Riesgos Lista de Riesgos Descartados Planear 3 Analizar 2 Controlar 5 Identificar 1 Documento con Riesgos Seguir 4 Top n

26 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

27 Principios de Data Centers Control de Cambios Staff Plan de recuperación ante desastres Libro de Acción Establecer excelencia operacional

28 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

29 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

30 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?

31 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

32 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

33 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

34 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

35 Agenda Que entendemos por Alta Disponibilidad (HA)? Tecnologías de HA Administrando para HA Diseñando una Solución para HA

36 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?

37 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

38 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

39 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)

40 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

41 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)

42 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)

43 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)

44 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)

45 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)

46 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)

47 9 Hardware bien administrado Hardware bien administrado Puede tolerar algunas fallas de HW 9 Buena 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ón Puede soportar la mayoría de las caídas planeadas o no Puede tolerar algunas fallas de operaciones 9 9 Casi sin administrar En Resumen (cont)

48 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 Administrators Companion MS Support Homepage (Q Articles)

49 © 2002 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.


Descargar ppt "Soluciones de Alta Disponibilidad y Escalabilidad con SQL Server 2000 Diego Casali Systems Engineer Microsoft de Argentina Region Cordoba y NOA."

Presentaciones similares


Anuncios Google