مرحبًا ، اسمي Kostya Kramlikh ، أنا المطور الرئيسي لقسم Virtual Private Cloud في Yandex.Cloud. أنا متصل بالشبكة الافتراضية ، وكما قد تتخيل ، سأتحدث في هذه المقالة عن جهاز Virtual Private Cloud (VPC) بشكل عام والشبكة الافتراضية بشكل خاص. وستكتشف أيضًا سبب تقديرنا نحن ، مطورو الخدمة ، التعليقات الواردة من مستخدمينا. لكن أول الأشياء أولاً.
ما هو VPC؟
في الوقت الحاضر ، هناك مجموعة متنوعة من الخيارات لنشر الخدمات. أنا متأكد من أن شخصًا ما لا يزال يحتفظ بالخادم تحت مكتب المسؤول ، على الرغم من أنني آمل أن يكون هناك عدد أقل من هذه القصص.
تحاول الخدمات الآن الانتقال إلى السحابة العامة ، وهنا تتصادم مع VPCs. VPC هو جزء من السحابة العامة التي تربط المستخدم والبنية التحتية والنظام الأساسي والقدرات الأخرى معًا ، أينما كانوا ، في السحابة الخاصة بنا أو خارجها. في الوقت نفسه ، يسمح لك VPC بعدم تعريض هذه القدرات للإنترنت دون داع ، فهي تظل داخل شبكتك المعزولة.
كيف تبدو الشبكة الافتراضية من الخارج؟
من خلال VPC ، نعني بشكل أساسي شبكة تراكب وخدمات الشبكة ، مثل VPNaaS و NATaas و LBaas وما إلى ذلك ، وكل هذا يعمل على رأس بنية تحتية للشبكة تتسامح مع الأخطاء ، والتي تم بالفعل هنا في حبري.
دعنا نلقي نظرة فاحصة على الشبكة الافتراضية وجهازها.
ضع في اعتبارك منطقتين متاحتين. نحن نقدم شبكة افتراضية - ما نسميه VPC. في الواقع ، إنها تحدد مساحة تفرد عناوينك "الرمادية". داخل كل شبكة افتراضية ، لديك سيطرة كاملة على مساحة العناوين التي يمكنك تخصيصها لحساب الموارد.
الشبكة عالمية. في الوقت نفسه ، يتم عرضه على كل منطقة من مناطق الإتاحة في شكل كيان يسمى الشبكة الفرعية. لكل شبكة فرعية ، تقوم بتعيين CIDR بحجم 16 أو أقل. يمكن أن يكون هناك أكثر من كيان واحد في كل منطقة توافر ، وهناك دائمًا توجيه شفاف بينها. هذا يعني أن جميع مواردك في نفس VPC يمكنها "التحدث" مع بعضها البعض ، حتى لو كانت في مناطق توافر خدمات مختلفة. "التواصل" دون الوصول إلى الإنترنت ، من خلال قنواتنا الداخلية ، "معتقدًا" أنهم داخل نفس الشبكة الخاصة.
يوضح الرسم البياني أعلاه موقفًا نموذجيًا: اثنان من VPC يتقاطعان في مكان ما في العناوين. كلاهما يمكن أن يكون لك. على سبيل المثال ، أحدهما للتطوير والآخر للاختبار. قد يكون هناك ببساطة مستخدمين مختلفين - في هذه الحالة لا يهم. ويتم توصيل آلة افتراضية واحدة بكل VPC.
دعونا نجعل المخطط أسوأ. يمكنك إجراء ذلك بحيث يتم تعليق جهاز افتراضي واحد في عدة شبكات فرعية في وقت واحد. وليس هكذا فحسب ، بل في شبكات افتراضية مختلفة.
في الوقت نفسه ، إذا كنت بحاجة إلى تعريض الأجهزة للإنترنت ، فيمكن القيام بذلك من خلال واجهة برمجة التطبيقات أو واجهة المستخدم. للقيام بذلك ، تحتاج إلى تكوين ترجمة NAT لعنوانك الداخلي "الرمادي" إلى "أبيض" - عام. لا يمكنك اختيار عنوان "أبيض" ، يتم تعيينه عشوائيًا من مجموعة العناوين لدينا. بمجرد التوقف عن استخدام IP الخارجي ، يتم إرجاعه إلى التجمع. أنت تدفع فقط مقابل وقت استخدام العنوان "الأبيض".
من الممكن أيضًا منح الجهاز إمكانية الوصول إلى الإنترنت باستخدام مثيل NAT. يمكنك توجيه حركة المرور إلى مثيل من خلال جدول توجيه ثابت. لقد قدمنا مثل هذه الحالة ، لأن المستخدمين يحتاجون إليها أحيانًا ، ونحن نعرف ذلك. وفقًا لذلك ، يحتوي كتالوج الصور الخاص بنا على صورة NAT تم تكوينها خصيصًا.
ولكن حتى في حالة وجود صورة NAT جاهزة ، يمكن أن يكون الإعداد صعبًا. لقد فهمنا أنه بالنسبة لبعض المستخدمين ، هذا ليس الخيار الأكثر ملاءمة ، لذلك في النهاية جعلنا من الممكن تمكين NAT للشبكة الفرعية المطلوبة بنقرة واحدة. لا تزال هذه الميزة في الوصول للمعاينة المغلقة ، حيث يتم اختبارها بمساعدة أعضاء المجتمع.
كيف يتم ترتيب الشبكة الافتراضية من الداخل
كيف يتفاعل المستخدم مع الشبكة الافتراضية؟ يبدو الويب إلى الخارج من خلال واجهة برمجة التطبيقات الخاصة به. يأتي المستخدم إلى API ويعمل مع الحالة المستهدفة. من خلال واجهة برمجة التطبيقات ، يرى المستخدم كيف يجب ترتيب كل شيء وتهيئته ، بينما يرى الحالة ، إلى أي مدى تختلف الحالة الفعلية عن الحالة المطلوبة. هذه صورة للمستخدم. ماذا يحدث بالداخل؟
نكتب الحالة المطلوبة إلى قاعدة بيانات Yandex ونذهب لتكوين أجزاء مختلفة من VPC الخاص بنا. تعتمد شبكة التراكب في Yandex.Cloud على مكونات محددة من OpenContrail ، والتي تم تسميتها مؤخرًا Tungsten Fabric. يتم تنفيذ خدمات الشبكة على منصة CloudGate واحدة. في CloudGate ، استخدمنا أيضًا عددًا من المكونات مفتوحة المصدر: GoBGP - للوصول إلى معلومات التحكم ، بالإضافة إلى VPP - لتنفيذ موجه برمجي يعمل فوق DPDK لمسار البيانات.
تتواصل Tungsten Fabric مع CloudGate عبر GoBGP. يخبرنا بما يحدث في شبكة التراكب. CloudGate ، بدوره ، يربط شبكات التراكب مع بعضها البعض ومع الإنترنت.
الآن دعنا نرى كيف تحل الشبكة الافتراضية مشاكل التوسع والتوافر. لنفكر في حالة بسيطة. توجد منطقة توافر واحدة ويتم إنشاء VPCs فيها. قمنا بنشر مثيل Tungsten Fabric ، وهو يسحب عدة عشرات الآلاف من الشبكات. تتواصل الشبكات مع CloudGate. CloudGate ، كما قلنا سابقًا ، يضمن اتصالهم ببعضهم البعض ومع الإنترنت.
لنفترض أنه تمت إضافة منطقة توافر ثانية. يجب أن تفشل بشكل مستقل تمامًا عن الأول. لذلك ، في منطقة الإتاحة الثانية ، يجب علينا تثبيت مثيل Tungsten Fabric منفصل. سيكون هذا نظامًا منفصلاً يتعامل مع التراكب ولا يعرف إلا القليل عن النظام الأول. والرؤية بأن شبكتنا الافتراضية عالمية ، في الواقع ، تخلق VPC API الخاص بنا. هذه هي مهمته.
يتم تعيين VPC1 إلى منطقة توافر الخدمات B إذا كانت هناك موارد في منطقة توافر الخدمات B تم دفعها إلى VPC1. إذا لم تكن هناك موارد من VPC2 في منطقة التوفر B ، فلن نقوم بتحقيق VPC2 في هذه المنطقة. في المقابل ، نظرًا لأن الموارد من VPC3 موجودة فقط في المنطقة B ، فإن VPC3 غير موجود في المنطقة A. كل شيء بسيط ومنطقي.
دعنا نتعمق قليلاً ونرى كيف يعمل مضيف معين في Y.Cloud. الشيء الرئيسي الذي أريد أن أشير إليه هو أن جميع المضيفين يتم ترتيبهم بنفس الطريقة. نجعله يعمل على الحد الأدنى الضروري من الخدمات فقط ، بينما يعمل الباقي على الأجهزة الافتراضية. نحن نبني خدمات عالية المستوى بناءً على خدمات البنية التحتية الأساسية ، ونستخدم أيضًا السحابة لحل بعض المشكلات الهندسية ، على سبيل المثال ، في إطار التكامل المستمر.
إذا نظرنا إلى مضيف معين ، يمكننا أن نرى أن هناك ثلاثة مكونات تعمل على نظام التشغيل المضيف:
- الحساب - الجزء المسؤول عن توزيع موارد الحوسبة على المضيف.
- VRouter هو جزء من Tungsten Fabric الذي ينظم تراكبًا ، أي أنه ينفق الحزم من خلال طبقة أساسية.
- VDisks هي أجزاء من التخزين الافتراضي.
بالإضافة إلى ذلك ، يتم إطلاق الخدمات في الأجهزة الافتراضية: خدمات البنية التحتية السحابية وخدمات النظام الأساسي وقدرات العملاء. دائمًا ما تنتقل قدرات العملاء وخدمات النظام الأساسي إلى التراكب من خلال VRouter.
يمكن أن تلتصق خدمات البنية التحتية بالتراكب ، لكنهم يريدون بشكل أساسي العمل في الأساس. هم عالقون في الأساس بمساعدة SR-IOV. في الواقع ، قمنا بتقطيع البطاقة إلى بطاقات شبكة افتراضية (وظائف افتراضية) ودفعناها إلى أجهزة افتراضية للبنية التحتية حتى لا نفقد الأداء. على سبيل المثال ، يتم إطلاق CloudGate نفسه كأحد هذه الأجهزة الافتراضية للبنية التحتية.
الآن بعد أن وصفنا المهام العالمية للشبكة الافتراضية وهيكل المكونات الأساسية للسحابة ، دعنا نرى بالضبط كيف تتفاعل الأجزاء المختلفة من الشبكة الافتراضية مع بعضها البعض.
نميز في نظامنا ثلاث طبقات:
- تكوين الطائرة - يحدد الحالة المستهدفة للنظام. هذا ما يقوم المستخدم بتكوينه عبر واجهة برمجة التطبيقات.
- مستوى التحكم - يوفر دلالات معرّفة من قبل المستخدم ، أي إحضار حالة مستوى البيانات إلى ما وصفه المستخدم في Config Plane.
- طائرة البيانات - تعالج حزم المستخدم مباشرة.
كما قلت أعلاه ، يبدأ كل شيء بحقيقة أن المستخدم أو خدمة النظام الأساسي الداخلي تأتي إلى واجهة برمجة التطبيقات وتصف حالة هدف معينة.
تتم كتابة هذه الحالة على الفور إلى قاعدة بيانات Yandex ، وتُرجع معرّف العملية غير المتزامن عبر واجهة برمجة التطبيقات ، وتبدأ آليتنا الداخلية في إرجاع الحالة التي أرادها المستخدم. تنتقل مهام التكوين إلى وحدة تحكم SDN وتخبر Tungsten Fabric بما يجب القيام به في التراكب. على سبيل المثال ، يقومون بحجز المنافذ والشبكات الافتراضية وما شابه.
يرسل Config Plane في Tungsten Fabric الحالة المطلوبة إلى مستوى التحكم. من خلالها ، تتواصل Config Plane مع المضيفين ، لتخبرهم بما سيدور عليهم بالضبط قريبًا.
الآن دعنا نرى كيف يبدو النظام على المضيفين. يحتوي الجهاز الظاهري على محول شبكة متصل بـ VRouter. VRouter عبارة عن وحدة أساسية من Tungsten Fabric تبحث في الحزم. إذا كان هناك تدفق بالفعل لبعض الحزم ، تقوم الوحدة بمعالجتها. إذا لم يكن هناك تدفق ، فإن الوحدة تقوم بما يسمى الركلة ، أي أنها ترسل حزمة إلى عملية المستخدم. تقوم العملية بتوزيع الحزمة وإما أنها تستجيب لها بنفسها ، مثل DHCP و DNS ، أو تخبر VRouter بما يجب فعله بها. بعد ذلك ، يمكن لـ VRouter معالجة الحزمة.
علاوة على ذلك ، تمر حركة المرور بين الأجهزة الافتراضية داخل نفس الشبكة الافتراضية بشفافية ، ولا يتم توجيهها إلى CloudGate. يتواصل المضيفون الذين يتم نشر الأجهزة الافتراضية عليهم مباشرة مع بعضهم البعض. إنهم ينقلون حركة المرور ويوجهونها لبعضهم البعض من خلال القاعدة السفلية.
تتواصل مستويات التحكم مع بعضها البعض بين مناطق التوفر عبر BGP ، كما هو الحال مع جهاز توجيه آخر. إنهم يخبرون الأجهزة الموجودة في مكانها بحيث يمكن لأجهزة VM في منطقة واحدة التواصل مباشرة مع أجهزة افتراضية أخرى.
وتتواصل طائرة التحكم مع CloudGate. وبالمثل ، فإنه يُبلغ عن مكان وما هي الأجهزة الافتراضية التي يتم رفعها ، والعناوين التي لديها. يسمح لك هذا بتوجيه حركة المرور الخارجية وحركة المرور من الموازين إليهم.
تأتي حركة المرور التي تترك VPC إلى CloudGate ، إلى مسار البيانات ، حيث يتم مضغ VPP مع المكونات الإضافية بسرعة. ثم يتم تشغيل حركة المرور إما إلى VPCs الأخرى أو خارجها ، إلى أجهزة التوجيه الحدودية التي تم تكوينها من خلال لوحة التحكم الخاصة بـ CloudGate نفسها.
خطط المستقبل القريب
إذا قمنا بتلخيص كل ما قيل أعلاه في بضع جمل ، فيمكننا القول أن VPC في Yandex.Cloud يحل مهمتين مهمتين:
- يوفر العزلة بين العملاء المختلفين.
- يجمع بين الموارد والبنية التحتية وخدمات النظام الأساسي والسحابات الأخرى والمحلية في شبكة واحدة.
ومن أجل حل هذه المشكلات بشكل جيد ، تحتاج إلى توفير قابلية التوسع والتسامح مع الأخطاء على مستوى البنية الداخلية ، وهو ما يفعله VPC.
تدريجيًا يكتسب VPC وظائف ، ونقوم بتنفيذ ميزات جديدة ، ونحاول تحسين شيء ما من حيث راحة المستخدم. يتم التعبير عن بعض الأفكار والحصول على قائمة الأولويات بفضل أعضاء مجتمعنا.
لدينا حاليًا قائمة الخطط التالية للمستقبل القريب:
- VPN كخدمة
- مثيلات DNS الخاصة هي صور لإعداد الأجهزة الافتراضية بسرعة باستخدام خادم DNS تم تكوينه مسبقًا.
- DNS كخدمة.
- موازن الحمل الداخلي.
- إضافة عنوان IP "أبيض" بدون إعادة إنشاء الجهاز الظاهري.
كان الموازن والقدرة على تبديل عنوان IP لجهاز ظاهري تم إنشاؤه بالفعل في هذه القائمة بناءً على طلب المستخدمين. لنكون صادقين ، بدون ردود فعل صريحة ، كنا سنقوم بهذه الوظائف بعد ذلك بقليل. ولذا فإننا نعمل بالفعل على حل مشكلة العناوين.
مبدئيًا ، لا يمكن إضافة عنوان IP "أبيض" إلا عند إنشاء جهاز. إذا نسي المستخدم القيام بذلك ، فيجب إعادة إنشاء الجهاز الظاهري. نفس الشيء ، وإذا لزم الأمر ، قم بإزالة عنوان IP الخارجي. سيكون من الممكن قريبًا تشغيل IP العام وإيقاف تشغيله دون الحاجة إلى إعادة إنشاء الجهاز.
لا تتردد في التعبير عن الخاص بك مستخدمين آخرين. أنت تساعدنا في تحسين السحابة والحصول على ميزات مهمة ومفيدة بشكل أسرع!
المصدر: www.habr.com