سؤال

أنا أعمل في شركة كبيرة تدير كثير من الخوادم المستندة إلى x86 والتي نقوم بتشغيل JVMs عليها.

لقد جربنا بنجاح برنامج VMWare ESX للحصول على استخدام أفضل لمركز البيانات الخاص بنا.لكن هذه لا تزال تستهلك الكثير من الطاقة لكل وحدة معالجة.

كانت لدي فكرة مجنونة مفادها أنه ينبغي علينا إحياء الحواسيب المركزية، حيث يمكننا استضافة الكثير من أجهزة JVM أو الأجهزة الافتراضية.

هل هناك اي احد جرب هذة؟هل هناك أي فوائد جيدة من حيث التكلفة؟

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

هل كانت مفيدة؟

المحلول

يفترض كل هذا أنك تتحدث عن Java على Z/OS ولا تقوم بتشغيل Linux VM على الحاسوب المركزي للاستفادة من توفير التكاليف الذي يأتي مع عدد أقل من الأجهزة.

أفكاري حول المحاكاة الافتراضية موجودة في نهاية هذا وربما يكون هذا هو المسار الذي تريد إلقاء نظرة عليه ولكنني سأبدأ بـ Z/OS نظرًا لأنه ما ترتبط به الحواسيب المركزية تقليديًا وما أعرفه.لدي بعض الخبرة مع جافا المركزية.

الإجابة المختصرة هي أن ذلك يعتمد، ولكن ربما لا.ما هي تطبيقاتك بالضبط؟يعد الكمبيوتر المركزي بيئة صعبة مقارنة بخوادم x86.إذا كنت تقوم بتشغيل أحمال عمل كثيفة الإدخال/الإخراج ضمن شيء مثل Websphere، فقد يكون الأمر يستحق ذلك، على افتراض أن حاسبك المركزي غير مستغل بشكل كافٍ.

من خلال تجربتي، تعد Java بطيئة للغاية على الحواسيب المركزية، ولكن ذلك لأن النظام الذي استخدمته تم إعداده لمرونة المطورين بدلاً من الأداء.وهذا يثبت أن ضبط الأداء على الحاسوب المركزي عادة ما يكون أكثر تعقيدًا من ذلك على خادم متوسط ​​نظرًا لأن الحواسيب المركزية ستشغل العديد من أعباء العمل أكثر من خادم x86 العام.

تذكر أن الحاسوب المركزي مصمم بشكل أساسي لإنتاجية الإدخال/الإخراج ويمكنه أن يتفوق في الأداء على أي خادم x86 عادي في ذلك الوقت.لم يتم تصميمه لإجراء الكثير من العمليات الحسابية المكثفة، لذا لن يتفوق في الأداء على مجموعة صغيرة من خوادم x86 إذا كنت تقوم بالكثير من العمليات الحسابية.

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

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

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

نصائح أخرى

تقوم شركة IBM بتصنيع معالج مشترك خاص لـ Java والذي يجب أن تفكر فيه بجدية.لن أقوم بتشغيل Java على المحركات العامة لأن ذلك قد يزيد من رسوم MPU للبرامج المرخصة.

لدينا خبرة واسعة في تشغيل Java على أنظمة التشغيل Windows وLinux وعلى أجهزة الكمبيوتر الصغيرة IBM SystemI (أو iSeries أو AS/400، اعتمادًا على مزاج IBM في ذلك العام).من رأيي أن منصة الكمبيوتر المصغر تبدو أنها تقدم قيمة أقل بكثير مقارنة بوحدات المعالجة المركزية الحديثة متعددة النواة x86.

لاحظ أن Java تستفيد بسهولة أكبر من توفر مراكز متعددة مقارنة بالبرامج النموذجية اليوم، نظرًا لطبيعتها متعددة مؤشرات الترابط بطبيعتها - سيكون هذا أكثر صحة عند تشغيل JVMs متعددة.

ومع ذلك، ستكون قادرًا عادةً على الحصول على عدد أكبر من نوى وحدة المعالجة المركزية المتاحة مع عرض نطاق ترددي أفضل للوصول إلى الذاكرة على حاسب صغير أو مركزي، وإنتاجية أفضل على أنظمة القرص الفرعية (بشكل عام) لذلك قد تتوسع هذه الأنظمة بشكل أفضل بكثير عندما تقوم بطرح المزيد من أجهزة JVM عليهم.

آي بي إم تسمح بذلك.يمكن لبعض الحواسيب المركزية الخاصة بهم أن تحتوي على معالجات Java Accelerator التي تقوم بتشغيل الكود الثانوي محليًا لمزيد من الأداء.لديهم أيضًا مسرعات DB2، وربما بعضها لعمليات XML.

لم يسبق لي أن ألعب مع أي منهم، لكني بالتأكيد أحب ذلك.

على الرغم من أنني أعمل في الصناعة منذ عام 1975، إلا أنني لم أعد متأكدًا من معنى "الحاسب المركزي".يحتوي جهاز التطوير الحالي الخاص بي على أربعة معالجات بسرعة 3 جيجاهرتز، وذاكرة وصول عشوائي (RAM) سعة 8 جيجابايت، ومساحة قرص تبلغ 750 جيجابايت (RAID 1، لذا فهو ضعف ذلك بالفعل)، وشاشتين مسطحتين مقاس 19 بوصة.

هذا لأنني هناك بموجب عقد.جميع الموظفين لديهم صناديق أقوى بكثير من صناديقي.

أدرك أن أجهزة الخادم، وخاصة خوادم قواعد البيانات، أسرع بكثير.

الحاسوب المركزي؟

اعتمادًا على عبء العمل لديك، فإن هذا يستحق النظر إليه!

هناك عدد مذهل من الخيارات المتاحة لك فقط باستخدام أجهزة IBM:

  1. من المؤكد أنه يستحق النظر في الإضافة على معالجات جافا.(هذه في الواقع ليست من أشكال مختلفة من وحدات المعالجة المركزية القياسية ، فهي تقتصر على أعباء عمل Java JVM - والأهم من ذلك أنه يتم استبعادها من تسعير ترخيص البرمجيات القائم على وحدة المعالجة المركزية).

  2. يمكنك تشغيل العديد من أجهزة Linux الافتراضية التي يقوم كل منها بتشغيل تطبيق Java الخاص بها.

  3. يمكنك تشغيل عدة VMs الأصلية التي تعمل على تشغيل نظام التشغيل البسيط الذي يستخدم ليتم تسميته DOS ولكنهم يغيرون الاسم كل عامين.تكون تراخيص البرمجيات أرخص من نظام التشغيل الرئيسي ، ولكن لديها وظائف محدودة للغاية والتي تبين أنها ميزة إذا كنت تقوم بتشغيل تطبيقات محتوية على ذاتي.

  4. يمكنك التشغيل في بيئة monster z/OS إما: -

أ.ضمن خدمات نظام USS (UNIX System) التي تعد إلى حد كبير نظام التشغيل UNIX كامل يعمل داخل الأصل z/OS.

ب.قم بتشغيل تطبيق Java الخاص بك في مهمته التي بدأها (== برنامج Unix الخفي).

ج.قم بتشغيل التطبيق الخاص بك داخل CICS.(ربما ليس كما تحتاج إلى استخدام CICS/Java API حيث يمكنك عادة استخدام واجهات برمجة تطبيقات Servlet/J2EE بحيث تتطلب إعادة كتابة.)

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top