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

Článek
11/07/2024

Automatické škálování služby Azure Monitor platí jenom pro škálovací sady virtuálních počítačů Azure, Azure Cloud Services, funkci Web Apps služby Aplikace Azure a Azure API Management.

Koncepty automatického škálování

Prostředek může mít pouze 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ž je horizontální navýš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 čte přidruženou metriku ke škálování tím, že kontroluje, jestli překročila nakonfigurovanou prahovou hodnotu pro horizontální navýšení kapacity nebo horizontální navýšení kapacity. Seznam metrik, které se dají automaticky škálovat, můžete zobrazit na základě běžných metrik 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 v případě průměrného využití procesoru > 80 %, když je počet instancí 2. To znamená horizontální navýšení kapacity, pokud je průměrný procesor ve všech instancích větší než 80 %.
Všechna selhání automatického škálování se protokolují do protokolu aktivit. Upozornění protokolu aktivit pak můžete nakonfigurovat tak, abyste byli upozorněni prostřednictvím e-mailu, SMS nebo webhooků, kdykoli dojde k selhání automatického škálování.
Podobně se všechny úspěšné akce škálování publikují do protokolu aktivit. Upozornění protokolu aktivit pak můžete nakonfigurovat tak, abyste byli upozorněni prostřednictvím e-mailu, SMS nebo webhooků, kdykoli dojde k úspěšné akci automatického škálování. Oznámení e-mailu nebo webhooku můžete také nakonfigurovat tak, aby dostávala 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žití automatického škálování použijte 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í s minimální hodnotou=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 minimálním a maximálním automatickým škálováním.

Pokud ručně aktualizujete počet instancí na hodnotu vyšší nebo nižší než maximum, modul automatického škálování se 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 příštím spuštění škáluje na tři instance. Podobně platí, že pokud škálovací kapacitu nastavíte ručně na osm instancí, při příštím spuštění automatického škálování se škáluje zpět na šest instancí při dalším spuštění. Ruční škálování je dočasné, pokud také resetujete pravidla automatického škálování.

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

Pokud používáte pouze jednu část kombinace, automatické škálování provede akci pouze v jednom směru (horizontální navýšení kapacity nebo v), 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 se váš prostředek škálovat v době vysokého využití, 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 stejnou metriku k řízení obou. V opačném případě je možné, že podmínky horizontálního snížení kapacity a horizontálního navýšení kapacity mohou být splněny současně a vést k určité úrovni prolnutí. Nedoporučujeme například následující kombinaci pravidel, protože pro využití paměti neexistuje žádné pravidlo škálování:

Pokud procesor > 90 %, vertikálně navyšte kapacitu o 1
Pokud paměť > 90 %, horizontální navýšení kapacity o 1
Pokud procesor < 45 %, vertikálně navyšte kapacitu o 1

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

Vyberte vhodnou statistiku pro konkrétní diagnostickou metriku

U diagnostických metrik můžete jako metriku pro škálování vybrat metriku Průměr, Minimum, Maximum a Total . Nejběžnější statistikou je Průměr.

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

Pro speciální metriky, jako je metrika délky fronty Azure Storage nebo Azure Service Bus, představuje prahová hodnota průměrný počet zpráv dostupných pro aktuální počet instancí. Pečlivě zvolte prahovou hodnotu pro tuto metriku.

Pojďme to ilustrovat příkladem, abyste lépe pochopili chování:

Zvýšení počtu instancí o 1 počet zpráv >fronty úložiště = 50
Snížení počtu instancí o 1 počet zpráv fronty <úložiště = 10

Vezměte v úvahu 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 zahájit akci horizontálního navýšení kapacity. Všimněte si ale, že je stále 50/2 = 25 zpráv na instanci. Horizontální navýšení kapacity se tedy neprojeví. Aby k první akci horizontálního navýšení kapacity došlo, celkový počet zpráv ve frontě úložiště 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á z důvodu akce horizontálního navýšení kapacity. Další akce horizontálního navýšení kapacity se nestane, dokud celkový počet zpráv ve frontě nedosáhne 150, protože 150/3 = 50.
Počet zpráv ve frontě je teď menší. U tří instancí se první akce horizontálního snížení kapacity provede, když celkové zprávy ve všech frontách sečtou 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

Existují případy, kdy možná budete muset nastavit více pravidel v profilu. Následující pravidla automatického škálování používá modul automatického škálování, když je nastaveno více pravidel:

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

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

Pokud procesor < 30 %, vertikálně navyšte kapacitu o 1
Pokud paměť < 50 %, vertikálně navyšte kapacitu o 1
Pokud procesor > 75 %, vertikálně navyšte kapacitu o 1
Pokud paměť > 75 %, horizontální navýšení kapacity o 1

Pak dojde k následující akci:

Pokud je procesor 76 % a paměť je 50 %, škálujeme kapacitu.
Pokud je procesor 50 % a paměť je 76 %, škálujeme kapacitu.

Na druhou stranu platí, že pokud je procesor 25 % a paměť je 51 %, automatické škálování se neškálí . Aby bylo možné kapacitu škálovat, 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 vaši službu na tento počet, pokud metriky nejsou dostupné. 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í příspěvků do protokolu aktivit, pokud dojde k některé z následujících podmínek:

Automatické škálování vystavuje 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 bylo možné provést rozhodnutí o škálování.
Metriky jsou opět k dispozici (obnovení), aby bylo možné provést rozhodnutí 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 jsou 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 by způsobila flapping. Místo toho se modul automatického škálování škáloval na jiný počet instancí (například pomocí tří instancí místo dvou), což už nezpůsobí flapping, takže se škálovalo na tento počet instancí.

K monitorování stavu modulu automatického škálování můžete použít také 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í horizontálního škálování nebo horizontálního navýšení kapacity ve vašem předplatném.

Kromě upozornění protokolu aktivit můžete také nakonfigurovat e-mailová nebo webhooká oznámení, aby se prostřednictvím karty oznámení na kartě oznámení v nastavení automatického škálování zobrazovala oznámení.

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

Abychom zajistili zabezpečení přenášených dat do služby Azure Monitor, důrazně doporučujeme, abyste agenta nakonfigurovali tak, aby používal alespoň TLS (Transport Layer Security) 1.2. Starší verze protokolu TLS/Secure Sockets Layer (SSL) byly ohroženy. I když stále fungují tak, aby umožňovaly zpětnou kompatibilitu, nedoporučujeme je. Odvětví rychle přechází na opuštění podpory těchto starších protokolů.

Rada bezpečnostních standardů PCI nastavila lhůtu 30. června 2018, aby zakázala starší verze protokolu TLS/SSL a upgradovala na bezpečnější protokoly. Pokud vaši agenti nebudou moct komunikovat přes protokol TLS 1.2, nebudete moct odesílat data do protokolů služby Azure Monitor.

Doporučujeme, abyste agenta explicitně nenastavili tak, aby používal pouze protokol TLS 1.2, pokud to není nutné. Lepší je umožnit agentu automaticky zjišťovat, vyjednávat a využívat budoucí standardy zabezpečení. V opačném případě můžete vynechat přidané zabezpečení novějších standardů a případně se setkáte s problémy, pokud je protokol TLS 1.2 někdy zastaralý ve prospěch těchto novějších standardů.

Sdílet prostřednictvím