Saltar al contenido

Redes

Servicio CloudFare en aodbc.es

Durante esta semana (y quizás la próxima) es posible que experimentéis o hayáis sufrido algún tipo de lentitud o fallo a la hora visitar este blog. El motivo es que estoy evaluando la posibilidad de usar CloudFare para gestionar los dominios aodbc.es y aodbc.com.

Logo CloudFare

¿Qué es CloudFare?

Es una compañía que nos ofrece varios servicios, en distintas modalidades (una de ellas Free) que puede ser muy interesante para usuarios particulares e incluso empresas.

Las funcionalidades que nos ofrece CloudFare (dependerá del plan contratado, así que por favor chequea en su web que incluye cada plan y su coste) son:

  • Gestión DNS
  • Cacheo y uso de su red CDN para mejorar accesos por distribución geográfica
  • Protección frente ataques (incluso en la versión Free ofrece una protección básica)
  • Optimización de htmls, imagenes, javascript, etc. para reducir tiempos de carga

¿Por qué te metes en estos líos?, ¿lo necesitas?

Afortunadamente el servicio que tengo contratado es suficiente par manejar el tráfico actual de aodbc.es y aodbc.com sin necesidad de aditivos o ayudas, pero que lo voy a hacer, lo llevo en el ADN, tengo que probar cosas y ver que pueden aportar.

La experimentación junto con la observación, es una de las mejores maneras de aprender 😉

¿Y funciona?

En clientes importantes (con planes comerciales contratados) el resultado ha sido francamente bueno, así que quería ver que podría hacer CloudFare por mí.

La respuesta es sí, funciona bastante bien y puede ahorraros una gran cantidad de ancho de banda, a continuación os dejo algunos ejemplos para el dominio aodbc.es:

CloudFare_Cache

 

CloudFare Performance

 

Un consejo:

 

Si os animáis a probar el servicio, no os pongáis a activar todas las funcionalidades de optimización que os ofrece como locos, ya que seguramente tendréis algún efecto no previsto (normalmente algún tipo de ralentización) y no sabréis acotar que opción lo ha provocado. Activarlas de una en una y dejad un tiempo prudencial para observar el comportamiento, hasta que tengáis vuestra configuración optima.

En mi caso he sufrido ralentización durante algunos periodos y he notado que he perdido tráfico (debido a la carga lenta de la página) en algunos periodos tras activar alguna optimización que provocaba problemas con mi wordpress.

 

Espero os haya resultado de interés y os animo a explorar las posibilidades que este y otro tipo de servicios pueden ofreceros.

Os veo en el siguiente post.

 

Cables submarinos, las autopistas del océano

Con un volumen de tráfico creciendo de manera exponencial desde años y con cada vez más acceso por parte de ciudadanos de todo el mundo a las autopistas de la información, el tendido (y explotación) de cables submarinos se ha convertido en un lucrativo negocio, prueba de lo cual es su imparable proliferación.

 

Existen varias webs donde puedes consultar los cables existentes y su capacidad, por ejemplo aquí, pero recientemente he encontrado un mapa que me parece muy interesante por su aspecto visual, de cara a incorporarlo en presentaciones, demos, etc.

 

Mapa cables submarinos

<Fuente original aquí>

Web Scale conceptos de arquitectura

Web-Scale es uno de esos conceptos que utilizamos habitualmente en Arquitectura de Sistemas y que de un tiempo a esta parte escuchamos con más asiduidad, pero ¿qué es exactamente?.

Web Scale nube de palabras

Definición de Web Scale:

 

Utilizamos este termino para indicar que un determinado servicio o arquitectura debe poder escalar con facilidad y rapidez para atender a un gran número de usuarios.

El termino “web” se usa ya que es en está tecnología o ámbito donde con más frecuencia los sistemas deben ser Web-Scale, pensemos por ejemplo en servicios como Facebook, Gmail, etc. que no paran de crecer o en páginas web que deben poder aumentar su capacidad para atender picos de usuarios.

 

Se trata por tanto de una nueva forma de diseñar nuestros sistemas, teniendo en cuenta no solo los aspectos tradicionales como:

  • Diseño modular
  • Seguridad
  • Interoperatividad
  • etc.

a partir de ahora nuestros sistemas deben estar preparados para afrontar el reto de convertirse en un Facebook, Twitter o similar sin morir de éxito 🙂

 

Los problemas de escalado:

En realidad no es nada fácil diseñar sistemas que soporten el reto del Web-Scale, implica conocimientos avanzados de múltiples tecnologías y engloba no solo a la arquitectura de sistemas, también al propio diseño de las aplicaciones (fase de desarrollo). Diseñar una aplicación determinada que soporte 10 usuarios concurrentes es muy sencillo, si subimos a 100 empezaremos a encontrar algún problemilla, si pasamos 1000, 10.000……… solventar esa problemática es el origen del Web Scale.

 

 

Big Switch’s llega a un acuerdo con HPE

Big Switch’s comercializa tecnología de software-defined networking (SDN) y recientemente a llegado a un acuerdo con HPE para equipar algunos de los switches SDN con su tecnología, en un acuerdo similar al que ya tiene con DELL.

Switch HPE Altoline

<Switch HPE Altoline cortesía de HPE>

 

Es un movimiento muy interesante, porque poco a poco están ganando cuota de mercado.

SDN & NFV, ¿quién es quién?

SDN y NFV son dos de las palabras que surgen en toda discusión (actual) sobre arquitecturas de red. Están de moda y por tanto parece que abordar una nueva arquitectura de red (independientemente del tamaño o necesidades) sin tan si quiera plantearlo es poco menos que un pecado mortal, pero realmente ¿tenemos claro que es SDN y que NFV?, ¿que ventajas e inconvenientes podemos obtener de la adopción de estos modelos?.

Mi intención con esta entrada es dar una pequeña introducción de que es SDN y NFV, si eres un arquitecto de sistemas/redes acostumbrado a grandes despliegues, posiblemente este post no es para ti ;-).

 

SDN:

En las redes tradicionales, la inteligencia o capacidad de configuración y control se aplicaba a nivel de cada dispositivo, es decir, la configuración de un switch se hacía en el propio switch y esta era más o menos aislada de la del resto de dispositivos que le rodeaban.

Con SDN se pretende desacoplar/separar el plano de control de los dispositivos del propio dispositivo, de tal manera que este puede ser transferido a un elemento “controlador”.

 

sdn

<original de la imagen, aquí>

Algunas preguntas interesantes sobre SDN

 

¿Se pueden definir redes SDN multi-vendor? => Sí, siempre que nos basemos en estándares abiertos. El más popular es OpenFlow.

¿Se pueden controlar múltiples dispositivos desde una misma controladora? => Sí, es una de las cosas más interesantes que aporta SDN, la simplificación de redes complejas y la posibilidad de gestionar todos los dispositivos desde un único punto.

¿Permite configuraciones multi-tenant?=> Of course

¿Es apta para despliegues cloud?=> Nació entre otras cosas para solucionar los problemas derivados de los grandes despliegues cloud.

 

NFV:

NFV es una iniciativa para virtualizar las funciones de red, de tal manera que se reduzca la cantidad de HW necesaria, pero…¿qué es exactamente una función de red?.

Entendemos por funciones de red aquellas tales como Routing, switching, balanceo de carga, Firewall, etc., etc.

Algunas preguntas interesantes sobre NFV

¿Es SDN lo mismo que NFV? => No,SDN se puede apoyar sobre dispositivos físicos o virtuales y su principal objetivo es optimizar el funcionamiento de la red y de su gestión. NFV, tiene entre sus objetivos, reducir la cantidad de HW necesario.

¿Pueden trabajar juntas SDN y NFV? Sí, en arquitecturas modernas y de un cierto tamaño es habitual cierto grado de integración entre ambas.

¿Qué es mejor SDN o NFV?=> Son complementarias, pueden usarse de manera individual o conjunta dependiendo de nuestras necesidades

 

Espero os resulte de interés y utilidad esta entrada, que intentare completar con una individual que trate con más detalles tanto SDN, como NFV.

Fortigate 30D configuración de VLANs

Continuando con el artículo anterior de configuración de un Forti 30D para uso en homelab, os dejo a continuación como configurar VLANs.

fortigate-30d-frontal

Si recordáis en el artículo anterior explicaba como romper el switch que agrupaba los 4 interfaces LAN, para disponer de 4 interfaces individuales con capacidad de filtrado y Routing. Esto ya es una mejora sustancial con respectoa las funcionalidades que Fortinet penso darnos con este equipo, pero seguía faltando algo fundamental… la configuración de VLANs.

Si recorremos los menus de la web y las opciones de los interfaces veremos que no es posible configurar estas opciones, por lo que deberemos recurrir a la cli.

FWF30D # config system interface

FWF30D (interface) # edit vlan_dmz

FWF30D (vlan_dmz) # set interface lan2

 

FWF30D(vlan_dmz) # set type vlan

 

FWF30D (vlan_dmz) # set vlanid 2

 

FWF30D (vlan_dmz) # set mode static

 

FWF30D (vlan_dmz) # set ip 192.168.xxx.yyy 255.255.255.0

 

FWF30D(vlan_dmz) # set allowaccess https ping ssh

 

FWF30D (vlan_dmz) # next

de esta manera tan sencilla veremos como en los interaces ya nos aparecen en la web

forti_vlan_1

 

y con esto si que tenemo sun equipo mucho más operativo para nuestro Homelab.

 

Espero que os resulte de utilidad.

Open Switches y Bare Metal Switches, ¿son lo mismo?

Este es una pregunta que me han hecho en más de una ocasión y es que hoy en día es rara la semana que no tenemos alguna noticia referente a este tipo de dispositivos, unas veces los llaman Open Switches, otras Bare Metal Switches, pero, ¿son lo mismo?. Tengo que decir que no he encontrado definición “formal” de los mismos, por lo que la siguiente explicación se basa en mi experiencia (y por tanto puede estar equivocada en su totalidad o en parte :-))

Switch_Dell_Bare_Metal

<Switch Dell Bare Metal>

Open Switches:

En esencia un Open Switch es un Switch en el cual Hardware y el Software se desacoplan, de manera que podríamos correr cualquier software (diseñado para ese switch) o a la inversa, podríamos instalar el software en distintas plataformas hardware (soportadas).

Bare Metal Switches:

Al igual que los Open Switch, separan el plano de software y Hardware de manera que un mismo dispositivo puede correr varias versiones distintas de software y un mismo software puede correr en distinto hardware

¿Entonce son lo mismo?

No, la diferencia radicaría en el termino “Open”, en un Open Switch el HW debería cumplir estándares y diseño abierto (un ejemplo de esto es el Open Compute Project), en un Bare Metal no tiene porque ser así. Podemos encontrar por ejemplo Switches de Dell y de otros fabricantes comerciales que cumplirían el requisito Bare pero no el Open

¿Qué son las VXLAN?

Con la proliferación de instalaciones del algún tipo de cloud (publico, privado o Hybrido) e independientemente de la tecnología o fabricante usado, empezamos a escuchar con asiduidad términos que si bien quedan fueran del día a día de much@s, os pueden aparecer en cualquier momento, sobre todo si como digo, trabajáis en entornos Cloud.

Como podéis suponer VXLAN, tiene algún tipo de relación con VLAN, es más VXLAN nace entre otras cosas para dar respuestas a una de las limitaciones de VLAN, concretamente al del Nº máximo de VLANs permitidas.

 

¿Cual es el Nº máximo de VLANs que pueden configurarse?

Aunque estamos tentado de contestar, “depende del switch..”, aquí nos remitiremos al estándar de IEEE  802.1q que fija el Nº máximo de VLANs permitidas en 4096.  Lo que significa que en una red basada en este estándar, ese será el ma´ximo Nº de segmentaciones o VLANs que podríamos crear.

vlan-8021q

 

como podéis ver en la imagen anterior (fuente de la imagen aquí), tenemos 12 bits para identificar la VLAN (4096)

 

4096 son muchas, ¿verdad?

Pues si, la verdad que 4096 son más que suficientes para la inmensa mayoría de redes, pero no para una minoría. Si pensamos por ejemplo en los grandes actores de CLoud con miles y miles de clientes, veremos que 4096 quizás no son suficientes, hace falta algo más y ese algo más es VXLAN.

 

¿Que es VXLAN?

VXLAN (RFC7348) no es ni más ni menos que llevar la tecnología de virtualización a la segmentación de red ofreciendo VLAN-like encapsulation, es decir usaremos las mac para encapsular el tráfico sobre paquete UDP en layer 4 y producir algo similar a una VLAN. El máximo teórico de segmentación es  de 16 millones de redes.

¿Quienes son los padres de la criaturita?

A día de hoy están todos los grandes pero en su momento fueron VMware, Arista y Cisco los creadores, posteriormente se unieron Huawei, Dell, Mellanox, RedHat, etc, etc.

vxlan

<original de la imagen aquí>

¿Necesito tener claro la diferencia entre VLAN y VXLAN?

Si eres un usuario estándar con curiosidad por las redes y sistemas, probablemente no necesites saberlo. Si trabajas en IT en niveles de soporte bajo/medio, probablemente sea suficiente con que hagas algún tipo de analogía VLAN=VXLAN pero más grande, ahora bien, si pretendes dedicarte a la arquitectura de sistemas de una manera más o menos profesional, deberías tener claro que es cada cosa y el porque de ellas. Ten en cuenta que cada vez caminamos más hacia el Datacenter definido por software y este es un paso más.

Ethernet 5GBase-T, Larga vida al rey

Que ethernet sobre cables de cobre es una parte fundamental de las redes Lan actuales nadie lo duda (a pesar de la proliferación del Wifi), pero es cierto que de un tiempo a esta parte el voraz apetito de ancho de banda estaba haciendo que cada vez más estuviese contra las cuerdas. La aparición de 10Gbps Base-T fue un balón de oxigeno para esta tecnología, pero parecía que el chicle no se podía estirar mucho mas.

ethernet

Si bien en los backbone veíamos velocidades de 10,40 y 100Gbps con normalidad (gracias a la fibra óptica), el puesto de usuario estaba condenado a velocidades de 1Gbps, en parte por el cableado existente, en parte por la electrónica de de los equipos, siendo la única solución actualizar el equipo (si lo permitía), con adaptadores de 10Gbps y aún así esto no siempre era posible por el cableado existente.

 

Las realidad es que las redes cableadas al puesto de usuario son costosas de actualizar, lo que provoca que prácticamente cualquier edificio con unos años tenga sus redes en Categoría 6 o 5E . Con ese panaroma atender la demanda de ancho de banda en el puesto de usuario es una misión complicada…o lo era.

 

categoria_cableado_ethernet

 

El IEEE acaba de aprobar el nuevo estándar que permitirá alcanzar velocidades de 2.5 y 5Gbps sobre cableado 6 (e incluso 5E) en distancias de hasta 100m. Obviamente tendremos que actualizar nuestra electrónica de red, pero al menos será un balón de oxigeno para todas aquellas instalaciones de datos que por un motivo u otro han quedado desactualizadas.

 

Podéis leer el anuncio del IEEE aquí.

 

Jumbo Frames, ¿qué son y donde usarlas?

Diseñando con uno de nuestros clientes su nueva arquitectura de servidores/virtualización y almacenamiento, le han surgido una serie de dudas sobre el uso de Jumbo frames. En realidad es un tema, que aunque sencillo, no es muy conocido y es habitual ejemplos de uso (o no) inadecuado.

Un poco de teoría:

La mayoría de nuestras redes a nivel de CPD se construyen sobre los protocolos ethernet para L2 e IP para L3.

modelo OSI

 

el tamaño de trama por defecto para ethernet es de 1500bytes (fijaos que digo trama y no paquete. En ethernet lo que se transmiten son tramas de datos y en IP paquetes que a su vez se alojaran en las tramas ethernet). Este valor, que es modificable, es lo que convierte una trama ethernet normal en un Jumbo Frame cuando ampliamos su tamaño.

 

Es importante remarcar que las Jumbo Frames, están fuera del estándar 802.3 que define ethernet. El tamaño máximo es de 9.000Bytes

 

¿Debo usar Jumbo Frames en mi red?

Pues depende… activar el uso de Jumbo Frames reduce la carga de gestión de las tramas y paquetes (si paquetes ip también, luego veremos la razón) y puede mejorar el rendimiento a la hora de transferir grandes volúmenes de información, (por eso las SAN son escenarios donde usar Jumbo Frames), por contra aumentan la latencia de la red (especialmente en redes lentas).

En general se puede decir que el uso de Jumbo Frames mejora la eficiencia de nuestra red.

Eficiencia_Jumbo_Frames

<Fuente Wikipedia>

Lo que no debes hacer bajo ningún concepto es mezclar dispositivos con Jumbo Frames activos y otros desactivos, eso es una fuente potencial de problemas.

 

¿Entonces por qué no las usa todo el mundo?

Fundamentalmente porque no toda la electrónica de red (sobre todo la antigua) la soporta. El aumento de tamaño de trama reduce el nº de tramas a transmitir, pero al ser estas de mayor tamaño también se incrementa el esfuerzo necesario para calcular los CRC y esto puede tener un impacto importante en el rendimiento de nuestra red. También es necesario ampliar la cantidad de memoria asiganada a los buffers de los dispositivos de red.

Como comentaba unas lineas más arriba, no debemos mezclar dispositivos con y sin Jumbo Frame activo, esto limita su uso a redes donde nos podemos permitir que todos los dispositivos lo tengan activo. Un ejemplo de este tipo de redes serían las redes de almacenamiento SAN (iSCSI). Para otro tipo de redes el estándar sigue siendo 1500, después de todo no es casualidad que todos los S.O. vengan configurados con una MTU de 1500 (El que la MTU de S.O. y el tamaño de trama coincidan, aumentan la eficiencia del uso de la red).

 

¿Hay alguien pensando en tamaños distintos a las Jumbo Frames?

La respuesta es sí. Ya podemos encontrar al menos:

  • Baby Jumbo Frames: son más pequeñas que las Jumbo (en realidad solo un poco más grandes que las ethernet) y se usan en entornos de carrier encapsuladas en protocolos como MPLS.
  • Super Jumbo Frames: esto como imagináis va de grande, porque grande es mejor. 64.000Bytes

 

¿Tiene aplicación a la virtualización?

Por supuesto, ya os comentaba antes que las redes SAN basadas en iSCSI son un escenario claro para el uso de Jumbo Frames.

¿VMware soporta Jumbo Frames?

Si, os enseñare a configurarlo en un próximo artículo.