Cluster de Servidores Unix: la implementación

Una vez determinado que íbamos a implementar un cluster del tipo Activo – Pasivo con dos servidores Unix HP idénticos (ver blog) nos informamos sobre la solución de HP al respecto… se llama Service Guard, su filosofía me gustó mucho y funciona de la siguiente manera:

Service Guard de HP:

La idea de Service Guard es la de tener una red de servidores en la cual se definan los servicios necesarios (por ejemplo DNS, DHCP, Oracle, Apache, etc.) y en que servidores se desean que estén activos o pasivos.

Ejemplo:

Se desean tener los servicios de DNS, DHCP, Apache, Application Server, Oracle y MySQL bajo un esquema de Cluster Activo – Pasivo. Los servicios podrían estar distribuidos de la siguiente manera:

Servidor 1: DNS y DHCP

Servidor 2: Apache y Application Server

Servidor 3: Oracle

Servidor 4: MySQL

Pero también hay que definir que servidor tomaría las funciones de un servidor que se haya caído, así por ejemplo se podría tener:

Servidor 1:

Servicios Activos: DNS y DHCP

Servicios Pasivos: Oracle

Servidor 2:

Servicios Activos: Apache y Application Server

Servicios Pasivos: MySQL

Servidor 3:

Servicios Activos: Oracle

Servicios Pasivos: DNS y Apache

Servidor 4:

Servicios Activos:  MySQL

Servicios Pasivos: DHCP y Application Server

Así que si se cae el servidor número 2, los servicios de Apache levantarían en el servidor 3 y los de Application Server en el 4.

Con esta filosofía, siempre habría un servidor dispuesto a levantar servicios que se hayan caído del servidor que habitualmente los tiene. Esto Service Guard lo implementa mediante “paquetes” en los cuales se configura el servicio que tiene que vigilar, donde tiene que levantar en caso de caída, el script para arrancar un servicio dado, la IP relacionada, etc.

Claro está que, en caso de una caída, los servicios pueden tardar minutos en levantar en el servidor pasivo (dependerá de lo complicado de levantar esos servicios), por lo tanto este esquema es aceptable para el caso de negocios que pueden estar sin funcionar por un espacio de tiempo que se mida en minutos y no en segundos. Si la criticidad del negocio lo ameritara, claramente se tendrá que implementar un esquema Activo – Activo.

El caso nuestro fue bastante simple ya que los servicios a mantener eran tres únicamente: Oracle 10g, Oracle Application Server 10g y MySQL.

Se adquirieron dos servidores iguales:

·         HP rx3600 con un CPU Itanium cada uno (y posibilidad de un segundo)

·         8GBytes de memoria RAM (que tuvimos que ampliar al poco tiempo a 16)

·         4 discos SAS de 146GBytes cada uno

·         2 tarjetas de Fibra cada uno para acceder la SAN (un EVA4100)

·         4 tarjetas de red 10/100/1000 cada uno

·         HP UX 11i

La configuración de Service Guard fue:

Servidor 1:

Servicios Activos: Oracle AS 10g, MySQL

Servicios Pasivos: Oracle 10g

Servidor 2:

Servicios Activos: Oracle 10g

Servicios Pasivos: Oracle AS 10g, MySQL

La parte curiosa del asunto fue la relativa al acceso a la SAN, factor esencial ya que era necesario, obviamente, compartir los mismos datos entre los dos servidores: yo pensaba que la partición de la SAN a compartir simple­mente se vería por ambos servidores al mismo tiempo… algo parecido a cuando se comparte una carpeta en servidores Windows: en el momento que alguien crea un archivo en ella, inmediatamente el cambio es visto por los demás que la acceden. Eso es válido en una carpeta compartida en la red, pero no en una partición de la SAN que, para todos los efectos, es un disco local!

Total que aprendí que se definen las particiones en la SAN que serán usadas por cada servidor EN MOMENTO DISTINTOS es decir, cuando el servidor que la necesita está con el servicio en modalidad de “Activo”. El paquete de Service Guard es el que se encarga de activarla en el momento adecuado… de esta manera nunca hay dos servidores viendo la misma partición al mismo tiempo… hermoso!

Otra cosa interesante de los paquetes de Service Guard, es que tienen asociada una IP, con eso se logra que los clientes no tengan que ser reconfigurados: ellos siempre referencian a la misma IP (o idealmente a un nombre resuelto en un servidor DNS) y ésta es la que viaja de un servidor a otro de acuerdo a donde el servicio esté activo!

Claro que al tener una configuración como ésta, ya no se puede ser tan feliz a la hora de bajar un servicio ya que, a menos que se le indique lo contario a Service Guard, éste interpretará que se cayó el servicio y lo tratará de levantar en el otro servidor! Claro está que Service Guard viene con una batería de comandos para comunicarse y configurar los paquetes y evitar estos efectos dañinos.

Lo importante del caso es que se logró el objetivo propuesto: se pusieron en Alta Disponibilidad tres de los servicios más importantes de la organización, así las operaciones de manutención de los servidores fueron mucho más simples de llevar a cabo puesto que los servicios se detenían por tiempos muy cortos.

Cluster de Servidores Unix: el proyecto

Hace algunos años el tema de poner servidores en Cluster era todo un misterio que tenía un halo mítico que los hacía posibles solo en grandes organizaciones con grandes recursos técnicos de hardware, software y humanos. Hoy en día esta tecnología se ha vuelto al alcance de organizaciones medianas y hasta pequeñas; afortunadamente tuve una experiencia muy interesante implantando un Cluster en el Banco.

Antecedentes:

Aun cuando para todo personal técnico que necesita efectuar labores de manutención en la plataforma tecnológica el Cluster es algo muy práctico ya que permite retirar de operación un servidor SIN que la operación deje de funcionar, y, aun cuando para cualquier organización tener la garantía de que la operación siga funcionando a pesar de alguna falla de hardware o de software es lo ideal, lo que finalmente empujó la implementación del Cluster fue la reglamentación tecnológica de la Superintendencia de Bancos que inclusive le pide a los Bancos que posean un centro alterno para la continuidad de la operación en caso de desastres.

Aprovechando el proceso de reconversión monetaria (que necesitaba ambientes adicionales) y aprovechando la necesidad de una renovación y ampliación tecnológica, se planteó entonces la opción de implementar un Cluster de Servidores para lo relacionado con Oracle… es decir la parte crítica del negocio.

Las necesidades:

La necesidad básica era la de tener al motor de Bases de Datos y al servidor de aplicaciones en un ambiente de alta disponibilidad ya que el banco trabaja 7x24 y efectuar labores de mantenimiento en los servidores era siempre complicado.

Las opciones:

En lo relacionado al Hardware las opciones eran solo dos (por requerimientos del proveedor del software): Sun o HP. Hasta los momentos habíamos trabajado con un servidor Sun V440 que había hecho un buen trabajo, a pesar de haber pasado por una falla misteriosa relacionada con la tarjeta de red incrustada en la tarjeta madre que lo reinicializaba de cuando en cuando al azar; los que si habían fallado muchas veces, fueron los servidores de poca envergadura Sun de la familia V65x (con procesadores Intel) y en menor escala un V240… estas fallas nos habían dejado un mal sabor ya que los servidores HP DL380 no habían fallado nunca.

La gran duda, más allá del Hardware, era la de implantar un Cluster del tipo Activo – Activo o del tipo Activo – Pasivo… Oracle posee una solución espectacular, que se llama RAC (Real Application Clusters), que implementa Clusters del tipo Activo – Activo, es decir que todos los miembros del Cluster procesan transacciones en paralelo.

Aun cuando suene paradójico, quién inclinó la balanza a favor del esquema Activo – Pasivo fue el mismo Oracle o, mejor dicho, el esquema de licenciamiento de Oracle: al seleccionar un esquema Activo – Activo, Oracle requiere que se licencie su producto para cada servidor, si además se usa RAC, éste también deberá adquirirse en forma análoga. Yo entiendo que un esquema Activo – Activo se requiera para organizaciones que tienen millares de transacciones por minuto (una telefónica, un gran banco, etc.) pero esa no era nuestra realidad, por lo tanto el costo del licenciamiento de Oracle no era justificado de NINGUNA manera por nuestro negocio.

También se exploró la alternativa de tener no solamente una pareja de servidores gemelos para el Cluster, sino la utilización de servidores virtuales en ellos, de esta manera la portatibilidad y la flexibilidad de la solución eran únicos.  La idea era tener a dos servidores físicos con Unix conectados a una SAN, cada uno de ellos con dos servidores virtuales Unix (uno para Oracle y otro para el Application Server), de esta manera se tendría, además de la alta disponibilidad implementada entre los servidores reales, la alta disponibilidad inherente a la portatibilidad de los servidores virtuales de un servidor anfitrión a otro… una solución realmente espectacular!

Una vez más los sueños se disiparon cuando comenzaron los precios… sobre todo los del software. Parece increíble que a estas alturas, todavía las grandes casas de software no contemplen casos especiales para la virtualización: Oracle licencia sus productos de acuerdo al Hardware sobre el cual están instalados SIN importar si se trata de un servidor virtual que solo utiliza una fracción, HP hace lo mismo con sus productos (incluyendo HP UX) así que la instalación de la solución sobre servidores virtuales se hizo económicamente no viable.

Así que al final se optó por la implementación de un esquema de Cluster del tipo Activo – Pasivo sobre dos servidores HP conectados a una SAN.

El siguiente diagrama ilustra lo que se deseaba implementar (bien sea con servidores virtuales o reales). Los colores tenues indican los servicios en Pasivo:

La próxima semana contaré como fue la implementación propiamente.

Aplicación de DFS (Distributed File System)

Toda plataforma de tecnología pasa por transformaciones y evoluciones, es imposible que una plataforma tecnológica pueda servir a una organización moderna sin alteraciones a lo largo del tiempo: hay mejoras en servidores, en almacenamiento, en enlaces de comunicación, en software, etc. Típicamente el problema que se genera cuando se cambia información de un lugar a otro (por ejemplo cuando se pasan carpetas compartidas de un servidor a otro) es el impacto que tendrán los usuarios ya que se les altera el lugar al cual referenciaban… antes estaban en \\servidor-1\CarpetaPublica y ahora están en \\servidor-2\CarpetaPublica por lo tanto el departamento de HelpDesk tendrá que modificar los accesos directos y/o instruir a los usuarios sobre la novedad con la correspondiente molestia ya que, seguramente, habrá usuarios que no se enterarán.

Una excelente forma de evitar estas molestias es usando los DFS (Distributed File System) de Windows Server.

La filosofía de los DFS es muy simple: instruir al Directorio Activo de Windows para que distribuya los nombres de los recursos compartidos SIN que los usuarios siquiera se enteren a que servidor pertenecen. De esta manera los usuarios ya no se conectarán a \\servidor-1\CarpetaPublica sino a \\Dominio\Links\CarpetaPublica.

Los DFS son relativamente simples de implementar: se designa un servidor (generalmente un Controlador de Dominios) que será quién posea la tabla de equivalencia entre los nombres a difundir y su lugar físico correspondiente tal como se hizo referencia anteriormente.

A partir de ese momento los usuarios podrán referenciar a las carpetas compartidas mediante la nomenclatura que NO referencia al servidor. Ahora el departamento de TI tiene la facilidad de poder mover la información de un servidor a otro sin que los usuarios se enteren:

-          Se desactiva temporalmente la carpeta compartida a mover

-          Se mueven los archivos del servidor inicial al final

-          Se ajusta el DFS para que referencie a la nueva localidad

Listo!

Seguridad de TI: Experiencia con WSUS

Tal como comenté en una entrada de un blog anterior, la instalación del WSUS no fue demasiado complicada y se pudo efectuar sin demasiadas complicaciones. Tampoco fue muy complicado relacionar algunas políticas del Directorio Activo para instruir a los servidores con respecto al reboot automático cuando las mejoras de Windows así lo pidieran; los servidores Windows fueron así programados y se puede decir que no ocurrieron incidencias de importancia. Los inconvenientes surgieron con las PC… HelpDesk no tenía ninguna política de actualización con respecto a las PC, estos implica que las PC de los usuarios con más tiempo con ellas y muy conservadores a la hora de navegar en Internet y/o bajar programas, fácilmente tenía versiones de XP con SP1, por lo tanto de haberse incorporado al WSUS, éstas hubiesen recibido más de 1000 actualizaciones en las primeras de cambio! Para resolver este problema, que además se juntaba con el saneamiento de los Virus, se preparó para HelpDesk un área con todos los patch de seguridad de Microsoft organizados por Sistema Operativo e idioma (había algunas PC con Windows en inglés), ésta área era actualizada mensualmente con las nuevas actualizaciones. Adicionalmente se instruyó a HelpDesk para que, cuando les “cayese” en las manos una PC por alguna razón (típicamente porque tenía un virus), ésta se preparara con el último Service pack disponible para esa versión de Windows y luego se le aplicaran las actualizaciones de seguridad posteriores. Finalmente, luego que la PC en cuestión hubiese sido actualizada, nos informaban para que ésta se incluyera en el administrador del WSUS y así se mantendría actualizada en forma automática.

El esquema mencionado anteriormente funcionó bastante bien, el problema surgía cuando HelpDesk se olvidaba de notificarnos y así la PC dejaba de actualizarse automáticamente posteriormente.

En cuanto a las aplicaciones de las actualizaciones de seguridad de Windows, debo decir que nunca interfirieron con ningún programa… nunca nos pasó de que algún usuario se quejara que la aplicación X no funcionara adecuadamente a partir de una actualización. Personalmente si tuve algunos problemas con mi PC que tenía Windows 7: más de una vez me ocurrió que, a la mañana siguiente de que se le aplicar alguna actualización de Windows, la PC arrancaba de una forma extraña (con un escritorio en limpio, con Outlook desconfigurado, sin acceso a la carpeta de “Mis Documentos”, que teníamos localizada en un servidor de archivos, etc.) que me obligaba recurrir a la copia de seguridad que Windows efectuaba automáticamente para restaurar el Sistema Operativo a un estado previo a la actualización (que por cierto funciona perfectamente). Dado que no oí a ningún otro usuario quejarse de algo parecido, asumí que se trataba algo peculiar en mi PC y le resté importancia.

La parte más problemática de la distribución de las actualizaciones, es el reboot cuando éste hace falta. Con las PC no hubo mayores problemas porque, más temprano que tarde, son apagadas por los usuarios pero, para el caso de los servidores que no se apagan virtualmente nunca, se tuvieron que tomar ciertas políticas: en la mayoría de los casos los reboot se mandaban a efectuar automáticamente cuando sabíamos que no estaban realizando ninguna operación del negocio o, para el caso de los File Servers, en horarios en los cuales no debía haber nadie trabajando (nunca nadie se quejó de alguna pérdida de archivos debido a alguna reinicialización de algún servidor). Finalmente quedaban los casos de algunos servidores realmente críticos que, en teoría, no podían interrumpir sus labores nunca (por ejemplo los que atendían a los cajeros automáticos, el del Internet banking, el usado por el Call Center…), éstos los reiniciábamos manualmente en momentos que sabíamos que su ausencia no sería notada (generalmente cuando se tenían que bajar otros servicios de los cuales ellos dependían).

Por su lado la consola de WSUS nos informaba siempre el estado de cada servidor en cuanto a actualizaciones se refería con lo cual se podía hacer seguimiento de la distribución de alguna actualización en particular.