Azure Files에 대한 FAQ(질문과 대답)

  • 아티클

Azure Files는 산업 표준 SMB(서버 메시지 블록) 프로토콜 및 NFS(네트워크 파일 시스템) 프로토콜을 통해 액세스할 수 있는 클라우드에서 완전 관리형 파일 공유를 제공합니다. Azure 파일 공유를 Windows, Linux 및 macOS의 클라우드 또는 온-프레미스 배포에 동시에 탑재할 수 있습니다. 데이터가 사용되는 위치 가까이에 대한 빠른 액세스를 위해 Azure 파일 동기화를 사용하여 Windows Server 컴퓨터에서 Azure 파일 공유를 캐시할 수도 있습니다.

Azure 파일 동기화

  • 도메인 조인 서버와 비 도메인 조인 서버가 동일한 동기화 그룹에 있을 수 있나요?
    예. 동기화 그룹에는 도메인에 가입하지 않은 경우에도 다른 Active Directory 구성원 자격을 갖는 서버 엔드포인트가 포함될 수 있습니다. 이 구성이 기술적으로는 작동하지만, 한 서버의 파일 및 폴더에 대해 정의된 ACL(액세스 제어 목록)은 동기화 그룹의 다른 서버에 의해 적용될 수 없으므로 이런 구성은 일반적인 구성으로 권장되지 않습니다. 최상의 결과를 얻으려면 동일한 Active Directory 포리스트에 있는 서버 간, 다른 Active Directory 포리스트에 있지만 설정된 신뢰 관계에 있는 서버 간 또는 도메인에 있지 않은 서버 간에 동기화하는 것이 좋습니다. 이러한 구성 간의 혼합 사용은 방지하는 것이 좋습니다.

  • SMB 또는 포털을 통해 파일을 Azure 파일 공유에 직접 만들었습니다. 해당 파일이 동기화 그룹의 서버에 동기화되는 데 얼마나 걸리나요?

    Azure Portal 또는 SMB를 사용하여 Azure 파일 공유에서 변경한 사항은 즉시 검색되지 않고 서버 엔드포인트의 변경 사항처럼 복제됩니다. Azure Files에는 아직 변경 알림/저널링이 없어서 파일이 변경될 때 동기화 세션을 자동으로 시작할 방법이 없습니다. Windows Server에서 Azure 파일 동기화는 Windows USN 저널링을 사용하여 파일이 변경될 때 자동으로 동기화 세션을 시작합니다.

    Azure 파일 공유의 변경 사항을 검색하기 위해 Azure 파일 동기화에는 변경 검색 작업이라는 예약된 작업이 있습니다. 변경 검색 작업은 파일 공유의 모든 파일을 열거한 다음 해당 파일의 동기화 버전과 비교합니다. 변경 검색 작업에서 파일이 변경된 것으로 판단되면 Azure 파일 동기화는 동기화 세션을 시작합니다. 변경 검색 작업은 24시간마다 시작됩니다. 변경 검색 작업은 Azure 파일 공유의 모든 파일을 열거하여 작동하므로 변경 검색은 큰 네임스페이스가 작은 네임스페이스보다 오래 걸립니다. 큰 네임스페이스의 경우 변경된 파일을 확인하는 것이 24시간마다 한 번 이상이 걸릴 수 있습니다.

    Azure 파일 공유에서 변경된 파일을 즉시 동기화하기 위해 AzStorageSyncChangeDetection PowerShell cmdlet을 사용하여 Azure 파일 공유의 변경 내용 검색을 수동으로 시작할 수 있습니다. 이 cmdlet은 일부 유형의 자동화된 프로세스를 통해 Azure 파일 공유를 변경하거나 관리자가 변경 작업을 수행하는 시나리오를 위한 것입니다(예: 파일 및 디렉터리를 공유로 이동). 최종 사용자 변경의 경우 IaaS VM에 Azure 파일 동기화 에이전트를 설치하고, 최종 사용자가 IaaS VM을 통해 파일 공유에 액세스할 수 있도록 하는 것이 좋습니다. 이렇게 하면 Invoke-AzStorageSyncChangeDetection cmdlet을 사용하지 않고도 모든 변경 내용을 신속하게 다른 에이전트와 동기화할 수 있습니다. 자세한 내용은 Invoke-AzStorageSyncChangeDetection 설명서를 참조하세요.

    Windows Server의 볼륨에 대해 USN과 유사한 Azure 파일 공유에 대한 변경 검색 기능을 추가하는 방법을 모색하고 있습니다. 향후 개발을 위해 Azure 커뮤니티 피드백에서 투표하여 이 기능의 우선 순위를 지정할 수 있도록 도움을 주세요.

  • 같은 파일이 두 서버에서 거의 동시에 변경하는 경우 어떻게 되나요?
    파일 충돌은 Azure 파일 공유의 파일이 서버 엔드포인트 위치에 있는 파일과 일치하지 않을 때 생성됩니다(크기 및/또는 마지막으로 수정한 시간이 다름).

    다음 시나리오에서는 파일 충돌을 일으킬 수 있습니다.

    • 엔드포인트에서 파일을 만들거나 수정합니다(예: 서버 A). 서버 A의 변경 내용이 해당 엔드포인트와 동기화되기 전에 다른 엔드포인트에서 동일한 파일을 수정하면 충돌 파일이 만들어집니다.
    • 파일은 서버 엔드포인트를 만들기 전에 Azure 파일 공유 및 서버 엔드포인트 위치에 존재했습니다. 서버 엔드포인트를 만들 때 파일 크기 및/또는 마지막으로 수정된 시간이 서버의 파일과 Azure 파일 공유 간에 다른 경우 충돌 파일이 만들어집니다.
    • 데이터베이스가 손상되었거나 지식 제한에 도달하여 동기화 데이터베이스가 다시 생성되었습니다. 데이터베이스가 다시 만들어지면 동기화가 조정이라는 모드로 전환됩니다. 조정이 발생할 때 파일 크기 및/또는 마지막으로 수정된 시간이 서버의 파일과 Azure 파일 공유 간에 다른 경우 충돌 파일이 만들어집니다.

    Azure 파일 동기화는 간단한 충돌 해결 전략을 사용합니다. 두 개의 엔드포인트에서 동시에 변경된 파일에 대한 변경 내용을 유지합니다. 가장 최근에 기록된 변경 내용에 원래 파일 이름이 사용됩니다. 이전 파일(LastWriteTime으로 결정됨)에는 파일 이름에 엔드포인트 이름과 충돌 번호가 추가됩니다. 서버 엔드포인트의 경우 엔드포인트 이름은 서버의 이름입니다. 클라우드 엔드포인트의 경우 엔드포인트 이름은 클라우드입니다. 이름은 다음 분류를 따릅니다.

    <FileNameWithoutExtension>-<endpointName>[-#].<ext>

    예를 들어, CompanyReport.docx의 첫 번째 충돌은 CentralServer가 이전 쓰기가 발생한 위치인 경우 CompanyReport-CentralServer.docx가 됩니다. 두 번째 충돌은 CompanyReport-CentralServer-1.docx라는 이름이 됩니다. Azure 파일 동기화는 파일당 100개의 충돌 파일을 지원합니다. 최대 충돌 파일 수에 도달하면 충돌 파일 수가 100개 미만이 될 때까지 파일 동기화가 실패합니다.

  • 클라우드 계층화를 사용하지 않도록 설정했습니다. 서버 엔드포인트 위치에 계층화된 파일이 있는 이유는 무엇인가요?
    계층화된 파일이 서버 엔드포인트 위치에 있을 수 있는 이유는 두 가지입니다.

    • 기존 동기화 그룹에 새 서버 엔드포인트를 추가할 때 초기 다운로드 모드에 대해 첫 번째 네임스페이스 리콜 옵션 또는 네임스페이스 리콜 전용 옵션을 선택하면 파일이 로컬에서 다운로드될 때까지 계층화된 것으로 표시됩니다. 이 문제를 방지하려면 초기 다운로드 모드에서 계층화 파일 방지 옵션을 선택합니다. 파일을 수동으로 회수하려면 Invoke-StorageSyncFileRecall cmdlet을 사용합니다.

    • 서버 엔드포인트에서 클라우드 계층화를 사용하도록 설정한 다음 사용하지 않도록 설정하면 파일에 액세스할 때까지 파일이 계층화된 상태로 유지됩니다.

  • 계층화된 파일이 Windows 파일 탐색기에서 썸네일이나 미리 보기가 표시되지 않는 이유는 무엇인가요?
    계층화된 파일의 경우 서버 엔드포인트에 썸네일 및 미리 보기가 표시되지 않습니다. 이런 동작은 Windows의 썸네일 캐시 기능이 오프라인 특성을 사용하여 파일 읽기를 의도적으로 건너뛰기 때문에 발생할 수 있습니다. 클라우드 계층화를 사용하는 경우 계층화된 파일을 통해 읽으면 해당 파일을 다운로드(회수)할 수 있습니다.

    이 동작은 Azure 파일 동기화와 관련이 없습니다. Windows 파일 탐색기는 오프라인 특성이 설정된 모든 파일에 대해 “회색 X”를 표시합니다. SMB를 통해 파일에 액세스할 때 X 아이콘이 표시됩니다. 이 동작에 대한 자세한 설명은 오프라인으로 표시된 파일에 대한 미리 보기 이미지가 표시되지 않는 이유는 무엇인가요?를 참조하세요.

    계층화된 파일 관리 방법에 관한 질문은 계층화된 파일을 관리하는 방법을 참조하세요.

  • 계층화된 파일이 서버 엔드포인트 네임스페이스 외부에 있는 이유는 무엇인가요?
    Azure 파일 동기화 에이전트 버전 3 이전에 Azure 파일 동기화는 서버 엔드포인트인 동일한 볼륨이 아닌 서버 엔드포인트 외부에서 계층화된 파일의 이동을 차단합니다. 복사 작업, 계층화되지 않은 파일의 이동, 계층화된 파일이 다름 볼륨으로 이동하는 작업은 영향을 받지 않았습니다. 이 동작의 이유는 파일 탐색기 및 다른 Windows API에서 동일한 볼륨에서의 이동 작업이 거의 순간적인 이름 바꾸기 작업이라는 암시적 가정 때문이었습니다. 즉, 이동하면 Azure 파일 동기화가 클라우드의 데이터를 다시 호출하는 동안 파일 탐색기 또는 다른 이동 방법(예: 명령줄 또는 PowerShell)이 응답하지 않는다고 표시됩니다. Azure 파일 동기화 에이전트 버전 3.0.12.0부터 Azure 파일 동기화를 사용하면 외부 서버 엔드포인트에서 계층화된 파일을 이동할 수 있습니다. 계층화된 파일을 서버 엔드포인트 외부에서 계층화된 파일로 유지한 다음, 백그라운드에서 파일을 회수하여 앞에서 언급한 부정적인 영향을 방지합니다. 즉, 동일한 볼륨에서의 이동은 즉각적이고, 이동이 완료되면 파일을 디스크로 회수하는 모든 작업을 수행합니다.

  • 내 서버의 Azure 파일 동기화와 관련된 문제(동기화, 클라우드 계층화 등)가 있습니다. 내 서버 엔드포인트를 제거하고 다시 만들어야 하나요?

    없음: 서버 엔드포인트를 제거하는 것은 서버를 다시 부팅하는 것과 다릅니다! 서버 엔드포인트를 제거했다가 다시 만드는 것이 Azure 파일 동기화의 동기화, 클라우드 계층화 또는 기타 측면의 문제를 해결하기 위한 적절한 해결 방법이 아닙니다. 서버 엔드포인트를 제거하는 것은 파괴적인 작업입니다. 계층화된 파일이 서버 엔드포인트 네임스페이스 외부에 존재하는 경우 데이터가 손실될 수 있습니다. 자세한 내용은 계층화된 파일이 서버 엔드포인트 네임스페이스 외부에 존재하는 이유를 참조하세요. 또는 서버 엔드포인트 네임스페이스 내에 있는 계층화된 파일에 액세스할 수 없는 파일이 생성될 수 있습니다. 이러한 문제는 서버 엔드포인트를 다시 만들어도 해결되지 않습니다. 클라우드 계층화를 사용하도록 설정하지 않아도 계층화된 파일이 서버 엔드포인트 네임스페이스에 있을 수 있습니다. 따라서 이 특정 폴더에 Azure 파일 동기화를 더 이상 사용하지 않거나 Microsoft 엔지니어가 명시적으로 이렇게 하도록 지시한 경우가 아니라면, 서버 엔드포인트를 제거하지 않는 것이 좋습니다. 서버 엔드포인트 제거에 대한 자세한 내용은 서버 엔드포인트 제거를 참조하세요.

  • 스토리지 동기화 서비스 및/또는 스토리지 계정을 다른 리소스 그룹이나 구독 또는 Microsoft Entra 테넌트로 이동할 수 있나요?
    네, 스토리지 동기화 서비스 및/또는 스토리지 계정을 다른 리소스 그룹이나 구독 또는 Microsoft Entra 테넌트로 이동할 수 있습니다. 스토리지 동기화 서비스 또는 스토리지 계정을 이동한 후에는 Microsoft.StorageSync 애플리케이션 액세스 권한을 스토리지 계정에 부여해야 합니다. 다음 단계를 수행합니다.

    1. Azure Portal에 로그인하고 왼쪽 탐색에서 IAM(액세스 제어)를 선택합니다.

    2. 역할 할당 탭을 선택하여 스토리지 계정에 액세스할 수 있는 사용자 및 애플리케이션(서비스 주체)을 나열합니다.

    3. Microsoft.StorageSync 또는 하이브리드 파일 동기화 서비스(이전 애플리케이션 이름)가 읽기 권한자 및 데이터 액세스 역할이 있는 목록에 나타나는지 확인합니다.

      Microsoft.StorageSync 또는 하이브리드 파일 동기화 서비스가 목록에 나타나지 않으면 다음 단계를 수행합니다.

      • 추가를 선택합니다.
      • 역할 필드에서 읽기 권한자 및 데이터 액세스를 선택합니다.
      • 선택 필드에 Microsoft.StorageSync를 입력하고 역할을 선택한 다음, 저장을 선택합니다.

      참고 항목

      클라우드 엔드포인트를 만들 때 스토리지 동기화 서비스 및 스토리지 계정이 동일한 Microsoft Entra 테넌트에 있어야 합니다. 클라우드 엔드포인트를 만든 후에는 스토리지 동기화 서비스 및 스토리지 계정을 다른 Microsoft Entra 테넌트로 이동할 수 있습니다.

  • Azure 파일 동기화에서 Azure Files에 저장된 데이터와 함께 디렉터리/파일 수준 NTFS ACL을 보존하나요?

    2020년 2월 24일부터 Azure 파일 동기화에 의해 계층화된 신규 및 기존 ACL은 NTFS 형식으로 유지되며, Azure 파일 공유에 직접 적용된 ACL 수정은 동기화 그룹의 모든 서버에 동기화됩니다. Azure 파일 공유에 대한 ACL 변경 내용은 Azure 파일 동기화를 통해 동기화됩니다. Azure Files에 데이터를 복사할 때 SMB 또는 REST를 통해 특성, 타임스탬프, ACL을 Azure 파일 공유에 복사하는 데 필요한 “충실도”를 지원하는 복사 도구를 사용해야 합니다. AzCopy와 같은 Azure 복사 도구를 사용할 때는 최신 버전을 사용하는 것이 중요합니다. 파일의 중요한 메타데이터를 모두 복사할 수 있도록 Azure 복사 도구에 관한 개요를 보려면 파일 복사 도구 표를 확인합니다.

    Azure 파일 동기화 관리형 파일 공유에서 Azure Backup을 사용하도록 설정한 경우 파일 ACL은 백업 복원 워크플로의 일부로 계속해서 복원될 수 있습니다. 이는 전체 공유 또는 개별 파일/디렉터리에 대해 작동합니다.

    Azure 파일 동기화에서 관리형 파일 공유에 대한 자체 관리형 백업 솔루션의 일부로 스냅샷을 사용하는 경우, 스냅샷이 2020년 2월 24일 이전에 생성되었다면 ACL이 NTFS ACL로 제대로 복원되지 않을 수 있습니다. 이 문제가 발생하는 경우 Azure 지원에 문 하는 것이 좋습니다.

  • Azure 파일 동기화 디렉터리에 대한 LastWriteTime을 동기화하나요? 디렉터리 내의 파일이 변경될 때 수정된 날짜 타임스탬프가 업데이트되지 않는 이유는 무엇인가요?
    아니요, Azure 파일 동기화는 디렉터리에 대한 LastWriteTime을 동기화하지 않습니다. 또한 Azure Files는 디렉터리 내의 파일이 변경될 때 디렉터리에 대해 수정된 날짜 타임스탬프(LastWriteTime)를 업데이트하지 않습니다. 이는 정상적인 동작입니다.

보안, 인증 및 액세스 제어

  • Azure Files에서 파일 액세스 및 변경을 감사하려면 어떻게 해야 하나요?

    Azure Files에 대한 감사 기능을 제공하는 두 가지 옵션이 있습니다.

    • 사용자가 Azure 파일 공유에 직접 액세스하는 경우 Azure Storage 로그를 사용하여 파일 변경 내용 및 사용자 액세스를 추적할 수 있습니다. 요청은 최상의 노력을 기준으로 기록됩니다.
    • 사용자가 Azure 파일 동기화 에이전트가 설치된 Windows Server를 통해 Azure 파일 공유에 액세스하는 경우 감사 정책 또는 타사 제품을 사용하여 Windows Server에서 파일 변경 내용 및 사용자 액세스를 추적합니다.

  • Azure Files는 ABE(액세스 기반 열거형)를 사용하여 SMB Azure 파일 공유의 파일 및 폴더 표시 유형을 제어하도록 지원하나요?

    Azure Files에서 ABE를 사용하는 것은 현재 지원되지 않지만 SMB Azure 파일 공유에서 DFS-N을 사용할 수 있습니다.

ID 기반 인증

  • Microsoft Entra Domain Services가 Microsoft Entra ID에 가입되거나 등록된 디바이스에서 Microsoft Entra 자격 증명을 사용하여 SMB 액세스를 지원하나요?

    아니요. 이 시나리오는 지원되지 않습니다.

  • ID 기반 인증을 사용하는 동안 CNAME(정식 이름)을 사용하여 Azure 파일 공유를 탑재할 수 있나요?

    예, 이 시나리오는 이제 SMB Azure 파일 공유에 대한 단일 포리스트 및 다중 포리스트 환경에서 모두 지원됩니다. 그러나 Azure Files는 스토리지 계정 이름을 도메인 접두사로 사용하는 CNAME 구성만 지원합니다. 스토리지 계정 이름을 접두사로 사용하지 않으려면 DFS 네임스페이스를 대신 사용하는 것이 좋습니다.

  • 다른 구독으로 VM에서 Microsoft Entra 자격 증명을 사용하여 Azure 파일 공유에 액세스할 수 있나요?

    파일 공유가 배포된 구독과 VM이 도메인에 조인된 Microsoft Entra Domain Services 배포와 동일한 Microsoft Entra 테넌트가 연결되어 있는 경우 동일한 Microsoft Entra 자격 증명을 사용하여 Azure 파일 공유에 액세스할 수 있습니다. 제한 사항은 연결된 Microsoft Entra 테넌트가 아닌 구독에만 적용됩니다.

  • Azure 파일 공유의 기본 테넌트와 다른 Microsoft Entra 테넌트를 사용하여 Azure 파일 공유에 대해 Microsoft Entra Domain Services 또는 온-프레미스 AD DS 인증을 사용하도록 설정할 수 있나요?

    아니요. Azure Files는 파일 공유와 동일한 구독에 있는 Microsoft Entra 테넌트와의 Microsoft Entra Domain Services 또는 온-프레미스 AD DS 통합만 지원합니다. 구독은 하나의 Microsoft Entra 테넌트와만 연결할 수 있습니다. 인증에 온-프레미스 AD DS를 사용하는 경우 스토리지 계정과 연결된 Azure AD에 AD DS 자격 증명이 동기화되어야 합니다.

  • Azure 파일 공유에 대한 온-프레미스 AD DS 인증에서 여러 포리스트를 사용하는 AD DS 환경과의 통합을 지원하나요?

    Azure Files 온-프레미스 AD DS 인증은 스토리지 계정이 등록된 도메인 서비스의 포리스트와만 통합됩니다. 다른 포리스트의 인증을 지원하려면 환경에서 포리스트 신뢰를 올바르게 구성해야 합니다. 자세한 지침은 여러 Active Directory 포리스트에서 Azure Files 사용을 참조하세요.

    참고 항목

    다중 포리스트 설정에서 파일 탐색기 사용하여 루트, 디렉터리, 파일 수준에서 Windows ACL/NTFS 권한을 구성하지 마세요. 대신 icacls를 사용합니다.

  • AD에서 내 스토리지 계정을 나타내기 위해 컴퓨터 계정 또는 서비스 로그온 계정을 만드는 데 차이가 있나요?

    컴퓨터 계정(기본값) 또는 서비스 로그온 계정을 만들어도 Azure Files에서 인증이 작동하는 방법에는 차이가 없습니다. AD 환경에서 스토리지 계정을 ID로 나타내는 방법을 직접 선택할 수 있습니다. Join-AzStorageAccountForAuth cmdlet에 설정된 기본 DomainAccountType은 컴퓨터 계정입니다. 그러나 AD 환경에서 구성된 암호 만료 기간은 컴퓨터 또는 서비스 로그온 계정에 대해 다를 수 있으며, AD에서 스토리지 계정 ID의 암호를 업데이트하는 것을 고려해야 합니다.

  • Microsoft Entra ID 또는 AD 자격 증명으로 새 연결을 초기화하기 전에 스토리지 계정 키로 캐시된 자격 증명을 제거하고 기존 SMB 연결을 삭제하는 방법은 무엇인가요?

    아래 두 단계 프로세스에 따라 스토리지 계정 키와 연결된 저장된 자격 증명을 제거하고 SMB 연결을 제거할 수 있습니다.

    1. Windows 명령 프롬프트에서 다음 명령을 실행하여 자격 증명을 제거합니다. 자격 증명을 찾을 수 없는 경우 이는 자격 증명을 유지하지 않은 것을 의미하므로 이 단계를 건너뛸 수 있습니다.

      cmdkey /delete:Domain:target=storage-account-name.file.core.windows.net

    2. 파일 공유에 대한 기존 연결을 삭제합니다. 탑재 경로를 탑재된 드라이브 문자 또는 storage-account-name.file.core.windows.net 경로로 지정할 수 있습니다.

      net use <drive-letter/share-path> /delete

  • SID(보안 식별자) 대신 파일 탐색기에서 파일/디렉터리 소유자의 UPN(userPrincipalName)을 볼 수 있나요?

    파일 탐색기는 RPC API를 서버(Azure Files)에 직접 호출하여 SID를 UPN으로 변환합니다. Azure Files가 이 API를 지원하지 않으므로, 파일 탐색기에서 Azure Files에 호스트되는 파일 및 디렉터리에 대한 UPN 대신 파일/디렉터리 소유자의 SID가 표시됩니다. 그러나 도메인 조인된 클라이언트에서 다음 PowerShell 명령을 사용하여 UPN을 포함한 디렉터리의 모든 항목과 해당 소유자를 볼 수 있습니다.

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

네트워크 파일 시스템(NFS v4.1)

공유 스냅샷

공유 스냅샷 만들기

  • 내 공유 스냅샷은 지리적으로 중복되나요?
    공유 스냅샷은 생성된 Azure 파일 공유와 동일한 중복성을 갖습니다. 계정에 대해 지역 중복 스토리지를 선택한 경우 공유 스냅샷이 페어링된 지역에도 중복해서 저장됩니다.

공유 스냅샷 정리

  • 내 공유는 삭제할 수 있지만 공유 스냅샷은 삭제할 수 없나요?
    공유에 활성 공유 스냅샷이 있는 경우 공유를 삭제할 수 없습니다. API를 사용하여 공유와 함께 공유 스냅샷을 삭제할 수 있습니다. Azure Portal에서 공유 스냅샷과 공유를 모두 삭제할 수도 있습니다.

청구 및 가격 책정

  • Azure Files에서 트랜잭션은 무엇이며 어떻게 청구됩니까? 프로토콜 트랜잭션은 사용자, 애플리케이션, 스크립트, 서비스가 Azure 파일 공유와 상호 작용할 때마다 발생합니다(파일 작성, 읽기, 나열, 삭제 등). 단일 작업으로 인식할 수 있는 일부 작업에는 실제로 여러 트랜잭션이 포함될 수 있다는 점을 기억해야 합니다. 종량제 모델에 대해 청구되는 표준 Azure 파일 공유의 경우 파일 공유에 미치는 영향에 따라 다양한 유형의 트랜잭션 가격이 다릅니다. 트랜잭션은 프로비전된 모델을 사용하여 청구되는 프리미엄 파일 공유에 대한 청구에 영향을 주지 않습니다. 자세한 내용은 요금 청구 이해를 참조하세요.

  • 스냅샷 공유 비용은 얼마인가요?
    공유 스냅샷은 기본적으로 증분합니다. 기본 공유 스냅샷은 공유 자체입니다. 모든 후속 공유 스냅샷은 증분하며, 이전 공유 스냅샷과의 차이만 저장합니다. 변경된 콘텐츠에 대해서만 요금이 청구됩니다. 100GiB의 데이터 공유가 있으나 마지막 공유 스냅샷 후에 5GiB만 변경된 경우 해당 공유 스냅샷은 추가로 5GiB만 사용하게 되며 105GiB에 대한 요금만 청구됩니다. 트랜잭션 및 표준 송신 요금에 대한 자세한 내용은 가격 책정 페이지를 참조하세요.

다른 서비스와 상호 운용성

  • Azure 파일 공유를 파일 공유 감시로 내 Windows Server 장애 조치(Failover) 클러스터에 사용할 수 있나요?
    이 구성은 현재 Azure Files에서 지원되지 않습니다. Azure Blob Storage를 사용하여 이 기능을 설정하는 방법에 대한 자세한 내용은 장애 조치(Failover) 클러스터에 대한 클라우드 감시 배포를 참조하세요.

참고 항목