شبكات السحابة على نطاق واسع: المحور والأطراف والربط الهجين

طريقان إلى نفس الفكرة

قبل أن تبدأ

الفكرة الجوهرية

1خطة العناوين قبل كل شيء

خصص لكل منطقة جزءًا من 10.0.0.0/8، ولكل شبكة /16 أو /20 حسب حجمها، واحجز ما لمراكز البيانات والفروع، ولا تستخدم أبدًا الافتراضي 10.0.0.0/16 أو 172.31.0.0/16 لأن كل حساب جديد يأتي به. والسبب: شبكتان متداخلتان لا تُوجّه بينهما دون NAT معقد، وتغيير عناوين شبكة تعمل يعني إعادة بناء كل ما فيها.

كل منطقة /12 فيها 16 شبكة /16. الشبكة التي أنشأها فريق بالافتراضي تتداخل مع مركز البيانات فورًا.

import ipaddress

on_prem = [ipaddress.ip_network(n) for n in ("10.0.0.0/12", "192.168.0.0/16")]   # data centres and branches
cloud = ipaddress.ip_network("10.64.0.0/10")                                       # everything in the cloud
regions = dict(zip(["me-central", "eu-west", "us-east"], cloud.subnets(new_prefix=12)))

plan = {}
for region, block in regions.items():
    nets = block.subnets(new_prefix=16)
    for env in ("prod", "dev", "shared"):
        plan[f"{region}/{env}"] = next(nets)

for name, net in plan.items():
    clash = [str(o) for o in on_prem if net.overlaps(o)]
    print(f"{name:<18} {str(net):<15}", "OVERLAP " + ", ".join(clash) if clash else "ok")

team_default = ipaddress.ip_network("10.0.0.0/16")
print("a team using the default 10.0.0.0/16 clashes with on-prem:", any(team_default.overlaps(o) for o in on_prem))
print("usable hosts in a /24 subnet on AWS:", ipaddress.ip_network("10.64.1.0/24").num_addresses - 5)

2لماذا المحور؟

الربط المباشر بسيط لشبكتين أو ثلاث. لكنه لا يتعدى، فكل شبكة تحتاج ربطًا بكل شبكة، ولا مكان مركزيًا للفحص. مع المحور تتصل كل شبكة مرة واحدة، وجداول التوجيه في المحور تقرر من يصل إلى من: الإنتاج لا يرى التطوير، وكل شيء نحو الإنترنت يمر بشبكة الفحص.

مع 200 شبكة: نحو عشرين ألف ربط مباشر، أو 200 اتصال بالمحور.

for n in (3, 10, 50, 200):
    print(f"{n:>3} networks: peering mesh {n * (n - 1) // 2:>6} links | hub {n:>3} attachments")

3الربط بمركز البيانات: VPN أم وصلة مخصصة؟

VPN عبر الإنترنت يعمل في ساعة، رخيص، لكن كمونه يتغير مع الإنترنت وسعته محدودة للنفق. الوصلة المخصصة (Direct Connect في AWS، وExpressRoute في Azure) كابل فعلي عبر شريك اتصالات إلى السحابة: كمون ثابت وسعات من 1 إلى 100 Gbps، لكنها تأخذ أسابيع وتكلف أكثر. التصميم الشائع: وصلتان مخصصتان في موقعين مختلفين، وVPN احتياطي، وBGP يختار.

4DNS الهجين والوصول الخاص والتكلفة

الخادم في مركز البيانات يحتاج أن يحل أسماء السحابة الخاصة، والعكس. الحل نقاط Resolver داخلية وخارجية وقواعد توجيه لكل نطاق. والوصول الخاص (PrivateLink) يجعل خدمة مثل التخزين أو قاعدة بيانات تظهر بعنوان داخلي في شبكتك فلا تخرج حركتها للإنترنت. أما التكلفة فخفية: الحركة بين المناطق وإلى الإنترنت وعبر بوابات NAT تُحسب بالجيجابايت، فتصميم سيئ ينقل البيانات ذهابًا وإيابًا قد يكلف أكثر من الخوادم.

# Terraform: the hub and two spokes, reviewed in Git like any code
resource "aws_ec2_transit_gateway" "hub" {
  description                     = "core hub"
  default_route_table_association = "disable"   # every attachment picks its table on purpose
}
resource "aws_ec2_transit_gateway_vpc_attachment" "prod" {
  transit_gateway_id = aws_ec2_transit_gateway.hub.id
  vpc_id             = aws_vpc.prod.id
  subnet_ids         = aws_subnet.prod_tgw[*].id
}

مثال محلول

المسألة: شركة ستنقل 40 تطبيقًا إلى السحابة في منطقتين، ولها مركز بيانات بعناوين 10.0.0.0/12. فريقان أنشآ شبكتيهما بـ 10.0.0.0/16. صمّم الشبكة.

الحل: (1) خطة: السحابة كلها 10.64.0.0/10، ولكل منطقة /12، ولكل بيئة /16. (2) شبكتا الفريقين متداخلتان مع المركز: أعد بناءهما الآن قبل أن يكبرا. (3) Transit Gateway في كل منطقة وربط بين المحورين، وجداول توجيه منفصلة للإنتاج والتطوير والمشتركة. (4) شبكة فحص بجدار يمر بها الخروج للإنترنت والحركة بين البيئات. (5) وصلتا Direct Connect في موقعين مع VPN احتياطي، وBGP يفضّل المخصصة. (6) نقاط Resolver لـ DNS الهجين، وPrivateLink للتخزين. (7) كل ذلك في Terraform مع مراجعة في Git.

خرافة مقابل حقيقة

أين تقابله في العمل

اختبر فهمك

بطاقات مراجعة سريعة

تحقق من فهمك