من المغري التفكير في أن مزود الخدمة السحابية سيضمن التوافر العالي لتطبيقاتك المصرفية الهامة المستندة إلى السحابة. المشكلة هي أنهم في الحقيقة لا يفعلون ذلك.
ربما ساعدك موفر السحابة في تكوين مجموعة من الأجهزة الافتراضية (VMs) التي تنفد من عدة مراكز بيانات أو مناطق توافر (AZs). ربما تكون قد نفذت نظامًا آليًا لتجاوز الفشل للتأكد من أن الجهاز الظاهري الاحتياطي في التكوين يمكن أن يتولى فورًا إذا توقف الجهاز الظاهري الأساسي فجأة. يبدو الأمر وكأنه يجب أن يوفر توافرًا عاليًا ، أليس كذلك؟
لكن انظر عن كثب إلى اتفاقية مستوى الخدمة (SLA) التي تحدد التوافر العالي: تضمن اتفاقية مستوى الخدمة (SLA) إمكانية الوصول إلى واحد على الأقل من الأجهزة الافتراضية في نظامك بنسبة 99.9٪ على الأقل أو حتى 99.99٪ من الوقت. لكن هذا ليس ضمانًا لتوافر التطبيق أو البيانات. إذا لم يتمكن الجهاز الظاهري المتبقي من الوصول إلى البنية التحتية للتخزين حيث توجد تطبيقاتك المصرفية وبياناتك ، فإن تطبيقاتك المهمة تكون في وضع عدم الاتصال بشكل فعال.
ضمان الوصول إلى السحابة
كيف يمكنك التأكد من أن تطبيقاتك المصرفية الهامة وبياناتك تظل قابلة للوصول إلى حد كبير في السحابة أو في تكوين مختلط محلي / سحابي ، إذا كان تكوين التكنولوجيا الأساسية لتجاوز الفشل الآلي عبر مناطق توافر خدمات متعددة غير كافٍ؟
لنبدأ بالقول إن وجود أجهزة ظاهرية مجمعة منتشرة بين مناطق توافر خدمات متعددة أمر بالغ الأهمية لضمان التوفر العالي (HA) لتطبيقاتك وبياناتك الرئيسية. ما تحتاجه بالإضافة إلى ذلك ، هو استراتيجية للتأكد من أن كل من هذه الأجهزة الافتراضية لديها إمكانية الوصول إلى التطبيقات والبيانات الهامة التي تريد الاستمرار في تشغيلها. هذا هو المكان الذي تتباعد فيه الطرق التقليدية لـ HA عندما يتعلق الأمر بالسحابة.
في توصيف HA التقليدي - بمعنى محلي - ، قد تقوم بتكوين مجموعة تجاوز الفشل تتكون من عدة وحدات خدمة أو VM وشبكة منطقة تخزين (SAN) ، حيث توجد تطبيقاتك وبياناتك. يمكن لأي خادم أو جهاز افتراضي في المجموعة أن يتفاعل مع التطبيقات والبيانات الموجودة في شبكة التخزين SAN ، لذلك إذا توقف الجهاز الظاهري الذي يقوم بتشغيل تطبيق رئيسي بشكل نشط فجأة ، فإن الكتلة ستفشل تلقائيًا في جهاز افتراضي آخر يمكنه التفاعل مع SAN والبدء في تشغيل تطبيق وتحديث نفس قاعدة البيانات التي كان الجهاز السابق يستخدمها.
التكوين للسحابة
على الرغم من ذلك ، في السحابة ، لا يوجد خيار حقيقي لإنشاء SAN مشترك. هناك بعض خيارات التخزين المشتركة ، لكنها ليست مصممة لتوفير أداء أو مستويات HA التي تتطلبها تطبيقاتك المصرفية الهامة. بدلاً من ذلك ، تعتمد تكوينات HA المستندة إلى مجموعة النظراء على التخزين عالي الأداء المرفق بكل من الأجهزة الظاهرية في المجموعة. عندما يقوم جهاز افتراضي معين بتشغيل تطبيق ، فإنه يتفاعل مع البيانات المخزنة في قاعدة بيانات موجودة في التخزين المرفق بهذا الجهاز الظاهري.
إذن ، مفتاح HA للتطبيقات المصرفية المستندة إلى السحابة هو التأكد من أن كل جهاز افتراضي في مجموعتك لديه دائمًا نفس التطبيقات ونفس البيانات. بهذه الطريقة ، إذا أصبح الجهاز الظاهري الأساسي في المجموعة مظلمًا فجأة ، يمكن أن تفشل المجموعة تلقائيًا في جهاز افتراضي افتراضي ، يمكن لأي واحد منها بدء تشغيل التطبيق والتفاعل مع البيانات على الفور نظرًا لوجود نسخة من التطبيق والبيانات في تخزينها المرفق.
يمكن لمزود الخدمة السحابية تكوين الأجهزة الافتراضية بسهولة والتي ستوفر مستويات الأداء والتوافر التي تتطلبها تطبيقاتك الهامة. يمكنه أيضًا إرفاق أنظمة تخزين عالية الأداء بتلك الأجهزة الظاهرية ، ويمكنه تكوين مجموعتك لتجاوز الفشل تلقائيًا عبر مناطق توافر خدمات متعددة. بعد ذلك ، تحتاج إلى نشر آلية تعمل على أتمتة النسخ المتماثل المتزامن للبيانات بين جميع أنظمة التخزين المرتبطة بـ VMs في مجموعة تجاوز الفشل الخاصة بك.
حلول نسخ البيانات
لديك عدد من الخيارات عندما يتعلق الأمر بحلول نسخ البيانات.
إذا كانت مجموعتك تعتمد على Windows وكنت تستخدم Microsoft SQL Server ، فيمكنك استخدام ميزة مجموعات التوافر (AGs) المضمنة في SQL Server ، والتي ستقوم تلقائيًا بنسخ قواعد بيانات SQL التي تحمل اسم المستخدم إلى كل عقد في المجموعة الخاصة بك. الجانب السلبي لهذا النهج هو أنه ينسخ قواعد بيانات SQL فقط ، بدلاً من كل كتلة من البيانات في التخزين. يمكن أن يكون تكرار قواعد بيانات SQL Server المتعددة إلى أجهزة افتراضية متعددة الاحتياطية مكلفًا للغاية حيث سيتعين عليك استخدام SQL Server Enterprise Edition لنسخ أكثر من قاعدة بيانات واحدة أو لنسخ قواعد البيانات إلى عدة أجهزة افتراضية ، حتى إذا كانت تطبيقاتك تعمل بشكل جيد باستخدام SQL Server Standard Edition .
بدلاً من ذلك ، يمكنك استخدام حل تجميع SANless ، والذي يوفر نسخًا متماثلًا تلقائيًا على مستوى الكتلة للبيانات من الجهاز الظاهري الأساسي النشط إلى كل من الأجهزة الظاهرية الثانوية في مجموعة. تتمثل ميزة استخدام حل SANless Clustering في أنه لا يعرف التطبيق وقاعدة البيانات ؛ يقوم ببساطة بتكرار كتل البيانات من نظام تخزين إلى آخر ، مما يضمن نسخ جميع البيانات الموجودة في نظام التخزين الأساسي الخاص بك إلى كل من الأجهزة الظاهرية الأخرى. يتمثل الجانب السلبي لنهج التجميع SANless في وجود برنامج آخر لفريق تكنولوجيا المعلومات لديك لترخيصه والتعلم منه ، وهو ما قد يبدو مرهقًا إذا كان بإمكانك استخدام وظيفة AG في SQL Server دون أي تكلفة إضافية.
يعد نسخ البيانات هو المفتاح لضمان HA للأنظمة المصرفية المستندة إلى مجموعة النظراء ، سواء كنت تستخدم الوظيفة المضمنة في حل مثل SQL Server ، أو الوظيفة التي يوفرها حل تجميع مستقل بدون شبكة SAN.
يمكن لمزود الخدمة السحابية توفير البنية التحتية عالية الأداء التي تتطلبها تطبيقاتك ، ولكن يجب عليك التأكد من أن البيانات والتطبيقات المتاحة لكل من الأجهزة الظاهرية في تلك المجموعة محدثة إذا كان حل HA الخاص بك سيعمل كما هو متوقع عندما تحتاج للقيام بذلك.
Todd Doane هو مهندس حلول في SIOS Technology. لقد أمضى أكثر من 20 عامًا ، في المقام الأول في عالم الخدمات المالية ، حيث ابتكر بنى مرجعية عالية التوفر وأنماط ومبادئ تصميم خاصة بالتطبيقات.
- محتوى مدعوم من تحسين محركات البحث وتوزيع العلاقات العامة. تضخيم اليوم.
- بلاتوبلوكشين. Web3 Metaverse Intelligence. تضخيم المعرفة. الوصول هنا.
- المصدر https://bankautomationnews.com/allposts/core-cloud/ensuring-high-availability-for-cloud-based-banking-applications/
