Memilih platform Azure target untuk menghosting data historis yang diekspor
Salah satu keputusan penting yang akan Anda buat selama proses migrasi adalah memilih di mana Anda akan menyimpan data historis. Untuk membuat keputusan ini, Anda perlu memahami dan dapat membandingkan berbagai platform target.
Artikel ini membandingkan platform target dalam hal performa, biaya, kegunaan, dan overhead manajemen.
Catatan
Pertimbangan dalam tabel ini hanya berlaku untuk migrasi log historis, dan tidak berlaku dalam skenario lain, misalnya retensi jangka panjang.
| Log Dasar/Arsip | Azure Data Explorer (ADX) | Azure Blob Storage | ADX + Azure Blob Storage | |
|---|---|---|---|---|
| Kemampuan: | • Menerapkan sebagian besar pengalaman Log Azure Monitor dengan biaya yang lebih rendah. • Log Dasar disimpan selama delapan hari, dan kemudian secara otomatis ditransfer ke arsip (sesuai dengan periode retensi asli). • Menggunakan pekerjaan pencarian untuk menelusuri seluruh petabyte data dan menemukan peristiwa tertentu. • Untuk penyelidikan mendalam pada rentang waktu tertentu, pulihkan data dari arsip. Data tersebut kemudian akan tersedia di cache panas untuk analitik lebih lanjut. |
• ADX dan Microsoft Sentinel menggunakan Bahasa Kueri Kusto (KQL), memungkinkan Anda untuk mengkueri, mengagregasi, atau menghubungkan data di kedua platform. Misalnya, Anda dapat menjalankan kueri KQL dari Microsoft Sentinel untuk menggabungkan data yang disimpan di ADX dengan data yang disimpan di Log Analytics. • Dengan ADX, Anda memiliki kontrol besar atas ukuran dan konfigurasi kluster. Misalnya, Anda dapat membuat kluster yang lebih besar untuk mencapai throughput penyerapan yang lebih tinggi, atau membuat kluster yang lebih kecil untuk mengontrol biaya Anda. |
Penyimpanan blob dioptimalkan untuk menyimpan data tidak terstruktur dalam jumlah besar. • Menawarkan biaya kompetitif. • Cocok untuk skenario di mana organisasi Anda tidak memprioritaskan aksesibilitas atau performa, seperti ketika ada organisasi harus selaras dengan persyaratan kepatuhan atau audit. |
• Data disimpan dalam penyimpanan blob, yang biayanya rendah. • Anda menggunakan ADX untuk mengkueri data dalam KQL, memungkinkan Anda untuk dengan mudah mengakses data. Pelajari cara mengkueri data Azure Monitor dengan ADX |
| Kegunaan: | Sangat baik Opsi arsip dan pencarian mudah digunakan dan dapat diakses dari portal Microsoft Azure Sentinel. Namun, data tidak segera tersedia untuk kueri. Anda perlu melakukan pencarian untuk mengambil data, yang mungkin memakan waktu, tergantung pada jumlah data yang dipindai dan dikembalikan. |
Baik Cukup mudah digunakan dalam konteks Microsoft Sentinel. Misalnya, Anda bisa menggunakan buku kerja Azure untuk memvisualisasikan data yang tersebar di Microsoft Sentinel dan ADX. Anda juga dapat mengkueri data ADX dari portal Microsoft Sentinel menggunakan proksi ADX. |
Buruk Dengan migrasi data historis, Anda mungkin harus berurusan dengan jutaan file, dan menjelajahi data menjadi tantangan. |
Biasa saja Meskipun menggunakan externaldata operator sangat menantang dengan sejumlah besar blob untuk dirujuk, menggunakan tabel ADX eksternal menghilangkan masalah ini. Definisi tabel eksternal memahami struktur folder penyimpanan blob, dan memungkinkan Anda untuk secara transparan mengkueri data yang terkandung dalam banyak blob dan folder yang berbeda. |
| Overhead manajemen: | Dikelola sepenuhnya Opsi pencarian dan arsip dikelola sepenuhnya dan tidak menambahkan overhead manajemen. |
Tinggi ADX berada di luar Microsoft Azure Sentinel, yang memerlukan pemantauan dan pemeliharaan. |
Rendah Meskipun platform ini membutuhkan sedikit pemeliharaan, memilih platform ini menambahkan tugas pemantauan dan konfigurasi, seperti menyiapkan manajemen siklus hidup. |
Medium Dengan opsi ini, Anda memelihara dan memantau ADX dan Azure Blob Storage, yang keduanya merupakan komponen eksternal ke Microsoft Azure Sentinel. Meskipun ADX dapat dimatikan kadang-kadang, pertimbangkan overhead manajemen ekstra dengan opsi ini. |
| Performa: | Medium Anda biasanya berinteraksi dengan log dasar dalam arsip menggunakan pekerjaan pencarian, yang cocok ketika Anda ingin mempertahankan akses ke data, tetapi tidak memerlukan akses langsung ke data. |
Tinggi ke rendah • Performa kueri kluster ADX tergantung pada jumlah simpul dalam kluster, SKU komputer virtual kluster, partisi data, dan banyak lagi. • Saat Anda menambahkan simpul ke kluster, performa meningkat, dengan biaya tambahan. • Jika Anda menggunakan ADX, kami sarankan Anda mengonfigurasi ukuran kluster Anda untuk menyeimbangkan performa dan biaya. Konfigurasi ini bergantung pada kebutuhan organisasi Anda, termasuk seberapa cepat migrasi Anda perlu diselesaikan, seberapa sering data diakses, dan waktu respons yang diharapkan. |
Rendah Menawarkan dua tingkat performa: Premium atau Standar. Meskipun kedua tingkatan adalah opsi untuk penyimpanan jangka panjang, Standar lebih hemat biaya. Pelajari tentang batas performa dan skalabilitas. |
Rendah Karena data berada di Storage Blob, performa dibatasi oleh platform tersebut. |
| Biaya: | Tinggi Biaya terdiri dari dua komponen: • Biaya penyerapan. Setiap GB data yang diserap ke dalam Log Dasar tunduk pada biaya penyerapan Log Microsoft Sentinel dan Azure Monitor, yang menjumlahkan hingga sekitar $1/GB. Lihat detail harga. • Biaya arsip. Biaya untuk data dalam tingkat arsip menjumlahkan hingga sekitar $0,02/GB per bulan. Lihat detail harga. Selain kedua komponen biaya ini, jika Anda sering membutuhkan akses ke data, biaya tambahan berlaku saat Anda mengakses data melalui pekerjaan pencarian. |
Tinggi ke rendah • Karena ADX adalah kluster komputer virtual, Anda dikenakan biaya berdasarkan penggunaan komputasi, penyimpanan, dan jaringan, ditambah markup ADX (lihat detail harga. Oleh karena itu, semakin banyak simpul yang Anda tambahkan ke kluster Anda dan semakin banyak data yang Anda simpan, semakin tinggi biayanya. • ADX juga menawarkan kemampuan autoscaling untuk beradaptasi dengan beban kerja sesuai permintaan. ADX juga dapat memperoleh manfaat dari harga Instans Cadangan. Anda dapat menjalankan perhitungan biaya Anda sendiri di Kalkulator Harga Azure. |
Rendah Dengan penyiapan optimal, Azure Blob Storage memiliki biaya terendah. Untuk efisiensi dan penghematan biaya yang lebih besar, Azure Storage manajemen siklus hidup dapat digunakan untuk secara otomatis menempatkan blob yang lebih lama ke tingkat penyimpanan yang lebih murah. |
Rendah ADX hanya bertindak sebagai proksi dalam kasus ini, sehingga kluster bisa kecil. Selain itu, kluster dapat dimatikan ketika Anda tidak memerlukan akses ke data dan hanya memulainya saat akses data diperlukan. |
| Cara mengakses data: | Pekerjaan pencarian | Kueri KQL langsung | data eksternal | Kueri KQL yang dimodifikasi |
| Skenario: | Akses sesekali Relevan dalam skenario di mana Anda tidak perlu menjalankan analitik berat atau memicu aturan analitik, dan Anda hanya perlu mengakses data sesekali. |
Akses yang sering Relevan dalam skenario di mana Anda perlu sering mengakses data, dan perlu mengontrol bagaimana kluster berukuran dan dikonfigurasi. |
Kepatuhan/audit • Optimal untuk menyimpan sejumlah besar data yang tidak terstruktur. • Relevan dalam skenario di mana Anda tidak memerlukan akses cepat ke data atau performa tinggi, seperti untuk tujuan kepatuhan atau audit. |
Akses sesekali Relevan dalam skenario di mana Anda ingin mendapatkan manfaat dari biaya rendah Azure Blob Storage, dan mempertahankan akses yang relatif cepat ke data. |
| Kompleksitas: | Sangat rendah | Medium | Rendah | Tinggi |
| Kesiapan: | GA | GA | GA | GA |
Pertimbangan umum
Sekarang setelah Anda mengetahui lebih banyak tentang platform target yang tersedia, tinjau faktor utama ini untuk menyelesaikan keputusan Anda.
- Bagaimana organisasi Anda akan menggunakan log yang diserap?
- Seberapa cepat migrasi perlu berjalan?
- Berapa jumlah data yang akan diserap?
- Berapa estimasi biaya migrasi, selama dan setelah migrasi? Lihat perbandingan platform untuk membandingkan biaya.
Penggunaan log yang diserap
Tentukan bagaimana organisasi Anda akan menggunakan log yang diserap untuk memandu pilihan platform penyerapan Anda.
Pertimbangkan tiga skenario umum ini:
- Organisasi Anda perlu menyimpan log hanya untuk tujuan kepatuhan atau audit. Dalam hal ini, organisasi Anda akan jarang mengakses data. Bahkan jika organisasi Anda mengakses data, performa tinggi atau kemudahan penggunaan bukanlah prioritas.
- Organisasi Anda perlu menyimpan log sehingga tim Anda dapat mengakses log dengan mudah dan cukup cepat.
- Organisasi Anda perlu menyimpan log sehingga tim Anda dapat mengakses log sesekali. Performa dan kemudahan penggunaan bersifat sekunder.
Lihat perbandingan platform untuk memahami platform mana yang sesuai dengan masing-masing skenario ini.
Kecepatan migrasi
Dalam beberapa skenario, Anda mungkin perlu memenuhi tenggat waktu yang ketat, misalnya, organisasi Anda mungkin perlu pindah secara mendesak dari SIEM sebelumnya karena peristiwa kedaluwarsa lisensi.
Tinjau komponen dan faktor yang menentukan kecepatan migrasi Anda.
Sumber data
Sumber data biasanya merupakan sistem file lokal atau penyimpanan cloud, misalnya, S3. Performa penyimpanan server tergantung pada beberapa faktor, seperti teknologi disk (SSD vs HDD), sifat permintaan IO, dan ukuran setiap permintaan.
Misalnya, performa komputer virtual Azure berkisar dari 30 MB per detik pada SKU VM yang lebih kecil, hingga 20 GB per detik untuk beberapa SKU yang dioptimalkan penyimpanan menggunakan disk NVM Ekspres (NVMe). Pelajari cara mendesain Azure VM Anda untuk performa penyimpanan tinggi. Anda juga dapat menerapkan sebagian besar konsep ke server lokal.
Daya komputasi
Dalam beberapa kasus, bahkan jika disk Anda mampu menyalin data Anda dengan cepat, daya komputasi adalah hambatan dalam proses penyalinan. Dalam kasus ini, Anda dapat memilih salah satu opsi penskalaan ini:
- Skalakan secara vertikal. Anda meningkatkan kekuatan satu server dengan menambahkan lebih banyak CPU, atau meningkatkan kecepatan CPU.
- Skalakan secara horizontal. Anda menambahkan lebih banyak server, yang meningkatkan paralelisme proses penyalinan.
Platform target
Setiap platform target yang dibahas di bagian ini memiliki profil performa yang berbeda.
- Log Dasar Azure Monitor. Secara default, log Dasar dapat didorong ke Azure Monitor dengan kecepatan sekitar 1 GB per menit. Tarif ini memungkinkan Anda untuk menyerap sekitar 1,5 TB per hari atau 43 TB per bulan.
- Azure Data Explorer. Performa penyerapan bervariasi, tergantung pada ukuran kluster yang Anda provisikan, dan pengaturan batching yang Anda terapkan. Pelajari tentang praktik terbaik penyerapan, termasuk performa dan pemantauan.
- Azure Blob Storage. Performa akun Azure Blob Storage dapat sangat bervariasi tergantung pada jumlah dan ukuran file, ukuran pekerjaan, konkurensi, dan sebagainya. Pelajari cara mengoptimalkan performa AzCopy dengan Azure Storage.
Jumlah data
Jumlah data adalah faktor utama yang memengaruhi durasi proses migrasi. Oleh karena itu, Anda harus mempertimbangkan cara menyiapkan lingkungan Anda tergantung pada himpunan data Anda.
Untuk menentukan durasi minimum migrasi dan di mana hambatan bisa, pertimbangkan jumlah data dan kecepatan penyerapan platform target. Misalnya, Anda memilih platform target yang dapat menyerap 1 GB per detik, dan Anda harus memigrasikan 100 TB. Dalam hal ini, migrasi Anda akan memakan waktu minimal 100.000 GB, dikalikan dengan kecepatan 1 GB per detik. Bagi hasilnya dengan 3600, yang dihitung hingga 27 jam. Perhitungan ini benar jika komponen lainnya dalam alur, seperti disk lokal, jaringan, dan komputer virtual, dapat melakukan dengan kecepatan 1 GB per detik.
Langkah berikutnya
Dalam artikel ini, Anda telah mempelajari cara memetakan aturan migrasi dari QRadar ke Microsoft Sentinel.