Rozwiązywanie problemów z wydajnością usługi Azure Files

W tym artykule wymieniono typowe problemy związane z wydajnością udziału plików platformy Azure i przedstawiono potencjalne przyczyny i obejścia. Aby uzyskać największą wartość z tego przewodnika rozwiązywania problemów, zalecamy najpierw przeczytanie artykułu Omówienie wydajności usługi Azure Files.

Dotyczy

Typ udziału plików	SMB	NFS
Udziały plików w warstwie Standardowa (GPv2), LRS/ZRS
Udziały plików w warstwie Standardowa (GPv2), GRS/GZRS
Udziały plików w warstwie Premium (FileStorage), LRS/ZRS

Ogólne rozwiązywanie problemów z wydajnością

Najpierw wyklucz niektóre typowe przyczyny problemów z wydajnością.

Korzystasz ze starego systemu operacyjnego

Jeśli maszyna wirtualna klienta korzysta z systemu Windows 8.1 lub Windows Server 2012 R2 lub starszej dystrybucji systemu Linux lub jądra systemu Linux, mogą wystąpić problemy z wydajnością podczas uzyskiwania dostępu do udziałów plików platformy Azure. Uaktualnij system operacyjny klienta lub zastosuj poniższe poprawki.

Obciążenie jest ograniczane

Żądania są ograniczane, gdy osiągnięto limity operacji we/wy na sekundę (IOPS), ruchu przychodzącego lub wychodzącego dla udziału plików. Jeśli na przykład klient przekroczy liczbę operacji we/wy na sekundę według planu bazowego, zostanie on ograniczony przez usługę Azure Files. Ograniczanie przepustowości może spowodować, że klient ma niską wydajność.

Aby zrozumieć limity standardowych i premium udziałów plików, zobacz Cele udziału plików i skalowania plików. W zależności od obciążenia ograniczanie przepustowości można często uniknąć, przechodząc z standardowych do premium udziałów plików platformy Azure.

Aby dowiedzieć się więcej o tym, jak ograniczanie przepustowości na poziomie udziału lub konta magazynu może powodować duże opóźnienia, niską przepływność i ogólne problemy z wydajnością, zobacz Udostępnianie lub konto magazynu jest ograniczane.

Duże opóźnienia, niska przepływność lub mała liczba operacji we/wy na sekundę

Przyczyna 1. Udostępnianie lub konto magazynu jest ograniczane

Aby sprawdzić, czy udział lub konto magazynu jest ograniczane, możesz uzyskać dostęp do metryk platformy Azure i korzystać z nich w portalu. Możesz również utworzyć alerty, które powiadomią Cię, jeśli udział jest ograniczany lub ma zostać ograniczony. Zobacz Rozwiązywanie problemów z usługą Azure Files, tworząc alerty.

1. W witrynie Azure Portal przejdź do konta magazynu.

2. W okienku po lewej stronie w obszarze Monitorowanie wybierz pozycję Metryki.

3. Wybierz pozycję Plik jako przestrzeń nazw metryki dla zakresu konta magazynu.

4. Wybierz pozycję Transakcje jako metryka.

5. Dodaj filtr dla typu odpowiedzi, a następnie sprawdź, czy wszystkie żądania zostały ograniczone.

   W przypadku standardowych udziałów plików następujące typy odpowiedzi są rejestrowane, jeśli żądanie jest ograniczane na poziomie konta klienta:

   • ClientAccountRequestThrottlingError
   • ClientAccountBandwidthThrottlingError

   W przypadku udziałów plików w warstwie Premium następujące typy odpowiedzi są rejestrowane, jeśli żądanie jest ograniczane na poziomie udziału:

   • SuccessWithShareEgressThrottling
   • SuccessWithShareIngressThrottling
   • SuccessWithShareIopsThrottling
   • ClientShareEgressThrottlingError
   • ClientShareIngressThrottlingError
   • ClientShareIopsThrottlingError

   Jeśli żądanie ograniczone zostało uwierzytelnione za pomocą protokołu Kerberos, może zostać wyświetlony prefiks wskazujący protokół uwierzytelniania, taki jak:

   • KerberosSuccessWithShareEgressThrottling
   • KerberosSuccessWithShareIngressThrottling

   Aby dowiedzieć się więcej o poszczególnych typach odpowiedzi, zobacz Wymiary metryki.

   

Rozwiązanie

Jeśli używasz udziału plików w warstwie Premium, zwiększ aprowizowany rozmiar udziału plików, aby zwiększyć limit liczby operacji we/wy na sekundę. Aby dowiedzieć się więcej, zobacz Opis aprowizacji udziałów plików w warstwie Premium.

Przyczyna 2. Duże obciążenie metadanych lub przestrzeni nazw

Jeśli większość żądań jest skoncentrowana na metadanych (na przykład createfile, , openfile, closefile, queryinfolub querydirectory), opóźnienie będzie gorsze niż w przypadku operacji odczytu/zapisu.

Aby ustalić, czy większość żądań jest skoncentrowana na metadanych, zacznij od wykonania kroków 1–4 zgodnie z wcześniejszym opisem w sekcji Przyczyna 1. W kroku 5 zamiast dodawania filtru dla typu odpowiedzi dodaj filtr właściwości dla nazwy interfejsu API.

Obejścia

• Sprawdź, czy można zmodyfikować aplikację, aby zmniejszyć liczbę operacji metadanych.

• Jeśli używasz udziałów plików SMB platformy Azure w warstwie Premium, użyj buforowania metadanych.

• Rozdziel udział plików na wiele udziałów plików w ramach tego samego konta magazynu.

• Dodaj wirtualny dysk twardy (VHD) w udziale plików i zainstaluj dysk VHD z klienta, aby wykonać operacje na plikach względem danych. Takie podejście działa w przypadku scenariuszy lub scenariuszy z jednym zapisem/czytelnikiem z wieloma czytnikami i bez składników zapisywania. Ponieważ system plików jest własnością klienta, a nie usługi Azure Files, umożliwia to wykonywanie operacji metadanych na komputerze lokalnym. Konfiguracja oferuje wydajność podobną do lokalnej bezpośrednio dołączonej pamięci masowej. Jednak ze względu na to, że dane są w wirtualnym dysku twardym, nie można uzyskać do nich dostępu za pośrednictwem innych metod innych niż instalacja protokołu SMB, takich jak interfejs API REST lub witryna Azure Portal.

  1. Z komputera, który musi uzyskać dostęp do udziału plików platformy Azure, zainstaluj udział plików przy użyciu klucza konta magazynu i zamapuj go na dostępny dysk sieciowy (na przykład Z:).
  2. Przejdź do pozycji Zarządzanie dyskami i wybierz pozycję Akcja > Utwórz dysk VHD.
  3. Ustaw pozycję Lokalizacja na dysk sieciowy, na który jest mapowany udział plików platformy Azure, ustaw rozmiar wirtualnego dysku twardego zgodnie z potrzebami i wybierz pozycję Stały rozmiar.
  4. Wybierz przycisk OK. Po zakończeniu tworzenia dysku VHD zostanie on automatycznie zamontowany i pojawi się nowy nieprzydzielony dysk.
  5. Kliknij prawym przyciskiem myszy nowy nieznany dysk i wybierz polecenie Zainicjuj dysk.
  6. Kliknij prawym przyciskiem myszy nieprzydzielony obszar i utwórz nowy wolumin prosty.
  7. W obszarze Zarządzanie dyskami powinna zostać wyświetlona nowa litera dysku reprezentująca ten wirtualny dysk twardy z dostępem do odczytu/zapisu (na przykład E:). W Eksplorator plików nowy wirtualny dysk twardy powinien być widoczny na zamapowanym dysku sieciowym udziału plików platformy Azure (Z: w tym przykładzie). Aby było jasne, powinny istnieć dwie litery dysku: standardowe mapowanie sieci udziału plików platformy Azure w systemie Z:i mapowanie wirtualnego dysku twardego na dysku E:.
  8. W przypadku dużych operacji metadanych na dysku mapowanym dysku VHD (E:) powinna być znacznie wyższa wydajność niż na dysku mapowanym udziału plików platformy Azure (Z:). W razie potrzeby należy odłączyć zamapowany dysk sieciowy (Z:) i nadal uzyskiwać dostęp do zainstalowanego dysku VHD (E:).
  • Aby zainstalować dysk VHD na kliencie systemu Windows, możesz również użyć Mount-DiskImage polecenia cmdlet programu PowerShell.
  • Aby zainstalować dysk VHD w systemie Linux, zapoznaj się z dokumentacją dystrybucji systemu Linux. Oto przykład.

Przyczyna 3. Aplikacja jednowątkowa

Jeśli używana aplikacja jest jednowątkowa, ta konfiguracja może spowodować znacznie niższą przepływność operacji we/wy na sekundę niż maksymalna możliwa przepływność, w zależności od aprowizowanego rozmiaru udziału.

Rozwiązanie

• Zwiększ równoległość aplikacji, zwiększając liczbę wątków.
• Przełącz się do aplikacji, w których jest to możliwe, równoległość. Na przykład w przypadku operacji kopiowania można użyć narzędzia AzCopy lub narzędzia RoboCopy z klientów systemu Windows lub równoległego polecenia z klientów systemu Linux.

Przyczyna 4. Liczba kanałów SMB przekracza cztery

Jeśli używasz protokołu SMB MultiChannel i liczba kanałów, które przekroczyły cztery, spowoduje to niską wydajność. Aby określić, czy liczba połączeń przekracza cztery, użyj polecenia cmdlet get-SmbClientConfiguration programu PowerShell, aby wyświetlić bieżące ustawienia liczby połączeń.

Rozwiązanie

Ustaw ustawienie Systemu Windows na kartę sieciową dla protokołu SMB, aby łączna liczba kanałów nie przekraczała czterech. Jeśli na przykład masz dwie karty sieciowe, możesz ustawić maksymalną liczbę kart sieciowych na dwie przy użyciu następującego polecenia cmdlet programu PowerShell: Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2.

Przyczyna 5: Rozmiar odczytu z wyprzedzeniem jest za mały (tylko system plików NFS)

Począwszy od jądra systemu Linux w wersji 5.4, klient systemu plików NFS systemu Linux używa wartości domyślnej read_ahead_kb 128 kibibajtów (KiB). Ta mała wartość może zmniejszyć przepływność odczytu dla dużych plików.

Rozwiązanie

Zalecamy zwiększenie wartości parametru read_ahead_kb jądra do 15 mebibajtów (MiB). Aby zmienić tę wartość, należy ustawić rozmiar z wyprzedzeniem odczytu w sposób trwały, dodając regułę w ujściu, menedżera urządzeń jądra systemu Linux. Wykonaj te kroki:

1. W edytorze tekstów utwórz plik /etc/udev/rules.d/99-nfs.rules , wprowadzając i zapisując następujący tekst:

   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. W konsoli zastosuj regułę udev, uruchamiając polecenie udevadm jako superużytkownik i ponownie ładując pliki reguł i inne bazy danych. Aby uświadomić sobie nowy plik, wystarczy uruchomić to polecenie tylko raz.

   sudo udevadm control --reload
   

Bardzo duże opóźnienie żądań

Przyczyna

Maszyna wirtualna klienta może znajdować się w innym regionie niż udział plików. Inne przyczyny dużego opóźnienia mogą być spowodowane opóźnieniem spowodowanym przez klienta lub sieć.

Rozwiązanie

• Uruchom aplikację z maszyny wirtualnej znajdującej się w tym samym regionie co udział plików.
• W przypadku konta magazynu przejrzyj metryki transakcji SuccessE2ELatency i SuccessServerLatency za pośrednictwem usługi Azure Monitor w witrynie Azure Portal. Duża różnica między wartościami metryk SuccessE2ELatency i SuccessServerLatency jest wskazaniem opóźnienia, które prawdopodobnie jest spowodowane przez sieć lub klienta. Zobacz Metryki transakcji w dokumentacji danych monitorowania usługi Azure Files.

Klient nie może uzyskać maksymalnej przepływności obsługiwanej przez sieć

Przyczyna

Jedną z potencjalnych przyczyn jest brak obsługi wielokanałowej protokołu SMB dla standardowych udziałów plików. Obecnie usługa Azure Files obsługuje tylko jeden kanał dla standardowych udziałów plików, więc istnieje tylko jedno połączenie z maszyny wirtualnej klienta do serwera. To pojedyncze połączenie jest powiązane z jednym rdzeniem na maszynie wirtualnej klienta, więc maksymalna przepływność osiągalna z maszyny wirtualnej jest powiązana przez jeden rdzeń.

Rozwiązanie

• W przypadku udziałów plików w warstwie Premium włącz funkcję SMB Multichannel.
• Uzyskanie maszyny wirtualnej z większym rdzeniem może pomóc zwiększyć przepływność.
• Uruchomienie aplikacji klienckiej z wielu maszyn wirtualnych zwiększy przepływność.
• W miarę możliwości używaj interfejsów API REST.
• W przypadku udziałów nconnect plików platformy Azure NFS jest dostępny. Zobacz Zwiększanie wydajności udziału plików platformy Azure w systemie plików NFS za pomocą programu nconnect.

Niska wydajność w udziale usługi Azure File zainstalowanym na maszynie wirtualnej z systemem Linux

Przyczyna 1. Buforowanie

Jedną z możliwych przyczyn niskiej wydajności jest wyłączone buforowanie. Buforowanie może być przydatne, jeśli wielokrotnie uzyskujesz dostęp do pliku. W przeciwnym razie może to być obciążenie. Przed jego wyłączeniem sprawdź, czy używasz pamięci podręcznej.

Rozwiązanie dla przyczyny 1

Aby sprawdzić, czy buforowanie jest wyłączone, poszukaj cache= wpisu.

Cache=none wskazuje, że buforowanie jest wyłączone. Zainstaluj ponownie udział przy użyciu domyślnego polecenia instalacji lub jawnie dodając cache=strict opcję do polecenia instalacji, aby upewnić się, że domyślne buforowanie lub "ścisłe" tryb buforowania jest włączony.

W niektórych scenariuszach serverino opcja instalacji może spowodować ls uruchomienie stat polecenia względem każdego wpisu katalogu. To zachowanie powoduje obniżenie wydajności podczas wyświetlania listy dużego katalogu. Opcje instalacji można sprawdzić we wpisie /etc/fstab :

//azureuser.file.core.windows.net/cifs /cifs cifs vers=2.1,serverino,username=xxx,password=xxx,dir_mode=0777,file_mode=0777

Możesz również sprawdzić, czy są używane poprawne opcje, uruchamiając sudo mount | grep cifs polecenie i sprawdzając jego dane wyjściowe. Poniżej przedstawiono przykładowe dane wyjściowe:

//azureuser.file.core.windows.net/cifs on /cifs type cifs (rw,relatime,vers=2.1,sec=ntlmssp,cache=strict,username=xxx,domain=X,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.10.1,file_mode=0777, dir_mode=0777,persistenthandles,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,actimeo=1)

cache=strict Jeśli opcja lub serverino nie jest obecna, odinstaluj i zainstaluj ponownie usługę Azure Files, uruchamiając polecenie instalacji z dokumentacji. Następnie ponownie sprawdź, czy wpis /etc/fstab ma poprawne opcje.

Przyczyna 2. Ograniczanie przepustowości

Istnieje możliwość ograniczenia przepustowości, a żądania są wysyłane do kolejki. Możesz to sprawdzić, korzystając z metryk usługi Azure Storage w usłudze Azure Monitor. Możesz również utworzyć alerty, które powiadamiają o tym, czy udział jest ograniczany lub ma zostać ograniczony. Zobacz Rozwiązywanie problemów z usługą Azure Files, tworząc alerty.

Rozwiązanie dla przyczyny 2

Upewnij się, że aplikacja znajduje się w celach skalowania usługi Azure Files. Jeśli używasz standardowych udziałów plików platformy Azure, rozważ przejście na warstwę Premium.

Przepływność na klientach z systemem Linux jest niższa niż w przypadku klientów z systemem Windows

Przyczyna

Jest to znany problem z implementacją klienta SMB w systemie Linux.

Rozwiązanie

• Rozłóż obciążenie na wiele maszyn wirtualnych.
• Na tej samej maszynie wirtualnej użyj wielu punktów instalacji z opcją nosharesock i rozłóż obciążenie między te punkty instalacji.
• W systemie Linux spróbuj przeprowadzić instalowanie przy użyciu nostrictsync opcji , aby uniknąć wymuszania opróżniania protokołu SMB na każdym fsync wywołaniu. W przypadku usługi Azure Files ta opcja nie zakłóca spójności danych, ale może to spowodować nieaktualne metadane pliku na listach katalogów (ls -l polecenie). Bezpośrednie wykonywanie zapytań dotyczących metadanych pliku przy użyciu stat polecenia spowoduje zwrócenie najbardziej aktualnych metadanych pliku.

Duże opóźnienia w przypadku obciążeń z dużym obciążeniem metadanych obejmujących rozległe operacje otwierania/zamykania

Przyczyna

Brak obsługi dzierżaw katalogów.

Rozwiązanie

• Jeśli to możliwe, należy unikać nadmiernego otwierania/zamykania uchwytu w tym samym katalogu w krótkim czasie.
• W przypadku maszyn wirtualnych z systemem Linux zwiększ limit czasu pamięci podręcznej wpisu katalogu, określając actimeo=<sec> jako opcję instalacji. Domyślnie limit czasu wynosi 1 sekundę, więc może pomóc większa wartość, taka jak 30 sekund.
• W przypadku maszyn wirtualnych CentOS Linux lub Red Hat Enterprise Linux (RHEL) uaktualnij system do systemu CentOS Linux 8.2 lub RHEL 8.2. W przypadku innych dystrybucji systemu Linux uaktualnij jądro do wersji 5.0 lub nowszej.

Powolne wyliczanie plików i folderów

Przyczyna

Ten problem może wystąpić, jeśli na komputerze klienckim nie ma wystarczającej ilości pamięci podręcznej dla dużych katalogów.

Rozwiązanie

Aby rozwiązać ten problem, dostosuj DirectoryCacheEntrySizeMax wartość rejestru, aby umożliwić buforowanie większych list katalogów na komputerze klienckim:

• Lokalizacja: HKEY_LOCAL_MACHINE\System\CCS\Services\Lanmanworkstation\Parameters
• Nazwa wartości: DirectoryCacheEntrySizeMax
• Typ wartości: DWORD

Można na przykład ustawić ją na 0x100000 wartość i sprawdzić, czy wydajność się poprawia.

Powolne kopiowanie plików do i z udziałów plików platformy Azure

Podczas próby przeniesienia plików do usługi Azure Files może być widoczna niska wydajność. Jeśli nie masz określonego minimalnego wymagania dotyczącego rozmiaru we/wy, zalecamy użycie 1 MiB jako rozmiaru we/wy w celu uzyskania optymalnej wydajności.

Nadmierny katalogOtwórz/KatalogZawołania

Przyczyna

Jeśli liczba wywołań DirectoryOpen/DirectoryClose jest jednym z najważniejszych wywołań interfejsu API i nie oczekujesz, że klient wykona te wiele wywołań, problem może być spowodowany przez oprogramowanie antywirusowe zainstalowane na maszynie wirtualnej klienta platformy Azure.

Rozwiązanie

Poprawka tego problemu jest dostępna w kwietniowej aktualizacji platformy dla systemu Windows.

Funkcja SMB Multichannel nie jest wyzwalana

Przyczyna

Ostatnie zmiany ustawień konfiguracji SMB Multichannel bez ponownego zainstalowania.

Rozwiązanie

• Po wprowadzeniu zmian w ustawieniach konfiguracji wielokanałowej SMB klienta lub konta SMB systemu Windows należy odinstalować udział, poczekać 60 sekund i ponownie zainstalować udział, aby wyzwolić wielokanałowość.
• W przypadku systemu operacyjnego klienta systemu Windows wygeneruj obciążenie operacjami we/wy z dużą głębokością kolejki, na przykład skopiowanie pliku w celu wyzwolenia funkcji SMB Multichannel. W przypadku systemu operacyjnego serwera funkcja SMB Multichannel jest wyzwalana z funkcją QD=1, co oznacza, że natychmiast po uruchomieniu dowolnego we/wy udziału.

Niska wydajność podczas rozpakowywania plików

W zależności od dokładnej metody kompresji i operacji rozpakowywania operacje dekompresacji mogą działać wolniej w udziale plików platformy Azure niż na dysku lokalnym. Jest to często spowodowane tym, że rozpakowywanie narzędzi wykonuje wiele operacji metadanych w procesie dekompresacji skompresowanego archiwum. Aby uzyskać najlepszą wydajność, zalecamy skopiowanie skompresowanego archiwum z udziału plików platformy Azure do dysku lokalnego, rozpakowanie tam, a następnie użycie narzędzia do kopiowania, takiego jak Robocopy (lub AzCopy), aby skopiować z powrotem do udziału plików platformy Azure. Użycie narzędzia do kopiowania, takiego jak Robocopy, może zrekompensować zmniejszoną wydajność operacji metadanych w usłudze Azure Files względem dysku lokalnego przy użyciu wielu wątków w celu równoległego kopiowania danych.

Duże opóźnienie w witrynach internetowych hostowanych w udziałach plików

Przyczyna

Powiadomienie o zmianie pliku o dużej liczbie udziałów plików może spowodować duże opóźnienia. Dzieje się tak zwykle w przypadku witryn internetowych hostowanych w udziałach plików z głęboką strukturą katalogów zagnieżdżonych. Typowym scenariuszem jest hostowana aplikacja internetowa usług IIS, w której dla każdego katalogu w konfiguracji domyślnej jest konfigurowane powiadomienie o zmianie pliku. Każda zmiana (ReadDirectoryChangesW) w udziale, który klient jest zarejestrowany w celu wypychania powiadomienia o zmianie z usługi plików do klienta, który pobiera zasoby systemowe, a problem pogarsza się wraz z liczbą zmian. Może to spowodować ograniczenie udziału, a tym samym zwiększyć opóźnienie po stronie klienta.

Aby potwierdzić, możesz użyć metryk platformy Azure w portalu.

1. W witrynie Azure Portal przejdź do konta magazynu.
2. W menu po lewej stronie w obszarze Monitorowanie wybierz pozycję Metryki.
3. Wybierz pozycję Plik jako przestrzeń nazw metryki dla zakresu konta magazynu.
4. Wybierz pozycję Transakcje jako metryka.
5. Dodaj filtr ResponseType i sprawdź, czy jakiekolwiek żądania mają kod SuccessWithThrottling odpowiedzi (dla protokołu SMB lub NFS) lub ClientThrottlingError (dla architektury REST).

Rozwiązanie

• Jeśli powiadomienie o zmianie pliku nie jest używane, wyłącz powiadomienie o zmianie pliku (preferowane).

  • Wyłącz powiadomienie o zmianie pliku, aktualizując tryb FCNMode.
  • Zaktualizuj interwał sondowania procesu roboczego usług IIS (W3WP) na 0, ustawiając HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds w rejestrze i ponownie uruchom proces W3WP. Aby dowiedzieć się więcej o tym ustawieniu, zobacz Typowe klucze rejestru używane przez wiele części usług IIS.

• Zwiększ częstotliwość interwału sondowania powiadomień o zmianie pliku, aby zmniejszyć wolumin.

  Zaktualizuj interwał sondowania procesu roboczego W3WP na wyższą wartość (na przykład 10 lub 30 minut) na podstawie wymagań. Ustaw HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds w rejestrze i uruchom ponownie proces W3WP.

• Jeśli zamapowany katalog fizyczny witryny sieci Web ma zagnieżdżonym strukturę katalogów, możesz spróbować ograniczyć zakres powiadomień o zmianie pliku, aby zmniejszyć liczbę powiadomień. Domyślnie usługi IIS używają konfiguracji z plików Web.config w katalogu fizycznym, do którego jest mapowany katalog wirtualny, a także w katalogach podrzędnych w tym katalogu fizycznym. Jeśli nie chcesz używać plików Web.config w katalogach podrzędnych, określ false atrybut allowSubDirConfig w katalogu wirtualnym. Więcej informacji można znaleźć tutaj.

  Ustaw ustawienie katalogu allowSubDirConfig wirtualnego usług IIS w pliku Web.Config , aby false wykluczyć zamapowane fizyczne katalogi podrzędne z zakresu.

Zobacz też

• Rozwiązywanie problemów z plikami platformy Azure
• Rozwiązywanie problemów z usługą Azure Files przez tworzenie alertów
• Informacje o wydajności usługi Azure Files
• Przegląd alertów na platformie Microsoft Azure
• Często zadawane pytania dotyczące usługi Azure Files

Skontaktuj się z nami, aby uzyskać pomoc

Jeśli masz pytania lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pomoc techniczną społeczności platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii na temat platformy Azure.