← Referenční architektury / reference-architecture / architectures

Referenční architektura load balancingu

Cloudflare Load Balancing je služba SaaS, která organizacím umožňuje hostovat aplikace pro globální uživatelskou základnu a přitom výrazně snižuje starosti s údržbou, převzetím služeb při selhání, odolností a škálovatelností. Díky Cloudflare Load Balancing mohou organizace řešit tyto výzvy:

• Efektivní zvládání velkých objemů příchozího provozu, zejména při neočekávaných nárazech či výkyvech.
• Zajištění dostupnosti aplikací a služeb pro uživatele.
• Udržení rychlé doby odezvy a optimálního výkonu pro všechny uživatele, zejména během období vysoké zátěže.
• Přizpůsobení se měnícím nárokům na provoz a zajištění toho, že infrastruktura zvládne růst.
• Pomáhá aplikacím a službám odolávat útokům Distributed Denial of Service (DDoS).

Cloudflare Load Balancing je postaveno na Cloudflare connectivity cloud, jednotné inteligentní platformě programovatelných cloud-native služeb, která umožňuje zabezpečenou konektivitu typu any-to-any mezi všemi sítěmi (podnikovými i internetovými), cloudovými prostředími, aplikacemi a uživateli. Jde o jednu z největších globálních sítí s datacentry ve více než 330 městech a propojením s více než 13 000 síťovými partnery. Cloudflare má také větší zastoupení v klíčových internetových uzlech než mnohé jiné velké technologické společnosti.

Díky tomu se Cloudflare pohybuje ve vzdálenosti přibližně 50 ms od zhruba 95 % světové populace připojené k internetu. Protože jsou navíc všechny služby Cloudflare navržené tak, aby běžely v každé síťové lokalitě, veškeré požadavky se směrují, kontrolují a filtrují v blízkosti svého zdroje, což vede k vysokému výkonu a konzistentnímu uživatelskému zážitku.

Tento dokument popisuje referenční architekturu pro organizace, které chtějí nasadit řešení load balancingu jak pro globální, tak pro lokální řízení provozu.

Tato referenční architektura je určena pracovníkům IT, webhostingových a síťových týmů, kteří mají na starosti stávající infrastrukturu organizace nebo ji dobře znají. Užitečná je zkušenost se síťovými koncepty, jako je směrování, DNS a adresace IP, a základní znalost fungování load balanceru.

Pro hlubší základní pochopení Cloudflare a jeho řešení pro vyvažování zátěže doporučujeme následující zdroje:

• Co je Cloudflare? | Web ↗ (čtení na 5 minut) nebo video ↗ (2 minuty)

• Přehled řešení: Cloudflare Private Network Load Balancing ↗ (čtení na 5 minut)
• Přehled řešení: Cloudflare GTM Load Balancing ↗ (čtení na 5 minut)
• Blog: Vylepšete load balancing pomocí Private IPs a Cloudflare Tunnels: bezpečná cesta k efektivní distribuci provozu ↗ (13 minut)

Čtenáři této referenční architektury se dozvědí:

• Jak Cloudflare Load Balancing řeší případy použití pro Private Network Load Balancing i pro správu globálního provozu.
• Jak globální síť Cloudflare rozšiřuje funkce služby Cloudflare Load Balancing.
• Možnosti Cloudflare Load Balancers a jejich využití v různých případech použití.
• Struktura Cloudflare Load Balancer a jeho různých konfigurací.

V tomto dokumentu označuje pojem „endpoint“ jakoukoli službu nebo hardware, který zachytává a zpracovává příchozí veřejný nebo privátní provoz. Protože load balancing lze použít nejen pro webové servery, byl pojem endpoint zvolen tak, aby zastupoval všechny možné typy origin serverů, hostname, privátních nebo veřejných IP adres, virtuálních IP adres (VIP), serverů a dalších dedikovaných hardwarových zařízení. Může jít o řešení on-premises, hostované ve veřejném nebo privátním cloudu, případně dokonce o load balancer třetí strany.

Směrování je hlavní funkcí load balanceru: jde o proces zpracování, odesílání a přeposílání požadavků na základě sady zásad. Tyto zásady obvykle zohledňují mnoho faktorů, včetně URL požadavku, cesty URL, hlaviček HTTP, nakonfigurovaných vah, priority a latence, odezvy, kapacity a zátěže koncového bodu.

Vrstva 7 ↗ Model OSI ↗, známá také jako aplikační vrstva, je vrstva, kde se nacházejí protokoly jako SSH, FTP, NTP, SMTP a HTTP(S). Když tento dokument odkazuje na vrstvu 7 nebo vyvažovače zátěže vrstvy 7, má na mysli služby založené na HTTP(S). Zásobník vrstvy 7 od Cloudflare umožňuje Cloudflare uplatňovat na web zákazníka služby jako ochrana před DDoS útoky, Bot Management, WAF, CDN, vyvažování zátěže a další, aby se zlepšil výkon, dostupnost a zabezpečení.

Vrstva 4 modelu Model OSI ↗ , známá také jako transportní vrstva, odpovídá za komunikaci mezi dvěma zařízeními od konce ke konci. Síťové služby, které fungují na vrstvě 4, mohou podporovat mnohem širší škálu služeb a protokolů. Veřejné vyvažovače zátěže vrstvy 4 od Cloudflare umožňuje produkt Spectrum, který funguje jako reverzní proxy vrstvy 4. Kromě vyvažování zátěže poskytuje Spectrum ochranu před Útoky DDoS ↗ a dokáže skrýt IP adresy endpointů.

SSL (Secure Sockets Layer) a jeho nástupce TLS (Transport Layer Security) jsou kryptografické protokoly, které zabezpečují připojení přes internet. SSL/TLS offloading, označovaný také jako SSL/TLS terminace nebo SSL/TLS akcelerace, je technika používaná v load balancerech a webových serverech ke zpracování šifrování a dešifrování SSL/TLS, aniž by to ovlivnilo výkon koncového bodu. SSL/TLS offloading zlepšuje výkon serveru, zjednodušuje správu certifikátů a zvyšuje škálovatelnost tím, že náročné šifrovací a dešifrovací operace přenáší na vyhrazená zařízení, takže se koncové body mohou soustředit na obsluhu obsahu a aplikační logiky.

Moderní webové stránky, respektive aplikace obecně, čelí třem hlavním výzvám:

1. Výkon: Zajišťuje, aby aplikace reagovala na požadavky a vstupy uživatelů včas
2. Dostupnost: Udržuje dostupnost aplikace, aby vždy dokázala reagovat na požadavky uživatelů
3. Škálovatelnost: Rozšiřování, zmenšování nebo přesouvání prostředků aplikace na základě chování uživatelů nebo poptávky.

Výkon aplikace může ovlivnit řada faktorů, nejčastější příčinou problémů s výkonem je ale míra vytížení nebo zátěž koncového bodu. Koncový bod má obvykle k dispozici jen omezené výpočetní prostředky. Pokud najednou přijde příliš mnoho požadavků nebo pokud jejich typ způsobí zvýšené využití CPU či paměti, koncový bod bude reagovat pomaleji, nebo přestane odpovídat úplně.

Tyto problémy lze řešit navýšením výpočetních prostředků koncových bodů. V době nečinnosti nebo nízkého vytížení ale organizace platí za nevyužité prostředky. Firmy mohou také nasadit více koncových bodů, k plynulému rozložení provozu mezi nimi je však potřeba řešení pro vyvažování zátěže, aby byl celý proces pro koncového uživatele bezproblémový.

Obrázek 1 znázorňuje, jak by mohla být zátěž rozložena bez load balanceru:

Load balancery umožňují organizacím provozovat více koncových bodů a rozdělovat mezi ně provoz tak, aby žádný z nich nebyl přetížený. Load balancer zpracovává všechny příchozí požadavky a přeposílá je na odpovídající koncový bod. Klient nemusí vůbec vědět, jaká je dostupnost nebo zátěž koncových bodů, požadavek jednoduše odešle load balanceru a ten se postará o zbytek. Obrázek 2 ukazuje, jak load balancer rovnoměrně rozděluje provoz uživatelů mezi skupinu koncových bodů.

Dalším problémem souvisejícím s výkonem je vzdálenost mezi klientem a koncovým bodem. Ať už jde o samotnou vzdálenost, nebo o nutnost více síťových skoků, požadavek putující na delší vzdálenost má obecně vyšší dobu odezvy (RTT).

RTT nabývá na významu při větším rozsahu. Pokud se například klient i koncový bod nacházejí ve Spojených státech, lze rozumně očekávat RTT 25ms. Pokud klient potřebuje odpovědi na 20 požadavků, celkový čas potřebný k jejich sekvenčnímu zpracování (bez výpočetního času) by činil 500ms (20 x 25ms). Pokud by se stejný klient připojoval z regionu APAC, RTT by mohlo dosahovat až 150ms, což by vedlo k nežádoucí celkové době načítání 3000ms (20 x 150ms). (Vylepšení streamování požadavků v HTTP/2 a HTTP/3 mohou tento výpočet do jisté míry změnit, avšak u webů s dynamickým nebo interaktivním obsahem, kde se informace z odpovědi používají k vygenerování dalších požadavků, příklad obecně stále platí.) Obrázek 3 znázorňuje, jak k tomu dochází.

Stejně jako může load balancer předávat provoz méně vytíženému koncovému bodu, může jej předávat i geograficky bližšímu koncovému bodu, což klientovi zajistí rychlejší odezvu. Load balancer konkrétně vyhledá IP adresu, ze které požadavek přišel, určí její polohu a vybere nejbližší nebo regionálně nejvhodnější koncový bod, kam požadavek odešle (jde o funkci podobnou té, kterou nabízí DNS řešení jako GeoDNS).

Dostupnost služby zahrnuje jak neúmyslné, tak úmyslné výpadky koncových bodů za load balancerem. K neúmyslným výpadkům může přispívat řada faktorů, včetně selhání hardwaru, softwarových chyb, problémů se sítí a potíží na straně poskytovatele internetových služeb nebo jiného dodavatele. Těmto problémům se nevyhnou ani nejvyspělejší organizace.

Load balancery tyto problémy řeší tím, že neustále sledují stav koncových bodů. Pokud koncový bod odpovídá na kontrolu stavu pomalu nebo na ni nereaguje vůbec, označí se jako nefunkční. Existuje několik způsobů sledování, od základních testů jako ICMP (ping) a testy TCP spojení, až po pokročilejší testy, například odeslání požadavku HTTP GET a ověření, že koncový bod vrátí očekávaný stavový kód a obsah odpovědi. Jakmile je koncový bod ve zhoršeném stavu, load balancer na něj směruje méně požadavků nebo žádné a dává přednost zdravějším koncovým bodům. Jakmile je koncový bod znovu funkční a load balancer začne dostávat odpovědi na kontroly stavu, označí se jako funkční a provoz se na něj znovu směruje.

Plánovaná odstávka má několik podob, mezi které patří změny kapacity, upgrady hardwaru nebo infrastruktury a aktualizace softwaru. Load balancery při takové údržbě šetrně odklánějí provoz z jednoho nebo více koncových bodů.

Efektivní škálování aplikací pomáhá organizacím naplnit poptávku zákazníků či uživatelů a vyhnout se zbytečným nákladům. Při nárůstu provozu mohou organizace potřebovat dočasně nasadit další koncové body, aby služba zůstala výkonná a dostupná. Trvale udržovat dostatek aktivních koncových bodů pro pokrytí maximálního možného provozu by ale mohlo být nákladné, ať už je koncový bod umístěný on-premises, nebo u cloudového poskytovatele jako AWS, GCP nebo Azure. Load balancery umožňují kapacitu dynamicky zvyšovat i snižovat na základě sledování požadavků, připojení a latence ke koncovým bodům.

Dalším typem škálování, které je třeba zvážit, je geografické měřítko. S rostoucí oblibou služeb totiž stále více záleží na umístění koncového bodu. Uživatelé z jiného geografického regionu, než ve kterém se koncový bod nachází, mohou zaznamenat pomalejší odezvy a nižší kvalitu služby než uživatelé ve stejném regionu. Když organizace nasazují nové koncové body v různých regionech, musí se rozhodnout, jak mezi ně chtějí rozdělovat provoz. Tuto výzvu řeší různé vrstvy load balancingu označované jako global traffic management (GTM) a Private Network Load Balancing. Obě jsou podrobně popsány v následující části dokumentu: ve stručnosti GTM load balancer zpracuje počáteční požadavek (obvykle přes DNS) a poté vybere a nasměruje provoz na Private Network Load Balancer nasazený v blízkosti koncových bodů v příslušném geografickém regionu.

Jak již bylo zmíněno, load balancing pro globální aplikace a služby probíhá ve dvou vrstvách. První se nazývá Global Traffic Management nebo Manager (GTM), případně také Global Server Load Balancing (GSLB). Druhá se nazývá Private Network Load Balancing, případně také Server Load Balancing (SLB). Tato část definuje účel obou typů load balancingu a způsob, jakým spolupracují.

Global Traffic Manager má za úkol směrovat požadavky, obvykle z internetu, do správného regionu nebo datového centra. Řada load balancerů GTM funguje na úrovni DNS, což jim umožňuje:

• Přeložit DNS požadavek na IP adresu na základě geografické oblasti nebo fyzické polohy.
• Poskytnout IP adresu koncového bodu nebo služby nejblíže klientovi, aby se k ní mohl připojit.

Obrázek 4 znázorňuje, jak load balancer GTM vybírá datové centrum podle polohy nebo oblasti klienta.

Global Traffic Managery mohou provoz také proxovat a provádět různé kontroly, včetně čtení, změny a mazání hlaviček v požadavcích HTTP a úpravy adres URL podle regionu nebo geografické polohy. Funkčnost GTM nejlépe zajišťují cloudové load balancery (jako Cloudflare), protože cílem je směrovat provoz odkudkoli na světě. Hardwarové load balancery existují na jediném fyzickém místě, což znamená, že čím dál od load balanceru provoz pochází, tím pomalejší je zkušenost koncového uživatele. Cloudový load balancer může běžet na mnoha různých geografických místech, díky čemuž nabízí výkonné řešení pro kontexty pouze DNS, vrstvy 4 i vrstvy 7.

Private Network Load Balancing směruje provoz v rámci datového centra nebo geografické lokality. Private Network Load Balancer může zajišťovat vyrovnávání zátěže, odlehčení SSL/TLS, přepínání obsahu a další funkce pro doručování aplikací. Private Network Load Balancing zajišťuje efektivní rozložení klientských požadavků mezi více koncových bodů, čímž zlepšuje výkon a zajišťuje vysokou dostupnost. Private Network Load Balancery se obvykle umísťují uvnitř privátních sítí a slouží k vyrovnávání zátěže veřejně i privátně přístupných zdrojů. Na obrázku 5 níže GTM load balancer vybral evropské datové centrum a nasměroval do něj požadavek na Private Network Load Balancer evropského datového centra, který jej následně přesměruje na příslušný koncový bod.

Private Network Load Balancer a jeho koncové body obvykle sídlí za firewally. Koncové body sice mohou být v privátních sítích chráněné, přístupnost k Private Network Load Balanceru ale může být podle požadavků nasazení veřejná nebo privátní. Private Network Load Balancer sleduje celkový počet požadavků, připojení a stav koncových bodů, aby zajistil směrování požadavků na koncové body, které dokážou odpovídat včas.

Existují dvě hlavní architektury load balanceru:

• Lokální load balancery
  • Obvykle hardwarové, ale může být i virtualizované nebo softwarové
  • Zaměřeno na maximální výkon
• Cloudové load balancery
  • Software nasazený na infrastruktuře veřejného cloudu
  • Zpracovávejte požadavky blíže k jejich původci

Každý přístup má své výhody a nevýhody. On-premises load balancery obvykle fungují v privátních sítích, které organizace plně kontroluje. Tyto load balancery jsou umístěné společně s koncovými body, mezi kterými rozkládají zátěž, takže latence a doba RTT bývají minimální. Nevýhodou on-premises load balancerů je, že jsou vázané na jedinou fyzickou lokalitu, což znamená, že provoz z jiných regionů může mít dlouhou dobu RTT a vysokou latenci odpovědí. Přidání dalšího datového centra navíc vyžaduje nákup a nasazení zcela nového vybavení. On-premises load balancery navíc obvykle potřebují cloudové load balancery pro geografické směrování provozu, aby požadavky směrovaly do geograficky nejbližšího nebo regionálně vhodného datového centra. Výhodou cloudových load balancerů je, že mohou fungovat téměř v jakémkoli geografickém regionu bez ohledu na místo v racku, napájení, chlazení nebo údržbu a dokážou se škálovat bez nutnosti řešit nová šasi, moduly nebo větší síťové připojení. Cloudové load balancery ovšem zvyšují latenci a RTT mezi load balancerem a koncovými body, protože obvykle nejsou umístěné společně s koncovými body, do kterých provoz směrují.

Cloudflare nabízí cloudové GTM od roku 2016 a od roku 2023 postupně přidává funkce Private Network Load Balancing. Tato část popisuje celou architekturu Cloudflare Load Balancing a podrobně se věnuje jednotlivým dostupným konfiguracím a možnostem. Nejprve je ale důležité pochopit výhody, které Cloudflare Load Balancers získávají už jen tím, že běží na globální síti Cloudflare.

Cloudflare Load Balancing je postaveno na Cloudflare connectivity cloud, jednotné inteligentní platformě programovatelných cloud-native služeb, která umožňuje konektivitu typu any-to-any mezi všemi sítěmi (podnikovými i internetovými), cloudovými prostředími, aplikacemi a uživateli. Jde o jednu z největších globálních sítí s datacentry ve více než 330 městech a propojením s více než 13 000 síťovými partnery. Cloudflare má také větší zastoupení v klíčových internetových uzlech než mnohé jiné velké technologické společnosti.

Díky tomu se Cloudflare pohybuje ve vzdálenosti přibližně 50 ms od zhruba 95 % světové populace připojené k internetu. Protože jsou navíc všechny služby Cloudflare navržené tak, aby běžely v každé síťové lokalitě, veškerý provoz se připojuje, kontroluje a filtruje v blízkosti zdroje, což zajišťuje nejlepší výkon a konzistentní uživatelský zážitek.

Řešení load balancingu od Cloudflare těží z toho, že využíváme technologii anycast. Anycast umožňuje Cloudflare inzerovat IP adresy našich služeb z každého datového centra po celém světě, takže provoz je vždy směrován do datového centra Cloudflare nejblíže zdroji. To znamená, že kontrola provozu, autentizace a vynucování politik probíhají blízko koncového uživatele, což vede k trvale kvalitnímu uživatelskému zážitku.

Díky anycastu je síť Cloudflare dobře vyvážená. Pokud dojde k náhlému nárůstu provozu v síti, lze zátěž rozložit mezi více datových center, což pomáhá udržet stabilní a spolehlivé připojení pro uživatele. Rozsáhlá síťová kapacita Cloudflare a inteligentní směrování optimalizované pomocí AI/ML navíc pomáhají zajistit trvale optimální výkon.

Naproti tomu řada dalších poskytovatelů SaaS load balancingu používá unicastové směrování, kdy je jedna IP adresa přiřazena jednomu koncovému bodu nebo datovému centru. V mnoha takových architekturách je pak jedna IP adresa přiřazena konkrétní aplikaci, což znamená, že požadavky na přístup k této aplikaci mohou mít velmi odlišný průběh směrování v síti podle toho, jak daleko musí provoz cestovat. Výkon tak může být vynikající pro zaměstnance pracující v kanceláři vedle koncových bodů dané aplikace, avšak špatný pro vzdálené zaměstnance nebo ty, kteří pracují v zahraničí. Unicast navíc komplikuje škálování zátěže provozu: dané umístění služby musí při nárůstu zátěže navyšovat zdroje samo, zatímco anycastové sítě dokážou provoz rozložit mezi mnoho datových center a geografických oblastí.

Obrázek 6 znázorňuje, jak síť Cloudflare umožňuje geograficky rozptýleným uživatelům připojit se ke svým prostředkům co nejrychleji.

Obrázek 6 výše ukazuje, že v každém z těchto datových center běží i další služby Cloudflare, protože Cloudflare provozuje každou službu v každém datovém centru, aby měli uživatelé všude stejně kvalitní zkušenost. Load balancer vrstvy 7 od Cloudflare tak může využívat i další služby, jako je DDoS Protection, CDN/Cache, Bot Management nebo WAF. Všechny tyto doplňkové služby pomáhají chránit vaši službu před zbytečným provozem, ať už jde o škodlivé požadavky (blokované pomocí DDoS Protection, Bot Management nebo WAF), nebo o požadavky, které lze obsloužit z mezipaměti místo odeslání na koncový bod. Všechny tyto služby lze podle potřeby kombinovat a vytvořit tak službu nebo nabídku co nejlépe chráněnou, odolnou a výkonnou.

Cloudflare má také služba pro optimalizaci sítě ↗ která neustále běží ve všech datových centrech, aby zajistila, že Cloudflare mezi jednotlivými datovými centry vždy volí nejlepší cestu, a zároveň sleduje všechny dostupné cesty k endpointům. Díky tomu Cloudflare zajišťuje, že endpointy jsou vždy dosažitelné, a v případě potřeby přesměruje provoz na alternativní datové centrum Cloudflare, aby endpoint zůstal dosažitelný. Jakmile load balancer rozhodne, na který endpoint provoz nasměrovat, je provoz předán službě pro optimalizaci sítě Cloudflare, která určí nejlepší cestu k cíli. Tuto cestu může ovlivnit funkce Argo Smart Routing, která po zapnutí pomocí časovaných TCP připojení hledá datové centrum Cloudflare s nejnižší latencí RTT k danému endpointu. Obrázek 8 ukazuje, jak může Argo Smart Routing zlepšit dobu připojení k endpointům.

Tok provozu může ovlivnit také použití Cloudflare Tunnels, kterým se podrobně věnuje následující část dokumentu. Cloudflare Tunnels propojují koncové body s konkrétními datovými centry Cloudflare, a provoz určený pro tyto koncové body proto musí projít právě těmito centry, aby je dosáhl. Obrázek 9 ukazuje, jak připojení k privátním koncovým bodům přes Cloudflare Tunnel musí projít datovým centrem, ve kterém tunel končí.

GTM a Private Network Load Balancers bývají obvykle buď samostatný hardware, nebo oddělené komponenty SaaS (GTM) a hardwarového Private Network Load Balancingu. Cloudflare tyto funkce GTM a Private Network Load Balancingu spojuje do jediné nabídky SaaS, což výrazně zjednodušuje konfiguraci i správu. Odpadá potřeba vytvářet GTM load balancer a směrovat provoz na další, lokálnější Private Network Load Balancery. Všechny koncové body lze připojit přímo ke Cloudflare a provoz je díky jediné konfiguraci load balanceru směrován do správného regionu, datového centra i koncového bodu. Koncepty GTM a Private Network Load Balancingu zůstávají zachovány, jejich implementace v Cloudflare je však navržena tak, aby byla konfigurace load balanceru co nejjednodušší a nejpřehlednější. Obrázek 10 znázorňuje, jak lze globální provoz podle potřeby směrovat z libovolného geografického regionu na konkrétní koncový bod.

Cloudflare Load Balancer, často označovaný jako Virtual IP (VIP), je nakonfigurován se vstupním bodem (entrypoint). Tímto vstupním bodem bývá obvykle DNS záznam. Load balancer nejprve podle definovaného algoritmu řízení provozu vybere fond koncových bodů (endpoint pool), tedy skupinu koncových bodů zvolených podle funkce, geografické oblasti nebo regionu. Jedna konfigurace load balanceru může obsahovat jeden nebo více fondů koncových bodů a každý fond může obsahovat jeden nebo více koncových bodů. Po výběru fondu koncových bodů load balancer použije algoritmus řízení provozu mezi koncovými body ze seznamu koncových bodů a vybere ten, na který provoz přesměruje. Obrázek 11 ukazuje základní kroky od požadavku klienta až po koncový bod v rámci Cloudflare Load Balanceru.

Definice Cloudflare Load Balanceru se skládá ze tří hlavních komponent:

1. Monitory stavu: tyto komponenty sledují stav koncových bodů a kategorizují je jako zdravé nebo kritické (nezdravé).
2. Fondy endpointů: zde se definují endpointy a nastavují kontroly stavu a řízení výběru endpointů.
3. Load balancery: v této komponentě se uplatňují seznamy skupin koncových bodů a zásady směrování provozu.

Následující části popisují dostupné možnosti a aspekty konfigurace Cloudflare Load Balancer, počínaje směrováním (steering), které se uplatňuje jak při konfiguraci endpoint pool, tak load balanceru.

Směrování je klíčovou funkcí load balanceru a metody směrování v konečném důsledku určují, který koncový bod bude vybrán při použití load balanceru. Z pohledu load balanceru lze směrování uplatnit ve dvou klíčových oblastech.

První se nazývá „traffic steering“ a určuje, který pool koncových bodů bude obsluhovat příchozí požadavky, obvykle na základě blízkosti nebo geografického regionu žadatele. Koncept traffic steering úzce souvisí s myšlenkou globální správy provozu (global traffic management).

Druhou oblastí, kde se směrování (steering) uplatňuje, je okamžik po výběru regionu, datacentra nebo endpoint pool. V tu chvíli musí load balancer vybrat jediný endpoint, který požadavek nebo spojení zpracuje, což se označuje jako „endpoint steering“. Na obou těchto úrovních se směrování řídí metodami přizpůsobenými konkrétním potřebám zákazníka, který load balancer nasazuje. Na výběr je několik různých algoritmů, ne všechny ale lze použít pro oba typy směrování.

Níže najdete podrobný přehled všech metod řízení provozu (steering), které Cloudflare nabízí. Na konci této části je stručná přehledová tabulka, která pomůže pochopit, jaké algoritmy se hodí pro jaké případy použití.

Traffic Steering vybírá skupinu koncových bodů, nazývanou také fond koncových bodů (endpoint pool). Nejběžnějším využitím Traffic Steering je výběr fondu koncových bodů na základě nejnižší latence odezvy, geografické oblasti nebo fyzické lokality. Traffic Steering úzce souvisí s globální správou provozu a představuje první krok při směrování provozu ke koncovému bodu.

Řízení výběru endpointů určuje, který endpoint požadavek nebo spojení obdrží. Může vybrat endpoint náhodně, zvolit dříve použitý endpoint (pokud je zapnutá afinita relace), nebo vybrat endpoint s nejnižším vytížením či nejrychlejší odezvou. Řízení výběru endpointů úzce souvisí s Private Network Load Balancing, protože právě ono určuje konečný cíl požadavku nebo spojení.

Vážené směrování zohledňuje rozdíly mezi fondy koncových bodů a koncovými body, které budou zpracovávat požadavky z load balanceru. Váha koncového bodu, což je povinné pole pro každý koncový bod, se použije pouze v případě, že je zvolena konkrétní metoda směrování. Podobně je váha fondu koncových bodů potřebná jen tehdy, když je vybrána konkrétní metoda směrování. Podívejte se prosím na přehled možností směrování se stručným přehledem toho, kdy se váhy uplatňují.

Váha ovlivňuje náhodnost výběru fondu koncových bodů nebo koncového bodu pro jeden požadavek či připojení v rámci load balanceru. Váha nebere v úvahu historická data ani informace o aktuálním připojení, takže rozložení podle váhy se může v kratších časových úsecích lišit. Při delším časovém horizontu a významném provozu se však rozložení bude čím dál víc blížit požadovaným váhám nastaveným v konfiguraci. Je důležité mít na paměti, že afinita relace po navázání počátečního připojení váhová nastavení přebije, protože jejím účelem je směrovat následné požadavky do stejného fondu koncových bodů nebo na stejný koncový bod. Obrázek 12 ukazuje příklad váhy pro dva fondy koncových bodů se stejnou kapacitou a pravděpodobností výběru.

Konkrétní algoritmy, jako je Least Outstanding Request Steering, zohledňují počet otevřených požadavků a připojení. Váha se používá k určení, které koncové body nebo fondy koncových bodů zvládnou vyšší počet otevřených požadavků nebo připojení. Váha v podstatě definuje kapacitu koncových bodů nebo fondů koncových bodů, bez ohledu na zvolenou metodu řízení provozu.

Váha je definována jako libovolné číslo mezi 0.00 a 1.00. Je důležité mít na paměti, že celková váha fondů koncových bodů nebo koncových bodů v rámci jednoho fondu nemusí dát dohromady 1. Jednotlivé váhy se místo toho sečtou a hodnota konkrétní váhy se pak vydělí tímto součtem, čímž se získá pravděpodobnost výběru daného koncového bodu.

Rovnice pro převod váhy na procenta: (váha koncového bodu) ÷ (součet všech vah ve fondu) = (% provozu směřujícího na koncový bod)

Níže najdete několik příkladů s diagramy, které pomohou pochopit, jak se váha (weight) používá k rozdělování provozu. V těchto příkladech se předpokládá, že cílem je rovnoměrně rozdělit provoz mezi všechny koncové body se stejnou kapacitou nebo výpočetními prostředky. Random směrování provozu bude použito k demonstraci rozložení provozu mezi třemi pooly koncových bodů.

Příklad 1:

• Jsou definovány tři fondy koncových bodů, všechny s váhou 1
• Každý pool koncových bodů má 33% pravděpodobnost výběru

Příklad výpočtu pro váhu 1: (1) ÷ (1 + 1 + 1) = (.3333) (neboli 33.33%)

V tomto příkladu bylo jednoduché nastavit hodnotu váhy 1 pro všechny skupiny koncových bodů. Je však třeba poznamenat, že bylo možné použít jakékoli číslo mezi 0,01 a 1,00, pokud by se stejné číslo použilo u všech tří skupin koncových bodů. Kdyby se například u všech tří skupin nastavila hodnota 0,1 nebo dokonce 0,7, výsledkem by byla stejná pravděpodobnost výběru každé skupiny pro příjem provozu.

Protože se součet vah používá k výpočtu pravděpodobnosti, mohou organizace pro snazší srozumitelnost použít libovolné hodnoty. V následujících příkladech má každý koncový bod stejnou kapacitu, proto je každému přiřazena váha .1, a součet těchto hodnot se použije jako váha fondu koncových bodů.

Příklad 2

• Jsou definovány tři fondy koncových bodů
• Každý pool koncových bodů má jiný počet koncových bodů, ale všechny koncové body mají stejnou kapacitu
• Aby bylo možné zátěž rovnoměrně rozložit mezi koncové body, potřebuje každý fond koncových bodů odlišnou pravděpodobnost

Příklad výpočtu pro váhu .4 : (.4) ÷ (.4 + .5 + .6) = (.2667) (neboli 26.67%)

Příklad výpočtu pro váhu .5 : (.5) ÷ (.4 + .5 + .6) = (.3333) (neboli 33.33%)

Příklad výpočtu pro váhu .6 : (.6) ÷ (.4 + .5 + .6) = (.4000) (neboli 40.00%)

Koncové body nemusí mít vždy stejnou kapacitu. V následujícím příkladu má jeden z koncových bodů v poolu koncových bodů dvojnásobnou kapacitu oproti koncovým bodům ve zbylých dvou poolech.

Příklad 3

• Jsou definovány tři fondy koncových bodů
• Fond endpointů 1 obsahuje endpointy s dvojnásobnou kapacitou oproti endpointům ve fondu endpointů 2 a fondu endpointů 3
• Cílem je směrovat do endpoint pool 1 na jeden endpoint dvojnásobné množství provozu
• Fond endpointů 1 má 4 endpointy, ale s dvojnásobnou kapacitou, takže váha každého endpointu bude .2, což dává dohromady .8 pro celý fond endpointů

Příklad výpočtu pro váhu .8 : (.4) ÷ (.8 + .5 + .6) = (.4211) (neboli 42.11%)

Příklad výpočtu pro váhu .5 : (.5) ÷ (.8 + .5 + .6) = (.2632) (neboli 26.32%)

Příklad výpočtu pro váhu .6 : (.6) ÷ (.8 + .5 + .6) = (.3157) (neboli 31.57%)

V tomto posledním příkladu mají čtyři koncové body ve skupině koncových bodů 1 dvojnásobnou kapacitu oproti ostatním koncovým bodům, takže výpočet zachází se skupinou 1, jako by měla fakticky 8 koncových bodů místo 4. Proto je hodnota váhy 0,8 místo 0,4, jak je uvedeno v příkladu 2.

Toto jsou jen tři jednoduché příklady, které ukazují, jak lze pomocí váhy rozkládat zátěž mezi fondy koncových bodů nebo mezi koncovými body. Stejné výpočty se používají i pro váhy přiřazené koncovým bodům uvnitř fondu koncových bodů. Dopad použití vah se u jednotlivých metod směrování v zásadě podobá, byť s mírně upravenými výpočty, jak popisují následující části.

Váhy se nejvíc hodí v situaci, kdy má jeden fond koncových bodů více prostředků než jiný, nebo když koncové body v rámci jednoho fondu nemají stejnou kapacitu. Váha pomáhá zajistit, aby byly všechny prostředky využívány rovnoměrně vzhledem ke svým možnostem.

Off - failover je nejzákladnější zásada směrování provozu. Pořadí fondů koncových bodů slouží jako seznam priorit pro výběr fondu, do kterého se má provoz směrovat. Pokud je první fond v seznamu funkční a schopný přijímat provoz, vybere se právě on. Jelikož off - failover není k dispozici pro směrování koncových bodů, použije se pro výběr koncového bodu jiná metoda. Off - failover se běžně používá ve scénářích aktivního a pasivního přepnutí při selhání, kdy provoz zajišťuje primární datové centrum nebo skupina koncových bodů a teprve při výpadku se provoz přesměruje na záložní fond koncových bodů.

Random steering je k dispozici jak pro řízení provozu, tak pro řízení koncových bodů. Random rozděluje provoz mezi prostředky podle váhy definované v konfiguraci load balanceru i v rámci fondu koncových bodů. Hodnoty váhy nastavené na load balanceru pro jednotlivé fondy koncových bodů se mohou lišit od váhy nastavené pro jednotlivý koncový bod uvnitř daného fondu. Pokud je například v konfiguraci load balanceru 70% provozu směrováno do jednoho ze dvou fondů koncových bodů, uvnitř tohoto fondu pak může být provoz rovnoměrně rozdělen mezi čtyři koncové body. Předchozí část, vážené směrování, podrobně vysvětluje, jak se používá váha (weight) a jaké výpočty určují výběr fondu koncových bodů nebo koncového bodu.

Hašovací směrování je algoritmus směrování koncových bodů, který k výběru koncového bodu využívá váhu koncového bodu a zdrojovou IP adresu požadavku. Výsledkem je, že každý požadavek ze stejné IP adresy bude vždy směrován na stejný koncový bod. Je důležité mít na paměti, že změna pořadí koncových bodů nebo přidání či odebrání koncových bodů z fondu koncových bodů může při použití hašovacího algoritmu vést k odlišným výsledkům.

Geografické směrování je algoritmus směrování provozu určený zákazníkům s plánem Enterprise, který slouží k přiřazení fondů koncových bodů ke konkrétním zemím nebo geografickým regionům. Tato možnost může zlepšit výkon tím, že provoz směruje na koncové body blíže uživatelům. Zároveň pomáhá dodržovat zákony a předpisy, protože požadavky uživatelů z konkrétních regionů směruje na prostředky ve stejném regionu, případně na prostředky navržené tak, aby splňovaly dané regulační požadavky.

Dynamické směrování je algoritmus směrování provozu dostupný pro zákazníky s plánem enterprise, který vytváří profily doby odezvy (round trip time, RTT). Hodnoty RTT se sbírají při každém požadavku health probe a vycházejí z odpovědi koncového bodu na monitorovací požadavek. Když přijde požadavek, Cloudflare zkontroluje data RTT a seřadí pooly podle jejich hodnot RTT. Pokud pro váš pool v dané oblasti nebo kolokačním centru žádná data RTT ještě neexistují, Cloudflare směruje provoz do poolů v pořadí podle failover. Při prvním zapnutí dynamického směrování pro pool koncových bodů počítejte s tím, že se změna projeví až za 10 minut, protože si Cloudflare musí pro daný pool vytvořit profil RTT. Dynamické směrování při rozhodování nebere v úvahu geografické hranice a zaměřuje se výhradně na výběr poolu koncových bodů s nejnižší hodnotou RTT.

Proximity steering je algoritmus směrování provozu dostupný zákazníkům s plánem Enterprise, který směruje provoz do nejbližšího fyzického datového centra na základě místa vzniku požadavku.

Cloudflare určuje fyzickou polohu žadatele pomocí následujících metod, a to v tomto pořadí:

1. EDNS Client Subnet ↗ informace, pokud jsou uvedeny v požadavku DNS
2. Informace o geolokaci resolveru použitého k připojení ke Cloudflare
3. GPS poloha datacentra Cloudflare, které požadavek zpracovává

Proximity steering vyžaduje zadání souřadnic GPS pro všechny pooly koncových bodů, což Cloudflare umožňuje vypočítat nejbližší pool koncových bodů na základě IP adresy žadatele, resolveru DNS nebo datového centra Cloudflare.

Least outstanding request steering (LORS) je k dispozici zákazníkům s enterprise plánem a lze ji použít jak pro směrování provozu, tak pro směrování koncových bodů.

LORS ovlivňuje směrování podle počtu nezodpovězených HTTP požadavků a funguje pouze u Cloudflare Load Balancerů proxovaných na vrstvě 7 (Layer 7). Pokud je LORS přiřazen jinému typu load balanceru, chová se stejně jako náhodné směrování. LORS kombinuje počet otevřených požadavků s vahou a vytváří tak novou transformovanou váhu, která se použije při rozhodování o směrování.

Rovnice pro transformovanou váhu LORS:

• weight / (count + 1) = transformedWeight

Připomenutí k výpočtu náhodné váhy:

• weight / (total weight) = probability of being selected

Zde je příklad LORS:

• Pool A má váhu 0.4
• Pool B má váhu 0.6
• Pool A má 3 otevřené požadavky
• Pool B má 0 otevřených požadavků
• Relevantní rovnice
  • weight / (count + 1) = transformedWeight
• Transformovaná váha Pool A: 0.4 / (3 + 1) = 0.1
• Transformovaná váha Pool B: 0.6 / (0 + 1) = 0.6
• Relevantní rovnice
  • weight / (total weight) = probability of being selected
• Pravděpodobnost směrování na Pool A: 0.1 / (0.1+0.6) = .1429 (14.29%)
• Pravděpodobnost směrování na Pool B: 0.6 / (0.1+0.6) = .8571 (85.71%)

V tomto příkladu má další spojení 14,29% pravděpodobnost, že bude nasměrováno do Pool A, a 85,71% pravděpodobnost, že bude nasměrováno do Pool B. Provoz sice pravděpodobně poputuje do Pool B, přesto je možné, že bude nasměrován do Pool A. Při nižší zátěži bude ve výsledcích směrování větší variabilita, která nemusí přesně odpovídat nakonfigurovaným váhám. Se zvyšující se zátěží se ale skutečné výsledky směrování budou nakonfigurovaným váhám blížit stále více.

Když se s LORS používají load balancery proxované mimo vrstvu L7, informace o počtu otevřených požadavků nejsou k dispozici. Jmenovatel proto bude vždy roven 1. Protože dělení libovolného čísla jedničkou nemění čitatele, a tím čitatelem je v tomto případě váha, rozhodnutí o směrování se budou opírat výhradně o váhu. Výsledkem je náhodná metoda popsaná výše.

LORS se nejlépe uplatní tam, kde skupiny koncových bodů nebo jednotlivé koncové body snadno zahltí nárazové zvýšení počtu souběžných požadavků. Hodí se pro aplikace, které dávají stavu koncových bodů vyšší prioritu než faktorům jako latence, geografická blízkost nebo jiné metriky. Zvlášť užitečné je to tam, kde některé nebo všechny požadavky výrazně zatěžují koncový bod a jejich zpracování trvá dlouho.

Všechny metody řízení provozu (traffic steering) uvedené výše jako dostupné pouze pro Enterprise lze rovněž získat jako samoobslužný doplněk. Všechny metody směrování na koncové body označené jako Enterprise Only vyžadují plán Enterprise u Cloudflare.

Health monitor určuje stav koncových bodů po jejich nakonfigurování ve fondu koncových bodů. Health monitory generují sondy, tedy pokusy o připojení ke koncovým bodům, a na základě odpovědí na tyto sondy zaznamenávají stav koncového bodu. Health monitory slouží jako šablony, které obsahují typ služby, cestu a port, a dále pokročilé funkce, jako je interval, timeout a nastavení specifická pro protokol používaná k hodnocení stavu koncového bodu. Šablona health monitoru se pak použije na fond koncových bodů, který obsahuje koncové body hostující podobné služby. Jakmile je health monitor připojen k fondu koncových bodů, adresa koncového bodu se použije jako cíl sondy health monitoru. Jeden health monitor lze použít napříč mnoha fondy koncových bodů, health monitory jsou objekty na úrovni účtu a lze je tak využívat ve více zónách v rámci stejného účtu Cloudflare.

Sondy health monitoru se standardně odesílají přímo na adresu koncového bodu a obcházejí celý zásobník vrstvy 7. To znamená, že skutečný provoz směřující ke koncovému bodu přes load balancer se zpracovává jinak než sonda health monitoru. V závislosti na konfiguraci pak může health monitor hlásit koncový bod jako funkční, i když skutečná připojení nebo požadavky selhávají.

Funkce Simulate Zone zajišťuje, že sondy health monitoru procházejí stejnou cestou jako požadavky HTTP/HTTPS vrstvy 7 pro danou zónu, a to prostřednictvím stejného softwarově definovaného směrování Cloudflare pro odchozí provoz k originu. Health monitory tak procházejí sítí Cloudflare a dalšími procesy vrstvy 7 stejnou cestou, aby dosáhly originového koncového bodu.

Funkce Simulate Zone je pro health monitory vyžadována, pokud jsou na úrovni zóny povoleny určité funkce, například Authenticated Origin Pulls nebo Bring your own CA, kde by sondy selhaly, pokud by neměly k dispozici správný certifikát mTLS nebo autoritu potřebnou k ověření vůči origin serveru. Simulate Zone navíc zajišťuje, že sondy Health Monitoru používají stejnou cestu, jakou zadává Argo Smart Routing a stejný Dedicated CDN Egress IPs když organizace využívají Smart Shield Advanced k omezení edge IP adres, které Cloudflare používá k dosažení jejich koncových bodů.

Sondy monitoru stavu lze nakonfigurovat jako následující typy:

• HTTP
• HTTPS
• TCP
• UDP ICMP
• ICMP Ping
• SMTP
• LDAP

Jakmile je monitor stavu definován, lze ho přiřadit koncovému bodu a sondy se na něj budou odesílat v nastaveném intervalu. V konfiguraci monitoru stavu v rámci fondu koncových bodů stojí za zmínku ještě dvě další nastavení. Prvním je Health Threshold, který určuje, kolik koncových bodů ve fondu musí být funkčních, aby byl fond koncových bodů považován za funkční, nebo za degradovaný.

• Fond endpointů ve stavu zdravý
  • Obsahuje pouze zdravé koncové body
• Fond endpointů ve stavu degradovaný
  • Obsahuje alespoň jeden kritický koncový bod, ale zůstává na hodnotě prahu stavu nebo nad ní
• Fond endpointů ve stavu kritický
  • Obsahuje zdravé koncové body pod prahem stavu
  • Není schopen zpracovávat provoz; je vyřazen ze všech rozhodování o směrování.

Druhým nastavením po definování health monitoru v endpoint pool je určení, ze kterých regionů v rámci globální sítě Cloudflare mají probíhat sondy health monitoru. Dostupné možnosti jsou uvedeny níže:

• Všechny regiony (výchozí)
• Všechna datová centra (pouze Enterprise)
• Západní Severní Amerika
• Východní Severní Amerika
• Západní Evropa
• Východní Evropa
• Severní část Jižní Ameriky
• Jižní část Jižní Ameriky
• Oceánie
• Blízký východ
• Severní Afrika
• Jižní Afrika
• Jižní Asie
• Jihovýchodní Asie
• Severovýchodní Asie

S výjimkou možností „All Regions“ a „All Data Centers“ vycházejí sondy health monitoru pouze z datacenter ve vybraném regionu nebo regionech. U služeb s lokálním významem nemusí záležet na tom, zda k daným koncovým bodům dosáhne i datacentrum na druhé straně světa. Omezení kontrol na konkrétní region nebo skupinu regionů proto může dávat smysl. Volba „All Regions“ nebo „All Data Centers“ je určená pro globálně dostupné služby, u kterých může být dosažitelnost dané skupiny koncových bodů pro fungování aplikace klíčová.

Endpointy jsou skutečné servery, které po uplatnění všech zásad load balanceru zpracovávají spojení a požadavky. Mohou to být fyzické servery, virtuální stroje nebo bezserverové aplikace. Pokud dokážou obsloužit požadavek nebo spojení od uživatele či klienta, považují se za endpoint. Existuje několik způsobů, jak endpointy definovat a připojit ke Cloudflare, a další část je popisuje podrobněji.

Koncové body Cloudflare lze definovat dvěma způsoby: pomocí IP adresy nebo pomocí hostname. IP adresy představují nejjednodušší a nejzákladnější způsob připojení, u hostname je třeba zvážit několik možností. Hostname lze v DNS Cloudflare definovat se stavem Proxied, nebo jako DNS only (bez proxy). Další možností samozřejmě je, že hostname nepatří do domény, pro kterou je Cloudflare autoritativním DNS serverem, což znamená, že se Cloudflare při překladu tohoto hostname na IP adresu spoléhá na externí DNS servery. Použít lze také Cloudflare Tunnel, který rovněž nabízí dvě různé možnosti. Těmito metodami se zabývá zbytek této části.

Jak již bylo zmíněno výše v části „HTTP(S) Load Balancing“, load balancing je úplně posledním procesem, který proběhne předtím, než je požadavek odeslán na koncový bod. I když je ale koncový bod proxovaný přes edge Cloudflare, požadavek se po průchodu load balancerem přeposílá přímo na koncový bod, aniž by znovu procházel vrstvou 7. To ale neznamená, že koncový bod zůstává nechráněný nebo mimo mezipaměť: pokud je proxovaný samotný load balancer, všechny tyto ochrany se uplatňují na load balancer, nikoli na koncové body. Přímá komunikace s koncovým bodem může být stále proxovaná a zpracovaná vrstvou 7 Cloudflare, avšak komunikace s koncovým bodem umísťuje veškeré zpracování před load balancer, nikoli před koncový bod. Obrázek 19 znázorňuje rozdíl v tom, kde se vrstva 7 Cloudflare nachází ve vztahu ke koncovému bodu (koncovým bodům).

Z pohledu load balanceru je jedno, jaký typ koncového bodu je v rámci fondu koncových bodů definován, rozdíly jsou minimální. Jakmile se uplatní zásady směrování provozu a koncových bodů spolu s pravidly load balanceru, služba Cloudflare Load Balancing určí vrstvě L7, kam má příchozí požadavek nebo spojení přesměrovat. Tento požadavek je odeslán přímo na koncový bod. V závislosti na typu připojení ke koncovému bodu se cesta může lišit. Funkce jako Argo Smart Routing nebo koncové body připojené přes tunel a ukončené v jiných datacentrech Cloudflare směrují provoz jinak, než kdyby byl požadavek odeslán z edge sítě Cloudflare přes internet přímo na koncový bod. Bez ohledu na zvolenou cestu je ale load balancing posledním procesem v této vrstvě, takže provoz už žádné další zpracování nedostává. Připojení ke koncovému bodu tedy může změnit cestu od Cloudflare ke koncovému bodu, ale jakmile je koncový bod vybrán, způsob zpracování se dál nemění.

Cloudflare Tunnel je odchozí spojení, díky kterému mohou organizace zjednodušit konfiguraci firewallu, snížit složitost, posílit zabezpečení a snadněji připojit svá aktiva k síti Cloudflare. Spustitelný soubor, který tyto tunely vytváří, se nazývá cloudflared a v tomto dokumentu i v následujících diagramech na něj může být odkazováno.

Cloudflare Tunnel (cloudflared) lze nainstalovat přímo na koncový bod nebo na libovolný server s IP konektivitou k tomuto koncovému bodu. Protože se spojení s Cloudflare navazuje z místa, kam byl Cloudflare Tunnel nainstalován, směrem ke Cloudflare, stačí pro něj pouze odchozí přístup ke Cloudflare. Jeden Cloudflare Tunnel dokáže přenášet provoz k jednomu nebo více různým koncovým bodům dvěma způsoby: jedním, díky kterému je koncový bod veřejně přístupný, a druhým, který jej ponechává přístupný výhradně privátně.

Cloudflare Tunnel lze nainstalovat přímo na koncový bod nebo na libovolný server s konektivitou na vrstvě 3 (IP) ke koncovému bodu či koncovým bodům, které je třeba připojit ke Cloudflare. Rozhodnutí oddělit cloudflared může mít řadu důvodů, například izolaci koncových bodů a zajištění jejich výkonu, existenci samostatných týmů spravujících síťovou konektivitu a koncové body, nebo oddělení kvůli architektonické jednoduchosti tam, kde mají servery oddělené role a odpovědnosti.

Jedna instance cloudflared vytvoří 4 různé tunely, dva tunely ve dvou různých datových centrech Cloudflare. Tento model zajišťuje vysokou dostupnost a snižuje riziko výpadku jednotlivých spojení. To znamená, že pokud dojde k výpadku jednoho spojení, serveru nebo datového centra, koncové body zůstanou dostupné. Cloudflare Tunnel navíc umožňuje organizacím nasadit další instance cloudflared pro scénáře dostupnosti a failoveru. Tyto samostatné instance se nazývají repliky. Každá replika vytváří čtyři nová spojení, která slouží jako další vstupní body ke koncovému bodu (koncovým bodům). Všechny repliky směřují do stejného tunelu, což zajišťuje, že vaše síť zůstane dostupná i v případě výpadku jediného hostitele, na kterém cloudflared běží. Repliky ze své podstaty nenabízejí žádnou formu řízení provozu (random, hash ani round-robin).

Metoda veřejného endpointu umožňuje organizacím definovat tunel, který směřuje ke konkrétní službě nebo portu běžícímu na endpointu. Tunel může končit přímo na endpointu, nebo na jakémkoli serveru s IP konektivitou k danému endpointu. Použití této metody veřejného hostname vyžaduje, aby každá služba, ke které se bude přistupovat přes tunel, byla definována v konfiguraci tunelu. Po nakonfigurování se pro IP adresu a port nebo službu, ke které tunel provoz připojuje, vytvoří jedinečné ID tunelu, například d74b3a46-f3a3-4596-9049-da7e72c876f5. Toto ID tunelu se poté promítne do jedinečného veřejného hostname v doméně cfargotunnel.com, kterou vlastní Cloudflare, čímž vznikne záznam DNS A směřující přímo k dané službě, tedy d74b3a46-f3a3-4596-9049-da7e72c876f5.cfargotunnel.com. Ačkoli je tento hostname veřejný, přistupovat k němu nebo jej využívat může pouze provoz odeslaný přes účet, kterému konfigurace Cloudflare Tunnel patří. Žádný jiný účet nemůže k této adrese DNS přistupovat ani na ni přímo odesílat provoz. Záznam DNS CNAME vytvořený mimo účet, kterému hostname cfargotunnel.com patří, nebude moci provoz přes daný Cloudflare Tunnel odesílat.

Při konfiguraci přes Dashboard Cloudflare automaticky vytvoří v zóně DNS záznam CNAME odkazující na název hostitele cfargotunnel.com. Vytvořit lze například záznam CNAME myTunnelService.example.com, který by odkazoval na záznam A d74b3a46-f3a3-4596-9049-da7e72c876f5.cfargotunnel.com. Hlavní výhodou je snadné použití a správa, protože záznam CNAME mnohem lépe napovídá svůj účel a patří do zákaznické zóny DNS.

Další možností je vytvořit tyto tunely a služby na hostiteli, na kterém běží cloudflared. Označuje se to jako lokálně spravovaný tunel. Při práci s lokálně spravovanými tunely se záznam CNAME nevytváří automaticky, takže jej organizace musí po definování tunelu a služby nastavit ručně.

Z pohledu load balanceru je velmi důležité pochopit, jak lze tyto tunely použít jako endpoint. Endpoint lze definovat pouze pomocí hostname cfargotunnel.com. Použití veřejného CNAME záznamu, který směřuje na adresu cfargotunnel.com, nebude fungovat správně a není podporováno. To je obzvlášť důležité u endpointových služeb, které neběží na portu 80 nebo 443, protože Cloudflare Load Balancers standardně přistupují ke službám na endpointech právě přes tyto dva porty. Pokud má organizace služby běžící na jiných portech, bude muset nakonfigurovat Cloudflare Tunnel s pravidlo catch-all k dosažení daného portu. Tato konfigurace umožňuje Cloudflare Load Balanceru přistupovat ke službě přes port 443, zatímco Cloudflare tunnel proxíruje připojení na požadovaný port na koncovém bodu.

Druhá metoda se týká privátních podsítí. Umožňuje organizacím definovat privátní IP adresy a masku podsítě, které se použijí k vytvoření privátní virtuální sítě v rámci globální sítě Cloudflare. Metoda privátní podsítě neumožňuje definovat port, a jakmile jsou tedy podsíť a maska definovány, je přes daný tunel dostupná celá podsíť, avšak pouze pro uživatele organizace, kterým přístup povolují definované zásady Zero Trust.

Tato podsíť se poté přidá do virtuální sítě uvnitř Cloudflare, kde zákazník může řídit, jak a kteří uživatelé k ní mají přístup. Podsíť lze definovat pro libovolné potřebné rozdělení na podsítě nebo směrování, včetně použití 32bitové masky (jediná IP adresa, například 10.0.0.1/32). Povolená podsíť navíc nemusí existovat na hostiteli, na kterém běží proces cloudflared. Postačí konektivita na vrstvě 3 nebo IP konektivita mezi hostitelem, na kterém běží cloudflared, a podsítí, která má být dostupná přes Cloudflare Tunnel.

V rámci fondu koncových bodů (endpoint pool) je k dispozici několik konfiguračních možností. Tato část popisuje, o jaké možnosti jde a jak ovlivňují chování Cloudflare Load Balanceru.

První konfigurace, kromě definování názvu a popisu poolu koncových bodů, spočívá v určení metody řízení koncových bodů (endpoint steering). Endpoint steering nakonec rozhoduje o tom, který pool koncových bodů nebo koncový bod obdrží požadavek nebo pokus o připojení (viz Metody směrování s podrobným popisem jednotlivých metod).

Jednotlivé koncové body se definují v rámci skupin koncových bodů, přičemž skupina koncových bodů umožňuje definovat jeden nebo více koncových bodů na skupinu.

• název koncového bodu se používá především pro referenci, reportování a analytiku; nemá vliv na funkci load balanceru ani fondu endpointů.
• adresa endpointu, nicméně definuje prostředek, který může load balancer použít ke zpracování požadavku nebo připojení.
  • Endpointy ve fondu endpointů musí být dostupné na portu 80 nebo 443. Pokud endpoint na portu 80 nebo 443 neposlouchá, je potřeba před něj umístit proxy službu nebo zařízení pro přesměrování síťových portů, které port 80 nebo 443 namapuje na port, na kterém služba skutečně naslouchá.
  • Další metodou mapování portů koncových bodů na 80 nebo 443 je připojení ke službě koncového bodu pomocí Cloudflare Tunnel, a poté použijte hostitelský název vytvořený tímto postupem jako adresu koncového bodu. Tím se zamýšlený port koncového bodu automaticky namapuje na port 443.

Adresa koncového bodu lze definovat některým z následujících způsobů:

• Veřejně směrovatelná IP adresa
• Veřejně dostupný hostname proxovaný přes Cloudflare
• Veřejně dostupný název hostitele mimo Cloudflare
• Privátní, veřejně nesměrovatelná IP adresa s výběrem virtuální sítě

Použití veřejných IP adres a hostitelských názvů jakéhokoli typu nevyžaduje žádnou další konfiguraci. V takových scénářích by měla být virtuální síť nastavena na výchozí hodnotu „žádné“. „žádné“ nastavení signalizuje, že tyto zdroje budou přístupné na veřejném internetu, směrované přes globální edge síť společnosti Cloudflare.

Použití virtuální síť je vyhrazena pro privátní IP prostředky. Toto nastavení odpovídá podsítím IP, které jsou umístěny za Konfigurace Cloudflare Tunnel. Měli byste vybrat virtuální síť, která má trasu k IP adrese koncového bodu. Toto nastavení v Cloudflare Dashboard najdete tak, že vyberete Networks - Routes ze stránky Zero Trust.

Váha endpointu se používá pouze u metod řízení provozu random, hash a least outstanding request; musí být vždy definováno jako součást definice endpointu. (Více informací najdete v Vážené směrování s dalšími informacemi o tom, jak se váhy používají při výběru endpointu.)

Fondy endpointů umožňují upravit hlavičku Host ještě před odesláním požadavku na endpoint. Toto nastavení platí jen pro load balancer vrstvy 7 (HTTP(S)) a při použití s load balancery vrstvy 4, včetně private IP a Spectrum, se ignoruje.

U load balanceru vrstvy 7, kde jsou požadavky založené na HTTP(S), sděluje hlavička Host koncovému bodu, o jaký web se jedná, protože jeden koncový bod může hostovat několik různých webových domén. Pokud je koncový bod nakonfigurovaný speciálně pro hostování konkrétní webové domény, může na požadavek na zdroj buď neodpovědět, nebo poslat chybovou odpověď, pokud se domnívá, že daný zdroj z hlavičky Host nehostuje (tedy pokud si hlavičky Host neodpovídají).

Například:

• Představme si, že se uživatel pokusí připojit k www.example.com. Load balancer se nakonfiguruje s hostname www.example.com k přijímání všech požadavků.
• Protože koncové body nemohou mít v DNS stejný veřejný hostname, jejich hostname je endpoint1.example.com.
• Když uživatel odešle požadavek na www.example.com, bude hlavička Host nastavena na www.example.com, a to rovněž. Koncový bod bude nutné nakonfigurovat tak, aby reagoval na hlavičky Host s hodnotou www.example.com.
• V některých případech (například u určitých cloudových nebo SaaS aplikací) však koncové body tímto způsobem konfigurovat nelze, takže koncový bod může obdržet požadavek s neznámou hlavičkou Host a nedokáže na něj správně odpovědět.
• V tomto příkladu se v konfiguraci koncového bodu nastavuje hlavička Host koncového bodu na adresu koncového bodu endpoint1.example.com nahradí hlavičku Host u www.example.com hodnotou endpoint1.example.com, a umožní koncovému bodu na tento požadavek správně reagovat.

Obrázek 21 zdůrazňuje potenciální problém s neshodujícími se hlavičkami Host:

U poolu koncových bodů lze rovněž definovat GPS souřadnice poolu (které se používají u směrování podle blízkosti, proximity steering). Pokud se proximity steering nepoužívá, tyto souřadnice nejsou vyžadovány (viz Proximity Steering).

Odlehčení zátěže : reakce v reálném čase dostupná administrátorům pro ochranu před koncovými body v poolu, které jsou přechod do nezdravého stavu : je nakonfigurován také v poolu koncových bodů.

Nastavení load shedding se má zapínat jen tehdy, když se administrátor snaží aktivně chránit endpoint pool před tím, aby se stal nezdravým. Aktivuje se například tehdy, když endpoint sice na požadavky ještě odpovídá, ale vykazuje zvýšené využití CPU nebo paměti, delší dobu odezvy, případně občas na požadavky vůbec neodpoví.

Když se stav fondu koncových bodů začne zhoršovat, odlehčení zátěže (load shedding) může pomoci přesměrovat část stávající zátěže z jednoho fondu koncových bodů do jiného.

V závislosti na stavu endpoint poolu může stačit nové požadavky a spojení jednoduše odmítat nebo přesměrovávat mimo daný endpoint pool. Tato zásada se vztahuje na provoz, na který se nevztahují žádná pravidla session affinity, protože jde o nová spojení, pro která ještě nebyl vybrán endpoint pool ani konkrétní endpoint (a tudíž nemůže dojít k ovlivnění koncové uživatelské zkušenosti).

Pokud se fond koncových bodů kvůli zátěži blíží kritickému selhání, další možností je odlehčit i provoz vázaný session affinity. Tím se začnou přesměrovávat i požadavky a připojení, která jsou k fondům koncových bodů vázána prostřednictvím session affinity. Je však třeba mít na paměti, že tento proces může nakonec změnit koncový bod uživatele, což může ovlivnit jeho zážitek. Dopad v konečném důsledku závisí na tom, jaká aplikace je vyvažována zátěží a jak velký kontext připojení je mezi koncovými body sdílený.

Monitory stavu jsou k koncovým bodům přiřazeny na úrovni fondu koncových bodů, stejně jako práh stavu a výběr oblasti kontroly stavu. Podrobnosti o těchto možnostech najdete v monitor stavu sekce.

Load balancing v Cloudflare spojuje GTM i Private Network Load Balancing do jediné konfigurace load balanceru. Některé funkce nebo pojmy se sice více vážou k GTM nebo k Private Network Load Balancing, ale zákazníkům Cloudflare se obojí nabízí jako jedna snadno správitelná instance.

Podle konkrétního případu použití mohou organizace využívat různé typy Cloudflare Load Balancers. Následující část popisuje hlavní rozdíly mezi jednotlivými modely nasazení a vysvětluje, kdy je vhodné použít který typ load balanceru.

Obrázek 22 zdůrazňuje všechny možné kombinace load balancerů a koncových bodů podporované Cloudflare:

Cloudflare nabízí tři modely nasazení load balancingu, z nichž každý podporuje odlišné případy užití, funkce a požadavky na ochranu soukromí.

• Load balancing na vrstvě 7 HTTP(S)
• DNS-only vyvažování zátěže
• Load balancing Spectrum

Kromě možnosti DNS-only load balancingu popsané podrobněji níže všechny modely nasazení směrují provoz přes load balancer. To znamená, že uživatel nebo klient vytvářející požadavek či spojení se o endpointech, které jej obsluhují, vůbec nedozví. Informace o endpointu lze sice v případě potřeby zpřístupnit pomocí hlaviček, ale u žádného z těchto ukotvených modelů nasazení to není výchozí chování.

Následující část podrobněji popisuje čtyři hlavní modely nasazení a jejich rozdíly.

Nejprve je nejběžnějším modelem Proxovaný load balancer na vrstvě 7 založený na HTTP(S). Tyto load balancery běží na okrajové síti Cloudflare a jsou veřejně dostupné. Tento model mimo jiné podporuje WebSockets, což jsou otevřená spojení mezi klientem a koncovým bodem, která umožňují obousměrný přenos dat mezi oběma stranami.

Protože stejný zásobník zabezpečení na vrstvě 7 zajišťuje také WAF, ochranu před útoky DDoS, Bot Management, Zero Trust a další služby, lze přístup k těmto veřejným load balancerům podle potřeby omezit jen na ověřené a autorizované uživatele. (Více informací najdete v Zabezpečení load balancerů s dalšími informacemi.)

V rámci této vrstvy 7 může load balancing dále zlepšit výkon, spolehlivost a dostupnost veřejně přístupných webových prostředků organizace. Koncové body těchto load balancerů mohou být nasazeny ve veřejném cloudu, privátním cloudu, on-premises nebo v jakékoli jejich kombinaci v rámci jednoho load balanceru. (Viz Připojení koncových bodů ke Cloudflare s dalšími podrobnostmi o tom, jak připojit koncové body k okrajové síti Cloudflare).

Jak ukazuje výše uvedený obrázek 23, komponenta load balancingu ve vrstvě 7 je posledním procesem, kterým požadavek na cestě ke koncovému bodu projde. To může výrazně přispět ke zvýšení výkonu a snížení zátěže koncových bodů.

Cachování může například zabránit tomu, aby požadavky vůbec dosáhly endpointu, a lze na ně odpovědět, aniž by bylo nutné zapojit load balancery. WAF, ochrana proti DDoS a Bot Management navíc dokážou útočný provoz zcela eliminovat, čímž zůstává více kapacity pro legitimní provoz.

Jakmile požadavek dorazí do procesu load balanceru, vždy se odešle přímo na vybraný koncový bod. To znamená, že i když je koncový bod proxovaný přes Cloudflare, požadavek se odešle přímo na koncový bod a dále se už nijak nezpracovává.

Pro přizpůsobené zacházení poté, co load balancer vybere endpoint, se uplatní Custom Rules load balanceru. (Podrobně je to popsáno v Load balancery níže).

Důležité poznámky k load balancerům Layer 7 HTTP(S):

• Load balancery na vrstvě 7 HTTP(S) podporují veřejné i privátní koncové body
• Load balancery na vrstvě 7 HTTP(S) budou podporovat pouze provoz HTTP(S) a WebSocket
• Zásady Zero Trust lze uplatnit na load balancery vrstvy 7 HTTP(S)

DNS-only load balancer Cloudflare je neproxovaný load balancer. To znamená, že přes edge Cloudflare prochází pouze počáteční DNS dotaz na daný zdroj, nikoli samotný provoz. Místo toho, aby se DNS dotaz přeložil na IP adresu Cloudflare a poté procházel vrstvou 7 stacku, jak bylo vidět dříve na obrázku 7, přijme Cloudflare v tomto případě DNS dotaz na DNS-only load balancer, uplatní všechny příslušné politiky load balancingu a poté vrátí IP adresu žádajícímu klientovi, který se pak k cíli připojí přímo.

Veškerý provoz mezi klientem a koncovým bodem probíhá přímo mezi nimi a neprochází vrstvou 7 v zásobníku Cloudflare, takže load balancer typu DNS-only dokáže podporovat jakýkoli typ IP provozu.

I když Cloudflare tyto typy spojení load balanceru neproxuje, služba kontroly stavu přesto sleduje stav všech endpointů ve fondu. Podle stavu nebo dostupnosti endpointu pak Cloudflare DNS-only load balancer buď přidá, nebo odebere příslušný endpoint z DNS odpovědi, aby byl provoz vždy směrován na funkční endpointy.

Jakmile load balancer pracující pouze s DNS vybere pomocí traffic steering pool koncových bodů, odpověď DNS může obsahovat jednu nebo více IP adres.

Rozhodnutí, zda odeslat v odpovědi DNS jednu nebo více IP adres, vychází z váhy přiřazené koncovým bodům ve vybraném poolu koncových bodů:

• Pokud mají všechny koncové body stejnou váhu, v odpovědi DNS se vrátí IP adresy všech koncových bodů.
• Pokud má v rámci fondu koncových bodů alespoň jeden koncový bod nastavenou jedinečnou váhu, v odpovědi DNS se vrátí jen jedna IP adresa, a to bez ohledu na metodu směrování koncových bodů zvolenou pro daný fond.

Organizace tak mají možnost buď nechat aplikace, aby znaly všechny koncové body a prováděly lokální přepnutí při výpadku (failover), nebo nechat Cloudflare poskytnout aplikaci jedinou IP adresu.

Obrázek 27 ukazuje, jak definovaná váha v rámci fondu koncových bodů může ovlivnit odezvu load balanceru pouze pro DNS.

Mějte na paměti, že load balancery v režimu pouze DNS mají ve srovnání s proxovanými load balancery určitá omezení:

• Load balancer už před klientem neskrývá IP adresu endpointu, protože se klientovi odesílá přímo.
• Nemají vestavěné služby vrstvy 7 zmíněné v předchozím modelu; load balancery typu pouze DNS tedy nezahrnují cachování, WAF, ochranu před DDoS ani podporu Zero Trust.
• Session affinity je omezena na ip_cookie, které deterministicky vybere koncový bod a následně jej namapuje na IP adresu klienta pro všechny další požadavky.
• V neposlední řadě platí, že jelikož se u režimu DNS only připojení přes load balancer neproxují, nebudou fungovat ani některé metody řízení provozu (steering). Například LORS nebude fungovat, protože Cloudflare nebude mít přehled o připojeních ke koncovým bodům. Tyto metody směrování se v takovém případě vrátí k náhodnému váženému směrování.

Další informace o dalších metodách směrování najdete v Směrování sekce.

Při použití load balancerů typu pouze DNS je třeba počítat i s ukládáním do DNS mezipaměti na straně klienta a resolveru. Dobu platnosti v mezipaměti určuje DNS server, který na požadavek odpovídá. Hodnota Doba platnosti (TTL) ↗ udává klientovi, jak dlouho je odpověď platná, než by měl odeslat nový DNS dotaz a zjistit, zda se cíl nezměnil. TTL se počítá v sekundách, takže hodnota TTL 3600 odpovídá jedné hodině. Standardní hodnoty DNS TTL bývají obvykle 12 nebo 24 hodin, tedy 43200, respektive 86400.

TTL load balanceru typu DNS-only je nastaveno na 30 (sekund). Díky tomu je load balancer typu DNS-only při změnách stavu koncových bodů nebo jejich přidávání či odebírání dotazován častěji, což zajišťuje co nejpřesnější seznam dostupných koncových bodů.

Důležité poznámky k load balancerům pouze DNS:

• DNS-only load balancery podporují pouze veřejné endpointy
• DNS-only load balancery neproxují provoz, a proto se nepodílejí na připojeních k endpointu
• DNS-only load balancery odpovídají na DNS požadavek pouze IP adresou nebo sadou IP adres

Cloudflare také nabízí další metodu ingress prostřednictvím Spectrum produkt.

Zatímco zásobník vrstvy 7 podporuje pouze HTTP(S) a WebSockets, Spectrum nabízí podporu pro libovolný protokol založený na TCP nebo UDP. Cloudflare Load Balancer, který jako vstupní bod provozu využívá Spectrum, pracuje na vrstvě 4, kde existují jak protokol TCP, tak UDP. Spectrum s Cloudflare Load Balancerem může využít jakákoli služba, která pro přenos používá TCP nebo UDP, včetně SSH, FTP, NTP, SMTP a dalších.

Vzhledem k šíři služeb a protokolů, které to zahrnuje, je poskytované zpracování obecnější než u zásobníku HTTP(S) na vrstvě 7. Cloudflare Spectrum tak například u našich load balancerů na vrstvě 4 podporuje funkce jako TLS/SSL offloading, ochranu před DDoS, seznamy IP Access, Argo Smart Routing a perzistenci relací.

Load balancery Cloudflare Spectrum na vrstvě 4 jsou veřejně přístupné. Přístup k těmto prostředkům pro load balancing lze řídit pomocí konfigurace Spectrum nazvané IP Access Rules, které lze definovat jako součást konfigurace WAF, ale jsou omezeny na pravidla vytvořená s akcí „allow“ nebo „block“ pro konkrétní IP adresy, podsítě, země nebo Border Gateway Protocol (BGP) ↗ Čísla autonomních systémů (ASN).

Load balancery Spectrum jsou kromě toho, že jsou veřejné, vždy proxované. Nastavení proxy uvedené výše (obrázky 24 a 25) bude ignorováno, pokud je Spectrum nakonfigurován jako vstupní cesta pro load balancer. Veškerý provoz směřující k load balancerům založeným na Spectrum vždy prochází přes okraj sítě Cloudflare.

Důležité poznámky k load balancerům Spectrum:

• Load balancery Spectrum podporují veřejné i privátní koncové body
• Load balancery Spectrum se nejprve vytvářejí jako load balancery vrstvy 7 pro HTTP(S). Poté se vytvoří aplikace Spectrum s typem koncového bodu Load Balancer, přičemž se vybere již vytvořený load balancer.
• Load balancery Spectrum jsou vždy proxovány bez ohledu na nastavení proxy v konfiguraci load balanceru
• Vstupní port, kterým provoz z internetu přichází přes Spectrum ke koncovému bodu, nelze změnit; pokud tedy provoz přijde do Spectrum na portu 22, bude nasměrován na port 22 na koncovém bodě
• Load balancery Spectrum podporují session affinity pouze pomocí metody směrování hash endpoint
• Load balancery Spectrum nepodporují Custom Rules

Nastavení hostname určuje veřejně dostupný hostname load balanceru. Tento hostname musí být vytvořen v rámci zóny, pro kterou se load balancer vytváří.

Nastavení proxy určuje, zda bude Cloudflare provoz load balanceru proxovat, nebo jen vrátí odpověď DNS s endpointy, ke kterým se klient připojí přímo. Podrobně to popisuje Modely nasazení sekce.

Session affinity, také známá jako session persistence nebo sticky session, udržuje klienta připojeného ke stejnému koncovému bodu pro všechny následující požadavky po prvním požadavku nebo připojení. Jde o důležitou funkci pro aplikace, které si mezi koncovými body nesdílejí data relace, tedy kontext interakce uživatele s webovou aplikací. Pokud by například byl uprostřed relace klienta vybrán nový koncový bod a informace o relaci, například obsah nákupního košíku uživatele, se ztratily, byl by uživatelský zážitek z dané aplikace špatný.

Cloudflare nabízí tři způsoby, jak zapnout session affinity:

1. Pouze pomocí cookie Cloudflare (cookie): Při prvním požadavku na proxovaný load balancer se vygeneruje cookie, která zakóduje informaci o tom, na jaký endpoint bude požadavek přesměrován. Následující požadavky (od stejného klienta na stejný load balancer) se odešlou na endpoint zakódovaný v cookie, a to a) po dobu platnosti cookie a b) dokud zůstane endpoint funkční. Pokud platnost cookie vyprší nebo endpoint přestane být funkční, vypočítá se a použije nový endpoint.
2. Pomocí cookie Cloudflare se záložní možností Client IP (ip_cookie): Toto chování je podobné výše popsané metodě cookie, s tím rozdílem, že se cookie generuje na základě IP adresy klienta. Požadavky ze stejné IP adresy jsou v tomto případě vždy směrovány na stejný endpoint, a to a) po dobu platnosti cookie a b) dokud je daný endpoint funkční. Pokud platnost cookie vyprší nebo endpoint přestane být funkční, vypočítá se a použije nový endpoint.
3. Pomocí HTTP hlavičky (header): Při prvním požadavku na proxovaný load balancer se na základě nakonfigurovaných hlaviček HTTP vygeneruje klíč relace. Následující požadavky na load balancer se stejnými hlavičkami se odešlou na stejný endpoint, a to a) po dobu trvání relace nebo b) dokud zůstane endpoint funkční. Pokud je relace neaktivní po dobu danou hodnotou TTL (time to live) afinity relace v sekundách nebo endpoint přestane být funkční, vypočítá se a použije nový endpoint.

Tyto tři možnosti session affinity platí pouze pro load balancery vrstvy 7 HTTP(S). Session affinity vyžaduje TTL, které určuje, jak dlouho bude load balancer směrovat následné požadavky na konkrétní koncový bod. Výchozí TTL je 82,800 sekund (23 hodin), lze jej ale nastavit v rozmezí od 1,800 sekund (30 minut) do 604,800 sekund (sedm dní).

U session affinity založené na cookies se časovač vypršení nikdy neresetuje, což znamená, že odpočítává od začátku relace bez ohledu na to, zda je relace neaktivní, nebo aktivní. Session affinity založená na HTTP hlavičce naopak resetuje časovač vypršení při každé aktivitě v rámci relace.

Vyřazování koncových bodů je dílčí funkce session affinity. Umožňuje, aby relace na koncovém bodu postupně vypršely, zatímco na tomtéž koncovém bodu už nelze vytvářet nové relace. Vyřazování koncových bodů se hodí při údržbě, protože administrátoři díky němu nemusí uživatelské relace ukončovat svévolně nebo náhle, aby z koncového bodu odstranili všechny aktivní relace.

TTL vyprazdňování koncového bodu (endpoint drain TTL) je doba, po kterou mohou koncové body udržovat aktivní relace, než jsou vynuceně ukončeny. Po nastavení TTL vyprazdňování koncového bodu se vyprazdňování spustí zakázáním jednoho nebo více koncových bodů v poolu koncových bodů. Jak je vidět na obrázku níže, administrátoři mohou v uživatelském rozhraní load balanceru sledovat zbývající čas operace vyprazdňování koncového bodu.

Vyřazování koncových bodů lze použít pouze v kombinaci se session affinity, protože bez session affinity není zaručeno, že další požadavky nebo připojení budou směrované na stejný koncový bod. Zakázání koncového bodu proto nemá vliv na uživatelský zážitek.

Failover bez výpadku automaticky směruje provoz na koncové body v rámci fondu koncových bodů během přechodných problémů se sítí.

Zero-downtime failover spustí jen jeden opakovaný pokus, a to pouze pokud je ve fondu další funkční koncový bod a Kód chyby 521, 522, 523, 525 nebo 526 právě probíhá. Žádné jiné chybové kódy nespustí přepnutí na záložní systém bez výpadku.

Failover bez výpadku funguje ve třech režimech:

1. Žádné (vypnuto): Nedojde k žádnému failoveru a uživatelé mohou obdržet chybové zprávy nebo mít horší uživatelský zážitek.
2. Dočasné: Provoz se bude směrovat na jiné endpointy, dokud nebude původní endpoint opět dostupný.
3. Trvalé: Cookie session affinity se aktualizuje a další požadavky se podle potřeby odesílají na nový endpoint. Toto chování není podporováno, pokud session affinity používá režim HTTP hlavičky.

Adaptivní směrování: failover mezi pooly rozšiřuje funkčnost failoveru bez výpadku tím, že umožňuje přechod na koncové body v jiném poolu koncových bodů, místo aby probíhal pouze na koncový bod v stejný fondu.

Fondy endpointů se řadí podle priority a lze je podle potřeby přeuspořádat. Toto pořadí priorit se zohledňuje jen při použití Směrování provozu Off - Failover; jinak budou fondy koncových bodů vybírány na základě kritérií uvedených v Metody směrování sekce.

Pooly koncových bodů přiřazené k load balanceru představují celou skupinu koncových bodů, které mohou přes load balancer potenciálně obsluhovat požadavky nebo připojení. Pool koncových bodů obvykle obsahuje koncové body se stejnými schopnostmi, které se nacházejí ve stejném datovém centru nebo geografickém regionu. Všechny koncové body v poolu by měly být schopné obsloužit jakýkoli požadavek směrovaný na daný pool. Další informace o poolech koncových bodů najdete v Fondy endpointů sekce.

Záložní fond (fallback pool) je fondem poslední instance. Když jsou všechny fondy koncových bodů nedostupné nebo nefunkční, použije se pro veškeré požadavky a připojení právě tento záložní fond. Zatímco load balancer při směrování provozu vždy zohledňuje data z health monitoru, u záložního fondu tomu tak není a na těchto datech nezávisí.

Monitory stavu se obvykle konfigurují jako součást fondu koncových bodů. Monitory stavu lze přidávat, měnit nebo odstraňovat v rámci konfigurace load balanceru. Viz Monitory stavu sekci pro další informace.

Traffic Steering je metoda výběru mezi fondy koncových bodů. Nápovědu k výběru vhodné metody Traffic Steering najdete v Typy a metody směrování sekce.

Custom rules umožňují uživatelům provádět akce s požadavky nebo připojeními ještě předtím, než load balancer dokončí svůj rozhodovací proces. Vlastní pravidla se konfigurují pomocí výrazů, které odpovídají určitým pole v požadavcích nebo připojeních. Jakmile je výraz pro shodu s provozem vytvořen, action se přiřadí, když požadavek nebo připojení odpovídá danému výrazu.

Custom rules představují účinný nástroj pro přizpůsobení směrování a výstupu load balanceru ještě předtím, než je požadavek nebo spojení odesláno na endpoint. Lze například porovnávat HTTP metodu (např. GET, PUT, POST) a zajistit tak, aby zprávy POST směřovaly do konkrétního poolu endpointů určeného pro příjem informací od klientů.

Alternativně lze TTL afinity relace resetovat na základě požadavku směřujícího na konkrétní cestu URL, aby měl klient dostatek času transakci dokončit.

Není možné popsat všechny možné kombinace polí, která lze porovnávat, a akcí, které lze provést. Následující zdroje ale popisují všechna aktuálně dostupná pole a akce:

• Podporovaná pole a operátory
• Akce load balancingu

Pokud výchozí chování load balanceru nepokrývají výše uvedené dokumenty, pravděpodobně pomůže vlastní pravidlo, které pokryje požadavky konkrétního případu použití.

Všechny modely nasazení Cloudflare Load Balancer mají vestavěnou ochranu. Následující část stručně shrnuje výchozí zabezpečení, které Cloudflare poskytuje, i volitelnou ochranu, kterou lze před Cloudflare Load Balancer doplnit:

• Proxovaný HTTP load balancer vrstvy 7 (veřejný)
  • Ochrana před DDoS k ochraně před útoky
  • WAF s spravovaná sada pravidel Cloudflare a sada pravidel OWASP k blokování známých zranitelností a exploitů
• DNS-only load balancer (veřejný)
  • Ochrana DNS proti DDoS ↗ k zajištění toho, aby byl load balancer typu pouze DNS vždy dostupný
• Spectrum load balancer vrstvy 4 (Public)
  • DDoS Protection k ochraně před útoky na vrstvě 4

Cloudflare nabízí další bezpečnostní vrstvy, které lze použít společně s load balancingem k ochraně libovolných služeb, včetně webů, API, služeb založených na HTTP(S) a dalších:

• Proxovaný HTTP load balancer vrstvy 7 (veřejný)
  • Bot management k řízení toho, kteří roboti mohou přistupovat ke zdrojům
  • WAF pro vytváření vlastních pravidel pro webové aplikace
  • Client-side security pro sledování používání skriptů ve webových aplikacích
  • API Shield k ochraně API
• DNS-only load balancer (veřejný)
  • DNSSEC k zajištění pravosti záznamů DNS
• Spectrum load balancer vrstvy 4 (Public)
  • IP Access Rules pro řízení přístupu k veřejným load balancerům na vrstvě 4

Globální anycast síť Cloudflare je výkonnou platformou pro load balancing. Konfigurace load balancingu v Cloudflare je dostupná ve více než 330 městech po celém světě a má prakticky neomezenou kapacitu a šířku pásma.

Tyto load balancery fungují v okruhu přibližně 50ms od zhruba 95% populace připojené k internetu, včetně koncových bodů, díky nimž Cloudflare Load Balancers zvládají jak GTM, tak Private Network Load Balancing. Cloudflare nyní tyto dva odlišné koncepty load balancingu spojuje do jediného load balanceru. Organizacím to pomáhá směrovat provoz do geograficky nejvhodnějších datacenter a následně vybrat správný koncový bod pro zpracování požadavku.

Díky Cloudflare Tunnel mohou koncové body ležet uvnitř privátních sítí, a přesto je mohou využívat Cloudflare Load Balancery. Cloudflare nabízí veřejné load balancery vrstvy 7, které podporují jak HTTP(S), tak WebSockets, i veřejné load balancery vrstvy 4, které dokážou směrovat jakýkoli provoz TCP nebo UDP. To znamená, že Cloudflare může nabídnout služby vyvažování zátěže všem organizacím a uživatelům bez ohledu na jejich umístění, případy užití nebo stávající konfiguraci.