28 agosto 2008

Diseño de centros de respaldo

Las Tecnologías de la Información ya son verdaderos puntales de la actividad de muchas organizaciones, por lo que una simple interrupción de sus servicios puede resultar fatal para su cuenta de resultados. Para evitarlo no hay otra solución que dotar de redundancia a los sistemas de la organización. Esta redundancia tiene distintos enfoques y niveles. El primer enfoque es el más utilizado e implica la redundancia de los sistemas individuales lo que incrementa la disponibilidad de los servicios y, en algunos casos, su potencia si se consigue la redundancia activo-activo mediante clusters o granjas de servidores. El segundo enfoque es el que se tratará a lo largo de este artículo e implica la redundancia de todo el CPD de la organización en otro emplazamiento, por lo que es menos común dado el elevado coste que supone, pero es el que más seguridad ofrece por lo que suele ser la opción elegida por instituciones gubernamentales y grandes corporaciones (que además suelen asumir simultáneamente el primer enfoque en el CPD principal). La distancia entre el CPD y su réplica es variable y se pueden encontrar CPDs compartiendo pared con su réplica, mientras que otros se situan en edificios distintos o a muchos kilómetros de distancia. Cuanto más lejos estén el CPD y su réplica mejor, así una catástrofe (fuegos, explosiones, accidentes, etc) o ataque localizado (por ejemplo bombas) sólo afectará a uno de los dos, mientras que el otro podrá seguir funcionando. Lógicamente a mayor distancia entre los CPDs mayor será el coste de mantenerlos ya que , entre otras cosas se disparará el coste de la actualización de la réplica. Igual que la redundancia de sistemas puede ser de dos tipos - activo-activo y activo-pasivo - la de CPDs puede ser de actualización síncrona o asíncrona. La actualización síncrona implica que la réplica recibe en tiempo real los cambios que experimentan los sistemas del CPD de manera que cuando se de una conmutación, el CPD caiga y la réplica se haga cargo del servicio, la réplica este plenamente actualizada. Por contra la actualización asíncrona no traspasa los datos a la réplica en tiempo real sino por lotes. Por ejemplo, una política de actualización asíncrona podría ser hacer un clonado de los sistemas del CPD cada noche e instalar dichas copias en la réplica. El problema de la actualización asíncrona es que en el momento de la conmutación la réplica no estará plenamente actualizada sino que sólo contará con los datos hasta el momento del último volcado. En el ejemplo que hemos puesto de política de actualización asíncrona el caso peor podría ser una caída irrecuperable del sistema principal a última hora de la tarde lo que supondría la entrada de la réplica con los datos de la noche anterior, es decir se perderían todos los datos generados durante la mañana y la tarde. Por eso la actualización síncrona es mucho más segura, pero claro, también mucho más cara ya que supone el despliegue de enlaces entre el CPD y su réplica con la suficiente capacidad para permitir el envío masivo de datos en tiempo real a los sistemas de la réplica. Si además el CPD y su réplica están separados por una gran distancia los costes de interconexión se disparan. En el caso de las actualizaciones asíncronas lo normal es que se tenga que transmitir una cantidad muy elevada de datos pero que se asuma un intervalo de tiempo más o menos largo para realizar la transmisión (por ejemplo, clonado a comienzo de la noche y transmisión de los datos a lo largo de la noche), por tanto se necesitan enlaces con un ancho de banda elevado pero no tanto como en el caso síncrono en el que el requisito de actualización en tiempo real exigen enlaces fiables de alta capacidad que no se conviertan en cuellos de botella. Una tecnología comúnmente usada para establecer estos enlaces se basa en fibra óptica y por ello recibe el nombre de Fiber Channel, también utilizadas para el despliegue de redes SAN, con las que se pueden obtener velocidades superiores a los 400 MBps (sí, bytes) en distancias por debajo de 2 Km. Para distancias más grandes la fibra puede ofrecer hasta 200 MBps por debajo de los 50 Km. Cuando la réplica se encuentra en el mismo edificio o en el mismo complejo de edificios que el CPD resulta muy fácil establecer un enlace de fibra entre ellos, pero cuando están más alejados entre sí no queda más remedio que acudir a las empresas de telecomunicaciones para alquilarles sus fibras oscuras. Una alternativa más barata, pero también mucho más limitada en cuanto a distancias y velocidades, es iSCSI, una versión TCP/IP del protocolo SCSI, que permite utilizar equipamiento de red ethernet, mucho más barato que el de fiber channel. La pega de iSCSI es que no permite las altas velocidades de fiber channel pero lo cierto es que la llegada de Gigabit Ethernet ha reducido las diferencias, sobre todo si en los troncales se recurre al agregado de enlaces (ethernet channel en la terminología Cisco y trunking según otros). Eso a nivel de datos de almacenamiento, en lo que se refiere al necesario tráfico de red para el acceso a los sistemas, lo más usual es colocar un conmutador multicapa en el centro de respaldo unido por enlaces redundados (cada uno de ellos debería seguir una ruta distinta o, en su caso, estar contratados a un operador distinto) al conmutador multicapa del centro principal, de manera que las VLANs del CPD se extiendan a la réplica. Una vez que se ha afrontado el problema de la sincronización de los datos hay que estudiar otro muy importante: cómo hacer la conmutación de los servicios desde el CPD a la réplica. La verdad es que depende enormemente del tipo de servicios y sistemas que queramos replicar, aunque si estamos en un caso de actualización síncrona dadas las altas velocidades y la fiabilidad de las redes actuales resulta similar a la conmutación de equipos redundados dentro del mismo CPD ya que gracias a estos factores se pueden extender VLANs entre distintos edificios y localizaciones de manera transparente a los servidores. De esta manera no resulta complicado establecer clusters de equipos, cuyos nodos estén distribuidos a partes iguales entre los dos emplazamientos. Lo mismo se puede decir de las granjas de servidores. Este esquema (activo-activo) permite que no se desaproveche la potencia de los nodos desplegados en el centro de respaldo ya que se les utiliza en las tareas diarias. En caso de caída de uno de los emplazamientos los nodos del otro continuarán con el trabajo que venían haciendo y asumirán el del centro caído. Otra ventaja de los diseños de respaldo activo-activo es que como las máquinas del centro de respaldo funcionan constantemente se puede detectar cuando se estropea una, mientras que en los diseños activo-pasivo como el centro de respaldo está "apagado" no es raro encontrarse con la desagradable sorpresa de que alguno de los sistemas falla a la hora de "arrancarlos". En el caso de diseños de actualización asíncrona la puesta en marcha puede ser más compleja y menos automática ya que los equipos del centro de respaldo son meras copias de los del centro activo por lo que se mantienen en estado pasivo y suelen requerir cierta puesta a punto antes de asumir el servicio. Eso de cara a los servicios internos, de cara a los externos a veces hay que avisar al resto del mundo de que las máquinas que ofrecen los servicios pasan a ser las del centro de respaldo, lo que impica cambiar los registros de los DNS externos. En ese sentido existen empresas que ofrecen servicios de monitorización de sistemas mediante los cuales comprueban periodicamente que dichos servicios siguen en pie y, en caso contrario, cambian los registros DNS para que apunten a las máquinas de la réplica. De todos modos, hay que tener en cuenta que en este caso las actualizaciones en el DNS pueden tardar horas en extenderse por lo que la perdida de servicio a los clientes externos puede prolongarse.