تطـــويـر الـتطــبيـقـات المــوزّعــة المــوثـوقـة والقــابــلـة للتـجــزئــة بـاســتـخـدام Jgroup/ARM

الملخص

يتطلّب الاعتماد المتزايد على الأنظمة الشبكية في النشاطات اليومية تزويدها لخدمات متوفّرة وموثوقة. تزوّد Jgroup خدمة متوفّرة من خلال إنشائها نسخ (Replicas) متعددة من الخدمة نفسها وتوزيعها على أجهزة متعددة, بينما تحقّق الموثوقية من خلال سماحها لنسخ الخدمة بالحفاظ على الحالة المشتركة فيما بينها وتنسيق نشاطاتها باستخدام تقنية استدعاء الطريقة البعيدة (Remote Method Invocation). خلافاً لـJgroup, تستخدم JavaGroups تقنية تمرير الرسائل (Message Passing) لتحقيق التنسيق بين النسخ. تقارن هذه المقالة بين أداءي استدعاء طريقة المجموعة في Jgroup بنوعيه الوحيد (anycast) والمتعدّد (multicast) واستدعاء الطريقة في JavaGroups بنوعيه طريقة الحصول على أول إجابة (GET_FIRST) وطريقة الحصول على جميع الإجابات (GET_ALL). تحسّن هذه المقالة أيضاً من أداء منصّة العمل ARM (Autonomous Replication Management) المدمجة مع Jgroup (Jgroup/ARM) لزيادة دعمها مع التسامح مع الخطأ؛ من خلال إيجاد حل أفضل لمعالجة مشكلة تعطّل كامل أعضاء نسخ الخدمة في تعاقب سريع. تتميز الآلية الجديدة بقيام نسخة واحدة فقط (النسخة القائدة) بإرسال حدث التجديد بدلاً من قيام كل نسخ الخدمة بإرسال هذا الحدث؛ مع محافظتها على الزمن اللازم لاكتشاف حالة التعطّل من قبل مدير النسخ (Replication Manager). تُظهر نتائج المقارنة بين Jgroup وJavaGroups تفوّق الثانية عند وجود نسخة خدمة واحدة, بينما يتفوّق أداء الاستدعاء في Jgroup على JavaGroups مع تزايد عدد نسخ الخدمة. تظهر النتائج أيضاً تزايد ملحوظ في زمن الاستدعاء في JavaGroups مع تزايد حجم المصفوفة الممررة إلى الطريقة المستدعاة. الأمر الذي يجعل JavaGroups غير مناسبة للتطبيقات التي تتطلب نقلاً لحجوم كبيرة من البيانات وعدداً كبيراً من المخدمات, بينما تعتبر Jgroup مناسبة لذلك. تبين نتائج تقييم أداء الحل المقترح بأنّه يخفّض عدد أحداث التجديد المرسلة مقارنةً مع حل ميلينغ تصل في حدّها الأعظمي إلى 37.5%, وتستغرق Jgroup/ARM الفترة الزمنية نفسها التي يتطلّبها الحل السابق لاكتشاف تعطّل المجموعة بكاملها. The increasing reliance on network systems in day-to-day activities requires that they provide available and reliable services. Jgroup provides available service through creating multiple replicas of the same service on multiple devices. Jgroup achieves reliable service by maintaining the shared state between the replicas and coordinating their activities through Remote Method Invocation. Unlike Jgroup, JavaGroups uses message passing to implement coordination between the replicas. In this paper, we compare Jgroup and JavaGroups for different Group Method Invocation modes. These modes are Anycast and Multicast in Jgroup, GET_FIRST and GET_ALL in JavaGroups. This paper also improves the performance of ARM (Autonomous Replication Management) which is embedded with Jgroup (Jgroup/ARM) for supporting fault tolerance, through finding a new solution to handle group failure where all remaining replicas fail in rapid succession. In this new solution, only one replica (the group leader) issues renew events (IamAlive) periodically, instead of sending it by every replica in the group, with taking the same period to discover group failure by Replication Manager. Results of Comparison show that JavaGroups is faster than Jgroup when a single replica is used, whereas Jgroup outperforms JavaGroups with increasing number of replicas. The invocation delay in JavaGroups increases noticeably with increasing the size of array passed into the invoked method which make JavaGroups unsuitable for applications which require exchanging big sizes of data and use large number of servers, whereas Jgroup is suitable for that. Results show that the new proposal reduces the number of renew events to 37.5% at most, and Jgroup/ARM takes approximately the same period of time to discover group failure as in Meling solution.