Desde que leí la primera vez sobre SDNs pensé que muchas de las funciones básicas de "pushing" scheduleado de configuraciones de red se pueden hacer de modo bastante simple si es que los equipos de red tienen SSH+SCP, como es el caso de muchos Cisco.
Tenés que tener key SSH (o un script wrapper basado en expect, para que le pase la passwd al equipo luego del login), y luego vas "pusheando" los cambios que necesités, claro es mucho más manual que hacerlo vía APIs.
Por ejemplo, la idea es que podés hacer cosas simples fácilmente: configurar que todos los días, de 8 a 13 y de 17 a 21, todos los puertos de la red tengan el nivel más bajo de seguridad, y que en otro horario, la seguridad de los puertos sea máxima, inclusive que todos los puertos de estaciones de trabajo estén "down" (apagados), fuera del horario de trabajo.
Básicamente necesitás un SO que te permita schedulear dos scripts, uno que suba (y aplique) cada configuración, en el horario apropiado. Y otro que haga lo mismo, con otra configuración.
Tu scripting va a tener que manejar un juego completo de configuraciones "base", u "originales", las están activas en los equipos de red. Luego en el horario apropiado, el otro script se conecta a todos los equipos de red, copia la otra configuración, la activa, y la pone en producción.
En realidad, podés desarrollar un solo script y pasarle como parámetro un archivo de configuración completa para cada equipo de red, con los parámetros que quieras modificar cambiados en esos archivos, el script simplemente los va a "pushear" a los equipos y los va a poner en producción.
No sería mucho pedir también, incorporar un mínimo manejo de errores en los scripts:
- Volcar todo el trabajo a logs.
- Verificar luego de la aplicación qué configuración está online, en qué equipos, desde qué hora.
- Enviar correos de aviso en caso de cualquier fallo.
La idea central de todo esto es que la noción de "SDN" se podría poner a funcionar "a caballo" de una infraestructura de red tradicional, que no soporta en hardware ninguna API ni estándar de SDN formal, y ello utilizando recursos fáciles de conseguir, e implementandolo de un modo relativamente muy sencillo.
Vualá: "SDN" a pelo, sin APIs, ni siquiera requiriendo soporte en hardware :-)
sábado, 17 de agosto de 2013
sábado, 3 de agosto de 2013
Desastres organizacionales, cómo ocurren y cómo prevenirlos.
En mi experiencia como sysadmin ví explotar literalmente proyectos de toda escala presupuestaria, que quedaron inconclusos, penando las consecuencias de los recursos ya gastados sin haber conseguido los objetivos, por ello me volví afín al estudio de las causas sociológicas de los desastres organizacionales, leyendo material como el de abajo; que considero una buena introducción.
Lo de abajo me parece una muy buena noción inicial, es el primer párrafo del paper (traducido):
"Cuando pensamos en desastres organizacionales mayores, como el colapso de una corporación o un accidente en una planta química, tendemos a hacer dos suposiciones: que la falla fue causada por un error humano o por una falla de máquinas/equipamiento, y que la falla ocurrió súbitamente con poca o ninguna advertencia. De hecho, la investigación de desastres organizacionales sugiere que ambas suposiciones son incorrectas o al menos incompletas. Mientras el error humano o de máquinas/equipamiento puede ser el evento que precipita el desastre, tal error yace al final de una cadena de otros factores causales. Incluso más, muchas organizaciones incuban desastres durante largos períodos de gestación durante los cuales, los errores y llamadas de atención se acumulan. Aunque estas señales de alarma son doloramente claras en retrospectiva, ¿por qué es tan difícil para las organizaciones detectar, reconocer y actuar sobre estas condiciones precursoras antes de que se vuelvan una tragedia? Este estudio sugiere que las señales de alarma no son reconocidas y no se actúa por impedimentos en la circulación de información que causa que las organizaciones ignoren las señales de advertencia lo que permite a los errores crecientes y problemas escalar, llevando eventualmente a un quiebre a gran escala. Identificamos tres tipos de impedimentos de información derivados de la investigación teórica y de análisis de casos de desastre organizacional: puntos ciegos epistémicos, negación de los riesgos, e impedimentos estructurales."
http://www.researchgate.net/publication/235275618_Organizational_disasters_why_they_happen_and_how_they_may_be_prevented?ev=pub_cit_inc
Lo de abajo me parece una muy buena noción inicial, es el primer párrafo del paper (traducido):
"Cuando pensamos en desastres organizacionales mayores, como el colapso de una corporación o un accidente en una planta química, tendemos a hacer dos suposiciones: que la falla fue causada por un error humano o por una falla de máquinas/equipamiento, y que la falla ocurrió súbitamente con poca o ninguna advertencia. De hecho, la investigación de desastres organizacionales sugiere que ambas suposiciones son incorrectas o al menos incompletas. Mientras el error humano o de máquinas/equipamiento puede ser el evento que precipita el desastre, tal error yace al final de una cadena de otros factores causales. Incluso más, muchas organizaciones incuban desastres durante largos períodos de gestación durante los cuales, los errores y llamadas de atención se acumulan. Aunque estas señales de alarma son doloramente claras en retrospectiva, ¿por qué es tan difícil para las organizaciones detectar, reconocer y actuar sobre estas condiciones precursoras antes de que se vuelvan una tragedia? Este estudio sugiere que las señales de alarma no son reconocidas y no se actúa por impedimentos en la circulación de información que causa que las organizaciones ignoren las señales de advertencia lo que permite a los errores crecientes y problemas escalar, llevando eventualmente a un quiebre a gran escala. Identificamos tres tipos de impedimentos de información derivados de la investigación teórica y de análisis de casos de desastre organizacional: puntos ciegos epistémicos, negación de los riesgos, e impedimentos estructurales."
http://www.researchgate.net/publication/235275618_Organizational_disasters_why_they_happen_and_how_they_may_be_prevented?ev=pub_cit_inc
Lo "último" en monitoreo opensource
Las startups IT y empresas de éxito como Arista, Cloudera, Sonian, Etsy, Netflix, etc. usan - y crean - herramientas de monitoreo opensource de nueva tecnología, muy buenas, estables y confiables, apropiadas para mantener funcionando los sistemas de empresas muy exitosas o rumbo al éxito, pero no son muy populares, más que nada por desconocimiento.
¿Qué herramientas de monitoreo opensource se están usando en la "frontera"?
¿Qué es lo último que funciona bien en producción, soluciona problemas importantes, es seguro, estable, pero todavía no es un software de monitoreo popular (como Ganglia o Nagios)?
La homework es ver qué hace cada herramienta, de qué puede consumir y hacia donde puede publicar datos (cof cof Nagios cof cof).
OpenTSDB - Monitoreo con soporte de altas cargas (vía HBase/Hadoop)
http://www.slideshare.net/thecupoflife/opentsdb-in-a-real-enviroment
http://www.slideshare.net/geoffanderson/monitoring-mysql-with-opentsdb-19982758
http://www.slideshare.net/cloudera/4-opentsdb-hbasecon
Sensu
https://github.com/sensu
https://speakerdeck.com/joemiller/practical-examples-with-sensu-monitoring-framework
Graphite
http://graphite.wikidot.com/
http://graphite.readthedocs.org/en/1.0/tools.html
Logster - Generador de métricas desde Logs para Graphite y Ganglia
https://github.com/etsy/logster
Logstash - (fijáte la parte de "outputs" > Nagios, Ganglia, OpenTSDB, Graphite, Pagerduty, etc.)
http://logstash.net/docs/1.1.13/
(GUI para Logstash) - http://kibana.org/about.html
- Etc.
¿Qué herramientas de monitoreo opensource se están usando en la "frontera"?
¿Qué es lo último que funciona bien en producción, soluciona problemas importantes, es seguro, estable, pero todavía no es un software de monitoreo popular (como Ganglia o Nagios)?
La homework es ver qué hace cada herramienta, de qué puede consumir y hacia donde puede publicar datos (cof cof Nagios cof cof).
OpenTSDB - Monitoreo con soporte de altas cargas (vía HBase/Hadoop)
http://www.slideshare.net/thecupoflife/opentsdb-in-a-real-enviroment
http://www.slideshare.net/geoffanderson/monitoring-mysql-with-opentsdb-19982758
http://www.slideshare.net/cloudera/4-opentsdb-hbasecon
Sensu
https://github.com/sensu
https://speakerdeck.com/joemiller/practical-examples-with-sensu-monitoring-framework
Graphite
http://graphite.wikidot.com/
http://graphite.readthedocs.org/en/1.0/tools.html
Logster - Generador de métricas desde Logs para Graphite y Ganglia
https://github.com/etsy/logster
Logstash - (fijáte la parte de "outputs" > Nagios, Ganglia, OpenTSDB, Graphite, Pagerduty, etc.)
http://logstash.net/docs/1.1.13/
(GUI para Logstash) - http://kibana.org/about.html
- Etc.
sábado, 27 de julio de 2013
Gnome empieza a desaparecer? QT (y KDE) avanzan.
Como ya se anticipaba hace un tiempo, LXDE y Razor-QT van a ser un solo escritorio, LXDE-QT, que va a dejar de lado GTK y su herencia de GNOME para adoptar tecnologías QT (que se llevan muy bien con KDE, y se van a llevar mejor todavía próximamente).
Por otro lado, Gnome se empieza a apagar como entorno de escritorio. La conferencia anual de desarrolladores Gnome, GUADEC, no se hizo en 2013, y muchos ya están abandonando el barco que no parece que fuera a durar tanto más tiempo. Muchas apps están planeando migrando a QT (como Subsurface de Linus Torvalds), muchas desde el vamos se basan en QT, y otras como LXDE se encuentran en plena migración. Además, el entorno de escritorio se encuentra cada vez más desplazado del escenario de ser escritorio por defecto de distribuciones populares: Ubuntu migró a Unity (de fondo tenemos a XFCE muy fuerte), Mint pisa muy fuerte con Cinnamon y de fondo KDE, XFCE y LXDE, Opensuse sigue con KDE como escritorio principal, y solamente Fedora - que no es demasiado popular al momento en realidad - lo sigue manteniendo como entorno por defecto.
El patrocinador principal del desarrollo de Gnome3 (la empresa que paga a la mayoría de los top developers de Gnome), Red Hat, decidió no usar la nueva interfaz de Gnome 3 para próximas versiones de su versión Enterprise (van a usar el modo Fallback como entorno por defecto), y ello es una demostración evidente de que la nueva interfaz, luego de ya bastante tiempo - años - no ha podido resolver algunos problemas de compatibilidad con cierto hardware gráfico (problemas que no existían en Gnome 2 por cierto).
Otras distribuciones Enterprise de uso actual tampoco tienen a Gnome 3 como entorno por defecto; SuSe Enterprise tiene Gnome 2 o KDE, Ubuntu LTS tiene Unity u otros entornos, pero no Gnome 3, CentOS sigue usando Gnome 2, y así sucesivamente.
Al parecer nos vamos despidiendo de Gnome, lo que en realidad no es grato, ya es un buen software en general; sin embargo queda todavía ver si su comunidad lo puede salvar, tal como lo hizo la comunidad de developers de KDE, luego del fiasco inicial de KDE4 y tal como lo hizo la comunidad de XFCE cuando todos decían que no hacía falta un 2do. entorno gráfico basado en GTK+.
El último GUADEC
http://tech.slashdot.org/story/13/07/24/0157210/the-last-guadec
Por otro lado KDE como entorno que promovió originalmente el uso de QT, se afianza con nuevas versiones estables regulares, inclusive con un cambio de tecnología mayor detrás de escena en las últimas y en las que se vienen (QT 4 a QT 5), y se preparan para tener en unos meses, no una sino dos versiones estables. La actual KDE 4.X y el próximo KDE 5.
http://www.muylinux.com/2013/07/22/lxde-razor-qt-se-fusionan-proyectos/
Por otro lado, Gnome se empieza a apagar como entorno de escritorio. La conferencia anual de desarrolladores Gnome, GUADEC, no se hizo en 2013, y muchos ya están abandonando el barco que no parece que fuera a durar tanto más tiempo. Muchas apps están planeando migrando a QT (como Subsurface de Linus Torvalds), muchas desde el vamos se basan en QT, y otras como LXDE se encuentran en plena migración. Además, el entorno de escritorio se encuentra cada vez más desplazado del escenario de ser escritorio por defecto de distribuciones populares: Ubuntu migró a Unity (de fondo tenemos a XFCE muy fuerte), Mint pisa muy fuerte con Cinnamon y de fondo KDE, XFCE y LXDE, Opensuse sigue con KDE como escritorio principal, y solamente Fedora - que no es demasiado popular al momento en realidad - lo sigue manteniendo como entorno por defecto.
El patrocinador principal del desarrollo de Gnome3 (la empresa que paga a la mayoría de los top developers de Gnome), Red Hat, decidió no usar la nueva interfaz de Gnome 3 para próximas versiones de su versión Enterprise (van a usar el modo Fallback como entorno por defecto), y ello es una demostración evidente de que la nueva interfaz, luego de ya bastante tiempo - años - no ha podido resolver algunos problemas de compatibilidad con cierto hardware gráfico (problemas que no existían en Gnome 2 por cierto).
Otras distribuciones Enterprise de uso actual tampoco tienen a Gnome 3 como entorno por defecto; SuSe Enterprise tiene Gnome 2 o KDE, Ubuntu LTS tiene Unity u otros entornos, pero no Gnome 3, CentOS sigue usando Gnome 2, y así sucesivamente.
Al parecer nos vamos despidiendo de Gnome, lo que en realidad no es grato, ya es un buen software en general; sin embargo queda todavía ver si su comunidad lo puede salvar, tal como lo hizo la comunidad de developers de KDE, luego del fiasco inicial de KDE4 y tal como lo hizo la comunidad de XFCE cuando todos decían que no hacía falta un 2do. entorno gráfico basado en GTK+.
El último GUADEC
http://tech.slashdot.org/story/13/07/24/0157210/the-last-guadec
Por otro lado KDE como entorno que promovió originalmente el uso de QT, se afianza con nuevas versiones estables regulares, inclusive con un cambio de tecnología mayor detrás de escena en las últimas y en las que se vienen (QT 4 a QT 5), y se preparan para tener en unos meses, no una sino dos versiones estables. La actual KDE 4.X y el próximo KDE 5.
http://www.muylinux.com/2013/07/22/lxde-razor-qt-se-fusionan-proyectos/
martes, 23 de julio de 2013
Playbook para la buena gestión de servicios informáticos en una organización
La primer página del playbook ("Libro de Jugadas") para la gestión de servicios informáticos para una organización (incluye administración de infraestructura y soporte a usuarios por ejemplo), que estuvimos manejando en 2012 y 2013 con el equipo de trabajo del que formo parte hoy, es esta:
El Playbook (Libro de Jugadas)
Regla 1: Atender todos los pedidos de soporte y ayuda de los usuarios.
Regla 2: Atender los pedidos lo más rápido posible.
Regla 3: Atender los pedidos de cualquier importancia. No importa si es un usuario que no sabe cómo subrayar un título en un documento, un cartucho de impresora vacío o un switch que no funciona y deja sin conectividad a 20 usuarios. Hay diferentes prioridades, pero todos los pedidos de atención son atendidos.
Regla 4: Simplificar la arquitectura organizativa publicando - internamente - servicios de atención: X se encarga de soporte, X se encarga de gestión , X atiende servers & redes, X coordina y gestiona recursos con la organización, etc. Se evita la confusión, y los usuarios saben qué persona está manejando su problema, y trabajando para resolverlo.
Regla 5: Automatizar la gestión operativa, implica:
- Gestión de sistemas (trabajo de adm. de redes y servidores): Todas las tareas automatizables en la infraestructura deben llegar a ser automatizadas, a medida que se incrementa la automatización, se incrementa el tiempo disponible de adm. de sistemas que se puede re-utilizar en optimización/mejoramiento y en nuevos proyectos.
- Gestión organizativa (apoyándose en la Regla 4): Se evita al máximo la duplicación de tareas, por ende cada elemento del equipo puede realizar sus tareas más eficientemente (completa más tareas en igual tiempo que antes tomaba hacer menos cosas).
Regla 6: Aprovechar las oportunidades únicas de la "nube":
La adopción de tecnologías de virtualización nos permitió adquirir una flexibilidad muy alta para la rápida adaptación a los desafíos y requerimientos cambiantes en la gestión y administración de la infraestructura, tendientes a mejorar la prestación de servicios informáticos; siempre interactuando y unificando esta idea con los conceptos de las demás Reglas.
La Gestión organizativa puede ofrecer así a la organización, un nivel inusitado de posibilidades disponibles de inmediato para nuevos servicios y soluciones que se necesite, gracias a que la Gestión de sistemas va a poder absorber bien nuevos requerimientos, inclusive inesperados.
Suscribirse a:
Entradas (Atom)