تنبيه
تشير هذه المقالة إلى CentOS، وهو توزيع Linux هو نهاية العمر الافتراضي (EOL). يرجى مراعاة استخدامك والتخطيط وفقا لذلك. لمزيد من المعلومات، راجع إرشادات نهاية العمر الافتراضي CentOS.
يوضح هذا السيناريو مثال كيفية تشغيل Apache NiFi على Azure. NiFi توفر نظاماً لمعالجة البيانات وتوزيعها.
تعد Apache® وApache NiFi® وNiFi® إما علامات تجارية مسجلة أو علامات تجارية لمؤسسة Apache Software Foundation في الولايات المتحدة و/أو دول أخرى. لا توجد موافقة ضمنية من Apache Software Foundation باستخدام هذه العلامات.
بناء الأنظمة
قم بتنزيل ملف Visio لهذه البنية.
سير العمل
يشغل تطبيق NiFi على أجهزة VMs في عقدة نظام المجموعة NiFi. توجد VMs في مجموعة تغيير حجم الجهاز الظاهري يوزعها التكوين عبر مناطق التوفر.
يشغل Apache ZooKeeper على VMs في نظام مجموعة منفصلة. تستخدم NiFi نظام مجموعة ZooKeeper لهذه الأغراض:
- لاختيار عقدة منسق نظام مجموعة أجهزة
- لتنسيق تدفق البيانات
توفر بوابة تطبيق Azure موازنة تحميل الطبقة 7 لواجهة المستخدم التي تشغل على عُقد NiFi.
تقوم ميزة المراقبة وتحليلات السجل الخاصة بها بجمع وتحليل وعمل بيانات تتبع الاستخدام من نظام NiFi. يتضمن بيانات تتبع الاستخدام سجل النظام NiFi وقياسات صحة النظام وقياسات الأداء.
يقوم Azure Key Vault بتخزين الشهادات والمفاتيح بشكل آمن لمجموعة أجهزة NiFi.
يوفر معرف Microsoft Entra تسجيل الدخول الأحادي (SSO) والمصادقة متعددة العوامل.
المكونات
- NiFi توفر نظاماً لمعالجة البيانات وتوزيعها.
- ZooKeeper هو خادم مفتوح المصدر يدير الأنظمة الموزعة.
- الأجهزة الظاهرية هي أحد عروض البنية التحتية كخدمة (IaaS). يمكنك استخدام الأجهزة الظاهرية لتوزيع موارد الحوسبة القابلة للتطوير عند الطلب. توفر الأجهزة الظاهرية مرونة ظاهرية واجهة المستخدم ولكنها تلغي متطلبات الصيانة للأجهزة المادية.
- مجموعات Azure Virtual Machine Scale Sets توفر طريقة لإدارة مجموعة من VMs. ذات رصيد الحمل. يمكن أن يزيد عدد مثيلات VM في مجموعة أو ينقص تلقائياً استجابةً للطلب أو جدول محدد.
- مناطق التوفر هي مواقع مادية فريدة داخل منطقة Azure. تعمل هذه العروض عالية التوفر على حماية التطبيقات والبيانات من حالات فشل مراكز البيانات.
- بوابة Application عبارة عن موازن تحميل يدير نسبة استخدام الشبكة إلى تطبيقات الويب.
- المراقبة تجمع البيانات الموجودة في البيئات وموارد Azure وتحللها. تتضمن هذه البيانات بيانات تتبع الاستخدام للتطبيق، مثل مقاييس الأداء وسجلات النشاط. لمزيد من المعلومات، راجع اعتبارات المراقبة لاحقاً في هذه المقالة.
- Log Analytics هي أداة مدخل Microsoft Azure تقوم بتشغيل الاستعلامات على بيانات سجل المراقبة. يوفر تحليلات السجل أيضاً ميزات لرسم المخططات والتحليل الإحصائي لنتائج الاستعلام.
- Azure DevOps Services توفر الخدمات، والأدوات، والبيئات لإدارة مشاريع الترميز وعمليات التوزيع.
- Key Vault يخزن أسرار النظام ويتحكم في الوصول إلى البيانات السرية، مثل مفاتيح API، وكلمات المرور، والشهادات، ومفاتيح التشفير.
- معرف Microsoft Entra هو خدمة هوية مستندة إلى السحابة تتحكم في الوصول إلى Azure وتطبيقات السحابة الأخرى.
البدائل
- Azure Data Factory يوفر بديلاً لهذا الحل.
- بدلاً من Key Vault، يمكنك استخدام خدمة مماثلة لتخزين بيانات النظام السرية.
- Apache Airflow. لمزيد من المعلومات، راجع كيفية اختلاف Airflow وNFi.
- من الممكن استخدام بديل NiFi للمؤسسة مدعوم مثل Cloudera Apache NiFi. يتوفر عرض Cloudera من خلال Azure Marketplace.
تفاصيل السيناريو
في هذا السيناريو، يتم تشغيل NiFi في تكوين مجمع عبر أجهزة Azure الظاهرية في مجموعة تغيير الحجم. لكن معظم توصيات هذه المقالة تنطبق أيضاً على السيناريوهات التي تقوم بتشغيل NiFi في وضع المثيل الفردي على جهاز ظاهري واحد (VM). توضح أفضل الممارسات الواردة في هذه المقالة عملية توزيع آمنة وقابلة لتغيير الحجم وقابلية التوفر.
حالات الاستخدام المحتملة
تعمل NiFi بشكل جيد لنقل البيانات وإدارة تدفق البيانات:
- يعيّن الأنظمة المنفصلة في السحابة
- نقل البيانات من وإلى Azure Storage ومخازن البيانات الأخرى
- دمج تطبيقات السحابة من الحافة إلى السحابة والتطبيقات السحابية المختلطة مع Azure IoT وAzure Stack وAzure Kubernetes Service (AKS)
نتيجة لذلك، ينطبق هذا الحل على العديد من المساحات:
تجمع مستودعات البيانات الحديثة (MDWs) البنيات المنظمة وغير المهيكلة معاً على نطاق تغيير الحجم. يقومون بجمع وتخزين البيانات من مختلف المصادر، والمتلقيات، والأشكال. تتفوق NiFi في إدخال البيانات إلى MDWs في Azure للمتابعات التالية:
- يتوفر أكثر من 200 معالج لقراءة البيانات، وكتابتها، ومعالجته.
- يدعم النظام خدمات التخزين مثل Azure Blob Storage وAzure Data Lake Storage، ومراكز الأحداث، وAzure Queue Storage، وAzure Cosmos DB، وAzure Synapse Analytics.
- مصدر بيانات قوي لإصدار البيانات إمكانية تنفيذ الحلول المتوافقة. للحصول على معلومات بشأن نقطة ارتكاز مصدر البيانات في ميزة Log Analytics في Azure Monitor، راجع اعتبارات الإبلاغ وإعداد التقارير لاحقاً في هذه المقالة.
يمكن تشغيل NiFi على أساس مستقل على الأجهزة صغيرة الحجم. في مثل هذه الحالات، يتيح NiFi إمكانية معالجة بيانات الحافة ونقل تلك البيانات إلى مثيلات أو نظام المجموعة NiFi أكبر في السحابة. تساعد NiFi على تصفية بيانات الحافة وتحويلها وتحديد أولوياتها، ما يضمن تدفقات موثوقة وفعالة للبيانات.
تدير حلول IoT الصناعية (IIoT) تدفق البيانات من الحافة إلى مركز البيانات. يبدأ هذا التدفق بالحصول على البيانات من أنظمة وعناصر التحكم الصناعي. تنتقل البيانات بعد ذلك إلى حلول إدارة البيانات وMDWs. تقدم NiFi إمكانات تجعلها مناسبة تماماً لاكتساب البيانات وحركتها:
- وظيفة معالجة بيانات الحافة
- دعم البروتوكولات التي تستخدمها بوابات وأجهزة IoT
- التكامل مع مراكز الأحداث وخدمات التخزين
يمكن لتطبيقات IoT في مجالات الصيانة التنبُئية وإدارة سلسلة التوريد الاستفادة من هذه الوظيفة.
التوصيات
ضع النقاط التالية في الاعتبار عند استخدام هذا الحل:
الإصدارات الموصى بها من NiFi
عند تشغيل هذا الحل على Azure، نوصي باستخدام الإصدار 1.13.2+ من NiFi. يمكنك تشغيل إصدارات أخرى، ولكنها قد تتطلب تكوينات مختلفة عن تلك الموجودة في هذا الدليل.
لتركيب NiFi على Azure VMs، من الأفضل تنزيل الخانات الملائمة من صفحة تنزيلات NiFi. يمكنك أيضاً إنشاء الخانات من التعليمة البرمجية للمصدر.
الإصدارات الموصى بها من ZooKeeper
بالنسبة لمثال حمل العمل هذا، نوصي باستخدام الإصدارات 3.5.5 والإصدارات الأحدث أو 3.6.x من ZooKeeper.
يمكنك تركيب ZooKeeper على Azure VMs باستخدام خانات الراحة الرسمية أو التعليمة البرمجية المصدر. كلاهما متاح في صفحة الإصدارات Apache ZooKeeper.
الاعتبارات
تنفذ هذه الاعتبارات ركائز Azure Well-Architected Framework، وهو عبارة عن مجموعة من المبادئ التوجيهية التي يمكن استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.
للحصول على معلومات بشأن تكوين NiFi، راجع إرشاد مسؤول نظام Apache NiFi. ضع هذه الاعتبارات في الاعتبار أيضا عند تنفيذ هذا الحل.
تحسين التكلفة
يركز تحسين التكلفة على البحث عن طرق للحد من النفقات غير الضرورية وتحسين الكفاءة التشغيلية. لمزيد من المعلومات، راجع نظرة عامة على ركيزة تحسين التكلفة.
- استخدم حاسبة أسعار Azure لتقدير تكلفة الموارد في هذه البنية.
- للحصول على تقدير يتضمن جميع الخدمات في هذه البنية باستثناء حل التنبيه المخصص، راجع هذا نموذج ملف تعريف التكلفة.
اعتبارات VM
توفر الأقسام التالية مخططاً تفصيلياً لكيفية تكوين أجهزة NiFi VM:
حجم الجهاز الظاهري
يسرد هذا الجدول أحجام VM الموصى بها للبدء بها. بالنسبة لمعظم تدفقات البيانات ذات الأغراض العامة، فإن Standard_D16s_v3 هو الأفضل. لكن لكل تدفق بيانات في NiFi متطلبات مختلفة. اختبر التدفق الخاص بك وقم بتغيير الحجم حسب الحاجة بناءً على متطلبات التدفق الفعلية.
ضع في اعتبارك تمكين الشبكات المسرعة على الأجهزة الظاهرية لزيادة أداء الشبكة. لمزيد من المعلومات، راجع إنشاء شبكات لمجموعات تحجيم الجهاز الظاهري في Azure.
حجم الجهاز الظاهري | vCPU | الذاكرة في GB | الحد الأقصى لمعدل نقل البيانات غير المخزنة مؤقتاً في عمليات الإدخال / الإخراج في الثانية (IOPS) لكل MBps* | الحد الأقصى من واجهات الشبكة (بطاقات NIC) / النطاق الترددي المتوقع للشبكة (Mbps) |
---|---|---|---|---|
Standard_D8s_v3 | 8 | 32 | 12800/192 | 4/4,000 |
Standard_D16s_v3** | 16 | 64 | 25,600/384 | 8/8,000 |
Standard_D32s_v3 | 32 | 128 | 51,200/768 | 8/16,000 |
Standard_M16m | 16 | 437.5 | 10,000/250 | 8/4,000 |
* تعطيل التخزين المؤقت لكتابة قرص البيانات لجميع أقراص البيانات التي تستخدمها على عُقد NiFi.
** نوصي بـ SKU هذا لمعظم تدفقات البيانات ذات الأغراض العامة. يجب أن تكون وحدات التخزين Azure VM SKU ذات تكوينات وحدة المعالجة المركزية الظاهرية والذاكرة المماثلة كافية أيضاً.
نظام تشغيل VM (OS)
نوصي بتشغيل NiFi في Azure على أحد أنظمة تشغيل الضيف التالية:
- Ubuntu 18.04 LTS أو أحدث
- CentOS 7.9
للوفاء بالمتطلبات المحددة لتدفق البيانات الخاصة بك، من المهم ضبط العديد من إعدادات مستوى OS بما في ذلك:
- الحد الأقصى للعمليات المعالجة.
- مؤشرات الملفات القصوى.
- وقت الوصول،
atime
.
بعد ضبط OS ليناسب حالة الاستخدام المتوقعة، استخدم Azure VM Image Builder لتدوين إنشاء تلك الصور المضبوطة. للحصول على إرشادات خاصة بـ NiFi، راجع Configuration Best Practices في إرشاد مسؤول نظام Apache NiFi.
التخزين
قم بتخزين مستودعات NiFi المختلفة على أقراص البيانات وليس على قرص OS لثلاثة أسباب رئيسية:
- غالباً ما يكون للتدفقات متطلبات معدل النقل عالية للقرص لا يمكن لقرص واحد تلبيتها.
- من الأفضل فصل عمليات قرص NiFi عن عمليات قرص نظام التشغيل.
- لا ينبغي أن تكون المستودعات في التخزين المؤقت.
متابعة إرشادات مخطط تفصيلي الأقسام التالية لتكوين أقراص البيانات. هذه الإرشادات خاصة بـ Azure. لمزيد من المعلومات بشأن تكوين المستودعات، راجع State Management في إرشاد مسؤول نظام Apache NiFi.
نوع وحجم قرص البيانات
ضع في اعتبارك هذه العوامل عند تكوين أقراص البيانات لـ NiFi:
- نوع القرص
- حجم القرص
- عدد الملفات المنسوخة للأقراص
إشعار
للحصول على معلومات محدثة بشأن أنواع الأقراص والتحجيم والأسعار، راجع مقدمة بشأن الأقراص المدارة من Azure.
يعرض الجدول التالي أنواع الأقراص المُدارة المتوفرة حالياً في Azure. يمكنك استخدام NiFi مع أي من أنواع الأقراص هذه. ولكن بالنسبة لتدفقات البيانات عالية معدل النقل، نوصي باستخدام Premium SSD.
Ultra Disk Storage (NVM Express (NVMe)) | Premium SSD | Standard SSD | Standard HDD | |
---|---|---|---|---|
نوع القرص | SSD | SSD | SSD | HDD |
الحد الأقصى لحجم القرص | 65,536 جيجابايت | 32,767 جيجابايت | 32,767 جيجابايت | 32,767 جيجابايت |
الحد الأقصى لمعدل النقل | 2,000 ميبي بايت/ثانية | 900 ميبي بايت/ثانية | 750 ميبي بايت/ثانية | 500 ميبي بايت/ثانية |
الحد الأقصى ل IOPS | 160,000 | 20,000 | 6,000 | 2,000 |
استخدم ثلاثة أقراص بيانات على الأقل لزيادة سرعة معدل نقل البيانات. للحصول على أفضل الممارسات لتكوين المستودعات على الأقراص، راجع تكوين المستودع لاحقاً في هذه المقالة.
يسرد الجدول التالي الحجم المناسب وأرقام معدل النقل لكل حجم ونوع قرص.
Standard HDD S15 | Standard HDD S20 | Standard HDD S30 | Standard SSD S15 | Standard SSD S20 | Standard SSD S30 | Premium SSD P15 | Premium SSD P20 | Premium SSD P30 | |
---|---|---|---|---|---|---|---|---|---|
حجم القرص بـ GB | 256 | 512 | 1,024 | 256 | 512 | 1,024 | 256 | 512 | 1,024 |
IOPS لكل قرص | ما يصل إلى 500 | ما يصل إلى 500 | ما يصل إلى 500 | ما يصل إلى 500 | ما يصل إلى 500 | ما يصل إلى 500 | 1,100 | 2,300 | 5,000 |
معدل النقل لكل قرص | Up to 60 MBps | Up to 60 MBps | Up to 60 MBps | Up to 60 MBps | Up to 60 MBps | Up to 60 MBps | 125 MBps | 150 MBps | 200 ميغابت في الثانية |
إذا وصل النظام إلى حدود الجهاز الظاهري، فقد لا تؤدي إضافة المزيد من الأقراص إلى زيادة معدل النقل:
- تعتمد حدود IOPS ومعدل النقل على حجم القرص.
- يضع حجم الجهاز الظاهري الذي تختاره IOPS وحدود معدل النقل لـ VM على جميع أقراص البيانات.
لمعرفة حدود معدل نقل القرص على مستوى VM، راجع أحجام أجهزة Linux الظاهرية في Azure.
قرص VM التخزين المؤقت
في Azure VMs، تدير ميزة Host Caching التخزين المؤقت للكتابة على القرص. لزيادة سرعة معدل النقل أقراص البيانات التي تستخدمها للمستودعات، قم بإيقاف تشغيل التخزين المؤقت للكتابة على القرص عن طريق تعيين Host Caching على None
.
تكوين المستودع
تتمثل أفضل إرشادات الممارسات الخاصة بـ NiFi في استخدام قرص أو أقراص منفصلة لكل من هذه المستودعات:
- المحتوى
- FlowFile
- Provenance
يتطلب هذا النهج ما لا يقل عن ثلاثة أقراص.
تدعم NiFi أيضاً التخطيط على مستوى التطبيق. تعمل هذه الوظيفة على زيادة حجم أو أداء مستودعات البيانات.
القصاصة البرمجية التالية من nifi.properties
ملف التكوين. يقوم هذا التكوين بتقسيم المستودعات وتخطيطها عبر الأقراص المرفقة المتصلة بـ VMs:
nifi.provenance.repository.directory.stripe1=/mnt/disk1/ provenance_repository
nifi.provenance.repository.directory.stripe2=/mnt/disk2/ provenance_repository
nifi.provenance.repository.directory.stripe3=/mnt/disk3/ provenance_repository
nifi.content.repository.directory.stripe1=/mnt/disk4/ content_repository
nifi.content.repository.directory.stripe2=/mnt/disk5/ content_repository
nifi.content.repository.directory.stripe3=/mnt/disk6/ content_repository
nifi.flowfile.repository.directory=/mnt/disk7/ flowfile_repository
لمزيد من المعلومات بشأن التصميم لتخزين عالي الأداء، راجع تخزين Azure المتميز: التصميم لأداء عالٍ.
إعداد التقرير
تتضمن NiFi مهمة إعداد تقارير عن المصدر لميزة Log Analytics.
يمكنك استخدام مهمة إعداد التقارير هذه لإلغاء تحميل أحداث المصدر إلى تخزين طويل الأمد وفعال من حيث التكلفة. توفر ميزة Log Analytics واجهة استعلام لعرض الأحداث الفردية ورسمها البياني. لمزيد من المعلومات بشأن طلبات البحث هذه، راجع استعلامات Log Analytics لاحقاً في هذه المقالة.
يمكنك أيضاً استخدام هذه المهمة مع مساحة تخزين ذات ذاكرة مضمنة متطايرة (مؤقتة). في العديد من السيناريوهات، يمكنك بعد ذلك تحقيق زيادة في معدل النقل. لكن هذا النهج محفوف بالمخاطر إذا كنت بحاجة إلى الحفاظ على بيانات الحدث. تأكد من أن التخزين المتطاير يلبي متطلبات المتانة لأحداث المصدر. لمزيد من المعلومات، راجع Provenance Repository في إرشاد مسؤول نظام Apache NiFi.
قبل استخدام هذه العملية، قم بإنشاء مساحة عمل Log Analytics في اشتراك Azure الخاص بك. من الأفضل إعداد مساحة العمل في نفس منطقة حجم العمل لديك.
لتكوين مهمة الإبلاغ عن المصدر:
- افتح إعدادات وحدة التحكم في NiFi.
- حدد قائمة مهام إعداد التقارير.
- حدد Create a new reporting task.
- حدد Azure Log Analytics Reporting Task.
تُظهر لقطة الشاشة التالية قائمة الخصائص لمهمة إعداد التقارير هذه:
مطلوب خاصيتين:
- معرف مساحة عمل Log Analytics
- مفتاح مساحة عمل Log Analytics
يمكنك العثور على هذه القيم في مدخل Microsoft Azure بالانتقال إلى مساحة عمل Log Analytics.
تتوفر أيضاً خيارات أخرى لتخصيص أحداث المصدر التي يرسلها النظام وتصفيتها.
الأمان
ويوفر عامل الأمان ضمانات للحماية من الهجمات المتعمدة واستغلال البيانات والأنظمة القيمة الخاصة بك. للمزيد من المعلومات، يرجى الرجوع إلى نظرة عامة على ركيزة الأمان.
يمكنك تأمين NiFi من وجهة نظر المصادقة والتخويل. يمكنك أيضاً تأمين NiFi لجميع اتصالات الشبكة بما في ذلك:
- داخل نظام مجموعة أجهزة.
- بين نظام مجموعة الأجهزة وZooKeeper.
راجع دليل مسؤولي Apache NiFi للحصول على إرشادات بشأن تشغيل الخيارات التالية:
- Kerberos
- بروتوكول الوصول الخفيف إلى الدليل (LDAP)
- المصادقة على أساس الشهادة والتحويل
- طبقة مآخذ توصيل آمنة ثنائية الاتجاه (SSL) نظام مجموعة الاتصالات
إذا قمت بتشغيل الوصول الآمن للعميل ZooKeeper، فقم بتكوين NiFi عن طريق إضافة الخصائص ذات الصلة إلى ملف التكوين bootstrap.conf
الخاص به. توفر إدخالات التكوين التالية مثالاً:
java.arg.18=-Dzookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
java.arg.19=-Dzookeeper.client.secure=true
java.arg.20=-Dzookeeper.ssl.keyStore.location=/path/to/keystore.jks
java.arg.21=-Dzookeeper.ssl.keyStore.password=[KEYSTORE PASSWORD]
java.arg.22=-Dzookeeper.ssl.trustStore.location=/path/to/truststore.jks
java.arg.23=-Dzookeeper.ssl.trustStore.password=[TRUSTSTORE PASSWORD]
للحصول على توصيات عامة، راجع أساس أمان Linux.
أمن الشبكة
عند تنفيذ هذا الحل، ضع في اعتبارك النقاط التالية بشأن أمان الشبكة:
مجموعات أمان الشبكة
في Azure، يمكنك استخدام مجموعات أمان الشبكة لتقييد نسبة استخدام الشبكة.
نوصي باستخدام Jumpbox للاتصال بنظام مجموعة NiFi لأداء المهام الإدارية. استخدم VM المشدد من حيث الأمان مع الوصول في نفس الوقت (JIT) أو Azure Bastion. قم بإعداد مجموعات أمان الشبكة للتحكم في كيفية منحك الوصول إلى Jumpbox أو Azure Bastion. يمكنك تحقيق عزل الشبكة وعنصر التحكم فيها باستخدام مجموعات أمان الشبكة بحكمة على الشبكات الفرعية المختلفة للبنية.
تُظهر لقطة الشاشة التالية المكونات الموجودة في شبكة ظاهرية نموذجية. يحتوي على شبكة فرعية مشتركة لـ Jumpbox، ومجموعة تغيير سعة جهاز ظاهري وZooKeeper VMs. يعمل تخطيط الشبكة المبسط هذا على تجميع المكونات في شبكة فرعية واحدة. اتبع إرشادات مؤسستك لفصل المهام وتصميم الشبكة.
النظر في الوصول إلى الإنترنت الصادرة
لا يحتاج NiFi في Azure إلى الوصول إلى الإنترنت العام لتشغيله. إذا لم يكن تدفق البيانات بحاجة إلى الوصول إلى الإنترنت لاسترداد البيانات، فقم بتحسين أمان النظام للمجموعة باتباع هذه الخطوات لتعطيل الوصول إلى الإنترنت الصادر:
قم بإنشاء قاعدة مجموعة أمان إضافية للشبكة في الشبكة الظاهرية.
استخدم الإعدادات التالية:
- المصدر:
Any
- الوجهة:
Internet
- الإجراء:
Deny
- المصدر:
مع تطبيق هذه القاعدة، لا يزال بإمكانك الوصول إلى بعض خدمات Azure من تدفق البيانات إذا قمت بتكوين نقطة نهاية خاصة في الشبكة الظاهرية. استخدم Azure Private Link لهذا الغرض. توفر هذه الخدمة وسيلة لنقل نسبة استخدام الشبكة الخاصة بك على شبكة Microsoft الأساسية بينما لا تتطلب أي وصول آخر للشبكة الخارجية. تدعم NiFi حالياً الارتباط الخاص لمعالجات Blob Storage وتخزين مستودع البيانات. إذا لم يكن خادم بروتوكول وقت الشبكة (NTP) متوفرا في شبكتك الخاصة، فاسمح بالوصول الصادر إلى NTP. للحصول على معلومات تفصيلية، راجع مزامنة الوقت لأجهزة Linux VMs في Azure.
حماية البيانات
من الممكن تشغيل NiFi دون تأمين، دون تشفير سلكي، وإدارة الهوية والوصول (IAM)، أو تشفير البيانات. ولكن من الأفضل تأمين الإنتاج وعمليات التوزيع على السحابة العامة بهذه الطرق:
- تشفير الاتصال بأمان طبقة النقل (TLS)
- استخدام آلية مصادقة وتحويل مدعومة
- تشفير بيانات ثابتة
يوفر Azure Storage تشفيراً شفافاً للبيانات من جانب الخادم. ولكن بدءاً من الإصدار 1.13.2، لا يقوم NiFi بتكوين تشفير الأسلاك أو IAM افتراضياً. قد يتغير هذا السلوك في الإصدارات المستقبلية.
توضح الأقسام التالية كيفية تأمين عمليات التوزيع بهذه الطرق:
- تفعيل تشفير الأسلاك باستخدام TLS
- تكوين المصادقة المستندة إلى الشهادات أو معرف Microsoft Entra
- إدارة التخزين المشفر على Azure
تشفير القرص
لتحسين الأمان، استخدم تشفير قرص Azure. للحصول على إجراء تفصيلي، راجع تشفير OS وأقراص البيانات المرفقة في تغيير حجم جهاز ظاهري تم تعيينه باستخدام Azure CLI. يحتوي هذا المستند أيضاً على إرشادات بشأن توفير مفتاح التشفير الخاص بك. توضح الخطوات التالية مثالاً أساسياً لـ NiFi يعمل مع معظم عمليات التوزيع:
لتشغيل تشفير القرص في مثيل Key Vault موجود، استخدم الأمر التالي Azure CLI:
az keyvault create --resource-group myResourceGroup --name myKeyVaultName --enabled-for-disk-encryption
قم بتشغيل تشفير أقراص بيانات مجموعة تغيير حجم الجهاز الظاهري باستخدام الأمر التالي:
az vmss encryption enable --resource-group myResourceGroup --name myScaleSet --disk-encryption-keyvault myKeyVaultID --volume-type DATA
يمكنك اختياريا استخدام مفتاح تشفير مفتاح (KEK). استخدم الأمر التالي Azure CLI للتشفير باستخدام KEK:
az vmss encryption enable --resource-group myResourceGroup --name myScaleSet \ --disk-encryption-keyvault myKeyVaultID \ --key-encryption-keyvault myKeyVaultID \ --key-encryption-key https://<mykeyvaultname>.vault.azure.net/keys/myKey/<version> \ --volume-type DATA
إشعار
إذا قمت بتكوين تغيير حجم الجهاز الظاهري الخاص بك على وضع التحديث اليدوي، فقم بتشغيل الأمر update-instances
. قم بتضمين إصدار مفتاح التشفير الذي قمت بتخزينه في Key Vault.
التشفير أثناء النقل
يدعم NiFi TLS 1.2 للتشفير أثناء النقل. يوفر هذا البروتوكول الحماية لوصول المستخدم إلى واجهة UI. مع مقاطع تخزينية، يحمي البروتوكول الاتصال بين عُقد NiFi. يمكنه أيضاً حماية التواصل مع ZooKeeper. عند تمكين TLS، تستخدم NiFi بروتوكول TLS المتبادل (mTLS) للمصادقة المتبادلة من أجل:
- مصادقة العميل المستندة إلى الشهادة إذا قمت بتكوين هذا النوع من المصادقة.
- جميع الاتصالات داخل المجموعات.
لتمكين TLS، اتبع الخطوات التالية:
إنشاء مخزن مفاتيح ومخزن ثقة لاتصالات ومصادقة العميل والخادم وداخل المجموعة.
تكوين
$NIFI_HOME/conf/nifi.properties
. قم بتعيين القيم التالية:- اسم المضيف
- منافذ
- خصائص مخزن المفاتيح
- خصائص مخزن الثقة
- خصائص أمان نظام المجموعة وZooKeeper، إن أمكن
يكوّن المصادقة في
$NIFI_HOME/conf/authorizers.xml
، عادةً مع مستخدم أولي لديه مصادقة قائمة على شهادة أو خيار آخر.قم بتكوين mTLS ونهج قراءة الوكيل اختيارياً بين NiFi وأي خوادم وكيلة أو موازنات تحميل أو نقاط نهاية خارجية.
للحصول على إرشادات كاملة، راجع تأمين NiFi باستخدام TLS في وثائق مشروع Apache.
إشعار
اعتباراً من الإصدار 1.13.2:
- لا يقوم NiFi بتمكين TLS افتراضياً.
- لا يوجد دعم خارجي لوصول مجهول ومستخدم فردي لمثيلات NiFi التي تُمكن TLS.
لتمكين TLS للتشفير أثناء النقل، هيئ مجموعة مستخدمين وموفر نهج للمصادقة والتحويل في $NIFI_HOME/conf/authorizers.xml
. لمزيد من المعلومات، راجع التحكم في الهوية والوصول لاحقاً في هذه المقالة.
الشهادات والمفاتيح ومخازن المفاتيح
لدعم TLS، قم بإنشاء الشهادات، وتخزينها في Java KeyStore وTrustStore، وتوزيعها عبر مجموعة أجهزة NiFi. هناك خياران عامان للشهادات:
- الشهادات الموقعة ذاتيًا
- الشهادات التي توقعها المراجع المصدقة
باستخدام الشهادات الموقعة من قِبل المرجع المصدق، من الأفضل استخدام مرجع مصدق وسيط لإنشاء شهادات للعقد في نظام المجموعة.
KeyStore وTrustStore هما حاويات المفاتيح والشهادات في نظام Java الأساسي. KeyStore يخزن المفتاح الخاص وشهادة العقدة في نظام المجموعة. يقوم TrustStore بتخزين أحد أنواع الشهادات التالية:
- جميع الشهادات الموثوقة، للشهادات الموقعة ذاتياً في KeyStore
- شهادة من CA، للشهادات الموقعة من CA في KeyStore
ضع في اعتبارك قابلية التوسع في نظام مجموعة NiFi عند اختيار حاوية. على سبيل المثال، قد ترغب في زيادة أو تقليل عدد العقد في نظام المجموعة في المستقبل. اختر الشهادات الموقعة من CA في KeyStore وشهادة واحدة أو أكثر من CA في TrustStore في هذه الحالة. باستخدام هذا الخيار، ليست هناك حاجة لتحديث TrustStore الموجودة في العقد الحالية لنظام مجموعة. يثق TrustStore الموجود ويقبل الشهادات من هذه الأنواع من العقد:
- العقد التي تضيفها إلى نظام مجموعة
- العقد التي تحل محل العقد الأخرى في نظام مجموعة
تكوين NiFi
لتمكين TLS لـ NiFi، استخدم $NIFI_HOME/conf/nifi.properties
لتكوين الخصائص في هذا الجدول. تأكد من أن الخصائص التالية تتضمن اسم المضيف الذي تستخدمه للوصول إلى NiFi:
nifi.web.https.host
أوnifi.web.proxy.host
- الاسم المعين لشهادة المضيف أو الأسماء البديلة للموضوع
وإلا، فقد يؤدي فشل التحقق من اسم المضيف أو فشل التحقق من عنوان HTTP HOST إلى رفض الوصول.
اسم الخاصية | الوصف | قيم الأمثلة |
---|---|---|
nifi.web.https.host |
اسم المضيف أو عنوان IP المراد استخدامه لـ UL وREST API. يجب أن تكون هذه القيمة قابلة للحل داخلياً. نوصي بعدم استخدام اسم متاح للجميع. | nifi.internal.cloudapp.net |
nifi.web.https.port |
منفذ HTTPS لاستخدامه في لـ UL وREST API. | 9443 (افتراضي) |
nifi.web.proxy.host |
قائمة مفصولة بفواصل لأسماء المضيفين البديلة التي يستخدمها العملاء للوصول إلى UI وREST API. تتضمن هذه القائمة عادةً أي اسم مضيف يتم تحديده كاسم بديل للموضوع (SAN) في شهادة الخادم. يمكن أن تشتمل القائمة أيضاً على أي اسم مضيف ومنفذ يستخدمه موازن التحميل أو الوكيل أو وحدة تحكم إدخال Kubernetes. | 40.67.218.235, 40.67.218.235:443, nifi.westus2.cloudapp.com, nifi.westus2.cloudapp.com:443 |
nifi.security.keystore |
المسار إلى ملف تخزين المفاتيح JKS أو PKCS12 الذي يحتوي على المفتاح الخاص للشهادة. | ./conf/keystore.jks |
nifi.security.keystoreType |
نوع مخزن المفاتيح. | JKS أو PKCS12 |
nifi.security.keystorePasswd |
كلمة مرور مخزن المفاتيح. | O8SitLBYpCz7g/RpsqH+zM |
nifi.security.keyPasswd |
(اختياري) كلمة المرور للمفتاح الخاص. | |
nifi.security.truststore |
المسار إلى مخزن الثقة JKS أو PKCS12 الذي يحتوي على شهادات أو شهادات CA التي تصادق المستخدمين الموثوق بهم وعقد نظام المجموعة. | ./conf/truststore.jks |
nifi.security.truststoreType |
نوع مخزن الثقة. | JKS أو PKCS12 |
nifi.security.truststorePasswd |
كلمة مرور مخزن الثقة. | RJlpGe6/TuN5fG+VnaEPi8 |
nifi.cluster.protocol.is.secure |
حالة TLS للاتصال داخل العنقود. إذا كانت nifi.cluster.is.node هي true ، فاضبط هذه القيمة على true لتمكين TLS لنظام المجموعة. |
true |
nifi.remote.input.secure |
حالة TLS للاتصال من موقع إلى موقع. | true |
يوضح المثال التالي كيف تظهر هذه الخصائص في $NIFI_HOME/conf/nifi.properties
. لاحظ أن قيم nifi.web.http.host
وnifi.web.http.port
فارغة.
nifi.remote.input.secure=true
nifi.web.http.host=
nifi.web.http.port=
nifi.web.https.host=nifi.internal.cloudapp.net
nifi.web.https.port=9443
nifi.web.proxy.host=40.67.218.235, 40.67.218.235:443, nifi.westus2.cloudapp.com, nifi.westus2.cloudapp.com:443
nifi.security.keystore=./conf/keystore.jks
nifi.security.keystoreType=JKS
nifi.security.keystorePasswd=O8SitLBYpCz7g/RpsqH+zM
nifi.security.keyPasswd=
nifi.security.truststore=./conf/truststore.jks
nifi.security.truststoreType=JKS
nifi.security.truststorePasswd=RJlpGe6/TuN5fG+VnaEPi8
nifi.cluster.protocol.is.secure=true
تكوين ZooKeeper
للحصول على إرشادات بشأن تمكين TLS في Apache ZooKeeper لاتصالات الحصة ووصول العميل، راجع إرشاد مسؤول ZooKeeper. تدعم الإصدارات 3.5.5 أو الأحدث هذه الوظيفة فقط.
تستخدم NiFi ZooKeeper للتجميع الصفري وتنسيق نظام مجموعة. بدءاً من الإصدار 1.13.0، تدعم NiFi وصول العميل الآمن إلى مثيلات ZooKeeper التي تدعم TLS. يخزن ZooKeeper عضوية نظام المجموعة وحالة المعالج ذو النطاق العنقودي في نص عادي. لذلك من المهم استخدام وصول العميل الآمن إلى ZooKeeper لمصادقة طلبات عميل ZooKeeper. قم أيضاً بتشفير القيم الحساسة أثناء النقل.
لتمكين TLS لوصول عميل NiFi إلى ZooKeeper، قم بتعيين الخصائص التالية في $NIFI_HOME/conf/nifi.properties
. إذا قمت بتعيين nifi.zookeeper.client.secure
true
دون تكوين الخصائص nifi.zookeeper.security
، فإن NiFi يعود إلى مخزن المفاتيح ومخزن الثقة الذي تحدده في nifi.securityproperties
.
اسم الخاصية | الوصف | قيم الأمثلة |
---|---|---|
nifi.zookeeper.client.secure |
حالة TLS للعميل عند الاتصال بـ ZooKeeper. | true |
nifi.zookeeper.security.keystore |
المسار إلى مخزن مفاتيح JKS أو PKCS12 أو PEM الذي يحتوي على المفتاح الخاص للشهادة المقدمة إلى ZooKeeper للمصادقة. | ./conf/zookeeper.keystore.jks |
nifi.zookeeper.security.keystoreType |
نوع مخزن المفاتيح. | JKS ، أو PKCS12 ، أو PEM ، أو الكشف التلقائي عن طريق الملحق |
nifi.zookeeper.security.keystorePasswd |
كلمة مرور مخزن المفاتيح. | caB6ECKi03R/co+N+64lrz |
nifi.zookeeper.security.keyPasswd |
(اختياري) كلمة المرور للمفتاح الخاص. | |
nifi.zookeeper.security.truststore |
المسار إلى مخزن الثقة JKS أو PKCS12 أو PEM الذي يحتوي على شهادات أو شهادات CA المستخدمة لمصادقة ZooKeeper. | ./conf/zookeeper.truststore.jks |
nifi.zookeeper.security.truststoreType |
نوع مخزن الثقة. | JKS ، أو PKCS12 ، أو PEM ، أو الكشف التلقائي عن طريق الملحق |
nifi.zookeeper.security.truststorePasswd |
كلمة مرور مخزن الثقة. | qBdnLhsp+mKvV7wab/L4sv |
nifi.zookeeper.connect.string |
سلسلة الاتصال بمضيف ZooKeeper أو الحصة. هذه السلسلة عبارة عن قائمة من قيم host:port مفصولة بفواصل. عادةً ما تختلف قيمة secureClientPort عن قيمة clientPort . راجع تكوين ZooKeeper الخاص بك لمعرفة القيمة الصحيحة. |
zookeeper1.internal.cloudapp.net:2281, zookeeper2.internal.cloudapp.net:2281, zookeeper3.internal.cloudapp.net:2281 |
يوضح المثال التالي كيف تظهر هذه الخصائص في $NIFI_HOME/conf/nifi.properties
:
nifi.zookeeper.client.secure=true
nifi.zookeeper.security.keystore=./conf/keystore.jks
nifi.zookeeper.security.keystoreType=JKS
nifi.zookeeper.security.keystorePasswd=caB6ECKi03R/co+N+64lrz
nifi.zookeeper.security.keyPasswd=
nifi.zookeeper.security.truststore=./conf/truststore.jks
nifi.zookeeper.security.truststoreType=JKS
nifi.zookeeper.security.truststorePasswd=qBdnLhsp+mKvV7wab/L4sv
nifi.zookeeper.connect.string=zookeeper1.internal.cloudapp.net:2281,zookeeper2.internal.cloudapp.net:2281,zookeeper3.internal.cloudapp.net:2281
لمزيد من المعلومات بشأن تأمين ZooKeeper باستخدام TLS، راجع دليل إدارة Apache NiFi.
الهوية وعناصر التحكم في الوصول
في NiFi، تتحقق الهوية والتحكم في الوصول من خلال مصادقة المستخدم والتحويل. لمصادقة المستخدم، لدى NiFi خيارات متعددة للاختيار من بينها: مستخدم واحد، LDAP، Kerberos، Security Assertion Markup Language (SAML)، وOpenID Connect (OIDC). إذا لم تقم بتكوين أحد الخيارات، فإن NiFi تستخدم شهادات العميل لمصادقة المستخدمين عبر HTTPS.
إذا كنت تفكر في المصادقة متعددة العوامل، نوصي بمزيج من معرف Microsoft Entra وOIDC. يدعم Microsoft Entra ID تسجيل الدخول الأحادي (SSO) الأصلي على السحابة باستخدام OIDC. باستخدام هذه المجموعة، يمكن للمستخدمين الاستفادة من العديد من ميزات أمان المؤسسة:
- التسجيل والتنبيه بشأن الأنشطة المشبوهة من حسابات المستخدمين
- مراقبة محاولات الوصول إلى معلومات تسجيل الدخول المعطلة
- تنبيه بشأن سلوك غير معتاد لتسجيل الدخول إلى الحساب
للتخويل، توفر NiFi تطبيقاً يعتمد على نُهج المستخدم والمجموعة والوصول. توفر NiFi هذا الإنفاذ من خلال UserGroupProviders وAccessPolicyProviders. بشكل افتراضي، يتضمن الموفرون UserGroupProviders المستندة إلى File وLDAP وShell وAzure Graph. باستخدام AzureGraphUserGroupProvider، يمكنك مصدر مجموعات المستخدمين من معرف Microsoft Entra. يمكنك بعد ذلك تعيين نُهج لهذه المجموعات. للحصول على إرشادات التكوين، راجع إرشاد إدارة Apache NiFi.
AccessPolicyProviders التي تستند إلى الملفات وApache Ranger متاحة حالياً لإدارة وتخزين نُهج المستخدم والمجموعات. للحصول على معلومات مفصلة، راجع وثائق Apache NiFi ووثائق Apache Ranger.
بوابة التطبيق
توفر بوابة التطبيق موازنة تحميل مُدار من الطبقة 7 لواجهة NiFi. قم بتكوين بوابة التطبيق لاستخدام مجموعة تغيير حجم الجهاز الظاهري لعقد NiFi كمجموعة خلفية لها.
بالنسبة لمعظم عمليات تثبيت NiFi، نوصي بتكوين بوابة Application التالية:
- المستوى: قياسي
- حجم SKU: متوسط
- عدد المثيلات: اثنان أو أكثر
استخدم اختبار الحالة لمراقبة سلامة خادم الويب على كل عقدة. قم بإزالة العقد غير الصحية من دوران موازن التحميل. هذا النهج يجعل من السهل عرض واجهة المستخدم عندما تكون نظام المجموعة أجهزة الكلية غير صحية. يوجهك المستعرض فقط إلى العقد السليمة حالياً والتي تستجيب للطلبات.
هناك نوعان من التحقيقات الصحية الرئيسية للنظر فيها. يوفران معاً نبضات قلب منتظمة على الحالة العامة لكل عقدة في نظام المجموعة. قم بتكوين مسبار الحالة الأول للإشارة إلى المسار /NiFi
. يحدد هذا المسبار صحة واجهة مستخدم NiFi على كل عقدة. قم بتكوين اختبار صحة ثانٍ للمسار /nifi-api/controller/cluster
. يشير هذا التحقيق إلى ما إذا كانت كل عقدة في الوقت الحالي سليمة ومتصلة بنظام المجموعة.
لديك خياران لتكوين عنوان IP الأمامي لبوابة التطبيق:
- مع عنوان IP عام
- مع عنوان IP للشبكة الفرعية الخاصة
قم بتضمين عنوان IP عام فقط إذا احتاج المستخدمون إلى الوصول إلى UI عبر الإنترنت العام. إذا لم يكن الوصول العام إلى الإنترنت للمستخدمين مطلوباً، فقم بالوصول إلى الواجهة الأمامية لموازنة التحميل من صندوق القفز في الشبكة الظاهرية أو من خلال النظر إلى شبكتك الخاصة. إذا قمت بتكوين بوابة التطبيق بعنوان IP عام، فإننا نوصي بتمكين مصادقة شهادة العميل لـ NiFi وتمكين TLS لواجهة مستخدم NiFi. يمكنك أيضاً استخدام مجموعة أمان الشبكة في الشبكة الفرعية لبوابة التطبيق المفوَّض لتقييد عناوين IP للمصدر.
التشخيص والمراقبة الصحية
ضمن إعدادات التشخيص الخاصة لبوابة Application، يوجد خيار تكوين لإرسال القياسات وسجلات الوصول. باستخدام هذا الخيار، يمكنك إرسال هذه المعلومات من موازن التحميل إلى أماكن مختلفة:
- A حساب تخزين
- مراكز الأحداث
- مساحة عمل Log Analytics
يعد تشغيل هذا الإعداد مفيداً لتصحيح مشكلة موازنة التحميل والحصول على نتيجة تحليلات بشأن صحة عقد نظام المجموعة.
يعرض طلب البحث التالي Log Analytics سلامة عقدة نظام المجموعة بمرور الوقت من منظور بوابة التطبيق. يمكنك استخدام استعلام مشابه لإنشاء تنبيهات أو إجراءات إصلاح آلية للعقد غير الصحية.
AzureDiagnostics
| summarize UnHealthyNodes = max(unHealthyHostCount_d), HealthyNodes = max(healthyHostCount_d) by bin(TimeGenerated, 5m)
| render timechart
يُظهر الرسم البياني التالي لنتائج الاستعلام عرضاً زمنياً لسلامة نظام المجموعة:
التوافر
عند تنفيذ هذا الحل، ضع في اعتبارك النقاط التالية بشأن التوفر:
موازن التحميل
استخدم موازن التحميل لـ UI لزيادة توفر UI وقت تعطل العقدة.
VMs منفصلة
لزيادة التوفر، قم بتوزيع مجموعة ZooKeeper على أجهزة ظاهرية منفصلة عن VMs في نظام مجموعة NiFi. لمزيد من المعلومات بشأن تكوين ZooKeeper، راجع إدارة الحالة في إرشاد مسؤول نظام Apache NiFi.
مجموعات التوافر
قم بتوزيع كلاً من نظام مجموعة تغيير حجم الجهاز الظاهري NiFi ومجموعة أجهزة ZooKeeper في تكوين عبر المنطقة لزيادة الإتاحة إلى أقصى حد. عندما يتخطى الاتصال بين العقد في نظام المجموعة في مناطق التوفر، فإنه يقدم مقداراً صغيراً من زمن الانتقال. لكن زمن الانتقال هذا عادةً ما يكون له تأثير إجمالي ضئيل على معدل النقل في نظام المجموعة.
مجموعات توسيع الجهاز الافتراضي
نوصي بتوزيع عُقد NiFi في مجموعة تغيير حجم جهاز ظاهري واحد تمتد عبر مناطق التوفر حيثما كان ذلك متاحاً. للحصول على معلومات مفصلة بشأن استخدام مجموعات تغيير الحجم بهذه الطريقة، راجع إنشاء مجموعة تغيير حجم جهاز ظاهري تستخدم مناطق توافر الخدمات.
مراقبة
لمراقبة صحة وأداء نظام مجموعة NiFi، استخدم مهام إعداد التقارير.
الإبلاغ عن المراقبة القائمة على المهام
للمراقبة، يمكنك استخدام مهمة إعداد التقارير التي تقوم بتكوينها وتشغيلها في NiFi. كما يناقش التشخيص ومراقبة الحالة، يوفر Log Analytics مهمة إعداد التقارير في حزمة NiFi Azure. يمكنك استخدام مهمة إعداد التقارير هذه لدمج المراقبة مع Log Analytics وأنظمة المراقبة أو التسجيل الحالية.
استفسارات Log Analytics
يمكن أن تساعدك نماذج الاستعلامات في الأقسام التالية على البدء. للحصول على نظرة عامة بشأن كيفية الاستعلام عن بيانات Log Analytics، راجع استعلامات سجل Azure Monitor.
تستخدم استعلامات السجل في Monitor وLog Analytics إصدارا من Kusto Query Language. ولكن توجد اختلافات بين استعلامات السجل واستعلامات Kusto. لمزيد من المعلومات، راجع نظرة عامة على استعلام Kusto.
لمزيد من التعلم المنظم، راجع هذه الدروس:
مهمة تقارير Log Analytics
بشكل افتراضي، ترسل NiFi بيانات القياسات إلى الجدول nifimetrics
. ولكن يمكنك تكوين وجهة مختلفة في خصائص مهمة إعداد التقارير. تلتقط مهمة إعداد التقارير قياسات NiFi التالية:
نوع المقياس | اسم قياسي |
---|---|
قياسات NiFi | FlowFilesReceived |
قياسات NiFi | FlowFilesSent |
قياسات NiFi | FlowFilesQueued |
قياسات NiFi | BytesReceived |
قياسات NiFi | BytesWritten |
قياسات NiFi | BytesRead |
قياسات NiFi | BytesSent |
قياسات NiFi | BytesQueued |
قياسات حالة المنفذ | InputCount |
قياسات حالة المنفذ | InputBytes |
قياسات حالة الاتصال | QueuedCount |
قياسات حالة الاتصال | QueuedBytes |
قياسات حالة المنفذ | OutputCount |
قياسات حالة المنفذ | OutputBytes |
مقاييس الجهاز الظاهري Java (JVM) | jvm.uptime |
قياسات JVM | jvm.heap_used |
قياسات JVM | jvm.heap_usage |
قياسات JVM | jvm.non_heap_usage |
قياسات JVM | jvm.thread_states.runnable |
قياسات JVM | jvm.thread_states.blocked |
قياسات JVM | jvm.thread_states.timed_waiting |
قياسات JVM | jvm.thread_states.terminated |
قياسات JVM | jvm.thread_count |
قياسات JVM | jvm.daemon_thread_count |
قياسات JVM | jvm.file_descriptor_usage |
قياسات JVM | jvm.gc.runs jvm.gc.runs.g1_old_generation jvm.gc.runs.g1_young_generation |
قياسات JVM | jvm.gc.time jvm.gc.time.g1_young_generation jvm.gc.time.g1_old_generation |
قياسات JVM | jvm.buff_pool_direct_capacity |
قياسات JVM | jvm.buff_pool_direct_count |
قياسات JVM | jvm.buff_pool_direct_mem_used |
قياسات JVM | jvm.buff_pool_mapped_capacity |
قياسات JVM | jvm.buff_pool_mapped_count |
قياسات JVM | jvm.buff_pool_mapped_mem_used |
قياسات JVM | jvm.mem_pool_code_cache |
قياسات JVM | jvm.mem_pool_compressed_class_space |
قياسات JVM | jvm.mem_pool_g1_eden_space |
قياسات JVM | jvm.mem_pool_g1_old_gen |
قياسات JVM | jvm.mem_pool_g1_survivor_space |
قياسات JVM | jvm.mem_pool_metaspace |
قياسات JVM | jvm.thread_states.new |
قياسات JVM | jvm.thread_states.waiting |
قياسات مستوى المعالج | BytesRead |
قياسات مستوى المعالج | BytesWritten |
قياسات مستوى المعالج | FlowFilesReceived |
قياسات مستوى المعالج | FlowFilesSent |
فيما يلي نموذج استعلام BytesQueued
لمقياس نظام المجموعة:
let table_name = nifimetrics_CL;
let metric = "BytesQueued";
table_name
| where Name_s == metric
| where Computer contains {ComputerName}
| project TimeGenerated, Computer, ProcessGroupName_s, Count_d, Name_s
| summarize sum(Count_d) by bin(TimeGenerated, 1m), Computer, Name_s
| render timechart
ينتج عن هذا الاستعلام مخطط مثل المخطط الموجود في لقطة الشاشة هذه:
إشعار
عندما تقوم بتشغيل NiFi على Azure، فأنت لست مقيداً بمهمة إعداد تقارير Log Analytics. تدعم NiFi إعداد التقارير للعديد من تقنيات المراقبة التابعة لجهات خارجية. للحصول على قائمة بمهام إعداد التقارير المدعومة، راجع مهام إعداد التقارير في قسم فهرس Apache NiFi Documentation.
مراقبة البنية الأساسية لـ NiFi
بالإضافة إلى مهمة إعداد التقارير، قم بتثبيت ملحق Log Analytics VM على عقدتي NiFi وZooKeeper. يجمع هذا الملحق السجلات والقياسات الإضافية على مستوى VM والقياسات من ZooKeeper.
سجلات مخصصة لتطبيق NiFi والمستخدم وbootstrap وZooKeeper
لتسجيل المزيد من السجلات، اتبع الخطوات التالية:
في مدخل Microsoft Azure، حدد مساحة عمل Log Analytics، ثم حدد مساحة العمل الخاصة بك.
ضمن Settings، حدد Custom logs.
حدد Add custom log.
قم بإعداد سجل مخصص بهذه القيم:
- الاسم:
NiFiAppLogs
- نوع المسار:
Linux
- اسم المسار:
/opt/nifi/logs/nifi-app.log
- الاسم:
قم بإعداد سجل مخصص بهذه القيم:
- الاسم:
NiFiBootstrapAndUser
- نوع المسار الأول:
Linux
- اسم المسار الأول:
/opt/nifi/logs/nifi-user.log
- نوع المسار الثاني:
Linux
- اسم المسار الثاني:
/opt/nifi/logs/nifi-bootstrap.log
- الاسم:
قم بإعداد سجل مخصص بهذه القيم:
- الاسم:
NiFiZK
- نوع المسار:
Linux
- اسم المسار:
/opt/zookeeper/logs/*.out
- الاسم:
فيما يلي نموذج استعلام للجدول المخصص NiFiAppLogs
الذي أنشأه المثال الأول:
NiFiAppLogs_CL
| where TimeGenerated > ago(24h)
| where Computer contains {ComputerName} and RawData contains "error"
| limit 10
ينتج عن هذا الاستعلام نتائج مشابهة للنتائج التالية:
تكوين سجل البنية الأساسية
يمكنك استخدام الشاشة لمراقبة وإدارة VMs أو أجهزة الكمبيوتر الفعلية. يمكن أن تكون هذه الموارد في مركز البيانات المحلي أو بيئة سحابية أخرى. لإعداد هذه المراقبة، قم بتوزيع عامل Log Analytics. تكوين العامل لتقديم تقرير إلى مساحة عمل Log Analytics. لمزيد من المعلومات، راجع نظرة عامة على عامل Log Analytics.
تُظهر لقطة الشاشة التالية نموذج تكوين عامل لأجهزة NiFi VMs. يخزن الجدول Perf
البيانات التي تم جمعها.
فيما يلي نموذج استعلام تطبيق NiFi Perf
سجلات :
let cluster_name = {ComputerName};
// The hourly average of CPU usage across all computers.
Perf
| where Computer contains {ComputerName}
| where CounterName == "% Processor Time" and InstanceName == "_Total"
| where ObjectName == "Processor"
| summarize CPU_Time_Avg = avg(CounterValue) by bin(TimeGenerated, 30m), Computer
ينتج عن هذا الاستعلام تقرير مثل ذلك الموجود في لقطة الشاشة هذه:
التنبيهات
استخدم مراقباً لإنشاء تنبيهات بشأن صحة وأداء نظام المجموعة NiFi. تتضمن أمثلة التنبيهات ما يلي:
- تجاوز إجمالي عدد قوائم الانتظار حد.
- قيمة
BytesWritten
أقل من الحد المتوقع. - قيمة
FlowFilesReceived
أقل من الحد الأدنى. - نظام مجموعة أجهزة غير صحية.
لمزيد من المعلومات بشأن إعداد التنبيهات في الشاشة، راجع نظرة عامة على التنبيهات في Microsoft Azure.
معلمات التكوين
تناقش الأقسام التالية التكوينات الموصى بها وغير الافتراضية لـ NiFi وتوابعها، بما في ذلك ZooKeeper وJava. هذه الإعدادات مناسبة لأحجام أنظمة مجموعة الأجهزة الممكنة في السحابة. قم بتعيين الخصائص في ملفات التكوين التالية:
$NIFI_HOME/conf/nifi.properties
$NIFI_HOME/conf/bootstrap.conf
$ZOOKEEPER_HOME/conf/zoo.cfg
$ZOOKEEPER_HOME/bin/zkEnv.sh
للحصول على معلومات تفصيلية بشأن ملفات وخصائص التكوين المتاحة، راجع إرشاد مسؤول نظام Apache NiFi وإرشاد مسؤول ZooKeeper.
NiFi
لتوزيع Azure، ضع في اعتبارك تعديل الخصائص في $NIFI_HOME/conf/nifi.properties
. يسرد الجدول التالي أهم الخصائص. لمزيد من التوصيات والتفاصيل، راجع قوائم بريد Apache NiFi.
المعلمة | الوصف | الإعداد الافتراضي | التوصية |
---|---|---|---|
nifi.cluster.node.connection.timeout |
كم من الوقت ينتظر عند فتح اتصال بعقد نظام المجموعة الأجهزة الأخرى. | 5 seconds | 60 ثانية |
nifi.cluster.node.read.timeout |
كم من الوقت ينتظر الرد عند تقديم طلب لعقدة نظام المجموعة الأجهزة الأخرى. | 5 seconds | 60 ثانية |
nifi.cluster.protocol.heartbeat.interval |
كم مرة يتم إرسال رسالة كشف أخطاء الاتصال مرة أخرى إلى منسق نظام المجموعة الأجهزة. | 5 seconds | 60 ثانية |
nifi.cluster.node.max.concurrent.requests |
ما هو مستوى التوازي الذي يجب استخدامه عند تكرار استدعاءات HTTP مثل استدعاءات REST API لعقد مجموعة الأجهزة الأخرى. | 100 | 500 |
nifi.cluster.node.protocol.threads |
حجم تجمع مؤشر الترابط الأولي للاتصالات بين نظام المجموعة/الاتصالات المنسوخة نسخا متماثلا. | 10 | 50 |
nifi.cluster.node.protocol.max.threads |
الحد الأقصى لعدد مؤشرات الترابط التي يجب استخدامها للاتصالات بين نظام المجموعة/المنسوخة نسخا متماثلا. | 50 | 75 |
nifi.cluster.flow.election.max.candidates |
عدد العقد التي يجب استخدامها عند تحديد التدفق الحالي. هذه القيمة تقصر التصويت على الرقم المحدد. | فارغ | 75 |
nifi.cluster.flow.election.max.wait.time |
كم من الوقت تنتظر العقد قبل أن تقرر ما هو التدفق الحالي. | 5 دقائق | 5 دقائق |
سلوك نظام المجموعة الأجهزة
عندما تقوم بتكوين مجموعة الأجهزة، ضع في اعتبارك النقاط التالية.
المهلة
لضمان الحالة العامة لمجموعة الأجهزة وعقدها، قد يكون من المفيد زيادة المهلات. تساعد هذه الممارسة على ضمان ألا تنجم الأعطال عن مشاكل عابرة في الشبكة أو أحمال عالية.
في النظام الموزع، يختلف أداء الأنظمة الفردية. يشمل هذا الاختلاف اتصالات الشبكة وزمن انتقال، والذي يؤثر عادةً على الاتصال بين العقد وبين مجموعات الأجهزة. يمكن أن تتسبب البنية الأساسية للشبكة أو النظام نفسه في حدوث هذا الاختلاف. نتيجة لذلك، من المحتمل جداً أن يكون احتمال الإعجاب في مجموعات كبيرة من الأنظمة. في تطبيقات Java قيد التحميل، يمكن أن تؤثر التوقفات المؤقتة في تجميع البيانات المهملة (GC) في جهاز Java الظاهري (JVM) أيضاً على أوقات استجابة الطلب.
استخدم الخصائص في الأقسام التالية لتكوين المهلات لتناسب احتياجات نظامك:
nifi.cluster.node.connection.timeout وnifi.cluster.node.read.timeout
الـ nifi.cluster.node.connection.timeout
تحدد الخاصية مدة الانتظار عند فتح اتصال. الـ nifi.cluster.node.read.timeout
تحدد الخاصية مدة الانتظار عند تلقي البيانات بين الطلبات. القيمة الافتراضية لكل خاصية خمس ثوان. تنطبق هذه الخصائص على طلبات عقدة إلى عقدة. تساعد زيادة هذه القيم في التخفيف من العديد من المشكلات ذات الصلة:
- أن يتم قطع الاتصال من قبل منسق نظام المجموعة بسبب انقطاعات في رسالة كشف أخطاء الاتصال
- فشل التدفق من المنسق عند الانضمام إلى نظام المجموعة
- إنشاء اتصالات من موقع إلى موقع (S2S) وموازنة الحمل
ما لم تكن مجموعة نظام المجموعة بك تحتوي على مجموعة تغيير الحجم صغيرة جداً، مثل ثلاث عقد أو أقل، فاستخدم قيماً أكبر من القيم الافتراضية.
nifi.cluster.protocol.heartbeat.interval
كجزء من إستراتيجية تجميع NiFi، تصدر كل عقدة رسالة كشف أخطاء الاتصال لتوصيل حالتها الصحية. بشكل افتراضي، ترسل العقد رسالة كشف أخطاء الاتصال كل خمس ثوان. إذا اكتشف منسق نظام المجموعة أن ثماني رسائل لكشف أخطاء الاتصال من عقدة قد فشلت، فإنه يفصل العقدة. قم بزيادة الفاصل الزمني الذي تم تعيينه في الخاصية nifi.cluster.protocol.heartbeat.interval
للمساعدة في استيعاب رسالة كشف أخطاء الاتصال البطيئة ومنع نظام المجموعة من فصل العقد دون داع.
التزامن
استخدم الخصائص في الأقسام التالية لتكوين إعدادات التزامن:
nifi.cluster.node.protocol.threads وnifi.cluster.node.protocol.max.threads
nifi.cluster.node.protocol.max.threads
تحدد خاصية الحد الأقصى لعدد مؤشرات الترابط التي يجب استخدامها في اتصالات كل أنظمة المجموعة مثل موازنة تحميل S2S وتجميع واجهة UI. الافتراضي لهذه الخاصية هو 50 مؤشر ترابط. بالنسبة لأنظمة المجموعات الكبيرة، قم بزيادة هذه القيمة لحساب العدد الأكبر من الطلبات التي تتطلبها هذه العمليات.
nifi.cluster.node.protocol.threads
تحدد الخاصية الحجم الأولي لمجمع مؤشرات الترابط. القيمة الافتراضية هي 10 مؤشرات ترابط. هذه القيمة هي الحد الأدنى. ينمو حسب الحاجة حتى يصل إلى الحد الأقصى المحدد في nifi.cluster.node.protocol.max.threads
. قم بزيادة nifi.cluster.node.protocol.threads
قيمة لأنظمة المجموعة التي تستخدم تغييراً واسعاً للحجم تم تعيينه عند التشغيل.
nifi.cluster.node.max.concurrent.requests
تحتاج العديد من طلبات HTTP مثل استدعاءات REST API واستدعاءات UI إلى النسخ المتماثل إلى العقد الأخرى في أنظمة المجموعة. مع نمو حجم نظام المجموعة، يتم تكرار عدد متزايد من الطلبات. nifi.cluster.node.max.concurrent.requests
تحدد الخاصية عدد الطلبات المعلقة. يجب أن تتجاوز قيمتها حجم مجموعة أجهزة الكمبيوتر المتوقع. القيمة الافتراضية هي 100 طلب متزامن. ما لم تكن تقوم بتشغيل نظام المجموعة صغيرة من ثلاث عقد أو أقل، امنع الطلبات الفاشلة عن طريق زيادة هذه القيمة.
اختيار التدفق
استخدم الخصائص في الأقسام التالية لتكوين إعدادات انتخابات التدفق:
nifi.cluster.flow.election.max.candidates
تستخدم NiFi تكوين أنظمة المجموعات ذي الرقم الصفري، ما يعني أنه لا توجد عقدة موثوقة واحدة محددة. نتيجة لذلك، تصوت العقد على تعريف التدفق الذي يعتبر صحيحاً. يصوتون أيضاً لتحديد العقد التي تنضم إلى المجموعة.
بشكل افتراضي، تكون الخاصية nifi.cluster.flow.election.max.candidates
هي أقصى وقت انتظار تحدده الخاصية nifi.cluster.flow.election.max.wait.time
. عندما تكون هذه القيمة عالية جداً، يمكن أن يكون بدء التشغيل بطيئاً. القيمة الافتراضية لـ nifi.cluster.flow.election.max.wait.time
خمس دقائق. عيّن الحد الأقصى لعدد العناصر عامل التصفية على قيمة غير فارغة مثل 1
أو أكبر للتأكد من أن فترة الانتظار لم تعد مطلوبة. إذا قمت بتعيين هذه الخاصية، فقم بتعيين قيمة تتوافق مع حجم نظام المجموعة أو جزء الأغلبية من حجم نظام المجموعة المتوقع. بالنسبة لنظام المجموعات الصغيرة الثابتة المكونة من 10 عقد أو أقل، قم بتعيين هذه القيمة على عدد العقد في نظام المجموعة.
nifi.cluster.flow.election.max.wait.time
في بيئة السحابة المرنة، يؤثر وقت توفير المضيفين على وقت بدء تشغيل التطبيق. nifi.cluster.flow.election.max.wait.time
تحدد الخاصية مدة انتظار NiFi قبل اتخاذ قرار بشأن التدفق. اجعل هذه القيمة تتناسب مع وقت التشغيل الإجمالي لأنظمة المجموعة بحجمها الأولي. في الاختبار الأولي، خمس دقائق أكثر من كافية في جميع مناطق Azure مع أنواع المثيلات الموصى بها. ولكن يمكنك زيادة هذه القيمة إذا تجاوز وقت التوفير بشكل منتظم الوقت الافتراضي.
Java
نوصي باستخدام إصدار LTS من Java. من بين هذه الإصدارات، يُفضل Java 11 قليلاً على Java 8 لأن Java 11 يدعم تنفيذ تجميع البيانات المهملة بشكل أسرع. ومع ذلك، من الممكن الحصول على توزيع NiFi عالي الأداء باستخدام أي من الإصدارين.
تناقش الأقسام التالية تكوينات JVM الشائعة لاستخدامها عند تشغيل NiFi. قم بتعيين معلمات JVM في ملف تكوين التمهيد في $NIFI_HOME/conf/bootstrap.conf
.
جامع المهملات
إذا كنت تقوم بتشغيل Java 11، فإننا نوصي باستخدام أداة جامع المهملات G1 (G1GC) في معظم المواقف. قام G1GC بتحسين الأداء على ParallelGC لأن G1GC يقلل من طول فترات توقف GC إيقافاً مؤقتاً. G1GC هو الإعداد الافتراضي في Java 11، ولكن يمكنك تهيئته بشكل صريح عن طريق تعيين القيمة التالية في bootstrap.conf
:
java.arg.13=-XX:+UseG1GC
إذا كنت تقوم بتشغيل Java 8، فلا تستخدم G1GC. استخدم ParallelGC بدلاً من ذلك. هناك أوجه قصور في تنفيذ Java 8 لـ G1GC تمنعك من استخدامه مع تطبيقات المستودع الموصى بها. ParallelGC أبطأ من G1GC. ولكن مع ParallelGC، لا يزال بإمكانك توزيع NiFi عالي الأداء باستخدام Java 8.
كومة ذاكرة مؤقتة
تحدد مجموعة الخصائص في bootstrap.conf
ملف تكوين كومة ذاكرة مؤقتة NiFi JVM. للحصول على تدفق قياسي، قم بتكوين كومة ذاكرة مؤقتة 32-GB باستخدام هذه الإعدادات:
java.arg.3=-Xmx32g
java.arg.2=-Xms32g
لاختيار حجم كومة الذاكرة المؤقتة الأمثل لتطبيقه على عملية JVM، ضع في اعتبارك عاملين:
- خصائص تدفق البيانات
- الطريقة التي تستخدم بها NiFi الذاكرة في معالجتها
للحصول على وثائق مفصلة، راجع Apache NiFi في العمق.
اجعل كومة الذاكرة المؤقتة كبيرة فقط بالقدر المطلوب للوفاء بمتطلبات المعالجة. هذا الأسلوب يقلل من طول توقف GC إيقاف مؤقت. للحصول على اعتبارات عامة بشأن Java تجميع البيانات المهملة، راجع إرشاد ضبط مجموعة البيانات المهملة لإصدار Java الخاص بك.
عند ضبط إعدادات ذاكرة JVM، ضع في اعتبارك هذه العوامل المهمة:
عدد FlowFiles، أو سجلات بيانات NiFi النشطة في فترة معينة. يتضمن هذا الرقم ملفات FlowFiles التي تم الضغط عليها مرة أخرى أو في قائمة الانتظار.
عدد السمات التي تم تحديدها في FlowFiles.
مقدار الذاكرة الذي يحتاجه المعالج لمعالجة جزء معين من المحتوى.
الطريقة التي يعالج بها المعالج البيانات:
- بيانات متدفقة
- استخدام معالجات التسجيل
- الاحتفاظ بجميع البيانات في الذاكرة دفعة واحدة
هذه التفاصيل مهمة. أثناء المعالجة، يحتفظ NiFi بالمراجع والسمات لكل ملف FlowFile في الذاكرة. في ذروة الأداء، يتناسب حجم الذاكرة التي يستخدمها النظام مع عدد ملفات FlowFiles الحية وجميع السمات التي تحتوي عليها. يتضمن هذا الرقم ملفات FlowFiles في قائمة الانتظار. يمكن لـ NiFi التبديل إلى القرص. لكن تجنب هذا الخيار لأنه يضر بالأداء.
ضع في اعتبارك أيضاً استخدام ذاكرة العنصر الأساسي. على وجه التحديد، اجعل كومة الذاكرة المؤقتة كبيرة بما يكفي للاحتفاظ بالعناصر في الذاكرة. ضع في اعتبارك هذه النصائح لتكوين إعدادات الذاكرة:
- قم بتشغيل التدفق الخاص بك باستخدام البيانات التمثيلية والحد الأدنى من الضغط الخلفي بالبدء بالإعداد
-Xmx4G
ثم زيادة الذاكرة بشكل متحفظ حسب الحاجة. - قم بتشغيل التدفق الخاص بك ببيانات تمثيلية وأعلى ضغط رجعي بالبدء بالإعداد
-Xmx4G
ثم زيادة حجم نظام المجموعة بشكل متحفظ حسب الحاجة. - قم بإنشاء ملف تعريف للتطبيق أثناء تشغيل التدفق باستخدام أدوات مثل VisualVM وYourKit.
- إذا لم تؤدِّ الزيادات المتحفظة في كومة الذاكرة المؤقتة إلى تحسين الأداء بشكل ملحوظ، ففكر في إعادة تصميم التدفقات والمعالجات والجوانب الأخرى لنظامك.
معلمات JVM إضافية
يسرد الجدول التالي خيارات JVM الإضافية. كما يوفر القيم التي عملت بشكل أفضل في الاختبار الأولي. لاحظت الاختبارات نشاط GC واستخدام الذاكرة واستخدمت جمع معلومات الدقيق.
المعلمة | الوصف | JVM الافتراضي | التوصية |
---|---|---|---|
InitiatingHeapOccupancyPercent |
مقدار كومة الذاكرة المؤقتة المستخدمة قبل بدء دورة وضع المشغّل. | 45 | 35 |
ParallelGCThreads |
عدد مؤشرات الترابط التي يستخدمها GC. تم تحديد نقطة الارتكاز هذه للحد من التأثير الكلي على النظام. | 5/8 من عدد وحدات المعالجة المركزية الظاهرية | 8 |
ConcGCThreads |
عدد مؤشرات الترابط GC المراد تشغيلها بالتوازي. يتم زيادة هذه القيمة لحساب ParallelGCThreads نقطة ارتكاز. | 1/4 من قيمة ParallelGCThreads |
4 |
G1ReservePercent |
النسبة المئوية للذاكرة الاحتياطية للاحتفاظ بها خالية. يتم زيادة هذه القيمة لتجنب استنفاد الفضاء، ما يساعد على تجنب GC الكامل. | 10 | 20 |
UseStringDeduplication |
ما إذا كانت ستتم محاولة تحديد وإزالة المراجع لسلاسل متطابقة. يمكن أن يؤدي تشغيل هذه الميزة إلى توفير الذاكرة. | - | present |
قم بتكوين هذه الإعدادات عن طريق إضافة الإدخالات التالية إلى NiFi bootstrap.conf
:
java.arg.17=-XX:+UseStringDeduplication
java.arg.18=-XX:G1ReservePercent=20
java.arg.19=-XX:ParallelGCThreads=8
java.arg.20=-XX:ConcGCThreads=4
java.arg.21=-XX:InitiatingHeapOccupancyPercent=35
ZooKeeper
لتحسين التسامح مع الخطأ، قم بتشغيل ZooKeeper كنظام المجموعة. اتبع هذا النهج على الرغم من أن معظم عمليات توزيع NiFi تضع عبئاً متواضعاً نسبياً على ZooKeeper. قم بتشغيل الأنظمة المجموعة لـ ZooKeeper بشكل صريح. بشكل افتراضي، يشغل ZooKeeper في وضع الخادم الفردي. للحصول على معلومات مفصلة، راجع نظام مجموعة (متعدد الخوادم) في إرشاد مسؤول ZooKeeper.
باستثناء إعدادات تكوين أنظمة المجموعات، استخدم القيم الافتراضية لتكوين ZooKeeper الخاص بك.
إذا كان لديك مجموعة NiFi كبيرة، فقد تحتاج إلى استخدام عدد أكبر من خوادم ZooKeeper. بالنسبة لأحجام نظام المجموعة الأصغر، تكون أحجام VM الأصغر والأقراص المُدارة القياسية لـ SSD كافية.
المساهمون
تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.
الكاتب الرئيسي:
- معزامة زاهد | مدير رئيس الوزراء الأساسي
لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.
الخطوات التالية
جاءت المواد والتوصيات الواردة في هذه الوثيقة من عدة مصادر:
- الاختبار
- أفضل ممارسات Azure
- معلومات مجتمع NiFi وأفضل الممارسات والتوثيق
لمزيد من المعلومات، راجع الموارد التالية:
- إرشاد مسؤول نظام Apache NiFi
- قوائم بريد Apache NiFi
- أفضل ممارسات Cloudera لإعداد تثبيت NiFi عالي الأداء
- تخزين Azure premium: تصميم لأداء عالٍ
- تحرّي الخلل وإصلاحه في أداء الجهاز الظاهري Azure على Linux أو Windows