Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Mechanismy replikace služby Azure HDInsight je možné integrovat do architektury vysoce dostupných řešení. V tomto článku se fiktivní případová studie společnosti Contoso Retail používá k vysvětlení možných přístupů k zotavení po havárii s vysokou dostupností, aspektů nákladů a jejich odpovídajících návrhů.
Doporučení pro zotavení po havárii s vysokou dostupností můžou mít mnoho permutací a kombinací. Tato řešení musí být doručena po deliberování výhod a nevýhod jednotlivých možností. Tento článek popisuje pouze jedno možné řešení.
Architektura zákazníka
Následující obrázek znázorňuje primární architekturu contoso retailu. Architektura se skládá z úlohy streamování, dávkové úlohy, obsluhující vrstvy, vrstvy spotřeby, vrstvy úložiště a správy verzí.
Úloha streamování
Zařízení a senzory vytvářejí data do HDInsight Kafka, což představuje architekturu zasílání zpráv. Spotřebitel Spark v HDInsight čte z témat Kafka. Spark transformuje příchozí zprávy a zapíše je do clusteru HDInsight HBase na obslužné vrstvě.
Dávkové pracovní zatížení
Cluster HDInsight Hadoop se systémem Hive a MapReduce ingestuje data z místních transakčních systémů. Nezpracovaná data transformovaná Hivem a MapReduce se ukládají v tabulkách Hive v logickém oddílu datového jezera zálohovaného službou Azure Data Lake Storage Gen2. Data uložená v tabulkách Hive jsou také dostupná pro Spark SQL, která provádí dávkové transformace před uložením kurátorovaných dat do HBase pro obsluhu.
Obslužná vrstva
Cluster HDInsight HBase s Apache Phoenixem slouží k poskytování dat webovým aplikacím a řídicím panelům vizualizace. Cluster HDInsight LLAP slouží ke splnění interních požadavků na vytváření sestav.
Vrstva spotřeby
Vrstva Azure API Apps a API Management podporuje veřejně dostupnou webovou stránku. Power BI zajišťuje plnění požadavků na interní reportování.
Vrstva úložiště
Logicky dělené Azure Data Lake Storage Gen2 se používá jako podnikové datové jezero. Metastory HDInsight jsou podporovány službou Azure SQL DB.
Systém správy verzí
Systém správy verzí integrovaný do Azure Pipelines a hostovaný mimo Azure.
Požadavky na provozní kontinuitu zákazníků
Je důležité určit minimální obchodní funkce, které budete potřebovat, pokud dojde k havárii.
Požadavky společnosti Contoso Retail na kontinuitu podnikových procesů
- Musíme být chráněni před regionálním selháním nebo regionálním problémem se stavem služeb.
- Moji zákazníci nesmí nikdy vidět chybu 404. Veřejný obsah musí být vždy poskytován. (RTO = 0)
- Ve většině částí roku můžeme zobrazit veřejný obsah, který je zastaralý o 5 hodin. (RPO = 5 hodin)
- Během svátků musí být náš veřejný obsah vždy aktuální. (RPO = 0)
- Moje vnitřní požadavky na vytváření sestav nejsou považovány za kritické pro kontinuitu podnikání.
- Optimalizujte náklady na provozní kontinuitu.
Navrhované řešení
Následující obrázek ukazuje architekturu zotavení po havárii společnosti Contoso Retail s vysokou mírou dostupnosti.
Kafka používá aktivní – pasivní replikaci k zrcadlení témat Kafka z primární oblasti do sekundární oblasti. Alternativou k replikaci Kafka může být vytvoření do Kafka v obou oblastech.
Hive a Spark používají aktivní primární – sekundární modely replikace na vyžádání v normálních časech. Proces replikace Hive se pravidelně spouští a zahrnuje replikaci Hive Azure SQL metastore a účtu úložiště Hive. Účet úložiště Spark se pravidelně replikuje pomocí ADF DistCP. Přechodná povaha těchto clusterů pomáhá optimalizovat náklady. Replikace se naplánují každých 4 hodiny tak, aby dorazily do cíle bodu obnovení, který je v pětihodinovém požadavku.
Replikace HBase používá model Leader – Follower za běžných podmínek, aby se zajistilo, že se data vždy obsluhují bez ohledu na to, ve které oblasti se nachází, a cílový čas obnovení je velmi nízký.
Pokud v primární oblasti dojde k regionálnímu selhání, webová stránka a back-endový obsah se obsluhují ze sekundární oblasti po dobu 5 hodin s určitým stupněm zastaralosti. Pokud řídicí panel stavu služby Azure v pětihodinovém intervalu neuvede odhadovaný čas obnovení, vytvoří společnost Contoso Retail vrstvu transformace Hive a Spark v sekundární oblasti a pak nasměruje všechny zdroje dat v předcházejícím toku do sekundární oblasti. Zpřístupnění sekundární oblasti pro zápis by způsobilo proces obnovení, který zahrnuje replikaci zpět do primární oblasti.
Během špičky nákupní sezóny je celý sekundární kanál vždy aktivní a spuštěný. Producenti Kafka produkují do obou oblastí a replikace HBase by byla změněna z Leader-Follower na Leader-Leader, aby byl veřejný obsah vždy aktuální.
Pro interní reporting není potřeba navrhovat žádné řešení pro případ výpadku, protože pro kontinuitu podnikání není důležité.
Další kroky
Další informace o položkách probíraných v tomto článku najdete tady: