Mostrando entradas con la etiqueta red. Mostrar todas las entradas
Mostrando entradas con la etiqueta red. Mostrar todas las entradas

miércoles, 17 de octubre de 2018

Cloud NAT [Nuevo servicio en Google Cloud]

cloud_NAT.png 


En Google Cloud español nos hacemos eco de que  hace unos días, se anuncio la versión beta del servicio servicio Cloud NAT totalmente gestionado.
 

Los usos del "Cloud NAT"


Cuando coloca una aplicación detrás de una puerta de enlace NAT en el Cloud, puede acceder a Internet (para actualizaciones, parches, administración de configuración y más) de una manera controlada y eficiente, pero los recursos externos no pueden acceder directamente a esas instancias. Esto ayuda a mantener sus VPC de Google Cloud más aisladas y seguras.
Cloud NAT ofrece una serie de ventajas en comparación con otras ofertas de NAT:
  • Como una solución definida por software sin un proxy central administrado, Cloud NAT ofrece un diseño  que es altamente confiable, de alto rendimiento y escalable.
  • Cloud NAT es compatible con las máquinas virtuales (VM) de Google Compute Engine y con el motor de Google Kubernetes (contenedores).
  • La capacidad de configurar múltiples direcciones IP de NAT por puerta de enlace NAT le permite escalar según el tamaño de su red sin tener que agregar o administrar otra puerta de enlace NAT.
  • Los modos Manual y Automático para la asignación de IP NAT le permiten ajustar según sus requisitos específicos.En modo manual proporciona un control total al especificar IP, y en modo Automático permite que las IP de NAT se asignen y escalen automáticamente según el número de instancias.
  • Ajuste los valores de timeout del NAT.
  • NAT todas las subredes en una VPC para una región a través de una única puerta de enlace NAT, independientemente del número de instancias en esas subredes.
  • Alta disponibilidad regional incluso si una zona no está disponible.

Los primeros usuarios de Cloud NAT están implementando y presenta un correco funcionamiento dentro de sus implementaciones existentes de Google Cloud.


NAT  chokepoint, definido por software

Chokepoint-free.png

 
Cloud NAT es un servicio totalmente administrado, definido por software, no una solución basada en instancias o dispositivos. Esto difiere de las soluciones de proxy NAT tradicionales porque no hay proxies intermedios NAT en la ruta desde la instancia hasta el destino. En su lugar, a cada instancia se le asigna una IP NAT junto con una asignacion del rango de puerto asociado. Esta IP asignada y el rango de puertos está programado por nuestra pila de virtualización de red de Andrómeda en la instancia y luego la instancia lo utiliza para realizar NAT.

La implementación de Cloud NAT, es similar a nuestros cortafuegos, se distribuye sin ningún punto de estrangulamiento en la ruta entre su instancia interna y su destino externo. Este enfoque ofrece una mayor escalabilidad, rendimiento, rendimiento y disponibilidad para Cloud NAT.

Modos de asignación de IP NAT


Cuando se diseño el modelo de asignación de IP de Cloud NAT, por peticion de los clientes que apuntaban a  la capacidad de configurar las IP de NAT estáticas y especificadas manualmente es esencial para que puedan abrir firewalls para estas IP de NAT en los servidores externos. Tambien se puede  escalar automáticamente las IP de la nube como lo hacen nuestros balanceadores de carga.

Por eso se puede ofrecer dos opciones para la asignación de IP NAT:
  •     Podemos usar la asignación automática de direcciones IP mediante una puerta de enlace NAT: GCP asigna automáticamente las direcciones IP de NAT y las ajusta automáticamente en función del número de máquinas virtuales. Esta es la mejor manera de garantizar que haya suficientes IP disponibles para NAT. Tenga en cuenta que con este método, las IP de la lista blanca en el lado receptor se ajustan peor  porque algunas IP se liberan cuando ya no son necesarias.
  •     Configure una (s) IP (s) NAT específica (s) para ser utilizadas por una puerta de enlace NAT: En este caso, debe especificar manualmente una o más IP de NAT para que la puerta de enlace NAT las utilice. Estas direcciones IP deben ser reservadas y estáticas, y no se realiza una autoasignación de direcciones IP. Se prefiere este modo si necesita incluir en la lista blanca las direcciones IP de NAT en el lado receptor. Tenga en cuenta que si no hay suficientes IP NAT para realizar NAT para todas las instancias requeridas, entonces algunas de estas instancias no podrán usar NAT. Recibirá un mensaje de registro cuando se requieran más direcciones IP de NAT.

Creando una puerta de enlace NAT en su VPC


Para configurar una puerta de enlace NAT en su entorno. Echemos un vistazo a un ejemplo.

Digamos que tiene una red GCP que contiene tres subredes en dos regiones:
    us-este1
        subred 1 (10.240.0.0/16) y subred 2 (172.16.0.0/16)
          europa-oeste
                subred 3 (192.168.1.0/24)

Las máquinas virtuales en la subred 1 (10.240.0.0/16) y la subred 3 (192.168.1.0/24) no tienen direcciones IP externas, pero necesitan obtener actualizaciones periódicas de un servidor externo al 203.0.113.1. Las máquinas virtuales en la subred 2 (172.16.0.0/16) no necesitan obtener estas actualizaciones y no se les debe permitir conectarse a Internet en absoluto, incluso con NAT.

VMs in subnet.png
 
Para lograr esta configuración, primero configure una puerta de enlace NAT por región, por red:

   1. Configure NAT-GW-US-EAST para la subred 1 (10.240.0.0/16).

   2. Configure NAT-GW-EU para la subred 3 (192.168.1.0/24).

   3. Configure cada puerta de enlace NAT con la (s) subred (s) para la cual debe traducir el tráfico:

        subred 1 (10.240.0.0/16) para NAT-GW-US-EAST

        subred 3 (192.168.1.0/24) para NAT-GW-EU

   4. No configure NAT para la subred 2. Esto lo aísla de Internet, como lo requiere este ejemplo.

Para obtener información detallada sobre cómo configurar Cloud NAT, puede ver las configuraciones de Cloud NAT para Google Compute Engine y Google Kubernetes Engine aquí.

Cloud NAT para GKE

Puede usar Cloud NAT para los contenedores de Kubernetes de Google (GKE) configurando Cloud NAT a NAT-traducir todos los rangos en la subred.


GKE.png

Tanto los nodos como los pods pueden usar Cloud NAT. Si no desea que los Pods puedan usar NAT, puede crear una Política de red de clústeres para evitarlo.

En el ejemplo anterior, se permite que sus contenedores se traduzcan a NAT. Para habilitar NAT para todos los contenedores y el nodo GKE, debe elegir todos los rangos de IP de la subred 1 como candidatos de NAT. No es posible utilizar NAT solo para container1 o container2.

Precios y disponibilidad

Cloud NAT está disponible en todas las regiones de Google Cloud, y durante el período beta, lo ofrecemos de forma gratuita. Una vez que Cloud NAT está disponible en general (GA), cada puerta de enlace tiene el precio siguiente:
  •     A partir de $ 0.045 por hora de puerta de enlace NAT
  •     Cargos de procesamiento de datos NAT

Además, los costos de transferencia de salida para mover datos entre una instancia de GCP e Internet permanecen sin cambios. Para obtener más información, lea acerca de los precios de NAT de la nube aquí.

Prueba Cloud NAT

Hemos estado ocupados ofreciendo capacidades como Cloud NAT para hacer que sus cargas de trabajo y servicios de Google Cloud sean fáciles de implementar y administrar. Lea  la documentación en línea de Cloud NAT y comience con una implementación de muestra utilizando nuestro ejemplo de Cloud NAT. También nos encantaría recibir sus comentarios, puede contactar en gcp-networking@google.com.

lunes, 5 de marzo de 2018

Google cloud y La "Zona Andrómeda" O como controlar un ataque DDOS

Hoy  en google cloud español nos hemos preguntado como estamos de protegidos en Google Cloud ante un ataque DDOS.


Esta semana hemos sido informados toda la comunidad de como GitHub ha sufrido uno delos últimos ataques de DDOS, que por otro parte han sabido gestionar. Tienes mas información aquí o aquí. El ataque brutal de 1,35Tbs que fue repelido por  GitHub.



Por este motivo me pregunto como estamos ante ataques de este tipo si estamos con google cloud, y la respuesta es: Entramos en la Zona Andrómeda.

Dentro zona de Andrómeda: la última pila de redes de Google Cloud Platform.
La última tecnología de red que impulsa nuestros servicios internos a disposición de los usuarios de Cloud Platform en todo el mundo.

Andromeda, el nombre clave de la pila de virtualización de red de Google, ahora activa dos zonas de Google Compute Engine. Los clientes  verán automáticamente un mayor rendimiento en el rendimiento a través de nuestras conexiones de red rápidas.

Los desafíos de redes introducidos por la virtualización. Ofrecer el más alto nivel de rendimiento, disponibilidad y seguridad requiere la organización a través de máquinas virtuales, hipervisores, sistemas operativos, tarjetas de interfaz de red, conmutadores de rack, switches de fabric, enrutadores fronterizos e incluso nuestro extremo de peering de red.

En google cloud tienen   una posición única para aprovechar el control y la experiencia de Google sobre todo el hardware, el software, la LAN y la WAN para ofrecer una experiencia perfecta para los clientes de Cloud Platform.

En Googlec loud , nos beneficiamos de tener acceso programable a toda la pila de red, desde el hardware de nivel más bajo hasta los elementos de software de más alto nivel. En lugar de forzarnos a crear soluciones comprometidas basadas en los puntos de inserción disponibles, podemos diseñar soluciones integrales seguras y eficaces mediante la coordinación en toda la pila.

Andromeda es un sustrato basado en Software Defined Networking (SDN) para nuestros esfuerzos de virtualización de red. Es el punto de orquestación para el aprovisionamiento, la configuración y la administración de redes virtuales y el procesamiento de paquetes dentro de la red. La siguiente figura de mi presentación muestra la arquitectura de alto nivel de Andrómeda:

El objetivo de Andromeda es exponer el rendimiento sin procesar de la red subyacente a la vez que se expone la virtualización de funciones de red (NFV). Exponemos el mismo procesamiento dentro de la red que permite que nuestros servicios internos se escalen y permanezcan extensibles y aislados para los usuarios finales. Esta funcionalidad incluye protección de denegación de servicio (DDoS) distribuida, equilibrio de carga de servicio transparente, listas de control de acceso y firewalls.

Hacemos esto al mismo tiempo que mejoramos el rendimiento, con más mejoras por venir.
Por lo tanto, Andrómeda en sí no es un producto de red de Cloud Platform; más bien, es la base para brindar servicios de red de Cloud Platform con alto rendimiento, disponibilidad, aislamiento y seguridad. Por ejemplo, las reglas de cortafuegos, enrutamiento y enrutamiento de Cloud Platform aprovechan todas las API internas y la infraestructura de Andromeda.


Presenta  varios escenarios, como la publicación de equilibrio de carga de Google Compute Engine 1M RPS previamente descrita. También presenta mejoras en el rendimiento de transmisión TCP en Google Compute Engine (GCE), la más notable de las cuales fue una mejora significativa de la latencia, el rendimiento y la sobrecarga de la CPU a nivel de red. Si bien estas mejoras conducirán a algunos de los mejores rendimientos de red disponibles en la industria,.

Andromeda permite Cloud Platform exponer cada vez más el rendimiento de la infraestructura de red sin procesar de Google a todas las máquinas virtuales (VM) de GCE.

Algunas de las mejoras más valiosas permiten que las máquinas virtuales incorporadas al soporte de kernels de Linux exploten las capacidades de descarga / multi-cola.

Animo a los clientes interesados ​​a crear nuevas máquinas virtuales GCE utilizando la imagen de backports de Debian. Esta imagen tiene los últimos controladores necesarios para lograr el mejor rendimiento.
Para mostrar la magnitud del despliegue de mejoras, el equipo de Cloud Platform realizó una serie de experimentos de rendimiento. Un benchmark evaluó el rendimiento utilizando netperf TCP_STREAM en la misma zona GCE. Al comparar el rendimiento de línea base (antes de Andrómeda) con Andrómeda, podemos destacar los beneficios de la arquitectura de Andrómeda.


Andromeda es una nueva versión de la arquitectura de virtualización de red subyacente, y su núcleo SDN permite iterar rápidamente y ofrecer nuevas funcionalidades. Esto asegura que la red de Cloud Platform continuará siendo un agente de interrupción de la computación en nube en el futuro.

jueves, 18 de enero de 2018

Google Cloud mucho mas que unos datacenter

Hoy en google cloud en español.




Google anuncia que ha instalado un nuevo cable submarino "Curie",

Google Cloud Platform (GCP) está disponible en dos nuevas regiones: Fráncfort y São Paulo. GCP cuenta con 12 regiones, 36 zonas, más de 100 puntos de presencia y una red mundial bien aprovisionada con cientos de miles de kilómetros de cable de fibra óptica.

Puntos de presencia perimetrales (PoP)

Lod puntos de presencia (PoP) extremos son los que conectamos la red de Google con el resto de Internet a través de la interconexión. Estamos presentes en más de 90 intercambios de Internet y en más de 100 instalaciones de interconexión en todo el mundo.


Nodos de borde (Google Global Cache o GGC) [Edge nodes]

Los nodos de borde (llamados Google Global Cache, o GGC) representan el nivel de la infraestructura de Google más cercano a nuestros usuarios. Con nuestros nodos de borde, los operadores de red y los proveedores de servicios de Internet implementan los servidores suministrados por Google dentro de su red.



El contenido estático que es muy popular entre la base de usuarios del host local, incluidos YouTube y Google Play, se almacena temporalmente en caché en los nodos de borde. Los sistemas de gestión de tráfico de Google dirigen las solicitudes de los usuarios a un nodo de borde que proporcionará la mejor experiencia.

En algunos lugares, también utilizamos nuestros nodos de borde para admitir la entrega de otros servicios de Google, como la Búsqueda de Google, mediante el tráfico de proxys, que ofrecerá un mejor rendimiento de extremo a extremo para el usuario final.

Mira otros mapas de la red global de infraestructura de Google aquí y aquí.

martes, 29 de agosto de 2017

Niveles de servicio de red [Tiers]

Introducción a los "Niveles de Servicio de red" [Tiers].

Desde Google Cloud Networking nos anuncian Network Service Tiers Alpha, convirtiendo Google Cloud Platform (GCP) en la primera nube pública principal en ofrecer una red con políticas de servicio "Tiers". Para optimizar el rendimiento eligiendo Premium Tier, que utiliza la red global de Google con una calidad de servicio sin precedentes y optimiza el coste, utilizando el nuevo nivel , ademas nos han ajustado el precios con un rendimiento comparable al de otras nubes públicas.

"En los últimos 18 años, en Google han  construido la red más grande del mundo, que en algunos casos ofrece el 25-30% de todo el tráfico de Internet", dijo Urs Hölzle, SVP Technical Infrastructure de Google. "Ponemos a su disposición de la misma infraestructura que Premium Tier. Puede elegir, es posible que prefiera una alternativa más barata y de menor rendimiento.Con las políticas de servicio de red, puede elegir la red adecuada para cada aplicación ".

Potencia del nivel superior

Si utiliza Google Cloud  ya utiliza el potente nivel superior. Premium Tier ofrece tráfico a través de la red global altamente confiable de Google, bien provista y de baja latencia. Esta red consta de una extensa red privada global de fibra con más de 100 puntos de presencia (POPs) en todo el mundo. Mediante esta medida, la red de Google es la más grande de cualquier proveedor de cloud público.





En la opción Premium Tier, el tráfico entrante de tu usuario final a tu aplicación en Google Cloud entra en la red privada de alto rendimiento de Google en el POP más cercano a tu usuario final y GCP entrega este tráfico a tu aplicación a través de su red privada.


Envío de tráfico entrante y saliente

Del mismo modo, GCP entrega tráfico saliente de su aplicación a los usuarios finales en la red de Google y sale al POP más cercano a ellos, dondequiera que los usuarios finales estén en todo el mundo. Por lo tanto, la mayor parte de este tráfico llega a su destino con un solo salto al ISP del usuario final, por lo que goza de la congestión mínima y el máximo rendimiento.

El Diseño de red de Google se creo para que sea altamente redundante, para garantizar la alta disponibilidad de sus aplicaciones. Existen al menos tres rutas independientes (redundancia N + 2) entre dos ubicaciones de la red de Google, lo que ayuda a garantizar que el tráfico continúe fluyendo entre estas dos ubicaciones incluso en caso de una interrupción. Como resultado, con Premium Tier, su tráfico no se ve afectado por un solo corte de fibra. En muchas situaciones, el tráfico puede fluir hacia y desde su aplicación sin interrupción incluso con dos cortes simultáneos de fibra.

Los clientes de GCP utilizan Global Load Balancing, otra característica Premium Tier. El Cliente de Google Cloud no sólo obtiene la simplicidad de administración de un único IP virtual IPv4 o IPv6 IP virtual (VIP), sino que también puede expandirse de manera transparente entre regiones y desbordarse o saltar si falla en otras regiones.
Con Premium Tier, utiliza la misma red que ofrece Google Search, Gmail, YouTube y otros servicios, así como los servicios de clientes como The Home Depot, Spotify y Evernote.

    "El 75% de homedepot.com ya está disponible desde Google Cloud, y desde el principio, queríamos correr en varias regiones para una tener alta disponibilidad." La red global de Google es una de las características más fuertes para elegir Google Cloud.

    - Ravi Yeddula, Director Senior de Arquitectura de Plataformas y Desarrollo de Aplicaciones, The Home Depot.

Introducción al Nivel Estándar

Nuestro nuevo nivel estándar ofrece una calidad de red comparable a la de otras grandes nubes públicas, y a un precio inferior a nuestro Nivel Premium. ¿Por qué Standard Tier es menos costoso? Debido a que entregamos su tráfico de salida de GCP a Internet a través de redes de tránsito (ISP) en lugar de la red de Google.
Envío de tráfico entrante y saliente

Del mismo modo, entregamos su tráfico de entrada, desde el usuario final a GCP, en la red de Google sólo en la región donde reside su destino GCP. Si su tráfico de usuario se origina en una región diferente, su tráfico viajará primero por redes de transporte (ISP) hasta que llegue a la región del destino de GCP.

Standard Tier proporciona un rendimiento y una disponibilidad de red más bajos en comparación con Premium Tier. Dado que entregamos su tráfico entrante y saliente en la red de Google sólo en el salto corto entre GCP y el POP más cercano, las características de rendimiento, disponibilidad y redundancia de Standard Tier dependen del proveedor de tránsito que transporta su tráfico. Su tráfico puede experimentar congestión o interrupciones más frecuentes en relación con Premium Tier, pero a un nivel comparable a otras nubes públicas importantes.

También proporcionamos servicios de red regionales en Nivel estándar, como el nuevo servicio regional de Balanceo de carga de la nube. En este nivel, su IP virtual de equilibrio de carga (VIP) es regional, similar a otras ofertas de nube pública y agrega complejidad de administración en comparación con el Balanceo de carga global Premium Tier, si requiere una implementación de varias regiones.

Comparar el rendimiento de los niveles

Google gestino y permitió a Cedexis,  con herramientas de monitorización y de rendimiento de Internet y herramientas de optimización Empresa, para poder tomar mediciones de rendimiento preliminares para ambos niveles de servicio de red. Como se esperaba, Premium Tier ofrece un rendimiento más alto y una latencia más baja que Standard Tier. Puede ver los cuadros de resumen en vivo en www.cedexis.com/google-reports/ en la sección "Red Tiers".Cedexis también detalla su metodología de pruebas en su sitio web.

El siguiente gráfico de Cedexis muestra el rendimiento para Premium y Standard Tier para el tráfico de balanceo de carga HTTP en el percentil 50. El rendimiento estándar (línea azul) es de 3,223 kbps mientras que Premium (línea verde) es 5,401 kbps, lo que hace que el rendimiento Premium sea 1,7x veces el estándar. Vea el gráfico de Cedexis a continuación:

 
En general, Premium Tier muestra un rendimiento considerablemente mayor, en cada percentil, que en el nivel estándar.

Comparar los precios de los niveles

En Google están introduciendo nuevos precios para Premium y Standard Tiers. Puede consultar los precios detallados de ambos niveles aquí. Este pago de precios entrará en vigor cuando los niveles de servicio de red se hagan disponibles en forma genérica (GA). Mientras que en alfa y beta, se aplica el precio de salida de Internet existente.

Con el nuevo precio de Network Tiers (efectivo en GA), el tráfico de salida (GCP a Internet) tiene un precio 24-33% más bajo en Nivel estándar que en Nivel Premium para Norteamérica y Europa. El nivel estándar es menos costoso que las opciones de salida de Internet ofrecidas por otros proveedores de nube públicos importantes (basados ​​en los precios publicados típicos para julio de 2017). El tráfico entrante permanece libre para Premium y Standard Tiers. También cambiaremos nuestros precios basados ​​en destinos actuales para Premium Tier y para que se basen tanto en el origen como en el destino del tráfico, ya que el costo del tráfico de red varía con la distancia que recorre su tráfico en la red de Google. En contraste, el tráfico de Nivel Estándar se basará en su origen, ya que no viaja mucho por la red de Google.

Elija el nivel correcto

El potente nivel superior sigue siendo el nivel predeterminado para sus cargas de trabajo. Aquí hay un árbol de decisiones para ayudarle a elegir el nivel que mejor se adapte a sus necesidades.

Configure el nivel para su (s) aplicación (es)

Una misma  opción no se ajusta a todos, y sus aplicaciones en Google Cloud suelen tener diferentes requisitos de disponibilidad, rendimiento, huella y costo. Configure el nivel en el nivel del recurso (por instancia, plantilla de instancia, equilibrador de carga) si desea un control granular o en el nivel general del proyecto si desea utilizar el mismo nivel en todos los recursos.

 

Pruebe los niveles de servicio de red hoy


    "Los clientes de Cloud quieren opciones en cuanto a niveles de servicio y costo. Hacer coincidir el servicio adecuado con los requisitos empresariales adecuados proporciona la alineación necesaria para los clientes. Google es el primer proveedor de cloud público que reconoce que en la versión alpha de Network Service Tiers. Premium Tier atiende a aquellos que necesitan una calidad garantizada y Nivel Estándar a aquellos que necesitan costos más bajos o tienen una necesidad limitada de redes globales ".

    - Dan Conde, Analista de ESG

Para obtener más información, visite el sitio web de Network Service Tiers y conceda a los niveles de servicios de red un giro al inscribirse en alfa.