السحابة المتعددة: Azure وGCP

الحوسبة والشبكات في Google Cloud

18 دقيقة الدرس 6 من 28

الحوسبة والشبكات في Google Cloud

بُنيت منصة Google Cloud Platform من الداخل إلى الخارج — على نفس البنية التحتية العالمية التي تخدم Google Search وGmail وYouTube. هذا ليس تسويقاً؛ بل يحدد مباشرةً كيفية حوسبة GCP وتوجيه حركة المرور، ولماذا تختلف بنيتها المعمارية عن AWS وAzure معاً بطرق تهم كثيراً على نطاق واسع. في هذا الدرس ستتعلم GCE (طبقة الجهاز الافتراضي الخام)، ونموذج VPC العالمي الفريد في GCP، وطبقة موازنة الأحمال التي تعمل على حافة شبكة Google نفسها.

محرك الحوسبة من Google (GCE)

GCE هو خدمة IaaS للأجهزة الافتراضية في GCP. على السطح تشبه EC2 — تختار نوع الجهاز والصورة والقرص والشبكة — لكن ثلاثة قرارات تصميمية تميّزها.

أنواع الأجهزة المخصصة. بدلاً من الاختيار من قائمة ثابتة من عائلات الأجهزة، تتيح لك GCE تحديد نسبة دقيقة من المعالجات الافتراضية والذاكرة. تحتاج إلى 6 vCPU و22 غيغابايت ذاكرة وصول عشوائي لتطبيق قديم لا يناسب الأشكال القياسية؟ هذا خيار من الدرجة الأولى. يهمّ هذا من الناحية التشغيلية لأن ضبط حجم الأجهزة الافتراضية هو أعلى تحسين للتكلفة عائداً، وGCE تجعله دقيقاً.

الترحيل المباشر. تُرحّل Google الأجهزة الافتراضية قيد التشغيل بشفافية عبر المضيفين الفعليين أثناء أحداث الصيانة — دون إعادة تشغيل قسرية أو نوافذ مقاطعة لجدولتها. تقدم AWS وAzure نوافذ صيانة مجدولة؛ تجعل GCE ذلك غير مرئي افتراضياً.

الأجهزة الافتراضية القابلة للاستباق وSpot. مكافئ Spot في AWS في GCE هي Spot VMs. أرخص بنسبة تصل إلى 91% لكن يمكن استرجاعها بإشعار 30 ثانية. مثالية للمهام الدُفعية عديمة الحالة وعمّال CI وتدريب نماذج التعلم الآلي مع نقاط تفتيش متكررة.

# إنشاء Spot VM بنوع جهاز مخصص وسكريبت بدء تشغيل
gcloud compute instances create batch-worker-1 \
  --zone=us-central1-a \
  --machine-type=custom-8-32768 \       # 8 vCPU, 32 غيغابايت ذاكرة
  --provisioning-model=SPOT \
  --instance-termination-action=DELETE \
  --image-family=debian-12 \
  --image-project=debian-cloud \
  --boot-disk-size=50GB \
  --boot-disk-type=pd-ssd \
  --metadata=startup-script='#!/bin/bash
    echo "Worker started" >> /var/log/startup.log
    /opt/job/run.sh' \
  --scopes=storage-rw,logging-write

# عرض قائمة الأجهزة الافتراضية قيد التشغيل وحالتها
gcloud compute instances list --filter="status=RUNNING" --format="table(name,zone,machineType,status)"

تتبع أنواع أجهزة GCE اصطلاح التسمية {family}-{vCPU}[-{memory}]. للأغراض العامة: n2-standard-4 (4 vCPU، 16 غيغابايت). للحوسبة المُحسَّنة: c3-highcpu-8. للذاكرة المُحسَّنة: m3-megamem-64. مخصص: custom-6-22528 (6 vCPU، 22 غيغابايت). تحقق من gcloud compute machine-types list --zones us-central1-a للتوفر الحالي.

نموذج GCP العالمي للشبكات الافتراضية الخاصة (VPC)

هنا يتباين GCP بشكل أساسي عن AWS. في AWS، الـ VPC إقليمي — تنشئ VPCs منفصلة لكل منطقة وتربطها بالتناظر أو Transit Gateway. في GCP، يمتد VPC واحد عبر جميع المناطق عالمياً. تضيف شبكات فرعية في مناطق محددة، لكنها تنتمي جميعها إلى شبكة منطقية واحدة ويمكنها التواصل باستخدام عناوين RFC-1918 الداخلية دون أي تناظر أو بوابة.

التداعيات العملية كبيرة:

مجموعة GKE في us-central1 ونموذج Cloud SQL في europe-west4 يمكنهما التواصل عبر عناوين IP خاصة دون إعداد شبكة إضافي — نفس الـ VPC.
قواعد جدار الحماية تُطبَّق على VPC ككل، باستخدام علامات الشبكة أو حسابات الخدمة كأهداف بدلاً من مجموعات الأمان المحدودة بـ VPC. يمكن إرفاق علامة مثل allow-http بأي جهاز افتراضي في أي مكان بالـ VPC.
نطاقات IP للشبكة الفرعية إقليمية لكنها لا تحتاج إلى أن تكون فريدة عبر المناطق.

VPC ذو الوضع التلقائي في GCP ينشئ شبكة فرعية في كل منطقة تلقائياً. يبدو ملائماً لكنه فخ في الإنتاج: تفقد السيطرة على نطاقات CIDR، وكتلة 10.128.0.0/9 الافتراضية تتعارض مع كثير من الشبكات المحلية. أنشئ دائماً VPCs ذات وضع مخصص في الإنتاج وحدد CIDRs الخاصة بك بعناية.

VPC واحد عالمي في GCP يغطي جميع المناطق بشكل مدمج؛ تحتاج AWS إلى تناظر صريح أو Transit Gateway لحركة المرور الخاصة عبر المناطق.

Shared VPC وتناظر شبكات VPC

على نطاق المؤسسات، لا يكفي VPC واحد. تقدم GCP نموذجين متعدد الشبكات: Shared VPC وVPC Network Peering. يُعيّن Shared VPC مشروعاً واحداً كمضيف ويسمح لمشاريع خدمة متعددة بإرفاق مواردها (الأجهزة الافتراضية، عقد GKE) بالشبكات الفرعية للمضيف. هذا يُمركز إدارة الشبكة — تُدار قواعد جدار الحماية والشبكات الفرعية من قبل فريق المنصة بينما تنشر فرق التطبيقات بحرية في تلك الشبكات الفرعية.

# تفعيل Shared VPC على مشروع المضيف (تشغيله كـ Org Admin)
gcloud compute shared-vpc enable my-host-project

# إرفاق مشروع خدمة بـ VPC المضيف
gcloud compute shared-vpc associated-projects add my-app-project \
  --host-project=my-host-project

# إنشاء شبكة فرعية في مشروع المضيف متاحة لمشاريع الخدمة
gcloud compute networks subnets create prod-app-subnet \
  --network=prod-vpc \
  --region=us-central1 \
  --range=10.20.0.0/24 \
  --project=my-host-project

# منح حساب خدمة مشروع التطبيق صلاحية Compute Network User على الشبكة الفرعية
gcloud compute networks subnets add-iam-policy-binding prod-app-subnet \
  --region=us-central1 \
  --member="serviceAccount:app-sa@my-app-project.iam.gserviceaccount.com" \
  --role="roles/compute.networkUser" \
  --project=my-host-project

موازنة أحمال Cloud: ميزة Google

موازنة الأحمال في GCP ليست أسطولاً من الأجهزة الافتراضية مُنشأة في VPC — إنها نظام موزع عالمياً يعمل على بنية Google التحتية الحدّية (نفس البنية التي تمتص هجمات DDoS بمعدل Tbps). تدخل حركة المرور شبكة Google عند أقرب نقطة حضور، ويتخذ موازن الأحمال قرارات التوجيه هناك قبل أن تصل الحزمة إلى أجهزتك الافتراضية. هذا له ثلاث نتائج ملموسة لمهندسي DevOps:

عناوين IP Anycast. عنوان IP عالمي واحد يوجه إلى مجموعة الخوادم الخلفية الأقرب والسليمة حول العالم.
تجاوز فشل شبه فوري. لأن فحوصات صحة الخادم الخلفي تُشغَّل من بنية Google التحتية، يُكتشف تجاوز الفشل ويُنشر في أقل من 10 ثوانٍ عالمياً.
Cloud Armor مدمج. جدار حماية تطبيقات الويب من GCP (Cloud Armor) يتكامل مباشرة مع HTTP(S) LB عند الحافة. تخفيف DDoS وتقييم قواعد OWASP يحدثان قبل وصول حركة المرور إلى VPC.

تقدم GCP عدة مستويات من موازنة الأحمال. اعرف أيها تستخدم:

Global HTTP(S) LB — الطبقة 7، anycast، خوادم خلفية متعددة المناطق، تكامل Cloud CDN. للخدمات العامة.
Regional Internal HTTP(S) LB — الطبقة 7، خاص، داخل VPC. لحركة المرور الشرقية-الغربية.
TCP/UDP Network LB — الطبقة 4، إقليمي، إنتاجية عالية. للبروتوكولات غير HTTP.
Internal TCP/UDP LB — الطبقة 4، خاص، للخدمات الداخلية.

# --- Terraform: موازن أحمال HTTP(S) عالمي لمجموعة أجهزة GCE ---

resource "google_compute_instance_group_manager" "app" {
  name               = "app-mig"
  base_instance_name = "app"
  zone               = "us-central1-a"
  target_size        = 3

  version {
    instance_template = google_compute_instance_template.app.id
  }

  named_port {
    name = "http"
    port = 8080
  }

  auto_healing_policies {
    health_check      = google_compute_health_check.app.id
    initial_delay_sec = 60
  }
}

resource "google_compute_health_check" "app" {
  name               = "app-health-check"
  check_interval_sec = 10
  timeout_sec        = 5

  http_health_check {
    port         = 8080
    request_path = "/healthz"
  }
}

resource "google_compute_backend_service" "app" {
  name                  = "app-backend"
  protocol              = "HTTP"
  port_name             = "http"
  load_balancing_scheme = "EXTERNAL_MANAGED"
  timeout_sec           = 30

  backend {
    group           = google_compute_instance_group_manager.app.instance_group
    balancing_mode  = "UTILIZATION"
    max_utilization = 0.8
  }

  health_checks = [google_compute_health_check.app.id]

  log_config {
    enable      = true
    sample_rate = 1.0
  }
}

فعّل Premium Tier للشبكات لجميع موازنات الأحمال في الإنتاج. تحتوي GCP على مستويَي خدمة شبكة: يوجّه Premium حركة المرور عبر الشبكة الخاصة لـ Google من نقطة الدخول إلى الوجهة (أقل زمن استجابة، أعلى موثوقية)؛ تستخدم Standard الإنترنت العام حتى المنطقة. Premium هو الافتراضي لموازنات الأحمال العالمية وهو الاختيار الصحيح لأي شيء يواجه العملاء.

Cloud NAT والوصول الخاص لـ Google

تحتاج الأجهزة الافتراضية في الشبكة الفرعية الخاصة إلى اتصال خارجي دون عنوان IP عام. Cloud NAT في GCP هي خدمة NAT مُدارة بالكامل وعالية التوفر — لا توجد أجهزة بوابة NAT تحتاج لتصحيح أو توسعة. اقرنها مع Private Google Access على شبكاتك الفرعية: عند تفعيله، يمكن للأجهزة الافتراضية ذات العناوين الداخلية فقط الوصول إلى Google APIs (Cloud Storage، Pub/Sub، BigQuery) عبر الشبكة الخاصة لـ Google دون المرور عبر NAT.

حادثة إنتاج شائعة: يفشل جهاز افتراضي في شبكة فرعية خاصة في سحب صور الحاويات من Artifact Registry. السبب الجذري دائماً تقريباً هو أن Private Google Access غير مُفعَّل على الشبكة الفرعية، أو أن موجّه Cloud NAT لا يشمل مساراً لـ 0.0.0.0/0. تحقق بـ gcloud compute routers get-nat-mapping-info <router-name> --region=<region>.

أنماط الفشل الإنتاجي الواجب معرفتها

هذه أكثر مشاكل الحوسبة والشبكات في GCP ظهوراً في دورات الإنتاج:

استنفاد الحصة. لدى GCE حصص لكل مشروع ومنطقة على المعالجات وعناوين IP والأقراص. تفشل مهام التوسع التلقائي بصمت عند بلوغ الحصة. راقب serviceruntime.googleapis.com/quota/exceeded في Cloud Monitoring.
حلقات المعالجة في مجموعات الأجهزة الافتراضية المُدارة. إذا أرجع مسار فحص الصحة غير 200 أثناء بدء تشغيل التطبيق، ستدمر المجموعة المُدارة الجهاز وتعيد إنشاؤه بشكل متكرر. نفّذ دائماً نقطة نهاية /healthz مخصصة واضبط initial_delay_sec.
تعارض أولوية قواعد جدار الحماية. قواعد جدار حماية GCP مرتبة بالأولوية (0-65535، أقل = أعلى أولوية). قاعدة سماح مُهيأة بشكل خاطئ بأولوية أعلى رقماً ستخسر بصمت أمام قاعدة رفض بأولوية أقل رقماً.
خطأ في إعداد وقت التصريف للخادم الخلفي. خدمة الخادم الخلفي لموازن الأحمال لها connection_draining_timeout_sec (الافتراضي 300 ثانية). اضبطها لتطابق زمن استجابة p99 للطلبات مع هامش أمان.

تكافئ طبقة الحوسبة والشبكات في GCP المهندسين الذين يأخذون الوقت الكافي لفهم تصميمها العالمي الأول. نموذج VPC وبنية موازنة الأحمال والترحيل المباشر معاً تُمكّن من بناء أنظمة موزعة عالمياً دائمة التشغيل تستلزم تعقيداً أكبر بكثير في الإعداد على السحب الأخرى.