General

Rebasing CoreOS for ephemeral cloud storage

The convenience and economy of cloud storage is indisputable, but cloud storage also presents an I/O performance challenge. For example, applications that rely too heavily on filesystem semantics and/or shared storage generally need to be rearchitected or at least have their performance reassessed when deployed in public cloud platforms.

Some of the most resilient cloud-based architectures out there minimize disk persistence across most of the solution components and try to consume either tightly engineered managed services (for databases, for examples) or persist in a very specific part of the application. This reality is more evident in container-based architectures, despite many methods to cooperate with the host operating system to provide cross-host volume functionality (i.e., volumes)

Like other public cloud vendors, Azure presents an ephemeral disk to all virtual machines. This device is generally /dev/sdb1 in Linux systems, and is mounted either by the Azure Linux agent or cloud-init in /mnt or /mnt/resource. This is an SSD device local to the rack where the VM is running so it is very convenient to use this device for any application that requires non-permanent persistence with higher IOPS. Users of MySQL, PostgreSQL and other servers regularly use this method for, say, batch jobs.

Today, you can roll out Docker containers in Azure via Ubuntu VMs (the azure-cli and walinuxagent components will set it up for you) or via CoreOS. But a seasoned Ubuntu sysadmin will find that simply moving or symlinking /var/lib/docker to /mnt/resource in a CoreOS instance and restarting Docker won’t cut it to run the containers in a higher IOPS disk. This article is designed to help you do that by explaining a few key concepts that are different in CoreOS.

First of all, in CoreOS stable Docker runs containers on btrfs. /dev/sdb1 is normally formatted with ext4, so you’ll need to unmount it (sudo umount /mnt/resource) and reformat it with btrfs (sudo mkfs.btrfs /dev/sdb1). You could also change Docker’s behaviour so it uses ext4, but it requires more systemd intervention.

Once this disk is formatted with btrfs, you need to tell CoreOS it should use it as /var/lib/docker. You accomplish this by creating a unit that runs before docker.service. This unit can be passed as custom data to the azure-cli agent or, if you have SSH access to your CoreOS instance, by dropping /etc/systemd/system/var-lib-docker.mount (file name needs to match the mountpoint) with the following:

[Unit]
Description=Mount ephemeral to /var/lib/docker
Before=docker.service
[Mount]
What=/dev/sdb1
Where=/var/lib/docker
Type=btrfs

After systemd reloads the unit (for example, by issuing a sudo systemctl daemon-reload) the next time you start Docker, this unit should be called and /dev/sdb1 should be mounted in /var/lib/docker. Try it with sudo systemctl start docker. You can also start var-lib-docker.mount independently. Remember, there’s no service in CoreOS and /etc is largely irrelevant thanks to systemd. If you wanted to use ext4, you’d also have to replace the Docker service unit with your own.

This is a simple way to rebase your entire CoreOS Docker service to an ephemeral mount without using volumes nor changing how prebaked containers write to disk (CoreOS describes something similar for EBS) Just extrapolate this to, say, your striped LVM, RAID 0 or RAID10 for higher IOPS and persistence across reboots. And, while not meant for benchmarking, here’s the difference between the out-of-the-box /var/lib/docker vs. the ephemeral-based one:

# In OS disk

--- . ( ) ioping statistics ---
20 requests completed in 19.4 s, 88 iops, 353.0 KiB/s
min/avg/max/mdev = 550 us / 11.3 ms / 36.4 ms / 8.8 ms

# In ephemeral disk

--- . ( ) ioping statistics ---
15 requests completed in 14.5 s, 1.6 k iops, 6.4 MiB/s
min/avg/max/mdev = 532 us / 614 us / 682 us / 38 us

Standard
General

NIC Ecuador y la importancia de la infraestructura DNS

Hace dos años escribí en este blog un post sobre NIC Venezuela, y las dificultades operativas que estaba atravesando en momentos de cambio de la estructura burocrática que la opera. Hoy, una falla en los servidores raíz del ccTLD .ve ocasionó una caída del servicio DNS y por consiguiente, que por alrededor de tres horas la vasta mayoría de personas dentro y fuera de Venezuela no pudieran acceder a los 217 mil dominios venezolanos, con el consiguiente impacto político y económico.

Así que quedó claro, de una forma un poco dolorosa, la fragilidad que tienen las infraestructuras DNS de algunos ccTLD, y el impacto que tiene DNS en la operación de un país. Ahora bien, ¿es posible extrapolar la situación de NIC Venezuela a la del NIC del Ecuador? Considerando que la motivación de mi post entonces fue, principalmente, entender cómo podríamos superar a la burocratización de esa entidad, que es pública, cuando en Ecuador el nic.ec es operado por una empresa privada, parecería que no hay mucho que extrapolar. Pero hagamos el ejercicio.

¿Qué pasa cuando usted escribe http://www.<algo>.ec?

Este nombre debe ser traducido a una dirección IPv4 o IPv6. Una dirección IPv4, por ejemplo, puede verse como 154.65.43.2, y una IPv6 como 2801:0:60::1. Pero esto es irrelevante para el usuario pues la conversión se hace detrás de las cámaras. Además, los resultados de estas conversiones se guardan en una memoria temporal (caché de DNS) ya sea en su máquina, en su router Wi-Fi o inclusive en los servidores de su ISP. De hecho, normalmente su ISP es el responsable de hacer esta conversión, pero cuando la dirección que usted solicita termina en .ec, incluso su ISP deberá consultar a NIC Ecuador para poder darle una respuesta.

El ccTLD ecuatoriano (.ec) es servido por cuatro servidores DNS. Dos de ellos, n1.nic.ec y n2.nic.ec, están asignados al mismo sistema autónomo, y presumiblemente, están en el mismo sitio físico (muy probablemente, en un centro de datos en las oficinas de NIC Ecuador, en el Edificio La Previsora del Malecón en Guayaquil) lo cual como mencioné en mi artículo de NIC Venezuela, puede ser un problema por razones de seguridad física y resiliencia ante desastres. Claro que, lo mismo ocurre con los DNS de algunos ISP, pero estos no son autoritativos para la zona .ec.

Por supuesto, n1 y n2 no son los únicos. Los otros dos servidores están fuera de Ecuador. El primero es operado por ISC, una organización inteacional, y el segundo es una adición reciente, n3.dns.ec, que no me queda muy claro quien lo está operando, pero está en la Costa Oeste de los Estados Unidos. Dos servidores, n2.nic.ec y n3.dns.ec, también responden por IPv6. Esto nos da una ventaja adicional en caso de problemas con IPv4 o de un escenario solo-IPv6, pero aun es marginal.

Replicación en el exterior y sistema de registro

Cuando se maneja un esquema así, la aplicación de registro (el sistema de NIC Ecuador) que se encarga de interactuar con los usuarios que son dueños de un dominio .ec, y escribir los resultados de sus solicitudes a los servidores, también debe replicar estos nuevos cambios a los servidores alteos.

Es de esperar que la aplicación de registro escriba primero en n1.nic.ec y n2.nic.ec, ya que están muy probablemente en sus oficinas, pero debe escribirse también a los servidores alteos. Como observación preliminar, hay momentos en que n1 y n2 responden con un serial de zona más actualizado que los otros dos. Quizás que la replicación no es inmediata.

Esto podría significar que, de existir algún problema en Guayaquil, los alteos tendrían información vieja, y se podrían perder las actualizaciones, o que se presente un escenario como el de la replicación de la zona corrupta que ocurrió en el .ve, al menos para roughly la mitad de los clientes DNS.

Update: hay momentos del día en que hay sincronización, y ventanas en que no siempre ocurre. Hice algunas observaciones más y conseguí que el tema es consistente con los dos servidores exteos en algunas horas del día. Aquí hice otras en el cambio del serial del 29 al 30 de mayo, aun más interesantesEsto es relativamente normal en operaciones de ccTLD, con ciclos de 15 minutos, aunque en estas observaciones hay ciclos mayores. Pero podría ser un problema del lado de los operadores de esos servidores exteos, y además, ¿podrían reducirse esos tiempos?

Conclusiones

No tengo ninguna razón para pensar que en NIC Ecuador puedan presentarse problemas como el que ocasionó la caída de hoy en Venezuela, pero tampoco tengo evidencia para pensar lo contrario, así que pensemos en ese escenario en el que la zona quede vacía, se replique a los alteos, eventualmente a los servidores de los ISP, y todas las consultas a dominios terminados en .ec no devuelvan respuesta lo que dejaría por ejemplo al .gob.ec fuera de operación hasta que se resuelva el problema. El impacto sería muy alto, y, sobre todo con el advenimiento de IPv6 (del cual ya existe regulación al respecto emanada del MINTEL) se vuelve total y absolutamente imprescindible.

Tratando de aprender de los dos mundos, de las cosas que se han hecho bien en los NIC de ambos países, podría sugerir que se promueva la instalación de réplicas en universidades, y en los centros de datos de los ISPs a través de la AEPROVI. Ecuador opera un NAP exitosamente, pero podría tomarse la idea de los grandes proveedores como Google o Microsoft que facilitan servidores preinstalados y preconfigurados con valor agregado para los operadores. Por ejemplo, una imagen de un sistema operativo Linux que opere un servidor DNS, un servidor NTP, un relay Teredo, un exit point de Tor… no sé, algo que ofrezca valor agregado. Si se firma un convenio para tener a alguien pendiente 24/7, y luego de un período de prueba y monitorización, ese servidor DNS podría entrar como una réplica. En este escenario “altamente distribuido”, la operación se volvería más compleja, sí, pero aumenta la resiliencia del modelo.

(Por cierto, tener un NAP en Venezuela no hubiera necesariamente impedido que se presentara el problema de hoy.)

Y, por supuesto, operar un par de servidores DNS adicionales afuera de Ecuador también representaría una gran ventaja. Técnicamente, no sería operar pues en algunos casos los convenios solo permiten que se haga la copia y no operarlos per se, pero los beneficios son importantes.

Pero aquí otra idea: ¿por qué NIC Venezuela no hospeda una copia de NIC Ecuador y NIC Ecuador una copia de NIC Venezuela
? Conozco a los administradores de sistema de ambos NIC, y tienen una buena comunicación, ¡podría ser una buena idea!

Creo que el aprendizaje es importante. DNS se encuentra en la capa más fundamental de la infraestructura de Inteet, y en medio de un escenario de crecimiento en el acceso a Inteet, especialmente de banda ancha, y de mayor acceso a servicios de gobieo electrónico, una falla en el servicio DNS en Ecuador o en cualquier otro ccTLD resultaría en pérdidas económicas y de confianza en el sistema. Y aunque suene a exageración nerd, no tenemos una infraestructura DNS infalible.

Mis más cordiales saludos a todos los que se dedican a mantener estas infraestructuras fundacionales de Inteet funcionando, en Venezuela, en Ecuador y en donde sea. Funcionamos gracias a ustedes.
Standard
General

Crowdsourced CSIRT en LACSEC

Hoy presenté el concepto del CCSIRT en el marco de LACSEC 2012. En el enlace está la presentación, el código, el paper y las bases conceptuales, y obviamente el sistema que ya está funcionando.

Al final de la presentación, la SUPERTEL me entrevistó para saber más sobre crowdsourcing y la importancia de los CERTs/CSIRTs en la región y colgaron el video en YouTube.

Quiero agradecer a Feando Gont, chair de LACSEC, y al Comité de Evaluación de Trabajos de LACSEC por haber aceptado la presentación y al público por su fenomenal participación, estoy muy honrado de haber podido participar en este evento como ponente en mi primera asistencia.
Standard
General

Consideraciones para implementar IPv6 en Linux

Fui invitado por Amanda Mafla y la gente del FLISOL en Ibarra (Ecuador) para participar en un evento en la Universidad Técnica del Norte en el que realicé una presentación introductoria sobre IPv6.

Es la segunda vez que participo en un evento de la UTN, y nunca han fallado en la convocatoria, muy por encima de las cien personas, en esta oportunidad para compartir sobre IPv6. Así que gracias de nuevo a las autoridades y los organizadores por la invitación.

Lo primero que quiero aclarar es que el estilo de la presentación está a medio camino entre Lessig y Matz. Por eso las láminas podrían no mostrar información de manera estructurada o como referencia y les invito a que revisen los enlaces complementarios si necesitan más información.

Esta presentación es la primera en una serie de actividades que tengo preparadas sobre IPv6 durante el año, y la realizo el día antes de que se inicie la reunión anual de LACNIC en Quito.

Standard
General

DNSCrypt en… ¿Windows?

A estas alturas quizás ya conozcasDNSCrypt, la respuestaeducada de OpenDNS al problema de DNS spoofing que surge en escenariosde MITM. Sin embargo, puede que estés utilizando alguna plataformaarcana, como… Windows, y quieras usar DNSCrypt, ¿se podrá hacer?

Definitivamente. De hecho, para lograr el punto, escribo esto desdeWindows 7, usando DNSCrypt (específicamente dnscrypt-proxy) y loúnico que necesito es Cygwin y obviamenteuna conexión a Inteet.

Una vez instalado Cygwin, llamas a bash (el script aparece en el menúcomo Cygwin Bash Shell) y descargas el código delgithub deDNSCrypt; yo usé el último tar.bz2. Puedes usar wget para bajar elcódigo y luego tar cjf para descomprimirlo. Adentro es solo cuestiónde:

./configure make && make install

Y algunos minutos después tengo dnscrypt-proxy instalado enusr/local/sbin, por lo que solo queda llamar a DNSCrypt, que vienepreconfigurado para usar OpenDNS, de la siguiente forma:

/usr/local/sbin/dnscrypt-proxy —daemonize

Ahora puedes configurar la resolución de nombres DNS contralocalhost, por ejemplo con netsh (sí, Windows tiene línea decomandos)

netsh interface ip set dns static 127.0.0.1

Y solo queda un problema por resolver y es el inicio del servicio alarranque, o de otra forma no podrás resolver nombres por DNS cuandoreinicies, esto es trivial creando un servicio, por ejemplo:

sc create dnscrypt binPath=

E iniciar dnscrypt con sc o por PowerShell.

Básicamente, DNSCrypt cifrará las consultas entre tu equipo y OpenDNS,eliminando el vector de ataque para el DNS spoofing, y circunveniendoasí censuras a nivel de DNS que implementan algunos ISPs. Sin embargo,cualquier tráfico no cifrado con aplicaciones en una red bajo MITM,específicamente ARP spoofing o suplantación del router continúa sujetoa los problemas de privacidad que ya he citado en artículosanteriores y de igual forma cualquiercensura en base a IP (blackholes, por ejemplo) continuaráfuncionando a menos que se usen proxies o redes como Tor.

Standard
General

Farewell, VirtualBox

Hace unas semanas dejé de usar definitivamente VirtualBox y pasé a utilizar KVM. Para aquellos que, como yo, empezaron a usar QEMU back in the days y se recuerdan todavía de kqemu probablemente les haya ocurrido que, cuando VirtualBox tomó vuelo, se convirtió en un estándar de facto para sus proyectos de virtualización.

¿Por qué? QEMU no era particularmente útil, y el performance era en realidad frustrante, y Xen no resolvía la situación, con una configuración sinceramente críptica. Sí, estable, enterprise-grade (3 años después y sin tocar el SLA todavía está funcionando un cluster de Zimbra Collaboration Suite, Open Source Edition para 25K cuentas con alta disponibilidad y conexión a NAS que instalé en la industria petrolera) pero se sentía como un acto de fe.

Así que muchos empezamos a utilizar VirtualBox y a consumir muchas de sus funcionalidades que lo hacían competitivo ante escenarios complejos de virtualización, sobre todo en aplicaciones de escritorio, tipo VMWare, o App-V/RDS de Microsoft. Entre estas funciones estaba el soporte para USB y VRDP. VBoxHeadless y mucho scripting salvaban la patria. Para mi, usar imágenes base (discos diferenciados) y snapshots era muy útil, y eventualmente las opciones de networking mejoraron mucho en VirtualBox. Una herramienta suficiente.

Sin embargo, el problema de ser un fanboy es que te pierdes como gira el mundo a tu alrededor. Hay muchos ejemplos. En este caso, libvirt se convirtió en realidad, y Red Hat (entre algunos otros mecenas) pusieron énfasis en GUIs y toolkits para virtualización, incluyendo específicamente a KVM como un motor de virtualización integrado al núcleo.

Manos a la obra. Instalé libvirt-bin, virt-manager y, por supuesto, qemu-kvm. Estoy en el keel 2.6.39-1-686-pae de Debian Unstable. Si vas a administrar con un usuario sin privilegios, éste debe estar en el grupo libvirt. Hay un servicio llamado libvirt-bin que debes activar y que en principio vela porque los módulos del keel estén cargados y, lo más importante, que el networking virtual esté configurado.

Quizás ésta sea una de las patas flojas de libvirt, el networking. En principio no hay tantas opciones como en VirtualBox para hacer networking arbitrario, pero si sabes manejar Netfilter (iptables) y puentes, puedes hacer lo que te dé la gana (es decir, no hay una opción explícita en virt-manager para configurar una interfaz como puente de una física, solo como un NAT o enrutando) Además, si usas dnsmasq, puede que tengas problemas de compatibilidad con los dnsmasq que utiliza libvirt para configurar la red.

Dicho esto, como tenía solo 8 máquinas virtuales en mi laptop, no investigué sobre “migradores automáticos” de la configuración de VirtualBox a KVM/libvirt. Solo migré los discos virtuales. Para esto usé kvm-img, migrando de VDI a QCOW2, como desventaja, para los discos diferenciados tuve que hacer un paso previo de “exportar” el disco con VBoxManage usando el ID del disco en VirtualBox, y luego convertirlo a QCOW2. De hecho, en este setup no tengo discos diferenciados, lo cual me incomoda pero no me he dedicado a revisar si hay alteativas.

Así mismo, donde necesité configurar dispositivos USB, lo hice por la interfaz de virt-manager. No tuve ningún problema para presentar un dispositivo del host a las máquinas virtuales. Y, para mi sorpresa (porque en qemu nunca hubo, y recuerdo el revuelo cuando Novell se la desarrolló al SuSe Studio) el acceso por VNC es una funcionalidad excepcionalmente útil, de hecho virt-manager usa esta función para presentar la pantalla en la interfaz gráfica. Excelente.

Finalmente, creo que libvirt fue una excelente opción porque me permite escalar. De hecho, en algunos de los servers que tengo en la red de la casa usé libvirt también. Solo hice ssh, e instalé los paquetes. Y solo con eso, y con tener replicados los discos (puede ser vía SAN/NAS) puedo migrar una máquina virtual de mi laptop al server y dejarla ejecutando allí de forma transparente. Awesome.

¿Performance? Muy bueno. En mis casos de uso, es casi imperceptible la diferencia con VirtualBox. Las ventajas para la administración, y sobre todo la falta de drama en las actualizaciones, valen la pena. ¡Dale libvirt!

Standard
General

Haciendo que nginx y Apache coexistan

nginx es un producto que me ha apasionado desde hace varios años. Su enfoque orientado a eventos lo hace inherentemente distinto a otros servidores Web, y en particular Apache y Cherokee que eran los dos que tenían mi atención allá en el 2006, cuando usaba Gentoo y pasaba la noche compilando cosas.

El rendimiento de nginx es increíble, y su funcionalidad como proxy reverso HTTP es incuestionable. Lo que la gente normalmente dice es que nginx tiene muy buen performance, pero pocas funcionalidades, especialmente cuando se compara con Apache, que tiene módulos para casi cualquier cosa.

A pesar de que mi primer proyecto grande con nginx fue justamente un caso de funcionalidades (hacer un proxy IMAP) estoy consciente de esa limitante, por lo que siempre he pensado que Apache es un buen servidor Web de backend, y nginx funciona muy bien en el frontend, como proxy reverso y caché. De hecho eso se aplica para otros servidores Web, incluso no solamente de código abierto sino propietarios como IIS o WAS.

Desde hace ya varios años utilizo una arquitectura sencilla pero con muchos beneficios, donde nginx se para delante de mis servidores Apache (que sirven aplicaciones con maravillosos módulos) y hace caché con el popular motor memcached.

Básicamente, en la instancia server de nginx correspondiente, y en el location que queramos servir, colocamos algo como:

location / {                set  $memcached_key  $uri;                memcached_pass 127.0.0.1:10101;                proxy_pass http://127.0.0.1:8080/;                ...        }

Lo que hacemos es pasar a un server memcached corriendo en 10101, y utilizar un proxy reverso en 8080, que en este caso sería nuestro Apache. La URI que el cliente desea es lo que se busca en memcache como una clave, y para eso sirve la primera línea. El resto de la configuración involucra instalar y correr memcached (en Debian y derivados, aptitude install memcached) e instalar, configurar y correr Apache en el puerto que definamos; y opcionalmente protegerlo con Netfilter (iptables).

Hay dos caveats de esta solución. El primero es que si delegamos los registros en Apache, solo veremos conexiones locales. Para eso hay soluciones, como pasar algunos headers con el host apropiado y usar un módulo de Apache (RPAF) en el backend. El segundo caveat es que no queremos que todas las aplicaciones pasen por el memcached, para ello podemos abrir el puerto del Apache, o bien definir otro server en nginx y solo usar proxy_pass.

En mi escenario, memcached ocupa alrededor de 2 MB. de memoria RAM cuando no hay carga y puede crecer hasta 64 MB. cuando hay carga (es el default) lo cual es razonable en un VPS.

¿Hay algo mejor que nginx? Sí. nginx y tu servidor Web preferido.

Standard