Consideraciones para Cloud Storage Pools
Sugerir cambios
PDF
Si planea utilizar un pool de almacenamiento en cloud para mover objetos desde el sistema StorageGRID, debe revisar las consideraciones que hay que tener en cuenta a la hora de configurar y utilizar pools de almacenamiento en cloud.
Consideraciones generales
-
En general, el almacenamiento de archivado en cloud, como el almacenamiento de Amazon S3 Glacier o Azure Blob, es un lugar económico para almacenar datos de objetos. No obstante, los costes para recuperar datos del almacenamiento de archivado en el cloud son relativamente altos. Para alcanzar el coste general más bajo, debe tener en cuenta cuándo y con qué frecuencia accederá a los objetos en el pool de almacenamiento en cloud. El uso de un Cloud Storage Pool solo se recomienda para el contenido al que espera acceder con poca frecuencia.
-
No use Cloud Storage Pools para los objetos que han sido procesados por los clientes de Swift. Swift no admite solicitudes POSTERIORES a la restauración de objetos, por lo que StorageGRID no podrá recuperar objetos de Swift que se hayan migrado al almacenamiento S3 Glacier ni al nivel de almacenamiento de Azure Blob. La emisión de una solicitud de objeto GET de Swift para recuperar estos objetos fallará (403 Prohibido).
-
No se puede usar Cloud Storage Pools con FabricPool debido a la latencia añadida de recuperar un objeto del destino de Cloud Storage Pool.
Información necesaria para crear un pool de almacenamiento en cloud
Antes de poder crear un Cloud Storage Pool, debe crear el bloque de S3 externo o el contenedor de almacenamiento externo de Azure Blob que utilizará para el Cloud Storage Pool. A continuación, cuando cree el pool de almacenamiento en cloud en StorageGRID, debe especificar la siguiente información:
-
El tipo de proveedor: Almacenamiento Amazon S3 o Azure Blob.
-
Si selecciona Amazon S3, si Cloud Storage Pool va a utilizarse con la región secreta de AWS (CAP (Portal de acceso C2S)).
-
El nombre exacto del contenedor o contenedor.
-
El extremo de servicio necesario para acceder al bloque o contenedor.
-
La autenticación necesaria para acceder al bloque o contenedor:
-
S3: Opcionalmente, un ID de clave de acceso y una clave de acceso secreta.
-
C2S: La dirección URL completa para obtener credenciales temporales del servidor CAP; un certificado de CA del servidor, un certificado de cliente, una clave privada para el certificado de cliente y, si la clave privada está cifrada, la frase de acceso para descifrarla.
-
Almacenamiento de Azure Blob: Un nombre de cuenta y una clave de cuenta. Estas credenciales deben tener permiso completo para el contenedor.
-
-
De manera opcional, un certificado de CA personalizado para verificar las conexiones TLS al bloque o contenedor.
Consideraciones sobre los puertos utilizados para Cloud Storage Pools
Para garantizar que las reglas de ILM puedan mover objetos desde y hacia el Cloud Storage Pool especificado, debe configurar la red o las redes que contienen los nodos de almacenamiento del sistema. Debe asegurarse de que los siguientes puertos puedan comunicarse con el pool de almacenamiento en cloud.
De forma predeterminada, los pools de almacenamiento en cloud utilizan los puertos siguientes:
-
80: Para los URI de punto final que comienzan con http
-
443: Para los URI de punto final que comienzan con https
Es posible especificar un puerto diferente cuando se crea o se edita un pool de almacenamiento en el cloud.
Si utiliza un servidor proxy no transparente, también debe hacerlo Configure un proxy de almacenamiento para permitir el envío de mensajes a puntos finales externos, como un punto final en internet.
Consideraciones sobre los costos
El acceso al almacenamiento en el cloud por medio de un pool de almacenamiento en el cloud requiere conectividad de red al cloud. Debe tener en cuenta el coste de la infraestructura de red que utilizará para acceder al cloud y aprovisionarlo adecuadamente, en función de la cantidad de datos que espera mover entre StorageGRID y el cloud con el pool de almacenamiento en cloud.
Cuando StorageGRID se conecta al extremo externo de Flash Storage Pool, emite distintas solicitudes para supervisar la conectividad y garantizar que puede ejecutar las operaciones requeridas. Aunque se asociarán algunos costes adicionales con estas solicitudes, el coste de supervisar un Cloud Storage Pool solo debería ser una pequeña fracción del coste total de almacenar objetos en S3 o Azure.
Es posible que deba incurrir en costes más significativos si necesita mover objetos desde un extremo de almacenamiento en cloud externo a StorageGRID. Los objetos pueden moverse de nuevo a StorageGRID en cualquiera de estos casos:
-
La única copia del objeto se encuentra en un Pool de almacenamiento en cloud y en su lugar decide almacenar el objeto en StorageGRID. En este caso, sólo tiene que volver a configurar las reglas y la política de ILM. Cuando se produce la evaluación de la gestión de la vida útil de la información, StorageGRID emite varias solicitudes para recuperar el objeto desde el pool de almacenamiento en cloud. A continuación, StorageGRID crea el número especificado de copias replicadas o codificadas de borrado en forma local. Cuando el objeto se mueve de nuevo a StorageGRID, se elimina la copia en el pool de almacenamiento en el cloud.
-
Se pierden los objetos debido a un fallo en el nodo de almacenamiento. Si la única copia restante de un objeto se encuentra en un pool de almacenamiento en el cloud, StorageGRID restaura temporalmente el objeto y crea una nueva copia en el nodo de almacenamiento recuperado.
|
Cuando se devuelven objetos a StorageGRID desde un pool de almacenamiento en el cloud, StorageGRID emite varias solicitudes al extremo de pool de almacenamiento en cloud para cada objeto. Antes de mover un gran número de objetos, póngase en contacto con el soporte técnico para obtener ayuda a la hora de calcular el plazo de tiempo y los costes asociados. |
S3: Permisos necesarios para el bloque de Cloud Storage Pool
La política de bloque para el bloque externo de S3 usado para un Cloud Storage Pool debe otorgar permiso StorageGRID para mover un objeto al bloque, obtener el estado de un objeto, restaurar un objeto del almacenamiento Glacier cuando sea necesario y más. Lo ideal es que StorageGRID tenga acceso de control total al cucharón (s3:*); sin embargo, si esto no es posible, la directiva bucket debe conceder los siguientes permisos S3 a StorageGRID:
-
s3:AbortMultipartUpload -
s3:DeleteObject -
s3:GetObject -
s3:ListBucket -
s3:ListBucketMultipartUploads -
s3:ListMultipartUploadParts -
s3:PutObject -
s3:RestoreObject
S3: Consideraciones para el ciclo de vida del bloque externo
El movimiento de objetos entre StorageGRID y el bloque externo S3 especificado en el Cloud Storage Pool está controlado por las reglas de ILM y la política activa de ILM en StorageGRID. Por el contrario, la configuración del ciclo de vida de ese bloque controla la transición de objetos desde el bloque S3 externo especificado en Cloud Storage Pool a Amazon S3 Glacier o S3 Glacier Deep Archive (o a una solución de almacenamiento que implementa la clase de almacenamiento Glacier).
Si desea realizar la transición de objetos desde Cloud Storage Pool, debe crear la configuración de ciclo de vida adecuada en el bloque externo de S3. Debe usar una solución de almacenamiento que implemente la clase de almacenamiento Glacier y sea compatible CON la API DE restauración POSTERIOR a objetos de S3.
Por ejemplo, supongamos que desea que se realice inmediatamente la transición de todos los objetos movidos de StorageGRID al pool de almacenamiento en cloud al almacenamiento Amazon S3 Glacier. Debe crear una configuración de ciclo de vida en el bloque S3 externo que especifique una única acción (transición) de la siguiente forma:
<LifecycleConfiguration>
<Rule>
<ID>Transition Rule</ID>
<Filter>
<Prefix></Prefix>
</Filter>
<Status>Enabled</Status>
<Transition>
<Days>0</Days>
<StorageClass>GLACIER</StorageClass>
</Transition>
</Rule>
</LifecycleConfiguration>
Esta regla transitaría todos los objetos de bloques al Amazon S3 Glacier el día en que se crearon (es decir, el día en que se movieron de StorageGRID a la agrupación de almacenamiento en cloud).
|
|
Al configurar el ciclo de vida del cucharón externo, no utilice nunca acciones Expiración para definir cuándo caducan los objetos. Las acciones de caducidad hacen que el sistema de almacenamiento externo elimine los objetos caducados. Si más adelante intenta acceder a un objeto caducado de StorageGRID, no se encuentra el objeto eliminado. |
Si desea realizar la transición de objetos del Cloud Storage Pool a S3 Glacier Deep Archive (en lugar de Amazon S3 Glacier), especifique <StorageClass>DEEP_ARCHIVE</StorageClass> en el ciclo de vida de la cuchara. Sin embargo, tenga en cuenta que no puede utilizar el Expedited organice en niveles los objetos de S3 Glacier Deep Archive.
Azure: Consideraciones para el nivel de acceso
Al configurar una cuenta de almacenamiento de Azure, puede configurar el nivel de acceso predeterminado en Hot o Cool. Al crear una cuenta de almacenamiento para usar con un pool de almacenamiento en el cloud, se debe usar el nivel de función como nivel predeterminado. Aunque StorageGRID establece inmediatamente el nivel Archivado cuando se mueven objetos al pool de almacenamiento en el cloud, el uso de una configuración predeterminada de caliente garantiza que no se cobrará una tarifa de eliminación anticipada de los objetos que se quitan del nivel de refrigeración antes del mínimo de 30 días.
Azure: Gestión del ciclo de vida no compatible
No utilice la gestión del ciclo de vida del almacenamiento BLOB de Azure para el contenedor utilizado con un Cloud Storage Pool. Las operaciones de ciclo de vida pueden interferir en las operaciones de Cloud Storage Pool.