Az Azure Analysis Services horizontális felskálázása

A horizontális felskálázással az ügyfél-lekérdezések több lekérdezésreplika között is eloszthatók a lekérdezéskészletben, így csökkentve a válaszidőt a magas lekérdezési számítási feladatok során. A feldolgozást a lekérdezéskészlettől is elkülönítheti, így biztosítva, hogy az ügyfél-lekérdezéseket ne befolyásolja hátrányosan a feldolgozási műveletek. A vertikális felskálázás konfigurálható az Azure Portalon vagy az Analysis Services REST API-val.

A horizontális felskálázás a Standard tarifacsomagú kiszolgálók esetében érhető el. Az egyes lekérdezésreplikák díjszabása megegyezik a kiszolgálóéval. Minden lekérdezésreplikát a kiszolgálóval megegyező régióban kell létrehozni. A konfigurálható lekérdezésreplikák számát az a régió korlátozza, amelyben a kiszolgáló található. További információ: Rendelkezésre állás régiónként. A vertikális felskálázás nem növeli a kiszolgáló számára rendelkezésre álló memória mennyiségét. A memória növeléséhez magasabb szintű csomagra kell váltania.

Miért érdemes felskálázni?

Egy tipikus kiszolgálótelepítésben egy kiszolgáló feldolgozási kiszolgálóként és lekérdezéskiszolgálóként is szolgál. Ha a kiszolgáló modelljeire irányuló ügyfél-lekérdezések száma meghaladja a kiszolgáló tervéhez tartozó lekérdezésfeldolgozási egységeket (QPU), vagy a modellfeldolgozás a magas lekérdezési számítási feladatokkal egy időben történik, a teljesítmény csökkenhet.

A horizontális felskálázással akár hét további lekérdezésreplika-erőforrással is létrehozhat lekérdezéskészletet (összesen nyolcat, beleértve az elsődleges kiszolgálót is). A lekérdezéskészlet replikáinak számát a QPU-igényeknek megfelelően skálázhatja a kritikus időszakokban, és bármikor elkülönítheti a feldolgozó kiszolgálót a lekérdezéskészlettől.

A lekérdezéskészletben található lekérdezésreplikák számától függetlenül a számítási feladatok nem lesznek elosztva a lekérdezésreplikák között. Az elsődleges kiszolgáló szolgál a feldolgozó kiszolgálóként. A lekérdezésreplikák csak az elsődleges kiszolgáló és a lekérdezéskészlet minden replikája között szinkronizált modelladatbázisok lekérdezéseit szolgálják ki.

A horizontális felskálázás akár öt percet is igénybe vehet, amíg az új lekérdezésreplikák növekményesen hozzáadva lesznek a lekérdezéskészlethez. Ha az összes új lekérdezésreplika működik, az új ügyfélkapcsolatok terhelése ki van osztva a lekérdezéskészlet erőforrásai között. A meglévő ügyfélkapcsolatok nem változnak az aktuálisan csatlakoztatott erőforrástól. A skálázás során a lekérdezéskészletből eltávolított lekérdezéskészlet-erőforrás meglévő ügyfélkapcsolatai megszakadnak. Az ügyfelek újra csatlakozhatnak egy fennmaradó lekérdezéskészlet-erőforráshoz.

Működés

Amikor először konfigurálja a horizontális felskálázást, a rendszer automatikusan szinkronizálja az elsődleges kiszolgálón lévő modelladatbázisokat egy új lekérdezéskészlet új replikáival. Az automatikus szinkronizálás csak egyszer történik. Az automatikus szinkronizálás során a rendszer az elsődleges kiszolgáló adatfájljait (a blobtárolóban inaktív állapotban titkosítva) egy második helyre másolja, a blobtárolóban pedig inaktív állapotban is titkosítja. A lekérdezéskészlet replikái ezután a második fájlkészletből származó adatokkal vannak hidratálva .

Bár az automatikus szinkronizálást csak akkor hajtja végre a rendszer, ha először skáláz fel egy kiszolgálót, manuális szinkronizálást is végrehajthat. A szinkronizálás biztosítja, hogy a lekérdezéskészlet replikáin lévő adatok megegyeznek az elsődleges kiszolgáló adataival. Amikor az elsődleges kiszolgálón feldolgoz (frissít) modelleket, szinkronizálást kell végrehajtani a feldolgozási műveletek befejezése után . Ez a szinkronizálás az elsődleges kiszolgáló blobtárolóban lévő fájljaiból a második fájlkészletbe másolja a frissített adatokat. A lekérdezéskészlet replikái ezután a Blob Storage második fájlkészletéből származó frissített adatokkal vannak hidratálva.

Ha egy későbbi horizontális felskálázási műveletet hajt végre, például a lekérdezéskészlet replikáinak számát 2-ről ötre növeli, az új replikákat a blobtároló második fájlkészletéből származó adatok hidratálják. Nincs szinkronizálás. Ha a horizontális felskálázás után szinkronizálást végez, a lekérdezéskészlet új replikái kétszer hidratálva lesznek – redundáns hidratálás. Egy későbbi vertikális felskálázási művelet végrehajtásakor fontos szem előtt tartani:

• A felskálázási művelet előtt végezzen szinkronizálást a hozzáadott replikák redundáns hidratálásának elkerülése érdekében. Az egyidejűleg futó egyidejű szinkronizálási és vertikális felskálázási műveletek nem engedélyezettek.

• A feldolgozási és a vertikális felskálázási műveletek automatizálása során fontos, hogy először az elsődleges kiszolgálón dolgozza fel az adatokat, majd hajtsa végre a szinkronizálást, majd hajtsa végre a vertikális felskálázási műveletet. Ez a sorozat minimális hatást biztosít a QPU-ra és a memóriaerőforrásokra.

• A horizontális felskálázási műveletek során a lekérdezéskészlet összes kiszolgálója, beleértve az elsődleges kiszolgálót is, ideiglenesen offline állapotban van.

• A szinkronizálás akkor is engedélyezett, ha nincsenek replikák a lekérdezéskészletben. Ha nulláról egy vagy több replikára skáláz fel új adatokat az elsődleges kiszolgálón végzett feldolgozási műveletből, először hajtsa végre a szinkronizálást replikák nélkül a lekérdezéskészletben, majd horizontális felskálázást. A horizontális felskálázás előtti szinkronizálás elkerüli az újonnan hozzáadott replikák redundáns hidratálását.

• Amikor töröl egy modelladatbázist az elsődleges kiszolgálóról, az nem törlődik automatikusan a lekérdezéskészlet replikáiból. Végre kell hajtania egy szinkronizálási műveletet a Sync-AzAnalysisServicesInstance PowerShell-paranccsal, amely eltávolítja az adott adatbázis fájlját vagy fájljait a replika megosztott blobtárhelyéről, majd törli a modelladatbázist a lekérdezéskészlet replikáiról. Annak megállapításához, hogy létezik-e modelladatbázis a lekérdezéskészlet replikáin, de nem az elsődleges kiszolgálón, győződjön meg arról, hogy a feldolgozó kiszolgáló elkülönítése a lekérdezési készlet beállításától igen értékre van-e állítva. Ezután az SQL Server Management Studio (SSMS) használatával csatlakozzon az elsődleges kiszolgálóhoz a :rw minősítő használatával, és ellenőrizze, hogy létezik-e az adatbázis. Ezután kapcsolódjon a lekérdezéskészlet replikáihoz úgy, hogy a :rw minősítő nélkül csatlakozik, hogy kiderüljön, ugyanaz az adatbázis is létezik-e. Ha az adatbázis a lekérdezéskészlet replikáin található, de nem az elsődleges kiszolgálón, futtasson szinkronizálási műveletet.

• Amikor átnevez egy adatbázist az elsődleges kiszolgálón, egy másik lépés szükséges annak biztosításához, hogy az adatbázis megfelelően szinkronizálva legyen a replikákkal. Az átnevezés után szinkronizálást hajt végre a Sync-AzAnalysisServicesInstance paranccsal, amely megadja a paramétert a -Database régi adatbázisnévvel. Ez a szinkronizálás eltávolítja a régi nevű adatbázist és fájlokat a replikákból. Ezután végezzen egy másik szinkronizálást, amely megadja a -Database paramétert az új adatbázis nevével. A második szinkronizálás az újonnan elnevezett adatbázist a második fájlkészletbe másolja, és hidratálja a replikákat. Ezek a szinkronizálások nem hajthatóak végre a Modell szinkronizálása parancs használatával a portálon.

Szinkronizálási mód

Alapértelmezés szerint a lekérdezésreplikák teljes mértékben rehidratálódnak, nem növekményesen. A rehidratálás fázisokban történik. A rendszer leválasztja őket, és egyszerre kettőhöz csatolja őket (feltételezve, hogy legalább három replika van), hogy legalább egy replika bármikor online állapotban legyen a lekérdezésekhez. Bizonyos esetekben előfordulhat, hogy az ügyfeleknek újra csatlakozniuk kell az egyik online replikához a folyamat során. A ReplicaSyncMode beállítással mostantól megadhatja, hogy a lekérdezésreplika szinkronizálása párhuzamosan történjen. A párhuzamos szinkronizálás a következő előnyöket nyújtja:

• A szinkronizálási idő jelentős csökkentése.
• A replikák adatai nagyobb valószínűséggel konzisztensek a szinkronizálási folyamat során.
• Mivel az adatbázisok online állapotúak maradnak minden replikán a szinkronizálási folyamat során, így az ügyfeleknek nem kell újracsatlakozniuk.
• A memóriabeli gyorsítótár növekményesen frissül csak a módosított adatokkal, ami gyorsabb lehet, mint a modell teljes rehidratálása.

A ReplicaSyncMode beállítása

A ReplicaSyncMode speciális tulajdonságokban való beállításához használja az SSMS-t. A lehetséges értékek a következők:

• 1 (alapértelmezett): Teljes replikaadatbázis rehidratációja szakaszokban (növekményes).
• 2: Optimalizált szinkronizálás párhuzamosan.

A ReplicaSyncMode=2 beállításakor a gyorsítótár frissítésének mennyiségétől függően a lekérdezésreplikák több memóriát használhatnak fel. Az adatbázis online állapotban tartásához és a lekérdezésekhez való rendelkezésre állásához – az adatok mennyiségétől függően – a művelet akár a replika memóriájának megduplázását is igényelheti, mivel a régi és az új szegmens is egyszerre marad a memóriában. A replikacsomópontok memóriakiosztása megegyezik az elsődleges csomópontéval, és általában extra memória van az elsődleges csomóponton a frissítési műveletekhez, ezért nem valószínű, hogy a replikák elfogynának a memóriájuk. Emellett a gyakori forgatókönyv az, hogy az adatbázis növekményesen frissül az elsődleges csomóponton, ezért a memória megduplázása nem kötelező. Ha a szinkronizálási művelet memóriakihasználtsági hibát tapasztal, újrapróbálkozás az alapértelmezett technikával (egyszerre kettő csatolása/leválasztása).

A feldolgozás elkülönítése a lekérdezéskészlettől

A feldolgozási és a lekérdezési műveletek maximális teljesítményéhez választhatja a feldolgozó kiszolgálót a lekérdezéskészlettől. Ha külön van választva, az új ügyfélkapcsolatok csak a lekérdezéskészlet lekérdezésreplikáihoz lesznek hozzárendelve. Ha a feldolgozási műveletek csak rövid időt vesznek igénybe, dönthet úgy, hogy a feldolgozási kiszolgálót csak annyi ideig választja el a lekérdezéskészlettől, amennyi a feldolgozási és szinkronizálási műveletek végrehajtásához szükséges, majd visszafoglalhatja a lekérdezéskészletbe. A feldolgozási kiszolgálónak a lekérdezéskészlettől való elkülönítése vagy a lekérdezéskészletbe való visszavétele akár öt percet is igénybe vehet a művelet befejezéséhez.

QPU-használat figyelése

Annak megállapításához, hogy szükséges-e a kiszolgáló vertikális felskálázása, figyelje a kiszolgálómetrikáit az Azure Portalon. Ha a QPU rendszeresen maximális, az azt jelenti, hogy a modelleken végzett lekérdezések száma meghaladja a csomag QPU-korlátját. A lekérdezéskészlet feladatsorhosszának metrikája akkor is nő, ha a lekérdezésszál-készlet várólistájában lévő lekérdezések száma meghaladja a rendelkezésre álló QPU-t.

Egy másik jó metrika az átlagos QPU a ServerResourceType szerint. Ez a metrika az elsődleges kiszolgáló átlagos QPU-értékét hasonlítja össze a lekérdezéskészlettel.

QPU konfigurálása ServerResourceType szerint

1. A Metrikák vonaldiagramon kattintson a Metrikák hozzáadása elemre.
2. Az ERŐFORRÁS területen válassza ki a kiszolgálót, majd a METRIC NAMESPACE-ben válassza az Analysis Services standard metrikáit, majd a METRIKában válassza a QPU, majd az AGGREGATION területen az Avg elemet.
3. Kattintson a Felosztás alkalmazása gombra.
4. Az ÉRTÉKEK területen válassza a ServerResourceType lehetőséget.

Részletes diagnosztikai naplózás

A kibővített kiszolgálói erőforrások részletesebb diagnosztikáihoz használja az Azure Monitor-naplókat. A naplókkal Log Analytics-lekérdezésekkel bonthatja ki a QPU-t és a memóriát kiszolgáló és replika szerint. További információ: Naplók elemzése a Log Analytics-munkaterületen. A lekérdezések például a Kusto-minta lekérdezések című témakörben olvashatók.

Horizontális felskálázás konfigurálása

Az Azure Portalon

1. A portálon kattintson a Felskálázás elemre. A csúszkával válassza ki a lekérdezésreplika-kiszolgálók számát. A kiválasztott replikák száma a meglévő kiszolgálón kívül van.

2. A feldolgozó kiszolgáló és a lekérdezési készlet elkülönítése esetén válassza az Igen lehetőséget a feldolgozó kiszolgáló lekérdezéskiszolgálókból való kizárásához. Az alapértelmezett kapcsolati sztring (anélkül:rw) használó ügyfélkapcsolatokat a rendszer átirányítja a lekérdezéskészlet replikáira.

   

3. Kattintson a Mentés gombra az új lekérdezésreplika-kiszolgálók kiépítéséhez.

Amikor először konfigurálja a kiszolgáló horizontális felskálázását, a rendszer automatikusan szinkronizálja az elsődleges kiszolgálón lévő modelleket a lekérdezéskészlet replikáival. Az automatikus szinkronizálás csak egyszer történik, amikor először konfigurálja a vertikális felskálázást egy vagy több replikára. Az ugyanazon a kiszolgálón található replikák számának későbbi módosítása nem indít el újabb automatikus szinkronizálást. Az automatikus szinkronizálás akkor sem fordul elő újra, ha a kiszolgálót nulla replikára állítja be, majd ismét felskálázza tetszőleges számú replikára.

Szinkronizálás

A szinkronizálási műveleteket manuálisan vagy a REST API használatával kell végrehajtani.

Az Azure Portalon

Az áttekintési> modell >szinkronizálási modelljében.

REST API

Használja a szinkronizálási műveletet.

Modell szinkronizálása

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

Szinkronizálás állapotának lekérése

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

Visszatérési állapotkódok:

Kód	Leírás
1-	Érvénytelen
0	Replikáló
0	Rehidratálás
2	Befejeződött
3	Sikertelen
4	Véglegesítése

PowerShell

Feljegyzés

Javasoljuk, hogy az Azure Az PowerShell modult használja az Azure-ral való interakcióhoz. Az első lépésekhez tekintse meg az Azure PowerShell telepítését ismertető szakaszt. Az Az PowerShell-modulra történő migrálás részleteiről lásd: Az Azure PowerShell migrálása az AzureRM modulból az Az modulba.

A PowerShell használata előtt telepítse vagy frissítse a legújabb Azure PowerShell-modult.

A szinkronizálás futtatásához használja a Sync-AzAnalysisServicesInstance parancsot.

A lekérdezésreplikák számának beállításához használja a Set-AzAnalysisServicesServer parancsot. Adja meg az opcionális -ReadonlyReplicaCount paramétert.

Ha el szeretné különíteni a feldolgozó kiszolgálót a lekérdezéskészlettől, használja a Set-AzAnalysisServicesServer parancsot. Adja meg a használni Readonlykívánt paramétert-DefaultConnectionMode.

További információ: Szolgáltatásnév használata az Az.AnalysisServices modullal.

Kapcsolatok

A kiszolgáló Áttekintés lapján két kiszolgálónév található. Ha még nem konfigurálta a vertikális felskálázást egy kiszolgálóhoz, mindkét kiszolgálónév ugyanúgy működik. Miután konfigurálta a kiszolgáló vertikális felskálázását, meg kell adnia a megfelelő kiszolgálónevet a kapcsolat típusától függően.

A végfelhasználói ügyfélkapcsolatok, például a Power BI Desktop, az Excel és az egyéni alkalmazások esetében használja a Kiszolgáló nevét.

A PowerShellben, az Azure Functions-alkalmazásokban és az AMO-ban található SSMS-, Visual Studio- és kapcsolati sztring esetén használja a felügyeleti kiszolgáló nevét. A felügyeleti kiszolgáló neve egy speciális :rw (olvasási-írási) minősítőt tartalmaz. Minden feldolgozási művelet az (elsődleges) felügyeleti kiszolgálón történik.

Vertikális felskálázás, leskálázás és vertikális felskálázás

Több replikával rendelkező kiszolgálón módosíthatja a tarifacsomagot. Ugyanez a tarifacsomag az összes replikára vonatkozik. A skálázási művelet először egyszerre összes replikát lehoz, majd az új tarifacsomag összes replikáját megjeleníti.

Hibaelhárítás

Probléma: A felhasználók hibaüzenetet kapnak, és nem találják a kiszolgáló "<A kiszolgáló> neve" példányát a "ReadOnly" kapcsolati módban.

Megoldás: Amikor kiválasztja a feldolgozó kiszolgáló elkülönítése a lekérdezési készlet beállítástól, a rendszer átirányítja az alapértelmezett kapcsolati sztring (anélkül:rw) használó ügyfélkapcsolatokat a lekérdezéskészlet replikáira. Ha a lekérdezéskészlet replikái még nem online állapotban vannak, mert a szinkronizálás még nem fejeződött be, az átirányított ügyfélkapcsolatok meghiúsulhatnak. A sikertelen kapcsolatok elkerülése érdekében szinkronizáláskor legalább két kiszolgálónak kell lennie a lekérdezéskészletben. A rendszer minden kiszolgálót külön szinkronizál, míg mások online állapotban maradnak. Ha úgy dönt, hogy a feldolgozás során nem rendelkezik a feldolgozó kiszolgálóval a lekérdezéskészletben, akkor dönthet úgy, hogy eltávolítja a készletből feldolgozás céljából, majd a feldolgozás befejezése után, de a szinkronizálás előtt visszaveszi a készletbe. Memória- és QPU-metrikák használatával monitorozza a szinkronizálás állapotát.

Kapcsolódó információk

Az Azure Analysis Servicesfelügyeletének monitorozása Az Azure Analysis Services kezelése