هندسة شبكة SAP HANA (مثيلات كبيرة)
في هذه المقالة، سنلقي نظرة على بنية الشبكة لنشر SAP HANA على مثيلات Azure الكبيرة (المعروفة باسم البنية التحتية ل BareMetal).
بنية خدمات شبكة Azure مكون أساسي من بنجاح نشر تطبيقات SAP على مثيل HANA كبير. بشكل عام، يكون عمليات نشر SAP HANA على Azure (مثيلات كبيرة) أفقي SAP أكبر. من المحتمل أن تتضمن العديد من حلول SAP بأحجام مختلفة من قواعد البيانات واستهلاك موارد وحدة المعالجة المركزية واستخدام الذاكرة.
من المحتمل أن لا توجد جميع أنظمة تكنولوجيا المعلومات في Azure بالفعل. قد يكون مشهد SAP الخاص بك هجينا أيضا. قد يستخدم نظام إدارة قواعد البيانات (DBMS) وتطبيق SAP مزيجا من NetWeaver و S/4HANA و SAP HANA. قد يستخدم تطبيق SAP الخاص بك نظام إدارة قواعد بيانات آخر.
يقدم Azure خدمات مختلفة تسمح لك بتشغيل أنظمة DBMS و NetWeaver و S/4HANA في Azure. يقدم Azure تقنية الشبكة لجعل Azure تبدو وكأنها مركز بيانات ظاهري لنشر البرامج المحلية. تتضمن وظيفة شبكة Azure ما يلي:
- شبكات Azure الظاهرية متصلة بدائرة ExpressRoute والتي تتصل بدورها بأصول الشبكة الداخلية خاصتك.
- دائرة ExpressRoute تتصل محليًا بـ Azure، بنطاق ترددي يبلغ 1 جيجابت في الثانية أو أكثر. تسمح هذه الدائرة بعرض نطاق ترددي كاف لنقل البيانات بين الأنظمة المحلية والأنظمة التي تعمل على الأجهزة الافتراضية (VMs). كما يسمح بعرض النطاق الترددي الكافي للاتصال بأنظمة Azure من المستخدمين المحليين.
- كل أنظمة SAP في Azure يتم إعدادها في الشبكات الظاهرية للاتصال ببعضها.
- يتم توسيع Active Directory و DNS المستضافة محليا إلى Azure من خلال ExpressRoute من الموقع. قد يتم تشغيلها أيضا بالكامل في Azure.
عند دمج مثيلات HANA الكبيرة في بنية شبكة مركز بيانات Azure، يتم استخدام تقنية Azure ExpressRoute أيضا.
إشعار
يمكن ربط اشتراك Azure واحد فقط بمستأجر واحد فقط في خوادم HANA Large Instance المخصصة في منطقة Azure محددة. وعلى العكس، يمكن ربط مستأجر الخوادم المخصصة لـ HANA Large Instance إلى اشتراك Azure واحد فقط. يتوافق هذا المتطلب مع الكائنات الأخرى القابلة للفوترة في Azure.
إذا تم نشر SAP HANA على Azure (مثيلات كبيرة) في مناطق Azure متعددة، يتم نشر مستأجر منفصل في طابع مثيل كبير HANA. يمكنك تشغيل كليهما ضمن نفس اشتراك Azure شريطة أن تكون هذه المثيلات جزءا من نفس المشهد SAP.
هام
يتم دعم أسلوب نشر Azure Resource Manager فقط مع SAP HANA على Azure (المثيلات الكبيرة).
معلومات الشبكة الظاهرية الإضافية
لتوصيل شبكة ظاهرية ب ExpressRoute، يجب إنشاء بوابة Azure ExpressRoute. لمزيد من المعلومات، راجع حول بوابات Expressroute ل ExpressRoute.
تُستخدم بوابة Azure ExpressRoute مع ExpressRoute إلى بنية أساسية خارج Azure أو لخادم Azure مخصص كبير. يمكنك توصيل عبارة Azure ExpressRoute إلى أربعة دوائر ExpressRoute كحد أقصى، ولكن فقط إذا كانت هذه الاتصالات تأتي من أجهزة توجيه حافة المؤسسة ل Microsoft (MSEEs) مختلفة. لمزيد من المعلومات، راجع البنية الأساسية SAP HANA (المثيلات الكبيرة) والاتصال على Azure.
إشعار
الحد الأقصى للإنتاجية التي يمكنك تحقيقها باستخدام بوابة ExpressRoute هو 10 جيجابت في الثانية باستخدام اتصال ExpressRoute. لا يؤدي نسخ الملفات بين جهاز ظاهري موجود في شبكة ظاهرية ونظام داخلي (باعتباره دفق لنسخة واحدة) إلى تحقيق معدل النقل الكامل لوحدات SKU المختلفة. للاستفادة من النطاق الترددي الكامل لبوابة ExpressRoute، استخدم تدفقات متعددة أو انسخ ملفات مختلفة في تدفقات متوازية لملف واحد.
بنية الشبكات لمثيل HANA الكبير
يمكن فصل بنية الشبكات لمثيلات HANA الكبيرة إلى أربعة أجزاء:
- الشبكات المحلية واتصال ExpressRoute ب Azure. هذا الجزء هو مجالك (العميل) وهو متصل ب Azure من خلال ExpressRoute. يتم دفع هذه الدائرة ExpressRoute بالكامل من قبلك. يجب أن يكون النطاق الترددي كبيرا بما يكفي للتعامل مع نسبة استخدام الشبكة بين أصولك المحلية ومنطقة Azure التي تتصل بها. انظر أسفل اليمين في الشكل التالي.
- خدمات شبكة Azure، كما نوقش سابقا، مع الشبكات الافتراضية، والتي تحتاج مرة أخرى إلى إضافة بوابات ExpressRoute. بالنسبة لهذا الجزء، تحتاج إلى إنشاء التصميمات المناسبة لتلبية متطلبات التطبيق والأمان والامتثال. فكر فيما إذا كنت تريد استخدام مثيلات HANA الكبيرة نظرا لعدد الشبكات الافتراضية ووحدات SKU لبوابة Azure للاختيار من بينها. انظر الجزء العلوي الأيمن في الشكل.
- اتصال مثيل HANA الكبير الخاص بك من خلال ExpressRoute إلى Azure. يتم نشر هذا الجزء ومعالجتها من قبل Microsoft. كل ما عليك القيام به هو توفير بعض نطاقات عناوين IP بعد نشر الأصول الخاصة بك في مثيل HANA الكبير وتوصيل دائرة ExpressRoute بالشبكات الظاهرية. لمزيد من المعلومات، راجع البنية الأساسية SAP HANA (المثيلات الكبيرة) والاتصال على Azure. لا توجد رسوم إضافية للاتصال بين شبكة اتصال مركز البيانات Azure ووحدات مثيل HANA الكبير.
- الشبكات ضمن خادم HANA Large Instance المخصص، والذي يكون في الغالب مرئيًا بالنسبة لك.
لا يزال الشرطان التاليان قائمين على الرغم من أنك تستخدم مثيلات Hana الكبيرة:
- يجب أن تتصل أصولك المحلية عبر ExpressRoute ب Azure.
- تحتاج إلى شبكة افتراضية واحدة أو أكثر تقوم بتشغيل الأجهزة الظاهرية الخاصة بك. تستضيف هذه الأجهزة الظاهرية طبقة التطبيق التي تتصل بمثيلات HANA المستضافة في مثيلات HANA الكبيرة.
الاختلافات في عمليات نشر SAP في Azure هي:
- يتم توصيل مثيلات HANA الكبيرة للمستأجر الخاص بك من خلال دائرة ExpressRoute أخرى في الشبكات الافتراضية الخاصة بك. لا تشترك دوائر ExpressRoute الشبكة الظاهرية في Azure والدوائر بين الشبكات الظاهرية Azure و HANA المثيلات الكبيرة نفس أجهزة التوجيه. تظل ظروف التحميل منفصلة.
- ملف تعريف حمل العمل بين طبقة تطبيق SAP ومثيل HANA الكبير ذو طبيعة مختلفة. SAP HANA يولد العديد من الطلبات الصغيرة والرشقات المتتالية مثل نقل البيانات (مجموعات النتائج) إلى طبقة التطبيق.
- تصميم تطبيق SAP أكثر حساسية لزمن الانتقال للشبكة من السيناريوهات النمطية التي يجري فيها تبادل البيانات بين النظام الداخلي وAzure.
- تحتوي بوابة Azure ExpressRoute على اتصالين على الأقل من ExpressRoute. يتم توصيل دائرة واحدة من أماكن العمل وأخرى متصلة من مثيل HANA الكبير. يترك هذا التكوين مساحة فقط لاثنين من دوائر أخرى من MSEEs مختلفة للاتصال بعبارة ExpressRoute. هذا القيد مستقل عن استخدام ExpressRoute FastPath. تشترك جميع الدوائر المتصلة في الحد الأقصى للنطاق الترددي للبيانات الواردة من بوابة ExpressRoute.
باستخدام المراجعة 3 من طوابع المثيل الكبير HANA، يمكن أن يكون زمن انتقال الشبكة بين الأجهزة الظاهرية ووحدات مثيل HANA الكبيرة أعلى من زمن انتقال شبكة VM إلى VM النموذجية ذهابا وإيابا. اعتماداً على منطقة Azure، يمكن أن تتجاوز القيم التي تم قياسها زمن الوصول ذهاباً وإياباً 0.7 مللي ثانية المُصنف على أنه أقل من المتوسط في SAP Note #1100926 - الأسئلة الشائعة: أداء الشبكة. اعتمادا على منطقة Azure وأداة لقياس زمن الوصول ذهابا وإيابا شبكة الاتصال بين Azure VM و HANA مثيل كبير، يمكن أن يصل زمن الوصول إلى 2 مللي ثانية. ومع ذلك، نجح العملاء في نشر تطبيقات SAP المستندة إلى SAP HANA على مثيلات SAP HANA الكبيرة. تأكد من اختبار عمليات العمل بدقة باستخدام مثيلات Azure HANA الكبيرة. يمكن لوظيفة جديدة، تسمى ExpressRoute FastPath، أن تقلل بشكل كبير من زمن انتقال الشبكة بين مثيلات HANA الكبيرة والأجهزة الظاهرية لطبقة التطبيقات في Azure (انظر أدناه).
تعمل المراجعة 4 من طوابع المثيل الكبير HANA على تحسين زمن انتقال الشبكة بين أجهزة Azure الظاهرية التي تم نشرها بالقرب من طابع المثيل الكبير HANA. يفي زمن الوصول بمتوسط التصنيف أو أفضل من المتوسط كما هو موثق في SAP Note #1100926 - الأسئلة المتداولة: أداء الشبكة إذا تم تكوين Azure ExpressRoute FastPath (انظر أدناه).
لنشر أجهزة Azure الظاهرية بالقرب من مثيلات HANA الكبيرة من المراجعة 4، تحتاج إلى تطبيق مجموعات مواضع Azure Proximity Place. يمكن استخدام مجموعات مواضع القرب لتحديد موقع طبقة تطبيق SAP في مركز بيانات Azure نفسه مثل مثيلات HANA الكبيرة المستضافة في المراجعة 4. لمزيد من المعلومات، راجع مجموعات موضع تقارب Azure للحصول على زمن الانتقال الأمثل إلى الشبكة مع تطبيقات SAP.
لتوفير زمن وصول شبكة الاتصال الحتمي بين VMs و HANA مثيل كبير، استخدام بوابة ExpressRoute SKU ضروري. على عكس أنماط حركة المرور بين الأماكن و VMs، يمكن أن تتطور أنماط نسبة استخدام الشبكة بين VMs و HANA Large Instances اندفاعات في الطلبات ووحدات تخزين البيانات. للتعامل مع مثل هذه الانفجارات، نوصي بشدة باستخدام وحدة SKU لبوابة UltraPerformance. بالنسبة للفئة من النوع الثاني من وحدات SKU للمثيل الكبير HANA، يعد استخدام وحدة SKU لبوابة UltraPerformance كبوابة ExpressRoute أمرا إلزاميا.
هام
نظرا لنسبة استخدام الشبكة الإجمالية بين تطبيق SAP وطبقات قاعدة البيانات، يتم دعم وحدات SKU لبوابة HighPerformance أو UltraPerformance للشبكات الظاهرية للاتصال ب SAP HANA على Azure (مثيلات كبيرة). بالنسبة ل HANA مثيل كبير نوع II SKUs، يتم اعتماد SKU عبارة UltraPerformance كعبارة ExpressRoute. تنطبق الاستثناءات عند استخدام ExpressRoute FastPath (انظر أدناه).
ExpressRoute FastPath
في مايو 2019، أصدرنا ExpressRoute FastPath. يقلل FastPath من زمن الانتقال بين مثيلات HANA الكبيرة وشبكات Azure الظاهرية التي تستضيف الأجهزة الظاهرية لتطبيق SAP. مع FastPath، لا يتم توجيه تدفق البيانات بين VMs و HANA مثيلات كبيرة من خلال عبارة ExpressRoute. تتصل VMs المعين في الشبكة الفرعية (الشبكات) للشبكة الظاهرية Azure مباشرة مع موجه حافة المؤسسة المخصص.
هام
يتطلب ExpressRoute FastPath أن الشبكات الفرعية التي تعمل على VMs تطبيق SAP في نفس شبكة اتصال Azure الظاهرية المتصلة مثيلات HANA الكبيرة. لا تستفيد VMs الموجودة في شبكات Azure الظاهرية التي يتم نظيرها مع شبكة الاتصال الظاهرية Azure المتصلة بوحدات مثيل كبير HANA من ExpressRoute FastPath. ونتيجة لذلك، لوحة الوصل النموذجية وتصاميم شبكة الاتصال الظاهري تكلم، حيث الدوائر ExpressRoute الاتصال مقابل شبكة اتصال ظاهرية محور والشبكات الافتراضية التي تحتوي على طبقة تطبيق SAP (المتحدثين) peered، التحسين بواسطة ExpressRoute FastPath لن تعمل. لا يدعم ExpressRoute FastPath حاليا قواعد التوجيه المعرفة من قبل المستخدم (UDR). لمزيد من المعلومات، راجع حول بوابات الشبكة الظاهرية لـ ExpressRoute.
لمزيد من المعلومات حول كيفية تكوين ExpressRoute FastPath، راجع الاتصال شبكة ظاهرية إلى مثيلات HANA الكبيرة.
إشعار
مطلوب بوابة ExpressRoute فائقة الأداء لاستخدام ExpressRoute FastPath.
الأنظمة المفردة لـ SAP
يتم توصيل البنية الأساسية المحلية المعروضة سابقا من خلال ExpressRoute إلى Azure. تتصل دائرة ExpressRoute ب MSEE. لمزيد من المعلومات، راجع نظرة عامة على ExpressRoute. بعد إنشاء المسار، يتصل بالعمود الأساسي ل Azure.
إشعار
لتشغيل وضع SAP الأفقي في Azure، اتصل بجهاز التوجيه الطرفي للمؤسسة الأقرب إلى منطقة Azure في وضع SAP الأفقي. يتم توصيل طوابع مثيل كبير HANA من خلال أجهزة توجيه حافة المؤسسة المخصصة لتقليل زمن وصول الشبكة بين VMs في طوابع Azure IaaS وHANA Large Instance.
يتم توصيل عبارة ExpressRoute ل VMs التي تستضيف مثيلات تطبيق SAP إلى دائرة ExpressRoute واحدة تتصل محلية. يتم توصيل نفس الشبكة الظاهرية إلى جهاز توجيه حافة المؤسسة منفصلة. تم تخصيص جهاز التوجيه الطرفي هذا للاتصال بطوابع المثيل الكبير. مرة أخرى، مع FastPath، لا يتم توجيه تدفق البيانات من مثيلات HANA الكبيرة إلى الأجهزة الظاهرية لطبقة تطبيق SAP عبر بوابة ExpressRoute. يقلل هذا التكوين من زمن انتقال الشبكة ذهابا وإيابا.
هذا النظام هو مثال مباشر لنظام SAP واحد. طبقة تطبيق SAP مُستضافة في Azure. تعمل قاعدة بيانات SAP HANA على SAP HANA على Azure (Large Instances). الافتراض هو أن النطاق الترددي لمعدل نقل بوابة ExpressRoute البالغ 2 جيجابت في الثانية أو 10 جيجابت في الثانية لا يمثل ازدحامًا.
أنظمة SAP متعددة أو أنظمة SAP كبيرة
إذا قمت بنشر أنظمة SAP متعددة أو أنظمة SAP كبيرة تتصل SAP HANA (مثيلات كبيرة)، قد تصبح الإنتاجية من عبارة ExpressRoute اختناق. في هذه الحالة، تقسيم طبقات التطبيق إلى شبكات ظاهرية متعددة. يمكنك أيضا تقسيم طبقات التطبيق إذا كنت تريد عزل أنظمة الإنتاج وغير الإنتاج في شبكات Azure الظاهرية المختلفة.
قد تقوم بإنشاء شبكة اتصال ظاهرية خاصة تتصل بمثيلات HANA الكبيرة عند:
- القيام النسخ الاحتياطي مباشرة من مثيلات HANA في مثيل HANA كبير إلى VM في Azure الذي يستضيف مشاركات NFS.
- نسخ النسخ الاحتياطية الكبيرة أو الملفات الأخرى من مثيلات HANA الكبيرة إلى مساحة القرص المدارة في Azure.
استخدم شبكة ظاهرية منفصلة لاستضافة الأجهزة الظاهرية التي تدير التخزين لنقل البيانات بشكل كبير بين مثيلات HANA الكبيرة وAzure. يتجنب هذا الترتيب نقل الملفات الكبيرة أو البيانات من مثيلات HANA الكبيرة إلى Azure على بوابة ExpressRoute التي تخدم الأجهزة الظاهرية التي تقوم بتشغيل طبقة تطبيق SAP.
للحصول على بنية شبكة أكثر قابلية للتوسعة:
استخدم شبكات ظاهرية متعددة لطبقة تطبيق SAP واحدة أكبر.
نشر شبكة ظاهرية منفصلة واحدة لكل نظام SAP منشور، مقارنةً بدمج أنظمة SAP ذات الصلة في الشبكات الفرعية المنفصلة في إطار نفس الشبكة الظاهرية.
يوضح الرسم التخطيطي التالي بنية شبكة أكثر قابلية للتوسيع SAP HANA على Azure (مثيلات كبيرة):
اعتمادا على القواعد والقيود التي تريد تطبيقها بين مختلف الشبكات الافتراضية استضافة VMs من أنظمة SAP مختلفة، يجب أن نظير تلك الشبكات الظاهرية. لمزيد من المعلومات حول نظير الشبكة الظاهرية، راجع نظير الشبكة الظاهرية.
التوجيه في Azure
من خلال النشر الافتراضي، تكون ثلاثة اعتبارات لتوجيه الشبكة مهمة SAP HANA على Azure (المثيلات الكبيرة):
يمكن الوصول إلى SAP HANA على Azure (مثيلات كبيرة) فقط من خلال نظام رصد السفن Azure واتصال ExpressRoute المخصص، وليس مباشرة من أماكن العمل. لا يمكن الوصول المباشر من الموقع المحلي إلى وحدات مثيل HANA الكبير، كما سلمتها Microsoft إليك، على الفور. قيود التوجيه العابرة بسبب بنية شبكة Azure الحالية المستخدمة في مثيلات SAP HANA الكبيرة. لا يمكن الاتصال بعض عملاء الإدارة وأية تطبيقات تحتاج إلى الوصول المباشر، مثل إدارة حلول SAP التي تعمل محليا، إلى قاعدة بيانات SAP HANA. للحصول على استثناءات، راجع القسم التالي، التوجيه المباشر إلى مثيلات HANA الكبيرة.
إذا كان لديك وحدات مثيل كبير HANA نشرها في منطقتين Azure مختلفة للتعافي من الكوارث، يتم تطبيق قيود التوجيه العابرة نفسها كما في الماضي. بمعنى آخر، لم يتم توجيه عناوين IP لمثيل HANA الكبير في منطقة واحدة (على سبيل المثال، غرب الولايات المتحدة) إلى مثيل HANA كبير تم نشره في منطقة أخرى (على سبيل المثال، شرق الولايات المتحدة). هذا التقييد مستقل عن استخدام شبكة Azure التي تناظر المناطق أو عبر الاتصال بدوائر ExpressRoute التي تربط مثيلات HANA الكبيرة بالشبكات الظاهرية. للحصول على تمثيل رسومي، راجع الشكل الموجود في القسم، استخدام وحدات مثيل HANA الكبيرة في مناطق متعددة. حظر هذا التقييد، الذي جاء مع الهندسة المعمارية المنشورة، الاستخدام الفوري للنسخ المتماثل لنظام HANA للتعافي من الكوارث. للاطلاع على التغييرات الأخيرة، مرة أخرى، راجع استخدام وحدات مثيل HANA الكبيرة في مناطق متعددة.
يحتوي SAP HANA على مثيلات Azure الكبيرة على عنوان IP معين من نطاق عنوان تجمع IP للخادم الذي قمت بإرساله عند طلب نشر مثيل كبير HANA. لمزيد من المعلومات، راجع البنية الأساسية SAP HANA (المثيلات الكبيرة) والاتصال على Azure. يمكن الوصول إلى عنوان "IP" ذي الصلة من خلال اشتراكات Azure والدائرة التي تربط شبكات Azure الظاهرية بمثيلات HANA الكبيرة. عنوان IP المُعين خارج نطاق عناوين تجمع IP للخادم يُعين مباشرةً إلى وحدة الأجهزة. لم يُعيَن من خلال ترجمة عناوين الشبكة (NAT)، كما كان الحال في عمليات النشر الأولى لهذا الحل.
التوجيه المباشر إلى مثيلات HANA الكبيرة
بشكل افتراضي، لا يعمل التوجيه العابر في هذه السيناريوهات:
بين وحدات مثيل HANA الكبيرة والنشر المحلي.
بين وحدات مثيل كبير HANA المنتشرة في مناطق مختلفة.
هناك ثلاث طرق لتمكين التوجيه العابر في هذه السيناريوهات:
- وكيل عكسي لتوجيه البيانات، من وإلى. على سبيل المثال، F5 BIG-IP، NGINX مع مدير نسبة استخدام الشبكة الذي تم نشره في شبكة Azure الظاهرية التي تتصل بمثيلات HANA الكبيرة والمحلية كحل افتراضي لجدار الحماية/توجيه حركة المرور.
- استخدام قواعد IPTables في Linux VM لتمكين التوجيه بين المواقع المحلية ووحدات مثيل HANA الكبير، أو بين وحدات مثيل كبير HANA في مناطق مختلفة. يجب نشر VM تشغيل IPTables في شبكة الاتصال الظاهري Azure الذي يتصل مثيلات كبيرة HANA و إلى محلية. يجب أن يكون حجم الجهاز الظاهري بحيث تكون سرعة نقل الشبكة من VM كافية لنسبة استخدام الشبكة المتوقعة. لمزيد من المعلومات حول النطاق الترددي لشبكة VM، راجع المقالة أحجام الأجهزة الظاهرية Linux في Azure.
- سيكون جدار حماية Azure حلا آخر لتمكين نسبة استخدام الشبكة المباشرة بين وحدات مثيل HANA الكبيرة والوحدات المحلية.
سيتم توجيه كل نسبة استخدام الشبكة هذه الحلول عبر شبكة Azure الظاهرية. على هذا النحو، يمكن أيضا تقييد نسبة استخدام الشبكة بواسطة الأجهزة اللينة المستخدمة أو بواسطة مجموعات أمان شبكة Azure. وبهذه الطريقة، يمكن حظر عناوين IP محددة أو عناوين IP من محلية أو السماح صراحة الوصول إلى مثيلات HANA الكبيرة.
إشعار
يجب أن تدرك أن تطبيق ودعم الحلول المخصصة التي تتضمن أجهزة شبكة اتصال تابعة لجهة خارجية أو IPTables لا يتم توفيره من قبل Microsoft. يجب توفير الدعم من قبل مورد المكون المستخدم أو من قبل المدمج.
الوصول السريع للطريق العالمي
قدمت Microsoft وظيفة جديدة تسمى ExpressRoute Global Reach. يمكن استخدام Global Reach لمثيلات HANA الكبيرة في سيناريوهين:
- تمكين الوصول المباشر من الداخل إلى وحدات مثيل HANA الكبيرة المنتشرة في مناطق مختلفة.
- تمكين الاتصال المباشر بين وحدات مثيل HANA الكبير المنتشرة في مناطق مختلفة.
الوصول المباشر من أماكن العمل
في مناطق Azure حيث يتم تقديم الوصول العالمي، يمكنك طلب تمكين الوصول العالمي لدائرة ExpressRoute الخاصة بك. تقوم هذه الدائرة بتوصيل شبكتك المحلية بشبكة Azure الظاهرية التي تتصل بمثيلات HANA الكبيرة. هناك تكاليف للجانب المحلي من دائرة ExpressRoute الخاصة بك. لمزيد من المعلومات، راجع تسعير الوظيفة الإضافية للوصول العالمي. لن تدفع تكاليف إضافية للدائرة التي تربط مثيلات HANA الكبيرة ب Azure.
هام
عند استخدام "الوصول العالمي" لتمكين الوصول المباشر بين وحدات مثيل HANA الكبير والأصول المحلية، لا يتم توجيه بيانات الشبكة وتدفق التحكم عبر الشبكات الظاهرية Azure. بدلا من ذلك، يتم توجيه بيانات الشبكة وتدفق التحكم مباشرة بين أجهزة توجيه Microsoft Enterprise Exchange. لذلك لن يتم لمس أي قواعد NSG أو ASG، أو أي نوع من جدار الحماية أو NVA أو الوكيل الذي قمت بنشره في شبكة Azure الظاهرية. إذا كنت تستخدم ExpressRoute Global Reach لتمكين الوصول المباشر من الداخل إلى وحدات مثيل HANA الكبير، يجب تعريف القيود المفروضة على الوصول إلى وحدات مثيل HANA الكبير المثبتة في جدران الحماية الداخلية.
توصيل مثيلات HANA الكبيرة في مناطق Azure مختلفة
وبالمثل، يمكن استخدام ExpressRoute Global Reach للاتصال بين مستأجري مثيل كبير HANA نشر في مناطق مختلفة. العزل هو الدوائر ExpressRoute التي يستخدمها مستأجرو مثيل HANA الكبير للاتصال ب Azure في كلتا المنطقتين. لا توجد رسوم إضافية لربط اثنين من مستأجري مثيل HANA الكبير المنتشرين في مناطق مختلفة.
هام
لن يتم توجيه تدفق البيانات وتدفق التحكم في نسبة استخدام الشبكة بين مستأجري مثيل HANA الكبير عبر شبكات Azure. لذلك لا يمكنك استخدام وظائف Azure أو الأجهزة الظاهرية للشبكة (NVAs) لفرض قيود الاتصال بين مستأجري مثيلات HANA الكبيرة.
لمزيد من المعلومات حول كيفية تمكين الوصول العالمي ل ExpressRoute، راجع الاتصال شبكة ظاهرية إلى مثيلات HANA الكبيرة.
اتصال الإنترنت من HANA مثيل كبير
لا تحتوي مثيلات HANA الكبيرة على اتصال مباشر بالإنترنت. على سبيل المثال، قد يحد هذا القيد من قدرتك على تسجيل صورة نظام التشغيل مباشرة لدى بائع نظام التشغيل. قد تحتاج إلى العمل مع خادم أداة إدارة اشتراك خادم المؤسسة SUSE Linux المحلي أو إدارة اشتراك Red Hat Enterprise Linux.
تشفير البيانات بين الأجهزة الظاهرية ومثيل HANA الكبير
البيانات المنقولة بين مثيلات HANA الكبيرة و VMs غير مشفرة. فقط للتبادل بين جانب HANA DBMS والتطبيقات المستندة إلى JDBC / ODBC، ومع ذلك، يمكنك تمكين تشفير حركة المرور. لمزيد من المعلومات، راجع الاتصال الآمن بين SAP HANA وعملاء JDBC/ODBC.
استخدام وحدات مثيل HANA الكبيرة في مناطق متعددة
للتعافي من الكوارث، يجب أن يكون لديك وحدات مثيل HANA كبير في مناطق Azure متعددة. باستخدام نظير Azure Global Vnet Peering فقط، لن يعمل التوجيه الانتقالي بشكل افتراضي بين مستأجري مثيل HANA الكبير في مناطق مختلفة. ومع ذلك، يفتح Global Reach التواصل بين وحدات مثيل HANA كبير في مناطق مختلفة. يتيح هذا السيناريو باستخدام ExpressRoute Global Reach ما يلي:
- النسخ المتماثل لنظام HANA دون أي وكلاء أو جدران حماية أخرى.
- نسخ النسخ الاحتياطية بين وحدات مثيل كبير HANA في مناطق مختلفة لإجراء نسخ النظام أو القيام بتحديث النظام.
يوضح الشكل السابق كيفية اتصال الشبكات الافتراضية في كلتا المنطقتين بدائرتين من دوائر ExpressRoute. يتم استخدام الدوائر للاتصال SAP HANA على Azure (مثيلات كبيرة) في كل من منطقتي Azure (الخطوط الرمادية). السبب في وجود وصلتين متقاطعتين هو الحماية من انقطاع MSEEs على كلا الجانبين. من المفترض أن يتم التعامل مع تدفق الاتصال بين الشبكتين الظاهريتين في منطقتي Azure عبر نظير عالمي للشبكتين الظاهريتين في المنطقتين المختلفتين (الخط الأزرق المنقط). يصف الخط الأحمر السميك اتصال ExpressRoute Global Reach. يسمح هذا الاتصال لوحدات مثيل HANA كبير الخاصة بالمستأجرين في مناطق مختلفة بالتواصل مع بعضهم البعض.
هام
إذا كنت تستخدم العديد من دوائر ExpressRoute، فاستخدم إعدادات AS Path المسبقة وإعدادات BGP للتفضيلات المحلية لضمان التوجيه السليم لحركة المرور.
الخطوات التالية
تعرف على بنية التخزين SAP HANA (المثيلات الكبيرة).