يرغب العديد من العملاء الجدد عند بدء استخدام CloudSigma في اختبار الأداء؛ وغالبًا ما يتطلعون إلى قياس نتائج الأداء بين الخوادم السحابية وبنيتهم التحتية الخاصة، وهذا أمر منطقي. إن مقارنة الأسعار المباشرة حسب الموارد لا تروي القصة كاملة على الإطلاق؛ فما يهم حقًا هو النتيجة النهائية، كم تبلغ تكلفة إنجاز مهمة حوسبة معينة؟
بالنسبة لأي متطلب معين، قد يختلف عدد الموارد اللازمة لتحقيقه بشكل كبير بين السحب المختلفة. وهذا يعني أن مقارنة الأسعار فقط لا تجدي نفعًا. والجانب الآخر هو أن مقارنة الأداء بمعزل عن العوامل الأخرى ليست أفضل حالاً. تحتاج المقارنات الهادفة إلى الجمع بين السعر والأداء معًا لحساب مقياس ما للتكلفة لكل وحدة حوسبة. في هذه المشاركة، سأشارك بعض أفكاري حول قياس أداء خوادمنا السحابية وغيرها. سأقدم أيضًا بعض النصائح للحصول على نتائج مفيدة وما تعنيه حقًا.
تحذيرات صحية
للتوضيح مقدمًا، أنا متشكك تمامًا بشأن اختبارات قياس الأداء بشكل عام. فهي نادرًا ما تقدم نظرة حقيقية على الاستخدام الفعلي في الواقع. باختصار، لا يوجد بديل حقيقي لتشغيل التطبيقات الفعلية التي تنوي استخدامها على المنصة. إذا كان بإمكانك تحقيق ذلك بتكلفة معقولة من حيث الوقت، فلا يوجد بديل لمثل هذه التجربة.
هناك عامل آخر وهو مدى انشغال مزود الخدمة السحابية. قد تقوم بقياس أداء الخوادم السحابية وتحصل على نتائج ممتازة. ومع ذلك، قد يرجع ذلك إلى حد كبير إلى مستوى الاستخدام (أو عدم وجوده) لدى هذا المزود بالذات. قد لا يكون هذا علامة إيجابية؛ فقد يعكس صعوبات في التشغيل، أو خسارة عملاء، أو مشكلات سابقة تتعلق بالتوفر والموثوقية، وما إلى ذلك. لذلك، يجب عليك دائمًا البحث في تاريخ مزود السحابة بحثًا عن حالات انقطاع الخدمة السابقة وغيرها من المشكلات المحتملة عند تفسير نتائج قياس الأداء الخاصة به.
كتحذير صحي أخير، لا يعد الأداء العامل الوحيد الذي يجب عليك مراعاته. فغالباً ما يعكس الأداء المنخفض بنية عتادية أكثر قوة (واحتياطية) تعتمد عليها السحابة. لذلك، من المهم دائمًا أن يكون لديك فهم واضح جدًا للبنية التحتية التي بُنيت عليها السحابة. وبالتالي، يمكنك مقارنة النتائج بشكل عادل مما يتيح لك اتخاذ قرار شراء مدروس.
تحديد المشكلة
لاحقًا في هذه المشاركة، سأعرض الجوانب المختلفة للأداء وأفضل السبل لتفسير النتائج. ومع ذلك، قبل إجراء أي قياس للأداء، من المهم تحديد طبيعة الحوسبة التي تتطلع إلى القيام بها في السحابة؛ فهذا سيحدد الأهمية النسبية لمقاييس الأداء المختلفة. على سبيل المثال، إذا كنت تتطلع إلى وضع خادم قاعدة بيانات وسيكون تحت ضغط قراءة كثيف ولكن وصول كتابة منخفض، فيجب عليك الانتباه إلى أداء القرص في السحابة وخاصة الوصول غير المتسلسل للقراءة.
لذا، قبل البدء في قياس أداء أي خوادم سحابية، حدد فعليًا ما تعتبره أداءً جيدًا من السحابة. يجب عليك تحديد الجوانب الرئيسية والتي لها تأثير كبير وغير متناسب على الأداء الفعلي لحوسبتك في الواقع. بمجرد أن تكون لديك فكرة واضحة عن ذلك، ستكون في وضع يسمح لك بالبدء في النظر في قياس الأداء.
الأداء الحوسبي
عندما ننظر إلى الأداء الحوسبي الخام، فإننا نتحدث عن CPU و RAM. إن الاختلافات في الأداء على المستوى الحوسبي البحت بين السحب ليست كبيرة في الواقع. ومع ذلك، هناك بعض العوامل التي تسبب الاختلافات الحقيقية.
إن العامل الأكبر على الإطلاق الذي يؤثر على الأداء الحوسبي في السحابة هو التنازع. السحب العامة هي بيئات متعددة المستأجرين. لا يمكن في الواقع الإفراط في تخصيص RAM والتخزين (على الرغم من إمكانية بيعها بشكل زائد)، ولكن يمكن الإفراط في تخصيص CPU وهو ما يحدث بالفعل. تختلف مستويات التنازع بشكل كبير، ولكن بائعو السحابة العامة قادرون أساسًا على بيع سعة CPU للمضيف الفعلي بنسبة تزيد عن 100%.
يستخدم بعض أكبر البائعين نسب تنازع لوحدة المعالجة المركزية (CPU) تزيد عن ثلاث مرات. وهذا يعني أن إجمالي سعة وحدة المعالجة المركزية ‘المباعة’ لجميع الخوادم الافتراضية على نفس الجهاز الفعلي قد تكون ثلاثة أضعاف سعة وحدة المعالجة المركزية الفعلية الخاصة به. وهم يفعلون ذلك لأن معظم الخوادم الافتراضية لا تستخدم ما يقرب من 100% من تخصيص وحدة المعالجة المركزية الخاصة بها في معظم الأوقات. ومع ذلك، فإن نسب التنازع ستؤثر بشكل مباشر على معايير أداء الخوادم السحابية والاستخدام الفعلي. وإذا كان التنازع مرتفعًا (أي عند أي شيء يزيد عن 200% من تخصيص وحدة المعالجة المركزية)، فإن أداء الخادم السحابي سيتدهور بشكل كبير.
ببساطة، إذا تجاوز الحمل على أي جهاز فعلي 1 لكل نواة، فسيتم وضع المهام الحسابية في قائمة الانتظار وسيكون الوقت الذي يستغرقه هذا الجهاز الافتراضي لإكمال المهمة أطول. ونظرًا لأن معظم السحابات تفرض رسومًا على أساس السعة/الساعة، فإن هذا له تأثير مباشر على التكلفة بالنسبة لعملاء تلك السحابة.
العامل المهم الآخر الذي يؤثر على الأداء الحسابي هو عدد نوى وحدة المعالجة المركزية (CPU) التي يمكن للجهاز الافتراضي الوصول إليها. هذا ليس عاملًا لجميع التطبيقات ولكن العديد من التطبيقات الحديثة تدعم تعدد الخيوط. ويعني هذا فعليًا أن التطبيق و/أو نظام التشغيل قادر على توزيع المهام الحسابية على نوى متعددة. إحدى النصائح الرائعة لتحسين أداء الحوسبة لديك هي مطابقة عدد الخيوط (أي النوى) التي يمكن للتطبيق دعمها مع عدد النوى التي يمكن للجهاز الافتراضي الوصول إليها.
للأسف، هذا ليس ممكنًا مع العديد من السحابات العامة. وذلك لأن منصات المحاكاة الافتراضية الخاصة بها لا تدعم المحاكاة الافتراضية على مستوى نواة وحدة المعالجة المركزية. وبعبارة أخرى، لا يمكن استخدام كل نواة إلا من قبل جهاز افتراضي واحد في كل مرة. في السحابات التي تدعم المحاكاة الافتراضية لنوى وحدة المعالجة المركزية، يجب عليك تجربة تغيير عدد النوى لهذا الجهاز مع الحفاظ على الحجم الإجمالي لوحدة المعالجة المركزية كما هو.
على سبيل المثال، إذا كان لديك جهاز بسرعة 2 جيجاهرتز، فيمكنك معرفة كيف يؤثر مضاعفة النوى المستخدمة من اثنتين إلى أربع على قياس الأداء الخاص بك. ومن خلال القيام بذلك، ستتمكن التطبيقات التي تعمل على ذلك الجهاز الافتراضي من تنفيذ المهام عبر أربع نوى في وقت واحد. في حالتنا، يمكنك تعيين عدد النوى التي يستخدمها الجهاز الافتراضي عبر علامة التبويب ‘advanced’ في نافذة تفاصيل الخادم الخاصة بنا على وحدة تحكم الويب. تذكر فقط أن تتحقق دائمًا من حجم النواة القياسي لموفر السحابة قبل الكتابة فوق عدد النوى المستخدمة يدويًا. في حالتنا، يبلغ 2.2 جيجاهرتز لكل نواة ولكنه يختلف من سحابة إلى أخرى.
أوصي بالتفكير في استخدام POV-RAY, CoreMark, Dhrystone أو Whetstone لقياس أداء الخوادم السحابية.
التخزين: المعيار الحقيقي لأداء الخوادم السحابية
كل الأداء محدود بالحلقة الأضعف حيث تنشأ نقطة الاختناق. في الوقت الحالي، تقدمت التكنولوجيا بشكل كبير في مجال المحاكاة الافتراضية فيما يتعلق باستخدام وحدة المعالجة المركزية (CPU) وذاكرة الوصول العشوائي (RAM). على سبيل المثال، يمكن تحويل جهاز فعلي واحد إلى بيئة افتراضية ويحتوي على خوادم سحابية متعددة مع حد أدنى من الخسارة في الأداء الإجمالي التراكمي. للأسف في حالة التخزين، لا يزال هناك الكثير من التقدم الذي يتعين إحرازه. والنتيجة النهائية هي أنه في معظم الحالات، يتم تحديد أداء الخوادم الافتراضية في السحابة من خلال أداء حل التخزين الخاص بتلك السحابة.
باختصار، يعد التخزين حاليًا هو العامل المحدد لأداء معظم المهام الحسابية في السحابة. ومهما كانت النتائج التي قد ينتجها pov-ray وغيره من أدوات قياس الأداء للمهام الحسابية البحتة، فإن الحقيقة هي أن السرعة التي يمكن بها للخادم الافتراضي استرداد البيانات وكتابتها على أقراص التخزين الفعلية ستحدد الأداء الفعلي للخادم السحابي حاليًا.
ومع أخذ ذلك في الاعتبار، فإن الاختلافات الحقيقية التي تظهر في الأداء في السحابة، حتى فيما يتعلق بالمهام الحسابية، تميل إلى أن تنبع من الاختلافات في أداء التخزين. وكما ذكرنا سابقًا في هذا المنشور، هناك احتياجات مختلفة تمامًا للعملاء اعتمادًا على المهمة الحسابية. ولا ينطبق هذا على أي شيء أكثر مما ينطبق على التخزين. هل تحتاج إلى وصول سريع للقراءة إلى مجموعات متتالية كبيرة من البيانات (مثل بث الوسائط) أو إلى قطع صغيرة متفرقة من المعلومات (ربما في قاعدة بيانات كبيرة)؟ هل تحتاج إلى الحفاظ على وصول كثيف للكتابة للبيانات سريعة التغير والتي يتم الوصول إليها بشكل دوري في دفعات كبيرة؟ هناك سيناريوهات عديدة وسيعمل كل منها بشكل مختلف على نفس النظام الأساسي.
من الناحية الأساسية، تعود الاختلافات في الأداء إلى البنية المعمارية. وعادة ما تنتج تلك الاختلافات في البنية المعمارية عن درجات متفاوتة من المتانة فيما يتعلق بتخزين البيانات، وتكرارها، وبالتالي احتمالية فقدانها بشكل لا يمكن إصلاحه. وعلى مستوى عالٍ، تستخدم السحابات إما حلول بيانات مركزية في شكل شبكة منطقة التخزين (SAN) أو حلول تخزين محلية أكثر توزيعًا. وفي هذه الحلول، يقع التخزين على كل جهاز مادي فردي.
تتمتع شبكات SAN الجيدة بطبيعتها بمستوى عالٍ من التكرار المدمج. ومع ذلك، يتأثر الأداء نظرًا لأن البيانات تحتاج إلى إرسالها من شبكة SAN عبر الشبكة إلى وحدة المعالجة المركزية وذاكرة الوصول العشوائي الخاصة بالجهاز الافتراضي لمهام الحوسبة. ونتيجة لذلك، تميل السحابات القائمة على SAN إلى تقديم أداء أقل مقارنة بالسحابات التي تحتوي على حلول تخزين موزعة محلية. وهناك عيب آخر لشبكة SAN وهو أنها تمثل نقطة فشل فردية كبيرة جدًا. إن شبكات SAN موثوقة للغاية. وإذا حدث بها خطأ جسيم (وقد حدث بالفعل)، فمن المرجح أن تواجه انقطاعًا كبيرًا جدًا وتلفًا في البيانات.
لا يستخدم معظم موفري السحابة الذين يستخدمون شبكات SAN حلول تجاوز الفشل المتكررة بالكامل من النوع المستخدم في بيئة المؤسسات، ويرجع ذلك إلى حد كبير لأسباب تتعلق بالتكلفة. ومن المهم إدراك أن شبكات SAN ليست كلها متساوية، وفهم مستوى التكرار الذي يستخدمه موفر السحابة مع شبكات SAN الخاصة به.
تميل السحابات القائمة على التخزين المحلي إلى تقديم أداء جيد للأقراص. ومع ذلك، غالبًا ما تقدم تخزينًا محليًا في شكل غير مستمر فقط. هذا ليس مقارنة عادلة بالتخزين المستمر. لا يجب أن يكون التخزين المؤقت قويًا ضد الأعطال بنفس طريقة التخزين الدائم. من المهم دائمًا مقارنة التخزين المستمر بالتخزين المستمر للحصول على نتائج ذات مغزى.
عند النظر إلى السحابات التي تحتوي على حلول تخزين محلية موزعة، تحتاج أيضًا إلى معرفة نوع التكرار الذي لديها. تفشل محركات الأقراص الثابتة بمعدل كبير، وبالتالي فإن طريقة التخزين أمر بالغ الأهمية. يستخدم معظم الموفرين شكلًا من أشكال RAID ولكن هناك مستويات مختلفة تمامًا من الأمان. في الحد الأدنى، لديك RAID1 حيث يقوم قرصان بمرآة بعضهما البعض بشكل أساسي. وعادة ما يتمتع هذا بأداء جيد. ولكن عندما يفشل قرص واحد حتى يقوم القرص البديل بنسخ جميع البيانات من القرص القديم، تكون البيانات عرضة لخطر الفقدان الكامل إذا فشل القرص الثاني (المحمل بشكل كبير). أيضًا، أثناء أي إعادة بناء لمصفوفة RAID1، من المرجح أن يكون أداء القرص أقل بكثير من المعتاد.
لذلك، يستخدم العديد من الموفرين RAID5 (المرن تجاه فشل قرص واحد) أو RAID6 (المرن تجاه فشل قرصين). يقدم RAID6 الحل الأكثر أمانًا على الإطلاق للتخزين المحلي ولكنه يتطلب ضريبة كبيرة على الأداء. نهجنا هو استخدام RAID6 ولكن مع دمجه مع بطاقات تحكم RAID للأجهزة من الفئة الأولى. وهي تحتوي على ذاكرة تخزين مؤقت كبيرة ومدعومة ببطارية. إن بطاقات تحكم RAID التي نستخدمها هي في الواقع أغلى بكثير من مصفوفات الأقراص بأكملها. وبالتالي، يمكننا تقديم أداء مماثل للإعدادات الأقل مرونة بكثير مع الاستمرار في تقديم شبكة الأمان الكبيرة جدًا لتخزين RAID6. اقرأ المزيد عن البنية التحتية السحابية الخاصة بنا والتي نتعامل معها بشفافية تامة.
أوصي باستخدام IOzone أو Bonnie++ لاختبارات أداء القرص.
لذا، عند تفسير نتائج اختبارات أداء التخزين، تأكد من حصولك أيضًا على المعلومات التالية:
- ما هي بنية التخزين التي تستخدمها السحابة (محلي، SAN، أو غير ذلك)؟
- ما هي تدابير تجاوز الفشل والتكرار المطبقة على البيانات؟
- هل التخزين الذي أقوم باختبار أدائه مؤقت أم دائم؟
إن وضع الإجابات على هذه الأسئلة الثلاثة معًا مع نتائج اختبار الأداء سيمنحك نظرة ثاقبة جيدة إلى حد ما حول أداء التخزين الفعلي.
الشبكات
إن تحديد وقياس أداء الشبكات هو أمر أكثر وضوحًا بكثير من أداء الحوسبة والأقراص. ويشتمل أداء الشبكات على جانبين رئيسيين، هما زمن الاستجابة وعرض النطاق الترددي.
اعتمادًا على احتياجاتك، قد يكون زمن استجابة الشبكة التي يستخدمها موفر الخدمة السحابية مهمًا أو غير مهم. إذا كنت تستخدم السحابة لعمليات قائمة بذاتها إلى حد كبير، فمن غير المرجح أن يكون زمن الاستجابة أولوية. أما إذا كنت تقوم بتشغيل تطبيقات في الوقت الفعلي تتفاعل مع العالم خارج السحابة، فإن زمن الاستجابة سيكون محددًا حاسمًا للأداء.
عادةً ما ينتج الغالبية العظمى من زمن الاستجابة عن المسافة المادية البحتة. على سبيل المثال، معظم زمن الاستجابة بين لندن وسان فرانسيسكو هو في الواقع الوقت الذي يستغرقه الضوء لقطع تلك المسافة. وتتحدد الاختلافات في زمن الاستجابة من خلال الكفاءة المتفاوتة للمسار المتخذ. هذا هو الجانب الذي يختلف من سحابة إلى أخرى. وتعد كفاءة المسار نتيجة مباشرة لمزودي الشبكة الذين تمتلك السحابة اتصالات مباشرة بهم. ويحدث هذا إما عن طريق الحصول على اتصال IP منهم أو من خلال التناظر. عند النظر في زمن الاستجابة، يمكنك ببساطة عمل ping لخادمك السحابي وتحديد أدائه. ومع ذلك، من المهم تحديد الأداء بين المستخدمين النهائيين الفعليين وخادمك السحابي.
إذا كان معظم مستخدميك يتواجدون في منطقة جغرافية واحدة أو كان الوصول يتم بشكل أساسي من المكتب الرئيسي لشركتك، فمن المهم اختبار الأداء من تلك المواقع. تقدم الخدمات التجارية مثل Pingdom طريقة فعالة من حيث التكلفة لتحديد زمن الاستجابة من عدد كبير من المواقع العامة في وقت واحد بجميع أنحاء العالم.
إن عرض النطاق الترددي الفعلي الذي يمكن لخادمك السحابي تحقيقه هو أمر مهم للغاية أيضًا. وعلى عكس حلول الاستضافة التقليدية، يميل موفرو الخدمات السحابية إلى فرض رسوم تتناسب مع الحجم الإجمالي لنقل البيانات. وبعبارة أخرى، لا يعتمد الأمر على الوقت كما هو الحال في طريقة الدفع لكل ميجابت والتي توفر لك مستوى ثابتًا من الاتصال على مدار الساعة طوال أيام الأسبوع. وعلى الرغم من ذلك، فإن العديد من موفري الخدمات السحابية سيقومون بـ ‘خنق’ عرض النطاق الترددي لأي خادم افتراضي. وسيكون هذا غير مرئي للمستخدم حتى تصطدم بهذا الحاجز. وإذا كان لديك نمط عرض نطاق ترددي متذبذب للغاية، فقد يكون هذا عامل أداء مهمًا يجب أخذه في الاعتبار.
لاختبار عرض النطاق الترددي الفعلي لخادمك السحابي، من المهم محاولة تنزيل البيانات إلى الخادم السحابي من مصدر لا يفرض قيودًا على معدل النقل من جانبه. وغالبًا ما أجد أن الطريقة الرائعة لتحديد السرعة المتاحة هي تنزيل ملف كبير من جهة رئيسية مثل Microsoft, Ubuntu أو الأفضل من ذلك عن طريق تحديث نظام التشغيل. يميل هذا إلى تنزيل العديد من الملفات المختلفة من مواقع مختلفة في وقت واحد. وسيعطيك ذلك انطباعًا جيدًا عن سرعة اتصالك.
غالبًا ما أقوم بتنزيل Fedora live CD من موقعهم الرئيسي كاختبار قياسي، ولكن يجب عليك دائمًا تجربة بعض الملفات والمواقع المختلفة كحد أدنى. إذا كنت تصر على امتلاك شبكة شركات سريعة جدًا خاصة بك، فقد ترغب في تنزيل ملف من خادمك السحابي إلى شبكتك الخاصة كاختبار بدلاً من ذلك.
الآن أعد إضافة التسعير لوزن النتائج
باستخدام الطرق المذكورة أعلاه، يجب أن تكون قادرًا على الحصول على فكرة جيدة عن كيفية أداء مختلف موفري الخوادم السحابية. علاوة على ذلك، يجب أن تعرف الجوانب التي يجب التركيز عليها والتي تعد الأكثر أهمية لاحتياجاتك الخاصة.
الخطوة الأخيرة هي إضافة بُعد التسعير إلى نتائج اختبار الأداء. لا توجد صيغة محددة لهذا الأمر. فهو يعتمد على الأداء النسبي لمختلف الجوانب المذكورة أعلاه، وأنت من يحددها. إذا كانت إحدى السحابات تقدم أداءً أفضل بنسبة 40% (وفقًا لتقديرك) ولكنها أغلى بنسبة 30% فقط، فمن الواضح أنها تبدو جذابة. وبالمثل، إذا كانت لديك حاجة كبيرة لنطاق التردد التراسلي، فقد يتفوق عرض تسعير تنافسي لنقل البيانات على الأداء الحوسبي المنخفض. والمفتاح لاتخاذ القرار الصحيح هو مراعاة جميع العوامل المختلفة معًا.
أخيرًا، يجب أن يكون اختبار الأداء جزءًا من عملية أكبر لتحديد خوادم السحابة المناسبة لك. ويجب أن يشمل هذا جوانب أخرى. على سبيل المثال، يمكن أن تشمل هذه الجوانب اتفاقيات مستوى الخدمة، واعتبارات الارتباط بالبيانات/المورد، والموقع الجغرافي، والولاية القضائية القانونية. ومن خلال جمع كل هذه الجوانب معًا، ستضع’ نفسك في موقف يسمح لك باتخاذ القرار الصحيح بشأن اختيار مورد الحوسبة السحابية.
التعليقات
لا توجد تعليقات بعد. كن أول من يعلق.