Compartir a través de

Preguntas más frecuentes sobre Azure Files y Azure File Sync

  • Artículo

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.

    Una vez completada la carga inicial en el recurso compartido de archivos de Azure, Azure File Sync no sobrescribe ningún archivo del grupo de sincronización. En su lugar, usa una estrategia sencilla de resolución de conflictos: mantiene los dos cambios en los archivos que se cambian 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 Azure Portal y seleccione Control de acceso (IAM) en el menú del servicio.

    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.

  • ¿Por qué está el software antivirus en el servidor AFS recuperando archivos en capas?
    Cuando los usuarios acceden a archivos en capas, algún software antivirus (AV) puede provocar recuperaciones de archivos no deseadas. Esto ocurre si el software AV no está configurado para pasar por alto los archivos en capas (aquellos con el atributo RECALL_ON_DATA_ACCESS). Esto es lo que sucede:

    1. Un usuario intenta acceder a un archivo en capas.
    2. El software AV bloquea el identificador de lectura.
    3. A continuación, la aplicación AV realiza su propia lectura para examinar el archivo de virus.

    Este proceso puede aparecer como si el software AV recuperase los archivos en capas, pero realmente lo desencadena el intento de acceso del usuario. Para evitar este problema, asegúrese de que el proveedor de AV configura su software para omitir el examen de archivos en capas con el atributo RECALL_ON_DATA_ACCESS.

  • ¿Puede el software de inspección SSL bloquear el acceso a los servidores AFS? Asegúrese de que el software de inspección SSL (como Zscaler o FortiGate) permite que los puntos de conexión de servidor de Azure File Sync (AFS) accedan a Azure. Estas herramientas de inspección SSL pueden invalidar la configuración del firewall y permitir de forma selectiva el tráfico. Póngase en contacto con el administrador de red para resolver este problema. Use el comando "testnet" para determinar si el servidor AFS está experimentando este problema.

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, la antigüedad de expiración de contraseña configurada en el entorno de AD puede ser diferente para las cuentas de inicio de sesión de equipo o servicio, y debe tenerlo en cuenta para Actualizar la contraseña de la identidad de la 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, desde un cliente unido a un dominio, puede usar el siguiente comando de PowerShell para ver todos los elementos de un directorio y su propietario, incluido el UPN:

    Get-ChildItem <Path> | Get-ACL | Select Path, Owner

Network File System (NFS v4.1)

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?
    No. El flujo de trabajo eliminar recurso compartido de archivos eliminará automáticamente las instantáneas al eliminar el recurso compartido.

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