Curioso dato este y por eso me he decidido a comentarlo. Resulta que según contaba ayer “The New York Times” en su sección de tecnología (ver aquí) los Data Centers (Centros de Proceso de Datos, C.P.D.) no tienen el apetito eléctrico esperado. Desde luego es una mala noticia para ENDESA, Gas Natural Fenosa y similares, pero para mí es una estupenda e interesante noticia.
A nadie se le escapa que seguramente esto se debe a la dichosa crisis, sí, seguro, pero mucha de esta ausencia de apetito eléctrico está ocasionada, como bien explica la noticia, por el incremento en el último lustro del uso de la virtualización y por una mejora más que notable en la reducción de consumo gracias a las nuevas tecnologías hardware. Los chips son ahora más eficaces y eficientes y con una única máquina física, encima, podemos tener 4, 5, 6 servidores virtuales que hacen la misma labor que uno físico consumiendo recursos de manera altamente optimizada.
Por desgracia, durante las dos últimas semanas y debido a un maldito rayo que cayó donde no debía, he mirado con mucha frecuencia un rack de servidores con 6 máquinas físicas conectados a una cabina de discos con unos cuantos Teras, y no paraba de sorprenderme que allí realmente estuviesen funcionando 26 servidores virtuales. Y lo más bueno es que en septiembre debo desplegar allá unos cuantos más. Con los recortes de presupuesto no os podéis ni imaginar lo contento y privilegiado que me siento de poder usar entornos virtualizados.
Os dejo con este vídeo que José María González me enseñó un día en uno de los estupendos cursos que imparte sobre VMware y virtualización, para que reflexionéis un poco sobre lo que he dicho y luego, si sois CEO o CFO, penséis en vuestra cuenta de resultados. Ah, y por cierto, lo que veréis en el vídeo sucede automáticamente sin intervención humana gracias a VMware DPM (VMware Distributed Power Management).
jul 11
3
En el otoño de 2008, durante una estupenda velada en casa de un buen amigo mío y compañero de promoción, éste me dijo “… el Cloud Computing te dejará sin trabajo, deberías reinventarte …”. A cualquiera que le dijeran algo así, de golpe, se echaría a reír, pero claro, me lo decía la persona que me lo decía, alguien con una visión única en el sector TIC, alguien que, a lo largo de más de 22 años, no se ha equivocado en ninguno de sus vaticinios sobre la evolución de este sector, y alguien que, al menos para mí, ha sido una especie de oráculo o punto de referencia absoluto (siempre le recuerdo que por su culpa yo acabé dedicándome a las TICs). Desde entonces, me he mirado muy de cerca el Cloud Computing y, poco a poco, lo he ido analizando con gran interés y cautela.
Para aquellos que aún no sepáis de qué demonios hablo, Cloud Computing es la última moda en TI, el último grito en tendencias, como años atrás lo fue Internet, la externalización, o la virtualización. La finalidad que persigue no es otra que la de convertir las TICs en un mero suministro, un “pago por uso”, como lo son el agua, el gas o la electricidad, y, de esta manera, de la mano de un proveedor de confianza, aumentar la función de negocio y disminuir la función de tecnología: deje en manos de terceros las TICs y haga que los recursos humanos de su empresa estén centrados en generar valor en lo que su empresa produzca (servicios jurídicos, gafas, ropa, coches, o lo que sea…).
Voy a dar un poco más de detalle sobre qué es y cómo funciona Cloud Computing.
Bajo mi punto de vista, y el de otros muchos, podemos diferenciar el Cloud en tres tipos:
Desde el punto de vista de Recursos Humanos, comenzando por IaaS , siguiendo por PaaS, y acabando por SaaS, a medida que progresamos vamos realizando una mayor y más intensa abstracción de la tecnología y de la complejidad y, por ende, obteniendo una menor necesidad de personal TIC que las gestione y administre. Por lo tanto, en IaaS todavía necesitamos personal que administre la infraestructura (aunque ya no tengamos el CPD en casa), personal que revise la salud de los servidores, que los monitorice, que les haga las convenientes y necesarias actualizaciones de parches, etc… En PaaS, ya hemos prescindido de administradores y técnicos de sistemas, pero aún tenemos desarrolladores y jefes de proyecto en casa, aunque por poco tiempo, porque cuando lleguemos a Saas tan sólo tendremos al usuario final, al personal de la empresa que realmente sepa hacer lo que la empresa haga o venda, o sea, al consumidor final de TICs-Cloud, ese nuevo suministro, esa nueva “utility”. De este modo, hemos completado nuestro camino desde CAPEX (CAPital EXpenditures, esto es, activos normalmente pagados por adelantado -o con financiación, renting, etc…- y que generalmente se deprecian con el paso del tiempo) hasta OPEX (OPerational EXpenditures, esto es, gastos básicos en los que incurre una organización como consecuencia de su propio funcionamiento).
Todo lo que he explicado hasta ahora no es un cuento de hadas, todo esto ya existe y podría citar innumerables casos de éxito (“Telecinco invierte menos de 10.000 € usando Microsoft Azure para dar cobertura en Internet al Mundial de Fútbol de Sudáfrica en 2010”, ver aquí), y no nos engañemos, esto es el sueño de todo CEO,CFO o similar, y más en tiempos de crisis, obligados a reducir costes de donde sea y como sea. Pero como todo en el mundo de la empresa al margen de tener su lado bonito, también existe el lado oscuro. Para aquellos que os guste analizar las cosas con un DAFO, os recomiendo que hagáis click aquí.
Visto lo visto, el “pago por uso” está bien, muy bien. Pero, ¿después de leer este post tienes tentaciones de subir tu aplicación .NET directamente a Microsoft Azure? Pues cuidado, mucho cuidado, ya que puedes acabar descubriendo que, al no haber sido diseñada para trabajar inicialmente en esta plataforma, tu aplicación .NET al correr en sistemas de “pago por uso” puede generar un consumo excesivo de CPU, o de cualquier otro recurso, lo que daría lugar a que la factura de la “utility” se disparase a final de mes. Por eso digo, desarrolladores .NET, instalad todo lo necesario para Azure en vuestro Visual Studio y cambiad vuestra manera de desarrollar. Por cierto, si crees que te has librado de hacer “backup” de tus datos, estás totalmente equivocado: Azure no dispone de copias que cubran el fallo humano, por lo que deberás implementar tu propio sistema o pagar por soluciones de terceros que cubran la posibilidad de que un becario o un jefe de explotación (a todos nos puede pasar) te borre de la base de datos miles de registros por error.
No tener un costoso CPD en tu casa, con su consumo de electricidad y aire acondicionado, es algo genial y, además, puedes venderte a tus clientes como empresa sostenible y ecológica, jactándote encima de que tu proveedor de Cloud hace cosas como las que hace Google (ver aquí). Pero, ¿qué pasa si una excavadora llega con su pala cerca de las instalaciones de tu empresa y se lleva toda la fibra óptica por delante? En ese caso, puedes llegar a desear tener tu CPD bien fresquito en la planta 1 de tus instalaciones. Estas cosas pasan más de lo que creemos.
Llegados a este punto, tienes ya todo en la nube, estás tranquilo, eres más sostenible y ecológico que nadie, ya no cuentas con aquel desagradable y siempre malhumorado administrador de sistemas, solo cuentas con tu gente, la que sabe de tu negocio, y confías que esa capa tecnológica que te permite incrementar las ventas mes a mes (aquello que algunos llaman “alinear las TIC con el negocio”), esa capa que está ahora fuera de tu casa, pero en manos de verdaderos expertos en eso, jamás te va a fallar. Pues falso, esos expertos, generalmente muy mal pagados, al igual que aquel desagradable y siempre malhumorado administrador de sistemas, también se equivocan. A Amazon le pasó (ver aquí). Valora seria y cuidadosamente el impacto que un parón de hasta más de 48 horas de tus sistemas puede provocar en tu cuenta de resultados.
Y por último, está la Seguridad, ese tema tan delicado. Hay quien vende el Cloud Computing como algo altamente seguro, mucho más seguro que tener los datos en casa, ya que si, por ejemplo, nuestras instalaciones sufren un incendio, nuestros datos corporativos seguirán disponibles allá arriba, en la nube. Pero, por otra parte, no olvidemos que con este modelo, por un lado datos críticos para nuestra compañía pueden estar circulando por una red pública, y, por otro, en un sector más allá de la partición NTFS en la que está la base de datos de nuestro BI o nuestro CRM pueden estar los datos de nuestra competencia. Sin olvidar normativa y legislación nacional o europea en materia de custodia de datos.
No quisiera transmitiros con estos últimos párrafos la sensación de rechazo por mi parte a todo lo que huela a Cloud. Nada más lejos de la realidad. Cloud es algo maravilloso y es hoy por hoy una realidad, un tren pesado de mercancías que circula a una velocidad de vértigo desde CAPEX hasta OPEX y que ya nadie puede parar. Ha llegado ya y está aquí para quedarse, y nosotros lo único que debemos hacer como profesionales del sector es adaptarnos a este nuevo paradigma, hacerlo crecer y aportar valor con él a nuestras organizaciones.
Por mi parte, en ello estoy, y pienso seguir compartiéndolo con todos vosotros.
Cerramos un ciclo. Después de preparar un dispositivo de “fencing” para VMware en el post publicado el pasado 29 de Mayo (ver aquí), acometemos el objetivo final que no era otro que el de dotar de un mecanismo de “fencing” (vallado de nodos) apropiado al clúster Red Hat que montamos tiempo atrás (ver aquí).
En este vídeo veremos que las cosas no son tan fáciles como inicialmente podemos imaginar, y nos veremos en la obligación de definir un disco de quórum para ajustar el comportamiento del mecanismo de “fencing”.
Por cierto, durante el vídeo cometo un error al decir que la cifra de 3 en “Total cluster votes” viene dada por forzar el parámetro “expected_votes” a ese valor. Si “Total cluster votes” es igual a 3 es porque se están contando los votos de los dos nodos y el del disco de quórum.
Recomiendo encarecidamente la lectura de este enlace http://magazine.redhat.com/2007/12/19/enhancing-cluster-quorum-with-qdisk/.
Espero que os resulte interesante y os sea de utilidad.
PARTE 1 DE 3
PARTE 2 DE 3
PARTE 3 DE 3
jun 11
9
En el clúster que montamos en el tan traído y llevado video-tutorial “Montando un Red Hat Cluster para servir Apache usando Conga, GFS2 e iSCSI” (y lo que aún le queda), hay un bug: cuando apagamos los nodos, éstos entran en un bucle sin fin mostrando mensajes como el que sigue:
openais[6111]: [TOTEM] The consensus timeout expired. openais[6111]: [TOTEM] entering GATHER state from 3. openais[6111]: [TOTEM] The consensus timeout expired. openais[6111]: [TOTEM] entering GATHER state from 3.
El problema es que como todo buen bucle sin fin, nunca se acaba, lo que nos obliga a parar los nodos de manera forzada. En este enlace de Bugzilla (https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=592125) nos explican cómo resolverlo, pero nosotros, para no tener que ir haciendo la misma modificación nodo por nodo, instalaremos “Cluster SSH”, una herramienta diseñada por Charly Kühnast, pensada para realizar trabajos mecánicos y repetitivos en múltiples máquinas de manera simultánea.
Espero, una vez más, que os sea de utilidad.
may 11
29
Aquí está la primera parte de la asignatura que dejamos pendiente en el video-tutorial “Montando un Red Hat Cluster para servir Apache usando Conga, GFS2 e iSCSI”.
En esta primera entrega preparamos la configuración de “fence_vmware”, que como veréis está llena de trampas, para que en un video-tutorial posterior retomemos la configuración del clúster que montamos entonces y le podamos configurar el “fencing” de manera adecuada para poder trabajar en entornos de producción.
Las fuentes seguidas para elaborar el presente video-tutorial son:
https://bugzilla.redhat.com/show_bug.cgi?id=590304
http://sourceforge.net/projects/viperltoolkit/
http://www.mail-archive.com/linux-cluster@redhat.com/msg09654.html
Espero que os sea de utilidad.
En este video-tutorial dividido en 6 partes explico cómo realizar el montaje de una arquitectura clusterizada para ofrecer un servicio, en nuestro caso Apache, en alta disponibilidad. En el montaje usamos Red Hat 5.5 (si no disponéis de él podéis usar perfectamente CentOS 5.5) con sus “suites” de “Clustering” y de almacenamiento compartido. A esta arquitectura le conectaremos el sistema iSCSI basado en Openfiler, DRBD y Heartbeat que montamos en un post anterior, lo cual dotará al conjunto de un número reducido de SPOFs (Single Point of Failure). Este sistema de almacenamiento compartido lo formatearemos con GFS2, un potente sistema de ficheros disponible en Red Hat y CentOS, que está orientado a este tipo de arquitecturas compartidas gracias al sistema de bloqueo DLM (Distributet Lock Manager). Por cierto, que no lo menciono en el video, en todos los elementos Red Hat que intervienen en el montaje se ha deshabilitado IPTables y SELinux para evitar que interfieran el trabajo de los distintos agentes que intervienen en la arquitectura.
El video-tutorial se basa en un documento PDF que podréis descargar desde aquí, y un pequeño esquema del montaje que también os podréis descargar desde aquí.
Después de ver este video-post, recomiendo veáis estos otros dos:
http://www.eduardocamposjimenez.es/?p=157
http://www.eduardocamposjimenez.es/?p=197
Espero que os sea de utilidad.
PARTE 1 DE 6
PARTE 2 de 6
PARTE 3 de 6
PARTE 4 de 6
PARTE 5 de 6
PARTE 6 de 6
En este video-tutorial dividido en 4 partes explico cómo realizar el montaje de un sistema de almacenamiento iSCSI dotado de alta disponibilidad, usando Openfiler, DRBD y Heartbeat. Hace ya unos años tuve mi primer contacto con DRBD y me pareció algo interesantísimo. En aquel momento alguien dijo “ha nacido el cluster de los pobres”, y no le faltaba razón, ya que es software libre y nos permite disponer de nuestros datos en alta disponibilidad al estilo de una RAID-1 de red. Si esto lo combinas con el experimentado y superprobado Heartbeat dentro de una distribución Linux estable y fiable (Openfiler es eso), puedes obtener en entornos de producción no muy exigentes unas prestaciones espectaculares por poco dinero (o ninguno, si reaprovechas hardware obsoleto).
El video-tutorial se basa en un documento PDF que podréis descargar desde aquí, y que a su vez está basado en un HOW-TO que podréis encontrar también aquí: thank you very much “gilly05” (autor del How-To)!!!!.
Espero que os sea de utilidad.
PARTE 1 DE 4
PARTE 2 de 4
PARTE 3 de 4
PARTE 4 de 4
sep 10
18
Una de las novedades que nos trajo la llegada de Windows Server 2008 fue la posibilidad de tener diferentes directivas de contraseñas y poder aplicarlas particularmente a usuarios o grupos de usuarios específicos.
En el vídeo mudo que adjunto arriba podréis ver los pasos a seguir para crear una de estas políticas y aplicarla, por ejemplo, al grupo “Marketing” de vuestro Directorio Activo.
Los parámetros que usamos para este ejercicio son:
msDS-PasswordSettingsPrecedence
“Prioridad de la configuración de contraseña”, con un valor de “1”
Se trata de un valor entero que se usa para resolver conflictos en caso de que varios PSO se apliquen a un usuario u objeto de grupo. Su valor puede oscilar entre 0 y 10
msDS-PasswordReversibleEncryptionEnabled
“Estado de cifrado reversible de la contraseña de las cuentas de usuario”, con valor “FALSE”
Almacenar contraseñas con cifrado reversible: mejor que no, no vaya a ser que a alguien se le ocurra darle la vuelta.
msDS-PasswordComplexityEnabled
“Estado de complejidad de la contraseña de las cuentas de usuario”, con valor “TRUE”
La complejidad de contraseña puede ser un quebradero de cabeza para algunos usuarios y por ende, su administrador. A gusto del consumidor.
msDS-MinimumPasswordLength
“Longitud mínima de la contraseña de las cuentas de usuario”, con un valor de “20”
Quizás con “8” había suficiente, ¿no?.
msDS-MinimumPasswordAge
“Vigencia mínima de la contraseña de las cuentas de usuario”, con un valor de “2:00:00:00”
Ese valor significa 2 días.
msDS-MaximumPasswordAge
“Vigencia máxima de la contraseña de las cuentas de usuario”, con un valor de “42:00:00:00”
Pasados 42 días hay que cambiar.
msDS-LockoutThreshold
“Umbral de bloqueo para bloquear cuentas de usuario”, con un valor de “50”
Hay que ser muy lerdo para equivocarse 50 veces, ¿no?
msDS-LockoutObservationWindow
“Ventana de observación para bloquear cuentas de usuario”, con un valor de “0:00:30:00”
Ese valor significa 30 minutos. Observamos que nos hacen durante ese tiempo antes de bloquear.
msDS-LockoutDuration
“Duración del bloqueo de cuentas de usuario bloqueadas”, con un valor de “0:00:30:00”
Si alguien se pasa de listo deberá esperarse 30 minutos para poder volver a intentarlo.
msDS-PSOAppliesTo
“Establece vínculos a los objetos a los que se aplica este objeto Configuraciones de contraseña (vínculo de avance)”, con valor “CN=Marketing,OU=Corp,DC=woodgrovebank,DC=com”
Para los del grupo Marketing del banco de siempre, que son unos liantes.
Saludos