تحديد نظام Azure الأساسي المستهدف لاستضافة البيانات السابقة التي تم تصديرها

تعد من أحد القرارات المهمة التي تتخذها في أثناء عملية الترحيل هو مكان تخزين بياناتك السابقة. لاتخاذ هذا القرار، عليك فهم ومقارنة الأنظمة الأساسية المستهدفة المختلفة.

تقارن هذه المقالة الأنظمة الأساسية المستهدفة من حيث الأداء والتكلفة وقابلية الاستخدام والنفقات العامة للإدارة.

ملاحظة

تنطبق الاعتبارات الموجودة في هذا الجدول فقط على ترحيل السجل السابق، ولا تنطبق في سيناريوهات أخرى، مثل الاستبقاء طويل الأجل.

السجلات الأساسية/الأرشيف Azure Data Explorer (ADX) Azure Blob Storage ADX + Azure Blob Storage
الإمكانات: • تطبيق معظم تجارب Azure Monitor Logs الحالية بتكلفة أقل.
• يتم الاحتفاظ بالسجلات الأساسية لمدة ثمانية أيام، ثم يتم نقلها تلقائياً إلى الأرشيف (وفقاً لفترة الاستبقاء الأصلية).
• استخدام مهام البحث للبحث عبر بيتابايت من البيانات والعثور على أحداث محددة.
• لإجراء تحقيقات عميقة حول نطاق زمني محدد، يمكنك استعادة البيانات من الأرشيف. ثم تتوفر البيانات في ذاكرة التخزين المؤقت الساخنة لإجراء مزيد من التحليلات.
• يستخدم كل من ADX وMicrosoft Sentinel لغة استعلام Kusto (KQL)، مما يسمح لك بالاستعلام عن البيانات أو تجميعها أو ربطها في كلا النظامين الأساسيين. على سبيل المثال، يمكنك تشغيل استعلام KQL من Microsoft Sentinel للانضمام إلى البيانات المخزنة في ADX مع البيانات المخزنة في Log Analytics.
• من خلال ADX، لديك تحكم كبير في حجم نظام المجموعة وتكوينها. على سبيل المثال، يمكنك إنشاء مجموعة أكبر لتحقيق معدل نقل استيعاب أعلى، أو إنشاء مجموعة أصغر للتحكم في التكاليف الخاصة بك.
تم تحسين موقع تخزين الكائنات الثنائية كبيرة الحجم لتخزين كميات هائلة من البيانات غير المهيكلة.
• يوفر تكاليف تنافسية.
• مناسب لسيناريو لا تعطي فيه مؤسستك الأولوية لإمكانية الوصول أو الأداء، على سبيل المثال، عندما تكون المؤسسة هناك متوافقة مع متطلبات التوافق أو التدقيق.
• يتم تخزين البيانات في موقع تخزين كائن ثنائي كبير الحجم، وهو منخفض التكاليف.
• يمكنك استخدام ADX للاستعلام عن البيانات في KQL، مما يسمح لك بالوصول بسهولة إلى البيانات. تعرف على كيفية الاستعلام عن بيانات Azure Monitor باستخدام ADX
قابلية الاستخدام: رائع

خيارات الأرشيف والبحث سهلة الاستخدام ويمكن الوصول إليها من مدخل Microsoft Sentinel. ومع ذلك، لا تتوفر البيانات على الفور للاستعلامات. تحتاج إلى إجراء بحث لاسترداد البيانات، والتي قد تستغرق بعض الوقت، اعتماداً على كمية البيانات التي يتم مسحها ضوئياً وإرجاعها.
جيد

سهل الاستخدام إلى حد ما في سياق Microsoft Sentinel. على سبيل المثال، يمكنك استخدام مصنف Azure لتصور البيانات المنتشرة عبر كل من Microsoft Sentinel وADX. يمكنك أيضاً الاستعلام عن بيانات ADX من مدخل Microsoft Sentinel باستخدام وكيل ADX.
رديء

من خلال عمليات ترحيل البيانات السابقة، قد تضطر إلى التعامل مع ملايين الملفات، ويصبح استكشاف البيانات أمراً صعباً.
متوسط

في أثناء استخدام عامل التشغيل externaldata يمثل تحدياً كبيراً مع وجود أعداد كبيرة من الكائنات الثنائية كبيرة الحجم للإشارة إليها، فإن استخدام جداول ADX الخارجية يلغي هذه المشكلة. يفهم تعريف الجدول الخارجي بنية مجلد تخزين الكائن الثنائي كبير الحجم، ويسمح لك بالاستعلام بشفافية عن البيانات الموجودة في العديد من الكائنات الثنائية كبيرة الحجم والمجلدات المختلفة.
النفقات الإدارية: مدُار بشكل كامل:

تتم إدارة خيارات البحث والأرشيف بشكل كامل ولا تضيف نفقات إدارية.
درجة عالية

ADX خارجي لـ Microsoft Sentinel، والذي يتطلب المراقبة والصيانة.
منخفض

في حين أن هذا النظام الأساسي يتطلب القليل من الصيانة، فإن تحديد هذا النظام الأساسي يضيف مهام المراقبة والتكوين، مثل إعداد إدارة دورة الحياة.
متوسط

باستخدام هذا الخيار، يمكنك صيانة ومراقبة ADX وAzure Blob Storage، وكلاهما مكونان خارجيان لـ Microsoft Sentinel. بينما يمكن إيقاف تشغيل ADX في بعض الأحيان، ضع في اعتبارك النفقات الإدارية الإضافية باستخدام هذا الخيار.
الأداء: متوسط

عادة ما تتفاعل مع السجلات الأساسية داخل الأرشيف باستخدام مهام البحث، وهي مناسبة عندما تريد الحفاظ على الوصول إلى البيانات، ولكن لا تحتاج إلى الوصول الفوري إلى البيانات.
عالي إلى منخفض

• يعتمد أداء الاستعلام لنظام مجموعة ADX على عدد العُقد في نظام المجموعة، وSKU الجهاز الظاهري لنظام المجموعة، وتقسيم البيانات، والمزيد.
• أثناء إضافة العُقد إلى نظام المجموعة، يتحسن الأداء، مع إضافة تكلفة.
• إذا كنت تستخدم ADX، نوصي بتكوين حجم نظام مجموعتك لتحقيق التوازن بين الأداء والتكلفة. يعتمد هذا التكوين على احتياجات مؤسستك، بما في ذلك مدى سرعة اكتمال الترحيل، ومدى تكرار الوصول إلى البيانات، ووقت الاستجابة المتوقع.
منخفض

يقدم مستويين من الأداء: متميز أو قياسي. على الرغم من أن كلا المستويين خيار للتخزين طويل الأجل، فإن القياسي أكثر كفاءة من حيث التكلفة. تعرف على حدود الأداء وقابلية التوسع.
منخفض

نظراً لوجود البيانات في Blob Storage، فإن الأداء محدود بواسطة هذا النظام الأساسي.
التكلفة: درجة عالية

تتكون التكلفة من مكونين:
تكلفة الاستيعاب. يخضع كل جيجابايت من البيانات التي يتم استيعابها في السجلات الأساسية لتكاليف استيعاب Microsoft Sentinel وAzure Monitor Logs، والتي تصل إلى حوالي دولار أمريكي واحد/غيغابايت. راجع ⁧⁩تفاصيل الأسعار⁧⁩.
تكلفة الأرشفة. تكلفة البيانات في طبقة الأرشيف تصل إلى حوالي 0.02 دولار أمريكي/غيغابايت شهرياً. راجع ⁧⁩تفاصيل الأسعار⁧⁩.
بالإضافة إلى مكوني التكلفة هذين، إذا كنت بحاجة إلى الوصول المتكرر إلى البيانات، يتم تطبيق تكاليف إضافية عند الوصول إلى البيانات عبر مهام البحث.
عالٍ إلى منخفض

• نظراً أن ADX عبارة عن نظام مجموعة من الأجهزة الظاهرية، يتم تحصيل رسوم منك استناداً إلى الحوسبة والتخزين واستخدام الشبكات، بالإضافة إلى علامات ADX (راجع تفاصيل الأسعار. لذلك، كلما زادت العُقد التي تضيفها إلى مجموعتك والمزيد من البيانات التي تخزنها، زادت التكلفة.
• يوفر ADX أيضاً قدرات التحجيم التلقائي للتكيف مع حمل العمل عند الطلب. يمكن أن تستفيد ADX أيضاً من تسعير المثيل المحجوز. يمكنك تشغيل حسابات التكلفة الخاصة بك في Azure Pricing Calculator.
منخفض

من خلال الإعداد الأمثل، يحتوي Azure Blob Storage على أقل التكاليف. لمزيد من الكفاءة وتوفير التكاليف، يمكن استخدام إدارة دورة حياة Azure Storage لوضع الكائنات الثنائية كبيرة الحجم القديمة تلقائياً في طبقات تخزين أرخص.
منخفض

يعمل ADX فقط كوكيل في هذه الحالة، بحيث يمكن أن يكون نظام المجموعة صغير. بالإضافة إلى ذلك، يمكن إيقاف تشغيل نظام المجموعة عندما لا تحتاج إلى الوصول إلى البيانات وبدء تشغيلها فقط عند الحاجة إلى الوصول إلى البيانات.
كيفية الوصول إلى البيانات: مهام البحث استعلامات KQL المباشرة بيانات خارجية استعلامات KQL المعدّلة
السيناريو: الوصول العرضي

ذات صلة في السيناريوهات التي لا تحتاج فيها إلى تشغيل تحليلات ثقيلة أو تشغيل قواعد التحليلات، وتحتاج فقط إلى الوصول إلى البيانات أحياناً.
الوصول المتكرر

ذات صلة في السيناريوهات التي تحتاج فيها إلى الوصول إلى البيانات بشكلٍ متكرر، وتحتاج إلى التحكم في كيفية قياس حجم نظام المجموعة وتكوينها.
التوافق/التدقيق

• الأمثل لتخزين كميات هائلة من البيانات غير المنظمة.
• ذات صلة في السيناريوهات التي لا تحتاج فيها إلى الوصول السريع إلى البيانات أو الأداء العالي، مثل لأغراض التوافق أو التدقيق.
الوصول العرضي

ذات صلة في السيناريوهات حيث تريد الاستفادة من التكلفة المنخفضة لـ Azure Blob Storage، والحفاظ على وصول سريع نسبياً إلى البيانات.
التعقيد: منخفض جداً متوسط منخفض درجة عالية
الاستعداد: GA GA GA GA

اعتبارات عامة

الآن بعد أن عرفت المزيد عن الأنظمة الأساسية المستهدفة المتاحة، راجع هذه العوامل الرئيسية لاتخاذ قرارك النهائي.

استخدام السجلات التي تم استيعابها

حدد كيفية استخدام مؤسستك للسجلات التي تم استيعابها لتوجيه اختيارك لنظام الاستيعاب الأساسي.

ضع في اعتبارك هذه السيناريوهات العامة الثلاثة:

  • تحتاج مؤسستك إلى الاحتفاظ بالسجلات فقط لأغراض التوافق أو التدقيق. في هذه الحالة، نادراً ما تصل مؤسستك إلى البيانات. حتى إذا كانت مؤسستك تصل إلى البيانات، فإن الأداء العالي أو سهولة الاستخدام ليست أولوية.
  • تحتاج مؤسستك إلى الاحتفاظ بالسجلات حتى تتمكن فرقك من الوصول إلى السجلات بسهولة وبسرعة إلى حد ما.
  • تحتاج مؤسستك إلى الاحتفاظ بالسجلات حتى تتمكن فرقك من الوصول إلى السجلات بسهولة وبسرعة أحياناً. يعد الأداء وسهولة الاستخدام أمرين ثانويين.

راجع مقارنة النظام الأساسي لفهم النظام الأساسي الذي يناسب كل من هذه السيناريوهات.

سرعة الترحيل

في بعض السيناريوهات، قد تحتاج إلى الوفاء بموعد نهائي ضيق، على سبيل المثال، قد تحتاج مؤسستك إلى الانتقال بشكلٍ عاجل من SIEM السابق بسبب حدث انتهاء صلاحية الترخيص.

راجع المكونات والعوامل التي تحدد سرعة الترحيل.

‏‏مصدر البيانات

عادة ما يكون مصدر البيانات هو نظام ملفات محلي أو تخزين على السحابة، على سبيل المثال، S3. يعتمد أداء التخزين الخاص بالخادم على عوامل متعددة، مثل تقنية القرص (SSD مقابل HDD)، وطبيعة طلبات الإدخال/الإخراج، وحجم كل طلب.

على سبيل المثال، يتراوح أداء جهاز Azure الظاهري من 30 ميغابايت في الثانية على وحدات SKU أصغر للجهاز الظاهري، إلى 20 غيغابايت في الثانية لبعض وحدات SKU المحسّنة للتخزين باستخدام أقراص NVM Express (NVMe). تعرف على كيفية تصميم جهاز Azure الظاهري للحصول على أداء تخزين عالٍ. يمكنك أيضاً تطبيق معظم المفاهيم على الخوادم المحلية.

طاقة الحساب

في بعض الحالات، حتى إذا كان القرص الخاص بك قادراً على نسخ بياناتك بسرعة، فإن قوة الحساب هي الازدحام في عملية النسخ. في هذه الحالات، يمكنك اختيار أحد خيارات التحجيم هذه:

  • تغيير الحجم عمودياً. يمكنك زيادة قوة خادم واحد عن طريق إضافة المزيد من وحدات CPU، أو زيادة سرعة CPU.
  • تغيير الحجم أفقياً. يمكنك إضافة المزيد من الخوادم، ما يزيد من توازي عملية النسخ.

النظام الأساسي المستهدف

يحتوي كل نظام أساسي من الأنظمة الأساسية المستهدفة التي تمت مناقشتها في هذا القسم على ملف تعريف أداء مختلف.

  • سجلات Azure Monitor Basic. يمكن دفع السجلات الأساسية إلى Azure Monitor بمعدل 1 غيغابايت تقريباً في الدقيقة بشكلٍ افتراضي. يتيح لك هذا المعدل استيعاب ما يقرب من 1.5 تيرابايت يومياً أو 43 تيرابايت شهرياً.
  • Azure Data Explorer. يختلف أداء الاستيعاب، اعتماداً على حجم نظام المجموعة التي توفرها وإعدادات إرسال الدفعات التي تطبقها. تعرف على أفضل ممارسات الاستيعاب، بما في ذلك الأداء والمراقبة.
  • ⁩Azure Blob Storage⁧⁩. يمكن أن يختلف أداء حساب Azure Blob Storage بشكل كبير اعتماداً على عدد وحجم الملفات وحجم الوظيفة والتزامن وما إلى ذلك. تعرف على كيفية تحسين أداء AzCopy باستخدام Azure Storage.

كمية البيانات

كمية البيانات هي العامل الرئيسي الذي يؤثر على مدة عملية الترحيل. لذلك يجب أن تفكر في كيفية إعداد بيئتك اعتماداً على مجموعة بياناتك.

لتحديد الحد الأدنى لمدة الترحيل ومكان الازدحام، ضع في اعتبارك كمية البيانات وسرعة استيعاب النظام الأساسي المستهدف. على سبيل المثال، يمكنك تحديد نظام أساسي مستهدف يمكنه استيعاب 1 غيغابايت في الثانية، ويتعين عليك ترحيل 100 تيرابايت. في هذه الحالة، ستحتاج عملية الترحيل 100000 غيغابايت كحد أدنى، مضروباً في سرعة 1 غيغابايت في الثانية. اقسّم النتيجة على 3600، والتي تحسب إلى 27 ساعة. هذا الحساب صحيح إذا كان باستطاعة بقية المكونات في البنية الأساسية، مثل القرص المحلي والشبكة والأجهزة الظاهرية، تنفيذها بسرعة 1 غيغابايت في الثانية.

الخطوات التالية

في هذه المقالة، تعلمت كيفية تعيين قواعد الترحيل الخاصة بك من QRadar إلى Microsoft Sentinel.