مرحبا يا هبر!

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

في بداية عام 2018 ، أطلقنا (وأطلقنا!) وحدة التخزين الخاصة بنا المتوافقة مع S3 بنسبة 100٪ استنادًا إلى Cloudian HyperStore. كما اتضح ، فإن الشبكة لديها عدد قليل جدًا من المنشورات باللغة الروسية حول Cloudian نفسها ، وحتى أقل حول التطبيق الفعلي لهذا الحل.

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

إذا كنت تقوم ببناء وحدة تخزين S3 أو كنت مشغولًا في صيانتها ، فستجد هذه المقالة مفيدة لك.

بادئ ذي بدء ، سأشرح لماذا وقع اختيارنا على Cloudian. الأمر بسيط: هناك عدد قليل جدًا من الخيارات القيمة في هذا المكان. على سبيل المثال ، قبل عامين ، عندما كنا نفكر فقط في البناء ، لم يكن هناك سوى ثلاثة خيارات:

• بوابة CEHP + RADOS ؛
  
• مينيو
  
• Cloudian HyperStore.
  

بالنسبة لنا ، كمزود خدمة ، كانت العوامل الحاسمة هي: مستوى عالٍ من المراسلات بين واجهة برمجة تطبيقات التخزين و Amazon S3 الأصلي ، وتوافر الفوترة المدمجة ، وقابلية التوسع مع دعم تعدد المناطق ووجود خط ثالث من دعم البائعين. كلودان لديه كل هذا.

ونعم ، الشيء الأكثر أهمية (بالتأكيد!) هو أن DataLine و Cloudian لديهما ألوان مشتركة مماثلة. يجب أن تعترف أننا لا نستطيع مقاومة مثل هذا الجمال.



لسوء الحظ ، لا يعد Cloudian البرنامج الأكثر شيوعًا ، ولا توجد معلومات عنه في RuNet. اليوم سنقوم بتصحيح هذا الظلم ونتحدث معك حول ميزات بنية HyperStore ، ودراسة أهم مكوناتها والتعامل مع الفروق المعمارية الرئيسية. دعونا نبدأ بالأبسط ، وهي - ما هو Cloudian تحت غطاء المحرك؟

كيف يعمل Cloudian HyperStore Storage

دعونا نلقي نظرة على الرسم البياني ونرى كيف يعمل الحل السحابي.


مخطط تخزين المكونات الرئيسية.

كما نرى ، يتكون النظام من عدة مكونات رئيسية:

• التحكم في إدارة Cloudian - وحدة تحكم الإدارة ؛
• الخدمة الإدارية - وحدة الإدارة الداخلية ؛
• خدمة S3 - الوحدة المسؤولة عن دعم بروتوكول S3 ؛
• خدمة HyperStore - خدمة التخزين الفعلية ؛
• أباتشي كاساندرا - مستودع مركزي لبيانات الخدمة ؛
• Redis - للبيانات الأكثر قراءة .

سيكون عمل الخدمات الرئيسية ، S3 Service و HyperStore Service ، من أهم اهتماماتنا ، ثم سننظر بعناية في عملهم. ولكن أولاً ، من المنطقي معرفة كيفية ترتيب توزيع الخدمات في المجموعة وما هو التسامح مع الخطأ وموثوقية تخزين البيانات لهذا الحل ككل.




نعني بالخدمات المشتركة في الرسم البياني أعلاه الخدمات S3 و HyperStore و CMC و Apache Cassandra . للوهلة الأولى ، كل شيء جميل وأنيق. ولكن عند الفحص الدقيق ، اتضح أن فشل عقدة واحدة فقط هو الذي تم حله بشكل فعال. ويمكن أن يكون الفقدان المتزامن للعقدتين في وقت واحد قاتلاً لتوافر العنقود - يحتوي Redis QoS (على العقدة 2) على عبد واحد فقط (على العقدة 3). نفس الصورة مع خطر فقدان إدارة الكتلة - خادم Puppet موجود فقط على عقدتين (1 و 2). ومع ذلك ، فإن احتمال فشل عقدتين في وقت واحد منخفض جدًا ، ويمكنك التعايش معه.

ومع ذلك ، لزيادة موثوقية التخزين ، نستخدم 4 عقد في DataLine بدلاً من الثلاثة الحد الأدنى. يتم الحصول على توزيع الموارد التالية:



هناك فارق بسيط آخر يلفت انتباهك على الفور - لا يتم وضع بيانات اعتماد Redis على كل عقدة (كما يمكن افتراضها من المخطط الرسمي أعلاه) ، ولكن فقط على 3 منها. في هذه الحالة ، يتم استخدام بيانات اعتماد Redis لكل طلب وارد. اتضح أنه بسبب الحاجة إلى الذهاب إلى Redis لشخص آخر ، هناك بعض عدم التوازن في أداء العقدة الرابعة.

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

هكذا يبدو مخطط الترحيل على 6 عقد:



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

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

من وجهة نظر أمن البيانات ، كل شيء أكثر إثارة للاهتمام. يتم تخزين بيانات تعريف الكائن في Apache Cassandra ، ويتم نسخ كل سجل إلى 3 من أصل 4 عقد. يُستخدم عامل النسخ المتماثل 3 أيضًا لتخزين البيانات ، ولكن يمكنك تكوين عامل أكبر. وهذا يضمن سلامة البيانات حتى في حالة الفشل المتزامن ل 2 من 4 عقد. وإذا كان لديك الوقت لإعادة موازنة الكتلة ، فلن تفقد شيئًا مع عقدة واحدة متبقية. الشيء الرئيسي هو أن يكون لديك مساحة كافية.



هذا ما يحدث عندما تفشل عقدتان. يوضح الرسم البياني بوضوح أنه حتى في هذه الحالة ، تظل البيانات آمنة

في الوقت نفسه ، سيعتمد توفر البيانات والتخزين على استراتيجية ضمان الاتساق. بالنسبة للبيانات والبيانات الوصفية والقراءة والكتابة ، يتم تكوينه بشكل منفصل.

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

معالجة الاستعلام في Cloudian

أدناه سننظر في نظامين لمعالجة الطلبات الواردة في Cloudian HyperStore و PUT و GET. هذه هي المهمة الرئيسية لخدمة S3 و HyperStore.

لنبدأ بكيفية معالجة طلب الكتابة:



من المؤكد أنك لاحظت أن كل طلب يولد الكثير من عمليات التحقق واسترداد البيانات ، على الأقل 6 نتائج من مكون إلى آخر. ومن هنا تظهر تأخيرات التسجيل واستهلاك الوقت المرتفع لوحدة المعالجة المركزية عند العمل مع الملفات الصغيرة.

يتم نقل الملفات الكبيرة عن طريق القطع. لا يتم اعتبار القطع المنفصلة كطلبات منفصلة ولا يتم إجراء بعض عمليات التحقق.

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



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

تخزين البيانات ونسخها

كما ترى من الرسوم البيانية أعلاه ، يدعم Cloudian العديد من أنظمة تخزين البيانات والنسخ:

النسخ المتماثل - باستخدام النسخ المتماثل ، من الممكن الاحتفاظ بعدد مخصص من نسخ كل كائن بيانات في النظام وتخزين كل نسخة على عقد مختلفة. على سبيل المثال ، باستخدام النسخ المتماثل 3X ، يتم إنشاء 3 نسخ من كل كائن ، وكل نسخة "تقع" على العقدة الخاصة به.

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

على سبيل المثال ، في تشفير المحو ، وفقًا لصيغة 4 + 2 (4 أجزاء من البيانات بالإضافة إلى جزأين من كود التكرار) ، يتم تقسيم كل كائن إلى 6 أجزاء فريدة مخزنة على ست عُقد مختلفة ، ويمكن استعادة هذا الكائن وقراءته في حالة توفر 4 أجزاء من 6 أجزاء .

وتتمثل ميزة تشفير المحو مقارنةً بالنسخ المتماثل في توفير المساحة ، وإن كان ذلك على حساب زيادة كبيرة في حمل المعالج ، وتفاقم سرعة الاستجابة والحاجة إلى إجراءات خلفية للتحكم في اتساق الأشياء. في أي حال ، يتم تخزين البيانات الوصفية بشكل منفصل عن البيانات (في Apache Cassandra) ، مما يزيد من مرونة وموثوقية الحل.

باختصار حول الوظائف الأخرى لـ HyperStore

كما كتبت في بداية هذه المقالة ، تم دمج العديد من الأدوات المفيدة في HyperStore. من بينها:

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

ومع ذلك ، لا يزال Cloudian HyperStore غير مثالي. على سبيل المثال ، لسبب ما ، لا يمكنك نقل حساب موجود إلى مجموعة أخرى أو تعيين مجموعات متعددة لسجل واحد. لا يمكن إنشاء تقارير الفواتير المؤقتة - لن تتلقى جميع التقارير إلا بعد إغلاق فترة إعداد التقارير. لذلك ، لا العملاء ولا يمكننا معرفة مقدار نمو الحساب في الوقت الفعلي.

منطق كلوديان هايبر ستور

سنقوم الآن بالتعمق أكثر وننظر إلى الأكثر إثارة للاهتمام في أي تخزين SDS - منطق توزيع الكائنات حسب العقد. في حالة التخزين السحابي ، يتم تخزين البيانات الوصفية بشكل منفصل عن البيانات نفسها. بالنسبة للبيانات الوصفية ، يتم استخدام Cassandra ، للبيانات ، حل HyperStore الخاص.

لسوء الحظ ، حتى الآن لا توجد ترجمة رسمية لوثائق Cloudian إلى الروسية على الإنترنت ، لذا سأقوم بنشر ترجمة لأهم الأجزاء من هذه الوثائق أدناه.

دور أباتشي كاساندرا في هايبر ستور

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

• عند إنشاء كائن كاساندرا جديد (المفتاح الأساسي وقيمه المقابلة) ، يتم تجزئته ، ويتم استخدام التجزئة لربط الكائن مع vNode محدد. يقوم النظام بفحص المضيف الذي تم تعيين هذا vNode له ، ثم يتم تخزين النسخة المتماثلة الأولى لكائن Cassandra على محرك الأقراص Cassandra على ذلك المضيف.
  
• على سبيل المثال ، لنفترض أن مضيفًا معينًا لـ 96 vNodes موزعة عبر عدة أقراص بيانات HyperStore. سيتم كتابة كائنات كاساندرا التي تقع قيم تجزئتها ضمن نطاقات الرمز المميز لأي من 96 vNodes إلى محرك أقراص كاساندرا على هذا المضيف.
  
• ترتبط النسخ المتماثلة الإضافية لكائن كاساندرا (يعتمد عدد النسخ المتماثلة على التكوين الخاص بك) مع vNodes برقم التسلسل التالي ويتم تخزينها على العقدة التي تم تعيين هذه vNodes لها ، شريطة أن يتم تخطي vNodes إذا لزم الأمر ، بحيث يتم تخزين كل نسخة طبق الأصل لكائن كاساندرا على آخر الجهاز المضيف.
  

كيف يعمل التخزين هايبر ستور

يعتمد وضع وتكرار كائنات S3 في كتلة HyperStore على نظام تخزين مؤقت متناسق يستخدم مساحة الرمز الصحيح في النطاق من 0 إلى 2 ¹²⁷ -1. يتم تعيين الرموز المميزة الصحيحة للعقد HyperStore. لكل كائن S3 ، يتم حساب التجزئة حيث يتم تحميله في التخزين. يتم تخزين الكائن في العقدة التي تم تعيينها على أقل قيمة للرمز المميز ، أكبر من أو يساوي قيمة التجزئة للكائن. يتم تنفيذ النسخ المتماثل أيضًا عن طريق تخزين الكائن على العقد التي تم تعيين الرموز المميزة لها ، والتي لها قيمة دنيا.

في التخزين "الكلاسيكي" المتسق القائم على التجزئة ، يتم تعيين رمز مميز واحد إلى عقدة فعلية واحدة. يستخدم نظام Cloudian HyperStore وظائف "العقدة الافتراضية" (vNode) المقدمة في Cassandra في الإصدار 1.2 ويوسعها - يتم تعيين عدد كبير من الرموز المميزة لكل مضيف فعلي (بحد أقصى 256). في الواقع ، تتكون مجموعة التخزين من عدد كبير جدًا من "العقد الافتراضية" مع عدد كبير من العقد الافتراضية (الرموز) على كل مضيف فعلي.

يعين نظام HyperStore مجموعة منفصلة من الرموز المميزة (العقد الافتراضية) لكل قرص على كل مضيف فعلي. كل قرص على المضيف مسؤول عن مجموعته الخاصة من الكائنات. يؤثر فشل القرص فقط على النسخ المتماثلة للكائنات الموجودة عليه. ستستمر محركات الأقراص الأخرى في المضيف في العمل والاضطلاع بمسؤوليات تخزين البيانات الخاصة بها.

نقدم مثالاً ونأخذ في الاعتبار مجموعة من 6 مضيفي HyperStore ، كل منها يحتوي على 4 أقراص تخزين S3. افترض أنه تم تعيين 32 رمزًا مميزًا لكل مضيف فعلي وأن هناك مساحة رمزية مبسطة من 0 إلى 960 ، وأن قيمة 192 رمزًا في هذا النظام (6 مضيفين لـ 32 رمزًا) هي 0 ، 5 ، 10 ، 15 ، 20 ، وهكذا حتى 955.

يوضح الرسم البياني أدناه توزيعًا محتملاً واحدًا للرموز المميزة عبر المجموعة. يتم توزيع 32 رمزًا مميزًا لكل مضيف بالتساوي عبر 4 أقراص (8 رموز مميزة لكل قرص) ، ويتم توزيع الرموز المميزة بشكل عشوائي عبر المجموعة.



لنفترض الآن أنك قمت بتكوين HyperStore على 3X نسخ كائنات S3. لنوافق على تحميل كائن S3 في النظام ، وتعطينا خوارزمية التجزئة المطبقة على اسمه قيمة التجزئة 322 (في مساحة التجزئة المبسطة). يوضح الرسم البياني أدناه كيف سيتم تخزين ثلاث مثيلات أو نسخ متماثلة لكائن في كتلة:

• مع قيمة التجزئة للاسم 322 ، يتم تخزين النسخة المتماثلة الأولى من الكائن على 325 رمز مميز ، لأنه هذه هي أصغر قيمة رمزية أكبر من أو يساوي قيمة التجزئة للكائن. 325 رمز مميز (مظلل باللون الأحمر على الرسم التخطيطي) تم تعيينها لـ hyperstore2: Disk2. وفقًا لذلك ، يتم تخزين النسخة المتماثلة الأولى من الكائن هناك.
  

• يتم تخزين النسخة المتماثلة الثانية على القرص الذي تم تعيينه الرمز المميز التالي (330 ، مظلل باللون البرتقالي) ، أي على hyperstore4: Disk2.
  
• يتم حفظ النسخة المتماثلة الثالثة إلى القرص ، الذي تم تعيين الرمز المميز التالي بعد 330 - 335 (أصفر) ، على hyperstore3: Disk3.
  

سأضيف تعليقًا: من وجهة نظر عملية ، فإن هذا التحسين (توزيع الرموز ليس فقط بين العقد المادية ، ولكن أيضًا بين الأقراص الفردية) مطلوب ليس فقط لضمان إمكانية الوصول ، ولكن أيضًا للتوزيع الموحد للبيانات بين الأقراص. في هذه الحالة ، لا يتم استخدام صفيف RAID ، ويتم التحكم في منطق تخصيص البيانات بالكامل على الأقراص بواسطة HyperStore نفسه. من ناحية ، إنه مريح ومُحكم ؛ في حالة فقدان القرص ، سيتم إعادة توازن كل شيء من تلقاء نفسه. من ناحية أخرى ، أنا شخصياً أثق في المزيد من وحدات تحكم RAID الجيدة - بعد كل شيء ، تم تحسين منطقهم لسنوات عديدة. لكن هذه كلها تفضيلاتي الشخصية ، حول عضلات ومشاكل حقيقية ، لم نكتشف HyperStore أبدًا ، إذا اتبعنا توصيات البائع عند تثبيت البرنامج على الخوادم الفعلية. لكن محاولة استخدام المحاكاة الافتراضية والأقراص الافتراضية على سطح القمر نفسه على نظام التخزين فشلت ، عند التحميل الزائد على نظام التخزين أثناء اختبار التحميل ، أصبح HyperStore مجنونًا ومبعثرًا من البيانات بشكل غير متساو تمامًا ، مما يؤدي إلى انسداد بعض الأقراص وعدم لمس الآخرين.

محرك الجهاز داخل كتلة

تذكر أن لكل مضيف 32 رمزًا مميزًا ، ويتم توزيع الرموز المميزة لكل مضيف بالتساوي بين أقراصه. دعونا نلقي نظرة فاحصة على hyperstore2: Disk2 (في الرسم البياني أدناه). نرى أن الرموز المميزة 325 و 425 و 370 وما إلى ذلك يتم تعيينها لهذا القرص.

نظرًا لتكوين الكتلة للنسخ المتماثل 3X ، سيتم تخزين ما يلي على hyperstore2: Disk2:

وفقًا لـ 325 قرص مميز:

• النسخ المتماثلة الأولى من الكائنات بقيمة تجزئة من 320 (حصريًا) إلى 325 (ضمناً) ؛
• النسخ المتماثلة الثانية للكائنات بقيمة تجزئة من 315 (حصريًا) إلى 320 (ضمناً) ؛
• النسخ المتماثلة الثالثة للكائنات بقيمة تجزئة من 310 (حصريًا) إلى 315 (ضمناً).

وفقًا لرمز القرص 425:

• النسخ المتماثلة الأولى من الكائنات بقيمة تجزئة من 420 (حصريًا) إلى 425 (ضمناً) ؛
• النسخ المتماثلة الثانية للكائنات ذات قيمة تجزئة من 415 (حصريًا) إلى 420 (ضمنيًا) ؛
• النسخ المتماثلة الثالثة للكائنات بقيمة تجزئة من 410 (حصريًا) إلى 415 (ضمناً).

وهكذا دواليك.

كما لوحظ سابقًا ، عند وضع النسخ المتماثلة الثانية والثالثة ، قد يقوم HyperStore في بعض الحالات بتمرير الرموز المميزة حتى لا يتم تخزين أكثر من نسخة واحدة من الكائن على عقدة فعلية واحدة. هذا يلغي استخدام hyperstore2: disk2 كمخزن للنسخ المتماثلة الثانية أو الثالثة لنفس الكائن.



إذا تعطل القرص 2 على الأقراص 1 و 3 و 4 ، سيستمر تخزين البيانات ، وسيتم تخزين الكائنات الموجودة على القرص 2 في الكتلة ، لأن تم نسخها إلى مضيفين آخرين.

التعليق: نتيجة لذلك ، يعتمد توزيع النسخ المتماثلة و / أو أجزاء من الكائنات في مجموعة HyperStore على تصميم كاساندرا ، الذي تم تطويره لتلبية احتياجات تخزين الملفات. , , , , «» . . . , : , , .

, HyperStore . - . . () , .
, , , «Multi-Data Center Deployments».

HyperStore -. DC1 DC2. - 3 . , , 32 (vNodes), 0 960. -, 192 — 32 6 . .

, S3 -.

, S3 942 2 -:

• vNode 945 ( ), DC2, hyperstore5:Disk3.
  
• vNode 950 ( ) DC2, hyperstore6:Disk4.
  
• vNode 955 DC2, , vNode .
  
• vNode 0 () — DC1, hyperstore2:Disk3. , (955) (0).
  
• vNode (5) DC2, , vNode .
  
• vNode 10 () — DC1, hyperstore3:Disk3.
  

: , , , , . , .

Cloudian. , , . , , , , .
S3 DataLine, , !