Úvod
Organizace často vyžadují určitou úroveň dostupnosti systému pro své nasazení ArcGIS Enterprise, například 99 procent času nebo více. Pro tyto organizace je klíčové implementovat strategii zajišťující vysokou dostupnost.
Vysoká dostupnost (HA), i když souvisí s Disaster Recovery (DR), je samostatný koncept. Obecně se HA zaměřuje na zabránění výpadkům při poskytování služeb, zatímco DR se zaměřuje na uchování dat a zdrojů potřebných k obnovení systému do předchozí přijatelné podoby po katastrofě.
Tento příspěvek se zaměří na osvědčené postupy konfigurace lokálního load balanceru (Local Traffic Manager, LTM) na jednom místě pro vysokou dostupnost a nezahrnuje úvahy o konfiguraci Global Traffic Manager (GTM) pro automatické přepnutí mezi různými lokalitami.
Pro dosažení vysoké dostupnosti musíte snížit jednotlivé body selhání pomocí duplikace a vyvažování zátěže.
Load balancery fungují jako reverzní proxy a rozdělují provoz na back-end servery. Třetí strana load balancer je vyžadována v nasazení ArcGIS Enterprise s vysokou dostupností ke zvýšení kapacity a spolehlivosti softwaru. Zpracovávají klientský provoz do vašich portálových a serverových lokalit, stejně jako interní provoz mezi softwarovými komponentami.
ArcGIS Web Adaptor
Ačkoli je ArcGIS Web Adaptor považován za load balancer, není dostatečný jako jediný load balancer v nasazení s vysokou dostupností, protože ArcGIS Web Adaptor také vyžaduje redundanci k dosažení vysoké dostupnosti.
ArcGIS Web Adaptor je volitelná komponenta, protože load balancery mohou požadavky přeposílat přímo na vaše portálové a serverové lokality, ale je doporučenou komponentou. Výhody použití web adaptérů jsou:
- Poskytuje snadný způsob konfigurace jediné URL pro systém
- Umožňuje zvolit názvy kontextů pro různé systémové komponenty, např. portal, server, mapping atd.
- Je nativně integrován s ostatními softwarovými komponentami ArcGIS Enterprise, portálem a serverovými lokalitami, a automaticky zvládá kontroly stavu a konfigurační úkoly, např. přidání nového stroje do serverové lokality
Web Context URL
Web context URL je veřejná URL adresa portálu. Protože každý prvek v portálu má URL - soubor, vrstvu, mapu a aplikaci, vlastnost WebContextURL portálu mu pomáhá sestavit správné URL na všechny zdroje, které posílá koncovému uživateli.
Externí přístup a DNS
Portál ArcGIS Enterprise podporuje pouze jedno DNS pro veřejnou URL portálu (web context URL) a v současné době neexistuje podporovaný způsob změny web context URL bez opětovného provedení administrativních úkolů, např. federace serverových lokalit s vaším portálem. Pokud vaše ArcGIS Enterprise vyžaduje externí přístup, např. umožnit přístup mobilním uživatelům, dodavatelům, partnerům nebo agenturám bez VPN, nebo pokud předpokládáte, že budete v budoucnu potřebovat povolit externí přístup, musíte použít externě řešitelný DNS název pro web context URL portálu, např. https://gis.company.com/portal.
Pro zabezpečení externího přístupu k ArcGIS Enterprise je běžné hostovat load balancer v DMZ a implementovat Split Domain Name System (Split DNS), tj. interní přístup k ArcGIS Enterprise DNS (např. gis.company.com) bude směrován na interní IP load balanceru, takže interní uživatelé zůstanou za firewallem, a externí přístup k ArcGIS Enterprise DNS bude směrován na externí (DMZ) IP load balanceru.
URL používané ve federaci
V nasazení ArcGIS Enterprise s vysokou dostupností se používá několik různých URL.
Services URL
Toto je URL používané uživateli a klientskými aplikacemi k přístupu na serverové lokality ArcGIS Server. Je to URL pro load balancer, který zpracovává provoz ArcGIS Serveru a předává požadavky buď na Web Adaptor serverové lokality nebo přímo na serverové stroje.
Administrative URL
Toto URL používají administrátoři a interně portál k přístupu na serverovou lokalitu ArcGIS Server při provádění administrativních operací. Toto URL se také používá pro publikování GIS služeb s odkazem na registrovaný datový sklad, např. SQL Server enterprise geodatabase, do federované serverové lokality. Musí směřovat na load balancer; pokud administrativní URL ukazuje na jeden stroj v serverové lokalitě a tento stroj je offline, federace nebude fungovat. Může to být stejné URL jako services URL nebo může být druhý load balancer (VIP) pro každé administrativní URL federované serverové lokality přes port 6443. Konfigurace dedikovaného VIP pro každé administrativní URL federované serverové lokality přes port 6443 bude vyžadovat otevření tohoto portu pro administrátory a vydavatele a můžete zakázat administrativní přístup přes web adaptor, čímž poskytnete další bezpečnostní kontrolu organizaci.
Doporučuji používat stejné URL jako services URL, protože to zjednodušuje konfiguraci. Administrativní přístup k ArcGIS Server bude řízen autentizací ArcGIS Enterprise a uživatelskými rolemi podobně jako administrativní přístup k portálu, např. ArcGIS Portal Directory (portaladmin) a Nastavení organizace. Pro použití web adaptor URL jako administrativního URL musíte povolit administrativní přístup ve web adaptor serveru.
Private portal URL
Toto je interní URL používané vašimi serverovými lokalitami ke komunikaci s portálem. Také musí směřovat na load balancer a mělo by být definováno před federací. Pokud provedete federaci svých serverových lokalit před nastavením privatePortalURL, postupujte podle kroků 8 a 9 v tématu Configure an existing deployment for vysoká dostupnost pro aktualizaci URL ve vaší nasazení. Podobně jako u administrativní URL může být toto stejné jako veřejná URL portálu (webový kontext portálu), nebo to může být druhý load balancer (VIP) přes port 7443.
Pro jednoduchost konfigurace doporučuji použít veřejnou URL portálu jako soukromou URL portálu. Pokud se rozhodnete použít dedikovaný load balancer VIP přes port 7443 pro soukromou URL portálu, měli byste nakonfigurovat load balancer tak, aby kontroloval stav portálových strojů.
Konfigurace Load Balanceru
Nastavení kontroly stavu
Nejdůležitější funkcí je použití kontroly stavu. Jak je popsáno v dokumentaci kontroly stavu portálu:
„Kontrola stavu hlásí, zda odpovídající Portal for ArcGIS stroj je schopen přijímat a zpracovávat požadavky. Například před vytvořením portálu kontrola stavu URL hlásí, že stránka není dostupná, protože v té době nemůže přijímat požadavky.“
ArcGIS Enterprise portal a server mají kontroly stavu.
Když používáte ArcGIS Web Adaptors, web adaptory se postarají o provádění kontrol stavu proti portálu a serverům. V tomto případě můžete nakonfigurovat load balancer s základní TCP/443 kontrolou stavu nebo statickou stránkou kontroly stavu, s běžnými nastaveními pro timeout, spouštěč selhání, interval dotazování a prahovou hodnotu zdraví.
Pokud nakonfigurujete load balancer tak, aby přistupoval přímo k portálu a/nebo serverům, např. pokud nezahrnujete web adaptory do své architektury, nebo pokud používáte dedikovanou URL load balanceru pro soukromou URL portálu (port 7443) nebo federovanou administrativní URL serveru (port 6443), měli byste nakonfigurovat load balancer tak, aby kontroloval stav portálových a serverových strojů.
Existují důležité úvahy ohledně nastavení kontroly stavu na load balanceru. Většina organizací používajících load balancer používá statickou stránku jako svou kontrolu stavu (např. index.html) k určení, zda je webový server zdravý. Jedná se o statický soubor, který vyžaduje pouze načtení z disku. Také většina webových serverů má tendenci mít úzké hrdlo spíše v I/O než v CPU.
Nicméně Esri ArcGIS Server je jiný tím, že naše kontrola stavu vyžaduje velmi malé množství CPU, protože naše kontrola není jen načtení z disku, software musí určit, zda jsou určité procesy funkční.
Při kontrolách stavu existuje hodnota timeoutu na dotazování. Většina správců load balancerů nastavuje timeout velmi nízko, protože načtení z disku je obvykle velmi rychlé (i když často ponechávají nějakou rezervu pro špatnou latenci sítě).
Při použití nízké hodnoty timeoutu s ArcGIS Serverem a při použití více-strojového nastavení existuje šance, že jeden ze strojů překročí nízkou hodnotu timeoutu a zdravý stroj bude odstraněn.
Esri doporučuje vyšší hodnotu timeoutu, ideálně alespoň 5 sekund. Záleží na systému, možná budete muset tuto hodnotu ještě zvýšit. Měli byste sledovat své prostředí a podle toho tuto hodnotu upravit. Toto může připadat správcům sítí jako vysoké číslo, protože kontrola stavu na jednoduché stránce obvykle trvá méně než 10 ms normálně (plus latence sítě).
Je však kritické pro load balancery rozlišovat mezi tím, kdy je stroj jen pomalý vs. kdy je skutečně mrtvý a nereaguje. Pokud je portál nebo server skutečně mimo provoz a vůbec neposlouchá na portu, většina load balancerů to zjistí ještě dříve než za 5 sekund, takže tento timeout neovlivňuje „normální“ selhání, kdy stroj zmizí.
Druhou úvahou je spouštěč selhání - kolikrát musí dotazování selhat před tím, než je stroj odstraněn z load balanceru.
Obecně správci sítí nastavují spouštěč selhání na více než 1 selhání, protože nechtějí, aby jediný výpadek sítě způsobil pád systému. Jak bylo uvedeno výše, malý nárůst využití CPU (což je běžné u systémů ArcGIS Server) může způsobit timeout a není žádoucí odstavit stroj kvůli jednomu nárůstu CPU na jednom stroji.
Esri provedlo rozsáhlé interní testy s load balancery a zjistilo, že nastavení 5 selhání výrazně snížilo počet falešných poplachů při stále detekování skutečných výpadků. Zjistili jsme, že hodnota 3 byla stále velmi náchylná k falešným poplachům.
Třetí úvaha je interval dotazování. Esri zjistilo, že intervaly dotazování 30 sekund spolu s 5 selháními byly optimální kombinací pro detekci skutečných výpadků a ignorování falešných poplachů.
S touto kombinací je očekávaná hodnota (používající statistický termín) nebo průměrný čas do detekce 1 minuta a 15 sekund výpadku před detekcí, s nejhorším případem 2 minuty a 30 sekund. Je možné usilovat o nižší průměrný čas do detekce, ale kompromisem je přijímání falešných poplachů.
Pokud je preferován nižší průměrný čas do detekce, může být potřeba zvýšit kapacitu tak, aby byly dostatečné zdroje pro zvládnutí skutečného výpadku na stroji i falešného poplachu bez přetížení zbývajících strojů.
Posledním nastavením týkajícím se kontrol stavu je prahová hodnota zdraví pro load balancer k opětovnému začátku odesílání požadavků. Esri nemá doporučení pro toto nastavení a nezaznamenali jsme mnoho rozdílů v této hodnotě, ale obvykle vidíme 3 po sobě jdoucí zdravé dotazy před opětovným připojením.
Omezování
Nastavení omezování stojí za zvážení. ArcGIS Server je vázán na CPU což znamená, že většina času požadavku je strávena využitím CPU spíše než čekáním na I/O.
To znamená, že pokud jsou k dispozici 8 jader, ArcGIS Server může prakticky zvládnout trochu více než 8 současných požadavků. Pokud je ArcGIS Server vytížený, začne řadit požadavky do fronty až do stovek požadavků v řadě a po dosažení tohoto limitu odmítá připojení. Když je dlouhá fronta požadavků vznikne dlouhá doba čekání, ale nakonec je požadavek zpracován.
ArcGIS Server má nastavení pro řízení tohoto chování tak, aby bylo méně těchto opuštěných požadavků zpracováváno, ale také je nejlepší praxí řídit to na úrovni load balanceru pomocí jeho schopnosti omezovat zatížení.
Esri nemá číselné doporučení protože to hodně závisí na konkrétní architektuře a typech přicházejících požadavků, ale typicky se omezuje na výrazně nižší hodnoty než by správci sítí obvykle nastavovali pro webový server.
Toto není pod kontrolou správce sítě, ale klientské aplikace by měly být napsány tak, aby zvládaly událost omezování a prováděly opakované pokusy v rostoucích časových intervalech (např. první pokus můžete okamžitě zopakovat, druhý pokus počkáte sekundu, třetí pokus počkáte 5 sekund atd.).
Sticky Sessions
Esri nedoporučuje sticky sessions kromě velmi vzácných případů. Sticky sessions teoreticky mohou přetížit jeden stroj. Esri provedlo zátěžové testy pomocí sticky sessions aby zjistilo zda by došlo k přetížení našeho GIS Serveru a k tomu nedošlo. Také jsme nezaznamenali žádné stížnosti od zákazníků. Nicméně protože náš software je bezstavový nevidíme hodnotu ve využívání sticky sessions.
Vrstva 4 vs. Vrstva 7
Posledním nastavením k zmínění je zda load balancer používá „vrstvu 7“ nebo „vrstvu 4“. Toto může být předmětem debat mezi správci sítí, ale níže je stručné shrnutí situace popisující rozdíly a výhody každého přístupu.
Load balancer vrstvy 7 rozumí http a https proto dešifruje https obsah a poté jej znovu zašifruje. Protože rozumí http a https může ukládat obsah do cache a šetřit požadavky směřující na backend server.
Load balancer vrstvy 4 vidí veškerý provoz jako TCP pakety a nemá tušení co pakety znamenají; mohou být pro ftp, https nebo smtp ale to vrstvě 4 nevadí. Výsledkem je že nemusí rozumět http obsahu a může být rychlejší.
ArcGIS Server může pracovat s oběma přístupy a neexistuje doporučení ohledně tohoto nastavení pro správce sítí ale existují některé informace které by správce měl znát.
Přenášená data ArcGIS Serveru mohou být mnohem větší než HTML stránky CSS a JS obsah (skutečné množství by bylo užitečné ale často závislé na datech používaných zákazníkem). To znamená větší zatížení CPU u load balanceru vrstvy 7 při dešifrování a šifrování na základě jednotlivých požadavků.
Také protože většina dat ArcGIS Serveru je dynamická a často se mění výchozí cache hlavičky zakazují ukládání do cache u klienta i u load balanceru. Pokud se data moc nemění a zákazník chce použít load balancer vrstvy 7 může tato cache nastavení změnit a ovládat.
Shrnutí doporučení
Kontrola stavu
- Pokud konfigurujete své load balancery s ArcGIS Web Adaptors můžete nakonfigurovat load balancer s základní TCP/443 kontrolou stavu nebo statickou stránkou kontroly proti webovým serverům
- Pokud konfigurujete load balancer tak aby přistupoval přímo k portálu a/nebo serverům (přes porty 6443 a 7443), použijte HTTPS endpoint kontroly stavu:<\/SPAN>Portal:<\/SPAN>Požadavek: <\/SPAN>https:\/\/\/\/portaladmin\/healthCheck?f=json
NEBO<\/SPAN>
<\/SPAN>https:\/\/:7443\/arcgis\/portaladmin\/healthCheck?f=json<\/A><\/SPAN><\/LI>Odpověď: {"status":"success"}<\/SPAN><\/LI><\/UL><\/LI>Server:<\/SPAN>Požadavek: <\/SPAN>https:\/\/\/\/rest\/info\/healthCheck?f=json
NEBO<\/SPAN>
<\/SPAN>https:\/\/:6443\/arcgis\/rest\/info\/healthCheck?f=json<\/A><\/SPAN><\/LI>Odpověď: {"success":true}<\/SPAN><\/LI><\/UL><\/LI>Použijte vyšší hodnotu timeoutu kontroly stavu, alespoň 5 sekund<\/SPAN><\/LI>Použijte hodnotu 5 pro spouštěč selhání<\/SPAN><\/LI>Použijte intervaly dotazování 30 sekund<\/SPAN><\/LI>Použijte 3 po sobě jdoucí zdravé kontroly před opětovným připojením<\/SPAN><\/LI><\/UL><\/LI><\/UL>Omezování <\/SPAN><\/P>Použijte nastavení throttle na výrazně nižší hodnotu než u běžných webových serverů<\/SPAN><\/LI><\/UL>Sticky Sessions<\/SPAN><\/P>Nepoužívejte sticky sessions<\/SPAN><\/LI><\/UL>Certifikáty<\/SPAN><\/H1>Komponenty ArcGIS Enterprise jsou předkonfigurovány s self-signed server certifikáty, což umožňuje software nejprve otestovat a rychle ověřit, že instalace byla úspěšná. Nicméně ve většině případů by organizace měla požádat o certifikát od důvěryhodné certifikační autority (CA) a nakonfigurovat software tak, aby jej používal. Certifikát může být podepsán firemní (interní) nebo komerční CA. Komerční CA (known-CA) musí být použita pro externě řešitelný DNS, např. load balancer VIP DNS; interní doménové certifikáty lze použít pro interní servery. <\/SPAN>
Pro systém ArcGIS Enterprise s externě řešitelným DNS, pokud je SSL metoda load balanceru SSL-passthrough (load balancer nešifruje a znovu nešifruje https obsah), není potřeba certifikát a komerční CA certifikát musí být nainstalován na mapovaných serverech (např. webové servery, kde jsou nainstalovány web adaptory). Pokud je SSL metoda load balanceru SSL re-encryption, komerční CA certifikát musí být nainstalován na load balanceru.<\/SPAN><\/SPAN><\/P>
.png)
