Vyberte cílovou platformu Azure pro hostování exportovaných historických dat.
Jedním z důležitých rozhodnutí, která jste udělali během procesu migrace, je místo pro ukládání historických dat. Pokud chcete toto rozhodnutí provést, musíte porozumět různým cílovým platformám a být schopni 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:
Aspekty v této tabulce platí jenom pro historickou migraci protokolů a neplatí v jiných scénářích, 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řevedou do archivu (podle původní doby uchovávání). • Pomocí úloh vyhledávání můžete vyhledávat v petabajtech dat a vyhledávat konkrétní události. • Pro hloubkové šetření v určitém časovém rozsahu obnovte data z archivu. Data jsou pak k dispozici v horké mezipaměti pro další analýzu. |
• ADX i Microsoft Sentinel používají dotazovací jazyk Kusto (KQL), které umožňují dotazovat, agregovat nebo korelovat data na obou platformách. Můžete například spustit dotaz KQL z Microsoft Sentinelu pro připojení dat uložených v ADX s daty uloženými v Log Analytics. • S 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ář, ve kterém vaše organizace nemá prioritu přístupnosti nebo výkonu, jako je situace, kdy organizace musí sladit 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 se dotazujete na 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 však nejsou okamžitě k dispozici pro dotazy. K načtení dat je potřeba provést vyhledávání, které může nějakou dobu trvat v závislosti na množství naskenovaných a vrácených dat. |
Dobrý V kontextu Microsoft Sentinelu je poměrně snadné. Pomocí sešitu Azure můžete například vizualizovat data rozložená mezi Microsoft Sentinelem a ADX. Data ADX můžete také dotazovat z portálu Microsoft Sentinel pomocí proxy serveru ADX. |
Chudý Při historických migracích dat možná budete muset řešit miliony souborů a zkoumání dat se stává výzvou. |
Jarmark Použití operátoru externaldata je velmi náročné s velkým počtem objektů blob, na které se odkazuje, 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žijní náklady na správu: | Plně spravovaná Možnosti vyhledávání a archivace jsou plně spravované a nepřidávají režijní náklady na správu. |
Vysoko ADX je externí pro 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ává úlohy monitorování a konfigurace, jako je nastavení správy životního cyklu. |
Medium Pomocí této možnosti udržujete a monitorujete ADX a Azure Blob Storage, z nichž obě jsou externí komponenty pro Microsoft Sentinel. I když je možné ADX občas vypnout, zvažte další režii při správě pomocí této možnosti. |
| Výkon: | Medium Obvykle pracujete se základními protokoly v archivu pomocí úloh vyhledávání, které jsou vhodné, když chcete zachovat přístup k datům, ale nepotřebujete okamžitý přístup k datům. |
Vysoká až nízká • Výkon dotazů clusteru ADX závisí na počtu uzlů v clusteru, skladové po straně virtuálního počítače clusteru, dělení dat a dalších. • Při přidávání uzlů do clusteru se zvyšuje výkon s přidanými náklady. • Pokud používáte ADX, doporučujeme nakonfigurovat velikost clusteru tak, aby vyrovnáovala výkon a náklady. Tato konfigurace závisí na potřebách vaší organizace, včetně toho, jak rychle se má migrace dokončit, jak často se k datům přistupuje, a očekávanou dobu 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ší. Seznamte se s limity výkonu a škálovatelnosti. |
Nízký Vzhledem k tomu, že se data nacházejí ve službě Blob Storage, je výkon omezen danou platformou. |
| Náklady: | Vysoko Náklady se skládají ze dvou součástí: • Náklady na příjem dat. Každá GB dat přijatých do základních protokolů podléhá nákladům na příjem dat služby Microsoft Sentinel a Azure Monitor, které sečtou až 1 USD/GB. Podívejte se na podrobnosti o cenách. • Archivní náklady. Náklady na data v archivní úrovni se sčítají do přibližně 0,02 USD za měsíc. Podívejte se na podrobnosti o cenách. Kromě těchtodvouch |
Vysoká až nízká • 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 také značek ADX (viz podrobnosti o cenách. Čím více uzlů přidáte do clusteru a čím více dat ukládáte, tím vyšší budou náklady. • ADX také nabízí možnosti automatického škálování, které se přizpůsobí úlohám na vyžádání. Služba ADX může také využívat ceny rezervovaných instancí. V cenové kalkulačce Azure můžete spouštět vlastní výpočty nákladů. |
Nízký S optimálním nastavením má Azure Blob Storage nejnižší náklady. Kvůli větší efektivitě a úsporám nákladů je možné použít správu životního cyklu služby Azure Storage k automatickému umístě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.< a1/a0> |
| Jak získat přístup k datům: | Úlohy hledání | Přímé dotazy KQL | Operátor externích dat KQL | Upravené dotazy KQL |
| Scénář: | Občasný přístup Relevantní v situacích, kdy nepotřebujete spouštět velká analytická pravidla nebo spouštět analytická pravidla, a přístup k datům potřebujete jenom občas. |
Častý přístup Relevantní v situacích, kdy potřebujete často přistupovat k datům, a potřebujete řídit, jak je cluster velký a nakonfigurovaný. |
Dodržování předpisů / audit • Optimální pro ukládání velkých objemů nestrukturovaných dat. • Relevantní ve scénářích, ve kterých nepotřebujete rychlý přístup k datům nebo k vysokému výkonu, 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á | Velký zájem |
| 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í.
- Jak bude vaše organizace používat ingestované protokoly?
- Jak rychle se migrace musí spustit?
- Jaké je množství dat k ingestování?
- Jaké jsou odhadované náklady na migraci během migrace a po migraci? Porovnání nákladů najdete v porovnání platforem.
Použití přijatých protokolů
Definujte, jak bude vaše organizace používat ingestované protokoly k vedení vašeho 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 auditu. V takovém případě bude vaše organizace zřídka přistupovat k datům. I když vaše organizace přistupuje k datům, vysoký výkon nebo snadné použití nejsou prioritou.
- Vaše organizace potřebuje protokoly zachovat, aby vaše týmy mohly k protokolům přistupovat snadno a poměrně rychle.
- Vaše organizace potřebuje uchovávat protokoly, aby k protokolům mohly občas přistupovat vaše týmy. 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 konečný termín, například kvůli události vypršení platnosti licence bude vaše organizace muset naléhavě přejít z 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 je například disková technologie (SSD nebo HDD), povaha požadavků na vstupně-výstupní operace 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ě pomocí disků NVM Express (NVMe). Zjistěte, jak navrhnout virtuální počítač Azure pro zajištění vysokého výkonu ú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, i když je disk schopný rychle kopírovat data, je výpočetní výkon kritickým bodem procesu kopírování. V těchto případech můžete zvolit jednu z těchto možností škálování:
- Vertikální škálování Výkon jednoho serveru zvýšíte přidáním dalších procesorů nebo zvýšíte 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á v této části má jiný profil výkonu.
- Základní protokoly služby Azure Monitor Ve výchozím nastavení je možné základní protokoly odesílat do služby Azure Monitor 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 nastavení dávkování, které použijete. Seznamte se s osvědčenými postupy příjmu dat, včetně výkonu a monitorování.
- Azure Blob Storage. Výkon účtu služby 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 pomocí služby Azure Storage.
Množství dat
Objem dat je hlavním faktorem, který ovlivňuje dobu trvání procesu migrace. Proto byste měli zvážit, jak nastavit prostředí v závislosti na vaší sadě dat.
Pokud chcete určit minimální dobu trvání migrace a místo, 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 musíte 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 zbývající komponenty v kanálu, jako je místní disk, síť a virtuální počítače, mohou provádět rychlostí 1 GB za sekundu.
Další kroky
V tomto článku jste zjistili, jak namapovat pravidla migrace z QRadar na Microsoft Sentinel.