Vyberte cílovou platformu Azure pro hostování exportovaných historických dat.

Jedním z důležitých rozhodnutí, která během procesu migrace uděláte, je místo, kam ukládat historická data. K tomuto rozhodnutí potřebujete porozumět různým cílovým platformám a umět je porovnat.

Tento článek porovnává cílové platformy z hlediska výkonu, nákladů, použitelnosti a režijních nákladů na správu.

Poznámka

Důležité informace v této tabulce platí jenom pro migraci historických protokolů a nevztahují se na jiné scénáře, jako je dlouhodobé uchovávání.

Základní protokoly / Archiv Azure Data Explorer (ADX) Azure Blob Storage ADX + Azure Blob Storage
Možnosti: • Využijte většinu stávajících prostředí protokolů služby Azure Monitor s nižšími náklady.
• Základní protokoly se uchovávají po dobu osmi dnů a pak se automaticky přenesou do archivu (podle původní doby uchovávání).
• Pomocí úloh vyhledávání můžete vyhledávat petabajty dat a hledat konkrétní události.
• V případě hloubkového zkoumání konkrétního časového rozsahu obnovte data z archivu. Data jsou pak k dispozici v horké mezipaměti pro další analýzy.
• ADX i Microsoft Sentinel používají dotazovací jazyk Kusto (KQL), což umožňuje dotazování, agregaci nebo korelaci dat na obou platformách. Můžete například spustit dotaz KQL ze služby Microsoft Sentinel a spojit data uložená v ADX s daty uloženými v Log Analytics.
• Se službou ADX máte značnou kontrolu nad velikostí a konfigurací clusteru. Můžete například vytvořit větší cluster, abyste dosáhli vyšší propustnosti příjmu dat, nebo vytvořit menší cluster pro řízení nákladů.
• Úložiště objektů blob je optimalizované pro ukládání obrovských objemů nestrukturovaných dat.
• Nabízí konkurenční náklady.
• Vhodné pro scénář, kdy vaše organizace nedává prioritu přístupnosti nebo výkonu, například když tam musí být v souladu s požadavky na dodržování předpisů nebo audit.
• Data se ukládají v úložišti objektů blob, což je nízké náklady.
• Pomocí ADX můžete dotazovat data v KQL, což vám umožní snadný přístup k datům. Zjistěte, jak dotazovat data služby Azure Monitor pomocí ADX.
Použitelnost: Skvělé

Možnosti archivace a vyhledávání jsou snadno použitelné a přístupné z portálu Microsoft Sentinel. Data ale nejsou pro dotazy okamžitě dostupná. K načtení dat je potřeba provést vyhledávání, což může v závislosti na množství kontrolovaných a vrácených dat nějakou dobu trvat.
Dobré

Poměrně snadné použití v kontextu služby Microsoft Sentinel. Sešit Azure můžete například použít k vizualizaci dat rozložených ve službě Microsoft Sentinel a ADX. Data ADX můžete také dotazovat z portálu Služby Microsoft Sentinel pomocí proxy serveru ADX.
Slabé

Při migracích historických dat se možná budete muset vypořádat s miliony souborů a prozkoumání dat se stane výzvou.
Přiměřené

I když je použití operátoru externaldata velmi náročné s velkým počtem objektů blob, na které je potřeba odkazovat, použití externích tabulek ADX tento problém eliminuje. Definice externí tabulky rozumí struktuře složek úložiště objektů blob a umožňuje transparentně dotazovat data obsažená v mnoha různých objektech blob a složkách.
Režie na správu: Plně spravovaná

Možnosti vyhledávání a archivace jsou plně spravované a nepřidávají režii na správu.
Vysoká

Služba ADX je externí pro Službu Microsoft Sentinel, která vyžaduje monitorování a údržbu.
Nízká

I když tato platforma vyžaduje malou údržbu, výběr této platformy přidá úlohy monitorování a konfigurace, jako je nastavení správy životního cyklu.
Medium

S touto možností budete udržovat a monitorovat ADX a Azure Blob Storage, což jsou externí komponenty služby Microsoft Sentinel. AdX se dá občas vypnout, ale u této možnosti zvažte další režijní náklady na správu.
Výkon: Medium

Se základními protokoly v archivu obvykle pracujete pomocí úloh hledání, které jsou vhodné, když chcete zachovat přístup k datům, ale nepotřebujete k nim okamžitý přístup.
Od nejvyššího po nejnižší

• Výkon dotazů clusteru ADX závisí na počtu uzlů v clusteru, skladové pořidce virtuálního počítače clusteru, dělení dat a dalších.
• S přidáváním uzlů do clusteru se zvyšuje výkon s dalšími náklady.
• Pokud používáte ADX, doporučujeme nakonfigurovat velikost clusteru tak, aby se vyrovnaly výkon a náklady. Tato konfigurace závisí na potřebách vaší organizace, včetně rychlosti dokončení migrace, četnosti přístupu k datům a očekávané doby odezvy.
Nízká

Nabízí dvě úrovně výkonu: Premium nebo Standard. I když obě úrovně představují možnost dlouhodobého úložiště, standard je nákladově efektivnější. Přečtěte si o omezeních výkonu a škálovatelnosti.
Nízká

Vzhledem k tomu, že se data nacházejí ve službě Blob Storage, je výkon této platformy omezený.
Náklady: Vysoká

Náklady se skládají ze dvou složek:
Náklady na příjem dat. Každý GB dat ingestovaných do základních protokolů podléhá nákladům na příjem protokolů služby Microsoft Sentinel a Azure Monitor, které v součtu činí přibližně 1 USD/GB. Podívejte se na podrobnosti o cenách.
Náklady na archivaci. Náklady na data v archivní vrstvě se sčítají přibližně do 0,02 USD/GB za měsíc. Podívejte se na podrobnosti o cenách.
Kromě těchto dvou nákladových složek platí, že pokud potřebujete častý přístup k datům, při přístupu k datům prostřednictvím úloh vyhledávání se můžou vyžadovat další náklady.
Od nejvyššího po nejnižší

• Vzhledem k tomu, že ADX je cluster virtuálních počítačů, účtují se vám poplatky na základě využití výpočetních prostředků, úložiště a sítí a přirážky ADX (viz podrobnosti o cenách. Proto čím více uzlů přidáte do clusteru a čím více dat uložíte, tím vyšší budou náklady.
• ADX také nabízí možnosti automatického škálování pro přizpůsobení úlohám na vyžádání. Služba ADX může také využívat ceny rezervovaných instancí. Vlastní výpočty nákladů můžete provádět v cenové kalkulačce Azure.
Nízká

Při optimálním nastavení má Azure Blob Storage nejnižší náklady. Pro vyšší efektivitu a úsporu nákladů je možné použít správu životního cyklu služby Azure Storage k automatickému umísťování starších objektů blob do levnějších úrovní úložiště.
Nízká

ADX v tomto případě funguje jenom jako proxy server, takže cluster může být malý. Kromě toho je možné cluster vypnout, když nepotřebujete přístup k datům, a spustit ho jenom v případě, že je potřeba přístup k datům.
Jak získat přístup k datům: Úlohy hledání Přímé dotazy KQL externaldata Upravené dotazy KQL
Scénář: Občasný přístup

Relevantní ve scénářích, kdy nepotřebujete spouštět náročné analýzy nebo aktivovat analytická pravidla a potřebujete k datům přistupovat jen příležitostně.
Častý přístup

Relevantní ve scénářích, kdy potřebujete často přistupovat k datům a potřebujete řídit velikost a konfiguraci clusteru.
Dodržování předpisů nebo audit

• Optimální pro ukládání obrovských objemů nestrukturovaných dat.
• Relevantní ve scénářích, kdy nepotřebujete rychlý přístup k datům nebo vysoký výkon, například pro účely dodržování předpisů nebo auditu.
Občasný přístup

Relevantní ve scénářích, ve kterých chcete těžit z nízkých nákladů na Azure Blob Storage a udržovat relativně rychlý přístup k datům.
Složitost: Velmi nízká Střední Nízká Vysoká
Připravenost: GA GA GA GA

Obecné aspekty

Teď, když víte více o dostupných cílových platformách, projděte si tyto hlavní faktory a dokončete své rozhodnutí.

Použití ingestovaných protokolů

Definujte, jak bude vaše organizace používat ingestované protokoly k výběru platformy pro příjem dat.

Vezměte v úvahu tyto tři obecné scénáře:

  • Vaše organizace musí protokoly uchovávat jenom pro účely dodržování předpisů nebo auditování. V takovém případě bude vaše organizace k datům přistupovat jen zřídka. I když vaše organizace přistupuje k datům, není vysoký výkon nebo snadné použití prioritou.
  • Vaše organizace musí protokoly uchovávat, aby k nim vaše týmy mohly snadno a poměrně rychle přistupovat.
  • Vaše organizace musí protokoly uchovávat, aby k nim vaše týmy mohly příležitostně přistupovat. Výkon a snadné použití jsou sekundární.

Podívejte se na porovnání platforem , abyste pochopili, která platforma vyhovuje jednotlivým scénářům.

Rychlost migrace

V některých scénářích může být potřeba splnit přísný termín, například vaše organizace bude muset kvůli události vypršení platnosti licence naléhavě přejít od předchozího systému SIEM.

Projděte si komponenty a faktory, které určují rychlost migrace.

Zdroj dat

Zdrojem dat je obvykle místní systém souborů nebo cloudové úložiště, například S3. Výkon úložiště serveru závisí na několika faktorech, jako jsou disková technologie (SSD vs. HDD), povaha vstupně-výstupních požadavků a velikost jednotlivých požadavků.

Například výkon virtuálních počítačů Azure se pohybuje od 30 MB za sekundu u menších skladových položek virtuálních počítačů až po 20 GB za sekundu u některých skladových položek optimalizovaných pro úložiště, které používají disky NVM Express (NVMe). Zjistěte, jak navrhnout virtuální počítač Azure pro vysoký výkon úložiště. Většinu konceptů můžete použít také na místní servery.

Výpočetní výkon

V některých případech je výpočetní výkon kritickým bodem procesu kopírování i v případě, že váš disk dokáže data rychle kopírovat. V těchto případech můžete zvolit jednu z těchto možností škálování:

  • Vertikální škálování Můžete zvýšit výkon jednoho serveru přidáním dalších procesorů nebo zvýšit rychlost procesoru.
  • Horizontální škálování Přidáte další servery, což zvyšuje paralelismus procesu kopírování.

Cílová platforma

Každá z cílových platforem probíraných v této části má jiný profil výkonu.

  • Základní protokoly služby Azure Monitor. Ve výchozím nastavení je možné do Služby Azure Monitor odesílat základní protokoly rychlostí přibližně 1 GB za minutu. Tato rychlost umožňuje ingestovat přibližně 1,5 TB za den nebo 43 TB za měsíc.
  • Azure Data Explorer. Výkon příjmu dat se liší v závislosti na velikosti clusteru, který zřídíte, a na nastavení dávkování, které použijete. Seznamte se s osvědčenými postupy pro příjem dat, včetně výkonu a monitorování.
  • Azure Blob Storage. Výkon účtu Azure Blob Storage se může výrazně lišit v závislosti na počtu a velikosti souborů, velikosti úlohy, souběžnosti atd. Zjistěte, jak optimalizovat výkon AzCopy s využitím Služby Azure Storage.

Množství dat

Množství dat je hlavním faktorem, který ovlivňuje dobu trvání procesu migrace. V závislosti na datové sadě byste proto měli zvážit, jak nastavit prostředí.

Pokud chcete určit minimální dobu trvání migrace a kde může být kritický bod, zvažte množství dat a rychlost příjmu dat cílové platformy. Například vyberete cílovou platformu, která může ingestovat 1 GB za sekundu, a budete muset migrovat 100 TB. V takovém případě bude vaše migrace trvat minimálně 100 000 GB vynásobenou rychlostí 1 GB za sekundu. Vydělte výsledek 3600, který se vypočítá na 27 hodin. Tento výpočet je správný, pokud ostatní komponenty v kanálu, jako je místní disk, síť a virtuální počítače, můžou fungovat rychlostí 1 GB za sekundu.

Další kroky

V tomto článku jste se dozvěděli, jak namapovat pravidla migrace z QRadaru na Microsoft Sentinel.