كل مطور يريد منصة تطوير خاصة به. كل اختبار يريد منضدة الاختبار الخاصة به. وكل أخصائي في مرحلة ما قبل الإنتاج يريد حامله الخاص - من أجل التحقق من كل شيء أخيرًا والتدرب على الإطلاق في المنتج. عندما تتقارب كل قائمة الرغبات هذه في المعالجة - أحد أكبر أنظمة البنك وأكثرها نشاطًا - تجعلك تكاليف البنية التحتية تخدش رأسك وتبحث عن "خيارات". سنخبر عما وجدناه في هذا المنشور.
يبلغ حجم قواعد بيانات المعالجة في شركتنا حوالي 6 تيرابايت. في نسخة واحدة من قواعد البيانات ، يتداخل المطورون مع بعضهم البعض ، وبالتالي فإن المساحة الفعلية التي تشغلها القواعد تنمو بسرعة وبشكل متناسب. على الرغم من مدى السرعة ... سريع جدًا لخدمة المرافقة وليس بالسرعة الكافية لأولئك الذين يحتاجون إلى نسخ من قواعد البيانات. وها هو السبب.
للاختبار ، من الضروري أن يكون حامل الاختبار متسقًا تمامًا مع الإصدار الحالي من الإنتاج (وينطبق الشيء نفسه على حامل ما قبل الإنتاج). يتم نسخ النسخة الاحتياطية الرئيسية للنظام طوال اليوم ، ثم يتم نشرها على الحامل. خلال هذه العمليات الطويلة ، لا تتوفر الحوامل ، لذلك يتم نقل النسخ إلى عطلات نهاية الأسبوع والعطلات عندما لا يعمل أحد مع المدرجات. نحصل على تأخير من 1 إلى 5 أيام. للموافقة المبدئية على عملية النسخ نفسها ، يستغرق الأمر أيضًا بعض الوقت - لدينا العديد من مقاعد الاختبار ، عادةً من ثلاثة إلى ستة. نضيف 2-3 أيام لتنسيق وقت الخمول. قبل الوصول إلى المسؤول للحصول على الموافقة ، لا يزال التطبيق في قائمة الانتظار. في المجموع ، نحصل على تأخير كبير جدًا.
ما الذي ساعد Delphix
ما الذي يمكن أن يسرع العملية ويوفر المساحة؟ المحاكاة الافتراضية لقاعدة البيانات. أخذنا بعين الاعتبار خيارات مختلفة: Oracle SnapClone و NetApp + Oracle Cloud ، فقط لقطات على المصفوفات. كل شيء يتطلب إعدادًا معقدًا. علاوة على ذلك ، تعمل حلول Oracle مع قواعد بيانات Oracle فقط.
ثم نظرت إلى دلفكس. إنه سهل التنفيذ ، ويدعم قواعد بيانات مختلفة - Oracle و SQL Server و DB2 و Sybase ASE. يتم توفير واجهة لجميع العمليات. من خلاله ، يمكن للمطورين والمختبرين إدارة نسخهم بشكل مستقل - التحديث ، حفظ / استعادة الحالة ، التوقف / البدء ، إلخ. هناك أيضًا واجهة برمجة تطبيقات و CLI للتكامل مع أنظمة CI / CD أو عملياتها.
لا يستغرق نشر Delphix نفسه وقتًا طويلاً - عدة ساعات. يمكن توصيل المصدر لفترة أطول بكثير ، هنا يتناسب الوقت مع الحجم. في حالتنا ، كان المصدر نسخة مبيعات من قاعدة البيانات ، واستغرق اتصالها يومًا تقريبًا. لا يتطلب إعداد المصدر والخوادم لاستنساخ قاعدة البيانات عمالة خاصة. على الخادم الهدف ، تحتاج إلى تثبيت ORACLE_HOME المناسب ، وكذلك إنشاء مستخدم خاص للاتصال. بالنسبة إلى النسخ التجريبية الافتراضية ، نستخدم نفس الخوادم التي كانت بها نسخ فعلية.
يسمح لك Delphix بإنشاء منصات اختبار في الوقت الفعلي تقريبًا ، دون أي تنسيق ، لأن الحوامل معزولة تمامًا عن بعضها البعض. يتم قضاء بعض الوقت فقط في تحديث قاعدة البيانات إلى الحالة الحالية - من 20 دقيقة إلى عدة ساعات ، لا يوجد أي سؤال حول أي يوم.
نحاول إجراء اختبار الإجهاد في ظروف قريبة قدر الإمكان من المنتج. إذا كان همز على الأقراص المادية - ثم يقف الحمل أيضا. في هذه الحالة ، يساعد زر Delphix V2P ، والذي يسمح لك بإنشاء قاعدة بيانات "صادقة" من قاعدة بيانات افتراضية.
بالنسبة لتوفير مساحة القرص ، فإن قراءات لوحة Delphix الخاصة بنا ، بالطبع ، تكذب - انخفاض حجمه بمقدار 73 ضعفاً رائع للغاية. في معالجتنا ، تحتل نسخة من البيع مع لقطات يومية وسجلات المعاملات المؤرشفة لمدة أسبوعين (200 غيغابايت في اليوم) 4.5 تيرابايت من مساحة القرص. 1.5 تيرابايت آخر - تسعة نسخ من الأحجام من 50 إلى 500 جيجابايت ، كل منها يخزن أيضًا تاريخًا من اللقطات اليومية. في المجموع ، يتم الحصول على 6 تيرابايت.
نضيف 15٪ أخرى من المساحة الحرة (900 جيجا بايت) حتى تعمل Delphix بشكل طبيعي. وبالتالي ، عند إنفاق حوالي 7 تيرابايت فقط ، يمكننا الحصول على نسخة تجريبية من البيانات ذات الصلة في أي وقت خلال الأسبوعين الماضيين.
في السابق ، من أجل تخزين تسع نسخ مادية من قاعدة البيانات في 6 تيرابايت ، كنا بحاجة إلى 54 تيرابايت (أو ~ 20 تيرابايت مع مراعاة الضغط بمقدار 2-3 مرات على التخزين). وعلى عكس النظام الجديد ، هنا لم يتمكن المطورون من إدارة هذه النسخ واستعادة الحالات السابقة - عندما تم إتلاف البيانات ، كان من الممكن فقط إعادة التحميل من نسخة من البيع.
تسمح لك Delphix أيضًا بسرعة إنشاء فروع مختلفة للحاوية نفسها لمشاريع مختلفة - وكل هذا في أقل وقت ممكن. لا يخشى المطورون من تلف البيانات ، يمكنهم التراجع واستعادة حالتهم السابقة. هذا يعطي دفعة للأداء.
ولكن هناك فروق دقيقة ...
الانطباعات من Delphix إيجابية في الغالب ، على الرغم من أن كل شيء ليس مثاليًا. المشكلة الأكبر هي استخدام الأقراص. يتم تخزين كل كتلة بيانات مرة واحدة فقط لجميع النسخ الافتراضية ، وإلى أن تتوقف جميع النسخ الافتراضية عن استخدام الكتلة ، فلا يمكن حذفها. قد تنشأ مشاكل تنظيمية هنا - ليس كل المستخدمين على استعداد لدعم دورة الحياة القصيرة لمواقفهم. إذا كان مقعد الاختبار موجودًا على نسخة قديمة ، فسأبيعها. نقوم بحل هذه المشكلة على نطاق واسع ، من خلال توسيع الأقراص ، والتي يمكن القيام بها دون مقاطعة الخدمة. نتأكد من توفير 15٪ من المساحة الخالية دائمًا. إذا كان أصغر ، فسوف يتوقف النظام ببساطة عن إجراء أي عمليات بنسخ افتراضية. على الرغم من أن القواعد نفسها ستظل متاحة.
بالنسبة للأنظمة ذات الإدخال / الإخراج للقرص المكثف ، من المحتمل أن يكون عرض النطاق الترددي للشبكة عاملاً مقيدًا. اعتمادًا على ملف تعريف التحميل المحدد ، قد يبدأ النظام في العمل بشكل أفضل مع المحاكاة الافتراضية. اعتمادًا على الحمل ، يبلغ متوسط زمن انتظار القراءة المتسلسلة لملف db 5-10 مللي ثانية ، وهو أمر جيد جدًا حتى بالنسبة للأنظمة الصناعية.
محركات أقراص Delphix "الكلاسيكية" متصلة بأي طريقة تدعم ESX ، ولدى البائع قائمة من التوصيات حول كيفية القيام بذلك بأقصى أداء. نستخدم SAN. يقدم النظام نفسه الأقراص التي توجد عليها ملفات قاعدة البيانات الافتراضية ، فقط عبر بروتوكول NFS. لهذا السبب ، يجب أن تكون حذرًا بشأن النطاق الترددي للقناة وازدحامها. في حالتنا ، من المنطقي وضع ملفات البيانات الخاصة بـ Delphix فقط على صفائف القرص بحيث لا يؤثر أي نشاط في البنك على سرعة الإدخال / الإخراج لقواعد البيانات الافتراضية.
الآن نحن نعمل على Delphix 5.1.9 ، ولكن انظر إلى الإصدار 5.2 - حيث تركت واجهة المستخدم الفلاش ، ووفقًا للمورد ، أصبحت أكثر ملاءمة. أعجب Delphix زملائنا ، وبعد المعالجة ، نفكر في نقل الملف الشخصي ، وإدارة علاقات العملاء ، والخدمات المصرفية عبر الإنترنت إلى هذا النظام من المطورين.