توضح هذه البنية المرجعية كيفية نشر الأجهزة الظاهرية (VMs) وشبكة ظاهرية تم تكوينها لتطبيق N-tier، باستخدام Apache Cassandra على Linux لطبقة البيانات.
بناء الأنظمة
قم بتنزيل ملف Visio لهذه البنية.
سير العمل
البنية لديها المكونات التالية.
عام
مجموعة الموارد. يتم استخدام مجموعات الموارد لتجميع موارد Azure بحيث يمكن إدارتها حسب العمر أو المالك أو معايير أخرى.
مناطق التوفر. مناطق التوفر هي مواقع فعلية فريدة داخل منطقة Azure. تحتوي كل منطقة على مركز بيانات واحد أو أكثر من مركز بطاقة مستقلة وتبريد وشبكات. من خلال وضع الأجهزة الظاهرية عبر المناطق، يصبح التطبيق مرنًا في مواجهة حالات الفشل داخل المنطقة.
موازنة الشبكات والتحميل
الشبكة الظاهرية والشبكات الفرعية. يتم نشر كل جهاز Azure ظاهري في شبكة ظاهرية يمكن تقسيمها إلى شبكات فرعية. إنشاء شبكة فرعية منفصلة لكل مستوى.
بوابة التطبيق. بوابة التطبيق هي عبارة عن موازن تحميل الطبقة 7. في هذه البنية، فإنه يوجه طلبات HTTP إلى الواجهة الأمامية للويب. توفر بوابة التطبيق أيضًا جدار حماية تطبيق الويب (WAF) الذي يحمي التطبيق من عمليات الاستغلال والثغرات الأمنية الشائعة.
موازن التحميل. استخدم موازن تحميل Azure Standard لتوزيع نسبة استخدام الشبكة من طبقة الويب إلى طبقة الأعمال.
مجموعات أمان الشبكة (NSGs). استخدم NSGs لتقييد نسبة استخدام الشبكة داخل الشبكة الظاهرية. على سبيل المثال، في البنية ثلاثية المستويات الموضحة هنا، لا يقبل مستوى قاعدة البيانات نسبة استخدام الشبكة من واجهة الويب الأمامية، فقط من طبقة الأعمال والشبكة الفرعية للإدارة.
DDOS Protection. على الرغم من أن النظام الأساسي ل Azure يوفر حماية أساسية ضد هجمات رفض الخدمة الموزعة (DDoS)، نوصي باستخدام حماية شبكة Azure DDoS، التي عززت ميزات تخفيف DDoS. راجع اعتبارات الأمان.
Azure DNS. Azure DNS هي خدمة استضافة لمجالات DNS. يوفر تحليل الاسم باستخدام البنية الأساسية لـ Microsoft Azure. يمكنك، من خلال استضافة المجالات في Azure، إدارة سجلات DNS باستخدام نفس بيانات الاعتماد وواجهات برمجة التطبيقات والأدوات والفوترة مثل خدمات Azure الأخرى.
الأجهزة الظاهرية
قاعدة بيانات Apache Cassandra. يوفر توفرًا عاليًا في طبقة البيانات، عن طريق تمكين النسخ المتماثل وتجاوز الفشل.
OpsCenter. نشر حل مراقبة مثل DataStax OpsCenter لمراقبة نظام مجموعة Cassandra.
مربع الانتقال السريع. يُطلق عليه أيضاً مضيف الأساس. جهاز ظاهري آمن على الشبكة يستخدمه المسؤولون للاتصال بالأجهزة الظاهرية الأخرى. يحتوي jumpbox على NSG الذي يسمح بنسبة استخدام شبكة عن بُعد فقط من عناوين IP العامة في قائمة آمنة. يجب أن تسمح NSG بنسبة استخدام الشبكة لبروتوكول سطح المكتب البعيد (RDP).
التوصيات
قد تختلف متطلباتك عن البنية الموصوفة هنا. استخدم هذه التوصيات كنقطة انطلاق.
الأجهزة الظاهرية
للحصول على توصيات حول تكوين الأجهزة الظاهرية، راجع تشغيل جهاز Linux الظاهري على Azure.
الشبكة الظاهرية
عند إنشاء الشبكة الظاهرية، حدد عدد عناوين IP التي تتطلبها مواردك في كل شبكة فرعية. حدد قناع شبكة فرعية ونطاق عناوين شبكة اتصال كبير بما يكفي لعناوين IP المطلوبة، باستخدام رمز [التوجيه بين المجالات دون فئة (CIDR)]. استخدم مساحة عنوان تقع ضمن كتل عناوين IP الخاصة القياسية، وهي 10.0.0.0/8 و172.16.0.0/12 و192.168.0.0/16.
اختر نطاق عناوين لا يتداخل مع شبكتك المحلية، في حالة الحاجة إلى إعداد بوابة بين الشبكة الظاهرية والشبكة المحلية لاحقا. بمجرد إنشاء الشبكة الظاهرية، لا يمكنك تغيير نطاق العناوين.
تصميم الشبكات الفرعية مع مراعاة متطلبات الوظائف والأمان. يجب أن تنتقل جميع الأجهزة الظاهرية داخل نفس المستوى أو الدور إلى نفس الشبكة الفرعية، والتي يمكن أن تكون حد أمان. لمزيد من المعلومات حول تصميم الشبكات الظاهرية والشبكات الفرعية، راجع تخطيط وتصميم شبكات Azure الظاهرية.
Application Gateway
للحصول على معلومات حول تكوين بوابة التطبيق، راجع نظرة عامة على تكوين بوابة التطبيق.
موازنة التحمل
لا تعرض الأجهزة الظاهرية مباشرة على الإنترنت. بدلًا من ذلك، امنح كل جهاز ظاهري عنوان IP خاصًا. يتصل العملاء باستخدام عنوان IP المقترن ببوابة التطبيق.
حدد قواعد موازن التحميل لتوجيه نسبة استخدام الشبكة إلى الأجهزة الظاهرية. على سبيل المثال، لتمكين نسبة استخدام الشبكة HTTP، قم بإنشاء قاعدة تعين المنفذ 80 من تكوين الواجهة الأمامية إلى المنفذ 80 في تجمع عناوين الواجهة الخلفية. عندما يرسل عميل طلب HTTP إلى المنفذ 80، يحدد موازن التحميل عنوان IP خلفي باستخدام خوارزمية تجزئة تتضمن عنوان IP المصدر. يتم توزيع طلبات العميل عبر جميع الأجهزة الظاهرية.
مجموعات أمان الشبكة
استخدم قواعد NSG لتقييد نسبة استخدام الشبكة بين المستويات. على سبيل المثال، في البنية ثلاثية المستويات الموضحة أعلاه، لا تتصل طبقة الويب مباشرة بطبقة قاعدة البيانات. لفرض ذلك، يجب أن يمنع مستوى قاعدة البيانات نسبة استخدام الشبكة الواردة من الشبكة الفرعية لطبقة الويب.
- رفض كافة نسبة استخدام الشبكة الواردة من الشبكة الظاهرية. (استخدم العلامة
VIRTUAL_NETWORKفي القاعدة.) - السماح بنسبة استخدام الشبكة الواردة من الشبكة الفرعية لمستوى الأعمال.
- السماح بنسبة استخدام الشبكة الواردة من الشبكة الفرعية لطبقة قاعدة البيانات نفسها. تسمح هذه القاعدة بالاتصال بين الأجهزة الظاهرية لقاعدة البيانات، وهي مطلوبة للنسخ المتماثل لقاعدة البيانات وتجاوز الفشل.
- السماح بنسبة استخدام الشبكة SSH (المنفذ 22) من الشبكة الفرعية ل jumpbox. تتيح هذه القاعدة للمسؤولين الاتصال بطبقة قاعدة البيانات من مربع الانتقال.
إنشاء القواعد من 2 إلى 4 ذات أولوية أعلى من القاعدة الأولى، بحيث تتجاوزها.
Cassandra
نوصي باستخدام DataStax Enterprise للإنتاج، ولكن تنطبق هذه التوصيات على أي إصدار Cassandra. لمزيد من المعلومات حول تشغيل DataStax في Azure، راجع DataStax Enterprise Deployment Guide for Azure.
تكوين العقد في وضع الرف المدرك. تعيين مجالات الخطأ إلى حوامل في الملف cassandra-rackdc.properties.
لا تحتاج إلى موازن تحميل أمام نظام المجموعة. يتصل العميل مباشرة بعقدة في نظام المجموعة.
تستخدم البرامج النصية للتوزيع لهذه البنية تحليل الاسم لتهيئة العقدة الأولية للاتصال داخل نظام المجموعة (gossip). لتمكين تحليل الاسم، ينشئ التوزيع منطقة Azure Private DNS مع سجلات لعقد Cassandra. اعتمادا على البرامج النصية للتهيئة الخاصة بك، قد تتمكن من استخدام عنوان IP الثابت بدلًا من ذلك.
إشعار
Azure Private DNS هو حاليًا في المعاينة العامة.
Jumpbox
لا تسمح بوصول SSH من الإنترنت العام إلى الأجهزة الظاهرية التي تقوم بتشغيل حمل عمل التطبيق. بدلا من ذلك، يجب أن تأتي جميع وصول SSH إلى هذه الأجهزة الظاهرية من خلال jumpbox. يسجل المسؤول الدخول إلى jumpbox، ثم يسجل الدخول إلى الجهاز الظاهري الآخر من jumpbox. يسمح jumpbox بحركة مرور SSH من الإنترنت، ولكن فقط من عناوين IP المعروفة والمأمونة.
يحتوي jumpbox على الحد الأدنى من متطلبات الأداء، لذلك حدد حجم جهاز ظاهري صغير. إنشاء عنوان IP عام لـjumpbox. ضع jumpbox في نفس الشبكة الظاهرية مثل الأجهزة الظاهرية الأخرى، ولكن في شبكة فرعية إدارة منفصلة.
لتأمين jumpbox، أضف قاعدة NSG تسمح باتصالات SSH فقط من مجموعة آمنة من عناوين IP العامة. تكوين مجموعات أمان الشبكة للشبكات الفرعية الأخرى للسماح بنسبة استخدام الشبكة SSH من الشبكة الفرعية للإدارة.
الاعتبارات
قابلية التوسع
مجموعات التوسعة
بالنسبة إلى مستويات الويب والأعمال، ضع في اعتبارك استخدام مجموعات مقياس الجهاز الظاهري، بدلا من نشر أجهزة ظاهرية منفصلة في مجموعة توفر. تسهل مجموعة التحجيم نشر وإدارة مجموعة من الأجهزة الظاهرية المتطابقة، والتحجيم التلقائي للأجهزة الظاهرية استنادًا إلى مقاييس الأداء. مع زيادة الحمل على الأجهزة الظاهرية، تتم إضافة أجهزة ظاهرية إضافية تلقائيًا إلى موازن التحميل.
هناك طريقتان أساسيتان لتكوين الأجهزة الظاهرية المنشورة في مجموعة مقياس:
استخدم الملحقات لتكوين الجهاز الظاهري بعد توزيعه. باستخدام هذا الأسلوب، قد تستغرق مثيلات الجهاز الظاهري الجديدة وقتا أطول لبدء التشغيل من الجهاز الظاهري بدون ملحقات.
نشر قرص مدار مع صورة قرص مخصص. قد يكون هذا الخيار أسرع للنشر. ومع ذلك، يتطلب منك الاحتفاظ بالصورة محدثة.
لمزيد من المعلومات، راجع اعتبارات التصميم لمجموعات التحجيم.
تلميح
عند استخدام أي حل تحجيم تلقائي، اختبره مع أحمال العمل على مستوى الإنتاج مسبقا.
حدود الاشتراك
يحتوي كل اشتراك Azure على حدود افتراضية، بما في ذلك الحد الأقصى لعدد الأجهزة الظاهرية لكل منطقة. يمكنك زيادة الحد عن طريق تقديم طلب دعم. لمزيد من المعلومات، راجع حدود الاشتراك والخدمة في Azure والحصص النسبية والقيود.
Application Gateway
تدعم بوابة التطبيق وضع السعة الثابتة أو وضع التحجيم التلقائي. يعد وضع السعة الثابتة مفيداً للسيناريوهات ذات أحمال العمل المتسقة والتي يمكن التنبؤ بها. ضع في اعتبارك استخدام وضع التحجيم التلقائي لأحمال العمل ذات نسبة استخدام الشبكة المتغيرة. لمزيد من المعلومات، راجع التحجيم التلقائي وتكرار المناطق في Application Gateway v2.
كفاءة الأداء
للحصول على أفضل أداء من Cassandra على أجهزة Azure الظاهرية، راجع التوصيات في تشغيل Apache Cassandra على أجهزة Azure الظاهرية.
التوافر
توفر مناطق التوفر أفضل مرونة داخل منطقة واحدة. إذا كنت بحاجة إلى توفر أعلى، ففكر في نسخ التطبيق عبر منطقتين.
لا تدعم جميع المناطق مناطق التوفر، ولا يتم دعم جميع أحجام الأجهزة الظاهرية في جميع المناطق. قم بتشغيل الأمر Azure CLI التالي للعثور على المناطق المدعومة لكل حجم جهاز ظاهري داخل منطقة:
az vm list-skus --resource-type virtualMachines --zone false --location <location> \
--query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table
إذا قمت بنشر هذه البنية إلى منطقة لا تدعم مناطق التوفر، فضع الأجهزة الظاهرية لكل طبقة داخل مجموعة توفر. يتم نشر الأجهزة الظاهرية ضمن نفس التوفر عبر خوادم فعلية متعددة ورفوف حساب ووحدات تخزين ومفاتيح تبديل الشبكة للتكرار. تستخدم مجموعات التحجيم تلقائيًا مجموعات المواضع، والتي تعمل كمجموعة توفر ضمنية.
عند النشر إلى مناطق التوفر، استخدم SKU القياسي لـAzure Load Balancer وv2 SKU لبوابة التطبيق. تدعم وحدات SKU هذه التكرار عبر المنطقة. لمزيد من المعلومات، راجع:
- موازن التحميل القياسي ومناطق التوفر
- التحجيم التلقائي وApplication Gateway المكررة في المنطقة الإصدار 2
- كيف تدعم بوابة التطبيق قابلية الوصول العالية وقابلية التوسع؟
يمكن لنشر Application Gateway واحد تشغيل مثيلات متعددة من البوابة. بالنسبة لأحمال عمل الإنتاج، قم بتشغيل مثيلين على الأقل.
نظام مجموعة Cassandra
بالنسبة إلى نظام مجموعة Cassandra، تعتمد سيناريوهات تجاوز الفشل على مستويات التناسق المستخدمة من قبل التطبيق وعدد النسخ المتماثلة. للحصول على مستويات التناسق والاستخدام في Cassandra، راجع تكوين تناسق البيانات وCassandra: كم عدد العقد التي يتم التحدث إليها مع الحصة؟ يتم تحديد توفر البيانات في Cassandra بواسطة مستوى التناسق المستخدم من قبل التطبيق وآلية النسخ المتماثل. للنسخ المتماثل في Cassandra، راجع شرح النسخ المتماثل للبيانات في قواعد بيانات NoSQL.
تحقيقات الصحة
يستخدم كل من Application Gateway و Load Balancer تحقيقات السلامة لمراقبة توفر مثيلات الجهاز الظاهري.
- تستخدم بوابة التطبيق دائما فحص HTTP.
- يمكن لـLoad Balancer اختبار إما HTTP أو TCP. بشكل عام، إذا كان الجهاز الظاهري يقوم بتشغيل خادم HTTP، فاستخدم فحص HTTP. خلاف ذلك، استخدم TCP.
إذا لم يتمكن الفحص من الوصول إلى مثيل خلال فترة مهلة، تتوقف البوابة أو موازن التحميل عن إرسال نسبة استخدام الشبكة إلى هذا الجهاز الظاهري. يستمر الفحص في التحقق وسيعيد الجهاز الظاهري إلى تجمع النهاية الخلفية إذا أصبح الجهاز الظاهري متوفرا مرة أخرى.
ترسل تحقيقات HTTP طلب HTTP GET إلى مسار محدد وتستمع إلى استجابة HTTP 200. يمكن أن يكون هذا المسار هو المسار الجذر ("/")، أو نقطة نهاية مراقبة السلامة التي تنفذ بعض المنطق المخصص للتحقق من صحة التطبيق. يجب أن تسمح نقطة النهاية بطلبات HTTP مجهولة.
لمزيد من المعلومات حول فحوصات السلامة، راجع:
للحصول على اعتبارات حول تصميم نقطة نهاية فحص السلامة، راجع نمط مراقبة نقطة النهاية الصحية.
تحسين التكلفة
استخدم حاسبة أسعار Azure لتقدير التكاليف. فيما يلي بعض الاعتبارات الأخرى.
مجموعات توسيع الجهاز الافتراضي
تتوفر مجموعات مقياس الجهاز الظاهري على جميع أحجام أجهزة Linux الظاهرية. يتم تحصيل رسوم منك فقط مقابل أجهزة Azure الظاهرية التي تنشرها، بالإضافة إلى أي موارد بنية أساسية إضافية مستهلكة مثل التخزين والشبكات. لا توجد رسوم تزايدية لخدمة مجموعات مقياس الجهاز الظاهري نفسها.
للحصول على خيارات تسعير الأجهزة الظاهرية الفردية، راجع تسعير أجهزة Linux الظاهرية.
موازنة التحمل
تتم محاسبتك فقط على عدد قواعد موازنة التحميل والصادرة المكونة. قواعد ترجمة عناوين الشبكة الواردة (NAT) مجانية. لا توجد رسوم بالساعة لموازن التحميل القياسي عند عدم تكوين أي قواعد.
لمزيد من المعلومات، راجع قسم التكلفة في Microsoft Azure Well-Architected Framework.
الأمان
الشبكات الظاهرية هي حد عزل نسبة استخدام الشبكة في Azure. لا يمكن للأجهزة الظاهرية في شبكة ظاهرية واحدة الاتصال مباشرة مع الأجهزة الظاهرية في شبكة ظاهرية مختلفة. يمكن للأجهزة الظاهرية داخل نفس الشبكة الظاهرية الاتصال، إلا إذا قمت بإنشاء مجموعات أمان الشبكة (NSGs) لتقييد حركة المرور. لمزيد من المعلومات، راجع خدمات Microsoft السحابية وأمان الشبكة.
بالنسبة لنسبة استخدام الإنترنت الواردة، تحدد قواعد موازن التحميل نسبة استخدام الشبكة التي يمكن أن تصل إلى النهاية الخلفية. ومع ذلك، لا تدعم قواعد موازن التحميل قوائم IP الآمنة، لذلك إذا كنت تريد إضافة عناوين IP عامة معينة إلى قائمة آمنة، فأضف NSG إلى الشبكة الفرعية.
DMZ. ضع في اعتبارك إضافة جهاز ظاهري للشبكة (NVA) لإنشاء DMZ بين الإنترنت وشبكة Azure الظاهرية. NVA هو مصطلح عام لجهاز ظاهري يمكنه تنفيذ المهام المتعلقة بالشبكة، مثل جدار الحماية وفحص الحزمة والتدقيق والتوجيه المخصص. لمزيد من المعلومات، راجع تنفيذ DMZ بين Azure والإنترنت.
التشفير. تشفير البيانات الحساسة الثابتة واستخدام Azure Key Vault لإدارة مفاتيح تشفير قاعدة البيانات. يمكن أن يتسعيد Key Vault مفاتيح التشفير في وحدات أمان الجهاز النمطية (HSMs). يوصى أيضًا بتخزين أسرار التطبيق، مثل سلاسل اتصال قاعدة البيانات، في Key Vault.
حماية DDOS. يوفر النظام الأساسي Azure حماية DDoS الأساسية بشكل افتراضي. تستهدف هذه الحماية الأساسية حماية البنية الأساسية لـAzure ككل. على الرغم من تمكين حماية DDoS الأساسية تلقائيا، نوصي باستخدام Azure DDoS Network Protection. تستخدم حماية الشبكة الضبط التكيفي، استنادا إلى أنماط نسبة استخدام الشبكة لتطبيقك، للكشف عن التهديدات. يسمح ذلك بتطبيق عوامل التخفيف من المخاطر ضد هجمات DDoS التي قد تمر دون أن يلاحظها نهج DDoS على مستوى البنية الأساسية. توفر حماية الشبكة أيضا التنبيه وبيانات تتبع الاستخدام والتحليلات من خلال Azure Monitor. لمزيد من المعلومات، راجع حماية Azure DDoS: أفضل الممارسات والبنى المرجعية.
التميز التشغيلي
نظرا لأن جميع الموارد الرئيسية وتبعياتها موجودة في نفس الشبكة الظاهرية في هذه البنية، يتم عزلها في نفس حمل العمل الأساسي. تسهل هذه الحقيقة إقران الموارد المحددة لحمل العمل بفريق DevOps، بحيث يمكن للفريق إدارة جميع جوانب هذه الموارد بشكل مستقل. يمكن هذا العزل Teams وخدمات DevOps من إجراء التكامل المستمر والتسليم المستمر (CI/CD).
يمكنك أيضًا استخدام قوالب توزيع مختلفة ودمجها مع خدمات Azure DevOps لتوفير بيئات مختلفة في دقائق، على سبيل المثال لنسخ الإنتاج مثل السيناريوهات أو بيئات اختبار التحميل فقط عند الحاجة، ما يوفر التكلفة.
في هذا السيناريو، يتم تكوين أجهزتك الظاهرية باستخدام ملحقات الجهاز الظاهري، لأنها توفر إمكانية تثبيت برامج إضافية معينة، مثل Apache Cassandra. على وجه الخصوص، يسمح ملحق البرنامج النصي المخصص بتنزيل وتنفيذ التعليمات البرمجية العشوائية على جهاز ظاهري، ما يسمح بتخصيص غير محدود لنظام التشغيل لجهاز Azure الظاهري. يتم تثبيت ملحقات الجهاز الظاهري وتنفيذها فقط في وقت إنشاء الجهاز الظاهري. وهذا يعني أنه إذا تم تكوين نظام التشغيل بشكل غير صحيح في مرحلة لاحقة، فسيتطلب تدخلًا يدويًا لنقله مرة أخرى إلى حالته الصحيحة. يمكن استخدام أدوات إدارة التكوين لمعالجة هذه المشكلة.
ضع في اعتبارك استخدام Azure Monitor لتحليل وتحسين أداء البنية الأساسية الخاصة بك، ومراقبة وتشخيص مشكلات الشبكات دون تسجيل الدخول إلى أجهزتك الظاهرية. Application Insights هي في الواقع إحدى مكونات Azure Monitor، التي تمنحك المقاييس الغنية والسجلات للتحقق من حالة مشهد Azure كاملة. سيساعدك Azure Monitor على متابعة حالة البنية الأساسية الخاصة بك.
احرص ليس فقط على مراقبة عناصر الحساب التي تدعم التعليمات البرمجية لتطبيقك، بل أيضاً النظام الأساسي للبيانات أيضاً وخاصة قواعد البيانات الخاصة بك لأن الأداء المنخفض لطبقة البيانات لتطبيق قد يكون له عواقب وخيمة.
من أجل اختبار بيئة Azure حيث يتم تشغيل التطبيقات، يجب التحكم في الإصدار وتوزيعه من خلال نفس آليات التعليمة البرمجية للتطبيق، ثم يمكن اختبارها والتحقق من صحتها باستخدام نماذج اختبار DevOps أيضًا.
لمزيد من المعلومات، راجع قسم التميز التشغيلي في Microsoft Azure Well-Architecture Framework.