it-swarm-eu.dev

Jaké potenciální problémy musím znát v prostředí více serverů / skupin?

Již nějakou dobu pracuji na webových stránkách s klientem a samotný web si masivně získal popularitu. Nyní jsme ve fázi, kdy jediný stroj, který hostujeme, se snaží udržet požadavky a optimalizovali jsme samotný web co nejdále (ukládání do mezipaměti atd.).

Nyní jsme ve fázi, kdy potřebujeme přidat další server, abychom se nadměrně namáhali, což vede k mé otázce - jaké potenciální nástrahy a upozornění musím znát nebo otestovat, když se přesunu na webovou farmu nebo sdružený hosting životní prostředí?

3
Wolfwyrd

Existuje několik možných upozornění:

Sessions

Pokud jsou relace uloženy na straně serveru (tj. PHP), oba servery budou potřebovat přístup ke sdílené cestě úložiště relací. V opačném případě ztratíte relace, protože vyrovnávač zátěže odešle požadavek z jednoho serveru na druhý nebo případně (gasp) má jednoho uživatele se dvěma jedinečnými relacemi. To může být obzvláště frustrující s AJAX. V závislosti na vyvažovači zatížení mohou být také možné „lepivé“ relace.

dočasné soubory

Oba servery by měly sdílet stejný adresář/tmp, pokud ve skutečnosti používáte jakýkoli druh dočasných souborů při práci na podávání požadavků. Může to být dočasný archiv, který je komprimován pro stahování, plochý soubor DB, který sleduje něco, cokoli.

SQLite Locking

Pokud používáte SQLite3, můžete si všimnout některých vtipů, které se nikdy neobjevily, zejména pokud používáte k sdílení databázových souborů mezi servery něco podobného NFS. NFS je s tím pomalý, takže doporučuji použít něco jiného. Distribuované souborové systémy, jako je Luster, lze snadno nastavit, nebo byste mohli použít GFS/OCFS2.

SSL

Pravděpodobně budete chtít, aby vyvažovač zátěže byl tím, co zpracovává handshake SSL, což pak provede požadavek na servery typu back-end pomocí jakéhokoli starého certifikátu s vlastním podpisem.

Některé obecné poznámky:

  • Jak bylo uvedeno, pro sdílení adresářů použijte vysoce výkonný systém souborů. Všechny sdílené soubory by měly žít v síťovém úložišti, nikoli na jednom z webových serverů. V opačném případě, pokud někdo spadne, oba jsou k ničemu, druh poráží účel.

  • Pokud web používá RDBMS, máte dvě možnosti. Spusťte jej na obou uzlech a použijte synchronizaci master-master, nebo umístěte server DB na svůj vlastní domov. Doporučuji druhý, protože to dává vašim webovým serverům mnohem větší prostor pro práci.

  • Vyvažovače zátěže také potřebují redundanci.

Ve většině případů můžete přejít z jednoho serveru na farmu vyváženou zátěží s malými nebo žádnými změnami skutečného webu/aplikace samotné, ale musíte se ujistit, že všechny uzly dokáží číst a zapisovat do stejných souborů. To může vyžadovat přidání logiky pro zamykání v samotné aplikaci.

1
Tim Post

Potenciálním problémem je stav relace (pokud se jedná o problém). Většina zařízení pro vyvažování zátěže může používat lepivé relace, což znamená, že uživatel, který skončí spuštěním služby SERVER1, zůstane na serveru SERVER1, obvykle pomocí cookie uloženého v paměti prohlížeče. Jedinou výzvou je, že když se SERVER1 z jakéhokoli důvodu přepne do režimu offline, bude se muset uživatel znovu přihlásit na jiném serveru.

Začal jsem to obcházet ve svých aplikacích (jsou to aplikace CF) sdílením relací v serverové farmě. Jeden stroj, který spadne, tedy neovlivní dojem uživatele.

Jediná další výzva, které jsem čelil při správné replikaci obsahu na všechny servery ve farmě. K dispozici je software, který to dělá (roboskopie, Fling ze softwaru NCH jsou dva, které jsem použil), ale stále jsem měl případy, kdy synchronizace nefungovala 100% času.

0
Milner

Zajímá vás aplikace stav? Pokud má uživatel jeden požadavek doručený jedním strojem a poté druhým doručeným, záleží na tom? Pokud potřebujete přetrvávat nějakou formu stavu mezi požadavky, pak je vše složitější a existuje několik způsobů, jak problém vyřešit.

Pokud se nemusíte starat o stav, pak si dobře vytvořte své stránky a vy byste měli být v pořádku s proxy a několika backend servery.

Pokud potřebujete přetrvávat stav, existuje několik způsobů, jak vytvořit lepivou relaci prostřednictvím proxy serveru, takže stejný server backend zpracovává všechny požadavky od jednoho uživatele, ale existuje také mnoho věcí, které těmto relacím obtížně udržují lepivost .

Můžete také setrvat ve společném médiu na backendu, takže každý server načte stejný stav pro stejného uživatele. Můžete to udělat s databází (možná příliš pomalá) nebo s něčím jako memcached .

Také zvyšujete počet databázových serverů? To přinese další strach problémů.

Některé problémy relace jsou popsány v podcastu přetečení zásobníku číslo 6

Pro testování se ujistěte, že jste tvrdě zasáhli podobný testovací klastr, abyste viděli, jak se vaše požadavky dělají, když jsou nasměrovány na mnoho serverů, protože mnoho požadavků od stejného klienta na různá pozadí je pravděpodobně způsobeno problémy, takže se ujistěte, že něco ve vašem testovacím plánu způsobí, že k tomu dojde.

Můžete si také přečíst informace o Network config

0
danivovich