Sitecore Publishing Target Replication

Replikace publishing targetu

Pokud potřebujete pracovat se publishing targetem, který je umístěn na velkou vzdálenost od vaší Sitecore CM instance, musíte zvážit, jak moc budete publikovat a jak moc je publikování kritické. Publishing v Sitecoru je granulární operace, která odesílá každý jeden item přes síť individuálně – zatím neexistuje žádná “bulk” operace, která by takto učinila. To znamená, že se čas pro publishing zvyšuje se zvyšující se latencí a snižující se propustností sítě. Pojďme se podívat, jak to vyřešit.

Při latenci ~300 ms a propustností sítě 200 Mbit/s je čas pro vypublikování jedné itemy neskutečných 6 – 7 sekund. Čas pru publish 1 000 item by tedy přesáhů 1,5 hodiny. Jakkoli by toto mohlo být použitelné v některých use casech, ve valné většině případů je nutné mít co nejnižší čas na publikaci. Aby toho bylo možné dosáhnout, je nejlepší cestou celý publishing target replikovat za použití replikace SQL Serveru.

Doposud (až do Sitecore 8.1) je Merge Replication podporovaným způsobem replikace SQL Serveru pro Sitecore. Replikace je pak nastavena tak, aby replikovala jeden publishing target do jedné nebo více lokací. Replikovat obsah je efektivnější než jeho publishing, v případě přenosu po sítích typu WAN, vzhledem k tomu, že je operace hromadná, na rozdíl od atomické operace publishe.  Poté, co je obsah vypublikován do publishing targetu Sitecoru, který je zároveň nastaven jako Publication v replikaci SQL Serveru, Subscriber kontroluje změny v případě jejich výskytu, okamžitě obsah synchronizuje.

V případě výše zmíněné WAN s ~300 ms latencí a 200 Mbit propustností a za předpokladu, že máme items bez velkého binárního obsahu, zvládne replikace synchronizovat změny do 5 minut.

Typy Architektur

Existují dva hlavní scénáře, kterak se postavit k replikaci web targetu – univerzální publishing target a dedikovaný publishing target.

Univerzální publishing target

Univerální publishing target je jediný publishing target (web databáze), kde je vypublikován vždy všechen obsah. Tento obsah může pak být replikován do jedné nebo dalších několika lokací. Replikované web databáze se chovají přesně tak, jako ty standardní a v Sitecoru jsou nakonfigurovány jako pbuslihing targety.

Universal publishing target replication

Jediný rozdíl v porovnání s tradičním publishing targetem je ten, že replikovavaný publishing target není nakonfigurován v Master databázi. Tak je tedy možné přistoupit na různé publishing targety v Desktop prostředí a zároveň nejsou dostupné pro výběr z dialogového okna Publishingu.

Dedikovaný publishing target

Dedikovaný publishing target je samostatná web databáze, umístěna v blízkosti CM serveru. Tato web databáze je pak použita pouze pro docílení rychlého publishe; není použita pro žádné servírování obsahu žádnému CD serveru. Naopak je použita pro replikaci obsahu do vzdálené web databáze, která obsah blízko umístěným CD serverům již poskytuje.

Dedicated publishing target replication

Ve vyobrazeném scénáři jsou dvě web databáze na prvním databázovém serveru a jedna web databáze na druhém. Pro tento use case je obsah centrálně administrován (např. v Evropě) s druhým publishing targetem, reprezentujícím vzdálené umístění konzumace obsahu (např. Asie).

Setup

Celé nastavení je velice dobře popsáno v dokumentu SQL replication guide, dostupném na SDN (toto je stále platné i pro Sitecore série 8.x). Nicméně je zde pár chytáků, které stojí za to zmínit:

  1. Core DB – Příručka replikace tvrdí, že Core DB může být volitelně replikována. Pokud je však Core DB standalone instancí, nebude vhodně čištěna cleanup joby Sitecore – zejména EventQueue – pokud není přímo konfigurována v Sitecore instanci, která tento cleanup provádí. Vzhledem k tomu, že Core databáze může být na každou Sitecore instanci pouze jedna a pouze jedna instance Sitecore by měla provozovat cleanup joby (více instancí provozujících cleanup joby by mohlo vést k deadlockům v databázi), replikace Core DB by měla být považována za jedinou vhodnou cestu, kterou zvolit v případě potřeby provozovat více Core DBs.
  2. Vyprázdnění EventQueue – Vzpomeňte si na vyprázdnění EventQueue tabulky těsně před inicializací snapshotu databáze. EventQueues obsahují timespamp sloupec, který může způsobovat problém při inicializaci replikace.
  3. Startování replikace na větší databázi – Nastavení replikace na nové prázdné databázi je velice rychlé a snadné. Pokud ji potřebujete nastavit na větší databázi (mnoho GB) po pomalejším připojení, bude se vám hodit nastavení prvotní velikosti databáze tak, aby se do ní vešel veškerý prvotně replikovaný obsah a nemusela se přitom zvětšovat. Také nastavte autogrowth logu a datového souboru z 1 MB na něco většího – např. 500 MB. Je dobré pamatovat na to, že inicializace replikace přenosem snapshotu přes SQL Server je poněkud náchylná k problémům, takže, pokud je možnost, vždy je lepší plánovat replikaci v raných fázích projektu, spíše nežli později.
  4. Replicating the views – Sitecore neuvádí možnost replikace views v jejich replikační příručce. Pokud se ale rozhodnete views přecijen replikovat (v současnosti je ve web databázi pouze jedno view dbo.Fields), pamatujte na reinicializaci snapshotu pokaždé když se view změní. Pamatujte na to zejména při každém upgradu Sitecore.

Závěrem

Replikací publishing targetu lze ušetřit mnoho času při publishingu, nejen protože se sníží množství publishing targetů, na které fyzicky publikovat, ale také úsporou velkého množství síťové komunikace a pohybováním obsahu v “bulk” režimu.

Leave a Reply

Your email address will not be published. Required fields are marked *