Bitrix cluster. Webový cluster – reálná zkušenost

Modul Web Cluster je kombinací technologických řešení, které vám umožňují distribuovat jednu webovou stránku na několik serverů, čímž řeší několik problémů: poskytování vysoká dostupnost webové stránky, škálování v podmínkách rostoucí zátěže, vyrovnávání zátěže, provozu, dat mezi několika servery. S webovým clusterem zvýšíte výkon, škálovatelnost a spolehlivost svého projektu!

Na jaké úkoly potřebujete webový cluster?

Cluster je potřebný pro flexibilní řešení problémů se zvyšující se zátěží a zvyšováním stability služeb. S rostoucím provozem tedy můžete do clusteru rychle přidávat nové servery. A pokud jeden z clusterových serverů selže, systém nadále nepřetržitě obsluhuje návštěvníky/klienty. Nic méně důležitý úkol– to je vyrovnávání zátěže, provoz, data mezi několika servery. Zároveň systém umožňuje odstranit zálohy ze speciálně určených uzlů clusteru, aniž by to ovlivnilo provoz webu, bez vypínání strojů nebo jejich zpomalování. Existují samostatné úkoly geodistribuce. Když spustíte geografický webový cluster, umožní vám roztočit celé skupiny serverů. Každá z těchto skupin má svého hlavního – v datových centrech na sobě nezávislých. Vaše webové stránky a vaše podnikání jsou tak zcela chráněny před nedostupností datových center a samotných komunikačních kanálů.

Jak funguje webový cluster 1C Bitrix?

Podívejme se, jaké technologie používá webový cluster 1C Bitrix:

• Pro databázi to je vertikální šrafování(přesun modulů do samostatných MySQL servery)
• replikace MySQL A vyvažování zátěže mezi servery
• Distribuováno datová mezipaměť(memcached)
• Kontinuita relace mezi webovými servery (ukládání relací do databáze)

Clusterování webových serverů dochází z důvodu synchronizace souborů, vyvažování zátěže mezi servery, geonezávislosti na datovém centru (v případě výpadku jednoho datového centra okamžitě zprovozní další, bez nutnosti navyšovat zálohy a další akce, jedná se o skutečnou hot swap).

Tajemství vysokého zatížení na 1C Bitrix s webovým clusterem

1. MySQL Sharding

Rozdělení jedné databáze webové aplikace na dvě nebo více databází pomocí alokace jednotlivé moduly, aniž by se změnila logika webové aplikace.

Můžete jej vložit do samostatných databází následující moduly produkt: , .

2. Replikace MySQL

Schéma „master slave“ je implementováno pomocí MySQL / MariaDB. Tento technologický zásobník je poměrně dobře popsán a je široce používán.

3. Balancer pro vyrovnávání zátěže mezi servery

Podívejme se blíže na balancer. Platforma 1C-Bitrix: Site Management ve funkcionalitě Web Cluster umožňuje flexibilně vyvažovat zátěž mezi servery účastnícími se replikace.

Dostáváme následující klíčové vlastnosti: flexibilní vyrovnávání zátěže v MySQL, snadná správa z jednoho rozhraní, rychlé neomezené škálování bez dalších nákladů, zálohování za chodu (ve skutečnosti je to: vytváření záložních kopií skutečný stav). Všechny tyto funkce nevyžadují úpravu logiky webové aplikace, vše již funguje v této edici.

4. Distribuovaná mezipaměť dat (spravuje: memcached)

Tato technologie umožňuje ukládat data do mezipaměti BERAN sady dostupné servery. Distribuce je realizována sdílením dat podle hodnoty hash klíče, podobně jako sokety hash tabulky. Klientská knihovna pomocí datového klíče vypočítá hash a použije jej k výběru vhodného serveru.

To zajišťuje vysokou efektivitu – díky centralizovanému využití mezipaměti webovou aplikací, stejně jako spolehlivost – díky odolnosti mezipaměti podsystému proti selhání jednotlivé komponenty a zároveň zaručuje neomezenou škálovatelnost přidáním nových serverů memcached s rostoucí zátěží.

5. Kontinuita relace

Pro organizaci kontinuity relací mezi webovými servery je nutné povolit ukládání relací do databáze a samotné databáze se replikují, jak je uvedeno výše.

Možnost ukládat data uživatelských relací do databáze zajišťuje „transparentnost“ relace pro všechny webové servery v clusteru, protože Po autorizaci na jednom ze serverů musí být uživatel považován za autorizovaného pro všechny ostatní servery. A naopak, po skončení relace na jakémkoli serveru by to mělo znamenat její konec na všech serverech najednou.

Bitrix dnes představil své nové řešení – „web cluster“. Pro ty, kteří to neznají, vysvětlím, že tato věc vám umožňuje umístit vysoce navštěvovaný projekt ne na jeden, ale na několik serverů a kdykoli přidat nové servery, abyste urychlili web. Je také bezpečné odebrat jakýkoli server pro opravy, upgrady nebo v případě selhání. Jako jejich první konkurent (zastoupený firmou Yumisoft) jsem samozřejmě potřeboval především zjistit, co zásadního nového na trh nabízejí.

Nic. V v dobrém slova smyslu Nic. Bitrix přestal blbnout a „znovu vynalézat kolo“ – do týmu se zřejmě dostal chytrý technolog, takže místo „kol“ vzali a udělali vše, jak to normální lidé obvykle dělají. V tomto příspěvku řeknu jednoduchými slovy– co přesně udělali a jak můžete totéž zopakovat ve svém projektu.

Podívejme se na hlavní části clusteru:

0. Cloud – cloud, sada serverů, na kterých to vše poběží.
1. Load balancer – příchozí load balancer.
2. Replikace MySQL – populární vzhled shlukování databáze.
3. Síťový soubor systém – distribuovaný úložiště souborů.

Jak bylo uvedeno výše, cluster je sada libovolného počtu webových serverů. Mohou plnit stejné úkoly nebo různé v závislosti na cílech. Začněme servery: zde se navrhuje použít pro ně virtuální stroje aws.amazon.com. Neřekl bych, že je to rozumné řešení: virtuální stroje jsou a priori pomalé, ale tady klíčový bod- snadnost tvorby. Stiskl jsem tlačítko a bylo vytvořeno. A ne výchozí stroj, ale konfigurovaný speciálně pro vaše potřeby. Můžete jej vytvořit podle plánu nebo dokonce dynamicky, jak se zvyšuje zatížení. Vaše stránky spadly mocný tok návštěvníků - to r-r-r-az a vytvořil několik nových strojů. Zátěž skončila - stroje se vypnuly. Krása.

Každý server na internetu může samozřejmě fungovat jako clusterový server: virtuální nebo hardwarový. Pro informaci: každý, kdo není příliš líný začít instalovat nový, si může zdarma vytvořit svůj vlastní osobní cluster „Amazon“. Distribuce Ubuntu Server.

Balancér je potřebný k distribuci příchozích požadavků od návštěvníků webu mezi servery clusteru. Navrhuje se použít nginx jako to, Google „nginx load balance“ a získáte spoustu odkazů na hotové příklady.

Replikace databáze je potřebná pro zápis dat na jeden server (nazývá se master) a čtení ze všech ostatních (respektive slave). Protože obvykle existuje málo operací zápisu a mnoho operací čtení, pouhým zvýšením počtu podřízených jednotek můžete neomezeně zvýšit „výkon“ projektu. Data z masteru do slave proudí do pozadíčistě pomocí MySQL a slave lze kdykoli přidat a odebrat. Google „replikace mysql“ a získejte pokyny.

Distribuované úložiště souborů je nutné, aby bylo zajištěno, že všechny servery budou mít stejnou sadu souborů. Pokud uživatel nahrál obrázek „někde“ na některý ze serverů, měl by se objevit všude. Proč? Protože informace mohou být poskytovány jiným uživatelům z jiného serveru. Pro implementaci soudruzi z Bitrixu doporučují „csync2“ – funguje na pozadí a hloupě synchronizuje soubory mezi servery, aby bylo vše všude stejné.

Vše. Takže jste vytvořili shluk. A teď – jemné doladění:

První kámen úrazu, na který při převodu svého projektu (myslím projekt na jiném CMS nebo vlastnoručně napsaném) do takového modelu, narazíte, bude v databázových operacích. Základem je, že aplikace musí být schopna rozlišit požadavky „zapisování“ od požadavků „čtení“. Jinými slovy, INSERT, UPDATE, DELETE, stejně jako CREATE, ALTER a DROP je třeba provádět pouze na masteru. SELECT dotazy lze v zásadě provádět kdekoli. Přeškolení vašeho motoru na tento způsob myšlení zabere poměrně značné množství času.

Navíc Bitrixoidi přišli se zajímavou věcí: protože data proudí z mastera do slave s určitým zpožděním, naučili systém rozpoznávat „kritická“. psaní žádostí. Po takovém požadavku jsou všechna data až do úplného konce provádění PHP skriptů přebírána (SELECT) pouze z masteru, aby se předešlo chybám způsobeným stejným zpožděním.

Druhou myšlenkou, kterou je třeba zvážit, je přidělení serverů pro úkoly. Není nutné dělat všechny servery stejné a přiřazovat je identické úkoly. Některé nechejte sloužit například internetovému obchodu a druhá část sbírá statistiky.

Třetí myšlenkou je shlukování memcached. Bitrix jej zařadil na začátek své prezentace, ale můžete jej spustit později. Jeho výhodou je, že se propojuje přímo s nginx (pamatujete na první bod?) a umožňuje mu obsluhovat stránky uložené v mezipaměti (nebo bloky) přímo z RAM. Vaším úkolem je přesněji úkol vašich skriptů – umístěte obsah uložený v mezipaměti do memcached.

Jak rozvíjet projekt na klastru? Často kladená otázka pro zástupce webových studií. Ano, úplně stejně jako na běžný server. Bude pro vás pouze jeden cluster velký počítač, do kterého se přihlásíte přes ssh stejným způsobem a fungujete.

1C-Bitrix: Webový cluster Hlavní úkoly, které je třeba vyřešit: 1. Zajištění vysoké dostupnosti služby (tzv. HA - High Availability nebo Failover clustery) 2. Škálování webového projektu v podmínkách rostoucí zátěže (HP - Vysoce výkonné clustery) 3. Vyrovnávání zátěže, provozu, dat mezi několika servery. 4.Vytvoření kompletní záložní kopie dat pro MySQL.

1C-Bitrix: Webový cluster „Webový cluster“ zajišťuje kontinuitu podnikání, odolnost proti chybám, škálování, rozložení zátěže. Jakýkoli nový nebo běžící projekt na 1C-Bitrix: Site Management 10.0 může být prezentován jako webový cluster vyměnitelných serverů. 1. Jak se provoz zvyšuje, můžete do clusteru rychle přidávat nové servery. 2. Pokud jeden z klastrových serverů selže, systém nadále nepřetržitě obsluhuje klienty. 3. Vyrovnávání zátěže, provoz, data mezi několika servery. 4. Systém vám umožňuje pořizovat záložní kopie ze speciálně určených uzlů clusteru, aniž by to ovlivnilo provoz webu.

Historie výkonu platformy Do roku 2005 se problematika výkonu rok systematicky neřešila - zásadním úkolem pro vývoj se stal výkon roku - vznik nástrojů pro ladění SQL dotazů. Systematická práce na rok výkonu produktu – první zátěžové testování s QSOFT (1,5 milionu přístupů za den v edici „Business“, 6 milionů v edici „Start“) let – nasazení 4 konfigurací Oracle RAC se 4 servery rok – „monitor výkonu“ ve všech edicích produktových let – „1C “vydáno -Bitrix: Virtuální stroj“ a „1C-Bitrix: Web Environment“ – rok certifikace poskytovatele hostingu – růst produktivity – o 430 %! Nové zátěžové testy: 8,5 milionu přístupů – „Business“, 12,4 milionu – „Start“, 85 milionů – „Vyrovnávací paměť HTML“.

Možnosti pro škálování až rozdělení na dva servery: webový server + databáze. 2.Zvýšení výkonu zařízení (čím výkonnější, tím dražší; nárůst nákladů není úměrný). 3. Přidělení mezipaměti jedné externí server přes memcached. 4. Přechod na Oracle (minimální licence + 5000 USD na procesor). 5.Vytvoření Oracle RAC (Real Application Cluster). Projekt – cca $ (vybavení + licence + „sdílená police“). Specialistů je velmi málo. Pro většinu klientů je výkon dostatečný, ale problémy s odolností proti chybám, redundancí a dostupností sítě nebyly vyřešeny.

1C-Bitrix: Webový cluster „1C-Bitrix: Webový cluster“ je kombinací technologií: Vertikální sharding (distribuce modulů k oddělení serverů MySQL) Replikace MySQL (v budoucnu Oracle a MS SQL) a vyrovnávání zátěže mezi servery Distribuovaná mezipaměť dat ( memcached) Kontinuita relací mezi webovými servery (ukládání relací do databáze) Klastrování webového serveru: – Synchronizace souborů – Vyrovnávání zátěže mezi servery

Rozdělení jedné databáze webové aplikace na dvě nebo více databází oddělením samostatných modulů beze změny logiky webové aplikace: Webová analytika Vyhledávání 1. Efektivní rozložení zátěže. 2. Měřítko. 3.Separace velké objemy data. Vertikální šrafování

Webový server Base Data MySQL Webová aplikace Vysoká zátěž: ~10^3 zápisů/s ~10^4 čtení/s Vysoký provoz 1) Dotazy zpracovává pouze jeden server DBMS 2) CPU a diskový subsystém DBMS jsou přetížené Škálování se zvyšujícím se zatížením MySQL

Vysoká účinnost - díky centralizovanému použití mezipaměti webová aplikace Spolehlivost - díky odolnosti cachovacího subsystému proti selhání jednotlivých komponent Neomezená škálovatelnost - díky přidání nových memcachovaných serverů. memcached 1 memcached 2 memcached 3 Webový cluster "1C-Bitrix" 40%30% Webový server Distribuovaná mezipaměť dat (memcached)

Kontinuita relací mezi webovými servery Uživatelská relace by měla být pro všechny servery „transparentní“. webový cluster. 1.Po autorizaci na jednom ze serverů musí být uživatel považován za autorizovaného pro všechny ostatní servery. 2. A naopak - konec relace na jakémkoli serveru by měl znamenat její konec na všech serverech najednou.

80 % Vysoký provoz 1) Zátěž zpracovává pouze jeden webový server 2) CPU je přetíženo Zpracování PHP, prekompilátor je povolen, jsou pozorovány chyby segmentace Úloha: scale" title="Webový server Databáze MySQL Webová aplikace Vysoké zatížení CPU >80% Vysoký provoz 1) Zátěž zpracovává pouze jeden webový server 2) Procesor je přetíženo zpracováním PHP, povolený prekompilátor, pozorovány chyby segmentace Úkol: scale" class="link_thumb"> 22 !} Webový server Databáze MySQL Webová aplikace Vysoké zatížení CPU >80% Vysoký provoz 1) Zátěž zpracovává pouze jeden webový server 2) CPU je přetíženo zpracováním PHP, je povolen prekompilátor, jsou pozorovány chyby segmentace Úkol: škálování jako zátěž zvyšuje 80 % Vysoký provoz 1) Zátěž zpracovává pouze jeden webový server 2) CPU je přetíženo zpracováním PHP, je povolen prekompilátor, jsou pozorovány chyby segmentace Úkol: scale"> 80 % Vysoký provoz 1) Zátěž je zpracována pouze jeden webový server 2) CPU je přetíženo zpracováním PHP, je povolen prekompilátor, jsou pozorovány chyby segmentace CPU je přetíženo zpracováním PHP, je povolen prekompilátor, jsou pozorovány chyby segmentace Úkol: škálování" title="(! LANG:Webový server Databáze MySQL Webová aplikace Vysoké zatížení CPU >80% Vysoký provoz 1) Zátěž zpracovává pouze jeden web server 2) CPU je přetíženo zpracováním PHP, prekompilátor je povolen, jsou pozorovány chyby segmentace Úkol: škálovat"> title="Webový server MySQL databáze Webová aplikace Vysoké zatížení CPU >80% Vysoký provoz 1) Zátěž zpracovává pouze jeden webový server 2) CPU je přetíženo zpracováním PHP, je povolen prekompilátor, jsou pozorovány chyby segmentace Úkol: škálovat"> !}

Proč jsme si vybrali csync2? Rychlý přístup do souborů aplikace pomocí místní úložiště. Vysoká rychlost práce. Nízká spotřeba zdrojů (CPU, diskové operace). Tyto dva faktory umožňují, aby proces synchronizace probíhal tak často, jak je to jen možné, takže data na serverech se stávají identickými téměř v „reálném čase“. Snadné nastavení pro výměnu dat mezi libovolným počtem serverů. Schopnost synchronizovat mazání souborů. Bezpečná komunikace mezi hostiteli (SSL).

Webový server MySQL databáze MASTER "1C-Bitrix: Web cluster" MySQL databáze SLAVE 1 MySQL databáze SLAVE N Online zálohování dat Disk Holistické logické/fyzické zálohování MySQL bez zpomalení hlavního systému MySQL databáze MASTER kandidát DRBD – online záloha disku s databází Organizace zálohování- MySQL

Webový server "1C-Bitrix: Web Cluster" /var/www LVM /var/www – snímek 1 /var/www – snímek 2 /var/www – snímek 3 Rychlé, holistické zálohování na úrovni Linux rychle, holistické, přírůstkové, automaticky konsolidované zálohování pomocí hostingových nástrojů Organizace zálohování - souborů

"1C-Bitrix: Web Cluster", DC v Moskvě Webový uzel DB "1C-Bitrix: Web Cluster", DC v New Yorku "1C-Bitrix: Web Cluster", DC v Novosibirsku, cirkulární, asynchronní, master-master replikace pro zajištění provoz geograficky distribuovaných webových clusterů 1C-Bitrix Cache DB Webový uzel Cache DB Webový uzel Cache Pracujeme na…

"1C-Bitrix: Web cluster", DC v Moskvě Webový uzel DB "1C-Bitrix: Web cluster", DC v New Yorku "1C-Bitrix: Web cluster", DC v Novosibirsku, kruhová, asynchronní, master-master replikace pro zajištění provoz geograficky distribuovaných webových clusterů 1C-Bitrix DB Cache Webový uzel DB Cache Webový uzel DB Cache Webový uzel DB Cache Webový uzel DB Cache Webový uzel DB Cache Webový uzel DB Cache Webový uzel Cache DB Webový uzel Cache Pracujeme na...

Stabilita systému při vypnutí uzlů webového clusteru Když jsou uzly clusteru vypnuty, systém nepřeruší službu klienta. Fronta se zvyšuje (prodlužuje se doba potřebná k doručení stránek klientům), ale celkově je systém vyvážený zatížením. Přidání uzlu webového klastru zpět úměrně zvýší výkon systému. Zátěžový test - vypnutí jednoho z uzlů clusteru

Zdravím vás, drazí spolupachatelé!

Tento článek je o tom, jak jsme implementovali webový cluster zpravodajský portál(s vrcholem 130 tisíc návštěv unikátní návštěvníci za den - to je 7TB provozu na 3 dny - volby a 2 následné. Nyní v průměru klastr distribuuje 35–40 TB provozu za měsíc), o tom, jak programátoři a novináři chápou stejné úkoly odlišně, o tom, jak můžete dosáhnout stejného cíle tím, že se vydáte různými cestami.

Bude to zajímat ty, kteří chtějí vybudovat snadno škálovatelný, geograficky distribuovaný webový cluster, aniž by investovali astronomické částky do vybavení (a podle televizních standardů budou částky obecně směšné).

Jsem si více než jistý, že marketéři prosazující uber řešení pro nově vydané produkty se slovy „škálovatelný webový cluster“ nebo „horizontální nekonečný škálovatelný webový cluster“ mě budou nenávidět.

Jsem si více než jistý, že konkurence našich klientů bude překvapena jednoduchostí námi použitého řešení.

Nebudu dávat banální konfigurace, které lze nalézt v jakémkoli tutoriálu Nastavení PHP, Nginx a Firebird (ten, přísně vzato, nemá co konfigurovat - vše funguje po vybalení) a obecně budu mluvit o podstatě řešení, a ne o tom, které z nich verze PHP lepší.

Zkušené designéry to pravděpodobně nebude zajímat - už všechno vědí, ale pro ty, kteří právě začínají v obtížné oblasti návrhu systému, je to obtížnější než "Ahoj, světe!" určitě se bude co učit - řešení je již téměř 2 roky v bojovém režimu a nenastaly žádné architektonické problémy (i když výpadek dvou najednou pevné disky byl na dvou ze tří uzlů, ale nikdo si ničeho nevšiml - stránky se otevíraly trochu pomaleji než obvykle).

Takže pár slov o tom, jak to všechno začalo. Byl jednou web skupiny nezávislých novinářů, kteří opravdu snili o tom, že se stanou skutečnou televizí (při pohledu dopředu řeknu, že se jim to podařilo - vytvořili si vlastní, docela úspěšnou televizi s „blackjackem a...“ - dále v textu). Naše země je malá, nic hrozného se neděje (a jsme za to rádi), ale jednou za 4 roky máme tradičně volby do Parlamentu. Která tradičně nijak nevolí prezidenta. (Nebojte se, tady nebude žádná politika, je to jen pro společné porozumění okamžik).

Samozřejmě v období před volbami a něco po nich jsou všechna online média velmi nestabilní. Některé weby jen tak neleží, povalují se, některé se pravidelně snaží poskytnout alespoň řádek textu, ale problém je univerzální a známý – weby nápor návštěvníků nezvládají. Mluvím o běžných, textových stránkách. A naši klienti měli neobvyklý web. Faktem je, že měli i videa - zprávy, produkovali 10 gigabajtů měsíčně - v té době, teď vytvářejí tolik videí denně. Ke všemu ostatnímu (upřímně toto je poslední zmínka o politice) tito novináři nebyli nijak zvlášť loajální k úřadům. Říkali a psali, co chtěli. Docela drzé, co? Vždy se stavíme jako žoldáci – klient nabízí problém, my nabízíme jeho řešení. Všechno ostatní nás nezajímá;

Dostali jsme za úkol nabídnout řešení pro zpravodajské weby, které by jim nejen umožnilo odolat náporu 50-100 tisíc návštěvníků, ale zároveň by bylo geograficky rozptýleno po celém světě a řízeno z mobilního bunkru kdekoli ve Vesmíru na planeta. Geografický rozptyl uzlů clusteru byl samozřejmě ponechán na nás. V důsledku toho jsme navrhli následující schéma (nejsem moc umělec, pokud mě omluvíte):

(Tento zjednodušené schéma od listopadu byly později téměř všechny servery převedeny na Hetzner, protože kanál Netdirektu se v té době neustále potýkal s problémy. Nyní je situace s jejich sítí mnohem lepší).
Pravidelní návštěvníci vidí jeden ze 3 serverů, přičemž jsme to udělali tak, že všichni návštěvníci z Moldavska stahovali „lehký“ obsah ve formě textu a obrázků z jednoho ze 3 a „těžký“ obsah (video) stahovali ze serveru umístěného na místním poskytovatel. Externí návštěvníci prostě neviděli moldavské zrcadlo a veškerý obsah stáhli z jednoho z německých serverů.

Výsledkem je to, co jsme s návštěvníky získali (každá část portálu má svůj vlastní čítač):

Toto schéma umožňuje kdykoliv změnit řídící server, sám kontroluje dostupnost uzlů clusteru, je snadno škálovatelné - jako záloha byl uvažován i Amazon EC - navíc byl Amazon EC nějakou dobu dokonce používán pro streamování videa ( cca 4 měsíce), ale z důvodu Vzhledem k vysokým nákladům na provoz bylo rozhodnuto přesunout streamovací uzly k německému Hetznerovi.
Bezprostředně 2 týdny před hodinou „X“, kterou jsme si vzali záložní servery a udržoval je připravené (ale uživatelé je neviděli, protože je ponechali aktivní server poněkud levnější než použití v bojovém režimu - pouze kvůli provozu).

Jak to celé funguje? Velmi jednoduché - tiše a nepřetržitě;).

Na řídícím serveru (jak jsem již zmínil, portál má 2 velké „sekce“: zprávy ve formě textu s obrázky a novinky ve formě textového výtahu a videa; de facto jsou použity 2 servery, ale pro zjednodušení Jeden jsem zobrazil) existuje něco, co se běžně nazývá redakční systém.

Hlavním účelem tohoto serveru je umožnit novinářům přidávat novinky. Jednou za každý určitý čas(3-5 minut) se spustí skript, který vytvoří... offline kopii webu. Samozřejmě se generují pouze stránky, které se změnily nebo které je potřeba přestavět kvůli crosslinkům a závislostem.

To je velmi snadné implementovat pomocí sekvencí a kaskádových spouštěčů ve Firebirdu – postup potřebuje pouze provést změny na hlavní stránce webu a kaskádové spouštěče aktualizují všechny závislosti a označí každou stránku, kterou je třeba aktualizovat. Značka není nastavena ve formě vlajky 1/0, ale ve formě jedinečné číslo, získaný na základě generátoru. Skript pro vytvoření offline verze při spuštění rozpozná novou hodnotu generátoru, přečte hodnotu tohoto generátoru z jeho předchozího spuštění a znovu vytvoří všechny stránky ve výsledném rozsahu. Zároveň vzhledem k tomu, že používáme transakční mechanismus Firebird, je skriptu jedno, jaké změny při jeho provádění nastanou – tzn. Vždy vytváříme koherentní a konzistentní verzi webu, bez ohledu na to, co reportéři dělají.

Vytvoříme tak hlavní kopii portálu (nebo dva portály, chcete-li - text a video). Skript (stejně jako samotný admin panel) je napsán v PHP a pro práci s Firebirdem používá ADODB – lze jej tedy celkem snadno na přání zákazníka* předělat.

(* Ale ADODB se brzy zbavíme ve všech našich budoucích projektech - jeho univerzálnost pouze poškozuje běžný mechanismus pro práci s databází, umožňuje vám využívat všechny funkce Firebirdu SQL server(ovšem stejně jako ostatní) tam není implementováno - např. nelze zachytit výjimky při vzorkování ze výběrových řízení, ne flexibilní řízení transakce a obecně mají tyto třídy příliš mnoho umělé inteligence – raději se rozhoduji sám, kdy chci transakci vrátit zpět a kdy potvrdit.)

Jediné, co bylo nutné v nastavení Firebirdu změnit, byla hodnota velikosti cache stránky databáze - protože počet připojení k databázi je velmi malý (zřídka více než 50-60 simultánní spojení), poté byl počet stránek experimentálně zvýšen na 2048 (používáme verzi Classic; pro architekturu Super lze tuto hodnotu snadno zvýšit 10krát, protože existuje běžná mezipaměť stránek. V nadcházející verzi Firebird 3.0 je vývojáři slibují jednu architekturu přátelskou k SMP se sdílenou mezipamětí, takže by to bylo docela možné použít velké hodnoty pro nastavení mezipaměti stránky).

Pak pomocí běžného rsync je rozdíl ve změnách rozptýlen mezi zrcadly, což jsou běžné uzly pro distribuci statických souborů založených na Nginx. Myslím, že není třeba říkat, co je schopen 4jádrový server s 12 GB RAM, když distribuuje pouze statická data? ;-)

Zároveň je 10 % kanálu každého uzlu (to je přesně 10 nebo 100 megabitů, v závislosti na konkrétním připojení) vyhrazeno pro synchronizaci. Synchronizace probíhá ve 2 fázích – nejprve se synchronizuje „těžký“ obsah – obrázky a videa, poté – text (html/xml/js).

Někdy (když jsou kanály z řídicího serveru do zrcadel zaneprázdněny) může návštěvník vidět drobné nesrovnalosti ve formě nenačítajících se obrázků a/nebo videí - protože se používá kruhové DNS, uživatel může obdržet text stránku z jednoho zrcadla a odkaz na video z jiného . To nebrání fungování portálu - text je tam vždy a obrázek nebo video se dříve nebo později objeví.

Vzhledem k tomu, že stránky mají dynamické formuláře - například přihlášení k odběru newsletteru - tyto formuláře zpracovává samostatný dedikovaný server (v diagramu to není znázorněno, ale to na podstatě nic nemění). I když předpokládáme, že všichni návštěvníci spěchají s odběrem novinek ve stejnou dobu a tento server vypadne, nic špatného se nestane - formuláře se načítají do iframe a absence těchto formulářů nemá vliv na dostupnost novinek.

Přidání nového uzlu je jednoduché – nejprve se synchronizuje nový mirror s hlavní kopií (to se děje paralelně s běžným provozem synchronizátoru), poté se záznam přidá do DNS a... nikdo si ničeho nevšimne.

Odebrání uzlu je jednodušší – jednoduše odstraníte záznam z DNS. Přidávání a mazání je docela přístupné automatizaci (přesně to jsme udělali s částí, která byla zodpovědná za webové streamování asi 1000 megabitových streamů na Amazom EC), ale pokud se náhle rozhodnete to zopakovat, doporučuji vám nejprve vypočítat, jak hodně zabere počáteční synchronizace dat (pro nás to jsou 2 gigabajty za " odlehčená verze portál“ a přibližně 1 terabajt pro video, je uloženo pouze několik poslední měsíce).

Proto jsme po nějaké době projektu odstranili dynamické přidávání/odebírání uzlů z rezervního fondu - obsah zabíral příliš mnoho a skript se ukázal jako příliš paranoidní - odebíral uzly vždy, když byl problém s nimi komunikovat .

Samostatně stojí za zmínku výpočty zobrazení zpráv. Nabyl jsem dojmu, že oblíbenou zábavou novinářů (kromě psaní/natáčení reportáží) je měření počtu návštěvníků konkrétní zprávy. Museli jsme vynaložit asi litr krve a kilometr nervů, abychom novinářské bratrstvo přesvědčili, že změny počítadel není nutné zobrazovat v reálném čase.

Programátoři velmi dobře chápou, že zjištění, kolik lidí je uvnitř přítomný okamžikČíst článek je prostě nemožné, můžete spočítat pouze počet žádostí o článek ze serveru, ale pro novináře jsou to stejné pojmy. :)

Pro počítání zhlédnutí jsme kontaktovali Kirila Korinského (také známého jako catap), který laskavě souhlasil s přidáním funkce počítání zhlédnutí URL do své pobočky Nginx. Pak je vše jednoduché - všechny uzly jsou pravidelně dotazovány a čítače stránek se berou v úvahu ve vlastnostech samotné stránky. Protože čítače (tedy samotné hodnoty) jsou uloženy v samostatné soubory(v současnosti se jedná o jeden soubor na novinku, brzy plánujeme vytvořit skupinu čítačů v jednom souboru, abychom snížili počet samotných souborů) - při synchronizaci se pak nepřenášejí celé stránky webu, ale pouze soubor čítačů. Při velkém počtu souborů to vytváří další zatížení diskového subsystému - proto při použití stejného přístupu okamžitě přemýšlejte o tom, jak rozdělit počítadla do skupin - my jsme se usadili na rozdělení počítadel podle typu a data zpráv - soubory jsou relativně malé a postupem času se přestávají měnit, protože staré zprávy prakticky nikoho nezajímají.

Zde jsou ve stručnosti výhody námi použitého řešení:

1. Použití statických webů jako uzlů webového clusteru vám umožní zredukovat správu celého clusteru na několik rutinní úkoly- aktualizace operační systém uzly a platby za provoz. Stejný bod vám umožňuje geograficky rozmístit uzly clusteru, které lze spolu s GEO-DNS obecně považovat za nějaký druh analogové sítě pro doručování obsahu (CDN) - ve skutečnosti to tak je.
2. Použití transakčního mechanismu databáze a přenesení logiky do databáze samotné vám umožňuje mít vždy holistickou a logicky konzistentní verzi webu – velmi by mě však překvapilo, kdyby „výsek“ dat ze serveru byl logicky nekonzistentní .
3. Pokud se očekává příliv návštěvníků, pak jednoduché zvětšení uzly clusteru to snadno zvládnou. Kompletní zprovoznění nového uzlu u nás zabralo něco málo přes hodinu u textové části portálu a zhruba den (nelze nacpat něco, co nejde vmáčknout) u videa. Pokud přistoupíte na částečnou synchronizaci stránek a zbytek přidáte na pozadí, lze zadání nového uzlu pro video zkrátit také na hodinu.
4. Administrativní server lze vytvořit z libovolného uzlu (v případě potřeby) - stačí nasadit zálohu databáze (v komprimované podobě asi sto megabajtů). Veškerý ostatní obsah je již k dispozici.

No, pár mínusů, aby se vše nezdálo tak růžové:

1. Řešení není vhodné pro případy, kdy jsou části webu, které by měly být viděny jinak různých uživatelů, tj. kdy jsou podle podmínek úkolu stránky generovány osobně pro každého uživatele. V našem případě se to ukázalo jako zbytečné.
2. Počítadla návštěv se aktualizují se zpožděním přibližně půl hodiny až hodiny. Snesitelné, ale o tom budete muset klienta přesvědčovat ještě dlouho.
3. Největší problém je synchronizace s lokálním zrcadlem – naši poskytovatelé zatím neprodávají provoz za cenu 7 eur za terabajt, a i když do světa poskytnou 100 poctivých Megabitů, je to za velmi neadekvátní ceny.
4. Navrhněte méně paranoidní systém pro sledování uzlů clusteru – ten náš se ukázal jako příliš citlivý, museli jsme přepnout přidávání a odebírání uzlů do manuálního režimu.

A doslova malá špetka zážitku, která zpestří nevýrazný nepořádek všedního dne.

K ukládání offline kopie webu používáme souborový systém JFS. Velmi dobře se osvědčil při práci s různými malé soubory a při práci s velké soubory(podle mých zkušeností pouze XFS dokáže téměř okamžitě smazat soubor o velikosti 200-300 GB).

Takže toto je výchozí nastavení souborový systém namontován s výchozími parametry. Jelikož jsme ale postupem času měli hodně souborů, diskové operace se začaly trochu zpomalovat. Vzhledem k tomu, že nepotřebujeme čas posledního přístupu k souboru, přidal jsem do parametrů montáže FS možnost „noatime“. Stalo se toto – myslím, že se můžete sami rozhodnout, kdy to přidat:

Dovolte mi krátce zopakovat - pro stabilní provoz PROTI normální režim použitý:

• 3 servery pro distribuci obsahu
• 2 servery pro „admin“
• 2 servery pro DNS a sledovací systém pro další servery.

Uzly clusteru jsou geograficky rozptýleny a jsou umístěny u různých poskytovatelů.
V případě očekávaných událostí, které přitahují velký počet návštěvníci - připojit další servery distribuovat obsah.

Měsíčně se spotřebuje asi 40 TB provozu, celkový objem obsah – něco málo přes 1 terabajt, video obsah je uložen po dobu asi 3 měsíců.

Rád zodpovím dotazy z komunity habra.