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).

Arquitectura propietaria: servers Windows y antivirus+antimalware

Corriendo servers Windows, la política por default típica - del planeta? - implica correr necesariamente, obligadamente software antivirus y antimalware de nivel industrial en el server.

Hay diferentes enfoques que plantean lo contrario, principalmente adheridos a las posibilidades de "aislar" el server de cualquier comunicación con Internet. Sin embargo, inclusive dado un escenario perfecto de aislamiento de alto grado, muy propio de infraestructuras de alta seguridad, existe malware relativamente accesible en Internet que permite realizar ataques dirigidos muy eficaces usando jump-points como >

- USB keys: la víctima conecta USB keys a máquinas internas, el malware extrae la información, la guarda en la USB key, luego, cuando la víctima conecta el USB key en su PC hogareña, el malware se conecta a Internet y envía la información robada.

http://www.infosecurity-magazine.com/view/26761/indian-navy-secrets-stolen-and-sent-to-china/
http://www.indianexpress.com/news/china-hackers-enter-navy-computers-plant-bug-to-extract-sensitive-data/968897/0
http://www.theregister.co.uk/2008/07/01/japan_sensitive_usb_drive_lost/

- o inclusive infectando files que se transfieren habitualmente vía correo electrónico (fotos, etc.)

Etc.

Los motivos para instalar software antivirus y antimalware en un server Windows no faltan, más allá de cualquier aislamiento de seguridad lógico (vía routing, FW rules, filtering L7, etc.), o físico (que la red del servidor esté físicamente desconectada de cualquier red con conexión a Internet).

La policy de seguridad por default debe ser siempre instalar soft antivirus y antimalware en Windows Server.

Failover clusters, sumo otra explicación a las que hay + muchos links

Al día de hoy ningun server deployado en funciones de misión crítica debería correr fuera de un esquema de - al menos - alta disponibilidad, es decir, hablemos de clusters.

Primero el contexto, hablamos aquí de - tres - servers físicos en configuración de failover cluster, activo / pasivo.

El más famoso tipo de cluster a nivel empresarial/organizacional es el failover cluster. Básicamente tendremos dos servers idénticos (bah, iguales), cargados con el mismo software y configuraciones, compartiendo - de algun modo - el espacio de almacenamiento; típicamente y desde lo más recomendable, algun tipo de storage SAN, hardware o "amañado" - ya vamos a hablar de eso - aunque se puede recurrir a replicación (no hay un storage externo a los servers, pero hay en pie un soft que replica el contenido de los discos entre ambos servidores físicos).

Hay otros tipos de clusters muy interesantes - loadbalancers, la especialidad del devop típico por ejemplo - y pueden cultivarse por demás en los links de abajo, sigo con los failover clusters aquí.

El objetivo primario del failover cluster es que si un server físico se "cae" (el OS deja de responder, quema, explota, apaga por razones desconocidas, etc. etc.), el otro server físico automáticamente va a tomar el lugar del primero y el servicio que brinde el cluster seguirá proporcionandose a los clientes del mismo (que permanecerán gloriosamente ajenos al drama de recuperar el nodo primario caído).

El caso de uso por excelencia de un failover cluster es para servidores de base de datos, más o menos el corazón operativo de la mayoría de las aplicaciones de una organización.

Imagínense un servidor de base de datos de misión crítica, deployado fuera de un cluster...

Tenemos un array de 10 discos en RAID 6, que se banca perder hasta 2 discos del array sin fallar, doble procesador, triple procesador (ironía), 64 GB de memoria en 16 bancos de 2 gigas (ironía), podemos tener cierta redundancia para conectividad al agrupar placas de red en bonding (X tipo, a piacere del administrador o por disposición de policies, según el "shop" donde esté el server), etc. ...pero, tenemos una sola placa madre, forzosamente los 10 discos del RAID6 dependen de una sola placa controladora;

[¿se puede armar un RAID6 por hardware con redundancia de placas controladoras? Si se puede, los aportes de información son bienvenidos]

Solamente por tener una sola placa madre en el server, sosteniendo la función de misión crítica de la que depende una organización, es mandatorio configurar ese server de base de datos en un failover cluster.

Para clustering hay muchas y diversas tecnologías. La arquitectura del failover cluster típico consiste en un par de servers de "procesamiento" (nodo primario y nodo secundario), uno - el nodo primario - de los cuales va a estar trabajando efectivamente hasta que se produzca el evento que ponga en acción el otro - el nodo secundario. Ambos van a compartir espacio de storage, es decir, van a "ver" las mismas "particiones".

¿Cómo es que van a ver las mismas "particiones"? Muy simple, la arquitectura incluye - en gral. - un tercer server, que brinda el espacio de almacenamiento o storage compartido que el cluster va a utilizar.

En realidad el storage compartido podría ser un dispositivo de storage real, una SAN, pero, son bastante caras en vista a configurar el failover cluster básico del que estamos hablando (que ya se ocupa 2 servers físicos para una sola función), por lo que típicamente se busca utilizar algun buen server con mucha redundancia en RAID.

[ Vamos a buscarle el pero a esto: este tercer server también tiene una placa madre verdad? bien, es cierto. En este punto ya podríamos hablar de elevar la redundancia del storage compartido, ahora sí, configurando filesystems replicados entre ambos servidores de un cluster que brinde storage compartido al failover cluster original.]

Es bastante fácil configurar esta arquitectura tanto en Windows Server como en Linux y es muy recomendable hacerlo. Redundo, pocos aventureros - involuntarios en los peores casos - corren conscientemente servers de misión crítica fuera de un esquema de alta disponibilidad.

Si en este punto surgiera hablar de virtualización, ¿qué hacemos si los servers no son físicos y corren sobre hipervisores? Aquí la redundancia se puede arreglar de formas más "variadas" que en el mundo físico, por ejemplo, a nivel de la virtualización, teniendo los servers del cluster en diferentes hipervisores (distintos servers físicos), con el obvio cálculo obligado de overheads sumados que pueda encontrar, o si estamos ya en una infraestructura virtual completa, tal vez no sea necesario configurar el cluster en más de un hipervisor (corriendo ambos servers sobre el mismo hardware), pero de vuelta volcando la función de redundancia en la infraestructura virtual mediante funciones de replicación en background (copiando en background ambas máquinas virtuales de un hipervisor a otro), y hot-standby de máquinas virtuales (permitiendo que el hipervisor secundario, de respaldo corra las máquinas virtuales del cluster en caso de un fallo del hardware físico que sostiene al hipervisor primario).

..en fin,

¿Alguien puede aportar links de howtos simples de failover clusters (active / pasive) para RHEL, Ubuntu, etc.? 

Porque encontré un par, pero me parece que sería lectura obligada el pdf de la documentación oficial de RHEL.


En los links de abajo pueden ver diversos tutoriales que recopilé, para Win 2008 Server y Linux (Ubuntu y RHEL).

Windows Server

Windows Server 2008 Clustering Whitepapers
http://www.microsoft.com/en-us/download/details.aspx?id=13153

Para leer:
Overview of Failover Clustering with Windows Server 2008.doc
Windows Server 2008 Failover Clustering Architecture Overview.doc
WS2008 Failover Clustering Datasheet.doc

Failover Clusters in Windows Server 2008 R2
http://technet.microsoft.com/en-us/library/ff182338(v=ws.10).aspx

Creando un Cluster de Windows Server 2008 (Parte 1)
http://blogs.technet.com/b/ponicke/archive/2007/10/08/creando-un-cluster-de-windows-server-2008-parte-1.aspx

Creando un Cluster de Windows Server 2008 (Parte 2)
http://blogs.technet.com/b/ponicke/archive/2007/10/09/creando-un-cluster-de-windows-server-2008-parte-2.aspx

Creando un clúster de alta disponibilidad en Microsoft Windows Server 2008
http://www.bujarra.com/?p=2290

(este otro es un requisito para el tutorial anterior)
Creando un iSCSI Target en Windows Unified Data Storage Server
http://www.bujarra.com/?p=2234

Linux (Ubuntu)

(este es nuevito, del 12 de abril 2012)
Simple Apache failover cluster on Ubuntu with config synchronization
http://laurentbel.com/2012/04/12/simple-apache-failover-cluster-on-ubuntu-with-config-synchronization/

Linux (RHEL)

Red Hat Enterprise Linux Cluster, High Availability, and GFS Deployment Best Practices
https://access.redhat.com/knowledge/articles/40051

[Nunca está de más leer primero el título "Unsupported Items", antes de empezar a investigar diferentes enfoques posibles en el montaje de un cluster RHEL, así evitaremos montar configuraciones no soportadas oficialmente.]

Red Hat Enterprise Linux 6 - Cluster Administration
Configuring and Managing the High Availability Add-On
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Cluster_Administration/index.html


(este bien se puede implementar en RHEL)
How To Set Up An Active/Passive PostgreSQL Cluster With Pacemaker, Corosync, And DRBD (CentOS 5.5)
http://www.howtoforge.com/how-to-set-up-an-active-passive-postgresql-cluster-with-pacemaker-corosync-and-drbd-centos-5.5

(este viejito me gustó por el detalle que tiene la narración, obviamente está outdated respecto de nuevas versiones de RHEL, y ni hablar de que hay que darle una revisión detallada para no utilizar algun esquema no soportado oficialmente)
Redhat Cluster 4 how-to
http://unixnotebook.blogspot.com.ar/2005/07/redhat-cluster-4-how-to.html

(este no me pareció muy completo en realidad)
RedHat Cluster Suite And Conga - Linux Clustering
http://www.howtoforge.com/redhat-cluster-suite-and-conga-linux-clustering

Experiencias con Hyper-V y Windows Server 2008 Core

Hace un par de semanas, estuve trasteando con un Hyper-V. Como pueden saber, comprando un Windows 2008 Server Enterprise, se posee licencia para correr legalmente hasta 4 (cuatro) instalaciones virtuales de Windows 2008 sobre un hypervisor Hyper-V.

No me interioricé fuertemente en Hyper-V más allá de este primer contacto porque arrancó como una experiencia piloto. Básicamente se instala Windows 2008 Server en modo "Core", es decir, sin interfaz gráfica, así que al loguearnos nos aparece una consola (cmd) y ahí tenemos que interactuar con la instalación recién realizada, acá viene la parte clásica de configuración del server y de networking (para poder empezar a hacer algunas cosas), luego hay que añadir el Rol de Hypervisor, para lo cual el instalador modo texto de Win08, se conecta a Internet a un sitio de Microsoft checkeando que el paquete de Rol Hyper-V de nuestro instalador (un dvd oficial), es el último disponible, y si no lo fuera, descarga automáticamente una nueva versión y la instala.

Parece que el modo de instalación y la consola pelada por default del server core 2008 es bastante áspera para la configuración inicial, por lo que me figuré que todo iba seguro por un tutorial rápido de Technet para ver qué comandos correr para configurar el servidor desde la consola cmd (por ejemplo, para darle una ip estática a la placa de red, netsh y argumentos; pero no se olviden de habilitar antes el firewall). La solución fue utilizar unos scripts .vbs con GUI modo texto (esas que se arman con un menú que sale de un while en loop infinito y hay que darle opciones numéricas para que ingrese en cada opción de la GUI), muy buenos, y que configuraron el server core en un par de minutos con 0 (cero) overhead de manejo profundo de comandos Win 08 Server.

Luego de correr los scripts, agregamos el Rol hypervisor al Core y Windows se descargó un paquete de un server oficial (la ip/host.dominio la manejó internamente, no hubo que cargar ninguna información), lo instaló y ya quedó el núcleo operativo principal del Windows Server 2008 Core + Hyper-V listo para ser accedido vía msc desde otra PC.

La GUI del hypervisor, de la que no recuerdo el nombre (ver en google "technet hyper-v gui tools"), es otra herramienta de descarga freeware desde algun reducto de microsoft.com y dominios amigos. Para funcionar requiere Vista o Seven en adelante (no XP), y por lo que pudimos ver en una demo rápida de una GUI ya instalada es bastante poderosa, es un rich-client con opciones un poco más granulares y detalladas que la GUI de administración de Vmware ESXi.

Hasta aquí todo perfecto, el problema fue que no teníamos en nuestro equipo cliente de administración ninguna dependencia de las que necesita la GUI de administración de Hyper-V, así que en un tun-tun, ida y vuelta, estuvimos bajando paquetes (.exe), de instalación de varias utilidades "base" (son dependencias, como en los rpm/deb de Linux), para esta GUI, yo tenía que irme y pude ver antes de salir del "laboratorio" que nuestro win admin iniciaba una descarga de 200.x MB con tiempo de download estimado en 40 min. y ahí me fui.

La conclusión parcial hasta ahora es: Hyper-V es poderoso, la GUI es excelente, los downsides de instalación son esquivables fácilmente (gracias a scripts como en Linux/*nix), pero parece que a Microsoft le falta mirar un poco a Vmware en cuanto a la instalación de la GUI administrativa.

En hypervisores ESX (y ESXi), que uso y tengo implementados en producción hace un par de años, luego de una instalación de 5-10 minutos, totalmente automática, el server hypervisor queda listo para funcionar. Para administrarlo, tenemos que ir a una página web (el instalador configura automáticamente un webserver), y descargar un cierto "setup.exe", compatible con plataformas win desde XP "1", pasando por service packs, hasta el último Seven; luego de un clickeo repetitivo estilo siguiente-siguiente, ejecutamos el ícono en el escritorio y llegamos al login del hypervisor. Eso es todo, nada adicional. Tiempo estimado de realización del procedimiento: 5 minutos (tardando más en descargar el .exe, que en instalarlo y llegar al login del ESX).

Por ahora me queda la sensación de que Hyper-V va a andar muy bien, aunque tiene un par de bordes sin pulir por ahí, aunque Technet puede ayudar muchísimo a suavizar el impacto de estos detalles sin afinar. Continuó luego con más info sobre estos temas.