ما هي القيود العملية مع تحجيم السيارات EC2 أو غيرها من البنية التحتية للحوسبة السحابية؟

Question

كنت فضوليا إذا قام أي شخص بتجربة الويب التقليدية أو الطبقة DB في EC2 أو البنية التحتية السحابية السحابية الأخرى؟ يبدو من الناحية النظرية، لكنني فضولي ما هي القيود العملية / ربما.

شكرا!

Answer 1

نحن أيضا بدأنا في النظر إلى التحجيم التلقائي.

تتمثل نهج المرشح الأول في استخدام ELB Amazon's ELB (موازن التحميل المرن) و الجبهة السحابية. ومع ذلك، فإن حركة المرور لدينا هي خدمة ويب. كثيرا ما ترسل المتصل رسالة HTTP 100 متابعة 100، ولا يمكن أن يفهم ELB هذه الرسالة. لا توجد كلمة بعد من الأمازون عند ذلك قد تكون ثابتة. أيضا، هناك عدد من الشكاوى في منتديات الأمازون حول ELB لا يتعامل مع الحمل الثقيل.

يشبه LightTPD 1.5 كحل جزئي واعد، حيث يمكنه اكتشافه عندما لا يعمل مثيل وإخراجه بشفافية من التناوب، ويمكن إعادة تكوينه ديناميكيا دون إعادة تشغيل موازن التحميل.

هناك عدد من الحلول التجارية كذلك. من المحتمل أن نلقي نظرة على النطاق الصحيح.

Answer 2

هذا هو أكثر سؤالا من الإجابة، لكنني على وشك البدء في تجربة تهدئة نفسي (على الأرجح باستخدام مرافق الأمازون Cloudfront) وأعتقد أن وقت بدء التشغيل سيكون عاملا. لقد لاحظت أن مثيل EC2 الجديد قد يستغرق من 5 إلى 20 دقيقة للبدء، لذلك ليس كما لو أنه يمكنك إضافة سعة أكبر عند زيادة الحمل؛ يبدو أنك ستحتاج إلى حالات أو أكثر من مثيلات الخمول لتشغيلها وعلى استعداد لالتقاط تحميل متزايد.

Answer 3

الإضافة المتأخرة:

النظر في simpleedb كذلك ... هذا من شأنه أن يلغي الجانب القياس DB.

بالنسبة إلى AutoCaling، اتصلنا برامج نصية خاصة بنا لرصد وخوادم التشغيل وتوفيرها ونعم، تستغرق العملية برمتها حوالي 7 دقائق. نحن نقوم بتحليل تنبؤي قليلا لتخمين عندما تكون هناك حاجة إلى خوادم جديدة ثم اقتحمها فقط إذا لم تكن كذلك. التكلفة الإجمالية: ~ 10 سنتات.

أيضا، يبدو SCALR واعدة كحل تجاري (لم تستخدمه).

تشاد