Nyní, když jsou skupiny dostupnosti stále více rozšířené, myslel jsem si, že se budu věnovat tématu, které může být při počátečním plánování a instalaci SQL Serveru v tomto typu prostředí přehlédnuto. Aby byla konfigurace skutečně odolná vůči chybám, je třeba do nastavení databázové konektivity zapojit určité myšlenky a plánování.
V tomto příspěvku se nebudu zabývat podrobnostmi nastavení vašeho prostředí AlwaysOn, ale pro další pomoc vám doporučuji podívat se na příspěvek Aarona Bertranda „Odstraňování problémů AlwaysOn – někdy to vyžaduje mnoho očí.“ Jakmile je vaše prostředí nakonfigurováno, dalším krokem při poskytování připojení k databázi je vytvoření modulu pro naslouchání skupin dostupnosti pomocí SQL Management Studio nebo T-SQL:
ALTER AVAILABILITY GROUP [GroupName] ADD LISTENER N'ListenerName' (WITH IP ((N'10.x.x.x', N'255.255.255.0')), PORT=1433);
Řetězce připojení AG Listener
Váš název virtuální sítě (VNN) je registrován v DNS a je vždy vlastněn instancí SQL Server, kde se nachází primární replika. Všechny IP adresy zadané při konfiguraci AG Listeneru jsou registrovány v DNS pod stejným názvem virtuální sítě.
Po vytvoření AG Listeneru se musíte ujistit, že se vaši klienti mohou připojit. Vaše připojení k aplikaci funguje stejným způsobem jako vždy, ale místo toho, abyste směřovali na konkrétní server v řetězci připojení, ukazujete na AG Listener.
AG Listenery lze připojit pouze pomocí TCP a jsou přeloženy vaším místním DNS na seznam IP adres a TCP portů, které jsou mapovány na VNN. Váš klient se bude postupně pokoušet připojit ke každé z IP adres, dokud buď nezíská připojení, nebo dokud nevyprší časový limit připojení. Důležitým parametrem připojovacího řetězce, který je třeba zvážit, je MultiSubnetFailover. Pokud je tento parametr nastaven na hodnotu true, klient se pokusí o připojení paralelně, což umožní rychlejší připojení a v případě potřeby rychlejší převzetí služeb při selhání klienta:
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True
Když dojde k převzetí služeb při selhání, připojení klientů se resetují a vlastnictví AG Listener se přesune do instance SQL Server, která převezme roli primární repliky. Koncový bod VNN je pak svázán s novými adresami IP a porty TCP nové instance primární repliky. V závislosti na klientovi dojde k automatickému opětovnému připojení k AG nebo může uživatel muset ručně restartovat postiženou aplikaci nebo připojení.
Aplikační záměr
Jedním z největších důvodů, proč implementovat skupiny dostupnosti, je poskytnout možnost využít vaše prostředí zálohování nebo obnovy po havárii k přesunu práce z vašeho produkčního prostředí. Tyto servery lze nyní používat pro zálohování, analýzu, ad-hoc dotazy a sestavování nebo pro jakoukoli jinou operaci, při které stačí mít kopii databáze pouze pro čtení.
Chcete-li poskytnout přístup pouze pro čtení k vašim sekundárním replikám, používá se parametr připojovacího řetězce ApplicationIntent. Na každé replice lze nakonfigurovat volitelný seznam směrování pouze pro čtení koncových bodů SQL Server. Tento seznam se používá k přesměrování požadavků na připojení klienta, které používají parametr ApplicationIntent=ReadOnly, na první dostupnou sekundární repliku, která byla nakonfigurována pomocí vhodného filtru záměru aplikace.
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True;ApplicationIntent=ReadOnly;
Filtrování záměrů aplikace
Pro usnadnění Application Intent od klientů, kteří se připojují k vaší skupině dostupnosti, by měla být každá instance SQL Server ve skupině nakonfigurována s vhodným filtrem Application Intent Filter. Filtr určuje, jaké typy připojení každá replika přijme.
Primární replika, která je nakonfigurována tak, aby měla připojení v primární roli „Povolit všechna připojení“, bude přijímat všechna připojení vytvořená prostřednictvím AG Listeneru. Primární replika nakonfigurovaná jako „Povolit připojení pro čtení/zápis“ odmítne všechna připojení, která specifikují „ApplicationIntent=ReadOnly“.
Při konfiguraci replik musíte také definovat, zda každá bude či nebude čitelnou sekundární. Replika, která je nakonfigurována jako „Ne“, odmítne všechna připojení. Předpokládá se, že tato replika bude použita pouze pro převzetí služeb při selhání v situaci zotavení po havárii. Pokud je sekundární replika nakonfigurována jako „Ano“, budou povolena všechna připojení, ale pouze pro přístup pro čtení, i když není zadáno „ApplicationIntent=ReadOnly“. Konečně, pokud je sekundární nakonfigurován jako „Intent pouze pro čtení“, budou se moci připojit pouze klienti, kteří specifikují „ApplicationIntent=ReadOnly“.
Směrování pouze pro čtení
Nyní, když víme, jak nakonfigurovat Application Intent na instancích serveru, a vytvořit potřebné připojovací řetězce, musíme nakonfigurovat směrování skupiny dostupnosti pouze pro čtení. Když se připojíte k AG Listener pomocí připojovacího řetězce, jak je definováno výše, posluchač se dotáže na primární instanci repliky a určí, zda má být připojení vytvořeno k primární (čtení/zápis) nebo k sekundární pouze pro čtení. Aby toho bylo dosaženo, musí být vytvořen seznam směrování pro KAŽDOU repliku dostupnosti, která se použije, pokud a když replika převezme roli primární. Obvykle je nejlepším postupem zahrnout každou adresu URL směrování pouze pro čtení pro každou sekundární repliku pouze pro čtení s adresou URL místní repliky na konci seznamu. Požadavky na připojení se záměrem čtení jsou směrovány na první dostupný čitelný sekundární prvek na seznamu směrování, mezi sekundárními servery není žádné vyrovnávání zátěže.
Nejprve upravte každou repliku tak, aby poskytovala směrovací adresu URL pouze pro čtení:
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER01.mydomain.com:1433')); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER02.mydomain.com:1433'));
Za druhé, upravte každou repliku tak, aby poskytovala seznam směrování pouze pro čtení, který se použije, když je daná replika v primární roli:
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER02','COMPUTER01')));
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER01','COMPUTER02'))); Směrovací adresa URL by měla být ve tvaru „TCP://:“. Pomoc s určením adresy URL naleznete v tomto blogu a skriptu vytvořeném Mattem Neerincxem.
Závěr
S nakonfigurovaným směrováním pouze pro čtení, vytvořeným AG Listener a klientskými aplikacemi používajícími správné připojovací řetězce byste měli mít pro vaši skupinu dostupnosti připojení plně odolné proti chybám. Ujistěte se, že věnujete nějaký čas testování své konektivity a schopnosti vašich aplikací sledovat vaše servery, když selžou.