Skalowanie w poziomie usług Azure Analysis Services

W przypadku skalowania w poziomie zapytania klientów mogą być dystrybuowane między wieloma replikami zapytań w puli zapytań, co zmniejsza czas odpowiedzi podczas dużych obciążeń zapytań. Można również oddzielić przetwarzanie od puli zapytań, zapewniając, że zapytania klienta nie mają negatywnego wpływu na operacje przetwarzania. Skalowanie w poziomie można skonfigurować w Azure Portal lub przy użyciu interfejsu API REST usług Analysis Services.

Zwiększanie skali w poziomie jest dostępne dla serwerów w warstwie cenowej Standardowa. Każda replika zapytań jest rozliczana według tej samej stawki co serwer. Wszystkie repliki zapytań są tworzone w tym samym regionie co serwer. Liczba replik zapytań, które można skonfigurować, jest ograniczona przez region, w którym znajduje się serwer. Aby dowiedzieć się więcej, zobacz Dostępność według regionów. Zwiększanie skali w poziomie nie zwiększa ilości dostępnej pamięci dla serwera. Aby zwiększyć ilość pamięci, należy uaktualnić plan.

Dlaczego warto skalować w poziomie?

W typowym wdrożeniu serwera jeden serwer służy zarówno jako serwer przetwarzania, jak i serwer zapytań. Jeśli liczba zapytań klienta względem modeli na serwerze przekracza liczbę jednostek przetwarzania zapytań (QPU) dla planu serwera lub przetwarzanie modelu odbywa się w tym samym czasie co duże obciążenia zapytań, wydajność może się zmniejszyć.

W przypadku skalowania w poziomie można utworzyć pulę zapytań z maksymalnie siedmioma dodatkowymi zasobami repliki zapytań (łącznie z ośmioma sumami, w tym serwerem podstawowym ). Liczbę replik w puli zapytań można skalować w celu spełnienia wymagań QPU w krytycznym czasie i w dowolnym momencie można oddzielić serwer przetwarzania od puli zapytań.

Niezależnie od liczby replik zapytań, które znajdują się w puli zapytań, obciążenia przetwarzania nie są dystrybuowane między replikami zapytań. Serwer podstawowy służy jako serwer przetwarzania. Repliki zapytań obsługują tylko zapytania względem baz danych modelu synchronizowanych między serwerem podstawowym a każdą repliką w puli zapytań.

Podczas zwiększania skali w poziomie może upłynąć do pięciu minut zanim nowe repliki zapytań będą mogły zostać przyrostowo dodane do puli zapytań. Gdy wszystkie nowe repliki zapytań są uruchomione, nowe połączenia klienckie są równoważona obciążenia między zasobami w puli zapytań. Istniejące połączenia klienckie nie są zmieniane z zasobu, z którego są obecnie połączone. Podczas skalowania w poziomie wszystkie istniejące połączenia klienta z zasobem puli zapytań, które są usuwane z puli zapytań, są przerywane. Klienci mogą ponownie łączyć się z pozostałym zasobem puli zapytań.

Jak to działa

Podczas konfigurowania skalowania w poziomie po raz pierwszy bazy danych modelu na serwerze podstawowym są automatycznie synchronizowane z nowymi replikami w nowej puli zapytań. Automatyczna synchronizacja odbywa się tylko raz. Podczas automatycznej synchronizacji pliki danych serwera podstawowego (zaszyfrowane w spoczynku w magazynie obiektów blob) są kopiowane do drugiej lokalizacji, również szyfrowane w magazynie obiektów blob. Repliki w puli zapytań są następnie nawodnione danymi z drugiego zestawu plików.

Podczas gdy automatyczna synchronizacja jest wykonywana tylko w przypadku skalowania serwera w poziomie po raz pierwszy, można również wykonać synchronizację ręczną. Synchronizacja zapewnia, że dane replik w puli zapytań są zgodne z serwerem podstawowym. Podczas przetwarzania (odświeżania) modeli na serwerze podstawowym należy przeprowadzić synchronizację po zakończeniu operacji przetwarzania. Ta synchronizacja kopiuje zaktualizowane dane z plików serwera podstawowego w magazynie obiektów blob do drugiego zestawu plików. Repliki w puli zapytań są następnie nawodnione ze zaktualizowanymi danymi z drugiego zestawu plików w magazynie obiektów blob.

Podczas wykonywania kolejnej operacji skalowania w poziomie, na przykład zwiększenie liczby replik w puli zapytań z dwóch do pięciu, nowe repliki są nawodnione z danych z drugiego zestawu plików w magazynie obiektów blob. Brak synchronizacji. Jeśli następnie wykonasz synchronizację po przeskalowaniu w górę, nowe repliki w puli zapytań zostaną nawodnione dwa razy — nadmiarowe nawodnienie. Podczas wykonywania kolejnej operacji skalowania w poziomie należy pamiętać o:

• Wykonaj synchronizację przed operacją skalowania w poziomie , aby uniknąć nadmiarowego nawodnienia dodanych replik. Synchronizacja współbieżna i operacje skalowania w poziomie uruchomione w tym samym czasie nie są dozwolone.

• Podczas automatyzowania operacji przetwarzania i skalowania w poziomie ważne jest, aby najpierw przetwarzać dane na serwerze podstawowym, a następnie przeprowadzić synchronizację, a następnie wykonać operację skalowania w poziomie. Ta sekwencja zapewnia minimalny wpływ na zasoby QPU i pamięci.

• Podczas operacji skalowania w poziomie wszystkie serwery w puli zapytań, w tym serwer podstawowy, są tymczasowo w trybie offline.

• Synchronizacja jest dozwolona nawet wtedy, gdy w puli zapytań nie ma replik. Jeśli skalujesz z zera do co najmniej jednej repliki z nowymi danymi z operacji przetwarzania na serwerze podstawowym, najpierw przeprowadź synchronizację bez replik w puli zapytań, a następnie przeprowadź skalowanie w poziomie. Synchronizacja przed skalowaniem wyprzedaży pozwala uniknąć nadmiarowego nawodnienia nowo dodanych replik.

• Podczas usuwania bazy danych modelu z serwera podstawowego nie jest ona automatycznie usuwana z replik w puli zapytań. Należy wykonać operację synchronizacji przy użyciu polecenia Sync-AzAnalysisServicesInstance programu PowerShell, które usuwa pliki dla tej bazy danych z udostępnionej lokalizacji magazynu obiektów blob repliki, a następnie usuwa bazę danych modelu na replikach w puli zapytań. Aby określić, czy baza danych modelu istnieje na replikach w puli zapytań, ale nie na serwerze podstawowym, upewnij się, że ustawienie Rozdziel serwer przetwarzania z puli zapytań ma wartość Tak. Następnie użyj programu SSMS, aby nawiązać połączenie z serwerem podstawowym przy użyciu :rw kwalifikatora, aby sprawdzić, czy baza danych istnieje. Następnie połącz się z replikami w puli zapytań, łącząc się bez :rw kwalifikatora, aby sprawdzić, czy ta sama baza danych również istnieje. Jeśli baza danych istnieje na replikach w puli zapytań, ale nie na serwerze podstawowym, uruchom operację synchronizacji.

• Podczas zmieniania nazwy bazy danych na serwerze podstawowym istnieje dodatkowy krok niezbędny do zapewnienia prawidłowej synchronizacji bazy danych z dowolnymi replikami. Po zmianie nazwy wykonaj synchronizację przy użyciu polecenia Sync-AzAnalysisServicesInstance określającego -Database parametr ze starą nazwą bazy danych. Ta synchronizacja usuwa bazę danych i pliki ze starą nazwą z dowolnych replik. Następnie wykonaj kolejną synchronizację określającą -Database parametr z nową nazwą bazy danych. Druga synchronizacja kopiuje nowo nazwaną bazę danych do drugiego zestawu plików i nawilża wszystkie repliki. Tych synchronizacji nie można wykonać za pomocą polecenia Synchronizuj model w portalu.

Tryb synchronizacji

Domyślnie repliki zapytań są ponownie wypełnianie, a nie przyrostowo. Ponowne wypełnianie odbywa się na etapach. Są one odłączone i dołączone dwa naraz (przy założeniu, że istnieją co najmniej trzy repliki), aby zapewnić, że co najmniej jedna replika jest przechowywana w trybie online dla zapytań w danym momencie. W niektórych przypadkach klienci mogą wymagać ponownego nawiązania połączenia z jedną z replik online podczas wykonywania tego procesu. Za pomocą ustawienia ReplicaSyncMode można teraz określić synchronizację repliki zapytań odbywa się równolegle. Synchronizacja równoległa zapewnia następujące korzyści:

• Znaczny spadek czasu synchronizacji.
• Dane między replikami są bardziej prawdopodobne, aby były spójne podczas procesu synchronizacji.
• Ponieważ bazy danych są przechowywane w trybie online we wszystkich replikach w całym procesie synchronizacji, klienci nie muszą ponownie się łączyć.
• Pamięć podręczna w pamięci jest aktualizowana przyrostowo tylko przy użyciu zmienionych danych, co może być szybsze niż pełne wypełnianie modelu.

Ustawianie funkcji ReplicaSyncMode

Użyj programu SSMS, aby ustawić wartość ReplicaSyncMode we właściwościach zaawansowanych. Możliwe wartości są następujące:

• 1 (wartość domyślna): ponowne wypełnianie pełnej bazy danych repliki na etapach (przyrostowe).
• 2: zoptymalizowana synchronizacja równolegle.

Podczas ustawiania parametru ReplicaSyncMode=2, w zależności od ilości pamięci podręcznej, dodatkowa pamięć może być zużywana przez repliki zapytań. Aby zachować bazę danych w trybie online i dostępną dla zapytań, w zależności od tego, ile danych uległo zmianie, operacja może wymagać maksymalnie dwukrotnego podwojenia pamięci repliki, ponieważ zarówno stare, jak i nowe segmenty są przechowywane w pamięci jednocześnie. Węzły repliki mają tę samą alokację pamięci co węzeł podstawowy i zwykle w węźle podstawowym jest dodatkowa pamięć na potrzeby operacji odświeżania, więc może być mało prawdopodobne, że repliki zabraknie pamięci. Ponadto typowym scenariuszem jest to, że baza danych jest przyrostowo aktualizowana w węźle podstawowym, dlatego wymaganie dotyczące dwukrotnego podwojenia pamięci powinno być rzadkie. Jeśli operacja synchronizacji napotka błąd braku pamięci, spróbuje ponownie użyć domyślnej techniki (dołączanie/odłączanie dwóch naraz).

Oddzielenie przetwarzania od puli zapytań

Aby uzyskać maksymalną wydajność operacji przetwarzania i wykonywania zapytań, możesz oddzielić serwer przetwarzania od puli zapytań. Po oddzieleniu nowe połączenia klienta są przypisywane tylko do replik zapytań w puli zapytań. Jeśli operacje przetwarzania zajmują tylko krótki czas, możesz oddzielić serwer przetwarzania od puli zapytań tylko przez czas potrzebny do wykonania operacji przetwarzania i synchronizacji, a następnie dołączyć go z powrotem do puli zapytań. W przypadku oddzielenia serwera przetwarzania z puli zapytań lub ponowne dodanie go do puli zapytań może potrwać do pięciu minut, aby operacja została ukończona.

Monitorowanie użycia funkcji QPU

Aby określić, czy serwer jest skalowany w poziomie, należy monitorować serwer w Azure Portal przy użyciu metryk. Jeśli QPU regularnie się maksymatuje, oznacza to, że liczba zapytań względem modeli przekracza limit QPU dla planu. Metryka długości kolejki zadań puli zapytań zwiększa się również, gdy liczba zapytań w kolejce puli wątków zapytania przekracza dostępną jednostki QPU.

Kolejną dobrą metryczką do watch jest średnia wartość QPU według parametru ServerResourceType. Ta metryka porównuje średnią QPU dla serwera podstawowego z pulą zapytań.

Aby skonfigurować QPU według parametru ServerResourceType

1. Na wykresie liniowym Metryki kliknij pozycję Dodaj metrykę.
2. W obszarze ZASÓB wybierz serwer, a następnie w obszarze METRYKA PRZESTRZEŃ NAZW wybierz pozycję Metryki standardowe usług Analysis Services, a następnie w obszarze METRYKA wybierz pozycję QPU, a następnie w obszarze AGREGACJA wybierz pozycję Średnia.
3. Kliknij pozycję Zastosuj dzielenie.
4. W obszarze WARTOŚCI wybierz pozycję ServerResourceType.

Szczegółowe rejestrowanie diagnostyczne

Użyj dzienników usługi Azure Monitor, aby uzyskać bardziej szczegółową diagnostykę skalowanych zasobów serwera w poziomie. Za pomocą dzienników można użyć zapytań usługi Log Analytics, aby rozbić QPU i pamięć według serwera i repliki. Aby dowiedzieć się więcej, zobacz przykładowe zapytania w rejestrowaniu diagnostycznym usług Analysis Services.

Konfigurowanie zwiększania skali w poziomie

W Azure Portal

1. W portalu kliknij pozycję Skaluj w poziomie. Użyj suwaka, aby wybrać liczbę serwerów repliki zapytań. Liczba wybieranych replik jest dodatkiem do istniejącego serwera.

2. W obszarze Oddziel serwer przetwarzania od puli zapytań wybierz pozycję Tak, aby wykluczyć serwer przetwarzania z serwerów zapytań. Połączenia klienta przy użyciu domyślnych parametrów połączenia (bez :rw) są przekierowywane do replik w puli zapytań.

   

3. Kliknij przycisk Zapisz , aby aprowizować nowe serwery repliki zapytań.

Podczas konfigurowania skalowania w poziomie dla serwera po raz pierwszy modele na serwerze podstawowym są automatycznie synchronizowane z replikami w puli zapytań. Automatyczna synchronizacja odbywa się tylko raz, gdy najpierw skonfigurujesz skalowanie w poziomie do co najmniej jednej repliki. Kolejne zmiany liczby replik na tym samym serwerze nie będą wyzwalać kolejnej automatycznej synchronizacji. Automatyczna synchronizacja nie nastąpi ponownie, nawet jeśli serwer zostanie ustawiony na zero replik, a następnie ponownie przeprowadź skalowanie w poziomie do dowolnej liczby replik.

Synchronizowanie

Operacje synchronizacji muszą być wykonywane ręcznie lub przy użyciu interfejsu API REST.

W Azure Portal

W obszarze Przegląd> model Synchronizuj model>.

Interfejs API REST

Użyj operacji synchronizacji .

Synchronizowanie modelu

POST https://<region>.asazure.windows.net/servers/<servername>:rw/models/<modelname>/sync

Pobieranie stanu synchronizacji

GET https://<region>.asazure.windows.net/servers/<servername>/models/<modelname>/sync

Kody stanu powrotu:

Kod	Opis
-1	Nieprawidłowy
0	Replikowanie
1	Ponowne wypełnianie
2	Ukończone
3	Niepowodzenie
4	Finalizacji

PowerShell

Uwaga

Zalecamy korzystanie z modułu Azure Az programu PowerShell do interakcji z platformą Azure. Zobacz Instalowanie programu Azure PowerShell, aby rozpocząć. Aby dowiedzieć się, jak przeprowadzić migrację do modułu Az PowerShell, zobacz Migracja programu Azure PowerShell z modułu AzureRM do modułu Az.

Przed rozpoczęciem korzystania z programu PowerShell zainstaluj lub zaktualizuj najnowszy moduł Azure PowerShell.

Aby uruchomić synchronizację, użyj polecenia Sync-AzAnalysisServicesInstance.

Aby ustawić liczbę replik zapytań, użyj polecenia Set-AzAnalysisServicesServer. Określ opcjonalny -ReadonlyReplicaCount parametr.

Aby oddzielić serwer przetwarzania od puli zapytań, użyj polecenia Set-AzAnalysisServicesServer. Określ opcjonalny -DefaultConnectionMode parametr do użycia .Readonly

Aby dowiedzieć się więcej, zobacz Using a service principal with the Az.AnalysisServices module (Korzystanie z jednostki usługi za pomocą modułu Az.AnalysisServices).

Połączenia

Na stronie Przegląd serwera znajdują się dwie nazwy serwerów. Jeśli nie skonfigurowano jeszcze skalowania w poziomie dla serwera, obie nazwy serwerów działają tak samo. Po skonfigurowaniu skalowania w poziomie dla serwera należy określić odpowiednią nazwę serwera w zależności od typu połączenia.

W przypadku połączeń klienckich użytkowników końcowych, takich jak Power BI Desktop, Excel i aplikacje niestandardowe, użyj nazwy serwera.

W przypadku programów SSMS, Visual Studio i parametrów połączenia w programie PowerShell, aplikacjach funkcji platformy Azure i funkcji platformy Azure użyj nazwy serwera zarządzania. Nazwa serwera zarządzania zawiera specjalny :rw kwalifikator (odczyt-zapis). Wszystkie operacje przetwarzania są wykonywane na serwerze zarządzania (podstawowym).

Skalowanie w górę, skalowanie w dół a skalowanie w poziomie

Możesz zmienić warstwę cenową na serwerze z wieloma replikami. Ta sama warstwa cenowa ma zastosowanie do wszystkich replik. Operacja skalowania najpierw obniży wszystkie repliki jednocześnie, a następnie wyświetli wszystkie repliki w nowej warstwie cenowej.

Rozwiązywanie problemów

Problem: Użytkownicy otrzymują błąd Nie można odnaleźć serwera "<Nazwa serwera>" w trybie połączenia "ReadOnly".

Rozwiązanie: Podczas wybierania opcji Oddziel serwer przetwarzania od puli zapytań połączenia klienckie przy użyciu domyślnych parametrów połączenia (bez :rw) są przekierowywane do replik puli zapytań. Jeśli repliki w puli zapytań nie są jeszcze w trybie online, ponieważ synchronizacja nie została jeszcze ukończona, przekierowane połączenia klienckie mogą zakończyć się niepowodzeniem. Aby zapobiec nieudanym połączeniom, w puli zapytań musi znajdować się co najmniej dwa serwery podczas przeprowadzania synchronizacji. Każdy serwer jest synchronizowany indywidualnie, podczas gdy inne pozostają w trybie online. Jeśli nie masz serwera przetwarzania w puli zapytań podczas przetwarzania, możesz usunąć go z puli do przetwarzania, a następnie dodać go z powrotem do puli po zakończeniu przetwarzania, ale przed synchronizacją. Monitorowanie stanu synchronizacji za pomocą metryk pamięci i QPU.

Informacje pokrewne

Monitorowanie metryk serwera
Zarządzanie usługami Azure Analysis Services