DRP

Creo que toda empresa debe tener un DRP = Disaster Recovery Plan.

En la empresa en la que trabajo estamos ahora intentando minimizar los RPO y los RTO (http://es.wikipedia.org/wiki/Plan_de_recuperaci%C3%B3n_ante_desastres).

Como software usamos Backup Exec de Veritas. Algunas plantas aún estan con ArcServe pero en desuso. El Hardware son robots de copias LTO-3, LTO-4… La tecnología será la del momento de compra y el número total de cintas que soporta el robot dependerá del dimensionamiento futuro. Es importante tener en cuenta cuando compras los equipos de backup, no el almacenamiento actual sino el que tendrás dentro de 3-4 años (tiempo en que amortizas el material). Debes calcular la ventana de backup por los datos futuros, así no tendrás ni sorpresas ni problemas.

Muchas tecnologías actuales de infraestructuras de TI como VMWare, Xenapp… permiten obtener KPIs cercanos al 100% en disponibilidad de aplicaciones/servicios, tecnologias a tener en cuenta si quieres tener un buen DRP.

Base de datos como Oracle, DB2… disponen de su propio sistema de alta disponibilidad que dependerá de la versión y de tu infraestructura. En DB2 (Iseries AS400) usamos Quick-EDD/HA sistema de duplicación de objetos entre una VM y otra (el Iseries usa LPARs, y le llamo VMs porque son maquinas virtuales por similitud al concepto de VMWare). Con Oracle 11G tenemos un Oracle DataGuard para la alta disponibilidad.

La conexión a Internet también está securizada vía BGP con el ISP (Wimax como principal y backup ADSL). El Proxy Websense lo securiza el antiguo Bluecoat que tenia y aun está vivo, y por si las moscas un Squid de Linux (este tiene un Radius para autenticar, pues los websense vía LDAP lee el Active Directory y Bluecoat vía agente en los DCs también permite la autenticación.

A nivel de aplicaciones Lotus Notes, esta plataforma también permite el cluster. La replicación de documentos en Lotus es lo más simple y potente a la vez.

¿Que me queda? El firewall tengo un cluster Nokia Checkpoint Fw1 – IP350. A nivel MPLS también está redundado vía Operador. A nivel de CoreLan, pues a parte de un buen mantenimiento tener bocas de fibra y cobre disponibles dado el caso que alguna parte de tu Core caiga. A nivel de Wifi, tenemos 2 Cisco Wireless LAN Controller 5508. Al tener algunos APs de Cisco antiguos no hemos podido migrar los WLCs a la versión cluster, pero tenemos alta disponibilidad igualmente en versiones 6x, pero a nivel de administración es un poquitín más laborioso, pero bueno, tampoco añades APs cada día.

Los servicios que usan servidores radius permiten configurar 2 o más servidores radius, por lo que también tienes securizado las autenticaciones de VPNs de usuarios itinerantes (Cisco PIX, Cisco ASAs…), Los proxys, los WLCs…

A nivel de Active Directory, doy por entendido que todo el mundo tendrá un mínimo de 2 DCs por dominio. Yo para cada dominio tengo uno o varios en virtual y siempre uno físico (para sedes con más de 200 usuarios)

A nivel de seguridad (WSUS, Antivirus), cada fabrica tiene su servidor local de descarga de actualizaciones. En caso de caída de servidor local, servidores de Datacenters mas cercanos, vía Script o GPOs según el caso, se desvía la actualización (alerta con los anchos de banda y latencias entre dichas sedes, a nivel de antivirus no tendréis problemas pero os recomiendo que reviséis en el WSUS central como estaba la sede caída pues si había mucho ordenador pendiente de descarga de parches, puede que os sature la red WAN).

Caída de servidor de impresión de una sede: imprimir en la central en PDF y enviártelo por mail e imprimir en la impresora que tengas configurada localmente.

Mensajería: ahora estamos con Google Apps. Antes con Domino Server teníamos los clusters comentados en el apartado aplicaciones Notes, por lo que había también una redundancia.

La infraestructura VMWare debe securizarse. A modo de ejemplo os doy este linkhttps://jfrigolait.wordpress.com/2013/05/13/6/ donde vereis un esquema tipico de 2 switches, 2 cabinas y 3 hosts. Aquí la tecnologia usada es la barata Iscsi, pero podria ser Fiber channel tranquilamente, pero aun siendo economica da unos resultados excelentes.

Tambien podriamos hablar del emplazamiento del datacenter. Recomendable para grandes organizaciones 2 datacenters y ubicados en sedes distintas; como es el caso de nuestro datacenter central del Grupo en Francia.

En España solo dispongo de un datacenter, no está clonado, pero en este caso, el tema de un DRP se hace aún más riguroso, con revisiones más constantes del SAI y grupo electrogeno. Revisión de las cargas de las distintas lineas de corriente. Doble fuente de alimentación el los equipos, y cada de una de ellas a una linea (diferencial) distinta, servicios importantes de red como DC, DNS… ubicados en distintos racks.

Sistema antiincendios en el CPD, con sondas de temperatura (CPD y sala SAI)…

No falta decir del uso de RAIDs en los discos, dobles tarjetas de red para teamings, tarjetas IDRAC Enterprise para el control remoto de los Server desde la BIOS misma (muy importante si tenéis sedes distantes sin soporte local informático o con tiempos de respuesta altos)

Esta información la encontrareis en el grupo TechNet Spain de LinkedIn

Jose Antonio Quilez Lahoz • El Plan de contingencia es imprescindible en cualquier empresa que quiera tener un mínimo de seguridad, y Joan lo ha expresado perfectamente. Pero nos encontramos con que muchas empresas implementan todo ese tipo de medidas para securizar su inversión, pero les falta documentar correctamente los procedimientos a aplicar cuando ocurre un incidente, sea de pequeña entidad o un completo desastre. No vale con confiar en que si tenemos clusters se producirá correctamente el failover, sino que alguien tiene que saber que ha de comprobar que efectivamente se ha realizado, así como el rollback posterior. Lo mismo si replicamos VMs con Hyper-V 3 al CPD de respaldo, tiene que haber alguien que levante manualmente las máquinas en éste. Y así con todo.
Y para que eso funcione bien, necesitamos dos cosas: por un lado, designar una estructura de personal al que se le asignen responsabilidades y tareas en este sentido, y por otro lado, hay que escribirlo. Es imprescindible escribir un documento en el que se detallen todas las operaciones a realizar ante cualquier tipo de incidencia, y ese documento hay que difundirlo de tal forma que todos los implicados lo conozcan y sepan exactamente qué tienen que hacer.

Alfredo Abad Domingo • No disponer de un buen Disaster Recovery Plan, o no haberlo probado una vez diseñado, solo se llega a hacer una única vez, por alguna de estas dos razones:

a) Después de sufrir el desastre, siendo uno el responsable de ello, significará que no le darán una segunda oportunidad: búscate otra compañía que administrar y, si la encuentras, no cometas el mismo error.

b) No te han despedido, pero la solución al problema fue tan violenta que ya nunca se te ocurrirá dejar de validar una copia de seguridad, no tener etiquetadas correctamente las cintas de backup o extraviar el calendario de operaciones.

¿No sé si compartís esta idea conmigo?

Joan Frigola • José Antonio ha hecho la introducción del verdadero tema a tratar.

Yo hice la introducción: lo bonito, lo que nos gusta a todos, y la mayoría de veces lo fácil.

En los años que llevo en esta profesión, me he encontrado con bastantes desastres, en la mayoría de ellos no existía ningún DRP; pero si es cierto que con la experiencia empiezas a darte cuenta que debes documentar.

Nuestro amigo Alfredo con sus preguntas nos hace reflexionar; pues si es verdad que disponer de un DRP y no haberlo probado nunca, mucho sentido no tiene, pero también es cierto que si lo pruebas y no funciona, los efectos laterales pueden a llegar a ser «no muy deseables»

No creo que la organización te eche por haber provocado «un paro» en la actividad del negocio. Si lo hace, sinceramente, a lo mejor te está haciendo un favor, pues de los errores se aprende y habrá servido ese error para ver los fallos del sistema.

El año pasado, ya con un DRP bastante actualizado…, tuvimos un gran desastre en el Host Iseries AS400 que contiene uno de nuestros ERPs. Fue una perdida total de los datos (no entraremos en detalles escabrosos). Bien, este sistema está redundado en otro Datacenter… y bien: basculamos. A priori todo tenía que ir bien según el DRP, pero resulta que días atrás IBM estuvo migrando la versión del sistema operativo (a la v7.1) y la maquina que teníamos en producción estaba en v6x. ¿Que creéis que pasó?

¿Estaba el DRP actualizado? ¿Cuantas organizaciones actualizan su DRP a cada cambio de un sistema de los miles que puedes llegar a tener?

… continuará (a ver si la gente se anima, hace comentarios, y finalmente expongo que pasó)

 

Manuel Suarez • Cuan importante es tenerlo, pero que poco se valora por parte de muchas empresas. No se valora ni se pretende valorarlo, y menos poner medios para que pueda ser funcional. Todo esto que comentáis esta muy bien y debería cumplirse, y uno de nuestros principales esfuerzos es conseguir que las empresas sean conscientes de su necesidad e importancia, pues estas medidas suponen una inversión adicional. Por que dos servidores si con uno funciona? porque dos cabinas si con una tenemos? dos de esto otras cosa allí? Claro, luego vienen las sorpresas, y a ver como le dices que no invirtió lo suficiente. En estas situaciones se tiende a minimizar el impacto del futuro desastre, realizando un seguimiento mas que continuo de toda la infraestructura y esperando que Murphy se olvide de ti.

Josep Padullés • ¿Y las pruebas de recuperación de copias de seguridad?
¿Estamos seguros de que en caso de desastre o pérdida de información nuestras copias de seguridad funcionarán correctamente?
¿Están documentados correctamente los procesos?

Si no es posible disponer de un DRP completo como mínimo debería verificarse regularmente la fiabilidad de los procesos de recuperación y las copias de seguridad.

Efraín Oswaldo Luna Mejía • Interesante debate.

Alfredo, comparto tu idea, afortunadamente no hemos tenido ningún desastre hasta el momento. Coincido con el grupo de documentar o tener un plan de recuperación de desastres, por cierto como realizáis el seguimiento de las tareas relacionadas con las copias de seguridad?, cada cuanto tiempo?

Manuel Suarez • Las copias se revisan diariamente que finalizan de forma correcta. Y se hacen restauraciones de esas copias cada cierto tiempo para verificar que funcionan, igual es mucho 3 semanas aproximadamente.

Ivan Tribiño • Ademas de que estoy de acuerdo al 100 % que es necesario este documento, en infraestructruras con cpd de respaldo , con gran cantidad de servidores y Hardware que participan en esa infraestructura , se debe documentar al minimo detalle los cambios que sufren los servidores (cambios hardware , PArches , Service Pack… ) , y a la par cada cierto tiempo con paradas programadas , probar (te toca pringar a altas horas) que el disaster-recovery funciona perfectamente con en ese documento.
Muchas veces se hace el documento y no se corrige , hasta que pasa lo que dice Alfredo.