Testeo rápido de monitoreo opensource, update de capabilities al 2013

Fue una semana movida hasta ahora, estuve re-analizando el status de diferentes soluciones de monitoreo basado en soft opensource, y desde el lunes estuve deployando Nagios, Icinga, Ganglia, Cacti, OpenNMS y Zabbix, y estoy instalando Sensu ahora mismo.

Las viejas quejas de todos los que usamos soft de monitoreo desde hace años se hacen muy evidentes al trabajar con todo ese software. 

https://speakerdeck.com/garethr/monitoring-sucks

https://github.com/monitoringsucks

https://github.com/monitoringsucks/blog-posts

Básicamente OpenNMS es lo que mejor funcionó out-of-the-box, llevando solamente un par de horas la primer instalación+configuración completa (la 1ra. fue la de prueba también), y luego con un par de clicks, un auto-discovery barrió muy bien un rango detectando los dispositivos de mi red prueba. Configurar thresholds y la mensajería fue un poco más trabajoso, otra hora de trabajo, leyendo un poco una documentación bastante confusa y más confusos mails de pedidos de ayuda de usuarios y respuestas vagas. Claro, la solución era bastante simple e intuitiva...luego de haberla hecho funcionar la primera vez. Básicamente funciona bastante bien, pero es un poco inestable en el sentido de que deployar plugins y adicionales rápido - vía apt por ejemplo - no va a terminar siempre en un OpenNMS completamente estable, y se puede llegar a tener un servicio funcionando perfectamente durante horas luego de instalar plugins, y luego al primer reinicio del sistema, algo triggerea una falla en el arranque, y los mensajes de error son básicamente el volcado del output de la Java VM, y pocas veces contienen información útil para hacer la recuperación (el "profile" de respuesta de los foros/listas apunta mucho a que los users avanzados de OpenNMS están muy familiarizados con identificar "partes" de la configuración del soft a modificar/arreglar mirando directamente el volcado de la JVM, más que a buscar/encontrar esa información en alguna documentación). 

Por ejemplo, al instalar el plugin de monitoreo de DHCP, configurarlo, y luego desinstalarlo, dejó al software incapaz de arrancar por la falta de los binarios para arrancar el servicio, en este caso fue con suerte y el mensaje de error indicaba claramente que el fallo se debía a que no podía arrancar el servicio de monitoreo de DHCP, y la solución era simplemente volver a comentar el servicio en el file de configuración correspondiente (y así desactivar el intento de arrancarlo al inicio de OpenNMS).

Cacti fue muy fácil de instalar, el uso de Cacti es tan sencillo que casi nadie se preocupó por crear tutoriales de cómo agregar un dispositivo y llegar a generar (y ordenar), las gráficas; pero.."sencillo" no implica que sea totalmente intuitivo, y estuve una buena media hora jugando con la GUI hasta entender el workflow para agregar dispositivos y generar la información gráfica, motivo base para deployar Cacti (de todos modos, al parecer, OpenNMS está generando "exactamente" la misma información, pero claro, hay que navegar varios menúes hasta encontrarla, en Cacti se la tiene a la vista luego del login directamente).

Ganglia es desde siempre mi primer opción para levantar información de performance y uso de servers, principalmente porque se instala muy rápido, no requiere más que instalar el soft servidor, el soft cliente, y "engancharlos" mediante configuración (hay que decirle al soft cliente, al agente ganglia en el server a monitorear, cual es su - o sus - server a aceptar en comunicaciones). Luego de instalar Ganglia y dejarlo tomando información, me puse a revisar la demás opciones y a medio camino de estar bastante decidido a implementar OpenNMS y Cacti, Ganglia ya tenía perfiles gráficos armados de mis sistemas de testing.

A Zabbix lo instalé en minutos (y un par de agentes también), y la GUI si bien es muy atractiva, no es tan intuitiva como la de OpenNMS (que no es demasiado intuitiva tampoco), de todos modos ubiqué la capability de auto-discovery y triggereé un rápido discovery, que no llegó a captar ni un solo dispositivo en el mismo rango de red que había cargado dos horas antes en OpenNMS (y donde este último soft detectó perfectamente mis servers y dispositivos de prueba, datos snmp incluídos). Así que fui de la GUI a la documentación sin encontrar mayor explicación del procedimiento de agregado - "intuitivo" - de dispositivos, de ahí fui buscar en foros y listas de correo, sin encontrar nada de vuelta, supongo que es algo tan fácil que nadie se molestó en escribir un paso-a-paso, así que dejé Zabbix funcionando y sin configurar por ahora (hasta encontrar cómo agregar dispositivos). Igualmente, a cada golpe de Google no dejo de encontrar las recomendaciones de que Zabbix es "muy fácil", supongo que se refieren a la instalación, pero tengo que dedicarle más de los 20 minutos que le dediqué para poder concluir algo sobre el software (y poder cargar al menos un par de dispositivos de prueba). Si llega a funcionar, podría tener un poco más de utilidad que OpenNMS inclusive.

Nagios (e Icinga, en mi primer contacto con el soft, utilicé mi expertise en Nagios y lo pude configurar/administrar sin issue alguno, así que la portabilidad de skills la puedo confirmar) es lo que dejé para probar al final, es una tentación el querer a producción el soft más fácil de configurar y más rápido de deployar, ello no siempre significa que el software sea razonablemente fácil de administrar en el día a día (bah, en el caso de Nagios ES fácil de administrar), y/o que escale muy bien siquiera a mediano plazo. 

Nagios no escala nada bien en ambientes dinámicos, donde los servers suben y bajan de producción constantemente, y la medida básica de esto es implementar nagios para monitorear ambientes en clouds, sin embargo, si implementas Nagios en ambientes virtualizados, rápidamente verás como solo tus servers en producción y estables son permanentemente monitoreados, mientras que los demás servers que son arrancados y apagados dinámicamente, inclusive aunque estén en producción, lentamente van quedando atrás mientras las configuraciones de Nagios solo se dedican a controlar los servers que están funcionando continuamente, sin downtimes dinámicos.

Aparte está la tentación de integrar Nagios+Cacti, RRDD+Nagios, Nagios+lo que sea, una solución que rápidamente va a dejar de reflejar correctamente el verdadero perfil de performance total de ambientes virtualizados, claro, a menos que elijas manejar la arquitectura de modo que tus servers "fijos" en producción están siempre funcionando en determinados hipervisores y los demás, en producción pero dinámicamente arrancados/apagados y los de testing (que se crean y borran regularmente), quedan limitados a otros hipervisores. 

Mmm, hay un problema en que justamente, la posibilidad de utilizar las capacidades ociosas en los hipervisores es la razón para virtualizar en principio, así que "limitar" el foco de la infraestructura virtualizada porque un(1) software no tiene capabilities para "seguir" el dinamismo de la infra virtual es quitarle capabilities en exceso a la solución de virtualización. Consideren por ejemplo que esa limitación se potencia radicalmente cuando los servers corren en infras virtualizadas con configuraciones complejas (las que definen jerarquías para el apagado dinámico de VMs en hipervisores bajo determinados perfiles de performance, por ejemplo).

Claro, Nagios puede ser "adaptado" a escenarios dinámicos, pero esa misma configuración va a ser estática (básicamente se podría "jugar" con schedulear downtimes programados que coincidan con los downtimes estimables que van a tomar las VMs cuando la infra virtualizada apague los servers), con el resultado de que por un lado configuramos la infra virtual para que se adapte automáticamente y por el otro lado tenemos que lidiar con (re)adaptar manual/continuamente la configuración del software de monitoreo para los servers.

Casi nada de estas conclusiones es nuevo (vean los links de monitoring-sucks), ni tampoco utilizar software comercial es la solución (tiene las mismas limitaciones para adaptarse a infraestructuras dinámicas en general), y no es que no suceda lo mismo con el resto del software que probé: OpenNMS, Cacti, Ganglia, etc.

Me falta testear Groundwork y HypericHQ (similar a Zabbix, comerciales, pero opensource o freeware al menos), y ver que tal se comportan. Me resulta curioso como las páginas de todos los software de monitoreo que se venden dicen que son los mejores o algo similar :-D > "Monitoring The World's Largest Web Applications"

http://www.gwos.com/

http://www.hyperic.com/

Al rearrancar la semana voy a testear Sensu y ver cual es su perfil de adaptación a escenarios dinámicos, ya que hay bastante material en la red prometiendo mucho a este respecto:

http://www.slideshare.net/jeremy_carroll/sensu-14485155

https://github.com/sensu/sensu/wiki/Install-Guide

Planeo escribir algo (cuando tenga la experiencia práctica), de Sensu - en español - para que al menos alguien que googlee desde LATAM/ES "sensu" a corto plazo al menos encuentre algo de material en español y de 2013 entre los primeros hits.

Links:

http://www.opennms.org/

http://www.cacti.net/

http://ganglia.sourceforge.net/

http://www.zabbix.com/

http://www.nagios.org/

https://www.icinga.org/

Comprar más servidores físicos o rentar en la nube?

La oferta de servicios de nube pública se sigue expandiendo, por otra parte, ayuda a mantener el status quo a favor de los servers físicos locales (cajita), el ratio de fallos de los servicios de nube. Los proveedores locales de servicio de nube (de algún datacenter que ofrece servicios de nube en Arg. por ej.) también ayudan no publicitando abiertamente el nivel de disponibilidad de los servicios de nube, al menos algo como esto > 

http://status.aws.amazon.com/
http://www.google.com/appsstatus
https://status.rackspace.com/

Es dudoso que un área de sistemas en Argentina contrate servidores en la nube para servicios críticos (que es lo que más se corre en servers locales en la mayoría de las organizaciones/empresas en Arg.), si es que no dispone de mínima información pública y moderadamente certera acerca del historial de disponibilidad y acerca de los motivos de las fallas anteriores, incluyendo detalles técnicos importantes de análisis publicados por el mismo proveedor, similar a esto:

http://aws.amazon.com/es/message/65648/
https://aws.amazon.com/es/message/680342/
http://blog.rightscale.com/2011/04/25/amazon-ec2-outage-summary-and-lessons-learned/

* Los SLA para servicios de nube son, como decirlo, muy relativos. ¿Se condice con la realidad tener un SLA firmado por el proveedor y que el servicio luego falle? ¿Aceptará el proveedor sanciones / multas por caída de servicio? Si no es económica la sanción por caídas de servicio (por cada hora de falta de servicio, se entrega automáticamente 4 horas sin costo), ¿Cómo puede exigirse el SLA? ¿Judicializando? ¿Vale la pena ir a una instancia judicial por micro-outages constantes de pocas horas-días, etc.?

De todos modos, alguien siempre tiene que ser el primero, y muchos proveedores se están esforzando en crear servicios baratos para pelear por el lado del costo: TCO de tener servers locales vs. TCO al tener servers en la nube.

Al menos algun par de servers no críticos se puede seleccionar y "enviar" a la nube para ir probando - y registrando la experiencia en logs, datos de tráfico, gráficas descriptivas, etc. - la fiabilidad del servicio (durante un par de años). Supongo que ya debe haber bastantes servers no críticos de organizaciones en Argentina subidos a nubes públicas para hacer esto justamente.

Las soluciones IT completas y un ejemplo con infraestructura virtual vSphere

En este artículo cuento cómo en gral. las soluciones "completas" no lo son, y hay que completarlas para que realmente cumplan con el objetivo para el cual fueron pensadas. Hay además comentarios sobre los ámbitos de responsabilidad de provedores IT terceros y la relación de los proveedores IT internos de una organización con su cliente principal (la organización).


Soluciones buenas, pero parciales
Es común ver en infraestructura que al comprar una solución IT, la empresa acuerda el trabajo a realizar, viene a la empresa/organización, realiza el trabajo y luego se va. Dejando garantías vigentes, por un tiempo, bajo ciertas condiciones, etc.

Por ejemplo, la instalación de una infraestructura vSphere: se instalan los hipervisores, se monta el server vCenter, se agrega los hipervisores al vCenter, se deploya algunas máquinas virtuales - probablemente no?, y listo (hasta ahí es el trabajo acordado con el proveedor de servicios IT en este ejemplo). El cliente luego toma la posta desde ahí, administrando todo la infraestructura - virtual ahora. Instalando, migrando sistemas operativos de físico a virtual, etc. etc.

El precio de un trabajo puntual de infraestructura y sus límites son indispensables, sino la empresa proveedora va a hacerse cargo hasta el infinito de cualquier cuestión relacionada con lo que instaló/configuró inicialmente.


Soluciones IT completas
Ahora, el caso de las áreas de sistemas internas en la organización es bien diferente. Cada área IT interna en una organización tiene la obligación de sostener la continuidad de la infraestructura en el tiempo, a largo plazo. 

Lo que es muy diferente de la obligación de proveedor IT comercial, sin embargo es común encontrar el caso de que las soluciones IT internas en una organización se implementan "por única vez", y luego se las abandona "como están" y sin tomar en cuenta la prerrogativa de mantenimiento y mejora contínua (que es en gral. un requerimiento del puesto para los empleados del área IT interna por cierto).

Siguiendo el ejemplo de la infraestructura vSphere, algunos pasos posteriores a la "simple" instalación y configuración de una infra virtual vSphere podrían ser (más o menos en orden de importancia estratégica-técnica): 

1) Implementar backup automatizado de la configuración del vCenter (y su DB de backend)

2) Implementar backup automatizado de la configuración de los ESXi,

3) Deployar (comprar en gral.) una solución de backup virtual (Veem, etc.), para las máquinas virtuales en sí,

4) Implementar chequeo de configuraciones automatizado (extraer toda la configuración de vSphere, volcar a un GIT o similar, y luego ir haciendolo regularmente, para tener un registro centralizado exacto de cada cambio en la configuración), AKA "configuration management".

5) Implementar monitoreo de la infraestructura virtual (hay varias maneras)

6) Deployar un vSphere Update Manager (para mantener todos los hipervisores actualizados/parcheados), 

7) Implementar alta disponibilidad para vCenter (o sea, montar otro server vCenter, de alguna de las varias maneras posibles),

8) Implementar automatización en el mantenimiento necesario para vCenter (tip: la DB de backend necesita atención de a ratos).

9) Cómo proceder, y qué hacer exactamente desde lo técnico para recuperar la caída/cuelgue/fuera de servicio de cualquier componente de la infraestructura virtual vSphere (incluye tener instaladas y configuradas las herramientas necesarias, los planes, y que los que vayan a haber la recuperación, hayan realizado prácticas y pruebas de campo para saber que toda las políticas/procedimientos/herramientas funcionan realmente como deberían).

Etc.


Si se fijan, extrapolando la idea general del ejemplo, cualquier infraestructura necesita básicamente (además de la instalación, configuración y puesta en producción inicial): 

- Backup, 
- Configuration Management, 
- Monitoreo y Optimización/Mantenimiento/Mejora Contínua.
- Añadir redundancia/resiliencia adicional (como parte de la mejora contínua)
- Plan de acción de recuperación de desastres.

Sin todos esos detalles (y varios más no mencionados), la solución puede "estrellarse" con mucha facilidad y dejar de funcionar apropiadamente, y con algo de mala suerte además, inesperadamente (por ejemplo: madrugada de año nuevo, 3 de la mañana, llamada del dueño de la empresa al personal IT, cayendo a las 3.10 cuando el personal que usa el sistema le acaba de avisar de que no anda. "Casos de uso": clínica de guardia, farmacia de guardia, empresa de seguridad, polícia, etc.).


Completar la solución
Si una solución integral no incluye lo anterior, habría que ir preguntando al proveedor cuanto saldría implementar backup, config management, monitoreo, y disaster recovery...o pensar cómo se hace internamente para completar la solución de infraestructura. Normalmente esas tareas tercerizadas implica un precio mayor que la instalación/configuración inicial, ese precio más alto es realmente una mejor aproximación al TCO real de la solución.

TCO:
http://es.wikipedia.org/wiki/Coste_total_de_propiedad

* Esto es cuestión de opiniones, pero para completar más el TCO de la solución, se podría agregar la previsión/estimación de costos futuros del lifecycle management, por ejemplo, previendo una migración de plataforma. 

Siguiendo el ejemplo: preveer un posible/eventual path de migración de Vmware vSphere 5.1 (+ ESXi) hacia Microsoft Hyper-V 2012 + System Center 2012 Virtual Machine Manager .

Por ejemplo: tener que comprar una SAN "ahora":
- aumenta el TCO de la solución vSphere, pero 
- baja el TCO de la - posible a futuro - solución Hiper-V 2012, pero, 
- en gral. hace disminuir el TCO de la solución "Infraestructura Virtual" 
(que es lo que le interesa a la organización en realidad), y por lo tanto genera un "path de migración" aceptable, y se concluye que comprar la SAN "estaría bueno" :-)


Ambitos y tiempos limitados
Las áreas IT internas tienen un ámbito de injerencia y obligaciones para con la infraestructura IT por lejos mucho mayor que casi cualquier solución "llave en mano" que pueda proveer un tercero, ya que inclusive con el mejor presupuesto disponible, el ámbito de injerencia de un proveedor IT tercerizado siempre - pero siempre - está limitado a determinadas tareas y obligaciones, y a un rango de tiempo - contratado - durante el cual le va a responder al cliente. Y luego del cual, ya no va a tener obligación de responderle al cliente. 

El área IT interna por otra parte no está limitada en absoluto de sus obligaciones para con la organización, a la que debe responder por obligación organizacional (o sea, independientemente de quién/es estén integrando esa área como empleados/responsables), de modo contínuo, y tiene la responsabilidad de completar y subsanar cualquier limitación que exista en la infraestructura. 

Siguiendo el ejemplo: el que en la solucion "llave en mano" no haya previsto un mecanismo de backup para los hipervisores ESXi. Si no lo hace el proveedor, es obligación del área IT interna completar la solución.


La obligación contractual del proveedor IT, siempre tiene un límite práctico: el tiempo máximo contratado y qué tanto trabajo se puede hacer durante ese tiempo. Aunque y a pesar de que se suele contratar: 
- "soluciones completas", 
- "soluciones llave en mano", 
- "soluciones integrales", 

y demás buena jerga de vendedor IT, por más que esté "prometido" las soluciones provistas por un tercero nunca van a poder ser integralmente completas, sino solamente van a estar de acuerdo a lo contratado (una lista de tareas que figura en el contrato), cualquier tarea adicional, paga o no, es a discreción y buena voluntad del tercero proveedor. 

...A menos que directamente se los contrate permanentemente para hacer el trabajo del área interna IT...ooops, pero ese contrato también tiene una duración máxima, así que no, no es posible sostener la tercerización ilimitada, siempre va a haber que pagar más o contratar servicios adicionales para poder tener una tercerización ilimitada (por eso es tan buen negocio por cierto :-).


Conclusión
Es bastante seguro decir, falta de presupuestos infinitos mediante, que eventualmente toda organización/empresa se va a volver a hacer cargo de sus propias necesidades de informatización, y lo mejor es que sea lo antes posible y con el mejor grado de previsión y responsabilidad.

Firewalling y ciberguerra

Firewalling y ciberguerra

Guerra informática (cyberwar)
http://es.wikipedia.org/wiki/Guerra_inform%C3%A1tica

Hace un tiempo, varios países grandes están construyendo grandes infraestructuras de firewall alrededor de sus redes principales, de modo que si fuera necesario, podrían clausurar el acceso desde Internet hacia cualquier host dentro de sus redes nacionales.

Muchos autores de artículos y blogs expresan constantemente un único punto de vista no técnico respecto de este tema, cuyo foco es la masiva capacidad de auditoría y censura de las comunicaciones que se obtiene al armar esas infraestructuras.

Por ejemplo:
"China levanta su ‘Gran Cortafuegos’ para proteger al régimen de la Red"
http://internacional.elpais.com/internacional/2012/10/26/actualidad/1351278234_650074.html

Aparte de lo anterior (y su nivel de veracidad, cualquiera sea), hay otro punto de vista, también obvio pero con un foco técnico: la "cyberguerra".

Los ataques a infraestructuras informáticas auspiciados por países están en auge desde hace bastantes años, simplemente que luego de los incidentes de 2007 y 2008:

http://en.wikipedia.org/wiki/2007_cyberattacks_on_Estonia
http://en.wikipedia.org/wiki/Cyberattacks_during_the_2008_South_Ossetia_war


http://www.telegraph.co.uk/news/worldnews/europe/georgia/2539157/Georgia-Russia-conducting-cyber-war.html
http://bits.blogs.nytimes.com/2008/08/11/georgia-takes-a-beating-in-the-cyberwar-with-russia/

se hizo evidente para la opinión pública y al poco tiempo se hicieron públicos diversos esfuerzos de orden nacional en muchos países para construir infraestructuras de firewalling alrededor de sus redes y con motivos de peso, como se puede advertir en la escalada de incidentes hasta el presente:

http://en.wikipedia.org/wiki/Cyberwarfare#Incidents

Los ataques a infraestructuras informáticas son frecuentes y habituales, ya sea en operaciones directas, solo involucrando cyberataques o como apoyo para otras acciones militares y/o de inteligencia.

Los ataques "indirectos" también son otra gran motivación para el montaje de infraestructuras de firewalling de borde alrededor de redes nacionales:

http://en.wikipedia.org/wiki/Stuxnet
http://en.wikipedia.org/wiki/Flame_(malware)
http://en.wikipedia.org/wiki/Duqu


Plazos
Es importante considerar también que la mayoría de los riesgos residen en el largo plazo. Los ataques a infraestructuras informáticas que pudieron ser rastreados hasta naciones estado particulares (al menos con un alto grado de fiabilidad), por ejemplo:

http://en.wikipedia.org/wiki/Flame_(malware)#Origin

tienen la particularidad de haber sido planificados, deployados sus recursos y efectivamente realizados a lo largo de varios años, desde el momento de la decisión, hasta la disponibilidad de la decisión de "atacar o no atacar":

"Several other details have been uncovered which suggest there was possibly at least one further spyware module based on the same platform in 2007-2008, and several other programs whose functionality was unclear between 2008 and 2010."

---

"Varios otros detalles fueron descubiertos los cuales sugieren que había posiblemente al menos un futuro módulo spyware  basado en la misma plataforma en 2007-2008, y varios otros programas cuya funcionalidad no estaba clara entre 2008 y 2010"

Fuente:
http://www.securelist.com/en/analysis/204792208/Stuxnet_Duqu_The_Evolution_of_Drivers


Hardware de Networking
El hardware de networking es un punto clave a analizar en este tema. 

Si bien hay varios modos de filtrar el tráfico de un equipo de networking y lograr determinar si incluye algun tipo de backdoor (simples puertos abiertos, alguna irregularidad en el manejo de algun protocolo de comunicaciones salientes que pudiera "pinpointear" OTRO protocolo de comunicaciones subyacente embebido, etc.); está el problema de que es muy difícil detectar si hay algun mecanismo subyacente de comunicaciones subrepticias si es que este está inserto directamente en el hardware mismo.

Justamente es la razón explicada para banear productos Huawei y ZTE en EE.UU.

"The task of finding and eliminating every significant vulnerability from a complex product is monumental. If we also consider flaws intentionally inserted by a determined and clever insider, the task becomes virtually impossible."

-------------

"La tarea de encontrar y eliminar cada vulnerabilidad significativa de un producto complejo es monumental. Si también consideramos las fallas intencionales insertadas por un infiltrado determinado y astuto, la tarea se vuelve virtualmente imposible."


Fuente:
http://intelligence.house.gov/sites/intelligence.house.gov/files/documents/Huawei-ZTE%20Investigative%20Report%20(FINAL).pdf


Un artículo relacionado (más legible) aquí:
"Congress accuses Chinese tech giants of un-American activities
Huawei and ZTE "cannot be trusted," says House Intelligence Committee."
http://arstechnica.com/tech-policy/2012/10/congress-accuses-chinese-tech-giants-of-un-american-activities/


Así, el incidente en progreso en relación a Huawei y Cisco está fundado en esa idea:

"Huawei ofrece acceso al código fuente de sus equipos en Australia"
http://www.europapress.es/portaltic/empresas/noticia-huawei-ofrece-acceso-codigo-fuente-equipos-australia-20121024115252.html

"Chinese Huawei, ZTE face new hurdles in U.S. market"
http://english.sina.com/business/2012/1008/514156.html

Claro, que no se puede evitar considerar el punto de vista económico donde otras acciones parecen apuntar más bien a una guerra económica encubierta como "preocupaciones de seguridad".

"China Unicom replaces Cisco devices over security concerns"
http://www.morningwhistle.com/html/2012/Company_Industry_1026/214830.html


Sin embargo, hay bastantes fundamentos lógicos en la idea detrás de la proscripción de compra de equipamiento de networking Huawei y ZTE en EE.UU:

http://www.heritage.org/research/reports/2012/10/china-cyber-threat-huawei-and-american-policy-toward-chinese-companies


Conclusiones
Como se puede ver la construcción de infraestructuras masivas periféricas de firewalling de alta resiliencia a ataques externos es una - relativamente - nueva necesidad para asegurar el correcto funcionamiento de los servicios informáticos a nivel nacional, más aún dada la posibilidad de atacantes hostiles financiados - sino plenos miembros de sus fuerzas de seguridad/militares - por un país, ya sean ataques subrepticios o directos.

La naturaleza típica de "caja negra" del equipamiento de networking y firewalling existente vuelve igualmente dicha seguridad parcialmente relativa, ya que dicho equipamiento podría contener insertas diferentes mecanismos de backdooring:

http://en.wikipedia.org/wiki/Backdoor_(computing)

y ello especialmente si hablamos de espionaje informático y operaciones subrepticias de infiltración (de equipamiento con backdoors) y sabotaje (en base a criterios preventivos: "si fuera necesario", "cuando sea necesario", etc.)  a largo plazo auspiciadas por naciones estado.

El - de vuelta, relativamente - nuevo escenario se configura en una escalada de riesgo de ataques informáticos, mucho mayor que cualquier amenaza preexistente, especialmente de particulares y organizaciones criminales, de una escala muy significativamente menor en relación con hostiles vinculados y respaldados por naciones estado.

Arquitectura opensource: linux + DBs opensource + apps de negocios

Tus apps empresariales deberían correr sobre Linux

La cuestión es simple: las infraestructuras crecen, más pronto de lo que piensas te verás en la necesidad de implementar 30 o 40 servidores de tu aplicación empresarial, aunque hoy estés corriendo solo 2 servers.

Pronto la verás correr en entornos virtualizados, clusterizada localmente en el hipervisor, luego replicada a otro/s hipervisores (típicamente son dos réplicas adicionales: una en un hipervisor local, diferente máquina/server físico, pero mismo datacenter, y otra replica, corriendo en un hipervisor - o no -en un datacenter remoto para disaster recovery), sea que repliques usando el soft de clustering (vía OS clustering o app clustering), o herramientas de replicación de la infraestructura de virtualización.

Es decir, aunque hoy compremos 5 licencias de la aplicación, dentro de poco tal vez estemos comprando 30, si a ese costo le tienes que sumar el costo de las licencias para el sistema operativo base, ello suele llevar a una situación típica: no se implementa esquemas de replicación y otras infraestructuras de soporte de continuidad de negocios solo porque el costo de la licencia en sistemas operativos lo vuelve imposible.

La solución en principio es simple: que tu app de negocios pueda correr en Linux.


Tus apps deberían poder usar bases de datos opensource como backend

La cuestión es simple: muchas aplicaciones de negocios se respaldan en las fuertes capacidades "extra" brindan las bases de datos propietarias: diferentes y amplias posibilidades de replicación, mejoras importantes en la performance usando capacidades disponibles solo en esas DB propietarias, etc. Dichos "extras" son reales y muchos solo están disponibles al momento pagando licencias de DBs propietarias.

El problema que vimos con el costo de licencias de sistemas operativos aparece de vuelta aquí, en este caso el costo de tener hoy - licencias para - 2 servers de base de datos, es X, si mañana requirieramos correr, digamos, 20 servers de DB, el costo sería Y (mucho más alto).

Si queremos disponer de la posibilidad de usar la facilidad instalar cuantos servers Linux (con nuestra app de negocios corriendo en él), querramos, necesitamos que la DB que usa la app de backend sea también opensource.

La opción por default para aplicaciones de negocios es Postgresql, pero no hay que olvidar a MySql (y las varias alternativas libres de MySql). Ambas opciones ofrecen hoy capacidades de mejora de performance y replicamiento de nivel industrial, (con pocas excepciones), normalmente dentro del rango de los requerimientos típicos para DBs de backend para apps de negocios y/o de misión crítica.

Hoy en día muchas apps de negocios preveen esta capacidad y no solamente son compatibles con DBs propietarias, sino que también se las puede implementar sobre Postgresql (muy habitual), o MySql (no tan habitual).


De primera mano conozco muchos casos de éxito de este esquema de arquitectura básica para desplegar aplicaciones de negocios y de misión critica en organizaciones, con el consiguiente logro de otros beneficios derivados de correr software opensource.

Devops para gestionar administradores de sistemas en infraestructuras en crecimiento

Autor: Dardo Valdez (ar.linkedin.com/in/dardovaldez)
Versión: 02 de Junio de 2012
Licencia: derechos reservados




Presentación: Considero este texto un estudio/idea en evolución, espero ir modificándolo y corrigiendolo según sea necesario a medida que progreso en la investigación.

Temáticas tratadas: expansión de número de servers en organizaciones, infraestructuras ágiles, virtualización, planificación de personal de administración de sistemas, beneficios del uso de configuration management soft, cadena de herramientas.

El problema
Cuando una infraestructura informática se pone en producción en una organización, hay muchas chances de que solo sea un punto de inicio desde el cual va a ir creciendo junto con la organización.

Acortando explicaciones para sysadmins: vamos a tener cada vez más servidores que atender, más aún, el ciclo de mantenimiento de los viejos servers va a entrometerse cada vez más en las tareas diarias.

Además, en las infraestructuras típicas, la implementación inicial no justifica una inversión masiva en nada, es decir, grandes plataformas de infraestructura integrada como Oracle Exadata o Cisco UCS siemplemente no son necesarias en ese punto de la vida de la infraestructura (al menos aún). Por ende la fragmentación de plataformas de hardware y software suele ser fuerte, lo que deriva en necesitar más horas/hombre de trabajo de administración de sistemas.

Desde el punto de vista del software, dados los típicos casos de uso en organizaciones es casi imposible disponer de plataformas de software totalmente homogéneas, probablemente vamos a estar corriendo alguna combinación de Unix/Linux y Windows Server.

Las plataformas de hardware homogéneas sí son posibles de implementar (blade servers, por ejemplo), pero no hay que dejarse llevar por las promesas de que eso "lleve", "tienda" a homogeneizar el software (vía licencias incluídas con la compra de hardware por ejemplo), ya que el uso de soft se basa en requerimientos y necesidades de la organización, no en el hardware en el que corre.


Planes: el ejemplo de un Poder Judicial
Volviendo a los servers: a poco de iniciado el montaje de una nueva infraestructura vamos a empezar a poner más servers en producción, los que hay que administrar, ello plantea la necesidad de planificar la gestión del personal que lo hará: los administradores de sistemas (sysadmins).

Un Poder Judicial como ejemplo de organizaciones de crecimiento contínuo
Las organizaciones provinciales y nacionales del estado que cubren las necesidades de provisión de servicio del estado para con la población son un ejemplo claro y general donde se va a encontrar la necesidad de realizar una óptima gestión del personal destinado a administrar sistemas.

Los servicios informáticos de un Poder Judicial (provincial, nacional), son un ejemplo puntual. Bien, sigamos con el ejemplo de las necesidades de servicios de un Poder Judicial provincial típico - y debo mencionar, tengo varios años de experiencia específica en este tema (ar.linkedin.com/in/dardovaldez):

A medida que crece la población, se debe ir incorporando más empleados al Poder Judicial, para poder mantener su capacidad de provisión de servicios para con su creciente número de clientes debido a que la población crece y el número de horas/hombre que provee el servicio de justicia debe ser el necesario para esa población incrementada.

Es bastante remoto que la cantidad de horas hombre totales disponibles en casi cualquier dependencia del estado tenga horas/hombre libres disponibles, tal que le permita no contratar más empleados por varios años, de hecho, la mayoría de las dependencias del estado - entre ellas el Poder Judicial - contratan personal casi constantemente.

El problema [horas/hombre-capacidad de servicio a la población] de un Poder Judicial típico, se está resolviendo hoy en Argentina mediante la incorporación masiva de software al trabajo interno del Poder Judicial. Ello multiplica la capacidad productiva de la fuerza laboral, y por ende crea un escenario donde:

• Se introduce herramientas informáticas - software - en los procesos internos, modificandolos, en gral. haciendo que tareas que llevaban horas - literalmente - se realicen en minutos, produciendo un impacto fuerte en la productividad organizacional.
•  Se puede contratar menos gente anualmente, disminuyendo el costo de personal
•  Se implementa una plataforma fuertemente documentada formal e informalmente que permite un aprendizaje bastante más rápido para los nuevos empleados. 
•  Adicionalmente - mientras la capacidad productiva "extra" - respecto a antes de utilizar software - recien adquirida no esté completamente utilizada - los servicios de justicia se vuelven más rápidos.

Planificación reactiva
Volvemos ahora al escenario de gestión de personal de administración de sistemas.

El escenario es una organización en crecimiento constante, que añade servidores y software casi constantemente, lo que conlleva la necesidad de tener personal de administración de sistemas adecuado.

Si vemos el tema desde la óptima de la planificación reactiva - y con un ejemplo práctico - se entiende mejor el dilema a resolver, el ejemplo es:

"El primer año contrato un sysadmin Jr., luego de un par de años contrato dos sysadmins SSr., al cabo de otro año más, se "prevee" la necesidad y contrato un sysadmin Sr."

En algun punto luego de arrancada la historia del ejemplo, nos damos cuenta que los sysadmins Jr. y SSr. no van lograrlo: luego del primer año la infraestructura ya creció al punto en que un SSr. apenas tiene skills para manejarla, y aunque nuestro Jr. original ya es SSr. en este punto, ya trabaja codo a codo junto a sus compañeros, mientras esperan el support de un nuevo sysadmin, Sr. en esta oportunidad.

Es decir, la complejidad creciente de la infraestructura va incrementando rápidamente algunos factores:

• El skillset necesario para administrarla (implica mayor costo en personal, sueldos a pagar más elevados)
• La cantidad de personas necesarias para el trabajo

Más problemas
Hay varios sucesos colaterales, uno importante es que al crecer la infraestructura y las horas de trabajo, si no se planificó bien desde management y si los administradores no lo propusieron (lo que es de esperar, ya que eran básicamente Juniors y Semiseniors en skillset), el nivel de automatización de la infraestructura va a ser muy bajo, las tareas van a ser excesivamente repetitivas e inapropiadas para una infraestructura grande. Las tareas de emergencia - inevitables - van a ser cada vez más numerosas y con mayores tiempos hasta lograr soluciones.

Todo lo anterior acarrea costos no económicos, un stress muy alto para la estabilidad de los administradores en sus puestos y para los mismos administradores (problemas de salud importantes por stress por ejemplo), que pueden empezar a buscar oportunidades en infraestructuras con menos stress y mejor diagnóstico a futuro (ya que si algo funciona mal en el presente y no hay una evolución en la infraestructura, va a funcionar peor en el futuro).


Conclusión
Una expansión gradual y esperable del parque de servidores en una infraestructura va absorbiendo la capacidad productiva de los sysadmins mucho más rápido de lo que se puede incorporar nuevos sysadmins. El skillset técnico requerido va subiendo constantemente y luego de cierto tiempo, ningun sysadmin que tenga un nivel de skillset por debajo de Senior va a ser viable para contratar. Otros problemas relacionados con el exceso de trabajo y el stress, pueden incrementar más aún varios costos en la infraestructura (personal fuera de oficina con frecuencia por problemas de salud, sueldos, tiempos perdidos por renuncias imprevistas).



La solución
El problema de arriba es el mismo que enfrentan muchas organizaciones, y la solución es simple, se hace lo mismo que se hizo en el ejemplo del Poder Judicial usando software para multiplicar la capacidad productiva por persona.

La solución es elevar el nivel automatización de la infraestructura: usar software automatizando tareas a gran escala, permitiendo así que pocos administradores de sistemas puedan manejar de centenares a miles de servidores con - relativamente - muy pocas horas de trabajo dedicadas.

Las bases prácticas de la solución son:

• Modernizar las herramientas de configuración en los datacenters (software de configuration management), y los procedimientos de automatización de operaciones (metodologías ágiles en Operations; filosofía Devops),
• Explotar a gran escala el uso de virtualización vía provisión IaaS (Infraestructura como Servicio), usando cloud services.
• Mejorar el monitoreo para que lleve a entender mejor cómo se comporta la infraestructura y permita maximizar el mejor uso de los recursos disponibles.

Cadena de herramientas
La idea de fondo hoy, es migrar a una "cadena de herramientas", siguiendo la noción de arquitecturas DevOps, adoptando herramientas pequeñas e interrelacionarlas para realizar funciones puntuales.

Una "cadena de herramientas" muy usada en plataformas Linux es:

• IaaS cloud provisioning: Openstack  
• Configuration Management: Puppet, Chef
• Monitoreo: Nagios (o derivados), 

* La versión comercial de Puppet permite gestionar configuration management en Windows.

Es fácil verlo mejor con un ejemplo práctico típico: los pasos necesarios para instalar un nuevo servidor. En este caso, vemos la secuencia de acciones para añadir un server (nodo) a la infraestructura de virtualización/cloud:

1. Se instala físicamente un servidor y se la registra.
2. Es arrancada por el técnico de campo
3. El server bootea vía red y el sistema operativo se instala automáticamente (vía PXE)
4. El sistema operativo se configura vía Puppet (en muy poco comandos y en forma remota)
5. El servidor se registra automáticamente en la nube Openstack
6. El servidor queda listo para aceptar máquinas virtuales

Una cadena de herramientas propia de la plataforma Windows
La automatización en plataformas Windows, en lo específico ofrece opciones nativas de la plataforma, en un ejemplo, una cadena de herramientas completa está disponible vía productos de Microsoft en este conjunto de herramientas:

• IaaS cloud provisioning: Openstack
• Configuration Management: System Center Configuration Manager (SCCM)
• OS Windows
• Monitoreo: System Center Operations Manager (SCOM)

Razones para utilizar Configuration Management
Algunas razones para usar software de Configuration Management son:

- Documentación: toda la información de cómo construir esos sistemas va a quedar finamente detallada en el software: Puppet, Chef, SCCM (Microsoft System Center Configuration Manager), etc.

- Infrastructure as Code: que por ejemplo, va a permitir..

• Hacer builds rápidos y replicados exactos de sistemas que ya tengas en producción. Algo útil si quieres montar una máquina virtual para testing (como instalar una app "rara" en versión demo, que no saben si se llevará muy bien con el consumo de recursos de una DB corriendo en el mismo server, etc.) 
• Montar y resolver dependencias de deployments: cuando tienes que configurar "algo", pero ese "algo" necesita de otros dos componentes (A y B), exactamente instalados en secuencia (primero A, luego B). Así evitarás repeticiones y algun sysadmin novato va poder hacerse cargo del build. 

- Training y recursos: al montar una herramienta de configuration management, se hace menos pronunciada la curva de entrenamiento de sysadmins nuevos. Se los puede destinar a aprender a manejar la herramienta en principio, cuando aprendan a hacer "recetas", inmediatamente van a acceder a entender cómo es la arquitectura global de la infraestructura.

Al usar herramientas estándares del mercado (Puppet, Chef, SCCM, etc.), es más probable encontrar sysadmins que ya estén entrenados en ellas, incluso tal vez con experiencia.

Un modo para evaluar la utilidad real de usar cloud services, los detalles

Todos los sistemas van a fallar catastróficamente en algun momento, sin embargo creo que es una cuestión de costo-beneficio.

Cuando una empresa chica - Instagram por ej. - decide ir por el hosting propio, normalmente no tiene inmediatamente cosas como:

• Su propio datacenter 
• Otro datacenter en una locación diferente, replicando la infraestructura física (que detallo abajo)
• Doble línea de aprovisionamiento de energía (una de una "zona" y otra de otra "zona", si cortan la luz en una, se contiene y se pasa a la otra línea, etc.)
• Una UPS que aguante 2 o más horas de corte de luz (suficiente tiempo para tomar medidas de contención - servicios disminuídos en la infra, etc. - y preparar DR - Disaster Recovery y/o evaluar MTTR (tiempo promedio hasta que todo vuelva a la normalidad)
• Un grupo electrógeno con buen tiempo disponible (en realidad, lo ideal es usar primero el grupo electrógeno y tener las UPS disponibles como última opción de provisión de energía)
• Buena provisión de aire acondicinado (incluyendo la potencia extra necesaria para el grupo electrógeno durante las horas del corte de luz)
•  Un server - el hard- en cold-standby (nuevos, montados y apagados), listos para reemplazar cualquiera en producción. En cantidad suficiente para cubrir el promedio de fallas de hardware de los fabricantes del hard (el promedio de la datasheet para vender y el promedio interno, obtenido de la experiencia inhouse),
• Lo mismo que lo anterior pero para hard de networking
• etc. 

En gral, cuando se compra un server propio y se lo hostea "por ahí", las medidas anteriores están todas dadas, aunque no se tiene exacta idea - típicamente - de qué hay de todo lo anterior (aunque hay buenos datacenters en AR para hostear servers propios si mal no recuerdo).

Una startup que recien arranca y planea - y desea - tener una expansión explosiva, suele arrancar con uno o dos servers alquilados, luego - inversión inicial mediante - compran un par de "físicos" y los hostean por ahí; ya llegado el momento del lanzamiento y cuando arranca el uso explosivo, toda la arquitectura tiene que estar armada para ir adaptandose transparemente a la nueva carga.

Lo más importante de usar servers en clouds pasa - imho - por no necesitar comprar 20 servers (+ el datacenter y/o alquiler de infra que los contiene), y poder alquilarlos en la cloud, luego, si ya no hace falta, pum!, se apagan los nodos, se pierde esa información y se vuelve a la base.

Supongo que como toda startup que va ganando pie (como Zynga por ejemplo), van a terminar migrando a una infra de hard propio, y la cloud de Amazon les sirvió - ya es efectivo eso - para dar el salto a la masividad con mínima inversión y apoyándose mayormente en el skillset del equipo de desarrollo + sysadmins + ideas de negocio.


Vi - ojos propios - muchas veces en el NEA que cuando se busca "hosting propio" y se compra un servidor - caro, de marca,  o no - casi todo lo anterior que mencioné (inclusive el tema del grupo electrógeno), se pasa olímpicamente por alto, y si hay cortes de luz de 4 horas - como sucede varias veces por verano en Ctes. - un sistema de misión crítica se tiene que apagar porque las UPS solamente soportan un máximo de dos horas (en realidad, para resguardar la integridad de los datos, esas dos horas quedan cortas, así que los admins apagan todo - ordenadamente - mucho antes de esas dos horas, previa llamada al jefe/dueño explicando qué en realidad no tienen dos horas).

Conclusión
El nivel de fiabilidad para el negocio en poner servers en Amazon es comparable al de tener los mejores ingenieros y técnicos trabajando con el máximo posible de recursos - hard, soft, skillsets, training especializado, expertise, etc. - para intentar mantener online todo el tiempo posible a un datacenter.

Más allá de los fallos que tuvo esa infra de cloud (y todas las clouds privadas tienen/tuvieron outages), la evaluación debería hacerse - imho - con el nivel y la frecuencia de fallos a nivel de pérdida de servers que encontramos en un datacenter - bien armado promedio.

Probablemente encontremos que la frecuencia de fallos en un datacenter promedio suele ser bastante más elevada que el del servicio de cloud privado promedio (Amazon, HP Cloud Services, RackSpace, MS Azure, etc.).

Cómo es la arquitectura de Instagram

Un ingeniero de Instagram, la empresa recientemente comprada por Facebook publicó en el blog -oficial- del team de ingeniería de Instagram los detalles de la arquitectura que sostiene Instagram.

Acá pueden leer el artículo completo
http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances-dozens-of

Me gusta leer estos textos para ir viendo qué se usa hoy en deployments grandes, cómo lo usan, qué cosas deberían funcionar y no lo hacen, qué otras cosas no están tan probadas pero funcionan muy bien, etc. Startups como Instagram hacen un uso extensivo de tecnología opensource - obviamente - para reducir costos al máximo, así que - en gral. - el profile de TCO de este tipo de arquitecturas suele ser muy bajo en consumo de recursos, lo más bajo posible sin afectar la escalabilidad y la calidad de los servicios (más o menos el requerimiento base presente en toda arquitectura de sistemas).


Traduzco/colaboro el artículo original:

La arquitectura evolucionó durante un año, provee servicios para 14+ millones de usuarios. La infra la manejan 3 ingenieros. Tres principios de la arquitectura:

- Mantener las cosas bien simples.
- No reinventar la rueda.
- Aplicar, cuando se pueda, tecnologías sólidas y probadas.

La arquitectura, de arriba hacia abajo

1) OS / Hosting
Ubuntu 11.04 (Natty), corriendo sobre Amazon EC2.
Los Ubuntus anteriores les dieron problemas en EC2 con alto tráfico, pero Natty funcionó bien. Por ahora están con Amazon, ya que con 3 ingenieros es poco viable el hosting propio.

2) Balanceo de Carga
Todo request a los servers de Instagram pasa por balanceadores. Solían correr 2 Nginx y balancearlos con DNS Round-Robin. El problema con eso es el tiempo que tarda DNS en actualizarse, para el caso en que hubiera que decomisionar alguno de los servers. Ahora están usando Amazon Elastic Load Balancer, con 3 instancias Nginx detrás y las pueden sacar y poner sin problemas (son sacadas de la rotación automáticamente si alguna falla en un health-check). También terminan su SSL a nivel ELB, lo que libera carga de CPU en los Nginx. Usan amazon Route53 para DNS.

3) Servers de aplicación
Corren Django sobre 25 máquinas Amazon High-CPU Extra-Large. La carga de trabajo está muy ligada a las CPU más que a la memoria. así que las máquinas mencionadas le ofrecen un buen balance de memoria y cpu.

Usan gunicorn como server WSGI, antes usaban mod_wsgi de Apache, pero Gunicorn les resultó más fácil de configurar y con menos consumo de CPU. Para correr comandos en varias instancias a la vez, usan Fabric, que hace poco tiene un modo paralelo que les permite deployar código en muy poco tiempo.


4) Data Storage
La mayoría de los datos (usuarios, metadatos de fotos, tags, etc.), están guardados en Postgresql, en este link explican como "shardean" a través de varias diferente instancias de Postgresql.
http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram

¿Qué es "shardear" en bases de datos?
http://en.wikipedia.org/wiki/Shard_(database_architecture)

El cluster shard principal tiene 12 instancias de memoria Quadruple Extra-Large (y 12 réplicas en una zona diferente).

Los ingenieros se dieron cuenta que el network filesystem de Amazon (EBS), no soportaba suficientes búsquedas de disco por segundo, así se dedicaron a mantener en memoria todo el set de trabajo. Para lograr buena performance de IO (entrada/salida), configuraron los discos EBS en RAIDS por software usando mdadm.

Un tip que dan: se dieron cuenta que vmtouch ( http://hoytech.com/vmtouch/vmtouch.c ) es una muy buena herramienta para ver qué datos están en memoria, especialmente al hacer failover de una máquina a la otra donde no hay un perfil de memoria activo todavía. Hay un script ( https://gist.github.com/1424540 ) que usan para parsear el output de vmtouch y mostrar el comando vmtouch correspondiente a correr en otro sistema para hacerlo coincidir con el estado de la memoria de la anterior.

Todas las instancias Postgresql corren en un esquema master-replica usando Streaming Replication. Usan snapshots EBS, para hacer snapshots frecuentes de los sistema para backup. Usan XFS como filesystem del OS, lo cual les permite congelar/descongelar los arreglos RAID cuando están haciendo el snapshot, garantizando así la consistencia del - filesystem dentro del - snapshot. Se inspiraron en ec2-consistent-snapshot ( http://alestic.com/2009/09/ec2-consistent-snapshot ). Para arrancar la replicación, la herramienta que usan es repmgr. de 2ndQuadrant ( https://github.com/greg2ndQuadrant/repmgr ).

Para conectar las bases de datos con los servers de aplicación, se dieron cuenta pronto que ello tenía un fuerte impacto en la performance, así que usan Pgbouncer para poolear conecciones a Postgresql. El blog de Christopher Pettus es una gran fuente de datos respecto de Django, Postgresql y Pgbouncer.

http://pgfoundry.org/projects/pgbouncer/
http://thebuild.com/blog/

Las fotos en sí las guardan en Amazon S3, la cual guarda ahora varios terabytes de datos de fotos para Instagram. Usan Amazon CloudFront como CDN, lo que ayuda a los tiempos de carga de imágenes de usuarios alrededor del mundo.

También usan Redis extensivamente. que abastece el feed principal, el de actividades y el del sistema de sesiones (este es el backend de session de Django > https://gist.github.com/910392), y el de otros sistemas relacionados ( http://instagram-engineering.tumblr.com/post/12202313862/storing-hundreds-of-millions-of-simple-key-value-pairs ). Todos los datos de Redis necesitan estar en memoria, así que terminaron corriendo varias instancias de memoria Quadruple Extra-Large para Redis, ocasionalemente shardean en varias instancias de Redis para algun subsistema. Corren Redis en un esquema master-replica, y las réplicas constantemente guardan la DB a disco; para terminar usan snapshots EBS para backupear esos dumps DB (lo hacen en la réplica porque se dieron cuenta que dumpear la DB en el master era muy "costoso" en recursos). Ya que Redis permite escribir a las réplicas, se hace para para lograr un fácil failover a nuevas máquinas Redis, sin que sea necesario un downtime (bajar el servicio).

Para la API de geo-búsqueda usaron Postgresql por varios meses, pero cuando shardearon sus entradas Media, se mudaron a Apache Solr, que tiene una interfaz JSON simple, así que por lo que concierne a su aplicación, es solo otra API a consumir.

Finalmente, como todo servicio web moderno, usan Memcached para cacheo y tienen 6 instancias Memcached, a las que se conectan usando pylibmc y libmemcached, cuentan que Amazon tiene el servicio Elastic Cache, pero no es más barato ($$$), que correr las instancias Memcached, así que todavía no lo están usando.


5) Cola de tareas y envío de notificaciones
Cuando un usuario quiere compartir una foto Instagram en Twitter o Facebook, o cuando necesitan notificar a los suscriptores "Real-Time" ( http://instagram.com/developer/realtime/ ), de que una nueva foto fue posteada, manejan esa tarea con Gearman ( http://gearman.org/ ), un sistema de manejo de colas escrito en Danga. Proceder asincrónicamente en la cola implica que los uploads de medios terminan rápidamente, mientras que los más pesados pueden correr en background. Tienen unos 200 workers (todos escritos en Python), consumiendo de la cola de tareas en cualquier momento, divididos entre los servicios que comparten. También manejan el feed de fan-out en Gearman, así que postear es tan responsivo para un nuevo usuario como lo es para un usuario con muchos followers.

Para enviar notificaciones la solución de mejor costo-beneficio que encontraron fue https://github.com/samuraisam/pyapns , un servicio opensource de Twisted que llegó a manejar más de un billón de envíos de notificaciones y funcionó bien.


6) Monitoreo
Con más de 100 instancias, es importante saber qué está pasando. Usan Munin ( http://munin-monitoring.org/  ) para graficar métricas de todos los sistemas, y también los alerta si algo está fuera de rangos normales. Escriben muchos plugins customizados para Munin, sobre Python-Munin (http://samuelks.com/python-munin/ ), para graficar métricas que no son del sistema (por ejemplo, suscripciones por minuto, fotos posteadas por segundo, etc.), Usan Pingdom ( http://pingdom.com/ ) para monitoreo externo del servicio y PagerDuty ( http://pagerduty.com/ )para manejar notificaciones e incidentes.

Para reporte de errores de Python usan Sentry ( http://pypi.python.org/pypi/django-sentry) una muy buen app Django escrita por la gente de Disqus. En cualquier momento dado, se loguean y pueden ver qué errores están ocurriendo en el sistema, en tiempo real.

Usar servicios de clouds

Los servicios de clouds ofrecen varias cosas, IaaS, PaaS, etc. En principio una migración estándar que "tiene" que funcionar es migrar lo que corre un servidor físico directo a una instancia en una cloud IaaS (Infraestructura como Servicio), y la "instancia" sería básicamente un server virtual en algun proveedor de cloud services, y migramos ahí nuestro server físico. No es nada diferente de migrar a servers virtualizados hosteados localmente o migrarlos a un VPS, un server virtualizado en un proveedor de hosting. Hasta ahí son parecidos los viejos proveedores a los servicios de cloud, pero solo hasta ahí (luego vemos más diferencias importantes).

Hay muchos escenarios donde se puede utilizar clouds, pero la idea base es esta: servicios - una aplicación X  que corre en servers físicos - que no es necesario correr con frecuencia.

Es decir, usaríamos clouds si necesitamos de vez en cuando correr esa aplicación X que requeriría un servidor físico muy potente para correr, pero, no tenemos suficientes servers físicos para dejar uno dedicado y prenderlo cuando haga falta.

Si hablamos de infra virtualizada, es lo mismo, puede que tengamos 6 servidores virtualizados en un server físico, y que no haya la posibilidad de usar los recursos virtualizados en el momento en que haga falta correr nuestra aplicación X. (un ejemplo, es que la aplicación X necesite correr indefectiblemente a las 11 de la mañana, cuando los demás 6 servidores virtualizados están usando todos los recursos del host físico).

Así que una alternativa sería rentar un host virtualizado en una cloud, disponer de los servicios básicos: el mínimo espacio de disco necesario para alojar los datos, la mínima cantidad de ram necesaria para que bootee el server y así sucesivamente, todos los mínimos.

¿Por qué mínimos? Porque la razón de usar servicios en clouds es poder ampliar y reducir a voluntad los recursos de servidor que contratamos (y pagando más o de dejando de pagar por ello). Así que se se puede tener - dependiendo del proveedor de cloud - incluso el server apagado todo el tiempo, por un mínimo costo, y solo arrancarlo cuando haga falta, luego ampliar el "pack" de servicios (+ CPU, +RAM, +placas de red, etc.), por el tiempo que nos haga falta (4 horas por ejemplo), utilizar esos recursos y luego, al terminar, ya nos facturaron el uso que hicimos de lo contratado, y podemos reducir nuestro "pack" a lo mínimo de vuelta, y así sucesivamente podemos llegar a tener disponible recursos físicos para nuestro server en la cloud, que no estarían disponibles en nuestra infraestructura local.

Como pueden ver, contratar más servicio, subir requerimientos de RAM, CPU, storage, etc. es un trabajo de administración importante, y más aún si consideramos todo el trabajo de arrancar/rearrancar el servidor, y luego las tareas internas de administración en nuestra app (que es el motivo por el cual se hace todo este trabajo). Ok, acá es donde empezamos a considerar otras diferencias entre un proveedor tradicional y una cloud: en clouds tenemos una API y herramientas que nos permiten interactuar con la infraestructura de cloud, enviando ordenes a las instancias. No tengo noticias puntuales de que ningun proveedor de cloud ofrezca mecanismos de manejo de capacidad desde su API, por ej. adquirir 20 GB extra de storage, pero es posible que alguno lo tenga disponible.

Administrar sistemas en 2012 - II : Infraestructura Física

Aquí encontramos el típico servidor basado en hardware físico. Sobre él corren sistemas operativos y aplicaciones. Mucho de la administración de sistemas clásica se relaciona con este tipo de infras, y mucho de lo que hay en las otras infras se deriva directamente de este.

Lo particular de este tipo de infra es que las aplicaciones siempre corren dentro del sistema operativo. Como apps tenemos todo (bases de datos, webservers, servicios de soporte de red - dns, ftp, ssh, rdp, etc.), incluídas apps de soporte de infra (backup, clustering, monitoring, configuration management, patch management, software antivirus/seguridad, etc.).

Lo otro particular es que este tipo de infra está muy cerca del mundo real, tenemos los servidores, que van montados en racks, que necesitan aprovisionamiento de energía fiable, que viene de UPS, con reaseguro en generados propios ("grupo electrógeno"). La refrigeración es un factor importante y ello se relaciona directamente con la provisión de energía. La seguridad física tiene un papel preponderante, no solamente en cuanto a la autenticación/autorización del personal, sino en cuanto a la integridad de la infra física (previsión contra incendios, robos, evacuación). Todo lo anterior requiere políticas escritas, explícitas y auditables, siguiendo las normas,reglamentdos y disposiciones establecidas para este tipo de instalaciones (están bastante reguladas en algunas ciudades), y luego tenemos la auditorías de - todo - lo anterior, regulares y necesarias, con la "rule of thumbs" de tener que realizarlas por terceros.

No es necesario que un sysadmin tenga conocimientos de ingeniería eléctrica para administrar un datacenter, tampoco de refrigeración, pero debe entender los fundamentos de esos campos para poder interactuar fluídamente con los demás miembros del equipo que trabajan fuera de campos IT.

Desde lo técnico, si bien las apps de soporte suelen tener muchas posibilidades, lo más "exótico" requerido en la práctica suele ser el manejo de software de clustering (cada sistema operativo suele incluir su suite de clustering y hay apps comerciales importantes que hacen lo mismo pero con un "extra", que se cobra). Es indispensable y se da por hecho, el manejo de algun software de backup y de monitoring (más que nada para poder adaptar ese conocimiento a otro/cualquier software que se usen localmente). En tercer y a veces lejano puesto, está el requerimiento de aptitudes de administración de bases de datos, en gral. consiste en poder hacer deployments y performance tunning, ya que la tarea de administración de base de datos es una especialidad donde es bastante habitual encontrar un especialista cubriendo la tarea, por más chica que sea la infraestructura.

La infra física se relaciona directamente con otros dos tipos de infraestructuras necesarias, pero no explícitamente campo del administrador de sistemas y se suele encontrar un tercer y un cuarto tipo de infraestructura, basada en hardware (incluso software), propietario especializado:

1. a) Infraestructura de Networking
1. b) Infraestructura de Storage
1. c)  Infraestructura de appliances
1. d) Infraestructura de soluciones integradas

1. a) Infraestructura de Networking
Networking es lo más conocido por estar hace tiempo, y todos sabemos que hace falta un administrador de redes como especialista para operar este tipo de infraestructuras. El conocimiento generalista sobre networking es requerido al administrador para poder configurar los servicios, servidores y hardware que lo requiera, para poder conectarlos a la infraestructura de networking. Hay que mencionar un subcampo de especialidad en networking, Firewalls, del que también requiere conocimiento generalista el sysadmin, ello con el objeto de poder accionar apropiadamente - desde su action point, por ejemplo, desde un server - en la solución de problemas de conectividad.

1. b) Infraestructura de Storage
La infra de Storage es más nueva, de hace pocos años, también requiere conocimiento de especialista, tal como en networking. Lo particular es que el administrador de sistemas es el que más manejó Storage desde su aparición, más que nada porque lo primero que hubo de infra de storage era hardware especializado muy fácil de operar, por ende no se contrataba a un tercer especialista. Con el tiempo, el field de Storage creció en complejidad y es una especialidad aparte.

Desde el punto de vista del administrador de sistemas, hay conocimiento de background sobre infra de storage que debe manejar, al igual que debe manejar conocimientos sobre networking (por ejemplo, para cargar una tabla de ruteo en un sistema operativo). En la infra de Storage se da igual, con nociones se puede manejar bien lo que hace falta de saber de Storage, pero con un poco más de insight, de profundidad en Storage, se puede administrar mucho mejor (sin que ello implique que el sysadmin llegue a ser un storage administrator).

1. c)  Infraestructura de appliances
Los appliances hardware califican como infraestructura física porque constituyen un target adicional de administración, de modo similar al hard de storage y de networking. Muchos de estos appliances están preparados para ser desplegados masivamente en la infraestructura, interconectandose, intercambiando actualizaciones de firmware, de definiciones de antivirus, parches de emergencia del fabricante, etc. Los productos nuevos ofrecen niveles resiliencia mínimos como para llegar disponer de la opción de montarlos en cluster.

Un appliance hardware es cualquier "caja", solución enlatada que brinde un servicio. Físicamente son servidores pre-configurados; desde el punto de vista de la administración tienen interfaces de administración - gráficas, web, modo texto- propietarias y ellas requieren un training especializado a veces tan extenso y minucioso que un especialista en determinados appliances se vuelve directamente necesario al momento de adoptar esos appliances en la infraestructura. Hay todo tipo de appliances al momento: mailservers, security (antivirus para mailservers, para la red filtrando en capa 7, etc.), loadbalancers, monitoreo, para recolección y analisis de logs, etc.


1. d) Infraestructura de soluciones integradas
Estas se originan cuando grandes vendors concretan una gran integración en uno o más datacenters, luego de lo cual el grueso de la infra (servers, blades, storage, networking, software de infra: configuration management, patch management, backup, monitoring, antivirus, etc. ) pasa a ser de un solo proveedor, en general en componentes hardware, pero en los últimos años la tendencia es sumar software a la integración masiva.
Ello que implica que en general nos encontramos con "administración centralizada" y otras prestaciones que se logra con este tipo de integración. En estas soluciones los puntos de administración directa son relativamente pocos para las operaciones diarias usuales (es decir, con pocos administradores se puede manejar una infra muy grande), y la automatización es masiva ni bien vamos un nivel abajo de las interfaces de administración.
Ello implica que el conocimiento REAL necesario para mantener funcionando la infra entera a largo plazo (y no solo los puntos de administración logrados mediante automatización), puede ser de considerable magnitud. Normalmente este tipo de implementaciones masivas incluye un fuerte apoyo de soporte remoto y onsite del vendor, a la vez que se vuelve indispensable que los administradores vayan progresivamente incrementando su insight - en gral. se incluye cursos y training dentro de la solución - para realmente poder operar al nivel técnico requerido cuando haya que realizar troubleshooting directo de la automatización subyacente (por más que se cuente con soporte onsite y remoto, los responsables son siempre "locales").

Administrar sistemas en 2012 - I : Tipos de infraestructura

En qué consiste administrar sistemas hoy en día?

Hace un tiempo atrás buscaba background para actualizar mi skillset de sysadmin y no encontré material que explicara lo que explico en esta serie de artículos. Espero que les sea util.

Parecería que los campos de conocimiento para administrar sistemas crecen sin control y desmesuradamente, en realidad la disciplina de administración de sistemas crece "consecuentemente", es decir como consecuencia de necesidades técnicas y organizativas que van creando nuevos campos de injerencia y nuevas tecnologías que administrar para el administrador.

Hay una tendencia hoy, casi una moda, que considera a los DevOps como el "futuro" de la administración de sistemas. En parte es cierto, lo son, por otra parte la profesión abarca mucho más que lo que sería la máxima injerencia típica de un devop en cuanto a administrar sistemas.


Tipos de Infraestructura

El orden en que se explica cada campo en los primeros 3 casos está fuertemente relacionado con que son infraestructuras derivadas, unas de otras. Desde la física se construye la virtual y sobre la virtual se monta la de clouding.

La cuarta se considera aparte porque está más relacionada con un contexto y requerimientos propios del ambiente donde se implanta, es decir, Internet, y puede estar montada sobre cualquiera de las tres anteriores.

Hoy en día tenemos cuatro tipos de infraestructura:


1. Infraestructura física
2. Infraestructura virtual
3. Infraestructura de clouding
4. Infraestructura web

Tal vez haya alguno más tipos (incluí varios subtipos en realidad), pero estos los voy a definir por extensión para ir viendo los campos de conocimiento que hay que abarcar para manejarse en cada una de esas infras.

Es obvio que los conocimientos se solapan y por ejemplo, saber implementar - básicamente - un servidor de db Oracle sobre hardware físico va a servir para poder hacerlo sobre hardware virtualizado, y sobre hardware virtualizado corriendo en clouds (públicas).

El background básico de cada infraestructura - y lo que es la base de la disciplina de administración de sistemas - es saber instalar, configurar y administrar sistemas operativos y aplicaciones sobre un servidor, independientemente de la infraestructura sobre la cual esté montado el servidor.

El truco es que, además, el administrador de sistemas se encarga de administrar la infraestructura subyacente a los servidores, sistemas operativos y aplicaciones. A medida que se expande la operación de una organización y por ende sus infraestructuras, la carga de horas/hombre para la administración efectiva crece, en consecuencia la especialización es algo común de encontrar en grandes organizaciones, por ejemplo, en el especialista en infraestructura física, el especialista en infraestructura virtual, los devops (especialistas en infras web y de clouding típicamente), etc.

Contínua en:

Parte II - Infraestructura Física