تحياتي لمجتمع الهبر! لقد كتبت مؤخرًا عن إصدارنا الأول للوحة الكتلة []. واليوم أريد أن أخبركم كيف عملنا على الإصدار ذاكرة الوصول العشوائي.
نحن مغرمون بالخوادم الصغيرة التي يمكن استخدامها للتنمية المحلية والاستضافة المحلية. على عكس أجهزة الكمبيوتر المكتبية أو أجهزة الكمبيوتر المحمولة ، تم تصميم خوادمنا للعمل على مدار الساعة طوال أيام الأسبوع ، ويمكن دمجها بسرعة ، على سبيل المثال ، كان هناك 24 معالجات في مجموعة ، وبعد 7 دقائق كان هناك 4 معالجًا (بدون معدات شبكة إضافية) وكل هذا في شكل مضغوط عامل صامت وموفر للطاقة.
تعتمد بنية خوادمنا على مبدأ الكتلة للبناء ، أي نصنع لوحات عنقودية تقوم ، باستخدام شبكة إيثرنت على اللوحة ، بتوصيل العديد من وحدات الحوسبة (المعالجات). للتبسيط ، لم نصنع وحدات الحوسبة الخاصة بنا بعد ، ولكننا نستخدم وحدات Raspberry Pi Compute وكنا نأمل حقًا في وحدة CM4 الجديدة. لكن كل شيء سار عكس الخطط مع عامل الشكل الجديد وأعتقد أن الكثيرين أصيبوا بخيبة أمل.
تحت القطع ، كيف انتقلنا من V1 إلى V2 وكيف كان علينا الخروج مع عامل الشكل Raspberry Pi CM4 الجديد.
إذن ، بعد إنشاء مجموعة مكونة من 7 عقد ، فإن الأسئلة هي - ما التالي؟ كيف تزيد من قيمة المنتج؟ 8 أو 10 أو 16 عقدة؟ الشركات المصنعة للوحدة التي؟ بالتفكير في المنتج ككل ، أدركنا أن الشيء الرئيسي هنا ليس عدد العقد أو هوية الشركة المصنعة ، ولكن جوهر المجموعات باعتبارها لبنة أساسية. نحن بحاجة إلى البحث عن الحد الأدنى من لبنة البناء
أول، ستكون كتلة وفي نفس الوقت تكون قادرة على توصيل الأقراص ولوحات التوسع. يجب أن تكون الكتلة العنقودية عقدة أساسية مكتفية ذاتيًا ولها نطاق واسع من خيارات التوسيع.
ثان، بحيث يمكن ربط الحد الأدنى من الكتل العنقودية ببعضها البعض عن طريق بناء مجموعات ذات حجم أكبر بحيث تكون فعالة من حيث الميزانية وسرعة القياس. يجب أن تكون سرعة القياس أسرع من توصيل أجهزة الكمبيوتر العادية بشبكة وأرخص بكثير من أجهزة الخادم.
الثالثيجب أن تكون وحدات الكتلة الدنيا مدمجة بدرجة كافية ومتنقلة وموفرة للطاقة وفعالة من حيث التكلفة وغير متطلبة في ظروف التشغيل. هذا هو أحد الاختلافات الرئيسية عن رفوف الخادم وكل ما يتعلق بها.
بدأنا بتحديد عدد العقد.
عدد العقد
من خلال أحكام منطقية بسيطة ، أدركنا أن 4 عقد هي الخيار الأفضل للحد الأدنى من كتلة الكتلة. 1 عقدة ليست كتلة ، 2 عقدتان غير كافيتين (1 عامل رئيسي 1 ، لا توجد إمكانية للقياس داخل كتلة ، خاصة بالنسبة للخيارات غير المتجانسة) ، 3 عقد تبدو جيدة ، ولكن ليست متعددة قوى 2 والقياس داخل الكتلة محدودة ، وتأتي 6 عقد بسعر يشبه 7 عقد تقريبًا (من تجربتنا هذا سعر تكلفة كبير بالفعل) ، 8 كثير ، لا يتناسب مع عامل شكل ITX المصغر وحتى حل PoC أغلى.
تعتبر أربع عقد لكل كتلة هي المتوسط الذهبي:
- مواد أقل لكل لوحة عنقودية ، وبالتالي أرخص في التصنيع
- مضاعفات 4 ، إجمالي 4 كتل تعطي 16 معالجًا فيزيائيًا
- دائرة مستقرة 1 سيد و 3 عمال
- المزيد من الاختلافات غير المتجانسة ، وحدات الحوسبة العامة + الحوسبة المتسارعة
- عامل شكل صغير ITX مع محركات أقراص SSD وبطاقات التوسعة
حساب الوحدات
الإصدار الثاني يعتمد على CM4 ، اعتقدنا أنه سيتم إصداره في عامل شكل SODIMM. لكن…
لقد اتخذنا قرارًا لإنشاء لوحة تحكم SODIMM وتجميع CM4 مباشرة في وحدات بحيث لا يضطر المستخدمون إلى التفكير في CM4.
وحدة حساب Turing Pi التي تدعم Raspberry Pi CM4
بشكل عام ، بحثًا عن الوحدات النمطية ، تم فتح سوق كامل لوحدات الحوسبة من وحدات صغيرة مع 128 ميجابايت من ذاكرة الوصول العشوائي إلى 8 جيجابايت من ذاكرة الوصول العشوائي. الوحدات ذات 16 جيجابايت من ذاكرة الوصول العشوائي وأكثر في المستقبل. بالنسبة لاستضافة تطبيقات الحافة على أساس التقنيات السحابية الأصلية ، فإن 1 غيغابايت من ذاكرة الوصول العشوائي ليست كافية بالفعل ، والظهور الأخير للوحدات 2 و 4 وحتى 8 غيغابايت من ذاكرة الوصول العشوائي يوفر مساحة جيدة للنمو. حتى أنهم نظروا في خيارات مع وحدات FPGA لتطبيقات التعلم الآلي ، لكن دعمهم تأخر بسبب عدم تطوير النظام البيئي للبرامج. أثناء دراسة سوق الوحدات ، توصلنا إلى فكرة إنشاء واجهة عالمية للوحدات النمطية ، وفي V2 بدأنا في توحيد واجهة وحدات الحوسبة. سيسمح هذا لمالكي الإصدار V2 بتوصيل الوحدات من الشركات المصنعة الأخرى ودمجها في مهام محددة.
يدعم V2 خط Raspberry Pi 4 Compute Module (CM4) بالكامل ، بما في ذلك الإصدارات الخفيفة ووحدات ذاكرة الوصول العشوائي بسعة 8 جيجابايت
المحيط
بعد تحديد بائع الوحدات النمطية وعدد العقد ، اقتربنا من ناقل PCI الذي توجد عليه الأجهزة الطرفية. يعتبر ناقل PCI هو المعيار للأجهزة الطرفية وهو موجود في جميع وحدات الحوسبة تقريبًا. لدينا عدة عقد ، ومن الناحية المثالية ، يجب أن تكون كل عقدة قادرة على مشاركة أجهزة PCI في وضع الطلب المتزامن. على سبيل المثال ، إذا كان قرصًا متصلًا بالناقل ، فسيكون متاحًا لجميع العقد. بدأنا في البحث عن محولات PCI مع دعم متعدد المضيفين ووجدنا أن أيا منها لا يلائم متطلباتنا. اقتصرت كل هذه الحلول في الغالب على مضيف واحد أو مضيفين متعددين ، ولكن بدون وضع الطلبات المتزامنة لنقاط النهاية. المشكلة الثانية هي التكلفة العالية التي تبلغ 1 دولارًا أو أكثر لكل شريحة. في V50 ، قررنا تأجيل التجارب مع محولات PCI (سنعود إليها لاحقًا أثناء تطويرنا) وذهبنا في مسار تعيين دور لكل عقدة: أول نقطتين تعرض منفذ PCI Express صغير لكل عقدة ، العقدة الثالثة وحدة تحكم SATA مكشوفة ذات منفذين 2 جيجابت في الثانية. للوصول إلى الأقراص من العقد الأخرى ، يمكنك استخدام نظام ملفات الشبكة داخل الكتلة. ولم لا؟
نظرة خاطفة
قررنا مشاركة بعض الرسومات التخطيطية لكيفية تطور الحد الأدنى من الكتلة العنقودية بمرور الوقت من خلال المناقشة والتفكير.
نتيجة لذلك ، وصلنا إلى وحدة الكتلة مع 4 عقدة ذات 260 سنًا ، ومنفذي PCIe (Gen 2) صغيران ، ومنفذا SATA (Gen 2). تحتوي اللوحة على Layer-2 Managed Switch مع دعم VLAN. تمت إزالة منفذ PCIe صغير من العقدة الأولى ، حيث يمكنك تثبيت بطاقة شبكة والحصول على منفذ Ethernet آخر أو مودم 3G وإنشاء جهاز توجيه للشبكة على منافذ المجموعة ومنافذ Ethernet من العقدة الأولى.
يحتوي ناقل الكتلة على المزيد من الميزات ، بما في ذلك القدرة على وميض الوحدات مباشرة من خلال جميع الفتحات وبالطبع موصلات FAN على كل عقدة مع التحكم في السرعة.
تطبيق
البنية التحتية المتطورة للتطبيقات والخدمات ذاتية الاستضافة
لقد قمنا بتصميم V2 ليكون الحد الأدنى من لبنة البناء الأساسية للمستهلك / المستوى التجاري. مع V2 ، من الرخيص البدء في إثبات المفهوم والتوسع أثناء نموك ، وتنقل التطبيقات تدريجيًا التي تكون أكثر فعالية من حيث التكلفة وعملية لاستضافتها على الحافة. يمكن توصيل الكتل العنقودية معًا لبناء مجموعات أكبر. يمكن القيام بذلك بشكل تدريجي دون المخاطرة بإثباته
العمليات. يوجد بالفعل اليوم عدد كبير من التطبيقات للأعمال ، .
محطة عمل ARM
مع ما يصل إلى 32 جيجابايت من ذاكرة الوصول العشوائي لكل مجموعة ، يمكن استخدام العقدة الأولى لإصدار سطح المكتب من نظام التشغيل (على سبيل المثال ، Ubuntu Desktop 20.04 LTS) والعقد الثلاثة المتبقية لمهام التجميع والاختبار وتصحيح الأخطاء ، وتطوير حلول السحابة الأصلية لـ ARM عناقيد المجموعات. كعقدة لـ CI / CD على البنية التحتية لحافة ARM في المنتج.
مجموعة Turing V2 مع وحدات CM4 متطابقة تقريبًا من الناحية المعمارية (اختلاف في الإصدارات الثانوية من ARMv8) إلى المجموعة بناءً على مثيلات AWS Graviton. يستخدم معالج الوحدة النمطية CM4 بنية ARMv8 حتى تتمكن من إنشاء صور وتطبيقات لمثيلات AWS Graviton 1 و 2 ، والتي من المعروف أنها أرخص بكثير من مثيلات x86.
المصدر: www.habr.com