في هذه المقالة ، يشارك إيغور كوتينكو ، كبير المهندسين المعماريين في Neoflex ، تجربته في نشر منصة حاويات على البنية التحتية للمؤسسة.
غالبًا ما تكون الأسباب التي تجعل الشركات تختار عادةً حلًا محليًا غير تقنية وغالبًا ما تتعلق بالتمويل. يحاول شخص ما تقليل تكاليف التشغيل (الدفع مقابل السحب الخارجية) لصالح الاستفادة من الشركة (شراء الخوادم الخاصة بهم) ، شخص ما لديه بالفعل موارد صلبة للأجهزة ويريد استخدامها في بنية الخدمات المصغرة.
قبل الانتقال إلى تفاصيل التنفيذ ، دعنا ننتقل إلى الشروط.
يعتبر مصطلح "السحب" مكتظًا جدًا. من المعتاد التمييز بين الأنواع المختلفة للحلول السحابية:
- البنية التحتية كخدمة (IAAS) - الأجهزة (الافتراضية عادةً) ؛
- البرمجيات كخدمة (SAAS) ، على سبيل المثال ، DBAS - قاعدة البيانات كخدمة ؛
- النظام الأساسي كخدمة (PAAS) ؛
- التطبيق كخدمة (AAAS).
في الوقت نفسه ، لا شيء يمنع الطبقات من أن تكون مبنية على بعضها البعض. من الواضح أنه ستكون هناك بنية تحتية تحت النظام الأساسي أو البرنامج.
هناك بعض الالتباس حول مصطلح "السحب الخاصة". يُطلق على ذلك أحيانًا اسم السحابة المحلية ، ويتم نشرها أحيانًا على بنية تحتية مؤجرة مع عزل كامل لشريحة الشبكة الخاصة بك. حتى أنه كان هناك ذكر للأجهزة الافتراضية ذات الذاكرة والأقراص المشفرة ، في حين أن تفريغ الذاكرة لن يمنح الموفر إمكانية الوصول إلى معلوماتك. في هذه المقالة ، سنناقش الحلول التي تم نشرها داخليًا - داخل الشركة.
عند تقديم السحابات الخاصة ، من المتوقع أن تكون مماثلة للسحابات العامة ، ولكنها أرخص وأكثر أمانًا وموثوقية. لذلك ، يعتقد الكثير من الناس أن السحب الخاصة أفضل بداهة. غالبًا ما ينشر الخبراء الإصدار المختار من Kubernetes أو Openshift ويعتقدون أن هذا هو المكان الذي يتم فيه إكمال عملهم.
ما الذي تتوقع الشركات الحصول عليه عند تنفيذ السحب في أماكن العمل:
- انخفاض تكلفة الموارد. لأنك تدفع فقط مقابل ما تستخدمه.
- القدرة على إضافة الموارد وإعادتها في أسرع وقت ممكن.
- التسامح مع الخطأ. تعطل الخادم ، وتم منح خادم آخر تلقائيًا بدلاً منه.
- تكلفة صيانة منخفضة.
كيف يتم تحقيق ذلك في السحب العامة؟
كقاعدة عامة ، بسبب أتمتة العمليات ، وفورات الحجم (أرخص بالجملة) وتقاسم الموارد بين مختلف المستهلكين.
دعونا نلقي نظرة على هذه الوعود في سياق السحب الخاصة.
1. انخفاض تكلفة الموارد مقارنة بالبنية التحتية التقليدية.
في الحقيقة ، الأمر ليس كذلك. تم نشر نفس البرنامج على نفس الأجهزة ، ولكن في حاويات. في تجربتنا ، على العكس من ذلك ، يتم إهدار المزيد من الموارد.
2. القدرة على زيادة وتقليل الموارد بسرعة كبيرة.
لا. للتوسيع ، تحتاج إما إلى الاحتفاظ بالاحتياطي السريع لتراخيص الأجهزة والبرامج خاملاً ، أو التخلص أولاً من شيء غير ضروري. يمكنك إزالة الموارد من الاستخدام ، ولكن بعد ذلك ستكون خاملة.
3. التسامح مع الخطأ.
نعم ، ولكن هناك العديد من الفروق الدقيقة. لنفترض أن الخادم معطل. من أين يمكنني الحصول على واحد آخر؟ كيف يتم نشره بسرعة وإضافته إلى مجموعة؟ إذا لم تكن أمازون ، فلن يكون لديك مورد غير محدود من الموارد.
4. انخفاض تكلفة الدعم.
لقد أضفنا طبقة واحدة على الأقل (منصة حاوية) ، والعديد من الأنظمة الجديدة. نحتاج لمتخصصين ذوي كفاءات جديدة. من أين ستأتي المدخرات؟
دعونا نفحص هذه الأسئلة بمزيد من التفصيل. من المهم أن نتذكر أن السحابات الخاصة يجب أن تتعايش مع الأنظمة القديمة الحالية. تضطر المنظمات إلى الحفاظ على البنية التحتية للأنظمة الحالية بالتوازي ، وتنظيم بيئة تكنولوجيا المعلومات المختلطة.
بطبيعة الحال ، 99٪ من النظام غير مبني من الصفر. عادة ، حتى قبل تنفيذ حل PAAS ، هناك مجموعة من العمليات والأتمتة لدعم البنية التحتية القديمة. عمليات DevOps والتخطيط وملكية الموارد والمراقبة وتحديثات البرامج والأمان - يجب الاتفاق على كل هذه المشكلات وتغييرها أثناء تنفيذ السحابة الخاصة.
كيف تتغير عمليات DevOps
عادةً ، قبل تنفيذ PAAS الخاص بك ، يعتمد نهج إنشاء DevOps على استخدام أنظمة أتمتة التكوين مثل Ansible أو Chef. إنها تسمح لك بأتمتة جميع عمليات تكنولوجيا المعلومات الروتينية تقريبًا ، وغالبًا ما تستخدم مكتبات البرامج النصية الجاهزة. ومع ذلك ، فإن منصات النقل بالحاويات تروج لنهج بديل - "البنية التحتية الثابتة". لا يكمن جوهرها في تغيير النظام الحالي ، بل في التقاط صورة افتراضية جاهزة للنظام بإعدادات جديدة واستبدال الصورة القديمة بأخرى جديدة. لا يلغي النهج الجديد الأسلوب القديم ، ولكنه يفرض أتمتة التكوين في طبقة البنية التحتية. بالطبع ، تتطلب الأنظمة القديمة الحفاظ على النهج القديم.
لنتحدث عن طبقة البنية التحتية
المعيار الفعلي في تكنولوجيا المعلومات هو استخدام البنية التحتية الافتراضية. كما تبين الممارسة ، فإن الخيار الأكثر شيوعًا هو استخدام vSphere. هناك أسباب عديدة لذلك ، ولكن هناك أيضًا عواقب. في ممارستنا ، تفاقمت المشاكل المتكررة مع زيادة الاكتتاب من حيث الموارد (محاولة لخياطة سبعة أغطية من جلد واحد) بسبب الافتقار شبه الكامل للسيطرة والتأثير على هذه العملية من المسؤولين عن أداء الحل. أدى تحديد مجالات المسؤولية في أقسام الشركة وإضفاء الطابع الرسمي على إجراءات طلب الموارد والأهداف المختلفة لإدارة الأقسام إلى مشاكل في بيئة المنتج واختبار الحمل غير المتسق. في مرحلة ما ، أنشأ قسم التطوير لدينا أداة قياس أداء أساسية افتراضية ،لتشخيص نقص موارد الأجهزة بسرعة.
من الواضح أن محاولة وضع منصة حاويات على مثل هذه البنية التحتية ستجلب ألوانًا جديدة إلى الفوضى الحالية.
لقد تمت مناقشة مسألة ما إذا كانت منصة الحاوية في مقر الشركة تحتاج إلى بنية تحتية افتراضية أم أنه من الأفضل وضعها بدون استخدام (على خوادم حديدية) لفترة طويلة وعلى نطاق واسع. تجادل المقالات التي تم الضغط عليها من قبل الشركات المصنعة لأنظمة المحاكاة الافتراضية بأنه لا توجد خسائر في الأداء عمليًا ، وأن الفوائد كبيرة جدًا. من ناحية أخرى ، هناك نتائج اختبار مستقلة تظهر خسارة 10٪ أو أكثر في الأداء. لا تنس تكلفة تراخيص vSphere. على سبيل المثال ، لتثبيت إصدار مجاني من Kubernetes على أجهزة غير مكلفة فقط لتوفير المال والدفع مقابل vSphere؟ قرار مثير للجدل.
تجدر الإشارة إلى أحد حلول افتراضية البنية التحتية مفتوحة المصدر ، على سبيل المثال ، Open Stack. بشكل عام ، كان يُنظر إليه على أنه حل يتطلب استثمارًا جادًا في الفريق. هناك إحصائيات على الشبكة ، تفيد بأن حجم فريق دعم Open Stack يتراوح من 20 إلى 60 شخصًا. وهذا منفصل عن دعم منصة الحاويات! يوجد عدد قليل من هؤلاء المتخصصين في السوق ، مما يزيد من تكلفتهم. عادة ما تؤتي هذه الاستثمارات ثمارها فقط على كميات كبيرة جدًا من الموارد.
من المهم مراعاة وجود متخصصين ذوي كفاءات فريدة في الشركة. لسوء الحظ ، غالبًا ما يتم إعاقة عمليات تثبيت Kubernetes المعدنية ، على الرغم من مزايا الشفافية وانخفاض تكاليف الترخيص ، بسبب ، على سبيل المثال ، عدم وجود أدوات أتمتة التثبيت المناسبة. نأمل أن يكون المستقبل لهذا النهج.
هناك جانب آخر يؤثر على الاختيار بين التركيبات الافتراضية والمعدنية وهو تنظيم الخوادم الحديدية.
عادة ، تشتري المنظمة خوادم لأغراض محددة. يمكنك استئجار خوادم في مركز البيانات (مما يقدمونه) ، يمكنك توحيد وتوحيد التسمية (تبسيط تكرار المكونات) ، يمكنك التوفير على الأجهزة (العديد من الخوادم غير المكلفة) ، يمكنك توفير مساحة الرف. مناهج مختلفة في منظمات مختلفة. بشكل عام ، هذه إما خوادم قوية مع عدد كبير من النوى والذاكرة ، أو صغيرة الحجم نسبيًا ، أو خليط مركب. لكن لا تنسى احتياجات الأنظمة القديمة. في هذه المرحلة ، نواجه مرة أخرى تناقضًا في المفاهيم. أيديولوجية Kubernetes هي الكثير من الأجهزة الرخيصة والاستعداد لفشلها. سقط الخادم - لا يهم ، انتقلت خدماتك إلى خدمة أخرى. البيانات مجزأة (مكررة) وليست مرتبطة بحاوية. الأيديولوجية القديمة - التكرار على مستوى الأجهزة. مصفوفات RAIDرفوف القرص ، وإمدادات الطاقة المتعددة على الخادم ، والمبادلة الساخنة. ركز على أقصى قدر من الموثوقية. قد تكون المشاركة في مثل هذه البنية التحتية لـ Kubernetes مكلفة بشكل غير معقول.
, …
إذا كان لدى الشركة خوادم عالية الأداء مع العديد من النوى على متنها ، فقد يكون من الضروري تقسيمها بين مستهلكين مختلفين. هنا لن تكون قادرًا على الاستغناء عن نظام المحاكاة الافتراضية. في الوقت نفسه ، من الضروري مراعاة إمكانية فشل الخادم أو توقفه للصيانة. العملية الحسابية بسيطة: إذا كان لديك خادمان ، وفي حالة فشل أحدهما ، فإنك تحتاج إلى احتياطي طاقة بنسبة 50٪ لكل منهما ؛ إذا - 4 خوادم ، إذا فشل أحدها ، فأنت بحاجة إلى 25٪ احتياطي. للوهلة الأولى ، كل شيء بسيط - فأنت بحاجة إلى عدد لا حصر له من الخوادم ، ثم لن يؤثر فشل أحدها على السعة الإجمالية ولن تحتاج إلى حجز أي شيء. للأسف ، لا يمكن تقليل حجم موارد مضيف واحد بشكل كبير. كحد أدنى ، يجب أن تستوعب جميع المكونات ذات الصلة ، والتي تسميها مصطلحات Kubernetes "pods". وبالطبع ، عند التكسير في خوادم أصغر ،تتزايد التكاليف العامة لخدمات المنصة نفسها.
لأغراض عملية ، من المستحسن توحيد معلمات المضيف للنظام الأساسي. في الأمثلة القريبة من الحياة ، يوجد مركزان للبيانات (دعم سيناريو DR يعني حجز 50٪ على الأقل من الموارد من حيث السعة). بعد ذلك ، يتم تحديد احتياجات المنظمة لموارد منصة الحاوية وإمكانية وضعها على مضيفين عاديين أو افتراضيين. توصية Kubernetes - لا يزيد عن 110 كبسولات لكل عقدة.
وبالتالي ، لتحديد حجم العقدة ، عليك مراعاة ما يلي:
- من المستحسن جعل العقد متساوية ؛
- يجب أن تتناسب العقد مع أجهزتك (للأجهزة الافتراضية - المضاعفات ، N الظاهري لقطعة واحدة من الأجهزة) ؛
- إذا فشلت عقدة واحدة (بالنسبة للإصدار الذي يحتوي على بنية تحتية افتراضية - خادم حديدي واحد) ، يجب أن يكون لديك موارد كافية على العقد المتبقية لنقل الكبسولات إليها ؛
- لا يمكن أن يكون هناك عدد كبير جدًا من القرون (> 110) على عقدة واحدة ؛
- مع تساوي الأشياء الأخرى ، من المستحسن جعل العقد أكبر.
يجب مراعاة هذه الأنواع من الميزات في كل جانب من جوانب الهندسة المعمارية.
التسجيل المركزي - كيف تختار من بين عدة خيارات؟
المراقبة - ربما لن يعمل نظام المراقبة الحالي لديك ، أو يحتفظ باثنين أو ينتقل إلى نظام جديد؟
تحديثات النظام الأساسي لإصدار جديد - بشكل منتظم أم فقط عند الضرورة القصوى؟
الموازنة المتسامحة بين مركزي بيانات - كيف؟
هندسة الأمن ، التفاعل مع الأنظمة القديمة - هناك اختلافات عن السحب العامة. من الممكن التوصية بأنظمة البناء بحيث تكون هناك إمكانية للهجرة إلى السحب العامة ، لكن هذا سيعقد الحل.
يختلف تخطيط الموارد وتخصيصها وملكيتها للسحب العامة والخاصة قليلاً. الاختلاف الرئيسي هو كمية الموارد المحدودة. إذا كان من الممكن في أي وقت استخدام موارد إضافية ضرورية في السحب العامة ، على سبيل المثال ، لاختبار الحمل ، فيجب أن يخطط في مكان العمل بعناية لتسلسل استخدامها. هذا يعني أنه قد يكون لديك إطلاقات ليلية ، وبالتالي ، سيزداد عمل الموظفين من الخطين الثاني والثالث في غير ساعات العمل. لا شيء جديد لمن هم بمفردهم ، ولكن طعم مرير لخيبة الأمل للمعجزات التي تنتظر تبني السحابة الخاصة.
"الكوادر يقررون كل شيء"
عند التخطيط لتنفيذ منصة حاويات في مقر الشركة ، أولاً وقبل كل شيء ، هناك حاجة إلى متخصصين ذوي كفاءات فريدة. من الواضح أنه لا يوجد عدد كافٍ منهم في سوق العمل الحالي. علاوة على ذلك ، بدون خبرة في هذا التنفيذ ، من الصعب حتى إعداد قائمة بجميع المتخصصين الضروريين.
على سبيل المثال ، لكي يعمل النظام الأساسي ، تحتاج إلى تحديد نظام تخزين وتثبيته. أيًا كان النظام الذي تختاره (CEPH أو Portworx) ، سيكون مهمًا للمنصة. يعلم الجميع أن الأمر يحتاج إلى مسؤول للحفاظ على قاعدة البيانات. وبالمثل ، يحتاج نظام تخزين البيانات إلى متخصص منفصل. للأسف ، لا أحد يفكر في هذا قبل تطبيق النظام! لاحظ أن الاختلاف بين المسؤولين عن المنتجات المختلفة كبير - يمكن مقارنته بالفرق بين Oracle DBA و MS SQL DBA. ستحتاج إلى شخصين على الأقل لكل دور: الموظفون يذهبون في إجازة ويمرضون وحتى ، لا قدر الله ، يستقيلون. وهكذا لكل اختصاص ، وقائمة الكفاءات المطلوبة لدعم الحل مثيرة للإعجاب.
أود أن أحذر على الفور من محاولات عبور جميع الاختصاصات في بعض الجنود العالميين. إن تكلفتها وندرتها ومخاطر فقدانها تتجاوز كل الحدود المعقولة.
مرة أخرى ، صيانة السحابة عملية معقدة. لا تأكل شركات السحابة خبزها مقابل لا شيء: هناك ، خلف الضباب الغائم ، هناك الكثير من التكنولوجيا والعمالة المستثمرة.
بالطبع ، يمكن أن يؤدي استخدام الخدمات الاستشارية إلى تسريع تنفيذ النظام الأساسي بشكل كبير. سيساعدك الشركاء المتمرسون على تجنب العديد من الأخطاء وإنشاء العمليات وتدريب فريقك. ومع ذلك ، إذا كنت تستضيف خدمات مهمة لعملك على النظام الأساسي ، فمن المهم بنفس القدر تقديم دعم وتطوير عالي الجودة. علاوة على ذلك ، في الوقت الحالي ، تتطور جميع الأنظمة الموجودة في السوق بنشاط ، وتظهر تقنيات جديدة ، وقد تتطلب الإصدارات الجديدة من النظام الأساسي ترحيل العمليات المعقدة والاختبار الجاد قبل التحديث. مطلوب فريق دعم قوي لضمان التشغيل الموثوق للنظام. وسوف تحتاج إلى مثل هذا الفريق بشكل مستمر.
متى يجب أن تفكر في تنفيذ منصة حاوية داخل الشركة؟
بادئ ذي بدء ، من الضروري تقييم النسبة بين الاستثمار والعائد ، وحجم تكاليف الأجهزة والموظفين. يجب أن تكون هناك إما أسباب وجيهة لعدم القدرة على العيش في السحب العامة ، أو متطلبات موارد جادة حقًا. أي ، إذا كان حوالي 100 Core كافيًا لمؤسسة ولم تكن مستعدًا لتوسيع فريق الدعم ليشمل عشرات الأشخاص ، فمن المرجح أن تركز على السحابات العامة ، أو على التكوينات البسيطة مع خوادم التطبيقات. يوجد حد أدنى لحجم الفريق مطلوب لدعم النظام الأساسي وقد لا تؤتي التكلفة ثمارها. ومع ذلك ، مع توسيع نطاق الموارد والأتمتة المختصة لجميع العمليات ، يمكن أن تكون فوائد الحل الخاص كبيرة للغاية. يمكن الحفاظ على عدة مئات من العقد بنفس الأمر.
معيار اختيار آخر هو تنوع الاحتياجات لموارد الحوسبة. إذا كانت العمليات التجارية للشركة تخلق عبئًا أكثر أو أقل من الموارد ، فمن المربح تطوير بنيتها التحتية الخاصة. إذا كنت بحاجة إلى استخدام سعة كبيرة ، ولكن نادرًا ، ففكر في السحب العامة أو المختلطة.
على أي حال ، عند اختيار الحلول داخل الشركة ، اضبط العمل الجاد والمنهجي ، واستعد للاستثمار في الفريق. انتقل من البسيط إلى المعقد. كن منتبهاً لتوقيت التنفيذ ، وكن حذرًا بشكل خاص عند الترقية إلى إصدارات جديدة من النظام الأساسي. استخدم الخبرة المكتسبة من أخطاء الآخرين وليس من أخطائك.
نشكرك على قراءة هذا المقال ، نأمل أن تجد المعلومات مفيدة.