مرحباً ، قراء حبر. مع هذه المقالة نفتح حلقة تتحدث عن نظام AERODISK vAIR الذي تم تطويره. في البداية ، أردنا أن يخبر المقال الأول كل شيء عن كل شيء ، ولكن النظام معقد للغاية ، لذلك سوف نتناول فيلًا في أجزاء.
لنبدأ القصة مع تاريخ النظام ، ونذهب إلى عمق نظام ملفات ARDFS ، الذي هو أساس vAIR ، ونتحدث أيضًا قليلاً عن وضع هذا الحل في السوق الروسية.
في المقالات المستقبلية ، سنتحدث أكثر عن المكونات المعمارية المختلفة (الكتلة ، المشرف ، موازن التحميل ، نظام المراقبة ، وما إلى ذلك) ، وعملية التكوين ، وسنثير مشكلات الترخيص ، ونُظهر اختبارات الأعطال بشكل منفصل ، وبالطبع نكتب عن اختبار التحميل و التحجيم. سنخصص أيضًا مقالة منفصلة لإصدار مجتمع vAIR.
هو airdisc قصة حول التخزين؟ أو لماذا بدأنا حتى hyperconverging؟
في البداية ، أتت فكرة إنشاء تقارب مفرط خاص بنا إلينا في مكان ما بالقرب من عام 2010. ثم لم يكن هناك أي Aerodisk وحلول مماثلة (أنظمة محاصرة hyperconverged التجارية) في السوق. كانت مهمتنا كالتالي: من مجموعة من الخوادم التي لها أقراص محلية متصلة عبر اتصال عبر الإيثرنت ، كان علينا أن نجعل التخزين الممتد وتشغيل الأجهزة الافتراضية وشبكة البرمجيات في نفس المكان. كل هذا كان مطلوبًا تنفيذه بدون أنظمة تخزين (لأنه ببساطة لم يكن هناك أموال لتخزينها وتجميعها ، ولم نقم بعد باختراع نظام التخزين الخاص بنا).
لقد جربنا الكثير من الحلول مفتوحة المصدر ومازلنا نحل هذه المشكلة ، لكن الحل كان معقدًا للغاية ، وكان من الصعب تكراره. بالإضافة إلى ذلك ، كان هذا القرار من فئة "الأشغال؟ لا تلمس! " لذلك ، بعد حل هذه المشكلة ، لم نقم بتطوير فكرة تحويل نتيجة عملنا إلى منتج متكامل.
بعد هذه الحادثة ، ابتعدنا عن هذه الفكرة ، لكن لا يزال لدينا شعور بأن هذه المهمة كانت قابلة للحل تمامًا ، وكانت فوائد هذا الحل أكثر من واضحة. بعد ذلك ، أكدت منتجات HCI للشركات الأجنبية التي تم إصدارها فقط هذا الشعور.
لذلك ، في منتصف عام 2016 ، عدنا إلى هذه المهمة كجزء من إنشاء منتج متكامل. ثم لم يكن لدينا أي علاقات مع المستثمرين حتى الآن ، لذلك كان علينا شراء منصة تطوير لأموالنا ليست كبيرة جدًا. بعد الكتابة على خوادم ومفاتيح Avito BU-shyh ، بدأنا العمل.
كانت المهمة الأولية الرئيسية هي إنشاء نظام الملفات الخاص بك ، وإن كان بسيطًا ، لكنه سيكون قادرًا على توزيع البيانات تلقائيًا وبشكل متساوٍ في شكل كتل افتراضية على الرقم التاسع من عقد المجموعات المرتبطة ببعضها عبر شبكة إيثرنت. في هذه الحالة ، يجب أن يكون نطاق الخدمة الثابتة جيدًا وسهل الاستقلالية ومستقلًا عن الأنظمة المجاورة ، أي تنفر من vAIR في شكل "مجرد تخزين".
مفهوم فير فيرست
لقد رفضنا عن قصد استخدام حلول مفتوحة المصدر جاهزة لتنظيم تخزين ممتد (ceph ، لمعان ، لمعان وما شابه) لصالح تطويرنا ، لأن لدينا بالفعل الكثير من تجربة المشروع معهم. بالطبع ، هذه الحلول رائعة ، وقبل أن نعمل على Aerodisk ، قمنا بتنفيذ أكثر من مشروع تكامل معهم. ولكن من المهم أن ندرك المهمة المحددة لعميل واحد ، وهو تدريب الموظفين ، وربما شراء الدعم لبائع كبير ، وهو شيء آخر تمامًا لإنشاء منتج منسوخ بسهولة سيتم استخدامه لمختلف المهام ، التي قد نعرفها نحن كبائع لن نفعل ذلك. بالنسبة للغرض الثاني ، فإن منتجات المصادر المفتوحة الحالية لا تناسبنا ، لذلك قررنا أن نرى نظام الملفات الموزع بأنفسنا.
بعد ذلك بعامين ، حقق العديد من المطورين (الذين قاموا بدمج العمل على vAIR مع العمل على محرك التخزين الكلاسيكي) نتيجة معينة.
بحلول عام 2018 ، كنا قد كتبنا أبسط نظام الملفات وقمنا باستكماله بالربط الضروري. قام النظام بدمج الأقراص الفعلية (المحلية) من خوادم مختلفة في تجمع واحد مسطح عبر اتصال داخلي و "قصها" إلى كتل افتراضية ، ثم تم إنشاء أجهزة بدرجات متفاوتة من التسامح مع الخطأ من الكتل الافتراضية ، التي تم إنشاء وتنفيذها برامج مراقبة KVM الافتراضية الجهاز.
لم نكن نزعج اسم نظام الملفات ونطلق عليه بإيجاز اسم ARDFS (احزر كيف يتم فك تشفيره))
بدا هذا النموذج الأولي جيدًا (ليس بصريًا ، بالطبع ، لم يكن هناك تصميم مرئي بعد ذلك) وأظهر نتائج جيدة في الأداء والتحجيم. بعد النتيجة الحقيقية الأولى ، وضعنا المسار لهذا المشروع ، بعد أن نظمت بيئة تطوير كاملة وفريق منفصل كان يعمل فقط في vAIR.
فقط في ذلك الوقت ، نضجت البنية العامة للحل ، والتي لم تشهد تغييرات كبيرة حتى الآن.
الغوص في نظام الملفات ARDFS
ARDFS هي أساس vAIR ، الذي يوفر تخزين تجاوز الفشل الموزع للكتلة بأكملها. تتمثل إحدى الميزات المميزة لـ ARDFS (وليس فقط) في أنه لا يستخدم أي خوادم مخصصة إضافية للبيانات الوصفية والإدارة. تم تصميم هذا في الأصل لتبسيط تكوين الحل وموثوقيته.
هيكل التخزين
ضمن كافة عقد نظام المجموعة ، يقوم ARDFS بتنظيم تجمع منطقي من كل مساحة القرص المتاحة. من المهم أن نفهم أن المجموعة ليست بعد بيانات وليست مساحة منسقة ، ولكن ببساطة ترميز ، أي تتم إضافة أي عقد مع vAIR مثبتة عند إضافتها إلى الكتلة تلقائيًا إلى تجمع ARDFS المشترك وتصبح موارد القرص تلقائيًا مشتركة عبر المجموعة بالكامل (ومتاحة لتخزين البيانات في المستقبل). تتيح لك هذه الطريقة إضافة وإزالة العقد السريعة دون أي تأثير خطير على نظام يعمل بالفعل. أي من السهل جدًا توسيع نطاق النظام باستخدام "الطوب" ، مع إضافة أو إزالة العقد في المجموعة إذا لزم الأمر.
تتم إضافة الأقراص الظاهرية (كائنات التخزين للأجهزة الافتراضية) أعلى تجمع ARDFS ، والتي تم إنشاؤها من كتل افتراضية بحجم 4 ميغابايت. الأقراص الافتراضية تخزين البيانات مباشرة. على مستوى القرص الظاهري ، يتم تعريف نظام التسامح مع الخطأ.
كما كنت قد خمنت ، من أجل التسامح مع الخطأ للنظام الفرعي للقرص ، لا نستخدم مفهوم RAID (مجموعة متكررة من الأقراص المستقلة) ، ولكننا نستخدم RAIN (مجموعة متكررة من العقد المستقلة). أي يتم قياس التسامح مع الخطأ وأتمتة وإدارته استنادًا إلى العقد وليس الأقراص. تعد الأقراص ، بطبيعة الحال ، أيضًا كائن تخزين ، فهي ، مثلها مثل كل شيء آخر ، تتم مراقبتها ، ويمكنك إجراء جميع العمليات القياسية معهم ، بما في ذلك إنشاء RAID للأجهزة المحلية ، ولكن تعمل المجموعة مع العقد.
في المواقف التي تريد فيها RAID (على سبيل المثال ، سيناريو يدعم العديد من حالات الفشل في الكتل الصغيرة) ، لا شيء يمنعك من استخدام وحدات التحكم RAID المحلية ، والقيام بعمليات تخزين ممتدة وبنية RAIN في الأعلى. هذا السيناريو مفعم بالحيوية ويدعمه لنا ، لذلك سنتحدث عنه في مقالة حول السيناريوهات النموذجية لاستخدام vAIR.
أنظمة تجاوز الفشل في التخزين
قد يكون هناك اثنين من خطط vAIR مرونة القرص الظاهري:
1) عامل النسخ المتماثل أو مجرد التكرار - طريقة التسامح مع الخطأ بسيطة "مثل العصا والحبل". يتم إجراء النسخ المتماثل المتزامن بين العقد مع عامل 2 (نسختين لكل كتلة) أو 3 (3 نسخ ، على التوالي). يسمح RF-2 للقرص الظاهري بتحمل فشل عقدة واحدة في كتلة ما ، ولكن "يأكل" نصف الحجم القابل للاستخدام ، وسوف يتحمل RF-3 فشل عقدتين في كتلة ، لكنه سيحتفظ بحصة 2/3 من حجمه القابل للاستخدام لاحتياجاته. يشبه هذا المخطط RAID-1 ، أي أن القرص الظاهري المكوّن في RF-2 مقاوم لفشل أي عقدة واحدة من الكتلة. في هذه الحالة ، ستكون البيانات على ما يرام وحتى I / O لن تتوقف. عندما تعود العقدة الساقطة إلى التشغيل ، سيبدأ الاسترداد التلقائي / مزامنة البيانات.
فيما يلي أمثلة لتوزيع بيانات RF-2 و RF-3 في الوضع العادي وفي حالات الفشل.
لدينا آلة افتراضية بسعة 8 ميجابايت من البيانات الفريدة (المفيدة) التي تعمل على 4 عقد vAIR. من الواضح أنه في الواقع من غير المحتمل أن يكون هناك مثل هذا المبلغ الضئيل ، لكن بالنسبة إلى مخطط يعكس منطق ARDFS ، يكون هذا المثال أكثر قابلية للفهم. AB عبارة عن كتل افتراضية 4 ميجابايت تحتوي على بيانات الجهاز الظاهري الفريدة. مع RF-2 ، يتم إنشاء نسختين من هذه الكتلتين A1 + A2 و B1 + B2 ، على التوالي. يتم "وضع" هذه الكتل بواسطة العقد ، وتجنب تقاطع البيانات نفسها على نفس العقدة ، أي أن النسخة A1 لن تكون بنفس الملاحظة مثل النسخة A2. مع B1 و B2 هو مشابه.
في حالة فشل إحدى العقد (على سبيل المثال ، العقدة 3 ، التي تحتوي على نسخة من B1) ، يتم تنشيط هذه النسخة تلقائيًا على العقدة حيث لا توجد نسخة من نسختها (أي ، نسخة B2).
وبالتالي ، فإن القرص الظاهري (و VMs ، على التوالي) سوف ينجو بسهولة من فشل عقدة واحدة في مخطط RF-2.
تعاني الدائرة التي تحتوي على نسخ متماثل وبساطتها وموثوقيتها من نفس قرحة RAID1 - هناك مساحة صغيرة يمكن استخدامها.
2) محو تشفير أو تشفير الحذف (المعروف أيضًا باسم "تشفير زائد" أو "تشفير محو" أو "شفرة التكرار") موجود فقط لحل المشكلة أعلاه. EC هو مخطط التكرار الذي يوفر توفر البيانات عالية مع أقل مقدار الحمل القرص مقارنة النسخ المتماثل. يشبه مبدأ تشغيل هذه الآلية RAID 5 و 6 و 6P.
عند الترميز ، تقسم عملية EC الكتلة الظاهرية (4 ميجابايت افتراضيًا) إلى عدة "أجزاء بيانات" أصغر وفقًا لنظام EC (على سبيل المثال ، يقسم مخطط 2 + 1 كل كتلة 4 ميغابايت إلى قطعتين بحجم 2 ميجابايت). علاوة على ذلك ، تولد هذه العملية "أجزاء تعادل" لـ "أجزاء من البيانات" لا تزيد عن واحد من الأجزاء التي سبق فصلها. عند فك التشفير ، تنشئ المجموعة الأوروبية الأجزاء المفقودة ، وقراءة البيانات "الباقية" عبر المجموعة بأكملها.
على سبيل المثال ، يمكن للقرص الظاهري الذي يحتوي على مخطط EC + 2 ، والذي تم تنفيذه على 4 عقد من الكتلة ، أن يتحمل بسهولة فشل عقدة واحدة في كتلة بنفس طريقة RF-2. في نفس الوقت ، ستكون التكاليف العامة أقل ، على وجه الخصوص ، عامل السعة مع RF-2 هو 2 ، وفي EC 2 + 1 سيكون 1.5.
إذا كان من الأسهل وصفه ، فإن الخلاصة هي أن الكتلة الافتراضية مقسمة إلى 2-8 (لماذا من 2 إلى 8 انظر أدناه) "القطع" ، وبالنسبة لهذه القطع يتم حساب "القطع" للتكافؤ من نفس الحجم.
نتيجة لذلك ، يتم توزيع البيانات والتكافؤ بالتساوي عبر كافة عقد الكتلة. في الوقت نفسه ، كما هو الحال مع النسخ المتماثل ، يقوم ARDFS تلقائيًا بتوزيع البيانات بين العقد بطريقة تمنع تخزين البيانات نفسها (نسخ البيانات وتعادلها) على عقدة واحدة من أجل القضاء على فرصة فقدان البيانات بسبب حقيقة أن البيانات و سوف ينتهي التكافؤ فجأة على عقدة التخزين نفسها ، والتي سوف تفشل.
فيما يلي مثال ، مع نفس الجهاز الظاهري في 8 ميغابايت و 4 عقد ، ولكن بالفعل مع مخطط EC 2 + 1.
تقسم الكتل A و B إلى قطعتين بسعة 2 ميجابايت لكل منهما (اثنان بسبب 2 + 1) ، وهما A1 + A2 و B1 + B2. بخلاف النسخة المتماثلة ، A1 ليست نسخة من A2 ، بل هي كتلة افتراضية A ، مقسمة إلى جزأين ، أيضًا مع الكتلة B. في المجموع ، نحصل على مجموعتين من 4 ميجابايت ، يحتوي كل منهما على قطعتين بحجم 2 ميجابايت. علاوة على ذلك ، لكل من هذه المجموعات يتم حساب التكافؤ مع حجم لا يزيد عن قطعة واحدة (أي 2 ميغابايت) ، نحصل على + 2 قطعة إضافية (AP و BP). إجمالي لدينا 4x2 البيانات + 2x2 التعادل.
بعد ذلك ، يتم "وضع" القطع بواسطة العقد بحيث لا تتداخل البيانات مع تكافؤها. أي A1 و A2 لن تقع على نفس العقدة مع AP.
في حالة فشل عقدة واحدة (على سبيل المثال ، أيضًا العقدة الثالثة) ، ستتم استعادة الكتلة الساقطة B1 تلقائيًا من التماثل BP ، الذي يتم تخزينه على العقدة رقم 2 ، وسيتم تنشيطه على العقدة حيث لا يوجد تماثل ب ، قطع من BP. في هذا المثال ، هذا هو العقدة رقم 1
أنا متأكد من أن القارئ لديه سؤال:
"كل ما وصفته تم تنفيذه منذ فترة طويلة من قبل كل من المنافسين والحلول مفتوحة المصدر ، ما هو الفرق بين تطبيقك للمفوضية الأوروبية في ARDFS؟"
ثم ستكون هناك ميزات مثيرة للاهتمام لعمل ARDFS.
محو الترميز مع التركيز على المرونة
في البداية ، قدمنا نظام EC X + Y مرنًا إلى حد ما ، حيث X تساوي عددًا من 2 إلى 8 ، و Y تساوي عددًا من 1 إلى 8 ، ولكن دائمًا أقل من أو تساوي X. يتم توفير مثل هذا المخطط للمرونة. إن زيادة عدد أجزاء البيانات (X) التي تنقسم إليها الوحدة الافتراضية يسمح بتقليل الحمل ، أي زيادة المساحة القابلة للاستخدام.
زيادة في عدد قطع التماثل (Y) يزيد من موثوقية القرص الظاهري. أكبر قيمة Y ، يمكن أن تفشل العقد أكثر في الكتلة. بطبيعة الحال ، فإن الزيادة في التكافؤ تقلل من كمية السعة القابلة للاستخدام ، لكن هذه تكلفة موثوقية.
يكون اعتماد الأداء على دارات EC مباشرًا تقريبًا: فكلما زاد عدد "القطع" ، انخفض الأداء ، هنا ، بالطبع ، أنت بحاجة إلى مظهر متوازن.
يتيح هذا النهج للمسؤولين الطريقة الأكثر مرونة لتكوين مساحة التخزين الموسعة. ضمن تجمع ARDFS ، يمكنك استخدام أي مخططات للتسامح مع الأعطال ومجموعاتها ، وهذا في رأينا مفيد للغاية.
يقارن الجدول أدناه عدة دوائر (RF) و (EC) غير ممكنة.
يوضح الجدول أنه حتى مزيج "terry" من EC 8 + 7 ، والذي يسمح بفقد ما يصل إلى 7 نقاط في وقت واحد في كتلة ، "يأكل" مساحة أقل صالحة للاستعمال (1.875 مقابل 2) من النسخ المتماثل القياسي ، ويحمي بشكل أفضل 7 مرات ، مما يجعل آلية الحماية هذه ، رغم أنها أكثر تعقيدًا ، ولكنها أكثر جاذبية في المواقف التي تحتاج فيها إلى ضمان أقصى درجة من الموثوقية في ظروف نقص مساحة القرص. في الوقت نفسه ، عليك أن تفهم أن كل "علامة زائد" إلى X أو Y ستكون بمثابة حمل إضافي للإنتاجية ، لذلك عليك أن تختار بعناية فائقة في المثلث بين الموثوقية والاقتصاد والأداء. لهذا السبب ، سوف نخصص مقالة منفصلة لتغيير حجم الحذف الترميز.
الموثوقية واستقلال نظام الملفات
يعمل ARDFS محليًا على جميع عقد المجموعة ويقوم بمزامنتها بوسائلها الخاصة من خلال واجهات Ethernet المخصصة. نقطة مهمة هي أن ARDFS يقوم بمزامنة البيانات ليس فقط بشكل مستقل ، ولكن أيضًا البيانات التعريفية المتعلقة بالتخزين. أثناء العمل على ARDFS ، درسنا في وقت واحد عددًا من الحلول الحالية ووجدنا أن العديد منها يقوم بإجراء مزامنة تعريفية لنظام الملفات باستخدام DBMS خارجي موزع ، والذي نستخدمه أيضًا للمزامنة ، ولكن فقط التكوينات ، وليس بيانات تعريف FS (حول هذا النظام والأنظمة الفرعية الأخرى ذات الصلة) في المادة القادمة).
تزامن البيانات الوصفية للخدمة الثابتة باستخدام نظام إدارة قواعد البيانات الخارجية هو ، بطبيعة الحال ، حل فعال ، ولكن اتساق البيانات المخزنة على ARDFS يعتمد على قواعد البيانات الخارجية وسلوكها (وهي ، بصراحة ، سيدة متقلبة) ، وهو أمر سيء في رأينا. لماذا؟ في حالة تلف بيانات تعريف الخدمة الثابتة ، يمكن أيضًا قول بيانات الخدمة الثابتة نفسها "وداعًا" ، لذلك قررنا السير في مسار أكثر تعقيدًا ويمكن الاعتماد عليه.
لقد جعلنا النظام الفرعي لمزامنة البيانات التعريفية لـ ARDFS بشكل مستقل ، وهو يعيش بشكل مستقل تمامًا عن الأنظمة الفرعية المجاورة. أي لا يوجد نظام فرعي آخر يمكنه إتلاف بيانات ARDFS. في رأينا ، هذه هي الطريقة الأكثر موثوقية وصحيحة ، وهل هي حقًا - الوقت سيخبرنا. بالإضافة إلى ذلك ، مع هذا النهج ، تظهر ميزة إضافية. يمكن استخدام ARDFS بشكل مستقل عن vAIR ، تمامًا مثل التخزين الموسّع ، والذي سنستخدمه بالتأكيد في المنتجات المستقبلية.
نتيجة لذلك ، بعد تطوير ARDFS ، حصلنا على نظام ملفات مرن وموثوق يوفر لك خيارًا حيث يمكنك توفير السعة أو تقديم كل شيء بعيدًا عن الأداء ، أو جعل التخزين موثوقًا بدرجة عالية مقابل رسوم معتدلة ، ولكن مع تقليل متطلبات الأداء.
بالإضافة إلى سياسة الترخيص البسيطة ونموذج التسليم المرن (بالنظر إلى المستقبل ، يتم ترخيصه بواسطة vAIR من خلال العقد ، ويتم تقديمه إما عن طريق البرنامج أو باعتباره PAC) ، مما يتيح لك تصميم الحل بدقة شديدة بحيث يلبي متطلبات العملاء المختلفة ، ومن السهل الحفاظ على هذا التوازن في المستقبل.
من يحتاج لهذه المعجزة؟
من ناحية ، يمكننا القول أن هناك بالفعل لاعبين في السوق لديهم قرارات جادة في مجال التقارب المفرط ، وإلى أين نحن ذاهبون بالفعل. هذا البيان يبدو صحيحا ، ولكن ...
من ناحية أخرى ، عند الخروج إلى الحقول والتواصل مع العملاء ، نرى نحن وشركاؤنا أن هذا ليس هو الحال على الإطلاق. هناك العديد من المشكلات التي تواجه التقارب المفرط ، في مكان ما لم يعرف الناس ببساطة أن هناك مثل هذه الحلول ، في مكان ما بدا مكلفًا ، في مكان ما كانت هناك اختبارات غير ناجحة للحلول البديلة ، لكن في مكان ما كانوا يمنعون الشراء عمومًا بسبب العقوبات. بشكل عام ، لم يتم حرث الحقل ، لذلك ذهبنا لرفع الأراضي البكر))).
متى يكون التخزين أفضل من GCS؟
أثناء العمل مع السوق ، غالبًا ما يُسألنا متى من الأفضل استخدام المخطط الكلاسيكي مع أنظمة التخزين ، ومتى يكون التقارب المفرط؟ تقول العديد من الشركات - الشركات المصنعة لـ GCS (وخاصة تلك التي ليس لديها مساحة تخزينية في محفظتها): "التخزين قديم ، إنه مفرط التحسس فقط!" هذا بيان جريء ، لكنه لا يعكس الواقع تمامًا.
في الواقع ، فإن سوق التخزين ، في الواقع ، يسبح نحو حلول شديدة التشابه والحلول المماثلة ، ولكن هناك دائمًا "لكن".
أولاً ، لا يمكن بسهولة إعادة بناء مراكز البيانات والبنية التحتية لتكنولوجيا المعلومات التي تم إنشاؤها وفقًا للمخطط الكلاسيكي مع أنظمة التخزين ، وبالتالي فإن تحديث وإتمام هذه الهياكل الأساسية لا يزال إرثًا من 5 إلى 7 سنوات.
ثانياً ، تلك البنى التحتية التي يتم بناؤها الآن في جزء كبير (بمعنى الاتحاد الروسي) يتم بناؤها وفقًا للمخطط الكلاسيكي الذي يستخدم أنظمة التخزين وليس لأن الناس لا يعرفون شيئًا عن التقارب المفرط ، ولكن نظرًا لأن سوق التشدد المفرط جديد ، لم يتم إنشاء حلول ومعايير بعد ، لم يتم تدريب موظفي تكنولوجيا المعلومات بعد ، فهناك خبرة قليلة ، ونحن بحاجة إلى بناء مراكز بيانات هنا والآن. وهذا الاتجاه لمدة 3-5 سنوات أخرى (ثم إرث آخر ، انظر الفقرة 1).
ثالثًا ، وجود قيود فنية بحتة على تأخيرات صغيرة إضافية تبلغ 2 مللي ثانية لكل الكتابة (باستثناء ذاكرة التخزين المؤقت المحلية ، بالطبع) ، وهي رسوم للتخزين الموزع.
حسنًا ، دعونا لا ننسى استخدام الخوادم المادية الكبيرة التي تحب القياس الرأسي للنظام الفرعي للقرص.
هناك العديد من المهام الضرورية والشائعة حيث يتصرف نظام التخزين بشكل أفضل من GCS. هنا ، بطبيعة الحال ، فإن المصنّعين الذين لا يملكون أنظمة تخزين في مجموعة منتجاتهم سيختلفون معنا ، لكننا مستعدون للمناقشة بشكل معقول. بالطبع ، نحن كمطورين لكلا المنتجين في أحد المنشورات المستقبلية ، سنقوم بالتأكيد بإجراء مقارنة بين أنظمة التخزين و GCS ، حيث سنوضح بوضوح ما هو أفضل تحت أي ظروف.
وأين ستعمل الحلول شديدة التحمل بشكل أفضل من أنظمة التخزين؟
بناءً على الرسائل أعلاه ، هناك ثلاثة استنتاجات واضحة:
- عندما يكون هناك 2 مللي ثانية إضافية من التأخير في التسجيل التي تحدث بثبات في أي منتج (الآن لا نتحدث عن المواد التركيبية ، يمكنك إظهار النانوثانية في المواد التركيبية) غير حرجة ، ستفعل فرط التوافق.
- حيث يمكن تحويل الحمل من خوادم فعلية كبيرة إلى العديد من الخوادم الافتراضية الصغيرة وتوزيعها عن طريق العقد ، سوف يعمل hyperconvergent أيضًا بشكل جيد هناك.
- عندما يكون القياس الأفقي أكثر أهمية من القياس الرأسي ، فإن GCS ستعمل بشكل جيد هناك.
ما هي هذه الحلول؟
- جميع خدمات البنية التحتية القياسية (خدمة الدليل ، البريد ، EDS ، خوادم الملفات ، أنظمة ERP و BI الصغيرة أو المتوسطة ، إلخ). نحن نسمي هذا "الحوسبة العامة".
- البنية التحتية لموفري الخدمات السحابية ، حيث من الضروري توسيع وتوحيد أفقياً بسرعة وتقسيم عدد كبير من الأجهزة الافتراضية للعملاء بسهولة.
- بنية تحتية لسطح المكتب الافتراضي (VDI) ، حيث يتم إطلاق العديد من المستخدمين الظاهري الصغير و "تطفو" بهدوء داخل مجموعة موحدة.
- , , , 15-20 .
- (big data-, ). , «», «».
- , , , .
AERODISK vAIR ( ). , , .. .
…
, .
, .