CLOUD COMPUTING

CLOUD COMPUTING

Introducción

Cloud Computing es un enfoque para ofrecer servicios de IT a los clientes. Sin embargo, Cloud Computing no es un producto, o un conjunto de productos, un protocolo o cualquier cosa. Así que, mientras se aceptan descripciones y definiciones de Cloud Computing hoy en día, se necesita un amplio conocimiento de él más allá de la red para saber si un servicio de TI en particular es o no es digno de ser llamado un servicio de Cloud Computing.

Cloud Computing, o Cloud, es un enfoque en cuanto a cómo ofrecer servicios a los clientes. Para que un servicio de TI sea considerado como Cloud Computing, debe tener estas características: se puede solicitar bajo demanda; puede escalar dinámicamente (es decir, es elástico); utiliza un pool de recursos; tiene una variedad de opciones de acceso a la red; y se puede medir y facturar de nuevo al usuario basándose en la cantidad utilizada.

Conceptos del Cloud Computing

Desde una perspectiva, la función it en cualquier negocio proporciona servicios: el servicio de apoyo navega aplicaciones a los clientes internos dentro de la empresa. Podríamos pensar en Como servidores, bases de datos y redes, y seguridad, y todo el hardware relacionado y Software. Pero desde la otra dirección, el objetivo es ejecutar las operaciones empresariales de la empresa, utilizando diferentes aplicaciones, y su negocio es entregar esas aplicaciones a el resto de la compañía. Cloud Computing se refiere a un enfoque para proporcionar algunos tipos de servicios de ti. Que enfoque se centra en el servicio más que la tecnología. Pero antes de que puedas empezar a en la informática de la nube, esta sección debe introducir algunos conceptos y terminología del mundo de los centros de datos virtualizados. A continuación, esta primera sección define y explica la Cloud Computing.

 

Virtualización de servidores

Cuando piensas en un servidor, ¿qué te viene a la mente? ¿es un ordenador de sobremesa con un rápido ¿Cpu? ¿un ordenador de sobremesa con mucha RAM? ¿es el hardware que no se sentaría vertical en el suelo, pero podría ser fácilmente atornillado en un rack en un centro de datos? Cuando tienes que pensar en un servidor, ¿ni siquiera piensas en el hardware, sino en el sistema operativo del servidor (SO), ejecutando en algún lugar como una máquina virtual (VM)? Todas esas respuestas son precisas desde una perspectiva u otra. De la perspectiva un servidor es un lugar para ejecutar aplicaciones, con los usuarios que se conectan a esas aplicaciones a través de la red.

Cisco Server Hardware

Piense en el factor de forma de los servidores por un momento, es decir, la forma y el tamaño del servidor físico. Si fueras a construir un servidor propio, ¿qué aspecto tendría? Cómo sería grande, ¿qué tan ancho, ¿qué alto, y así sucesivamente? Incluso si usted nunca ha visto un dispositivo caracterizado como un Server, considere estos hechos clave:

No KVM

Para la mayoría de los servidores, no hay ningún usuario permanente que se encuentre cerca del servidor; todos los usuarios y administradores se conectan al servidor a través de la red. Como resultado, no es necesario un teclado, una pantalla de vídeo o un mouse permanentes (denominados de forma colectiva como KVM).

Racks de servidores en el Data Center

En los primeros años de los servidores, un servidor era cualquier ordenador con CPU relativamente rápida, grandes cantidades de RAM, etc. Hoy, las empresas ponen muchas los servidores en una habitación o un centro de datos y un objetivo es no desperdiciar espacio. Por lo tanto, hacer que los servidores con un factor de forma que encaja en un rack estándar hacen que el uso más eficiente del espacio disponible, especialmente cuando no se espera que la gente esté sentada frente a cada Servidor.

Vamos a ver las siguientes imágenes de ejemplo

Aspectos básicos de la virtualización de servidores

Piense en un servidor (el hardware) como un equipo. Lo tradicionalmente, cuando uno piensa en un servidor, ese servidor ejecuta un SO. Dentro, el Hardware incluye una CPU, un poco de RAM, algún tipo de almacenamiento permanente (como unidades de disco), y algunos componentes llamados NICs. Y el sistema operativo puede usar todo el hardware dentro del sistema operativo y puede correr una o más aplicaciones.

 

Con el modelo de servidor físico que se muestra en la figura 27-2, cada servidor físico ejecuta un SO y ese sistema operativo utiliza todo el hardware de ese servidor. Que era cierto de los servidores en los días anteriores Virtualización de servidores.

Hoy en día, la mayoría de las empresas crean un centro de datos virtualizado. Eso significa que la empresa el hardware del servidor de las compras, lo instala en bastidores, y después trata toda la CPU, RAM, y así sucesivamente como capacidad en el centro de datos. Luego, cada instancia de so se desempareja del hardware, y es por lo tanto virtual (en contraste con físico). Cada pieza de hardware que antes como un servidor ejecuta varias instancias de un SO al mismo tiempo, cada vez que se instancia de un sistema operativo denominada máquina virtual o VM.

Un único host físico (servidor) a menudo tiene más potencia de procesamiento de la que necesita para un SO. Pensando en los procesadores por un momento, las CPUs de servidores modernas tienen múltiples núcleos (procesadores) en un solo chip de CPU. Cada núcleo también puede ser capaz de ejecutar varios subprocesos con una característica se llama multihilo. Por lo tanto, cuando lees acerca de un procesador Intel en particular con 8 núcleos y multihilo (típicamente dos hilos por núcleo), que un chip de CPU puede ejecutar 16 diferentes programas simultáneamente. El hypervisor (introducido en breve) puede entonces tratar cada provecho el hilo de rosca capaz como una CPU virtual (vCPU), y da a cada VM un número de vCPUs, con 16 núcleos.

Una VM, es decir, una instancia de so que se desempareja del hardware del servidor todavía debe ejecutar en hardware. Cada VM tiene configuración en cuanto al número mínimo de vCPUs necesidades, RAM mínima, etc. El sistema de virtualización inicia cada VM en algún servidor físico para que exista suficiente capacidad de hardware de servidor físico para VMS corriendo en ese host. Por lo tanto, en cualquier punto en el tiempo, cada VM se está ejecutando en un físico servidor de cal, utilizando un subconjunto de la CPU, RAM, almacenamiento de información y NICs en ese servidor. Figura 27-3 muestra un gráfico de ese concepto, con cuatro VMs independientes que se ejecutan en un servidor físico. Para hacer funcionar la virtualización de servidores, cada servidor físico (llamado host en el servidor virtualización World) utiliza un hypervisor. El hypervisor administra y asigna el hardware del host (CPU, RAM, etc.) a cada VM basándose en la configuración de la VM. Cada VM se ejecuta como si fuera se ejecuta en un servidor físico autónomo, con un número específico de CPUs virtuales y NIC y una cantidad fija de RAM y almacenamiento. Por ejemplo, si una VM pasa a ser configurado para utilizar cuatro CPUs, con 8 GB de RAM, el hypervisor asigna las partes específicas de la CPU y RAM que la VM utiliza realmente.

Para conectar el mercado a las grandes ideas discutidas hasta el momento, la siguiente lista incluye unos pocos de los proveedores y nombres de familia de productos asociados con los centros de datos virtualizados:

  • VMware vCenter
  • Microsoft HyperV
  • Citrix XenServer
  • KVM de Red Hat

Más allá del hypervisor, compañías como ésas en la lista (y otras) venden virtualización de sistemas. Estos sistemas permiten a los ingenieros de virtualización crear dinámicamente VMS, iniciar ellos, moverlos (manual y automáticamente) a diferentes servidores, y detenerlos. Para ejemplo, cuando se necesita realizar el mantenimiento del hardware, el ingeniero de virtualización puede mover las VMs a otro host (a menudo mientras se ejecuta) para que el mantenimiento se pueda haber hecho.

Networking con switches virtuales en un host virtualizado

Las herramientas de virtualización de servidores proporcionan una amplia variedad de opciones para conectar las VMs a Redes. T su libro no intenta discutir todos ellos, pero puede ayudar a conseguir algunos de los Fundamentos antes de pensar más sobre Cloud Computing. En primer lugar, ¿qué incluye un servidor físico para las funciones de red? Típicamente tiene uno o más NICs, tal vez tan lento como 1 Gbps, a menudo 10 Gbps hoy, y tal vez tan rápido como 40 Gbps. Luego, piense en las VMs. normalmente, un SO tiene una NIC, tal vez más. Para que el SO trabajar como normal, cada VM tiene (al menos) una NIC, pero para una VM, es una NIC virtual. (por ejemplo, en los sistemas de virtualización de VMware, la NIC virtual de la VM pasa por el nombre VNIC.) Por último, el servidor debe combinar las ideas de las NICs físicas con las vNICs utilizadas por el VMs en una especie de red. Con mayor frecuencia, cada servidor utiliza algún tipo de El concepto del interruptor de Ethernet, llamado a menudo (usted lo adivinó) un interruptor virtual, o vSwitch. Figura 27-4 muestra un ejemplo, con cuatro VMs, cada uno con un VNIC. El servidor físico tiene dos NICs físicas. Las NICs vNICs y físicas se conectan internamente a un Switch virtual.

 

Curiosamente, el vSwitch puede ser suministrado por el proveedor del hypervisor o por Cisco. Para ejemplo, la línea de productos switch del centro de datos de Cisco, switches Cisco Nexus, incluye el nexo 1000V (v para virtual). A su opción, puede utilizar el vSwitch incluido en el hypervisor, o Instale el Cisco Nexus 1000V (o productos similares). El Nexus 1000V apoya entonces algunas características exclusivas de la serie de switches Cisco Nexus. (tenga en cuenta que el centro de datos de Cisco switches, y el sistema operativo NX-os que se ejecuta en los modelos Nexus de switches, son cubierto en las certificaciones CCNA, CCNP, y CCIE Data Center.) Los detalles de la red que se muestran en la figura 27-4 muestran sólo lo básico, pero dos puntos importantes permanezcan para la acumulación de este capítulo a la nube. En primer lugar, el networking en el Data Center tiene muchos Opciones. Cada VM puede estar en su propio v [una, o compartir la misma VLAN, o incluso utilizar v LAN troncalización a la VM misma. En segundo lugar, esa configuración se puede hacer fácilmente desde el el mismo software de virtualización que controla la programación de VMs. Red Hat permite la virtualización software para mover VMS entre hosts (servidores) y reprogramar el vSwitches para que la VM tiene las mismas capacidades de red independientemente de dónde se esté ejecutando la VM.

La red de data centers físicos

Para reunir estas ideas, a continuación, considere lo que sucede con la red física en un Centro de datos de virtualizado. Cada host, es decir, el host físico, necesita una conexión física para la red. Mirando de nuevo en la figura 27-4, ese anfitrión, con dos NICs físicas, necesita desconecte esas dos NICs físicas a una LAN en el Data Center. La figura 27-5 muestra el cableado tradicional para una LAN de Data Center. Cada representante de rectángulo más alto resiente un rack dentro de un centro de datos, con los cuadrados minúsculos que representan los puertos de NIC, y las líneas que representan los cables.

A menudo, cada host está cableado a dos interruptores diferentes en la parte superior del rack, que se llama la parte superior de Switches de rack (Tor): para proporcionar paths redundantes a la LAN. Cada switch Tor actúa como un acceda al conmutador Layer desde una perspectiva de diseño. Cada conmutador Tor se conecta a un extremo de el conmutador Row (EoR), que actúa como un conmutador de distribución, y también se conecta al resto del Red.

 

 

Flujo de trabajo con un Data Center virtualizado

Hasta ahora, la primera parte de este capítulo ha descrito la información de fondo importante para las próximas discusiones de Cloud Computing. La virtualización de servidores ha sido una gran mejora operaciones de muchos centros de datos, pero la virtualización por sí sola no crea un entorno de Cloud Computing. Continuando la discusión de estas tecnologías fundamentales estrategias antes de hablar de Cloud Computing, considere este ejemplo de un flujo de Centro de datos virtualizado (no basado en nube). Algunos de los empleados de ti, los llaman servidores o ingenieros de virtualización o administradores, orden e instalar nuevos hosts (servidores). Reúnen los requisitos, planifican la capacidad requerida, comprar hardware, ordenarlo e instalar el hardware. Desempeñan el papel de servidor de largo plazo administradores e ingenieros, pero ahora también trabajan con las herramientas de virtualización. Para las partes de virtualización del esfuerzo, los ingenieros de virtualización también instalan y las herramientas de virtualización. Más allá del hypervisor en cada anfitrión, muchas otras herramientas útiles ayudar a administrar y controlar un centro de datos virtualizado. Por ejemplo, una herramienta podría dar la ingeniera una vista del centro de datos en su totalidad, con todas las VMs corriendo allí, con la idea que un centro de datos es sólo una gran cantidad de capacidad para ejecutar VMS. Con el tiempo, el servidor/virtualización los ingenieros agregan nuevos servidores físicos al Data Center y configuran el sistema de virtualizaciones para hacer uso de los nuevos servidores físicos, y asegúrese de que todo funciona. Hasta ahora en este escenario, el trabajo ha sido en preparación para prestar servicios a algún cliente interno: un miembro del equipo de desarrollo, el personal de operaciones, etc. Ahora, un el cliente está solicitando un “servidor”. En realidad, el cliente quiere una VM (o muchas), con ciertos requisitos: un número específico de vCPUs, una cantidad específica de RAM, y así sucesivamente. El CUS- Tomar hace una solicitud al ingeniero de virtualización/servidor para configurar las VMs, como se muestra en

Figura 27-6.

 

 

Paso 1.

El cliente del grupo de ti, como un desarrollador o un miembro del personal de operaciones, quiere un poco de servicio, como un conjunto de nuevas VMs.

Paso 2.

El Servidor de virtualización el ingeniero del servidor reacciona a la petición del cliente. El ingeniero de servidor/virtualización hace clic en la interfaz de usuario, o si el número de VMs es grande, a menudo ejecutan un programa llamado script para más eficientemente crear las VMs.

Paso 3.

Independientemente de si el ingeniero de virtualización hace clic o utiliza secuencias de comandos, el software de la virtualización podría entonces crear un número de nuevas VMs y comenzar ésos en algunos hosts dentro del centro de datos.

 

El proceso mostrado en la figura 27-6 funciona muy bien. Sin embargo, ese enfoque para proporcionar servicios de vicios rompe algunos de los criterios básicos de un servicio en la nube. Por ejemplo, Cloud Computing requiere auto-servicio. Para que el flujo de trabajo se considere un servicio en la nube, el proceso como el paso 2 no debe requerir un ser humano para dar servicio a esa solicitud, pero en su lugar la solicitud debe ser llenado automáticamente. ¿quieres nuevas VMs en un mundo de nubes? Haga clic en una interfaz de usuario para preguntar para algunas VMS nuevas, vayan a tomar una taza de café, y sus VMs se habrán configurado y empezado, a su especificación, en minutos.

Resumiendo, algunos de los puntos clave sobre un Data Center virtualizado hasta ahora, que habilitar Cloud Computing:

  • El SO está desacoplado del hardware en el que se ejecuta, de modo que el SO, como VM, puede ejecutar en cualquier servidor de un centro de datos que tenga recursos suficientes para ejecutar la VM.
  • El software de virtualización puede iniciar y mover automáticamente la VM entre servidores en el centro de datos.
  • La red de Data Center incluye switches virtuales y NICs virtuales dentro de cada host (servidor).
  • La red de Data Center puede ser programada por el software de virtualización, permitiendo nuevas VMs que se configura, se inicia, se mueve según sea necesario y se detiene, con la red detalles configurados automáticamente.

Servicios de Cloud Computing

Cloud Computing es un enfoque para ofrecer servicios de ti. Cloud Computing hace uso de productos como los productos de virtualización, pero también utiliza productos construidos específicamente para activar funciones de nube. Sin embargo, Cloud Computing no es sólo un conjunto de productos para ser implementado en cambio, es una forma de ofrecer servicios de ti. Por lo tanto, entender qué Cloud Computing es y no es toma un poco de trabajo; el siguiente tema introduce los fundamentos. De las discusiones recién terminadas sobre la virtualización, usted ya conoce un carácter TIC de un servicio Cloud: debe permitir el aprovisionamiento de autoservicio por el consumidor del servicio. Esto es, el consumidor o cliente del servicio debe poder solicitar el servicio y recibir ese servicio sin la demora de esperar a que un humano tenga tiempo para trabajar en él, considere la petición, haga el trabajo, y así sucesivamente. Para obtener un sentido más amplio de lo que significa para un servicio para ser un servicio en la nube, examine esta lista de cinco criterios para un servicio de Cloud Computing. La lista se deriva de la definición de Cloud Computing, según lo planteado por el Instituto Nacional de estándares y tecnología de los Estados Unidos

(NIST):

 

  1. Autoservicio on-Demand: el consumidor de ti escoge Cuándo empezar y dejar de usar el servicio, sin ninguna interacción directa con el proveedor del servicio.
  2. Amplio acceso a la red: el servicio debe estar disponible en muchos tipos de dispositivos y sobre muchos tipos de redes (incluyendo Internet).
  3. Agrupación de recursos: el proveedor crea un conjunto de recursos (en lugar de dedicar específico servidores para su uso sólo por ciertos consumidores), y asigna dinámicamente recursos de esa piscina para cada nueva solicitud de un consumidor.
  4. Elasticidad rápida: al consumidor, el fondo de recursos parece ser ilimitado (es decir, se expande rápidamente, por lo que se llama elástico), y las solicitudes de nuevo servicio se llenan rápidamente.
  5. Servicio medido: el proveedor puede medir el uso y reportar que el uso del consumidor, tanto por la transparencia como por la facturación.

Nube privada

Vuelva a mirar el ejemplo de flujo de trabajo en la figura 27-6 con un Data Center virtualizado. Usted piense en los cinco criterios del NIST para la compensacion en nube. Si desglosa la lista en comparación con el ejemplo alrededor de la figura 27-6, parece que el flujo de trabajo puede cumplir al menos algunos de estos cinco criterios de la nube del NIST, y lo hace. En particular, como se describe en este capítulo, Data Center virtualizado agrupa recursos para que puedan asignarse dinámicamente. Se podría argumentar que un centro de datos virtualizado es elástico, en el que el fondo de recursos se expande. Sin embargo, el proceso puede no ser rápido, porque el flujo de trabajo requiere cheques humanos, saldos y tiempo antes de aprovisionar nuevos servicios.

Private Cloud crea un servicio, dentro de una empresa, a clientes internos, que cumplen los cinco criterios de la lista del NIST. Para crear una nube privada, una empresa a menudo expande sus herramientas de ti (como las herramientas de virtualización), cambia los procesos de flujo de trabajo internos, agrega herramientas adicionales, y así como algunos ejemplos, considere lo que sucede cuando un desarrollador de aplicaciones en una empresa necesita VMs para usar al desarrollar una aplicación. Con la nube privada, el desarrollador puede solicitar esas VMS y las VMs se inicien automáticamente y estén disponibles en cuestión de minutos, con la mayor parte del tiempo de retraso es el momento de arrancar las VMs. Si el desarrollador quiere muchos más VMS, puede asumir que la nube privada tendrá suficiente capacidad, y nuevas solicitudes son todavía se mantiene rápidamente. Y todas las partes deben saber que el grupo de ti puede medir el uso de los servicios de facturación interna.

Enfóquese en el aspecto de autoservicio de Cloud por un momento. Para hacer que eso suceda, muchas nubes los servicios informáticos utilizan un catálogo de servicios Cloud. Ese catálogo existe para el usuario como Web aplicación que enumera cualquier cosa que se pueda solicitar a través de la infraestructura Cloud de la empresa. Antes de usar una nube privada, desarrolladores y operadores que necesitaban nuevos servicios (como nuevo VMS) envió una solicitud de cambio pidiéndole al equipo de virtualización que agregara VMs (vea la figura 27-6). Con la nube privada, los consumidores (internos) de los servicios de TI: desarrolladores, operadores y como — puede hacer clic para elegir entre el catálogo de servicios de Cloud. Y si la solicitud es para un nuevo conjunto de VMs, las VMs aparecen y están listas para su uso en minutos, sin interacción humana para ese paso, como se ve en el paso 2 de la figura 27-7.

 

 

Para hacer que este proceso funcione, el equipo de Cloud tiene que añadir algunas herramientas y procesos a su centro de datos de virtualizado. Por ejemplo, instala software para crear el catálogo de servicios de Cloud, ambos con una interfaz de usuario y con código que interconecta a las API de la virtualización de sistemas. Que el software de catálogo de servicios puede reaccionar a solicitudes de los consumidores, utilizando APIs software de virtualización, para agregar, mover y crear VMS, por ejemplo. Además, el equipo de Cloud — integrado por ingenieros de servidores, virtualización, redes y almacenamiento de información, se centra en la creación el grupo de recursos, probar y agregar nuevos servicios al catálogo, controlar las excepciones y ver los informes (según el requerimiento de servicio medido) para saber cuándo agregar capacidad para mantener el pool de recursos listo para controlar todas las solicitudes. En particular, con el modelo Cloud, el equipo de Cloud ya no pasa tiempo manejando individuos solicitudes de adición de 10 VMS aquí, 50 allí, con solicitudes de cambio de diferentes grupos.

Resumiendo, con la nube privada, usted cambia sus métodos y herramientas para ofrecer algunos de los mismos servicios. La nube privada es “privada” en que una empresa posee las herramientas que crean la nube y emplea a las personas que utilizan los servicios. Incluso dentro de una empresa, utilizando un el enfoque de Cloud Computing puede mejorar la velocidad operacional de implementar los servicios de ti.

Nube pública

Con una nube privada, el proveedor de la nube y el consumidor de la nube son parte de la misma compañía. Con Cloud pública, lo contrario es cierto: un proveedor de Cloud pública ofrece servicios, vendiendo esos servicios a los consumidores de otras empresas. De hecho, si usted piensa en el servicio de procedores de Internet y XV proveedores de servicios que venden Internet y WAN a muchas empresas, la misma idea general trabaja aquí con los proveedores de nube pública que venden sus servicios a muchas empresas. El flujo de trabajo en la nube pública sucede algo así como nube privada cuando se empieza desde el punto de un consumidor que pide algún servicio (como una nueva VM). Como se muestra a la derecha de la figura 27-8, en el paso 1, el consumidor solicita el nuevo servicio del catálogo de servicios Página Web. En el paso 2, las herramientas de virtualización reaccionan ante la solicitud de creación del servicio. Vez los servicios están disponibles, pero se ejecutan en un centro de datos que reside en otro lugar en el mundo, y desde luego no en el centro de datos de la empresa (paso 3).

 

 

Por supuesto, el consumidor está en una red diferente a la de Cloud Provider con Cloud computting, que trae el tema de cómo conectarse a un proveedor de nube. Proveedores de nube soporta múltiples opciones de red. Cada uno se conecta a Internet, para que las aplicaciones y los usuarios dentro de la red del consumidor puede comunicarse con las aplicaciones que el consumidor ejecuta en la red del proveedor de la nube. Sin embargo, uno de los cinco criterios del NIST para el cálculo de la nube es un amplio acceso a la red, por lo que los proveedores de nube ofrecen diferentes opciones de red, así, incluyendo conexiones de red privada virtual (VPN) y red privada de área amplia (WAN) entre los consumidores y la nube.

Cloud y el modelo “como servicio”

Entonces, ¿Qué obtienes con Cloud Computing? Hasta ahora, este capítulo acaba de mostrar una VM como Servicio. Con Cloud Computing, hay una variedad de servicios, y tres se destacan como el más común visto en el mercado hoy en día. Primero, una breve palabra acerca de una terminología próxima. El mundo de la Cloud Computing funciona en un modelo de servicios. En lugar de comprar (consumir), hardware, comprar o licenciar software, instalando usted mismo, y así sucesivamente, el consumidor recibe un cierto servicio del abastecedor. Pero esa idea, recibir un servicio, es más abstracta que la idea de comprar un servidor e instalar un paquete de software en particular. Así que, con Cloud Computing, en lugar de mantener la discusión tan genérica, la industria utiliza una variedad de términos que terminan en “como un servicio”. Y cada “-SaaS” el término tiene un significado diferente.

El siguiente tema explica los tres servicios Cloud más comunes la infraestructura como Servicio, software como servicio y plataforma como servicio.

Infraestructura como servicio

La Infraestructura como un servicio (laaS) puede ser el más fácil de los servicios de Cloud Computing para entender para la mayoría de la gente. Para la perspectiva, piense en cualquier momento que usted ha comprado para una computadora. Pensaste en el sistema operativo para ejecutar (el último sistema operativo de Microsoft, o Linux, o OS X Si comprar un Mac). Se compararon los precios basados en la CPU y su velocidad, la cantidad RAM de la computadora tenía, el tamaño de la unidad de disco, y así sucesivamente. laaS ofrece una idea similar, pero el consumidor recibe el uso de una VM. Se especifica la cantidad de rendimiento/capacidad de hardware para asignar a la VM (número de CPUs virtuales, cantidad de RAM, y así sucesivamente) como se muestra en la figura 27-9. Incluso puede seleccionar un SO para usarlo. Vez seleccionado, el proveedor de Cloud inicia la VM, que arranca el sistema operativo elegido.

 

El proveedor también proporciona al consumidor detalles sobre la VM para que el consumidor pueda conectarse a la interfaz de usuario del SO, instalar más software y personalizar la configuración. Por ejemplo, imagine que el consumidor desea ejecutar una aplicación concreta en el servidor. Si ese cliente quería utilizar Microsoft Exchange como servidor de correo electrónico, entonces necesitaría conectarse a la VM e instalar Exchange. La figura 27-10 muestra una página web de Amazon Web Services (AWS), una nube pública, desde el cual se puede crear una VM como parte de su servicio laaS. La captura de pantalla muestra que el usuario seleccionó una pequeña VM llamada “micro”. Si observa de cerca el texto, puede ser capaz de leer el encabezado y los números para ver que esta VM en particular tiene un vCPU y 1 GB de RAM. (tenga en cuenta que esta VM en particular resulta estar disponible como una prueba gratuita de AWS.)

 

 

Software como servicio

Con software como servicio (SaaS), el consumidor recibe un servicio con software de trabajo. El proveedor de Cloud puede usar VMS, posiblemente muchas VMS, para crear el servicio, pero esos son oculto del consumidor. El proveedor de Cloud licencia, instala y soporta cualquier se requiere software. El proveedor de Cloud monitorea el rendimiento de la aplicación. Sin embargo, el consumidor escoge utilizar la aplicación, se firma para el servicio, y comienza uso de la aplicación: no se requiere ningún otro trabajo de instalación. La figura 27-11 muestra estos principales conceptos.

 

Muchos de ustedes probablemente han utilizado o al menos oído hablar de muchas ofertas públicas de SaaS. Archivo de almacenamiento- servicios de edad como Apple iCloud, Google Drive, Dropbox, y Box son todas las ofertas de SaaS. La mayoría de ofertas de correo electrónico en línea pueden considerarse servicios SaaS hoy. Como otro ejemplo, Microsoft ofrece su software Exchange Email Server como un servicio, para que pueda tener servicios de correo electrónico pero ofrecidos como un servicio, junto con todas las otras características incluidas con Exchange, pero sin tener que licenciar, instalar y mantener el software de Exchange en algunas VMS.

Plataforma como servicio de Desarrollo

Plataforma como servicio (PaaS) es una plataforma de desarrollo, preconstruida como servicio. Un servicio PaaS es como laaS de alguna manera. Ambos abastecen al consumidor con una (o más) VMS, con una cantidad calculable de CPU, RAM y otros recursos.La diferencia clave entre PaaS y laaS es que PaaS incluye muchas más herramientas de software más allá del sistema operativo básico. Estas herramientas son útiles para un desarrollador de software durante el software proceso de desarrollo. Una vez completado el proceso de desarrollo, y la aplicación ha en producción, esas herramientas no son necesarias en los servidores que ejecutan las aplicaciones Catión. Así que las herramientas de desarrollo son particulares para el trabajo realizado en el desarrollo. Una oferta de PaaS incluye un conjunto de herramientas de desarrollo, y cada oferta de PaaS tiene una combinación de herramientas. Las VMs de PaaS suelen incluir un entorno de desarrollo integrado (IDE), que es un conjunto de herramientas relacionadas que permite al desarrollador escribir y probar código fácilmente. Las VMs de PaaS incluyen herramientas de integración continua que permiten al desarrollador actualizar código y que el código se pruebe y se integre automáticamente en un proyecto de software más grande.

 

Ejemplos

incluya la oferta PaaS de Google App Engine (https://Cloud.Google.com/appengine), el Entorno de desarrollo integrado de Eclipse (ver http://www.Eclipse.org), y el Jenkins herramienta de integración y automatización continua (ver https://Jenkins.IO).

Las principales razones para elegir un servicio PaaS sobre otro, o para elegir una solución PaaS en lugar de laaS, es la mezcla de herramientas de desarrollo. Sin experiencia como desarrollador, puede ser difícil saber si un servicio de PaaS puede ser mejor. Usted todavía puede hacer algunas opciones sobre el dimensionamiento de las VMs de PaaS, similares a las herramientas de laaS al configurar algunos servicios PaaS, como se muestra en la figura 27-12, pero las herramientas de desarrollador incluidas son la clave de un servicio PaaS.

Rutas de tráfico WAN para llegar a servicios en la nube

La recién completada primera sección importante de este capítulo ha creado la historia de Cloud Computing lo suficiente como para ahora discutir los temas de examen relacionados con la nube en el ICND2 y CCNA R&S Exámenes. La primera sección ha definido algunos detalles sobre Cloud Computing, lo suficiente para discuta los temas del examen. En esta segunda sección se explican algunos problemas de red sobre cómo Acceda a esos servicios. Esta segunda sección importante del capítulo se centra en las opciones de WAN para la nube pública, y los pros y los contras de cada uno. Esta sección omite la nube privada en su mayor parte, porque el uso de una nube privada (que es interna para una empresa) tiene mucho menos impacto en una empresa WAN en comparación con la nube pública. Con la nube pública, los servicios en la nube existen en el otro lado de alguna conexión WAN en comparación con el consumidor de los servicios, por lo tanto, los ingenieros de red deben pensar en cómo construir una WAN cuando se utiliza Cloud servicios públicos.

Conexiones WAN de empresa a Cloud pública

El uso de Internet para comunicarse entre la empresa y un proveedor de Cloud pública es fácil y conveniente. Sin embargo, también tiene algunos negativos. Esta primera sección describe labásicos, y señala los temas, que luego conduce a algunas de las razones por las que el uso de otros Las conexiones WAN pueden ser preferidas.

Acceso a servicios de nube pública mediante Internet

Imagine una empresa que opera su red sin Cloud. Todas las aplicaciones que utiliza para Ejecute su negocio en servidores en un centro de datos dentro de la empresa. Las instancias de SO donde estas aplicaciones se pueden alojar directamente en servidores físicos o en VMs en un Data Center, pero todos los servidores existen en algún lugar dentro de la empresa. Ahora Imagine que el personal de ti comienza a mover algunas de esas aplicaciones a un público servicio de nube. ¿Cómo los usuarios de la aplicación (dentro de la empresa) llegar al usuario interfaz de la aplicación (que se ejecuta en el centro de datos del proveedor de la nube pública)? La Internet, por supuesto. Tanto la empresa como el proveedor de Cloud se conectan a Internet, el uso de Internet es la opción fácil y conveniente. Ahora considere un flujo de trabajo común para mover una aplicación interna que ahora se ejecute en el pubLic Cloud, con el propósito de hacer un par de puntos importantes. En primer lugar, la figura 27-13 muestra el ejemplo. El personal de la empresa puede llegar al catálogo de servicios del proveedor de Cloud, a través de Internet, como se muestra en el paso 1. Después de elegir los servicios deseados — por ejemplo, algunas VMs para un servicio laaS: el proveedor de nube (paso 2) crea instancias de las VMs. Entonces, no se muestra como un paso en la figura, las VMs están personalizadas para ejecutar ahora la aplicación que antes era corriendo dentro del centro de datos de la empresa.

 

En este punto, la nueva aplicación se está ejecutando en la nube, y esos servicios requerirá red Banda. En particular, el paso 3 muestra a los usuarios que se comunican con las aplicaciones, pasaría con cualquier otra aplicación. Además, la mayoría de las aplicaciones envían muchos más datos que sólo los datos entre la aplicación y el usuario final. Por ejemplo, puede mover una aplicación a la nube pública, pero podría mantener los servicios de autenticación en un servidor interno, debido a que son utilizados por un gran número de aplicaciones, algunos internos y algunos alojados en la nube pública. Así que en el paso 4, cualquier comunicación de aplicación entre VMS alojado en también es necesario realizar la nube desde/hacia las VMs alojadas dentro de la empresa.

Pros y contras con la conexión a la nube pública con Internet

El uso de Internet para conectarse desde la empresa a Internet tiene varias ventajas. La ventaja más obvia es que todas las empresas y proveedores de Cloud ya tienen Internet conexiones, así que empezar a usar servicios de nube pública es fácil. Uso de las obras de Internet

particularmente bien con servicios SaaS y una fuerza de trabajo distribuida. Por ejemplo, tal vez la división de ventas utiliza una aplicación de contacto con el cliente SaaS. a menudo, los vendedores no se sientan dentro del red empresarial la mayor parte del día de trabajo. Probablemente se conecten a Internet, y utilicen un VPN para conectar con la empresa. Para aplicaciones alojadas en la nube pública, con esta base de usuarios, tiene perfecto sentido usar Internet. Aunque ese fue sólo un ejemplo, la siguiente lista resume algunas buenas razones para usar Internet como la conexión WAN a un servicio de nube pública:

Agilidad: una empresa puede empezar a usar Cloud pública sin tener que esperar para pedir una conexión WAN privada al proveedor de Cloud porque los proveedores de nube admiten Internet Conectividad.

Migración: una empresa puede cambiar su carga de trabajo de un proveedor de nube a otro más fácilmente porque los proveedores de nube se conectan a Internet.

Usuarios distribuidos: los usuarios de la empresa se distribuyen y se conectan a Internet con sus dispositivos (como en el ejemplo de la aplicación SaaS de ventas).

El uso de Internet como la conectividad WAN a una nube pública es una bendición y una maldición en cierto modo. El uso de Internet puede ayudarle a empezar con Cloud pública, y a obtener trabajando rápidamente, pero también significa que usted no tiene que hacer ninguna planificación antes de implementar- servicio de nube pública. Con un poco de planificación, un ingeniero de red puede ver algunos de los negativos de usar Internet — los mismos negativos cuando se utiliza Internet para otras poses, lo que puede hacer que desee utilizar conexiones WAN alternativas. Esos aspectos negativos para el uso de Internet para el acceso a la nube pública son

 

Seguridad: Internet es menos seguro que las conexiones WAN privadas en que un “hombre en el medio “puede intentar leer el contenido de los datos que pasan a/desde la nube pública.

Capacidad: mover una aplicación interna a la nube pública aumenta el tráfico de red, así que la pregunta de si los enlaces de Internet de la empresa pueden manejar la carga adicional necesita ser considerado.

Calidad del servicio (QoS): el Internet no proporciona QoS, mientras que WAN privado. El uso de Internet puede resultar en una experiencia de usuario peor de la deseada, debido a mayor demora (latencia), jitter y pérdida de paquetes.

No SLA WAN: los ISP normalmente no proporcionarán un acuerdo de nivel de servicio (SIA) para WAN rendimiento y disponibilidad a todos los destinos de una red. Los proveedores de servicios WAN muchas más probabilidades de ofrecer rendimiento y disponibilidad SIAS.

Esta lista de preocupaciones no significa que una empresa no pueda utilizar Internet para acceder a sus servicios de Cloud pública. Significa que debe considerar los pros y los contras de cada opción WAN.

WAN privado y acceso a Internet VPN a Cloud pública

La definición del NIST para la informática en nube enumera el “acceso amplio de la red” como uno de los cinco criterios principales. En el caso de la nube pública, que a menudo significa soporta una variedad de conexiones WAN, incluidas las tecnologías WAN de empresa más comunes. Básicamente, una puede conectarse a un proveedor de Cloud pública con tecnologías WAN discutidas en este libro. En aras de la discusión, la figura 27-14 la divide en dos grandes categorías.

 

Para crear un túnel V PN entre la empresa y el proveedor de Cloud, puede utilizar las mismas características de V PN discutidas anteriormente en el capítulo 15, “WAN privado con Internet VPN.” el proveedor de Cloud puede ofrecer un servicio v PN, es decir, el lado de la nube del túnel v PN es implemente por el proveedor de Cloud, y la empresa configura el servicio VPN coincidente en uno de sus propios routers. O la empresa puede utilizar su propio router dentro del proveedor de la nube

Network: un enrutador virtual, que se ejecuta como una VM, y configura los servicios VPN en ese enrutador. En hecho, Cisco hace que el router servicios Cloud (CSR) para hacer exactamente eso •. ser un router, pero un router que se ejecuta como una VM en un servicio de nube, controlado por el consumidor de la nube, para hacer varias funciones que hacen los routers, incluyendo la terminación de VPNs. (también, ejecutando un router virtual como una VM y la gestión de la configuración internamente, la empresa podría ahorrar algunos de los costos de utilizar un servicio similar ofrecido por el proveedor de Cloud.) Para hacer una conmutación de etiquetas privada multiprotocolo (MPIS) V PN o Ethernet WAN conectar-, la empresa necesita trabajar con el proveedor de Cloud y el proveedor de WAN. Los proveedores de nube se conectan a muchos clientes con conexiones WAN privadas, a menudo han publicado las instrucciones establecidas a seguir. En la forma más básica, con MPLS, la empresa y el proveedor de nube se conecta con el mismo proveedor de MPIS, con el proveedor de MPIS con une los sitios de la empresa y la nube. El mismo proceso básico ocurre con Ethernet WAN servicios, con uno o más EVC creados entre la WAN pública y la empresa.

 

Las conexiones XVAN privadas también requieren alguna planificación física. Cada uno de los grandes públicos los proveedores de Cloud tienen una serie de grandes data centers diseminados por el planeta, y con pre- puntos de conexión construidos en los principales servicios de WAN para ayudar a la creación de la WAN privada conexiones con los clientes. Una empresa podría entonces mirar el documentacion del proveedor de la nube y trabajar con ese proveedor para elegir el mejor lugar para instalar la Conexión WAN privada. (esas compañías de nube pública más grandes incluyen Amazon Web Services, Google Calcular Cloud, Microsoft Azure y Rackspace, si desea ver su Web- sitios para obtener información sobre sus ubicaciones.)

Pros y contras con la conexión a la nube con WAN privado

Privado WAN superar algunos de los problemas de uso de Internet sin VPN, por lo que el trabajo a través de estos temas considere algunas de las diferentes opciones de WAN. En primer lugar, teniendo en cuenta el tema de la seguridad, todas las opciones privadas, incluyendo la adición de una VPN para que cifre los datos para mantenerlo en privado. Las conexiones WAN privadas con MPIS y Ethernet tienen tradicionalmente se consideró seguro sin encriptación, pero las empresas a veces encriptación de datos enviados a través de conexiones WAN privadas, así para hacer la red más segura. Con respecto a QoS, el uso de una solución de Internet V PN todavía no proporciona QoS porque el Internet no proporciona QoS. Servicios WAN como MPLS VPN y Ethernet WAN Can.

Por último, en cuanto a la cuestión de la capacidad, la preocupación de planificar la capacidad de red existe sin importar qué tipo de WAN se utiliza. Cualquier plan para migrar una aplicación lejos de un centro de datos interno a en lugar de ser alojado como un proveedor de nube pública requiere un pensamiento adicional y la planificación. Existen varios negativos para usar una WAN privada, como cabría esperar. La instalación del nuevo PrIvate WAN toma tiempo, retrasando cuando una empresa se inicia en la nube de cálculo. Los WAN privados suelen costar más que el uso de Internet. Si se utiliza una conexión XV a un proveedor de Cloud (en lugar de utilizar Internet) y luego migrar a un nuevo proveedor de nube puede requerir otra ronda de instalación privada de WAN, retrasando de nuevo los proyectos de trabajo. Usando Internet (con o sin VPN) habría hecho que la migración fuera mucho más fácil, pero como se muestra en la siguiente sección, una solución de compromiso fuerte existe también. La conexión a Internet existente, mejorar la seguridad significativamente. Un Internet VPN

Intercambios intercloud

La informática pública en la nube también introduce un nuevo nivel de competencia, porque una nube el consumidor puede mover su carga de trabajo de un proveedor de nube a otro. Mover el trabajo toma un poco de esfuerzo, (baste decir que la mayoría de los proveedores de nube difieren en el detalle de cómo implementan los servicios.) Pero las empresas pueden migrar su carga de trabajo de un proveedor de Cloud a otro, una nueva compañía por una variedad de razones, incluyendo la búsqueda de una nube menos costosa.

Ahora, vuelva a centrarse en las conexiones de red. El principal negativo con el uso de un privado WAN para la nube es que añade otra barrera a la migración a una nueva proveedora de la nube pública. Una solución agrega una migración más fácil al uso de una WAN privada a través de una nube vicio llamado un intercambio intercloud (o simplemente un intercloud). Genéricamente, el término intercloud Exchange ha llegado a ser conocido como una empresa que crea una red privada como servicio. En primer lugar, un intercambio intercloud se conecta a múltiples Cloud Providers en un lado. Por otro lado, el intercloud se conecta con los consumidores de nube. Una vez conectado, el consumidor de la nube puede ser configurado para comunicarse con un proveedor público de nube, a sitios específicos de proveedores de nube. más adelante, si el consumidor quiere migrar para utilizar otro proveedor de nube, el consumidor mantiene los mismos enlaces WAN privados para intercloud Exchange, y pide al proveedor que reconfigure para configurar una nueva WAN privada conexiones con el nuevo proveedor de Cloud.

En cuanto a pros y contras, con un intercambio intercloud, obtendrá los mismos beneficios que cuando une con una conexión WAN privada a una nube pública, pero con el Pro adicional de migración más fácil a un nuevo proveedor de Cloud. La estafa principal es que el uso de un intercambio intercloud introduce a otra compañía en la mezcla.

Tenga en cuenta que Cisco tiene un conjunto de productos relacionados (llamado Cisco intercloud fabric) que ayuda a resolver muchos de los otros desafíos de la migración con cargas de trabajo móviles de una nube Provider a la siguiente. Estas herramientas de software de Cisco no proporcionan un intercambio intercloud Servicio WAN, pero resuelven muchos de los desafíos que existen al administrar Cloud cargas de trabajo en la nube privada y pública a través de una variedad de conexión Opciones WAN. Mire a http://www.Cisco.com/go/intercloud para más detalles.

Resumiendo, los pros y los contras de las opciones de Cloud WAN públicas

La siguiente tabla resume algunos de estos pros y contras clave para las opciones públicas de WAN para Cloud Computing, para estudio y referencia.

 

 

Un escenario: sucursales y la nube pública

Hasta ahora en esta sección importante sobre el diseño WAN con Cloud pública, la empresa ha sido se muestra como una entidad, pero la mayoría de las empresas WAN tienen muchos sitios. Los distribuidos entre los sitios web impactan algunas partes del diseño WAN para Cloud pública. La próxima discusión de los problemas de diseño de WAN con Cloud pública funcionan a través de un escenario que muestra una empresa con un típico sitio central y sucursal.

El ejemplo utilizado en esta sección es uno común: el movimiento fuera del correo electrónico interno servidores, soportados directamente por el personal de ti, al correo electrónico entregado como una oferta SaaS. Centrarse en el impacto de los sitios remotos de la empresa como sucursales.

Migrar flujos de tráfico al migrar a correo SaaS

En primer lugar, pensar en el flujo de tráfico dentro de una empresa antes de SaaS, cuando la empresa compra servidores, licencias de software de servidor de correo electrónico, instala el hardware y el software en una información interna Centro, y así sucesivamente. La compañía puede tener cientos o miles de sitios remotos, como la sucursal que se muestra en la figura 27-16. Para comprobar el correo electrónico, un empleado de la sucursal envía paquetes de un lado a otro con el servidor de correo electrónico en el sitio central, como se muestra.

 

 

La compañía entonces mira los muchos diversos costes para el email en este viejo modelo contra el nuevo modelo SaaS. Por ejemplo, Microsoft Exchange es un paquete de software muy popular para Construya esos servidores de correo de empresa. Microsoft, que como empresa es un actor importante en el espacio público en la nube con su servicio de Microsoft Azure, ofrece Exchange como un servicio SaaS. Por lo tanto, la empresa considera las opciones y decide migrar un correo electrónico SaaS Offering. Una vez migrados, los servidores de correo electrónico se ejecutan en la nube, pero como un servicio SaaS. La empresa que el personal, que son los clientes del servicio SaaS, no tiene que gestionar los servidores. Sólo para vuelta a algunas grandes ideas, como un servicio SaaS, el consumidor no se preocupa de instalar- VMS, el dimensionamiento de ellos, la instalación de Exchange o algún otro software de servidor de correo electrónico, y así sucesivamente. El consumidor recibe servicio de correo electrónico en este caso. La compañía tiene que hacer algunas migrar trabajo para mover el correo electrónico existente, contactos, etc., pero una vez migrado, todos los usuarios ahora Comuníquese con servidores de correo electrónico que se ejecutan en la nube como un servicio SaaS. Ahora piense en ese usuario de la sucursal empresarial, y los flujos de tráfico mostrados en la figura 27-17, cuando un usuario de sucursal envía o recibe un correo electrónico. Por ejemplo, piense en un correo electrónico con un gran apego, sólo para hacer el impacto más dramático. Si el diseño de la empresa se conecta sucursales a los sitios centrales sólo, este es el efecto neto sobre el tráfico WAN:

  • No se produce ninguna reducción en el tráfico \VAN privado, porque todo el correo electrónico de la sucursal el tráfico fluye hacia/desde el sitio central.
  • 100 por ciento del tráfico de correo electrónico (incluso los correos electrónicos internos) que fluye desde/hacia las sucursales ahora también fluye a través de la conexión a Internet, consumiendo el ancho de banda de la empresa Enlaces de Internet.

Sólo para hacer el punto, Imagine dos usuarios en la misma sucursal. Pueden ver cada otro a través de la habitación. Uno quiere compartir un archivo con el otro, pero la más conveniente forma en que saben compartir un archivo es enviar por correo electrónico el archivo como un adjunto. Así que uno de ellos envía un correo electrónico al otro, adjuntando el archivo de 20 MB al correo electrónico. Antes de usar SaaS, con un correo electrónico servidor en el sitio central, que el correo electrónico y el archivo que fluyen sobre la WAN privada, al correo electrónico servidor y, a continuación, de nuevo al cliente de correo electrónico del segundo usuario. Con este nuevo diseño, ese email con el accesorio de 20 MB fluiría sobre la WAN privada, luego a través de Internet al servidor de correo electrónico y, a continuación, de nuevo a través de Internet y la WAN privada cuando el segundo usuario descarga su email.

Sucursales con Internet y WAN privada

Para las empresas que ponen sus conexiones de Internet principalmente en los sitios centrales, este el modelo de nube publica puede causar problemas como el que acabamos de describir. Una manera de lidiar con esto el desafío particular es planificar la capacidad adecuada para los vínculos de Internet; otro es planificar capacidad para algunas conexiones WAN privadas a la nube pública. Otra opción existe como bueno: rediseñar la empresa WAN en un pequeño grado, y considerar la colocación directa de Internet conexiones en las sucursales. A continuación, todo el tráfico de Internet, incluyendo el tráfico de correo electrónico al nuevo servicio SaaS, podría ser enviado directamente, y no consumir el ancho de banda WAN privado o el ancho de banda del enlace de Internet del sitio central, como se muestra en la figura 27-18. El diseño de la figura 27-18 tiene varias ventajas. El tráfico fluye mucho más directamente. Es no desperdicia el ancho de banda WAN para el sitio central. Y conexión a Internet de banda ancha de las interconexiones son relativamente baratas hoy en día en comparación con las conexiones WAN privadas.

 

 

Sin embargo, cuando se agregan las conexiones de Internet por rama por primera vez, el nuevo los enlaces de Internet crean problemas de seguridad. Una de las razones por las que una empresa puede utilizar pocos enlaces a Internet, ubicados en un sitio central, es centrar los esfuerzos de seguridad en esos enlaces. El uso de una conexión a Internet en cada sucursal cambia ese enfoque. Pero muchas empresas no sólo utilizar el Internet en cada sitio, sino confiar en él como su única conexión WAN, como se muestra con VPN de Internet de nuevo en el capítulo 15.

Funciones y servicios de red virtual

Esta tercera y última sección importante del capítulo ahora mira más de cerca lo que sucede con funciones de red dentro del entorno Cloud público. En particular, esta sección introduce el concepto de una función de red virtual (VNF), mostrando cómo una nube pública la instalación podría implementar routers y firewalls como VMS. El resto de esta sección

analiza las opciones para cambiar la forma en que los DNS, DHCP y NTP podrían funcionar al migrar un aplicación desde el interior de una empresa a ser alojado en un servicio de nube pública.

Funciones de red virtual: firewalls y routers

Cuando comience a despegar las capas de lo que obtiene en un servicio de nube pública, puede comience a ver funciones y características familiares. Los proveedores de la nube pública no pueden usar terminología antigua para los enfoques tradicionales de la misma, pero a cualquiera que haya trabajado en ella, muchas de las ideas se miraran de manera familiar

 

Como ejemplo, tomemos el siguiente escenario básico en el que una empresa ordena un laaS servicio de un proveedor de Cloud pública:

  • El consumidor desea un número de servidores laaS.
  • Todas las VMs ejecutarán la misma aplicación; el consumidor desea que varias VMs se ocupen carga del servidor.
  • Debido a que ejecutan la misma aplicación, el consumidor no le importa qué servidor en particular cualquier un cliente utiliza, por lo que el consumidor quiere que el proveedor de nube para realizar la carga del servidor balanceado (SLB).
  • El consumidor usará Internet para todo el tráfico de usuarios a las VMs.

La figura 27-19 muestra el tipo de información que el consumidor recibiría del proveedor de la nube, junto con las funciones proporcionadas. Incluye una dirección IP pública (198.51.100.1). cada servidor laaS obtiene su propia dirección IP privada, desde el proveedor de la nube espacio de direcciones IPv4 privado. El proveedor realiza SLB como servicio (SLBaaS). (y no mostrado en la figura por ahora, el proveedor también proporciona algunos servicios de seguridad y DNS.)

 

Una vez que el proveedor de Cloud crea instancias de las VMs, el consumidor agrega las aplicaciones al VMS, y los usuarios pueden conectarse a la dirección IP pública como se muestra a la izquierda de la figura. Los usuarios se conectan a través de Internet (paso 1), a la dirección IP pública 198.51.100.1 (Step 2). la función NAT estática en el proveedor de Cloud (paso 3) se traduce en el privado asignado Dirección IPv4. Finalmente, en el paso 4, la carga de la función SLB balancea a cada usuario a uno de los Vms.

Como se muestra, todos los servicios ofrecidos por el proveedor de Cloud son servicios. El consumidor puede solicitar determinados tipos de servicio, como tener una dirección pública, y hacer la carga de servido. Sin embargo, como se muestra aquí, el consumidor no obtiene acceso al enrutador de nube que realiza NAT, o el dispositivo que realiza SLB. El consumidor necesitaba un servicio, la nube proveedor lo ofreció, el consumidor lo solicitó. Y funciona.

En otros casos, el consumidor puede sentir la necesidad de estar en control directo sobre función de Ing. Por ejemplo, muchos personales de ti podrían ver el diseño en la figura 27-19 y pregunta: ¿Aquí está el Firewall? O tal vez usted quiere utilizar VPN servicios, tal vez incluso DMVPN, terminado en un router. Como consumidor, es posible que desee tener un router en su parte de la nube pública: no es un servicio de router, sino un router propio, uno que controlas y Configurar. En ese caso, el consumidor de nube puede utilizar una función de red virtual. Una función de red virtual (VNF) es una instancia virtual de un dispositivo de red tradicional que el consumidor puede elegir utilizar en una nube. Por ejemplo, los proveedores de Cloud ofrecen diferentes servicios de seguridad, pero, además, ofrecen permitir a los consumidores ejecutar su propio firewall en la nube. Del mismo modo, el proveedor de Cloud enruta los paquetes y realiza otras funciones típicas del router, pero si un consumidor quiere el control total de un router, el consumidor de la nube puede ejecutar un virtual router como una VM. Cualquier dispositivo de red virtual es un VNF.

La figura 27-20 muestra un diseño común de la WAN pública para un inquilino (consumidor) en el que el el consumidor ha optado por añadir dos VNFs: un cortafuegos virtual y un enrutador virtual. El virtual Firewall podría ser un Cisco ASAv (es, la versión virtual de Cisco ASA firewall), ejecutando como una VM. Del mismo modo, el router podría ser un router Cisco, específicamente un Cisco Cloud Services Router (CSR), que es un router Cisco con el sistema operativo iOS XE funcionando como una VM. Esos dispositivos estarían disponibles para que el consumidor los configure y use tal como ellos usaría una versión física del mismo dispositivo.

 

Cuanto más Lea acerca de la tecnología de redes emergentes en la prensa, más verá una variedad de términos relacionados con el concepto de funciones virtuales en una red, por lo que ayuda a ser consciente de algunos de los términos relacionados. Por ejemplo, los temas del examen se refieren al término virtual infraestructura de red, que es un término amplio que se refiere al hecho de redes tradicionales funciones como enrutamiento, conmutación, etc. ocurren en el software, es decir, es virtual en lugar de Física. El término virtualización de funciones de red (NFV) es un término utilizado principalmente en el espacio del proveedor de servicios para cómo SPS virtualiza las funciones de red dentro de su red. (en los términos son definidos por ETSI, un cuerpo europeo de los estándares de Telco, consideran http://www.ETSI.org.) Con NFV, cada función de red, como el router CSR en la figura 27-20, entonces sería llamado un VNF.

DNS Services

Existen muchas opciones para los servicios DNS relacionados con una nube pública. Este siguiente tema funciona a través de un par de opciones comunes. En primer lugar, porque este libro pasa sólo un poco de tiempo con las discusiones de DNS, revisar algunos DNS Fundamentos sin Cloud, como se muestra en la figura 27-21. La figura muestra lo que sucede con DNS Cuando un usuario va a una página web y hace clic en un enlace para una aplicación, APL, como se muestra en la parte inferior de la página. En este escenario, el APL se ejecuta dentro de la empresa; es decir, es una aplicación tradicional, no se ejecuta en una nube privada o pública.

La acción de la figura sigue estos pasos numerados:

Paso 1.

El usuario hace clic en el enlace de APL; el vínculo incluye el nombre de dominio appl.example.com.

Paso 2.

El dispositivo del usuario envía una solicitud DNS para appl.example.com a la empresa Servidor DNS.

Paso 3.

El servidor DNS devuelve la dirección IP asociada a appl.example.com (10.1.1.1).

Paso 4.

El usuario se conecta a APL en el servidor que utiliza la dirección 10.1.1.1.

 

 

Ahora Imagine que el personal de TI de la empresa migra una aplicación diferente, App2, al público Nube. El proveedor de Cloud pública quiere que todos sus clientes tengan una buena experiencia, y para el servicio para trabajar bien. Así que cuando se pide el nuevo laaS VMS, el consumidor elige algunos Configuración. Como resultado de esas elecciones, el proveedor de Cloud asigna un Dirección IP (198.51.100.1) para las VMs, crea dinámicamente un nombre coincidente y agrega un registro de dirección para el nombre y la dirección del servidor DNS del proveedor de la nube. La nube Pro- vider también pone a disposición del consumidor toda esta misma información (nombre de host, dirección IP, y así sucesivamente).

Dado esos pasos, la empresa puede elegir hacer algo simple: apenas actualice su propio DNS para referirse a la dirección IP pública utilizada por su aplicación como ejecutada en la nube pública Proveedor. La figura 27-22 muestra el flujo de usuario después de realizar cambios en el DNS de la empresa.

 

 

Siguiendo los pasos de la figura:

Paso 1.

El usuario hace clic en el enlace de App2; el enlace incluye el nombre de dominio App2. Example.com.

Paso 2.

El dispositivo del usuario envía una solicitud DNS para App2.example.com a la empresa Servidor DNS.

Paso 3.

El DNS devuelve la dirección IP asociada a App2.example.com (198.51.100.1).

Paso 4.

El usuario se conecta a la aplicación en el servidor que utiliza la dirección 198.51.100.1.

Como otra opción, el consumidor puede confiar en el servicio DNS del proveedor de Cloud. El proveedor de Cloud crea automáticamente un registro DNS para cada VM. En este escenario, la compañía DNS todavía requiere un cambio para el nombre App2.example.com, pero en lugar de un a-registro que identifica la dirección IP, apunta al servidor DNS del proveedor de nube. Y el usuario. Las solicitudes de resolución DNS fluyen al DNS de la empresa y, a continuación, al DNS del proveedor de la nube, y luego de nuevo. Sin embargo, el resultado final es que el usuario aprende la misma dirección IP (198.51.100.1 en este caso) que se utiliza para el servicio laaS.

Servicios de asignación de direcciones y DHCP

Los proveedores de nube hacen un gran esfuerzo para suministrar direcciones IP a los hosts en el servicio, y para hágalo de forma automática y lo más simple posible. Saben que cualquier VM definida por una nube servicio, público o privado, necesita una dirección IP. Así que en lugar de hacer que cada cliente tome la tiempo y esfuerzo para configurar un VNF para que se ejecute como servidor DHCP y, a continuación, configurarlo, la nube el proveedor permite al consumidor especificar algunos criterios para las direcciones. Por ejemplo, el consumidor puede permitir que el proveedor de nube elija direcciones, o el consumidor puede especificar toda la IP direcciones a utilizar. A continuación, el proveedor de nube configura el direccionamiento automáticamente.

En primer lugar, considere el caso en el que el consumidor desea que la aplicación sea accesible directamente por Internet. El proveedor de la nube puede asignar una dirección IP pública. Entonces, la nube el proveedor puede dar a cada VM una dirección IP privada basada en la dirección IP privada del proveedor espacio. Como de costumbre, y como se ha visto anteriormente en la figura 27-19, el proveedor de Cloud utiliza NAT para traducir entre las direcciones públicas y privadas.

La figura 27-23 muestra tal ejemplo. El proveedor de Cloud utiliza 10.0.0.0 de red para sus direcciones privadas, y en este caso asigna direcciones desde la subred 10.2.2.0/24 a la nueva VMs para un inquilino en particular (consumidor). Tenga en cuenta que el proveedor de Cloud puede (y probablemente hace) utilizar DHCP detrás de las escenas, pero no hay ningún servidor DHCP requerido por el cliente como VNF, y ninguna configuración DHCP requerida por el cliente. La dirección IP pública utilizado para este servicio utiliza la dirección IP pública 198.51.100.1, que el proveedor de Cloud NATs a la dirección privada correcta en la red 10.0.0.0 en nombre del cliente. En cuanto a configura, el cliente elige opciones del catálogo de servicios de Cloud y el proveedor hace las direcciones coinciden.

 

 

Otros consumidores de la nube pueden querer un diseño de red diferente en la nube, requiriendo diferentes direcciones IP. Por ejemplo, al conectar una conexión WAN privada, el consumidor sólo los usuarios de empresas internas puedan llegar a las aplicaciones que se ejecutan en el Nube. En ese caso, tendría sentido utilizar sólo direcciones privadas y usar direcciones desde el espacio de direcciones IP del consumidor. Esas subredes entonces serían anunciadas en el resto de la empresa, al igual que cualesquiera otras subredes de la empresa.

La figura 27-24 muestra tal ejemplo. En este caso, la empresa crea una conexión VPN a la nube, terminando en un Cisco CSR (funcionando como un VNF). Que el túnel V PN privado direccionamiento utiliza la subred 172.16.1.0/24 desde el espacio de direcciones IP privadas del consumidor. Las VMs creadas por el proveedor de nube proceden de la subred 172.16.2.0/24. La empresa puede a continuación, anuncie las rutas para 172.16.2.0/24 en toda la empresa, para que todos los usuarios puedan alcanzar las aplicaciones basadas en la nube.

 

En los escenarios descritos con las dos últimas cifras, tenga en cuenta que el consumidor de la nube no Ejecute su propio servicio DHCP como VNF. Incluso en este segundo caso, con la figura 27-24, el el proveedor de Cloud realiza el servicio de asignación de direcciones, incluso con las direcciones procedentes del espacio de direcciones del consumidor. El consumidor sólo necesita hacer el correcto opciones en el catálogo de servicios de Cloud (es, en la página web o APIs del proveedor de la nube).

NTP

Para concluir la discusión sobre las funciones y los servicios de la red virtual, piense de nuevo en el tema del Protocolo de tiempo de la red (NT P), cubierto en la mitad ICNDI del examen CCNA R&S. NTP utiliza el concepto de servidores que suministran la información del reloj de la hora del día. Clientes NTP a continuación, reciba esa información en los mensajes NTP y ajustar (sincronizar) sus relojes para coinciden con el tiempo del servidor. Con el tiempo, el reloj del cliente debe sincronizarse para tener cerca del mismo tiempo que el servidor.

Los VNFs y las VMs en un servicio Cloud, ya sean privados o públicos, a menudo necesitan sincronizar su tiempo con el resto de los dispositivos y servidores en la empresa. Para ello, las VMs y VNFs se puede configurar como clientes NTP, haciendo referencia a los servidores ntp dentro de la empresa, como se muestra en la figura 27-25.

 

 

Si un consumidor ya está usando un VNF en la nube, como un router, podría tener más sentido para configurar ese enrutador para que actúe en el modo cliente/servidor NTP, como se muestra en la figura 27-26. En este ejemplo, un CSR corriendo en la nube hace justamente eso. El CSR primero actúa como cliente NTP, sincronizando su tiempo con el servidor NTP dentro de la empresa. La RSE también actúa como un servidor al VMS y al otro VNFs usado para eso consumidor (arrendatario).

¡ÚNETE A NUESTRO GRUPO DE #TELEGRAM https://t.me/joinchat/Gt2Ru0rFda0NR1VMfjWbEA!

 

Compartir esta publicación

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.