Comparando costos de Amazon EC2 y Google Computing Engine

Miércoles, 17 de septiembre de 2014 2 comentarios

Estuve mirando y por suerte son prácticamente similares las tablas disponibles en cada site (EC2 / GCE) y es relativamente sencillo compararlas [1][2].

Para sus Data Centers en USA, establecí las siguientes relaciones:

  • En las versiones de VMs “standard“, los precios son exactamente iguales, con configuraciones llamativamente similares.
  • En las versiones “high memory“, es más barato Google (la mitad), aunque Amazon te da el doble de CPUs por una VM con la misma cantidad de memoria.
    Ej: Google te da 4 CPUs / 26 GB de RAM y Amazon en cambio te da 8 CPUs para su configuración de 26 GB de RAM. Dado que estamos en “high memory“, igualé a cantidad de memoria disponible para luego decir “Google es la mitad de barato”.
  • En las versiones “large” (“high cpu” de Google), Amazon es un 15% más caro para igual cantidad de CPUs, pero te da el doble de memoria en sus VMs.

Observaciones:

  • Se desprende de lo anterior Amazon EC2 ofrece perfiles más simétricos que Google comparando la relación de cantidades de CPU/Memoria. Puede ser útil para algunas aplicaciones o no, ya que va obviamente asociado al costo.
  • Amazon tiene configuraciones con más CPUs ya que llega a 32 CPUs y más memoria también: 244 GB; Google llega a 16 CPUs y 104 GB de memoria.
  • No comparé tamaños de almacenamiento, asumo que no tiene tanta relevancia para nuestra aplicación (se disponen de varias decenas de GB en disco en ambos).
  • Amazon dice que te incluye discos de estado sólido (SSD). Google te cobra ambos (?) 0,04 USD por GB/mes el disco estándar, 0,325 USD GB/mes el SSD.
  • Fundamental para la región en la que vivo: Amazon tiene Data Center en San Pablo (Brasil), Google no; sólo sirve VMs desde USA, Europa y Asia/Pacífico.
  • Amazon tiene diferentes tipo de instancias, en este caso comparé las “Bajo demanda” aka “Dedicadas” (según el lugar que se mire en la documentación), que son las más caras. Las otras son tipo prepagas (“Instancias Reservadas”), donde según entiendo, uno abona un importe fijo y después usa X cantidad de tiempo y se descuenta del fijo.
    Hay otros tipos de instancias pero no se ajustan a nuestro uso (“Instancias Puntuales” y “Instancias optimizadas para EBS”). En este apartado, pareciera que Amazon tiene largamente muchas más ofertas y más desarrollo del negocio que Google.

Bonus Track: versus Linode.com

  • Linode tiene hasta 20 CPUs / 96 GB RAM máximo [3].
  • Linode es mucho más barato que ambos; es más simple su tabla de precios y más “1 a 1″ la distribución de CPUs / RAM (4GB / 4CPUs, 8 GB / 6 CPUs, y así hacia arriba), además de que da bastante más storage en SSD.
    Por ejemplo, 4 GB / 4 CPUs en Linode: USD 0,06/hora (USD 40/mes), mientras que en Amazon estamos en USD 0,28/hora por 15GB / 4 CPUs o USD 0,105/hora por 3,75GB / 2 CPUs. Eso sí, Linode está en USA (Newark/Atlanta/Dallas/Fremont), Europa (Londres) y Asia (Tokio), no en Sudamérica.
  • Comparando Linode contra GCE:
    • 1 Linode (2 GB de RAM/ 2 CPUs / 3 TB transfer / 48 GB SSD): U$S 20/mes.
    • 1 GCE (1,70 GB RAM / CPUs “shared” (?) / 48 GB SSD): U$S 33.29/mes (no dicen si hay límite de transferencia).
  • A Linode lo conocemos los que estamos “en la pomada”, y hay casos en donde suena mucho mejor “lo tengo repartido en la nube de Amazon/Google”, nobleza obliga.

[1] http://aws.amazon.com/es/ec2/purchasing-options/dedicated-instances/
[2] https://cloud.google.com/products/compute-engine/
[3] https://www.linode.com/pricing

¿Sugerencias, comentarios?

Saludos

Categories: codear, linux, sysadmin, web Tags:

Migrando Host de VMs KVM de Ubuntu 12.04 a 14.04

Viernes, 16 de mayo de 2014 8 comentarios

En estos días arranqué la tarea de migrar Máquinas Virtuales de Hosts Ubuntu 12.04 (entorno QEmu-KVM/Libvirt) a Ubuntu 14.04, para testear que esté funcionando todo ok, y me encontré con dos particularidades:

1) Por defecto, las interfaces de red no se llaman más “ethX” ni se guían como antes con el archivo en /etc/udev/rules.d/70-net-persistent.rules, sino que ahora son medio raras (“p2p1″, “p5p4″, “eno1″, “enp2s0″, etc). Acá está explicado el por qué del cambio [1]. A priori no me gusta nada este cambio, por no respetar ninguna convención como sí lo hacía ethX, y encima por ser un cambio por defecto, pero como todo… supongo que me acostumbraré. Es adaptarse o morir; no es un capricho de Ubuntu, sino de udev.

2) ¡No hace falta más configurar un bridge en el host! Ahora se usa el driver de kernel macvtap [2][3][4][5], que uno lo selecciona en el administrador virt-manager. Así que para el host no habría que cambiar la configuración; para recordarlo, en un host Ubuntu 12.04 pasábamos de esto:

auto eth0
 iface eth0 inet static
 address 192.168.1.18
 netmask 255.255.255.0
 gateway 192.168.1.1
 dns-nameservers 192.168.1.1 192.168.1.2

a esto (cambia eth0 por br0, y las líneas de bridge):

auto br0
 iface br0 inet static
 address 192.168.1.18
 netmask 255.255.255.0
 gateway 192.168.1.1
 dns-nameservers 192.168.1.10 192.168.1.15
 bridge_ports eth0
 bridge_stp off
 bridge_fd 0
 bridge_maxwait 0

Ahora en Ubuntu 14.04 no hace falta tocar nada, ya que la interfaz principal sigue siendo la misma, aún cuando haya VMs que salgan directamente puenteadas por dicha interfaz. Lo que sí, por cada VM puenteada con el driver macvtap se va a crear una interfaz en el host, quedando así, digamos:

macvtap0 Link encap:Ethernet HWaddr 52:54:00:1e:b5:29
 inet6 addr: fe80::5054:ff:fe1e:b529/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
 RX packets:437 errors:0 dropped:0 overruns:0 frame:0
 TX packets:71 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:500
 RX bytes:36313 (36.3 KB) TX bytes:6617 (6.6 KB)

 p2p1 Link encap:Ethernet HWaddr 44:87:fc:ef:96:be
 inet addr:192.168.1.18 Bcast:192.168.1.255 Mask:255.255.255.0
 inet6 addr: fe80::4687:fcff:feef:96be/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
 RX packets:15346 errors:0 dropped:46 overruns:0 frame:0
 TX packets:16615 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:2096838 (2.0 MB) TX bytes:4714920 (4.7 MB)

Esto seguramente es más rápido que lo anterior, por diferentes motivos, pero tiene un lado feo, y es que de esta manera los guests no pueden comunicarse con el host [6]. Apliqué la “less painful solution” de esa wiki, y fue crear una red NAT aislada entre el host y sus guests, todo de manera gráfica desde virt-manager. Fue bastante simple, y aunque no me guste que tenga que haber una interfaz en el guest únicamente para comunicarse con el host, funciona bien y en mi caso esto es para necesidades muy puntuales (emergencia casi siempre).

En resumen, esto fue para darles un pantallazo de algunos de los cambios que vamos a tener que hacer cuando migremos a 14.04. Estos cambios también están en RHEL 7, ya que son todos cambios de proyectos upstream, así que no nos ahorramos este trabajo yendo para aquel lado tampoco.

[1] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
[2] http://seravo.fi/2012/virtualized-bridged-networking-with-macvtap
[3] http://virt.kernelnewbies.org/MacVTap
[4] http://libvirt.org/formatnetwork.html#examplesDirect
[5] http://www.linux-kvm.com/content/simple-bridged-networking-virt-manager-using-macvtap
[6] http://www.furorteutonicus.eu/2013/08/04/enabling-host-guest-networking-with-kvm-macvlan-and-macvtap/

Saludos!

Categories: codear, linux, sysadmin, ubuntu-ar, Uncategorized Tags:

FLISOL 2014 en Luján

Lunes, 7 de abril de 2014 Sin comentarios

El grupo de usuarios de Software Libre de la Universidad de Luján -UNLUX- invita a toda la comunidad a participar de la edición 2014 del FLISOL – Festival Latinoamericano de Instalación de Software Libre en la ciudad de Luján, a llevarse a cabo el día sábado 26 de abril, en concordancia con numerosas ciudades de Argentina y el continente. Las actividades se desarrollaran en la Sede Central de la Universidad Nacional de Luján (UNLu) a partir de las 13:00 hs.

Al igual que en ediciones anteriores, los integrantes del grupo instalarán Software Libre (GNU/Linux, Firefox, etc.) de forma gratuita y totalmente legal en los equipos informáticos que los asistentes acerquen al encuentro. Durante la ejecución del mismo se ofrecerán charlas informativas y técnicas sobre diferentes aspectos relacionados con el Software Libre.

Los invitamos a participar acercando sus equipos tanto para la instalación de Software Libre, la resolución de problemas sobre instalaciones existentes o simplemente para participar de una jornada distinta para intercambiar experiencias sobre Software Libre o compartir una tarde en un ambiente agradable.

Sobre el FLISOL

FLISOL 2014 en Luján
El Festival Latinoamericano de Instalación de Software Libre es un evento que se viene desarrollando de forma anual desde hace casi una década, donde se promueve el trabajo colaborativo ayudando a personas a conocer el mundo del Software Libre.
Está organizado por varios grupos de usuarios de los países involucrados congregados alrededor de esta iniciativa que reúne participantes de Argentina, Bolivia, Brasil, Chile, Colombia, Cuba, Ecuador, El Salvador, Guatemala, Honduras, México, Nicaragua, Panamá, Paraguay, Perú, Uruguay y Venezuela, entre otros. En Argentina ya está confirmada la realización de FLISOL en distintas ciudades.

El encuentro está dirigido a todas las personas que desean conocer más sobre software libre, instalarlo y usar sus computadoras preservando sus libertades, en condiciones de legalidad y sin estar preocupados por virus y otros problemas comunes del software privativo. Durante la jornada, se realizan instalaciones en forma totalmente gratuita, mientras que en paralelo se ofrecen diversas charlas de divulgación para promover el uso y la filosofía del Software Libre.

Cronograma de Charlas

El cronograma de charlas se está actualizando constantemente. Revisa los sitios flisol.info/FLISOL2014/Argentina/Lujan o www.unlux.com.ar para estar al tanto de las novedades.

Inscripción

Llenando este formulario, nos ayudas a estimar la asistencia de público y preparar mejor los espacios disponibles:
http://eventosimple.net/event/sp/publication/flisol-unlu/register

Sin embargo, la entrada es libre y gratuita, no es necesario registrarse para asistir a las charlas. Si pensás traer un equipo para instalar o configurar, por favor registrate y lee detenidamente las aclaraciones y datos al respecto.

Sobre el UNLUX

El UNLUX es un grupo de usuarios y entusiastas del Software Libre, que existe desde el 2005 y realiza sus actividades en el marco de la Universidad Nacional de Luján. Participa en el FLISOL desde el 2006, instalando y difundiendo diferentes ventajas de usar el Software Libre en el ámbito Educativo, Social, Técnico, Profesional y Personal.

Para conocer las vías de comunicación, podés empezar por www.unlux.com.ar y suscribirte a la lista de correo y el canal IRC.

En agenda

Categories: codear, linux, misceláneos Tags:

Cómo compartir un dispositivo serie por la red en Linux

Lunes, 27 de mayo de 2013 Sin comentarios

En el trabajo me encontré con la necesidad de utilizar un puerto serial (por ejemplo, un dispositivo con un adaptador USB/Serie en /dev/ttyUSB0, un módem 3G o una placa Arduino en /dev/ttyACM0, etc.) conectado físicamente a una máquina en mi red, que por diferentes motivos (distancia, pereza, lo que sea), lo quería acceder con un programa en mi máquina, pero como si fuera local.

Es decir, tenía un programa en mi máquina que usa pySerial para acceder al Arduino en /dev/ttyACM0, pero por diferentes motivos el Arduino está conectado en otra máquina de mi red y quería que, sin tocar mi programa, éste acceda al Arduino como si estuviera directamente conectado a mi PC, haciendo de alguna manera “transparente” la red que nos separaba. Por suerte lo pude resolver, y quizás esta herramienta y acercamiento sirva a más de uno para resolver algún otro problema similar.

Para esto vamos a utilizar la herramienta socat, que es como netcat pero para streams bidireccionales. Los pasos son:

  • Instalar socat (apt-get install socat), tanto en la máquina que tiene el dispositivo serie real (vamos a llamarlo “servidor”) como en el “cliente”.
  • Ejecutar en el servidor: “socat -d -d -d OPEN:/dev/ttyACM0 TCP4-LISTEN:31337″:
usuario@servidor:~$ socat -d -d -d OPEN:/dev/ttyACM0 TCP4-LISTEN:31337
2013/05/27 10:40:53 socat[2703] I socat by Gerhard Rieger - see www.dest-unreach.org
2013/05/27 10:40:53 socat[2703] I This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)
2013/05/27 10:40:53 socat[2703] I This product includes software written by Tim Hudson (tjh@cryptsoft.com)
2013/05/27 10:40:53 socat[2703] N opening character device "/dev/ttyACM0" for reading and writing
2013/05/27 10:40:53 socat[2703] I open("/dev/ttyACM0", 02, 0666) -> 3
2013/05/27 10:40:53 socat[2703] I socket(2, 1, 6) -> 4
2013/05/27 10:40:53 socat[2703] I starting accept loop
2013/05/27 10:40:53 socat[2703] N listening on AF=2 0.0.0.0:31337
2013/05/27 10:40:58 socat[2703] I accept(4, {2, AF=2 192.168.1.150:44624}, 16) -> 5
2013/05/27 10:40:58 socat[2703] N accepting connection from AF=2 192.168.1.150:44624 on AF=2 192.168.1.93:31337
2013/05/27 10:40:58 socat[2703] I permitting connection from AF=2 192.168.1.150:44624
2013/05/27 10:40:58 socat[2703] I close(4)
2013/05/27 10:40:58 socat[2703] I resolved and opened all sock addresses
2013/05/27 10:40:58 socat[2703] N starting data transfer loop with FDs [3,3] and [5,5]

Esto hace que socat abra el archivo /dev/ttyACM0 (el dispositivo serie a compartir), y además abra un socket en modo LISTEN (escuchando por conexiones) en todas las interfaces del equipo, particularmente en el puerto 31337. Las opciones -d -d -d son opcionales y sirve para habilitar los mensajes de debug.

  • Ejecutar en el cliente “socat -d -d -d TCP4:192.168.1.93:31337 PTY,link=/dev/ttyACM0″:
usuario@cliente:~$ socat -d -d -d TCP4:192.168.1.93:31337 PTY,link=/tmp/ttyACM0
2013/05/27 11:52:34 socat[8408] I socat by Gerhard Rieger - see www.dest-unreach.org
2013/05/27 11:52:34 socat[8408] I This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)
2013/05/27 11:52:34 socat[8408] I This product includes software written by Tim Hudson (tjh@cryptsoft.com)
2013/05/27 11:52:34 socat[8408] N opening connection to AF=2 192.168.1.93:31337
2013/05/27 11:52:34 socat[8408] I starting connect loop
2013/05/27 11:52:34 socat[8408] I socket(2, 1, 6) -> 3
2013/05/27 11:52:34 socat[8408] N successfully connected from local address AF=2 192.168.1.150:45293
2013/05/27 11:52:34 socat[8408] I setting option "symbolic-link" to "/tmp/ttyACM0"
2013/05/27 11:52:34 socat[8408] I openpty({4}, {5}, {"/dev/pts/4"},,) -> 0
2013/05/27 11:52:34 socat[8408] N PTY is /dev/pts/4
2013/05/27 11:52:34 socat[8408] I resolved and opened all sock addresses
2013/05/27 11:52:34 socat[8408] N starting data transfer loop with FDs [3,3] and [4,4]

Este comando hace que el socat de mi máquina se conecte a la IP 192.168.1.93 (allí debe estar el servidor), al puerto 31337, y que localmente lo haga ver como un nuevo dispositivo serial (pseudo terminal) creado por socat mismo en /dev/pts/X, y además haga un symlink de éste al archivo /tmp/ttyACM0. A partir de éste momento en /tmp/ttyACM0 existe un archivo que puede ser abierto con pyserial (por ejemplo, puede ser minicom, etc.) y ser utilizado como un dispositivo serie local.

Un detalle, cuando se cierra la conexión del socat en el cliente hacia el servidor, en el servidor también se termina la ejecución del socat (y viceversa), por lo que en caso de volver a establecer la sesión, es necesario ejecutar nuevamente en ambos equipos.

Saludos

Categories: codear, linux, programación, sysadmin Tags:

Novedades en SPDY/4, HTTP/2.0

Domingo, 26 de mayo de 2013 Sin comentarios

Si bien SPDY/4 todavía está en desarrollo, por lo que se deduce de este hilo y por lo que puede apreciarse en la forma que tienen ambos drafts, éste va a dejar de ser un trabajo separado de HTTP/2.0 como sucedía hasta la versión anterior, sino que será un protocolo que implementará progresivamente lo que se vaya definiendo y ganando adhesiones en la discusión que se está teniendo en el marco del IETF.

Es por esto que además de los cambios previamente definidos para SPDY/4, se le suma un “port” o “sincronización” de características definidas desde HTTP/2.0 hacia SPDY/4.  Los elementos que “se mudan” para desplazar a aquellos definidos en SPDY/3 cuentan con un relativo acuerdo general dentro del HTTPbis WG para ser parte de HTTP/2.0, y son:

  • SYN_STREAM, SYN_REPLY, HEADERS pasan a ser reemplazados por HEADERS+PRIORITY* y HEADERS. Ya había un frame de HEADERS en SPDY/3, pero no se usaban en casos comunes; ahora pasan a eliminarse los frames SYN_STREAM y SYN_REPLY, unificando todas las formas de envío de headers HTTP (ya sea para iniciar/responder peticiones) en el frame de HEADERS que ya existía (entiendo que sólo se le agrega un campo de prioridad). En resumen, en SPDY/4 (y en HTTP/2.0), las peticiones se pedirán y responderán con un frame de HEADERS.
  • Unificaron los frames de RST_STREAM y GOAWAY. Eran redundantes, claramente.
  • Después de ciertas pruebas (ejemplo)(**), ya está definido el magic byte para inicializar una conexión directamente en HTTP/2.0 (o SPDY/4): “FOO * HTTP/2.0\r\n\r\nBAR\r\n\r\n”. Pasando en limpio, la idea es que (en principio) haya 3 mecanismos de uso de HTTP/2.0:
    • Vía TLS+NPN, como SPDY/3. De todas maneras, NPN se envió hace unos meses al TLS WG y lo modificaron levemente, dándole forma a lo que se llama ALPN. Para el caso, hará lo mismo que NPN. Claro está, esto funciona sobre SSL/TLS (puerto 443), con sus pros y contras.
    • Si el servidor con el que hablamos no sabemos si soporta HTTP/2.0, se intentaría un upgrade mediante el mecanismo estándar de Upgrade de HTTP, como se hace con WebSockets (ejemplo). Esto funciona sobre puerto 80, en claro.
    • Si el servidor con el que hablamos sí sabemos de antemano que soporta HTTP/2.0, directamente se envía el magic byte luego de establecer la conexión TCP, para comenzar a intercambiar frames HTTP/2.0. La idea es ahorrar el tiempo (valioso) de upgrade. El magic byte está elegido en base a que si lo enviamos por equivocación a un server que sólo soporta HTTP/1.1, éste cause el cierre de la conexión inmediatamente.
    • Hay otras propuestas para ahorrarse el tiempo de upgrade sin saber de antemano si el server soporta 2.0, como publicar el soporte de HTTP/2.0 vía DNS (y así el navegador podría saber si el server habla 2.0 al momento de hacer la resolución DNS), pero por el momento la propuesta está en stand-by.
  • Incluirá control de flujo por stream (además del control de flujo por sesión de SPDY/3).
  • Un algoritmo de compresión de encabezados no basado en el stream completo de éstos, sino basado en cambios (diferencias entre los headers), para evitar los ataques del estilo CRIME. Sobre esto se está trabajando en el HTTPbis WG (principalmente por cosas como el requisito del mantenimiento de estado) y hay dos algoritmos con posibilidades (HeaderDiff y Delta). SPDY/4 incluiría este último.

*: Este frame está en discusión en estos momentos, quizá se defina un nuevo frame PRIORITY para soportar repriorización “al vuelo” de streams.
**: Es interesante comentar que en las pruebas de búsqueda del magic byte realizadas se intentó encontrar un stream de bytes que haga que la gran mayoría de web servers actuales que soporten HTTP/1.1 cierren la conexión inmediatamente o al menos devuelvan un código HTTP de error (4xx). La idea es que si un cliente envía ese stream de bytes, éste se asegure de una respuesta satisfactoria que asegure que el server es HTTP/2.0, y en caso contrario (por error, al suponer que el server soporta 2.0 pero no es así), el efecto producido en el server (y en la comunicación en sí) sea el mínimo posible.

Vamos a ver cómo evoluciona, y si SPDY/4 se hace “estable” en un futuro próximo para poder ir haciendo pruebas. Pero parece ser claro que va a ser bastante diferente a SPDY/3.

Saludos

Categories: codear, sysadmin, web Tags: