Google Cloud para profesionales de Azure: Almacenamiento

Actualizado el 24 de abril de 2019

Compara los servicios de almacenamiento que ofrecen Microsoft Azure y Google Cloud. En este artículo se analizan los siguientes tipos de servicios:

  • Almacenamiento de objetos distribuidos o almacenes clave-valor redundantes en los que puedes almacenar objetos de datos
  • Almacenamiento en bloque o volúmenes de discos virtuales que se pueden conectar a instancias de máquinas virtuales
  • Almacenamiento de archivos o almacenamiento basado en servidores de archivos conectados en red
  • Redes de áreas de almacenamiento o almacenamiento remoto con acceso a almacenamiento a nivel de bloques
  • Almacenamiento en frío o servicios de almacenamiento diseñados para almacenar copias de seguridad de datos
  • Almacenamiento de archivo o servicios de almacenamiento diseñados para almacenar datos de archivo con fines de análisis o cumplimiento

En este artículo no se analizan las colas de mensajes ni las bases de datos.

Comparación de los modelos de servicio

Los enfoques para la organización y la configuración de alto nivel de los servicios de almacenamiento difieren entre Microsoft Azure y Google Cloud. Sin embargo, en la práctica, estos servicios suelen ser más similares que distintos.

Microsoft Azure

En Azure, debes almacenar los distintos tipos de datos, incluidos objetos binarios (blobs), bases de datos y colas de mensajes, en servicios específicos dentro de una cuenta de almacenamiento. Azure requiere que definas el tipo de cuenta, de disco y de redundancia en el nivel de la cuenta de almacenamiento. Luego, estos atributos se aplican a todos los servicios de almacenamiento dentro de esa cuenta.

Estos son los tres tipos de cuentas de almacenamiento que hay en Azure: cuentas de uso general v1 (GPv1), cuentas de almacenamiento de blobs y cuentas de uso general v2 (GPv2). Las cuentas GPv1 admiten todos los tipos de almacenamiento estándar de Azure y las cuentas de almacenamiento de blobs admiten funcionalidades avanzadas de Azure Blob Storage. Las cuentas GPv2 admiten las API y las funciones de los dos tipos de cuentas anteriores.

Si bien las cuentas de almacenamiento de blobs se ejecutan exclusivamente en unidades de disco duro (HDD), ambas cuentas de uso general se dividen aún más en cuentas de almacenamiento estándar, que se ejecutan en HDD, y cuentas de almacenamiento Premium, que se ejecutan en unidades de estado sólido (SSD). Este último tipo de cuenta solo admite blobs de página.

Al momento de crear una cuenta de almacenamiento nueva en Azure, debes seleccionar el nivel de replicación que quieres usar. Azure ofrece los siguientes niveles:

  • Almacenamiento con redundancia local (LRS): replica los datos a nivel local dentro del centro de datos que contiene la cuenta de almacenamiento. Los datos se replican en tres ocasiones.
  • Almacenamiento con redundancia de zona (ZRS): replica los datos entre una o dos regiones con coherencia eventual. Al igual que con el LRS, los datos se replican tres veces a nivel local. El ZRS se limita al almacenamiento de blobs en bloque en cuentas de almacenamiento de uso general.
  • Almacenamiento con redundancia geográfica (GRS): replica los datos en una región principal y también en una región secundaria ubicada a 161 km de distancia, como mínimo. Los datos se replican tres veces en la región principal y después tres veces de forma asíncrona en la región secundaria.
  • Almacenamiento con redundancia geográfica de acceso de lectura (RA-GRS): es idéntico al GRS, pero agrega un extremo secundario de solo lectura en la región secundaria.

Google Cloud

De forma similar a Azure, Google Cloud almacena los distintos tipos de datos en servicios de tipo específico. Sin embargo, Google Cloud no tiene una capa de organización de alto nivel, como una cuenta de almacenamiento. En su lugar, se pueden crear recursos de almacenamiento y definir sus atributos, como el tipo de disco o redundancia, en el nivel de servicio.

Google Cloud ofrece Cloud Storage para el almacenamiento de objetos distribuidos y este es similar al almacenamiento en bloques y Append Blob de Azure Blob Storage. Para el almacenamiento en bloque, Google Cloud ofrece discos persistentes de Compute Engine, que son equivalentes a los VHD de Azure.

Almacenamiento de objetos distribuidos

Para el almacenamiento de objetos distribuidos, Azure ofrece Azure Blob Storage y Google Cloud ofrece Cloud Storage.

Azure Blob Storage y Cloud Storage son similares en muchos aspectos. En ambos servicios, se almacenan objetos binarios dentro de una unidad de almacenamiento con nombre. En Azure Blob Storage, estos objetos binarios se conocen como blobs y la unidad de almacenamiento se llama contenedor. En Cloud Storage, los objetos binarios se llaman objetos y la unidad de almacenamiento se conoce como depósito.

En ambos servicios, cada objeto binario dentro de una unidad de almacenamiento se identifica con una clave única dentro de la unidad de almacenamiento, además cada objeto se asocia con un registro de metadatos. Este registro de metadatos contiene información como el tamaño del objeto, la fecha de la modificación más reciente y el tipo de medio. Con los permisos adecuados, puedes ver y modificar algunos de estos metadatos. También puedes personalizarlos, si lo necesitas.

Si bien los depósitos y los contenedores son almacenes clave-valor, la experiencia del usuario de cada uno se diseñó para ser similar, pero no idéntica, a la de los sistemas de archivos. Por regla general, las claves de los objetos suelen ser rutas de acceso como “/foo/bar.txt” o “/foo/subdir/baz.txt”. Azure y Cloud Storage ofrecen API similares a los sistemas de archivos, por ejemplo, tanto el método List Blobs de Azure Blob Storage como el método list de Cloud Storage pueden enumeran todas las claves de objeto con un prefijo común, como ocurriría con ls -R en un sistema de archivos similar a Unix.

Además de su uso más evidente, el almacenamiento de objetos distribuidos, ambos servicios sirven para alojar contenido web y medios estáticos.

A continuación, se presenta una comparación entre las funciones y la terminología de Azure Blob Storage y Cloud Storage:

Función Azure Blob Storage Cloud Storage
Unidad de implementación Contenedor Depósito
Identificador de la implementación Clave única al nivel de la cuenta Clave única global
Emulación de sistemas de archivos Limitado Limitado
Tipos de objetos BLOB en bloque, BLOB de agregación, BLOB de página Objetos
Metadatos del objeto
Control de versiones de los objetos Manual, según las capturas de instantáneas de los objetos Control de versiones automático de todos los objetos de un depósito (se debe habilitar)
Administración del ciclo de vida de los objetos Sí (mediante reglas de ciclo de vida o Azure Automation) Sí (nativo)
Notificaciones de cambios de objetos Sí (mediante Azure Event Grids) Sí (mediante Pub/Sub)
Clases de servicio Niveles de redundancia: LRS, ZRS, GRS, RA-GRS
Niveles: Hot, Cool, Archive
Standard, Nearline, Coldline, Archive
Localidad de implementación Zonal y regional Regional y multirregional
Redundancia

Tipos de BLOB

En Azure Blob Storage, los datos se almacenan como blobs en bloque, Append Blobs o blobs de páginas. En Cloud Storage, los datos se almacenan como objetos, que son equivalentes a los BLOB en bloque. Google Cloud no proporciona un servicio o un tipo de objeto directamente comparable con los BLOB adjuntos. Sin embargo, puedes usar la funcionalidad de composición de objetos y los controles de simultaneidad de Cloud Storage para replicar la funcionalidad de un Append Blob. Consulta Objetos compuestos y subidas en paralelo para obtener más información.

A diferencia de Azure, Google Cloud no almacena los volúmenes de disco como BLOB de página dentro de su servicio de almacenamiento de objetos. En cambio, tus volúmenes de disco se almacenan en Compute Engine, la infraestructura de Google Cloud como una oferta de servicios. Consulta Almacenamiento en bloque para obtener más información.

Niveles de acceso y réplicas

La flexibilidad de Azure Blob Storage depende del tipo de cuenta de almacenamiento que se haya creado, además de las opciones de réplicas que se configuraron en esta. Las cuentas de almacenamiento GPv1 limitan el uso al nivel predeterminado de Azure para almacenamiento de blobs. Sin embargo, las cuentas GPv2 y de almacenamiento de blobs permiten elegir entre los niveles de acceso frecuente, esporádico y de archivo de Azure Blob Storage. Como sus nombres lo indican, el nivel de acceso frecuente se diseñó para los datos de uso frecuente, el de acceso esporádico para los datos de uso poco frecuente y el último, para el archivo de datos. El nivel de replicación de los servicios de Azure Blob Storage se determina en función del tipo de replicación de la cuenta de almacenamiento.

Por el contrario, los tipos de replicación de Cloud Storage se incorporan en las clases de servicio. A continuación, se presenta una comparación entre estas clases de servicio y los tipos de replicación y niveles de acceso de Azure Blob Storage:

Configuración Azure Google Cloud
Datos de acceso frecuente con redundancia geográfica Azure Blob Storage (de uso general o nivel de acceso frecuente) con GRS o RA-GRS Almacenamiento estándar en una región doble o multirregión
Datos de acceso frecuente con redundancia regional Azure Blob Storage (de uso general) con ZRS Almacenamiento estándar en una región
Datos de acceso frecuente con redundancia local (centro de datos) Azure Blob Storage (de uso general o nivel de acceso frecuente) con LRS Almacenamiento estándar en una región*
Datos de acceso infrecuente Nivel de acceso esporádico de Azure Blob Storage Cloud Storage Nearline y Cloud Storage Coldline
Datos de archivo Nivel de archivo de Azure Blob Storage Cloud Storage Archive

* La redundancia regional es el nivel más bajo de redundancia disponible en Google Cloud.

Control de versiones de los objetos

Tanto Azure como Cloud Storage permiten controlar las versiones de los objetos almacenados mediante el almacenamiento de versiones distintas de un objeto con una clave específica bajo ID de versión diferentes. Sin embargo, en ambos servicios, la implementación de esta funcionalidad varía.

En Azure Blob Storage, las versiones se pueden controlar mediante instantáneas de solo lectura de los blobs. Si los archivos se suben de manera programática, puedes capturar otra instantánea antes de cada subida. Azure Blob Storage también te permite especificar las condiciones de acceso, para evitar que se creen instantáneas innecesarias.

Por el contrario, Cloud Storage permite habilitar el control automático de las versiones de todos los objetos de un depósito. Si se habilita esta función, Cloud Storage creará automáticamente una versión nueva de un objeto cada vez que este se modifique. Con este enfoque se simplifica el proceso de control de versiones de los objetos, pero es un tanto menos flexible que el método de Azure. Los costos de almacenamiento pueden aumentar, ya que cada versión de un objeto también se considera en el total de datos almacenados. Este problema se puede mitigar con la administración del ciclo de vida de los objetos de Cloud Storage.

Controles de simultaneidad

Según sus configuraciones predeterminadas, Azure Blob Storage y Cloud Storage usan una estrategia de "la última escritura gana". Esta estrategia funciona con las escrituras secuenciales, pero permite que se generen condiciones de carrera si se realizan escrituras simultáneas en el mismo objeto. A fin de mitigar este problema, ambos servicios cuentan con mecanismos que permiten administrar las escrituras simultáneas.

En Azure, se pueden administrar las escrituras simultáneas de forma optimista o pesimista, como se detalla a continuación:

  • Enfoque optimista: el encabezado de la ETag de un objeto se recupera cuando se realiza una operación GET y luego se compara esa ETag con la del objeto actual cuando se intenta realizar una escritura. La escritura se confirma si las etiquetas coinciden.
  • Enfoque pesimista: se asigna el objeto de destino y se bloquea durante un período específico mientras se realiza la escritura.

Cloud Storage usa un enfoque optimista. Para administrar las escrituras simultáneas, se debe obtener el número de generación actual de un objeto determinado y, luego se usa con fines de confirmación cuando la secuencia de comandos o la aplicación intentan escribir. La escritura se confirma si los números coinciden. Si no es el caso, la transacción se anula y se reinicia. Consulta Control de versiones de objetos y de simultaneidad.

Administración del ciclo de vida de los objetos

La administración del ciclo de vida de Azure Blob Storage ofrece políticas basadas en reglas para GPv2 y cuentas de almacenamiento de blobs. Puedes utilizar estas políticas si deseas transferir tus datos a los niveles de acceso adecuados o para que caduquen al final del ciclo de vida de los datos. Las reglas de administración del ciclo de vida de objetos de Azure admiten situaciones, como archivar o borrar datos según la antigüedad, archivar datos en la transferencia y eliminar instantáneas antiguas.

Cloud Storage permite automatizar la eliminación de los objetos en función de las políticas de ciclo de vida especificadas por el usuario. Consulta Administración del ciclo de vida de los objetos para obtener más información.

Si bien Azure Blob Storage no cuenta con una función nativa para administrar el ciclo de vida, Azure Automation permite automatizar la eliminación de objetos.

Notificaciones de cambios de objetos

Tanto Azure como Google Cloud proporcionan un modelo de publicación/suscripción que te permite enviar y recibir notificaciones cuando se modifican tus objetos. Con Azure Blob Storage, puedes usar Azure Event Grid para supervisar los eventos de Blob Storage y enviarlos a un webhook, Azure Function u otros extremos. De manera similar, Google Cloud proporciona notificaciones de Pub/Sub, que te permiten publicar notificaciones en un tema de Pub/Sub cuando se crean, borran o actualizan dentro de un depósito de Cloud Storage. Para recibir estas notificaciones, puedes suscribirte a este tema de Pub/Sub desde otras aplicaciones o servicios.

Encryption

Azure admite la encriptación en reposo mediante Azure Storage Service Encryption (SSE) para datos en reposo. Todo el almacenamiento basado en BLOB dentro de la cuenta de almacenamiento se encripta con AES256 durante la entrada y se desencripta durante la salida. Si habilitas la encriptación para tu cuenta después de haber subido los datos, esos datos no se encriptarán hasta que se reescriban. Azure también es compatible con las claves de encriptación administradas por el cliente (CMEK) para el cifrado del lado del servidor (SSE). SSE para Azure Blob Storage y Azure Files está integrado con Azure Key Vault, a fin de que puedas usar un almacén de claves para administrar tus claves de encriptación.

Del mismo modo, todos los datos almacenados en los servicios de almacenamiento de Google Cloud, incluido Cloud Storage, se encriptan automáticamente en reposo con AES256 o AES128. Para los datos que requieren que administres tu propia clave de encriptación, Google Cloud también admite CMEK con Cloud Key Management Service y claves de encriptación proporcionadas por el cliente (CSEK). Consulta Encriptación en reposo en Google Cloud Platform para obtener más información.

Acuerdo de Nivel de Servicio

Microsoft y Google ofrecen Acuerdos de Nivel de Servicio (ANS) de tiempo de actividad y cuentan con políticas para otorgar créditos a las cuentas de los clientes en el caso de que los ANS no se cumplan. Microsoft define las garantías y políticas de Azure Blob Storage en el ANS de almacenamiento de Azure. Por su parte, Google define las garantías y políticas en el ANS de Cloud Storage.

Costos

Azure Blob Storage

Los precios de Azure Blob Storage se calculan en función de la cantidad de datos que se almacenan al mes, el tipo de cuenta de almacenamiento, el tipo de replicación y la salida de red. Si capturas instantáneas de los objetos, estas se cobran con las mismas tarifas que las versiones publicadas de los mismos. Azure Blob Storage también cobra las solicitudes comunes a la API.

Cloud Storage Standard

El precio de Cloud Storage Standard depende de la cantidad de datos almacenados por mes y de la salida de la red. En el caso de los depósitos que tienen habilitado el control de versiones de objetos, cada versión archivada de un objeto se cobra a la misma tarifa que la versión publicada. Cloud Storage Standard también cobra por solicitudes comunes a la API.

Almacenamiento en bloque

Google Cloud y Azure ofrecen opciones de almacenamiento en bloque. Google Cloud proporciona almacenamiento en bloque en forma de discos persistentes, que son parte de Compute Engine. Azure ofrece almacenamiento en bloque a través de los BLOB de páginas, que se almacenan en contenedores pertenecientes a cuentas de almacenamiento de uso general. En ambas plataformas también se ofrece la opción de usar SSD conectados localmente.

Comparación de los modelos de servicio

Aparte del método en que se almacenan, los discos persistentes de Compute Engine y los discos duros virtuales de Azure (VHD) son muy similares en la mayoría de los aspectos. En ambos casos, los volúmenes de discos se conectan en red, aunque tanto Compute Engine como Azure también brindan la capacidad de conectar un disco de manera local si es necesario. Si bien los discos conectados en red tienen una latencia operativa más alta y menos capacidad de procesamiento que los discos conectados localmente, también tienen muchos beneficios, como la redundancia incorporada, la captura de instantáneas y la facilidad para desconectar discos y volver a conectarlos.

VHD de Azure

Azure almacena los VHD como blobs de páginas. Estos blobs pueden tener un tamaño máximo de 8 TB mientras que los VHD solo de 4 TB. Las máquinas virtuales (VM) de Azure imponen límites según el tipo de máquina para la cantidad de VHD que se pueden conectar a la vez.

Cada VHD debe encontrarse en una cuenta de almacenamiento de la misma región que la VM a la cual se conectó. La latencia y la capacidad de procesamiento de los VHD dependen del tipo de cuenta de almacenamiento y el tipo de máquina de la VM, como se detalla a continuación:

  • Las cuentas de Azure Standard Storage se ejecutan en HDD estándar y se recomiendan para los casos prácticos con datos de acceso esporádico o de almacenamiento masivo.
  • Las cuentas de Azure Premium Storage se ejecutan en unidades SSD y se recomiendan para las operaciones intensivas de E/S. El nivel Premium Storage solo admite replicación LRS. Si prefieres administrar los discos manualmente en lugar de permitir que los administre Azure, puede que tengas que crear otra cuenta de almacenamiento específica para los VHD respaldados por SSD, debido a que el nivel Premium Storage solo está disponible con los VHD. Algunas máquinas de nivel bajo, como A0, no son compatibles con los VHD respaldados por SSD.

Los discos administrados por Azure son una forma de usar los VHD con las VM de Azure. Es una abstracción de los BLOB de página, contenedores de BLOB y cuentas de almacenamiento. Existen cuatro tipos de discos administrados: Ultra SSD, SSD premium, SSD estándar y HDD estándar.

Discos persistentes de Compute Engine

Google Cloud proporciona almacenamiento en bloque en forma de discos persistentes que se almacenan en Compute Engine. En la mayoría de las instancias de VM de Compute Engine con tipos personalizados de máquinas o tipos de máquinas predefinidos, puedes adjuntar hasta 128 discos persistentes. Las instancias con tipos de máquina de núcleo compartido están limitadas a un máximo de 16 discos persistentes. También puedes conectar hasta 257 TB de almacenamiento en discos persistentes por cada instancia de VM y cada disco persistente tiene un límite de tamaño de 64 TB. Los discos persistentes pueden ser HDD o SSD. Al igual que con Azure, debes crear el volumen de disco en la misma zona que la instancia de VM a la que se conectará el disco.

A continuación, se presenta una comparación entre los discos persistentes de Compute Engine y las ofertas de Azure Storage:

Función VHD de Azure Discos persistentes de Compute Engine
Tipos de volúmenes Standard Storage (HDD), Premium Storage (SSD) Disco persistente estándar (HDD), disco persistente SSD
Esquemas de administración Discos no administrados, discos administrados N/A (administrado por Google Cloud a nivel de proyecto)
Adjunto de volúmenes Solo se pueden adjuntar a una instancia a la vez Volúmenes de lectura y escritura: se pueden adjuntar a una sola instancia a la vez
Volúmenes de solo lectura: se pueden adjuntar a varias instancias
Tamaño máximo del volumen 4 TiB 64 TB
Redundancia
Captura de instantáneas
Encriptación de los discos Encriptado según la configuración predeterminada Encriptado según la configuración predeterminada

A continuación, se presenta una comparación entre los discos conectados localmente de Compute Engine con los de Azure:

Función Azure Compute Engine
Nombre del servicio Disco SSD local Disco SSD local
Conexión de volúmenes Vinculada al tipo de instancia Se puede conectar a cualquier instancia de núcleo no compartido
Volúmenes conectados por instancia Varía según el tipo de instancia Hasta 8
Capacidad de almacenamiento Varía según el tipo de instancia 375 GB por volumen
Migración en vivo No
Redundancia Ninguna Ninguna

Replicación

En Azure Storage, según el tipo de máquina y el tipo de cuenta de almacenamiento, puedes replicar los VHD para la redundancia. Puedes replicar tus datos de forma local en una unidad de escala de almacenamiento mediante el uso del almacenamiento redundante local (LRS), en tres zonas de disponibilidad a través del almacenamiento redundante por zonas (ZRS) o en regiones mediante el almacenamiento redundante geográfico o geográfico de acceso de lectura (GRS o RA-GRS).

Puedes replicar los discos persistentes de Compute Engine dentro de una sola región del servicio. Si diseñas sistemas sólidos en Compute Engine, considera usar discos persistentes regionales para mantener una alta disponibilidad de recursos en varias zonas. Los discos persistentes regionales proporcionan replicación síncrona para cargas de trabajo que podrían no tener replicación a nivel de aplicación.

Si bien cada servicio ofrece replicación para una mayor durabilidad, esta función no protege contra la corrupción de los datos o las eliminaciones accidentales debido a errores de los usuarios o la aplicación. A fin de proteger los datos importantes, los usuarios deben crear copias de seguridad de los datos y capturar instantáneas de los discos con regularidad.

Conexión y desconexión de volúmenes

Tras crear un volumen de disco, puedes conectar el volumen a una VM. Las instancias de VM de Azure y VM de Compute Engine funcionan de manera similar. Luego, la instancia de VM puede activar y formatear el volumen del disco como con cualquier otro dispositivo de bloques. De manera similar, puedes desactivar y desconectar un volumen desde una instancia, lo que permite que se vuelva a conectar a otras instancias.

Un VHD de Azure se puede conectar a una sola VM a la vez. Los discos persistentes de Compute Engine tienen la misma limitación en el modo de lectura y escritura. Sin embargo, los discos persistentes en modo de solo lectura se pueden conectar a varias instancias a la vez.

Copias de seguridad de los volúmenes

Compute Engine y Azure permiten que los usuarios capten y almacenen instantáneas de los volúmenes de discos. Estas instantáneas se pueden usar para crear volúmenes nuevos posteriormente.

Los discos persistentes de Compute Engine y los discos no administrados de Azure son compatibles con las instantáneas diferenciales. La instantánea inicial crea una copia completa del volumen y las posteriores solo copian los bloques que cambiaron desde la instantánea anterior. Después de que se captura una cantidad determinada de instantáneas diferenciales, se captura otra instantánea completa, y así sucesivamente.

En la actualidad, los discos administrados de Azure no admiten las instantáneas diferenciales. En su lugar, cada instantánea crea una copia completa del volumen del disco. La compatibilidad de las API facilita las instantáneas incrementales, las cuales no se proporcionan de forma predeterminada.

Azure también ofrece Azure Backup y Azure Recovery Service, que permiten automatizar las operaciones de copia de seguridad y restablecimiento. Google Cloud no proporciona servicios equivalentes a estos.

Rendimiento del volumen

El rendimiento de los discos, tanto de los discos persistentes de Compute Engine como de los VHD de Azure, depende de varios factores, como los que se indican a continuación:

  • Tipo de volumen: cada servicio ofrece varios tipos de volúmenes distintos. Y cada uno cuenta con sus propias características y límites de rendimiento.
  • Ancho de banda disponible: la capacidad de procesamiento de un volumen conectado en red depende del ancho de banda de red disponible para la VM de Compute Engine o Azure a la que está conectado.

En esta sección se analizan los detalles de rendimiento adicionales para cada servicio.

VHD de Azure

El rendimiento de red de los tipos de VM de Azure varía ampliamente. Es posible que los tipos de VM con pocos núcleos no cuenten con la capacidad de red suficiente para alcanzar el máximo publicitado de IOPS o capacidad de procesamiento en un tipo de disco de VHD en particular. Consulta Premium Storage de alto rendimiento y discos administrados para VM si quieres obtener más información.

Discos persistentes de Compute Engine

Compute Engine asigna la capacidad de procesamiento en función de los núcleos. Puedes usar 2 Gbps de salida de red por cada núcleo de CPU virtual con un máximo teórico de 16 Gbps para una sola instancia de máquina virtual. Debido a que Compute Engine usa un factor de redundancia de los datos de 3.3 veces, cada escritura lógica en realidad requiere 3.3 veces el valor de escritura del ancho de banda de red. Por ello, es posible que los tipos de máquina con pocos núcleos no tengan la capacidad de red suficiente para alcanzar el máximo publicitado de IOPS o capacidad de procesamiento con ciertos tipos de discos persistentes. Consulta Límites de salida de red para obtener más información.

En cada tipo de disco de Compute Engine, la capacidad total de E/S disponible se relaciona con el tamaño total de los volúmenes conectados a una instancia determinada. Por ejemplo, si hay dos discos persistentes estándar de 2.5 TB conectados a una instancia, la capacidad total de E/S disponible será de 3,000 IOPS de lectura y 7,500 IOPS de escritura.

Discos conectados localmente

Además del almacenamiento en bloque estándar conectado en red, Azure y Compute Engine permiten que los usuarios usen SSD conectados localmente a la máquina física que ejecuta la instancia. Los discos se conocen como SSD locales en ambos entornos. Estos discos brindan tasas de transferencia muy superiores a las del almacenamiento en bloque conectado en red. Sin embargo, a diferencia de este último, no garantizan la persistencia de los datos y no se puede capturar instantáneas de estos con funciones de captura diferenciales y nativas.

En Azure, el tamaño y la disponibilidad de los SSD locales depende directamente del tipo de máquina. El tamaño mínimo de los SSD locales es de 16 GB y el máximo es de 6 TB. Algunos tipos de máquina, como las de la serie A, no incluyen SSD locales.

En Compute Engine, los SSD locales se pueden conectar a casi todos los tipos de máquina, menos los de núcleo compartido, como f1-micro y g1-small. Los SSD locales tienen un tamaño fijo de 375 GB por disco y se puede conectar un máximo de 8 a una sola instancia para un total de 3 TB.

Compute Engine migra los SSD locales de forma automática y fluida antes de que sus máquinas host se desactiven para someterlas a mantenimiento. Consulta Migración en vivo para obtener más información.

Costos

En Azure, los precios de los volúmenes de discos se calculan por GB y por mes. Los cobros de los SSD locales se incluyen en el costo de la VM.

Los precios de los discos persistentes de Compute Engine y sus instantáneas se calculan por GB y por mes. Los SSD locales se cobran aparte de los costos de las máquinas. Consulta Precios de los SSD locales para obtener más detalles.

Almacenamiento de archivos

Para las cargas de trabajo basadas en servidores de archivos, Azure ofrece Azure Files, un servicio de servidor de archivos distribuido basado en SMB.

Google Cloud ofrece Filestore, un servicio de almacenamiento de archivos completamente administrado dirigido a aplicaciones que requieren una interfaz de sistema de archivos y un sistema de archivos compartido para los datos. Filestore brinda a los usuarios una experiencia simple y nativa para levantar el almacenamiento en red adjunto (NAS) administrado con instancias de Compute Engine y Google Kubernetes Engine.

Red de área de almacenamiento (SAN)

Azure permite la integración con StorSimple, un dispositivo de SAN de propiedad de Microsoft, para las cargas de trabajo de SAN. A nivel de arquitectura, StorSimple consta de una SAN de StorSimple local y un dispositivo virtual basado en la nube que replica el comportamiento de la SAN local.

En Google Cloud, puedes usar discos persistentes para admitir cargas de trabajo que esperan SAN. En el contexto de las SAN, los discos persistentes son análogos de los volúmenes de discos lógicos a los que se accedería mediante dispositivos de número de unidad lógica (LUN) y se pueden aprovisionar de forma similar. Al igual que con los volúmenes de discos lógicos basados en LUN, puedes activar varios discos persistentes en una sola instancia de VM. También puedes activar un único disco persistente de solo lectura en varias instancias de VM. Consulta Google Cloud Platform para profesionales de centros de datos: Almacenamiento a fin de obtener más información.

Almacenamiento en frío

Google Cloud y Azure ofrecen una opción de almacenamiento atractiva para los datos a los que no es necesario acceder con frecuencia. Cloud Storage ofrece clases adicionales denominadas Cloud Storage Nearline y Cloud Storage Coldline, mientras que Azure Blob Storage ofrece un nivel Cool adicional.

Latencia

En ambos servicios, el tiempo que tarda enviar el primer byte es de milisegundos.

Replicación

Con el nivel de acceso esporádico de Azure Blob Storage, los datos se replican según el tipo de replicación que use la cuenta de almacenamiento. Cuando usas Cloud Storage Nearline o Cloud Storage Coldline, la forma en que se replican tus datos depende del tipo de ubicación en la que almacenas los datos.

Duración del almacenamiento

El nivel de acceso esporádico de Azure Blob Storage no impone un período de almacenamiento mínimo si usas una cuenta de almacenamiento de blobs. En el caso de las cuentas de almacenamiento GPv2, este nivel de Azure Blob Storage tiene un período de almacenamiento mínimo de 30 días para cada blob. Se generarán cobros adicionales si se borra o reemplaza un blob antes de que finalice el período mínimo de almacenamiento.

Cloud Storage Nearline tiene un período de almacenamiento mínimo de 30 días para cada objeto de datos, mientras que Cloud Storage Coldline tiene un período de almacenamiento mínimo de 90 días para cada objeto de datos. Al igual que con el nivel de acceso esporádico de Azure Blob Storage cuando se usa con una cuenta GPv2, si borras o reemplazas un objeto de datos antes de que finalice el período mínimo de almacenamiento, se generarán cobros adicionales.

Costos

Nivel de acceso esporádico de Azure Blob Storage

Los precios del nivel de almacenamiento esporádico de Azure Blob Storage se calculan en función de la cantidad de datos que se almacenan al mes, el tipo de cuenta de almacenamiento, el tipo de replicación y la salida de red. Azure Cool Blob Storage también cobra las solicitudes comunes a la API, las escrituras de datos y la recuperación de estos.

Cloud Storage Nearline y Cloud Storage Coldline

Tanto Cloud Storage Nearline como Cloud Storage Coldline se valoran por la cantidad de datos almacenados por mes y por salida de red. Se te cobrará el resto del período si borras o modificas los datos antes de que transcurra el período mínimo de almacenamiento. Por ejemplo, si borras un objeto almacenado como Cloud Storage Nearline 5 días después de haberlo almacenado, se te cobrará por los 25 días restantes de almacenamiento para ese objeto. Cloud Storage Nearline y Cloud Storage Coldline también cobran por solicitudes a la API y por recuperación de datos comunes.

Si deseas obtener más información sobre los precios de Cloud Storage Nearline y Cloud Storage Coldline, consulta Precios de Cloud Storage.

Almacenamiento de archivos

GCP y Azure ofrecen opciones de almacenamiento de archivo. Cloud Storage ofrece una clase adicional llamada Cloud Storage Archive, y Azure Blob Storage ofrece un nivel de archivo adicional.

Latencia

En Cloud Storage Archive, el tiempo que tarda en enviarse el primer byte es de milisegundos. En el nivel de archivo de Azure Blob Storage, el tiempo que tarda en enviarse el primer byte es de 15 horas o menos.

Replicación

Con el nivel de archivo de Azure Blob Storage, los datos se replican según el tipo de replicación que use la cuenta de almacenamiento. Cuando usas Cloud Storage Archive, la forma en que se replican tus datos depende del tipo de ubicación en la que se almacenen.

Duración del almacenamiento

En el nivel de archivo de Azure Blob Storage el período mínimo de almacenamiento es de 180 días para cada blob. Se generarán cobros adicionales si se borra o reemplaza un blob antes de que finalice el período mínimo de almacenamiento.

Cloud Storage Archive tiene un período de almacenamiento mínimo de 365 días para cada objeto de datos. Al igual que con el nivel de archivo de Azure Blob Storage, si borras o reemplazas un objeto de datos antes de que finalice el período mínimo de almacenamiento, se generarán cobros adicionales.

Costos

Nivel de archivo de Azure Blob Storage

Los precios del nivel de archivo de Azure Blob Storage se calculan en función de la cantidad de datos que se almacenan al mes, el tipo de cuenta de almacenamiento, el tipo de replicación y la salida de red. Se te cobrará el resto del período si borras o modificas los datos antes de que transcurra el período mínimo de almacenamiento. Por ejemplo, si borras un blob 5 días después de almacenarlo, se te cobrarán los 175 días restantes de su almacenamiento. Además, si capturas instantáneas de los blobs, estas se cobran a las mismas tarifas que las versiones publicadas de los blobs.

En el nivel de archivo de Azure Blob Storage también se cobran las solicitudes comunes a la API.

Cloud Storage Archive

Los precios de Cloud Storage Archive se calculan según la cantidad de datos almacenados por mes y la salida de red, Se te cobrará el resto del período si borras o modificas los datos antes de que transcurra el período mínimo de almacenamiento. Por ejemplo, si borras un objeto 5 días después de almacenarlo, se te cobrarán los 360 días restantes de almacenamiento para ese objeto. Cloud Storage Archive también cobra por las solicitudes comunes a la API y la recuperación de datos.

Para obtener más información sobre los precios de Cloud Storage Archive, consulta Precios de Cloud Storage.

¿Qué sigue?

Consulta los demás artículos de Google Cloud para profesionales de Azure: