Sdílet prostřednictvím


Škálování prostředků na flexibilním serveru Azure Database for PostgreSQL

PLATÍ PRO: Flexibilní server Azure Database for PostgreSQL

Flexibilní server Azure Database for PostgreSQL podporuje možnosti vertikálního i horizontálního škálování.

Vertikální škálování

Instanci můžete škálovat vertikálně přidáním dalších prostředků do instance flexibilního serveru Azure Database for PostgreSQL. Můžete zvýšit nebo snížit počet procesorů a paměti přiřazených k němu.

Propustnost sítě vaší instance závisí na hodnotách, které zvolíte pro procesor a paměť.

Po vytvoření instance flexibilního serveru Azure Database for PostgreSQL můžete nezávisle škálovat:

  • Úroveň výpočetních prostředků a skladová položka
  • Úroveň a velikost úložiště.
  • Doba uchovávání záloh.

Úroveň výpočetních prostředků je možné vertikálně navýšit nebo snížit mezi možností nárazového škálování, pro obecné účely a optimalizovánou pro paměť, aby se přizpůsobila potřebám vaší úlohy. V každé z těchto úrovní je k dispozici dostatek předem nakonfigurovaného hardwaru různých generací a s více nebo méně procesory a více nebo méně nainstalovanou pamětí. Mezi tímto širokým výběrem si můžete vybrat ten, který podporuje vaše požadavky na prostředky kdykoli a zároveň snížit provozní náklady a upravit je podle vašich potřeb.

Počet virtuálních jader a nainstalované paměti je možné vertikálně navýšit nebo snížit. Úroveň úložiště je také možné nakonfigurovat nahoru nebo dolů tak, aby vyhovovala požadavkům na propustnost a IOPS, které vaše úlohy vyžadují. Velikost úložiště je možné zvětšit pouze. V závislosti na vašich požadavcích můžete také prodloužit nebo snížit dobu uchovávání záloh mezi 7 a 35 dny.

Tyto prostředky je možné škálovat pomocí více rozhraní. Můžete například použít Azure Portal nebo Azure CLI.

Poznámka:

Po zvětšení velikosti úložiště přiřazeného k vaší instanci ji nemůžete zmenšit na menší velikost.

Horizontální škálování

Instanci můžete škálovat horizontálně vytvořením replik pro čtení. Repliky pro čtení umožňují škálovat úlohy čtení na samostatné instance flexibilního serveru Azure Database for PostgreSQL. Nemají vliv na výkon a dostupnost primární instance.

V horizontálně škálované instalaci lze také vertikálně škálovat primární instanci a repliky pro čtení.

Když změníte počet virtuálních jader nebo výpočetní úroveň, instance se restartuje, aby nový hardware přiřazený začal spouštět serverovou úlohu. Během této doby se systém přepne na nový typ serveru. Nelze navázat žádná nová připojení a všechny nepotvrzené transakce se vrátí zpět.

Celkový čas potřebný k restartování serveru závisí na procesu zotavení po havárii a aktivitě databáze v době restartování. Restartování obvykle trvá minutu nebo méně, ale může to být několik minut. Časování závisí na transakční aktivitě při zahájení restartování.

Pokud je vaše aplikace citlivá na ztrátu transakcí v letu, ke kterým může dojít během škálování výpočetních prostředků, doporučujeme implementovat model opakování transakce.

Škálování úložiště ve většině případů nevyžaduje restartování serveru. Další informace najdete v tématu Možnosti úložiště na flexibilním serveru Azure Database for PostgreSQL.

Změny doby uchovávání záloh jsou online operace.

Pokud chcete zkrátit dobu restartování, doporučujeme provádět operace škálování v době mimo špičku. Tento přístup zkracuje dobu potřebnou k restartování databázového serveru.

Škálování s téměř nulovými výpadky

Škálování téměř nulového výpadku je funkce navržená tak, aby minimalizovala výpadky při úpravě úrovní úložiště a výpočetních prostředků. Pokud upravíte počet virtuálních jader nebo změníte výpočetní úroveň, server projde restartováním, aby se použila nová konfigurace. Během tohoto přechodu na nový server není možné navázat žádná nová připojení.

Tento proces obvykle může trvat 2 až 10 minut s pravidelným škálováním. Díky funkci škálování téměř nulového výpadku se tato doba trvání zmenší na méně než 30 sekund. Toto snížení výpadku během škálování prostředků zlepšuje celkovou dostupnost vaší instance databáze.

Jak to funguje

Když aktualizujete instanci flexibilního serveru Azure Database for PostgreSQL ve scénářích škálování, služba pro váš server vytvoří nový virtuální počítač s aktualizovanou konfigurací. Pak se synchronizuje s virtuálním počítačem, na kterém právě běží vaše instance, a pak se přepne na nový s krátkou přerušením. Proces na pozadí pak eliminuje starý virtuální počítač. K tomuto procesu dochází bez dalších poplatků.

Tento proces umožňuje bezproblémové aktualizace a současně minimalizuje výpadky a zajišťuje nákladovou efektivitu. Tento proces škálování se aktivuje, když dojde ke změnám na úrovni úložiště a výpočetních prostředků. K použití této funkce není nutná žádná akce zákazníka.

U horizontálně škálovaných konfigurací, které se skládají z primárního serveru a jedné nebo více replik pro čtení, musí operace škálování dodržovat konkrétní sekvenci, aby se zajistila konzistence dat a minimalizovala prostoje. Podrobnosti o této sekvenci najdete v tématu Škálování pomocí replik pro čtení.

Poznámka:

Škálování téměř nulového výpadku je výchozím typem operace. Když dojde k následujícím omezením , systém se přepne na běžné škálování, což v porovnání se škálováním téměř nulového výpadku zahrnuje více výpadků.

Přesná očekávání výpadků

  • Doba trvání výpadku: Ve většině případů se výpadek pohybuje od 10 do 30 sekund.
  • Další aspekty: Po události škálování existuje období TTL (Inherent DNS Time-To-Live ) přibližně 30 sekund. Proces škálování neřídí toto období přímo. Jedná se o standardní součást chování DNS. Z hlediska aplikace může být celkový výpadek během škálování v rozsahu 40 až 60 sekund.

Úvahy a omezení

  • Aby škálování téměř nulového výpadku fungovalo, povolte při použití integrovaných sítí virtuální sítě všechna příchozí a odchozí připojení mezi IP adresami v delegované podsíti. Pokud tato připojení nejsou povolená, proces škálování téměř nulového výpadku nefunguje a škálování probíhá prostřednictvím standardního pracovního postupu škálování.
  • Škálování téměř nulového výpadku nefunguje, pokud ve vašem předplatném existují omezení regionální kapacity nebo limity kvót.
  • Škálování téměř nulového výpadku nefunguje u serveru repliky, protože je podporováno pouze na primárním serveru. U serverů repliky operace škálování automaticky prochází pravidelným procesem.
  • Škálování téměř nulového výpadku nefunguje, pokud server vložený do virtuální sítě nemá v delegované podsíti dostatek použitelných IP adres. Pokud máte samostatný server, je potřeba jedna další IP adresa. Pro instanci s povolenou vysokou dostupností jsou vyžadovány dvě další IP adresy.
  • Sloty logické replikace se během události převzetí služeb při selhání téměř nulového výpadku nezachovají. Pokud chcete udržovat sloty logické replikace a zajistit konzistenci dat po operaci škálování, použijte rozšíření pg_failover_slot . Další informace najdete v tématu povolení rozšíření pg_failover_slots v instanci flexibilního serveru.
  • Škálování téměř nulového výpadku nefunguje s nepřipojenými tabulkami. Pokud pro některá z vašich dat používáte nezalogované tabulky, přijdete o všechna data v těchto tabulkách po škálování téměř nulového výpadku.