Dla wolnego dostępu do Azure Files przez VPN proponuje się dwie zmiany i skracają one różne rzeczy. Bufor metadanych po stronie usługi czyni kwalifikujące się operacje tańszymi dla serwera. Lokalny bufor oddziału przybliża bajty i operacje do użytkownika. Wybór między nimi na podstawie cennika lub komunikatu prasowego to droga, na której udział staje się szybszy w teście i niezmieniony o dziewiątej rano.

Dwa bufory, dwie różne latencje

Obie opcje pojawiają się pod słowem bufor i tam zaczyna się zamieszanie. Leżą po przeciwnych stronach sieci.

ChangeWhere it actsWhat it does not imply
Azure Files service metadata cachingThe service's handling of supported metadata operations on eligible sharesNo removal of the client's network round trips
A supported local server or cache designSome content and operations placed nearer the usersNo universal offline access or instant cross-site consistency
Application batching or limited copy concurrencyThe number and overlap of remote operationsNo automatic speedup for every workload

Przewodnik wydajności SMB firmy Microsoft opisuje buforowanie metadanych dla kwalifikujących się udziałów SSD wraz z towarzyszącym mu krokiem rejestracji. Kwalifikowalność i stan funkcji należą do rzeczywistego konta magazynu, więc czytaj bieżącą stronę, a nie zapowiedź wersji zapoznawczej sprzed dwóch lat.

Podziel oczekiwanie na trzy części

Każde wolne wyliczenie katalogu ma trzy składniki kosztu i reagują one na różne poprawki. Jest czas przetwarzania żądania po stronie usługi, liczba zależnych podróży w obie strony przez VPN i ładunek, który trzeba przenieść. Bufor po stronie usługi atakuje pierwszy. Nic po stronie serwera nie atakuje drugiego.

Dlatego udział może pokazywać lepsze metryki usługi, podczas gdy selektor plików użytkownika nadal wisi przez osiem sekund.

Gdzie każda opcja zasługuje na swoje miejsce

Jeśli obciążenie jest mocno metadanych, z wieloma otwarciami, wywołaniami stat i wyliczeniami katalogów wobec kwalifikującego się udziału SSD, buforowanie po stronie usługi jest tanim eksperymentem. Nie wymaga nowej infrastruktury ani zmiany sposobu, w jaki użytkownicy docierają do udziału.

Jeśli obciążenie jest interaktywne i ograniczone latencją, uczciwą opcją jest obsługiwany projekt lokalnego serwera z udokumentowanym modelem synchronizacji. To inna architektura z własnymi kosztami operacyjnymi, a nie przełącznik.

Czego nie zmienia żadna z opcji

Podpisywanie i szyfrowanie SMB nadal obowiązują i nadal kosztują tyle, ile kosztują. Kontrola dostępu nadal jest rozstrzygana dla każdego użytkownika, więc buforowana kopia nie upraszcza autoryzacji. Spójność między lokalizacjami nadal wymaga zdefiniowanego modelu, ponieważ lokalne odczyty w oddziale i zapisy po stronie chmury muszą się na czymś zgodzić. A dostęp offline pozostaje ustawieniem klienta, a nie skutkiem ubocznym funkcji serwera.

Kiedy ktoś obiecuje, że funkcja usługi usuwa podróże WAN w obie strony, to jest twierdzenie, które należy sprawdzić najpierw.

Mierz wobec operacji, na którą skarżą się użytkownicy

Zmierz czas dokładnej operacji, a nie syntetycznej kopii. Measure-Command { Get-ChildItem \\files\projects -Recurse } na kliencie oddziału daje liczbę, którą możesz porównać przed i po, a Get-SmbMultichannelConnection pokazuje, czy klient używa więcej niż jednej ścieżki. Postaw to obok metryk latencji po stronie usługi dla tego samego okna.

Utrzymuj udział, lokalizację klienta, ścieżkę VPN i politykę bezpieczeństwa na stałym poziomie, inaczej mierzysz swoje okno zmian, a nie funkcję. Zanotuj też liczbę plików i rozkład rozmiarów, ponieważ obciążenia małymi plikami i masowe kopie reagują na zupełnie inne dźwignie.

Wynik, który warto mieć, to zmiana dopasowana do granicy, która naprawdę była wolna, z zapisanymi kosztami operacyjnymi i kosztami spójności. Większa liczba IOPS magazynu na slajdzie nie jest tym wynikiem.

Powiązane artykuły