SQL Server: Proteja los datos a toda costa

  • Artículo

Mantener una alta disponibilidad de los almacenes de datos corporativos administrados con SQL Server es un elemento esencial en cualquier estrategia de administración de datos.

Paul S. Randal

El mundo empresarial se paralizaría si perdiera la capacidad de almacenar y recuperar datos en forma ininterrumpida. Aparte de los recursos humanos, los datos se están convirtiendo rápidamente en el bien más preciado de las empresas. Y SQL Server o SQL Server 2008 R2 a menudo constituyen el núcleo de cualquier estrategia de administración de datos. Visto de esta forma, los desarrolladores y administradores de las bases de datos son los responsables de mantener en marcha la empresa.

¿Pero cuántas directrices definitivas se cuelan desde las jefaturas de las unidades de negocios hasta las unidades responsables de los datos? ¿Se están comunicando en forma clara los requisitos operacionales? ¿Se están comunicando de manera tal que los profesionales técnicos puedan convertirlos en una estrategia productiva?

En ciertos segmentos del mercado existen exigencias reglamentarias estrictas acerca de los aspectos de la infraestructura, tales como las auditorías de seguridad o el cifrado y retención de los datos. Al no cumplir con estos requerimientos las empresas se exponen a multas o condenas, y a la pérdida de credibilidad pública y de ganancias a futuro. Esto es una de las peores cosas que pueden ocurrir en un mercado altamente competitivo.

Ajuste su estrategia de administración de datos

Algunos requisitos operacionales aparentemente son más fáciles de comunicar por los responsables de las empresas: los que se relacionan con la seguridad, la administración de las cargas de trabajo, las auditorías, y la obligación de informar. Afortunadamente, estos también son los mismos que se implementan con mayor facilidad dentro del marco de SQL Server 2008.

  • Los requisitos de seguridad de los datos se pueden cumplir mediante el uso de características tales como el Cifrado de datos transparente que cifra los datos almacenados y la Administración extensible de claves que permite almacenar las claves de cifrado fuera del servidor y alejado de los datos cifrados.
  • Las obligaciones de informar se pueden cumplir con SQL Server Reporting Services.
  • El regulador de recursos permite predecir el rendimiento de las cargas de trabajo.
  • Y se puede emplear SQL Server Audit para cumplir con los requerimientos más estrictos de auditoría.

Pero hay dos requerimientos operacionales importantes que se suelen comunicar muy mal: la inactividad del sistema y la pérdida aceptable de datos. Éstos se conocen como el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO), respectivamente. Desafortunadamente, muchos directores de las empresas no toman en cuenta los RTO y RPO. En caso de un desastre tienen que descubrir a la fuerza que el nivel de datos no está suficientemente protegido, lo que causa inactividades del sistema o pérdidas de datos.

Sin importar si usted tiene un cargo de director de una empresa o de administrador de bases de datos, tómese un minuto para pensar si está completamente seguro que el nivel de datos está protegido en la medida requerida por la empresa. Si llega a la conclusión que no lo está ¿cuál es su plan para solucionar el problema?

En este caso, ni el pánico ni la complacencia son las reacciones adecuadas. Si pretende poner en marcha una estrategia en el plazo de una semana, una operación de simulacro de incendio es una receta segura para provocar un desastre. Se requiere de mucho cuidado y dedicación para diseñar e implementar una estrategia global adecuada para una alta disponibilidad y recuperación ante desastres (HA/DR) para SQL Server. Hacer caso omiso del problema sólo puede llevar a una catástrofe y equivale a la negligencia más grave en la empresa.

Analice cada requerimiento

La clave para diseñar una estrategia satisfactoria está en elaborar primero los requerimientos operacionales. Luego hay que equilibrar éstos con las limitaciones de la empresa. Aquí es donde los directores de TI y comerciales tienen que enfrentarse para mirar las cosas cara a cara. Los requerimientos estratégicos tienen que encapsular los siguientes factores para cada porción de datos pertinente para la operación de la empresa:

  1. ¿Qué tan importante es una determinada porción de datos comparada con todo el almacén de datos restante? Frecuentemente los directores comerciales dicen que todo tiene prioridad absoluta y debe ser protegido indistintamente. Esto funciona con una cantidad pequeña de datos, pero se vuelve menos práctico a medida que varios terabytes de datos se distribuyen en más y más instancias de SQL Server.
  2. ¿Cuántos datos puede permitirse perder la empresa? Es comprensible que los dueños de las empresas quieran ver cero pérdidas de datos, pero esto no siempre es práctico.
  3. ¿Durante cuánto tiempo deben estar disponibles los datos? Los dueños de las empresas también querrían que no existieran tiempos de inactividad, pero esto tampoco se puede lograr en la realidad. Pero es posible aproximarse a esta meta.
  4. ¿Alguno de estos dos factores cambia en diferentes momentos del día o durante los fines de semana? Esto puede tener un impacto profundo en la capacidad de cumplir con los requerimientos. Las metas de cero tiempos de inactividad y cero pérdidas de datos son mucho más alcanzables durante períodos limitados de tiempo, como por ejemplo entre las 9 de la mañana y las 5 de la tarde todos los días de la semana, comparado con un acceso por tiempo completo, las 24 horas todos los días del año.
  5. ¿Se puede aceptar una degradación del rendimiento en la carga de trabajo para conservar la disponibilidad y la durabilidad de los datos? Las únicas tecnologías que ofrecen cero pérdidas de datos requieren de reflejos sincrónicos de los registros de las transacciones o de las escrituras de los subsistemas de entrada y salida. Ambos pueden generar retrasos en el procesamiento, por lo que se trata de una solución intermedia.

Una buena forma de enfrentar esto es considerar el impacto que tiene en el negocio cada porción de datos que se vuelve inaccesible o se pierde. Es probable que se encuentre con sorpresas cuando analice y cuantifique las ramificaciones posibles con respecto a sus clientes, la imagen de su empresa y sus controles reglamentarios.

Analice cada limitación

Uno de los errores más comunes al diseñar e implementar una estrategia de HA/DR es seguir adelante con el diseño técnico sin considerar primero los factores limitantes. Esto significa que habrá que volver a replantearse la estrategia desde el principio —lo que implica una pérdida de tiempo y dinero— o que se implementará una estrategia deficiente que no cumple con los requerimientos de la empresa.

Existen muchas limitantes, algunas de las cuales son técnicas y otras no. El factor más importante generalmente es el presupuesto. Más hardware implica más consumo energético, lo que implica más pérdidas de calor, lo que implica más aire acondicionado, lo que implica aún más consumo energético, lo que implica que se necesita más espacio y más dinero dedicado a esa infraestructura. También hay que considerar el costo del hardware, las licencias adicionales para SQL Server y Windows, el ancho de banda de la red y quizás incluso más personal para administrar los sistemas adicionales y el centro de datos.

Transigencias y el rompecabezas empresarial

Una vez familiarizado con todas las limitaciones técnicas, el arte consiste en encontrar la solución intermedia más eficaz. Necesita una lista por orden de prioridad de los datos de mayor importancia para la empresa. Dadas las restricciones bajo las cuales tiene que operar, evaluará las tecnologías que le permitirán cumplir con los requerimientos operacionales más importantes.

Es fundamental que no se limite simplemente adaptar las tecnologías existentes para cumplir con los requerimientos operacionales nuevos. Y tampoco elija una tecnología sin evaluarla cuidadosamente con respecto a sus prioridades operacionales. Siempre es preferible comenzar pronto con el trabajo y llevar a cabo el proceso de manera adecuada. Así conseguirá una estrategia mejor que le permitirá ahorrar tiempo y dinero a la larga.

Si cree que las tecnologías que puede costear no le permiten cumplir con los requerimientos operacionales, tendrá que cambiar esos requerimientos en conjunto con los directores de la unidad comercial, de modo que reflejen la realidad presupuestaria. En su calidad de técnico, por ejemplo, no tiene sentido que acepte un requerimiento de cero pérdidas de datos si no dispone de los fondos necesarios para implementar una tecnología sincrónica. A la hora de una desgracia, cuando las expectativas de los directores de las empresas no se cumplan, la culpa de esta situación recaerá sobre el personal de TI.

Uno de los aspectos más difíciles al diseñar la estrategia de HA/DR suele ser el lograr integrar este componente en forma armoniosa dentro de la estrategia global de la TI de la empresa. Si usted está a cargo de la administración de las bases de datos en una empresa, probablemente son otros los equipos responsables de los servidores Windows, de la red, el almacenamiento, la infraestructura del edificio, etc. Si la empresa necesita que después de un desastre una determinada base de datos esté disponible dentro de cuatro horas, probablemente tendrá que involucrar a todos estos equipos para lograr esa meta. Ahí entran en juego factores de políticas y relaciones entre los equipos. Es indispensable que los demás equipos también acepten el compromiso de cumplir con los mismos acuerdos que el equipo del nivel de datos, y las mismas expectativas y promesas con la empresa en general.

Probar y probar

Si tiene la impresión que el nivel de datos no está suficientemente protegido, es probable que la estrategia de HA/DR no se haya probado suficientemente en su empresa. Al diseñar e implementar una estrategia de HA/DR es imprescindible poner a prueba el sistema para que éste pueda responder en caso de crisis.

Pero es más fácil decir esto que llevarlo a la práctica. Puede ser muy difícil convencer a los directores de las empresas para que autoricen unas pruebas que eventualmente podrían conducir a tiempos de inactividad. Un posible argumento frente a esta actitud podría ser que es mejor hacer una prueba cuando todos están en el lugar de trabajo, esperando que ocurra una “desgracia”, listos para entrar en acción y solucionar rápidamente cualquier tipo de problemas. De lo contrario podría ser que descubra un error en el diseño cuando ocurra un desastre a las dos de la madrugada, en la temporada de vacaciones, cuando sólo se encuentra el personal de relevo.

Incluso si descubre que su nivel de datos no está bastante protegido con respecto a los tiempos de inactividad y las pérdidas de datos, SQL Server 2008 y SQL Server 2008 R2 ofrecen muchas alternativas para implementar una estrategia de HA/DR. Comprenda las diferentes tecnologías y sus disyuntivas, y estudie las arquitecturas que otras empresas han implementado con éxito. Revise las siguientes notas de productos y publicaciones de blog donde encontrará más información:

Trabaje para poner en marcha una estrategia válida. Es la única forma que le permite proteger su negocio y evitar tiempos de inactividad inesperados.

Paul Randal

Paul S. Randales director administrativo de SQLskills.com, director regional de Microsoft y MVP de SQL Server. Trabajó en el equipo de Motor de almacenamiento de SQL Server en Microsoft desde 1999 a 2007. Paul escribió DBCC CHECKDB/reparación para SQL Server 2005 y era responsable del Motor principal de almacenamiento durante el desarrollo de SQL Server 2008. Randal es experto en recuperación ante desastres, alta disponibilidad y mantenimiento de bases de datos, y es moderador habitual en congresos en todo el mundo. Mantiene un blog en SQLskills.com/blogs/paul y puede encontrarlo en Twitter en twitter.com/PaulRandal.

Contenido relacionado