تحديات السحابة: قابلية التوسع
- 7 دقائق
إن تصميم برنامج موزع وتنفيذه ينطوي، كما رأينا، على اختيار نموذج البرمجة ومعالجة مشكلات التزامن، والتوازي، والبنية. وبالإضافة إلى هذه الأمور، عند تطوير برامج السحابة، يجب على المصمم أيضاً إيلاء اهتمام دقيق للعديد من التحديات الأخرى الحاسمة للبيئات السحابية. نحن سنناقش بعد ذلك التحديات المرتبطة بقابلية التوسع، والاتصال، وعدم التجانس، والمزامنة، والتسامح مع الخطأ، والجدولة.
قابلية التوسع
يمكن اعتبار أي برنامج موزع قابلاً للتوسع إذا كان لا يزال فعالاً عندما تزيد كميات المستخدمين والبيانات والموارد زيادة كبيرة. وللحصول على فكرة عن نطاق المشكلة، فكر في العديد من التطبيقات والمنصات الشائعة المقدمة حالياً لملايين المستخدمين في صورة الخدمات القائمة على الإنترنت. إلى جانب بعد البيانات، في هذا الوقت من البيانات الضخمة و"عصر التيرا" (عبارة Intel)،1 تتكيف البرامج الموزعة عادةً مع البيانات على نطاق الويب بما يصل إلى المئات أو الآلاف من غيغابايت، أو تيرابايت، أو بيتابايت. وعلى الصعيد العالمي، في عام 2010، أنتجت مصادر البيانات حوالي 1.2 زيتابايت (1.2 مليون بيتابايت)، وتتوقع التنبؤات لعام 2020 زيادة بنحو 44 مرة عن هذا القدر.2 وتعالج خدمات الإنترنت، مثل التجارة الإلكترونية والشبكات الاجتماعية، أحجام البيانات التي ينتجها الملايين من المستخدمين يومياً. وفيما يتعلق بالموارد، تستضيف مراكز البيانات السحابية بالفعل عشرات إلى مئات الآلاف من الأجهزة. وتتوقع التصورات حدوث تحجيم آخر متعدد الأوجه لعدد الأجهزة.
إن حقيقة التنفيذ على n من العقد لا يلبي أبداً الصورة المثالية لتصاعد الأداء n من المرات. وتتدخل عدة أسباب في ذلك:
- كما هو موضح في الشكل 13، لا يمكن أبداً أن تكون بعض أجزاء البرنامج موازية (على سبيل المثال، التهيئة).
- من المرجح جداً وجود عدم موازنة التحميل بين المهام، لا سيما في النظم الموزعة، مثل السحب، حيث يشكل فيها عدم التجانس عاملاً رئيسياً. وكما هو موضح في الشكل 13 (ب)، عادةً ما يؤخر عدم موازنة التحميل البرامج بحيث يصبح البرنامج مقيداً بأبطأ مهمة. وبوجه خاص، حتى مع انتهاء جميع المهام في أي برنامج، لا يمكن تثبيت البرنامج قبل انتهاء المهمة الأخيرة.
- النفقات الكبيرة الأخرى، مثل نفقات الاتصال والمزامنة، يمكن أن تعوق قابلية التوسع بشكل كبير.
الشكل 13: الإسراع المتوازي: (أ) حالة مثالية و(ب) حالة حقيقية
هذه المسائل مهمة عند مقارنة أداء البرامج الموزعة والمتسلسلة. وهناك تعبير واسع الاستخدام يصف السرعات، إلى جانب، حسابات المصاريف العامة المختلفة، وهو قانون أمدال. لتوضيح الحساب، نفترض أن إصداراً متسلسلاً من برنامج، $T$، يستغرق $T_{s}$ وحدة زمنية، بينما يستغرق إصدار مواز/موزع $T_{p}$ وحدة زمنية باستخدام مجموعة من العقد $n$. وبالإضافة إلى ذلك، فإننا نفترض أن كسر $f$ من البرنامج ليس قابلاً للتوازي، مما يترك الجزء $(1–f)$ قابلاً للتوازي. ووفقاً لقانون أمدال، يمكن تعريف سرعة التنفيذ الموازي/الموزع لـ $P$ مقابل التنفيذ المتسلسل على النحو التالي:
$$ Speedup_{p} = \frac {T_{s}}{T_{p}} = \frac {T_{s}}{T_{s} \times {f + T_{s}} \times \frac {1 - f}{n}} = \frac{1} {f + \frac {1 - f}{n}} $$
على الرغم من أن الصيغة تبدو بسيطة، إلا أنها تعرض دلالة حاسمة: إذا افترضنا وجود مجموعة مع عدد غير محدود من الأجهزة وثابت $s$، يمكننا التعبير عن أقصى سرعة قابلة للتحقيق ببساطة عن طريق حساب إسراع $P$ مع عدد لا نهائي من المعالجات على النحو التالي:
$$ \lim_{n\to\infty} Speedup_{p} = \lim_{n\to\infty} \frac{1}{f + \frac{1 - f}{n}} = \frac{1} {f} $$
لفهم جوهر هذا التحليل، دعونا نفترض وجود كسر تسلسلي $f$ بنسبة 2٪ فقط. عند تطبيق الصيغة مع، مثلاً، عدد غير محدود من الأجهزة سيؤدي إلى حد أقصى من الإسراع يبلغ 50 فقط. وتخفيض $f$ إلى 0.5٪ من شأنه أن يؤدي إلى حد أقصى من الإسراع يبلغ 200. وبالتالي، نلاحظ أن تحقيق قابلية التوسع في الأنظمة الموزعة أمر صعب للغاية لأنه يتطلب أن يكون $f$ تقريباً 0، ويتجاهل هذا التحليل آثار النفقات الناتجة عن عدم موازنة التحميل، والمزامنة، والاتصال. وعند الممارسة العملية، تزداد النفقات العامة للمزامنة (مثل إجراء مزامنة الحواجز والحصول على الأقفال) مع زيادة عدد الأجهزة، وغالباً ما تكون فوق خطية.3 كما تزداد النفقات العامة للاتصالات أيضاً بشكل كبير في الأنظمة الموزعة كبيرة النطاق لأن جميع الأجهزة لا يمكن أن تشترك في اتصالات مادية قصيرة. ويصبح عدم موازنة التحميل عاملاً كبيراً في البيئات غير المتجانسة، كما نناقش قريباً. وعلى الرغم من صعوبة ذلك حقاً، ولكننا نود الإشارة إلى أنه مع بيانات الإدخال على نطاق الويب، يمكن أن تقل النفقات العامة للمزامنة والاتصالات بشكل كبير إذا كانت تسهم بدرجة أقل بكثير نحو وقت التنفيذ الكلي مما يفعل الحساب. ولحسن الحظ، مع العديد من تطبيقات البيانات الضخمة، فإن هذا الوضع الأخير هو الحال.
المراجع
- S. تشن وس. و. شلوسر (2008). MapReduce يلبي مجموعة متنوعة من التطبيقات IRP-TR-08-05، أبحاث Intel
- إم. زاهاريا ، أ. كونوينسكي ، أ. جوزيف ، ر. كاتز ، وآي ستويكا (2008). تحسين أداء MapReduce في البيئات غير المتجانسة OSDI
- ي. صليحين (2009). أساسيات هندسة الكمبيوتر المتوازية كتب Solihin
اختبر معلوماتك
الملاحظات
هل كانت هذه الصفحة مفيدة؟
لا
هل تحتاج إلى مساعدة مع هذا الموضوع؟
هل تريد محاولة استخدام Ask Learn لتوضيح هذا الموضوع أو إرشادك خلاله؟