تعزيز سلسلة التوافر | بوابة ITProPortal
نشرت: 2022-01-10
ما الذي تعتقده في البداية عند التفكير في التأكد من الإتاحة الفائقة (HA) لتطبيقاتك وتفاصيلك الأكثر أهمية؟ إذا احتجت أنت أو عملاؤك إلى الوصول إلى هذه التطبيقات بنسبة 99.99 جهاز كمبيوتر في ذلك الوقت ، فمن الطبيعي تمامًا أن نفترض أولاً ضمان إمكانية الوصول إلى مصادر الحوسبة والتخزين. إذا كنت تعمل SQL Server في السحابة ، على سبيل المثال ، يمكنك تكوين مثيل مجموعة تجاوز الفشل (FCI) لنظام Windows للرد على فشل مصادر الحوسبة أو التخزين من خلال الانتقال الفوري لأحمال الحوسبة والتخزين إلى عقدة بديلة من مجموعة تجاوز الفشل. حل مشكلة HA!
ولكن ماذا لو لم تنجح الحوسبة أو التخزين؟ هناك العديد من الروابط الخلفية في سلسلة الإتاحة التي تربطك أنت والمشترين لديك بمصادر حوسبة وتخزين للأفراد. تحتاج إلى التفكير في كل هذه الروابط لضمان خبرة عمل HA التي تسعى جاهدة لتحقيقها.
توافر الشبكة
إذا كنت تقوم بتشغيل تطبيقاتك المهمة في السحابة ، فستكون شركة الدعم السحابي الخاصة بك على يقين من توفر الشبكة الداخلية التي تربط عوامل البنية التحتية السحابية الخاصة بك. توفر كل من AWS و Azure و Google Cloud System سرعة فائقة وشبكات داخلية متينة مع عدد من المسارات ، لذلك فإن الشبكات السحابية الأساسية قادرة تمامًا على دعم 99.99 جهاز كمبيوتر شخصي هدف HA.
لا يمكنك فقط إدارة كيفية ارتباط المتسوقين ببرامجك المستندة إلى مجموعة النظراء ، ولكن يمكنك التحكم في كيفية الانضمام إليها. ربما تستخدم بوابة VPN أو خدمات اتصال مخصصة مثل Azure ExpressRoute أو AWS Direct Connect أو Google Direct Interconnect. يمكن أن توفر لك كل هذه الحلول اتصالاً سريعًا للغاية وزمن انتقال منخفض جدًا بالسحابة ، ولكنها توفر جميعها اتفاقيات مستوى خدمة مختلفة — وكثير منها يعرض روابط خلفية ضعيفة في سلسلة الإتاحة. يوفر التكوين القياسي لـ Azure ExpressRoute توفر 99.95 جهاز كمبيوتر فقط لضمان أن التكوين الأساسي لـ AWS Immediate Join أقل من ذلك - 99.9 جهاز كمبيوتر فقط إذا فشل الموفر المحتمل بشكل غير متوقع ، فقد يتم تقييد إمكانية الوصول إلى تطبيقاتك المهمة لفترة أطول بكثير مما تتوقع. في الحقيقة ، قد تستمر الأجهزة الظاهرية التي تم تكوينها لـ HA في سحابة Azure أو AWS في العمل دون انقطاع - ولكن هذا الأمر سهل ومريح إذا لم تتمكن من الوصول إليها نظرًا لحقيقة تعطل ExpressRoute أو الانضمام الفوري.
يمكنك تكوين Azure ExpressRoute أو AWS Immediate Connect for HA ويمكنه فقط التنظيم. ستحتاج إلى تكوين دائرتين من ExpressRoute على الأقل و 4 دوائر انضمام فوري للحصول على اتفاقية مستوى الخدمة بنسبة 99.99٪. إذا كنت تستخدم الموفرين المماثلين على GCP ، فستحتاج إلى استخدام Google Immediate Interconnect Assistance لتطبيقات مرحلة الإنشاء نسبيًا مقارنة بخدمات Google Immediate Interconnect للتطبيقات غير الهامة للحصول على 99.99 PC SLA.
توافر البنية التحتية
حتى إذا قمت بتعزيز الروابط الضعيفة أحادية الاتجاه في الشبكة ، على الرغم من ذلك ، فهناك روابط خلفية ضعيفة محتملة داخل البنية التحتية السحابية نفسها - بين موازنات التحميل ، وخوادم DNS ، وخوادم الهوية والمصادقة ، ومزارع خوادم مواقع الويب ، وما شابه ذلك. لا تنسى الانقطاع العام حقًا عن Facebook في أكتوبر 2021؟ كانت الانقطاعات التي أثرت على الدخول إلى خوادم DNS الداخلية لفيسبوك - وليس طرق الإنتاج التي تدعم سلالات الأعمال الرئيسية لفيسبوك - يمكن الاعتماد عليها لتقليص الأعمال الكاملة لساعات. يجب أن تبدو في هذه المكونات من البنية التحتية العامة الخاصة بك بشكل فعال للتأكد من أنك مهيأ تمامًا لـ HA.
اتفاقية مستوى الخدمة (SLA) من Google لحلول خادم DNS هي 100 جهاز كمبيوتر ، وهو أمر مشجع ، لكن اتفاقية مستوى الخدمة لشركات Cloud Id تبلغ 99.9 في المائة فقط. وبالمثل ، فإن دعم DNS غير العام لـ AWS's Route 53 يسعى جاهدًا لتوفير 100٪ من اتفاقية مستوى الخدمة (SLA) ، لكن حلول الدليل الخاصة بها تقدم أعلى نسبة 99.9٪. تقدم منتجات وخدمات Azure Energetic Directory الأساسية والجودة 100 جهاز كمبيوتر لاتفاقية مستوى الخدمة ، لكن اتفاقية مستوى الخدمة لخدمات Azure Active List Domain Expert تتفوق على 99.9 في المائة.
كما هو الحال مع الاتصال المجتمعي ، هناك مشكلات يمكن للمرء القيام بها لزيادة مصداقية البنية التحتية الداخلية التي تدعم تطبيقاتك الحيوية المستندة إلى السحابة. على سبيل المثال ، يمكنك تكوين بيئة AWS الطبيعية الخاصة بك مع العديد من وحدات التحكم في المنطقة ، والتي يمكن أن تعزز موثوقية منتجات وخدمات AWS التي تتميز بدرجة وصول أقرب إلى 99.99 في المائة من درجات الوصول التي تبحث عنها.
البديل متعدد السحابة
ومع ذلك ، هناك فترات ، كما هو الحال في انقطاع خدمة AWS لمدة 7 ساعات في 7 ديسمبر 2021 ، قد تتعرض حتى أكثر الشركات استعدادًا جيدًا لتعطل غير متوقع. في حالة انقطاع خدمة AWS ، لم تنشأ المشاكل من الأجهزة التي كان يستخدمها العملاء المحتملون ، ولكن ، كما تلاحظ AWS ، من المشكلات التي تحدث في المجتمع الداخلي "لاستضافة الخدمات الأساسية ، مثل المراقبة ونظام DNS الداخلي ومنتجات وخدمات التفويض ، وعناصر من مستوى أوامر EC2. "* في الواقع ، في العديد من الظروف ، ظلت الأجهزة الافتراضية التي كانت تطبيقات العملاء تعمل وفقًا لها تعمل ومتوافقة تمامًا مع اتفاقيات مستوى الخدمة HA - ومع ذلك لم يتمكن العملاء من الوصول إلى تطبيقاتهم بسبب مشاكل في البوابات ومنتجات DNS الداخلية والخدمات وموازنات الأحمال والأجزاء الأخرى التي تعرضت قدرتها على العمل بشكل صحيح للخطر بسبب العواقب المتتالية للأخطاء التي تحدث على المجتمع الداخلي.
كيف يمكن أن تظل تطبيقاتك قيد التشغيل ويمكن الوصول إليها عندما يتبين أن الرابط الخلفي الضعيف في سلسلة الإتاحة هو السحابة نفسها؟ تتمثل أكبر احتمالية لك في هذه المقالة في الاعتماد على إجابة التعافي من الكوارث متعددة السحابة (DR). في الأساس ، ستقوم بتطوير بنية تحتية متطابقة لدعم البرامج الأكثر حيوية في سحابة فردية تمامًا. إذا كانت بنية SQL Server الأساسية الخاصة بك تعمل على AWS ، للتوضيح ، فستنتج مناسبة مماثلة لـ SQL Server على Azure أو GCP ، وهي مناسبة يمكنك البدء فيها يدويًا إذا كانت سحابة AWS غير متصلة بالإنترنت. ستحتاج إلى اختيار إجابة إدارة DR التي يتم تشغيلها في كل من بيئات AWS و Azure / GCP والتي يمكنها تنظيم نسخ المعلومات بسرعة من مثيل SQL Server في AWS إلى التخزين المتصل بالبنية التحتية في محيط سحابة Azure / GCP. إذا لم تقم بالفعل بنشر خيار إدارة DR المماثل في البيئتين ، فقد لا تقوم بتكرار معرفتك بشكل مناسب بما في ذلك السحب.
ستحتاج أيضًا إلى تكوين علاقة مجتمع خاص رقمي (VPN) بسرعة كبيرة بين البنية الأساسية الرئيسية والبنية التحتية DR. تقدم كل من AWS و Azure و GCP منتجات وخدمات VPN التي يمكن أن تتيح ارتباطًا آمنًا من السحابة إلى السحابة (وهناك بدائل للجمع الثالث أيضًا) ، وستصبح هذه هي القناة التي تكرر إجابة إدارة DR الخاصة بك من خلالها معلومات مهمة بين البنى التحتية السحابية. بالطبع ، إذا كنت تستخدم AWS VPN Remedy في ديسمبر ، فربما تكون قد توقفت منذ فترة طويلة أثناء انقطاع الخدمة - ولكن في هذا السيناريو ، كل شيء على ما يرام. يكرر قرار إدارة DR الذي يدير على AWS جميع عمليات الكتابة المجاورة إلى نظيرتها التخزينية في بنية DR بالسرعة التي يتيحها المجتمع لذلك ، وبحلول الوقت الذي يتوقف فيه موفرو AWS عن الاتصال بالإنترنت ، يكون برنامج DR قد نسخ الكل (أو تقريبًا جميع) بيانات AWS الحيوية للبنية التحتية DR. بالسرعة التي اتضح فيها أن السحابة الرئيسية لم تكن موجودة في وضع عدم الاتصال ، ستعمل على تدوير البنية التحتية في سحابة DR ويمكن أن تبدأ في توصيل حصول المستهلك على أغراضك الأساسية مع اضطراب ضئيل. قد لا تكون مستيقظًا وتتحكم في إطار زمني أقل من 5 دقائق تعتمد عليه في علاج HA ، ولكنك ستكون جاهزًا للعمل بسرعة أكبر بكثير مما لو كنت قد واجهت الصمود لمدة 7 ساعات للحصول على AWS عملياتها مرة أخرى على الخط.
توافر البرامج
على المدى الطويل ، يتعلق التوصيف لـ HA بالتوصيف للتأكد من الإتاحة الأساسية للتطبيق الخاص بك. يمكنك إنشاء FCIs التي ستضمن HA لأجهزة VM والتخزين دون مواجهة مشكلة. اعتاد جميع بائعي المساعدة السحابية على استيعابك على هذا المستوى. للحصول على HA الصحيح من النهاية إلى النهاية ، تحتاج إلى زيادة الوعي بجميع الروابط الخلفية الأخرى في سلسلة الإتاحة. سيكون البعض أضعف مما تتصور إلا أنك تأخذ طرقًا زائدة لتقويتها.
ديف بيرمينجهام ، المبشر التقني الأول ، الابتكار التكنولوجي لشركة SIOS