Google Cloud Platform para usuarios de OpenStack

Este artículo está diseñado para que las personas familiarizadas con OpenStack incorporen los conceptos clave a fin de comenzar a usar Google Cloud Platform (GCP), ya sea si consideran migrar o implementar una implementación híbrida.

Descripción general

En este artículo, primero, se comparan las arquitecturas de muestra de aplicaciones web de 3 niveles en OpenStack y en GCP. Luego, se comparan las características de OpenStack y GCP y se proporcionan tablas de referencia rápida que explican cómo los términos y conceptos de OpenStack se corresponden con los de GCP.

No se compararán los SDK, las API ni las herramientas de línea de comandos que proporcionan OpenStack y GCP.

Para obtener una lista completa de los productos de Google Cloud Platform, consulta Productos y servicios.

Servicios de computación en la nube

Los servicios de computación en la nube proporcionan un conjunto de servicios básicos que incluyen procesos informáticos, almacenamiento, herramientas de redes, administración de acceso y, a menudo, servicios de bases de datos.

Los servicios básicos de OpenStack incluyen lo siguiente:

  • Procesamiento: OpenStack Compute (Nova y Glance)
  • Almacenamiento: OpenStack Block Storage (Cinder)
  • Herramientas de redes: OpenStack Networking (Neutron)
  • Administración de identidades y accesos: OpenStack Identity Service (Keystone)

Los servicios básicos de Cloud Platform incluyen lo siguiente:

Precios de Google Cloud Platform

La mayoría de los servicios en GCP se ofrecen según un modelo de precios de pago por uso que incluye una facturación por segundo o por minuto y descuentos automáticos por un incremento en el uso. El modelo de precios de GCP ayuda a optimizar el rendimiento rentable para tus aplicaciones, en combinación con una asignación flexible de recursos como tipos personalizados de máquinas.

Para obtener información sobre herramientas y detalles de estimación de precios rápido, consulta la calculadora de precios.

¿Por qué elegir Google Cloud Platform?

Hace más de 15 años que Google desarrolla una de las infraestructuras en la nube más rápida, potente y con la mayor calidad del mundo. Google usa esta infraestructura de manera interna en varios servicios de tráfico alto y de escala global, entre ellos: Gmail, Maps, YouTube y Búsqueda. GCP pone esta infraestructura a tu disposición.

Compara las arquitecturas de muestra

En esta sección, se comparan las formas en que puedes compilar un sistema de aplicación web de 3 niveles en OpenStack y en GCP.

  • La configuración de OpenStack genera una configuración de copia de seguridad activa.
  • La configuración de GCP aprovecha los servicios administrados para generar una configuración de activo a activo.

Una aplicación web típica de 3 niveles consta de los siguientes componentes:

  • Balanceador de cargas
  • Servidor web
  • Servidor de aplicaciones
  • Servidor de base de datos

OpenStack: configuración de copia de seguridad activa

La configuración de muestra de OpenStack que aparece en la figura 1 cuenta con las características siguientes:

  • Implementas recursos en dos regiones como dos dominios con fallas separados para aumentar la redundancia.
  • La red usa una sola subred para todos los niveles en cada región y todos los servidores son instancias de máquina virtual (VM).
  • Defines los grupos de seguridad para las cuatro funciones del servidor y los asignas a las instancias adecuadas.
  • Un volumen de Cinder se adjunta al servidor de base de datos como un volumen de datos. Para garantizar que haya redundancia en los dominios con fallas, se crea una copia de seguridad de la base de datos en la región activa en el almacenamiento de objetos. Luego, cuando sea necesario, se restablece en el de la región de la copia de seguridad (esta arquitectura no usa la replicación de la base de datos en tiempo real porque el ancho de banda está limitado entre regiones).
  • Esta arquitectura proporciona una configuración de copia de seguridad activa. Cuando realizas una conmutación por error del servicio a otra región, debes restablecer la copia de seguridad más reciente en el servidor de base de datos en la región de la copia de seguridad.

App web de tres niveles

Figura 1: un sistema de aplicación web de 3 niveles de OpenStack

GCP: configuración de activo a activo

La configuración de muestra de GCP que aparece en la figura 2 cuenta con las características siguientes:

  • Implementas recursos en una subred única que cubre varias zonas en una sola región para aumentar la redundancia.
  • Implementas servidores web y servidores de aplicaciones como instancias de VM.
  • Defines reglas de firewall con etiquetas para especificar los destinos de los paquetes.
  • Configuras el control de acceso para la conexión de la base de datos en función de la dirección IP de origen como parte de la configuración de Cloud SQL. Cloud SQL es un servicio que administra GCP para las bases de datos de MySQL que proporciona replicaciones de datos entre varias zonas. La copia de seguridad de los datos programada y el proceso de conmutación por error son automatizados. Puedes acceder a la base de datos desde varias zonas en la misma región. La conmutación por error entre zonas es transparente para las aplicaciones que se ejecutan en instancias de VM. Puedes acceder a una sola instancia de Cloud SQL desde varias zonas. (Cloud SQL tiene dos generaciones: la primera y la segunda generación de Cloud SQL. Tienen características y comportamientos predeterminados diferentes para la replicación y la conmutación por error).
  • Google Cloud Load Balancing es un servicio de balanceo de cargas HTTPS con el que puedes usar una dirección IP (VIP) única y global para distribuir el acceso de los clientes en varias regiones y zonas.
  • La arquitectura proporciona una configuración de activo a activo en varias zonas, lo que genera un servicio redundante en los dominios con fallas.

App2 web de tres niveles

Figura 2: un sistema de aplicación web de 3 niveles en GCP

Compara las características

En esta sección, se comparan los detalles sobre las características que se usan en las arquitecturas de muestra.

Arquitectura de la red

En esta sección, se compara el funcionamiento de las redes de OpenStack y GCP dentro de las regiones y zonas y se analizan las instancias y los proyectos, las direcciones IP, la conmutación por error y las reglas de firewall.

Regiones y zonas

Descubre cómo se asignan los términos y conceptos de OpenStack a los de GCP:

OpenStack GCP Notas
Región Región En OpenStack, una región puede abarcar varios centros de datos. En GCP, una región corresponde a un campus de centro de datos que, por lo general, tiene varias compilaciones independientes.
Zona de disponibilidad Zona En OpenStack, una zona de disponibilidad se usa con frecuencia para identificar un conjunto de servidores que tienen un atributo común.

En GCP, una zona corresponde a un clúster dentro de un centro de datos.

En OpenStack, una región se define como un clúster único que administran los nodos de controlador dedicados. Una región consiste de zonas de disponibilidad. Debes usarlas para definir varios grupos de recursos, como los nodos de procesamiento y los soportes de almacenamiento.

En GCP, una región es un área geográfica independiente que consta de zonas. Las ubicaciones dentro de las regiones suelen tener latencias de red de ida y vuelta de menos de 5 ms en el percentil 95. Al igual que las zonas de disponibilidad de OpenStack, una zona es un área de implementación para los recursos de GCP dentro de una región. Una zona se debe considerar como un dominio con fallas único.

GCP proporciona una red interna dedicada en las regiones, de modo que el ancho de banda y la latencia entre zonas diferentes en la misma región se puedan comparar con el ancho de banda y la latencia dentro de una sola región. Puedes implementar una aplicación de clúster vinculada con firmeza a través de varias zonas sin tener que preocuparte por el ancho de banda y la latencia entre zonas.

En ambas plataformas, la implementación de tu aplicación en varias zonas o regiones puede ayudar a protegerte contra fallas inesperadas. En GCP, las zonas se consideran dominios con fallas independientes. Por el contrario, en OpenStack, las regiones (en lugar de las zonas de disponibilidad) se consideran dominios con fallas independientes, ya que las zonas de disponibilidad en una sola región comparten los mismos nodos de controlador. Para obtener una lista de las regiones y zonas de GCP, consulta Ubicaciones de Cloud.

Instancias y proyectos

Descubre cómo se asignan los términos y conceptos de OpenStack a los de GCP:

OpenStack GCP Notas
Instancia Proyecto Todos los recursos en GCP deben pertenecer a un proyecto. Los usuarios pueden crear sus propios proyectos nuevos.

En OpenStack, solo los administradores pueden crear instancias nuevas.

Debes configurar una Cuenta de Google para usar los servicios de GCP. GCP agrupa tu uso del servicio por proyecto. Puedes crear varios proyectos separados por completo con la misma cuenta y tus usuarios pueden crear sus propios proyectos con sus cuentas. Los recursos dentro de un mismo proyecto pueden trabajar juntos con facilidad, por ejemplo, mediante la comunicación a través de una red interna sujeta a las reglas de las regiones y zonas. Los recursos de cada proyecto están aislados de los de otros proyectos; solo puedes interconectarlos a través de una conexión de red externa.

Este modelo te permite crear espacios de proyectos para divisiones o grupos independientes dentro de la empresa. Además, también puede ser útil para realizar pruebas: cuando terminas un proyecto, puedes borrarlo y todos los recursos que creó el proyecto también se borrarán.

En OpenStack, se usa el término instancia a fin de referirse a una funcionalidad similar que aísla recursos para grupos diferentes. En OpenStack, solo los administradores de sistemas pueden crear instancias nuevas.

Configuraciones de red

Descubre cómo se asignan los términos y conceptos de OpenStack a los de GCP:

OpenStack GCP Notas
Neutron Cloud Virtual Network Cloud Virtual Network es un servicio de red administrado. En GCP, puedes definir varias redes en un proyecto y cada red es independiente.
Red privada virtual
Red privada virtual Una sola red privada virtual de GCP abarca todas las regiones conectadas a través de la red interna de GCP. Una red privada virtual de Neutron abarca todas las zonas de disponibilidad en una región.

En una implementación típica de Neutron de OpenStack, la red virtual de cada instancia se encuentra dentro de su propio espacio de red privada. Como se muestra en la figura 1, no es necesario que uses varias subredes, pero puedes configurar varias si lo necesitas. En la figura 3, se muestra una red virtual de OpenStack que consta de un solo router virtual y tres conmutadores virtuales. Dos de los conmutadores virtuales se conectan a la red externa a través del router virtual. AZ-1 y AZ-2 son zonas de disponibilidad.

/virtual-network/

Figura 3: ejemplo de una configuración de red de OpenStack

GCP ofrece dos tipos de red: heredada y subred.

La red heredada proporciona una sola subred privada que abarca todas las regiones del mundo, como se muestra en la figura 4.

En una red de subred, que se muestra en la figura 5, el conmutador virtual corresponde a un router virtual de Neutron de OpenStack y los conmutadores virtuales se conectan a través de la red interna. Todas las subredes se pueden enrutar entre sí a través de direcciones IP privadas, por lo que no necesitas usar direcciones IP globales o Internet para la comunicación interregional.

En GCP, puedes usar una combinación de redes heredadas y subredes en un proyecto. Cada proyecto nuevo incluye una red predefinida denominada predeterminada que, a su vez, contiene una subred llamada predeterminada en cada región.

Red heredada

Figura 4: ejemplo de una configuración de red heredada de Google Cloud Platform

red de subred

Figura 5: ejemplo de una configuración de red de subred de Google Cloud Platform

Direcciones IP

Descubre cómo se asignan los términos y conceptos de OpenStack a los de GCP:

OpenStack GCP
Las instancias tienen direcciones IP internas privadas. Se puede asignar una dirección IP global (una dirección IP flotante) si es necesario.

Las instancias tienen direcciones IP internas privadas. Además, cuando se crea una instancia mediante la herramienta de línea de comandos `gcloud`, se asigna una dirección IP efímera de forma automática. También se pueden asignar direcciones IP estáticas si es necesario.
Las direcciones IP globales son necesarias para la comunicación entre instancias en diferentes regiones o con distintos routers virtuales. Las subredes de todas las regiones se pueden enrutar entre sí a través de direcciones IP privadas, por lo que no necesitas usar direcciones IP globales o Internet para la comunicación entre instancias.

En Neutron, las instancias de VM en una red privada se comunican a través de conmutadores y routers virtuales mediante direcciones IP privadas asignadas en el inicio. Las direcciones IP globales no se asignan de forma predeterminada.

El router virtual controla el acceso desde las instancias de VM a la red externa, de modo que las instancias comparten la dirección IP global común asignada al router virtual. Si quieres exponer una instancia a la red externa y permitir que los usuarios externos se conecten, asigna una dirección IP flotante a la instancia desde un grupo de direcciones IP globales.

Debido a que la red virtual se encuentra dentro de una sola región, las instancias en regiones diferentes deben usar las direcciones IP flotantes para comunicarse a través de la red externa.

Una sola red puede incluir varios routers virtuales. Las instancias de VM conectadas a routers diferentes no pueden comunicarse de forma directa con direcciones IP privadas; sin embargo, se comunican a través de la red externa mediante direcciones IP flotantes.

En GCP, todas las instancias de VM tienen una dirección IP interna y una dirección IP externa en el inicio. Puedes desvincular las direcciones IP externas si es necesario.

De forma predeterminada, las direcciones IP externas son efímeras, lo que significa que están vinculadas a la vida de la instancia. Cuando apagas una instancia y luego vuelves a iniciarla, es posible que se le asigne una dirección IP externa diferente. También puedes solicitar una dirección IP permanente, denominada IP estática, para adjuntarla a una instancia. Una dirección IP estática es tuya hasta que decides liberarla y asignarla de forma explícita a instancias de VM. Las direcciones IP estáticas se pueden adjuntar y separar de las instancias según sea necesario.

Como se ilustra en las arquitecturas de muestra de aplicaciones web de 3 niveles, en la conmutación por error, en OpenStack, debes usar un mecanismo adicional, como el DNS dinámico, para permitir que los clientes sigan accediendo al servicio con la misma URL. Esto se debe a que no puedes usar la misma dirección IP global en regiones diferentes.

En cambio, en GCP, puedes usar una única dirección IP global (VIP) que proporciona Cloud Load Balancing para distribuir el acceso de los clientes a varias regiones y zonas. Esto proporciona una conmutación por error entre las regiones y zonas, que es transparente para los clientes.

Firewalls

Descubre cómo se asignan los términos y conceptos de OpenStack a los de GCP:

OpenStack GCP Notas
Aplica reglas de firewall a través de grupos de seguridad. Aplica reglas de firewall a través de reglas y etiquetas. Un grupo de seguridad de OpenStack contiene varias LCA que defines por la función de la instancia y, luego, asignas a una instancia.

Los grupos de seguridad de OpenStack se deben definir para cada región.

Las reglas y etiquetas de GCP se pueden definir una vez y usarse en todas las regiones.

En OpenStack, un solo grupo de seguridad contiene varias listas de control de acceso (LCA) que son independientes de las instancias de VM. Debes asignar un grupo de seguridad a una instancia de VM para aplicar las LCA a la instancia. Por lo general, los grupos de seguridad se definen de acuerdo con las funciones de la instancia de VM, como el servidor web o el servidor de base de datos.

Por ejemplo, para la arquitectura de muestra, define los grupos de seguridad siguientes destinados a cada región:

Grupo de seguridad Fuente Protocolo
load-balancer Cualquiera HTTP/HTTPS
Subred de administración SSH
web-server load-balancer HTTPS
Subred de administración SSH
web-application web-server TCP 8080
Subred de administración SSH
database web-application MYSQL
Subred de administración SSH

Puedes especificar la fuente del paquete con un rango de subred o el nombre de un grupo de seguridad. En la tabla anterior, el término subred de administración se refiere a un rango de subred desde el cual los administradores del sistema acceden al SO invitado con fines de mantenimiento.

En esta arquitectura, se da por sentado que el SSL del cliente termina en el balanceador de cargas, que se comunica con los servidores web mediante el uso de HTTPS. Los servidores web se comunican con los servidores de aplicaciones con TCP 8080. MySQL se usa para el servidor de base de datos.

Después de definir estos grupos de seguridad, debes asignarlos a cada instancia de la siguiente manera:

Instancia Grupo de seguridad
Balanceador de cargas load-balancer
Servidor web web-server
Servidor de aplicaciones web-application
Servidor de base de datos database

En GCP, mediante Cloud Virtual Network, puedes definir reglas de firewall que abarcan todas las regiones con una combinación de reglas y etiquetas. Una etiqueta es una identificación arbitraria asociada con una instancia de VM y puedes asignar varias etiquetas a una sola instancia de VM. Una regla es una LCA que permite que un paquete fluya con las siguientes condiciones:

  • Fuente: rango de IP, subred y etiquetas
  • Destino: etiquetas

Por ejemplo, primero debes definir una regla que permita enviar paquetes que tienen un puerto de destino TCP 80 desde cualquier dirección IP a la etiqueta del servidor web. Luego, puedes agregar la etiqueta del servidor web a cualquiera de las instancias de VM para permitirles acceso a conexiones HTTP. Se administran las etiquetas a fin de especificar las funciones de las instancias y las reglas para especificar las LCA que corresponden a las funciones por separado.

En la figura 6, se ilustran algunas reglas predefinidas para la red predeterminada en un proyecto recién creado. Por ejemplo, 10.128.0.0/9 es un rango de subredes que contiene subredes subyacentes en todas las regiones. Este rango de subredes puede ser diferente en cada proyecto. De principio a fin, las reglas permiten las siguientes conexiones de red:

  • Paquetes del protocolo de mensajes de control de Internet (ICMP) desde cualquier fuente externa
  • Cualquier paquete entre todas las instancias conectadas a la red predeterminada
  • Conexión al protocolo de escritorio remoto (RDP) desde cualquier fuente externa
  • Conexión a Secure Shell (SSH) desde cualquier fuente externa

Reglas de firewall predefinidas

Figura 6: reglas de firewall predefinidas en Virtual Cloud Network para la red predeterminada

Para obtener más información, consulta Uso de redes y firewalls.

En las reglas de firewall de GCP, debes usar etiquetas a fin de especificar los destinos de los paquetes y los rangos de subred o etiquetas para especificar las fuentes de los paquetes. En esta situación, define las reglas siguientes:

Fuente Destino Protocolo
130.211.0.0/22 web-server HTTP/HTTPS
web-server web-application TCP 8080
Subred de administración web-server, web-application SSH

En la tabla anterior, 130.211.0.0/22 es un rango de subred desde el cual el balanceador de cargas y el sistema de verificación de estado acceden al servidor web. El término subred de administración se refiere a un rango de subred desde el cual los administradores de sistemas acceden al SO invitado con fines de mantenimiento. web-server y web-application son etiquetas que se asignan al servidor web y al servidor de aplicaciones, de manera respectiva. En lugar de asignar reglas como lo harías con los grupos de seguridad, debes asignar etiquetas a las instancias según sus funciones.

El control de acceso para la conexión de la base de datos se configura según la dirección IP de origen como parte de la configuración de Cloud SQL.

Almacenamiento

Descubre cómo se asignan los términos y conceptos de OpenStack a los de GCP:

OpenStack GCP Notas
Volúmenes de Cinder Discos persistentes Almacenamiento continuo adjunto a la instancia

Con los discos persistentes de GCP, los datos se encriptan de forma automática antes de pasar de la instancia al almacenamiento en discos persistentes.

Discos efímeros N/A Almacenamiento efímero adjunto a las instancias
OpenStack Swift Cloud Storage Servicios de almacenamiento de objetos
Discos efímeros y volúmenes de Cinder

OpenStack ofrece dos opciones para los discos adjuntos a la instancia: discos efímeros y volúmenes de Cinder.

Los discos efímeros se diseñaron para usarlos como discos del sistema que contienen archivos del sistema operativo y los volúmenes de Cinder se diseñaron para almacenar datos de aplicaciones persistentes. Sin embargo, debido a que la migración en vivo no está disponible con discos efímeros, a menudo se usan los volúmenes de Cinder para los discos del sistema.

Cuando se usa un disco efímero como un disco del sistema, una imagen de la plantilla del SO se copia en el almacenamiento local de un nodo de procesamiento y la imagen local se adjunta a la instancia. Cuando se destruye la instancia, la imagen adjunta también se destruye.

Los volúmenes de Cinder proporcionan un área de disco persistente que se encuentra en dispositivos de almacenamiento externos. En las implementaciones típicas, el dispositivo de bloques se adjunta al nodo de procesamiento mediante el protocolo iSCSI y se adjunta a la instancia como un disco virtual. Cuando se destruye la instancia, el volumen adjunto permanece en el dispositivo externo y se puede reutilizar desde otra instancia.

El software de aplicación que se ejecuta en la instancia también puede acceder al almacenamiento de objetos que proporciona OpenStack Swift.

Disco efímero y volumen de Cinder

Figura 7: comparación entre un disco efímero y un volumen de Cinder en OpenStack

Discos persistentes

GCP ofrece almacenamiento continuo adjunto a una instancia en forma de discos persistentes que son similares a los volúmenes de Cinder en OpenStack. Debes usar un disco persistente como un disco del sistema que contiene archivos del sistema operativo y para almacenar datos persistentes de la aplicación. Los datos se encriptan de forma automática antes de pasar de la instancia al almacenamiento en discos persistentes. Puedes extender un solo disco persistente hasta 64 TB, pero la capacidad total máxima de los discos adjuntos se restringe según el tamaño de la instancia. Para obtener más información, consulta Opciones de almacenamiento.

Cuando necesitas un almacenamiento local de alto rendimiento, también puedes usar discos locales persistentes de estado sólido (SSD). Cada SSD local tiene un tamaño de 375 GB, pero puedes conectar hasta ocho dispositivos SSD locales por instancia para 3 TB de espacio total de almacenamiento SSD local. Ten en cuenta que la migración en vivo está disponible para las instancias con SSD locales adjuntos. Debido a que los datos en los SSD locales se copian entre las instancias durante la migración en vivo, el rendimiento del almacenamiento puede disminuir por un tiempo.

El software de aplicación que se ejecuta en la instancia puede acceder al almacenamiento de objetos que proporciona Cloud Storage, un servicio alojado para almacenar y acceder a una gran cantidad de objetos binarios o BLOB de diferentes tamaños.

Instancias de VM

Descubre cómo se asignan los términos y conceptos de OpenStack a los de GCP:

OpenStack GCP Nota
Tipo de instancia Tipo de máquina En OpenStack, los usuarios generales no pueden crear tipos personalizados de instancias.

En GCP, cualquier usuario puede crear tipos personalizados de máquinas.
Servicio de metadatos Servidor de metadatos OpenStack solo proporciona información sobre instancias.

GCP también proporciona información sobre proyectos.

Cuando inicias una instancia nueva de VM en OpenStack, debes elegir un tipo de instancia para especificar su tamaño, como la cantidad de CPU virtuales y la cantidad de memoria. Si tienes un derecho de acceso adecuado asignado por el administrador del sistema, puedes definir tipos de instancia adicionales. Los usuarios generales no pueden agregar tipos personalizados de instancias.

En GCP, los tamaños de instancias se definen como tipos de máquinas. Además de elegir uno de los tipos de máquina predefinidos, el usuario puede cambiar la cantidad de CPU virtuales y la cantidad de memoria por separado para crear un tipo de máquina personalizado. Para obtener más información, consulta Tipos de máquinas.

Metadatos

OpenStack proporciona un servicio de metadatos para recuperar información de la instancia de VM desde el sistema operativo invitado de la instancia (SO invitado), como el tipo de instancia, los grupos de seguridad y las direcciones IP asignadas. También puedes agregar metadatos personalizados en forma clave-valor. OpenStack proporciona un tipo de metadatos denominados datos del usuario. Puedes especificar un archivo de texto ejecutable como user-data cuando inicias una instancia nueva para que el agente de cloud-init que se ejecuta en el SO invitado realice las tareas de configuración de inicio de acuerdo con su contenido, como la instalación de paquetes de aplicaciones. Debes usar la URL en http://169.254.169.254/latest/meta-data para acceder a los metadatos desde el SO invitado.

GCP proporciona un servidor de metadatos para recuperar información sobre instancias y proyectos del SO invitado de la instancia. Todas las instancias del proyecto comparten los metadatos de este. Puedes agregar metadatos personalizados para metadatos de instancia y metadatos del proyecto en forma clave-valor. GCP proporciona metadatos especiales denominados startup-script y shutdown-script que se ejecutan cuando inicias o cierras las instancias de forma respectiva.

A diferencia de user-data de OpenStack, startup-script se ejecuta cada vez que reinicias la instancia. Las dos secuencias de comandos startup-script y shutdown-script se controlan mediante el agente incluido en los paquetes de imágenes de procesamiento que se preinstalan en las imágenes de las plantillas del SO. Para obtener más información, consulta Almacenamiento y recuperación de metadatos de instancias.

Usa una de las siguientes URL para acceder a los metadatos del SO invitado:

  • http://metadata.google.internal/computeMetadata/v1/
  • http://metadata/computeMetadata/v1/
  • http://169.254.169.254/computeMetadata/v1/
Agente del sistema operativo invitado
OpenStack GCP Notas
Paquete de agente de tareas de configuración de cloud-init Paquete de agente de tareas de configuración de compute-image-packages El agente de OpenStack solo controla la configuración de arranque inicial.

El agente de GCP controla la configuración de arranque inicial y los cambios de configuración dinámicos mientras se ejecuta la instancia.

En OpenStack, el paquete de agente llamado cloud-init está preinstalado en las imágenes estándar del SO invitado. Este controla las tareas de configuración inicial la primera vez que se inician, como la extensión del espacio del sistema de archivos raíz, el almacenamiento de una clave pública SSH y la ejecución de una secuencia de comandos proporcionada como datos del usuario.

En GCP, el paquete de agente llamado compute-image-packages está preinstalado en las imágenes estándar del SO invitado. Este controla las tareas de configuración inicial a través de startup-script la primera vez que se inician y, también, maneja la configuración dinámica del sistema mientras se ejecuta el SO invitado, como la adición de claves públicas SSH nuevas y el cambio de las configuraciones de red para el balanceo de cargas HTTP. Puedes generar y agregar una nueva llave SSH a través de Google Cloud Platform Console o la herramienta de línea de comandos de gcloud después de iniciar una instancia.

El SDK de Google Cloud está preinstalado en las imágenes estándar del SO invitado en GCP. Puedes usar el SDK para acceder a los servicios en GCP desde el SO invitado con una cuenta de servicio a la que se le otorgan ciertos privilegios de manera predeterminada.

Control de acceso

Google Cloud IAM aplica el control de acceso en GCP por instancia. Por ejemplo, si deseas que la aplicación que se ejecuta en una instancia almacene datos en Google Cloud Storage, puedes asignar el permiso de lectura y escritura a la instancia. Con Cloud IAM, no necesitas preparar contraseñas o códigos de credenciales de manera manual para las aplicaciones que se ejecutan en la instancia. Si quieres obtener más información, consulta Crea y habilita cuentas de servicio para instancias.

OpenStack Keystone proporciona control de acceso para las API del servicio según la cuenta de usuario, pero no proporciona control de acceso en función de la instancia para las API de la aplicación, como el permiso de lectura y escritura en el almacenamiento de objetos o la base de datos. Puedes implementar el control de acceso personalizado para las API de la aplicación si es necesario.

Más allá de IaaS: plataforma como servicio

En este artículo, se comparan los componentes y servicios que ofrece OpenStack y Google Cloud Platform que son esenciales para IaaS. Pero si quieres aprovechar al máximo GCP en términos de disponibilidad, escalabilidad y eficiencia operativa, debes combinar los servicios administrados como componentes básicos para todo el sistema.

Todos los servicios de GCP se extienden mucho más allá del concepto tradicional de una plataforma IaaS para incluir lo siguiente y más:

Pasos siguientes

  • Obtén más información sobre la integración de Google Cloud Dataproc con los servicios de almacenamiento, procesamiento y supervisión en todo GCP para crear una plataforma completa de procesamiento de datos.
  • Obtén más información acerca de la supervisión, el registro y los diagnósticos mediante Google Stackdriver.
  • Obtén más información sobre Google BigQuery, un almacén de datos administrado por completo para estadísticas que proporciona una plataforma sin servidores, por lo que puedas concentrarte en el análisis de datos con SQL, incluso con conjuntos de datos a escala de petabyte.
  • Obtén más información sobre los Productos y servicios de Google Cloud Platform.
¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Google Cloud Platform para usuarios de OpenStack