GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

Azure Storage


Azure Storage es la solución de almacenamiento de Microsoft en Azure, masivamente escalable (podemos almacenar terabytes de información y satisfacer las más ambiciosas necesidades de Big Data), de pago por uso (no por capacidad), accesible desde REST API y desde los lenguajes de programación más comunes, replicado siempre al menos en tres sitios y con opciones adicionales de replicación geográfica, con soporte nativo de Tablas NoSQL y Colas (Queues), y con diferentes opciones de seguridad para compartir el acceso con terceras personas y aplicaciones (ej: Shared Access Signatures - SAS, Stored Access Policy, etc). Una solución muy completa, y uno de los principales pilares de Azure.

El Almacenmiento en Azure se provisiona a través de las Cuentas de Almacenamiento (Storage Accounts). Cada Cuenta de Almacenamiento permite almacenar hasta 500TB.

Los datos de una Cuenta de Almacenamiento (Storage Account) están siempre replicados en tres sitios, y además tenemos varias opciones adicionales de replicación geográfica (ojo, la replicación geográfica es asíncrona).

  • Locally redundant storage (LRS). Es la opción mínima. El dato se almacena replicado en tres sitios dentro de un mismo datacenter, como protección a fallos HW.
  • Zone-redundant storage (ZRS). El dato se almacena replicado en tres sitios, repartidos entre dos o tres datacenters, de la misma o distinta región, como protección a fallos de un datacenter.
  • Geo-redundant storage (GRS). El dato se almacena replicado en seis sitios, tres veces dentro la región primaria, y otras tres veces en una región secundaria ubicada a cientos de kilómetros de la primaria, como protección a fallos de una región.
  • Read access geo-redundant storage (RA-GRS). Ofrece acceso de lectura a los datos en la localización secundaria.

Azure nos ofrece los siguientes tipos de almacenamiento a través de las Cuentas de Almacenamiento:

  • Blobs. Ideal para almacenar grandes cantidades de datos binarios, como Video, Audio, Imágenes, Backups, etc. Una de sus características es hacer streaming. Permite crear Contenedores, que son como carpetas que podemos usar para organizar nuestros Blobs (sólo se permite un único nivel), y sobre los cuales podemos definir Políticas de Seguridad (Security Policies). Cada Blob tiene asociado una URI relativa. También se puede acceder a ellos utilizando los métodos HTTP de GET, PUT, POST o DELETE utilizando una URL con el formato https://[account name].blob.core.windows.net/[container name]/[blob name]. Todo esto, lo hace apropiado para muchos escenarios, incluyendo el Big Data.
    • Block Blobs. Optimizado para el acceso secuencial, y para subir ficheros grandes de una manera eficiente. Lee y escribe los datos en bloques (utiliza conjuntos de bloques identificado de forma unequívoca por un Block ID). Es el más usado.
    • Page Blobs. Optimizado para el acceso aleatorio, lee y escribe en páginas de 512 bytes. Su uso típico es para los VHD, y pueden ser de hasta 1TB. Al crear un Page Blob es necesario especificar su tamaño máximo (si necesitamos más espacio, deberemos crear uno nuevo).
  • Tablas. Almacén NoSQL, ideal para almacenar meta-datos, y otros tipos de información no-estructurada no-relacional, que acepta llamadas autenticadas desde dentro y fuera de Azure. Resulta una alternativa sencilla y económica a Azure CosmosDB. Cada Entidad (el equivalente a una fila) puede ser de hasta 1MB y puede incluir hasta 252 Propiedades (el equivalente a los campos), más las tres Propiedades del sistema: partition key, row key, y timestamp. Ofrece un sistema de Particionamiento automático, en base al valor de la Propiedad del sistema partition key (cada partición es siempre servida desde el mismo servidor). El valor de partition key y row key lo debe de introducir el usuario (en caso contrario se quedará vacío y no se podrá aprovechar el Particionamiento). Incluye una Clave Primaria o Índice Único (Clustered Index) definido por las Propiedades partition key y row key. Cada tabla tiene asociada una URL con el formato http://[account].queue.core.windows.net/<table>
  • Colas (Queue). Sistema de mensajería escalable y confiable, que permite almacenar una gran cantidad de mensajes, accesible desde todo el mundo a través de llamadas autenticadas utilizando HTTP ó HTTPS. Cada mensaje puede ser de hasta 64KB. Un caso típico de uso, es el intercambio de mensajes entre un Azure Web Role y un Azure Worker Role. Cada cola tiene asociada una URL con el formato http://[account].queue.core.windows.net/<queue>
  • Ficheros. Ofrece un almacenamiento compartido utilizando el protocolo SMB, donde podemos almacenar ficheros en una jerarquía de directorios. Cada fichero tiene asociado una URL con el formato https://[account].file.core.windows.net/<share>/<directory/directories>/<file>

El siguiente diagrama representa la arquitectura general del almacenamiento en Azure.

Aunque podemos hacer gran cantidad de cosas desde el Portal de Azure, nos será de gran utilidad la herramienta Microsoft Azure Storage Explorer, ya que desde ella podremos hacer cosas que no son posibles desde el Portal, como ver/modificar elementos en Tablas y Colas (Queue), y muchas cosas más. Imprescindible!

Seguridad en Azure Storage

Por defecto, solo el propietario de la Cuenta de Almacenamiento tiene permisos para acceder a los recursos de dicha cuenta. Además de esto, cada Cuenta de Almacenamiento incluye dos Claves que dan acceso completo a la cuenta. Estas Claves se pueden reciclar, lo que genera una nueva e invalida la anterior, como medida de protección en caso de que alguna de estas claves quedara comprometida. Utilizando estas claves, podemos conseguir que nuestras Aplicaciones se conecten a nuestras Cuentas de Almacenamiento (se puede, aunque no es muy recomendable, la verdad), o también nosotros mismos (o un tercero) utilizando herramientas como el Microsoft Azure Storage Explorer (nuestro gran amigo). Hay que tener mucho cuidado con ellas, y es mejor limitar su uso en todo lo posible, pero están aquí y tenemos que conocerlas.

En el caso de los Blob, es posible dar acceso de lectura a otros usuarios a través de la Propiedad Public Read Access que tiene cada Contenedor. Esta Propiedad la podemos ver/modificar desde el Microsoft Azure Storage Explorer. Desde el Portal la podemos ver/modificar desde la opción Access Policy de cada Contenedor. Hay tres posibles valores:

  • Off (Private). No public access
  • Container. Public read access for container and blobs.
  • Blob. Public read access for blobs only.

El siguiente diagrama representa las distintas opciones de permisos de acceso que tenemos con los Blob en Microsoft Azure. Evidentemente, a través del acceso con Clave, tendremos un acceso total.

El siguiente pantallazo del Microsoft Azure Storage Explorer, muestra estas opciones de configuración:

En el Portal estas opciones se ven un poco diferente, lo cual al principio causa un poco de confusión, aunque en cualquier caso es bastante intuitivo.

Esta es una solución interesante, pero se queda corta, ya que sólo hay definidos tres niveles de permisos, que dan accesos de sólo lectura o ningún acceso, y además, sólo aplica a los Blob (también tenemos Tablas y Colas). ¿Qué pasa si queremos escribir o si necesitamos un nivel de acceso un poco más granular? No pasa nada. Está to pensao.

La otra opción que tenemos es SAS (Shared Access Signatures), que nos permite conceder un acceso temporal y granular, tanto a Blobs individuales, como a Contenedores, Colas (Queues) y Tablas. Con SAS podemos generar una URI o URL (un Token) que incluye un conjunto de parámetros como Query Strings para especificar las opciones de acceso, como la fecha de comienzo y expiración, permisos concedidos, y una firma realizada con la Clave Principal de la Cuenta de Almacenamiento. Ojo con esto, porque si regeneramos la Clave Principal de nuestra Cuenta de Almacenamiento, invalidaremos todos los accesos SAS que hayamos generado hasta el momento. Interesante solución, porque de este modo podemos conceder accesos sin compartir la Claves de la Cuenta de Almacenamiento.

Básicamente, los accesos SAS son una implementación del Patrón de Diseño Valet Key pattern.

Podemos obtener un acceso SAS ad-hoc a un fichero (o a cualquier otro elemento) a través del Microsoft Azure Storage Explorer, simplemente utilizando el menú contextual.

 

Especificamos la ventana temporal y los permisos deseados, y listo, click en Create y ya tenemos la URL lista para copiar, pegar y acceder.

Una alternativa a los accesos SAS ad-hoc, es utilizar lo que se denomina Stored Access Policy, que nos permite generar accesos SAS basados en una política predefinida y almacenada en el servidor, a nivel de Contenedor, Tabla o Cola (máximo cinco por Contenedor/Tabla/Cola), indicando el rango temporal de validez y los permisos concedidos. Definida la política, podemos generar una URI de acceso SAS basada en la misma, ya sea para acceder al Contenedor o a un elemento individual (esto también lo podemos hacer ayudándonos del Microsoft Azure Storage Explorer). En este caso, la QueryString (Token) llevará el nombre de la Policy y la firma. La ventaja de este método, es que si posteriormente necesitamos invalidar/cambiar dicho acceso SAS por cualquier motivo, no es necesario reciclar nuestra Clave Principal: tan sólo es necesario modificar o eliminar dicha Policy.

Podemos crear dos tipos de shared access signatures (SAS):

  • Service SAS. Permite dar acceso sobre un recurso o servicio particular de una cuenta de almacenamiento (ej: sobre un Blob, sobre una Cola, sobre un Contenedor, etc).
  • Account SAS. Permite dar un acceso temporal a toda la cuenta de almacenamiento, pudiendo definir algunos filtros.

En la siguiente imagen se muestra un ejemplo de cómo se crearía una Account SAS desde el Azure Storage Manager.

El dialogo que tenemos para definer los permisos de acceso de una Account SAS en un poco diferente:

Ejemplo de caso de uso de accesos SAS: una Aplicación Web necesita que sus usuarios puedan subir y almacenar ficheros, para lo cual se decide utilizar un almacenamiento Blob de Azure. En lugar de que la Aplicación Web utilice la Clave de la Cuenta de Almacenamiento, se llama a un servicio que devuelve un acceso SAS para un intervalo de 10 minutos sobre un Contenedor específico con un nivel de permisos limitado. De este modo también se descarga a la Aplicación, ya que tan sólo tendrá que pedir un acceso SAS cada 10 minutos.

A continuación se incluye un ejemplo de código PowerShell, capaz de conectarse a una Cuenta de Almacenamiento, crear una Stored Access Policy, y obtener un Token de acceso (la QueryString que deberemos utilizar en la URL para acceder al recurso solicitado.

$context = New-AzureStorageContext -ConnectionString "[Pegar aquí la Cadena de Conexión]";
$policy = New-AzureStorageContainerStoredAccessPolicy -Container backups -Policy downloadPolicy -Permission rdl -Context $context
$token = New-AzureStorageContainerSASToken -Name backups -Policy downloadPolicy -Context $context
$token

StorSimple

StorSimple es la combinación de un servicio, dispositivo, y herramientas de gestión que puede crear flujos (workflows) para migrar datos al datacenter o al cloud. Se trata de un array de almacenamiento híbrido on-premise que ofrece almacenamiento primario e iSCSI. Incluye discos SSD y HDD, así como soporte para Clustering y Failover automático. Ofrece una interfaz de administración Web, PowerShell, y MMC. Los datos más activos son almacenados localmente (en SSD), mientras que los menos activos y los inactivos son migrados automáticamente al Cloud.

Para más información puede consultarse los siguientes enlaces:

Poco más por hoy. Como siempre, confío que la lectura resulte de interés.


[Fecha del Artículo (UTC): 09/12/2017]
[Autor: GuilleSQL]



Escribir un Comentario

Para poder escribir un comentario, debe Iniciar Sesión con un usuario.

Si no dispone de un usuario, puede Registrarse y hacerse miembro.

Si dispone de un usuario, pero no recuerda sus credenciales de acceso, puede Restablecer su Contraseña.

Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Mayo de 2018 (3)
Abril de 2018 (3)
Marzo de 2018 (2)
Febrero de 2018 (7)
Enero de 2018 (1)
Diciembre de 2017 (15)
Noviembre de 2017 (7)
Junio de 2017 (3)
Mayo de 2017 (1)
Marzo de 2017 (3)
Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Esta información se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.
This information is provided "AS IS" with no warranties, and confers no rights.

Copyright © 2007 GuilleSQL, todos los derechos reservados.
GuilleSQL.com y GuilleSQL.net son también parte de Portal GuilleSQL.

Visitas recibidas (Page Loads) en GuilleSQL (fuente: StatCounter):

screen resolution stats
Visitas