Osvědčené postupy pro automatické škálování

Článek
01/07/2024

Automatické škálování služby Azure Monitor se vztahuje pouze na Azure Virtual Machine Scale Sets, Azure Cloud Services, Web Apps funkci Azure App Service a Azure API Management.

Koncepty automatického škálování

Prostředek může mít jenom jedno nastavení automatického škálování.
Nastavení automatického škálování může mít jeden nebo více profilů a každý profil může mít jedno nebo více pravidel automatického škálování.
Nastavení automatického škálování škáluje instance horizontálně, což se provádí zvýšením počtu instancí a snížením počtu instancí.
Nastavení automatického škálování má maximální, minimální a výchozí hodnotu instancí.
Úloha automatického škálování vždy přečte přidruženou metriku, podle které se má škálovat, a kontroluje, jestli nedošlo k překročení nakonfigurované prahové hodnoty pro škálování na více nebo více instancí. Seznam metrik, podle kterého je možné automatické škálování škálovat, najdete v tématu Běžné metriky automatického škálování služby Azure Monitor.
Všechny prahové hodnoty se počítají na úrovni instance. Příkladem je horizontální navýšení kapacity o jednu instanci při průměrném využití procesoru > 80 %, když je počet instancí 2. To znamená škálování na více instancí, když je průměrné využití procesoru napříč všemi instancemi větší než 80 %.
Všechna selhání automatického škálování se protokolují do protokolu aktivit. Pak můžete nakonfigurovat upozornění protokolu aktivit , abyste byli upozorněni e-mailem, ZPRÁVAMI SMS nebo webhooky, kdykoli dojde k selhání automatického škálování.
Podobně se všechny úspěšné akce škálování publikují do protokolu aktivit. Pak můžete nakonfigurovat upozornění protokolu aktivit, abyste byli upozorněni prostřednictvím e-mailu, SMS nebo webhooků vždy, když dojde k úspěšné akci automatického škálování. Můžete také nakonfigurovat e-mailová oznámení nebo oznámení webhooku, abyste dostávali oznámení o úspěšných akcích škálování prostřednictvím karty oznámení v nastavení automatického škálování.

Osvědčené postupy automatického škálování

Při používání automatického škálování používejte následující osvědčené postupy.

Ujistěte se, že se maximální hodnota liší od minimální hodnoty a že mezi nimi je přiměřené rozpětí

Pokud máte nastavení, které má minimum=2, maximum=2 a aktuální počet instancí je 2, nemůže dojít k žádné akci škálování. Udržujte přiměřené rozpětí mezi maximálním a minimálním počtem instancí. Automatické škálování vždy provádí škálování mezi těmito limity.

Ruční škálování se resetuje na základě minimálního a maximálního automatického škálování

Pokud ručně aktualizujete počet instancí na hodnotu vyšší nebo nižší než maximum, modul automatického škálování automaticky škáluje zpět na minimum (pokud je nižší) nebo maximum (pokud je výše). Například nastavíte rozsah mezi 3 a 6. Pokud máte jednu spuštěnou instanci, modul automatického škálování se při dalším spuštění škáluje na tři instance. Podobně platí, že pokud ručně nastavíte škálování na osm instancí, při dalším spuštění se automatické škálování škáluje zpět na šest instancí při dalším spuštění. Ruční škálování je dočasné, pokud také nevynulujete pravidla automatického škálování.

Vždy používejte kombinaci pravidel horizontálního navýšení a snížení kapacity, která provádí zvýšení a snížení kapacity.

Pokud použijete jenom jednu část kombinace, provede automatické škálování akci pouze v jednom směru (horizontální navýšení nebo snížení kapacity), dokud nedosáhne maximálního nebo minimálního počtu instancí, jak je definováno v profilu. Tato situace není optimální. V ideálním případě chcete, aby váš prostředek v době vysokého využití škálovat na více instancí, aby se zajistila dostupnost. Podobně v době nízkého využití chcete, aby se váš prostředek škálovat, abyste mohli dosáhnout úspor nákladů.

Pokud používáte pravidlo horizontálního snížení kapacity a horizontálního navýšení kapacity, v ideálním případě použijte k řízení obojího stejnou metriku. Jinak je možné, že se podmínky horizontálního snížení kapacity a horizontálního navýšení kapacity můžou splnit současně a vést k určité úrovni flappingu. Například následující kombinaci pravidel nedoporučujeme, protože neexistuje žádné pravidlo škálování na více instancí pro využití paměti:

Pokud je využití procesoru > 90 %, horizontální navýšení kapacity o 1
Pokud paměť > je 90 %, horizontální navýšení kapacity o 1
Pokud je využití procesoru < 45 %, horizontální snížení kapacity o 1

V tomto příkladu může dojít k situaci, kdy využití paměti přesáhlo 90 %, ale využití procesoru je nižší než 45 %. Tento scénář může vést k flappingu, dokud jsou splněny obě podmínky.

Vyberte vhodnou statistiku pro konkrétní diagnostickou metriku

U diagnostických metrik si jako metriku pro škálování můžete vybrat mezi metrikami Průměr, Minimum, Maximum a Součet . Nejběžnější statistika je Průměr.

Důležité informace o prahových hodnotách škálování pro speciální metriky

U speciálních metrik, jako je metrika Azure Storage nebo délka fronty Azure Service Bus, je prahovou hodnotou průměrný počet zpráv dostupných na aktuální počet instancí. Pečlivě vyberte prahovou hodnotu pro tuto metriku.

Pojďme si to ukázat na příkladu, abyste lépe pochopili chování:

Zvýšení počtu instancí o 1, když počet >zpráv ve frontě úložiště = 50
Snížení počtu instancí o 1, pokud počet <zpráv ve frontě služby Storage = 10

Zvažte následující posloupnost:

Existují dvě instance fronty úložiště.
Zprávy stále přicházejí a když zkontrolujete frontu služby Storage, celkový počet přečte 50. Můžete předpokládat, že automatické škálování by mělo spustit akci horizontálního navýšení kapacity. Všimněte si ale, že stále platí 50/2 = 25 zpráv na instanci. Škálování na více instancí tedy nenastane. Aby se první akce škálování na více instancí proběhla, celkový počet zpráv ve frontě storage by měl být 100.
Dále předpokládejme, že celkový počet zpráv dosáhne 100.
Třetí instance fronty úložiště se přidá kvůli akci horizontálního navýšení kapacity. Další akce horizontálního navýšení kapacity neproběhne, dokud celkový počet zpráv ve frontě nedosáhne 150, protože 150/3 = 50.
Počet zpráv ve frontě se teď zmenší. U tří instancí dojde k první akci horizontálního snížení kapacity, když celkový počet zpráv ve všech frontách přidá až 30, protože 30/3 = 10 zpráv na instanci, což je prahová hodnota horizontálního snížení kapacity.

Důležité informace o škálování v případě více nakonfigurovaných pravidel v profilu

V některých případech může být nutné nastavit v profilu více pravidel. Při nastavení více pravidel používá modul automatického škálování následující pravidla automatického škálování:

Při škálování na více instancí se automatické škálování spustí, pokud je splněné nějaké pravidlo.
Při horizontálním snížení kapacity vyžaduje automatické škálování splnění všech pravidel.

Pro ilustraci předpokládejme, že máte čtyři pravidla automatického škálování:

Pokud je využití procesoru < 30 %, horizontální snížení kapacity o 1
Pokud paměť < 50 %, horizontální snížení kapacity o 1
Pokud je využití procesoru > 75 %, horizontální navýšení kapacity o 1
Pokud paměť > 75 %, horizontální navýšení kapacity o 1

Pak dojde k následující akci:

Pokud je využití procesoru 76 % a paměť 50 %, navyšujeme kapacitu.
Pokud je využití procesoru 50 % a paměť 76 %, kapacitu navyšujeme.

Na druhou stranu, pokud je procesor 25 % a paměť 51 %, automatické škálování neškálí . Pokud chcete škálovat na více instancí, procesor musí být 29 % a paměť 49 %.

Vždy vyberte bezpečný výchozí počet instancí

Výchozí počet instancí je důležitý, protože automatické škálování škáluje službu na tento počet, když metriky nejsou k dispozici. V důsledku toho vyberte výchozí počet instancí, který je pro vaše úlohy bezpečný.

Konfigurace oznámení automatického škálování

Automatické škálování odešle příspěvek do protokolu aktivit, pokud dojde k některé z následujících podmínek:

Automatické škálování vydává operaci škálování.
Služba automatického škálování úspěšně dokončí akci škálování.
Službě automatického škálování se nepodaří provést akci škálování.
Metriky nejsou k dispozici pro službu automatického škálování, aby se rozhodla o škálování.
Metriky jsou znovu k dispozici (obnovení), aby se bylo možné rozhodnout o škálování.
Automatické škálování detekuje flapping a přeruší pokus o škálování. V této situaci se zobrazí typ Flapping protokolu . Pokud se zobrazí tento typ protokolu, zvažte, jestli nejsou prahové hodnoty příliš úzké.
Automatické škálování detekuje flapping, ale stále dokáže úspěšně škálovat. V této situaci se zobrazí typ FlappingOccurred protokolu . Pokud se zobrazí tento typ protokolu, modul automatického škálování se pokusil škálovat (například ze čtyř instancí na dvě), ale zjistil, že tato změna způsobí flapping. Místo toho se modul automatického škálování škáloval na jiný počet instancí (například používá tři instance místo dvou), což už nezpůsobuje flapping, takže se škáloval na tento počet instancí.

K monitorování stavu modulu automatického škálování můžete také použít upozornění protokolu aktivit. Jeden příklad ukazuje, jak vytvořit upozornění protokolu aktivit pro monitorování všech operací modulu automatického škálování ve vašem předplatném. Další příklad ukazuje, jak vytvořit upozornění protokolu aktivit pro monitorování všech neúspěšných operací automatického škálování na více nebo více instancí ve vašem předplatném.

Kromě použití upozornění protokolu aktivit můžete také nakonfigurovat e-mailová oznámení nebo oznámení webhooku, aby dostávala oznámení o akcích škálování prostřednictvím karty oznámení v nastavení automatického škálování.

Bezpečné odesílání dat pomocí protokolu TLS 1.2

Pokud chcete zajistit zabezpečení přenášených dat do služby Azure Monitor, důrazně doporučujeme, abyste agenta nakonfigurovali tak, aby používal protokol TLS (Transport Layer Security) alespoň 1.2. Starší verze protokolu TLS/SSL (Secure Sockets Layer) byly zjištěny jako zranitelné. I když v současné době stále fungují tak, aby umožňovaly zpětnou kompatibilitu, nedoporučujeme je. Odvětví rychle opouští podporu těchto starších protokolů.

Rada PCI Security Standards Council stanovila termín na 30. června 2018, aby zakázala starší verze TLS/SSL a upgradovala na bezpečnější protokoly. Pokud vaši agenti nebudou moct komunikovat přes protokol TLS 1.2, nebudete moct posílat data do protokolů služby Azure Monitor, pokud Azure zahodí podporu starší verze.

Doporučujeme explicitně nenastavovat agenta tak, aby používal pouze protokol TLS 1.2, pokud to není nutné. Lepší je umožnit agentům automaticky zjišťovat, vyjednávat a využívat budoucí standardy zabezpečení. V opačném případě byste mohli přijít o přidané zabezpečení novějších standardů a případně narazit na problémy, pokud by se protokol TLS 1.2 někdy zastaral ve prospěch těchto novějších standardů.