Díganos qué opina sobre la experiencia de descarga del PDF.

Documentación de Azure Files

Recursos compartidos de archivos en la nube de nivel empresarial sencillos, seguros y
sin servidor.

Acerca de Azure Files

ｅ INFORMACIÓN GENERAL

Guía de plan de Azure Files

¿Qué es Azure Files?

Habilitación basada en identidad

Vídeos

Introducción

ｆ INICIO RÁPIDO

Creación y uso de un recurso compartido de archivos de Azure

ｇ TUTORIAL

Creación de un recurso compartido de archivos SMB de Azure: Windows

Creación de un recurso compartido de archivos NFS de Azure: Linux

Solución de problemas

ｉ REFERENCIA

Solucionar problemas de Azure Files

Solución de problemas de rendimiento de Azure Files

Migrate

GUÍA PASO A PASO

 GUÍA PASO A PASO
ｃ
Información general sobre la migración

Guías de migración

Entrenamiento autodirigido

ｄ CURSOS

Introducción a Azure Files

Configuración de Azure Files y Azure File Sync

Architecture

Ｙ ARQUITECTURA

Recurso compartido de archivos de la nube empresarial de Azure

Servicios de archivo híbridos

Uso de recursos compartidos de archivos de Azure en un entorno híbrido

Recurso compartido de archivos híbrido con la recuperación ante desastres para trabajos
tanto remotos como de sucursales locales

Archivos de Azure a los que se accede de forma local y que protege AD DS

¿Qué es Azure Files?
Artículo • 25/03/2023

Azure Files le ofrece recursos compartidos de archivos en la nube totalmente

administrados, a los que se puede obtener acceso mediante el protocolo Bloque de
mensajes del servidor (SMB) estándar, el protocolo Network File System (NFS) y la API
de REST de Azure Files. Los recursos compartido de archivos de Azure se pueden
montar simultáneamente mediante implementaciones locales o en la nube. A los
recursos compartidos de archivos SMB de Azure se puede acceder desde clientes
Windows, Linux y macOS. Se puede acceder a los recursos compartidos de archivos NFS
de Azure desde clientes Linux. Además, los recursos compartidos de archivos SMB de
Azure Files se pueden almacenar en la caché de los servidores de Windows Server con
Azure File Sync, lo que permite un acceso rápido allí donde se utilizan los datos.

Estos son algunos vídeos sobre casos de uso comunes de Azure Files:

Reemplazo del servidor de archivos por un recurso compartido de archivos de

Azure sin servidor
Introducción a los contenedores de perfiles de FSLogix en Azure Files en Azure
Virtual Desktop mediante el aprovechamiento de la autenticación de AD

Para empezar a usar Azure Files, consulte Inicio rápido: Creación y uso de un recurso
compartido de archivos de Azure.

¿Por qué es útil Azure Files?

Los recursos compartidos de archivos de Azure se pueden usar para:

Reemplazar o complementar servidores de archivos locales:

Azure Files puede ser utilizado para reemplazar o complementar los servidores de
archivos tradicionales locales o en dispositivos de almacenamiento conectado a la
red (NAS). Desde sistemas operativos tan extendidos como Windows, macOS y
Linux se puede montar directamente un recurso compartido de Azure Files desde
cualquier lugar del mundo. Los recursos compartidos de archivos SMB de Azure
Files se pueden replicar también con Azure File Sync en servidores de Windows
Server, locales o en la nube, para obtener un almacenamiento en caché eficiente y
distribuido de los datos. Con la Autenticación de AD de Azure Files, los recursos
compartidos de archivos de Azure de SMB pueden funcionar con Active Directory
Domain Services (AD DS) hospedados en el entorno local para el control de
acceso.
Aplicaciones "Lift-and-shift" :
Azure Files facilita la migración mediante "lift and shift" de aplicaciones a la nube
que espera un recurso compartido de archivos para almacenar datos de la
aplicación de archivos o de un usuario. Azure Files permite la migración clásica
mediante "lift and shift" en la que tanto la aplicación como sus datos se mueven a
Azure, y la migración híbrida mediante "lift and shift" en la que los datos de la
aplicación se mueven a Azure Files pero la aplicación continúa ejecutándose de
forma local.

Simplificar el desarrollo en la nube:

Azure Files también se puede utilizar para simplificar los nuevos proyectos de
desarrollo en la nube. Por ejemplo:

Configuración de aplicaciones compartidas

Un patrón habitual entre las aplicaciones distribuidas es contar con archivos de
configuración en una ubicación centralizada que permite tener acceso a ellos
desde muchas instancias de aplicaciones. Las instancias de la aplicación pueden
cargar su configuración mediante la API de REST de Azure Files y los usuarios
pueden acceder a ella montando el recurso compartido localmente.

Recurso compartido de diagnóstico:

Un recurso compartido de Azure Files es un lugar adecuado para que las
aplicaciones en la nube escriban sus registros, métricas y volcados de memoria.
Las instancias de la aplicación pueden escribir los registros mediante la API de
REST de Azure Files, y los desarrolladores pueden acceder a ellos montando el
recurso compartido de archivos en su máquina local. Esto permite una gran
flexibilidad, ya que los desarrolladores pueden adoptar el desarrollo en la nube
sin tener que abandonar las herramientas existentes que ya conocen y disfrutan.

Desarrollo, pruebas y depuración:

Cuando los desarrolladores o administradores están trabajando en máquinas
virtuales en la nube, a menudo necesitan diversas herramientas o utilidades.
Copiar estas utilidades y herramientas en cada máquina virtual puede ser una
tarea que consuma mucho tiempo. Mediante el montaje de un recurso
compartido de Azure Files localmente en las máquinas virtuales, un
desarrollador o administrador pueden acceder rápidamente a sus herramientas
y utilidades, sin tener que copiarlos.

Contenedorización:
los recursos compartidos de archivos de Azure se pueden usar como volúmenes
persistentes para contenedores con estado. Los contenedores ofrecen
funcionalidades de "compilar una vez, ejecutarse en cualquier lugar" que permiten
 a los desarrolladores acelerar la innovación. En el caso de los contenedores que
acceden a datos sin procesar en cada inicio, se requiere un sistema de archivos
compartidos para que estos contenedores puedan acceder al sistema de archivos,
independientemente de la instancia en que se ejecuten.

Ventajas principales
Fácil de usar. Cuando se monta un recurso compartido de archivos de Azure en el
equipo, no es necesario hacer nada especial para acceder a los datos: simplemente
vaya a la ruta de acceso donde se monta el recurso compartido de archivos y abra
o modifique un archivo.
Acceso compartido. Los recursos compartidos de Azure Files admiten los
protocolos SMB y NFS estándar del sector, lo que significa que puede reemplazar
perfectamente los recursos compartidos de archivos en local por recursos
compartidos de archivos de Azure sin preocuparse de compatibilidad de
aplicaciones. La posibilidad de compartir un sistema de archivos entre varias
máquinas, aplicaciones e instancias de aplicaciones es una ventaja importante para
aquellas aplicaciones que necesitan la posibilidad de compartir.
Completamente administrado. Los recursos compartidos de Azure Files pueden
crearse sin necesidad de administrar ni el hardware ni un sistema operativo. Esto
significa que no tiene que tratar con la aplicación de actualizaciones de seguridad
críticas en el sistema operativo del servidor ni ocuparse de reemplazar discos
duros defectuosos.
Herramientas y scripting. Como parte de la administración de las aplicaciones de
Azure, se pueden usar cmdlets de PowerShell y la CLI de Azure para crear, montar
y administrar recursos compartidos de archivos de Azure. Los recursos
compartidos de archivos de Azure se pueden crear y administrar mediante Azure
Portal y el Explorador de Azure Storage.
Resistencia. Azure Files se creó desde sus orígenes para estar siempre disponible.
Reemplazar los recursos compartidos de archivos en local por Azure Files significa
que ya no tendrá que tratar con problemas de red o interrupciones del suministro
eléctrico local.
Programación amigable. Las aplicaciones que se ejecutan en Azure pueden tener
acceso a los datos en el recurso compartido mediante las API de E/S del sistema.
Por tanto, los desarrolladores pueden aprovechar el código y los conocimientos
que ya tienen para migrar las aplicaciones actuales. Además de las API de E/S del
sistema, puede usar las Bibliotecas de cliente de Azure Storage o la API de REST de
Azure Files.
Cursos
Para el entrenamiento autodirigido, consulte los módulos siguientes:

Introducción a Azure Files

Configuración de Azure Files y Azure File Sync

Architecture
Para obtener instrucciones sobre cómo diseñar soluciones en Azure Files mediante
patrones y prácticas establecidos, consulte lo siguiente:

Recurso compartido de archivos de la nube empresarial de Azure

Servicios de archivo híbridos
Uso de recursos compartidos de archivos de Azure en un entorno híbrido
Recurso compartido de archivos híbrido con recuperación ante desastres para
trabajos tanto remotos como de sucursales locales
Archivos de Azure a los que se accede de forma local y que protege AD DS

Casos prácticos
Las organizaciones de todo el mundo aprovechan Azure Files y Azure File Sync
para optimizar el acceso a los archivos y el almacenamiento. Consulte sus casos
prácticos aquí.

Pasos siguientes
Planeamiento de una implementación de Azure Files
Creación de un recurso compartido de Azure Files
Conexión y montaje de un recurso compartido de archivos SMB en Windows
Conexión y montaje de un recurso compartido de archivos SMB en Linux
Conexión y montaje de un recurso compartido de archivos SMB en macOS
Conexión y montaje de un recurso compartido de archivos NFS en Linux
Preguntas más frecuentes de Azure Files
Inicio rápido: Creación y uso de un
recurso compartido de archivos de
Azure
Artículo • 10/10/2023

Azure Files es el sencillo sistema de archivos en la nube de Microsoft. Puede montar

recursos compartidos de archivos de Azure en los sistemas operativos Windows, Linux y
macOS. En este artículo se muestra cómo crear un recurso compartido de archivos de
Azure con el protocolo SMB mediante Azure Portal, la CLI de Azure o Azure PowerShell.

Se aplica a
Este inicio rápido solo se aplica a recursos compartidos de archivos de Azure SMB. Los
recursos compartidos de archivos SMB estándar y premium admiten el almacenamiento
con redundancia local (LRS) y el almacenamiento con redundancia de zona (ZRS). Los
recursos compartidos de archivos estándar también admiten almacenamiento con
redundancia geográfica (GRS) y el opciones de almacenamiento con redundancia de
zona geográfica (GZRS). Para más información, consulte Redundancia de Azure Files.

Tipo de recurso compartido de archivos SMB NFS

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS

Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Introducción
Portal

Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Crear una cuenta de almacenamiento

Portal
Una cuenta de almacenamiento es un grupo compartido de almacenamiento en el
que puede implementar un recurso compartido de archivos de Azure u otros
recursos de almacenamiento como blobs o colas. Una cuenta de almacenamiento
puede contener un número ilimitado de recursos compartidos. Un recurso
compartido puede almacenar un número ilimitado de archivos, hasta los límites de
capacidad de la cuenta de almacenamiento.

Para crear una cuenta de almacenamiento mediante Azure Portal, siga estos pasos:

1. En Servicios de Azure, seleccione Cuentas de almacenamiento.

2. Seleccione Crear para crear una cuenta de almacenamiento.

3. En la sección Detalles del proyecto, seleccione la suscripción de Azure en la

que se va a crear la cuenta de almacenamiento. Si solo tiene una suscripción,
debe ser la predeterminada.

4. Si desea crear un nuevo grupo de recursos, seleccione Crear nuevo y escriba

un nombre como myexamplegroup.

5. En Detalles de la instancia, proporcione un nombre para la cuenta de

almacenamiento. Es posible que tenga que agregar algunos números
aleatorios para convertirlo en un nombre único global. Los nombres de las
cuentas de almacenamiento deben estar formados por minúsculas, números y
deben tener entre 3 y 24 caracteres. Anote el nombre de la cuenta de
almacenamiento. La usará más adelante.

6. En Región, seleccione la región en la que desea crear la cuenta de

almacenamiento.

7. En Rendimiento, conserve el valor predeterminado de Estándar.

8. En Redundancia, seleccione Almacenamiento con redundancia local (LRS).

 

9. Seleccione Revisar para revisar la configuración. Azure ejecutará una

validación final.

10. Una vez completada la validación, seleccione Crear. Debería ver una
notificación informándole de que la implementación está en curso.

Creación de un recurso compartido de archivos

de Azure
Portal

Para crear un recurso compartido de archivos de Azure:

1. Seleccione la cuenta de almacenamiento desde el panel.

2. En la página de la cuenta de almacenamiento, en la sección Almacenamiento

de datos, seleccione Recursos compartidos de archivos.
3. En el menú de la parte superior de la página Recursos compartidos de
archivos, seleccione + Recurso compartido de archivos. Se abre la página
New file share (Nuevo recurso compartido de archivos).

4. En Nombre, escriba myshare. Los nombres de recursos compartidos de

archivos deben estar formados por letras minúsculas, números y guiones
únicos, y deben comenzar y terminar con un número o una letra en minúscula.
El nombre no puede contener dos guiones consecutivos. Para obtener detalles
sobre cómo asignar un nombre a recursos compartidos y archivos, vea
Asignación de nombres y referencia a recursos compartidos, directorios,
archivos y metadatos.

5. Deje la opción Transacción optimizada seleccionada para el Nivel.

6. Seleccione la pestaña Copia de seguridad. De forma predeterminada, la copia

de seguridad se habilita al crear un recurso compartido de archivos de Azure
mediante Azure Portal. Si quiere deshabilitar la copia de seguridad para el
recurso compartido de archivos, desactive la casilla Habilitar copia de
seguridad. Si quiere habilitar la copia de seguridad, puede dejar los valores
predeterminados o bien crear un almacén de servicios de recuperación en la
misma región y suscripción de la cuenta de almacenamiento. Para crear una
directiva de copia de seguridad, seleccioneCrear una nueva directiva.
 7. Seleccione Revisar y crear y, después, Crear para crear el recurso compartido
de archivos de Azure.

Creación de un directorio

Portal

Para crear un nuevo directorio denominado myDirectory en la raíz del recurso

compartido de archivos de Azure:

1. En la página Configuración del recurso compartido de archivos, seleccione el

recurso compartido de archivos myshare. Al seleccionarlo, se abrirá la página
del recurso compartido de archivos e indicará que No se encontraron archivos.
2. En el menú que aparece en la parte superior de la página, seleccione + Add
directory (Agregar directorio) y su cuenta. Se abre la página New directory
(Nuevo directorio).
3. Escriba myDirectory y, luego, seleccione Aceptar.

Cargar un archivo

Portal
 En primer lugar, debe crear o seleccionar un archivo para cargarlo. Hágalo por
cualquier medio que considere oportuno. Cuando haya decidido el archivo que
desea cargar, siga estos pasos:

1. Seleccione el directorio myDirectory. Se abre el panel myDirectory.

2. En el menú en la parte superior, seleccione Cargar. Se abre el panel Upload

files (Cargar archivos).

3. Seleccione el icono de carpeta para abrir una ventana donde examinar los
archivos locales.

4. Seleccione un archivo y, después, elija Abrir.

5. En la página Cargar archivos, compruebe el nombre de archivo y, luego, haga

clic en Cargar.

6. Cuando termine, el archivo debe aparecer en la lista en la página myDirectory.

Descarga de un archivo

Portal

Para descargar una copia del archivo cargado, haga clic sobre este con el botón
derecho y seleccione Descargar. La experiencia exacta de la descarga dependerá
del sistema operativo y el explorador web que use.

Limpieza de recursos
Portal

Cuando haya terminado, elimine el grupo de recursos. Al eliminar el grupo de

recursos, se elimina la cuenta de almacenamiento, el recurso compartido de
archivos de Azure y otros recursos que se implementaron en el grupo de recursos.
 Si hubiera bloqueos en la cuenta de almacenamiento, primero deberá quitarlos.
Vaya a la cuenta de almacenamiento y seleccione Configuración>Bloqueos. Si se
muestran bloqueos, elimínelos.

Es posible que también tenga que eliminar el almacén de Azure Backup Recovery
Services antes de poder eliminar el grupo de recursos.

1. Seleccione Inicio y, a continuación, seleccione Grupos de recursos.

2. Seleccione el grupo de recursos que desea eliminar.
3. Seleccione Eliminar grupo de recursos. Se abre una ventana con una
advertencia acerca de los recursos que se eliminarán con el grupo de recursos.
4. Escriba el nombre del grupo de recursos y, luego, seleccione Eliminar.

Pasos siguientes
¿Qué es Azure Files?
Tutorial: Creación de un recurso
compartido de archivos SMB de Azure y
conexión a una VM de Windows
mediante Azure Portal
Artículo • 23/10/2023

Azure Files ofrece recursos compartidos de archivos totalmente administrados en la

nube a los que se puede acceder mediante el protocolo SMB (Bloque de mensajes del
servidor) o el protocolo NFS (Network File System) estándar del sector. En este
tutorial, aprenderá varias maneras de usar un recurso compartido de archivos SMB de
Azure en una máquina virtual (VM) Windows.

Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

＂ Crear una cuenta de almacenamiento

＂ Creación de un recurso compartido de archivos
＂ Implementación de una máquina virtual
＂ Conexión a la máquina virtual
＂ Montaje de un recurso compartido de archivos de Azure en la máquina virtual
＂ Creación y eliminación de una instantánea de recurso compartido

Se aplica a
Tipo de recurso compartido de archivos SMB NFS

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS

Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Introducción

Crear una cuenta de almacenamiento

Para poder trabajar con un recurso compartido de archivos de Azure, es necesario que
cree una cuenta de Azure Storage.
Una cuenta de almacenamiento es un grupo compartido de almacenamiento en el que
puede implementar un recurso compartido de archivos de Azure u otros recursos de
almacenamiento como blobs o colas. Una cuenta de almacenamiento puede contener
un número ilimitado de recursos compartidos. Un recurso compartido puede almacenar
un número ilimitado de archivos, hasta los límites de capacidad de la cuenta de
almacenamiento.

Para crear una cuenta de almacenamiento mediante Azure Portal, siga estos pasos:

1. En Servicios de Azure, seleccione Cuentas de almacenamiento.

2. Seleccione Crear para crear una cuenta de almacenamiento.

3. En la sección Detalles del proyecto, seleccione la suscripción de Azure en la que se

va a crear la cuenta de almacenamiento. Si solo tiene una suscripción, debe ser la
predeterminada.

4. Si desea crear un nuevo grupo de recursos, seleccione Crear nuevo y escriba un

nombre como myexamplegroup.

5. En Detalles de la instancia, proporcione un nombre para la cuenta de

almacenamiento. Es posible que tenga que agregar algunos números aleatorios
para convertirlo en un nombre único global. Los nombres de las cuentas de
almacenamiento deben estar formados por minúsculas, números y deben tener
entre 3 y 24 caracteres. Anote el nombre de la cuenta de almacenamiento. La usará
más adelante.

6. En Región, seleccione la región en la que desea crear la cuenta de

almacenamiento.

7. En Rendimiento, conserve el valor predeterminado de Estándar.

8. En Redundancia, seleccione Almacenamiento con redundancia local (LRS).

 

9. Seleccione Revisar para revisar la configuración. Azure ejecutará una validación

final.

10. Una vez completada la validación, seleccione Crear. Debería ver una notificación
informándole de que la implementación está en curso.

Creación de un recurso compartido de archivos de Azure

A continuación, cree de un recurso compartido de archivos SMB de Azure.

1. Cuando se complete la implementación de la cuenta de Azure Storage, seleccione

Ir al recurso.

2. Seleccione Recursos compartidos de archivos en el panel de la cuenta de

almacenamiento.
3. Seleccione + Recurso compartido de archivos.

4. Asigne al nuevo recurso compartido de archivos el nombre qsfileshare y deje la

opción Transacción optimizada seleccionada para Nivel.

5. Seleccione la pestaña Copia de seguridad. De manera predeterminada, la copia de

seguridad se habilita al crear un recurso compartido de archivos de Azure
mediante Azure Portal. Si quiere deshabilitar la copia de seguridad para el recurso
compartido de archivos, desactive la casilla Habilitar copia de seguridad. Si quiere
habilitar la copia de seguridad, puede dejar los valores predeterminados o bien
crear un almacén de servicios de recuperación en la misma región y suscripción de
la cuenta de almacenamiento. Para crear una directiva de copia de seguridad,
seleccioneCrear una nueva directiva.
 6. Seleccione Revisar y crear y, después, Crear para crear el recurso compartido de
archivos.

7. Cree un nuevo archivo txt denominado qsTestFile en la máquina local.

8. Seleccione el nuevo recurso compartido de archivos y en su ubicación, haga clic en

Cargar.

9. Vaya a la ubicación donde haya creado el archivo .txt > seleccione qsTestFile.txt>
seleccione Cargar.

Implementación de una máquina virtual

Ya ha creado una cuenta de Azure Storage y un recurso compartido de archivos con un
solo archivo en ella. A continuación, cree una máquina virtual de Azure con
Windows Server 2019 Datacenter que represente el servidor local en este tutorial.

1. Expanda el menú del lado izquierdo del portal y seleccione Crear un recurso en la
esquina superior izquierda de Azure Portal.

2. En Servicios populares, seleccione Máquinas virtuales.

3. En la pestaña Aspectos básicos, en Detalles del proyecto, seleccione el grupo de

recursos que creó anteriormente.
 4. En Detalles de la instancia, asigne a la máquina virtual el nombre qsVM.

5. En Tipo de seguridad, seleccione Estándar.

6. En Imagen, seleccione Windows Server 2019 Datacenter - x64 Gen2.

7. Mantenga los valores predeterminados en Región, Opciones de disponibilidad y

Tamaño.

8. En Cuenta de administrador, agregue un nombre de usuario y escriba una

contraseña para la máquina virtual.

9. En Reglas de puerto de entrada, elija Permitir los puertos seleccionados y luego

seleccione RDP (3389) y HTTP en la lista desplegable.

10. Seleccione Revisar + crear.

11. Seleccione Crear. La creación de una máquina virtual nueva tardará varios minutos
en completarse.

12. Después de completar la implementación de la máquina virtual, seleccione Ir al

recurso.

Conexión a la máquina virtual

Ahora que ha creado la máquina virtual, conéctese a ella para poder montar el recurso
compartido de archivos.

1. Seleccione Conectar en la página de propiedades de la máquina virtual.

 2. En la página Connect to virtual machine (Conectarse a una máquina virtual),
mantenga las opciones predeterminadas para conectarse por dirección IP a través
del número de puerto3389 y seleccione Descargar archivo RDP.

3. Abra el archivo RDP que descargó y haga clic en Conectar cuando se le solicite.

4. En la ventana Seguridad de Windows, seleccione Más opciones y, después, Usar

otra cuenta. Escriba el nombre de usuario con el siguiente formato,
localhost\nombre de usuario, siendo <nombre de usuario> el nombre de usuario
administrador de la máquina virtual que creó. Escriba la contraseña que creó para
la máquina virtual y, luego seleccione Aceptar.

5. Puede recibir una advertencia de certificado durante el proceso de inicio de sesión.

Seleccione Sí o Continuar para crear la conexión.

Asigne el recurso compartido de archivos de Azure a una

unidad de Windows
1. En Azure Portal, vaya al recurso compartido de archivos qsfileshare y seleccione
Conectar.

2. Seleccione una letra de unidad y, a continuación, Mostrar script.

3. Copie el script y péguelo en el Bloc de notas.

 

4. En la máquina virtual, abra PowerShell y pegue el contenido del Bloc de notas y

presione Entrar para ejecutar el comando. Debe asignar la unidad.

Creación de una instantánea de recurso

compartido
Ahora que ha asignado la unidad, cree una instantánea.

1. En el portal, vaya al recurso compartido de archivos, seleccione Instantáneas,

después, + Agregar instantánea y, a continuación, OK.

2. En la máquina virtual, abra qstestfile.txt y escriba "este archivo se ha modificado".

Guarde y cierre el archivo.

3. Cree otra instantánea.

Búsqueda de una instantánea de recurso

compartido
1. En el recurso compartido de archivos, seleccione Instantáneas.

2. En la pestaña Instantáneas, seleccione la primera instantánea de la lista.

3. Abra esa instantánea y seleccione qsTestFile.txt.

Restauración desde una instantánea
1. En la pestaña de instantánea de recurso compartido de archivo, haga clic con el
botón derecho en qsTestFile y seleccione el botón Restaurar.

2. Seleccione Sobrescribir el archivo original y, a continuación, OK.

3. En la máquina virtual, abra el archivo. Se ha restaurado la versión no modificada.

Eliminación de una instantánea de recurso

compartido
1. Para poder eliminar una instantánea de recurso compartido, deberá quitar los
bloqueos de la cuenta de almacenamiento. Vaya a la cuenta de almacenamiento
 que creó para este tutorial y seleccione Configuración>Bloqueos. Si se muestran
bloqueos, elimínelos.

2. En el recurso compartido de archivos, seleccione Instantáneas.

3. En la pestaña Instantáneas, seleccione la primera instantánea de la lista y

seleccione Eliminar.

Uso de una instantánea de recurso compartido

en Windows
Al igual que con las instantáneas de VSS locales, puede ver las instantáneas desde el
recurso compartido de archivos de Azure montado mediante la pestaña versiones
anteriores.

1. Ubique el recurso compartido montado en el Explorador de archivos.

2. Seleccione qsTestFile.txt>haga clic con el botón derecho y seleccione Propiedades

en el menú.
 3. Seleccione Versiones anteriores para ver la lista de instantáneas de recursos
compartidos de este directorio.

4. Seleccione Abrir para abrir el archivo.

Restaurar desde una versión anterior

 1. Seleccione Restaurar. Esta acción copia el contenido de todo un directorio de
forma recursiva en la ubicación original en el momento de la creación de la
instantánea del recurso compartido.

７ Nota

Si el archivo no ha cambiado, no verá una versión anterior para ese archivo

porque ese archivo es la misma versión que la instantánea. Esto es coherente
con el modo en que funciona en un servidor de archivos de Windows.

Limpieza de recursos
Cuando haya terminado, elimine el grupo de recursos. Al eliminar el grupo de recursos,
se elimina la cuenta de almacenamiento, el recurso compartido de archivos de Azure y
otros recursos que se implementaron en el grupo de recursos.

Si hubiera bloqueos en la cuenta de almacenamiento, primero deberá quitarlos. Vaya a

la cuenta de almacenamiento y seleccione Configuración>Bloqueos. Si se muestran
bloqueos, elimínelos.

Es posible que también tenga que eliminar el almacén de Azure Backup Recovery
Services antes de poder eliminar el grupo de recursos.

1. Seleccione Inicio y, a continuación, seleccione Grupos de recursos.

2. Seleccione el grupo de recursos que desea eliminar.
 3. Seleccione Eliminar grupo de recursos. Se abre una ventana con una advertencia
acerca de los recursos que se eliminarán con el grupo de recursos.
4. Escriba el nombre del grupo de recursos y, luego, seleccione Eliminar.

Pasos siguientes
Uso de un recurso compartido de archivos de Azure con Windows
Tutorial: Creación de un recurso
compartido de archivos NFS de Azure y
montaje del mismo en una máquina
virtual Linux mediante Azure Portal
Artículo • 10/10/2023

Azure Files ofrece recursos compartidos de archivos totalmente administrados en la

nube a los que se puede acceder mediante el protocolo SMB (Bloque de mensajes del
servidor) o el protocolo NFS (Network File System) estándar del sector. Los protocolos
NFS y SMB se admiten en máquinas virtuales (VM) de Azure que ejecutan Linux. En este
tutorial se muestra cómo crear un recurso compartido de archivos de Azure mediante el
protocolo NFS y conectarlo a una máquina virtual Linux.

En este tutorial, aprenderá lo siguiente:

＂ Crear una cuenta de almacenamiento

＂ Implementación de una máquina virtual Linux
＂ Creación de un recurso compartido de archivos NFS
＂ Conexión a la máquina virtual
＂ Montaje del recurso compartido de archivos en la máquina virtual

Se aplica a
Tipo de recurso compartido de archivos SMB NFS

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS

Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Introducción
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Inicie sesión en Azure Portal .

Creación de una cuenta de almacenamiento FileStorage

Para poder trabajar con un recurso compartido de archivos NFS 4.1 de Azure, es
necesario que cree una cuenta de almacenamiento de Azure con el nivel de rendimiento
prémium. Actualmente, los recursos compartidos de NFS 4.1 solo están disponibles
como recursos compartidos de archivos prémium.

1. En el menú de Azure Portal, seleccione Todos los servicios. En la lista de recursos,

escriba Cuentas de almacenamiento. Cuando comience a escribir, la lista se filtrará
en función de la entrada. Seleccione Cuentas de almacenamiento.
2. En la ventana Cuentas de almacenamiento que aparece, elija + Crear.
3. En la pestaña Aspectos básicos, seleccione la suscripción en la que se va a crear la
cuenta de almacenamiento.
4. En el campo Grupo de recursos, seleccione Crear nuevo para crear un grupo de
recursos nuevo para usar en este tutorial.
5. Escriba un nombre para la cuenta de almacenamiento. El nombre que elija debe
ser único en Azure. El nombre también debe tener una longitud de entre 3 y 24
caracteres, y solo puede contener números y letras minúsculas.
6. Seleccione una región para la cuenta de almacenamiento o utilice la región
predeterminada. Azure admite recursos compartidos de archivos NFS en las
mismas regiones que admiten el almacenamiento de archivos prémium.
7. Seleccione el nivel de rendimiento Premium para almacenar los datos en unidades
de estado sólido (SSD). En Tipo de cuenta Premium, seleccione Recursos
compartidos de archivos.
8. Mantenga la opción de replicación establecida en su valor predeterminado de
Almacenamiento con redundancia local (LRS).
9. Seleccione Revisar y crear para revisar la configuración de la cuenta de
almacenamiento y crear la cuenta.
10. Cuando aparezca la notificación Validación superada, seleccione Crear. Debería
ver una notificación informándole de que la implementación está en curso.

En la imagen siguiente se muestra la configuración de la pestaña Aspectos básicos de

una nueva cuenta de almacenamiento:
 

Implementación de una máquina virtual de

Azure que ejecuta Linux
A continuación, cree una máquina virtual de Azure que ejecute Linux para representar el
servidor en el entorno local. Al crear la máquina virtual, se creará automáticamente una
red virtual. El protocolo NFS solo se puede usar desde una máquina dentro de una red
virtual.

1. Seleccione Inicio y, a continuación, Máquinas virtuales en Servicios de Azure.

2. Seleccione + Crear y, después, + Máquina virtual de Azure.

3. En la pestaña Aspectos básicos, en Detalles del proyecto, asegúrese de que la

suscripción y el grupo de recursos correctos están seleccionados. En Detalles de
instancia, escriba myVM en Nombre de máquina virtual y seleccione la misma
región que la cuenta de almacenamiento. Elija la distribución de Linux para la
imagen. Deje los demás valores predeterminados. El tamaño y los precios
predeterminados solo se muestran como ejemplo. La disponibilidad y los precios
del tamaño dependen de su región y suscripción.
 

4. En Cuenta de administrador , seleccione Clave pública SSH. Deje el resto de

valores predeterminados.

5. En Reglas de puerto de entrada > Puertos de entrada públicos, elija Permitir los
puertos seleccionados y luego seleccione SSH (22) y HTTP (80) en la lista
desplegable.
 

） Importante

Solo se recomienda establecer puertos SSH abiertos a Internet para realizar

pruebas. Si quiere cambiar esta configuración más adelante, vuelva a la
pestaña Aspectos básicos.

6. Seleccione el botón Revisar y crear de la parte inferior de la página.

7. En la página Crear una máquina virtual verá los detalles de la máquina virtual que
va a crear. Anote el nombre de la red virtual. Cuando esté preparado, seleccione
Crear.

8. Cuando se abra la ventana Generar nuevo par de claves, seleccione Descargar la

clave privada y crear el recurso. El archivo de clave se descargará como
myVM_key.pem. Asegúrese de saber dónde se descargó el archivo .pem, ya que
necesitará la ruta de acceso al archivo para conectarse a la máquina virtual.

Verá un mensaje que indica que la implementación está en curso. Espere unos minutos
a que se complete la implementación.

Creación de un recurso compartido de archivos

NFS de Azure
Ahora está listo para crear un recurso compartido de archivos NFS y proporcionar
seguridad de nivel de red para el tráfico NFS.

Adición de un recurso compartido de archivos a la cuenta

de almacenamiento
1. Seleccione Inicio y, a continuación, Cuentas de almacenamiento.
2. Seleccione la cuenta de almacenamiento que ha creado.

3. Seleccione Almacenamiento de datos y Recursos compartidos de archivos en el

panel de la cuenta de almacenamiento.

4. Seleccione + Recurso compartido de archivos.

5. Asigne al nuevo recurso compartido de archivos el nombre qsfileshare y escriba

"100" para la Capacidad mínima aprovisionada o aprovisione más capacidad
(hasta 102 400 GiB) para obtener más rendimiento. Seleccione el protocolo NFS,
deje seleccionada la opción Sin restringir raíz y seleccione Crear.
 

Configurar un punto de conexión privado o un punto de

conexión de servicio
A continuación, configure un punto de conexión privado para la cuenta de
almacenamiento. Esto proporciona a la cuenta de almacenamiento una dirección IP
privada desde el espacio de direcciones de la red virtual. Se aplican las tasas de
procesamiento de datos estándar para los puntos de conexión privados. Si no
necesita una dirección IP estática, puede usar un punto de conexión de servicio en su
lugar. No se realiza ningún cargo adicional por el uso de puntos de conexión de servicio.

1. Seleccione el recurso compartido de archivos qsfileshare. Debería ver un cuadro de

diálogo que indica Conectar a este recurso compartido de NFS desde Linux. En
Configuración de red, seleccione Opciones de revisión.

2. A continuación, seleccione Configurar un punto de conexión privado.

3. Seleccione + Punto de conexión privado.

4. Deje Suscripción y Grupo de recursos como están. En Instancia, proporcione un
nombre y seleccione una región para el nuevo punto de conexión privado. El
punto de conexión privado debe estar en la misma región que la red virtual, por lo
que debe usar la misma región que especificó al crear la máquina virtual. Cuando
haya completado todos los campos, seleccione Siguiente: Recurso.

5. Confirme que la Suscripción, el Tipo de recurso y el Recurso son correctos y

seleccione Archivo en la lista desplegable Subrecurso de destino. A continuación,
seleccione Siguiente: Red virtual.


6. En Redes, seleccione la red virtual asociada a la máquina virtual y deje la subred
predeterminada. En la sección Configuración de IP privada, seleccione Asignar
dirección IP de forma dinámica. Seleccione Next: DNS (Siguiente: DNS).

7. En Integrar con la zona DNS privada, seleccione Sí. Asegúrese de que están
seleccionados la suscripción y el grupo de recursos correctos y, después,
seleccione Siguiente: Etiquetas.

8. Opcionalmente, puede aplicar etiquetas para clasificar los recursos, como aplicar el
nombre Entorno y el valor Prueba a todos los recursos de prueba. Escriba pares
 nombre-valor si quiere y, a continuación, seleccione Siguiente: Revisar y crear.

9. Azure intentará validar el punto de conexión privado. Una vez completada la

validación, seleccione Crear. Verá una notificación informándole de que la
implementación está en curso. Transcurridos unos minutos, debería ver una
notificación indicando que la implementación se ha completado.

Deshabilitación de la transferencia segura

Azure Files no admite actualmente el cifrado en tránsito con el protocolo NFS y se basa
en la seguridad de nivel de red. Por lo tanto, deberá deshabilitar la transferencia segura.

1. Seleccione Inicio y, a continuación, Cuentas de almacenamiento.

2. Seleccione la cuenta de almacenamiento que ha creado.

3. Seleccione Recursos compartidos de archivos en el panel de la cuenta de

almacenamiento.

4. Seleccione el recurso compartido de archivos NFS que ha creado. En

Configuración de transferencia segura, seleccione Cambiar configuración.


 5. Cambie la opción Se requiere transferencia segura a Deshabilitado y seleccione
Guardar. El cambio puede tardar hasta 30 segundos en surtir efecto.

Conexión a la máquina virtual

Cree una conexión SSH con la máquina virtual.

1. Seleccione Inicio y, a continuación, Máquinas virtuales.

2. Seleccione la máquina virtual Linux que ha creado para este tutorial y asegúrese de
que su estado es En ejecución. Tome nota de la dirección IP pública de la máquina
virtual y cópiela en el portapapeles.

3. Si está en una máquina Mac o Linux, abra un símbolo del sistema de Bash. Si está
en una máquina Windows, abra un símbolo del sistema de PowerShell.

4. Cuando se le solicite, abra una conexión SSH a la máquina virtual. Reemplace la

dirección IP por la de la máquina virtual y reemplace la ruta de acceso al archivo
 .pem por la ruta de acceso a la ubicación en la que se descargó el archivo de clave.

Consola

ssh -i .\Downloads\myVM_key.pem [email protected]

Si recibe una advertencia de que no se puede establecer la autenticidad del host, escriba
sí para continuar con la conexión a la máquina virtual. Deje abierta la conexión SSH para
el paso siguiente.

 Sugerencia

Ahora la clave SSH que creó se puede usar la próxima vez que cree una máquina
virtual en Azure. Solo tiene que seleccionar la opción Usar la clave existente
almacenada en Azure en Origen de clave pública SSH la próxima vez que cree una
máquina virtual. Ya dispone de la clave privada en el equipo, por lo que no tendrá
que descargar nada.

Montaje de recurso compartido de archivos

NFS
Ahora que ha creado un recurso compartido de NFS, para usarlo debe montarlo en el
cliente Linux.

1. Seleccione Inicio y, a continuación, Cuentas de almacenamiento.

2. Seleccione la cuenta de almacenamiento que ha creado.

3. Seleccione Recursos compartidos de archivos en el panel de la cuenta de

almacenamiento y seleccione el recurso compartido de archivos NFS que ha
creado.

4. Debería consultar Conexión a este recurso compartido de archivos NFS desde

Linux junto con comandos de ejemplo para usar NFS en la distribución de Linux y
un script de montaje que contenga las opciones de montaje necesarias. Para ver
otras opciones de montaje recomendadas, consulte Montaje del recurso
compartido de archivos de Azure NFS en Linux.

） Importante
 El script de montaje proporcionado montará el recurso compartido NFS solo
hasta que se reinicie la máquina Linux. Para montar automáticamente el
recurso compartido cada vez que se reinicia la máquina, consulte Montaje de
un recurso compartido NFS mediante /etc/fstab.

5. Seleccione su distribución de Linux.

6. Mediante la conexión SSH que ha creado con la máquina virtual, escriba los
comandos de ejemplo para usar NFS y montar el recurso compartido de archivos.

Ahora ha montado el recurso compartido de archivos NFS y está listo para almacenar
archivos.

Limpieza de recursos
Cuando haya terminado, elimine el grupo de recursos. Al eliminar el grupo de recursos,
se elimina la cuenta de almacenamiento, el recurso compartido de archivos de Azure y
otros recursos que se implementaron en el grupo de recursos.

1. Seleccione Inicio y, a continuación, seleccione Grupos de recursos.

2. Seleccione el grupo de recursos que ha creado para este tutorial.
3. Seleccione Eliminar grupo de recursos. Se abre una ventana con una advertencia
acerca de los recursos que se eliminarán con el grupo de recursos.
4. Escriba el nombre del grupo de recursos y, luego, seleccione Eliminar.

Pasos siguientes
Obtenga más información sobre el uso de recursos compartidos de archivos NFS
de Azure
.
Tutorial: Extensión de servidores de
archivos de Windows con Azure File
Sync
Artículo • 01/06/2023

En este artículo se demuestran los pasos básicos para ampliar la capacidad de

almacenamiento de un servidor con Windows Server mediante Azure File Sync. Aunque
este tutorial presenta un servidor con Windows Server como una máquina virtual de
Azure, lo habitual es realizar este proceso para servidores locales. En el artículo
Implementación de Azure File Sync puede encontrar instrucciones para implementar
Azure File Sync en su propio entorno.

＂ Implementación del servicio de sincronización de almacenamiento

＂ Preparación de Windows Server para su uso con Azure File Sync
＂ Instalación del agente de Azure File Sync
＂ Registro de un servidor de Windows Server en el servicio de sincronización de
almacenamiento
＂ Creación de un grupo de sincronización y un punto de conexión en la nube
＂ Creación de un punto de conexión de servidor

Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Inicio de sesión en Azure

Inicie sesión en Azure Portal .

Preparación del entorno

Para este tutorial, deberá realizar las siguientes operaciones antes de implementar Azure
File Sync:

Crear una cuenta de Azure Storage y un recurso compartido

Configurar una máquina virtual con Windows Server 2019 Datacenter
Preparar la máquina virtual con Windows Server para Azure File Sync

Creación de una carpeta y un archivo .txt

En el equipo local, cree una carpeta nueva denominada FilesToSync y agregue un archivo
de texto denominado mytestdoc.txt. Dicho archivo se cargará en el recurso compartido
de archivos más adelante.

Crear una cuenta de almacenamiento

Para crear una cuenta de almacenamiento de uso general v2 en Azure Portal, siga estos
pasos:

1. En Servicios de Azure, seleccione Cuentas de almacenamiento.

2. En la página Cuentas de almacenamiento, elija + Create (+ Crear).
3. En la hoja Aspectos básicos, seleccione la suscripción en la que se va a crear la
cuenta de almacenamiento.
4. En el campo Grupo de recursos, seleccione el grupo de recursos deseado o cree
uno nuevo. Para más información sobre los grupos de recursos de Azure, consulte
Información general de Azure Resource Manager.
5. Después, escriba un nombre para la cuenta de almacenamiento. El nombre que
elija debe ser único en Azure. El nombre también debe tener una longitud de entre
3 y 24 caracteres, y solo puede contener números y letras minúsculas.
6. Seleccione una región para la cuenta de almacenamiento o utilice la región
predeterminada.
7. Seleccione un nivel de rendimiento. El valor predeterminado es Estándar.
8. Especifique cómo se replicará la cuenta de almacenamiento. La opción de
redundancia predeterminada es Almacenamiento con redundancia geográfica (GRS)
. Para más información acerca de las opciones de replicación disponibles, consulte
Redundancia de Azure Storage.
9. Hay otras opciones disponibles en las hojas Opciones avanzadas, Redes,
Protección de datos y Etiquetas. Para utilizar Azure Data Lake Storage, elija la hoja
Opciones avanzadas y, después, establezca Espacio de nombres jerárquico en
Habilitado. Para más información, consulte Introducción a Azure Data Lake
Storage Gen2.
10. Seleccione Revisar y crear para revisar la configuración de la cuenta de
almacenamiento y crear la cuenta.
11. Seleccione Crear.

En la imagen siguiente se muestra la configuración de la hoja Aspectos básicos de una

nueva cuenta de almacenamiento:
 

Creación de un recurso compartido de archivos

Tras implementar una cuenta de Azure Storage, siga estos pasos para crear un recurso
compartido de archivos.

1. En Azure Portal, seleccione Ir al recurso.

2. En el menú de la izquierda, seleccione Almacenamiento de datos>Recursos

compartidos de archivos.

3. Seleccione + Recurso compartido de archivos.

4. Asigne al nuevo recurso compartido de archivos el nombre afsfileshare, deje el

nivel establecido en Optimizado para transacciones y, luego, seleccione Crear. Solo
necesita 5 TiB para este tutorial.
 5. Seleccione el recurso compartido de archivos nuevo. En la ubicación del recurso
compartido de archivos, seleccione Cargar.

6. Vaya a la carpeta FilesToSync en la máquina local en la que creó el archivo .txt,

seleccione mytestdoc.txt y, después, seleccione Cargar.

Ya ha creado una cuenta de almacenamiento y un recurso compartido de archivos con

un archivo en él. A continuación, implementará una VM de Azure con Windows Server
2019 Datacenter que representará el servidor local en este tutorial.
Implementación de una máquina virtual y conexión de un
disco de datos
1. Seleccione Inicio en Azure Portal y, en Servicios de Azure, seleccione + Crear un
recurso.

2. En Servicios populares de Azure, seleccione Máquina virtual>Crear.

3. En Detalles del proyecto, seleccione la suscripción y el grupo de recursos que creó

para este tutorial.

4. En Detalles de instancia, especifique el nombre de la máquina virtual. Por ejemplo,

use MiVM.

5. No cambie la configuración predeterminada en Región, Opciones de

disponibilidad y Tipo de seguridad.

6. En Imagen seleccione Windows Server 2019 Datacenter - Gen2. Deje Tamaño

establecido en el valor predeterminado.
7. En Cuenta de administrador, especifique el nombre de usuario y la contraseña de
la máquina virtual. El nombre de usuario debe tener entre 1 y 20 caracteres y no
puede contener caracteres especiales \/""[]:|<>+=;,?*@& ni terminar con '.' La
contraseña debe tener entre 12 y 123 caracteres y debe tener 3 de las siguientes
opciones: 1 carácter en minúsculas, 1 carácter en mayúscula, 1 número y 1 carácter
especial.

8. En Reglas de puerto de entrada, elija Permitir los puertos seleccionados y, luego,

seleccione RDP (3389) y HTTP (80) en el menú desplegable.

9. Antes de crear la máquina virtual, es preciso crear un disco de datos.

a. En la parte inferior de la página, seleccione Siguiente: Discos.

b. En la pestaña Discos, en Opciones de disco, deje los valores predeterminados.

c. En Discos de datos, seleccione Crear y adjuntar un nuevo disco.

d. Use la configuración predeterminada, salvo en Tamaño, que se puede cambiar a

4 GiB para este tutorial al seleccionar Cambiar tamaño.
 e. Seleccione Aceptar.

10. Seleccione Revisar + crear.

11. Seleccione Crear.

Puede seleccionar el icono Notificaciones para ver el progreso de la

implementación. La creación de una máquina virtual tarda varios minutos en
completarse.

12. Después de que se complete la implementación de la máquina virtual, seleccione Ir

al recurso.

Ya ha creado una nueva máquina virtual y ha conectado un disco de datos. Después,

conéctese a la máquina virtual.

Conexión a la máquina virtual

1. En Azure Portal, seleccione Conectar>RDP en la página de propiedades de la VM.
2. En la página Conectar, mantenga las opciones predeterminadas para conectarse
mediante la dirección IP pública a través del puerto 3389. Seleccione Descargar
archivo RDP.

3. Abra el archivo RDP que descargó y haga clic en Conectar cuando se le solicite. Es
posible que vea la siguiente advertencia: No se puede identificar el publicador de
esta conexión remota. Haga clic en Conectar de todos modos.

4. En la ventana Seguridad de Windows que le pide que escriba las credenciales,

seleccione Más opciones y, luego, Usar otra cuenta. Escriba localhost\username en
el campo dirección de correo electrónico, escriba la contraseña que creó para la
VM y, después, seleccione Aceptar.
 5. Es posible que reciba una advertencia de certificado durante el proceso de inicio
de sesión que indica que no se puede comprobar la identidad del equipo remoto.
Seleccione Sí o Continuar para crear la conexión.

Preparación de la VM con Windows Server

En el caso de la VM con Windows Server 2019 Datacenter, deshabilite Configuración de
seguridad mejorada de Internet Explorer. Este paso solo es necesario para el registro
inicial del servidor. Se puede volver a habilitar una vez registrado el servidor.

En la VM con Windows Server 2019 Datacenter, el Administrador del servidor se abre

automáticamente. Si el Administrador del servidor no se abre de forma predeterminada,
búsquelo en el menú Inicio.

1. En el Administrador del servidor, seleccione Servidor local.

2. En el panel Propiedades, busque la entrada de Configuración de seguridad

mejorada de IE y haga clic en Activar.

3. En el cuadro de diálogo Configuración de seguridad mejorada de Internet

Explorer, seleccione Desactivar en Administradores y Usuarios y, luego, seleccione
Aceptar.
Ya puede agregar el disco de datos a la máquina virtual.

Incorporación del disco de datos

1. En la VM con Windows Server 2019 Datacenter, haga clic en Files and storage
services>Volumes>Disks (Archivos y servicios de almacenamiento > Volúmenes >
Discos).

2. Haga clic con el botón derecho en el disco de 4 GiB llamado Msft Virtual Disk y
seleccione New volume (Volumen nuevo).

3. Finalice el asistente. Use la configuración predeterminada y tome nota de la letra

de unidad asignada.

4. Seleccione Crear.

5. Seleccione Cerrar.
 Ya está el disco en línea y ha creado un volumen. Abra el Explorador de archivos en
la máquina virtual de Windows Server para confirmar la presencia del disco de
datos recién agregado.

6. En el Explorador de archivos de la máquina virtual, expanda Este PC y abra la

nueva unidad. En este ejemplo es la unidad F:.

7. Haga clic con el botón derecho y seleccione Nueva>carpeta. Asigne a la carpeta el

nombre FilesToSync.

8. Abra la carpeta FilesToSync.

9. Haga clic con el botón derecho y seleccione Nuevo>Documento de texto. Asigne

el archivo de texto el nombre MyTestFile.

10. Cierre el Explorador de archivos y el Administrador del servidor.

Instalación del módulo de Azure PowerShell

A continuación, en la VM con Windows Server 2019 Datacenter, instale el módulo de
Azure PowerShell en el servidor. El módulo Az es un módulo acumulativo para los
cmdlets de Azure PowerShell. Al instalarlo, se descargan todos los módulos disponibles
de Azure Resource Manager y hace que sus cmdlets estén disponibles para su uso.

1. En la VM, abra una ventana de PowerShell con privilegios elevados (ejecute como
administrador).

2. Ejecute el siguiente comando:

PowerShell

Install-Module -Name Az
 ７ Nota

Si tiene una versión de NuGet anterior a la 2.8.5.201, se le pedirá que

descargue e instale la versión más reciente.

De forma predeterminada, la Galería de PowerShell no está configurada como un

repositorio de confianza para PowerShellGet. La primera vez que use PSGallery
verá el siguiente mensaje:

Resultados

Untrusted repository

You are installing the modules from an untrusted repository. If you

trust this repository, change its InstallationPolicy value by running
the Set-PSRepository cmdlet.

Are you sure you want to install the modules from 'PSGallery'?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "N"):

3. Responda Sí o Sí a todo para continuar con la instalación.

Ya ha configurado el entorno para el tutorial Cierre la ventana de PowerShell. y está listo

para implementar el servicio de sincronización de almacenamiento.

Implementación del servicio de sincronización

de almacenamiento
Para implementar Azure File Sync, en primer lugar coloque un recurso del servicio de
sincronización de almacenamiento en un grupo de recursos de la suscripción
seleccionada. El servicio de sincronización de almacenamiento hereda los permisos de
acceso de su suscripción y del grupo de recursos.

1. En Azure Portal, seleccione Crear un recurso y busque Azure File Sync.

2. En los resultados de la búsqueda, haga clic en Azure File Sync.

3. Seleccione Crear para abrir la pestaña Implementar Azure File Sync.

 En el panel que se abre, escriba la siguiente información:

Value Descripción

Nombre Un nombre único (por suscripción) para el servicio de sincronización de

almacenamiento.

Use afssyncservice02 para este tutorial.

Suscripción La suscripción de Azure que utiliza para este tutorial.

Grupos de el grupo de recursos que contiene el servicio de sincronización de

recursos almacenamiento.

Use myexamplegroup para este tutorial.

Ubicación Este de EE. UU.

4. Cuando termine, seleccione Revisar y crear y, luego, Crear para implementar el

Servicio de sincronización de almacenamiento. La implementación del servicio
tardará varios minutos.

5. Cuando la implementación se complete, seleccione Ir al grupo de recursos.

Instalación del agente de Azure File Sync

El agente de Azure File Sync es un paquete descargable que permite la sincronización
de Windows Server con un recurso compartido de archivos de Azure.

1. En la VM con Windows Server 2019 Datacenter, abra Internet Explorer.

） Importante

Es posible que vea una advertencia que le indica que active la configuración
de seguridad mejorada de Internet Explorer. No vuelva a activarla hasta que
haya terminado de registrar el servidor en el paso siguiente.

2. Vaya al Centro de descarga de Microsoft . Desplácese hacia abajo hasta la

sección Azure File Sync Agent (agente de Azure File Sync) y haga clic en
Download (Descargar).

3. Seleccione la casilla de StorageSyncAgent_WS2019.msi y, después, Siguiente.

4. Seleccione Permitir una vez>Run.

5. Siga el Asistente para instalación de agente de sincronización de

almacenamiento y acepte los valores predeterminados.
 6. Seleccione Instalar.

7. Seleccione Finalizar.

Ha implementado el Servicio de sincronización de Azure e instalado el agente en la VM

con Windows Server. Ahora tiene que registrar la máquina virtual en el servicio de
sincronización de almacenamiento.

Registro de Windows Server

Si el servidor de Windows Server se registra en un servicio de sincronización de
almacenamiento, se establece una relación de confianza entre el servidor (o el clúster) y
el servicio. Un servidor no se puede registrar en más de un servicio de sincronización de
almacenamiento. No obstante, se puede sincronizar con otros servidores y recursos
compartidos de archivos de Azure asociados con dicho servicio.

Tras la instalación del agente de Azure File Sync, la interfaz de usuario de Registro del
servidor se debería abrir automáticamente. Si no es así, puede abrirla manualmente
desde su ubicación de archivo: C:\Program
Files\Azure\StorageSyncAgent\ServerRegistration.exe.

1. Cuando la interfaz de usuario del registro del servidor se abra en la VM, seleccione
Iniciar sesión.

2. Inicie sesión con las credenciales de su cuenta de Azure.

3. Proporcione la siguiente información:

 Value Descripción

Suscripción de Azure La suscripción que contiene el servicio de sincronización de

almacenamiento de este tutorial.

Grupo de recursos el grupo de recursos que contiene el servicio de sincronización

de almacenamiento. Use myexamplegroup para este tutorial.

Servicio de El nombre del servicio de sincronización de almacenamiento. Use

sincronización de afssyncservice02 para este tutorial.
almacenamiento

4. Seleccione Registrar para completar el registro del servidor.

5. Como parte del proceso de registro, se le solicita un que vuelva a iniciar sesión.
Inicie sesión y seleccione Siguiente.

6. Seleccione Aceptar.

Creación de un grupo de sincronización

Un grupo de sincronización define la topología de sincronización de un conjunto de
archivos. Un grupo de sincronización debe contener un punto de conexión en la nube,
que representa un recurso compartido de archivos de Azure. También debe contener
uno o varios puntos de conexión de servidor. Un punto de conexión de servidor
representa una ruta de acceso en un servidor registrado. Para crear un grupo de
sincronización:

1. En Azure Portal , seleccione + Grupo de sincronización en el servicio de

sincronización de almacenamiento que ha implementado.

2. Escriba la siguiente información para crear un grupo de sincronización con un

punto de conexión en la nube:

Value Descripción
 Value Descripción

Nombre del Este nombre debe ser único dentro del servicio de sincronización de
grupo de almacenamiento, pero puede ser cualquier nombre que considere
sincronización lógico.

Suscripción La suscripción en la que se ha implementado el servicio de

sincronización de almacenamiento de este tutorial.

Cuenta de Elija Seleccionar cuenta de almacenamiento. En el panel que aparece,

almacenamiento seleccione la cuenta de almacenamiento que tiene el recurso
compartido de archivos de Azure que ha creado.

Recurso El nombre del recurso compartido de archivos de Azure que ha creado.

compartido de
archivos de
Azure

3. Seleccione Crear.

Si selecciona el grupo de sincronización, puede ver que ahora tiene uno punto de
conexión en la nube.

Adición de un punto de conexión de servidor

Un punto de conexión del servidor representa una ubicación concreta en un servidor
registrado. Por ejemplo, una carpeta en un volumen de servidor. Para agregar un punto
de conexión del servidor:

1. Seleccione al grupo de sincronización recién creado y, después, seleccione

Agregar punto de conexión del servidor.

2. En el panel Agregar punto de conexión del servidor, escriba la siguiente

información para crear un punto de conexión del servidor:
 Value Descripción

Servidor registrado El nombre del servidor que ha creado. Por ejemplo, myVM.

Path La ruta de acceso del servidor de Windows Server a la unidad que

ha creado. Por ejemplo, f:\filestosync.

Nube por niveles Déjelo deshabilitado para este tutorial.

Espacio disponible Déjelo en blanco para este tutorial.

del volumen

3. Seleccione Crear.

Los archivos ya están sincronizados entre el recurso compartido de archivos de Azure y

Windows Server.

Limpieza de recursos
Si desea limpiar los recursos que ha creado en este tutorial, primero elimine los puntos
de conexión del servicio de sincronización de almacenamiento. A continuación, anule el
registro del servidor con el servicio de sincronización de almacenamiento, quite los
grupos de sincronización y elimine el servicio de sincronización.

Cuando haya terminado, elimine el grupo de recursos. Al eliminar el grupo de recursos,

se elimina la cuenta de almacenamiento, el recurso compartido de archivos de Azure y
otros recursos que se implementaron en el grupo de recursos.

1. Seleccione Inicio y, a continuación, seleccione Grupos de recursos.

2. Seleccione el grupo de recursos que desea eliminar.
3. Seleccione Eliminar grupo de recursos. Se abre una ventana con una advertencia
acerca de los recursos que se eliminarán con el grupo de recursos.
4. Escriba el nombre del grupo de recursos y, luego, seleccione Eliminar.

Pasos siguientes
En este tutorial, ha aprendido los pasos básicos necesarios para ampliar la capacidad de
almacenamiento de un servidor con Windows Server mediante Azure File Sync. Para
obtener una visión más completa del planeamiento de una implementación de Azure
File Sync, consulte:

Planeamiento de una implementación de Azure Files Sync

Planeamiento de una implementación
de Azure Files
Artículo • 05/10/2023

Puede implementar Azure Files de dos formas: montando directamente los recursos
compartidos de archivos de Azure sin servidor o almacenando en caché recursos
compartidos de archivos de Azure localmente mediante Azure File Sync. Las
consideraciones de implementación cambiarán en función de la opción que escoja.

Montaje directo de un recurso compartido de archivos de Azure: dado que Azure

Files proporciona acceso mediante Bloque de mensajes del servidor (SMB) o
Network File System (NFS), puede montar recursos compartidos de archivos de
Azure en el entorno local o en la nube mediante los clientes SMB o NFS estándar
disponibles en el sistema operativo. Dado que los recursos compartidos de
archivos de Azure no tienen servidor, la implementación en escenarios de
producción no requiere la administración de un servidor de archivos o un
dispositivo NAS. lo que significa que no tiene que aplicar revisiones de software ni
intercambiar discos físicos.

Almacenamiento en caché de recursos compartidos de archivos de Azure

localmente con Azure File Sync: Azure File Sync le permite centralizar los recursos
compartidos de archivos de su organización en Azure Files sin renunciar a la
flexibilidad, el rendimiento y la compatibilidad de un servidor de archivos local.
Azure File Sync transforma una instancia de Windows Server local (o en la nube) en
una caché rápida del recurso compartido de archivos SMB de Azure.

En este artículo se abordan principalmente las consideraciones de implementación de

un recurso compartido de archivos de Azure que se va a montar directamente mediante
un cliente local o en la nube. Para planear una implementación de Azure File Sync,
consulte Planeamiento de una implementación de Azure File Sync.

Protocolos disponibles
Azure Files ofrece dos protocolos de sistema de archivos estándar del sector para
montar recursos compartidos de archivos de Azure: el protocolo Bloque de mensajes
del servidor (SMB) y el protocolo Network File System (NFS), permitiéndole elegir el
protocolo que se ajuste más a su carga de trabajo. Los recursos compartidos de archivos
de Azure no admiten los protocolos SMB y NFS en el mismo recurso compartido de
archivos, aunque puede crear recursos compartidos de archivos de Azure SMB y NFS
dentro de la misma cuenta de almacenamiento. Actualmente, NFS 4.1 solo se admite en
el nuevo tipo de cuenta de almacenamiento FileStorage (solo recursos compartidos de
archivos premium).

Con los recursos compartidos de archivos SMB y NFS, Azure Files ofrece recursos
compartidos de archivos de nivel empresarial que se pueden escalar verticalmente para
satisfacer sus necesidades de almacenamiento y a los que pueden acceder
simultáneamente miles de clientes.

Característica SMB NFS

Versiones de protocolo SMB 3.1.1, SMB 3.0, SMB 2.1 NFS 4.1
admitidas

SO recomendado Windows 11, versión 21H2+ Versión posterior a la 4.3 del

Windows 10, versión 21H1 o kernel de Linux
posterior
Windows Server 2019 o posterior
Versión 5.3 o posterior del kernel
de Linux

Niveles disponibles Premium, optimizado para Premium

transacciones, acceso frecuente y
acceso esporádico

Modelo de facturación Capacidad aprovisionada para Capacidad aprovisionada

recursos compartidos de archivos
premium
Pago por uso para recursos
compartidos de archivos estándar

Puntos de conexión de Compatible Compatible

zona de Azure DNS
(versión preliminar)

Redundancia LRS, ZRS, GRS, GZRS LRS, ZRS

Semántica del sistema Win32 POSIX

de archivos

Authentication Autenticación basada en identidad Autenticación basada en

(Kerberos), autenticación de clave host
compartida (NTLMv2)

Authorization Listas de control de acceso (ACL) de Permisos de estilo UNIX

estilo Win32

Distinción entre Sin distinción de mayúsculas y Distingue mayúsculas de

mayúsculas y minúsculas, conservación de minúsculas
Característica SMB NFS

minúsculas mayúsculas y minúsculas

Eliminación o Solo con bloqueo Sí

modificación de
archivos abiertos

Uso compartido de Modo de uso compartido de Windows Network Lock Manager con
archivos bloqueo aconsejado de
intervalo de bytes

Compatibilidad con No compatible Compatible

vínculos físicos

Compatibilidad con los No compatible Compatible

vínculos simbólicos

Opcionalmente Sí (solo SMB 3.0 o posterior) No

accesible desde Internet

Admite FileREST Sí Subconjunto:

Operaciones en
FileService
Operaciones en
FileShares
Operaciones en
Directories
Operaciones en Files

Bloqueos de intervalo Compatible No compatible

de bytes obligatorios

Bloqueos de intervalo No compatible Compatible

de bytes de aviso

Atributos extendidos o No compatible No compatible

con nombre

Flujos de datos No compatible N/D

alternativos

Identificadores de No compatible N/D

objeto

Puntos de repetición de No compatible N/D

análisis

Archivos dispersos No compatible N/D

 Característica SMB NFS

Compresión No compatible N/D

Canalizaciones con No compatible N/D

nombre

SMB directo No compatible N/D

Concesión de directorio No compatible N/D

SMB

Instantánea de volumen No compatible N/D

Nombres de archivos No compatible N/D

cortos (alias 8.3)

Servicio de servidor No compatible N/D

Transacciones del No compatible N/D

sistema de archivos
(TxF)

Conceptos de administración
Los recursos compartidos de archivos de Azure se implementan en cuentas de
almacenamiento, que son objetos de nivel superior que representan un grupo
compartido de almacenamiento. Este grupo de almacenamiento se puede usar para
implementar varios recursos compartidos de archivos, así como otros recursos de
almacenamiento, tales como contenedores de blobs, colas o tablas. Todos los recursos
de almacenamiento que se implementan en una cuenta de almacenamiento comparten
los límites que se aplican a esa cuenta de almacenamiento. Para ver los límites actuales
de una cuenta de almacenamiento, consulte Objetivos de escalabilidad y rendimiento
de Azure Files.

Hay dos tipos principales de cuentas de almacenamiento que se usarán para las
implementaciones de Azure Files:

Cuentas de almacenamiento de uso general, versión 2 (GPv2) : Las cuentas de

almacenamiento de GPv2 permiten implementar recursos compartidos de archivos
de Azure en hardware estándar o basado en disco duro (HDD). Además de
almacenar recursos compartidos de archivos de Azure, las cuentas de
almacenamiento de GPv2 pueden almacenar otros recursos de almacenamiento,
como contenedores de blobs, colas o tablas.
 Cuentas de almacenamiento FileStorage: Las cuentas de almacenamiento
FileStorage permiten implementar recursos compartidos de archivos de Azure en
hardware prémium o basado en unidades de estado sólido (SSD). Las cuentas
FileStorage solo se pueden usar para almacenar recursos compartidos de archivos
de Azure. No se puede implementar ningún otro recurso de almacenamiento
(contenedores de blobs, colas, tablas, etc.) en una cuenta FileStorage. Solo las
cuentas de FileStorage pueden implementar recursos compartidos de archivos
SMB y NFS.

Existen otros tipos de cuenta de almacenamiento que puede encontrar en el Azure

Portal, PowerShell o la CLI. Dos tipos de cuentas de almacenamiento, BlockBlobStorage
y BlobStorage, no pueden contener recursos compartidos de archivos de Azure. Los
otros dos tipos de cuenta de almacenamiento que puede ver son las cuentas de
almacenamiento clásico y de uso general de la versión 1 (GPv1), y ambas pueden
contener recursos compartidos de archivos de Azure. Aunque las cuentas de
almacenamiento clásico y de GPv1 pueden contener recursos compartidos de archivos
de Azure, la mayoría de las nuevas características de Azure Files solo están disponibles
en las cuentas de almacenamiento de GPv2 y FileStorage. Por lo tanto, se recomienda
usar solo las cuentas de almacenamiento de GPv2 y FileStorage para las nuevas
implementaciones, así como actualizar las cuentas de almacenamiento de GPv1 y clásico
si ya existen en su entorno.

Al implementar recursos compartidos de archivos de Azure en cuentas de

almacenamiento, se recomienda:

Implementar solo recursos compartidos de archivos de Azure en cuentas de

almacenamiento con otros recursos compartidos de archivos de Azure. Aunque las
cuentas de almacenamiento de GPv2 permiten tener cuentas de almacenamiento
de propósito combinado, dado que los recursos de almacenamiento como los
recursos compartidos de archivos de Azure y los contenedores de blobs
comparten los límites de la cuenta de almacenamiento, la combinación de recursos
puede dificultar la solución de problemas de rendimiento más adelante.

Prestar atención a las limitaciones de IOPS de la cuenta de almacenamiento al

implementar recursos compartidos de archivos de Azure. Lo ideal sería asignar
recursos compartidos de archivos 1:1 con cuentas de almacenamiento. Sin
embargo, quizás no sea posible debido a diversos límites y restricciones, tanto de
su organización como de Azure. Cuando no sea posible tener un solo recurso
compartido de archivos implementado en una cuenta de almacenamiento, tenga
en cuenta qué recursos compartidos estarán muy activos y cuales estarán menos
activos, con el fin de asegurarse de que los recursos compartidos de archivos más
activos no se colocan en la misma cuenta de almacenamiento.
 Implementar solamente cuentas de GPv2 y FileStorage, y actualizar las cuentas de
almacenamiento clásicas y de GPv1, cuando las encuentre en su entorno.

Identidad
Para acceder a un recurso compartido de archivos de Azure, el usuario debe estar
autenticado y tener la debida autorización. Esto se hace en función de la identidad del
usuario que accede al recurso compartido de archivos. Azure Files admite los siguientes
métodos de autenticación:

Active Directory Domain Services local (AD DS, o AD DS local): las cuentas de
almacenamiento de Azure pueden estar unidas a un dominio de Active Directory
Domain Services propiedad del cliente, al igual que un servidor de archivos de
Windows Server o un dispositivo NAS. Puede implementar un controlador de
dominio en el entorno local, en una VM de Azure o, incluso, como VM en otro
proveedor de nube. Azure Files es independiente de la ubicación donde se
hospeda el controlador de dominio. Una vez que una cuenta de almacenamiento
está unida a un dominio, el usuario final puede montar un recurso compartido de
archivos con la cuenta de usuario con la que inició sesión en su equipo. La
autenticación basada en AD usa el protocolo de autenticación Kerberos.
Microsoft Entra Domain Services: Microsoft Entra Domain Services proporciona
un controlador de dominio administrado por Microsoft que se puede usar para los
recursos de Azure. La unión a un dominio de la cuenta de almacenamiento a
Microsoft Entra Domain Services proporciona ventajas similares a la unión a un
dominio de dicha cuenta a una instancia de AD DS propiedad del cliente. Esta
opción de implementación es especialmente útil para escenarios de migración
mediante lift-and-shift de aplicaciones que requieren permisos basados en AD.
Dado que Microsoft Entra Domain Services proporciona autenticación basada en
AD, esta opción también usa el protocolo de autenticación Kerberos.
Microsoft Entra Kerberos para identidades híbridas: Microsoft Entra Kerberos
permite usar Microsoft Entra ID para autenticar identidades de usuario híbridas,
que son identidades de AD locales que se sincronizan con la nube. Esta
configuración usa Microsoft Entra ID para emitir tickets de Kerberos para acceder
al archivo compartido con el protocolo SMB. Esto significa que los usuarios finales
pueden acceder a los recursos compartidos de archivos de Azure a través de
Internet sin necesidad de una línea de visión a los controladores de dominio desde
las máquinas virtuales unidas de forma híbrida a Microsoft Entra y unidas a
Microsoft Entra.
Autenticación de Active Directory a través de SMB para clientes Linux:
Azure Files admite la autenticación basada en identidades a través de SMB para
 clientes Linux mediante el protocolo de autenticación Kerberos mediante AD DS o
Microsoft Entra Domain Services.
Clave de la cuenta de Azure Storage: los recursos compartidos de archivos de
Azure también se pueden montar con una clave de cuenta de almacenamiento de
Azure. Para montar un recurso compartido de archivos de esta forma, el nombre
de la cuenta de almacenamiento se usa como nombre de usuario y la clave de la
cuenta de almacenamiento se usa como contraseña. El uso de la clave de la cuenta
de almacenamiento para montar el recurso compartido de archivos de Azure es
realmente una operación de administrador, porque el recurso compartido de
archivos montado tendrá permisos completos para todos los archivos y todas las
carpetas del recurso compartido, aunque tengan ACL. Cuando se usa la clave de la
cuenta de almacenamiento para el montaje a través de SMB, se usa el protocolo
de autenticación NTLMv2. Si tiene previsto usar la clave de la cuenta de
almacenamiento para acceder a los recursos compartidos de archivos de Azure, se
recomienda usar puntos de conexión privados o puntos de conexión de servicio
como se describe en la sección Redes.

En el caso de los clientes que realizan la migración desde servidores de archivos locales
o que crean nuevos recursos compartidos de archivos en Azure Files destinados a
comportarse como servidores de archivos de Windows o dispositivos NAS, la unión a un
dominio de la cuenta de almacenamiento a una instancia AD DS propiedad del cliente
es la opción recomendada. Para obtener más información sobre la unión de dominio de
su cuenta de almacenamiento a un AD DS propiedad del cliente, consulte Información
general: autenticación de Active Directory Domain Services local en SMB para recursos
compartidos de archivos de Azure.

Redes
El montaje directo del recurso compartido de archivos de Azure a menudo requiere
cierta idea sobre la configuración de red, debido a las siguientes razones:

El puerto que usan los recursos compartidos de archivos SMB para la

comunicación, el puerto 445, se suele bloquear por parte de muchas
organizaciones y proveedores de servicios de Internet (ISP) para el tráfico saliente
(Internet).
Los recursos compartidos de archivos NFS se basan en la autenticación de nivel de
red y, por tanto, solo son accesibles mediante redes restringidas. El uso de un
recurso compartido de archivos NFS siempre requiere algún nivel de configuración
de redes.
Para configurar las redes, Azure Files proporciona un punto de conexión público
accesible a través de Internet e integración con características de red de Azure como
puntos de conexión de servicio, que ayudan a restringir el punto de conexión público a
redes virtuales específicas y puntos de conexión privados, que proporcionan a la cuenta
de almacenamiento una dirección IP privada desde un espacio de direcciones IP de red
virtual. Aunque no hay ningún cargo adicional por el uso de puntos de conexión
públicos o puntos de conexión de servicio, las tasas de procesamiento de datos
estándar se aplican a los puntos de conexión privados.

Desde un punto de vista práctico, esto significa que deberá tener en cuenta las
siguientes configuraciones de red:

Si el protocolo necesario es SMB y todo el acceso a través de SMB procede de

clientes de Azure, no se requiere ninguna configuración de conexión en red
especial.
Si el protocolo requerido es SMB y el acceso es desde clientes locales, entonces se
requiere una conexión VPN o ExpressRoute desde los locales a su red Azure, con
Azure Files expuestos en su red interna usando puntos de conexión privados.
Si el protocolo necesario es NFS, puede usar puntos de conexión de servicio o
puntos de conexión privados para restringir la red a redes virtuales específicas. Si
necesita una dirección IP estática o la carga de trabajo requiere alta disponibilidad,
use un punto de conexión privado.

Para más información sobre cómo configurar las redes para Azure Files, consulte
Consideraciones sobre redes de Azure Files.

Además de conectarse directamente al recurso compartido de archivos mediante el

punto de conexión público o mediante una conexión VPN o ExpressRoute con un punto
de conexión privado, SMB proporciona una estrategia de acceso de cliente adicional:
SMB a través de QUIC. SMB vía QUIC ofrece "VPN SMB" de configuración cero para el
acceso SMB a través del protocolo de transporte QUIC. Aunque Azure Files no admite
directamente SMB a través de QUIC, puede crear una caché ligera de los recursos
compartidos de archivos de Azure en una máquina virtual de Azure Edition de Windows
Server 2022 mediante Azure File Sync. Para más información sobre esta opción, consulte
SMB a través de QUIC con Azure File Sync.

Cifrado
Azure Files admite dos tipos diferentes de cifrado:

Cifrado en tránsito, que se relaciona con el cifrado usado al montar o acceder al

recurso compartido de archivos de Azure
 Cifrado en reposo, que se relaciona con la manera en que cifran los datos cuando
se almacenan en el disco

Cifrado en tránsito

） Importante

En esta sección se tratan los detalles del cifrado en tránsito para recursos
compartidos SMB. Para más información sobre el cifrado en tránsito con recursos
compartidos de NFS, consulte Seguridad y redes.

De forma predeterminada, todas las cuentas de Azure Storage tienen habilitado el

cifrado en tránsito. Esto significa que, al montar un recurso compartido de archivos a
través de SMB o acceder a él a través del protocolo de FileREST (por ejemplo, a través
de Azure Portal, la CLI o PowerShell, o los SDK de Azure), Azure Files solo permitirá la
conexión si se realiza con una versión posterior a SMB 3.x con cifrado o HTTPS. Los
clientes que no admiten SMB 3.x, o los clientes que admiten SMB 3.x pero no el cifrado
SMB, no podrán montar el recurso compartido de archivos de Azure si está habilitado el
cifrado en tránsito. Para obtener más información sobre qué sistemas operativos
admiten SMB 3.x con cifrado, consulte nuestra documentación para Windows, macOS y
Linux. Todas las versiones actuales de PowerShell, la CLI y los SDK admiten HTTPS.

Puede deshabilitar el cifrado en tránsito para una cuenta de almacenamiento de Azure.

Cuando el cifrado está deshabilitado, Azure Files también permite el uso de SMB 2.1 y
SMB 3.x sin cifrado, y de llamadas a la API de FileREST sin cifrar a través de HTTP. La
razón principal para deshabilitar el cifrado en tránsito es admitir una aplicación
heredada que debe ejecutarse en un sistema operativo anterior, como Windows Server
2008 R2 o una distribución de Linux anterior. Azure Files solo permite conexiones
SMB 2.1 dentro de la misma región de Azure del recurso compartido de archivos de
Azure. Un cliente SMB 2.1 fuera de la región de Azure del recurso compartido de
archivos de Azure (por ejemplo, en un entorno local o en una región de Azure diferente)
no podrá acceder al recurso compartido de archivos.

Se recomienda encarecidamente asegurarse de que está habilitado el cifrado de los

datos en tránsito.

Para obtener más información sobre el cifrado en tránsito, consulte Requerir

transferencia segura en Azure Storage.

Cifrado en reposo
Todos los datos almacenados en Azure Files se cifran en reposo mediante el cifrado de
servicio de almacenamiento (SSE) de Azure. El cifrado del servicio de almacenamiento
funciona de forma similar a BitLocker en Windows: los datos se cifran bajo el nivel del
sistema de archivos. Dado que los datos se cifran bajo el sistema de archivos del recurso
compartido de archivos de Azure, ya que se codifican en el disco, no es necesario tener
acceso a la clave subyacente en el cliente para leer o escribir en dicho recurso
compartido. El cifrado en reposo se aplica a los protocolos SMB y NFS.

De manera predeterminada, los datos almacenados en Azure Files se cifran con claves
administradas por Microsoft. Con las claves administradas por Microsoft, Microsoft
mantiene las claves para cifrar o descifrar los datos y es responsable de rotarlas de
forma periódica. También puede elegir administrar sus propias claves, lo que le permitirá
controlar el proceso de rotación. Si decide cifrar los recursos compartidos de archivos
con claves administradas por el cliente, Azure Files está autorizado para tener acceso a
las claves con el fin de satisfacer las solicitudes de lectura y escritura de los clientes. Con
las claves administradas por el cliente, puede revocar esta autorización en cualquier
momento, pero esto significa que el recurso compartido de archivos de Azure ya no
será accesible a través de SMB o la API FileREST.

Azure Files usa el mismo esquema de cifrado que los otros servicios de almacenamiento
de Azure, como Azure Blob Storage. Para aprender más sobre el cifrado del servicio de
almacenamiento (SSE) de Azure, consulte Cifrado de Azure Storage para datos en
reposo.

Protección de los datos

Azure Files tiene un enfoque de varias capas para garantizar la copia de seguridad de
los datos, su recuperación y su protección contra amenazas de seguridad. Consulte
Introducción a la protección de datos de Azure Files.

Eliminación temporal
La eliminación temporal es una configuración de nivel de cuenta de almacenamiento de
recursos compartidos de archivos de SMB que permite recuperar el recurso compartido
de archivos cuando se elimina accidentalmente. Cuando se elimina un recurso
compartido de archivos, pasa a un estado de eliminación temporal, en lugar de borrarse
de forma permanente. Se puede configurar el tiempo durante el que los recursos
compartidos eliminados de forma temporal se pueden recuperar antes de que se
eliminen permanentemente y durante este período de retención el recurso compartido
se puede recuperar en cualquier momento.
La eliminación temporal está habilitada de manera predeterminada para las nuevas
cuentas de almacenamiento desde enero de 2021 y se recomienda dejarla activada para
la mayoría de los recursos compartidos de archivos SMB. Si tiene un flujo de trabajo en
el que la eliminación de recursos compartidos es común y se espera, puede que decida
tener un período de retención corto o no tener habilitada la eliminación temporal. La
eliminación temporal no funciona con los recursos compartidos de NFS, incluso si está
habilitada para la cuenta de almacenamiento.

Para obtener más información acerca de la eliminación temporal, consulte Evitar la

eliminación accidental de datos.

Copia de seguridad
Puede realizar una copia de seguridad del recurso compartido de archivos de Azure a
través de instantáneas de recurso compartido, que son copias de solo lectura de un
momento dado del recurso compartido. Las instantáneas son incrementales, lo que
significa que solo contienen los datos que han cambiado desde la instantánea anterior.
Puede tener hasta 200 instantáneas por recurso compartido de archivos y conservarlas
durante un máximo de diez años. Puede realizar instantáneas manualmente en
Azure Portal, a través de PowerShell o en la interfaz de la línea de comandos (CLI), o
bien puede usar Azure Backup.

Azure Backup para recursos compartidos de archivos de Azure controla la programación

y retención de instantáneas. Sus capacidades de abuelo-padre-hijo (GFS) significan que
puede tomar instantáneas diarias, semanales, mensuales y anuales, cada una con su
propio período de retención distinto. Azure Backup también organiza la habilitación de
la eliminación temporal y toma un bloqueo de eliminación en una cuenta de
almacenamiento en cuanto se configura un recurso compartido de archivos en ella para
la copia de seguridad. Por último, Azure Backup proporciona ciertas capacidades clave
de supervisión y alertas que permiten a los clientes tener una vista consolidada de su
copia de seguridad.

Puede realizar restauraciones de nivel de elemento y de nivel de recurso compartido en

Azure Portal mediante Azure Backup. Lo único que debe hacer es elegir el punto de
restauración (una instantánea concreta), el archivo o directorio en cuestión si es
pertinente y, a continuación, la ubicación (original o alternativa) en la que quiere realizar
la restauración. El servicio de copia de seguridad controla la copia de los datos de
instantáneas y muestra el progreso de la restauración en el portal.

Protección de Azure Files con Microsoft Defender para

Storage
Microsoft Defender para Storage es una capa de inteligencia de seguridad nativa de
Azure que detecta posibles amenazas a sus cuentas de almacenamiento. Proporciona
una seguridad completa mediante el análisis de la telemetría del plano de datos y el
plano de control generados por Azure Files. Usa capacidades avanzadas de detección de
amenazas con tecnología de Inteligencia contra amenazas Microsoft para
proporcionar alertas de seguridad contextuales, incluidos los pasos para mitigar las
amenazas detectadas y evitar futuros ataques.

Defender para Storage analiza continuamente el flujo de telemetría generado por Azure
Files. Cuando se detectan actividades potencialmente malintencionadas, se generan
alertas de seguridad. Estas alertas se muestran en Microsoft Defender for Cloud junto
con los detalles de la actividad sospechosa, los pasos de investigación, las acciones de
corrección y las recomendaciones de seguridad.

Defender para Storage detecta malware conocido, como ransomware, virus, spyware y
otro malware cargado en una cuenta de almacenamiento basada en un hash de archivo
completo (solo se admite para la API de REST). Esto ayuda a evitar que el malware entre
en la organización y se propague a más usuarios y recursos. Consulte Descripción de las
diferencias entre el examen de malware y el análisis de reputación de hash.

Defender para Storage no tiene acceso a los datos de la cuenta de almacenamiento y no

afecta a su rendimiento. Puede habilitar Microsoft Defender para Storage en el nivel de
suscripción (recomendado) o de recursos.

Niveles de almacenamiento
Azure Files ofrece cuatro niveles diferentes de almacenamiento: Premium, Optimizado
para transacciones, Frecuente y Esporádico, con el fin de que pueda adaptar sus
recursos compartidos a los requisitos de rendimiento y precio de su escenario:

Premium: Los recursos compartidos de archivos Premium tienen el respaldo de

discos SSD y proporcionan alto rendimiento y baja latencia de forma consistente
en menos de 10 milisegundos en la mayoría de las operaciones de E/S para las
cargas de trabajo con mayor uso de E/S. Los recursos compartidos de archivos
Premium son adecuados para una amplia variedad de cargas de trabajo como
bases de datos, hospedaje de sitios web y entornos de desarrollo. Los recursos
compartidos de archivos Premium se pueden usar con los protocolos Bloque de
mensajes del servidor (SMB) y Network File System (NFS).
Optimizado para transacciones: Los recursos compartidos de archivos con el nivel
Optimizado para transacciones permiten cargas de trabajo con muchas
transacciones que no necesitan la latencia que ofrecen los recursos compartidos
de archivos Premium. Los recursos compartidos de archivos optimizados para
 transacciones se ofrecen en el hardware de almacenamiento estándar respaldado
por unidades de disco duro (HDD). A los optimizados para transacciones se les ha
llamado históricamente "estándar"; sin embargo, realmente es el tipo de soporte
físico de almacenamiento, en lugar del propio nivel (tanto el acceso frecuente
como el esporádico también son niveles "estándar", ya que se encuentran en el
hardware de almacenamiento estándar).
Acceso frecuente: Los recursos compartidos de nivel de acceso frecuente ofrecen
almacenamiento optimizado para escenarios de uso compartido de archivos de
uso general, como los recursos compartidos de los equipos. Los recursos
compartidos de archivos de nivel de acceso frecuente se ofrecen en el hardware de
almacenamiento estándar respaldado por unidades de disco duro.
Acceso esporádico: Los recursos compartidos de archivos de acceso esporádico
ofrecen un almacenamiento económico optimizado para escenarios de
almacenamiento de archivo en línea. Los recursos compartidos de archivos de nivel
de acceso esporádico se ofrecen en el hardware de almacenamiento estándar
respaldado por unidades de disco duro.

Los recursos compartidos de archivos Premium se implementan en la cuenta de

almacenamiento de FileStorage y solo están disponibles en un modelo de facturación
aprovisionado. Para más información sobre el modelo de facturación aprovisionado
para recursos compartidos de archivos Premium, consulte Planeamiento de una
implementación de Azure Files. Los recursos compartidos de archivos estándar, que
incluyen los optimizados para las transacciones, los de nivel de acceso frecuente y los de
nivel de acceso esporádico, se implementan en la cuenta de almacenamiento de uso
general, versión 2 (GPv2) y están disponibles en un modelo de pago por uso.

Al seleccionar una capa de almacenamiento para la carga de trabajo, tenga en cuenta

los requisitos de rendimiento y uso. Si la carga de trabajo requiere una latencia de un
solo dígito o si usa medios de almacenamiento SSD en un entorno local, es probable
que el nivel Premium sea el más adecuado. Si no es muy importante que la latencia sea
baja, por ejemplo, en el caso de recursos compartidos de equipo montados localmente
desde Azure o almacenados en la caché local mediante Azure File Sync, desde el punto
de vista del costo es posible que sea más adecuado usar el almacenamiento estándar.

Una vez que se haya creado un recurso compartido de archivos en una cuenta de
almacenamiento, no se podrá mover a niveles exclusivos de diferentes tipos de cuenta
de almacenamiento. Por ejemplo, para cambiar un recurso compartido de archivos
optimizado para transacciones al nivel Premium, es preciso crear un recurso compartido
de archivos en una cuenta de almacenamiento de FileStorage y copiar los datos desde el
recurso compartido original a un nuevo recurso compartido de archivos en la cuenta de
FileStorage. Se recomienda usar AzCopy para copiar datos entre recursos compartidos
de archivos de Azure, pero también se pueden usar herramientas como robocopy en
Windows o rsync en macOS y Linux.

Para más información, consulte Facturación de Azure Files.

Limitaciones
Actualmente, los recursos compartidos de archivos estándar con recursos compartidos
de archivos grandes habilitados (hasta una capacidad de 100 TiB) tienen ciertas
limitaciones.

Solo se admiten cuentas de almacenamiento con redundancia local (LRS) y

almacenamiento con redundancia de zona (ZRS).
Una vez que habilite recursos compartidos de archivos grandes en una cuenta de
almacenamiento, no podrá convertir la cuenta de almacenamiento para usar ni el
almacenamiento con redundancia geográfica (GRS) ni el almacenamiento con
redundancia de zona geográfica (GZRS).
Una vez que habilite los recursos compartidos de archivos de gran tamaño, no
podrá deshabilitarlos.

Si desea usar GRS o GZRS con recursos compartidos de archivos de Azure SMB
estándar, consulte Redundancia geográfica de Azure Files para recursos compartidos de
archivos grandes (versión preliminar).

Redundancia
Para proteger los datos de los recursos compartidos de archivos de Azure contra la
pérdida o daños de los datos, Azure Files almacena varias copias de cada archivo a
medida que se escriben. En función de sus requisitos, podrá seleccionar diferentes
grados de redundancia. Actualmente, Azure Files admite las siguientes opciones de
redundancia de datos:

Almacenamiento con redundancia local (LRS) : con LRS, todos los archivos se
almacenan tres veces dentro de un clúster de almacenamiento de Azure. Esto
protege contra la pérdida de datos debido a errores de hardware, como una
unidad de disco incorrecta. No obstante, si se produjera un desastre, como un
incendio o una inundación en el centro de datos, es posible que todas las réplicas
de las cuentas de almacenamiento que usen LRS se pierdan o no se puedan
recuperar.
Almacenamiento con redundancia de zona (ZRS): con ZRS, se almacenan tres
copias de cada archivo. Sin embargo, estas copias están aisladas físicamente en
 tres clústeres de almacenamiento distintos en diferentes zonas de disponibilidad de
Azure. Las zonas de disponibilidad son ubicaciones físicas exclusivas dentro de una
región de Azure. Cada zona consta de uno o varios centros de datos equipados
con alimentación, refrigeración y redes independientes. No se acepta la escritura
en el almacenamiento hasta que se realice la escritura en los clústeres de
almacenamiento en las tres zonas de disponibilidad.
Almacenamiento con redundancia geográfica (GRS): con GRS, hay dos regiones,
una primaria y una secundaria. Los archivos se almacenan tres veces dentro de un
clúster de almacenamiento de Azure en la región primaria. Las escrituras se
replican de forma asincrónica en una región secundaria definida por Microsoft.
GRS proporciona seis copias de los datos distribuidas entre dos regiones de Azure.
En caso de un desastre importante, como la pérdida permanente de una región de
Azure debido a una catástrofe natural o a otro evento similar, Microsoft realizará
una conmutación por error. En este caso, la base de datos secundaria se convertiría
en la principal, atendiendo todas las operaciones. Dado que la replicación entre las
regiones principal y secundaria es asincrónica, en caso de que se produzca un
desastre importante, se perderán los datos que todavía no se hayan replicado en la
región secundaria. También puede realizar una conmutación por error manual de
una cuenta de almacenamiento con redundancia geográfica.
Almacenamiento con redundancia de zona geográfica (GZRS): GZRS es como
ZRS, pero con redundancia geográfica. Con GZRS, los archivos se almacenan tres
veces en tres clústeres de almacenamiento distintos en la región primaria. Todas
las escrituras se replican de forma asincrónica en una región secundaria definida
por Microsoft. El proceso de conmutación por error de GZRS funciona igual que en
GRS.

Los recursos compartidos de archivos estándar de Azure de hasta 5 TiB admiten los
cuatro tipos de redundancia. Los recursos compartidos de archivos estándar de más
de 5 TiB solo admiten LRS y ZRS. Los recursos compartidos de archivos premium de
Azure solo admiten LRS y ZRS.

Las cuentas de almacenamiento de uso general versión 2 (GPv2) proporcionan otras dos
opciones de redundancia que Azure Files no admite: almacenamiento con redundancia
geográfica con acceso de lectura (RA-GRS) y almacenamiento con redundancia de zona
geográfica con acceso de lectura (RA-GZRS). Puede aprovisionar recursos compartidos
de archivos de Azure en cuentas de almacenamiento con estas opciones establecidas;
sin embargo, Azure Files no admite la lectura desde la región secundaria. Los recursos
compartidos de archivos de Azure implementados en cuentas de almacenamiento con
RA-GRS o RA-GZRS se facturan como GRS o GZRS, respectivamente.

Para obtener más información sobre la redundancia, consulte Redundancia de datos de

Azure Files.
Disponibilidad de ZRS estándar
ZRS para cuentas de almacenamiento estándar de uso general v2 está disponible para
un subconjunto de regiones de Azure.

Disponibilidad de ZRS premium

ZRS para recursos compartidos de archivos premium está disponible para un
subconjunto de regiones de Azure.

Disponibilidad de GZRS estándar

GZRS está disponible para un subconjunto de regiones de Azure.

Recuperación ante desastres y conmutación

por error
En el caso de una interrupción de servicio regional no planeada, debe tener un plan de
recuperación ante desastres (DR) para los recursos compartidos de archivos de Azure.
Para comprender los conceptos y los procesos implicados en la conmutación por error
de la cuenta de almacenamiento y recuperación ante desastres, consulte Recuperación
ante desastres y conmutación por error para Azure Files.

Migración
En muchos casos, no podrá establecer un nuevo recurso compartido de archivos para su
organización, sino que se migrará uno existente de un servidor de archivos local o un
dispositivo NAS a Azure Files. La elección de la herramienta y estrategia de migración
adecuadas para el escenario es importante para el éxito de la migración.

En el artículo de introducción a la migración se describen brevemente los aspectos

básicos y se incluye una tabla que le conduce a guías de migración que probablemente
cubran su escenario.

Pasos siguientes
Planeamiento de una implementación de Azure File Sync
Implementación de Azure Files
Implementación de Azure File Sync
Consulte el artículo de introducción a la migración para encontrar la guía de
migración para su escenario.
Recursos compartidos de archivos SMB
en Azure Files
Artículo • 29/09/2023

Azure Files ofrece dos protocolos estándar del sector para el montaje de recursos
compartidos de archivos de Azure: el protocolo Bloque de mensajes del servidor (SMB)
y el protocolo Network File System (NFS) . Azure Files le permite seleccionar el
protocolo del sistema de archivos más adecuado para su carga de trabajo. Los recursos
compartidos de archivos de Azure no admiten el acceso a un recurso compartido de
archivos de Azure individual con los protocolos SMB y NFS, aunque se pueden crear
recursos compartidos de archivos SMB y NFS dentro de la misma cuenta de
almacenamiento. En general, Azure Files ofrece recursos compartidos de archivos de
nivel empresarial que se pueden escalar verticalmente para satisfacer sus necesidades
de almacenamiento y a los que pueden acceder simultáneamente miles de clientes.

En este artículo se tratan los recursos compartidos de archivos SMB de Azure. Para
obtener información sobre los recursos compartidos de archivos NFS de Azure, consulte
el artículo sobre Recursos compartidos de archivos NFS en Azure Files.

Escenarios frecuentes
Los recursos compartidos de archivos SMB se usan para diversas aplicaciones, incluidos
recursos compartidos de archivos de usuario final y recursos compartidos de archivos
que respaldan las bases de datos y las aplicaciones. Los recursos compartidos de
archivos SMB se suelen usar en los escenarios siguientes:

Recursos compartidos de archivos de usuario final, como recursos compartidos de

equipo, directorios particulares, etc.
Almacenamiento auxiliar para aplicaciones basadas en Windows, como bases de
datos de SQL Server o aplicaciones de línea de negocio escritas para las API del
sistema de archivos local Win32 o .NET.
Desarrollo de aplicaciones y servicios nuevos, sobre todo si esa aplicación o
servicio tiene como requisito una E/S aleatoria y almacenamiento jerárquico.

Características
Azure Files admite las características principales de SMB y Azure que se requieren para
las implementaciones de producción de recursos compartidos de archivos SMB:
 Listas de control de acceso discrecional (DACL) y unión a un dominio de AD.
Copia de seguridad sin servidor integrada con Azure Backup.
Aislamiento de red con puntos de conexión privados de Azure.
Alto rendimiento de red con SMB multicanal (solo recursos compartidos de
archivos premium).
Cifrado de canal SMB que incluye AES-256-GCM, AES-128-GCM y AES-128-CCM.
Compatibilidad con versiones anteriores mediante instantáneas de recurso
compartido integradas de VSS.
Eliminación temporal automática en los recursos compartidos de archivos de Azure
para evitar eliminaciones accidentales.
Opcionalmente, recursos compartidos de archivos accesibles desde Internet con
SMB 3.0 y versiones posteriores seguro para Internet.

Los recursos compartidos de archivos SMB pueden montarse directamente en el

entorno local o también se pueden almacenar en caché en el entorno local con
Azure File Sync.

Seguridad
Todos los datos almacenados en Azure Files se cifran en reposo mediante el cifrado de
servicio de almacenamiento (SSE) de Azure. El cifrado del servicio de almacenamiento
funciona de forma similar a BitLocker en Windows: los datos se cifran bajo el nivel del
sistema de archivos. Dado que los datos se cifran bajo el sistema de archivos del recurso
compartido de archivos de Azure, ya que se codifican en el disco, no es necesario tener
acceso a la clave subyacente en el cliente para leer o escribir en dicho recurso
compartido. El cifrado en reposo se aplica a los protocolos SMB y NFS.

De forma predeterminada, todas las cuentas de Azure Storage tienen habilitado el

cifrado en tránsito. Esto significa que, al montar un recurso compartido de archivos a
través de SMB (o acceder a él a través del protocolo FileREST), Azure Files solo permitirá
la conexión si se realiza con una versión SMB 3.x con cifrado o HTTPS. Los clientes que
no admiten SMB 3.x con cifrado del canal SMB no podrán montar el recurso compartido
de archivos de Azure si está habilitado el cifrado en tránsito.

Azure Files admite AES-256-GCM con SMB 3.1.1 cuando se usa con
Windows Server 2022 o Windows 11. SMB 3.1.1 también admite AES-128-GCM y
SMB 3.0 admite AES-128-CCM. AES-128-GCM se negocia de forma predeterminada en
Windows 10, versión 21H1, por motivos de rendimiento.

Puede deshabilitar el cifrado en tránsito para una cuenta de almacenamiento de Azure.

Cuando el cifrado está deshabilitado, Azure Files también permite el uso de SMB 2.1 y
SMB 3.x sin cifrado. La razón principal para deshabilitar el cifrado en tránsito es admitir
una aplicación heredada que debe ejecutarse en un sistema operativo anterior, como
Windows Server 2008 R2 o una distribución de Linux anterior. Azure Files solo permite
conexiones SMB 2.1 dentro de la misma región de Azure del recurso compartido de
archivos de Azure. Un cliente SMB 2.1 fuera de la región de Azure del recurso
compartido de archivos de Azure (por ejemplo, en un entorno local o en una región de
Azure diferente) no podrá acceder al recurso compartido de archivos.

Configuración del protocolo SMB

Azure Files ofrece varias configuraciones que afectan al comportamiento, rendimiento y
seguridad del protocolo SMB. Se configuran para todos los recursos compartidos de
archivos de Azure dentro de una cuenta de almacenamiento.

SMB multicanal
SMB multicanal permite que un cliente SMB 3.x establezca varias conexiones de red a un
recurso compartido de archivos SMB. Azure Files admite SMB multicanal en recursos
compartidos de archivos prémium (recursos compartidos de archivos en el tipo de
cuenta de almacenamiento FileStorage). No hay ningún costo adicional por habilitar
SMB multicanal en Azure Files. SMB multicanal está deshabilitado de forma
predeterminada.

Portal

Para ver el estado de SMB multicanal, vaya a la cuenta de almacenamiento que

contiene los recursos compartidos de archivos prémium y seleccione Recursos
compartidos de archivos en el encabezado Almacenamiento de datos de la tabla
de contenido de la cuenta de almacenamiento. El estado de SMB multicanal se
puede ver en la sección Configuración del recurso compartido de archivos.
Para habilitar o deshabilitar SMB multicanal, seleccione el estado actual (Habilitado
o Deshabilitado en función del estado). El cuadro de diálogo resultante
proporciona un botón de alternancia para habilitar o deshabilitar SMB multicanal.
Seleccione el estado deseado y seleccione Guardar.
Configuración de seguridad de SMB
Azure Files expone una configuración que le permite alternar el protocolo SMB para que
sea más compatible o más seguro, en función de los requisitos de la organización. De
manera predeterminada, Azure Files está configurado para ser compatible al máximo,
por lo que tenga en cuenta que restringir esta configuración puede hacer que algunos
clientes no puedan conectarse.

Azure Files expone la siguiente configuración:

Versiones de SMB: qué versiones de SMB se permiten. Las versiones admitidas del
protocolo son SMB 3.1.1, SMB 3.0 y SMB 2.1. De forma predeterminada, se
admiten todas las versiones de SMB, salvo en el caso de SMB 2.1 si está habilitada
la opción para requerir la transferencia segura, ya que SMB 2.1 no admite el
cifrado en tránsito.
Métodos de autenticación: qué métodos de autenticación SMB se permiten. Los
métodos de autenticación admitidos son NTLMv2 (solo clave de cuenta de
 almacenamiento) y Kerberos. De forma predeterminada, se admiten todos los
métodos de autenticación. La eliminación de NTLMv2 impide el uso de la clave de
la cuenta de almacenamiento para montar el recurso compartido de archivos de
Azure. Azure Files no admite el uso de la autenticación NTLM para las credenciales
de dominio.
Cifrado de vales Kerberos: qué algoritmos de cifrado se permiten. Los algoritmos
de cifrado admitidos son AES-256 (recomendado) y RC4-HMAC.
Cifrado del canal SMB: qué algoritmos de cifrado del canal SMB se permiten. Los
algoritmos de cifrado admitidos son AES-256-GCM, AES-128-GCM y AES-128-
CCM.

Puede ver y cambiar la configuración de seguridad de SMB mediante Azure Portal,

PowerShell o la CLI. Seleccione la pestaña deseada para ver los pasos sobre cómo
obtener y establecer la configuración de seguridad de SMB.

Portal

Para ver o cambiar la configuración de seguridad de SMB mediante Azure Portal,

siga estos pasos:

1. Busque Cuentas de almacenamiento y seleccione la cuenta de

almacenamiento cuya configuración de seguridad quiere ver.

2. Seleccione Almacenamiento de datos>Recursos compartido de archivos.

3. En Configuración del recurso compartido de archivos, seleccione el valor

asociado a Seguridad. Si no ha modificado la configuración de seguridad,
tiene como valor predeterminado Compatibilidad máxima.

4. En Perfil, seleccione Compatibilidad máxima, Maximum security (Seguridad

máxima) o Personalizado. Si selecciona Personalizado, podrá crear un perfil
personalizado para las versiones del protocolo SMB, el cifrado de canales
SMB, los mecanismos de autenticación y el cifrado de vales de Kerberos.
 Después de especificar la configuración de seguridad deseada, seleccione Guardar.

Limitaciones
Los recursos compartidos de archivos SMB en Azure Files admiten un subconjunto de
características compatibles con el protocolo SMB y el sistema de archivos NTFS. Aunque
la mayoría de los casos de uso y de las aplicaciones no requieren estas características, es
posible que algunas aplicaciones no funcionen correctamente con Azure Files si
dependen de características no admitidas. No se admiten las características siguientes:

SMB directo
Concesión de directorio SMB
VSS para recursos compartidos de archivos SMB (esto permite a los proveedores
de VSS vaciar sus datos en el recurso compartido de archivos SMB antes de tomar
una instantánea).
Flujos de datos alternativos
Atributos ampliados
Identificadores de objeto
Vínculos físicos
Enlaces simbólicos
Puntos de repetición de análisis
Archivos dispersos
Nombres de archivos cortos (alias 8.3)
Compresión

Disponibilidad regional
Los recursos compartidos de archivos SMB de Azure están disponibles en todas las
regiones de Azure, incluidas todas las públicas y soberanas. Los recursos compartidos
de archivos SMB premium están disponibles en un subconjunto de regiones .

Pasos siguientes
Planeamiento de una implementación de Azure Files
Creación de un recurso compartido de archivos de Azure
Montaje de recursos compartidos de archivos SMB en su sistema operativo
preferido:
Montaje de recursos compartidos de archivos SMB en Windows
Montaje de recursos compartidos de archivos SMB en Linux
Montaje de recursos compartidos de archivos SMB en macOS
Recursos compartidos de archivos NFS
en Azure Files
Artículo • 16/10/2023

Azure Files ofrece dos protocolos de sistema de archivos estándar del sector para
montar recursos compartidos de archivos de Azure: el protocolo Bloque de mensajes
del servidor (SMB) y el protocolo Network File System (NFS) , permitiéndole elegir el
protocolo que se ajuste más a su carga de trabajo. Los recursos compartidos de archivos
de Azure no admiten el acceso a un recurso compartido de archivos de Azure individual
con los protocolos SMB y NFS, aunque se pueden crear recursos compartidos de
archivos SMB y NFS dentro de la misma cuenta de almacenamiento de FileStorage.
Azure Files ofrece recursos compartidos de archivos de nivel empresarial que se pueden
escalar verticalmente para satisfacer sus necesidades de almacenamiento y a los que
pueden acceder simultáneamente miles de clientes.

En este artículo se describen los recursos compartidos de archivos NFS de Azure. Para
obtener información acerca de los recursos compartidos de archivos SMB de Azure,
consulte Recursos compartidos de archivos SMB en Azure Files.

） Importante

Los recursos compartidos de archivos NFS de Azure no se admiten para Windows.

Antes de usar recursos compartidos de archivos de NFS de Azure en producción,
consulte Solución de problemas de recursos compartidos de archivos de NFS de
Azure para ver una lista de problemas conocidos. No se admiten las listas de
control de acceso (ACL) de NFS.

Escenarios frecuentes
Los recursos compartidos de archivos NFS se suelen usar en los escenarios siguientes:

Almacenamiento de respaldo para aplicaciones basadas en Linux o UNIX, como

aplicaciones de línea de negocio escritas con API del sistema de archivos Linux o
POSIX (incluso aunque no requieran compatibilidad con POSIX).
Cargas de trabajo que requieren recursos compartidos de archivos compatibles
con POSIX, distinción entre mayúsculas y minúsculas o permisos de estilo Unix
(UID/GID).
Desarrollo de aplicaciones y servicios nuevos, sobre todo si esa aplicación o
servicio tiene como requisito una E/S aleatoria y almacenamiento jerárquico.
Características
Sistema de archivos totalmente compatible con POSIX.
Compatibilidad con vínculos físicos.
Compatibilidad con vínculos simbólicos.
Actualmente, los recursos compartidos de archivos NFS solo admiten la mayoría
de las características de la especificación del protocolo 4.1 . No se admiten
algunas características, como delegaciones y devoluciones de llamada de todo
tipo, listas de control de acceso, la autenticación Kerberos y el cifrado en tránsito.

７ Nota

Actualmente no se admite la creación de un vínculo físico a partir de un vínculo

simbólico existente.

Seguridad y redes
Todos los datos almacenados en Azure Files se cifran en reposo mediante el cifrado de
servicio de almacenamiento (SSE) de Azure. El cifrado del servicio de almacenamiento
funciona de forma similar a BitLocker en Windows: los datos se cifran bajo el nivel del
sistema de archivos. Dado que los datos se cifran bajo el sistema de archivos del recurso
compartido de archivos de Azure, ya que se codifican en el disco, no es necesario tener
acceso a la clave subyacente en el cliente para leer o escribir en dicho recurso
compartido. El cifrado en reposo se aplica a los protocolos SMB y NFS.

En el caso del cifrado en tránsito, Azure proporciona una capa de cifrado para todos los
datos en tránsito entre los centros de datos de Azure mediante MACSec . Gracias a
esto, se produce el cifrado cuando se transfieren datos entre centros de datos de Azure.

A diferencia de Azure Files cuando usa el protocolo SMB, los recursos compartidos de
archivos que utilizan el protocolo NFS no ofrecen autenticación basada en usuario. La
autenticación de los recursos compartidos NFS se basa en las reglas de seguridad de
red configuradas. Debido a esto, para garantizar que solo se establecen conexiones
seguras a su recurso compartido NFS, debe configurar un punto de conexión privado o
un punto de conexión de servicio para su cuenta de almacenamiento.

Un punto de conexión privado (también denominado vínculo privado) proporciona a la

cuenta de almacenamiento una dirección IP privada estática dentro de la red virtual, lo
que impide que las interrupciones de conectividad cambien de dirección IP dinámica. El
tráfico a la cuenta de almacenamiento se mantiene dentro de las redes virtuales
interconectadas, incluidas las de otras regiones y las locales. Se aplican las tarifas de
procesamiento de datos estándar.

Si no necesita una dirección IP estática, puede habilitar un punto de conexión de

servicio para Azure Files dentro de la red virtual. Un punto de conexión de servicio
configura las cuentas de almacenamiento para permitir el acceso solo desde subredes
específicas. Las subredes permitidas pueden pertenecer a una red virtual de la misma
suscripción o una suscripción diferente, incluidas las que pertenecen a un inquilino de
Microsoft Entra diferente. No se realiza ningún cargo adicional por el uso de puntos de
conexión de servicio.

Si desea acceder a recursos compartidos desde un entorno local, debe configurar una
VPN o ExpressRoute, además de un punto de conexión privado. Las solicitudes que no
tengan los siguientes orígenes se rechazarán:

Un punto de conexión privado

Azure VPN Gateway
Una VPN de punto a sitio (P2S)
De sitio a sitio
ExpressRoute
Un punto de conexión público restringido

Para más información sobre las opciones de red disponibles, consulte Consideraciones
de redes para Azure Files.

Compatibilidad con las características de

Azure Storage
En la tabla siguiente, se muestra el nivel actual de compatibilidad con características de
Azure Storage en las cuentas que tienen habilitada la característica NFS 4.1.

El estado de los elementos que aparecen en esta tabla puede cambiar con el tiempo a
medida que se siga ampliando la compatibilidad.

Característica de Azure Storage Compatible con recursos

compartidos NFS

API REST del plano de administración de archivos ✔️

API REST del plano de datos de archivos ⛔

Cifrado en reposo ✔️

Cifrado en tránsito ⛔
Característica de Azure Storage Compatible con recursos
compartidos NFS

Tipos de redundancia LRS o ZRS ✔️

Conversión de LRS a ZRS ⛔

Puntos de conexión de zona de Azure DNS (versión preliminar) ✔️

Puntos de conexión privados ✔️

Montajes de subdirectorios ✔️

Concesión de acceso de red a redes virtuales de Azure ✔️

específicas

Concesión de acceso a determinadas direcciones IP ⛔

Nivel Premium ✔️

Niveles estándar (nivel de acceso frecuente, nivel de acceso ⛔

esporádico y transacción optimizados)

Permisos POSIX ✔️

Uso de root_squash ✔️

Acceder a los mismos datos desde el cliente Windows y Linux ⛔

Habilitación basada en identidad ⛔

Eliminación temporal de recursos compartidos de archivos de ⛔

Azure

Azure File Sync ⛔

Copia de seguridad de un recurso compartido de archivos de ⛔

Azure

Instantáneas de recursos compartidos de archivos de Azure ✔️(versión preliminar)

Tipos de redundancia GRS o GZRS ⛔

AzCopy ⛔

Explorador de Azure Storage ⛔

Compatibilidad con más de 16 grupos ⛔

Disponibilidad regional
Los recursos compartidos de archivos NFS de Azure se admiten en las mismas regiones
que admiten el almacenamiento de archivos Prémium.

Para obtener la lista más actualizada, consulte la entrada Premium Files Storage en la
página Productos de Azure disponibles por región .

Rendimiento
Los recursos compartidos de archivos de Azure NFS solo se ofrecen en recursos
compartidos de archivos premium, que almacenan datos en unidades de estado sólido
(SSD). Las IOPS y el rendimiento de los recursos compartidos de NFS se escalan con la
capacidad aprovisionada. Consulte la sección del modelo aprovisionado del artículo
Descripción de la facturación para comprender las fórmulas de IOPS, ráfagas de E/S y
rendimiento. Las latencias de E/S promedio son de un número bajo de milisegundos
inferior a 10 para los tamaños de E/S pequeños, mientras que las latencias de metadatos
promedio son de un número alto de milisegundos inferior a 10. Las operaciones de
metadatos de carga elevada, como la descompresión y las cargas de trabajo como
WordPress, pueden tener latencias adicionales debido al gran número de operaciones
de apertura y cierre.

７ Nota

Puede usar la opción de montaje de Linux nconnect para mejorar el rendimiento de

los recursos compartidos de archivos de Azure NFS a escala. Para más información,
consulte Mejora del rendimiento del recurso compartido de archivos NFS de
Azure.

Cargas de trabajo

） Importante

Antes de usar recursos compartidos de archivos de NFS de Azure en producción,

consulte Solución de problemas de recursos compartidos de archivos de NFS de
Azure para ver una lista de problemas conocidos.

NFS se ha validado para funcionar bien con cargas de trabajo como el nivel de
aplicación de SAP, copias de seguridad de bases de datos, replicación de bases de
datos, colas de mensajería, directorios particulares para servidores de archivos de uso
general y repositorios de contenido para cargas de trabajo de aplicaciones.
Pasos siguientes
Creación de un recurso compartido de archivos NFS
Comparación del acceso a Azure Files, Blob Storage y Azure NetApp Files con NFS
Consideraciones de redes para Azure
Files
Artículo • 01/06/2023

Puede acceder a los recursos compartidos de archivos de Azure mediante el punto de

conexión público accesible desde Internet, mediante uno o varios puntos de conexión
privados en las redes o almacenando en caché el recurso compartido de archivos de
Azure en el entorno local con Azure File Sync (solo recursos compartidos de archivos
SMB). Este artículo se centra en cómo configurar Azure Files para el acceso directo
mediante puntos de conexión públicos o privados. Para obtener información sobre
cómo almacenar en caché el recurso compartido de archivos de Azure en el entorno
local con Azure File Sync, consulte ¿Qué es Azure File Sync?

Se recomienda leer Planeamiento de una implementación de Azure Files antes de pasar

a esta guía conceptual.

A menudo, el acceso directo al recurso compartido de archivos de Azure requiere una

reflexión adicional con respecto a las redes:

Los recursos compartidos de archivos SMB se comunican mediante el puerto 445,

que muchas organizaciones y proveedores de servicios de Internet (ISP) bloquean
para el tráfico saliente (Internet). Esta práctica procede de las instrucciones de
seguridad heredadas sobre las versiones en desuso y no seguras para Internet del
protocolo SMB. Aunque SMB 3.x es un protocolo seguro para Internet, es posible
que no se puedan cambiar las directivas de la organización o del ISP. Por lo tanto,
el montaje de un recurso compartido de archivos SMB a menudo requiere una
configuración de redes adicional para su uso fuera de Azure.

Los recursos compartidos de archivos NFS se basan en la autenticación de nivel de

red y, por tanto, solo son accesibles mediante redes restringidas. El uso de un
recurso compartido de archivos NFS siempre requiere algún nivel de configuración
de redes.

La configuración de puntos de conexión públicos y privados para Azure Files se realiza

en el objeto de administración de nivel superior de Azure Files, la cuenta de
almacenamiento de Azure. Una cuenta de almacenamiento es una construcción de
administración que representa un grupo compartido de almacenamiento en el que
puede implementar varios recursos compartidos de archivos de Azure, así como los
recursos de almacenamiento de otros servicios de almacenamiento de Azure, como
contenedores de blobs o colas.
 How to replace an on-premises file server with Azure file shares

Este vídeo es una guía y demostración sobre cómo exponer de forma segura recursos
compartidos de archivos de Azure directamente para las aplicaciones y trabajadores de
la información en cinco sencillos pasos. En las secciones siguientes se proporcionan
vínculos y contexto adicional de la documentación a la que se hace referencia en el
vídeo.

Se aplica a
Tipo de recurso compartido de archivos SMB NFS

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS

Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Transferencia segura
De manera predeterminada, las cuentas de almacenamiento de Azure requieren
transferencia segura, independientemente de si se accede a los datos mediante el punto
de conexión público o privado. Para Azure Files, se aplica la configuración requerir
transferencia segura para todo el acceso de protocolo a los datos almacenados en
recursos compartidos de archivos de Azure, incluidos SMB, NFS y FileREST. Puede
deshabilitar la configuración requerir transferencia segura para permitir el tráfico sin
cifrar. En Azure Portal, también puede ver esta configuración etiquetada como requerir
transferencia segura para las operaciones de la API de REST.
Los protocolos SMB, NFS y FileREST tienen un comportamiento ligeramente diferente
con respecto a la configuración requerir transferencia segura:

Cuando se habilita la configuración requerir transferencia segura en una cuenta

de almacenamiento, todos los recursos compartidos de archivos SMB de esa
cuenta de almacenamiento requerirán el protocolo SMB 3.x con los algoritmos de
cifrado AES-128-CCM, AES-128-GCM o AES-256-GCM, según la negociación de
cifrado disponible y requerido entre el cliente SMB y Azure Files. Puede alternar
qué algoritmos de cifrado SMB se permiten mediante la configuración de
seguridad de SMB. Al deshabilitar la configuración requerir transferencia segura,
se permiten los montajes SMB 2.1 y SMB 3.x sin cifrado.

Los recursos compartidos de archivos NFS no admiten un mecanismo de cifrado,

por lo que para poder usar el protocolo NFS para acceder a un recurso compartido
de archivos de Azure, debe deshabilitar la configuración requerir transferencia
segura para la cuenta de almacenamiento.

Cuando se requiere transferencia segura, el protocolo FileREST solo se puede usar

con HTTPS. Actualmente, FileREST solo se admite en recursos compartidos de
archivos SMB.

Punto de conexión público

El punto de conexión público de los recursos compartidos de archivos de Azure de una
cuenta de almacenamiento es un punto de conexión expuesto a Internet. El punto de
conexión público es el punto de conexión predeterminado para una cuenta de
almacenamiento; sin embargo, se puede deshabilitar si lo desea.

Los protocolos SMB, NFS y FileREST pueden usar el punto de conexión público. Sin
embargo, cada uno tiene reglas ligeramente diferentes para el acceso:

Los recursos compartidos de archivos SMB son accesibles desde cualquier lugar
del mundo mediante el punto de conexión público de la cuenta de
almacenamiento con SMB 3.x con cifrado. Esto significa que las solicitudes
autenticadas, como las solicitudes autorizadas por la identidad de inicio de sesión
de un usuario, se pueden originar de forma segura dentro o fuera de la región de
Azure. Si se desea usar SMB 2.1 o SMB 3.x sin cifrado, se deben cumplir dos
condiciones:

1. La configuración requerir transferencia segura de la cuenta de

almacenamiento debe estar deshabilitada.
 2. La solicitud se debe originar desde dentro de la región de Azure. Como se
mencionó anteriormente, se permiten las solicitudes SMB cifradas desde
cualquier lugar, dentro o fuera de la región de Azure.

Los recursos compartidos de archivos NFS son accesibles desde el punto de

conexión público de la cuenta de almacenamiento si y solo si el punto de conexión
público de la cuenta de almacenamiento está restringido a redes virtuales
específicas mediante puntos de conexión de servicio. Consulte Configuración de
firewall del punto de conexión público para obtener información adicional sobre
los puntos de conexión de servicio.

FileREST es accesible mediante el punto de conexión público. Si se requiere

transferencia segura, solo se aceptan solicitudes HTTPS. Si la transferencia segura
está deshabilitada, el punto de conexión público acepta las solicitudes HTTP
independientemente del origen.

Configuración de firewall del punto de conexión público

El firewall de la cuenta de almacenamiento restringe el acceso al punto de conexión
público de una cuenta de almacenamiento. Con el firewall de la cuenta de
almacenamiento, puede restringir el acceso a determinadas direcciones IP o intervalos
de direcciones IP, a redes virtuales específicas o deshabilitar por completo el punto de
conexión público.

Al restringir el tráfico del punto de conexión público a una o varias redes virtuales, se
usa una funcionalidad de la red virtual llamada puntos de conexión de servicio. Las
solicitudes dirigidas al punto de conexión de servicio de Azure Files aún van a la
dirección IP pública de la cuenta de almacenamiento; sin embargo, la capa de redes
realiza una comprobación adicional de la solicitud para validar que proceda de una red
virtual autorizada. Los protocolos SMB, NFS y FileREST admiten puntos de conexión de
servicio. Sin embargo, a diferencia de SMB y FileREST, solo se puede acceder a los
recursos compartidos de archivos NFS con el punto de conexión público mediante el
uso de un punto de conexión de servicio.

Para más información sobre cómo configurar el firewall de la cuenta de

almacenamiento, consulte Configuración de los firewalls y las redes virtuales de Azure
Storage.

Enrutamiento de red del punto de conexión público

Azure Files admite varias opciones de enrutamiento de red. La opción predeterminada,
el enrutamiento de Microsoft, funciona con todas las configuraciones de Azure Files. La
opción de enrutamiento de Internet no admite escenarios de unión a un dominio de AD
ni Azure File Sync.

Puntos de conexión privados

Además del punto de conexión público predeterminado para una cuenta de
almacenamiento, Azure Files ofrece la opción de tener uno o más puntos de conexión
privados. Un punto de conexión privado es un punto de conexión que solo es accesible
dentro de una red virtual de Azure. Cuando se crea un punto de conexión privado para
la cuenta de almacenamiento, esta obtiene una dirección IP privada del espacio de
direcciones de la red virtual, de forma muy parecida a cómo un servidor de archivos
local o un dispositivo NAS reciben una dirección IP dentro del espacio de direcciones
dedicado de la red local.

Un punto de conexión privado está asociado a una subred de red virtual de Azure
específica. Una cuenta de almacenamiento puede tener puntos de conexión privados en
más de una red virtual.

El uso de puntos de conexión privados con Azure Files le permite:

Conectarse de forma segura a los recursos compartidos de archivos de Azure

desde redes locales mediante una conexión VPN o ExpressRoute con
emparejamiento privado.
Proteger los recursos compartidos de archivos mediante la configuración del
firewall de la cuenta de almacenamiento para bloquear todas las conexiones el
punto de conexión público. De forma predeterminada, crear un punto de conexión
privado no bloquea las conexiones al punto de conexión público.
Aumentar la seguridad de la red virtual, al permitirle bloquear la filtración de datos
desde la red virtual (y los límites de emparejamiento).

Para crear un punto de conexión privado, consulte Configuración de puntos de conexión

privados para Azure Files.

Tunelización del tráfico a través de una red privada virtual

o de ExpressRoute
Para usar puntos de conexión privados para acceder a recursos compartidos de archivos
SMB o NFS desde el entorno local, debe establecer un túnel de red entre la red local y
Azure. Una red virtual (o VNet) es similar a una red local tradicional. Al igual que una
cuenta de almacenamiento de Azure o una máquina virtual de Azure, una red virtual es
un recurso de Azure que se implementa en un grupo de recursos.
Azure Files admite los siguientes mecanismos para tunelizar el tráfico entre los
servidores y las estaciones de trabajo locales y los recursos compartidos de archivos de
SMB y NFS de Azure:

Una puerta de enlace de VPN es un tipo específico de puerta de enlace de red

virtual que se usa para enviar tráfico cifrado entre una red virtual de Azure y una
ubicación alternativa (por ejemplo, en un entorno local) a través de Internet. Una
instancia de Azure VPN Gateway es un recurso de Azure que se puede
implementar en un grupo de recursos junto con una cuenta de almacenamiento u
otros recursos de Azure. Las puertas de enlace de VPN exponen dos tipos de
conexión distintos:
Las conexiones de puerta de enlace de VPN de punto a sitio, que son
conexiones VPN entre Azure y un cliente individual. Esta solución es
principalmente útil para los dispositivos que no forman parte de la red local de
la organización. Un caso de uso común es el de los teletrabajadores que
quieren poder montar su recurso compartido de archivos de Azure desde su
casa, una cafetería o un hotel cuando están de viaje. Para usar una conexión
VPN de punto a sitio con Azure Files, debe configurar una conexión VPN de
punto a sitio para cada cliente que quiera conectarse. Para simplificar la
implementación de una conexión VPN P2S, consulte Configuración de una VPN
de punto a sitio (P2S) en Windows para su uso con Azure Files y Configuración
de una VPN de punto a sitio (P2S) en Linux para su uso con Azure Files.
Las VPN de sitio a sitio, que son conexiones VPN entre Azure y la red de su
organización. Una conexión VPN de sitio a sitio le permite configurar una
conexión VPN una vez para un servidor o dispositivo VPN hospedado en la red
de su organización, en lugar de configurar una conexión para cada dispositivo
cliente que necesite acceder al recurso compartido de archivos de Azure. Para
simplificar la implementación de una conexión VPN S2S, consulte Configuración
de una VPN de sitio a sitio (S2S) para su uso con Azure Files.
ExpressRoute, que permite crear una ruta definida entre Azure y la red local que no
atraviesa Internet. Como ExpressRoute proporciona una ruta de acceso dedicada
entre el centro de recursos local y Azure, ExpressRoute puede resultar útil cuando
se tiene en cuenta el rendimiento de la red. ExpressRoute también es una buena
opción cuando la directiva o los requisitos normativos de la organización requieren
una ruta de acceso determinista a los recursos en la nube.

７ Nota

Aunque se recomienda usar puntos de conexión privados para ayudar a extender la

red local a Azure, técnicamente es posible enrutar al punto de conexión público
mediante la conexión VPN. Sin embargo, esto requiere codificar de forma rígida la
 dirección IP del punto de conexión público del clúster de almacenamiento de Azure
que atiende la cuenta de almacenamiento. Dado que las cuentas de
almacenamiento se pueden mover entre clústeres de almacenamiento en cualquier
momento y se agregan clústeres nuevos y se quitan con frecuencia, esto requiere
codificar de forma rígida y con regularidad todas las posibles direcciones IP de
almacenamiento de Azure en las reglas de enrutamiento.

Configuración de DNS
Cuando se crea un punto de conexión privado, de forma predeterminada también se
crea una zona DNS privada (o se actualiza una existente) correspondiente al subdominio
privatelink . En sentido estricto, no es necesario crear una zona DNS privada para usar
un punto de conexión privado para la cuenta de almacenamiento. Sin embargo, se
recomienda en general y se requiere de forma explícita al montar el recurso compartido
de archivos de Azure con una entidad de seguridad de usuario de Active Directory o al
acceder a él desde la API de FileREST.

７ Nota

En este artículo se usa el sufijo DNS de la cuenta de almacenamiento para las

regiones públicas de Azure core.windows.net . Este comentario también se aplica a
las nubes soberanas de Azure, como la nube de Azure US Government y la nube de
Azure China; simplemente sustituya los sufijos adecuados para su entorno.

En la zona DNS privada, se va a crea un registro D para

storageaccount.privatelink.file.core.windows.net y un registro CNAME para el

nombre normal de la cuenta de almacenamiento, que sigue el patrón

storageaccount.file.core.windows.net . Dado que la zona DNS privada de Azure está

conectada a la red virtual que contiene el punto de conexión privado, puede observar la
configuración de DNS cuando mediante una llamada al cmdlet Resolve-DnsName desde
PowerShell en una máquina virtual de Azure (como alternativa, nslookup en Windows y
Linux):

PowerShell

Resolve-DnsName -Name "storageaccount.file.core.windows.net"

En este ejemplo, la cuenta de almacenamiento storageaccount.file.core.windows.net

se resuelve en la dirección IP privada del punto de conexión privado, que resulta ser
192.168.0.4 .

Output

Name Type TTL Section NameHost

---- ---- --- ------- --------
storageaccount.file.core.windows. CNAME 29 Answer
csostoracct.privatelink.file.core.windows.net
net

Name : storageaccount.privatelink.file.core.windows.net
QueryType : A
TTL : 1769
Section : Answer
IP4Address : 192.168.0.4

Name : privatelink.file.core.windows.net
QueryType : SOA
TTL : 269
Section : Authority
NameAdministrator : azureprivatedns-host.microsoft.com
SerialNumber : 1
TimeToZoneRefresh : 3600
TimeToZoneFailureRetry : 300
TimeToExpiration : 2419200
DefaultTTL : 300

Si ejecuta el mismo comando en el entorno local, verá que el mismo nombre de cuenta
de almacenamiento se resuelve en la dirección IP pública de la cuenta de
almacenamiento; storageaccount.file.core.windows.net es un registro CNAME para
storageaccount.privatelink.file.core.windows.net , que, a su vez, es un registro

CNAME para el clúster de almacenamiento de Azure que hospeda la cuenta de

almacenamiento:

Output

Name Type TTL Section NameHost

---- ---- --- ------- --------
storageaccount.file.core.windows. CNAME 60 Answer
storageaccount.privatelink.file.core.windows.net
net
storageaccount.privatelink.file.c CNAME 60 Answer
file.par20prdstr01a.store.core.windows.net
ore.windows.net

Name : file.par20prdstr01a.store.core.windows.net
QueryType : A
TTL : 60
 Section : Answer
IP4Address : 52.239.194.40

Esto refleja el hecho de que la cuenta de almacenamiento puede exponer el punto de

conexión público y uno o varios puntos de conexión privados. Para asegurarse de que el
nombre de la cuenta de almacenamiento se resuelve en la dirección IP privada del
punto de conexión privado, debe cambiar la configuración en los servidores DNS
locales. Esto puede realizarse de varias maneras:

Modifique el archivo hosts de los clientes para que

storageaccount.file.core.windows.net se resuelva en la dirección IP privada del
punto de conexión privado deseado. Este método no se recomienda en entornos
de producción, ya que estos cambios se deberán realizar en todos los clientes que
quieran montar los recursos compartidos de archivos de Azure y los cambios en la
cuenta de almacenamiento o en el punto de conexión privado no se administrarán
automáticamente.
Cree un registro D para storageaccount.file.core.windows.net en los servidores
DNS locales. Este método tiene la ventaja de que los clientes de su entorno local
podrán resolver automáticamente la cuenta de almacenamiento sin necesidad de
configurar cada cliente. Sin embargo, esta solución es igual de frágil que modificar
el archivo hosts, ya que no se reflejan los cambios. Aunque esta solución es frágil,
puede ser la mejor opción para algunos entornos.
Reenvíe la zona core.windows.net de los servidores DNS locales a la zona DNS
privada de Azure. Se puede acceder al host DNS privado de Azure a través de una
dirección IP especial ( 168.63.129.16 ) que solo es accesible dentro de las redes
virtuales que están vinculadas a la zona DNS privada de Azure. Para solucionar esta
limitación, puede ejecutar servidores DNS adicionales dentro de la red virtual que
reenviarán core.windows.net a la zona DNS privada de Azure. Para simplificar esta
configuración, se han proporcionado cmdlets de PowerShell que implementarán
automáticamente los servidores DNS en la red virtual de Azure y los configurarán
según sea necesario. Para aprender a configurar el reenvío de DNS, consulte
Configuración de DNS con Azure Files.

SMB a través de QUIC

Windows Server 2022 Azure Edition admite un nuevo protocolo de transporte llamado
QUIC para el servidor SMB proporcionado por el rol Servidor de archivos. QUIC es una
sustitución de TCP que se basa en UDP, lo que proporciona numerosas ventajas sobre
TCP, a la vez que proporciona un mecanismo de transporte confiable. Una de las
principales ventajas para el protocolo SMB es que, en lugar de usar el puerto 445, todo
el transporte se lleva a cabo mediante el puerto 443, que está generalmente abierto
para admitir HTTPS. Esto significa de forma efectiva que SMB mediante QUIC ofrece una
"VPN de SMB" para el uso compartido de archivos mediante la red pública de Internet.
Windows 11 se suministra con un cliente compatible con SMB mediante QUIC.

En este momento, Azure Files no admite directamente SMB mediante QUIC. Sin
embargo, puede obtener acceso a recursos compartidos de archivos de Azure a través
de Azure File Sync que se ejecutan en Windows Server, como se muestra en el diagrama
siguiente. Esto también le ofrece la opción de tener memorias caché de Azure File Sync
tanto locales como en diferentes centros de datos de Azure para proporcionar cachés
locales para un personal distribuido. Para más información sobre esta opción, consulte
Implementación de Azure File Sync y SMB a través de QUIC.

Consulte también
Introducción a Azure Files
Planeamiento de una implementación de Azure Files
Introducción a la protección de datos de
Azure Files
Artículo • 26/07/2023

Azure Files proporciona muchas herramientas para proteger los datos, incluida la
eliminación temporal, las instantáneas de recursos compartidos, Azure Backup y Azure
File Sync. En este artículo se describe cómo proteger los datos en Azure Files y los
conceptos y procesos implicados en la copia de seguridad y recuperación de recursos
compartidos de archivos de Azure.

How Azure Files can help protect against ransomware and acciden…
acciden…

Consulte este vídeo para ver cómo la protección de datos avanzada de Azure Files
protege a las empresas contra el ransomware y la pérdida accidental de datos, a la vez
que ofrece una mayor continuidad empresarial.

Por qué debe proteger los datos

En el caso de Azure Files, la protección de datos hace referencia a la protección de la
cuenta de almacenamiento, los recursos compartidos de archivos y los datos que
contienen contra la eliminación o modificación. Con la protección de datos, también es
posible restaurar los datos después de eliminarlos o modificarlos.

Hay varias razones por las que debe proteger los datos del recurso compartido de
archivos.

Recuperación de la pérdida accidental de datos: Recupere los datos que se

eliminen o dañen accidentalmente.
 Escenarios de actualización: Restaure a un estado correcto conocido después de
un intento de actualización erróneo.
Protección contra ransomware: Recupere datos sin pagar rescate a
ciberdelincuentes.
Retención a largo plazo: Cumpla con los requisitos de retención de datos.
Continuidad empresarial: Prepare la infraestructura para que sea de alta
disponibilidad para cargas de trabajo críticas.

Copia de seguridad y restauración de recursos

compartidos de archivos de Azure
Puede configurar Azure Backup para realizar copias de seguridad de los recursos
compartidos de archivos mediante Azure Portal, Azure PowerShell, la CLI de Azure o la
API de REST. También puede usar Azure File Sync para realizar copias de seguridad de
los datos del servidor de archivos locales en un recurso compartido de archivos de
Azure.

Azure Portal

Para obtener información sobre cómo realizar copias de seguridad y restaurar

recursos compartidos de archivos de Azure mediante Azure Portal, consulte los
siguientes artículos:

Copia de seguridad de recursos compartidos de archivos de Azure

Restauración de recursos compartidos de archivos de Azure
Administración de copias de seguridad de recursos compartidos de archivos
de Azure

Redundancia de datos
Azure Files ofrece varias opciones de redundancia, incluida la redundancia geográfica,
para ayudar a proteger los datos frente a interrupciones del servicio debido a problemas
de hardware o desastres naturales. Para averiguar qué opción es mejor para su caso de
uso, consulte Redundancia de datos de Azure Files.

） Importante

Azure Files solo admite redundancia geográfica (GRS o GZRS) para los recursos
compartidos de archivos con SMB estándar. Los recursos compartidos de archivos
 Premium y los recursos compartidos de archivos NFS deben usar almacenamiento
con redundancia local (LRS) o almacenamiento con redundancia de zona (ZRS).

Recuperación ante desastres y conmutación

por error
En el caso de un desastre o una interrupción no planeada, la restauración del acceso a
los datos del recurso compartido de archivos suele ser fundamental para mantener
operativa la empresa. En función de la importancia de los datos hospedados en los
recursos compartidos de archivos, es posible que necesite una estrategia de
recuperación ante desastres que incluya errores en los recursos compartidos de archivos
de Azure en una región secundaria.

Azure Files ofrece conmutación por error administrada por el cliente para cuentas de
almacenamiento estándar si el centro de datos de la región primaria deja de estar
disponible. Consulte Recuperación ante desastres y conmutación por error para obtener
Azure Files.

Evitar la eliminación accidental de cuentas de

almacenamiento y recursos compartidos de
archivos
La pérdida de datos no siempre se produce debido a un desastre. Más a menudo, es el
resultado de un error humano. Azure proporciona herramientas para evitar la
eliminación accidental de cuentas de almacenamiento y recursos compartidos de
archivos.

Bloqueos de cuenta de almacenamiento

Los bloqueos de cuenta de almacenamiento permiten a los administradores bloquear la
cuenta de almacenamiento para evitar que los usuarios eliminen accidentalmente la
cuenta de almacenamiento. Existen dos tipos de bloqueos de cuentas de
almacenamiento:

Un bloqueo CannotDelete impide que los usuarios eliminen una cuenta de

almacenamiento, pero permite modificar su configuración.
Un bloqueo ReadOnly impide que los usuarios eliminen una cuenta de
almacenamiento o modifiquen su configuración.
Para más información, consulte Aplicación de un bloqueo de Azure Resource Manager a
una cuenta de almacenamiento.

Eliminación temporal
La eliminación temporal funciona en un nivel de recurso compartido de archivos para
proteger los recursos compartidos de archivos de Azure frente a la eliminación
accidental. Si se elimina un recurso compartido con eliminación temporal habilitada,
este pasa a un estado de eliminación temporal internamente y se puede recuperar hasta
que expire el período de retención. Los recursos compartidos de archivos de Azure se
siguen facturando en la capacidad usada cuando se eliminan temporalmente.

Para más información, consulte Habilitación de la eliminación temporal en recursos

compartidos de archivos de Azure y Prevención de la eliminación accidental de recursos
compartidos de archivos de Azure.

Instantáneas de recursos compartido

Las instantáneas de recurso compartido de archivos son copias a un momento dado del
recurso compartido de archivos de Azure que puede realizar manual o automáticamente
a través de Azure Backup. Después, puede restaurar archivos individuales a partir de
estas instantáneas. Puede tomar hasta 200 instantáneas por recurso compartido de
archivos.

Las instantáneas son incrementales por naturaleza, por lo que capturan solo los cambios
desde la última instantánea. Eso significa que son eficientes en cuanto a costo y espacio.
Se le factura el uso diferencial del almacenamiento de cada instantánea, por lo que
resulta práctico tener varios puntos de recuperación para satisfacer los requisitos de
RPO bajos.

Para obtener más información, consulte Información general de las instantáneas de

recurso compartido de Azure Files.

Uso de Azure File Sync para copias de

seguridad en la nube híbrida
El uso de Azure File Sync con Azure Backup es una solución sencilla para las copias de
seguridad en la nube híbridas desde el entorno local a la nube. Azure File Sync mantiene
los archivos sincronizados y centralizados.
Este método simplifica la recuperación ante desastres y proporciona varias opciones.
Puede recuperar archivos o directorios únicos, o realizar una restauración rápida de
todo el recurso compartido de archivos. Solo tiene que abrir un nuevo servidor en el
servidor principal y apuntarlo al recurso compartido de archivos de Azure centralizado
donde puede acceder a los datos. Con el tiempo, los archivos se almacenarán en caché
localmente o se almacenarán en capas en la nube en función de la configuración de
Azure File Sync.

Consulte también
Redundancia de Azure Files
Recuperación ante desastres y conmutación por error de Azure Files
Redundancia de datos de Azure Files
Artículo • 28/06/2023

Azure Files siempre almacena varias copias de los datos, con el fin de protegerlos de
eventos planeados y no planeados, como errores transitorios de hardware,
interrupciones del suministro eléctrico o cortes de la red, y desastres naturales. La
redundancia garantiza que la cuenta de almacenamiento cumple sus objetivos de
disponibilidad y durabilidad, aunque se produzcan errores.

A la hora de decidir qué opción de redundancia es la más adecuada para su escenario,

intente buscar un equilibrio entre bajo costo y alta disponibilidad. Entre los factores que
ayudan a determinar qué opción de redundancia debe elegir se incluye:

Cómo se replican los datos en la región primaria.

Si los datos se replican en una región secundaria que está alejada geográficamente
de la región primaria, para protección frente a desastres regionales (redundancia
geográfica).

Los recursos compartidos de archivos de Azure se administran a través de un recurso

común de Azure denominado cuenta de almacenamiento. La cuenta de almacenamiento
representa un grupo compartido de almacenamiento que se puede usar para
implementar recursos compartidos de archivos. Para más información sobre las cuentas
de almacenamiento, consulte Introducción a las cuentas de Storage.

Al crear una cuenta de almacenamiento, debe elegir una configuración de redundancia

para la cuenta de almacenamiento que se comparte con todos los servicios de
almacenamiento expuestos por esa cuenta. Todos los recursos compartidos de archivos
implementados en la misma cuenta de almacenamiento tienen la misma configuración
de redundancia. Se recomienda aislar los recursos compartidos de archivos en
diferentes cuentas de almacenamiento si no tienen los mismos requisitos de
redundancia.

Redundancia en la región primaria

Los datos de una cuenta de Azure Storage siempre se replican tres veces en la región
primaria. Azure Files ofrece dos métodos para replicar los datos en la región primaria:

El almacenamiento con redundancia local (LRS) copia los datos de forma

sincrónica tres veces dentro de una única ubicación física en la región primaria.
LRS es la opción de replicación menos costosa, pero no se recomienda para las
aplicaciones que requieren de alta disponibilidad o durabilidad.
 El almacenamiento con redundancia de zona (ZRS) copia los datos de forma
sincrónica en tres zonas de disponibilidad de Azure en la región primaria. En el
caso de las aplicaciones que requieren de alta disponibilidad, le recomendamos
usar ZRS en la región primaria y también replicación en una región secundaria.

Almacenamiento con redundancia local

El almacenamiento con redundancia local (LRS) replica la cuenta de almacenamiento
tres veces dentro de un único centro de datos en la región primaria. LRS ofrece una
durabilidad mínima del 99,999999999 % (11 nueves) en un año determinado.

LRS es la opción de redundancia de costo más bajo y ofrece la menor durabilidad en

comparación con otras opciones. LRS protege los datos frente a errores en la estantería
de servidores y en la unidad. No obstante, si se produce un desastre como un incendio
o una inundación en el centro de datos, es posible que todas las réplicas de una cuenta
de almacenamiento con LRS se pierdan o no se puedan recuperar. Para mitigar este
riesgo, le recomendamos usar almacenamiento con redundancia de zona (ZRS), el
almacenamiento con redundancia geográfica (GRS) o el almacenamiento con
redundancia de zona geográfica (GZRS).

Las solicitudes de escritura a una cuenta de almacenamiento que usa LRS se producen
de forma sincrónica. Las operaciones de escritura se devuelven correctamente solo
después de que los datos se escriben en las tres réplicas.

En el diagrama siguiente se muestra cómo se replican los datos en un único centro de

datos con LRS:

LRS es una buena opción para los siguientes escenarios:

 Si la aplicación almacena datos que se pueden reconstruir fácilmente en caso de
que se produzca una pérdida de datos.
Si la aplicación está restringida a la replicación de datos en un país o una región
debido a requisitos de gobernanza de datos. En algunos casos, las regiones
emparejadas en las que los datos se replican geográficamente pueden estar en
otro país o región. Para más información sobre las regiones emparejadas, consulte
Regiones de Azure .

Almacenamiento con redundancia de zona

El almacenamiento con redundancia de zona (ZRS) replica la cuenta de almacenamiento
de forma sincrónica en tres zonas de disponibilidad de Azure en la región primaria.
Cada zona de disponibilidad es una ubicación física individual con alimentación,
refrigeración y redes independientes. ZRS proporciona una durabilidad mínima del
99,9999999999 % (12 nueves) en un año determinado.

Con ZRS, los datos son accesibles para las operaciones de escritura y lectura incluso si
una zona deja de estar disponible. Si alguna zona deja de estar disponible, Azure realiza
las actualizaciones de la red, como el redireccionamiento de DNS. Estas actualizaciones
pueden afectar a la aplicación si se accede a los datos antes de que se completen dichas
actualizaciones. Al diseñar aplicaciones para ZRS, siga los procedimientos para el control
de errores transitorios, incluida la implementación de directivas de reintentos con
retroceso exponencial.

Las solicitudes de escritura a una cuenta de almacenamiento que usa ZRS se producen
de forma sincrónica. Las operaciones de escritura se devuelven correctamente solo
después de que los datos se escriben en todas las réplicas de las tres zonas de
disponibilidad.

Una ventaja de usar ZRS para cargas de trabajo de Azure Files es que si una zona deja
de estar disponible, no es necesario volver a montar los recursos compartidos de
archivos de Azure de los clientes conectados. Le recomendamos usar ZRS en la región
primaria para escenarios que requieren de alta disponibilidad y bajo RPO/RTO. También
recomendamos ZRS para restringir la replicación de datos a un país o región en
particular a fin de cumplir los requisitos de gobernanza de datos.

７ Nota

Azure File Sync tiene redundancia de zona en todas las regiones que admiten
zonas, excepto US Gov Virginia. En la mayoría de los casos, se recomienda que los
usuarios de Azure File Sync configuren las cuentas de almacenamiento para usar
ZRS o GZRS.
En el diagrama siguiente se muestra cómo los datos se replican en las zonas de
disponibilidad de la región primaria con ZRS:

ZRS ofrece un rendimiento excelente, una latencia baja y resistencia para los datos si
dicha región deja de estar disponible temporalmente. No obstante, ZRS por sí sola
podría no proteger los datos frente a un desastre regional en el que varias zonas
resulten afectadas permanentemente. Para la protección frente a desastres regionales,le
recomendamos usar almacenamiento con redundancia de zona geográfica (GZRS), que
usa ZRS en la región primaria y también replica geográficamente los datos en una
región secundaria.

Para obtener más información sobre qué regiones admiten ZRS, consulte Servicio de
zona de disponibilidad y compatibilidad regional.

Cuentas de almacenamiento estándar

ZRS se admite en cuentas de almacenamiento estándar de uso general v2 para los tres
niveles estándar: optimizado para transacciones, frecuente y esporádico.
Para obtener una lista de regiones que admiten ZRS para cuentas de almacenamiento
estándar, consulte Regiones de Azure que admiten almacenamiento con redundancia de
zona (ZRS) para cuentas de almacenamiento estándar.

Cuentas de recursos compartidos de archivos premium

ZRS se admite para recursos compartidos de archivos con el tipo de cuenta de
almacenamiento FileStorage .

Para obtener una lista de las regiones que admiten ZRS para las cuentas de recursos
compartidos de archivos premium, consulte Almacenamiento con redundancia de zona
de Azure Files para recursos compartidos premium.

Redundancia en una región secundaria

En el caso de las aplicaciones que requieren de alta durabilidad para los recursos
compartidos de archivos con SMB, puede elegir el almacenamiento con redundancia
geográfica para copiar los datos de la cuenta de almacenamiento en una región
secundaria que esté a cientos de kilómetros de distancia de la región primaria. Si la
cuenta de almacenamiento se copia a una región secundaria, sus datos se mantienen
incluso ante un apagón regional completo o un desastre del cual la región primaria no
se puede recuperar.

） Importante

Azure Files solo admite redundancia geográfica (GRS o GZRS) para los recursos
compartidos de archivos con SMB estándar. Los recursos compartidos de archivos
premium y los recursos compartidos de archivos NFS deben usar LRS o ZRS.

Al crear una cuenta de almacenamiento, seleccione la región principal de la cuenta. La

región secundaria emparejada se determina según la región primaria y no es posible
cambiarla. Para obtener más información sobre las regiones compatibles con Azure,
consulte Regiones de Azure .

Azure Files ofrece dos opciones para copiar los datos a una región secundaria.
Actualmente, las opciones de almacenamiento con redundancia geográfica solo están
disponibles para recursos compartidos de archivos SMB estándar que no tienen
habilitada la configuración de recursos compartidos de archivos grandes en la cuenta
de almacenamiento (hasta 5 TiB), a menos que use Redundancia geográfica de
Azure Files para recursos compartidos de archivos grandes (versión preliminar).
 El almacenamiento con redundancia geográfica (GRS) copia los datos de forma
sincrónica tres veces dentro de una única ubicación física en la región primaria
mediante LRS. Luego copia los datos de forma asincrónica en una única ubicación
física en la región secundaria. Dentro de la región secundaria, los datos siempre se
replican de forma sincrónica tres veces mediante LRS.
El almacenamiento con redundancia de zona geográfica (GZRS) copia los datos
de forma sincrónica en tres zonas de disponibilidad de Azure en la región primaria
mediante ZRS. Luego copia los datos de forma asincrónica en una única ubicación
física en la región secundaria. Dentro de la región secundaria, los datos se copian
de forma sincrónica tres veces mediante LRS.

La principal diferencia entre GRS y GZRS es la forma en que los datos se replican en la
región primaria. Dentro de la región secundaria, los datos siempre se replican de forma
sincrónica tres veces mediante LRS. LRS en la región secundaria protege los datos frente
a errores de hardware.

Almacenamiento con redundancia geográfica

El almacenamiento con redundancia geográfica (GRS) copia los datos de forma
sincrónica tres veces dentro de una única ubicación física en la región primaria mediante
LRS. Después, copia los datos de forma asincrónica en una única ubicación física de una
región secundaria que se encuentra a cientos de miles de kilómetros de distancia de la
región primaria. GRS proporciona una durabilidad mínima del 99.99999999999999 %
(16 nueves) en un año determinado.

Una operación se escritura se confirma primero en la ubicación principal y se replica

mediante LRS. Después, la actualización se replica de manera asincrónica en la región
secundaria. Cuando los datos se escriben en la ubicación secundaria, también se
replican dentro de esa ubicación con LRS.

En el diagrama siguiente, se muestra cómo se replican los datos con GRS:

Almacenamiento con redundancia de zona geográfica
El almacenamiento con redundancia de zona geográfica (GZRS) combina la alta
disponibilidad que proporciona la redundancia entre zonas de disponibilidad con la
protección frente a interrupciones regionales que proporciona la replicación geográfica.
Los datos de una cuenta de almacenamiento de GZRS se almacenan en tres zonas de
disponibilidad de Azure en la región primaria y también se replican en una región
geográfica secundaria para protegerlos frente a desastres regionales. Le recomendamos
el uso de GZRS en aplicaciones que requieran de coherencia, durabilidad y
disponibilidad máximas, además de un excelente rendimiento y resistencia para la
recuperación ante desastres.

Con una cuenta de almacenamiento de GZRS, puede seguir leyendo y escribiendo datos
si una zona de disponibilidad deja de estar disponible o es irrecuperable. Además, los
datos se mantienen en caso de un apagón completo de una región o de un desastre
tras el que la región primaria no se puede recuperar. GZRS está diseñada para
proporcionar una durabilidad mínima del 99,99999999999999 % (16 nueves) en un año
determinado.

En el diagrama siguiente, se muestra cómo se replican los datos con GZRS:

Solo las cuentas de almacenamiento estándares de uso general v2 son compatibles con
GZRS.

Para obtener una lista de regiones que admiten GZRS, consulte Regiones de Azure que
admiten el almacenamiento con redundancia de zona geográfica (GZRS).
Recuperación ante desastres y conmutación por error
Con GRS o GZRS, los recursos compartidos de archivos no serán accesibles en la región
secundaria a menos que se produzca una conmutación por error. Si la región primaria
deja de estar disponible, puede conmutar por error a la región secundaria. El proceso de
conmutación por error actualiza la entrada DNS que proporciona Azure Files, de modo
tal que el punto de conexión secundario se convierte en el nuevo punto de conexión
principal de la cuenta de almacenamiento. Durante el proceso de conmutación por
error, los datos no son accesibles. Una vez completada la conmutación por error, puede
leer y escribir datos en la nueva región primaria. Una vez completada la conmutación
por error, la región secundaria se convierte en la región primaria y se pueden leer y
escribir datos de nuevo. Para más información, consulte Recuperación ante desastres y
conmutación por error de Azure Files.

） Importante

Azure Files no admite el almacenamiento con redundancia geográfica con acceso

de lectura (RA-GRS) ni el almacenamiento con redundancia de zona geográfica con
acceso de lectura (RA-GZRS). Si una cuenta de almacenamiento está configurada
para usar RA-GRS o RA-GZRS, los recursos compartidos de archivos se configurarán
y facturarán como GRS o GZRS.

Redundancia geográfica para recursos compartidos de

archivos premium
Como se mencionó anteriormente, las opciones de redundancia geográfica (GRS y
GZRS) no se admiten para recursos compartidos de archivos premium. Sin embargo,
puede obtener redundancia geográfica de otras maneras.

En los escenarios de Azure File Sync, puede sincronizar entre el recurso compartido de
archivos de Azure (el punto de conexión de nube), un servidor de archivos de Windows
local y un recurso compartido de archivos montado que se ejecuta en una máquina
virtual de otra región de Azure (el punto de conexión del servidor con fines de
recuperación ante desastres). Debe deshabilitar la nube por niveles para asegurarse de
que todos los datos están presentes localmente y aprovisionar suficiente
almacenamiento en la máquina virtual de Azure para contener todo el conjunto de
datos. Para asegurarse de que los cambios se replicarán rápidamente en la región
secundaria, solo se debe acceder a los archivos y modificarlos en el punto de conexión
del servidor en lugar de en Azure.
También puede crear su propio script para copiar datos en una cuenta de
almacenamiento de una región secundaria mediante herramientas como AzCopy (usar
la versión 10.4 o posterior para conservar las ACL y las marcas de tiempo).

Resumen de las opciones de redundancia

Las tablas de las siguientes secciones resumen las opciones de redundancia disponibles
para Azure Files.

Parámetros de durabilidad y disponibilidad

En la tabla siguiente se describen los parámetros clave de cada opción de redundancia:

Parámetro LRS ZRS GRS GZRS

Porcentaje de al menos al menos Como mínimo Como mínimo

durabilidad en 99,999999999 % 99,9999999999 % 99,99999999999999 % 99,99999999999999 %
un año (once nueves) (doce nueves) (dieciséis nueves) (dieciséis nueves)
determinado

Disponibilidad Al menos un Al menos un Al menos un 99,9 % Al menos un 99,9 %

de las 99,9 % (99 % 99,9 % (99 % (99 % para el nivel (99 % para el nivel
solicitudes de para el nivel para el nivel esporádico) esporádico)
lectura esporádico) esporádico)

Disponibilidad Al menos un Al menos un Al menos un 99,9 % Al menos un 99,9 %

de las 99,9 % (99 % 99,9 % (99 % (99 % para el nivel (99 % para el nivel
solicitudes de para el nivel para el nivel esporádico) esporádico)
escritura esporádico) esporádico)

Número de Tres copias Tres copias en Seis copias en total, Seis copias en total,
copias de dentro de una zonas de tres en la región tres en zonas de
datos única región disponibilidad primaria y tres en la disponibilidad
mantenidas en independientes región secundaria independientes en la
nodos dentro de una región primaria y tres
independientes única región copias con
redundancia local en
la región secundaria

Para más información, consulte el Acuerdo de Nivel de Servicio para cuentas de

Storage .

Durabilidad y disponibilidad por escenario de

interrupción
En la tabla siguiente, se indica si los datos son duraderos y están disponibles en un
escenario determinado, según el tipo de redundancia vigente para la cuenta de
almacenamiento. Azure Files no admite el acceso de lectura a la región secundaria si la
región primaria deja de estar disponible, a menos que se produzca una conmutación
por error.

Escenario de interrupción LRS ZRS GRS GZRS

Un nodo de un centro de datos deja de estar disponible Sí Sí Sí Sí

Un centro de datos completo (de zona o no de zona) deja de estar No Sí Sí1 Sí

disponible

Se produce una interrupción en toda la región en la región primaria No No Sí1 Sí1

1
Se requiere la conmutación por error de cuenta para restaurar la disponibilidad de
escritura si la región primaria deja de estar disponible.

Para obtener más información sobre los precios de las diferentes opciones de
redundancia, consulte Precios de Azure Files .

Consulte también
Cambio de la opción de redundancia para una cuenta de almacenamiento
Uso de redundancia geográfica para diseñar aplicaciones de alta disponibilidad
Recuperación ante desastres y
conmutación por error para Azure Files
Artículo • 23/10/2023

Microsoft se esfuerza por garantizar que los servicios de Azure siempre estén
disponibles. Sin embargo, es posible que se produzcan interrupciones de servicio no
planeadas y debe tener un plan de recuperación ante desastres (DR) para controlar una
interrupción del servicio regional. Parte importante de un plan de recuperación ante
desastres es preparar la conmutación por error en el punto de conexión secundario ante
la eventualidad de que el punto de conexión principal deje de estar disponible. En este
artículo se describen los conceptos y procesos implicados en la recuperación ante
desastres (DR) y la conmutación por error de la cuenta de almacenamiento.

） Importante

Azure File Sync solo admite la conmutación por error de la cuenta de

almacenamiento si el servicio de sincronización de almacenamiento también se
conmuta por error. Esto se debe a que Azure File Sync requiere que la cuenta de
almacenamiento y el servicio de sincronización de almacenamiento estén en la
misma región de Azure. Si solo se conmuta por error la cuenta de almacenamiento,
se producirá un error en las operaciones de sincronización y nube por niveles hasta
que el servicio de sincronización de almacenamiento se conmute por error a la
región secundaria. Si quiere conmutar por error una cuenta de almacenamiento
que contiene recursos compartidos de archivos de Azure que se usan como puntos
de conexión en la nube en Azure File Sync, vea Procedimientos recomendados de
recuperación ante desastres de Azure File Sync y recuperación del servidor de
Azure File Sync.

Métricas y costos de recuperación

Para formular una estrategia de recuperación ante desastres eficaz, una organización
debe comprender lo siguiente:

Cantidad de datos que puede permitirse perder en caso de interrupción (objetivo

de punto de recuperación o RPO)
La rapidez con la que debe poder restaurar las funciones empresariales y los datos
(objetivo de tiempo de recuperación o RTO)
El costo de la recuperación ante desastres generalmente aumenta con un RPO o un RTO
más bajo o cero. Las empresas que necesitan estar en funcionamiento unos segundos
después de un desastre y que no pueden soportar ninguna pérdida de datos pagarán
más por recuperación ante desastres, mientras que aquellas con números de RPO/RTO
más altos pagarán menos. Azure proporciona soluciones que pueden funcionar con
varios requisitos de RPO y RTO.

Elección de la opción de redundancia correcta

Azure Files ofrece diferentes opciones de redundancia para proteger los datos de
eventos planeados y no planeados que van desde errores transitorios de hardware, red
e interrupciones de energía hasta desastres naturales. Todos los recursos compartidos
de archivos de Azure pueden usar almacenamiento con redundancia local (LRS) o con
redundancia de zona (ZRS). Para más información, consulte Redundancia de Azure Files.

Azure Files admite la conmutación por error de cuentas para cuentas de

almacenamiento estándar configuradas con almacenamiento con redundancia
geográfica (GRS) y almacenamiento con redundancia de zona geográfica (GZRS) para
protegerse frente a interrupciones regionales. Con la conmutación por error de la
cuenta, puede iniciar el proceso de conmutación por error de la cuenta de
almacenamiento si el punto de conexión principal deja de estar disponible. La
conmutación por error actualiza el punto de conexión secundario para convertirlo en el
principal de la cuenta de almacenamiento. Una vez finalizada la conmutación por error,
los clientes pueden empezar a escribir en el nuevo punto de conexión principal.

GRS y GZRS siguen presentando un riesgo de pérdida de datos porque los datos se
copian en la región secundaria de forma asincrónica, lo que significa que hay un retraso
antes de que una escritura en la región primaria se copie en la secundaria. Si se produce
una interrupción, se perderán las operaciones de escritura del punto de conexión
principal que todavía no se hayan copiado en el punto de conexión secundario. Esto
significa que un error que afecte a la región primaria podría provocar la pérdida de
datos si no se puede recuperar dicha región. El intervalo entre las escrituras más
recientes en la región primaria y la última escritura en la región secundaria es el objetivo
de punto de recuperación. Normalmente, Azure Files tiene un RPO de 15 minutos o
menos, aunque actualmente no hay ningún Acuerdo de Nivel de Servicio sobre el
tiempo que se tarda en replicar los datos en la región secundaria.

Diseño para lograr alta disponibilidad

Es importante diseñar la aplicación para lograr alta disponibilidad desde el principio.
Consulte estos recursos de Azure para instrucciones sobre cómo diseñar la aplicación y
planificar la recuperación ante desastres:

Diseño de aplicaciones resistentes de Azure: información general de los conceptos

clave para diseñar aplicaciones altamente disponibles en Azure.
Lista de comprobación de resistencia: lista de comprobación para verificar que la
aplicación implementa los mejores procedimientos recomendados para lograr alta
disponibilidad.
Uso de redundancia geográfica para diseñar aplicaciones de alta disponibilidad:
instrucciones de diseño para compilar aplicaciones para aprovechar el
almacenamiento con redundancia geográfica.

También recomendamos diseñar la aplicación para prepararse para la posibilidad de

errores de escritura. La aplicación debe exponer los errores de escritura de manera de
avisarle sobre la posibilidad de que se produzca una interrupción en la región primaria.

Como procedimiento recomendado, diseñe la aplicación para comprobar la propiedad

Hora de la última sincronización para evaluar la pérdida de datos esperada. Por ejemplo,
si registra todas las operaciones de escritura, puede comparar la hora de las últimas
operaciones de escritura con la hora de la última sincronización para determinar las
escrituras que no se sincronizaron en la región secundaria.

Seguimiento de las interrupciones

Se puede suscribir al panel de Azure Service Health para hacer el seguimiento del
estado de Azure Files y otros servicios de Azure.

Descripción del proceso de conmutación por

error de una cuenta
La conmutación por error de una cuenta administrada por el cliente le permite
conmutar por error toda una cuenta de almacenamiento en la región secundaria si la
región principal deja de estar disponible por cualquier motivo. Cuando se fuerza una
conmutación por error en la región secundaria, los clientes pueden empezar a escribir
datos en el punto de conexión secundario una vez que se completa la conmutación por
error. Por lo general, la conmutación por error tarda aproximadamente una hora. Se
recomienda suspender la carga de trabajo tanto como sea posible antes de iniciar una
conmutación por error de cuenta.

Para más información sobre cómo iniciar una conmutación por error de una cuenta,
consulte el artículo sobre la iniciación de la conmutación por error de una cuenta.
Funcionamiento de la conmutación por error de una
cuenta
En circunstancias normales, un cliente escribe los datos en una cuenta de
almacenamiento en la región primaria y esos datos se copian de forma asincrónica en la
región secundaria. En la imagen siguiente se muestra el escenario donde está disponible
la región primaria:

Si el punto de conexión principal deja de estar disponible por cualquier motivo, el

cliente ya no puede escribir en la cuenta de almacenamiento. En la imagen siguiente
muestra el escenario en que la región primaria ha dejado de estar disponible, pero
todavía no se ha realizado la recuperación:


El cliente inicia la conmutación por error de la cuenta en el punto de conexión
secundario. El proceso de conmutación por error actualiza la entrada DNS que
proporciona Azure Storage, de modo tal que el punto de conexión secundario se
convierte en el nuevo punto de conexión principal de la cuenta de almacenamiento, tal
como se muestra en la imagen siguiente:

El acceso de escritura se restaura para las cuentas con redundancia geográfica una vez
que la entrada DNS se actualiza y las solicitudes se dirigen al nuevo punto de conexión
principal. Los puntos de conexión de servicio de almacenamiento existentes no cambian
después de la conmutación por error. Los identificadores de archivos y las concesiones
no se conservan en la conmutación por error, por lo que los clientes deben desmontar y
volver a montar los recursos compartidos de archivos.

） Importante

Una vez completada la conmutación por error, la cuenta de almacenamiento se

configura para que sea con redundancia local en el nuevo punto de conexión o
región principal. Para reanudar la replicación en el nuevo punto de conexión
secundario, vuelva a configurar la cuenta para la redundancia geográfica.

Tenga en cuenta que la conversión de una cuenta de almacenamiento con

redundancia local para usar redundancia geográfica conlleva un costo y un tiempo.
Para más información, consulte Implicaciones importantes de la conmutación por
error de la cuenta.

Previsión de la pérdida de datos

 Ｕ Precaución

Por lo general, la conmutación por error de una cuenta implica perder algunos
datos. Es importante entender las implicaciones que tiene iniciar la conmutación
por error de una cuenta.

Como los datos se escriben de forma asincrónica desde la región primaria a la

secundaria, si la región primaria deja de estar disponible, es posible que las escrituras
más recientes aún no se hayan copiado en la región secundaria.

Al forzar una conmutación por error, todos los datos de la región primaria se pierden a
medida que la región secundaria se convierte en la nueva región primaria. La nueva
región primaria está configurada para tener redundancia local después de la
conmutación por error.

Todos los datos ya copiados en la región secundaria se conservan cuando se produce la

conmutación por error. Sin embargo, los datos escritos en la región primaria que no se
hayan copiado en la región secundaria se perderán de forma permanente.

Comprobación de la propiedad Hora de la última

sincronización
La propiedad Last Sync Time (LST) indica la hora más reciente en que se garantiza que
los datos de la región primaria se escribieron en la secundaria. Todos los datos escritos
antes de la última hora de sincronización están disponibles en la base de datos
secundaria, mientras que es posible que los datos escritos después de la última hora de
sincronización no se hayan escrito en la base de datos secundaria y que se pierdan. Use
esta propiedad si se produce una interrupción para calcular la cantidad de datos
perdidos que puede haber al iniciar la conmutación por error de una cuenta.

Para asegurarse de que los recursos compartidos de archivos estén en un estado

coherente cuando se produce una conmutación por error, se crea una instantánea del
sistema en la región primaria cada 15 minutos y se replica en la región secundaria.
Cuando se produce una conmutación por error a la región secundaria, el estado del
recurso compartido se basará en la instantánea del sistema más reciente de la región
secundaria. Si se produce un error en la región primaria, es probable que la región
secundaria esté retrasada en relación con la región primaria, ya que todas las
operaciones de escritura en la primaria no se habrían replicado todavía en la secundaria.
Debido al retraso geográfico u otros problemas, la instantánea del sistema más reciente
de la región secundaria podría ser mayor que 15 minutos.
Todas las operaciones de escritura en la región primaria antes de la LST se han replicado
correctamente en la región secundaria, lo que significa que están disponibles para
leerse desde la región secundaria. Es posible que las operaciones de escritura en la
región primaria, después de la hora de la última sincronización, se hayan replicado o no
en la región secundaria, lo que significa que podrían no estar disponibles para las
operaciones de lectura.

Puede consultar el valor de la propiedad Hora de la última sincronización mediante

Azure PowerShell, la CLI de Azure o la biblioteca cliente. La propiedad Hora de la última
sincronización es un valor de fecha y hora GMT. Para obtener más información, consulte
Comprobación de la propiedad Hora de la última sincronización de una cuenta de
almacenamiento.

Precaución al conmutar por recuperación en la región

primaria original
Como se mencionó anteriormente, después de conmutar por error desde la región
primaria a la secundaria, la cuenta de almacenamiento se configura con redundancia
local en la nueva región primaria. A continuación, puede configurar la cuenta en la
nueva región primaria para la redundancia geográfica. Cuando la cuenta se configura
para usar la redundancia geográfica después de una conmutación por error, la nueva
región primaria empieza de inmediato a copiar los datos en la nueva región secundaria,
que antes de la conmutación por error original era la primaria. Sin embargo, puede
tardar algún tiempo antes de que los datos existentes en la nueva base de datos
principal se copien completamente en la nueva secundaria.

Una vez que la cuenta de almacenamiento se vuelve a configurar para la redundancia

geográfica, es posible iniciar una conmutación por recuperación de la nueva región
primaria a la nueva región secundaria. En este caso, la región primaria original de antes
de la conmutación por error se convierte de nuevo en la región primaria y se configura
para redundancia local o redundancia de zona, en función de si la configuración
primaria original era GRS o GZRS. Todos los datos de la región primaria posterior a la
conmutación por error (la región secundaria original) se pierden durante la conmutación
por recuperación. Si la mayoría de los datos de la cuenta de almacenamiento nunca se
ha copiado en la nueva región secundaria antes de la conmutación por recuperación,
podría ocurrir una pérdida de datos importante.

Para evitar que suceda esto, compruebe el valor de la propiedad Hora de última
sincronización antes de la conmutación por recuperación. Compare la hora de última
sincronización con las últimas horas en que los datos se escribieron en la nueva región
primaria para evaluar la pérdida de datos esperada.
Después de una operación de conmutación por recuperación, puede configurar la nueva
región primaria para redundancia geográfica de nuevo. Si la región primaria original se
configuró para LRS, puede configurarla para que tenga GRS. Si la región primaria
original se configuró para LRS, puede configurarla para que tenga GZRS. Para otras
opciones, consulte Cambio de la forma en que se replica una cuenta de
almacenamiento.

Iniciación de una conmutación por error de la

cuenta
Puede iniciar la conmutación por error de una cuenta desde Azure Portal, PowerShell, la
CLI de Azure o la API de proveedor de recursos de Azure Storage. Para más información
sobre cómo iniciar una conmutación por error, consulte el artículo sobre la iniciación de
la conmutación por error de una cuenta.

Conmutación por error administrada por

Microsoft
En casos extremos en los que se pierde una región debido a un desastre importante,
Microsoft puede iniciar una conmutación por error regional. En este caso, no se
requieren acciones por su parte. No tendrá acceso de escritura a la cuenta de
almacenamiento hasta que se complete la conmutación por error administrada por
Microsoft.

Consulte también
Redundancia de Azure Files
Introducción a la protección de datos de Azure Files
Inicio de una conmutación por error de la cuenta de almacenamiento
Acerca de la copia de seguridad de
recursos compartidos de archivos de
Azure
Artículo • 01/06/2023

La copia de seguridad de recursos compartidos de archivos de Azure es una solución de

copia de seguridad nativa basada en la nube que protege los datos en la nube y elimina
las sobrecargas de mantenimiento adicionales implicadas en las soluciones de copia de
seguridad locales. El servicio Azure Backup se integra completamente con Azure File
Sync y permite centralizar los datos de recursos compartidos de archivos, así como las
copias de seguridad. Esta solución sencilla, confiable y segura le permite configurar la
protección de los recursos compartidos de archivos de su empresa en unos cuantos
pasos fáciles con la garantía de poder recuperar los datos en caso de eliminación
accidental.

Principales ventajas de la copia de seguridad

de recursos compartidos de archivos de Azure
Cero infraestructura: no se necesita ninguna implementación para configurar la
protección de los recursos compartidos de archivos.
Retención personalizada: Puede configurar copias de seguridad con retención
diaria, semanal, mensual o anual según sus requisitos.
Funcionalidades de administración integradas: puede programar copias de
seguridad y especificar el período de retención deseado sin la sobrecarga adicional
de eliminación de datos.
Restauración instantánea: la copia de seguridad de recursos compartidos de
archivos de Azure usa instantáneas de recursos compartidos de archivos, por lo
que puede seleccionar justo los archivos que quiera restaurar al instante.
Alertas e informes: puede configurar alertas para los errores de copia de
seguridad y restauración y usar la solución de generación de informes que se
proporciona en Azure Backup para obtener información sobre las copias de
seguridad en los recursos compartidos de archivos.
Protección contra la eliminación accidental de recursos compartidos de archivos:
Azure Backup habilita la característica de eliminación temporal en el nivel de
cuenta de almacenamiento con un período de retención de 14 días. Incluso si un
actor malintencionado elimina el recurso compartido de archivos, su contenido y
puntos de recuperación (instantáneas) se conservan durante un período de
 retención configurable, lo que permite recuperar correctamente y por completo el
contenido de origen y las instantáneas sin pérdida de datos.
Protección contra la eliminación accidental de instantáneas: Azure Backup
adquiere un contrato de arrendamiento de las instantáneas tomadas por trabajos
de copia de seguridad programados o a petición. La concesión actúa como un
bloqueo que agrega una capa de protección y protege las instantáneas contra la
eliminación accidental.

Architecture

Cómo funciona el proceso de copia de

seguridad
1. El primer paso para configurar la copia de seguridad de recursos compartidos de
archivos de Azure es crear un almacén de Recovery Services. El almacén
proporciona una vista consolidada de las copias de seguridad configuradas en
diferentes cargas de trabajo.

2. Una vez que se crea un almacén, el servicio Azure Backup detecta las cuentas de
almacenamiento que se pueden registrar en él. Puede seleccionar la cuenta de
almacenamiento que hospeda los recursos compartidos de archivos que quiere
proteger.

3. Después de seleccionar la cuenta de almacenamiento, el servicio Azure Backup

muestra el conjunto de recursos compartidos de archivos presentes en ella y
almacena sus nombres en el catálogo de niveles de administración.
 4. Luego, configure la directiva de copia de seguridad (programación y retención)
según sus requisitos y seleccione los recursos compartidos de archivos de los que
quiere realizar una copia de seguridad. El servicio Azure Backup registra las
programaciones en el plano de control para realizar copias de seguridad
programadas.

5. Según la directiva especificada, el programador de Azure Backup desencadena las

copias de seguridad a la hora programada. Como parte de ese trabajo, se crea la
instantánea de recursos compartidos de archivos mediante la API de recurso
compartido de archivos. Solo la dirección URL de la instantánea se almacena en el
almacén de metadatos.

７ Nota

Los datos de los recursos compartidos de archivos no se transfieren al servicio

Azure Backup, dado que este crea y administra las instantáneas que forman
parte de la cuenta de almacenamiento y las copias de seguridad no se
transfieren al almacén.

6. Puede restaurar el contenido de los recursos compartidos de archivos de Azure

(archivos individuales o el recurso compartido completo) de las instantáneas
disponibles en el recurso compartido de archivos de origen. Una vez que se
desencadena la operación, la dirección URL de la instantánea se recupera del
almacén de metadatos y los datos se muestran y transfieren desde la instantánea
de origen al recurso compartido de archivos de destino que elija.

7. Si usa Azure File Sync, el servicio de copia de seguridad indica al servicio Azure File
Sync las rutas de acceso de los archivos que se están restaurando, lo que
desencadena un proceso de detección de cambios en segundo plano en estos
archivos. Los archivos que han cambiado se sincronizan con el punto de conexión
del servidor. Este proceso se produce en paralelo a la restauración original en el
recurso compartido de archivos de Azure.

8. Los datos de supervisión de los trabajos de copia de seguridad y restauración se

insertan en el servicio de supervisión de Azure Backup. Esto le permite supervisar
las copias de seguridad en la nube de los recursos compartidos de archivos en un
único panel. Además, también puede configurar alertas o notificaciones por correo
electrónico cuando resulte afectado el estado de la copia de seguridad. Se envían
correos electrónicos a través del servicio de correo electrónico de Azure.

Costos de la copia de seguridad

Existen dos costos asociados con la solución de copia de seguridad del recurso
compartido de archivos de Azure:

1. Costo del almacenamiento de instantáneas: Los cargos por almacenamiento

incurridos por las instantáneas se facturan junto con el uso de Azure Files según
los detalles de precios que figuran aquí .

2. Cuota de instancia protegida: a partir del 1 de septiembre de 2020, se le cobrará

una cuota de instancia protegida según los detalles de precios . La cuota de
instancia protegida depende del tamaño total de los recursos compartidos de
archivos protegidos en una cuenta de almacenamiento.

Para obtener estimaciones detalladas para realizar copias de seguridad de los recursos
compartidos de archivos de Azure, puede descargar el estimador de precios de Azure
Backup detallado.

¿Cómo funciona la instantánea del tiempo de la

concesión?
Cuando Azure Backup toma una instantánea, programada o a petición, agrega un
bloqueo en la instantánea con la funcionalidad de instantánea de concesión de la
plataforma Archivos. El bloqueo protege las instantáneas de eliminación accidental y la
duración del bloqueo es infinita. Si un archivo compartido tiene instantáneas
concedidas, la eliminación ya no es una operación de un solo clic. Por lo tanto, también
obtiene protección contra la eliminación accidental del recurso compartido de archivos
de copia de seguridad.

Para proteger una instantánea de la eliminación mientras la operación de restauración

está en curso, Azure Backup comprueba el estado de concesión de la instantánea. Si no
está concedida, agrega un bloqueo al tomar un contrato de arrendamiento en la
instantánea.

En el siguiente diagrama se explica el ciclo de vida de la concesión adquirida por Azure

Backup:
Pasos siguientes
Más información sobre cómo realizar copias de seguridad de recursos compartidos
de archivos de Azure.
Encuentre respuestas a las preguntas sobre la copia de seguridad de Azure Files.
Información general de las instantáneas
de recurso compartido de Azure Files
Artículo • 16/10/2023

Azure Files proporciona la capacidad de tomar instantáneas de recursos compartidos de

SMB. Las instantáneas de recursos compartidos capturan el estado del recurso
compartido en ese momento dado. En este artículo se describen las funcionalidades que
proporcionan las instantáneas del recurso compartido de archivos y cómo sacar
provecho de ellas en el caso de uso personalizado.

Las instantáneas de recursos compartidos de archivos NFS se encuentran actualmente

en versión preliminar pública con disponibilidad regional limitada.

Se aplica a
Tipo de recurso compartido de archivos SMB NFS

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS

Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Cuándo usar instantáneas de recursos

compartidos

Error de protección frente a la aplicación y datos dañados

Las aplicaciones que usan recursos compartidos de archivos realizan operaciones tales
como escritura, lectura, almacenamiento, transmisión o procesamiento. Si se
desconfigura una aplicación o se produce un error accidental, es posible que se
produzca una sobrescritura involuntaria o daños en algunos bloques. Para evitar estas
circunstancias, puede tomar una instantánea del recurso compartido antes de
implementar un código de aplicación nuevo. Si se produce un error o hay algún
problema con la aplicación al llevar a cabo la nueva implementación, puede volver a la
versión anterior de los datos de ese recurso compartido de archivos.
Protección frente a eliminaciones accidentales y cambios
no intencionados
Imagine que está trabajando en un archivo de texto en un recurso compartido de
archivos. Una vez que se cierra el archivo de texto pierde la capacidad de deshacer los
cambios. En estos casos, necesitará recuperar una versión anterior del archivo. Gracias a
las instantáneas de recursos compartidos, podrá recuperar versiones anteriores del
archivo si se cambia el nombre o se elimina accidentalmente.

Propósitos generales de copia de seguridad

Después de crear un recurso compartido de archivos, puede crear periódicamente una
instantánea de recurso compartido del recurso compartido de archivos para usarla
como una copia de seguridad de los datos. Si toma instantáneas de recurso compartido
de forma periódica, podrá tener versiones de datos previas y usarlas si son necesarias en
posibles auditorías o en una recuperación ante desastres. Se recomienda usar la copia
de seguridad del recurso compartido de archivos de Azure para tomar y administrar
instantáneas. También puede tomar y administrar instantáneas usted mismo, mediante
Azure Portal, Azure PowerShell o la CLI de Azure.

Capacidades
Una instantánea de recurso compartido es una copia de solo lectura de un momento
dado de sus datos. En el nivel del recurso compartido de archivos se proporciona la
funcionalidad de la instantánea de recurso compartido. La recuperación se ofrece en el
nivel de archivos individuales para permitir la restauración de archivos individuales.
Puede restaurar un recurso compartido de archivos completo mediante el SMB, NFS
(versión preliminar), la API REST, Azure Portal, la biblioteca cliente o con PowerShell o
CLI.

Puede ver las instantáneas de un recurso compartido con la API REST, SMB o NFS
(versión preliminar). Igualmente, puede recuperar la lista de versiones del directorio o
archivo y también puede montar una versión específica directamente como unidad
(disponible solo en Windows: consulte los Límites).

Una vez se crea la instantánea de recurso compartido, puede leerla, copiarla o

eliminarla, pero no modificarla. Recuerde que no puede copiar una instantánea de
recurso compartido completa en otra cuenta de almacenamiento. Si quiere copiarla,
deberá hacerlo archivo por archivo, mediante AzCopy u otros mecanismos de copia.
Una instantánea de recurso compartido de un recurso compartido de archivos es
idéntica a su recurso compartido de archivos base. La única diferencia es que se anexa
un valor DateTime al URI del recurso compartido para indicar el momento en que se
tomó la instantánea de recurso compartido. Por ejemplo, si el URI de un recurso
compartido de archivos es http://storagesample.core.file.windows.net/myshare, el URI
de instantánea es similar a:

http://storagesample.core.file.windows.net/myshare?snapshot=2011-03-
09T01:42:34.9360000Z

Las instantáneas de recurso compartido se conservan hasta que se eliminan

explícitamente. Una instantánea de recurso compartido no puede durar más que su
recurso compartido de archivos base. Puede enumerar las instantáneas asociadas al
recurso compartido de archivos base para llevar a cabo un seguimiento de las
instantáneas actuales.

Cuando crea una instantánea de recurso compartido de un recurso compartido de

archivos, los archivos que se encuentren en las propiedades del sistema del recurso
compartido se copian en la instantánea de recurso compartido con los mismos valores.
Los metadatos del recurso compartido de archivos y los archivos base también se
copian en la instantánea de recurso compartido, a menos que especifique los metadatos
independientes de la instantánea de recurso compartido al crearla.

No puede eliminar un recurso compartido que disponga de instantáneas de recurso

compartido sin antes eliminar todas las instantáneas de ese recurso compartido de
archivos.

Uso del espacio

Las instantáneas de recurso compartido son de naturaleza incremental. Solo se guardan
los datos que hayan cambiado después de realizar la instantánea de recurso compartido
más reciente. Esto minimiza el tiempo necesario para crear la instantánea de recurso
compartido y ahorra en costos de almacenamiento. Cualquier operación de escritura en
el objeto o propiedad o cualquier operación de actualización de metadatos se agrega al
"contenido cambiado" y se guarda en la instantánea de recurso compartido.

Para ahorrar espacio, puede eliminar la instantánea de recurso compartido durante el

periodo en el que la renovación se encuentra en su punto álgido.
Incluso si las instantáneas de recurso compartido se guardan de forma incremental,
solamente deberá guardar la instantánea de recurso compartido más reciente para
poder restaurar el recurso compartido. Cuando elimine una instantánea de recurso
compartido, solo se quitan los datos exclusivos para esa instantánea de recurso
compartido. Las instantáneas activas contienen toda la información necesaria para
examinar y restaurar sus datos (desde el momento en el que se realizó la instantánea de
recurso compartido) en la ubicación original o en una alternativa. Puede restaurarlas en
el nivel de elemento.

Las instantáneas no cuentan para el límite máximo de tamaño de recurso compartido,

que es 100 TiB para recursos compartidos de archivos Premium y recursos compartidos
de archivos estándar con recursos compartidos de archivos grandes habilitados. No hay
ninguna restricción en la cantidad de espacio que ocupan las instantáneas de recurso
compartido. Los límites de cuenta de almacenamiento se siguen aplicando.

Límites
El número máximo de instantáneas de recurso compartido que permite Azure Files
actualmente es de 200 por recurso compartido. Una vez se llegue a las 200 instantáneas
de recurso compartido, tiene que eliminar las más antiguas para poder crear otras
nuevas. Puede conservar instantáneas durante un máximo de 10 años.

No hay ningún límite en las llamadas simultáneas dedicadas a crear instantáneas de

recurso compartido. Asimismo, tampoco hay ningún límite en la cantidad de espacio
que las instantáneas de recurso compartido de un recurso compartido de archivos
determinado pueden consumir.

Las instantáneas de recursos compartidos de archivos NFS se encuentran actualmente

en versión preliminar pública con disponibilidad regional limitada. La versión preliminar
solo admite las API de administración ( AzRmStorageShare ), no las API del plano de datos
( AzStorageShare ), lo que permite a los usuarios crear, listar y eliminar instantáneas de
recursos compartidos de archivos de Azure NFS.

Volver a copiar datos en un recurso compartido

desde una instantánea de recurso compartido
Las operaciones de copia que implican archivos e instantáneas de recurso compartido
siguen estas reglas:

Puede copiar archivos individuales en una instantánea de recurso compartido de

archivos por encima de su recurso compartido base o en cualquier otra ubicación.
Puede restaurar una versión anterior de un archivo o restaurar un recurso compartido
de archivos completo copiando archivo por archivo desde la instantánea de recurso
compartido. La instantánea de recurso compartido no se promociona al recurso
compartido base.

La instantánea de recurso compartido se mantiene intacta después de la operación de

copia, pero el recurso compartido de archivos base se sobrescribe con una copia de los
datos que estaban disponibles en la instantánea de recurso compartido. Todos los
archivos restaurados se tienen en cuenta como "contenido cambiado".

Puede copiar un archivo en una instantánea de recurso compartido en un destino

diferente con un nombre distinto. El archivo de destino resultante es un archivo en el
que se puede escribir y no una instantánea de recurso compartido. En este caso, el
recurso compartido de archivos de base permanecerá intacto.

Cuando un archivo de destino se sobrescribe con una copia, las instantáneas de recurso
compartido asociadas al archivo de destino original no se modifican.

Procedimientos recomendados generales

Automatice las copias de seguridad para la recuperación de datos siempre que sea
posible. Las acciones automatizadas son más fiables que los procesos manuales, lo que
le ayuda a mejorar la recuperabilidad y la protección de datos. Puede usar la copia de
seguridad de recursos compartidos de archivos de Azure, la API REST, el SDK del cliente
o el scripting de automatización.

Antes de implementar el programador de la instantánea de recurso compartido, tenga

en cuenta la frecuencia de la instantánea de recurso compartido y la configuración de
retención para evitar gastos innecesarios.

Las instantáneas de recurso compartido solo proporcionan protección a nivel de

archivo. Recuerde que las instantáneas de recurso compartido no previenen
eliminaciones que se hayan producido por errores involuntarios en un recurso
compartido de archivos o en una cuenta de almacenamiento. Para impedir la
eliminación accidental de una cuenta de almacenamiento, puede habilitar la eliminación
temporal o bloquear la cuenta de almacenamiento o el grupo de recursos.

Consulte también
Trabajo con instantáneas de recurso compartido en:
Copia de seguridad de un recurso compartido de archivos de Azure
Azure PowerShell
CLI de Azure
Windows
Preguntas más frecuentes sobre instantáneas de recurso compartido
Evitar la eliminación accidental de
recursos compartidos de archivos de
Azure
Artículo • 01/06/2023

Azure Files ofrece eliminación temporal para los recursos compartidos de archivos de
SMB. La eliminación temporal permite recuperar el recurso compartido de archivos
cuando una aplicación u otro usuario de la cuenta de almacenamiento lo ha eliminado
por error.

Se aplica a
Tipo de recurso compartido de archivos SMB NFS

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS

Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Cómo funciona la eliminación temporal

Cuando la eliminación temporal de recursos compartidos de archivos de Azure está
habilitada en una cuenta de almacenamiento, si se elimina uno de ellos, realiza la
transición a un estado de eliminación temporal, en lugar de borrarse de forma
permanente. Se puede configurar el tiempo durante el que los datos eliminados de
forma temporal se pueden recuperar antes de que se eliminen permanentemente y
durante este período de retención el recurso compartido se puede recuperar en
cualquier momento. Después de recuperarlo, tanto el recurso compartido como todo su
contenido, incluidas las instantáneas, se restaurarán al estado en que se encontraban
antes de la eliminación. La eliminación temporal solo funciona a nivel de recurso
compartido de archivos (los archivos individuales que se eliminen se borrarán de forma
permanente).

La eliminación temporal se puede habilitar en recursos compartidos de archivos nuevos

o existentes. La eliminación temporal también es compatible con versiones anteriores
por lo que no es necesario realizar ningún cambio en las aplicaciones para aprovechar
las ventajas de las protecciones que se obtienen con esta característica. La eliminación
temporal no funciona con los recursos compartidos de NFS, incluso si está habilitada
para la cuenta de almacenamiento.

Para eliminar de forma permanente un recurso compartido de archivos en un estado de

eliminación temporal antes de su hora de expiración, debe recuperar el recurso
compartido, deshabilitar la eliminación temporal y, después, volver a eliminar el recurso
compartido. Luego, debe volver a habilitar la eliminación temporal, ya que los restantes
recursos compartidos de archivos de esa cuenta de almacenamiento serán vulnerables a
la eliminación accidental mientras la eliminación temporal esté desactivada.

En el caso de los recursos compartidos de archivos Premium eliminados temporalmente,

la cuota de recursos compartidos de archivos (el tamaño aprovisionado de un recurso
compartido de archivos) se usa en el cálculo de la cuota de cuenta de almacenamiento
total hasta la fecha de expiración del recurso compartido con eliminación temporal,
cuando este se elimina de forma completa.

Parámetros de configuración

Habilitación o deshabilitación de la eliminación temporal

La eliminación temporal de recursos compartidos de archivos está habilitada en el nivel
de cuenta de almacenamiento, a causa de ello, la configuración de eliminación temporal
se aplica a todos los recursos compartidos de archivos de una cuenta de
almacenamiento. La eliminación temporal está habilitada de forma predeterminada para
las nuevas cuentas de almacenamiento y se puede deshabilitar o habilitar en cualquier
momento. La eliminación temporal no se habilita automáticamente en las cuentas de
almacenamiento existentes a menos que se haya configurado la copia de seguridad del
recurso compartido de archivos de Azure para un recurso compartido de archivos de
Azure en dicha cuenta de almacenamiento. Si se configuró la copia de seguridad del
recurso compartido de archivos de Azure, la eliminación temporal de estos recursos
compartidos de archivos de Azure se habilita automáticamente en la cuenta de
almacenamiento de ese recurso compartido.

Si habilita la eliminación temporal para recursos compartidos de archivos, elimina

algunos y, después, deshabilita la eliminación temporal, si durante ese período se han
guardado los recursos compartidos, todavía podrá acceder a ellos y recuperarlos. Al
habilitar la eliminación temporal, también debe configurar el período de retención.

Período de retención
El período de retención es la cantidad de tiempo durante el que los recursos
compartidos de archivos eliminados temporalmente se almacenan y están disponibles
para su recuperación. En el caso de los recursos compartidos de archivos que se
eliminan explícitamente, el reloj del período de retención se pone en marcha cuando se
eliminan los datos. Actualmente se puede especificar un periodo de retención que oscile
entre 1 y 365 días. El período de retención de la eliminación temporal se puede cambiar
en cualquier momento. Un período de retención actualizado solo se aplicará a los
recursos compartidos eliminados una vez que se haya actualizado el período de
retención. Los recursos compartidos eliminados antes del período de retención
expirarán en función del período de retención que se ha configurado en el momento de
eliminar los datos.

Precios y facturación
Los recursos compartidos de archivos Estándar y Premium se facturan según la
capacidad usada cuando se han eliminado temporalmente, en lugar de la capacidad
aprovisionada. Además, los recursos compartidos de archivos Premium se facturan
según la tasa de instantáneas mientras se encuentran en el estado de eliminación
temporal. Los recursos compartidos de archivos Estándar se facturan según la tasa
habitual mientras se encuentran en el estado de eliminación temporal. Los datos que se
eliminen permanentemente después del período de retención configurado no se
cobrarán.

Para más información sobre los precios de Azure Files en general, consulte la página de
precios de Azure Files .

Cuando se habilita inicialmente la eliminación temporal, se recomienda usar un período

de retención pequeño para comprender mejor cómo afecta la característica a la
facturación.

Pasos siguientes
Para aprender a habilitar y usar la eliminación temporal, vaya a Habilitación de la
eliminación temporal.

Para obtener información sobre cómo evitar que una cuenta de almacenamiento se
elimine o modifique, consulte Aplicación de un bloqueo de Azure Resource Manager a
una cuenta de almacenamiento.

Para obtener información sobre cómo aplicar bloqueos a recursos y grupos de recursos,
consulte Bloqueo de recursos para evitar cambios inesperados.
Redundancia geográfica de Azure Files
para recursos compartidos de archivos
grandes (versión preliminar)
Artículo • 28/08/2023

La redundancia geográfica de Azure Files para recursos compartidos de archivos

grandes (versión preliminar) mejora significativamente la capacidad y el rendimiento de
los recursos compartidos de archivos SMB estándar al usar las opciones de
almacenamiento con redundancia geográfica (GRS) y almacenamiento con redundancia
de zona geográfica (GZRS).

Durante varios años, Azure Files ha sido compatible con recursos compartidos de
archivos grandes. Esto no solo proporciona una capacidad de recurso compartido de
archivos de hasta 100 TiB, sino que también mejora el rendimiento y las IOPS. En gran
medida, los clientes han adoptado el uso de recursos compartidos de archivos grandes
mediante el almacenamiento con redundancia local (LRS) y almacenamiento con
redundancia de zona (ZRS). No obstante, las opciones de almacenamiento con
redundancia geográfica (GRS) y almacenamiento con redundancia de zona geográfica
(GZRS) no han estado disponibles hasta ahora.

Redundancia geográfica de Azure Files para recursos compartidos de archivos grandes

(la "versión preliminar") está sujeta a los condiciones de uso complementarios para las
versiones preliminares de Microsoft Azure . Puede usar la versión preliminar en
entornos de producción.

Se aplica a
Tipo de recurso compartido de archivos SMB NFS

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS

Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Almacenamiento con redundancia geográfica

Azure mantiene varias copias de los datos para garantizar su durabilidad y alta
disponibilidad. Para protegerse frente a interrupciones regionales, puede configurar la
cuenta de almacenamiento para GRS o GZRS para copiar los datos de forma asincrónica
en dos regiones geográficas separadas por cientos de kilómetros. Esta versión
preliminar agrega la compatibilidad con GRS y GZRS para las cuentas de
almacenamiento estándar que tienen habilitada la característica de recursos
compartidos de archivos grandes.

El almacenamiento con redundancia geográfica (GRS) copia los datos de forma

sincrónica tres veces dentro de una única ubicación física en la región primaria.
Luego copia los datos de forma asincrónica en una única ubicación física en la
región secundaria. Dentro de la región secundaria, los datos se copian de forma
sincrónica tres veces.

El almacenamiento con redundancia de zona geográfica (GZRS) copia los datos

de manera sincrónica en tres zonas de disponibilidad de Azure de la región
primaria. Luego copia los datos de forma asincrónica en una única ubicación física
en la región secundaria. Dentro de la región secundaria, los datos se copian de
forma sincrónica tres veces.

Si la región primaria deja de estar disponible por cualquier motivo, puede iniciar una
conmutación por error de cuenta en la región secundaria.

７ Nota

Azure Files no admite el almacenamiento con redundancia geográfica con acceso

de lectura (RA-GRS) ni el almacenamiento con redundancia de zona geográfica con
acceso de lectura (RA-GZRS). Si una cuenta de almacenamiento está configurada
para usar RA-GRS o RA-GZRS, los recursos compartidos de archivos se configurarán
como GRS o GZRS. Los recursos compartidos de archivos no serán accesibles en la
región secundaria a menos que se produzca una conmutación por error.

Límites de recursos compartidos de archivos

grandes
La habilitación de los recursos compartidos de archivos grandes, al usar el
almacenamiento con redundancia geográfica (GRS) y el almacenamiento con
redundancia de zona geográfica (GZRS), aumenta significativamente los límites de
capacidad y rendimiento de los recursos compartidos de archivos estándar:
 Atributo Límite Límite de recursos compartidos de
actual archivos grandes

Capacidad por recurso compartido 5 TiB 100 TiB (aumento de 20 veces)

Máximo de IOPS por recurso 1000 IOPS 20 000 IOPS (aumento de 20 veces)
compartido

Rendimiento máximo por recurso Up to 60 Hasta el límite de la cuenta de

compartido MiB/s almacenamiento

Disponibilidad en regiones
Actualmente, la versión preliminar de redundancia geográfica para recursos
compartidos de archivos grandes de Azure Files está disponible en las siguientes
regiones:

Centro de Australia
Centro de Australia 2
Este de Australia
Sudeste de Australia
Sur de Brasil
Sur de Brasil
Centro de Canadá
Este de Canadá
Centro de la India
Centro de EE. UU.
Este de China 2
Este de China 3
Norte de China 2
Norte de China 3
Este de Asia
Este de EE. UU.
Este de EE. UU. 2
Centro de Francia
Sur de Francia
Norte de Alemania
Centro-oeste de Alemania
Japón Oriental
Japón Occidental
Centro de Corea del Sur
Corea del Sur
 Centro-Norte de EE. UU
Norte de Europa
Este de Noruega
Oeste de Noruega
Norte de Sudáfrica
Oeste de Sudáfrica
Centro-sur de EE. UU.
Sur de la India
Sudeste de Asia
Centro de Suecia
Sur de Suecia
Norte de Suiza
Oeste de Suiza
Centro de Emiratos Árabes Unidos
Norte de Emiratos Árabes Unidos
Sur de Reino Unido
Oeste de Reino Unido
US Gov: Arizona
US Gov Texas
US Gov - Virginia
Centro-Oeste de EE. UU.
Oeste de Europa
Oeste de la India
Oeste de EE. UU.
Oeste de EE. UU. 2
Oeste de EE. UU. 3

Precios
Los precios se basan en el nivel de recurso compartido de archivos estándar y la opción
de redundancia configurada para la cuenta de almacenamiento. Para más información,
consulte precios de Azure Files .

Registro para obtener la versión preliminar

Para empezar, regístrese para la versión preliminar mediante Azure Portal o PowerShell.

Azure Portal

1. Inicie sesión en Azure Portal .

 2. Busque y seleccione Características en versión preliminar.
3. Haga clic en el filtro Tipo y seleccione Microsoft.Storage.
4. Seleccione Versión preliminar de redundancia geográfica para recursos
compartidos de archivos grandes de Azure Files y haga clic en Registrar.

Habilitación de la redundancia geográfica y

recursos compartidos de archivos grandes para
los recursos compartidos de archivos de SMB
estándar
Con la versión preliminar de redundancia geográfica para recursos compartidos de
archivos grandes de Azure Files, puede habilitar la redundancia geográfica y los recursos
compartidos de archivos grandes para los recursos compartidos de archivos de SMB
estándar nuevos y existentes.

Creación de una nueva cuenta de almacenamiento y un

recurso compartido de archivos
Realice los pasos siguientes para configurar la redundancia geográfica y los recursos
compartidos de archivos grandes para un nuevo recurso compartido de archivos de
Azure.

1. Cree una cuenta de almacenamiento estándar.

Seleccione almacenamiento con redundancia geográfica (GRS) o

almacenamiento con redundancia de zona geográfica (GZRS) para la opción
Redundancia.
En la sección Opciones avanzadas, seleccione Habilitar recursos compartidos
de archivos grandes.

2. Cree un recurso compartido de archivos SMB de Azure.

Cuentas de almacenamiento y recursos compartidos de

archivos existentes
Los pasos para habilitar la redundancia geográfica para los recursos compartidos de
archivos grandes variarán en función de la opción de redundancia configurada
actualmente para la cuenta de almacenamiento. Siga los pasos que se indican a
continuación en función de la opción de redundancia adecuada para la cuenta de
almacenamiento.

Cuentas de almacenamiento existentes con una opción de

redundancia de LRS o ZRS
1. Cambie la opción de redundancia de la cuenta de almacenamiento a GRS o GZRS.
2. Compruebe que la configuración de recursos compartidos de archivos grandes
está habilitada en la cuenta de almacenamiento.
3. Opcional:aumente la cuota del recurso compartido de archivos hasta 100 TiB.

Cuentas de almacenamiento existentes con una opción de

redundancia de GRS, GZRS, RA-GRS o RA-GZRS

1. Habilite la configuración de recursos compartidos de archivos grandes en la cuenta

de almacenamiento.
2. Opcional:aumente la cuota del recurso compartido de archivos hasta 100 TiB.

Frecuencia de instantánea y sincronización

Para asegurarse de que los recursos compartidos de archivos estén en un estado
coherente cuando se produce una conmutación por error, se crea una instantánea del
sistema en la región primaria cada 15 minutos y se replica en la región secundaria.
Cuando se produce una conmutación por error a la región secundaria, el estado del
recurso compartido se basará en la instantánea del sistema más reciente de la región
secundaria. Debido al retraso geográfico u otros problemas, la instantánea del sistema
más reciente de la región secundaria puede ser mayor de 15 minutos.

La propiedad Hora de la última sincronización (LST) de la cuenta de almacenamiento

indica la hora más reciente en que los datos de la región primaria se escribieron
correctamente en la secundaria. Para Azure Files, la hora de la última sincronización se
basa en la instantánea del sistema más reciente de la región secundaria. Puede usar
PowerShell o la CLI de Azure para comprobar la hora de la última sincronización de una
cuenta de almacenamiento.

Es importante comprender lo siguiente sobre la propiedad Hora de la última

sincronización:

La propiedad Hora de la última sincronización de la cuenta de almacenamiento se

basa en el servicio (archivos, blobs, tablas, colas) de la cuenta de almacenamiento
que está más lejos.
 La hora de la última sincronización no se actualiza si no se han realizado cambios
en la cuenta de almacenamiento.
El cálculo de hora de la última sincronización puede agotar el tiempo de espera si
el número de recursos compartidos de archivos supera los 100 por cuenta de
almacenamiento. Se recomienda menos de 100 recursos compartidos de archivos
por cuenta de almacenamiento.

Consideraciones sobre la conmutación por

error
En esta sección, se enumeran las consideraciones que podrían afectar a la capacidad de
conmutar por error a la región secundaria.

La conmutación por error de la cuenta de almacenamiento se bloqueará si no

existe una instantánea del sistema en la región secundaria.

Los identificadores de archivo y las concesiones no se conservan en la

conmutación por error y los clientes deben desmontar y volver a montar los
recursos compartidos de archivos.

La cuota del recurso compartido de archivos puede cambiar después de la

conmutación por error. La cuota del recurso compartido de archivos en la región
secundaria se basará en la cuota que se ha configurado cuando se ha capturado la
instantánea del sistema en la región primaria.

Las operaciones de copia en curso se anularán cuando se produzca una

conmutación por error. Cuando se complete la conmutación por error en la región
secundaria, vuelva a intentar la operación de copia.

Para probar la conmutación por error de la cuenta de almacenamiento, consulte Iniciar

una conmutación por error de cuenta.

Consulte también
Recuperación ante desastres y conmutación por error de la cuenta de
almacenamiento
Descripción del rendimiento de Azure
Files
Artículo • 20/07/2023

Azure Files puede satisfacer los requisitos de rendimiento de la mayoría de las

aplicaciones y casos de uso. En este artículo se explican los distintos factores que
pueden afectar al rendimiento del recurso compartido de archivos y cómo optimizar el
rendimiento de los recursos compartidos de archivos de Azure para la carga de trabajo.

Se aplica a
Tipo de recurso compartido de archivos SMB NFS

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS

Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Glosario
Antes de leer este artículo, resulta útil comprender algunos términos clave relacionados
con el rendimiento del almacenamiento:

Operaciones de E/S por segundo (IOPS)

IOPS u operaciones de entrada/salida por segundo, mide el número de

operaciones del sistema de archivos por segundo. En la documentación de Azure
Files, el término "E/S" es un sinónimo de los términos "operación" y "transacción".

Tamaño de E/S

El tamaño de E/S, a veces denominado tamaño de bloque, es el tamaño de la

solicitud que una aplicación usa para realizar una única operación de
entrada/salida (E/S) en el almacenamiento. En función de la aplicación, el tamaño
de E/S puede variar de tamaños muy pequeños, como 4 KiB, a tamaños mucho
mayores. El tamaño de E/S desempeña un papel importante en el rendimiento
factible.

Rendimiento
 El rendimiento mide el número de bits leídos o escritos en el almacenamiento por
segundo y se mide en mebibytes por segundo (MiB/s). Para calcular el
rendimiento, multiplique las IOPS por el tamaño de E/S. Por ejemplo, 10 000 IOPS *
1 MiB de tamaño de E/S = 10 GiB/s, mientras que 10 000 IOPS * 4 KiB de tamaño
de E/S = 38 MiB/s.

Latency

La latencia es un sinónimo de retraso y normalmente se mide en milisegundos

(ms). Hay dos tipos de latencia: de un extremo a otro y del servicio. Para obtener
más información, vea latencia.

Profundidad de la cola

La profundidad de la cola es el número de solicitudes de E/S pendientes que un

recurso de almacenamiento puede controlar en cualquier momento. Para obtener
más información, vea Profundidad de la cola.

Elección de un nivel de rendimiento basado en

patrones de uso
Azure Files proporciona una variedad de niveles de almacenamiento que ayudan a
reducir los costos al permitirle almacenar datos en el nivel adecuado de rendimiento y
precio. En el nivel más elevado, Azure Files ofrece dos niveles de rendimiento: Estándar y
Premium. Los recursos compartidos de archivos Estándar se hospedan en un sistema de
almacenamiento respaldado por unidades de disco duro (HDD), mientras que los
recursos compartidos de archivos Premium están respaldados por unidades de estado
sólido (SSD) para mejorar el rendimiento. Los recursos compartidos de archivos Estándar
tienen varios niveles de almacenamiento (optimizados para transacciones, frecuente y
esporádico) entre los que puede moverse sin problemas a fin de maximizar los datos en
reposo y los precios de transacción. Pero no puede moverse entre los niveles Estándar y
Premium sin migrar físicamente los datos entre diferentes cuentas de almacenamiento.

Al elegir entre recursos compartidos de archivos Estándar y Premium, es importante

comprender los requisitos del patrón de uso esperado que tiene previsto ejecutar en
Azure Files. Si necesita grandes cantidades de IOPS, velocidades de transferencia de
datos extremadamente rápidas o una latencia muy baja, debe elegir recursos
compartidos de archivos de Azure Premium.

En la tabla siguiente se resumen los objetivos de rendimiento esperados entre los

recursos Estándar y Premium. Para obtener más información, vea Objetivos de
escalabilidad y rendimiento de Azure Files.
 Requisitos del patrón de uso Estándar Premium

Latencia de escritura (milisegundos de un solo dígito) Sí Sí

Latencia de lectura (milisegundos de un solo dígito) No Sí

Los recursos compartidos de archivos Premium ofrecen un modelo de

aprovisionamiento que garantiza el perfil de rendimiento siguiente en función del
tamaño del recurso compartido. Para obtener más información, vea Modelo
aprovisionado. Cada vez que el tráfico para el recurso compartido de archivos se
encuentra por debajo del valor de IOPS de la línea base, se acumulan créditos de ráfaga
en un cubo de ráfagas. Los créditos obtenidos se usan más adelante para habilitar la
expansión cuando las operaciones superen la IOPS de línea base.

Capacidad IOPS IOPS de Créditos de Rendimiento (entrada +

(GiB) base ráfaga ráfaga salida)

100 3100 Hasta 10 000 24 840 000 110 MiB/s

500 3500 Hasta 10 000 23 400 000 150 MiB/s

1024 4 024 Hasta 10 000 21 513 600 203 MiB/s

5120 8120 Hasta 15 360 26 064 000 613 MiB/s

10 240 13 240 Hasta 30 720 62 928 000 1125 MiB/s

33 792 36 792 Hasta 100 000 227 548 800 3480 MiB/s

51 200 54 200 Hasta 100 000 164 880 000 5220 MiB/s

102 400 100 000 Hasta 100 000 0 10 340 MiB/s

Azure Database for PostgreSQL: Lista de comprobación

de rendimiento
Si va a evaluar los requisitos de rendimiento de una carga de trabajo nueva o existente,
comprender los patrones de uso le permitirá lograr un rendimiento predecible. Consulte
con el administrador de almacenamiento o el desarrollador de aplicaciones para
determinar los patrones de uso siguientes.

Sensibilidad de latencia: ¿los usuarios abren archivos o interactúan con escritorios

virtuales que se ejecutan en Azure Files? Estos son ejemplos de cargas de trabajo
que son sensibles a la latencia de lectura y que también tienen alta visibilidad para
los usuarios finales. Estos tipos de cargas de trabajo son más adecuados para los
recursos compartidos de archivos Premium de Azure, que pueden proporcionar
 una latencia de milisegundos para las operaciones de lectura y escritura (< 2 ms
para tamaño de E/S pequeño).

Requisitos de IOPS y rendimiento: los recursos compartidos de archivos Premium

admiten mayores límites de IOPS y rendimiento que los recursos compartidos de
archivos estándar. Consulte Destinos de escalado de recursos compartidos de
archivos para obtener más información.

Duración y frecuencia de la carga de trabajo: es menos probable que las cargas

de trabajo cortas (minutos) y poco frecuentes (por hora) logren los límites de
rendimiento superiores de los recursos compartidos de archivos Estándar en
comparación con las cargas de trabajo que se producen con frecuencia. En los
recursos compartidos de archivos Premium, la duración de la carga de trabajo es
útil al determinar el perfil de rendimiento correcto que se va a usar en función del
tamaño de aprovisionamiento. En función del tiempo que necesite expandirse la
carga de trabajo y el tiempo que tarda por debajo de las IOPS de línea base, puede
determinar si va a acumular suficientes créditos de ráfaga para satisfacer
constantemente la carga de trabajo en horas punta. La búsqueda del equilibrio
correcto reducirá los costos en comparación con el exceso de aprovisionamiento
del recurso compartido de archivos. Un error común consiste en ejecutar pruebas
de rendimiento solo unos minutos, lo que a menudo es engañoso. Para obtener
una vista realista del rendimiento, asegúrese de probar con una frecuencia y una
duración suficientemente altas.

Paralelización de cargas de trabajo: en el caso de las cargas de trabajo que

realizan operaciones en paralelo, como a través de varios subprocesos, procesos o
instancias de aplicación en el mismo cliente, los recursos compartidos de archivos
premium proporcionan una ventaja clara sobre los recursos compartidos de
archivos estándar: SMB multicanal. Consulte SMB multicanal para obtener más
información.

Distribución de operaciones de API: ¿los metadatos de la carga de trabajo son

pesados con las operaciones de apertura y cierre de archivos? Esto es habitual para
las cargas de trabajo que realizan operaciones de lectura en un número elevado de
archivos. Consulte Carga de trabajo pesada del espacio de nombres o los
metadatos.

Latencia
Al pensar en la latencia, es importante comprender primero cómo se determina esta con
Azure Files. Las medidas más comunes son la latencia asociada a las métricas de latencia
de un extremo a otro y latencia del servicio. El uso de estas métricas de transacción
puede ayudar a identificar problemas de latencia o de redes del lado cliente al
determinar el tiempo que pasa el tráfico de la aplicación en tránsito hacia el cliente y
desde este.

La latencia de un extremo a otro (SuccessE2ELatency) es el tiempo total que tarda

una transacción en realizar un recorrido de ida y vuelta completo desde el cliente,
por la red, al servicio Azure Files y de vuelta al cliente.

La latencia del servicio (SuccessServerLatency) es el tiempo que tarda una

transacción en realizar un recorrido de ida y vuelta solo dentro del servicio Azure
Files. Esto no incluye ninguna latencia de red o cliente.

La diferencia entre los valores de SuccessE2ELatency y SuccessServerLatency es la

latencia que probablemente provocan la red y el cliente.

Es habitual confundir la latencia del cliente con la latencia del servicio (en este caso, el
rendimiento de Azure Files). Por ejemplo, si la latencia del servicio notifica baja latencia y
la de un extremo a otro notifica una latencia muy alta para las solicitudes, eso sugiere
que todo el tiempo se invierte en el tránsito hacia el cliente y desde este, y no en el
servicio Azure Files.

Además, tal como se muestra en el diagrama, cuanto más lejos esté del servicio, más
lenta será la experiencia de latencia y más difícil será alcanzar límites de escalado de
rendimiento con cualquier servicio en la nube. Esto sucede especialmente al acceder a
Azure Files desde el entorno local. Aunque las opciones como ExpressRoute son ideales
para el entorno local, siguen sin coincidir con el rendimiento de una aplicación (proceso
y almacenamiento) que se ejecuta exclusivamente en la misma región de Azure.

 Sugerencia
 El uso de una máquina virtual en Azure para probar el rendimiento entre el entorno
local y Azure es una manera eficaz y práctica de establecer como base las
capacidades de red de la conexión a Azure. A menudo, un circuito ExpressRoute o
una puerta de enlace de VPN con un tamaño insuficiente o incorrectamente
enrutado puede ralentizar una carga de trabajo.

Profundidad de la cola
La profundidad de la cola es el número de solicitudes de E/S pendientes que un recurso
de almacenamiento puede atender. A medida que los discos que usan los sistemas de
almacenamiento han evolucionado de los ejes HDD (IDE, SATA, SAS) a los dispositivos
de estado sólido (SSD, NVMe), también han evolucionado para admitir una mayor
profundidad de cola. Un ejemplo de profundidad de cola baja consiste en una carga de
trabajo que consta de un único cliente que interactúa en serie con un único archivo
dentro de un conjunto de datos grande. Por el contrario, una carga de trabajo que
admite paralelismo con varios subprocesos y varios archivos puede lograr fácilmente
una profundidad de cola alta. Dado que Azure Files es un servicio de archivos
distribuido que abarca miles de nodos de clúster de Azure y está diseñado para ejecutar
cargas de trabajo a gran escala, se recomienda compilar y probar cargas de trabajo con
una profundidad de cola alta.

La profundidad de cola alta se puede alcanzar de varias maneras diferentes en

combinación con clientes, archivos y subprocesos. Para determinar la profundidad de
cola de la carga de trabajo, multiplique el número de clientes por el número de archivos
y por el número de subprocesos (clientes * archivos * subprocesos = profundidad de
cola).

En la tabla siguiente se muestran las distintas combinaciones que puede usar para
lograr una mayor profundidad de cola. Aunque puede superar la profundidad de cola
óptima de 64, esta opción no se recomienda. Si lo hace, no observará más mejoras en el
rendimiento y corre el riesgo de aumentar la latencia debido a la saturación de TCP.

Clientes Archivos Subprocesos Profundidad de la cola

1 1 1 1

1 1 2 2

1 2 2 4

2 2 2 8

2 2 4 16
 Clientes Archivos Subprocesos Profundidad de la cola

2 4 4 32

1 8 8 64

4 4 2 64

 Sugerencia

Para lograr límites de rendimiento superiores, asegúrese de que la carga de trabajo

o la prueba de punto de referencia sea de varios subprocesos con varios archivos.

Aplicaciones de un solo subproceso frente a

varios subprocesos
Azure Files es más adecuado para aplicaciones de varios subprocesos. La manera más
fácil de comprender el impacto en el rendimiento que tiene la opción de varios
subprocesos en una carga de trabajo es recorrer el escenario con E/S. En el ejemplo
siguiente, tenemos una carga de trabajo que necesita copiar 10 000 archivos pequeños
lo antes posible hacia un recurso compartido de archivos de Azure o desde este.

En esta tabla se desglosa el tiempo necesario (en milisegundos) para crear un único
archivo de 16 KiB en un recurso compartido de archivos de Azure, basado en una
aplicación de un solo subproceso que escribe en tamaños de bloque de 4 KiB.

Operación de Crear Escritura de Escritura de Escritura de Escritura de Close Total

E/S 4 KiB 4 KiB 4 KiB 4 KiB

Subproceso 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

En este ejemplo, tardaría aproximadamente 14 ms en crear un único archivo de 16 KiB a

partir de las seis operaciones. Si una aplicación de un solo subproceso quiere mover
10 000 archivos a un recurso compartido de archivos de Azure, esto supondría
140 000 ms (14 ms * 10 000) o 140 segundos, porque cada archivo se mueve
secuencialmente de uno en uno. Tenga en cuenta que el tiempo de servicio de cada
solicitud lo determina principalmente la proximidad entre el proceso y el
almacenamiento, tal como se describe en la sección anterior.

Al usar ocho subprocesos en lugar de uno, la carga de trabajo anterior se puede reducir
de 140 000 ms (140 segundos) hasta 17 500 ms (17,5 segundos). Tal como se muestra
en la tabla siguiente, cuando se mueven ocho archivos en paralelo en lugar de hacerlo
de uno en uno, puede mover la misma cantidad de datos empleando un 87,5 % menos
de tiempo.

Operación de Crear Escritura de Escritura de Escritura de Escritura de Close Total

E/S 4 KiB 4 KiB 4 KiB 4 KiB

Subproceso 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Subproceso 2 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Subproceso 3 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Subproceso 4 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Subproceso 5 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Subproceso 6 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Subproceso 7 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Subproceso 8 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Vea también
Solución de problemas de rendimiento de recursos compartidos de archivos de
Azure
Supervisión de Azure Files
Planeamiento de una implementación de Azure Files
Descripción de la facturación de Azure Files
Precios de Azure Files
Mejora del rendimiento del recurso compartido
de archivos de Azure SMB
Artículo • 03/09/2023

En este artículo se explica cómo puede mejorar el rendimiento de los recursos compartidos de archivos de
Azure SMB, incluido el uso de SMB multicanal.

Se aplica a
Tipo de recurso compartido de archivos SMB NFS

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS

Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Optimización del rendimiento

Las siguientes sugerencias pueden ayudarte a optimizar el rendimiento:

Asegúrese de que la cuenta de almacenamiento y el cliente se colocan en la misma región de Azure

para reducir la latencia de red.
Use aplicaciones multiproceso y distribuya la carga entre varios archivos.
Las ventajas de rendimiento de SMB multicanal aumentan con el número de archivos que distribuyen la
carga.
El rendimiento del recurso compartido Premium está limitado por el tamaño del recurso compartido
aprovisionado (IOPS/salida/entrada) y los límites de un solo archivo. Para obtener detalles, consulte
Descripción del aprovisionamiento de recursos compartidos de archivos Premium.
El rendimiento máximo de un solo cliente de VM sigue estando enlazado a los límites de máquina
virtual. Por ejemplo, Standard_D32s_v3 puede admitir un ancho de banda máximo de 16 000 MBps (o
2 GBps), la salida de la máquina virtual (escrituras en el almacenamiento) se mide, la entrada (lecturas
del almacenamiento) no. El rendimiento de los recursos compartidos de archivos está sujeto a los
límites de red de la máquina, las CPU, el almacenamiento interno, el ancho de banda de red disponible,
los tamaños de E/S, el paralelismo, así como otros factores.
La prueba inicial suele ser una preparación. Descarte los resultados y repita la prueba.
Si el rendimiento está limitado por un solo cliente y la carga de trabajo sigue estando por debajo de los
límites de cuota provisionados, puede conseguir un mayor rendimiento repartiendo la carga entre
varios clientes.

La relación entre IOPS, el rendimiento y los tamaños de E/S

Rendimiento = tamaño de E/S * IOPS

Cuanto mayor sea el tamaños de E/S mayores serán el rendimiento y las latencias, lo que dará lugar a un
número menor de IOPS de red. Los tamaños de E/S menores aumentarán la IOPS, pero provocarán unas
latencias y un rendimiento menores. Para más información, consulte Descripción del rendimiento de Azure
Files.
SMB multicanal
SMB multicanal permite que un cliente SMB 3.x establezca varias conexiones de red a un recurso compartido
de archivos SMB. Azure Files admite SMB multicanal en recursos compartidos de archivos premium (recursos
compartidos de archivos en el tipo de cuenta de almacenamiento FileStorage) para clientes de Windows. En
el lado del servicio, el SMB multicanal está deshabilitado de forma predeterminada en Azure Files, pero no
hay ningún costo adicional por habilitarlo.

Ventajas
SMB multicanal permite a los clientes usar varias conexiones de red que proporcionan un mayor rendimiento
a la vez que se reduce el costo de propiedad. El mayor rendimiento se logra a través de la agregación de
ancho de banda en varias NIC y el uso de la compatibilidad con Ajuste de escala en lado de recepción (RSS)
para que las NIC distribuyan la carga de E/S entre varias CPU.

Rendimiento aumentado: varias conexiones permiten la transferencia de los datos a través de varias
rutas de acceso en paralelo y, por tanto, benefician significativamente a las cargas de trabajo que usan
tamaños de archivo más grandes con tamaños de E/S más grandes, y requieren un alto rendimiento de
una sola máquina virtual o un conjunto de máquinas virtuales más pequeño. Entre algunas de estas
cargas de trabajo se incluyen medios y entretenimiento para la creación de contenido o la
transcodificación, la genómica y el análisis de riesgos de servicios financieros.
E/S por segundo más alta: la funcionalidad RSS de NIC permite una distribución de carga eficaz entre
varias CPU con varias conexiones. Esto ayuda a lograr una escala de IOPS más alta y un uso eficaz de las
CPU de VM. Esto es útil para las cargas de trabajo que tienen tamaños de E/S pequeños, como las
aplicaciones de base de datos.
Tolerancia a los fallos de la red: varias conexiones mitigan el riesgo de interrupción, ya que los clientes
ya no dependen de una conexión individual.
Configuración automática: cuando SMB multicanal está habilitado en los clientes y las cuentas de
almacenamiento, permite la detección dinámica de las conexiones existentes y puede crear rutas de
acceso de conexión adicionales según sea necesario.
Optimización de costos: las cargas de trabajo pueden alcanzar una mayor escala de una sola máquina
virtual o un conjunto pequeño de máquinas virtuales mientras se conectan a recursos compartidos
Premium. Esto podría reducir el costo total de propiedad al reducir el número de máquinas virtuales
necesarias para ejecutar y administrar una carga de trabajo.

Para obtener más información sobre SMB multicanal, consulte la documentación de Windows.

Esta característica proporciona mayores ventajas de rendimiento a las aplicaciones multiproceso, pero
normalmente no ayuda a las aplicaciones de un único subproceso. Consulte la sección Comparación del
rendimiento para obtener más detalles.

Limitaciones
SMB multicanal para los recursos compartido de archivos de Azure tiene actualmente las siguientes
restricciones:

Solo se admite en clientes de Windows que utilizan SMB 3.1.1. Asegúrese de que los sistemas
operativos cliente de SMB tengan las revisiones aplicadas hasta los niveles recomendados.
Actualmente no se admite ni se recomienda para los clientes de Linux.
El número máximo de canales es cuatro. Para más información, consulte este artículo.
Configuración
SMB multicanal solo funciona cuando la característica está habilitada tanto en el lado del cliente (su cliente)
como en el lado del servicio (su cuenta de almacenamiento de Azure).

En los clientes Windows, SMB multicanal está habilitado de manera predeterminada. Puede comprobar la
configuración ejecutando el siguiente comando de PowerShell:

PowerShell

Get-SmbClientConfiguration | Select-Object -Property EnableMultichannel

En la cuenta de almacenamiento de Azure, deberás habilitar SMB multicanal. Consulte Implementación de

SMB multicanal.

Deshabilitar SMB multicanal

En la mayoría de los escenarios, concretamente las cargas de trabajo multiproceso, los clientes deben ver un
rendimiento mejorado con SMB multicanal. Sin embargo, algunos escenarios específicos, como las cargas de
trabajo con un único subproceso o con fines de prueba, es posible que desee deshabilitar el SMB multicanal.
Consulte Comparación del rendimiento para obtener más detalles.

Comprobar que SMB multicanal está configurado correctamente

1. Crea un nuevo recurso compartido de archivos premium o use uno premium existente.
2. Asegúrese de que el cliente admite SMB multicanal (uno o varios adaptadores de red tienen habilitado
el ajuste de escala en lado de recepción). Consulte la documentación de Windows para obtener más
detalles.
3. Monte un recurso compartido de archivos en el cliente.
4. Genere carga con la aplicación. Una herramienta de copia como robocopy o MT, o bien cualquier
herramienta de rendimiento como Deskspd para archivos de lectura/escritura, pueden generar carga.
5. Abra PowerShell como administrador y use el siguiente comando: Get-SmbMultichannelConnection |fl
6. Busque las propiedades MaxChannels y CurrentChannels.

Comparación del rendimiento

Hay dos categorías de patrones de carga de trabajo de lectura/escritura: de un único subproceso y
multiproceso. La mayoría de las cargas de trabajo usan varios archivos, pero podría haber casos de uso
específicos en los que la carga de trabajo funcione con un solo archivo en un recurso compartido. En esta
sección se tratan diversos casos de uso y el impacto en el rendimiento de cada uno de ellos. En general, la
mayoría de las cargas de trabajo son multiproceso y distribuyen la carga de trabajo por varios archivos, por
lo que deberían poder observar mejoras significativas en el rendimiento con SMB multicanal.

Varios archivos/Multiproceso: según el patrón de carga de trabajo, deberías poder observar una
mejora significativa en el rendimiento en E/S de lectura y escritura a través de varios canales. Las
mejoras de rendimiento varían desde cualquier punto entre 2x y 4x en términos de IOPS, rendimiento y
latencia. En esta categoría, SMB multicanal debe habilitarse para obtener el mejor rendimiento.
Un solo archivo/Multiproceso: en la mayoría de los casos de uso de esta categoría, las cargas de
trabajo se beneficiarán de tener habilitado SMB multicanal, especialmente si la carga de trabajo tiene
un tamaño medio de E/S > ~16 k. Algunos escenarios de ejemplo que se benefician de SMB multicanal
son la copia de seguridad o la recuperación de un solo archivo grande. Una excepción en la que es
posible que desees deshabilitar SMB multicanal es si tu carga de trabajo es pesada en E/S pequeñas. En
ese caso, tal vez observes una ligera pérdida de rendimiento (10 %). Dependiendo del caso de uso,
considere la posibilidad de distribuir la carga entre varios archivos o deshabilitar la característica.
Consulte la sección Configuración para obtener más información.
Varios archivos o un solo archivo/Multiproceso: en la mayoría de las cargas de trabajo de un único
subproceso, existen unas ventajas de rendimiento mínimas debido a la falta de paralelismo. Por lo
general, hay una ligera degradación del rendimiento de ~10 % si el SMB multicanal está habilitado. En
este caso, es ideal deshabilitar SMB multicanal, con una excepción. Si la carga de trabajo de un único
subproceso puede distribuir la carga entre varios archivos y usa un tamaño medio de E/S más grande
(> ~16 k), deben existir unas ventajas de rendimiento mínimas del SMB multicanal.

Configuración de prueba de rendimiento

En los gráficos de este artículo, se usó la siguiente configuración: una sola máquina virtual D32s v3 Estándar
con una sola NIC habilitada para RSS con cuatro canales. La carga se generó mediante diskspd.exe,
multiproceso con una profundidad de E/S de 10 y E/S aleatorias con diversos tamaños de E/S.

Size vCPU Memoria: GiB de Discos Rendimiento Rendimiento Nº Ancho

GiB almacenamiento de máximo de máximo del máx. de
temporal (SSD) datos almacenamiento disco sin NIC banda
máx. temporal y en almacenamiento de red
caché: en la caché: esperado
IOPS/Mbps IOPS/Mbps (Mbps)
(tamaño de
caché en GiB)

Standard_D32s_v3 32 128 256 32 64000/512 (800) 51200/768 8 16000

Multihilo/múltiples archivos con SMB Multicanal

La carga se realizó con respecto a 10 archivos con diversos tamaños de E/S. Los resultados de la prueba de
escalado vertical mostraron mejoras significativas en los resultados de la prueba de rendimiento e IOPS con
SMB multicanal habilitado. En los diagramas siguientes se describen los resultados:
 

En una sola NIC, en el caso de las lecturas, el rendimiento aumentó entre el doble y el triple, mientras
que en el caso de las escrituras, una mejora en términos de IOPS y rendimiento se multiplicó por 3 y
hasta por 4.
SMB multicanal permitió que IOPS y el rendimiento alcanzaran los límites de VM incluso con una sola
NIC y el límite de cuatro canales.
Dado que la salida (o las lecturas en el almacenamiento) no se mide, el rendimiento de lectura pudo
superar el límite publicado de VM de 16 000 Mbps (2 GiB/s). La prueba alcanzó >2,7 GiB/s. La entrada
(o las escrituras en el almacenamiento) sigue estando sujeta a límites de VM.
Distribución de la carga por varios archivos permitidos para mejoras sustanciales.

Un comando de ejemplo utilizado en esta prueba es:

diskspd.exe -W300 -C5 -r -w100 -b4k -t8 -o8 -Sh -d60 -L -c2G -Z1G z:\write0.dat z:\write1.dat

z:\write2.dat z:\write3.dat z:\write4.dat z:\write5.dat z:\write6.dat z:\write7.dat z:\write8.dat

z:\write9.dat .

Cargas de trabajo multiproceso o de un solo archivo con SMB

multicanal
La carga se realizó con respecto a un solo archivo de 128 GiB. Con SMB multicanal habilitado, la prueba de
escalado vertical con archivos multiproceso o únicos mostró mejoras en la mayoría de los casos. En los
diagramas siguientes se describen los resultados:
 

En una sola NIC con un tamaño medio de E/S mayor (> ~16 k), había mejoras significativas tanto en las
lecturas como en las escrituras.
Para tamaños de E/S más pequeños, hubo un ligero impacto de ~10 % en el rendimiento con el SMB
multicanal habilitado. Esto podría mitigarse mediante la distribución de la carga por varios archivos, o
la deshabilitación de la característica.
El rendimiento sigue estando sujeto a los límites de un solo archivo.

Pasos siguientes
Habilitar SMB multicanal
Consulta la documentación de Windows para el SMB multicanal
Mejora del rendimiento del recurso
compartido de archivos NFS de Azure
Artículo • 26/10/2023

En este artículo se explica cómo puede mejorar el rendimiento de los archivos

compartidos de NFS de Azure.

Se aplica a
Tipo de recurso compartido de archivos SMB NFS

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS

Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Aumento del tamaño de la lectura anticipada

para mejorar el rendimiento de lectura
El parámetro del kernel read_ahead_kb en Linux representa la cantidad de datos que
deben "leerse de forma anticipada" o capturarse previamente durante una operación de
lectura secuencial. Las versiones del kernel de Linux anteriores a la versión 5.4
establecen el valor de la lectura anticipada en el equivalente de 15 veces el valor de
rsize del sistema de archivos montado (la opción de montaje del lado cliente para el

tamaño del búfer de lectura). Esto establece el valor de lectura anticipada lo

suficientemente alto como para mejorar el rendimiento de lectura secuencial del cliente
en la mayoría de los casos.

Sin embargo, a partir de la versión 5.4 del kernel de Linux, el cliente NFS de Linux usa un
valor predeterminado de read_ahead_kb de 128 KiB. Este valor pequeño puede reducir la
cantidad de rendimiento de lectura para archivos grandes. Los clientes que actualizan
desde versiones de Linux con un mayor valor de lectura anticipada en comparación con
los que tienen el valor predeterminado de 128 KiB podrían experimentar una
disminución en el rendimiento de lectura secuencial.

En el caso de los kernels de Linux 5.4 o posteriores, se recomienda establecer de forma

persistente el valor de read_ahead_kb en 15 MiB para mejorar el rendimiento.
Para cambiar este valor, establezca el tamaño de lectura anticipada agregando una regla
en udev, un administrador de dispositivos del kernel de Linux. Siga estos pasos:

1. En un editor de texto, cree el archivo /etc/udev/rules.d/99-nfs.rules escribiendo y

guardando el texto siguiente:

Resultados

SUBSYSTEM=="bdi" \
, ACTION=="add" \
, PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi)
{ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
, ATTR{read_ahead_kb}="15360"

2. En una consola, aplique la regla udev ejecutando el comando udevadm como

superusuario y vuelva a cargar los archivos de reglas y otras bases de datos. Solo
tiene que ejecutar este comando una vez para que udev sea consciente del nuevo
archivo.

Bash

sudo udevadm control --reload

Nconnect
Nconnect es una opción de montaje de Linux del lado cliente que aumenta el

rendimiento a escala al permitirle usar más conexiones TCP entre el cliente y el servicio
Azure Premium Files para NFSv4.1, a la vez que mantiene la resistencia de la plataforma
como servicio (PaaS).

Ventajas de nconnect
Con nconnect , puede aumentar el rendimiento a escala mediante menos máquinas
cliente para reducir el costo total de propiedad (TCO). Nconnect aumenta el rendimiento
mediante el uso de varios canales TCP en una o varias NIC, mediante uno o varios
clientes. Sin nconnect , necesitaría aproximadamente 20 máquinas cliente para lograr los
límites de escala de ancho de banda (10 GiB/s) ofrecidos por el mayor tamaño de
aprovisionamiento de recursos compartidos de archivos premium de Azure. Con
nconnect , puede lograr esos límites usando solo de 6 a 7 clientes. Esa es casi una

reducción del 70 % en el costo informático, al tiempo que proporciona mejoras

significativas en la IOPS y el rendimiento a escala (consulte la tabla).
 Métrica (operación) Tamaño de E/S Mejora del rendimiento

IOPS (escritura) 64K, 1024K 3x

IOPS (lectura) Todos los tamaños de E/S 2-4x

Rendimiento (escritura) 64K, 1024K 3x

Rendimiento (lectura) Todos los tamaños de E/S 2-4x

Requisitos previos
Las distribuciones de Linux más recientes son totalmente compatibles con
nconnect . En el caso de las distribuciones anteriores de Linux, asegúrese de que la

versión del kernel de Linux es 5.3 o posterior.

La configuración por montaje solo se admite cuando se usa un único recurso
compartido de archivos por cuenta de almacenamiento a través de un punto de
conexión privado.

Impacto en el rendimiento de nconnect

Hemos logrado los siguientes resultados de rendimiento al usar la nconnect opción de
montaje con recursos compartidos de archivos NFS de Azure en clientes Linux a gran
escala. Para obtener más información sobre cómo logramos estos resultados, consulte
Configuración de pruebas de rendimiento.
Recomendaciones para nconnect
Siga estas recomendaciones para obtener los mejores resultados de nconnect .

Establezca nconnect=4 .

Aunque Azure Files admite la configuración nconnect hasta el máximo de 16, se

recomienda configurar las opciones de montaje con el valor óptimo de nconnect=4 .
Actualmente, no hay ganancias más allá de cuatro canales para la implementación de
Azure Files de nconnect . De hecho, superar cuatro canales en un único recurso
compartido de archivos de Azure de un solo cliente podría afectar negativamente al
rendimiento debido a la saturación de la red TCP.

Ajustar el tamaño de las máquinas virtuales cuidadosamente

En función de los requisitos de la carga de trabajo, es importante ajustar correctamente

el tamaño de las máquinas cliente para evitar que se vean limitados por el ancho de
banda de red esperado. No necesita varias NIC para lograr el rendimiento de red
esperado. Aunque es habitual usar máquinas virtuales de uso general con Azure Files,
hay varios tipos de máquinas virtuales disponibles en función de las necesidades de la
carga de trabajo y la disponibilidad de las regiones. Para más información, consulte
Selector de máquinas virtuales de Azure .

Mantener la profundidad de la cola menor o igual que 64

La profundidad de la cola es el número de solicitudes de E/S pendientes que un recurso
de almacenamiento puede atender. No se recomienda superar la profundidad óptima
de la cola de 64. Si lo hace, no verá más mejoras de rendimiento. Para obtener más
información, vea Profundidad de la cola.
Nconnect configuración por montaje

Si una carga de trabajo requiere montar varios recursos compartidos con una o varias
cuentas de almacenamiento con una configuración de nconnect diferente de un solo
cliente, no podemos garantizar que esa configuración persista al montarse a través del
punto de conexión público. La configuración por montaje solo se admite cuando se usa
un único recurso compartido de archivos de Azure por cuenta de almacenamiento a
través del punto de conexión privado, como se describe en Escenario 1.

Escenario 1: configuración de nconnect por montaje (compatible) a

través de un punto de conexión privado con varias cuentas de
almacenamiento
StorageAccount.file.core.windows.net = 10.10.10.10
StorageAccount2.file.core.windows.net = 10.10.10.11
Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1

nconnect=4
Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Escenario 2: configuración de nconnect por montaje (no

compatible) a través del punto de conexión público
StorageAccount.file.core.windows.net = 52.239.238.8
StorageAccount2.file.core.windows.net = 52.239.238.7
Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1

nconnect=4
Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2

Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

７ Nota

Incluso si la cuenta de almacenamiento se resuelve en una dirección IP diferente,

no podemos garantizar que la dirección persistirá porque los puntos de conexión
públicos no son direcciones estáticas.

Escenario 3: configuración de nconnect por montaje (no

compatible) a través de un punto de conexión privado con varios
recursos compartidos de archivos en una cuenta de
almacenamiento
 StorageAccount.file.core.windows.net = 10.10.10.10
Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1

nconnect=4
Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2

Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare3

Configuración de prueba de rendimiento

Usamos los siguientes recursos y herramientas de pruebas comparativas para lograr y
medir los resultados descritos en este artículo.

Cliente único: Máquina virtual de Azure (serie DSv4) con una sola NIC
Sistema operativo: Linux (Ubuntu 20.40)
Almacenamiento NFS: Recurso compartido de archivos premium de Azure Files
(aprovisionado 30 TiB, configurado nconnect=4 )

Tamaño vCPU Memoria Almacenamiento Discos Nº Ancho de

temporal (SSD) de datos máx. banda de red
máx. NIC esperado

Standard_D16_v4 16 64 GiB Solo 32 8 12 500 Mbps

almacenamiento
remoto

Pruebas y herramientas de pruebas comparativas

Usamos Flexible I/O Tester (FIO), una herramienta de E/S de disco libre y de código
abierto que se usa tanto para pruebas comparativas como para comprobación del
esfuerzo y el hardware. Para instalar FIO, siga la sección Paquetes binarios que aparece
en el archivo README de FIO para instalar la versión correspondiente a la plataforma
que prefiera.

Aunque estas pruebas se centran en patrones de acceso de E/S aleatorios, obtendrá

resultados similares al usar E/S secuencial.

IOPS elevadas: lecturas del 100 %

Tamaño de E/S de 4 k - lectura aleatoria - profundidad de 64 colas

Bash

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --

time_based --bs=4k --iodepth=64 --filesize=4G --rw=randread --
 group_reporting --ramp_time=300

Tamaño de E/S de 8 k - lectura aleatoria - profundidad de 64 colas

Bash

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --

time_based --bs=8k --iodepth=64 --filesize=4G --rw=randread --
group_reporting --ramp_time=300

Alto rendimiento: 100 % de lecturas

Tamaño de E/S de 64 k - lectura aleatoria - profundidad de 64 colas

Bash

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --

time_based --bs=64k --iodepth=64 --filesize=4G --rw=randread --
group_reporting --ramp_time=300

Tamaño de E/S de 1024 k - 100 % de lectura aleatoria - profundidad de 64 colas

Bash

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --

time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randread --
group_reporting --ramp_time=300

IOPS elevadas: 100 % de escrituras

Tamaño de E/S de 4 k - 100 % de escritura aleatoria - profundidad de 64 colas

Bash

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --

time_based --bs=4k --iodepth=64 --filesize=4G --rw=randwrite --
group_reporting --ramp_time=300

Tamaño de E/S de 8 k - 100 % de escritura aleatoria - profundidad de 64 colas

Bash

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --

time_based --bs=8k --iodepth=64 --filesize=4G --rw=randwrite --
 group_reporting --ramp_time=300

Alto rendimiento: 100 % de escrituras

Tamaño de E/S de 64 k - 100 % de escritura aleatoria - profundidad de 64 colas

Bash

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --

time_based --bs=64k --iodepth=64 --filesize=4G --rw=randwrite --
group_reporting --ramp_time=300

Tamaño de E/S de 1024 k - 100 % de escritura aleatoria - profundidad de 64 colas

Bash

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --

time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randwrite --
group_reporting --ramp_time=300

Consideraciones de rendimiento para nconnect

Al usar la opción de montaje de nconnect , debe evaluar detenidamente las cargas de
trabajo que tienen las siguientes características:

Cargas de trabajo de escritura sensibles a la latencia que son un único subproceso

o usan una profundidad de cola baja (menos de 16)
Cargas de trabajo de lectura confidenciales de latencia que son un único
subproceso o usan una profundidad de cola baja en combinación con tamaños de
E/S más pequeños

No todas las cargas de trabajo requieren rendimiento de alta escala en todo el sistema o
de IOPS. En el caso de cargas de trabajo de escala más pequeñas, es posible que no
tenga sentido usar nconnect . Use la tabla siguiente para decidir si nconnect será
ventajoso para la carga de trabajo. Se recomiendan escenarios resaltados en verde,
mientras que los resaltados en rojo no. Los resaltados en amarillo son neutros.
Consulte también
Para obtener instrucciones de montaje, consulte Montaje del recurso compartido
de archivos NFS en Linux.
Para obtener una lista completa de las opciones de montaje, consulte página man
de NFS de Linux .
Para obtener información sobre la latencia, las IOPS, el rendimiento y otros
conceptos de rendimiento, consulte Descripción del rendimiento de Azure Files.
Objetivos de escalabilidad y
rendimiento de Azure Files
Artículo • 06/04/2023

Azure Files ofrece recursos compartidos de archivos en la nube totalmente

administrados a los que se puede acceder mediante los protocolos SMB y del sistema
de archivos NFS. En este artículo se explican los objetivos de escalabilidad y rendimiento
de Azure Files y Azure File Sync.

Los objetivos enumerados aquí pueden verse afectados por otras variables de la
implementación. Por ejemplo, el rendimiento de E/S de un archivo puede verse afectado
tanto por el comportamiento del cliente SMB como por el ancho de banda de red
disponible. Debe probar el patrón de uso para determinar si la escalabilidad y el
rendimiento de Azure Files cumplen sus requisitos. También debería esperar que estos
límites aumenten con el tiempo.

Se aplica a
Tipo de recurso compartido de archivos SMB NFS

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS

Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Objetivos de escalabilidad de Azure Files

Los recursos compartidos de archivos de Azure se implementan en cuentas de
almacenamiento, que son objetos de nivel superior que representan un grupo
compartido de almacenamiento. Este grupo de almacenamiento se puede usar para
implementar varios recursos compartidos de archivos. Por tanto, existen tres categorías
que se deben tener en cuenta: cuentas de almacenamiento, recursos compartidos de
archivo de Azure y archivos individuales.

Objetivos de escalabilidad de la cuenta de

almacenamiento
Los objetivos de escalabilidad de la cuenta de almacenamiento se aplican en el nivel de
cuenta de almacenamiento. Hay dos tipos principales de cuentas de almacenamiento
para Azure Files:

Cuentas de almacenamiento de uso general, versión 2 (GPv2) : Las cuentas de

almacenamiento de GPv2 permiten implementar recursos compartidos de archivos
de Azure en hardware estándar o basado en disco duro (HDD). Además de
almacenar recursos compartidos de archivos de Azure, las cuentas de
almacenamiento de GPv2 pueden almacenar otros recursos de almacenamiento,
como contenedores de blobs, colas o tablas. Los recursos compartidos de archivos
se pueden implementar en los niveles de transacción optimizada (valor
predeterminado), acceso frecuente o acceso esporádico.

Cuentas de almacenamiento FileStorage: Las cuentas de almacenamiento

FileStorage permiten implementar recursos compartidos de archivos de Azure en
hardware prémium o basado en unidades de estado sólido (SSD). Las cuentas
FileStorage solo se pueden usar para almacenar recursos compartidos de archivos
de Azure. No se puede implementar ningún otro recurso de almacenamiento
(contenedores de blobs, colas, tablas, etc.) en una cuenta FileStorage.

Atributo Cuentas de Cuentas de almacenamiento

almacenamiento GPv2 FileStorage (prémium)
(estándar)

Número de cuentas de 2501 2501

almacenamiento por
suscripción y región

Capacidad máxima de la cuenta 5 PiB2 100 TiB (aprovisionados)

de almacenamiento

Número máximo de recursos Sin límite Sin límite, el tamaño total

compartidos de archivos aprovisionado de todos los recursos
compartidos debe ser inferior al
máximo que la capacidad máxima de
la cuenta de almacenamiento.

Velocidad máxima de 20 000 IOPS2 100 000 IOPS

solicitudes simultáneas
Atributo Cuentas de Cuentas de almacenamiento
almacenamiento GPv2 FileStorage (prémium)
(estándar)

Rendimiento (entrada + salida) Entrada: 10,340 MiB/s

para LRS/GRS 7,152 MiB/s
Salida:
Este de Australia 14,305 MiB/s
Centro de EE. UU.
Este de Asia
Este de EE. UU. 2
Japón Oriental
Centro de Corea del Sur
Norte de Europa
Centro-sur de EE. UU.
Sudeste de Asia
Sur de Reino Unido 2
Oeste de Europa
Oeste de EE. UU.

Rendimiento (entrada + salida) Entrada: 10,340 MiB/s

para ZRS 7,152 MiB/s
Salida:
Este de Australia 14,305 MiB/s
Centro de EE. UU.
Este de EE. UU.
Este de EE. UU. 2
Japón Oriental
Norte de Europa
Centro-sur de EE. UU.
Sudeste de Asia
Sur de Reino Unido 2
Oeste de Europa
Oeste de EE. UU. 2

Rendimiento (entrada + salida) Entrada: 10,340 MiB/s

para combinaciones de 2,980 MiB/s
redundancia y región no Salida:
enumeradas en la fila anterior 5,960 MiB/s

Número máximo de reglas de 200 200

red virtual

Número máximo de reglas de 200 200

dirección IP

Operaciones de lectura de 800 por cada 5 minutos 800 por cada 5 minutos
administración
 Atributo Cuentas de Cuentas de almacenamiento
almacenamiento GPv2 FileStorage (prémium)
(estándar)

Operaciones de escritura de 10 por segundo/1200 10 por segundo/1200 por hora

administración por hora

Operaciones de lista de 100 por cada 5 minutos 100 por cada 5 minutos
administración

1
Con un aumento de cuota, puede crear hasta 500 cuentas de almacenamiento con
puntos de conexión estándar por región. Para más información, consulte Aumento de
las cuotas de la cuenta de Azure Storage. 2 Las cuentas de almacenamiento de uso
general, versión 2, admiten límites más altos de capacidad y límites más altos de entrada
por solicitud. Para solicitar un aumento en los límites de cuenta, póngase en contacto
con el soporte técnico de Azure .

Objetivos de escala de recursos compartidos de archivos

de Azure
Los objetivos de escalabilidad de los recursos compartidos de archivos de Azure se
aplican en el nivel de recurso compartido de archivos.

Atributo Recursos compartidos de Recursos compartidos

archivos estándar1 de archivos Prémium

Tamaño máximo de un recurso Sin mínimo 100 GiB

compartido de archivos (aprovisionados)

Unidad de aumento/reducción de N/D 1 GiB

tamaño aprovisionada

Tamaño máximo de un recurso 100 TiB, con la 100 TiB

compartido de archivos característica de
recurso compartido de
archivos grande
habilitada2
5 TiB, valor
predeterminado

Número máximo de archivos en un Sin límite Sin límite

recurso compartido de archivos
Atributo Recursos compartidos de Recursos compartidos
archivos estándar1 de archivos Prémium

Velocidad máxima de solicitud (IOPS 20 000, con la IOPS de línea

máx.) característica de base: 3000 +
recurso compartido de 1 IOPS por GiB,
archivos grandes hasta 100 000
habilitada2 Expansión de
1000 o 100 solicitudes IOPS: Máximo
por 100 ms, valor (10 000, 3x IOPS
predeterminado por GiB), hasta
100 000

Rendimiento (entrada y salida) de un Hasta los límites de la 100 + CEILING (0,04 *

único recurso compartido de archivos cuenta de ProvisionedStorageGiB)
(MiB/seg) almacenamiento, con la + CEILING (0,06 *
característica de ProvisionedStorageGiB)
recurso compartido de
archivos de gran
tamaño habilitada2
Hasta 60 MiB/s, valor
predeterminado

Número máximo de instantáneas de 200 instantáneas 200 instantáneas

recurso compartido

La longitud máxima del nombre de 2048 caracteres 2048 caracteres

3
objeto (nombre de ruta de acceso
completo que incluye todos los
directorios, los nombres de archivo y
caracteres de barra diagonal inversa)

La longitud máxima del componente 255 caracteres 255 caracteres

nombre de ruta de acceso individual3
(en la ruta de acceso \A\B\C\D, cada
letra representa un directorio o archivo
que constituye un componente
individual)

Límite de vínculo físico (solo NFS) N/D 178

Número máximo de canales de SMB N/D 4

multicanal

Número máximo de directivas de 5 5

acceso almacenadas por recurso
compartido de archivos
1
Los límites de los recursos compartidos de archivos estándar se aplican a los tres
niveles disponibles para dichos recursos: optimizado para transacciones, acceso
frecuente y acceso esporádico.

2 El valor predeterminado de los recursos compartidos de archivos estándar es 5 TiB;

consulte Creación de un recurso compartido de archivos de Azure para obtener más
información sobre cómo crear recursos compartidos de archivos con un tamaño de
100 TiB y aumentar los recursos compartidos de archivos estándar existentes hasta
100 TiB. Para aprovechar las ventajas de los destinos de mayor escala, debe cambiar la
cuota para que sea mayor que 5 TiB.

3
Azure Files aplica ciertas reglas de nomenclatura para los nombres de los directorios y
archivos.

Objetivos de escalabilidad de archivos

Los objetivos de escalabilidad de los archivos se aplican a los archivos individuales
almacenados en los recursos compartidos de archivos de Azure.

Atributo Archivos en recursos Archivos en recursos

compartidos de archivos compartidos de archivos
estándar prémium

Tamaño de archivo máximo 4 TiB 4 TiB

Velocidad máxima de solicitudes 1000 IOPS Hasta 80001

simultáneas

Entrada máxima de un archivo 60 MiB/s 200 MiB/s (hasta 1 GiB/s con

SMB multicanal)2

Salida máxima de un archivo 60 MiB/s 300 MiB/s (hasta 1 GiB/s con

SMB multicanal)2

Número máximo de identificadores 10 000 identificadores 10 000 identificadores

simultáneos para el directorio raíz3

Número máximo de identificadores 2000 identificadores 2000 identificadores

simultáneos por archivo y
directorio3

1 Se aplica a entradas y salidas de lectura y escritura (normalmente los tamaños de E/S son iguales o menores que

64 KiB). Las operaciones de metadatos, que no sean lecturas y escrituras, pueden ser más lentas. Estos límites son

flexibles y la limitación puede producirse más allá de estos límites.

2 En función de los límites de red de la máquina, el ancho de banda disponible, los tamaños de E/S, la profundidad de

la cola y otros factores. Para más información, consulte Rendimiento multicanal de SMB.

3 Azure Files admite 10 000 identificadores abiertos en el directorio raíz y 2000 identificadores abiertos por archivo y

directorio dentro del recurso compartido. El número de usuarios activos admitidos por recurso compartido depende

de las aplicaciones que acceden al recurso compartido. Si las aplicaciones no abren un identificador en el directorio

raíz, Azure Files puede admitir más de 10 000 usuarios activos por recurso compartido.

Objetivos de escalabilidad de Azure File Sync

En la tabla siguiente, se indica qué destinos son flexibles, que representan el límite
probado por Microsoft, y qué destinos son rígidos, lo que indica un máximo obligatorio:

Recurso Destino Límite

máximo

Servicios de sincronización 100 servicios de sincronización de Storage Sí

de almacenamiento por
región

Grupos de sincronización 200 grupos de sincronización Sí

por servicio de
sincronización de
almacenamiento

Servidores registrados por 99 servidores Sí

servicio de sincronización
de almacenamiento

Puntos de conexión en la 1 punto de conexión en la nube Sí

nube por grupo de
sincronización

Puntos de conexión del 100 puntos de conexión de servidor Sí

servidor por grupo de
sincronización

Puntos de conexión del 30 puntos de conexión de servidor Sí

servidor por servidor

Objetos del sistema de 100 millones de objetos No

archivos (archivos y
directorios) por grupo de
sincronización
 Recurso Destino Límite
máximo

Número máximo de 5 millones de objetos Sí

objetos del sistema de
archivos (directorios y
archivos) en un directorio
(no recursivo)

Tamaño máximo del 64 KiB Sí

descriptor de seguridad de
(archivos y directorios) del
objeto

Tamaño de archivo 100 GiB No

Tamaño mínimo de un basado en el tamaño del clúster del sistema de archivos Sí

archivo que se va a (tamaño del clúster del sistema de archivos doble). Por
organizar en niveles ejemplo, si el tamaño del clúster del sistema de archivos
es 4 KiB, el tamaño mínimo del archivo será de 8 KiB.

７ Nota

Un punto de conexión de Azure File Sync puede escalar verticalmente hasta el

tamaño de un recurso compartido de archivos de Azure. Si se alcanza el límite de
tamaño de recurso compartido de archivos de Azure, la sincronización no podrá
funcionar.

Métricas de rendimiento de Azure File Sync

Dado que el agente de Azure File Sync se ejecuta en una máquina con Windows Server
que se conecta a los recursos compartidos de archivos de Azure, el rendimiento de
sincronización efectivo depende de una serie de factores de su infraestructura: Windows
Server y la configuración del disco subyacente, el ancho de banda de la red entre el
servidor y Azure Storage, el tamaño del archivo, el tamaño total del conjunto de datos y
la actividad en el conjunto de datos. Dado que Azure File Sync funciona en el nivel de
archivo, las características de rendimiento de una solución basada en Azure File Sync se
debe medir según el número de objetos (archivos y directorios) que se procesan por
segundo.

En el caso de Azure File Sync, el rendimiento es fundamental en dos fases:

1. Aprovisionamiento inicial que se realiza una sola vez: para optimizar el

rendimiento del aprovisionamiento inicial, consulte Incorporación con Azure File
 Sync, donde obtendrá los detalles de una implementación óptima.
2. Sincronización en curso: después de que los datos se inicializan en los recursos
compartidos de archivos de Azure, Azure File Sync mantiene varios puntos de
conexión sincronizados.

７ Nota

Cuando muchos puntos de conexión de servidor del mismo grupo de

sincronización se están sincronizando al mismo tiempo, compiten por los recursos
del servicio en la nube. Como resultado, el rendimiento de la carga se ve afectado.
En casos extremos, algunas sesiones de sincronización no podrán acceder a los
recursos y se producirá un error. Sin embargo, esas sesiones de sincronización se
reanudarán en breve y finalmente se realizarán correctamente una vez que se
reduzca la congestión.

Resultados de las pruebas internas

Para ayudarle a planear la implementación de cada una de las fases (aprovisionamiento
inicial de una sola vez y sincronización continua), a continuación encontrará los
resultados observados durante las pruebas internas en un sistema con la siguiente
configuración:

Configuración del sistema Detalles

CPU 64 núcleos virtuales con una memoria caché L3 de 64 MiB

Memoria 128 GB

Disco Discos SAS con RAID 10 con caché con respaldo de batería

Red Red de 1 Gbps

Carga de trabajo Servidor de archivos de uso general

Aprovisionamiento inicial que se realiza una sola vez

Aprovisionamiento inicial que se realiza una Detalles

sola vez

Número de objetos 25 millones de objetos

Tamaño del conjunto de datos ~4,7 TiB

 Aprovisionamiento inicial que se realiza una Detalles
sola vez

Tamaño de archivo medio ~200 KiB (archivo más grande: 100 GiB)

Enumeración inicial de cambios de nube 80 objetos por segundo

Rendimiento de carga 20 objetos por segundo por grupo de

sincronización

Rendimiento de descarga de espacio de 400 objetos por segundo

nombres

Enumeración inicial de cambios de nube: Cuando se crea un nuevo grupo de

sincronización, la enumeración inicial de cambios en la nube es el primer paso que se
ejecutará. En este proceso, el sistema enumerará todos los elementos del recurso
compartido de archivos de Azure. Durante este proceso, no habrá ninguna actividad de
sincronización; es decir, no se descargará ningún elemento del punto de conexión de la
nube al punto de conexión del servidor, y no se cargará ningún elemento desde el
punto de conexión del servidor al punto de conexión en la nube. La actividad de
sincronización se reanudará una vez que se complete la enumeración inicial de cambios
en la nube. La tasa de rendimiento es de 80 objetos por segundo. Para calcular el
tiempo que se tarda en completar la enumeración inicial de cambios en la nube, los
clientes pueden calcular el número de elementos del recurso compartido de nube y usar
la siguiente fórmula para obtener el tiempo en días.

Tiempo (en días) para la enumeración inicial en la nube = (número de objetos en el

punto de conexión de nube)/(80*60*60*24)

Sincronización inicial de datos de Windows Server con un recurso compartido de

archivos de Azure: muchas implementaciones de Azure File Sync comienzan con un
recurso compartido de archivos de Azure vacío porque todos los datos están en el
servidor de Windows. En estos casos, la enumeración inicial de cambios en la nube es
rápida y la mayor parte del tiempo se dedica a sincronizar los cambios de
Windows Server con los recursos compartidos de archivos de Azure.

Mientras la sincronización carga los datos en el recurso compartido de archivos de

Azure, no hay tiempo de inactividad en el servidor de archivos local y los
administradores pueden configurar los límites de red para restringir la cantidad de
ancho de banda que se usa para la carga de datos en segundo plano.

La sincronización inicial suele estar limitada por la velocidad de carga inicial de

20 archivos por segundo/por grupo de sincronización. Los clientes pueden calcular el
tiempo de carga de todos sus datos en Azure con las siguientes fórmulas para obtener
el tiempo en días:

Tiempo (en días) para la carga de archivos en un grupo de sincronización = (número

de objetos en el punto de conexión del servidor)/(20*60*60*24)

Dividir los datos en varios puntos de conexión de servidor y grupos de sincronización

puede acelerar esta carga de datos inicial, ya que la operación puede realizarse en
paralelo con varios grupos de sincronización a una velocidad de 20 elementos por
segundo. Por lo tanto, se ejecutarían dos grupos de sincronización con una tasa
combinada de 40 elementos por segundo. El tiempo total para terminar la operación
sería el tiempo estimado del grupo de sincronización con el mayor número de archivos
que se van a sincronizar.

Rendimiento de descarga de espacio de nombres Cuando se agrega un nuevo punto

de conexión de servidor a un grupo de sincronización existente, el agente de Azure File
Sync no descarga ningún contenido de archivo del punto de conexión en la nube. En
primer lugar sincroniza el espacio de nombres completo y, después, desencadena la
recuperación en segundo plano para descargar los archivos, ya sea en su totalidad o, si
está habilitada la organización en niveles en la nube, la directiva de niveles en la nube
establecida en el punto de conexión del servidor.

Sincronización en curso

Sincronización en curso Detalles

Número de objetos sincronizados 125 000 objetos (renovación ~ 1 %)

Tamaño del conjunto de datos 50 GiB

Tamaño de archivo medio ~500 KiB

Rendimiento de carga 20 objetos por segundo por grupo de sincronización

Rendimiento de descarga completa* 60 objetos por segundo

*Si están habilitados los niveles de la nube, es probable que observe un rendimiento
mejor, ya que solo se descargan algunos de los datos de los archivos. Azure File Sync
solo descarga los datos de los archivos almacenados en la memoria caché cuando
cambian en cualquiera de los puntos de conexión. En el caso de los archivos en niveles o
recién creados, el agente no descarga los datos de los archivos, solo sincroniza el
espacio de nombres en todos los puntos de conexión del servidor. El agente también
admite descargas parciales de archivos en capas cuando el usuario accede a ellos.
 ７ Nota

Los números anteriores no indican el rendimiento que experimentará. El

rendimiento real dependerá de varios factores, como se ha indicado al principio de
esta sección.

Como guía general para la implementación, debería tener varios factores en cuenta:

El rendimiento de los objetos se escala aproximadamente en proporción al número

de grupos de sincronización del servidor. La división de los datos en varios grupos
de sincronización en un servidor mejora el rendimiento, que también está limitado
por el servidor y la red.
El rendimiento de los objetos es inversamente proporcional al rendimiento de MiB
por segundo. En archivos pequeños, el rendimiento será mayor en cuanto al
número de objetos procesados por segundo, pero el rendimiento en MiB por
segundo será inferior. Por el contrario, en archivos grandes, se procesarán menos
objetos por segundo, pero el rendimiento en MiB por segundo será superior. El
rendimiento en MiB por segundo está limitado por los destinos del escalado de
Azure Files.

Consulte también
Descripción del rendimiento de Azure Files
Planeamiento de una implementación de Azure Files
Planeamiento de una implementación de Azure File Sync
Introducción a las opciones de
autenticación basada en la identidad de
Azure Files con el acceso SMB
Artículo • 22/11/2023

En este artículo se explica la forma en que los recursos compartidos de archivos de

Azure pueden usar los servicios de dominio, ya sea de forma local o en Azure, para
admitir el acceso basado en la identidad a los recursos compartidos de archivos de
Azure en SMB. La habilitación del acceso basado en identidad de los recursos
compartidos de archivos de Azure permite reemplazar los servidores de archivos
existentes por recursos compartidos de archivos de Azure sin reemplazar el servicio de
directorio existente, con lo que se mantiene el acceso sin problemas de los usuarios a
los recursos compartidos.

Se aplica a
Tipo de recurso compartido de archivos SMB NFS

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS

Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Glosario
Es útil comprender algunos términos clave relacionados con la autenticación basada en
la identidad para recursos compartidos de archivos de Azure:

Autenticación Kerberos

Kerberos es un protocolo de autenticación que se utiliza para comprobar la

identidad de un usuario o un host. Para más información sobre Kerberos, consulte
Introducción a la autenticación Kerberos.

Protocolo Bloque de mensajes del servidor (SMB)

SMB es un protocolo de uso compartido de archivos de red estándar del sector.

Para más información sobre SMB, consulte Microsoft SMB Protocol and CIFS
Protocol Overview (Introducción a los protocolos CIFS y SMB de Microsoft).
Microsoft Entra ID

Microsoft Entra ID (anteriormente Azure AD) es el directorio multiinquilino basado

en la nube y el servicio de administración de identidades de Microsoft. Microsoft
Entra ID combina servicios de directorio fundamentales, administración del acceso
a las aplicaciones y protección de identidades en una única solución.

Servicios de dominio de Microsoft Entra

Microsoft Entra Domain Services proporciona servicios de dominio administrados

como, por ejemplo, unión a un dominio, directivas de grupo, LDAP y autenticación
Kerberos/NTLM. Estos servicios son totalmente compatibles con Active Directory
Domain Services. Para más información, consulte Microsoft Entra Domain Services.

Active Directory Domain Services (AD DS) local

La integración de Active Directory Domain Services (AD DS) local en Azure Files
proporciona los métodos para almacenar datos de directorio y poner dichos datos
a disposición de los usuarios y administradores de la red. La seguridad se integra
en AD DS mediante la autenticación de inicio de sesión y el control de acceso a los
objetos del directorio. Con un único inicio de sesión de red, los administradores
pueden administrar los datos del directorio y la organización a través de su red, y
los usuarios de red autorizados pueden tener acceso a los recursos en cualquier
parte de la red. Normalmente, las que adoptan AD DS son empresas en entornos
locales o en máquinas virtuales hospedadas en la nube, que usan las credenciales
de AD DS para el control de acceso. Para obtener más información, consulte
Introducción a Active Directory Domain Services.

Control de acceso basado en roles de Azure (Azure RBAC)

RBAC de Azure permite la administración detallada del acceso a Azure. Con Azure
RBAC, puede administrar el acceso a los recursos mediante la concesión a los
usuarios del menor número de permisos necesarios para realizar su trabajo. Para
obtener más información, consulte ¿Qué es el control de acceso basado en rol de
Azure (RBAC)?

Identidades híbridas

Las identidades de usuario híbridas son identidades de AD DS sincronizadas con

Microsoft Entra ID mediante la aplicación de sincronización de Microsoft Entra
Connect local o Microsoft Entra Connect Cloud Sync, un agente ligero que se
puede instalar desde el Centro de Administración de Microsoft Entra.
Escenarios de autenticación admitidos
Azure Files admite la autenticación basada en la identidad en SMB mediante los
métodos siguientes. Solo puede usar un método por cuenta de almacenamiento.

Autenticación AD DS local: Las máquinas Windows unidas a AD DS local o a

Microsoft Entra Domain Services pueden acceder a los recursos compartidos de
archivos de Azure con las credenciales de Active Directory local que se sincronizan
con Microsoft Entra ID a través de SMB. El cliente debe tener conectividad de red
no impedida a su AD DS. Si ya tiene AD DS configurado en el entorno local o en
una máquina virtual en Azure donde los dispositivos están unidos a un dominio de
AD, debe usar AD DS para la autenticación en los recursos compartidos de
archivos de Azure.
autenticación de Microsoft Entra Domain Services: máquinas virtuales basadas en
la nube de Windows unidas a Microsoft Entra Domain Services pueden acceder a
recursos compartidos de archivos de Azure con credenciales de Microsoft Entra. En
esta solución, Microsoft Entra ID ejecuta un dominio de Windows Server Active
Directory tradicional en nombre del cliente, que es un elemento secundario del
inquilino de Microsoft Entra del cliente.
Kerberos de Microsoft Entra para identidades híbridas: el uso de Microsoft Entra
ID para la autenticación de identidades híbridas de usuario permite a los usuarios
de Microsoft Entra acceder a recursos compartidos de archivos de Azure mediante
la autenticación Kerberos. Esto significa que los usuarios finales pueden acceder a
los recursos compartidos de archivos de Azure a través de Internet sin necesidad
de tener conectividad de red a los controladores de dominio desde máquinas
virtuales unidas a Microsoft Entra híbrido y a Microsoft Entra. Las identidades solo
en la nube no se admiten actualmente.
Autenticación Kerberos de AD para clientes Linux: los clientes Linux pueden usar
la autenticación Kerberos a través de SMB para Azure Files mediante AD DS local o
Microsoft Entra Domain Services.

Restricciones
Ninguno de los métodos de autenticación admite la asignación de permisos de
nivel de recurso compartido a cuentas de equipo (cuentas de máquina) mediante
RBAC de Azure, ya que las cuentas de equipo no se pueden sincronizar con una
identidad en Microsoft Entra ID. Si quiere permitir que una cuenta de equipo
acceda a recursos compartidos de archivos de Azure mediante la autenticación
basada en identidades, use un permiso de nivel de recurso compartido
 predeterminado o considere la posibilidad de usar una cuenta de inicio de sesión
del servicio en su lugar.
No se admite la autenticación basada en identidad con recursos compartidos de
archivos de Network File System (NFS).

Casos de uso comunes

La autenticación basada en identidades con Azure Files puede ser útil en diversos
escenarios:

Reemplazo de servidores de archivos locales

Dejar de usar y reemplazar servidores de archivos locales dispersos es un problema
común que toda empresa encuentra en su recorrido de modernización de TI. Los
recursos compartidos de archivos de Azure con la autenticación de AD DS local son los
más idóneos aquí, cuando puede migrar los datos a Azure Files. Una migración
completa le permitirá aprovechar las ventajas de alta disponibilidad y escalabilidad, a la
vez que minimiza los cambios del lado cliente. Proporciona una experiencia de
migración perfecta para los usuarios finales, para que puedan seguir accediendo a sus
datos con las mismas credenciales mediante sus equipos unidos a un dominio existente.

Migración "lift-and-shift" de aplicaciones a Azure

Al aplicar migraciones "lift-and-shift" de aplicaciones a la nube, querrá mantener el
mismo modelo de autenticación para los datos. A medida que se amplía la experiencia
de control de acceso basado en identidad a los recursos compartidos de archivos de
Azure, se elimina la necesidad de cambiar la aplicación a los métodos de autenticación
modernos y acelerar la adopción de la nube. Los recursos compartidos de archivos de
Azure ofrecen la opción de integrarse en Microsoft Entra Domain Services o AD DS local
para la autenticación. Si tiene pensado pasarse un 100 % a la nube nativa y minimizar
los esfuerzos de administración de infraestructuras en la nube, puede que Microsoft
Entra Domain Services sea una mejor opción como servicio de dominio totalmente
administrado. Si necesita compatibilidad total con las funcionalidades de AD DS, puede
tener en cuenta la posibilidad de ampliar el entorno de AD DS a la nube mediante
controladores de dominio autohospedados en máquinas virtuales. En cualquier caso,
proporcionamos flexibilidad para elegir el servicio de dominio que mejor se adapte a
sus necesidades empresariales.

Copia de seguridad y recuperación ante desastres (DR)

Si mantiene el almacenamiento de archivos principal en el entorno local, los recursos
compartidos de archivos de Azure pueden servir como almacenamiento ideal para
copias de seguridad o recuperación ante desastres, lo que mejora la continuidad
empresarial. Puede usar recursos compartidos de archivos de Azure para realizar copias
de seguridad de los datos a partir de servidores de archivos existentes, a la vez que
conserva las listas de control de acceso discrecionales de Windows (DACL). En
escenarios de recuperación ante desastres, puede configurar una opción de
autenticación para admitir el cumplimiento adecuado del control de acceso en la
conmutación por error.

Ventajas de la autenticación basadas en

identidad
La autenticación basada en identidad para Azure Files ofrece varias ventajas respecto al
uso de la autenticación de clave compartida:

Ampliar la experiencia tradicional de acceso compartido de archivos basada en

identidad en la nube
Si tiene previsto realizar una migración "lift-and-shift" de su aplicación a la nube,
mediante el reemplazo de los servidores de archivos tradicionales con recursos
compartidos de archivos de Azure, tal vez quiera que la aplicación se autentique
con las credenciales de AD DS local o Microsoft Entra Domain Services para
acceder a los datos de los archivos. Azure Files admite el uso de credenciales de
AD DS local o de Microsoft Entra Domain Services para tener acceso a los recursos
compartidos de archivos de Azure a través de SMB desde VM unidas a un dominio
de AD DS local o Microsoft Entra Domain Services.

Aplicar el control de acceso granular en recursos compartidos de archivos de

Azure
Puede conceder permisos a una identidad específica en el nivel de recurso
compartido, directorio o archivo. Por ejemplo, suponga que tiene varios equipos
que utilizan un solo recurso compartido de archivos de Azure para la colaboración
en proyectos. Puede conceder a todos los equipos acceso a directorios no
confidenciales, al tiempo que limita el acceso a directorios que contienen datos
financieros confidenciales únicamente a su equipo de financiero.

Realizar copias de seguridad de ACL de Windows (también conocidas como

permisos NTFS) junto con los datos
Puede usar recursos compartidos de archivos de Azure para realizar copias de
seguridad de los recursos compartidos de archivos locales existentes. Azure Files
conserva las listas de control de acceso junto con los datos cuando se hace una
 copia de seguridad de un recurso compartido de archivos en recursos compartidos
de archivos de Azure sobre SMB.

Funcionamiento
Los recursos compartidos de archivos de Azure utilizan el protocolo Kerberos para la
autenticación con un origen de AD. Cuando una identidad asociada con un usuario o
una aplicación que se ejecuta en un cliente intenta acceder a los datos de recursos
compartidos de archivos de Azure, la solicitud se envía al origen de AD para autenticar
la identidad. Si la autenticación es correcta, devuelve un token de Kerberos. El cliente
envía una solicitud que incluye el token de Kerberos, y los recursos compartidos de
archivos de Azure usan ese token para autorizar la solicitud. Los recursos compartidos
de archivos de Azure solo reciben el token de Kerberos, no las credenciales de acceso
del usuario.

Puede habilitar la autenticación basada en la identidad en las cuentas de

almacenamiento nuevas y existentes mediante uno de los tres orígenes de AD: AD DS,
Microsoft Entra Domain Services y Kerberos de Microsoft Entra (solo para las
identidades híbridas). Solo se puede usar un origen de AD para la autenticación de
acceso a archivos en la cuenta de almacenamiento, lo que se aplica a todos los recursos
compartidos de archivos de la cuenta. Para poder habilitar la autenticación basada en
identidades en la cuenta de almacenamiento, primero debe configurar el entorno del
dominio.

AD DS
En el caso de la autenticación de AD DS local, primero debe configurar los controladores
de dominio de AD y unir el dominio de sus máquinas o máquinas virtuales. Puede
hospedar los controladores de dominio en máquinas virtuales de Azure o en un entorno
local. En cualquier caso, los clientes unidos a un dominio deben tener una conectividad
de red no impedida al controlador de dominio, por lo que deben estar en la red
corporativa o en la red virtual (VNet) del servicio de dominio.

En este diagrama se muestra la autenticación de AD DS local en recursos compartidos

de archivos de Azure a través de SMB. El AD DS local debe sincronizarse con Microsoft
Entra ID mediante Microsoft Entra Connect Sync o la sincronización en la nube de
Microsoft Entra Connect. Solo se pueden autenticar y autorizar a las identidades de los
usuarios híbridos que existen en el AD DS local y en Microsoft Entra ID para el acceso a
recursos compartidos de archivos de Azure. Esto se debe a que el permiso de nivel de
recurso compartido se configura con respecto a la identidad representada en Microsoft
Entra ID, mientras que el permiso de nivel de archivo o directorio se aplica con el de AD
DS. Asegúrese de configurar los permisos correctamente con el mismo usuario híbrido.

Para más información sobre cómo habilitar la autenticación de AD DS, primero lea
Introducción: autenticación de Active Directory Domain Services local en SMB para
recursos compartidos de archivos de Azure y, después, Habilitar la autenticación de AD
DS para los recursos compartidos de archivos de Azure.

Servicios de dominio de Microsoft Entra

En el caso de la autenticación de Microsoft Entra Domain Services, debe habilitar
Microsoft Entra Domain Services y unir a un dominio las VM desde las que tiene
pensado obtener acceso a los datos de los archivos. La VM unida a un dominio debe
residir en la misma red virtual (Vnet) que la instancia de Microsoft Entra Domain
Services.

Este diagrama representa el flujo de trabajo para la autenticación de Microsoft Entra

Domain Services en recursos compartidos de archivos de Azure a través de SMB. Sigue
un patrón similar a la autenticación de AD DS local, pero hay dos diferencias principales:

1. No es necesario crear la identidad en Microsoft Entra Domain Services para

representar la cuenta de almacenamiento. Esto lo realiza el proceso de habilitación
en segundo plano.

2. Todos los usuarios que existen en Microsoft Entra ID se pueden autenticar y

autorizar. El usuario puede ser híbrido o estar solo en la nube. La plataforma
administra la sincronización de Microsoft Entra ID a Microsoft Entra Domain
Services sin necesidad de ninguna configuración de usuario. Sin embargo, el
cliente debe estar unido al dominio hospedado de Microsoft Entra Domain
Services. No se puede estar unido ni registrado a Microsoft Entra. Microsoft Entra
Domain Services no admite los clientes que no son de Azure (es decir, los equipos
portátiles de usuario, las estaciones de trabajo, las máquinas virtuales en otras
nubes, etc.) que se unan a al dominio hospedado de Microsoft Entra Domain
 Services. Sin embargo, es posible montar un recurso compartido de archivos desde
un cliente no unido a un dominio proporcionando credenciales explícitas como
DOMAINNAME\username o mediante el nombre de dominio completo
(username@FQDN).

Para aprender a habilitar la autenticación de Microsoft Entra Domain Services, consulte

Habilitación de la autenticación de Microsoft Entra Domain Services en Azure Files.

Microsoft Entra Kerberos para identidades híbridas

La habilitación y configuración de Microsoft Entra ID para autenticar identidades de
usuarios híbridas permite a los usuarios de Microsoft Entra acceder a recursos
compartidos de archivos de Azure mediante la autenticación Kerberos. Esta
configuración usa Microsoft Entra ID para emitir los vales de Kerberos necesarios para
acceder al recurso compartido de archivos con el protocolo SMB estándar del sector.
Esto significa que los usuarios finales pueden acceder a los recursos compartidos de
archivos de Azure a través de Internet sin necesidad de tener conectividad de red a los
controladores de dominio desde máquinas virtuales unidas a Microsoft Entra híbrido y a
Microsoft Entra. Sin embargo, la configuración de permisos de nivel de archivo y
directorio de usuarios y grupos requiere conectividad de red no impedida al controlador
de dominio local.

） Importante

La autenticación Kerberos de Microsoft Entra solo admite las identidades de

usuario híbridas; no admite identidades solo en la nube. Se necesita una
implementación tradicional de AD DS y debe sincronizarse con Microsoft Entra ID
mediante Microsoft Entra Connect Sync o la sincronización en la nube de Microsoft
Entra Connect. Los clientes deben estar unido a Microsoft Entra o a Microsoft Entra
híbrido. Kerberos de Microsoft Entra no se admite en clientes unidos a Microsoft
Entra Domain Services o unidos solo a AD.
Para aprender a habilitar la autenticación Kerberos de Microsoft Entra para identidades
híbridas, consulte Activación de la autenticación Kerberos de Microsoft Entra para
identidades híbridas en Azure Files.

También puede usar esta característica para almacenar perfiles de FSLogix en recursos
compartidos de archivos de Azure para máquinas virtuales unidas a Microsoft Entra.
Para obtener más información, consulte Creación de un contenedor de perfil con Azure
Files y Microsoft Entra ID.

Control de acceso
Azure Files aplica la autorización en el acceso del usuario tanto a nivel del recurso
compartido como a los niveles de directorio o archivo. La asignación de permisos de
nivel de recurso compartido se puede llevar a cabo en usuarios o grupos de Microsoft
Entra administrados con Azure RBAC. Con Azure RBAC, las credenciales que se usan
para el acceso a archivos deben estar disponibles o sincronizadas con Microsoft Entra
ID. Para conceder acceso a un recurso compartido de archivos de Azure, puede asignar
roles integrados de Azure, como el de lector de recursos compartidos de SMB de datos
de archivos de almacenamiento, a usuarios o grupos en Microsoft Entra ID.

En el nivel de directorio o archivo, Azure Files admite la conservación, la herencia y la

aplicación de listas ACL de Windows, igual que cualquier servidor de archivos de
Windows. Si lo desea, puede mantener las listas ACL de Windows al copiar datos a
través de SMB entre su recurso compartido de archivos y los recursos compartidos de
archivos de Azure. Independientemente de que se tenga previsto aplicar la autorización
o no, se pueden usar los recursos compartidos de archivos de Azure para hacer copias
de seguridad de las ACL junto con los datos.

Configuración de los permisos de nivel de recurso

compartido para Azure Files
Una vez que haya habilitado un origen de AD en la cuenta de almacenamiento, debe
realizar una de las siguientes acciones para acceder al recurso compartido de archivos:

Establecer un permiso de nivel de recurso compartido predeterminado que se

aplique a todos los usuarios y grupos autenticados
Asignación de roles RBAC de Azure integrados a usuarios y grupos, o
Configurar roles personalizados para las identidades de Microsoft Entra y asignar
derechos de acceso a los recursos compartidos de archivos en la cuenta de
almacenamiento.

El permiso de nivel de recurso compartido asignado permite a la identidad concedida

obtener acceso solo al recurso compartido, a nada más, ni siquiera al directorio raíz. Aún
es necesario configurar por separado los permisos de nivel de directorio y de archivo.

Configuración de los permisos de nivel de archivo o

directorio para Azure Files
Los recursos compartidos de archivos de Azure aplican listas de control de acceso
estándar de Windows en el nivel de archivo y directorio, incluido el directorio raíz. La
configuración de permisos de nivel de archivo o directorio se admite sobre SMB y REST.
Monte el recurso compartido de archivos de destino de la VM y configure los permisos
mediante el Explorador de archivos de Windows, o el comando de Windows icacls o
Set-ACL.

Uso de la clave de cuenta de almacenamiento para los

permisos de superusuario
Un usuario con la clave de cuenta de almacenamiento puede acceder a los recursos
compartidos de archivos de Azure con permisos de superusuario. Los permisos de
superusuario omiten todas las restricciones de control de acceso.

） Importante

Nuestro procedimiento recomendado de seguridad es evitar el uso compartido de

las claves de cuenta de almacenamiento y aprovechar la autenticación basada en
identidad siempre que sea posible.

Conservación de las listas de control de acceso de

archivos y directorios al importar datos a recursos
compartidos de archivos de Azure
Azure Files admite la conservación de las listas de control de acceso de directorios o
archivos al copiar datos a recursos compartidos de archivos de Azure. Puede copiar
listas de control de acceso de un directorio o archivo en recursos compartidos de
archivos de Azure mediante Azure File Sync o conjuntos de herramientas comunes para
mover archivos. Por ejemplo, puede usar robocopy con la marca /copy:s para copiar
tanto los datos como las listas de control de acceso en un recurso compartido de
archivos de Azure. Las listas de control de acceso se conservan de forma
predeterminada, no es necesario habilitar la autenticación basada en la identidad en la
cuenta de almacenamiento para conservarlas.

Precios
No hay ningún cargo adicional por servicio por habilitar la autenticación basada en la
identidad en SMB en la cuenta de almacenamiento. Para obtener más información sobre
los precios, consulte Precios de Azure Files y Precios de Microsoft Entra Domain
Services .

Pasos siguientes
Para obtener más información sobre Azure Files y la autenticación basada en identidad a
través de SMB, consulte estos recursos:

Planeamiento de una implementación de Azure Files

Introducción: autenticación de Active Directory Domain Services local en SMB para
recursos compartidos de archivos de Azure
Habilitación de la autenticación de Microsoft Entra Domain Services en Azure Files
Habilitación de la autenticación Kerberos de Microsoft Entra para identidades
híbridas en Azure Files
Habilitar la autenticación Kerberos de AD para clientes Linux
P+F
Acceso a recursos compartidos de
archivos de Azure mediante Microsoft
Entra ID con OAuth de Azure Files a
través de REST
Artículo • 21/10/2023

OAuth de Azure Files a través de REST permite acceso de lectura y escritura de nivel de
administrador a los recursos compartidos de archivos de Azure para usuarios y aplicaciones
a través del protocolo de autenticación de OAuth , por medio de Microsoft Entra ID para
el acceso basado en la API de REST. Los usuarios, grupos, servicios de primera entidad,
como Azure Portal, y servicios y aplicaciones de terceros que usan interfaces de REST,
ahora pueden usar la autenticación y autorización de OAuth con una cuenta de Microsoft
Entra para acceder a los datos de recursos compartidos de archivos de Azure. Los cmdlets
de PowerShell y los comandos de la CLI de Azure que llaman a las API de REST también
pueden usar OAuth para acceder a recursos compartidos de archivos de Azure.

） Importante

Debe llamar a la API de REST mediante un encabezado explícito para indicar la

intención de usar el privilegio adicional. Esto también es cierto para el acceso a Azure
PowerShell y la CLI de Azure.

Limitaciones
OAuth de Azure Files a través de REST (versión preliminar) solo admite las API de datos de
REST de Files que admiten operaciones en archivos y directorios. OAuth no se admite en
las API del plano de datos de FilesREST que administran los recursos FileService y FileShare.
Estas API de administración se llaman mediante la clave de cuenta de almacenamiento o el
token de SAS, y se exponen a través del plano de datos por motivos heredados. Se
recomienda usar las API del plano de control (el proveedor de recursos de
almacenamiento: Microsoft.Storage) que admitan OAuth para todas las actividades de
administración relacionadas con los recursos FileService y FileShare.

La autorización de operaciones de datos de archivos con Microsoft Entra ID solo se admite

para las versiones 2022-11-02 y posteriores de la API de REST. Control de versiones para
servicios de Azure Storage.
Casos de uso de clientes
La autenticación y autorización de OAuth con Azure Files a través de la interfaz de la API de
REST pueden beneficiar a los clientes en los escenarios siguientes.

Integración del servicio y desarrollo de aplicaciones

La autenticación y autorización de OAuth permiten a los desarrolladores crear aplicaciones
que accedan a las API de REST de Azure Storage mediante identidades de usuario o
aplicación de Microsoft Entra ID.

Los clientes y asociados también pueden permitir que los servicios propios y de terceros
configuren el acceso necesario de forma segura y transparente a una cuenta de
almacenamiento del cliente.

Las herramientas de DevOps, como Azure Portal, PowerShell y la CLI, AzCopy y Explorador
de Azure Storage pueden administrar datos mediante la identidad del usuario, lo que
elimina la necesidad de administrar o distribuir claves de acceso de almacenamiento.

Identidades administradas
Los clientes con aplicaciones e identidades administradas que requieren acceso a los datos
del recurso compartido de archivos con fines de copia de seguridad, restauración o
auditoría pueden beneficiarse de la autenticación y autorización de OAuth. La aplicación de
permisos de nivel de archivo y directorio para cada identidad agrega complejidad y podría
no ser compatible con determinadas cargas de trabajo. Por ejemplo, es posible que los
clientes quieran autorizar a un servicio de solución de copia de seguridad para acceder a
recursos compartidos de archivos de Azure con acceso de solo lectura a todos los archivos
sin tener en cuenta los permisos específicos del archivo.

Reemplazo de la clave de la cuenta de almacenamiento

Microsoft Entra ID proporciona una mayor seguridad y facilidad de uso que el acceso de
clave compartida. Puede reemplazar el acceso a la clave de la cuenta de almacenamiento
por la autenticación y autorización de OAuth para acceder a recursos compartidos de
archivos de Azure con privilegios de lectura y escritura. Este enfoque también ofrece una
mejor auditoría y seguimiento del acceso específico de los usuarios.

Permisos de acceso y acceso con privilegios para

las operaciones de datos
Para usar la característica OAuth de Azure Files sobre REST, se requieren permisos
adicionales para incluirse en el rol RBAC asignado al usuario, grupo o entidad de servicio.
Se presentan dos nuevas acciones de datos como parte de esta característica:

Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action

Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action

Los usuarios, grupos o entidades de servicio que llaman a la API de REST con OAuth deben
tener asignada la acción readFileBackupSemantics o writeFileBackupSemantics al rol que
permita el acceso a los datos. Este es un requisito para usar esta característica. Para
obtener información sobre los permisos necesarios para llamar a operaciones concretas de
servicio de archivos, vea Permisos para llamar a operaciones de datos.

Esta característica proporciona dos nuevos roles integrados que incluyen estas nuevas
acciones.

Rol Acciones de datos

Lector con Microsoft.Storage/storageAccounts/fileServices/fileShares/files/read

privilegios Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action
de datos de
archivos de
Storage

Colaborador Microsoft.Storage/storageAccounts/fileServices/fileShares/files/read
con Microsoft.Storage/storageAccounts/fileServices/fileShares/files/write
privilegios Microsoft.Storage/storageAccounts/fileServices/fileShares/files/delete
de datos de Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action
archivos de Microsoft.Storage/storageAccounts/fileServices/fileshares/files/modifypermissions/action
Storage

Estos nuevos roles son similares a los roles integrados existentes Lector de recursos
compartidos de SMB de datos de archivos de Storage y Colaborador con privilegios
elevados de recursos compartidos de SMB de datos de archivos de almacenamiento, pero
hay algunas diferencias:

Los nuevos roles contienen las acciones de datos adicionales necesarias para el
acceso de OAuth.

Cuando el usuario, el grupo o la entidad de servicio a los que se asignan los roles
Lector con privilegios de datos de archivo de almacenamiento o Colaborador con
privilegios de archivos de almacenamiento llama a la API de FilesREST Data
mediante OAuth, el usuario, el grupo o la entidad de servicio tendrán:
Lector con privilegios de datos de archivo de almacenamiento: Acceso de lectura
completo en todos los datos de los recursos compartidos para todas las cuentas
 de almacenamiento configuradas, independientemente de los permisos NTFS de
nivel de archivo o directorio establecidos.
Colaborador con privilegios de datos de archivo de almacenamiento: Acceso de
lectura, escritura, eliminación y modificación de ACL completo en todos los datos
de los recursos compartidos para todas las cuentas de almacenamiento
configuradas, independientemente de los permisos NTFS de nivel de archivo o
directorio establecidos.

Con estos permisos y roles especiales, el sistema omitirá los permisos de nivel de
archivo o directorio y permitirá el acceso a los datos del recurso compartido de
archivos.

Con los nuevos roles y acciones de datos, esta característica proporcionará privilegios para
toda la cuenta de almacenamiento, que reemplazan todos los permisos en los archivos y
carpetas de todos los recursos compartidos de los archivos de la cuenta de
almacenamiento. Sin embargo, los nuevos roles solo contienen permisos para acceder a los
servicios de datos. No incluyen ningún permiso para acceder a los servicios de
administración de recursos compartidos de archivos (acciones en recursos compartidos de
archivos). Para usar esta característica, asegúrese de que tiene permisos para acceder a:

la cuenta de almacenamiento
servicios de administración de recursos compartidos de archivos
servicios de datos (los datos del recurso compartido de archivos)

Hay muchos roles integrados que proporcionan acceso a los servicios de administración.
También puede crear roles personalizados con los permisos apropiados. Para más
información sobre el control de acceso basado en roles, consulte Azure RBAC. Para más
información sobre cómo se definen los roles integrados, consulte Descripción de
definiciones de roles.

） Importante

Los casos de uso con caracteres comodín definidos para la ruta de acceso
Microsoft.Storage/storageAccounts/fileServices/* o el ámbito superior heredarán

automáticamente el acceso adicional y los permisos concedidos a través de esta

nueva acción de datos. Para evitar el acceso no deseado o con privilegios excesivos a
Azure Files, hemos implementado comprobaciones adicionales que requieren que los
usuarios y las aplicaciones indiquen explícitamente su intención de usar el privilegio
adicional. Además, se recomienda encarecidamente que los clientes revisen sus
asignaciones de roles RBAC de usuario y reemplacen cualquier uso de caracteres
comodín con permisos explícitos para garantizar la administración adecuada del
acceso a los datos.
Autorización del acceso a los datos de archivo en
el código de la aplicación
La biblioteca cliente de Azure Identity simplifica el proceso de obtener un token de acceso
de OAuth 2.0 para la autorización con Microsoft Entra ID a través del SDK de Azure . Las
versiones más recientes de las bibliotecas cliente de Azure Storage para .NET, Java, Python,
JavaScript y Go se integran con las bibliotecas de Azure Identity para dichos lenguajes para
proporcionar un medio sencillo y seguro de obtener un token de acceso para la
autorización de las solicitudes del servicio de archivos de Azure.

Una ventaja de la biblioteca cliente de Azure Identity es que permite usar el mismo código
para adquirir el token de acceso tanto si la aplicación se ejecuta en el entorno de
desarrollo como en Azure. La biblioteca cliente de Azure Identity devuelve un token de
acceso para una entidad de seguridad. Cuando el código se ejecuta en Azure, la entidad de
seguridad puede ser una identidad administrada para recursos de Azure, una entidad de
servicio, un usuario o un grupo. En el entorno de desarrollo, la biblioteca cliente
proporciona un token de acceso para un usuario o una entidad de servicio con fines de
prueba.

El token de acceso devuelto por la biblioteca cliente de Azure Identity se encapsula en una
credencial de token. A continuación, puede usar la credencial de token para obtener un
objeto de cliente de servicio que se usará para realizar operaciones autorizadas en el
servicio de Azure Files.

Este es un código de ejemplo:

ASP.NET (C#)

using Azure.Core;
using Azure.Identity;
using Azure.Storage.Files.Shares;
using Azure.Storage.Files.Shares.Models;

namespace FilesOAuthSample
{
internal class Program
{
static async Task Main(string[] args)
{
string tenantId = "";
string appId = "";
string appSecret = "";
string aadEndpoint = "";
string accountUri = "";
string connectionString = "";
string shareName = "testShare";
string directoryName = "testDirectory";
string fileName = "testFile";
 ShareClient sharedKeyShareClient = new
ShareClient(connectionString, shareName);
await sharedKeyShareClient.CreateIfNotExistsAsync();

TokenCredential tokenCredential = new ClientSecretCredential(

tenantId,
appId,
appSecret,
new TokenCredentialOptions()
{
AuthorityHost = new Uri(aadEndpoint)
});

ShareClientOptions clientOptions = new

ShareClientOptions(ShareClientOptions.ServiceVersion.V2021_12_02);

// Set Allow Trailing Dot and Source Allow Trailing Dot.

clientOptions.AllowTrailingDot = true;
clientOptions.SourceAllowTrailingDot = true;

// x-ms-file-intent=backup will automatically be applied to all

APIs
// where it is required in derived clients.

clientOptions.ShareTokenIntent = ShareTokenIntent.Backup;
ShareServiceClient shareServiceClient = new ShareServiceClient(
new Uri(accountUri),
tokenCredential,
clientOptions);

ShareClient shareClient =
shareServiceClient.GetShareClient(shareName);
ShareDirectoryClient directoryClient =
shareClient.GetDirectoryClient(directoryName);
await directoryClient.CreateAsync();

ShareFileClient fileClient =
directoryClient.GetFileClient(fileName);
await fileClient.CreateAsync(maxSize: 1024);
await fileClient.GetPropertiesAsync();
await sharedKeyShareClient.DeleteIfExistsAsync();
}
}
}

Autorización del acceso mediante la API del

plano de datos FileREST
También puede autorizar el acceso a los datos de archivo mediante el Azure Portal o Azure
PowerShell.
Azure Portal

Azure Portal puede usar la cuenta de Microsoft Entra o las claves de acceso de
cuenta de almacenamiento para acceder a los datos de archivos de una cuenta de
almacenamiento de Azure. El esquema de autorización que use Azure Portal depende
de los roles de Azure que tenga asignados.

Si intenta acceder a datos de archivos, Azure Portal primero comprueba si tiene

asignado un rol de Azure con Microsoft.Storage/storageAccounts/listkeys/action . Si
tiene un rol asignado con esta acción, Azure Portal usa la clave de cuenta para acceder
a los datos de archivos mediante la autorización de clave compartida. Si no tiene un
rol asignado con esta acción, Azure Portal intenta acceder a los datos mediante la
cuenta de Microsoft Entra.

Para acceder a datos de archivos desde Azure Portal con la cuenta de Microsoft Entra,
necesita permisos para acceder a datos de archivos y, también, permisos para
examinar los recursos de la cuenta de almacenamiento en Azure Portal. Los roles
integrados que proporciona Azure conceden acceso a recursos de archivos, pero no
conceden permisos a los recursos de la cuenta de almacenamiento. Por este motivo, el
acceso al portal también requiere la asignación de un rol de Azure Resource Manager
(ARM), como el rol Lector, con ámbito limitado al nivel de la cuenta de
almacenamiento o superior. El rol Lector concede los permisos más restringidos, pero
otro rol de ARM que conceda acceso a los recursos de administración de la cuenta de
almacenamiento también es aceptable.

Azure Portal indica qué esquema de autorización se está usando al examinar un

contenedor. Para obtener más información sobre acceso a los datos en el portal,
consulte Elección de la forma de autorizar el acceso a los datos de archivos en Azure
Portal.

Consulte también
Elegir cómo autorizar el acceso a los datos de archivo en Azure Portal
Descripción de la facturación de Azure
Files
Artículo • 09/04/2023

Azure Files proporciona dos modelos de facturación distintos: aprovisionado y pago por
uso. El modelo aprovisionado solo está disponible para los recursos compartidos de
archivos prémium, que son recursos compartidos de archivos implementados en el tipo
de cuenta de almacenamiento FileStorage. El modelo de pago por uso solo está
disponible para los recursos compartidos de archivos estándar, que son recursos
compartidos de archivos implementados en el tipo de cuenta de almacenamiento de
uso general, versión 2 (GPv2) . En este artículo se explica cómo funcionan ambos
modelos con el fin de ayudarle a entender la factura mensual de Azure Files.

Azure Unblogged - Pricing Up Azure Files

Este vídeo es una entrevista donde se describen los conceptos básicos del modelo de
facturación de Azure Files. Se abordan la optimización de los recursos compartidos de
archivos de Azure para lograr los costos más bajos posibles y la comparación de
Azure Files con otras ofertas de almacenamiento de archivos en el entorno local y en la
nube.

Para obtener información sobre los precios de Azure Files, vea la página de precios de
Azure Files .

Se aplica a
Tipo de recurso compartido de archivos SMB NFS
 Tipo de recurso compartido de archivos SMB NFS

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS

Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Unidades de almacenamiento
Azure Files usa unidades de medida de base 2 para representar la capacidad de
almacenamiento: KiB, MiB, GiB y TiB.

Acrónimo Definición Unidad

KiB 1024 bytes kibibyte

MiB 1024 KiB (1 048 576 bytes) mebibyte

GiB 1024 MiB (1 073 741 824 bytes) gibibyte

TiB 1024 GiB (1 099 511 627 776 bytes) tebibyte

Aunque la mayoría de los sistemas operativos y las herramientas utilizan habitualmente

las unidades de medida de base 2 para medir las cantidades de almacenamiento, con
frecuencia se etiquetan erróneamente como unidades de base 10, con las que quizá
esté más familiarizado: KB, MB, GB y TB. Aunque los motivos pueden variar, la razón
común por la que los sistemas operativos como Windows etiquetan incorrectamente las
unidades de almacenamiento es porque muchos sistemas operativos comenzaron a usar
estos acrónimos antes de que se estandarizaran mediante IEC, BIPM y NIST.

En la tabla siguiente, se muestra cómo miden y etiquetan el almacenamiento los

sistemas operativos comunes:

Sistema Sistema de medición Etiquetado

operativo

Windows Base 2 Etiquetas incorrectas uniformes como base 10.

Distribuciones de Normalmente base 2, El etiquetado y la alineación incoherentes entre

Linux algún software puede la medición y el etiquetado depende del paquete
usar base 10 de software.

macOS, iOS y el Base 10 Etiquetas uniformes como base 10 .

sistema operativo
para iPad
Consulte con el proveedor del sistema operativo si su sistema operativo no aparece en
la lista.

Lista de comprobación del costo total de

propiedad del recurso compartido de archivos
Si va a migrar a Azure Files desde el entorno local o va a comparar Azure Files con otras
soluciones de almacenamiento en la nube, debe tener en cuenta los siguientes factores
para garantizar una comparación justa entre elementos equivalentes:

¿Cómo se paga por el almacenamiento, IOPS y el ancho de banda? Con Azure

Files, el modelo de facturación que use depende de si va a implementar recursos
compartidos de archivos prémium o estándar. La mayoría de las soluciones en la
nube tienen modelos en consonancia con los principios del almacenamiento
aprovisionado, como determinismo de precios y simplicidad, o el almacenamiento
de pago por uso, que puede optimizar los costes al cobrar solo por lo que
realmente se usa. En el caso de los modelos aprovisionados, son de especial
interés el tamaño mínimo del recurso compartido aprovisionado, la unidad de
aprovisionamiento y la posibilidad de aumentar y disminuir el aprovisionamiento.

¿Hay algún método para optimizar los costos de almacenamiento? Puede usar
reservas de Azure Files para lograr un descuento de hasta un 36 % en el
almacenamiento. Otras soluciones pueden emplear estrategias como la
desduplicación o compresión para optimizar de manera opcional la eficacia del
almacenamiento. Sin embargo, estas estrategias de optimización del
almacenamiento suelen tener costos no monetarios, como una reducción del
rendimiento. Las reservas no tienen efectos secundarios en el rendimiento.

¿Cómo se consigue la resistencia y la redundancia del almacenamiento? Con

Azure Files, la resistencia y la redundancia del almacenamiento están integradas en
la oferta del producto. Todos los niveles y opciones de redundancia garantizan una
alta disponibilidad de los datos y el acceso a al menos tres copias de estos. Al
considerar otras opciones de almacenamiento de archivos, tenga en cuenta si la
resistencia y redundancia del almacenamiento están integradas o es algo de lo que
tenga que encargarse personalmente.

¿Qué tiene que administrar? Con Azure Files, la unidad básica de administración
es una cuenta de almacenamiento. Otras soluciones pueden requerir
administración adicional, como actualizaciones del sistema operativo o
administración de recursos virtuales (máquinas virtuales, discos, direcciones IP de
red, etc.).
 ¿Cuáles son los costos de los productos de valor añadido, como la copia de
seguridad, la seguridad, etc.? Azure Files admite integraciones con varios servicios
de valor añadido propios y de terceros. Servicios de valor añadido como Azure
Backup, Azure File Sync y Azure Defender, que proporcionan copia de seguridad,
replicación y almacenamiento en caché, y funcionalidad de seguridad adicional
para Azure Files. Las soluciones de valor añadido, ya sean locales o en la nube,
tienen sus propios costos de licencias y de producto, pero a menudo se consideran
parte del costo total de propiedad para el almacenamiento de archivos.

Reservations
Azure Files admite reservas (también conocidas como instancias reservadas), lo que le
permite lograr un descuento en el almacenamiento mediante la confirmación previa del
uso del almacenamiento. Debe considerar la posibilidad de comprar instancias
reservadas para cualquier carga de trabajo de producción o cargas de trabajo de
desarrollo y pruebas con superficies coherentes. Al comprar una reserva, debe
especificar las siguientes dimensiones:

Tamaño de capacidad: las reservas pueden ser de 10 TiB o 100 TiB, con descuentos
más significativos por la compra de una reserva de capacidad mayor. Puede
comprar varias reservas, incluso reservas de diferentes tamaños de capacidad para
satisfacer los requisitos de la carga de trabajo. Por ejemplo, si la implementación
de producción tiene 120 TiB de recursos compartidos de archivos, podría comprar
una reserva de 100 TiB y dos reservas de 10 TiB para satisfacer los requisitos
totales de capacidad de almacenamiento.
Período: las reservas se pueden comprar durante un período de un año o tres
años, con descuentos más significativos por comprar un período de reserva más
largo.
Nivel: el nivel de Azure Files para la reserva. Las reservas están disponibles
actualmente para los niveles de acceso prémium, frecuente y esporádico.
Ubicación: la región de Azure para la reserva. Las reservas están disponibles en un
subconjunto de regiones de Azure.
Redundancia: la redundancia de almacenamiento para la reserva. Las reservas se
admiten para todas los redundancias que admite Azure Files, como LRS, ZRS, GRS
y GZRS.
Frecuencia de facturación: indica la frecuencia con la que se factura la cuenta para
la reserva. Entre las opciones se incluyen Mensual o Por adelantado.

Una vez que compre una reserva, el uso de almacenamiento existente la consumirá
automáticamente. Si usa más espacio de almacenamiento del que ha reservado, pagará
el precio de venta del saldo que no esté cubierto por la reserva. Los cargos por
transacción, ancho de banda, transferencia de datos y almacenamiento de metadatos no
se incluyen en la reserva.

Hay diferencias en el funcionamiento de las reservas con las instantáneas de recursos

compartidos de archivos de Azure para recursos compartidos de archivos estándar y
premium. Si va a tomar instantáneas de recursos compartidos estándar, las diferenciales
de instantáneas se cuentan para la reserva y se facturan como parte del medidor de
almacenamiento usado normal. Sin embargo, si va a tomar instantáneas de recursos
compartidos de archivos Premium, se usa un medidor independiente para facturar las
instantáneas y estas no cuentan para la reserva. Para más información, consulte
Instantánea.

Para más información sobre cómo comprar reservas, consulte Optimización de costos
para Azure Files con las reservas.

Modelo aprovisionado
Azure Files usa un modelo aprovisionado para los recursos compartidos de archivos
prémium. En un modelo de facturación aprovisionado, debe especificar de forma
proactiva cuáles son los requisitos de almacenamiento del servicio Azure Files, en lugar
de que se le aplique una factura basada en lo que usa. Un modelo aprovisionado para el
almacenamiento es similar a comprar una solución de almacenamiento local porque, al
aprovisionar un recurso compartido de archivos de Azure con una determinada cantidad
de capacidad de almacenamiento, se paga por esa capacidad de almacenamiento
independientemente de si la usa o no. A diferencia de la compra de soportes físicos
locales, los recursos compartidos de archivos aprovisionados se pueden escalar o
reducir verticalmente de forma dinámica en función de las características de
rendimiento de almacenamiento y de E/S.

El tamaño aprovisionado del recurso compartido de archivos puede aumentar en

cualquier momento, pero solo se puede reducir una vez transcurridas 24 horas desde el
último aumento. Después de esperar 24 horas sin un aumento de cuota, puede reducir
el recurso compartido tantas veces como quiera hasta que lo vuelva a aumentar. Los
cambios de escala de IOPS/rendimiento se aplicarán minutos después del cambio de
tamaño aprovisionado.

Es posible reducir el tamaño del recurso compartido aprovisionado por debajo de los
GiB usados. Si lo hace, no perderá datos, pero se le seguirá facturando el tamaño usado
y seguirá recibiendo el rendimiento del recurso compartido aprovisionado, no del
tamaño usado.
Método de aprovisionamiento
Al aprovisionar un recurso compartido de archivos prémium, se especifica la cantidad de
GiB que requiere la carga de trabajo. Cada GiB aprovisionado permite beneficiarse de
más IOPS y rendimiento con una proporción fija. Además de la IOPS de línea de base
garantizada, cada recurso compartido de archivos prémium admite ráfagas dentro de lo
posible. Las fórmulas de IOPS y rendimiento son las siguientes:

Elemento Value

Tamaño máximo de un recurso 100 GiB

compartido de archivos

Unidad de aprovisionamiento 1 GiB

Fórmula de IOPS de línea de base MIN(3000 + 1 * ProvisionedStorageGiB, 100000)

Límite de aumento MIN(MAX(10000, 3 * ProvisionedStorageGiB), 100000)

Créditos de ráfaga (BurstLimit - BaselineIOPS) * 3600

Tasa de rendimiento (entrada + 100 + CEILING(0.04 * ProvisionedStorageGiB) +

salida) (MiB/seg.) CEILING(0.06 * ProvisionedStorageGiB)

En la tabla siguiente se ilustran algunos ejemplos de estas fórmulas para los tamaños de
recursos compartidos aprovisionados:

Capacidad IOPS IOPS de Créditos de Rendimiento (entrada + salida)

(GiB) base ráfaga ráfaga (MiB/s)

100 3100 Hasta 10 000 24 840 000 110

500 3500 Hasta 10 000 23 400 000 150

1024 4 024 Hasta 10 000 21 513 600 203

5120 8120 Hasta 15 360 26 064 000 613

10 240 13 240 Hasta 30 720 62 928 000 1125

33 792 36 792 Hasta 227 548 800 3480

100 000

51 200 54 200 Hasta 164 880 000 5220

100 000

102 400 100 000 Hasta 0 10 340

100 000
El rendimiento efectivo de los recursos compartidos de archivos está sujeto a los límites
de red de la máquina, el ancho de banda de red disponible, los tamaños de E/S y el
paralelismo, entre muchos otros factores. Para aprovechar al máximo la paralelización,
se recomienda habilitar SMB multicanal en los recursos compartidos de archivos
premium. Para más información, consulte Habilitar SMB multicanal. Consulte en el
artículo sobre rendimiento de SMB multicanal y en la guía de solución de problemas de
rendimiento algunos problemas de rendimiento comunes y sus soluciones alternativas.

Creación de ráfagas
Si la carga de trabajo necesita un rendimiento adicional para satisfacer los picos de
demanda, el recurso compartido puede usar créditos de expansión para superar el límite
de IOPS de línea base del recurso compartido, con el fin de proporcionar al recurso
compartido el rendimiento que necesita para satisfacer la demanda. La creación de
ráfagas está automatizada y funciona de acuerdo con un sistema de crédito. La
expansión funciona en la medida de lo posible y el límite de expansión no es una
garantía.

Cada vez que el tráfico para el recurso compartido de archivos se encuentra por debajo
del valor de IOPS de la línea de base, se acumulan créditos en un cubo de ráfagas. Los
créditos obtenidos se usan más adelante para habilitar la expansión cuando las
operaciones superarían la IOPS de línea base.

Cada vez que un recurso compartido supera el valor de IOPS de línea base y tiene
créditos en un cubo de expansión, este aumentará hasta alcanzar la velocidad máxima
permitida. Los recursos compartidos pueden seguir con la expansión siempre y cuando
queden créditos, pero esto se basa en el número de créditos de expansión acumulados.
Cada E/S que supere el valor de IOPS de línea base consume un crédito y, una vez que
se consumen todos los créditos, el recurso compartido volvería al valor de IOPS de la
línea base.

Los créditos de recursos compartidos tienen tres estados:

Acumulado: cuando el recurso compartido de archivos usa un valor inferior al de

IOPS de línea de base.
Rechazado: cuando el recurso compartido de archivos usa más que el valor de
IOPS de la línea base y en el modo de aumento.
Constante: cuando el recurso compartido de archivos usa exactamente el valor de
IOPS de línea de base, no hay créditos acumulados ni usados.

Los nuevos recursos compartidos de archivo empiezan con la cantidad total de créditos
del cubo de ráfagas. Los créditos de expansión no se acumularán si el valor de IOPS del
recurso compartido cae por debajo del valor de IOPS de la línea base debido a una
limitación por parte del servidor.

Modelo de pago por uso

Azure Files usa un modelo de facturación de pago por uso para los recursos
compartidos de archivos estándar. En un modelo de facturación de pago por uso, la
cantidad que se paga se determina según el volumen que se usa realmente, en lugar de
basarse en una cantidad aprovisionada. En un nivel alto, se paga un costo por la
cantidad de datos lógicos almacenados y, a continuación, un conjunto adicional de
transacciones en función del uso de esos datos. Un modelo de pago por uso puede ser
rentable, ya que no es necesario sobreaprovisionar para tener en cuenta los requisitos
futuros de crecimiento o rendimiento. Tampoco es necesario desaprovisionar si la carga
de trabajo y la superficie de datos varían con el tiempo. Por otro lado, un modelo de
pago por uso también puede ser difícil de planear como parte de un proceso de
presupuesto, porque este modelo se basa en el consumo del usuario final.

Diferencias en los niveles estándar

Al crear un recurso compartido de archivos estándar, puede elegir entre los siguientes
niveles: optimizado para transacciones, acceso frecuente y acceso esporádico. Los tres
niveles se almacenan en el mismo hardware de almacenamiento estándar. La principal
diferencia de estos tres niveles son los precios de almacenamiento de datos en reposo,
que son menores en los niveles de acceso esporádico, y los precios de las transacciones,
que son más altos en estos mismos niveles. Esto significa lo siguiente:

La transacción optimizada, como su nombre implica, optimiza el precio de las

cargas de trabajo de mucha transacción. La transacción optimizada tiene el precio
de almacenamiento de datos en reposo más alto, pero los precios de transacción
más bajos.
El acceso frecuente es para cargas de trabajo activas que no implican un gran
número de transacciones, y tiene un precio de almacenamiento de datos en
reposo ligeramente inferior, pero los precios de transacción son algo mayores en
comparación con la transacción optimizada. Considérelo como el punto medio
entre los niveles de transacción optimizada y acceso esporádico.
El acceso esporádico optimiza el precio de las cargas de trabajo que no tienen
mucha actividad y ofrece el precio más bajo de datos en reposo, pero el más alto
en las transacciones.

Si coloca una carga de trabajo a la que se accede con poca frecuencia en el nivel de
transacción optimizada, no pagará casi nada por las pocas horas del mes en que realiza
transacciones en el recurso compartido. Sin embargo, pagará una cantidad elevada por
los costos de almacenamiento de datos. Si tuviera que trasladar este mismo recurso
compartido al nivel de acceso esporádico, tampoco pagaría casi nada por los costos de
transacción, simplemente porque no realiza transacciones con mucha frecuencia en esta
carga de trabajo. Sin embargo, el nivel de acceso esporádico ofrece un precio de
almacenamiento de datos mucho más barato. La selección del nivel adecuado para su
caso de uso le permite reducir considerablemente los costos.

Del mismo modo, si coloca en el nivel de acceso esporádico una carga de trabajo a la
que accede con mucha frecuencia, incurrirá en muchos más costos por las
transacciones, pero pagará menos por el almacenamiento de datos. Esto puede derivar
en una situación en la que el aumento de los costos por los precios de las transacciones
sobrepasan el ahorro obtenido por el precio más reducido del almacenamiento de
datos, de tal forma que pagará más dinero en el nivel de acceso esporádico en
comparación con el de transacción optimizada. Para algunos niveles de uso, es posible
que el nivel de acceso frecuente sea el nivel más rentable y el nivel de acceso
esporádico sea más caro que el optimizado para transacciones.

El nivel de la carga de trabajo y de la actividad determinarán el nivel más rentable del

recurso compartido de archivos estándar. En la práctica, la mejor manera de elegir el
nivel más rentable es examinar el consumo de recursos real del recurso compartido
(datos almacenados, transacciones de escritura, etc.). En el caso de los recursos
compartidos de archivos estándar, se recomienda comenzar en el nivel optimizado para
transacciones durante la migración inicial a Azure Files y, luego, seleccionar el nivel
correcto en función del uso una vez completada la migración. El uso de transacciones
durante la migración no suele indicar el uso normal de las transacciones.

¿Qué son las transacciones?

Al montar un recurso compartido de archivos de Azure en un equipo mediante SMB, el
recurso compartido de archivos de Azure se expone en el equipo como si fuera
almacenamiento local. Esto significa que las aplicaciones, los scripts y otros programas
que tenga en el equipo pueden acceder a los archivos y las carpetas del recurso
compartido de archivos de Azure sin necesidad de saber que están almacenados en
Azure.

Al leer o escribir en un archivo, la aplicación que se usa hace una serie de llamadas API a
la API del sistema de archivos proporcionada por el sistema operativo. Luego, el sistema
operativo interpreta estas llamadas en transacciones de protocolo SMB, que se envían a
través de la conexión a Azure Files para completar. Una tarea que el usuario final percibe
como una sola operación, por ejemplo, leer un archivo de principio a fin, se puede
traducir en varias transacciones SMB atendidas por Azure Files.
Como principio, el modelo de facturación de pago por uso que usan los recursos
compartidos de archivos estándar factura en función del uso. Las transacciones SMB y
FileREST hechas por las aplicaciones, scripts y otros programas usados por los usuarios
representan el uso del recurso compartido de archivos y se muestran como parte de la
factura. El mismo concepto se aplica a los servicios en la nube de valor añadido que
puede agregar a su recurso compartido, como Azure File Sync o Azure Backup. Las
transacciones se agrupan en cinco categorías diferentes que tienen precios diferentes
en función de su impacto en el recurso compartido de archivos de Azure. Estas
categorías son: escritura, enumeración, lectura, otros y eliminación.

En la tabla siguiente se muestra la categorización de cada transacción:

Cubo de transacciones Operaciones de Operaciones de datos

administración

Transacciones de escritura CreateShare CopyFile

SetFileServiceProperties Create
SetShareMetadata CreateDirectory
SetShareProperties CreateFile
SetShareAcl PutRange
SnapshotShare PutRangeFromURL
RestoreShare SetDirectoryMetadata
SetFileMetadata
SetFileProperties
SetInfo
Write
PutFilePermission
Flush
SetDirectoryProperties

Transacciones de lista ListShares ListFileRanges

ListFiles
ListHandles
Cubo de transacciones Operaciones de Operaciones de datos
administración

Transacciones de lectura GetFileServiceProperties FilePreflightRequest

GetShareAcl GetDirectoryMetadata
GetShareMetadata GetDirectoryProperties
GetShareProperties GetFile
GetShareStats GetFileCopyInformation
GetFileMetadata
GetFileProperties
QueryDirectory
QueryInfo
Read
GetFilePermission

Otros/Transacciones de AcquireShareLease AbortCopyFile

protocolo BreakShareLease Cancel
ReleaseShareLease ChangeNotify
RenewShareLease Close
ChangeShareLease Echo
Ioctl
Lock
Logoff
Negotiate
OplockBreak
SessionSetup
TreeConnect
TreeDisconnect
CloseHandles
AcquireFileLease
BreakFileLease
ChangeFileLease
ReleaseFileLease

Transacciones de eliminación DeleteShare ClearRange

DeleteDirectory
DeleteFile

７ Nota

NFS 4.1 solo está disponible para los recursos compartidos de archivos premium,
que usan el modelo de facturación aprovisionado. Las transacciones no afectan a la
facturación de los recursos compartidos de archivos prémium.
Cambio entre niveles estándar
Aunque puede cambiar un recurso compartido de archivos estándar entre los tres
niveles de recursos compartidos de archivos estándar, el procedimiento recomendado
para optimizar los costos después de la migración inicial es la elección del nivel óptimo
más rentable en el que estar y permanecer allí a menos que cambie el patrón de acceso.
Esto se debe a que el cambio del nivel de un recurso compartido de archivos estándar
da como resultado costos adicionales de la siguiente manera:

Transacciones: si un recurso compartido se pasa de un nivel de acceso frecuente a

un nivel esporádico, incurrirá en la carga de transacciones de escritura del nivel
más esporádico en cada archivo del recurso compartido. Por contra, si un recurso
compartido se pasa de un nivel de acceso esporádico a un nivel frecuente, incurrirá
en la carga de transacciones de lectura del nivel más esporádico en cada archivo
del recurso compartido.

Recuperación de datos: si va a mover del nivel acceso esporádico al frecuente u

optimizado para transacciones, incurrirá en un cargo por recuperación de datos
según el tamaño de los datos movidos. Solo el nivel de acceso esporádico tiene un
cargo por recuperación de datos.

En la tabla siguiente se muestra el desglose de costos de los niveles que se van a mover:

Nivel Optimizado para Frecuente (destino) Esporádico (destino)

transacciones
(destino)

Optimizado para -- 1 transacción de 1 transacción de

transacciones escritura escritura
(origen) frecuente por esporádica por
archivo. archivo.

Frecuente 1 transacción de -- 1 transacción de

(origen) lectura frecuente escritura
por archivo. esporádica por
archivo.

Esporádico 1 transacción de 1 transacción de --

(origen) lectura lectura
esporádica por esporádica por
archivo. archivo.
Recuperación de Recuperación de
datos por GiB datos por GiB
total usado. total usado.
Aunque no hay ningún límite formal sobre la frecuencia con la que se puede cambiar el
nivel del recurso compartido de archivos, el recurso compartido tardará en hacer la
transición en función de la cantidad de datos del recurso compartido. No se puede
cambiar el nivel del recurso compartido mientras el recurso compartido de archivos
hace la transición entre niveles. Cambiar el nivel del recurso compartido de archivos no
afecta al acceso normal al recurso compartido de archivos.

Aunque no hay ningún mecanismo directo para moverse entre recursos compartidos de
archivos premium y estándar, porque están contenidos en diferentes tipos de cuenta de
almacenamiento, puede usar una herramienta de copia como Robocopy para moverse
entre recursos compartidos de archivos premium y estándar.

Elección de un nivel
Independientemente de cómo migre los datos existentes a Azure Files, se recomienda
crear inicialmente el recurso compartido de archivos en el nivel optimizado para
transacciones debido al gran número de transacciones en las que se incurre durante la
migración. Luego de completada la migración y de haber trabajado durante unos días o
semanas con un uso normal, puede conectar los recuentos de transacciones a la
calculadora de precios para averiguar qué nivel es más adecuado para la carga de
trabajo.

Dado que los recursos compartidos de archivos estándar solo muestran la información
de transacciones en el nivel de cuenta de almacenamiento, el uso de métricas de
almacenamiento para calcular qué nivel es más barato en el nivel de recurso compartido
de archivos es una ciencia imperfecta. Si es posible, se recomienda implementar solo un
recurso compartido de archivos en cada cuenta de almacenamiento para garantizar una
visibilidad completa de la facturación.

Para ver las transacciones anteriores:

1. Vaya a la cuenta de almacenamiento y seleccione Métricas en la barra de

navegación izquierda.
2. Seleccione Ámbito como nombre de la cuenta de almacenamiento, Espacio de
nombres de métricas como "Archivo", Métrica como "Transacciones" y
Agregación como "Suma".
3. Haga clic en Aplicar división.
4. Seleccione Valores como "Nombre de API". Seleccione los valores deseados en
Límite y Orden.
5. Seleccione el período de tiempo deseado.

７ Nota
 Asegúrese de ver las transacciones durante un período de tiempo para obtener una
mejor idea del número medio de transacciones. Asegúrese de que el período de
tiempo elegido no se superponga con el aprovisionamiento inicial. Multiplique el
número medio de transacciones durante este período de tiempo para obtener las
transacciones estimadas durante todo un mes.

Tamaño aprovisionado o cuota, tamaño lógico

y tamaño físico
Azure Files realiza un seguimiento de tres cantidades distintas con respecto a la
capacidad del recurso compartido:

Tamaño o cuota aprovisionados: con los recursos compartidos de archivos

premium y estándar, se especifica el tamaño máximo al que puede crecer el
recurso compartido de archivos. En los recursos compartidos de archivos premium,
este valor se llama tamaño aprovisionado y la cantidad que se aprovisiona es lo
que paga, independientemente de la cantidad que realmente use. En los recursos
compartidos de archivos estándar, este valor se llama cuota y no afecta
directamente a la factura. El tamaño aprovisionado es un campo obligatorio para
los recursos compartidos de archivos prémium. En el caso de los recursos
compartidos de archivos estándar, si el tamaño aprovisionado no se especifica
directamente, el recurso compartido tendrá como valor predeterminado el valor
máximo admitido por la cuenta de almacenamiento. Serán 5 TiB o 100 TiB, en
función del tipo y la configuración de la cuenta de almacenamiento.

Tamaño lógico: El tamaño lógico de un recurso compartido de archivos o un

archivo está relacionado con el tamaño que tiene sin tener en cuenta cómo se
almacena realmente, donde se pueden aplicar optimizaciones adicionales. Una
manera de pensar en esto es que el tamaño lógico del archivo es cuántos KiB, MiB
o GiB se transferirán mediante la conexión si los copia en otra ubicación. En los
recursos compartidos de archivos premium y estándar, el tamaño lógico total del
recurso compartido de archivos es lo que se usa para el cumplimiento del tamaño
o la cuota aprovisionados. En los recursos compartidos de archivos estándar, el
tamaño lógico es la cantidad utilizada para la facturación del uso de datos en
reposo. El tamaño lógico se conoce como "tamaño" en el cuadro de diálogo de
propiedades de Windows para un archivo o carpeta y como "longitud del
contenido" para las métricas de Azure Files.

Tamaño físico: el tamaño físico del archivo está relacionado con el tamaño del
archivo como codificado en el disco. Esto puede alinearse con el tamaño lógico del
 archivo, o puede ser menor, en función de cómo haya escrito el archivo el sistema
operativo. Un motivo común para que el tamaño lógico y el tamaño físico sean
diferentes se encuentra en el uso de archivos dispersos. El tamaño físico de los
archivos del recurso compartido se usa para la facturación de instantáneas, aunque
los intervalos asignados se compartan entre instantáneas si no cambian
(almacenamiento diferencial). Para más información sobre cómo se facturan las
instantáneas en Azure Files, consulte Instantáneas.

Instantáneas
Azure Files admite instantáneas, que son similares a las instantáneas de volumen (VSS)
en el servidor de archivos Windows. Las instantáneas siempre son diferenciales del
recurso compartido activo y entre sí, lo que significa que siempre paga solo por lo que
es diferente en cada instantánea. Para más información sobre las instantáneas de
recursos compartidos, consulte Información general de las instantáneas de recurso
compartido de Azure Files.

Las instantáneas no cuentan para los límites de tamaño del recurso compartido de
archivos, aunque está limitado a un número específico de instantáneas. Para ver los
límites actuales de instantáneas, consulte Objetivos de escala de recursos compartidos
de archivos de Azure.

Las instantáneas siempre se facturan en función del uso diferencial del almacenamiento
de cada instantánea; sin embargo, esto tiene un aspecto ligeramente diferente entre los
recursos compartidos de archivos premium y los recursos compartidos de archivos
estándar:

En los recursos compartidos de archivos premium, las instantáneas se facturan con

su propio medidor de instantáneas, que tiene un precio reducido sobre el precio
del almacenamiento aprovisionado. Esto significa que verá un elemento de línea
independiente en la factura, que representa las instantáneas de recursos
compartidos de archivos prémium para cada cuenta de almacenamiento de tipo
FileStorage en la factura.

En los recursos compartidos de archivos estándar, las instantáneas se facturan

como parte del medidor normal del almacenamiento usado, aunque también se le
factura por el costo diferencial de la instantánea. Esto significa que no verá un
elemento de línea independiente en la factura, que representa las instantáneas
para cada cuenta de almacenamiento estándar que contenga recursos
compartidos de archivos de Azure. Esto también significa que el uso diferencial de
instantáneas se tiene en cuenta para las reservas adquiridas para recursos
compartidos de archivos estándar.
Los servicios de valor añadido para Azure Files pueden usar instantáneas como parte de
su propuesta de valor. Consulte Servicios de valor añadido para más información sobre
cómo se usan las instantáneas.

Servicios de valor añadido

Al igual que las soluciones de almacenamiento locales que ofrecen características o
integraciones de productos propios y de terceros para añadir valor a los recursos
compartidos de archivos hospedados, Azure Files ofrece puntos de integración para
productos propios y de terceros para su integración con los recursos compartidos de
archivos propiedad del cliente. Aunque estas soluciones pueden proporcionar un valor
adicional considerable para Azure Files, debe tener en cuenta los costos extra que
agregan estos servicios al costo total de una solución de Azure Files.

Los costos se dividen en tres grupos:

Costos de licencias del servicio de valor añadido. Estos pueden tener la forma de
un costo fijo por cliente, usuario final (a veces llamado "costo principal"), recurso
compartido de archivos o cuenta de almacenamiento de Azure. También pueden
basarse en unidades de uso del almacenamiento, como un costo fijo para cada
fragmento de datos de 500 GiB en el recurso compartido de archivos.

Costos de transacciones del servicio de valor añadido. Algunos servicios de valor

añadido tienen su propio concepto de transacciones, distinto de lo que Azure Files
ve como una transacción. Estas transacciones se mostrarán en la factura en los
cargos del servicio de valor añadido; sin embargo, están directamente relacionados
con cómo se usa el servicio de valor añadido con el recurso compartido de
archivos.

Costos de Azure Files por usar un servicio de valor añadido. Azure Files no cobra
directamente a los clientes los costos por agregar servicios de valor añadido, pero
como parte de agregar valor al recurso compartido de archivos de Azure, el
servicio de valor añadido podría aumentar los costos que ve en el recurso
compartido de archivos de Azure. Esto es fácil de ver con los recursos compartidos
de archivos estándar, ya que los recursos compartidos de archivos estándar tienen
un modelo de pago por uso con cargos por transacciones. Si el servicio de valor
añadido realiza transacciones en el recurso compartido de archivos en su nombre,
se mostrarán en la factura de transacciones de Azure Files aunque no haya hecho
directamente esas transacciones usted mismo. Esto también se aplica a los
recursos compartidos de archivos premium, aunque puede ser menos notable. Las
transacciones adicionales en los recursos compartidos de archivos prémium de los
servicios de valor añadido cuentan para las cifras de IOPS aprovisionadas, lo que
 significa que los servicios de valor añadido pueden requerir el aprovisionamiento
de más almacenamiento para tener suficientes IOPS o rendimiento disponibles
para la carga de trabajo.

Al calcular el costo total de propiedad del recurso compartido de archivos, debe tener
en cuenta los costos de Azure Files y de todos los servicios de valor añadido que le
gustaría usar con Azure Files.

Hay varios servicios de valor añadido propios y de terceros. En este documento, se trata
un subconjunto de los servicios propios comunes que usan los clientes con los recursos
compartidos de archivos de Azure. Para obtener información sobre los servicios que no
aparecen aquí, consulte la página de precios de ese servicio.

Azure File Sync

Azure File Sync es un servicio de valor añadido para Azure Files que sincroniza uno o
varios recursos compartidos de archivos locales Windows con un recurso compartido de
archivos de Azure. Dado que el recurso compartido de archivos de Azure en la nube
tiene una copia completa de los datos en un recurso compartido de archivos
sincronizado que está disponible en el entorno local, puede transformar el servidor de
archivos Windows local en una memoria caché del recurso compartido de archivos de
Azure para reducir la superficie local. Para más información, consulte ¿Qué es Azure File
Sync?

Al considerar el costo total de propiedad de una solución implementada con Azure File
Sync, debe tener en cuenta los siguientes aspectos de costos:

Costos operativos y de capital de los servidores de archivos Windows con uno o

varios puntos de conexión de servidor. Azure File Sync como solución de
replicación es independiente de dónde están los servidores de archivos Windows
que se sincronizan con Azure Files, podrían hospedarse en el entorno local, en una
máquina virtual de Azure o, incluso, en otra nube. A menos que utilice Azure File
Sync con un servidor de archivos Windows hospedado en una máquina virtual de
Azure, los costos de capital (es decir, los costos iniciales de hardware de la
solución) y los costos operativos (es decir, el costo de personal y de electricidad,
electricidad, etc.) no formarán parte de la factura de Azure, pero seguirán siendo
una parte del costo total de propiedad. Debe tener en cuenta la cantidad de datos
que necesita almacenar en caché en el entorno local, el número de CPU y la
cantidad de memoria que necesitan los servidores de archivos Windows para
hospedar cargas de trabajo de Azure File Sync (para más información, consulte los
recursos recomendados del sistema) y otros costos específicos de la organización
que pueda tener.
Costo de licencias por servidor de los servidores registrados con Azure File Sync.
Si desea utilizar Azure File Sync con un servidor de archivos Windows específico,
primero debe registrarlo con el recurso de Azure de Azure File Sync, el servicio de
sincronización de almacenamiento. Cada servidor que registra después del primer
servidor tiene una tarifa plana mensual. Si bien esta tarifa es muy pequeña, es un
componente de la factura que se debe tener en cuenta. Para ver el precio actual de
la tarifa de registro de los servidores de la región deseada, consulte la sección de
File Sync en la página de precios de Azure Files .

Costos de Azure Files. Como Azure File Sync es una solución de sincronización
para Azure Files, hará que consuma recursos de Azure Files. Algunos de estos
recursos, como el consumo de almacenamiento, son relativamente obvios,
mientras que otros, como el uso de transacciones y instantáneas, pueden no serlo.
Para la mayoría de los clientes, recomendamos utilizar recursos compartidos de
archivos estándar con Azure File Sync, aunque Azure File Sync es totalmente
compatible con los recursos compartidos de archivos premium si se desea.

Uso del almacenamiento. Azure File Sync replicará los cambios que haya hecho
en la ruta de acceso del servidor de archivos Windows que especificó en el
punto de conexión de servidor al recurso compartido de archivos de Azure, lo
que hace que se consuma almacenamiento. En los recursos compartidos de
archivos estándar, esto significa que agregar archivos o aumentar el tamaño de
los existentes en los puntos de conexión de servidor hará que aumenten los
costos de almacenamiento, ya que se replicarán los cambios. En el caso de los
recursos compartidos de archivos premium, los cambios consumirán espacio
aprovisionado. Es su responsabilidad aumentar periódicamente el
aprovisionamiento según sea necesario para tener en cuenta el crecimiento del
recurso compartido de archivos.

Uso de instantáneas. Azure File Sync toma instantáneas en el nivel de recurso

compartido y de archivo como parte del uso normal. El uso de instantáneas
siempre es diferencial, pero puede contribuir considerablemente a la factura
total de Azure Files.

Transacciones de renovación. A medida que los archivos cambian en los puntos

de conexión del servidor, los cambios se cargan en el recurso compartido en la
nube, lo que genera transacciones. Cuando se habilita la nube por niveles, se
generan transacciones adicionales para administrar los archivos en niveles,
incluida la E/S que se está produciendo en los archivos en niveles, además de
los costos de salida. La cantidad y el tipo de transacciones son difíciles de
predecir debido a la tasa de renovación y la eficacia de la memoria caché, pero
 puede usar los patrones de transacción anteriores para calcular los costos
futuros si cree que el uso futuro será similar al actual.

Transacciones de enumeración en la nube. Azure File Sync enumera el recurso

compartido de archivos de Azure en la nube una vez al día para detectar los
cambios que se realizaron directamente en el recurso compartido para que
puedan sincronizarse con los puntos de conexión del servidor. Este examen
genera transacciones que se facturan a la cuenta de almacenamiento a una tasa
de una transacción ListFiles por directorio al día. Puede poner este número
en la calculadora de precios para calcular el costo del examen.

 Sugerencia

Si no está seguro de cuántas carpetas tiene, consulte la herramienta TreeSize

de JAM Software GmbH.

Para optimizar los costos de Azure Files con Azure File Sync, debe tener en cuenta el
nivel del recurso compartido de archivos. Para más información sobre cómo elegir el
nivel de cada recurso compartido de archivos, consulte Elección de un nivel.

Si va a migrar a Azure File Sync desde StorSimple, consulte Comparación de los costos
de StorSimple con Azure File Sync.

Azure Backup
Azure Backup proporciona una solución de copia de seguridad sin servidor para Azure
Files que se integra a la perfección con los recursos compartidos de archivos, así como
con otros servicios de valor añadido, como Azure File Sync. Azure Backup para Azure
Files es una solución de copia de seguridad basada en instantáneas que ofrece un
mecanismo de programación para hacer instantáneas automáticamente según una
programación definida por el administrador. También brinda una interfaz fácil de usar
para restaurar archivos o carpetas eliminados o todo el recurso compartido a un
momento dado. Para más información sobre Azure Backup para Azure Files, consulte
Acerca de la copia de seguridad de recursos compartidos de archivos de Azure.

Al considerar los costos de usar Azure Backup para hacer copias de seguridad de los
recursos compartidos de archivos de Azure, tenga en cuenta lo siguiente:

Costo de licencias de instancias protegidas para los datos de los recursos

compartidos de archivos de Azure. Azure Backup cobra un costo de licencia de
instancia protegida por cada cuenta de almacenamiento que contiene recursos
compartidos de archivos de Azure de los que se ha hecho una copia de seguridad.
 Una instancia protegida se define como 250 GiB de almacenamiento de recursos
compartidos de archivos de Azure. Las cuentas de almacenamiento que contienen
menos de 250 GiB de almacenamiento de recursos compartidos de archivos de
Azure están sujetas a un costo fraccionario de instancia protegida. Para más
información, consulte Precios de Azure Backup . Tenga en cuenta que tiene que
seleccionar Azure Files en la lista de servicios que Azure Backup puede proteger.

Costos de Azure Files. Azure Backup aumenta los costos de Azure Files de las
siguientes maneras:

Costos diferenciales de las instantáneas de recursos compartidos de archivos

de Azure. Azure Backup automatiza la toma de instantáneas de recursos
compartidos de archivos de Azure según una programación definida por el
administrador. Las instantáneas siempre son diferenciales; sin embargo, el costo
adicional agregado al total de la factura depende del período de tiempo que se
conservan las instantáneas y de la cantidad de renovación en el recurso
compartido de archivos durante ese tiempo. Esto determina cuánto difiere la
instantánea del recurso compartido de archivos activo y, por tanto, la cantidad
de datos adicionales que almacena Azure Files.

Costos de transacción de las operaciones de restauración. Las operaciones de

restauración desde la instantánea al recurso compartido activo provocarán
transacciones. En el caso de los recursos compartidos de archivos estándar, esto
significa que las lecturas de instantáneas y las escrituras de las restauraciones se
facturarán como transacciones normales del recurso compartido de archivos. En
el caso de los recursos compartidos de archivos premium, estas operaciones se
tienen en cuenta para las IOPS aprovisionadas para el recurso compartido de
archivos.

Microsoft Defender para Storage

Microsoft Defender proporciona compatibilidad con Azure Files como parte de su
producto Microsoft Defender para Storage. Microsoft Defender para Storage detecta
intentos inusuales y potencialmente perjudiciales de acceder a los recursos compartido
de archivos de Azure mediante SMB o FileREST o de vulnerarlos. Microsoft Defender
para Storage está habilitado en el nivel de suscripción para todos los recursos
compartidos de archivos de las cuentas de almacenamiento de esa suscripción.

Microsoft Defender para Storage no admite funcionalidades antivirus para recursos

compartidos de archivos de Azure.
El costo principal de Microsoft Defender para Storage es un conjunto adicional de
costos de transacciones que el producto cobra sobre las transacciones que se realizan
en el recurso compartido de archivos de Azure. Aunque estos costos se basan en las
transacciones en las que se incurre en Azure Files, no forman parte de la facturación de
Azure Files, sino que forman parte de los precios de Microsoft Defender. Microsoft
Defender para Storage cobra una tasa de transacciones incluso en los recursos
compartidos de archivos premium, en los que Azure Files incluye las transacciones como
parte del aprovisionamiento de IOPS. La tarifa de transacciones actual se puede
encontrar en la página de precios de Microsoft Defender for Cloud en la fila de la
tabla de Microsoft Defender para Storage.

Los recursos compartidos de archivos con gran cantidad de transacciones incurrirán en

costos significativos al usar Microsoft Defender para Storage. En función de estos
costos, es posible que desee no participar en Microsoft Defender para Storage para
cuentas de almacenamiento específicas. Para más información, consulte Exclusión de
una cuenta de almacenamiento de las protecciones de Microsoft Defender para Storage.

Consulte también
Página de precios de Azure Files
Planeamiento de una implementación de Azure Files y Planeamiento de una
implementación de Azure File Sync
Creación de un recurso compartido de archivos e Implementación de Azure File
Sync
Reemplace o amplíe los servidores de
archivos de Windows por Azure Files y
Azure File Sync
Artículo • 22/03/2023

En este artículo se explica cómo puede usar Azure Files y Azure File Sync para
reemplazar o ampliar los servidores de archivos de Windows locales para reducir el
costo total de propiedad (TCO), aumentar la flexibilidad y simplificar la protección de
datos y el control de acceso. Azure Files tiene sus orígenes en el rol de servidor de
archivos de Windows, lo que lo convierte en una excelente opción al migrar servidores
de archivos de Windows a la nube.

La mayoría de los clientes toman uno de los dos enfoques de implementación:

Implementación solo en la nube: Migre servidores de archivos locales a un

recurso compartido de archivos de Azure SMB totalmente administrado (o varios
recursos compartidos de archivos).
Implementación híbrida: Use Azure File Sync para sincronizar los servidores de
archivos de Windows existentes con un recurso compartido de archivos de Azure
SMB. Opcionalmente, use la nube por niveles para escalar los datos de archivos en
la nube mientras se activan servidores locales en cachés locales para archivos
activos.

Se aplica a
Tipo de recurso compartido de archivos SMB NFS

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS

Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Reducción del TCO con recursos compartidos

de archivos totalmente administrados
Hay más que el TCO del recurso compartido de archivos que el precio por GiB de
almacenamiento. Al centralizar los recursos compartidos de archivos en Azure, puede
reducir el TCO de muchas maneras:

Para lograr un mejor uso del almacenamiento, no tenga que aprovisionar por
encima de la capacidad del recurso compartido de archivos. Con Azure Files,
puede cambiar rápidamente el tamaño del recurso compartido sin tiempo de
inactividad.

Elimine el trabajo asociado a la adquisición, configuración y mantenimiento de

hardware. Con Azure Files, se incluyen la resistencia de almacenamiento, la
redundancia y el mantenimiento, y no hay revisiones ni actualizaciones para
administrar.

Los clientes que dependen de tecnologías de replicación de recursos compartidos

completos, como DFS-R, pueden reducir los costos centralizando una copia
completa en un recurso compartido de archivos de Azure y usando Azure File Sync
para almacenar en caché los archivos activos localmente.

Las instantáneas diferenciales e integración con Azure Backup ofrecen protección

de datos económica.

Elija entre varios niveles de almacenamiento, desde SSD de baja latencia premium
hasta almacenamiento esporádico rentable, lo que le permite elegir el nivel que
mejor se adapte a la carga de trabajo.

Azure Files descuentos en reservas permiten ahorrar hasta un 36 % en el

almacenamiento confirmado previamente.

Para más información sobre cómo se facturan los recursos compartidos de archivos de
Azure y cómo puede reducir el TCO, consulte Descripción de la facturación de Azure
Files.

Amplia compatibilidad con servidores de

archivos de Windows
La mayoría de las funcionalidades principales del sistema de archivos y SMB en el rol de
servidor de archivos de Windows también existen en Azure Files, como:

Listas de control de acceso (ACL de Windows)

Integración de Active Directory
Cifrado de SMB
Conmutación por error transparente
Bloqueos de archivos
SMB multicanal
Actualmente, Azure Files no admite un conjunto limitado de características compatibles
con SMB y NTFS.

Implementación flexible y acceso híbrido

Azure Files se ha creado para el acceso híbrido y ofrece opciones de implementación
flexibles, incluida la migración sin tiempo de inactividad desde servidores de archivos de
Windows. Puede conectarse a un recurso compartido de archivos de Azure desde una
variedad de clientes o desde máquinas virtuales (VM) o contenedores. Puede conectarse
desde cualquier lugar a través del tráfico cifrado de SMB 3.x, ya sea a través de Internet
o a través de VPN/ExpressRoute. Si desea mantener el rendimiento local, puede usar
Azure File Sync para almacenar en caché los archivos activos o una copia completa del
recurso compartido de archivos de Azure.

Mover datos de servidores de archivos de Windows a Azure Files es fácil y puede

hacerlo en segundo plano sin interrumpir el acceso del usuario. Simplemente instale
Azure File Sync en el servidor de archivos, conéctese a un recurso compartido de
archivos de Azure e inicie la sincronización.

Al migrar a Azure Files, ninguno de los vínculos de ruta de acceso de archivo debe
interrumpirse. Puede usar espacios de nombres DFS y redirigir a los usuarios a Azure
Files. Si va a extender un servidor de archivos de Windows existente a Azure mediante
Azure File Sync, los usuarios seguirán accediendo a sus archivos mediante las mismas
rutas de acceso de archivo.
 

Azure File Sync puede sincronizar y almacenar en caché el recurso compartido de

archivos de Azure en cualquier lugar donde pueda instalar Windows Server. Como se
muestra en el diagrama, puede crear cachés regionales de los servidores de archivos en
diferentes regiones de Azure. Puede almacenar en caché archivos locales, en los centros
de datos o en una máquina virtual en nubes de terceros. Más información en el tutorial
Extensión de servidores de archivos de Windows con Azure File Sync.

Protección de datos simplificada y control de

acceso
Con Azure Files se beneficia de la seguridad multicapa proporcionada por Microsoft en
centros de datos físicos, infraestructura y operaciones en Azure. Proporcionamos varias
opciones de redundancia de datos, como local, regional o global. Las instantáneas
diferenciales y la administración de instantáneas de Azure Backup simplificar la
protección de datos, mientras que Azure File Sync ofrece una variedad de opciones de
recuperación ante desastres. Incluso puede proteger a los usuarios de la eliminación
accidental de un archivo o recurso compartido a través de la eliminación temporal.

El control de acceso funciona igual que los servidores de archivos de Windows. Puede
usar la autenticación basada en identidades e integrar recursos compartidos de archivos
de Azure SMB con el entorno de Active Directory local o Azure AD, y controlar el acceso
de nivel de recurso compartido y de directorio/archivo, así como privilegios de
administrador.

Consulte también
Migración a Azure Files
Consideraciones de redes para Azure Files
Cifrado de Azure Storage para datos en
reposo
Artículo • 25/03/2023

Azure Storage usa el cifrado del servicio (SSE) para cifrar automáticamente los datos
cuando se guardan en la nube. El cifrado de Azure Storage protege los datos y le ayuda
a satisfacer los requisitos de cumplimiento normativo y seguridad de la organización.

Microsoft recomienda usar el cifrado del servicio para proteger los datos en la mayoría
de los escenarios. Sin embargo, las bibliotecas cliente de Azure Storage para Blob
Storage y Queue Storage también proporcionan cifrado de cliente para los clientes que
necesitan cifrar los datos en el cliente. Para obtener más información, consulte la sección
sobre el cifrado de cliente para blobs y colas.

Acerca del cifrado del servicio de Azure Storage

Los datos de Azure Storage se cifran y descifran de forma transparente mediante el
cifrado AES de 256 bits, uno de los cifrados de bloques más sólidos que hay
disponibles, y son compatibles con FIPS 140-2. El cifrado de Azure Storage es similar al
cifrado de BitLocker en Windows.

El cifrado de Azure Storage está habilitado para todas las cuentas de almacenamiento,
incluidas las cuentas de almacenamiento clásicas y las de Resource Manager. El cifrado
de Azure Storage no se puede deshabilitar. Como los datos están protegidos de forma
predeterminada, no es necesario modificar el código o las aplicaciones para aprovechar
el cifrado de Azure Storage.

Los datos de una cuenta de almacenamiento se cifran independientemente de su nivel

de rendimiento (Estándar o Premium), del nivel de acceso (frecuente o esporádico) o del
modelo de implementación (Azure Resource Manager o clásico). Todos los blobs en
bloques nuevos y existentes, los blobs anexos y los blobs en páginas se cifran, incluidos
los blobs en el nivel de archivo. Todas las opciones de redundancia de Azure Storage
admiten el cifrado, y todos los datos de las regiones primaria y secundaria se cifran
cuando la replicación geográfica está habilitada. Se cifran todos los recursos de Azure
Storage, incluidos los blobs, los discos, los archivos, las colas y las tablas. También se
cifran todos los metadatos de objetos.

No hay ningún costo adicional para el cifrado de Azure Storage.

Para más información sobre de los módulos criptográficos subyacentes al cifrado de
Azure Storage, vea API de criptografía: última generación.

Para más información sobre el cifrado y la administración de claves de Azure Managed

Disks, consulte Cifrado del lado servidor de Azure Managed Disks.

Información sobre la administración de claves

de cifrado
Los datos de una cuenta de almacenamiento nueva se cifran con claves administradas
por Microsoft de manera predeterminada. Puede seguir confiando en las claves
administradas por Microsoft para el cifrado de los datos, o puede administrar el cifrado
con sus propias claves. Si opta por administrar el cifrado con sus propias claves, tiene
dos opciones. Puede usar cualquiera de los tipos de administración de claves, o ambos:

Puede especificar una clave administrada por el cliente que se usará para cifrar y
descifrar datos en Blob Storage y en Azure Files.1,2 Las claves administradas por el
cliente se deben almacenar en Azure Key Vault o en el modelo de seguridad de
hardware (HSM) administrado de Azure Key Vault. Para más información sobre las
claves administradas por el cliente, consulte Uso de claves administradas por el
cliente para el cifrado de Azure Storage.
Puede especificar una clave proporcionada por el cliente en las operaciones de Blob
Storage. Un cliente que realiza una solicitud de lectura o escritura en Blob Storage
puede incluir una clave de cifrado en la solicitud para tener un control detallado
sobre el cifrado y el descifrado de los datos de blob. Para más información sobre
las claves proporcionadas por el cliente, consulte Especificación de una clave de
cifrado en una solicitud a Blob Storage.

De forma predeterminada, una cuenta de almacenamiento está cifrada con una clave
cuyo ámbito es toda la cuenta de almacenamiento. Los ámbitos de cifrado permiten
administrar el cifrado con una clave cuyo ámbito es un contenedor o un blob individual.
Se pueden usar ámbitos de cifrado para crear límites seguros entre los datos que
residen en la misma cuenta de almacenamiento, pero que pertenecen a clientes
distintos. Los ámbitos de cifrado pueden usar claves administradas por Microsoft o
claves administradas por el cliente. Para obtener más información sobre los ámbitos de
cifrado, vea Ámbitos de cifrado para Blob Storage.

En la tabla siguiente se comparan las opciones de administración de claves para el

cifrado de Azure Storage.
 Parámetro de Claves administradas Claves administradas Claves
administración de por Microsoft por el cliente proporcionadas
claves por el cliente

Operaciones de Azure Azure Azure

cifrado y descifrado

Servicios de Azure All Blob Storage, Azure Blob Storage

Storage admitidos Files1,2

Almacenamiento de Almacén de claves de Azure Key Vault o HSM Propio almacén de

claves Microsoft de Key Vault claves del cliente

Responsabilidad de Microsoft Customer Customer

la rotación de claves

Control de claves Microsoft Customer Customer

Ámbito de clave Cuenta (valor Cuenta (valor N/D

predeterminado), predeterminado),
contenedor o blob contenedor o blob

1
Para obtener información sobre cómo crear una cuenta que admita el uso de claves
administradas por el cliente con Queue Storage, consulte Creación de una cuenta que
admita las claves administradas por el cliente para colas.
2
Para obtener información sobre cómo crear una cuenta que admita el uso de claves
administradas por el cliente con Table Storage, consulte Creación de una cuenta que
admita las claves administradas por el cliente para tablas.

７ Nota

Las claves administradas por Microsoft se rotan correctamente según los requisitos
de cumplimiento. Si tiene requisitos específicos de rotación de claves, Microsoft
recomienda que se cambie a las claves administradas por el cliente para que pueda
administrar y auditar la rotación usted mismo.

Cifrado doble de los datos con cifrado de

infraestructura
Los clientes que necesitan niveles altos de seguridad de que sus datos están seguros
también pueden habilitar el cifrado AES de 256 bits en el nivel de infraestructura de
Azure Storage. Cuando se habilita el cifrado de la infraestructura, los datos de las
cuentas de almacenamiento se cifran dos veces, una vez en el nivel de servicio y otra en
el nivel de infraestructura, con dos algoritmos de cifrado y dos claves diferentes. El
doble cifrado de los datos de Azure Storage sirve de protección en caso de que uno de
los algoritmos de cifrado o las claves puedan estar en peligro. En este escenario, la capa
adicional de cifrado también protege los datos.

El cifrado en el nivel de servicio admite el uso tanto de claves administradas por

Microsoft como de claves administradas por el cliente con Azure Key Vault. El cifrado en
el nivel de infraestructura se basa en las claves administradas por Microsoft y siempre
usa una clave independiente.

Para más información sobre cómo crear una cuenta de almacenamiento que habilite el
cifrado de infraestructura, consulte Creación de una cuenta de almacenamiento con el
cifrado de infraestructura habilitado para poder realizar el cifrado doble de datos.

Cifrado de cliente para blobs y colas

Las bibliotecas cliente de Azure Blob Storage para .NET, Java y Python admiten el cifrado
de datos dentro de las aplicaciones cliente antes de cargarlos en Azure Storage y el
descifrado de datos mientras estos se descargan al cliente. Las bibliotecas cliente de
Queue Storage para .NET y Python también admiten el cifrado del lado cliente.

７ Nota

Considere la posibilidad de usar las características de cifrado del servicio

proporcionadas por Azure Storage para proteger los datos, en lugar del cifrado de
cliente.

Las bibliotecas cliente de Blob Storage y Queue Storage usan AES para cifrar los datos
del usuario. Hay dos versiones del cifrado de cliente disponibles en las bibliotecas
cliente:

La versión 2 usa el modo Galois/contador (GCM) con AES. Los SDK de Blob
Storage y Queue Storage admiten el cifrado del lado cliente con v2.
La versión 1 usa el modo Cipher Block Chaining (CBC) con AES. Los SDK de Blob
Storage, Queue Storage y Table Storage admiten el cifrado del lado cliente con v1.

２ Advertencia

El uso de la versión 1 del cifrado de cliente no se recomienda debido a una

vulnerabilidad de seguridad en la implementación de la biblioteca cliente del modo
CBC. Para más información sobre esta vulnerabilidad de seguridad, consulte
 Actualización de Azure Storage del cifrado del lado cliente en el SDK para
abordar la vulnerabilidad de seguridad . Si actualmente usa la versión 1, se
recomienda actualizar la aplicación para que use la versión 2 del cifrado del lado de
cliente y migrar los datos.

El SDK de Azure Table Storage solo admite la versión 1 del cifrado de cliente. No se
recomienda usar el cifrado de cliente con Table Storage.

En la tabla siguiente se muestra qué bibliotecas cliente admiten qué versiones del
cifrado de cliente y se proporcionan instrucciones para migrar a la versión 2 del cifrado
de cliente.

Biblioteca de cliente Versión del Migración recomendada Instrucciones

cifrado de adicionales
cliente
compatible

Bibliotecas cliente de 2,0 Actualice el código para usar la Cifrado de

Blob Storage para .NET versión 2 del cifrado de cliente. cliente para
(versión 12.13.0 y 1.0 (se blobs
posteriores), Java conserva Descargue los datos cifrados para
(versión 12.18.0 y únicamente descifrarlos y, a continuación, vuelva
posteriores) y Python por a cifrarlos con la versión 2 del
(versión 12.13.0 y compatibilidad cifrado de cliente.
posteriores) con versiones
anteriores)

Biblioteca cliente de 1.0 (no se Actualice la aplicación para que use Cifrado de
Blob Storage para .NET recomienda) una versión del SDK de Blob cliente para
(versión 12.12.0 y Storage que admita la versión 2 del blobs
anteriores), Java (versión cifrado de cliente. Consulte la
12.17.0 y anteriores) y sección sobre la matriz de
Python (versión 12.12.0 compatibilidad del SDK para el
y anteriores) cifrado de cliente para obtener
detalles.

Actualice el código para usar la

versión 2 del cifrado de cliente.

Descargue los datos cifrados para

descifrarlos y, a continuación, vuelva
a cifrarlos con la versión 2 del
cifrado de cliente.
Biblioteca de cliente Versión del Migración recomendada Instrucciones
cifrado de adicionales
cliente
compatible

Biblioteca cliente de 2,0 Actualice el código para usar la Cifrado de

Queue Storage para versión 2 del cifrado de cliente. cliente para
.NET (versión 12.11.0 y 1.0 (se colas
posteriores) y Python conserva
(versión 12.4 y únicamente
posteriores) por
compatibilidad
con versiones
anteriores)

Biblioteca cliente de 1.0 (no se Actualice la aplicación para usar una Cifrado de
Queue Storage para recomienda) versión de la versión del SDK de cliente para
.NET (versión 12.10.0 y Queue Storage que admita la colas
anteriores) y Python versión 2 del cifrado de cliente.
(versión 12.3.0 y Consulte la sección sobre la matriz
anteriores) de compatibilidad del SDK para el
cifrado de cliente

Actualice el código para usar la

versión 2 del cifrado de cliente.

Biblioteca cliente de 1.0 (no se No disponible. N/D

Table Storage para .NET, recomienda)
Java y Python

Pasos siguientes
¿Qué es Azure Key Vault?
Claves administradas por el cliente para el cifrado de Azure Storage
Ámbitos de cifrado para Blob Storage
Especificación de una clave de cifrado en una solicitud a Blob Storage
Claves administradas por el cliente para
el cifrado de Azure Storage
Artículo • 11/05/2023

Puede usar su propia clave de cifrado para proteger los datos de la cuenta de
almacenamiento. Cuando se especifica una clave administrada por el cliente, esa clave
se usa para proteger y controlar el acceso a la clave que cifra los datos. Las claves
administradas por el cliente ofrecen más flexibilidad para administrar controles de
acceso.

Debe usar uno de los siguientes almacenes de claves de Azure para almacenar las claves
administradas por el cliente:

Azure Key Vault

Módulo de seguridad de hardware (HSM) administrado por Azure Key Vault

Puede crear sus propias claves y almacenarlas en un almacén de claves o HSM

administrado, o bien puede usar las API de Azure Key Vault para generarlas. La cuenta
de almacenamiento y el almacén de claves o HSM administrado pueden estar en
diferentes inquilinos, regiones y suscripciones de Azure Active Directory (Azure AD).

７ Nota

Azure Key Vault y HSM administrado por Azure Key Vault admiten las mismas API e
interfaces de administración para la configuración de claves administradas por el
cliente. Cualquier acción que se admita para Azure Key Vault también se admite
para HSM administrado por Azure Key Vault.

Acerca de las claves administradas por el

cliente
En el diagrama siguiente se muestra cómo Azure Storage usa Azure AD y un almacén de
claves o HSM administrado para hacer solicitudes mediante la clave administrada por el
cliente:
En la lista siguiente se explican los pasos numerados del diagrama:

1. Un administrador de Azure Key Vault concede permisos para las claves de cifrado a
una identidad administrada. La identidad administrada puede ser una identidad
administrada asignada por el usuario que haya creado y administrado, o bien una
identidad administrada asignada por el sistema asociada a la cuenta de
almacenamiento.
2. Un administrador de Azure Storage configura el cifrado con una clave
administrada por el cliente para la cuenta de almacenamiento.
3. Azure Storage usa la identidad administrada a la que el administrador de Azure
Key Vault concedió permisos en el paso 1 para autenticar el acceso a Azure
Key Vault a través de Azure AD.
4. Azure Storage encapsula la clave de cifrado de la cuenta con la clave administrada
por el cliente en Azure Key Vault.
5. En operaciones de lectura y escritura, Azure Storage envía solicitudes a Azure Key
Vault para desencapsular la clave de cifrado de la cuenta con el fin de realizar
operaciones de cifrado y descifrado.

La identidad administrada asociada a la cuenta de almacenamiento debe tener estos

permisos como mínimo para acceder a una clave administrada por el cliente en
Azure Key Vault:

wrapkey
unwrapkey
get

Para obtener más información sobre los permisos de clave, consulte Tipos de claves,
algoritmos y operaciones.

Azure Policy proporciona una directiva integrada para requerir que las cuentas de
almacenamiento usen claves administradas por el cliente para cargas de trabajo de Blob
Storage y Azure Files. Para obtener más información, consulte la sección
Almacenamiento de las definiciones de directivas integradas de Azure Policy.
Claves administradas por el cliente para colas y
tablas
Los datos almacenados en Queue y Table Storage no se protegen automáticamente
mediante una clave administrada por el cliente cuando se habilitan las claves
administradas por el cliente para la cuenta de almacenamiento. Opcionalmente, puede
configurar estos servicios para que se incluyan en esta protección en el momento de
crear la cuenta de almacenamiento.

Para más información sobre cómo crear una cuenta de almacenamiento que admita el
uso de claves administradas por el cliente para colas y tablas, consulte Creación de una
cuenta que admita las claves administradas por el cliente para tablas y colas.

Los datos en Blob Storage y Azure Files siempre están protegidos por claves
administradas por el cliente cuando se han configurado las claves administradas por el
cliente para la cuenta de almacenamiento.

Habilitación de claves administradas por el

cliente para una cuenta de almacenamiento
Al configurar claves administrada por el cliente para una cuenta de almacenamiento,
Azure Storage encapsula la clave de cifrado de la cuenta con la clave administrada por el
cliente en el almacén de claves o HSM administrado asociado. La protección de la clave
de cifrado raíz cambiará, pero los datos de la cuenta de Azure Storage seguirán cifrados
en todo momento. No se requiere ninguna acción adicional por su parte para
asegurarse de que los datos permanezcan cifrados. La protección de las claves
administradas por el cliente surte efecto de manera inmediata.

Puede cambiar entre las claves administradas por el cliente y las claves administradas
por Microsoft en cualquier momento. Para obtener más información sobre las claves
administradas por Microsoft, vea Información sobre la administración de claves de
cifrado.

Requisitos del almacén de claves

El almacén de claves o HSM administrado que almacena la clave debe tener habilitada la
eliminación temporal y la protección de purga. El cifrado de almacenamiento de Azure
admite claves RSA y RSA-HSM de los tamaños 2048, 3072 y 4096. Para obtener más
información sobre las claves, consulte Acerca de las claves.
El uso de un almacén de claves o HSM administrado tiene costos asociados. Para más
información, vea Precios de Key Vault .

Claves administradas por el cliente con un almacén de

claves en el mismo inquilino
Puede configurar claves administradas por el cliente con el almacén de claves y la
cuenta de almacenamiento en el mismo inquilino o en distintos inquilinos de Azure AD.
Para aprender a configurar el cifrado de Azure Storage con claves administradas por el
cliente cuando el almacén de claves y la cuenta de almacenamiento están en los mismos
inquilinos, consulte uno de los siguientes artículos:

Configuración de claves administradas por el cliente en un almacén de claves de

Azure para una nueva cuenta de almacenamiento
Configuración de claves administradas por el cliente en un almacén de claves de
Azure para una cuenta de almacenamiento existente

Al habilitar las claves administradas por el cliente con un almacén de claves en el mismo
inquilino, debe especificar una identidad administrada que se usará para autorizar el
acceso al almacén de claves que contiene la clave. La identidad administrada puede ser
una identidad administrada asignada por el usuario o asignada por el sistema:

Si configura claves administradas por el cliente al crear una cuenta de

almacenamiento, debe usar una identidad administrada asignada por el usuario.
Si configura claves administradas por el cliente en una cuenta de almacenamiento
existente, puede usar una identidad administrada asignada por el usuario o
asignada por el sistema.

Para más información sobre las identidades administradas asignadas por el sistema en
comparación con las asignadas por el usuario, consulte Identidades administradas para
recursos de Azure. Para más información sobre cómo crear y administrar una identidad
administrada asignada por el usuario, consulte Administración de identidades
administradas asignadas por el usuario.

Claves administradas por el cliente con un almacén de

claves en un inquilino diferente
Para aprender a configurar el cifrado de Azure Storage con claves administradas por el
cliente cuando el almacén de claves y la cuenta de almacenamiento están en distintos
inquilinos de Azure AD, consulte uno de los siguientes artículos:
 Configuración de claves administradas por el cliente entre inquilinos para una
nueva cuenta de almacenamiento
Configuración de claves administradas por el cliente entre inquilinos para una
cuenta de almacenamiento existente

Claves administradas por el cliente con un HSM

administrado
Puede configurar claves administradas por el cliente con un HSM administrado de Azure
Key Vault para una cuenta nueva o existente. Además, puede configurar claves
administradas por el cliente con un HSM administrado que esté en el mismo inquilino
que la cuenta de almacenamiento o en otro inquilino. El proceso para configurar claves
administradas por el cliente en un HSM administrado es el mismo que para configurar
claves administradas por el cliente en un almacén de claves, pero los permisos son un
poco diferentes. Para más información, consulte Configuración del cifrado con claves
administradas por el cliente almacenadas en HSM administrado por Azure Key Vault.

Actualización de la versión de la clave

Seguir los procedimientos recomendados criptográficos significa rotar la clave que
protege la cuenta de almacenamiento según una programación normal; por lo general,
al menos, cada dos años. Azure Storage nunca modifica la clave en el almacén de claves,
pero puede configurar una directiva de rotación de claves para rotar la clave según sus
requisitos de cumplimiento. Para más información, consulte Configurar la rotación
automática de claves en Azure Key Vault.

Una vez rotada la clave en el almacén de claves, la configuración de claves

administradas por el cliente para la cuenta de almacenamiento debe actualizarse para
usar la nueva versión de clave. Las claves administradas por el cliente admiten la
actualización automática y manual de la versión de clave para la clave que protege la
cuenta. Puede decidir qué enfoque desea usar al configurar claves administradas por el
cliente o al actualizar la configuración.

Al modificar la clave o la versión de clave, la protección de la clave de cifrado raíz

cambiará, pero los datos de la cuenta de Azure Storage seguirán cifrados en todo
momento. No se requiere ninguna acción adicional por su parte para asegurarse de que
los datos están protegidos. La rotación de la versión de la clave no afecta al
rendimiento. No hay tiempo de inactividad asociado a la rotación de la versión de la
clave.
 ） Importante

Para rotar una clave, cree una nueva versión de la clave en el almacén de claves o
HSM administrado, según los requisitos de cumplimiento. Azure Storage no
controla la rotación de claves, por lo que deberá administrar la rotación de la clave
en el almacén de claves.

Cuando rotas la clave que se usa para las claves administradas por el cliente, esa
acción no se registra actualmente en los registros de Azure Monitor para Azure
Storage.

Actualización automática de la versión de clave

para actualizar automáticamente una clave administrada por el cliente a una nueva
versión disponible, omita la versión de la clave al habilitar el cifrado con las claves
administradas por el cliente para la cuenta de almacenamiento. Si se omite la versión de
la clave, Azure Storage comprueba el almacén de claves o HSM administrado
diariamente para obtener una nueva versión de una clave administrada por el cliente. Si
hay disponible una nueva versión de la clave, Azure Storage usa automáticamente la
versión más reciente.

Azure Storage comprueba solo una vez al día el almacén de claves para obtener una
nueva versión de la clave. Al girar una clave, asegúrese de esperar 24 horas antes de
deshabilitar la versión anterior.

Si la cuenta de almacenamiento se configuró anteriormente para la actualización

manual de la versión de la clave y desea cambiarla para que se actualice
automáticamente, es posible que tenga que cambiar explícitamente la versión de la
clave a una cadena vacía. Para más información sobre cómo hacerlo, consulte
Configuración de claves administradas por el cliente en un almacén de claves de Azure
para una nueva cuenta de almacenamiento.

Actualización manual de la versión de la clave

para usar una versión determinada de una clave para el cifrado de Azure Storage,
especifique la versión de la clave al habilitar el cifrado con las claves administradas por
el cliente para la cuenta de almacenamiento. Si especifica la versión de la clave, Azure
Storage usará esa versión para el cifrado hasta que actualice manualmente la versión de
la clave.
Cuando se especifica la versión de la clave de manera explícita, debe actualizar
manualmente la cuenta de almacenamiento para usar el nuevo URI de la versión de la
clave cuando se crea una nueva versión. Para obtener más información sobre cómo
actualizar la cuenta de almacenamiento para usar una nueva versión de la clave,
consulte Configuración del cifrado con claves administradas por el cliente almacenadas
en Azure Key Vault o Configuración del cifrado con claves administradas por el cliente
almacenadas en HSM administrado de Azure Key Vault.

Revocar el acceso a una cuenta de

almacenamiento que usa claves administradas
por el cliente
Para revocar el acceso a una cuenta de almacenamiento que usa claves administradas
por el cliente, deshabilite la clave en el almacén de claves. Para obtener información
sobre cómo deshabilitar la clave, consulte Revocar el acceso a una cuenta de
almacenamiento que usa claves administradas por el cliente.

Después de deshabilitar la clave, los clientes no pueden llamar a las operaciones que
leen o escriben en un recurso o en sus metadatos. Los intentos de llamar a estas
operaciones producirán un error con el código de error 403 (prohibido) para todos los
usuarios.

Para volver a llamar a estas operaciones, restaure el acceso a la clave administrada por el
cliente.

Todas las operaciones de datos que no aparecen en las siguientes secciones pueden
continuar después de que se hayan revocado las claves administradas por el cliente o se
haya deshabilitado o eliminado una clave.

Para revocar el acceso a las claves administradas por el cliente, use PowerShell o la CLI
de Azure.

Operaciones de Blob Storage que producen un error

después de revocar una clave
List Blobs, cuando se llama con el parámetro include=metadata en el URI de
solicitud
Get Blob
Get Blob Properties
[Obtener metadatos de blob] (/rest/api/storageservices/get-bl- ob-metadata)
 Set Blob Metadata
Snapshot Blob, cuando se llama con el encabezado de solicitud x-ms-meta-name
Copy Blob
Copy Blob From URL
Set Blob Tier
Put Block
Put Block From URL
Append Block
Append Block From URL
Put Blob
Put Page
Put Page From URL
Incremental Copy Blob (Copia incremental del blob)

Operaciones de Azure Files que producen un error

después de revocar una clave
Crear permiso
Obtener permiso
Enumerar directorios y archivos
Crear directorio
Obtener propiedades del directorio
Establecer propiedades del directorio
Obtener metadatos de directorio
Establecer metadatos de directorio
Crear archivo
Get File
Obtener propiedades del archivo
Establecer propiedades del archivo
Put Range
Colocar rango desde dirección URL
Obtener metadatos del archivo
Set File Metadata
Copiar archivo
Cambiar nombre de archivo

Claves administradas por el cliente para discos

administrados por Azure
Las claves administradas por el cliente también están disponibles para administrar el
cifrado de discos administrados por Azure. Las claves administradas por el cliente se
comportan de forma diferente en los discos administrados que en los recursos de Azure
Storage. Para más información, consulte Cifrado del lado servidor de Azure Managed
Disks para Windows o Cifrado del lado servidor de Azure Managed Disks para Linux.

Pasos siguientes
Cifrado de Azure Storage para datos en reposo
Configuración del cifrado con claves administradas por el cliente almacenadas en
Azure Key Vault
Configuración del cifrado con claves administradas por el cliente almacenadas en
HSM administrado de Azure Key Vault.
Ofertas de cumplimiento de Azure
Storage
Artículo • 30/04/2023

Para ayudarle a satisfacer sus propias obligaciones de cumplimiento en sectores y

mercados regulados de todo el mundo, Azure mantiene el cumplimiento más amplio
del sector en cuanto a amplitud (número total de ofertas) y profundidad (número de
servicios orientados al cliente en el ámbito de la evaluación). Para la disponibilidad de
los servicios, consulte Productos disponibles por región .

Ámbito de auditoría de Azure Storage

Microsoft conserva firmas de auditoría independientes y de terceros para realizar
auditorías de los servicios en la nube de Microsoft. Las ofertas de cumplimiento se
agrupan en cuatro segmentos: aplicables globalmente, gobierno estadounidense,
específicas de un sector y específicas de un país o región. Los certificados de
cumplimiento de Azure y los informes de auditoría indican claramente qué servicios en
la nube están en el ámbito de las auditorías de terceros independientes. Las distintas
auditorías pueden tener diferentes servicios en la nube de ámbito de auditoría en
entornos de nube de Azure y Azure Government.

Azure Storage se incluye en muchas auditorías de cumplimiento de Azure, como CSA

STAR, ISO, SOC, PCI DSS, HITRUST, FedRAMP, DoD, etc. Las garantías de cumplimiento
resultantes son aplicables a:

Blobs (incluyendo Azure Data Lake Storage Gen2)

Archivos
Colas
Tablas
Discos
Almacenamiento de acceso esporádico
Premium Storage

Para obtener la información más reciente sobre el ámbito de auditoría de cumplimiento

de Azure Storage, consulte Servicios en la nube en el ámbito de auditoría.

Pasos siguientes
Para más información sobre el cumplimiento de Azure, consulte la siguiente
información.

Cumplimiento de Azure
Azure y otras ofertas de cumplimiento de servicios de Microsoft
Preguntas más frecuentes (P+F) sobre
Azure Files
Artículo • 28/11/2023

Azure Files le ofrece recursos compartidos de archivos en la nube totalmente

administrados, a los que se puede obtener acceso mediante el protocolo Bloque de
mensajes del servidor (SMB) estándar y el protocolo Network File System (NFS) . Los
recursos compartidos de archivos de Azure se pueden montar simultáneamente en
implementaciones de Windows, Linux y macOS en la nube o locales. También puede
almacenar en caché recursos compartidos de archivos de Azure en máquinas con
Windows Server mediante Azure File Sync para tener un acceso rápido cerca de donde
se usan los datos.

Azure File Sync

¿Puedo tener servidores unidos a un dominio y no unidos a un dominio en el
mismo grupo de sincronización?
Sí. Un grupo de sincronización puede contener puntos de conexión de servidor
que tienen pertenencias diferentes de Active Directory, incluso aunque no estén
unidos a dominio. Aunque técnicamente la configuración funciona, no se
recomienda como configuración normal, ya que las listas de control de acceso
(ACL) que se definen para los archivos y carpetas de un servidor no podrán
aplicarse a otros servidores del grupo de sincronización. Para mejores resultados,
se recomienda realizar la sincronización entre servidores en el mismo bosque de
Active Directory, entre servidores en bosques distintos de Active Directory con
relaciones de confianza establecidas o entre servidores que no están en un
dominio. Se recomienda no usar una combinación de estas configuraciones.

Si creé un archivo directamente en el recurso compartido de archivos de Azure

mediante SMB o el portal, ¿cuánto tiempo tarda el archivo en sincronizarse con
los servidores del grupo de sincronización?

Los cambios realizados en el recurso compartido de archivos de Azure mediante

Azure Portal o SMB no se detectan y replican de forma inmediata como cambios
en el punto de conexión del servidor. Azure Files aún no dispone de registros en
diario o notificaciones, por lo que no hay manera de iniciar automáticamente una
sesión de sincronización cuando se cambian los archivos. En Windows Server,
Azure File Sync usa el registro en diario de USN de Windows para iniciar
automáticamente una sesión de sincronización cuando cambian los archivos.
Para detectar cambios en el recurso compartido de archivos de Azure, Azure File
Sync tiene un trabajo programado que se denomina trabajo de detección de
cambios. Un trabajo de detección de cambios enumera todos los archivos del
recurso compartido de archivos y, a continuación, los compara con la versión de
sincronización correspondiente. Cuando el trabajo de detección de cambios
determina qué archivos han cambiado, Azure File Sync inicia una sesión de
sincronización. El trabajo de detección de cambios se inicia cada 24 horas. Dado
que el trabajo de detección de cambios enumera todos los archivos del recurso
compartido de archivos de Azure, la detección de cambios tarda más en los
espacios de nombres más largos que los espacios de nombres más cortos. En el
caso de los espacios de nombres largos, es posible que sea necesario determinar
más de una vez cada 24 horas qué archivos han cambiado.

Para sincronizar inmediatamente los archivos que se modifican en el recurso

compartido de archivos de Azure, se puede usar el cmdlet Invoke-
AzStorageSyncChangeDetection de PowerShell para iniciar de forma manual la
detección de cambios en el recurso compartido. Este cmdlet está pensado para
escenarios en los que algún tipo de proceso automatizado está realizando cambios
en el recurso compartido de archivos de Azure o en los que es el administrador el
que efectúa los cambios (por ejemplo, al mover archivos y directorios al recurso
compartido). En el caso de los cambios del usuario final, se recomienda instalar el
agente de Azure File Sync en una máquina virtual de IaaS y hacer que los usuarios
finales accedan al recurso compartido de archivos a través de ella. De este modo,
todos los cambios se sincronizarán rápidamente con otros agentes sin necesidad
de usar el cmdlet Invoke-AzStorageSyncChangeDetection. Para más información,
consulte la documentación sobre Invoke-AzStorageSyncChangeDetection.

Estamos considerando agregar la detección de cambios para un recurso

compartido de archivos de Azure similar al USN para volúmenes en Windows
Server. Ayúdenos a priorizar el futuro desarrollo de esta característica votándola en
Comentarios de la comunidad de Azure .

Si se cambia el mismo archivo en dos servidores aproximadamente al mismo

tiempo, ¿qué sucede?
Los conflictos de archivos se crean cuando el archivo del recurso compartido de
archivos de Azure no coincide con el archivo en la ubicación del punto de
conexión del servidor (el tamaño o la hora de la última modificación es diferente).

Los siguientes escenarios pueden provocar conflictos de archivos:

Se crea o modifica un archivo en un punto de conexión (por ejemplo, el
Servidor A). Si el mismo archivo se modifica en un punto de conexión diferente
 antes de que el cambio en el servidor A se sincronice con ese punto de
conexión, se crea un archivo de conflicto.
El archivo existía en el recurso compartido de archivos de Azure y en la
ubicación del punto de conexión del servidor antes de la creación del punto de
conexión de servidor. Si el tamaño del archivo o la hora de la última
modificación es diferente entre el archivo del servidor y el recurso compartido
de archivos de Azure cuando se crea el punto de conexión del servidor, se crea
un archivo de conflicto.
Se ha vuelto a crear la base de datos de sincronización debido a daños o a que
se alcanzaron los límites de conocimiento. Una vez que se vuelve a crear la base
de datos, la sincronización entra en un modo denominado conciliación. Si el
tamaño del archivo o la hora de la última modificación es diferente entre el
archivo del servidor y el recurso compartido de archivos de Azure cuando se
produce la conciliación, se crea un archivo de conflicto.

Azure File Sync usa una estrategia simple de resolución de conflictos: conservamos
los cambios realizados en los archivos que se modifican en dos puntos de
conexión al mismo tiempo. El cambio de escritura más reciente mantiene el
nombre de archivo original. El archivo antiguo (según lo establecido por
LastWriteTime) tiene el nombre del punto de conexión y el número de conflicto
anexado al nombre de archivo. En el caso de los puntos de conexión de servidor, el
nombre del punto de conexión es el nombre del servidor. Para los puntos de
conexión de nube, el nombre del punto de conexión es Cloud. El nombre sigue
esta taxonomía:

<FileNameWithoutExtension>-<endpointName>[-#].<ext>

Por ejemplo, el primer conflicto de CompanyReport.docx se convertiría en

CompanyReport-CentralServer.docx si CentralServer es donde se ha producido la
operación de escritura anterior. El segundo conflicto se denominará
CompanyReport-CentralServer-1.docx. Azure File Sync admite 100 archivos de
conflicto por archivo. Una vez alcanzado el número máximo de archivos de
conflicto, el archivo no se sincronizará hasta que el número de archivos de
conflicto sea inferior a 100.

Tengo deshabilitada la nube por niveles, ¿por qué hay archivos por niveles en la
ubicación del punto de conexión de servidor?
Existen dos razones por las que pueden existir archivos por niveles en la ubicación
del punto de conexión de servidor:

Al agregar un nuevo punto de conexión de servidor a un grupo de

sincronización existente, si elige la opción de recuperar primero el espacio de
 nombres o la opción de recuperar solo el espacio de nombres para el modo de
descarga inicial, los archivos se mostrarán por niveles hasta que se descarguen
localmente. Para evitar esta situación, seleccione la opción de evitar archivos
por niveles para el modo de descarga inicial. Para recuperar archivos
manualmente, use el cmdlet Invoke-StorageSyncFileRecall.

Si se ha habilitado la nube por niveles en el punto de conexión de servidor y

luego se ha deshabilitado, los archivos permanecen por niveles hasta que se
accede a ellos.

¿Por qué no se muestran miniaturas ni vistas previas de los archivos

almacenados por niveles en el Explorador de archivos de Windows?
En el caso de los archivos con niveles, las vistas previas y las miniaturas no estarán
visibles en el punto de conexión del servidor. Este comportamiento es el esperado,
ya que la característica de caché de vistas en miniatura de Windows omite
intencionadamente la lectura de archivos con el atributo sin conexión. Con Niveles
de la nube habilitado, la lectura de archivos con niveles provocaría su descarga
(recuperación).

Este comportamiento no es específico de Azure File Sync, el Explorador de

Windows muestra una "X gris" para los archivos que tienen establecido el atributo
sin conexión. Verá el icono X al acceder a los archivos a través de SMB. Para
obtener una explicación detallada de este comportamiento, consulte ¿Por qué no
se obtienen miniaturas de archivos marcados como sin conexión?

Si tiene preguntas sobre cómo administrar archivos almacenados en niveles,

consulte Administración de archivos en niveles.

¿Por qué los archivos en capas se encuentran fuera del espacio de nombres del
punto de conexión de servidor?
Antes de la versión 3 del agente de Azure File Sync, Azure File Sync bloqueaba el
movimiento de archivos en capas fuera del punto de conexión del servidor, pero
en el mismo volumen que el punto de conexión del servidor. Las operaciones de
copia, los movimientos de archivos sin niveles y los movimientos de archivos por
niveles a otros volúmenes no resultaban afectados. La razón de este
comportamiento era la presunción implícita que tienen el Explorador de archivos y
otras API de Windows de que las operaciones de movimiento en el mismo
volumen son operaciones de cambio de nombre (casi) instantáneas. Esto significa
que los movimientos que haga el Explorador de archivos u otros métodos de
movimiento (como la línea de comandos o PowerShell) parecen no responder
mientras Azure File Sync recupera los datos de la nube. A partir de la versión
3.0.12.0 del agente de Azure File Sync, Azure File Sync le permitirá mover un
archivo con capas fuera del punto de conexión del servidor. Evitamos los efectos
negativos que se mencionaron anteriormente permitiendo que el archivo con
capas exista como un archivo con capas fuera del punto de conexión del servidor
y, a continuación, recuperando el archivo en segundo plano. Esto significa que los
movimientos en el mismo volumen son instantáneos y nosotros nos ocupamos por
completo de recuperar el archivo en el disco una vez que el movimiento se ha
completado.

Tengo un problema con Azure File Sync en mi servidor (sincronización, niveles

en la nube, etc.). ¿Debería quitar y volver a crear el punto de conexión del
servidor?

No: eliminar un punto de conexión de servidor no es como reiniciar un servidor.

Eliminar y volver a crear el punto de conexión del servidor casi nunca es una
solución adecuada para solucionar problemas de sincronización, niveles de nube u
otros aspectos de Azure File Sync. Quitar un punto de conexión de servidor es una
operación destructiva. Puede producirse una pérdida de datos en caso de que
existan archivos en capas fuera del espacio de nombres del punto de conexión de
servidor. Para más información, consulte ¿Por qué los archivos en capas se
encuentran fuera del espacio de nombres del punto de conexión de servidor? para
más información. También pueden producirse archivos inaccesibles para los
archivos en capas que existen en el espacio de nombres del punto de conexión de
servidor. Estos problemas no se resolverán al volver a crear el punto de conexión
en el servidor. Puede haber archivos en capas en el espacio de nombres del punto
de conexión de un servidor aunque nunca se hayan habilitado los niveles en la
nube. Por eso se recomienda no eliminar el punto de conexión del servidor a
menos que desee dejar de usar Azure File Sync con esta carpeta en concreto o un
ingeniero de Microsoft le haya solicitado expresamente que lo haga así. Para más
información sobre la eliminación de puntos de conexión del servidor, consulte
Eliminación de un punto de conexión de servidor.

¿Puedo mover el servicio de sincronización de almacenamiento o la cuenta de

almacenamiento a otro grupo de recursos, suscripción o inquilino de Microsoft
Entra?
Sí, puede mover el servicio de sincronización de almacenamiento y/o la cuenta de
almacenamiento a un grupo de recursos, suscripción o inquilino de Microsoft Entra
diferente. Después de mover el servicio de sincronización de almacenamiento o la
cuenta de almacenamiento, debe otorgar acceso a la aplicación
Microsoft.StorageSync a la cuenta de almacenamiento. Siga estos pasos:

1. Inicie sesión en el Azure Portal y seleccione Control de acceso (IAM) en el

panel de navegación izquierdo.
 2. Seleccione la pestaña Asignaciones de roles de la lista de los usuarios y
aplicaciones (entidades de seguridad) que tienen acceso a su cuenta de
almacenamiento.

3. Confirme que Microsoft.StorageSync o Hybrid File Sync Service (nombre

anterior de la aplicación) figuran en la lista con el rol Lector y acceso a los
datos.

Si Microsoft.StorageSync o Hybrid File Sync Service no aparecen en la lista,

siga los siguientes pasos:
Seleccione Agregar.
En el campo Rol, seleccione Lector y acceso a los datos.
En el campo Seleccionar, escriba Microsoft.StorageSync, seleccione el rol
y, a continuación, seleccione Guardar.

７ Nota

Al crear el punto de conexión en la nube, el servicio de sincronización de

almacenamiento y la cuenta de almacenamiento deben estar en el
mismo inquilino de Microsoft Entra. Una vez creado el punto de
conexión en la nube, el servicio de sincronización de almacenamiento y
la cuenta de almacenamiento se pueden mover a diferentes inquilinos
de Microsoft Entra.

¿Mantiene Azure File Sync las listas ACL de NTFS a nivel de directorio/archivo
junto con los datos almacenados en Azure Files?

A partir del 24 de febrero de 2020, tanto las listas de control de acceso nuevas
como las existentes que Azure File Sync organiza en capas se conservarán en
formato NTFS y las modificaciones de ACL realizadas directamente en el recurso
compartido de archivos de Azure se sincronizarán con todos los servidores del
grupo de sincronización. Los cambios en las listas de control de acceso realizados
en recursos compartidos de archivos de Azure se sincronizarán a través de Azure
File Sync. Al copiar datos en Azure Files, asegúrese de usar una herramienta de
copia que admita la "fidelidad" necesaria para copiar los atributos, las marcas de
tiempo y las ACL en un recurso compartido de archivos de Azure, ya sea a través
de SMB o REST. Al usar las herramientas de copia de Azure, como AzCopy, es
importante usar la versión más reciente. Eche un vistazo a la tabla de herramientas
de copia de archivos para obtener información general sobre las herramientas de
copia de Azure, lo que le permitirá asegurarse de que pueda copiar todos los
metadatos importantes de un archivo.
 Si ha habilitado Azure Backup en los recursos compartidos de archivos
administrados de Azure File Sync, las listas de control de acceso de los archivos se
pueden seguir restaurando como parte del flujo de trabajo de la restauración de la
copia de seguridad. Esto puede realizarse tanto en todo el recurso compartido o
en cada uno de los archivos o directorios.

Si usa instantáneas como parte de la solución de copia de seguridad

autoadministrada para los recursos compartidos de archivos administrados por
Azure File Sync, es posible que las listas de control de acceso no se restauren
correctamente en las ACL con formato NTFS si las instantáneas se tomaron antes
del 24 de febrero de 2020. En ese caso, póngase en contacto con el soporte
técnico de Azure.

¿Azure File Sync sincroniza el LastWriteTime de los directorios? ¿Por qué no se

actualiza la marca de tiempo de fecha de modificación de un directorio cuando
se modifican los archivos que contiene?
No, Azure File Sync no sincroniza el valor de LastWriteTime de los directorios.
Además, Azure Files no actualiza la marca de tiempo de fecha de modificación
(LastWriteTime) de los directorios cuando se cambian los archivos del directorio.
Este es el comportamiento esperado.

Seguridad, autenticación y control de acceso

¿Cómo se pueden auditar tanto el acceso a los archivos como los cambios que
se realicen en ellos en Azure Files?

Hay dos opciones que proporcionan la funcionalidad de auditoría a Azure Files:

Si los usuarios acceden directamente al recurso compartido de archivos de
Azure, puede usar los registros de Azure Storage para realizar un seguimiento
de los cambios en los archivos y del acceso de los usuarios con el fin de
solucionar problemas. Las solicitudes se registran en función de la mejor opción.
Si los usuarios acceden al recurso compartido de archivos de Azure a través de
un servidor de Windows Server con el agente de Azure File Sync instalado, use
una directiva de auditoría o un producto de terceros para realizar el
seguimiento de los cambios en los archivos y el acceso de los usuarios en el
servidor de Windows Server.

¿Admite Azure Files el uso de Access-Based Enumeración (ABE) para controlar la

visibilidad de los archivos y las carpetas en los recursos compartidos de archivos
de Azure SMB?
 El uso de ABE con Azure Files no se admite actualmente, pero puede usar DFS-N
con recursos compartidos de archivos de Azure SMB.

Habilitación basada en identidad

¿Admite los servicios de dominio de Microsoft Entra el acceso SMB mediante
credenciales de Microsoft Entra desde dispositivos unidos o registrados con
Microsoft Entra ID?

No, este escenario no se admite.

¿Puedo usar el nombre canónico (CNAME) para montar un recurso compartido

de archivos de Azure mientras se usa la autenticación basada en identidades?

Sí, este escenario ahora se admite tanto en los entornos de bosque único como en
los de varios bosques para recursos compartidos de archivos de Azure SMB. Sin
embargo, Azure Files solo admite la configuración de CNAME mediante el nombre
de la cuenta de almacenamiento como prefijo de dominio. Si no quiere usar el
nombre de la cuenta de almacenamiento como prefijo, considere la posibilidad de
usar espacios de nombres DFS.

¿Puedo acceder a los recursos compartidos de archivos de Azure con

credenciales de Microsoft Entra desde una máquina virtual con una suscripción
diferente?

Si la suscripción bajo la cual se implementa el recurso compartido de archivos está

asociada con el mismo inquilino de Microsoft Entra que la implementación de
servicios de dominio de Microsoft Entra a la cual la máquina virtual está unida al
dominio, puede acceder a los recursos compartidos de archivos de Azure usando
las mismas credenciales de Microsoft Entra. La limitación no se impone en la
suscripción, sino en el inquilino de Microsoft Entra asociado.

¿Puedo habilitar los servicios de dominio de Microsoft Entra o la autenticación

AD DS local para los recursos compartidos de archivos de Azure mediante un
inquilino de Microsoft Entra diferente del inquilino principal del recurso
compartido de archivos de Azure?

No. Azure Files solo admite servicios de dominio de Microsoft Entra o la

integración de AD DS local con un inquilino de Microsoft Entra que resida en la
misma suscripción que el recurso compartido de archivos. Una suscripción solo se
puede asociar a un inquilino de Microsoft Entra. Al usar AD DS local para la
autenticación, la credencial de AD DS debe sincronizarse con Microsoft Entra ID al
que está asociada la cuenta de almacenamiento.
¿La autenticación con AD DS local para recursos compartidos de archivos de
Azure admite la integración en un entorno de AD DS mediante varios bosques?

La autenticación con AD DS local para Azure Files solo se integra con el bosque del
servicio de dominio en el que está registrada la cuenta de almacenamiento. Para
admitir la autenticación desde otro bosque, la confianza de bosque del entorno
debe estar configurada correctamente. Para obtener instrucciones detalladas,
consulte Uso de Azure Files con varios bosques de Active Directory.

７ Nota

En una configuración de varios bosques, no use el Explorador de archivos

para configurar los permisos de ACL o NTFS de Windows en el nivel de raíz,
directorio o archivo. En su lugar, use icacls.

¿Hay alguna diferencia entre la creación de una cuenta de equipo y una cuenta
de inicio de sesión de servicio para representar mi cuenta de almacenamiento en
AD?

La creación de una cuenta de equipo (valor predeterminado) o de una cuenta de

inicio de sesión de servicio no representa ninguna diferencia en el modo en que la
autenticación funciona con Azure Files. Puede elegir cómo representar una cuenta
de almacenamiento como una identidad en el entorno de AD. El valor
predeterminado de DomainAccountType establecido en el cmdlet Join-
AzStorageAccountForAuth es la cuenta de la máquina. Sin embargo, el tiempo de

expiración de la contraseña configurado en el entorno de AD puede ser diferente

para las cuentas de inicio de sesión de servicio y de equipo, por lo que se debe
tener en cuenta para la Actualización de la contraseña de la identidad de cuenta
de almacenamiento en AD.

¿Cómo quitar las credenciales almacenadas en caché con la clave de cuenta de

almacenamiento y eliminar las conexiones SMB existentes antes de inicializar
una nueva conexión con credenciales de Microsoft Entra ID o AD?

Siga el proceso de dos pasos siguiente para quitar las credenciales guardadas
asociadas a la clave de cuenta de almacenamiento y quitar la conexión SMB:

1. Ejecute el siguiente comando desde un símbolo del sistema de Windows para

quitar la credencial. Si no encuentra uno, significa que no ha conservado la
credencial y puede omitir este paso.

cmdkey /delete:Domain:target=storage-account-name.file.core.windows.net
 2. Elimine la conexión existente con el recurso compartido de archivos. Puede
especificar la ruta de acceso de montaje como la letra de unidad montada o
la ruta de acceso storage-account-name.file.core.windows.net .

net use <drive-letter/share-path> /delete

¿Es posible ver el userPrincipalName (UPN) de un propietario de archivo o

directorio en el Explorador de archivos en lugar del identificador de seguridad
(SID)?

El Explorador de archivos llama a una API RPC directamente al servidor (Azure

Files) para trasladar el SID a un UPN. Azure Files no admite esta API, por tanto, en
el Explorador de archivos, se muestra el SID de un propietario de archivos o
directorios en lugar del UPN de los archivos y directorios hospedados en Azure
Files. Sin embargo, puede usar el siguiente comando de PowerShell para ver todos
los elementos de un directorio y su propietario, incluido el UPN:

PowerShell

Get-ChildItem <Path> | Get-ACL | Select Path, Owner

Network File System (NFS v4.1)

¿Cuándo se deben usar recursos compartidos de archivos NFS de Azure?

Consulte Recursos compartidos NFS.

¿Cómo hago una copia de seguridad de los datos almacenados en recursos

compartidos NFS?

La realización de copias de seguridad de los datos en recursos compartidos NFS se

puede organizar mediante herramientas conocidas, como rsync, o productos de
uno de nuestros asociados para la copia de seguridad. Varios asociados para la
copia de seguridad, entre los que se incluyen Commvault , Veeam y Veritas ,
han ampliado sus soluciones para que funcionen con SMB 3.x y NFS 4.1 para Azure
Files.

¿Puedo migrar datos existentes a un recurso compartido NFS?

Dentro de una región, puede usar herramientas estándar como scp, rsync o SSHFS
para mover los datos. Dado que se puede acceder a recursos compartidos de
archivos NFS de Azure desde varias instancias de proceso al mismo tiempo, se
pueden mejorar las velocidades de copia con cargas paralelas. Si desea traer datos
 de fuera de una región, use una VPN o Expressroute para el montaje en el sistema
de archivos desde el centro de datos local.

¿Puede ejecutar IBM MQ (incluidas las instancias múltiples) en recursos

compartidos de archivos NFS de Azure?
Los recursos compartidos de archivos de Azure Files NFS v4.1 cumplen los tres
requisitos que establece IBM MQ:
https://www.ibm.com/docs/en/ibm-mq/9.2?topic=multiplatforms-
requirements-shared-file-systems
Integridad de escritura de datos
Acceso exclusivo garantizado a los archivos
Liberación de bloqueos en caso de error
Los siguientes casos de prueba se ejecutan correctamente:

1. https://www.ibm.com/docs/en/ibm-mq/9.2?topic=multiplatforms-
verifying-shared-file-system-behavior
2. https://www.ibm.com/docs/en/ibm-mq/9.2?topic=multiplatforms-
running-amqsfhac-test-message-integrity

Instantáneas de recursos compartido

Creación de instantáneas de recurso compartido

¿Tienen mis instantáneas de recurso compartido redundancia geográfica?
Las instantáneas de recurso compartido tienen la misma redundancia que el
recurso compartido de archivos de Azure para el que se han tomado. Si ha
seleccionado el almacenamiento con redundancia geográfica para la cuenta, la
instantánea de recurso compartido también se almacena de manera redundante
en la región emparejada.

Limpiar instantáneas de recurso compartido

¿Puedo eliminar mi recurso compartido pero no las instantáneas de recurso
compartido?
Si tiene instantáneas de recurso compartido activas en el recurso, no puede
eliminar el recurso compartido. Puede usar una API para eliminar instantáneas de
recurso compartido junto con el recurso compartido. También puede eliminar las
instantáneas de recurso compartido y el recurso compartido en Azure Portal.

Precios y facturación
 ¿Qué son las transacciones en Azure Files y cómo se facturan? Las transacciones
de protocolo se producen cada vez que un usuario, aplicación, script o servicio
interactúa con recursos compartidos de archivos de Azure (escritura, lectura,
enumeración, eliminación de archivos, etc.). Conviene recordar que, algunas
acciones que puede percibir como una sola operación, podrían implicar en
realidad varias transacciones. En el caso de los recursos compartidos de archivos
Estándar de Azure facturados en un modelo de pago por uso, los distintos tipos de
transacciones tienen precios diferentes en función de su impacto en el recurso
compartido de archivos. Las transacciones no afectan a la facturación de recursos
compartidos de archivos Premium, que se facturan mediante un modelo
aprovisionado. Para más información, consulte Descripción de la facturación.

¿Cuánto cuestan las instantáneas de recurso compartido?

Las instantáneas de recurso compartido son de naturaleza incremental. La
instantánea de recurso compartido de base es el mismo recurso compartido. Todas
las instantáneas de recurso compartido siguientes son incrementales y solo
almacenan la diferencia de la instantánea de recurso compartido anterior. Se le
facturará únicamente por el contenido cambiado. Si tiene un recurso compartido
con 100 GB de datos, pero solo se han cambiado 5 GB desde la última instantánea
de recurso compartido, esa instantánea de recurso compartido consumirá solo
5 GB adicionales y se le facturarán, por tanto, 105 GB. Para obtener más
información sobre los cargos de salida estándar y de transacciones, vea la página
de precios .

Interoperabilidad con otros servicios

¿Puedo usar mi recurso compartido de archivos de Azure como un testigo del
recurso compartido de archivos para el clúster de conmutación por error de
Windows Server?
Esta configuración no se admite actualmente para Azure Files. Para obtener más
información acerca de cómo configurar esto usando Azure Blob Storage, consulte
Implementar un testigo en la nube para un clúster de conmutación por error.

Consulte también
Solucionar problemas de Azure Files
Solución de problemas de Azure File Sync
Novedades de Azure Files
Artículo • 13/10/2023

Azure Files se actualiza periódicamente para ofrecer nuevas características y mejoras. En

este artículo se proporciona información detallada sobre las novedades de Azure Files y
Azure File Sync.

Novedades de 2023

4.º trimestre de 2023 (octubre, noviembre, diciembre)

Azure Files ahora admite todos los caracteres Unicode válidos

La compatibilidad con caracteres expandidos permitirá a los usuarios crear recursos
compartidos de archivos SMB con nombres de archivo y directorio a la par que el
sistema de archivos NTFS para todos los caracteres Unicode válidos. También habilita
herramientas como AzCopy y Storage Mover para migrar todos los archivos a Azure
Files mediante el protocolo REST. La compatibilidad con caracteres expandidos ya está
disponible en todas las regiones de Azure. Para más información, lea el anuncio .

3.er trimestre de 2023 ( julio, agosto, septiembre)

La compatibilidad de Azure Active Directory con la API de REST de

Azure Files con autenticación de OAuth está disponible con
caracter general
Esta característica permite el acceso de lectura y escritura a nivel de recurso compartido
a recursos compartidos de archivos de Azure SMB para usuarios, grupos e identidades
administradas al acceder a los datos del recurso compartido de archivos a través de la
API de REST. Las aplicaciones nativas y modernas en la nube que usen las API de REST
pueden usar la autorización y autenticación basada en identidades para acceder a los
recursos compartidos de archivos. Para obtener más información, lea esta entrada de
blog .

2.º trimestre de 2023 (abril, mayo, junio)

La mejora de la escalabilidad de Azure Files para Azure Virtual
Desktop y otras cargas de trabajo que controla el directorio raíz
abierto está disponible de forma generalizada
Azure Files ha aumentado el límite de identificadores de directorio raíz por recurso
compartido de 2000 a 10 000 para recursos compartidos de archivos estándar y
premium. Esta mejora beneficia a las aplicaciones que mantienen un identificador
abierto en el directorio raíz. Por ejemplo, Azure Virtual Desktop con contenedores de
perfiles de FSLogix ahora admite 10 000 usuarios activos por recurso compartido (cinco
veces más).

Nota: el número de usuarios activos admitidos por recurso compartido depende de las
aplicaciones que acceden al recurso compartido. Si las aplicaciones no abren un
identificador en el directorio raíz, Azure Files puede admitir más de 10 000 usuarios
activos por recurso compartido.

El límite de identificadores de directorio raíz se ha aumentado en todas las regiones y se

aplica a todos los recursos compartidos de archivos existentes y nuevos. Para obtener
más información sobre los objetivos de escalabilidad de Azure Files, consulte Objetivos
de escalabilidad y rendimiento de Azure Files.

El almacenamiento con redundancia geográfica para recursos

compartidos grandes está en versión preliminar pública

La versión preliminar de redundancia geográfica de Azure Files para recursos

compartidos de archivos grandes mejora significativamente la capacidad y el
rendimiento de los recursos compartidos de archivos SMB estándar al usar las opciones
de almacenamiento con redundancia geográfica (GRS) y almacenamiento con
redundancia de zona geográfica (GZRS). La versión preliminar solo está disponible para
recursos compartidos de archivos de Azure SMB estándar. Para obtener más
información, consulte Redundancia geográfica de Azure Files para la versión preliminar
de recursos compartidos de archivos grandes.

El nuevo Acuerdo de Nivel de Servicio del 99,99 % para Azure Files

nivel Premium está disponible con carácter general
Azure Files ahora ofrece un Acuerdo de Nivel de Servicio del 99,99 % por recurso
compartido de archivos para todos los recursos compartidos de Azure Files Premium,
independientemente del protocolo (SMB, NFS y REST) o tipo de redundancia. Esto
significa que puede beneficiarse de este Acuerdo de Nivel de Servicio inmediatamente,
sin cambios de configuración ni costes adicionales. Si la disponibilidad cae por debajo
del tiempo de actividad garantizado del 99,99 por ciento, podrá optar a créditos de
servicio.

La compatibilidad de Azure Active Directory con la API de REST de

Azure Files con autenticación de OAuth está en versión preliminar
pública

Esta versión preliminar permite el acceso de lectura y escritura a nivel de recurso

compartido a recursos compartidos de archivos de Azure SMB para usuarios, grupos e
identidades administradas al acceder a los datos del recurso compartido de archivos a
través de la API de REST. Las aplicaciones nativas y modernas en la nube que usen las
API de REST pueden usar la autorización y autenticación basada en identidades para
acceder a los recursos compartidos de archivos. Para obtener más información, lea esta
entrada de blog .

La autenticación Kerberos AD para clientes Linux (SMB) está

disponible con carácter general

Los clientes de Azure Files ahora pueden usar la autenticación Kerberos basada en
identidad para clientes Linux sobre SMB usando Servicios de dominio de Active
Directory (AD DS) locales o Servicios de dominio de Active Directory de Azure (Azure AD
DS). Para más información, consulte Habilitar la autenticación de Active Directory sobre
SMB para clientes Linux que acceden a Azure Files.

1.er trimestre de 2023 (enero, febrero, marzo)

Nconnect para recursos compartidos de Azure NFS está disponible

con carácter general

Nconnect es una opción de montaje de Linux del lado cliente que aumenta el
rendimiento a escala, ya que permite usar más conexiones TCP entre el cliente Linux y el
servicio Azure Premium Files para NFSv4.1. Con nconnect, puede aumentar el
rendimiento a escala mediante menos máquinas cliente para reducir el costo total de
propiedad. Para más información, consulte Mejora del rendimiento del recurso
compartido de archivos NFS de Azure.

Disponibilidad mejorada del servicio Azure File Sync

Azure File Sync ahora es un servicio con redundancia de zona, lo que significa que una
interrupción en una zona tendrá un impacto limitado al tiempo que mejora la resistencia
del servicio para minimizar el impacto del cliente. Para aprovechar completamente esta
mejora, configure las cuentas de almacenamiento para que usen la replicación de
almacenamiento con redundancia de zona (ZRS) o de almacenamiento con redundancia
de zona geográfica (GZRS). Para más información sobre las distintas opciones de
redundancia de las cuentas de almacenamiento, consulte: Redundancia de Azure Files.

Nota: Azure File Sync tiene redundancia de zona en todas las regiones que admiten
zonas, excepto US Gov Virginia.

Novedades de la versión 2022

4.º trimestre de 2022 (octubre, noviembre, diciembre)

La autenticación Kerberos de Azure Active Directory (Azure AD)

para identidades híbridas en Azure Files tiene disponibilidad
general
Esta característica se basa en la compatibilidad con contenedores de perfiles de FSLogix
publicada en diciembre de 2022 y la amplía para admitir más casos de uso (solo SMB).
Las identidades híbridas, que son identidades de usuario creadas en Active Directory
Domain Services (AD DS) y sincronizadas con Azure AD, pueden montar recursos
compartidos de archivos de Azure y acceder a ellos sin necesidad de línea de visión a un
controlador de dominio de Active Directory. Aunque la compatibilidad inicial se limita a
las identidades híbridas, es un hito importante a medida que simplificamos la
autenticación basada en identidades para los clientes de Azure Files. Leer la entrada de
blog .

2.º trimestre de 2022 (abril, mayo, junio)

Compatibilidad de SUSE Linux con la replicación del sistema de

SAP HANA (HSR) y Pacemaker
Los clientes de Azure ahora pueden implementar un sistema SAP HANA de alta
disponibilidad en una configuración de escalabilidad horizontal con HSR y Pacemaker
en máquinas virtuales (VM) de Azure SUSE Linux Enterprise Server mediante recursos
compartidos de archivos de Azure NFS para un sistema de archivos compartido.

1.er trimestre de 2022 (enero, febrero, marzo)

Mejoras de TCO de Azure File Sync
Para ofrecer sincronización y división en niveles, Azure File Sync realiza dos tipos de
transacciones en nombre del cliente:

Transacciones de renovación, incluidos archivos modificados (sincronización) y

archivos recuperados (por niveles).
Transacciones de la enumeración de cambios en la nube, realizadas para detectar
los cambios realizados directamente en el recurso compartido de archivos de
Azure. Históricamente, este era un componente importante de la factura de Azure
Files de un cliente de Azure File Sync.

Para mejorar el TCO, hemos reducido notablemente el número de transacciones

necesarias para examinar completamente un recurso compartido de archivos de Azure.
Antes de este cambio, la mayoría de los clientes estaban mejor en el nivel de acceso
frecuente. Ahora la mayoría de los clientes están mejor en el nivel de acceso esporádico.

Novedades de la versión 2021

4.º trimestre de 2021 (octubre, noviembre y diciembre)

Aumento de IOPS para recursos compartidos de archivos Premium

Los recursos compartidos de archivos Premium de Azure ahora tienen IOPS de línea
base incluidas adicionales y un número de IOPS de ráfaga mínima más alto. La IOPS de
línea base incluida con un recurso compartido aprovisionado se incrementó de 400 a
3000, lo que significa que se garantizan 3100 IOPS de línea base para un recurso
compartido de 100 GiB (el tamaño de recurso compartido mínimo). Además, el suelo
para IOPS de ráfaga se incrementó de 4000 a 10 000, lo que significa que cada recurso
compartido de archivos Premium podrá ampliarse hasta al menos 10 000 IOPS.

Cambios en la fórmula:

Elemento Valor anterior Valor nuevo

Fórmula de IOPS de MIN(400 + 1 * ProvisionedGiB, MIN(3000 + 1 * ProvisionedGiB,

línea de base 100000) 100000)

Límite de aumento MIN(MAX(4000, 3 * MIN(MAX(10000, 3 *

ProvisionedGiB), 100000) ProvisionedGiB), 100000)

Para más información, consulte:

 Modelo aprovisionado para los recursos compartidos de archivos Premium
Precios de Azure Files

La compatibilidad con el protocolo NFSv4.1 está disponible con

carácter general
Los recursos compartidos de archivos Premium de Azure ahora admiten los protocolos
SMB o NFSv4.1 NFSv4.1 está disponible en todas las regiones donde Azure Files admite
el nivel Premium, tanto para almacenamiento con redundancia local como para
almacenamiento con redundancia de zona. Los recursos compartidos de archivos de
Azure creados con el protocolo NFSv4.1 habilitado son recursos compartidos de
archivos distribuidos totalmente compatibles con POSIX que admiten una amplia
variedad de cargas de trabajo basadas en contenedores y Linux. Algunas cargas de
trabajo de ejemplo incluyen: capa de aplicaciones SAP de alta disponibilidad, mensajería
empresarial, directorios principales de usuario, aplicaciones personalizadas de línea de
negocio, copias de seguridad de bases de datos, replicación de bases de datos y Azure
Pipelines.

Para más información, consulte:

Recursos compartidos de archivos NFS en Azure Files

Alta disponibilidad de SAP NetWeaver en máquinas virtuales de Azure utilizando
NFS en Azure Files
Precios de Azure Files

Rendimiento simétrico para recursos compartidos de archivos

Premium

Los recursos compartidos de archivos Premium de Azure ahora admiten el

aprovisionamiento de rendimiento simétrico, lo que permite que el rendimiento
aprovisionado para un recurso compartido de archivos de Azure se utilice para la
entrada al 100 %, la salida al 100 % o alguna combinación de entrada y salida. El
rendimiento simétrico proporciona la flexibilidad para aprovechar al máximo el
rendimiento disponible y alinea los recursos compartidos de archivos Premium con los
recursos compartidos de archivos Estándar.

Cambios en la fórmula:

Elemento Valor anterior Valor nuevo

Rendimiento Entrada: 40 + CEILING(0.04 * 100 + CEILING(0.04 * ProvisionedGiB) +

(MiB/s) ProvisionedGiB) CEILING(0.06 * ProvisionedGiB)
 Elemento Valor anterior Valor nuevo

Salida: 60 + CEILING(0.06 *
ProvisionedGiB)

Para más información, consulte:

Modelo aprovisionado para los recursos compartidos de archivos Premium

Precios de Azure Files

3\.er trimestre de 2021 ( julio, agosto, septiembre)

SMB multicanal está disponible con carácter general

SMB multicanal permite a los clientes SMB establecer varias conexiones paralelas a un
recurso compartido de archivos de Azure. Esto permite a los clientes SMB aprovechar al
máximo todo el ancho de banda de red disponible y los hace resistentes a los errores de
red, lo que reduce el costo total de propiedad y habilita 2-3x para lecturas y 3-4x para
escrituras a través de un solo cliente. SMB multicanal está disponible para recursos
compartidos de archivos Premium (recursos compartidos de archivos implementados en
el tipo de cuenta de almacenamiento FileStorage) y está deshabilitado de forma
predeterminada.

Para más información, consulte:

Rendimiento de SMB multicanal en Azure Files

Habilitar SMB multicanal
Información general sobre SMB multicanal en la documentación de
Windows Server

Configuración de seguridad de SMB 3.1.1 y SMB

SMB 3.1.1 es la versión más reciente del protocolo SMB, publicada con Windows 10, que
contiene actualizaciones importantes de seguridad y rendimiento. Azure Files SMB 3.1.1
se suministra con dos modos de cifrado adicionales, AES-128-GCM y AES-256-GCM,
además de AES-128-CCM, que ya se admite. Para maximizar el rendimiento, AES-128-
GCM se negocia como la opción de cifrado de canal SMB predeterminada; AES-128-
CCM solo se negociará en clientes anteriores que no admitan AES-128-GCM.

Según los requisitos normativos y de cumplimiento de la organización, se puede

negociar AES-256-GCM en lugar de AES-128-GCM, ya sea restringiendo las opciones de
cifrado del canal SMB permitidas en los clientes SMB, en Azure Files o en ambos. Se
agregó compatibilidad con AES-256-GCM en Windows Server 2022 y Windows 10,
versión 21H1.

Además de SMB 3.1.1, Azure Files expone la configuración de seguridad que cambia el
comportamiento del protocolo SMB. Con esta versión, puede configurar las versiones de
protocolo SMB permitidas, las opciones de cifrado del canal SMB, los métodos de
autenticación y las opciones de cifrado de vales de Kerberos. De manera
predeterminada, Azure Files habilita las opciones más compatibles, pero estas opciones
se pueden cambiar en cualquier momento.

Para más información, consulte:

Configuración de seguridad de SMB

Información de la versión SMB de Windows y Linux
Introducción a las características de SMB en la documentación de Windows Server

2\.º trimestre de 2021 (abril, mayo, junio)

Reservas de almacenamiento premium, de acceso frecuente y de

acceso esporádico
Azure Files admite reservas de almacenamiento (también denominadas instancias
reservadas). Las reservas de Azure Files le permiten conseguir un descuento en el
almacenamiento mediante la confirmación previa del uso del almacenamiento.
Azure Files admite reservas en los niveles premium, de acceso frecuente y de acceso
esporádico. Las reservas se venden en unidades de 10 TiB o 100 TiB, por periodos de un
año o tres años.

Para más información, consulte:

Descripción de la facturación de Azure Files

Optimización de costos para Azure Files con las reservas
Precios de Azure Files

Mejora de la experiencia del portal para la unión de dominios a

Active Directory

Se ha mejorado la experiencia de unirse a un dominio de una cuenta de

almacenamiento de Azure para ayudar a guiar a los administradores de recursos
compartidos de archivos de Azure por primera vez a través del proceso. Al seleccionar
Active Directory en File share settings (Configuración de recursos compartidos de
archivos) en la sección File shares (Recursos compartidos de archivos) de Azure Portal,
se le guiará por los pasos necesarios para la unión a un dominio.

Para más información, consulte:

Introducción a las opciones de autenticación basadas en la identidad de

Azure Files para el acceso con SMB
Introducción: autenticación de Active Directory Domain Services local en SMB para
recursos compartidos de archivos de Azure

1\.er trimestre de 2021 (enero, febrero, marzo)

Administración de Azure Files disponible ahora a través del plano

de control

Las API de administración de los recursos de Azure Files, el servicio de archivos y los
recursos compartidos de archivos están disponibles ahora a través del plano de control
(proveedor de recursos Microsoft.Storage ). Esto permite crear recursos compartidos de
archivos de Azure con una plantilla de Azure Resource Manager o Bicep, para que sean
totalmente administrables cuando el plano de datos (es decir, la API de FileREST) no
está accesible (como cuando el punto de conexión público de la cuenta de
almacenamiento está deshabilitado) y para admitir la semántica de control de acceso
basado en roles (RBAC) completa.

Se recomienda administrar Azure Files a través del plano de control en la mayoría de los
casos. Para admitir la administración del servicio de archivos y los recursos compartidos
de archivos a través del plano de control, Azure Portal, el módulo PowerShell de
Azure Storage y la CLI de Azure se han actualizado para admitir la mayoría de las
acciones de administración a través del plano de control.

Para conservar el comportamiento de los scripts existentes, el módulo PowerShell de

Azure Storage y la CLI de Azure mantienen los comandos existentes que utilizan el plano
de datos para administrar el servicio de archivos y los recursos compartidos de archivos,
además de agregar nuevos comandos para usar el plano de control. Las solicitudes del
portal solo pasan por el proveedor de recursos del plano de control. Los comandos de
PowerShell y la CLI se denominan de la siguiente manera:

Az.Storage PowerShell:
Los cmdlets de recurso compartido de archivos del plano de control llevan el
prefijo Rm , por ejemplo: New-AzRmStorageShare , Get-AzRmStorageShare , Update-
AzRmStorageShare y Remove-AzRmStorageShare .

Los cmdlets de recurso compartido de archivos de plano de datos tradicionales

no tienen prefijo, por ejemplo: New-AzStorageShare , Get-AzStorageShare , Set-
AzStorageShareQuota y Remove-AzStorageShare .

Los cmdlets para administrar el servicio de archivos solo están disponibles a

través del plano de control y no tienen ningún prefijo especial, por ejemplo,
Get-AzStorageFileServiceProperty y Update-AzStorageFileServiceProperty .

CLI de Azure Storage:

Los comandos del recurso compartido de archivos del plano de control están
disponibles en el grupo de comandos az storage share-rm , por ejemplo: az
storage share-rm create , az storage share-rm update , etc.

Los comandos del recurso compartido de archivos tradicional están disponibles

en el grupo de comandos az storage share , por ejemplo: az storage share
create , az storage share update , etc.

Los comandos para administrar el servicio de archivos solo están disponibles a

través del plano de control y no están disponibles a través del grupo de
comandos az storage account file-service-properties , por ejemplo: az
storage account file-service-properties show y az storage account file-
service-properties update .

Para obtener más información sobre la API de administración de Azure Files, consulte:

Información general de la API de REST de Azure Files

API del plano de control (proveedor de recursos Microsoft.Storage ) para recursos
de Azure Files:
FileService
FileShare
 Azure PowerShell y CLI de Azure

Consulte también
¿Qué es Azure Files?
Planeamiento de una implementación de Azure Files
Creación de un recurso compartido de archivos de Azure
Creación de un recurso compartido de
archivos SMB de Azure
Artículo • 21/10/2023

Para crear un recurso compartido de archivos de Azure, debe responder a tres

preguntas sobre cómo lo usará:

¿Cuáles son los requisitos de rendimiento para el recurso compartido de

archivos de Azure?
Azure Files ofrece recursos compartidos de archivos estándar, que se hospedan en
hardware basado en disco duro (HDD), y recursos compartidos de archivos
prémium, que se hospedan en hardware basado en disco de estado sólido (SSD).

¿Cuáles son los requisitos de redundancia para el recurso compartido de

archivos de Azure?
Los recursos compartidos de archivos estándar ofrecen almacenamiento con
redundancia local (LRS), redundancia de zona (ZRS), redundancia geográfica (GRS)
o redundancia de zona geográfica (GZRS). Sin embargo, la característica de
recursos compartido de archivos de gran tamaño solo se admite en los recursos
compartidos de archivos con redundancia local y redundancia de zona. Los
recursos compartidos de archivos prémium no admiten ninguna forma de
redundancia geográfica.

Los recursos compartidos de archivos prémium están disponibles con redundancia

local y redundancia de zona en un subconjunto de regiones. Para averiguar si los
recursos compartidos de archivos prémium están disponibles en su región,
consulte los productos disponibles por región . Para más información, consulte
Redundancia de Azure Files.

¿Qué tamaño de recurso compartido de archivos necesita?

En las cuentas de almacenamiento con redundancia local y de zona, los recursos
compartidos de archivos de Azure pueden abarcar hasta 100 TiB. Sin embargo, en
las cuentas de almacenamiento con redundancia geográfica y de zona geográfica,
los recursos compartidos de archivos de Azure solo pueden abarcar hasta 5 TiB, a
menos que se registre en el almacenamiento con redundancia geográfica para
recursos compartidos de archivos grandes (versión preliminar).

Para más información sobre estas tres opciones, consulte Planeamiento de una
implementación de Azure Files.
Se aplica a
Tipo de recurso compartido de archivos SMB NFS

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS

Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Requisitos previos
En este artículo, se da por supuesto que ya ha creado una suscripción a Azure. Si
todavía no tiene una suscripción, cree una cuenta gratuita antes de empezar.
Si planea usar Azure PowerShell, instale la versión más reciente.
Si planea usar la CLI de Azure, instale la versión más reciente.

Crear una cuenta de almacenamiento

Los recursos compartidos de archivos de Azure se implementan en cuentas de
almacenamiento, que son objetos de nivel superior que representan un grupo
compartido de almacenamiento. Este grupo de almacenamiento se puede usar para
implementar varios recursos compartidos de archivos.

Azure admite varios tipos de cuentas de almacenamiento para los distintos escenarios
de almacenamiento que pueden tener los clientes, pero hay dos tipos principales de
cuentas de almacenamiento para Azure Files. El tipo de cuenta de almacenamiento que
debe crear depende de si desea crear un recurso compartido de archivos estándar o un
recurso compartido de archivos prémium:

Cuentas de almacenamiento de uso general, versión 2 (GPv2) : Las cuentas de

almacenamiento de GPv2 permiten implementar recursos compartidos de archivos
de Azure en hardware estándar o basado en disco duro (HDD). Además de
almacenar recursos compartidos de archivos de Azure, las cuentas de
almacenamiento de GPv2 pueden almacenar otros recursos de almacenamiento,
como contenedores de blobs, colas o tablas. Los recursos compartidos de archivos
se pueden implementar en los niveles de transacción optimizada (valor
predeterminado), acceso frecuente o acceso esporádico.

Cuentas de almacenamiento FileStorage: Las cuentas de almacenamiento

FileStorage permiten implementar recursos compartidos de archivos de Azure en
hardware prémium o basado en unidades de estado sólido (SSD). Las cuentas
 FileStorage solo se pueden usar para almacenar recursos compartidos de archivos
de Azure. No se puede implementar ningún otro recurso de almacenamiento
(contenedores de blobs, colas, tablas, etc.) en una cuenta FileStorage.

Portal

Para crear una cuenta de almacenamiento mediante Azure Portal, seleccione +

Crear un recurso en el panel. En la ventana de búsqueda de Azure Marketplace que
aparece, busque cuenta de almacenamiento y seleccione el resultado de la
búsqueda resultante. Esta operación le dirigirá a una página de información general
de las cuentas de almacenamiento. Seleccione Crear para continuar con el Asistente
para crear cuentas de almacenamiento.

Aspectos básicos

La primera sección que se debe rellenar para crear una cuenta de almacenamiento
se denomina Datos básicos. Contiene todos los campos obligatorios para crear una
cuenta de almacenamiento. Para crear una cuenta de almacenamiento de GPv2,
asegúrese de que el botón de radio Rendimiento está establecido en Estándar y
que la lista desplegable Tipo de cuenta tiene seleccionada la opción StorageV2
(general purpose v2) StorageV2 (uso general V2).
Para crear una cuenta de almacenamiento de FileStorage, asegúrese de que el
botón de radio Rendimiento esté configurado en Prémium y Fileshares esté
seleccionado en la lista desplegable Tipo de cuenta prémium.

Los demás campos de datos básicos son independientes de la elección de la cuenta

de almacenamiento:

Nombre de la cuenta de almacenamiento: nombre del recurso de la cuenta

de almacenamiento que se va a crear. Este nombre debe ser único
globalmente. El nombre de la cuenta de almacenamiento se usará como el
nombre del servidor al montar un recurso compartido de archivos de Azure a
través de SMB. Los nombres de cuenta de almacenamiento deben tener una
longitud de entre 3 y 24 caracteres. Solo pueden contener números y letras
minúsculas.
Ubicación: región de la cuenta de almacenamiento donde se va a realizar la
implementación. Puede ser la región asociada al grupo de recursos o
cualquier otra región disponible.
Replication (Replicación): aunque se trata de replicación etiquetada, este
campo significa redundancia en realidad; este es el nivel de redundancia
deseado: redundancia local (LRS), redundancia de zona (ZRS), redundancia
geográfica (GRS) y redundancia de zona geográfica (GZRS). Esta lista
desplegable también contiene redundancia geográfica con acceso de lectura
(RA-GRS) y redundancia de zona geográfica con acceso de lectura (RA-GZRS),
que no se aplican a los recursos compartidos de archivos de Azure. Los
recursos compartidos de archivos creados en una cuenta de almacenamiento
con estas opciones seleccionadas tendrán redundancia geográfica o
redundancia de zona geográfica, respectivamente.

Redes

La sección Redes le permite configurar las opciones de redes. Esta configuración es

opcional para la creación de la cuenta de almacenamiento y se puede configurar
más adelante si lo desea. Para obtener más información sobre estas opciones, vea
Consideraciones de redes para Azure Files.

Protección de datos
La sección de protección de datos le permite configurar la directiva de eliminación
temporal para recursos compartidos de archivos de Azure en su cuenta de
almacenamiento. Otras opciones relacionadas con la eliminación temporal de blobs
y contenedores, la restauración a un momento dado de contenedores, el control de
versiones y la fuente de cambios solo se aplican a Azure Blob Storage.

Avanzadas
La sección Opciones avanzadas contiene varias opciones de configuración
importantes para los recursos compartidos de archivos de Azure:

Se requiere transferencia segura: este campo indica si la cuenta de

almacenamiento requiere cifrado en tránsito para la comunicación con la
cuenta de almacenamiento. Si requiere compatibilidad con SMB 2.1, debe
deshabilitarlo.

Recursos compartidos de archivos grandes: este campo habilita la cuenta de

almacenamiento para los recursos compartidos de archivos de hasta 100 TiB.
Al habilitar esta característica, se limita la cuenta de almacenamiento a las
opciones de almacenamiento con redundancia local y redundancia de zona
solamente. Una vez habilitada una cuenta de almacenamiento de GPv2 para
los recursos compartidos de archivos grandes, no se puede deshabilitar la
funcionalidad de recurso compartido de archivos grandes. Las cuentas de
almacenamiento de FileStorage (cuentas de almacenamiento para recursos
compartidos de archivos prémium) no tienen esta opción, ya que todos los
recursos compartidos de archivos prémium se pueden escalar hasta 100 TiB.

Los demás valores de configuración que están disponibles en la pestaña Opciones

avanzadas (espacio de nombres jerárquico para Azure Data Lake Storage Gen 2,
 nivel de blob predeterminado, NFSv3 para Blob Storage, etc.) no se aplican a Azure
Files.

） Importante

La selección del nivel de acceso del blob no afecta al nivel del recurso
compartido de archivos.

Etiquetas
Las etiquetas son pares nombre-valor que permiten categorizar los recursos y ver
una facturación consolidada mediante la aplicación de la misma etiqueta en varios
recursos y grupos de recursos. Son opcionales y se pueden aplicar después de la
creación de la cuenta de almacenamiento.

Revisar y crear
El paso final para crear la cuenta de almacenamiento es seleccionar el botón Crear
en la pestaña Revisar y crear. Este botón no estará disponible a menos que se
hayan rellenado todos los campos obligatorios para una cuenta de
almacenamiento.

Habilitación de recursos compartidos de archivos de gran

tamaño en una cuenta existente
Antes de crear un recurso compartido de archivos de Azure en una cuenta de
almacenamiento existente, es posible que quiera habilitar los recursos compartidos de
archivos de gran tamaño (de hasta 100 TiB) en la cuenta de almacenamiento si todavía
no lo ha hecho. Las cuentas de almacenamiento estándar que usan LRS o ZRS se
pueden actualizar para admitir recursos compartidos de archivos grandes sin provocar
tiempo de inactividad para los recursos compartidos de archivos existentes en la cuenta
de almacenamiento. Si tiene una cuenta GRS, GZRS, RA-GRS o RA-GZRS, deberá
convertirla en una cuenta LRS antes de continuar o registrarse para la versión preliminar
de redundancia geográfica de Azure Files para recursos compartidos de archivos
grandes.

Portal
 1. Abra Azure Portal y navegue hasta la cuenta de almacenamiento donde
quiere habilitar los recursos compartidos de archivos grandes.
2. Seleccione Configuración en la sección Configuración.
3. Vaya a la configuración Recursos compartidos de archivos grandes en la
parte inferior de la página. Si se establece en Deshabilitado, cambie la
configuración a Habilitado.
4. Seleccione Guardar.

Creación de un recurso compartido de archivos

Una vez que haya creado una cuenta de almacenamiento, puede crear un recurso
compartido de archivos. Este proceso es prácticamente el mismo, independientemente
de si usa un recurso compartido de archivos prémium o un recurso compartido de
archivos estándar. Debe tener en cuenta las siguientes diferencias:

Los recursos compartidos de archivos estándar pueden implementarse en uno de los

niveles estándar: optimizado para transacciones (valor predeterminado), acceso
frecuente o acceso esporádico. Se trata de un nivel de recurso compartido de archivos
que no se ve afectado por el nivel de acceso de blob de la cuenta de almacenamiento
(esta propiedad solo se relaciona con Azure Blob Storage, no está relacionada con
Azure Files). Puede cambiar el nivel del recurso compartido en cualquier momento una
vez implementado. Los recursos compartidos de archivos prémium no se pueden
convertir directamente a ningún nivel estándar.

） Importante

Los recursos compartidos de archivos se pueden mover entre niveles dentro de los
tipos de cuenta de almacenamiento GPv2 (transacción optimizada, nivel de acceso
frecuente y nivel de acceso esporádico). Los movimientos de recursos compartidos
entre niveles incurren en transacciones: el traslado de un nivel de acceso frecuente
a un nivel de acceso esporádico incurrirá en el cargo de transacción de escritura del
nivel de acceso esporádico, mientras que si dicho traslado se realiza de un nivel
esporádico a un nivel frecuente, todos los archivos incurrirán en el cargo de
transacción de lectura del nivel de acceso esporádico.

Portal
Siga estas instrucciones para crear un nuevo recurso compartido de archivos de
Azure mediante Azure Portal.

1. Si acaba de crear la cuenta de almacenamiento, puede navegar a esta desde la

pantalla de implementación. Para ello, seleccione Ir al recurso. Una vez en la
cuenta de almacenamiento, seleccione Recurso compartido de archivos en la
tabla de contenido de la cuenta de almacenamiento.

2. En la lista de recursos compartidos de archivos, debería ver los recursos

compartidos de archivos creados previamente en esta cuenta de
almacenamiento; se muestra una tabla vacía si aún no se han creado recursos
compartidos de archivos. Seleccione + Recurso compartido de archivos para
crear un recurso compartido de archivos.

3. La hoja Nuevo recurso compartido de archivos debería aparecer en la pantalla.

Complete los campos de la pestaña Básico de la hoja de nuevo recurso
compartido de archivos para crear un recurso de este tipo:

Nombre: nombre del recurso compartido de archivos que se va a crear.

Nivel: nivel seleccionado para un recurso compartido de archivos

estándar. Este campo solo está disponible en un tipo de cuenta de
almacenamiento de uso general (GPv2). Puede elegir los niveles
optimizado para transacciones, acceso frecuente o acceso esporádico. El
nivel del recurso compartido de archivos se puede cambiar en cualquier
momento. Se recomienda elegir el nivel de acceso más frecuente posible
durante una migración para minimizar los gastos de transacciones y, a
continuación, cambiar a un nivel inferior si lo desea una vez completada
la migración.

Capacidad aprovisionada: solo para recursos compartidos de archivos

prémium; la capacidad aprovisionada es la cantidad que se le facturará,
independientemente del uso real. Este campo solo está disponible en un
tipo de cuenta de almacenamiento FileStorage. Los valores de IOPS y
rendimiento disponibles en un recurso compartido de archivos prémium
se basan en la capacidad aprovisionada, por lo que puede aprovisionar
más capacidad para obtener más rendimiento. El recurso compartido de
archivos prémium mínimo es de 100 GiB. Para obtener más información
sobre cómo planear un recurso compartido de archivos prémium,
consulte el tema sobre el aprovisionamiento de recursos compartidos de
archivos prémium.
 4. Seleccione la pestaña Copia de seguridad. De forma predeterminada, la copia
de seguridad se habilita al crear un recurso compartido de archivos de Azure
mediante Azure Portal. Si quiere deshabilitar la copia de seguridad para el
recurso compartido de archivos, desactive la casilla Habilitar copia de
seguridad. Si quiere habilitar la copia de seguridad, puede dejar los valores
predeterminados o bien crear un almacén de Recovery Services en la misma
región y suscripción de la cuenta de almacenamiento. Para crear una directiva
de copia de seguridad, seleccioneCrear una nueva directiva.

5. Seleccione Revisar y crear y, después, Crear para crear el recurso compartido

de archivos de Azure.

７ Nota

El nombre del recurso compartido de archivos debe estar formado por letras
minúsculas, números y guiones únicos, y debe comenzar y terminar con un número
o una letra en minúscula. El nombre no puede contener dos guiones consecutivos.
Para obtener detalles completos sobre cómo asignar un nombre a los recursos
compartidos y los archivos, consulte Asignación de nombres y referencia a
recursos compartidos, directorios, archivos y metadatos.

Cambio del nivel de un recurso compartido de archivos

de Azure
Los recursos compartidos de archivos que se implementan en una cuenta de
almacenamiento de uso general v2 (GPv2) pueden pertenecer a los niveles optimizado
para transacciones, de acceso frecuente o de acceso esporádico. Puede cambiar el nivel
del recurso compartido de archivos de Azure en cualquier momento, en función de los
costos de las transacciones, tal como se ha descrito anteriormente.

Portal

En la página de la cuenta de almacenamiento principal, seleccione Recursos

compartidos de archivos y seleccione el icono con la etiqueta Recursos
compartidos de archivos (también puede navegar a Recursos compartidos de
archivos a través de la tabla de contenido de la cuenta de almacenamiento).
En la lista de tabla de recursos compartidos de archivos, seleccione el recurso para
el que desea cambiar el nivel. En la página información general del recurso
compartido de archivos, seleccione Cambiar nivel en el menú.

En el cuadro de diálogo resultante, seleccione el nivel deseado: optimizado para

transacciones, acceso frecuente o acceso esporádico.
Expansión de recursos compartidos de archivos existentes
Si habilita recursos compartidos de archivos grandes en una cuenta de almacenamiento
existente, tendrá que expandir los recursos compartidos de archivos existentes de esa
cuenta de almacenamiento para aprovechar el aumento de la capacidad y la escala.

Portal

1. En la cuenta de almacenamiento, seleccione Recurso compartido de archivos.

2. Haga clic con el botón derecho en el recurso compartido de archivos y
seleccione Cuota.
3. Escriba el nuevo tamaño que quiera y, luego, seleccione Aceptar.

Eliminación de un recurso compartido de

archivos
Para eliminar un recurso compartido de archivos de Azure, puede usar Azure Portal,
Azure PowerShell o la CLI de Azure. Los recursos compartidos de archivos SMB de Azure
se pueden recuperar dentro del período de retención de la eliminación temporal.

Portal

1. Abra Azure Portal y vaya a la cuenta de almacenamiento que contiene el

recurso compartido de archivos que quiere eliminar.
2. Abra la cuenta de almacenamiento y seleccione Recursos compartidos de
archivos.
3. Seleccione el recurso compartido de archivos que quiere eliminar.
4. Seleccione Eliminar recurso compartido.
5. Active la casilla que confirma que acepta la eliminación del recurso
compartido de archivos y todo su contenido.
6. Seleccione Eliminar.
 

Pasos siguientes
Planeamiento de una implementación de Azure Files o Planeamiento de una
implementación de Azure File Sync.
Consideraciones de redes para Azure Files.
Monte un recurso compartido de archivos SMB en Windows, macOS o Linux.
Tutorial: Creación de un recurso
compartido de archivos NFS de Azure y
montaje del mismo en una máquina
virtual Linux mediante Azure Portal
Artículo • 10/10/2023

Azure Files ofrece recursos compartidos de archivos totalmente administrados en la

nube a los que se puede acceder mediante el protocolo SMB (Bloque de mensajes del
servidor) o el protocolo NFS (Network File System) estándar del sector. Los protocolos
NFS y SMB se admiten en máquinas virtuales (VM) de Azure que ejecutan Linux. En este
tutorial se muestra cómo crear un recurso compartido de archivos de Azure mediante el
protocolo NFS y conectarlo a una máquina virtual Linux.

En este tutorial, aprenderá lo siguiente:

＂ Crear una cuenta de almacenamiento

＂ Implementación de una máquina virtual Linux
＂ Creación de un recurso compartido de archivos NFS
＂ Conexión a la máquina virtual
＂ Montaje del recurso compartido de archivos en la máquina virtual

Se aplica a
Tipo de recurso compartido de archivos SMB NFS

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS

Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Introducción
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Inicie sesión en Azure Portal .

Creación de una cuenta de almacenamiento FileStorage

Para poder trabajar con un recurso compartido de archivos NFS 4.1 de Azure, es
necesario que cree una cuenta de almacenamiento de Azure con el nivel de rendimiento
prémium. Actualmente, los recursos compartidos de NFS 4.1 solo están disponibles
como recursos compartidos de archivos prémium.

1. En el menú de Azure Portal, seleccione Todos los servicios. En la lista de recursos,

escriba Cuentas de almacenamiento. Cuando comience a escribir, la lista se filtrará
en función de la entrada. Seleccione Cuentas de almacenamiento.
2. En la ventana Cuentas de almacenamiento que aparece, elija + Crear.
3. En la pestaña Aspectos básicos, seleccione la suscripción en la que se va a crear la
cuenta de almacenamiento.
4. En el campo Grupo de recursos, seleccione Crear nuevo para crear un grupo de
recursos nuevo para usar en este tutorial.
5. Escriba un nombre para la cuenta de almacenamiento. El nombre que elija debe
ser único en Azure. El nombre también debe tener una longitud de entre 3 y 24
caracteres, y solo puede contener números y letras minúsculas.
6. Seleccione una región para la cuenta de almacenamiento o utilice la región
predeterminada. Azure admite recursos compartidos de archivos NFS en las
mismas regiones que admiten el almacenamiento de archivos prémium.
7. Seleccione el nivel de rendimiento Premium para almacenar los datos en unidades
de estado sólido (SSD). En Tipo de cuenta Premium, seleccione Recursos
compartidos de archivos.
8. Mantenga la opción de replicación establecida en su valor predeterminado de
Almacenamiento con redundancia local (LRS).
9. Seleccione Revisar y crear para revisar la configuración de la cuenta de
almacenamiento y crear la cuenta.
10. Cuando aparezca la notificación Validación superada, seleccione Crear. Debería
ver una notificación informándole de que la implementación está en curso.

En la imagen siguiente se muestra la configuración de la pestaña Aspectos básicos de

una nueva cuenta de almacenamiento:
 

Implementación de una máquina virtual de

Azure que ejecuta Linux
A continuación, cree una máquina virtual de Azure que ejecute Linux para representar el
servidor en el entorno local. Al crear la máquina virtual, se creará automáticamente una
red virtual. El protocolo NFS solo se puede usar desde una máquina dentro de una red
virtual.

1. Seleccione Inicio y, a continuación, Máquinas virtuales en Servicios de Azure.

2. Seleccione + Crear y, después, + Máquina virtual de Azure.

3. En la pestaña Aspectos básicos, en Detalles del proyecto, asegúrese de que la

suscripción y el grupo de recursos correctos están seleccionados. En Detalles de
instancia, escriba myVM en Nombre de máquina virtual y seleccione la misma
región que la cuenta de almacenamiento. Elija la distribución de Linux para la
imagen. Deje los demás valores predeterminados. El tamaño y los precios
predeterminados solo se muestran como ejemplo. La disponibilidad y los precios
del tamaño dependen de su región y suscripción.
 

4. En Cuenta de administrador , seleccione Clave pública SSH. Deje el resto de

valores predeterminados.

5. En Reglas de puerto de entrada > Puertos de entrada públicos, elija Permitir los
puertos seleccionados y luego seleccione SSH (22) y HTTP (80) en la lista
desplegable.
 

） Importante

Solo se recomienda establecer puertos SSH abiertos a Internet para realizar

pruebas. Si quiere cambiar esta configuración más adelante, vuelva a la
pestaña Aspectos básicos.

6. Seleccione el botón Revisar y crear de la parte inferior de la página.

7. En la página Crear una máquina virtual verá los detalles de la máquina virtual que
va a crear. Anote el nombre de la red virtual. Cuando esté preparado, seleccione
Crear.

8. Cuando se abra la ventana Generar nuevo par de claves, seleccione Descargar la

clave privada y crear el recurso. El archivo de clave se descargará como
myVM_key.pem. Asegúrese de saber dónde se descargó el archivo .pem, ya que
necesitará la ruta de acceso al archivo para conectarse a la máquina virtual.

Verá un mensaje que indica que la implementación está en curso. Espere unos minutos
a que se complete la implementación.

Creación de un recurso compartido de archivos

NFS de Azure
Ahora está listo para crear un recurso compartido de archivos NFS y proporcionar
seguridad de nivel de red para el tráfico NFS.

Adición de un recurso compartido de archivos a la cuenta

de almacenamiento
1. Seleccione Inicio y, a continuación, Cuentas de almacenamiento.
2. Seleccione la cuenta de almacenamiento que ha creado.

3. Seleccione Almacenamiento de datos y Recursos compartidos de archivos en el

panel de la cuenta de almacenamiento.

4. Seleccione + Recurso compartido de archivos.

5. Asigne al nuevo recurso compartido de archivos el nombre qsfileshare y escriba

"100" para la Capacidad mínima aprovisionada o aprovisione más capacidad
(hasta 102 400 GiB) para obtener más rendimiento. Seleccione el protocolo NFS,
deje seleccionada la opción Sin restringir raíz y seleccione Crear.
 

Configurar un punto de conexión privado o un punto de

conexión de servicio
A continuación, configure un punto de conexión privado para la cuenta de
almacenamiento. Esto proporciona a la cuenta de almacenamiento una dirección IP
privada desde el espacio de direcciones de la red virtual. Se aplican las tasas de
procesamiento de datos estándar para los puntos de conexión privados. Si no
necesita una dirección IP estática, puede usar un punto de conexión de servicio en su
lugar. No se realiza ningún cargo adicional por el uso de puntos de conexión de servicio.

1. Seleccione el recurso compartido de archivos qsfileshare. Debería ver un cuadro de

diálogo que indica Conectar a este recurso compartido de NFS desde Linux. En
Configuración de red, seleccione Opciones de revisión.

2. A continuación, seleccione Configurar un punto de conexión privado.

3. Seleccione + Punto de conexión privado.

4. Deje Suscripción y Grupo de recursos como están. En Instancia, proporcione un
nombre y seleccione una región para el nuevo punto de conexión privado. El
punto de conexión privado debe estar en la misma región que la red virtual, por lo
que debe usar la misma región que especificó al crear la máquina virtual. Cuando
haya completado todos los campos, seleccione Siguiente: Recurso.

5. Confirme que la Suscripción, el Tipo de recurso y el Recurso son correctos y

seleccione Archivo en la lista desplegable Subrecurso de destino. A continuación,
seleccione Siguiente: Red virtual.


6. En Redes, seleccione la red virtual asociada a la máquina virtual y deje la subred
predeterminada. En la sección Configuración de IP privada, seleccione Asignar
dirección IP de forma dinámica. Seleccione Next: DNS (Siguiente: DNS).

7. En Integrar con la zona DNS privada, seleccione Sí. Asegúrese de que están
seleccionados la suscripción y el grupo de recursos correctos y, después,
seleccione Siguiente: Etiquetas.

8. Opcionalmente, puede aplicar etiquetas para clasificar los recursos, como aplicar el
nombre Entorno y el valor Prueba a todos los recursos de prueba. Escriba pares
 nombre-valor si quiere y, a continuación, seleccione Siguiente: Revisar y crear.

9. Azure intentará validar el punto de conexión privado. Una vez completada la

validación, seleccione Crear. Verá una notificación informándole de que la
implementación está en curso. Transcurridos unos minutos, debería ver una
notificación indicando que la implementación se ha completado.

Deshabilitación de la transferencia segura

Azure Files no admite actualmente el cifrado en tránsito con el protocolo NFS y se basa
en la seguridad de nivel de red. Por lo tanto, deberá deshabilitar la transferencia segura.

1. Seleccione Inicio y, a continuación, Cuentas de almacenamiento.

2. Seleccione la cuenta de almacenamiento que ha creado.

3. Seleccione Recursos compartidos de archivos en el panel de la cuenta de

almacenamiento.

4. Seleccione el recurso compartido de archivos NFS que ha creado. En

Configuración de transferencia segura, seleccione Cambiar configuración.


 5. Cambie la opción Se requiere transferencia segura a Deshabilitado y seleccione
Guardar. El cambio puede tardar hasta 30 segundos en surtir efecto.

Conexión a la máquina virtual

Cree una conexión SSH con la máquina virtual.

1. Seleccione Inicio y, a continuación, Máquinas virtuales.

2. Seleccione la máquina virtual Linux que ha creado para este tutorial y asegúrese de
que su estado es En ejecución. Tome nota de la dirección IP pública de la máquina
virtual y cópiela en el portapapeles.

3. Si está en una máquina Mac o Linux, abra un símbolo del sistema de Bash. Si está
en una máquina Windows, abra un símbolo del sistema de PowerShell.

4. Cuando se le solicite, abra una conexión SSH a la máquina virtual. Reemplace la

dirección IP por la de la máquina virtual y reemplace la ruta de acceso al archivo
 .pem por la ruta de acceso a la ubicación en la que se descargó el archivo de clave.

Consola

ssh -i .\Downloads\myVM_key.pem [email protected]

Si recibe una advertencia de que no se puede establecer la autenticidad del host, escriba
sí para continuar con la conexión a la máquina virtual. Deje abierta la conexión SSH para
el paso siguiente.

 Sugerencia

Ahora la clave SSH que creó se puede usar la próxima vez que cree una máquina
virtual en Azure. Solo tiene que seleccionar la opción Usar la clave existente
almacenada en Azure en Origen de clave pública SSH la próxima vez que cree una
máquina virtual. Ya dispone de la clave privada en el equipo, por lo que no tendrá
que descargar nada.

Montaje de recurso compartido de archivos

NFS
Ahora que ha creado un recurso compartido de NFS, para usarlo debe montarlo en el
cliente Linux.

1. Seleccione Inicio y, a continuación, Cuentas de almacenamiento.

2. Seleccione la cuenta de almacenamiento que ha creado.

3. Seleccione Recursos compartidos de archivos en el panel de la cuenta de

almacenamiento y seleccione el recurso compartido de archivos NFS que ha
creado.

4. Debería consultar Conexión a este recurso compartido de archivos NFS desde

Linux junto con comandos de ejemplo para usar NFS en la distribución de Linux y
un script de montaje que contenga las opciones de montaje necesarias. Para ver
otras opciones de montaje recomendadas, consulte Montaje del recurso
compartido de archivos de Azure NFS en Linux.

） Importante
 El script de montaje proporcionado montará el recurso compartido NFS solo
hasta que se reinicie la máquina Linux. Para montar automáticamente el
recurso compartido cada vez que se reinicia la máquina, consulte Montaje de
un recurso compartido NFS mediante /etc/fstab.

5. Seleccione su distribución de Linux.

6. Mediante la conexión SSH que ha creado con la máquina virtual, escriba los
comandos de ejemplo para usar NFS y montar el recurso compartido de archivos.

Ahora ha montado el recurso compartido de archivos NFS y está listo para almacenar
archivos.

Limpieza de recursos
Cuando haya terminado, elimine el grupo de recursos. Al eliminar el grupo de recursos,
se elimina la cuenta de almacenamiento, el recurso compartido de archivos de Azure y
otros recursos que se implementaron en el grupo de recursos.

1. Seleccione Inicio y, a continuación, seleccione Grupos de recursos.

2. Seleccione el grupo de recursos que ha creado para este tutorial.
3. Seleccione Eliminar grupo de recursos. Se abre una ventana con una advertencia
acerca de los recursos que se eliminarán con el grupo de recursos.
4. Escriba el nombre del grupo de recursos y, luego, seleccione Eliminar.

Pasos siguientes
Obtenga más información sobre el uso de recursos compartidos de archivos NFS
de Azure
.
Uso de Espacios de nombres DFS con
Azure Files
Artículo • 24/05/2023

Espacios de nombres del Sistema de archivos distribuido, normalmente conocido como

Espacios de nombres DFS o DFS-N, es un rol de servidor de Windows Server muy
utilizado para simplificar la implementación y el mantenimiento de los recursos
compartidos de archivos SMB en la producción. Espacios de nombres DFS es una
tecnología de virtualización de espacios de nombres de almacenamiento, lo que
significa que le permite proporcionar una capa de direccionamiento indirecto entre la
ruta de acceso UNC de los recursos compartidos de archivos y los recursos compartidos
de archivos en sí. Los espacios de nombres DFS funcionan con recursos compartidos de
archivos SMB y se hospedan con independencia de estos: se pueden usar con recursos
compartidos de SMB hospedados en un servidor de archivos de Windows local con o
sin Azure File Sync, recursos compartidos de archivos de Azure directamente, recursos
compartidos de archivos SMB hospedados en Azure NetApp Files u otras ofertas de
terceros, e incluso con recursos compartidos de archivos hospedados en otras nubes.

Básicamente, Espacios de nombres DFS proporciona una asignación entre una ruta de
acceso UNC descriptiva, como \\contoso\shares\ProjectX , y la ruta de acceso UNC
subyacente del recurso compartido SMB, como \\Server01-Prod\ProjectX o
\\storageaccount.file.core.windows.net\projectx . Cuando el usuario final quiere

navegar al recurso compartido de archivos, escribe la ruta de acceso UNC descriptiva,

pero el cliente SMB accede a la ruta de acceso SMB subyacente de la asignación.
También puede ampliar este concepto básico para que asuma un nombre de servidor de
archivos existente, como \\MyServer\ProjectX . Puede usar esta funcionalidad para
conseguir lo siguiente:

Proporcionar un nombre a prueba de migraciones para un conjunto lógico de

datos. En este ejemplo, tiene una asignación como \\contoso\shares\Engineering
que se asigna a \\OldServer\Engineering . Cuando complete la migración a
Azure Files, puede cambiar la asignación para que la ruta de acceso UNC
descriptiva apunte a \\storageaccount.file.core.windows.net\engineering .
Cuando un usuario final acceda a la ruta de acceso UNC descriptiva, se le redirigirá
sin problemas a la ruta de acceso del recurso compartido de archivos de Azure.

Establecer un nombre común para un conjunto lógico de datos que se distribuye a

varios servidores en distintos sitios físicos, por ejemplo, a través de Azure File Sync.
En este ejemplo, un nombre como \\contoso\shares\FileSyncExample se asigna a
 varias rutas de acceso UNC, como \\FileSyncServer1\ExampleShare ,
\\FileSyncServer2\DifferentShareName y \\FileSyncServer3\ExampleShare . Cuando
el usuario accede a la UNC descriptiva, se le proporciona una lista de rutas de
acceso UNC posibles y este elige la más cercana en función de las definiciones de
sitio de Windows Server Active Directory (AD).

Ampliar un conjunto lógico de datos más allá de los umbrales de tamaño, E/S u
otras escalas. Esto es habitual cuando se trabaja con directorios de usuario, en los
que cada usuario obtiene su carpeta propia en un recurso compartido, o con los
recursos compartidos temporales, donde los usuarios obtienen un espacio
arbitrario para administrar las necesidades de datos temporales. Con Espacios de
nombres DFS, se unen varias carpetas en un espacio de nombres cohesionado. Por
ejemplo, \\contoso\shares\UserShares\user1 se asigna a
\\storageaccount.file.core.windows.net\user1 ,

\\contoso\shares\UserShares\user2 se asigna a
\\storageaccount.file.core.windows.net\user2 y así sucesivamente.

Puede ver un ejemplo de cómo usar Espacios de nombres DFS con su implementación
de Azure Files en el vídeo de introducción siguiente.

７ Nota

Vaya al minuto 10:10 del vídeo para ver cómo configurar Espacios de nombres DFS.

Si ya tiene un espacio de nombres DFS, no es necesario realizar ningún paso especial

para usarlo con Azure Files y File Sync. Si accede al recurso compartido de archivos de
Azure desde el entorno local, se aplican las consideraciones habituales para las redes.
Consulte Consideraciones de redes para Azure Files para obtener más información.

Se aplica a
Tipo de recurso compartido de archivos SMB NFS

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS

Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Tipos de espacios de nombres

Espacios de nombres DFS proporciona dos tipos de espacio de nombres principales:

Espacio de nombres basado en dominio: un espacio de nombres hospedado

como parte del dominio de Windows Server AD. Los espacios de nombres
hospedados como parte de AD tendrán una ruta de acceso UNC que contiene el
nombre del dominio, por ejemplo, \\contoso.com\shares\myshare si el dominio es
contoso.com . Los espacios de nombres basados en dominio admiten límites de

escalado más altos y redundancia integrada a través de AD. Asimismo, no pueden

ser un recurso en clúster de conmutación por error.
Espacio de nombres independiente: un espacio de nombres hospedado en un
servidor individual, no como parte de Windows Server AD. El nombre de los
espacios de nombres independientes se basarán en el nombre del servidor
independiente, como \\MyStandaloneServer\shares\myshare , donde el servidor
independiente se llama MyStandaloneServer . Los espacios de nombres
independientes admiten destinos de escala inferiores a los espacios de nombres
basados en dominio, pero pueden hospedarse como un recurso en clúster de
conmutación por error.

Requisitos
Para usar Espacios de nombres DFS con Azure Files y File Sync, debe tener los recursos
siguientes:

Un dominio de Active Directory. Se puede hospedar en cualquier lugar que quiera,

como en el entorno local, en una máquina virtual (VM) de Azure o incluso en otra
nube.
 Una instancia de Windows Server que puede hospedar el espacio de nombres. Un
patrón de implementación común para los espacios de nombres DFS consiste en
usar el controlador de dominio de Active Directory para hospedarlos, si bien los
espacios de nombres pueden configurarse desde cualquier servidor que tenga el
rol de servidor Espacios de nombres DFS instalado. Espacios de nombres DFS está
disponible en todas las versiones compatibles de Windows Server.
Un recurso compartido de archivos SMB hospedado en un entorno unido a un
dominio, como un recurso compartido de archivos de Azure hospedado en una
cuenta de almacenamiento unida a un dominio o un recurso compartido de
archivos hospedado en un servidor de archivos de Windows unido a un dominio
con Azure File Sync. Para obtener más información sobre cómo unir a un dominio
la cuenta de almacenamiento, consulte el artículo sobre la autenticación basada en
la identidad. Los servidores de archivos de Windows se unen a un dominio de la
misma manera, independientemente de que use Azure File Sync o no.
Los recursos compartidos de archivos SMB que quiere usar con Espacios de
nombres DFS deben ser accesibles desde las redes locales. Esto es un problema
sobre todo para los recursos compartidos de archivos de Azure; sin embargo,
técnicamente, se aplica a cualquier recurso compartido de archivos hospedado en
Azure o en cualquier otra nube. Para obtener más información sobre las redes,
consulte el documento sobre consideraciones de redes para el acceso directo.

Instalación del rol de servidor Espacios de

nombres DFS
Si ya está usando Espacios de nombres DFS o quiere configurar este rol en el
controlador de dominio, puede omitir estos pasos sin riesgo alguno.

Portal

Para instalar el rol de servidor Espacios de nombres DFS, abra el Administrador del
servidor en el servidor. Seleccione Administrar y, a continuación, elija Agregar roles
y características. El asistente que aparece le guía a través del proceso de instalación
de los componentes de Windows necesarios para ejecutar y administrar los
espacios de nombres DFS.

En la sección Tipo de instalación del asistente para instalación, seleccione el botón

de radio Instalación basada en características o en roles y elija Siguiente. En la
sección Selección del servidor, seleccione los servidores en los que quiera instalar
el rol de servidor Espacios de nombres DFS y elija Siguiente.
 En la sección Roles de servidor, seleccione el rol Espacios de nombres DFS en la
lista de roles. Puede encontrarla en Servicios de archivos y
almacenamiento>Servicios de iSCSI y archivo. Al seleccionar el rol de servidor
Espacios de nombres DFS, también puede agregar cualquier característica o rol de
servidor compatible necesario que aún no tenga instalados.

Después de haber seleccionado el rol Espacios de nombres DFS, puede seleccionar

Siguiente en todas las pantallas posteriores y elegir Instalar tan pronto como se
habilite el botón en el asistente. Una vez completada la instalación, puede
configurar el espacio de nombres.

Uso de los nombres de servidor existentes con

la consolidación raíz
Un uso importante de los espacios de nombres DFS es asumir un nombre de servidor
existente para refactorizar el diseño físico de los recursos compartidos de archivos. Por
ejemplo, puede que quiera consolidar los recursos compartidos de archivos de varios
servidores de archivos antiguos en un único servidor de archivos durante una migración
de modernización. Normalmente, la familiaridad del usuario final y la vinculación de
documentos limitan la capacidad de consolidar los recursos compartidos de archivos de
distintos servidores de archivos en un solo host, pero la característica de consolidación
raíz de Espacios de nombres DFS permite establecer un único servidor para varios
nombres de servidor y enrutar al nombre de recurso compartido adecuado.

Si bien resulta útil para diversos escenarios de migración de centros de datos, la

consolidación raíz es especialmente útil para adoptar recursos compartidos de archivos
Azure nativos de nube debido a lo siguiente:

Los recursos compartidos de archivos de Azure no permiten mantener los nombres

de servidores locales existentes.
El acceso a los recursos compartidos de archivos de Azure debe realizarse a través
del nombre de dominio completo (FQDN) de la cuenta de almacenamiento. Por
ejemplo, el acceso a un recurso compartido de archivos de Azure llamado share
en la cuenta de almacenamiento storageaccount siempre se realiza a través de la
ruta de acceso UNC \\storageaccount.file.core.windows.net\share . Esto puede
resultar confuso para los usuarios finales que esperan un nombre corto
( \\MyServer\share , por ejemplo) o un nombre que sea un subdominio del nombre
de dominio de la organización (por ejemplo, \\MyServer.contoso.com\share ).

La consolidación raíz solo se puede usar con los espacios de nombres independientes. Si
ya tiene un espacio de nombres basado en dominio para los recursos compartidos de
archivos, no es necesario crear un espacio de nombres consolidado raíz.

Habilitación de la consolidación raíz

Para habilitar la consolidación raíz, establezca las claves del Registro siguientes desde
una sesión de PowerShell con privilegios elevados (o mediante la comunicación remota
de PowerShell).

PowerShell

New-Item `
-Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs" `
-Type Registry `
-ErrorAction SilentlyContinue
New-Item `
-Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters" `
-Type Registry `
-ErrorAction SilentlyContinue
New-Item `
-Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters\Replicated"
`
-Type Registry `
-ErrorAction SilentlyContinue
Set-ItemProperty `
-Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters\Replicated"
`
 -Name "ServerConsolidationRetry" `
-Value 1

Creación de entradas DNS para los nombres de

servidores de archivos existentes
Para que los espacios de nombres DFS respondan a nombres de servidores de archivos
existentes, cree registros de alias (CNAME) para los servidores de archivos existentes
que apunten al nombre del servidor de Espacios de nombres DFS. El procedimiento
exacto para actualizar los registros DNS puede depender de los servidores que use la
organización y de si en esta se utilizan herramientas personalizadas para automatizar la
administración de DNS. Los pasos siguientes se muestran para el servidor DNS que se
incluye con Windows Server y que Windows AD usa de forma automática.

Portal

En un servidor DNS de Windows, abra la consola de administración de DNS. Para

encontrarla, seleccione el botón Inicio y escriba DNS. Vaya a la zona de búsqueda
directa del dominio. Por ejemplo, si el dominio es contoso.com , la zona de
búsqueda directa puede encontrarse en Zonas de búsqueda directa> contoso.com
en la consola de administración. La jerarquía exacta que se muestre en este cuadro
de diálogo dependerá de la configuración de DNS para la red.

Haga clic con el botón derecho en la zona de búsqueda directa y seleccione Nuevo
alias (CNAME) . En el cuadro de diálogo que aparece, escriba el nombre corto del
servidor de archivos que va a reemplazar (el nombre de dominio completo se
rellenará de forma automática en el cuadro de texto con la etiqueta Nombre de
dominio completo). En el cuadro de texto con la etiqueta Nombre de dominio
completo (FQDN) para el host de destino, escriba el nombre del servidor DFS-N
que ha configurado. Si quiere, puede usar el botón Examinar para ayudarle a
seleccionar el servidor. Seleccione Aceptar a fin de crear el registro CNAME para el
servidor.
Creación de un espacio de nombres
La unidad básica de administración de Espacios de nombres DFS es el espacio de
nombres. La raíz del espacio de nombres, o el nombre, es el punto inicial de este, de
forma que en la ruta de acceso UNC \\contoso.com\Public\ , la raíz de espacio de
nombres es Public .

Si usa los espacios de nombres DFS para asumir un nombre de servidor existente con
consolidación raíz, el nombre del espacio de nombres debe ser el nombre del servidor
que quiere asumir, con el carácter # antepuesto. Por ejemplo, si quiere asumir un
servidor existente llamado MyServer , debe crear un espacio de nombres DFS-N
denominado #MyServer . La sección de PowerShell siguiente se encarga de anteponer # ,
pero si realiza las tareas de creación mediante la consola de Administración de DFS,
deberá anteponer según corresponda.

Portal

Para crear un espacio de nombres, abra la consola de Administración de DFS. Para

encontrarla, seleccione el botón Inicio y escriba Administración de DFS. La consola
de administración que aparece tiene dos secciones: Espacios de nombres y
Replicación, que hacen referencia a los espacios de nombres DFS y a la replicación
DFS (DFS-R), respectivamente. Azure File Sync proporciona un mecanismo moderno
de replicación y sincronización que se puede usar en lugar de DFS-R si también se
quiere replicar.

Seleccione la sección Espacios de nombres y el botón Nuevo espacio de nombres

(también puede hacer clic con el botón derecho en la sección Espacios de
nombres). El Asistente para crear nuevo espacio de nombres que aparece le guiará
a través del proceso de creación de un espacio de nombres.

La primera sección del asistente requiere que elija el servidor de espacio de

nombres DFS para hospedar el espacio de nombres. Varios servidores pueden
hospedar un espacio de nombres, pero tendrá que configurar Espacios de nombres
DFS con un servidor cada vez. Escriba el nombre del servidor de espacio de
nombres DFS que quiera usar y seleccione Siguiente. En la sección Nombre y
configuración de espacio de nombres, escriba el nombre que quiera usar para el
espacio de nombres y seleccione Siguiente.

La sección Tipo de espacio de nombres permite elegir entre un Espacio de

nombres basado en dominio y un Espacio de nombres independiente. Si piensa
usar Espacios de nombres DFS para conservar un nombre de dispositivo NAS o
servidor de archivos existente, debe seleccionar la opción de espacio de nombres
independiente. Para cualquier otro escenario, debe seleccionar un espacio de
nombres basado en dominio. Consulte los tipos de espacio de nombres anteriores
para obtener más información sobre cómo elegir entre ellos.
 Seleccione el tipo de espacio de nombres que quiera usar para el entorno y elija
Siguiente. A continuación, el asistente resumirá el espacio de nombres que se va a
crear. Seleccione Crear para crear el espacio de nombres y Cerrar una vez que se
complete el cuadro de diálogo.

Configuración de carpetas y de destinos de

carpeta
Para que un espacio de nombres sea útil, debe tener carpetas y destinos de carpeta.
Cada carpeta puede tener uno o más destinos de carpeta, que son punteros a los
recursos compartidos de archivos SMB que hospedan ese contenido. Cuando los
usuarios examinan una carpeta con destinos de carpeta, el equipo cliente recibe una
referencia que lo redirige de forma transparente a uno de los destinos de carpeta.
También puede tener carpetas sin destinos de carpeta para agregar la estructura y la
jerarquía al espacio de nombres.

Considere que las carpetas de Espacios de nombres DFS son análogas a los recursos
compartidos de archivos.

Portal
 En la consola de Administración de DFS, seleccione el espacio de nombres que
acaba de crear y elija Nueva carpeta. Aparece el cuadro de diálogo Nueva carpeta,
que le permite crear tanto la carpeta como sus destinos.

Proporcione el nombre de la carpeta en el cuadro de texto con la etiqueta Nombre.

Seleccione Agregar... a fin de agregar destinos de carpeta para esta carpeta. Se
muestra el cuadro de diálogo Agregar destino de carpeta, que proporciona un
cuadro de texto con la etiqueta Ruta de acceso de destino de carpeta, en el que
puede proporcionar la ruta de acceso UNC a la carpeta que quiera. Seleccione
Aceptar en el cuadro de diálogo Agregar destino de carpeta. Si está agregando
una ruta de acceso UNC a un recurso compartido de archivos de Azure, es posible
que reciba un mensaje que indica que no se puede contactar con el servidor
storageaccount.file.core.windows.net . Este es el comportamiento esperado;

seleccione Sí para continuar. Por último, seleccione Aceptar en el cuadro de diálogo

Nueva carpeta para crear la carpeta y los destinos de carpeta.

Ahora que ha creado un espacio de nombres, una carpeta y un destino de carpeta, debe
poder montar el recurso compartido de archivos en los espacios de nombres DFS. Si usa
un espacio de nombres basado en dominio, la ruta de acceso completa del recurso
compartido debe ser \\<domain-name>\<namespace>\<share> . Si usa un espacio de
nombres independiente, la ruta de acceso completa del recurso compartido debe ser \\
<DFS-server>\<namespace>\<share> . Si usa un espacio de nombres independiente con
consolidación raíz, puede acceder directamente a través del nombre del servidor
anterior, como \\<old-server>\<share> .

Enumeración basada en el acceso (ABE)

El uso de ABE para controlar la visibilidad de los archivos y carpetas en los recursos
compartidos de archivos de SMB de Azure no se admite actualmente. ABE es una
característica de DFS-N, por lo que es posible configurar la autenticación basada en
identidades y habilitar la característica ABE. Sin embargo, esto solo se aplica a los
destinos de carpetas DFS-N; no se aplica retroactivamente a los propios recursos
compartidos de archivos de destino. Esto se debe a que DFS-N funciona por referencia,
en lugar de como un proxy delante del destino de carpetas.

Por ejemplo, si el usuario escribe la ruta de acceso \\mydfsnserver\share , el cliente SMB

obtiene la referencia de \\mydfsnserver\share => \\server123\share y realiza el montaje
en este último.

Por este motivo, ABE solo funcionará en los casos en los que el servidor DFS-N hospede
la lista de nombres de usuario antes del redireccionamiento:

\\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\contosouser1

\\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\users\contosouser1

(Donde contosouser1 es una subcarpeta del recurso compartido users)

Si cada usuario es una subcarpeta después del redireccionamiento, ABE no funcionará:

\\DFSServer\SomePath\users --> \\SA.file.core.windows.net\users

Consulte también
Implementación de un recurso compartido de archivos de Azure: Planeamiento de
una implementación de Azure Files y Creación de un recurso compartido de
archivos de Azure.
Configuración del acceso a recursos compartidos de archivos: documentos sobre
autenticación basada en la identidad y consideraciones de red para el acceso
directo.
Espacios de nombres del Sistema de archivos distribuido de Windows Server
Creación de una FCI con un recurso
compartido de archivos Premium (SQL
Server en VM de Azure)
Artículo • 02/10/2023

Se aplica a: SQL Server en VM de Azure

 Sugerencia

Hay muchos métodos para implementar un grupo de disponibilidad. Simplifique

la implementación y elimine la necesidad de un nombre de red distribuida (DNN) o
un equilibrador de carga de Azure para el grupo de disponibilidad Always On
mediante la creación de las máquinas virtuales (VM) de SQL Server en varias
subredes dentro de la misma red virtual de Azure. Si ya ha creado el grupo de
disponibilidad en una sola subred, puede migrarlo a un entorno de varias
subredes.

En este artículo se explica cómo crear una instancia de clúster de conmutación por error
(FCI) con SQL Server en Azure Virtual Machines (VM) con un recurso compartido de
archivos Premium.

Los recursos compartidos de archivos Premium son recursos compartidos de archivos

de baja latencia constante con respaldo de SSD que son totalmente compatibles para su
uso con la instancia del clúster de conmutación por error en SQL Server 2012 y
versiones posteriores en Windows Server 2012 y versiones posteriores. Los recursos
compartidos de archivos Premium ofrecen mayor flexibilidad, lo que le permite cambiar
el tamaño y escalar el recurso compartido de archivos sin tiempo de inactividad.

Para obtener más información, consulte información general de FCI con SQL Server en
VM de Azure y procedimientos recomendados del clúster.

７ Nota

Ahora es posible migrar mediante lift and shift la solución de instancia de clúster
de conmutación por error a SQL Server en máquinas virtuales de Azure mediante
Azure Migrate. Consulte Migración de una instancia de clúster de conmutación
por error para más información.
Requisitos previos
Antes de completar las instrucciones de este artículo, ya debe tener:

Suscripción a Azure.
Una cuenta que tenga permisos para crear objetos en máquinas virtuales de Azure
y en Active Directory.
Dos o más máquinas virtuales de Azure para una FCI en un conjunto de
disponibilidad o en zonas de disponibilidad diferentes.
Un recurso compartido de archivos premium que se usará como unidad en clúster,
en función de la cuota de almacenamiento de la base de datos de los archivos de
datos.
La versión más reciente de PowerShell.

Montaje del recurso compartido de archivos

Premium
Para montar el recurso compartido de archivos Premium, realice estos pasos:

1. Inicie sesión en Azure Portal y vaya a la cuenta de almacenamiento.

2. Vaya a Recursos compartidos de archivos en Almacenamiento de datos y, luego,

seleccione el recurso compartido de archivos prémium que quiere usar para el
almacenamiento SQL.

3. Seleccione Conectar para mostrar la cadena de conexión del recurso compartido

de archivos.

4. En la lista desplegable, seleccione la letra de unidad que quiere usar, elija Clave de
cuenta de almacenamiento como método de autenticación y, luego, copie el
bloque de código en un editor de texto, como el Bloc de notas.
 5. Aplique el protocolo de escritorio remoto (RDP) para conectarse a la VM con
SQL Server con la cuenta que la FCI de SQL Server usará para la cuenta de
servicio.

6. Abra una consola de comandos de PowerShell de administración.

7. Ejecute el comando que copió anteriormente en el editor de texto desde el portal

de recursos compartidos de archivos.

8. Vaya al recurso compartido mediante el Explorador de archivos o el cuadro de

diálogo Ejecutar (Windows + R en el teclado). Use la ruta de acceso a la red
\\storageaccountname.file.core.windows.net\filesharename . Por ejemplo:

\\sqlvmstorageaccount.file.core.windows.net\sqlpremiumfileshare

9. Cree al menos una carpeta en el recurso compartido de archivos recién conectado

para colocar los archivos de datos de SQL.

10. Repita estos pasos en cada VM con SQL Server que participará en el clúster.

） Importante
 Considere la posibilidad de usar un recurso compartido de archivos independiente
para los archivos de copia de seguridad a fin de ahorrar la capacidad de
operaciones de entrada/salida por segundo (IOPS) y espacio de este recurso
compartido para usarla para el archivo de registro y de datos. Puede usar un
recurso compartido de archivos Premium o Estándar para los archivos de copia de
seguridad.

Creación de un clúster de conmutación por

error de Windows
Los pasos necesarios para crear un clúster de conmutación por error de Windows Server
varían en función de si se han implementado las máquinas virtuales con SQL Server en
una sola subred o en varias. Para crear el clúster, siga los pasos del tutorial de un
escenario de varias subredes o un escenario de una sola subred. Aunque estos tutoriales
son para crear un grupo de disponibilidad, los pasos para crear el clúster son los
mismos.

Configuración de un cuórum
El testigo en la nube es la solución de cuórum recomendada para este tipo de
configuración de clúster con SQL Server en máquinas virtuales de Azure.

Si tiene un número par de votos en el clúster, configure la solución de cuórum que

mejor se adapte a sus necesidades empresariales. Para más información, consulte
Cuórum con VM SQL Server.

Validar el clúster
Valide el clúster en una de las máquinas virtuales mediante la interfaz de usuario del
administrador de clústeres de conmutación por error o PowerShell.

Para validar el clúster con la interfaz de usuario, realice los pasos siguientes en una de
las máquinas virtuales:

1. En Administrador del servidor, seleccione Herramientas y, después, seleccione

Administrador de clústeres de conmutación por error.

2. En Administrador de clústeres de conmutación por error, seleccione Accióny, a

continuación, seleccione Validar configuración.
 3. Seleccione Next (Siguiente).

4. En Seleccionar servidores o un clúster, escriba el nombre de ambas máquinas

virtuales.

5. En Opciones de pruebas, seleccione Ejecutar solo las pruebas que seleccione.

6. Seleccione Next (Siguiente).

7. En Selección de pruebas, seleccione todas las pruebas excepto Almacenamiento y

Espacios de almacenamiento directo como se muestra aquí:

8. Seleccione Siguiente.

9. En Confirmación, seleccione Siguiente. El Asistente para validar una configuración

ejecuta las pruebas de validación.

Para validar el clúster con PowerShell, ejecute el siguiente script en una sesión de
PowerShell de administrador de una de las máquinas virtuales:

PowerShell

Test-Cluster –Node ("<node1>","<node2>") –Include "Inventory", "Network",

"System Configuration"

Conmutación por error del clúster de prueba

Pruebe la conmutación por error del clúster. En Administrador de clústeres de
conmutación por error, haga clic con el botón derecho en el clúster y seleccione Más
acciones>Mover principales recursos de clúster>Seleccionar nodo y, después,
seleccione el otro nodo del clúster. Mueva el recurso de clúster principal a cada nodo
del clúster y, después, devuélvalo al nodo principal. Si puede mover correctamente el
clúster a cada nodo, está listo para instalar SQL Server.

Crear la FCI de SQL Server

Después de haber configurado el clúster de conmutación por error, puede crear la FCI
de SQL Server.

1. Conéctese a la primera máquina virtual con RDP.

2. En Administrador de clústeres de conmutación por error, asegúrese de que todos

los recursos principales de clúster estén en la primera máquina virtual. Si es
necesario, mueva todos los recursos a esta máquina virtual.

3. Si la versión del sistema operativo es Windows Server 2019 y el clúster de

Windows se creó con el nombre de red distribuida (DNN) predeterminado, se
produce un error en la instalación de instancia de clúster de conmutación por error
para SQL Server 2017 y versiones anteriores con el error The given key was not
present in the dictionary .

Durante la instalación, el programa de instalación de SQL Server consulta el

nombre de red virtual (VNN) existente y no reconoce el DNN del clúster de
Windows. El problema se ha corregido en el programa de configuración de SQL
 Server 2019. En SQL Server 2017 y versiones anteriores, siga estos pasos para
evitar el error de instalación:

En el Administrador de clústeres de conmutación por error, conéctese al

clúster, haga clic con el botón derecho en Roles y seleccione Crear rol vacío.
Haga clic con el botón derecho en el rol vacío recién creado, seleccione
Agregar recurso y seleccione Punto de acceso cliente.
Escriba cualquier nombre y complete el asistente para crear el punto de
acceso cliente.
Una vez completada la instalación de instancia de clúster de conmutación por
error de SQL Server, se puede eliminar el rol que contiene el punto de acceso
cliente temporal.

4. Localice los medios de instalación. Si la máquina virtual usa una de las imágenes
de Azure Marketplace, los medios se encuentran en C:\SQLServer_<version
number>_Full .

5. Seleccione Setup (Configuración).

6. En el Centro de instalación de SQL Server, seleccione Instalación.

7. Seleccione Nueva instalación de clúster de conmutación por error de SQL Server

y, a continuación, siga las instrucciones del asistente para instalar la FCI de SQL
Server.

8. En la página Configuración de red de clúster, la IP que proporcione varía en

función de si las máquinas virtuales con SQL Server se implementaron en una sola
subred o en varias.
a. En el caso de un entorno de una sola subred, especifique la dirección IP que
planea agregar a Azure Load Balancer
b. En el caso de un entorno de varias subredes, especifique la dirección IP
secundaria en la subred de la primera máquina virtual con SQL Server que
designó anteriormente como la dirección IP del nombre de red de la instancia
de clúster de conmutación por error:
9. En Configuración del motor de base de datos, los directorios de datos deben
estar en el recurso compartido de archivos Premium. Escriba la ruta de acceso
completa del recurso compartido,con este formato:
\\storageaccountname.file.core.windows.net\filesharename\foldername . Aparece

una advertencia que le notifica que ha especificado un servidor de archivos como

directorio de datos. Se espera esta advertencia. Para evitar posibles errores,
asegúrese de que la cuenta de usuario que usó para tener acceso a la máquina
virtual mediante RDP cuando conservó el recurso compartido de archivos sea la
misma que usa el servicio SQL Server.
10. Después de completar los pasos del asistente, el programa de instalación instalará
una FCI de SQL Server en el primer nodo.

11. Tras completar correctamente la instalación de instancia de clúster de conmutación

por error en el primer nodo, conéctese al segundo nodo mediante RDP.

12. Abra el Centro de instalación de SQL Server y, a continuación, seleccione

Instalación.

13. Seleccione Agregar nodo a clúster de conmutación por error de SQL Server. Siga
las instrucciones del asistente para instalar SQL Server y agregar el nodo a la
instancia de clúster de conmutación por error.

14. En el caso de un escenario de varias subredes, en Configuración de red en clúster,

especifique la dirección IP secundaria en la subred de la segunda máquina virtual
con SQL Server que designó anteriormente como la dirección IP del nombre de
red de la instancia de clúster de conmutación por error
 Después de seleccionar Siguiente en Configuración de red de clúster, el programa
de instalación muestra un cuadro de diálogo que indica que el programa de
instalación de SQL Server ha detectado varias subredes como en la imagen de
ejemplo. Seleccione Sí para confirmar la acción.

15. Después de completar las instrucciones del asistente, el programa de instalación

agrega el segundo nodo FCI de SQL Server.

16. Repita estos pasos en cualquier otro nodo que desee agregar a la instancia de
clúster de conmutación por error de SQL Server.

７ Nota

Las imágenes de la galería de Azure Marketplace vienen con SQL Server

Management Studio instalado. Si no ha usado una imagen de Marketplace,
 descargue SQL Server Management Studio (SSMS).

Registro con una extensión Agente de IaaS de

SQL
Para administrar la VM con SQL Server desde el portal, regístrela con la extensión de
agente de IaaS de SQL. Solo la funcionalidad limitada está disponible en máquinas
virtuales SQL que tienen instancias de clúster de conmutación por error de SQL Server
(FCI).

Si la VM con SQL Server ya se registró con la extensión Agente de IaaS de SQL y se

habilitaron características que requieren el agente, deberá anular el registro de la VM
con SQL Server desde la extensión y registrarla de nuevo después de instalar la FCI.

Registre una VM con SQL Server con PowerShell ((-LicenseType puede ser PAYG o AHUB ):

PowerShell

# Get the existing compute VM

$vm = Get-AzVM -Name <vm_name> -ResourceGroupName <resource_group_name>

# Register SQL VM with SQL IaaS Agent extension

New-AzSqlVM -Name $vm.Name -ResourceGroupName $vm.ResourceGroupName -
Location $vm.Location `
-LicenseType <license_type>

Configuración de la conectividad
Si implementó las máquinas virtuales de SQL Server en varias subredes, omita este paso.
Si implementó las máquinas virtuales de SQL Server en una sola subred, debe configurar
un componente adicional para enrutar el tráfico a la instancia de clúster de conmutación
por error. Puede configurar un nombre de red virtual (VNN) con Azure Load Balancer o
un nombre de red distribuida para una instancia de clúster de conmutación por error.
Revise las diferencias entre los dos y, luego, implemente un nombre de red distribuida o
un nombre de red virtual y Azure Load Balancer para la instancia de clúster de
conmutación por error.

Limitaciones
No se admite el Coordinador de transacciones distribuidas de Microsoft (MSDTC)
en Windows Server 2016 y versiones anteriores.
 FILESTREAM no se admite en los clústeres de conmutación por error con un
recurso compartido de archivos Premium. Para usar la secuencia de archivos,
implemente el clúster con Espacios de almacenamiento directo o discos
compartidos de Azure en su lugar.
Las FCI de SQL Server registradas con la extensión no admiten características que
requieran el agente, como la copia de seguridad automatizada, la aplicación de
revisiones y la administración avanzada del portal. Consulte la tabla de ventajas.
Las instantáneas de base de datos no se admiten actualmente en Azure Files
debido a las limitaciones de archivos dispersos.
Puesto que no se admiten instantáneas de base de datos, CHECKDB para bases de
datos de usuario vuelve a CHECKDB WITH TABLOCK. TABLOCK limita las
comprobaciones que se llevan a cabo; DBCC CHECKCATALOG no se ejecuta en la
base de datos y los datos de Service Broker no se validan.
No se admite DBCC CHECKDB en la base de datos master y msdb .
Las bases de datos que usan la característica OLTP en memoria no se admiten en
una instancia de clúster de conmutación por error implementada con un recurso
compartido de archivos prémium. Si su empresa requiere OLTP en memoria,
considere la posibilidad de implementar la instancia de clúster de conmutación por
error con discos compartidos de Azure o Espacios de almacenamiento directo.

Compatibilidad de extensión limitada

En este momento, las instancias de clúster de conmutación por error de SQL Server en
máquinas virtuales de Azure registradas con la extensión Agente de IaaS de SQL solo
admiten un número limitado de características. Consulte la tabla de ventajas.

Si la VM con SQL Server ya se registró con la extensión Agente de IaaS de SQL y se

habilitaron características que requieren el agente, debe anular el registro desde la
extensión; para ello, elimine el recurso de máquina virtual con SQL para las VM
correspondientes y, luego, vuelva a registrarlas con la extensión Agente de IaaS de SQL.
Cuando elimine el recurso Máquina virtual con SQL desde Azure Portal, desactive la
casilla de la máquina virtual correcta para evitar la eliminación de la máquina virtual.

Contenido relacionado
Creación de una FCI con discos compartidos de Azure (SQL Server en VM de
Azure)
Creación de una FCI con Espacios de almacenamiento directo (SQL Server en Azure
VM)
Clúster de conmutación por error de Windows Server con SQL Server en VM de
Azure
Instancias de clúster de conmutación por error con SQL Server en Azure Virtual
Machines
Información general de las instancias de clúster de conmutación por error
Procedimientos recomendados para la configuración de HADR (SQL Server en
Azure Virtual Machines)
Optimización de costos para Azure Files
con las reservas
Artículo • 01/06/2023

Puede ahorrar en los costos de almacenamiento de los recursos compartidos de

archivos de Azure con las reservas de Azure Files. Las reservas de Azure Files (que
también se denominan instancias reservadas) ofrece un descuento por capacidad para
los costos de almacenamiento cuando se establece un compromiso anual o trienal al
realizar la reserva. Las reservas proporcionan una cantidad fija de capacidad de
almacenamiento durante el plazo comprometido.

Las reservas de Azure Files pueden reducir considerablemente los costos de capacidad
por almacenar datos en los recursos compartidos de archivos de Azure. La cantidad que
ahorre dependerá de la duración de la reserva, de la capacidad total que elija reservar y
de la configuración de nivel y redundancia que haya elegido para los recursos
compartidos de archivos de Azure. Las reservas permiten un descuento en la facturación
y no afectan al estado de los recursos compartidos de Azure.

Para obtener información acerca de los precios de las reservas de Azure Files, consulte
Precios de Azure Files .

Se aplica a
Tipo de recurso compartido de archivos SMB NFS

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS

Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Términos de la reserva de Azure Files

En las secciones siguientes se describen los términos de una reserva de Azure Files.

Unidades y términos de las reservas

Las reservas de Azure Files se pueden comprar en unidades de 10 TiB y 100 TiB al mes
durante un período de uno o tres años.
Ámbito de la reserva
Las reservas de Azure Files están disponibles en una sola suscripción, varias
suscripciones (ámbito compartido) y grupos de administración. Cuando el ámbito es
una suscripción única, el descuento de la reserva se aplica únicamente a la suscripción
seleccionada. Cuando el ámbito es varias suscripciones, el descuento de la reserva se
comparte entre esas suscripciones, dentro del contexto de facturación del cliente.
Cuando el ámbito es un grupo de administración, el descuento por reserva se aplica a
las suscripciones que forman parte del grupo de administración y del ámbito de
facturación. Las reservas se aplican al uso dentro del ámbito adquirido y no se pueden
limitar a una cuenta de almacenamiento, un contenedor o un objeto concretos de la
suscripción.

Una reserva de Azure Files solo cubre la cantidad de datos que se almacenan en una
suscripción o un grupo de recursos compartidos. Los cargos por transacción, ancho de
banda, transferencia de datos y almacenamiento de metadatos no se incluyen en la
reserva. En cuanto se compra una reserva, los cargos de capacidad que coincidan con
los atributos de la reserva se cobran según las tarifas de descuento, en lugar de las
tarifas de pago por uso. Para más información, consulte ¿Qué son las reservas de
Azure?.

Reservas e instantáneas
Si va a tomar instantáneas de recursos compartidos de archivos de Azure, hay
diferencias en el funcionamiento de las reservas de recursos compartidos de archivos
estándar con respecto a los Prémium. Si va a tomar instantáneas de recursos
compartidos estándar, las diferenciales de instantáneas se cuentan para la reserva y se
facturan como parte del medidor de almacenamiento usado normal. Sin embargo, si va
a tomar instantáneas de recursos compartidos de archivos Premium, se usa un medidor
independiente para facturar las instantáneas y estas no cuentan para la reserva. Para
más información, consulte Instantánea.

Niveles admitidos y opciones de redundancia

Las reservadas de Azure Files están disponibles para los recursos compartidos de
archivos Prémium, de acceso frecuente y de acceso esporádico. Las reservas no están
disponibles para los recursos compartidos de archivos de Azure en el nivel de
transacción optimizada. Todas las redundancias de almacenamiento admiten reservas.
Para más información sobre las opciones de redundancia, consulte Redundancia de
Azure Files.
Requisitos de seguridad para la compra
Para comprar una reserva:

Debe tener el rol Propietario al menos en una suscripción Enterprise o individual

con tarifas de pago por uso.
En el caso de las suscripciones Enterprise, la opción Agregar instancias reservadas
debe estar habilitada en el portal de EA. O bien, si esa opción está deshabilitada,
debe ser un administrador de EA en la suscripción.
En el caso del programa del Proveedor de soluciones en la nube (CSP), solo los
agentes de administración o de ventas pueden comprar reservas de Azure Files.

Determinación de la capacidad necesaria antes

de la compra
Cuando compra una reserva de Azure Files, debe elegir las opciones de región, nivel y
redundancia de la misma. La reserva solo es válida para los datos almacenados en esa
región, nivel y nivel de redundancia. Por ejemplo, supongamos que adquiere una
reserva de datos en la región Oeste de EE. UU. para el nivel de acceso frecuente
mediante el almacenamiento con redundancia de zona (ZRS). Esa reserva no se aplicará
a los datos en la región Este de EE. UU., a los datos del nivel de acceso esporádico ni a
los datos de almacenamiento con redundancia geográfica (GRS). Sin embargo, puede
adquirir otra reserva que cubra sus necesidades adicionales.

Las reservas están disponibles para bloques de 10 TiB o 100 TiB, con descuentos más
altos para los bloques de 100 TiB. Al adquirir una reserva en Azure Portal, Microsoft
puede realizarle recomendaciones basadas en el uso anterior para ayudarle a
determinar qué reserva debe comprar.

Compra de reservas de Azure Files

Las reservas de Azure Files se pueden realizar desde Azure Portal . Pague la reserva por
adelantado o de forma mensual. Para más información sobre los pagos mensuales,
consulte Compra de reservas de Azure con pagos por adelantado o mensuales.

Para ayudarle a identificar los términos de reserva adecuados para su escenario,

consulte el artículo sobre la aplicación de descuentos en las reservas de Azure Storage.

Para comprar una reserva siga estos pasos:

1. Vaya a la hoja Comprar reservas en Azure Portal.

2. Seleccione Azure Files para comprar una nueva reserva.

3. Rellene los campos obligatorios tal como se describe en la tabla siguiente:

Campo Descripción

Ámbito Indica el número de suscripciones que pueden usar la ventaja de

facturación asociada con la reserva. También controla cómo se aplica la
reserva a suscripciones concretas.

Si selecciona Compartido, el descuento de la reserva se aplica a la

capacidad de Azure Files en cualquier suscripción que se encuentre en el
contexto de facturación. El contexto de facturación se basa en cómo se
haya suscrito a Azure. Para los clientes Enterprise, el ámbito compartido es
la inscripción e incluye todas las suscripciones que esta contiene. Para los
clientes de pago por uso, el ámbito compartido incluye todas las
suscripciones con tarifas de pago por uso creadas por el administrador de
la cuenta.

Si selecciona Suscripción única, el descuento de la reserva se aplica a la

capacidad de Azure Files de la suscripción seleccionada.

Si selecciona Grupo de recursos único, el descuento de la reserva se aplica

a la capacidad de Azure Files de la suscripción seleccionada y al grupo de
recursos seleccionado que hay dentro de esa suscripción.

El ámbito de la reserva se puede cambiar después de haberla adquirido.

Suscripción La suscripción que se usa para pagar la reserva de Azure Files. El método de
pago en la suscripción seleccionada se usa al cargar los costos. La
suscripción debe ser uno de los tipos siguientes:

Contrato Enterprise (números de oferta: MS-AZR-0017P o MS-AZR-0148P):

En el caso de una suscripción Enterprise, los cargos se deducirán del saldo
de pago por adelantado de la inscripción de Azure (anteriormente llamado
compromiso monetario) o se cobrarán como parte del uso por encima del
límite.

Suscripción individual con tarifas de pago por uso (números de la oferta:

MS-AZR-0003P o MS-AZR-0023P): en una suscripción individual con tarifas
de pago por uso, los cargos se cobran en el método de pago de tarjeta de
crédito o factura de la suscripción.
 Campo Descripción

Región La región en la que está en vigor la reserva.

Nivel El nivel en el que está en vigor la reserva. Entre las opciones se incluyen
Premium, Frecuente e Inactivo.

Redundancia La opción de redundancia de la reserva. Entre las opciones se incluyen LRS,

ZRS, GRS y GZRS. Para más información sobre las opciones de redundancia,
consulte Redundancia de Azure Files.

Frecuencia Indica la frecuencia con que se factura la cuenta para la reserva. Entre las
de opciones se incluyen Mensual o Por adelantado.
facturación

Tamaño Cantidad de capacidad que se va a reservar.

Término Un año o tres años.

4. Después de seleccionar los parámetros de la reserva, Azure Portal muestra el costo.

El portal también muestra el porcentaje de descuento en la facturación de pago
por uso.

5. En la hoja Compra de reservas, revise el costo total de la reserva. También puede

especificar un nombre para la reserva.

Después de comprar una reserva, esta se aplica automáticamente a todos los recursos
compartido de archivos de Azure que coincidan con los términos de la reserva. Si aún
no ha creado ningún recurso compartido de archivos de Azure, la reserva se aplicará
siempre que se cree un recurso que coincida con sus términos. En cualquier caso, el
período de la reserva comienza inmediatamente después de una compra correcta.

Intercambio o reembolso de una reserva

Las reservas se pueden cambiar o reembolsar, pero con ciertas limitaciones. que se
describen en las secciones siguientes.

Para cambiar o reembolsar una reserva, vaya a los detalles de la reserva en Azure Portal.
Seleccione Intercambiar o Reembolsar y siga las instrucciones para enviar una solicitud
de soporte técnico. Una vez procesada la solicitud, Microsoft le enviará un correo
electrónico para confirmar que se completó la solicitud.

Para más información sobre las directivas de reservas de Azure, consulte Autoservicio de
cambios y reembolsos de reservas de Azure.
Cambio de una reserva
El cambio de una reserva permite recibir un reembolso en el que se prorratea la parte
no utilizada de la reserva. Después, puede aplicar este reembolso al precio de compra
de una nueva reserva de Azure Files.

No hay límite en el número de intercambios que puede hacer. Además, los intercambios
no conllevan ninguna tarifa. El valor de la reserva nueva que compre debe ser igual o
mayor que el crédito prorrateado de la reserva original. Una reserva de Azure Files se
puede intercambiar solo para otra reserva de Azure Files y no para una reserva de
ningún otro servicio de Azure.

Reembolso de una reserva

Las reservas de Azure Files se pueden cancelar en cualquier momento. Si lo hace,
recibirá un reembolso prorrateado según el período restante de la reserva, menos una
cuota de un 12 % por finalización anticipada. El reembolso máximo por año es de
USD 50 000.

Al cancelar una reserva, esta finaliza inmediatamente y se devuelven los meses restantes
a Microsoft. El saldo prorrateado restante, menos la cuota, se reembolsará en la forma
de compra original.

Expiración de una reserva

Cuando una reserva expira, cualquier capacidad de Azure Files que use en ella se factura
según la tarifa de pago por uso. Las reservas no se renuevan automáticamente.

Recibirá una notificación por correo electrónico 30 días antes de la expiración de la

reserva y otra en la fecha de expiración. Para seguir aprovechando el ahorro de costos
que proporciona una reserva, debe renovarla a más tardar en la fecha de expiración.

¿Necesita ayuda? Ponerse en contacto con

nosotros
Si tiene alguna pregunta o necesita ayuda, cree una solicitud de soporte técnico .

Pasos siguientes
¿Qué es Azure Reservations?
Aplicación del descuento por reserva a Azure Storage
Administración del almacenamiento en
las nubes independientes mediante
PowerShell
Artículo • 11/05/2023

La mayoría de los usuarios utiliza la nube pública de Azure para una implementación
global. También hay algunas implementaciones independientes de Microsoft Azure por
motivos de soberanía, etc. Estas implementaciones independientes se conocen como
"entornos". La siguiente lista detalla las nubes independientes disponibles actualmente.

Azure Government Cloud (Nube de Azure Government)

Nube Azure China 21Vianet controlada por 21Vianet en China
Nube de Azure German

７ Nota

Se recomienda usar el módulo Azure Az de PowerShell para interactuar con Azure.

Consulte Instalación de Azure PowerShell para empezar. Para más información
sobre cómo migrar al módulo Az de PowerShell, consulte Migración de Azure
PowerShell de AzureRM a Az.

Uso de una nube independiente

Para usar Azure Storage en una de las nubes independientes, conéctese a ella, en lugar
de a la nube pública de Azure. Para usar una de las nubes independientes en lugar de la
nube pública de Azure:

Especifique el entorno al que se va a conectar.

Puede determinar y usar las regiones disponibles.
Utilice el sufijo de punto de conexión correcto, que es diferente en el caso de la
nube pública de Azure.

Los ejemplos requieren la versión 0.7 o posterior del módulo Az de Azure PowerShell. En
una ventana de PowerShell, ejecute Get-Module -ListAvailable Az para buscar la
versión. Si no aparece ninguna o necesita una actualización, consulte Instalación del
módulo de Azure PowerShell.
Inicio de sesión en Azure
Ejecute el cmdlet Get-AzEnvironment para ver los entornos de Azure disponibles:

PowerShell

Get-AzEnvironment

Inicie sesión en la cuenta que tenga acceso a la nube a la que desea conectarse y
establezca el entorno. Este ejemplo le muestra cómo iniciar sesión en una cuenta que
utiliza la nube de administración pública de Azure.

PowerShell

Connect-AzAccount –Environment AzureUSGovernment

Para acceder a la nube de China, use el entorno AzureChinaCloud. Para acceder a la

nube de Alemania, use AzureGermanCloud.

En este momento, si necesita la lista de ubicaciones para crear una cuenta de

almacenamiento o algún otro recurso, puede consultar las ubicaciones disponibles de la
nube seleccionada mediante Get-AzLocation.

PowerShell

Get-AzLocation | select Location, DisplayName

La siguiente tabla muestra las ubicaciones devueltas para la nube de Alemania.

Location Display Name (Nombre para mostrar)

germanycentral Centro de Alemania

germanynortheast Nordeste de Alemania

Sufijo de punto de conexión

El sufijo de punto de conexión para cada uno de estos entornos es diferente del punto
de conexión de la nube pública de Azure. Por ejemplo, el sufijo de punto de conexión de
blobs para la nube pública de Azure es blob.core.windows.net. Para la nube de
administración pública, el sufijo de punto de conexión de blobs es
blob.core.usgovcloudapi.net.
Obtención del punto de conexión mediante Get-
AzEnvironment
Puede recuperar el sufijo del punto de conexión mediante Get-AzEnvironment. El punto
de conexión es la propiedad StorageEndpointSuffix del entorno.

En los fragmentos de código siguientes se muestra cómo recuperar el sufijo del punto
de conexión. Todos estos comandos devuelven algo parecido a "core.cloudapp.net" o
"core.cloudapi.de", etc. Adjunte este sufijo al servicio de almacenamiento para acceder a
ese servicio. Por ejemplo, "queue.core.cloudapi.de" accederá al servicio de cola en la
nube de Alemania.

Este fragmento de código recupera todos los entornos y el sufijo de punto de conexión
para cada uno de ellos.

PowerShell

Get-AzEnvironment | select Name, StorageEndpointSuffix

Este comando devuelve los siguientes resultados.

Nombre StorageEndpointSuffix

AzureChinaCloud core.chinacloudapi.cn

AzureCloud core.windows.net

AzureGermanCloud core.cloudapi.de

AzureUSGovernment core.usgovcloudapi.net

Para recuperar todas las propiedades del entorno especificado, llame a Get-
AzEnvironment y especifique el nombre de la nube. Este fragmento de código devuelve
una lista de propiedades. Busque StorageEndpointSuffix en la lista. El ejemplo siguiente
es para la nube de Alemania.

PowerShell

Get-AzEnvironment -Name AzureGermanCloud

Los resultados son similares a los valores siguientes:

Nombre de la propiedad Value

Nombre AzureGermanCloud
 Nombre de la propiedad Value

EnableAdfsAuthentication False

ActiveDirectoryServiceEndpointResourceI http://management.core.cloudapi.de/

GalleryURL https://gallery.cloudapi.de/

ManagementPortalUrl https://portal.microsoftazure.de/

ServiceManagementUrl https://manage.core.cloudapi.de/

PublishSettingsFileUrl https://manage.microsoftazure.de/publishsettings/index

ResourceManagerUrl http://management.microsoftazure.de/

SqlDatabaseDnsSuffix .database.cloudapi.de

StorageEndpointSuffix core.cloudapi.de

... ...

Para recuperar solo la propiedad del sufijo de punto de conexión de almacenamiento,

recupere la nube específica y pida solo esa propiedad.

PowerShell

$environment = Get-AzEnvironment -Name AzureGermanCloud

Write-Host "Storage EndPoint Suffix = " $environment.StorageEndpointSuffix

Este comando devuelve la siguiente información:

Storage Endpoint Suffix = core.cloudapi.de

Obtención del punto de conexión desde una cuenta de

almacenamiento
También puede examinar las propiedades de una cuenta de almacenamiento para
recuperar los puntos de conexión:

PowerShell

# Get a reference to the storage account.

$resourceGroup = "myexistingresourcegroup"
$storageAccountName = "myexistingstorageaccount"
$storageAccount = Get-AzStorageAccount `
-ResourceGroupName $resourceGroup `
-Name $storageAccountName
 # Output the endpoints.
Write-Host "blob endpoint = " $storageAccount.PrimaryEndPoints.Blob
Write-Host "file endpoint = " $storageAccount.PrimaryEndPoints.File
Write-Host "queue endpoint = " $storageAccount.PrimaryEndPoints.Queue
Write-Host "table endpoint = " $storageAccount.PrimaryEndPoints.Table

En el caso de una cuenta de almacenamiento en la nube de administración pública, este

comando devolverá la siguiente salida:

blob endpoint = http://myexistingstorageaccount.blob.core.usgovcloudapi.net/

file endpoint = http://myexistingstorageaccount.file.core.usgovcloudapi.net/
queue endpoint =
http://myexistingstorageaccount.queue.core.usgovcloudapi.net/
table endpoint =
http://myexistingstorageaccount.table.core.usgovcloudapi.net/

Después de configurar el entorno

Ahora puede usar PowerShell para administrar las cuentas de almacenamiento y acceder
a los datos de blobs, colas, archivos y tablas. Para más información, consulte Az.Storage.

Limpieza de recursos
Si ha creado un nuevo grupo de recursos y una cuenta de almacenamiento para este
ejercicio, puede quitar ambos recursos eliminando el grupo de recursos. Al eliminar un
grupo de recursos se eliminan todos los recursos contenidos en él.

PowerShell

Remove-AzResourceGroup -Name $resourceGroup

Pasos siguientes
Conservación de inicios de sesión de usuario entre sesiones de PowerShell
Almacenamiento de Azure Government
Guía para desarrolladores de Microsoft Azure Government
Notas para desarrolladores para las aplicaciones de Azure China 21Vianet
Documentación sobre Azure Alemania
Montaje de un recurso compartido de
archivos de Azure de SMB en Windows
Artículo • 03/09/2023

Azure Files es el sencillo sistema de archivos en la nube de Microsoft. Los recursos

compartidos de archivos de Azure se pueden usar sin problemas en Windows y
Windows Server. En este artículo se describen los aspectos que se deben tener en
cuenta al usar un recurso compartido de archivos de Azure con Windows y Windows
Server.

Para usar un recurso compartido de archivos de Azure por medio del punto de conexión
público fuera de la región de Azure en la que se hospeda, bien sea en el entorno local o
en otra región de Azure, el sistema operativo debe admitir SMB 3.x. Las versiones
anteriores de Windows que solo admiten SMB 2.1 no pueden montar recursos
compartidos de archivos de Azure por medio del punto de conexión público.

Versión de Windows Versión de SMB multicanal de Azure Files Cifrado máximo

SMB del canal SMB

Windows 11, versión SMB 3.1.1 Sí AES-256-GCM

22H2

Windows 10, versión SMB 3.1.1 Sí AES-128-GCM

22H2

Windows Server 2022 SMB 3.1.1 Sí AES-256-GCM

Windows 11, versión SMB 3.1.1 Sí AES-256-GCM

21H2

Windows 10, SMB 3.1.1 Sí AES-128-GCM

versión 21H2

Windows 10, SMB 3.1.1 Sí, con KB5003690 o posterior AES-128-GCM

versión 21H1

Windows Server, versión SMB 3.1.1 Sí, con KB5003690 o posterior AES-128-GCM
20H2

Windows 10, versión SMB 3.1.1 Sí, con KB5003690 o posterior AES-128-GCM
20H2

Windows Server, SMB 3.1.1 Sí, con KB5003690 o posterior AES-128-GCM

versión 2004
 Versión de Windows Versión de SMB multicanal de Azure Files Cifrado máximo
SMB del canal SMB

Windows 10, SMB 3.1.1 Sí, con KB5003690 o posterior AES-128-GCM

versión 2004

Windows Server 2019 SMB 3.1.1 Sí, con KB5003703 o posterior AES-128-GCM

Windows 10, versión SMB 3.1.1 Sí, con KB5003703 o posterior AES-128-GCM
1809

Windows Server 2016 SMB 3.1.1 Sí, con KB5004238 o más AES-128-GCM
reciente, y una clave del Registro
aplicada

Windows 10, versión SMB 3.1.1 Sí, con KB5004238 o más AES-128-GCM
1607 reciente, y una clave del Registro
aplicada

Windows 10, SMB 3.1.1 Sí, con KB5004249 o más AES-128-GCM

versión 1507 reciente, y una clave del Registro
aplicada

Windows Server 2012 R2 SMB 3.0 No AES-128-CCM

Windows 8.1 SMB 3.0 No AES-128-CCM

Windows Server 2012 SMB 3.0 No AES-128-CCM

Windows Server 2008 SMB 2.1 No No compatible

R21

Windows 71 SMB 2.1 No No compatible

1
El soporte técnico habitual de Microsoft para Windows 7 y Windows Server 2008 R2 ha
finalizado. Es posible adquirir soporte técnico adicional para las actualizaciones de
seguridad solo a través del programa Actualización de seguridad extendida (ESU) . Se
recomienda encarecidamente migrar de estos sistemas operativos.

７ Nota

Siempre se recomienda disponer de la KB más reciente para su versión de

Windows.

Se aplica a
 Tipo de recurso compartido de archivos SMB NFS

Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS

Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS

Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Requisitos previos
Asegúrese de que el puerto 445 está abierto: el protocolo SMB requiere que esté
abierto el puerto TCP 445. Se producirá un error en las conexiones si se bloquea el
puerto 445. Puede comprobar si el firewall o ISP está bloqueando el puerto 445 con el
cmdlet Test-NetConnection . Consulte Puerto 445 bloqueado.

Uso de un recurso compartido de archivos de

Azure con Windows
Para usar un recurso compartido de archivos de Azure con Windows, debe montarlo, lo
que significa asignarle una letra de unidad o una ruta de acceso a un punto de montaje,
o acceder a él mediante su ruta de acceso UNC.

En este artículo se usa la clave de la cuenta de almacenamiento para tener acceso al

recurso compartido de archivos. Una clave de cuenta de almacenamiento es una clave
de administrador para una cuenta de almacenamiento, lo que incluye los permisos de
administrador de todos los archivos y carpetas dentro de un recurso compartido de
archivos al que accede, y de todos los recursos compartidos de archivos y otros recursos
de almacenami