Windows Server es tan "difícil" de administrar como Linux

Termino una semana más en el training de Windows Server 2008 R2, básicamente ganando profundidad en conocimientos que fui viendo a lo largo del tiempo, ya que siempre se termina trabajando de una u otra forma con servers Windows, incluso siendo un especialista en Linux/Unix. 

El Mito 1: Si sabés administrar bien el cliente, el server es igual de fácil
Todos los administradores de Windows Server lo escucharon alguna vez, el usuario avanzado típico de Windows, que sabe administrar muy bien - al máximo - el sistema operativo cliente, Windows XP, Windows 7, etc. supone en gral. que administrar Windows Server - cualquier versión - no va a ser mucho más difícil que sentarse delante y empezar a hacer clicks. 

Eso es un error, el conocer la GUI de Windows Server por ser igual o muy similar a la del cliente no los vuelve automáticamente administradores de Winserver, simplemente porque en gral. no están familiarizados con las cuestiones internas del S.O. de servidor, ni tampoco suelen conocer sobre las complejidades de los diferentes servicios - muy avanzados en gral. por cierto - que se puede correr e implementar en el S.O. 

En contraste ayuda mucho realmente el que ya tengan buena experiencia previa en administración de Linux, ya que los pone al tanto de cuestiones generales de administración de sistemas, que se aplican por igual a cualquier sistema operativo de servidor.



El Mito 2: Windows Server es más "fácil" de administrar que Linux
Mi opinión acerca de la supuesta "facilidad" de Windows Server para ser administrado se mantiene: winserver tiene sus más y sus menos, la tecnología tiene puntos fuertes y puntos débiles, pero de ninguna manera es superior desde lo técnico a similares tecnologías que se puede encontrar en Linux/Unix. 

Tampoco existe realmente una mayor facilidad en la administración en gral., Winserver tiene puntos fuertes en cuanto a la GUI, especialmente en cuanto a soluciones muy comunes y de habitual implementación, que se hacen muy rápido y en pocos clicks (por ejemplo, configurar fileservers).

Sin embargo la supuesta simplicidad se diluye muy rápido cuando las instrucciones básicas para configurar cualquier solución medianamente compleja abarcan hacer 45 clicks en 9 ventanas diferentes, en una secuencia precisa y en un contexto de configuración específico. Un solo click fuera de lugar o una opción que elijas sin saber exactamente qué hace y por qué la clickeaste, y vas derecho al Visor de Eventos+Process Explorer (systernals), como mínimo, y el resto de la configuración queda sin terminar hasta resolver el problema.


Configuración y Troubleshooting
Sets de instrucciones paso a paso, precisas y de calidad, para construir una determinada solución son muy escasos en relación con lo que hay disponible para Linux en gral., por ejemplo, documentos similares a los encontrados en howtoforge.com. 

Un ejemplo de howtos de configuración muy bueno para Windows Server, se puede encontrar en bujarra.com. Y allí pueden verificar qué tan simple es manejar la GUI.

La sensación de no saber donde buscar primero cuando falla algo en la GUI de Windows Server no tiene parangón en Linux/Unix, donde siempre hay logs detallados esperando al administrado cuando ocurre un fallo (si es que el mismo no está justo en ese momento mirando los logs correr justo delante de él, TIP: "tail -f log" es tu amigo). Claro, existe lo mismo en Win (y casi siempre los servicios soportan parametrización que eleva el nivel de debug). Pero el administrador de winserver novato se va a encontrar con las manos atadas cuando la GUI no le provea respuesta alguna de por qué no arranca un servicio en winserver, o por qué arrancó y luego falló, etc.

De todos modos, la utilidad de las msc (las consolas de administración de MS), es relativamente limitada al momento en que las cosas no funcionan o se requiere configuración avanzada. Y ahí hay que bajar muy rápido a powershell y usar commandlets para trabajar en serio.


Cómo aprender
La clave de poder administrar bien Windows Server y Linux es conocer lo suficiente de cómo trabajan ambos sistemas operativos internamente.

Se puede empezar a entender cómo funciona Windows Server leyendo material como este:

- Windows® Internals, Part 1: Covering Windows Server® 2008 R2 and Windows 7

- Windows® Sysinternals Administrator's Reference (viejo libro, pero muy bueno para aprender tips importantes, todavía útiles al día de hoy)

- Advanced Windows Debugging

En Internet, más que buscar la documentación oficial de Microsoft, los documentos más útiles se pueden leer en la KB (Knowledge Base) oficial, en Technet y en los blogs técnicos semi-oficiales para los productos (que los escriben usuarios avanzados, sino directamente empleados de Microsoft muy involucrados con los productos).



Conclusiones
No dudo igualmente que para un especialista que solo conoce en profundidad la administración de Windows Server, el mismo resulte aparentemente más fácil de administrar para soluciones complejas que cualquier Linux/Unix. Sin embargo, para los administradores que tenemos mucha experiencia en Linux y a la vez, considerable experiencia en administración de Windows Server, las complejidades, facilidades y dificultades son diferentes, pero están presentes en ambas plataformas, y diría por igual.

Linux en sí tiene iguales cantidades de puntos fuertes y débiles que Windows Server en cuanto a la administración, la configuración de soluciones complejas y el troubleshooting de problemas complejos.

Por ejemplo, no saber cómo se integra la capa de customización de interfaz gráfica desde Windows Server 2008 en adelante, con el core del sistema operativo, puede llevar a importantes dolores de cabeza: Al intentar instalar ciertos componentes y aplicaciones donde los "Locale" sean diferentes a los del sistema operativo, en principio, el S.O. probablemente ni siquiera les deje instalar nada, y luego reconfigurando los locale, les deje instalar tranquilamente el mismo componente/software que no dejó instalar minutos antes.

Link del Issue mencionado arriba: 
https://connect.microsoft.com/SQLServer/feedback/details/556958/sql-server-setup-media-does-not-support-the-language-of-the-os

Active Directory, checked

Contento che, recién salido del training de Windows Server, configuré hands-on mi primer Active Directory DC, y estuve paso a paso gritandole a Pablo (del team de training), qué hacer para agregar un member. 

Era una especie de deuda que tenía que cumplir, siempre me decían que era complicado-pero-fácil y ya había leído en algun momento tutoriales bastante high-level - ver en el link - y se vía fácil (era de algun modo fácil pero tiene bastantes detalles críticos, parecido a configurar un cluster), pero no me surgió hasta ahora la necesidad de deployar un AD (ni pintó montar un lab para hacerlo @home). Bueno, ahora sí, AD configuration, checked, a leer sobre administración ahora.

Justo venía pensando, ¿Qué es lo primero que tiene que hacer un administrador luego de aprender a configurar algo? Romperlo, sí, de inmediato, para luego empezar a aprender a repararlo. Si tenés una DB nueva recién instalada - en un entorno de testing claro -, andá y dale un kill -9 al pid de la base, fijáte cómo se arregla eso, cómo no se arregla (tip: por acá viene la mano :-), y por qué no tenés que killear pids de bases de datos que están online.

Es parte del proceso, configurar, administrar, etc. Si no lo rompés de inmediato, cuando algo falle va a ser la primera vez que te encontrás con el soft muerto, sin responder, y vas a tener que investigar desde cero cómo repararlo (mientras de atrás te corren para que ande lo antes posible).


Así que haciendo honor al training típico de sysadmin, ni bien levantamos el DC, el member falló a la mitad antes de unirse; así que empezamos (bah, Pancho empezó), a correr procedimientos de recuperación y limpieza (el AD queda "sucio" por el proceso a medio completar), borrando cosas por acá y por allá, joineando el server candidato a member al domain, etc. Y así ya estuvimos viendo un poco de troubleshooting light para cuando, por decirlo de modo políticamente correcto, las cosas se van al carajo.

Escuché que no teníamos que modificar la configuración DNS unas 25 veces en 2 horas, y después pregunté por casos en que había que efectivamente meterse y modificar esa config (tip, hay casos,  y hay que hacerlo con cuidado de joder nada).

Aprendiendo a garabatear diseños de infraestructuras

En este artículo comento acerca de enfoques recomendados para encarar el diseño de nuevas infraestructuras, también acerca de los motivos para adoptar distintos enfoques y ello acompañado de ejemplos de infraestructuras reales en las que trabajé (o estoy trabajando).


Ser Ordenados
Si me dieran un centavo por cada vez que escuché que hay que hacer y planificar las cosas ordenadamente cuando se diseña una infraestructura...lo que es correcto.

Sin embargo, vivimos en un mundo imperfecto, por ende es un caso muy común el que tengamos que diseñar infraestructuras de sistemas con los que no hemos trabajado nunca antes. Es una cuestión típica del trabajo en infraestructura IT, trabajar con tecnología desconocida.

Por ejemplo, esa nueva cabina SAN que se compra una organización en estos días de infraestructuras virtuales, que puede tener a un equipo completo de ingenieros experimentados sentados alrededor como si fueran pastores de ovejas mirando por primera vez el arca de Noé.

Los casos en que un profesional IT está fuertemente especializado en una tecnología están ligados casi exclusivamente a los altos niveles de skillset y de experiencia previa, y claro, sabemos que el equipo IT promedio no está compuesto en su totalidad por - digamos - 7 ingenieros con 10 años de experiencia en Windows Server (cada uno), sino por tal vez un par de ingenieros con mucha experiencia (2 Seniors), otro par con menos experiencia (2 SSr.), y varios ingenieros novatos (3 juniors).

La posibilidad de trabajar ordenadamente está fuertemente relacionada con el nivel de experiencia y conocimiento previo que se tenga sobre un sistema. Si el nivel es 0 o tendiendo a cero, tenemos que replantear la estrategia de diseño.

Así que cuando estamos diseñando infraestructuras de sistemas que no conocemos previamente ¿Cómo se puede proceder ordenadamente?


Enfoques
Hay dos enfoques típicos en general (no son los únicos):

1) Aprender todo primero y luego hacer el trabajo
Acá tenemos un problema, el tiempo, se tarda mucho tiempo en leerse 300-600 hojas de material técnico sobre el sistema a implementar. 300 a 600 hojas de libros/tutoriales es una cantidad estándar de material que abarca desde una introducción teórica, pasando por una instalación básica, llegando a la configuración básica, luego tratando temas avanzados y finalmente tratando con temáticas de recuperación y troubleshooting.

El enfoque 1) suele ser el enfoque a utilizar cuando se necesita implementar un sistema utilizando el grueso de sus capacidades técnicas (70% al 100% de sus opciones, etc.), normalmente para estos casos, si es que la planificación fue adecuada, tendremos incluída una capacitación en el costo de adquisición del sistema.

Por ejemplo, se compra una licencia de Windows Server para montar una infraestructura virtual basada en Hyper-V + System Center Virtual Machine Manager 2008 R2, donde vamos a montar un Active Directory, Exchange, SQL Server como backend - server separado - de una aplicación (también a instalar). Evidentemente, el nivel de conocimiento sobre Windows Server tiene que ser bastante alto para poder hacer todo esto en un tiempo razonable. 

2) Manos a la obra (Hands on)
Acá tenemos un foco más directo, agarramos buenos tutoriales de la red, los revisamos, adquirimos conceptos básicos (la terminología usada en el sistema por ejemplo, sumamente importante), luego podemos sentarnos tranquilos a leer las introducciones y explicaciones teóricas de los libros (de 50 a 100 hojas típicamente). Después podemos montar un entorno de prueba y empezar a testear los tutoriales básicos.

El enfoque 2) es más adecuado cuando ya se tiene una idea de que la implementación del sistema no va a utilizar - al principio al menos - demasiadas capacidades técnicas, así que lo que hace falta entender para poder configurarlo apropiadamente es poco en comparación con el caso 1).

Por ejemplo, se compra una licencia de Windows Server para utilizarlo como File Server, vean acá lo que hace falta hacer para configurar un Windows Server como file server (es un video de 5 minutos de duración):

http://www.youtube.com/watch?v=fBvi3giio-I


Pies en la tierra
Siendo realistas, la mayoría de las tecnologías informáticas nuevas que se suele introducir en una organización no tienen la urgencia de ser implementadas en un tiempo límite (por ej. "tiene que estar terminada y funcionando con fecha límite en marzo 2013"). 

Pocas veces la implementación de nueva tecnología informática no pasa por el ciclo de testeos y pruebas piloto, previas a un deployment piloto y antes de una implementación masiva final.

Menos veces aún la misma tecnología se implementa desde cero (nada implementado en la organización), hasta niveles de implementación donde se use el 70-100% de las capacidades técnicas de la tecnología, abarcando una solución organizativa completa: un sistema/servicio consumido masivamente por clientes internos distribuídos por toda la organización. Tal es el caso del ejemplo mencionado de Windows Server + Hyper-V + SCVMM + AD + Exchange + SQL Server + Aplicación.

Y es sumamente escaso el ejemplo de una implementación con tiempo límite + desde cero a todo.

[ Los casos de proyectos de implementación de tecnología informática que tengan características de "con tiempo límite", "de cero a todo" y sus combinaciones, se dan típicamente cuando hay al menos un Senior y/o varios SSr. conocedores y/o con experiencia previa - práctica y útil - en la tecnología a implementar. ]

El ejemplo típico de "con tiempo límite"+"desde cero a todo" esta ligado al 99% con hardware. O sea, no se puede implementar "de a poco" una SAN de 5 TB. Hay que comprarla, configurarla, migrar el uso de storage local de los servers a los volúmenes de la SAN, y pum!, ya se está amortizando el TCO. Caso contrario (NO recomendado por supuesto), el TCO crece paulatinamente mientras transcurre el tiempo de soporte (acercandose cada día el momento en que será descontinuado por el fabricante y tendremos que comprar tiempo de soporte adicional, entre otras varias circunstancias desfavorables y no recomendables para el proyecto "comprar SAN").


El caso más usual
En realidad, el caso usual donde se trabaja implementando tecnología informática nueva de infraestructura implica una adopción paulatina, relativamente limitada, y atendiendo a necesidades puntuales (es decir, donde no se va a utilizar más que una mínima cantidad de características técnicas del sistema).

Por ejemplo, se intenta elevar el grado de awareness de la organización respecto de un creciente número de servidores. Así que se estudia y decide implementar paulatinamente Nagios como solución de monitoreo básico.

- Se instala y configura Nagios, se carga una configuración básica que permita ping monitoring (ver si los servidores están "activos" pingueandolos cada cierto tiempo). Adicionalmente se configura el mecanismo de alerta para que envié mails en el evento de falla del ping monitoring de cualquier server.

- En una mejora subsiguiente de solución, se incorpora una estructura de autenticación vía SSH keys en el servidor Nagios, y se le agrega a Nagios el monitoreo de sistemas internos de los servidores (basado en acceso vía SSH). Esto mejora mucho la solución inicial de "ping monitoring only".

- En una tercera instancia, se incorpora el uso de agentes locales en los servidores a monitorear. Añadiendo así un nivel de sofisticación (y capacidades adicionales), muy superior al obtenido en la 2da. instancia vía monitoreo basado en acceso SSH.


Conclusiones
Como se puede deducir del ejemplo de implementar Nagios paulatinamente, el nivel de conocimiento de Nagios de los administradores de sistemas va a ir creciendo a medida que vayan trabajando con Nagios, recorriendo la curva de aprendizaje de a poco, sin por ello dejar de brindar e implementar la solución de monitoreo requerida por la organización.

Si tuviéramos que proceder en modo "de cero a todo", la curva de aprendizaje se hace mucho más grande (hay que aprender muchas cosas en poco tiempo), y por ende, *2 si los administradores no tienen el beneficio de un entrenamiento brindado por terceros (un curso, etc.), normalmente la organización va a quedarse *1 sin monitoreo para sus servidores por un tiempo muy largo hasta que los administradores de sistemas tengan los conocimientos necesarios para implementar Nagios "de cero a todo".

*1 Si además hay un tiempo límite, no implementar la solución de "cero a todo" por estar aprendiendo, ello podría tener repercusiones negativas en la organización; probablemente el monitoreo se estaba necesitando - con tiempo límite - por razones puntuales. Por ejemplo, reevaluación del ciclo de vida típico de los servers por apagado/reinicio contínuo por fallas en el suministro eléctrico.

*2 La capacitación de alto nivel técnico, especialmente orientada a capacitar administradores de sistemas a nivel "de cero a todo", y en poco tiempo (semanas, máximo meses), tiene costos tan altos que cuando se compra hardware de nivel industrial (SANs por ejemplo), el porcentaje de costo del entrenamiento suele ser de dos guarismos (10%, 15%, etc.), del costo de adquisición del hardware.

Por todo eso es que las implementaciones paulatinas son las más habituales.

Windows 2012, un primer vistazo

Hoy se está liberando la versión 2012 de Windows Server y muchos administradores ya están pensando ponerle las garras encima. Encontré un par de artículos y comparto la información que leí en ellos.

Powershell y administración
Una de las mejores características es la adopción de powershell como herramienta pervasiva de administración: todos y cada uno de los aspectos de Windows Server pueden ser configurados vía CLI (Command Line Interface).

Dadas las actuales necesidades de automatización, es fácil ver como esos commandlets powershell van a terminar en scripts "glue" para diversas tareas, que hoy son a duras penas realizadas vía scripts batch (los viejos archivos .bat).

Claro, es justamente la idea ya que cualquier configuración realizada ya sea desde la interfaz gráfica Server Manager o desde powershell, puede ser exportada a una plantilla en XML, y de ese modo reutilizada como base para instalaciones automatizadas de otros servers via powershell.

Hyper-V 2012
Hyper-V se vuelve una plataforma muy fuerte en esta versión, y ya desde hace meses se sabe que la competencia (vSphere), va a estar en aprietos para muchos escenarios de infraestructuras virtuales. Por ejemplo, la versión Free de Hyper-V se puede bajar e instalar el hipervisor en varios servers, no incluye las herramientas de administración; pero comprando una sola licencia de Server 2012, se los puede configurar a todos y crear un cluster de servers con failover automático.

La característica de replicación puede ser usada para DR - Disaster Recovery. A diferencia de las soluciones DR basadas en SAN, Hyper-V no necesita que el hardware en los demás nodos sea idéntico, o que tenga la misma capacidad de almacenamiento; solamente con tener discos virtuales donde "entre" o "quepa" la máquina virtual, está presente la posibilidad de replicarlas allí y ponerlas online - remota/automáticamente vía failover capability - en el evento de una falla.

Capacidades SAN
Windows Server 2012 eleva las capacidades de agrupamiento de discos permitiendo formar, administrar grupos de discos como un único "pool", proveer (publicar) volúmenes lógicos (vía iSCSI) con bastantes capacidades de resiliencia a fallos (vía Resilient File System - ReFS, por ejemplo), hacer thin provisioning de la capacidad de storage disponible (publicar varios discos cuyos espacios totales sumados resultan en una capacidad mayor que el espacio de disco total y real disponible).

Las capacidades de provisión de storage vuelven el sistema operativo un candidato ideal para la construcción de SANs de mediana capacidad para entornos pequeños (que justamente no podrían permitirse pagar hardware SAN dedicado), e incluyen una fuerte capacidad de customización y adaptación (muy necesaria cuando el storage, los discos, pueden ser simplemente discos locales, RAIDs locales por hard o soft, etc.).

Deduplicación
Las capacidades de deduplicación de datos de Windows Server 2012 quedan por verificar en implementaciones reales, sin embargo, incluyen el "pack" completo de características encontradas en otros sistemas operativos que implementaron deduplicación (Solaris, NetApp, etc.), y probablemente algunas mejoras evolutivas lógicas (obtenidas de las experiencias ajenas al respecto).

La deduplicación de datos es una característica presente en muchos hardware SAN y se realiza vía hardware en gral. y muy eficientemente. Así que obviamente se suma esta capability a las de manejo de storage, repotenciando el posible uso de win2012 para SANs "homemade" chicas a medianas.

Licenciamiento
El nuevo licenciamiento para win2012 se basa en licenciar por pares de procesadores. La funcionalidad de las versiones Estándar y Datacenter son las mismas ahora, la única diferencia es el número de máquinas virtuales soportadas por licencia. La versión Estándar se vende a U$S 882 hasta para dos procesadores y solo soporta dos máquinas virtuales por licencia; la versión Datacenter a U$S 4809 por licencia soporta una cantidad ilimitada de máquinas virtuales.

La licencia del server se puede utilizar en una máquina virtual corriendo en el server, por lo que con una licencia Estándar se puede correr hasta 3 máquinas virtuales por server de dos procesadores. Si querés correr ocho máquinas virtuales Windows, vas a necesitar 4 licencias estándar.

Si vas a correr máquinas virtuales con sistemas operativos no Windows, podés usar la versión Free de Hyper-V 2012, y correrlas en otro server, teniendo las mismas características del Hyper-V "pagado", soportando un número ilimitado de máquinas virtuales. De esto último no se hace mucha publicidad, pero es un hecho práctico: podés usar Hyper-V 2012 sin pagar ninguna licencia y usarlo para correr la cantidad de server virtuales Linux que quieras por ejemplo.

Links:
http://arstechnica.com/information-technology/2012/09/windows_server_2012_first_look/2/

http://blogs.technet.com/b/filecab/archive/2012/05/21/introduction-to-data-deduplication-in-windows-server-2012.aspx