الأسئلة الشائعة حول Service Fabric
هناك العديد من الأسئلة الشائعة حول ما يمكن لـ Service Fabric فعله وكيفية استخدامه. يتناول هذا المستند العديد من تلك الأسئلة الشائعة وإجاباتها.
إشعار
نوصي باستخدام الوحدة النمطية Azure Az PowerShell للتفاعل مع Azure. راجع تثبيت Azure PowerShell للبدء. لمعرفة كيفية الترحيل إلى الوحدة النمطية Az PowerShell، راجع ترحيل Azure PowerShell من AzureRM إلى Az.
إعداد نظام المجموعة وإدارته
كيف يمكنني العودة إلى الحالة السابقة لشهادة نظام مجموعة Service Fabric؟
يتطلب العودة إلى الحالة السابقة لأي ترقية للتطبيق كشف فشل الحالة قبل اكتمال حصة نظام مجموعة Service Fabric الذي ينفذ التغيير؛ فلا يمكن الانتقال إلى الحالة التالية للتغييرات المنفَّذة. قد تكون هناك حاجة إلى مهندس التصعيد من خلال خدمات دعم العملاء لاستعادة نظام المجموعة، إذا تم إدخال تغيير غير مراقَب في شهادة الكسر. تطبق ترقية تطبيق Service Fabricمعلمات ترقية التطبيق، وتقدم تعهداً بالترقية لوصول وقت التعطل إلى صفر. بعد الوضع المراقَب الموصى به لترقية التطبيق، يعتمد التقدم التلقائي من خلال مجالات التحديث على اجتياز عمليات التحقق من الحالة، مع العودة إلى الحالة السابقة تلقائياً في حالة فشل تحديث الخدمة الافتراضية.
إذا كان نظام المجموعة لا يزال تستفيد من خاصية بصمة إبهام الشهادة التقليدية في قالب Resource Manager، فمن المستحسن تغيير نظام المجموعة من بصمة إبهام الشهادة إلى الاسم الشائع، للاستفادة من ميزات إدارة البيانات السرية الحديثة.
هل يمكنني إنشاء نظام مجموعة يمتد عبر مناطق Azure متعددة أو مراكز البيانات الخاصة بي؟
نعم.
يمكن استخدام تكنولوجيا الأساسية لتكوين أنظمة مجموعات Service Fabric للجمع بين الأجهزة التي تعمل في أي مكان في العالم، طالما أنها تتصل ببعضها البعض من خلال الشبكة. ومع ذلك، يمكن أن يكون إنشاء نظام المجموعة هذا وتشغيله أمراً معقداً.
إذا كنت مهتماً بهذا السيناريو، فنحن نشجعك على التواصل من خلال قائمة مشكلات GitHub لـ Service Fabric أو من خلال ممثل الدعم لديك من أجل الحصول على إرشادات إضافية. يعمل فريق Service Fabric على تقديم المزيد من الوضوح والتوجيهات والتوصيات فيما يخص هذا السيناريو.
بعض الأشياء التي يجب مراعاتها:
- مورد نظام مجموعة Service Fabric في Azure إقليمي حالياً، وكذلك مجموعات مقاييس الجهاز الظاهري التي تم إنشاء نظام المجموعة فيها. وهذا يعني أنه في حالة حدوث فشل إقليمي، قد تفقد القدرة على إدارة نظام المجموعة عبر Azure Resource Manager أو مدخل Microsoft Azure. يمكن أن يحدث هذا على الرغم من أن نظام المجموعة لا يزال قيد التشغيل ولديك القدرة على التفاعل معه مباشرة. بالإضافة إلى ذلك، لا يوفر Azure حالياً القدرة على الحصول على شبكة ظاهرية واحدة قابلة للاستخدام عبر المناطق. وهذا يعني أن نظام المجموعة متعدد المناطق في Azure تتطلب عناوين IP عامة لكل جهاز ظاهري في مجموعات مقاييس الجهاز الظاهري أو بوابات Azure VPN Gateway. خيارات الشبكات هذه لها تأثيرات مختلفة على التكاليف والأداء وإلى حد ما تصميم التطبيقات؛ لذلك، يلزم إجراء تحليل وتخطيط دقيقين قبل النهوض بمثل هذه البيئة.
- يمكن أن تصبح صيانة هذه الأجهزة وإدارتها ومراقبتها معقدة، خاصة عندما تمتد عبر أنواع البيئات، على سبيل المثال، بين موفري الخدمات السحابية المختلفين أو بين الموارد المحلية وAzure. يجب توخي الحذر لضمان فهم الترقيات والمراقبة والإدارة والتشخيصات لكل من نظام المجموعة والتطبيقات قبل تشغيل أحمال عمل الإنتاج في هذه البيئة. إذا كان لديك بالفعل خبرة في حل هذه المشكلات في Azure أو داخل مراكز البيانات لديك، فمن المحتمل أن يتم تطبيق هذه الحلول نفسها عند إنشاء نظام مجموعة Service Fabric أو تشغيله.
هل تتلقى عُقد Service Fabric تحديثات نظام التشغيل تلقائياً؟
يمكنك استخدام ميزة التحديث التلقائي لصورة نظام تشغيل مجموعة مقاييس الأجهزة الظاهرية المتوفرة بشكل عام حالياً.
بالنسبة لأنظمة المجموعات التي لا يتم تشغيلها في Azure، وفرنا تطبيقاً لتصحيح أنظمة التشغيل أسفل عُقد Service Fabric.
هل يمكنني استخدام مجموعات مقاييس الجهاز الظاهري الكبيرة في نظام مجموعة SF؟
إجابة قصيرة - لا.
إجابة طويلة - على الرغم من أن مجموعات مقاييس الجهاز الظاهري الكبيرة تسمح لك بتغيير حجم إعداد مقياس الجهاز الظاهري إلى 1000 مثيل جهاز ظاهري، إلا أنه يمكنه إجراء ذلك باستخدام مجموعات المواضع (PG). لا تكون مجالات الخطأ (FD) ومجالات الترقية (UD) متناسقة إلا داخل مجموعة المواضع ويستخدم Service Fabric مجالات الخطأ ومجالات الترقية لاتخاذ قرارات تحديد المواضع الخاصة بالنسخ المتماثلة/المثيلات الخاصة بالخدمة. نظراً لأن مجالات الخطأ ومجالات الترقية لا تكون قابلة للمقارنة إلا داخل مجموعة المواضع، لا يمكن لـ SF استخدامها. على سبيل المثال، إذا كان لدى VM1 في PG1 طوبولوجيا FD = 0 ولدى VM9 في PG2 طوبولوجيا FD = 4، فهذا لا يعني أن VM1 وVM2 على حاملين مختلفين من الأجهزة؛ وبالتالي، لا يمكن لـ SF استخدام قيم FD في هذه الحالة لاتخاذ قرارات تحديد المواضع.
توجد مشكلات أخرى في مجموعات مقاييس الجهاز الظاهري الكبيرة حالياً، مثل عدم وجود دعم موازنة التحميل من المستوى 4. راجع للحصول على تفاصيل عن مجموعات المقاييس الكبيرة
ما هو الحد الأدنى لحجم نظام مجموعة Service Fabric؟ لماذا لا يمكن أن يكون أصغر؟
أدنى حجم مدعوم لنظام مجموعة Service Fabric يشغّل أحمال العمل الإنتاجية هو خمس عُقد. بالنسبة لسيناريوهات التطوير، ندعم أنظمة المجموعات ذات عقدة واحدة (محسنة لتجربة تطوير سريع في Visual Studio) وخمس عُقد.
من متطلباتنا أن يحتوي نظام المجموعة الإنتاجي على خمس عُقد على الأقل للأسباب الثلاثة التالية:
- حتى عند عدم تشغيل أي خدمات مستخدم، يشغّل نظام مجموعة Service Fabric مجموعة من خدمات النظام ذات الحالة الخاصة، بما في ذلك خدمة التسمية وخدمة إدارة تجاوز الفشل. تكون خدمات النظام هذه ضرورية لكي يظل نظام المجموعة قيد التشغيل.
- نضع دائماً نسخة متماثلة واحدة من خدمة لكل عقدة، لذا، فإن حجم نظام المجموعة يمثل الحد الأعلى لعدد النسخ المتماثلة التي يمكن أن تحتوي عليها الخدمة (القسم في الواقع).
- نظراً لأن ترقية نظام المجموعة ستؤدي إلى تعطيل عقدة واحدة على الأقل، نريد أن يكون لدينا مخزن مؤقت لعقدة واحدة على الأقل؛ وبالتالي، نريد أن يحتوي نظام المجموعة الإنتاجي على عقدتين على الأقل بالإضافة إلى الحد الأدنى. الحد الأدنى هو حجم حصة خدمة النظام كما هو موضح أدناه.
نريد أن يكون نظام المجموعة متوفراً في مواجهة الفشل المتزامن لعقدتين. لكي يتوفر نظام مجموعة Service Fabric، يجب أن تتوفر خدمات النظام. تعتمد خدمات النظام ذات الحالة الخاصة مثل خدمة التسمية وخدمة إدارة تجاوز الفشل، التي تتعقب الخدمات التي تم توزيعها على نظام المجموعة ومكان استضافتها حالياً، على الاتساق القوي. ويتوقف هذا الاتساق القوي، بدوره، على القدرة على اكتساب الحصة لأي تحديث معين لحالة تلك الخدمات، حيث تمثل الحصة أغلبية صارمة من النسخ المتماثلة (N/2 +1) لخدمة معينة. وبالتالي، إذا أردنا أن نحقق المرونة ضد الفقدان المتزامن لعقدتين (وبالتالي فقدان متزامن لنسختين متماثلتين من خدمة النظام)، يجب أن يكون لدينا ClusterSize - QuorumSize >= 2؛ مما يفرض أن يكون الحد الأدنى للحجم خمسة. للاطلاع على ذلك، ضع في الاعتبار أن نظام المجموعة يحتوي على N من العُقد ويوجد N من النسخ المتماثلة من خدمة النظام - واحدة في كل عُقدة. حجم حصة خدمة النظام هو (N/2 + 1). يبدو عدم المساواة أعلاه مثل N - (N/2 + 1) >= 2. هناك حالتان لوضعها في الاعتبار: عندما يكون N عدداً زوجياً وعندما يكون N عدداً فردياً. إذا كان N عدداً زوجياً، افترض أن N = 2*m حيث m >= 1، يبدو عدم المساواة مثل 2*m - (2*m/2 + 1) >= 2 أو m >= 3. الحد الأدنى لـ N هو 6 ويتحقق عندما يكون m = 3. من ناحية أخرى، إذا كان N عدداً فردياً، افترض أن N = 2*m+1 حيث m >= 1، يبدو عدم المساواة مثل 2*m+1 - ( (2*m+1)/2 + 1 ) >= 2 أو 2*m+1 - (m+1) >= 2 أو m >= 2. الحد الأدنى لـ N هو 5 ويتحقق عندما يكون m = 2. لذلك، من بين جميع قيم N التي تستوفي عدم المساواة ClusterSize - QuorumSize >= 2، يكون الحد الأدنى هو 5.
لاحظ أنه، في الوسيطة أعلاه، افترضنا أن كل عقدة تحتوي على نسخة متماثلة من خدمة النظام؛ وبالتالي، يتم حساب حجم الحصة بناء على عدد العُقد في نظام المجموعة. ومع ذلك، من خلال تغيير TargetReplicaSetSize، يمكننا جعل حجم الحصة أقل من (N/2+1)؛ مما قد يعطي انطباعاً بأنه يمكن أن يكون لدينا نظام مجموعة أصغر من 5 عُقد ولا يزال لدينا عقدتان إضافيتان أعلى من حجم الحصة. على سبيل المثال، في نظام مجموعة ذي 4 عُقد، في حالة تعيين TargetReplicaSetSize إلى 3، فإن حجم الحصة استناداً إلى TargetReplicaSetSize هو (3/2 + 1) أو 2؛ وبالتالي، يكون لدينا ClusterSize - QuorumSize = 4-2 >= 2. ومع ذلك، لا يمكننا ضمان أن خدمة النظام ستبلغ الحصة أو تكون أعلى منها إذا فقدنا أي زوج من العُقد في وقت واحد، حيث يمكن أن تكون العقدتان اللتان فقدناهما كانتا تستضيفان نسختين متماثلتين؛ وبالتالي، فإن خدمة النظام ستفقد الحصة (مع وجود نسخة متماثلة واحدة فقط) وستصبح غير متوفرة.
مع هذه الخلفية، دعونا نفحص بعض تكوينات نظام المجموعة المحتملة:
عقدة واحدة: لا يوفر هذا الخيار توفراً عالياً لأن فقدان عقدة واحدة لأي سبب من الأسباب يعني فقدان نظام المجموعة بأكمله.
عقدتان: حصة الخدمة التي تم توزيعها على عقدتين (N = 2) هي 2 (2/2 + 1 = 2). عند فقدان نسخة متماثلة واحدة، من المستحيل إنشاء الحصة. نظراً لأن إجراء ترقية الخدمة يتطلب إزالة نسخة متماثلة مؤقتاً، فهذا ليس تكويناً مفيداً.
ثلاث عُقد: مع وجود ثلاث عُقد (N=3)، لا يزال شرط إنشاء الحصة هو عقدتان (3/2 + 1 = 2). وهذا يعني أنه يمكنك فقدان عقدة واحدة مع استمرار الحفاظ على الحصة، ولكن الفشل المتزامن لعقدتين سيؤدي إلى فقدان خدمات النظام للحصة وسيؤدي إلى عدم توفر نظام المجموعة.
أربع عُقد: مع وجود أربع عقد (N=4)، يكون شرط إنشاء الحصة هو ثلاث عُقد (4/2 + 1 = 3). وهذا يعني أنه يمكنك فقدان عقدة واحدة مع استمرار الحفاظ على الحصة، ولكن الفشل المتزامن لعقدتين سيؤدي إلى فقدان خدمات النظام للحصة وسيؤدي إلى عدم توفر نظام المجموعة.
خمس عُقد: مع وجود خمس عُقد (N=5)، لا يزال شرط إنشاء الحصة هو ثلاث عُقد (5/2 + 1 = 3). وهذا يعني أنه يمكنك فقدان عقدتين في الوقت نفسه والاحتفاظ بحصة خدمات النظام.
بالنسبة لأحمال العمل الإنتاجية، يجب أن تكون مرناً في مواجهة الفشل المتزامن لعقدتين على الأقل (على سبيل المثال، واحدة بسبب ترقية نظام المجموعة، والأخرى لأسباب أخرى)؛ لذلك، يلزم وجود خمس عُقد.
هل يمكنني إيقاف تشغيل نظام مجموعتي في الليل/عطلات نهاية الأسبوع لتوفير التكاليف؟
بشكل عام، لا. يخزن Service Fabric الحالة على أقراص محلية مؤقتة؛ أي أنه إذا تم نقل الجهاز الظاهري إلى مضيف مختلف، فلن تنتقل البيانات معه. في العملية العادية، لا تكون هذه مشكلة حيث يتم تحديث العقدة الجديدة بواسطة عُقد أخرى. ومع ذلك، أوقفت جميع العُقد وأعدت تشغيلها لاحقاً، فهناك احتمال كبير بأن تبدأ معظم العُقد على مضيفين جدد وتجعل النظام غير قادر على الاسترداد.
إذا كنت ترغب في إنشاء أنظمة مجموعات لاختبار التطبيق قبل توزيعه، فإننا نوصي بإنشاء أنظمة المجموعات هذه ديناميكياً كجزء من البنية الأساسية لبرنامج ربط العمليات التجارية للتكامل/التوزيع المستمر.
كيف يمكنني ترقية نظام التشغيل (على سبيل المثال، من Windows Server 2012 إلى Windows Server 2016)؟
بينما نعمل على تقديم تجربة محسنة، تكون عليك مسؤولية إجراء الترقية. يجب ترقية صورة نظام التشغيل على الأجهزة الظاهرية لنظام المجموعة بجهاز ظاهري واحد في كل مرة.
هل يمكنني تشفير أقراص البيانات المرفقة في نوع عقدة نظام المجموعة (مجموعة مقاييس الأجهزة الظاهرية)؟
نعم. لمزيد من المعلومات، راجع إنشاء نظام مجموعة يحتوي على أقراص بيانات مرفقة وتشفير قرص Azure لمجموعات مقاييس الأجهزة الظاهرية.
هل يمكنني استخدام الأجهزة الظاهرية منخفضة الأولوية في نوع عقدة نظام المجموعة (مجموعة مقاييس الأجهزة الظاهرية)؟
لا. لا يتم دعم الأجهزة الظاهرية ذات الأولوية المنخفضة.
ما هي الدلائل والعمليات التي أحتاج إلى استبعادها عند تشغيل برنامج الحماية من الفيروسات في نظام المجموعة؟
| الدلائل المستبعدة من برنامج الحماية من الفيروسات |
|---|
| ملفات البرامج\Microsoft Service Fabric |
| FabricDataRoot (من تكوين نظام المجموعة) |
| FabricLogRoot (من تكوين نظام المجموعة) |
| العمليات المستبعدة من برنامج الحماية من الفيروسات |
|---|
| Fabric.exe |
| FabricHost.exe |
| FabricInstallerService.exe |
| FabricSetup.exe |
| FabricDeployer.exe |
| ImageBuilder.exe |
| FabricGateway.exe |
| FabricDCA.exe |
| FabricFAS.exe |
| FabricUOS.exe |
| FabricRM.exe |
| FileStoreService.exe |
كيف يمكن للتطبيق المصادقة على Key Vault للحصول على البيانات السرية؟
فيما يلي وسائل يمكن للتطبيق من خلالها الحصول على بيانات اعتماد للمصادقة على Key Vault:
أ. أثناء مهمة إنشاء/تعبئة التطبيقات، يمكنك سحب شهادة إلى حزمة بيانات تطبيق SF، واستخدامها للمصادقة على Key Vault. ب. بالنسبة للمضيفين المزودين بـ MSI لمجموعة مقاييس الأجهزة الظاهرية، يمكنك تطوير PowerShell SetupEntryPoint بسيطة لتطبيق SF للحصول على رمز مميز للوصول من نقطة نهاية MSI، ثم استرداد بياناتك السرية من Key Vault.
هل يمكنني نقل اشتراكي إلى مستأجر Microsoft Entra مختلف؟
لا. في هذا الوقت ستحتاج إلى إنشاء مورد مجموعة Service Fabric جديد بعد نقل الاشتراك إلى مستأجر Microsoft Entra مختلف.
هل يمكنني نقل/ترحيل نظام المجموعة الخاص بي بين مستأجري Microsoft Entra؟
لا. في هذا الوقت ستحتاج إلى إنشاء مورد مجموعة Service Fabric جديد ضمن المستأجر الجديد.
هل يمكنني نقل/ترحيل مقطع التخزين الخاص بي بين الاشتراكات؟
لا. في هذا الوقت ستحتاج إلى إنشاء مورد مجموعة Service Fabric جديد ضمن الاشتراك الجديد.
هل يمكنني نقل/ترحيل موارد نظام المجموعة أو نظام المجموعة إلى مجموعات موارد أخرى أو إعادة تسميتها؟
لا. في هذا الوقت ستحتاج إلى إنشاء مورد مجموعة Service Fabric جديد ضمن مجموعة الموارد الجديدة/الاسم.
تصميم التطبيق
ما هي أفضل طريقة للاستعلام عن البيانات عبر أقسام مجموعة موثوقة؟
عادة ما يتم تقسيم المجموعات الموثوقة لتمكين التوسيع للحصول على أداء ومعدل نقل أكبر. وهذا يعني أن حالة خدمة معينة قد تنتشر عبر عشرات أو مئات الأجهزة. لتنفيذ العمليات عبر مجموعة البيانات الكاملة هذه، تتوفر لديك بضعة خيارات:
- إنشاء خدمة تستعلم عن جميع أقسام خدمة أخرى لسحب البيانات المطلوبة.
- إنشاء خدمة يمكن أن تتلقى البيانات من جميع أقسام خدمة أخرى.
- دفع البيانات دورياً من كل خدمة إلى مخزن خارجي. لا يكون هذا النهج مناسباً إلا إذا لم تكن الاستعلامات التي تنفذها جزءاً من منطق تسلسل العمل الأساسي، حيث ستكون بيانات المخزن الخارجي تالفة.
- بدلاً من ذلك، خزِّن البيانات التي يجب أن تدعم الاستعلام عبر جميع السجلات مباشرة في مخزن بيانات بدلاً من مجموعة موثوقة. وهذا يحل المشكلة في البيانات التالفة، ولكن لا يسمح بالاستفادة من مزايا المجموعات الموثوقة.
ما هي أفضل طريقة للاستعلام عن البيانات عبر المستخدمين؟
تم تصميم المستخدمين ليمثلوا وحدات مستقلة للحالة والحوسبة؛ لذلك، لا يوصى بتنفيذ استعلامات واسعة عن حالة المستخدم في وقت التشغيل. إذا كان لديك حاجة للاستعلام عبر مجموعة كاملة من حالة المستخدم، يجب أن تأخذ في الاعتبار:
- استبدال خدمات المستخدمين بخدمات موثوقة ذات حالة خاصة، بحيث يكون عدد طلبات الشبكة لجمع جميع البيانات من عدد المستخدمين إلى عدد الأقسام في خدمتك.
- تصميم المستخدمين لدفع الحالة دورياً إلى مخزن خارجي لتسهيل الاستعلام. كما هو موضح أعلاه، يكون هذا النهج قابلاً للتطبيق فقط إذا كانت الاستعلامات التي تنفذها غير مطلوبة لسلوك وقت التشغيل.
ما مقدار البيانات التي يمكنني تخزينها في مجموعة موثوقة؟
عادة ما يتم تقسيم الخدمات الموثوقة؛ وبالتالي، فإن المقدار الذي يمكنك تخزينه يكون محدوداً فقط بعدد الأجهزة الموجودة في نظام المجموعة، ومقدار الذاكرة المتوفرة في تلك الأجهزة.
على سبيل المثال، لنفترض أن لديك مجموعة موثوقة في خدمة تحتوي على 100 قسم و3 نسخ متماثلة، تخزِّن كائنات يبلغ حجمها في المتوسط 1 كيلوبايت. افترض الآن أن لديك نظام مجموعة مكون من 10 أجهزة بذاكرة تبلغ 16 جيجابايت لكل جهاز. لتحقيق البساطة ولكي تكون متحفظاً، افترض أن نظام التشغيل وخدمات النظام، ووقت تشغيل Service Fabric، وخدماتك تستهلك 6 جيجابايت من الذاكرة، تاركةً 10 جيجابايت متاحة لكل جهاز، أو 100 جيجابايت لنظام المجموعة.
مع الأخذ في الاعتبار أنه يجب تخزين كل كائن ثلاث مرات (واحد أساسي ونسختين متماثلتين)، سيكون لديك ذاكرة كافية لما يقرب من 35 مليون كائن في مجموعتك عند العمل بكامل السعة. ومع ذلك، نوصي بالتحلي بالمرونة في مواجهة الفقدان المتزامن لمجتا الفشل ومجال الترقية، والذي يمثل حوالي 1/3 السعة، ومن شأنه أن يقلل من العدد إلى ما يقرب من 23 مليوناً.
تفترض هذه العملية الحسابية أيضاً ما يلي:
أن توزيع البيانات على الأقسام موحد تقريباً أو أنك تبلِّغ Cluster Resource Manager بمقاييس التحميل. بشكل افتراضي، تتم موازنة تحميل Service Fabric استناداً إلى عدد النسخ المتماثلة. في المثال السابق، يؤدي ذلك إلى وضع 10 نسخ متماثلة أساسية و 20 نسخة متماثلة ثانوية على كل عقدة في نظام المجموعة. يعمل ذلك جيداً مع التحميل الذي يتم توزيعه على الأقسام بالتساوي. إذا لم يكن التحميل متساوياً، يجب عليك الإبلاغ عن التحميل حتى يتمكن Resource Manager من حزم النسخ المتماثلة الأصغر معاً والسماح للنسخ المتماثلة الأكبر باستهلاك المزيد من الذاكرة في عقدة فردية.
أن الخدمة الموثوقة المعنية هي الوحيدة التي تخزِّن الحالة في نظام المجموعة. نظراً لأنه يمكنك توزيع خدمات متعددة على نظام مجموعة، يجب أن تضع في اعتبارك الموارد التي تحتاج إليها كل خدمة لتشغيل حالتها وإدارتها.
أن نظام المجموعة نفسه لا يزداد ولا ينقص. إذا أضفت المزيد من الأجهزة، فسيعيد Service Fabric موازنة النسخ المتماثلة للاستفادة من السعة الإضافية حتى يتجاوز عدد الأجهزة عدد الأقسام في خدمتك، نظراً لأن النسخة المتماثلة الفردية لا يمكنها أن تمتد عبر الأجهزة. وعلى النقيض من ذلك، إذا قللت حجم نظام المجموعة عن طريق إزالة الأجهزة، تتم تعبئة النسخ المتماثلة بشكل أكثر إحكاماً وتكون لها سعة إجمالية أقل.
ما مقدار البيانات التي يمكنني تخزينها في مستخدم؟
كما هو الحال مع الخدمات الموثوقة، يتم تقييد مقدار البيانات التي يمكنك تخزينها في خدمة المستخدم فقط بإجمالي مساحة القرص والذاكرة المتوفرة عبر العُقد في نظام المجموعة. ومع ذلك، يكون المستخدمون الفرديون الأكثر فعالية عند استخدامهم لتغليف مقدار صغيرة من الحالة ومنطق تسلسل العمل المقترن. كقاعدة عامة، يجب أن يكون لدى المستخدم الفردي حالة تقاس بالكيلوبايت.
أين يخزّن Azure Service Fabric Resource Provider بيانات العملاء؟
لا ينقل Azure Service Fabric Resource Provider بيانات العملاء أو تخزينها خارج المنطقة التي تم توزيعها فيها.
أسئلة أخرى
كيف يرتبط Service Fabric بالحاويات؟
توفر الحاويات طريقة بسيطة لحَزْم الخدمات وتبعياتها بحيث تعمل باستمرار في جميع البيئات، ويمكن أن تعمل بطريقة معزولة على جهاز واحد. يوفر Service Fabric طريقة لتوزيع الخدمات وإدارتها، بما في ذلك الخدمات التي تم تحزيمها في حاوية.
هل تخطط لفتح مصدر Service Fabric؟
لدينا أجزاء مفتوحة المصدر من Service Fabric (إطار عمل الخدمات الموثوقة وإطار عمل المستخدمين الموثوقين ومكتبات تكامل ASP.NET Core وService Fabric Explorer وService Fabric CLI) على GitHub وقبول إسهامات المجتمع في تلك المشروعات.
لقد أعلنا مؤخراً أننا نخطط لفتح مصدر وقت تشغيل Service Fabric. في هذه المرحلة، لدينا مستودع Service Fabric على GitHub مع أدوات إنشاء واختبار Linux؛ أي أنه يمكنك نسخ المستودع، وإنشاء Service Fabric لنظام التشغيل Linux، وتشغيل الاختبارات الأساسية، وفتح المشكلات، وتقديم طلبات السحب. نحن نعمل بجد لترحيل بيئة بناء Windows أيضاً، إلى جانب بيئة CI كاملة.
تابع مدونة Service Fabric للحصول على مزيد من التفاصيل عند الإعلان عنها.
الخطوات التالية
تعرف على مفاهيم وقت تشغيل Service Fabric وأفضل الممارسات المتعلقة به