مشاركة عبر

الأسئلة المتداولة حول مرونة التطبيق لملفات Azure NetApp

  • مقالة

تجيب هذه المقالة على الأسئلة المتداولة (FAQs) حول مرونة تطبيق Azure NetApp Files.

ما الذي توصي به لمعالجة اضطرابات التطبيقات المحتملة بسبب أحداث صيانة خدمة التخزين؟

قد تخضع Azure NetApp Files لصيانة مخططة عرضية (على سبيل المثال، تحديثات النظام الأساسي أو ترقيات الخدمة أو البرامج). من منظور بروتوكول الملف (NFS/SMB)، تكون عمليات الصيانة غير متقطعة، طالما أن التطبيق يمكنه التعامل مع إيقاف الإدخال/الإخراج مؤقتا الذي قد يحدث لفترة وجيزة أثناء هذه الأحداث. عادة ما تكون الإيقافات المؤقتة الإدخال/الإخراج قصيرة، تتراوح بين بضع ثوان حتى 30 ثانية. بروتوكول NFS قوي بشكل خاص، وتستمر عمليات ملف خادم العميل بشكل طبيعي. قد تتطلب بعض التطبيقات ضبطا للتعامل مع إيقاف IO مؤقتا لمدة 30-45 ثانية. على هذا النحو، تأكد من أنك على دراية بإعدادات مرونة التطبيق للتعامل مع أحداث صيانة خدمة التخزين. بالنسبة للتطبيقات التفاعلية البشرية التي تستفيد من بروتوكول SMB، عادة ما تكون إعدادات البروتوكول القياسية كافية.

هام

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

هل أحتاج إلى اتخاذ احتياطات خاصة للتطبيقات المستندة إلى SMB؟

نعم، تتطلب بعض التطبيقات المستندة إلى SMB تجاوز فشل شفاف SMB. يتيح SMB Transparent Failover عمليات الصيانة على خدمة Azure NetApp Files دون مقاطعة الاتصال بتطبيقات الخادم التي تخزن البيانات والوصول إليها على وحدات تخزين SMB. لدعم تجاوز الفشل الشفاف SMB لتطبيقات معينة، تدعم Azure NetApp Files الآن خيار مشاركات SMB Continuous Availability. استخدام SMB Continuous Availability مدعوم فقط لأحمال العمل على:

تنبيه

التطبيقات المخصصة غير مدعومة مع SMB Continuous Availability ولا يمكن استخدامها مع وحدات التخزين الممكنة ل SMB Continuous Availability.

أنا أقوم بتشغيل IBM MQ على Azure NetApp Files. ما الاحتياطات التي يمكنني اتخاذها لتجنب الاضطرابات بسبب أحداث صيانة خدمة التخزين على الرغم من استخدام بروتوكول NFS؟

إذا كنت تقوم بتشغيل تطبيق IBM MQ في تكوين ملفات مشتركة، حيث يتم تخزين بيانات IBM MQ وسجلاته على وحدة تخزين Azure NetApp Files، يوصى بالاعتبارات التالية لتحسين المرونة أثناء أحداث صيانة خدمة التخزين:

إشعار

يعتمد عدد الرسائل التي يجب أن يعالجها كل زوج متعدد المثيلات MQ بشكل كبير على بيئتك المحددة. تحتاج إلى تحديد عدد أزواج MQ متعددة المثيلات المطلوبة، أو ما هي قواعد التوسيع أو التوسيع.

ستتألف بنية التوسع من أزواج متعددة من IBM MQ متعددة المثيلات المنشورة خلف Azure Load Balancer. ثم يتم تكوين التطبيقات التي تم تكوينها للتواصل مع IBM MQ للاتصال بمثيلات IBM MQ عبر Azure Load Balancer. للحصول على الدعم المتعلق ب IBM MQ على وحدات تخزين NFS المشتركة، يجب الحصول على دعم المورد في IBM.

أقوم بتشغيل Apache ActiveMQ مع LevelDB أو KahaDB على Azure NetApp Files. ما الاحتياطات التي يمكنني اتخاذها لتجنب الاضطرابات بسبب أحداث صيانة خدمة التخزين على الرغم من استخدام بروتوكول NFS ؟

إذا كنت تقوم بتشغيل Apache ActiveMQ، فمن المستحسن نشر ActiveMQ High Availability مع Pluggable Storage Lockers.

تضمن نماذج قابلية الوصول العالية (HA) ل ActiveMQ أن مثيل الوسيط متصل دائما بالإنترنت وقادر على معالجة حركة مرور الرسائل. يتضمن نموذجا ActiveMQ HA الأكثر شيوعا مشاركة نظام ملفات عبر شبكة. الغرض هو توفير إما LevelDB أو KahaDB لمثيلات الوسيط النشطة والسلبية. تتطلب نماذج قابلية الوصول العالية هذه الحصول على تأمين على مستوى نظام التشغيل والاحتفاظ به على ملف في دلائل LevelDB أو KahaDB، يسمى "تأمين". هناك بعض المشاكل مع نموذج ActiveMQ HA هذا. يمكن أن تؤدي إلى وضع "لا رئيسي"، حيث لا تدرك النسخة المتماثلة أنه يمكنها تأمين الملف. يمكن أن تؤدي أيضا إلى تكوين "رئيسي" يؤدي إلى تلف الفهرس أو دفتر اليومية وفقدان الرسائل في نهاية المطاف. معظم هذه المشاكل تنبع من عوامل خارج سيطرة ActiveMQ. على سبيل المثال، يمكن أن يتسبب عميل NFS الذي تم تحسينه بشكل سيئ في أن يصبح تأمين البيانات تالفة تحت الحمل، مما يؤدي إلى وقت تعطل "غير رئيسي" أثناء تجاوز الفشل.

نظرا لأن معظم المشاكل مع حل قابلية الوصول العالية هذا تنبع من قفل الملفات غير الدقيق على مستوى نظام التشغيل، قدم مجتمع ActiveMQ مفهوم خزانة تخزين قابلة للتوصيل في الإصدار 5.7 من الوسيط. يسمح هذا الأسلوب للمستخدم بالاستفادة من وسيلة مختلفة من التأمين المشترك، باستخدام تأمين قاعدة بيانات JDBC على مستوى الصف بدلا من تأمين نظام الملفات على مستوى نظام التشغيل. للحصول على الدعم أو الاستشارات حول بنيات وتوزيعات ActiveMQ HA، يجب عليك الاتصال ب OpenLogic بواسطة Perforce.

أقوم بتشغيل Apache ActiveMQ مع LevelDB أو KahaDB على Azure NetApp Files. ما الاحتياطات التي يمكنني اتخاذها لتجنب الاضطرابات بسبب أحداث صيانة خدمة التخزين على الرغم من استخدام بروتوكول SMB ؟

توصية الصناعة العامة هي عدم تشغيل تخزين KahaDB المشترك على CIFS [Common Internet File System]/SMB. إذا كنت تواجه مشكلة في الحفاظ على حالة تأمين دقيقة، فراجع JDBC Pluggable Storage Locker، والذي يمكن أن يوفر آلية تأمين أكثر موثوقية. للحصول على الدعم أو الاستشارات حول بنيات وتوزيعات ActiveMQ HA، يجب عليك الاتصال ب OpenLogic بواسطة Perforce.

أنا أقوم بتشغيل Boomi على Azure NetApp Files. ما هي الاحتياطات التي يمكنني اتخاذها لتجنب الاضطرابات بسبب أحداث صيانة خدمة التخزين؟

إذا كنت تقوم بتشغيل Boomi، فمن المستحسن اتباع أفضل ممارسات Boomi لتوافر وقت التشغيل العالي والتعافي من الكوارث.

توصي Boomi باستخدام جزيء Boomi لتنفيذ قابلية وصول عالية ل Boomi Atom. حالة متطلبات نظام Boomi Molecule أنه يمكن استخدام إما NFS مع تمكين تأمين NFS (دعم NLM) أو مشاركات ملفات SMB. في سياق Azure NetApp Files، تحتوي وحدات التخزين NFSv4.1 على دعم NLM.

توصي Boomi باستخدام مشاركة ملف SMB مع أجهزة Windows الظاهرية؛ بالنسبة إلى NFS، توصي Boomi ب Linux VMs.

إشعار

مشاركات التوفر المستمر لملفات Azure NetApp غير مدعومة مع Boomi.

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