في 25 سبتمبر 2026 أعلنت Google Cloud الإتاحة العامة لسلسلة X5 المحسّنة للذاكرة، لترفع سقف العقدة الواحدة من 32 تيرابايت في X4 إلى 48 تيرابايت. العنوان لافت لأن X5 ليست مجرد VM أكبر؛ إنها Bare Metal مخصصة لأحمال SAP HANA الضخمة بنمط Scale-up وأحمال أخرى كثيفة الذاكرة، مع ما يصل إلى 2,064 vCPU ومعالجات Intel Granite Rapids.
قد تزيل 16 تيرابايت الإضافية حدًا معماريًا صلبًا من أمام قاعدة بيانات تحتاج إبقاء Working Set واحدة في الذاكرة. لكنها تجمع أيضًا تكلفة ومخاطر تشغيلية أكبر في مضيف واحد. لذلك ليس السؤال المفيد: هل 48 تيرابايت رقم كبير؟ بل: هل يستفيد الحمل من نظام Scale-up موحّد بما يكفي لقبول قيود التخزين ونظام التشغيل والتوافر والتعافي في X5؟
ما الذي أصبح متاحًا؟
تذكر ملاحظات إصدار Compute Engine أن X5 أصبحت متاحة عمومًا بتكوين يصل إلى 48 تيرابايت، أي أعلى 50% من حد X4 السابق. تسرد وثائق عائلة Memory-optimized الحالية أشكال Bare Metal جاهزة من 12 إلى 48 تيرابايت ومن 688 إلى 2,064 vCPU. تستخدم X5 الجيل السادس من Intel Xeon Scalable المعروف باسم Granite Rapids إلى جانب بنية Titanium من Google.
تتيح الآلة موارد المضيف الخام بدل تشغيل Guest تقليدي خلف Hypervisor. توثق Google مسرّعات مدمجة، منها Intel QAT لأعمال التشفير والضغط، وDLB لتوزيع الحمل الديناميكي، وDSA لنقل البيانات، وIAA لتحليلات الذاكرة. وجود هذه الوحدات لا يضمن تسريعًا تلقائيًا؛ يجب أن تستخدمها البرمجيات والتعريفات وتوزيعات العمل فعلًا، وأن تحل قياسات التطبيق محل افتراضات الأداء النظري.
تقدم Google السلسلة لأحمال SAP HANA فائقة الحجم بنمط Scale-up والحوسبة عالية الأداء. تسرد شهادات SAP أشكال 12 و16 و24 و32 و48 تيرابايت لأحمال SAP. وتوضح تحديدًا أن الشكل الأعلى `x5-2064-48T-metal` متاح لأحمال SAP التي تديرها SAP ضمن RISE with SAP. هذا الشرط مهم: لا ينبغي التعامل مع أكبر شكل معلن كخادم HANA عام متاح بلا قيود قبل فحص الأهلية التجارية وشهادة الحمل والمنطقة المختارة.
يحل Scale-up مشكلة ويكبر أخرى
يبقي Scale-up قاعدة البيانات الكبيرة داخل صورة نظام تشغيل واحدة، ويجنب توزيع كل Query وTransaction وLock بين عقد متعددة. في SAP HANA قد يحافظ الشكل الأكبر المعتمد على نموذج نشر يفهمه الفريق مع استيعاب بيانات أكثر، كما قد يقلل تغييرات التطبيق المطلوبة للانتقال إلى Sharding أوقاعدة بيانات مختلفة.
لكن السعة ليست Resilience. مضيف بسعة 48 تيرابايت يصنع نطاق فشل وصيانة كبيرًا بالقدر نفسه. وحتى مع وجود Replica على نظام آخر، قد يستغرق Restart وRestore وLog Replay وإحماء الذاكرة وقتًا طويلًا. تنص Google على أن إقلاع X5 قد يستغرق حتى 30 دقيقة بسبب حجم العتاد وPower-On Self-Test. يجب إدخال هذا الزمن في أهداف التعافي واختباراته، لا إخفاؤه خلف Health Check مصمم لـVM عادية.
تتضمن المقارنة السليمة ثلاث معماريات على الأقل: مضيف Scale-up معتمد أصغر، ومضيف X5 مع Secondary مُختبر، وتصميم Scale-out. قارن توافق التطبيق وزمن Failover واستعادة التخزين والتعقيد التشغيلي وإجمالي السعة المحجوزة، لا سعر جيجابايت الذاكرة وحده. يضيف Scale-out تنسيقًا موزعًا وتغييرات للتطبيق غالبًا؛ يقلل Scale-up هذه الكلفة لكنه يرفع قيمة عقدة واحدة ونطاق أثرها.
تصبح NUMA جزءًا من مسؤولية التطبيق
الآلة التي تضم آلاف vCPUs وعشرات التيرابايتات هي نظام Non-Uniform Memory Access. الوصول إلى الذاكرة المتصلة بنطاق CPU محلي أرخص من الوصول إلى ذاكرة بعيدة. بهذا الحجم قد تظهر للنظام ذاكرة شاغرة وفيرة بينما يعاني من Remote Memory Traffic أوThread Migration أوتوزيع غير متوازن. متوسط CPU لن يفسر هذا النوع من الفشل.
قبل الانتقال، أعد تشغيل Concurrency وحجم بيانات قريبين من الإنتاج، واجمع Metrics لكل نطاق NUMA عن المعالج وتخصيص الذاكرة والوصول البعيد وMemory Bandwidth. تحقق أن نظام التشغيل وإصدار قاعدة البيانات وWorkload Scheduler تفهم Topology. قد تفيد Pinning وHuge Pages وسياسات الذاكرة بعض المحركات، لكنها قرارات ضبط تحتاج دعم المورد ودليلًا عمليًا. لا تنسخ إعدادًا من آلة أصغر وتفترض أنه يتوسع خطيًا.
راقب Tail Query Latency وTransaction Throughput وتشبع Memory Bandwidth وPage Faults والانتظار وزمن استعادة Working Set بعد Restart. اختبر Steady State والوظائف التي تتنافس على الذاكرة: Backup والضغط وتحميل البيانات وبناء الفهارس وAnalytical Scans. ينجح الانتقال عندما يبقى الحمل الكامل متوقعًا، لا عندما يصبح Query واحد أسرع.
التخزين والشبكة عقد جديد
تقبل X5 تخزين Google Cloud Hyperdisk فقط عبر NVMe. لا تدعم Persistent Disk ولاLocal SSD ولاSCSI ولاVirtIO-net ولاgVNIC. توثق Google أن عائلات Hyperdisk Balanced وExtreme وThroughput وML متاحة للسلسلة، بينما يحدد جدول تخطيط SAP HANA عائلتي Balanced وExtreme لأشكال X5 المعتمدة لـHANA. اختر المنتج وفق الحمل والشهادة؛ لا تفترض أن كل Volume متوافق مع X5 صالح لكل مسار Data أوLog في SAP.
احسب Throughput وIOPS وLatency بصورة منفصلة من القياسات. قد تلائم قاعدة البيانات الذاكرة وتتعطل مع Redo Logs أوCheckpoints أوBackup Streams أوإعادة التحميل بعد فشل. اضبط تخطيط Volumes النهائي وQueue Depth وحدود الربط واختبرها. نفذ Restore من طبقة النسخ الاحتياطي الفعلية وقِس الزمن حتى تصبح الخدمة مفيدة، لا زمن إقلاع المضيف فقط.
تستخدم الشبكة تعريف Intel IDPF المحسن لدى Google، وتذكر وثائق X5 حدًا يصل إلى 200 Gbps حسب شكل الآلة. تحقق أن صورة نظام التشغيل المدعومة تتضمن التعريف وأن Monitoring تكشف الأخطاء وDrops والتشبع. الحد الأقصى للوصلة ليس Application Throughput، كما يضيف Replication بين المناطق زمن انتقال واعتماديات لا يظهرها Benchmark محلي.
قيود التوافر والأمان مدخلات معمارية
تتوفر X5 بأشكال محددة مسبقًا وفي Regions وZones مختارة فقط؛ لا توجد Custom Shapes. كما لا تدعم كل صور أنظمة التشغيل، ويجب أن تكون الصورة المخصصة متوافقة مع UEFI. يبدأ تخطيط السعة إذن من الموقع وQuota والشراء، لا من Terraform Variable. توجه Google العميل إلى مدير حساب للحصول على السعر والطلب، بما فيه On-demand للاختبار؛ لذلك لا يصلح افتراض قائمة سعر عامة كأساس لحالة العمل.
يزيل Bare Metal أيضًا تسهيلات تتوقعها فرق VM. تقول Google إن X5 لا تدعم Live Migration ولاShielded VM، ولا توفر Hypervisor ولا تفعّل Nested Virtualization. لا تجعل هذه الحقائق المنصة غير آمنة تلقائيًا، لكنها تغير مجموعة الضوابط. اختبر متطلبات Secure Boot والصور وتشفير الأقراص والهوية والتسجيل والتحديث وإدارة الثغرات وصيانة المضيف وفق عقد Bare Metal الفعلي.
يجب أن تفترض خطة الصيانة أن الحمل لن ينتقل بصمت إلى مضيف آخر. وثّق طريقة تحويل Traffic إلى Secondary، وكيف تمنع صحة Replication صيانة غير آمنة، وكيف يعيد الفريق الخدمة دون Split Brain. إذا كان المتطلب يعتمد على Nested Virtualization أوAppliance مبني حول Virtual NIC تقليدية، فـX5 هدف خاطئ مهما كان حجم الذاكرة.
بوابات عملية قبل الانتقال
ابدأ بالدليل لا بأكبر شكل. اجمع Peak Used Memory ومعدل النمو وسلوك الضغط وCPU Profile وMemory Bandwidth وLog Rate وStorage Latency ومدة Backup وزمن التعافي المُختبر. أضف Headroom لعمليات مثل Upgrade وبناء Index. أكد شكل X5 والمنطقة ونظام التشغيل وشهادة SAP أو دعم الحمل بدقة قبل الشراء.
ابنِ Rehearsal قريبًا من الإنتاج على أصغر شكل X5 ممثل متاح للبرنامج. اختبر أتمتة الإقلاع والتجهيز، وتعريفات IDPF وNVMe، وسلوك NUMA، وإعداد قاعدة البيانات، وأداء Hyperdisk، والمراقبة، وBackup Restore. ثم احقن الفشل: أوقف Primary، واقطع مسار تخزين، وأخّر Replication، وأعد التشغيل من Working Set باردة. قِس RPO وRTO بدل إعلان النجاح بعد Import نظيف.
لا تنتقل إلا بعد نجاح أربع بوابات: يحتاج الحمل ذاكرة Scale-up فعلًا؛ يبقى التطبيق متوقعًا عبر نطاقات NUMA؛ يحقق التخزين والنسخ أهداف التعافي؛ وتقبل المؤسسة قيود المنطقة والدعم والصيانة والتعاقد. وإلا فاختر شكلًا معتمدًا أصغر أواستثمر في Scale-out. قيمة X5 الحقيقية ليست أن كل نظام يمكن أن يكبر، بل أن فئة ضيقة من الأنظمة تستطيع تأجيل إعادة تصميم موزعة أكثر إزعاجًا، بشرط التعامل مع 48 تيرابايت كالتزام معماري لا كخانة سعة.
المراجع الرسمية
تدعم هذه المراجع سلوك الأدوات المذكورة. الأمثلة وقرارات التصميم توضيحية، ويجب تكييفها مع متطلبات المشروع وإصداراته.
إعداد: Noor Yasser
تعمل على تحدٍ تقني مشابه؟
أساعد الفرق على تحويل القرار المعماري إلى نطاق واضح وتنفيذ يمكن تشغيله ومراجعته بثقة.
