مرحباً بقراء الهبر. من خلال هذه المقالة ، نفتح دورة تتحدث عن نظام التقارب الفائق AERODISK vAIR الذي طورناه. في البداية ، أردنا أن نخبر كل شيء عن كل شيء في المقالة الأولى ، لكن النظام معقد للغاية ، لذلك سنأكل الفيل في أجزاء.
لنبدأ القصة بتاريخ إنشاء النظام ، ونتعمق في نظام ملفات ARDFS ، وهو أساس vAIR ، ونناقش أيضًا قليلاً حول وضع هذا الحل في السوق الروسية.
في المقالات المستقبلية ، سنتحدث بمزيد من التفاصيل حول المكونات المعمارية المختلفة (الكتلة ، Hypervisor ، موازن التحميل ، نظام المراقبة ، وما إلى ذلك) ، وعملية التكوين ، ورفع مشكلات الترخيص ، وعرض اختبارات التعطل بشكل منفصل ، وبالطبع الكتابة عن اختبار الحمل والتحجيم. سنخصص أيضًا مقالة منفصلة لإصدار المجتمع من vAIR.
Aerodisk مثل قصة عن أنظمة التخزين؟ أو لماذا بدأنا hyperconvergent على الإطلاق؟
في البداية ، جاءت فكرة إنشاء أداة التقارب الفائق الخاصة بنا في مكان ما في عام 2010 تقريبًا. في ذلك الوقت ، لم يكن هناك Aerodisk ولا حلول مماثلة (أنظمة تجارية مجمعة للغاية) في السوق. كانت مهمتنا على النحو التالي: من مجموعة من الخوادم بأقراص محلية ، متصلة بواسطة اتصال داخلي عبر بروتوكول Ethernet ، كان من الضروري إنشاء تخزين موسع وتشغيل أجهزة افتراضية وشبكة برنامج هناك. كل هذا يحتاج إلى أن يتم تنفيذه بدون تخزين (لأنه ببساطة لم يكن هناك أموال للتخزين وحزمه ، ولم نكن قد اخترعنا نظام التخزين الخاص بنا بعد).
لقد جربنا الكثير من الحلول مفتوحة المصدر وما زلنا نحل هذه المشكلة ، لكن الحل كان معقدًا للغاية ويصعب تكراره. بالإضافة إلى ذلك ، كان هذا الحل من فئة "الأعمال؟ لا تلمس! لذلك ، بعد حل هذه المشكلة ، لم نطور فكرة تحويل نتيجة عملنا إلى منتج كامل.
بعد تلك الحادثة ، ابتعدنا عن هذه الفكرة ، ولكن لا يزال لدينا شعور بأن هذه المهمة كانت قابلة للحل تمامًا ، وكانت فوائد مثل هذا القرار أكثر من واضحة. في المستقبل ، أكدت منتجات HCI الصادرة عن الشركات الأجنبية هذا الشعور فقط.
لذلك ، في منتصف عام 2016 ، عدنا إلى هذه المهمة كجزء من إنشاء منتج متكامل. في ذلك الوقت لم تكن لدينا أي علاقات مع المستثمرين ، لذلك كان علينا شراء منصة تطوير لأموالنا ليست كبيرة جدًا. بعد كتابة خوادم BU والمفاتيح على Avito ، بدأنا العمل.
كانت المهمة الأولية الرئيسية هي إنشاء نظام ملفات خاص بنا ، وإن كان بسيطًا ، ولكنه يمكن أن يوزع البيانات تلقائيًا وبشكل متساوٍ في شكل كتل افتراضية على العدد n من العقد العنقودية ، والتي يتم توصيلها عن طريق ربط Ethernet. في الوقت نفسه ، يجب أن يتسع نطاق الخدمة الثابتة بشكل جيد وسهل وأن تكون مستقلة عن الأنظمة المجاورة ، أي ينفصل عن vAIR باعتباره "مجرد تخزين".
أول مفهوم vAIR
لقد تخلينا عمدًا عن استخدام حلول مفتوحة المصدر جاهزة لتنظيم التخزين الممتد (ceph ، gluster ، luster ، وما شابه ذلك) لصالح تطويرنا ، نظرًا لأن لدينا بالفعل الكثير من الخبرة في المشروع معهم. بالطبع ، هذه الحلول ممتازة في حد ذاتها ، وقبل العمل على Aerodisk ، قمنا بتنفيذ أكثر من مشروع تكامل معهم. لكن تنفيذ مهمة محددة لعميل واحد ، وتدريب الموظفين ، وربما شراء الدعم من بائع كبير ، شيء آخر هو إنشاء منتج قابل للتكرار بسهولة ، والذي سيتم استخدامه في مهام مختلفة ، البائع ، قد نعرف حتى عن أنفسنا ، لن نفعل ذلك. بالنسبة للهدف الثاني ، لم تكن المنتجات مفتوحة المصدر الحالية مناسبة لنا ، لذلك قررنا قطع نظام الملفات الموزعة بأنفسنا.
بعد عامين ، بمساعدة العديد من المطورين (الذين جمعوا بين العمل على vAIR والعمل في محرك التخزين الكلاسيكي) ، حققوا نتيجة معينة.
بحلول عام 2018 ، كتبنا أبسط نظام ملفات وقمنا بتكميله بالربط الضروري. قام النظام بدمج الأقراص المادية (المحلية) من خوادم مختلفة في مجموعة مسطحة واحدة عبر اتصال داخلي و "قطعها" إلى كتل افتراضية ، ثم تم إنشاء حظر الأجهزة بدرجات متفاوتة من التسامح مع الخطأ من الكتل الافتراضية ، والتي تم إنشاء أجهزة افتراضية عليها ونُفِّذت باستخدام برنامج Hypervisor KVM.
لم ننزعج كثيرًا باسم نظام الملفات وأطلقنا عليه بإيجاز اسم ARDFS (خمن كيف ترمز إليه))
بدا هذا النموذج الأولي جيدًا (ليس بصريًا ، بالطبع ، لم يكن هناك تصميم مرئي في ذلك الوقت) وأظهر نتائج جيدة من حيث الأداء والقياس. بعد النتيجة الحقيقية الأولى ، أطلقنا هذا المشروع ، بعد أن قمنا بالفعل بتنظيم بيئة تطوير كاملة وفريق منفصل يتعامل فقط مع vAIR.
بحلول ذلك الوقت فقط ، كانت البنية العامة للحل قد نضجت ، والتي لم تخضع بعد لتغييرات كبيرة.
الغوص في نظام ملفات ARDFS
ARDFS هو العمود الفقري لـ vAIR ، والذي يوفر تخزينًا موزعًا يتحمل الأخطاء للمجموعة بأكملها. تتمثل إحدى السمات المميزة لـ ARDFS (ولكن ليس الوحيد) في أنه لا يستخدم أي خوادم مخصصة إضافية للميتا والإدارة. تم تصميم هذا في الأصل لتبسيط تكوين الحل وموثوقيته.
هيكل التخزين
داخل جميع عقد الكتلة ، ينظم ARDFS تجمعًا منطقيًا من كل مساحة القرص المتوفرة. من المهم أن نفهم أن التجمع ليس بعد بيانات أو مساحة منسقة ، ولكن مجرد ترميز ، أي تتم إضافة أي عقد مثبت عليها vAIR عند إضافتها إلى المجموعة تلقائيًا إلى تجمع ARDFS المشترك وتتم مشاركة موارد القرص تلقائيًا عبر المجموعة بأكملها (ومتاحة لتخزين البيانات في المستقبل). يتيح لك هذا الأسلوب إضافة العقد وإزالتها أثناء التنقل دون أي تأثير خطير على النظام قيد التشغيل بالفعل. أولئك. من السهل جدًا قياس النظام باستخدام "الطوب" ، وإضافة أو إزالة العقد في الكتلة إذا لزم الأمر.
في الجزء العلوي من تجمع ARDFS ، تمت إضافة أقراص افتراضية (كائنات تخزين للأجهزة الافتراضية) ، والتي تم إنشاؤها من كتل افتراضية بحجم 4 ميغا بايت. يتم تخزين البيانات مباشرة على الأقراص الافتراضية. يتم أيضًا تعيين مخطط التسامح مع الخطأ على مستوى القرص الظاهري.
كما قد تكون خمنت ، من أجل التسامح مع أخطاء النظام الفرعي للقرص ، فإننا لا نستخدم مفهوم RAID (مجموعة متكررة من الأقراص المستقلة) ، لكننا نستخدم RAIN (مجموعة متكررة من العقد المستقلة). أولئك. يتم قياس التسامح مع الخطأ وأتمته وإدارته من حيث العقد وليس الأقراص. الأقراص ، بالطبع ، هي أيضًا كائن تخزين ، فهي ، مثل أي شيء آخر ، تتم مراقبتها ، ويمكنك تنفيذ جميع العمليات القياسية معها ، بما في ذلك بناء RAID للأجهزة المحلية ، لكن الكتلة تعمل بدقة مع العقد.
في المواقف التي تريد فيها RAID حقًا (على سبيل المثال ، سيناريو يدعم حالات فشل متعددة على مجموعات صغيرة) ، لا شيء يمنعك من استخدام وحدات تحكم RAID المحلية ، علاوة على القيام بالتخزين الممتد وبنية RAIN. مثل هذا السيناريو حي تمامًا ومدعوم من قبلنا ، لذلك سنتحدث عنه في مقال حول السيناريوهات النموذجية لاستخدام vAIR.
مخططات تجاوز فشل التخزين
يمكن أن يكون هناك نظامان للتسامح مع الأخطاء للأقراص الافتراضية في vAIR:
1) عامل النسخ أو النسخ المتماثل فقط - طريقة تحمل الخطأ هذه بسيطة "مثل العصا والحبل". يتم إجراء النسخ المتزامن بين العقد بعامل 2 (نسختان لكل مجموعة) أو 2 (3 نسخ ، على التوالي). يسمح RF-3 للقرص الافتراضي بمقاومة فشل عقدة واحدة في المجموعة ، ولكن "يلتهم" نصف الحجم القابل للاستخدام ، ويمكن لـ RF-2 تحمل فشل عقدتين في المجموعة ، ولكنه يحتفظ بالفعل بنسبة 3/2 من الحجم القابل للاستخدام لاحتياجاته. يشبه هذا المخطط إلى حد كبير RAID-2 ، أي أن القرص الظاهري الذي تم تكوينه في RF-3 يقاوم فشل أي عقدة من الكتلة. في هذه الحالة ، ستكون البيانات على ما يرام ولن تتوقف حتى I / O. عندما تعود العقدة المعطلة إلى الخدمة ، سيبدأ الاستعادة / المزامنة التلقائية للبيانات.
فيما يلي أمثلة لتوزيع بيانات RF-2 و RF-3 في الوضع العادي وفي حالة الفشل.
لدينا آلة افتراضية بحجم 8 ميغا بايت من البيانات الفريدة (المفيدة) ، والتي تعمل على 4 عقد vAIR. من الواضح أنه في الواقع من غير المحتمل أن يكون هناك مثل هذا الحجم الصغير ، ولكن بالنسبة للمخطط الذي يعكس منطق ARDFS ، فإن هذا المثال هو الأكثر قابلية للفهم. ABs عبارة عن كتل افتراضية بحجم 4 ميجابايت تحتوي على بيانات آلة افتراضية فريدة. يقوم RF-2 بإنشاء نسختين من هذه الكتل A1 + A2 و B1 + B2 ، على التوالي. يتم "تحلل" هذه الكتل إلى عقد ، لتجنب تقاطع نفس البيانات على نفس العقدة ، أي لن يتم وضع نسخة من A1 على نفس العقدة مثل نسخة من A2. مع B1 و B2 يكون الأمر مشابهًا.
في حالة فشل إحدى العقد (على سبيل المثال ، العقدة رقم 3 ، والتي تحتوي على نسخة من B1) ، يتم تنشيط هذه النسخة تلقائيًا على العقدة حيث لا توجد نسخة من نسختها (أي نسخة من B2).
وبالتالي ، فإن القرص الظاهري (و VM ، على التوالي) سوف ينجو بسهولة من فشل عقدة واحدة في مخطط RF-2.
نظام النسخ المتماثل ، على الرغم من بساطته وموثوقيته ، يعاني من نفس القرحة مثل RAID1 - هناك مساحة صغيرة قابلة للاستخدام.
2) محو الترميز أو محو الترميز (المعروف أيضًا باسم "الترميز الزائد" أو "محو الترميز" أو "رمز التكرار") موجود فقط لحل المشكلة أعلاه. EC هو مخطط تكرار يوفر توفرًا عاليًا للبيانات مع مساحة أقل على القرص مقارنة بالنسخ المتماثل. يشبه مبدأ تشغيل هذه الآلية RAID 5 و 6 و 6P.
عند التشفير ، تقسم عملية EC كتلة افتراضية (افتراضية 4 ميجابايت) إلى عدة "مجموعات بيانات" أصغر اعتمادًا على مخطط EC (على سبيل المثال ، يقسم مخطط 2 + 1 كل كتلة 4 ميجابايت إلى قطع 2 ميجابايت). علاوة على ذلك ، تولد هذه العملية "أجزاء تكافؤ" لـ "أجزاء البيانات" التي لا تزيد عن أحد القطع المفصولة سابقًا. عند فك التشفير ، يولد EC الأجزاء المفقودة من خلال قراءة البيانات "الباقية" من المجموعة بأكملها.
على سبيل المثال ، فإن القرص الافتراضي مع مخطط 2 + 1 EC المطبق على 4 عقد عنقودية سوف ينجو بسهولة من فشل عقدة واحدة في الكتلة بنفس طريقة RF-2. في الوقت نفسه ، ستكون التكاليف العامة أقل ، على وجه الخصوص ، يكون عامل السعة المفيد لـ RF-2 هو 2 ، وبالنسبة للمفوضية الأوروبية 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 ميجابايت) ، نحصل على قطع تماثل إضافية + 4 (AP و BP). في المجموع لدينا 2 × 2 بيانات + 2 × XNUMX تكافؤ.
بعد ذلك ، يتم "تحلل" القطع إلى عقد بحيث لا تتقاطع البيانات مع تكافؤها. أولئك. لن يقع A1 و A2 على نفس العقدة مثل AP.
في حالة فشل إحدى العقدة (دعنا نقول أيضًا العقدة الثالثة) ، سيتم استعادة الكتلة الساقطة B1 تلقائيًا من تماثل BP ، والذي يتم تخزينه في العقدة رقم 2 ، وسيتم تنشيطه على العقدة حيث توجد لا يوجد تكافؤ ب ، أي قطعة من BP. في هذا المثال ، هذا هو رقم العقدة 1
أنا متأكد من أن القارئ يتساءل:
"كل ما وصفته تم تنفيذه منذ فترة طويلة من قبل المنافسين وفي حلول المصادر المفتوحة ، ما هو الفرق بين تطبيقك لـ EC في ARDFS؟"
وبعد ذلك ستكون هناك ميزات مثيرة للاهتمام لعمل ARDFS.
محو الترميز مع التركيز على المرونة
في البداية ، قدمنا مخطط EC X + Y مرنًا إلى حد ما ، حيث X عبارة عن رقم من 2 إلى 8 ، و Y هو رقم من 1 إلى 8 ، ولكنه دائمًا أقل من أو يساوي X. تم توفير هذا المخطط للمرونة. تتيح لك زيادة عدد أجزاء البيانات (X) التي يتم تقسيم الكتلة الافتراضية إليها تقليل الحمل ، أي زيادة المساحة القابلة للاستخدام.
تؤدي زيادة عدد قطع التكافؤ (Y) إلى زيادة موثوقية القرص الظاهري. كلما زادت قيمة Y ، يمكن أن تفشل المزيد من العقد في الكتلة. بطبيعة الحال ، فإن زيادة مقدار التكافؤ يقلل من مقدار السعة القابلة للاستخدام ، ولكن هذه مقايضة من أجل الموثوقية.
إن اعتماد الأداء على مخططات المفوضية الأوروبية يكاد يكون مباشرًا: فكلما زاد عدد "القطع" ، انخفض الأداء ، وهنا ، بالطبع ، هناك حاجة إلى رؤية متوازنة.
يتيح هذا الأسلوب للمسؤولين تكوين التخزين الممتد بمرونة قدر الإمكان. داخل تجمع ARDFS ، يمكنك استخدام أي مخططات للتسامح مع الأخطاء ومجموعاتها ، والتي ، في رأينا ، مفيدة جدًا أيضًا.
يوجد أدناه جدول يقارن بين العديد من مخططات RF و EC (ليس كل ما هو ممكن).
يوضح الجدول أنه حتى أكثر مجموعات "تيري" من EC 8 + 7 ، والتي تسمح بفقدان ما يصل إلى 7 عقد في مجموعة في نفس الوقت ، "تلتهم" مساحة أقل قابلية للاستخدام (1,875 مقابل 2) من النسخ القياسي ، ويحمي 7 مرات أفضل ، مما يجعل آلية الحماية هذه ، على الرغم من أنها أكثر تعقيدًا ، ولكنها أكثر جاذبية في المواقف التي تحتاج فيها إلى ضمان أقصى قدر من الموثوقية في ظروف نقص مساحة القرص. في الوقت نفسه ، عليك أن تفهم أن كل "زائد" إلى X أو Y سيكون عبئًا إضافيًا للأداء ، لذلك عليك أن تختار بعناية فائقة في المثلث بين الموثوقية والاقتصاد والأداء. لهذا السبب ، سنخصص مقالة منفصلة لتحديد حجم محو الترميز.
موثوقية واستقلالية نظام الملفات
يعمل ARDFS محليًا على جميع عقد المجموعة ويقوم بمزامنتها بوسائله الخاصة عبر واجهات Ethernet المخصصة. نقطة مهمة هي أن ARDFS نفسه لا يقوم بمزامنة البيانات فحسب ، بل يقوم أيضًا بمزامنة البيانات الوصفية المتعلقة بالتخزين. في سياق العمل على ARDFS ، درسنا عددًا من الحلول الحالية بالتوازي ووجدنا أن العديد منها يقوم بمزامنة نظام الملفات الوصفية باستخدام DBMS خارجي موزع ، والذي نستخدمه أيضًا للمزامنة ، ولكن فقط التكوينات ، وليس البيانات الوصفية لنظام الملفات ( حول هذا والأنظمة الفرعية الأخرى ذات الصلة في المقالة التالية).
تعد مزامنة البيانات الوصفية FS باستخدام DBMS خارجي ، بالطبع ، حلاً عمليًا ، ولكن بعد ذلك سيعتمد اتساق البيانات المخزنة على ARDFS على نظام DBMS الخارجي وسلوكه (وبصراحة ، إنها سيدة متقلبة) ، والتي في منطقتنا الرأي سيء. لماذا؟ في حالة تلف البيانات الوصفية للخدمة الثابتة ، يمكن أيضًا توديع بيانات FS نفسها ، لذلك قررنا اتخاذ مسار أكثر تعقيدًا ولكن يمكن الاعتماد عليه.
لقد صنعنا النظام الفرعي لمزامنة البيانات الوصفية لـ ARDFS بمفردنا ، وهو يعيش بشكل مستقل تمامًا عن الأنظمة الفرعية المجاورة. أولئك. لا يوجد نظام فرعي آخر يمكنه إتلاف بيانات ARDFS. في رأينا ، هذه هي الطريقة الأكثر موثوقية وصحيحة ، لكن الوقت سيحدد ما إذا كان هذا هو الحال بالفعل. بالإضافة إلى ذلك ، مع هذا النهج ، هناك ميزة إضافية. يمكن استخدام ARDFS بشكل مستقل عن vAIR ، تمامًا مثل التخزين الممتد ، والذي سنستخدمه بالتأكيد في المنتجات المستقبلية.
نتيجة لذلك ، من خلال تطوير ARDFS ، حصلنا على نظام ملفات مرن وموثوق يوفر خيارًا حيث يمكنك التوفير في السعة أو تقديم كل شيء على الأداء ، أو جعل التخزين موثوقًا للغاية بتكلفة متواضعة ، ولكن مع متطلبات أداء أقل.
جنبًا إلى جنب مع سياسة الترخيص البسيطة ونموذج التسليم المرن (بالنظر إلى المستقبل ، يتم ترخيص vAIR بواسطة العقد ، ويتم تسليمه إما كبرنامج أو كحزمة PACK) ، وهذا يجعل من الممكن ضبط الحل وفقًا لمجموعة متنوعة من متطلبات العملاء وبسهولة الحفاظ على هذا التوازن في المستقبل.
من يحتاج هذه المعجزة؟
من ناحية أخرى ، يمكننا القول أن هناك بالفعل لاعبين في السوق لديهم حلول جادة في مجال التقارب المفرط ، وحيث نتسلق بالفعل. يبدو أن هذا البيان صحيح ، ولكن ...
من ناحية أخرى ، عند الخروج إلى الحقول والتواصل مع العملاء ، نرى نحن وشركاؤنا أن هذا ليس هو الحال على الإطلاق. هناك العديد من المهام المتعلقة بفرط التقارب ، في مكان ما لا يعرف الناس ببساطة وجود مثل هذه الحلول ، وفي مكان ما يبدو أنها باهظة الثمن ، وفي مكان ما كانت هناك اختبارات غير ناجحة للحلول البديلة ، وفي مكان ما يُحظر الشراء على الإطلاق ، بسبب العقوبات. في الحقل العام اتضح أنه غير محروث ، لذلك ذهبنا لرفع تربة عذراء))).
متى يكون التخزين أفضل من GKS؟
في سياق العمل مع السوق ، غالبًا ما يُسألون متى يكون من الأفضل استخدام المخطط الكلاسيكي مع أنظمة التخزين ، ومتى يكون من الأفضل استخدام تقنية التقارب الفائق؟ تقول العديد من الشركات التي تنتج GKS (خاصة تلك التي ليس لديها أنظمة تخزين في محفظتها): "SAN أصبحت قديمة ، شديدة التقارب فقط!". هذا بيان جريء ، لكنه لا يعكس الواقع تمامًا.
في الحقيقة ، يتجه سوق التخزين بالفعل نحو حلول متقاربة ومتشابهة ، ولكن هناك دائمًا "لكن".
أولاً ، لا يمكن إعادة بناء مراكز البيانات والبنى التحتية لتكنولوجيا المعلومات التي تم بناؤها وفقًا للمخطط الكلاسيكي مع التخزين على هذا النحو ، وبالتالي فإن تحديث واستكمال هذه البنى التحتية لا يزال إرثًا لمدة 5-7 سنوات.
ثانيًا ، تلك البنى التحتية التي يتم بناؤها الآن في الغالب (بمعنى الاتحاد الروسي) يتم بناؤها وفقًا للمخطط الكلاسيكي باستخدام أنظمة التخزين ، وليس لأن الناس لا يعرفون شيئًا عن التقارب الفائق ، ولكن نظرًا لأن السوق شديد التقارب جديد ، فإن الحلول و لم يتم وضع المعايير بعد ، ولم يتم تدريب متخصصي تكنولوجيا المعلومات بعد ، وهناك خبرة قليلة ، ولكن من الضروري بناء مراكز بيانات هنا والآن. وهذا الاتجاه يستمر لمدة 3-5 سنوات أخرى (ثم إرث آخر ، انظر النقطة 1).
ثالثًا ، وجود قيود تقنية بحتة في حالات التأخير الصغيرة الإضافية البالغة 2 مللي ثانية لكل عملية كتابة (دون مراعاة ذاكرة التخزين المؤقت المحلية ، بالطبع) ، وهي عبارة عن دفعة للتخزين الموزع.
حسنًا ، دعونا لا ننسى استخدام الخوادم المادية الكبيرة التي تحب التحجيم الرأسي لنظام القرص الفرعي.
هناك العديد من المهام الضرورية والشائعة حيث يتصرف نظام التخزين بشكل أفضل من نظام GCS. هنا ، بالطبع ، هؤلاء المصنِّعون الذين ليس لديهم أنظمة تخزين في مجموعة منتجاتهم سيختلفون معنا ، لكننا على استعداد للتجادل مع العقل. بالطبع ، كمطورين لكلا المنتجين ، في أحد المنشورات المستقبلية سنقارن بالتأكيد بين أنظمة التخزين ونظام GCS ، حيث سنبين بوضوح أيهما أفضل في ظل أي ظروف.
وأين ستعمل الحلول شديدة التقارب بشكل أفضل من التخزين؟
بناءً على الأطروحة أعلاه ، يمكن استخلاص ثلاثة استنتاجات واضحة:
- عندما يكون التأخير الإضافي في الكتابة بمقدار 2 مللي ثانية ، والذي يحدث بشكل مطرد في أي منتج (الآن لا نتحدث عن المواد التركيبية ، يمكنك إظهار نانوثانية على المواد التركيبية) ، ليس حرجًا ، يكون التقارب الفائق مناسبًا.
- حيث يمكن تحويل الحمل من الخوادم المادية الكبيرة إلى العديد من الخوادم الافتراضية الصغيرة وتوزيعها بين العقد ، سيعمل التقارب المفرط أيضًا بشكل جيد هناك.
- عندما يكون القياس الأفقي أكثر أهمية من القياس الرأسي ، ستعمل GKS أيضًا بشكل جيد هناك.
ما هي هذه الحلول؟
- جميع خدمات البنية التحتية القياسية (خدمة الدليل ، البريد ، EDMS ، خوادم الملفات ، أنظمة ERP و BI الصغيرة أو المتوسطة ، إلخ). نسمي هذا "الحوسبة العامة".
- البنية التحتية لمزود الخدمات السحابية حيث يكون من الضروري بسرعة وتوحيد معايير أفقية التوسع و "تقسيم" عدد كبير من الأجهزة الافتراضية للعملاء بسهولة.
- البنية التحتية الافتراضية لسطح المكتب (VDI) ، حيث يبدأ تشغيل العديد من الأجهزة الظاهرية المخصصة الصغيرة و "تطفو" بهدوء داخل مجموعة موحدة.
- شبكات الفروع ، حيث تحتاج في كل فرع إلى الحصول على بنية أساسية قياسية قابلة للتسامح مع الأخطاء ، ولكن في نفس الوقت بنية تحتية غير مكلفة تتكون من 15 إلى 20 جهازًا افتراضيًا.
- أي حوسبة موزعة (خدمات البيانات الضخمة ، على سبيل المثال). حيث لا يكون الحمل "في العمق" ، بل "في العرض".
- بيئات الاختبار التي يُسمح فيها بتأخيرات صغيرة إضافية ، ولكن توجد قيود على الميزانية ، لأن هذه اختبارات.
في الوقت الحالي ، لقد صنعنا AERODISK vAIR لهذه المهام ونركز عليها (حتى الآن بنجاح). ربما سيتغير هذا قريبًا ، لأن. العالم لا يقف ساكنا.
لذلك ...
بهذا يختتم الجزء الأول من سلسلة كبيرة من المقالات ، في المقالة التالية سنتحدث عن بنية الحل والمكونات المستخدمة.
سنكون سعداء للأسئلة والاقتراحات والنزاعات البناءة.
المصدر: www.habr.com